System and method for trustless key provisioning - Patents.com

Abstract

A method for cryptographic key provisioning, comprising providing shared secret data to a device and a security service in a quantum computing safe manner, using the provided shared secret data to provide a root key, and using the root key as a basis for a sequence of steps, where each step comprises an operation of transforming a start key into a different generated key, the same steps being performed in parallel at the device and the security service, and where the root key is used as the start key for a first step in the sequence, and the generated keys generated at each step in the sequence are used as start keys for a next step in the sequence, except for a last step in the sequence, and where the generated keys generated at the device and the security service for the last step in the sequence are symmetric keys.

Description

[Technical field]

[0001] This application relates to a method, system and software for trustless key provisioning of key provisioning systems, and in particular for trustless key provisioning of quantum safe keys. [Background technology]

[0002] Cryptography is used to protect billions of transactions every day, from, but not limited to, Transport Layer Security (TLS) for online shopping and banking to ultra-secure government communications. These transactions rely on at least two or more transacting parties sharing a secret key, a reliable and secure means by which one party can encrypt data and subsequently decrypt it by the other parties.

[0003] With the advent of quantum computers and the invention of Shor's algorithm, classical asymmetric cryptography is no longer considered secure. Most well-known secure communication protocols (e.g., TLS) rely on asymmetric cryptography to send the same symmetric key to both ends of the communication channel (e.g., via Diffie-Hellman key agreement), so the advent of quantum computers is expected to make these protocols insecure.

[0004] Another approach to secure encryption is to provide symmetric keys to both ends of a communication channel. If symmetric keys could be sent to both ends of a communication channel without the use of asymmetric cryptography, this could provide the basis for desirable quantum-resistant encryption. However, known techniques for secure symmetric key provisioning typically require manually distributed key material, which is time-consuming, costly, and relies on the trustworthiness of the parties involved. Furthermore, manual key provisioning processes put a large amount of key material in the hands of the distributing party, and if this key material is lost or compromised, either by accident or through unauthorized access to the parties involved, the key material must be revoked and new keys must be issued, repeating the same slow manual process.

[0005] Therefore, there is a strong need for quantum-resistant approaches to symmetric key provisioning, as well as approaches that avoid the risk of key material being lost or compromised during the key provisioning process.

[0006] The embodiments described below aim to solve, but not limit, some or all of the problems present in known approaches as described above. Summary of the Invention

[0007] This Summary is intended to provide a brief introduction to a selection of concepts, the details of which are set forth in the Detailed Description below. This Summary is not intended to identify key or essential features of the patent application subject matter or to be used to delimit the scope of the subject matter. Different alternative features that facilitate the practice of the invention and / or serve to achieve substantially similar technical effects should also be considered within the scope of the invention disclosed herein.

[0008] In a first aspect, the disclosure provides a method for cryptographic key provisioning, comprising providing shared secret data to a device and a security service in a quantum computing safe manner, using the provided shared secret data to provide a root key, and using the root key as a basis for a sequence of steps, where each step comprises an operation of transforming a start key into a different generated key, the same steps being performed in parallel at the device and the security service, and where the root key is used as a start key for a first step in the sequence, and the generated keys generated at each step in the sequence are used as start keys for a next step in the sequence, except for a last step in the sequence, where the generated keys generated at the device and the security service for the last step in the sequence are symmetric keys.

[0009] In a second aspect, the disclosure provides a method for device authentication, including providing shared secret data to a device and a security service in a quantum computing secure manner, using the provided shared secret data to provide a root key, using the root key as a basis for a sequence of steps, where each step comprises an operation of transforming a start key into a different generated key, the same steps being performed in parallel at the device and the security service, and where the root key is used as a start key for a first step of the sequence, and the generated key generated at each step of the sequence, except for the last step of the sequence, is used as a start key for a next step of the sequence, and further including using the generated key generated at the device and the security service for the last step of the sequence to authenticate the device to the security service.

[0010] In a third aspect, the disclosure provides a method for cryptographic key provisioning, comprising providing data derived from a secret data of a device to a security service in a quantum computing safe manner, using the data derived from the secret data to provide a root key, and using the root key as a basis for a sequence of steps, where each step comprises an operation of transforming a start key into a different generated key, the same steps being performed in parallel at the device and at the security service, and where the root key is used as a start key for a first step of the sequence, and the generated keys generated at each step of the sequence are used as start keys for a next step of the sequence, except for a last step of the sequence, and where the generated keys generated at the device and at the security service for the last step of the sequence are symmetric keys.

[0011] In a fourth aspect, the disclosure provides a method for authenticating a device, comprising providing data derived from a secret data of a device to a security service in a quantum computing safe manner, using the data derived from the secret data to provide a root key, and using the root key as a basis for a sequence of steps, where each step comprises an operation of transforming a start key into a different generated key, the same steps being performed in parallel in the device and in the security service, and where the root key is used as a start key for a first step of the sequence, and the generated key generated in each step of the sequence, except for the last step of the sequence, is used as a start key for a next step of the sequence, and further comprising using the generated key generated in the last step of the sequence in the device and in the security service to authenticate the device to the security service.

[0012] In a fifth aspect, the disclosure provides a cryptographic key provisioning system, comprising means arranged for providing shared secret data to a device and a security service in a quantum computing safe manner, means arranged for using the provided shared secret data to provide a root key, and means arranged for using the root key as a basis for a sequence of steps, where each step comprises an operation of transforming a start key into a different generated key, the system being arranged to perform the same steps in parallel at the device and the security service, and where the root key is used as a start key for a first step in the sequence, and the generated keys generated at each step in the sequence are used as start keys for a next step in the sequence, except for the last step in the sequence, and the generated keys generated at the device and the security service for the last step in the sequence are symmetric keys.

[0013] In a sixth aspect, the disclosure provides a device authentication system, comprising means arranged for providing shared secret data to a device and a security service in a quantum computing safe manner, means arranged for using the provided shared secret data to provide a root key, and means arranged for using the root key as a basis for a sequence of steps, where each step comprises an operation of converting a start key into a different generated key, the same steps being performed in parallel at the device and the security service, and where the root key is used as a start key for a first step of the sequence, and the generated key for each step of the sequence, except for the last step of the sequence, is used as a start key for a next step of the sequence, and further comprising means arranged for using the generated key for the last step of the sequence at the device and the security service to authenticate the device to the security service.

[0014] In a seventh aspect, the disclosure provides a cryptographic key provisioning system, comprising means arranged for providing data derived from a secret data of a device in a quantum computing safe manner to a security service, means arranged for using the data derived from the secret data to provide a root key, and means arranged for using the root key as a basis for a sequence of steps, where each step comprises an operation of transforming a start key into a different generated key, the same steps being performed in parallel at the device and at the security service, and where the root key is used as a start key for a first step of the sequence, and the generated keys generated at each step of the sequence are used as start keys for a next step of the sequence, except for a last step of the sequence, and where the generated keys generated at the device and at the security service for the last step of the sequence are symmetric keys.

[0015] In an eighth aspect, the present disclosure provides a device authentication system, comprising: means arranged for providing data derived from a secret data of the device in a quantum computing safe manner to a security service; means arranged for using the data derived from the secret data to provide a root key; and means arranged for using the root key as a basis for a sequence of steps, each step consisting of an operation of converting a start key to a different generated key, the same steps being performed in parallel in the device and the security service, the root key being used as a start key for a first step of the sequence, and the generated key generated in each step of the sequence, except for the last step of the sequence, being used as a start key for a next step of the sequence. Also included is means arranged for using the generated key generated in the last step of the sequence in the device and the security service to authenticate the device to the security service.

[0016] In a ninth aspect, the present disclosure provides a computer-readable medium having stored thereon code or computer instructions that, when executed by a processor, cause the processor to perform a method according to any of aspects 1 to 4.

[0017] In a tenth aspect, the present disclosure provides computer program instructions which, when executed on a processor, cause the processor to perform a method according to any of aspects one to four.

[0018] The methods described herein may be implemented in machine-readable form by software on a tangible recording medium, such as in the form of a computer program comprising computer program code means adapted to perform all the steps of any of the methods described herein when the program is running on a computer and the computer program may be embodied in a computer readable medium. Examples of tangible (or non-transitory) recording media include disks, thumb drives, memory cards, etc., but do not include propagated signals. The software may be suitable for execution on a parallel or serial processor, as the software may perform the steps of the method in any suitable order, or simultaneously.

[0019] This application recognizes that firmware and software can be expensive, separately tradable commodities. Software that runs on or controls non-processing or standard hardware is intended to perform a desired function. Additionally, software that "describes" or defines the configuration of hardware, such as Hardware Description Language (HDL) software used to design silicon chips or configure universal programmable chips, is also intended to perform a desired function.

[0020] As will be apparent to those skilled in the art, any desired feature may be combined in any suitable manner and in any combination with any aspect of the present invention. Embodiments of the present invention will now be described, by way of example only, with reference to the following drawings, in which: [Brief description of the drawings]

[0021] [Figure 1] FIG. 1 is a schematic diagram illustrating a satellite quantum key provisioning system according to a first embodiment of the present invention. [Diagram 2] FIG. 2 is a schematic diagram illustrating a terrestrial quantum key provisioning system according to a second embodiment of the present invention. [Diagram 3] FIG. 3 is a schematic diagram illustrating a key fill process according to the first or second embodiment of FIG. 1 or FIG. [Figure 4] FIG. 4 is a schematic diagram illustrating the schema of a device record that can be used in the key fill process of FIG. [Diagram 5] FIG. 5 is a schematic diagram illustrating a user registration process that can be used in the first embodiment of FIG. 1 and the second embodiment of FIG. [Figure 6] FIG. 6 is a schematic diagram illustrating a user authentication process that can be used in the first embodiment of FIG. 1 and the second embodiment of FIG. [Figure 7] FIG. 7 is a schematic diagram illustrating a user role setting process that can be used in the first embodiment of FIG. 1 and the second embodiment of FIG. [Figure 8] FIG. 8 is a schematic diagram illustrating a workflow step policy setting process that can be used in the process of FIG. [Figure 9] FIG. 9 is a schematic diagram illustrating a bootstrap key injection process that can be used in the process of FIG. [Figure 10] FIG. 10 is a schematic diagram illustrating a device authentication process that can be used in the process of FIG. [Figure 11] FIG. 11 is a schematic diagram illustrating a device registration process that can be used in the process of FIG. [Figure 12] FIG. 12 is a schematic diagram illustrating a commissioner approval process that can be used in the process of FIG. [Figure 13] FIG. 13 is a schematic diagram illustrating a key revocation process that can be used in the process of FIG. [Figure 14]FIG. 14 is a schematic diagram illustrating a terrestrial quantum key provisioning system according to a third embodiment of the present invention. [Figure 15] Figure 15 is a schematic diagram illustrating a key fill process according to the third embodiment of Figure 14. Common reference numbers are used throughout the figures to indicate like features. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0022] Embodiments of the present invention are described below by way of example only. These examples represent the best ways currently known to applicants of carrying out the invention, but are not the only ways that this can be accomplished. The description sets forth the functions of the examples, and the sequence of steps for constructing and operating the examples, although the same or equivalent functions and sequences may be accomplished in other examples.

[0023] Overall, this disclosure provides a method for seeding authentication keys for a party and a cloud service for use in authenticating to the cloud service. In some instances the party is a device and the cloud service is a security service, but this is not critical. The method provides quantum-resistant security for the party and the cloud service by establishing a symmetric key. This shared symmetric key can be used as a root of trust for secure communications or other interactions between the party and the cloud service. This disclosure provides a method for key-filling this symmetric key into a computing device through a process that acts as a root of trust and can be fully or partially autonomous, where no supporting cloud service, no human party, and no eavesdropper can gain access to the symmetric key.

[0024] 1 is a schematic diagram outlining an example of a satellite-based quantum-safe trustless key provisioning system 100 according to a first embodiment of the present invention. The satellite trustless key provisioning system 100 comprises at least one quantum key provisioning (QKD) satellite 1 in Earth orbit and a number of optical ground receivers (OGRs) 2. Each OGR 2 can receive a quantum-safe encryption key from the QKD satellite 1 and share it with at least one other OGR 2. Methods for distributing encryption keys from satellites are known and need not be described in detail here.

[0025] As shown in Figure 1, a first OGR 2a is associated with a manufacturing facility 5 and a second OGR 2b is associated with a cloud service 6. OGRs 2a and 2b can be located at the manufacturing facility 5 and the cloud service 6, respectively, or can be located elsewhere and arranged to communicate with the manufacturing facility 5 or the cloud service 6, respectively. The cloud service can have a unique ID. This ID can be specific to the data center or server hosting the cloud service. This allows identifying the data center or server hosting the cloud service. Figure 1 shows satellite 1 communicating with both OGRs 2a and 2b. Of course, this is not intended to imply that it is essential that a satellite can communicate with both OGRs 2a and 2b simultaneously.

[0026] Each OGR 2 comprises at least one optical communication system 3 for optical communication with at least one OKD satellite 1, and a Hardware Security Module (HSM) 4 for securely storing and managing cryptographic key material distributed from the optical communication system 3. The HSM 4 ensures that any attempt to illicitly extract the keys is blocked or detected. The HSM provides tamper detection sensors such as a wire cage surrounding an encapsulated memory module, over-voltage, under-voltage, temperature detection, etc. This list is not intended to be comprehensive. In some cases the HSM 4 may be FIPS 140 certified. In operation of the system 100, symmetric QKD keys are distributed to both the manufacturing facility 5 and the cloud service 6 and securely stored in HSMs 4a and 4b, respectively.

[0027] As will be appreciated by those skilled in the art, the satellite-based quantum key provisioning system 100 may in fact include many other components, such as a satellite control and / or security operations center, which are omitted for simplicity and clarity.

