Security components and operation methods

Abstract

A security component (102, 202) for a device (200) is disclosed. The security component (102) includes: a physical unclonable function (PUF) (150) having a plurality of sub-functions (152); and a management module (110) configured to manage the PUF (150) according to a policy. The management module (110) includes: a measurement module (112) configured to receive at least one of a measurement of a component on the device or a measurement of a hardware state of the device from a device boot process; and a rule module (114) configured to compare the received measurement with at least one rule implementing the policy and enter a policy state based on the comparison. The management module also includes: a control module (116) configured to configure the PUF (150) according to the policy state entered by the rule module. A method (300) for operating a security component is also disclosed.

Description

Technical Field

[0001] The present disclosure relates to a security component for a device and a method for operating a security component for a device. The present disclosure also relates to a computer program and a computer program product configured to perform the method for operating a security component for a device when executed on a computer. Background Art

[0002] A physically unclonable function (PUF) can be used as part of a security device for an electronic device, which may be, for example, a device operable to communicate via wired or wireless technology and operable to connect to a communication network. The PUF is used to generate a unique response by exploiting implicit or explicit randomness in the physical structure of the PUF. Implicit randomness refers to unpredictable manufacturing differences in semiconductor devices that can be used to generate a device-unique response. Explicit randomness refers to differences that are not an inherent result of manufacturing but are intentionally introduced at a later stage. The PUF response can be used for encryption or device identity purposes. For example, the PUF response can be used to generate a unique device identity or a device-unique key without having to store the key in, for example, battery-backed random access memory (BBRAM) or one-time password (OTP) memory.

[0003] A PUF may include one or more elements or components, which are referred to in this disclosure as sub-functions. Each sub-function contributes a portion of the PUF response. Examples of sub-functions may include:

[0004] Ring Oscillator: The number of signal inverters in the ring is odd, and the ring uses gate delay propagation as a source of randomness. The PUF response is a comparison between two or more ring oscillators, where the number of oscillations at a given point is measured. The response can, for example, be an identifier of the fastest / slowest ring oscillator.

[0005] An uninitialized static random access memory (SRAM) cell has two possible states (0 and 1). Before power is applied, the cell is not in either state. At power-up, the cell settles into one of two states. The response is the state entered.

[0006] Each sub-function also has the property of being physically unclonable, ie, unique to a device. Thus, a PUF may include multiple sub-functions that can be used as independent PUFs, albeit with fewer possible challenges and fewer response bits.

[0007] There are many different types of PUFs, and they can be categorized based on performance, physical structure, and more. Challenge-response PUFs require input to trigger a PUF response. Challenge-response PUFs include static PUFs, which only support a single challenge to which they return a response, and PUFs that support multiple challenge-response mappings. Most PUF types additionally require user data in order to function correctly; for example, a PUF may need helper data to increase the probability of reproducing the exact same response under the same challenge. Because PUF responses are often sensitive and should be kept confidential, devices containing PUFs are typically required to have firmware and / or hardware that protects the PUF.

[0008] PUFs are not client-aware and, therefore, cannot protect any secrets if accessed by an unauthorized party. Therefore, the PUF and its responses must be protected by the device on which the PUF is installed. If the device is compromised, any secrets protected by the PUF are also compromised. This presents a particular challenge if the PUF response or any derivatives thereof are to be protected from corruption by a party with physical access to the device. Challenge-response PUFs can deterministically generate multiple responses. Any challenge-response pair can be generated by anyone with access to the PUF. To ensure that a specific response is unavailable to a specific user, the corresponding challenge must be kept secret, thus eliminating part of the advantage of using a PUF: the lack of secrets stored in OTP or BBRAM.

[0009] US 10,263,793 discloses the possibility of modifying the PUF response due to a "tampering event." This could temporarily disable the PUF to prevent it from providing its response and thereby revealing the associated key or identity during the investigation of the tampering event. In other examples, the modification could be a permanent change, essentially destroying the PUF by permanently modifying the structure of the installed PUF, and therefore destroying the PUF's response to challenges. Summary of the Invention

[0010] One object of the present disclosure is to provide a security component, a method of operating a security component, and a computer-readable medium that cooperate to provide a security component response that is dependent on the component booted on a device and consistent with policy.

[0011] According to a first aspect of the present disclosure, a security component for a device is provided, the security component comprising: a physical unclonable function (PUF) having multiple sub-functions; and a management module configured to manage the PUF according to a policy. The management module comprises: a measurement module configured to receive at least one of a measurement of a component on the device or a measurement of the device's hardware state during a device boot process; and a rule module configured to compare the received measurement with at least one rule implementing the policy and enter a policy state based on the comparison. The management module further comprises: a control module configured to configure the PUF according to the policy state entered by the rule module.

[0012] According to another aspect of the present disclosure, a method for operating a security component for a device is provided, the security component comprising: a PUF having multiple sub-functions; and a management module configured to manage the PUF according to a policy. The method comprises: receiving, from a device boot process, at least one of a measurement of a component on the device or a measurement of a hardware state of the device; and comparing the received measurement to at least one rule implementing the policy. The method further comprises: entering a policy state based on the comparison; and configuring the PUF according to the entered policy state.

[0013] According to another aspect of the present disclosure, there is provided a computer program product comprising a computer-readable medium having computer-readable code embodied therein, wherein the computer-readable code is configured to, when executed by a suitable computer or processor, cause the computer or processor to perform the method according to any aspect or example disclosed herein.

[0014] Thus, aspects of the present disclosure provide a security component including a PUF that effectively "senses" the environment in which it operates. That is, the security component is operable to modify its behavior based on the components and policies booted on its device. A management module of the security component evaluates the environment in which it operates by comparing measurements (e.g., hash values) of the booted components or hardware states to pre-defined policies. The policies determine which state the management module should enter based on the received measurements and, therefore, how the PUF should be configured. According to some examples of the present disclosure, each state that the management module can enter forces the PUF to use a specific sub-function and, therefore, generates a response that is unique not only to the device but also to the current device environment. According to other examples of the present disclosure, once a state has been entered, PUF sub-functions that are not used by the current state can be disabled, thereby providing an additional layer of security to prevent malicious attempts to generate responses belonging to other states. BRIEF DESCRIPTION OF THE DRAWINGS

