WO2025229205A1

WO2025229205A1 - An authentication protocol

Info

Publication number: WO2025229205A1
Application number: PCT/EP2025/062120
Authority: WO
Inventors: Marc Xander MAKKES; Peter Antonius Henricus KNOBEN; Rahul Rakeshkumar VYAS; Stephane Thomas CHANTELOUP
Original assignee: Fortaegis Technologies Holding BV
Current assignee: Fortaegis Technologies Holding BV
Priority date: 2024-05-03
Filing date: 2025-05-02
Publication date: 2025-11-06
Anticipated expiration: 2026-11-03

Abstract

The present disclosure relates to a method of establishing a secure channel between at least two clients which comprises, at an initiating client: retrieving an initiating challenge-response pair and sending a first message which comprises the initiating challenge; at the responding client: isolating the initiating challenge from the received first message and stimulating the PUF of the responding client with the isolated initiating challenge to obtain the first PUF response; at the responding client: retrieving a responding challenge-response pair, generating a shared key from the responding response and the PUF response, and transferring a second message which comprises the responding challenge to the initiating client; and at the initiating client: isolating the responding challenge from the received second message, stimulating the PUF of the initiating client with the responding challenge to obtain a second PUF response, and generating the shared key from the second PUF response and the initiating response.

Description

AN AUTHENTICATION PROTOCOL

FIELD

The present disclosure relates to the field of Physical Unclonable Functions (PUFs).

Physical Unclonable Functions (PUFs) are physical objects that are unique, practically unclonable and that behave like a random function or response when subjected to or stimulated with a challenge. Their use has been proposed for authentication tokens and anti -counterfeiting. A Controlled PUF (CPUF) consists of a PUF and a control layer that restricts a user’s access to the PUF input and output. CPUFs can be used for secure key generation and storage, authentication, certified execution of programs, and certified measurements.

BACKGROUND

In the prior art, numerous modifications are known for protocols involving PUFs and CPUFs.

A Physical Unclonable Function (PUF) refers to a function that is implemented as a physical system in such a way that the output for an input is obtained by applying the input stimulus to the physical system and observing the resulting behaviour. The interaction between the stimulus and the physical system is unpredictable, depending on essentially random elements within the physical system. This makes it impossible to obtain the output without having had direct access to the physical system, and also renders it impractical to reproduce the physical system itself. PUFs are typically low in manufacturing costs and easy to evaluate for practical applications.

Conventionally, an input or stimulus that a PUF accepts is called a challenge. The output of a PUF, that is, the behaviour the PUF exhibits after interaction with the stimulus, is called a response. A pair comprising a challenge and the corresponding response of a PUF is called a challenge-response pair. Some types of PUFs allow a wide range of different inputs, some types allow a more limited range of inputs, or may even allow only a single input. The property that the PUF produces the same response to a challenge c that is presented multiple times, is preferable, but not necessary and, in practice, most PUFs do not possess it. As long as the multiple responses are sufficiently close to each other, the PUF can be usefully applied.

Since the interaction between a stimulus and the physical system cannot be predicted without access to the system, the PUF is hard to characterize and therefore to model. The output of a particular PUF for an input can therefore only be obtained using the particular physical system underlying the particular PUF. Possession of a challenge-response pair is proof that at some point the challenge was offered to the unique physical system that underlies the PUF. Because of this property, i.e., the property that challenge-response pairs are coupled to a unique physical device, a PUF is called unclonable. By equipping a device with a PUF, the device also becomes unclonable.

A Controlled PUF (CPUF) comprises a PUF and a control layer that restricts a user’s access to the PUF input and output. The CPUF is especially beneficial if a system has multiple users or sessions accessing the same computational device. Different types of CPUFs exist. As a first example, WO 03/090259 A2 describes the control layer creating a hash of a program to be executed on the system which wants to access the PUF and providing a response to a challenge or pre-challenge that depends on this hash.

As a second example, the paper ‘Flowchart description of security primitives for Controlled Physical Unclonable Functions’, International Journal of Information Security, Vol. 9, pages 327 - 335, of August 3, 2010, is referenced here, where a number of protocols involving PUFs and CPUFs are presented to improve security. Modifications therein mainly consist of encryption of a larger portion of the message traffic, and additional restrictions on the PUF / CPUF accessibility. Furthermore, it was explicitly set out how the helper data for the PUFs is handled. Further this paper discloses a CPUF which allows access to PUF functionality only when a secure channel has been established. All communications and iterations need to pass through the secure channel handler. Everything that happens within the CPUF is considered secure against invasive attacks.

Reference is made here to Eee, SW., Safkhani, M., Ee, Q. et al. in ‘Designing secure PUF- based authentication protocols for constrained environments’ Sci Rep 13, 21702 (2023). https://doi.org/10.1038/s41598-023-48464-z. Therein an improvement is proposed relative to the disclosure of Roy, S. et al. in ‘PLAKE: PUF-based secure lightweight authentication and key exchange protocol for IOT’, IEEE Internet Things J. 10, 8547-8559. https://doi.Org/10.l 109/ JIOT.2022.3202265 (2023). Protocols according to both papers work on the principle that node 1 acts as a server who has a Challenge Response Pair ‘CRP’ of the client (node 2) and clients comprises a challenge-response PUF that can generate a unique response for a unique challenge.

Node 2 sends a request to node 1 with a random salt (Rs). Node 1 responds by sending an encrypted message comprising 3 parts, first the (Y s) challenge encrypted with random salts from both the nodes (Rs and Rc), second the random salt from the second node (Rc) and third, a hashed value (Vs) based on the challenge, response and the helper data.

