Methods and systems for establishing a secure session between a client device and a server

Abstract

A device with a PUF (physical unclonable function) generates challenges from random numbers (RAND) and PUF outputs (e.g. challenge = Matrix*RAND + PUF) and responses from the random numbers (e.g. (key

Description

FIELD Embodiments described herein relate to methods and systems for establishing a secure session between a client device and a server. BACKGROUND With the advent of the Internet of Things (loT), the world has seen a continued growth in the number of interconnected computing devices. Coupled with this growth is a corresponding need for those devices to be able to authenticate themselves to one another. Physical Unclonable Functions (PUFs) provide one means for doing so. A PUF can be understood to comprise one or more features of a device that can be used to generate a digital fingerprint, which will serve as a unique identifier for that device. The PUF can be used in an authentication process in which a challenge is issued to the device and a response generated based on the PUF. During this process, the output of the PUF is not itself disclosed outside of the device, but the authenticity of the device can be confirmed based on the generated response. Some PUFs will be embodied in the physical structure of the device and encode subtle variations in that structure introduced during manufacture. For example, a PUF may be obtained by capturing an image of one or more component parts of a device, and using that image to generate a map of the physical imperfections (scratches I dimples etc.) present on the surface of that component. A PUF may also be derived from functional aspects of the device. For example, a computing device may incorporate a static random access memory (S-RAM) chip. On booting up the device, the cells in the chip may default to a particular arrangement of 1s and Os, unique to that chip. The arrangement of binary digits may be used as a PUF for the device. Whilst the use of PUFs for authentication is well known in the art, problems persist in the application of PUFs in scenarios that involve large numbers of actors and I or devices. One example concerns supply chains for complex products such as cars, which can be large and international in scope. At the lowest level, a car is composed of many thousands of devices, more and more of which are becoming interconnected. The supply chain itself has multiple levels, with component parts provided at the lowest 01 07 24 level being combined to form systems at the next level, which are in turn combined to form more complex systems, and eventually the full vehicle. These levels can involve a number of different organisations with different responsibilities, each of whom may wish to establish the provenance of devices in the supply chain, so as to distinguish genuine 5 parts from fake parts. In order for PUF authentication to be implemented in such a supply chain, confidential PUF information needs to be shared between different parties to enable them all to perform authentication. Current approaches, however, do not account for differing levels of trust between parties in the supply chain, nor do they provide for clear handover of control between the different parties. Moreover, these 10 approaches have tended to focus solely on aspects relevant to the authentication protocol, and not the wider architecture for integrating PUF based devices into larger systems. Thus, existing PUF authentication protocols are designed with particular PUF constructions in mind, requiring that each new device, and each new PUF, should have its own bespoke architecture and protocol in order to be integrated. The large number 15 of different authentication protocols poses a challenge from a system integrator’s point of view, making it time consuming, expensive and often impractical to support authentication solutions based on PUFs. In addition, many conventional systems do not support constrained devices, as are used in many loT applications, and for which authentication based on PUFs might be particularly advantageous. Many solutions also 20 require additional processing to handle inherent noise in PUF outputs, which can impact performance. SUMMARY 25 According to a first aspect of the present invention, there is provided a method as set out in claim 1. 01 07 24 The first MAC may be computed using a first MAC key. The first MAC key may be computed by the server as a function of the response in the selected challengeresponse pair. The second MAC may be computed using a second MAC key. The 5 second MAC key may be computed by the client device using the second readout of the PUF. The method may further comprise: obtaining, based on the challenge received from the server and the second 10 readout of the PUF, a candidate value for the random number; and computing the second MAC key as a function of the candidate value for the random number. In the event that the second MAC does not match the first MAC, the method may 15 further comprise: obtaining, based on the challenge received from the server, and the second readout of the PUF, a new candidate value for the random number; and re-computing, by the client device, the second MAC key as a function of the new candidate value for the random number. 20 The client device may continue to obtain new candidate values for the random number and to re-compute the second MAC key using each candidate value, until either: (i) the MAC as computed by the client device using the second MAC key matches the first MAC or 25 (ii) a predetermined number of attempts have been made to calculate a MAC that matches the first MAC but without success. In the event that the first MAC matches the second MAC, the method may further comprise sending an acknowledgement from the client device to the server using the 30 second MAC key. Sending the acknowledgement to the server may comprise encoding an identifier of the client device using the second MAC key. Upon verifying, by the server, that the acknowledgement is consistent with the challenge-response pair from which the challenge was selected, the client device may be authenticated by the server. Upon authenticating the client device by the server, a session key may be generated to be used for communication between the client device and the server. The session key may be generated based on the random number used in generating the challengeresponse pair. Information may be exchanged between the client device and the server, the information being confidentiality protected using the session key. The method may comprise providing, by the client device, and after the client has been authenticated by the server, one or more further challenge-response pairs to the server. The client device may be enrolled with the server, the enrolment comprising: obtaining an estimate of a noise distribution of the PUF, wherein the noise distribution reflects an extent of variation in a digital output obtained when the PUF is read out multiple times. The enrolment may further comprise obtaining Confidence Information for the PUF. The Confidence Information may provide an indication as to which elements in the digital output remain consistent when the PUF is read out multiple times. The Confidence Information may be used to select a portion of the digital output to be used in authenticating the client device at the server. The client device may be re-enrolled with the server at a later point in time from the initial enrolment. The re-enrolment may comprise: obtaining a new estimate of a noise distribution of the PUF; and generating and issuing, by the client device, one or more new challengeresponse pairs to the server. Each challenge-response pair may have a respective index value. For each challengeresponse pair, the challenge in the pair may be obtained by computing the first function of the random number, the readout of the PUF and the respective index. The response in the pair may be obtained by computing the second function of the random number and the respective index. The client device may receive, from the server, the index value for the challengeresponse pair. Prior to computing the second MAC, the client device may check that the index value is one that the client device has not previously received from the server. 5 The first function may be a pseudo-random function. According to a second aspect of the present invention, there is provided a method for authenticating a client device to a server as set out in claim 18. 10 The PUF may comprise a structural or functional feature of the client device that is capable of being interrogated to produce a read out of the PUF, the PUF read out comprising a digital output sequence that is unique to the client device. 15 The server may be a first authentication server and may receive a plurality of challenge-response pairs from the client device. CM 01 07 24 The method may comprise: forwarding a subset of the challenge response pairs to a second authentication server, the subset of challenge response pairs being marked as used by the first authentication server; and 5 authenticating the client device at the second authentication server, using one of the subset of challenge response pairs. According to a fourth aspect of the present invention, there is provided a computer-readable storage medium as set out in claim 21. 10 According to a fifth aspect of the present invention, there is provided a computing device as set out in claim 22. Embodiments described herein provide an architecture and protocol(s) for supporting 15 the enrolment and re-enrolment of devices to Authentication Servers based on PUFs, and the mutual authentication of those Servers and devices. In this context, an authentication server can be understood to mean any entity that carries is configured to verify or authenticate a particular device’s identity based on a PUF. Embodiments support the authentication of a wide range of PUFs and devices in the same system, 20 without requiring modification, i.e. it is unnecessary to adopt a new protocol for each new PUF and / or PUF based device. In this way, embodiments can help to reduce the costs of integrating new devices in a system and for managing obsolescence of devices over time (hardware refresh). Embodiments can facilitate the use of PUF-based authentication in more complex systems and supply chains, such as those 25 required to support use in automotive systems, for example. BRIEF DESCRIPTION OF DRAWINGS Embodiments of the invention will now be described by way of example with reference 30 to the accompanying drawings in which: Figure 1 shows a schematic of a system according to an embodiment: Figure 2 shows a flow-chart of steps for enrolling a PUF based device with an Authentication Server, according to an embodiment; Figure 3 shows a flow-chart of steps for mutual authentication of a PUF-based device and a server, according to an embodiment; Figure 4 shows a flow-chart of steps for mutual authentication of a PUF-based device, according to an embodiment; and Figure 5 shows a schematic of a system according to an embodiment DETAILED DESCRIPTION Figure 1 shows an example system according to an embodiment. The system comprises one or more authentication servers 101, and a PUF based device 103. The PUF based device may be any type of computing device that is capable of communicating with one or more other device(s), either wirelessly or over a wired connection, and which includes a PUF by means of which it is able to authenticate itself to those other devices. Once authenticated by another device, the PUF based device may provide data to that other device, or receive data such as management instructions from that device, for example. The PUF based device 103 includes a PUF 105 that is capable of being read to output several hundred bits of data, and a processor 107 configured to read output values from the PUF and perform protocol operations. The processor 107 may be a general purpose processor running software, but could also be a microcontroller, an FPGA or ASIC, for example. The PUF based device 107 further includes memory 109 available to process the PUF output as part of an authentication protocol. As shown in Figure 1, the PUF based device includes a source 111 of high quality random numbers. However, the source of random numbers 111 need not be stored on the PUF based device, but could instead be stored on the Authentication Server. The PUF based device 103 is able to communicate with the Authentication Server 101 via a communication means, which may be one of a number of standard communications known in the art, including a USB, serial connection, Ethernet, BlueTooth or Wi-Fi connection, for example. The Authentication Server 101 itself comprises a general purpose computing device running software, and may be used as part of a wider system that the PUF based device is being integrated with. In other examples, the Authentication Server may comprise a more limited device. As in the PUF based device 103, the Authentication Server 101 includes a processor 113 able to perform protocol operations. The processor 113 may be a general purpose processor running software, but could be a microcontroller, an FPGA or an ASIC, for example. The Authentication Server 101 also includes a secure memory 115 for long-term storage of Challenge Response Pairs (CRPs) to be used when authenticating the PUF based device to the Server (and vice versa). The long term storage 115 may be confidentiality and integrity protected, with the stored contents being secured using one or more cryptographic algorithms. The long term storage may be in the region of 10s of KBs for each PUF based device. In order that the Authentication Server 101 should be able to authenticate the PUF-based device, the PUF-based device is first enrolled or registered with the Authentication Server. Figure 2 shows the three main stages of enrolment. The first step S201 is to obtain an estimate of the PUF noise distribution. The noise distribution reflects the extent of variation seen in the output obtained when the PUF is interrogated or read multiple times. Each interrogation will generally elicit the same output sequence, but with occasional variations, due to either fluctuations in the PUF itself or the signal used to interrogate the PUF. For example, where the PUF is embodied in the surface profile of a particular component, the PUF may be read out by capturing an image of the surface and using the measured intensity to determine the depth at each pixel in the image. The recovered depth values may then be output as a digital sequence. In this case, whilst successive images will return the same overall result for the surface profile, some pixels may see different depth values returned for different images, owing to minor fluctuations in intensity and / or the sensitivity of the sensor on which the image is captured; these differences will in turn manifest themselves as a change in the digit values at certain points in the output digital sequence. Similarly, in the case where the PUF is embodied in the arrangement of 1s and 0s in the cells of an S-RAM chip at the point of boot up, the arrangement should remain largely consistent between successive boot ups, but with some cells occasionally seeing a switch from 1 to 0 and vice versa. The current PUF noise distribution may be estimated by performing tests on the PUF device as part of the enrolment process. Alternatively, the noise estimate may be obtained based on knowledge of PUF noise from theory, or by performing experiments with similar PUFs / reviewing noise distributions obtained in the past from similar PUFs. The estimate of the noise distribution can be used to set parameters for the authentication protocol, discussed in more detail below. In the second step S202, Confidence Information (Cl) is obtained. The Confidence Information, in effect, measures the reliability of the different bits in the sequence output by reading the PUF; that is, the Confidence Information provides an indication as to which elements of the PUF sequence demonstrate the most consistency across multiple interrogations, and which elements are more prone to variation. Those elements that show the most consistency in turn provide the most reliable bits of the PUF output to use during authentication. Those elements that have poor consistency may be discarded when performing the authentication process. The Confidence Information itself may be generated during enrolment and stored on the Authentication Server. The Confidence Information can then be provided to the PUF based device during later authentications. Alternatively, the Confidence Information can be generated during enrolment and stored on the PUF based device for use during later authentications. Depending on the type of PUF, Confidence Information may be regenerated each time the PUF output is read; in such cases, the Confidence Information need not be stored on either device. It will be appreciated that many existing PUFs do not have significant levels of inherent noise. In these cases, enrolment may take place without the need to obtain Confidence Information. Thus, obtaining Confidence Information can be seen as an optional, rather than essential part of the process. Nevertheless, the Confidence Information provides a useful addition in enabling embodiments to work with the widest range of PUFs. With continued reference to Figure 2, in a third step S203, the Authentication Server obtains a set of Challenge Response Pairs (CRPs), for use in authenticating the PUF based device. As discussed further below, the Authentication Server will use the CRPs during authentication to provide challenges to the device, and check the response received from the PUF based device against that which is expected. The CRPs may, for example, be based on an LPN (“Learning Parity with Noise”) construction, as discussed in a paper by Jin et al. (“FPGA Implementation of a Cryptographically-Secure PUF Based on Learning Parity With Noise” - Journal of Cryptography, 1(3): 23, 2017). The LPN construction allows for the protocol to be quantum safe, lightweight, and able to cope with PUF noise. The method may proceed as follows: The Authentication Server requests CRPs from the PUF-based device. The CRPs of are the form (c,r): (c = (y = As+e, i), r = h(s||i)), where: ‘A’ is a public matrix value provided by the Authentication Server. ‘e’ is the PUF output. Note that the value ‘e’ does not itself ever leave the PUF based device. If Confidence Information is being used, then the Confidence Information will need to be used to select the subset of output bits of the PUF that form e during enrolment. ‘||’ denotes string concatenation. ‘i’ is an optional counter value, used to ensure freshness of the challenge-response pair (if i is not used, it is omitted from c and r). ‘s’ is a secret value generated randomly by a random number generator. The value s may be generated by the PUF based device; alternatively, it may be generated by the Authentication Server and passed to the PUF based device. ‘h’ is a Key Derivation Function (KDF). In embodiments described herein, the value y that forms part of c may be reused across multiple challenges (assuming it is not compromised); this reduces the memory needed by the protocol. Having enrolled the PUF based device with the Authentication Server, the PUF based device may subsequently undergo authentication by the Authentication Server, using the CRPs. Figure 3 shows a flow-chart of steps used in authenticating the PUF based device. The Authentication Server commences the protocol by sending a ‘Hello’ message to the PUF based device (S301). This message may optionally contain details of the Authentication Server such as an identity value, VJd to allow the PUF based device to check the claimed identity and respond appropriately. For example, based on the value VJd, the PUF based device may select the correct ID and correct parameters to use, or else choose not to respond. In step S302, on receiving the ‘Hello’ message, the PUF based device verifies that details of the Authentication Server match those which it has registered. If not, the PUF based device terminates the protocol. If the PUF based device is registered with the Authentication Server, the PUF based device responds by sending a ‘Hello’ message that also includes its claimed identity ‘PJd’ to the Authentication Server (step S303). It will be appreciated in the above that step S302 is optional; that is, the PUF based device may respond with a ‘Hello’ message without necessarily verifying the details of the Authentication Server. In step S304, the Authentication Server verifies that the PUF based device has been enrolled (registered) with the Authentication Server, using the ‘P_id’ received from the PUF based device. If the PUF based device is not deemed to be enrolled, the Authentication Server terminates the protocol. In the event that the PUF based device is identified as having been enrolled, the Authentication Server now generates a challenge, using the CRPs previously obtained during the enrolment process. The Authentication Server sends the challenge to the PUF based device (step S305). The PUF based device receives the challenge and generates a response (step S306). At the same time, the PUF based device is able to verify the Authentication Server. The PUF based device sends the response to the Authentication Server (S307). In step S308, the Authentication Server receives the response from the PUF based device and uses the response to verify the PUF based device. If the response received from the PUF based device does not match the one expected by the Authentication Server, the PUF based device is not authenticated. With both the PUF based device and the Authentication Server having verified one another, the two compute a shared session key to be used in a communication session between the two devices. The session key may be computed as a function of one or more elements used in the generation of the challenge and / or response. In some embodiments, the session key generated at the end of the Authentication Protocol may be used to unlock software installed on the PUF based device. Thus, in embodiments described herein, one or more CRPs are generated using a PUF, with the CRPs in turn being used to prove the identity of PUF to an Authentication Server and vice versa. In addition to confirming the identity of the PUF-based device, the CRPs may be used in generating a session key for a communication session between the Authentication Server and PUF-based device once the two have confirmed each other’s identities. Figure 4 shows a more detailed flow-chart of steps involved in generating the challenge and response according to an embodiment In this sense, Figure 4 can be understood to illustrate one particular means for implementing steps S305 to S310 of Figure 3. The algorithm described in Figure 4 is quantum safe, in comparison to other algorithms that may not have this same property. Thus, this method provides future proofing in the event of a large-scale quantum computer being built. The process shown in Figure 4 commences with the Authentication Server having verified that the PUF based device is enrolled (see step S304 of Figure 3) and with the Authentication Server having knowledge of the (c, r) pairs (c = (y = As + e, i), r= h(s||i))). In step S401, if the counter i is used, the Authentication Server increments the counter value i associated with PJd, the unique identifier of the PUF-based device. The Authentication Server now selects a fresh Challenge Response Pair (c, r) containing the incremented i value (if used). Using the response rfrom the pair, the Authentication Server computes a Message Authentication Code (MAC) key r’ as h(r||O) (step S402). In step S403, the Authentication Server uses the key r’ to compute the Message Authentication Code (MAC) of challenge c and public parameters PP, if used. Here, the public parameters PP may include one or more of: (i) the Confidence Information (assuming the Confidence Information has been recorded and stored by the Authentication Server during the enrolment process); (ii) the counter i; and (iii) identifier VJd. In step S404, the Authentication Server sends the message (c, PP, MAC_r’(c||PP)) to the PUF based device. In step S405, the PUF based device receives the message (c, PP, MAC_r’(c||PP)) sent by the Authentication Server. If the counter i is used, the PUF based device first verifies the value of i is different from each value it has previously seen in association with the identifier VJd of the Authentication Server (step S406). If so, the PUF obtains the challenge c = y = As + e (step S407), and generates e’ (a noisy version of e) using its PUF (step S408). It will be appreciated that the value e is not “known” to the PUF based device per se; rather, the PUF-based device can only generate a noisy e, denoted here as e’. Optionally, the PUF based device may use the Confidence Information in generating e’, with the Confidence Information either being provided by the Authentication Server, or having been previously stored by the PUF based device or generated on the fly by the PUF based device. In step S409, the PUF based device seeks to recover the value s. To do so, the PUF based device obtains a candidate s’ from (y, A, e’) using Gaussian elimination (GE). In step S410, the candidate s’ is used to compute a candidate MAC key r’, where r = h(h(s’||i)||O) (excluding i if not used). The candidate r’ is in turn used for recomputing MAC_r’(c||PP) (step S411). In step S412, the PUF based device determines whether the value MAC_r’(c||PP) as computed in step S411 matches the value MAC_r’(c||PP)) received from the Authentication Server in step S405. If this check fails, or the initial counter check failed (if used), it is determined whether the number of authentication attempts equals a predetermined number N (step S413). If so, the protocol is terminated (step S414). If fewer than N authentication attempts have been made, the PUF based device may retry the procedure by returning to step S409 and generating a new candidate s’ using Gaussian Elimination, with steps S410 to S412 being repeated with the new candidate value s’. The process may be repeated until either the value MAC_r’(c||PP) computed in step S411 matches that received from the Authentication Server in step S405, or until the number of authentication attempts reaches N. Assuming the PUF based device is successful in reproducing the value MAC_r’(c||PP) received from the Authentication Server, the PUF based device will have authenticated the Authentication Server, since only the Authentication Server and PUF based device are assumed to know r’. If the counter i is used, then the PUF based device will have also authenticated the freshness of the message, by verifying that the counter i used by the Authentication Server is one that it has not previously received from the Authentication Server. Following this, the PUF based device computes and sends MAC_r’(P_id) to the Authentication Server (step S415). The Authentication Server computes and verifies the received MAC_r’(P_id) value (step S416). By doing so, the Authentication Server is able to verify that the sender is the PUF based device, since the PUF based device is the only other entity able to compute r’. If the MAC verification fails, the PUF based device is not authenticated. When both entities have verified each other, the two parties may compute the session key sk as h(h(s)||i|| 1) (steps S417, S418). It will be seen that the method above supports mutual authentication of both the Authentication Server and the PUF based device i.e. the two verify each other’s identity, rather than just supporting verification of the PUF based device’s identity as is the case in many conventional protocols. It will be appreciated that the precise algorithm shown in Figure 4 is one example of how steps S305 to S310 can be implemented, and other algorithms may also be implemented to achieve the same outcome of mutual authentication and a shared session key. For example, a variation on the LPN approach, such as Ring LPN or LWE (Learning With Errors) may be used. Each implementation will have the properties that: (i) The Authentication Server does not learn, and is unable, to derive the raw PUF outputs e; and (ii) Each CRP is independent, in the sense that knowledge of one or more CRPs does not allow other CRPs to be derived. The above features allow the proposed architecture to support multiple Authentication Servers that do not fully trust each other. Returning to Figure 2, in some embodiments, the process of enrolment may be performed again to generate new CRPs, which can be provided to the Authentication Server for use in future authentications; this may be especially important in the event it is determined that the existing set of CRPs has been used up or otherwise compromised. In addition to providing the Authentication Server with new CRPs, reenrolment provides an opportunity to obtain new measurements of PUF noise and Confidence Information. By doing so, the re-enrolment process can help to accommodate changes in the noise characteristics of a particular PUF over time, such as might happen if the PUF physically degrades or experiences environmental damage. The re-enrolment process may be performed remotely over a secure communications channel established at the end of the authentication process shown in Figures 3 and 4; this then enables a PUF based device to be re-enrolled whilst remaining deployed, and without manual intervention. In a further embodiment, the Authentication Server may perform a handover procedure whereby another Authentication Server is able to authenticate the PUF based device(s). This approach enables other Authentication Servers to authenticate devices directly, or to bootstrap their own registration of devices in a supply chain, and takes into account potential lack of trust between Authentication Servers. The process of handover or transferring enrolment can be understood by reference to Figure 5, which shows a sequence of interactions carried out between the PUF-based device 501, a first Authentication Server 503 and a second Authentication Server 505. Steps A and B of Figure 5 represent the process of enrolling the PUF based device with the first Authentication Server, and authenticating the PUF based device with the first Authentication Server, respectively. In step C, a subset of the CRPs obtained by the first Authentication Server 503 is securely provided to the second (receiving) Authentication Server 505. The transfer of the CRPs from the first Authentication Server 503 to the second Authentication Server 505 may be implemented in a number of ways, such as by secure file transfer, manual copying and re-entry, etc. Once the subset of CRPs have been transferred from the first Authentication Server 503 to the second Authentication Server 505, those CRPs may be marked as used by the first Authentication Server 503, meaning that they will not be used by the first Authentication Server in future authentications, and future sessions between the first Authentication Server 503 and the PUF based device 501 will not be accessible by the second Authentication Server 505. In step D, the PUF based device 501 and second Authentication Server 505 may use the transferred set of CRPs for authenticating one another. In a further optional procedure (step E), the PUF based device 501 may independently enrol with the second Authentication Server 505 using new material; that is, the PUF based device may issue a new set of CRPs to the second Authentication Server 505, with the first Authentication Server 503 having no knowledge of those new CRPs. The result of doing so is that the second Authentication Server 505 will have a new set of CRPs that it can use for future authentications of the PUF based device 501 (step F), whilst the first Authentication Server 503 has no knowledge of those CRPs, and is hence unable to access communications that are secured based on those new CRPs. Finally, as discussed above, the PUF based device 501, having already enrolled with the second Authentication Server 505, may subsequently re-enrol with the second Authentication Server 505 (step G), allowing for the transfer of further new CRPs to the second Authentication Server 505, as well as new measurements of PUF noise and Confidence Information. The steps shown in Figure 5 allow for handover of authentication support in a supply chain without the need for complex trust relationships to be established to manage confidential PUF related material. The supplying party (Authentication Server 503) can provide a subset of data to enable the receiver (Authentication Server 505) to either perform, or bootstrap, authentications. Compromise of material at the second Authentication Server 505 does not affect first Authentication Server 503 performing later authentications or establishing secure sessions, e.g. if device is returned for maintenance or recovery. Similarly, the second Authentication Server 505 is able to authenticate and set up secure sessions that are not accessible by the first Authentication Server 503. Thus, compromise of a particular CRP does not lead to compromise of other CRPS. Embodiments described herein provide a single purpose authentication solution supporting PUFs and PUF based devices that is reusable across many use cases and deployments. Embodiments can also help reduce the enrolment and memory requirements of the Authentication Server, compared with conventional methods. In contrast to conventional methods, which are typically limited to a specific type of device, such as a PUF embodied in a specific FPGA, embodiments described herein facilitate the authentication of a wide variety of different PUFs (e.g. taking into account how to obtain and use different types of “Confidence Information”, and cope with different noise levels in the PUFs), as well as allowing for PUF based devices to authenticate the Servers too. Embodiments as described herein are applicable to use cases involving highly constrained devices, and hence can support a wide range of use cases including loT. Embodiments do not require the use of error correction, commonly required to handle noise in such protocols produced by PUFs, and which adds performance overhead. The authentication protocols as described herein may also be carried out at orders of magnitude faster than conventional authentication protocols. Implementations of the subject matterand the operations described in this specification can be realized in digital electronic circuitry, or in computer software, firmware, or hardware, including the structures disclosed in this specification and their structural equivalents, or in combinations of one or more of them. Implementations of the subject matter described in this specification can be realized using one or more computer programs, i.e., one or more modules of computer program instructions, encoded on computer storage medium for execution by, or to control the operation of, data processing apparatus. Alternatively or in addition, the program instructions can be encoded on an artificially generated propagated signal, e.g., a machine-generated electrical, optical, or electromagnetic signal that is generated to encode information for transmission to suitable receiver apparatus for execution by a data processing apparatus. A computer storage medium can be, or be included in, a computer-readable storage device, a computer-readable storage substrate, a random or serial access memory array or device, or a combination of one or more of them. Moreover, while a computer storage medium is not a propagated signal, a computer storage medium can be a source or destination of computer program instructions encoded in an artificially generated propagated signal. The computer storage medium can also be, or be included in, one or more separate physical components or media (e.g., multiple CDs, disks, or other storage devices). While certain embodiments have been described, these embodiments have been presented by way of example only and are not intended to limit the scope of the invention. Indeed, the novel methods, devices and systems described herein may be embodied in a variety of forms; furthermore, various omissions, substitutions and changes in the form of the methods and systems described herein may be made without departing from the spirit of the invention. The accompanying claims and their equivalents are intended to cover such forms or modifications as would fall within the scope and spirit of the invention.

