Methods and mechanisms for enabling secure digital communication between groups

Abstract

A system for establishing a digital cryptographic group includes a cryptographic engine that generates a cryptographic product from input data. The cryptographic engine responds to receiving a request over a secure transport mechanism with generation of a cryptographic product, the request including a plurality of user identifiers. The cryptographic engine also responds to receiving a subsequent second request over the secure transport mechanism by sending the cryptographic product over the secure transport mechanism, the second request also being received over the secure transport mechanism and including one of the plurality of user identifiers. The cryptographic product is a digital cryptographic group and includes the plurality of user identifiers and a common cryptographic key for use in symmetric encryption between users identified by the plurality of user identifiers or a public key unique to a user and associated with the user identifier for use in asymmetric encryption in communications between the users.

Description

[Technical field]

[0001] The present invention generally relates to the technical field of security required when using digital services between two or more groups. In particular, the present invention relates to the problem of centrally establishing trust between parties, who may rely on the centrally established trust for group communications and for use of group-related digital services. BACKGROUND OF THEINVENTION

[0002] Security in digital communication 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). A subspecies of digital communication is group communication, i.e., the use of digital communication and / or other digital services among members of a predefined group. Members of a group need to be able to access group-specific communications as easily and securely as possible, while at the same time preventing parties outside the group from accessing or interfering with the communications. Due to their inherent reliance on cryptographic applications, the groups in question are sometimes called digital crypto groups.

[0003] At least two basic approaches to group communication are known: In a centralized solution, all communication between members of a group is routed through a server or similar centralized service point. In this case, the server takes on much of the responsibility of authenticating participants and performing the necessary encryption and decryption operations. The other approach is a decentralized solution, where communication takes place directly between members. In a decentralized solution, user devices need to have access to a certain shared secret (or secrets) to provide the necessary security.

[0004] Centralized solutions have at least the disadvantage of being completely dependent on the continued access to the server of all active members of the group. On the other hand, finding a cost-effective and computationally reasonable way to distribute the shared secret has proven to be problematic for decentralized solutions. For example, in the known Diffie-Hellman scheme, each party must agree on the order in which public keys are provided for processing so that they can compute the group-wide shared secret. Also, many of the known decentralized solutions have inefficient ways of establishing a sufficient level of trust between the parties, which may make such solutions vulnerable to malicious attacks. A further disadvantage of many decentralized solutions is related to the dependency on a specific technology when using an established digital cryptography group. It would be better if the digital cryptography group was technology-agnostic, i.e., independent of any specific technology with respect to the methods that the group owners and members plan to use in the future. Abstract

[0005] 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 be used to limit the scope of the claimed subject matter.

[0006] It is an object of the present invention to overcome the above-mentioned shortcomings of the prior art and to provide a method and mechanism by which digital encryption groups can be established, utilized and enforced.

[0007] According to a first aspect, there is provided a system for establishing a digital cryptographic group, the system comprising a cryptographic engine configured to generate a cryptographic product from given input data, and a receiving end and a transmitting end of a secure transport mechanism coupled to the cryptographic engine. The cryptographic engine is configured to respond to receiving a first request by generating a cryptographic product, the first request being received over the secure transport mechanism and including a plurality of user identifiers. The cryptographic engine is configured to respond to receiving a subsequent second request by transmitting the cryptographic product over the secure transport mechanism, the second request being received over the secure transport mechanism and including one of the plurality of user identifiers. The cryptographic product is a digital cryptographic group, the digital cryptographic group including the plurality of user identifiers and including a common cryptographic key for use in symmetric cryptography between users identified by the plurality of user identifiers, and / or a user-specific and user identifier-related public key for use in asymmetric cryptography in communications between users identified by the plurality of user identifiers.

[0008] In some embodiments, the system is configured to check whether the first request includes a user-specific encryption key for each of the plurality of user identifiers. The system may then be configured to respond to finding that the first request does not include a user-specific encryption key for each of the plurality of user identifiers by augmenting data received in the first request to include a user-specific encryption key for each of the plurality of user identifiers. This includes at least the advantage that the system can flexibly respond to situations where the first request does not include all of the user-specific encryption keys.

[0009] In some embodiments, the system is configured to perform the reinforcement by requesting and receiving a user-specific encryption key from a source external to the system, which includes at least the advantage that the system is operable and flexible in situations where the missing user-specific encryption key is not in its own possession.

[0010]

[0009] In some embodiments, the system is configured to match the pieces of user-related information received in the first request with corresponding pieces of user-related information from another source to see if the pieces match each other, which includes at least the advantage of being able to detect and address fraudulent or otherwise inappropriate use of user-related information.

[0011] In some embodiments, the system is configured to react to finding that the pieces of user related information do not match each other by making a decision whether the establishment of the digital encryption group can proceed, which includes at least the advantage that the operation of the system can be flexibly adapted to different types of needs regarding how accurate each piece of information must be.

[0012] In some embodiments, the system is configured to use a signing key to digitally sign information elements included in the cryptographic group, which has at least the advantage that the information elements may be given special value as trusted information for later use.

[0013] In some embodiments, the system is configured to check from the subsequent second request whether it is directed to itself or to another recipient, and if it is found to be directed to another recipient, react by forwarding the subsequent second request to the other recipient, which includes at least the advantage that the same principles can be followed when operating in an environment where different users may belong to domains managed by different trust providers.

