Author: Parnashree Saha

FIPS 140-3 is a U.S. government standard specifying security requirements for cryptographic modules, including hardware and software components. These security requirements are designed to ensure that cryptographic modules provide a minimum level of security for protecting sensitive information and transactions.

Some of the key security requirements specified in FIPS 140-3 include the following

1. Cryptographic module specification

   A detailed specification of the cryptographic module, including its physical and logical boundaries, interfaces, and security functions.

2. Roles and services

   A definition of the roles and services provided by the cryptographic module, including key management, encryption, and authentication.

3. Cryptographic algorithms

   A list of approved cryptographic algorithms that can be used by the cryptographic module, along with specific requirements for key length, block size, and other parameters.

4. Key management

   Requirements for generating, storing, and protecting cryptographic keys, including key lifecycle management and destruction.

5. Physical security

   Requirements for physical security measures to protect the cryptographic module from unauthorized access, tampering, and theft.

6. Logical security

   Requirements for logical security measures to protect the cryptographic module from attacks such as malware, side-channel attacks, and unauthorized access.

7. Security testing and validation

   Requirements for testing and validating the security of the cryptographic module, including vulnerability testing, penetration testing, and compliance testing.

General requirements for each level of FIPS 140-3

The below table explains the general requirements for each level of FIPS 140-3

Table 1: General requirements of FIPS 140-3 for each level

These are the general requirements for each level of FIPS 140-3. However, there are many specific requirements for each level, and the requirements for each level are quite detailed. The purpose of the standard is to provide a framework for evaluating and certifying the security of cryptographic modules. The specific requirements for each level are designed to ensure that the module provides a certain level of protection against various attacks.

FIPS 140-3 Security requirements for each level

FIPS 140-3 is a security standard defining the requirements for cryptographic modules that protect sensitive data.

FIPS 140-3 Level 1

Level 1 of FIPS 140-3 provides the lowest level of security and is intended for use in low-risk applications. The security requirements for level 1 are as follows

1. Cryptographic module specification

   The module must have a concise specification describing its cryptographic functions, interfaces, and protocols.

2. Roles, services, and authentication

   The module must define the roles, services, and authentication mechanisms required for secure operation.

3. Physical security

   The module must have physical safeguards to protect against unauthorized access, theft, or tampering

4. Design assurance

   The module must have undergone a comprehensive design process, including security analysis and testing.

5. Mitigation of attacks

   The module must have measures to prevent or mitigate attacks, such as software or hardware countermeasures

6. Self-tests

   The module must perform self-tests to ensure it is functioning correctly and detect tampering attempts

7. Environmental design

   The module must be designed to operate in various environmental conditions, including temperature, humidity, and electromagnetic interference.

8. Cryptographic key management

   The module must have secure key management processes to ensure that cryptographic keys are generated, stored, and used securely.

FIPS 140-3 Level 2

Level 2 of the FIPS 140-3 standard outlines the security requirements for a cryptographic module that provides moderate security assurance. The following are the specific security requirements for a cryptographic module to achieve FIPS 140-3 level 2

1. Physical security

   The module must be physically protected against unauthorized access, tampering, and theft. It should be designed to withstand environmental hazards like fire, water, and electromagnetic interference.

2. Cryptographic key management

   The module must have strong key management mechanisms that ensure cryptographic keys’ confidentiality, integrity, and availability. The module should protect keys against unauthorized access, modification, and destruction

3. Authentication and access control

   The module must authenticate users and restrict access to authorized users only. It should have strong password policies and mechanisms to prevent brute-force attacks.

4. Audit logging and reporting

   The module must log all security-related events and provide reports to authorized users. The module should also have mechanisms to protect audit logs against tampering or destruction.

5. Software security

   The module must be designed with secure software practices that minimize the risk of security vulnerabilities. The software should be tested for security flaws and vulnerabilities and undergo regular security updates and patches.

6. Communication security

   The module must use secure communication protocols and encryption to protect data in transit. The module should also have mechanisms to prevent unauthorized access to data transmitted over networks.

7. Cryptographic algorithms

   The module must use approved cryptographic algorithms and standards that NIST has validated. The module should also have mechanisms to prevent using weak or outdated cryptographic algorithms.

