Method and apparatus for enabling secure digital communication between groups

Abstract

An apparatus for establishing a digital cryptographic group includes a cryptographic engine configured to generate a cryptographic product from given input data. The cryptographic engine responds to receiving a request containing a user identifier via a secure transmission mechanism by generating a cryptographic product (101). It also responds to receiving a subsequent second request (108) comprising one of the plurality of user identifiers via the secure transmission mechanism by sending the cryptographic product (110) via the secure transmission mechanism. The password product is a digital password group, and the digital password group comprises the plurality of user identifiers; and 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.

Description

Technical Field

[0001] The present invention generally relates to the field of security techniques required for the use of digital services between groups of two or more parties. In particular, the present invention relates to the task of centrally establishing trust between the parties, who can thereafter rely on the centrally established trust in group communications or other kinds of group-related use of digital services. Background Art

[0002] Security in digital communications involves several aspects, such as confidentiality (only authorized parties can access a piece of information), authentication (the communicating parties must be sure who they are communicating with), integrity (a piece of information has not been impermissibly modified), and non-repudiation (a party cannot successfully deny having sent a piece of information). A sub-genre of digital communication is group communication, i.e., digital communications and / or the use of other digital services between members of a predefined group. Members of the group should have access to group-specific communications as easily and reliably as possible, while ensuring that parties outside the group cannot access or otherwise interfere with the communications. Due to its inherent reliance on the application of cryptography, any type of group referred to here may be referred to as a digital cryptographic group.

[0003] At least two basic approaches for group communication are known. In a centralized solution, all communications between members of the group are routed through a server or similar centralized service point. In this case, the server has considerable responsibility in authenticating the participants and performing the necessary encryption and decryption operations. Another approach is a distributed solution, where communications can take place directly between members. Distributed solutions require that user devices have access to certain shared secrets to provide the required security.

[0004] Centralized solutions have at least the following disadvantages: they are completely dependent on continuous access to the server by all active members of the group. On the other hand, in distributed solutions, finding a cost-effective and computationally reasonable way to distribute the shared secret has proven to be problematic. For example, in the known Diffie-Hellman method, the parties must agree on the order in which the public keys are presented for processing in order to enable the parties to compute the shared secret common to the group. Moreover, many known distributed solutions are inefficient in the way they establish a sufficient level of trust between the parties, which may make such solutions vulnerable to malicious attacks. Other disadvantages of many distributed solutions are related to their dependence on a specific technology when using an established digital cryptographic suite. It would be better if the digital cryptographic suite was technology-independent, i.e., did not depend on any specific technology related to the way the owner and members of the group plan to use it in the future. Summary of the invention

[0005] This Summary is provided to introduce some concepts in a simplified form that are further described below in the Detailed Description. This Summary 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.

[0006] The object is to provide a method and apparatus for establishing, utilizing and implementing a digital cipher suite without the above-mentioned disadvantages of the prior art.

[0007] According to a first aspect, a device for establishing a digital cryptographic group is provided. The device includes: a cryptographic engine configured to generate a cryptographic product from given input data; and a receiving end and a sending end of a secure transmission mechanism connected to the cryptographic engine. The cryptographic engine is configured to respond to a first request containing multiple user identifiers received via the secure transmission mechanism by generating a cryptographic product. The cryptographic engine is configured to respond to a subsequent second request containing one of the multiple user identifiers received via the secure transmission mechanism by sending the cryptographic product via the secure transmission mechanism. The cryptographic product is a digital cryptographic group that contains the multiple user identifiers, and a shared cryptographic key used in symmetric cryptography between users identified by the multiple user identifiers and / or a user-specific and user-identifier-related public key used in asymmetric cryptography in communications between users identified by the multiple user identifiers.

[0008] According to an embodiment, the apparatus is configured to check whether the first request contains a corresponding user-specific encryption key for each of the plurality of user identifiers. The apparatus may then be configured to respond to the finding that the first request does not contain a corresponding user-specific encryption key for each of the plurality of user identifiers by augmenting the data received in the first request to contain a corresponding user-specific encryption key for each of the plurality of user identifiers. This involves at least the following advantages: the apparatus can flexibly adapt to the situation where not all user-specific encryption keys are included in the first request.

[0009] According to an embodiment, the device is configured to perform said augmentation by requesting and receiving the corresponding user-specific encryption key from a source external to the device. This involves at least the following advantages: the device can operate and flexibly adapt to situations where it does not possess the missing user-specific encryption key itself.

[0010] According to an embodiment, the apparatus is configured to check a piece of user-related information received in the first request against a corresponding piece of user-related information from another source to find out whether the pieces of user-related information match each other. This involves at least the following advantages: fraudulent or otherwise inappropriate use of user-related information can be detected and reacted to.

[0011] According to an embodiment, the device is configured to respond to the finding that multiple pieces of user-related information do not match each other by making a decision as to whether to allow the establishment of the digital password group to continue. This involves at least the following advantages: the operation of the device can be flexibly adapted to different kinds of requirements on how accurate each piece of information must be.

[0012] According to an embodiment, the device is configured to digitally sign the information elements it includes in the cryptographic group using a signature key. This involves at least the following advantages: when used later, such information elements can carry a special value as trust information.

[0013] According to an embodiment, the apparatus is configured to check from the subsequent second request whether the request is to itself or to another recipient, and respond to the finding that the request is to another recipient by forwarding the subsequent second request to the other recipient. This involves at least the following advantages: the same principle can be followed when operating in an environment where different users may belong to management domains of different trust providers.

[0014] According to an embodiment, the device is configured to replace the original authentication of the subsequent second request with the authentication of the device itself before the forwarding. This involves at least the following advantages: even when forwarding information further, the trust relationship between the parties can be properly maintained and used.

