Method and arrangement for establishing a digital identity - Patents.com

Abstract

A system may use a secure transport mechanism (120) comprising a random data generator configured to generate a cryptographic seed (102, PU0). The system may generate a cryptographic intermediate product (105) through a first cryptographic operation (104, 204). The cryptographic intermediate product is deterministically dependent on both the cryptographic seed and a user secret (113, USS) received through the secure transport mechanism. The cryptographic intermediate product constitutes a digital identity of a party. A second cryptographic operation (106) is then applied to the digital identity of the party to generate a cryptographic output (107) including the cryptographic seed in encrypted form, at least a portion of which is transmitted via the secure transport mechanism.

Description

[Technical field]

[0001] The present invention relates generally to the technical field of security required when using digital services. In particular, the present invention relates to the problem of centrally establishing trust between parties that may rely on said centrally established trust in a distributed use of digital services. Background of the invention

[0002] Security in digital communications includes several aspects, such as confidentiality (only authorized parties can access information), authentication (parties must be sure that they are who they are communicating with), integrity (information has not been altered in an unauthorized way), and non-repudiation (parties cannot deny having sent certain information). For authentication, it is common to rely on a third party called a trust provider. A computer or smartphone user who wants to communicate with a service provider's website must first contact the trust provider's authentication service. This is usually done with a user ID and a disposable key. The disposable key is read from a printed list carried by the user or provided by a dedicated app running on the user device. Once the authentication service has verified the user's identity, the user is redirected to the website he or she was trying to communicate with, along with a digital certificate issued by the trust provider.

[0003] At a conceptual level, digital authentication can be compared to the well-known traditional practice of physically presenting an ID card, passport, driver's license, or any other official document previously obtained by a user from an authority. It is widely agreed that if the nature of such an official document is sufficiently trustworthy, the user should be free to reuse it whenever he or she likes, at least for a certain period of time from the date of issue.

[0004] A drawback of known arrangements in the digital world is the continuous dependency of the communicating parties on the trust provider: every time the user wants to get in touch with the service provider, the same authentication routine has to be repeated, resulting in additional costs that are ultimately paid by the user.

[0005] Another problem with known arrangements is that they tie users into customer relationships with, for example, banks, telecommunications carriers, or other intermediate parties that may not be closely related to the communications the user wishes to have with the service provider. In order to provide better independence to users and to eliminate such intermediate parties from acting as gatekeepers with at least the theoretical possibility of monitoring when, where, and with whom the user has secure digital communications, it is desirable to centralize (centralize) the provision of digital identities and related services under a government or other trusted authority.

[0006] Known arrangements have further drawbacks, dating back to the days of printed identity certificates, such as printed passports, driver's licenses, and ID cards. They usually require the user to share a lot of information with the service provider. A trivial example is when a user is asked to show ID when buying an alcoholic drink, and the salesperson is in fact only entitled to know if the user is over or under the legal age. By showing his driver's license, however, the user reveals his exact age, his social security number, the class of car he is allowed to drive, etc. A similar situation occurs with digital certificates, because the trust provider usually does not know at the time of the authentication request from the user what the digital certificate will be used for in the user's later communication with the service provider. As a result, the electronic certificate may contain more information about the user than is necessary. Abstract

[0007] This section is provided to introduce some of the concepts described later in the detailed description in a simplified form. This section is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used to limit the scope of the claimed subject matter.

[0008] It is an object to provide a method and arrangement for establishing, using and enabling digital identities of parties without the drawbacks of the prior art as mentioned above. In particular, it is an object to enable users, service providers and other parties wishing to engage in secure digital communications and transactions to establish, use and enable digital identities without continually relying on a third party to provide trust, i.e., without going through a direct trust relationship. A further object is to enable parties to exchange only the information necessary for the purposes of secure digital communications. Furthermore, a particularly important object is to ensure confidentiality and data protection in all respects relating to the establishment and use of digital identities.

[0009] According to a first aspect, there is provided a system for establishing a digital identity of a party. The system comprises a random data generator configured to generate a cryptographic seed, and a receiving side and a transmitting side of a secure transport mechanism. A first cryptographic operation is coupled to the random data generator and to the receiving side of the secure transport mechanism, and a second cryptographic operation is coupled to the first cryptographic operation and to the transmitting side of the secure transport mechanism. The system is configured to generate, through the first cryptographic operation, a cryptographic intermediate product that is deterministically dependent on both the cryptographic seed and a user secret received through the secure transport mechanism. The cryptographic intermediate product constitutes the digital identity of the party. The system is configured to generate, through the second cryptographic operation, a cryptographic output that includes the cryptographic seed in encrypted form using the digital identity of the party. The system is configured to transmit at least a portion of the cryptographic output via the secure transport mechanism.

[0010] In some embodiments, the system is configured to permanently obfuscate the digital ID in memory after using the digital ID in the generation of the cryptographic output, which provides at least the advantage that there is no risk of the digital ID being accidentally revealed at a later time, at least by any action associated with the system.

[0011] In some embodiments, the system is configured to generate a cryptographic certificate for the party as part of the cryptographic output through the second cryptographic operation, which provides at least the advantage that the party can later use the cryptographic certificate for authentication without having to access the system again.

[0012] In some embodiments, the system comprises a pre-provisioning function configured to respond to a received pre-provisioning request indicating an identifier and at least one attribute of the participant, by establishing a temporary secret for the participant and sending a pre-provisioning response including at least a portion of the temporary secret. The system may further comprise a registration completion function configured to respond to a registration completion request received after the sending of the pre-provisioning response by verifying the contents of the registration completion re-request against the temporary secret. The pre-provisioning function may be configured to encrypt and store the identifier and the at least one attribute in a temporary encrypted archive specific to the participant using the cryptographic seed. The registration completion function may be configured to encrypt and store the identifier and the at least one attribute in a final encrypted archive specific to the participant using the user secret received in the registration completion request. The system may further be configured to use the digital ID in the encryption and storage of the identifier and the at least one attribute in the final encrypted archive. This provides the advantage that at least for participants who have not yet provided a user secret required to complete the registration of a user, certain preparatory actions can be performed and some temporary encrypted product can be generated.

[0013] In some embodiments, the pre-provisioning functionality is configured to generate an ephemeral pair of keys of an asymmetric cryptographic system as the temporary secret for the party and to send a public key of the ephemeral pair of keys in the pre-provisioning response, which has the advantage of providing at least additional security for the steps required to later establish a digital identity for the party.

[0014] In some embodiments, the pre-provisioning functionality is configured to use the random number provided by the random data generator as a private key of the pair of ephemeral keys and generate a public key of the pair of ephemeral keys from the private key of the pair of ephemeral keys using the Curve25519 Elliptic Curve Diffie-Hellman method, which provides at least the advantage that the generated key pair may bear a certain mathematical relationship to a corresponding key pair generated by a party establishing a digital identity, thereby simplifying further steps of the process.

[0015] In some embodiments, the pre-provisioning functionality is configured to generate a first shared secret by a first mathematical operation using the private key of the pair of ephemeral keys and a public key received from an entity external to the system, and to use the first shared secret when encrypting and storing the identifier and the at least one attribute in the temporary encrypted archive, which provides further advantages related to the mathematical relationship between keys discussed above.

[0016] In some embodiments, the system is configured to use an Argon2 hashing process as the first cryptographic process, which provides at least the advantage that cryptographic intermediate products can be generated in a manner that is well known, widely applicable and trusted with a sufficient level of security.

[0017] In some embodiments, the system is configured to use the digital ID to generate a portion of a cryptographic output for the party, and may be configured to generate a certificate for the party by signing at least a portion of the cryptographic output with the system's signing key, which provides at least the advantage that certificates can be generated in a manner that is well known, widely applicable, and trusted with a sufficient level of security.

[0018] In some embodiments, the system is configured to generate, as one of said portions of cryptographic output, a public key of a further key pair of an asymmetric cryptosystem from said digital identity using the Curve25519 elliptic curve Diffie-Hellman algorithm, which provides at least the advantage that a party for whom a digital identity has been established can subsequently use such a key pair for a variety of cryptographic purposes.

