Hi,
Thank you for your insight. It will help me give direction to my work. I
need to do my homework better. Will look from public/private pair angle
instead of challenge/response.
Looking forward to similar guidance in future also,
Thanks and Regards,
Sankalp Bagaria.
On Mon 18 Feb, 2019, 10:44 AM Paul Lambert, <p...@nymbus.net> wrote:
> Sankalp,
>
> The schema below is the wrong way to use PUF technology for IoT device
> authentication.
>
> PUF is already being used in many fielded IoT systems. You simply use the
> device unique PUF secret to create a public/private key pair. The public
> key is then extracted and used to authentic the device. This enables
> tracking and identification of the device through its full life-cycle.
> Early observation of the device-unique public key mitigates a variety of
> supply chain attacks. The extracted public key may be certified by a X.509
> CA. The PUF derived identity may then be used directly in a TLS protocol
> exchange.
>
> Early assignment of public key certificate to a device enables strong
> protection of the device during manufacturing. The PUF device keys may be
> used as part of the boot process to enable per-device protection of
> sensitive firmware or other cryptographic secrets.
>
> PUF may be instantiated as HW or SW. Your scheme mentions " signal path
> can affect the delay in the propagation of a signal” … the seems to imply a
> HW based implementation (perhaps a Butterfly PUF). A simpler implementation
> would be to use SRAM PUF where the entropy in uninitialized SRAM is used to
> generate the device unique secrets. SRAM based PUF can be readily
> integrated into existing MCU devices.
>
> The simplest application of PUF in IoT uses a device unique symmetric
> secret key to serve as a key to encrypt sensitive data in unprotected NV
> memory. This is basically a low-level key vault that provides
> confidential and non-non-maleable secure device storage. This is a very
> attractive alternative to OTP memory that s more expensive and of limited
> size.
>
> PUF is just one way for a device to obtain unique secrets (symmetric or
> asymmetric). It has been standard practice to “inject’ secrets during
> manufacturing. Injection requires more trust in the key distribution and
> provisioning process than approaches that generate keys on device and never
> expose these secrets.
>
> Long-lived device unique public keys and certificates that provide
> protection through the full manufacturing life-cycle are an interesting
> topic area … Challenge/response PUF protocols are not useful or
> interesting for standardization.
>
> Paul
>
>
>
>
>
> On Feb 15, 2019, at 9:06 PM, Sankalp Bagaria <sankalp.n...@gmail.com>
> wrote:
>
> *Hello,*
>
> *Please take a look at this and advise if it is a good idea and whether it
> should be pursued.*
>
> *Thanks,*
>
> *Sankalp Bagaria.*
>
>
> *ITDA - IoT Device Authentication*
>
> *Abstract: *We propose that the server is authenticated using X509
> certificate in a TLS 1.3 like protocol. The Server sends 32-byte Challenge.
> Client replies by sending 32-byte Response. Thus the client is
> authenticated. In the transfer of the application data, the client may send
> more challenge-response pairs as encrypted data for updating database of
> server. Client doesn’t store challenge/response or key or certificate. Both
> the server and the client can initiate the handshake.
>
> *Background*
>
> Traditionally, there are two ways to authenticate a device: a centralised
> CA issuing certificates and block-chain. Both require costly infrastructure
> and can’t be used to authenticate IoT devices, which are of low cost. While
> block-chain provides non-repudiation, transactions are distributed all over
> the net. X.509 certificates are costlier than many sensors.
>
> Another option is Physically Uncloneable Functions (PUF). Because of the
> random variations taking place during the manufacturing process of an IC,
> no two ICs are same. For instance, the impurities present in the IC can
> affect the doping level of an IC and thus cause signal paths to change.
> These slight variations in the signal path can affect the delay in the
> propagation of a signal which can be measured and used to identify the
> chip. This uniqueness of an IC can be used to authenticate the device in
> which the IC has been placed.
>
>
> *PUF: The Concept*
>
> *[image: P02.JPG]*
>
> Figure 1: PUF – Multiplexer pair’s output delay compared by arbiter
> (latch)
>
> When the same input is fed to two adjacent multiplexers, depending on the
> impurities and other manufacturing variations, the delay observed in the
> propagation of the signal to one multiplexer output is different from that
> of the other. This delay can be compared using an arbiter (latch) and the
> final output generated. Several pairs of multiplexers can be operated in
> parallel or a series of inputs can be fed to the same pair of multiplexer..
> Thus, a set of output bits is generated that is specific to the chip.
>
> The set of input bits is called challenge and the set of output bits is
> called response. A challenge/ response pair is specific to the chip. The
> experimental results [4] show that two identical PUF circuits on two
> different chips have different outputs for the same input with a
> probability of 23% (inter-chip variation). On the other hand, multiple
> measurements on the same chip are different only with 0.7% probability. As
> both the multiplexers on the chip are in the same environment, the PUF
> output is mostly independent of the environmental variations.
>
> *Limitations of current PUF implementation*
>
> To prevent the replay attack, a challenge – response pair can be used only
> once. To enable this, a large set of challenge – response pairs have to be
> generated at the installation time and pre-stored in the server. A server
> can have many devices connected to it. So, it has to have a large database
> and computational power.
>
> Moreover, this setting is inflexible. There is the problem of distributing
> challenge/ response pairs from client to server. When the PUF is
> commissioned, challenge/ response pairs have to be generated at the chip
> and taken to server. If the server exhausts its supply of
> challenge-response pairs, it cannot be easily renewed.
>
>
> *Our solution*
>
> Thus in our solution, we combine the best of X.509 certificate and PUF.
> Certificate is well-tested technology and provides flexible way to
> distribute keys. PUF is relatively new but allows a cheap solution to IoT
> authentication problem. Moreover, there is no need to store keys or
> certificates at the client-side.
>
> *The Protocol Combining TLS 1.3 and Challenge/ Response of PUF*
>
> *The Protocol with Client Starting the Connection*
>
> Client starts by generating its key_share and sends it to Server for
> normal TLS connection. It also sends acceptable ciphersuites. Server
> generates its own private key and joins with client's keyshare to get the
> shared secret. It takes this share-secret and combines with hash of the
> handshake till that point to generate handshake keys. The connection is
> encrypted from this point on.
>
>
> The server sends its X.509 certificate, CertificateVerify and
> PUF_Challenge. The client also generates the handshake key from its private
> key and server's public key. It then verifies the certificate, generates
> PUF_Response. It encrypts the PUF_Response and sends to the Server. Server
> verifies it, generates Application Key from Handshake_key and hash of the
> Handshake.
>
>
> The Client also generates the Application Keys similarly. The Application
> data flows in encrypted form. To start, Server requires only one pair of
> Challenge/ Response. When server's stock is depleting it may request more
> challenge/ response pairs in application data. Client may generate more
> pairs and send them as encrypted data to server which stores in its
> database for future use. Client should delete its copy permanently so that
> an adversary can't recover it by attacking hardware.
>
> Client
>
> Server
>
> ClientHello
>
> + key_share -------->
>
>
>
> ServerHello
>
>
> + key_share
>
>
> {Encrypted
> Extensions}
>
>
> {Certificate}
>
> {CertificateVerify}
>
> <---------
> {PUF_Challenge}
>
> PUF_Response ---------->
>
>
>
> {Finished}
>
> <---------
> [Application Data]
>
> {Finished}
>
> [Application Data} <-------->
> [Application Data]
>
>
>
>
>
> *The Protocol with Server Starting the Connection*
>
> The Server may also initiate connection by sending Server Hello. Client
> replies by sending Client Hello with its key_share and list of acceptable
> ciphersuites. When server receives Client_Hello, it proceeds just like the
> above use-case.
>
>
> Client
>
> Server
>
> <-----------
> ServerHello
>
>
> ClientHello
>
> + key_share ---------->
>
>
> key_share
>
>
> {Encrypted Extensions}
>
>
> {Certificate}
>
>
> {CertificateVerify}
>
>
> <-----------
> {PUF_Challenge}
>
>
> {PUF_Response} ----------à
>
>
>
> {Finished}
>
>
> <---------
> [Application Data]
>
> {Finished}
>
>
> [Application Data} <-------->
> [Application Data]
>
>
> The Client doesn't store the Keys, Challenge/ Response or the Certificate..
> Each session is a unit in itself. Everything is calculated on the fly. This
> may create latency but this minimizes the resource requirement. It is
> required that when the IoT device is commissioned, atleast one Challenge/
> Response pair is generated and stored in Server Database. Whenever the
> challenge - response pairs are depleting, on Server's request, the Client
> can generate them and send to the Server as encrypted data. After sending,
> the Client deletes its copy of Challenge / Response.
>
> *Future Work:*
> 1) Complete the development of protocol described above by including
> use cases like when does the Handshake fails and Challenge/ Response has to
> be re-negotiated; when Resumption happens etc.
> 2) Adapt other IoT protocols like QUIC, DTLS to work with PUF.
>
> 3) Validate the solution with PUF-enabled Evaluation kits.
>
> References –
>
> [1] RFC 5280 - Internet X.509 Public Key Infrastructure Certificate and
> Certificate Revocation List (CRL) Profile.
> https://tools.ietf.org/html/rfc5280
>
> [2] 50 Billion IoT devices will be connected by 2020 – Post – The Things
> Network.
> https://www.thethingsnetwork.org/community/thessaloniki/post/50-billion-iot-devices-will-be-connected-by-2020
>
> [3] https://en.wikipedia.org/wiki/Physical_unclonable_function
>
> [4] G. E. Suh and S. Devadas, “Physical unclonable functions for device
> authentication and secret key generation,” in Proceedings of the 44th
> annual Design Automation Conference, San Diego, CA, Jun. 2007, pp.9–14
> https://people.csail.mit.edu/devadas/pubs/puf-dac07.pdf
>
> [5]
> http://people.csail.mit.edu/rudolph/Teaching/Lectures/Security/Lecture-Security-PUFs-2.pdf
>
> [5] Blaise Gassend, Dwaine Clarke, Marten van Dijk and Srinivas Devadas.
> Silicon Physical Random Functions. Proceedings of the Computer and
> Communications Security Conference, November 2002
> http://csg.csail..mit.edu/pubs/memos/Memo-456/memo-456.pdf
> <http://csg.csail.mit.edu/pubs/memos/Memo-456/memo-456.pdf>
>
> [6] C. Herder, L. Ren, M. van Dijk, M-D. Yu, and S. Devadas, "Trapdoor
> Computational Fuzzy Extractors and Cryptographically-Secure Physical
> Unclonable Functions", IEEE Transactions on Dependable and Secure
> Computing, January 2017
> https://people.csail.mit.edu/devadas/pubs/trapdoor.pdf
>
> [7] Helfmeier, Clemens; Nedospasov, Dmitry; Boit, Christian; Seifert,
> Jean-Pierre (2013). Cloning Physically Unclonable Functions
> <http://users.sec.t-labs.tu-berlin.de/~nedos/host2013.pdf> (PDF). IEEE
> Hardware Oriented Security and Trust (IEEE HOST 2013). June 2–3, 2013
> Austin, TX, USA
>
> http://ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=6581556
>
> [8] Merchan Jorge Guajardo
> <https://www.google.com/search?tbo=p&tbm=pts&hl=en&q=ininventor:%22Merchan+Jorge+Guajardo%22>,
> Shankaran S. Kumar
> <https://www.google.com/search?tbo=p&tbm=pts&hl=en&q=ininventor:%22Shankaran+S.+Kumar%22>,
> Pim T. Tuyls
> <https://www.google.com/search?tbo=p&tbm=pts&hl=en&q=ininventor:%22Pim+T.+Tuyls%22>,
> Geert J. Schrijen
> <https://www.google.com/search?tbo=p&tbm=pts&hl=en&q=ininventor:%22Geert+J.+Schrijen%22>
> Identification of devices using physically unclonable functions
> WO 2009024913 A2
>
> [9] M. Fyrbiak, C. Kison, W. Adi. Construction of Software-Based Digital
> Physical Clone Resistant Functions. 2013 Fourth International Conference on
> Emerging Security Technologies
> http://ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=6680199
>
> [10]
> https://www.esat.kuleuven.be/cosic/thesis/2011/mai/CloningTheUnclonable_en.pdf
>
> [11] Srinivas Devadas, Edward Suh, Sid Paral, Richard Sowell, Tom Ziola,
> Vivek Khandelwal . Design and Implementation of PUF-Based “Unclonable” RFID
> ICs for Anti-Counterfeiting and Security Applications.
> http://verayo.com/pdf/2008_Verayo_IEEE_RFID_Paper.pdf
>
> [12] Rishab Nithyanand, John Solis. A Theoretical Analysis: Physical
> Unclonable Functions and The Software Protection Problem. SANDIA REPORT
> SAND2011-6673. Printed in 2011.
> http://prod.sandia.gov/techlib/access-control.cgi/2011/116673.pdf
> <http://prod.sandia..gov/techlib/access-control.cgi/2011/116673.pdf>
>
> [13] Shahriar B. Shokouhi. Cooperative Artificial Immune System And
> Recurrent Neural Network Error Correction Scheme For Generating Robust
> Hardware Key. International Journal Of Electrical, Electronics And Data
> Communication. ISSN: 2320-2084. Volume-4, Issue-5,May 2016
> http://www.iraj.in/journal/journal_file/journal_pdf/1-254-146502604154-59...pdf
> <http://www.iraj.in/journal/journal_file/journal_pdf/1-254-146502604154-59.pdf>
>
> [15] D. Lim. Extracting secret keys from integrated circuits. Master’s
> thesis, Massachusetts Institute of Technology, May 2004.
> http://csg.csail.mit.edu/pubs/memos/Memo-476/DaihyunLimThesis.pdf
>
> [16] Ulrich Ruhrmair. On the Formal Foundations of PUFs and Related
> Primitives. October 19, 2016.
> https://depositonce.tu-berlin.de/bitstream/11303/5994/4/ruehrmair_ulrich.pdf
>
> [17]
> https://patents.google.com/patent/US20090083833A1/en?q=PUF&q=physically+unclonable+function&oq=PUF+physically+unclonable+function
>
> [18]
> https://patents.google.com/patent/US8290150B2/en?q=authentication&q=PUF&q=physically+unclonable+function&oq=authentication+PUF+physically+unclonable+function
>
> [19]
> https://patents.google.com/patent/US20140279532A1/en?q=authentication&q=PUF&q=physically+unclonable+function&oq=authentication+PUF+physically+unclonable+function
>
> [20] RFC 8446 – The Transport Layer Security (TLS) Protocol Version 1.3
> https://datatracker.ietf.org/doc/rfc8446/
>
> [21] The New Illustrated TLS Connection https://tls13.ulfheim.net/
> [22] Internet-draft: State-of-the-Art and Challenges for the
> Internet of Things Security draft-irtf-t2trg-iot-seccons-16
>
> [23] Internet-draft: TLS 1.3 Extension for Certificate-based
> Authentication with an External Pre-Shared Key.
> draft-housley-tls-tls13-cert-with-extern-psk-03
> _______________________________________________
> T2TRG mailing list
> t2...@irtf.org
> https://www.irtf.org/mailman/listinfo/t2trg
>
>
>
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
