Authentication in secure group messaging

Abstract

Various methods for authenticating a user device in a group messaging protocol, such as messaging security (MLS), are described. Some methods utilize a public token and a private token, wherein the public token is derivable from the public token using a one-way function. Other methods replace the token with a one-time signature key pair. Yet another method utilizes a group signature scheme to allow traceability of user devices.

Description

TECHNICAL FIELD

[0001] The present invention relates to authentication in secure group messaging. In particular, methods of authenticating a message received from a sender user device in a group messaging protocol at a receiver user device are provided, as well as information processing systems comprising user devices and servers for performing such methods. BACKGROUND

[0002] The IETF Messaging Layer Security (MLS) protocol is the result of an internal collaboration effort within the Internet Engineering Task Force (IETF) and aims to provide a standardized approach to secure group messaging. The MLS protocol aims to provide end-to-end security in dynamic group communication scenarios, thereby helping to protect the privacy and integrity of messages exchanged among participants.

[0003] The MLS operates at the message layer, which means that what the MLS protects are individual messages, not the entire communication channel. The MLS is designed to work in a decentralized manner, adapting to dynamic groups where members can join or leave at any time. This makes the MLS suitable for scenarios where group members are prone to change, such as team collaboration or real-time group messaging.

[0004] The MLS employs a combination of cryptographic techniques to achieve its security goals. The MLS provides forward secrecy and cryptographic freshness of messages using a concept called “Continuous Group Key Agreement (CGKA)”. This means that each message is encrypted using a unique key derived from a chain of keys, ensuring that revealing one key does not reveal past or future messages.

[0005] The MLS is designed to be resistant to various types of attacks. The MLS provides protection against eavesdropping, tampering, message replay, and man-in-the-middle attacks. The protocol also contains mechanisms to detect and handle participant attrition, ensuring that new members can safely join the group and existing members can continue seamless communication.

[0006] While the MLS has undergone extensive research by researchers, most of the research has focused on the confidentiality of the exchanged information. However, there is also the problem that the authenticity of the messages should be checked, i.e. the user should be able to check the received message to find out which user in the group sent the message.

[0007] Within the MLS system, there are several ways to determine which user sent the message. The first method involves a reference Figure 1 will be described. Figure 1is a schematic diagram showing four user devices 1 in a group messaging system. The user devices communicate with each other via a server 2 using the MLS protocol. The MLS protocol is asynchronous such that messages are stored on the server 2 until the user devices 1 retrieve them. Therefore, it is necessary to be able to determine whether a received message was indeed sent by a particular user device. Figure 1 The user 1 shown in the bottom left is depicted as having a pair of keys, including a public key vk1 and a private key sk1. In practice, each user will have their own pair of keys, and the public keys will be centrally published. In the case that the user 1 sends a message m to the other users 1 via the server 2, the user 1 generates a signature Y σ of the message under the user’s private key sk1 using a pre-agreed signature scheme. Since the user 1 has published its public key vk1, the recipients of the message and signature can use the user’s public key and a verification function of the pre-agreed signature scheme to confirm that the signature was generated using the private key sk1. Since the private key sk1 is assumed to be known only to the user 1, the other users can be confident that the message came from the user 1, since only the user 1 could have generated the signature.

[0008] Figure 2 is a schematic diagram of a second method of authenticating messages. The method discussed in relation to Figure 1 has the disadvantage that the server 2 can determine which user is sending each message, since the public key required to verify the signature is publicly available. Preferably, the server 2 serves the function of delivering messages but cannot track which user devices 1 are messaging. In the example shown in relation to Figure 2 , each user device in the group has a group secret key for use in the MLS protocol. According to Figure 2 the method shown, each user within the group derives an authentication key k from the group secret key using a pre-agreed key derivation function. When the user 1 sends a message, the message is signed using a pre-agreed signature scheme to generate a signature Y σ , and then the message and signature are concatenated using the authentication key k and a pre-agreed symmetric encryption scheme to generate a ciphertext C t . The ciphertext C t is sent to the server 2 for distribution to the other members of the group. The server 2, which does not know the group secret key and therefore cannot derive the authentication key k, cannot read the encrypted message and also does not know which user sent the message. A group member receiving the message can decrypt the ciphertext C t using the authentication key k and a decryption function of the pre-agreed symmetric encryption scheme, and subsequently verify the signature as described in relation to the method of Figure 1 . However, this method has the disadvantage that the server 2 also cannot confirm that the user sending the message is a member of the group. Therefore, this method is vulnerable to denial of service attacks.

[0009] Therefore, there is a need to improve the methods used for authenticating users in secure group messaging protocols. Summary of the Invention

[0010] According to a first aspect of the present invention, a method is provided for authenticating a message received from a sending user device at a receiving user device using a group messaging protocol, the method comprising: receiving a public token associated with the sending user device at the receiving user device; storing the public token at the receiving user device; receiving a message and a private token from the sending user device; verifying the private token by comparing the stored public token with a one-way function; and determining that the message has been received from the sending user device if the private token is verified.

[0011] The public token can be received by the receiving user device from the server, and the message and the private token can be received by the receiving user device from the server. The server can receive the message and the private token from the sending user device. The server can perform an additional step, namely, using the one-way function to verify the private token against the stored public token, and then, if the private token is verified, making the message available to a group of user devices including the receiving user device. If the private token is verified, the public token can be obtained by applying the one-way function to the private token.

[0012] The one-way function can be a truncated encrypted function.

[0013] The method may include the sending user device creating the private token as a random number or pseudo-random number. The public token may be generated by the sending user device from the private token using the one-way function. The sending user device may publish the public token. The public token may be published on the server.

[0014] The sending user device may send a new public token along with the message and the private token. The server may receive the new public token and store it for use when receiving subsequent messages.

[0015] According to a further aspect of the application, there can be provided a group messaging system comprising a server and at least two user devices, each of the server and the at least two user devices being an information processing apparatus comprising a processor and a computer readable storage medium storing program instructions causing the information processing apparatus to perform the steps according to the first aspect of the application.

[0016] According to a further aspect of the application, there can be provided a plurality of programs which, when implemented on a group messaging system, cause the group messaging system to perform the method according to the first aspect of the application.

[0017] According to a second aspect of the application, there is provided a method of authenticating a message received from a sender user device in a group messaging protocol at a recipient user device, the method comprising: receiving, at the recipient user device, a first public token associated with the sender user device; storing the first public token at the recipient user device; receiving, at the recipient user device, a first private token and ciphertext, the ciphertext encrypting at least a message from the sender user device; decrypting, by the recipient user device, the ciphertext to obtain the message; verifying, by the recipient user device, the first private token against the stored first public token using a one-way function, wherein the first public token is obtainable by applying the one-way function to the first private token if the first private token is verified; and determining that the message has been received from the sender user device if the first private token is verified, wherein at least one of the first public token and the first private token is received in an encrypted format at the recipient user device.

[0018] The recipient user device can receive the first public token from a server, and the received first public token is encrypted in a previous ciphertext. The recipient user device can receive the ciphertext from the server. The server can receive the first public token, the ciphertext, the first private token and a message authentication code associated with the ciphertext from the sender user device. The message authentication code can be generated by the sender device from the ciphertext using a MAC key associated with a group of users in the group messaging protocol. The server can check the message authentication code using the MAC key, and only make the ciphertext available to the group of user devices if the message authentication code matches the ciphertext.

[0019] The ciphertext can be encrypted by the sender user device and decrypted by the recipient user device using a symmetric encryption key derived from a group secret associated with the group messaging protocol. The symmetric encryption key can be derived by the sender user device from the group secret associated with the group messaging protocol. The recipient user device can derive the symmetric encryption key from the group secret associated with the group messaging protocol.

[0020] The server can not have access to the group key and can not be able to decrypt the ciphertext. The MAC key can be provided to the server by one or more of the user devices that are members of the group of users. The sender user device can derive the MAC key from the group secret associated with the group messaging protocol. The recipient user device can derive the MAC key from the group secret associated with the group messaging protocol.

[0021] The one-way function can be a truncated encryption function. The encryption function can be SHA 256 and the output can be truncated to 16 bits.

[0022] The ciphertext can also encrypt a second public token. The recipient user device can store the second public token for use when receiving subsequent messages from the sender user device after the ciphertext has been decrypted.

[0023] The sender user device can create the private token as a random or pseudo-random number. The sender user device can generate the public token from the private token using the one-way function. The public token can be published by the sender user device. The public token can be published by the sender user device on the server.

[0024] In some examples, the sender user device can generate the first private token as a random or pseudo-random binary string. The sender user device can generate the first public token by applying a one-way function to the first private token. The sender user device can send the first public token to a server that stores public token values.

[0025] In some implementations, the sender user device generates a second private token as a random or pseudo-random binary string. The sender user device can generate a second public token by applying a one-way function to the second private token. The sender user device can generate the ciphertext by encrypting the message. The sender user device can generate the ciphertext by encrypting the message, the private token, and a new public token. The sender user device can generate a message authentication code using a MAC key and the generated ciphertext.

[0026] According to a further aspect of the application, there can be provided a group messaging system comprising a server and at least two user devices, each of the server and the at least two user devices being an information processing apparatus comprising a processor and a computer readable storage medium storing program instructions causing the information processing apparatus to perform the steps according to the second aspect of the application.

[0027] According to a further aspect of the application, there can be provided a plurality of programs which, when implemented on a group messaging system, cause the group messaging system to perform the method according to the second aspect of the application.

