Distributed trusted execution of an application in a network of controllable physical unclonable function devices

Abstract

A method and system for trusted execution of software parts in a network of CPUF devices are described, wherein the method comprises: establishing secure channels between controllable physical unclonable function (CPUF) devices based on challenge response pair (CRP) data, the CPUF devices defining a network, each CPUF device comprising a physical unclonable function (PUF) circuit controlled by a secure channel handler configured to establish a secret key associated with a secure channel based on CRP data; distributing program parts forming a software application over the secure channels to at least part of the CPUF devices, wherein the program parts need to be executed on the different CPUF devices in a predetermined hierarchical order, the distributing including sending a first program part to a first CPUF device in the network and a second program part to a second CPUF device in the network, the second program part being of a lower hierarchy than the first program part; and, receiving combined proof-of-execution information associated with the distributed execution of the software application, the combined proof-of- execution information including first proof-of-execution information comprising the first program part, first CRP data and a first proof-of-execution and second proof-of-execution information comprising the second program part, second CRP data and a second proof-of- execution, wherein the second proof-of-execution is computed by a second proof generation function of the second CPUF device based on information associated with the second program part, the second execution result and the second CRP data and the first proof-of- execution is computed by a first proof generation function of the first CPUF device based on information about the first program part, the first execution result, the first CRP data and the second proof of execution.

Description

[0001] Distributed trusted execution of an application in a network of controllable physical unclonable function devices

[0002] Technical field

[0003] The embodiments relate to distributed trusted execution of an application using controllable physical unclonable function (CPUF) devices, and, in particular, though not exclusively, to methods and systems for distributed trusted execution of an application in a network of CPUF devices and a computer program product for executing such methods.

[0004] Background

[0005] 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 behavior. 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.

[0006] A controlled PUF (CPUF) device comprises a PUF and a control layer that restricts a user’s access to the PUF input and output. Such CPUF device is especially beneficial in a system that has multiple users or sessions accessing the same computational device. Typically, the CPUF device is a hardware device integrated on a die, i.e. a small semiconductor substrate on which a microprocessor is fabricated. CPUF devices with different control layers exist. W003 / 090259A2 describes a control layer configured to create a hash of a program to be executed on the system which wants to access the PUF and to provide a response to a challenge or pre-challenge that depends on this hash such that the CPUF device can be used for authentication to semiconductor chips towards an owner.

[0007] A further CPUF implementation is described in the article by Skoric et al., “Flowchart description of security primitives for controlled physical unclonable functions", International Journal of Information Security 9, 2010, describes a CPUF device which only allows access to PUF functionality when a secure channel has been established. All communications and iterations need to pass though the secure channel handler. Everything that happens within the CPUF device is considered secure against invasive attacks.

[0008] Although known CPUF implementations provide more secure security than a bare PUF implementation, their functionality is still limited to the circuity components on the die on which the CPUF device is implemented. These CPUF implementations are not suitable for providing strong security in a distributed environment, for example an environment including multiple dies, which are configured to execute an application in a distributed way. Hence, from the above it follows that there is a need in the art for improved methods and systems for distributed trusted execution of an application using controllable CPUF devices.

[0009] Summary

[0010] As will be appreciated by one skilled in the art, aspects of the present invention may be embodied as a system, method or 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 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.

[0011] 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 (a non-exhaustive list) of the computer readable storage medium would include 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 this document, 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.

[0012] 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.

[0013] 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), Smalltalk, 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).

[0014] 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 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 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 functions / acts specified in the flowchart and / or block diagram block or blocks.

[0015] 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 function / act specified in the flowchart and / or block diagram block or blocks.

[0016] 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 functions / acts specified in the flowchart and / or block diagram block or blocks. Additionally, the instructions may be executed by any type of processors, including but not limited to one or more digital signal processors (DSPs), general purpose microprocessors, application specific integrated circuits (ASICs), field programmable logic arrays (FPGAs), or other equivalent integrated or discrete logic circuitry.

