Method and structure for establishing a digital identity

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, who may rely on the centrally established trust in the distributed use of digital services.

[0002] Security in digital communications encompasses multiple aspects, including confidentiality (only authorized parties can access information), authentication (parties must be sure they are who they are communicating with), integrity (information has not been altered in an unauthorized manner), and non-repudiation (parties cannot deny having sent certain information). Authentication typically relies on a third party called a trust provider. A computer or smartphone user attempting to communicate with a service provider's website must first contact the trust provider's authentication service. This typically involves a user ID and a disposable key. The disposable key is retrieved from a printed list carried by the user or provided by a dedicated app running on the user's device. Once the authentication service verifies the user's identity, the user is redirected to the website they were attempting 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 other official document that a user has previously obtained 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 they like, 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 contact the service provider, they have to repeat the same authentication routine, which incurs additional costs that the user ultimately has to pay.

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

[0006] Known arrangements have additional drawbacks. They date back to the days of printed identity certificates, such as printed passports, driver's licenses, and ID cards. This typically requires 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 purchasing alcoholic beverages, but the salesperson is only entitled to know whether the user is over or under legal age. By showing their driver's license, however, the user reveals their exact age, social security number, the class of vehicle they are permitted to drive, and so on. A similar situation occurs with digital certificates, because the trust provider typically does not know, at the time of the user's authentication request, what the digital certificate will be used for when the user later communicates with the service provider. As a result, digital certificates can contain unnecessarily much user information. Abstract

[0007] This section is provided to introduce some concepts in a simplified form that are described later in the detailed description. 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 of the present invention to provide methods and arrangements for establishing, using, and enabling digital identities of parties without the drawbacks of the prior art described above. In particular, it is an object of the present invention 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 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 aspects related 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 the receiving side of the secure transport mechanism, and a second cryptographic operation is coupled to the first cryptographic operation and the transmitting side of the secure transport mechanism. The system is 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 through the secure transport mechanism. The cryptographic intermediate product constitutes the digital identity of the party. The system is configured, through the second cryptographic operation, to generate 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 the digital ID is not at risk of being accidentally revealed at a later time by at least any activity 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 includes a pre-provisioning function configured to, in response to a received pre-provisioning request indicating an identifier and at least one attribute of the participant, establish a temporary secret for the participant and transmit a pre-provisioning response including at least a portion of the temporary secret. The system may further include a registration completion function configured to respond to a registration completion request received after the transmission 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 the identifier and the at least one attribute using the cryptographic seed and store them in a temporary encrypted archive specific to the participant. The registration completion function may be 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 specific to the participant. The system may be further 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 certain preparatory actions can be performed and some temporary encrypted products can be generated for participants who have not yet provided a user secret required to complete the user's registration.

[0013] In some embodiments, the pre-provisioning functionality is configured to generate an ephemeral key pair of an asymmetric cryptographic system as the temporary secret for the participant and to send the public key of the ephemeral key pair 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 participant.

