WLAN

family of standardised technologies for wireless Local Area Networks

IEEE 802.11

replacement and/or extension of wired 802.3/Ethernet LANs

covers the Physical and Data Link Layer only

Designed to work with TCP/IP

Formation of Ad-hoc networks is possible without infrastructure

most recent version: IEEE 802.11-2020

Incorporates most important amendments

Amendments are named by adding one or more small letters to the standard name

several possibilities for WLAN transmission

1. Direct Sequence Spread Spectrum (DSSS) on a single frequency

2. Frequency Hopping Spread Spectrum (FHSS), jumping between multiple frequencies

3. Infrared transmission

FHSS and Infrared are obsolete

DSSS uses 2.4 GHz

maximum data rate is 1-2Mb/s

enhancement to support higher data rates

3 non-overlapping channels of 22MHz each, split into smaller subchannels depending on the geographic region

maximum data rate of 11Mb/s

Frequency band is changed to 5GHz

Orthogonal Frequency Division Multiplexing (OFDM) instead of DSSS

through smart choosen orthogonal frequency channels could be overlapping without much interference

Maximum data rate is 54Mb/s

Adaptation of 802.11a for the ISM 2.4GHz band

Designed to be backwards compatible to 802.11b

Enabled widespread adoption of WLAN

significant improvement of throughput

Backwards compatible to 802.11g and 802.11a

Multiple Input Multiple Output OFDM (MIMO-OFDM): Exploits path diversity when using multiple antennas, 1 x 4 x 4 MIMO

Achieves maximum data rate of 600Mb/s

even more throughput

limited to 5GHz only

up to 256-QAM

MIMO-OFDM is used per default with up to 2 sets of up to 4 spatial streams 2 x 4 x 4 MIMO

data rates in excess of 1Gb/s

Eine Phased-Array-Antenne (von englisch phased array‚ phasengesteuertes Feld) ist ein amplituden- und phasengesteuertes, horizontales und/oder vertikales Antennen-Array

Durch die vertikale und horizontale Anordnung der einzelnen Antennenelemente, sowie die phasen- und amplituden-gerechte Ansteuerung der einzelnen Antennenelementen (Einzelstrahlern) oder als Arrays zusammengefassten Einzelantennen, die jeweils nur einen kleinen Antennengewinn und ein breites Antennendiagramm besitzen, ergibt sich durch Bündelung der Strahlungsenergie der einzelnen Antennenelemente im Fernfeld ein gemeinsames, gewünschtes Antennendiagramm in einer gewünschten Richtung und/oder Elevationswinkel mit höherem Antennengewinn, als die verwendeten einzelnen Antennenelemente

Can additionally use 6GHz band

uses MU-MIMO per default

Also supports 2.4GHz for compatibility

devices called Stations (STAs) with at least one Wireless Network Interface Card (WNIC)

different numbers and types of antennas, which significantly influence the throughput, range and reliability

STA is identified by its unique 48-bit MAC Address

Basic Service Set

defines a wireless network

consists of one or more STAs communicating in a specific RF channel

dentified by a unique BSSID

Independent BSS (IBSS)

Infrastructure BSS (iBSS)

Mesh BSS (MBSS)

communicating in a peer-to-peer fashion

also called an Ad-hoc network

BSSID is the MAC Address of the STA starting the IBSS

Access Point (AP) represents the BSS

AP relays all traffic, all other STAs communicate directly with the AP

BSSID is the MAC Address of the AP

added in 802.11s

STAs communicate in a peer-to-peer fashion and can route frames over multiple hops

allows two STAs to communicate even when not in RF range of each other, BSSID is not used

iBSS can be connected to a wired LAN

called a Distribution System (DS)

AP translates between WLAN and 802.3/Ethernet frames

Multiple iBSSs can be connected via DS to form an Extended Service Set (ESS)

roaming of mobile STAs when RF cells overlap

dentified by a separate SSID

responsible for providing all basic communication services of a STA

layer performs one of the following “abstract” actions:

• Generating a MAC Protocol Data Unit (MPDU)—> WLAN frame without physical layer-specific information

• MPDU is referred to as a Physical Layer Service Data Unit (PSDU)

BSS discovery: STAs end out Beacon Frames containing information about BSS

BSS management

Coordination of access to shared RF medium

Reliable delivery of data frames

Quality of Service (QoS)

Security

defined in original standard

officially called “pre-RSNA”

deprecated since the 2007 revision

made obsolete in 2020

Provides Confidentiality and Authentication

Key management and replay protection are not provided

Integrity Protection nominally supported, but implemented in a flawed way and practically not provided

added with 802.11i

Robust Security Network Association

new Authentication scheme from 802.11s

Upgrade of key lengths and cryptographic algorithms by the 802.11ac amendment

Wired Equivalent Privacy

provide the same level of implicit security as in a wired LAN

based on the RC4 stream cipher

proprietary stream cipher

choosen because of simplicity and speed

either 40-bit or 104-bit long keys

additional 24-bit Initialisation Vector (IV)

generate a pseudo-random key stream

Sender