The node 2 extracts the challenge and helper data from the Ys. Then it produces the Response from the PUF based on the extracted challenge. This information is used to compute its own Vs’. If Vs’ matches with the Vs sent by node 1 then the node 1 (server) is authenticated by node 2 (client).

Now the node 2 (client) generates a new Challenge from on a hashed output based on previous CRP and help data and the random salts from both the nodes. This new challenge is then used to extract a new response from the PUF. Now the node 2 (client) sends a new encrypted message encrypted with the random salts (Rs and Rc) previous CRP, the new PUF response and the helper data.

If the message integrity remains then the node 1 (server) is able to decrypt the message and extract the new response and the helper data. Node 1 then calculates the new challenge based on previous CRP and the helper data (the same way as done by node 2). Hence, this new CRP is replaced by the previous CRP in node 1’s memory. This method works on the premise that the server is a secured node and can be fully tested by the client. Hence, it’s the client that authenticates the server and, therefore, this is less secure while also being computationally quite expensive in terms of e.g. system load.

Additionally, reference is made here to Bracken, A. in ‘PUF Based Authentication Protocol for IoT’, Symmetry 2018, 10, 352. https:// doi.org/10.3390/syml0080352. Protocols according to this paper function on the basis of a similar process described in the above referenced paper. The difference is that according to this paper, two nodes (clients) communicate with each other via a trusted server. Both nodes use PUF to authenticate messages based on challenges proved by the server. Therefore these known protocols are also examples of one way authentication, where the server is not a PUF based device and is a tested node in the network, which is computationally quite expensive in terms of e.g. system load and also inherently less secure.

The paper "PUF based Authentication and Key Sharing Protocol for Smart Water Monitoring System" by Roy Sourav et al., published in 2022 IEEE Region 10 Symposium (TENSYMP), pages 1- 6, published on 1 July 2022, describes an authentication and key sharing protocol for smart water monitoring systems (SWMS) using Physically Unclonable Functions (PUFs). The proposed protocol involves a PUF module embedded in the controller devices within the water tank, performing authentication between the central server and a controller using two challenge-response pairs (CRPs). It employs a mathematical PUF model on the server to minimize server-side storage requirements.

US 2023/032099 Al describes a method for mutual authentication and key exchange between two endpoint nodes using physical unclonable functions (PUFs). Initially, a first endpoint node generates a cryptographic nonce and sends it to a second endpoint node. Both nodes use a predetermined challenge on their PUF circuits to generate responses, from which intermediary secret values are derived. The second node encrypts the initial nonce and session key material using its intermediary secret value and sends it back to the first node. The first node decrypts this message, authenticates the second node by comparing nonces, and then uses a key mask to derive a second intermediary secret value. It generates a second ciphertext and sends it to the second node, and finally, both nodes generate a session key from their session key materials for encrypted communication

CN 113839782 B describes a lightweight secure communication method for a Controller Area Network (CAN) bus in a vehicle based on Physical Unclonable Functions (PUF). The method involves establishing a session key on the in-vehicle CAN bus for secure bus communication. For unregistered external equipment, the method includes registering identity information on an in-vehicle gateway ECU and negotiating a key. Registered external devices can then log into the in-vehicle CAN bus using their identity information and secret key. SUMMARY

The system according to the present disclosure provides improvements over the prior art.

A system according to the present disclosure comprises at least two clients configured to establish a secure channel there between, each client comprising: a physically unclonable function ‘PUF’; a communication interface; a memory comprising at least a challenge-and-response pair ‘CRP’; and at least one processor, and respectively configured to:

- at an initiating client: retrieve an initiating CRP from memory, the initiating CRP including an initiating challenge and an initiating response, generate a first message, and send the first message to responding client, the first message comprising the initiating challenge;

- at the responding client: receive the first message from initiating client, isolate the initiating challenge from the first message, and stimulate the PUF of the responding client with the isolated initiating challenge to obtain the first PUF response;

- at the responding client: retrieve a responding CRP from memory, the responding CRP including a responding challenge and a responding response, generate a shared key from the responding response and the PUF response, and transfer a second message to the initiating client, the second message comprising the responding challenge; and

- at the initiating client: receive the second message, isolate the responding challenge from the second message, stimulate the PUF of the initiating client with the responding challenge to obtain a second PUF response, and generate the shared key from the second PUF response and the initiating response, wherein information transmitted from the initiating client to the responding client and/or information transmitted from the responding client to the initiating client is encrypted with the shared key.

The system may be configured to, at the initiating client: generate a first random number, encrypt the first random number using the initiating response to generate a first value, and include the first value in the first message, at the responding client: isolate the first value from the first message; decrypt the first value using the PUF response as key resulting in at least a third random number, encrypt, using the obtained shared key, the decrypted third random number in a second value, and include the second value in the second message, and at the initiating client: isolate the second value from the second message and decrypt, using the obtained shared key, the second value, resulting in at least a fourth random number. The secure channel is established in dependence on the first random number being equal to the fourth random number.

The system may be configured to, at the responding client: generate a second random number; encrypt, using the obtained shared key, the decrypted third random number and the second random number in the second value, at the initiating client: decrypt, using the obtained shared key, the second value, resulting in at least the fourth random number and a fifth random number, encrypt, using the obtained shared key, the first random number and/or the fifth random number in a third message, and send the third message to responding client, and at the responding client: receive the third message from the initiating client and decrypt the third message using the obtained shared key, resulting in a sixth random number and/or a seventh random number. The secure channel is established in dependence on the sixth random number being equal to the third random number and/or in dependence on the seventh random number being equal to the second random number.

The initiating client and the responding client may each comprise a random number generator ‘RNG’, configured to generate a true random number or a pseudo-random number.

