Method and apparatus for enabling secure digital communication between groups

Abstract

An apparatus for establishing a digital password group comprises a password engine configured to produce a password product from given input data. The password engine responds to receiving a request (101) comprising a user identifier via a secure transmission mechanism by producing a password product. 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 password product (110) via the secure transmission mechanism. The password product is a digital password group comprising the plurality of user identifiers, and a common password key for use in symmetric cryptography between users identified by the plurality of user identifiers and / or a user-specific and user-identifier-dependent public key for use in asymmetric cryptography in communications between users identified by the plurality of user identifiers.

Description

Technical Field

[0001] This invention generally relates to the field of security technology required for the use of digital services between groups of two or more parties. In particular, this invention relates to the task of centrally establishing trust between parties that can subsequently rely on the centrally established trust in other types of group-related use of group communications or digital services. Background Technology

[0002] Security in digital communication involves multiple aspects, such as confidentiality (only authorized parties can access a message), authentication (communicating parties must be certain of who they are communicating with), integrity (a message cannot be modified without permission), and non-repudiation (a party cannot successfully deny sending a message). A subgenus of digital communication is group communication, i.e., digital communication and / or the use of other digital services among members of a predefined group. Group members should have as easy and reliable access as possible to group-specific communications, while ensuring that parties outside the group cannot access or otherwise interfere with the communications. Due to its inherent reliance on cryptographic applications, any type of group referred to here can be called a digital cryptographic group.

[0003] At least two basic methods for group communication are known. In a centralized solution, all communication between group members is routed through a server or similar centralized service point. In this case, the server bears considerable responsibility for authenticating participants and performing the necessary encryption and decryption operations. The other approach is a distributed solution, where communication can occur directly between members. Distributed solutions require user devices to have access to certain shared secrets to provide the desired security.

[0004] Centralized solutions suffer from at least the following drawbacks: they rely entirely on continuous access to the server by 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 problematic in distributed solutions. For example, in the known Diffie-Hellman method, the parties must agree on the order in which the public key is processed so that they can compute the shared secret common to the group. Furthermore, many known distributed solutions are inefficient in establishing sufficient levels of trust among the parties, which can make such solutions vulnerable to malicious attacks. Other drawbacks of many distributed solutions relate to their dependence on specific technologies when using established digital cryptographic sets. It would be better if the digital cryptographic set were technology-agnostic, i.e., not dependent on any specific technology related to how the group's owners and members plan to use it in the future.

[0005] Prior art document US2019 / 0305940 A1 discloses a method in which, upon receiving a group credential request from a second user, the credential system checks the validity of the request using the public key of the first user before responding to the request by sending the group credential.

[0006] Another prior art document, US2015 / 0195261 A1, discloses a method in which a network node can create and join secure sessions for members of a group of network nodes.

[0007] Another prior art document, US2010 / 0329463 A1, discloses a method for group key management in mobile ad hoc networks. Summary of the Invention

[0008] This summary is provided to introduce, in a simplified form, some concepts that will be further described in the detailed description below. This summary is not intended to identify key or essential features of the claimed subject matter, nor is it intended to limit the scope of the claimed subject matter.

[0009] The aim is to provide methods and apparatus for establishing, utilizing, and implementing digital cryptographic blocks without the disadvantages of the aforementioned prior art.

[0010] According to a first aspect, an apparatus for establishing a digital cryptographic group is provided. The apparatus includes: a cryptographic engine configured to generate a cryptographic product from given input data; and a receiver and a transmitter coupled to a secure transmission mechanism of the cryptographic engine. The cryptographic engine is configured to respond to a first request received via the secure transmission mechanism containing a plurality of user identifiers by generating the cryptographic product. The cryptographic engine is configured to respond to a subsequent second request received via the secure transmission mechanism containing one of the plurality of user identifiers by transmitting the cryptographic product via the secure transmission mechanism. The cryptographic product is a digital cryptographic group containing 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-related public key used in asymmetric cryptography in communication between users identified by the plurality of user identifiers.

[0011] According to one implementation, the device is configured to check whether the first request contains a corresponding user-specific encryption key for each of the plurality of user identifiers. The device can then be configured to respond to the discovery that the first request does not contain a corresponding user-specific encryption key for each of the plurality of user identifiers by expanding the data received in the first request to include the corresponding user-specific encryption key for each of the plurality of user identifiers. This involves at least the advantage that the device can flexibly adapt to situations where not all user-specific encryption keys are included in the first request.

[0012] According to one implementation, the device is configured to perform the augmentation by requesting and receiving a corresponding user-specific encryption key from a source outside the device. This provides at least the advantage that the device can operate flexibly and adapt to situations where it does not possess the missing user-specific encryption key.

[0013] According to one embodiment, the device is configured to examine a piece of user-related information received in a first request against a corresponding piece of user-related information from another source to determine whether these pieces of user-related information match each other. This provides at least the advantage of being able to detect and respond to deceptive or otherwise inappropriate use of user-related information.

