Vincent: Why did you implement this using an SRAM PUF and not with a different kind of PUF?
Nicolas: Here the advantage of an SRAM PUF is that you don't need hardware modifications. So, if a device has an SRAM PUF, you can directly use the output of the uninitialized memory and no other hardware is needed.
Vincent: So you're saying that you can do this fully in software? Could you not do it with other types of PUFs?
Nicolas: You could, provided that you have access to them and that this hardware is present. And on top of that, you also need your other PUF to actually have noise, because for PUFs the typical good property is the deterministic aspect. Normally noise is considered something we want to get rid of and here we actually leverage the noise. So, to use another PUF you first need to have access to it. And second, you need that it produces enough noise for using it as a source of randomness. In a way using SRAM PUF, or such a design, is almost like having a driver that actually gives you access to some hardware you already have. And that gives you functionality that you were not using yet from the hardware you already have.
Vincent: How did you calculate that you need 192 bits of entropy? Is it somewhere in literature or did Intrinsic ID come up with that? Where is that number coming from.
Nicolas: You need 192 bits, because this is a NIST requirement for seeding a DRBG with a security level of 128 bits. You need to provide 128 bits of entropy and 64 bits for a nonce as well. In our particular SRAM PUF design, you use only the entropy only once and the nonce as well. So adding these two numbers together is 192 bits of entropy that you need.
Vincent: So you need 192 random bits out of the SRAM to seed the DRBG?
Nicolas: Yes. To seed the DRBG at the security level of 128 bits, because you can also have DRBGs at other security levels and then of course the entropy you would need becomes different.
Vincent: And I assume that this is described in the NIST standards that you mentioned in the slides, right?
Nicolas: Yes.
Vincent: And how did you estimate the amount of entropy you could get from a specific SRAM?
Nicolas: Intrinsic ID worked on that. First, we used a model of SRAM to determine an average entropy contribution per bit. And then we verified that this model works by performing measurements on actual devices from multiple technologies. And finally, based on the model and the experiments, we used a very conservative hypothesis. I think we based the figure on something like 2% of noise, which is particularly conservative compared to what we've observed on actual SRAMs from any kind of technology. Based on all this work we could estimate the size of the SRAM we needed to deliver at least 192 bits of entropy, in our case 2KB.
Vincent: There are a lot of questions coming in about where people can find more information about. So, please have a look at the NIST standards that Nicolas mentioned in the slides. You will find a lot of information about what a random number generator needs to uphold in terms of standards and requirements.
Nicolas: The NIST documents are very good. You can look at the part on the entropy source as a specification, because your entropy source needs to meet those requirements. And the DRBG needs to be implemented as it is. There's not much room for your own design there. You cannot make it up yourself.
Vincent: How do you separate or locate deterministic bits from the random bits of the SRAM output?
Nicolas: When you have 2KB of uninitialized SRAM, you will have some bits that always initialize as zero, some always as one, and some sometimes as zero and sometimes as one. Normally when we use a PUF, we will actually consider the bits that flip as noise, and we will use error correction to get rid of them. What we are doing now for the RNG is that we are redistributing the bits out of the 2KB of first run and we build a digest of that. This is an SRAM image, where all bits depend on a certain number of other bits and in which we can guarantee that there will be a certain number of the bits that actually flip. So that means that all the bits that we feed into the DRBG contribute a little to the total noise.
Vincent: You said bits are only uninitialized at startup. Is there anything specific that you need in order to get the SRAM when it's uninitialized?
Nicolas: It depends on how much access you have to the SRAM, so to the hardware directly. If you are, for example, running on a bare metal system or a low-level system such as Free RTOS, all you need is a section of memory, which is not initialized. When you are running a more advanced OS that might require a little more advanced manipulation. But basically what you need is at some point access to a memory area, which is not initialized to any arbitrary value.
Vincent: Do you recommend having a separate area within the SRAM that is always used for this purpose?
Nicolas: It should at least always be used at the beginning for this purpose. After you've initialized the DRBG, that memory can be used for anything else.
Vincent: Okay. So it only needs to be reserved at powerup. So now there's questions about whether you use any masking techniques to find the noisy bits.
Nicolas: We don't, because we don't find noisy bits. We don't, for example, in the device run a campaign of measurements to find out that bit number three is noisy and bit number five is noisy. What we do is we have an algorithm that, that mixes those bits in a way that we can generate a guarantee that all the output depends on noise. But there's no bit selection.
Vincent: You said something about the stochastic model. And that is something that NIST then tests for, right?
Nicolas: Not NIST themselves, but a lab.
Vincent: But they do that based on these NIST standards. Correct?
Nicolas: Yes.
