Verification of the design of the SPEKE protocols in many variants including the original and the latest ISO standard
Simple Password Exponential Key Exchange (SPEKE) is a well-known Password Authenticated Key Exchange (PAKE) protocol that has been used in Blackberry phones for secure messaging and Entrust's TruePass end-to-end web products. It has also been included into international standards such as ISO/IEC 11770-4 and IEEE P1363.2. In this paper, we analyse the SPEKE protocol as specified in the ISO/IEC and IEEE standards. We identify that the protocol is vulnerable to two new attacks: an impersonation attack that allows an attacker to impersonate a user without knowing the password by launching two parallel sessions with the victim, and a key-malleability attack that allows a man-in-the-middle (MITM) to manipulate the session key without being detected by the end users. Both attacks have been acknowledged by the technical committee of ISO/IEC SC 27, and ISO/IEC 11770-4 revised as a result. We propose a patched SPEKE called P-SPEKE and present a formal analysis in the Applied Pi Calculus using ProVerif to show that the proposed patch prevents both attacks. The proposed patch has been included into the latest revision of ISO/IEC 11770-4 published in 2017.READ FULL TEXT VIEW PDF
We analyze the Secure Remote Password (SRP) protocol for structural
A number of important real-world protocols including the Transport Layer...
Key establishment is one fundamental issue in wireless security. The wid...
Distributed network of the computer and the design defects of the TCP
All instances of the semidirect key exchange protocol, a generalisation ...
We consider a blockchain-based protocol for the certification of academi...
Perturbation-based attacks, while not physically realizable, have been t...
Verification of the design of the SPEKE protocols in many variants including the original and the latest ISO standard
A password-authenticated key exchange (PAKE) protocol aims to establish a high-entropy session key for secure communication between two parties based on a low-entropy secret password known to both without relying on any external trusted parties. The idea of bootstrapping a high-entropy secret key based on a low-entropy secret password is counter-intuitive, and for a long time had been thought impossible until the seminal work by Bellovin and Merrit who proposed the first PAKE solution called Encrypted Key Exchange (EKE) . Since then, research on PAKE has become a thriving field: many PAKE protocols have been proposed, and some have been included into international standards [22, 23].
However, the original EKE protocol was found to suffer from several limitations, of which the most significant one was the leakage about the password . Motivated by addressing the limitations, Jablon proposed another PAKE solution called the simple password exponential key exchange (SPEKE) in 1996 . SPEKE proves to be a more practical protocol than EKE since it does not have the same password leakage problem as in EKE. Although researchers raised concerns on some other aspects of SPEKE [33, 31] such as the possibility for an online attacker to test multiple passwords in one go, no major flaws have been reported. Over the years, SPEKE has been used in several commercial applications: for example, the secure messaging on Blackberry phones  and Entrust’s TruePass end-to-end web products . SPEKE has also been included into the international standards such as IEEE P1363.2  and ISO/IEC 11770-4 .
Given the wide usage of SPEKE in practical applications and its inclusion in standards, we believe a thorough analysis of SPEKE is both necessary and important. In this paper, we revisit SPEKE and its variants specified in the original paper , the IEEE 1363.2  and ISO/IEC 11770-4  standards. We first observe that the original SPEKE protocol is subtly different from those defined in the standards. The difference has significant security implications, which are not explained in the standards.
During the review, we have identified several issues that have not been reported before. In particular, we find two new attacks on SPEKE: namely, an impersonation attack and a key-malleability attack. The first attack allows an attacker to impersonate a user without knowing the password by launching two parallel sessions with the victim. The second attack allows an attacker to manipulate the session key without being detected. To address the identified problems, we propose a patched SPEKE, called P-SPEKE, which prevents both attacks by including the user identities in the key derivation function without altering the symmetry of the original SPEKE protocol. We build a formal model in the Applied Pi Calculus using ProVerif and apply it to formally analyse P-SPEKE. Our analysis confirms that the proposed patch is immune to the attacks. Finally, we identify an efficiency problem with the key confirmation procedure specified in both the ISO/IEC and IEEE standards and accordingly propose an improved procedure.
Our contributions are summarized below.
We discover two new attacks on SPEKE: an impersonation attack and a key-malleability attack. We explain how the attacks affect the SPEKE variants specified in the IEEE P1363.2 and ISO/IEC 11770-4 standards.
We propose a patched SPEKE, called P-SPEKE, which prevents both attacks without altering the symmetry of the SPEKE protocol. Furthermore, we propose an improved key confirmation procedure, which is more round-efficient than the one defined in the standards.
We build a formal model in the Applied Pi Calculus and verify the proposed patch by using ProVerif. Our formal analysis confirms that the proposed patch is immune against the identified attacks.
This paper extends the earlier conference paper  by adding a formal analysis of the patched SPEKE protocol, and details of how the proposed patch was accepted and included into the revision of ISO/IEC 11770-4. The two attacks and the efficiency issues, initially reported in , were discussed and acknowledged by the technical committee of ISO/IEC SC 27, Working Group 2. Accordingly, the ISO/IEC 11770-4 standard was revised. The latest revision ISO/IEC 11770-4:2017, incorporating our proposed patch and the improved key confirmation procedure, was formally published in November 2017 .
Since the invention of the first PAKE solution in , many PAKE protocols have been proposed, among which only a few have been actually used in practice. Notable examples of PAKE that have been deployed in practical applications include EKE , SPEKE  and J-PAKE . These three protocols happen to represent three different ways of constructing a PAKE. EKE works by using the shared password as a symmetric key to encrypt Diffie-Hellman key exchange items. Variants of EKE (e.g., SPAKE2 ) often differ only in how the symmetric cipher is instantiated. SPEKE works by using the shared password to derive a secret group generator for performing Diffie-Hellman key exchange. There are variants of SPEKE, such as Dragonfly  and PACE , which use different methods to derive the secret generator from the password. J-PAKE works by using the password to randomize the secret exponents in order to achieve a cancellation effect. A distinctive feature of J-PAKE as compared to the other two is its use of Zero Knowledge Proof (ZKP) to enforce participants to follow the protocol specification. By comparison, the use of ZKP is considered incompatible with the design of EKE and SPEKE.
A PAKE protocol serves to provide two functions: authentication and key exchange. The former is based on the knowledge of a password. If the two passwords match at both ends, a session key will be created for the subsequent secure communication. In the following, we review some common properties of a secure password authenticated key exchange protocols based on [9, 25, 19]; we also refer the reader to classic definitions of authentication from Lowe . Formal treatments of PAKE, based on authenticated key exchange models proposed by Bellare and Rogaway in 1993 , can be found in [7, 17, 27, 4].
Correctness. In the setting of key-exchange protocols, the protocol is correct if it gives both authentication and key distribution in presence of honest parties . This is a basic and necessary step in a formal model to prove that without influence of attackers, honest parties should always complete the protocol as expected.
Secrecy of the pre-shared password. This property requires that the execution of the protocol must not reveal any data that would allow an attacker to learn the password through off-line exhaustive search. If the attacker is directly engaging in the key exchange, he should be limited to guess only one password per protocol execution.
Implicit key authentication. Assume the key exchange protocol is run between Alice and Bob. The protocol is said to provide implicit key authentication if Alice is assured that no one other than Bob can compute the session key .
Explicit key authentication. Explicit authentication can only be achieved with a confirmation phase . This property requires that the entities have actually computed the same key. It completes and strengthens the implicit key authentication; in fact, if the two participants are the sole entities who can learn the session key and they have actually computed the key, the successive communication shall be secure.
Weak and strong entity authentication. Weak or strong entity authentication respectively correspond to the weak agreement and injective agreement properties of Lowe . A protocol achieves weak authentication if a participant believes she is speaking with another participant, and the other participant indeed started an authentication process with her. Even though this may seem a sufficient property for mutual authentication, it is not. In fact, nothing can be said about the problem where the party is tricked to communicate with some replayed session of the other party. With strong authentication, the additional property of agreeing with both the session and the session key is required. Strong entity authentication ensures that replay attacks and man-in-the-middle attacks are prevented.
Perfect forward secrecy. Perfect forward secrecy (PFS) ensures that the confidentiality of past session keys is preserved even when the long term secret, i.e., the password, is disclosed. This property implies that an attacker who knows the password still cannot learn the session key if he only passively eavesdrops the key exchange process.
The original specification of the SPEKE protocol in Jablon’s 1996 paper  is as follows. Participants agreed on a group of safe prime order where is also a prime. The SPEKE protocol operates in the subgroup of of prime order where the discrete logarithm problem is assumed to be hard. Two remote parties, Alice and Bob, share a common secret password from which they apply a function to compute the group generator: . Unless specified otherwise, all modular operations in the rest of the paper are performed with respect to the modulus . We will omit “” in the notation for simplicity.
The SPEKE protocol runs in two phases: the key-exchange phase and the key-confirmation phase, as illustrated in Figure 1. In the first phase, Alice chooses a secret value uniformly at random in , and sends to Bob. Similarly, Bob chooses a secret value uniformly at random in , and sends to Alice. Upon receiving , Alice verifies that its value is between and . This is to prevent the small subgroup confinement attack. Subsequently, Alice computes a session key where is a cryptographic hash function (used as a key derivation function here). Similarly Bob verifies belongs to and then computes the same session key . The key-exchange phase is completely symmetric. The symmetry in the design helps simplify the security analysis and reduce the communication rounds especially in a mesh network.
The second phase serves to provide explicit assurance that both parties have actually derived the same session key. This is realized in the original SPEKE paper  as follows: one party sends first and the other party replies with later.
The above key confirmation method has two subtle issues. First, it is ambiguous which party should send first. As we will explain, this ambiguity also carries over to the SPEKE specifications in the ISO/IEC and IEEE standards. Second, from a theoretical perspective, the direct use of the session key in the key confirmation process renders the session key no longer indistinguishable from random after the key confirmation is finished, hence breaking the session-key indistinguishability requirement in a formal model .
In the standards, the key confirmation phase is optional and it is left to the applications to decide whether it is added. With the absence of this phase, key confirmation will have to be deferred to the later secure communication stage where the session key is used to encrypt and decrypt messages (in the authenticated mode) and the decryption will only work if the session keys used at the two sides are equal.
|abort if||abort if|
|1-3 (optional) confirmation phase|
|abort if||abort if|
|hash is wrong,||hash is wrong,|
|otherwise accept||otherwise accept|
In , Zhang proposed an exponential-equivalence attack on SPEKE. This attack exploits the fact that some passwords are exponentially related. For example, two different passwords and may have the relation that where is an arbitrary integer (). By exploiting this relation, an active attacker can rule out two passwords in one go, and in the general case can rule out multiple passwords in one go if they are all exponentially related. This attack is especially problematic when the password is digits-only, e.g., a Personal Identification Numbers (PIN). As a countermeasure, Zhang proposed to hash the password before taking the square operation: in other words, redefining the password mapping function to . The hashing of passwords makes it much harder for the attacker to find exponential equivalence among the hashed outputs. Zhang’s attack is acknowledged in IEEE P1363.2 , which adds a hash function in SPEKE when deriving the base generator from the password.
Tang and Mitchell illustrated three attacks on the SPEKE protocol . The first attack is essentially the same as Zhang’s : an active attacker is able to test multiple passwords in one execution of the protocol by exploiting the exponential equivalence of passwords. The authors suggest to hash the identities of the parties along with the password to get the generator, that is where and are identities of two communicating parties. However, this countermeasure has the limitation that it breaks the symmetry of the protocol; instead of allowing the two parties to exchange messages simultaneously in one round, the two parties must first agree whose identity should be put first in the hash, which requires extra communication. The second attack is a unilateral Unknown Key-Share (UKS) attack. In this attack, the user is assumed to share the same password with more than one servers111We remark that it is unusual to assume a user shares the same password with multiple server in the security model for PAKE, as a server will be able to trivially impersonate another server. However, in practice, many users do reuse passwords across several accounts.. By replaying messages, the attacker may trick the user into believing that he is sharing a key with one server, but in fact he is sharing a key with a different server. To address the attack, they propose to include the server’s identity into the computation of . However, same as before, this countermeasure breaks the symmetry of the original protocol. The last attack they show is a scenario where two sessions are swapped. Here, the two parties run two concurrent sessions, and the attacker swaps the messages between the two sessions. At the end of the protocol, the parties will have shared two session keys, but they may get confused which message belongs to which session. They call this a generic vulnerability, which in this paper we call a sessions swap attack. To address this problem, they propose to include the “session identifier” into the computation of , but the paper gives no details on the definition of the “session identifier”.
When SPEKE was included into the IEEE P1363.2 and ISO/IEC 11770-4 standards, the protocol was revised to prevent the exponential-equivalence attack reported in  and . In the revised protocol, the password is hashed first before computing a secret generator. More specifically, the generator is obtained from instead of as in the original 1996 paper.
It is also worth noting that the key confirmation procedure of SPEKE defined in the standards is also different from that in the original SPEKE paper . In IEEE P1363.2  and in ISO/IEC 11770-4:2006 , the key confirmation is defined as follows.
As explicitly stated in the ISO/IEC 11770-4 standard, there is no order in the above two steps. In the same standard, it is also stated that there is no order during the SPEKE exchange phase. We find the two statements contradictory: the fact that comes before in the definition of key confirmation implies there is an order during the key exchange phase.
We would like to highlight that the above issue was carried over from Jablon’s original 1996 paper , which specifies that “Alice” sends the first confirmation message . Given the symmetric nature of the protocol, it is ambiguous which party is “Alice”. This ambiguity was unquestioned at the time of standardization and consequently was inherited by the specifications in IEEE P1363.2 and ISO/IEC 11770-4:2006.
We presented the above issue to the ISO/IEC SC 27 technical committee. The issue was acknowledged and rectified in the latest revision ISO/IEC 11770-4:2017. We will explain the details of the change later.
In this section, we present two new attacks that are not reported before: an impersonation attack and a key-malleability attack. We will first explain how the attacks work on the original SPEKE protocol  and then explain their applicability to the SPEKE variants defined in the IEEE and ISO/IEC standards [22, 23].
The first attack happens in the setting of parallel sessions: a user is engaged with another user in multiple sessions running in parallel. We illustrate the attack of Mallory who will be able to impersonate the user Bob to Alice, by launching parallel sessions with Alice to make Alice believe she is communicating with Bob, but actually Bob is not involved at all in the communication.
|Alice||Mallory (impersonating Bob)|
|Choose arbitrary (Session 1)|
|Start key confirmation|
|Verify key confirmation|
|Verify key confirmation|
|Reply key confirmation|
The attack is illustrated in Figure 2. Details of each step are explained below.
Alice chooses a secret exponent and computes . She initiates the protocol by sending to the insecure channel.
Mallory is in control of the channel and intercepts all the messages to Bob who never receives anything. So, Mallory receives the first message from Alice and generates an exponent such that 222When the work of Mallory reduces to simply relaying Alice’s messages to herself in the other session, which may be detected if Alice checks for duplicate of messages.. Mallory, impersonating Bob, initiates a parallel SPEKE session with Alice by sending her .
Alice follows the second session generating an exponent and computing . She sends to the insecure channel.
Mallory intercepts the message and raises it to the power of
(with overwhelming probability,will not be or ). Then, Mallory sends back to Alice in the first session.
At this point, Alice computes the key for the first session, generates the key confirmation challenge , and sends it to Bob.
Mallory intercepts the challenge from the first session and relays it to Alice in the second session.
Following the protocol, Alice answers the challenge with .
Finally, Mallory intercepts Alice’s answer in the second session and replays it in the first session to pass the key confirmation procedure.
At the end of the above attack, Alice authenticates Mallory as “Bob” in both sessions. However, Mallory does not know any secret password and the real “Bob” has never been involved in this key exchange. This indicates a serious flaw in the authentication procedure. We should note that in the above attack, we assume the initiator of the session is responsible for sending the first key confirmation message. This is allowed by the protocol since SPEKE specifications in both the IEEE and ISO/IEC standards permit the two parties to start the key confirmation in any order.
This attack can be regarded as a special instance of the Unknown Key-Share (UKS) attack . Alice thinks she is communicating with “Bob”, but actually she is communicating with another instance of herself. This confusion of identities in the key establishment can cause problems in some scenarios. For example, using the derived session key in an authenticated mode, like AES-GCM, Alice may send an encrypted message to Bob: “Please pay Charlie 5 bitcoins”. Mallory can intercept this message and (without knowing its content) relay back to Alice in the second session. Since the message is verified to be authentic from “Bob”, Alice may follow the instruction (assume Alice is an automated program that follows the protocol). Thus, although Alice’s initial intention is to make Bob pay Charlie 5 bitcoins, she ends up paying Charlie instead.
The second attack is a man-in-the-middle attack as shown in Figure 3. The attacker chooses an arbitrary from , raises the intercepted item to the power of and passes it on. The parties at the two ends are still able to derive the same session key , but without being aware that the messages have been modified.
|Raise to power|
The fact that an attacker is able to manipulate the session key without being detected has significant implications on the theoretical analysis of the protocol. In the original SPEKE paper, the protocol has no security proofs; it is heuristically argued that the security of the session key in SPEKE depends on either the Computational Diffie-Hellman assumption (i.e., an attacker is unable to compute the session key) or the Decisional Diffie-Hellman assumption (i.e., an attacker is unable to distinguish the session key from random). The existence of such a key-malleability attack suggests that a clean reduction to CDH or DDH is not possible. As an example,can be a result of an arbitrary function with the incepted inputs, i.e., . Because of the correlation of values on the exponent, standard CHD and DDH assumptions are not applicable since they require the secret values on the exponent be independent.
Recall from Section II-D that the SPEKE schemes specified in the standards differ from the original SPEKE paper in how the explicit key confirmation is defined. More specifically, the key confirmation procedure in IEEE P1363.2 and ISO/IEC 11770-4 includes additional data in the hash: i.e., key exchange items and . This change does not prevent the impersonation attack; the attacker is still able to relay the key confirmation string in one session to another parallel session to accomplish mutual authentication in both sessions. However, the key-malleability attack no longer works if the key confirmation method in IEEE 1363.2 or ISO/IEC 11770-4 is used. We should emphasize that the key confirmation method in both standards are marked as “optional”. Hence, the key-malleability attack is still applicable to the implicitly authenticated version of the SPEKE in both standards.
In the earlier conference version of the paper , we point out that the definition of the shared secret in ISO/IEC 11770-4:2006  is ambiguous. The shared low-entropy secret, denoted in that standard document , is defined as follows.
“A password-based octet string which is generally derived from a password or a hashed password, identifiers for one or more entities, an identifier of a communication session if more than one session might execute concurrently, and optionally includes a salt value and/or other data.
The above definition seems to include the “identifiers for one or more entities” as part of the shared secret. If the entity identifiers were included, the impersonation attack would not work, but the key-malleability would still work. However, the standard does not provide any formula about . It is not even clear if one or both entities’ identifiers should be included, and if only one identifier is to be included, which one and how. Furthermore, the word “generally” weakens the rigour in the definition and makes it subject to potentially different interpretations.
By comparison, the definition of the shared secret in IEEE P1363.2 (D26)  is clearer. It is specified as follows:
“A password-based octet string, used for authentication. is generally derived from a password or a hashed password, and may incorporate a salt value, identifiers for one or more parties, and/or other shared data.”
This definition clearly indicates that the incorporation of “a salt value, identifiers for one or more parties, and/or other shared data” is not mandatory (as indicated by the use of the word “may”). Based on the definition, it is clear that both attacks are applicable to the SPEKE scheme defined in IEEE P1363.2.
The issue about the ambiguity in the definition was acknowledge by ISO/IEC SC 27 after we first pointed it out in , and was rectified accordingly. In the latest revision in ISO/IEC 11770-4:2017, the definition of the shared secret has been revised to follow the same as in IEEE P1363.2 (D26) . In this revision, the two reported attacks are addressed by making technical changes to the SPEKE specification, as we will explain in the next section.
There are several reasons to explain the cause of the two attacks. First, there is no reliable method in SPEKE to prevent a sent message being relayed back to the sender. Second, there is no mechanism in the protocol to verify the integrity of the message, i.e., whether they have been altered during the transit. Third, no user identifiers are included in the key exchange process. It may be argued that all these issues can be addressed by using a Zero Knowledge Proof (ZKP) (as done in ). However, in SPEKE, the generator is a secret, which makes it incompatible with any existing ZKP construction. Since the use of ZKP is impossible in SPEKE, we need to address the attacks in a different way.
Our proposed patch is to redefine the session key computation. Assume Alice sends and Bob sends . The session key computation is defined below.
When the two users are engaged in multiple concurrent sessions, they need to ensure the identifiers are unique between these sessions. As an example, assume Alice and Bob launch several concurrent sessions. They may use “Alice” and “Bob” in the first session. When launching a second concurrent session, they should add an extension to make the entity identifier unique – for example, the entity identifiers may become “Alice (2)” and “Bob (2)” respectively in the second session, and so on. The use of the extension is to make the entity identifier distinguishable among multiple sessions running in parallel.
The new definition of the session-key computation function in Eq. 2 prevents both the impersonation and key-malleability attacks (as well as the session swap attack reported in ), which we will formally prove in the next section. The key confirmation remains “optional" as it is currently defined in the standards. Furthermore, this patch preserves the optimal one-round efficiency of the original SPEKE protocol.
An alternative patch, suggested in the earlier conference paper , is to refine the session key computation as follows.
As we will formally analyze in Section V, the above solution also prevents the two attacks. However, the advantage of the solution in Eq. 2 is that the hash output has a fixed bit length, which makes it easier to implement the and function. The final patch, which has been included into the latest revision of ISO/IEC 11770-4 published in 2017, is summarized in Figure 4.
|Public group parameters: , where|
|Secret information: ,|
|Abort if||Abort if|
As highlighted in Section II-D, neither of the key confirmation procedures defined in IEEE P1363.2 (D26) and ISO/IEC 11770-4 (2006) is symmetric. In both standards, they state that there is “no special ordering” of the key confirmation message. This implies that the messages can be sent simultaneously within one round. But in fact, these procedures require two rounds instead of one, because the second message depends on the first. This issue also applies to the key confirmation method in Jablon’s original 1996 paper . If both parties attempt to send the first message at the same time without an agreed order, they cannot tell if the message that they receive is a genuine challenge or a replayed message, and consequently enter a deadlock.
To address the above issue, we propose an improved key confirmation method which preserves the symmetry of the protocol and hence allows the key confirmation to be completed within one round. It works as follows.
In the above method, is a message authenticated code (MAC) algorithm, the string “KC_1_U” refers to unilateral key confirmation, and is a MAC key. To allow the session key to remain indistinguishable from random even after the key confirmation phase, should be derived differently from the session key, e.g., by adding a specific parameter to the key derivation function say . There is no dependence between the two flows, so Alice and Bob can send messages in one round. During the revision of ISO/IEC 11770-4, the hash based key confirmation method in Eq. 4 was preferred and was included into the latest standard since it requires minimum changes in the standard.
In this section, we build a formal model using the Applied Pi Calculus, then we apply this model to formally analyse the proposed patch in comparison to existing SPEKE variants.
ProVerif  is a tool for reasoning in the symbolic model. It has proved successful in formally verifying dozens of protocols, and has been widely accepted by the community. ProVerif’s input language is a dialect of the Applied Pi Calculus [14, 2], and we limit our informal illustration of the language to the subset that will be useful for describing our model.
The language is strongly typed, and arbitrary types can be declared. We use the following types for our model: for the hosts, for session IDs, for session keys, then we have the order- sub-group of where is a safe prime, and the elements in this sub-group can be expressed as where is a generator and is from .
The main abstraction of the Pi Calculus is the process. A process describes the algorithm that an entity follows according to the specifications of a protocol scheme. They can (i) include variables, constants, functions, and (private) nonces (i.e. restricts the value to the process ) (ii) write to and read from any channel , denoted by and respectively, (iii) insert and extract elements to and from any table , and , and (iv) record events. Processes can be put in sequential or parallel execution with other processes including themselves, for unbounded number of times of replication. Such instruments allow for symbolic modelling of protocols.
To model security properties, the language offers some facility. The secrecy of names is verified in terms of unreachability and indistinguishability. The unreachability of the secret by the attacker determines whether the knowledge of the attacker can be augmented with such secret by using the inference rules determined with respect to the model. From the point of view of indistinguishability, the tool determines whether the attacker can distinguish between executions that use different secrets.
More sophisticated security properties, like entity authentication, bilateral unknown shared-key resilience, and others, can be formalised through events and correspondences . Events must be explicitly included as extra lines into the processes, can take arguments, and will be recorded in the traces of execution. Correspondences are implications related to execution of events. By default the content of events is not accessible to the attacker, until the attacker is already aware of them or it will be by other rules. Moreover, the attacker is not directly capable of recording events, but it may induce processes to do so. Loosely speaking, an event can be thought as a piece of meta-semantics with respect to the purpose of the process itself. For example, the event may be interpreted as “Alice believes of having started an authentication with Bob”. Although the terminology “Alice believes…” can recall the BAN logic , and they undoubtedly share some sort of similarity at a high level, the concept of event is however different. In fact, its formalism has been built on top of a criticism to a lack of formality in the BAN logic ; in particular, an event may record something that cannot be interpreted as a belief. The generic proposition is used as a short notation to say that there exists (at least) a trace which recorded such event.
The reasoning engine of ProVerif will execute a main process and record traces of execution. At the same time, the attacker’s knowledge and the tables, if any, are accordingly updated. Security properties are eventually checked by inspecting traces, tables, the attacker’s knowledge, and, for equivalences, relations between traces and processes. We refer to the paper by Blanchet  for additional details.
We formally model the following variants of the SPEKE protocol in the Applied Pi Calculus : the original Jablon’s protocol , the ones in IEEE P1363.2:D26  and ISO/IEC 11770-4:2006 , the earlier patch proposed by Hao and Shahandashti in 2014 , and the final patch described in this paper and included into ISO/IEC 11770-4:2017 , each in two modes:
without explicit key confirmation,
with explicit key confirmation as described in the respective documents.
It is worth noting that a meaningful key exchange process should always be completed with some form of key confirmation, let it be explicit or implicit. The explicit key confirmation is realized by executing the explicit key confirmation procedure, which requires extra rounds of communication. But the explicit key confirmation procedure is optional [22, 23]: without it, the key confirmation is deferred to the secure communication stage, and this is called implicit key confirmation . However, the exact mechanisms for implicit key confirmation are not specified in [25, 22, 23], which makes it difficult to model SPEKE with implicit key confirmation. To address this issue, we assume the implicit key confirmation is realized in the secure communication stage by prepending the first encrypted message with an explicit key confirmation string as defined in the respective explicit key confirmation procedure. Thus, our formal model treats SPEKE with implicit and explicit key confirmations as essentially the same with the only difference being that the latter requires additional rounds of communication.
In the model, we formally specify the following:
The two parties. All variants of the SPEKE protocol involve two parties: the Initiator and the Responder . They are modelled as two processes and . We use the initiator and the responder for the convenience of naming in our model. Essentially we assume that one party initiates the protocol by sending data in the first flow, and the other party responds by sending data in the second flow. Thus a one-round protocol is implemented in two flows. This does not change the security analysis of the protocol. Below we give the “vanilla” specification of the protocol. In the “vanilla” specification, we abstract out key reconstruction by a function symbol , and the confirmation messages sent by the Initiator and the Responder are abstracted by the symbols and respectively. The actual specification of each variant has its own definitions of , and to capture the differences between the variants.
As can be easily seen in Figure 5, the code inside the boxes is the part modelling the protocol scheme depicted in Figure 1, where the key reconstruction part is abstracted by the function symbol , and the confirmation messages sent by the Initiator and the Responder are abstracted by the symbols and respectively, where we omit their arguments for simplicity. We highlight the symmetric nature of the protocol letting both processes to write to the channel simultaneously.
The other lines (outside the box) in Figure 5 serve to model the behaviour of the protocol and to verify security properties. In particular, the first line is to let the processes know the identities involved in the protocol; they read them from the channel at the very beginning. The second line checks whether the password table contains a suitable password to communicate to the other party; otherwise, they abort. The last line is useful to verify the secrecy of the shared key through the privacy of the message , and the perfect forward secrecy. The details are deferred to Section V-C where we discuss the security properties.
The pre-shared password. A table of passwords is filled with all secret group generators that would be calculated from the passwords, i.e., is the secret group generator for and . From the point of view of the symbolic protocol design, sharing a password and then computing the generator is the same as having directly shared the secret generator.
The main process. Informally, the main process is an infinite repetition of the parallel execution of the Initiator’s process and the Responder’s process . Due to the symmetric nature of the SPEKE protocol, the naive implementation of the main process brings false attacks where the Initiator speaks to itself. To avoid this issue, we must explicitly support the session within the two parties. However, the session is not private information, and we disclose it to the attacker by outputting it to the insecure channel , i.e. . At this point, we have the infinite repetition of the following process: . The two parties would never engage the protocol if they do not share the password. For this reason, we have an environment process which is in charge of inserting shared passwords into a table that can be accessed by and , but not the attacker. In order to record events and verify correspondences, we also have a process , which records the agreements between the parties through events.
Finally, the main process that the tool checks has the following structure:
The process collects information from two tables, one filled in by the Initiator and the other by the Responder. We emphasise that the protocol can be initiated by either of them and the two tables are put together recording a single event. For security properties that do not require tables to record events, the process will be simply ; otherwise, depending on the property to prove, the events end can be recorded, where means that the involved parties in the protocol agree with the participants, the session, and the reconstructed session key at the end of the protocol, and means that the involved parties in the protocol agree with the participants, the session, the secret group, the secret nonce, and the reconstructed session key at the end of the protocol.
The security properties are modelled as follows.
This property checks whether the protocol gives authentication and key distribution in presence of honest parties . Even though this property is generally the easiest to prove, it should not be neglected when formally modelling a protocol, in order to avoid either logical or typographic errors. To check the correctness of the models, we need to reconstruct the session key . Its implementation depends on the SPEKE variants.
Formally, for all the sessions and nonce exponents, we require that there exists at least a trace in which the event collecting private and shared values of the participants is recorded and is such that the two honest participants agree on their identities, the password, and the session key with the right formula.
where and are honest parties and is the generator calculated from the shared password. If such an event is raised, then there exists a run of the protocol in which the two parties have authenticated each other and they have correctly computed the session key.
We proved the secrecy of the password through observational equivalence. Formally, if we call the process describing the protocol where two honest parties and share the password , and the same protocol but with instead of , then the observational equivalence describes the property that any attacker cannot distinguish between the two runs of the protocol with probability (non-negligibly) better than a blind guess, and therefore no extra information about the secret password can be gained.
Implicit key authentication is verified when only the two participants can reconstruct the session key. This concept is modelled by using the key to encrypt a secret message with deterministic encryption. We then check for observational equivalence of two runs of the processes and where in the last line (Figure 5) the message encrypted is provided by a choice, . Similar to how we determine the secrecy of the password, if we call the process describing the protocol where two honest parties and encrypt , and the same protocol but with , then the observational equivalence is verified. If the observational equivalence holds and therefore the message remains secret, it trivially follows that the shared key is at least as secret as . In fact, the decryption function is public, and the reconstruction of the key will irredeemably compromise the secrecy of .
Explicit key authentication is verified when only the two participants can reconstruct the session key, and they actually do. It is therefore defined as implicit key authentication and an agreement on the computed key for the same session. Formally,
In other words, in a trace of execution the presence of the event where the first and fifth arguments being equal (agreement on the initiator), the second and the sixth being equal (agreement on the responder), and the third and the seventh being equal (agreement on the session) implies that the fourth and the eighth are equal (equivalence of the reconstructed key). When this property is true, a protocol completed between two authenticated parties in the same session guarantees that the parties agree on the session key. This property, along with the implicit key authentication, gives explicit key authentication.
Weak entity authentication guarantees that two parties are indeed speaking to each other. Strong entity authentication requires agreement on other values than the mere entities. These values are supposed not to be injected, produced or inferred by an attacker. Those two properties share similarities in their formality. The events involved are 1) to record that the initiator believes that it has started a protocol with the responder ; 2) to record that believes that it has started a protocol with ; 3) to record that believes that it speaks to at the end of the protocol, and 4) to record that believes that it speaks to at the end of the protocol. The first and the third are recorded by the honest initiator, while the the second and the fourth by the honest responder. Mutual weak authentication is provided by the two following symmetric correspondences, one for each honest party:
And mutual strong authentication by the following:
where they agree also on the session and the exchanged session key. Agreeing on the session will prevent any replay attack from other sessions, even concurrent, while agreeing on the key will guarantee that no attacker can let two authenticated parties not to share the same key. However, a key-malleability attack is still possible even if the protocol can achieve strong entity authentication.
Usually, key exchange protocols verify (or claim) the perfect forward secrecy (PFS) property. For the password authenticated key exchange protocols, this property means that if passwords are compromised, the past session keys derived from such passwords still remain secret. Hence, an adversary can only keep a record of past communication which has not been compromised. We can reformulate this concept as a passive adversary whom is given the password and eavesdrops (unbounded number of) executions of the protocol trying to reconstruct any of the session keys. In practice, to verify this property we disclose the secret generator to the attacker, , then we query the non-interference property on the encrypted message. Since the passive attacker can compute any decryption, the non-interference property captures the perfect forward secrecy, i.e., if the encrypted message cannot be reconstructed, it must be that any session key cannot be reconstructed either.
Informally, a successful bilateral UKS attack makes two honest parties and believe that they share with some other party . To capture this attack, we use the following correspondence:
If an initiator and a responder recorded the same key, then it must be that they agree on the entities. If we required that they should agree on the session too, then we could put in logical AND with the two equivalences. On the contrary, if we wanted to force the tool to show bilateral UKS attacks in the same session, we could state as a premise.
The impersonation attack is a problem that generally affects SPEKE protocols and an instance of such an attack has been shown in Section III-A. To formalise this attack, we build a model in which there exists only one honest party and the attacker. In this case, if the honest party ever shares a key with another party, then the other party must be the attacker, and the attacker must impersonate another honest party in order to run the protocol up to this point. In fact, all SPEKE variants without key confirmation phase are vulnerable to this attack.
To verify, we can check for every honest party, session and key, the event of authenticating the other party is not recorded in any trace (i.e. the adversary cannot establish a shared key with the honest party). Formally, we check the following property:
A man-in-the-middle is able to perform the sessions swap attack if it can let a honest party in some session share a key with another honest party in some other concurrent session and vice versa. This attack occurs in a key-exchange protocol where the key does not depend on the session. Formally, we say that for every two parties and for every key, the presence of an agreement on the Initiator, Responder, and session key must imply the equivalence of the sessions.
The malleability of the session key is an attack that affects many variants of the SPEKE protocols, and it was described in Section III-B. Capturing the malleability attack in ProVerif requires more efforts than other attacks, because it is based on an extra level of group exponentiation equality (three commutative exponents). This results in a larger search space when the reasoning engine checks the property, and ProVerif slows down considerably (taking minutes instead of milliseconds to verify the non-malleability property on a 3.2 GHz computer with 64 GB RAM running Linux). To detect malleability, we require the two honest parties to write into a table some values they agree with, plus their secret fresh exponents and the secret generator (the password). This way, when checking for correspondence, we can check whether the key is indeed what is expected with regard to the private inputs of the parties.
Formally, for every pair of parties, session, generator, two exponents and key, where the parties agree on the identities, the session, the generator and the key (they cannot agree on the other party’s secret), then the key they agree on is computed equivalently to the formula provided by the protocol.
Note the key may have two different values depending on in the protocol who is the initiator and who is the responder.
|Jablon 1996 paper ||1||3|
|IEEE P1363.2:D26 ||1||3|
|ISO/IEC 11770-4:2006 ||1||3|
|Hao and Shahandashti||1||2|
|P-SPEKE (ISO/IEC 11770-4:2017)||1||2|
The results are grouped by variants with and without key confirmation phase (KC).
Legend. Round efficiency: without explicit key confirmation (RND), with explicit key confirmation (RND-E). Security properties: Implicit Key Authentication (IKA), Explicit Key Authentication (EKA), Weak Entity Authentication (WA), Strong Entity Authentication (SA), Impersonation resilience (IMP), Sessions Swap resilience (SS), Perfect Forward Secrecy (PFS), bilateral Unknown Key-Share resilience (UKS), and Malleability resilience (MAL). Outcomes: () - verified, () - attacks found, () - not applicable.
The ProVerif scripts that we created to model and verify the protocols are available at GitHub . There are in total 54 scripts related to this paper, each for a different variant and a property. ProVerif will give one of the following four responses: (i) the property is true, (ii) the property is false, (iii) the property cannot be proved, and (iv) non-termination.
The results are summarised in Table I. The proposed patch (as well as the patch in ) improves the round efficiency over the previous SPEKE variants [25, 22, 23] by allowing the explicit key confirmation steps to be completed within one round. As a result, it requires only 2 rounds to finish the key exchange with explicit key confirmation as opposed to 3 rounds previously. All variants have the Implicit Key Authentication (IKA) property, confirming that the session key will not be learned by the attacker, and that the attacker cannot get confidential information by eavesdropping. This does not contradict the impersonation attack shown in Section III, since that attack works without the adversary learning the session key. However, that attack demonstrates that the adversary is able to manipulate the two parallel sessions to make them generate identical session keys. Consequently, the adversary is able to pass the explicit key confirmation by replaying messages. This is confirmed by our formal analysis that the original SPEKE , and the SPEKE in standards [22, 23] do not fulfil the explicit key authentication property. Also, the existence of the impersonation attack shows that these variants do not fulfil the weak/strong entity authentication which concerns assuring the identities of the entities involved in the key exchange protocol. The proposed patch prevents the Session Swap attack (SS), the UKS attack, and the Malleability (MAL) attack by making the session key depend on the session, the identities, and the transcript of the key exchange process. We emphasise that these security properties are verified before any key confirmation either implicit or explicit. To guarantee that the participants are mutually authenticated, the key confirmation becomes necessary. Such key confirmation must include all of the key points above, i.e., session, identities, and a transcript of the key exchange messages, so avoiding the above mentioned attacks. Including only the identities allows to verify weak entity authentication only.
Our formal analysis using ProVerif confirms that our proposed patch prevents the two attacks as identified earlier. However, this analysis does not constitute a complete proof of security for SPEKE, as one might expect from formal authenticated key exchange models [8, 7, 27, 17, 4]. In particular, we have not proved that SPEKE is resistant against off-line dictionary attacks based on standard security assumptions such as DDH or CDH. We highlight that the original SPEKE was designed without a security proof. Retrospective efforts to prove the security of a protocol based on standard number theoretical assumptions may turn out to be very hard if not impossible. We leave further analysis of SPEKE to future work.
The SPEKE protocol was firstly proposed by Jablon over two decades ago. Since then, it has been adopted by international standards, and built into smart phones and other products. We identified two weaknesses in the standardized SPEKE specification, which affect all implementations that follow the IEEE 1362.3 and ISO/IEC standards. Accordingly we proposed a patched SPEKE to address the identified issues. We formally modelled the discovered attacks against SPEKE and proved that the proposed patch was immune to these attacks. In addition, we contributed to improve the round efficiency of the protocol in the key confirmation phrase. Our proposed patch and the improved key confirmation procedure have been included into the latest revision ISO/IEC 11770-4 published in July 2017. However, the SPEKE specification in IEEE P1363.2 (which is currently not maintained) remains unfixed.
The problems in SPEKE identified in this paper have evaded 20 years cryptanalysis (informal and formal) by the security and standardization communities. The initial discovery of the two attacks on SPEKE was down to manual analysis, which was later formally verified by applying the ProVerif tool. The mechanised proofs that we produce are not only helpful for proving security properties of similar protocols, but also for preventing the same problems in the future. This shows that traditional human cryptanalysis, in conjunction with modern automated proof techniques, is useful in improving security protocols, especially those that have been included in international standards.
We thank Professor Liqun Chen for her invaluable advice and comments on revising SPEKE in ISO/IEC 11770-4.