FIPS 140-3 Level 3

Level 3 of the FIPS 140-3 standard protects against unauthorized cryptographic module access and sensitive information. It is also the third-highest level of FIPS 140-3. The following are the security requirements for level 3

1. Physical Security

   The cryptographic module must be physically protected against unauthorized access, tampering, theft, and damage. The module must also be designed to resist physical attacks, such as drilling, cutting, and probing. The module must be in a secure facility with access controls, video surveillance, and intrusion detection systems.

2. Cryptographic Key Management

   The cryptographic module must have a strong key management system that ensures the secure generation, storage, distribution, and destruction of cryptographic keys. The key management system must use strong cryptographic algorithms, such as Advanced Encryption Standard (AES), and have key backup, recovery, and destruction mechanisms.

3. Cryptographic Operations

   The cryptographic module must perform cryptographic operations securely and reliably. The module must use approved cryptographic algorithms and protocols, such as Transport Layer Security (TLS), Secure Sockets Layer (SSL), and IPsec. The module must also have error detection and correction mechanisms and handle cryptographic exceptions and failures.

4. Self-Tests and Tamper Evidence

   The cryptographic module must have self-tests and tamper-evidence mechanisms that detect and prevent unauthorized modifications, tampering, or substitution of the module’s hardware or software. The self-tests must be run periodically and must include checks for the integrity and authenticity of the module’s firmware, hardware, and software.

5. Design Assurance

   The cryptographic module must have a strong design assurance that ensures the module’s security requirements are met throughout the module’s lifecycle. An independent third-party evaluator must review and verify the module’s design. The module must be tested against a set of security requirements defined in the FIPS 140-3 standard. The design assurance also requires using secure coding practices, security testing, and security documentation.

6. Security Management

   The cryptographic module must have a strong security management system that includes policies, procedures, and controls for managing the module’s security risks. The security management system must include mechanisms for auditing, monitoring, reporting security events, and responding to security incidents and vulnerabilities.

   FIPS 140-3 level 3 provides strong protection against physical and logical attacks and requires a high level of key management, cryptographic operations, self-tests, tamper evidence, design assurance, and security management. The security requirements for level 3 are designed to protect sensitive information and maintain the integrity and availability of the cryptographic module.

FIPS 140-3 Level 4

Level 4 is the highest level of security defined in the standard and is intended for applications where the consequences of a security failure are severe. The following are the key security requirements for FIPS 140-3 Level 4

1. Physical Security

   The cryptographic module must be housed in a tamper-evident, ruggedized container designed to resist physical attacks, such as drilling, cutting, or punching. The container must also have sensors to detect unauthorized access and trigger alarms.

2. Cryptographic Key Management

   The module must have a strong, verifiable, and auditable key management system that ensures cryptographic keys’ secure generation, storage, distribution, and destruction. The module must also support key revocation and recovery.

3. User Authentication

   The module must have a robust and secure user authentication mechanism, such as biometric or smart card-based authentication, to ensure only authorized personnel can access the module.

4. Logical Security

   The module must have robust logical security mechanisms to prevent unauthorized access, tampering, or manipulation of the cryptographic module or its data. This includes secure boot, secure firmware updates, and secure communications protocols.

5. Environmental Controls

   The module must operate in various environmental conditions, such as extreme temperatures, humidity, and electromagnetic interference. The module must also be able to withstand power surges and disruptions.

6. Life Cycle Support

   The module must have a comprehensive life cycle support mechanism that includes regular security updates, vulnerability assessments, and secure disposal procedures

   Overall, FIPS 140-3 Level 4 defines the highest level of security for cryptographic modules, and it is intended for applications where the consequences of a security failure are severe. The standard defines strict security requirements in physical security, cryptographic key management, user authentication, logical security, environmental controls, and life cycle support to ensure the highest level of protection for sensitive data and systems.

Requirements of Cryptographic algorithms for each level of FIPS 140-3

The FIPS 140-3 standard outlines four security levels (Level 1-4), each specifying a different set of requirements for cryptographic algorithms

Here are the cryptographic algorithms required for each level