1. The 40/104-bit WEP Key is concatenated with the 24-bit IV and fed into the RC4 stream cipher – this produces a pseudo-random Key Stream (KS) of arbitrary length

2. Prior to encryption, a 32-bit Integrity Check Value (ICV) is calculated over the frame body (the plaintext payload) The ICV is a CRC checksum calculated in the same way as the FCS, but only over the frame body

3. The ICV is appended to the frame body and the resulting plaintext is XOR-ed with the Key Stream, resulting in a ciphertext

4. The IV is prepended to the ciphertext and both are sent as payload of the frame to the receiver

Receiver

1. The IV is extracted from the received frame and, together with the respective WEP Key, fed into RC4 to recreate the same Key Stream as was used by the sender

2. The received ciphertext is XOR-ed with the generated Key Stream to decrypt it

3. An expected ICV value ICV’ is calculated over the decrypted frame body and compared with the decrypted ICV received from the sender

   1. If ICV ≠ ICV’, the received frame is discarded due to an integrity failure (e. g. attacker changed frame body)

   2. If ICV = ICV’, the decrypted frame body is accepted as valid and forwarded to the higher layers for processing

No Replay Protection

Key Stream reuse due to the short IV

Cryptographic flaws in the RC4 stream cipher

Ineffective integrity protection

Attacker captures WEP-encrypted frame and re-injects it into the WLAN

Enables many practical attacks in combination with other flaws

The key stream produced must be as random as possible (must have high entropy)

Each key stream must be used only once, as the IV is short it is easy to reuse the same IV

Attaker just needs two frames with the same IV for this attack to work and get plaintext

with extended eavesdropping the construction of an IV to key stream tabel makes it possible to easily decryot of any frames

depends solely on the secrecy of the WEP Key

Some IV values produce key streams, so-called “weak keys”, that disclose information about the WEP Key

Due to the design of RC4, correlations exist between the produced key stream and the WEP Key used as input

With a large number of known IV-key stream pairs, a statistical analysis can reveal the WEP Key with a high probability

WEP uses the encrypted ICV to protect the integrity of a frame

In combination with the (also linear) XOR-ing with the RC4 key stream, the integrity protection is completely nullified

Attacker is not limited in manipulating a captured frame, except for the length of the frame body

for key stream recovery in an iBSS

Attacker captures frame and manipulates known/probable parts of the encrypted plaintext, e. g. IP Addresses in the IP Header

Attacker corrects ICV and sends manipulated frame to AP

Network Layer device (router) examines IP Header, discards Packet (e. g. due to unknown Destination IP Address) and sends predictable response message

AP encrypts response via WEP and sends it into iBSS

Attacker captures encrypted response and calculates key stream based on expected plaintext

plaintext and key stream recovery for captured frame byte-by-byte, based on special property of ICV calculation

Attacker captures frame and truncates encrypted frame body by one byte, rendering ICV invalid

Attacker assumes plaintext value of truncated byte (e. g. 0) and calculates a probable correction value for the ICV

Corrected frame is sent to target – when accepted, the guess of the plaintext byte was correct and procedure can be repeated inductively for all other bytes

Extends key stream of a captured packet byte-by-byte, starting from a known initial portion

Attacker recovers initial portion of a key stream of length n

Attacker constructs frame with an arbitrary frame body of length (n-3), calculates ICV, truncates ICV by 1 Byte (i. e. discards last byte of ICV) and encrypts with the known n-Byte key stream

Frame is sent with a guessed value for the missing last ciphertext byte (e. g. 0)

If receiver discards frame, guess was wrong and frame is repeated with another guess (max. 256 guesses necessary)

If receiver accepts, guess was correct and (n+1)th Byte of key stream can be calculated by XOR-ing last ICV Byte (plaintext) and guessed Byte (ciphertext)

Procedure can then be repeated ad infinitum for (n+2)th, (n+3)th, etc. key stream byte

Challenge-Response scheme based on a WEP Key as shared secret

STA requests Authentication from AP by sending an Authentication Request with an Auth. algorithm of “Shared Key”

AP generates a 128-bit challenge via RC4, using the WEP Key and a random IV as input and sends the challenge in clear to the STA

The STA calculates a response value by encrypting the challenge via RC4, using the shared WEP Key and a random IV, and sends the IV+response to the AP

The AP decrypts the response value and compares it with the sent challenge

When not equal, Authentication fails

When equal, Authentication succeeds and the STA can associate with the AP/iBSS

Null Authentication, STA sends an Authentication Request to AP and is automatically accepted with an Authentication Response

Open System Authentication: no security

Shared Secret: because Challenge sent in clear and Response can be calculated by attacker and therefore key stream can be calculated by XOR-ing

two types of BSS

1. Robust Security Network (RSN) … allows only devices which implement and use RSNA-Security services

2. Transition Security Network (TSN) … allows RSNA and pre-RSNA (i. e. WEP only) devices to coexist

Key Management … Establishment, distribution and update of key material between STAs

Confidentiality … Encryption of data frame payload, encryption of management frame payload of certain unicast management frames

Integrity … Protection of data frames and certain management frames

