[TLS] ITDA - IoT Device Authentication

[Sankalp Bagaria <[e-mail]>]

*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

[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

[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

[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