Q: Why is using a PUF better than storing a randomly generated device unique value in some kind of NVM?
A: There are a couple of differences:
- secrets are derived and not stored: when the device is turned off, no sensitive data or key resides in any non-volatile memory.
- In the case of a PUF, copying all non-volatile information does not result in a cloned device
- The PUF provides an independent and trusted source of entropy.
- The PUF solution works without requiring any secure NVM
- The PUF solution does not require a separate TRNG
Q: My security is already good enough. Why do I need PUFs?
A: Keys stored in on-chip non-volatile memory are susceptible to offline physical attacks. All non-volatile memories use some kind of physical state change to store key bits (e.g. blowing away material, changing amorphous to polycrystalline state, storing charge), which can be detected with special equipment when the chip is opened.
Traditional key injection mechanisms can lead to security breaches as the cryptographic root keys need to be known outside the chip and require very careful handling. There are several cases known where mistakes in handling keys have led to leaking sensitive key information.
Q: Do I still need the other security features, as if I am storing key in NVM?
A: Other security features are still recommended. Once a PUf has reconstructed the cryptographic key, it needs to be assured that it is securely transferred to the crypto logic and cannot easily be attacked. One needs to assure for example that the debugger cannot be used by an attacker to access internal registers. Furthermore the cryptographic modules that use the keys still need to be protected. The use of a PUF reduces the security requirements for the NVM. No secure NVM is needed anymore. Only a non-sensitive activation code is stored in NVM.
Q: What is an "Activation Code"?
A: An Activation Code is generated such that the same cryptographic key can be reconstructed from subsequent PUF readings. In scientific literature it is often referred to as "Helper Data".
Q: What is "Enrollment" of a PUF and when should it take place?
A: The enrollment step establishes the key based on an initial read of the PUF. The creation of this root key is typically performed by either the chip manufacturer or the OEM. The PUF enrollment process is an integral part of determining the identity of a device. The most benefit is gained when the device-unique identity is established near the end of the manufacturing process.
The best security is provided when the PUF initialization is in the boot ROM or in locked flash. The locking of the portions of the flash is normally part of the MCU configuration performed by a test system on the manufacturing floor. This locking process can improve other important security steps, like disabling of JTAG, scanning or debug ports.
When the enrollment step is being executed, depends on the use case. It can be executed at silicon manufacturing, provided that there is a place to store the device-unique activation code (e.g. in some memory on-chip or in a server database). However, it is also possible to let the chip establish its root keys much later in the production chain. For example, the enrollment can be done at the contract manufacturing stage where a chip is connected to other components and application software is loaded.
Q: Do PUFs using multiple enrollments leak information? Should Enrollment be limited to only-once?
A: It has been proven theoretically that multiple enrollments do not leak information (additional) information about the PUF, see for example https://sites.uclouvain.be/sitb2016/Proceedings_SITB2016.pdf (p. 118). This is however under the assumption that there is no bias in the SRAM startup behavior. In practice there may be a small biasing in the startup values (probability of starting up as a one is not exactly 50%). Therefore it is good practice to limit enrollment to only one time, OR use active debiasing schemes (VNM). Note that active debiasing comes at the cost of using more (e.g. at least ~2x as much) SRAM." target="true"> https://sites.uclouvain.be/sitb2016/Proceedings_SITB2016.pdf (p. 118). This is however under the assumption that there is no bias in the PUF behavior. In practice there may be a small biasing in the startup values (probability of starting up as a one is not exactly 50%). Therefore it is good practice to limit enrollment to only one time, OR use active debiasing schemes (VNM). Note that active debiasing comes at the cost of using more (e.g. at least ~2x as much) PUF data.
