Physical unclonable functions

The idea of physical one-way function (POWF) was introduced in [143]. The authors proposed a simple challenge-response authentication protocol. It assumes that an identi-

fier (e.g. server, that will authenticate a user) generates a set of challenges which are run on a user’s equipment. These challenges are then stored by the identifier along with the corresponding set of responses, i.e., as challenge-response pairs (CRPs). Next, when the user sends an authentication request to the identifier chooses one of the previously stored CRPs and “challenge” the user to produce a response. The authentication is successful, if the response is identical to the one previously stored in the identifier’s database. The structure proposed in [143] is based on the usage of a laser beam as input of their system. This beam propagates through a three-dimensional micro-structure and the final resulting pattern determines the output of the system. A challenge to this scheme could define the angle of the transmitted beam.

Later, the authors of [144] brought this idea to integrated circuit (IC) structures by introducing the silicon physical unclonable function (PUF). Its idea is to utilise the fact that every integrated circuit differs to others due to manufacturing variability [52, 145] and cannot be cloned [54]. A challenge to this scheme can refer to delay at each gate, power-on state and other variable features. Nowadays, due to its randomness and un- clonable properties, PUFs continues to attract the researches’ attention and since the in- troduction of PUFs in [144], numerous PUF architectures have been proposed many of which suitable for IoT applications. A few of these architectures are: arbiter PUF [146], ring oscillator PUF [39], transient effect ring oscillator PUF [147], static random-access memory PUF [148], hardware embedded delay PUF [149] and more [53, 128].

As mentioned above, each PUF can be used as a challenge – response scheme, mean- ing that a PUF takes a challenge as input, runs it and outputs the corresponding response. Depending on the number of CRPs that each PUF can support, two types of PUFs can be differentiated: i) strong PUFs, suitable for authentication and ii) weak PUFs, which can be used for secret key generation. Intuitively, a weak PUF can process a small number of challenges, while a strong PUF is capable of processing a large set of CRPs. Further requirement for a strong PUF is backward secrecy, meaning that if some of the previous CRPs are revealed, an attacker should not be able to predict the response of any future challenges. Throughout this thesis PUFs will refer to strong PUFs from this point on-

. . . _{Arbiter 0 or 1}

Challenge: 0 1 1 0

Figure 3.1: Arbiter PUF.

wards.

To familiarise the readers with the basics of PUFs, two structure examples are pre- sented. The structure of Arbiter PUF was presented in [146]. In this scheme the authors propose the usage of the delay variations of wires and transistors within integrated cir- cuits. The idea is based on transmitting rising edge signals through two “identical” delay paths which consist of several switching elements. Due to variation properties the delay will slightly differ at each path. Finally, an arbiter determines the corresponding “win- ner”, i.e., the signal that arrived first at the end of the trace. The produced response (output bit) depends on the “winner”. A challenge to this scheme is composed by choosing the configuration of each switching element as illustrated on Fig. 3.1. Another PUF scheme, called recombined oscillator PUF, was proposed in [150]. The scheme calculates fre- quency differences between pairs of oscillators which produces set of random variable. The challenge to this scheme determines the sign in front of each random variable. To produce the response to a specific challenge the scheme calculates the sum of all random variables and compares it to a pre-defined threshold. Similarly, [151] proposed an im- proved scheme which increases the secrecy of the output by choosing a different subset of the oscillators each time (defined by the challenge).

Following from the above, a typical PUF-based authentication protocol consists of two main phases, namely enrolment phase and authentication phase [152–156].

During the enrolment phase each user runs a set of challenges C on his PUF and characterises the variance of the measurement noise in order to generate helper data hd. Next, a verifier creates and stores a database of all CRPs (C, R) for each user’s PUF within its network. A CRP pair in essence consists of an authentication key and related helper