[0015] According to a second aspect, a method for establishing a digital cryptographic suite is provided. The method comprises: receiving a first request comprising a plurality of user identifiers via a secure transmission mechanism, and in response, generating a cryptographic product. The method comprises: receiving a subsequent second request comprising one of the plurality of user identifiers via the secure transmission mechanism, and responding by sending the cryptographic product via the secure transmission mechanism. The cryptographic product is a digital cryptographic suite comprising the plurality of user identifiers, and a shared cryptographic key used in symmetric cryptography between users identified by the plurality of user identifiers and / or a user-specific and user-identifier-dependent public key used in asymmetric cryptography in communications between users identified by the plurality of user identifiers.

[0016] According to an embodiment, the method comprises: checking whether the first request contains a corresponding user-specific encryption key for each of the plurality of user identifiers, and responding to a finding that the first request does not contain a corresponding user-specific encryption key for each of the plurality of user identifiers by extending the data received in the first request to contain a corresponding user-specific encryption key for each of the plurality of user identifiers. This involves at least the following advantages: the method is flexibly applicable to situations where not all user-specific encryption keys are included in the first request.

[0017] According to an embodiment, the method comprises: in generating the cryptographic group, using a signature key to digitally sign the information elements included in the cryptographic group. This involves at least the following advantages: the method can operate and flexibly adapt to the situation where the device executing the method itself does not possess the missing user-specific encryption key.

[0018] According to an embodiment, the method comprises checking from the subsequent second request whether the request is destined for the device executing the method or for another recipient, and responding to the finding that the request is destined for another recipient by forwarding the subsequent second request to the other recipient. This involves at least the following advantages: the same principle can be followed when operating in an environment where different users may belong to management domains of different trust providers.

[0019] According to an embodiment, the method comprises: before said forwarding, replacing the original authentication of said subsequent second request with the authentication of the device performing the method. This involves at least the following advantages: even when forwarding information further, the trust relationship between the parties can be properly maintained and used.

