Modelling of 802.11 4-Way Handshake Attacks and Analysis of Security Properties

. The IEEE 802.11 standard deﬁnes a 4-way handshake be-tween a supplicant and authenticator for secure communication. Many attacks such as KRACK, cipher downgrades, and key recovery attacks have been recently discovered against it. These attacks raise the question as to whether the implementation violates one of the required security properties or whether the security properties are insuﬃcient. To the best of our knowledge, this is the ﬁrst work that shows how to answer this question using formal methods. We model and analyse a variety of these attacks using the Tamarin prover against the security properties man-dated by the standard for the 4-way handshake. This lets us see which security properties are violated. We ﬁnd that our Tamarin models vulnerable to the KRACK attacks do not violate any of the standard’s security properties, indicating that the properties, as speciﬁed by the standard, are insuﬃcient. We propose an additional security property and show that it is violated by systems vulnerable to KRACK attacks, and that enforcing this property is successful in stopping them. We demonstrate how to use Tamarin to automatically test the adequacy of a set of security properties against attacks, and that the suggested mitigations make 802.11 secure against these attacks.


Introduction
The IEEE 802.11 standard [3] defines a 4-way handshake as the key management protocol.It involves exchanging four messages between an access point (AP) and a client, or equivalently in 802.11 terminology, an authenticator and a supplicant.These exchanges enables parties to compute and share session/group keys for future unicast/multicast secure communication over the wireless medium.It also provides mutual authentication and session-key agreement.
The 4-way handshake was proven formally secure [14,13], and had no attacks published on it until recently, when the so-called Key Reinstallation Attack (KRACK) was uncovered by Vanhoef and Piessens in 2017 [22].This attack exploits design and/or implementation flaws in the 4-way handshake by reinstalling already in-use session or group keys.As a consequence, the adversary can break the security guarantees, even with a secure protocol for data confidentiality, such as the AES-based Counter Cipher Mode with Block Chaining Message Authentication Code Protocol (AES-CCMP), and decrypt or replay messages [22].
Moreover, various 4-way handshake implementations have been found to be vulnerable to downgrade attacks in widely used routers [20], including models of Cisco and TP-Link.These attacks mostly affect the AP, when both the AP and the client support AES-CCMP and Temporal Key Integrity Protocol (TKIP) cipher suites.Although the client is always likely to choose the stronger AES-CCMP cipher suite over TKIP, an adversary can trick the AP into using TKIP.
We start our work by building models of 4-way handshake using the security protocol verification tool Tamarin [18].Our modelling focuses on the subset of functionalities and messages for successful execution of the attacks on 4-way handshake, and not building a complete model of the 802.11state machines, thus enabling a Dolev-Yao adversary [11] to exploit the vulnerabilities.We show that Tamarin can find the attacks mentioned above, and our models can formally verify that the suggested fixes to the vulnerabilities work as intended.
The IEEE 802.11 standard defines a list of security properties suggesting that it will lead to a secure 4-way handshake (e.g., freshness of session keys, secrecy of session/group keys, authentication).The existence of the attacks described above raises serious questions about these security properties: Does the IEEE 802.11 specification or some implementation violate these properties, leading to these attacks?Or are these security properties insufficient to guarantee security?If so, what security properties would be sufficient to stop the attacks?In this paper we show how these questions can be formally answered using Tamarin.
We encode the security properties from the standard using Tamarin, and use the tool to see if any of these security properties are violated in the presence of the attacks.We find that the weaknesses that lead to the KRACK attacks [22] do not violate any of the required properties.This suggests that the security properties, as defined in the standard, are insufficient.We then propose new security properties, and by imposing them as restrictions in Tamarin, we show that ensuring these new suggested properties is enough to stop these attacks.
We remark that our approach here is different from the normal use of formal methods for checking security protocols, which consists in defining a model of a protocol with its security properties to check for the existence of attacks.Instead, we use our models and known attacks from previous works to check if the security properties proposed in the standard are enough to ensure the security of the protocol.Where they are not, we propose a new security property that could be added to the standard, encode it in Tamarin, and use the tool to automatically show that it would be enough to stop a class of attacks, such as KRACK.
The main contributions of this work are: -Presenting Tamarin models of the 802.114-way handshake that exhibit several attacks [22,20], and formally showing correctness of suggested fixes.

