How to provision credentials on a device

Abstract

Device (200) contains the device secret key (K1pr) of the public and private asymmetric key pair (K1pub, K1pr). This method is performed by device (200). - The process of receiving device credentials from a credential provider in encrypted format, - A process of internally determining information regarding the current configuration of the device (200), - A step of generating device authentication information based on determined information about the current configuration of the device, - A step of generating a decryption key (K4i) based on the device secret key (K1pr) and the generated device authentication information, - The process includes decrypting the received device credentials in encrypted form using a decryption key and provisioning the device credentials to the device (200).

Description

Technical Field

[0001] This disclosure relates to a method of provisioning security credentials to a device.

Background Art

[0002] In cryptography, security credentials or credentials are security data or assets (e.g., symmetric secret keys, asymmetric keys, device certificate chains, public keys of certificate authorities for authenticating servers, confidential configuration data, license data, etc.) that can be configured within a device or server. Security credentials can enable the identification and authentication of parties such as users or devices. Credentials can be used in authentication procedures to control access to a network, cloud computing platform, information, or any other resource and / or to establish mutually authenticated secure communication with another party, e.g., with another party or a cloud system. For example, credentials can include a user identifier such as a username and a secret password or personal identification number (PIN), biometric data, or an API key, or a bearer token for accessing a resource, or an asymmetric key for signing a possession proof token for accessing a specific resource, or an encryption key (e.g., an asymmetric key pair or a shared symmetric key), and / or a combination with a password.

[0003] In the process of provisioning security credentials to a device, the security credentials are securely installed on the device. Usually, the security credentials are stored in a secure element such as a chip or a system-on-chip (SoC) of the device.

[0004] Consider an example of a smartphone that includes a phone device manufactured by a phone device manufacturer and a SIM card provided by a telecommunications carrier. The SIM card is a secure element that securely stores the credentials that enable the smartphone to access a telecommunications network.

[0005] Due to security reasons, devices are usually provisioned with security qualification information at a secure production site of the device manufacturer.

[0006] Therefore, the process of provisioning security qualification information to a device requires that the device should include a secure element such as a security SoC (System on Chip) or a chip for storing the security qualification information, and that the device manufacturer should have a secure production site.

[0007] However, there is a need to provision security qualification information to devices that have no secure elements at all, such as IoT (Internet of Things) devices or objects, and / or devices produced by device manufacturers that do not have a secure production site.

Summary of the Invention

[0008] The present disclosure is a method for provisioning device qualification information to a device, which is executed by the device, wherein the device includes a device private key of a pair of a public asymmetric key and a private asymmetric key, and the method includes - receiving device qualification information from a qualification information provider in an encrypted form; - internally self-determining information regarding the current configuration of the device; - generating device authentication information based on the determined information regarding the current configuration of the device; - generating a decryption key based on the device private key and the generated device authentication information; - decrypting the device qualification information received in the encrypted form using the decryption key to provision the device with the device qualification information.

[0009] If the device's current or actual configuration is not what is expected, the decryption key will be incorrect, and therefore the decryption process will not explicitly output device credentials. The process may output erroneous or incorrect decrypted data.

[0010] In one embodiment, the step of generating a decryption key is: - The process involves the device and the credential provider agreeing on key data by executing a key agreement protocol using the public key and device secret key from the credential provider's public asymmetric key and secret asymmetric key pair, -Includes the step of deriving a decryption key from agreed key data using a key derivation function that takes the generated device authentication information as input.

[0011] For example, agreed-upon key data may include a symmetric key. Then, using the generated authentication information as input, a decryption key can be derived from this agreed-upon key.

[0012] Advantageously, the method may further include a step of securely storing the device credentials in the device after the decryption step. In other words, the step of decrypting the device credentials received from the credential provider in encrypted form with a decryption key is performed before securely storing the device credentials in the device. After the decryption step, the credentials can be stored in persistent memory protected, for example, by hardware means and / or by encryption using the device's private key.

[0013] In one embodiment, in the step of receiving device credentials in an encrypted form, the device further receives an authentication tag, The decryption process includes authentication of device credentials received based on the authentication tag. - If authentication fails, an error message should be displayed. - If authentication is successful, this includes outputting the decrypted device credentials.

[0014] In one embodiment, the device includes a security chip that stores a device secret key, and the security chip is - A process of internally determining information about the current configuration of the device, - The process of generating device authentication information, - The process of generating a decryption key, - Perform the decryption of the received device credentials.

[0015] A security chip or SoC may include hardware and software. The security chip may determine information regarding the current actual configuration of the device. To this end, the security chip may internally determine information regarding the current actual configuration of the hardware and software on the security chip.

[0016] In one embodiment, the security chip is a master chip, and the device further includes one or more slave chips. The process of internally determining information about the current configuration of the device, and the process of generating device authentication information, - A process performed by the master chip and one or more slave chips to internally determine information regarding the current configuration of the chip, - A step of generating chip authentication information based on determined information regarding the current configuration of the chip, performed by the master chip and each of the one or more slave chips, - A process performed by each slave chip to transmit chip authentication information generated from the slave chip to the master chip, -Includes the step of calculating device authentication information based on the chip authentication information of the master chip and one or more slave chips.

[0017] If the device includes a master chip and one or more slave chips, device authentication information may arise from the current actual configuration of the master chip and the slave chips. The master chip may play the role of calculating device authentication information based on the chip authentication information received from each slave chip and the chip authentication information determined for the master chip itself.

[0018] Advantageously, the method further includes a step of authenticating a device based on device credentials in order to access resources or to establish a connection with another party. Thus, the device can use the device credentials to access resources (e.g., networks, cloud computing platforms, information, or any other resources) and / or establish a connection with another party (e.g., a device, a system, a cloud system, etc.).

[0019] This disclosure also relates to a method performed by a credential provider for provisioning device credentials to multiple devices, - A step of receiving multiple digital certificates for multiple devices, wherein each digital certificate includes information for identifying one device and the public key of a public key and private key pair assigned to that device. - A step of receiving predetermined expected device authentication information based on the configuration profiles of multiple devices, -For each device, A step of generating an encryption key based on the public key of the device and the expected device authentication information, A step of encrypting the device credentials of the device using an encryption key, The process includes the step of transmitting encrypted device credentials to the corresponding device.