[0028] For simplicity and clarity, only one satellite 1 and two OGRs 2 are shown in Figure 1. Of course, in practice the quantum key provisioning system 100 may have any number of satellites 1 and OGRs 2 in the chain.

[0029] Cloud Service 6 is a security service, i.e. a system that provides secure communications, such as using fiber optic links, and can provide secure data storage. Additionally, Cloud Service 6 can provide device and user authentication, which is described in more detail below. In this application, the terms "secure" and "securely" are used only when referring to communications over established links without the use of asymmetric algorithms. As mentioned above, asymmetric algorithms are generally not considered to be able to provide security against quantum computing. Cloud Service 6 provides a registry for the generation, storage, distribution and verification of quantum-safe keys, and a registry for the authentication and verification of devices and users associated with Cloud Service 6 using quantum-safe keys. All communications within and with Cloud Service 6 are quantum-safe. Cloud Service 6 is a service provided by, for example, Arqit Quantum Cloud. TM It is possible that.

[0030] The cloud services 6 may be hosted in a public cloud or a private data center. The cloud services 6 are backed or supported by a database 7 that provides data storage for the cloud services 6. The database 7 may be, for example, a traditional database, a NoSQL database, a distributed database, or a database that supports distributed ledger technology (DLT). The database 7 may operate using, for example, distributed ledger technology (DLT), distributed database technology (DDT), hash chain based logging / auditing, other database technologies (other than DLT) and hash chain based logging / auditing, and / or message based technologies and hash chain based logging / auditing. This list is by way of example only and is not intended to be exhaustive. Other database technologies and architectures may also be used.

[0031] A hash chain is the repeated application of a cryptographic hash function to some data. It can also be used to record the existence of data chronologically for non-repudiation purposes by successively applying the hash function to additional pieces of data. The use of hash chains or logging and / or auditing is well known and need not be described in detail here.

[0032] The manufacturing facility 5 may be controlled by a customer who wishes to deliver encryption keys to the customer-controlled target devices 8 to enable access to the cloud service 6 from the target devices 8. In some examples, the manufacturing facility 5 may be controlled by an operator of the cloud service 6.

[0033] 2 is a schematic diagram outlining an example of a terrestrial quantum-secure trustless key provisioning system 200 according to a second embodiment of the present invention. The terrestrial trustless key provisioning system 200 comprises a number of terrestrial transceivers 9 connected by optical fibre links 10. The terrestrial transceivers 9 are capable of transmitting and receiving quantum encryption keys between each other over the optical fibre links 10. Transmission and reception of encryption keys over optical fibre links is known and need not be described in detail here.

[0034] The terrestrial quantum-safe trustless key provisioning system 200 is similar to the satellite-based quantum-safe trustless key provisioning system 100 according to the first embodiment, except that the terrestrial transceiver 9 is replaced by an OGR 2 .

[0035] As shown in FIG. 2, a first terrestrial transceiver 9a is associated with the manufacturing facility 5 and a second terrestrial transceiver 9b is associated with the cloud service 6. The terrestrial transceivers 9a and 9b may be located at the manufacturing facility 5 and the cloud service 6, respectively, or may be located elsewhere and arranged for communication with the manufacturing facility 5 or the cloud service 6, respectively. Each terrestrial transceiver 9 comprises at least one optical quantum transceiver 11 arranged for communicating cryptographic keys over a fiber optic link 10, and a hardware security module (HSM) 4 for securely storing and managing cryptographic key material distributed through the optical quantum transceiver 11. The cloud system 6 corresponds to the cloud system 6 of the first embodiment. In operation of the system 200, symmetric QKD keys are distributed to both the manufacturing facility 5 and the cloud service 6 and securely stored in the respective HSMs 4a and 4b.

[0036] As will be appreciated by those skilled in the art, in practice there are many other components in the terrestrial trustless key provisioning system 200, such as a security operations center, but these are omitted for the sake of simplicity and clarity.

[0037] For simplicity and clarity, only two terrestrial transceivers 9 are shown in FIG. 2. Of course, in practice the network that constitutes the terrestrial trustless key provisioning system 200 may include any number of terrestrial transceivers 9.

[0038] Both trustless key provisioning systems 100 and 200 operate to key fill one or more target devices 8 by loading one or more cryptographic keys onto the target devices 8. For clarity and simplicity, the loading of one cryptographic key onto one target device is described herein, although it should be understood that systems 100 and 200 can accommodate loading any number of cryptographic keys onto any number of target devices 8.

[0039] 3 shows an overview of the workflow of the entire key provisioning process 300 performed by the quantum key provisioning (QKD) systems 100 and 200 according to the first and second embodiments. Of course, the only difference between the quantum key provisioning systems 100 and 200 according to the first and second embodiments is the mechanism by which the quantum-safe cryptographic keys are made available to the HSMs 4a and 4b associated with the manufacturing facility 5 and the cloud service 6.

[0040] The key provisioning process 300 distributes the QKD key to both the cloud service 6 and the target device 8. The key provisioning process 300 then advances these two keys (i.e., two copies of the same symmetric key) incrementally in the same rhythm of ratcheting in both the cloud service 6 and the target device 8 environments, respectively, until it arrives at the same key in the cloud service 6 and the target device 8. At each step, the start key is transformed by the ratcheting into a different, new or generated key. These final identical keys are now available as symmetric keys that act as a root of trust. This can be used for quantum computationally secure communication between the cloud service 6 and the target device 8, or to perform any other desired task. As a result, the key provisioning process 300 has two branches or arms that run in parallel. This consists of the upper branch, first branch 300a of FIG. 3, which runs in the target device 8, and the lower branch, second branch 300b of FIG. 3, which runs in the cloud service 6. In this example, the QKD key is distributed to both the cloud service 6 and the target device 8. Conveniently, the QKD key may be a symmetric encryption key, although in other instances the QKD key is typically some form of shared secret data that can be used as, or as the basis for, a shared encryption key.

[0041] In each branch 300a, 300b of the key provisioning process 300, a key may be used as an authentication key by the target device 8 to authenticate to the cloud service 6 before generating the next key in the chain. The final key may be used for further authentication, for example to generate a session key, or for other purposes.

[0042] Since the workflow is defined by the policy, different workflows can be defined for different situations by assigning different policies to a device or set of devices. A policy can be viewed as a set of related policy options that define the run-time operation of the system 100 or 200 in a particular case. The manufacturing facility 5 has a default policy that is assigned to the target devices 8 of the cloud service 6. This default policy can be a default policy that applies to all target devices 8 of the manufacturing facility 5, or a specific policy that is assigned to a certain classification or type of target devices 8. Or it can be a specific policy that is assigned to a specific target device 8 as desired, for example, by a customer operating the manufacturing facility 5 or a customer organization operating the device 8. The operation or ratcheting of the key through the key provisioning process 300 may require the approval of many control devices (not shown in FIGS. 1-3). The control devices may be used to approve the key fill to the target devices 8 as specified in the policy. In some cases, the control devices may have previously performed a key fill to enable the respective control devices to communicate securely with the cloud service 6. In other cases, the control devices may be suitable devices to launch a browser or other application to enable secure communication with the cloud service 6. The controller is used by the commissioning personnel to approve the next ratchet of the target device 8 as the target device 8 moves through the workflow. The number and identity of the controller and commissioning personnel required to approve the ratcheting forward and key fills to the target device 8 are defined by the policies of the manufacturing facility 5 or the customer of the target device 8. Typically, the commissioning personnel are appointed and selected by the customer operating the manufacturing facility 5, but this is not required. The commissioning personnel could be, for example, a cryptocurrency custodian, a key handler, an on-site security officer, etc., but would typically represent the person responsible for running the well-known key provisioning process. The commissioning personnel are formally trained and vetted. The selection process for the commissioning personnel is based on the requirements of the specific implementation customer and need not be detailed here.

[0043] In some examples, the control device may have been key-filled with a secure key by a key provisioning process 300 so that it can communicate securely with the cloud service 6 , and the control device may have been a target device 8 .

[0044] 3 shows the initial provision of a common QKD key to the cloud service 6 and the target device 8. This is performed by the system 100 of the first embodiment using satellite 1 and OGRs 2a and 2b. If the system 200 of the second embodiment were used instead, the satellite 1 and OGRs 2a and 2b depicted here would be replaced by a fiber optic link 10 and terrestrial transceivers 9a and 9b.

[0045] The key provisioning process 300 according to the first and second embodiments has a number of objectives: To expose a set of workflow steps that define the keychain used to authenticate the target device 8 to the cloud service 6 using a policy for future key negotiation tasks (e.g. negotiating a session key with another device); To associate the target device 8 with a workflow step policy, where each workflow step defines whether the step requires user authentication and / or commissioning officer approval; To configure a bootstrap key for the target device 8 at the time of manufacture, so that the bootstrap key sent to the two places derived from the same QKD distribution key is calculated separately at the manufacturing facility 5 and at the cloud service, so that the key cannot be intercepted in transit over the classical communication channel between the manufacturing facility 5 and the cloud service 6; To allow the target device 8 to connect to the cloud service 6 using the bootstrap key and transition to a new authentication key using a ratchet mechanism according to a predefined policy, and then to allow the target device 8 to connect to the cloud service 6 using the updated ratchet key and transition to a new authentication key using a ratchet mechanism according to a predefined policy.

[0046] The key provisioning process 300 of FIG. 3 according to the first and second embodiments is outlined as follows.

[0047] All steps of the key provisioning process 300 and / or all steps performed by the system 100 or 200 are securely logged and / or audited using a verifiable quantum secure hash chain. This is necessary to ensure that the log / audit trail is immutable and no changes from an attacker or the like can go undetected. In examples where the system 100 or 200 is based on DLT, the DLT can provide tamper-proof logging / audit capabilities. Also, in examples where the system 100 or 200 is not based on DLT, hash chain based logging / audit can be used to ensure that the logging / audit cannot be tampered with.

[0048] For the sake of clarity and to avoid unnecessary repetition, logging is not explicitly mentioned in the detailed description of the operation of the embodiments of the invention presented below, although it will be understood that each step of the method 300 is logged, which may be done, for example, by a centralized logging service provided by the cloud service 6.

[0049] For the sake of clarity and to avoid unnecessary repetition, auditing is not explicitly mentioned in the detailed description of the operation of the embodiments of the invention presented below. However, it will be understood that each workflow start, error, and success of the method 300 is audited. This may be performed, for example, by a centralized auditing service provided by cloud service 6.

[0050] Prior to performing the key provisioning process 300, a user of the system 100 or 200 signs up or registers with the cloud service 6. The cloud service 6 provides a user sign-up service using the user's email address. The user's email address is verified before the user is allowed to sign up. In the described embodiment, two-factor authentication is used when signing up a new user. Email address verification and two-factor authentication are well-known procedures and do not need to be described in detail here. Email address verification and the use of two-factor authentication are not mandatory when signing up a new user, and other example sign-up procedures may be used.

[0051] When a user signs up to the cloud service 6, the cloud service 6 assigns each user a random symmetric user key, which is stored in the cloud service's 6 database 7 encrypted using a hash of the respective user's password. Of course, this is not required and other means may be used to store and protect user keys and associated passwords.

[0052] Conveniently, the first user to sign up from any given institution is assigned the administrator role, and subsequent users from the same institution are assigned roles by the institution's administrator, although this is not required and alternative examples may use other methods of role assignment.

[0053] Users who sign up for Cloud Service 6 may be assigned multiple different roles by an administrator or administrators of their respective organizations. Accordingly, Cloud Service 6 provides a process by which administrators can change the roles of other users of Cloud Service 6. The details of this process, and what changes a particular administrator can make, are determined as necessary based on the requirements of each respective organization.

[0054] A user may be assigned the role of administrator. The administrator manages the cloud services 6, defines the policies to be applied during the key provisioning process 300, assigns roles to other users, and performs other tasks. A user may be assigned the role of auditor. Additionally, as part of the audits described above, an administrator or a specific auditor may receive audit notifications regarding the parts of the systems and processes under their responsibility. The administrator or auditor may configure their audit notifications appropriately, for example, to receive an email when a specific audit or type of audit is received. The auditor may also provide access or lock down all audit-related data in the system as an assurance activity separate from the administrator role. This may be desirable to prevent attempts by internal management-level system roles to destroy, delete, or conceal unauthorized system-level activity.

[0055] A user may be assigned the role of commissioner who, depending on the workflow step policy, may be required to approve the key ratcheting to the next key in the chain of the target device as part of an automated key fill process with the control device, as described in more detail below.

[0056] Users may be assigned a User role, which is a person authorized to use a particular target device, and depending on the workflow step policy, may be required to provide credentials to allow the target device to ratchet to the next key, as described in more detail below.

[0057] Beyond the roles identified above, other roles or scopes may apply to each user, for example whether the user is allowed to create and use OTPs via API.

[0058] In addition to the functionality provided to users who sign up with cloud system 6 as described above, cloud system 6 may provide a process by which users can authenticate to the cloud services from devices that are not configured to use cloud service keys to perform administrative tasks using the web portal or app.

[0059] 3, the system 100 or 200 provides an acyclic state machine that allows a responsible administrator to specify a series of workflow steps that define a key ratchet pipeline that forms the branches 300a, 300b of the key provisioning process 300. An acyclic state machine is a finite state machine where a previously visited state cannot be revisited, i.e., a straight line is formed from the start state to the end state, with no cycles.

[0060] 3 can be executed on a target device 8, a responsible administrator must define the sequence of steps in the workflow of the key distribution process 300 by specifying a workflow step policy that defines one or more workflow steps. This defined workflow step policy is then stored in the database 7 of the cloud service 6. Furthermore, the individual workflow steps must also be defined, and these defined workflow steps are also stored in the database 7 of the cloud service 6.

