Pre-shared Key Agreement for Secure Public Wi-Fi

11/07/2017
by   Seokseong Jeon, et al.
POSTECH
0

This paper presents a novel pre-shared key (PSK) agreement scheme to establish a secure connection between a Wi-Fi client and access point (AP) without prior knowledge of a password. The standard IEEE 802.11 security method, Robust Security Network Association, widely known as Wi-Fi Protected Access (WPA) and WPA2, derives a shared cryptographic key if and only if a user provides an identical password which an AP possesses, causing ofinconvenience of obtaining and entering the password. In this paper, a proposed scheme, Secure Open AP (SOAP), adopts two public key algorithms, the elliptic curve Diffie-Hellman key exchange algorithm (ECDH) and digital signature algorithm (ECDSA) to establish a secure connection between a client and an AP without having prior knowledge of a password. Implementation and experiment results demonstrate the viability of the proposed scheme.

READ FULL TEXT VIEW PDF

Authors

page 2

04/30/2021

A Novel Provably Secure Key-Agreement Using Secret Subgroup Generator

: In this paper, a new key-agreement scheme is proposed and analyzed. In...
09/10/2020

Multi-Authority Ciphertext-Policy Attribute Based Encryption With Accountability

Attribute-based encryption (ABE) is a promising tool for implementing fi...
12/28/2017

A Secure and Authenticated Key Management Protocol (SA-KMP) for Vehicular Networks

Public key infrastructure (PKI) is the most widely used security mechani...
02/27/2019

Efficient and Secure ECDSA Algorithm and its Applications: A Survey

Public-key cryptography algorithms, especially elliptic curve cryptograp...
12/14/2021

A code-based hybrid signcryption scheme

A key encapsulation mechanism (KEM) that takes as input an arbitrary str...
05/28/2020

Mitigating TLS compromise with ECDHE and SRP

The paper reviews an implementation of an additional encrypted tunnel wi...
04/21/2020

Group Key Agreement in Information Centric Networks with Tree Group Diffie-Hellman

The client-server model is known to scale badly without redundant server...
This week in AI

Get the week's most popular data science and artificial intelligence research sent straight to your inbox every Saturday.

I Introduction

With the wide distribution of mobile devices, Wi-Fi access points (APs) are becoming more available in public areas. They are mostly configured to use Open System Authentication (OSA) for clients’ convenience without having to enter a password. However, OSA provides null authentication and no protection of data traffic [1] posing security and privacy threats. On the other hand, a more recent IEEE 802.11 standard defines Robust Security Network Association (RSNA) [2] for confidentiality and integrity of data widely known as Wi-Fi Protected Access (WPA) and WPA2. It provides secure communication at the cost of inconvenience of obtaining and entering the password (pre-shared key or PSK).

In this paper, we propose Secure Open AP (SOAP) which enables a client and an AP to establish a secure connection without the prior knowledge of a password. Motivations of this work are three-fold: First, it is desirable to make free and public Wi-Fi connections secure. Second, captive portals, typically adopted in airports, coffee shops, etc, appear to offer secure connections with a login page and legal notices. However, they mostly use OSA and do not adequately warn that the communication is not protected [3], [4]. Third, authentication and security go hand in hand in Wi-Fi security algorithms. SOAP separates the two and thus, allows an AP to require no authentication but to provide message protection for each connected client.

To this end, SOAP adopts two public key algorithms, a key agreement algorithm and a digital signature algorithm [5]. First, without the loss of generality, the elliptic curve Diffie-Hellman key exchange algorithm (ECDH) is used to agree on a PSK. The elliptic curve digital signature algorithm (ECDSA) is adopted to prevent a possible man-in-the-middle attack. Along with it, SOAP introduces a new information element (IE) and frame format which conform to the standard and do not interfere SOAP-unaware legacy devices. Experiment results show that SOAP increases the connection delay by no more than 22 percent given the parameters used for the implementation. This is mainly due to the increased management frame size and the additional handshake messages but is not significant considering the benefit of clients’ security and convenience.

