Secure computing device, secure computing method, verifier, and device verification method

Abstract

A secure computing device, a secure computing method, a verifier and a device verification method, the device comprising a network interface, a memory and a processor. The network interface is configured to communicate with the verifier via a communication network. The memory is configured to store multiple layers of variable program code, wherein each layer can be identified by a respective measurement value. The processor is configured to generate a random number associated only with the boot cycle in a given boot cycle, receive a challenge from the verifier to authenticate a given layer, calculate an authentication key based on (i) a unique device key securely stored in the device, (ii) a measurement value of the given layer measured by another layer, and (iii) a random number generated for the given boot cycle, calculate a response to the challenge by signing the challenge using the authentication key, and transmit the response to the verifier to authenticate the given layer, thereby reducing the risk of zero-day attacks.

Description

Technical Field

[0001] Embodiments described herein relate generally to secure computing, and more particularly to attestation of devices running layered software. Background Art

[0002] In various secure computing environments, computing devices must prove or attest their status and identity to an entity called a "verifier". Authentication methods for computing devices are known in the art to which the present invention belongs. For example, the Trusted Computing Group (TCP) defines the Device Identifier Composition Engine (DICE) and develops a device authentication architecture based on DICE. The device authentication architecture based on DICE can use symmetric key or asymmetric key encryption. For specifications based on DICE, see, for example, certain references cited in this specification.

[0003] For the hardware requirements of DICE, please refer to Hardware Requirements for a DeviceIdentifier Composition Engine, Family “2.0” Level 00, Revision 78, March 22, 2018.

[0004] For the authentication architecture based on DICE and using asymmetric key encryption, please refer to documents such as Implicit Identity Based Device Attestation, Version 1.0, Revision 0.93 on March 5, 2018.

[0005] For the authentication architecture based on DICE and using symmetric key encryption, please refer to documents such as Symmetric Identity Based Device Attestation, Version 1.0, Revision 0.95, January 7, 2020.

[0006] For the DICE layered architecture, please refer to the DICE Layering Architecture, Version 1.0, Revision 0.19 on March 19, 2020.

[0007] For the general principles of DICE certificates, please refer to documents such as DICE Certificate Profiles, Version 1.0, Revision 0.01 on March 10, 2020. Summary of the invention

[0008] A device includes a network interface, a memory, and a processor. The network interface is configured to communicate with a verifier via a communication network. The memory is configured to store multiple layers of mutable program code, wherein each layer is identifiable by a respective measurement value. The processor is configured to generate a random number (nonce) associated only with a boot cycle during a power-on cycle, receive a challenge from the verifier to authenticate a given layer of mutable program code, derive an attestation key to calculate an attestation from (i) a unique device secret (UDS) securely stored in the device, (ii) a measurement value of the given layer measured by another layer, and (iii) a random number (nonce) generated for the given boot cycle, calculate a response to the challenge by signing the challenge with the attestation key, and transmit the response to the verifier to verify the given layer.

[0009] In some embodiments, the processor is configured to calculate an authentication key based on a random number, so that the authentication key used by the processor for authentication before a given boot cycle becomes invalid and cannot be authenticated in the given boot cycle. In other embodiments, the processor is configured to set the authentication key to be different from the authentication key used by the processor for authentication before the given boot cycle, even if the given layer and the layers of variable program code executed before the given layer remain intact in the given boot cycle. In other embodiments, the authentication key includes a symmetric key determined based on the random number, and the processor is configured to calculate a response by signing at least the challenge using the symmetric key, and transmit the response and the random number to the verifier.

[0010] In one embodiment, the authentication key comprises an asymmetric key determined based on a random number, and the processor is configured to compute a response by signing the challenge using a private key of the asymmetric key, and transmit the response to the verifier without transmitting the random number. In another embodiment, the processor is configured to generate individual asymmetric keys for each layer, including the authentication key, each asymmetric key comprising an individual private key and a certified public key, to generate a chain of certificates, wherein a certificate in a given layer certifies a public key generated in a subsequent layer, and is signed using the private key generated in the given layer, and the chain of certificates is transmitted to the verifier for verification using the certified public key of the authentication key. In yet another embodiment, the chain of certificates comprises a certificate independently generated from a random number, which can prove that the device was manufactured by a specific manufacturer.

[0011] In some embodiments, the processor is configured to generate a random number in a trusted layer that is executed prior to the given layer, calculate a key based on the random number in the trusted layer, and calculate an authentication key based on the key. In other embodiments, the processor is configured to execute multiple layers of program code in a predefined order and proceed from a selected layer to a subsequent layer according to the predefined order only after the selected layer has been successfully authenticated by the authenticator. In other embodiments, the processor is configured to calculate an authentication key based on the random number to mitigate the harm of a zero-day attack.

[0012] The present specification also provides a method according to an embodiment described herein, comprising storing multiple layers of variable program code in a memory of a device that communicates with a verifier via a communication network, wherein each layer can be identified by a separate measurement value. For a given power-on cycle, a random number associated only with the power-on cycle is generated. A given layer of variable program code receives an authentication challenge from the verifier. An authentication key is derived to calculate authentication from (i) a unique device key (UDS) securely stored in the device, (ii) a measurement value of the given layer measured by another layer, and (iii) a random number generated for the given power-on cycle. A response to the challenge is calculated by signing the challenge with the authentication key. The response is transmitted to the verifier to verify the given layer.

[0013] The specification also provides a verifier according to an embodiment described herein, including a network interface and a processor. The network interface is configured to communicate with a device via a communication network, wherein the device includes multiple layers of variable program code and generates a random number associated only with a given boot cycle. The processor is configured to send a challenge to the device to verify a given layer of variable program code, receive a response message generated by the device in response to the challenge, wherein the response message is generated based on a random code associated with the given boot cycle, and use the response message to verify the given layer of variable program code.

[0014] In some embodiments, the response message includes at least a challenge signed by an authentication key determined based on a random number, and the processor is configured to securely store device information in a memory of the verifier before transmitting the challenge, wherein the device information combined with the random number is sufficient to recover the authentication key, receive the random number from the device, recover the authentication key using the device information and the random number, and verify a given layer of variable program code using the recovered authentication key. In other embodiments, the response message includes (i) a digital signature of the challenge signed using a private key of an asymmetric authentication key, and (ii) a certificate of a public key associated with the given layer, and the processor is configured to verify the public key verified in the certificate, wherein the certificate is signed using a private key that matches the public key, and then verify the digital signature using the verified public key.

[0015] The specification also provides a method for verifying a device according to an embodiment described herein, including in a server communicating with a device via a communication network, wherein the device includes multiple layers of variable program code, and generates a random number associated only with a given boot cycle, and sends a challenge to the device to verify the given layer of variable program code. Response information generated by the device in response to the challenge is received from the device, wherein the response information is generated based on the random number associated with the given boot cycle. Using the above response information, the above given layer of variable program code is verified.