The system may be configured to, at the initiating client: encrypt the initiating challenge using the initiating response to generate a first value and combine the initiating challenge and the first value to generate the first message, at the responding client: isolate the initiating challenge and the first value from the first message, decrypt the first value using the PUF response as key resulting in at least an assumed initiating challenge, encrypt, using the obtained shared key, the responding challenge in a second value, and combine the second value with the responding challenge in the second message, and at the initiating client: isolate the responding challenge and the second value from the second message, decrypt, using the obtained shared key, the second value resulting in at least an assumed responding challenge. The secure channel is established in dependence on the assumed initiating challenge being equal to the initiating challenge received by the responding client and the assumed responding challenge being equal to the responding challenge received by the initiating client.

The system may be configured to, at the responding client: generate a digest from the responding response and the PUF response with a cryptographic hash function to obtain the shared key; and at the initiating client: generate a digest from the initiating response and the second PUF response with the cryptographic hash function to obtain the shared key.

Each of the first and second CRPs may comprise helper data ’011 2' in addition to challenge and response.

The system may be configured to, at the initiating client: encrypt the initiating challenge and initiating helper data using the initiating response to generate the first value and combine the initiating challenge, the initiating helper data, and the first value in the first message, at the responding client: isolate the initiating challenge, the initiating helper data, and the first value from the first message; decrypt the first value using the PUF response as key resulting in at least the assumed initiating challenge and assumed initiating helper data, encrypt, using the obtained shared key, the responding challenge and responding helper data in the second value, and combine the second value with the responding challenge and responding helper data in the second message, and at the initiating client: isolate the responding challenge, responding helper data, and the second value from the second message, and decrypt, using the obtained shared key, the second value resulting in at least an assumed responding challenge and assumed responding helper data.

The secure channel is established in dependence on the assumed initiating challenge and the assumed initiating helper data being equal to the initiating challenge and the initiating helper data received by the responding client and the assumed responding challenge and the assumed responding helper data being equal to the responding challenge and the responding helper data received by the initiating client.

The system may be configured to generate an eighth random number at the responding client to generate at least one new CRP for use with the responding client and/or generate a ninth random number at the initiating client to generate at least one new CRP for use with the initiating client.

The responding client may be configured to, after receipt of the first message, generate the at least one new CRP comprising a third challenge, optional third helper data, and a third response from the eighth random number, and encrypt a combined value thereof, using the obtained shared key, in a second value.

The initiating client may be configured to, after receipt of the second message, generate the at least one new CRP comprising a fourth challenge, optional fourth helper data, and a fourth response from the ninth random number, and encrypt a combined value thereof, using the obtained shared key, in a third message.

The present disclosure also relates to a method of establishing a secure channel between at least two clients, each client comprising a physically unclonable function, the method comprising:

- at an initiating client: retrieving an initiating challenge-and-response pair ‘CRP’ from memory, the initiating CRP including an initiating challenge and an initiating response, generating a first message, and sending the first message to responding client, the first message comprising the initiating challenge;

- at the responding client: receiving the first message from initiating client, isolating the initiating challenge from the first message, and stimulating the PUF of the responding client with the isolated initiating challenge to obtain the first PUF response;

- at the responding client: retrieving a responding CRP from memory, the responding CRP including a responding challenge and a responding response, generating a shared key from the responding response and the PUF response, and transferring a second message to the initiating client, the second message comprising the responding challenge; and

- at the initiating client: receiving the second message, isolating the responding challenge from the second message, stimulating the PUF of the initiating client with the responding challenge to obtain a second PUF response, and generating the shared key from the second PUF response and the initiating response, wherein information transmitted from the initiating client to the responding client and/or information transmitted from the responding client to the initiating client is encrypted with the shared key.

Thus, a system as described above and hereinafter may be controlled using this method. The method may be executed, for example, by the data processing system described above and hereinafter. Moreover, a computer program for carrying out the methods described herein, as well as a non- transitory computer readable storage-medium storing the computer program are provided. A computer program may, for example, be downloaded by or uploaded to an existing device or be stored upon manufacturing of these systems.

In one aspect, a non-transitory computer-readable storage medium stores a software code portion, the software code portion, when executed or processed by a computer, being configured to perform the method described above.

As will be appreciated by one skilled in the art, aspects of the present invention may be embodied as a device, a method or a computer program product. Accordingly, aspects of the present invention may take the form of an entirely hardware embodiment, an entirely software embodiment (including firmware, resident software, micro-code, etc.) or an embodiment combining software and hardware aspects that may all generally be referred to herein as a "circuit", "module" or "system." Functions described in this disclosure may be implemented as an algorithm executed by a processor/microprocessor of a computer. Furthermore, aspects of the present invention may take the form of a computer program product embodied in one or more computer readable medium(s) having computer readable program code embodied, e.g., stored, thereon.

Any combination of one or more computer readable medium(s) may be utilized. The computer readable medium may be a computer readable signal medium or a computer readable storage medium. A computer readable storage medium may be, for example, but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any suitable combination of the foregoing. More specific examples of a computer readable storage medium may include, but are not limited to, the following: an electrical connection having one or more wires, a portable computer diskette, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or Flash memory), an optical fiber, a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing. In the context of the present invention, a computer readable storage medium may be any tangible medium that can contain, or store, a program for use by or in connection with an instruction execution system, apparatus, or device.

A computer readable signal medium may include a propagated data signal with computer readable program code embodied therein, for example, in baseband or as part of a carrier wave. Such a propagated signal may take any of a variety of forms, including, but not limited to, electro-magnetic, optical, or any suitable combination thereof. A computer readable signal medium may be any computer readable medium that is not a computer readable storage medium and that can communicate, propagate, or transport a program for use by or in connection with an instruction execution system, apparatus, or device.

