Subject: [T2TRG] ITDA - IoT Device Authentication

From: Sankalp Bagaria <[email-masked]>
Date: Sat, 16 Feb 2019 10:36:53 +0530

*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

[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

---

From: Peter Gutmann <[email-masked]>
Date: Sun, 17 Feb 2019 01:00:42 +0000

Sankalp Bagaria <[email-masked]> writes:

>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.

Something very similar to this already exists in the form of CHAP/MSCHAP over
PEAP/EAP-TLS/EAP-TTLS.  It's supported by every Radius server and vast numbers
(probably billions) of clients.  To compete against this huge installed base, any
new proposal would have to be pretty spectacular...

Peter.

---

From: Sankalp Bagaria <[email-masked]>
Date: Sun, 17 Feb 2019 12:33:40 +0530

Hello Mr Peter,

Thank you for your reply. It was my first attempt to develop a protocol.
Hence, the mistake. I hope to do better work next time.

Although PUF is not my idea, I would like to know if it is a good idea. I
thought it was the future of IoT world. Should we invest time, money and
energy in it ? Please advise.

Thanks and Regards,
Sankalp Bagaria.

---

From: "Salz, Rich" <[email-masked]>
Date: Sun, 17 Feb 2019 18:50:20 +0000

I would also be concerned about adding a "new" scheme that easily functions as an oracle.

On 2/16/19, 8:01 PM, "Peter Gutmann" <[email-masked]> wrote:

    
    
    Peter.
    
    _______________________________________________
    TLS mailing list
    [email-masked]
    https://www.ietf.org/mailman/listinfo/tls

---

From: Sankalp Bagaria <[email-masked]>
Date: Mon, 18 Feb 2019 07:07:53 +0530

Hi,

Servers are usually more secure and can store challenge/ response pairs for
all clients it connects with in Oracle.

Remote IoT devices can be attacked physically and keys retrieved from them.
To prevent this, costly and complex tamper proof cryptographic circuitry is
used.

PUF provides a cheaper alternative to complex and expensive cryptographic
circuitry. As keys need not be stored at the IoT device. When PUF receives
a challenge from server, it calculates response and sends it to server.

Thanks and Regards,
Sankalp Bagaria..

---

From: "Salz, Rich" <[email-masked]>
Date: Mon, 18 Feb 2019 01:45:36 +0000

Do you know what I mean by an oracle?

  *   PUF provides a cheaper alternative to complex and expensive cryptographic circuitry. As keys need not be stored at the IoT device. When PUF receives a challenge from server, it calculates response and sends it to server.

---

From: Sankalp Bagaria <[email-masked]>
Date: Mon, 18 Feb 2019 08:29:54 +0530

Hi,

I looked in net for Oracle and found the following limitation. PUF depends
on physical variations of chip at time of manufacturing and after
processing, should function as a better Oracle than any other algorithm.
Limitations (as per wikipedia)Edit
<https://en.m.wikipedia.org/w/index.php?title=Random_oracle&action=edit&section=2>

According to the Church–Turing thesis
<https://en.m.wikipedia.org/wiki/Church%E2%80%93Turing_thesis>, no function
computable by a finite algorithm can implement a true random oracle (which
by definition requires an infinite description because it has infinitely
many possible inputs, and its outputs are all independent from each other
and need to be individually specified by any description).

Thanks and Regards,

Sankalp Bagaria.

On Mon 18 Feb, 2019, 7:15 AM Salz, Rich, <[email-masked]> wrote:

>    - PUF provides a cheaper alternative to complex and expensive
>    cryptographic circuitry. As keys need not be stored at the IoT device. When
>    PUF receives a challenge from server, it calculates response and sends it
>    to server.
>
>

---

From: "Salz, Rich" <[email-masked]>
Date: Mon, 18 Feb 2019 03:29:45 +0000

If a client will sign any challenge presented by any server, it open up a big hole.  An attacker can present a challenge that a (future) valid server will present, and the attacker, having the answer, can then act as the device to the server. For example, the attacker can intercept the server/client communication, present the challenge on its own, and then act as the client.

---

From: Sankalp Bagaria <[email-masked]>
Date: Mon, 18 Feb 2019 09:27:54 +0530

Hi,

Please see the comments inline.

On Mon 18 Feb, 2019, 8:59 AM Salz, Rich, <[email-masked]> wrote:

> If a client will sign any challenge presented by any server, it open up a
> big hole.  An attacker can present a challenge that a (future) valid server
> will present, and the attacker, having the answer, can then act as the
> device to the server.
>
Replay attack is avoided by using a challenge/ response pair only once.
2^32 combinations possible for 32 byte challenge.

Server is authenticated by its certificate. An attacker will not be able to
do so.

> For example, the attacker can intercept the server/client communication,
> present the challenge on its own, and then act as the client.
>

 MiTM attack is not possible since server is authenticated by certificate.
> An attacker will not have the private key of the server.
>
Thanks and Regards,
Sankalp Bagaria..

---

From: Paul Lambert <[email-masked]>
Date: Sun, 17 Feb 2019 21:14:45 -0800

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

---

From: Eliot Lear <[email-masked]>
Date: Mon, 18 Feb 2019 09:21:00 +0100

Just to add- this is what the plethora of BRSKI drafts are attempting to address in 6tisch, ANIMA, and EMU.  If there is to be a new mechanism, I encourage that it be listed on the GitHub page at https://github.com/iot-onboarding/catalog <https://github.com/iot-onboarding/catalog>.  Both the README.md file and the Onboard-Table file should be updated.  PRs welcome.

> On 18 Feb 2019, at 04:29, Salz, Rich <[email-masked]> wrote:
> 
> [email-masked] <mailto:[email-masked]>
> https://www.irtf.org/mailman/listinfo/t2trg <https://www.irtf.org/mailman/listinfo/t2trg>

---

From: Sankalp Bagaria <[email-masked]>
Date: Mon, 18 Feb 2019 16:57:48 +0530

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, <[email-masked]> wrote:

> 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
>
>
>
>
>
> 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.
>
>
> 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.
> http://csg.csail..mit.edu/pubs/memos/Memo-456/memo-456.pdf
> <http://csg.csail.mit.edu/pubs/memos/Memo-456/memo-456.pdf>
>
> <http://prod.sandia..gov/techlib/access-control.cgi/2011/116673.pdf>
>
> 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>
>
>       [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.

---

From: Sankalp Bagaria <[email-masked]>
Date: Mon, 18 Feb 2019 17:03:23 +0530

Hi,

My apologies if I appeared a little aggressive in pursuing my incorrect
idea. I have to learn a lot.

Looking forward to your guidance in future also,
Thanks and Regards,
Sankalp Bagaria.

On Mon 18 Feb, 2019, 1:51 PM Eliot Lear, <[email-masked]> wrote:

> Just to add- this is what the plethora of BRSKI drafts are attempting to
> address in 6tisch, ANIMA, and EMU.  If there is to be a new mechanism, I
> encourage that it be listed on the GitHub page at
> https://github.com/iot-onboarding/catalog.  Both the README.md file and
> the Onboard-Table file should be updated.  PRs welcome.
>
> device to the server. For example, the attacker can intercept the
> server/client communication, present the challenge on its own, and then act
> as the client.
>

---

From: "Salz, Rich" <[email-masked]>
Date: Mon, 18 Feb 2019 13:30:18 +0000

*   Replay attack is avoided by using a challenge/ response pair only once. 2^32 combinations possible for 32 byte challenge.

How is that enforced?

  *   Server is authenticated by its certificate. An attacker will not be able to do so.

Did I miss where you explained this?