Generating cryptographic information based on device-unique function and physical side-channel measurements

Abstract

Embodiments include computer-implemented methods for generating one or more cryptographic keys that are uniquely associated with execution of a software program by a computing device comprising a device-unique function (DUF). Such methods include obtaining at least one challenge input for the DUF. The at least one challenge input is based on measurements of side channel information resulting from the execution of the software program on the computing device. Such methods include, using the DUF, generating at least one challenge response based on the respective at least one challenge input. Such methods include generating one or more cryptographic keys based on the at least one challenge response. Other embodiments include computing devices or systems configured to perform such methods.

Description

[0001] GENERATING CRYPTOGRAPHIC INFORMATION BASED ON DEVICEUNIQUE FUNCTION AND PHYSICAL SIDE-CHANNEL MEASUREMENTS

[0002] TECHNICAL FIELD

[0003] The present disclosure relates generally to computing and / or communication devices, and more specifically to techniques for generating cryptographic information that is unique to execution of a particular program on a specific device with a device-unique function (DUF), and for verifying such cryptographic information.

[0004] BACKGROUND

[0005] Unintentional side-channel emissions (or leakage) by devices have been maliciously exploited by attackers to extract secrets. In general, side-channel emissions are via a nonintended information channel from a device to its surrounding environment. For example, sidechannel emissions may include power consumption, electromagnetic (EM) emissions, thermal signatures, sound emissions, optical emissions, memory and / or CPU utilization levels, etc. An attacker can utilize these leakages to extract sensitive information from a device.

[0006] One example attack based on side-channel emissions is extracting cryptographic keys from cryptographic algorithms implemented in software executing on subscriber identity modules (SIMs) and processors. Another example attack is on hardware implementations of cryptographic algorithms, such as Advanced Encryption Standard (AES) and Post-Quantum Cryptography (PQC) algorithms such as Module Lattice Key Encapsulation Mechanism (ML-KEM) and Module Lattice Digital Signature Algorithm (ML-DSA). Side-channel emissions can also be used to reverse engineer software running on a processor.

[0007] Side-channel emissions can also be monitored to detect malicious software alterations. In side-channel monitoring, an external monitor registers side-channel emissions from the device, based on which the external monitor determines whether the device behaves “normally” according to pre-defined criteria. In some solutions, the monitor is oblivious to the internal state of the device and only determines whether side-channel emissions are “normal” or “abnormal”. In other solutions, the monitor is aware of certain states or operations of the device that correspond to certain side-channel emissions. In this case, the monitor may detect “illegal” state transitions due to abnormal execution flow of the device that manifest as unexpected side-channel emissions.

[0008] In general, it is very difficult to avoid or intentionally shape the leakages by the device. This makes it very hard for an attacker to remain undetected by external side-channel monitoring, as an attack on a device unavoidably will cause abnormal changes into the side-channel leakage. This is beneficial in both high-security environments and as a complement to “classic” monitoring. Physical unclonable functions (PUFs) are circuits that can create a device-unique response to a given input based on implicit or explicit randomness. Due to the uniqueness, the response may be used for cryptographic or device identity purposes. In other words, two identical PUF implementations on two different devices will, with high probability, produce different responses when given the same challenge input - hence the “unclonable” label. Put differently, the physical unclonability property means that it should be easy to create a random PUF instance but difficult to create a specific PUF instance that produces a particular response to a given input.

[0009] In general, the physical unclonability property assumes that the respective clones are manufactured in the same production process as the original device. Even so, these clones may have implicit operational randomness due to unpredictable manufacturing differences in semiconductor devices; this may be exploited to generate the device-unique responses. Alternately or additionally, explicit randomness may be introduced during or after semiconductor device manufacturing (e.g., during packaging).

[0010] SUMMARY

[0011] Although PUFs may be used to generate device-unique responses, these responses do not take account whether software has executed on a particular device in an expected way. Likewise, external side-channel monitors may be used to determine whether a legitimate software program has executed in an expected way on a device, but they generally do not have access to device hardware and / or software. In general, there are no known solutions to ensure that a legitimate software program has executed in an expected way on a particular device with the capability of generating a device-unique response (e.g., PUF) where the response depends on measurements of the execution.

[0012] An object of embodiments of the present disclosure is to provide accurate and reliable techniques to cryptographically prove that a specific software program has executed correctly on a particular device, thereby improving ability to detect attacks on and / or unauthorized (or malicious) operation of devices.

[0013] Some embodiments include methods (e.g., procedures) for generating one or more cryptographic keys that are uniquely associated with execution of a software program by a computing device comprising a device-unique function (DUF).

[0014] These exemplary methods include obtaining at least one challenge input for the DUF. The at least one challenge input is based on measurements of side-channel information resulting from the execution of the software program on the computing device. These exemplary methods also include, using the DUF, generating at least one challenge response based on the respective at least one challenge input. These exemplary methods also include generating one or more cryptographic keys based on the at least one challenge response.

[0015] In some embodiments, the DUF is a physical unclonable function (PUF). In some embodiments, obtaining the at least one challenge input for the DUF includes obtaining the measurements of the side-channel information during execution of the software program on the computing device, and generating the at least one challenge input for the DUF based on the obtained measurements.

[0016] In some of these embodiments, the computing device includes a scheduler arranged to schedule execution of the software program, and the measurements are obtained in response to an indication from the scheduler of the scheduled execution of the software program. In some variants of these embodiments, the computing device also includes a measurement unit and a measurement cache, and obtaining the measurements is performed by the measurement unit based on capturing the measurements and storing the captured measurements in the measurement cache. In some further variants, the computing device includes a challenge creator function, and the at least one challenge input for the DUF is generated by the challenge creator function in response to an indication from the scheduler that the obtained measurements are ready in the measurement cache.

[0017] In some of these embodiments, the obtained measurements of side-channel information are of a first dimension, and generating the at least one challenge input also includes encoding the obtained measurements of side-channel information from the first dimension to a second dimension that is less than the first dimension. In some variants, the at least one challenge input may be generated based on the encoded measurements in the second dimension. In other variants, generating the at least one challenge input also includes transforming the encoded measurements into a sequence of integers using a vector quantizer. In such variants, the at least one challenge input may be generated based on the sequence of integers.

[0018] In some further variants, encoding the obtained measurements and / or transforming the encoded measurements results in at least one challenge input that does not change for different executions of the software on the computing device. In some further variants, encoding the obtained measurements and / or transforming the encoded measurements using the vector quantizer is based on a machine learning model trained on measurements of side-channel information captured during execution of the software program and one or more further software programs on the computing device.

[0019] In other embodiments, each challenge input is one of a predetermined plurality of codewords and generating the at least one challenge input includes the following operations for each of the at least one challenge input: • generating an initial challenge input based on the measurements of side-channel information, wherein the initial challenge input is not limited to the predetermined plurality of codewords; and

[0020] • applying error correction to the initial challenge input to obtain one of the predetermined plurality of codewords as the challenge input.

[0021] In some of these embodiments, applying error correction to the initial challenge input comprises modifying a subset of bits in a bitfield that represents the initial challenge input, such that the bitfield represents one of the predetermined plurality of codewords.

[0022] Other embodiments and variants of these exemplary methods are described herein.

[0023] Other embodiments include computing devices or systems (e.g., user equipment, loT devices, computing devices, cloud computing servers / sy stems, etc.) or secure components (e.g., circuitry or module) configured to perform operations corresponding to any of the exemplary methods described herein. Other embodiments include non-transitory, computer-readable media storing program instructions that, when executed by processing circuitry, configure such computing devices or systems or secure components to perform operations corresponding to any of the exemplary methods described herein.

[0024] These and other embodiments described herein may provide various benefits and / or advantages. For example, embodiments may protect against runtime-attacks on software that result in changes to software behavior that alter measured device power consumption, and thus the challenge input from which a device-unique response and cryptographic key(s) generated. Accordingly, software exposed to an attack will produce an incorrect cryptographic key that may be detected during cryptographic verification.

[0025] Moreover, unlike conventional hash-based techniques, embodiments may increase resilience of software against control flow integrity attacks where the same program is manipulated to have unexpected execution flow due to unexpected inputs or other factors. Also, embodiments may protect against attacks based on putting the device in unexpected environmental conditions, such as temperatures outside of rated operational range that may cause the DUF to generate an unexpected response, which results in an incorrect key that can be detected during cryptographic verification. Furthermore, embodiments may provide these and other protections without access to the actual source code of the software.

[0026] These and other objects, features, and advantages of embodiments of the present disclosure will become apparent upon reading the following Detailed Description in view of the Drawings briefly described below. BRIEF DESCRIPTION OF THE DRAWINGS

[0027] Figure 1 is a block diagram of a computing system that provides a cloud-based computing environment for software of one or more tenants.

[0028] Figure 2 is a block diagram illustrating an example security component and a computing device on which the security component is installed.

[0029] Figure 3 is a block diagram of a device (e.g., computing device, communication device, etc.) according to some embodiments of the present disclosure.

[0030] Figure 4 is a signaling diagram of a procedure for generating one or more cryptographic keys, according to some embodiments of the present disclosure.

[0031] Figure 5 is a flow diagram of an exemplary computer-implemented method (e.g., procedure) for generating one or more cryptographic keys, according to some embodiments of the present disclosure.

[0032] Figure 6 is a block diagram of a computing device according to various embodiments of the present disclosure.

[0033] Figure 7 is a block diagram of a computing system according to some embodiments of the present disclosure.

[0034] DETAILED DESCRIPTION