Program code embodied on a computer readable medium may be transmitted using any appropriate medium, including but not limited to wireless, wireline, optical fiber, cable, RF, etc., or any suitable combination of the foregoing. Computer program code for carrying out operations for aspects of the present invention may be written in any combination of one or more programming languages, including an object oriented programming language such as Java(TM), Rust, C++ or the like and conventional procedural programming languages, such as the "C" programming language or similar programming languages. The program code may execute entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer, or entirely on the remote computer or server. In the latter scenario, the remote computer may be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or the connection may be made to an external computer (for example, through the Internet using an Internet Service Provider).

Aspects of the present invention are described below with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the present invention. It will be understood that each block of the flowchart illustrations and/or block diagrams, and combinations of blocks in the flowchart illustrations and/or block diagrams, can be implemented by computer program instructions. These computer program instructions may be provided to a processor, in particular a microprocessor or a central processing unit (CPU), of a general purpose computer, special purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer, other programmable data processing apparatus, or other devices create means for implementing the fimctions/acts specified in the flowchart and/or block diagram block or blocks.

These computer program instructions may also be stored in a computer readable medium that can direct a computer, other programmable data processing apparatus, or other devices to function in a particular manner, such that the instructions stored in the computer readable medium produce an article of manufacture including instructions which implement the fimction/act specified in the flowchart and/or block diagram block or blocks.

The computer program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other devices to cause a series of operational steps to be performed on the computer, other programmable apparatus or other devices to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide processes for implementing the fiinctions/acts specified in the flowchart and/or block diagram block or blocks.

The flowchart and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of devices, methods and computer program products according to various embodiments of the present invention. In this regard, each block in the flowchart or block diagrams may represent a module, segment, or portion of code, which comprises one or more executable instructions for implementing the specified logical fiinction(s). It should also be noted that, in some alternative implementations, the functions noted in the blocks may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams and/or flowchart illustrations, and combinations of blocks in the block diagrams and/or flowchart illustrations, can be implemented by special purpose hardware-based systems that perform the specified functions or acts, or combinations of special purpose hardware and computer instructions.

BRIEF DESCRIPTION OF THE DRAWING

These and other aspects of the invention are apparent from and will be further elucidated, by way of example, with reference to the drawings, in which:

FIG. 1 exhibits an example of a client used in the present disclosure;

FIG. 2 exhibits a schematic flowchart of mutual authentication between CPUFs;

FIG. 3 exhibits a schematic flowchart of mutual authentication between CPUFs with helper data; and

FIG. 4 exhibits a schematic flowchart of mutual authentication between CPUFs with helper data and a renewal function.

Corresponding elements in the drawings are denoted by the same reference numeral.

DETAILED DESCRIPTION OF EMBODIMENTS

Fig. 1 shows a block diagram of a client 1 for establishing a secure channel with another client 2, which is the same as client 1 in Fig. 1, but may also be different, although it should at least comprise a PUF or CPUF. The shown embodiment of client 1 comprises a CPUF chip 11, which may also be a PUF chip, as will become apparent from the below embodiment description. The client 1 and/or the CPUF chip 11 comprises one or more processors 5, e.g. one or more computer cores, an input interface 3, an output interface 4, a physically unclonable function (PUF) 6, a memory 7, and one or more cryptographic accelerators 8. The input interface 3 and output interface 4 may be realized by a network interface, and/or may be integrated into a single component or functional unit.

The one or more processors 5 are configured to establish, via the at least one input interface 3 and/or output interface 4, together defining a communication interface, in cooperation with the other client 2, a secure channel which is based on below disclosed exemplary embodiments.

A first implementation of the method of establishing secure channels between client 1 and client 2 is shown in Fig. 2. The method may be performed by client 1 of Fig. 1, for example, and another similar or different client 2 having at least its own PUF 6.

In FIG. 2, a mutual authentication protocol according to the present disclosure is shown in a flow diagram. For the protocol to attain a certain level of security, it is assumed that client 1 and client 2 are strong PUFs, but the method according to the present disclosure may also be deployed to realize improvements in security in case of weak PUFs, which generate a relatively small number of challenge-response pairs. For the sake of brevity, and to promote comprehensibility of FIG. 2 and the below description thereof, as well as the underlying principles, only two clients, client 1 and client 2 are shown, but the method may involve any number of clients. For the below description of the protocol in FIG. 2, it’s assumed that some form of controller has set a Challenge Response Pair ‘CRP’ on each client, prior to initiation of the protocol.

The CRP can be split into a Challenge (C) part and a Response (R) part and together form a pair. It is assumed that the chips have a (pseudo) random number generator ‘RNG’ and a PUF.

Client: (i.e., a chip or a communication device) generates a random number Ti from a seed Si. Client2 (a same or similar device as Client:) generates a random number T2 from a seed S2.

Client; encrypts challenge C2 and random number Ti in value Ui with a known symmetric key algorithm using the response R2, and concatenates value Ui with challenge C2 in a message Mi . Message Mi is transferred over a public channel to Client2.

Client2 splits message Mi into challenge C2 and value Ui, and stimulates PUF2 with challenge C2to get response R2’. Then, response R2’ is used as key to decrypt value Ui which results in challenge C2’ and random number T This enables Client2 to validate that Client; has knowledge of a CcoR pair of the PUF of Client2, by comparing if the challenge C2 is equal to challenge C2’. Because a random number is included in the encrypted message, the encrypted message will be different every time.

If the challenge C2 and the challenge C2’ are different, Client2 will stop the protocol and no secure channel will be established.