[0017] The flowchart and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, 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 function(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.

[0018] In an aspect, the embodiments in this disclosure relate to a method for trusted execution of software parts using CPLIF devices. In an embodiment, the method may comprise establishing secure channels between controllable physical unclonable function (CPLIF) devices based on challenge response pair (CRP) data, each CPLIF device comprising a physical unclonable function (PUF) circuit controlled by a secure channel handler configured to establish a secret key associated with a secure channel based on CRP data; distributing program parts forming a software application over the secure channels to at least part of the CPLIF devices, wherein the program parts need to be executed on the different CPLIF devices in a predetermined hierarchical order, the distributing including sending a first program part to a first CPLIF device of the CPLIF devices and a second program part to a second CPLIF device of the CPLIF devices, the second program part being of a lower hierarchy than the first program part; and, receiving combined proof-of-execution information associated with the distributed execution of the software application, the combined proof-of-execution information including first proof-of-execution information comprising the first program part, first CRP data and a first proof-of-execution and second proof-of-execution information comprising the second program part, second CRP data and a second proof-of-execution, wherein the second proof-of-execution is computed by a second proof generation function of the second CPLIF device based on information associated with the second program part, the second execution result and the second CRP data and the first proof-of-execution is computed by a first proof generation function of the first CPLIF device based on information about the first program part, the first execution result, the first CRP data and the second proof of execution. In an embodiment, the CPLIF devices may define a network of CPLIF devices.

[0019] Hence, the CPLIF devices may be configured to form a distributed trusted execution environment (dTEE) in which a distributed application may be executed by multiple CPLIF chips. The distributed trusted execution environment provided by the network of CPLIF chips allows distributed proof-of-execution and certified execution of such distributed applications.

[0020] In an embodiment, the method may further comprise storing the combined proof-of-execution information in a data file, wherein the proof-of-execution information further comprises information about the hierarchy of the first and second program parts.

[0021] In an embodiment the first and second proof-of-execution may be associated with a first and second node identifier, preferably an URL or a device identifier, for identifying the first and second CPUF device respectively.

[0022] In an embodiment, the information about the first program part may include a hash value associated with at least part of the first program part and the information about the second program part may include a hash value associated with at least part of the second program part.

[0023] In an embodiment, the method may further comprise: sending the first proof- of-execution information to the first CPUF device and the second first proof-of-execution information to the second CPUF device; and, receiving verification information, the verification information including first verification information indicative of the validity of the first proof-of-execution, computed based on a first proof verification function of the first CPUF device, the first proof-of-execution information and the second proof-of-execution; and, second verification information indicative of the validity of the second proof-of-execution computed based on a second proof verification function of the second CPUF device and the second proof-of-execution information.

[0024] In an embodiment, the second proof verification function may include an input for receiving the second CRP data, the second execution result, information about the second program part and the second proof-of-execution and an output for outputting the second verification information and wherein the first proof verification includes an input for receiving the first CRP data, the first execution result, information about the first program part and the second proof-of-execution and an output for outputting the second verification information. In an embodiment, the method may further comprise: establishing secure channels between pairs of CPLIF devices based on secret keys shared between the pairs of CPLIF devices, each shared secret key being based on challenge response pairs associated with the pairs; and, sending the encrypted shared secret key and the encrypted first data from the first CPLIF device to the second CPLIF device over at least part of the established secure channels.

[0025] In an embodiment, the CPLIF devices may form an overlay network overlying an underlay network, the overlay network being controlled by a controller, which is configured to establish a secure connection between the first CPLIF device and the second CPLIF based on the shared secret key.

[0026] In an embodiment, the CPLIF devices may be implemented as integrated circuit dies, system on chip dies or chiplets; and / or, wherein the CPLIF devices are identified by a unique identifier, preferably a chip or chiplet ID.

[0027] In a further aspect, the embodiments may relate to a controlled physical unclonable function (CPLIF) device, preferably an die or system on a chip, comprising: a PUF circuit controlled by a secure channel handler configured to establish a secret key based on a challenge response pair (CRP); an encryption function for encrypting data based on an encryption key; a decryption function for decrypting encrypted data based on a decryption key; a network module for communicating with other CPLIF devices; and, a computer readable storage medium having computer readable program code embodied therewith, and a processor, coupled to the computer readable storage medium, wherein responsive to executing the computer readable program code, wherein the processor may be configured to perform executable operations.

[0028] In an embodiment, the executable operations may include establishing secure channels between controllable physical unclonable function (CPLIF) devices based on challenge response pair (CRP) data; distributing program parts forming a software application over the secure channels to at least part of the CPLIF devices, wherein the program parts need to be executed on the different CPLIF devices in a predetermined hierarchical order, the distributing including sending a first program part to a first CPLIF device and a second program part to a second CPLIF device, the second program part being of a lower hierarchy than the first program part; and, receiving combined proof-of-execution information associated with the distributed execution of the software application, the combined proof-of-execution information including first proof-of-execution information comprising the first program part, first CRP data and a first proof-of-execution and second proof-of-execution information comprising the second program part, second CRP data and a second proof-of-execution, wherein the second proof-of-execution is computed by a second proof generation function of the second CPLIF device based on information associated with the second program part, the second execution result and the second CRP data and the first proof-of-execution is computed by a first proof generation function of the first CPLIF device based on information about the first program part, the first execution result, the first CRP data and the second proof of execution.

[0029] In an embodiment, the executable operations may further comprise: storing the combined proof-of-execution information in a data file, wherein the proof-of-execution information further comprises information about the hierarchy of the first and second program parts.

[0030] In an embodiment, the first and second proof-of-execution may be associated with a first and second node identifier, preferably an URL or a device identifier, for identifying the first and second CPUF device respectively; and / or, wherein the information about the first program part includes a hash value associated with at least part of the first program part and wherein the information about the second program part includes a hash value associated with at least part of the second program part.

[0031] In an embodiment, the executable operations may further comprise: sending the first proof-of-execution information to the first CPUF device and the second first proof-of-execution information to the second CPUF device; and, receiving verification information, the verification information including first verification information indicative of the validity of the first proof-of-execution, computed based on a first proof verification function of the first CPUF device, the first proof-of-execution information and the second proof-of- execution; and, second verification information indicative of the validity of the second proof- of-execution computed based on a second proof verification function of the second CPUF device and the second proof-of-execution information.

[0032] In a further aspect, the embodiments may relate to a controller for controlling CPUF devices, wherein the controller may be configured to: establishing secure channels between controllable physical unclonable function (CPUF) devices based on challenge response pair (CRP) data, each CPUF device comprising a physical unclonable function (PUF) circuit controlled by a secure channel handler configured to establish a secret key associated with a secure channel based on CRP data; distributing program parts forming a software application over the secure channels to at least part of the CPUF devices, wherein the program parts need to be executed on the different CPUF devices in a predetermined hierarchical order, the distributing including sending a first program part to a first CPUF device of the CPUF devices and a second program part to a second CPUF device of the CPUF device, the second program part being of a lower hierarchy than the first program part; and, receiving combined proof-of-execution information associated with the distributed execution of the software application, the combined proof-of-execution information including first proof-of-execution information comprising the first program part, first CRP data and a first proof-of-execution and second proof-of-execution information comprising the second program part, second CRP data and a second proof-of-execution, wherein the second proof- of-execution is computed by a second proof generation function of the second CPLIF device based on information associated with the second program part, the second execution result and the second CRP data and the first proof-of-execution is computed by a first proof generation function of the first CPLIF device based on information about the first program part, the first execution result, the first CRP data and the second proof of execution. In an embodiment, the CPLIF devices may define a network of CPLIF devices,

[0033] In a further aspect, the embodiments may relate to a controlled physical unclonable function (CPLIF) device, preferably a die or system on a chip, configured to generate a proof-of-execution for one or more program parts of a distributed software application, wherein the one or more program parts need to be executed on different CPLIF devices in a predetermined hierarchical order, the CPLIF device comprising: a PUF circuit controlled by a secure channel handler configured to establish a secret key based on a challenge response pair (CRP) data and to establish a secure channel with one or more further CPLIF devices based on the secret key; a network module for communicating with the one or more further CPLIF devices; a secure function, preferably a hash function, configured to receive input information from the secure channel handler and to compute a secure value, preferably a hash value, based on the input information, the input information including a first program part of the distributed software application, a second proof-of-execution associated with a second program part of the distributed software application computed by a further CPLIF device and, optionally, one or more further input parameters associated with the first program part, wherein the first and second program part are associated with a first and second hierarchy, the second hierarchy being lower than the first hierarchy; a program execution module configured to compute an execution result based on the first program part and, optionally, the one or more further input parameters; a proof-of-execution generator configured to compute a first proof-of-execution associated with the first program part based on the secure value, the execution result and CRP data, the first proof-of-execution indicating that the first program part has been executed by the CPLIF device.

[0034] In yet a further aspect, the embodiments may relate to a controlled physical unclonable function (CPLIF) device, preferably a die or system on a chip, configured to evaluate a proof-of-execution for one or more program parts of a distributed software application, wherein the program parts need to be executed on different CPLIF devices in a predetermined hierarchical order, the CPLIF device comprising: a PUF circuit controlled by a secure channel handler configured to establish a secret key based on a challenge response pair (CRP) data and to establish a secure channel with one or more further CPUF devices based on the secret key; a network module for communicating with one or more further CPLIF devices; wherein the secure channel handler is configured to receive: an execution result computed by the CPLIF device based on a first program part of the distributed software application and, optionally, one or more further input parameters associated with the first program part; a secure value, preferably a hash value, computed by a secure function of the CPLIF device based on the first program part of the distributed software application, a second proof-of-execution associated with a second program part of the distributed software application computed by a further CPLIF device and, optionally, one or more further input parameters associated with the first program part, wherein the first and second program part are associated with a first and second hierarchy respectively, the second hierarchy being lower than the first hierarchy; CPR data that is used by the CPLIF device to compute the first proof-of-execution; a first proof-of-execution associated with the first program part computed by the CPLIF device; a proof-of-execution module that is configured to generate verification information based on the execution result, the secure value, the first proof-of-execution and the CRP data, wherein the verification information includes information indicating whether or not the first program part has been executed by the CPLIF device.

[0035] In an embodiment, the embodiments may further relate to a program product comprising software code portions configured for, when run in the memory of a controlled physical unclonable function (CPLIF) device, executing the method steps according to any of the steps as described above.

[0036] Further aspects of the embodiments in this disclosure relate to methods for secure memory transfer. Such secure transfer may be needed when executing program parts on different CPLIF devices in a network CPLIF devices.

[0037] In an embodiment, a method for secure memory transfer may comprise: creating a shared memory location in a data storage associated with a first controllable physical unclonable function (CPLIF) device, the first CPLIF device being configured to manage the shared memory location and being part of a network of CPLIF devices, the shared memory location comprising first data encrypted using a memory key; receiving a request from a second CPLIF device in the network of CPLIF devices for accessing the encrypted first data stored in the shared memory location, the second CPLIF device sharing a secret key with the first CPLIF device, the secret key being based one or more challenge response pairs shared between the first and the second CPLIF device; and, encrypting, by the first CPLIF device, the memory key associated with the shared memory location based the shared secret key and sending the encrypted shared secret key and the encrypted first data to the second CPLIF device for processing at least part of the first data.

[0038] The advantage of setting up a shared memory using a CPLIF device in a network of CPLIF device that the data are not only stored using the intrinsic properties of the PUF, i.e. based on the key material that is generated by the CPLIF, but also that data transport is based on secure channels that are setup between CPUF-devices. Hence granting access to the encrypted memory is only possible by CPLIF devices that have a secure channel setup with a CPLIF device that manages the shared memory.

[0039] In an embodiment, the processing of the first data may include modification of the first data in second data.

[0040] In an embodiment, the method may further include: receiving, by the first CPLIF device, second data from the second CPLIF device, the second data being encrypted by the second CPLIF device using the memory key.

[0041] In an embodiment, the method may include storing at least part of the second data encrypted by the memory key in the shared memory location.

[0042] In an embodiment, the method may include replacing at least part of the first data encrypted by the memory key in the shared memory location with at least part of the second data encrypted by the memory key.

[0043] In an embodiment, the creation of the shared memory location may include: generating a shared memory identifier; and. sharing the shared memory identifier with at least part of the CPLIF devices in the network.

[0044] In an embodiment, the creation of the shared memory location may include: generating the memory key based a challenge and / or response of the first CPLIF device.

[0045] In an embodiment, the creation of the shared memory location may include: encrypting data based on the memory key and storing the encrypted data in the shared memory region.

[0046] In an embodiment, the creation of the shared memory location may include: creating a sharing list for administering CPLIF devices accessing the shared memory location.

[0047] In an embodiment, the method may further include; adding the second CPLIF device to the sharing list if the second CPLIF device is allowed to access the shared memory location.

[0048] In an embodiment, the method may include locking access to shared memory region for other CPLIF devices until the first CPLIF device releases the locking.

[0049] In an embodiment, the method may further comprise: establishing secure channels between pairs of CPLIF devices in the network based on secret keys shared between the pairs of CPLIF devices, each shared secret key being based on challenge response pairs associated with the pairs.

[0050] In an embodiment, the method may further include: sending the encrypted shared secret key and the encrypted first data from the first CPLIF device to the second CPLIF device over at least part of the established secure channels. In an embodiment, the network of CPLIF devices form an overlay network overlying an underlay network, the overlay network being controlled by a controller which is configured to establish a secure connection between the first CPLIF device and the second CPLIF based on the shared secret key.

[0051] In an embodiment, the CPLIF devices may be implemented as integrated circuit dies, system on chip dies or chiplets.

[0052] In an embodiment, the CPLIF devices may be identified by an unique identifier, preferably a chip or chiplet ID.

[0053] In a further aspect, the embodiments in this disclosure may relate to a controlled physical unclonable function (CPLIF) device.

[0054] In an embodiment, the CPLIF device may be implemented as a die or system on a chip.

[0055] The CPLIF device may include: a PUF circuit controlled by a secure channel handler configured to establish a secret key based on a challenge response pair; an encryption function for encrypting data based on an encryption key; a decryption function for decrypting encrypted data based on a decryption key; a network module for communicating with other CPLIF devices in a network of CPLIF device; a memory controller for controlling a data storage external to the CPLIF device; and, a computer readable storage medium having computer readable program code embodied therewith, and a processor, coupled to the computer readable storage medium, wherein responsive to executing the computer readable program code.

[0056] In an embodiment, the processor may be configured to perform executable operations comprising: creating by the memory controller a shared memory location in the data storage, the shared memory location comprising first data encrypted using a memory key; receiving by the network module a request from a second CPLIF device in the network of CPLIF devices for accessing the encrypted first data stored in the shared memory location, the second CPLIF device sharing a secret key with the CPLIF device, the secret key being based one or more challenge response pairs shared between the CPLIF and the second CPLIF device; and, encrypting, by the encryption function, the memory key associated with the shared memory location based the shared secret key and sending, by the network module, the encrypted shared secret key and the encrypted first data to the second CPLIF device for processing at least part of the first data.

[0057] In an embodiment, the processing of the first data may include modification of the first data in second data.

[0058] In an embodiment, the executable operations may further comprise: receiving, by the network module, second data from the second CPLIF device, the second data being encrypted by the second CPLIF device using the memory key. In an embodiment, the executable operations may further comprise storing, by the memory controller, at least part of the second data encrypted by the memory key in the shared memory location

[0059] In an embodiment, the executable operations may further comprise: replacing, by the memory controller, at least part of the first data encrypted by the memory key in the shared memory location with at least part of the second data encrypted by the memory key.

[0060] In an embodiment, the creation of the shared memory location may include generating a shared memory identifier; and. sharing the shared memory identifier with at least part of the CPLIF devices in the network

[0061] In an embodiment, the creation of the shared memory location may include generating the memory key based a challenge and / or response of the first CPLIF device;

[0062] In an embodiment, the creation of the shared memory location may include: encrypting data based on the memory key and storing the encrypted data in the shared memory region;

[0063] In an embodiment, the creation of the shared memory location may include: creating a sharing list for administering CPLIF devices accessing the shared memory location

[0064] In an embodiment, the executable operations may further comprise adding the second CPLIF device to the sharing list if the second CPLIF device is allowed to access the shared memory location; and, optionally, locking access to shared memory region for other CPLIF devices until the first CPLIF device releases the locking.

[0065] In an embodiment, the embodiments may further relate to a program product comprising software code portions configured for, when run in the memory of a controlled physical unclonable function (CPLIF) device, executing the method steps according to any of the steps as described above, wherein the wherein the CPLIF device may comprise: a PUF controlled by a secure channel handler configured to establish a secret key based on a challenge response pair; an encryption function for encrypting data based on an encryption key; a decryption function for decrypting encrypted data based on a decryption key; a network module for communicating with other CPLIF devices in a network of CPLIF device; a memory controller for controlling a data storage external to the CPLIF device; and, a processor coupled to the memory.

[0066] The embodiments will be further illustrated with reference to the attached drawings, which schematically will show embodiments according to the invention. It will be understood that the invention is not in any way restricted to these specific embodiments. Brief description of the drawings

[0067] Fig. 1A and 1B depict schematics of a system for establishing a secure channel with an external device using a CPLIF;

[0068] Fig. 2 depicts a general schematic of a CPUF-implemented chip including security primitives that are used in the embodiments described in this disclosure;

[0069] Fig. 3 depicts an example of a network of CPUF-based chips;

[0070] Fig. 4A and 4B depict an example of a secure channel between a CPUF- based chip and a data storage;

[0071] Fig. 5 depicts a flow diagram of storing and retrieving encrypted data from a memory over a secure channel;

[0072] Fig. 6 depicts an example of establishing a secure channel between two CPUF-based devices according to an embodiment;

[0073] Fig. 7 depicts a CPUF device comprising an e-proof generator module according to an embodiment;

[0074] Fig. 8 depicts a CPUF device comprising an e-proof verification module according to an embodiment;

[0075] Fig. 9 depicts a high-level protocol flow of an CPUF-based e-proof generation and verification process according to an embodiment.

[0076] Fig. 10 illustrates a set of CPUF devices executing program parts and generating associated e-proofs according to an embodiment.

[0077] Fig. 11 depicts an example of the hierarchical dependency of e-proofs associated with executing a distributed number of program parts by difference CPUF devices.

[0078] Fig. 12 depicts an example a hierarchical tree structure of proofs associated with the trusted execution of a program parts in a network of CPUF devices according to an embodiment.

[0079] Fig. 13 depicts a protocol flow of a method for trusted execution of program parts in a network of CPUF devices according to an embodiment;

[0080] Fig. 14 depicts a protocol flow of a method for trusted execution of program parts in a network of CPUF devices according to another embodiment;

[0081] Fig. 15A and 15B depict a method of secure memory transfer using a CPUF- based device according to an embodiment;

[0082] Fig. 16 illustrates a system for managing a network of CPUF devices according to an embodiment.

[0083] Fig. 17 depicts an example of a network of CPUF-based chiplets; Description of the embodiments

[0084] The CPUF chip may be configured to establish, via the I / O interface, a secure channel with one or more external devices 120,122, i.e. one or more devices that are not part of the CPUF chip. Once established, secure communication between the CPUF chip and the external device can take place. The external device may be another CPUF device 124 or a device, e.g. a chip, that has no CPUF functionality but is configured to communicate with the CPUF device, e.g. a hardware module such as a memory module. The CPUF device and the one or more external devices may be part of a network wherein the CPUF device can communicate with at least part of the one or more external devices over a CPUF-secured secure channel.

[0085] In an embodiment, the CPUF devices and the other external devices may be implemented as chiplets which are interconnected via an interconnecting substrate. The interconnected chiplets may be configured as a network-on-chip (NOC), an intrachiplet network or an interchiplet network. Examples of such chiplet networks are described in the article by Chen et al, “Design Challenges of Intrachiplet and Interchiplet Interconnection”, IEEE Design & Test (Vol. 39, Issue: 6, December 2022. In other embodiments, the CPUF and the other external devices may form part of a network, e.g. an loT network, e.g. a cellular network, a LAN / PAN or LPWAN network or a mesh network.

[0086] As illustrated in Fig. 1 B, to establish a secure channel with the CPUF device, the CPUF device may be configured to receive from an external device, via its I / O interface, a request message 130 for setting up a secure channel. The request message may comprise a challenge Cand helper data w. The challenge may be provided to the input of the PUF which may determine or generate a unique response based on the challenge. The reproduce function REP 124 may determine a key k based on the PUF response and the helper data w. / shared secret R may be generated by applying a cryptographic hash function HASH 126 to the key k. Sometimes this hash function is referred to as hash2 to differentiate between other hash functions that are used by the CPUF device, e.g. the hash function hash3 that is used for proof- of-execution as described hereunder in more detail. The shared secret R is regarded as a shared secret between end-points and may be used by the SC handler 128 establish a secure communication channel with the external device that requested communication over a secure channel. The secure channel may include encrypting data to be transmitted from the CPUF device to the one or more external devices and / or decrypting data received by the CPUF device from the one or more external devices based on the shared secret. To run an application on the device, a secure channel should be established. The application can only be executed if the response of the PUF is reproduced by the CPUF device itself. All data to and from the device can be encrypted using the shared secret R. The secure channel SC handler manages the secure channel, including setup of the connection, status of the secure channels, key renewal, etc. Once the secure channel has been established, the user or program can access the CPUF functions / services of which some involve the generation of a cryptographic key.

[0087] Fig. 2 depicts a general schematic of a CPUF device 202 including security primitives that are used in the embodiments described in this disclosure. As shown in the figure, the device may include random generator RGN 208, a PUF 210, a generate GEN function 212 and a reproduce REP function 214 associated with the PUF, one or more HASH functions 220, a decryption function 216, an encryption function 218 and the secure channel (SC) handler 206. The random number generator is configured to generate a random number, which is used as a challenge for the PUF. The random number may be stored (at least temporarily). Alternatively, a challenge for the PUF may be received from the further system of the user or external program. A response of the PUF is input into the generate GEN function. This generate function may be a Fuzzy Extractor, also known as a helper data scheme, which is introduced as a primitive that achieves both information reconciliation and privacy amplification. The helper data (also referred to as redundancy data or public data) may be used to reproducibly reconstruct a string from noisy measurements and only leaks a negligible amount of information about the extracted key. The counterpart of the generate function is the reproduce REP function, which is configured to reconstruct the original output from the noisy output data of the PUF. The outputted secret s of the generate function is used as the input of a second cryptographic hash function. The output of the generate function represents the shared secured R to that is used by the SC handler for handling the secure communication channel.

[0088] The embodiments in this disclosure use the CPUF functionality as described in Fig. 2 to provide secure memory transfer in a distributed environment. The CPUF (including its extensions as described in European application no. 24168018.0 with title “Controllable physical unclonable function”) provides a trusted execution environment, in which almost all data and instructions are decrypted when entering the device and encrypted when leaving the device. This way, the controlled physical unclonable functions of the CPUF can be used in a distributed execution environment.

[0089] Fig. 3 depicts an example of a network of CPUF devices, in this example CPUF chips. The network may include a plurality of connected CPUF device 302i^. Instead of CPUF chips, CPUF chiplets may be used to form a network. In such chiplet implementation, chiplets may be connected via interconnects 304I-6 based on a chiplet interconnection technology that allows communication of messages and signals between chiplets. In that case, the chiplets may form a Network-On-Chip (NOC) system wherein a network controller may be configured to communicate messages and signals between chiplet components. The chips or chiplets may be further connected to one or more external devices, e.g. external memory banks 306i-s. One or more memory banks may be connected to a CPUF device using a memory controller. As will be described hereunder in more detail, each of the CPUF chips and / or CPUF chiplets may include a set of trusted CPUF functions, that are configured to execute protocols for authenticated execution and setting up and control of secure communication channels between chips or chiplets. In further implementations, the chips may be connected via one or more (wired or wireless) networks, including the Internet. Hence, a distributed network of CPUF chips or chiplets may be connected to each other via one or more communication channels (e.g. a die-to-die interface).

[0090] In an exemplary use case, CPUF chip 302i may want to share data stored in a memory, e.g. memory Mi i,with one or more other CPUF chips 3022-4 in a secure way using the CPUF functionality. In that case, the CPUF chip may configure part of the memory as a shared memory, wherein the content of the shared memory can be accessed by other CPUF devices. Secure and trusted access of the other chips to the shared memory based on the CPUF functionality of the chips will be described hereunder in greater detail. While the figure illustrates a memory bank, it is submitted that the embodiments are not limited thereto and that any type of storage medium, hard drive or even tape can be used.

[0091] The network of CPUF chips may be configured to form a distributed trusted execution environment (dTEE) in which a distributed application may be executed by multiple CPUF chips. Typically, in that case a program, e.g. an application, may be split in a plurality of program parts, for example four parts AI,A2, Aa,A4, 303I-4 as shown in the figure, wherein each of the program parts may be executed on a different CPUF chip. Further, each program part may request access memory that is managed by a specific CPUF chip. The distributed trusted execution environment provided by the network of CPUF chips may allow distributed proof-of- execution and certified execution of such distributed applications. The proof that a distributed application has been executed on a network of CPUF chip and that a certain result was produced by the execution of the distributed application can be used in many scenarios, such as logging or data acquisition and generation. Further, certified execution ensures that only pre-approved code is executed on a specific device, preventing any unauthorized modification to application. The distributed trusted execution environment as described with reference to the embodiments in this application may be implemented in any form, including (but not limited to) chip-to-chip secure networks over a chiplet interface such as the universal chiplet interconnect express (UCLe) standard.

[0092] CPUF chip 302i in Fig. 3 that wants to setup a shared memory for other chips in the network, manages access of other CPUF to the memory based on one or more secure channels that can be established by one or more CPUF devices. Similarly, the distributed proof- of-execution and certified execution of such distributed applications by the CPUF chips is based on secure channels between the CPUF chips. Examples of such secure channels are illustrated in Fig. 4-6. Fig. 4 and 5 depict an example of a secure channel between a CPUF device and external data storage according to an embodiment. To handle data storage and data retrieval between the CPUF device and the data storage 404, the data storage is associated with a controller that has an interface with the CPUF device 402. As shown in Fig. 4A, the CPUF device may include a secure channel SC handler 406, a PUF 408, a reproduce function 410 and a cryptographic function 412, a random generator RNG 405 and a symmetric encryption function 415 and on-chip secure storage 416 comprising data d. When storing data onto the memory, a challenge 2 may be generated by the random generator, which is input to the PUF to produce a response r2. The generate function 411 uses the response r2 to generate helper data w2 and a shared secret s. A cryptographic hash function 412 may use the shared secret sto produce a secret key sk. In some embodiments, the secret key s may be combined with other information to form the secret key. For example, the secret key s may be combined (e.g. concatenated) with one or more further keys, e.g. a further challenge cl and / or response rlof another CRP that is store on the CPUF device and provided by the SC handler to the HASH function. The secret key may subsequently be provided to encryption function 414, which encrypts data d with the (symmetric) secret key sk. The encrypted data ENC sk, d) may be stored on the external storage 404 along with the challenge c2 and the helper data w2. In some embodiments, an identifier may be associated with the stored encrypted data. This way, different encrypted data sets may be stored and identified in the memory. Hence, as shown in the figure, the encryption of the data that is stored on the shared memory is tied to (part of) the CRP that was used by the CPUF device to establish the secure channel.

[0093] Fig. 4B depicts the functionality of the CPUF device for retrieving encrypted data ENC sk, d) associated with challenge c2 and helper data w2 from the external data storage and descripting the data using the challenge and helper data. The challenge c2 may be provided to the PUF 408 to produce a response r2, which is provided together with the helper data w2 to the reproduce function 410 to produce a shared secret s. The shared secret s is subsequently provided to cryptographic function 412 to produce a (symmetric) secret key sk output by the second cryptographic hash function 412. In some embodiments, the secret key s may be combined with other information to form the secret key. For example, the secret key s may be combined (e.g. concatenated) with one or more further keys, e.g. a further challenge cl and / or response rlof another CRP that is store on the CPUF device and provided by the SC handler to the HASH function. The encrypted data ENC sk, d) is sent from the external storage means to the CPUF device and the (symmetric) secret key sk that is computed by the CPUF device is then used by the symmetric decryption function DEC to decrypt the encrypted data and store the clear data don a on-chip secure storage 416. After decryption, the data d can be used by the CPU 418. The data d in the secure storage may be modified by the CPU and the modified data d may be encrypted again in the manner described in relation to Fig. 4A.

