Abstract

The Signal Protocol is one of the most popular privacy protocols today for protecting Internet chats and supports end-to-end encryption. Nevertheless, despite its many advantages, the Signal Protocol is not resistant to Man-In-The-Middle (MITM) attacks because a malicious server can distribute the forged identity-based public keys during the user registration phase. To address this problem, we proposed the IBE-Signal scheme that replaced the Extended Triple Diffie–Hellman (X3DH) key agreement protocol with enhanced Identity-Based Encryption (IBE). Specifically, the adoption of verifiable parameter initialization ensures the authenticity of system parameters. At the same time, the Identity-Based Signature (IBS) enables our scheme to support mutual authentication. Moreover, we proposed a distributed key generation mechanism that served as a risk decentralization to mitigate IBE’s key escrow problem. Besides, the proposed revocable IBE scheme is used for the revocation problem. Notably, the IND-ID-CPA security of the IBE-Signal scheme is proven under the random oracle model. Compared with the existing schemes, our scheme provided new security features of mutual authentication, perfect forward secrecy, post-compromise security, and key revocation. Experiments showed that the computational overhead is lower than that of other schemes when the Cloud Privacy Centers (CPCs) number is less than 8.

1. Introduction

Revelations of mass surveillance of communications have made consumers more privacy-aware. Scientists and developers have proposed security techniques for end-users even if they do not trust the service providers fully [1]. The Signal Protocol is a cryptographic protocol that secures the text messages of billions of people. It provides end-to-end encryption and is applied by secure communication tools such as WhatsApp, Facebook Messenger, and Microsoft Skype [2, 3]. The information of applications with the Signal Protocol and their monthly active users are shown in Table 1.

The Signal Protocol consists of two main subalgorithms, X3DH and Double Ratchet. X3DH generates many sets of ephemeral key pairs for each user in addition to the permanent keys. Then a shared key is created for users by combining ephemeral and permanent key pairs. The Double Ratchet algorithm contains two ratchets [4], the Diffie–Hellman ratchet and the Symmetric-key ratchet. The Symmetric-key ratchet uses the key derivation function (KDF) chain to derive new keys. It offers a previous-key-based key to encrypt each message and attempt to provide Perfect Forward Secrecy (PFS). Even if an attacker cracks the key of one message, the keys of previous messages cannot be derived inversely. The included Diffie–Hellman ratchet aims at ensuring Post-compromise Security (PCS). Therefore, the Double Ratchet algorithm satisfies both PFS and PCS. Neither the keys generated before the key  nor after can be calculated when is compromised.

Although having PFS and PCS, Signal Protocol cannot resist MITM attacks due to X3DH’s key distribution problem. Since there is no public key authentication in X3DH, the server can be an attacker against the system itself or a collaborator of the adversary.

The developers did consider the shortcomings of Signal Protocol to protect against MITM attacks and made some refinements. So each chat has a unique safety number [9] that enables one to verify the security of messages and specific contacts. As shown in Figure 1, the safety number is a hash of identity generated locally by both communicators, usually in a QR code. If a safety number has been marked as verified, any change can be manually approved before sending a new message [9]. However, a better plan to prevent MITM attacks should be in advance, rather than doing detection when an attack has approached.

It is unreasonable to believe that a server will duly alert when it is a potential attacker. Only the user actively verifies the safety number through a third-party channel is reliable. Schröder et al. [10] found that most users could not successfully verify each other’s safety numbers due to usability problems and incomplete mental models. Worsely, the Signal Protocol is not secure under a threat model with an untrusted server since much of the Signal Protocol’s functionality is on the server trusted premise.

The existence of MITM attacks is essentially a lack of public-key authentication. We are considering replacing X3DH with Identity-Based Encryption (IBE) for improvement. IBE scheme is a public-key cryptosystem where any string representing the identity is a valid public key [11]. A user can generate a public key from a known unique identifier, such as a phone number. Then a trusted third-party server calculates the corresponding private key from the public key. This process eliminates the need to distribute the public key before exchanging encrypted data. The sender can generate the public key and encrypt the data simply by using the receiver’s unique identifier. Correspondingly, the receiver can generate the private key with the help of a trusted third-party server, the Private Key Generator (PKG).