If, on the other hand, challenge C2’ is equal to challenge C2, the protocol is continued and Client2 generates a digest from Ri and R2’ with a known cryptographic hash function. By using a hash function, machine learning attacks to the PUF may be prevented. This digest is the shared key R.

Client2 encrypts challenge Ci, random number T and random number T2 in value U2 using the shared key R, and concatenates value U2 with challenge C; in a message M2. Message M2 is transferred over the public channel to Client; .

Client: splits message M2 into value U2 and challenge Ci, and stimulates PUFi with challenge C: to get response R . Then, Client: generates a digest from response R;’ and response R2 with the above-mentioned known cryptographic hash function, which yields the shared key R, and decrypts value U2 into challenge C;’, random number Ti” and random number T2’ using the shared key R. The cryptograph hash function performed by Client; is the same function as the cryptographic hash function performed by Client2.

At this point Client; can verify that random number Ti ” is equal to random number Ti, and knows that key R is in fact shared, i.e. both clients use the same key.

Client: verifies that challenge Ci’ is equal to challenge C: and that random number Ti” is equal to random number Ti If they are not equal, the protocol will stop and no secure channel will be established. If, on the other hand, the protocol is continued, to allow Client2 to verify that it has the correct shared key R, Client: encrypts random number Ti and random number T2’ using shared key R, and the result is message M3, which is transferred over the public channel to Client2.

Client2 decrypts message M3 in random number Ti ” ’ and random number T2” using shared key R and verifies that Client2has the correct shared key R, by comparing random number Ti’” to random number Ti ’ and by comparing random number T2” to random number T2. After this verification, the secure channel is (considered) established. Shared key R may then be used to encrypt and decrypt information transmitted over the secure channel.

As a result, the method requires only 3 encryptions, 3 decryptions, 2 hashes, 2 (pseudo) random numbers being generated, and 3 messages sent between client 1 and client 2. Consequently, the algorithm according to the present disclosure is computationally less expensive than any prior art protocol in terms of e.g. system load, while security is increased.

The protocol shown in FIG. 3 is for CPUFs that use helper data. For the below description of the protocol in FIG. 3, it’s assumed that some form of controller has set a CcoR pair on each client, prior to initiation of this embodiment of the protocol according to the present disclosure, e.g., by a controller. The CcoR pair can be split into a Challenge (C) part, a Helper data (co) part and a Response (R) part. Since CcoR pair has three components, a more correct reference may be to a ‘grouping’ instead of a pair, but a ‘pair’ is the customary expression.

The Response part and the Helper data of a CcoR pair are typically generated at an earlier stage by providing a PUF with the Challenge part. The Challenge part may be randomly generated at that moment. The resulting CcoR pair is associated with the client that comprises the PUF, because the Response part can only be regenerated on this PUF, and then sent, e.g., by a controller, to another client for establishing a secure channel with this client.

When a PUF is provided with a challenge, it will typically provide noisy output data. To ensure that the PUF produces a Response part that is always the same if it is provided the same Challenge part, a Fuzzy Extractor may be used. A Fuzzy Extractor, also known as a helper data scheme, was introduced as a primitive that achieves both information reconciliation and privacy amplification. As part of this helper data scheme, the noisy output data from the PUF is provided to a generate (GEN) function, which then provides the response and the helper data. The helper data allows a reproduce (REP) function to reconstruct this original response of the PUF from new noisy output data of the PUF.

For the below description of the protocol in FIG. 3, it’s assumed that the clients have a (pseudo) random number generator (P)RNG and a cPUF. As described earlier, a Controlled PUF (cPUF) comprises a PUF and a control layer that restricts a user’s access to the PUF input and output.

Client: (i.e., a chip or a communication device) generates a random number T: from a seed Si. Client2 (a same or similar device as Client:) generates a random number T2 from a seed S2. Client: encrypts challenge C2, helper data CO2 and random number Ti in value Ui with a known symmetric key algorithm using the response R2, and concatenates value Ul with challenge C2 and helper data C02 in a message Mi. Message Mi is transferred over the public channel to Client2.

Client2 splits Message Mi into challenge C2, helper data C02 and value Ui and stimulates CPUF2 with challenge C2 and helper dataco2 to get response R2’. This stimulation typically involves performing a reproduce (REP) function, as described earlier. Then, response R2’ is used as key to decrypt value Ui which results in challenge C2’, helper data C02’ and random number T . This enables Client2 to validate that Clienti has knowledge of a CcoR pair of the PUF of Client2, by comparing if the challenge C2 and helper data C02 are equal to challenge C2’ and helper dataco2’. Because a random number is included in the encrypted message, the encrypted message will be different every time.

If the challenge C2 and the challenge C2’ or the helper data C02 and the helper data C02’ are different, Client2 will stop the protocol and no secure channel will be established.

If, on the other hand, the challenge C2 is equal to the challenge C2’, and the helper data C02 is equal to the helper data C02’, the protocol is continued and Client2 generates a digest from Ri and R2’ with a known cryptographic hash function. By using a hash function, machine learning attacks to the PUF may be prevented. This digest is the shared key R.

Client2 encrypts challenge Ci, helper data coi , random number Ti ’ and random number T2 in value U2 using the shared key R, and concatenates value U2 with challenge Ci and helper data coi in a message M2. Message M2 is transferred over the public channel to Clienti.

Clienti splits message M2 into challenge Ci, helper datacoi and value U2 and stimulates cPUFi with challenge Ci and helper datacoi to get response R . This stimulation typically involves performing a reproduce (REP) function, as described earlier. Then, Clienti generates a digest from Ri ’ and R2 with the above-mentioned cryptographic hash function, which yields the shared key R, and Clienti decrypts value U2 into challenge Ci’, helper data coi’, random number Ti” and random number T2’ using the shared key R. The cryptograph hash function performed by Clienti is the same function as the cryptographic hash function performed by Client2.