[0020] In one embodiment, the method further includes the step of generating device credentials for each of a plurality of devices.

[0021] In one embodiment, the step of transmitting device credentials in an encrypted format to a corresponding device is: - The process of transmitting the device credentials of the corresponding device in an encrypted format to a credential management system (for example, the device manufacturer's credential management system), - The process includes transmitting the device credentials from the credential management system to the corresponding device in an encrypted form via a communication network, such as a local area network or a local communication channel.

[0022] Encrypted device credentials for multiple devices can be sent to a credential management system. The credential management system can be located in the device manufacturing plant. Therefore, the transmission of device credentials to devices can be performed at the device manufacturing plant during device production.

[0023] In another embodiment, the step of transmitting device credentials in an encrypted form to a corresponding device is performed by the credential provider. - The process of establishing a connection between the credential provider and the corresponding device via a communication network, - The process includes transmitting device credentials in encrypted form to the corresponding device via an established connection.

[0024] The above transmission modes for device credentials can be performed after the device is produced, when the device is being used in a user environment, for example, when the device is connected to a local area network such as a home network or corporate network.

[0025] This disclosure also, - A device configured to perform the steps of the previously defined method, - A credential provider configured to perform the steps of the previously defined method, - A computer program which, when executed by a computer, includes instructions that cause the computer to perform steps of a method performed by a device, - Relating to a computer program which, when executed by a computer, includes instructions that cause the computer to perform steps in a method performed by a credential provider. [Brief explanation of the drawing]

[0026] Other features, purposes, and advantages of this disclosure will become clearer by reading the detailed description of non-limiting embodiments made with reference to the accompanying drawings.

[0027] [Figure 1] This document describes a system for provisioning devices using security credentials, according to one embodiment.

[0028] [Figure 2] A functional block diagram of a credential provider according to one embodiment is shown.

[0029] [Figure 3] A flowchart of a preliminary step in a method for provisioning security credentials to a device, according to one embodiment, is shown.

[0030] [Figure 4] A flowchart of the steps for a method of provisioning security credentials to a device, performed by a credential provider, according to one embodiment, is shown.

[0031] [Figure 5A] Two modes of transmission of security credentials from a credential provider to a device, according to one embodiment, are schematically represented. [Figure 5B]Two modes of transmission of security credentials from a credential provider to a device, according to one embodiment, are schematically represented.

[0032] [Figure 6] A flowchart of the steps of a method for provisioning security credentials to a device, performed by the device, according to one embodiment, is shown.

[0033] [Figure 7] A schematic representation of a device including a master chip and two slave chips according to another embodiment.

[0034] [Figure 8] A flowchart of the process for receiving and processing device credentials, as performed by the device shown in Figure 7, according to another embodiment, is shown. [Modes for carrying out the invention]

[0035] This disclosure relates to a system for provisioning security credentials to multiple devices or systems 200. The system includes multiple devices or systems 200 and a credential provider 100. For clarity, Figure 1 shows only one device or system 200.

[0036] Device security credentials or a set of credentials include any security data or assets configured within the device (e.g., symmetric private keys, asymmetric keys, device certificate chains, public keys of a certificate authority for authenticating a server, sensitive configuration data, license data, etc.). It may include data that enables the identification and authentication of the device. Credentials can be used in authentication procedures to control the device's access to networks, cloud computing platforms, information, or any other resources, and / or to establish communication with another device or system. Credentials may include machine-readable encryption keys (e.g., asymmetric key pairs or shared symmetric keys), digital certificates, and / or passwords.

[0037] In this disclosure, the term “key” is used to specify a cryptographic or digital key, which may be, for example, a secret symmetric key, a public asymmetric key, or a secret asymmetric key.

[0038] Multiple devices 200 are produced, for example, by a device manufacturer 500. The term “device” should be interpreted broadly to encompass any computing device, subsystem, or system. For example, a device could be an IoT device, or a set of interconnected IoT devices, a machine tool, an automotive ECU, a train control unit, or a subsystem within a vehicle (e.g., a car, train, airplane, etc.) which may include different components connected via wired or wireless communication protocols. In one embodiment, devices 200 could be a series of devices manufactured according to the same device template. They may be manufactured and configured to conform to a predetermined configuration profile, which is a template configuration or base configuration. This may include information about hardware components and software components or applications installed on the device 200, such as states and / or characteristics.

[0039] First Embodiment

[0040] In the first embodiment, the device 200 includes a security chip, i.e., a system-on-chip (SoC) 300.

[0041] The security chip 300 includes hardware components (e.g., processing cores, memories, ports, interfaces, etc.) and software components or applications. The software components may include, for example, - one or more non-secure applications "App#n", and - one or more secure or trusted applications "TA#n", and - a main operating system (OS) "Rich OS", e.g., Linux (copyright) or FreeRTOS (copyright), and - a security task, e.g., a secure OS "Trusted OS" used to execute OP-TEE (copyright) or ARM TFM (copyright).

[0042] The security chip 300 consists of a pair of a public asymmetric key and a secret asymmetric key K1 pub , K1 pr . The digital certificate or public key certificate proves the validity of the public key K1 pub . This digital certificate includes information about the public key K1 pub , information about the identity of its owner, and the digital signature of the entity that verified the content of the certificate. When the security chip 300 is installed in the device 200, the pair of public and secret keys K1 pub , K1 pr is assigned or associated with the device 200. The information about the identity of the owner of the public key K1 pub may include a chip identifier that becomes a device identifier when the security chip 300 is installed in the device 200. The secret key K1 pr is stored within the security chip 300, e.g., within the secure persistent memory 310 of the security chip 300. Optionally, the public key K1 pubThe digital certificate and its associated data are also stored in the security chip 300, for example, in the secure memory 310.

[0043] The security chip 300 further includes an authentication module 320, a security module 330, and an input / output interface or port 340.

[0044] The input / output interface 340 is configured to transmit and receive data. In one embodiment, it may be connected to a network or communication interface (not shown) of device 200 to connect device 200 to a communication network. This network may be the Internet 800 and / or a local area network. In particular, device 200 is configured to receive security credentials in encrypted form via the input / output interface 340, as described later.

[0045] The authentication module 320 is responsible for internally determining or self-determining data or information that describes the current or actual configuration of the device 200, and for generating device authentication information based on the determined data or information.

[0046] In the first embodiment, the configuration of device 200 includes the configuration of security chip 300, which may include the hardware components and software components or application state and / or characteristics of security chip 300. In one embodiment, authentication module 320 generates chip authentication information by implementing the specification of Document PSA Certification Authentication API 1.0, No. ARM IHI 0085. Alternatively, authentication module 320 may use a different authentication function.

[0047] The security module 330 is responsible for performing security or cryptographic tasks (e.g., encryption, decryption, digital signature calculation, digital signature verification, etc.). It has access to the secure memory 310, which may be included within the security module 330.

[0048] In this disclosure, the security module 330 includes a key generator 331 and a decryption block 332.

[0049] The key generator 331 generates the private key K1 of device 200. pr The key generator 331 is configured to generate a decryption key based on the device authentication information determined by the authentication module 320. In one embodiment, the key generator 331 includes a key agreement block 331A and a key derivation block 331B. The key agreement block 331A is configured to execute a key agreement function or protocol so that the device 200 and the credential provider 100 agree on key data. The key derivation block 331B is configured to derive a decryption key from the agreed key data by using a key derivation function and using the device authentication information determined by the authentication module 320 as input.

[0050] The key agreement block 331A is optional. In another embodiment, the key derivation block 331B is the private key K1 of device 200. pr Therefore, the system can be configured to derive a decryption key by using a key derivation function and by using device authentication information determined internally by the authentication module 320 as input.

[0051] The decryption block 332 is configured to decrypt the security credentials received in encrypted form using the decryption key generated by the key generator 331.

[0052] The credential provider 100 has the primary function of encrypting security credentials for device 200 and providing the security credentials to device 200 in an encrypted format. It may be, for example, a server, computing system, or cloud computing platform.

[0053] In the embodiment shown in Figure 2, the credential provider 100 includes a first receiving module 110 for receiving a digital certificate assigned to device 200, a second receiving module 120 for receiving expected device authentication information or reference device authentication information predetermined based on the expected or reference configuration of device 200, a credential generator 130 for generating security credentials for device 200, an encryption module 140 for encrypting the generated security credentials, and a transmission module 150 for transmitting the security credentials to device 200 in encrypted form.

[0054] The credential provider 100 may include a network interface 160 for connecting to a communication network, such as the Internet 800.

[0055] The first receiving module 110 receives the public key K1 of device 200. pub The digital certificate, more precisely, the public key K1 of the security chip 300 installed on device 200. pub It is configured to receive. In one embodiment, the digital certificate may be transmitted by the manufacturer 700 of the chip 300 via a communication network, for example, network 800. However, the digital certificate can be transmitted to the credential provider 100 using any other transmission mode.

[0056] The second receiving module 120 receives DVC_ATT_INFO from an external source (e.g., the manufacturer of device 200). expThe system is configured to receive expected authentication information or reference predetermined device authentication information for device 200, referred to as DVC_ATT_INFO. This external source is different from device 200. In one embodiment, the expected device authentication information is predetermined by the manufacturer 500 of device 200, for example, based on a template configuration or reference configuration or configuration profile of device 200. Device 200 is manufactured and configured by the manufacturer 500 to conform to a configuration profile that may be created by the manufacturer 500 of device 200, for example. In one embodiment, the expected device authentication information or reference device authentication information DVC_ATT_INFO of device 200 is exp This information may be transmitted by an external source (e.g., device manufacturer 500) via a communication network, such as network 800. However, any other transmission mode may also be used. Expected or reference device certification information for device 200 may be received in relation to a global device identifier that identifies a group or series of devices 200 manufactured and / or configured according to a corresponding configuration profile.

[0057] Expected device authentication information or reference device authentication information DVC_ATT_INFO for device 200 exp This can be determined in advance before provisioning credentials to device 200.

[0058] In one embodiment, the credential provider 100 has a first memory or database 111 for storing received digital certificates and expected device authentication information or reference device authentication information DVC_ATT_INFO for device 200. exp It includes a second memory 121 for storing the following.

[0059] The credential generator 130 is configured to generate security credentials for device 200. In one embodiment, the credential generator 130 is configured to generate security credentials for each public key certificate received by the first receiving module 110. As described above, the security credentials for device 200 may include one or more encryption keys (e.g., asymmetric key pairs or symmetric keys), digital certificates and / or passwords. Device 200 may further include memory or a database 131 for storing the security credentials generated for device 200.

[0060] The encryption module 140 has the function of encrypting generated security credentials, and the security credentials generated for a particular device are encrypted in a specific manner for that device, as described below. It comprises a key generator 141 and an encryption block 142.

[0061] The key generator 141 is configured to generate a specific encryption key for each device 200 based on the device's public key or public key certificate and the expected device authentication information or reference device authentication information received for multiple devices 200. In one embodiment, the key generator 141 may include a key agreement block 141A and a key derivation block 141B. The key agreement block 141A is configured to execute a key agreement function or protocol so that each device 200 and the credential provider 100 agree on key data. The key derivation block 141B is configured to execute a key derivation function from the agreed key data and derive an encryption key unique to each device 200 by using the expected device authentication information of the device 200 as input.

[0062] The key agreement block 141A is optional. In another embodiment, the key derivation block 141B is the public key K1 of device 200. pub From there, it can be configured to derive an encryption key by executing a key derivation function and using expected device authentication information or reference device authentication information as input.

[0063] The encryption block 142 is configured to encrypt the security credentials of each device 200 with a specific encryption key generated by the key generator 141 of that device 200.

[0064] For example, the key agreement function or protocol used by device 200 and credential provider 100 is specified in the standard document NIST Special Publication 800-56A, Revision 3, "Recommendation for Pair-Wise Key-Establishment Schemes Using Discrete Logarithm Cryptography." Alternatively, a quantum key agreement function may be used.

[0065] For example, the key derivation function used by device 200 and credential provider 100 is specified in the standard document NIST Special Publication 800-108r1, "Recommendation for Key Derivation Using Pseudorandom Functions." Other types of key agreement and key derivation functions can also be used.

[0066] The transmission module 150 is configured to transmit encrypted security credentials provided in the output of the encryption block 142 to the corresponding device 200. The encrypted security certificate can be delivered to the corresponding device 200 through communication between the credential provider 100 and each device 200, or, as described later, through a credential management system or device 900 that receives credentials from the device 200 and distributes them to the corresponding device 200.

[0067] In one embodiment, the credential provider 100 has a public key and private key pair K2 pub , K2 priv It is provisioned. The digital or public key certificate is the public key K2 pubThis proves the validity of the device 200i, public key K2 pub Access and / or store the digital certificate.

[0068] Next, a method for provisioning device credentials to multiple devices 200 according to the first embodiment will be described. For clarity, the devices are referred to as "200i" (1 ≤ i ≤ N), where i represents an index that identifies a particular device among N devices.

[0069] This method includes, according to the first embodiment, a process performed by the credential provider 100 for generating device credentials and transmitting said device credentials to device 200i, and a process performed by device 200i for receiving and processing the device credentials.

[0070] In the preliminary stage PP shown in Figure 3, device 200i (1 ≤ i ≤ N) is manufactured and configured. The preliminary stage PP may include the preliminary steps described below.

[0071] In process PP_1, the chip or SoC 300i (1≦i≦N) is manufactured in a secure chip production facility. During the manufacturing of the chip 300i, each chip 300i is assigned a specific public key and private key pair K1 pub,i , K1 pr,i The public and private key pair K1 is provisioned. pub,i , K1 pr,i For example, a Certificate Authority (not shown) generates a public key certificate or digital certificate. In other words, a public key and private key pair K1 pub,i , K1 pr,i This is specifically assigned to chip 300i. Private key K1 pr,i , and optionally K1 pub,i And / or the certificate is stored in the secure memory 310i of the chip 300i.

[0072] In process PP_2, the chip 300i is mounted onto the device 200i during its manufacturing. In this embodiment, one chip 300i is mounted on each device 200i.

[0073] In step PP_3, the digital certificates or public key certificates of multiple devices 200i (1 ≤ i ≤ N) are transmitted to the credential provider 100 by an entity of the chip manufacturer 700, for example, via the network 800. For example, a bundle of certificates containing the certificates of all devices 200i (1 ≤ i ≤ N) is transmitted to the credential provider 100 via the communication network 800. However, the certificates may be transmitted to the credential provider 100 by any other means.

[0074] In process PP_4, during the manufacturing of device 200i, chip 300i may be configured to conform to a predetermined configuration profile (or reference configuration). The configuration of chip 300i may be performed partly at the production site of chip 300i and partly at the manufacturing plant of device manufacturer 500. In this embodiment, this configuration profile of chip 300i can be considered as the configuration profile of device 200i.

[0075] In step PP_5, the entity of device manufacturer 500 uses DVC_ATT_INFO based on the configuration profile of device 200i. exp Determine or calculate the expected device authentication information or reference device authentication information, known as DVC_ATT_INFO. For this purpose, this entity of device manufacturer 500 may use authentication functions such as those specified in Document PSA Certification API 1.0, No. ARM IHI 0085. Expected device authentication information or reference device authentication information DVC_ATT_INFO expThis could be, for example, a tag formatted according to the PSA Certificate Authentication API, document number ARM IHI 0085, or the IETF Entity Attestation Token (EAT), Working Group RATS, draft-ietf-rats-eat-19, published on December 19, 2022.

[0076] In process PP_6, the device manufacturer 500 provides the expected device certification information or the reference device certification information DVC_ATT_INFO exp This expected device authentication information or reference device authentication information DVC_ATT_INFO is sent to the credential provider 100. exp This applies to all devices 200i (1 ≤ i ≤ N) including chip 300i configured according to a predetermined configuration profile or standard configuration.

[0077] Next, with reference to Figure 4, a process for generating and transmitting device credentials performed by the credential provider 100 according to one embodiment will be described.

[0078] In step S1, the credential provider 100 receives a bundle of public key certificates or digital certificates for device 200i (1 ≤ i ≤ N) from the chip manufacturer 700. Each digital certificate contains information to identify a specific device 200i, including chip 300i, for example, a chip or device identifier and a public and private key pair K1 assigned to that chip 300i or device 200i. pub,i , K1 pr,i This includes the device's public key.

[0079] In step S2, the credential provider 100 receives expected or reference credential information for device 200i (1 ≤ i ≤ N) from the device manufacturer 500.

[0080] Next, the credential provider 100 performs steps S3 to S5 for each device 200i (1 ≤ i ≤ N).

[0081] In step S3, the credential provider 100 receives the device public key K1 of the device 200i in step S1. pub,i And, the expected device authentication information or reference device authentication information DVC_ATT_INFO received in process S2. exp Based on this, the encryption key K4 is unique to device 200i. i Generates the digital certificate of device 200i. Optionally, the credential provider 100 may verify the digital certificate of device 200i before performing step S3. If the certificate is valid, the encryption key K4 i This is generated. If the digital certificate is not valid, the encryption key K4 i It is not generated, and an error is generated.

[0082] In one embodiment, the step S3 for generating the encryption key K4i includes a first step S30i for key agreement and a second step S31i for key derivation.

[0083] In the key agreement process S30i, the credential provider 100 determines the key data agreed upon by the credential provider 100 and the device 200i. In one embodiment, the credential provider uses a key agreement function to determine the public key K1 of the device 200i. pub,i and the private key K2 of credential provider 100 pr The system generates a key K3i specifically for device 200i, using the inputs or based on them. For example, the key agreement function is specified in the standard NIST Special Publication 800-56A, revision 3, "Recommendation for Pair-Wise Key-Establishment Schemes Using Discrete Logarithm Cryptography." Alternatively, the key agreement function may be a Diffie-Hellman key agreement function.

[0084] In this embodiment, the consensus key K3i is a symmetric key.

[0085] Alternatively, the agreed-upon key data may include a public asymmetric key and a private asymmetric key pair, along with a public key certificate.

[0086] In the key derivation process S31i, the credential provider 100 receives the expected device authentication information DVC_ATT_INFO exp A key derivation function that takes the agreed key data, in this case K3i, is used to derive a specific encryption key K4i. For example, a key derivation function is defined in the standard NIST Special Publication 800-108r1, "Recommendation for Key Derivation Using Pseudorandom Functions". However, any other arbitrary key derivation function can also be used. In this embodiment, key K4i is a symmetric key.

[0087] In step S4, the credential generator 130 generates credentials or security credentials, specifically referred to as "device credentials" for device 200i. For example, the credential provider 100 generates device credentials for each certificate received and / or stored in step S1. The generated credentials are associated with the digital certificate.

[0088] In step S5, the encryption module 140 encrypts the device credentials generated for device 200i with the corresponding encryption key K4i generated for device 200i.

[0089] Optionally, in step S5, an authenticated encryption algorithm is used for encryption that simultaneously guarantees the confidentiality and authenticity of the data (in this case, device credentials). Authenticated encryption may be authenticated encryption with associated data (AEAD), such as AES CCM mode encryption, or it may be an Encrypt-then-MAC (EtM) approach using, for example, the Advanced Encryption Standard (AES) and a hash-based message authentication code (HMAC). This type of encryption makes it possible to provide both authentication and confidentiality of device credentials. In this case, the encryption module 142 may output the device credentials and an authentication tag in encrypted form. For example, when the Encrypt-then-MAC (EtM) approach is used, the authentication tag may be the HMAC of the encrypted device credentials. The key required for authenticated encryption may be generated based on, for example, key K4i. The encryption itself may be performed by another key generated based on, for example, key K4i.

[0090] Processes S3 to S5 are performed for each device 300i (1 ≤ i ≤ N).

[0091] In step S6, the credential provider 100 transmits the device credentials in encrypted form to the corresponding device 200i. As shown in Figures 5A and 5B, the transmission of the device credentials in encrypted form from the credential provider 100 to the device 200i can be performed according to different modes.

[0092] The first transmission mode can be advantageously used while the device 200i is in the device manufacturing plant 930. This device manufacturing plant 930 may include a credential management system 900. The credential management system or device 900 may be a server, a mobile phone, or any other communication system or device.

[0093] According to the first transmission mode shown in Figure 5A, the credential provider 100 transmits, for example, a bundle of device credentials, including encrypted credentials for multiple devices, preferably for all devices 200i (1 ≤ i ≤ N), to the credential management system 900 via the network 800 or by any other transmission means. In one embodiment, the transmission of the certificate bundle can be performed upon request from the credential management system 900. The credential management system 900 then transmits or delivers the device credentials in encrypted form to the corresponding devices 200i via communication between the credential management system 900 and each device 200i, for example, via a local area network or via a local or air-gap (proximity) communication channel 920. This transmission between the credential management system 900 and each device 200i can be advantageously performed while the devices 200i are being manufactured at the device manufacturing plant 930. Since the credential management system 900 is located in the device manufacturing plant 930, this transmission mode avoids any connection via external communication networks while the devices are being manufactured, and therefore avoids undesirable interruptions to device manufacturing, for example, if the external network becomes temporarily unavailable due to a failure.

[0094] A second transmission mode can be used after production when device 200i is in use. For example, device 200i can connect to and / or integrate with a local area network 1000_i, or can connect directly to network 800 (e.g., device 200_1 in Figure 5B) as shown in Figure 5B. The local area network may be a home network or a corporate network. It may be connected to network 800. In the second transmission mode shown in Figure 5B, the credential provider 100 establishes communication with each device 200i via network 800, identifies the device 200i, and transmits the device credentials of device 200i to device 200i in encrypted form via the established communication. Optionally, a secure connection can be established between device 200i and the credential provider 100 to enhance security with encrypted communication. This communication may be established at the request of device 200i, for example, when device 200i is initiated or put into use on-site (i.e., within the user environment), typically by the end user or customer, and connected to network 800. After integration within the local area network, device 200i may be started up, and during the startup procedure, it may request to establish communication with credential provider 100 through network 800 to obtain its security credentials.

[0095] A process for receiving and processing device credentials, performed by each device 200i according to one embodiment, will be described with reference to Figure 6.

[0096] In the first step S10, device 200i receives its security credentials or device credentials in encrypted form from credential provider 100. If authenticated encryption was used to encrypt the device credentials, an authentication tag is also received in step S10.

[0097] In one embodiment, encrypted device credentials can be received directly from the credential provider 100 after communication between the credential provider 100 and the device 200i has been established. Optionally, the device 200i and the credential provider 100 may perform mutual authentication, for example, using their respective key pairs, before establishing communication.

[0098] In another embodiment, device credentials in encrypted form are received from a credential provider 100 via a credential management system 900, preferably via a local area network or local communication channel between the device 200i and the credential management system 900. If the credential management system 900 is located in the manufacturing plant of the device 200i, the step S10 of receiving device credentials in encrypted form can be performed in the manufacturing plant during the manufacturing of the device 200i.

[0099] In step S11, device 200i internally determines information regarding its current actual configuration. The determination of information regarding the actual configuration of device 200i is a self-determination performed by device 200i itself. To this end, in the first embodiment, the authentication module 320 of chip 300i internally determines and collects data or information regarding the actual current configuration of chip 300i. The step S11 of internally self-determining information regarding the current configuration of device 200i may be performed at the time of the device's boot process (i.e., during the series of operations performed from the moment device 200i is turned on until it is ready for use). Furthermore, the self-determination of information regarding the current configuration of device 200i may be performed and / or updated in each boot process of device 200i. For example, the data may include measurements of different software components performed by Secure Boot during the initialization phase or when requested, the lifecycle state of the chip or SoC "SoC LCS" (e.g., assembly test, provisioning, field_secured, field_return_analysis), configuration information about one or more hardware components of the chip or SoC (e.g., the state of a JTAG port and / or another hardware interface indicating whether it is closed (or locked), open (or unlocked), or protected, an indication of whether Secure Boot is activated or not), or any specific and application-specific state of the device, such as the physical location area provided by GPS, specific device data, and the results of integrated data of dynamic security measurements such as heap usage, stack usage, and runtime timing.

[0100] Therefore, in step S11, the authentication module 320 may determine a data structure that includes data describing the current or actual configuration of the hardware and software of the chip 300i. Expected authentication information or reference authentication information is generated by an external source, for example, the device manufacturer 500, based on the same type of data structure. In other words, the data self-determined by the authentication module 320 of the chip 300i and the expected authentication information or reference predetermined authentication information DVC_ATT_INFO exp The data used by external source 500 to generate the output is either of the same type or based on the same data structure, but they are different from each other.

[0101] In step S12, the authentication module 320 uses, for example, the PSA certification API 1.0, document number ARM IHI 0085, to determine the current, actual, or real device authentication information DVC_ATT_INFO based on a portion of the data or information determined in step S11. real Generates.

[0102] Self-determined information regarding the current configuration of device 200i (determined in step S11) and current device authentication information DVC_ATT_INFO real The (determined in step S12) is favorably held on device 200i. These are not shared with or transmitted to another device or system, such as the credential provider 100. The current device authentication information DVC_ATT_INFO on the device 200i side real This is the specified device authentication information DVC_ATT_INFO on the credential provider 100 side. exp It is different.

[0103] In step S13, the key generation unit 331 generates the device secret key K1 pr The authentication module 320 then determines the device authentication information DVC_ATT_INFO internally. real A decryption key is generated based on the above. In this embodiment, the decryption key is a symmetric key that should be identical to the encryption key K4i.

[0104] In one embodiment, step S13 includes a key agreement step S130, in which key agreement block 331A executes a key agreement function or protocol to determine the key K3i agreed upon by the credential provider 100 and device 200i. More precisely, device 200i uses the key agreement function to determine the public key K2 of the credential provider 100. pub and the private key K1 of device 200i pr,i The key K3i is generated by taking (or based on) the inputs. The key agreement function used by the chip 300i is, advantageously, the same as that used by the credential provider 100.

[0105] Next, in step S131, device 200i obtains the device authentication information DVC_ATT_INFO determined by the authentication module 320 in step S12 from the agreed key K3i. real The decryption key is derived by executing a key derivation function using the input. The key derivation function used by device 200i may be the same as the one used by credential provider 100.

[0106] The key agreement step S130 is optional. In another embodiment, the key derivation block 331B is the private key K1 of device 200i. pr,i The key derivation function is executed directly from there, and the device authentication information DVC_ATT_INFO determined by the authentication module 320 in step S12 is obtained. real It can be configured to derive a decryption key by using as input.

[0107] Next, the process includes a decryption step S14, which is performed by the decryption module 332, to decrypt the device credentials received in encrypted form using the decryption key K4i.

[0108] If authenticated encryption is used to encrypt device credentials, the decryption module 332 may check the validity of the authentication tag in step S140. For this purpose, the decryption module 332 may generate the authentication tag using the encryption / decryption key K4i used by the credential provider 100.

[0109] If the authentication tag is valid, in step S141, the decryption module 332 decrypts the received device credentials with key K4i and outputs the decrypted device credentials.

[0110] If the authentication tag is not valid, decryption will fail, and the decryption module 332 may output an error in step S142.

[0111] In any case, if the actual configuration of device 200i, as determined by device 200i itself, does not match, for example, the expected configuration or reference configuration of device 200i, or the configuration profile predetermined by device manufacturer 500, the decryption key determined in step S13 is incorrect, and as a result, the decryption step S14 cannot decrypt the device credentials.

[0112] After decrypting the device credentials, the process proceeds to step S15, which securely stores the device credentials in device 200i. In one embodiment, the device credentials are stored in the secure storage system or secure memory 350 of chip 300i, typically persistent memory, e.g., memory 350 or memory 310. This secure memory, which stores the provisioned device credentials, may be isolated by specific hardware and / or specific encryption. The device credentials may be re-encrypted using, for example, the secret key K5i of device 200i stored in memory 310 and then stored in memory 350. Secure memory 350 may only be accessible by modules, applications, or software configured to later use the device credentials (e.g., authentication applications and / or network control access applications).

[0113] Once the device credentials in the security chip 300i are decrypted and stored, the device credentials are provisioned to the device 200i.

[0114] Once device credentials are provisioned, device 200i can use the device credentials, for example in authentication procedure S16, to control access to networks, cloud computing platforms, information, websites, or any other resources, and / or to establish communication with another party, device, or system, as is well known to those skilled in the art.

[0115] The key agreement process performed by the credential provider 100 and device 200i is optional. Alternatively, the encryption key is the public key K1 of device 200i. pub,i and the private key K2 of credential provider 100 pr The decryption key may be derived by credential provider 100 from the private key K1 of device 200i. pr,i and the public key K2 of credential provider 100 pub It can be derived from device 200i or chip 300i. In that case, the encryption key and decryption key may be the same secret symmetric key.

[0116] Second Embodiment

[0117] The second embodiment is based on the first embodiment, differing only in the aspects described below.

[0118] In the second embodiment, the device 200 includes one master security chip 300 and one or more slave chips 400_a, 400_b, ... The master security chip 300 is the same as the security chip 300 (or 300i) in the first embodiment. Each slave chip 400_a, 400_b, ... is provided with an authentication module 410_a, 410_b, ...

[0119] Figure 7 shows an exemplary example of device 200i, which includes a master chip 400i and two slave chips 300i_a and 400i_b. For clarity, the master chip 300i is schematically represented in a simplified manner.

[0120] Each of the one or more slave chips 400i_a, 400i_b, ... includes hardware and software components (e.g., applications, trusted applications, main OS, secure OS, etc.). The authentication modules 420i_a, 420i_b, ... of the slave chips 400i_a, 400i_b, ... are similar to the authentication module 320i of the master security chip 300i. They are configured to internally determine data or information describing the current or actual configuration of the hardware components and / or software components or applications of the corresponding slave chips 400i_a, 400i_b, ... and to generate chip or SoC authentication information SoC_ATT_INFO_a, SoC_ATT_INFO_b, ... for the slave chips 400i_a, 400i_b, ... based on the self-determined data or information.

[0121] Each slave chip 400i_a, 400i_b, ... is connected to the master security chip 300 via a secure communication channel. For example, each slave chip 400i_a, 400i_b, ... shares a secret key with the master security chip 300i that is used to encrypt data exchanged between the master security chip 300i and the slave chips 400i_a, 400i_b, ...

[0122] Alternatively, the security of the communication channel between each slave chip and the master chip can be based on a public key infrastructure (PKI). For example, each of the slave chip and the master chip may have a public key and private key pair, as well as a public key certificate.

[0123] In one embodiment, each of the slave chips 400i_a, 400i_b, ... is advantageously paired with a master chip 300i during device production. A pair of public and private asymmetric keys may be assigned to each slave chip 400i_a, 400i_b, ... The pairing procedure between the slave chips 400i_a, 400i_b, ... and the master chip 300i may include the master chip 300i authenticating the slave chips 400i_a, 400i_b, ... using the slave chips' public key certificates. Once authenticated, the slave chips 400i_a, 400i_b, ... are "sealed" to the master chip 300i, thereby preventing replacement by another chip. After the pairing procedure, a shared private key may be negotiated between each slave chip 400i_a, 400i_b, ... and the master chip 300i, enabling faster boot times.

[0124] A method for provisioning device credentials to multiple devices 200i according to a second embodiment will be described below with reference to Figure 8. According to the second embodiment, this method includes a process performed by the credential provider 100 to generate and transmit device credentials, and a process performed by each device 200 to receive and process the device credentials.

[0125] The process that generates and transmits device credentials is either the expected device credentials or the reference device credentials DVC_ATT_INFO. exp However, it is the same as the first embodiment, except that, for example, it is generated by the manufacturer 500 of device 200i based on the configuration profile (or reference configuration) of the master security chip 300i and the configuration profiles of the slave chips 400i_a, 400i_b, ... For example, chip authentication information is generated for each of the master security chip 300i and the slave chips 400i_a, 400i_b, ... and the device manufacturer concatenates the chip authentication information of the different chips 300i, 400i_a, 400i_b, ... to obtain the expected authentication information or reference authentication information DVC_ATT_INFO for device 200i.exp To decide.

[0126] The process for receiving and processing device credentials, performed by each device 200i in the second embodiment, is based on the first embodiment but differs in essence from the first embodiment by steps S11 and S12 shown in Figure 8.

[0127] In the second embodiment, step S11 for internally or self-determining information regarding the actual current configuration of device 300i includes steps S110_a, S110_b, ..., and S111, which are described below.

[0128] Steps S110_a, S110_b, ... are performed by the authentication modules 320i_a, 320i_b, ... of each slave chip 300i_a, 400i_b, .... In these steps S110_a, S110_b, ..., the authentication modules 320i_a, 320i_b, ... of each slave chip 300i_a, 400i_b, ... internally determine data or information regarding the current or actual configuration of the slave chip 400i_a, 400i_b, .... Figure 8 shows steps S110_a and S110_b performed by the slave chips 400i_a, 400i_b, ... respectively.

[0129] In step S111, the authentication module 320i of the master chip 300i also internally determines data or information regarding the current or actual configuration of the master chip 300i.

[0130] Furthermore, in the second embodiment, the current, actual, or real device authentication information DVC_ATT_INFO of device 200i real Step S12 for generating includes steps S120_a, S120_b, ..., S121, S122_a, S122_b, ..., S123, which are described below.

[0131] Steps S120_a, S120_b, ... are performed by slave chips 400i_a, 300i_b, ... respectively. In steps S120_a, S120_b, ..., the authentication modules 320i_a, 320i_b, ... of each slave chip (or SoC) 400i_a, 400i_b, ... use, for example, the PSA certification API 1.0, document number ARM IHI 0085 to obtain the current, actual, or real device authentication information SoC_ATT_INFO based on the data self-determined in steps S110_a, S110_b, ... real,a , SoC_ATT_INFO real,b , ...generates.

[0132] In step S121, the authentication module 320 of the master chip (or SoC) 300i uses, for example, the PSA certification API 1.0, document number ARM IHI 0085, to determine the current chip authentication information SoC_ATT_INFO based on the data self-determined in step S111. real,M Generates.

[0133] In steps S122_a, S122_b, ..., each slave chip 400i_a, 400i_b, ... communicates its current chip or SoC authentication information SoC_ATT_INFO via the communication channel between the slave chips 400i_a, 400i_b, ... and the master chip 300i. real,a , SoC_ATT_INFO real,b ...send to the master chip 300i.

[0134] Next, in step S123, the authentication module 320i of the master chip 300i receives the current or actual chip or SoC certification information SoC_ATT_INFO for each slave chip 300i_a, 400i_b, ... real,a , SoC_ATT_INFO real,b ...and the current or actual chip or SoC certification information SoC_ATT_INFO of the master chip 400i. real,MBased on the actual or current device authentication information DVC_ATT_INFO real Determine or calculate the following. For example, the authentication module 320i of the master chip 300i determines the current or actual chip or SoC authentication information SoC_ATT_INFO of different slave chips 300i_a, 400i_b, ... real,a , SoC_ATT_INFO real,b ...and the current or actual chip or SoC authentication information SoC_ATT_INFO of the master chip 400i. real,M The actual or real device authentication information DVC_ATT_INFO is concatenated with the other. real It is possible to calculate this. However, it is possible to generate actual real device authentication information based on actual real device authentication information from the slave chip and the master chip, respectively, using any other function.

[0135] Device authentication information DVC_ATT_INFO real After the determination, the process for receiving and processing device credentials proceeds from steps S13 to S16, as described in the first embodiment.

[0136] Variation

[0137] The modified version is based on the second embodiment, and differs from the second embodiment only in the aspects described below.

[0138] In a modified example, reference number 200 represents, for example, a system including multiple modules or subsystems interconnected with a local network protocol. The master chip can be located in a different module or subsystem of the system. Each module may include a master security chip and one or more slave chips. Furthermore, depending on the system configuration, a module may include one or more chips and, possibly, one or more other modules including a master chip.

[0139] In that case, user credentials are provisioned to multiple master chips independently of each other.

[0140] This disclosure also, - A computer program that, when executed by a computer, includes instructions that cause the computer to perform the steps of the aforementioned process for generating and transmitting device credentials, as performed by a credential provider, and -The present invention relates to a computer program that, when executed by a computer, includes instructions causing the computer to perform the steps of the aforementioned process for receiving and processing device credentials, so as to be performed by device 200i.

[0141] Final considerations

[0142] While the subject matter of the present invention has been described with reference to certain exemplary embodiments, various modifications and changes may be made to these embodiments without departing from the broader spirit and scope of the embodiments of the present invention. For example, various embodiments of its features may be mixed, adapted, or selectively chosen by those skilled in the art. Accordingly, “modes for carrying out the invention” should not be interpreted in a restrictive sense, and the scope of the various embodiments is defined only by the appended claims, together with the entire scope of equivalents to which such claims are granted.

Claims

1. A method for provisioning device credentials to a device (200), which is performed by a device (200), wherein the device (200) has a public asymmetric key and a private asymmetric key pair (K1 ｐｕｂ K1 ｐｒ ) Device private key (K1 ｐｒ ) including, the method, - Step (S10) of receiving the device credentials in encrypted form from the credential provider (100), - A step (S11) in which the device (200) internally determines information regarding its current configuration, - Device authentication information (DVC_ATT_INFO) based on the determined information regarding the current configuration of the device ｒｅａｌ The process of generating (S12), - The device secret key (K1 ｐｒ ) and a step (S13) of generating a decryption key (K4i) based on the generated device authentication information, A method comprising the step (S14) of decrypting the received device credentials in encrypted form using the decryption key (K4i) and provisioning the device credentials to the device (200).

2. The step (S13) of generating the decryption key (K4i) is, - The public key (K2) of the pair of public and private asymmetric keys of the credential provider (100) ｐｕｂ ) and the device secret key (K1 ｐｒ The steps include: (S130) the device and the credential provider agree on key data (K3i) by executing a key agreement protocol using ) and - The generated device authentication information (DVC_ATT_INFO ｒｅａｌ The method according to claim 1, further comprising the step (S131) ​​of deriving the decryption key (K4i) from the agreed key data (K3i) using a key derivation function that takes ) as input.