[0035] Some of the embodiments contemplated herein will now be described more fully with reference to the accompanying drawings. Other embodiments, however, are contained within the scope of the subject matter disclosed herein, the disclosed subject matter should not be construed as limited to only the embodiments set forth herein; rather, these embodiments are provided by way of example to convey the scope of the subject matter to those skilled in the art.

[0036] In general, all terms used herein are to be interpreted according to their ordinary meaning to a person of ordinary skill in the relevant technical field, unless a different meaning is expressly defined and / or implied from the context of use. All references to a / an / the element, apparatus, component, means, step, etc. are to be interpreted openly as referring to at least one instance of the element, apparatus, component, means, step, etc., unless explicitly stated otherwise or clearly implied from the context of use. The operations of any methods and / or procedures disclosed herein do not have to be performed in the exact order disclosed, unless an operation is explicitly described as following or preceding another operation and / or where it is implicit that an operation must follow or precede another operation. Any feature of any embodiment disclosed herein can apply to any other disclosed embodiment, as appropriate. Likewise, any advantage of any embodiment described herein can apply to any other disclosed embodiment, as appropriate. Note that some aspects of the description given herein may focus on a 3GPP cellular communications system and, as such, 3GPP terminology or terminology similar to 3GPP terminology may be used. However, the concepts disclosed herein are not limited to a 3 GPP system and can be applied to any communication system that may benefit from them.

[0037] As briefly mentioned above, side-channel emissions (or leakage) by devices have been maliciously exploited by attackers to extract secrets. In general, side-channel emissions are via anon-intended information channel from a device to its surrounding environment. For example, side-channel emissions may include power consumption, EM emissions, thermal signatures, sound emissions, optical emissions, memory and / or CPU utilization levels, etc. An attacker can utilize these leakages to extract sensitive information from a device and / or to reverse engineer software running on the device.

[0038] In side-channel monitoring, an external monitor registers side-channel emissions from the device and concludes if the device behaves “normally” according to pre-defined criteria. Most commercially available devices are “closed source”, such that the owner or user has little or no possibility to install software-based intrusion detection capabilities. In such case, external side-channel monitoring may be used with the device as a “black box” that has no malware detection capabilities and is unaware of the side-channel monitoring. In general, it is difficult to avoid or intentionally shape the leakages by the device. This makes it very hard for an attacker to remain undetected by external side-channel monitoring, since an attack on a device unavoidably will cause abnormal changes into the side-channel leakage.

[0039] Side-channel monitoring may be used to detect various types of malware on a device. For example, a device infected by malware can act normally towards a controller by detaching the internal measurements with the status data supplied to the controller. Stuxnet is a well- known example of this type of sophisticated malware containing code that faked sensor signals so that a targeted system would not shut down due to abnormal behavior.

[0040] Since Stuxnet and similar malware install root kits, they affect side-channel emission patterns from the attacked component. Creating malware that manages to perform their original target task without creating detectable changes in the side-channel emissions would be an extremely complex problem, and while some limited academic progress has been made in this field, it is unlikely that such attacks will appear in the near future.

[0041] Another threat, especially concerning Internet of Things (loT) devices, is that a device may contain a software vulnerability or have a weak authentication setup. This may be exploited by an adversary to infect the device with malware that, unbeknownst to the owner, makes the device part of a botnet. This type of attack utilizes the device’s computing resources to perform malicious activities such denial-of-service (DoS) attacks and malware distribution to other devices. The Mirai botnet is an example of such malware that infected approximately 400000 devices. This type of malware infection is invisible to a controller (e.g., smart home hub) since the device seems to function normally, albeit with additional network traffic and some reduced performance.

[0042] In some cases, software may be obtained from a vendor packaged in a “container,” which is a standard unit of software that packages application code and all its dependencies so the application runs quickly and reliably in different computing environments, including commercial off-the-shelf (COTS) hardware. A computing infrastructure provider (e.g., hyperscale provider, communication service provider, etc.) typically provides resources to vendors for executing their containers. These resources include computing hardware as well as a software environment that hosts or executes the containers, which is often referred to as a “runtime environment” or more simply as “runtime.”

[0043] For example, Docker is a popular container runtime that runs on various Linux and Windows operating systems (OS). Docker creates simple tooling and a universal packaging approach that bundles all application dependencies inside a container to be run in a Docker Engine, which enables containerized applications to run consistently on any infrastructure. Side-channel monitoring of containers is a relatively new field and is usually performed using software performance indicators, e.g., CPU utilization and memory utilization.

[0044] In some cases, side-channel monitoring may also be performed on information provided by a computing device’s power management unit (PMU), which is responsible for controlling and measuring the voltage supplied to the different components in the computing device. For example, the PMU can temporarily increase or decrease the amount of allowed current for different components (e.g., processor unit), which may correspond to the power budgets for these components. Most modem processors (e.g., post-2016 Intel x86 processors) have multiple processor (or CPU) cores and support per-core power measurements and control, i.e., each CPU core can be measured and controlled individually.

[0045] PMU functionality may provide an interface to the computing device’s operating system (OS) for measurements and control of clock frequency, voltage and power state of the different components. For example, in Intel x86 processors and some ARM-based devices, Advanced Configuration and Power Interface (ACPI) provides functionality through which the OS can request changes to power and performance settings. Similarly, the framework for dynamically scaling frequency and voltage settings to save power for different hardware is commonly referred to as Dynamic Voltage and Frequency Scaling (DVFS).

[0046] Power (or energy) consumption of a processor in the computing device can be measured as a function of other parameters, such as clock frequency (approximately linearly proportional to power consumption), voltage (approximately quadratically proportional to power consumption) or a combination thereof. In general, the combination of voltage and frequency provides the most precise indirect measurement due to an existing covariance between clock frequency and voltage in terms of power consumption. It is also possible to measure the power consumption by observing the voltage at the common collector (Vcc) for the entire computing device (e.g., using a shunt resistor).

[0047] Although information provided by a PMU in response to queries may be useful for managing power budgets of components and / or processes, this information has also been used for side-channel attacks. In other words, a PMU is able to provide power-related measurements for processes running on the device, which are accurate enough to facilitate attacks. One example attack is PLATYPUS, where continuous querying allows an attacker to extract information about the state of the process / component. See, e.g., M. Lipp, et al., "PLATYPUS: Software-based Power Side-Channel Attacks on x86," 2021 IEEE Symposium on Security and Privacy, pp. 355-371. In particular, attackers may extract a cryptographic key from a process running on a CPU. To mitigate the risk of this attack, several PMUs now require a process requesting information to be privileged, throttle their responses, and / or lower the granularity of the information in the response.

[0048] Even so, PMUs often run at a significantly lower clock frequency than the CPU cores, such that PMU measurements will have a much lower sample rate than the variations in CPU core clock frequency (and corresponding power consumption). In some scenarios, this difference can be compensated by repeated measurements of the same process during an enrollment phase, to ensure that the measurements obtained during a validation phase can be mapped at least one subset of enrollment measurements.

[0049] PMU measurements may also be useful for “black box” monitoring of remotely executing software programs. This may be useful for a tenant which wants to ensure that its software program (e.g., a container) is executing properly on a computing system (e.g., cloud environment) and for a computing service provider that wants to verify that only allowed functionality is executing on their computing system hardware.

[0050] Figure 1 illustrates a computing system (100) that provides a cloud-based computing environment for software of one or more tenants, such as a first software program (104) that belongs to a tenant (102). The computing system includes orchestrator (106), a side-channel analysis (SCA) monitor (108), and one or more servers (110). The first software program 104 is to be executed in one or more of the servers, as scheduled by the orchestrator. For example, one or more parts of the first software program may be scheduled for execution by different servers and / or during different time periods. The first software program may be provided to the orchestrator 106 (and optionally to the server(s)) by the tenant as a container, function, microservice, etc. In some cases, the first software program may be provided in an encrypted form. Furthermore, the first software program may be provided in the form of uncompiled source code, compiled object code, or a combination thereof. In the case of uncompiled source code, the first software program may be compiled by the orchestrator or by one or more of the servers.

[0051] The orchestrator is communicatively coupled to the one or more servers and, as noted above, is responsible for sending and scheduling software programs to the one or more servers. For example, the orchestrator may include a software program scheduler (112) that schedules software programs (including the first software program) for execution on the server(s). The orchestrator may be a standalone entity or may be implemented as part of one of the servers (e.g., when all processors are located on a single server). The orchestrator may be, for example, a Kubemetes instance.

[0052] The SCA monitor is communicatively coupled to the server(s), but may be a standalone entity, a distributed virtual component, or part of the orchestrator 106. The SCA monitor may include a side-channel analyzer (114), a stitching function (116), a stitching cache (118), a monitor application programming interface (API, 120), and a database (122). However, the components of the SCA monitor illustrated in Figure 1 are only an example. In any event, the side-channel analyzer, the stitching function, and the monitor API may be implemented in software as subfunctions of a software package that implements the SCA monitor, which may be stored in memory of a computing system (e.g., a physical server) and executed by one or more processors (e.g., one or more CPUs) of the computing system.

[0053] The side-channel analyzer analyzes measurements, determines if the measurements are aligned with expected results, and decides what the appropriate action(s) is for the software based on a result of this determination. For example, the side-channel analyzer may utilize an anomaly detection statistical model that correlates observable characteristics (e.g., physical side-channel measurements) to expected execution of the software, and produces an indication of whether execution of the software was as expected based on the observables.

[0054] The database stores software program anomaly detection models (e.g., one model per software program), so that the appropriate model can be used by the side-channel analyzer to perform the comparison of a new measurement from a given process. In some cases, the sidechannel analyzer (and optionally the model used for the analysis) may be provided by the tenant. The stitching function, using the stitching cache, stores and merges several discrete measurements from execution instances of the software program.

