Ethereum for Secure Wi-Fi Authentication

Ethereum tools could be used to authenticate to secure Wi-Fi networks. The proposed protocol requires no passwords and no pre-shared keys — and so it eliminates one of the biggest security holes in competing protocols. No passwords also means it’s way easier for users. Its acceptance would lead to huge popularization of Ethereum. Read on for details about how it would work.

Introduction

The Ethereum Wildfire Project is proposing protocols that use Ethereum’s Keccak hash / ECDSA signature algorithm to login to websites and to authenticate to secure networks. In a previous article we gave a very general outline of how a Diffie-Hellman-Merkle key Exchange could be enhanced by signing certain messages to guarantee message integrity and to protect against Man-in-the-Middle attacks. Although we outlined the basic functioning of the proposed EAP-KeccakV1 protocol, there seems to be some confusion regarding how the protocol would be applied in the context of a Wi-Fi network to obviate the need for a Wi-Fi password. This article will provide a little bit more context and detail.

Currently the most secure Wi-Fi networks use what is known as WPA2 authentication. WPA2 is a Wi-Fi Alliance certification that is based on the ratified IEEE 802.11i standard. There are two versions of WPA2: Personal and Enterprise. WPA2-Personal always uses a password (Pre-Shared Key) for access to the Wi-Fi network. WPA-Enterprise uses EAP. This article will focus only on WPA2-Enterprise.

WPA2-Enterprise uses a RADIUS (802.1X) server for authentication. EAP messages between the supplicant and the Authenticator are encapsulated as EAPOL (EAP Over Lan). They are encapsulated as RADIUS packets between the Authenticator and the Authentication Server. While there are close to 100 different EAP authentication methods, WPA2 mandates support for at least five: EAP-TLS, EAP-TTLS, PEAPv0, PEAPv1, and EAP-SIM. In every case there

are 4 basic steps to signing on to a WPA2-secured Wi-Fi network:

1) Identification and selection of a security profile

2) 802.1X authentication

3) Master Key derivation

4) Subordinate Key derivation / distribution

Note that the majority of the message types that make up these 4 steps are specified in the 802.11i specification (or in the 802.1x specification, which is explicitly required for WPA2). The specific contents of the messages are specified in the corresponding EAP method specifications. The following sections will provide detail regarding the protocols that make up each of the 4 basic steps.

Step 1. Identification and selection of a security profile

When a new wireless station (Supplicant) requests access, the access point (Authenticator) asks for the Supplicant’s identity. The protocol used between the Supplicant and the Authenticator is EAP, encapsulated over LAN (EAPOL). At this point no traffic other than EAPOL is allowed before the Supplicant is authenticated.

The Identity packets that comprise Step 1 are more or less common to all the supported EAP methods. The Identity Response packet includes the Supplicant’s selected EAP method, and may include additional information. In our proposed protocol the Identity Response includes the Supplicant’s Ethereum address.

Step 2. 802.1X authentication

After the identity has been sent, the authentication process begins. Note that the protocol used between the Supplicant and the Authenticator is EAPOL. The Authenticator re-encapsulates the EAP messages to RADIUS format, and passes them to the Authentication Server.

During authentication, the Authenticator just relays packets between the Supplicant and the Authentication Server. When the authentication process finishes, the Authentication Server sends a success message (or failure, if the authentication failed).

The authentication that we are proposing was outlined in a previous

article, “EAP-Keccak, A Proposed Authentication Protocol for

Enterprise Environments.” The releveant messages are depicted below:

The contents of the RADIUS Access Request and Challenge packets are specific to each EAP authentication type. In our proposed EAP-Keccak protocol the challenge includes the RADIUS Server’s Ethereum address, a URI and the current Ethereum block height. The EAP-Keccak Auth response is an ECDSA signature of a Keccak hash of the challenge message.

Step 3. Master Key derivation

The messages that comprise the Master Key derivation step are specific to each EAP authentication type. During this process the Authenticator just relays packets between the Supplicant and the Authentication Server. Our proposed protocol uses a Diffie-Hellman-Merkle key Exchange, as outlined in a previous article, “Beyond EAP-Keccak, EAP-KeccakV1 For Encrypted

Communications.”