[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, which, when executed by one or more processors, are configured to cause the one or more processors to perform a method of the type described above. BRIEF DESCRIPTION OF THE DRAWINGS

[0021] In the attached picture:

[0022] Figure 1 illustrates the information exchange when operating according to an embodiment, and

[0023] Figure 2 The information exchange when operating according to the embodiment is illustrated. DETAILED DESCRIPTION

[0024] In the following description, reference is made to the accompanying drawings which form a part of the present disclosure and in which are shown by way of illustration specific aspects in which the present disclosure may be placed. It should be understood that other aspects may be utilized and structural or logical changes may be made without departing from the scope of the present invention. Therefore, the following detailed description should not be considered restrictive, as the scope of the present disclosure is defined by the appended claims.

[0025] For example, it should be understood that disclosures related to the described method are also valid for a corresponding device or system configured to perform the method, and vice versa. For example, if a specific method step is described, the corresponding device may include a unit for performing the described method step, even if such a unit is not explicitly described or shown in the drawings. On the other hand, for example, if a specific device is described based on functional units, the corresponding method may include steps for performing the described functions, even if such steps are not explicitly described or shown in the drawings. In addition, it should be understood that the features of the various example aspects described herein may be combined with each other unless specifically noted otherwise.

[0026] An example of a digital cryptographic group is a group of at least two users, such as (but not necessarily) individuals, who wish to share digitally transmitted information securely between each other, i.e., such that each of the group can trust that the others are who they claim to be, and such that parties that are not members of the group cannot access the shared information. One of the users may act as the owner or creator of the group.

[0027] Another example of utilizing a digital cryptographic group is one where the purpose is to enable a single user to securely possess a digital attribute and present it for inspection when needed. For example, a state agency responsible for granting driver's licenses could set up and manage such a group for each valid driver's license holder. Police officers could be members of such a group (preferably temporary members), in which case the police officer would have a means for secure digital communication with the user's digital wallet. The user's authority to drive a specific type of vehicle could be stored as an attribute, and the user's digital wallet could then be presented to the police for inspection. As another example, the owner of the group could be a commercial enterprise, while the members could be a user with a loyalty card and his or her family members, who in prior art systems appear as owners of slave cards associated with the master user.

[0028] In the general definition used in this article, the owner or creator of a digital password group is not necessarily a member of the group, despite having the described role of owner or creator. This situation can be visualized with the concept of read permissions and write permissions. Members of a digital password group always have read permissions; in other words, they can continuously access the properties stored for the group as long as they remain members. Although the owner has write permissions, that is, the right to decide what properties will be stored for the group, after setting up the group, the owner does not necessarily have access to the stored properties or communications between members later. However, in many cases, it is most practical for the owner to also become a member of the group.

[0029] The members of a digital cryptographic group may be users, but may also be organizations and / or devices, at least in some cases. Where members are users, they are usually referred to as members of the group (also referred to as the group owner itself), even though, strictly speaking, the parties involved in the actual digital communication are electronic devices operated by the users and the group owner. Such electronic devices may be, for example, computers, laptop computers, tablet computers, smart phones, portable digital assistants, or some other electronic devices including the required processing and communication means. In some cases, a user's programmable, implantable electronic device may serve as such an electronic device.

[0030] All references to a single device are meant to also cover groups of two or more devices working together under the supervision of the same user. Such a group of two or more devices can be described as consisting of devices that a user has linked together. Employing the concept of Self-Sovereign Identity (SSI) means that the user has cryptographically established control over the information generated into the group, including permissions such as management rights, processing rights, etc. Cryptographically established control is different from permissions that are based solely on certain storage permissions tied to a specific user ID: it means that the user possesses the necessary cryptographic elements to read and / or write the appropriate information. The purpose of establishing a cryptographic group is to provide members of the group with this possession of the necessary cryptographic elements.

[0031] Figure 1 Some communications between, and some operations performed by, a trust provider, a group owner, and one or more group members when executing a method according to an embodiment are illustrated. A trust provider may also be referred to as a vault, emphasizing that it represents the assumption of an institution with an extremely high level of digital security. Similar names that may also be used for trust providers are wallet providers and the abbreviations CA and / or VA (certification authority, verification authority). A trust provider may operate privately, or it may belong to an institution and / or operate under the supervision of an institution.

[0032] In order to start setting up a group, the group owner should have at least some means for digitally identifying each member of the group to be formed. More members can be added to the group later, but here we first consider the case of setting up a group for a predefined number of known users. With regard to new members to be added later, it should be noted that adding new members to a pre-existing group may mean that the new member will also gain access to information processed in the group before the new member was added. New members can be prevented from accessing previously processed information by encrypting previously processed information individually within the group, or using keys exchanged between old members in the group (such as so-called PGP keys, where old members may have distributed their public keys to each other while keeping their own secret keys) to encrypt previously processed information. Another possibility is to encrypt the old information only once with a key known to the old members, and to encrypt the key individually for each old member. This last possibility may be the most cost-effective possibility, because the amount of information shared within the group does not grow in proportion to the number of members; each old member only needs to securely store their own key for the encrypted information within the group. If the new member absolutely does not need (or should not) access to earlier processed information, it is more straightforward to set up a new group to which the new member belongs. Existing group members may also subsequently be removed from the group; this typically requires updating at least some of the keys used to securely process information associated with the group.

[0033] Figure 1 Step 101 is schematically shown, in which users transmit to the group owner an identifier by which they wish to be known in the group. However, it should be noted that for the purposes of the following description, it is immaterial how and when the group owner obtains the member ID or other identifier of a group member. If the group owner maintains, for example, a directory of contact information, an official register of demographic information, or a customer database, it can read the identifiers of the group members from there. Since there may be i members in a group, where i is a positive integer used as an index, the user identifier of a group member may generally be referred to as a UID i .

[0034] At step 101 (or at any other previous step), the group owner may also obtain a corresponding public key from each member of the group to be set up, which constitutes half of a user-specific key pair of the asymmetric cryptography system. However, this is not necessary, as the public keys of the group members may come into play later, as will be described later in this document. The public key of the i-th member in the group may be referred to as PK UIDi .

[0035] At step 102, the group owner writes an AddGroup request, i.e., a request to set a digital password group. The AddGroup request will be directed to the trust provider and should contain at least the identifier of the group member and one or more attributes intended for future use by the group member. As an example of an attribute, consider here a group called P G0 A pre-shared key (PSK) is a key that is used as a shared secret between group members, such as an encryption and decryption key for a symmetric encryption method. The PSK and / or other attributes are handled as part of a data structure called a keybase group archive, abbreviated KGA. According to the formal nomenclature, there are:

[0036] KGA(P G0 ,…)

[0037] The three periods indicate that the KGA may also contain other attributes, such as the group member identifier UID i and / or the public keys PK of (at least some) group members UIDi If these were to be listed explicitly, the formal naming would be:

[0038] KGA(P G0 ,UID i ,PK UIDi ,…).

[0039] Examples of other possible attributes in the KGA include, but are not limited to: the name and / or other identifier of the digital cryptographic group, timestamps showing, for example, when the digital cryptographic group was created and modified, expiration data showing how long the digital cryptographic group should remain valid, an identifier of the trust provider to which requests will be directed, and metadata relating to any aspect of the digital cryptographic group.

[0040] For security reasons, step 102 should include encrypting KGA. Generate encryption key K KGA The advantageous way is:

[0041] K KGA =SHA2(X25519(SK UID ,PK VID )||PK VID ||PK UID ||n)

[0042] Among them, SHA2() means executing Secure Hash Algorithm 2 on the parameters in parentheses, and X25519() means applying Curve25519 elliptic curve Diffie-Hellman method to the parameters in parentheses. The letter n represents a cryptographic random number, such as a 12-bit unique random number. The double vertical line || represents a bit-by-bit logical OR operation. The key PK VID and PKUID They are trust providers (PK VID ) and the group owner (PK UID )'s public key.

[0043] The encryption of the KGA can be performed, for example, using the AES256-GCM method, which means 256-bit AES in Galois / Counter mode. Using the notation introduced so far, the encrypted KGA can be represented as:

[0044] Enc(K KGA ,KGA(P G0 ,UID i ,PK UIDi ,…))

[0045] =AES256-GCM(SHA2(X25519(SK UID ,PK VID )

[0046] ||PK VID ||PK UID ||n),m,n,KGA(P G0 ,UID i ,PK UIDi ,…))

[0047] The letter m represents the MAC or message authentication code used to encrypt the authentication tag.

[0048] Furthermore, it is advantageous for step 102 to include the generation of a pair of temporary keys of an asymmetric cryptographic method. These temporary keys are referred to herein as PK GRT and SK GRT , where PK represents the public key, SK represents the secret key, and the subscript GRT comes from the term Group Request Token. The group owner will keep the secret key SK GRT The public key PK is stored and provided to the trust provider in the add group request GRT . In this way, the trust provider can use the public key PK GRT to encrypt its final response, thus ensuring that only the group owner can decrypt it. The ephemeral nature of these keys is not mandatory, but it increases security because a malicious party that later comes into possession of any of these keys will rarely use it.

[0049] Send the completed add group request from the group owner to the trust provider, such as Figure 1 As shown in step 103 in . Figure 1The naming of the add group and all other specific naming in step 103 is merely exemplary and should not be understood as limiting in any sense; naturally, some other naming may be used for the message. It is also not necessary to transmit all the information described here in a single message, but multiple transmissions over a common communication channel or even multiple channels may be used. Using the notation introduced above, the add group request of step 103 may contain at least the temporary public key PK GRT and encrypted KGA.

[0050] At step 103, the add group request is most advantageously transmitted from the group owner to the trust provider using a secure transmission mechanism. A non-limiting example of such a secure transmission mechanism is a digital communication channel in which the TLS (Transport Layer Security) protocol can be used. The device referred to herein as the trust provider includes a receiving end and a sending end of such a secure transmission mechanism, which is connected to a cryptographic engine capable of performing cryptographic operations. Receiving and sending via the secure transmission mechanism are not necessarily through the same or similar channels or connections, although this is not excluded.

[0051] Figure 1 Step 104 in the above method can be generally characterized as the trust provider setting up the requested digital cryptographic group and storing it in the form of a data structure that can be later transmitted to the members of the group upon request. Step 104 can also be characterized as a cryptographic engine in the trust provider's device responding to receiving a plurality of user identifiers (UIDs) via the secure transmission mechanism by generating a cryptographic product. i ) (i.e., add group request 103). Here, the term cryptographic product refers to a digital cryptographic group that includes at least user identifiers of group members and one or more keys for enabling secure communication between group members. The digital cryptographic group may also include various other information, as will be described in more detail later herein.

[0052] When the KGA appears in an encrypted form in the Add Group Request 103, the trusted provider's device should first decrypt it. Assuming that the group owner encrypts the KGA in the Add Group Request 103 using the method described above for generating encryption keys, the trusted provider's device can regenerate the key as

[0053] K KGA =SHA2(X25519(SK VID ,PK UID )||PK VID ||PK UID ||n)

[0054] And the KGA is decrypted using the regenerated key.

[0055] As noted above, it is not necessary for the group owner to possess the user-specific (public) encryption keys of all (or even any) group members when constructing the add group request 103. To this end, it is advantageous to configure the trust provider's apparatus to check whether the received add group request 103 contains a corresponding user-specific encryption key for each user identifier as part of step 104. If not, the trust provider's apparatus may be configured to expand the data received in the first request to contain a corresponding user-specific encryption key for each of the plurality of user identifiers.

[0056] One possibility is that the trust provider already knows the corresponding user-specific (public) encryption key, for example based on some previous communications with the user. As another possibility, the device of the trust provider can be configured to perform the expansion by requesting and receiving the corresponding user-specific encryption key from a source outside the device. As an example, the situation where there are two or more trust providers linked to each other can be considered. Each such trust provider has its previously known user database: the trust provider can be, for example, a different institution with which some users have previously communicated, and / or a different commercial enterprise each having its own customer database. User-specific encryption keys (particularly public keys) can be conventionally stored in such a database, and each such stored encryption key has a clear relationship with a corresponding user identifier of a similar type used in the add group request. The device of the trust provider can send a request to one or more such linked trust providers, and obtain the requested user-specific encryption key in response.

[0057] Similar principles apply to other data to be included in the cipher suite: the trust provider's device can augment the contents of the cipher suite by generating any missing information elements (either by itself, by requesting them from linked other sources, or by both). If necessary, the trust provider's device performs any such augmentation according to predefined specifications governing the creation and processing of cipher suites.

[0058] The apparatus of the trust provider can be configured to check any piece of information (e.g., user-related information) received in the add group request 103 against a corresponding piece of (user-related) information from another source. If performed, the purpose of this check is to find out whether these pieces of user-related information match each other. For example, if the add group request 103 contains one or more user-specific (public) encryption keys, the apparatus of the trust provider can compare these with its own database, or if it is not found in its own database, it can request again from other trust providers that may be linked, just like the above-mentioned request for user-specific encryption keys.

[0059] Each user (or other party that qualifies for membership in a group) may be assumed to "belong to" a certain trust provider, or to be initially securely identified by a certain trust provider. The trust provider whose device receives the add group request 103 may not be the trust provider that initially securely identifies all of the users that will be included as members of the new group. In other words, the add group request 103 may contain the UIDs of one or more expected members of the group, and the one or more expected members "belong to" one or more different trust providers rather than the trust provider whose device receives the add group request. In this case, one possibility is that the trust provider's device simply leaves empty space, and if one of its "own" users has a problem, it will use user-specific encryption keys in this space. This mode of operation, i.e. leaving the user-specific encryption keys of "foreign" users empty, may have certain further consequences described later in this article.

[0060] If the plurality of pieces of user-related information do not match each other, the trust provider's device can make a decision on whether to allow the establishment of the digital key set to proceed. Both positive and negative decisions are possible, depending on how the trust provider's device has been programmed to operate and what decision criteria it applies.

[0061] As noted above, in addition to the user identifier, a digital cryptographic group, when complete, should contain one or more keys to enable secure communications between group members. User-specific (public) encryption keys can satisfy this requirement, since each user can be assumed to have a corresponding secret key securely stored. Another example of such a key is the one referred to above as P G0 The pre-shared key (PSK), P G0 Usually defined as a public encryption key used in symmetric encryption between users identified by user identifiers. G0 , then the trust provider's device can simply read it from the decrypted KGA and store it as part of the digital cipher suite. As another alternative, the trust provider's device can generate such a PSK and store it as part of the digital cipher suite.

[0062] P G0 or other PSKs are examples of attributes (or information elements) included in a cryptographic suite, which group members must then be able to fully rely on. To provide this security, it is advantageous for the group owner (if the group owner has generated the PSK) to generate a PSK. G0 ) and / or by a trusted provider's device to P G0 Or other PSK for digital signing. According to known principles, the signing party uses its secret signing key to digitally sign, so that other parties can later use the signing party's corresponding public verification key to verify the integrity of the information element in question.