[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 ephemeral key pair, and to generate the public key of the ephemeral key pair from the private key of the ephemeral key pair using the Curve25519 Elliptic Curve Diffie-Hellman method, which provides at least the advantage that the generated key pair may bear a fixed 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 perform 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 to generate a first shared secret, and to use the first shared secret when encrypting the identifier and the at least one attribute and storing them in the temporary encrypted archive, which provides further benefits 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 the portions of cryptographic output, a public key of a further key pair of an asymmetric cryptographic system from the digital ID using the Curve25519 elliptic curve Diffie-Hellman algorithm, which provides at least the advantage that a party with whom a digital identity is established can subsequently use such 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 the digital ID is generated, 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 send in the registration complete response the cryptographic seed in encrypted form and a cryptographic key in signed form for use by entities external to the system, the cryptographic key being one half of a key pair in an asymmetric cryptographic system that constitutes or is derived from the digital identity of the party. This provides at least the advantage that a party whose digital identity has been established may receive sufficient digital information to subsequently utilize 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 deterministically depends 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 at least the advantage that the digital ID is not at risk of being accidentally revealed later, at least not by any activity 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 the contents of the registration completion re-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 certain preparatory actions can be performed and some interim encrypted product can be generated at least for parties that have not yet provided the user secret required to complete the user registration. [Brief explanation of the drawings]

[0027] [Figure 1] 1 illustrates the actions taken by the user equipment and the trust provider in an exemplary embodiment. [Figure 2] 1 illustrates some operations performed in another exemplary embodiment. [Figure 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. [Figure 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 the actions taken by the user equipment and the trust provider in an exemplary embodiment. [Figure 10]In an exemplary embodiment, actions taken and messages exchanged between a user equipment, a service provider, and a trust provider are shown. [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] In an exemplary embodiment, actions taken and messages exchanged between a user equipment, a service provider, and a trust provider are shown. Detailed explanation

[0028] In the following description, reference is made to the accompanying drawings, which form a part of this disclosure, and which show, by way of illustration, specific forms in which the present disclosure may be embodied. 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 particular 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 sufficiently unique to reliably identify a party. For example, if a mathematical algorithm is used to generate a cryptographic product, such as a cryptographic key, key set, certificate, or digital signature, using a digital or cryptographic identity as a seed, the likelihood of obtaining the same cryptographic product without knowledge of that particular digital identity should be so low as to be virtually impossible. A party capable of presenting such a cryptographic product can be safely assumed to be the party identified by that digital identity, provided, of course, that appropriate care is 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, can be significantly improved if a trusted party plays a role in its generation. This trusted party can 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 can be used. The abbreviations CA (Certification Authority) and / or VA (Validation Authority) can also be used.

[0032] The nature of digital or cryptographic IDs can be illustrated metaphorically by comparing them with the traditional world of paper documents. As of the time of this writing, a passport must contain digitally encoded information derived from the user's biometric data (e.g., facial image and fingerprint). A user's face and fingerprint represent the user's identity. A passport, on the other hand, is a "cryptographic product." It is impossible to create an identical passport without knowing what the user's face looks like and how their fingerprints are formed. On the other hand, only the appropriate government authorities know how to properly create all the technical details of a passport. Furthermore, the authorities will only consent to the creation of a passport after properly verifying that the person submitting the facial image and fingerprint has been properly identified. In this way, passport authorities play a role comparable to that of a trust provider, both in guaranteeing identity and in producing a "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 device 110. The 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 more apparent below, it is advantageous to use a dedicated device, such as an integrated circuit specially made for this purpose, as the random data generator 101. 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 by the designator PU0.

[0034] The user device 110 includes at least one of an input means 111 and device circuitry 112. The device circuitry 112 is capable of generating what is shown in FIG. 1 as a user secret 113. If present, the input means 111 may include, 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, and a microphone. A user may freely input a unique piece of digital information into the user device 110 as the user secret 113 using any such input means 111. 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 circuitry 112 may include a random data generator, etc. Generating the user secret 113 in the user device 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 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 an 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 come 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, i.e., user archive for storing keys) is used. For this reason, at this stage, the cryptographic seed or P U0 102 (and possibly other user-specific data) is referred to as a temporary encrypted archive (KUA). U0 ,...). If all encrypted archives are stored in the system 100 and not in the user device 110, they may be called VUAs (Vault User Archives).

[0036] Similarly, the USS 113 is stored for later retrieval on the user device 110, as indicated by block 114. In some embodiments, it is advantageous not to store the USS 113 on the user device 110 at all, 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 instead, the user may be required to have the user device 110 read biometric identification information, 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, so long as it provides communication security at least equivalent to that available with the Transport Layer Security (TLS) protocol at the time of writing. In a preferred embodiment, cryptographic protection of data content, such as encryption with a shared key or private key pair, may be used between the parties. 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 communications 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 communicate information to a corresponding input means of the system 100.

[0038] In this example, secure transport mechanism 120 is bidirectional, meaning that both system 100 and user equipment 110 have a receiving end and a transmitting end of secure transport mechanism 120. For convenience in setting up and maintaining communications, the two directions of 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. In one 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 using, for example, 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] Once the URT-related and UAT-related keys have been exchanged as in the previous example, one possible way to securely transmit the user secret 113 from the user device 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 the Secure Hash Algorithm 2 (SHA-2, sometimes called "Shah-2") run on the argument in parentheses, and X25519() denotes the Curve25519 elliptic curve Diffie-Hellman algorithm run on the argument in parentheses. The letter m denotes a MAC or message authentication code for a cryptographic authentication tag, and the letter n denotes a cryptographic nonce. The double vertical bar || denotes a bitwise OR operation.