• Level 1

  This is the lowest level of security, requiring only basic encryption and key management functions. The cryptographic algorithms required for this level include AES (128-bit), Triple-DES (112-bit), and SHA-1.

• Level 2

  This level requires additional physical security features to protect against tampering or unauthorized access to the cryptographic module. The cryptographic algorithms required for this level include AES (128-bit and 192-bit), Triple-DES (168-bit), SHA-2 (256-bit), and HMAC.

• Level 3

  This level requires the highest level of physical security to prevent unauthorized access and protect against attacks. The cryptographic algorithms required for this level include AES (256-bit), RSA (2048-bit), ECDSA (224-bit), SHA-2 (384-bit), and HMAC (with keys of at least 128 bits).

• Level 4

  This is the highest level of security, requiring the most stringent physical and logical security features to protect against sophisticated attacks. The cryptographic algorithms required for this level include AES (256-bit), RSA (3072-bit), ECDSA (384-bit), SHA-3 (512-bit), and HMAC (with keys of at least 256 bits).

Conclusion

In summary, FIPS 140-3 has been approved and launched as the latest standard for the security evaluation of cryptographic modules. It covers a large spectrum of threats and vulnerabilities as it defines the security requirements starting from the initial design phase leading towards the final operational deployment of a cryptographic module. FIPS 140-3 requirements are primarily based on the two previously existing international standards ISO/IEC 19790:2012 “Security Requirements for Cryptographic Modules” and ISO 24759:2017 “Test Requirements for Cryptographic Modules”.

The FIPS 140-3 standard provides a framework for ensuring the security of cryptographic modules used in sensitive applications such as banking, healthcare, and government.

To know more about FIPS 140-3 read : Knowing the new FIPS 140-3

Read time: 5 minutes

What is an IoT device?

Before we jump into the issues and challenges, let’s get a better idea of IoT devices. Devices that have a sensor attached to it and transmit data from one object to another or to people with the help of the Internet is known as an IoT device.IoT devices are wireless sensors, software, actuators, and computer devices. An IoT device is any device that connects to a network to access the Internet, so Personal Computers, cellphones, speakers, and even some outlets are considered IoT devices. Today, even cars and airplanes use IoT devices, meaning if these devices are attacked by threat actors, then cars or airplanes could be hijacked or stolen. With such widespread use of IoT devices in place globally, authenticating and authorizing IoT devices within your organization’s network has become vital. Allowing unauthorized IoT devices onto your network can lead to threat actors leveraging these unauthorized devices to perform malware attacks within your organization.

Need for IoT Security

Security breaches in IoT devices can occur anytime, including manufacturing, network deployment, and software updates. These vulnerabilities provide entry points for hackers to introduce malware into the IoT device and corrupt it. In addition, because all the devices are connected to the Internet, for example: through Wi-Fi, a flaw in one device might compromise the entire network, leading other devices to malfunction.Some key requirements for IoT security are:

• Device security, such as device authentication through digital certificates and signatures.
• Data security, including device authentication and data confidentiality and integrity.
• To comply with regulatory requirements and requests to ensure that IoT devices meet the regulations set up by the industry within which they are used.

IoT Security Challenges:

1. Malware and Ransomware

   The number of malware and ransomware used to exploit IoT-connected devices continue to rise in the coming years as the number of connected devices grows. While classic ransomware uses encryption to lock users out of various devices and platforms entirely, hybridization of malware and ransomware strains is on the rise to integrate multiple attacks.

   The ransomware attacks could reduce or disable device functions while stealing user data. For example, a simple IP (Internet Protocol) camera can collect sensitive information from your house, office, etc.

2. Data Security and Privacy

   Data privacy and security are the most critical issues in today’s interconnected world. Large organizations use various IoT devices, such as smart TVs, IP cameras, speakers, lighting systems, printers, etc., to constantly capture, send, store, and process data. All the user data is often shared or even sold to numerous companies, violating privacy and data security rights and creating public distrust.

   Before storing and disassociating IoT data payloads from information that might be used to identify users personally, the organization needs to establish dedicated compliance and privacy guidelines that redact and anonymize sensitive data. Mobile, web, cloud apps, and other services used to access, manage, and process data associated with IoT devices should comply with these guidelines. Data that has been cached but is no longer needed should be safely disposed of. If the data is saved, complying with various legal and regulatory structures will be the most challenging part.

