Split keys for station-to-station (STS) protocols
Correspondence to: Gizem Akman, Department of Computer Science, University of Helsinki, Helsinki, 00014, Finland. E-mail:
For authentication and key agreement, it is advisable to reduce the risks of key exposure and provide an additional level of control over key usage. This can be achieved by splitting the secret key across several devices, requiring their cooperation to use the key effectively.
We have studied the split-key setting in the context of the station-to-station with key derivation function (STS-KDF) protocol – a well-known two-party authenticated key agreement protocol based on the Diffie-Hellman key exchange and digital signatures – and developed it further. We use the methods of design science, modeling, and formal verification.
First, we have found a new reflection attack against the STS-KDF protocol for scenarios where several entities share the same private key. We designed a modification of that protocol, called STS-KDF with certificate binding (STS-KDF-CB), that includes measures against this attack and enhances user privacy. Second, we designed the STS-KDF-CB with the key encapsulation mechanism (KEM) protocol, where KEM is used instead of the Diffie-Hellman key exchange and digital signatures. Third, we designed split-key variants of the STS-KDF-CB and STS-KDF-CB with KEM protocols. The security properties of the STS-KDF protocol, the STS-KDF-CB protocols, and their split-key variants were formally verified using the ProVerif tool.
We have increased security and privacy for authentication and key agreement by developing new variants of the STS-KDF protocol. In addition, we have STS-KDF variants for the split key setting. Future work includes implementation of the protocols and extension to the case where one of the split-key devices provides attestation for the other.
We are concerned with the usage and storage of cryptographic keys in situations where the keys are vulnerable to exposure, either because they are not protected by the platform security of the underlying hardware or because an attacker may get physical access to the device using the keys.
An example of such a situation is the usage and storage of cryptographic keys in a household network, which typically includes a heterogeneous set of IoT devices that have different levels of platform security. Constrained IoT devices lack sophisticated platform security features. On the other hand, smartphone and personal computer platforms include hardware-based process isolation and secure storage. In addition, these sophisticated devices may also have a hardware-based root of trust, such as a trusted platform module (TPM)  and embedded secure element (eSE) . Another example is when the cryptographic keys are installed in a device, e.g., a wireless base station, or stored in a data center; these keys are vulnerable to physical attacks.
One way to address this issue is to split the key between two or more devices, such that both devices must cooperate when using that key. This mitigates the issue because compromising two or more devices is, in general, harder than compromising a single device. Moreover, the split provides an additional level of control over the key usage, which makes attacks, such as device cloning, more difficult. In the above examples, the key could be split between the constrained IoT device and a smartphone, between the wireless base station and an entity in a more secure location (e.g., in the core network), or between two different computers in a data center.
The station-to-station (STS) protocol is an authenticated key agreement (AKA) protocol with key confirmation that combines the Diffie-Hellman (DH) key agreement  and signature-based authentication of the two parties . Blake and Menezes  have shown that STS is vulnerable to Unknown Key Share (UKS) attacks and proposed a variant, STS with Key Derivation Function (STS-KDF), that prevents these attacks. Jackson et al. have shown using the Tamarin Prover that STS-KDF satisfies the following security properties: key secrecy, identity agreement, and strong session agreement . We chose to study the STS-KDF protocol in the split-key scenario because it is a well-studied and well-known protocol, supports an abstract two-party setting, and has been formally verified. In particular, the STS-KDF protocol is formally shown secure, assuming only minimal properties from the underlying signature scheme.
While designing the split-key variant of the STS-KDF protocol, we have found a new reflection attack on the STS-KDF. This attack is applicable in scenarios where, for privacy reasons, several STS-KDF endpoints use the same key pair.
The key encapsulation mechanism (KEM) is an efficient and provably secure public encryption scheme that generates encrypted random keys by combining asymmetric and symmetric encryption techniques [7,8]. KEM is an umbrella term for several protocols, such as Elliptic Curve Integrated Encryption Scheme-based KEM (ECIES-KEM), RSA-KEM, etc . In the DH key agreement, the shared key is constructed based on the public parameters of the two parties. With KEM, the shared key is generated by one party and sent to the other, encrypted with the public key of the receiver. The security of the DH key agreement is based on the hardness of the discrete logarithm problem. In contrast, KEM is more flexible regarding the used public-key crypto-system and the protocol design. It is possible to construct a KEM from almost any public key primitive . For example, the security of KEM could be based on the hardness of a discrete logarithm problem or another hard computational problem, e.g., the hardness of decoding a general linear code. For these reasons, KEM has become a popular cryptographic primitive, and there are studies to adopt KEM into TLS 1.3. Furthermore, secure KEMs, i.e., indistinguishability under chosen ciphertext attack (IND-CCA) KEMs, can be constructed from weaker public key encryption schemes by applying, e.g., the Fujisaki-Okamoto transform . IND-CCA is the de facto security property for modern public key encryption schemes. Moreover, there exist split-key KEMs . Considering the advantages of KEM presented above, we have designed a variant of the STS-KDF protocol that uses KEM (instead of the DH key agreement and signatures) and a split-key variant of the STS-KDF with KEM.
1. A new reflection attack on the STS-KDF protocol in situations where two parties have the same key pair but different identities.
2. A modification of the STS-KDF protocol: Privacy-Enhanced STS-KDF-CB protocol that mitigates the attack and, in addition, protects the privacy of the user identity. This protocol can be seen as a variant of SIGMA-I protocol .
3. A further variant of the protocol: Privacy-Enhanced STS-KDF-CB with KEM, that uses Key Encapsulation Mechanism (KEM)  instead of Diffie–Hellman key exchange and signatures.
4. The "split-key" variants for the Privacy-Enhanced STS-KDF-CB protocol, with and without KEM, where the asymmetric key pair of one or both of the parties is split between several devices.
5. Automated analysis of protocol models using ProVerif tool  and proofs of the security properties of the above protocols.
The rest of the paper is organized as follows. Section 2 contains the background information on our study and related work. The system and adversary models are defined in Section 3. The reflection attack against the STS-KDF protocol is explained in Section 4. In Section 5, we present the privacy-enhanced variants of STS-KDF that mitigate the reflection attack and their adaptations to the split-key scenarios. The formal verification of the protocols is described in Section 6. The paper ends with the analysis of the performance of the protocols in Section 7 and the discussion in Section 8.
BACKGROUND AND RELATED WORK
In this section, we review the following topics: formal verification tools, secret splitting for authentication, STS protocol, Authenticated Key Exchange (AKE), KEM, and Authenticated Encryption (AE).
Formal verification tools for security protocols
The application of formal methods for the analysis of cryptographic protocol means using automated formal analysis tools to determine whether an attacker can prevent the protocol from achieving its security objectives . Formal methods have proven valuable when developing critical systems, such as protocols, where safety or security is important. In fact, various protocols were believed to be secure for years, and then formal verification showed later that it was not the case. One classic example is the Needham-Shroeder protocol , which was developed in 1978 and later proven to be insecure by Lowe in 1996.
ProVerif uses applied pi-calculus as a formal language, translates the protocol into a set of Horn clauses, and considers an unbounded number of sessions and an unbounded message space for the protocol analysis. The tool can detect attacks. If a protocol property cannot be proven, ProVerif attempts to construct an execution trace that contradicts that property.
Tamarin-Prover offers comprehensive support for modeling and analyzing security protocols. The specification of protocols and adversaries employs an expressive language based on multiset rewriting rules. These rules define a labeled transition system, where the state includes a symbolic representation of the knowledge of the adversary, the messages on the network, freshly generated values, and the state of the protocol. The adversary and protocol interaction involves updating network messages and generating new ones.
Secret splitting for authentication
The internet standard IETF RFC 5026  introduces a split scenario in a model where the entity that provides service is different from the entity that authenticates and authorizes the user, e.g., the network access provider differs from the mobility service authorizer.
Several authentication schemes exist, e.g., biometric verification, text passwords, public key infrastructure, and symmetric-key-based authentication techniques. Multi-tier authentication schemes are more secure than single sign-on, considering layered defense; however, multi-tier authentication schemes increase the complexity of user experience . To reduce the computational overhead in a system with multiple sources of trust, Choi et al. present a new multi-source authentication scheme called Split-Join One-Way Key Chain (SOKC) that stores the parts of the keys in the source nodes .
Shah et al.  and Wang et al.  present a multi-factor authentication with the secret-splitting concept of biometrics, including exclusive-or operations, DH key exchange algorithms, and encryption algorithms. The proposed approaches split the biometric data into two, encrypt both parts, and store one on a smart card and another on a server. The proposed solutions are secure against authentication factor attacks, network attacks, and interior attacks from the card-issuing organization.
Choi et al.  suggest a solution for a certificate-based authentication system using a password and a secondary source, i.e., an honest-but-curious server or another mobile device. In this setup, the user has a secret key to authenticate himself to a controller (a website or an application). To prevent the danger of compromising the device of the user, some secret values are utilized, each of which is used to encrypt their secret key. The secret values are stored in the secondary sources. When the user wants to sign into the controller, he retrieves the secret value from the secondary sources to decrypt the secret key. Therefore, the user can authenticate himself to the controller only with the contribution of secondary sources.
The STS protocol was proposed by Diffie et al.  in 1992 to obtain mutual entity authentication and mutual explicit key authentication . STS is an AKA based on the DH key exchange protocol and authenticated signatures. Diffie et al. provide variants of the STS protocol that have explicit key confirmation by using a symmetric-key encryption scheme and a message authentication code (MAC) . Those variants are called STS-ENC and STS-MAC, respectively, in Blake-Wilson et al. .
Blake-Wilson et al. show that STS-ENC and STS-MAC are vulnerable to UKS attacks . To prevent these attacks, the authors propose to apply the Key Derivation Function (KDF) on the shared DH key. This variant was later named as STS-KDF by Jackson et al. , who also provide formal verification of the variants of the STS protocol by using the Tamarin Prover. They show that STS-KDF is the only variant that satisfies all the following security requirements: key secrecy, identity agreement, and strong session agreement (injective agreement) while using signatures that are secure under the Existential Unforgeability under an Adaptive Chosen Message Attack (EUF-CMA) model.
Next, we describe the STS-KDF protocol. Let Alice and Bob be two parties that use the protocol to agree on a shared key. Each party has a public and a secret key for signature verification and signing, respectively:
Protocol 1: STS-KDF
Setup: 1. (a) Alice chooses random (b) Alice computes her public DH key: 2. Alice sends 3. (a) Bob chooses random (b) Bob computes his public DH key: (c) Bob computes the shared DH key: (d) Bob signs his public DH key, along with the public DH key of Alice, by using his secret signing key: (e) Bob also computes the MAC of the signature by using the shared DH key: 4. Bob sends 5. (a) Alice computes the shared DH key: (b) Alice verifies (c) Alice signs her public DH key, along with the public DH key of Bob, by using her secret signing key: (d) Alice also computes the MAC of the signature by using the shared DH key: 6. Alice sends 7. Bob verifies 8. Alice and Bob compute the shared session key with the shared DH key and identities of Alice and Bob:
Authenticated key exchange
Authenticated Key Exchange (AKE) aims to provide two communicating parties some assurance that they know the identities of each other and share a secret key only known to them . The shared secret key can be used further to provide privacy, data integrity, or both.
Krawczyk  proposes several authenticated DH key exchange protocols under the name SIGMA. These protocols adapt the sign-and-MAC approach using DH key exchange and have been used in Internet Key Exchange (IKE) protocols . The author begins by studying STS protocols and builds the SIGMA protocols upon them. The basic form of SIGMA is similar to STS-KDF. Still, the MAC computation differs from the STS-KDF in that only the certificate or identifier is used as an input instead of the signature, while the MAC key is derived from the DH key. Another variation of SIGMA includes encryption of all the messages except for the public key to provide identity protection.
Krzywiecki et al.  designed an AKE protocol for wearable devices by improving the SIGMA protocol of Krawczyk . Krzywiecki et al.  aim to prevent impersonation attacks by splitting the signing key into two signing modules and renewing the partial keys. They claim that the impersonation attack would be successful only if the attacker captures both partial keys.
Key encapsulation mechanism
A KEM is a public encryption scheme that produces a shared key that can be used for symmetric encryption. The notion of KEMs was introduced by Cramer and Shoup  to build an efficient hybrid encryption scheme with an unrestricted message space.
1. Key Generation is a probabilistic, polynomial-time key generation algorithm that takes a security parameter
2. Key Encapsulation is a probabilistic, polynomial-time encryption algorithm that takes a public key
3. Key Decapsulation is a deterministic, polynomial-time decryption algorithm that takes a ciphertext
The KEM key
Split KEM: Next, we consider KEM in a secret-splitting scenario. Ebina et al. introduced a distributed KEM decapsulation, where the secret key
1. Split Key Generation is a probabilistic, polynomial-time key generation algorithm that takes a security parameter
2. Split Key Encapsulation is a probabilistic, polynomial-time encryption algorithm that takes a public key
3. Split Key Decapsulation is a deterministic, polynomial-time decapsulation algorithm that takes decapsulation key shares
4. Split Key Reconstruction is a deterministic, polynomial-time key generation algorithm that takes the two session key shares
5. Split Key Share Verification is a deterministic, polynomial-time algorithm that takes
We say that
The communication between two parties over a network requires two main security goals: privacy and authentication. Achieving both privacy and authentication at the same time is called authenticated encryption (AE). The three basic ways to achieve AE are (1) MAC-then-Encrypt; (2) Encrypt-then-MAC; and (3) Encrypt-and-MAC .
Since some application settings require associated data, which should be authenticated without encryption, in addition to the authenticated and encrypted data, the notion of AE with associated data (AEAD) is introduced. The AEAD was first formalized by Rogaway et al. in 2002 using the generic composition of a nonce-based, privacy-only encryption scheme and a pseudorandom function .
The National Institute of Standards and Technology (NIST) initiated a standardization process for lightweight cryptography to select one or more schemes for AEAD in 2015 and announced the decision in 2023. The permutation-based AEAD and a hashing scheme named ASCON are chosen to be standardized .
An Authentication and Key Agreement (AKA) protocol typically takes place between two parties. The aim is to establish a key where both parties contribute to deriving a shared secret key. In addition, the protocol should provide authentication, confirming that both entities are who they claim to be. Informally, an AKA protocol should mimic a face-to-face key agreement; a few security properties can capture such a requirement.
We aim to present an AKA protocol that can also be used in split-key settings. The rest of this section covers the split-key scenarios, adversary models, and security properties that we are interested in.
We model the scenario where the secret keys of the users could be split with, e.g., an assistant device. In our model, the users are called Alice and Bob. Alice splits her key into two pieces and distributes each piece in two devices, Alice1 and Alice2, where Alice2 is the assistant device. Alice requires the full cooperation of both Alice1 and Alice2 to use her key, e.g., for digital signature. Similarly, Bob splits his key between Bob1 and Bob2. The following four cases of the split key scenario are illustrated in Figure 2.
Figure 2. Cases of the system model: (ⅰ) no split key; (ⅱ) Alice's keys are split between Alice1-Alice2; (ⅲ) Bob's keys are split between Bob1-Bob2; (ⅳ) both Alice's and Bob's keys are split between Alice1-Alice2 and Bob1-Bob2, respectively.
(ⅰ) No Split Key (Alice-Bob);
(ⅱ) Split Key for Alice (Alice2-Alice1-Bob);
(ⅲ) Split Key for Bob (Alice-Bob1-Bob2);
(ⅳ) Split Key for both Alice and Bob (Alice2-Alice1-Bob1-Bob2).
Note that our secret splitting can be seen as a special case of threshold secret sharing where the threshold
As described in Section 3.1, the system model has two parties, say, Alice and Bob, that communicate over an unsecured channel. When the split key scenarios are considered, the number of parties in the model can be three or four.
We assume that the outsiders are Dolev-Yao adversaries; the attacker (a) can see any message that is sent to the network, (b) is a legitimate user of the network and can start a conversation with other users, and (c) has an opportunity to be a receiver of any initiator of the protocol . In addition to this definition, any message that is sent through the network by legitimate users is assumed to be either created or passed on by the attacker . In brief, the attacker, namely a Dolev-Yao adversary, "can compose messages, replay them, or decipher them if she knows the right keys, but cannot otherwise crack encrypted messages" .
We assume perfect cryptographic primitives, i.e., attackers can decrypt secrets only if they possess the corresponding keys, and hash functions are assumed to be one-way and collision-resistant. Moreover, we consider a more powerful adversary following the extended Canetti–Krawczyk (eCK) model . In particular, the adversary is allowed to compromise some parties, e.g., by physical access or malware in a device . Furthermore, we consider the possibility of the key reveals.
In the following, we give an overview of the main security properties provided by our proposed AKA protocols. For simplicity, we state the security properties in the case of an AKA protocol between two parties, say A and B.
Secrecy: One of the main goals of an AKA protocol is to agree on a cryptographic session key between the participating parties. The protocol is said to achieve session key secrecy if the shared key between A and B at the end of the protocol is not revealed to any malicious third party.
Mutual Authentication: Mutual authentication in an AKA protocol between two parties ensures that both parties are who they claim to be. In other words, mutual authentication is achieved if both sides correctly verify each other's identity.
Forward Secrecy: An AKA protocol satisfying forward secrecy ensures that the compromise of a long-term private key does not compromise past session keys resulting from past AKA executions.
Resistance to Unknown Key Share (UKS) attack: An AKA protocol, say between two parties A and B, is said to be vulnerable to a UKS attack if, by the end of the protocol, A believes that she shares the session key with B, which is the case, while B ends up believing that he shares the key with a party (e.g., the attacker) that is different from A.
Resistance to Key Compromise Impersonation (KCI) attack: A key compromise impersonation (KCI) attack against an AKA protocol is successful if the attacker manages to impersonate a party by compromising a private key.
Identity Confidentiality: An AKA protocol is said to provide identity confidentiality if the protocol protects the parties' privacy, especially their identities.
REFLECTION ATTACK AGAINST STATION-TO-STATION WITH KEY DERIVATION FUNCTION
We consider scenarios where the same secret and public key pairs are assigned to all members in a group, e.g., to protect user privacy. For example, members of a group can be devices belonging to the same production batch. One such scenario with the use of the same attestation key for protecting user privacy is recommended by W3C API specification for Web Authentication  and FIDO Alliance . Based on these recommendations, the Google-certified attestation key pairs for Android hardware-backed keystore are deployed to devices in batches of a minimum of
In these scenarios, it is conceivable that two devices, having the same key pair but different identities, would like to establish a secure communication channel based on that key pair. For example, an Android phone would like to check if it is connected to another genuine Android phone, even in the case where the attestation keys of the two devices are identical. Using STS-KDF for this purpose has the advantage of perfect forward secrecy – if the key pair is compromised in one of the devices, past communications will not be compromised. However, we have found the following reflection attack on STS-KDF in this setting.
Assume Alice and Bob have the same secret key for signing,
As a result of this attack, Alice agrees – allegedly with Bob – on two identical session keys,
Depending on the purpose of the key usage, the reflection attack can cause trouble to Alice and Bob. For example, Alice might be in control of a group of devices, including Bob's device, and give commands to entities in the group. Since Alice thinks she has agreed on a key with Bob, she would send commands and requests to Bob, which would be encrypted with the shared key. Being unaware of the key establishment, Bob would not follow the commands and respond to the requests. For example, the request from Alice could require an immediate response to protect the security of the system, such as destroying data or sending information to another entity, and an unresponsive Bob would put the system in danger. Moreover, if the attacker reflects Alice's messages to Bob back to Alice, then Alice could think that these messages were sent for her, and she might destroy or send her own data.
The attack can be realized independently from the type of signature used in the protocol. Thus, the classification of signature schemes in the paper of Jackson et al.  does not matter for the reflection attack.
Please note that the reflection attack against an STS-KDF protocol also works in the case where each party sharing the same signing key would have individual splits for that same key. Alice's signing key,
In the next section, we will present protocols that can mitigate this reflection attack.
Below, we present four new variants of STS-KDF and their adaptations for the split-key scenarios (see Section 3.1). Our goal is to add the following security properties to the basic STS-KDF (described in Section 2.3): (1) privacy enhancements such that outsiders cannot learn the identities of the parties, (2) protection against the reflection attack described in Section 4, and (3) measures against single-point failures by splitting keys with assistant devices. First, in Section 5.1, we introduce two protocols that provide properties (1) and (2). Then, in Section 5.2, we extend these protocols to the split key case, providing property (3).
New variants of station-to-station protocols
We will now describe two protocols for the "no split-key" setting, depicted as the case (i) in Figure 2: the Privacy-Enhanced STS-KDF-CB protocol and the Privacy-Enhanced STS-KDF-CB protocol with KEM that uses KEM instead of Diffie–Hellman key exchange and signature.
Next, we present Privacy-Enhanced STS-KDF-CB. In this protocol, the DH Key Exchange and the signature scheme are used as in the generic STS-KDF. Second, we adopt the KEM to the STS-KDF-CB protocol to provide flexibility in implementing different cryptosystems.
Privacy-enhanced STS-KDF certificate-binding (STS-KDF-CB) protocol
The Privacy-Enhanced STS-KDF-CB protocol protects against the reflection attack, and the parties can be anonymous toward outsiders because certificates and signatures are encrypted before transmission.
Protocol 2: Privacy-Enhanced STS-KDF-CB
Setup: Alice and Bob choose a safely large prime
The Protocol: (cf. Figure 4). 1.(a) Alice chooses random (b) Alice computes her public DH key: 2. Alice sends 3. (a) Bob chooses random (b) Bob computes his public DH key: (c) Bob computes the shared DH key: (d) Bob signs his public DH key along with the public DH key of Alice by using his secret signing key: (e) Bob applies AEAD on his signature and certificate: 4. Bob sends 5. (a) Alice computes the shared DH key: (b) Alice then decrypts the (c) Alice verifies the certificate (d) Alice signs her public DH key, along with the public DH key of Bob, by using her secret signing key: (e) Alice applies AEAD on her signature and certificate: 6. Alice sends 7. (a) Bob decrypts the (b) Bob verifies the certificate 8. Alice and Bob derive the session key
Privacy-enhanced STS-KDF-CB protocol with KEM
Next, we present the Privacy-Enhanced STS-KDF-CB Protocol with KEM, where we replace both the DH key exchange and the signature scheme with KEM. The certified public keys of the parties are used for the KEM instead of the signature scheme.
In this adaptation, we assume that Alice already knows who she is communicating with; therefore, she has the certificate of Bob when she starts the protocol. Only Alice needs to encrypt her certificate and send it to Bob to prove herself.
Protocol 3: Privacy-Enhanced STS-KDF-CB with KEM
The Protocol: (cf. Figure 5.) 1. (a) Alice generates the key pair (b) Alice knows and has verified the certificate of Bob before starting the protocol, so she knows his public key (c) Alice then encrypts her certificate by using the session key derived above: 2. Alice sends 3. (a) Bob applies the decapsulation function on the ciphertext (b) Bob decrypts (c) Bob applies the encapsulation function on the public key (d) Bob also applies the encapsulation function on the certified public key (e) Bob then derives the shared session key from the session keys: (f) Bob computes the MAC of the ciphertexts and the certificates using the derived key 4. Bob sends the ciphertexts 5. (a) Alice applies the decapsulation function on the ciphertext (b) Alice then applies the decapsulation function on the ciphertext (c) Alice then derives the shared session key: (d) Alice verifies the (e) Alice computes the MAC of the ciphertexts and the certificates using the shared session key 6. Alice sends 7. Bob verifies the
Please note that replacing the DH key exchange in STS-KDF with a KEM can be done as follows. Using the same notations as in Figure 1, a KEM version of STS-KDF is achieved by minor changes at Alice's and Bob's sides. On Alice's side, it is enough to replace generating a random
Similar modifications can be done for the STS-KDF-CB protocol in Figure 4, with the additional change of using the KEM key instead of the DH key in Step 8. This variant would protect against the reflection attack of Section 4.
Figure 4. Privacy-Enhanced STS-KDF Certificate-Binding (STS-KDF-CB) protocol. STS-KDF: station-to-station with key derivation function.
Protocol 4: Split-Key Privacy-Enhanced STS-KDF-CB Setup: ⅰ. Alice and Bob choose a safely large prime ⅱ. Alice1 and Alice2 generate a public key ⅲ. Alice1 gets a certificate for her public verification key
The Protocol: (cf. Figure 6.) 1. (a) Alice1 chooses random (b) Alice2 computes her public DH key: 2. Alice1 sends 3. (a) Bob1 chooses random (b) Bob1 computes his public DH key: (c) Bob1 computes the shared DH key: 4. Bob1 sends the public DH keys, 5. Bob2 signs the DH keys with his secret key 6. Bob2 sends the signature 7. (a) Bob1 also signs the DH keys with his secret key (b) Bob applies AEAD on his signature and certificate: 8. Bob1 sends 9. (a) Alice1 computes the shared DH key: (b) Alice1 then decrypts the (c) Alice1 verifies the certificate, i.e., 10. Alice1 sends the public DH keys, 11. Alice2 signs the DH keys with her secret key 12. Alice2 sends the signature 13. (a)Alice1 also signs the DH keys with her secret key (b) Alice1 applies AEAD on her signature and certificate: 14. Alice1 sends 15. (a) Bob decrypts the (b) Bob verifies the certificate, i.e., 16. Alice and Bob derive the session key
Split-key settings for station-to-station protocol
In this section, we adopt the privacy-enhanced variants of STS-KDF-CB to the setting in case (ⅳ) of Figure 2, where both of the parties of the protocol have split keys. By splitting the keys, we aim to protect the security of the key if the device is compromised since compromising two or more devices is harder than a single device.
In these split-key protocols, neither Alice nor Bob is aware that the other party has a split key. The protocols for the hybrid cases (ⅱ) or (ⅲ) in Figure 2 can be constructed by combining a split-key protocol from this section with the corresponding protocol from Section 5.1 above.
Split-key privacy-enhanced STS-KDF-CB protocol
Next, we present the split-key variant of the Privacy-Enhanced STS-KDF-CB Protocol.
Split-key privacy-enhanced STS-KDF-CB with KEM
Next, we present how we adopt the split-Key KEM construction (see Section 2.5) to the privacy-enhanced STS-KDF-CB with KEM.
Protocol 5: Split-Key Privacy-Enhanced STS-KDF-CB with KEM Setup: ⅰ. Alice1 and Alice2 apply ⅱ. Alice1 gets a certificate for her public key
The Protocol: (cf. Figure 7.)
1. (a) Alice1 generates key pair (b) Alice1 has the certificate of Bob before starting the protocol, so she knows his public key (c) Alice1 then encrypts her certificate by using the session key derived above: 2. Alice1 sends 3. Bob1 sends 4. Bob2 applies the split decapsulation function on the ciphertext 5. Bob2 sends the key part 6. (a) Bob1 first verifies that the key part he received from Bob2 is derived by using the correct secret key: (b) Bob1 then applies the split decapsulation function on the ciphertext (c) Bob1 applies the split reconstruction function on the key parts (d) Bob1 decrypts (e) Bob1 applies the encapsulation function on the public key (f) Bob1 also applies the split encapsulation function on the certified public key (g) Bob1 then derives the shared session key from the derived keys above and the certificates: (h) Bob1 computes the MAC of the ciphertexts and the certificates using the derived key 7. Bob1 sends the ciphertexts 8. Alice1 applies the decapsulation function on the ciphertext 9. Alice1 sends 10. Alice2 applies the split decapsulation function on the ciphertext 11. Alice2 sends the key part 12. (a) Alice1 first verifies that the key part she received from Alice2 is derived by using the correct secret key: (b) Alice1 then applies the split decapsulation function on the ciphertext (c) Alice1 applies the split reconstruction function on the key parts (d) Alice1 derives the shared session key from the derived keys above and the certificates: (e) Alice1 verifies the (f) Alice1 computes the MAC of the ciphertexts and her certificate with the certificate of Bob using the shared session key 13. Alice1 sends 14. Bob1 verifies the
STS-KDF was formally verified by Jackson et al.  using the Tamarin Prover. They have proved that this protocol satisfies key secrecy, identity agreement, and strong session agreement (injective agreement) while using the EUF-CMA signature.
We have used the ProVerif tool  to model STS-KDF and the protocols that we have presented in Section 5 and prove their security properties. In addition, we have modeled the possibility of sharing the same private key between different parties in order to capture the reflection attack, introduced in Section 4, for STS-KDF. Then, we have shown that the Privacy-Enhanced STS-KDF-CB protocols are not vulnerable to this reflection attack.
We will now explain how we constructed the formal models of the protocols and their security properties and present the verification results. The source codes of the formal verifications of the protocols are publicly available on GitHub .
Modeling the protocols
The ProVerif model is constructed in three parts: declarations, process macros, and main process.
The cryptographic primitives are formalized using declarations, which are a finite set of types, free names, and constructors (functions) . We have used the following primitives, for which examples of constructions are given in the ProVerif manual : symmetric encryption, MAC, DH Key Exchange, digital signature, and AEAD. In addition, we have modeled the following primitives, some of which have been used in our earlier work.
Split-Key Digital Signatures: In addition to the digital signatures, we have added a function for reconstructing the split secret keys. We then defined split signing functions for the parties in the protocol who want to collectively create digital signatures:
The equation below defines that the result of the reconstruction of split signatures should be the same as the result of the message signed with the reconstructed key. This equation is important, especially in scenarios where one party splits her key while the other party does not, as described in cases (ⅱ) and (ⅲ) of the split key scenarios in Section 3.1.
Key Encapsulation Mechanism (KEM): The KEM is modeled using the following five functions: key generation, encapsulation, KEM key derivation, ciphertext generation, and decapsulation of the KEM key. It is important to recall that the encapsulation algorithm is a probabilistic algorithm with two outputs, the ciphertext and the KEM key; thus, we model the two outputs with two separate functions: KEMkey and KEMCipher, taking randomized public encryption as input, i.e., output of Encaps function:
The equation below ensures that the key generated during encapsulation (
Split Key Encapsulation Mechanism (Split KEM): In addition to the functions that are defined for KEM, we added functions for split key generation, key share verification, and reconstruction of the key shares, which are the outputs of split decapsulation:
The reduction below ensures the verification of valid splits. The equation, in the end, ensures that the key generated during encapsulation (
The process macro consists of sub-processes such that different sub-processes are defined for different parties in the protocol in order to ease the development: Privacy-Enhanced STS-KDF-CB Protocol (Section 5.1.1) and Privacy-Enhanced STS-KDF-CB with KEM Protocol (Section 5.1.2), have two parties, say Alice and Bob. Split-Key Privacy-Enhanced STS-KDF-CB Protocol (Section 5.2.1) and Split-Key Privacy-Enhanced STS-KDF-CB with KEM Protocol (Section 5.2.2) have two additional parties, say Alice2 and Bob2. In ProVerif models, we created a sub-process for each party.
Finally, the protocol is encoded as a main process using the process macros. Next, we explain the main processes of the protocols of Section 5. We model the CA by simply generating secret and public
Protocol 1: STS-KDF: The main process creates secret-public signing and verification keys for CA, Alice, and Bob.
Protocol 2: Privacy-Enhanced STS-KDF-CB: The main process of Protocol 2 has the same main process as Protocol 1.
Protocol 3: Privacy-Enhanced STS-KDF-CB with KEM: The main process of Protocol 2 differs from Protocol 1 only when creating secret and public keys:
Protocol 4: Split-Key Privacy-Enhanced STS-KDF-CB: This protocol has two more parties participating, and the main process is prepared accordingly:
Protocol 5: Split-Key Privacy-Enhanced STS-KDF-CB with KEM: The setup of the main process of Protocol 5 is similar to Protocol 4, except for generating split keys for asymmetric encryption. In addition, in this protocol, a verification key for Split-KEM is generated for Alice1 and Bob1:
A query is a statement about a security property that is wanted to verify. It is used to express a specific security property or behavior that is expected by a protocol or system to satisfy.
Next, we list the queries that we have constructed to verify the security properties. Note that the protocols with KEM do not have queries for DH key
Secrecy: We want to prove the secrecy of the key that is derived during the protocol run. Therefore, we constructed the following queries:
Mutual Authentication: In ProVerif, the correspondence is defined for two events,
Forward Secrecy: To prove forward secrecy we use phases. We leak the long-term secret keys after the initial run of the protocol (phase 1) and show the secrecy property of the session that took place before the leak
Resistance to Unknown Key Share (UKS) attack: In order to construct queries for proving the resistance to UKS attacks, we use the events that are used to prove mutual authentication so that if these events occur for the same key, then the identities of the parties should be same. We check the UKS attack resistance for the keys
Resistance to Key Compromise Impersonation (KCI) attack: We want to verify that the protocol is resistant to KCI attacks by leaking the secret keys in the main process. Consequently, if the secrecy and correspondence queries remain true, then we conclude that the protocol is resistant to KCI attacks:
When KCI resistance is checked, these lines should be replaced with the corresponding lines in the main process.
Identity Confidentiality: The identity confidentiality of the users against outsiders can be verified by the notion of observational equivalence, see  Section 4.3.2. When we check the observational equivalence of Bob, we ask ProVerif to choose an identity for Bob while we assign a new identity to Alice. Note that
Note that the certificates, and, therefore, the identities, are already public. While creating certificates, we send the certificates that are made for Alice, Bob1, and Bob2 to the public network. However, we also create another certificate for chosen Bob, which should be the same as the certificate of either Bob1 or Bob2, and we send this certificate to Bob via a private channel. In addition, in our protocols, the certificates are sent in an encrypted form.
Formal verification results
After introducing how to construct the model for formally verifying the protocols, we now explain the results of the formal verification. We will start with the security properties of the STS-KDF protocol (Protocol 1) and then continue with the security properties of the other protocols when they differ from those of the STS-KDF protocol. A summary of the formal verification results is given in Table 1 and Table 2.
Summary of ProVerif results. Protocol 1: STS-KDF, Protocol 2: Privacy-Enhanced STS-KDF-CB, Protocol 3: Privacy-Enhanced STS-KDF-CB with KEM, Protocol 4: Split-Key Privacy-Enhanced STS-KDF-CB, and Protocol 5: Split-Key Privacy-Enhanced STS-KDF-CB with KEM. N/A: not applicable. true*: true if only the key of the assistant device is leaked
|Security Properties||Protocol 1||Protocol 2||Protocol 3||Protocol 4||Protocol 5|
|Mutual Authentication on
|Mutual Authentication on
|Resistance to UKS Attack on
|Resistance to UKS Attack on
|Resistance to KCI attack||false||false||false||true*||true*|
|Resistance to the Reflection Attack||false||true||true||true||true|
Summary of ProVerif results for identity confidentiality of user identities. true**: true with implicit rejection
|Protocol 1: STS-KDF||false||false|
|Protocol 2: Privacy-Enhanced STS-KDF-CB||true||false|
|Protocol 3: Privacy-Enhanced STS-KDF-CB with KEM||true||true**|
|Protocol 4: Split-Key Privacy-Enhanced STS-KDF-CB||true||false|
|Protocol 5: Split-Key Privacy-Enhanced STS-KDF-CB with KEM||true||true**|
The identity confidentiality results vary depending on users. Table 2 presents the ProVerif results for identity confidentiality of user identities.
The following is the explanation of security properties that we get from ProVerif results.
Mutual authentication on
Mutual authentication on
Forward Secrecy: The STS-KDF protocol has forward secrecy. The leak of the secret keys of Alice, Bob, and CA does not help the attacker recover the session keys derived during earlier sessions.
Resistance to Unknown Key Share Attack on
Resistance to Unknown Key Share Attack on
Resistance to Key Compromise Impersonation (KCI) attack: When the secret keys of Alice and Bob are leaked at the beginning of the protocol, the secrecy of the keys and the mutual authentication between Alice and Bob on
Identity Confidentiality: The certificates are sent in plaintext in the protocol; therefore, identity confidentiality is trivially not true for STS-KDF.
Next, we highlight the differences in security properties between STS-KDF and the protocols developed in this paper.
Privacy-Enhanced STS-KDF-CB protocols (Protocols 2, 3, 4, and 5) provide identity confidentiality so that the identities of the parties are not captured by outsiders and passive attackers. However, if the attacker starts Protocols 2 and 4 by sending the first message containing his public key to Bob, then Bob derives the shared DH key (
A limitation of our ProVerif model is that it cannot detect information exposure through error messages. However, the attacker could learn the identity of Bob with this kind of information exposure in Protocols 3 and 5. For example, the attacker replays Message (2) of Protocol 3 in Figure 5. If the ciphertext
In Privacy-Enhanced STS-KDF-CB protocols, parties check the certificate of the other party so that they do not receive their own certificates. They do this check by executing
Privacy-Enhanced STS-KDF-CB with KEM (Protocol 3) and Split-Key Privacy-Enhanced STS-KDF-CB with KEM (Protocol 5) protocols achieve mutual authentication for the key
Note that the queries related to
Considering Protocols 2 and 3, when the secret key of Alice is leaked at the beginning of the protocol, the secrecy of Bob's key and injective correspondence of Bob for Alice on
In a split-key setting (Protocols 4 and 5), a KCI attack is unsuccessful only if the secret keys of Alice2 and Bob2 are leaked. However, the cases for Alice1 and Bob1 are similar to those of Alice and Bob in Protocols 2 and 3.
Construction of reflection attack in ProVerif
In Section 4, we have explained that the reflection attack happens in a setting where the parties in the protocol have the same secret key but different identities and, therefore, different certificates. In order to capture the reflection attack in ProVerif, we have modified the protocol such that (ⅰ) only one secret key is created and assigned to the parties, (ⅱ) the certificates are created with different identities but the same public key, and (ⅲ) we allow that Alice and Bob can be both initiator and responder in the protocol.
In this setting, we could capture the reflection attack against STS-KDF in ProVerif. When the protocol model is executed, the mutual authentication for the DH key returns false. The traces captured from the query,
ProVerif proved that the reflection attack is not successful when a similar setting is applied to Privacy-Enhanced STS-KDF-CB and Privacy-Enhanced STS-KDF-CB with KEM protocols.
In this section, we analyze the computational cost, communication overhead, and resource requirement of the protocols presented in Section 5. While doing the analysis, we have selected the following cryptosystems, which are currently popular, to improve the readability by presenting concrete results.
● Diffie-Hellman Key Exchange: Elliptic Curve Diffie-Hellman (ECDH) with the curve P-256.
● Digital Signature Scheme: Elliptic Curve Digital Signature Algorithm (ECDSA) with curve P-256.
● Public Key Primitive for KEM: Elliptic Curve Integrated Encryption Scheme (ECIES) with curve P-256.
● Certificate: X.509 certificate.
● Symmetric Key Encryption: Advanced Encryption Standard (AES-128).
● Message Authentication Code: HMAC-SHA-256.
● Authenticated Encryption: AES-128-HMAC-SHA-256.
Next, we present the computational cost of the protocols in Table 3. We gathered all the operations under three titles: (ⅰ) scalar multiplication for elliptic curves, (ⅱ) modular inverse, and (ⅲ) symmetric key operations, which include symmetric encryption, symmetric decryption, hash, key derivation function, and random number generation.
Computational cost of the protocols from Section 5
|Protocols||Scalar Multiplications||Modular Inverses||Symmetric Key Operations|
|(4) Split STS-KDF-CB||16||12||18|
|(5) Split STS-KDF-CB-KEM||14||2||21|
As we can see from Table 3, the proposed protocols do more computations than STS-KDF (1). This is because, for example, STS-KDF-CB (2) and Split STS-KDF-CB (4) have additional encryption and certificate verification compared to STS-KDF. We also observe that Protocols (3) and (5), where we use KEM instead of DH key exchange and digital signature, are computationally less complex than Protocols (2) and (4). Even though the number of symmetric key operations increased, the total number of computationally heavier scalar multiplication and modular inverse functions decreased.
Comparing protocols STS-KDF-CB (2) and STS-KDF-CB-KEM (3) with Split STS-KDF-CB (4) and Split STS-KDF-CB-KEM (5), respectively, we see that the additional cost of the split-key variant (4) is two extra signatures, while the additional cost of the split-key variant (5) is two extra decapsulations. In conclusion, the split-key Protocols (4) and (5) are not much more computationally heavier compared to Protocols (2) and (3).
Table 4 presents the communication overhead of the messages sent in the protocols. Please note that split key protocols have more messages.
Communication overhead of the messages (in bytes) in the protocols from Section 5. A1: Alice1, A2: Alice2, B1: Bob1, B2: Bob2. The order of parties represents the direction of messages; e.g., A1-B1 means that the message is sent from Alice1 to Bob1
|(4) Split STS-KDF-CB||32||64||64||224||64||64||192||968|
|(5) Split STS-KDF-CB-KEM||292||32||32||96||32||32||32||548|
According to the cryptosystem choices mentioned earlier, we assume that the public and secret keys in elliptic curves have a length of 32 bytes. Therefore, signatures are 64 bytes long. We estimate the certificate length to be 228 bytes; this includes a public key (32 bytes), signature (64 bytes), and other information (132 bytes). Recall that HMAC-SHA-256 creates a 32-byte output. AES-128 creates a ciphertext of the same size as the plaintext. In our case, the plaintext consists of a signature and certificate; therefore, the ciphertext has a length of 292 bytes. The authenticated encryption adds 32 bytes of MAC to the ciphertext. Thus, for example, we get 324 bytes of ciphertext in Protocols (2) and (4) in the message sent from Alice1 to Bob1. The message from Bob1 to Alice1 includes the ciphertext and the public key of Bob. Thus, the length of that message is 356 bytes.
Observe that the total communication overhead of Protocols (1) and (2) are the same. Therefore, we conclude that adding privacy does not increase the communication overhead.
Note that the first message of protocol (3) is larger than Protocols (1) and (2), but the other messages are much smaller. Thus, replacing DH key exchange and digital signature with KEM decreases the total communication overhead by around 40%.
The total communication overhead increases for split-key variant of STS-KDF-CB by around 35%, and for split-key variant STS-KDF-CB with KEM by around 30%.
We have implemented STS-KDF-CB with KEM in Python with Cryptography package version 41.0.3 . Measurements were taken with a computer with 3.5 GH dual-core Intel i7 and 16GB RAM. With references to Figure 5 for step numbers, we present the average computation time of the protocol in Table 5.
Average computation time of STS-KDF-CB-KEM (in ms), referring to Figure 5
|Step 1||Step 3||Step 5||Step 7||Total|
From Table 5, we can observe that an STS-KDF-CB Protocol with KEM runs in less than 20 ms, ignoring the communication time between the parties. As we can see in Table 3, splitting keys in KEM increases the number of computations slightly. Therefore, we can estimate that the Split STS-KDF-CB Protocol with KEM could take around 30 ms, again ignoring the communication time between the parties. The implementations of other protocols are left for future work.
The protocols, described in Section 5 and analyzed in Section 7, add several security properties to the basic STS-KDF. The system designer could decide which protocol to choose based on the desired properties. For example, STS-KDF-CB and STS-KDF with KEM protocols provide additional privacy and protection against reflection attack, while split-key protocol variants also provide measures against single-point failures by splitting keys with assistant devices. In the KEM variants of the protocols, there is flexibility in the choice of any type of KEM and Split-KEM.
As verified by ProVerif, the protocols we propose in Section 5 are privacy-enhanced, which is mainly because the certificate and the signature are encrypted. The certificates are encrypted to provide identity confidentiality to the user by concealing the identity against the passive attackers. The signatures are also encrypted because otherwise, the attacker could run a brute-force attack with a list of public keys to figure out who the sender of the message is. If identity confidentiality is not a concern, the encryption in the protocols could be removed.
In addition, an active attacker can learn the identity of Bob in Protocols 2 and 4 if the attacker starts the protocol. This can be prevented in Protocols 3 and 5 due to the assumption that Alice already knows Bob's certificate. However, Information Exposure Through an Error Message could reveal to the attacker that if the decapsulation in Step 3.a of Figure 5 fails, the attacker understands Bob does not own the public key that was used to create
In our modification to the STS-KDF protocol, we are using certificates as inputs to the key derivation function instead of identities. One reason is that the same identity might occur in several certificates, e.g., for different devices controlled by the same user. Then, two devices with the same identity may still need to authenticate each other and exchange keys. Another reason for using certificates instead of identities is a case where identity is not relevant at all, while the certificate would technically act as a replacement for an identity.
As mentioned in the introduction, splitting the secret key between two or more devices has security benefits, such that those devices must cooperate when using the key. On the other hand, key usage and management are more complicated in the key-split setting. The usage of split keys is illustrated in Protocols 4 and 5 in Section 5. We will next discuss the different options for creating and certificating the long-term key pair
In the basic setting, where Alice is a single entity, the certification of the long-term key pair happens as follows. Alice generates a key pair
In some scenarios, the key pair generation can be done by the trusted CA instead of by Alice. For example, in a secure factory environment, the key pair and the certificate can be generated by the manufacturer's CA and directly injected into the device. In this scenario, the identity verification step can be omitted.
In the case where there are two entities, Alice1 and Alice2, one of them, say Alice1, generates a key pair
In another option, the key shares can be generated by Alice1 and Alice2 using a secure multi-party computation. As a result of this protocol Alice1 gets
In summary, the key pair
In a non-split-key case, it is critical to revoke
Under certain circumstances in split-key cases, it is secure to continue the usage of original
Recall that the STS protocol is an AKA based on the DH key exchange protocol and authenticated signatures. Various modifications of the STS protocol were introduced to improve its security. The study by Jackson et al.  extensively analyzes the STS variants and concludes that STS-KDF is the only variant that satisfies key secrecy, identity agreement, and strong session agreement (injective agreement). The same study shows that STS-KDF is secure against UKS attacks and provides mutual authentication of shared DH key. We formally verified that STS-KDF has perfect forward secrecy. The protocols that we introduce in Section 5 mostly provide resistance to the KCI attack and mutual authentication of shared key
Shah et al.  and Wang et al.  use the secret-splitting concept for multi-factor authentication where they split, e.g., biometric data. The solutions presented in these two papers include servers for keeping one of the shares of the secret. However, our solution is independent of a Trusted Party.
Our STS-KDF-CB Protocol in Section 5.1.1 can be seen as a variant of SIGMA-I protocol . Our protocol differs from the original SIGMA-I in using certificates, identities, and encryption. Our protocol is Certificate-Binding STS-KDF, which means that the shared session key includes the certificates of the participants. Recall that the same identity may be included in several certificates, e.g., with different capabilities. We also apply authenticated encryption on the signature and certificate, while SIGMA-I does not provide authenticated encryption because MAC is only applied to the identity of the user, not to the plaintext or ciphertext. Finally, we introduce the certificate verification upon arrival of the certificate such that the user checks that the received certificate does not belong to himself. By doing this, we aim to prevent replay attacks.
We emphasize that both the original STS and the SIGMA-I protocols use signatures for authentication. In our split and non-split STS-KDF-CB protocols with KEM, we achieve our desired security goals by using KEMs instead of signatures. We argue that KEM operations are typically computationally less costly than signing operations.
Krzywiecki et al.  present an AKE for wearable devices, such as a watch and a mobile phone, in which the key of a device is split between two signing modules in the same device. This is similar to our Split STS-KDF-CB Protocol in Section 5.2.1, but their setting has several limitations compared to ours. First, in our setting, the initiator and the responder do not have to know the public keys of each other, while Krzywiecki et al. assume they do. Second, in our setting, the channel between the devices holding the key shares is public. In Krzywiecki et al., the channel between the signing modules is internal to a device and is secure. Also, our protocol does not require human interaction to complete. The setting of Krzywiecki et al. includes an out-of-band channel between the initiator and the responder, and human interaction is required to establish the connection at the end of the protocol. Our formal security proof does not make any assumption about the used cryptographic primitives, such as KEMs, signatures, and authenticated encryption. The solution of Krzywiecki et al. is based on signatures, and their security proof is specific to the Decisional DH problem and Schnorr split signatures.
Recall that the key management with split-key cases is more complicated since there are more parties involved. One limitation of our key-split setting is the following. If Alice1 is fully compromised, but the user does not notice it, then the key split does not help because Alice2 will cooperate with the attacker who controls Alice1. On the other hand, if the user can detect the compromise, they could turn off the device Alice2. This limitation could be alleviated if the communication between Alice1 and Alice2 requires explicit authorization from the user, e.g., by pressing a button on Alice2. However, we will not discuss this enhancement further in this paper.
Yet, another limitation is related to the KEM-based schemes, as introduced in Section 5.1.2 and Section 5.2.2. In these adaptations, Alice, the initiator, needs to have the certificate of Bob, the responder, before initiating the protocol. If Alice does not already have a certificate of Bob, she should use the privacy-enhanced STS-KDF-CB protocols, as explained in Section 5.1.1 and Section 5.2.1. However, in this case, identity confidentiality for Bob cannot be provided.
We do not discuss protection against side-channel attacks, and it is left for future work. Future work also includes the implementation of all protocols and extensions to the cases where one of the split-key devices is able to attest the correctness of the functionality of the other one.
Conceptualization: Akman G, Damir MT, Ginzboorg P, Sovio S, Niemi V
Supervision: Ginzboorg P, Sovio S, Niemi V
Writing - original draft preparation: Akman G
Writing - review and editing: Damir MT, Ginzboorg P, Sovio S, Niemi V
Formal analysis: Akman G, Damir MT
Visualization: Akman G
All authors have read and agreed to the published version of the manuscript.
Availability of data and materials
The source code of our ProVerif Models is available in a GitHub repository .
Financial support and sponsorship
This research is a result of a funded collaboration project between the University of Helsinki and Huawei Technologies, Finland.
Conflicts of interest
All authors declared that there are no conflicts of interest.
Ethical approval and consent to participate
Consent for publication
© The Author(s) 2023.
1. Wooten D. Trusted platform module library. Trusted Computing Group (TCG); 2019. Available from:
2. GlobalPlatform. Secure Element Protection Profile. GlobalPlatform Technology; 2021. GPC_SPE_174. Available from:
4. Diffie W, Van Oorschot PC, Wiener MJ. Authentication and authenticated key exchanges. Des Codes Cryptogr 1992;2:107-25.
5. Blake-Wilson S, Menezes A. Unknown key-share attacks on the station-to-station STS Protocol. In: Goos G, Hartmanis J, van Leeuwen J, editors. Lecture notes in computer science. Berlin, Heidelberg: Springer; 1999. p. 154-70.
6. Jackson D, Cremers C, Cohn-Gordon K, Sasse R. Seems legit: automated analysis of subtle attacks on protocols that use signatures. In: Proceedings of the 2019 ACM SIGSAC Conference on Computer and Communications Security. London: ACM; 2019. p. 2165-80.
7. Cramer R, Shoup V. Design and analysis of practical public-key encryption schemes secure against adaptive chosen ciphertext attack. SIAM J Comput 2003;33:167-226.
8. Dent AW. A designer's guide to KEMs. In: Paterson KG, editor. Lecture notes in computer science. Berlin, Heidelberg: Springer; 2003. p. 133-51.
9. Shoup V. A proposal for an ISO standard for public key encryption (version 2.1). Switzerland: IBM Zurich Research Lab; 2001. Available from:
10. Fujisaki E, Okamoto T. Secure integration of asymmetric and symmetric encryption schemes. J Cryptol 2013;26:80-101.
11. Ebina M, Mita J, Shikata J, Watanabe Y. Efficient threshold public key encryption from the computational bilinear Diffie-Hellman assumption. In: Proceedings of the 8th ACM on ASIA Public-Key Cryptography Workshop. Hong Kong: ACM; 2021. p. 23-32.
12. Krawczyk H. SIGMA: the 'SIGn-and-MAc' approach to authenticated Diffie-Hellman and its use in the IKE protocols. In: Boneh D, editor. Lecture notes in computer science. Berlin, Heidelberg: Springer; 2003. p. 400-25.
13. Blanchet B, Smyth B, Cheval V, Sylvestre M. ProVerif 2.04: automatic cryptographic protocol verifier. Available from:
14. van Tilborg HCA, Jajodia S, editors. Encyclopedia of cryptography and security. Boston: Springer; 2011.
15. Needham RM, Schroeder MD. Using encryption for authentication in large networks of computers. Commun ACM 1978;21:993-99.
16. Lowe G. Breaking and fixing the Needham-Schroeder Public-Key Protocol using FDR. In: Margaria T, Steffen B, editors. Lecture notes in computer science. Berlin, Heidelberg: Springer; 1996. p. 147-66.
17. Basin D, Cremers C, Dreier J, et al. Tamarin-Prover Manual: Security Protocol Analysis in the Symbolic Model; 2022.
18. Giaretta G, Kempf J, Devarapalli V. RFC 5026. Mobile IPv6 bootstrapping in split scenario. DOI: 10.17487/RFC5026 Available from:
19. Manzoor A, Shah MA, Khattak HA, Din IU, Khan MK. Multi-tier authentication schemes for fog computing: architecture, security perspective, and challenges. Int J Commun Syst 2022;35:e4033.
20. Choi S, Sun K, Eom H. Chapter 17 - resource-efficient multi-source authentication utilizing split-join one-way key chain. In: Babak Akhgar, Hamid R. Arabnia, editors. Emerging trends in ICT security. Elsevier; 2014. p. 267-79.
21. Shah RH, Salapurkar DP. A multifactor authentication system using secret splitting in the perspective of Cloud of Things. In: 2017 International Conference on Emerging Trends & Innovation in ICT (ICEI); 2017 Feb 03-05; Pune, India. IEEE; 2017. p. 1-4.
22. Wang P, Ku CC, Wang TC. A new fingerprint authentication scheme based on secret-splitting for cloud computing security. In: Yang J, Norman Poh, editors. Recent application in biometrics. InTech; 2011. p. 183-96.
23. Choi J, Cho J, Kim H, Hyun S. Towards secure and usable certificate-based authentication system using a secondary device for an industrial internet of things. Appl Sci 2020;10:1-16.
24. Menezes AJ, Van Oorschot PC, Vanstone SA. Handbook of applied cryptography. CRC Press series on discrete mathematics and its applications. Boca Raton: CRC Press; 1997. Available from:
25. Kaufman C, Hoffman P, Nir Y, Eronen P, Kivinen T. Internet key exchange protocol version 2 (IKEv2). RFC Editor; 2014.
26. Krzywiecki L, Salin H. How to design authenticated key exchange for wearable devices: cryptanalysis of AKE for health monitoring and countermeasures via distinct sms with key split and refresh. In: Beresford AR, Patra A, Bellini E, editors. Lecture notes in computer science. Cham: Springer; 2022. p. 225-44.
27. Black J. Authenticated encryption. In: Van Tilborg HCA, Jajodia S, editors. Encyclopedia of cryptography and security. 2nd ed. Boston, MA: Springer; 2011. p. 52-61.
28. Rogaway P. Authenticated-encryption with associated-data. In: Proceedings of the 9th ACM conference on Computer and communications security. Washington: ACM; 2002. p. 98-107.
29. Turan MS, McKay K, Chang D, et al. Status report on the final round of the NIST lightweight cryptography standardization process. 2023.
31. Ebri NA, Baek J, Yeun CY. Study on Secret Sharing Schemes (SSS) and their applications. In: 2011 International Conference for Internet Technology and Secured Transactions; 2011 Dec 11-14; Abu Dhabi, United Arab Emirates. IEEE; 2011. p. 40-5. Available from:
33. Halpern JY, Pucella R. Modeling adversaries in a logic for security protocol Analysis. In: Goos G, Hartmanis J, Van Leeuwen J, Abdallah AE, Ryan P, et al., editors. Lecture Notes in Computer Science. Berlin, Heidelberg: Springer; 2003. p. 115-32.
34. LaMacchia B, Lauter K, Mityagin A. Stronger security of authenticated key exchange. In: Susilo W, Liu JK, Mu Y, editors. PLecture notes in computer science. Berlin, Heidelberg: Springer; 2007. p. 1-16.
35. W3C Web Authentication Working Group. Web authentication: an API for accessing public key credentials level 3. Available from:
36. Baghdasaryan D, Balfanz D, Hill B, Hodges J, Yang K. FIDO UAF Protocol Specification. Available from:
37. Android Bootcamp 2016: Android keystore attestation. Available from:
38. Powers A. FIDO TechNotes: The truth about attestation. Available from:
39. McKay KA, Bassham L, Turan MS, Mouha N. Report on lightweight cryptography. Available from:
40. Chang TY. Threshold signatures: current status and key issues. Int J Netw Secur 2005;1: 123-37. Available from:
41. Akman G. ProVerif implementation of STS-KDF and split-key STS-KDF variants. Available from:
42. Python Software Foundation. Cryptography 41.0.3. Available from:
Cite This Article
Akman G, Taoufiq Damir M, Ginzboorg P, Sovio S, Niemi V. Split keys for station-to-station (STS) protocols. J Surveill Secur Saf 2023;4:62-93. http://dx.doi.org/10.20517/jsss.2023.16
Akman G, Taoufiq Damir M, Ginzboorg P, Sovio S, Niemi V. Split keys for station-to-station (STS) protocols. Journal of Surveillance, Security and Safety. 2023; 4(3): 62-93. http://dx.doi.org/10.20517/jsss.2023.16
Akman, Gizem, Mohamed Taoufiq Damir, Philip Ginzboorg, Sampo Sovio, Valtteri Niemi. 2023. "Split keys for station-to-station (STS) protocols" Journal of Surveillance, Security and Safety. 4, no.3: 62-93. http://dx.doi.org/10.20517/jsss.2023.16
Akman, G.; Taoufiq Damir M.; Ginzboorg P.; Sovio S.; Niemi V. Split keys for station-to-station (STS) protocols. J. Surveill. Secur. Saf. 2023, 4, 62-93. http://dx.doi.org/10.20517/jsss.2023.16
Comments must be written in English. Spam, offensive content, impersonation, and private information will not be permitted. If any comment is reported and identified as inappropriate content by OAE staff, the comment will be removed without notice. If you have any queries or need any help, please contact us at firstname.lastname@example.org.