[0094] As shown in the figure, like the encryption, the decryption is tied to (part of) the challenge-response pair CRPs that were used to establish the secure channel. If the decryption is performed over a different secure channel than the encryption, then the encrypted data cannot be decrypted. Since the challenge c2 and the helper data w2are stored on the external storage, there is no need for the user or external program to keep a local copy of these values.

[0095] Fig. 5 depicts a flow diagram associated with the schematics of Fig. 4 illustrating data storage and retrieval of encryption using a CPUF device using CRPs and CPUF functions as described with reference to the embodiments in this disclosure. As shown in the figure, CPUF device 402 may compute a secret key sk using the CPUF primitives as illustrated in Fig. 4 (step 504). It determines a message M1 comprising the encrypted data, a challenge and associated helper data, which are sent to the memory controller for storage (step 506). In response, the memory controller may send a confirmation message back to the chip. In some embodiments, the confirmation message may include information regarding the memory storage, e.g. an identifier, to the CPUF-device, which can be used later for retrieving the encrypted data. In another embodiment, the CPUF device may determine an identifier for identifying the encrypted data. In that case, the identifier may be included message M1.

[0096] In a further step, the chip may decide to retrieve the data by sending a request to the memory controller (step 508). In some embodiments, the request may include an identifier for identifying the encrypted data. In response, the memory controller may send the encrypted data and the associated CPUF primitives (i.e. the challenge and helper data) in a message back to the chip (step 510), which may subsequently use the challenge and helper data to generate the secret key sk for decrypting the encrypted data into clear data d, which may be stored in the secure storage of the chip (step 512).