[0014] According to one implementation, the device is configured to respond to the discovery of mismatches between multiple pieces of user-related information by making a decision on whether to allow the continued establishment of a digital cryptographic group. This involves at least the following advantages: the operation of the device can flexibly adapt to different kinds of needs regarding how accurate each piece of information must be.

[0015] According to one embodiment, the device is configured to digitally sign information elements included in the cryptographic set using a signing key. This provides at least the following advantage: such information elements can carry special value as trust information when used later.

[0016] According to one implementation, the device is configured to check from the subsequent second request whether the request is destined for itself or for another recipient, and to respond to the discovery that the request is destined for another recipient by forwarding the subsequent second request to the other recipient. This has at least the advantage that the same principle can be followed when operating in an environment where different users can belong to the management domains of different trust providers.

[0017] According to an implementation, the device is configured to replace the original authentication of the subsequent second request with the device's own authentication before the forwarding. This provides at least the following advantage: the trust relationship between the parties can be properly maintained and used even when information is further forwarded.

[0018] According to a second aspect, a method for establishing a digital cryptographic set is provided. The method includes: receiving a first request containing a plurality of user identifiers via a secure transmission agency, and, in response, generating a cryptographic product. The method further includes: receiving a subsequent second request containing one of the plurality of user identifiers via the secure transmission agency, and, in response, sending the cryptographic product via the secure transmission agency. The cryptographic product is a digital cryptographic set containing 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-related public key used in asymmetric cryptography in communication between users identified by the plurality of user identifiers.

[0019] According to one implementation, the method includes: checking whether the first request contains a corresponding user-specific encryption key for each of the plurality of user identifiers, and responding to the discovery that the first request does not contain a corresponding user-specific encryption key for each of the plurality of user identifiers by expanding the data received in the first request to include the corresponding user-specific encryption key for each of the plurality of user identifiers. This involves at least the following advantage: the method is flexible and applicable to situations where not all user-specific encryption keys are included in the first request.

[0020] According to one implementation, the method includes: digitally signing information elements included in the cipher set using a signature key while generating the cipher set. This has at least the following advantages: the method is operable and flexible enough to adapt to situations where the device performing the method itself does not possess the missing user-specific encryption key.

[0021] According to one implementation, the method includes checking whether the subsequent second request is destined for the device performing the method or for another recipient, and responding to the discovery that the request is destined for another recipient by forwarding the subsequent second request to the other recipient. This involves at least the following advantage: the same principle can be followed when operating in an environment where different users can belong to the management domains of different trust providers.

[0022] According to an implementation, the method includes replacing the original authentication of the subsequent second request with the authentication of the device performing the method prior to the forwarding. This provides at least the following advantage: the trust relationship between the parties can be properly maintained and used even when information is further forwarded.

[0023] According to a third aspect, a computer program product is provided comprising one or more sets of one or more machine-executable instructions, said one or more machine-executable instructions being configured to cause said one or more processors to perform a method of the type described above when executed by said one or more processors. Attached Figure Description

[0024] In the attached diagram:

[0025] Figure 1 The information exchange during operation according to the implementation method is illustrated, and

[0026] Figure 2 An example of information exchange during operation according to the implementation method is shown. Detailed Implementation

[0027] In the following description, reference is made to the accompanying drawings, which form a part of this disclosure, and specific aspects in which this disclosure may be situated are illustrated by way of illustration. 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 invention. Therefore, the following detailed description should not be considered limiting, as the scope of this disclosure is defined by the appended claims.

[0028] For example, it should be understood that the disclosure relating to the described method also applies to the corresponding device or system configured to perform the method, and vice versa. For example, if specific method steps are described, the corresponding device may include units for performing the described method steps, even if such units are not explicitly described or shown in the drawings. On the other hand, for example, if a particular apparatus 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. Furthermore, it should be understood that features of the various exemplary aspects described herein can be combined with each other unless otherwise specifically indicated.

[0029] An example of a digital cryptographic group is a group of at least two users, who are individuals, for example (but not necessarily), who wish to securely share digitally transmitted information with each other, i.e., such that each member of the group can trust the other to be the person they claim to be, and such that parties who 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.

[0030] Another example of utilizing digital cryptographic groups is one where the aim is to enable a single user to securely possess digital attributes and present them for inspection when needed. For instance, a national agency responsible for granting driver's licenses could set up and manage such groups for each valid driver's license holder. A police officer could be a member of such a group (preferably a temporary member), in which case the officer would have access to secure digital communication with the user's digital wallet. The user's permission to drive a specific type of vehicle could be stored as an attribute, which the user's digital wallet could then present to the police for inspection. As another example, the group owner could be a business entity, while members could be a user with a loyalty card and his or her family members, who in existing systems would appear as owners of subordinate cards associated with the primary user.