[0055] Each server includes a measurement unit (MU, 124), such as a PMU. Each server also includes one or more processors (126) and memory (130) that stores the first software program (provided by the tenant via the orchestrator) and optionally one or more second software programs (132, e.g., obtained from the same and / or different tenant(s)). Each processor includes one or more processor cores (128), such that one or more software programs may execute on each processor core simultaneously. Each processor may be a CPU, a graphics processing units (GPU), a microprocessor, or the like. In some cases, the servers may be divided into nodes, with each node including multiple servers.

[0056] Each server includes a measurement cache that stores physical side-channel measurements made by the MU, an execution database (136), an OS scheduler (138), and a system time provider (144, e.g., a system clock). Optionally, each server may include a hypervisor scheduler (140) and / or a Trusted Execution Environment (TEE, 142). Note that the second software program(s) may or may not be evaluated by the SCA monitor.

[0057] Each MU performs physical side-channel measurements for the processor cores of the processor(s) in the corresponding server. These physical side-channel measurements may include measurements of the power (or energy) consumption of the respective processor cores, measurements of the electromagnetic radiation from the respective processor cores, measurements of the temperature of the respective processor cores, etc. The measurement cache stores the physical side-channel measurements for different processors and processor cores over a known sliding time window. In some embodiments, the MU (124) and the measurement cache (134) may be a standalone entity or a part of the SCA monitor. The MU may in this case measure the power consumption, electromagnetic radiation, temperature, etc. of the server 110.

[0058] The OS scheduler and / or the hypervisor scheduler schedule software programs for execution on the processors and (e.g., if requested) store the execution times (e.g., start and stop times), core IDs, and process IDs in the execution database. Note that a core ID may indicate both the processor and the processor core. The execution database stores execution times and core IDs for different processes. In some embodiments, the execution database may instead be a part of the orchestrator. The system time provider is responsible for delivering accurate time stamps for the OS scheduler, the hypervisor scheduler, and / or the MU.

[0059] In the exemplary system shown in Figure 1, the orchestrator allocates nodes and quotas for resource usage on those nodes. The cloud computing environment shown in Figure 1 has multiple layers of schedulers including an orchestrator (e.g., Kubemetes) scheduler, a hypervisor scheduler, and OS scheduler that are responsible for scheduling software from tenant(s) on nodes and ultimately on physical CPU cores. In the system shown in Figure 1, the orchestrator, the schedulers, and the MU cooperatively measure power usage for software programs that are requested to be measured, and track what physical resources should be measured in accordance with these requests. During or after execution of a software program (e.g., 104), the SCA monitor requests analysis data for the software program from the server on which the program executed. The server responds by mapping power measurements by the MU to execution times and processor ID scheduled for the software program, and sends this information to the SCA monitor. The SCA monitor performs stitching of the received set of power measurements to form a continuous measurement, which it evaluates to determine the appropriate actions for the software program. The orchestrator is informed of the decision and either continues scheduling execution of the software program or takes corrective actions, such as termination of the software program.

[0060] As briefly mentioned above, a physical unclonable function (PUF) is a type of “device unique function” that can create a device-unique response to a given input based on implicit or explicit randomness. Due to the uniqueness, the response may be used to create a unique device identity or a device-unique cryptographic key without having to store the identity or the key in non-volatile (e.g., battery-backed or one-time programmable, OTP) memory. The lack of persistent on-device storage of an identity or key, based on a device-unique PUF response, makes it much more difficult for an attacker to steal. Other device unique functions include a message authentication code (MAC) function with a device-unique key.

[0061] In general, two identical PUF implementations on two different devices will, with high probability, produce different responses when given the same challenge input. Put differently, the physical unclonability property means that it should be easy to create a random PUF instance but difficult to create a specific PUF instance that produces a particular response to a given input. This property assumes that all clones (or PUF instances) are manufactured in the same production process as the original device. Even so, these clones may have implicit operational randomness due to unpredictable manufacturing differences in semiconductor devices; this may be exploited to generate the device-unique responses. Alternately or additionally, explicit randomness may be introduced during or after semiconductor device manufacturing (e.g., during packaging).

[0062] A PUF may include one or more subfunctions, each of which contributes part of the PUF response. One example subfunction is a ring oscillator with an odd number of signal inverters arranged in a ring, with inverter input-output propagation delay providing the source of randomness. This part of the PUF response is generated by a comparison between two or more ring-oscillators, specifically the number of oscillations at a given point in time, with the result being an identifier of the fastest (or slowest) ring oscillator.

[0063] Another example PUF subfunction is uninitialized static RAM (SRAM) memory cells, which have no particular state before power-up but enter one of two possible states (0 and 1) at power-up. The response of this PUF subfunction is the state entered at power-up. Another example PUF subfunction is an arbiter of a digital race condition between two or more signal paths on in the device, each of which may include several switch blocks that can alter the signal path. In particular, the arbiter identifies the winning signal with the response being an identification (e.g., index) of the winning signal.

[0064] Although PUFs are generally probabilistic, some PUF implementations may require error correcting codes (or “helper data”) to function correctly. This may require the PUF to go through an enrollment process during which unstable PUF response bits are removed and helper data is created and stored. Also, the randomness in some PUF implementations may be biased. In such case, a fuzzy extractor may be used for both error correction and to increase the uniformity of the response’s randomness. In particular, the fuzzy extractor takes the PUF response as input and outputs a deterministic but uniformly random binary string.

[0065] Some PUF implementations may also be characterized as “environment aware.” For example, WO / 2021 / 259501A1 discloses a security component for a device, such as a computing device. Figure 2 is a block diagram illustrating an example security component (202) and a device (200) on which the security component is installed, in accordance with the disclosure in WO / 2021 / 259501A1. The security component shown in Figure 2 illustrates various options for how a management module (210) of the security component may be realised.

[0066] Referring to Figure 2, the device on which the security component is installed comprises a processor (204) and memory (206), in which one or more computer programs (208) may be stored. Various helper data (207), such as error correcting codes, may also be stored in the memory. The device may also include one or more telecommunications interfaces (not shown), such as for wired or wireless communication.

[0067] The security component includes a PUF (250) having a plurality of sub functions (252), as well as a management module (210) configured to manage the PUF in accordance with a policy. The management module of the security component includes a measurement module (212), a rule module (214), and a control module (216). The measurement module is configured to receive, from a device boot process, at least one measurement of a component booted on the device and / or of a hardware state of the device. The measurement module may for example comprise a plurality of measurement registers. The rule module is configured to compare the received measurement to at least one rule that implements the policy, and to enter a policy state on the basis of the comparison. The control module is configured to configure the PUF in accordance with a policy state entered by the rule module.

[0068] The rule module may be configured to receive configuration information defining the at least one rule that implements the policy. The configuration information may be a bitstream (e.g., if the management module is realized in reconfigurable logic) or memory and / or register configurations (e.g., if the management module is realized in an ASIC). The management module further comprises an authentication module configured to authenticate the configuration information using a security credential.

[0069] In other words, the management module can be seen as an “environment enforcer” that evaluates the environment in which it operates by comparing measurements (e.g., hash values of booted software components) to a predefined policy that determines which state the enforcer should enter and thereby how the PUF should be configured. For example, each state causes the PUF to use certain subfunctions and thereby generate a both device-unique and environmentunique response.

[0070] Other PUF implementations may be used for generating unique module secrets (UMS) for various hardware modules of a computing device. For example, WO / 2024 / 013554A1 describes a computing device (or system) having a plurality of hardware modules, where at least one hardware module produces a unique output that is based on a unique module secret (UMS). For example, a first one of the hardware modules may receive a UMS generated by a second hardware module and a measurement of a descriptor associated with a loadable software component for the second hardware module. The measurement of the descriptor may be based on metadata for the loadable component, a portion of the loadable component, a hash of the loadable component, or any combination thereof. The first hardware module may generate a first secret based on a UMS generated by the first hardware module and on the UMS and the measurement from the second hardware module. The second hardware module may generate a second secret based on the first secret and one or more additional measurements of loadable software component(s).

[0071] Other PUF implementations may be used in conjunction with certain side-channel measurements. For example, some side-channel measurements may be used for validation and / or verification of content captured by a device (e.g., camera, microphone, etc.). These side-channel measurements may be combined with a hash of the captured content, with the combination being encrypted by a “hardware-entangled key,” such as a key generated based on a device-unique output of a PUF. In this case, the key may be device-specific and fixed, such that it may be used to verify that the measurements tying the content to the device that captured it have not been tampered with, thereby facilitating the authentication of the content.

[0072] Although PUFs may be used to generate device-unique responses, these responses do not take account whether software has executed on a particular device in an expected way. For example, the security component described in WO / 2021 / 259501A1 generates a device-unique response based on a measurement value (e.g., hash) of a booted software component, without regard to whether the software component has executed properly on the device. Likewise, external side-channel monitors may determine whether a legitimate software program has executed in an expected way on a computing device, but they generally do not have access to device hardware and / or software. As such, external side-channel monitors may be unable to determine whether the software program has executed in an expected way according to unique characteristics of the device.

[0073] In general, there are no known solutions to ensure that a legitimate software program has executed in an expected way on a particular device with the capability of generating a deviceunique response (e.g., PUF).

[0074] Embodiments of the present disclosure address these and other problems, issues, and / or difficulties with novel, flexible, and efficient techniques to cryptographically prove that a specific program has executed correctly on a device. During the execution of the software on the device’s CPU (e.g., one or more processors and / or processor cores thereof), the device’s side-channel measurement unit (e.g., PMU) continuously measures power consumption of the device’s CPU and / or other physical side-channel information. These measurements may be synchronized with assistance from the device’s scheduler function and are used to create at least one challenge input to a device-unique function (DUF, e.g., PUF), based on which the DUF generates corresponding at least one device-unique response. The response output from the device-unique function is used as input to a key derivation function (KDF), based on which the KDF generates one or more cryptographic keys that is / are unique for the combination of device and software execution thereon. This cryptographic key(s) may be used to prove to an external party that the software executed correctly on the device, and / or to decrypt data that should be accessible only to the software on the device.

