Re: [TLS] [T2TRG] ITDA - IoT Device Authentication
Sankalp Bagaria <sankalp.nitt@gmail.com> Mon, 18 February 2019 11:28 UTC
Return-Path: <sankalp.nitt@gmail.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7E7B130EF3 for <tls@ietfa.amsl.com>; Mon, 18 Feb 2019 03:28:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level:
X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, LOTS_OF_MONEY=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 d42WCJTg6QDu for <tls@ietfa.amsl.com>; Mon, 18 Feb 2019 03:28:03 -0800 (PST)
Received: from mail-ot1-x32f.google.com (mail-ot1-x32f.google.com [IPv6:2607:f8b0:4864:20::32f]) (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 5D4AE130ED4 for <tls@ietf.org>; Mon, 18 Feb 2019 03:28:03 -0800 (PST)
Received: by mail-ot1-x32f.google.com with SMTP id v62so18838150otb.3 for <tls@ietf.org>; Mon, 18 Feb 2019 03:28:03 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=PcdK62lsPKipg2MDy5ito2PdKPTAZtWg7dJMblu5WmM=; b=BBpGBNncCpLYLgKoL0gSaohc1RGuahK4RTcFatpDaeBs6NqywAiFhx63l8sHD/x78D wRDICrcCXMSf3ZSTQBvTnb331Jvxw/sAT603U8zhvP+93seLmgtBXCrfp2WIAvhuOony kX9I6nYLZMtzirokaqJMgJDs2SwB6FOoysf+Er48iVD/ZT0jmStfSCYKvFwKQjZve6gm G1UK5e+2UrLDNq/P4/AC61+n3EQhruj4gi3oY4nc2l9t/EtSc3iV40GKqMZ3ln4ivi6d MmrtxXPkfiNrd07FsPyJrS9uDlyk1FOzOT3JSx9of+IqShkgOskeQSeyRmFbqyNaaHyg WmeQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=PcdK62lsPKipg2MDy5ito2PdKPTAZtWg7dJMblu5WmM=; b=BcUCty36IO2LS9rQsGerQRxZLKP6/CA68jQZX6hwH51n2m7BazT3MFM8aJ3OiuUv/b EryNs7oVPJhrnRHG/lhTWKh9HzW6Je9VfctVUsdH5vInn6+2b1ez6xeXemGugT8t/Fqq JQd3aibHBuaxlBYfNM4ZdX/lRezror0YWpYeuIhFJLi9k3O7EVVKcN21TR8bAVg8mMId 3n0dmI16SgO7xtJo/bbpbRRgJzNIdRaB7brGKOoNDYUZQ9iZX2sOud/CuaYyjGoIcVjv wQy8ze6J3lrtfIOg4AD3lxNMb+jiScWd0XsME+dRZlvQrH/1ZzI7hbe9Q8l+1SFk62K8 D7zg==
X-Gm-Message-State: AHQUAuZApX6fBOPZ38R31Hz+BYNpbNM3dhNUkTMHTU8lGueWWjHYCTIo FBSgBI0rlwjrZ4wYCJJaY+vCsz6J5CidjAi7f4gZRw==
X-Google-Smtp-Source: AHgI3IZyzMnnEjKu+W1S5YZ/VP63/QmiTElD1UH26L966RzsU1KVXD4DDJcL9qa0wt58W8+z/awKrs7ytL7TfYfhRTQ=
X-Received: by 2002:a9d:130:: with SMTP id 45mr14060666otu.355.1550489282037; Mon, 18 Feb 2019 03:28:02 -0800 (PST)
MIME-Version: 1.0
References: <CAPZZOTgmiDVxJmEYq7J6amgCaWrdcBHDjww=ZjrVd0m-5nbsjg@mail.gmail.com> <00F86909-D260-4267-AC79-D5D63AD6DBAD@nymbus.net>
In-Reply-To: <00F86909-D260-4267-AC79-D5D63AD6DBAD@nymbus.net>
From: Sankalp Bagaria <sankalp.nitt@gmail.com>
Date: Mon, 18 Feb 2019 16:57:48 +0530
Message-ID: <CAPZZOTj9C-d2zx_sOv-11GST_pv2oyM=CN7V+oJwnmRcuGGQww@mail.gmail.com>
To: Paul Lambert <paul@nymbus.net>
Cc: tls@ietf.org, T2TRG@irtf.org, Russell Housley <housley@vigilsec.com>
Content-Type: multipart/alternative; boundary="000000000000e24e840582296abb"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/EN2lonqMDLMGC2ZoSKUOQmmTUA8>
Subject: Re: [TLS] [T2TRG] ITDA - IoT Device Authentication
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 18 Feb 2019 11:28:07 -0000
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, <paul@nymbus.net> wrote: > Sankalp, > > The schema below is the wrong way to use PUF technology for IoT device > authentication. > > PUF is already being used in many fielded IoT systems. You simply use the > device unique PUF secret to create a public/private key pair. The public > key is then extracted and used to authentic the device. This enables > tracking and identification of the device through its full life-cycle. > Early observation of the device-unique public key mitigates a variety of > supply chain attacks. The extracted public key may be certified by a X.509 > CA. The PUF derived identity may then be used directly in a TLS protocol > exchange. > > Early assignment of public key certificate to a device enables strong > protection of the device during manufacturing. The PUF device keys may be > used as part of the boot process to enable per-device protection of > sensitive firmware or other cryptographic secrets. > > PUF may be instantiated as HW or SW. Your scheme mentions " signal path > can affect the delay in the propagation of a signal” … the seems to imply a > HW based implementation (perhaps a Butterfly PUF). A simpler implementation > would be to use SRAM PUF where the entropy in uninitialized SRAM is used to > generate the device unique secrets. SRAM based PUF can be readily > integrated into existing MCU devices. > > The simplest application of PUF in IoT uses a device unique symmetric > secret key to serve as a key to encrypt sensitive data in unprotected NV > memory. This is basically a low-level key vault that provides > confidential and non-non-maleable secure device storage. This is a very > attractive alternative to OTP memory that s more expensive and of limited > size. > > PUF is just one way for a device to obtain unique secrets (symmetric or > asymmetric). It has been standard practice to “inject’ secrets during > manufacturing. Injection requires more trust in the key distribution and > provisioning process than approaches that generate keys on device and never > expose these secrets. > > Long-lived device unique public keys and certificates that provide > protection through the full manufacturing life-cycle are an interesting > topic area … Challenge/response PUF protocols are not useful or > interesting for standardization. > > Paul > > > > > > On Feb 15, 2019, at 9:06 PM, Sankalp Bagaria <sankalp.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’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 > <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 > <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 > > [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 > _______________________________________________ > T2TRG mailing list > T2TRG@irtf.org > https://www.irtf.org/mailman/listinfo/t2trg > > >
- [TLS] ITDA - IoT Device Authentication Sankalp Bagaria
- Re: [TLS] ITDA - IoT Device Authentication Peter Gutmann
- Re: [TLS] ITDA - IoT Device Authentication Sankalp Bagaria
- Re: [TLS] ITDA - IoT Device Authentication Salz, Rich
- Re: [TLS] ITDA - IoT Device Authentication Sankalp Bagaria
- Re: [TLS] ITDA - IoT Device Authentication Salz, Rich
- Re: [TLS] ITDA - IoT Device Authentication Sankalp Bagaria
- Re: [TLS] ITDA - IoT Device Authentication Salz, Rich
- Re: [TLS] ITDA - IoT Device Authentication Sankalp Bagaria
- Re: [TLS] [T2TRG] ITDA - IoT Device Authentication Paul Lambert
- Re: [TLS] [T2TRG] ITDA - IoT Device Authentication Eliot Lear
- Re: [TLS] [T2TRG] ITDA - IoT Device Authentication Sankalp Bagaria
- Re: [TLS] [T2TRG] ITDA - IoT Device Authentication Sankalp Bagaria
- Re: [TLS] ITDA - IoT Device Authentication Salz, Rich