[0019] In some embodiments, the system is configured to transmit the cryptographic output in a registration complete response after generation of the digital ID, which provides at least the advantage that a party for whom a digital ID has been established may receive sufficient digital information to subsequently utilize the trust established by the system without having to re-access the system.

[0020] In some embodiments, the system is configured to transmit in the registration complete response an encrypted form of the cryptographic seed and a signed form of a cryptographic key for use by an entity external to the system, the cryptographic key being one half of a key pair of an asymmetric cryptographic system constituting or derived from the digital identity of the party. This provides at least the advantage that a party for whom a digital identity has been established may receive sufficient digital information to subsequently exploit the trust established by the system without having to re-access the system.

[0021] According to a second aspect, there is provided a method of establishing a digital identity of a party. The method includes generating a cryptographic seed as random data and receiving a user secret from an external source via a secure transport mechanism. The method includes applying a first cryptographic operation to generate a cryptographic intermediate product that is deterministically dependent on both the cryptographic seed and the user secret. The cryptographic intermediate product constitutes the digital identity of the party. The method includes applying a second cryptographic operation to the digital identity of the party to generate a cryptographic output that includes the cryptographic seed in encrypted form. The method includes transmitting at least a portion of the cryptographic output to the external source via the secure transport mechanism.

[0022] In some embodiments, the method includes permanently obfuscating the digital ID from memory after it has been used to generate the cryptographic output, which provides the advantage that there is at least no risk of the digital ID being accidentally revealed at a later time, at least not by any action associated with the system executing the method.

[0023] In some embodiments, the method includes generating a cryptographic certificate for the party as part of the cryptographic output through the second cryptographic operation, which provides at least the advantage that the party can later use the cryptographic certificate for authentication without having to re-access the system that executes the method.

[0024] In some embodiments, the method includes establishing a temporary secret for a participant in response to a received pre-provisioning request indicating an identifier and at least one attribute of the participant, and sending a pre-provisioning response including at least a portion of the temporary secret, and may include, as part of establishing the temporary secret, encrypting the identifier and the at least one attribute using the cryptographic seed and storing them in a temporary encrypted archive specific to the participant.

[0025] The method may further include responding to a registration completion request received after the sending of the pre-provisioning response by verifying content of the registration completion further request against the temporary secret.

[0026] The method may include encrypting the identifier and the at least one attribute using the user secret received in the registration completion request and storing them in a final encrypted archive specific to the party, and using the digital ID in the encryption and storing of the identifier and the at least one attribute in the final encrypted archive. This provides the advantage that at least for parties who have not yet provided a user secret required to complete a user registration, certain preparatory actions can be performed and some interim encrypted product can be generated. [Brief description of the drawings]

[0027] [Figure 1] 1 illustrates actions taken by a user device and a trust provider in an exemplary embodiment. [Diagram 2] 4 illustrates certain operations performed in another exemplary embodiment. [Diagram 3] A more detailed example of the operation shown in FIG. 1 will be described. [Figure 4] A more detailed example of the operation shown in FIG. 1 will be described. [Diagram 5] A more detailed example of the operation shown in FIG. 1 will be described. [Figure 6] A more detailed example of the operation shown in FIG. 1 will be described. [Figure 7] A more detailed example of the operation shown in FIG. 1 will be described. [Figure 8] A more detailed example of the operation shown in FIG. 1 will be described. [Figure 9] 1 illustrates actions taken by a user device and a trust provider in an exemplary embodiment. [Figure 10]1 illustrates actions taken and messages exchanged between a user equipment, a service provider, and a trust provider in an exemplary embodiment. [Figure 11] A more detailed example of the operation shown in FIG. 10 will be described. [Figure 12] A more detailed example of the operation shown in FIG. 10 will be described. [Figure 13] A more detailed example of the operation shown in FIG. 10 will be described. [Figure 14] A more detailed example of the operation shown in FIG. 10 will be described. [Figure 15] A more detailed example of the operation shown in FIG. 10 will be described. [Figure 16] A more detailed example of the operation shown in FIG. 10 will be described. [Figure 17] 1 illustrates actions taken and messages exchanged between a user equipment, a service provider, and a trust provider in an exemplary embodiment. Detailed explanation

[0028] In the following description, reference is made to the accompanying drawings, in which is shown by way of example specific forms in which the present disclosure may be embodied. The accompanying drawings constitute a part of this disclosure. It is to be understood that other forms may be utilized and structural or logical changes may be made without departing from the scope of the present disclosure. Therefore, the following detailed description is not to be taken in a limiting sense, as the scope of the present disclosure is defined by the appended claims.

[0029] For example, it should be understood that disclosure related to a described method may also apply to a corresponding apparatus or system configured to perform that method, and vice versa. For example, where certain method steps are described, a corresponding apparatus may comprise units that perform the described method steps, even if such units are not explicitly described or shown in the figures. Conversely, for example, where a particular apparatus is described in terms of functional units, a corresponding method may include steps that perform the described functions, even if such steps are not explicitly described or shown in the figures. Furthermore, it should be understood that features of various example aspects described herein can be combined with each other, unless otherwise noted.

[0030] The concept of digital identity is central to the following discussion. Digital identity is sometimes referred to as cryptoidentity. Conceptually, a digital or cryptographic identity may be characterized as a piece of digital information that is unique enough to reliably identify an entity. For example, if a mathematical algorithm is used to generate cryptographic products such as cryptographic keys, key sets, certificates, digital signatures, etc. using a digital or cryptographic identity as a seed, then the likelihood of obtaining the same cryptographic product without knowledge of that particular digital identity should be so low as to be virtually impossible. An entity capable of presenting such a cryptographic product can be safely assumed to be the entity identified by that digital identity, assuming, of course, that appropriate care has been taken in the generation and processing of the digital identity.

[0031] The authenticity of a digital or cryptographic identity, and therefore the reliability of the cryptographic products generated therefrom, may be significantly improved by a trusted party playing a role in its generation. This trusted party may be comparable to a known trust provider. For this reason, the term trust provider is also used herein. Alternatively, the terms Vault Provider and / or Wallet Provider may be used. Also, the abbreviations CA (Certification Authority) and / or VA (Validation Authority) may be used.

[0032] The nature of digital or cryptographic IDs can be illustrated metaphorically by comparison with the world of traditional paper documents. At the time of writing, a passport must contain digitally encoded information derived from the user's biometric data (such as a facial image and fingerprints). The user's face and fingerprints are what represent the user's identity. On the other hand, a passport is a "cryptographic product". It is impossible to create an identical passport without knowing what the user's face looks like and how the user's finger print is formed. On the other hand, only the appropriate government authorities know how to properly create all the technical details of a passport. Moreover, the authorities agree to the creation of a passport only after they have properly verified that the person who presented the facial image and fingerprint has been properly identified. In this way, the passport authorities play a role comparable to that of a trust provider, both in guaranteeing the identity and in producing the "cryptographic product" from it.

[0033] Fig. 1 shows on the left a system 100 for establishing a digital identity of a party. In this case, the party is a user of a user equipment 110. Said system comprises a random data generator 101. The acronym TRNG for "random data generator" comes from "True Random Number Generator". For purposes that will become clearer in the following description, it is advantageous to use as the random data generator 101 a dedicated device, such as an integrated circuit specially made for this purpose. In the most advantageous case, the random data generated by the random data generator 101 contains the maximum entropy available from the state of the art. An example of the output of the random data generator 101 is shown in Fig. 1 as a secret random number 102. For convenience and simplicity, the secret random number 102 is also called a cryptographic seed. For simplicity in the text, it is sometimes designated with the designator PU0.