Blazy et al. [12] introduced IBS into the Signal Protocol to make it resistant to MITM attacks, but the problems [1316] inherited in IBS/IBE are yet to be solved:The Authenticity of System Parameters Problem. In the BF-IBE scheme, the attacker can generate the public system parameters by himself to make the users mistakenly believe that the parameters are correct.One-Way Authentication Problem. Instant messaging protocols generally support mutual authentication, but BF-IBE only authenticates the recipient’s identity.Key Escrow Problem. The PKG generates the users’ private keys with the master key. For this reason, identity theft might occur since the PKG is available to sign any message with the users’ identities. Users may also slander the PKG for misusing their private keys for signing, which threatens the undeniability of the signature.Public Key Revocation Problem. A user can generate a new public-private key pair when his key is at risk or expire. However, the BF-IBE scheme is unavailable to revoke the user’s public key.

1.1. Our Contributions

Our advanced Signal Protocol has the following security features:Resist MITM attack. Our IBE-Signal scheme is resistant to MITM attacks by leveraging the IBE scheme. Furthermore, we fixed the problems inherited in IBS/IBE.The Authenticity of System Parameters. By introducing a verifiable parameter initialization technique, the public validation of parameters is guaranteed to ensure the correctness of parameters transmitted by the Key Generation Center (KGC) and Cloud Privacy Centers (CPCs).Mutual Authentication. Our IBE-Signal scheme supports mutual authentication by introducing an Identity-Based Signature (IBS).Secure Key Escrow. We used distributed key generation to solve the key escrow problem, inspired by the ESKI-IBE scheme proposed by Kumar et al. [17]. Moreover, we also used the KGC and the CPCs instead of one PKG. Compared with [17], we reduced the computational overhead since there is no need to negotiate parameters after an initial session.Resist User Slandering. The KGC and the CPCs own the master key share separately, which disenables an attacker from obtaining the complete key. Therefore, an attacker cannot decrypt the users’ ciphertexts or forge the users’ signatures, and users cannot defame the server for misusing their private key.Secure Key Issuing. The blind signature enables the KGC or the CPCs to issue the private key without seeing the actual information sent by the user.Key Revocation. We achieved efficient public key revocation by adopting Revocable IBE. This scheme proposed by Boldyreva et al. [18] is built on the Fuzzy IBE scheme and binary tree data structure.Perfect Forward Secrecy and Post‐compromise Security. Our scheme still retains the PFS and PCS of the Signal Protocol by introducing the concepts of session and connection in SSL protocol into our scheme and integrating the Double Ratchet algorithm into the CONNECTION part.IND-ID-CPA. We proved the IND-ID-CPA security of the IBE-Signal scheme under the random oracle model and the Bilinear Diffie–Hellman (BDH) assumption. With more powerful attackers, we gained a more compact reduction than [17] in a challenger-adversary game.

1.2. Related Work

The security proof of the Signal Protocol has always been a research hotspot. Cohn-Gordon et al. [19] analyzed the security of the Signal Protocol and other authenticated key exchange protocols. Van Dam [20] provided an automated analysis of the Signal Protocol. Frosch et al. [21] first proved that TextSecure (the predecessor of the Signal) achieves most of its claimed security goals if the key registration is secure. Alwen et al. [22] gave formal proof of the perfect forward secrecy and post-compromise security of the Signal Protocol. Cohn-Gordon et al. [1] analyzed the security of multistage key agreement protocols based on the Double Ratchet algorithm for the first time. In addition, Kobeissi et al. [23] verified the security of end-to-end cryptographic protocols like the Signal Protocol with automated tools.

The Signal Protocol cannot resist MITM attacks when the key registration is insecure. There are many ways to resist MITM attacks. The traditional methods are Digital Signatures and Message Authentication Codes. Rivest and Shamir [24] proposed the interlock protocol to expose the eavesdropper of full-duplex communication. However, the interlock protocol increases the communication cost and is not suitable for half-duplex communication. Khader and Lai [25] proposed a method to resist MITM attacks in the Diffie–Hellman Key Exchange Protocol with the Geffe generator.