[0031] In the general definition used in this article, the owner or creator of a cryptographic group is not necessarily a member of that group, despite having the aforementioned role of owner or creator. This can be visualized using the concepts of read and write permissions. Members of a cryptographic group always have read permissions; in other words, they can continuously access the attributes stored for the group as long as they remain members. While the owner has write permissions, i.e., the right to decide what attributes will be stored for the group, the owner does not necessarily have subsequent access to the stored attributes or communication between members after the group is set up. However, in many cases, it is most practical that the owner also becomes a member of the group.

[0032] Members of a digital cryptographic group can be users, but in at least some cases, they can also be organizations and / or devices. When members are users, they are typically referred to as members of the group (also known as the group owner themselves), even though, strictly speaking, the parties involved in actual digital communication are electronic devices operated by the users and the group owner. Such electronic devices can be, for example, computers, laptops, tablets, smartphones, portable digital assistants, or other electronic devices that include the necessary processing and communication means. In some cases, a user's programmable, implantable electronic device can act as such an electronic device.

[0033] All references to a single device imply a group 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 users have already linked together. Employing the concept of Self-Sovereign Identity (SSI) means that users have cryptographically established control over information generated within the group, including permissions such as administrative and processing rights. Cryptographically established control differs from permissions based solely on certain storage permissions bound to a specific user ID: it means that the user possesses the necessary cryptographic elements to read and / or write appropriate information. The purpose of establishing cryptographic groups is to provide group members with these necessary cryptographic elements.

[0034] Figure 1 This illustration depicts some communications between the trust provider, the group owner, and one or more group members, as well as some operations performed by the trust provider, the group owner, and one or more group members, when the method according to the implementation method is executed. The trust provider may also be referred to as a vault, emphasizing the assumption that it represents an institution with a very high level of digital security. Similar names that can also be used for trust providers are wallet providers and the abbreviations CA and / or VA (Certification Authority, Validation Authority). The trust provider may operate privately, or it may belong to an institution and / or operate under the supervision of an institution.

[0035] To begin setting up a group, the group owner should have at least some means of 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. Regarding new members to be added later, it should be noted that adding a new member to a previously existing group may mean that the new member will also gain access to information processed in the group before the new member was added. Access to previously processed information can be prevented by encrypting it separately within the group, or by encrypting it using a key exchanged between existing members in the group (e.g., a so-called PGP key, where existing members may have distributed their public keys to each other while keeping their own secret keys). Another possibility is to encrypt the old information only once with a key known to the existing members, and encrypt said key separately for each existing member. This last possibility is probably the most cost-effective, as the amount of information shared within the group does not grow proportionally with the number of members; each existing member only needs to securely store their own key for encrypted information within the group. If the new member absolutely does not need (or should not) access information processed earlier, it is more straightforward to set up a new group to which the new member belongs. Existing group members can then be removed from the group; this typically requires updating at least some of the keys used for securely handling information related to the group.

[0036] Figure 1 Step 101 is illustrated schematically, where users transmit to the group owner the identifiers they wish to be known within the group. However, it should be noted that how and when the group owner obtains the member IDs or other identifiers of group members is irrelevant for the purposes described below. If the group owner maintains, for example, a contact information directory, an official register of population information, or a customer database, it can read the identifiers of 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 is generally referred to as a UID. i .

[0037] In step 101 (or any other preceding step), the group owner can also obtain the corresponding public key from each member of the group to be set up, which constitutes half of the user-specific key pair of the asymmetric cryptographic system. However, this is not necessary, as the group members' public keys may come into play later, as described later in this document. The public key of the i-th member in the group can be called PK. UIDi .

[0038] In step 102, the group owner drafts an AddGroup request, i.e., a request to set up a digital password group. The AddGroup request will be directed to the trust provider, and it should contain at least the identifiers of the group members and one or more attributes intended for future use by the group members. As an example of an attribute, consider one referred to as P. G0 A pre-shared key (PSK). This PSK can mean a secret shared among group members, such as an encryption and decryption key used in symmetric encryption methods. The PSK and / or other attributes will be handled as part of a data structure called the Keystore Group Archive, abbreviated as KGA. According to the formal naming, it exists as follows:

[0039] KGA(P G0 ,…)

[0040] The three periods indicate that the KGA can also contain other attributes, such as the identifier UID of the group member. i and / or (at least some) group members' public key PK UIDi If we were to explicitly list these, the formal naming could be:

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

[0042] Examples of other possible attributes in the KGA include, but are not limited to: the name and / or other identifier of the cipher set, a timestamp indicating, for example, when the cipher set was created and modified, expiration data indicating how long the cipher set should remain valid, an identifier of the trust provider to which the request will be directed, and metadata relating to any aspect of the cipher set.

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

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

[0045] Here, SHA2() indicates that the parameter in parentheses is subjected to Secure Hash Algorithm 2, and X25519() indicates that the parameter in parentheses is subjected to the Curve 25519 elliptic curve Diffie-Hellman method. The letter 'n' represents a password random number, such as a 12-bit unique random number. The double vertical bar || indicates a bitwise logical OR operation. Key PK VID and PK UID These are trust providers (PK) VID ) and group owner (PK) UID The public key of ).