At this point Clienti can verify that random number Ti ” is equal to random number Ti, and knows that key R is in fact shared, i.e. both clients use the same key.

Clienti verifies that challenge Ci’ is equal to challenge Ci, that helper data coi ’ is equal to helper data coi and that random number Ti” is equal to random number Ti If they are not equal, the protocol will stop and no secure channel is established.

If, on the other hand, the protocol is continued, to allow Client2 to verify that it has the correct shared key R, Clienti encrypts random number Ti and random number T’2 using shared key R, and the result is message M3, which is transferred over the public channel to Client2.

Client2 decrypts message M3 in random number Ti ” ’ and random number T2” using shared key R and verifies that Client2has the correct shared key R, by comparing random number Ti’” to random number T and by comparing random number T2” to random number T2. As a result, the method requires only 3 encryptions, 3 decryptions, 2 hashes, 2 (pseudo) random numbers being generated, and 3 messages sent between client 1 and client 2. Consequently, the algorithm according to the present disclosure is computationally less expensive than any prior art protocol in terms of e.g. system load, while security is increased.

The protocol shown in FIG. 4 adds a renew function to the protocol of FIG. 3. The same renew function may be added to the protocol of FIG. 2. For the below description of the protocol in FIG. 4, it’s assumed that some form of controller has set a Challenge Response Pair ‘CRP’ on each client, specifically a CcoR pair in the embodiment of Fig. 4, prior to initiation of this embodiment of the protocol according to the present disclosure. The CcoR pair can be split into a Challenge (C) part, a Helper data (co) part and a Response (R) part. For the below description of the protocol in FIG. 4, it’s assumed that the clients have a (pseudo) random number generator RNG and a cPUF.

Client: (i.e., a chip or a communication device) generates a random number Ti from a seed Si and a random number T4 from a seed S4. Client2 (a same or similar device as Client:) generates a random number T2 from a seed S2 and a random number T3 from a seed S3.

Client; encrypts challenge C2, helper data CO2 and random number T: in value Ui with a known symmetric key algorithm using the response R2, and concatenates value Ui with challenge C2 and helper data C02 in a message Mi. Message Mi is transferred over the public channel to Client2.

Client2 splits Message Mi into challenge C2, helper data C02 and value Ui and stimulates CPUF2 with challenge C2 and helper dataco2to get response R2’. This stimulation typically involves performing a reproduce (REP) function, as described earlier. Then, response R2’ is used as key to decrypt value UI which results in challenge C2’, helper data co2’ and random number Tl’. This enables Client2 to validate that Client; has knowledge of a CcoR pair of the PUF of Client2, by comparing if the challenge C2 and helper data C 2 are equal to challenge C2’ and helper data co?'. Because a random number is included in the encrypted message, the encrypted message will be different every time.

If the challenge C2 and the challenge C2’, and the helper data C 2 and the helper data C 2’ are different, Client2 will stop the protocol and no secure channel will be established.

If, on the other hand, the challenge C2 is equal to the challenge C2’, and the helper data C 2 is equal to the helper data C02’, the protocol is continued and Client2 generates a digest from Ri and R2’ with a known cryptographic hash function. By using a hash function, machine learning attacks to the PUF may be prevented. This digest is the shared key R.

Client2 generates a new challenge C3, helper dataov and response R3 from random number T3 using the GEN function. Generating this CcoR pair may involve generating the challenge C3 from the random number T3 or using random number T3 as challenge C3, providing the challenge C3 to the PUF, and providing the noisy output data generated by the PUF to the GEN function, which then produces the helper dataov and the response R3, as described earlier. Clients concatenates the value of challenge Cs, helper dataov and response Rs which results in value Vi.

Clients encrypts challenge Ci, helper data co: .value Vi, random number T and random number T2 in value U2 using the shared key R, and concatenates value U2 with challenge Ci and helper data coi in a message M2. Message M2 is transferred over the public channel to Client:.

Client: splits message M2 into challenge Ci, helper data co: and value U2 and stimulates cPUF: with challenge Ci and helper dataco: to get response R . This stimulation typically involves performing a reproduce (REP) function, as described earlier. Then, Client: generates a digest from R: ’ and R2 with the above-mentioned cryptographic hash function, which yields the shared key R, and decrypts value U2 into challenge C:’, helper data co , value V:’, random number Ti” and random number T2’ using the shared key R. The cryptograph hash function performed by Client: is the same function as the cryptographic hash function performed by Client2.

At this point Client: can verify that random number Ti” is equal to random number Ti, and knows that key R is in fact shared, i.e. both clients use the same key.

Client: verifies that challenge C: ’ is equal to challenge C: and that helper data co: ’ is equal to helper data co:. If they are not equal, the protocol will stop and no secure channel is established.

If, on the other hand, the protocol is continued, Client: splits value V:’ into challenge C3’, helper dataov and response R3’, which is the new CcoR pair generated just before by Client2. Thus this new CcoR pair associated with Client2 can be used by Client: when establishing a secure channel with Client2.

Client: generates a new challenge C4, helper data C 4 and response R^from random number T4 using the GEN function. Generating this CcoR pair may involve generating the challenge C4 from the random number T4 or using random number T4 as challenge C4, providing the challenge C4 to the PUF, and providing the noisy output data generated by the PUF to the GEN function, which then produces the helper dataco4 and the response R4, as described earlier.

Client: concatenates the value of challenge C4, helper dataco4 and response R4, which results in value V 1.