3. Brute Force Attacks

   According to government reports, manufacturers should avoid selling IoT devices with default credentials, as they use “admin” as a username and password. However, these are only guidelines at this point, and there are no legal penalties in place to force manufacturers to stop using this risky approach. In addition, almost all IoT devices are vulnerable to password hacking and brute-forcing because of weak credentials and login details.

   For the same reason, Mirai malware successfully detected vulnerable IoT devices and compromised them using default usernames and passwords.

4. Skill Gap

   Nowadays, organizations face a significant IoT skill gap that stops them from fully utilizing new prospects. As it is not always possible to hire a new team, setting up training programs is necessary. Adequate training workshops and hands-on activities should be set up to hack a specific smart gadget. The more knowledge your team members have in IoT, the more productive and secure your IoT will be.

5. Lack of Updates and Weak Update Mechanism

   IoT products are designed with connectivity and ease of use in mind. They may be secure when purchased, but they become vulnerable when hackers find new security flaws or vulnerabilities. In addition, IoT devices become vulnerable over time if they are not fixed with regular updates.

Top IoT Vulnerabilities

The Open Web Application Security Project (OWASP) has published the IoT vulnerabilities, an excellent resource for manufacturers and users alike.

1. Weak Password Protection

   Use of easily brute-forced, publicly available, or unchangeable credentials, including backdoors in firmware or client software that grants unauthorized access to deployed systems.

   Weak, guessable, default, and hardcoded credentials are the easiest way to hack and attack devices directly and launch further large-scale botnets and other malware.

   In 2018, California’s SB-327 IoT law passed to prohibit the use of default certificates. This law aims to solve the use of weak password vulnerabilities.

2. Insecure network services

   Unnecessary or unsafe network services that run on the devices, particularly those that are exposed to the internet, jeopardize the availability of confidentiality, integrity/authenticity of the information, and open the risk of unauthorized remote control of IoT devices.

   Unsecured networks make it easy for cybercriminals to exploit weaknesses in protocols and services that run on IoT devices. Once they have exploited the network, attackers can compromise confidential or sensitive data transmitted between the user’s device and the server. Unsecured networks are especially vulnerable to Man-in-the-Middle (MITM) attacks, which steal device credentials and authentication as part of broader cyberattacks.

3. Insecure Ecosystem Interfaces

   Insecure web, backend API, cloud, or mobile interfaces in the ecosystem outside of the device that allows compromise of the device or its related components. Common issues include a lack of authentication/authorization, lacking or weak encryption, and a lack of input and output filtering.

   Useful identification tools help the server distinguish legitimate devices from malicious users. Insecure ecosystem interfaces, such as application programming interfaces (APIs), web applications, and mobile devices, allow attackers to compromise devices. Organizations should implement authentication and authorization processes to authenticate users and protect their cloud and mobile interfaces.

4. Insecure or Outdated Components

   Use of deprecated or insecure software components/libraries that could allow the device to be compromised. This includes insecure customization of operating system platforms, and the use of third-party software or hardware components from a compromised supply chain.

   The IoT ecosystem can be compromised by code and software vulnerabilities as well as legacy systems. Using unsafe or outdated components, such as open source or third-party software, can create security vulnerabilities that expand an organization’s attack surface.

5. Lack of Proper Privacy Protection

   User’s personal information stored on the device or in the ecosystem that is used insecurely, improperly, or without permission.

   IoT devices often collect personal data that organizations must securely store and process in order to comply with various data privacy regulations. Failure to protect this data can result in fines, loss of reputation and loss of business. Failure to implement adequate security can lead to data leaks that jeopardize user privacy.

6. Insecure Default Settings

   Devices or systems shipped with insecure default settings or lack the ability to make the system more secure by restricting operators from modifying configurations.

   IoT devices, like personal devices, come with hard-coded, default settings that allow for easy configuration. However, these default settings are very insecure and vulnerable to attackers. Once compromised, hackers can exploit vulnerabilities in a device’s firmware and launch broader attacks aimed at businesses.