[0034] The user device 110 comprises at least one of an input means 111 and a device circuit 112. The device circuit 112 is capable of generating what is shown in FIG. 1 as a user secret 113. If present, the input means 111 may comprise, for example, one or more of a set of keys, a touchpad, a touch-sensitive display, a fingerprint scanner, an iris scanner, a digital camera, a microphone. Using any such input means 111, the user may freely input a unique piece of digital information as the user secret 113 into the user device 110. Such a unique piece of digital information may be, for example, a stored PIN code, biometric information such as a fingerprint, or a piece of digital information read from the user's bio-implant. When used to generate the user secret 113, the device circuit 112 may comprise a random data generator or the like. Generating the user secret 113 in the user equipment may include additional operations, such as computing some cryptographic result (e.g. a hash) on one or more initial digital data. The initial digital data may be received from an input means 111, device circuitry 112, or both. As a non-limiting example, the user secret 113 may be a 256-bit hash calculated from one or more initial digital data with a one-way hash algorithm, such as the Argon2 hash. The user secret 113 may also be referred to as the User's Secret Salt USS.

[0035] In the following description, the cryptographic seed or P U0 It is important to note that the USS 102 and the USS 113 originate from two separate environments that are completely independent of each other. In the embodiment shown in FIG. 1, as shown in block 103, the cryptographic seed or P U0102 are stored for later retrieval by the system 100. Such storage may take the form of creating a user-specific so-called Provisional Encrypted Archive. In this document, the abbreviation KUA (Keystore User Archive) is used. For this reason, at this stage, the cryptographic seed or P U0 102 (and possibly other user-specific data) is stored as a temporary encrypted archive (KUA). U0 ,...). In addition, if all encrypted archives are stored in the system 100 and not in the user device 110, they may be called VUA (Vault User Archive).

[0036] Similarly, the USS 113 is stored for later retrieval at the user device 110, as indicated by block 114. In some embodiments, it is advantageous not to store the USS 113 at all at the user device 110, and to require the user to regenerate the USS 113 each time it is needed. For example, the user may be required to memorize a PIN code or password and enter it as a user secret (USS) each time it is needed. Additionally or alternatively, the user may be required to have the user device 110 read a biometric identification such as a fingerprint, iris scan, bio-implant, etc., each time the USS 113 is needed.

[0037] A secure transport mechanism 120 exists between the user device 110 and the system 100. The exact characteristics of the secure transport mechanism 120 are not important as long as it provides communication security at least equivalent to that obtained with the Transport Layer Security (TLS) protocol at the time of writing. In a preferred embodiment, cryptographic protection of the data content may be used between the parties, such as encryption with a shared key or a private key pair. This also makes the further characteristics of the secure transport mechanism 120 less important. As an example, the secure transport mechanism 120 may be a communication connection over one or more digital networks, secured by the TLS protocol. Alternatively, it may be something entirely different, such as a user being physically present and using a display, cable, or other output means of the user equipment 110 to convey information to a corresponding input means of the system 100.

[0038] In this example, the secure transport mechanism 120 is bidirectional, meaning that both the system 100 and the user equipment 110 have a receiving side and a transmitting side of the secure transport mechanism 120. For convenience in setting up and maintaining communications, the two directions of the secure transport mechanism 120 may utilize the same technology. However, this is not a requirement and the two directions may be via different technologies.

[0039] 1, only the transmission of the user secret 113 is explicitly shown. However, although not required, multiple messages may be exchanged between the system 100 and the user device 110 over the secure transport mechanism 120. As an example, the user device 110 may transmit a public key PK URT to the system 100, which in response derives the corresponding private key SK, for example using the Curve25519 elliptic curve Diffie-Hellman algorithm. UAT Another public key PK generated from UATmay be sent to the user device 110. The subscripts URT and UAT stand for User Request Token and User Access Token, respectively, and are used for brevity but are not intended to be limiting.

[0040] When the URT-related and UAT-related keys have been exchanged as in the previous example, one possible way to securely transmit the user's secret 113 from the user equipment 110 to the system 100 is to use the AES256-GCM encryption method, where the acronym AES stands for Advanced Encryption Standard and the acronym GCM stands for Galois / Counter Mode. Using the notation introduced above, the corresponding transmission over the secure transport mechanism 120 can be expressed as follows: AES256-GCM(SHA2(X25519(SK URT , P.K. UAT ) || PK URT || PKUAT || n), m, n, USS)

[0041] where SHA2() denotes a run of the Secure Hash Algorithm 2 (SHA-2, sometimes called "Shah-2") performed on the argument in parentheses, and X25519() denotes the application of the Curve25519 elliptic curve Diffie-Hellman algorithm to the argument in parentheses. The letter m denotes a MAC or message authentication code for the cryptographic authentication tag, and the letter n denotes a cryptographic nonce. The double vertical bars || mean bitwise OR.

[0042] After receiving a user secret 113 through the secure transport mechanism 120, the system 100 is configured to perform a cryptographic operation 104. The term "operation" may be understood to mean both the act of encryption and the means for performing such encryption. In addition to or instead of encrypting, other cryptographic operations may be used. Generally speaking, the system 100 may be considered to comprise a first cryptographic operation 104 coupled to the random data generator 101 and to the receiving end of the secure transport mechanism 120.

[0043] In the embodiment of FIG. U0 102 constitutes the input to a cryptographic operation 104, and the user's secret 113 received via a secure transport mechanism 120 constitutes the cryptographic key to the cryptographic operation 104. The output of the cryptographic operation 104 is the user's digital ID 105. In other words, the system 100 derives, through said first cryptographic operation 104, said cryptographic seed (P U0 2 illustrates the (first) cryptographic process 204 being a hashing process and a cryptographic seed (P) 113 being generated based on the cryptographic seed 102 and a cryptographic intermediate product 105 that is deterministically dependent on both the cryptographic seed 102 and a user secret (USS) 113 received over the secure transport mechanism (120), which cryptographic intermediate product 105 constitutes the digital identity of the user. U0 ) 102 is the input, and the User Secret (USS) 113 shows an alternative that constitutes the salt.

[0044] Regardless of the exact nature of the first cryptographic operation 104 (encryption, hashing, etc.), its output, i.e., the cryptographic intermediate product 105, is a unique, unpredictable random entity that is not generated by a mathematical operation. This means that while the first cryptographic operation 104 is mathematical, its input (the cryptographic seed or P U0 The mutual independence of the secret key 102 and the user's secret or USS 113 means that the generation operation is not entirely mathematical.

[0045] From an entropy perspective, the randomness of the unique unpredictable random entity is determined by the cryptographic seed or P U0 102. This is true regardless of whether the generation of the cryptographic seed or USS 113 was salted or keyed by an externally obtained user's private key or USS 113. As a result, the randomness of the unique and unpredictable random entity is potentially even quantum-resistant, provided that its two original components (the cryptographic seed or USS 113) are of high quality. U0 , the user's secret or USS 113) is available (e.g., retrievable from the respective storage locations 103 and 114). In the case of USS 113, as explained above, availability of USS 113 may mean that the user needs to enter USS 113 again.

[0046] The number of bits of the unique unpredictable random entity is determined by the cryptographic seed or P U0 The cryptographic operation 104 may be equal to the sum of the number of bits of the user's secret or USS 113 and the number of bits of the user's secret or USS 113. However, it may be advantageous to choose the cryptographic operation 104 to produce a very large result at one time, for example millions of bits, which can then be used for various cryptographic purposes.

[0047] Such further cryptographic purposes are generally represented in the further cryptographic algorithm block 106 of FIG. 1. The further cryptographic algorithm or second cryptographic operation 106 can be, for example, a key generation algorithm. Since the user's digital ID 105 is high quality cryptographic random data, the trust provider may use it, for example, for key generation. For example, it may be used for key generation for either or both asymmetric and symmetric cryptographic systems. Additionally or alternatively, the user's digital ID 105 may be used as a cryptographic seed to generate cryptographic nonce, cryptographic salt, and / or certificate key pairs. All such possible uses are generally covered in the further cryptographic algorithm block 106.

[0048] In general, one may say that the system is configured to use the user's digital ID 105 to generate a cryptographic output 107 through said further cryptographic algorithm or second cryptographic operation 106. For reasons that will be explained in more detail later, the cryptographic seed (P U0 ) 102 may be advantageously included in encrypted form as part of the encryption output 107.

