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
>
>
>
> 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 <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
>
> <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
> <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
> <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
>
> <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
> <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
> <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
> <http://ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=6680199>
>
> [10]https://www.esat.kuleuven.be/cosic/thesis/2011/mai/CloningTheUnclonable_en.pdf
>
> <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
> <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
> <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
> <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
>
> <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
>
> <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
>
> <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/
> <https://datatracker.ietf.org/doc/rfc8446/>
> [21] The New Illustrated TLS Connection https://tls13.ulfheim.net/
> <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