Claims

1. A method for authenticating a server to a client device, the client device comprising a Physical Unclonable Function PUF, the method comprising:5 generating, by the client device, one or more challenge-response pairs, whereinfor each pair, the challenge is obtained by computing a first function of a random number and a first readout of the PUF, and the response in the pair is obtained by computing a second function of the random number;sending the one or more challenge-response pairs to the server;10 receiving, by the client device, from the server:(i) a challenge from a selected one of the challenge-response pairs; and(ii) a first Message Authentication Code MAC computed by the server using the challenge and response in the selected challenge-15 response pair;obtaining, by the client device, a second readout of the PUF;computing, by the client device, a second MAC using the challenge received CM from the server and the second readout of the PUF; andIs**. in the event that the second MAC matches the first MAC, authenticating the20 server by the client device.1—2. A method according to claim 1, wherein:the first MAC is computed using a first MAC key, the first MAC key being computed by the server as a function of the response in the selected challenge-25 response pair; andthe second MAC is computed using a second MAC key, the second MAC key being computed by the client device using the second readout of the PUF.

3. A method according to claim 2, comprising:30 obtaining, based on the challenge received from the server and the secondreadout of the PUF, a candidate value for the random number; andcomputing the second MAC key as a function of the candidate value for the random number.35 4. A method according to claim 3, wherein in the event that the second MAC does notmatch the first MAC, the method further comprises:obtaining, based on the challenge received from the server, and the secondreadout of the PUF, a new candidate value for the random number; and re-computing, by the client device, the second MAC key as a function of the new candidate value for the random number.5 5. A method according to claim 4, wherein the client device continues to obtain newcandidate values for the random number and to re-compute the second MAC key using each candidate value, until either:(i) the MAC as computed by the client device using the second MAC key matches the first MAC or10 (ii) a predetermined number of attempts have been made to calculate a MACthat matches the first MAC but without success.