This paper is organized as follows: sec:primer briefly explains authentication and security algorithms in the IEEE 802.11 standard. sec:proposal explains the proposed mechanism, SOAP. sec:eval examines its performance and finally we will conclude this study in sec:concl.

Ii Primer

The IEEE 802.11 standard defines two classes of security algorithms, pre-RSNA and RSNA algorithms as shown in tab:security-algs.

Security class
in IEEE 802.11
Authentication
Message
Protection
Comment
Pre-RSNA OSA N/A
Convenient
but no protection
SKA WEP
Some protection
but found vulnerable
(obsolete now)
RSNA
(since
802.11i-2004)
WPA/WPA2-EAP
Used in an enterprise
environment with AS
WPA/WPA2-PSK
Used in open, public areas,
Requires a client
to enter a password
TABLE I: IEEE 802.11 security algorithms

Pre-RSNA includes Wired Equivalent Privacy (WEP) for message protection, and OSA and Shared Key Authentication (SKA) for entity authentication. While SKA can be used if WEP has been selected, both are obsolete due to their vulnerabilities and inefficiencies. An AP in an OSA (fig:osa) mode allows any client to connect to it without verification of its legitimacy.

Fig. 1: Open System Authentication procedure, which is null authentication and does not provide data protection

In RSNA, WPA can establish a secure connection between a client and an AP if and only if a client provides a valid user’s membership information (WPA-EAP mode), or if a client provides a correct password, PSK (WPA-PSK mode). The former is used in, for example, companies or universities using an authentication server (AS) such as RADIUS. The latter is used in personal or open, small-scale public areas. WPA-PSK establishes a connection between a client and an AP and derives a shared cryptographic key (pairwise transient key or PTK) using an identical password, PSK. This is accomplished via the 4-Way Handshake as illustrated in fig:wpa-key-exchange.

Fig. 2: The WPA-PSK procedure. (An AP sets a PSK at the configuration time and a client should enter an identical PSK to authenticate and derive a PTK.)

Fig. 3: The SOAP procedure. (Contrary to the existing WPA-PSK in fig:wpa-key-exchange, a PSK is agreed on using the SOAP Handshake without a user input.)

Prior to the 4-Way Handshake, a client and an AP negotiate WPA parameters by exchanging a Probe Response (PRRP), a Beacon (BCN), and an Association Request (ASSOCREQ) frame. Note that the WPA-PSK procedure in fig:wpa-key-exchange begins with null authentication (OSA) but it additionally provides a stronger authentication during the 4-Way Handshake by proving knowledge of a shared password. More specifically, the 4-Way Handshake is triggered by the AP, which uses Extensible Authentication Protocol over LAN (EAPOL) [6]. With a PSK configured at startup on the AP side and given by a user input on the client side, a PTK is derived from a PSK, SNonce, and ANonce on both sides. The identity is assessed by checking the MIC, authenticating the client. After the 4-Way Handshake, messages between the client and the AP are conveyed as encrypted. As described above, a PTK cannot be derived unless a client and an AP have a common priori knowledge.

Iii Secure Open AP

This paper aims for a user to be able to conveniently connect to an AP in a WPA-PSK mode without having to enter a password. SOAP uses two public key algorithms, ECDH and ECDSA, prior to the 4-Way Handshake to agree on a PSK on both sides so that the handshake can use it for the 4-Way Handshake as shown in fig:soap-key-exchange. alg:dh summarizes the SOAP Handshake.

1:Inputs
2:  : ECDSA public/private keys of a client and an AP
3:Output: a shared secret key
4:Exchange ECDH groups and ECDSA public keys via PRRP/BCN, and ASSOCREQ
5:Negotiate an ECDH group (alg:ie)
6:Initialize an ECDH generator (primitive element)
7:Generate ECDH private keys
8:
9:Generate ECDH public keys
10:
11:Exchange and with their signature via SOAP Message 1/2
12:Agree on a shared secret
13:
Algorithm 1 SOAP Handshake