[0016] The above and other embodiments can be more fully understood after reading the following detailed description together with the accompanying drawings. Among them, the drawings are: BRIEF DESCRIPTION OF THE DRAWINGS

[0017] Figure 1 is a block diagram illustrating a computing system for supporting security device authentication according to an embodiment described in this specification;

[0018] Figure 2 is a diagram illustrating a device layered architecture for symmetric key authentication according to an embodiment described in this specification;

[0019] Figure 3 is a flow chart illustrating a method for device authentication and verification using symmetric key encryption according to an embodiment described in this specification;

[0020] Figure 4 is a diagram illustrating a device layered architecture for asymmetric key authentication according to an embodiment described in this specification;

[0021] Figure 5 is a flow chart illustrating a method for device authentication and verification using asymmetric key encryption according to an embodiment described in this specification.

[0022]

Explanation of symbols

[0023] 20: Operational System

[0024] 24, 100, 300: Computing devices (such as the Internet of Things)

[0025] 28, 102, 302: Management Server

[0026] 32: Communication Network

[0027] 40: Processor

[0028] 44: Memory

[0029] 48:ROM

[0030] 52:PCIe

[0031] 54: Network interface

[0032] 56: Authentication function

[0033] 58: Boot program code (DICE layer)

[0034] 60: Variable Software Layer

[0035] 62, 124, 324: Unique Device Key (UDS)

[0036] 66:CDI

[0037] 70: Cryptographic Engine

[0038] 72, 132, 160: Random number generator

[0039] 74: Random Number

[0040] 76:Host processor

[0041] 80: Memory

[0042] 84: Network Interface

[0043] 86, 104, 304: Validator

[0044] 88: Device database

[0045] 90: Policy

[0046] 106, 306: Key chain generation

[0047] 108, 308: Authentication

[0048] 112:DICE

[0049] 114, 314:L 0

[0050] 116, 318:L n

[0051] 120, 320: One-way function

[0052] 128A, 328A:M 0

[0053] 128B, 328B:M 1

[0054] 136A, 136B: Firmware Security Descriptor

[0055] 140, 340, 344: Key derivation function

[0056] 144:SK n

[0057] 148, 354: Signature

[0058] 200, 400: Device startup

[0059] 204: Generate a random number N associated with the current boot cycle a , and transmit N a To Validator

[0060] 212: According to N a Generate symmetric authentication key SK n

[0061] 216: Receive challenge C from verifier to authenticate L n

[0062] 220: By using SK n Signature C calculates response R and sends R to the verifier

[0063] 228, 428: Restart?

[0064] 250: Store the device information of each device in the database to reproduce the same authentication key of the device

[0065] Device information includes: unique device key, hierarchical structure, and measurement values ​​of each layer

[0066] 254: Receive N from the device a

[0067] 258: Send challenge C to device to authenticate L n layer

[0068] 262: Receive response R from device

[0069] 266: Based on the stored device information and N a , remake SK n A copy of SK n '

[0070] 270: Use R and SK with recovery n ', verify Ln and previous layers

[0071] 310: Credentials

[0072] 316:L 1

[0073] 328C:M 2

[0074] 342:ECA 0 、ECA 1

[0075] 350: Manufacturer Certificate Authority

[0076] 404: Generate a random number N associated with the current boot cycle a

[0077] 408: Generate asymmetric keys and corresponding public key certificates at each layer

[0078] 412: Receive challenge N from validator v

[0079] 420: By using AK n Private key PR n Signature N v , calculate the response digital signature DS(AK n According to N a Decide)

[0080] 424: Send digital signature DS and certificate to the verifier

[0081] 458:Transmission Challenge N v To the device to verify L n layer

[0082] 462: Receive digital signature DS and certificate from device

[0083] 466: Verify credentials, including PK verification n Credentials

[0084] 470:Use verified PK n Verify DS to verify L n And previous layers DETAILED DESCRIPTION

[0085] [Overview]

[0086] The embodiments described in this specification provide improved device authentication methods and systems, including modification of authentication keys after a power-on event.

[0087] In the cloud or other computing environments, such as the Internet of Things (IoT) network, computing devices run software that includes multiple layers of program code. The various layers of program code may sometimes be modified (for example, to fix a bug) or a newer version may be downloaded. Because mutable program code is vulnerable to hacker attacks, its security requirements may require verification of the identity of the computing device and the software state.

[0088] In some embodiments, the computing device (e.g., a given code layer) is authenticated by an external authenticator using a challenge-response protocol. The authenticator sends a challenge to the device, and the device sends an authentication response back to the authenticator to verify the identity and integrity of the computing device. The device typically computes the response by applying an appropriate cryptographic operation to the challenge, such as generating a digital signature using a secret authentication key.

[0089] In the following description and claims, the term "attestation" refers to the action performed by a device that is requested to perform attestation to attest the device; and the term "verification" refers to the action performed by an external verifier to trigger the device to perform attestation and verify the status of the device. An architecture that includes both a verifier and a device that responds to the verifier's attestation request is referred to as an "attestation scheme" in this specification.

[0090] In some embodiments, the authentication key is derived from a secret key generated by the code layer, based on the identity of the device and the measurement of the code layer. The measurement of a given code layer may include the result of applying a secure hash function to the underlying code or firmware. If an unauthorized person modifies one or more code layers without access to the corresponding authentication key, the authentication will fail.

[0091] In certain types of attacks, a device key may be leaked and used by an unauthorized attacker to authenticate and impersonate the device. Upon detecting a key leak, the device owner may download an updated software or firmware version to the device to address the source of the leak. However, fixing the leak and updating a large number of devices in the field may take a relatively long time, during which time an attacker may be able to do a lot of damage.

[0092] It should be noted that the attack may be successful because after the device is rebooted and before the update, the device will generate the same authentication key, which is known to the attacker. This is an example of an attack sometimes called a "zero-day attack".

[0093] In the disclosed embodiment, the above device generates a different authentication key after each boot event. This will cause the authentication key value before the reboot to become invalid and unable to authenticate after the reboot. This mechanism can enhance the security of the authentication-verification architecture to prevent various attacks, including zero-day attacks.

