Nothing Special   »   [go: up one dir, main page]

Next Article in Journal
Relationship of Vitamin D Status with Biomarkers of Muscle Damage and Body Composition in Spanish Elite Female Football Players: A Cross-Sectional Study
Next Article in Special Issue
A Reliable Aggregation Method Based on Threshold Additive Secret Sharing in Federated Learning with Quality of Service (QoS) Support
Previous Article in Journal
A Comprehensive Review on Brain–Computer Interface (BCI)-Based Machine and Deep Learning Algorithms for Stroke Rehabilitation
You seem to have javascript disabled. Please note that many of the page functionalities won't work as expected without javascript enabled.
 
 
Font Type:
Arial Georgia Verdana
Font Size:
Aa Aa Aa
Line Spacing:
Column Width:
Background:
Article

Protecting Instant Messaging Notifications against Physical Attacks: A Novel Instant Messaging Notification Protocol Based on Signal Protocol

1
Computer Science Department, King Saud University, Riyadh 11451, Saudi Arabia
2
Center of Excellence in Information Assurance, Riyadh 11451, Saudi Arabia
*
Author to whom correspondence should be addressed.
These authors contributed equally to this work.
Appl. Sci. 2024, 14(14), 6348; https://doi.org/10.3390/app14146348
Submission received: 14 June 2024 / Revised: 14 July 2024 / Accepted: 17 July 2024 / Published: 21 July 2024
(This article belongs to the Special Issue Cryptography in Data Protection and Privacy-Enhancing Technologies)

Abstract

:
Over the years, there has been a significant surge in the popularity of instant messaging applications (IMAs). However, the message notification functionality in IMAs exhibits certain limitations. Some IMAs fail to alert users about new messages after their phone restarts unless they unlock the phone. This is a consequence of end-to-end encryption (E2EE) and the app not knowing the message is in the queue until the app decrypts it. This approach using E2EE is used to prevent offline attacks, as the key is unavailable to decrypt the notification messages. In this paper, we introduce a novel design and implementation of a message notification protocol for IMAs based on the Signal protocol. The proposed protocol aims to securely display notifications on a locked device and ensures that cryptographic keys are stored in a location that is isolated from the user’s device to prevent offline attacks. This approach enhances the security of private key storage, safeguarding private keys against various external threats. The innovative design strengthens the off-site key management system, rendering it resilient against offline attacks and mitigating the risk of key compromise. Additionally, the proposed protocol is highly efficient, requiring no specialized hardware for implementation. It offers confidentiality of cryptographic keys and protection against offline attacks, further enhancing the overall security of the system. We evaluate the protocol’s effectiveness by analyzing multiple independent implementations that pass a suite of formal tests via ProVerif.

1. Introduction

