Federal Information Processing Standards (FIPS) compliance requirements are crucial for embedded devices and systems designed for government agencies or industries such as healthcare, finance, and defense that are highly regulated. Embedded devices running Linux operating system extensively use OpenSSL library to implement cryptographic security. This blog post explores OpenSSL FIPS compliance and its role in ensuring that embedded software/firmware aligns with FIPS compliance requirements, specifically focusing on FIPS 140-2 and FIPS 140-3 standards.

Understanding FIPS and ISO/IEC 19790

FIPS are U.S. government standards that define the security requirements for cryptographic modules. These standards are developed and maintained by National Institute of Standards and Technology (NIST). NIST is a federal agency under the U.S. Department of Commerce, and its objective is to promote innovation and industrial competitiveness by advancing measurement science, standards, and technology. OpenSSL FIPS Compliance is a direct response to these standards, helping ensure that cryptographic components meet stringent government regulations.

The objective of FIPS standards is to ensure protection of sensitive and confidential data. FIPS compliance is a legal requirement for organizations and contractors working with U.S. government agencies or operating in highly regulated industries such as healthcare, finance, and defense. FIPS 140 is the specific standard that governs cryptographic modules, ensuring they meet strict requirements for the protection of sensitive information.

NIST validates cryptographic modules against FIPS standards via its Cryptographic Module Validation Program (CMVP). It guarantees integrity, confidentiality, and authenticity of the data. These standards are recognized worldwide for their reliability in cryptographic security.

IEC 19790 is an international standard that addresses a wide range of security concerns, and it specifies security requirements for cryptography modules. It defines four increasing levels of security addressing key areas such as physical security, software/firmware security, key management, and operational environment. It allows a product to be certified at a level appropriate for its targeted application and sensitivity of data it processes.

FIPS 140-3 aligns closely with IEC 19790 because it was derived from IEC 19790, ensuring its global acceptance.

OpenSSL in Embedded Systems

Devices running embedded Linux heavily rely on OpenSSL to implement edge security and secure communication. Open-source availability, strong developer community, and easy to use interfaces make OpenSSL an ideal choice to implement security in embedded as well as server-side software. OpenSSL FIPS Compliance is particularly important in these use cases, ensuring that even resource-constrained devices can meet regulatory standards without compromising performance.

OpenSSL is widely used across industries and applications, including IoT, automotive systems, security, industrial automation, consumer electronics, healthcare, and defense. For example, smart home devices such as cameras, thermostats, and access control systems use OpenSSL to establish secure connections with cloud servers, ensuring your personal data remains protected during transmission.

OpenSSL plays a critical role in securing office infrastructures and government systems, where the stakes for data security and privacy are far higher than in home environments. In government setups the importance of OpenSSL is even more pronounced, considering classified information and sensitive data to be processed and protected. OpenSSL ensures that the additional regulatory compliance applicable in such setups is also taken care of.

OpenSSL Versions and FIPS Compliance

OpenSSL supports various cryptography algorithms, though not all of them are standardized and approved by NIST. Historically, different OpenSSL versions have provided different mechanisms to implement NIST-approved cryptography algorithms for FIPS compliance.

OpenSSL 1.0.2

• FIPS Support: Via FIPS Object Module 2.0, validated and compliant with FIPS 140-2.
• Application usage
  • FOM 2.0 APIs are not standalone sets of functions; rather a subset of APIs with defined entry points that application code can use to manage the FIPS module.
  • FIPS_mode_set() – To put OpenSSL library in the FIPS mode, perform integrity checks, and self-tests required by FIPS 140-2.
  • FIPS_selftest() – To explicitly run self-tests.
• Limitations: End-of-life since December 2019. No updates or community support.

OpenSSL 1.1.1

• No FIPS Module: Incompatibility with FIPS Object Module 2.0 due to significant change in internal architecture of OpenSSL 1.1.x.
• Fallback: Projects needing FIPS compliance were forced to stay with OpenSSL 1.0.2 until OpenSSL 3.0 was released.

OpenSSL 3.0

• FIPS Support: Via FIPS Provider Module, a separate dynamically loadable module that contains only FIPS-approved algorithms.
• Architecture Highlights:
  • Provider framework: Cryptography operations access through providers.
  • Specific, small set of APIs used to manage and configure the FIPS Provider.
  • New architecture provides high-level, algorithm-agnostic interface through EVP APIs.
  • New architecture to allow applications to perform cryptography operations without the need to know which provider is being used. For example, EVP_DigestInit_ex() initializes a digest context, but it doesn’t care if the SHA256 algorithm is coming from the default provider or the FIPS provider.
  • Library context: To enable multiple configurations (FIPS and non-FIPS) within the same application.
  • New APIs to load and unload providers programmatically i.e.,OSSL_PROVIDER_load() and OSSL_PROVIDER_unload().
• Compliance: Compliant with FIPS 140-3 that is aligned with ISO/IEC 19790.

Migrating to OpenSSL 3.0

1. Analyze the usage of cryptography algorithms and OpenSSL APIs.
   • Replace and migrate to FIPS supported cryptography algorithms.
   • Migrate from legacy APIs such as SHA256_Init, AES_set_encrypt_key to modern EVP counterparts like EVP_DigestInit_ex, EVP_CipherInit_ex.
2. Load FIPS provider module

   

   The following lines in OpenSSL configuration file enable the FIPS provider module.

   

3. Implement the library contexts to isolate the code requiring FIPS supported functionality vs non-FIPS supported functionality.

   

4. Perform self-tests and validate cryptography correctness and module integrity.
5. Compliance documentation by maintaining logs of configuration, test results, and module versions.

Conclusion

As cyber-attacks rise and security regulations get stricter, FIPS compliance is no longer a choice, it’s a must for embedded systems in sensitive environments. OpenSSL 3.0 is a big step forward in cryptography. It is more modular, flexible, and fully FIPS 140-3 compliant. As embedded systems expand into new areas, developers must prioritize moving to OpenSSL 3.0. This ensures an alignment with regulatory standards, reliable security, and long-term support. Migrating to OpenSSL 3.0 is not only about meeting standards, but also about protecting embedded systems from future threats and building trust in every interaction.

Strategic Focus

Future emphasis should be on FIPS compliance requirements for OpenSSL and its dependent implementation within the product. Also, it is essential to incorporate these FIPS compliance activities across the embedded system development life cycle such as requirement creation and secure by design practices to development, testing, and monitoring. Adapting to these practices will help products align with regulatory standards and more importantly mitigate cryptography security risk associated with OpenSSL.