Preliminaries
The IEEE 802.11Standard.This standard defines protocols for data confidentiality, mutual authentication, and key management, providing enhanced security at the medium access control (MAC) layer in wireless networks [3].The original version of the standard [1] appeared in 1997, and defined the Wired Equivalent Privacy (WEP) security algorithm, based on the weak RC4 cipher.The vulnerable WEP was replaced with Wi-Fi Protected Access (WPA), as an intermediate measure, before the IEEE 802.11i amendment (WPA2) [2] was released in 2004.WPA includes the use of a message authentication code algorithm, coined as Message Integrity Check (MIC), as well as the TKIP cipher suite, which allows a more secure per-packet key system compared to the fixed key system used by WEP.The 802.11i amendment [2] and the current version of the standard [3] requires support of even more secure algorithm suites, discussed below.We summarise here the four stages of the 802.11key generation process.We refer the reader to [3] for the full details.
-Network Discovery.In this stage, the clients search for available networks along with their parameters.Clients can either actively send and receive probes, or just observe the broadcast beacons passively to learn the supported cipher suites (e.g., TKIP and/or AES-CCMP), and version of WPA.This set of parameters is called a Robust Security Network Element (RSNE).-Authentication and Association.In this step, the Pairwise Master Key (PMK) is derived at both ends.In WPA2-Personal mode, the PMK is derived using a Pre-Shared Key (PSK) with a length of 8 to 63 characters, the Service Set Identifier (SSID), and the SSID length, while in WPA2-Enterprise mode, it is derived from a key generated by an Extensible Authentication Protocol (EAP), e.g., using 802.1Xauthentication [4].The PMK is used later in the temporal keys generation.However, the real authentication is carried out during the 4-way handshake.The client and the AP accept or reject the association request based on the AP agreeing to the client's choice of RSNE.-4-Way Handshake.The 4-way handshake takes place to agree on a fresh session key, namely the Pairwise Transient Key (PTK), and optionally the Group Temporal Key (GTK); see Fig. 1.PTK derivation [3, Sec.12.7.1.7.5] uses the shared PMK, a supplicant nonce S Nonce , an authenticator nonce A Nonce , and both MAC addresses.The PTK can be refreshed after a fixed time interval, or at request from either party, by executing another 4-way handshake.The PTK is split into a Key Confirmation Key (KCK), Key Encryption Key (KEK), and Temporal Key (TK).The KCK and KEK protect handshake messages, while the TK protects data frames through the data confidentiality protocol.The 4-way handshake also transports the current GTK to the supplicant.Every message in the 4-way handshake follows the layout of EAP over LAN Key frames (EAPOL-Key) [3], and we use Msgn to denote the nth message in the handshake.The authenticator starts the handshake and increments the replay counter on every message sent.The supplicant replies to messages using the received replay counter.-Group Key Handshake.The standard allows for refreshing the GTK regularly, using a group key handshake, to ensure that only active clients are in possession of it.This process is initiated by the authenticator sending group message 1, denoted GrMsg1, to all clients.The clients reply, in turn, with group message 2, GrMsg2, with the received replay counter; see Fig. 1. -Data Confidentiality and Integrity Support.The standard defines several data confidentiality suites such as AES-CCMP and AES-GCMP as mandatory, but also TKIP for backwards interoperability with WPA [3].All suites include message integrity of the data frames.For brevity, we use the same notation as in [22] to denote an encrypted frame Enc n k (), being n the nonce (replay counter) in use, and k the key, i.e., PTK for unicast and GTK for broadcast messages.
We note that our focus is mainly on the attacks to the 4-way handshake.Therefore, the authentication and association stages are out of the scope of this paper, and we will hereafter assume that the PMK is already available at both ends.
Analysing Security Properties.The IEEE 802.11 standard lists five properties, labelled from a) to e), for the 4-way handshake [3, Sec.12.6.14].He et al. [14] aggregate four out of five of these security properties into session authentication, which can only be asserted when key secrecy is guaranteed.They formalise authentication in the cryptographic model using the notion of matching conversations [6], guaranteeing that the two entities have consistent views of the protocol runs.Using Protocol Composition Logic (PCL) [10], they verify that such properties hold.However, PCL has been subject of criticism by some authors such as [8], as it allows one to verify authentication protocols that rely on signing, but not those relying on decryption.More disconcertingly, there are no means to establish preceding actions in a thread.In contrast to matching conversations used in [14], we use standard notions of authentication from Lowe [17], e.g., mutual, injective agreement, to verify the security properties.Moreover, in their approach using PCL [14], the authors confirm that all their proofs were constructed manually.On the other hand, our verification using Tamarin is among the first attempts to verify security properties of 802.11 automatically.
Concurrent to our work, Cremers et al. [9] have also developed a detailed Tamarin model of the WPA2 protocol capable of detecting KRACK attacks, among others.Though yet to appear their work, as ours, verifies the effectiveness of the patched protocol, post-discovery of the KRACK attacks, in stopping all the attacks, including the KRACK attacks.However, our goals are different; our focus is on developing a framework to test the adequacy of the required security properties in spotting the attacks.Therefore, we only model the functionalities required to demonstrate the attacks (KRACK and downgrade), rather than the whole protocol.
The Tamarin Prover and SAPiC.Tamarin is a state-of-the-art tool for symbolic verification and automated analysis of security properties in protocols, under the Dolev-Yao model [11], with respect to an unbounded number of sessions.There are similar tools for symbolic verification, most notably ProVerif [7], where protocols are specified using applied pi-calculus [5].In our approach, we have decided to implement our models with Tamarin, since it can handle protocols with unrestricted global states and unbounded sessions.Sometimes, however, the user may have to provide auxiliary lemmas for complex protocols in order to help the tool terminate.Most importantly, Tamarin has the restriction feature, which allows a property to be enforced on the traces.This feature is essential for our work, to verify if enforcing particular security properties would stop an attack.To the best of our knowledge, other tools such as ProVerif do not offer this feature and hence are not suitable to our approach.
More concretely, we have developed our models using the SAPiC front-end, which allows to specify Tamarin models using processes.We provide a brief overview of these tools, but we refer the reader to [18,16] for further reference.SAPiC parses descriptions of protocols in an extension of the applied picalculus [5], called stateful applied pi-calculus, and converts them into (labeled) multiset rewriting rules (MSRs) to be analysed by Tamarin.
Fig. 2 describes the SAPiC syntax.The calculus comprises an order-sorted term algebra with infinite sets of publicly known names PN , freshly generated names FN , and variables V.It also comprises a signature Σ, i.e., a set of function symbols, each with an arity.The messages are elements of a set of terms T over PN , FN , and V, built by applying the function symbols in Σ.
The set of facts is defined as The special fact K(m) states that the term m is known to the adversary.For a set of roles, the Tamarin MSRs define how the system, i.e., protocol, can make a transition to a new state.An MSR is a triple of the form where L and R are the premise and conclusion of the rule, respectively, and A is a set of action facts, modelled by SAPiC events.For a process P , its trace Tr(P ) = [F 1 , . . ., F n ] is an ordered sequence of action facts generated by firing the rules in order.
Tamarin allows to express security properties as temporal, guarded firstorder formulas, modelled as trace properties.The construct F @i states the presence of the fact F at time point i.A property can be specified as a lemma to be tested if it holds or not, and enforced as a restriction, while testing the other lemmas in presence of this property [18].