[0061] Each defined workflow policy defines the requirements that the target device 8 must meet to move from each workflow state to the next workflow state in the key provisioning process 300. Each defined workflow step defines the requirements that the target device 8 must meet to move from a particular workflow state to the next workflow state. A workflow step may define whether a user authentication is required on the target device to move to the next workflow state, or whether approval of a commissioning officer is required, such as on a separate control device or via a web portal, to move to the next workflow state, how many, and what API scope is allowed when authenticating to the cloud service with the ratchet key in that workflow step.

[0062] For simplicity and clarity, this description will be in terms of one workflow policy for key filling of one target device 8. Of course, different organizations using the systems 100 or 200 may set different workflow policies, and each organization may set different workflow policies for different target devices 8 or groups of target devices 8.

[0063] As shown in FIG. 3, for each target device 8, the key provisioning process 300 begins with putting a bootstrap key into the target device 8 (302) to bootstrap the target device 8 (304). The manufacturing facility 5 selects a QKD key stored in the OGR 3a or HSM 4a of the terrestrial transceiver 9a as appropriate, derives a new bootstrap key from the selected key, and puts the derived bootstrap key into the target device 8. The bootstrap key is then stored in the target device 8, for example, in device storage or chip, or in some other manner. This bootstrap key injection may be performed at the initial manufacturing of the target device 8, or at some time thereafter. As noted above, the QKD key is any form of shared secret data that can be used as, or as the basis for, a shared encryption key. Conveniently, the QKD key may be a symmetric encryption key.

[0064] Subsequently, or simultaneously, the manufacturing facility 5 registers 306 the bootstrap key with the cloud service 6 using a bootstrap provisioning terminal or a service that provides secure communication with the cloud service 6. To perform the provisioning 306, the manufacturing facility 5 informs the cloud service 6 of metadata about the target device 8, such as data such as the device ID and / or manufacturer, and the ID of the QKD key used to derive the bootstrap key from the QKD key. However, the manufacturing facility 5 does not send the bootstrap key or the QKD key to the cloud service 6, so that these keys cannot be intercepted or accessed by other parties.

[0065] The cloud service 6 stores the QKD identity, metadata, and data provided by the manufacturing facility 5 in a database 7. The QKD key selected by the manufacturing facility 5 from HSM 4a to derive the bootstrap key is a symmetric key that is also available to the cloud service 6 from HSM 4b. Thus, on demand, the cloud service 6 can compute the same bootstrap key using the stored provided QKD identity and data, and the stored QKD key, whenever necessary.

[0066] As part of provisioning 306, the cloud service 6 creates a device record in database 7 for the target device 8. This device record stores or links to a copy of the workflow policy associated with the target device 8 selected by the associated administrator and / or manufacturing facility 5. Additionally, the cloud service 6 initializes the commissioning signature and commissioning party fields for the target device 8 to zero, and generates and stores a random commissioning salt for use in each workflow step that requires commissioning personnel approval for the target device 8. The commissioning signature field in the device record for the target device 8 is a signed random sequence of numbers that serves as evidence of the commissioning personnel's signature.

[0067] The cloud service 6 initializes the device record in the database 7 of the target device 8 with the workflow state bootstrap 308 .

[0068] As a result, the workflow state of the target device 8 starts at a known state bootstrap 304 and the workflow state of the target device 8's device record in the cloud service 6 becomes a corresponding known state bootstrap 308. If the requirements for the next workflow state are met as defined in the workflow step policy assigned to that target device 8, then the target device 8 can transition to the next workflow state, as described in more detail below.

[0069] The bootstrap key is therefore a key formed from the QKD distribution key that is inserted into the device at the time of manufacture or thereafter, and can also be computed by a cloud service. The bootstrap key grants access to a limited set of cloud service APIs, specifically those related to progressing through the ratchet pipeline.

[0070] The system 100 or 200 provides a means for a target device 8 to authenticate to a cloud service using a bootstrap key or a key ratcheted from the bootstrap key. In each case, the cloud service 6 first builds the keychain required for authentication from the QKD key stored in the HSM 4b, which is used to generate the bootstrap key. The bootstrap-based key can be calculated on-demand by the cloud service 6 using a stored ratchet value held in the database 7. When a target device 8 authenticates to the cloud service 6 using the bootstrap key or a key ratcheted to it, the cloud service 6 returns a token, such as a JSON Web Token (JWT), whose scope is defined for the target device 8 in the workflow step. Authentication of the target device 8 by the cloud service 6 involves a challenge-response to generate a session key from the current key (the bootstrap key or a key ratcheted to the bootstrap key) and two challenge codes that are exchanged between the target device 8 and the cloud service 6 and then discarded.

[0071] A JWT is an Internet standard way to create optionally signed and / or optionally encrypted data whose payload contains JSON that asserts at least some numeric claim or range.

[0072] The cloud service 6 uses the key to encrypt the target device 8 client state, K_CS. This allows RESTful APIs whereby the cloud service 6 server cannot store the target device 8 client state between sessions. Rather the client state is returned to the client and resent on the next RESTful call. This can be used, for example, to return a session key to the target device 8 client one service and then supply it on the next call to a different service, such as for load balancing, without the cloud service 6 needing to store the session key between calls or distributing the session key across many services.

[0073] If a workflow step requires commissioning approval for the target device 8 to transition, all required commissioning personnel must approve the request for approval to use the control device. Typically this is done by launching a secure mobile or web application on the control device. In some cases, the commissioning personnel may instead approve the request for approval using an email link, or by scanning a QR code that activates the link, or by launching a mobile or web application on an untrusted device. When the commissioning personnel approves the request for approval, the commissioning personnel's approval result in the control device encrypting the commissioning salt previously generated and stored by the cloud service 6 using the commissioning personnel's user key, the result is added to the list of signatures in the commissioning signature field of the target device's device record stored in the database 7, and the commissioning personnel's username is added to the commissioning party field of the target device's device record stored in the database 7.

[0074] After the target device 8 has authenticated the target device 8 to the cloud service 6 using the bootstrap key or a key ratcheted from the bootstrap key as appropriate, and negotiated a session key with the cloud service 6, and received an authentication token, such as a JWT, from the cloud service 6, a user of the target device 8 can begin the provisioning process of the target device 8 with the cloud service 6, triggering the ratcheting of the latest key, which is either the bootstrap key or a key ratcheted from the bootstrap key.

[0075] To register the target device 8 with the cloud service 6, the target device 8 calls the provisioning function, passing an authentication token and (optionally) user authentication if required by the workflow step. Optionally, the cloud service 6 may authorize the user to use a password and optionally to use two-factor authentication (2FA). Other authentication methods may be used in addition or instead, for example an authentication code such as a user JWT from an identity service. Upon receipt of the token and optionally successful user authentication, the cloud service 6 generates random data and uses it to create a ratchet value. The ratchet value is used to ratchet the latest ratchet key to the next ratchet key and stores this value in the database 7 in an array of ratchet values ​​associated with the target device 8. Optionally, if the current workflow step of the target device 8 requires approval by a commissioning officer and the required approval is stored in the commissioning signature field associated with the workflow step, the list of commissioning signatures is merged into the ratchet value of the workflow step. This ratchet value is used as the latest in the ratchet value chain and can be used in the future to calculate new authentication keys from the original QKD key on demand.

[0076] The cloud service 6 now returns the ratchet value to the target device 8, which can then generate a new ratchet key from the most recent key in its chain to form a new authentication key. As a result, on the first registration a new ratchet key is generated from the bootstrap key, or on subsequent registrations from the key generated during the previous registration.

[0077] As shown in FIG. 3, when the target device 8 is in the bootstrap state 304, the key provisioning process 300 continues with the target device 8 authenticating and provisioning with the cloud service 6 using the authentication and provisioning process described above. In some examples, the authentication and provisioning of the target device 8 with the cloud service 6 may be triggered by a user action. In other examples, the authentication and provisioning of the target device 8 with the cloud service 6 may be triggered automatically by the target device 8 itself, such as upon the first boot of the target device 8, if user authentication is not required by policy. If the authentication and provisioning process of the target device 8 is successful, any user authentication is successful, and any trustee approval identified as required by the next workflow step of the workflow step policy applied to the target device 8 is received, the cloud service 6 generates a ratchet value as described above and uses the ratchet value to create a ratchet authentication key from the bootstrap key, which is created from the QKD key selected as described above. The target device ratchets 310 the status of the target device 8 in its device record in the database 7 from the bootstrap state 308 to the next workflow state (in the example of FIG. 3, a state 312 named “Quarantine” in this example).

[0078] The cloud service 6 then, or simultaneously, sends the ratchet value to the target device 8, which creates the same ratchet authentication key from the bootstrap key, which in turn was previously created from the selected QKD key, as described above, and the target device 8 ratchets its state 314 from the bootstrap state 304 to the next workflow state, which in the example of FIG. 3 is named “Quarantine” 316.

[0079] In the example of FIG. 3, a target device 8 in state 316 named "Quarantine" and having a status of the target device 8 in a device record in database 7 in a corresponding state 310 named "Quarantine" is provided limited system and network connectivity by cloud service 6, contingent on the target device 8 successfully authenticating and registering with cloud service 6. This limited connectivity is selected to ensure that a target device 8 in state 316 cannot be used to harm or compromise the security of cloud service 6. In some examples, the cloud service connectivity provided to a target device 8 in state 316 may be such that it only allows connectivity to a closed, quarantined network.

[0080] Thereafter, when the target device 8 is in state 316, the key provisioning process 300 continues by the target device 8 again authenticating and provisioning with the cloud service 6 using the authentication and registration process described above. If the authentication and provisioning process is successful, and any user authentication is successful and any trustee approval identified as required by the next workflow step of the workflow step policy applied to the target device 8 is received, the cloud service 6 generates a further ratchet value as described above and uses the further ratchet value to create a new ratchet authentication key from the ratchet key. The cloud service 6 then ratchet 318 transfers the status of the target device 8 in its device record in database 7 from state 312 to the next workflow state (in the example of FIG. 3, state 320 of the “product cloud service”).

[0081] The cloud service 6 subsequently, or simultaneously, sends a further ratchet value to the target device 8, which creates the same new ratchet authentication key from the ratchet key previously created in turn from the bootstrap key and the selected QKD key, as described above, and the target device 8 ratchets its state 322 from state 316 to the next workflow state, state 324, named “production” in the example of FIG. 3.

[0082] In the example of FIG. 3, a target device 8 in state 324 and having a status of the target device 8 in its device record in database 7 in corresponding state 320 will be provided full system and network connectivity by the cloud service 6, contingent on the target device 8 successfully authenticating and provisioning with the cloud service 6. The connectivity provided may be set by the connectivity policies of the organization that controls the target device 8. The final "production" key allows access to a wider range of cloud service functionality than the "quarantine" state, and the access provided is defined by the scope of the associated workflow policy.

[0083] The example of FIG. 3 illustrates a key provisioning process 300 in which the target device 8 moves stepwise from an initial bootstrap state 304, to an intermediate “quarantine” state 316, to a final “production” state 324 that provides full system and network connectivity. In other examples, there may be any number of intermediate states between the initial bootstrap state and the final state as required by the policies of a particular organization, with each state defined and named in the workflow step policy. The requirements for allowing the target device 8 to ratchet forward from one state to the next may be set as required, in particular whether user authentication is required, whether and how many commissioning officer approvals are required, and so on. It is not mandatory to provide an intermediate “quarantine” state that provides limited connectivity. In addition to the initial bootstrap state, and the final state, in some examples one or more of the following named intermediate states may be configured: “Initial Configured Factory”, “MNO Pending”, “MNO Provisioned”, “Customer Pending”, “Customer Provisioned”, and / or “Quarantine”.

[0084] In some circumstances, it may be necessary to revoke all keys associated with the target device 8 and return the target device 8 to its original manufacturing facility state with the bootstrap key. This can be done by zeroing out all entrusted party and entrusted signature fields, zeroing out all ratchet fields and ratchet arrays, and returning the current workflow step to the start. This resets the record of the target device 8 in the database 7 to the bootstrap state 308. Thus, the next authentication using, for example, the key ratchet associated with state 324 will fail and an error code will be returned to the target device 8 informing it that a factory reset has occurred, and the target device 8 will be reset to the bootstrap state 304. The target device 8 can then begin the registration process again at the appropriate time.

[0085] In an alternative example, instead of the bootstrap key being derived from the QKD distribution key at both the manufacturer and cloud service locations, the bootstrap key may be distributed to the cloud service 6 by a classically secure, post-quantum cryptographically secure, or physical mechanism.

[0086] It will be understood from the above and the following detailed examples that the disclosed embodiments are capable of achieving the above stated goals.

[0087] FIG. 4 is an example of a schema 400 that may be maintained in a database 7 of a cloud service 6 as a device record for a target device 8. The schema 400 is comprised of device data 402 for the target device 8. The device data 402 is comprised of a manufacturer ID, a device ID, a QKD key ID, a bootstrap nonce, a workflow step policy identifier, a workflow ratchet value, a workflow commissioning identifier, and a workflow step index. The manufacturer ID may identify a manufacturing facility 5 or may identify an organization responsible for the target device 8. The bootstrap nonce is data used to derive a bootstrap key from a QKD key.

[0088] The workflow step policy identifier of the device data 402 links to workflow step policy data 404 of the workflow step policy that is to be applied to the target device 8. The workflow step policy data 404 consists of the workflow step policy ID, name, and number of the workflow step identifier.

[0089] Each workflow step identifier in the workflow step policy data 404 is linked to workflow step data 406. Each workflow step data 406 consists of a workflow step ID, a name identifying the name of the state reached by executing the workflow step, whether the workflow step requires user authentication, whether the workflow step requires authorization by a referral agent, and the scope, i.e., operation permissions, granted to the key reached by executing the workflow step.

