Secure memory transfer in a network of controllable physical unclonable function devices

Abstract

A method and a device for secure memory transfer are described wherein the method comprises creating a shared memory location in a data storage associated with a first controllable physical unclonable function (CPUF) device, the first CPUF device being part of a network of CPUF devices, the shared memory location comprising first data encrypted using a memory key; receiving a request from a second CPUF device in the network of CPUF devices for accessing the encrypted first data stored in the shared memory location, the second CPUF device sharing a secret key with the first CPUF device based on one or more challenge response pairs of the CPUF of the first CPUF device; encrypting, by the first CPUF device, the memory key associated with the shared memory location with the shared secret key and transmitting the encrypted shared secret key, the encrypted first data to the second CPUF device for processing at least part of the first data into second data; and, receiving, by the first CPUF device, second data by the second CPUF device, the second data being encrypted by the second CPUF device using the memory key, and replacing at least part of the first encrypted data in the shared memory location with the second encrypted data.

Description

[0001] Secure memory transfer in a network of controllable physical unclonable function devices

[0002] Technical field

[0003] The embodiments relate to secure memory transfer in a network of controllable physical unclonable function (CPUF) devices, and, in particular, though not exclusively, to methods and systems for secure memory transfer 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 operations that require sharing of information, e.g. data, that is stored on a memory model external to the dies. Hence, from the above it follows that there is a need in the art for improved methods and systems for memory transfer in a network of CPLIF devices.

[0009] Summary

[0010] As will be appreciated by one skilled in the art, aspects of the embodiments 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. 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).

[0013] Aspects of the embodiments 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.

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

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

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

[0017] In an aspect, the embodiments in this disclosure relate to a method for secure memory transfer comprising: 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.

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

[0019] In an embodiment, the processing of the first data may include modification of the first data in second data. 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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0038] 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

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

[0040] 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;

[0041] 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;

[0042] 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

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

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

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

[0046] Brief description of the drawings

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

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

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

[0050] Fig. 4A and 4B depict an example of a secure channel between a CPUF- based chip and a data storage; Fig. 5 depicts a flow of storing and retrieving encrypted data from a memory over a secure channel;

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

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

[0053] Fig. 8 depicts a flow diagram of secure memory transfer using a CPUF-based device according to an embodiment;

[0054] Fig. 9 a system for managing a network of CPUF devices according to an embodiment;

[0055] Fig. 10 depicts an example of a network of CPUF-based chiplets;

[0056] Description of the embodiments

[0057] The embodiments in this disclosure relate to secure memory transfer in a distributed environment using controlled physical unclonable function (CPUF) technology. 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.

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

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

[0060] Fig. 1 A and 1 B depict schematics of a device for establishing a secure channel with an external device using a PUF. As shown in the figure the system 104 may include a device 102 comprising components. In an embodiment, the device may be a chip comprising chip components. The components may include but are not limited to one or more processors 106, e.g. one or more computer cores, a hardware-implemented physical unclonable function (PUF) 108, memory 110, an input / output interface, one or more Al accelerators 116 and one or more cryptographic accelerators 114. The input / output interface may further include a network interface. The chip may be implemented in different ways, including but not limited as an integrated circuit having e.g. a integrated circuit (IC) architecture, a system on chip (SoC) architecture or a chiplet architecture. For example, some of the components in Fig. 1A may be implemented as chiplets on an interconnecting substrate. In another embodiment, the device may be implemented using a system in package (SiP) architecture, a Heterogeneous integration (HI) chip architecture or a chiplet system architecture. Software, e.g. client software and / or applications, may be executed by the one or more processors to implement functionality and applications that make use of the PUF.

[0061] The device including the PUF and other components may hereafter be referred to as a controlled physical unclonable function CPUF device. Fig. 1B depicts simple non-limiting example a CPUF device including functions for setting up a secure channel that is associated with CRPs of the PUF. The implementation of the CPUF as shown in Fig. 1B is known from the article by Skoric et al “Flowchart description of security primitives for controlled physical unclonable functions" International Journal of Information Security, 9, p. 327-335. As shown in the figure, the CPUF device may comprise a PUF 108, one or more functions to process input and output of the PUF, including a representation (REP) function 124, a cryptographic function 126, e.g. a hash function, and a secure channel (SC) handler 128. The functions and the SC handler may be implemented in the CPUF device in any suitable manner including software, firmware, hardware and / or combinations thereof. It is noted that the CPUF functionality depicted in Fig. 1B is just one of the many possible CPUF functionalities for providing a secure channel. Further CPUF architectures that may be used in the embodiments of this disclosure are described in associated European application no. 24168018.0 with title “Controllable physically unclonable function" which is hereby incorporated by reference in this application.

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

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