In the area of secure communication, the key management system (KMS) and secure key distribution are crucial components. They are widely used in various sectors of daily life such as communications apps, E-commerce, online banking, online health care systems, entertainment, government, and private sector organizations [1]. The main concern for these sectors is data confidentiality, integrity, and authentication. Data confidentiality prevents unauthorized access, the term data integrity refers to safeguarding against unauthorized alteration of information, and authentication prevents unauthorized entities from impersonating authorized users during communication [2]. For achieving these goals, cryptography plays a vital role; it is mainly the study of algorithms that offer the mentioned services and security goals. Cryptographic algorithms are mainly two types: asymmetric key and symmetric key algorithms. The input key differentiates these algorithms, as for asymmetric key algorithms, different keys are used for encryption and decryption. The encryption and decryption keys of such algorithms are mathematically related. The knowledge of the encryption key does not help to recover the decryption key unless some hard mathematical problems are proven to be solved [3,4,5]. The asymmetric key algorithm resolves the issue of key distribution. However, due to the inherent complexity of asymmetric key operations, their practical use is limited when encrypting large amounts of data [6]. On the other hand, symmetric key algorithms perform the encryption and decryption process in constant time for the input size [7,8]. Therefore, symmetric key algorithms are widely used to provide confidentiality services. Nevertheless, key distribution between the sender and recipient is the main challenge in a symmetric key cryptosystem. In such schemes, the same key is used for both encryption and decryption. Consequently, both parties must share the key through a secure channel before communication. Therefore, secure key management and distribution are crucial aspects of ensuring secure communication.
The importance of key management systems (KMSs) has attracted researchers to design various models that have been presented in the literature [9,10,11,12]. In 1999, Deyar et al. designed an IBM secure coprocessor enriched with various security features and tamper-resistant hardware modules that handle cryptographic operations, safe booting, and secure software with extreme caution [13]. The suggested protocol provides physical protection to cryptographic keys; however, it is impractical for use in portable electronic devices due to its high cost, inconvenient design, and the large amount of resources it consumes. The concept of a remote server connected through a network to conduct private key activities was recommended by MacKenzie, Reiter, Hoover, and Kausik [14,15]. In such a scheme, an attacker would need to breach the server’s security and the user’s password protection to gain access to the private key. According to Hoover, this approach can be utilized to handle the signature verification process. However, MacKenzie and Reiter reiterated in their study that the server assists the device with executing the private key. In practical terms, securing the user’s private key in software is more feasible than deploying tamper-resistant hardware. In both studies, security relies on users trusting the remote server. However, a thorough examination of their studies revealed vulnerabilities to impersonation. For instance, the software smart card was susceptible to impersonation attacks in various real-world scenarios. In various studies, authors have concentrated on the security of digital signature secret keys, including the utilization of human-memorable passwords for encryption. However, due to the low entropy in such schemes, they have proven to be insecure against loss or theft. In 1995, Ganesan presented a method in which the client’s signing exponent is derived from the password [16]. Similar approaches have also been suggested by the same author and are given in [17,18]. In these proposed schemes, multiple parties are involved in sharing a secret key, and one party’s involvement depends on the password. Zhong et al. recommended a similar algorithm in 2005 that used a password-based approach to authenticate with the server and sign messages on behalf of the user [19]. However, since the server has access to the signing key, it may execute offline attacks against the user’s password and sign messages under the user’s name, rendering this approach less secure.
Transport Layer Security (TLS) is widely used for secure communication over the internet. TLS is a hybrid protocol that employs both symmetric and asymmetric key cryptosystems for secure communication and Public Key Infrastructure (PKI) for key distribution and certificates. Another protocol that is tremendously used is Internet Protocol Security (IPsec). The application of IPsec is mostly for secure communication between IP-based networks. It uses a combination of symmetric and asymmetric key cryptosystems and various key management protocols, such as Internet Key Exchange (IKE) and Oakley protocol [20]. These protocols have applications for internet security and are used worldwide; however, they do have limitations. For instance, they may not be applicable to certain types of communication, such as peer-to-peer communication and secure communication between devices with limited resources. In recent years, quantum cryptography has seen tremendous progress in mitigating the threat of fast computation by quantum computers for classical algorithms [21]. Consequently, a new key management and distribution system has been designed based on Quantum Key Distribution (QKD) in this area [22]. QKD uses the principle of quantum computing and is considered a secure algorithm even in the presence of quantum computers, but it has certain limitations due to its complexity and implementation [23].
As discussed, certain existing models have limitations, such as interception during distribution, that may lead to unauthorized access to sensitive information. Furthermore, many of them rely on pre-shared keys or certificates, and their compromise poses a threat to the protocol. Additionally, a limitation of such a protocol is the loss or corruption of the key, which may render the data inaccessible to authorized parties.
Furthermore, protecting IMA notifications against physical attacks is an increasingly critical area of research, given the widespread use of mobile devices and the sensitive nature of the data they often carry. It has seen innovative advancements that focus on context-aware notification management, secure channels, screen obfuscation, proximity-based control, AI-driven behavior analysis, multi-factor authentication (MFA), adaptive filtering, and comprehensive privacy frameworks. Context-awareness leverages environmental and user activity data to intelligently manage notifications, as discussed by Künzler, F et al. [24]. Secure transmission channels using end-to-end encryption, explored by Marforio et al. [25], mitigate interception risks. Screen obfuscation techniques, highlighted by Wang et al. [26], prevent shoulder surfing by dynamically obscuring sensitive content. Proximity sensors control notification display based on user and observer presence, as [27] proposed. AI and machine learning analyze user behavior to predict threats and adjust settings, as demonstrated by Zhang et al. [28]. MFA ensures only authorized access to sensitive notifications, enhancing security, as shown in [29]. Adaptive filtering mechanisms classify and prioritize notifications based on sensitivity and context, as researched in [30]. Lastly, privacy-preserving frameworks integrate these technologies into cohesive systems for robust protection, as detailed in [31]. These approaches collectively enhance the security and privacy of IMA notifications against various physical attack vectors.
Therefore, in this paper, we introduced an innovative key management system that improves the security of off-site key storage against various external threats. Furthermore, we present a notification display on locked devices for Signal messenger, which is a secure messaging application. The proposed system is crafted to securely exhibit notifications to the user on a phone that is locked, and it exhibits a great way for key management that enhances off-site security.
The paper is organized as follows: Section 2 covers the basic definitions and notations used in the paper. Section 3 is devoted to the methodology. A detailed explanation of the proposed key management system is presented in Section 4. A performance analysis of the proposed system is discussed in Section 5. Section 6 concludes the discussion.

2. Preliminaries and Notations

In this section, we discuss the basic definitions and notations used in the proposed scheme. For two-party communication, we use Alice and Bob as the communicating parties. The other notations and definitions used in the paper are given as follows:

2.1. Definition (Keys)

Keys are one of the most important components in cryptography and are used for different purposes, such as signing, encryption, and decryption. In the proposed protocol, various keys are used. We cannot explain all of them due to space limitations; however, remember to note that we use the notation P K n a m e for the public key and S K n a m e for the private key.
To facilitate the sharing of a secret key between Alice and Bob, the Diffie–Hellman (DH) key exchange protocol is employed. Throughout, for this protocol, we use the notation DH ( P K A l i c e , P K B o b ) for the shared secret exchange between Alice and Bob using the Alice and Bob public keys P K A l i c e and P K B o b , respectively. The DH protocol utilized in the suggested scheme is known as X25519 and is based on the cyclic group Curve25519 over an elliptic curve.

2.2. Definition (Curve25519)

Curve25519 employs the prime number 2 255 19 for modulo arithmetic and the Montgomery curve equation y 2 = x 3 + a x 2 + x . For an efficient and fast implementation, the Montgomery ladder is utilized over the projective coordinates of the elliptic curve, ensuring speed and security against side-channel analysis; further detail is give in [32].
In the paper, the output of the 32-byte HKDF algorithm is denoted by KDF. The details of the HKDF algorithm are given in [32]. The input of the HKDF is the concatenation of F and KM, where F represents a 256-bit sequence of ones, and KM is the secret key material. In addition the notation XDH is used for the extended Diffie–Hellman given in [33], and λ is used for the security perimeters.

3. Methodology

The protocol designed in this paper is to ensure that the attacker is unable to retrieve the encryption key whenever it is stored external to the user’s devices. So in this section, before the protocol initiates, we introduce the network model and some underlying assumptions.

3.1. Assumptions

For the implementation of the proposed protocol, we assumed that Alice and Bob have both selected secure and strong symmetric and asymmetric cryptographic primitives and both possess the capability of executing their operation securely. Our second assumption is that both parties have successfully established an open channel for communication.

3.2. Network Model