Authentication … between devices prior to joining a BSS

Replay Protection … for data and certain management frames

Temporal Key Integrity Protocol

enhancement of WEP

intended as a transitional solution to migrate pre-RSNA devices to stronger security

The linear ICV is augmented by a non-linear keyed Message Integrity Code (MIC) to make it harder for an attacker to successfully manipulate a frame

Replay protection is added by including a TKIP Sequence Counter (TSC) in each sent frame

The TSC is 48 bit long and incremented for each sent frame

Frames received with a lower TSC than expected are discarded as replays

Instead of using a static WEP Key directly as input to RC4, a key-mixing function is used to generate a per-frame key and an IV for each sent frame

based on a 128-bit Temporal Key (TK)

Encryption is performed for the frame body, the MIC and the ICV

A per-frame WEP Key + IV, called WEP seed, is created by a 2-stage mixing function as follows:

In Stage 1, a value called TKIP-mixed Transmit Address and Key (TTAK) is calculated via a hash function, using as input the TK, the current TSC (Sequence Counter) and the MAC Address of the sender

Only the most-significant 32 bit of the 48-bit TSC are used in Stage 1, so the TTAK only changes after every 65 535 sent frames – this allows caching of the TTAK to avoid a costly recalculation for every sent frame

In Stage 2, the WEP seed for the sent frame is calculated by hashing the TTAK, the TK and the least-significant 16 bit of the TSC

WEP seed (WEP Key and IV) changes for each sent frame due to the incorporation of the TSC

The generated WEP Key and IV are then used as input for the RC4 algorithm to generate a pseudo-random key stream for XOR-ing with the plaintext

Same as with WEP, except that the additional MIC is also encrypted

The encrypted frame body + MIC + ICV are prepended by the TSC and sent to the receiver

Least significant 16 bits of TSC are encoded

in the original WEP IV field, remaining 32 bits are sent

in a separate Extended IV field between WEP IV

and ciphertext

non-linear keyed Message Integrity Code (MIC) of 64 bit length

calculated via a custom algorithm named Michael over the frame body, the Sender and Receiver MAC addresses

Two separate 64-bit integrity keys (negotiated via key management) are used for MIC calculation/checking: one in the send and another in the receive direction

The calculated MIC is put between the frame body and WEP ICV and encrypted together with them

When more than 1 MIC failure is detected in a time span of 1 minute a STA must deauthenticate all associated STAs and suspend sending and receiving of all traffic for 60 seconds

After the pause, the STA must re-authenticate, which causes the current TKIP keys to be discarded and new key material to be renegotiated

cryptographically weak

Designed to offer reasonably fast performance on WEP hardware

In contrast to keyed hash functions, Michael is reversible, i. e. the integrity key can be calculated from the protected plaintext data and the MIC!

TSC of incoming frames is checked against last seen TSC – when not greater, the frame is discarded as a replay

The check is performed prior to decryption and integrity check, to prevent unnecessary TKIP Countermeasures when replayed frames are received

modified ChopChop

iBSS must have 802.11e (WLAN QoS) or Wireless Multi-Media (WMM, subset of 802.11e) activated

Successful attack recovers integrity key for AP-to-STA traffic, allowing an attacker to send a small number of arbitrary frames to a STA on the iBSS

Also enables some other advanced attacks for key stream and plaintext recovery (TKIP fragmentation attack, Michael state reset attack)

Weaknesses in the key mixing function can allow recovery of the Temporal Key (!)

Attacker needs to recover the key streams of at least 2 packets which were created with the same TTAK value (i. e. the most significant 32 bits of the TSC were equal)

Attack can be sped up when more key streams are known

The TK can then be recalculated by executing the key mixing function in reverse with some brute forcing of intermediate values in a matter of hours

replacement of WEP/TKIP offering higher security

New algorithms require different HW than WEP/TKIP

CCMP is mandatory for devices in a RSN

CCMP uses the 128- or 256-bit Advanced Encryption Standard (AES) block cipher in two separate modes

Cipher Block Chaining Message Authentication Code

Counter

Cipher Block Chaining Message Authentication Code

Calculates a 64- or 128-bit Message Authentication Code (MAC) over the frame body and MAC Header (except some fields) by using a 128- or 256-bit Temporal Key (TK)

CCMP MAC is much stronger than the Michael MIC and not reversible

Counter

Stream cipher mode of AES, for encryption of frame body and MAC

Generates a pseudo-random key stream from the TK and a Nonce

Nonce consists of a 48-bit Packet Number (PN) value that is increased for each sent frame, the Address Field 2 (i. e. the sender address) and a Priority value (usually 0)

The PN is sent in clear to the receiver and also used for replay protection: any manipulation will result in a wrong key stream/decrypted ciphertext

The key stream is XOR-ed with the frame body + MAC to create the ciphertext (or with the ciphertext to recover the plaintext)

Galois/Counter Mode with Galois MAC Protocol (GCMP) is a replacement of CCMP for physical layers which require higher throughput

The performance of CCMP is unsuitable for multi-gigabit throughput due to the separate steps for encryption and MAC calculation requiring two complete passes through the plaintext