[0015] For a better understanding of the present disclosure, and to show more clearly how it may be put into practice, reference will now be made, by way of example, to the following drawings, in which:

[0016] Figure 1 is a block diagram illustrating a first example of a security component for a device;

[0017] Figure 2 is a block diagram illustrating another example of a security component and a device on which the security component is installed;

[0018] Figure 3 is a flow chart illustrating a method for operating a security component for a device;

[0019] Figures 4a to 4c A flow chart illustrating another example of a method for operating a security component for a device is shown;

[0020] Figure 5 An example implementation of a security component is shown;

[0021] Figure 6 An example policy including multiple state paths is shown;

[0022] Figure 7 、 8 and 11 show elements of an example safety assembly in use;

[0023] Figure 9 shows an example process flow before a device boots; and

[0024] Figure 10 and 12 An example process flow after a device boots is shown. DETAILED DESCRIPTION

[0025] Examples of the present disclosure provide a security component for a device and a method of operation that implements a finite number of states, each state being associated with a specific PUF configuration and, therefore, a specific PUF response. Each state requires a specific combination of measurements of components booted on the device and / or measurements of the device's hardware state in order to enter that state. The state (including the measurements required for each state to be entered) is determined by a policy. Therefore, the state entered by the security component depends on measurements of components booted on the device and / or the device's hardware state, but is not necessarily a direct result of these measurements. The policy specifies valid measurement combinations for entering each possible state. Some states can only be accessed via other states so that different responses can be chained, with one or more responses being accessible only after an initial response has been provided. The configuration of such sub-states is determined by the policy. For the avoidance of doubt, the hardware state of a device refers to the current hardware state and / or configuration of the device. The state associated with a security component (referred to as "state") refers to the current state and / or configuration of the security component.

[0026] The policy can be designed to protect access to the PUF, for example, by allowing access only to specific states and, therefore, specific PUF responses, when a specific configuration of components has been booted on the device. Thus, a user booting the device can only access PUF responses and their derivatives that are consistent with the booted device components and the user's specific device settings. Access to PUF responses for specific device environments can be tailored through appropriate policy design and modification. Rules implementing the policy can be configured on the secure element prior to use using a signed bitstream or other configuration information created off-chip.

[0027] If the provided measurements do not correspond to any state in the policy, or are otherwise incompatible with the policy, the secure component can enter a fallback state, which can, for example, cause the PUF to become static, thereby only providing responses that are accessible to all users, or completely disable the PUF. According to some examples, when a state in the policy becomes inaccessible based on measurements that have been received, only the PUF sub-functions used in the configuration associated with such inaccessible state can be disabled, thereby physically prohibiting the PUF from outputting responses belonging to the inaccessible state.

[0028] Figure 1 1 is a block diagram illustrating a first example of a security component 102 for a device according to the present disclosure. The device may include an electronic device, which may be, for example, a device operable to communicate via wired or wireless technology and operable to connect to a communication network. The device may, for example, include a UE. Figure 1The secure component 102 includes a physically unclonable function (PUF) 150 having multiple sub-functions 152. For the purposes of this disclosure, a PUF sub-function includes a component of the PUF that generates a portion (e.g., 1 bit) of a PUF response. Therefore, a PUF sub-function may be referred to as a PUF element or PUF component and may be embodied by a pair of ring oscillators, an SRAM memory cell, an arbiter, a transistor component, etc. The secure component also includes a management module 110 configured to manage the PUF 150 according to a policy. The management module includes a measurement module 112 configured to receive, from the device boot process, at least one of a measurement of a component booting on the device or a measurement of the device's hardware state, including temperature, tamper detection, etc. The measurement module may, for example, include multiple measurement registers. The management module 110 also includes a rule module 114 configured to compare the received measurement with at least one rule implementing the policy and, based on the comparison, enter a policy state. The management module 110 also includes a control module 116 configured to configure the PUF according to the policy state entered by the rule module.

[0029] Thus, the security component 102 uses a policy to determine how its PUF should be configured, the policy determining the PUF configuration based on the context of the device on which the PUF is installed (i.e., based on the components booted on the device and / or the hardware state of the device). The components booted on the device can be software components or bitstreams, and the measurements can include functions of the booted components or hardware state, such as cryptographic functions of the components or state (e.g., hash functions). Configuring the PUF by the control module can include activating one or more sub-functions of the PUF, such as selecting a sub-function to use by submitting a challenge to the PUF, configuring the behavior of the sub-functions, or remapping the challenge-response mapping using a logically reconfigurable PUF (LR-PUF).

[0030] PUF 150 may include any type of PUF. It will be understood that in order to implement a given policy, the PUF should satisfy at least one of the following conditions:

[0031] - The PUF includes an appropriate number of sub-functions so that the number of available challenges for the PUF is at least equal to the number of states defined in the policy

[0032] -PUF includes LR-PUF.

[0033] Figure 2 is a block diagram illustrating another example of a security component 202 and a device 200 on which the security component is installed. Figure 2 The security component 202 illustrates various options for how the management module 110 may implement the security component 102 .

[0034] refer to Figure 2, the device 200 on which the security component 202 is installed includes a processor 204 and a memory 206, on which one or more computer programs 208 may be stored. According to various examples of the present disclosure, items of "helper data" 207 (including, for example, error correction codes) may also be stored in the memory 206. The device 200 may additionally include one or more telecommunication interfaces for wired or wireless communication. The security component 202 includes a PUF 250 having a plurality of sub-functions 252. The security component 202 also includes a management module 210 configured to manage the PUF 250 according to a policy. As with the security component 102, the management module 210 of the security component 202 includes a measurement module 212, a rule module 214, and a control module 216. The measurement module 212 is configured to receive at least one measurement of a component booted on the device from the device boot process. The measurement module 212 may, for example, include a plurality of measurement registers. The rule module 214 is configured to compare the received measurement with at least one rule implementing the policy and enter a policy state based on the comparison. The control module 216 is configured to configure the PUF according to the policy state entered by the rule module.