7. Lack of Physical Hardening

   Lack of physical hardening measures, allowing potential attackers to gain sensitive information that can help in a future remote attack or take local control of the device.

   The nature of IoT devices suggests that they are deployed in remote environments rather than in easy-to-manage, controlled scenarios. This makes it easy for attackers to target, disrupt, manipulate, or sabotage critical systems within an organization.

8. Lack of secure update mechanisms

   Lack of ability to securely update the device. This includes lack of firmware validation on device, lack of secure delivery (un-encrypted in transit), lack of anti-rollback mechanisms, and lack of notifications of security changes due to updates.

   Unauthorized firmware and software updates pose a great threat to launch attacks against IoT devices.

Conclusion

References

• www.networkworld.com/article/3332032/top-10-iot-vulnerabilities.html
• wiki.owasp.org/index.php/OWASP_Internet_of_Things_Project

Read time: 12 minutes

PKI, the abbreviation for Public Key Infrastructure, is a set of roles, procedures, and policies needed to create, distribute, manage, use, and revoke digital certificates and manage public-key encryption. PKI is used to confirm the identity of a user by providing ownership of a private key. It is a trusted service to verify that a sender or receiver of data is exactly who they claim to be.

PKI is built around components and procedures for managing the key pairs (public and private key pairs).

A typical PKI is made up of the following components:

1. Certificate Authority (CA): A trusted CA is the only entity in PKI that can issue trusted digital certificates. CA accepts requests for certificates and verifies the information provided by the applicants based on certificate management policy. CA will sign the certificates with its private key and issue them to the applicants if the information is legal.
2. Registration Authority (RA): RA is responsible for receiving certificate signing requests for the initial enrollment or renewal of certificates from users, servers, other applications. RA verifies the identity of an end-entity and forwards the request to a certificate authority (CA).
3. Public Key: Public key can be distributed widely and does not require secure storage. Its corresponding private key can only decrypt messages/Data encrypted by the public key.
4. Private Key: Private keys are used by the recipient to decrypt the message/data encrypted by its corresponding public key. This establishes the ownership of the private and public key pair, ensuring the message is only read by the approved parties
5. Root Certificate Authority (Root CA): A certificate is considered valid when a trusted Root CA sign it. A Root CA is entitled to verify a person’s identity and signs the root certificate that is distributed to a user.
6. Intermediate Certificate Authority: An Intermediate CA is also a trusted CA and is used as a chain between the root CA and the client certificate that the user enrolls for. Since the Root CA has signed and trusts the intermediate CA, certificates generated from the intermediate CA are also trusted.
7. Hardware security module: A Hardware Security Module isn’t a mandatory component of a PKI, but it improves the security of the PKI when implemented. This device protects and manages digital keys and serves as the groundwork for building a secure enterprise PKI infrastructure. The HSM manages the complete lifecycle of cryptographic keys, including creation, rotation, deletion, auditing, and support for APIs to integrate with various applications.

Now we have a fair idea about some of the PKI components, let’s talk about different PKI vendors and their best practices:

Microsoft PKI

Below is few best practices that are recommended to use Microsoft PKI effectively.

• Make a detailed plan of your PKI infrastructure before deployment.
• Avoid installing ADCS on a domain controller.
• Root CA should be standalone and offline.
• Do not issue certificates to end-entity from a Root CA.
• Enable auditing events for both Root and Issuing CA.
• Secure the Private key with HSM (FIPS 140-2 level 3)
• Install Enterprise CA only if your CA issues a certificate for devices or users.
• It is not recommended to use default certificate templates.
• CRL distribution point should be highly available.
• Publish Root CA CRL to Active directory.
• Hash Algorithm should be at least SHA-2 (SHA 256 bit).
• The end-entity certificate validity period should be a maximum of 2 years.

AWS Certificate Manager

Here are the top 10 best practices we identified for AWS Certificate Manager (ACM):