[0090] If a workflow step requires a commissioning officer authorization, the workflow step data 406 is linked to multiple commissioning officer authorization data 408. Each commissioning officer authorization data 408 consists of an authorization ID, a commissioning officer's username, an email address, a password salt, a password digest, an encrypted user key, a state, and a user role. In the illustrated embodiment, the workflow step data 406 is directly linked to a single commissioning officer authorization data 408 for simplicity and clarity. It will be understood that each workflow step 6 may be linked to any number of commissioning officer authority data 408. Furthermore, rules can be set that define which commissioning officer or combination of commissioning officers is required at a workflow step. For example, approval may be required by a specific individual, one or more members of a defined group, or a logically defined combination, such as approval by Commissioning Officer A and a member of Commissioning Officer Group B, or approval by Commissioning Officer C or two members of Commissioning Officer Group D and a member of Commissioning Officer Group E.

[0091] The workflow step policy identifier of the device data 402 is also linked to the workflow step approval data 410 of the target device 8 where the approval state is stored. The workflow step approval data 410 consists of the workflow step approval ID, a record of the delegation agent signature of the approving delegation agent, the name of the approving delegation agent, a salt encrypted or signed by the delegation agent, and optionally a record of the user who provided authentication for this workflow step.

[0092] In the example of FIG. 4, there may be one or more workflow step data 406 linked to the schema 400, as indicated by the indicator 1:n on the line linking the workflow step data 406 to the workflow step policy data 404, and there may be zero or any number of referral agent approval data 408 linked to each workflow step data 406, as indicated by the indicator On on the line linking the referral agent approval data 408 to the workflow step data 406. Additionally, there are one or more workflow step approvals 410 linked to the schema 400, as indicated by the indicator 1:n on the user linking the workflow step approvals 410 to the device data 402. There is workflow step data 406 corresponding to each workflow step of the workflow step policy. Additionally, since each workflow step may require zero or any desired number of referral agents approvals, the workflow step data 406 is linked to a corresponding number (including zero) of referral agent approval data 408.

[0093] FIG. 5 is an illustration of a detailed user registration process that can be used in the first and second illustrated embodiments.

[0094] In the user registration process 500 shown in Figure 5, the process 500 begins when a user 502 chooses to create an account with the cloud service 6. The user provides sign-up information 504 consisting of a username UN_U, an email address E, and a password P_U. The user 502 may provide the sign-up information through an app for mobile users, through a web app user, or in other ways.

[0095] User Pri then calls cloud service 6, passing UN_U and PJJ, and requesting a new account.

[0096] The cloud service 6 checks whether an account already exists for the user 502. If the check indicates that an account already exists, the cloud service 6 returns an error message 510 and the registration is terminated. Alternatively, if the check 508 indicates that the user of the account does not exist, the cloud service 6 creates a new record 512 in its database for the user 502 and creates a symmetric user key K_U.

[0097] Cloud Service 6 then uses PDKDF2 (or other password hashing algorithm using SHA256 or higher) to derive a password key K_P from P_U, encrypts K_U with K_P to form K_UE, and stores the result in the user record: K_P=PBKDF2(P_U) or K_P=PBKDF2(P_U,<num iterations> ) and K_UE={K_U}K_P

[0098] Cloud service 6 then generates 516 a random password salt S_U, hashes P_U with it, creates a password digest D_P, and stores S_U and D_P: D_P=#(S_U,P_U)

[0099] The cloud service then creates a record 518 in the database for the user with at least the following fields and values ​​(it can add other fields, such as tenant ID, company name, etc., if desired): [Table 1]

[0100] The cloud service 6 then sends a verification email 520 to the user's email address E, which includes an anonymous link that can be used to verify the source email address and / or a QR Code that can be scanned to effectively click on the link.

[0101] When the user 502 receives the email, the user clicks on the link 522 or scans the QRCode, which causes a notification 524 to be sent to the cloud service 6 .

[0102] When the cloud service 6 receives the notification, it looks up the user record from the anonymous data in the link and marks the user status as verified.

[0103] The cloud service 6 then sends a message 530 back to the user 502 to confirm that the new user account has been opened.

[0104] The user registration process 500 contemplates either a single organization or single-tenant system, or a multi-organization or multi-tenant system where the organization or tenant is selected by matching the domain specified in the user's email address, or by other methods not covered by this invention.

[0105] In the user registration process 500, OAuth2 or other standard user authentication patterns can be used for user authentication and password management, in which case the user key must be kept in plaintext in the cloud service's 6 database 7 or the user key can be omitted entirely.

[0106] The user registration process 500 allows for two-factor authentication to be incorporated into the (user) authentication flow.

[0107] 6 is an illustrative example of a detailed user-only authentication process that may be used to enable user management in the illustrated first and second embodiments. The user-only authentication process of FIG. 6 is not used in the key provisioning process 300 of FIG.

[0108] In the user-only authentication process 600 shown in FIG. 6, the process 600 begins 604 when a user 602 initiates a login request 606 to the cloud service 6 providing a username UN_U', or email E', and a password P_U'.

[0109] Upon receiving the login request 606, the cloud service 6 checks 610 whether a corresponding user account exists and returns an error 612 if not. Alternatively, if a corresponding user account exists, the cloud service 6 looks up the user record in the database 7 and uses S_U from the user record to create a new digest 614: D_P'=#(S_U,P_U')

[0110] The cloud service 6 then verifies whether the new digest matches the digest in its database and checks whether the provided password is correct 616. If the provided password is incorrect, the cloud service 6 returns an error message 618. Alternatively, if the provided password is correct, the cloud service 6 creates 620 a user JWT and sends the user JWT 622 to the user's 602 browser or app for use in future API calls. The cloud service 6 then records the user 60 user and permissions in the user JWT scope.

[0111] As with the user registration process described above, OAuth2 or other standard patterns could be used instead.

[0112] Figure 7 is an example of a detailed user role configuration process that may be used to enable user roles to be configured in the illustrated first and second embodiments. This process assumes, as described above, that the first user created for a new organization or tenant will be the first administrator for that organization or tenant.

[0113] In the user role configuration process 700 shown in FIG. 7, the process 700 begins when a user 602 authenticates using the user-only authentication process 600 shown in FIG. 6 and obtains a user JWT.

[0114] Next, the user 602 requests 702 that the cloud service 6 pass the user JWT to set the role of the user U to the specified role R. For example, the user 602 can request that the cloud service 6 set the role of the user U to “Entrusted Person.”

[0115] Conditional on a User JWT being returned from the user authentication process 600, cloud service 6 then checks whether the User JWT scope includes a scope that allows setting a user role. This can be considered as a User JWT scope that identifies user 602 as an administrator. If the User JWT scope does not include this scope, or if no User JWT was passed, cloud service 6 returns a 706 error and the operation ends. Alternatively, if the User JWT scope does include this scope, cloud service 6 finds the record for user U and sets the user role to the specified role User Role.

[0116] The cloud service 6 then sends an email 710 to the administrator user 602 confirming that the user role for user U has been set to the specified role R. Optionally, the cloud service 6 can also send emails 712 to user U, and optionally to some or all users with administrator or audit roles in the same organization / tenant, to inform them of the role change and request them to report the change if they are not aware of it.

[0117] Similar to processes 500 and 600 described above, OAuth2 or other standard patterns may be used instead.

[0118] FIG. 8 is an illustration of a workflow step policy setting process that may be used in the first and second illustrated embodiments.

[0119] In the workflow step policy configuration process 800 shown in FIG. 8, the process 800 begins when a user 602 authenticates using the user-only authentication process 600 shown in FIG. 6 and obtains a user JWT.

[0120] Next, the user 602 requests that the cloud service 6 create or update 802 a specified workflow step policy passing the user JWT.

[0121] Assuming that a user JWT was returned from the user authentication process 600, if the request 802 was to create a workflow step, the cloud service 6 next checks whether the user JWT scope includes a scope that allows the creation of a workflow step. If the user JWT scope does not include this scope or no user JWT was passed, the cloud service 6 returns an 806 error and the operation ends. Alternatively, if the request 802 was to update a workflow step, the cloud service 6 checks whether the user JWT scope includes a scope that allows the modification of the workflow step. If the user JWT scope does not include this scope or no user JWT was passed, the cloud service 6 returns an 806 error and the operation ends. Furthermore, if no record of the user U is found, the cloud service 6 returns an 706 error and the operation ends.Workflow Step Alternatively, if the user JWT scope includes a scope for creating or updating the requested workflow step, the cloud service 6 stores the requested created or updated workflow step policy.

[0122] Alternatively, if the scope of the user JWT includes creating or updating the requested workflow step, the cloud service 6 stores 810 the policy of the requested created or updated workflow step.

[0123] The cloud service 6 then sends a confirmation to the administrator user 602 that the requested change has been made. Optionally, the cloud service 6 may also send an email 814 to the user U, and optionally to some or all users with administrator or audit roles in the same organization / tenant, informing them of the change to the workflow step policy and requesting them to report the change if they do not recognize it.

[0124] FIG. 9 is an illustration of a bootstrap key injection process that may be used in the first and second illustrated embodiments.

[0125] In order to execute the bootstrap key injection process, there must be a workflow step policy available at the point of manufacture, e.g., manufacturing facility 5. This may be a default workflow step policy. The workflow step policy may be overridden later by a user with appropriate authorization. How such authorization and role management is implemented between organizations is not specified here.

[0126] In the bootstrap key injection process 900 shown in FIG. 9, the process 900 begins when the manufacturing facility 5 generates 902 a bootstrap nonce N_B, for example at a bootstrap provisioning terminal at the manufacturing facility 5.

[0127] Next, the manufacturing facility 5 selects 904 a QKD key ID, ID_K, from the HSM 4a of the local OGR 2a, which is also shared with the OGR 2b connected to the cloud service 6.

[0128] Next, Manufacturing Facility 5 sends 904N_B and ID_K to HSM 4a connected to OGR 2a, and requests the creation of a bootstrap key K_B. HSM 4a of OGR 2a creates 906K_B: K_B=#(Select Key(ID_K),N_B)

[0129] OGR2a then returns 908K_B to Manufacturing Facility5.

[0130] The Manufacturing Facility then notifies the Cloud Service 6 910 of the new target device 8, having the following properties, manufacturer ID, and device ID, and passing the bootstrap nonce N_B. In some examples there may be additional parameters, or the identifier may instead be a simple guaranteed unique ID for the device, such as a 32-byte random number or an IMEI number.

[0131] The cloud service then creates a record 912 for the target device and stores in the database 7 at least the following (other fields may be added as needed, such as service provider): [Table 2]

[0132] Additionally, cloud service 5 initializes the entrusted signature field of the record to a random salt and initializes the entrusted party field of the 916 record to empty.

[0133] The cloud service returns a success code to the Manufacturing Facility 5, which in turn injects the following data into the target device 8: [Table 3]

[0134] The target device 8 then sends a confirmation 824 to the Manufacturing Facility 5 that the injection 920 occurred at 822 .

[0135] As mentioned above, storing the calculated bootstrap key in the database 7 of the cloud service 5 is optional. In the above example, the calculated bootstrap key is stored in the database 7 to avoid that the HSM 4b must indefinitely retain the QKD key for future bootstrap key calculations (i.e., to avoid each authentication having to calculate the bootstrap key anew). This opens up a potential attack vector since the bootstrap key can be read by a database attacker, but also reduces another attack vector, that is, removing the QKD key from the HSM 4b would prevent the target device 8 from being able to authenticate based on the bootstrap key. In some examples, to protect the bootstrap key, it can be stored in the database 7, for example wrapped in a tenant-specific HSM-stored key. In another example, the calculated bootstrap key is not stored in the database 7, and each authentication calculates the bootstrap key anew from the QKD key.

[0136] In another approach, instead of using QKD to calculate the bootstrap key and inject it into the target device, the manufacturing facility 5 or other company can generate its own bootstrap key and inject it into the target device 8 and register this bootstrap key or a hash of this bootstrap key with the cloud service 5 via a classically secure, post-quantum secure, quantum secure or manually secure link. The authentication flow then uses the bootstrap key of the manufacturing facility 5, stored in the bootstrap key field of the database 7, or a hash of this bootstrap key, as the first key in the chain instead of the key calculated by the OGR / HSM by combining the nonce with the QKD key.

[0137] The above examples are explained with reference to the satellite system 100 according to the first embodiment. In the terrestrial system 200 according to the second embodiment, the OGR 2a is replaced by a terrestrial transceiver 9a.

[0138] In some circumstances, it may be desirable to change the workflow step policy associated with a target device 8. As discussed above, this may be necessary, for example, if the bootstrap key was injected into the target device 8 using a default workflow step policy.

[0139] A workflow step policy may be changed by a user who has been authenticated using authentication process 600 and obtained a JWT requesting that cloud service 5 associate a new workflow step policy with a given target device 8. Cloud service 5 then verifies that the JWT scope includes a scope that allows it to associate a workflow step for the target device 8. Cloud service 5 then looks up the record for the target device 8, updates the device record for the target device 8 to point to the new workflow step policy, and zeroes out the workflow ratchet and workflow commissioning records for the device record for the target device 8. Optionally, cloud service 6 may send an email to the user, and optionally some or all users with administrator or audit roles, informing them of the change in the workflow or policy assigned to the particular target device 8 and requesting them to report the change if they are not aware of the change.

[0140] Updating the workflow step for target device 8 will zero out all ratchet keys, causing target device 8 to be reset to an uninitialized bootstrap or factory state where only the bootstrap key can authenticate successfully.

[0141] FIG. 10 is an illustration of a detailed target device authentication process that may be used to authenticate the target device 10 to the cloud system 6 in the first and second illustrated embodiments.

[0142] In the target device authentication process 1000 shown in FIG. 10, the process 1000 begins when the target device 8 initiates an authentication flow 1002 in response to some external stimulus. This external stimulus may be, for example, a user 1004 attempting to connect the target device 8 to the cloud system 6, or it may be, for example, the target device 8 booting up and executing a boot loader that initiates the authentication flow. The target device 8 creates a cha-target device, and optionally a timestamp T_D, and requests authentication from the cloud service 6, passing the following information 1008: ID_M, ID_D, C_D, T_D.