[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. Other cryptographic operations may be used in addition to or instead of encrypting. Generally speaking, the system 100 may be considered to comprise a first cryptographic operation 104 coupled to the random data generator 101 and the receiving end of the secure transport mechanism 120.

[0043] In the embodiment of FIG. 1, the cryptographic seed or P U0 102 constitutes the input to the cryptographic operation 104, and the user's secret 113 received via the 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 receives, through said first cryptographic operation 104, said cryptographic seed (P U0 ) 102 and a user secret (USS) 113 received through said secure transport mechanism (120), which cryptographic intermediate product (105) constitutes said digital identity of the user. Figure 2 shows that the (first) cryptographic process 204 is a hashing process and generates a cryptographic seed (P U0 ) 102 is the input, and User Secret (USS) 113 shows alternatives for configuring the salt.

[0044] Regardless of the exact nature of the first cryptographic operation 104 (encryption, hashing, etc.), its output, i.e., 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 (a cryptographic seed or P U0 The mutual independence of the secret key 102 and the user secret or USS 113 means that the generation operation is not entirely mathematical.

[0045] In terms of entropy, 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 is 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 P U0 , the user's secret information 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, the 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 in 102 and 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 once, for example millions of bits, which can then be used for various cryptographic purposes.

[0047] Such additional cryptographic purposes are generally represented in the additional cryptographic algorithm block 106 of FIG. 1. The additional cryptographic algorithm or second cryptographic operation 106 can be, for example, a key generation algorithm. Because 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 can be used as a cryptographic seed for generating cryptographic nonce, cryptographic salt, and / or certificate key pairs. All such potential uses are generally covered in the additional cryptographic algorithm block 106.

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

[0049] The user's digital ID 105 is preferably stored no longer than necessary for its immediate use for the purposes of a further cryptographic algorithm or second cryptographic operation 106. As shown schematically in the bottom left of Figure 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 device would prevent the two original secrets (cryptographic seeds or P U0 102 and the user's secret or USS 113) can later be exposed. The risk becomes real if some vulnerability is discovered in the encryption technique or hash function 104 and / or the user's secret or USS 113 is exposed.

[0050] 3 to 6 show examples of the first and second cryptographic operations in the system 100 of FIGS. 1 and 2. Reference numeral 102 denotes a cryptographic seed (referred to as P in the above) generated by a high-quality random data generator in the trust provider's system. U0 ) is used. Reference numeral 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 configured to generate, via a first cryptographic operation, a cryptographic intermediate product that deterministically depends on both the cryptographic seed and the (user's) secret. The cryptographic intermediate product constitutes the user's digital identity. Also common to these embodiments is that the system is configured, via a second cryptographic operation, to generate a cryptographic output that includes an encrypted form of the cryptographic seed using the user's digital identity.

[0051] In the embodiment of FIG. 3, the first cryptographic operation 304 has three inputs: the cryptographic seed 102, the user secret 113, and one or more attributes 301. Preferably, but not exclusively, the attribute 301 is a user-specific attribute associated with the particular user for whom the digital ID is being generated. Additionally or alternatively, at least one of the attributes is associated with the trust provider that validated the user's certificate. For example, the trust provider's identifier may be used as an attribute. The first cryptographic operation 304 may include, for example, 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 serve as inputs to the second cryptographic operation 306. FIG. 3 does not make any assumptions about what the cryptographic output from the second cryptographic operation 306 should look like or how it should be specified. Examples of these are discussed in more detail below.