[0035] The rule module 214 can be configured to receive configuration information defining at least one rule implementing the policy. The configuration information can be a bitstream (e.g., if the management module 210 is implemented as reconfigurable logic) or a memory and / or register configuration (e.g., if the management module 210 is implemented as an ASIC). The management module 210 also includes an authentication module 218 configured to authenticate the configuration information using security credentials.

[0036] According to an example of the present disclosure, a policy implemented by at least one rule includes a state path and a measurement path, through which at least one state can be reached. The state path includes at least one state corresponding to activating at least one sub-function of the PUF and accepting at least one request for generating a PUF response. The measurement path defines an ordered sequence of at least one measurement value of the following items: a component that can be booted on a device, or a hardware state of the device. Each state path may include more than one state, and each state on the state path may have a specific measurement path through which the state can be reached, so that the measurement path and state are effectively linked together. In some examples, the state path may include, for example, a state to be directly entered from another state after a threshold number of requests for PUF responses have been received. The policy may include multiple state paths.

[0037] The policy implemented by the at least one rule may also include a fallback path that defines at least one fallback state. The rules module 214 may also be configured to enter the fallback path if a comparison between the received measurement and the one or more rules indicates that the received measurement is incompatible with a valid next step along the measurement path in the policy.

[0038] If no measurement path has been started, the valid next step can be the first step on any measurement path in the strategy. If a measurement path has been started, the available progress along the measurement path includes the valid next steps on the paths that have been started. An example strategy that includes multiple state paths is shown in Figure 6 and discussed in more detail below.

[0039] The rules module 214 can also be configured to: based on the comparison, identify a policy state that can no longer be validly entered; and cause the identified policy state to become unreachable. A policy state that can no longer be validly entered can be a policy state that is unreachable via the policy's state path based on received measurements. Making the policy state unreachable means that the PUF behavior associated with the state is no longer accessible and, therefore, effectively disabled. For example, only PUF sub-functions associated with the unreachable state can be disabled when the state that uses these PUF sub-functions becomes unreachable.

[0040] The management module 210 may also include a plurality of state storage modules 220, and the rule module may make the identified policy state inaccessible by: writing to the state storage module corresponding to the identified policy state; and then preventing any further data from being written to the state storage module for the identified policy state. The state storage module 220 may include, for example, registers or other storage solutions.

[0041] Due to, for example, temperature variations, hardware degradation, and the like, responses generated by PUF 250 may be unstable between generations. Consequently, responses generated for a particular challenge may vary over time, such that responses generated for that challenge several generations later may contain errors compared to responses generated when the particular challenge was first submitted. According to some examples of the present disclosure, the output of PUF 250 may therefore undergo error correction to correct for such output variations. In some examples of security component 202, management module 210 may also include an error correction module 219 configured to correct errors in responses generated by the PUF. Error correction module 219 may include one or more error correction functions and may be configured to: extract helper data 207 from a first response generated for a challenge and store it in memory 206 of device 200, and use helper data 207 to perform error correction on responses subsequently generated for the challenge. Error correction may correct errors in responses due to variations (e.g., temperature variations and / or hardware degradation).

[0042] The management module is configured to receive a request for a PUF response, and then the rules module 214 is configured to determine whether the current policy state is compatible with granting the request, and if so, instruct the control module 216 to cause the PUF 250 to generate a response based on the current configuration of the PUF 250. The rules module may then increment a count of the number of times the PUF 250 has generated a response using the rules module in the current policy state. If the incremented count exceeds a count threshold for the current policy state, the rules module 214 may exit the current policy state. Upon exiting the current policy state, the rules module 214 may traverse the next step in the state path, which may include measuring the next measured value on the measurement path (to be compared with the next received measurement value), entering another policy state, entering a fallback state, and so on. Thus, if the incremented count exceeds a count threshold for the current policy state, the rules module may enter at least one of: a different policy state; a measurement path by which the different policy state can be reached, the measurement path defining an ordered sequence of at least one measurement value of a component that can be guided on the device; or a fallback path defining at least one fallback state. The fallback state may be associated with a specific configuration of the PUF 250 (which generates a response to be available to any user), or may be associated with disabling the PUF 250, for example.

[0043] As discussed in greater detail below with respect to example implementations of the security components 102 , 202 , the management module may be implemented using at least one of: reconfigurable control logic, a hard logic block, and / or at least one software module.

[0044] Figure 33 is a flow chart illustrating a method 300 for operating a security component for a device. The security component includes: a PUF having multiple sub-functions; and a management module configured to manage the PUF according to a policy. The security component may, for example, include the security component 102 or 202 described above. Figure 3 The method includes, in a first step 310, receiving at least one of a measurement of a component booted on the device or a measurement of a hardware state of the device from a device boot process. The method further includes, in a step 320, comparing the received measurement with at least one rule implementing the policy, and, in a step 330, entering a policy state based on the comparison. The method further includes, in a step 340, configuring the PUF according to the policy-entered state.

[0045] Figures 4a to 4c A flowchart illustrating process steps in another example of a method 400 for operating a security component for a device is shown. As with method 300, the security component includes a PUF having multiple sub-functions and a management module configured to manage the PUF according to a policy. The security component may, for example, include security component 102 or 202 as described above. Method 400 illustrates an example of how the steps of method 300 may be implemented and supplemented to achieve the aforementioned and additional functionality.

[0046] First reference Figure 4a In a first step 402, method 400 includes receiving configuration information defining at least one rule implementing a policy according to which the PUF is to be managed. The method further includes authenticating the configuration information using security credentials in step 404. In step 410, the method includes receiving, from a device boot process, at least one of a measurement of a component booting on the device or a measurement of a hardware state of the device, and, in step 420, comparing the received measurement to the at least one rule implementing the policy. As shown in 420a, the policy implemented by the at least one rule includes a state path having at least one state, the at least one state corresponding to activating at least one sub-function of the PUF and accepting at least one request for generating a PUF response. The policy also includes a measurement path through which the at least one state of the state path can be reached. The measurement path defines an ordered sequence of at least one measurement value of a component bootable on the device or a hardware state of the device. Also as shown in 420a, the policy implemented by the at least one rule may also include a fallback path defining at least one fallback state.