[0097] To achieve data sharing between a network of CPUF devices (as e.g. shown in Fig. 3) one or more memory modules associated with a CPUF-device need to be setup for data sharing; and, secure channels between different CPUF-devices need to be established so that data can be transferred over one or more secure channels between CPUF devices.

[0098] To setup an external memory module for data sharing, first a local region of memory needs to be assigned. This shared memory region may be identified by a memory identifier for example a number or a bit-string. The memory identifier is not changed during the lifetime of the shared memory region. Further, a memory key mko may be assigned to this memory region. In an embodiment, the memory key mko may be generated by the CPUF- device. The shared memory region may be administered by the CPUF device. To that end, in an embodiment, the CPUF device may comprise a shared memory controller. The controller may be configured to administer a list of CPUF devices that request access to the shared memory region as identified by the memory identifier. To that end, each of the CPUF devices may be identified by a unique identifier, e.g. a chip or a chiplet identification key. In an embodiment, the controller may send a message comprising the memory identifier one or more CPUF devices in the list that the memory region can be accessed.

[0099] Once the memory is set up, data can be encrypted using the memory key mko and copied to the shared region. The memory key may be stored together with the memory identifier and the list of CPUF devices that have access to the shared memory in a secure memory of the CPUF device that manages the shared memory. The advantage of setting up a shared memory using a CPUF device, is that the data are not only stored using the intrinsic properties of the PUF, i.e. based on the key material that is generated by the CPUF (as described with reference to Fig. 4 and 5), but data transport is also secure based on secure channels that are setup between CPUF-devices. Hence granting access to the encrypted memory is only possible by CPUF devices that have a secure channel setup with CPUF devices that manages the shared memory.

[0100] Fig. 6 depicts an example of establishing a secure channel between two CPUF devices according to an embodiment. A controller (not shown) may have provided CwR pairs to CPUF devices, CPUFi and CPUF2, prior to initiation of the protocol. Here, w refers to the helper data that is associated with a challenge-response pair. In particular, the first device may be provided with challenge response pair C2W2R2 (step 606) and the second device may be provided with challenge response pair CiW] R1 (step 608). Each of the CwR pairs can be split into a challenge (C) part, a response (R) part and associated helper data (w) part. The response part and the helper data of a CwR pair are typically generated at an earlier stage by providing a PUF with the challenge part. The challenge part may be randomly generated using the random generator that is part of the CPUF functionality as described with reference to Fig. 2. The resulting CwR pair is tied to the CPUF device that has generated the pair because the response part can only be regenerated using the PUF of that particular CPUF device. The CwR pair may be sent, e.g., by a controller, to another second CPUF device for establishing a secure channel.

[0101] As shown in the figure, the process may start computing first security primitives by the first CPUF device, e.g. a chip or a communication device, as shown in block 610. The computations may include generating a random number from a seed S The first device then encrypts challenge C2, helper data w2, and random number Tltin value U , with a known symmetric key algorithm using the response R2. Then, C2, w2and may be combined, e.g. concatenated in a message Mi, which may be sent over a channel, e.g. a public channels, to the second CPLIF device (step 612).

[0102] The second CPLIF device (the same or a similar device as the first device) may generate a random number ?2 fromaseed S2 (step 608). Further, it may process the information in message M1 as shown by the computations in block 614, which may include extracting, e.g. splitting, the values from message Mi into C2, W2 and t / iand stimulating the CPIIF2 with challenge C2 and helper data w2to obtain response / ?2- This stimulation may involve performing a reproduce (REP) function, as described e.g. with reference to Fig. 2. Then, response R2 may be used as a key to decrypt value U into challenge C2, helper data w2and random number 7 . This enables the second CPLIF device to validate that the first CPLIF device has knowledge of a CcoR pair of the PUF of the second CPLIF device by comparing if the challenge C2 and helper data w2are equal to challenge C2, and helper dataw2. Because a random number is included in the encrypted message, the encrypted message will be different every time.

[0103] If the challenge C2 and the challenge C2 or the helper data w2and the helper data w2are different, the second CPLIF device may 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 w2is equal to the helper data w2, the protocol is continued and the second client may generate a digest from R and , R2with a known cryptographic hash function. By using a hash function, machine learning attacks to the PUF may be prevented. This digest may be referred to as shared key R.

[0104] Further, as shown in block 614, the second device may encrypt challenge , helper data , random numberT^ and random number T2\r\ value U2using the shared key R, and combine, e.g. concatenate, value U2with challenge and helper data in a message M2. Message M2 may then be sent over a channel, e.g. a public channel, to the first CPUF device (step 616).

[0105] The first CPUF device may process the second message M2 according to block 618, which includes extracting challenge , helper data w±and value U2, from message M2 and stimulating the PUF of the first CPUF device with challenge and helper datawi to obtain response R . This stimulation typically involves performing a reproduce (REP) function, as described earlier. Then, the first CPUF device may generate a digest based on R±and R2with the above-mentioned cryptographic hash function, which yields the shared key R. This key is used to decrypt value U2into challenge , helper data w' , random number 7 and random number T2. The cryptograph hash function performed by first CPLIF device may be the same function as the cryptographic hash function performed by second CPLIF device.

[0106] At this point the first device can verify that random number is equal to random number 7Y If this is the case, it knows that key R is in fact shared, i.e. both devices use the same key. The first CPLIF device may verify that challenge C is equal to challenge Ci, that helper data w is equal to helper data w and that random number is equal to random number T i. If they are not equal, the first CPLIF device may stop the protocol and no secure channel is established.

[0107] If, on the other hand, the protocol is continued to allow the second CPLIF device to verify that it has the correct shared key R, the first device may encrypt random number Ti and random number ?2 using shared key R, and the result is message M3, which is transferred over the public channel to the second client (step 620).

[0108] Finally, in block 622 the second device may decrypt message Ma in random number 7 and random number T2using shared key R and verifies that the second device has the correct shared key R, by comparing random number 7 to random number 7 and by comparing random number T2to random number T2.

[0109] The method provides a mutual authentication protocol to establish a secure channel between two CPLIF devices, requiring only 3 encryptions, 3 decryptions, 2 hashes, 2 (pseudo) random numbers being generated, and 3 messages sent between the first and second device. The protocol is therefore computationally less expensive than prior art protocols in terms of e.g. system load, while security is increased.

[0110] It is submitted that the process depicted in Fig. 6 is only one of a plurality of CPUF-based authentication processes that can be used to determine a secure channel between two CPUF devices. Further protocols are described in associated European application no. 24174171 .9 with title “an authentication protocol" which is hereby incorporated by reference in this application.