[0014] In some embodiments, the system is configured to replace the original authentication of the subsequent second request with the system's own authentication prior to the forwarding, which has the advantage at least that trust between the parties is maintained and may be used appropriately even when information is forwarded.

[0015] According to a second aspect, there is provided a method of establishing a digital cryptographic group, the method including receiving, over a secure transport mechanism, a first request including a plurality of user identifiers, and generating a cryptographic product in response. The method includes receiving, over the secure transport mechanism, a subsequent second request including one of the plurality of user identifiers, and responding by transmitting the cryptographic product over the secure transport mechanism. The cryptographic product is a digital cryptographic group, the digital cryptographic group including the plurality of user identifiers, a common cryptographic key for use in symmetric cryptography between users identified by the plurality of user identifiers, and / or a user-specific, user identifier-associated public key for use in asymmetric cryptography in communications between users identified by the plurality of user identifiers.

[0016] In some embodiments, the method includes checking whether the first request includes a user specific encryption key for each of the plurality of user identifiers; and responding if the first request does not include a user specific encryption key for each of the plurality of user identifiers by augmenting data received in the first request to include a user specific encryption key for each of the plurality of user identifiers. This includes at least the advantage that the method can be flexibly adapted to situations where the first request does not include all of the user specific encryption keys.

[0017] In some embodiments, the method includes, when generating the cryptographic group, digitally signing the information elements included in the cryptographic group using a signing key, which has the advantage that the method can be implemented and flexibly adapted even in situations where the system performing the method does not have own possession of the missing user-specific encryption key.

[0018] In some embodiments, the method includes checking from the subsequent second request whether it is directed to the system executing the method or to another recipient; and if so, responding by forwarding the subsequent second request to the other recipient. This includes at least the advantage that the same principles can be followed when operating in an environment where different users may belong to domains managed by different trust providers.

[0019] In some embodiments, the method includes replacing the original authentication of the subsequent second request with an authentication of the system executing it prior to the forwarding, which has the advantage at least that trust between the parties is maintained and may be used appropriately even when information is forwarded.

[0020] According to a third aspect, there is provided a computer program product comprising one or more sets of one or more machine-executable instructions configured, when executed by one or more processors, to cause the one or more processors to perform a method of the type described above. [Brief description of the drawings]

[0021] In the following drawings: [Figure 1] FIG. 2 illustrates an exchange of information during operation according to an embodiment. [Diagram 2] FIG. 2 illustrates an exchange of information during operation according to an embodiment. Detailed explanation

[0022] 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.

[0023] 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.

[0024] An example of a digital cryptographic group is a group of at least two users, such as (but not necessarily) individuals, who wish to securely share digitally transmitted information with each other, i.e., everyone in the group can trust that everyone else is who they say they are, and who wishes to ensure that no one who is not a member of the group can access the shared information. One of these users may be able to act as the owner or founder of the group.

[0025] Another example of the use of digital cryptographic groups is aimed at allowing individual users to securely hold digital attributes and present them for checks when necessary. For example, a state agency in charge of granting driver's licenses could set up and manage such groups for each valid driver's license holder. A police officer could be a (hopefully temporary) member of such a group. In this case, the police officer would have the means to perform secure digital communication with the user's digital wallet. The user's right to drive a certain type of vehicle could be stored as an attribute. The user's digital wallet could then be presented to the police officer for check. As another example, the owner of the group is a commercial company and the members are users with loyalty cards and their families. They may appear in prior art systems as holders of sub-cards associated with the main user.

[0026] In the general definition used herein, the owner or creator of a digital cryptographic group may not necessarily be a member of the group, despite assuming the role of owner or creator. This situation can be expressed by the concepts of "read privileges" and "write privileges". A member of a digital cryptographic group always has "read privileges", i.e., a member of a digital cryptographic group always has access to the attributes stored for the group as long as he or she remains a member. The owner has "write privileges", i.e., the right to decide which attributes are stored in the group, but after the group is set up, the owner does not necessarily have later access to the stored attributes or the communication between members. However, in many cases, it will be most practical for the owner to also be a member of the group.

[0027] Members of a digital cryptographic group may be users, but in at least some cases are organizations and / or devices. When members are users, it is customary to refer to them as members of the group (and / or the group owner), even though in the strictest sense the actual digital communication parties are the electronic devices operated by the users and the group owner. Such electronic devices may be, for example, computers, laptops, tablets, smartphones, portable digital assistants, or any electronic device that has the necessary means for processing and communication. In some cases, a user's programmable embedded electronic device may act as such an electronic device.

[0028] Any description of a device is intended to apply to a group of two or more devices operating together under the control of the same user, even if a plurality of devices is not specifically stated. Such a group of two or more devices can be described as consisting of devices that are linked together by a user. The concept of Self-Sovereign Identity (SSI) means that a user has cryptographically established control over the information generated in the group, including rights such as management rights, handling rights, etc. Cryptographically established control is different from rights based simply on rights bound to a specific user ID and stored, and means that the user possesses the necessary cryptographic material to read and / or write the appropriate information. The establishment of a cryptographic group is intended to provide the members of the group with ownership of such necessary cryptographic material.

[0029] Figure 1 illustrates some of the communications between and operations performed by a Trust Provider, a Group Owner, and one or more Group Members when performing a method according to an embodiment. A Trust Provider may also be referred to as a Vault to emphasize the assumption that it represents an institution with a particularly high level of digital security. Similar names include Wallet Provider, CA and / or VA (Certification Authority, Validation Authority). A Trust Provider may be operated privately or may belong to and operate under the supervision of an authority.

