Internet of Things Catch here

Achieving FIPS 140-2 Validation for Modules implementing TCG DICE Architecture

By Avi Avanindra (Infi neon), Sergey Ostrikov (Infi neon), Travis Spann (Aegisolve)


he emerging, Internet of Things (IoT) segment is driving the development of billions of Internet connected products which demand a high level of security to be viable in the market. In an increasingly connected world, it is imperative that the privacy and security of connected devices over the network is maintained. As a result, security is playing a greater role in product design - more and more products are demanding security validations. FIPS 140-2, a US government security validation certifi cate, is a must have for devices sold to US government and for safety and security critical private industries. The validation provides assurance that the device meets the specifi ed level of security and once validated, these products also receive premium pricing. With the growth in autonomous driving and related safety concerns there is increasing demand to have FIPS 140-2 validation for devices used in autonomous vehicles. National Highway Traffi c Safety Administration (NHTSA) has proposed that all Vehicle to Vehicle (V2V) equipment be “hardened” (FIPS-140-2, level 3) against intrusion by entities attempting to steal its security credentials.

The FIPS 140-2 standard provides four increasing, qualitative levels of security: Level 1, Level 2, Level 3, and Level 4. The differences between the assessment levels relates to the sophistication of authentication methods, cryptographic key management, tamper resistance mechanisms and the associated cryptographic module design assurance. These levels are intended to cover a wide range of potential applications and environments in which cryptographic modules may be employed. The Cryptographic Module Validation Program (CMVP) validates cryptographic modules to Federal Information Processing Standard FIPS PUB 140-2. Once successfully validated, the module is listed on the CMVP website.

22 October 2020

Trusted Computing Group (TCG) has defi ned the Device Identifi er Composition Engine (DICE) and Implicit Identity Based Device Attestation architecture to enable enhanced security and privacy for connected devices with minimal cost, both in hardware and software. Device attestation or certifi cation is needed to know the cryptographic state of a system to be able to trust it. The TCG DICE emerges as a very useful standard to ensure that a system uses authentic hardware and fi rmware. Industries worldwide are taking advantage of TCG defi ned device identifi cation and attestation architecture to design secure systems. The FIPS 140-2 requirements for generation and management of cryptographic keys, including the use of random numbers, and the TCG DICE and Attestation architecture present a different set of requirements. Meeting these requirements simultaneously is not trivial; requirements must be carefully aligned to ensure compliance to both FIPS 140-2 and TCG DICE standards. An effective reconciliation enables the DICE Attestation architecture to be successfully validated by CMVP for critical applications.

Apparent misalignment between FIPS 140-2 and TCG DICE standards It is intuitive that secure systems depend on secret cryptographic keys. Therefore, the generation of these keys is of utmost importance. Herein lie the apparent differences in the requirements between TCG DICE/Device Attestation and FIPS 140-2: A) FIPS 140-2 requires that the generated cryptographic keys be random numbers – they must rely on the output of a SP800- 90A r1 Deterministic Random Bit Generator (DRBG) which uses as input a source of randomness to seed the DRBG. See Figure below. TCG DICE architecture specifi es that the keys be generated using a 1-way function.

Components in Electronics

Asymmetric key pair generation as per FIPS 140-2 B) As per NIST SP800-90Ar1: “The seed that is used to initialize one instantiation of a DRBG shall not be intentionally used to reseed the same instantiation or used as the seed for another DRBG instantiation”. DICE generates keys (Alias Keys) that serve as the identity of the system. These keys are based on measurements of the system FW. The identity represented by this key needs to be unchanged as long as the system FW does not change (i.e. identical Alias keys need to be re-generated upon every boot, a fundamental concept in DICE).

C) DICE architecture relies on a unique device secret (UDS), a large secret number unique to every device that is manufactured, and bound to the specifi c hardware and

unchangeable by fi rmware. For FIPS requirements, this is considered a critical security parameter that must be zeroizable (i.e. the UDS can be destroyed).

Achieving both

Compliance with both FIPS-140-2 and TCG DICE is possible. The requirements listed above must be carefully aligned to achieve FIPS 140-2 validation for TCG DICE based designs. FIPS 140-2 defi ned DRBG must be used as the 1-way function in TCG DICE based architecture. Aligning the requirements in item B above is more involved. The fi gure below shows such an implementation proposed by Infi neon that satisfi es both FIPS 140-2 and TCG DICE. A detailed description of the different requirements and a compliant solution to meet both the standards can be found here.

Page 1  |  Page 2  |  Page 3  |  Page 4  |  Page 5  |  Page 6  |  Page 7  |  Page 8  |  Page 9  |  Page 10  |  Page 11  |  Page 12  |  Page 13  |  Page 14  |  Page 15  |  Page 16  |  Page 17  |  Page 18  |  Page 19  |  Page 20  |  Page 21  |  Page 22  |  Page 23  |  Page 24  |  Page 25  |  Page 26  |  Page 27  |  Page 28  |  Page 29  |  Page 30  |  Page 31  |  Page 32  |  Page 33  |  Page 34  |  Page 35  |  Page 36  |  Page 37  |  Page 38  |  Page 39  |  Page 40  |  Page 41  |  Page 42  |  Page 43  |  Page 44  |  Page 45  |  Page 46  |  Page 47  |  Page 48  |  Page 49  |  Page 50  |  Page 51  |  Page 52  |  Page 53  |  Page 54