Re: [TLS] [T2TRG] ITDA - IoT Device Authentication

[Paul Lambert <[e-mail]>]

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 <[e-mail]> 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
> [e-mail]
> https://www.irtf.org/mailman/listinfo/t2trg