[0028] According to a third aspect of the application, there can be provided a method of authenticating a message received from a sender user device in a group messaging protocol at a recipient user device, the method comprising: each user device in a group generating one or more public tokens for each other user device in the group, wherein: each public token is associated with a corresponding private token stored by or generatable by the user device, each private token is usable to send a message to the user device, and the one or more public tokens generated by a user device for each user device in the group form a set of public tokens; each user device uploading its set of public tokens to a server to form an overall set of public tokens on the server; each user device downloading public tokens from the server and storing the overall set of public tokens; each user device in the group providing one or more private tokens associated with the uploaded public tokens for each other user device, or providing information for the other user device to generate the one or more private tokens associated with the uploaded public tokens; receiving at the server a message to be delivered and a private token from a sender user device at the server; verifying the private token by the server using a public token in the overall set of public tokens; making the message to be delivered and the private token available to user devices in a group including the recipient user device in the case that the private token is successfully verified with a public token in the overall set of public tokens at the server; obtaining the message and the private token by the recipient user device from the server; verifying by the recipient device whether the private token is a private token distributed by the recipient device for receiving messages; determining that the message has been received from the sender user device in the case that the private token is verified.

[0029] In some implementations, generating one or more public tokens can include generating one or more private tokens that are random numbers or pseudo-random numbers, and generating the one or more public tokens from the one or more private tokens using a one-way function.

[0030] The one or more private tokens can be generated at the user devices from a plurality of seeds, each seed being associated with a respective user device in the group.

[0031] Each user device in the group can provide a seed to other user devices for use by the other user devices to generate the one or more private tokens associated with the public token that has been uploaded.

[0032] The one-way function can be a truncated cryptographic function applied to the private token.

[0033] In other implementations, each public token is a verification key in a pair of signing keys, and the information from which the private token is generated is information used to generate a signing key in the pairs of signing keys. Generating one or more public tokens can include generating pairs of signing keys and extracting the verification keys from the pairs of signing keys.

[0034] The pairs of signing keys can be generated from a plurality of seeds, each seed being associated with a respective user device in the group. Each user device in the group can provide a seed to other user devices for use by the other user devices to generate the signing key associated with the public token that has been uploaded. Each private token can be a signature of a message sent by a sender user device. The signature can be created using a signing key in the pairs of signing keys.

[0035] The step of each user device in the group providing one or more private keys to other user devices associated with the public key that has been uploaded, or information for the other user devices to generate the one or more private keys associated with the public key that has been uploaded, can include each user generating a ciphertext encrypted under a respective public key of each other user device, whereby the other user devices can obtain the one or more private tokens associated with the public token that has been uploaded or information for the other user devices to generate the one or more private tokens associated with the public token that has been uploaded by decrypting the ciphertext using their private key.

[0036] The server can store the sets of public tokens uploaded by the user devices in a database according to index values. Each user device can upload its set of public tokens to the server with an index value generated at the user device using a permutation function, whereby the server does not know which public tokens in the group are associated with which user devices. The method can comprise the step of each user device deriving a permutation key from a group secret shared among the user devices according to the group messaging protocol. Each user device in the group can generate the index value using the permutation function and the generated permutation key.

[0037] The message can comprise at least one of a group of text, images, sound files and data files.

[0038] According to a further aspect of the application, there can be provided a group messaging system comprising a server and at least two user devices, each of the server and the at least two user devices being an information processing apparatus comprising a processor and a computer readable storage medium storing program instructions causing the information processing apparatus to perform the steps according to the third aspect of the application.

[0039] According to a further aspect of the application, there can be provided a plurality of programs which, when implemented on a group messaging system, cause the group messaging system to perform the method according to the third aspect of the application.

[0040] According to a fourth aspect of the present application, there is provided a method of authenticating a message received from a sender user device in a group messaging protocol at a recipient user device, wherein: a server is configured to handle messages from an overall set of user devices, the user devices in the overall set of user devices are configured to communicate with each other using a group messaging protocol in one or more local groups formed by the overall set of user devices, each user device in a local group of the one or more local groups derives a local group messaging protocol key pair comprising a local group signing key and a local group verification key, each user device in the overall set of user devices is a member of a system group signature scheme, and each user device in each local group of the one or more local groups has a tracker key of the group signature scheme associated with the group derived from a group key of the group messaging protocol, the method comprising: the sender user device generating a system group signature of a message using the group signature scheme, wherein the message is to be sent to a local group of the one or more local groups, and the system group signature is generated using a tracker key associated with the local group; the sender user device generating a private token associated with the message using the local group signing key; the server checking the system group signature using the group signature scheme and checking the private token using the local group verification key of the group messaging protocol key pair; and the server making the message available to the local group only after the system group signature is verified against the message and the private token is verified against the message, wherein the system group signature is usable by a recipient user device within the local group to verify the identity of the sender user device using a tracker function of the group signature scheme.

[0041] The private token can be one of a signature of the message and a message authentication code generated based on the message.

[0042] According to yet another aspect of the present application, there can be provided a group messaging system comprising a server and at least two user devices, each of the server and the at least two user devices being an information processing apparatus comprising a processor and a computer readable storage medium storing program instructions causing the information processing apparatus to perform the steps according to the fourth aspect of the present application.

[0043] According to yet another aspect of the present application, there can be provided a plurality of programs which, when implemented on a group messaging system, cause the group messaging system to perform the method according to the fourth aspect of the present application.

[0044] Further features and advantages of the present application will become apparent from the following description of preferred embodiments of the application given for the purpose of illustration only, with reference to the accompanying drawings. BRIEF DESCRIPTION OF DRAWINGS

[0045] Figure 1 Use of signatures in a group messaging protocol is shown; Figure 2 Use of encryption and signatures in a group messaging protocol is shown; Figure 3 User devices and a server are shown; Figure 4 Message exchange according to a first embodiment is shown; Figures 5A to 5C show an authenticated messaging protocol of the first embodiment; Figure 6 is a schematic diagram showing message exchange according to a second embodiment; Figures 7A to 7C show an authenticated messaging protocol of the second embodiment; Figure 8 is a schematic diagram showing message exchange according to a third embodiment; Figure 9 Private and public tokens stored for use in the third embodiment are shown; Figures 10A to 10D show an authenticated messaging protocol of the third embodiment; Figure 11 is a schematic diagram showing message exchange according to a fourth embodiment; Figures 12A to 12D show an authenticated messaging protocol of the fourth embodiment; and Figure 13 is a schematic diagram showing components of an information processing device. DETAILED DESCRIPTION

[0046] Embodiments allowing authentication of users in a secure group messaging protocol will be described below. The term "user" or "users" is to be understood as a user device (respectively user devices) configured to operate according to a secure group messaging protocol. The user device can be any information processing device such as a portable device or a computer. The user device is configured such that it is operable by a user within a group to send and receive messages within the group G.

[0047] Figure 3 is a schematic diagram showing a server 2 and four users 1. In Figure 3Four users are depicted in the figures described below, and the description applies equally to those figures, but those skilled in the art will appreciate that a group messaging protocol can enable communication between a group of two or more users, and the depiction of four users is purely for ease of illustration. Those skilled in the art will also appreciate that the number of users in a group can vary over time in accordance with the group messaging protocol. Details of the group messaging protocol, such as how to add and remove users from a group, will be described after the embodiments are described. A complete description of the IETF messaging layer protocol is not provided because it is not necessary to understand the present invention, but a description of the protocol is publicly available to the reader. The embodiments can be implemented using the messaging layer protocol (MLS) or other group messaging protocol. In the embodiments of generating a secret from a group, any group messaging protocol that shares a secret among group members can be used.

[0048] First embodiment

[0049] Figure 4 Communication between users according to the first embodiment is shown. In this example, the user devices 1 within the group are configured to communicate with each other using the MLS, but in other embodiments other group messaging protocols can be used. In addition, the user devices 1 are configured with a pre-agreed upon one-way function. Prior to sending messages, each user within the group G generates a token pair (x, y) during initial setup or when the user joins the group G. The private token of the token pair x is created by creating a random or pseudo-random binary string. Any method can be used to generate the binary string. In the first embodiment, the binary string is 128 bits in length. However, in other embodiments binary strings of different lengths can be used. The binary string forms the private token x. For convenience, the private and public tokens will be labeled according to the user, so that xi is the private token value created by user 1, x2 is the private token value created by user 2, and so on.

[0050] Each user device 1 also generates a public token value y by applying the one-way function to the private token x. Various one-way functions are known. However, by way of example, the private token can be encrypted using SHA-256 and then truncated to 16 bits. Each user device 1 sends its public token value y to a server 2 that stores the public token values. In addition, each user device 1 downloads a set of public tokens from the server 2 to allow messages to be authenticated using the public tokens.

[0051] If the user device 1 sends a message m to the group, the user device 1 generates a new token pair x' and y' using the same method as for the creation of the token pair described above. The user sends the concatenation of the message m, the newly created public token value y' and the current private token value x to the server 2. The server 2 can check if the private token value x corresponds to the public token value y uploaded by the user device 1 to the server 2 using the one-way function. If the private token value corresponds to the previously uploaded public token value y, the server 2 removes the public token value y stored at the server 2 and replaces it by the newly created public token value y'. In addition, the server 2 makes the message m and the public token y' available for download by the user devices 1 in the group G. In this way, the server 2 has checked that the message originates from a user within the group G. The token is only used once and is a one-time token. The used public token y is replaced by the new public token y'.

[0052] The other users in the group G can download the message, the private token and the new public token y' from the server 2. To authenticate the message m, the group members, which keep a copy of the set of public tokens y, can also check if the private token x corresponds to the public token y in view of the one-way function. If the check is successful, each receiving user device 1 updates its set of stored public tokens to remove the public token y associated with the received message and replace it by the received new public token y'.

[0053] As described above, each message generates a new public token y' and the used public token is removed to avoid replay attacks in which a third party can resend and intercept a public token in order to authenticate a message.

[0054] It is noted that each user is not limited to create one token pair (x, y). Each user device 1 can generate multiple token pairs and upload several public tokens to the server 2. In this way, the user can send several messages before the server 2 is refilled with associated public tokens.

[0055] The protocol of the first embodiment is illustrated in Figures 5A to 5C.