The Setup Message includes the Diffie-Hellman-Merkle setup parameters: b and p (the base and prime number). This message and the Server’s One-way Obfuscated Secret message are both Keccak-hashed and ECDSA signed using the Authentication Server’s Ethereum address (which was sent to the Supplicant in the RADIUS Access Challenge). The Peer One-way Obfuscated Secret is Keccak-hashed and ECDSA signed using the Supplicant’s Ethereum address. For a detailed explanation of how the key derivation works see the previous article — but the important take-away is that even though the messages are not encrypted, the Master Session Key will only be known to the Supplicant and the Authentication Server — even if the messages are snooped by a malicious third party! Signing the messages protects against a Man-in-the-Middle attack.

At the end of the Diffie-Hellman-Merkle key Exchange both the Supplicant and the Authentication Server are in possession of a Master Session Key (MSK). At this stage the Authentication Server sends the MSK to the Authenticator via a previously established secure channel; and the Authenticator and Supplicant continue with the derivation of Subordinate Keys.

Step 4. Subordinate Key derivation / distribution

Once the Authenticator and the Supplicant have the Master Session Key, the subordinate key derivation is essentially the same for all EAP authentication methods, including our proposed EAP-KeccakV1 protocol. Nevertheless, for the sake of completeness, we’ll review it briefly:

the Supplicant and the Authenticator derive a Pairwise Master Key (PMK). Generally the PMK is just the first 256 bits of the MSK.

the Supplicant and the Authenticator exchange nonces (AP Nonce and STA Nonce) in the first 2 messages of a 4-part EAPOL handshake.

the Supplicant and the Authenticator compute a Pairwise Transient Key (PTK) using a Pseudo Random Function (really a SHA1 hash): PTK=PRF(PMK, AP Nonce, STA Nonce, AP MAC address, STA MAC address).

The resultant PTK is installed and verified in the last 2 messages of the 4-part EAPOL handshake.

The 512 bit PTK is a concatenation of five separate keys and values, each with its own purpose:

Key Confirmation Key (KCK)

Used during the creation of the Message Integrity Code. It is used to prove

the possession of the PMK and to bind the PMK to the AP.

Used during the creation of the Message Integrity Code. It is used to prove the possession of the PMK and to bind the PMK to the AP. Key Encryption Key (KEK)

Used by the access point to encrypt and distribute the Group Transient Key (GTK) which is used for broadcast/multicast traffic.

Used by the access point to encrypt and distribute the Group Transient Key (GTK) which is used for broadcast/multicast traffic. Temporal Keys (TK1, TK2)

128 bit keys used for the encryption and decryption of unicast packets.

128 bit keys used for the encryption and decryption of unicast packets. MIC Authenticator Tx Key (MIC Tx)

Only used with TKIP.

Only used with TKIP. MIC Authenticator Rx Key (MIC Rx)

Only used with TKIP.

Temporal Keys 1 & 2 (TK1/TK2) are used for encryption according to the selected ciphersuite. But WPA2 mandates AES-based CCMP encryption.

Putting it All Together

As you read through this article you may have noticed that much of the protocol is common, regardless of the EAP method that is used to authenticate and to generate the Master Session Key. For this reason, the actual amount of code that needs to be modified in order to implement EAP-KeccakV1 in the context of WPA2 is minimized. Our plan is to start with FreeRADIUS, which is one of the most popular (and opensource) RADIUS implementations. In particular, Supplicant code will need to be modified to sign messages using the user’s selected Ethereum account. Concurrent with implementing and testing the code on eg. a laptop computer, we will refine and submit a draft specification to the appropriate standards committee. Once the standard is accepted we will begin work on the Android wpa_supplicant daemon (which is a modified version of the HostAp supplicant). Getting the modified wpa_suplicant into an official release of Android will be the coup de gras — but will most likely be predicated on acceptance of the EAP-KeccakV1 standard.

The idea of authenticating to networks without entering a password… actually without ever sharing a password, and with enhanced security is so powerful that it really should catch on like wildfire. The Ethereum Wildfire Project is at the forefront of promoting this technique. If you believe in Ethereum, and if you want to see this technology incorporate Ethereum into the daily lives of millions of people, then join us on our journey — visit the EWP website for more information and to participate in our seed-funding token sale.

Yaniv Shapiro and Radhika Anand

for the Ethereum Wildfire Project