Methodology for Analysing Security Properties
We summarise our process of analysing the security properties in Fig. 3.We start by building a model of a protocol with known attacks in Sec. 4. Subsequently, we verify all the security properties listed in the standard to see if they are satisfied or violated in Sec. 5. A violated security property can then be enforced as a restriction to check if it would stop the attacks, indicating an implementation issue.Alternatively, if all the security properties are verified, but the attack still exists, we can conclude that the security properties required by the standard are insufficient and need to be augmented.After analysing the attacks, we propose  a security property corresponding to the attack, shown below in Sec. 6.To test that the new property is successful in stopping the attack, we first place it as a lemma in the model and expect it to be falsified.Then, we enforce this property as a restriction in the model, expecting that it stops the attack.This helps us to verify if the attack corresponds to the new proposed security property.Finally, we execute the protocol model after fixing the vulnerability, to verify the absence of the attack.The verification of our newly proposed security properties and the fixes proves both the adequacy of the final set of properties, and correctness of the fixes in the protocol.We discuss this in Secs.6 and 7.
4 Formal Models of the 802.114-Way Handshake Attacks We present some variants of the KRACK attacks, exploiting nonce reuse [22], and a downgrade attack from [20].Along with the attack steps, we also highlight some relevant details of our SAPiC models for the attacks and for the security lemmas corresponding to each one.Some of the details, e.g., MIC, the usage of cipher suites in encryption, or some events are omitted here due to space constraints, but they can be easily understood from the context.The complete source for the models and mechanised proofs are available at [19].