[0075] In some embodiments, the measurement unit may be internal or external to the device’s processor(s). In some embodiments, the physical measurements may be processed by errorcorrecting functionality to produce the challenge input, such that minor deviations in the physical measurements do not cause a deviation in the challenge input. In some embodiments, the physical measurements may be transformed into a format suitable for the challenge input to the device-unique function. In some embodiments, the scheduler function may determine and / or define which measurements belong to the execution of the software component.

[0076] Embodiments may provide various benefits and / or advantages. For example, embodiments may protect against runtime-attacks on software that result in changes to software behavior (e.g., instruction skipping by fault injection) that alter device power consumption and thus the challenge input from which the device-unique response is generated. Since this deviceunique response is used to produce a cryptographic key, software that has been exposed to an attack will produce an incorrect cryptographic key that will be detected during cryptographic verification (e.g., integrity checking of signature).

[0077] Moreover, unlike conventional hash-based techniques, embodiments may increase resilience of software against control flow integrity attacks where the same program (i.e., with the same hash) is manipulated to have unexpected execution flow due to unexpected inputs or other factors. Also, embodiments may protect against attacks based on putting the device in unexpected environmental conditions, such as temperatures outside of rated operational range. In general, the device-unique function (e.g., PUF) is only deterministic within the rated operational range and is likely to produce different responses for a given input outside of the rated operational range. Based on this different response the KDF will generate an incorrect key that can be detected during cryptographic verification.

[0078] Furthermore, embodiments may operate according to “black box” principles without access to the actual source code of the software. Rather, embodiments only need to know when and on which processor(s) the software executed.

[0079] Figure 3 shows a block diagram of a device (300, e.g., computing device, communication device, etc.) according to some embodiments of the present disclosure. The device includes one or more processors (302) arranged to execute software stored in a memory (306), including a software program (304). Each processor may be or include one or more CPUs, CPU cores, GPUs, GPU cores, etc. that are able to execute instructions comprising the software program. Execution of the software program is managed by a scheduler (308), which informs the one or more processors when and on which constituent parts of the processor(s) the various parts of the software program will run. The scheduler may be a hardware function, software stored in the memory, or a combination thereof.

[0080] The device also includes a measurement unit (MU, 310) arranged to capture physical sidechannel measurements related to execution of software by the one or more processors. For example, the MU may be or include a PMU that can repetitively measure power consumption of the one or more processors and / or their constituent parts. Alternately or in addition, the MU may include one or more sensors capable of repetitive measurements of other side-channel signals such as electromagnetic emissions and / or temperature of the processor(s).

[0081] Additionally, the device includes a measurement cache (312) in which the MU may store the side-channel measurements that it performs. As used herein, the term “measurement cache” denotes a portion of memory used for temporary storage of physical side-channel measurements by the MU, e.g., for later access by one or more other components as explained below. The device also includes a challenge creator function (314) and a device-unique function (DUF, 322). The challenge creator is arranged to transform a series of measurements stored in the measurement cache into a challenge input to the DUF, which may be a PUF, a MAC function (with a device-unique configuration parameter), or similar hardware block that has device-unique characteristics described above (which may be limited to a particular operating range). Based on the challenge input, the DUF generates a device-unique response. Put differently, the DUF generates a response that is both device-unique (i.e., due to DUF characteristics) and unique to the observed characteristics of the execution of the software program by the device.

[0082] The device also includes a key derivation function (KDF, 324) arranged to create a deterministic cryptographic key (for symmetric) or key pair (for asymmetric) with a specified property (e.g., length) for any given input. In particular, the KDF input is (or is based on) the device-unique response generated by the DUF, so the KDF key output is both device-unique (i.e., due to DUF characteristics) and unique to the observed characteristics of the execution of the software program by the device. In some embodiments, when the DUF is based on a MAC, the challenge and other parameters may be directly input to the KDF for generation of the deviceunique key.

[0083] In some embodiments, the challenge creator may include one or more of an error correction function (316), and input transformer (318), and an output mapper (320). In general, the challenge creator should reliably and deterministically generate the same output for each execution of the software program. However, the physical side-channel measurements by the MU may vary slightly across different executions of the same software program. For example, this may be caused by random variations in device (or processor) state or in different timing of the measurement samples across different executions.

[0084] To address these variations, the challenge creator may use the error correction function to correct small deviations in DUF output such that similar, but not equal, sets of side-channel measurements produce the same challenge. Alternately, the challenge creator may use the input transformer to map slightly different measurements to a common DUF input that will produce the same challenge.

[0085] In some embodiments, the error correction function and the input transformer may be implemented as a single component. One way to implement these embodiments is to apply machine learning (ML) techniques to train a model for valid variations in measurements between different executions of the same software and then use this model to map new measurements to some predefined challenge (e.g., number or sequence) corresponding to this software. The same model should produce a different representation for measurements belonging to other software or modified versions of the same software. Other embodiments of the challenge creator may be based on a “fuzzy extractor”, which may be embodied as the error correction function followed by a hash function. In this approach, the hash function produces the same hash value output for similar (but not necessarily identical) inputs. Other embodiments of the challenge creator may be based on a “fuzzy vault”, which may be embodied as the error correction function followed by a substitution function. In this approach, a particular measurement input and similar measurement inputs result in a common pre-defined challenge.

[0086] Certain DUFs may only accept challenges only in a particular format. In such case, the challenge creator may employ the output mapper to deterministically map the error correction output to the closest valid challenge according to some predefined metric (e.g., Hamming distance).

[0087] In some embodiments, the challenge creator, the DU, and the KDF may be part of a secure (or security) component (330) of the device, denoted by the dashed rectangle in Figure 3. For example, the secure component may be a separate module that is resistant to tampering and / or intrusions. In some embodiments, the various constituent parts of the security component (e.g., DUF) may be implemented by hardware (e.g., ASICs, etc.) of internal processing circuitry (326). In other embodiments, the secure component may also include internal non-volatile memory (328) storing software instructions (329) executable by the internal processing circuitry. In such case, one or more of the constituent parts of the security component may be implemented by the internal processing circuitry executing these software instructions stored in internal memory. A combination of hardware and software implementation of the secure component is also possible.

[0088] Although the secure component is shown in Figure 3 as internal to the device, in other embodiments the secure component may be external to the device. Likewise, in some embodiments the MU and the measurement cache may be external to the device, e.g., but combined with or accessible to the external secure component.

[0089] Figure 4 shows a procedure for generating one or more cryptographic keys that are unique both to a device and to observed characteristics of execution of a software program by the device, according to some embodiments of the present disclosure. The procedure involves various device blocks or functions shown in Figure 3, including the one or more processors (302) that execute the software program, the scheduler (308), the MU (310), the measurement cache (312), the challenge creator (314), the DUF (322), and the KDF (324). Although operations of the procedure are given numerical labels, this is done to facilitate the following explanation rather than to require or imply any particular operational order, unless expressly stated otherwise.

[0090] As an optional pre-condition, an enrollment of the software program’s expected execution is performed in operation 0. In this operation, the processor performs one or more controlled executions of the program to create an expected (“reference”) cryptographic key (e.g., symmetric) or key pair (e.g., public / private), as the case may be. In the case of a key pair, operation 0 may involve generating and exporting a public key that can be used later as a reference key to authenticate and / or validate a digital signature or message authentication code by the device based on a private key created by later operations in the procedure.

[0091] In some cases, the Mb’s sampling rate of the physical measurements (e.g., power consumption) may be relatively low compared to the frequency of variation in the physical measurements relating to the software program. Alternately or additionally, it is possible that the Mb’s sampling duration of the physical measurements is inadequate to capture all variations in the physical measurements relating to the software program, particularly if the software program only executes for a short duration.

[0092] In such cases, during enrollment in operation 0, the processor is scheduled (e.g., as described below) to execute the software program a relatively large number of times and / or for a relatively long duration, during which the MU captures a variety of physical measurements relating to the software program. The challenge creator can then group the most similar measurement series for error correction mapping purposes. Although this technique may increase the stability of the key generation procedure, it may also reduce ability to detect small differences in execution characteristics of the software program.

[0093] In operation la (which may be after the enrollment period), the scheduler schedules the software program to execute on the processor (e.g., on a constituent CPU or CPU core). In operation lb, the scheduler instructs the MU to start collecting physical measurements for the execution on the processor.

[0094] In operation 2, the MU collects physical measurements (e.g., CPU power consumption) related to the execution of the software program by the processor. In operation 3, the MU stores the measurements in the measurement cache, optionally together with a system time stamp and / or software identifier.

[0095] In some embodiments, operations 2-3 may be repeated according to the MU’s measurement cycle for as long as the software program executes on the processor. In some embodiments, the MU may continuously collect and store physical measurements of the processor, e.g., in a ring buffer structure. In such embodiments, the scheduler’s instruction in operation lb marks the start time for measurements that relate to the software program’s execution on the processor.

[0096] In other embodiments, the scheduler’s instruction in operation lb may include a number of measurements to be collected or a duration for collection of the measurements. In such case, operations 2-3 are repeated according to the MU’s measurement cycle for the number of measurements or the duration specified.

