Durmus, Y. and Langendoen K.G. WiFi Authentication through Social Networks – a Decentralized and Context-Aware Approach –. In 5th Int. Workshop on Pervasive Collaboration and Social Networking. PerCol 2014
WiFi is the dominant access network technology due to its high capacity and zero cost. And the dominant authentication method is the use of passwords. Passwords are handy, the logic behind is easily understood by the end users. However, we have many passwords, which are mostly the same since it is hard to invent and remember all these passwords. Due to the same memory issue, we have weak passwords. In the case of WiFi, especially for home networks, password is not something secret, it is rather public. We share our passwords with all of our guests.
A promising idea that deserves additional attention as the integration of social networks in WiFi authentication can completely remove the need for password distribution/sharing. I will refer to such integrated systems as social WiFi access points.
Existing solutions for social network integration assign a centralized system to control the authentication process. For example, Meraki and many other companies use captive portal to let the users access to the network via social network login. After joining to the WLAN, captive portal keeps you in a walled garden and only allows you to access a social network authentication page or a payment page. The problem with this approach is first of all, you are already inside the WLAN therefore any mistake in walled garden configuration can lead to open holes. Secondly, due to two step authentication first you are annoyed that you need use browser even if you just plan to check your emails. And second, if the device does not have a browser like sensors, embedded systems there is no way that they can access to the network. Lastly, humans are always in the loop with captive portal, you cannot automate authentication process.
A second example is Instabridge, who created its own centralized online social network, and uses that to distribute the WiFi password among the friends of an AP owner. Obviously, password distribution and revoke are costly. And in a company network scenario, you cannot track the identity of the connected customers. You only know their MAC addresses.
Apart from the above issues, centralized approaches for creating social WiFi APs cannot be used offline (i.e., fail without Internet connectivity). Some of them are prone to single-point-of-failure and scalability problems, and generally they raise privacy concerns. To address these drawbacks we advocate a decentralized approach in which individual APs take full control and perform the device authorization themselves; access will be granted when a trust relation can be established between the AP owner and the owner of the client device as recorded in a social network.
We design a decentralized authentication system by leveraging the WebID. WebID uses well-known ontologies like Friend-of-a-Friend (FOAF) that are designed to solve the interoperability problem among online social networks. Instead of shared secrets (i.e. passwords), X509v3 certificates are used for authentication. These certificates are adapted to connect the devices they represent to a social network by including a link (URI) to a social profile on the web. Both devices and humans must publish their social relations (owners, friends) in these profiles to allow for an integrated solution. We merge WebID with Extensible Authentication Protocol-Transport Layer Security (EAP-TLS) and call it as EAP-SocialTLS.
To validate our design of decentralized social WiFi APs, we implemented a prototype version and tested it on real hardware. We altered the EAP-TLS source, part of Hostapd as the basis for our EAP-SocTLS code. In the certificate verification part of the Hostapd code, we compare the public key to the one in the social web profile. After verification, we call an external Python library for the authorization part (i.e., searching for trust relations). Although all the extensions can be placed in Hostapd is C code, Python was selected for its ease-of-use. Note that our modification is completely transparent to the client side, who follows the normal EAP-TLS process when requesting service from the AP. The only requirement for the client device is to have a certificate with a link to the corresponding social-profile page.