[0056] The function Init in Figure 5A illustrates the steps performed by each user device 1 in order to initialize the protocol. In steps 1 to 4, an empty list of public tokens and private tokens is prepared for each user in the group. In step 6, T private tokens are generated by each user device 1. These steps are performed using the function gen-auth-token(G, u) as illustrated in Figure 5C.

[0057] The function The gen-auth-token(G, u) generates T private tokens X[t] and T public tokens Y[t] using a one-way function OWF on the private token.

[0058] Returning to the Init function in Fig. 5A, in steps 6 to 9, the private token Xu is stored in the list PrivTOKEN and the public token Y u is stored in the list PubTOKEN. In steps 11 and 12, the total list TOKEN is formed from the private token list and the public token list, and the method generates a user state st u containing the group identifier G and the total list TOKEN u . In steps 14 to 17, the data DB is prepared at the server 2 (referred to as Sv in the protocol figures and other protocol figures) and the public tokens Y u are stored in the database.

[0059] As shown in Fig. 5A, the function Send is used to generate a group authentication token G to send a message m to the user device 1 based on the state st u . As shown, st u contains the group G, a counter ctr and an identifier of the total token list TOKEN u . In step 2, if the counter indicates that the number of messages sent is greater than T-1, then the tokens need to be refreshed at the server 2 and no message can be sent. This is resolved by an update which will be described further below. Otherwise, in step 3, the counter is incremented. In step 4, the function attach-auth-token(st u ) is used to generate a group authentication token G based on the user state st u . As shown in Fig. 5C, attach-auth-token(st u ) takes the user state st u and returns the counter ctr and a private token x u from the private token list PrivTOKEN associated with the counter. The private token forms the group authentication token G .

[0060] Returning to the Send function shown in Fig. 5A, in step 5, the user state is updated to reflect the updated counter ctr'. After the Send function is used, the sending user device 1 sends the message and the group authentication token to the server 2.

[0061] The function Verify is used by the server 2 to verify the received group authentication token Σ against the current state pp of the database DB G . In step 2, the server 2 checks if the group authentication token is valid using the function verify-auth-token (pp, Σ G ). As shown in Figure 5C, the function verify-auth-token (pp, Σ G ) checks the group authentication token against the public tokens in the database DB state using the one-way function OWF. If the check passes, the state of the database pp is updated by removing the corresponding public token from the database. The function returns the updated database state pp' and the download package σ v , which includes the user identifier u, the counter ctr and the private token x received from the sender user device 1.

[0062] The user device 1 executes the function Receive, which downloads the message m and the download package σ v from the server 2. The user device 1 uses the function trace-sender (st u , σ, m) shown in Figure 5C. In steps 1 and 2 of the function trace-sender (st u , σ, m), the user device 1 parses the user state st u to obtain the list of private tokens and the list of public tokens. In steps 4 to 6, the user device 1 compares the received private token with the list of public tokens stored on the user device 1 using the one-way function OWF. If a corresponding public token is found, the user device 1 updates the counter associated with the received private token and removes the corresponding public token. The function trace-sender (st u , σ, m) returns the updated user state st' u , an indication b if the token has been verified, and the identity of the user providing the private token v .

[0063] Referring now to Figure 5B, the function UpdSend performs the update and at the same time generates a token for sending the update. This function can be used when a token needs to be refreshed. In steps 1 to 6, the current state is parsed and a new token is generated using the function gen-auth-token (G, u) as described above. As with the Init function, the newly generated private token is added to the list of tokens PrivTOKEN uand the newly generated public token is added to the token list PubTOKEN u .

[0064] In step 7, the counter ctr is refreshed to 1 and in step 8, the new overall list TOKEN u is used to update the user status at the user device 1 performing the update. The user identifier and the public token Y u are stored as update package . In step 10, the function attach-auth-token(st u ) is used to generate the group authentication token as described previously in connection with the Send function. The UpdSend function returns the updated status of the user with the new token, the group authentication token for the update and the update package of the server 2.

[0065] The function UpdVerify(pp, , ) is shown in Fig. 5B and is executed by the server 2 and uses the function verify-auth-token to verify the group authentication token as described above. The UpdVerify (pp, , ) function also updates the status of the database with the newly received public token. The function UpdVerify(pp, , ) returns the updated database status and the download package σ v at the server 2, the function being the user identifier u, the counter ctr and the private token x. Furthermore, the function UpdVerify (pp, , ) returns the update package , the function being the user identifier and the new public token Y u .

[0066] The function UpdReceive(stu, , ) executed by the receiving user device 1 is similar to the Receive function described above, but the function UpdReceive is used to update the token list PubTOKEN maintained at the user device 1 to contain the new public token downloaded with the message. The function returns the updated user status st' u , sending the identity of the user receiving the update and an indication b whether the private token x has been verified.

[0067] The first embodiment can be useful because it provides a computationally efficient method of authenticating messages in a group messaging protocol. Post-quantum signature schemes tend to be computationally expensive, which can make conventional signature methods such as those described with reference to Figure 1 and 2 described less attractive for some applications. The first embodiment therefore provides a computationally light method for authenticating users.

[0068] The second embodiment

[0069] Figure 6 Message passing according to the second embodiment is illustrated. The first embodiment provides a lightweight authentication protocol. However, the scheme is not anonymous because the server 2 can track which users are sending messages. The message passing protocol according to the second embodiment introduces a pair of encryption keys to provide anonymity of the user devices with respect to the server 2. The user devices 1 in the second embodiment have a negotiated symmetric encryption scheme comprising an encryption function and a decryption function. As previously described, the MLS generates a group secret key that is shared amongst the users in the group. The group key is derived from an underlying continuous group key agreement (CGKA) protocol. The group secret key is therefore updated / rotated periodically by the CGKA. During the initiation of the second embodiment, each user derives a MAC key k MAC and an encryption key SKE from the group secret key. The encryption key and the MAC key are therefore secure and, given that they are derived from the group secret key, forward secrecy (i.e. even if the encryption key SKE is disclosed, it does not compromise previous encryptions) and post-compromise security (i.e. even if the MAC key is disclosed, the system will operate securely once the MAC key is updated) are achieved. At least one of the user devices 1 provides a copy of the MAC key to the server 2.

[0070] During initial setup, each user device provides a public token y to the other user devices. The public token y is generated from a corresponding private token using a one-way function. In the same way as described in the first embodiment, the private token is a binary string generated by the user device. The public tokens are distributed via the server. During distribution, each public token is encrypted by the group secret key SKE. As described below, messages sent via the server are provided with a message authentication code (MAC) that is checked by the server before forwarding the public key to the other user devices. The ciphertext of the encrypted public key and the MAC code generated based on the ciphertext are therefore distributed via the server. As with the first embodiment, the user devices are not limited to distributing a single public key y at a time, but can distribute multiple public keys y.

[0071] To send a message, a user (e.g. user 1) uses a one-way function to generate a new token pair x1’ and y1’ as described in connection with the first embodiment. The user device 1 then encrypts the message m, the new public token y’ and the current private token x using the encryption key SKE to generate a ciphertext C t In addition, the user device 1 uses the MAC key k MAC to generate a message authentication code Y t for the ciphertext C tag . The user device 1 then sends the ciphertext C t and the MAC code Y tag to the server 2.

[0072] Upon receiving the ciphertext and the MAC code, the server 2 immediately verifies the MAC code Y tag using the MAC key. According to a typical group messaging protocol (such as MLS), the server 2 is not yet provisioned with the encryption key SKE. Therefore, the server 2 cannot read the ciphertext C t nor can it verify which user device 1 sent the message. However, by checking the MAC code against the ciphertext using the MAC key, the server 2 can confirm that the ciphertext is from a member of the group and can prevent third parties from attacking the messaging system using denial-of-service attacks. If the MAC code matches the ciphertext, the server makes the ciphertext available to the group.

[0073] The recipient user device downloads the ciphertext from the server. The recipient user device can decrypt the ciphertext using the decryption function and the symmetric encryption key SKE. As previously described, the recipient user device checks the private token from the ciphertext against the stored public token to confirm the identity of the sender user device. The recipient user device also stores the new public token to allow further messages to be received from the sender user device.

[0074] The MAC key and the SKE key can be generated once for the group, or can be continuously regenerated in conjunction with the group secret in the group messaging protocol for the duration of the group messaging protocol.

[0075] In the example given, both the public token and the private token are encrypted within the ciphertext during transmission between the sender user device and the recipient user device via the server. However, in order to maintain anonymity, all that is required is that the server cannot access the public token and the private token. Therefore, in other implementations, one of the public token and the private token can be sent in decrypted form between the sender user device and the recipient user device via the server.

[0076] Figures 7A to 7C show a protocol according to a second embodiment. The main difference between the first embodiment and the second embodiment is shown in the boxes of Figures 7A to 7C.

[0077] Looking at the initialization function Init, shown in Figure 7A, the group secret key gsk is obtained. As mentioned above, the group secret key is a feature of the MLS protocol that allows each user device 1 in the group to access the group secret key gsk. In step 2, a pseudo-random function PRF is applied to the group secret key to generate a MAC key sk sv , also referred to as Sv. In step 3, the pseudo-random function PRF is also used to generate an encryption key SKE. Steps 5 to 14 are the same as steps 2 to 11 of the Init function in the first embodiment. As mentioned previously, these steps, performed by the user device 1, generate the private token and the public token. In step 15, the user state st u now contains the MAC key and the encryption key. In step 16, it is noted that, as mentioned above, since the token is encrypted, the server 2 is no longer able to check the received token. Therefore, the server 2 no longer maintains a database of public tokens and the state pp of the database is not maintained at the server Sv.

[0078] The Send function shown in Figure 7A is essentially the same as described in connection with the first embodiment, except that the attach-auth-token(st u ) function has been changed. Referring to the attach-auth-token(st u ) function, in step 6, the encryption function SKE.Enc is used to encrypt the user identifier u, the counter ctr and the private token x SKE to be sent to the server 2 under the encryption key k u to generate the ciphertext ct SKE . In step 7, the group message authentication code (MAC) is generated using the MAC generation function on the ciphertext ct SKE .