Iii-a SOAP Information Element and Elliptic Curve Negotiation

In fig:soap-key-exchange, a client and an AP first negotiate whether they will use SOAP, and if so, which elliptic curve they will use. Such information is conveyed via a newly introduced IE111 Note that BCN, PRRP, or ASSOCREQ are management frame subtypes. The frame body of a management frame consists of IEs, format of which is a 1 octet Element ID (EID) field, a 1 octet Length field, and a variable length element-specific Information field. Predefined elements are SSID (EID 0), Supported Rates (EID 1), TIM (EID 5), etc. , SOAP IE, which is included in the frame body of a PRRP, a BCN and an ASSOCREQ and is defined as in fig:soap-ie. Element ID is set to 251 which is a reserved value and is not used in the current standard. Group count represents the number of available elliptic curve groups and Group list is a list of 1-octet long integer identifiers representing elliptic curve groups.

Element ID Length Information
Group
count
()
Group
list
ECDSA
key
size ()
ECDSA
public
key
Octets 1 1 1 1
Fig. 4: SOAP IE

The AP first announces a set of available elliptic curve groups, , via a SOAP IE included in a PRRP/BCN. Upon receiving a PRRP/BCN, the client having its own supported set of groups, , (i) computes a common set , (ii) selects among the set with the largest key size , i.e., the highest security level, and (iii) sends it back to the AP via a SOAP IE included in an ASSOCREQ.

ECDH group negotiation can be summarized as alg:ie.

1:Inputs
2:: A set of ECDH groups available on each side
3:Output
4:: A negotiated ECDH group
5:An AP sends a PRRP/BCN to a client with
6:
7:if  then WPA-PSK mode
8:     The client requires a user to enter a password
9:     The client sends an ASSOCREQ to the AP without
10:else SOAP mode
11:     The client selects with the largest key size among
12:     The client sends ASSOCREQ to with to the AP
13:end if
Algorithm 2 ECDH group negotiation

Iii-B SOAP Handshake and Message Formats

After ECDH group negotiation is completed, the client and the AP first initializes ECDH machines with the negotiated group and generates their own private keys and public keys , respectively. The client and the AP exchange their ECDH public keys via SOAP Message 1 and 2. The AP sends its ECDH public key with its signature via a SOAP Message 1 to the client. Receiving the SOAP Message 1, the client sends and its signature via a SOAP Message 2 back to the AP. After exchanging and verifying a SOAP Message from each other, the client and the AP must be able to agree on a . And the AP triggers the 4-Way Handshake and both use instead of during the handshake.

Frame body of SOAP Message 1 and 2 is defined as shown in fig:soap-message.

EAPOL header Packet body
Protocol
version
Packet
type
Packet
body
length
ECDH
public
key
ECDSA
signature
Octets 1 1 2 variable variable
Fig. 5: Frame body of a SOAP Message.

Like an EAPOL-Key frame used in the 4-Way Handshake, a link layer control (LLC) header is prepended to SOAP Message 1 and 2 so that they are routed in a different reception and processing path than a normal data frame. In other words, a SOAP Message is a variant of an EAPOL-Key frame. Protocol version and packet type are currently set to 0xff which is a reserved value and is not used in the current IEEE 802.1X standard. The EAPOL header is followed by ECDH public key and its signature, whose lengths are determined by the previous negotiation process.

Note that messages for the SOAP Handshake are signed with the ECDSA private keys as mentioned earlier. The SOAP IE in fig:soap-ie contains an ECDSA public key of a sender (the client or the AP) to be used in the SOAP Handshake. It is used to sign the SOAP messages. SHA-256 is used for digestion. The client and the AP can verify the authenticity of a counterpart with the signature.

Iv Evaluation

Iv-a Feasibility and Applicability

Iv-A1 Implementation