The MITM attacks are due to the lack of public-key authentication, traditionally implemented by distributing public key certificates through the Public Key Infrastructure (PKI). In 1984, Shamir [15] proposed the IBE scheme to simplify the public key certificate management in the PKI. Boneh and Franklin [16] implemented a practical and functional IBE scheme, the BF-IBE scheme, based on bilinear pairings on elliptic curves in 2001. Goyal [26] introduced the Accountable Authority Identity-Based Encryption (A-IBE) scheme to reduce trust in the PKG as an effective solution for the key escrow problem. The A-IBE scheme was matured into the Black Box AIBE scheme by Goyal et al. [27]. Later, Garg et al. [28, 29] proposed the Registration-Based Encryption (RBE) scheme, aggregating the KGC and compactly compressing all users’ public keys into the master public key.

1.3. Organization

To begin, in Section 2, we presented helpful preliminary information. Then, in Section 3, we detailed the construction of our approach. In Section 4, we analyzed the security features of the scheme. In Section 5, the IND-ID-CPA security of our scheme was proved. In Section 6, we analyzed the scheme’s performance and compared it with other schemes in performance and security. Finally, we concluded with comments on our work and limitations for future work in Section 7.

2. Preliminaries

We briefly introduced the background knowledge needed to read this paper, including Symmetric Bilinear Function, BDH Problem, X3DH Algorithm, BF-IBE Scheme, Hess’s IBS Scheme, and RIBE Scheme.

2.1. Notation

We defined a secure symmetric encryption algorithm as . For , is the key, and are the messages to be encrypted. The symmetric decryption algorithm and the signature algorithm are given similar forms.

2.2. Symmetric Bilinear Function

Let be a large prime, is an additive group, and is a multiplicative group of the same order . Given a symmetric bilinear function from to as and satisfies the following properties:Bilinearity: and , such that .Nondegeneracy: , such that , that means the generator of cannot be the identity element.Computability: , there exists an effective algorithm to compute .Symmetry: , such that .

2.3. BDH Problem

Given , compute , where is a bilinear function, is the generator on , and , are two groups of the same order [30]. Assume the algorithm is used to solve the BDH problem:

2.4. X3DH Algorithm

X3DH [31] is a tripartite key negotiation protocol where the two communicating parties go through a server to achieve asynchronous encrypted communication.

Figure 2 shows the specific design of the protocol. First, Bob registers his public key bundle to the server. When Alice wants to establish communication with Bob, she retrieves Bob’s public key bundle from the server. Then, Alice verifies the prekey signature and performs four Diffie–Hellman key exchanges in the order shown in Figure 3. Finally, she generates the shared key . Bob similarly generates , decrypts the message and Alice’s safety number , and encrypts the message and the locally calculated safety number . The server forwards it to Alice.

Figure 4 shows an example when the protocol is subjected to a MITM attack by a malicious server Trudy. Both parties in the protocol can get the safety number forwarded to each other by the server. However, it is still impossible to determine whether there is a MITM attack based on direct comparison results. Through the original channel comparison, the safety number will still be tampered with by the man in the middle.

2.5. BF-IBE Scheme

The public key of the BF-IBE [16] scheme is determined by the identity, and a trusted third-party PKG generates the private key.Setup: Suppose is the security parameter, is a large prime of -bits, is an additive group, and is a multiplicative group where the order of both groups is , is a bilinear mapping. is a generator of , and are two hash functions where is the length of the message to be encrypted. The PKG picks as the master key and computes the public key . PKG keeps the public system parameter and the secret .Key generation: The public key corresponding to is . The PKG computes the private key .Encryption: The public key of the receiver is . To encrypt , calculate , , .Decryption: For the given ciphertext and the private key , the receiver can decrypt as .

2.6. Hess’s IBS Scheme

The signature scheme used in this paper is Hess’s IBS scheme [32], and Hess gives the security proof of their scheme under the random oracle model. The scheme reduces the number of bilinear pair operations and outperforms Shamir’s scheme [33] and Jae Cha’s scheme [34] in terms of efficiency.Setup: Suppose is a large prime, is an additive group, and is a multiplicative group where the order of both groups is , is a bilinear mapping. is a generator of , and are two hash functions. The PKG picks as the master key and computes the public key . The PKG keeps the system parameter public and secret.Key generation: After the identity verification passes, the PKG computes the public key based on the ID and the corresponding private key .Sign: is the message that needs to be signed, the signer randomly selects and , computes , , and . is the signature for .Verify: After receiving the signature , the verifier computes where . When holds, the signature is valid.

2.7. RIBE Scheme