[0097] In operation 4a, which is optional, the scheduler instructs the MU to stop the physical measurements. In some embodiments, the scheduler may provide a stop time for when the MU should stop the physical measurements, either in operation 4a or with the request in operation lb. Alternately, if the scheduler provided in operation lb a number or duration of physical measurements to be collected by the MU, the MU stops upon reaching that number or duration without an explicit instruction as in operation 4a.

[0098] In some embodiments, the operations la-4a that collect and store measurements for a single execution of the software program (referred to as a “measurement trace”) may be repeated to enable more measurements to be collected. Note that a large number of repetitive executions may be feasible only for small software programs, and thus may be reserved for very security sensitive programs.

[0099] In operation 4b, the scheduler sends to the challenge creator an indication that physical measurements are ready in the measurement cache. In response to this indication, in operation 5 the challenge creator obtains the physical measurements from the measurement cache. In case multiple measurement traces have been collected through multiple executions, as discussed above, the challenge creator can combine these traces in various ways to create a higher resolution trace that provides increased differentiation of small changes in software program execution flow.

[0100] For example, the measurements in the measurement cache may include, for each processor core on which the software program executed:

[0101] • information indicative of time periods during which the software program was executed on the processor core; and

[0102] • for each of the time periods during which the software program executed on the processor core, one or more physical measurements for the processor core during that time period and (optionally) information that identifies the processing core (e.g., core ID).

[0103] The challenge creator (e.g., input transformer) may then process the measurements to form a measurement profile for the software program. The measurement profile includes, for example, the physical side-channel measurements from the measurement data arranged in sequence according to the times at which those measurements were performed.

[0104] Alternately, the challenge creator (e.g., input transformer) may group the measurements in sets of two or more and compute an average of each group of measurements, which may be used as input to create the challenge. Each group may be overlapping or non-overlapping with one or more other groups of measurements. In operation 6, which is optional, the challenge creator determines error correction for the measurements obtained in operation 5. In some embodiments, the error correction is obtained prior to the challenge creator using the measurements as input to challenge creation. For example, the error correction may normalize the measurement values by adding and / or multiplying each measurement with one or more constants (i.e. , scalars) prior to quantization. As a more detailed example, for a quantization resolution of 0.1, a measurement of 0.04 would be quantized as 0 and a measurement of 0.07 would be quantized as 0.1, without error correction. However, the error correction may be applied to ensure that all measurements in the range 0.04- 0.07 (or other relevant range) are quantized as 0.1.

[0105] In other embodiments, the error correction is obtained after the challenge creator uses the measurements to produce the challenge output. For example, for a Y-bit challenge codeword, error correction may be applied to change up to X < Y bits of the challenge codeword.

[0106] In some embodiments, the error correction determined by the challenge creator may be based on and / or derived from the enrollment procedure in operation 0, as discussed above.

[0107] In some embodiments, machine learning (ML) may be used to obtain a vector quantizer from measurement data from the software program in addition to measurement data from other software programs, and / or modified measurements from any of these programs. For example, the vector quantizer may be learned as part of an anomaly detection model. The anomaly detection model may be trained with a contrastive loss function, which minimizes the difference between outputs of the model from measurements of the same program while maximizing the normalized difference between pairs of measurements where one measurement is expected to deviate from the other. The expected deviation of measurements during training can be due to selection of measurements from different programs or intentional modification of one or more measurements to induce deviation for more challenging training samples. The output of the learned vector quantizer model may produce a sequence of integer that can be error corrected based on statistics from multiple measurements from the software program.

[0108] In operation 7, the challenge creator determines at least one challenge based on the measurements, which may have been error-corrected in operation 6. Note that for embodiments where the error correction is obtained for the challenge output, as discussed above, the order of operations 6-7 may be effectively reversed.

[0109] In operation 8, the challenge creator sends the at least one challenge to the DUF. In some embodiments, the challenge creator may send a plurality (e.g., set) of challenges to the DUF. For example, the plurality of challenges may be provided as a binary bitstring with different portions corresponding to individual challenges of expected length. Alternately, the challenge creator may send a single challenge from which one of more subsequent challenges may be inferred / computed, e.g., Chal_next = hash(Chal_prev).

[0110] In operation 9-10, the DUF generates response(s) for the challenge(s) received and sends the challenge response(s) to the KDF. In operation 11, the KDF generates a cryptographic key or key pair based on the challenge response(s).

[0111] If the challenge creator produced the same challenge(s) in operations 7-8 as produced during the enrollment procedure in operation 0 (or other previous execution of the software program), the KDF will produce the same cryptographic key or key pair in operation 11 as was produced during the enrollment phase. Thus, if a key (e.g., symmetric or private) produced during operation 11 is used for a digital signature or message authentication code (MAC), this digital signature or MAC may be verified using a reference key (e.g., symmetric or public) produced during the enrollment procedure or other previous execution of the software program.

[0112] On the other hand, if the challenge creator did not produce the same challenge(s) in operations 7-8 as produced during the enrollment procedure in operation 0 (or other previous execution of the software program), the KDF will not produce the same cryptographic key or key pair in operation 11 as was produced during the enrollment phase. Thus, if a key (e.g., symmetric or private) produced during operation 11 is used for a digital signature or MAC, this digital signature or MAC will not be verified using a reference key (e.g., symmetric or public) produced during the enrollment procedure (or other previous execution of the software program). This nonverification indicates an unexpected deviation in the execution of the software program and / or the DUF operation (e.g., due to tampering).

[0113] As an illustrative example use case, the software program may be a boot program for the device. A key (or key pair) is generated according to the procedure in Figure 4 during execution of the boot program and is used to create a digital signature or MAC. Subsequently, a second software program (e.g., application program) needs to execute on the device but only on the condition that the boot program previously executed correctly. The second software program can verify this correct execution condition based on verifying the digital signature or MAC using a corresponding key (e.g., symmetric or public) previously generated based on execution of the boot program (e.g., during enrollment).

[0114] Other example use cases of the procedure shown in Figure 4 are described below. As one example, the software program encrypts data with the key generated in Figure 4 operation 11 and stores the encrypted data in a storage medium accessible to the device. This encrypted data can only be decrypted by a corresponding key (e.g., from the enrollment procedure or other previous / later execution of the software program) if the key used for encryption was generated based on measurements that reflect expected execution of the software program on the device. Inability to encrypt the data may indicate an unexpected deviation in the execution of the software program and / or the DUF operation (e.g., due to tampering).

[0115] As another example, the software program uses the key generated in Figure 4 operation 11 to authenticate itself to an external party, e.g., using a digital signature or MAC generated based on this key. In case a public key was generated during the enrollment process in operation 0, the external party may use this public key to validate the private key used for the signature. The software program will only be able to produce the private key if it has executed in the expected way on the device, as determined by the measurements.

[0116] Various features of the embodiments described above correspond to various operations illustrated in Figure 5, which depicts an exemplary method (e.g., procedure) for generating one or more cryptographic keys that are uniquely associated with execution of a software program by a computing device comprising a device-unique function (DUF), according to various embodiments of the present disclosure. In other words, various features of the operations shown in Figure 5 and described below correspond to various embodiments described above. Although Figure 5 shows specific blocks in a particular order, the operations of the exemplary method can be performed in a different order than shown and can be combined and / or divided into blocks having different functionality than shown. Optional blocks or operations are indicated by dashed lines.

[0117] The following description is based on the exemplary method being performed by a computing device. However, it should be understood that the exemplary method may be performed by a particular part of the computing device, such as a secure component discussed above. Alternately, the exemplary method may be performed by a secure component external to the computing device.

[0118] The exemplary method includes the operations of block 510, where the computing device obtains at least one challenge input for the DUF. The at least one challenge input is based on measurements of side-channel information resulting from the execution of the software program on the computing device. The exemplary method also includes the operations of block 520, where using the DUF, the computing device generates at least one challenge response based on the respective at least one challenge input. The exemplary method also includes the operations of block 530, where the computing device generates one or more cryptographic keys based on the at least one challenge response.

[0119] In some embodiments, the DUF is a physical unclonable function (PUF). In some embodiments, obtaining the at least one challenge input for the DUF in block 510 includes the following operations, labelled with corresponding sub-block numbers:

[0120] • (511) obtaining the measurements of the side-channel information during execution of the software program on the computing device; and • (514) generating the at least one challenge input for the DUF based on the obtained measurements.

[0121] In some of these embodiments, the computing device includes a scheduler arranged to schedule execution of the software program, and the measurements are obtained in block 511 in response to an indication from the scheduler of the scheduled execution of the software program. In some variants of these embodiments, the indication from the scheduler includes one or more of the following: an execution start indication, an indication of one or more device component on which the software execute or will execute, a number of measurements to be captured, and a duration over which the measurements should be captured.

[0122] In some variants of these embodiments, the computing device also includes a measurement unit and a measurement cache, and obtaining the measurements is performed by the measurement unit based on capturing the measurements and storing the captured measurements in the measurement cache. In some further variants, the computing device includes a challenge creator function, and the at least one challenge input for the DUF is generated by the challenge creator function in response to an indication from the scheduler that the obtained measurements are ready in the measurement cache.

[0123] In some of these embodiments, the obtained measurements of side-channel information are of a first dimension, and generating the at least one challenge input in block 510 also includes the operations of sub-block 512, where the computing device encodes the obtained measurements of side-channel information from the first dimension to a second dimension that is less than the first dimension. In some variants of these embodiments, the at least one challenge input is generated based on the encoded measurements in the second dimension.

[0124] In other variants of these embodiments, generating the at least one challenge input in block 510 also includes the operations of sub-block 513, where the computing device transforms the encoded measurements into a sequence of integers using a vector quantizer. In such case, the at least one challenge input is generated based on the sequence of integers.