[0111] To share a memory region in a network of CPUF devices as e.g. shown in Fig. 3, a secure channel between the devices needs to be established. Such secure channel may for example be established based on the protocol shown in Fig. 5. Depending on the situation, secure channels between two CPUF devices or a network of CPUF devices need to be established. In the latter case, data of the shared memory is sent from an initial node via one or more intermediate nodes to a destination node. For example, in the network of Fig. 3, CPUF device 4 may access shared memory 306i via CPUF device 3 and CPUF device 1 . In that case, data may be transferred over secure connections 304i and 3042.

[0112] The first CPUF device may be configured to manage a shared memory region on memory bank 306i, which comprises data that is encrypted with memory key mk0and which is identified by a memory identifier 3^. To that end, the CPUF device has a shared memory controller that is configured to manage a sharing list which identifies CPUF devices requesting access to the shared memory region. The sharing list may further comprise information that is needed during the secure memory sharing process. The shared memory controller may use a sharing list for each shared memory region it is controlling. The first CPUF device may send the shared memory identifier to one or more CPUF devices of the network, so that they can use the shared memory identifier to request transfer of the data stored in the shared memory region.

[0113] If the second CPUF device wants to access the shared memory region that is managed by the first CPUF device, the first and second CPUF device may setup a secure channel based on a shared key R12. The shared key R12(which was generated by the first CPUF device) may be used to encrypt the memory key mk0which is needed to decrypt the encrypted data stored in the shared memory. In some embodiments, before encryption, the memory key mk0may be combined, e.g. concatenated, with a random number to blind the key, i.e, Eko = ENC( / ?12, RAND || mk0). For each CPUF device on the list that would like to access the shared memory region, a secure channel may be set up and the memory key may be encrypted using a different shared key, which, optionally, may be blinded with a different random number.

[0114] To enable secure determination of proof-of-execution (in short referred to as e- proof) of a distributed application and certified execution of such distributed application, a CPUF device may be configured to determine a proof of execution for an executed program part A. An example of a CPUF function that can generate a proof of execution for a software program and an associated CPUF function that is configured to evaluate a generated proof execution is described in the article by Skoric et al., “Flowchart description of security primitives for controlled physical unclonable functions". The generated proof of execution may include the program part itself, its inputs and outputs.

[0115] Fig. 7 depicts a CPUF device 702 comprising an e-proof generator module according to an embodiment. As shown in the figure, the CPUF-based e-proof generator module may include a SC handler 704, which is configured to receive input information, which may include a first program part prog for which the proof needs to be computed and - optionally - further input parameters (referred to in the figure as input). As will be described hereunder in greater detail, the further input parameters may include one or more further e-proofs associated with further software parts, which are needed to execute the first program part.f