[0079] Since the verify-auth-token(┴, sk sv , Σ G ) has changed, the Verify function performed by the server 2 shown in Figure 7A has changed. Referring to the verify-auth-token(┴, sk sv , Σ G ) shown in Figure 7C, the server 2 uses the MAC generation function, the ciphertext and the MAC key to check the MAC code received from the user device 1. The function now returns an indicator indicating whether the MAC code is valid and the download package σ i , which is the ciphertext to be downloaded by the receiving user device 1 in the group.

[0080] The Receive function executed by the user device 1 differs from the first embodiment because the trace-sender(st u , σ, m) function has changed. Referring to the trace-sender(st u , σ, m) function in step 4, the user device 1 uses the encryption key k SKE and the decryption function SKE.Dec to decrypt the ciphertext ct SKE to retrieve the sender's user identifier v , the counter ctr v and the private token. Steps 5 to 9 correspond to steps 4 to 8 described in connection with the Verify function in the first embodiment and will not be described again. The Verify function compares the received private token x with the public token y maintained at the user device 1. The Receive function returns the updated state st u , an indication whether the token has been verified and the sender's user identifier v .

[0081] Referring to Fig. 7B, the function UpdSend differs from the first embodiment in several ways. In step 3, the function attach-auth-token is used to generate the encrypted ciphertext and the MAC code. The function attach-auth-token of the second embodiment has been described above and will not be described again. Step 10 corresponds to step 9 in the first embodiment and involves adding the new public token Y u to the update package . In the second embodiment, the user identifier and the new public token Y u are encrypted in the update package using the encryption function of the negotiated encryption scheme with the encryption key k SKE to generate the ciphertext , also referred to as (see step 11).

[0082] The function UpdVerify now essentially corresponds to the Verify function because the server 2 no longer maintains a list of public tokens. The verify-auth-token function used in this process has been described above in connection with the Verify function of the second embodiment and will not be described again.

[0083] The function UpdReceive is changed in several ways. In step 3, the function The trace-sender has been changed to contain a step to decrypt the ciphertext in the download package Steps 4 and 5 use the encryption key k SKE to decrypt the ciphertext containing the new public token Steps 6 to 9 of the UpdReceive function are the same as steps 5 to 8 of the UpdReceive function described in connection with the first embodiment, and serve to update the public token at the user device 1 based on the received new public token as described previously.

[0084] The second embodiment employs the first embodiment to provide anonymity. By using the MAC code, the server 2 can perform a check on incoming messages, thereby preventing user devices 1 that are not members of the group G from sending messages to the group G. This has the effect of reducing the chance of denial of service attacks.

[0085] The third embodiment

[0086] Figure 8 is a schematic diagram illustrating the third embodiment. The second embodiment can be vulnerable to denial of service attacks from within the group. For example, in connection with the second embodiment, a user device 1 within the group can create junk ciphertext and add a valid MAC to each ciphertext. The server 2 will check the MAC and forward the message, although the ciphertext has no value. To mitigate this problem, it can be desirable for users within the group to be traceable, so that the behaviour of a malicious user can be mitigated.

[0087] According to the third embodiment, rather than every user device 1 generating its own token, users generate tokens that allow other users to send messages to them. This involves a relatively expensive initial phase of generating and distributing tokens. Figure 8 Four user devices 1 during the initial phase are illustrated. Figure 8 Only user 1 is shown generating and distributing a token, but in practice every user can generate and distribute a token in order to allow messages to be sent to that user. As with the previous embodiments, the private token x is generated as a binary string, and the public token y is generated based on a one-way function known to all user devices 1 and the server 2. The notation a→b indicates that messages can be sent from user device a to user device b. Thus, the private token x 2→1 is a token that user 2 can use to send messages to user 1. Each user device 1 maintains a private / public key pair. The private token x is generated by user 1, encrypted using the appropriate public key, and distributed in encrypted form to other users, so that the private token is passed securely and can be decrypted by the receiving user device 1. For security reasons, user 1 also generates a private token for itself. As Figure 8As shown, user 1 uploads a public token y to server 2, which stores the public token in a database. The user device can download the public token from the database and store it locally.

[0088] Figure 9 Two tables are shown. The upper table shows the stored private tokens x, and the lower table shows the stored public tokens y. In the example shown, each device has been issued three tokens per user, such that a user can send a maximum of three messages before the public tokens in the lower table need to be refreshed. The lower table storing the public tokens y may be stored on server 2.

[0089] In use, a user wanting to send message m to another user looks up the received private token x from that user. A request is sent to server 2, containing message m and the associated private token x for each device in the group to receive the message. Server 2 uses a one-way function known to each user device 1 and server 2 to check if each received private token corresponds to a public token uploaded to server 2. If the check passes, the message is available to user devices 1 within the group. User devices 1 in the group can download the message and associated private tokens and can check the private tokens against the private tokens distributed to the sender or against the associated public tokens.

[0090] In this embodiment, the message provided by server 2 is checked against a public token, enabling the receiving user device 1 to know who is sending the message. Therefore, if the user's behavior is malicious, the user can be identified.

[0091] The third implementation reduces the need for periodically regenerating tokens. Instead of distributing a number of private tokens x to each user to allow them to send messages, each user device 1 can instead distribute a corresponding private seed token to each other user in the group, which can be used in conjunction with a pseudo-random function to generate private tokens. This reduces the overhead in the initial phase.

[0092] Further developments in the third implementation involve user anonymity. If server 2 uses... Figure 9 If the table is stored in the form shown in the lower table, server 2 will be able to track which user sent subsequent messages because adjacent columns in the lower table are used to check for messages from the same user. To solve this problem, users can generate a permutation key from the group secret key in the MLS protocol. Each user device 1 can write its generated public token to server 2 using an index generated based on the determined permutation key and another value (such as an incrementing period value each time the public token is updated). In this way, the public tokens are stored on server 2 in random order, and server 2 cannot track which users sent messages.

[0093] One feature of implementations of the third embodiment is that once one user in the group has exhausted the common tokens on the server 2, the user must wait until all other users have performed an update before being able to send a message again, otherwise the server 2 will reject the message as no corresponding common token is stored on the server 2. This feature can be undesirable if there is a large asymmetry in the number of messages sent by each user, or if some users remain inactive for long periods of time.

[0094] One way to alleviate this problem is to adaptively modify the number of common tokens distributed to each user at each epoch, to allow some users to send more messages than others. In the case of the anonymous implementation as described above, the server 2 can observe the total number of tokens, but cannot deduce how many tokens were distributed to any particular user.

[0095] In a further implementation, instead of waiting for all users of the group to update their tokens for the epoch, a subgroup of users can send messages within the group after having received a limited number of updates of a set of common tokens for the next epoch. The benefit of this approach is that users can update their tokens and start sending messages without having to wait for all users to perform an update. The drawback of this approach is that the anonymity of the user devices 1 is limited to the size of the subgroup of user devices 1 that have updated.

[0096] In some implementations, the second and third embodiments can be combined. As described above, the second embodiment is anonymous and efficient, but lacks user traceability. Thus, the third embodiment can be implemented, and in the case where the third embodiment is implemented and less than a predetermined number of user devices 1 in the group G have updated their tokens, the method can switch to using the second embodiment for communication until other user devices 1 have updated their tokens. This hybrid approach combines the benefits of both the second and third embodiments.

[0097] Figures 10A to 10D illustrate the protocol according to the third embodiment. Referring to Figure 10A, the Init function is performed by the user devices 1 in the offline phase in which the seeds are distributed among the user devices 1. The Init function is performed by each user device 1. In step 1, the group secret key gsk is obtained. As in the earlier embodiments, the group secret key is a feature of the MLS protocol which allows the group secret key to be distributed to each user device 1 that is a member of the group. Steps 4 to 8 are performed for each user device 1 in the group for group messaging. Two lists SendSEED u and ReceiveSEED u are prepared. A public / private key pair (ek u , dk u) is generated using a key encapsulation mechanism (such as the hashed ElGamal KEM or NIST post-quantum standard Kyber) of a key generation function. The user identifier and the encryption key form an object EK. The encryption key is a public key available to the group such as by publication on the server 2. A period is set to 0 and a period permutation key k epoch .

[0098] In step 10, the function gen-auth-token is called as shown in figure 10C. In step 3 of the function gen-auth-token, the value EK for each user (which is the user identifier and the generated encryption key ek v ) is used with an encryption function of the key encapsulation mechanism. The encryption function generates a seed value and a ciphertext ct v for each user device 1 of the group, the ciphertext encrypting the seed under the public key of the corresponding user. This process is repeated for each member of the group in order to generate a seed v for each user of the group from the generated seeds v→u In step 4, the generated seeds are included in the value ReceiveSEED for a given period. Steps 5 to 8 generate T public and private tokens from the generated seeds. In step 7, a pseudo-random function PRF is used to generate T private tokens from the seeds generated in step 4. In step 8, a one-way function OWF known by the user device 1 and the server 2 is used to generate T public tokens from the generated T private tokens. In step 9, the public tokens are ordered by the users of the group. As shown in step 10, the ordered sets of T public tokens ordered by the users are set to Y. The function gen-auth-token returns a list of seeds ReceiveSEED which is an ordered list of public tokens Y and ciphertexts ct v encrypted under the public keys of the other user devices and which will allow the other user devices 1 to receive the seeds.

[0099] Returning to the Init function shown in figure 10A, steps 12 and 13 store the seeds generated by each user device 1 for itself in the corresponding entry in the list ReceiveSEED u so that the seeds can receive a copy of their own messages.

[0100] Steps 14 and 15 define an overall list SEED u based on the lists SendSEED and ReceiveSEED, step 16 defines the user states st u .