[0052] The embodiment of Figure 4 differs from the embodiment of Figure 3 in that no attributes are used as inputs to the first cryptographic operation 404. Thus, the cryptographic intermediate product (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, just like 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 of the first cryptographic operation 501. 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 whom 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 thereof, is used as 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 additional inputs such as those in FIGS. 3 and 4.

[0055] Figure 6 is similar to Figure 5 in that pre-provisioning occurs. Pre-provisioning is shown as the first half 601 of the first cryptographic operation. As in Figure 5, the inputs for pre-provisioning are the 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 unique to the user.

[0056] One application where the principle of pre-provisioning can be advantageously applied is the creation, through pre-provisioning, of a digital signature certificate for a party that does not yet "exist" (in the sense of having personally contacted the trust provider), but for which certain attributes are already known. Such a digital signature certificate may remain unchanged for future use. For example, a public authority may create such a digital signature certificate for a person to whom it has not yet granted a USS. The trust provider (the authority in this example) can regenerate the public signature key for such a user 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 the cryptographic seed 102 and the user secret 113 as inputs 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 the second cryptographic operation 606. There may also be other inputs to the second cryptographic operation 606, 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 in which 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 may be referenced as 306, 406, or 606.) In addition to the user's digital ID 105, other inputs may be used, such as attributes to be included in the certificate and / or further keys necessary to properly generate the desired certificate product 707. As previously discussed, 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 Figure 8 expands the concepts of Figure 7 a little further. 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. Attributes 842 may be selected in conjunction with the signing operation. The system may have received attributes, preferably in encrypted form, from a service provider the user plans to use after receiving the necessary certificate 833, for example. One or more attributes associated with the trust provider may be used. Compared to the conceptual level of FIG. 7, the user's private key 831, public key 832, and certificate 833 form a certificate product 807, which is the useful output of the certificate generation algorithm 806.

[0060] Figure 8 thus illustrates an example 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 the party by signing at least a portion of the cryptographic output using 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 an asymmetric cryptographic system pair of keys 831 and 832 from the digital ID 105. An example of generating such a public key 832 involves first generating a private key 831 called a 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 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 called SIGN UID One of the cryptographic products that may be generated is a final encrypted archive that is unique to the user. The information elements contained in such a final encrypted archive may be, for example, a cryptographic seed P U0 , public key PKUID , Certificate SIGN UID For example, the user's secret USS can be used as the encryption key. 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 make any observations about how the system subsequently uses the outputs, i.e., cryptographic product 107 and / or certificate product 707 or 807. Keys 831 and 832 are primarily for use by user device 110. Thus, for example, a natural possibility is that system 100 is configured to send a response carrying at least keys 831 and 832 to user device 110, e.g., via a secure transport mechanism 120 the same as or similar to that of FIG. 1, thereby bringing user device 110 into possession of keys 831 and 832. Also, if certificate 833 has been generated, as in FIG. 8, it is also transmitted. In general, system 100 is configured to transmit at least a portion of 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] 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 encrypted form as a cryptographic seed (P U0 ) 102, the encryption seed (P U0 ) 102, the decoder 901 may be configured to extract the cryptographic seed. The user device 110 can retrieve the user secret (USS) 113 from secure storage or request that the user re-enter it, after which the user device 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 in FIGS. 3-6). The user device 110's ability to recreate the user's digital ID 905 means that after receiving a response from the system 100 as in FIG. 9, the user device 110 is independent of the system 100 for all subsequent uses of cryptographic products that are or can be derived from the user's digital ID 905. Briefly returning 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 when applying further cryptographic operations 906 can be digitally verified with a sufficient level of confidence by third parties with whom the user wishes to communicate using the user equipment 110.

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

[0075] FIG. 10 illustrates an example of how the principles described above may be applied in the actions and messages exchanged between a user, a service provider, and a trust provider in an exemplary embodiment. While FIG. 10 names actors as parties, 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 such as those described above in FIGS. 1-4. The term "service provider" should be understood broadly; in addition to private companies, authorities and the like may also be considered service providers. Alternatively, a party considered a service provider may also be considered a Registration Authority (RA). FIGS. 11-16 provide more detailed examples of how certain operations in FIG. 10 may be advantageously performed.