[0116] Based on the input information, the CPUF device may generate output information, including a proof-of-execution (also referred to as e-proof), i.e. information indicating that a program part has been executed on the device that holds the CPUF. To that end, the CPUF device may include a secure function 706, e.g. a hash function hash3 for hashing at least part of the input information (e.g. the program part and - depending on the situation - an e-proof of a program part that has a lower hierarchy than the program part for which an e-proof is computed , an execution module 708 for executing the program part, which is configured to receive the software part and the input information that is needed for executing the program part and compute a program output result (referred to as res). The CPUF device may further include an e-proof generator function 710, which is configured to receive at its input: the output res of the executed program part, the program part and in some embodiments in the form of one or more hash values h and CPR data, in this case C and w of the CPR, that is used for setting up the secure channel. The secure function may generate one or more unique value h based on the program part and one or more input parameters. Any unauthorized change to the program and / or input parameters will change the output of the secure function. This way, the program part and the input parameters are protected from unauthorized modifications. Based on the input information, the function generates an e-proof associated with an executed program part.

[0117] The result of the executed program part res and the e-proof may be combined with the other parameters for computing the e-proof and stored as e-proof information for later use. The e-proof information may for example include the parameters {C, w, h, res, input, e- proof}, wherein the hash value h may be computed based on at least part of the program part and other input parameters, such as an e-proof of a program part that has a lower hierarchy than the program part for which an e-proof is computed.

[0118] In an embodiment, the e-proof generator function may be implemented as a message authentication code (MAC) algorithm using k as the key, or using a keyed MAC. Security is guaranteed based on the fact that the ‘internal’ secret key k (generated by feeding the PUF with a challenge and helper data w) is only known to the CPUF device. This way, it is not possible to forge the e-proof certificate, not even by a user that is on the system having access to R = hash2(k), or a trusted enrollment authority.

[0119] When it is desired to show a third party that the program part that was executed by the CPUF device generated a result res, the e-proof information {C, w, h, res, e-proof} associated the program part may be sent to a CPUF device that is configured as an e-proof verification module. In some embodiment, the e-proof information may include further information such as address information, e.g. an URL or the like, of the CPUF device that has sent the e- proof information and that wants to receive a response from the verification module.

[0120] Fig. 8 depicts a CPUF device comprising an e-proof verification module according to an embodiment. As shown in this figure, the CPUF-based e-proof verification module may include a secure channel handler 804, a PUF 806, a REP function 808 and an e-proof verification function 810. Once the e-proof information is received by the CPUF-based e-proof verification module, it may use a CRP to set up a secure channel with the CPUF device that wants to receive a response from the verification module. The CPUF-based e-proof verification module may then execute a verification protocol over the secure channel to check the consistency between the e- proof and the ‘certified’ e-proof information {C, w, h, res, e-proof} and the secret key k, wherein h may be defined as a hash value (or a number of hash values) of the program part and the input parameters hash3(prog, input). These input parameters may include an e-proof of a program part of a lower hierarchy than the program part for which the e-proof is computed.

[0121] As shown in the figure, the protocol may include generation of the secret key k based on CRP data, in this case the challenge C and helper data w, the PUF 806 and the REP function 808. Then, the e-proof information and k may be provided to the input of the e-proof verification function 810 to generate an e-proof and to check if this generated e-proof matches the e-proof in the e-proof information. If the e-proof is generated based on a MAC then the consistency check executed by the verification function is also a MAC.

[0122] Fig. 9 depicts a high-level protocol flow of an CPUF-based e-proof generation and verification process according to an embodiment. As shown in the figure, the process may start with two CPUF devices, first and second nodes 900I,2, to establish a secure channel (step 902). In this example, the second node is a CPUF device that both capable to generate an e-proof of an execution of a program part and to verify an e-proof. Then, in a first phase 904 an e-proof may be created based on a CPR of the CPUF device. To that end, the first node may send a first program part and input parameters 906 over the secure channel to the second node (step 908). The second node may execute the program part and generate e-proof information (step 910) as described with reference to Fig. 7. Here, the e-proof information may include CRP data, e.g. C and w, h, res and e-proof. The determined e-proof information may be sent to first node (step 912), which may store the information for later verification.

[0123] Then, in a second phase 916 the e-proof may be verified based on the e-proof information 914, including a hash value that is computed based on the program and optionally input parameters. This information may be sent to the second node (step 918) (or another further node comprising a CPUF device that is capable of verifying an e-proof) which verifies the e-proof (step 920) as described with reference to Fig. 8. The result of the verification which indicates whether or not the program part was executed by a CPUF may be sent back to the first CPUF device (step 922)

[0124] The functions and protocols described with reference to Fig. 7-9 may be used in a distributed environment including a network of CPUF devices as described with reference to the embodiments in this disclosure (e.g. the embodiment illustrated in Fig. 3) wherein each of the CPUF devices at least have the e-proof generation functionality as described with reference to Fig. 7. In that case, one of the CPUF devices, a first CPUF device, may be configured to manage execution of a software application comprising program parts that need to be executed on different CPUF devices. To that end, the first CPUF device may distribute each of the program parts to a designated CPUF device in the network of CPUF devices. Thereafter, the program parts may be executed in a certain hierarchical order, wherein the result of the execution of a first program part may be needed as input for executing a subsequent second program part that is lower in hierarchy.

[0125] Fig. 10 illustrates a set of CPUF devices 1002i^ executing program parts and generating associated e-proofs according to an embodiment. Here, the computation of an e- proof, e.g. e-proof 1004s computed by CPUF device 1002s, may depend on the results generated by executed program parts and e-proofs computed by other CPUF devices, e.g. CPUF devices 1002i and 10022. Hence, for each program part in the hierarchy a separate proof-of-execution may be computed based on input and output information and the program part. The proof of executions, input and outputs and program parts may be collected by the CPUF device that forms the root in the hierarchy. The root then computes a proof-of-execution of its own program part based on inputs and outputs, as well as the other proof-of-executions and associated inputs and outputs lower in the hierarchy. This information may be stored in such a way that the hierarchy of the e-proofs is preserved.

[0126] Fig. 11 depicts an example of the hierarchical dependency of e-proofs associated with executing a distributed number of program parts by difference CPUF devices. The figure depicts a data structure comprising five program parts Ao, AI ,A2 A2,o, A2,I , wherein program part Ao hierarchically depends on sub-program parts Ai and A2 and (sub)program part A2 again hierarchically depends on sub-program parts A2,O and A2,I 11061,2. Thus, computation of the e- proof of A2 requires computation of sub-proofs of A2,o and A2,I and computation of the e-proof of Ao 1102 requires computation of sub-proofs of A1 and A2 1104I,2.

[0127] Fig. 12 depicts an example a hierarchical tree structure of proofs associated with the trusted execution of a program parts in a network of CPUF devices according to an embodiment. The tree structure depicts the hierarchy of the proofs of execution of a trusted distributed execution of a software application comprising multiple software parts. These software parts may be executed using a network of CPUF devices as described with reference to the embodiments in this disclosure. As shown in the figure, when executing the software parts in a distributed way, the proofs have a hierarchical dependency that matches the hierarchical dependency of the software parts. Thus, computation of a proof-of-execution for A3, 0 by a CPUF device requires both software part A3 and three sub-proofs As.i, A3, 2 and A3, 312061-3 as input to the e-proof. This proof A3, 0 may be referred to as combined proof A3. Similarly, computation of a proof-of-execution for Ao 1202 by the root CPUF device requires the software part Ao and four sub-proofs A1.A2.A4 and combined proof A3 1204I-3 as input.

[0128] The tree structure illustrates that multiple sub-hierarchies can exist when executing program parts of a program in a distributed way. To create multiple e-proofs, a CPUF device or a controller of the CPUF network may provide the program parts and inputs over a secure channel to different CPUF devices. Then, the program parts are executed and e-proof information is generated, wherein the e-proof information may include CRP data, the program part, the output of the executed program part, input parameters and an e-proof, e.g. {C, w, prog, res, input, e-proof}. The e-proof information may include further information including (but not limited to) user data, CRP data, and other auxiliary data, that an application or user may want to include.

[0129] The proofs may be structured in a file having a data structure that includes information regarding the hierarchy of the proofs (i.e. the root, nodes and leaves of the tree structure). In an embodiment, each of the proofs may be associated with a node identifier, which identifies an CPUF device that created the e-proof. The node identifier may be an URL or a device identifier, such that during the verification process, an e-proof associated with program part can be sent to an e-proof verification module of a CPUF device that created the e-proof.

[0130] Fig. 13 depicts a protocol flow of a method for trusted execution of program parts in a network of CPUF devices according to an embodiment. Here, the CPUF devices may also be referred to as nodes. As shown in the figure, the process may include a phase wherein secure channels are set up between the nodes of the network. In particular, a secure channel may be set up between a first and second node (step 1304) and a secure channel may be set up between the second and third node (step 1306). In some embodiments, a secure channel may also be established between the first and the second node.

[0131] Then, an e-proof creation phase 1308 may start wherein the first node may distribute the first and second program parts to the second and third node respectively so that these program parts can be executed in a hierarchical order starting with the lower-order second program part and subsequently the first program part. When starting the execution of the program parts in hierarchical order, the third node may execute the second program part and generate e- proof information associated with the execution of the second program part (step 1316). The e- proof information associated with the second program part may include an eproof2(prog2), a result res2 and the information associated with the CRP, in this case C2 and w2.

[0132] This e-proof information may be sent to node 2 (step 1318), which subsequently executes the first program part and computes the associated e-proof information (step 1320). In this case, e-proof1 is computed using the first program part progl and e-proof2 as input data, i.e. e-proof 1 (prog 1 ,e-proof2). Then, the second node sends the e-proof information associated with the execution of the first and second program part to the first node (step 1322), which may store the combined e-proof information in a memory for verification. As shown in the figure, the combined e-proof information 1324 may include the hash values, the results of the execution, the e-proofs and the challenge and helper data associated with the first and second program parts. Hence, the e-proof creation process starts at the leaves of the combined proof. Every proof in the hierarchical tree is generated node by node all the way up to the root of the tree, taken into account the inputs, the outputs and the program part at each node. In the verification phase 1310, the first node may send the e-proof information that is needed to verify the e-proofs to the second and third node (steps 1326,1328). Based on the e- proof information associated with the second program part, i.e. {hash2(prog2), res2, e-proof2, C2, w2}, the third node may verify e-proof2 (step 1330). Then, third node may send the outcome of the verification process to the second node (step 1332). If the outcome of the verification process is positive, the second node may verify e-proof1 based on the e-proof information associated with the first program part, i.e. {hashl (progl), res1 , e-proof1 , C1 , w1} and based on the e-proof2 as input (step 1334). Here, based on e-proof2 may refer to a hash value of e-proof2 as for example shown in Fig. 8. The second node may send the outcome of the verification process associated with the first program part to the first node (step 1334).

[0133] While the hierarchical tree structure of the combined proof-of-execution in the example of Fig. 13 is very simple (a hierarchical tree with one root and one leaf), the protocol can be easily extended to schemes for processing more complex hierarchical tree structures as e.g. shown in Fig. 11 and 12. The verification of a distributed proof-of-execution requires every subpart of the proof to be verified on each of the devices separately. Similar to the generation of the e-proof, the proof verification starts at the leaves of tree representing the combined proof. Every proof in the hierarchical tree is verified, node by node, all the way up to the root of the tree. The e-proof verification module may respond with a message, e.g. a binary yes / no answer, indicating whether the proof is correct or not. A proof can only be accepted if all of the sub proofs verification outcomes are yes / correct.

[0134] Fig. 14 depicts method for trusted execution of software parts in a network of CPUF devices according to an embodiment. As show in the figure, secure channels between controllable physical unclonable function (CPUF) devices may be established based on one or more challenge response pairs (CRPs) (step 1402). Here, the CPUF devices from a network, wherein each CPUF device comprises a physical unclonable function (PUF) circuit controlled by a secure channel handler configured to establish a secret key associated with a secure channel based on one of the one or more CPRs.

[0135] The method may further comprise a step 1404 of distributing program parts forming a software application over the secure channels to at least part of the CPUF devices, wherein the program parts need to be executed on the different CPUF devices in a predetermined hierarchical order. Here, the distribution of the program parts may comprise sending a first program part to a first CPUF device in the network and a second program part to a second CPUF device in the network, the second program part being of a lower hierarchy than the first program part.

[0136] Further, the method may include a step 1406 of receiving combined proof-of- execution information associated with the distributed execution of the software application, wherein the combined proof-of-execution may include a first and second execution result associated with the execution by the first and second CPLIF device of the first and second program parts respectively, a first and second proof-of-execution, and a first and second PUF challenge.

[0137] The second proof-of-execution may be computed by a second proof of execution function of the second CPLIF device using the second program part, the second execution result and the second PUF challenge as input parameters to the second proof of execution function and the first proof-of-execution being computed by a first proof of execution function of the first CPUF device using the first program part, the first execution result, the first PUF challenge and the second proof of execution as input parameters to the first proof of execution function.

[0138] The combined proof-of-execution information may be stored a data file, wherein the proof-of-execution information further comprises information about the hierarchy of the first and second program parts. Further, first and second proof-of-execution may be associated with a first and second node identifier, preferably an URL or a device identifier, for identifying the first and second CPUF device respectively. This way, the combined proof-of- execution information may be used at a later stage to check the validly of the generated proof-of-executions.

[0139] In that case, the method for trusted execution of software parts may include the step of sending the first proof-of-execution information to the first CPUF device and the second first proof-of-execution information to the second CPUF device; and, receiving verification information, the verification information including first verification information indicative of the validity of the first proof-of-execution, computed based on a first proof verification function of the first CPUF device, the first proof-of-execution information and the second proof-of-execution; and, second verification information indicative of the validity of the second proof-of-execution computed based on a second proof verification function of the second CPUF device and the second proof-of-execution information.

[0140] Here, the second proof verification function may an input for receiving the second CRP data, the second execution result, information about the second program part and the second proof-of-execution and an output for outputting the second verification information and the first proof verification may include an input for receiving the first CRP data, the first execution result, information about the first program part and the second proof- of-execution and an output for outputting the second verification information.

[0141] As described with reference to Fig. 3, when the program parts are executed by a network of CPUF devices, a CPUF device may access data stored in a memory of another CPUF device. Fig. 15A and 15B depict a method for secure memory transfer in a network of CPUF devices 1502in-i Here, a CPUF device in the network may also be referred to as a node. In this example, a second node, e.g. node n-1 , that executes a program part may want to process data that are stored on a memory bank 1500, which is controlled by a first node 1 1502i. To that end, a data connection for secure memory transfer needs to be established between nodel and node n-1.

[0142] Depending on the implementation, communication between the two nodes may be established in different ways. In an embodiment, communication may be established using a direct secure channel between nodel and node n-1. Such secure channel may for example be established based on the protocol as described with reference to Fig. 6. In other another embodiment, communication may be established using a network scheme wherein the network is controlled by a network controller. For example, a plurality of intermediate nodes may be located between node 1 and node n-1. In that case, a network handler (not shown) may be configured to control the nodes to establish secure connections between the nodes that form a path through the network connecting node 1 with node n-1. Further, secure memory transfer is realized based on a CPUF-based shared secret that is shared between node 1 and node n-1.

[0143] In an embodiment, the network of nodes may form an overlay network that is managed by a software defined infrastructure (SDI) controller. In such scheme, the controller may configure node 1 and node n-1 to share a CPUF-based shared secret that is used by the overlay network to transfer encrypted data of the shared memory to a node. This scheme will be described in more detail with reference to Fig. 16.

[0144] Hence, node 1 and node n-1 may setup either setup a direct secure channel or a shared secret for secure memory transfer. Both can be established by using the secure channel initialization of the CPUF device: a direct secure channel may be used for data transfer between node 1 and node n-1 , while a network scheme may use the CPUF-based shared secret to send data over the network from node 1 to node n-1.

[0145] Fig. 15A depicts a scheme wherein nodes in a network of CPUF devices may set up secure channels between pairs of CPUF devices that form a path between node 1 and node n-1 . In this scheme, pairs of CPUF devices in the network share a secret that is used to encrypt data over secure channels between the pairs of CPUF devices. As shown in the figure, block 1502 schematically illustrates secure channel setup between nodes 1 and 2, block 1504 a secure channel setup between nodes n-2 and n-1 , 1506 a secure channel between node k-1 and k (k<n) and block 508 a secure channel setup between node n-2 and n-1 and block 1507 a secure channel setup between node 1 and n-1. These steps may define the initialization of a network of CPUF-based nodes, wherein pairs of nodes share a CPUF based shared secret. The initialization may be instantiated by a network controller (not shown).

[0146] Allocation of the shared memory location by node 1 may be initiated by the network controller of by node 1. To that end, a shared memory locationoand an associated shared memory identifier may be defined. Further, a memory key mk0may be determined by a key generating function of node 1. The memory key may be used to encrypt data that is stored in the shared memory location. After allocating the memory, node 1 may encrypt the data that it wants to share and copy the encrypted data Co= ENC(mk0,Mo)to memory region. An example of the generation of such memory key and storage of encrypted data is described with reference to Fig. 4.

[0147] Node 1 , in particular the shared memory controller of node 1 , may further determine a sharing list A = gen_list(mk0) for identifying one or more nodes that access or can access the shared memory region. The list may include the memory identifierM0identifying the shared memory region and the memory key mk0, i.e. the key that is used to encrypt the data in the shared memory. The node 1 may further notify nodes in the network that a shared memory region is available. For example, node 1 may send notification messages 1509I-3 comprising the memory identifier to all nodes (e.g. using broadcasting) or to some nodes for example nodes k-1 ,k and n-1 as shown in the figure.

[0148] Fig. 15B illustrates the process of secure memory transfer in a network of CPLIF devices according to an embodiment, In this example, node n-1 may sent a request message to node 1 (step 1510) for requesting access to a shared memory Mo. In an embodiment, the request message may comprise a memory identifier identifying the shared memory region. The message may further include an identifier, e.g. a network address, for identifying node 1 , i.e. the CPLIF device that controls the shared memory region.

[0149] In response to the request, node 1 may determine if the request for access can be granted. Immediate access may not always possible. For example, the shared memory region may be temporarily locked because another node is accessing the memory. If node 1 grants access to the noden-i, node 1 may retrieve encrypted data of the shared memory region. For example, it may send a retrieve message 1512 to the memory controller, which - in response - may send a response message 1514 comprising encrypted data Coto the node. Further, it may add node n-1 to the sharing list. To that end, the node may be identified using a unique identifier, e.g. an CPLIF identifier or a chiplet identifier. A CPUF- based shared secret k^^ between the two nodes may be used to encrypt the memory key mk0of the shared memory Mointo encrypted ey ekn-= ENC kl n-1,mk0'). The shared memory controller of node 1 may administer that that node n-1 uses shared secret k^n^ by adding encrypted key ekn-to the sharing list

[0150] After adding the node to the list, node n-1 can request access to the shared memory using the memory identifier. The first node may send the encrypted memory key e / cand the encrypted data C0over the network to the node n-1 (step 1512). In case of a direct secure channel (not shown), it may be sent directly to the node n-1 .

[0151] In case of secure transfer of the encrypted data over the network from node 1 to node n-1 (as shown in Fig. 15B), encrypted data Coand the encrypted key e kn_ may be sent via the secure channels established by the intermediate nodes between node 1 and node n-1 . This means each time the encrypted data and the encrypted key are sent over a secure channel, the encrypted data and the encrypted key are encrypted and decrypted using a key that is shared between the two nodes associated with the secure channel. For example, when sent over the secure channel between node 1 and node 2 as shown in Fig. 2, Coand ekn-are encrypted based on a CPUF-based secured key / c1 2that is shared between node 1 and node 2, sent over the secure channel to node 2, which decrypts the encrypted Coand . This process is repeated for all secure channels along the network path between node 1 and node n-1. This process is schematically denoted in the figure by step 1518,

[0152] Once node n-1 receives the encrypted information Coand ek^, it may first decrypt the encrypted memory key ekn-using the shared secret k^n^ resulting in decrypted memory key mk0. Node n-1 can then use the memory key to decrypt the encrypted data (block 1520) into clear data Mo, which can be processed by node n-1.

[0153] In an embodiment, node n-1 may process the data into modified data and send the modified data back in the shared memory region. Before sending it back to the node 1 , it first may re-encrypt the modified data with the shared memory key into encrypted modified memory data Co. Once re-encrypted the data, the encrypted modified memory data Coand the memory identifier may be sent over the network back to node 1 (step 1516). The transmission of the encrypted modified memory data to node 1 may be executed in a similar was as the encrypted memory data that was sent to node n-1 . In some embodiment, also the memory key that was used to encrypt the modified memory data may be encrypted by the shared key.

[0154] After receiving the encrypted data, node 1 store the data in the shared memory region. In an embodiment, node 1 may replace (part of) the data in the memory with the modified memory data (step 1524). In an embodiment, before storing the modified memory data in the shared memory region, node 1 may execute a verification step. This verification step may include checking if the node n-1 is allowed to make changes to the shared memory region. In a further embodiment, the verification step may include checking if the memory key decrypted by node n-1 and encrypted again by node n-1 after reencrypting the modified memory data is correct. In an embodiment, node n-1 may generate proof and or a signature that is has processed the memory data using a PUF-based authentication code or fingerprint, attached to the encrypted memory data block that is sent to node 1. Node 1 can verify the signature on receiving the block or store the proof for later use.

[0155] In an embodiment, to avoid known plaintext attacks node 1 may include a counter and / or a random number to be added (concatenated) to the memory data before encryption. This counter and / or random number can be removed after decryption). In case of a counter, a counter value may be incremented as a form of keeping track the number of modifications to the memory.