[0143] In response to receiving the authentication request, the cloud service 6 searches the device record 1010 in the database 7 that corresponds to the target device 8 to determine whether a bootstrap key for the target device 8 is stored in the database 7 .

[0144] If the bootstrap key is stored in the database 7, the cloud service 6 recovers the bootstrap key. Alternatively, if the bootstrap key is not stored in the database 7, the cloud service 6 recovers ID_K from the cloud service database 7 and sends N_B and ID_K to HSM 4b connected to OGR 2b of the cloud service 6 and requests HSM 4b to calculate the bootstrap key K_B, as 1014: K_B=#(SelectKey(ID_K),N_B)

[0145] HSM4b then provides the requested bootstrap key to cloud service6.

[0146] If the device record in the database 7 indicates that the target device 8 is in a bootstrapped state, then key K is set to 1018 bootstrap key K_B. Alternatively, if the device record indicates that the target device 8 is not in a bootstrapped state, then the cloud service walks through the key ratchets stored in the workflow ratchet array of the target device record and ratchets the keys to calculate 1020 key K: K[0]=#TK_B,R[0]) and K[n] = #(K[n-1],R[n]) for n = 1 to (workflow step index - 1), so that K = K[n]

[0147] Alternatively, if the ratchet is collapsed into a single value K_CX (see below), the key K can be calculated as follows: K=K_BXORK_CX

[0148] The cloud service 6 then creates a 1022 challenge code C_C and optionally a timestamp T_C, and returns the 1024 challenge code and the timestamp (if applicable) to the target device 8. The cloud service 6 may also return the cloud service's ID, ID_CS, to the target device 8.

[0149] When the cloud service 6 and the target device 8 exchange timestamps, both the cloud service 6 and the target device 8 may verify that the exchanged timestamps are within a predefined time window. For example, the cloud service 6 and the target device 8 may verify that the exchanged timestamps are within one second of each other. If it is determined that the timestamps are not within the predefined time window, authentication is denied.

[0150] Then, in parallel, the cloud service 6 and the target device 8 calculate authentication values ​​1026a and 1026b using the key K that they expect to use for authentication: X_D=#fK,C_D,0) X_C=#fK,C_C,1) R_D=#(X_DC_C) R_C=#(X_C,C_D) The 0's and 1's add directionality and ensure that a mirror attack cannot occur where a dishonest server would simply return C_D as C_C, leading to K_S=(0,0,0,0,0,0,0,0,0,0,0......).

[0151] Alternatively, the cloud service 6 and the target device 8 may each (and in parallel) calculate the authentication values ​​1026a and 1026b using the key K expected to be used for authentication according to the following process: N_D=#C_D,ID_M,ID_D,T_D) N_C=#(C_C,ID_CS,T_C) X_D=#(K,N_D,0) X_C=#(K,N_C,1) R_D=#(X_D,N_C) R_C=#(X_C,N_D)

[0152] The target device 8 then sends 1028 R_D to the cloud service 6. The cloud service 6 compares R_D received from the target device 8 with R_D calculated by the cloud service 6, and if R_D received from the target device matches R_D calculated by the cloud service 6, the cloud service 6 creates 1030 a session key K_S: K_S=X_DXORX_C

[0153] Additionally, cloud service 6 creates a 1032 JWT with the appropriate scope for the key used for authentication.

[0154] Cloud Service 6 then returns the calculated 1034R_C, the JWT, and the session key encrypted with K_CS, a key known only to Cloud Service 6, all encrypted with the session key to the target device 8. K_CS is provided to enable the use of RESTful APIs, and future API calls will be passed the encrypted session key so that it does not need to be cached in Cloud Service 6. Use of K_CS and RESTful APIs is optional. R_C, {JWT, {K_S} K_CS} K_S

[0155] The target device 8 then compares the R_C returned from the cloud service 6 with the R_C calculated on the target device 8. If the R_C returned from the cloud service 6 does not match the R_C calculated on the target device 8, the target device 8 displays an error message 1036 to the user 1004. Alternatively, if the R_C returned from the cloud service 6 matches the R_C calculated on the target device 8, the target device 8 calculates a session key K_S from the locally calculated values: K_S=X_DXORX_C

[0156] The target device 8 then decrypts 1040 the JWT received from the cloud service and decrypts 1042 {K_S}K_CS.

[0157] The target device can then use the session keys, K_S, JWT, and {K_S}K_CS, when making further API calls on this session.

[0158] Alternatively, if the R_D received from the target device 8 does not match the R_D calculated by the cloud service 6 , the cloud service 6 returns an error message 1044 to the target device 8 .

[0159] In response to this error message 1044, the target device 8 should attempt to authenticate again using the bootstrap key since a key revocation (factory reset) process may have occurred that removed all key ratchets within the cloud service 6. If this further authentication attempt fails, the target device 8 cannot authenticate and the failure is audited and logged. Further defenses may also be employed, such as, for example, not allowing more than a specified number of authentication attempts (e.g., 3) from a particular IP address within an hour, or not allowing further authentication attempts of the device from any IP address within an hour.

[0160] Optionally, upon successful authentication with an authentication key that is not the bootstrap key, the current ratchet key can be ratcheted forwards using the bootstrap key (or other value known to both the target device and the cloud service), to provide forward security: K'=#(K_B,K), where K is the most recent key in the array of keys on the target device and K_B is the bootstrap key.

[0161] In an example where this is done, in response to error message 1044, the target device 8 should first attempt to authenticate again after ratcheting forward the last ratchet using a scheme equivalent to the scheme used after successful authentication if the ratchet forward after authentication was successful at the cloud service but failed at the last authentication at the target device, and then, if this authentication attempt also fails, the target device 8 should attempt to authenticate again using the bootstrap key, as described above.

[0162] Additionally or alternatively, the current ratchet can be initialized (if the bootstrap key itself was used for the initial authentication) or replaced with: K=#(X_D,X_C), if a bootstrap key was used for the initial authentication, K is the workflow ratchet initialized in the database, or If K'=#(K,X_D,X_C), where K is the current workflow ratchet associated with the workflow step index and K' replaces K in the database.

[0163] FIG. 11 is an illustrative example of a detailed target device enrollment process that may be used to enroll the target device 10 in the cloud system 6 in the first and second illustrated embodiments.

[0164] In the target device registration process 1100 shown in FIG. 11, the process 1100 is triggered by a user or via some other method. The target device 8 performs the device authentication process 1000 using the latest ratchet key in its possession. The cloud service 6 maintains a state for the target device 8 that defines the current workflow step in the chain of workflow steps for the target device 8. This state starts at 0, meaning that the first registration step by the target device 8 will use the first workflow step in the array of workflow steps defined in the workflow step policy for the target device 8.

[0165] If the JWT returned from the device authentication process 1000 includes the claim "require user auth" or the cloud service 6 returns a flag informing the target device 8 that user authentication is required, the target device 8 requests 1102 a username and password from the user 1004, and the user 1004 provides 1104 a username and password. In some examples, an alternative authentication method may be used instead of or in addition to a password.

[0166] The target device 8 then makes a request 1106 to the cloud service 6 to register the target device 8, providing the session key, the JWT, and a username and password (if required) protected by the encrypted session key: {K_S}K_CS, {JWT}K_S, and optionally {UN_U',P_U'}K_S

[0167] Cloud service 6 then decrypts and verifies the session key using K_CS and returns an error if the session key is not valid. If the session key is valid, cloud service 6 decrypts and verifies the JWT using the session key and returns error 1108 if the device JWT is not valid or does not contain the necessary scopes to access the API.

[0168] Alternatively, if the session key and device JWT are valid, the cloud service 6 loads 1110 workflow step policies, workflow ratchets, and workflow commissioning for the target device 8 from the record for the target device 8 in the database 7 and creates a random salt S_E.

[0169] Next, if an active workflow step (defined by the workflow step index) requires user authentication, the cloud service 6 decrypts the username UN_U and password P_U. The cloud service 6 then looks up the user record 1114 in database 7 and creates a new digest from P_U using S_U. The cloud service 6 then uses the new digest to check if the password is correct by verifying 1116 if the new digest matches the digest in database 7.

[0170] If the digests do not match, the password is incorrect and the cloud service 6 returns an error 1118. Alternatively, if the digests match, the password is correct and the cloud service 6 decrypts the user key K_U using PBKDF2(P_U') or equivalent and initializes the ratchet R 1122: R=#(K_U,K,S_E), where K is the device authentication key.

[0171] The username is then stored in the user authentication field of the target device's 8 most recent workflow commission record, as defined by the workflow step index.

[0172] Alternatively, if no active workflow steps require user authentication, Ratchet R is initialized 1124: R=#(K,S_E) where K is the device authentication key.

[0173] If an active workflow step in the workflow step policy requires delegating agent approval, cloud service 6 checks that the delegating agent signature and required signatures identified in the delegating agent's party field of the active step (defined by the workflow step index) match those in the workflow step policy for that step. If they do not match, registration fails, cloud service 6 sends error 1126, and appropriate audits and logs are created. Alternatively, if the delegating agent signature and delegating agent's party field of the active step match those in the workflow step policy for that step, cloud service 6 combines 1128 ratchet R with the delegating signature S_C to form a new ratchet R': R'=#(R,S_C)

[0174] The cloud service 6 then stores the former ratchet 1130, R, or the latter ratchet, R', as appropriate, in the current workflow ratchet array index (defined by the workflow step index), and then increments the device's workflow step index to transition the target device to the next state.

[0175] If an active workflow step in a workflow step policy requires both user authentication and delegating agent approval, cloud service 6 will not proceed with initializing the new ratchet until a match is confirmed between both the user password and the delegating agent’s signature and delegating agent’s party fields.

[0176] Optionally, to be able to conceal previous ratchets, Cloud Service 6 can collapse all ratchets into a single collapsed XOR value, K_CX, which is then XORed with the bootstrap key to form the latest ratchet key: K_CX=#(K,R)XORK_B where K is the device authentication key or K_CX=#(K,R')XORKB where K is the device authentication key And after that, the latest ratchet key used for the next authentication will simply be: KR=K_BXORK_CX

[0177] In either case, the cloud service 6 returns 1132 to the target device 8 the new ratchet R or R' encrypted by the session key: {R}K_Sor{R'}K_S

[0178] The target device 8 then uses the session key to decrypt R or R', and uses R or R' to calculate the latest ratchet key K_R' from the latest ratchet key K_R that it holds: K_R'=#(K_R,R)or K_R'=#fK_R,R')

[0179] The target device 8 then adds K_R′ to the array of keys held by the target device 8 and uses this key for authentication from now on, and the target device returns an OK message 1136 to the user 1004 .

[0180] FIG. 12 is an illustrative example of a commissioner approval process that may be used to approve workflow steps in the first and second illustrated embodiments.

[0181] In the Commissioner Approval Process 1200 shown in Figure 12, the process 1200 is triggered by a Trusted Role User 1202 using a control device 1204 that has been previously authorized by the process defined above. This control device 1204 runs the device authentication process 1000 using the latest ratchet key in its possession to obtain a control device JWT.

[0182] The controller 1204 requests 1206 a username and password from the commissioning user 1202, and the commissioning user 1202 provides 1208 the username and password to the controller 1204. In some examples, alternative authentication methods may be used in place of or in addition to a password.

[0183] Optionally, the control device 1204 can provide some entropy E; this can be done, for example, by the entrustor 1202 shaking the control device 1204 for a few seconds while an accelerometer in the control device 1204 generates some entropy, or by the entrustor 1202 drawing something on the screen of the control device 1204, or by the control device taking entropy from a random number generator (RNG), or OGR2.

[0184] The control device 1204 obtains the session key K_S calculated during the device authentication process 1000 and passes the control device JWT encrypted with the session key, the target device identifiers ID_M and ID_D also encrypted with the session key, and the username UN_U' and password P_U' to request 1212 that the cloud service 6 approve the next registration state of the given device. {K_S}K_CS,{JWT}K_S,{UN_U',P_U',ID_M,ID_D}K_S,or {K_S}K_CS,{JWT}K_S,{UN_U',P_U',ID_M,ID_D,E}K_S,If entropy is provided

[0185] Cloud service 6 then decrypts and verifies the session key using K_CS, decrypts and verifies 1214 the control device JWT, and returns an error 1216 if the control device JWT is not valid or does not contain a scope that grants authorization to this function.

[0186] Alternatively, if the session key and control device JWT are valid, the cloud service 6 decrypts 1218 the username UN_U', password P_U', and optionally the entropy E. The cloud service 6 then looks up 1220 the user record and creates a new digest using S_U: DP'=#(S_U,P_U')

[0187] The cloud service 6 then uses the new digest to check if the password is correct by checking 1222 that the new digest matches the one in the database and that the user role is commissioner, if they do not match the cloud service 6 returns 1224 an error and the operation ends (audits and logs are created).

[0188] Alternatively, if the new digest matches one in the database and the user's role is commissioner, the cloud service 6 decrypts 1226 the user key K_U using PBKDF2(P_U') or equivalent. The cloud service 6 then locates the current workflow step approval record (defined by the workflow step index) 1228 for the specified target device 8 and loads 1230 the commissioning salt S_C from that record. The cloud service 6 then encrypts, signs or hashes the commissioning salt S_C with K_U, optionally including the device ID, workflow step ID_W, current time, and other data as needed, and stores the result 1232 in the commissioner signature field of that record: S / G={S_C}K_Uor{S_C,ID_M,ID_D,ID_W,TIME}K_U