To make the IBE algorithm support efficient public key revocation, Boldyreva [18] et al. proposed the RIBE scheme. Each user corresponds to two attributes: identity and validity time of the public key, and therefore corresponds to two keys in RIBE: the private key and the key update. The core of RIBE is that only having two private keys can decrypt the message, while the PKG cannot update the key update to the user whose public key has been revoked. We only present the basic definition of RIBE here. For more details, please consult [18].Setup: : is the number of users, is the public parameters, is the master key, is the revocation list, and is the binary tree representing states.Private key generation: : is the identity, is the private key, and the state is updated by this function.Key update generation: : is the validity time and is the key update.Decryption key generation: : If the identity is revoked, then the function outputs ; else outputs the decryption key .Encryption: : is when the encryption occurs, is the plaintext, and is the ciphertext.Decryption: : If the ciphertext is invalid, the function outputs ; else outputs the plaintext .Revocation: : is the identity to be revoked, is the revocation time, and is updated by this function.

3. Scheme Definition

We first define the threat model of our IBE-Signal scheme, then introduce the framework of the whole scheme, and finally present the scheme’s construction in two parts.

3.1. Threat Model

As shown in Figure 5, our model uses one KGC, multiple CPCs, and one Key Authority to replace the single PKG in the BF-IBE model shown in Figure 6. The KGC sets most system parameters, and the CPCs also have the private key share for risk reduction. The Key Authority is fully trusted and only responsible for public key revocation. In addition, our public key revocation feature is optional, and if the user turns it off, the Key Authority will no longer serve him.

We assume that an ambitious adversary can collude with the KGC and n-1 CPCs. In other words, at least one CPC in our scheme is credible. Corrupt KGC/n-1 CPCs can assign the partial private key to any identity submitted by the adversary. The adversary can launch a chosen-plaintext attack and can finally select an to challenge. We allow the adversary to retrieve the partial private key from the KGC and n-1 partial private keys from the CPCs in this case. Before and after the challenge, the adversary can choose a random to query where . Furthermore, we allow the adversary to retrieve the partial private key from the KGC and n partial private keys from the CPCs in this case. This process can be repeated polynomial bounded times.

Even with these capabilities, the adversary has a negligible advantage against our IBE-Signal scheme.

3.2. The Framework of the IBE-Signal Scheme

Like the SSL protocol [35], our IBE-Signal scheme contains parts of the SESSION and the CONNECTION. The SESSION part refers to a collection of parameters and encryption keys generated through a handshake between two communicating parties. In contrast, the CONNECTION part refers to a subsequent session established after the SESSION part using the shared key . The SESSION part is more overhead than the CONNECTION part for the server. Once the SESSION part is established, a user can use a SESSION part context to create the CONNECTION part for the next time. This reduces the communication overhead of the protocol. The SESSION part consists of eight Probabilistic Polynomial-Time algorithms and can be described as . The CONNECTION part consists of four Probabilistic Polynomial-Time algorithms and can be described merely as .

The SESSION part is shown in Figure 7, and the CONNECTION part is shown in Figure 8.

3.3. Scheme Construction

We present the scheme’s construction in two parts, the SESSION and the CONNECTION. Since the scheme uses many symbols, Table 2 provides a table of characters for the reader’s convenience.

3.3.1. SESSION Part