[0076] A key feature of Figure 10 is that it depicts a two-step process on the trust provider side. These two steps can be referred to as the pre-provisioning step and the registration completion step, similar to the explanations of Figures 5 and 6 above. In the first step, the service provider (i.e., the party shown in the center of Figure 10) essentially makes the actual request to generate a digital ID for the user. The service provider does this for a user that the service provider already knows and with whom the service provider has already established a trust relationship. The nature of the corresponding previous operations is not important here, but we can assume that the trust relationship was established by a customer service, a registration authority, or through the eIDAS authorization model. The acronym eIDAS refers to the European Union's 2014 regulation on electronic identity verification, authentication, and trust services.

[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 reliability. For example, the user's MSIN (Mobile Subscriber Identification Number), or the more familiar mobile phone number, could serve as a unique identifier. In this document, the unique identifier will be abbreviated by the acronym UID.

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

[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 also include metadata and / or header information defined by one or more communication protocols. As shown in substep 1101 of FIG. 11, the user device may retrieve the public key PK from storage, such as a protected key store. URT Alternatively, the user equipment may retrieve the public key PK URT 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 within the user equipment (denoted as RNG(256)). Sub-step 1102 of Figure 11 represents the user equipment creating and transmitting the 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 Figure 10, this request is shown as AddUser request 1004. To convey AddUser request 1004 to the trust provider, a secure transport mechanism must be used. As an example, AddUser request 1004 may be transmitted over a communications connection over one or more digital networks secured by the TLS protocol. Because it triggers a pre-provisioning step at the trust provider, AddUser request 1004 is sometimes referred to as a pre-provisioning request.

[0081] The AddUser request may include, or at least can be reliably represented with a high degree of confidence, the user's identifier (UID) 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 is URT , UID, and UMD, or at least indicate it with a high degree of confidence. 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 is assumed to be in the sole possession of the user and stored in a secure key store on the user's device. A further consequence is that some information is the public key PK URT When encrypted with the secret key SK, only the user 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 receiving a public key PK from the user. URTThe service provider may create and send the AddUser request 1004 without receiving the corresponding public key. 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 that information using its private key. This consideration has some important implications for the next step described below.

[0083] Step 1005 of Figure 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 (AddUserRequest 1004) indicating a participant's identifier (UID) and at least one attribute (UMD) by establishing a temporary secret for the participant and sending a pre-provisioning response (AddUserResponse 1006 of Figure 10) containing at least a portion of the temporary secret. Furthermore, the pre-provisioning function is configured to encrypt the identifier (UID) and at least one attribute (UMD) using a cryptographic seed (corresponding to 102 of Figure 1) provided by a random data generator (corresponding to 101 of Figure 1) and store them in a temporary encrypted archive specific to the participant.

[0084] A notable 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. Therefore, at this step the trust provider is not yet able to generate a suitable digital ID for the user, as this requires cryptographic operations on both the random data provided by the internal random data generator and an additional secret obtained from the user, hence the term "pre-provisioning".

[0085] Figure 13 shows an example of sub-steps that may be 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 a pseudo-secret for the user. In this example, the pseudo-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 are referred to as 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, 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 derives the secret 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 is configured to generate

[0087] Substep 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 origin of the trust provider is not from the user but from the service provider, 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 is to use the secret ephemeral key SK received in the AddUser request. UAT and public key PK URT 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 benefit 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 temporary encrypted archive is designated as follows:

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

[0093] Secret Ephemeral Key SK UAT Since the origin of lies in the cryptographic seed obtained from the 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 public key PK URT First, calculate the shared secret SS by mathematical operations using UST and generating the identifier UID and in said encryption and storage in said temporary encrypted archive of said at least one attribute UMD, said first shared secret SS UST may be configured to use

[0094] Substep 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 substep 1302. In particular, the pre-provisioning response includes the public key PK UAT can be transmitted.

[0095] In the embodiment of Figure 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 with 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 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] Note that all steps and sub-steps described so far in Figure 10 can be repeated multiple times if necessary. As an example, consider the key PK transmitted in the AddUser request in step 1004.URT However, alternative embodiments can be envisaged in which the request 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 proper 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, so that the service provider may have 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 generate and send the first shared secret, SS UST Create a first version of the user-specific temporary encrypted archive encrypted with PK 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 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 In response, the trust provider decodes the first version according to the following formula:

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

[0100] It then creates a second version of the temporary encrypted archive that is unique to the user, this second version containing the updated shared secret key SS UST 2, and the calculation involves the key PK URT2 is used. The trust provider then obtains the corresponding second ephemeral public key, PK UAT Send 2 back.

[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 registration request 1002. Even in such embodiments, each AddUser response (or at least its payload) from the trust provider is naturally returned to the user, as described above with respect to steps 1006 and 1007 of Figure 10.

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

[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. While there is nothing against using a service provider as an intermediary in forwarding messages, 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-protected 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 returns its contents, in particular the ephemeral public key PK UATIn substep 1402, one or more user-specific secrets are generated. Such a first user-specific secret may be, for example, a USS (User Secret Salt). The USS may consist of 256 bits of a credential hash. The credential on which such a hash is calculated may be, for example, a PIN code entered by the user into the user device.

[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 such a case, the key SK URT has already been generated but is not necessarily used in previous stages of processing. URT and PK URT One advantageous 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 ) and the notation X25519() or 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 obtained from a random number generator within the user equipment.

[0107] When the user-specific secret described above is available, the user equipment can derive an encryption key K according to, for example, 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 hashing 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 a cryptographic key. This means 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 The user may encrypt the user secret salt USS using, for example, the AES256-GCM encryption method. 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 in 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 principles described above with reference to Figure 1. In other words, registration completion step 1010 ensures that the generated user's digital identity is based on a cryptographic seed and a user secret that come 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 trust provider's system can obtain 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 , SK UAT ) for GetUser request 1009 content (K USS ) The system verifies the regenerated key K USS The user private key USS can be decrypted using

[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, instead of the Argon2 algorithm, a less computationally intensive algorithm such as the SHA2 algorithm may be used. UID is called the permanent user public key in substep 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 PK UID constitutes the (user's) digital ID in this embodiment. From the Trust Provider's perspective, these are the cryptographic seed P that the Trust Provider received through the secure transport mechanism. 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 a 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 GetUser response 1011 of Figure 10. 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 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, AES256-GCM is the preferred encryption method, so the 1011 encrypted payload of the GetUser response can be represented as follows:

[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 thought of as an example of a trust provider's system generating a cryptographic output including: (a) a digital identity that is securely transmitted over secure transport mechanism 120 (see FIG. 9) to ultimately allow the user to securely recreate the established digital identity for use in various communications and transactions. An example of subsequent user device operations in step 1012 is described below.

[0139] Substep 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, e.g., in the same way as the trust provider's system did earlier. UID and PK 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 user equipment contains SIGN UID with the trust provider's corresponding public key, and the result is PK UID by checking that it matches the regenerated instance of UID This is shown in substep 1603 of Figure 16. Substep 1604 is where 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 Figure 10 and Figure 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 the RegUser request in Figure 17. The RegUser request 1702 includes, for example, the user's public key PK URT , a user identifier UID, user-specific attributes, and / or other metadata UMD may be communicated to the trust provider, which the trust provider may use to configure and store an initial version of a user-specific interim encrypted archive in step 1703. The interim encrypted archive stored in step 1703 may contain 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 exactly 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 to the trust provider over a secure channel. As in Figure 10 above, the registration request 1705 provides the public key PK URTAssuming 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 a user-specific temporary 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 in 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 in 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-described benefits and advantages may relate to one or more embodiments, and that the embodiments are not limited to those that solve any or all of the problems described or that have any or all of the benefits and advantages described. Furthermore, the number of components may be one or more, even if not specifically stated.

[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 above-described embodiments 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 methods or apparatus may include additional blocks or elements.

[0156] It will be understood that the above description is provided 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. While various embodiments have been described above with a certain degree of particularity, or with reference to one or more specific embodiments, those skilled in the art could 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 is deterministically dependent 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