KRACK Attacks
The KRACK attacks exploit vulnerabilities in the 802.11key management protocols [22].An adversary tricks a victim into reinstalling an already used key by dropping, delaying or altering the order of the 4-way handshake messages between two honest principals.On every key installation, the standard mandates that the replay counter (nonce) of the data confidentiality protocol be reset.The adversary can collect different encrypted messages using the same key and nonce: messages sent after the initial key installation, and messages sent after the key reinstallation.The adversary can then use this information to attack the data confidentiality protocol.The practical implications of the attack may enable the

Supplicant Authenticator Adversary
Reinstall PTK and GTK Install PTK and GTK Install PTK ?Nonce 1 reuse starts Fig. 4: KRACK -plaintext retransmission of message 3 after PTK install adversary to replay, decrypt or even forge the data packets, depending on the choice of the cipher suite (e.g., TKIP, AES-CCMP,AES-GCMP).We refer the reader to [22,15] for the detailed consequences of the attack.
The underlying causes of the attacks are the unclear standard specifications, such as the authenticator accepting any replay counter previously used in the 4-way handshake, not only the latest one [3, Sec.12.7.6.5].However, in practice, many APs fail to validate it, and imprudently accept an older replay counter.
We have successfully modelled several KRACK attacks exploiting the retransmission of message 3 and forcing nonce reuse [22].We remark that the goal of our models is not to verify the compromise of the data confidentiality protocol.Instead, we aim at detecting the sufficient conditions that allow an adversary to exploit it, i.e., reinstallations of the same key.
Retransmission of Message 3 after PTK Install.This variant of KRACK [22,Sec. 3.3] occurs when the supplicant accepts plaintext retransmission of message 3, even after a PTK has been installed.The message flow of the attack is shown in Fig. 4, and the outline of our model of the supplicant and authenticator are in Fig. 5.Note that we prepend 'S ' and 'A ' to the events executed at the supplicant and authenticator, respectively.The main process is defined as ν pmk; (!Supplicant | Authenticator), instantiating an arbitrary number of supplicant processes.Our model computes the PTK [3, Sec.12.7.1.7.5] with the identifiers A id , S id acting as the MAC addresses as follows: ptk = CalcPtk(pmk, A Nonce , S Nonce , A id , S id ).
The adversary sits between the supplicant and the authenticator to perform a man-in-the-middle (MitM) attack, and forwards messages 1-3 normally.The event S InstallsPtk (S id , ptk) captures an initial PTK install, after which the Fig. 5: Model outline for supplicant and authenticator vulnerable to KRACK attack based on plaintext retransmission of message 3 supplicant can send encrypted frames using the encryption key TK associated to PTK.Message 4 is blocked from reaching the authenticator by the adversary.The model uses the non-deterministic choice in the authenticator process via the + operator from the SAPiC calculus.Therefore, it captures either the reception of message 4, and installs the PTK, or timeouts and retransmits message 3 with an updated replay counter, and waits again for the confirmation.
Similarly, in order to capture the fact that the state machine of the supplicant accepts plaintext retransmission of message 3, we also branch the supplicant process, in order to capture traces completing a normal run of the protocol, and traces with an adversary blocking message 4.This latter case matches the attack scenario with the supplicant reinstalling an already in-use PTK (and GTK).It follows that the next data frames sent by the supplicant will be encrypted with a reused nonce.Our model, therefore, is aimed at capturing the traces with key reinstallations on the supplicant side using the same PTK already installed.
Retransmission of Message 3 before PTK Install.This KRACK attack has two variants with the supplicant accepting either a plaintext or encrypted retransmission of message 3 with the PTK yet to be installed [22,Sec. 3.4].
The first case is shown in Fig. 6.This attack assumes that the authenticator performs its actions as expected.The first two messages are transmitted normally.However, the original message 3 is blocked by the adversary while he waits for retransmitted of message 3.Both messages are then forwarded to the   As expected, our Tamarin models [19] falsify Lemma (NoKrackPtk), proving the existence of KRACK, allowing an adversary to cause key reinstall, nonce reuse and break the security guarantees of the data confidentiality protocol.
Attack Against the Group Key Handshake.This variant of the KRACK attack targets the group key handshake, and tricks the supplicant into reinstalling a GTK, rather than a PTK [22,Sec. 4.1].The attack is shown in Fig. 8.Note that the group key handshake runs encrypted by the already installed PTK.The standard requires that the supplicant install the GTK upon receipt of group message 1, regardless of whether it is a retransmission or not, and reply with group message 2. The adversary delays group message 2 from reaching the authenticator, triggering retransmission of group message 1.Now, the adversary forwards both versions of group message 1 to the supplicant, which causes a GTK install and subsequent reinstall.This will allow the attacker to replay group data frames to the supplicant [22].
To capture the reinstall of the GTK, Tamarin falsifies the following lemma stating that "given an installation of GTK by the supplicant, it is not the case that there exists an earlier installation with the same GTK," ∀id, gtk, t 1 .S InstallsGtk(id, gtk)@t 1 ⇒ ¬(∃t 2 .S InstallsGtk(id, gtk)@t 2 ∧ (t 2 < t 1 )). (NoKrackGtk) Our model (Fig. 8b) captures a scenario with a supplicant accepting arbitrary number of executions of the group key handshake, as long as the group message 1 Fig. 8: KRACK against group key handshake has an increased replay counter.We note that for this model we assume an initial valid 4-way handshake without exhibiting PTK reinstall.