Client: encrypts value V2 and random number T2’ in message M3 using the shared key R, which message M3 is transferred over the public channel to Client2.

Client2 decrypts message M3 into random number T2” and value V2’ using shared key R and verifies that Client2has the correct key, by comparing random number T2” to random number T2. Finally, after verifying that it has the correct key, Client2 splits value V2’ into the new challenge C4, helper data C04 and response R4, which is the new CcoR pair generated just before by Client: . Thus this new CcoR pair associated with Client: can be used by Client2 when establishing a secure channel with Client: .

As a result the method requires only 3 encryptions, 3 decryptions, 2 hashes, 2 generate functions, 4 (pseudo) random numbers being generated, and 3 messages sent between client 1 and client 2. Consequently, the algorithm according to the present disclosure is computationally less expensive than any prior art protocol in terms of e.g. system load, while security is increased.

Once the secure channel has been established, the clients 1 and 2 may be used for applications like decryption/encryption of data on external storage means, creation of public keys/signatures, signing of data, and verification of signatures, for example. Like PUFs and CPUFs in general, the clients 1 and 2 may also be used for authentication, certified execution of programs, creation of proof- of-execution, and certified measurements, for example. Certified execution of programs means that the PUF or CPUF can only be accessed by programs. The process of creating proof-of-execution is a process that produces, together with a computation output, a certificate (called e-certificate) which proves to the user of a specific processor chip that a specific computation was carried out on that specific processor chip, and that the computation was executed and produces the given computed output.

Various embodiments of the invention may be implemented as a program product for use with a computer system, for implementing steps of the disclosed method and closely associated therewith, where the program(s) of the program product define functions of the embodiments (including the methods described herein). In one embodiment, the program(s) can be contained on a variety of non- transitory computer-readable storage media, where, as used herein, the expression “non-transitory computer readable storage media” comprises all computer-readable media, with the sole exception being a transitory, propagating signal. In another embodiment, the program(s) can be contained on a variety of transitory computer-readable storage media. Illustrative computer-readable storage media include, but are not limited to: (i) non-writable storage media (e.g., read-only memory devices within a computer such as CD-ROM disks readable by a CD-ROM drive, ROM chips or any type of solid-state non-volatile semiconductor memory) on which information is permanently stored; and (ii) writable storage media (e.g., flash memory, floppy disks within a diskette drive or hard-disk drive or any type of solid-state random-access semiconductor memory) on which alterable information is stored.

The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of the invention. As used herein, the singular forms "a," "an," and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will be further understood that the terms "comprises" and/or "comprising," when used in this specification, specify the presence of stated features, integers, steps, operations, elements, and/or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and/or groups thereof.

The corresponding structures, materials, acts, and equivalents of all means or step plus function elements in the claims below are intended to include any structure, material, or act for performing the function in combination with other claimed elements as specifically claimed. The description of embodiments of the present invention has been presented for purposes of illustration, but is not intended to be exhaustive or limited to the implementations in the form disclosed. Many modifications and variations will be apparent to those of ordinary skill in the art without departing from the scope and spirit of the present invention. The embodiments were chosen and described in order to best explain the principles and some practical applications of the present invention, and to enable others of ordinary skill in the art to understand the present invention for various embodiments with various modifications as are suited to the particular use contemplated.

Claims

1. An initiating client (1) comprising: a physically unclonable function ‘PUF’ (6); a communication interface (3, 4); a memory comprising at least a challenge-and-response pair ‘CRP’; and at least one processor (5) configured to:

- retrieve an initiating CRP (C2, R2) from memory (7), the initiating CRP (C2, R2) including an initiating challenge (C2) and an initiating response (R2), generate a first message (Mi), and send the first message (Mi) to responding client (2), the first message comprising the initiating challenge (C2); and

- receive a second message (M2), the second message (M2) comprising a responding challenge (Ci), isolate the responding challenge (Ci) from the second message (M2), stimulate the PUF (6) of the initiating client (1) with the responding challenge (Ci) to obtain a second PUF response (Ri’), and generate a shared key (R) from the second PUF response (R ) and the initiating response (R2), wherein information transmitted from the initiating client (1) to the responding client (2) and/or information transmitted from the responding client (2) to the initiating client (1) is encrypted with the shared key (R).

2. An initiating client (1) as claimed in claim 1, wherein the initiating client (1) is configured to:

- generate a first random number (Ti), encrypt the first random number (Ti) using the initiating response (R2) to generate a first value (Ui), and include the first value (Ui) in the first message (Mi); and

- isolate a second value (U2) from the second message (M2) and decrypt, using the obtained shared key (R), the second value (U2), resulting in at least a fourth random number (Ti”), wherein the secure channel is established in dependence on the first random number (Ti) being equal to the fourth random number (Ti”).

3. An initiating client (1) as claimed in claim 2, wherein the initiating client (1) is configured to:

- decrypt, using the obtained shared key (R), the second value (U2), resulting in at least the fourth random number (Ti”) and a fifth random number (T2’), encrypt, using the obtained shared key (R), the first random number (Ti) and/or the fifth random number (T2’) in a third message (M3), and send the third message (M3) to responding client (2).

4. An initiating client (1) as claimed in any of the preceding claims, wherein the initiating client (1) is configured to:

- encrypt at least the initiating challenge (C2) using the initiating response (R2) to generate a first value (Ui), the first message further comprising the first value (Ui); and - isolate the responding challenge (Ci) and a second value (U2) from the second message (M2), and decrypt, using the obtained shared key (R), the second value (U2) resulting in at least an assumed responding challenge (Ci ’), wherein the secure channel is established in dependence on the assumed responding challenge (Ci’) being equal to the responding challenge (Ci) received by the initiating client (1).