In the proposed network model, there are four main components: Alice, Bob, the encrypted key, and notification databases. The role of each component is elaborated as follows. The details are also depicted in Figure 1.
  • Alice’s role: From the figure, Alice has the following numbered roles in Figure 1: 1—Alice creates an independent notification database. 2—Alice encrypts sensitive data on her device. 3—Alice stores the encrypted data in the independent notification database. 4—Alice sends the key (that was used for the encryption) to Bob securely using the proposed protocol and deletes the key from her device. The next role of Alice is to receive a notification message from Bob containing her secret key in encrypted form. The notification facilitates the establishment of a shared secret key. The primary purpose of the shared secret key is to enable bidirectional communication in the specified scenario.
  • Bob’s role: The role of Bob is to securely receive a communication message from Alice containing the key she used for encryption. After decrypting the message, Bob sends a notification to Alice containing the key she sent him earlier.
  • Encrypted key: Alice sends Bob the key she used for encryption along with her message in encrypted form and deletes it from her list. Bob stores the key, concatenates it with a new secret, and returns it to Alice in encrypted form.
  • Notification database: In the proposed scheme, an independent database is created to store cryptographic keys when the device is locked. The database is encrypted for data confidentiality and consists of two tables: a receiving table and a sending table, as shown in Figure 2.
    Receiving table: The receiving table consist of Alice’s secret data encrypted with a unique key and the identity public key I D P K B o b of Bob.
    Sending table: The sending table consists of Alice’s identity public key I D P K A l i c e and the key T k e y by which she trusts Bob in encrypted form.

4. Proposed Protocol

In this section, we present the proposed protocol, which is designed to enhance security in off-site key storage. Additionally, we suggest a method supporting self-interactive decryption without requiring user intervention. The protocol is straightforward to use; once the user installs the messaging app, they activate the suggested protocol, which progresses through various stages. Initially, a database consisting of two tables (the receiving table and sending table) is created on the user’s device. Subsequently, a random symmetric key is generated for the user to encrypt their data. The encrypted data are then stored in the receiving table of the database. In the next step, the user sends their key to their contact list and deletes it from their device, aiming to protect the key from offline attacks. Therefore, whenever an entity from the contact list wishes to communicate with the user, they must include the symmetric key that the user utilized to decrypt the received message, which is located in the database. To provide a detailed description, we have divided the protocol into five phases. In the following subsections, we present each phase in detail. For simplicity, we use the names Alice and Bob instead of the user and the communication party.

4.1. Alice’s Session Setup

For Alice’s session setup, Bob needs to provide Alice with his Identity Public Key I D P K B o b , a signature σ with his Sign Public Key S P K B o b for verification, and a one-time pre-key O T P K B o b . In the proposed protocol, Bob should securely upload these keys to the server. Alice retrieves these keys from the server, verifies the signature using Bob’s public key S P K B o b , and performs the other steps outlined in Algorithm 1.
Algorithm 1 Alice’s Session Setup
  Input: ( λ , σ , I D P K b o b , S P K B o b , O T P K B o b ) ▹Inputs Algorithm 1 retrieved from the server
  Output: ( I D P K A l i c e , E P K A l i c e 0 , E P K A l i c e 1 , C 1 )
1:
( I D S K A l i c e , I D K A l i c e ) K e y G e n ( 1 λ )    ▹Alice Identity Public and Private Keys
2:
( E P K A l i c e 0 , E S K A l i c e 0 ) K e y G e n ( 1 λ )   ▹Alice Ephemeral Public and Private Keys
3:
( E P K A l i c e 1 , E S K A l i c e 1 ) K e y G e n ( 1 λ )   ▹Alice Ephemeral Public and Private Keys
4:
D H 1 D H ( I D S K A l i c e , S P K B o b )         ▹Secret 1 exchange through DH1
5:
D H 2 D H ( E S K A l i c e 0 , I D P K B o b ) )         ▹Secret 2 exchange through DH2
6:
D H 3 D H ( E S K A l i c e 0 , S P K B o b )          ▹Secret 3 exchange through DH3
7:
D H 4 D H ( E S K A l i c e 0 , O T P K B o b )         ▹Secret 4 exchange through DH4
8:
S K K D F ( D H 1 | D H 2 | D H 3 | | D H 4 )  ▹Secret Key generated through DH secrets
9:
( R K 0 , C K 0 ) H K D F ( S K , W T )           ▹Root Key and Chain Key
10:
S K 1 D H ( E S K A l i c e 1 , S P K B o b )       ▹Updated Secret Key through DH
11:
R K 1 , C K 1 H K D F R K 0 , S K 1 , W T   ▹Updated Root Key and Chain Key
12:
( K 1 , C K 2 ) K D F C K 1 | | W T   ▹Secret Key for encrypting random key
13:
T k R a n d K e y ( 1 λ )             ▹Randomly generated key
14:
C 0 E N C ( N a m e , T k )   ▹Ciphertext corresponding to the Plaintext “Name”
15:
C 1 E N C ( T k , K 1 )      ▹Ciphertext corresponding to the Plaintext “ T k
16:
Delete T k            ▹Finally, delete the key T k
Algorithm 1 halts and returns nothing if verification of the signature fails. In the other case, it generates private and public identities and ephemeral keys for Alice. The generated keys are then used in the extended Diffie–Hellman algorithm to establish the initial shared secret key between Alice and Bob. The aim of the extended Diffie–Hellman algorithm is to ensure authentication and forward secrecy. Additionally, for the generation of root key R K 0 and chain key C K 0 , the double ratchet algorithm (DRA) [34] is employed, as described in [35]. The use of DRA in the proposed protocol guarantees forward secrecy, confidentiality, and non-repudiation. The DRA operation occurs after establishing the shared secret SK and takes it as input along with any constant value; we use the text WT = “whisper-ratchet” for demonstration to derive the keys R K 0 and C K 0 . The details are illustrated in Figure 3.
Additionally, in Alice’s session setup, she generates new ephemeral key pairs. After the symmetric ratchet, she uses the new ephemeral keys and calculates a shared secret with Bob using Diffie–Hellman (DH). Then she utilizes the shared secret as input for the symmetric ratchet. This process calculates the updated root key and chain key. The significance of this step lies in facilitating a swift recovery in case an attacker gains access to the encryption key. This step ensures that the attacker cannot predict future keys by using the knowledge of previous keys. For more information, see the detailed diagram provided in Figure 4.
In the final stage of the algorithm, Alice calculates a new key K 1 using a symmetric ratchet with the input of the new chain key C K 1 and the WT. She stores the key K 1 and generates a random key T K e y . In the subsequent step, she encrypts the name “Bob” and stores it in her database. Additionally, she encrypts the randomly generated key T K e y using the derived key K 1 and then deletes the key T K e y . The importance of these steps in the proposed protocol is to mitigate the risk of key compromise when Alice is offline or if the device is lost.