[0094] Consider a device including a network interface, a memory, and a processor. The network interface enables the device to communicate with an authenticator via a communications network. The memory stores multiple layers of variable program code, wherein each layer is identifiable by a respective measurement. The processor generates a random number associated only with a given boot cycle for a given boot cycle. The processor receives a challenge from the authenticator to authenticate a given layer of variable program code and computes an authentication key derived from (i) a unique device key (UDS) securely stored in the device, (ii) a measurement of the given layer measured by another layer, and (iii) a random number generated for the given boot cycle. The processor computes a response to the challenge by signing the challenge with the authentication key and transmits the response to the authenticator to authenticate the identity and integrity of the given layer. In the following description and claims, the phrase "deriving the authentication key from a given factor" means that if the factor is modified, the authentication key is also modified. However, the authentication key may be derived directly or indirectly from the factor.

[0095] In the disclosed embodiment, the processor generates a key chain along various layers, starting from a trusted hardware layer, which is called the Device Identification Combination Engine (DICE) layer. The DICE layer securely stores a unique device key (UDS) in accordance with the DICE standard referenced above. This UDS is the root of trust (RoT) of the trust chain that includes the DICE layer and other layers.

[0096] At power-up, the processor unconditionally executes the DICE layer, which measures the first variable layer. Based on the UDS and the measurements, the DICE layer generates a key for the first variable layer, called a Compound Device Identification (CDI). In a similar manner, each variable layer generates a key for the next layer based on the key generated by the previous layer and the measurements of the next layer. The processor derives the authentication key for a given layer from the key generated by the previous layer.

[0097] In some embodiments, the processor calculates the authentication key based on the random number so that the authentication key used by the processor for authentication before a given boot cycle becomes invalid and cannot be authenticated in the given boot cycle. The processor sets the authentication key to be different from the authentication key used by the processor for authentication before the given boot cycle, even if the given layer and the layers of variable program code executed before the given layer remain intact in the given boot cycle.

[0098] In one embodiment, the authentication key comprises a symmetric key determined according to a random number, and the processor calculates a response by signing at least the challenge using the symmetric key, and transmits the response and the random number to the verifier.

[0099] In another embodiment, the authentication key comprises an asymmetric key pair determined based on a random number, and the processor computes a response by signing the challenge using the private key of the asymmetric key pair and transmits the response to the verifier without transmitting the random number. In this case, the processor generates individual asymmetric keys for each layer, including the authentication key, and each asymmetric key pair comprises an individual private key and a public key. The processor generates a chain of credentials, wherein a credential in a given layer authenticates a public key generated in a subsequent layer and is signed using the private key generated in the given layer. The processor transmits the chain of credentials to the verifier for verification using the authenticated public key of the authentication key.

[0100] In one embodiment, the certificate chain includes a certificate independently generated by a random number that proves that the device was manufactured by a specific manufacturer. This certificate can start the certificate chain and can be generated by an external certification authority.

[0101] In some embodiments, the processor generates a random number in a trust layer that is executed prior to the given layer (the layer being verified), calculates a key based on the random number in the trust layer, and calculates an authentication key based on the key.

[0102] The processor typically executes each layer of program code in a predefined order. In one embodiment, the processor executes each layer in the order given above and authenticates the last layer. In another embodiment, the processor advances from the selected layer to the subsequent layer according to the predefined order only after the selected layer has been successfully authenticated by the authenticator.

[0103] In the technology provided in this specification, an authentication architecture is described, in which a device generates a random number associated with a power-on cycle and indirectly calculates an authentication key based on the random number. In this architecture, the authentication key used in the previous power-on cycle becomes invalid and cannot be authenticated at the next power-on cycle. The authentication architecture provided in this specification allows the device to mitigate the damage of attacks (such as zero-day attacks). The authentication architecture disclosed in this specification is applicable to symmetric authentication keys and asymmetric authentication keys.

[0104] [System Description]

[0105] Figure 1 FIG. 2 is a block diagram illustrating a computing system 20 for supporting secure device authentication according to one embodiment described in this specification.

[0106] The computing system 20 includes a plurality of computing devices 24, which are controlled by a management server 28 via a communication network 32. The communication network 32 may include any suitable packet network, operating using any suitable communication protocol, such as Ethernet, or an Internet Protocol (IP) network, such as the Internet. The communication network 32 may include a local area network (LAN), a wide area network (WAN), a wireless network, or a combination of several packet networks.

[0107] The computing system 20 can be used to authenticate low-cost devices, such as Internet of Things (IoT) devices (24). In addition, other types of computing devices, such as servers, can also use the authentication and verification techniques provided in this specification.

[0108] The computing device 24 (also referred to as "device" for simplicity) includes a processor 40, which is coupled to a rewritable memory 44 and a read-only memory (ROM) 48 via a bus 52, such as a high-speed Peripheral Component Interconnect Express (PCIe) bus, or any other suitable bus. The computing device 24 accesses the communication network 32 via a network interface 54, such as a network interface controller (NIC).

[0109] The processor 40 typically runs one or more applications. These applications may interact with other devices or servers via the communication network 32, and such interactions may make the device vulnerable to security attacks. Among various tasks, the processor 40 runs an authentication function 56 to prove its status and identity, as described below. It should be noted that for clarity, the authentication function 56 is depicted in the figure as being executed by the processor. However, the program code of the authentication function is typically stored in the memory 44 (or any other suitable memory accessible to the processor, not shown).

[0110] ROM 48 stores boot code 58, which is unconditionally executed by processor 40 upon reset or power on. Memory 44 stores multiple software layers 60, which can be modified when necessary, such as to correct functional errors or address security vulnerabilities. Figure 1 In the example, the first three layers 60 are marked as L 0 ,L 1 and L 2 The boot code 58 is also referred to as the "DICE layer". This DICE layer is immutable and highly secure, and is therefore considered a trusted layer.

[0111] Each layer can securely exchange secret information with the next or previous layer, thus building a trust chain starting from the above DICE layer. 0 …L n The access of each layer to the UDS is blocked before the DICE layer passes the control signal to the 0th layer. i In passing the control signal to the next layer L i+1 Before, it will prevent the key S i Access to and other confidential information. Preventing access may involve blocking access or erasing L from memory. i It is implemented by means of secret information of the layer, etc.

[0112] In the following description, if a certain layer is mentioned to perform certain operations, it means that the processor 40 performs the task by executing the program code in the layer.

[0113] A boot process begins with the processor 40 executing the boot code 58, and then sequentially executing the software layers 60 until the underlying operating system and application programs begin to run. These sequentially executed software layers form a chain of trust, where each trusted layer provides keys to the next layer. A trusted software layer can be trusted to have certain properties. For example, a trusted layer can be trusted to hold keys generated by the previous trusted layer.

[0114] The computing device 24 includes a unique device key (UDS) 62 as a root of trust for authentication. In some embodiments, the UDS 62 is immutable and can be securely embedded in hardware. For example, the UDS can be implemented using a one time programmable (OTP) memory or a physical unclonable function (PUF). Alternatively, the UDF can also be burned into the ROM 48. Alternatively, any other suitable method of securely embedding the UDS 62 in hardware can also be used, such as using a combination of some or all of OTP, PUF and ROM.