[0063] In order to provide additional security in subsequent stages of the method, it is advantageous to configure the trust provider's apparatus to generate another pair of temporary keys of an asymmetric cryptographic method as part of step 104. This pair of temporary keys will be referred to herein as the subscript GAT, denoting a group access token. As a non-limiting example, the trust provider's apparatus may generate a secret GAT key SK GAT for:

[0064] SK GAT =RNG(256)

[0065] The operator RNG() generates a random binary number with as many digits as the (decimal) number in the brackets. Then, the corresponding public key PK GAT can be used, for example, as a function from scalarbasemult(SK GAT ) is generated using the public key of . Here, scalarbasemult() is a function based on an elliptic curve (e.g. Curve25519) that, when given a secret key as input, deterministically returns the corresponding public key. 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 / . Whenever a pair of secret and public keys needs to be generated, this can also be done using an appropriate single function that gives both keys as output.

[0066] The trust provider's apparatus may be configured to encrypt the created or updated KGA in slightly different ways depending on whether the cryptographic group is created prior to sending a response to the group owner at step 104 (or is updated prior to communicating with any other group member) or whether the encryption is done in association with communicating with group members other than the group owner, see Figure 1 In the first case, an advantageous possibility is to utilize a previously obtained key specific to the group owner. An advantageous method for creating and handling such a key is described in the co-pending patent application No. EP22157019.5, which has not been published at the filing date of this application. The key in question is referred to in the method as SK UAT , where the subscript UAT comes from the user access token. The process of encrypting the newly created KGA may involve generating a shared secret SS GAK for:

[0067] SS GAK =scalarmult(SK GAT ,PK GRT )

[0068] Where the subscript GAK comes from the group archive key. The function scalarmult() is a function based on elliptic curves (such as Curve25519) that returns a calculated shared secret between two parties, so that the actual key does not need to be sent while relying on the security established by mathematically linked key pairs. The newly created KGA can then be encrypted as:

[0069] Enc(SS GAK ,KGA(…))

[0070] Here, the three periods usually again indicate all the information included in the KGA. However, if the situation is to update a previously used SS GAK As one of the key-encrypted KGAs, before communicating with any group members except the group owner, the update operation can be described as:

[0071] Update(Dec(SS GAK ,KGA(…)))

[0072] Thereafter, a new encryption can be performed similarly to the above.

[0073] If encryption is done as part of step 109, then communications with group members other than the group owner may be associated with the group owner by utilizing the secret GAT key SK described earlier herein. GAT for extra security.

[0074] In this case, the shared secret SS GAK can be obtained as:

[0075] SS GAK =scalarmult(SK GAT ,PK GRT )

[0076] where the subscript GAK comes from the group archive key. KGA can then be encrypted as

[0077] Enc(SS GAK ,KGA(…))

[0078] In this way, using SS GAK The KGA is stored in an encrypted form on the trust provider's device with the intention that a key from a source external to the trust provider is always required to decrypt the stored KGA. Thus, even if security at the trust provider is compromised and the stored KGAs are exposed, they are of little use to an attacker because even the trust provider cannot access their encrypted contents without those key components, which must come from the group owner or one of the other group members.