6. A method according to any one of the preceding claims, wherein in the event that the first MAC matches the second MAC, the method further comprises:15 sending an acknowledgement from the client device to the server using thesecond MAC key.

7. A method according to claim 6, wherein sending the acknowledgement to the server Is**. comprises encoding an identifier of the client device using the second MAC key.201— 8. A method according to claim 6 or 7, wherein upon verifying, by the server, that theacknowledgement is consistent with the challenge-response pair from which the challenge was selected, the client device is authenticated by the server.25 9. A method according to claim 8, wherein upon authenticating the client device by theserver, a session key is generated to be used for communication between the client device and the server, the session key being generated based on the random number used in generating the challenge-response pair.30 10. A method according to claim 9, comprising exchanging information between theclient device and the server, the information being confidentiality protected using the session key.

11. A method according to any one of claims 8 to 10, comprising:35 providing, by the client device, and after the client has been authenticated bythe server, one or more further challenge-response pairs to the server.

12. A method according to any one of the preceding claims, wherein the client device is enrolled with the server, the enrolment comprising:obtaining an estimate of a noise distribution of the PUF, wherein the noise distribution reflects an extent of variation in a digital output obtained when the PUF is 5 read out multiple times.

13. A method according to claim 12, wherein the enrolment further comprises: obtaining Confidence Information for the PUF, wherein the Confidence Information provides an indication as to which elements in the digital output remain10 consistent when the PUF is read out multiple times, the Confidence Information being used to select a portion of the digital output to be used in authenticating the client device at the server.