[0046] Encryption of a 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:

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

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

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

[0050] The letter 'm' represents the MAC or message authentication code used for the encryption authentication tag.

[0051] Furthermore, it is advantageous to include step 102 in generating a pair of temporary keys for an asymmetric cryptographic method. These temporary keys are referred to herein as PK. GRT and SK GRT In this context, PK represents the public key, SK represents the secret key, and the subscript GRT comes from the 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 This is used to encrypt the final response, 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 holds any of these keys will rarely use them.

[0052] The completed group addition request is sent from the group owner to the trust provider, such as... Figure 1 As shown in step 103. Figure 1 The naming of the add-group and all other specific names in the text are merely illustrative and should not be construed as limitations in any sense; naturally, some other names may be used for this message. Nor does it have to be that all the information described here is transmitted in a single message, but rather multiple transmissions can be used over a public communication channel or even multiple channels. Using the notation described above, the add-group request in step 103 may at least include a temporary public key PK. GRT And encrypted KGA.

[0053] In step 103, it is most advantageous to use a secure transmission mechanism to transmit the add group request from the group owner to the trust provider. 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 receiver and a transmitter of such a secure transmission mechanism coupled to a cryptographic engine capable of performing cryptographic operations. Reception and transmission via the secure transmission mechanism do not necessarily pass through the same or similar channels or connections, although this is not excluded.

[0054] Figure 1 Step 104 can typically be characterized by the trust provider setting up the requested digital cryptographic group and storing it as a data structure, which can later be transmitted to the group members upon request. Step 104 is further characterized in that the cryptographic engine in the trust provider's device responds to the receipt via the secure transmission mechanism of a cryptographic product containing multiple user identifiers (UIDs). iThe first request (i.e., Add Group Request 103). Here, the term "cryptographic product" refers to a digital cryptographic set that contains at least the user identifiers of the group members and one or more keys used to enable secure communication between group members. The digital cryptographic set may also contain various other information, as will be described in more detail later in this document.

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

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

[0057] And use the regenerated key to decrypt the KGA.

[0058] As noted above, when constructing Add Group Request 103, the group owner does not need to possess the user-specific (public) encryption keys for all (or even any) group members. Therefore, it is advantageous, as part of step 104, to configure the trust provider's means to check whether the received Add Group Request 103 contains a corresponding user-specific encryption key for each user identifier. If not, the trust provider's means can be configured to augment the data received in the first request to include a corresponding user-specific encryption key for each of the plurality of user identifiers.

[0059] 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 trust provider's device can be configured to perform the extension by requesting and receiving the corresponding user-specific encryption key from a source outside the device. As an example, a scenario can be considered where two or more trust providers are linked to each other. Each such trust provider has its own previously known user database: the trust providers could be, for example, different entities with which some users have previously communicated, and / or different businesses each with their own customer databases. User-specific encryption keys (especially public keys) can be routinely stored in such a database, each such stored encryption key having an explicit relationship with a corresponding user identifier of a similar type used in the add-group request. The trust provider's device can send a request to one or more such linked trust providers and, in response, obtain the requested user-specific encryption key.

[0060] A similar principle applies to other data to be included in the cipher set: the trust provider's apparatus can augment the contents of the cipher set by generating any missing information elements (either by itself, by requesting from other linked sources, or by both). If necessary, the trust provider's apparatus performs any such augmentation according to predefined specifications governing the creation and processing of cipher sets.

[0061] The trust provider's apparatus can be configured to examine any piece of information (e.g., user-related information) received in the add group request 103 against a corresponding (user-related) piece of information from another source. If performed, the purpose of this examination is to determine 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 trust provider's apparatus can compare these with its own database, or if not found in its own database, it can request them again from other potentially linked trust providers, as in the case of requesting user-specific encryption keys described above.

[0062] Each user (or other party eligible for membership in the group) may be assumed to "belong" to a certain trust provider, or be initially securely identified by a trust provider. The trust provider whose device receives the Add Group Request 103 may not be the trust provider that initially securely identified all those users to be included as new group members. In other words, the Add Group Request 103 may contain the UIDs of one or more expected members of the group who "belong" to one or more different trust providers, rather than the trust provider whose device received the Add Group Request. In this case, one possibility is that the trust provider's device simply leaves an empty space, and if one of its "own" users has a problem, it will use a user-specific encryption key in that space. This practice of leaving the user-specific encryption key of "outside" users empty may have some further consequences described later herein.

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

[0064] As noted above, in addition to user identifiers, a digital cryptographic group should contain one or more keys upon completion to enable secure communication between group members. User-specific (public) encryption keys can satisfy this requirement because it can be assumed that each user has 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 It is typically defined as a public encryption key used in symmetric encryption between users identified by user identifiers. If the group owner has already generated P G0 In this case, the trust provider's device can simply read the decrypted KGA and store it as part of a digital cryptographic set. Alternatively, the trust provider's device can generate such a PSK and store it as part of a digital cryptographic set.

