WP_Term Object
(
    [term_id] => 87
    [name] => Intrinsic ID
    [slug] => intrinsic-id
    [term_group] => 0
    [term_taxonomy_id] => 87
    [taxonomy] => category
    [description] => 
    [parent] => 178
    [count] => 8
    [filter] => raw
    [cat_ID] => 87
    [category_count] => 8
    [category_description] => 
    [cat_name] => Intrinsic ID
    [category_nicename] => intrinsic-id
    [category_parent] => 178
)
            
Logo Intrinsic ID 594x100 1
WP_Term Object
(
    [term_id] => 87
    [name] => Intrinsic ID
    [slug] => intrinsic-id
    [term_group] => 0
    [term_taxonomy_id] => 87
    [taxonomy] => category
    [description] => 
    [parent] => 178
    [count] => 8
    [filter] => raw
    [cat_ID] => 87
    [category_count] => 8
    [category_description] => 
    [cat_name] => Intrinsic ID
    [category_nicename] => intrinsic-id
    [category_parent] => 178
)

Using PUFs for Random Number Generation

Using PUFs for Random Number Generation
by Kalar Rajendiran on 10-19-2021 at 6:00 am

In our daily lives, few of us if any, would want randomness to play any role. We look for predictability in order to plan our lives. But reality is that random numbers have been playing a role in our lives for a long time. The more conspicuous use cases of random numbers are with key fobs, and nowadays mobile phones. And then there are a whole lot of behind the scene use cases that leverage random numbers for security purposes. As such, generating true random numbers is a topic of ongoing interest within the field of math and computer science.

There have been instances where faulty random number generators caused security and authentication issues. Nonces are random numbers used in authentication protocols. The term nonce as used here carries the meaning “number only used once.” Not to be mixed up with the slang meaning of this word as used in some parts of the world. There have been incidents in the past where a nonce was generated more than once due to weak random number generators. Lot of progress has been made since then and such lapses don’t happen as much. Nonetheless, due to the explosive growth in internet linked devices, we face increasing levels of threats to device and information security.

It is in this context that the recent announcement by Intrinsic ID of a NIST-Certified  Software Random Number Generator (RNG) is of interest. You can read the press release “Intrinsic ID Announces NIST-Certified Software Random Number Generator (Zign RNG) for IoT Devices” here. It points to a report that has identified critical vulnerabilities in billions of IoT devices due to poor random number generation mechanisms. The announcement states that their Zign RNG ensures a source of true randomness addressing the critical security flaw in IoT devices. And that the Zign RNG is the industry’s first and only embedded RNG software solution.

One of the coveted features of any solution is its ability to be a drop-in replacement without requiring any hardware change to already designed and manufactured devices. Particularly those that are already deployed in the field. Zign RNG claims to be such a solution, a cryptographically secure NIST-certified RNG that can even be retrofitted on already-deployed devices.

The curiosity in all of us would want to know how is Intrinsic ID able to achieve the above claimed solution. The answer can be found in the webinar that Intrinsic ID recently hosted on PUF Café. The webinar was titled “Using PUFs for Random Number Generation” and was delivered by Dr. Nicolas Moro. He is an embedded security systems engineer at Intrinsic ID. This blog is a synthesis of the salient points from watching that webinar.

 

Attractiveness of SRAM PUF for RNG

PUFs can be seen as the fingerprint of a device. In the case of SRAM PUFs – like most PUFs – this fingerprint comes with noise. In the normal use case of a PUF, algorithms are used to remove this noise. On the other hand, random number generators need a non-deterministic source of entropy. And the noise from an SRAM PUF fingerprint can be used for that purpose. Given that we know that every IoT device already contains SRAM, it makes sense to use the noise from the SRAM PUF as a source of entropy to extract a true random seed. Not only that, SRAM has additional benefits as seen in the Figure below.

Nice Properties of SRAM for RNGs

 

Harvesting the Entropy for RNG

The non-deterministic part of the start-up values of the SRAM is used as a source of entropy. This entropy is used as a seed for a Deterministic Random Bit Generator (DRBG).

The output of an SRAM PUF is slightly different each time. Random and repeatable but not 100% repeatable. For PUF purposes, this noise is eliminated through error correction techniques. But for random number generation, the data derived from the noise needs to pass some statistical tests. Thus, some processing is needed to create the seed for the DRBG.

The SRAM PUF source has enough noise in it to be able to generate the right number of bits of entropy for desired levels of security. For example, Intrinsic ID has established through its experiments that only 2 kilobytes of uninitialized SRAM are required to get 192 bits of entropy.

 

PUF-based RNG

The National Institute of Standards and Technology (NIST) has established clear set of specifications for secure random number generators. Refer to Figure below for the specification for each topic relating to this subject matter.

NIST SP800 90 A B C

 

The entropy derived from the PUF is fed as the seed to a DRBG to yield random data. A maximum of 2^19 bits can be received per call to the DRBG. The maximum number of calls that can be made before the reseed counter runs out is 2^48. That is more than 281 trillion calls. Everyone would agree that is large number. In the event the counter does run out, a power reboot of the device would start it off with new entropy to reseed the DRBG.

For implementing a 128-bit security level, a total of 192 bits of entropy is needed from the SRAM PUF. As noted earlier, this is achievable with just 2kilobytes of uninitialized SRAM. Once the seeding is one, this 2kilobytes of memory is available for other uses and purposes within the application.

 

NIST Certification

NIST has qualified third party certification labs to conduct validation programs. The Cryptographic Algorithm Validation Program (CAVP) is for certifying the RNG algorithm. The Cryptographic Module Validation Program (CMVP) is for certifying the system/module that implements and uses the algorithm. In addition to a GetEntropy function, a RNG solution must include a GetNoise and a HealthTest function. These are requirements by NIST and must be made available through an API at the top level. Refer to Figure below.

3 API Functions

 

The GetEntropy function is of course the one that returns the seed for the DRBG.

The GetNoise function is for use by a third-party certification lab during their evaluation to check the entropy source behavior against the specification.

The HealthTest function is used during run time to protect against any catastrophic failures. For example, if during run time, all zeroes are received as input for seeding DRBG, it will abort and raise a flag.

 

Summary

Zign RNG software can be implemented at any stage of a device’s lifecycle, even after a device is already deployed in the field. It has passed all standard NIST randomness tests and is a NIST/FIPS-compliant software solution. It addresses the issue of hardware RNG peripherals used in IoT devices running out of entropy and leaving the devices vulnerable.

Intrinsic ID’s Zign RNG is available now and is applicable to anyone making IoT devices or chips for IoT. More details about the product can be accessed here and a product brief can be downloaded from here.

You can access the full press release of the Zign RNG product announcement here.

And you can watch and listen to the webinar by registering here at PUF Café.

 

 

Share this post via:

Comments

There are no comments yet.

You must register or log in to view/post comments.