[0047] In step 422, the method includes determining whether a comparison between the received measurement and the rule indicates that the received measurement is compatible with a valid next step on a measurement path in the policy. If the measurement path has not yet been initiated, the valid next step may be the first step on any measurement path in the policy. If the measurement path has already been initiated, the valid next step includes the next step on the path that has already been initiated. If the comparison indicates that the received measurement is not compatible with a valid next step on the measurement path in the policy ("No" in step 422), the method includes entering a fallback path in step 424. Now referring to Figure 4b If the comparison indicates that the received measurement is compatible with a valid next step on the measurement path in the policy ("yes" in step 422), the method includes entering the policy state based on the comparison. As shown in step 430a, for example, if the measurement received in step 410 does not directly lead to the policy state, but leads to another measurement on the current measurement path, the policy state can be entered via one or more additional measurements received on the measurement path that lead to the policy state.

[0048] In step 432, the method includes identifying a policy state that is no longer validly enterable based on the comparison in step 420. This may include a state that is now unreachable via any measurement path in the policy based on one or more measurements received. In step 434, the method includes causing the identified policy state to become unreachable. As shown in 434a and 434b, causing the identified policy state to become unreachable may include writing to a state storage module (e.g., a state register) corresponding to the identified policy state and preventing any further data writes to the state storage module for the identified policy state.

[0049] In step 440, the method includes configuring the PUF according to the policy state entered in step 430. As shown in 440a and 440b, this may include, for example, selecting which sub-functions to use by submitting a challenge to the PUF, or remapping the challenge-response mapping using a logically reconfigurable PUF (LR-PUF).

[0050] In step 442, the method includes receiving a request for a PUF response. The method then includes determining, in step 444, whether the current policy state is compatible with granting the request. Figure 4cIf, in step 446, the current policy state is incompatible with granting the request, then, in step 448, no PUF response is generated. If the current policy state is compatible with granting the request, then the method includes, in step 450, causing the PUF to generate a response based on its current configuration. As shown in 450a, causing the PUF to generate a response based on its current configuration may further include correcting errors in the PUF response, for example, by submitting the PUF response to an error correction module. Correcting errors in the PUF response may include extracting helper data from a first response generated to the challenge and storing it in, for example, a memory of the device, and may include using the helper data to perform error correction on subsequent responses generated to the challenge. The helper data may include one or more error correction codes. If a PUF response is generated, then, in step 452, the method includes incrementing a count of the number of times the PUF has generated a response under the current policy state. In step 454, the method includes determining whether a count threshold has been reached or exceeded. If the threshold has not been reached or exceeded, then, in step 456, the management module maintains the current policy state. The method may then include returning to step 442 if a further request for a PUF response is received, or returning to step 410 if a further measurement is received.

[0051] If the incremented count has reached or exceeded the count threshold for the current policy state, the method includes exiting the current policy state in step 460. The method may then include entering at least one of: a different policy state; a measurement path through which the different policy state can be reached; or a fallback path defining at least one fallback state.

[0052] Methods 300 and 400 can be implemented via a computer program stored on a device, and the present disclosure provides a computer program product comprising a computer-readable medium having computer-readable code embodied therein, the computer-readable code being configured such that, when executed by a suitable computer or processor, the computer or processor performs the method according to any example described herein.

[0053] Different implementations of security components according to the present disclosure are now discussed.

[0054] In one example, the security component can be implemented on a device with configurable units that receive a configuration after power is applied but before the device boots. Examples of such components include processors, memory, programmable logic, etc. In another example, the security component can be implemented in an application-specific integrated circuit (ASIC), where the behavior of the hardware can be configured via memory and registers.

[0055] Figure 5An example implementation of a security component 502 for a device 500 is shown. The device 500 on which the security component is installed includes a processor 504 and a memory 506, on which one or more computer programs 508 may be stored. According to various examples of the present disclosure, items of "helper data" 207 (including, for example, error correction codes) may also be stored in the memory 206. In addition, the device 500 may include one or more telecommunication interfaces for wired or wireless communication. Consistent with the security components 102, 202, the security component 502 includes a PUF 550 of the electronic measurement type that relies on implicit randomness and has multiple sub-functions. The security component 502 also includes a management module 510. Figure 5 Also shown is a policy A to be implemented by the management module 510 , which defines how different measurements should activate, reconfigure or disable the PUF 550 . Figure 5 Also shown is a rule interpreter B that interprets the policy and generates configuration information (eg, code or bitstream) for the rule module and control module of the management module 510 .

[0056] The management module 510 includes:

[0057] -Public key Pub_policy 522

[0058] - an asymmetric cryptographic module (labeled as authentication module 518) that verifies signatures on bitstreams or other configuration information for the rule and control modules

[0059] - A plurality of measurement registers 512 for writing boot measurements

[0060] - A rules module 514 for evaluating incoming measurements with respect to the policy to be implemented

[0061] - A control module that determines the behavior of the PUF 550

[0062] - Error correction module 519, which is used to correct errors generated by PUF 550

[0063] PUF 550 can be of any subtype that uses implicit or explicit randomness. Thus, PUF 550 can be implemented using electronic circuitry and can use unpredictable manufacturing variations as a source of randomness. PUF 550 can also be implemented using explicit randomness. In this type of PUF, challenges and responses can be presented using, for example, light, radio frequency, or magnetism. In these cases, challenges and responses can be converted to and from electrical signals when interacting with PUF 550.

[0064] In the example of security component 502 formed from configurable logic units, rule module 514 and control module 516 can be implemented in configurable logic. PUF 550 can be implemented in reconfigurable logic or can be a hard logic block. Cryptographic module 518 can be implemented in hard logic blocks, reconfigurable logic, or software. Rule interpreter A is an external component and can be implemented in external software or hardware.