[0156] Hence, as illustrated in the figures, a secure memory transfer in a network of CPLIF devices is provided, wherein the method may include forming a shared memory location in a data storage associated with a first controllable physical unclonable function (CPLIF) device. The first CPLIF device may be part of a network of CPLIF devices. Further, the shared memory location may comprise first data encrypted using a memory key. Then, the first CPLIF device may receive a request from a second CPLIF device in the network of CPLIF devices for accessing the encrypted first data stored in the shared memory location. The second CPLIF device shares a secret key with the first CPLIF device based on one or more challenge response pairs of the CPLIF of the first CPLIF device. The first CPLIF device may encrypt the memory key associated with the shared memory location with the shared secret key and transmit the encrypted shared secret key, the encrypted first data to the second CPLIF device for processing at least part of the first data into second data.

[0157] The secure transfer of the shared memory data in a network of CPLIF devices provides transfer and storage of data based on the intrinsic properties of the PUF, i.e. based on the key material that is generated by the CPLIF devices. Data transport is based on secure channels that are setup between CPUF-devices so that granting access to the encrypted data in the shared memory is only possible by CPLIF devices that have a secure channel setup with the CPLIF device that manages the shared memory.

[0158] After the processing of the first data by the second CPLIF device into second data, the first CPLIF device may receive the second data by the second CPLIF device, wherein the second data is encrypted by the second CPLIF device using the memory key. The first node may subsequently store (part of) the first encrypted data in the shared memory.

[0159] After a certain period and / or actions by one or more CPLIF devices in the network, access of a CPLIF device to the shared memory region may be revoked by the CPLIF device that is managing the shared memory region. The shared memory controller of this CPLIF device may check the sharing list to check if the CPLIF device for which access needs to be revoked still has access to the shared memory region. If this is the case, a lock is created blocking the CPLIF device access to the shared memory region. A new memory key m / may be generated by shared memory controller and all data of the old shared memory may be copied to a new shared memory region by first decrypting the old shared memory region using the old memory key m / coand subsequently encrypting the data based on the new memory key mk . A new memory identifier may be assigned to the new shared memory region. Further, mk may be encrypted using each of the shared secret keys between the CPLIF that manages the shared memory region and CPLIF devices in the network that still have the right to access the memory data. The shared memory controller may create a list including the memory identifier, the encrypted memory keys and identifiers for identifying the CPLIF devices.

[0160] As described with reference to Fig. 3, CPUF devices may form nodes of a network of CPUF-based chiplets. The chipies may form any kind of suitable network topology and a network manager may be configured and control the network of chiplets. In an embodiment, the network may include public (clear) channels for communicating data between a CPUF based chiplet that manages a shared memory and other CPUF based chiplets in the network. For example, in an embodiment, an encrypted memory block from a shared memory region may be forwarded over a clear channel between chiplets. For example, the encrypted block may be forwarded by a network on chip (NOC) router using a plain forward protocol. In such protocol, the router may forward the encrypted block over the chiplet network towards its destination. Once the encrypted block is at the destination, it can be decrypted and processed. In this embodiment, no decryption and encryption is needed when sending the encrypted data from one node to the next node in the network.

[0161] In another embodiment, the network may include CPUF-based secure channels as for example described with reference to Fig. 6. Hence, a forward hop protocol may be used wherein an encrypted block is transferred over a secure channel from one CPUF device to the next CPUF device until the destination CPUF device has been reached. Each hop to the next CPUF device will add another encryption layer until the encrypted block has reached the designation, such that the encrypted block is never transferred in plaintext between chiplets.

[0162] In an embodiment, every chiplet can generate a proof that the memory block has been “seen” and that it has been forwarded by the chiplet. The proof can be either send to the originator or the destination depending on the requirement. The proof can be combined into a single proof.

[0163] Fig. 16 illustrates a system for managing a network of CPUF devices according to an embodiment. In particular, the figure illustrates an overlay network 1612 comprising a plurality of CPUF devices 1606i-5that overlays an underlay network 1610 of network nodes 1604i.? including network devices such as routers, switches, repeaters and / or gateways. The underlay network may for example the Internet. The CPLIF devices may be hosted on a subset nodes of the underlay network and managed by one or more software defined infrastructure SDI controllers 1608. The controller may be configured to control the distributed execution of program parts as described with reference to the embodiments in this disclosure. Further, the controller may be configured to control the setup of the secure channels between pairs of nodes to setup the network of CPLIF devices, the setup of a shared memory and the secure memory transfer illustrated as illustrated in Fig. 15. Known network protocols may be used for routing data packets over the network and for network addressing such as IPv4 and IPv6.

[0164] The secure overlay network depicted in Fig. 16 is only one a plurality of overlay networks that can be used with the embodiments described in this disclosure. Suitable overlay network architectures are described in associated European application no. 24171730.5 with title “secure overlay network’ which is hereby incorporated by reference in this application.

[0165] The CPLIF devices described with reference to the embodiments in this disclosure can be to be implemented as chiplets. Networks of CPUF-based chiplets may include a network of CPUF-based chiplets implemented on a single interconnecting substrate, a network of CPUF-based chiplets implemented on different interconnecting substrates which can communicate with each other using a suitable communication interface, e.g. a bus. Fig. 17 depicts an example of a CPUF network wherein CPUF devices 1702-1-4 may be implemented as CPUF chiplet and organized with other chiplets 1710-1-4- 1720-1-4 on a substrate includes an interaction structure 1722 for electrically connecting the chiplets. CPUF chiplets on different substrates may be connected via a bus structure 1724 or a network (not shown). Such network of CPUF chiplets may be configured to execute the schemes as described in this disclosure.

[0166] The techniques of this disclosure may be implemented in a wide variety of devices or apparatuses, including a wireless handset, an integrated circuit (IC) or a set of ICs (e.g., a chip set). Various components, modules, or units are described in this disclosure to emphasize functional aspects of devices configured to perform the disclosed techniques, but do not necessarily require realization by different hardware units. Rather, as described above, various units may be combined in a codec hardware unit or provided by a collection of interoperative hardware units, including one or more processors as described above, in conjunction with suitable software and / or firmware.

[0167] 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 the present invention has been presented for purposes of illustration and description, but is not intended to be exhaustive or limited to the invention 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 invention. The embodiment was chosen and described in order to best explain the principles of the invention and the practical application, and to enable others of ordinary skill in the art to understand the invention for various embodiments with various modifications as are suited to the particular use contemplated.