[0030] To start setting up a group, the group owner must at least possess a means of digitally identifying each member of the group to be formed. Although it is possible to add members to the group later, we first consider the case of setting up a group for a predefined number of known users. It should be noted that for new members added later, adding a new member to an already existing group may mean that the new member also has access to information that was processed in the group before the new member was added. However, previously processed information can be made inaccessible to the new member by either encrypting it separately in the group or by encrypting it with a key exchanged between the old members of the group (such as the so-called PGP keys; the old members distribute public keys to each other and may keep the private key for themselves). Another possibility is to first encrypt the old information with a key known by the old members and then encrypt this key to each old member individually. This last possibility may be the most cost-effective, since the amount of information shared in the group does not increase linearly with the number of members. Each member only needs to securely store his own key to the information encrypted in the group. If the new members do not need (or should not have) access to previously processed information, it may be easier to set up a new group to which the new members belong. Existing group members may later be removed from the group, which typically requires updating at least some of the keys used to securely process information related to the group.

[0031] FIG. 1 shows a schematic of step 101 where a user communicates an identifier to the group owner. Each user wants to be identified within the group by that identifier. Note, however, that for the purposes of the following discussion, it is irrelevant when and how the group owner obtains the IDs (identifiers) or other identifiers of the group members. If the group owner maintains, for example, a contact information catalog, a public demographic register, or a customer database, they may obtain the identifiers of the group members from there. If a group has i members (i is a positive integer used as an index), the user identifiers of the group members are generally referred to as UIDs. i It may also be expressed as:

[0032] In step 101 (or in some other step before), the group owner may obtain from each member of the established group their respective public keys that constitute one half of a user-specific key pair in the asymmetric cryptosystem. However, this is not required, since the public keys of group members may be used at a later time, as described below. The public key of the ith member in the group is PK UIDi It may be expressed as:

[0033] In step 102, the group owner creates an AddGroup request, i.e., a request to set up a digital cryptographic group. The AddGroup request is sent to the trust provider. The AddGroup request must contain at least an identifier for each group member and one or more attributes that each group member plans to use in the future. An example attribute is P G0 Consider a Pre-Shared Key (PSK), denoted as follows: A PSK may be intended to be used as a shared secret among group members, e.g., encryption and decryption keys in a symmetric cryptography system. The PSK and / or other attributes are treated as part of a data structure called a Keystore Group Archive, known by the acronym KGA. The formal notation is: KGA(P G0 ,...) Here, the three periods indicate that the KGA is a group member's UID i and the public keys PKUIDi of (at least some of) the group members. If we enumerate these explicitly, the formal representation becomes: KGA(P G0 ,UID i ,PK UIDi ,...)

[0034] Examples of other attributes of the KGA include, but are not limited to, the name and / or other identifying information of the digital cryptographic group, timestamps indicating the creation and modification times of the digital cryptographic group, expiration data indicating the expiration date of the digital cryptographic group, the identity of the trust provider to which the request is sent, and metadata associated with any aspect of the digital cryptographic group.

[0035] For security reasons, step 102 may include encrypting KGA. KGA An advantageous way to generate K KGA = SHA2(X25519(SK UID ,PK VID )||PK VID ||PK UID ||n) Here, 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 n denotes a cryptographic nonce, e.g. a 12-bit unique nonce. The double vertical bars || denote a bitwise OR operation. Key PK VID and key PK UID are the public keys (PKVID ) and the group owner's public key (PK UID ).

[0036] The encryption of the KGA may be done, for example, using the AES256-GCM algorithm (meaning 256-bit AES in Galois / Counter Mode). Using the notation introduced so far, the encrypted KGA can be represented as follows: Enc(K KGA , KGA(P G0 ,UID i ,PK UIDi ,...)) = AES256-GCM(SHA2(X25519(SK UID ,PK VID )||PK VID ||PK UID ||n),m,n, KGA(P G0 ,UID i ,PK UIDi ,...)) Here, the letter m represents the MAC or message authentication code of the encryption authentication tag.

[0037] Advantageously, step 102 further includes generating a pair of ephemeral keys in an asymmetric cryptographic scheme. These ephemeral keys are referred to herein as PK GRT and S.K. GRT Here, PK is a public key, SK is a private key, and the subscript GRT comes from Group Request Token. The group owner holds the private key SK GRT and store the public key PK GRT to the trust provider. The trust provider then receives the public key, PK GRTThe final response can be encrypted using , so that only the group owner can decrypt it. It is not mandatory that these keys be ephemeral, but this makes them more secure, since there is little use for them if a malicious actor later gets hold of one of them.

[0038] Sending the completed AddGroup request from the group owner to the trust provider is shown as step 103 in FIG. 1. The designation AddGroup and all other specific designations in FIG. 1 are exemplary and should not be construed as limiting in any way. Also, not all of the information described herein needs to be conveyed in one message, but multiple transmissions using a common communication channel or multiple channels may be used. Using the notation introduced above, the AddGroup request in step 103 includes at least the ephemeral public key PK GRT and the encrypted KGA.