We implemented SOAP on a Linux laptop. Kernel versions of 3.13 and 4.4, and Atheros AR9565 Wi-Fi NIC supporting IEEE 802.11b/g/n are used for evaluation. Most Linux distributions use wpa_supplicant as a backend daemon for a WPA client. We modified it to implement SOAP on a client side. Note that wpa_supplicant operates in user space, and can be used on other operating systems, and thus exhibits great applicability. For an evaluation purpose, SOAP is implemented using hostapd on an AP side. Both a client and an AP support 224-bit (28-octet) long key for both ECDH and ECDSA. The implementation is publicly accessible via [7].

Iv-A2 Coexistence with legacy devices

First, according to the standard, an IE with an unknown element ID in a management frame shall be discarded silently and it does not produce any side effect (BCN, PRRP, or ASSOCREQ implementing SOAP). Second, while a SOAP Message is an EAPOL-Key frame variant with an invalid EAPOL header, it shall not be generated unless a SOAP IE is exchanged prior to the SOAP Handshake. Even if it is transmitted by misbehavior, a SOAP-unaware device shall discard it silently, too. Note that a SOAP-aware client and AP also can establish a connection using a legacy WPA-PSK mode.

Iv-B Security Analysis

Since SOAP relies on the solid foundations of ECDH and ECDSA, a SOAP-capable client and AP are able to securely agree on a PSK. This section enumerates potential threats to SOAP and presents the corresponding security analysis as shown in tab:security-analysis.

In the table, the vulnerability due to message injection and masquerading are inherited from OSA. A client may connect with a rogue AP and is allowed a DoS attack and privacy leakage. We expect it can be resolved by obtaining ECDSA keys being managed globally for trustful APs, which is analogous to HTTPS certificates. Another vulnerability of connection hijacking can be caused by injecting a disassociation frame before SOAP handshake, which applies to WPA in the same manner. Note that it cannot hijack a connection (session), and only can disconnect a client from an AP. This can be resolved if management frames are also signed and verified with ECDSA keys.

Threat or criterion Security analysis (✓: Secure, ✗: Vulnerable, ➥: Possible solution)
Ephemeral ✓ Ephemeral is obtained at every new SOAP handshake
Elliptic curve key size ✓ 224-bit elliptic curve is acceptable until 2022 or later [8, 9]
Acitve/passive eavesdropping remains secret owing to confidentiality property of ECDH
Message replaying ✓ Properly implemented SOAP state machine can prevent replay attack by discarding replayed frames
Message deletion and interception ✓ It can cause DoS but requires techniques such as jamming which apply to all other Wi-Fi communication
Message injection ✗ It can cause DoS if PRRQ, PRRP and BCN containing an incorrect ECDSA public key are injected
➥ It can be filtered by blacklisting a device with repetitive ECDSA verification failure
Masquerading (MAC/SSID spoofing) ✗ Vulnerable as OSA if a client and an AP accept PRRQ, PRRP and BCN frames from an attacker
➥ Once correct ECDSA public keys are exchanged, masquerading has no effect
Connection hijacking ✗ An attacker can disconnect a client from an AP by sending a disassociation frame, causing DoS
➥ But it cannot hijack due to the attacker has a different ECDSA public key
➥ Disassociation can be prevented if management frames are signed and verified with ECDSA
TABLE II: Security analysis of SOAP

Iv-C Network Performance Analysis

Iv-C1 Connection establishment delay

An extra delay due to the SOAP Handshake is inevitable. We measure the time taken to establish a secure connection between a client and an AP. The delay is measured on an AP side, and is defined by a time interval from when an Association Response frame is sent and to when an EAPOL-Key Message 4 is sent. hostapd is modified to measure time of each event in microsecond precision. It is measured 1,000 times, plotted and compared in fig:delay. The mean extra delay caused by the SOAP Handshake is 3.65 ms, which corresponds to approximately 22 percent higher delay compared to the 4-Way Handshake (WPA-PSK).