[0079] As a result of the above process steps, the KGA (i.e., the cryptographic product of the cryptographic engine of the trust provider's device generated in step 104) may be described as, for example:

[0080] KGA(P G0 ,UID i ,PK UIDi ,PID,GID,GMD,…)

[0081] Among them, P G0 is the group's PSK, UID i Marks group members (including group owner) listed by their identifiers, PK UIDi The (public) user-specific encryption key that marks the group members, the PID or Provider ID is the public identifier of the trust provider, the GID or Group ID is the public identifier of the group, and the GMD or Group Metadata marks all possible metadata associated with the group. The identifier and / or public key of the group owner can be picked out to allow it or them to be associated with the UID i and PK UIDi separate from the rest of the .

[0082] In order to enhance the trustworthiness of the attributes in the cryptographic group, it is advantageous to configure the trust provider's device to digitally sign the information elements it includes in the cryptographic group using a signature key it owns. This enables all members of the group to later ensure that the attributes read from the cryptographic group are correct, i.e. their originality and integrity have not been compromised.

[0083] The trust provider's device sends an add group response to the group owner as follows: Figure 1 As shown in step 105 of the add group response 105. Similar to the earlier add group transmission in step 103, the trust provider's device advantageously encrypts the KGA before sending it to the group owner in the add group response 105. An advantageous form of this encryption is:

[0084] Enc(K KGA ,KGA(…))

[0085] =AES256-GCM(SHA2(X25519(SK VID ,PK UID )

[0086] ||PK VID ||PK UID ||n),m,n,KGA(…))

[0087] After step 105, the group owner has all necessary information about the group, including the extended information provided by the trust provider itself and / or requested from linked other trust providers or other sources during step 104. In addition, the group owner knows that all necessary information about the group is securely stored in the trust provider's device and is ready to be distributed to the members of the group from there.

[0088] Step 106 represents the group owner instructing the group members to contact the trust provider and download the KGA from the trust provider's device. An advantageous way to enable the group members to do this is to send them a copy of the group request token, i.e., the temporary public key PK GRT Additionally or alternatively, at step 106, the group owner may send other information about the group to the group members.

[0089] Figure 1 The remaining steps shown in are shown with respect to only one group member in order to keep the diagram clear. Similar steps should be performed for all group members to make the group fully operational. However, those group members that have completed the execution of the corresponding steps may have already utilized the group even if one or more group members have failed to complete their portion. It may be noted here that certain advantages may be obtained by using a trust provider as a secure storage for information elements associated with the group, even if only one member of the group will actually perform the steps and use the cryptographic group in the future.

[0090] Step 107 represents that the group member writes a request for obtaining necessary information about the group, and step 108 represents that the group member sends the request (herein referred to as a GetGroup request) to the trust provider. The sending of step 108 is similar to the sending of the earlier step 103, in that it can utilize a secure transmission mechanism, such as a digital communication channel in which the TLS (Transport Layer Security) protocol can be used.

[0091] The Get Group Request 108 should allow the trust provider to ensure that the sender (i.e., the group member) is one of those senders that are allowed to receive the KGA required to operate as a group member. Advantageously, the Get Group Request 108 thus contains at least the user identifier UID, which the trust provider can then compare with the user identifier UID previously received from the group owner. i A list of users to compare. An advantageous way to make the get group request 108 contain the user identifier UID is to make it contain the requester's certificate, which contains both the UID and the requester's public key. In this case, the trust provider can use the UID for the above purposes and use the public key to protect the KGA, which will be sent to the requester as a response.

[0092] In addition, the get group request 108 advantageously contains a group request token, ie, a temporary public key PK GRT Other possible information elements that a get group request may contain (at least if the requesting group member has previously obtained them from the group owner) include, but are not limited to, the group identifier GID, a reference to an identifier of the group owner, various types of signed or unsigned attributes, and / or any metadata associated with the group.

[0093] Figure 1 Step 109 in generally represents all checks that the trust provider's apparatus is configured to perform in response to receiving the get group request 108. Essentially, the cryptographic engine in the trust provider's apparatus is configured to respond to receiving the get group request 108 (which includes one of the multiple user identifiers previously received in the add group request 103) via the secure transmission mechanism by sending the previously generated cryptographic product (i.e., the digital cryptographic group) via the secure transmission mechanism.

[0094] Considering that KGA was previously stored in encrypted form in the trust provider's device, the device can first regenerate the key SS required for decryption GAK for

[0095] SS GAK =scalarmult(SK GAT ,PK GRT )

[0096] And then perform decryption

[0097] Dec(SS GAK ,KGA(…)).

[0098] The device may then proceed to encrypt the KGA again (this time for sending to the requesting group member) by providing

[0099] n = RNG(96)

[0100] As a random number, and provide

[0101] K KGA =SHA2(X25519(SK VID ,PK UID )||PK VID ||PK UID ||n)

[0102] as encryption key (using the PK of this specific user UID , read from the certificate if received in the get group request), and then encrypt:

[0103] Enc(K KGA ,KGA(…))

[0104] =AES256-GCM(SHA2(X25519(SK VID ,PK UID )

[0105] ||PK VID ||PK UID ||n),m,n,KGA(…)).

[0106] From a security point of view, it is particularly advantageous to require that the above-mentioned certificate always comes from the requester, because in step 109 (and later in Figure 2 The keystore group archive is secure for the user with respect to the public key PKUID of the specific user, as described in step 210 of the present invention. The certificate may be present in the Get Group Request as described above, but it may also be made known to the trust provider's device by some other PKI-based solution, for example according to the method described in the co-pending European patent application EP22157019.5 of the same applicant. Additionally or alternatively, if there is a suitable smart ID card, passport or corresponding document, the trust provider's device may read the certificate therefrom as an RSA or ECC certificate according to specification X.509.

[0107] Similarly, from a security point of view, it is highly advantageous to require that the certificate be signed by a device of the trust provider, or in the case of several interlinked trust providers, by a device of one of such interlinked trust providers. Any party receiving the certificate can then check the integrity and authenticity of the certificate and determine that it is signed by a trusted party (i.e., by the trust provider or one of the interlinked trust providers). This in turn proves that the public key contained in the certificate can be reliable.

[0108] In the random number n, it can be noted that it is related to the requirements of the AES-256GCM algorithm accepted by the IETF. It provides 32 additional bits of enhanced security to the encryption key, especially when it is used for a longer period of time, up to a maximum of 350GB.

[0109] Figure 1 Step 110 in FIG. 1 represents the trust provider's device sending the encrypted KGA to the group member requesting the encrypted KGA. Figure 1 108 is marked as Get Group Response to emphasize its association with the previous Get Group Request 108. Similar to the earlier naming of Add Group, the naming of Get Group is naturally just an example, and other naming may also be used.

[0110] As an application Figure 1As an example of a method of the type shown in , consider a situation in which a police officer on routine patrol stops a citizen and wants to check the citizen's authority to drive a vehicle of a particular type. The state agency responsible for granting driver's licenses can act as a group owner. Previously, when granting currently valid driver's licenses, the agency may have formed a digital cryptographic group in which it itself is the group owner and the citizen is a member. When forming the group, the agency can transmit the allowed vehicle types as attributes to the trust provider and ask the trust provider to digitally sign these attributes. When the citizen subsequently joins the group by sending a corresponding get group request, the digitally signed attributes are stored in a "digital wallet", i.e. a dedicated storage location in the citizen's user device. The attributes can remain valid for as long as the underlying document (in this example: the driver's license).

[0111] After learning the (public) user identifier from the citizen, the police officer can send a request to the agency, giving their own user ID (and possibly public key) and also adding the citizen's user identifier as an attribute to the request. The agency can then send an add group request to the trust provider, essentially requesting that the police officer be temporarily added to the previously formed numeric cryptographic group with the authority to receive the attribute "allowed vehicle types" from the citizen. As an alternative, the police officer (or the police force as an agency, with the corresponding derived authority when the individual officer is on duty) can already be a (permanent or at least long-term) member of this group in order to allow offline checking of the citizen's driver's license.

[0112] The trust provider's apparatus may perform the requested addition to the digital password group. An indication containing a group request token will then arrive at the police officer's user device. When the police officer's user device then sends a get group request to the trust provider, it eventually receives a get group response containing the information it needs. During this round of communication, one or more attributes may have been added to the digital password group: for example, time-limited validity information that only allows the police officer's user device to remain a member of the group for a short period of time.

[0113] Once the police officer becomes a member of the digital password group, the user devices of the citizen and the police officer can enter into a local communication, wherein the citizen's user device presents the previously obtained, digitally signed attribute "allowed vehicle types" to the police officer's user device. Thanks to the digital signature, the latter is able to verify that the presented attribute is valid. When all checks are completed, the police officer's user device can be removed from the digital password group via a round of communication similar to when it was added, or can simply rely on the previously mentioned time information to allow the police officer's membership in the digital password group to expire. As another alternative, there is a permanent or at least long-term membership of the police in the group.

[0114] In the example scenario described above, an organization may wish to periodically update the attributes of a cryptographic suite in order to ensure that no outdated attributes (or at least no severely outdated attributes) remain stored in a user's device. A citizen's user device may obtain an updated cryptographic suite from a trusted provider following a known update schedule and / or when prompted to do so by the organization.

[0115] Figure 2 Some communications between and operations performed by two trust providers, a group owner, and a group member when executing a method according to an embodiment are illustrated. As background to this embodiment, it can be recalled that each user can "belong" to the trust provider of his or her choice. In this example, the two vertical lines in the middle represent the devices of the trust provider, while the two vertical lines on the right and left represent the group owner and group member, respectively. For illustrative purposes, Figure 2 The example shown in can be considered to involve a real-world use case where a group owner wants to set up a protected phone call with group members.

[0116] Figure 2 Step 201 in Figure 1 Similar to step 101 in , the group owner should obtain the identifiers of the group members in some way or another. This step may even have already happened, for example, it is typical that users store each other's phone numbers in their user devices.

[0117] Step 202 may also be performed with Figure 1 , it represents the user equipment of the group owner performing steps aimed at setting up a protected call, i.e. creating a password group in which a protected call can take place. The written request is shown as step 203 and is named Add Group Request, which is very similar to Figure 1 Step 103. The group owner sends an add group request 203 to its "own" trust provider. Most advantageously, the add group request 203 contains an encrypted KGA (key store group archive) and a group request token PK GRT , where KGA contains the pre-shared key (hereinafter referred to as PSK or P G0 ) and the identifier UID of the group member to which the protected call should be made (and possibly the public key PK UID ).

[0118] Step 204 in FIG. 4 may be performed with Figure 15 , it represents the trust provider (the one to which the group owner "belongs") setting up the requested cryptographic suite and storing it in the form of a data structure that can later be transmitted to the group members upon request. The cryptographic engine in the trust provider's device responds to receiving an add group request 203 containing multiple user identifiers (the UIDs of the group owner and group members) via a secure transport mechanism by generating cryptographic products (i.e., by creating the requested cryptographic suite). Step 205 is the add group response that the trust provider's device sends back to the group owner, again very similar to step 105 in FIG. 5 .

[0119] In step 206, the user equipment of the group owner sends at least a group request token PK to the user equipments of the group members. GRT and the group owner's trust provider identifier VID. Although Figure 2 Although not explicitly shown as a separate step in , the user device of the group member uses this information to compose a request for obtaining (the encrypted KGA of) the cryptographic group. However, since the group member belongs to a different trust provider than the group owner, the obtain group request of step 207 is not sent to the trust provider that currently holds the storage data of the cryptographic group. Instead, the user device of the group member sends the obtain group request 207 to its own trust provider.

[0120] The pre-existing relationship between users and their trusted providers means that their corresponding devices and equipment are particularly easy and straightforward to set up and utilize for sending Figure 2 The secure transmission mechanism of the requests and responses shown. At some previous stage, sufficient keys and / or other shared secret information may have been exchanged between each user and the trust provider to which they respond to, so that these communication connections can be set up quickly and securely when required. The same applies to communications between trust providers. In this way, the shared secrets referred to here are agnostic to the technology used to establish them. As with PKI (Public Key Infrastructure), it does not matter what encryption (ECC, RSA or other) and algorithm is used. It is reasonable to assume that, for example, institutions may often rely on older encryption technology than the most advanced individual users and private enterprises, so in the most favorable case, the system and method should allow operation with any kind of PK key.

[0121] The above references to a shared secret may advantageously refer to a computational secret between a mathematically linked key pair, resulting from the product of one's own secret key (SK) and the other's public key (PK) according to an algorithm such as ECC or RSA.

[0122] At step 208, the trust provider of the group member receives the Get Group Request 207 and notices that it contains an external VID in addition to the group request token. In other words, the VID in the Get Group Request 207 is not the VID of the trust provider of the group member, but identifies the trust provider of the group owner. Based on the previously established link relationship between the trust providers, the trust provider of the group member is able to forward the Get Group Request to the trust provider of the group owner, such as Figure 2 However, the group member's trust provider uses its own credentials (rather than the group member's credentials) to authenticate the get group request 209 that it forwards to the group owner's trust provider.

[0123] Figure 2 Step 210 in Figure 1 Similar to step 109 in , the cryptographic engine in the device of the group owner's trust provider responds to receiving a get group request 209 via a secure transmission mechanism (for communication between trust providers). The request contains one of the multiple user identifiers (the identifier of the group member) previously received in the add group request 203. The device of the group owner's trust provider responds by sending the previously generated cryptographic product (i.e., the digital cryptographic group) to the trust provider of the group member via the secure transmission mechanism (see Figure 2 211 in step 212).

[0124] The trust provider of the group member does not need to know anything about the Get Group Response 211 it receives. Instead, it is sufficient to replace the authentication mechanism used between the two trust providers with the authentication mechanism used between the trust provider of the group member and the group member. The corresponding forwarded Get Group Response is as follows: Figure 2 After receiving it and decrypting its contents, the user device of the group member is ready to communicate securely with the user device of the group owner, as shown in step 212 of FIG. Figure 2 As shown in step 213.

[0125] One of the significant advantages associated with the above-described methods and apparatus is that the practice of decentralized identifiers, commonly referred to as DIDs, can be applied. In order to establish a trust relationship for digital communications, a trust provider may have different (public) cryptographic keys and sign-in information for users for different purposes. One advantageous result is that controls can be applied at different levels. Another is the possibility of anonymous and / or pseudonymous appearance of group members. Depending on the use case, members of a group may even appear anonymous to each other or operate as pseudonyms, but fully rely on the trust relationship guaranteed by the trust provider. It is also possible that members of the group can identify each other while they remain unidentifiable to non-members.

[0126] Any range or device value given herein may be expanded or altered without losing the effect sought. Unless expressly prohibited, any embodiment may be combined with another embodiment.

[0127] Although the subject matter has been described with language specific to structural features and / or actions, it should be understood that the subject matter defined in the appended claims is not necessarily limited to the specific features or actions described above. Instead, the specific features and actions described above are disclosed as examples of implementing the claims, and other equivalent features and actions are intended to be within the scope of the claims.

[0128] It should be understood that the benefits and advantages described above may relate to one embodiment or may relate to several embodiments. The embodiments are not limited to embodiments that solve any or all of the problems described or embodiments that have any or all of the benefits and advantages described. It will also be understood that reference to "an" item may refer to one or more of these items.

[0129] The steps of the methods described herein may be performed in any suitable order, or simultaneously where appropriate. In addition, individual blocks may be deleted from any method 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 other embodiment described to form further embodiments without losing the effects sought.

[0130] The term "comprising" is used herein to mean including the identified methods, blocks or elements, but such blocks or elements do not comprise an exclusive list and the method or apparatus may contain additional blocks or elements.

[0131] It should be understood that the above description is given as an example only, and various modifications may be made by those skilled in the art. The above description, 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 certain degree of particularity or with reference to one or more separate embodiments, those skilled in the art may make various changes to the disclosed embodiments without departing from the spirit or scope of this specification.

Claims

1. A device for establishing a digital password group, the device include: a cryptographic engine configured to generate a cryptographic product from given input data; as well as - a receiving end and a sending end of a secure transmission mechanism connected to said cryptographic engine, wherein the cryptographic engine is configured to respond to receiving a first request including a plurality of user identifiers via the secure transmission mechanism by generating a cryptographic product, and wherein the cryptographic engine is configured to respond to receiving via the secure transmission mechanism a subsequent second request including one of the plurality of user identifiers by sending via the secure transmission mechanism the cryptographic product, The password product is a digital password group including the multiple user identifiers and at least one of the following items: - a common cryptographic key used in symmetric cryptography between users identified by said plurality of user identifiers, - a user-specific and user-identifier-dependent public key used in asymmetric cryptography in communications between users identified by said plurality of user identifiers.

2. The device according to claim 1, in, - the apparatus is configured to check whether the first request contains a respective user-specific encryption key for each of the plurality of user identifiers, and - the apparatus is configured to respond to a finding that the first request does not include a respective user-specific encryption key for each of the plurality of user identifiers by augmenting the data received in the first request to include a respective user-specific encryption key for each of the plurality of user identifiers.

3. The device according to claim 2, in, The apparatus is configured to perform the augmenting by requesting and receiving a corresponding user-specific encryption key from a source external to the apparatus.

4. The device according to any one of the preceding claims, in, The apparatus is configured to check a piece of user-related information received in the first request against a corresponding piece of user-related information from another source to find out whether the pieces of user-related information match each other.

5. The device according to claim 4, in, The apparatus is configured to respond to a finding that the pieces of user-related information do not match one another by making a decision as to whether to allow establishment of the numeric password suite to proceed.

6. The device according to any one of the preceding claims, in, The device is configured to digitally sign information elements included by the device in the cryptographic group using a signing key.

7. The device according to any one of the preceding claims, in, The apparatus is configured to check from the subsequent second request whether the request is addressed to the apparatus itself or to another recipient, and to respond to the finding that the request is addressed to the other recipient by forwarding the subsequent second request to the other recipient.

8. The device according to claim 7, in, The device is configured to replace the original authentication of the subsequent second request with the device's own authentication before the forwarding.

9. A method for establishing a digital password group, the method include: - receiving, via a secure transmission mechanism, a first request including a plurality of user identifiers; - generating a cryptographic product in response to receiving said first request; - receiving, via the secure transmission mechanism, a subsequent second request comprising one of the plurality of user identifiers; as well as - in response to receiving said second request, sending said cryptographic product via said secure transmission mechanism, The password product is a digital password group including the multiple user identifiers and at least one of the following items: - a common cryptographic key used in symmetric cryptography between users identified by said plurality of user identifiers, - a user-specific and user-identifier-dependent public key used in asymmetric cryptography in communications between users identified by said plurality of user identifiers.

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

11. The method according to claim 9 or 10, wherein include: - When generating the cryptographic group, digitally signing the information elements included in the cryptographic group using the signing key.

12. The method according to any one of claims 9 to 11, wherein the method include: - checking from said subsequent second request whether said request is directed to the device executing said method or to another recipient; as well as - responding to a finding that the request is intended for another recipient by forwarding the subsequent second request to the other recipient.

13. The method according to claim 12, wherein include: - before said forwarding, replacing the original authentication of said subsequent second request with the authentication of said device executing said method.

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

Images