WO2023217357A1 - Certification de clé de plateforme avec racine de confiance de classe de dispositif - Google Patents

Certification de clé de plateforme avec racine de confiance de classe de dispositif Download PDF

Info

Publication number
WO2023217357A1
WO2023217357A1 PCT/EP2022/062674 EP2022062674W WO2023217357A1 WO 2023217357 A1 WO2023217357 A1 WO 2023217357A1 EP 2022062674 W EP2022062674 W EP 2022062674W WO 2023217357 A1 WO2023217357 A1 WO 2023217357A1
Authority
WO
WIPO (PCT)
Prior art keywords
key
device class
provisioning
key pair
certificate
Prior art date
Application number
PCT/EP2022/062674
Other languages
English (en)
Inventor
Qiming Li
Sampo Sovio
Gang LIAN
Pekka Laitinen
Original Assignee
Huawei Technologies Co., Ltd.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Huawei Technologies Co., Ltd. filed Critical Huawei Technologies Co., Ltd.
Priority to PCT/EP2022/062674 priority Critical patent/WO2023217357A1/fr
Publication of WO2023217357A1 publication Critical patent/WO2023217357A1/fr

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/602—Providing cryptographic facilities or services
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/64—Protecting data integrity, e.g. using checksums, certificates or signatures
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/64—Protecting data integrity, e.g. using checksums, certificates or signatures
    • G06F21/645—Protecting data integrity, e.g. using checksums, certificates or signatures using a third party
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3263—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3271—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using challenge-response