GCMP uses 128- or 256-bit AES in Galois/Counter Mode (GCM) to provide encryption and MAC calculation in a single step with a single key

GCM is an authenticated encryption algorithm based on the standard CTR mode for block ciphers but is optimised for parallelisation and requires only a single pass through the plaintext

GCMP uses the same input as CCMP (TK, PN, MAC of sender, MAC header, frame payload) but always outputs the encrypted frame payload and a separate 128-bit MAC (64-bit MAC is not supported)

Note that the MAC Header fields are not encrypted but only integrity-protected as in CCMP (“Additional Authentication Data” as termed in GCM)

The receiver can use GCM to decrypt the ciphertext and verify the MAC also in a single pass

The output of the GCM decrypt-and-verify procedure is either the plaintext or an integrity failure

Broadcast/Multicast Integrity Protocol (BIP) offers integrity and replay protection for Multicast/Broadcast Management Frames

No confidentiality is provided

BIP uses AES-CMAC (Cipher-based MAC) or AES-GMAC (Galois MAC) to calculate a 64- or 128-bit MAC, respectively

MAC is calculated over the management frame payload, certain MAC Header fields (Frame Control, Address Fields 1 to 3) and a 48-bit sequence counter value

The sequence counter is sent in clear with the frame – any frame with a counter lower than the last seen value is discarded

The key used for MAC calculation is named the Integrity Group Temporal Key (IGTK)

IGTK is shared by every associated device in the BSS and negotiated via key management

AES and the employed block cipher modes (CTR, CBC-MAC, CMAC, GCM, GMAC) are standardised encryption algorithms and considered secure

No significant flaws are known, despite extended cryptanalysis

A theoretical (?) flaw in GCMP is, that reuse of the PN (i. e. the nonce) can allow an eavesdropper to recover the internal key used to generate the MAC, enabling her to forge arbitrary ciphertext messages with a valid MAC

802.11 standard mandates that new devices exclusively implement CCMP/GCMP/BIP

No longer a problem, as efficient HW implementations of AES already exist

Implementation of GCMP is only expected for newer devices which implement the 802.11ac amendment

The shared IGTK offers the possibility of insider attacks

Associated STA can forge MC/BC management frames which are accepted by any other STA in the same BSS

Still much better than no integrity protection (as is the default case!)

Standard defines procedures to establish and distribute various cryptographic key material

Keys are used for the different security protocols (TKIP, CCMP, GCMP, BIP) and for protecting key establishment/update messages

Different Key Hierarchies are defined for uni- and multi/broadcast traffic:

Pairwise Key Hierarchy … for protection of unicast traffic (i. e. between a pair of devices) via TKIP/CCMP/GCMP, see next slide

Two separate Group Keys, for protection of multi/broadcast traffic

Group Temporal Key (GTK) … for protection of multi- and broadcast data frames via TKIP/CCMP/GCMP

Integrity GTK (IGTK) … for protection of multi- and broadcast management frames via BIP

Both GTK and IGTK are shared by all devices in a STA

IBSS: Every STA has an associated GTK/IGTK

iBSS: Only one GTK/IGTK is used for MC/BC traffic sent by the AP (STAs are only allowed to send unicast traffic)

Other key hierarchies are used for protection of frames in Mesh networks and on Direct Links between STAs in an iBSS (not discussed)

Pairwise Master Key (PMK) … root of the Pairwise Key Hierarchy, has a long life time (e. g. whole association) and is established during the association procedure

Pairwise Transient Key (PTK) … dynamically negotiated between devices using the PMK as basis, shorter life time than the PMK, is split into several other keys for individual security services:

Key Confirmation Key (KCK) … used during key agreement of the PTK to protect integrity of exchanged messages

Key Encryption Key (KEK) … used during key agreement and update procedures to protect other keying material

Temporal Key (TK) … Key used for encryption and integrity protection via TKIP/CCMP/GCMP

Authentication must be performed between RSNA-devices (e. g. STA and AP) prior to joining a BSS, in order to

mutually prove the devices identities

establish the PMK as basis for the key management between the devices

802.11 provides three possible Authentication and Key Management Protocols (AKMPs) with varying security properties:

Pre-Shared Key (PSK)

Based on a pre-shared secret that is pre-configured on all devices (e. g. a password or PIN) and directly used as the PMK

Only suitable for Small Office/Home Office (SOHO) networks

Password-based Authentication

Based on a passphrase pre-configured on devices

Uses public-key cryptography to dynamically establish the PMK

Mandatory for STAs in Mesh networks, optional for iBSS/IBSS

802.1x Authentication

Uses Extensible Authentication Protocol (EAP) to authenticate devices with a dedicated Authentication Server and to dynamically establish a PMK

Used mainly in Enterprise-level networks for maximum security

Authentication based on a Pre-Shared Secret (PSK)

PSK must be the same on all devices and distributed out-band (e. g. entered via management interface on devices)

High management effort with large number of devices

The PSK is 256-bit long, represented as 64 hexadecimal digits – it is directly used as the PMK for subsequent key management procedures