4.2. Bob’s Session Setup

Upon receiving Alice’s data, which consist of Alice’s identity public key, two ephemeral public keys, and the ciphertext corresponding to the randomly generated key, Bob follows the steps outlined in Algorithm 2 to establish a shared key between Alice and Bob.
Algorithm 2 Bob’s Session Setup
  Input: ( I D P K A l i c e , E P K A l i c e 0 , E P K A l i c e 1 , C 1 )  ▹Inputs of Algorithm 1 retrieved from the server
  Output: ( T k e y , N T k e y )
1:
D H 1 D H ( I D P K A l i c e , S S K B o b )        ▹Secret 1 exchange through DH1
2:
D H 2 D H ( E P K A l i c e 0 , I D S K B o b ) )       ▹Secret 2 exchange through DH2
3:
D H 3 D H ( E P K A l i c e 0 , S S K B o b )        ▹Secret 3 exchange through DH3
4:
D H 4 D H ( E P K A l i c e 0 , O T S K B o b )       ▹Secret 4 exchange through DH4
5:
S K K D F ( D H 1 | D H 2 | D H 3 | | D H 4 )  ▹Secret Key generated through DH secrets
6:
( R K 0 , C K 0 ) H K D F ( S K , W T )       ▹Root Key and Chain Key through
7:
S K 1 D H ( E P K A l i c e 1 , S S K B o b )        ▹Updated Secret Key through DH
8:
R K 1 , C K 1 H K D F R K 0 , S K 1 , W T   ▹Updated Root Key and Chain Key
9:
( K 1 , C K 2 ) K D F C K 1 | | W T     ▹Secret key for Decrypting random key
10:
T k e y D E C ( C 1 , K 1 )                ▹The Plaintext “ T k
11:
N T k e y =
The steps in Algorithm 2 are the same as those given in Algorithm 1. However, in Bob’s session setup, he uses his private key and the public key received from Alice for the XDH. Since the output of both XDH operations is the same, as both parties use their private key and the other party’s public key, both parties generate the same root keys and chains through symmetric and asymmetric ratcheting. Consequently, Algorithm 2 correctly outputs the key for decrypting the randomly generated key T k e y . The detailed corrective analysis is given in the following Lemma 1.
Lemma 1.
The output T k e y of Algorithm 2 is the same as the randomly generated key T k e y produced by Alice in Algorithm 1.
Proof. 
Assume identical parameters a, b, and p for Curve25519, identical DH, ENC, and  D E C  algorithms, and that  K D F / H K D F  are employed in both Algorithms 1 and 2. Given that the output of Algorithm 1 is the input for Algorithm 2, and Algorithm 1 produces the public parameters  P K A l i c e  corresponding to the private parameters  S K A l i c e  used in XHD, it follows that for all i, where  0 i 3 D H i = D H i . This, in turn, implies  S K = S K . Consequently, for all j, where  0 j 2 , the root key  R K j  and chain key  C K j  are equal, i.e.,  R K j = R K j  and  C K j = C K j . This equality extends to the encryption keys, establishing that  K 1 = K 1 . Given our assumption that both parties employ the same algorithms, it follows that  T k e y = D E C ( C 1 , K 1 ) = D E C ( E N C ( T K e y , K 1 ) , K 1 ) = T K e y .    □

4.3. Sending a Notification

Bob performs the notification-sending phase, during which he sends notifications to Alice whenever Alice is online. The steps for sending the notification are outlined in Algorithm 3. The algorithm reveals that Bob initiates the process by generating public and private ephemeral keys for the session. He then utilizes the generated keys as input for the asymmetric ratchet, producing a key K 2 and a chain key C K 4 . This step ensures that an attacker with the first ratchet key will not be able to obtain the current ratchet key. Subsequently, the algorithm generates a new key, encrypts it with K 2 , outputs a ciphertext along with the details, and sends the notification to Alice. The process is detailed as follows in Algorithm 3.
Algorithm 3 Sending a Notification
  Input: ( λ , E P K A l i c e 1 , R K 1 , T k e y , N T k e y )
  Output: ( C 3 , E P K B o b 2 )
1:
( E P K B o b 2 , E S K B o b 2 ) K e y G e n ( 1 λ )
2:
D H 1 D H ( E P K A l i c e 1 , E S K B o b 2 )
3:
( R K 2 , C K 3 ) H K D F ( R K 1 , D H )
4:
( K 2 , C K 4 ) H K D F ( C K 3 , constant value’)
5:
If  N T key = =
6:
N T k e y R a n d K e y ( 1 λ )
7:
Bundle T k e y | | N T k e y
8:
C 3 E N C ( K 2 , B u n d l e )

4.4. Receiving a Notification

When Alice receives a notification from Bob through a device that is locked with a password or biometric measure, Alice’s device executes the steps outlined in Algorithm 4 to retrieve the key used to encrypt Bob’s name.
Algorithm 4 Receiving a Notification
  Input: ( λ , E P K B o b 2 , R K 1 , C 0 , C 3 )
  Output: ( C 5 , E P K A l i c e 3 )