Fig. 6:

Cumulative probability of connection establishment delay. (Mean delay is 16.44 ms and 20.09 ms without and with SOAP scheme, respectively. Mean difference is 3.65 ms and it corresponds to approximately 22 percent additional time delay.)

Note that this delay is only involved when a client and an AP attempt to establish a connection. Hence the impact of additional delay due to SOAP is trivial.

Iv-C2 Network Overhead

Overheads of a SOAP IE and a SOAP Message are measured and compared in fig:eval-frame. It is assumed that a client and an AP support one common ECDH group and use a 224-bit elliptic curve as discussed earlier, thus and in fig:soap-ie, and a SOAP IE occupies 33 bytes, where ECDSA Public key field takes up a major portion (28 octets; 85 percent). It corresponds to up to 24 percent of overhead as shown in fig:eval-overhead. Adding another ECDH group to the IE only takes up 1 more octet.

Size of a SOAP Message is calculated as the sum of ECDH key size and ECDSA signature size, which is double of ECDSA key size. Assuming ECDH and ECDSA use an 224-bit elliptic curve, a SOAP Message is 148 bytes long including a MAC header, while an EAPOL-Key frame is 195 bytes long as shown in fig:eval-message.

(a) Management frame overhead due to SOAP IE
(b) SOAP Message size
Fig. 7: Frame length evaluation

V Conclusion

Motivated by the need of open but secure Wi-Fi communication, this paper proposes SOAP, which renders a client and an AP to securely agree on a PSK using two public key algorithms as an extension of WPA-PSK. The proposed scheme adopts a key agreement algorithm, ECDH and a digital signature algorithm, ECDSA for that purpose.

We expect that SOAP can secure a public Wi-Fi network without introducing inconvenience for a provider and a consumer, and also that it can be used to construct a secure IoT network with automated process. We further think SOAP can be extended to use a certificate instead of a simple public key algorithm and signature to manage and assess a trusted public AP in a global scale against a rogue AP.

References

  • [1] N. Cheng, X. O. Wang, W. Cheng, P. Mohapatra, and A. Seneviratne, “Characterizing privacy leakage of public wifi networks for users on travel,” in 2013 Proceedings IEEE INFOCOM, April 2013, pp. 2769–2777.
  • [2] “IEEE Standard for Information technology–Telecommunications and information exchange between systems Local and metropolitan area networks–Specific requirements - Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications,” IEEE Std 802.11-2016 (Revision of IEEE Std 802.11-2012), pp. 1–3534, dec 2016.
  • [3] D. Mancinelli, “Public wi-fi: Friend or foe?” 2013.
  • [4] K. Larose and D. Dolson, “CAPPORT Architecture,” Internet Engineering Task Force, Internet-Draft draft-ietf-capport-architecture-00, Sep. 2017, work in Progress. [Online]. Available: https://datatracker.ietf.org/doc/html/draft-ietf-capport-architecture-00
  • [5] A. J. Menezes, Elliptic curve public key cryptosystems.   Springer Science & Business Media, 2012, vol. 234.
  • [6] “IEEE Standard for Local and metropolitan area networks–Port-Based Network Access Control,” IEEE Std 802.1X-2010 (Revision of IEEE Std 802.1X-2004), pp. 1–205, 2010.
  • [7] S. Jeon, C. Yu, and Y.-J. Suh. Secure Open AP application and source code. [Online]. Available: https://github.com/secure-open-ap/hostap
  • [8] E. Barker, “Recommendation for key management part 1: General,” Tech. Rep., jan 2016. [Online]. Available: https://doi.org/10.6028/nist.sp.800-57pt1r4
  • [9] “Kryptographische verfahren: Empfehlungen und schlüssellängen,” Tech. Rep., feb 2017. [Online]. Available: https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/TechnischeRichtlinien/TR02102/BSI-TR-02102.pdf?__blob=publicationFile