[0049] The user's digital ID 105 is preferably not stored for any longer than necessary for its immediate use for the purposes of a further cryptographic algorithm or second cryptographic operation 106. As shown diagrammatically in the bottom left of FIG. 1, the system 100 is then configured to permanently obfuscate the digital ID 105 from memory. In theory, at least, keeping the digital ID 105 available in some storage would allow the two original secrets (cryptographic seeds or P U0 The risk becomes real if some vulnerability is discovered in the encryption technique or hash function 104 and / or the user secret or USS 113 is exposed.

[0050] 3 to 6 show examples of the first and second cryptographic operations in the system 100 of FIG. 1 and FIG. 2. Reference numeral 102 denotes a cryptographic seed (P in the above) generated by a high-quality random data generator in the trust provider system. U0 ) is used. Reference number 113 is used for a user secret (also referred to above as USS) received from a user via a secure transport mechanism. A common feature of all the embodiments of figures 3 to 6 is that the system is arranged to generate, through a first cryptographic operation, a cryptographic intermediate product that is deterministically dependent on both the cryptographic seed and the (user) secret. The cryptographic intermediate product constitutes a digital identity of the user. Also common to these embodiments is that the system is arranged to generate, through a second cryptographic operation, a cryptographic output that includes an encrypted form of the cryptographic seed using the digital identity of the user.

[0051] In the embodiment of FIG. 3, the first cryptographic operation 304 has three inputs: a cryptographic seed 102, a user secret 113, and one or more attributes 301. Preferably, but not exclusively, the attributes 301 are user-specific attributes associated with the particular user for which the digital ID is to be generated. Additionally or alternatively, at least one of the attributes is associated with a trust provider that validated the user's certificate. For example, an identifier of the trust provider may be used as an attribute. The first cryptographic operation 304 may, for example, include one or more cryptographic and / or hashing operations from which the user's digital ID 105 may be derived as a cryptographic intermediate product. This input and possibly further inputs 302 may be inputs to a second cryptographic operation 306. FIG. 3 does not make any notion of what the cryptographic output from the second cryptographic operation 306 should look like or be specified. Examples of these are described in more detail below.