Claims

36CLAIMS1. A method for trusted execution of software parts in a network of CPUF devices, the method comprising: establishing secure channels between controllable physical unclonable function (CPUF) devices based on challenge response pair (CRP) data, the CPUF devices defining a network, each CPUF device comprising a physical unclonable function (PUF) circuit controlled by a secure channel handler configured to establish a secret key associated with a secure channel based on CRP data; distributing program parts forming a software application over the secure channels to at least part of the CPUF devices, wherein the program parts need to be executed on the different CPUF devices in a predetermined hierarchical order, the distributing including sending a first program part to a first CPUF device in the network and a second program part to a second CPUF device in the network, the second program part being of a lower hierarchy than the first program part; and, receiving combined proof-of-execution information associated with the distributed execution of the software application, the combined proof-of-execution information including first proof-of-execution information comprising the first program part, first CRP data and a first proof-of-execution and second proof-of-execution information comprising the second program part, second CRP data and a second proof-of-execution, wherein the second proof-of-execution is computed by a second proof generation function of the second CPUF device based on information associated with the second program part, the second execution result and the second CRP data and the first proof-of-execution is computed by a first proof generation function of the first CPUF device based on information associated with the first program part, the first execution result, the first CRP data and the second proof-of-execution.

2. Method according to claim 1 further comprising: storing the combined proof-of-execution information in a data file, wherein the proof-of-execution information further comprises information about the hierarchy of the first and second program parts.

3. Method according to claim 1 and 2 wherein the first and second proof-of- execution are associated with a first and second node identifier, preferably an URL or a device identifier, for identifying the first and second CPUF device respectively.

4. Method according to any of claims 1-3 wherein the information associated with the first program part includes a hash value computed based on at least part of the first37 program part and wherein the information about the second program part includes a hash value computed based on at least part of the second program part.

5. Method according to any of claims 1-4 further comprising: sending the first proof-of-execution information to the first CPLIF device and the second first proof-of-execution information to the second CPLIF device; and, receiving verification information, the verification information including first verification information indicative of the validity of the first proof-of-execution, computed based on a first proof verification function of the first CPLIF device, the first proof-of- execution information and the second proof-of-execution; and, second verification information indicative of the validity of the second proof-of-execution computed based on a second proof verification function of the second CPLIF device and the second proof-of- execution information, wherein optionally, the second proof verification function includes an input for receiving the second CRP data, the second execution result, information about the second program part and the second proof-of-execution and an output for outputting the second verification information and wherein the first proof verification includes an input for receiving the first CRP data, the first execution result, information about the first program part and the second proof-of-execution and an output for outputting the second verification information.

6. Method according to any of claims 1-5 further comprising: establishing secure channels between pairs of CPLIF devices in the network based on secret keys shared between the pairs of CPLIF devices, each shared secret key being based on challenge response pairs associated with the pairs; and, sending the encrypted shared secret key and the encrypted first data from the first CPLIF device to the second CPLIF device over at least part of the established secure channels.

7. Method according to any of claims 1-6 wherein the network of CPLIF devices form an overlay network overlying an underlay network, the overlay network being controlled by a controller, which is configured to establish a secure connection between the first CPLIF device and the second CPLIF based on the shared secret key; and / or, wherein the CPLIF devices are implemented as integrated circuit dies, system on chip dies or chiplets; and / or, wherein the CPLIF devices are identified by a unique identifier, preferably a chip or chiplet ID.

8. A controlled physical unclonable function (CPLIF) device, preferably an die or system on a chip, comprising: a PUF circuit controlled by a secure channel handler configured to establish a secret key based on a challenge response pair (CRP); an encryption function for encrypting data based on an encryption key; a decryption function for decrypting encrypted data based on a decryption key; a network module for communicating with other CPLIF devices in a network of CPLIF devices; and, a computer readable storage medium having computer readable program code embodied therewith, and a processor, coupled to the computer readable storage medium, wherein responsive to executing the computer readable program code, the processor being configured to perform executable operations comprising: establishing secure channels between controllable physical unclonable function (CPLIF) devices in the network based on challenge response pair (CRP) data; distributing program parts forming a software application over the secure channels to at least part of the CPLIF devices, wherein the program parts need to be executed on the different CPLIF devices in a predetermined hierarchical order, the distributing including sending a first program part to a first CPLIF device in the network and a second program part to a second CPLIF device in the network, the second program part being of a lower hierarchy than the first program part; and, receiving combined proof-of-execution information associated with the distributed execution of the software application, the combined proof-of-execution information including first proof-of-execution information comprising the first program part, first CRP data and a first proof-of-execution and second proof-of-execution information comprising the second program part, second CRP data and a second proof-of-execution, wherein the second proof-of-execution is computed by a second proof generation function of the second CPLIF device based on information associated with the second program part, the second execution result and the second CRP data and the first proof-of-execution is computed by a first proof generation function of the first CPLIF device based on information associated with the first program part, the first execution result, the first CRP data and the second proof of execution.

9. Device according to claim 8 further comprising: storing the combined proof-of-execution information in a data file, wherein the proof-of-execution information further comprises information about the hierarchy of the first and second program parts.

10. Device according to claim 8 and 9 wherein the first and second proof-of- execution are associated with a first and second node identifier, preferably an URL or a device identifier, for identifying the first and second CPUF device respectively; and / or, wherein the information about the first program part includes a hash value computed based on at least part of the first program part and wherein the information about the second program part includes a hash value computed based on with at least part of the second program part.

11. Device according to any of claims 8-10 further comprising: sending the first proof-of-execution information to the first CPUF device and the second first proof-of-execution information to the second CPUF device; and, receiving verification information, the verification information including first verification information indicative of the validity of the first proof-of-execution, computed based on a first proof verification function of the first CPUF device, the first proof-of- execution information and the second proof-of-execution; and, second verification information indicative of the validity of the second proof-of-execution computed based on a second proof verification function of the second CPUF device and the second proof-of- execution information.

12. A controller for controlling a network of CPUF devices, the controller being configured to: establishing secure channels between controllable physical unclonable function (CPUF) devices based on challenge response pair (CRP) data, the CPUF devices defining a network, each CPUF device comprising a physical unclonable function (PUF) circuit controlled by a secure channel handler configured to establish a secret key associated with a secure channel based on CRP data; distributing program parts forming a software application over the secure channels to at least part of the CPUF devices, wherein the program parts need to be executed on the different CPUF devices in a predetermined hierarchical order, the distributing including sending a first program part to a first CPUF device in the network and a second program part to a second CPUF device in the network, the second program part being of a lower hierarchy than the first program part; and, receiving combined proof-of-execution information associated with the distributed execution of the software application, the combined proof-of-execution information including first proof-of-execution information comprising the first program part, first CRP data and a first proof-of-execution and second proof-of-execution information comprising the second program part, second CRP data and a second proof-of-execution,wherein the second proof-of-execution is computed by a second proof generation function of the second CPLIF device based on information associated with the second program part, the second execution result and the second CRP data and the first proof-of-execution is computed by a first proof generation function of the first CPLIF device based on information about the first program part, the first execution result, the first CRP data and the second proof of execution.

13. A controlled physical unclonable function (CPLIF) device, preferably a die or system on a chip, configured to generate a proof-of-execution for one or more program parts of a distributed software application, wherein the one or more program parts need to be executed on different CPLIF devices in a predetermined hierarchical order, the CPLIF device comprising: a PUF circuit controlled by a secure channel handler configured to establish a secret key based on a challenge response pair (CRP) data and to establish a secure channel with one or more further CPLIF devices based on the secret key; a network module for communicating with the one or more further CPLIF devices in a network of CPLIF devices; a secure function, preferably a hash function, configured to receive input information from the secure channel handler and to compute a secure value, preferably a hash value, based on the input information, the input information including a first program part of the distributed software application, a second proof-of-execution associated with a second program part of the distributed software application computed by a further CPLIF device and, optionally, one or more further input parameters associated with the first program part, wherein the first and second program part are associated with a first and second hierarchy, the second hierarchy being lower than the first hierarchy; a program execution module configured to compute an execution result based on the first program part and, optionally, the one or more further input parameters; and, a proof-of-execution generator configured to compute a first proof-of-execution associated with the first program part based on the secure value, the execution result and CRP data, the first proof-of-execution indicating that the first program part has been executed by the CPLIF device.

14. A controlled physical unclonable function (CPLIF) device, preferably a die or system on a chip, configured to evaluate a proof-of-execution for one or more program parts of a distributed software application, wherein the program parts need to be executed on different CPLIF devices in a predetermined hierarchical order, the CPLIF device comprising:41 a PUF circuit controlled by a secure channel handler configured to establish a secret key based on a challenge response pair (CRP) data and to establish a secure channel with one or more further CPLIF devices based on the secret key; a network module for communicating with one or more further CPLIF devices in a network of CPLIF devices; wherein the secure channel handler is configured to receive:- an execution result computed by the CPLIF device based on a first program part of the distributed software application and, optionally, based on one or more further input parameters associated with the first program part;- a secure value, preferably a hash value, computed by a secure function of the CPLIF device based on the first program part of the distributed software application, a second proof-of-execution associated with a second program part of the distributed software application computed by a further CPLIF device and, optionally, one or more further input parameters associated with the first program part, wherein the first and second program part are associated with a first and second hierarchy respectively, the second hierarchy being lower than the first hierarchy;- CRP data that is used by the CPLIF device to compute the first proof-of- execution;- a first proof-of-execution associated with the first program part computed by the CPLIF device; the CPLIF device further comprising proof-of-execution module that is configured to generate verification information based on the execution result, the secure value, the first proof-of-execution and the CRP data, wherein the verification information includes information indicating whether or not the first program part has been executed by the CPLIF device.

15. Computer program product comprising software code portions configured for, when run in the memory of a controlled physical unclonable function (CPLIF) device, executing the method steps according to any of claims 1-7, preferably the CPLIF device comprising: a PUF controlled by a secure channel handler configured to establish a secret key based on a challenge response pair; an encryption function for encrypting data based on an encryption key; a decryption function for decrypting encrypted data based on a decryption key; a network module for communicating with other CPUF devices in a network of CPUF device; and, a processor coupled to the memory.

Images