[0039] Most advantageously, a secure transport mechanism is used to convey the AddGroup request from the group owner to the trust provider in step 103. A non-limiting example of such a secure transport mechanism is a digital communication channel using the Transport Layer Security (TLS) protocol. A system or mechanism, referred to herein as a trust provider, has a receiving end and a sending end of such a secure transport mechanism, combined with a cryptographic engine capable of performing cryptographic operations. Receiving and transmitting via the secure transport mechanism need not necessarily be over the same or similar channel or connection, although such a form is not excluded.

[0040] Step 104 of Figure 1 is generally characterized by the trust provider configuring the requested digital cipher group and storing the configured digital cipher group in the form of a data structure that can be later communicated to members of the group upon request. The trust provider's cryptographic engine may then communicate a set of user identifiers (UIDs) to the trust provider's cryptographic engine. i ), step 104 may be characterized by the trust provider's cryptographic engine responding to said receipt by generating a cryptographic product, where "cryptographic product" refers to a digital cryptographic group that includes at least a user identifier for a group member and one or more keys for enabling secure communications between group members. As will be described in more detail below, the digital cryptographic group may also include a variety of other information.

[0041] The KGA is sent encrypted in the AddGroup request 103, so the trust provider's system first decrypts it. Assuming the group owner used the method described above to generate an encryption key to encrypt the KGA in the AddGroup request 103, the trust provider's system can regenerate the key as follows: K KGA = SHA2(X25519(SK VID ,PK UID )||PK VID ||PK UID ||n) Then, the regenerated key is used to decrypt the KGA.

[0042] It has already been pointed out that when constructing the AddGroup request 103, the group owner does not necessarily have the user-specific (public) encryption keys of all group members (or in some cases does not have them at all). For this reason, as part of step 104, it is advantageous to configure the trust provider's system to check whether the received AddGroup request 103 contains a user-specific encryption key for each of the user identifiers. If a user-specific encryption key is not included for each of the user identifiers, the trust provider's system may be configured to augment the data received in the first request such that each of the plurality of user identifiers contains a user-specific encryption key.

[0043] One possibility is that the trust provider already knows the user-specific (public) encryption key, for example based on previous communication with the user. Another possibility is that the trust provider's system may be configured to perform the augmentation by requesting and receiving the user-specific encryption key from a source external to the system. As an example, two or more trust providers may be linked to each other. Each of these trust providers has a database of known users. Each of these trust providers may be, for example, an authority with which the user has previously communicated or a commercial company with its own customer database. The user-specific encryption keys, in particular the public key, may be periodically stored in such a database. Each stored encryption key has a unique relationship with a user identifier of a similar kind to that used in the AddGroup request. The trust provider's system may send a request to one or more linked trust providers and obtain the requested user-specific encryption key in response.

[0044] Similar principles may be applied with respect to other data included in the cryptographic group. The trust provider's system may augment the contents of the cryptographic group by generating missing information elements itself, requesting them from other linked sources, or both. The trust provider's system performs such augmentation as necessary according to predefined specifications governing the creation and processing of the cryptographic group.

[0045] The trust provider's system may be configured to check any pieces of information received in the AddGroup request 103, e.g. user-related information, against corresponding pieces of (user-related) information from other sources. The purpose of such a check is to see if these pieces of user-related information match each other. For example, if the AddGroup request 103 contains one or more user-specific (public) encryption keys, the trust provider's system may compare these with its own database and, if not found in its own database, may resubmit the request to other possibly linked trust providers in a similar manner as described above for the user-specific encryption keys.

[0046] Each user (or other party with group membership) may be assumed to "belong" to some trust provider, or may be assumed to have already been securely identified by some trust provider. The trust provider whose system receives the AddGroup request 103 may not be the trust provider that originally securely identified all users who will be included as members in the new group. In other words, the AddGroup request 103 may contain UIDs of one or more intended members of the group that "belong" to one or more trust providers different from the one whose system received the AddGroup request. In such a case, one possibility is that the trust provider's system simply leaves an empty space that will use a user-specific encryption key if one of its "own" users is in question. This way of operating, i.e. leaving the user-specific encryption keys of "foreign" users empty, may have further consequences, as will be described below.

[0047] If the aforementioned pieces of user-related information do not match each other, the trust provider's system may make a decision on whether to allow the establishment of the digital encryption group to continue. Both positive and negative decisions are possible, depending on how the trust provider's system is programmed to work and what decision criteria it applies.

[0048] We pointed out earlier that a digital cryptographic group, when complete, should contain, in addition to user identifiers, one or more keys to enable secure communication between group members. User-specific (public) encryption keys could satisfy this requirement, since it can be assumed that each user has a corresponding private key safely stored. Another example of such a key is the P G0 A pre-shared key (PSK) is a shared key that is generally defined as a shared encryption key used by users identified by their user identifiers. G0If the trust provider has generated a PSK, then the trust provider's system need only read it from the decrypted KGA and store it as part of the digital cryptography group. Alternatively, the trust provider may generate a PSK and store it as part of the digital cryptography group.

[0049] P G0 A PSK or other key-sharing key is an example of an attribute (or information element) that is included in a cryptographic group and that group members must subsequently trust completely. To provide such security, G0 It may be advantageous to have the PSK or other PSK digitally signed by the Group Owner (if the Group Owner generated PG0) and / or by the Trust Provider's system. According to known principles, the signing party digitally signs using its private signing key, and other parties can later verify the integrity of that information element using the signing party's corresponding public verification key.