[0189] Alternatively, if entropy is provided, the cloud service 6 searches for the current workflow step approval record for the specified target device 8 (defined by the workflow step index), encrypts, signs, or hashes the delegation salt S_C with the entropy, optionally including further data as defined above, and stores the result in the delegation agent signature field of that record. S / G={S_C,E}K_U,or{S_C,E,ID_M,ID_D,ID_W,TIME}K_U

[0190] The cloud service 6 adds the user name 1234 to the delegate field of that record and returns 1236 an OK message to the controller 1204 , which displays 1238 an OK message to the user 1202 .

[0191] The process 1200 described with reference to FIG. 12 is an "AND" policy, where all designated commissioning personnel must sign in order to approve a workflow step. In several alternatives, different approval policies may be used. An alternative possible type would be an "OR" policy, whereby only one of the designated commissioning personnel is required to approve. Or, a more complex policy would require the approval of "at least one of the designated commissioning personnel." <n>It is also possible to require "human" approval. In some cases, the commissioning officers, with designated approval rights, may be a group defined in Active Directory or another directory service. This makes it easy to change the membership of the commissioning officer group, for example, in the event of personnel changes.

[0192] 13 is an illustration of the detailed key revocation process used to return the target device 10 to bootstrap, also known as a factory reset, as illustrated in the first and second embodiments.

[0193] 13 illustrates a key revocation process 1300. The process 1300 begins when an administrative user 1302 obtains and authenticates a user JWT using the user-specific authentication process 600 illustrated in FIG.

[0194] Next, the user 1302 requests 1304 that the cloud service 6 revoke keys from a particular target device 8 having a proof ID passing the user JWT.

[0195] Cloud service 6 checks whether the user JWT is valid and whether it contains a scope that verifies that the user is an administrator. If the user JWT is invalid or the user cannot be verified as an administrator, cloud service 6 returns an error at 1308 and the operation is terminated (and an audit log is created).

[0196] Alternatively, if the user JWT is valid and contains a scope that identifies the user as an administrator, the cloud service 6 looks up the device record for the target device 8 by ID in database 7 and resets or clears the workflow ratchet value at 1318. Additionally, the cloud service 6 resets or clears the workflow commissioning at 1320 and sets the workflow step index to zero.

[0197] Cloud service 6 returns OK to 1322 and an audit log is created.

[0198] Optionally, the cloud service 6 can generate a new nonce N_B. This new nonce N_B is used to calculate a new bootstrap key together with the QKD key and is temporarily kept in memory / cache. The cloud service 6 can then inform the target device 8 that all keys have been revoked and the target device 8 authenticates the cloud service 6 using its current bootstrap key and requests access to the new bootstrap key. Once the target device 8 confirms that it has received the new bootstrap key, the new nonce N_B is stored in the database and the old nonce is overwritten. If the target device 8 cannot be contacted, the old bootstrap key should remain in place.

[0199] It can be seen from the above embodiments that the final encryption key is a symmetric encryption key that can be used by the target device 8 and the cloud service 6 as a shared secret key to enable authentication of the target device 8 by the cloud service 6 for session key negotiation and other purposes. The final encryption key can be an AE256 symmetric key.

[0200] FIG. 14 is a schematic diagram of an example of a trustless key provisioning system 1400 according to a third embodiment of the present invention. The third embodiment of the present invention is intended to key fill a bootstrap symmetric key on a computing device that includes a SIM card and acts as a RoT by using a secret present in the SIM card, which is known to the network operator or other parties. As with the first and second embodiments, the key fill is done through a process that can be partially or wholly autonomous, where the supporting cloud service, any human actor, and any party cannot gain access to the symmetric key.

[0201] As shown in FIG. 14, a manufacturing facility 1401 manufactures SIMs 1402, which are then incorporated into a computing device 1403. The computing device 1403 may be a smartphone or other type of device with a communication function. Each SIM 1402 contains a number of inaccessible symmetric encryption keys that are embedded into the SIM card 1402 when the manufacturing facility 1401 manufactures the SIM 1402. Typically, these inaccessible symmetric encryption keys are loaded into the SIM during an initialization layer called "pre-personalization", and then access is locked down by a higher level of initialization. The inaccessible symmetric encryption keys usually consist of an OTA key and an authentication key K, but may also consist of a PIN and a PUK key.

[0202] The embedded symmetric encryption key is used by the mobile network operator (MNO) 1404, among other things, to authenticate the SIM's access to the wireless communications network operated by the MNO 1404. As a result, it will be appreciated that the embedded symmetric encryption key used for SIM authentication must at least be available to both the manufacturing facility 1401 and the MNO 1404 at some point in time. Typically, when the manufacturing facility 1401 produces a batch of SIMs 1402 for the MNO 1404, the manufacturing facility 1401 (or a SIM operator operating in conjunction with the manufacturing facility 1401) transmits 1405 pre-personalization data including the encryption key for the SIMs 1402 to the MNO 1404 in a secure manner, for example via a VPN. The manufacturing facility 1401 and / or the SIM operator then delete the pre-personalization data from their records. It will be appreciated that in order to perform a normal SIM provisioning process, the manufacturing facility 1401 and the MNO 1404 must have a means to allow secure exchange of the symmetric key loaded onto the SIM 1402.

[0203] In the third embodiment, the MNO 1404 transmits data 1406 generated from one of the keys embedded in the SIM 1402 to the cloud service 6 over a secure channel. This secure channel corresponds to the cloud service 6 of the first and second embodiments. The MNO 1404 may comprise a secure node that provides secure quantum communication to the cloud service 6.

[0204] In some examples, the generated data may be a hash of one of the inaccessible symmetric keys on the SIM 1402, or a ratchet diversified with the hash. In other examples, the derived data may be generated by signing a portion of fixed or dynamic data with one of the inaccessible symmetric private keys on the SIM 1402, such as an OTA key or an authentication key, and optionally hashing the result. It will be appreciated that alternative and / or additional processes may be used to derive the derived data from the inaccessible symmetric key, and that the same function is applied on the target device to compute the same derived data. In other examples, the derived data may be derived from an authentication key. Any symmetric key securely loaded on the SIM 1402 at any point during the SIM 1402 manufacturing may be used as the basis for the derived data.

[0205] The cloud service 6 stores the received derived data in a database 7. This database 7 corresponds to the database 7 in the first and second embodiments.

[0206] FIG. 15 shows a general workflow overview of a key provisioning process 1500 performed by the key provisioning system 1400 according to the third embodiment.

[0207] As shown in Figure 15, for each SIM 1402, the key provisioning process 1500 begins with an inaccessible symmetric key pre-loaded on the SIM 1402, which was previously loaded on the SIM 1402 during manufacturing at the manufacturing facility 1401. The MNO 14 then, also having the inaccessible symmetric key in its database, performs a pre-defined derivation operation 1502 to derive derived data 1504 from the inaccessible symmetric key. As previously mentioned, the derivation operation consists of generating a hash of the inaccessible key or signing a piece of data with the inaccessible key, possibly performing an optional hashing operation.

[0208] The MNO 1404 then provisions 1506 the derived data 1504 to the cloud service 6 over a secure channel, possibly using a secure node to perform secure communication with the cloud service 6. To perform the provisioning 1506, the MNO 1404 informs the cloud service 6 that the derived data 1504 is bound to the SIM 1402, e.g., using the secure node. The cloud service 6 stores the derived data provided by the MNO 1404 in a database 7.

[0209] The process 1500 operates in the same manner as the process 300 used in the first and second embodiments, where the derived data is used as or instead of the bootstrap key of the process 300. The derived data used as the bootstrap key is derived from a key stored on the SIM 1402. Thus, the SIM 1402 can regenerate the bootstrap key from the stored key on demand when needed. The bootstrap key can be provided to the computing device 1403, for example, by repeating a hash of the stored key, or by repeating a signature of the same data, possibly using an arbitrary hash, etc. Thus, the computing device 1403 supported by the SIM 1402 can perform an authentication flow to generate the bootstrap key and a subsequent key ratcheted from the bootstrap key if necessary. Similarly, since the cloud service 6 holds the derived data stored in the database 7 as the bootstrap key, the cloud service 6 can perform an authentication flow using the bootstrap key and a subsequent key ratcheted from the bootstrap key if necessary.

[0210] The key provisioning process 1500 securely provides the derived data to the cloud service 6. As mentioned above, the derived data by the SIM 1402 is already available on the computing device 1403. Thus, the computing device 1403 and the cloud service 6 use the derived data (or data derived from the derived data) as a symmetric key pair and ratchet these two keys (i.e., two copies of the same symmetric key / derived data) through identical steps, each of which constitutes a ratchet operation. The same key is arrived at in both the cloud service 6 and device 1403 environments. At each step, the starting key is transformed by the ratchet operation into another new or generated key. These final identical keys can then be used as symmetric keys to act as a RoT, to perform quantum secure communications between the cloud service 6 and the device 1403, or for any other desired task. Thus, the key provisioning process 1500 has two branches that run in parallel, a first branch 1500a which is the upper branch in FIG. 15 and runs the device 1403, and a second branch 1500b which is the lower branch in FIG. 15 and runs the cloud service 6.

[0211] In the illustrated example of the third embodiment, the derived data is derived from a symmetric encryption key. In other examples, in general, the derived data may be derived from any form of shared secret data and may be used as a shared encryption key or the basis for a shared encryption key.

[0212] This key can be used in each branch 1500a, 1500b of the key provisioning process 1500 as an authentication key to authenticate the device 1403 to the cloud service 6, and then generate the next key in the chain. The final key can be used for further authentication, for example to generate a session key or for other purposes.

[0213] Since workflows are defined by policies, different workflows can be defined for different situations by assigning different policies to devices or groups of devices, similar to the methods detailed in relation to the first and second embodiments above.

[0214] According to the third embodiment, the key provisioning process 1500 has a number of objectives, such as: to define a sequence of workflow steps using policies that define the keychain that the device 1403 will use to authenticate to the cloud service 6 for future key negotiation tasks (e.g. negotiating session keys with other devices) or other purposes; to associate the device 1403 with workflow step policies to define whether each step requires user authentication and / or commissioning officer approval; to provision a bootstrap key on the device 1403, since a derived data calculated from a symmetric key stored on the SIM 1402 of the device 1403 is present on the device 1403 as the bootstrap key; and, once the manufacturing facility 1401 or the MNO 1404 transmits the bootstrap key / derived data to the cloud service 6 in a classical or post-quantum cryptographically secured manner or by physical mechanisms, it is ensured that the bootstrap key cannot be intercepted during transmission over a classical communication channel between the device 1403 and the cloud service 6. Using the bootstrap key to enable the device 1403 to contact the cloud service 6 and transition to a new authentication key using a ratchet mechanism that complies with the defined policy, and then using the latest ratchet key to enable the device 1403 to contact the cloud service 6 and transition to a new authentication key using a ratchet mechanism that complies with the defined policy.

[0215] An overview of the key provisioning process 1500 of Fig. 15 according to the third embodiment is as follows: All operations performed by the key provisioning process 1500 and / or the system 1400 will be securely logged and / or audited using a verifiable quantum secure hash chain in a manner similar to the previous embodiments.

[0216] Prior to execution of the key provisioning process 1500, a user of the system 1400 signs up or registers with the cloud service 6 and is assigned roles in a manner similar to the embodiments described above.

[0217] Referring to FIG. 15, the system 1400 provides an acyclic state machine in which a responsible administrator can specify a sequence of workflow steps, thereby defining a key ratchet pipeline that forms branches 1500a, 1500b of the key provisioning process 1500. As with the above embodiment, before the key provisioning process 1500 in FIG. 15 can be executed for the device 1403, the responsible administrator(s) must define a workflow step policy to define one or more workflow steps. Thus, by defining a sequence of steps in the workflow of the key provisioning process 1500, the defined workflow step policy is stored in the database 7 of the cloud service 6. Furthermore, each individual workflow step must also be defined, and these defined workflow steps are also stored in the database 7 of the cloud service 6.

[0218] For brevity and clarity, key filling according to a single workflow policy is described herein with a single device 1403. It will be appreciated that different workflow policies may be configured by different organizations using the system 1400, and each organization may have multiple different workflow policies for different devices 1403 or groups of devices 1403.

[0219] As shown in FIG. 15, for each device 1403, derived data 1503 is derived 1502 from a symmetric key stored in the SIM 1402 of the device 1403 and known to the MNO 1404 to be used as a bootstrap key for the device 1403. The derived data / bootstrap key 1503 is then provided to the cloud service 6, thereby initiating a key provisioning process 1500. Additionally, as part of the provisioning 1506, the MNO 1404 informs the cloud service 6 of metadata relating to the device 1403 and / or SIM 1402, such as the device ID and / or manufacturer and / or SIM ID. Instead of being derived from a symmetric cryptographic key as described above, the derived data used as the bootstrap key can be derived from any form of shared secret data, which may be a shared cryptographic key or may be used as the basis for a shared cryptographic key. The key provisioning process 1500 may be initiated at any time during the life of the device 1403 and SIM 1402, and there is no requirement that it be performed during or near the manufacture of the SIM 1402.

[0220] The cloud service 6 stores the derived data / bootstrap keys provided by the MNO 1404 in its HSM. Because the derived data / bootstrap keys are derived from a symmetric key stored on the SIM 1402, the SIM 1402 can derive the bootstrap key and provide it to the device 1403 on demand when the device 1403 requests the bootstrap key.

[0221] Similar to the embodiment described above, as part of provisioning 1506, the cloud service 6 creates a device record in database 7 for the device 1403. This device record stores a copy of or connects to the workflow policy selected for the device 1403 by the associated administrator(s) and / or MNO 1404 and / or manufacturing facility 1401. Additionally, the cloud service 6 initializes the commissioning signature and commissioning party fields of the device 1403 to zero, and generates and stores a random commissioning salt for use in each workflow step that requires commissioning approval for that device 1403.