1:
D H 1 D H ( E S K A l i c e 1 , E P K B o b 2 )
2:
( R K 2 , C K 3 ) H K D F ( R K 1 , D H 1 )
3:
( K 2 , C K 4 ) H K D F ( C K 3 , ’constant value’)
4:
B u n d l e D E C ( K 2 , C 3 )
5:
B o b = D E C ( C 0 , T k e y )
6:
Display notification (Bob)
7:
T k e y = N T k e y
8:
C 4 = E N C ( T k e y , " B o b " )
9:
( E P K A l i c e 3 , E S K A l i c e 3 ) K e y G e n ( 1 λ )
10:
D H = D H ( E P K A l i c e 3 , E P K B o b 2 )
11:
( R K 3 , C K 5 ) H K D F ( R K 2 , D H 1 )
12:
( K 3 , C K 6 ) H K D F ( C K 5 , constant value)
13:
C 5 = E N C ( K 3 , T k e y )
The ciphertext C 0 corresponding to Bob’s name is stored in Alice’s database. The device retrieves the key T k e y for the decryption of Bob’s name and displays the name in the notification heading. The steps for retrieving the old key and generating a new one are given in Algorithm 4.
After displaying the notification, the algorithm updates the key T k e y to the new key N T k e y and encrypts the name of Bob with the new key. The algorithm replaces the old ciphertext C 0 with the new ciphertext C 4 in the database. Subsequently, it generates new ephemeral keys as input for the asymmetric ratchet and creates a new key for encrypting the key T k e y . It then sends the ciphertext corresponding to the plaintext to Bob along with the public ephemeral key E P K A l i c e 3 . Then it deletes the secret key T k e y from Alice’s device. In the receiving a notification algorithm, the implementation of the asymmetric ratchet, forward secrecy, and key removal from the data ensures confidentiality against offline attacks.
Therefore, our support for the self-interactive decryption emphasizes enhancing the user experience by prioritizing intuitive interaction. This protocol is designed to notify users, ensuring that security processes are transparent yet unobtrusive. By allowing users to interact with decryption notifications, they can feel more in control and informed without being overwhelmed or frustrated by constant alerts. The protocol’s user-centric design ensures that the decryption process complements the overall experience, maintaining the balance between security and usability. By focusing on these aspects, we aim to elevate the discussion of user experience in cryptographic applications, highlighting that effective security measures can coexist with user satisfaction and ease of use.
Lemma 2.
The concatenation of T k e y and N T k e y for sending a notification is equivalent to the decryption of the ciphertext C 3 in Algorithm 4.
Proof. 
Assume identical parameters a, b, and p for Curve25519, identical DH, ENC, and D E C algorithms, and that K D F / H K D F are employed in both Algorithms 1 and 2. We know that:
D H 1 : = D H ( E P K A l i c e 1 , E S K B o b 2 ) : = D H ( E S K A l i c e 1 , E P K B o b 2 ) : = D H 1
since in Lemma 1, we proved that R K 1 = R K 1 . This implies that
( R K 2 , C K 3 ) : = H K D F R K 1 , D H 1 : = H K D F R K 1 , D H 1 : = ( R K 2 , C K 3 )
The above equation implies that
( K 2 , C K 4 ) : = ( K 2 , C K 4 )
Thus, the decryption
D E C K 2 , C 3 : = D E C K 2 , E N C ( K 2 , T k e y | | N T k e y ) = T k e y | | N T k e y
   □

4.5. Key Updating

When Bob receives the output of Algorithm 4 from Alice, she deletes her old session key and adopts the new trusted key. The generation of the new trusted key follows the steps outlined in Algorithm 5.
Algorithm 5 Key Updating
  Input: ( E P K A l i c e 3 , C 5 )
  Output: ( T k e y , N T k e y )
1:
D H 1 ( E P K A l i c e 3 , E S K B o b 2 )
2:
( R K 3 , C K 5 ) H K D F ( R K 2 , D H )
3:
( K 3 , C K 5 ) H K D F ( C K 5 ,constant value’)
4:
T k e y D E C ( K 3 , C 5 )
5:
N T k e y =
The algorithm uses the public ephemeral key E P K A l i c e 3 of Alice as input for the asymmetric ratchet and generates the root key R K 3 and chain key C K 5 . It uses the chain key C K 5 with a constant value such as text “message-key send” to obtain the key for decrypting the ciphertext C 5 . The plaintext corresponding to the ciphertext C 5 is the new key that replaces the old key.

5. Security Analysis

In this section, we present the security analysis of the proposed key management protocol. Initially, we theoretically analyze the scheme in terms of its security properties. Additionally, we show that the proposed scheme is secure against offline attacks, which are a major threat to key use for secure communication. Moreover, we introduce a threat model and validate the analysis using an automated validation tool called ProVerif [36].
Lemma 3.
In Algorithm 5, Bob updates the key T k e y given in Algorithm 4.
Proof. 
The proof of Lemma 3 is same as the proof of Lemma 2. □

5.1. Confidentiality

Confidentiality is a security property that protects sensitive data from unauthorized access. In the proposed key management system, the shared secret keys used for message encryption between parties are themselves encrypted. To communicate the key securely, initially, both parties share the secret information through the Diffie–Hellman key exchange combined with the double ratchet algorithm during the Alice and Bob session setup phase. In the Diffie–Hellman key exchange, Curve25519 is deployed, which uses a 255-bit prime and offers 128-bit security when implemented securely; this is considered secure in the absence of a quantum computer. Additionally, the double ratchet algorithm is deployed in the proposed key management system to prevent access to future messages if at some point the key is compromised.

5.2. Authentication and Integrity

The term integrity refers to protecting information from unauthorized changes during communication, while authentication aims to prevent attackers from impersonating authorized users. In the proposed key management system, a digital signature is employed to address both authentication and integrity concerns. The digital signature authenticates the user before communication by utilizing a signing process with both public and private keys. Consequently, this ensures data integrity and prevents unauthorized intruders from impersonating authorized users.

5.3. Resistance against Offline Attacks

In the proposed management system, the key used for communication is transmitted and stored in the database in an encrypted form. In each session, the original key, which is employed for encrypting messages between the parties, is deleted from the database. Therefore, even if an attacker gains complete access to the device and the database, they will not be able to obtain the key in its entirety. Consequently, this strategic approach safeguards the scheme against offline attacks.

5.4. Formal Validation