• ACM Certificate expiry check: Ensure removal of expired SSL/TLS certificates managed by ACM. This eliminates the risk of deploying an invalid SSL/TLS certificate in resources that trigger the front end. This might cause a loss of credibility for business as well.
• ACM Certificate validity check: Ensure requests that arrive during the SSL/TLS certificate issue or renewal process are validated regularly.
• Root Certificate Authority (CA) usage: It is always a best practice to minimize the use of Root CA. Amazon recommends creating a separate account for Root CA.
• Transport layer protection is vital to ensure security. It is recommended to use only TLS version 1.1 or above and not use SSL as it is no longer secure.
• Whenever you import certificates instead of ACM-issued certificates, ensure keys used to generate SSL/TLS certificate private keys have high key strength to avoid a data breach.
• Avoid using wildcard domain certificates. Instead, try to issue ACM single domain certificate for each domain and subdomain with its own private key.
• Allow usage of imported certificates only from authenticated and trusted partners of your organization in ACM. When wildcard certificates are imported into AWS Certificate Manager (ACM), security threat risk is high as the user might hold an unencrypted copy of the certificate’s private key.
• Recommended best practice is to always use a Fully Qualified Domain Name (FQDN) in SSL/TLS ACM certificates.
• To avoid misuse of generated certificates, perform frequent audits of AWS environment for trusted certificates and validate audit reports.
• Turn on AWS CloudTrail and CloudWatch alarms: CloudTrail logging helps track the history of AWS API calls and monitor AWS deployments. CloudTrail can be integrated with applications for performing automated logging and monitoring activities. Enabling the CloudWatch alarm feature helps in alerting through notifications when configured metrics breach.

AWS ACM Private CA (ACM PCA)

Below are the recommended best practices that can help you use AWS ACM PCA more effectively.

• AWS recommends documenting all your policies and practices for operating your CA, including CA hierarchy, architecture diagram, CA validation period policies, path length, etc.
  The CA structure and policies above can be captured in two documents known as Certificate Policy (CP) and Certificate Practice Statement (CPS). Refer to RFC 3647 for a framework for capturing important information about your CA operations.
• Root CA should, in general, only be used to issue a certificate for intermediate CAs.
• Creating a Root CA and Subordinate CA in two different AWS account is recommended best practice.
• The CA administrator role should be separate from users who need access only to issue end-entity certificates.
• Turn on CloudTrail logging before you create and start operating a private CA. With CloudTrail, you can retrieve a history of AWS API calls for your account to monitor your AWS deployments.
• It is a best practice to update the private key for your private CA periodically. You can update a key by importing a new CA certificate or replacing the private CA with a new CA.
• Delete the unused private CA permanently.
• ACM Private CA recommends using the Amazon S3 Block Public Access (BPA) feature on buckets that contain CRLs. This avoids unnecessarily exposing details of your private PKI to potential enemies. BPA is an S3 best practice and is enabled by default on new buckets.

Google Cloud Certificate Authority Services

This topic outlines some of the best practices that can help you use Certificate Authority Service more effectively.

• Role and access control: Individuals shouldn’t be assigned more than one role at any given time. Everyone holding an assigned role should be adequately briefed and trained on their responsibilities and security practices. If you want to assign a diverse set of permissions to an individual, it is recommended that you create a custom role using IAM.
• In most cases, it is recommended to use the Enterprise tier to create a certificate authority (CA) pool that issues certificates to other CAs and end-entities.
• While creating a CA pool, it is recommended to carefully consider the DevOps tier, as it does not support certificate revocation.
• Secure CA signing keys by leveraging Cloud HSM.
• Enable cloud audit logs to monitor access and use of Cloud HSM signing keys.
• It is recommended not to import an existing external CA with issued certificates into CA service.
• For a Root CA and Subordinate CA, it is recommended to use the most significant key size available for that algorithm family.
  • For RSA, the largest supported key size is 4096 bits.
  • For ECDSA, the largest supported key size is 384 bits.

  (For subordinate CAs with a shorter lifetime, it is sufficient to use smaller key sizes, such as 2048 bits for RSA or 256 bits for ECDSA.)

• It is recommended that the authors of the certificate template grant the CA service user role to the members in the organization who might use that certificate template.

Resources:

PcaWelcome

Certificate Authority Service

Microsoft PKI Services CP