[0222] The cloud service 6 initializes a device record in the database 7 for the device 1403 in workflow state bootstrap 1508. Furthermore, the first time the device 1403 attempts to authenticate to the cloud service 6, the device 1403 starts in a known state, bootstrap 1504, using derived data / bootstrap key derived by the SIM 1402 from a symmetric key stored on the SIM 1402.

[0223] Thus, the workflow state of the device 1503 will start at a known state, bootstrap 1504, and the workflow state of the device record for the device 1503 in the cloud service 6 will be the corresponding known state, bootstrap 1508. The device 1503 can transition to the next workflow state if the requirements for the next workflow state are met as defined in the workflow step policy assigned to the device 1503. The bootstrap key allows access to a limited set of cloud service APIs.

[0224] The system 1400 provides a means for the device 1403 to authenticate to the cloud service 6 using either the bootstrap key or a key ratcheted from the bootstrap key. Each time, the cloud service 6 builds the keychain required for authentication from initial derived data, which may be stored in the HSM to generate the bootstrap key. Subsequent keys based on the bootstrap key can be calculated by the cloud service 6 using a stored ratchet value held in the database 7. Once the device 1403 authenticates to the cloud service 6 using either the bootstrap key or a key ratcheted to the bootstrap key, the cloud service 6 returns a token to the device 1403, whose scope is defined by the workflow step, for example a Jason Web Token (JWT). The cloud service 6 authenticates the device 1403 using a challenge response to generate a session key from the combination of the current key (the bootstrap key or a key ratcheted from the bootstrap key) and two challenge codes that are exchanged between the device 1403 and the cloud service 6 and then discarded.

[0225] The cloud service 6 uses a key that encrypts the client state K_CS of the device 1403 to allow RESTful APIs, as in the above embodiment.

[0226] If a workflow step requires commissioning personnel approval to migrate a target device 8, a similar process is used as described in the previous embodiment.

[0227] Once the device 1403 has properly authenticated to the cloud service 6 using the bootstrap key or a key ratcheted from the bootstrap key, the device 1403 receives an authentication token, such as a JWT, from the cloud service 6 and negotiates a session key with the cloud service 6. The user of the device 1403 can then initiate the provisioning process of the device 1403 with the cloud service 6.

[0228] To register the device 1403 with the cloud service 6, the device 1403 calls the provisioning function, passing an authentication token and (optionally) user credentials if required for the workflow step. The cloud service 6 can authenticate the user, optionally using a password and optionally using two-factor authentication (2FA). In response to receiving the token, if the optionally selected user authentication is successful, the cloud service 6 generates some random data and uses it to create a ratchet value. This ratchet value is used to ratchet the current latest ratchet key to the next ratchet key. This value is then stored in the database 7 in an array of ratchet values ​​associated with the device 1403. Optionally, if the current device 1403 workflow step requires approval from a commissioning officer and the required approval is stored in the commissioning signature field associated with that workflow step, the commissioning signature list is combined with the workflow step's ratchet value. This ratchet value is used as the latest in a series of ratchet values ​​and can be used in the future to calculate new authentication keys on demand from the stored derivation data.

[0229] The cloud service 6 then returns the ratchet value to the device 1403, allowing the target device 1403 to also create a new ratchet value from the most recent key in its set of ratchet values ​​and create a new authentication key. Thus, a new ratchet value is created from the derivation data / bootstrap key during the first registration, and from the key created during the previous registration during subsequent registrations.

[0230] As shown in Figure 15, when the device 1403 is in the bootstrap state 1504, the key provisioning process 1500 continues with the user of the device 1403 authenticating and registering with the cloud service 6 using the authentication and provisioning process described above. If the authentication and provisioning process is successful and the commissioning officer approval identified as required by the next workflow step of the workflow step policy applied to the device 1403 is received, the cloud service 6 generates the ratchet value described above and uses the ratchet value to create a ratchet authentication key from the bootstrap key. The cloud service 6 then ratchet forwards 1510 the status of the device 1403 in the device record in the database 7 from the bootstrap state 1508 to the next workflow state, in the example of Figure 15, the intermediate state 1512 named "Quarantine".

[0231] Next, or simultaneously, the cloud service 6 sends the ratchet value to the device 1403, which creates the same ratchet authentication key from the bootstrap key, which was previously created using the symmetric key as described above, and the target device 8 ratchet-forward 1514 its status from the Bootstrap state 1504 to the next workflow state, such as the intermediate state 1516 named "Quarantine" in the example of Figure 3.

[0232] In the example of FIG. 15, if the device 1403 is in the intermediate state "Quarantine" 1516 and the status of the device 1403 in the device record in the database 7 is also in the intermediate state "Quarantine" 1510, the device 1403 is given limited connectivity to the system and network by the cloud service 6 if the device 1403 successfully authenticates and registers with the cloud service 6. This limited connectivity is chosen so that the device 1403 cannot harm or compromise the security of the cloud service 6 while in the intermediate state "Quarantine" 1514. In some instances, when the device 1403 is in the intermediate state "Quarantine" 1516 and given limited connectivity therein, it may be allowed to connect only to the closed quarantine network.

[0233] Next, with the device 1403 in the intermediate state "quarantine", the user of the device 1403 again authenticates and registers the device 1403 with the cloud service 6 using the authentication and process described above, continuing the key provisioning process 1500. If the authentication and provisioning process is successfully completed and the commissioning officer approval identified as required by the next workflow step of the workflow step policy applied to the device 1403 is received, the cloud service 6 further generates the ratchet value described above and uses this additional generated ratchet value to create a new ratchet authentication key from the ratchet key, which in turn is generated from the bootstrap key and the selected QKD key, as described above. The cloud service 6 then ratchet-forward 1518 the status of the device 1403 in the device record in the database 7 from the intermediate state “Quarantine” 1512 to the next workflow state, such as the final state 1520 named “Production” in the example of FIG. 15 .

[0234] The cloud service 6 then, or simultaneously, sends the additionally generated ratchet value to the device 1403, which generates a similar new ratchet authentication key from the ratchet key that was previously generated from the bootstrap key and the symmetric key, as described above. The device 1403 then ratchet-forwards 1522 its status from the intermediate state "Quarantine" 1516 to the next workflow state, such as the final state "Production" 1524 in the example of FIG. 15.

[0235] In the example of FIG. 15, when the device 1403 is in the final state “Produced” 1524 and the state of the device 1403 in the database 7 is also the final state “Produced”, the device 1403 is granted full connectivity by the cloud service 6 if it has successfully authenticated and registered with the cloud service 6. The connectivity provided here can be configured by the connectivity policy of the MNO 1404, the organization that manages the device 1403. The final “Produced” key allows access to a wider range of cloud service features than the “Quarantine” state. The access provided is defined by the scope of the associated workflow policy.

[0236] The example of FIG. 15 shows a key provisioning process 1500 in which the device 1403 is ratcheted from an initial bootstrap state 1504 to an intermediate state "quarantine" 1516 to a final state "production" 1524 providing full connectivity to the system and network. In other examples, there may be any number of intermediate states between the initial bootstrap state and the final production state as required by a particular organizational policy. These intermediate states are configured to include the same examples shown in the example of FIG. 3. The requirements for ratcheting the device 1403 from one state to the next can be configured as desired, including whether and how many user authentication and commissioning approvals are required. It is not mandatory to provide an intermediate state "quarantine" that provides limited connectivity.

[0237] In some circumstances, it may become necessary to revoke all keys associated with the device 1403 and return the device 1403 to the state it was in at its original manufacturing facility. This is accomplished by zeroing all commissioning party and commissioning signature fields, zeroing all ratchet fields, and setting the current workflow step back to the start. This resets both the device 1403 and its record in database 7 to the bootstrap states 1504 and 1508, respectively. The device 1403 can then begin the registration process again if desired.

[0238] According to the third embodiment, the APP provider is provided with an SDK, which enables the APP provider to form a secure session and call an API on a cloud service without leaking information about the SIM or the symmetric key on the SIM.

[0239] It will be appreciated that while the derivation data is provided to the cloud service by the MNO, the bootstrap key is potentially vulnerable as it is known to the MNO, and therefore any subsequent keys generated from the bootstrap key by the ratcheting process are unknown to the MNO.

[0240] From the above, it will be appreciated that the third embodiment disclosed is capable of achieving the goals set out above.

[0241] The third embodiment may be carried out along the lines of the more detailed examples presented above in relation to the first and second embodiments and explained with reference to Figures 4 to 13 .

[0242] In the illustrated example of the third embodiment described above, the MNO performs the provisioning of the derivation data to the cloud service.

[0243] In the illustrated example of the third embodiment described above, the derived data provided to the cloud service 6 is used as a bootstrap key. In other examples, the derived data may be further processed to generate a bootstrap key, provided that both the cloud service 6 and the device 1403 with SIM 1402 are capable of performing the same additional processing.

[0244] In the illustrated example of the third embodiment above, the SIM may be, for example, a physical SIM card or an eSIM.

[0245] The example of the third embodiment above uses a SIM with a symmetric key. In other examples, any user device with an existing shared secret installed can be used, where the installed shared secret is used as the basis for the derivation data. In some examples, the existing shared secret may be a symmetric cryptographic key. An example of such a device is a Trusted Platform Module (TPM).

[0246] The third embodiment can be used at any time, including after the device leaves the manufacturer, and is under the control of the end user. In the example where the device is a mobile phone or other device with a SIM for mobile communication, the third embodiment can be used at any time during the life of the phone, even after it has been deployed for many years, because an app on the phone can derive the bootstrap key, and the cloud service can store the bootstrap key, or the MNO can provide it to the cloud service.

[0247] As can be seen from the above, the disclosed embodiments allow a device to be key-filled with a symmetric encryption key. The commissioning personnel does not have access to or knowledge of the final output encryption key deployed on the device. Furthermore, due to the memory protection used to store the keys on the device, the user of the device does not have any knowledge of the bootstrap key or the final output encryption key distributed to the device. Thus, the security of the production encryption key distributed to the device is guaranteed and the production encryption key can be loaded onto the device in a trustless manner. Here, there is no expectation that any of the parties involved will have possession of the production encryption key distributed to the device other than the cloud service. Of course, a shared copy of the symmetric production encryption key must be in possession in order to authenticate the device and provide the service. The key-filling of the device is possible without security personnel having to physically go to the device and manually key-fill the device.

[0248] In some examples, a user may be provided with a "force" code that the user can enter when attempting to log on to a cloud service using their device. In response to the force code, the cloud service revokes the cryptographic keys output by the device, thereby preventing unauthorized use. In some examples, in response to the force code, the cloud service may remotely wipe the device. In some examples, in response to the force code, the cloud service may load altered or counterfeit data onto the device in order to conceal the use of the force code from third parties.

[0249] The output encryption key enables the device to access cloud services. The device's web usage can be limited to authorized destinations selected by the organization managing the device through authorization settings within the cloud service. The device's web usage and access to other resources can be fully regulated, logged, and verified by services provided within the cloud service.

[0250] The use of various cryptographic keys allows for different stages in the key distribution process, allowing for a centralized management and control of the key provisioning process in a secure manner, limiting the network exposure of devices, applications and users involved in the process.

[0251] The method of the present application allows the use of cloud services to make the process of key provisioning and commissioning a secure, verified transaction that can be fully audited.

[0252] For simplicity and clarity, the above example is for distribution of a single encryption key to a single target device, however, this methodology allows for distribution of any number of encryption keys to any number of target devices via automated, trustless key filling.

[0253] The methods of the present application can be used to distribute large volumes of keys, such as automation keys and device bootstrap keys, on a B2B or B2C model to, for example, network carrier-based service providers, device manufacturers, governments, large enterprises, and individual organization / user groups.

[0254] As can be seen from the above, the method of the present application provides a global solution for quantum secure key provisioning and management of symmetric keys, which can support the global flow of data and information over secure private channels, the global flow and management of actors, and the global authentication of devices, users, systems and access.

[0255] In the illustrated embodiment, the encryption key is deployed to a target device, which can be any type of device, such as an endpoint device (EPD). The target device to which the encryption key is deployed does not have to be an individual device; a "target device" can be a system or any type of endpoint.

[0256] In some instances, while a device is in a quarantine state, necessary updates to the device may be performed, such as software or profile updates, maintenance, or system access updates, but the cloud service does not provide full connectivity to the device. This list is not intended to be exhaustive.

[0257] In the above embodiment, the system includes at least one satellite 1 according to the first embodiment. In some examples, the system may have a collection of satellites including satellites with different capabilities, for example different optical communication capabilities and / or capabilities supporting different quantum key provisioning techniques.

[0258] In the embodiment described above, the system includes two optical terrestrial receivers (OGRs) 2. A system may have any number of OGRs 2. There may be many OGRs 2, for example 10,000 or more.

[0259] In the above described embodiments, the HSM 4 may be physical or virtual.

[0260] In the embodiment described above, the HSM 4 is configured within the OGR 2. In other examples, some, but not all, of the HSM 4 may be securely connected to the OGR 2. In some examples, the HSM 4 is controlled by a user of the system.

[0261] The embodiment described above includes a manufacturing facility 5. Instead, in other examples, any type of facility may inject a bootstrap key into a device, allowing it to communicate with cloud services in a secure manner.

[0262] In the embodiment described above, the manufacturing facility communicates with the cloud service using a bootstrap terminal, however this is not required and other means may be used.

[0263] In the embodiment described above, the system is a quantum key provisioning system. In other examples, other cryptographic items may be provisioned, distributed, or delivered in addition to or as an alternative to cryptographic keys. Examples of other cryptographic items include cryptographic tokens, cryptographic coins, and value transfers.

[0264] The embodiments described above are fully automated, although in some instances a user or operator of the system may manually instruct the execution of the method steps.