[0065] The input and activation signals of PUF 550 are connected to management module 510, or more specifically, to rule module 514. Management module 510 handles all requests from clients to read PUF responses. If PUF 550 is a challenge-response type, the client is not allowed to select the challenge; this capability is limited to control module 516.

[0066] A policy consists of one or more paths of measurement values ​​leading to a state. A path in this context is one or more measurements that must be provided in the correct order and exactly match the values ​​in the policy. Along a path, there is at least one state. A state corresponds to a predefined configuration of the PUF 550 and to receiving a request to generate a PUF response. The policy can have constraints for each state, which define how many responses can be generated in each state. Each path can have additional states after the initial state. These states are called sub-states and can only be reached by first entering the initial state. The policy also defines one or more fallback paths, which describe what should happen if the received measurement does not match any path in the policy. A fallback path can specify that the PUF should generate a specific response or should be shut down.

[0067] Figure 6An example policy 600 is shown. State A1 is the initial state for the first policy path (Path 1), reached by measurements M1 and M2. State A1 generates at most one response before moving to substate A2. Once substate A2 is entered, subsequent generation will output a PUF response that differs from the PUF response output in state A1. Because substate A2 is only reachable by first accessing first-level state A1, the response generated in substate A2 can be considered a derivative of the response in state A1. State B is the initial state for the second policy path (Path 2), reached by measurements M3 and M4. Once entered, there is no upper limit on the number of responses the PUF can generate in state B. If the received measurement does not match a valid next step in the path, the policy's fallback path is entered, causing the PUF to enter a disabled state. If the received measurement is the first measurement received, the valid next step includes any first step on the policy path, i.e., measurement M1 or M3. If measurement M1 has already been received, the only valid next step is measurement M2 on path 1. If measurement M3 has been received, the only valid next step is measurement M4 on path 2 .

[0068] Reference again Figure 5 Once policy A is submitted, rule interpreter B parses the policy and converts it into register transfer level (RTL). RTL is used to create a bitstream or other configuration information that implements the rules in the policy. This bitstream is used to program the rule module 514. Once rule interpreter B has generated the bitstream, it uses its knowledge of the rule module 514 and the PUF 550 to generate configuration information for the control module. The control module is connected to both the rule module 514 and the PUF 550 and has a separate connection to the set of all PUF sub-functions, enabling the control module to disable specific sub-functions, change the challenge, or reconfigure the PUF.

[0069] The management module stores the public key Pub_policy 522 in OTP memory or ROM memory. The public key does not need to be secret, but storing it in OTP / ROM memory ensures integrity, meaning that once the key is provided, it cannot be altered. The corresponding private key K_policy can be used to sign configuration information for the rule module 514 and the control module 516. Depending on the specific use case, Pub_policy can be programmed during manufacturing and thus owned by the manufacturer, or programmed and owned by the hardware owner.

[0070] The control module and rule module bitstreams or other configuration information are provided via an external interface. The signature of the information is checked using Pub_policy 522 and cryptographic module 518. Updates to the control module 516 and / or rule module 514 should be performed before receiving measurements. The rule module 514 and control module 516 should not be reprogrammed during device operation. It will be understood that the security of the secure component does not rely on any component in the management module or on the PUF being secret. However, all parts of the management module and PUF should be integrity protected. As in the case of a Trusted Platform Module (TPM), the measurements should be written by a trusted boot process.

[0071] Figure 7 PUF 550, control module 516, measurement register 512, and rule module 514 are shown. PUF 550 includes multiple sub-functions 552. One-way function 554 is configured to provide a one-way transformation of the PUF response. Rule module 514 has been configured with rules that define two policy paths (path 1 leading to state A and path 2 leading to state B). Figure 7 In the state PUF 550 is not activated, the measurement has not yet been written to the measurement register 512 and the management module has not yet entered the state PUF 550 is not activated.

[0072] During bootup, device 500 writes measurements to measurement register 512. After each write, rule module 514 evaluates the measurement. If the first measurement matches the policy path, rule module 514 moves to the next step along the corresponding path as directed by the policy. If the next step is another measurement, rule module 514 waits for another write to measurement register 512. If the next step is a state, rule module 514 instructs control module 516 to set up PUF 550 using the configuration associated with that state.

[0073] Figure 8 shows that after receiving multiple measurements Figure 7 PUF 550, control module 516, measurement register 512, and rule module 514. Rule module 514 has matched all incoming measurements to path 1. Therefore, the rule module has entered state A and has instructed the control module to set up the PUF in a configuration corresponding to state A. This state uses sub-functions (F1, F3 ... Fx-3, Fx-1) to generate n bits. Figure 7 and 8 The multiplexer (MUX) shown shows the possibility of using multiple different sub-functions to generate 1 bit. These bits are provided to the one-way function 554, which outputs the one-way transformed output. It will be understood that Figure 8The PUF sub-function connections and the use of multiplexers in FIG. 1 and the connections shown between the control module and the PUF are illustrative configuration examples and may be designed differently in actual applications.

[0074] Each state has a corresponding state register. Once a state is determined to be unreachable, the rules module 514 writes to the register and makes it read-only. If the rules module 514 attempts to enter a state where the register has been written (for example due to a hardware error or hardware tampering), the rules module enters the fallback path. This adds an extra layer of security, allowing the PUF 550 to be used by any user of the device without the risk of leaking any responses in the inactive state. A state is unreachable if it cannot be effectively reached via any policy path. For example, refer to Figure 6 With the strategy shown, once measurement M1 has been received, path 1 is occupied and can no longer effectively reach state B. Thus, after receiving the first measurement matching M1, state B is unreachable.

[0075] Each state in the policy corresponds to a state setting, which includes at least one of: a combination of sub-functions in PUF 550, a challenge-response mapping for PUF 550, and / or a specific configuration of sub-functions in PUF 550. A state setting is selected by rule module 514 and activated by control module 512. Each state setting is unique.

