• State Not Answered
  • +1 person also asked this people also asked this
  • Replies 6 replies
  • Subscribers 75 subscribers
  • Views 3486 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 200153
Options
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

SRAM PUF

peterz

Hi

I just stumbled about SRAM PUF which could solve me a huge problem in IoT provisioning certificates.

https://www.intrinsic-id.com/products/spartan/ sounds very promising. But I see there are patents involved.

Does Nordic have any plans to provide this technology?

As I understand this technology it could be very easily applied to nRF5 products and it would give us extremely well protected certificates in a very cost effective way.

best regards

Peter Zankl

Parents
  • 0

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

  • 0 in reply to Turbo J

    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.

  • 0 in reply to peterz

    Hi Peter

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

    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

Reply
  • 0 in reply to peterz

    Hi Peter

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

    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

Children
No Data
Related
Terms of service