[0050] To provide further security in subsequent stages of the method, it is advantageous to configure the trust provider system to generate a further pair of ephemeral asymmetric cryptographic keys as part of step 104. This pair of ephemeral keys is denoted herein with the subscript GAT, which stands for Group Access Token. As a non-limiting example, the trust provider system may generate a private GAT key SKGAT as follows: SK GAT = RNG(256) The operator RNG() means to generate a random binary number with the same number of bits as the (decimal) number inside the brackets. GAT For example, scalarbasemult(SK GAT) as a public key. scalarbasemult() is a function that, given a private key as input, deterministically returns the corresponding public key based on an elliptic curve, for example Curve 25519. The name of the function may change depending on the source used, but at the time of writing, documentation for the original scalarmult() function can be found at https: / / doc.libsodium.org / . If you need to generate a private / public key pair, you can also use one of the appropriate functions that gives you both keys as output.

[0051] In step 104, the trust provider's system may be configured to encrypt the created or updated KGA in a slightly different manner, depending on whether the digital encryption group is being created before sending a response to the group owner (or a previously created digital encryption group is being updated before communicating with other group members), or whether encryption is being performed in connection with communicating with group members other than the group owner (see step 109 in FIG. 1).

[0052] In the first case, an advantageous possibility is to use a key that is obtained in advance and is specific to the group owner. An advantageous method for creating and processing such a key is described in a patent application (application number EP22157019.5) which is not published at the time of filing the present application. The key in question is then called SK UAT The subscript UAT comes from User Access Token. The process of encrypting the newly created KGA may involve generating a shared secret SSGAK as follows: SSGAK = scalarmult(SK GAT , P.K. GRT ) Here, the subscript GAK comes from Group Archive Key. The function scalarmult() returns a calculated shared secret between two parties based on an elliptic curve, for example Curve 25519, making it unnecessary to transmit the actual key while relying on the security established by a mathematically linked key pair.

[0053] The newly created KGA may be encrypted as follows: Enc(SS GAK , KGA(...)) Here, the three time periods represent all the information typically included in KGA.

[0054] Before communicating with group members other than the group owner, GAK To update a KGA encrypted with key, the update operation may be written as follows: Update(Dec(SS GAK , KGA(...))) A new encryption may then be performed as described above.

[0055] If encryption is performed as part of step 109 in connection with communications with group members other than the group owner, additional security can be obtained by utilizing the secret GAT key SKGAT introduced earlier in the text. In that case, the shared secret SSGAK may be obtained as follows: SSGAK = scalarmult(SK GAT , P.K. GRT ) Here, the subscript GAK comes from the Group Archive Key, and KGA may be encrypted as follows: Enc(SS GAK , KGA(...))

[0056] Storing the KGA in this SSGAK-encrypted form on the trust provider's system serves the purpose that a key from a source external to the trust provider is always required to decrypt the stored KGA, so that even if the trust provider's security is breached and its stored KGA is leaked, it is of little use to an attacker since not even the trust provider can access its encrypted contents without the key components, which must be obtained from the group owner or one of the other group members.