[0125] In some further variants, encoding the obtained measurements and / or transforming the encoded measurements results in at least one challenge input that does not change for different executions of the software on the computing device. In some further variants, one or more of the following is based on a machine learning model trained on measurements of side-channel information captured during execution of the software program and one or more further software programs on the computing device: encoding the obtained measurements, and transforming the encoded measurements using the vector quantizer.

[0126] In some embodiments, the measurements of side-channel information comprise measurements of at least one physical property for one or more device components on which the software program executes. In other words, the physical property(ies) may be measured on each device component that executes the software program, whether one or multiple device components. For example, the one or more device components executing the program may include processors (e.g., CPUs, GPUs, controllers), processor cores (e.g., of a CPU or GPU), programmable logic (e.g., FPGAs), non-programmable / fixed logic (e.g., ASICs), specialpurpose hardware (e.g., for cryptographic or Al operations), etc.

[0127] In some of these embodiments, for each device component on which the software program executed, the measurements include the following:

[0128] • an identifier of the device component;

[0129] • indications of one or more time periods during which the software program executed on the device component; and

[0130] • for each of the one or more time periods, the measurements of at least one physical property of the device component.

[0131] In some variants of these embodiments, generating the at least one challenge input based on the measurements in block 510 includes the following operations, labelled with corresponding subblock numbers:

[0132] • (517) combining the measurements obtained for each of the one or more time periods and for each of the one or more device components to obtain a measurement profile for the computing device and the software program; and

[0133] • (518) generating the at least one challenge input based on the measurement profile.

[0134] In some of these embodiments, the at least one physical property includes one or more of the following: power or energy consumption, electromagnetic emissions, temperature, time or duration, processing capacity usage, and memory usage.

[0135] In some embodiments, each challenge input is one of a predetermined plurality of codewords and generating the at least one challenge input in block 510 includes the following operations for each of the at least one challenge input, labelled with corresponding sub-block numbers:

[0136] • (515) generating an initial challenge input based on the measurements of side-channel information, wherein the initial challenge input is not limited to the predetermined plurality of codewords; and

[0137] • (516) applying error correction to the initial challenge input to obtain one of the predetermined pluralities of codewords as the challenge input.

[0138] In some of these embodiments, applying error correction to the initial challenge input in subblock 516 comprises modifying a subset of bits in a bitfield that represents the initial challenge input, such that the bitfield represents one of the predetermined pluralities of codewords. In some embodiments, the one or more cryptographic keys include one of the following: a master key for further key derivation, a single symmetric key, a private key, or an asymmetric key pair of public and private keys. In some of these embodiments, the exemplary method also includes the operations of block 540, where the computing device performs one or more of the following cryptographic operations using the one or more cryptographic keys:

[0139] • generating a digital signature or MAC,

[0140] • deriving another key from the master key,

[0141] • encrypting data generated by execution of the software program on the computing device, integrity protection of the data,

[0142] • decrypting further data generated by further execution of the software program on the computing device, and

[0143] • integrity verification of the further data.

[0144] In some embodiments, the exemplary method also includes the following operations, labelled with corresponding block numbers:

[0145] • (550) obtaining at least one further challenge input for the DUF, wherein the at least one further challenge input is based on measurements of side-channel information resulting from further execution of the software program or of a second software program on the computing device;

[0146] • (560) using the DUF, generating at least one further challenge response based on the respective at least one further challenge input; and

[0147] • (570) generating one or more further cryptographic keys based on the at least one further challenge response.

[0148] In some of these embodiments, the further execution is of the software program during an enrolment procedure before the execution of the software program, and the exemplary method also includes the operations of block 580, where the computing device sends one of the further cryptographic keys to a storage repository for subsequent use as a reference key.

[0149] In other of these embodiments, the further execution is of the second software program after the execution of the software program, and the one or more further cryptographic keys are also based on one or more of the following: the at least one challenge input, the at least one challenge response, and the one or more cryptographic keys.

[0150] Although various embodiments are described herein above in terms of methods, apparatus, devices, computer-readable medium and receivers, the person of ordinary skill will readily comprehend that such methods can be embodied by various combinations of hardware and software in various systems, communication devices, computing devices, control devices, apparatuses, non-transitory computer-readable media, etc. Figure 6 shows a computing device 600 in accordance with some embodiments of the present disclosure. Examples of a computing device include, but are not limited to, a smart phone, mobile phone, cell phone, voice over IP (VoIP) phone, wireless local loop phone, desktop computer, personal digital assistant (PDA), wireless cameras, gaming console or device, music storage device, playback appliance, wearable terminal device, wireless endpoint, mobile station, tablet, laptop, laptop-embedded equipment (LEE), laptop-mounted equipment (LME), smart device, wireless customer-premise equipment (CPE), vehicle, vehicle-mounted or vehicle embedded / integrated wireless device, etc. Other examples include any user equipment (UE) identified by 3GPP, including a narrow band internet of things (NB-IoT) UE, a machine type communication (MTC) UE, and / or an enhanced MTC (eMTC) UE.

[0151] Note that the computing device may not necessarily have a human user who owns and / or operates the device. Instead, the computing device may be a device that is intended for sale to, or operation by, a human user but which may not, or which may not initially, be associated with a specific human user. Alternatively, a computing device may be a device that is not intended for sale to, or operation by, a user but which may be associated with or operated for the benefit of a user.

[0152] Computing device 600 includes processing circuitry 602 that is operatively coupled via a bus 604 to an input / output interface 606, a power source 608, a memory 610, a communication interface 612, and / or any other component, or any combination thereof. Certain computing devices may utilize all or a subset of the components shown in Figure 6. The level of integration between the components may vary from one computing device to another computing device. Further, certain computing devices may contain multiple instances of a component, such as multiple processors, memories, transceivers, transmitters, receivers, etc.

[0153] Processing circuitry 602 is configured to process instructions and data and may be configured to implement any sequential state machine operative to execute instructions stored as machine-readable computer programs in memory 610. Processing circuitry 602 may be implemented as one or more hardware-implemented state machines (e.g., in discrete logic, field- programmable gate arrays (FPGAs), application specific integrated circuits (ASICs), etc.); programmable logic together with appropriate firmware; one or more stored computer programs, general-purpose processors, such as a microprocessor or digital signal processor (DSP), together with appropriate software; or any combination of the above. For example, processing circuitry 602 may include multiple central processing units (CPUs).

[0154] In the example, input / output interface 606 may be configured to provide an interface or interfaces to an input device, output device, or one or more input and / or output devices. Examples of an output device include a speaker, a sound card, a video card, a display, a monitor, a printer, an actuator, an emitter, a smartcard, another output device, or any combination thereof. An input device may allow a user to capture information into computing device 600. Examples of an input device include a touch-sensitive or presence-sensitive display, a camera (e.g., a digital camera, a digital video camera, a web camera, etc.), a microphone, a sensor, a mouse, a trackball, a directional pad, a trackpad, a scroll wheel, a smartcard, and the like. The presence-sensitive display may include a capacitive or resistive touch sensor to sense input from a user. A sensor may be, for instance, an accelerometer, a gyroscope, a tilt sensor, a force sensor, a magnetometer, an optical sensor, a proximity sensor, a biometric sensor, etc., or any combination thereof. An output device may use the same type of interface port as an input device. For example, a Universal Serial Bus (USB) port may be used to provide an input device and an output device.

[0155] In some embodiments, power source 608 is structured as a battery or battery pack. Other types of power sources, such as an external power source (e.g., an electricity outlet), photovoltaic device, or power cell, may be used. Power source 608 may further include power circuitry for delivering power from power source 608 itself, and / or an external power source, to the various parts of computing device 600 via input circuitry or an interface such as an electrical power cable. Delivering power may be, for example, for charging of power source 608. Power circuitry may perform any formatting, converting, or other modification to the power from power source 608 to make the power suitable for the respective components of computing device 600 to which power is supplied.

[0156] Memory 610 may be or be configured to include memory such as random-access memory (RAM), read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), magnetic disks, optical disks, hard disks, removable cartridges, flash drives, and so forth. In one example, memory 610 includes one or more application programs 614, such as an operating system, web browser application, a widget, gadget engine, or other application, and corresponding data 616. Memory 610 may store, for use by computing device 600, any of a variety of various operating systems or combinations of operating systems.

[0157] Computing device 600 also includes a measurement unit (MU) 603, which is configured to obtain measurements of side-channel information, such as measurements of physical property(ies) of components (e.g., processors, cores, GPUs, etc.) of processing circuitry 602, on which the programs 614 execute. For example, MU 603 may include side-channel receiver circuitry capable of capturing measurements of side-channel information emitted during execution of the programs 614. For example, the measurements may be of physical properties such as the power (or energy) consumption, electromagnetic emissions (including optical, infrared, sound, etc.), temperature, thermal emissions, time or duration, processing capacity usage, and memory usage. MU 603 may be similar in structure and / or function to MU 124 shown in Figure 1 and / or MU 310 shown in Figure 3.

[0158] Memory 610 may also include a measurement cache 615, which may be configured for temporary storage of the measurements of side-channel information obtained by MU 603. In addition, memory 610 may also store a scheduler 613, which is arranged to schedule execution of the programs 614 on respective components (e.g., processors, cores, GPUs, etc.) of processing circuitry 602. In some embodiments, scheduler 613 may be one of the programs 614 that run on processing circuitry 602, e.g., as part of an operating system (OS).

[0159] Computing device 600 also includes a secure (or security) component 605, which may be similar to security component 202 shown in Figure 2 and / or secure component 326 shown in Figure 3. Secure component 605 may include security-related circuitry (and software) such as a device unique function (DUF), a challenge creator function, and / or a key derivation function (KDF). For example, secure component 605 may be a separate module (e.g., relative to other blocks / modules shown) that is resistant to tampering and / or unauthorized intrusions.