[0064] As illustrated in Fig. 1B, 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. A shared secret R may be generated by applying a cryptographic hash function HASH 126 to the key k. 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.

[0065] 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 function 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 for managing the security functions and the secure channel. The CPUF device may further include a secure storage 222 for (temporarily) data and / or information for managing the security primitives, such as secure keys, challenge-response keys, helper data, etc. The secure storage may be connected to one or more processors 224, e.g. CPUs and / or GPUS, for running software to execute the functions and the secure channel handler of the CPUF device as described with reference to the embodiments in this disclosure. In an embodiment, the software may be configured as a client device, which is configured to communicated with a server (not shown). At least part of the CPUF device may be implemented in hardware or a combination of hardware and software. For example, at least part of the functions, the secure channel (SC) handler and t

[0066] 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. The 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.

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

[0068] 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 devices 302i^ forming a network of CPUF device. 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. For example,, 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. A memory bank 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).

[0069] In an exemplary use case, CPUF chip 302i may want to share data stored in a memory, e.g. memory M1;1,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.

[0070] 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 a secure channel of the CPUF of the chip. Fig. 4 and 5 depict an example of a secure channel between a CPUF device 402 and external data storage 404 according to an embodiment. To handle data storage and data retrieval between the CPUF device and the data storage, the data storage is associated with a controller that has an interface with the CPUF device.

[0071] Similar to Fig. 2, 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 c2 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.

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

[0073] 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 w2 are stored on the external storage, there is no need for the user or external program to keep a local copy of these values.

[0074] 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 included may be message M1 .

[0075] 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). 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.

[0076] To setup an external memory module for datasharing, 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 mk0may be assigned to this memory region. In an embodiment, the memory key mk0may 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.

[0077] Once the memory is set up, data can be encrypted using the memory key mk0and 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.

[0078] 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 Ciw1Ri (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 CPLIF device that has generated the pair because the response part can only be regenerated using the PUF of that particular CPLIF device. The CwR pair may be sent, e.g., by a controller, to another second CPLIF device for establishing a secure channel.

[0079] As shown in the figure, the process may start computing first security primitives by the first CPLIF device, e.g. a chip or a communication device, as shown in block 610. The computations may include generating a random number 7 from a seed The first device then encrypts challenge C2, helper data w2, and random number 1 , in value U , with a known symmetric key algorithm using the response R2. Then, C2, w2and Urmay 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).

[0080] The second CPLIF device (the same or a similar device as the first device) may generate a random number T2from a seed 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, w2and t^and stimulating the CPIIF2 with challenge C2and helper data w2to obtain response R2. This stimulation may involve performing a reproduce (REP) function, as described e.g. with reference to Fig. 2. Then, response R2may be used as a key to decrypt value Urinto challenge C2, helper data w2and random number T . This enables the second CPLIF device to validate that the first CPLIF device has knowledge of a CwR pair of the PUF of the second CPUF device by comparing if the challenge C2and 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.

[0081] If the challenge C2and the challenge C2or the helper data w2and the helper data w2are different, the second CPUF device may stop the protocol and no secure channel will be established. If, on the other hand, the challenge C2is 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.

[0082] Further, as shown in block 614, the second device may encrypt challenge Ct, helper data w1, random number^' and random number T2in value U2using the shared key R, and combine, e.g. concatenate, value U2with challenge C, and helper data w1in a message M2. Message M2 may then be sent over a channel, e.g. a public channel, to the first CPUF device (step 616). The first CPLIF device may process the second message M2 according to block 618, which includes extracting challenge Ct, helper data w1and value U2, from message M2 and stimulating the PUF of the first CPLIF device with challenge C, and helper data w1to obtain response R . This stimulation typically involves performing a reproduce (REP) function, as described earlier. Then, the first CPLIF 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 C(, helper data w(, random number T" 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.

[0083] At this point the first device can verify that random number T" is equal to random number T1. 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 Ct, that helper data is equal to helper data w1and that random number T" is equal to random number T1. If they are not equal, the first CPLIF device may stop the protocol and no secure channel is established.

[0084] 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 7 and random number T2using shared key R, and the result is message M3, which is transferred over the public channel to the second client (step 616).

[0085] Finally, in block 618 the second device may decrypt message Ma in random number T"’ and random number T2using shared key R and verifies that the second device has the correct shared key R, by comparing random number T"’ to random number T and by comparing random number T2to random number T2.

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

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

[0088] 24174171 .9 with title “an authentication protocol” which is hereby incorporated by reference in this application.