data hd. Within the database, each CRP is associated with the ID of the corresponding user. The enrolment phase is a one-time operation and it is assumed to be done on a secure channel. Later, during the authentication phase an user sends its ID to the verifier requesting to start a communication. Receiving the request, the verifier checks if the received ID exists in its database. If it does, the verifier chooses a random CRP (Ci, Ri) that correspond to this ID and sends Ci to the user. The user computes the response Ri by running the challenge Ci on its PUF, as follows Ri = PUF(Ci), and sends Ri to the verifier. However, the PUF measurements at the user are never exactly the same due to measurement noise, therefore, the verifier uses the new PUF measurement and the helper data hdR,istored during the enrollment to re-generate the authentication key. Finally, the verifier compares the re-generated key to the one in the CRP and if they are identical the authentication of the node is successful. In order to prevent replay attacks, once used, a CRP is deleted from the verifier database.

A widely used method for helper data and key generation is by employing fuzzy extractors (FE). FE are method that allows for key derivation from nonuniform noisy sources [157]. Due to their properties they are referred as a common technique to cope the noise present in biometric data and PUF measurements [158–162]. A so called (m, l, t, ) FE is built from a pair of randomised functions, namely Generate Gen and Reproduce Rep. The function Gen requires a single input R ∈ R and produces two outputs, helper data hdRand a key kR ∈ {0, 1}l. The function Rep is deterministic reproduction and can reproduce the key kR by using the helper data hdRand a sequence closely associated to R, i.e., R0. The correctness of the Rep function can be satisfies if only D(R, R0) ≤ t (D refers to Hamming distance). On the other hand, when hdR is public the key sequence kR is close to uniformly random only if the min-entropy of R is at least m. This im- plies the following condition on the statistical distance between kR and the universe of sequences with length l, whenever hdRis public SD((kR, hdR), (Ul, hdR)) ≤ . More details about FEs’ parameters and bounds can be found in [157, 163, 164].

To summarise, as it is possible to construct a PUF that does not require any complex operations, it can be used as a lightweight mechanism to generate an unclonable and ran-

dom secret. However, to guarantee a secure transmission of challenges and responses one cannot send these in clear text and risk to be obtained by an adversary. Therefore, further security mechanisms have to be employed to create a secure authentication protocol based on PUF. Many examples of PUF-based authentication protocols have been proposed in the literature: some for unilateral authentication [165, 166] and some for mutual authen- tication [166–169]. A comprehensive survey on lightweight PUF authentication schemes is presented by Delvaux et al. [55].

3.2.3

0-RTT protocols

This section briefly describes the 0-RTT authentication mode introduced in the transport layer security (TLS) 1.3 protocol [126]. The use of 0-RTT obviates the need of performing a full authentication procedure for every re-authentication through the use of a resumption secret z, thus reducing latency. The TLS 1.3 0-RTT handshake works as follows: in the very first connection between client and server a regular TLS handshake is used. During this step the server sends to the client a look-up identifier kl for a corresponding entry in session caches or it sends a session ticket. Then both parties derive a resumption secret z using their shared key and the parameters of the session. Finally, the client stores the resumption secret z and uses it when reconnecting to the same server which also retrieves it during the re-connection.

If session tickets are used, the server encrypts the resumption secret using a long-term symmetric encryption key, called a session ticket encryption key (STEK), resulting in a session ticket. The session ticket is then stored by the client and included in subsequent connections, allowing the server to retrieve the resumption secret. Using this approach the same STEK is used for many sessions and clients. On one hand, this property highly re- duces the required storage of the server, however, on the other hand, it makes it vulnerable to replay attacks and not is not forward secure. Forward secrecy assures that past sessions will remain secret even if current or/and future secret keys are compromised [170]. Due to these vulnerabilities, the work within this chapter focuses on the session cache mechanism

described next.

When using session caches the server stores all resumption secrets and issues a unique look-up identifier kl for each client. When a client tries to reconnect to that server it includes its look-up identifier klin the 0-RTT message, which allows the server to retrieve the resumption secret z. Storing a unique resumption secret z for each client requires server storage for each client but it provides forward security and resilience against replay attacks, when combined with a key generation mechanisms such as Diffie Hellman (or the SKG used in this thesis) which are important goals for security protocols [127].