[0115] The UDS is assumed to be accessible only by the DICE layer. At device boot, the DICE layer generates a key from the UDS 62, which is referred to in the TCG specification as a composite device identifier (CDI) 66. The DICE layer provides the CDI to the L 0 layer.

[0116] The computing device 24 includes a cryptographic engine 70 that supports various cryptographic operations, such as encryption, decryption, hashing, signature generation and verification, random number generation, etc. In some embodiments, the cryptographic engine 70 replaces the processor 40 to perform cryptographic calculations required for device authentication.

[0117] The cryptographic engine 70 includes a random number generator (RNG) 72, which generates a random or pseudo-random cryptographic nonce 74 for use by the processor 40 for verification. As described below, the cryptographic nonce 74 implicitly modifies the authentication key, making the authentication key value before the power-on event invalid and unable to be authenticated after the power-on event.

[0118] The cryptographic random number 74 includes a random or pseudo-random number and has sufficient bits to ensure that repeated random values ​​are rarely generated. In the disclosed authentication architecture, the cryptographic random number 74 is generated in association with a power-on cycle (eg, once per power-on cycle), as described below.

[0119] The management server 28 includes a host processor 76 and a memory 80. The management server 28 communicates with the computing device 24 via the communication network 32 using a network interface 84. In some embodiments, the memory 80 stores a database (DB) 88 of the computing device 24 under the control of the management server, as well as policies 90. The memory 80 may include, for example, a random access memory, a nonvolatile memory, or any other suitable storage device type. The management server 28 may communicate with the computing device 24 for various purposes, such as software provisioning, sending instructions to the computing device 24 to perform related tasks, and receiving reports from the devices. The management server 28 uses an authentication program 86 to authenticate the identity and status of the computing device 24; for simplicity, the authentication program 86 is also referred to as the "authenticator" in this specification. The authenticator (and the computing device 24) may implement a suitable challenge-response method, as described below.

[0120] Policy 90 indicates to host processor 76 the security policy for device 24. A given policy may specify a schedule for device authentication, which layers in each device require authentication, what actions to take if device authentication fails, approved firmware versions, and the like.

[0121] Figure 1 The configurations of the computing system 20, computing device 24, and management server 28 shown are only exemplary configurations and are depicted only to clearly illustrate the concepts. In other embodiments, any other suitable computing system, computing device, and management server may be used. Elements that are not necessary for understanding the disclosed technology are omitted in the figure for the sake of clarity.

[0122] In various embodiments, different components of the computing system 20 (e.g., computing device 24) may be implemented using any suitable hardware, such as one or more discrete components, one or more application specific integrated circuits (ASICs), and / or one or more field programmable gate arrays (FPGAs). Certain computer system components may be implemented using software, or using a combination of software and hardware components.

[0123] In some embodiments, processor 40 and host processor 76 each comprise a general purpose programmable processor that is programmed with software to perform the functions described herein. The software may be downloaded to the associated processor in electronic form over a network and / or stored in a non-transitory tangible medium such as a magnetic disk, optical disk, or electronic memory.

[0124] [Authentication architecture using symmetric key cryptography]

[0125] Figure 2 is a diagram illustrating a device layer architecture for symmetric key authentication according to one embodiment described in this specification.

[0126] exist Figure 2 In the example, the computing device 100 is authenticated using the management server 102 running the authenticator 104. The computing device 100, the management server 102 and the authenticator 104 may be used to implement Figure 1 The computing device 24, management server 28 and verification program 86.

[0127] Device 100 runs multiple code layers, which are referred to as "layers" for simplicity. The first layer is represented by "DICE layer" 112, which generally includes immutable code. The other layers that run mutable code are represented by L 0 …L n Indicates. Figure 2 For clarity, only L is shown. 0 Floor 114 and L n Layer 116. The DICE layer is the root of trust and is usually executed unconditionally when the device is powered on. 0 …L n Each layer is generally executed in a predefined order (e.g., one by one) after the DICE layer. The various tasks performed by the computing device 100 include L 0 …L n Each layer and authentication task is executed by the processor 40.

[0128] The device 100 includes a secret chain generation (SCG) 106 module and an authentication module 108. Each layer in the SCG 106 generates a key sequence in the form of S 0 …S n The DICE layer is used to generate 0 The first key S of the layer 0 , L 0 Layer generation for L 1 The first key S of the layer 1 In this example, the authentication module 108 is coupled to the last layer Ln Based on the above trust chain, the authentication in this case covers the DICE layer and each variable layer L 0 …L n Alternatively, the authentication module 108 may also be coupled to the slave 0 …L n-1 An intermediate layer L is selected from i , the certification will cover the DICE layer and L 0 …L i Each layer.

[0129] exist Figure 2 In the DICE layer and L 0 …L n-1 Each layer includes a one-way function (OWF) 120, which generates a key for the corresponding next layer L 1 …L n Specifically, the OWF of the DICE layer 112 generates the key S 0 Supply 0 Use, L 0 The OWF generates the key S 1 Supply 1 Use, and so on.

[0130] L 0 …L n Each layer can be represented by the corresponding measurement value (128)M 0 …M n Identification. The measurement of a layer may include, for example, a cryptographic hash function calculated on the layer's program code, a software image, data and / or firmware, or a combination of two or more of the above. In some embodiments, a given layer L i The generated key S i+1 is the measurement value M obtained by measuring the next layer based on the given layer i+1 And the previous layer L i-1 The generated key S i In some embodiments, using the above architecture, each layer can be presumed to be trustworthy or a layer of measurement that has been previously verified to be trustworthy.

[0131] OWF 120 should have the property of being difficult to perform inverse operations, so that the output key S i+1 And input the measured value M i+1 Derivation of input key S iIn one exemplary embodiment, OWF 120 includes a cryptographically secure hash function. Example functions of OWF 120 include, but are not limited to, a message authentication code (MAC), a hashed message authentication code (HMAC), a cipher-based MAC (CMAC), and a third generation secure hash algorithm (SHA-3) function Keccak message authentication code (KMAC).

[0132] In some embodiments disclosed in this specification, HMAC is used as an example of OWF 120; this method has been described in documents such as Request for Comments (RFC) 2104 in February 1997, entitled HMAC: Keyed-Hashing for Message Authentication.

[0133] To generate the key S 0 , the DICE layer will produce an L 0 The DICE layer has no upper layer, but instead includes a securely embedded unique device key (UDS) 124. The UDS is known only to the DICE layer and the authenticator. Depending on the implementation, the UDS may also be known to the device manufacturer. In one embodiment, the DICE layer uses an HMAC function by calculating