Let be the secure parameter. is the algorithm to generate parameters of BDH, including a prime , an additive group , a multiplicative group of the same order , and a bilinear function .Set up, where i = 0, 1, …, n. Including the following three algorithms, as shown in Figure 9:(1)KGC Setup. This algorithm is run by the KGC: where is a generator of group , is the private key of the KGC, is the public key of the KGC, and is the shared public key of the KGC. are secure hash functions, represents the length of the message key. The system parameter of the KGC is public, while the private key of the KGC is private.(2)CPC Setup, where i = 1, 2, …, n. This algorithm is run by the CPCs:Each CPCi chooses as the private key and computes as the public key, where i = 1, 2, …, n, n is the number of the CPCs.Each CPCi computes as the shared public key. Specially, we define as . For example, the CPC1 can compute with the private key and the shared public key of the KGC. We use this chain from the KGC to the CPCn to compute the shared public key of each entity. It is important to emphasize that when the CPCi-1 sends to the CPCi, then the CPCi must verify the correctness of . Take the CPC3 as an example. The CPC3 verifies by computing and . System parameter of the CPCi is public while the private key of the CPCi is private, where i = 1, 2, …, n.(3)Key Authority Setup. This algorithm is run by the Key Authority:where is the number of users, is the initially empty revocation list, and is the perfect binary tree with ( is even) or ( is odd) leaf nodes representing states. Let be the minimum time interval. System parameter of the Key Authority is public, while the private key of the Key Authority is private. In addition, the following two operations are defined just as [18]. For , set , the Lagrange coefficient is defined as follows:For , , ,In the Setup step, the final public parameter is .Encryption Key Generation, including the following two algorithms:(1)Encryption RootInput Generation. This algorithm is run by the sender:Parse as .where is the receiver’s identity, is the input of the root chain in the Double Ratchet algorithm.(2)Encryption Revocation Key Generation. This algorithm is run by the sender:Parse as .where time is the time when the encryption occurs and is the revocation key. Let be and be .In the Encryption Key Generation step, the final encryption key :Sign, including the following two algorithms:(1)Sender’s Private Key Generation, where i = 0, 1, …, n. The sender runs this algorithm and interacts with the KGC and the CPCs, as shown in Figure 10.Parse as .The sender does the following steps: , , , , where is the sender’s identity and is the blinding factor. We use the blind signature to protect the sender’s partial private key from being obtained by an attacker or server. The sender sends to the KGC. It should be noted that the sender must go through the corresponding identity authentication process, such as password authentication, to get the signed private key, whether interacting with the KGC or the CPCs. Since this is not our focus, this paper has no specific design.The KGC and the CPCs do the following steps: the KGC computes and verifies the correctness of . This ensures that the KGC is issuing the partial private key to . The KGC computes , and sends them to the sender. The sender sends to the CPCi, the CPCi computes and verifies the correctness of , then calculates , and sends them to the sender where i = 1, 2, …, n. After the iterations, the sender can get . The sender extracts the private key by computing , then verifies the correctness of .(2)Signature Generation. This algorithm is run by the sender:Parse as .where is the timestamp used to prevent replay attacks, is the message that needs to be signed, and is the signature. In the SESSION part, can be a fixed format message shown in Figure 11, such as “Hi! I’m Alice.” When Alice friends Bob, a notification is automatically sent when the initial session is established.Encrypt. This algorithm is run by the sender:Let be a secure symmetric encryption algorithm.where C is the ciphertext sent to the receiver.Decryption Key Generation, including the following six algorithms:(1)Receivers Private Key Generation. The receiver runs this algorithm and interacts with the KGC and the CPCs:The function is like Senders Private Key Generation, so we will not go over it here.(2)Decryption RootInput Generation. This algorithm is run by the receiver:Parse as and as .(3)Revocation Private Keys Generation. This algorithm is run by the Key Authority:Parse as .Select an empty leaf node from and store in it. In addition, the Path function is defined as follows: the set of all nodes on the path from the leaf node to the root node, including that leaf node and the root node.(i)(ii)(iii)(iv)(v)After the above code is executed, we get the private keys for revocation and the updated state tree .(4)Revocation Key Updates Generation. This algorithm is run by the Key Authority:Parse as .The KUNodes function is the same as in [18] and is shown in Figure 12:(i)(ii)(iii)(iv)(v)(vi)(vii)(viii)The following code is executed for the nodes that are output by the KUNodes function.(i)(ii)(iii)Then we get the set of the key updates for revocation .(5)Revocation Key Selection. This algorithm is run by the receiver:Parse as and as .(i)(ii)(iii)(iv)(6)Decryption Revocation Key Generation. This algorithm is run by the receiver:Parse as , as and as .In the Decryption Key Generation step, the final decryption key:Decrypt. This algorithm is run by the receiver:Parse as , as . Let be a secure symmetric decryption algorithm.Verify. This algorithm is run by the receiver:Parse as , as . Let be the receiver’s local time.(i)(ii)Revocation. This algorithm is run by the Key Authority:(i)(ii)(iii)

3.3.2. CONNECTION Part

In the CONNECTION part, we show how the first two messages are sent and received in the first session.Sender Key Generation:Parse as , as , as ,Encrypt:Let be a secure symmetric encryption algorithm.Receiver Key Generation:Parse as ,Decrypt:Let be a secure symmetric encryption algorithm.

4. Security Features’ Analysis

This paper selects two features to analyze in detail: resisting MITM attacks and supporting public key revocation.

