Re: [Lwip] (on PUFs) Re: [IoT-DIR] Iotdir early review of draft-ietf-lwig-crypto-sensors-04

[Hannes Tschofenig <[e-mail]>]

Thanks for sharing your presentation, Rene.

Do you consider PUFs useful for IoT security? That’s a point I couldn’t really see from your slide deck.

Ciao
Hannes

From: Rene Struik [mailto:[e-mail]]
Sent: 07 November 2017 15:53
To: Samita Chakrabarti; Hannes Tschofenig
Cc: [e-mail]; [e-mail]; [e-mail]; [e-mail]
Subject: (on PUFs) Re: [Lwip] [IoT-DIR] Iotdir early review of draft-ietf-lwig-crypto-sensors-04

Hi Samita, Hannes, et al:

I gave a presentation on physically unclonable functions at NIST key management workshop 5 years ago (see [1]), which explains the main concepts. Please note that the "unique device property" is lost as soon as the PUF f or a deterministically-derived key K=H(f) is exposed (see Slide 6 -- hence, the color coding in "red", not to be exposed material). One needs to do extra tricks, i.e., design a challenge-response protocol that witnesses possession of f without revealing this, to use this for ongoing authentication. There are ways to do this, though.

Best regards, Rene

[1] R. Struik, “Secure Key Storage and True Random Number Generation,” presented at NIST-KMW: NIST Cryptographic Key Management Workshop, Gaithersburg, MD, September 10-11, 2012

Available from https://csrc.nist.gov/csrc/media/events/cryptographic-key-management-workshop-2012/documents/struik_nist_kmw_2012.pdf

On 11/6/2017 11:21 PM, Samita Chakrabarti wrote:
Hi Hannes,
I have not done comparison with other technologies. But as I mentioned that it exists. I like the fact it can generate unique 'intrinsic-id' based on the physical properties of the chip-set. If IOT-DIR folks like to know more, perhaps I can find out if there is a remote presentation and Q&A session possible from the Intrinsic-id folks sometime in the near future. ( Disclaimer: I have no particular interest other than knowing more about the feasibility  of application of that technology) I was thinking that this ID can be used in any mutual authentication protocols ( especially generating the private key). Do you have more information on them or think otherwise ?

Regards,
-Samita

On Mon, Nov 6, 2017 at 1:39 AM, Hannes Tschofenig <[e-mail]<mailto:[e-mail]>> wrote:
Hi Samita,

Do you think PUFs are useful authentication technologies for IoT devices?

Ciao
Hannes

-----Original Message-----
From: IoT-DIR [mailto:[e-mail]<mailto:[e-mail]>] On Behalf Of Samita Chakrabarti
Sent: 06 November 2017 10:37
To: [e-mail]<mailto:[e-mail]>
Cc: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Subject: [IoT-DIR] Iotdir early review of draft-ietf-lwig-crypto-sensors-04

Reviewer: Samita Chakrabarti
Review result: Ready with Nits

I have reviewed draft-ietf-lwig-crypto-sensors-04 document for  IOT-Directorate review. The following are my comments:

General : The document is easy reading and informative about current and previous work. It is ready to publish with minor changes based on review comments.

Other comments:
Introduction:
 It might be useful to discuss/clarify that multi-level security may be  important for IOT devices  all the way from 'bootstrapping and management' to  application security. That perhaps can include obtaining IP-addresses  securely, mutual authentication between server and devices , etc. ( see
 https://tools.ietf.org/html/draft-ietf-6lo-ap-nd-03) in those cases where each  device has an IP address.

Section 2:
Regarding problems of provisioning and management of networks for the IOT devices there may be additional issues – 1) different types of IOT devices and the lack of standards way to provision them as they might be talking different RF technologies and running L2 protocols only. 2) The iot nodes may be moving individually or collectively and change networks; identifying the movement of the iot nodes or identifying a particular node at any point of time uniquely requires an intrinsic identification which might be useful to set during bootstrapping of the node

Regarding related work – does it consider IETF IOT security work only? There have been some work and thought process going on regarding blockchain IOT security in the industry. Perhaps that is out-of-scope of this document, but I wanted to mention for authors’ considerations.

Section 5:
Authors of the document may also want to browse a SRAM PUF based technology which provides unique ID based authentication mechanism.
https://www.intrinsic-id.com/intrinsic-id-joins-wi-sun-alliance/

Section 9:
Does the example simulate any particular deployment model or research experiments ? It might be good to clarify that. Section 10 and 11: Looks like section 11 is closely related to section 10. Should they be combined together ?
Else some more text is needed in section 10 on design trade-offs.

Section 13:
Does this document recommend one layer of security to IOT devices ? There are different types of IOT devices – some of them are very tiny and some are more capable. Some definitely benefit for multi-level security  than single layer of security.  L2 security is generally recommended for for all IOT networks. Does data object protection only protect the  application data (payload)  or more ?

Thanks for the initiative in documenting the valuable work in IOT security implementation and crypto comparison. -Samita


_______________________________________________
IoT-DIR mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/iot-dir
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.





_______________________________________________

Lwip mailing list

[e-mail]<mailto:[e-mail]>

https://www.ietf.org/mailman/listinfo/lwip



--

email: [e-mail]<mailto:[e-mail]> | Skype: rstruik

cell: [phone] | US: [phone]

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.