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.
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
, a signature
with his Sign Public Key
for verification, and a one-time pre-key
. 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
, and performs the other steps outlined in Algorithm 1.
Algorithm 1 Alice’s Session Setup |
Input: ,,) ▹Inputs Algorithm 1 retrieved from the server Output: - 1:
▹Alice Identity Public and Private Keys - 2:
▹Alice Ephemeral Public and Private Keys - 3:
▹Alice Ephemeral Public and Private Keys - 4:
, ▹Secret 1 exchange through DH1 - 5:
, ▹Secret 2 exchange through DH2 - 6:
, ▹Secret 3 exchange through DH3 - 7:
, ▹Secret 4 exchange through DH4 - 8:
▹Secret Key generated through DH secrets - 9:
▹Root Key and Chain Key - 10:
▹Updated Secret Key through DH - 11:
▹Updated Root Key and Chain Key - 12:
▹Secret Key for encrypting random key - 13:
▹Randomly generated key - 14:
← ▹Ciphertext corresponding to the Plaintext “Name” - 15:
▹Ciphertext corresponding to the Plaintext “” - 16:
Delete ▹Finally, delete the key
|
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
and chain key
, 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
and
. 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 using a symmetric ratchet with the input of the new chain key and the WT. She stores the key and generates a random key . In the subsequent step, she encrypts the name “Bob” and stores it in her database. Additionally, she encrypts the randomly generated key using the derived key and then deletes the key . 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: ▹Inputs of Algorithm 1 retrieved from the server Output: - 1:
, ▹Secret 1 exchange through DH1 - 2:
, ▹Secret 2 exchange through DH2 - 3:
, ▹Secret 3 exchange through DH3 - 4:
, ▹Secret 4 exchange through DH4 - 5:
▹Secret Key generated through DH secrets - 6:
▹Root Key and Chain Key through - 7:
▹Updated Secret Key through DH - 8:
▹Updated Root Key and Chain Key - 9:
▹Secret key for Decrypting random key - 10:
▹The Plaintext “” - 11:
|
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 . The detailed corrective analysis is given in the following Lemma 1.
Lemma 1. The output of Algorithm 2 is the same as the randomly generated key produced by Alice in Algorithm 1.
Proof. Assume identical parameters a, b, and p for Curve25519, identical DH, ENC, and algorithms, and that 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 corresponding to the private parameters used in XHD, it follows that for all i, where , . This, in turn, implies . Consequently, for all j, where , the root key and chain key are equal, i.e., and . This equality extends to the encryption keys, establishing that . Given our assumption that both parties employ the same algorithms, it follows that . □
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
and a chain key
. 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
, 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: Output: - 1:
- 2:
,) - 3:
- 4:
, constant value’) - 5:
If
⊥ - 6:
- 7:
- 8:
|
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: Output: - 1:
,) - 2:
- 3:
, ’constant value’) - 4:
- 5:
- 6:
Display notification (Bob) - 7:
- 8:
- 9:
- 10:
- 11:
- 12:
constant value) - 13:
|
The ciphertext corresponding to Bob’s name is stored in Alice’s database. The device retrieves the key 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 to the new key and encrypts the name of Bob with the new key. The algorithm replaces the old ciphertext with the new ciphertext in the database. Subsequently, it generates new ephemeral keys as input for the asymmetric ratchet and creates a new key for encrypting the key . It then sends the ciphertext corresponding to the plaintext to Bob along with the public ephemeral key . Then it deletes the secret key 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 and for sending a notification is equivalent to the decryption of the ciphertext in Algorithm 4.
Proof. Assume identical parameters a, b, and p for Curve25519, identical
DH,
ENC, and
algorithms, and that
are employed in both Algorithms 1 and 2. We know that:
since in Lemma 1, we proved that
. This implies that
The above equation implies that
□
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: Output: - 1:
- 2:
) - 3:
,constant value’) - 4:
- 5:
|
The algorithm uses the public ephemeral key of Alice as input for the asymmetric ratchet and generates the root key and chain key . It uses the chain key with a constant value such as text “message-key send” to obtain the key for decrypting the ciphertext . The plaintext corresponding to the ciphertext 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 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 , 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 .
If both the long-term key and the ephemeral keys are compromised, the attacker will obtain the secret used for encrypting that message session. However, they will not be able to retrieve the next or the previous session keys.