In the literature researchers have suggested various mechanisms for the validation of security protocols. To formalize security protocols, a mathematical model is necessary, and an active adversary must be capable of calculating its own messages and broadcasting them to the network, impersonating honest participants. For that, many protocol verifiers rely on the symbolic model of cryptography, commonly known as the “Dolev–Yao model”. The formal validation of our protocol is conducted using the ProVerif tool to establish the non-violation of required security properties: particularly, confidentiality, authentication, delivery proof, and replay protection. For clarity, we present our modeling using a high-level Alice and Bob notation. Additionally, we employ the default Dolev–Yao intruder model, enabling the simulation of an intruder with complete control over the network. The messages sent and received by different entities may be intercepted, analyzed, modified (to the extent of known keys), or sent to other entities for comprehensive evaluation. Therefore, to prevent a man-in-the-middle attack, Alice must confirm that the public key she obtained belongs to the intended communication partner. Verification of Bob’s signed key is essential for this purpose. Subsequently, the HKDF technique is employed to implement the symmetric ratchet, ensuring that the output is cryptographically secure. In the first phase, a secret key and some input data—possibly, a constant—are transmitted to the KDF function. The output of the KDF function is another concealed key.
In the subsequent step, this new key separates the next KDF key and the encryption key into two distinct components. This marks the turning of the “ratchet”: a new encryption key is generated while the internal state of the ratchet (the KDF key) is modified. Given the output key, reconstructing the input key of the KDF method is challenging since the algorithm is assume to be cryptographically secure. This means that even if the current state and encryption key are compromised, an attacker cannot recreate older keys. However, they can use the encryption key to decipher a single communication. Additionally, we ensure break-in recovery by varying the input value at each step: if the attacker does not know the input, they cannot infer the ratchet’s subsequent state from merely knowing the present one. Therefore in a session, Bob and Alice ensure confidentiality, integrity, authentication, and forward secrecy.
Furthermore, we conduct a test case (https://github.com/RaghadMarri/Proverif-Key-Trust-Protcol-, accessed on 13 February 2023) as illustrated in Figure 5. This test case confirms that Alice can successfully send the key used to encrypt Bob’s name to Bob. This indicates that an attacker cannot obtain the key entrusted to Bob. Moreover, a test case is used to test whether an intruder can attack an encrypted contact name in the database. We assume that an attacker grants himself full access to an offline device. The test case passes, indicating that Bob’s name is safe from an attacker who has access to it, as shown in Figure 6. This is guaranteed because the key is stored in Bob’s device.

5.5. Threat Model

In the context of a network entirely under adversarial control, we analyze our protocol. Our aim is to demonstrate the high-level characteristics of secrecy and trusted key authentication. Authentication, in this context, is implicit, meaning only the intended party can compute the key, rather than providing explicit evidence. The desired outcomes include the maintenance of secrecy for derived session keys in various compromise scenarios. This includes situations where a long-term secret is compromised but a medium-term or ephemeral secret remains secure, achieving forward secrecy. Additionally, for scenarios where a state is compromised, an uncompromised asymmetric stage follows, resulting in future or post-compromise secrecy. Identity keys and medium-term keys are considered out-of-band verifiable.
  • If the long-term key is compromised and the ephemeral key remains secure, the attacker will be unable to decrypt the secret key T k e y , preventing access to the information.
  • If the ephemeral keys are compromised and the long-term key remains secure, using the long-term key does not retrieve the secret key T k e y .
  • If both the long-term key and the ephemeral keys are compromised, the attacker will obtain the secret T k e y used for encrypting that message session. However, they will not be able to retrieve the next or the previous session keys.

6. Conclusions

In this paper, we presented a key management system aimed at securing off-site key storage against external threats. In the proposed system, a strategic approach is adopted by storing cryptographic keys in a location isolated from the user device. This not only strengthens the key management system against offline attacks but also mitigates the risk of keys being compromised. In addition to the protocol, the Montgomery curve Curve25519 is chosen. The Montgomery ladder method computes point addition in projective coordinates, making the proposed protocol highly efficient. The implementation demands no specialized hardware while providing confidentiality services and robust protection against offline attacks for cryptographic keys. The suggested approach contributes to the overall security and user privacy within the Signal messenger. Moreover, this paper introduces a robust notification display system for Signal messenger. The system ensures secure notification display on a mobile device, requiring biometric measures or a PIN code for access. We analyzed and validated the proposed method in terms of various cryptographic properties and observed that the proposed protocol fulfills all of the security requirements. In future work, we can extend the suggested protocol into a quantum-secure protocol by incorporating quantum-secure primitives and quantum operations.

Author Contributions

Conceptualization, A.A., S.A. (Saleh Almousa), and R.A.; methodology, R.A. and A.A.; software, A.A.; validation, A.A.; formal analysis, R.A.; investigation, R.A. and A.A.; resources, R.A.; data curation, A.A.; writing—original draft preparation, R.A.; writing—review and editing, S.A. (Saleh Almousa); visualization, R.A.; supervision, S.A. (Saad Alahmadi); project administration, S.A. (Saad Alahmadi); funding acquisition, CoEIA. All authors have read and agreed to the published version of the manuscript.

Funding

This research was funded by the Center of Excellence in Information Assurance at King Saud University.

Institutional Review Board Statement

Not applicable.

Informed Consent Statement

Not applicable.

Data Availability Statement

The verification analyses generated during the current study are available in the GitHub repository at https://github.com/RaghadMarri/Proverif-Key-Trust-Protcol-, accessed on 13 February 2023.

Conflicts of Interest

The authors declare no conflicts of interest.

References

  1. Androutsellis-Theotokis, S.; Spinellis, D. A Survey of Peer-to-Peer Content Distribution Technologies. ACM Comput. Surv. 2004, 36, 335–371. [Google Scholar] [CrossRef]
  2. Paar, C.; Pelzl, J. Understanding Cryptography: A Textbook for Students and Practitioners; Springer Science & Business Media: Berlin/Heidelberg, Germany, 2009. [Google Scholar]
  3. Diffie, W.; Hellman, M.E. New Directions in Cryptography. In Democratizing Cryptography: The Work of Whitfield Diffie and Martin Hellman; ACM: New York, NY, USA, 2022; pp. 365–390. [Google Scholar]
  4. Rivest, R.L.; Shamir, A.; Adleman, L. A Method for Obtaining Digital Signatures and Public-Key Cryptosystems. Commun. ACM 1978, 21, 120–126. [Google Scholar] [CrossRef]
  5. Regev, O. New Lattice-Based Cryptographic Constructions. J. ACM 2004, 51, 899–942. [Google Scholar] [CrossRef]
  6. Okamoto, T.; Pointcheval, D. RSA-REACT: An Alternative to RSA-OAEP. In Proceedings of the Second Open NESSIE Workshop, Egham, UK, 12–13 September 2001. [Google Scholar]
  7. Hodjat, A.; Verbauwhede, I. A 21.54 Gbits/s Fully Pipelined AES Processor on FPGA. In Proceedings of the 12th Annual IEEE Symposium on Field-Programmable Custom Computing Machines, Napa, CA, USA, 20–23 April 2004; pp. 308–309. [Google Scholar]
  8. Mahajan, P.; Sachdeva, A. A Study of Encryption Algorithms AES, DES and RSA for Security. Glob. J. Comput. Sci. Technol. 2013, 13, 15–22. [Google Scholar]
  9. Shivaramakrishna, D.; Nagaratna, M. A Novel Hybrid Cryptographic Framework for Secure Data Storage in Cloud Computing: Integrating AES-OTP and RSA with Adaptive Key Management and Time-Limited Access Control. Alex. Eng. J. 2023, 84, 275–284. [Google Scholar] [CrossRef]
  10. Msolli, A.; Ajmi, N.; Helali, A.; Gassoumi, A.; Maaref, H.; Mghaieth, R. New Key Management Scheme Based on Pool-Hash for WSN and IoT. J. Inf. Secur. Appl. 2023, 73, 103415. [Google Scholar] [CrossRef]
  11. Ahmad, S.; Mehfuz, S.; Beg, J. Hybrid Cryptographic Approach to Enhance the Mode of Key Management System in Cloud Environment. J. Supercomput. 2023, 79, 7377–7413. [Google Scholar] [CrossRef]
  12. Dyer, J.; Perez, R.; Smith, S.; Lindemann, M. Application Support Architecture for a High-Performance, Programmable Secure Coprocessor. In Proceedings of the 22nd National Information Systems Security Conference, Arlington, VA, USA, 18–21 October 1999; Volume 73. [Google Scholar]
  13. Hoover, D.N.; Kausik, B.N. Software Smart Cards via Cryptographic Camouflage. In Proceedings of the 1999 IEEE Symposium on Security and Privacy (Cat. No. 99CB36344), Oakland, CA, USA, 9–12 May 1999; pp. 208–215. [Google Scholar]
  14. MacKenzie, P.; Reiter, M.K. Networked Cryptographic Devices Resilient to Capture. Int. J. Inf. Secur. 2003, 2, 1–20. [Google Scholar] [CrossRef]
  15. Ganesan, R. Yaksha: Augmenting Kerberos with Public Key Cryptography. In Proceedings of the Symposium on Network and Distributed System Security, San Diego, CA, USA, 16–17 February 1995; pp. 132–143. [Google Scholar]
  16. Gjøsteen, K. Partially Blind Password-Based Signatures Using Elliptic Curves. IACR ePrint 2013, 2013/472. Available online: https://eprint.iacr.org/2013/472 (accessed on 2 June 2023).
  17. Gjøsteen, K.; Thuen, Ø. Password-Based Signatures. In Proceedings of the European Public Key Infrastructure Workshop, Leuven, Belgium, 15–16 September 2011; Springer: Berlin/Heidelberg, Germany, 2011; pp. 17–33. [Google Scholar]
  18. He, Y.Z.; Wu, C.K.; Feng, D.G. Server-Aided Digital Signature Protocol Based on Password. In Proceedings of the 39th Annual 2005 International Carnahan Conference on Security Technology, Las Palmas de Gran Canaria, Spain, 11–14 October 2005; pp. 89–92. [Google Scholar]
  19. Dierks, T.; Rescorla, E. The Transport Layer Security (TLS) Protocol Version 1.2; No. RFC5246; Internet Engineering Task Force (IETF): Fremont, CA, USA, 2008. [Google Scholar]
  20. Barker, E.; Dang, Q.; Frankel, S.; Scarfone, K.; Wouters, P. Guide to IPsec VPNs; No. NIST Special Publication (SP) 800-77 Rev. 1 (Draft); National Institute of Standards and Technology: Gaithersburg, MD, USA, 2019. [Google Scholar]
  21. Shor, P.W. Algorithms for Quantum Computation: Discrete Logarithms and Factoring. In Proceedings of the 35th Annual Symposium on Foundations of Computer Science, Santa Fe, NM, USA, 20–22 November 1994; pp. 124–134. [Google Scholar]
  22. Scarani, V.; Bechmann-Pasquinucci, H.; Cerf, N.J.; Dušek, M.; Lütkenhaus, N.; Peev, M. The Security of Practical Quantum Key Distribution. Rev. Mod. Phys. 2009, 81, 1301–1350. [Google Scholar] [CrossRef]
  23. Martinez-Mateo, J.; Elkouss, D.; Martin, V. Key Reconciliation for High Performance Quantum Key Distribution. Sci. Rep. 2013, 3, 1576. [Google Scholar] [CrossRef] [PubMed]
  24. Künzler, F.; Kramer, J.-N.; Kowatsch, T. Efficacy of Mobile Context-Aware Notification Management Systems: A Systematic Literature Review and Meta-Analysis. In Proceedings of the 2017 IEEE 13th International Conference on Wireless and Mobile Computing, Networking and Communications (WiMob), Rome, Italy, 9–11 October 2017; pp. 131–138. [Google Scholar] [CrossRef]
  25. Marforio, C.; Karapanos, N.; Soriente, C.; Kostiainen, K.; Capkun, S. Smartphones as Practical and Secure Location Verification Tokens for Payments. In Proceedings of the Network and Distributed System Security Symposium (NDSS), San Diego, CA, USA, 23–26 February 2014. [Google Scholar]
  26. Zhou, Z.; Tang, D.; Wang, W.; Wang, X.; Li, Z.; Zhang, K. Beware of your screen: Anonymous fingerprinting of device screens for off-line payment protection. In Proceedings of the 34th Annual Computer Security Applications Conference, San Juan, PR, USA, 3–7 December 2018; pp. 77–88. [Google Scholar]
  27. Mascetti, S.; Bettini, C.; Freni, D.; Wang, X.S.; Jajodia, S. Privacy-aware proximity based services. In Proceedings of the 2009 Tenth International Conference on Mobile Data Management: Systems, Services and Middleware, Taipei, Taiwan, 18–20 May 2009; pp. 31–40. [Google Scholar]
  28. Zhang, J.; Feng, H.; Liu, B.; Zhao, D. Survey of Technology in Network Security Situation Awareness. Sensors 2023, 23, 2608. [Google Scholar] [CrossRef] [PubMed]
  29. Mostafa, A.M.; Ezz, M.; Elbashir, M.K.; Alruily, M.; Hamouda, E.; Alsarhani, M.; Said, W. Strengthening cloud security: An innovative multi-factor multi-layer authentication framework for cloud user authentication. Appl. Sci. 2023, 13, 10871. [Google Scholar] [CrossRef]
  30. Mehrotra, A.; Hendley, R.; Musolesi, M. PrefMiner: Mining User’s Preferences for Intelligent Mobile Notification Management. In Proceedings of the 2016 ACM International Joint Conference on Pervasive and Ubiquitous Computing, Heidelberg, Germany, 12–16 September 2016; pp. 1223–1234. [Google Scholar]
  31. Togan, M.; Chifor, B.-C.; Florea, I.; Gugulea, G. A Smart-Phone Based Privacy-Preserving Security Framework for IoT Devices. In Proceedings of the 2017 9th International Conference on Electronics, Computers and Artificial Intelligence (ECAI), Targoviste, Romania, 29 June–1 July 2017; pp. 1–7. [Google Scholar] [CrossRef]
  32. Bernstein, D.J. Curve25519: New Diffie-Hellman Speed Records. In Proceedings of the Public Key Cryptography-PKC 2006: 9th International Conference on Theory and Practice in Public-Key Cryptography, New York, NY, USA, 24–26 April 2006; Springer: Berlin/Heidelberg, Germany, 2006; pp. 207–228. [Google Scholar]
  33. Krawczyk, H.; Eronen, P. HMAC-Based Extract-and-Expand Key Derivation Function (HKDF); No. RFC5869; Internet Engineering Task Force: Fremont, CA, USA, 2010. [Google Scholar]
  34. Perrin, T.; Marlinspike, M. The Double Ratchet Algorithm. GitHub Wiki. 2016. Available online: https://kr-labs.com.ua/books/doubleratchet.pdf (accessed on 15 January 2023).
  35. Bienstock, A.; Fairoze, J.; Garg, S.; Mukherjee, P.; Raghuraman, S. A More Complete Analysis of the Signal Double Ratchet Algorithm. In Proceedings of the Annual International Cryptology Conference, Santa Barbara, CA, USA, 15–18 August 2022; Springer Nature Switzerland: Cham, Switzerland, 2022; pp. 784–813. [Google Scholar]
  36. Blanchet, B. Modeling and Verifying Security Protocols with the Applied Pi Calculus and ProVerif. Found. Trends Priv. Secur. 2016, 1, 1–135. [Google Scholar] [CrossRef]
Figure 1. Network model.
Figure 1. Network model.
Applsci 14 06348 g001
Figure 2. Notification database.
Figure 2. Notification database.
Applsci 14 06348 g002
Figure 3. Symmetric ratchet.
Figure 3. Symmetric ratchet.
Applsci 14 06348 g003
Figure 4. Asymmetric ratchet.
Figure 4. Asymmetric ratchet.
Applsci 14 06348 g004
Figure 5. ProVerif output.
Figure 5. ProVerif output.
Applsci 14 06348 g005
Figure 6. ProVerif output (Bob’s name).
Figure 6. ProVerif output (Bob’s name).
Applsci 14 06348 g006
Disclaimer/Publisher’s Note: The statements, opinions and data contained in all publications are solely those of the individual author(s) and contributor(s) and not of MDPI and/or the editor(s). MDPI and/or the editor(s) disclaim responsibility for any injury to people or property resulting from any ideas, methods, instructions or products referred to in the content.

Share and Cite

MDPI and ACS Style

Almari, R.; Almosallam, A.; Almousa, S.; Alahmadi, S. Protecting Instant Messaging Notifications against Physical Attacks: A Novel Instant Messaging Notification Protocol Based on Signal Protocol. Appl. Sci. 2024, 14, 6348. https://doi.org/10.3390/app14146348

AMA Style

Almari R, Almosallam A, Almousa S, Alahmadi S. Protecting Instant Messaging Notifications against Physical Attacks: A Novel Instant Messaging Notification Protocol Based on Signal Protocol. Applied Sciences. 2024; 14(14):6348. https://doi.org/10.3390/app14146348

Chicago/Turabian Style

Almari, Raghad, Abdullah Almosallam, Saleh Almousa, and Saad Alahmadi. 2024. "Protecting Instant Messaging Notifications against Physical Attacks: A Novel Instant Messaging Notification Protocol Based on Signal Protocol" Applied Sciences 14, no. 14: 6348. https://doi.org/10.3390/app14146348

Note that from the first issue of 2016, this journal uses article numbers instead of page numbers. See further details here.

Article Metrics

Back to TopTop