SRAM PUF

RE: SRAM PUF

ovrebekk — Tue, 06 Feb 2018 12:09:43 GMT

Hi Peter

I know the random generation algorithm we use is FIPS compliant, so that should give the 'freaks' some indication of its quality 😉

If storing a key in flash is an option you could also consider storing a unique, private key in flash as part of your production programming stage. This might slow down the production process slightly, but would at least give you the capability to add any sort of key you like into the flash.

A sophisticated hacker can read out the data from the flash by decapping the chip, but if the keys are unique to each device then this should not be a large issue.

Best regards
Torbjørn

RE: SRAM PUF

ovrebekk — Tue, 06 Feb 2018 12:00:51 GMT

Hi Peter

Thanks for the explanation. I wasn't aware of this interesting property of SRAM, but I forwarded it to our security experts, and they were familiar with it.

I believe the main problem with this technology is that it is quite expensive to use, since there is a license associated with it. There is nothing stopping you or anyone else from licensing this technology and using it with our device, but then you would have to pay their license.

We don't have any plans to make this technology an integrated part of our product.

For future roadmaps you should talk to our sales people (send me a PM if you need to know who your sales representative is).

Best regards
Torbjørn

RE: SRAM PUF

peterz — Tue, 06 Feb 2018 00:47:00 GMT

thanks a lot for the pointer. The manual does not say a lot about identity root and encryption root. Those security freaks are paranoid (that's their job) and they will ask me where those bits come from and what's the quality of the random number generator and how I can trust Nordic not to store those numbers somewhere and so on :-(

In the forum I find a topic "identity root and encryption root": ...The IR and ER fields are random values used to generate some of the device information and keys used by the SoftDevice for BLE. These are not very useful for the common user, but could be used as a static identifier for a specific chip.

OK, but I can't present this answer to my security guys. Before I can bring many thousands of "secure" IoT devices in the field I need a bit more than this page 46 in the manual.

RE: SRAM PUF

Turbo J — Mon, 05 Feb 2018 21:11:37 GMT

Not very useful for NRF5x, since there are many random bits already present in FICR.

RE: SRAM PUF

peterz — Mon, 05 Feb 2018 20:48:23 GMT

> If the technology is SRAM based, how does it handle key storage when you don't have power?

the trick is: it doesn't! When the SRAM is powered up, fluctuations within the chip cause the individual RAM cells to fall in a preferred state. The pattern is unique because you can't control production down to this level. And when the power is off, you can't detect any stored information from the outside!

As the nRF52832 gives me the possibility to switch off a block of 4K SRAM and to switch it on whenever I need to retrieve this unique fingerprint of the chip I get a lot of unique, reproduceable information almost for free.

RE: SRAM PUF

ovrebekk — Mon, 05 Feb 2018 12:02:53 GMT

Hi Peter

Being in IoT we have a strong focus on security, and the subject of secure key storage is one that pops up regularly.

I don't think we have looked into this particular technology, but I can forward it to the designers to make sure they are aware of it.

If the technology is SRAM based, how does it handle key storage when you don't have power?

Best regards
Torbjørn