Cipher Suite Downgrade
The downgrade attack we consider [20] is limited to the authenticator-side only.In a correct implementation, a client should be able to detect this attack easily by observing inconsistencies in the RSNE information.Recall from Sec. 2 that the RSNE information is selected in the association stage in plaintext, and subsequently encrypted and transmitted as part of message 3, as shown in Fig. 1.The supplicant must verify that the RSNE information observed in the association stage matches with the authenticated contents of message 3, and it should terminate the handshake otherwise.
In a downgrade attack, depicted in Fig. 9, the adversary forces GTK encryption with a weak cipher suite (RC4), rather than the intended strong cipher suite (AES-CCMP).The attack was discovered on the access point TP-Link WP841P [20,Sec. 5.2].The authenticator advertises support for AES-CCMP during the association stage.However, it will follow the supplicant in switching the cipher suite in mid-handshake process, accepting the TKIP-based message 2.
An adversary acts as a MitM by negotiating the AES-CCMP suite with the authenticator, and TKIP with the supplicant, as message 1 is in plain.The supplicant calculates the PTK and replies with message 2 using the TKIP suite.The authenticator accepts the message, overrides its initial AES-CCMP selection, and responds with a well-formed TKIP message 3 containing the GTK encrypted with RC4.The adversary can now exploit the weakness of this cipher to recover the GTK [21].The RSNE mismatch can be easily detected on forwarding of message 3 to the supplicant, which can drop the connection.Unfortunately, by this time, the adversary is already in possession of the RC4-encrypted GTK.Note, that this theory is semantically equivalent to the usual symmetric encryption using as key the tuple k = cs, k , because Dec cs,k (Enc cs,k (m)) = m.