[0134] S 0 =HMAC(M 0 ,UDS)

[0135] Generate key S 0 , where UDS is used as the HMAC key. In the terminology used by TCG, the key S generated by the DICE layer above is 0 Also called a Composite Device Identifier (CDI).

[0136] To generate the key S 1 , L 0 The layer will generate an L 1 The measured value of the layer is 128B (in M 1 ), and receives the key S from the DICE layer 0 In this example, L 0 The layer includes a random number (in N) generated after the device is turned on. a In some embodiments, L 0 OWF reception of layer (i)L 1 The measured value of the layer M1 (ii) DICE layer key S 0 , and (iii) using a random number N generated by RNG 132 a As input. 0 The OWF of a layer is calculated by:

[0137] S 1 =HMAC([M 1 |N a ],S 0 )

[0138] Generate key S 1 , where S 0 Including HMAC key, and concatenated data [M 1 |N a ] is the data input of the HMAC function. In other layers, the key S i+1 Available from:

[0139] S i+1 =HMAC([M i+1 ],S i )

[0140] Calculated.

[0141] exist Figure 2 In the example, the random number N a YesL 0 The input of the OWF layer is a random number N a Usually implemented with a minimal code base that is expected to be bug-free and not require (or only require occasional) updates, so L 0 is considered a trust layer. However, usually the random number N a Maybe L 1 …L n Any OWF in other layers that is considered a trusted layer is input.

[0142] In certain embodiments, L 0 …L n Each of the layers includes a firmware security descriptor (FSD) 136. The FSD includes a self-measured value that is owned or calculated by the layer. Figure 2 In, L 0 Layer includes FSD 136A, while L n Layer includes FSD 136B. 0 …L n-1 At each layer, FSD may be incorporated into the key calculation of OWF. For example, in Figure 2 L 0layer, FSD 136A is provided to L 0 At this time, OWF is:

[0143] S 1 =HMAC([M 1 |FSD|N a ],S 0 )

[0144] Calculate S 1 At this time, the key S 1 According to L 0 and L 1 The measured value M obtained by measuring both 1 Decide.

[0145] exist Figure 2 In the example of n 116) Performing a device authentication protocol using the authentication module 108. This authentication protocol is typically performed by the device side by (i) receiving a challenge from the authenticator 104, (ii) signing the challenge using the authentication key to generate a response, and (iii) sending the response to the authenticator for authentication, as described herein.

