Krack - Revision history

Admin: /* Flags */

2017-10-25T05:09:27Z

Flags

← Older revision		Revision as of 05:09, 25 October 2017
Line 205:		Line 205:
	[[Category:Security]]		[[Category:Security]]
	[[Category:Wireless]]		[[Category:Wireless]]
	~~[[Category:Kismet]]~~

Admin: /* Papers */

2017-10-25T05:09:10Z

Papers

← Older revision		Revision as of 05:09, 25 October 2017
Line 184:		Line 184:

	Natural Language Approach to Automated Cracking of OTP (2006 paper): https://www.cs.jhu.edu/~jason/papers/mason+al.ccs06.pdf		Natural Language Approach to Automated Cracking of OTP (2006 paper): https://www.cs.jhu.edu/~jason/papers/mason+al.ccs06.pdf

			===Video===

			Computerphile: KRACK Attack: https://www.youtube.com/watch?v=mYtvjijATa4

	===Stack Exchange Questions===		===Stack Exchange Questions===

Admin: /* Stack Exchange Questions */

2017-10-25T05:08:42Z

Stack Exchange Questions

← Older revision		Revision as of 05:08, 25 October 2017
Line 187:		Line 187:
	===Stack Exchange Questions===		===Stack Exchange Questions===

	Infosec ~~Stack Exchange question~~: "~~how~~ does a nonce reset allow for decryption?": https://security.stackexchange.com/questions/171381/how-does-a-nonce-reset-allow-for-decryption		Infosec SE: "How does a nonce reset allow for decryption?": https://security.stackexchange.com/questions/171381/how-does-a-nonce-reset-allow-for-decryption

	Continued chat on above question: https://chat.stackexchange.com/transcript/151/2017/10/17 (via [https://chat.stackexchange.com/transcript/message/40582326#40582326])		Continued chat on above question: https://chat.stackexchange.com/transcript/151/2017/10/17 (via [https://chat.stackexchange.com/transcript/message/40582326#40582326])

	Crypto ~~Stack Exchange~~: "How do you attack a two-time pad (OTP with key re-use)?": https://crypto.stackexchange.com/questions/2249/how-does-one-attack-a-two-time-pad-i-e-one-time-pad-with-key-reuse		Crypto SE: "How do you attack a two-time pad (OTP with key re-use)?": https://crypto.stackexchange.com/questions/2249/how-does-one-attack-a-two-time-pad-i-e-one-time-pad-with-key-reuse

	Consequences of WPA2 KRACK attack: https://security.stackexchange.com/questions/171356/consequences-of-the-wpa2-krack-attack/171358		Infosec SE: "Consequences of WPA2 KRACK attack": https://security.stackexchange.com/questions/171356/consequences-of-the-wpa2-krack-attack/171358

			Infosec SE: "Is this the correct flow of the KRACK attack?": https://security.stackexchange.com/questions/171901/is-this-the-correct-flow-of-the-krack-attack

	==Flags==		==Flags==

Admin: /* How Krack Works */

2017-10-25T05:07:41Z

How Krack Works

@@ Line 133: / Line 133: @@
 The KRACK attach works by forcing the re-use of a nonce (a kind of one-time pad), which enables cracking and obtaining the PMK.
-In a normal handshake process, the client will compute the PTK (session key) from the PMK, the authenticator nonce, the supplicant nonce, and the MAC addresses of the authenticator and supplicant. The client will then use the PTK and their nonce to transmit their MAC address to the authenticator.
+===How A Brute Force Attack Works===
 If the attacker does not have the PMK, they are stuck trying to obtain the PMK through brute-force. They try and come up with a PMK that can be combined with the supplicant nonce to correctly lead to the supplicant MAC address. Sniffing the handshake only gets you enough information to carry out a brute force attack.