[0065] P G0 Or other PSKs are examples of attributes (or information elements) included in a cipher group that group members must subsequently be able to fully rely on. To provide this security, it is advantageous for the group owner (if the group owner has already generated the PSK) to be responsible for it. G0 ) and / or by the trusted provider's device for P G0 Alternatively, a PSK can be used for digital signing. Based on known principles, the signer uses its secret signing key to digitally sign, allowing other parties to later verify the integrity of the information element in question using the signer's corresponding public verification key.

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

[0067] SK GAT =RNG(256)

[0068] The operator RNG() generates a random binary number with the same number of digits as the (decimal) number in parentheses. Then, the corresponding public key PK... GAT It can be, for example, from scalarbasemult(SK GAT The public key is used to generate the secret key. Here, `scalarbasemult()` is a function based on elliptic curves (e.g., Curve 25519) that deterministically returns the corresponding public key when given a secret key as input. The name of the function may vary 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 / . This can also be done whenever a pair of secret and public keys needs to be generated, using an appropriate single function that takes both keys as output.

[0069] The trust provider's device can be configured to encrypt the created or updated KGA in a slightly different manner depending on whether the digital cipher group is created before sending a response to the group owner in step 104 (or updated before communicating with any other group member) or whether the encryption is performed in connection with communication with group members other than the group owner. See [link to relevant documentation]. Figure 1 Step 109 in the process. 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 processing such a key is described in co-pending patent application number EP22157019.5, which is not published as of the date of this filing. The key in question is referred to as SK in the method described therein. UAT The subscript UAT comes from the user access token. Encrypting the newly created KGA may involve generating a shared secret SS. GAK for:

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

[0071] Here, the subscript GAK comes from the group archive key. The function scalarmult() is based on elliptic curves (e.g., Curve 25519) and returns the computationally shared secret between the two parties, allowing for security based on mathematically linked key pairs without sending the actual key. The newly created KGA can then be encrypted as:

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

[0073] The three periods usually indicate that all information is included in the KGA. However, if the situation is an update previously used with SS... GAK As part of a key-encrypted KGA, an update operation can be described as follows before communicating with any group member other than the group owner:

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

[0075] After that, new encryption can be performed in a similar manner to the above.

[0076] If encryption is performed as part of step 109, then communication with group members other than the group owner can be achieved by utilizing the secret GAT key SK described earlier in this document. GAT To gain additional security.

[0077] In this case, the shared secret SSGAK It can be obtained as:

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

[0079] The subscript GAK comes from the group archive key. Then, the KGA can be encrypted as...

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

[0081] In this way, SS can be used GAK The encrypted form stores the KGA on the trust provider's device, with the aim of always requiring a key from a source outside the trust provider to decrypt the stored KGA. Therefore, even if security at the trust provider's location is compromised and the stored KGA is exposed, they are of little use to attackers because even the trust provider cannot access their encrypted contents without the key components that must come from the group owner or other group members.

[0082] 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) can be described, for example:

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

[0084] Among them, P G0 It is the group's PSK, UID i The PK is a list of group members (including the group owner) whose identifiers are used to identify them. UIDi The group members are identified by a (public) user-specific encryption key, a PID or provider ID (a public identifier of the trusted provider), a GID or group ID (a public identifier of the group), and a GMD or group metadata tag, which identifies all possible metadata associated with the group. The group owner's identifier and / or public key can be selected to allow it or them to be associated with the UID. i and PK UIDi Distinguish the rest of the text.

[0085] To enhance the trustworthiness of attributes within a cipher group, it is advantageous to configure the trust provider's device to digitally sign the information elements included in the cipher group using its own signing key. This allows all members of the group to later ensure that the attributes read from the cipher group are correct, i.e., that their originality and integrity have not been compromised.

[0086] The trusted provider's device will add the group response and send it to the group owner as follows: Figure 1 As shown in step 105. Similar to the earlier add group transmission in step 103, the trusted 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:

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

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

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

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

[0091] Step 106 indicates that the group owner instructs group members to contact the trust provider and download the KGA from the trust provider's device. An advantageous way to enable 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, in step 106, the group owner may send additional information about the group to group members.

[0092] Figure 1 The remaining steps shown are illustrated only with respect to one group member for clarity. Similar steps should be performed for all group members to make the group fully operational. However, even if one or more group members fail to complete their parts, those who have completed the corresponding steps may have already utilized the group. It can be noted here that certain advantages can be gained by using a trust provider as a secure storage location for the group-related information elements, even if only one member of the group will actually perform these steps and use the cryptographic group in the future.