[0146] L n The layer uses a key derivation function (KDF) 140, from the key S n Generate a symmetric key 144 (SK n denoted by () for authentication purposes. Several families of key derivation functions using pseudorandom functions are described in Lily Chen, October 2009, NIST special publication 800-108, entitled Recommendation for Key Derivation Using Pseudorandom Functions (Revised). Authentication module 108 receives a challenge generated by the verifier, denoted by C (usually C includes a random or pseudorandom number), and a device random number generated by RNG 160 in response to the challenge, denoted by N d The authentication module 108 uses SK n 144 Signature [C|N d ] generates a response, represented by R.

[0147] The authenticator receives a response R from the device and also receives N a and N d , and by using the same n The same key value signature [C|N d], in which R' is calculated. In some embodiments, the verifier is based on UDS and the measured value M i , using the device to calculate its SK n Same architecture, OWF and KDF functions to calculate SK n When R is equal to R', the device is successfully authenticated. After the device is powered on, the random number N a This random number indirectly leads to the authentication key SK n The value of has changed compared to its value before power-on. This result leads to the successful capture of the pre-power-on SK n An attacker with a valid value cannot use it for authentication after booting.

[0148] Figure 3 is a flow chart illustrating a method for device authentication and verification using symmetric key encryption according to an embodiment described in this specification.

[0149] The above authentication architecture can be Figure 1 The device 24 and the verifier 86 in the embodiment are executed. The device 24 is presumed to implement Figure 2 When performing the above authentication protocol, the device and the verifier can communicate with each other via, for example, the communication network 32.

[0150] Figure 3 The method (device portion) begins at a power-on step 200, where the processor 40 of the device 24 begins a power-on cycle. When powering on, the processor 40 begins executing the DICE layer 112. In a random number generation step 204, the processor (e.g., using the RNG 132) generates a random number N associated only with the current power-on cycle. a , and transmit N a to the verifier. Alternatively, the processor can also securely traverse L 1 …L n At least several layers transmit the random number N a , and the N a By non-L 0 A layer (such as L n ) is transmitted to the verifier. In one embodiment, the processor transmits the random number N a It is sent together with the response in step 220 described below.

[0151] In the key generation step 212, the processor generates a key in L n A symmetric authentication key is generated in the layer, SK n For example, the processor can n The key of the layer S n Use function OWF 120 to generate SK n The authentication key SK nThrough a key chain starting from a certain layer (where N a is the input value of the OWF layer) and according to the random number N a Decide.

[0152] In the challenge receiving step 216, the processor receives a challenge C from the verifier to verify the last layer L n Alternatively, the processor may also receive a challenge to verify L 0 …L n-1 Another layer in.

[0153] In response calculation step 220, the processor responds to the challenge by using the authentication key SK n Sign the challenge C (e.g., using signature function 148) to generate a response (denoted by R). For example, the processor signs:

[0154] R=MAC(C,SK n )

[0155] Calculate the response. In some embodiments, the processor generates a device random number N for C d (for example using RNG160), and with:

[0156] R=MAC([C|N d ],SK n )

[0157] Calculate the response. Set the random number N d Incorporating a response R can help overcome attempts to guess SK by sending multiple selected challenge values ​​to the device. n Further, in step 220, the processor 40 transmits the response R to the authenticator. As described above, in some embodiments, the processor transmits the response R and the random number N in step 220. a to the validator.

[0158] In the boot query step 228, the processor checks whether a reboot is necessary or occurring. If not, it returns to step 216 to receive the next challenge in the same boot cycle to verify the same layer or another layer. Otherwise, the processor returns to step 200 to start the next boot cycle and regenerate the N used in the previous boot cycle. a Random number N with different values a .

[0159] exist Figure 3 In the embodiment of the present invention, the processor generates SK in a power-on cycle. n In other embodiments, the processor may generate SK in response to receiving a challenge C. nIn this embodiment, Figure 3 Step 212 may be performed after step 216 and before step 220 .

[0160] Figure 3 The methods (of the validator part) are generally the same as Figure 3 (Device part) method is carried out in parallel. Figure 3 The method begins at a storage step 250 where the host processor 76 stores device information in a database of the authenticator (e.g., database 88). The device information can be used to recover the symmetric authentication key SK used by the device when generating a response to a given challenge. n To this end, the host processor stores device information for each device, including at least the UDS (62) of the DICE layer of the device, the layer settings used by the device, and the measurement values ​​associated with each layer. The authenticator uses the above device information (and a random number N a ) by calculating the SK calculated by the licensed device within itself n SK with the same value n Values, as described below.

[0161] In the random number receiving step 254, the verifier receives a random number N a , this random number N a Generated by the device and associated with the current power-on cycle. Generally speaking, the device provides N a Alternatively, the device may generate N multiple times in the same power-on cycle. a , and report each updated N to the validator a In some embodiments, the verifier does not receive the N in step 254. a , but in step 262 described below, N a Received with response.

[0162] In the challenge transmission step 258, the verifier generates a challenge C to verify the L n The authenticator generates and sends the challenge to the device. The authenticator typically generates a random or pseudo-random number as the challenge. The authenticator issues a different challenge each time, so that knowledge of the previous response is useless. Using different challenges is useful, for example, to reduce the risk of replay attacks. The authenticator may generate and send the challenge at any appropriate time, such as in response to a request from the device, at the request of an administrator, or periodically.

[0163] In the response receiving step 262, the authenticator receives a response R from the device corresponding to the challenge C previously sent in step 258. In the key recovery step 266, the authenticator uses the device information stored in step 250 and the random number N received in step 254 to a , recreate a symmetric authentication key SK inside it n A copy of SK n '.

[0164] In the verification step 270, the verifier uses the response R and the recovered authentication key SK n 'Verify the device's L n Because of the chain of trust in this device, by verifying L n layer, you can verify the DICE layer and L 0 …L n-1 As mentioned above, due to the authentication key SK n According to the random number N a Therefore, even if an attacker obtains the authentication key SK n , will also fail authentication after restarting, because N a The value of has changed.

[0165] After step 270, the authenticator returns to step 250, 254 or 258. Specifically, the authenticator returns to step 250 after the device is updated (e.g., software or firmware version is updated). Alternatively, the authenticator returns to step 254 after the device is powered on to receive the N associated with the current power cycle. a Alternatively, the authenticator returns to step 258 to send a next different challenge to the device.

[0166] [Authentication architecture using asymmetric key cryptography]

[0167] Figure 4 is a diagram illustrating a device layered architecture for asymmetric key authentication according to one embodiment described in this specification.

[0168] exist Figure 4 In the example, the computing device 300 is authenticated using the management server 302 running the authenticator 304. The computing device 300, the management server 302 and the authenticator 304 may be used to implement Figure 1 The computing device 24, management server 28 and verification program 86.

[0169] and Figure 1 Similar to the device 100, the device 300 runs multiple layers of code, including a "DICE layer" 312 and a variable code layer L 0 …L n .exist Figure 4For clarity, only L is shown. 0 314, L 1 316 and L n 318 and other layers. In one embodiment, the DICE layer is used as the root of the trust layer and is executed unconditionally when the device is turned on. 0 …L n Each layer is executed after the DICE layer in a predefined order (eg, one by one). The hierarchical and secret key generation architecture in the device 300 is generally similar to the architecture in the device 100 described above.

[0170] The apparatus 300 includes a secret chain generation (SCG) module 306, an authentication module 308, and a credential module 310. Figure 2 Similar to SCG 106 in FIG. 1 , SCG 306 uses OWF 320 to generate a key sequence S 0 …S n The OWF of the DICE layer is based on UDS324 and L 0 The measured value M 0 (328A) generated for L 0 The key of the layer S 0 .L 0 The OWF layer is generated for L 1 The key of the layer S 1 , and so on. For a given layer L i The OWF is based on the hierarchical order, based on the previous layer L i-1 The generated key S i and the measurement value M of the next layer i+1 Generate key S i+1 .

[0171] In this example, the authentication module 308 is connected to the last layer L n Coupling, so that the device authentication DICE layer and each variable layer L 0 …L n Alternatively, the authentication module 308 may also be connected to an intermediate layer L 0 …L n-1 Coupling to authenticate the middle layer and the layers below it.

[0172] In this example, (similar to the device 100 described above) L 0 The layer includes generating a random number N after the device is powered on a A random number generator (RNG) 332 is provided. In some embodiments, L 0 OWF reception of layer (i)L 1 The measured value of the layer M 1 (328B), (ii) the key S from the DICE layer0 , and (iii) using a random number N generated by RNG 332 a As input. 0 The OWF of a layer is calculated by, for example:

[0173] S 1 =HMAC([M 1 |N a ],S 0 )

[0174] Generate key S 1 Supply 1 Use, where S 0 Including HMAC key, and concatenated data [M 1 |N a ] is the data input of the HMAC function. In other layers, the key S i+1 Available from:

[0175] S i+1 =HMAC([M i+1 ],S i )

[0176] Calculated.

[0177] The certificate module 310 generates a certificate chain CERT 0 …CERT n , corresponding to L 0 …L n Each layer. The process of verifying the certificate includes using the 0 …L n Asymmetric key AK 0 …AK n In L i In the layer, the processor 40 performs the key S i Using a suitable key derivation function (KDF) 340, an asymmetric key AK is derived i KDF 340 may be the same (or similar) function as KDF 140 described above. Each asymmetric key AK i Including a public key PK i and a corresponding private key PR i In this example, L 0 …L n-1 Each layer includes an Embedded Certificate Authorization (ECA) 342. 0 Layer ECA 0 Generate CERT 1 , L 1 Layer ECA1 Generate CERT 2 , and so on.

[0178] exist Figure 2 In the example of i Layer ECA i Receive peer L i Generated private key PR i and equal to the expected value to be generated in the next layer L i+1 Asymmetric key AK i+1 PK i+1 The public key PK i+1 '(In L i In certain embodiments, ECA i By using a private key PR i Signature Public Key PK i+1 To generate the CERT i+1 Therefore, the CERT i+1 It can be provided that it has been L i Layer private key PR i It should be noted that CERT i+1 Also through the key S i , L i KDF, AK of the layer i and ECA i , which implies the i-1 Measured value M of layer measurement i The credentials.

[0179] In some embodiments, the device 300 uses a CERT 0 To the device L 0 The external certification authority (CA) 350 of the L 0 The public key PK of the layer 0 CERT 0 Also known as "device ID", PK 0 When the manufacturer appoints CA 350 as the certificate authority for the device, CERT 0 This proves that the device was manufactured by that manufacturer. In addition, CERT 0 The device may also be provided by an original equipment manufacturer (OEM). 0 The layer may use any suitable self-credentialing method to authenticate the PK 0 In one embodiment, the L i Layer, AK i-1The public key PK i-1 Can be used to make the CERT i The signature will take effect.

[0180] The authentication module 308 receives L n The key of the layer S n , and use KDF 340 self-key S n Generate an asymmetric key AK n , its private key PR n The authentication module 308 receives a challenge N from the verifier 304. v , and by using the private key PR n Challenge N v Using signature function 354, a digital signature response DS is generated. Example methods for signature generation and verification suitable for implementing function 354 for signing (and verification in a verifier) ​​are described in the Federal Information Processing Standard Publication (FIPS PUB) 186-4, Digital Signature Standard (DSS), July 2013. The authentication module 308 further receives L 0 …L n CERT 0 …CERT n The part of the authenticator in this authentication architecture is described in detail below.

[0181] Figure 5 is a flow chart illustrating a method for device authentication and verification using asymmetric key encryption according to an embodiment described in this specification.

[0182] This authentication framework can be Figure 1 The device 24 in the embodiment is executed by the verifier 86. The device 24 is presumed to implement Figure 4 When performing the authentication protocol, the device and the authenticator may communicate with each other via, for example, a communication network 32 .

[0183] Figure 5 The method (device portion) begins when the processor 40 of the device 24 begins a power cycle at power-on step 400. When powering on, the processor 40 begins executing the DICE layer 312. In a random number generation step 404, the processor generates (e.g., using the RNG 332) a random number N associated only with the current power cycle. a Alternatively, the processor may (eg, securely) traverse L 1 …L n At least several layers transmit random numbers N a , and the N a By non-L 0 A layer (such as Ln ) is sent to the validator.

[0184] In the voucher step 408, the processor executes L according to a predefined order (eg, one by one). 0 …L n Each layer, and at each layer L i Based on L i-1 The generated key S i Generate asymmetric key AK i . The processor is more in L i (Using ECA i ) generates a verification L i+1 AK in layer i+1 The public key PK i+1 , and by AK i Private key PR i Signed certificate.

[0185] In the challenge receiving step 412, the processor receives a challenge N from the verifier. v In response calculation step 420, the processor responds to the challenge by using the asymmetric key AK n Private key PR n Challenge N v Signing is performed (eg, using signing function 354) and a digital signature DS is calculated.

[0186] In the response transmission step 424, the processor transmits the response DS and the certificate CERT via the communication network 32. 0 …CERT n to the authenticator.

[0187] In the power-on query step 428, the processor checks whether a power-on restart is necessary or occurring. If not, it returns to step 412 to receive the next challenge from the authenticator. Otherwise, the processor returns to step 40 to start the next power-on cycle and generates an N a Random number N with different values a .

[0188] Figure 5 The methods (of the validator part) are generally the same as Figure 5 (Device part) method is carried out in parallel. Figure 5 The method begins with the verifier 86 generating and transmitting a challenge N in a challenge transmission step 458. v To device 24, to verify L n The authenticator may generate and transmit the challenge at any suitable time, such as in response to a service request from the device, an administrator request, or periodically.

[0189] In response receiving step 462, the host receives from the device a challenge N corresponding to the challenge N transmitted in step 458. v The verification operation mainly consists of two stages: (i) verifying the credential, and (ii) verifying the digital signature response, as described in this article.

[0190] In a credential verification step 466, the host verifies the CERT 0 …CERT n The authenticator is presumed to hold the manufacturer's CA 350 root certificate, or the authenticator can be verified by CERT 0 The Authorization Information Access (AIA) field in the certificate accesses the root certificate. The authenticator uses the above root certificate to verify the CERT 0 The validator uses the 0 Perform public key PK of the certificate 0 (Device ID) Verification CERT 1 , and so on, until the PK is verified n CERT for credentials n After the credential verification is completed, PK n It can be considered trustworthy.

[0191] In digital signature verification step 470, the verifier uses PK n Verify the DS response. The DS verification function in step 470 matches the signature generation function 354 used by the device. This verification stage verifies the DICE layer and L 0 …L n The identity and status of each layer.

[0192] After step 470, the method returns to step 458 to send the next different challenge N, if necessary. v to the device.

[0193] In some embodiments, after a device power-on event, the authenticator waits for the device to perform steps 400, 404, and 408 and indicate to the authenticator that the device is ready to receive the next challenge.

[0194] The above embodiments are examples, and other suitable embodiments may also be used. For example, although in the above embodiments, the trust chain uses the DICE layer as the trust root, in other embodiments, other types of elements may also be used as the trust root.

[0195] Although the embodiments described in this specification are primarily directed to a device authentication architecture connected to a wireless network or a land network, the methods and systems described in this specification may also be used for other purposes, such as where the device and authenticator are connected by a suitable bus (e.g., on a motherboard) or by a cable (e.g., in a vehicle).

[0196] It should be noted that the above embodiments are cited as examples, and the following claims are not limited to the above explicit contents. On the contrary, their scope includes the combination and sub-combination of the above features, as well as changes and improvements that can be known to a person skilled in the art after reading the above content and are not disclosed in the prior art. The documents incorporated by reference in this application shall be regarded as part of the entire application of this application, except where the definitions of terms in such incorporated documents conflict with the definitions expressly or impliedly in this specification, and in the case of conflict, only the definitions used in this specification shall be adopted.

Claims

1. A secure computing device, characterized in that: include: a network interface configured to communicate with a validator via a communications network; a memory configured to store multiple layers of variable program code, each layer of the multiple layers of variable program code being identifiable by a corresponding measurement value; as well as A processor configured to: In a given power-on cycle, generating a random number associated only with the given power-on cycle; receiving a challenge from the verifier to authenticate a given layer of the variable program code; Calculating a first authentication key by deriving from a unique device key stored in the secure computing device, a measurement value of the given layer measured by another layer, and a random number generated for the given boot cycle; Using the first authentication key to sign the challenge to calculate a response corresponding to the challenge; as well as The response is sent to the verifier to verify the given layer.

2. The secure computing device according to claim 1, characterized in that: The processor is configured to calculate the first authentication key according to the random number, so that the second authentication key used by the processor for authentication before the given boot cycle becomes invalid and cannot be authenticated in the given boot cycle.

3. The secure computing device according to claim 2, wherein: The processor is configured to set the first authentication key to be different from a second authentication key used by the processor for authentication before the given boot cycle, even if the variable program code of the given layer and layers executed before the given layer remains intact during the given boot cycle.

4. The secure computing device according to claim 1, wherein: The first authentication key includes a symmetric key determined according to the random number, and the processor is configured to calculate the response by signing at least the challenge using the symmetric key, and transmit the response and the random number to the verifier.

5. The secure computing device according to claim 1, wherein: The first authentication key includes an asymmetric key determined according to the random number, and the processor is configured to sign the challenge by using a private key of the asymmetric key to calculate the response, and transmit the response to the verifier without transmitting the random number.

6. The secure computing device according to claim 5, characterized in that: The processor is configured to generate the asymmetric key for each layer, the first authentication key includes the asymmetric key, each of the asymmetric keys includes a private key and a public key, to generate a certificate chain, wherein the certificate in the given layer is used to certify the public key generated in the next layer, and the certificate in the given layer is signed by the private key generated in the given layer, and the certificate chain is transmitted to the verifier for verification using the certified public key of the first authentication key.

7. The secure computing device according to claim 6, wherein: The certificate chain includes a certificate independently generated from the random number, and the certificate is used to prove that the secure computing device is manufactured by a specific manufacturer.

8. The secure computing device according to claim 1, wherein: The processor is configured to generate the random number in a trust layer executed before the given layer, calculate a key in the trust layer based on the random number, and calculate the first authentication key according to the key.

9. The secure computing device according to claim 1, wherein: The processor is configured to execute the multiple layers of variable program code in a predefined order and proceed from a selected layer to a next layer in the predefined order only after the selected layer has been successfully verified by the verifier.

10. The secure computing device according to claim 1, wherein: The processor is configured to calculate the first authentication key according to the random number to reduce the risk of zero-day attacks.

11. A secure computing method, characterized in that: include: In a device communicating with a validator via a communication network, storing multiple layers of variable program code in a memory of the device, each layer of the multiple layers of variable program code being identifiable by a corresponding measurement value; In a given power-on cycle, generating a random number associated only with the given power-on cycle; receiving a challenge from the verifier to authenticate a given layer of the variable program code; deriving a first authentication key based on a unique device key stored in the device, a measurement of the given layer by another layer, and a random number generated for the given boot cycle; Using the first authentication key to sign the challenge to calculate a response corresponding to the challenge; as well as The response is sent to the verifier to verify the given layer.

12. The secure computing method according to claim 11, characterized in that: The action of calculating the first authentication key includes calculating the first authentication key based on the random number, so that the second authentication key used by the processor for authentication before the given boot cycle becomes invalid and cannot be authenticated in the given boot cycle.

13. The secure computing method according to claim 12, wherein: The operation of calculating the first authentication key includes: The first authentication key is set to be different from a second authentication key used by the processor for authentication before the given boot cycle, even if the variable program code of the given layer and layers executed before the given layer remains intact during the given boot cycle.

14. The secure computing method according to claim 11, wherein: The first authentication key comprises a symmetric key determined according to the random number, and the action of calculating the response comprises: At least the challenge is signed using the symmetric key to calculate the response, and the response and the random number are transmitted to the verifier.

15. The secure computing method according to claim 11, wherein: The first authentication key comprises an asymmetric key determined according to the random number, and the action of calculating the response comprises: The challenge is signed using a private key of the asymmetric key to calculate the response, and the response is transmitted to the verifier without transmitting the random number.

16. The secure computing method according to claim 15, characterized in that: Also includes: Generating the asymmetric key for each layer, wherein the first authentication key includes the asymmetric key, and each asymmetric key includes a private key and a public key; Generate a credential chain; Wherein a certificate in a given layer certifies a public key generated in a next layer, and the certificate in the given layer is signed by a private key generated in the given layer, and the certificate chain is transmitted to the verifier for verification using the certified public key of the first authentication key.

17. The secure computing method according to claim 16, wherein: The certificate chain includes a certificate independently generated from the random number, the certificate proving that the device was manufactured by a specific manufacturer.

18. The secure computing method according to claim 11, wherein: The act of generating the random number includes generating the random number in a trust layer executed before the given layer, and wherein the act of calculating the first authentication key includes calculating a secret key in the trust layer based on the random number, and calculating the first authentication key according to the secret key.

19. The secure computing method according to claim 11, wherein: The method further includes executing the multiple layers of variable program code in a predefined order and proceeding from the selected layer to the next layer in the predefined order only after the selected layer has been successfully verified by the verifier.

20. The secure computing method according to claim 11, wherein: The action of calculating the first authentication key includes calculating the first authentication key according to the random number to reduce the harm of zero-day attacks.

21. A validator, characterized in that: include: a network interface configured to communicate with a device via a communication network, the device comprising multiple layers of variable program code, each layer of the multiple layers of variable program code being identifiable by a corresponding measurement value, and the device generating a random number associated only with a given boot cycle in a given boot cycle; as well as A processor is configured to: sending a challenge to the device to authenticate a given layer of the variable program code; receiving, from the device, a response message generated by the device signing the challenge using a first authentication key, wherein the first authentication key is determined by the device based on a unique device key stored in the device, a measurement of the given layer by another layer, and the random number associated with the given boot cycle; as well as Using the response information, the given layer of the variable program code is verified.

22. The authenticator according to claim 21, characterized in that The response message includes at least a challenge signed by an authentication key determined according to the random number, and wherein the processor is configured to securely store device information in a memory of the authenticator before transmitting the challenge, the device information being sufficient to recover the authentication key when combined with the random number; The processor is configured to receive the random number from the device, restore the authentication key using the device information and the received random number, and verify the given layer of the variable program code using the restored authentication key.

23. The authenticator according to claim 21, characterized in that The response message includes a digital signature of the challenge, wherein the challenge is signed by a private key of the asymmetric authentication key, and a certificate of a public key associated with the given layer, and wherein the processor is configured to verify a public key verified in the certificate signed by a private key matching the public key, and then verify the digital signature using the verified public key.

24. A device verification method, characterized in that: include: In a server communicating with a device via a communication network, wherein the device includes multiple layers of variable program code, each layer of the multiple layers of variable program code is identifiable by a corresponding measurement value, and the device generates a random number associated only with a given boot cycle during a given boot cycle, sending a challenge to the device to authenticate a given layer of the variable program code; receiving, from the device, a response message generated by the device signing the challenge using a first authentication key, wherein the first authentication key is determined by the device based on a unique device key stored in the device, a measurement of the given layer by another layer, and a random number associated with the given boot cycle; as well as Using the response information, the given layer of the variable program code is verified.

25. The method according to claim 24, characterized in that The response message at least includes a challenge signed by an authentication key determined according to the random number, and the processor is configured to securely store device information in a memory of the server before transmitting the challenge, wherein the device information combined with the random number is sufficient to recover the authentication key; The processor is configured to receive the random number from the device, restore the authentication key using the device information and the received random number, and verify the given layer of the variable program code using the restored authentication key.

26. The method according to claim 24, characterized in that The response message includes a digital signature of the challenge, wherein the challenge is signed by a private key of the asymmetric authentication key, and a certificate for a public key associated with the given layer, and wherein the processor is configured to verify a public key verified in a certificate signed by a private key matching the public key, and then verify the digital signature using the verified public key.

Images