5. An initiating client (1) as claimed in any one of the preceding claims, wherein the initiating client (1) is configured to generate a ninth random number (T4) to generate at least one new CRP for use with the initiating client (1).

6. An initiating client (1) as claimed in claim 5, wherein the initiating client (1) is configured to, after receipt of the second message (M2), generate the at least one new CRP comprising a fourth challenge (C4), optional fourth helper data (0J4). and a fourth response (R0 from the ninth random number (T4), and encrypt a combined value (V2) thereof, using the obtained shared key (R), in a third message (M3).

7. A responding client (2) comprising: a physically unclonable function ‘PUF’ (6); a communication interface (3, 4); a memory comprising at least a challenge-and-response pair ‘CRP’; and at least one processor (5) configured to:

- receive a first message (Mi) from an initiating client (1), the first message comprising an initiating challenge (C2), isolate the initiating challenge (C2) from the first message (Mi), and stimulate the PUF (6) of the responding client (2) with the isolated initiating challenge (C2) to obtain the first PUF response (R2’); and

- retrieve a responding CRP (Ci, Ri) from memory (7), the responding CRP (Ci, Ri) including a responding challenge (Ci) and a responding response (Ri), generate a shared key (R) from the responding response (Ri) and the PUF response (R2’), and transfer a second message (M2) to the initiating client (1), the second message (M2) comprising the responding challenge (Ci), wherein information transmitted from the initiating client (1) to the responding client (2) and/or information transmitted from the responding client (2) to the initiating client (1) is encrypted with the shared key (R).

8. A responding client (2) as claimed in claim 7, wherein the responding client (2) is configured to:

- isolate a first value (Ui) from the first message (Mi); decrypt the first value (Ui) using the PUF response (R2’) as key resulting in at least a third random number (T ), encrypt, using the obtained shared key (R), the decrypted third random number (T ) in a second value (U2), and include the second value (U2) in the second message (M2), wherein the secure channel is established in dependence on the first random number (Ti) being equal to the fourth random number (Ti ”).

9. A responding client (2) as claimed in claim 8, wherein the responding client (2) is configured to:

- generate a second random number (T2); encrypt, using the obtained shared key (R), the decrypted third random number (T ) and the second random number (T2) in the second value (U2); and

- receive the third message (M3) from the initiating client (1) and decrypt the third message (M3) using the obtained shared key (R), resulting in a sixth random number (Ti’”) and/or a seventh random number (T2”), and wherein the secure channel is established in dependence on the sixth random number (Ti’”) being equal to the third random number (T ) and/or in dependence on the seventh random number (T2”) being equal to the second random number (T2).

10. A responding client (2) as claimed in any one of claims 7 to 9, wherein the responding client (2) is configured to:

- isolate the initiating challenge (C2) and a first value (Ui) from the first message (Mi), decrypt the first value (Ui) using the PUF response (R2’) as key resulting in at least an assumed initiating challenge (C2’), encrypt, using the obtained shared key (R), the responding challenge (Ci) in a second value (U2), and combine the second value (U2) with the responding challenge (Ci) in the second message (M2), wherein the secure channel is established in dependence on the assumed initiating challenge (C2’) being equal to the initiating challenge (C2) received by the responding client (2).

11. A responding client (2) as claimed in any one of claims 7 to 10, wherein the responding client (2) is configured to generate an eighth random number (T3) to generate at least one new CRP for use with the responding client (2).

12. A responding client (2) as claimed in claim 11, wherein the responding client (2) is configured to, after receipt of the first message (Mi), generate the at least one new CRP comprising a third challenge (C3), optional third helper data (0)3). and a third response (R3) from the eighth random number (T3), and encrypt a combined value (Vi) thereof, using the obtained shared key (R), in a second value (U2).

13. A system comprising the initiating client of any one of claims 1 to 6 and the responding client of any of claims 7 to 12, the system being configured to establish a secure channel there between.

14. A method of establishing a secure channel between at least two clients at an initiating client

(1), the initiating client (1) comprising a physically unclonable function, the method comprising:

- retrieving an initiating challenge-and-response pair ‘CRP’ (C2, R2) from memory, the initiating CRP (C2, R2) including an initiating challenge (C2) and an initiating response (R2), generating a first message (Mi), and sending the first message (Mi) to responding client (2), the first message comprising the initiating challenge (C2); and

- receiving a second message (M2), the second message (M2) comprising a responding challenge (Ci), isolating the responding challenge (Ci) from the second message (M2), stimulating the PUF of the initiating client (1) with the responding challenge (Ci) to obtain a second PUF response (Ri’), and generating the shared key (R) from the second PUF response (R ) and the initiating response (R2), wherein information transmitted from the initiating client (1) to the responding client (2) and/or information transmitted from the responding client (2) to the initiating client (1) is encrypted with the shared key (R).

15. A method of establishing a secure channel between at least two clients at a responding client

(2), the responding client (2) comprising a physically unclonable function, the method comprising:

- receiving a first message (Mi) from an initiating client (1), isolating an initiating challenge (C2) from the first message (Mi), and stimulating the PUF of the responding client (2) with the isolated initiating challenge (C2) to obtain the first PUF response (R2’); and

- retrieving a responding CRP (Ci, Ri) from memory, the responding CRP (Ci, Ri) including a responding challenge (Ci) and a responding response (Ri), generating a shared key (R) from the responding response (Ri) and the PUF response (R2’), and transferring a second message (M2) to the initiating client (1), the second message (M2) comprising the responding challenge (Ci), wherein information transmitted from the initiating client (1) to the responding client (2) and/or information transmitted from the responding client (2) to the initiating client (1) is encrypted with the shared key (R).