14. A method according to claim 12 or 13, wherein the client device is re-enrolled with 15 the server at a later point in time from the initial enrolment, the re-enrolmentcomprising:obtaining a new estimate of a noise distribution of the PUF andCM generating and issuing, by the client device, one or more new challenge-response pairs to the server.201— 15. A method according to any one of the preceding claims, wherein each challenge-response pair has a respective counter value, the client device receiving the counter value for the challenge-response pair from the server; andprior to computing the second MAC, the client device checks that the counter25 value is one that the client device has not previously received from the server.

16. A method according to claim 15, wherein:for each challenge-response pair:the challenge in the pair is obtained by computing the first function of the30 random number, the readout of the PUF and the respective counter value; and the response in the pair is obtained by computing the second function of the random number and the respective counter value.

17. A method according to any one of the preceding claims, wherein the first function is35 a pseudo-random function.

18. A method for authenticating a client device to a server, the client device comprising101520a Physical Unclonable Function PUF, the method comprising:receiving, by the server from the client device, one or more challenge-response pairs, wherein for each pair, the challenge is obtained by computing a first function of a random number and a first readout of the PUF, and the response in the pair is obtained by computing a second function of the random number;selecting, by the server, a challenge-response pair received from the client device;computing, by the server, a first Message Authentication Code MAC key as a function of the response in the selected challenge-response pair;computing, by the server, a first MAC using the first MAC key and the challenge in the selected challenge-response pair;sending, to the client device:(i) the challenge from the selected challenge-response pair; and(ii) the first MAC;receiving, from the client device, an acknowledgement generated using a second MAC key generated by the client device; andauthenticating the client device, based on the received acknowledgement.

19. A method according to any one of the preceding claims, wherein the PUF comprises a structural or functional feature of the client device that is capable of being interrogated to produce a read out of the PUF, the PUF read out comprising a digital output sequence that is unique to the client device.

20. The method of claim 18, wherein the server is a first authentication server and25 receives a plurality of challenge-response pairs from the client device, the method further comprising:forwarding a subset of the challenge response pairs to a second authentication server, the subset of challenge response pairs being marked as used by the first authentication server; and30 authenticating the client device at the second authentication server, using oneof the subset of challenge response pairs.

21. A computer-readable storage medium comprising computer executable instructions that when executed cause the computer to carry out a method according to any one of 35 the preceding claims.CM22. A computing device comprising one or more processors and configured to carry out a method according to any one of claims 1 to 20.

Images