4.1. Our IBE-Signal Scheme Can Resist MITM Attack

We discussed that MITM attacks cannot be implemented in both the SESSION part and the CONNECTION part.In the SESSION part, mutual authentication exists.To indicate the existence of mutual authentication in the SESSION part, we show a simplified version of our IBE-Signal protocol in Figure 13. Based on the characteristics of the IBE scheme, Alice can get Bob’s public key directly from Bob’s and then encrypt the message by the public key . is a random challenge to Bob’s identity. The only way to get is to have Bob’s private key, which encrypts message as a response to the challenge . This completes the authentication of Bob and is resistant to replay attacks. Authentication of Alice is done by signature and timestamp and prevents replay attacks. A MITM attack is not possible when mutual authentication is established.In the CONNECTION part, launching a MITM attack is ineffective.Since we use the Diffie–Hellman ratchet in the CONNECTION part, an attacker can launch a MITM attack to hijack the session, as shown in Figure 14. However, both parties have a negotiated in the SESSION part, while the attacker has no . The attacker cannot calculate K1 and K2 and naturally cannot send the message .

4.2. Our IBE-Signal Scheme Supports Public Key Revocation

Once the user’s public key expires, the Key Authority will add it to , and the KUNodes function will output a new point set. As shown in Figure 12, the set consisting of red dots is and the set consisting of green dots is . The two sets have no intersection and thus cannot generate the revocation key .

Assume that the encryption time is and the expiration time is . Formula 22 shows that the attacker cannot get using the old revocation key , so the initial session cannot be established.

5. Security Proof

We first prove the correctness of the scheme, then introduce the security model, and subsequently show that the scheme is IND-ID-CPA secure.

Theorem 1. Our IBE-Signal scheme satisfied the correctness property.

Proof. To facilitate the proof, we distinguish the corresponding recipient symbols by adding “’”, e.g. RootInput and RootInput’.

Lemma 1. The SESSION part satisfied the correctness property.

Proof .

Lemma 2. The CONNECTION part satisfied the correctness property.

Proof.

Lemma 3. The Sign&Verify part satisfied the correctness property.

Proof.

5.1. Security Model

It should be noted that the proof of the IND-sRID-CPA security of the RIBE scheme is given in [18], so the revocation key is provided directly by the challenger in the Setup phase of our game. The next game describes the security model of our scheme:Setup. The challenger inputs a secure parameter and outputs public parameters , revocation key , and private keys and where i = 0, 1, 2, …, n. The challenger sends and to the adversary. The challenger controls the following queries and can be queried by the adversary. queries: Given identity , the challenger runs these queries and gives . queries: Given , the challenger runs these queries and gives .Phase 1. The adversary chooses an and sends queries of partial private keys of the . The challenger generates the partial private keys and then sends them to the adversary.Challenge. The adversary outputs two plaintexts , of equal length and the identity intentionally to challenge. The only restriction is that does not appear in any query in Phase 1. The adversary sends , and to the challenger. The challenger randomly chooses as the honest CPC’s serial number and generates the partial private key . The challenger randomly chooses a bit and computes where then sends and to the adversary.Phase 2. The adversary sends queries of partial private keys of to the challenger. The challenger responds in the way of Phase 1.Guess. The adversary outputs his guess . If , the adversary attacks the IBE-Signal scheme successfully.

The adversary’s advantage is defined as the function of the safe parameter :

Theorem 2. Assume H1 and H2 are random oracle models, and the BDH problem is infeasible to solve; our IBE-Signal scheme is semantically secure against IND-ID-CPA attack.

Proof. Expressly, assume the adversary can run at most partial private key queries and queries. Assume can break our scheme in polynomial time with probability ; there must be an adversary that can solve the BDH problem with advantage at least , where , e is the base of the natural logarithm.
Theorem 2 reduces our IBE-Signal scheme to the BDH problem. To prove this reduction, firstly, we reduce the IBE-Signal scheme to a nonidentity-based encryption scheme BasicPub. Then, we reduce the BasicPub scheme to the BDH problem. The transitivity of the reduction is noticeable.

Lemma 4. Assume is a random oracle model from to and the adversary attacks the IBE-Signal scheme with advantage in the IND-ID-CPA game. Assume can run at most partial private key queries. There must be an adversary that can attack BasicPub successfully with an advantage in the IND-CPA game.