[0160] Memory 610 may be configured to include a number of physical drive units, such as redundant array of independent disks (RAID), flash memory, USB flash drive, external hard disk drive, thumb drive, pen drive, key drive, high-density digital versatile disc (HD-DVD) optical disc drive, internal hard disk drive, Blu-Ray optical disc drive, holographic digital data storage (HDDS) optical disc drive, external mini-dual in-line memory module (DIMM), synchronous dynamic random access memory (SDRAM), external micro-DIMM SDRAM, smartcard memory such as tamper resistant module in the form of a universal integrated circuit card (UICC) including one or more subscriber identity modules (SIMs), such as a USIM and / or ISIM, other memory, or any combination thereof. The UICC may for example be an embedded UICC (eUICC), integrated UICC (iUICC) or a removable UICC commonly known as ‘SIM card.’ Memory 610 may allow computing device 600 to access instructions, application programs and the like, stored on transitory or non-transitory memory media, to off-load data, or to upload data. An article of manufacture, such as one utilizing a communication system may be tangibly embodied as or in memory 610, which may be or comprise a device-readable storage medium.

[0161] Processing circuitry 602 may be configured to communicate with an access network or other network using communication interface 612. Communication interface 612 may comprise one or more communication subsystems and, in some cases, may include or be communicatively coupled to an antenna 622. Communication interface 612 may include one or more transceivers used to communicate with other devices or nodes, such as another computing device or a network node in an access network. Each transceiver may include a transmitter 618 and / or a receiver 620 appropriate to provide network communications (e.g., optical, electrical, frequency allocations, and so forth). Moreover, transmiter 618 and receiver 620 may be coupled to one or more antennas (e.g., antenna 622) and may share circuit components, software, or firmware, or alternatively be implemented separately.

[0162] In the illustrated embodiment, communication functions of communication interface 612 may include cellular communication, Wi-Fi communication, LPWAN communication, data communication, voice communication, multimedia communication, short-range communications such as Bluetooth, near-field communication, location-based communication such as the use of the global positioning system (GPS) to determine a location, another like communication function, or any combination thereof. Communications may be implemented in according to one or more communication protocols and / or standards, such as IEEE 802.11, Code Division Multiplexing Access (CDMA), Wideband Code Division Multiple Access (WCDMA), GSM, LTE, New Radio (NR), UMTS, WiMax, Ethernet, transmission control protocol / intemet protocol (TCP / IP), synchronous optical networking (SONET), Asynchronous Transfer Mode (ATM), QUIC, Hypertext Transfer Protocol (HTTP), and so forth.

[0163] The computing device may be intended and / or configured for use in one or more application domains. As such, the computing device may include circuitry and / or software that supports operation in the intended application domain(s), in addition to other components described above for computing device 600 shown in Figure 6.

[0164] Figure 7 is a block diagram illustrating a computing system 700 according to some embodiments of the present disclosure.

[0165] Computing system 700 may include a runtime environment 720 hosted by one or more of hardware nodes 730. Such hardware nodes can be computing machines arranged in a cluster (e.g., such as in a data center or customer premise equipment (CPE)) where many hardware nodes work together and are managed via management and orchestration (MANO) 7100, which, among others, oversees lifecycle management of applications. Runtime environment 720 can run on top of an operating system (OS) 725, such as Linux or Windows, which runs directly on hardware nodes 730. Alternately, OS 725 may run on a virtual machine (VM), which abstracts one or more of the hardware nodes 730.

[0166] Hardware nodes 730 may include processing circuitry 760 and memory 790. Memory 790 contains instructions (or software code) 795 executable by processing circuitry 760 whereby application 740 can be operative for various features, functions, procedures, etc. of the embodiments disclosed herein. Processing circuitry 760 can include general-purpose or specialpurpose hardware devices such as one or more processors (e.g., custom and / or commercial off- the-shell), dedicated Application Specific Integrated Circuits (ASICs), or any other type of processing circuitry including digital or analog hardware components or special purpose processors. Each memory 790 of a hardware node can comprise memory 790-1 which can be non- persistent memory for temporarily storing instructions 795 executed by processing circuitry 760 of the hardware node. For example, instructions 795 can include program instructions (also referred to as a computer program product) that, when executed by processing circuitry 760, can configure hardware node 730 to perform operations corresponding to the methods / procedures described herein.

[0167] Each hardware node 730 can include one or more network interface controllers or cards (NICs) 770, which include physical network interface 780. Each memory 790 of a hardware node can also include non-transitory, persistent, machine-readable storage media 790-2 having stored therein the instructions executable by processing circuitry 760. Instructions 795 can include any type of software including operating system 725, runtime environment 720, software integrity tool 750, and containerized applications 740.

[0168] Various applications 742 (which can alternatively be called programs, software instances, virtual appliances, network functions, virtual nodes, virtual network functions, containers, containerized applications, services, etc.) can be executed by host computing system 700. Some or all of the applications 742 may be included in respective container 74E

[0169] In some embodiments, runtime environment 720 may abstract applications 742 and containers 741 from the underlying hardware nodes 730. In such embodiments, processing circuitry 760 executes software 795 to instantiate runtime environment 720, which can in some instances be a Docker Runtime. For example, runtime environment 720 can appear like computing and / or networking hardware to containers and / or pods hosted by host computing system 700.

[0170] In some embodiments, multiple application containers 741 can be arranged in a pod 740 (e.g., a Kubemetes pod). In such embodiments, each pod 740 can be a basic execution unit, i.e., the smallest and simplest unit that can be created and deployed in host computing system 700. This may be the case, for instance, when multiple containers 741 encapsulate services that are used are building blocks for a higher-level application, represented by pod 740.

[0171] Each pod can include a plurality of resources shared by containers within the pod. For example, a pod can represent processes running on a cluster and can encapsulates container(s) (including applications / services therein), storage resources, a unique network IP address, and options that govern how the container(s) should run. In general, containers can be relatively decoupled from underlying physical or virtual computing infrastructure.

[0172] MANO 7100 may include a scheduler 7101 arranged to schedule execution of programs 742, containers 741, and / or pods 740 on respective components (e.g., processors, cores, GPUs, etc.) of processing circuitry 760. Alternately, scheduler 760 may be part of OS 725. MANO 7100 may also include a measurement unit (MU) 7102, which is configured to obtain measurements of side-channel information, such as measurements of physical property(ies) of components (e.g., processors, cores, GPUs, etc.) of processing circuitry 760, on which programs 742, containers 741, and / or pods 740 execute. For example, MU 7102 may include side-channel receiver circuitry capable of capturing measurements of side-channel information emitted during execution of programs 742, containers 741, and / or pods 740. For example, the measurements may be of physical properties such as the power (or energy) consumption, electromagnetic emissions (including optical, infrared, etc.), temperature, thermal emissions, sound emissions, time or duration, processing capacity usage, and memory usage. MU 7102 may be similar in structure and / or function to MU 124 shown in Figure 1 and / or MU 310 shown in Figure 3.

[0173] MANO 7100 may also include a measurement cache 7103, which may be configured for temporary storage of the measurements of side-channel information obtained by MU 7102. For example, measurement cache 7103 may utilize memory 790-1 for such temporary storage.

[0174] MANO 7100 may also include a secure (or security) component 7104, which may be similar to security component 202 shown in Figure 2 and / or secure component 326 shown in Figure 3. Secure component 7104may include security-related circuitry (and software) such as a device unique function (DUF), a challenge creator function, and / or a key derivation function (KDF). For example, secure component 7104 may be a separate module (e.g., relative to other blocks / modules shown) that is resistant to tampering and / or unauthorized intrusions.

[0175] Alternately, one or more of measurement unit 7102, measurement cache 7103, and secure component 7104 may be logically and / or physically external to MANO 7100. This arrangement is illustrated in Figure 7 as measurement unit 751, measurement cache 752, and secure component 753, which are accessible via OS 725.

[0176] The foregoing merely illustrates the principles of the disclosure. Various modifications and alterations to the described embodiments will be apparent to those skilled in the art in view of the teachings herein. It will thus be appreciated that those skilled in the art will be able to devise numerous systems, arrangements, and procedures that, although not explicitly shown or described herein, embody the principles of the disclosure and can be thus within the spirit and scope of the disclosure. Various embodiments can be used together with one another, as well as interchangeably therewith, as should be understood by those having ordinary skill in the art.

[0177] The term unit, as used herein, can have conventional meaning in the field of electronics, electrical devices and / or electronic devices and can include, for example, electrical and / or electronic circuitry, devices, modules, processors, memories, logic solid state and / or discrete devices, computer programs or instructions for carrying out respective tasks, procedures, computations, outputs, and / or displaying functions, and so on, as such as those that are described herein.

[0178] Any appropriate steps, methods, features, functions, or benefits disclosed herein may be performed through one or more functional units or modules of one or more virtual apparatuses. Each virtual apparatus may comprise a number of these functional units. These functional units may be implemented via processing circuitry, which may include one or more microprocessor or microcontrollers, as well as other digital hardware, which may include Digital Signal Processor (DSPs), special-purpose digital logic, and the like. The processing circuitry may be configured to execute program code stored in memory, which may include one or several types of memory such as Read Only Memory (ROM), Random Access Memory (RAM), cache memory, flash memory devices, optical storage devices, etc. Program code stored in memory includes program instructions for executing one or more telecommunications and / or data communications protocols as well as instructions for carrying out one or more of the techniques described herein. In some implementations, the processing circuitry may be used to cause the respective functional unit to perform corresponding functions according to one or more embodiments of the present disclosure.