[0057] As a result of the method steps described above, the KGA (ie, the cryptographic product generated by the trust provider's cryptographic engine in step 104) may be written, for example, as follows: KGA(P G0 ,UID i ,PK UIDi ,PID,GID,GMD,...) Here, P G0 is the group's PSK and UID i shows group members (including group owner) listed by their identifier, PKUID i indicates the (public) user-specific encryption keys of the group members. PID or provider ID indicates the public identifier of the trust provider, GID or group ID indicates the public identifier of the group, and GMD or group metadata indicates all metadata that may be associated with the group. The group owner's identifier and / or public key may be used with other UIDs. i and PKUID i may be treated specially so as to be distinguishable from

[0058] To increase the trustworthiness of the cryptographic group's attributes, the trust provider's system is advantageously configured to digitally sign the information elements it includes in the cryptographic group using a signing key owned by the trust provider, so that all members of the group can subsequently verify that the attributes they read from the cryptographic group are correct, i.e. that they are authentic and their integrity has not been compromised.

[0059] After step 105, the group owner has all the necessary information about the group, which may include information added by the trust providers that the trust providers themselves provided and / or requested from other linked trust providers or other sources in step 104. Furthermore, the group owner knows that all the necessary information about the group is securely stored in the trust providers' systems and ready to be distributed to the members of the group.

[0060] Step 106 shows the group owner instructing the group members to contact the trust provider and download the KGA from the trust provider's system. One advantageous way to enable the group members to do this is by using the group request token (i.e., the ephemeral public key PK GRT Additionally or alternatively, the group owner may send other information about the group to the group members in step 106.

[0061] The remaining steps shown in FIG. 1 are shown for only one group member for clarity. Similar procedures must be performed for all group members in order for the group to be fully functional. However, even if one or more group members do not fulfill their roles, the group may be available to those members of the group who have completed the required steps. It should be noted that even if only one member of the group performs these steps and only one will ever use the cryptographic group, certain advantages may be gained from using a trust provider as a secure storage of information elements related to the group.

[0062] Step 107 represents the group member formulating a request to obtain the required information about the group, and step 108 represents the group member sending the request, referred to herein as a GetGroup request, to the trust provider. The sending in step 108 is equivalent to the sending in the previous step 103 in that it may utilize a secure transport mechanism, such as a digital communication channel capable of using the Transport Layer Security (TLS) protocol.

[0063] The GetGroup request 108 must enable the trust provider to verify that the sender, i.e. the group member, is one of those authorized to receive the KGA required to act as a member of the group. Advantageously, the GetGroup request 108 includes at least a user identifier UID, which the trust provider can then combine with the user identifier UID previously received from the group owner. i . One advantageous way to include the user identifier UID in the GetGroup request 108 is to include the requester's certificate, which includes both the UID and the requester's public key. In this case, the trust provider may use the UID for the above purposes, and may also use the public key to protect a KGA that it sends in response to the requester.

[0064] Alternatively, the GetGroup request 108 preferably includes a group request token, i.e., the ephemeral public key PKGRT. Other information elements that the GetGroup request may include, for example, the group identifier GID, information indicating the identity of the group owner, various types of signed or unsigned attributes, and / or any metadata related to the group (but other information elements are also possible). However, in order to include these information elements in a GetGroup request, at least the requesting group member must have previously obtained them from the group owner.

[0065] Step 109 of Fig. 1 generally represents all the checks that the trust provider's system is configured to make in response to receiving a GetGroup request 108. Essentially, the trust provider's cryptographic engine is configured to transmit a pre-generated cryptographic product (i.e., a digital cryptographic group) over the secure transport mechanism in response to receiving a GetGroup request 108 (which includes any of a number of user identifiers previously received in an AddGroup request 103) over the secure transport mechanism. The step of the trust provider sending an AddGroup response to the group owner is shown as step 105 in Fig. 1. As with the AddGroup transmission in step 103 above, the trust provider's system preferably encrypts the KGA before sending it to the group owner in the AddGroup response 105. An advantageous form of such encryption is as follows: Enc(K KGA , KGA(...)) = AES256-GCM(SHA2(X25519(SK VID ,PK UID )||PK VID ||PK UID ||n),m,n, KGA(...))

[0066] If the KGA is stored in encrypted form on the trust provider's system, the system may first regenerate the key SSGAK needed for decryption. SSGAK = scalarmult(SK GAT , P.K. GRT ) Then, decryption is performed. Dec(SS GAK , KGA(...))

[0067] The system may then re-encrypt the KGA for transmission to the requesting group member. n = RNG(96) as a nonce, and K KGA = SHA2(X25519(SK VID ,PK UID )||PK VID ||PK UID ||n) is provided as the encryption key.

[0068] If a certificate was received in the GetGroup request, the system uses the PKUID read from the certificate for this particular user, and then encrypts it as follows: Enc(K KGA , KGA(...)) = AES256-GCM(SHA2(X25519(SK VID ,PK UID )||PK VID ||PK UID ||n),m,n, KGA(...)).

[0069] From a security point of view, it is particularly advantageous to require that the above-mentioned certificate always comes from the requester, since in step 109 (and step 210 later in FIG. 2) the Keystore Group Archive (KGA) is protected for the public key PKUID of the particular user. The certificate may be obtained with a GetGroup request as described above, but also by the trust provider's system through other PKI-based solutions, for example as described in the European patent application EP 22157019.5, another patent application by the applicant of the present application. Additionally or alternatively, if a suitable intelligent ID card, passport or corresponding document is present, the trust provider's system may read the certificate therefrom as an RSA or ECC certificate according to the X.509 specification.

[0070] Similarly, from a security perspective, it is highly advantageous to require that certificates be signed by a system of trust providers, or, in the case of interlinked trust providers, by a system of such interlinked trust providers. A party receiving a certificate may check the integrity and authenticity of the certificate and verify that it was signed by a trusted party (i.e., either the trust provider or an interlinked trust provider). This proves that the public key contained in the certificate can be trusted.

[0071] The nonce n relates to the IETF-accepted requirements for the AES-256 GCM algorithm, which provides 32 bits of additional security to encryption keys for up to 350 GB, especially when encryption keys are used for long periods of time.

[0072] Step 110 in Figure 1 represents the trust provider's system sending the encrypted KGA to the group member that requested it. This transmission is labeled in Figure 1 as a GetGroup response to emphasize its connection to the previous GetGroup request 108. As with AddGroup above, the GetGroup nomenclature is of course merely an example and other nomenclatures could be used.

[0073] As an example of the application of a method as shown in Fig. 1, a police officer on patrol may stop a citizen and want to check if the citizen has the right to drive a certain type of vehicle. A state agency in charge of granting driver's licenses could act as the group owner mentioned above. Already previously, when granting a currently valid driver's license, the authority may have formed a digital cryptographic group in which it is itself a group owner and the citizen is a member. When forming the group, the authority may have communicated the permitted vehicle types as attributes to the trust provider and asked the trust provider to digitally sign these attributes. After that, when the citizen sends a corresponding GetGroup request to join the group, the digitally signed attributes become stored in a "digital wallet", i.e. a dedicated memory location in the citizen's user device. The attributes may remain valid as long as the base document (in this example, the driver's license) is valid.

[0074] The police officer, having learned the (public) user identifier from the citizen, may send a request to the authority, including his own user identifier (and possibly public key) and adding the citizen's user identifier as an attribute of the request. The authority may then send an AddGroup request to the trust provider, requesting that the police officer be temporarily added to the previously formed digital cryptographic group that has the right to receive the attribute "permitted vehicle type" from the citizen. Alternatively, the police officers (or the police, as an organization with corresponding derivative rights during each individual officer's work) could be made members (permanent or at least long-term) of the group beforehand, so that they can also check the citizen's driver's license offline.