Supplicant
Our Tamarin model that "for each run of the protocol, the cipher suites used by them is be the same," implying that a change of the cipher suite between a run is impossible.As expected, the lemma below is falsified: ∀tid, cs 1 , cs 2 , t 1 , t 2 .A SentMsg3(tid, cs 1 )@t 1 ∧ A Starts(tid, cs 2 )@t 2 ⇒ (cs 1 = cs 2 ).(NoDowngrade)

Analysis of IEEE 802.11 Security Properties
In this section, we list the five properties a)-e) specified for the 4-way handshake in the 802.11 standard [3, Sec.12.6.14].These properties overlap with each other and cannot be easily encoded into conventional queries, e.g., secrecy or authentication.Therefore, we sometimes define multiple security lemmas that jointly satisfy a given property.Moreover, the standard is unclear about what properties are satisfied by the group key handshake.In that case, we consider an extension of property c) below for GTK.We recall that we prepend 'S ' and 'A ' to the supplicant and authenticator events, respectively.a) Confirm the existence of the PMK at the peer.As stated in Sec. 2, our model treats this property as a premise.However, to confirm this property, we use the following lemma: Similarly, we define Lemma (FreshGtk) for the case of GTK (omitted).c) Synchronise the installation of temporal keys into the MAC.We consider the strongest authentication property from Lowe's hierarchy [17], namely, injective agreement.For the case of PTK, we verify that: "for each S CommitPtk event executed by the supplicant S id , the associated authenticator A id executed the corresponding A RunningPtk earlier, and for each run of the protocol there is a unique S CommitPtk for each RunningPtk," ∀S id , A id , pars, t 1 .S CommitPtk(S id , A id , pars)@t 1 ⇒ ((∃t 2 .A RunningPtk(A id , S id pars)@t 2 ∧ (t 2 < t 1 )) ∧ ¬(∃S id , A id , t 3 .S CommitPtk(S id , A id , pars)@t 3 ∧ ¬(t 3 = t 1 ))). (AgreePtk) Obviously, the set of parameters pars must contain the value of the PTK.S CommitPtk events are placed as late as possible on the supplicant side.A RunningPtk events are executed as earlier as possible, when all the parameters to agree are available to the authenticator.In order to capture mutual agreement, the lemma also needs to include the case when the roles of the authenticator and supplicant are reversed.For brevity, we omit this case in our exposition, but it can be found in the source of our models [19].As customary, authentication requires key secrecy to be asserted.We verify this using the following lemma for ∀id, ptk, t 1 .S InstallsPtk(id, ptk)@t 1 ⇒ ¬(∃t 2 .K(ptk)@t 2 ).(SecretPtk) Again, S InstallsPtk models the primitive MLME-SETKEYS.request[3], and we require that any installed PTK is unknown to the adversary.
Security Property for Downgrade Attack.The downgrade attack from Fig. 9 violates property e) through the Lemma (AgreeCs).Surprisingly, the attack continue to exist even after enforcing this property as restriction.Since enforcing the agreement property on cipher suite does not stop the attack, it is violating a property not present in the standard.A detailed analysis of property e) along with the downgrade attack suggests that though the standard guarantees authentication w.r.t.other party, it does not perform agreement with itself.Accordingly, we suggest the following additional security property g), as Lemma (ValidCipherSuite), to the model of Fig. 9b that captures this attack (results omitted from Table 1 due to space constraints).
g) The cipher suite that the authenticator started with is the cipher suite that the authenticator finishes with, and is the strongest one from the available choices.
As expected, the downgrade attack from Sec. 4 is captured by property g), which is encoded in Tamarin using lemma ∀tid, cs 1 , cs 2 , t 1 ,t 2 .A SentMsg3(tid, cs 1 )@t 1 ∧ A Starts(tid, cs 2 )@t 2 ⇒ (cs To verify that our proposed security properties f) and g) corresponds to respective attacks, we fix the respective Tamarin models of Sec. 4 by enforcing (NoPtkReuse), (NoGtkReuse) and (ValidCipherSuite) as restrictions.
On testing the security properties from Sec. 4, i.e., Lemmas (NoKrackPtk), (NoKrackGtk), and (NoDowngrade), Tamarin verifies them in the fixed model, proving that the proposed security properties are successful in stopping these attacks.
7 Verifying the Mitigations to the Models Finally, we fix the KRACK models, from Sec. 4, making sure that they follow the newly proposed security property f), i.e., disconnect if there is an attempt to install with the same PTK or GTK, and then execute the model again.After the fix, both of the attack lemmas, i.e., Lemmas (NoKrackPtk) and (NoKrackGtk), along with the security properties (NoPtkReuse) and (NoGtkReuse) are verified.The absence of the attack, with the new security properties verified, shows the validity of the proposed fix.This result is also a verification of the proposed countermeasure for KRACK by [22].
Similarly, the downgrade attack from Fig. 9 can be easily detected at the supplicant side [20], and can be stopped if the authenticator implementation disallows the change of cipher suites mid-handshake.Accordingly, we fix the model ensuring that it rejects a connection where the authenticator does not start and finish with the same cipher suite.After fixing it, Tamarin reports the attack Lemma (NoDowngrade) as verified, i.e., the downgrade attack no longer exists, and that the mitigation is valid.Both the fixed Tamarin models, of KRACK and downgrade attacks, are publicly available at [19].