3. The method according to claim 1 or 2, further comprising the step (S15) of securely storing the device credentials in the device (200) after the decryption step (S14).

4. In the step of receiving the device credentials in the encrypted form (S10), the device (200) further receives an authentication tag. The decryption step (S14) includes authentication of the received device credentials based on the authentication tag (S140), - If the authentication fails, output an error (S142), - If the authentication is successful, output the decrypted device credentials (S141), The method according to any one of claims 1 to 3, including

5. The device (200) includes a security chip (300) that stores the device private key (K1 ｐｒ ), and the security chip - A step (S11) of internally determining information regarding the current configuration of the device (200), - Device authentication information (DVC_ATT_INFO) ｒｅａｌ The process of generating (S12), - The process of generating the decryption key (S13), The method according to any one of claims 1 to 4, comprising the step of decrypting the received device credentials (S14).

6. The security chip (300) is a master chip, and the device further includes one or more slave chips (400_a, 400_b, ...). Step (S11) to internally determine information regarding the current configuration of the device (200), and device authentication information (DVC_ATT_INFO ｒｅａｌ The process (S12) for generating ) is, - A step (S110_a, S110_b, ..., S111) performed by each of the master chip (300) and the one or more slave chips (400_a, 400_b, ...) to internally determine information regarding the current configuration of the chip, - Chip authentication information (SoC_ATT_INFO) is performed by each of the master chip (300) and the one or more slave chips (400_a, 400_b, ...) based on the determined information regarding the current configuration of the chip. ｒｅａｌ，ａ , SoC_ATT_INFO ｒｅａｌ，ｂ ,. .. .. , SoC_ATT_INFO ｒｅａｌ，Ｍ The process of generating (S12), - The generated chip authentication information (SoC_ATT_INFO) is executed by each slave chip (400_a, 400_b, ...). ｒｅａｌ，ａ , SoC_ATT_INFO ｒｅａｌ，ｂ The process involves transmitting , , , , ) from the slave chip (400_a, 400_b, , , , ) to the master chip (300), - The chip authentication information SoC_ATT_INFO of the master chip and each of the one or more slave chips ｒｅａｌ，ａ , SoC_ATT_INFO ｒｅａｌ，ｂ ,. .. .. , SoC_ATT_INFO ｒｅａｌ，Ｍ Based on the device authentication information (DVC_ATT_INFO ｒｅａｌ The process of calculating (S123), The method according to claim 5, including the method described in claim 5.

7. The method according to any one of claims 1 to 6, further comprising the step (S16) of authenticating the device (300) based on the device credentials in order to access a resource or to establish a connection with another party.

8. A method performed by a credential provider (100) for provisioning device credentials to multiple devices (200i), - Step (S1) of receiving multiple digital certificates for the multiple devices (200i), wherein each digital certificate contains information for identifying one device (200i) and a public key and private key pair (K1) assigned to the device (200i). ｐｕｂ，ｉ K1 ｐｒ，ｉ ) and the process, - Step (S2) of receiving expected device authentication information predetermined based on the configuration profiles of the plurality of devices (200i), and - For each device (200i), The public key (K1) of the device (200i) ｐｕｂ，ｉ ) and the expected device authentication information (DVC_ATT_INFO ｅｘｐ The process of generating an encryption key (K4i) based on (S3), and Step (S5) of encrypting the device credentials of the device (200i) using the encryption key (K4i), and A method comprising a provisioning step (S6) of transmitting the device credentials in an encrypted format to the corresponding device (200i).

9. The method according to claim 8, further comprising the step of generating device credentials for each of the plurality of devices (200i).

10. The step (S6) of transmitting the device credentials in an encrypted format to the corresponding device is: - A step of transmitting the device credentials of the corresponding device in an encrypted format to the credential management system (900), The method according to claim 8 or 9, further comprising the step of transmitting the device credentials in encrypted form from the credential management system (900) to the corresponding device via a local area network or local communication channel (920).

11. The step (S6) of transmitting the device credentials in an encrypted format to the corresponding device (200i) is performed by the authentication information provider (100). - A step of establishing a connection between the credential provider (100) and the corresponding device (200i) via a communication network (800), The method according to claim 8 or 9, further comprising the step of transmitting the device credentials in encrypted form to the corresponding device via an established connection.

12. A device configured to perform a step according to any one of claims 1 to 7.

13. A credential provider configured to perform the steps of the method described in any one of claims 8 to 11.

14. A computer program, which, when executed by a computer, includes an instruction causing the computer to perform a step according to any one of claims 1 to 7.

15. A computer program, which, when executed by a computer, includes an instruction causing the computer to perform a step according to any one of claims 8 to 11.

Images