The specification suggests that the PSK is generated from an ASCII passphrase

Makes it easier for users to remember and distribute the shared secret – used by almost every implementation

However, security depends on the entropy of the passphrase, which is typically much lower than a randomly chosen PSK (ASCII characters only!)

Added in 802.11s amendment (Mesh networks)

May also be used by STAs in an iBSS/IBSS, but rarely implemented

Uses a protocol named Simultaneous Authentication of Equals (SAE) for password-authenticated key agreement (PAKE)

Two devices proof knowledge of a shared secret (pre-configured password) and derive a common secret (the PMK)

SAE uses either FFC (Finite Field Cryptography, similar to Diffie-Hellman) or ECC (Elliptic Curve Cryptography) to thwart possible eavesdroppers

In both cases, a search algorithm (called “hunting and pecking”) is used to calculate a Private-Key value based on the shared secret

The search algorithm is deterministic, i. e. both devices will agree on the Private-Key value

The Private-Key value is then used to derive per-device Public-Key values for mutually confirming the equality of the Private-Key and hence the devices identities

In addition, a shared secret (the PMK) is created from the Public Keys of both devices

Uses IEEE 802.1x ("Dot1x") Port based Network Access Control for authentication

Originally designed for wired LANs, adapted for 802.11

802.1x is based on the following principles:

A device, called Supplicant, which wants to access a LAN must authenticate itself prior to gaining access

Authentication is performed by a device called Authenticator, which is usually the local switch

The Authenticator blocks access to the LAN for the Supplicant until authentication was performed successfully

An Authentication Server (AS) situated in the LAN or co-located with the Authenticator performs the actual authentication procedure and has access to all necessary credentials (passwords, shared secrets, certificates,…)

The AS is also called "AAA server" (Authentication, Authorization, and Accounting)

The Authenticator relays all messages between the Supplicant and AS during the authentication procedure via Extensible Authentication Protocol (EAP)

EAP is a meta protocol that allows execution of many different authentication protocols between Supplicant and AS without the Authenticator being aware of the exact protocol used

The actual protocol used to transport EAP messages between Authenticator and AS is not defined (a common choice is RADIUS) In case of WLAN, 802.1x is the default choice for an iBSS

A STA wanting to associate with the AP of an iBSS is a Supplicant

The AP of the iBSS is the Authenticator

The AS is located either on the AP or on a dedicated device in the DS (usual case, esp. for ESSs)

802.1x can be optionally used for an IBSS

every STA must then be able to function as an Authenticator and AS for newly joining STAs

The general procedure of authenticating a joining STA in an iBSS is described on the next slides

It is assumed that RADIUS is used as the protocol between Authenticator and AS

The joining STA performs Open System Authentication with the AP prior to associating

Only done for compatibility reasons, no actual authentication is performed

The joining STA performs Association with the AP

AP nominally accepts Association but blocks all access to the iBSS or DS until the actual 802.1x Authentication was performed successfully

AP acting as Authenticator initiates 802.1x Authentication by sending an EAP-Request message to the STA, which will act as the Supplicant

The EAP-Request is sent as an EAPOL ("EAP over LAN") message, encapsulated in a 802.11 data frame

Alternatively, the STA/Supplicant can initiate 802.1x Authentication by sending an EAPOL-Start message to the AP, triggering the EAP-Request

The STA/Supplicant sends an EAP-Response to the AP/Authenticator which contains information on the Supplicant and the supported authentication protocols

The AP/Authenticator relays the information in the EAP-Response to the AS via the wired LAN (the DS)

In case of RADIUS, the information is sent as a RADIUS Access Request to the AS

The AS initiates a supported authentication protocol by sending a respective RADIUS-encapsulated message to the AP/Authenticator who forwards it as an EAPOL message to the STA/Supplicant

STA/Supplicant and AS now perform the negotiated auth. protocol by exchanging protocol-specific EAP messages, with the AP/Authenticator acting as relay

AP/Authenticator still allows no communication of the STA/Supplicant with other STAs on the iBSS or in the DS, except with the AS for authentication purposes

During the auth. procedure, STA/Supplicant and AS mutually authenticate each other and establish a shared secret called the Master Session Key (MSK) which is later used as PMK

AP/Authenticator and AS are assumed to be authenticated to each other (e. g. via pre-shared secret or certificate) and communicate over a secure channel

When the auth. protocol is completed successfully, the AS transmits the PMK created during authentication to the AP/Authenticator in a RADIUS Accept message

This allows the AP/Authenticator to derive the other pairwise keys

for key management purposes with the STA/Supplicant

 Upon receipt of the PMK, the AP/Authenticator finishes the authentication

procedure by sending an EAP-Success message to the now authenticated

STA/Supplicant

 Initiates key management procedures between AP and STA

A STA/Supplicant can "pre-authenticate" with a number of APs, i. e. perform 802.1x Authentication prior to associating

Can be done even when currently associated to an AP

Used mainly to reduce the delay when the STA associates with a new AP during roaming

Pre-Authentication is performed by the STA/Supplicant sending an EAPOL-Start message with the new AP's address as EAP destination