[0101] In step 17, the database is prepared on server 2 (referred to as Sv). In steps 18 through 21, each user device 1 uploads its public token to the database DB, where the public token is configured according to the pseudo-random permutation function PRP with respect to the epoch key k. epoch Reorder below.

[0102] Although not shown, the encrypted ct v It is uploaded to server 2 and downloaded by the corresponding user device 1. User device 1 uses its private key dk u The ciphertext is decrypted using a key encapsulation mechanism. Each decrypted seed is added to the SendSEED list of user device 1 for transmission to the user device 1 from which the seed is received.

[0103] Figure 10A shows the Send function used to generate the group authentication token Σ. G This is used when sending message m. In steps 1 and 2, user device 1 parses the user state st. u And check the counter ctr to see if the token at server 2 needs to be updated. In step 3, update the counter, and in step 4, use the function... attach-auth-token(st u To generate group authentication tokens Σ G .

[0104] attach-auth-token(st u The following is shown in Figure 10C. In steps 1 and 2, the user state st is parsed. u and SEED u In step 3, the key k is replaced. epoch It is generated in the same manner as step 8 of the Init function. In steps 4 through 6, the seed is retrieved from SendSEED. u→v Pseudo-random functions are used based on a counter (ctr) and a seed (seed). u→v Use epochs to generate private token x (ctr) u→v Note that the generated private token is generated using the Init function described above. Step 7 of the `gen-auth-token` function is generated using the same method. Therefore, the corresponding public token is available in the database `DB` on server 2. Steps 7 through 9 involve using the pseudo-random permutation function `PRP` to compute the permutation index of the corresponding public token in the database. attach-auth-token returns the substitution index. sendThe index identifies the location of the corresponding public token in the database on server 2 and a set of private tokens used to send messages to group user device 1.

[0105] Returning to the Send function shown in Figure 10A, in step 5, the user state st is updated with the updated counter. u The Send function returns the updated user state st'. u and group authentication token Σ G .

[0106] Figure 10A also shows the Verify function executed by server 2, which receives message m and group authentication token Σ from the sending user device 1. G In step 1, server 2 determines the status pp of database DB. In step 2, server 2 uses... verify-auth-token(pp, Σ G The final step of the Verify function is to return the function. verify-auth-token(pp, Σ G The output of ).

[0107] verify-auth-token(pp, Σ G This is illustrated in Figure 10D. In step 1, the state pp of the database is obtained, which contains the public token Y. In step 2, the received group authentication token Σ is parsed. G To identify the period and the replaced index send And a set of private tokens. In steps 4 through 7, server 2 checks and replaces the index. send A portion of the associated database is used to check the received private token against the corresponding uploaded public token Y. This check is performed using a one-way function OWF. If the check passes, server 2 removes the column for the public token and generates a download package. In steps 8 and 9, server 2 generates a download package σ for each user device 1 to receive the message. The download package contains the period of that user device 1, the replacement index, and the associated private token. In steps 10 and 11, the database state is updated. verify-auth-token(pp, Σ G Returns the updated database status and group σ i Download package for user device 1.

[0108] Figure 10B illustrates the UpdSend function executed by user device 1 to refresh the public token according to the third embodiment. As previously described, the purpose of the UpdSend function is to generate a public token to refresh the public token on server 2 and to generate a group authentication token Σ that will be sent along with the update. G Step 1: Parse the current user state st u Step 2 notes that user device 1 cannot start another period if other users have not completed refreshing their public tokens in the current period. In step 3, if the counter has reached T, meaning all public tokens associated with user device 1 have been used, the counter is reset to zero.

[0109] In step 4, the SEED is parsed. u And in step 5, the period is advanced. In step 6, a new permutation key k is generated for the new period. epoch' The replacement key is generated based on the group key gsk and the new epoch value. In steps 7 and 8, the function is used... `gen-auth-token` generates new seeds and tokens for the new era. The above description, combined with the `Init` function, illustrates this. The process of generating an auth token is the same and will not be described again. In steps 9 through 12, the newly generated public token... u Uploaded to server 2 to be replaced by key k epoch' The determined permutation order is stored in the database. In step 13, an update package is formed. t G In the update package t G It contains the index idx(u) and a new set of public tokens. u and encrypted ct v .

[0110] In step 14, the function attach-auth-token is used to generate group authentication tokens. G .function The attach-auth-token has already been described above in conjunction with the Send function, and will not be described again. In step 17, the seed SendSEED is sent. u The list is reset to remove seeds from the previous period. In steps 16 and 17, the user's own seeds are added for the new period. Steps 18 and 19 define the overall seed list. u And note that the counter is set to T, but the user state is st' uThe set period value has not yet been updated. In step S20, the user state is updated, and in step 21, the UpdSend function returns the updated state st'. u Group authentication token G and update package t G .

[0111] Figure 10B also shows the UpdVerify function executed by server 2. In step 1, the state of server 2 is parsed. Step 2 is the same as step 2 of the verification function, which uses the above-described... The `verify-auth-token` function returns the updated database status and the downloaded package σ. i Since the functionality has already been described, it will not be repeated. In steps 3 and 4, the group authentication token is parsed. G and update package t G In step 5, server 2 checks the database to see if there is an entry ID for user device 1 that is sending updates in the next epoch (epoch+1). receive If this condition is met, then in step 6, the public token will be combined with user device 1 and the new era. Save to the database. In step 8, update package ct. i Torrent download package set to receive from user device 1 The UpdVerify function returns the updated database status pp' and the downloaded package σ. i and torrent download package t i .

[0112] Figure 10B also shows the function UpdReceive. This function is executed by each user device 1 that receives an update from user device 1 that has executed UpdSend. In steps 1 and 2, the user state st is parsed. u and Seeds u Step 3 corresponds to step 1 of the Receive function described above, and utilizes... The trace-sender function is used to identify user device 1 that sent the download packet. Since this step and function have already been described, they will not be repeated here.

[0113] Steps 4 through 7 relate to updating the SendSEED list. In step 4, user device 1 adds the seeds it generates for itself to the SendSEED list. In step 5, user device 1 checks which user device 1's send-seed list does not yet contain an entry in the new epoch (epoch+1). If the condition in step 5 is met, then in step 6, the user device's private key dk is used. u For ciphertext Decrypt to decrypt the seed u→v In step 7, the decrypted seed is added to the SendSEED list. Step 8 defines the updated overall list of seeds. u In step 9, if all user devices 1 in the group have completed the update process, and the new era list is SendSEED... u If there are no empty entries, then in step 11, the user device status st' is updated with the new time value. u Step 12 indicates that if all user devices 1 in the group have not yet completed their updates, then the user device status st' u It will not be updated to the new period value.

[0114] The function UpdReceive returns the updated user state st' u And the identifier of user device 1 that sends the update.

[0115] The third implementation adds user traceability to the authentication mechanism. As mentioned above, these methods can be used to mitigate the risk of denial-of-service attacks because users within a group cannot easily carry out such attacks.

[0116] Fourth Implementation Method

[0117] The fourth implementation is an improvement upon the third implementation. The main difference between the third and fourth implementations is that the public token is replaced by a verification key from the one-time signature key pair, and the private token is replaced by a signature under the signing key of the one-time signature key pair. Previous implementations offered slightly less protection against forgery because the private token was not bound to the sent message. This drawback is a trade-off for the relative computational efficiency of these earlier implementations.

[0118] Figure 11 The fourth embodiment is shown, which illustrates four users during the initial phase. Figure 11Only user 1 is shown generating and distributing tokens, but in practice each user can generate tokens to allow messages to be sent to that user. User device 1 and server 2 are aware of a one-time signature scheme. Each user device 1 in the group provides each other user with a respective signing key from a plurality of pairs of one-time signature keys otsk using its respective public key. Each user device 1 also uploads a verification key of a one-time signature key pair to server 2. Thus, in addition to the public keys taking the form of verification keys from one-time signature key pairs, server 2 stores a set of public tokens similar to the third embodiment. In the case of a user device 1 sending a message m, the user device 1 locates a one-time signature key received from the user device 1 to which the message is to be sent (or a set of one-time signature keys for members of the group to which the message is to be sent) and signs the message with the one-time signature key (or set of one-time signature keys) to generate a private token. The message and private token in the form of a message signature are then sent by the sender user device 1 to server 2. Server 2 receives the message and private token and checks the signature / private token using a public token, which is a one-time signature verification key associated with a signature previously uploaded to server 2.

[0119] If server 2 can verify the signature / private token using the public token / verification key, server 2 makes the message and private token available to the group.

[0120] Receiving user devices 1 in the group obtain the message and private token and check the private token against the corresponding public token or against a private token generated by the receiving user device 1 for receiving the message from the sender user device 1.

[0121] As with the third embodiment, rather than sending multiple one-time signature keys to a user, a single distribution phase can distribute a seed which can be used by a sender user device 1 to generate a one-time signature key. The sender user device 1 then signs a message to be sent using the one-time signature key, the signature forming a private token.

[0122] As with the third embodiment, the fourth embodiment requires a limited number of public tokens (one-time verification keys) to be uploaded to server 2 to allow checking and receiving of messages. The difficulties associated with running out of public tokens on server 2 are discussed in relation to the third embodiment and methods for mitigating these difficulties are equally applicable to the fourth embodiment.

[0123] Figures 12A to 12D show the protocol of the fourth embodiment. The main differences compared to the third embodiment are shown in the boxes.

[0124] Figure 12A shows the Init function. In addition to Apart from the difference in the gen-auth-token function, this function is the same as the function described above in conjunction with the third implementation method. The gen-auth-token function is shown in Figure 12C. In steps 6 through 9, the public token y is replaced with the verification key from the one-time signature key pair. In step 7, T random values ​​r are generated using a pseudo-random function. v→u The pseudo-random function uses seed v→u As input, the period, the token counter t varying across T values, and the user identifier u are concatenated. The T one-time signature key pairs are obtained using corresponding random values ​​r. v→u The one-time key signature key is generated as input by a one-time key signature key generation function. Each one-time key signature pair includes a one-time signature key otsk and a one-time verification key otvk. In step 9, each one-time verification key is set as a public token y. As previously described, each user device 1 generates T keys for each user device 1 in the group.

[0125] In addition to using additional tags as input now... Apart from the changes to the attach-auth-token function, Figure 12A also shows the same Send function as described in conjunction with the third embodiment. In the Send function, the attached tag is set to "msg". The attach-auth-token function is shown in Figure 12C. In steps 3 through 15, a private token x is generated. u→v The private token is formed by signing using a one-time signature key. In step 6, a random value r is generated using a pseudo-random function PRF. v→u The pseudo-random function will send a seed. u→v As input and concatenated with the period, counter, and user device identifier. In step 7, the one-time signature key pair is used with a random value r. v→u The one-time key signature key is generated as input by the key generation function. This is the same process used in the Init function to generate the one-time signature key pair, so the corresponding verification key has been uploaded to server 2 as a public token. Steps 7 to 14 involve cases where the label is "msg" or "obj". The function for attach-auth-token. Since the tag is "msg" in this case, steps 8 through 10 will be described. The description of steps 11 through 14 will be postponed until when discussing the UpdSend function.

[0126] Steps 8 to 10 generate a private token x by signing message m. u→vThe message will be sent under the one-time signing key otsk. Otherwise, the protocol proceeds as before.

[0127] Figure 12A shows the Verify function, except... Apart from the changes in the verify-auth-token function, the Verify function is the same as described above. The verify-auth-token function now additionally accepts the message m and the tag "msg" as input. The verify-auth-token function is shown in Figure 12D. Steps 4 through 15 describe alternative functions depending on whether the input label is "msg" or "upd". Steps 4 through 8 related to the label "msg" will now be described. The description of steps 9 through 15 will be postponed to the discussion of the UpdVerify function.

[0128] In steps 4 through 8, the received private token x is parsed and based on the index. send The corresponding public token is identified in the database. The public token is used to verify the private token via the Verify function OTS.Verify from the signature scheme. The Verify function takes the public token, the message, and the private token as input. In this way, server 2 can verify the one-time signature that forms private token x.

[0129] Figure 12A shows the Receive function. Besides... Apart from the changes to the trace-sender function, the Receive function is the same as in the third embodiment, except for downloading the packet. The trace-sender function now also takes messages as input.

[0130] Due to the changes in steps 12 to 14, The trace-sender function differs from that in the third embodiment. The trace-sender function. User device 1 uses the pseudo-random function PRF to generate a random value r associated with the counter. v→u The pseudo-random function will send a seed. u→v As input, and concatenated with the period, counter, and user device identifier u. In step 13, a random value r is used. v→u To generate a one-time signature key pair. Use the Verify function in the signature scheme to check the received private token x, which takes the one-time signature verification key otvk, the message m, and the private token x as input.

[0131] Figure 12B shows the UpdSend function. Besides... gen-auth-token function and the attach-auth-token function. This function is similar to the function described in the third embodiment, except for the changes to the The changes to the gen-auth-token function have been described above in connection with the Init function and are not repeated here. The attach-auth-token function is shown in Fig. 12C and, unlike the send function, the The attach-auth-token function now takes the ciphertext ct v as input with the label "obj". In steps 11 to 14, the ciphertext ct v is signed using the one-time signing key otsk to generate a private key which is the signature of the ciphertext.

[0132] Fig. 12B shows the UpdVerify function performed by the server 2. This function is identical to the UpdVerify function described in the third embodiment, except for the changes to the verify-auth-token function. The verify-auth-token function is shown in Fig. 12D and steps 9 to 15 are related to verifying the update. The group authentication token G is parsed to obtain the private token x. The update package t G is parsed to obtain the ciphertext ct i . In step 14, the private token which is the signature of the ciphertext is checked using the Verify function of the signature scheme which uses the public token (verification key), the ciphertext and the private token to check the private token (signature).

[0133] Fig. 12B shows the UpdReceive function performed by the user device 1. This function is similar to the UpdReceive function described in connection with the third embodiment, except for the changes to the trace-sender function. The changes to the trace-sender function have been described above and are not repeated.

[0134] As mentioned above, the fourth embodiment reintroduces a signature scheme. The signature is based on the message which provides stronger protection against forging messages since the private token is now tied to the content of the message being sent.

[0135] Fifth embodiment ​

[0136] The fifth embodiment is a development of the fourth embodiment and aims to address the need to maintain a database of one-time signature verification keys at the server 2. The fifth embodiment uses a group signature scheme to manage traceability.

[0137] A group signature scheme is a cryptographic protocol that allows members of a group to sign messages on behalf of the group anonymously. The group signature scheme provides anonymity, traceability, unforgeability and verifiability.

[0138] The identity of the individual signer within the group remains hidden. The signature only identifies the group from which the signature originated, rather than revealing the actual signer. While the individual identity is hidden, a designated authority known as the tracer can trace the signer of the signature. This property ensures that if the signature is misused or generated maliciously, the tracer can expose the identity of the signer.

[0139] Signatures generated using a group signature scheme should have the ability to be unforgeable. Only authorised members of the group can produce valid signatures, and it is computationally infeasible for anyone else to forge a signature. Any recipient of the group signature can verify its authority using a public verification key. The verification process confirms that the signature is valid and originates from a member of the prescribed group.

[0140] A group signature scheme can involve various cryptographic techniques, such as digital signatures, zero-knowledge proofs and key management protocols, to achieve the desired properties. The exact details and underlying algorithms used can vary depending on the specific group signature scheme being implemented. Examples are given further below.

[0141] A group signature consists of three entity types: a group manager, a group tracer and users. The group manager is unique and handles the registration of new users in the system. When a user wishes to join the system, the group manager provides a certificate cert proving that the user is a legitimate user in the system. The user prescribes a group tracer and can use cert to anonymously sign messages on behalf of all users in the system. Note that there can be multiple group tracers with different tracer keys in a group signature scheme. The signature is publicly verifiable, but importantly, the signature is anonymous to any entity, including the group manager, except the prescribed group tracer . In contrast, the tracer can return the signature traced back to the user .

[0142] ​A secure group messaging protocol using group signatures is provided as follows. Server 2 is the group manager and system user 1 is a user of the group signature scheme. Note that the system user will want to communicate in a smaller group, which will be referred to as the MLS group from now on. Since the MLS group users in the MLS group should be the only users that can track the signature of the MLS group, each group tracker associated with that set of tracker keys are in the MLS group. This is possible because each user in the MLS group G is using the MLS shared common group secret key gsk. Each user in the MLS group generates the group tracker's key (gtvk , gtsk ) by executing the group tracker's key generation algorithm using randomness derived from the MLS group signature key. When a user sends a message to the MLS group G, the user runs the signature algorithm of the group signature scheme by specifying the group tracker's key (i.e. specifying that MLS group as the tracker). The server 2 relays the message to the MLS group G only if the signature is verified. A group user can locally run the tracking algorithm on the system group signature because the group user holds the group tracker's secret key gtsk . The users in the group further use the group secret key gsk to generate a unique MLS group signature key pair (vk, sk) and upload the MLS group verification key vk to the server 2. To send a message to the group, the group user device 1 generates the system group signature discussed in the previous paragraph, which allows traceability, and also appends the MLS group signature or MLS group message access code (MAC) generated by the MLS group signature key sk. Similar to the second embodiment, this additional MLS group signature guarantees that only group members can send messages within the group because the server 2 checks the MLS group signature of the incoming message with the MLS group signature verification key vk. The group signature scheme guarantees that users can sign the group user tracker. Since the group signature scheme allows the user device 1 to sign an unlimited number of messages, the problem of needing to update the token or one-time signature at the server 2 periodically is overcome.

[0143] Further description

[0144] Details of examples of these functions are given as follows:

[0145] Various functions are described above. Details of examples of these functions are given as follows: ​One-way function (OWF): This can be any one-way function. Truncated SHA 256 is an example. The output can be truncated to any length, but in one example is truncated to 16 bits.

[0146] Message authentication code (MAC) and pseudo-random function (PRF): This can be selected from known MACs and PRFs. In one example, the MAC can be HMAC (Hugo Krawczyk, Mihir Bellare, and Ran Canetti, “HMAC: Keyed-Hashing for Message Authentication,” RFC 2104, IETF Internet Review, 1997). The output can be truncated. In one example, the output can be truncated to 16 bits. Note that a deterministic MAC can be considered a PRF.

[0147] Pseudo-random permutation (PRP): This can be selected from known PRP functions. In some embodiments, Fast-PRP (Emil Stefanov and Elaine Shi, “Fast-PRP: Fast Pseudo-Random Permutations for Small Domains,” Cryptology ePrint Archive, Report 2012 / 254, 2012), or Thorp shuffle (Ben Morris, Phillip Rogaway, and Till Stegers, “Deterministic Encryption with the Thorp Shuffle,” Journal of Cryptology, Vol. 31, No. 2 (April 2018), pp. 521-536) can be used.

[0148] One-time signature scheme: This can be selected from known schemes. For example, for classical security, Ed-DSA (Daniel J. Bernstein, Niels Duif, Tanja Lange, Peter Schwabe, and Bo-Yin Yang, “High-Speed High-Security Signatures,” CHES 2011 (LNCS, Vol. 6917), edited by Bart Preneel and Tsuyoshi Takagi, Springer-Verlag (Heidelberg), pp. 124-142, 2011) can be used. For post-quantum security, WOTS+ (Andreas Hülsing, “W-OTS+ - Short Signatures Based on Hash-Based Signature Schemes,” Africrypt 13 (LNCS, Vol. 7918), edited by Amr Youssef, Abderrahmane Nitaj, and Aboul Ella Hassanien, Springer-Verlag (Heidelberg), pp. 173-188, 2013) can be used.

[0149] Signature scheme: This can be chosen among known signature schemes. For example, the traditional secure Ed-DSA (see references above) can be used. For post-quantum security, the NIST PQC standard Dilithium (Vadim Lyubashevsky, Léo Ducas, Eike Kiltz, Tancrède Lepoint, Peter Schwabe, Gregor Seiler, Damien Stehlé, and Shi Bai, “CRYSTALS-DILITHIUM,” in Technical Report, published by the National Institute of Standards and Technology, 2022) can be used.

[0150] Group signature: This can be chosen among known group signature schemes. For example, for traditional security, the pairing-based BBS scheme (Dan Boneh, Xavier Boyen, and Hovav Shacham, “Short Group Signatures,” in CRYPTO 2004 (LNCS, vol. 3152), edited by Matthew Franklin, Springer-Verlag (Heidelberg), pp. 41-55, 2004) can be used. For post-quantum security, the lattice-based scheme proposed by Lyubashevsky, Nguyen, and Plançon (LNP) (Vadim Lyubashevsky, Ngoc Khanh Nguyen, and Maxime Plançon, “Lattice-Based Zero-Knowledge Proofs and Applications: Shorter, Simpler, More Versatile,” in

[43] , pp. 71-101, 2022) can be used.

[0151] Key encapsulation mechanism (KEM) scheme: This can be chosen among known schemes. In some examples, the hash-based ElGamal key encapsulation mechanism, or the NIST PQC standard Kyber (Peter Schwabe, Roberto Avanzi, Joppe Bos, Léo Ducas, Eike Kiltz, Tancrède Lepoint, Vadim Lyubashevsky, John M. Schanck, Gregor Seiler, Damien Stehlé, and Jintai Ding, “CRYSTALS-KYBER,” in Technical Report, published by the National Institute of Standards and Technology, 2022) can be used.

[0152] As mentioned above, the user device 1 and the server 2 can be any type of information processing apparatus. For example, the user device 1 can be a mobile device, such as a mobile phone. In some cases, the server 2 can be implemented as a cloud service or a separate standalone server.Figure 13 is a schematic diagram of components of an example information handling device suitable for use in the method. The diagram is illustrative and as is well known in the art different hardware configurations of information handling devices are possible. The information handling device includes an I / O interface 10, such as a USB port, a Thunderbolt port or the like, to which additional devices, such as storage devices, can be connected. The information handling device comprises a processor 11, a storage device in the form of a memory 12, a network module 13, a display 14 and a user interface 15. The network module can allow the information handling device to communicate over a network, such as a Wi-Fi network, a mobile telecommunications network, a local area network or the like. The user interface can include components such as a keyboard, a mouse, a camera or the like. The components of the information handling device can communicate with each other over a bus 16. Further components can be provided but are not shown or described. Any of the steps of the method described above can be performed by computer readable instructions of one or more programs stored in the storage device and executed by the processor on one or more information handling devices.

[0153] The above-described embodiments can be implemented on MLS or related protocols such as CoCoA (Joël Alwen, Benedikt Auerbach, Miguel Cueto Noval, Karen Klein, Guillermo Pascual-Perez, Krzysztof Pietrzak, and Michael Walter. CoCoA: Concurrent Continuity Group Key Agreement. In

[44] , pages 815-844, 2022), and variants of MLS (Joël Alwen, Sandro Coretti, Yevgeniy Dodis, and Yiannis Tselekounis. Security Analysis and Improvements for the IETF MLS Group Messaging Protocol. In CRYPTO 2020, Part I (LNCS, volume 12170), edited by Daniele Micciancio and Thomas Ristenpart, Springer-Verlag, Heidelberg, pages 248-277, 2020), (Joël Alwen, Sandro Coretti, Daniel Jost, and Marta Mularczyk. Continuity Group Key Agreement with Proactive Security. In

[62] , pages 261-290, 2020), and (Joël Alwen, Dominik Hartmann, Eike Kiltz, and Marta Mularczyk. Server-Aided Continuity Group Key Agreement. In

[73] , pages 69-82, 2022). Additional suitable continuity group key agreement schemes are described in (Keitaro Hashimoto, Shuichi Katsumata, Eamonn Postlethwaite, Thomas Prest, and Bas Westerbaan. Concrete Treatment for Efficient Continuity Group Key Agreement via Multi-Receiver PKE. In

[68] , pages 1441-1462, 2021), and (Keitaro Hashimoto, Shuichi Katsumata, and Thomas Prest. How to Hide Metadata in Secure Group Messaging like MLS: Simple, Modular, and Post-Quantum Era. In

[73] , pages 1399-1412, 2022).

[0154] Each of the above embodiments can be implemented using MLS (or variants thereof). While this is straightforward, it is noted that the above definition of the authentication method is intentionally kept simple. The above method assumes that a trusted initialization algorithm Init prepares the group user state and that the user device 1 group is fixed once and for all. In contrast, in MLS, a single user creates (or initializes) a group G = {U1, U2, U3,...}, and then dynamically adds users to the group via sending a Welcome message.

[0155] In the following, an explanation is provided of how the above embodiments can be implemented with MLS. First consider use with an established / fixed set of group users. Then consider a slightly more complex case of how the embodiments can be implemented in the case of adding a new user to the group.

[0156] MLS message review

[0157] MLS consists of a Forward-Secure Payload Delivery (FSPD) and a Continuous Group Key Agreement (CGKA) protocol. The FSPD protocol authenticates application messages containing various types of data, such as chat text, images, and stamps. In contrast, the CGKA protocol authenticates two different messages: Handshake messages: This is further divided into Proposal messages and Commit messages (Richard Barnes, Benjamin Beurdouche, Raphael Robert, Jon Millican, Emad Omara, and Katriel Cohn-Gordon, Messaging Layer Security (MLS) Protocol, published by the Internet Engineering Task Force, Section 2 and 3 of draft-ietf-mls-protocol-20, Internet-Draft). These are messages sent between group users that are responsible for modifying the group state (e.g., to update the group secret key gsk).

[0158] Welcome messages: This is a message sent by a group user to an outsider, making him / her a group member.

[0159] Note that both application and handshake messages are messages exchanged within the group. In contrast, welcome messages are exchanged between a group user and an outsider. For ease of explanation, we refer to the first two messages as group messages.

[0160] Authentication in a fixed group

[0161] ​We assume that one of the above embodiments has been set. That is, if any user device 1 sends a message, all users accept the group authentication token. And since the group is fixed, we only focus on group messages.

[0162] MLS formats group messages in a specific way: (gid, epoch, senderID, Contents, AuthData), when using public mode (gid, epoch, ct) senderID ct Contents AuthData), when using private mode Where gid is the group identifier; epoch is the counter; senderID is the sender's identifier; Contents stores group messages; ct Under the SKE key derived from the group key SKE encryption is performed. AuthData is the authentication data field. In MLS, AuthData contains the sender's signature in public mode or the encryption of the signature in private mode. Specifically, handshake messages are in public or private mode, corresponding to MLS Plaintext and MLS Ciphertext respectively. Application messages are always in private mode. In the following text, we will represent all information except AuthData as gmsg without considering the two modes, and for simplicity, gmsg will be called group messages. Considering this structure, the above implementation using MLS is simple. When the user When ∈G wants to send a group message gmsg, the user runs the Send algorithm to create a group authentication token Σ. G And then (gmsg, AuthData := Σ G Uploaded to server 2. Server 2 verifies Σ. G And prepare user authentication tokens ( ) ∈[ ],in = |G|.

[0163] In users Index of ∈G = idx( In the case of contacting server 2, server 2 returns (gmsg, AuthData). := Then, the user This can be achieved by adjusting (gmsg, The Receive algorithm described above is used to verify and track users. Here, we note that if the underlying MLS (or more precisely, the CGKA protocol) provides selective downloading, then server 2 can clean up gmsg into (gmsg ) ∈[ This allows each user to download only the amount of data they need.

[0164] Finally, in cases where the authentication method requires state updates (e.g., implementations 3 and 4), the group update information Σ can be determined based on the required anonymity guarantee. G Directly embedded into Contents or ct Contents It runs simply on top of MLS.

[0165] Authentication with a new group user

[0166] Now consider the case where outsiders are added to the group.

[0167] As previously mentioned, in the context of MLS, this is performed via a welcome message generated within the CGKA protocol. While the above implementations do not have the concept of such a welcome message, all implementations allow outsiders to adaptively join the group. Details are as follows: Implementation 1. This is simple because each user's state is independent of other users' states. When a newcomer joins the group via a welcome message, the newcomer only needs to create a new token ( 0, 0), and will public token 0 was uploaded to server 2 and the group. Additionally, outsiders could upload... 0 is either included in its key packet or authenticated by signing it directly with a long-term private key that can be verified using the corresponding public key. 0. Once 0 is shared within the group, and newcomers who join the group can use it. Messages are sent starting from 0. Additionally, outsiders can obtain other users' current public tokens from server 2. If a new user device 1 wants to verify that these public tokens were indeed created by the corresponding user, the new user device can obtain the public tokens directly from user devices 1 in the group.

[0168] The second implementation method is almost identical to the first implementation method. The only difference is that after processing the welcome message, the outsider recovers the current group secret key gsk. Then, the outsider uses gsk to derive the MAC key kMAC and the SKE key k. SKENote that kMACand kSKEcan be updated at any time of the CGKA protocol execution submission. This provides forward secrecy and post-compromise security of the anonymity and the anonymous blacklisting properties. Moreover, if anonymous sending of the welcome message is required, we can rely on existing anonymous two-party messaging protocols, such as Sealed Sender (Technical Preview: Sealed Sender of Signals, https: / / signal.org / blog / ) or Orca (Nirvan Tyagi, Julia Len, Ian Miers, and Thomas Ristenpart. Orca: Blacklisting in Sender-Anonymous Messaging. In USENIX Security 2022, edited by Kevin RB Butler and Kurt Thomas, USENIX Association, pages 2299-2316, 2022), since the welcome message is exchanged between a specific group user and a foreigner. Note that the latter protocols also provide user traceability.

[0169] Implementations 3 and 4. These are the most complex due to the global state update property. Since the protocol flow of the third implementation and the fourth implementation are identical, we only focus on the third implementation. We cannot simply append columns corresponding to new users, since server 2 can always link the public tokens associated with these appended columns. Therefore, to ensure anonymity, the group users must all update their state and flush the public tokens held by server 2. In more detail, similarly to the first implementation, the foreigner After processing the welcome message, the tokens are created and the public token ( ) j→o are uploaded to server 2, and the PRF seed → is sent to each group user device 1 so that it can recover the corresponding private token. After every other user device 1 updates its state by further creating an additional public token for the new user o , the new user can start sending messages. Note that since waiting for every user in a large group can be prohibitive, the method can initially use the second implementation at the cost of weakening anonymity and user traceability, as discussed above in connection with the third implementation.

[0170] Fifth embodiment. This is the only protocol that requires the MLS server 2 to additionally run a group signature scheme. When a user joins the secure group messaging application, the server 2 provides the user with a certificate. Assuming this step has been completed, joining the group is simple. This is because the only thing that a foreigner running the authentication method of the fifth embodiment needs is the group's tracking key and signature key, both of which are derived from the group secret key gsk. Thus, following the same discussion in the second embodiment, we can easily add a new user to the authentication scheme of the fifth embodiment.

[0171] Finally, note that for all of the above embodiments, removing a user is simple. Since the first embodiment is not anonymous, the server 2 can simply maintain a list of group members. The first and fifth embodiments themselves support removal at the MLS layer, since once a submission occurs, the MAC key kMAC is updated along with the group secret key gsk. Finally, for the third embodiment, the user device 1 can simply remove the unused public token corresponding to the removed user from the server 2.

[0172] The term "message" has been used in the above description. The term "message" is to be understood to mean data to be communicated and is not limited to text messages. For example, the message can be any of an image, a sound file, text or a data file.

[0173] The above embodiments are to be understood as illustrative examples of the application. It is understood that any feature described in relation to any one embodiment can be used alone or in combination with other features described, and can also be used in combination with one or more features of any of the other embodiments, or any combination of the other embodiments. Furthermore, equivalents and modifications not described above can also be employed without departing from the scope of the application, which is defined in the claims appended hereto.

[0174] The following clauses form part of the description. The claims follow these clauses and are so labelled.

[0175] 1. A method of authenticating a message received from a sender user device at a recipient user device in a group messaging protocol, comprising: receiving at the recipient user device a public token associated with the sender user device; storing the public token on the recipient user device; receiving at the recipient user device a private token and ciphertext, the ciphertext at least encrypting a message from the sender user device; decrypting the ciphertext by the recipient user device to obtain the message; verifying the private token against the public token stored by the recipient user device using a one-way function; in the event that the private token is verified, determining that the message has been received from the sender user device, wherein at least one of the public token and the private token is received at the recipient user device in an encrypted format.

[0176] 2. The method of clause 1, wherein the recipient user device receives the public token from a server, and the received public token is encrypted in a second ciphertext.

[0177] 3. The method of clause 1 or clause 2, wherein the recipient user device receives the ciphertext from the server, and the ciphertext encrypts both the private token and the message.

[0178] 4. The method of clause 2, wherein the server receives the public token, the ciphertext, the private token and a message authentication code associated with the ciphertext from the sender user device.

[0179] 5. The method of any preceding clause, wherein the message authentication code is generated from the ciphertext by the sender device using a MAC key associated with a group of users in the group messaging protocol.

[0180] 6. The method of clause 5, wherein the server checks the message authentication code using the MAC key, and only makes the ciphertext available to the group of user devices when the message authentication code matches the ciphertext.

[0181] 7. The method of any preceding clause, wherein the ciphertext is encrypted by the sender user device and decrypted by the recipient user device using a symmetric encryption key derived from a group secret associated with the group messaging protocol.

[0182] 8. The method of clause 7, wherein the sender user device derives the symmetric encryption key from the group secret associated with the group messaging protocol.

[0183] 9. The method of any preceding clause, wherein the MAC key is provided to the server by one or more of the user devices that are members of the group of users.

[0184] 10. The method of clause 9, wherein the sender user device derives the MAC key from a group secret associated with the group messaging protocol.

[0185] 11. The method of any preceding clause, wherein the one-way function is a truncated cryptographic function.

[0186] 12. The method of clause 11, wherein the cryptographic function is SHA 256 and the output is truncated to 16 bits.

[0187] 13. The method of any preceding clause, wherein the ciphertext also encrypts a new public token, and the recipient user device stores the new public token for use in receiving subsequent messages from the sender user device after the ciphertext has been decrypted.

[0188] 14. The method of any of clauses 1 to 12, wherein the sender user device generates the ciphertext by encrypting the message and one or more of a new public token and the private token for use in a next round of communication.

[0189] 15. A group messaging system comprising a server and at least two user devices, each of the server and the at least two user devices being an information processing apparatus comprising a processor and a computer readable storage medium storing program instructions causing the information processing apparatus to perform the steps of the method of any of clauses 1 to 14.

[0190] 16. A plurality of programs which, when implemented on a group messaging system according to clause 15, cause the group messaging system to perform the method of any of clauses 1 to 14.

[0191] 17. A method of authenticating a message received at a recipient user device from a sender user device in a group messaging protocol, wherein: a server is configured to handle messages from an overall set of user devices, user devices in the overall set of user devices are configured to communicate with each other in one or more local groups formed from the overall set of user devices using a group messaging protocol, each user device in a local group of the one or more local groups derives a local group messaging protocol key pair comprising a local group signing key and a local group verification key, each user device in the overall set of user devices is a member of a system group signature scheme, and each user device in each local group of the one or more local groups has a tracker key of the group signature scheme associated with that group, the tracker key being derived from a group secret of the group messaging protocol, the method comprising: the sender user device generates a system group signature for a message using the group signature scheme, wherein the message is to be sent to a local group of the one or more local groups and the system group signature is generated using a tracker key associated with the local group; the sender user device generates a private token associated with the message using the local group signing key; the server checks the system group signature using the system group signature scheme and checks the private token using the local group verification key of the group messaging protocol key pair; and the server makes the message available to the local group only when the system group signature is verified against the message and the private token is verified against the message, wherein the system group signature is usable by a recipient user device within the local group to verify the identity of the sender user device using a tracker function of the system group signature scheme.

[0192] 18. The method of clause 17, wherein the private token is one of a signature of the message and a message authentication code generated based on the message.

Claims

1. A method for authenticating messages received from a sender's user equipment using a group messaging protocol at a receiving user equipment, comprising: Receive a first public token associated with the sending user device at the receiving user device; The first public token is stored at the recipient user device; The first private token and ciphertext are received at the receiving user device, wherein the ciphertext at least encrypts the message from the sending user device. The ciphertext is decrypted by the receiving user device to obtain the message; The receiving user device verifies the first private token by comparing it with the stored first public token using a one-way function, wherein, if the first private token is verified, the first public token can be obtained by applying the one-way function to the first private token; and If the first private token is verified, it is determined that the message has been received from the sending user device. Wherein, at least one of the first public token and the first private token is received at the receiving user device in an encrypted format.

2. The method according to claim 1, wherein, The receiving user device receives the first public token from the server, and the received first public token is encrypted in the previous ciphertext.

3. The method according to claim 1 or claim 2, wherein, The receiving user device receives the ciphertext from the server, and the ciphertext encrypts both the first private token and the message.

4. The method according to claim 2, wherein, The server receives the first public token, the ciphertext, the first private token, and the message authentication code associated with the ciphertext from the sending user device.

5. The method according to any of the preceding claims, wherein, The message authentication code is generated from the ciphertext by the sending device using a MAC key associated with a group of users in the group messaging protocol.

6. The method according to claim 5, wherein, The server uses the MAC key to check the message authentication code, and only makes the ciphertext available to a group of user devices if the message authentication code matches the ciphertext.

7. The method according to any of the preceding claims, wherein, The ciphertext is encrypted by the sending user device and decrypted by the receiving user device using a symmetric encryption key derived from a group secret associated with the group messaging protocol.

8. The method according to claim 7, wherein, The sending user device derives the symmetric encryption key from the group secret associated with the group messaging protocol.

9. The method according to any of the preceding claims, wherein, The MAC key is provided to the server by one or more of the user devices that are members of the group of users.

10. The method according to claim 9, wherein, The sending user device derives the MAC key from the group secret associated with the group messaging protocol.

11. The method according to any of the preceding claims, wherein, The one-way function is a truncated encryption function.

12. The method according to claim 11, wherein, The encryption function is SHA 256, and the output is truncated to 16 bits.

13. The method according to any of the preceding claims, wherein, The ciphertext also encrypts a second public token, and the receiving user device stores the second public token for receiving subsequent messages from the sending user device after the ciphertext has been decrypted.

14. The method according to any preceding claim, comprising: The first private token is generated by the sending user device, and the first private token is a random or pseudo-random binary string; The sending user device generates the first public token by applying a one-way function to the first private token; The first public token, in encrypted or decrypted format, is sent to the recipient user device via the server.

15. The method according to claim 14, wherein, The sending user device: Generate the first private token, which is a random or pseudo-random binary string; A second public token is generated by applying a one-way function to the second private token; The ciphertext is generated by encrypting the message, the second public token, and the first private token; and The ciphertext is sent to the server.

16. A group messaging system comprising a server and at least two user devices, each of the server and at least two user devices being an information processing device, the information processing device including a processor and a computer-readable storage medium storing program instructions that cause the information processing device to perform the steps of the method according to any one of claims 1 to 15.

17. A plurality of programs, when implemented on a group messaging system according to claim 16, wherein the plurality of programs cause the group messaging system to perform the method according to any one of claims 1 to 15.

Images