[0075] The trust provider system may perform the requested addition to the digital cryptographic group. A notification containing a Group Request Token (GRT) is then received by the officer's user device. The officer's user device then sends a GetGroup request to the trust provider and eventually receives a GetGroup response containing the required information. During this round of communication, one or more attributes may have been added to the digital cryptographic group, such as time-limited validity information that allows the officer's user device to be a member of the group for a short period of time.

[0076] Once the police officer becomes a member of the digital encryption group, the citizen and police officer user devices may enter into a local communication in which the citizen user device presents the previously obtained digitally signed attribute "Allowed vehicle types" to the police officer user device. The digital signature allows the police officer to verify that the presented attributes are valid. Once all verifications are completed, the police officer's user device may be removed from the digital encryption group by repeating the same communication as when it was added, or the police officer's membership in the digital encryption group may expire simply depending on the time information mentioned above. In some embodiments, the police officer is permanently or at least long-term registered in the digital encryption group.

[0077] In the above example, the authority may wish to periodically update the cryptographic group attributes so that out-of-date (or at least significantly out-of-date) attributes are not left stored on the user's device. The citizen's user device may fetch updated cryptographic groups from the trust provider according to a known update schedule and / or when prompted by the authority to do so.

[0078] 2 illustrates some of the communications between two trust providers, a group owner, and a group member, and some of the operations performed by them, when performing a method according to an embodiment. As background to this embodiment, recall the assumption that each individual user may "belong" to a trust provider of their choice. In this example, the two vertical lines in the middle represent the trust provider system, and the two vertical lines on the left and right represent the corresponding group owner and group members. For the sake of illustration, the example shown in FIG. 2 may be considered to relate to a real use case, where a group owner wants to set up a protected phone call to a group member.

[0079] Step 201 of Figure 2 is equivalent to step 101 of Figure 1 in that the group owner must have somehow obtained identifiers for the group members. This step may have occurred some time ago, for example, as is typical with users having each other's phone numbers stored on their user devices.

[0080] Step 202 represents the group owner's user device performing steps aimed at setting up a secured telephone call, i.e. creating a cryptographic group within which secured telephone calls can occur, and is thus similar to corresponding step 102 of Figure 1. The request that is made is shown as step 203 and is named an AddGroup request, similar to step 103 of Figure 1. The group owner sends the AddGroup request 203 to "his" trust provider. The AddGroup request 203 includes an encrypted Keystore Group Archive (KGA) and a group request token PK GRT Among these, the KGA is particularly a pre-shared key (PSK or P G0 , called the public key PK), and the identifier UID (and possibly the public key PK) of the group member to whom the secure telephone call should be made. UID ) and

[0081] Step 204 in Figure 4 is equivalent to step 104 in Figure 1 in that it represents the trust provider (the one the group owner "belongs to") configuring the requested cryptographic group and storing it in the form of a data structure that can later be communicated to group members upon request. When the cryptographic engine of this trust provider's system receives the AddGroup request 203) containing multiple user identifiers (UIDs of the group owner and group members) via the secure transport mechanism, it responds by generating cryptographic products, i.e., creating the requested cryptographic group. Step 205 is the AddGroup response that the trust provider's system sends back to the group owner, which is also equivalent to step 105 in Figure 5.

[0082] In step 206, the group owner's user device transmits at least the group request token PK to the group member's user equipment. GRTand the identifier VID of the group owner's trust provider. Although not explicitly shown as a separate step in Figure 2, the group member's user device uses this information to create a request to get the (encrypted KGA of) the cryptographic group. However, because the group member belongs to a different trust provider than the group owner, the GetGroup request in step 207 is not sent to the trust provider that currently has the stored data for the cryptographic group. The group member's user device sends the GetGroup request 207 to its trust provider.

[0083] The existing relationships between users and their trust providers mean that it is particularly simple and easy for corresponding devices and systems to set up and use the secure transport mechanism used to transmit the requests and responses shown in Figure 2. Sufficient keys and / or other shared secrets may have been exchanged between each user and each trust provider at some previous stage to allow these communication connections to be set up quickly and securely when needed. The above also applies to communication between trust providers. Thus, the reliance on a shared secret here does not depend on the technology used to establish it. As in the case of a PKI (Public Key Infrastructure), it is not important what encryption (ECC, RSA, etc.) or algorithm is used. It is reasonable to assume that authorities, for example, will often rely on older encryption technologies than state-of-the-art private users or private companies. Therefore, in the most favorable case, the system and method should be able to work with any kind of PK key.

[0084] The reference above to a shared secret may preferably mean a computational secret between a mathematically linked key pair, which is obtained from the product of a private key (SK) of one with a public key (PK) of the other, for example according to the ECC or RSA algorithm.

[0085] In step 208, the group member's trust provider receives the GetGroup request 207. The group member's trust provider notes that the GetGroup request 207 includes an external VID in addition to the group request token. In other words, the VID in the GetGroup request 207 identifies the group owner's trust provider, not the group member's trust provider. As shown in step 209 of FIG. 2, based on the pre-established link relationship between the trust providers, the group member's trust provider can forward the GetGroup request to the group owner's trust provider. However, the group member's trust provider uses its own authentication information (not the group member's authentication information) to authenticate the GetGroup request 209 that it forwards to the group owner's trust provider.