[0076] The PUF response is passed through a one-way function that removes any correlation between different combinations of sub-functions. Figure 7 and 8 An example is shown using a unique combination of state setting and one-way functions.

[0077] When device 500 requests to generate a PUF response, rules module 514 evaluates whether it is in a state that allows the request. If the request is allowed, rules module 514 instructs control module 516 to activate the PUF and generate a response. Rules module 514 also increments its internal counter, which indicates the number of responses generated in the current state. If the policy places a limit on the number of responses generated in the current state, rules module 514 will exit its current state once the maximum number of responses is reached. If a sub-state exists, the management module will immediately enter the new state after generating the response, thereby instructing control module 516 to reprogram PUF 550.

[0078] Each policy path can end in one of two ways:

[0079] - The last state of the path has no restrictions and the PUF configuration becomes static until reboot, returning a PUF response for that state on any subsequent request (e.g. Figure 6 Path 2).

[0080] - The last state of the path has a restriction (in Figure 6 Once this limit is reached, the rule module enters the fallback path. The fallback state can be associated with shutting down the PUF or entering a new state, and thus the PUF can be disabled or its configuration rendered static until rebooted.

[0081] Some example implementations of the secure element may be sensitive to errors in the PUF response (e.g., caused by temperature variations), and some implementations may include an error correction module 519. The error correction module 519 may be configured to generate helper data (e.g., an error correction code) during the enrollment phase, or to take helper data and use it to correct any errors during the challenge phase.

[0082] Figure 11 Similar to Figure 8 , shows that after receiving multiple measurements Figure 7 PUF 550 , control module 516 , measurement register 512 and rule module 514 . Figure 11 Also shown is an error correction module 519. The error correction module 519 takes the PUF response as input and outputs a corrected response to the one-way function 554. In addition to the PUF input, the error correction module 519 takes two additional inputs: helper data 507 and an enrollment mode signal 509. If the enrollment mode signal is activated, the error correction module 519 extracts and outputs helper data (e.g., an error correction code), which can be stored by the module generating the PUF response or by a dedicated helper data component. When the enrollment mode signal is activated, no error correction is performed. If the enrollment mode signal is deactivated, the helper data 507 is input to the error correction module 519 and used to correct errors in the PUF sub-function response.

[0083] The error correction module may include one or more error correction functions. The helper data may include one or more types of error correction codes, such as BCH codes or Reed-Muller codes. The error correction module may also or alternatively include a bit selection function in which unreliable bits in the PUF response are removed. The bit selection function may operate based on knowledge of the characteristics of a particular PUF and is therefore not specific to a particular challenge, like the extracted helper data (e.g., error correction code).

[0084] The above discussion of the implementation of the security component is presented in the context of a security component implemented in a configurable logic block. It will be understood that in the example where the security component is implemented in an ASIC, all of the functions described will operate substantially as described on the ASIC, with the following exceptions:

[0085] • Management module components are implemented as hard logic blocks.

[0086] • Because the rule module and the control module are implemented in hard logic blocks, the bitstream is not suitable for setting these components. Instead, the rule interpreter generates memory / register configurations, which are signed and used to set these components.

[0087] • Limited possibilities on how policies can be configured. Policies can only change registers and memory, which provides less flexibility in configuring PUF behavior.

[0088] Various example process flows according to different implementations of the present disclosure are now described.

[0089] Figure 9 The process flow before the device boots is shown.

[0090] On the outside of the device:

[0091] The process starts 902

[0092] • Policies are uploaded to the rule interpreter 904.

[0093] • The rule interpreter parses the policy 906 and creates the RTL corresponding to the policy. The RTL is compiled into a rule module bitstream 908.

[0094] • The rule interpreter uses the rule module and knowledge of the PUF to create the RTL for the control module 910. The RTL is compiled into the control module bitstream.

[0095] • The policy owner signs the bitstreams using K_policy 912 and provides them to the device 914.

[0096] On the device:

[0097] The cryptographic module uses Pub_Policy to check the signature of the bitstream 916.

[0098] The control module and rule module bitstreams are stored in access-protected on-chip memory 918

[0099] ·Equipment powered on 920

[0100] The bitstream is loaded into the programmable logic 922

[0101] Device Guide 924

[0102] Figure 10 The flowchart shows the process flow after the device is powered on in an example where the safety component is implemented as a configurable unit.

[0103] The process starts 1002

[0104] Management is loaded into the programmable logic 1004

[0105] Equipment provides measurement 1006

[0106] The received measurements are added to the measurement set 1008

[0107] Check if the received measurement complies with status 1010

[0108] If yes, then management enters state 1012

[0109] If no, then enter fallback state or power off 1022, if the measurement set is full 1024, then end, if the measurement set is not full 1024, then wait for additional measurements 1026

[0110] After entering state 1012, the PUF is powered on 1014

[0111] PUF generates response 1016

[0112] Maximum number of responses generated? 1018

[0113] If no, generate a new response 1016

[0114] If yes, are there any sub-states? 1020

[0115] If yes, enter substate

[0116] If no, then enter fallback state or power off 1022, if the measurement set is full 1024, then end, if the measurement set is not full 1024, then wait for additional measurements 1026

[0117] Figure 12 Another example of the process flow after the device is powered on in an example in which the safety component is implemented as a configurable unit is shown.

[0118] The process starts 1202

[0119] Management is loaded into the programmable logic 1204

[0120] · Equipment provides measurement 1206

[0121] The received measurements are added to the measurement set 1208

[0122] Check if the received measurement complies with status 1210

[0123] If yes, then management enters state 1212

[0124] If not, then enter fallback state or power off 1222, if the measurement set is full 1224, then end, if the measurement set is not full 1224, then wait for additional measurements 1226

[0125] After entering state 1212, the PUF is powered on 1214

[0126] PUF generates response 1216

[0127] Is the error correction module in registration mode? 1228

[0128] If yes, the error correction module outputs help data 1230

[0129] If no, the error correction module takes the helper data as input and performs error correction on the PUF response 1232

[0130] Has the maximum number of responses been generated? 1218

[0131] If no, generate a new response 1216

[0132] If yes, are there any sub-states? 1220

[0133] If yes, enter substate

[0134] If not, then enter fallback state or power off 1222, if the measurement set is full 1224, then end, if the measurement set is not full 1224, then wait for additional measurements 1226

[0135] The following use case scenario illustrates the use of Figure 6 The strategy shown above is used to apply the process flow

[0136] Scenario 1

[0137] Power on the device.

[0138] Load / configure rule modules and control modules.

[0139] The device begins the boot sequence.

[0140] • When the first boot component has been loaded, the hash function of the component is performed and the result M3 is written to the measurement register.

[0141] M3 is compared to the allowed values ​​in the first step of each path. Path 2 is found to match M3. This disables Path 1, and all registers in the unreachable state are written and are then write-protected.

[0142] When the second boot component has been loaded, the hash function of the component is performed and the result M4 is written to the measurement register.

[0143] Compare M4 to the allowed values ​​along the current path. M4 matches the second value of path 2.

[0144] The device sends a request for a PUF response.

[0145] • The rules module receives the request and instructs the control module to generate a PUF response, which can be read by the device.

[0146] This is the final state for this path, and there is no limit on the number of responses. The PUF will continue to generate State B responses until the device is rebooted.

[0147] Scenario 2

[0148] Power on the device.

[0149] Load / configure rule modules and control modules.

[0150] The device begins the boot sequence.

[0151] • When the first boot component has been loaded, the hash function of the component is performed and the result M1 is written to the measurement register.

[0152] M1 is compared to the allowed values ​​in the first step of each path. Path 1 is found to match M1. This disables Path 2, and all registers in the unreachable state are written and are then write-protected.

[0153] • When the second boot component has been loaded, the hash function of the component is performed and the result M2 is written to the measurement register.

[0154] Compare the measurement to the allowed values ​​along the current path. M2 matches the second value of path 1.

[0155] • The rules module enters state A1 and instructs the control module to configure the PUF to be in the state corresponding to A1.

[0156] • The control module configures the PUF as defined for state A1 and waits for a request from the device.

[0157] The device sends a request for a PUF response.

[0158] • The rules module receives the request and instructs the control module to generate a PUF response, which can be read by the device.

[0159] • The rules module leaves state A1 because only one response can be generated in this state. The rules module enters state A2 and instructs the control module to configure the PUF to be in the state corresponding to A2.

[0160] The device sends an additional request for the PUF response.

[0161] • The rules module receives the request and instructs the control module to generate a PUF response, which can be read by the device.

[0162] When both requests have been serviced, the rules module leaves state A2. There are no further states along this path. The PUF is powered down and will not provide further responses until the device is rebooted.

[0163] Scenario 3

[0164] Power on the device.

[0165] Load / configure rule modules and control modules.

[0166] The device begins the boot sequence.

[0167] • When the first boot component has been loaded, the hash function of the component is performed and the result M5 is written to the measurement register.

[0168] The measurement is compared to the allowed values ​​in the first step of each path. No match is found, so the fallback state is entered, disabling paths 1 and 2. All registers are written and then write-protected, so only the fallback state is allowed.

[0169] The fallback state is defined as “disable PUF.” The management module sends an instruction to the control module to disable PUF.

[0170] The control module has not yet activated the PUF because it has not entered any state and no action is required.

[0171] Thus, aspects of the present disclosure provide a security component including a PUF that is effectively "aware" of the environment in which it operates. That is, the security component is operable to modify its behavior based on the components and policies bootstrapped on its device. Aspects of the present disclosure enable the use of a single PUF to deterministically generate different responses. This provides the possibility of generating cryptographic keys that are unique not only to the device but also to the environment in which the device operates. In this way, keys that should, for example, only be available to the manufacturer can be "hidden" from other users without having to protect the PUF from access. Furthermore, when accessing the PUF, users with different permissions can be allowed access to different device-unique keys.

[0172] Given a device that can boot in different modes (i.e., loading different components, such as software and bitstreams, during boot), measurements from the boot sequence can be used to determine the device's settings. Examples of the present disclosure match such measurements with policy to select a configuration for the PUF. This ensures that the device can only generate specific PUF responses given specific measurements; loading unauthorized components will cause the PUF to be deactivated (if specified by policy) and no responses will be disclosed.

[0173] If the policy defines multiple allowed boot component combinations, each combination (including the order in which the components are booted) can trigger the PUF to operate in a different manner. It is also possible to establish a policy that causes different measurement combinations to produce the same PUF response. For example, multiple different boot component combinations can produce the same PUF configuration, while a specific component combination indicating a privileged boot mode generates a different PUF configuration.

[0174] Each state defined by the policy can be restricted in the number of times it can be used to generate a response, so that, for example, the policy can be configured to ensure that a particular response can only be used for a single generation, after which it cannot be accessed until the device is rebooted. This provides the possibility for a first boot component to receive a PUF response that cannot be recreated for any subsequent component. When leaving a particular first state, the policy can be configured to cause entry into one or more sub-states that are only reachable by first entering the first state. This enables the creation of "sub-responses" that can only be generated after a response belonging to the first state has been generated by a previous PUF configuration. This can be advantageous if the response is used for cryptographic purposes because it does not require an external key derivation function (KDF).

[0175] The methods of the present disclosure may be implemented in hardware or as a software module running on one or more processors. These methods may also be performed according to the instructions of a computer program, and the present disclosure further provides a computer-readable medium having a program for performing any method described herein stored thereon. The computer program embodying the present disclosure may be stored on a computer-readable medium, or it may, for example, be in the form of a signal (e.g., a downloadable data signal provided from an internet website), or it may be in any other form.

[0176] It should be noted that the above examples illustrate rather than limit the present disclosure, and that those skilled in the art will be able to design many alternative embodiments without departing from the scope of the appended claims. The word "comprising" does not exclude the presence of elements or steps other than those listed in a claim, and "a" or "an" does not exclude a plurality, and a single processor or other unit may perform the functions of several units listed in a claim. Any reference signs in a claim should not be construed as limiting the scope of the claim.

Claims

1. A security component for a device, the security component comprising: Physical Unclonable Function (PUF), which has multiple sub-functions; as well as a management module configured to manage the PUF according to a policy; Wherein, the management module includes: a measurement module configured to receive, from a device boot process, at least one of a measurement of a component booted on the device or a measurement of a hardware state of the device, the component booted on the device or the hardware state of the device representing an environment of the device on which the PUF is installed; a rules module configured to compare the received measurement to at least one rule implementing the policy and enter a policy state based on the comparison; and A control module is configured to configure the PUF according to the policy state entered by the rule module.

2. The safety component according to claim 1, wherein: The rules module is configured to receive configuration information defining the at least one rule implementing the policy.

3. The safety component according to claim 2, wherein: The management module also includes: An authentication module is configured to authenticate the configuration information using security credentials.

4. The safety component according to claim 1, wherein: The policy implemented by the at least one rule comprises a state path, and wherein the state path comprises: at least one state corresponding to activating at least one sub-function of the PUF and accepting at least one request for generating a PUF response; and A measurement path, via which the at least one state can be reached, defines an ordered sequence of at least one measured value of a component that can be booted on the device or a hardware state of the device.

5. The safety component according to claim 4, wherein: The strategy implemented by the at least one rule further comprises a fallback path defining at least one fallback state; and wherein the rules module is further configured to enter the fallback path if the comparison indicates that the received measurement is incompatible with a valid next step along the measurement path in the strategy.

6. The safety component according to claim 1, wherein: The rule module is further configured to: Based on the comparison, identifying a policy state that can no longer be validly entered; and The identified policy state is caused to become unreachable for the rule module.

7. The safety assembly according to claim 6, wherein: The management module further includes a plurality of state storage modules, and wherein the rule module is configured to cause the identified policy state to become unreachable by the rule module by: writing to the state storage module corresponding to the identified policy state; and Any further data writing to the state storage module for the identified policy state is blocked.

8. The safety assembly according to claim 1, wherein: The management module is configured to: receive a request for a PUF response; and wherein the rule module is further configured to: determining whether the current policy state is compatible with granting the request; and If the current policy state is compatible with granting the request, the control module is instructed to cause the PUF to generate a response based on a current configuration of the PUF.

9. The safety assembly according to claim 8, wherein: The rule module is further configured to: after instructing the control module to cause the PUF to generate a response based on the current configuration of the PUF, A count of the number of times a response has been generated by the PUF using the rules module in the current policy state is incremented.

10. The safety assembly according to claim 9, wherein: The rule module is further configured to: If the incremented count exceeds a count threshold for the current policy state, the current policy state is exited.

11. The safety assembly according to claim 9, wherein: The rule module is further configured to, if the incremented count exceeds a count threshold for the current policy state, proceed to at least one of the following: Different strategic states; a measurement path by which different policy states can be reached, the measurement path defining an ordered sequence of at least one measurement value of: a component capable of being booted on the device, or a hardware state of the device; or Define a fallback path for at least one fallback state.

12. The safety assembly according to claim 1, wherein: The management module is implemented using at least one of the following: Reconfigurable control logic; Hard logic blocks; At least one software module.

13. A method for operating a security component for a device, the security component comprising: Physical Unclonable Function (PUF), which has multiple sub-functions; and a management module configured to manage the PUF according to a policy, the method comprising: receiving, from a device boot process, at least one of a measurement of a component booted on the device or a measurement of a hardware state of the device, the component booted on the device or the hardware state of the device representing an environment of the device on which the PUF is installed; comparing the received measurement to at least one rule implementing the policy; entering a policy state based on the comparison; as well as The PUF is configured according to the policy state entered.

14. The method according to claim 13, further comprising: Configuration information defining the at least one rule implementing the policy is received.

15. The method according to claim 14, further comprising: The configuration information is authenticated using security credentials.

16. The method according to claim 13, wherein: The policy implemented by the at least one rule comprises a state path, and wherein the state path comprises: at least one state corresponding to activating at least one sub-function of the PUF and accepting at least one request for generating a PUF response; and A measurement path, via which the at least one state can be reached, defines an ordered sequence of at least one measured value of a component that can be booted on the device or a hardware state of the device.

17. The method according to claim 16, wherein The strategy implemented by the at least one rule further comprises a fallback path defining at least one fallback state; and wherein the method further comprises entering the fallback path if the comparison indicates that the received measurement is incompatible with a valid next step along the measurement path in the strategy.

18. The method according to claim 13, further comprising: Based on the comparison, identifying a policy state that can no longer be validly entered; as well as Causes the identified policy state to become unreachable.

19. The method according to claim 18, wherein The management module includes a plurality of state storage modules, and wherein causing the identified policy state to become unreachable includes: writing to the state storage module corresponding to the identified policy state; and Any further data writing to the state storage module for the identified policy state is blocked.

20. The method of claim 13, further comprising: receiving a request for a PUF response; determining whether the current policy state is compatible with granting the request; as well as If the current policy state is compatible with granting the request, causing the PUF to generate a response based on a current configuration of the PUF.

21. The method according to claim 20, further comprising: After causing the PUF to generate a response based on the current configuration of the PUF, Increment a count of the number of times a response has been generated by the PUF in the current policy state.

22. The method according to claim 21, further comprising: If the incremented count exceeds a count threshold for the current policy state, the current policy state is exited.

23. The method of claim 21, further comprising: If the incremented count exceeds the count threshold for the current policy state, proceed to at least one of the following: Different strategic states; a measurement path by which different policy states can be reached, the measurement path defining an ordered sequence of at least one measurement value of: a component capable of being booted on the device, or a hardware state of the device; or Define a fallback path for at least one fallback state.

24. A computer program product comprising a computer readable medium having computer readable code embodied therein, the computer readable code being configured such that, when executed by a suitable computer or processor, the computer or processor is caused to perform the method according to any one of claims 13 to 23.

Images