Return-Path: X-Original-To: t2trg@ietfa.amsl.com Delivered-To: t2trg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBF91130EC1 for ; Sun, 17 Feb 2019 21:14:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, LOTS_OF_MONEY=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nymbus-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VGjVelpxliCi for ; Sun, 17 Feb 2019 21:14:11 -0800 (PST) Received: from mail-pf1-x441.google.com (mail-pf1-x441.google.com [IPv6:2607:f8b0:4864:20::441]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E852C1200B3 for ; Sun, 17 Feb 2019 21:14:10 -0800 (PST) Received: by mail-pf1-x441.google.com with SMTP id h1so7927521pfo.7 for ; Sun, 17 Feb 2019 21:14:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nymbus-net.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=y/zFAhhTKankbPbki4tEjBSqd31uZJa8cUaCOer61xc=; b=zUKsg7USOhtCBUYz2VmOZquDYmsb/+7TDi0vuGpcYZ9tFefkTu0EDAB0M4hBPG4rIN wP3Gf/CMJYO0PUF/K+8hVEPE3N+QV+b14MlQwjz9sY+rIS6mfWP4JXrAVMrynvjSsXts OosuRBE3AHW+QI2uFgv2ALrZUGs5WQhN/hW8OzinubbNwCRwQTzlNzHXs7ukxCK4rYbI 1jzpv4gZ9yG7NPBIC4w6DicPIaJDNMy1BGLE0Kbi5wGG866irG8NdCHWmyEswllHzIRP VGUBAqJ15UcB6Xy86WOKlAkmT/knSpgwXhYNwWpgBxKU0gWz0mjCxJKaEWSPQpo/mwRu aAcQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=y/zFAhhTKankbPbki4tEjBSqd31uZJa8cUaCOer61xc=; b=GQpvt7gtmxUjjsU9kI9HEXIv5sUUrGQgCGiU6FAdPARSjHJJ+ozD6Be3MmyLqUXikk K85YLh8joBLXQfLmbsHUCGPmBDa57xs7VCYFhybbtL00PfUcOMHDDjhjxAXnLbwhv0Gn CG6/ygUwlhDKQ8HCZpg8OXSnoMBWkpF0FA9owhk6SvMht3UU8tqmU0ETGWUFjPIuqUeD CBIj4DCE2wBtgsFfewNw4RoBWjip/T0akW4zLEaY3Ud2WbW412aPi1CQN7NzLIU0yrNg TqcTSe/dRE9QnslAUwE2XVCVI3ih4cf9WyVPIrq1jUnMrZQ4AnL+uNzPmaAl66wbzQBe 3+yw== X-Gm-Message-State: AHQUAubxJMAuXa6NIFRImPBhtpRP1MrH1LGeN/5W7XyxPXieH8kXCM09 Z0KMGiGVemx28Tc9S1C45sEwDg== X-Google-Smtp-Source: AHgI3Ia8uJYIQwihKKboWMIh/exP8gERnIrCA5Pr3e5Q00rfX4GZy8l/ED7ojm4lmumxkawqkk+7/A== X-Received: by 2002:a63:4346:: with SMTP id q67mr16725345pga.92.1550466850249; Sun, 17 Feb 2019 21:14:10 -0800 (PST) Received: from [192.168.1.97] (172-125-76-95.lightspeed.sntcca.sbcglobal.net. [172.125.76.95]) by smtp.gmail.com with ESMTPSA id e65sm17089228pfc.184.2019.02.17.21.14.08 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 17 Feb 2019 21:14:09 -0800 (PST) From: Paul Lambert Message-Id: <00F86909-D260-4267-AC79-D5D63AD6DBAD@nymbus.net> Content-Type: multipart/alternative; boundary="Apple-Mail=_79A3FFD5-9578-4B4B-A7CC-681160980C15" Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Date: Sun, 17 Feb 2019 21:14:45 -0800 In-Reply-To: Cc: tls@ietf.org, T2TRG@irtf.org, Russell Housley To: Sankalp Bagaria References: X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [T2TRG] ITDA - IoT Device Authentication X-BeenThere: t2trg@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IRTF Thing-to-Thing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Feb 2019 05:14:16 -0000 --Apple-Mail=_79A3FFD5-9578-4B4B-A7CC-681160980C15 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Sankalp, The schema below is the wrong way to use PUF technology for IoT device = authentication.=20 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.=20 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. =20 PUF may be instantiated as HW or SW. Your scheme mentions " signal path = can affect the delay in the propagation of a signal=E2=80=9D =E2=80=A6 = 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.=20 PUF is just one way for a device to obtain unique secrets (symmetric or = asymmetric). It has been standard practice to =E2=80=9Cinject=E2=80=99 = 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.=20 Long-lived device unique public keys and certificates that provide = protection through the full manufacturing life-cycle are an interesting = topic area =E2=80=A6 Challenge/response PUF protocols are not useful or = interesting for standardization. Paul > On Feb 15, 2019, at 9:06 PM, Sankalp Bagaria = wrote: >=20 > Hello, >=20 > Please take a look at this and advise if it is a good idea and whether = it should be pursued. >=20 > Thanks, >=20 > Sankalp Bagaria. >=20 >=20 >=20 > ITDA - IoT Device Authentication >=20 > 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=E2=80=99t store challenge/response or = key or certificate. Both the server and the client can initiate the = handshake. >=20 > Background >=20 > Traditionally, there are two ways to authenticate a device: a = centralised CA issuing certificates and block-chain. Both require costly = infrastructure and can=E2=80=99t 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. >=20 > 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. >=20 > =20 > PUF: The Concept >=20 >=20 >=20 > Figure 1: PUF =E2=80=93 Multiplexer pair=E2=80=99s output delay = compared by arbiter (latch) >=20 > 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. >=20 > 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. >=20 > Limitations of current PUF implementation >=20 > To prevent the replay attack, a challenge =E2=80=93 response pair can = be used only once. To enable this, a large set of challenge =E2=80=93 = 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. >=20 > 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. >=20 > =20 > Our solution >=20 > 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. >=20 > The Protocol Combining TLS 1.3 and Challenge/ Response of PUF >=20 > The Protocol with Client Starting the Connection >=20 > 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. >=20 > =20 > 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. >=20 > =20 > 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. >=20 > Client = Server >=20 > ClientHello =20 >=20 > + key_share --------> =20 >=20 > = ServerHello >=20 > = + key_share =20 >=20 > = {Encrypted Extensions} >=20 > = {Certificate} >=20 > {CertificateVerify} >=20 > <--------- = {PUF_Challenge} >=20 > PUF_Response ----------> =20 >=20 > = {Finished} >=20 > <--------- = [Application Data] >=20 > {Finished} = =20 >=20 > [Application Data} <--------> = [Application Data] >=20 > =20 >=20 > =20 >=20 > The Protocol with Server Starting the Connection >=20 > 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. >=20 > =20 > Client = Server >=20 > <----------- = ServerHello >=20 > =20= > ClientHello =20 >=20 > + key_share ----------> = =20 >=20 > key_share =20 >=20 > = {Encrypted Extensions} >=20 > = {Certificate} >=20 > = {CertificateVerify} >=20 > = <----------- {PUF_Challenge} >=20 > =20 > {PUF_Response} ----------=C3=A0 >=20 > = {Finished} >=20 > = <--------- [Application Data] >=20 > {Finished} = =20 >=20 > [Application Data} <--------> = [Application Data] >=20 > =20 > 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. >=20 > Future Work: >=20 > 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. >=20 > References =E2=80=93 >=20 > [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 =E2=80=93 Post = =E2=80=93 The Things Network. = https://www.thethingsnetwork.org/community/thessaloniki/post/50-billion-io= t-devices-will-be-connected-by-2020 = > [3] https://en.wikipedia.org/wiki/Physical_unclonable_function = > [4] G. E. Suh and S. Devadas, =E2=80=9CPhysical unclonable functions = for device authentication and secret key generation,=E2=80=9D in = Proceedings of the 44th annual Design Automation Conference, San Diego, = CA, Jun. 2007, pp.9=E2=80=9314 = https://people.csail.mit.edu/devadas/pubs/puf-dac07.pdf = > [5] = http://people.csail.mit.edu/rudolph/Teaching/Lectures/Security/Lecture-Sec= urity-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 = (PDF). IEEE = Hardware Oriented Security and Trust (IEEE HOST 2013). June 2=E2=80=933, = 2013 Austin, TX, USA >=20 > http://ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=3D6581556 = > [8] Merchan Jorge Guajardo = , Shankaran S. Kumar = , Pim T. Tuyls = , Geert J. Schrijen = Identification of devices using physically = unclonable functions=20 > WO 2009024913 A2 >=20 > [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=3D6680199 = > = [10]https://www.esat.kuleuven.be/cosic/thesis/2011/mai/CloningTheUnclonabl= e_en.pdf = > [11] Srinivas Devadas, Edward Suh, Sid Paral, Richard Sowell, Tom = Ziola, Vivek Khandelwal . Design and Implementation of PUF-Based = =E2=80=9CUnclonable=E2=80=9D 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=E2=80=99s 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.p= df = > [17] = https://patents.google.com/patent/US20090083833A1/en?q=3DPUF&q=3Dphysicall= y+unclonable+function&oq=3DPUF+physically+unclonable+function = > [18] = https://patents.google.com/patent/US8290150B2/en?q=3Dauthentication&q=3DPU= F&q=3Dphysically+unclonable+function&oq=3Dauthentication+PUF+physically+un= clonable+function = > [19] = https://patents.google.com/patent/US20140279532A1/en?q=3Dauthentication&q=3D= PUF&q=3Dphysically+unclonable+function&oq=3Dauthentication+PUF+physically+= unclonable+function = > [20] RFC 8446 =E2=80=93 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 >=20 > [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 >=20 > _______________________________________________ > T2TRG mailing list > T2TRG@irtf.org > https://www.irtf.org/mailman/listinfo/t2trg --Apple-Mail=_79A3FFD5-9578-4B4B-A7CC-681160980C15 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 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=E2=80=9D =E2=80=A6 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 =E2=80=9Cinject=E2=80=99 = 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 =E2=80=A6 =  Challenge/response PUF protocols are not useful or interesting for = standardization.

Paul





On Feb 15, 2019, at 9:06 PM, Sankalp Bagaria = <sankalp.nitt@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=E2=80=99t 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=E2=80=99t 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 =E2=80=93 Multiplexer pair=E2=80=99s 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 =E2=80=93 response pair can be used only once. To enable this, a large set of challenge =E2=80=93 = 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         &nb= sp;     =             &n= bsp;           &nbs= p;            =             &n= bsp;           &nbs= p;            =             &n= bsp;          Server

ClientHello        &nbs= p;            =             &n= bsp;     

+ = key_share          -------->           = =           

          &nb= sp;           =             &n= bsp;           &nbs= p;            =             &n= bsp;           &nbs= p;            =             &n= bsp;      ServerHello

          &nb= sp; =             &n= bsp;           &nbs= p;            =          =             &n= bsp;           &nbs= p;            =             &n= bsp;      + key_share      

          &nb= sp;            = ;      =             &n= bsp;           &nbs= p;            =             &n= bsp;           &nbs= p;  {Encrypted Extensions}

          &nb= sp;            = ;            &= nbsp;           &nb= sp;  =             &n= bsp;           &nbs= p;            =             &n= bsp;           &nbs= p;   {Certificate}

    {CertificateVerify}

          &nb= sp;     =             &n= bsp;           &nbs= p;  <---------        = ;     =             &n= bsp;           &nbs= p;      {PUF_Challenge}

PUF_Response          =     ---------->      =             &n= bsp;           =

          &nb= sp;            = ;            &= nbsp;         =             &n= bsp;           &nbs= p;            =             &n= bsp;           &nbs= p;       {Finished}

          &nb= sp;          =             &n= bsp;       <---------  &nb= sp;          =             &n= bsp;           &nbs= p;           [Appli= cation Data]

{Finished}  =             &n= bsp;           &nbs= p;            =             &n= bsp; =             

[Application Data} =         <--------> &nbs= p;           =             &n= bsp;           &nbs= p;      [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         &nb= sp;            = ;      =             &n= bsp;           &nbs= p;            =             &n= bsp;           &nbs= p;            =  Server

          &nb= sp;        =             &n= bsp;           &nbs= p;            = <-----------  =             &n= bsp;           &nbs= p;            = ServerHello

     =             &n= bsp;           &nbs= p;            =             &n= bsp;           &nbs= p;   
ClientHello        &nbs= p;            =             &n= bsp;     

+ = key_share    =             &n= bsp;           &nbs= p; ---------->        &nbs= p;    =             &n= bsp;           &nbs= p;            =

 key_share        =         

          &nb= sp;            = ;            &= nbsp;            =   =             &n= bsp;           &nbs= p;            =            {Encrypt= ed Extensions}

          &nb= sp;            = ;            &= nbsp;           =             &n= bsp;           &nbs= p;            =             &n= bsp;           &nbs= p;   {Certificate}

          &nb= sp;            = ;            &= nbsp;            =      =             &n= bsp;           &nbs= p;            =             &n= bsp;  {CertificateVerify}

          &nb= sp;         =             &n= bsp;           &nbs= p;            =      <-----------     = ;       =             &n= bsp; {PUF_Challenge}

          &nb= sp;            = ;            &= nbsp;            =             =

{PUF_Response}        =             &n= bsp;         ----------=C3=A0

          &nb= sp;            = ;            &= nbsp;         =             &n= bsp;           &nbs= p;            =             &n= bsp;           &nbs= p;       {Finished}

          &nb= sp;          =             &n= bsp;           &nbs= p;            =         <---------  &= nbsp;         =           [Application = Data]

    =  {Finished}  =             &n= bsp;           &nbs= p;            =             &n= bsp;        =             

[Application = Data}  =             &n= bsp;           &nbs= p;   <-------->      &n= bsp;     =             &n= bsp;   [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 = =E2=80=93

[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 =E2=80=93 Post =E2=80=93 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, = =E2=80=9CPhysical unclonable functions for device authentication and secret key generation,=E2=80=9D = in Proceedings of the 44th annual Design Automation Conference, San Diego, CA, Jun. = 2007, pp.9=E2=80=9314 https://people.csail.mit.edu/devadas/pubs/puf-dac07.pdf<= /a>

[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 (PDF). IEEE Hardware Oriented Security and Trust = (IEEE HOST 2013). June 2=E2=80=933, 2013 Austin, TX, USA

 http://ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=3D6581556

 [8] Merchan Jorge Guajardo, = Shankaran S. Kumar, Pim T. Tuyls, Geert J. Schrijen = 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=3D6680199

      = [10]https://www.esat.kuleuven.be/cosic/thesis/2011/mai/CloningTheUn= clonable_en.pdf

[11] Srinivas Devadas, Edward = Suh, Sid Paral, Richard Sowell, Tom Ziola, Vivek Khandelwal . Design and Implementation of = PUF-Based =E2=80=9CUnclonable=E2=80=9D 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.p= df

[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-14650= 2604154-59..pdf

[15] D. Lim. Extracting secret = keys from integrated circuits. Master=E2=80=99s thesis, Massachusetts Institute of = Technology, May 2004. http://csg.csail.mit.edu/pubs/memos/Memo-476/DaihyunLimThesis.p= df

[16] Ulrich Ruhrmair. On the = Formal Foundations of PUFs and Related Primitives. October 19, 2016.  https://depositonce.tu-berlin.de/bitstream/11303/5994/4/ruehrma= ir_ulrich.pdf

[17] https://patents.google.com/patent/US20090083833A1/en?q=3DPUF&am= p;q=3Dphysically+unclonable+function&oq=3DPUF+physically+unclonable+fu= nction

[18]      = https://patents.google.com/patent/US8290150B2/en?q=3Dauthentica= tion&q=3DPUF&q=3Dphysically+unclonable+function&oq=3Dauthentic= ation+PUF+physically+unclonable+function

[19] https://patents.google.com/patent/US20140279532A1/en?q=3Dauthen= tication&q=3DPUF&q=3Dphysically+unclonable+function&oq=3Dauthe= ntication+PUF+physically+unclonable+function

[20] RFC 8446 =E2=80=93 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
T2TRG@irtf.org
https://www.irtf.org/mailman/listinfo/t2trg

= --Apple-Mail=_79A3FFD5-9578-4B4B-A7CC-681160980C15--