-KRACK works by interfering with Message 3 (which contains a key being sent from  and Message 4. Normally, the authenticator will send message 3 to the supplicant, and the supplicant will respond with message 4. However, if the attacker forges another Message 3 to look like the authenticator re-sent Message 3, the client will reinstall the key and reset the nonces (or IVs, or packet counters) to zero.
+===How Krack Works===
-In practice, the attacker can either forge Message 3 packets (to look like they came from the authenticator), or they can simply block Message 4 from reaching the authenticator (in which case the authenticator will repeatedly send out a Message 3 packet).
+(Discussion here: [https://chat.stackexchange.com/transcript/message/40596199#40596199])
 ==Resources==

Admin: /* How Krack Works */

2017-10-25T04:27:47Z

How Krack Works

← Older revision		Revision as of 04:27, 25 October 2017
Line 131:		Line 131:
	==How Krack Works==		==How Krack Works==

	The KRACK attach works by obtaining the PMK.		The KRACK attach works by forcing the re-use of a nonce (a kind of one-time pad), which enables cracking and obtaining the PMK.

	~~The~~ PTK (session key) ~~is never transmitted over the air - it is computed~~ from the PMK, the authenticator nonce, the supplicant nonce, and the MAC addresses of the authenticator and supplicant.		In a normal handshake process, the client will compute the PTK (session key) from the PMK, the authenticator nonce, the supplicant nonce, and the MAC addresses of the authenticator and supplicant. The client will then use the PTK and their nonce to transmit their MAC address to the authenticator.

	~~Normally, an~~ attacker ~~who sniffs packets can't do anything with them, because they do~~ not have the PMK ~~and therefore cannot obtain the PTK. If an attacker sniffed a handshake~~, they ~~would need~~ to ~~do a~~ brute-force ~~attack~~. ~~Specifically, the client would send their MAC addresses~~ with ~~their nonce, using~~ a ~~key~~ that ~~is part of~~ the ~~PTK;~~ the ~~attacker would try various passphrases, and compute~~ the ~~PMK and PTK for those passphrases, and verify if they got the correct MAC~~.		If the attacker does not have the PMK, they are stuck trying to obtain the PMK through brute-force. They try and come up with a PMK that can be combined with the supplicant nonce to correctly lead to the supplicant MAC address. Sniffing the handshake only gets you enough information to carry out a brute force attack.

			KRACK works by interfering with Message 3 (which contains a key being sent from and Message 4. Normally, the authenticator will send message 3 to the supplicant, and the supplicant will respond with message 4. However, if the attacker forges another Message 3 to look like the authenticator re-sent Message 3, the client will reinstall the key and reset the nonces (or IVs, or packet counters) to zero.

			In practice, the attacker can either forge Message 3 packets (to look like they came from the authenticator), or they can simply block Message 4 from reaching the authenticator (in which case the authenticator will repeatedly send out a Message 3 packet).

	==Resources==		==Resources==

Admin: /* Resources */

2017-10-25T03:46:39Z

Resources

← Older revision		Revision as of 03:46, 25 October 2017
Line 128:		Line 128:

	If we're including WPA Enterprise, there is also a RADIUS server involved. This is a third party in the handshake process. The RADIUS server is referred to as the authentication server. Ana additional set of handshakes need to occur between the authenticator (AP) and the authentication server (RADIUS server).		If we're including WPA Enterprise, there is also a RADIUS server involved. This is a third party in the handshake process. The RADIUS server is referred to as the authentication server. Ana additional set of handshakes need to occur between the authenticator (AP) and the authentication server (RADIUS server).

			==How Krack Works==

			The KRACK attach works by obtaining the PMK.

			The PTK (session key) is never transmitted over the air - it is computed from the PMK, the authenticator nonce, the supplicant nonce, and the MAC addresses of the authenticator and supplicant.

			Normally, an attacker who sniffs packets can't do anything with them, because they do not have the PMK and therefore cannot obtain the PTK. If an attacker sniffed a handshake, they would need to do a brute-force attack. Specifically, the client would send their MAC addresses with their nonce, using a key that is part of the PTK; the attacker would try various passphrases, and compute the PMK and PTK for those passphrases, and verify if they got the correct MAC.



	==Resources==		==Resources==

Admin: /* Quote */

2017-10-25T03:39:38Z

Quote

← Older revision		Revision as of 03:39, 25 October 2017
Line 113:		Line 113:
	* Like sequence numbers, MAC addresses are not necessary for authentication process - they don't add anything		* Like sequence numbers, MAC addresses are not necessary for authentication process - they don't add anything

	===Quote===		===Quote from Stanford Paper===

	{{Quote\|		{{Quote\|

Admin: /* Denial of Service */

2017-10-25T03:39:25Z

Denial of Service

← Older revision		Revision as of 03:39, 25 October 2017
Line 112:		Line 112:
	* If PMK based on PSK (shared by group of users), fresh nonces will bind PTK to peers		* If PMK based on PSK (shared by group of users), fresh nonces will bind PTK to peers
	* Like sequence numbers, MAC addresses are not necessary for authentication process - they don't add anything		* Like sequence numbers, MAC addresses are not necessary for authentication process - they don't add anything

	~~===Denial of Service===~~

	~~By flooding the network with a forged copy of message 1, an attacker can create a denial of service.~~

	~~An attacker forges a fake message 1 (the real message 1 goes from authenticator to supplicant). It is sent out after the supplicant responds to the authenticator with message 2.~~


	===Quote===		===Quote===

Admin: /* Overview from Stanford Paper */

2017-10-25T03:27:48Z

Overview from Stanford Paper

← Older revision		Revision as of 03:27, 25 October 2017
Line 48:		Line 48:
	An alternative overview of the four-way handshake from this paper: http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.142.1615&rep=rep1&type=pdf		An alternative overview of the four-way handshake from this paper: http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.142.1615&rep=rep1&type=pdf

	Successful authentication results in the supplicant and authenticator verifying each other's identity, and generating a shared secret for subsequent secure data transmissions.		What is the outcome of a successful handshake?
			* Successful authentication results in the supplicant and authenticator verifying each other's identity, and generating a shared secret for subsequent secure data transmissions.

	Once the supplicant and authenticator have authenticated each other they generate a common shared secret (the Master Session Key MSK). The supplicant uses the MSK to derive a Pairwise Master Key (PMK).		What happens (what keys are generated) after successful authentication?
			* Once the supplicant and authenticator have authenticated each other they generate a common shared secret (the Master Session Key MSK).
	In subsequent sessions, the authenticator and supplicant will generate fresh Pairwise Transient Key (PTK), as well as coordinating the Group Transient Key (GTK).		* The supplicant uses the MSK to derive a Pairwise Master Key (PMK).
			* In subsequent sessions, the authenticator and supplicant will generate fresh Pairwise Transient Key (PTK), as well as coordinating the Group Transient Key (GTK).
			* Once the authenticator and supplicant have agreed upon a shared PMK, the authenticator begins a 4-way handshake (either by itself or upon request by the supplicant). Here's the summary:

	It is assumed that the shared PMK is only known to the authenticator and supplicant. ''THIS ASSUMPTION IS DESTROYED BY THE KRACK ATTACK.''		It is assumed that the shared PMK is only known to the authenticator and supplicant. ''THIS ASSUMPTION IS DESTROYED BY THE KRACK ATTACK.''

	~~Once~~ the ~~authenticator and supplicant have agreed upon a shared PMK,~~ the ~~authenticator begins a~~ 4-way handshake ~~(either by itself or upon request by the supplicant). Here's the summary:~~		What is the message sequence for the 4-way handshake?

	* Message 1: Authenticator to Supplicant: Authenticator MAC Address, ANonce, sn, msg		* Message 1: Authenticator to Supplicant: Authenticator MAC Address, ANonce, sn, msg
	* Message 2: Supplicant to Authenticator: Supplicant MAC Address, SNonce, sequence_number, msg2, MIC-PTK(SNonce, sequence_number, msg2)		* Message 2: Supplicant to Authenticator: Supplicant MAC Address, SNonce, sequence_number, msg2, MIC-PTK(SNonce, sequence_number, msg2)
Line 63:		Line 65:
	* Message 4: Supplicant to Authenticator: SPA, sequence_number+1, msg4, MIC-PTK(sequence_number+1, msg4)		* Message 4: Supplicant to Authenticator: SPA, sequence_number+1, msg4, MIC-PTK(sequence_number+1, msg4)

	MIC-PTK represents the message integrity code (MIC) calculated as a function of the quantities in parentheses. It is computed with the fresh PTK.		Note: MIC-PTK represents the message integrity code (MIC) calculated as a function of the quantities in parentheses. It is computed with the fresh PTK.

	The fresh PTK (temporary session key) is derived from the shared PMK through a pseudo-random function with output length X. This is a function of the PMK, the authenticator MAC address, the SPA mac address, the ANonce, and the SNonce.		How is the PTK derived?
			* The fresh PTK (temporary session key) is derived from the shared PMK through a pseudo-random function with a specified output length
			* This pseudo-random function is a function of the PMK, the authenticator MAC address, the SPA mac address, the ANonce, and the SNonce.

	Once the PTK is obtained, it is divided into the KEK (Key Encryption Key) and TK (Temporary Key).		Division of PTK:
			* Once the PTK is obtained, it is divided into the KEK (Key Encryption Key) and TK (Temporary Key).

	Normally, one 4-way handshake leads to one valid PTK after handshake. Running another 4-way handshake with the same PMK leads to generating a fresh PTK.		Normally, one 4-way handshake leads to one valid PTK after handshake. Running another 4-way handshake with the same PMK leads to generating a fresh PTK.
Line 75:		Line 80:
	* The difficulty for the attacker is in not knowing the PMK of the honest participants		* The difficulty for the attacker is in not knowing the PMK of the honest participants
	* An attacker can eavesdrop on every message and remember nonces and MICs for each message		* An attacker can eavesdrop on every message and remember nonces and MICs for each message
	* Additional ~~difficulties~~ arise from the fact that attackers can insert forged messages or replay stored messages		* Additional complications for authenticator/supplicant arise from the fact that attackers can insert forged messages or replay stored messages
	* An attacker can compose a message 1 from stored nonces, and respond to every message with arbitrary combinations of known nonces/MICs		* An attacker can compose a message 1 from stored nonces, and respond to every message with arbitrary combinations of known nonces/MICs
	* Again, difficulties arise from fact that attacker can't control flow of messages, but assume the worst...		* Again, difficulties arise from fact that attacker can't control flow of messages, but assume the worst...

			What can't the attacker do?
			* Attacker does not know the PMK
			* Attacker can't control the order/timing/arrival of packets



	Message flag:		Message flag:

Admin: /* Overview from KRACK Paper */

2017-10-25T03:16:31Z

Overview from KRACK Paper

← Older revision		Revision as of 03:16, 25 October 2017
Line 8:		Line 8:

	The WPA2 handshake process involves a 4-way exchange of packets between a router/AP (authenticator) and a client (supplicant):		The WPA2 handshake process involves a 4-way exchange of packets between a router/AP (authenticator) and a client (supplicant):
	* Mutual authentication between authenticator and supplicant is based on Pairwise Master Key		* Mutual authentication between authenticator and supplicant is based on Pairwise Master Key (PMK)
	* The PMK is derived from ~~either~~ a pre-shared password and negotiated using 802.1x authentication		* The PMK is derived from a pre-shared password and negotiated using 802.1x authentication
	* During the handshake process, a fresh session key called Pairwise Transient Key (PTK) is negotiated		* During the handshake process, a fresh session key called Pairwise Transient Key (PTK) is negotiated
	* The PTK derived from PMK, authenticator nonce (anonce), supplicant nonce (snonce), and MAC address of supplicant and authenticator		* The PTK is derived from the PMK, the authenticator nonce (anonce), the supplicant nonce (snonce), and MAC address of the supplicant and authenticator

	PTK is generated ~~from those three things~~, ~~and~~ it is split into three keys:		Once the PTK is generated, it is split into three keys:
	* key confirmation key (KCK)		* key confirmation key (KCK)
	* key encryption key (KEK)		* key encryption key (KEK)