[0089] To share a memory region in a network of CPUF devices as e.g. shown in Fig. 3, a secure connection 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 connections 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.

[0090] 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 M14. 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.

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

[0092] Fig. 7A and 7B depict a method for secure memory transfer in a network of CPUF devices 702in-i according to an embodiment. 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 , wants to process data that are stored on a memory bank 700, which is controlled by a first node 1 702i. To that end, a data connection for secure memory transfer needs to be established between nodel and node n-1 .

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

[0094] 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. 9.

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

[0096] Fig. 7A 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 702 schematically illustrates secure channel setup between nodes 1 and 2, block 704 a secure channel setup between nodes n-2 and n-1 , 706 a secure channel between node k-1 and k (k<n) and block 708 a secure channel setup between node n-2 and n-1 and block 707 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).

[0097] 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 location Moand 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.

[0098] Node 1 , in particular, the shared memory controller of node 1 , may further determine a sharing list = geniist(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 709I-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.

[0099] Fig. 7B 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 710) 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.

[0100] 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 712 to the memory controller, which - in response - may send a response message 714 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 / cl n-1between 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 by adding encrypted eyekn-to the sharing listn l= addpeer( , ek^).

[0101] 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 712). In case of a direct secure channel (not shown), it may be sent directly to the node n-1.

[0102] In case of secure transfer of the encrypted data over the network from node 1 to node n-1 (as shown in Fig. 7B), encrypted data Coand the encrypted key e / cn-1may 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 e / cn_i are encrypted based on a CPUF-based secured key kr ;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 718, Once node n-1 receives the encrypted information Coand ekn-ltit may first decrypt the encrypted memory key ekn-1using the shared secret kl n-1resulting in decrypted memory key mk0. Node n-1 can then use the memory key to decrypt the encrypted data (block 720) into clear data Mo, which can be processed by node n-1.

[0103] In an embodiment, node n-1 may process the data into modified data Mand 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 CQ . Once re-encrypted the data, the encrypted modified memory data CQ and the memory identifier may be sent over the network back to node 1 (step 716). 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.

[0104] 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 724). 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 re-encrypting the modified memory data is correct. In an embodiment, node n-1 may generate proof and or a signature that it 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.

[0105] 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 of the number of modifications to the memory.

[0106] Fig. 8 depicts a flow diagram of secure memory transfer in a network of CPLIF devices according to an embodiment. In particular, the figure represents a flow diagram of a secure memory transfer as described with reference to Fig. 7 above. The method may include forming a shared memory location in a data storage associated with a first controllable physical unclonable function (CPLIF) device (step 802). 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 (step 804). 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 (step 806).

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

[0108] 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 (step 808). The first node may subsequently store (part of) the first encrypted data in the shared memory.

[0109] 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 mk1may 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 CPUF that manages the shared memory region and CPUF 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 CPUF devices. As described with reference to Fig. 3, CPUF devices may form nodes of a network of CPUF-based chiplets. The chiplets 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.

[0110] In another embodiment, the network may include CPUF-based secure channels as for example described with reference to Fig. 7. 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 destination, such that the encrypted block is never transferred in plaintext between chiplets.

[0111] In an embodiment, every chiplet can generate a proof that it seen the memory block has been “seen” and 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 in to a single proof.

[0112] Fig. 9 illustrates a system for managing a network of CPUF devices as described with reference to the embodiments. In particular, the figure illustrates an overlay network 912 comprising overlay network nodes 906i.sthat overlays an underlay network 910 of underlay network nodes 904i.?. The underlay network nodes may include network devices such as routers, switches, repeaters and / or gateways. The underlay network may be for example part of the Internet. A subset of the set of nodes forming the underlay network may comprise CPUF devices. Software, such as applications and / or clients, may be executed on the physical CPUF devices and managed by one or more software defined infrastructure (SDI) controllers 908. SDI clients and the one or more SDI controllers may define the nodes of the overlay network. The SDI controller may manage the overlay network, including execution of software by the nodes and communication between the nodes.

[0113] The SDI controller may manage for each node which software runs on the nodes of the overlay network and may check if the software is correct and valid. In order to manage the nodes, the SDI controller may require a secure connection 910i-s to that node, such that all commands and applications that are run on the node are encrypted. In addition, the SDI controller may put a helper application on the node that can interpret commands sent by the SDI controller, and execute them locally on the node, such as starting and stopping an application, configuring networking and collecting key performance indicators (KPIs) of an application. Typically, the SDI controller dictates and verifies the configuration of the secure channel(s) that each node has. For example,, 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 in Fig. 7.