Proof. The challenger first constructs the BasicPub scheme. attacks the BasicPub scheme by taking as a subroutine.4.1. Establish the BasicPub scheme.The challenger generates public parameters of the BasicPub scheme.And keeps the key and the partial key private, where i = 0, 1, 2, …, n. The challenger sends to the adversary .4.2. partial private key queries.The challenger randomly chooses as the honest CPC’s serial number, generates the partial private keys , and then sends them to .the following 4.3–4.8 steps, simulates challenger to play IND-ID-CPA game with .4.3. Establish the IBE-Signal scheme. sends the IBE-Signal scheme’s public parametersto . Since of the BasicPub scheme does not contain , needs to construct a 4-tuple to simulate challenger.4.4. queries.(i)(ii)(iii)(iv)(v)(vi)(vii)where represents that thinks will challenge in this query.4.5. partial private key queries – Phase I.This step and step 4.7 can run at most times in total. Assume initiates a query on to and each round of the query is independent.(i)(ii)(iii)(iv)4.6. challenge.Assume challenges . takes from so that .(i)(ii)(iii)(iv)(v)(vi)(vii)(viii)4.7. partial private key queries–Phase II.Phase II is the same as Phase I.4.8. Guess. outputs as his guess and sends it to . sends to the challenger as his guess.

Assertion 1. In the above reduction process, if does not exist, the simulation of is complete.
From Assertion 1, advantage in a simulated attack is equal to that in an actual attack, at least . If attacks the IBE-Signal scheme successfully in step 4.8, can attack the BasicPub scheme successfully.
Since the probability of without interruption is in steps 4.5, 4.7, and in step 4.6. The advantage is at least . Consider is the function of . It can be calculated that when , reaches the maximum.Therefore, the advantage of is at least .

Lemma 5. Assume is a random oracle model from to . The adversary attacks the BasicPub scheme with an advantage and can run at most queries. There must be an adversary that can solve the BDH problem on with an advantage .

Proof. already knows and intends to compute through the attack of on the BasicPub scheme.5.1. generates public parameters of the BasicPub schemeSome parameters of are generated as follows: Let be . randomly chooses as the honest CPC’s serial number and generates , then computes , , , , and .5.2. queries. constructs a 2-tuple . can issue queries at any time and at most times.(i)(ii)(iii)5.3. Partial private key queries. generates the partial private keys , then sends them to .5.4. Challenge. outputs , to challenge. randomly chooses and sends to . Let U be . To decrypt , should compute: issues the queries before decrypting and the BDH problem’s solution will be embedded in .5.5. Guess. outputs . Meanwhile, randomly chooses from and let be the solution to the BDH problem.

Assertion 2. In the above simulation process, the simulation of is complete.

Assertion 3. Let denotes the event: in the above simulation, has issued the query . Then, .

Proof. Obviously, . We know . So,From Assertion 2 and Assertion 3, solves the BDH problem with the probability at least .
From Lemma 4, there is an adversary that attacks the BasicPub scheme with the advantage of at least . From Lemma 5, there is an adversary that solves the BDH problem on with the advantage of at least .

6. Performance Evaluation

We mainly evaluated the performance of our scheme from the computational overhead and the security features. To facilitate the calculation of overhead, we implemented it by calculating and combining cryptographic operations, which is also adopted in [17, 3639]. Moreover, the implementation of the IBE-Signal scheme was based on OpenSSL v1.1.1f and the Type-A curve of the PBC library and was performed on a Dell Inspiron 7580 with Intel Core i7-8565U CPU (1.80 GHz) and 16 GB memory, running Ubuntu 64-bit Linux (v20.04.4 LTS). For the pairing-based scheme, to achieve the 1,024-bit RSA level security, we used the Tate pairing defined over the supersingular elliptic curve with embedding degree 2, where is a 160-bit Solinas prime and a 512-bit prime satisfying . For the ECC-based schemes, to achieve the same security level, we employed the ECC group on Koblitz elliptic curve defined on with and a 163-bit random prime.

6.1. The Computational Overhead of Our Scheme

Table 3 shows the time taken for the cryptographic operations involved in this paper. We define the overhead of modular multiplication as , the overhead of modular inversion as , the overhead of two elliptic curve points addition as , the overhead of elliptic curve scalar point multiplication as , the overhead of exponentiation as , the overhead of one-to-one hash mapping as , the overhead of two-to-one hash mapping as , the overhead of bilinear pairing as , and the overhead of encryption or decryption of the 1 KB size message using AES-128 at CTR mode as . From [17], we have obtained and . Then, we calculated the overheads of , , and separately. In [40], , , and have been given. It has been given in [39] that the overhead of bilinear pairing .