[0179] As described herein, device and / or apparatus can be represented by a semiconductor chip, a chipset, or a (hardware) module comprising such chip or chipset; this, however, does not exclude the possibility that a functionality of a device or apparatus, instead of being hardware implemented, be implemented as a software module such as a computer program or a computer program product comprising executable software code portions for execution or being run on a processor. Furthermore, functionality of a device or apparatus can be implemented by any combination of hardware and software. A device or apparatus can also be regarded as an assembly of multiple devices and / or apparatuses, whether functionally in cooperation with or independently of each other. Moreover, devices and apparatuses can be implemented in a distributed fashion throughout a system, so long as the functionality of the device or apparatus is preserved. Such and similar principles are considered as known to a skilled person.

[0180] Unless otherwise defined, all terms (including technical and scientific terms) used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this disclosure belongs. It will be further understood that terms used herein should be interpreted as having a meaning that is consistent with their meaning in the context of this specification and the relevant art and will not be interpreted in an idealized or overly formal sense unless expressly so defined herein.

[0181] In addition, certain terms used in the present disclosure, including the specification and drawings, can be used synonymously in certain instances (e.g., “data” and “information”). It should be understood, that although these terms (and / or other terms that can be synonymous to one another) can be used synonymously herein, there can be instances when such words can be intended to not be used synonymously.

Claims

CLAIMS1. A computer-implemented method for generating one or more cryptographic keys that are uniquely associated with execution of a software program by a computing device comprising a device-unique function, DUF, the method comprising obtaining (510) at least one challenge input for the DUF, wherein the at least one challenge input is based on measurements of side-channel information resulting from the execution of the software program on the computing device; using the DUF, generating (520) at least one challenge response based on the respective at least one challenge input; and generating (530) one or more cryptographic keys based on the at least one challenge response.

2. The method of claim 1, wherein obtaining (510) the at least one challenge input for the DUF comprises: obtaining (511) the measurements of the side-channel information during execution of the software program on the computing device; and generating (514) the at least one challenge input for the DUF based on the obtained measurements.

3. The method of claim 2, wherein the computing device includes a scheduler arranged to schedule execution of the software program, and the measurements are obtained in response to an indication from the scheduler of the scheduled execution of the software program.

4. The method of claim 3, wherein the indication from the scheduler includes one or more of the following: an execution start indication, an indication of one or more device component on which the software executes or will execute, a number of measurements to be captured, and a duration over which the measurements should be captured.

5. The method of any of claims 3-4, wherein the computing device also includes a measurement unit and a measurement cache, and obtaining (511) the measurements is performed by the measurement unit based on capturing the measurements and storing the captured measurements in the measurement cache.

346. The method of claim 5, wherein the computing device includes a challenge creator function, and the at least one challenge input for the DUF is generated by the challenge creator function in response to an indication from the scheduler that the obtained measurements are ready in the measurement cache.

7. The method of any of claims 2-6, wherein the obtained measurements of side-channel information are of a first dimension, and generating (510) the at least one challenge input further comprises encoding (512) the obtained measurements of side-channel information from the first dimension to a second dimension that is less than the first dimension.

8. The method of claim 7, wherein one of the following applies: the at least one challenge input is generated based on the encoded measurements in the second dimension; or generating (510) the at least one challenge input further comprises transforming (513) the encoded measurements into a sequence of integers using a vector quantizer, wherein the at least one challenge input is generated based on the sequence of integers.

9. The method of claim 8, wherein one or more of the following is based on a machine learning model trained on measurements of side-channel information captured during execution of the software program and one or more further software programs on the computing device: encoding (512) the obtained measurements, and transforming (513) the encoded measurements using the vector quantizer.

10. The method of any of claims 8-9, wherein encoding (512) the obtained measurements and / or transforming (513) the encoded measurements results in at least one challenge input that does not change for different executions of the software on the computing device.

11. The method of any of claims 1-10, wherein the measurements of side-channel information comprise measurements of at least one physical property of one or more device components on which the software program executes.

12. The method of claim 11, wherein for each device component on which the software program executed, the measurements include the following: an identifier of the device component;indications of one or more time periods during which the software program executed on the device component; and for each of the one or more time periods, the measurements of at least one physical property of the device component.

13. The method of claim 12, wherein generating (510) the at least one challenge input based on the measurements comprises: combining (517) the measurements obtained for each of the one or more time periods and for each of the one or more device components to obtain a measurement profile for the computing device and the software program; and generating (518) the at least one challenge input based on the measurement profile.

14. The method of any of claims 11-13, wherein the at least one physical property includes one or more of the following: power consumption, electromagnetic emissions, temperature, time or duration, processing capacity usage, and memory usage.

15. The method of any of claims 1-14, wherein each challenge input is one of a predetermined plurality of codewords and generating (510) the at least one challenge input comprises, for each of the at least one challenge input: generating (515) an initial challenge input based on the measurements of side-channel information, wherein the initial challenge input is not limited to the predetermined plurality of codewords; and applying (516) error correction to the initial challenge input to obtain one of the predetermined pluralities of codewords as the challenge input.

16. The method of claim 15, wherein applying (516) error correction to the initial challenge input comprises modifying a subset of bits in a bitfield that represents the initial challenge input, such that the bitfield represents one of the predetermined pluralities of codewords.

17. The method of any of claims 1-16, wherein the one or more cryptographic keys include one of the following: a master key for further key derivation, a single symmetric key, a private key, or an asymmetric key pair of public and private keys.

18. The method of claim 17, further comprising performing (540) one or more of the following cryptographic operations using the one or more cryptographic keys: generating a digital signature or message authentication code, deriving another key from the master key, encrypting data generated by execution of the software program on the computing device, integrity protection of the data, decrypting further data generated by further execution of the software program on the computing device, and integrity verification of the further data.

19. The method of any of claims 1-18, wherein the DUF is a physical unclonable function, PUF.

20. The method of any of claims 1-19, further comprising: obtaining (550) at least one further challenge input for the DUF, wherein the at least one further challenge input is based on measurements of side-channel information resulting from further execution of the software program or of a second software program on the computing device; using the DUF, generating (560) at least one further challenge response based on the respective at least one further challenge input; and generating (570) one or more further cryptographic keys based on the at least one further challenge response.

21. The method of claim 20, wherein the further execution is of the software program during an enrolment procedure before the execution of the software program, and the method further comprises sending (580) one of the further cryptographic keys to a storage repository for subsequent use as a reference key.

22. The method of claim 20, wherein the further execution is of the second software program after the execution of the software program, and the one or more further cryptographic keys are also based on one or more of the following: the at least one challenge input, the at least one challenge response, and the one or more cryptographic keys.

23. A computing device or system (300, 600, 700) configured to generate one or more cryptographic keys that are uniquely associated with execution of a software program (306) on the computing device, wherein the computing device comprises: processing circuitry (302, 602, 760) arranged to execute software programs; anda secure component (326, 605, 7104) comprising a device-unique function, DUF (322), wherein the secure component is configured to: obtain at least one challenge input for the DUF, wherein the at least one challenge input is based on measurements of side-channel information resulting from the execution of the software program on the computing device; using the DUF, generate at least one challenge response based on the respective at least one challenge input; and generate one or more cryptographic keys based on the at least one challenge response.

24. The computing device or system of claim 23, wherein one of the following applies: the one or more cryptographic keys are generated using the DUF; or the secure component further comprises a key derivation function, KDF (324) configured to generate the one or more cryptographic keys.

25. The computing device or system of any of claims 23-24, further comprising a measurement unit (310, 603, 7102, 751) and a measurement cache (312, 615, 7103, 752), wherein the measurement unit is configured to obtain the measurements based on capturing the measurements and storing the captured measurements in the measurement cache.

26. The computing device or system of any of claims 23-25, wherein the secure component further comprises a challenge creator function (314) configured to generate the at least one challenge input based on the measurements of side-channel information.

27. A computing device or system (300, 600, 700) configured to generate one or more cryptographic keys that are uniquely associated with execution of a software program (306) on the computing device, wherein the computing device comprises a device-unique function, DUF (322) and is further configured to: obtain at least one challenge input for the DUF, wherein the at least one challenge input is based on measurements of side-channel information resulting from the execution of the software program on the computing device; using the DUF, generate at least one challenge response based on the respective at least one challenge input; and generate one or more cryptographic keys based on the at least one challenge response.

28. The computing device or system of claim 27, wherein one of the following applies: the one or more cryptographic keys are generated using the DUF; or the computing device further comprises a key derivation function, KDF (324) configured to generate the one or more cryptographic keys.

29. The computing device or system of any of claims 27-28, further comprising a measurement unit (310, 603, 7102, 751) and a measurement cache (312, 615, 7103, 752), wherein the measurement unit is configured to obtain the measurements based on capturing the measurements and storing the captured measurements in the measurement cache.

30. The computing device or system of any of claims 27-29, further comprising a challenge creator function (314) configured to generate the at least one challenge input based on the measurements of side-channel information.

31. A non-transitory, computer-readable medium (328) storing computer-executable instructions that, when executed by a computing device or system (300, 600, 700) that comprises a device-unique function, DUF (322) and is configured to generate one or more cryptographic keys that are uniquely associated with execution of a software program (306) on the computing device or system, configure the computing device or system to perform operations corresponding to any of the methods of claims 1-22.

32. A computer program product (329) comprising computer-executable instructions that, when executed by a computing device or system (300, 600, 700) that comprises a device-unique function, DUF (322) and is configured to generate one or more cryptographic keys that are uniquely associated with execution of a software program (306) on the computing device or system, configure the computing device or system to perform operations corresponding to any of the methods of claims 1-22.

Images