[0093] Step 107 indicates that a group member drafts a request to obtain necessary information about the group, and step 108 indicates that the group member sends the request (here referred to as the GetGroup request) to the trust provider. The sending in step 108 is similar to the sending in the earlier step 103 because it can utilize a secure transport mechanism, such as a digital communication channel where the TLS (Transport Layer Security) protocol can be used.

[0094] The Acquire Group Request 108 should allow the trust provider to ensure that the sender (i.e., the group member) is one of those senders who are permitted to receive the KGA required for group member operations. Advantageously, the Acquire Group Request 108 therefore includes at least a user identifier UID, which the trust provider can then compare with the user identifier UID previously received from the group owner. i The list is compared. An advantageous way to make the Get Group Request 108 include a User Identifier (UID) is to include 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 aforementioned purposes and use the public key to protect the KGA, which will be sent as a response to the requester.

[0095] Additionally, the Group Request 108 advantageously includes a Group Request token, i.e., the temporary public key PK. GRT Other possible information elements that a request to retrieve a group may include (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 the group owner's identifier, various types of signed or unsigned attributes, and / or any metadata related to the group.

[0096] Figure 1 Step 109 typically indicates that the trust provider's device is configured to perform all checks in response to receiving the Acquire Group Request 108. Essentially, the cryptographic engine in the trust provider's device is configured to respond to receiving the Acquire Group Request 108 (which includes one of the multiple user identifiers previously received in the Acquire Group Request 103) via the secure transmission mechanism by sending the previously generated cryptographic product (i.e., the digital cipher set) via the secure transmission mechanism.

[0097] Given that the KGA was previously stored in encrypted form on the trusted provider's device, that device can first regenerate the key SS required for decryption. GAK for

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

[0099] And then perform decryption.

[0100] Dec(SS GAK ,KGA(...)).

[0101] The device can then re-encrypt the KGA (this time for sending to the requesting group member) by providing...

[0102] n = RNG(96)

[0103] As a random number, and provide

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

[0105] As an encryption key (using the specific user's PK) UID (If a certificate is received in the GET request, it is read from the certificate), and then encrypted:

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

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

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

[0109] From a security perspective, it is particularly advantageous to require that the aforementioned certificate always originate from the requester, because in step 109 (and later in...) Figure 2 In step 210), the keystore group file is secure to the user relative to the user's public key PKUID. The certificate can appear in the acquisition group request as described above, but it can also be made known to the trust provider's device through other PKI-based solutions, such as the method described in the co-pending European patent application EP22157019.5 of the same applicant. Additionally or alternatively, if a suitable smart ID, passport, or corresponding document exists, the trust provider's device can read the certificate from it as an RSA or ECC certificate according to specification X.509.

[0110] Similarly, from a security perspective, it is highly advantageous to require the certificate to be signed by a trusted provider's device, or, in the case of several interconnected trusted providers, by a device of one of these interconnected trusted providers. Any party receiving the certificate can then verify its integrity and authenticity, and determine that it was signed by a trusted party (i.e., by the trusted provider or one of the interconnected trusted providers). This, in turn, proves that the public key contained in the certificate can be reliable.

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

[0112] Figure 1 Step 110 in the process indicates that the trusted provider's device sends the encrypted KGA to the group members who requested the encryption. This sending occurs in... Figure 1 The response is marked as a "Get Group" to emphasize its association with the previous "Get Group" request 108. Similar to the earlier named "Add Group," the named "Get Group" is naturally just one example, and other names can also be used.

[0113] As an application Figure 1 An example of the type of method shown can be considered in a scenario where a routine patrolling police officer stops a citizen and wants to check the citizen's permission to drive a particular type of vehicle. The national agency responsible for granting driver's licenses can act as the group owner. Previously, when granting a currently valid driver's license, the agency may have already formed a digital cryptographic group, where it is the group owner and the citizen is a member. When forming this group, the agency can transmit the permitted vehicle types as attributes to a trust provider and request the trust provider to digitally sign these attributes. When the citizen subsequently joins the group by sending a corresponding Acquire Group request, the digitally signed attributes are stored in a "digital wallet," i.e., a dedicated storage location on the citizen's user device. The attributes can remain valid for as long as the underlying document (in this example: the driver's license).

[0114] After obtaining the (public) user identifier from the citizen, the officer can send a request to the agency, providing their own user ID (and possibly a public key), and also adding the citizen's user identifier as an attribute to the request. The agency can then send a group add request to the trust provider, essentially requesting the officer to temporarily join a pre-established digital cipher group with the authority to receive the attribute "permitted vehicle types" from the citizen. Alternatively, the officer (or, as part of the agency's police force, with corresponding derived permissions when an individual officer is on duty) could already be a (permanent or at least long-term) member of this group to allow for offline checks of citizens' driver's licenses.

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

[0116] Once an officer becomes a member of the digital cipher group, the user devices of both the citizen and the officer can access local communications, where the citizen's user device presents the previously acquired, digitally signed attribute "permitted vehicle type" to the officer's user device. Due to the digital signature, the latter is able to verify that the presented attribute is valid. When all checks are complete, the officer's user device can be removed from the digital cipher group via a round of communications similar to when it was added, or its membership in the digital cipher group can simply rely on the previously mentioned time information to allow the officer's membership to expire. Alternatively, permanent or at least long-term membership may exist for the officer within the group.

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

[0118] Figure 2 This illustration depicts some communication between two trust providers, a group owner, and group members, as well as some operations performed by these two trust providers, group owner, and group members when the method according to this embodiment is executed. As background to this embodiment, the assumption that each user can "belong" to a trust provider of their choice can be recalled. In this example, the two vertical lines in the middle represent the devices of the trust providers, while the two vertical lines on the right and left respectively represent the group owner and group members. For illustrative purposes, Figure 2 The example shown can be considered to involve a real-world use case where a group owner wants to set up protected phone calls with group members.

[0119] Figure 2 Step 201 and Figure 1 Similar to step 101, the group owner should obtain the group members' identifiers in one way or another. This step may even have occurred much earlier, for example, typically when users store each other's phone numbers on their user devices.

[0120] Step 202 can also be combined with Figure 1 Similar to step 102 in the previous example, it indicates that the group owner's user equipment performs steps aimed at setting up protected calls, i.e., creating a password group in which protected calls can occur. The written request is shown as step 203 and named Add Group Request, which is very similar to... Figure 1 Step 103. The group owner sends the Add Group Request 203 to its "own" trusted provider. Most advantageously, the Add Group Request 203 contains an encrypted KGA (Keystore Group Archive) and a group request token PK. GRT The KGA contains a pre-shared key (referred to as PSK or P in this document). G0 ) and the identifiers (UIDs) of the group members to whom the protected calls should be made (and possibly the public key PK). UID ).

[0121] Step 204 in Figure 4 can be compared with... Figure 1 Similar to step 104 in Figure 5, it indicates that the trust provider (the one to which the group owner "belongs") sets up the requested cipher group and stores 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 the add group request 203, which receives the request via a secure transmission mechanism and contains multiple user identifiers (UIDs of the group owner and group members), by producing a cryptographic product (i.e., by creating the requested cipher group). Step 205 is the add group response sent back to the group owner by the trust provider's device, again very similar to step 105 in Figure 5.

[0122] In step 206, the group owner's user equipment sends at least a group request token (PK) to the user equipment of the group members. GRT And the trust provider identifier VID of the group owner. Although in Figure 2While not explicitly shown as a separate step, the group member's user device uses this information to draft a request to obtain the cipher group (the encrypted KGA). However, because the group member belongs to a different trust provider than the group owner, the obtain group request in step 207 is not sent to the trust provider currently holding the stored data of the cipher group. Instead, the group member's user device sends obtain group request 207 to its own trust provider.

[0123] The pre-existing relationship between users and their trusted providers means that their corresponding devices and apparatuses are particularly easy and direct to set up and utilize for sending... Figure 2 The secure transmission mechanism for requests and responses is illustrated. At some earlier stage, sufficient keys and / or other shared secret information may have been exchanged between each user and their trusted provider to enable the quick and secure establishment of these communication connections when needed. The same applies to communication between trusted providers. Thus, reliance on the shared secrets referred to herein is agnostic to the technology used to establish them. As with PKI (Public Key Infrastructure), the type of encryption (ECC, RSA, or others) and algorithm used is not critical. It is reasonable to assume, for example, that institutions may frequently rely on encryption technologies older than those used by state-of-the-art individual users and private enterprises; therefore, in the most favorable circumstances, the system and methods should allow operation with any kind of PK key.

[0124] The above reference to a shared secret can advantageously represent the computational secret between mathematically linked key pairs, which comes from the product of one's own secret key (SK) and the other's public key (PK) according to, for example, an ECC or RSA algorithm.

[0125] In step 208, the group member's trust provider 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 group member's trust provider, but rather the VID of the trust provider identifying the group owner. Based on the previously established link between trust providers, the group member's trust provider can forward the Get Group Request to the group owner's trust provider, such as... Figure 2 As shown in step 209. However, the group member's trust provider uses its own credentials (instead of the group member's credentials) to authenticate the Get Group request forwarded to the group owner's trust provider 209.