As shown in Table 4, we calculated the number of operations and the computational overhead of each subalgorithm of the IBE-Signal scheme according to Table 3. Among them, the CPCs are selected as ten, and the number of users is selected as 1 billion. The overhead of the SESSION part of our scheme is 3206.45 ms. However, the SESSION part only runs when the two opposing parties communicate for the first time, so a computational overhead of 3 seconds is acceptable. After the SESSION part is established, the CONNECTION part takes only 57.07 ms. Further, if the communication parties are not in the first message in each round of session, the computational overhead can be reduced to 14.5 ms.

The number of CPCs is essential in determining the system's computational overhead. Theoretically, the more the number of the CPCs, the lower the risk of the key escrow problem, but the computational overhead also increases. In Figure 15, we show the relationship between the computational overhead of each subalgorithm and from 1 to 10. Among them, the computational overhead of three subalgorithms CPC Setup, Senders Private Key Generation, and Receivers Private Key Generation increases as increases. In addition to the number of the CPCs, the computational overhead of the two subalgorithms Revocation Private Keys Generation and Revocation Key Updates Generation is related to the number of users . We give the overhead trend as grows in Figure 16, where grows from 1 million to 1 billion. Considering the monthly active users in Table 1, we set the number of users to 1 billion. Furthermore, the algorithm’s time complexity is due to a binary tree structure. This results in a computational overhead of only about 800 ms, even with a billion users.

6.2. Comparison of the Computational Overhead with Other Schemes

In Table 5 and Figure 17, we compare the computational overhead between our scheme and other schemes. Moreover, the comparison mainly focuses on the two stages of Setup and Key Extraction. As shown in Figure 17, the SESSION part overhead of our scheme is lower than the Kumar et al. scheme [17] when the number of the CPCs is less than 8. Even if there are less than 8 CPCs, they can already provide sufficient private key distribution protection. Moreover, the CONNECTION part of our scheme is a constant function for . Our scheme runs the CONNECTION part in most cases, so our scheme is still competitive in computational overhead.

6.3. Comparison of the Security Features with Other Schemes

Table 6 compares our scheme with other schemes in terms of security features. We define Resilient to the Key Escrow Problem as RKEP, Resilient to the Secure Key Issuing Problem as RSKIP, Resilient to the User Slandering Problem as RUSP, Support Mutual Authentication as SMA, Support Perfect Forward Secrecy as SPFS, Support Post‐compromise Security as SPCS, and Support Key Revocation as SKR. The KGC cannot directly generate private keys for users in our scheme, so the scheme has the RKEP feature. The blind signature enables the KGC or the CPCs to issue the private key without seeing the actual information sent by the user, which provides the RSKIP feature for the scheme. The CPCs have a master key slice, which spreads the risk of private key distribution and provides the RUSP feature. Furthermore, we provide the SMA feature by introducing IBS. Since our CONNECTION part is based on the Double Ratchet algorithm, we provide both the SPFS feature and the SPCS feature. Finally, we introduce the Revocable IBE to provide the SKR feature.

7. Conclusion

We have proposed the IBE-Signal scheme to reshape the Signal into a MITM-attack-resistant protocol. Our scheme provides more security features (such as Perfect Forward Secrecy, Post‐compromise Security, and Key Revocation) than other schemes. Furthermore, experiments show that our scheme has less computational overhead when the number of the CPCs is less than 8. Moreover, we proved that our scheme is IND-ID-CPA secure under the random oracle model, even if only one CPC is credible. We increased the attackers’ capabilities in the proofs: some partial private keys of can still be queried in the challenge phase. In the future, we will transform the IND-ID-CPA secure scheme into IND-ID-CCA secure scheme using the Fujisaki-Okamoto method [44].

Data Availability

The data used to support the findings of this study are included within the article.

Conflicts of Interest

The authors declare no known conflicts of interest or personal relationships that could have appeared to influence the work reported in this study.

Acknowledgments

This work was supported by Research Funds for NSD Construction, University of International Relations (2020GA04) and National Natural Science Foundation of China (62102113).