2
$\begingroup$

Does SRAM-PUF require the microcontroller/system to be (1) on the same silicon piece and (2) to prevent access from dumping the SRAM in an uninitialized state in order to be tamper-proof?

In SRAM PUF, there are two types of challenges that can be applied to the system. The challenge can be either the whole SRAM memory or specific addresses.

source: *Setyawan Sajim, A. (2018). Open-Source Software-Based SRAM-PUF for Secure Data and Key Storage Using Off-The-Shelf SRAM.

Does it mean that the response is only derived from the content of the SRAM in an uninitialized state? How can this be tamper-proof? As an attacker, I could just dump the content of the SRAM in an uninitialized state.

Improve this question
$\endgroup$
4
  • $\begingroup$ Then you could also dump the secret after the PUF outputs it, no ? You have to make assumptions. $\endgroup$
    – Ruggero
    Oct 26, 2018 at 10:06
  • $\begingroup$ I think that in any PUF, you are supposed not to disclose the challenges before you use them. If you use strong PUFs, this should be impossible to try all the possible challenges in advance. Strong PUFs can be recognized by possessing a tremendous number of CRPs which prevent an adversary to read all possible CRPs even if he has open access to the challenge-response interface. $\endgroup$
    – DurandA
    Oct 26, 2018 at 12:23
  • $\begingroup$ what I meant is the same argument that fgrieu explained in his answer. The goal of the PUF is to protect against reverse-enginnering, FW dumping, cloning. $\endgroup$
    – Ruggero
    Oct 29, 2018 at 9:39
  • $\begingroup$ Do you mean PUFs in general or SRAM-PUF specifically? Due to the tremendous number of CRPs, I think that strong PUFs can additionally be used for secure authentication. $\endgroup$
    – DurandA
    Oct 31, 2018 at 14:39

1 Answer 1

Reset to default
1
$\begingroup$

Does it mean that the response is only derived from the content of the SRAM in an uninitialized state?

For the raw RAM-PUF response, that's my understanding. How that is turned into a stable value (in practice identical across power-up cycles) is more complex, and requires long-term storage like conventional Flash for associated error-correction data (which at least in principle needs not be secret).

How can this be tamper-proof?

My understanding is that the implicit attack model here includes: the adversary has no physical access to the RAM, and can't remotely read it in its power-up state. Perhaps the early stages of boot read the initial state of the RAM, use that, then zero that RAM.

Update: as noted in comment, if we assume that getting access to the content of the RAM-PUF at power-up is impossible without de-caping the IC, and such de-caping alters the RAM-PUF beyond the error-correction capability of the associated error-correction data, then the RAM-PUF can become a tamper-resistant vault for a secret key. I have no information about if the above assumptions hold in practice (and welcome input on that).

Another attack model commonly considered for RAM-PUF is that the attacker only attempts to make a silicon-level exact copy, or steal ICs on the fabrication line (perhaps rejects). That adversary is unable to write in Flash the associated error-correction data which, together with the unique content of the RAM-PUF, makes the device operative. In this model, reading the initial content of the RAM won't help the adversary bound to not redesign the IC.

Improve this answer
$\endgroup$
4
  • $\begingroup$ From a security standpoint, this seems to have zero advantage over a random number in ROM or eFuse provided by the manufacturer. $\endgroup$
    – DurandA
    Oct 26, 2018 at 12:29
  • 1
    $\begingroup$ @DurandA eFuse's cost a layer plus 2 sec to blow them. I generally just use FLASH, but that again is post processing. Both of these methods cost USD 0.02, in the cases that I've experienced. The PUF allows for it to just "work" out of fab. $\endgroup$
    – b degnan
    Oct 29, 2018 at 17:47
  • 1
    $\begingroup$ @DurandA: from a silicon manufacturer's perspective, preventing silicon-level exact copies and ICs diverted from the production line from working has some level of usefulness, even if that can't prevent a more elaborate attack. Like one removing the need of the RAM-PUF altogether, by way of a minor redesign (e.g. of the boot-control logic/code). $\endgroup$
    – fgrieu ♦
    Oct 29, 2018 at 18:02
  • 1
    $\begingroup$ Can it prevent more advanced attacks if further processing of the SRAM-PUF is performed on the same silicon? E.g., a secret is derived from the PUF and used for HMAC. Would it prevent extraction of the secret as decapping the IC would alter the PUF? $\endgroup$
    – DurandA
    Oct 30, 2018 at 10:03

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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