The EAPOL-Start is sent to the current AP, who forwards it to the new AP over the DS, acting as a relay for the subsequent 802.1x Authentication between STA and new AP

STA and new AP need not be in RF range of each other

After successful authentication, the STA and new AP cache the derived MSK/PMK

Once the STA needs to associate with the new AP (e. g. by roaming into its RF range), the cached MSK/PMK is directly used for initiating key management, bypassing the authentication procedure

EAP supports a huge number of authentication protocols with varying security properties

Choice depends on the capabilities of the devices (e. g. PC vs. mobile phone), desired level of user interaction and network infrastructure (e. g. integration with existing services)

802.11 mandates that only protocols which allow for mutual authentication and derivation of a PMK are used

WPA/WPA2 (see later) further define a suite of acceptable EAP protocols for use in enterprise networks

Protocols based on classical Challenge-Response procedure:

AS sends a challenge value (random number) to the Supplicant

Supplicant calculates a response value from the challenge, based on a secret shared with the AS (e. g. password, PIN) by using a one-way function (e. g. hash) and sends it back to the AS

AS calculates an expected response value and compares with the received one - if equal, the Supplicant is considered authenticated

EAP supports many different protocols for this basic method, such as:

EAP-MD5 ... response is the MD5 hash of the challenge and a shared secret password (basically the same as CHAP, Challenge Authentication Protocol employed in PPP)

EAP-AKA (Authentication and Key Agreement) ... response is calculated by a SIM on the Supplicant, used in 3rd generation mobile phone networks (UMTS)

EAP-GTC (Generic Token Card) ... uses Token Cards (HW authentication credentials, e. g. Smartcards or USB dongles) for generating responses

The general issue with these protocols is their vulnerability to Dictionary attacks

Eavesdropper captures challenge (plaintext) and response (ciphertext) and tries to brute force shared secret, focusing on common passphrases

In principle, these protocols should only be used together with a tunnelled EAP protocol for additional protection

After authentication, devices perform a key establishment procedure to establish a common PTK

PTK is derived from the PMK that was created during the authentication procedure (or derived from a PSK)

The same key establishment procedure is also performed whenever the PTK should be changed (e. g. key update)

Key establishment uses a 4-Way Handshake (4WHS) to establish and confirm a PTK

The 4WHS is also used to transfer the GTK/IGTK to the authenticated STA for protection of multi/broadcast traffic

All messages sent during the 4WHS are EAPOL-Key messages - Supplicant and Authenticator roles are used even when PSK or SAE authentication was performed

Every EAPOL-Key message include a key replay counter value which is incremented for every sent EAPOL-Key message and used for replay protection

When either STA or AP does not receive an expected message after a certain timeout, it retransmits the last sent message up to a certain limit

The AP/Authenticator initiates the 4WHS by generating a random nonce ANonce and sends it to the STA/Supplicant

This first message is not protected in any way!

The Supplicant generates a random nonce SNonce and calculates the PTK via Key derivation function using as input the PMK, the MAC addresses of both Authenticator and Supplicant and the two nonces ANonce and SNonce

The key derivation function is based on either HMAC-SHA-1 or HMAC-SHA-256/384 depending on the capabilities of the devices as negotiated during association

The Supplicant also derives the other pairwise keys from the PTK (=KCK, KEK, TK)

The Supplicant sends the SNonce to the Authenticator, who also calculates the PTK and related keys

The Authenticator calculates the PTK in the same way as the Supplicant by using the received SNonce

The message is protected by a MIC calculated using the KCK with either HMAC-SHA-1, HMAC-SHA256/384 or AES-CMAC depending on the capabilities of the devices as negotiated during association

Integrity of the received message is checked after deriving the KCK to prevent a MITM attack

This also implicitly ensures integrity of Message 1, because if an attacker would have changed the ANonce, a wrong PTK/KCK and MIC would have resulted

The Authenticator generates a GTK and an IGTK (when management frame protection is enabled) and sends them to the Supplicant

GTK/IGTK are only generated when not already done for a joining STA before (i. e. when Supplicant is the first STA joining the iBSS)

GTK and IGTK are encrypted with the KEK, using the AES keywrap method defined in RFC 3394

The message is protected by a MIC based on the KCK, like Message 2, and also includes the ANonce again for MITM protection

The Supplicant checks the integrity of the received Message 3 and whether the ANonce is the same as the one received in Message 1 (if not, a MITM attack is assumed) - if yes, the Supplicant decrypts the GTK/IGTK and sends the next message

The Supplicant sends an EAPOL message to the Authenticator to inform of the successful installation of the pairwise keys for receipt of protected traffic

Message 4 is protected by a MIC like Messages 2 and 3

After sending message 4, the Supplicant installs all derived keys (GTK, IGTK, TK) for usage in the encryption and integrity protocols (TKIP/CCMP/GCMP/BIP) in order to send and receive protected data

Upon receipt of Message 4 by the AP/Authenticator and successful MIC check, the AP/Authenticator installs all derived keys in order to send/receive protected traffic to/from the joined STA – finishing the 4WHS