[0126] Figure 2 Step 210 and Figure 1Similar to step 109, the cryptographic engine in the group owner's trust provider's device responds via a secure transmission mechanism (for communication between trust providers) upon receiving the acquire group request 209. This request includes one of a plurality of user identifiers (the group member's identifier) ​​previously received in the add group request 203. The group owner's trust provider's device responds by sending the previously generated cryptographic product (i.e., the digital cipher set) to the group member's trust provider via the secure transmission mechanism (see [link to relevant documentation]). Figure 2 Step 211 in the middle.

[0127] The trust provider of a group member does not need to know anything about the content of 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 group member's trust provider and the group member. The corresponding forwarded Get Group response is as follows: Figure 2 As shown in step 212. After receiving it and decrypting its contents, the group member's user equipment is ready to communicate securely with the group owner's user equipment, as follows: Figure 2 As shown in step 213.

[0128] One of the significant advantages associated with the aforementioned methods and apparatus is the ability to apply distributed identifiers, commonly known as DIDs. To establish trust relationships for digital communication, the trust provider can have different (public) cryptographic keys and sign-in information for users for different purposes. One advantageous consequence is the ability to apply control at different levels. Another is the possibility of group members appearing anonymous and / or pseudonymous. Depending on the use case, group members may even appear anonymous to each other or operate as pseudonyms, but entirely rely on the trust relationship guaranteed by the trust provider. It is also possible that group members can identify each other while remaining unidentifiable to non-members.

[0129] Any ranges or device values ​​given herein may be extended or modified without losing the desired effect. Unless expressly prohibited, any implementation may be combined with another implementation.

[0130] Although the subject matter has been described using 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. Rather, 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.

[0131] It should be understood that the above benefits and advantages may apply to one implementation or to several implementations. The implementation is not limited to implementations that solve any or all of the described problems or implementations that have any or all of the described benefits and advantages. It will also be understood that a reference to "a" may refer to one or more of these items.

[0132] The steps described herein can be performed in any suitable order, or simultaneously where appropriate. Furthermore, individual boxes can be removed from any method without departing from the spirit and scope of the subject matter described herein. Any aspect of any of the embodiments described above can be combined with aspects of any other described embodiments to form further embodiments without loss of the desired effects.

[0133] The term “comprising” is used herein to mean including the identified method, box, or element, but such box or element does not include an exclusive list, and the method or apparatus may include additional boxes or elements.

[0134] It should be understood that the above description is merely illustrative, and various modifications can be made by those skilled in the art. The above specification, examples, and data provide a complete description of the structure and use of exemplary embodiments. Although various embodiments have been described above with a degree of specificity or by reference to one or more individual embodiments, those skilled in the art can make various changes to the disclosed embodiments without departing from the spirit or scope of this specification.

Claims

1. An apparatus for establishing a digital cryptographic block, the apparatus comprising: A cryptographic engine configured to generate cryptographic products from given input data; as well as The receiving and sending ends of the 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. Furthermore, the cryptographic engine is configured to respond to a subsequent second request received via the secure transmission mechanism containing one of the plurality of user identifiers by sending the cryptographic product via the secure transmission mechanism. The cryptographic product is a set of digital cryptographic elements comprising the plurality of user identifiers and at least one of the following: A shared cryptographic key used in symmetric cryptography among users identified by the plurality of user identifiers. User-specific and user-identifier-related public keys used in asymmetric cryptography in communication between users identified by the plurality of user identifiers.

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

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

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

5. The apparatus according to claim 4, wherein, The device is configured to respond to the discovery that these user-related information items do not match each other by making a decision on whether to allow the continued establishment of the digital cipher group.

6. The apparatus according to any one of claims 1 to 3, wherein, The device is configured to use a signature key to digitally sign the information elements included in the cryptographic set.

7. The apparatus according to any one of claims 1 to 3, wherein, The device is configured to check from the subsequent second request whether the request is destined for the device itself or for another receiver, and to respond to the discovery that the request is destined for the other receiver by forwarding the subsequent second request to the other receiver.

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

9. A method for establishing a digital cipher block, the method comprising: Receive a first request containing multiple user identifiers via a secure transmission mechanism; In response to receiving the first request, a cryptographic product is generated; Receive a subsequent second request containing one of the plurality of user identifiers via the secure transmission mechanism; and In response to receiving the second request, the cryptographic product is sent via the secure transmission mechanism. The cryptographic product is a set of digital cryptographic elements comprising the plurality of user identifiers and at least one of the following: A shared cryptographic key used in symmetric cryptography among users identified by the plurality of user identifiers. User-specific and user-identifier-related public keys used in asymmetric cryptography in communication between users identified by the plurality of user identifiers.

10. The method according to claim 9, wherein the method comprises: Check whether the first request contains a corresponding user-specific encryption key for each of the plurality of user identifiers; as well as The response to the discovery that the first request did not contain a corresponding user-specific encryption key for each of the plurality of user identifiers was to expand the data received in the first request to include a corresponding user-specific encryption key for each of the plurality of user identifiers.

11. The method according to claim 9 or 10, wherein the method comprises: When generating the cryptographic set, the information elements included in the cryptographic set are digitally signed using a signing key.

12. The method according to any one of claims 9 to 10, the method comprising: From the subsequent second request, check whether the request is directed to the device performing the method or to another receiver; as well as The response to the request is the discovery of going to the other recipient by forwarding the subsequent second request to the other recipient.

13. The method according to claim 12, wherein the method comprises: Prior to the forwarding, the original authentication of the subsequent second request is replaced with the authentication of the device performing the method.

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

Images