[0086] Step 210 of Figure 2 is similar to step 109 of Figure 1, in which the cryptographic engine of the group owner's trust provider responds to receiving the GetGroup request 209 over the secure transport mechanism (used for communication between trust providers), including one of the multiple user identifiers (group member identifier) ​​previously received in the AddGroup request 203. The group owner's trust provider system responds by sending the previously generated cryptographic product, i.e., the digital cryptographic group, over the secure transport mechanism towards the group member's trust provider (see step 211 of Figure 2).

[0087] The group member's trust provider does not need to know the contents of the received GetGroup response 211. Instead, it is sufficient to replace the authentication mechanism used between the two trust providers with the one used between the group member's trust provider and the group member. The corresponding forwarded GetGroup response is shown in step 212 of Fig. 2. Upon receiving it and decrypting its contents, the group member's user device is ready for secure communication with the group owner's user device, as shown in step 213 of Fig. 2.

[0088] One of the important advantages associated with the above mentioned methods and arrangements is the possibility to implement decentralized identifiers, commonly called DIDs. To establish trust relationships for digital communication, the trust provider may have different (public) cryptographic keys and user sign-ins for different purposes. One advantageous consequence is the possibility to apply controls at different levels. Another is the possibility that group members can appear anonymous and / or pseudonymous. Depending on the use case, group members may appear anonymous to each other or participate pseudonymously, but entirely depend on the trust relationships guaranteed by the trust provider. Similarly, it is also possible that group members can identify each other while remaining unidentified to non-members.

[0089] 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.

[0090] 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.

[0091] 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.

[0092] 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.

[0093] 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.

[0094] 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 a digital encryption group, comprising: a cryptographic engine configured to generate a cryptographic product from given input data; a receiving end and a sending end of a secure transport mechanism coupled to said cryptographic engine; Equipped with the cryptographic engine is configured to respond to receiving a first request by generating a cryptographic product, the first request being received through the secure transport mechanism and including a plurality of user identifiers; and the cryptographic engine is configured to respond to receiving a subsequent second request by transmitting the cryptographic product over the secure transport mechanism, the second request being received over the secure transport mechanism and including one of the plurality of user identifiers; The cryptographic product is a digital cryptographic group including the plurality of user identifiers, the digital cryptographic group further comprising at least a common encryption key used for common encryption between users identified by the plurality of user identifiers; and a public key associated with a user identifier and specific to the user for use in asymmetric cryptography in communications between users identified by said plurality of user identifiers; Contains any of the following: system.

2. configured to check whether the first request includes a user-specific encryption key for each of the plurality of user identifiers; and configured to respond to finding that the first request does not include a user-specific encryption key for each of the plurality of user identifiers by augmenting data received in the first request to include a user-specific encryption key for each of the plurality of user identifiers; The system of claim 1 .

3. 3. The system of claim 2, configured to perform the enforcement by requesting and receiving a user-specific encryption key from a source external to the system.

4. 4. A system as claimed in claim 1, configured to match the pieces of user-related information received in the first request with corresponding pieces of user-related information from another source to see whether the pieces match each other.

5. The system of claim 4 , configured to respond to finding that the pieces of user-related information do not match each other by making a decision as to whether establishment of the digital encryption group can proceed.

6. The system of claim 1 , configured to digitally sign information elements included in the cryptographic group using a signing key.

7. 7. The system of claim 1, further comprising: a second subsequent request configured to: check from the second subsequent request whether the request is directed to itself or to another recipient; and if it is found to be directed to another recipient, respond by forwarding the second subsequent request to the other recipient.

8. 8. The system of claim 7, configured to replace an original authentication of the subsequent second request with an authentication of the system itself before the forwarding.

9. 1. A method for establishing a digital encryption group, comprising: receiving a first request over a secure transport mechanism, the first request including a plurality of user identifiers; generating a cryptographic product in response to receiving the first request; and receiving a subsequent second request over the secure transport mechanism, the second request including one of the plurality of user identifiers; in response to receiving the second request, transmitting the cryptographic product over the secure transport mechanism; Including, The cryptographic product is a digital cryptographic group including the plurality of user identifiers, the digital cryptographic group further comprising at least a common encryption key used for common encryption between users identified by the plurality of user identifiers; and a public key associated with a user identifier and specific to the user for use in asymmetric cryptography in communications between users identified by said plurality of user identifiers; Contains any of the following: method.

10. checking whether the first request includes a user-specific encryption key for each of the plurality of user identifiers; - responding to finding that the first request does not include a user-specific encryption key for each of the plurality of user identifiers by augmenting the data received in the first request to include a user-specific encryption key for each of the plurality of user identifiers; and 10. The method of claim 9, comprising:

11. 11. A method according to claim 9 or 10, comprising digitally signing information elements included in said cryptographic group using a signing key.

12. checking from said subsequent second request whether it is directed to the system executing the method or to another recipient; if found to be intended for another recipient, responding by forwarding said subsequent second request to said another recipient; The method of any one of claims 9 to 11, comprising:

13. 13. The method of claim 12, further comprising replacing an original authentication of the subsequent second request with an authentication of the system implementing the method itself before the forwarding.

14. 14. A computer program product comprising one or more sets of one or more machine-executable instructions configured, when executed by one or more processors, to cause the one or more processors to perform a method according to any of claims 9 to 13.

Images