A separate Group Key Handshake is used to update the GTK and IGTK (in case of management frame protection)

Can only be performed after successful 4WHS as KEK and KCK are needed

Normally initiated by the AP, but a STA can trigger a group key update via EAPOL-Request message to the AP at any time

Procedure:

The AP generates a new GTK and IGTK and sends both in an EAPOL-Key message to the Supplicant(s)

GTK/IGTK are encrypted with the KEK and the whole message is integrity protected via MIC calculated with the KCK

The message is sent as unicast to each STA separately, as the pairwise KEK/KCK is used for protection

The message includes the key replay counter value which is continued from any previous EAPOL message exchange (e. g. from the prior 4WHS) to prevent replay attacks with old key updates

Each Supplicant that receives the message checks integrity via MIC, decrypts the GTK/IGTK and installs it into the security protocols (TKIP/CCMP/GCMP, BIP)

Each Supplicant sends an EAPOL-Key message as acknowledgement to the Authenticator

The message contains the key replay counter value from the first message as replay protection and is protected by a MIC

Upon receipt of the acknowledgement message from every STA, AP switches to the new GTK/IGTK

When no ack. message was received from a STA, it is automatically deauthenticated

In principle, an eavesdropper can capture the messages of the 4WHS to mount an offline brute force/dictionary attack in order to recover the PMK

This is especially dangerous when PSK is used as authentication method, as the PMK/PSK rarely, if ever, changes

A high entropy PSK must be used and the PSK must be immediately changed when disclosure is suspected (e. g. due to theft of a device)

Brute force attacks are harder with SAE and 802.1x authentication, as the PMK is dynamically created

Note that with PSK every STA in the BSS knows the shared secret and can therefore calculate the PTK of any other STA – 802.1x must be used when traffic should be protected from the other STAs too

This is also the case with SAE, when the same passphrase is used on multiple STAs A 4WHS can be forced by an attacker by injecting spoofed Disassociation/ Deauthentication frames

Always possible when management frame protection is not enabled (which is the usual case)

As the GTK/IGTK is shared by all devices in the same BSS, insider attacks with multi/broadcast frames are possible

GTK derivation does not use the Supplicant and Authenticator MAC addresses and hence a receiver can not reliably distinguish between MC/BC frames sent from the AP and forged frames sent by a malicious STA associated with the same iBSS

An insider can exploit this by acting as a MITM (e. g. by sending spoofed ARP requests)

A newly discovered type of attack, called Key Reinstallation AttACK (KRACK) is possible against every RSNA key management handshake

By suppressing/delaying and replaying certain handshake messages, an attacker can force the

STA/Supplicant or AP/Authenticator to reinstall an already used PTK or GTK, causing a reset of associated cryptographic parameters (nonces, replay counters)

This allows an attacker to provoke keystream reuse (i. e. some data frames are encrypted with the same nonces/keystreams), replay certain frames and possibly forge frames in one or both directions

The attack is particularly effective against WLANs protected by 802.1x authentication, as it targets the handshakes performed after the authentication

The next slide shows a KRACK procedure against the 4WHS for forcing a STA/Supplicant to reinstall an already negotiated PTK

Note that the attack is possible, because the STA/Supplicant treats the retransmission of Message 3 in the same way as the first, original Message 3 – which is actually a flaw in the 802.11 standard!

Three security certification suites are defined by the Wi-Fi Alliance

for WLAN equipment:

Wi-Fi Protected Access (WPA) … introduced 2003 as an interim solution to migrate from WEP, mandates the usage of TKIP

WPA2 … introduced 2004 and based on 802.11i, mandates CCMP

WPA3 … introduced 2018 and based on the security extensions added by various amendments over the years, mandates Management Frame Protection (802.11w)

All suites can work in different modes regarding authentication and key management:

WPA/WPA2 Personal (also: WPA/WPA2-PSK) … uses PSK as authentication method, intended for SOHO networks

WPA3-SAE … uses Password-based Authentication via SAE, replaces PSK for SOHO networks

WPA/WPA2/WPA3 Enterprise … uses 802.1x Authentication with one of several certified EAP Protocols, intended for corporate networks

WPA3-SAE is, in general, an improvement over WPA2-PSK as the PMK is created with high entropy during the SAE-handshake instead of using a user-selected (and usually unchanging) PSK

This also provides Forward Secrecy, in case the PMK is recovered

However, WPA3 mandates a transition mode for APs and STAs where both WP3-SAE and WPA2-PSK must be supported with the same passphrase/PSK – this can be exploited to force a WPA3-capable client to initiate a 4WHS using a WPA2-PSK in order to mount a dictionary attack on the passphrase/PSK

The Dragonfly protocol used as basis for SAE is prone to leaking timing information due to the iterative procedure for calculating the shared private key values

SAE includes defenses against these problems but many implementations of WPA3-SAE do not (correctly) implement them – this allows improved offline dictionary attacks against the SAE passphrase

Wi-Fi Protected Setup (WPS) is a standard for automated setup of a WPA2-Personal/PSK protected iBSS

intended to facilitate secure configuration for end users without security know-how