[0052] The embodiment of Figure 4 differs from the embodiment of Figure 3 in that no attributes are used as input to the first cryptographic operation 404. Thus, the cryptographic intermediate product (the user's digital ID 105) depends only on the cryptographic seed 102 and the user's secret 113. Block 402 shows attributes and possible further inputs as one of the inputs to the second cryptographic operation 406, similar to the embodiment of Figure 3.

[0053] The embodiment of Figure 5 differs from the embodiments of Figures 3 and 4 in that it includes so-called pre-provisioning, which is shown in Figure 5 as the first half 501 of the first cryptographic operation. The system may perform this, for example, before receiving the user's secret 113 via the secure transport mechanism. The input for pre-provisioning includes the cryptographic seed 102 and one or more attributes 301 associated with the user. The result of pre-provisioning 505 may include, for example, a so-called temporary encrypted archive specific to the user for which pre-provisioning is performed.

[0054] The second half of the first cryptographic operation is shown in FIG. 5 at 502. One of the inputs is the user's secret 113. The pre-provisioning result 505, or at least a portion of it, is used as an input to the second half of the first cryptographic operation 502. Additionally or alternatively, the cryptographic seed 102 may be an input to the second half of the first cryptographic operation 502. The output is the user's digital ID 105. As with the other embodiments, the user's digital ID 105 is a cryptographic intermediate product that can be used in any type of second cryptographic operation described herein, possibly with attributes and / or further inputs as in FIGS. 3 and 4.

[0055] Figure 6 is similar to Figure 5 in that pre-provisioning takes place. Pre-provisioning is shown as the first half 601 of a first cryptographic operation. As in Figure 5, the inputs for pre-provisioning are a cryptographic seed 102 and one or more attributes 301. Pre-provisioning may be performed before the user's private key is received. The result 603 of pre-provisioning may include a temporary encrypted archive specific to the user.

[0056] One application where the principle of pre-provisioning can be advantageously applied is the creation, through pre-provisioning, of digital signature certificates for parties that do not yet "exist" (by having personally contacted the trust provider), but for which certain attributes are already known. Such digital signature certificates may remain unchanged for future use. For example, a public authority may create such digital signature certificates for persons to whom it has not yet granted a USS. The trust provider (the authority in this example) can regenerate the public signing key for such users based on the attributes. Any USS subsequently obtained from the user does not affect the digital signature certificate.

[0057] The second half of the first cryptographic operation 602 takes as input the cryptographic seed 102 and the user's secret 113 and produces the user's digital ID 105 as a cryptographic intermediate product. The user's digital ID 105 and the pre-provisioning result 603 form inputs to a second cryptographic operation 606. There may also be other inputs to the second cryptographic operation 606 that are not shown in Figure 6. The cryptographic output, shown in Figure 6 as the cryptographic product 107, includes at least the encrypted cryptographic seed.

[0058] FIG. 7 shows an example where the further cryptographic algorithm or second cryptographic operation is a certificate generation algorithm 706. (The further cryptographic algorithm or second cryptographic operation was shown as 106 in FIG. 1 , and similarly referenced 306, 406, 606.) In addition to the user's digital ID 105, other inputs may be used, such as attributes that the certificate should contain, and / or further keys necessary to properly generate the desired certificate product 707. As previously mentioned, there may be zero, one or more attributes, and the attributes may be associated with the user, the trust provider, or both. In general, the system may be configured to generate a cryptographic certificate for the user as part of its cryptographic output through the further cryptographic algorithm or second cryptographic operation.

[0059] The example shown in Fig. 8 explains the concept of Fig. 7 in a little more detail. Particular types of parts of the certificate generation algorithm 806 include a private key generator 821, a public key generator 822, and a certificate generator 823. The system is configured to use the user's digital ID 105 as input to the private key generator 821 to generate the user's private key 831. The system is further configured to use the generated private key as input to the public key generator 822 to generate the user's public key 832. The certificate generator 823 essentially signs the generated public key using the trust provider's private signing key 841. In conjunction with the signing operation, attributes 842 may be selected. The system may have received attributes, preferably in encrypted form, for example from a service provider that the user plans to use after receiving the required certificate 833. One or more attributes related to the trust provider may be used. Comparing it to the conceptual level of FIG. 7, the user's private key 831 , public key 832 , and certificate 833 form a certificate product 807 that is the useful output of the certificate generation algorithm 806 .

[0060] Figure 8 is thus an example of an embodiment in which a system is configured to generate a cryptographic output for a party using a digital ID 105. Additionally, in the embodiment of Figure 8, the system is configured to generate a certificate for said party by signing at least a portion of the cryptographic output with a system signing key 841. In this embodiment, the system is configured to generate, as part of the cryptographic output, a public key 832 of a pair of keys 831 and 832 of an asymmetric cryptographic system from said digital ID 105. An example of generating such a public key 832 would be to first generate a private key 831 called SKUID.

[0061] SK UID = Argon2Id(P U0 , USS)

[0062] Here, Argon2Id() means that the Argon2 hash algorithm is used. And the corresponding public key PK UID Proceed to generate.

[0063] Penalty kick UID = X25519(SK UID ) = X25519(Argon2Id(P U0 , USS)).

[0064] The Argon2 algorithm is computationally very intensive, so simpler generation methods such as the SHA2 algorithm may be used.

[0065] Penalty kick UID = X25519(SKUID) = X25519(SHA2(P U0 || USS)).

[0066] Public key PK UID The result of signing with the signing key of system 100 is SIGN UID One of the possible cryptographic products that can be generated is a final encrypted archive that is unique to the user. Information elements contained in such a final encrypted archive may be, for example, a cryptographic seed P U0 , public key PKUID , CERTIFICATE SIGN UID As encryption key, for example, the user's private USS can be used. In such a case, the final encrypted archive is specified as follows:

[0067] Enc(USS, KUA(P U0 , P.K. UID , SIGN UID ,…)).

[0068] 1-8 do not give any idea as to how the system subsequently uses the outputs, i.e. the cryptographic product 107 and / or the certificate products 707 or 807. The keys 831 and 832 are primarily for use by the user equipment 110. Thus, for example, a natural possibility is that the system 100 is configured to send a response carrying at least the keys 831 and 832 to the user equipment 110, for example via a secure transport mechanism 120 the same as or similar to that of FIG. 1, thereby making the user equipment 110 in possession of the keys 831 and 832. Also, if the certificate 833 has been generated, as in the case of FIG. 8, it is also transmitted. In general, the system 100 is configured to transmit at least a part of the cryptographic output 107 through said secure transport mechanism 120.

[0069] Using the notation introduced above, one possible way to encrypt at least a portion of the cipher output 107 is to first obtain an encryption key K KUA The solution is to generate it as follows:

[0070] K KUA = SHA2(X25519(SK UAT , P.K. URT ) || PKUAT || PKURT || n)

[0071] And then use it to encode the final encrypted archive as follows:

[0072] Enc(K KUA , KUA(PU0 , …)).

[0073] 9 illustrates one method that may be utilized by the user equipment 110 after at least a portion of the encrypted output 107 is received via a secure transport mechanism 120. The portion of the encrypted output 107 received by the user equipment may be stored in an encrypted form as a cryptographic seed (P U0 ) 102, the encryption seed (P U0 9, the decoder 901 may be configured to extract the cryptographic seed, as shown in the section relating to the user secret (USS) 102. The user equipment can retrieve the user secret (USS) 113 from the secure storage or request the user to enter it again, after which the user equipment 110 can recreate the user's digital ID 905 by applying a (first) cryptographic operation 904 similar to that performed by the system 100 in step 104 of FIG. 1 (or step 204 of FIG. 2 or the corresponding steps of FIGS. 3-6). The ability of the user equipment 110 to recreate the user's digital ID 905 means that after receiving a response from the system 100 as in FIG. 9, the user equipment 110 is independent of the system 100 with respect to all subsequent uses of cryptographic products that are or can be derived from the user's digital ID 905. Returning briefly to the passport example above, the user now receives a "passport" issued by the trust provider. The cryptographic seed (P U0 ) 102, and the appropriate cryptographic measures taken when delivering it to the user equipment 110, ensure that the cryptographic product 907 derived by the user equipment 110 applying further cryptographic operations 906 can be digitally verified with a sufficiently high level of trust by third parties with which the user wishes to communicate using the user equipment 110.

[0074] As shown in Fig. 9, the decoder 901 of the user equipment 110 can also extract other useful parts of the received cryptographic product 107. Such extracted parts can be used as input for a cryptographic operation 906. The user's digital ID 905 would advantageously not be stored in the user equipment 110, at least not for a long period of time. The user may have to enter the user's secret 113 again, but the user equipment 110 can in any case regenerate the user's digital ID 905 at any time. Correspondingly, Fig. 9 shows the user device obfuscating the user's digital ID 905 from memory immediately after performing any of the possible further cryptographic operations 907.

[0075] FIG. 10 shows an example of how the principles described above may be applied in the actions taken and messages exchanged between a user, a service provider, and a trust provider in an exemplary embodiment. Although actors are named as Parties in FIG. 10, the operations described herein are of course operations performed by devices and / or equipment owned by and / or operated on behalf of such Parties. Thus, for example, the operations described herein with reference to the leftmost column of FIG. 10 are operations of a system as described above in FIGS. 1-4. The expression "service provider" must be understood in a broad sense, and in addition to private companies, authorities, etc. may also be considered as service providers. Alternatively, a Party considered as a service provider may also be considered as a Registration Authority (RA). FIGS. 11-16 show more detailed examples of how certain operations in FIG. 10 may be advantageously performed.

[0076] A feature of Figure 10 is that it shows a two-step process on the part of the trust provider. These two steps may be called the pre-provisioning step and the registration completion step, similar to the explanation of Figures 5 and 6 above. In the first step, the service provider (i.e., the party shown in the center of Figure 10) basically makes the actual request to generate a digital ID for the user. The service provider does this for a user who is already known to the service provider at that stage and with whom the service provider has already established a trust relationship. It is not important here what the corresponding previous operations were, but we may assume that the establishment of the trust relationship was completed by a customer service, a registration authority, or in the eIDAS authorization model. The acronym eIDAS refers to the regulation on electronic identification, authentication and trust services enacted by the European Union in 2014.

[0077] Thus, the service provider will identify the user in some way and will want the trust provider to create a protected archive with certain attributes tied to the user's unique identifier. This unique identifier does not need to be secret, as long as it can be associated with the correct user with reasonable confidence. For example, the user's MSIN (Mobile Subscriber Identification Number), or the more familiar mobile phone number, may serve as the unique identifier. In this document, the unique identifier is abbreviated by the acronym UID.

[0078] In Fig. 10, in step 1001, a user creates a message and sends it to a service provider as a registration request 1002. The registration request 1002 can be sent, for example, as an SMS (a text message according to the Short Message Service standard). An SMS has the advantage that the user's UID (mobile phone number) is automatically attached, making it easily recognizable by the service provider.

[0079] In some embodiments, the registration request 1002 may include the user's public key as a payload. The term payload refers to the contents of the message, which may include metadata and / or header information defined by one or more communication protocols. As shown in substep 1101 of FIG. 11, the user device retrieves the public key PK from storage, such as a protected key store. URT Alternatively, the user equipment may retrieve the public key PK URT may be generated on the fly. The initials URT in the subscript stand for User Request Token. For example, the public key PK URT may be a 256-bit output from a random number generator in the user equipment, denoted RNG(256). Sub-step 1102 of Figure 11 represents the user equipment creating and sending a registration request 1002 shown in Figure 10.

[0080] In step 1003, the service provider associates the UID with the desired attributes and prepares what amounts to a request to generate a digital ID for the user. In Fig. 10, the request is shown as an AddUser request 1004. To convey the AddUser request 1004 to the trust provider, a secure transport mechanism must be used. As an example, the AddUser request 1004 may be conveyed through a communication connection over one or more digital networks secured by the TLS protocol. The AddUser request 1004 may also be referred to as a pre-provisioning request since it triggers a pre-provisioning step at the trust provider side.

[0081] The AddUser request may include, or at least can be indicated with a high degree of confidence, an identifier (UID) for the user and at least one attribute of the user. UMD, an abbreviation for User Meta Data, can generally be used to represent one or all attributes associated with a user and stored in a protected archive that the service provider requests the trust provider to create. In short, the AddUser request 1004 includes the PK URT , UID, and UMD. An example of actions taken by the service provider in step 1003 is shown in Figure 12. Sub-step 1201 corresponds to receiving a registration request 1002 from a user and noting the UID. Sub-step 1202 corresponds to reading and storing the contents of the registration request 1002. Sub-step 1203 corresponds to associating desired attributes with the UID. Sub-step 1204 corresponds to preparing and sending an AddUser request 1004 to the trust provider.

[0082] In the above explanation, the public key PK URT is assumed to originate from the user, not from the service provider. URT We assume that the public key PK is owned exclusively by the user and stored in a secure key store on the user's device. URT If the data is encrypted with the private key SK, only the user can URT According to an alternative embodiment, the service provider may decrypt the information using the public key PK without first receiving a registration request 1002 from the user, or at least without first receiving a registration request 1002 from the user. URTThe service provider may create and send the AddUser request 1004 without receiving the public key from the service provider. In such a case, the service provider includes the corresponding public key in the payload of the AddUser request and stores the corresponding private key in the service provider's secure key store. This means that if any information is encrypted with the service provider's public key, only the service provider can later decrypt it using the private key. This consideration has some important implications in the next step described below.

[0083] Step 1005 of Fig. 10 is a pre-provisioning step performed by a trust provider. In general terms, a pre-provisioning function in the trust provider's system is configured to respond to a received pre-provisioning request (AddUser Request 1004) indicating an identifier (UID) and at least one attribute (UMD) of a participant by establishing a temporary secret for the participant and sending a pre-provisioning response (AddUser Response 1006 of Fig. 10) containing at least a part of said temporary secret. Furthermore, said pre-provisioning function is configured to encrypt said identifier (UID) and said at least one attribute (UMD) using a cryptographic seed (corresponding to 102 of Fig. 1) provided by a random data generator (corresponding to 101 of Fig. 1) and store them in a temporary encrypted archive specific to said participant.

[0084] A noteworthy detail is that in the embodiment of Figure 10, in step 1005 the trust provider does not yet possess the equivalent of the user's secret 113 described above with reference to Figure 1. Thus, at this step the trust provider is not yet able to generate a suitable digital ID for the user, since it must subject both the random data provided by the internal random data generator and an additional secret obtained from the user to cryptographic operations, hence the name "pre-provisioning".

[0085] Figure 13 shows examples of possible sub-steps included in step 1005 of Figure 10. In sub-step 1301, the system receives an AddUser request 1004 and retrieves its contents, i.e., the PK URT , UID, and UMD. Substep 1302 represents establishing an ephemeral secret for the user. In this example, the ephemeral secret comprises a pair of keys for an asymmetric cryptosystem. These keys are intended to be used only once in subsequent communications between the user and the trust provider, and are therefore referred to herein as an ephemeral key pair for the asymmetric cryptosystem. These keys are referred to herein as an ephemeral key pair for the PK UAT , S.K. UAT The subscript UAT stands for User Access Token. Advantageously, a cryptographic seed derived from a random data generator is used to establish the user's pseudo-secret.

[0086] As a specific and non-limiting example, the pre-provisioning function may convert a 256-bit random number provided by the random data generator into a secret key SK of the pair of ephemeral keys. UAT , and derive the private key SK of the pair of ephemeral keys using the Curve25519 Elliptic Curve Diffie-Hellman method. UAT to the public key PK of the pair of ephemeral keys UAT The method is configured to generate

[0087] Sub-step 1303 represents the creation of a temporary encrypted archive specific to the user. For the encryption, it is advantageous to use a so-called Shared Secret, which is (or will be) shared between the trust provider and the user. The aforementioned public key PK URT In another case where the authentication request originates from the service provider rather than from the user, the shared secret used in this stage may also be shared between the trust provider and the service provider.

[0088] Here, the shared secret used to create the interim encrypted archive in sub-step 1303 is SS UST The acronym UST stands for User Session Token. UST One convenient way to create the ephemeral secret key SK received in the AddUser request is to use UAT and the public key PK URT The trick is to perform a scalar multiplication of . In other words:

[0089] SS UST = scalarmult(SK UAT , P.K. URT ).

[0090] The "scalarmult" notation above essentially means scalar multiplication, but can also be expressed using the X25519 or Curve25519 methods. The advantage gained is a mathematical link between the key pair: both parties can use their own private key and the other's public key to derive the same shared secret.

[0091] Using a similar notation, and using the acronym KUA (Keystore User Archive) for the stored payload, the interim encrypted archive is specified as follows:

[0092] Enc(SSUST, KUA~(UID, UMD, P U0 ,…))

[0093] Secret ephemeral key SK UAT Since the origin of is a cryptographic seed obtained from a random data generator, this exemplary process follows the characteristics presented above: the pre-provisioning function is configured to use the cryptographic seed in creating the temporary encrypted archive. According to a more formal characterization, the pre-provisioning function uses a secret ephemeral key SK received from an entity external to the system.UAT and the public key PK URT First, we calculate the shared secret SS by mathematical operations using UST and generating said identifier UID and in said encryption and storing in said temporary encrypted archive of said at least one attribute UMD, said first shared secret SS UST The IEEE 802.11 standard may be configured to use

[0094] Sub-step 1304 of Figure 13 represents the transmission of the pre-provisioning response 1006 described above, which includes at least a portion of the pseudo-secret created in sub-step 1302. In particular, the pre-provisioning response includes the public key PK UAT can be transmitted.

[0095] In the embodiment of FIG. 10, the service provider has only a minor role in forwarding the AddUser response 1006 to the user in the form of a registration response 1007. As in the case of messages 1002 and 1004, it can be assumed that a TLS-secured channel or the like exists between the trust provider and the service provider, and that text messages or the like can be used between the service provider and the user. In such a case, the role of the service provider is to extract the payload (i.e. the ephemeral public key PK) from the AddUser response 1006. UAT ) and forward it to the user via SMS. URT However, in an alternative embodiment where the forwarding message 1007 originates from a service provider rather than a user, the forwarding message 1007 is not needed at all, and the payload of the AddUser response 1006 (i.e., the ephemeral public key PK UAT ) may remain with the service provider.

[0096] It should be noted that all steps and sub-steps described so far in FIG. 10 can be repeated multiple times if necessary. As an example, the key PK transmitted in the AddUser request in step 1004 isURT However, alternative embodiments can be envisaged in which the unique identifier for the user originates from the service provider rather than the user. Such an embodiment could mean, for example, that the service provider already knows the user's unique identifier and is prepared for possible future needs for secure communication with the user, but has not yet received a suitable registration request from the user.

[0097] At some point, the service provider may have an initial attribute (or an initial set of attributes) to associate with a user's unique identifier. This allows the service provider to obtain the user's unique identifier, the initial (set of) attributes, and a key PK generated for this purpose. URT 1. In response, the trust provider may be prompted to generate and send an initial AddUser request, conveying the first shared secret, SS UST Create a first version of a user-specific interim encrypted archive encrypted with 1 and the corresponding first ephemeral public key PK UAT Send 1 back.

[0098] The service provider can then learn something more about the user, generate the corresponding second attribute(s), and send a second AddUser request, which includes the user's unique identifier, the second attribute(s), and a key PK generated for this purpose. URT 2(Key PK URT 1). In response, the trust provider decodes the first version according to the following formula:

[0099] Dec(SSUST1, KUA~(…))

[0100] Then, it creates a second version of the temporary encrypted archive that is unique to the user. This second version uses the updated shared secret key SS UST 2, and the calculation requires the key PK URT2 is used. The trust provider then sends the corresponding second ephemeral public key, PK UAT Send back 2.

[0101] Such rounds of communication can be repeated as many times as necessary. The same applies to such embodiments in which the user had a role in initiating at least some of such rounds, for example by sending a registration request 1002. Even in such embodiments, each AddUser response (or at least its payload) from the trust provider is of course returned to the user, as described above with respect to steps 1006 and 1007 of Figure 10.

[0102] Step 1008 of Figure 10 represents the user preparing and sending a complete registration request, shown in Figure 10 as GetUser request 1009. The purpose of such a complete registration request is to securely convey the user's secret, shown in principle in Figure 1 as 113, to the trust provider, so that the second step in the process shown in Figure 10 can be to generate and properly use a digital ID for the user to complete the user's registration.

[0103] In the embodiment shown in Figure 10, the GetUser request 1009 does not actually involve a service provider at all, but is purely between the user and the trust provider. There is nothing against using a service provider as an intermediary in forwarding the message, but there is also no reason to do so, so in Figure 10 the GetUser request 1009 is shown as being sent directly from the user to the trust provider, assuming a secure communications channel such as a TLS-secured network connection.

[0104] Figure 14 shows example sub-steps that the user equipment may perform in step 1008 of Figure 10. Sub-step 1401 receives the registration response 1007 and transmits its contents, in particular the ephemeral public key PK UATIn sub-step 1402, one or more user-specific secrets are generated. Such a first user-specific secret may for example be a USS (User Secret Salt). The USS may consist of 256 bits of a credential hash. The credential on which such a hash is computed may for example be a PIN code entered by the user into the user equipment.

[0105] Another user-specific secret is the key SK URT , i.e., the public key PK URT is the private key of the key pair previously sent to the trust provider. In this case, the key SK URT has already been generated but is not necessarily used in previous steps of the process. URT and P.K. URT One convenient way to generate a private key SK is URT A 256-bit random number RNG(256) is used as the public key PK URT function ScalarBaseMult(SK URT ) for the calculation. The notations X25519() and Curve25519() can also be used.

[0106] Yet another user-specific secret may simply be a nonce designated by the letter n, where nonce n is, for example, a 96-bit random number derived from a random number generator within the user equipment.

[0107] With the above-mentioned user-specific secret available, the user equipment can derive an encryption key K, for example according to the following formula: USS may be generated.

[0108] K USS = SHA2(X25519(SK URT , P.K. UAT ) || PK URT || PK UAT || n).

[0109] encryption key K USSThe use of a hash algorithm in the process of generating the key is optional, but may provide additional security against brute force attacks by malicious actors attempting to discover the private key. At the time of writing, it is assumed that using optimized quantum computing approaches and Shor's algorithm, it is possible to effectively halve the number of bits in the cryptographic key, meaning that, for example, a 256-bit key would appear to be only 128 bits, and a brute force attack may already be successful.

[0110] The user device generates the key K USS Using the notation introduced above, the payload of the GetUser request 1009 is represented as follows:

[0111] AES256-GCM(SHA2(X25519(SK URT , P.K. UAT ) || PK URT || PK UAT || n),m,n,USS).

[0112] Substeps 1403 and 1404 of FIG. 14 represent the user equipment preparing and sending a GetUser request 1009 .

[0113] Step 1010 of Figure 10 generally represents the actions performed by a conceptually defined registration completion function contained in a trust provider's system. The essential purpose of registration completion step 1010 is to ensure the application of the principle previously described with reference to Figure 1. In other words, registration completion step 1010 ensures that the generated digital identity of a user is based on a cryptographic seed and a user secret coming from two separate environments that are completely independent of each other.

[0114] Key Pair (SK URT , P.K. URT ) and (SKUAT , P.K. UAT ), the mathematical relationship between the key K USS can be regenerated as follows:

[0115] K USS = SHA2(X25519(SK UAT , P.K. URT ) || PK URT || PK UAT || n)

[0116] This is essentially the temporary private key (PK) established in step 1005. UAT , S.K. UAT ) for GetUser request 1009's content (K USS ) The system verifies the regenerated key K USS Using this, the user private key USS can be decrypted as follows:

[0117] Dec(K USS , USS)

[0118] These operations are included in sub-step 1501 of Figure 15. After associating the GetUser request 1009 with the appropriate, previously created, temporary encrypted archive KUA, the system can decrypt it as follows.

[0119] Dec(SS UST , KUA~(UID, UMD, ...).

[0120] The system may also perform the decryption operation using the user secret salt USS.

[0121] Dec(USS, KUA(P U0 , ...))

[0122] Next, the system applies the principle shown in Figure 8 to first obtain the user's private key SK UID is generated as follows:

[0123] SK UID = Argon2Id(P U0 , USS)

[0124] And the corresponding public key PK UID Generate.

[0125] Penalty kick UID = X25519(SK UID ) = X25519(Argon2Id(P U0 , USS)).

[0126] As mentioned above, an algorithm with less computational complexity, such as the SHA2 algorithm, may be used instead of the Argon2 algorithm. UID is called the permanent user public key in sub-step 1502 of FIG. 15. The generated key SK UID , P.K. UID are ECC / PCI compliant private key and ECC / PCI compliant public key, respectively.

[0127] Generated key SK UID and P.K. UID constitute the (user's) digital ID in this embodiment. From the trust provider's point of view, these are the cryptographic seed P U0 and the user secret USS.

[0128] Generated user-specific public key PK UID is sometimes called the user's confirmed secret. The system also UID the trust provider's signing key SK VID By signing with the user's certificate, SIGN UID The trust provider may be configured to generate a signing key SK VIDis preferably an ECC / PKI compliant private key, and the signing may be done according to Ed25519 / EdDSA practices. Signing is shown as sub-step 1503 in Figure 15. According to known principles of digital signatures and signature checking, anyone can check such a digital signature of the trust provider using the trust provider's corresponding public key.

[0129] The system may then proceed to encrypt the user identifier UID and all appropriate and available attributes UMD using the further secret USS received in the GetUser request 1009 and store them in a final encrypted archive specific to the user. The encryption can be expressed as follows:

[0130] Enc(USS, KUA(UID, UMD, SIGN UID , P.K. UID , P U0 , ...))

[0131] This is represented by substep 1504 in FIG.

[0132] Sub-step 1505 of Figure 15 represents the system sending a registration completion response, which is the GetUser response 1011 of Figure 10. The GetUser response 1011 may convey to the user a useful end product of the registration completion step, namely the updated contents of the Keystore User Archive (KUA). The encryption key for encrypting the contents of the GetUser response 1011 is generated as follows:

[0133] K KUA = SHA2(X25519(SK UAT , P.K. URT ) || PK UAT || PK URT || n)

[0134] And the encrypted payload of the GetUser response 1011 is created as follows:

[0135] KUA(response) = Enc(K KUA , KUA(P U0 , ...)).

[0136] Again with AES256-GCM being the preferred encryption method, the encrypted payload of the GetUser response 1011 can be expressed as:

[0137] AES256-GCM(SHA2(X25519(SK UAT , P.K. URT ) || PKUAT || PKURT || n), m, n, KUA(response)).

[0138] Either or both of the cryptographic operations of sub-steps 1504 or 1505 generate a cryptographic seed P in a form encrypted by a second cryptographic operation. U0 This can be considered as an example of a trust provider's system generating a cryptographic output including: (a) a digital identity that is encrypted using a secure transport mechanism 120 (see FIG. 9) that ultimately allows the user to safely recreate the established digital identity for use in various communications and transactions. An example of subsequent operations of the user device in step 1012 is described below.

[0139] Sub-step 1601 represents the user equipment receiving and at least partially decoding the GetUser response 1011. In particular, the user equipment receives the key K KUA is regenerated as follows:

[0140] K KUA = SHA2(X25519(SK URT , P.K. UAT ) || PKUAT || PKURT || n)

[0141] It is then used for decoding.

[0142] Dec(K KUA , KUA(P U0 ,...)).

[0143] In substep 1602, the user device uses the decoded information to derive a permanent key SK that constitutes the user's digital identity, for example in the same way as the trust provider's system did earlier. UID and P.K. UID You can create your own instance of

[0144] SK UID = X25519(Argon2Id(P U0 , USS)) or SK UID = X25519(SHA2(PU0 || USS)) and pk UID = x25519(sk UID )

[0145] The payload of GetUser response 1011 contains the key PK UID Signed form SIGN UID If the SIGN UID with the corresponding public key of the trust provider, and the result is PK UID by checking that it matches the regenerated instance of UID This is shown in FIG. 16 at substep 1603. Substep 1604 is to verify the regenerated instance of the signed form SIGN UID This indicates that the user certificate is to be stored as the user's user certificate.

[0146] Figure 17 is another example showing how the principles discussed above are applied in the actions taken and messages exchanged between a user, a service provider, and a trust provider in an exemplary embodiment. The difference between the embodiments of Figures 10 and 17 relates to the roles of the user and the service provider in the pre-provisioning phase. In step 1701, the user equipment creates a user equipment version of a request message, called RegUser request in Figure 17. The RegUser request 1702 requests, for example, the user's public key PK URT , a user identifier UID, user-characteristic attributes, and / or other metadata UMD may be communicated to the trust provider, which may then use these to populate and store an initial version of a user-specific interim encrypted archive in step 1703. The interim encrypted archive stored in step 1703 may include any or all of the information conveyed in the RegUser request, as well as a high-entropy, user-specific cryptographic seed P generated by the trust provider's system. U0 may include:

[0147] Steps 1704 and 1705 in Figure 17 represent the user creating and sending something to the service provider that triggers an AddUser request from the service provider to the trust provider. This "something" may be, for example, a registration request and / or a link to appropriate user specific information in the trust provider's system. With respect to positive identification of the user by the service provider, steps 1704 and 1705 in Figure 17 are entirely equivalent to steps 1001 and 1002 in Figure 10 above.

[0148] In step 1706, the service provider may augment the information received from the user with one or more attributes, similar to step 1003 above in Figure 10. The result of step 1706 is an AddUser request 1707 that the service provider sends over a secure channel to the trust provider. As in Figure 10 above, the registration request 1705 requests the public key PK URTAssuming that this catches the service provider's attention, AddUser will then URT A user identifier such as a UID may be included in the AddUser request 1707, but is not required, because the trust provider may have already received the key PK URT , can be used to identify the user just as easily and reliably.

[0149] Step 1708 of Figure 17 represents a second round of pre-provisioning in the trust provider's system. This second round is essentially similar to the iteration of pre-provisioning steps described above with respect to Figure 10. Additional information originating from the service provider in step 1706 is added to the user-specific interim encoding archive in the trust provider's system. Additionally or alternatively, such additional information may have originated from the user in step 1704. However, the trust provider does not yet possess the user's secret 113 of Figure 1, and therefore cannot yet complete the user's registration.

[0150] In the embodiment of Figure 17, the trust provider sends the RegUser response 1709 directly to the user without going through the service provider, although in some embodiments it may go through the service provider, as in steps 1006 and 1007 of Figure 10. The RegUser response 1709 includes the ephemeral public key PK UAT to the user, which the user device uses in step 1710 to create a GetUser request 1711. Again, these two steps are similar to the corresponding steps 1008 and 1009 of Figure 10. Through the GetUser request 1711, the trust provider obtains the user's secret needed to generate the user's digital ID, completing the user's registration in step 1712. The GetUser response 1713 and its use by the user device in step 1714 are similar to the corresponding steps 1011 and 1012 of Figure 10.

[0151] The ranges or values ​​set forth herein may be expanded or modified without losing the desired effect, and any embodiment may be combined with other embodiments unless expressly prohibited.

[0152] Although the subject matter of the present application has been described in language specific to structural features and / or operations, it should be understood that the subject matter defined in the appended claims is not necessarily limited to the specific features or operations described above. Rather, the specific features and operations described above are disclosed as example forms of implementing the claims, and other equivalent features and operations are intended to be encompassed within the scope of the claims.

[0153] It should be understood that the above-mentioned advantages and benefits may relate to one or more embodiments. The embodiments are not limited to those that solve any or all of the problems described or those that have any or all of the advantages and benefits described. Also, the number of components may be one or more, even if not specifically mentioned.

[0154] The steps of the methods described herein may be performed in any suitable order, or simultaneously where appropriate. Additionally, individual blocks may be deleted from any of the methods without departing from the spirit and scope of the subject matter described herein. Aspects of any of the embodiments described above may be combined with aspects of any of the other embodiments described above to form further embodiments without losing the desired effect.

[0155] The term "consisting of" is used herein to mean including specified methods, blocks, or elements, but such blocks or elements do not constitute an exclusive list and the method or apparatus may include additional blocks or elements.

[0156] It will be understood that the above description is given by way of example only, and that various modifications may be made by those skilled in the art. The above specification, examples, and data provide a complete description of the structure and use of the exemplary embodiments. Although various embodiments have been described above with a degree of particularity, or with reference to one or more individual embodiments, those skilled in the art may make numerous modifications to the disclosed embodiments without departing from the spirit or scope of the present specification.

Claims

1. 1. A system for establishing digital identities for participants, comprising: a random data generator configured to generate a cryptographic seed; - a receiving side and a sending side of a secure transport mechanism for communicating with an external source; a first cryptographic operation coupled to the random data generator and to the receiving side of the secure transport mechanism; a second cryptographic operation coupled to the first cryptographic operation and the sender side of the secure transport mechanism; Equipped with configured to generate, through the first cryptographic operation, a cryptographic intermediate product that deterministically depends on both the cryptographic seed and a user secret received from an external source via the secure transport mechanism, the cryptographic intermediate product constituting the digital identity of the party; configured to generate, through the second cryptographic operation, a cryptographic output using the digital identity of the party, the cryptographic output including the cryptographic seed in encrypted form; configured to transmit at least a portion of the cryptographic output over the secure transport mechanism; configured to permanently obfuscate the digital ID in memory after using the digital ID in the generation of the cryptographic output. system.

2. The system of claim 1 , configured to generate, through the second cryptographic operation, a cryptographic certificate for the party as part of the cryptographic output.

3. a pre-provisioning function configured, in response to a received pre-provisioning request indicating an identifier and at least one attribute of the participant, to establish a temporary secret for the participant and to send a pre-provisioning response including at least a portion of the temporary secret; a registration completion function configured to respond to a registration completion request received after said sending of said pre-provisioning response by verifying the contents of said registration completion request against said temporary secret; Equipped with the pre-provisioning function is configured to encrypt and store the identifier and the at least one attribute in a temporary encrypted archive specific to the participant using the cryptographic seed; the registration completion function is configured to encrypt the identifier and the at least one attribute using the user secret received in the registration completion request and store them in a final encrypted archive unique to the participant; the system is configured to use the digital ID in the encryption and storage of the identifier and the at least one attribute in the final encrypted archive. The system of claim 1 .

4. The pre-provisioning function includes: generating a pair of ephemeral keys of an asymmetric cryptographic system as said pseudo-secrets for said party; configured to send the public key of the pair of ephemeral keys in the pre-provisioning response; The system of claim 3.

5. The pre-provisioning function includes: using the random number provided by the random data generator as a private key of the pair of ephemeral keys; configured to generate the public key of the pair of ephemeral keys from the private key of the pair of ephemeral keys using the Curve25519 elliptic curve Diffie-Hellman algorithm; The system of claim 4.

6. The pre-provisioning function includes: generating a first shared secret using a first mathematical operation using the private key of the pair of ephemeral keys and a public key received from an entity external to the system; configured to use the first shared secret when encrypting and storing the identifier and the at least one attribute in the temporary encrypted archive; The system of claim 5.

7. The system of claim 1 , configured to use Argon 2 hashing as the first cryptographic operation.

8. configured to generate a portion of the cryptographic output for the party using the digital ID; configured to generate a certificate for the party by signing at least a portion of the cryptographic output with a signing key of the system; A system according to any one of claims 1 to 6.

9. 9. The system of claim 8, configured to generate, as one of the portions of the cryptographic output, a public key of a further key pair of an asymmetric cryptographic system from the digital ID using Curve25519 elliptic curve Diffie-Hellman.

10. The system of claim 1 , configured to transmit the encrypted output in a registration complete response after generating the digital ID.

11. 11. The system of claim 10, configured to send in the registration complete response the cryptographic seed in encrypted form and a cryptographic key in signed form for use by an entity external to the system, the cryptographic key being one half of a key pair of an asymmetric cryptographic system that constitutes or is derived from the digital identity of the party.

12. 1. A method of establishing a digital identity for a participant, comprising: generating a cryptographic seed as random data; receiving a user secret from an external source via a secure transport mechanism; applying a first cryptographic operation to generate a cryptographic intermediate product that deterministically depends on both the cryptographic seed and the user secret, the cryptographic intermediate product constituting the digital identity of the party; applying a second cryptographic operation to the digital ID of the party to produce a cryptographic output that includes an encrypted form of the cryptographic seed; transmitting at least a portion of said encrypted output to said external source via said secure transport mechanism; permanently obfuscating the digital ID from memory after using the digital ID to generate the cryptographic output; A method comprising:

13. 13. The method of claim 12, further comprising generating a cryptographic certificate for the party as part of the cryptographic output through the second cryptographic operation.

14. establishing a temporary secret for the participant in response to a received pre-provisioning request indicating an identifier and at least one attribute of the participant, and transmitting a pre-provisioning response including at least a portion of the temporary secret; as part of establishing the interim secret, encrypting the identifier and the at least one attribute using the cryptographic seed and storing them in an interim encrypted archive unique to the party; responding to a registration completion request received after said sending of said pre-provisioning response by verifying the contents of said registration completion request against said temporary secret; encrypting the identifier and the at least one attribute using the user secret received in the registration completion request and storing them in a final encrypted archive unique to the participant; using the digital ID in the encryption and storage of the identifier and the at least one attribute in the final encrypted archive; 14. The method of claim 12 or 13, comprising:

Images