Conclusion and Further Work
We have presented formal models of various KRACK attacks on the IEEE 802.11 4-way handshake and group key handshake, and downgrade attacks on implementations of the 4-way handshake.Using the automatic verification tool Tamarin, we verify all the security properties of the 4-way handshake mandated by the 802.11standard, in the presence of KRACK and downgrade vulnerabilities.We find that KRACK attacks do not violate any of the required security properties.We conclude that the set of properties is inadequate to capture these attacks.Using a novel approach, we propose additional security properties to be added to the 802.11standard, enabling it to capture them.We also demonstrate that enforcing these security properties in our model successfully stops these attacks.Accordingly, we fix the models with countermeasures to mitigate the attacks and verify all the security properties, providing a formal proof of correctness of the recommended countermeasures.Our novel technique can strengthen protocol specifications, by testing the adequacy of the set of required security properties against known or newly discovered attacks, and by augmenting them with new properties, if required.For future work, we would like to extend it to other use cases, i.e., to test the set of required security properties for other protocols against known attacks on them.

Fig. 3 :
Fig. 3: Flow diagram for verifying security properties, identifying new ones, and fixing the model against an attack

Table 1 :
Tamarin results of testing properties a)-e) from the 802.11 standard and proposed property f) in Sec. 5. Ensure that the security association keys are not used more than once.The security property f) is encoded, using the following lemma, in Tamarin.All the KRACK attack models from Sec. 4 violate either one or both properties (See Table1), i.e., the KRACK attacks are now captured by property f).