Definitions

  • the present invention relates generally to a device, a server and an improved mechanism for platform key certification and validation.
  • a computing device During the secure manufacturing process of a computing device, it is often required to provision cryptographic keys, digital certificates, and configuration data to the devices in a secure way. Similar processes may be required when individual components of the computing devices are manufactured. For example, when a mobile phone with a secure element (SE) is manufactured, some keys and data may be provisioned into the secure element by the secure element vendor, while other keys and data may be provisioned into a secure region of the mobile device after the secure element has been integrated into the device.
  • SE secure element
  • a class key is a symmetric cryptographic key provisioned by an integrated circuit (IC) vendor during the manufacturing of the chips, such as system-on-chip (SoC) chips, secure elements, and others.
  • SoC system-on-chip
  • the device vendor can utilise the class keys to derive asymmetric key pairs (i.e. platform key pairs) for the purpose of secure provisioning of other keys and data for the devices.
  • the class keys are so named because each of the class keys is shared among a class of IC chips, such as chips manufactured in the same batch, or those intended to be deployed in the same type of devices by the same device vendor.
  • An objective of the present disclosure is to provide a platform key certification and validation method.
  • a first aspect of the present disclosure provides a method comprising deriving, by a first device, a root asymmetric key pair based on a symmetric cryptographic key of a device class identifier and a set of derivation parameters, the symmetric cryptographic key of the device class identifier comprised in the first device, certifying, by a first certification authority, a public key of the derived root asymmetric key pair to thereby obtain a device class certificate, and registering the device class certificate with a public server such that the device class certificate is publicly available.
  • any verifier can validate the derived keys without a reference device, implicit trust, or knowledge about the key derivation process. Additionally, by having dynamically derived keys, various keys can be derived and used in different use cases. Importantly, the verifier can validate whether the derived key has been correctly derived for the intended use case.
  • the set of derivation parameters may comprise a key derivation parameter, an internal diversifier, and an external diversifier.
  • the key pair can be derived such that the key derivation parameter and the external diversifier have correct values known to a verifier, and the internal diversifier correctly reflects the expected use case.
  • the set of derivation parameters may be statically programmed into the first device.
  • the derivation and certification of a root asymmetric key can be a one-time process for each device or chip class (i.e. devices or IC chips loaded with the same class key).
  • the set of derivation parameters may be provided to the first device via user input.
  • the derivation parameters can be provided from the outside of the device.
  • the symmetric cryptographic key of the device class identifier may be securely programmed into the device during manufacturing. Certifying the public key of the derived first root asymmetric key pair may comprise the step of using a certificate enrollment method in a public-key infrastructure, PKI. Thus, the certification can be obtained in a straightforward manner.
  • the device class certificate may comprise the set of derivation parameters.
  • the asymmetric key can be derived from the device class certificate.
  • the method may further comprise the step of cross-certifying, by a second certification authority, the public key of the derived first root asymmetric key pair.
  • a second certification authority the public key of the derived first root asymmetric key pair.
  • the method may further comprise the steps of deriving, by a second device of the same class as the first device, the root asymmetric key pair based on the symmetric cryptographic key of the device class identifier and the set of derivation parameters, the symmetric cryptographic key of the device class identifier comprised in the second device, deriving, by the second device, a provisioning asymmetric key pair based on a set of input parameters, generating an attestation comprising a public key of the provisioning asymmetric key pair and the set of input parameters, and obtaining, by a verifier, the attestation from the second device and the device class certificate from the public server to thereby validate the provisioning asymmetric key pair derived by the second device.
  • the validity of the derived key can be verified by a third party without a reference device.
  • the method may further comprise the step of extracting, by the verifier, the public key of the provisioning asymmetric key pair from the attestation.
  • the key can be used in the intended use cases.
  • Validating the provisioning asymmetric key pair may comprise at least one of verifying, by the verifier, that the device class certificate is valid, verifying, by the verifier, that a signature related to the attestation is valid, and verifying, by the verifier, that the set of input parameters in the attestation is valid.
  • a second aspect of the present disclosure provides a device comprising a processor, a memory coupled to the processor, the memory configured to store program code executable by the processor, the program code comprising one or more instructions, whereby to cause the user device to derive a root asymmetric key pair based on a symmetric cryptographic key of a device class identifier and a set of derivation parameters, the symmetric cryptographic key of the device class identifier comprised in the device, transmit a public key of the derived root asymmetric key pair to a first certification authority to thereby obtain a device class certificate from the first certification authority, and transmit the obtained device class certificate to a public server to thereby register the device class certificate therewith, such that the device class certificate is publicly available.
  • any verifier can validate the derived keys without a reference device, implicit trust, or knowledge about the key derivation process. Additionally, by having dynamically derived keys, various keys can be derived and used in different use cases. Importantly, the verifier can validate whether the derived key has been correctly derived for the intended use case.
  • the set of derivation parameters may comprise a key derivation parameter, an internal diversifier, and an external diversifier.
  • the key pair can be derived such that the key derivation parameter and the external diversifier have correct values known to a verifier, and the internal diversifier correctly reflects the expected use case.
  • the memory may be configured to store the set of derivation parameters, the set of derivation parameters statically programmed into the memory during the manufacturing of the device.
  • the derivation and certification of a root asymmetric key can be a one-time process for each device or chip class (i.e. devices or IC chips loaded with the same class key).
  • the device may further comprise an interface configured to receive a user input, the interface coupled to the memory such that the memory is configured to store the user input as the set of derivation parameters.
  • the derivation parameters can be provided from the outside of the device.
  • the memory may be configured to securely store the symmetric cryptographic key of the device, the symmetric cryptographic key of the device programmed into the memory during manufacturing of the device.
  • a third aspect of the disclosure provides a provisioning server comprising a processor, a memory coupled to the processor, the memory configured to store program code executable by the processor, the program code comprising one or more instructions, whereby to cause the provisioning server to receive, from a device, a request for data to be provisioned, the request comprising a device class identifier, retrieve, from a certificate authority, a device class certificate corresponding to the device class identifier, transmit, to the device, a random challenge value, the device class certificate, a first set of derivation parameters, and a second set of derivation parameters for encryption, receive, from the device, a signed challenge and an attestation for a first provisioning asymmetric key pair and a second provisioning asymmetric key pair, validate that the signed challenge is correct using a public key of the first provisioning asymmetric key pair extracted from the attestation, encrypt the data to be provisioned using a public key of the second provisioning asymmetric key pair extracted from the attestation, and transmit the encrypted
  • the provisioning server can easily validate the keys used during the provisioning process, including the asymmetric key without the use of a reference device.
  • a system comprising a device as set out herein, and a provisioning server as set out herein.
  • Figure 1 schematically depicts a device, in accordance with an example embodiment
  • Figure 2 schematically depicts a method, in accordance with an example embodiment
  • Figure 3 schematically depicts a method, in accordance with an example embodiment
  • Figure 4 schematically depicts a provisioning server, in accordance with an example embodiment.
  • Asymmetric cryptography also known as public key cryptography refers to a cryptographic technique that involves a pair of keys linked with each other, i.e. a public key and a private key.
  • the public key may be distributed widely, whereas the private key is only known by its owner. Any person can encrypt a message using the public key of the owner (i.e. receiver of the message), but such an encrypted message can only be decrypted with the receiver's private key.
  • the public key can used for authentication, i.e. to verify by anyone that the owner of the corresponding private key sent the message.
  • Symmetric cryptography refers to a cryptographic technique that involves the use of the same cryptographic key for both encryption of plaintext and decryption of ciphertext. In other words, the cryptographic key of the symmetric cryptography represents a shared secret between two or more parties.
  • a traditional public-key infrastructure may be employed, and a digital certificate for each and every valid platform public key may be enrolled.
  • PKI public-key infrastructure
  • a new platform pair is needed, for example, due to a new use case or a new device vendor. This may be undesirable and/or infeasible in some scenarios.
  • a new certificate would need to be enrolled for the new use case, and then distributed for all the devices requiring the new use case.
  • a mechanism for allowing any verifier to validate the derived platform keys without a reference device or implicit trust or knowledge about the key derivation process By having dynamically derived platform keys, various platform keys can be derived and used for different use cases. Furthermore, a verifier can validate that the derived platform key is correctly derived for the intended use case.
  • Examples in the present disclosure can be provided as methods, systems or machine-readable instructions, such as any combination of software, hardware, firmware or the like.
  • Such machine-readable instructions may be included on a computer readable storage medium (including but not limited to disc storage, CD-ROM, optical storage, etc.) having computer readable program codes therein or thereon.
  • the machine-readable instructions may, for example, be executed by a machine such as a general-purpose computer, user equipment such as a smart device, e.g., a smart phone, a special purpose computer, an embedded processor or processors of other programmable data processing devices to realize the functions described in the description and diagrams.
  • a processor or processing apparatus may execute the machine-readable instructions.
  • modules of apparatus for example, a module implementing a comparator unit, or a firewall structure and so on
  • processor' is to be interpreted broadly to include a CPU, processing unit, ASIC, logic unit, or programmable gate set etc.
  • the methods and modules may all be performed by a single processor or divided amongst several processors.
  • Such machine-readable instructions may also be stored in a computer readable storage that can guide the computer or other programmable data processing devices to operate in a specific mode.
  • the instructions may be provided on a non-transitory computer readable storage medium encoded with instructions, executable by a processor.
  • FIG. 1 schematically depicts a device, in accordance with an example embodiment.
  • the device 100 can be, for example, an electronic device such as a smartphone, tablet computer, smart watch, laptop computer, Internet-of-Things (loT) device and others.
  • the device 100 comprises a processor 103, and a memory 105 coupled to the processor 103 and configured to store instructions or program code 107, executable by the processor 103.
  • the device 100 is arranged to derive a root asymmetric key pair based on a symmetric cryptographic key of a device class identifier and a set of derivation parameters, the symmetric cryptographic key of the device class identifier comprised in the device 100.
  • the root asymmetric key pair may also be referred to using the term root platform key pair or similar.
  • the device 100 may comprise a secure region where the symmetric cryptographic key of the device class identifier is programmed and made available to a secure software component of the device 100.
  • the memory 105 may be configured to securely store the symmetric cryptographic key of the device class identifier, the symmetric cryptographic key of the device programmed into the memory 105 during manufacturing of the device.
  • the secure software component may comprise a key derivation service, thereby enabling the device 100 to derive the root asymmetric key pair.
  • the device 100 belongs to a class of devices.
  • devices with the same hardware specifications may share the same class.
  • hardware with different specifications it is possible for hardware with different specifications to also have the same class identifier.
  • a device class is uniquely identified by an associated device class identifier.
  • each device class identifier is assigned its own class key.
  • the class key is a symmetric cryptographic key that is the same for all the hardware with the same class identifier.
  • the class key is a secret cryptographic key shared by all the hardware with the same class manufactured by the hardware vendor.
  • the class key is typically written into a secure memory area of the device (such as a secure storage in the memory 105) that is accessible by secure hardware of the device. Normal application code cannot access the class key.
  • the root asymmetric key pair is derived in the same way as other asymmetric key pairs, except that the derivation parameters and diversifiers used to derive the keys are tightly controlled so that they can be trusted implicitly or certified together with the derived public key.
  • the derivation parameters may comprise a key derivation parameter, an internal diversifier, and an external diversifier.
  • the device 100 is arranged to transmit a public key of the derived root asymmetric key pair to a first certification authority to thereby obtain a device class certificate from the first certification authority.
  • the device 100 is arranged to transmit the obtained device class certificate to a public server to thereby register the device class certificate therewith, such that the device class certificate is publicly available.
  • the device class certificate may be obtainable via a public cloud service.
  • the memory 105 may be configured to store the set of derivation parameters, the set of derivation parameters statically programmed into the memory 105 during manufacturing of the device 100. That is, the set of derivation parameters may remain the same during the lifetime of the device 100.
  • the device 100 may comprise an interface 109 configured to receive a user input, the interface 109 coupled to the memory 105 such that the memory 105 is configured to store the user input as the set of derivation parameters. That is, the set of derivation parameters may be dynamically supplied to the device 100 during the root asymmetric key pair derivation process.
  • Figure 2 schematically depicts a method, in accordance with an example embodiment.
  • the method comprises, in block 201, deriving, by a first device, a root asymmetric key pair based on a symmetric cryptographic key of a device class identifier and a set of derivation parameters, the symmetric cryptographic key of the device class identifier comprised in the first device.
  • the first device may be, for example, the device 100 shown in Figure 1 and described above.
  • the method comprises certifying, by a first certification authority, a public key of the derived root asymmetric key pair to thereby obtain a device class certificate.
  • the device class certificate is registered with a public server such that the device class certificate is publicly available.
  • the process of root asymmetric key certification may comprise three main steps. Firstly, a root asymmetric key pair (or, in other words, root platform key pair) is derived from the class key and the static root parameters using the platform derivation service.
  • the platform derivation service may be a software or a hardware component within the first device responsible for key derivation.
  • the public key of the derived root asymmetric key pair (in other words, a root platform public key) is certified using a certified authority.
  • the certification may be performed using any certificate enrollment method in the traditional public key infrastructure (PKI).
  • PKI public key infrastructure
  • the result of the certification (known as the device class certificate) is registered with a public server.
  • the symmetric cryptographic key of the device class identifier may be securely programmed into the first device (such as the device 100) during manufacturing. For the sake of brevity, a description thereof will not be repeated.
  • certificate and “certification” are used in a broad sense.
  • X.509 digital certificates and common certificate enrollment protocols may be used.
  • a proprietary protocol or certificate format may be used.
  • the set of derivation parameters may comprise a key derivation parameter, an internal diversifier, and an external diversifier. These parameters may be either statically programmed into the first device and hence remain the same during the lifetime of the first device or dynamically supplied during the root asymmetric key derivation, e.g. as user inputs.
  • the device class certificate may comprise the set of derivation parameters, regardless of whether said parameters are static or dynamic (i.e. externally provided).
  • the parameters may be included as certificate extensions with a publicly specified object identifier. If the device class certificate is in a proprietary format, said format may support the inclusion of such parameters.
  • the method of Figure 2 may further comprise the step of cross-certifying, by a second certification authority, the public key of the derived first root asymmetric key pair, after it has been certified by the first certification authority.
  • Such cross-certification may be performed using standard methods in the PKI or using any non-standard method which allows for the result of the cross-certification to be verified by a verifier that wishes to validate the root asymmetric key.
  • reference devices and/or IC chips are only required during the root asymmetric key certification.
  • Cross-certification of the root asymmetric key can be performed at any time without a reference device, and can be repeated if necessary.
  • a third-party verifier is able validate that the root asymmetric key pair is derived according to a given specification by validating the device class certificate and the set of derivation parameters included in the certificate. The validity of such root asymmetric key pair may then be used to further validate other asymmetric key pairs, as described in more detail below.
  • certified root asymmetric keys allow further certification of other asymmetric keys, effectively building a trust chain from the first certificate authority (or a third-party certificate authority) such that the validity of the derived asymmetric key can be verified by a third party without a reference device.
  • Figure 3 schematically depicts a method, in accordance with an example embodiment.
  • the method depicted in Figure 3 is a continuation of the method depicted in Figure 2, i.e. the steps depicted herein take place after the steps of Figure 2.
  • the root asymmetric key can be used to further attest (i.e. certify) other asymmetric keys derived from IC chips or devices belonging to the same device or chip class via the method of Figure 3.
  • the method may comprise deriving, by a second device of the same class as the first device, the root asymmetric key pair based on the symmetric cryptographic key of the device class identifier and the set of derivation parameters, the symmetric cryptographic key of the device class identifier comprised in the second device.
  • the method may comprise deriving, by the second device, a provisioning asymmetric key pair based on a set of input parameters. Said input parameters may be identical to the set of derivation parameters used by the first device.
  • the input parameters comprise key derivation parameters and diversifiers, provided either statically or dynamically.
  • the method may comprise generating an attestation comprising a public key of the provisioning asymmetric key pair and the set of input parameters.
  • the method may comprise obtaining, by a verifier, the attestation from the second device and the device class certificate from the public server to thereby validate the provisioning asymmetric key pair derived by the second device.
  • the verifier may extract the public key of the provisioning asymmetric key pair from the attestation and use it in the intended use cases.
  • Validating the provisioning asymmetric key pair by the verifier may comprise at least one of verifying that the device class certificate is valid, verifying that a signature related to the attestation is valid, and verifying that the set of input parameters in the attestation is valid.
  • the process of attestation and validation may comprise obtaining the device class certificate beforehand so that the parameters can be retrieved and used to derive the provisioning asymmetric key pair.
  • FIG. 4 schematically depicts a provisioning server, in accordance with an example embodiment.
  • the provisioning server 400 comprises a processor 403 and a memory 405 coupled to the processor 403, the memory configured to store instructions or program code 407, executable by the processor 403.
  • the device when a device already deployed in the field (for example, a device such as the device 100) requires additional data that is to be provisioned by the provisioning server 400, the device sends a request for data to be provisioned, the request comprising a device class identifier.
  • the provisioning server 400 is arranged to retrieve the device class certificate corresponding to the device class identifier from a certificate authority or a public server where the device class certificate was registered.
  • the provisioning server 400 then responds with a random challenge value, the device class certificate, a first set of derivation parameters, and a second set of derivation parameters.
  • the first set of derivation parameters may be used for authentication purposes, whereas the second set of derivation parameters may be used for encryption.
  • the provisioning server 400 receives, from the device, a signed challenge and an attestation for a first provisioning asymmetric key pair and a second provisioning asymmetric key pair.
  • the first provisioning asymmetric key pair may be derived using the first set of derivation parameters
  • the second provisioning asymmetric key pair may be derived using the second set of derivation parameters.
  • the attestation may be generated for both the first and second provisioning asymmetric key pairs, signed by a root asymmetric key.
  • the received challenge may be signed using the first provisioning asymmetric key.
  • the provisioning server 400 validates that the signed challenge is correct using a public key of the first provisioning asymmetric key pair extracted from the attestation. For example, the provisioning server 400 may validate that the keys are generated according to parameters specified in the device class certificate and the first and second set of derivation parameters, and validate that the signed challenge is correct using the public key of the first provisioning asymmetric key pair. After that, the provisioning server 400 encrypts the data to be provisioned using a public key of the second provisioning asymmetric key pair extracted from the attestation, and transmits the encrypted data to the device.
  • machine-readable instructions can be loaded onto a computer or other programmable data processing devices, so that the computer or other programmable data processing devices perform a series of operations to produce computer-implemented processing, thus the instructions executed on the computer or other programmable devices provide an operation for realizing functions specified by flow(s) in the flow charts and/or block(s) in the block diagrams.
  • teachings herein may be implemented in the form of a computer or software product, such as a non-transitory machine-readable storage medium, the computer software or product being stored in a storage medium and comprising a plurality of instructions, e.g., machine readable instructions, for making a computer device implement the methods recited in the examples of the present disclosure.
  • Cloud-computing environments may provide various services and applications via the Internet. These cloud-based services (e.g., software as a service, platform as a service, infrastructure as a service, etc.) may be accessible through a web browser or other remote interface of the user equipment for example. Various functions described herein may be provided through a remote desktop environment or any other cloud-based computing environment.
  • the embodiments disclosed herein may also be implemented using software modules that perform certain tasks. These software modules may include script, batch, or other executable files that may be stored on a computer-readable storage medium or in a computing system. In some embodiments, these software modules may configure a computing system to perform one or more of the exemplary embodiments disclosed herein. In addition, one or more of the modules described herein may transform data, physical devices, and/or representations of physical devices from one form to another.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Theoretical Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Computer Hardware Design (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Health & Medical Sciences (AREA)
  • General Health & Medical Sciences (AREA)
  • Bioethics (AREA)
  • Computing Systems (AREA)
  • Storage Device Security (AREA)

Abstract

La présente invention concerne, selon certains exemples, un procédé qui comprend les étapes consistant à dériver, par un premier dispositif, une paire de clés asymétriques racines sur la base d'une clé cryptographique symétrique d'un identifiant de classe de dispositif et d'un ensemble de paramètres de dérivation, la clé cryptographique symétrique de l'identifiant de classe de dispositif étant comprise dans le premier dispositif, certifier, par une première autorité de certification, une clé publique de la paire de clés asymétriques racines dérivée pour obtenir ainsi un certificat de classe de dispositif et enregistrer le certificat de classe de dispositif avec un serveur public de telle sorte que le certificat de classe de dispositif est disponible publiquement.
PCT/EP2022/062674 2022-05-10 2022-05-10 Certification de clé de plateforme avec racine de confiance de classe de dispositif WO2023217357A1 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
PCT/EP2022/062674 WO2023217357A1 (fr) 2022-05-10 2022-05-10 Certification de clé de plateforme avec racine de confiance de classe de dispositif

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/EP2022/062674 WO2023217357A1 (fr) 2022-05-10 2022-05-10 Certification de clé de plateforme avec racine de confiance de classe de dispositif

Publications (1)

Publication Number Publication Date
WO2023217357A1 true WO2023217357A1 (fr) 2023-11-16

Family

ID=81984597

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2022/062674 WO2023217357A1 (fr) 2022-05-10 2022-05-10 Certification de clé de plateforme avec racine de confiance de classe de dispositif

Country Status (1)

Country Link
WO (1) WO2023217357A1 (fr)

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP3444999A1 (fr) * 2017-08-14 2019-02-20 Nxp B.V. Procédé pour générer une paire de clés publiques/privées et un certificat de clé publique pour un dispositif d'internet des objets
US20210126801A1 (en) * 2019-10-25 2021-04-29 John A. Nix Secure configuration of a secondary platform bundle within a primary platform

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP3444999A1 (fr) * 2017-08-14 2019-02-20 Nxp B.V. Procédé pour générer une paire de clés publiques/privées et un certificat de clé publique pour un dispositif d'internet des objets
US20210126801A1 (en) * 2019-10-25 2021-04-29 John A. Nix Secure configuration of a secondary platform bundle within a primary platform

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
RICHARDSON SANDELMAN SOFTWARE WORKS M: "A Taxonomy of operational security considerations for manufacturer installed keys and Trust Anchors draft-richardson-t2trg-idevid-considerations-03; draft-richardson-t2trg-idevid-considerations-03.txt", no. 3, 22 February 2021 (2021-02-22), pages 1 - 26, XP015144736, Retrieved from the Internet <URL:https://tools.ietf.org/html/draft-richardson-t2trg-idevid-considerations-03> [retrieved on 20210222] *

Similar Documents

Publication Publication Date Title
CN110770695B (zh) 物联网(iot)设备管理
US11757662B2 (en) Confidential authentication and provisioning
CN108092776B (zh) 一种基于身份认证服务器和身份认证令牌的系统
US11070542B2 (en) Systems and methods for certificate chain validation of secure elements
US8285989B2 (en) Establishing a secured communication session
CN110677240A (zh) 通过证书签发提供高可用计算服务的方法及装置
EP2204008A1 (fr) Approvisionnement de justificatif d&#39;identité
JP2015149722A (ja) 証明書生成装置および方法
US11777743B2 (en) Method for securely providing a personalized electronic identity on a terminal
US20210392004A1 (en) Apparatus and method for authenticating device based on certificate using physical unclonable function
CN113569210A (zh) 分布式身份认证方法、设备访问方法及装置
CN117397198A (zh) 绑定加密密钥证明
CN117640096A (zh) 更新设备证书的方法和用于驱动该方法的设备
US20240187262A1 (en) Encrypted and authenticated firmware provisioning with root-of-trust based security
EP4324159A1 (fr) Inscription racine de confiance sécurisée et gestion d&#39;identité de dispositifs intégrés
WO2023217357A1 (fr) Certification de clé de plateforme avec racine de confiance de classe de dispositif
US11972032B2 (en) Authentication of an original equipment manufacturer entity
US20240195641A1 (en) Interim root-of-trust enrolment and device-bound public key registration
US20230155842A1 (en) Method and apparatus for certifying an application-specific key and for requesting such certification
CN112925543A (zh) 一种密码芯片嵌入式应用升级方法及装置
JP2017183932A (ja) 暗号化通信チャネル確立システム、方法、プログラム及びコンピュータ読取り可能なプログラム記録媒体

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 22728789

Country of ref document: EP

Kind code of ref document: A1