5
$\begingroup$

I have read in many places that SRAM PUF is considered a weak PUF, since it generates a single response (based on the value of all RAM cells upon power-up).

Why can't I use just a limited number of bytes from the RAM space in order to create a CRP? For example if I have a 64kB RAM, I can divide it into 256 sections, each section 256B long, obtaining 256 CRP's? (Assuming that all the RAM cells are stable and can be used for PUF...)

|improve this question
$\endgroup$
  • $\begingroup$ Could you give at least some of your sources? $\endgroup$ – kelalaka Dec 4 '18 at 11:51
  • $\begingroup$ @Paul Uszak CRP stands for "challenge–response pairs" $\endgroup$ – Yaron Dec 4 '18 at 15:06
  • $\begingroup$ @kelalaka please look at ieeexplore.ieee.org/document/6823677?denied= $\endgroup$ – Yaron Dec 4 '18 at 15:08
0
$\begingroup$

Strong SRAM PUFs exist, and this is the way a strong PUF device is designed. The challenge (for response) is the access pattern. SRAM tends to be contiguous, so partitioning into CRPs can be easy if the dependability of the silicon is good. This may not always be the case as it is die /family dependent. So you can segment your 64KB into say two units. The "weak" nomenclature may be a throwback to days of smaller RAM sizes, and making an allowance for the following...

You cannot say "Assuming that all the RAM cells are stable and can be used for PUF". RAM cells are definitely not stable, and repeatable behaviour is fundamental to the PUF concept. Otherwise the SRAM forms an entropy source for random number generators. This variability may be as high as 1 bit /byte on some INFINEON TRICOREs (source). You are balancing predictable states against unpredictable ones.

Your idea of 256 bytes may be too low for a sufficient number of reliable bits to be extracted. Error correction is an absolute must and cannot be overlooked otherwise the whole PUF concept fails. SHA256ing blocks of 32 bytes will not work. Quantum, voltage, temporal and thermal effects will ensure that the hash will not produce consistent output. Memory-based Combination PUFs for Device Authentication in Embedded Systems shows this effect ameliorated via error correction using 16 such blocks. There is a white paper here that needs 1KB of cells to get 256 reliable bits. That's a 32:1 ratio.

So it might work if you pick /screen your silicon carefully, but it's hard to say without actually trying it. Die variability is too high to speculate on 256 bytes, but the concept is valid.

PS. The number of challenges can be the permutation of CRP cells, not just a single response from each individual cell. That's illustrated in Open-Source Software-Based SRAM-PUF for Secure Data and Key Storage Using Off-The-Shelf SRAM. There they create a possible $10^{12,626}$ pairs, using a Arduino Mega 2560 and COTS SRAM.

|improve this answer
$\endgroup$
  • $\begingroup$ Thanks for your response. If I understand you correctly, the reason that SRAM is considered "weak" is simply that is might not have enough stable cells to produce many CRP's. Am I correct? $\endgroup$ – Yaron Dec 5 '18 at 8:52
  • $\begingroup$ @Yaron The exact definition is elusive, but it does seem to be related to the stability of the cells wrt their environment. It means serious error correction is necessary with redundancy of the order of 32:1 for SRAM. That said, strong optical PUFs (with rock solid cells) still required some post processing. Gabor transforms are required in optical PUFs, as the laser twinkles through the optic medium. So yes, strength $\propto$ stability seems true. $\endgroup$ – Paul Uszak Dec 5 '18 at 10:35
1
$\begingroup$

In the article, "weak PUFs" are for key storage, and "strong PUFs" are for authentication, but both are PUFs. It's just a function of how you use them. A 32-bit PUF is just a random 32-bit number. What makes a weak PUF strong is pairing it with an HMAC circuit, or something for a challenge response.

A few notes on the article: the assumption that EEPROMs are expensive in both power and area is not really true. It's difficult to find any IC without some sort method to hold the serial number, and if it is not EEPROMs, it's e-fuses. Everything in IoT has some sort of method to program memory. To that end, if I have EEPROM infrastructure already, PUFs cost more regarding area, and both circuits have the same issues when I de-cap something and put my probes on it. The circuit discussion was rather weak and some of the implementation in the overview won't work on aggressive nodes.

|improve this answer
$\endgroup$
  • $\begingroup$ The difference between "strong PUF" and "weak PUF" is the number of possible challenge–response pairs. This is why "strong PUF" can be used directly for authentication, while "weak PUF" are used for cryptographic key generation. $\endgroup$ – Yaron Dec 5 '18 at 8:41
  • $\begingroup$ @Yaron In the simplest sense, a PUF is a hardware construct. The HMAC, etc, that allows for complex functions is unrelated to the PUF, as I could just replace the PUF with eFuses or EEPROM. Have no idea why the authors picked that notation. I would have given them a hard time in the reviews if I were the editor; however, I'm more hardware than cryptography. $\endgroup$ – b degnan Dec 5 '18 at 13:50
  • 1
    $\begingroup$ @PaulUszak 32nm and smaller basically. There are still some planar processes, but most are FinFETs. PUFs depend on inherent variations and these are so pronounced that things get weird. You used to be able to change W/L of transistors, but now I cannot do that so I just have cells. on 14nm SOI, I found that all of my PUFs were stuck at 1 (as I knew they would be) just due to the nature of variation of devices. There's a few fixes, but I never implemented them due to space as I could just use the two-way shot noise in the channel to generate random numbers. 3nm is just a disaster. $\endgroup$ – b degnan Dec 5 '18 at 16:01
  • $\begingroup$ Hmm. So comparing my links to your experience, I get that you're operating with much higher technology. Some of my links are for old DIP chips like 62256 SRAMs. And you're finding that as nodes shrink, their reliability as PUFs decreases? Akin to DRAM errors getting more prolific as density increases? $\endgroup$ – Paul Uszak Dec 5 '18 at 16:24
  • 1
    $\begingroup$ @PaulUszak I just have one sample point on 14nm SOI. BTW, as an example of how things change, I use DRAM for cache instead of SRAM because of process variation on 14nm and lower. SRAM has more transistors, so I have more problem with it with yield than I did with DRAM. There's not really a correct answer when it comes to hardware; it's just all different answers for different conditions. $\endgroup$ – b degnan Dec 5 '18 at 21:06

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.