Defines new protocols for automatic exchange of configuration data and derivation of a dynamic PSK

APs and STAs supporting WPS include respective information in the Beacon and Probe frames

Message exchange is done via EAP messages of custom EAP type (EAP-WSC, Wi-Fi Simple Configuration)

Three methods are defined for initial exchange of a device password (=shared secret used for authentication and PSK generation):

PIN ... user must enter an 8 digit PIN number at the AP or the STA device, PIN is either static (printed on label on device) or dynamically created by device and displayed

Near-Field Communication (NFC) ... user must establish an NFC link for exchange of credentials, e. g. via NFC-capable tags

Push Button Configuration (PBC) ... user presses a button at AP and STA device at same time

Exchange of credentials is followed by a key agreement and authentication procedure to derive a PSK

Uses a Diffie-Hellman exchange to establish a shared key followed by the exchange of keyed hashes of the device password to mutually authenticate AP and STA

PSK is derived from the shared DH key and random numbers and is therefore different for each new association (in contrast to normal WPA/WPA2-PSK) WPS with Push-Button Configuration is inherently vulnerable

A default PIN of all-0 is used, so a MITM can not be detected

Furthermore, the AP accepts any association for a certain time after pushing the button

WPS with PIN entry method using a static PIN (e. g. printed on AP) is vulnerable to an accelerated online brute force attack against the AP

The authentication procedure confirms knowledge of the PIN in two steps, first and second half of PIN is separately confirmed

In addition, the last digit of the PIN is used as checksum of the first 7 digits, reducing the entropy

An attacker can separately brute force the PIN halves, thereby reducing the max. tries from 108 to 104 + 103

Revision of WPS standard mandates that the AP enters a lockdown state after 10 failed authentication attempts to prevent this attack

Still many old implementations out there – some do not even allow WPS to be disabled!

The MAC Layer supports fragmentation and reassembly for unicast data and management frames

Each fragment is sent and acknowledged as a separate frame (MPDU)

802.11n and higher provide modifications to the MAC layer for transporting multiple unicast frames in a single aggregate frame

Allows for significant reduction of MAC layer overhead and decreases latency, as STA can send more data per medium access

Both features can be exploited for various attacks, independent on the actual security protocol (WEP, TKIP, CCMP, GCMP) in use

A receiver can be tricked to process a normal frame as an aggregated frame, allowing injection of arbitrary payload, by manipulating the unprotected A-MSDU flag in the QoS Control field

A MitM can selectively forward fragments encrypted with different keys (one known by the attacker, one unknown) to an AP so that the AP sends the reassembled frame back for the attacker to decrypt

An attacker can install a “rogue AP” in a target network

Allows LAN access without direct physical connection ("LAN port in the parking lot")

Can also result involuntarily, e. g. due to employee installing AP for convenience

Necessitates strict LAN-level authentication at all times (via 802.1x for wired ports) and dedicated WLAN IDS systems working together with wired IDS for detection

802.11 is exceptionally vulnerable to logical DoS via management frames when management frame protection is not enabled (usual case in SOHO networks)

Disassociation/Deauthentication frame spoofing

Fake Association DoS against AP (overflowing association table)

Spoofed Beacon Frames for setting up rogue/fake APs

Control Frames are not protected in any way

CTS-jamming/NAV attack ... attacker sends forged CTS frames with maximum reserved time to permanently occupy the NAV, depriving all other STAs from RF medium access

False packet validation attack ... attacker destroys data frame at receiver and sends fake ACK to sender to prevent retransmission for prolonged time

Many old implementations are vulnerable to fuzzing attacks

Attacker STA sends specially prepared frame with unconventional content to victim in order to crash it or gain access via exploit in WLAN driver

Disable IBSS support on WLAN NICs to mitigate attack vector

Flaws in the handling of CCMP encryption by chipsets of several major HW vendors were found that cause frames to be encrypted with an all-0 Temporal Key (or not at all) for a short while after a STA disassociates

This vulnerability, called “Kr00k”, affects a large number of existing smartphones and IoT devices and was discovered in the wake of the KRACK attacks Due to ambiguities in the 802.11 standard regarding the management of security contexts for buffered frames, an attacker can force APs of certain vendors to send buffered frames in plaintext or encrypted with an a key chosen by the attacker

Buffering of frames is part of the power save features and is triggered by a client via setting the power-management bit in a frame header - this bit is sent unprotected, allowing an attacker to force buffering of frames at the AP!

By forcefully changing the security context of a client, e.g. via spoofed authentication frames, the AP can be tricked into deleting the security context of the client, falling back to a null or all-zero encryption for the buffered frames once they are sent out

Because the SSID is not authenticated when connecting to a network, a victim can be tricked into connecting to another network with the same credentials but a different SSID via MitM-attack

This can be a problem, for example, with VPN services that disable themselves based on a trusted SSID

Implementation flaws in wpa-supplicant and IWD, two widely used client implementations, allow an attacker to trick a client into connecting to a fake network when using 802.1x authentication (wpa-supplicant)

complete a 4-way handshake with a peer without knowing the PMK, allowing decryption and forging of packets (IWD)