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
<[email protected] <mailto:[email protected]>> wrote:
Hi Samita,
Do you think PUFs are useful authentication technologies for IoT
devices?
Ciao
Hannes
-----Original Message-----
From: IoT-DIR [mailto:[email protected]
<mailto:[email protected]>] On Behalf Of Samita Chakrabarti
Sent: 06 November 2017 10:37
To: [email protected] <mailto:[email protected]>
Cc: [email protected] <mailto:[email protected]>; [email protected]
<mailto:[email protected]>;
[email protected]
<mailto:[email protected]>
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
<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/
<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
[email protected] <mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/iot-dir
<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
[email protected]
https://www.ietf.org/mailman/listinfo/lwip
--
email: [email protected] | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363
_______________________________________________
Lwip mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lwip