[0114] Once the secure overlay network is operational, each of the overlay nodes may be configured to communicate with any other overlay node. This overlay communication may be transmitted over a high-level secure channel established between end nodes, e.g. two SDI clients, of the overlay network and controlled by the SDI controller, e, in the overlay network. Such higher-level secure communication channel may be established using a CPUF-based shared secret, e.g. one or more CRPs. One end node may allow a user or an remote application to use a service of another end node. For example, an application and / or client running on a second end node may require secure transfer of a shared memory that is managed by an application and / or client running on a first end node of the overlay network. Such secure transfer of a shared memory may be realized based on the embodiments in this disclosure. The SDI controller may be responsible for configuring protocols on the network and keeping track of node identifiers and addresses that are used on these nodes. This makes it for instance possible that the underlay network uses IPv4 while the overlay network runs an IPv6-only network, complete with addressing and routing protocols.

[0115] The secure overlay network depicted in Fig. 9 is only one example of a plurality of networks that can be used with the embodiments described in this disclosure. Any network architecture, e.g. a mesh network, wireless and / or wired, may be used to realize a network of CPUF devices. Network architectures that are particularly suitable are described in associated European application no. 24171730.5 with title “secure overlay network’ which is hereby incorporated by reference in this application.

[0116] The CPUF 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. 10 depicts an example of a CPUF network wherein CPUF devices 1002-1-4 may be implemented as CPUF chiplet and organized with other chiplets 101 O- - 1020i-4 on a substrate includes an interaction structure 1022 for electrically connecting the chiplets. CPLIF chiplets on different substrates may be connected via a bus structure 1024 or a network (not shown)

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

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

[0119] 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

CLAIMS1 . Method for secure memory transfer comprising: creating a shared memory location in a data storage associated with a first controllable physical unclonable function (CPUF) device, the first CPUF device being configured to manage the shared memory location and being part of a network of CPUF devices, the shared memory location comprising first data encrypted using a memory key; receiving a request from a second CPUF device in the network of CPUF devices for accessing the encrypted first data stored in the shared memory location, the second CPUF device sharing a secret key with the first CPUF device, the secret key being based one or more challenge response pairs shared between the first and the second CPUF device; and, encrypting, by the first CPUF 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 CPUF device for processing at least part of the first data.

2. Method according to claim 1 , wherein the processing of the first data includes modification of the first data in second data, the method further comprising: receiving, by the first CPUF device, second data from the second CPUF device, the second data being encrypted by the second CPUF device using the memory key; storing at least part of the second data encrypted by the memory key in the shared memory location; or, 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.

3. Method according to claims 1 or 2, wherein the creation of the shared memory location includes: generating a shared memory identifier; and. sharing the shared memory identifier with at least part of the CPUF devices in the network4. Method according to any of claims 1-3, wherein the creation of the shared memory location includes: generating the memory key based a challenge and / or response of the first CPUF device; and, optionally, encrypting data based on the memory key and storing the encrypted data in the shared memory region;5. Method according to any of claims 1-4, wherein the creation of the shared memory location includes: creating a sharing list for administering CPLIF devices accessing the shared memory location; and, wherein, optionally, the method includes: 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.

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 an unique identifier, preferably a chip or chiplet ID.

8. A controlled physical unclonable function (CPLIF) device, preferably implemented on a die or as system on a chip, comprising: a secure channel handler configured to determine a secret key based on a challenge response pair, the challenge response pair being associated with a physical unclonable function; 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 associated with the CPLIF device, preferably the data storage being 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, the processor being 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.

9. Device according to claim 8 wherein the processing of the first data includes modification of the first data in second data, the executable operations further comprising: 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; storing, by the memory controller, at least part of the second data encrypted by the memory key in the shared memory location; or, 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.

10. Device according to claim 8 or 9 wherein the creation of the shared memory location includes: generating a shared memory identifier; and. sharing the shared memory identifier with at least part of the CPLIF devices in the network11. Device according to any of claims 8-10 wherein the creation of the shared memory location includes: generating the memory key based a challenge and / or response of the firstCPLIF device;12. Device according to any of claims 8-11 wherein the creation of the shared memory location includes: encrypting data based on the memory key and storing the encrypted data in the shared memory region;13. Device according to any of claims 8-12 wherein the creation of the shared memory location includes: creating a sharing list for administering CPLIF devices accessing the shared memory location14. Device according to any of claims 8-13 the executable operations further comprising: 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.

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-14, wherein the CPLIF device comprises: a secure channel handler configured to determine a secret key based on a challenge response pair, the challenge response pair being associated with a physical unclonable function; 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; a memory controller for controlling a data storage associated with the CPLIF device, preferably the data storage being external to the CPLIF device; and, a processor coupled to the memory.

Images