[0265] In describing embodiments of the present invention, parts of the system may be implemented in the form of computing devices and / or electronic devices. Such devices may include one or more processors, such as a microprocessor, controller, or other suitable type of processor. These processors may process computer-executable instructions for controlling the operation of the device and may collect and record routing information. In some instances, such as where a system-on-chip architecture is used, the processor may include one or more fixed function blocks (also called accelerators) that implement some of the methods in hardware (rather than software or firmware). Platform software, consisting of an operating system or other suitable platform software, may be provided in the computing-based device to enable application software to be executed on the device.

[0266] Various functions described herein may be implemented in hardware, software, or a combination thereof. When implemented in software, they may be stored or transferred as one or more instructions or codes on a computer-readable medium. Computer-readable media include, for example, computer-readable storage media. Computer-readable storage media may include volatile or non-volatile, removable or non-removable media, which may be implemented by any method or technology for storing information, such as computer-readable instructions, data structures, program modules, or other data. Computer-readable storage media may be any storage medium accessible by a computer. By way of example and not limitation, such computer-readable storage media include RAM, ROM, EEPROM, flash memory, or other memory devices, CD-ROM or other optical disk storage, magnetic disk storage, or other magnetic storage, or any other medium that may be used in the form of instructions or data structures to transmit or store requested program code and that may be accessed by a computer. Disks and disks as used herein include compact discs (CDs), laser discs, optical discs, digital versatile discs (DVDs), floppy disks, and Blu-ray discs (BDs). Moreover, radio signals are not included within the scope of computer-readable storage media. Computer-readable media also includes communication media, which includes any medium that facilitates the transfer of a computer program from one place to another. A connection can be any communication medium. For example, if the software is transmitted from a website, server, or other remote source using coaxial cable, fiber optic cable, twisted pair, DSL, or wireless technologies such as infrared, radio, or microwave, it is included in the definition of communication media. Combinations of the above are also included within the scope of computer-readable media.

[0267] Alternatively, or in addition, the functionality described herein may be performed, at least in part, by one or more hardware logic components, including, but not limited to, field programmable gate arrays (FPGAs), program specific integrated circuits (ASICs), program specific standard products (ASSPs), systems on a chip (SOCs), complex programmable logic devices (CPLDs), and the like.

[0268] Although illustrated as a single system, it should be understood that the systems of the first and second embodiments may also be distributed systems.

[0269] The above benefits and advantages may relate to one embodiment or to multiple embodiments. The embodiments are not limited to those that solve any or all of the problems described or have any or all of the benefits and advantages described. Variants should be considered within the scope of the present invention.

[0270] A reference to an item is a reference to one or more of those items. As used herein, the term "comprising" is intended to include the identified method steps or elements, but such steps or elements do not constitute an exclusive list and methods and apparatus may include additional steps or elements.

[0271] As used herein, the terms "component" and "system" are intended to encompass computer-readable data storage configured with computer-executable instructions that, when executed by a processor, perform a particular function. Computer-executable instructions may include routines, functions, or the like. It should be understood that a component or system may be localized on a single device or distributed across multiple devices.

[0272] Moreover, the word "exemplary" as used herein is intended to mean "serving as an illustration or example of something."

[0273] Moreover, to the extent the term "including" is used in either the detailed description or the claims, such term is intended to be inclusive, just as the term "comprising / including" may be used as a transitional term in the claims.

[0274] The figures illustrate example methods. Although the methods are shown and described as a series of acts performed in a particular sequence, it should be understood that the methods are not limited by the order of the sequence. For example, some acts may occur in a different order than described herein. Additionally, some acts may occur simultaneously with other acts. Additionally, sometimes not all acts are required to perform the methods described herein.

[0275] Additionally, the operations described herein comprise computer-executable instructions that can be executed by one or more processors and / or stored on a computer-readable medium. Computer-executable instructions may include routines, subroutines, programs, threads of execution, and / or the like. Additionally, results of the operations of the methods may be stored on a computer-readable medium, displayed on a display device, and / or the like.

[0276] The ordering of steps of the methods described herein is illustrative, but may be performed in any suitable order, or simultaneously where appropriate, and steps may be added or substituted, or individual steps may be deleted, from any method without departing from the subject matter described herein. Aspects of any of the above-described examples may be combined with aspects of any of the other examples described to form further examples without losing the effect sought.

[0277] It should be understood that the above description of the application is given by way of example only, and various modifications may be made by those skilled in the art. The above description includes one or more examples of the embodiments. Of course, it is not possible to describe all possible modifications and changes to the above device or method for the purpose of describing the above aspects, but one of ordinary skill in the art can recognize that many further modifications and substitutions are possible for various aspects.< / n>

Claims

1. The encryption key provisioning method consists of: Providing shared secret data to devices and to security services in a quantum computing secure manner; Using the shared secret data to provide a root key; and Using the root key as the basis for a series of stages, each stage involves an operation that transforms the starting key into a different generated key, and in parallel, the same stages are performed on the device and the security service; the root key is used as a start key for the first stage of the sequence, and the generated keys generated at each stage of the sequence, except for the final stage of the sequence, are used as start keys for the next stage of the sequence; and The generated key is generated by the device and the security service in the final stage of the sequence and is a symmetric key.

2. 10. The method of claim 1, further authenticating the device to the security service using a generated key generated by the device and a final stage of the security service.

3. 3. A method according to claim 1 or claim 2, wherein the shared secret data is a symmetric encryption key or data derived from a symmetric encryption key.

4. A method according to the preceding claims, wherein the start key of each stage of the series of stages is used as a symmetric key in the device and in the security service to authenticate the device to the security service and to enable secure communication between the device and the security service.

5. 5. The method of claim 4, further comprising after the device has been authenticated to the security service, the security service sending data to the device and using this data to convert the starting key into a different key for the current stage in the sequence of steps.

6. 10. A method according to any preceding claim, wherein each of said stages comprises a ratchet operation.

7. 7. A method as claimed in claim 6, when dependent on claim 5, wherein said transmitted data is a ratchet value.

8. 2. A method according to the preceding claims, wherein there are a plurality of stages in the sequence of stages.

9. 9. The method of claim 8, wherein the sequence of stages generates a corresponding sequence of keys, different keys in the sequence of keys being associated with different scopes or permissions when used as symmetric keys to authenticate a device to a security service.

10. 4. The method of claim 3, wherein the provided symmetric encryption key or data derived from the symmetric encryption key is used as a root key.

11. 4. The method of claim 3, wherein the provided symmetric encryption key or data derived from the symmetric encryption key is further processed to provide a root key.

12. 12. The method of claim 3, 10 or 11, wherein the symmetric encryption key or data derived from the symmetric encryption key is provided to devices and security services by a quantum key distribution (QKD) method.

13. 12. A method according to any one of claims 3, 10 or 11, wherein the symmetric encryption key or data derived from the symmetric encryption key is provided to devices and security services by classically secure or physical mechanisms.

14. 12. The method of claim 3, 10 or 11, wherein the symmetric encryption key is derived from keys provided to the device and the security service by a quantum key distribution (QKD) method.

15. 12. The method of claim 3, 10 or 11, wherein the symmetric encryption key is derived by a classically secure or physical mechanism from keys provided to the device and the security service.

16. 12. The method of claim 3, 10 or 11, wherein the symmetric encryption key derived data is derived from a symmetric encryption key stored on the device.

17. 17. The method of claim 16, wherein the device is or comprises a SIM, and the symmetric encryption key is stored on the SIM.

18. 18. The method of claim 17, wherein the symmetric encryption key is an OTA key.

19. 18. A method according to claim 16 or claim 17, wherein the data derived from the symmetric encryption key on the SIM is provided by a Mobile Network Operator (MNO) associated with that SIM.

20. A method according to the preceding claims, wherein at least one stage of the sequence of stages requires user authentication in order for that stage to be completed.

21. A method according to the preceding claims, wherein at least one stage of the sequence of stages requires authorization in order for the stage to be completed.

22. 22. The method of claim 21, wherein said authorization must be provided by a commissioning official.

23. 10. A method according to the preceding claim, wherein the sequence of stages is defined by a workflow.

24. 24. The method of claim 23, wherein the workflow is configurable to require user authentication to complete one, some or all of a sequence of stages.

25. 25. A method according to claim 23 or claim 24, wherein the workflow is configurable to require one or more authorizations to complete one, some or all of a sequence of stages.

26. 26. The method of claim 25, wherein the workflow is configurable to specify who is required to perform each of one or more authorizations.

27. A method according to any one of claims 2 to 4, or according to any dependent claim of any one of claims 2 to 4, wherein following authentication of a device to a security service, the security service issues a token to the device having a scope related to the stage of the key used to perform the authentication.

28. 28. The method of claim 27, wherein the token is a Jason Web Token (JWT).

29. 10. The method of claim 9, wherein said security service is a cloud service.

30. The device authentication method consists of: Providing shared secret data to the device and also to the security service in a quantum computing secure manner; Using the provided shared secret data to provide a root key; and using a root key as the basis for a sequence of stages, each of which consists of an operation that transforms a starting key into a different generated key, the same stages being executed in parallel on the device and on the security service; the root key is used as a starting key for a first stage of the sequence, and the generated keys generated at each stage of the sequence, except for the final stage of the sequence, are used as starting keys for the next stage of the sequence; Further included is using the generated key generated by the final stage of the sequence at the device and the security service to authenticate the device to the security service.

31. Symmetric key provisioning method components: Providing data derived from secret data on the device to a security service in a quantum computing safe manner; providing a root key using the provided data derived from the secret data; Using the root key as the basis for a series of stages, each stage involves an operation that transforms the starting key into a different generated key, and in parallel, the same stages are performed on the device and the security service; the root key is used as a start key for the first stage of the sequence, and the generated keys generated at each stage of the sequence, except for the final stage of the sequence, are used as start keys for the next stage of the sequence; The generated key is generated by the device and the security service in the final stage of the sequence and is a symmetric key.

32. The device authentication method consists of: Providing data derived from secret data on the device to a security service in a quantum computing safe manner; Providing a root key using the provided data derived from the secret data; and Using the root key as the basis for a series of stages, each stage involves an operation that transforms the starting key into a different generated key, and in parallel, the same stages are performed on the device and the security service; the root key is used as a start key for the first stage of the sequence, and the generated keys generated at each stage of the sequence, except for the final stage of the sequence, are used as start keys for the next stage of the sequence; It further includes using the generated key generated by the final stage of the sequence at the device and the security service to authenticate the device to the security service.

33. An encryption key provisioning system consists of: A method for providing shared secret data to a device and to a security service using a quantum computing-safe method; A method configured to use the provided shared secret data to provide a root key; and a method for configuring a system to use a root key as the basis for a sequence of stages, each of which includes an operation to convert the starting key into a different generated key, in parallel with the system executing the same stages on the device and the security service; The root key is used as a start key for a first stage of the sequence, and the generated keys generated by each stage of the sequence, except for the final stage of the sequence, are used as start keys for the next stage of the sequence; and the generated keys generated by the final stage of the sequence at the device and security service are symmetric keys.

34. 34. A system according to claim 33, further comprising a mechanism arranged for the device and the security service to use the generated key generated by the final stage of the sequence to authenticate the device to the security service.

35. A system according to claim 33 or claim 34, wherein the shared secret data is a symmetric encryption key or data derived from a symmetric encryption key.

36. The device authentication system consists of: providing said shared secret data to the device and to the security service in a quantum computing secure manner; A method configured to use the provided shared secret data to provide a root key; and a method for configuring a root key to be used as the basis for a sequence of stages, each of which includes an operation to convert the starting key into a different generated key, and for performing the same stages in parallel on the device and in the security service; the root key is used as a start key for a first stage of the sequence, and the generated keys generated by each stage of the sequence, except for the final stage of the sequence, are used as start keys for the next stage of the sequence; and The method further includes configuring the device and the security service to use the generated key generated by the final stage of the sequence to authenticate the device to the security service.

37. 37. The system of claim 36, wherein the shared secret data is a symmetric encryption key or data derived from a symmetric encryption key.

38. An encryption key provisioning system consists of: A method for providing a security service with data derived from secret data stored on the device using quantum computing-safe methods; A method configured to use provisioning data derived from secret data to provide a root key; and a method for configuring a root key to be used as the basis for a sequence of stages, each of which includes an operation to convert the starting key into a different generated key, and for performing the same stages in parallel on the device and in the security service; the root key is used as a start key for a first stage of the sequence, and the generated keys generated by each stage of the sequence, except for the final stage of the sequence, are used as start keys for the next stage of the sequence; and The generated key generated by the final stage of the sequence in the device and security service is a symmetric key.

39. 39. A system according to claim 38, further comprising a mechanism arranged for the device and the security service to use the generated key generated by the final stage of the sequence to authenticate the device to the security service.

40. A system according to claim 38 or claim 39, wherein the secret data is a symmetric encryption key or data derived from a symmetric encryption key.

41. The device authentication system consists of: A method for providing a security service with data derived from secret data stored on the device using quantum computing-safe methods; A method configured to use provisioning data derived from secret data to provide a root key; and a method for configuring a root key to be used as the basis for a sequence of stages, each of which includes an operation to convert the starting key into a different generated key, and for performing the same stages in parallel on the device and in the security service; the root key is used as a start key for a first stage of the sequence, and the generated keys generated by each stage of the sequence, except for the final stage of the sequence, are used as start keys for the next stage of the sequence; and further including a method configured for the device and the security service to use the generated key generated by the final stage of the sequence to authenticate the device to the security service.

42. 42. The system of claim 41, wherein the secret data is a symmetric encryption key or data derived from a symmetric encryption key.

43. A computer readable medium having stored thereon code or computer instructions which, when executed by a processor, cause the processor to perform a method according to any of claims 1 to 29, claim 30 or claims 31 to 32.

44. A computer program comprising instructions which, when executed by a processor, cause the processor to perform a method according to any of claims 1 to 29, claim 30 or claims 31 to 32.

Images