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  posing security and privacy threats. On the other hand, a more recent IEEE 802.11 standard defines Robust Security Network Association (RSNA)  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 , . 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 . 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.
The IEEE 802.11 standard defines two classes of security algorithms, pre-RSNA and RSNA algorithms as shown in tab:security-algs.
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.
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.
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) . 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.
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.
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.
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|
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-a Feasibility and Applicability
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 .
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
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).
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.
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.
-  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.
-  “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.
-  D. Mancinelli, “Public wi-fi: Friend or foe?” 2013.
-  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
-  A. J. Menezes, Elliptic curve public key cryptosystems. Springer Science & Business Media, 2012, vol. 234.
-  “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.
-  S. Jeon, C. Yu, and Y.-J. Suh. Secure Open AP application and source code. [Online]. Available: https://github.com/secure-open-ap/hostap
-  E. Barker, “Recommendation for key management part 1: General,” Tech. Rep., jan 2016. [Online]. Available: https://doi.org/10.6028/nist.sp.800-57pt1r4
-  “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