eindhoven university of technology master credential

Eindhoven University of Technology

MASTER

Credential sharing based on Hotspot 2.0 release 2 specification

Tan, H.

Award date:2017

Link to publication

DisclaimerThis document contains a student thesis (bachelor's or master's), as authored by a student at Eindhoven University of Technology. Studenttheses are made available in the TU/e repository upon obtaining the required degree. The grade received is not published on the documentas presented in the repository. The required complexity or quality of research of student theses may vary by program, and the requiredminimum study period may vary in duration.

General rightsCopyright and moral rights for the publications made accessible in the public portal are retained by the authors and/or other copyright ownersand it is a condition of accessing publications that users recognise and abide by the legal requirements associated with these rights.

• Users may download and print one copy of any publication from the public portal for the purpose of private study or research. • You may not further distribute the material or use it for any profit-making activity or commercial gain

https://research.tue.nl/en/studentTheses/0be5a604-87a8-42ef-bc08-7dd60019d189

Credential Sharing basedon Hotspot 2.0 Release 2

Specification

Master Thesis

Hongyu Tan

Department of Mathematics and Computer Science

Supervisors:Dr. Dmitri Jarnikov

Prof. Dr. Johan LukkienDr. Alexander Serebrenik

Eindhoven, August 2017

Abstract

With the blooming development of Wi-Fi hotspot networks, new Hotspot 2.2 (HS2.2) stand-ard are released for establishing more convenient and secure connection to the Wi-Fi networks.In this standard, service providers (SPs) can provision username/password credential or cer-tificate credential to client devices within the hotspot network. This may lead to credentialsharing that devices in hotspot networks share and reuse the same credential to access to thesubscription service, which brings huge risks to both SPs and legitimate users. The HS2.2standard specifies the sharing policy only for username/password credential. Therefore, thisthesis first addresses certificate credential sharing problem existing behind HS2.2 networks andanalyzes the information needs to be shared between the legit and the pirate non-SIM mobiledevices. Based on literature studied, six candidate approaches for certificate credential sharingproblem are proposed. These approaches allow SPs to detect and/or prevent the sharing of cer-tificate credential from different perspectives. Each approach has its own strength, limitation,and impacts on HS2.2 networks. To this end, I proposed a risk management system combin-ing most of approaches to mitigate against certificate credential sharing in a HS2.2 environment.

Key words: HS2.2 network, non-SIM mobile device, certificate credential, credential sharing

ii Credential Sharing based on Hotspot 2.0 Release 2 Specification

Acknowledgements

I would first like to thank Eindhoven University of Technology (TU/e) and Irdeto for this op-portunity to study and research in the area of embedded systems and security. I would like toexpress my gratitude to all the people who are involved in this research project.

I am grateful to my university supervisors, Dr.Dmitri Jarnikov and Prof.Dr.Johan Lukkienof the Department of Mathematics and Computer Science at TU/e. I am also grateful to mycompany supervisors, Dr.Calin Ciordas, Dr.Milosh Stolikj, and Dr.Peter Roelse, for their en-couragement and great help through the process of this master thesis. Without their insightand guidance, my thesis would have undoubtedly been more difficult. I would also like to thankDr.Alexander Serebrenik for being my exam committee member. Additionally, I would like tothank my classmates, Xiaojia Qu, Yuefeng Wu, Yongyi Wei and Zemin Piao for their kindlysupport. During this two-year study, we have witnessed each other’s growth in both study andlife. I wish them all the best in their future lives. Finally, I would like to express my veryheartfelt gratitude to my parents for providing me with continuous support and encouragementthroughout my years of study.

Hongyu Tan

August 6th, 2017

Credential Sharing based on Hotspot 2.0 Release 2 Specification iii

Contents

Contents iv

List of Figures vi

List of Tables vii

1 Introduction 1

1.1 Problem Statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.1.1 Credential Sharing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.1.2 Credential Sharing for HS2.2 . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.2 Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.3 Contributions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2 Literature Review 4

2.1 Hotspot 2.0 Release 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2.2 The Generic Architecture of HS2.2 . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2.3 Connection Establishment using HS2.2 . . . . . . . . . . . . . . . . . . . . . . . . 6

2.4 First-Time Subscription . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.5 Reconnection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.6 Authentication Methods in HS2.2 . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.6.1 Secure Authentication and Open Authentication . . . . . . . . . . . . . . 11

2.6.2 Local Authentication and Remote Authentication . . . . . . . . . . . . . 13

3 Credential Sharing in HS2.2 16

3.1 HS2.2 Certificates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

3.2 HS2.2 Certificate Enrollment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

3.3 The Usage of Credential Sharing . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

3.4 Certificate Credential Sharing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

3.4.1 Use cases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

3.4.2 The Analysis of Sharing Information . . . . . . . . . . . . . . . . . . . . . 19

3.4.3 The technical feasibility of certificate credential sharing . . . . . . . . . . 21

4 Addressing the Certificate Credential Sharing Problem 22

4.1 Token-based Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

4.1.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

4.1.2 Detailed Specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

4.1.3 HS2.2 Case . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

iv Credential Sharing based on Hotspot 2.0 Release 2 Specification

CONTENTS

4.2 Remote Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 354.2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 354.2.2 Detailed Specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 354.2.3 HS2.2 Case . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

4.3 Device Fingerprinting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 374.3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 374.3.2 Detailed Specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 374.3.3 HS2.2 Case . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

4.4 Secure Storage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 424.4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 424.4.2 Detailed Specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 424.4.3 HS2.2 Case . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

4.5 Summarizing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

5 Risk Management System 445.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 445.2 HS2.2 Case . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

5.2.1 The structure of the RMS . . . . . . . . . . . . . . . . . . . . . . . . . . . 455.2.2 The working process of the RMS . . . . . . . . . . . . . . . . . . . . . . . 46

5.3 Analysis of the RMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 505.3.1 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

6 Conclusions and Future Works 526.1 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 526.2 Future Works . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

Bibliography 54

Credential Sharing based on Hotspot 2.0 Release 2 Specification v

List of Figures

2.1 The generic HS2.2 network deployment . . . . . . . . . . . . . . . . . . . . . . . 62.2 The four stages for first-time subscription . . . . . . . . . . . . . . . . . . . . . . 72.3 The general flow chart of HS2.2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.4 The structure of OMA Device Management Tree . . . . . . . . . . . . . . . . . . 92.5 The association and authentication steps of reconnection . . . . . . . . . . . . . . 112.6 The message flow of EAP-TLS mutual authentication . . . . . . . . . . . . . . . 122.7 The 802.11 open authentication and association between the client device and

the AP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132.8 The working processes of local authentication in the first-time subscription and

reconnection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

3.1 The message flow of client certificate enrollment process . . . . . . . . . . . . . . 173.2 The example of certificate credential sharing . . . . . . . . . . . . . . . . . . . . . 193.3 All the Information for Certificate Credential Sharing . . . . . . . . . . . . . . . 21

4.1 The token-based authentication approach used in the web applications . . . . . . 234.2 Original certificate credential sharing between authorized and unauthorized devices 244.3 The sequence diagram of the Secure Access stage without using the first approach 264.4 The sequence diagram of the Secure Access stage when using the first approach . 274.5 Alleviating certificate credential sharing based on the subscription remediation

process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 284.6 The circumstances when the SP can and cannot detect the presence of certificate

credential sharing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 294.7 Alleviating certificate credential sharing based on newly generated tokens . . . . 304.8 The sequence diagram of the OSU process and Secure Access without using the

second approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 314.9 The sequence diagram of the generating new token approach . . . . . . . . . . . 324.10 The sequence diagram of the OSU process and Secure Access . . . . . . . . . . . 39

5.1 The risk management system for SPs in HS2.2 networks . . . . . . . . . . . . . . 455.2 The flow chart of the risk management system . . . . . . . . . . . . . . . . . . . 47

vi Credential Sharing based on Hotspot 2.0 Release 2 Specification

List of Tables

2.1 The authentication methods used for first-time subscription and reconnection . . 15

3.1 The basics certificate fields of X.509V3 public key certificate . . . . . . . . . . . . 16

4.1 The comparison between the two token-based approaches . . . . . . . . . . . . . 354.2 A list of tested features of passive fingerprinting . . . . . . . . . . . . . . . . . . . 414.3 The Use of Each Approach for Certificate Credential Sharing Problem . . . . . . 43

Credential Sharing based on Hotspot 2.0 Release 2 Specification vii

Chapter 1

Introduction

In recent years, Wi-Fi hotspot networks are growing in popularity as a means of providingdevices access to packet data services, e.g. the Internet, offered by service providers (SPs).Hotspot 2.0 (HS2.0) is a new standard specified by Wi-Fi Alliance for the next generation Wi-Fi hotspot networks [18]. The benefit of this new standard is that mobile devices are able toautomatically establish a secure connection to the Wi-Fi networks. Moreover, HS2.0 enablesseamless roaming within the same Wi-Fi network and among Wi-Fi networks. For example,for those people who are moving around in a city space, their mobile devices could automatic-ally get secure access to the subscribed service offered by one particular SP through differenthotspot networks in the case that both hotspot networks and mobile devices are HS2.0 capableand those hotspot networks support this SP.

So far, this standard has two versions which are Release 1 (HS2.1) and Release 2 (HS2.2).HS2.1 specifies the automatic and secure connection process under the premise that mobiledevices already have credentials to access a subscription service of a certain SP. But the sourceof credentials is unknown, which could be actively set up by the user like username/password orpassively supplied by SPs. HS2.2 standard not only defines the source and type of credential butalso specifies the credential provisioning process on top of HS2.1. Nevertheless, the credentialmanagement after provisioning is rarely discussed, e.g. credential sharing. Credential sharingrefers to that user credentials for subscription services offered by SPs are being shared withother users or devices both willingly and unknowingly. That is to say, credentials can be extrac-ted from one device and used fraudulently on other devices, which may result in compromisedaccounts. Consequently, credential sharing will be a potential problem for HS2.0 networks.

In addition to HS2.0 networks, there are also HS1.0 networks. The HS1.0 network is a com-mercial hotspot network or a captive portal hotspot network [11]. Once users connect to theHS1.0 network, they are redirected to for payment to be granted access to networks. SPs donot provision any credential to mobile devices and users do not need to provide credentialsfor authentication. In other words, there is no credential existing in this pay-per-use hotspotnetwork. Consequently, credential sharing is not a problem for HS1.0 networks. For my work,I only consider the credential sharing problem regarding credentials provisioned by SPs, that isto say, for HS2.2 networks.

Credential Sharing based on Hotspot 2.0 Release 2 Specification 1

CHAPTER 1. INTRODUCTION

1.1 Problem Statement

1.1.1 Credential Sharing

Credential sharing is a well-known problem that has existed and been studied for many years[5] [8] [30]. In general, credential sharing means reusing the credential of one user on a commonsubscription by another user and getting access to the service corresponding to it. The pair ofuser ID and password is the credential that is commonly used. Basically, there are two maintypes of credential sharing happening per user account.

The first type is casual sharing. Casual sharing means that users willingly share credentialswith someone else, particularly among friends and family members. In that case, each SPshould have clear policies as to how many users or devices are allowed to share the same cre-dential, otherwise credentials can be shared in an unauthorized manner. For example, Netflixhas a subscription plan that allows multiple devices to be simultaneously used per subscriber.Unlike Netflix, Spotify allows the Family plan that one subscription can be shared with up to6 members of the same family. However, casual sharing may result in some significant negativeeffects for those service providers (SP). For Netflix, as a consequence of credential sharing, onesubscriber can pay, share the password required to access the service with someone else (andthe subscription costs normally); the two then together can simultaneously access Netflix as faras they dont go above the device limit for the use together. The damage for Netflix in thisparticular case is that they have one paying subscriber and one not paying. The non-payingcustomers gain unauthorized access instead of taking a legitimate subscription. For the ”Fam-ily” plan of Spotify, the definition of family is vague, and there is nothing stopping users fromfreely sharing the subscription further. Furthermore, it can be difficult for the SP to tell thedifference between casual sharing and malicious sharing.

The second type is credential stealing. As the name implies, credential stealing means thatunknown to the rightful users, credentials are stolen by attackers through various methods,such as phishing scams, malware, brute force attacks, and etc [25]. By pooling of credentials forsubscription services, attackers can access services illegally or sell valid accounts with a groupof people, which brings huge risks to both SPs and legit users. Therefore, as a real concernof service providers, no matter it is casual sharing with friends or credential stolen by attack-ers, credential sharing may result in the loss of revenue, the loss of potential customers andaccordingly affects the brand reputation.

1.1.2 Credential Sharing for HS2.2

Currently, some hardware-based and software-based solutions have been proposed for prevent-ing general credential sharing such as generating unique password [1], using token during theauthentication process [19] [29], adopting biometric authentication systems to get unique useridentity information [21], etc. However, there is no related research work about credential shar-ing in the HS2.2 environment.

In the HS2.2 standard, username/password credential and certificate credential are the onlytwo types of credential that can be provisioned by SPs. The SP has the option to allow theusername/password credential sharing between multiple devices for accessing a common ser-

2 Credential Sharing based on Hotspot 2.0 Release 2 Specification

CHAPTER 1. INTRODUCTION

vice in HS2.2 networks. For this purpose, along with the username/password, correspondingsubscription configuration is also provisioned to the mobile device, indicating whether the user-name/password credential is usable only on the mobile device which subscribed or usable byother mobile devices of the user as well [18]. Unlike for the username/password credential shar-ing, the HS2.2 standard does not specify an option for the SP to allow credential sharing ifcertificates are used. However, it does not mean that illegal certificate-based credential sharingwill not take place in the HS2.2 networks. Therefore, there exists a need to study the certificatecredential sharing problem and find a proper solution for this new standard.

1.2 Goals

There are two goals of this thesis, which are:

• Evaluate the possibility of credential sharing in HS2.2.

• Propose solutions to solve certificate-based credential sharing problem.

– Solutions to prevent credential sharing

– Solutions to detect the presence of credential sharing and then alleviate it.

1.3 Contributions

This thesis is composed of six chapters. Chapter 2 discusses in more detail about HS2.2 stand-ard, including the background, the network deployment and the working process of HS2.2networks. Chapter 3 elaborates on the certificate credential sharing problem existing behindthe HS2.2 standard, and analyzes the necessary information for completing certificate credentialsharing. Chapter 4 proposes six approaches that enable SPs to detect and/or prevent certificatecredential sharing problem. Chapter 5 proposes a risk management system for SPs, which usesa combined approach for certificate credential sharing detection and prevention. Chapter 6concludes the entire project.


Chapter 2

Literature Review

2.1 Hotspot 2.0 Release 2

In this thesis, I concentrate only on Hotspot 2.0 Release 2. Both HS2.1 and HS2.2 providesnetwork selection and secure access functions. HS2.2 focuses on improving the user experiencewhen connecting to a hotspot network by providing two more functions on top of HS2.1 whichare the Online Sign Up (OSU) and Policy provisioning. For instance, sometimes, people movingout of the original connected network range that wants to keep a continuous wireless networkconnection are required to manually select a new SP’s network, provide some personal informa-tion like email address and sign up for an account to get access to the Internet again. However,by applying the HS2.2 standard, the entire time-consuming process as described before can beautomatically accomplished by the mobile device itself.

In the HS2.2 standard, mobile devices can be divided into two categories. One is SIM-capabledevices with SIM Credential, and the other is non-SIM capable devices provisioned with user-name/password credential and certificate credential. Software-based username/password can berelatively easily obtained or copied from the device. Hardware-based SIM Credential is difficultto be obtained or copied from the device. In this thesis, I focus on the non-SIM mobile devices.

2.2 The Generic Architecture of HS2.2

According to the HS2.2 Deployment Guidelines [31], Figure 2.1 illustrates the generic HS2.2architecture that enables multiple SPs to provide services to non-SIM mobile devices on top ofthe same hotspot network. The architecture can be mainly divided into two parts: the hotspotnetwork and SP’s networks.

As shown in the figure below, each hotspot network consists of one or more access points(APs) for providing wireless connectivity to mobile devices, routers and an AAA (authentica-tion, authorization and accounting) server for local authentication or relaying messages betweenmobile devices and SPs AAA server. For each hotspot network, there is a hotspot operator whois responsible for deploying and operating the network. The hotspot operator could be the sameentity as the SP. In HS2.2 specification, there is an Access Network Query Protocol (ANQP)server residing on a Passpoint capable AP for providing mobile devices with information aboutthis hotspot network and SPs it supports.


CHAPTER 2. LITERATURE REVIEW

Each SPs network has:

• an OSU server

– The OSU server is responsible for registering new subscribers and provisioning themwith credentials in the OSU process (see Section 2.3). According to the registrationinformation provided by the user, the OSU server determines the type of credentialto provision: username/password or certificate. In case of provisioning username/-password, the OSU server will directly create and send this type of credential to thedevice. Alternatively, the OSU server will contact the certificate authority (CA) toissue a client certificate and then send the certificate to the device.

• an AAA server

– The AAA server is responsible for accounting the service usage and authenticatingsubscribers. Before the client device get the network access, it needs to performmutual authentication (see Section 2.6) with the SP’s AAA server in the SecureAccess stage (see Section 2.3).

• a policy server

– During the OSU process, the policy server is responsible for provisioning policy in-formation for network selection and updating. The policy information refers to theHome SP policy, including the preference or priority of roaming partners, the policyfor updating, IP protocol, port number, etc. In the Secure Access stage (section Sec-tion 2.3), the policy server may update the policy information to the mobile deviceaccording to the needs of the SP.

• a subscription remediation server

– The subscription remediation server is responsible for updating provisioned informa-tion, e.g. update the credential and the subscription, and correcting problems knownto the SP, e.g. certificate expiry and billing overdue. In the Secure Access stage (seeSection 2.3), the AAA server can request the mobile device to contact the subscrip-tion remediation server for the purpose of remediating the subscription. Subscriptionremediation can be divided into two types: active update and passive remediation.Active Update refers to the process that is initiated by the mobile device. Passiveremediation refers to the process that is initiated by the SP.

• a CA

– The CA is ”a collection of computer hardware, software and the people who operateit” [18]. The CA performs the following functions:

1. Issuing certificates. The CA uses the information provided by devices to createcertificates and signs the certificates. The detailed process will be explained inSection 3.2.

2. Maintaining the status information of issued certificates, e.g. expired or revoked

3. Issuing certificate revocation lists (CRLs) to indicate the revocation states ofcertificates that the same CA issued before.



4. Publishing the CRLs periodically.

Except the AAA server, all the other servers are known as subscription servers. Based onthis architecture, for example, multiple SPs like Vodafone and KPN can be accessed throughthis hotspot network. To subscribe the service offered by one of them, the mobile device firstconnects to one of the APs to the hotpsot network, and then communicates with the SPs networkthrough that AP.

Figure 2.1: The generic HS2.2 network deployment

2.3 Connection Establishment using HS2.2

When the user wants to first-time subscribe to a service offered by one intended SP, his/hermobile device shall pass through all four stages as shown in Figure 2.2 to obtain credentialsfrom that SP. The four stages are described below:

1) Discovery: The mobile device selects a Passpoint AP with which to associate and queriesfor SPs information for network selection.

2) Registration: The user provides personal information and creates an account with theselected SP.



3) Provisioning: The SP establishes credentials and subscription policy information and pro-visions them to the mobile device. Only Username/Password and certificate credentials canbe provisioned during this stage.

4) Secure Access: The mobile device mutually authenticates and associates with the SPsnetwork and then successfully get access to the subscription service.

The combination of Registration and Provisioning stages is called OSU process. Every time itreconnects to the network, the mobile device only needs to go through the Discovery and SecureAccess stages because the device has already been provisioned with credentials previously. TheOSU process is always skipped if there are valid provisioned credentials except that the mobiledevice uses client certificates which are pre-provisioned by other SP or during the manufacturingprocess. Figure 2.2 shows the entire process of first-time subscription that enables mobile deviceto have automatic and secure access to Wi-Fi network.

Figure 2.2: The four stages for first-time subscription [31]

2.4 First-Time Subscription

Figure 2.3 simply illustrates the message exchange among the mobile device, the hotspot net-work and the SP’s network during the entire working process. As shown in the diagram, thered rectangle indicates the hotspot network and the yellow one indicates the SP’s network.In the Discovery stage, since there might be more than one physical AP in one hotspot site, thenon-SIM mobile device without any credential first needs to find out an appropriate AP to asso-ciate and select a SP which supports OSU through querying information with the ANQP server.The OSU Server-only authenticated layer 2 Encryption Network (OSEN) mechanism protectsthe secure association and communication between the mobile device and the AP. The OSENassociation consists of 802.11 open authentication and association, anonymous EAP-TLS au-thentication and 4-way handshake (4WHS) authentication protocol. Basically, the mobile device



Figure 2.3: The general flow chart of HS2.2

first connects to the hotspot network’s AAA server for local authentication and then establishesencryption keys with the AP for protecting the Wi-Fi link before it connects to the OSU serverof SP’s network.

In the Registration stage, the mobile device connects to the OSU server and subscribes to theintended SP through the hotspot network. The user needs to select subscription plan, providecontact information, payment information and his/her device identity information which is con-tained in DevInfo and DevDetail management objects (MOs). As documented in the OMADevice Management specification, DevInfo MO and DevDetail MO are two standard objects inthe OMA Device Management tree [2]. Figure 2.4 shows the general structure of OMA DeviceManagement Tree. The question mark in the figure means zero or one occurrence. The identityinformation of a mobile device such as:

• DevId: A leaf node of DevInfo MO, containing a globally unique identifier for the device.

• IMSI (International Mobile Subscriber Identity): A leaf node of DevDetail MO, contain-ing the mobile device’s IMSI. IMSI is a unique number to identify the user of a cellularnetwork. It is stored in the SIM card.

• IMEI MEID (International Mobile Equipment Identity and Mobile Equipment Identi-fier): A leaf node of DevDetail MO, containing the mobile device’s IMEI or MEID. IMEIis a equipment identifier for a 3GPP (3rd Generation Partnership Project) mobile deviceor dual mode 3GPP2/3GPP mobile device [18]. MEID is a equipment identifier for a3GPP2 mobile device [18].



• Wi-Fi MAC address: A leaf node of DevDetail MO, containing the MAC address ofthe mobile device.

shall be sent to the OSU server during this stage. Note that IMSI and IMEI MEID leaf nodesare optional for mobile devices not possessing SIM cards; these nodes are mandatory for mobiledevices possessing SIM cards [18]. Only HTTPS traffic is allowed between the mobile deviceand the SPs OSU server.

In the Provisioning stage, based on the information provided by the user, the OSU server

Figure 2.4: The structure of OMA Device Management Tree

decides the type of credential to provision (either Username/Password or Client Certificate eachtime), establishes subscription information contained in PerProviderSubscription ManagementObject (PPS MO) and delivers this information to the intended user. The provisioned PPS MOwill be added into the OMA Device Management tree as a leaf node under the Root node. ThePPS MO consists of some leaf nodes containing the Home SP information, subscription policy,management and credential information. For example, the PPS MO contains the following leafnodes:

• UpdateIdentifier: The UpdateIdentifier is a number set by the SP to identify the versionof the PPS MO. It is abbreviated as PPS MO ID. The value of the PPS MO ID will bechanged every time any information in the PPS MO is modified.

• Policy: This interior node contains the Home SP policy set by the policy server. Thecontent of the policy is introduced in section 2.2.

• SubscriptionUpdate: This interior node contains the information related to the sub-scription updates and subscription remediation, such as UpdateInterval and Update-Method. UpdateInterval is the parameter specifies the frequency that the mobile deviceshould check with the SP for updating the subscription configuration. UpdateMethod is



the parameter specifies the method used to update the subscription, e.g. OMA DM orSOAP XML.

• HomeSP: This interior node contains the information related to the Home SP, such as theSSID (Service Set Identifier), the friendly name, FQDN (Fully Qualified Domain Name),and etc.

• SubscriptionParameters: This interior node contains the information related to thesubscription service, such as the subscription creation date, expiration date, accumulatedusage limits in data (megabytes) or time (minutes).

• Credential: This interior node contains the information related to the credential of thesubscription, such as the credential creation date, expiration date, username/password ordigital certificate, and etc. Note that the digital certificate here is a fingerprint of thecertificate credential.

In case of provisioning certificate credential, the mobile device will generate a public/privatekey pair, and the CA will sign the public key for issuing the client certificate to the mobiledevice. Optionally, the policy server provides policy information (see section 2.2) to the mo-bile device, which will also be added into the PPS MO. Therefore, after the OSU process, theSPs infrastructure stores the subscribers information in its own registry, and the mobile devicepossesses PPS MO, OSU server certificate, SPs AAA server Trust Root CA certificate and/orclient certificate and a public/private key pair in case of provisioning certificate credential. Forclarity, the username/password credential refers to the PPS MO containing username/pass-word, subscription information and policy information. The certificate credential refers to thecombination of PPS MO and the client certificate. The client certificate is stored on the mobiledevice.

In the Secure Access stage, by using the provisioned credential, device identity informationand/or digital signature in case of certificate credential provisioned, the mobile device associ-ates and mutually authenticates with the SPs AAA server and can successfully get access tothe service that the user has subscribed.

2.5 Reconnection

Figure 2.5 illustrates the association and authentication steps of authorized client device whenit reconnects to the SP’s network. As mentioned above, at any moment it reconnects, the mo-bile device only needs to go through the Discovery and Secure Access stages if there is validcredential provisioned by the intended SP previously. In the Discovery phase, the mobile deviceutilizes the subscription and policy information configured in the PPS MO, reconnecting to theHome SPs network through the hotspot network. As shown in Figure 2.5 step 1, the deviceconnects to the AP, and then through the AP connects to the SP network’s AAA server. Atthis point, the AP relays the PPS MO ID of the device to the AAA server by using RADIUSprotocol. After that, the mobile device directly moves to the Secure Access state, skipping theOSU process. Using device identity information and username/password credential or certific-ate credential with digital signature, the mobile device can pass through mutual authenticationand get access to the subscription service again, as shown in step 2 and step 3. During theassociation and authentication with SPs AAA server, the SP may require the mobile device to



contact the subscription remediation server for updating the subscription configuration, serviceagreement, billing information, and etc.

Figure 2.5 illustrates the association and authentication steps of authorized client device whenit reconnects to the SP’s network.

Figure 2.5: The association and authentication steps of reconnection

2.6 Authentication Methods in HS2.2

2.6.1 Secure Authentication and Open Authentication

In HS2.2, the authentication between the mobile device and the AP can be classified intotwo groups: secure authentication and open authentication. Secure authentication includesanonymous authentication and mutual authentication between the client device and authen-tication server. Both types are based on Extensible Authentication Protocol (EAP) methods.The usage of different EAP methods, such as EAP-TLS, EAP-TTLS, EAP-SIM, and etc, isassociated with the credential type. For those mobile devices who hold certificate type cre-dential, EAP-TLS will be used. For those mobile devices who hold username/password typecredential, EAP-TTLS will be used. Anonymous EAP-TLS authentication means that only theserver authenticates to the client device (server-side authentication). The client device cannotauthenticate to the AAA server (client-side authentication) because there is no credential storedon the device can be provided to the AAA server for verifying. Therefore, anonymous EAP-TLSauthentication is only used during the Discovery stage for the first-time subscription. Mutualauthentication means both server-side authentication and client-side authentication should be



performed. At this point, the mobile device already obtained the credential from the OSU serverand is able to provide the credential to the AAA server for verifying. Hence, mutual authen-tication is used during the Secure Access stage for both first-time subscription and reconnection.

Figure 2.6 illustrates the message flow of mutual authentication between the mobile deviceand SP’s AAA server. At the beginning of the authentication, the identity information of the

Figure 2.6: The message flow of EAP-TLS mutual authentication

client device will be requested by SP1’s AAA server. According to the EAP-TLS authenticationprotocol, the identity is determined from the subject or subjectAltName fields (see Table 3.1)in the device certificate [27]. In the HS2.2 standard, the information included in subject fieldor subjectAltName extension is obtained from DevInfo and DevDetail MOs [18]. Hence, theidentity required by the AAA server is derived from the information in DevInfo and DevDetailMOs. After having received the identity, the AAA server requests the client device to startthe EAP-TLS conversation with an EAP-Request packet. Next, the client device responds theAAA server with an EAP-Response packet containing a client hello message. Before the clientdevice submits its client certificate (see section 3.1) to the AAA server for validation, it first au-thenticates the AAA server using the AAA server certificate and a verify message signed by theprivate key (see section 3.1) of the AAA server (server-side authentication), and subsequently,



the AAA server authenticates the device using the client certificate and a verify message signedby the private key of the client device (client-side authentication). At the end of EAP-TLSauthentication, the client device needs to negotiate with the AAA server to make an agreementon the cipher suite including encryption algorithm, hash algorithm and etc.

Except of secure authentication, the AP has an option of using open authentication with theclient device. The link between the client device and the AP will be open and unencrypted.Figure 2.7 illustrates the working flow of 802.11 open authentication and association betweenthe client device and the AP. The client device will first send an authentication request with itsMAC address as the device identity to the AP. Next, the AP will send back an authenticationresponse indicating the authentication is a success or failure. Then, the client device will sendan association request to the AP, and as the response, the AP will reply with an association IDin the case of a success.

Figure 2.7: The 802.11 open authentication and association between the client device and theAP

2.6.2 Local Authentication and Remote Authentication

The authentication between the mobile device and the AAA server can also be classified intoanother two groups: local authentication and remote authentication. Local authenticationmeans the client device authenticates with the AAA server of the local hotspot network. Re-mote authentication means the client device authenticates with the AAA server of the SP’snetwork. During the Discovery stage, according to the identity information received from themobile device, the AP may determine that the device should proceed with local authenticationor remote authentication. If the identity of the mobile device is on the hotspot network’s list oflocal users, it should perform the local authentication with hotspot network’s AAA server. Ifthe identity of the mobile device is not on that list, it should perform the remote authenticationwith SP network’s AAA server, and at this point, the hotspot network’s AAA server acts as apass-through, relaying messages between the device and SP’s AAA server.



Figure 2.8 illustrates the working processes of local authentication in the first-time subscription(the left process) and reconnection (the right process). Both local authentication processes util-ize the secure authentication methods. Comparing the secure authentication processes, thereare three differences between these two connection:

• Secure authentication method

• The object to connect

• The intention of the connection

Figure 2.8: The working processes of local authentication in the first-time subscription andreconnection

First, for the secure authentication method, the left process utilizes anonymous EAP-TLS au-thentication, while the right process utilizes mutual EAP-TLS authentication. As explainedabove, the usage of EAP-TLS authentication depends on whether the client device has beenprovisioned with credential from the SP.

Second, for the connection object, in the left process, the client device associates with theOSU AP, while in the right process, the client device associates with the production AP. Inthe HS2.2 standard, one HS2.2 capable AP should have two different virtual APs – OSU AP



and production AP. The OSU AP is used only for connecting to the OSU server, while theproduction AP is used for providing network access to the authenticated mobile device. Thechoose of the connection object links to the connection intention.

The last is the connection intention. In the left process, the client device will proceed tothe OSU process after completing the local authentication. Because the client device needs tosubscribed with the OSU server of the SP’s network to be provisioned with the subscriptioncredential. Therefore, the client device first needs to connect to the OSU AP. In the right pro-cess, in order to access to the network service, the client device will connect to the productionAP and directly move to the Secure Access stage after completing the local authentication.

Table 2.1 lists the authentication methods used for the first-time subscription and reconnection.In HS2.2 networks, the AP has two options for the local authentication: open authenticationand secure authentication. If secure authentication is adopted, for the first-time subscription,only anonymous authentication can be performed between the client device and the hotspotnetwork’s AAA server as explained above. As for reconnection, mutual authentication shouldbe performed between them. For the remote authentication, the client device should mutuallyauthenticate with the SP network’s AAA server regardless of first-time subscription or recon-nection.

Table 2.1: The authentication methods used for first-time subscription and reconnection

Authentication methods First-time subscription ReconnectionLocal authentication Open/Anonymous Open/Mutual

Remote authentication Mutual Mutual


Chapter 3

Credential Sharing in HS2.2

This chapter elaborates on the certificate-based credential sharing problem existing behind theHS2.2 standard. The first two sections introduce the client certificate and certificate enrollmentprocess in HS2.2 networks. The third section discusses the usage of credential sharing and themotivation of exploring certificate credential sharing. The fourth section analyzes the requiredinformation for completing certificate credential sharing and also the technical feasibility ofextracting this information from the authorized device.

3.1 HS2.2 Certificates

In order to consider certificate credential Sharing, it is first necessary to understand what is acertificate and how a certificate is being provisioned by the SP in HS2.2 networks. In general,certificates bind the identity of the certificate subject to the public key contained in the certific-ate [22]. According to the HS2.2 specification, client certificates provisioned to mobile devicesshall be X.509v3 public key certificates [9] based on RSA public/private key pairs. Table 3.1lists the basic fields of a standard X.509v3 certificate.

As shown in Table 3.1, an X.509V3 certificate includes three required fields: tbsCertificate,signatureAlgorithm, and signatureValue. The tbsCetificate (to be signed Certificate) field con-tains the identity of the subject and the identity of the issuer, the public key associated with thesubject, a validity period and other information. The value of signatureAlgorithm identifies the

Table 3.1: The basics certificate fields of X.509V3 public key certificate

Basic Certificate fields ContentsubjectissuervaliditysubjectPublicKeyInfo

...subjectAltName

1.tbsCertificate

extensions...

2.signatureAlgorithm algorithm3.signatureValue digital signature


CHAPTER 3. CREDENTIAL SHARING IN HS2.2

algorithm used by the CA to sign the certificate, and signatureValue contains the correspondingdigital signature by the CA. In HS2.2, the public/private key pair is generated by the mobiledevice during the OSU process (see Figure 3.1 step 4) and is stored in the device. On the onehand, the public key can be used for encrypting messages, and the corresponding private key isthen used for decrypting such encrypted messages. On the other hand, the private key can beused for generating a digital signature which can then be verified by the corresponding publickey. Since the private key is bound to a specific subject and shall not be freely shared, a validdigital signature can be used for verifying the authenticity of this subject during an EAP-TLSauthentication process.

3.2 HS2.2 Certificate Enrollment

In the provisioning stage, after it is determined to provision a certificate as the credential (seeSection 2.4), the OSU server instructs the mobile device to start the client certificate enroll-ment process by sending the execution command getCertificate, as shown in Figure 3.1. The

Figure 3.1: The message flow of client certificate enrollment process

certificate enrollment for clients adopts the Enrollment over Secure Transport (EST) protocol.The mobile device acts as the EST client, and the OSU server acts as the EST server. Inorder to request the client certificate from the CA, the mobile device should first provide itsdevice identity, e.g. DevId, Wi-Fi MAC address, IMSI, IMEI MEID, and its public key to theOSU server. As mentioned in section 2.4, this device identity information is contained in both



DevInfo MO and DevDetail MO in the OMA Device Management tree. Next, the OSU serververifies the device identity for the CA since it already received the DevInfo and DevDetail MOsduring the initial association. Once the device identity has been validated, the OSU server willrelay the client certificate request with the identity information and the public key to the CA.As the final step, the CA issues the client certificate and sends it to the mobile device throughthe OSU server. Formatted according to X.509V3, the client certificate includes informationabout the public key, the device identity and a digital signature of the CA.

3.3 The Usage of Credential Sharing

Although there are risks posed by credential sharing, for some service providers, in order tobe more attractive and increase customer loyalty, username/password sharing is considered asacceptable usage, like Netflix and Spotify examples. As mentioned in the Introduction, the SPcan provision a username/password credential to a device instead of a certificate. The HS2.2standard includes an option for username/password credential sharing. For this purpose, thestandard defines the parameter AbleToShare; this parameter is included in the PPS MO. Oncethis parameter is set to true by the SP, the entire PPS MO, which also includes the username/-password, should be shared between multiple mobile devices on a common subscription serviceto enable credential sharing. Since this type of credential sharing is legal, those mobile devicescan obtain the entire PPS MO directly from the OSU server.

The following text assumes that the SP provisions a certificate to devices. Unlike for theusername/password credential sharing, the HS2.2 standard does not specify an option for theSP to allow credential sharing if certificates are used; in particular, the standard does not specifyany parameter, subscription configuration or policies for this. In addition, the standard specifiesthat devices generate their own key pairs and that the value of the private key in such a pairis unknown to the SP. In other words, the SP cannot enable multiple devices to use the samecredentials. Since certificates are public, the certificate of one device could be used by otherdevices during their authentication process. However, without knowing the value of correspond-ing private key, another device will not be able to successfully pass the authentication process.In addition, using certificates and private keys, to some extent, is believed to be more securethan using username/password. If certificate credential can be shared and reused on multipledevices, then the risk for security and privacy will be significantly raised. Furthermore, for non-SIM devices, secrets and other critical information like private keys will not be protected byhardware, which also brings risks to both authorized users and SPs. Therefore, it is necessaryto explore certificate credential sharing in HS2.2 networks. In the following section, based ontwo use cases, all the necessary information required for sharing will be figured out, and alsothe technical feasibility of certificate credential Sharing in HS2.2 networks will be analyzed.

3.4 Certificate Credential Sharing

3.4.1 Use cases

As an example, assume there are two users, user A and user B. Both user A and user B have twomobile devices, as illustrated in Figure 3.2. All these four mobile devices are non-SIM devices



(device A1, device A2, device B1 and device B2). User A has registered his/her mobile deviceA1 with SP1 and has successfully gained access to his/her subscription service using a certificatecredential provisioned to device A1. Device A2, device B1 and device B2 have not subscribed tothe same service with SP1. Now the first use case is casual sharing (see Section 1.1.1) that user Ais willing to share device A1’s certificate credential with the other three mobile devices to allowthem to access the same subscription as device A1. As explained above, the specification doesnot support sharing of certificates and/or private keys. As a result, user A is considered to be anattacker if he/she shares the certificate or private key of device A1 with another device (such asdevice A2, device B1 and/or device B2). The second use case is credential stealing (see Section1.1.1) that device A1’s certificate credentials are stolen by user B and then used on anotherdevice. At this point, user B is considered to be an attacker. Regardless of casual sharing orcredential stealing, device A1 is the legit device, while device A2, device B1 and device B2 arethe pirate devices. After all the necessary information is extracted from device A1 and copiedto the pirate devices, each of the mobile devices A1, A2, B1 and B2 can impersonate the legitdevice A1 and access the service provided by SP1. From SP1’s perspective, it cannot detectthe real identity of an impersonating device or user if he/she illegally utilizes the duplicatedcertificate credentials to get access to the legit devices subscription service.

Figure 3.2: The example of certificate credential sharing

3.4.2 The Analysis of Sharing Information

For both use cases, the information that needs to be extracted from device A1 is identical. Nomatter if credentials are willingly shared or being unknowingly stolen, the purpose of sharing isalways to enable other mobile devices to impersonate device A1, i.e. successfully pass throughthe reconnection process ( the Discovery and Secure Access stages) using the identity of deviceA1. Therefore, the reconnection process is the key point for identifying the information requiredfor credential sharing. The first use case will be used for the following analysis.

• Discovery

At the beginning of the reconnection process, device A1 scans for HS2.2 capable networks anduses ANQP messages to perform network selection. Based on the provisioned subscription con-figuration, device A1 compares the ANQP information received from the hotspot network withthe Home SP policy and subscription specific parameters stored in the PPS MO. That is to say,



sharing the PPS MO is necessary to enable certificate credential sharing as the configurationinformation in the PPS MO is needed to ensure that other mobile devices can connect to thesame SP and use the same subscription service as user A.

After network discovery and selection, device A1 connects to the production AP and performsthe local authentication with the hotspot networks’s AAA server (see Section 2.6). As listed inTable 2.1, there are two options for the local authentication: one is the open authentication,the other is the secure or mutual authentication. The following text assumes that the AP usesthe open authentication for reconnection (see Figure 2.6).

At the beginning of the open authentication and association, device A1 will first send an au-thentication request with its MAC address as the device identity to the AP. Next, the APwill send back an authentication response indicating the authentication is a success or failure.Then, device A1 will send an association request to the AP, and as the response, the AP willreply with an association ID in the case of a success. At the end of the open authenticationand association, device A1 will associate with the production AP and automatically proceedto the Secure Access stage. During this open authentication process, device A1 only needs toprovide its MAC address to the AP. Therefore, in the case of casual sharing, user A also needsto share device A1’s MAC address with other devices to help them pass the Discovery stage. Amobile device’s MAC address is a parameter contained in the DevDetail MO (see Section 2.4).Note that just having the shared MAC address is not sufficient, the pirate devices (device A2,device B1 and device B2) need to masquerade their MAC addresses to the legit device A1’sMAC address. In general, there are two ways for mobile devices to modify their MAC address:changing the address in the memory of the network card or using software application.

• Secure Access

Skipping the entire OSU process, device A1 proceeds to mutual authentication with the AAAserver of SP1’s network. Once device A1 performs the mutual authentication successfully, itwill have network access. In section 2.6.1, Figure 2.6 explains the working process of EAP-TLSmutual authentication.

In the Secure Access stage, the mobile device performs remote authentication with the SP’sAAA server, while the AP exchanges messages between the device and SP’s AAA server. Atthe beginning of the authentication, device A1 needs to provide its DevInfo MO and DevDetailMO as the device identity information to SP1’s AAA server (see Figure 2.6 step 2). There-fore, both DevInfo MO and DevDetail MO of device A1 are information that user A needs toshare. After having received the identity, the AAA server and device A1 will perform server-side authentication and client-side authentication respectively (see Figure 2.6 step 5,6). DeviceA1 first authenticates the AAA server using the AAA server certificate and a verify messagesigned by the private key of the AAA server, and subsequently, the AAA server authenticatesdevice A1 using the client certificate and a verify message signed by the private key of deviceA1. Server-side certificates and signatures do not need to be validated in order to establish anillegal connection. Therefore, in the case of casual sharing, both client certificate and the privatekey should be extracted from device A1. Note that at the end of EAP-TLS authentication, noadditional information needs to be shares for negotiating the cipher suite (see Figure 2.6 step7-9).



All the necessary information that is needed for another mobile device in order to associatewith SP1’s network and complete the mutual authentication has now been identified. Conclud-ing, in order to impersonate device A1, there are five elements that need to be shared, whichare:

1. the PPS MO,

2. the client certificate,

3. the private key,

4. DevInfo MO and

5. DevDetail MO,

as also shown in Figure 3.3. The first two are provisioned by the SP, while the others aregenerated or owned by the mobile device itself.

Figure 3.3: All the Information for Certificate Credential Sharing

3.4.3 The technical feasibility of certificate credential sharing

Only knowing the information that needs to be shared is insufficient for proving the possibilityof certificate credential sharing. Extracting this information from device A1 should also betechnically feasible. In non-SIM devices, the information will not be protected by hardwaremeasure. As a result, this information is stored in software which generally offers a lowerlevel of security. Consequently, attackers can typically extract the information, e.g. throughinterfaces or by using malicious applications. Therefore, the conclusion is that the possibilityof certificate credential sharing does exist in HS2.2 networks.


Chapter 4

Addressing the CertificateCredential Sharing Problem

In order to mitigate certificate credential sharing problem in HS2.2 networks, the SP can eitherprevent sharing or first detect the presence of credential sharing and then take correspondingmeasures to solve it. This chapter will introduce six different approaches aiming to certificatecredential sharing detection and/or prevention. These approaches can be classified into fourcategories, which are token-based authentication, remote monitoring, device fingerprinting andsecure storage. Each category corresponds to one section. At the end of this chapter, a summaryabout all the approaches will be given.

4.1 Token-based Authentication

In this section, two token-based approaches will be proposed and discussed. At first, I willintroduce the concept of token and token-based authentication. Next, I will explain how thegeneral token-based method was used before and what problem this method solves. After that,I will proceed to the particular HS2.2 case to explain the application of token-based method inHS2.2 environment and propose two approaches. Then, I will discuss the implications of thesetwo approaches for HS2.2 and analyze their advantages and disadvantages.

4.1.1 Introduction

Token can be classified into two groups: hardware-based token and software-based token.Hardware-based token refers to physical devices such as key fob, smart cards, USB token,and etc. Software-based token refers to a piece of data generated by a server and containsinformation to identify a particular user. The token to be discussed below is software-basedtoken. No hardware-based token will be taken into consideration. Like certificates, tokens areusually created by a server with an expiration time after which they will become invalid andnew tokens need to be obtained from this server. In addition, tokens contain enough data toidentify a particular user.

Token-based authentication is a mechanism that utilizes server provisioned tokens to fast andsecurely identify the user or client device, which is widely applied in the web applications.Usually, a token-based authentication system allows users to log in with their username/pass-


CHAPTER 4. ADDRESSING THE CERTIFICATE CREDENTIAL SHARING PROBLEM

word to obtain token(s) for future authentication with the authentication server of the system.After token(s) are being obtained, users only need to pass the token to access to the specificresource or service. In other words, token(s) replaces the username/password and becomes newcredential.

4.1.2 Detailed Specification

Figure4.1 shows the basic message exchange between the client device and web server whentoken-based authentication is used.

Figure 4.1: The token-based authentication approach used in the web applications

Step 1. The client device first sends its authentication credentials to the AAA server.

Step 2. The AAA server verifies and validates credentials.

Step 3. If the credentials are valid, then the AAA server will generate a token. The payloadof the token contains the user identification information and the token metadata, e.g.the expiration time. After a series of cypher operations, the AAA server generates acryptographically signed message as the token.

Step 4. The AAA server sends the token to the client device.

Step 5. The client device stores the token and sends it to the AAA server in subsequentrequests. The token replaces the credentials for authentication.

Step 6. The AAA server parses the token, checks the validity of the token, and verifies theidentity of the user by comparing a database of known users.

In traditional web authentication, the application relies on the user logged in information storedon the server to verify and authenticate the user. The server needs to create and keep the au-thentication records to identify the user, which results in the burden of the server-side storage.Token-based authentication is designed to solve this problem. The server does not need to keep



the authentication records as the token itself contains the user information for the purpose ofverification, which can lower the server load.

Using tokens extends the strength of authentication. The information related to the user andthe token is encoded in the token itself, and protects against tampering with a strong crypto-graphic signature. In addition, the token will expire and be invalid after a set amount of time.In order to obtain new tokens, the user will be required to authenticate to the server once again.The server could determine the token validity period and the update frequency, e.g. one-timeused token. The validity time of the token may affect the sharing between the authorized deviceand unauthorized device and force them to be synchronized frequently. In other words, usingtokens may enable the SP to detect and prevent certificate credential sharing problem.

4.1.3 HS2.2 Case

Back to the casual sharing use case discussed in section 3.4.1, user A is willing to share thecertificate credentials of device A1 with his/her another device and user B’s devices (device A2,device B1 and device B2). Due to the uniqueness of the public/private key pair, the illegalcertificate credential sharing should be among multiple devices regardless the user. Therefore,the use case is changed to that user A is willing to share the certificate credentials of his/herdevice A with another device B. Figure 4.2 shows the original certificate credential sharingresult between the authorized device A and unauthorized device B.

Figure 4.2: Original certificate credential sharing between authorized and unauthorized devices



The red lines refer to the simplified association and authentication steps of the authorized deviceA, as the same with Figure 2.5 in Section 2.5. First of all, device A will locally authenticateand associate with an AP of the hotspot network. Next, through the hotspot network, device Awill contact to the SP’s network and mutually authenticate to the AAA server using certificatecredentials. Afterwards, the AAA server will send a EAP success message to the device indic-ating a successful mutual authentication, and then device A will have network access. Afterthat, as analyzed in chapter 3, user A shares all the necessary information (the PPS MO, theclient certificate, the private key, DevInfo MO and DevDetail MO) with device B. With thisinformation, device B can follow the same association and authentication steps as illustratedin blue lines, and have network access as device A. Note that the first two steps shown in thediagram are related to the following two token-based approaches respectively.

Approach 1. Increasing Subscription Remediation and Update Frequency

From time-to-time, the user’s subscription may require remediation or update. Subscriptionremediation is the process that the SP uses in the Secure Access stage to modify informationincluded in the PPS MO. The SP determines when subscription remediation is necessary andwhat information needs to be changed. As introduced in Section 2.2, there are two types ofsubscription remediation: active update and passive remediation. For active update, the stand-ard defines the parameter UpdateInterval included in the PPS MO (see Section 2.4). Based onthis parameter, during the Secure Access stage of reconnection, the mobile device will activelyconnect to the subscription remediation server and then update the subscription configurationwith this server at a certain frequency. If the SP requests a passive remediation, the SP’s AAAserver will signal the mobile device that remediation is needed, and then the device will connectto the subscription remediation server. In order to make the decision of passive remediation,the SP needs to know the current version of the PPS MO that stored in the mobile device. Forthis purpose, the standard also defines the parameter PPS MO ID (see Section 2.4). The valueof the PPS MO ID will be changed every time any information in the PPS MO is modified.That is to say, a new PPS MO ID will replace the old one every time active update or passiveremediation takes place in the Secure Access stage.

For the purpose of detection, the SP should keep multiple PPS MO ID in a particular user’sdatabase. If another device uses the old value of PPS MO ID for 802.11 association, then bycomparing the user’s database the SP can detect that the device should have updated its PPSMO ID and raise the suspicion of certificate credential sharing. As a result of subscription re-mediation, the pirate device is forced to synchronize the PPS MO ID to keep using the service.Back to the use cases discussed in Section 3.4.1, regardless of casual sharing or credential steal-ing, after all the necessary information is extracted from device A, the attacker can foreknowthe active update frequency through the parameter UpdateInterval to avoid out of synchroniz-ation. However, the passive remediation initiated by the SP is not predictable. Therefore, thefirst approach proposed is to use PPS MO ID as the token and increase passive remediationfrequency up to per connection.

Figure 4.3 and Figure 4.4 are two sequence diagrams that illustrate the Secure Access stagewith and without using the first approach. For Figure 4.4, the messages in bold indicates theextra working process if subscription remediation is required by the SP. In both diagrams, dur-ing the 802.11 association process, the PPS MO ID will be provided to the AP and then relayed



to the SP’s AAA server within the RADIUS Access Request message. This is also the first stepillustrated in Figure 4.2. Then during the EAP authentication, the AAA server can use thisparameter to determine if passive remediation is required or not.

• Without using the first approach

Normally, passive remediation is rarely required by the SP unless increasing the remediationfrequency or there are problems occurred, e.g. certificate expiry or billing overdue. Note thatin the HS2.2 standard, the validity period of a client certificate is two years. Thus, assumethe frequency is not increased and passive remediation is not required by the SP, then after asuccessful mutual authentication with the AAA server, device A will get access to the network,as shown in Figure 4.3.

Figure 4.3: The sequence diagram of the Secure Access stage without using the first approach

• With using the first approach

Assume passive remediation is required by the SP, the AAA server will contain a WNM (WirelessNetwork Management)-Notification Request in the RADIUS Access Accept message and send itto the AP, as shown in Figure 4.4. Next, the AP will relay this message to device A after sendingthe EAP success message. The PPS MO of device A contains the URL of the subscriptionremediation server so that device A can connect to the intended subscription remediation serveridentified by the URL. Device A will initiate a connection to the subscription remediationserver using HTTPS. After that, device A first authenticates the subscription remediation serverusing the subscription remediation server certificate and a verify message signed by the privatekey of the subscription remediation server. As device A has certificate credentials, it usesthat certificate and a verify message signed by its private key for client-side authentication.Afterwards, the subscription remediation server will update the PPS MO ID. Once receivingthe updated PPS MO ID and replacing the old one in PPS MO, device A will disassociate withthe production AP and then re-associate it using the updated PPS MO ID.

Analysis of the Approach

Figure 4.5 shows the result of casual sharing between device A and device B when device A isfrequently required to go through the subscription remediation process. Assume device B hasextracted all the necessary information from device A but have not used this information toaccess the network yet. There are three situations:



Figure 4.4: The sequence diagram of the Secure Access stage when using the first approach

1) If device A updates its PPS MO ID before device B, and device B has not synchronizedthe latest PPS MO ID yet. Device A will be provisioned with a new PPS MO ID, whiledevice B only has the old version, as shown in Figure 4.6. The SP can detect the existenceof certificate credential sharing if device B still uses the old value of PPS MO ID during802.11 association. In this case, only device A can access to the network service.

2) If device B updates its PPS MO ID before device A, and device A has not completed thesynchronization yet. Device B will be provisioned with a new PPS MO ID, while deviceA only has the old version, as shown in Figure 4.6. The SP can detect the existence ofcertificate credential sharing if device A still uses the old value of PPS MO ID during 802.11association. In this case, only device B can access to the network service.

3) If both device A and device B hold up-to-date PPS MO ID. In this case, the SP cannotdetect the certificate credential sharing. As a countermeasure of this situation, the SP canincrease the update frequency up to per connection to prevent simultaneous usage betweendevice A and device B. Even if user A is willing to share new PPS MO, either device A ordevice B can access to the network service.

On the one hand, using this approach can enable the SP to detect the presence of certificatecredential sharing when the client device (device A or device B) connects to the network beforethe synchronization between device A and device B has completed, as shown in Figure 4.6.On the other hand, if the SP requires the passive remediation every time the client deviceconnects to its network, this approach can be used to prevent simultaneous usage among multipledevices. In other words, multiple devices impersonate the same device cannot access to the samesubscription service at the same time. This approach also has its limitation: the SP cannotdetermine to choose which device to de-associate or de-authenticate after detecting the presenceof sharing, as this approach cannot enable the SP to detect the device identity.



Figure 4.5: Alleviating certificate credential sharing based on the subscription remediationprocess

Discussion

Assume the SP increases the subscription remediation frequency to per connection, then usingthis approach will have the following impacts on the HS2.2 architecture:

1) Structural Complexity: In the Secure Access stage, when the AAA server checks thevalue of PPS MO ID, it will require another token sever or the AAA server itself to keeptrack of PPS MO IDs per mobile device. In case of requiring another server, this componentneeds to be added to the SP’s network.

2) Latency: The authentication time will be extended. The authentication time Ta is givenby:

Ta1 = ta1 + ts (4.1)

where ts is the average time needed to complete one subscription remediation process, ta1is the original average time needed to complete the mutual authentication, Ta1 is the newaverage authentication time for one client device per connection. Each time the client deviceconnects to the network service, the user needs to wait Ta1 for authentication.

3) Cost: With the increase of remediation frequency, there will exists extra computation costfor the SP. The computation cost C is given by:

C = csr ∗ nrq (4.2)



Figure 4.6: The circumstances when the SP can and cannot detect the presence of certificatecredential sharing

where csr is the computation cost for updating one PPS MO ID, nrq is the average number ofreconnection requests from mobile devices per day, C indicates the total computation cost ofsubscription remediation process per day. Therefore, the SP’s computation cost will increaselinearly along with the number of reconnection requests.

Expect that, this approach modifies the working process of the HS2.2 standard. Before using thisapproach, the client device is rarely required to perform the subscription remediation process.After using this approach, every time the device connects, it will be required to contact thesubscription remediation server in the Secure Access stage.

Approach 2. Generating New Tokens

Referring to the example of web application, the second approach proposed is generating newtokens for the authentication process. Figure 4.7 illustrates the newly designed first-time sub-scription. Compared to Figure 4.2, the architecture and the working flow have been changed.This approach implements a token service on the top of the HS2.2 standard. The token serviceutilizes an API (application programming interface) that enables the SP to generate and ma-nipulate tokens bound to a particular mobile device. Through the token service, servers of theSP’s network can create new tokens, check the status of tokens, invalid tokens, and etc. Unlikethe web application example, tokens will not replace the client certificate as the credential forauthentication. In the Secure Access stage, the client device should mutually authenticate withthe AAA server with both certificate credentials and tokens. Figure 4.8 and Figure 4.9 are twosequence diagrams that illustrate the OSU process and mutual authentication process with andwithout using the second approach. For Figure 4.9, the messages in bold indicates the steps ofgenerating and validating tokens.

• Without using the second approach

As discussed in section 3.1, during the OSU process, once the SP receives the device identityand determines to provision a certificate as the credential, the OSU server will inform the clientdevice to start the client certificate enrollment process. Then the client device sends its deviceidentity attributes and a public key to the OSU server. After validating the device identity



Figure 4.7: Alleviating certificate credential sharing based on newly generated tokens

attributes, the OSU server relays them and the public key to the CA for generating the clientcertificate. Then the CA issues the client certificate and sends it to the OSU server. As the finalstep of original OSU process, the client device receives its certificate and PPS MO from the OSUserver. In the original Secure Access stage, the client device only needs to provide its certificateand a verify message signed by the private key to the AAA server for mutual authentication,as elaborated in section 3.3.2. At the end of mutual authentication, the AAA server will sendan EAP success message to the client device to indicate a successful authentication.

• With using the second approach

In the newly designed first-time subscription, receiving a token from the OSU server will befinal step of the OSU process. As shown in Figure 4.9, OSU server will call the token service togenerate token 1 and then send to the client device for the later mutual authentication with theAAA server. Token 1 is a piece of data signed by the OSU server’s private key. The payloadof token 1 contains the device identification and token metadata, e.g. the expiration time, con-figured by the SP. In the new Secure Access stage, apart from the client certificate, the clientdevice also needs to provide the previously generated token for validation and authentication.Therefore, at the end of mutual authentication, the AAA server will not send the EAP successmessage to the client device since the AAA server needs to verify the token 1.

Assume the AAA server receives the public key that corresponds to the private key used tosign the token from the OSU server. The AAA server can use this public key to verify the di-gital signature of token 1. In this case, the AAA server can confirm that token 1 was generatedby the OSU server of the same SP. Additionally, the AAA server will check the validity of this



Figure 4.8: The sequence diagram of the OSU process and Secure Access without using thesecond approach

token. If token 1 is out of the expiration time, then the AAA server will send an access rejectmessage to the client device. If token 1 is not expired, then the AAA server will call the tokenservice to check if token 1 can be found in the token database link to the client device. Next,if token 1 cannot be found in the database, then the AAA server will send an access rejectmessage to the client device. If token 1 can be found in the database, then the AAA server willcheck the status of this token. Next, if the status is invalid, then the AAA server will send anaccess reject message to the client device. If the status is valid, then the AAA server will senda success message to the client device. At the end of the session, the AAA server will call thetoken service to invalid token 1 and generate another token 2. Token 2 will be sent to the clientdevice for the next authentication.


Back to Figure 4.7, it also illustrates the result of casual sharing between device A and device Bif device A uses the token as another credential for getting access to the network service. Assumedevice A has already completed the newly designed first-time subscription, and obtains certific-ate credentials and token 2 as token 1 has been used during the mutual authentication. Also,device B has extracted all the necessary information from device A. There are two situations:

1) If device A first reconnects to the network using certificate credentials and token 2. At thispoint, token 2 has become invalid since it can be only used once. If device B still uses token2 for authentication, then the SP can detect that credentials have been shared. Therefore,only device A can access to the network service.

2) If device B first reconnects to the network using certificate credentials and token 2. DeviceA cannot access to the network service unless device B shares the new token 3 generated



Figure 4.9: The sequence diagram of the generating new token approach



in the reconnection with device A. In that case, device A can access to the network service,but device A and device B cannot simultaneously access to the service.

Similar to the first approach, on the one hand, this approach can also be used to enable the SPto detect credential sharing problem when the delay of synchronization is longer than the timebetween one device’s twice connection to the network. On the other hand, this approach canprevent simultaneous usage among multiple devices even if tokens have been synchronized.

Discussion

This approach has the following impacts on the HS2.2 architecture:

1) Structural Complexity: Some components need to be added to the SP’s network, suchas the token API, the token database and a specific token server. The token server utilizesthe token API to generate tokens for a client device and then store these tokens to the tokendatabase link to the device. The token sever is also responsible for keeping track of thegenerated tokens and change the status of the token in the token database. For example,in the OSU process, when the OSU server call the token service, the token server will sendgenerated token 1 to device A through the OSU server. At the same time, the token serverwill store token 1 into device A’s token database. In the Secure Access stage, the token serverwill compare the token state received from the client device with the token state stored inthis device’s token database, and then send the check result to the AAA server.

2) Latency: The OSU time and authentication time will be extended due to the time forgenerating and authenticating tokens. The extended time can be divided into two parts: thegeneration time and the authentication time. The text above assumes that the sever everytime only creates and generates one token to the client device. In practice, the SP has theoption to generate multiple tokens to one client device. In a large scale network, the numberof tokens N to generate per day is given by:

N = nd ∗ nt, (nt ≥ 1) (4.3)

where nd is the average number of connected client devices which require to be provisionedwith new tokens per day, nt is the number of tokens per device. Assume nt is a fixed number,then N will increase linearly along with the number of connected devices which need newtokens. The generation time tg for the SP is given by:

tmin1 ≤ tg ≤ tmax1 ∗N (4.4)

where tmin1 is the minimum time for generating a token, and tmax1 is the maximum time forgenerating a token. Because the server can process multiple generation requests simultan-eously, the maximum generation time should be at most equal to tmax1∗N , and the minimumgeneration time should be at least equal to tmin1. Note that the generation of tokens canhappen offline in a batch. The server compute N tokens one time before provisioning them.Provisioning will take time as well as verification of tokens. The authentication time ta2 forthe SP is given by:

tmin2 ≤ ta2 ≤ tmax2 ∗N (4.5)

where tmin2 is the minimum time for authenticating a token, and tmax2 is the maximum timefor authenticating a token. Because the server can process multiple authentication requests



simultaneously, the maximum generation time should be at most equal to tmax2 ∗N , and theminimum generation time should be at least equal to tmin2. Therefore, the total time T perday for the SP is given by:

T = tg + ta2 (4.6)

Therefore, T is affected by nd and the computational capacity of the server. Regardless ofthe computational capacity of the server, T will increase along with nd. As a result, in alarge scale network, if there are millions of devices that require to obtain tokens at the sametime, it will cause huge latency to the SP.

3) Cost: Using this approach will result in extra computation cost to the SP. The computationcost C is given by:

C = cg ∗N (4.7)

where cg is the average computation cost of one token. Therefore, C will linearly increasealong with nd. As a result, in a large scale network, if there are millions of devices thatrequire to obtain tokens at the same time, it will cause huge computation cost to the SP.

4) Throughput: Using this approach will take up the network bandwidth and affect thenetwork traffic between connected devices and servers. The bandwidth B1 is given by:

B1 =sp ∗ nrq

24hours ∗ 3600seconds(4.8)

where brq is the average bandwidth consumption of the transmissions during token genera-tion and token authentication for each reconnection request. nrq is the average number ofreconnection requests from mobile devices per day. Thus B1 indicates the average increase inbandwidth usage of the server, and B1 will increase along with the number of reconnectionrequests. In case of millions of requests in a short time period, the increase of bandwidthconsumption could be considerably high, which may result in lower throughput and longerresponse time for each request and even network congestion.

This approach also has an impact on the HS2.2 standard, especially the working process inthe standard. The OSU process and the Secure Access stage will be modified when using thisapproach. Comparing Figure 4.8 and Figure 4.9, the token generation process is added to theOSU process, and the token authentication process is added to the Secure Access stage.

For the two token-based approaches, they utilize different parameters, PPS MO ID and thetoken, but achieve the same goal. Table 4.1 lists the difference and similarity between the twotoken-based approaches. First of all, the first approach utilizes the parameter PPS MO ID andsubscription remediation process existed in HS2.2 networks, While the second approach createa new token service on top of the HS2.2 networks. Second, the engaged stages are different.The first approach is only engaged in the Secure Access stage, while the second approach isengaged in OSU and Secure Access stage as the tokens are first generated by the OSU server.Additionally, the use of the parameter is different. Since the SP can determine the updatefrequency, one PPS MO ID could be used several times and down to once. The token is de-signed to be used only once. As for the similarity, both these two approaches force the attackerto synchronize certificate credentials under a certain frequency, and also prevent simultaneousconnection using the same identity or certificate credentials.



Table 4.1: The comparison between the two token-based approaches

Difference Increasing Sub Rem frequency Generating new tokens

ArchitectureUtilize the originalHS2.2 network deployment

Create a token serviceon the top of HS2.2 networks

Engaged stageSecure Access withsubscription remediation process

OSU process + Secure Access

ImplementationRandom update frequencyup to per connection

One-time used tokens

Similarity

Purpose- Force the attacker to synchronize certificate credentials;- Prevent two or more simultaneous connectionusing the same identity or credential

Intention Detection and prevention

4.2 Remote Monitoring

4.2.1 Introduction

In general, remote monitoring is a system for measuring conditions of an object at a remotelocation and providing information relating to measurements to an end user [14]. For example,Ruan et al., [23] proposed a remote monitoring system for health examination. The systemcollects a user’s physiological data, and then transmits to the remote web server for monitoringthe real-time physical condition of the user. Further, the user’s mobile device can displaythe physiological data in real time. Remote monitoring system is not only being applied inhealthcare, but also in the field of transportation, agriculture [20], automobile industry [16],and etc. In addition, many SPs, e.g. websites, social media platforms and email providers,use the remote monitoring system to track the location, measure the service usage and recordthe browser history of their customers for the purpose of user behavior analysis and identityverification.


Location tracking is one of common types of remote monitoring. The SP can use the locationtracking service to verify the location of legit users. Location tracking can be classified into twotypes:

1. Active tracking: The SP is monitoring from where users are accessing their service, andtries to actively verify, i.e. mailing users and asking for information, whether users liveon the same address.

2. Passive tracking: The SP can track the location of the user without being noticed by them.Usually, the SP can discover the location of the user through IP geolocation techniques.Geolocation is the process of determining the geographical location of a mobile phone,laptop or Internet-connected equipment. Geolocation uses the IP address, MAC address,radio-frequency identification and other information to specify the geographical locationof the mobile device.



4.2.3 HS2.2 Case

In HS2.2 networks, the SP could utilize remote monitoring to track the location, time and serviceusage information of a mobile device to detect the presence of certificate credential sharing. Forexample, if the same two certificate credentials are used in two countries simultaneously or ina very close time, this could indicate a sharing of the credential. Alternatively, if an inactiveaccount is suddenly being used lots of time or consumed large amounts of data, this could alsobe an indicator. These two examples utilize two types of remote monitoring data respectively.The former relies on real-time monitoring data, and the latter relies on historical monitoringdata.

Approach 3. Remote Monitoring

Under the HS2.2 environment, remote monitoring is the service that allows the SP to monitorthe location, time and service usage information of a mobile device when the device is usingthe subscription service. Remote monitoring is the approach that can enable SPs to detect theexisting of certificate credential sharing.

For the location information, as the device is located in the range of the AP, the SP doesnot need to grasp accurate coordinate position of a mobile device, but only needs to know thelocation of the AP that the device is connecting to. In other words, learning the location ofAPs can help the SP to find the approximate geographical location of the connected devices. Ifthe SP is the same entity as the HS operator, it is obvious that the SP should be familiar withthe deployment of each hotspot network and each AP. If the SP is a different entity from theHS operator, through the cooperation between each other or geolocation techniques, the SP canknow the location of APs. In HS2.2 networks, when the AP is relaying messages between themobile device and the SP’s AAA server, the AAA server can get this AP’s MAC address and IPaddress through RADIUS protocol. In other words, the SP is able to monitor the location of theconnected AP and, hence, of the connected mobile devices. For the service usage information,since accounting is one of functions of the AAA server, both the SP and the HS operator canknow the service usage of the mobile device, e.g. consumed amount of data or used service time.


The remote monitoring approach can enable the SP to detect the presence of certificate creden-tial sharing when a legit device moves to a location that is impossible to be reached in a shorttime. In other words, the SP can detect whether the certificate credential has been shared whenspace span and time span cannot be met at the same time. Another limitation is that afterdetecting the presence of credential sharing, the SP cannot determine which one is the legitdevice or which one is the pirate device as this approach cannot be used to detect the deviceidentity.

Discussion

Using this approach has the following impact to the HS2.2 architecture:

• Structural Complexity: In order to collect the IP address and determine the locationof the device, the SP’s network needs to add a specific server to support the remotemonitoring service. The server needs to be able to analyze the time span and space span



of the device and then record them into the user’s database as a known device link to theuser. Moreover, the server needs to decide that there are two accesses within a short timefar away from each other. If the server detects a discrepancy, the SP needs to identifyboth devices to determine which one is the legit device and which one is the pirate device.

For the impact on the HS2.2 standard, there is no protocol modification required.

4.3 Device Fingerprinting

4.3.1 Introduction

Device fingerprint is a set of features collected from mobile devices for the purpose of identi-fication. In order to identify a device, the value of the features should be unique or be lesslikely shared by other devices. Device fingerprinting is the process of the identification based onthe collected fingerprint information. In practice, device fingerprinting is usually used in webapplications for authentication [4]. As introduced in Section 4.2.1, browser cookies can be usedto identify users or devices in traditional web applications. However, users have the option toturn off the cookies when visit websites. Device fingerprinting can solve this problem as devicefingerprints can be collected to identify users or devices even when cookies are turned off.


In web applications, every time a client device tries to access a web page, the server will collectdifferent features from the device and its browser, e.g. the operating system (OS) and itsversion, installed plugins, screen resolution, user language, etc., to profile the user and storethis information into the user’s database. Next time when the user browses the same website,the web server will collect the same features and then compare them with the information storedin the database of known users to identify the user. One limitation of device fingerprinting isthat the features collected from the device could be modified by the legit user or the attacker.For example, the version of the OS is changed or a new OS is installed.

4.3.3 HS2.2 Case

In the HS2.2 standard, the user needs to provide contact information and payment information,e.g. credit card, bank account number as the registration data during the OSU process. How-ever, no device-related information will be provided to the SP. In addition, the mobile devicesinvestigated in this thesis are non-SIM devices, which means the SP cannot directly identify theuser or the device through the SIM card. In that case, the SP could gather various features ofclient devices and utilize device fingerprinting to detect the identity of the device. Device finger-printing can be classified into two categories: active fingerprinting and passive fingerprinting.Both of approaches could be adopted by the SP in HS2.2 networks.

Approach 4. Active Fingerprinting

In general, active fingerprinting refers to the method that a sever actively identifies clientdevices through challenge-response mechanism. The server sends some specific requests asthe challenge to the client device and analyzes the challenge response to detect the featuresand the identity of the device. For example, Bratus et al., proposed an active method for



discovering the information about the firmware or the driver of an 802.11 wireless device [6].They sent a stimulus frame to a test station and then observed the response. The advantage ofactive fingerprinting is that the challenge is flexible and the corresponding responses can differsignificantly to distinguish devices. But using this method requires time to analyze the responseand yield the result. The fourth approach I propose is to combine this active fingerprintingapproach with the HS2.2 environment. The challenge used corresponds to the fingerprint thatthe SP wants to collect. For example, if the fingerprint is some data, the challenge could be adata value query; if the fingerprint is a result of a computation, the challenge could be someexecutable codes representing the computation; if the fingerprint is a response to an error, thechallenge could be an erroneous message or a malformed packet. The following text describesthe application of executable codes as the challenge in HS2.2 environment by comparing theworking flow of the HS2.2 with and without using the approach.

• Without using the fourth approach

Without using the active fingerprinting, the OSU process and the Secure Access stage are thesame as shown in Figure 4.8.

• With using the fourth approach

Figure 4.10 illustrates the sequence diagram of the new OSU process and Secure Access stagewhen using executable codes as the challenge. There is a profiling server for generating thechallenge codes and profiling the client device. The challenge is some executable codes, but theexecution result varies from devices regardless of casual sharing or credential stealing. In theOSU process, before starting the client certificate enrollment, the profiling server will first sendthe executable codes to the client device through the OSU server. Once receiving the codes,the client device will execute them and send the result back to the server. The execution resultcan reflect some particular hardware level attributes, e.g. the memory size and the number ofprocessor cores. Then, when the profiling server receives the execution result, it will analyzethe response and profile the device. After that, the profiling server will store the analysis resultinto the user’s database as a known client device bound to the user. Every time a client deviceauthenticates to the SP’s AAA server, the profiling server will send the same codes to the devicethrough the AAA server, and then compare the execution result with the information stored inthe user’s database for the purpose of identification and detection.


Using this approach can enable the SP to fully or partially detect the device identity. Theaccuracy of detection depends on the challenge codes sent to the device. If the SP can detectthe identity of the pirate device, which means the SP detects the presence of certificate credentialsharing problem. One limitation of using this approach is when the pirate device has the samehardware and firmware with the legit device, then it is difficult for the SP to distinguish thedevice identity and detect the presence of credential sharing.

Discussion




Figure 4.10: The sequence diagram of the OSU process and Secure Access

1) Structural Complexity: In order to generate challenge codes and analyze the challengeresponse, a profiling server needs to be added to the SP’s network, as shown in Figure 4.10.Besides, the server-side storage needs to be expanded to store the device profile.

2) Latency: The OSU time and authentication time will be extended because the client devicerequires time to execute the challenge codes sent by the SP and the SP requires time toanalyze the challenge response and store the result to the database. The new OSU timeTOSU for the SP and the client device is given by:

TOSU = tosu + tactive (4.9)

where tosu is the original average time needed to complete the OSU process; tactive is theaverage time for completing the challenge response mechanism. TOSU is the new averageOSU time for one client device and the SP per connection. For the first time subscription,the user needs to wait TOSU for the OSU process. The new authentication time Ta2 for theSP and the client device is given by:

Ta2 = ta1 + tactive + tquery (4.10)

where ta1 is the original average time needed to complete the mutual authentication, tqueryis the average time for the server to query the fingerprint stored in the user’s database.



Ta2 is the new average authentication time for one client device and the SP per connection.Each time the client device connects to the network service, the user needs to wait Ta2 forauthentication.

3) Throughput: Using this approach will take up the network bandwidth and affect thenetwork traffic between connected devices and servers. The bandwidth B2 is given by:

B2 =bactive ∗ nrq

24hours ∗ 3600seconds(4.11)

where bactive is average bandwidth consumption of the transmission during the active finger-printing for each reconnection request. nrq is the average number of reconnection requestsfrom mobile devices per day. Thus, B2 indicates the average bandwidth usage of the net-work, and B2 will linearly increase along with the number of reconnection requests. In caseof millions of requests in a short time period, the increase of bandwidth consumption couldbe considerably high, which may result in lower throughput and longer response time foreach request.

This approach also has an impact on the HS2.2 standard. The OSU process and the SecureAccess stage will be modified when using this approach. As shown in Figure 4.10, in the OSUprocess, the SP will profile the client device before performing the client certificate enrollment.In this case, more device identity attributes may be sent to the CA and added into the extensionfield of the client certificate. In the Secure Access stage, the AAA will perform the challenge-response process before it sends an EAP success to the client device so as to verify the deviceidentity and increase the accuracy of detection.

Approach 5. Passive Fingerprinting

Passive fingerprinting refers to the approach that a server passively identifies client devicesthrough traffic analysis. The server can collect the features of the client device during the com-munication, and then profile the device. For example, Matsunaka et al., proposed a passive OSfingerprinting method through Domain Name System (DNS) traffic analysis [17]. In addition,there are other methods relying on the device’s TCP/IP configuration [15], clock skew [13] andIEEE 802.11 wireless settings [26], e.g. frame type, frame size and transmission rate. Comparedto the active fingerprinting, passive fingerprinting can also be used for the purpose of identifica-tion, but the sever does not need to send extra querying request to profile client devices, whicheliminates the client-side execution time. Furthermore, the attacker will not know the server isprofiling the pirate devices when passive fingerprinting is adopted by the server. The fifth ap-proach I propose is to combine the passive fingerprinting approach with the HS2.2 environment.The following text describes the application of passive fingerprinting in HS2.2 environment.

In the SP’s network, both the OSU server and the AAA server can be used to analyze thetransmission packet sent from the client device. In the OSU process, the OSU server can ob-serve the features contained in the transmission packets, e.g. frame type, frame size, and etc,to profile the connected device. Then the OSU server will record the profiling results to theuser’s database as a known client device of the user. Later, in the Secure Access stage, the AAAserver can also be used to profile the device and compare the results stored in the database linkto the device. If the information can match successfully, the AAA server will continue processthe request from the device. Otherwise, the AAA server will send an error to the device, andthe SP is enable to detect the presence of sharing.




Using this approach can enable the SP to fully or partially detect the device identity. Theaccuracy of detection depends on the features collected during the communication betweenthe device and the SP. For example, Neumann et al., selected the following features of 802.11devices, and evaluated the detection accuracy of each feature as shown in Table 4.2.

Table 4.2: A list of tested features of passive fingerprinting

Feature Fingerprint accuracyTransmission time 1st

Frame inter-arrival time 2ndMedium access time 3rd

Frame size 4thTransmission rate 5th

If the SP detects the identity of the connected device does not match the identity informationrecorded in its database, which means the connected device is a pirate device and the certificatecredential sharing problem has taken place. One limitation of using this approach is whenthe pirate device uses the same wireless network configuration with the legit device, then itis difficult for the SP to distinguish the device identity and detect the presence of credentialsharing.

Discussion


1) Structural Complexity: The server-side storage needs to be expanded to store the deviceprofile. Moreover, the OSU server and the AAA server will be required to possess additionalfunctionalities, profiling and identifying mobile devices.

2) Latency: The authentication time will be extended because the AAA server needs to profilethe connected device, check the database and verify the device identity. For one connecteddevice, the new authentication time is given by:

Ta3 = ta1 + tpassive (4.12)

where ta1 is the original average time for completing the mutual authentication, tpassive isthe average time for the AAA server to complete the passive fingerprinting approach. Theuser needs to wait Ta3 for authentication.

3) Throughput: Compared to the active fingerprinting approach, the bandwidth usage willbe hardly affected as no extra challenge request needs to be send to the client device. Thethroughput will be slightly affected by the additional mobile identification process for eachrequest.



4.4 Secure Storage

4.4.1 Introduction

The secure storage or secure data storage refers to the technology used to save data in encryptedform. In the meantime, it ensures stored data integrity and confidentiality. The secure storagecan be used to encrypt data, control the access to sensitive and critical data, protect againstdata corruption threats like viruses, worms, software flaws, and etc.


The secure storage has been investigated for many years. It relies on hardware-based storagecard and software-based system or application. For example, Soltesz invented a system for thesecure storage which encodes sensitive data onto hardware card [28]. Except the local securestorage, critical data can also be stored in the cloud in a secure manner. Bessani proposeda virtual storage cloud that used to manage sensitive data stored in the cloud [3]. Besides,Goldstein invented a mechanism that encrypts a database. The information stored in thedatabase can still be processed but in an encrypted form [12]. Compared to hardware-basedsecure storage, software-based solution is more flexible that it can be deployed on various typesof mobile devices. In addition, mobile devices are not required to install new hardware modulesthat may result in higher cost and longer development time. However, hardware-based solutionis more reliable as it generally offers a higher level of security.

4.4.3 HS2.2 Case

As all the mobile devices discussed in this thesis are non-SIM device, which means critical datawill not be protected by SIM card. In order to prevent casual sharing or credential stealing inHS2.2, it is necessary to control or limit the access to sensitive information, e.g. private keyand the device identity, through software measures.

Approach 6. Secure Storage

The last approach proposed is building a software-based secure storage on mobile devices, andthen putting all critical information (the PPS MO, the client certificate, the private key, DevInfoMO and DevDetail MO) into it to prevent certificate credential sharing. The software-basedsecure storage uses mechanisms supplied by the operating system (OS) of the mobile device, i.e.the Android OS provides security features that can help the developer to build their own securestorage. In HS2.2, the software-based secure storage can be used to encrypt all the information(the PPS MO, the client certificate, the private key, DevInfo MO and DevDetail MO). The userswill not have access permission to these information so as to prevent casual sharing. In addition,without a proper software interface to access to the secure storage, the attackers cannot stealthe information from the secure storage. Before the device connects to the HS2.2 network, theDevInfo MO and DevDetail MO need to be stored into the secure storage. During the clientcertificate enrollment, when the device generates its own public/private key pair, the privatekey needs to be stored into the secure storage. At the end of the OSU process, the OSU serverneeds to directly provision the client certificate and the PPS MO into the secure storage.




This approach can be used to prevent attackers stealing information from the mobile devicebut cannot prevent them eavesdropping on the communication between the device and thehotspot network or the SP’s network. In addition, the secure storage works only after themobile device finished initialization. For example, if attackers build a software application forobtaining critical information like DevInfo MO, DevDetail MO and public/private key pairs,and then use this application to perform OSU process before initialization, they could controlthe entire HS2.2 working process. At this point, the secure storage cannot prevent certificatecredential sharing.

Discussion

Using this approach has the following impact on the HS2.2 architecture:

• Structural Complexity: In order to store information into the client device, the SPneeds a specific software interface to gain access to the secure storage. Therefore, asoftware interface should be added to the SP’s network.

4.5 Summarizing

Each approach has different use regarding the certificate credential sharing problem, e.g. detec-tion and/or prevention. Table 4.3 summarizes the purpose and use of each approach introducedabove. Limited means that the approach can achieve a particular goal in a particular scenario.For example, the token-based authentication approaches can be used for detecting the certificatecredentials sharing when the delay of synchronization between the legit device and the piratedevice is longer than their second connection to the service. In other words, the presence ofcertificate credential sharing can be detected when the device reconnects to the SP’s networkwithout completing the synchronization of the latest version of token, as shown in Figure 4.6.

Table 4.3: The Use of Each Approach for Certificate Credential Sharing Problem

Token-based authentication Device fingerprint

Generatingnew tokens

IncreaseRemediation

frequency

Remotemonitoring

Activeapproach

Passiveapproach

Securestorage

Detection Limited Limited Limited Yes Yes NoDetect sharing Yes* Yes* Yes Yes Yes NoDetect deviceidentity

No No No Yes Yes No

Prevention Limited Limited No No No YesPrevent sharing No No No No No YesPreventsimultaneoususage

Yes Yes No No No No

* means a limited ”detect sharing”, as described in the analysis of each approach.


Chapter 5

Risk Management System

In the previous chapter, six different approaches have been introduced for detecting and/or pre-venting certificate credential sharing problem in HS2.2 environment. Each of these approacheshas its own strengths and limitations. For example, the token-based approaches cannot alwaysenable the SP to detect whether certificate credential sharing exists or not. Remote monitor-ing can help the SP to detect the presence of certificate credential sharing when the same twocertificate credentials are used in two countries simultaneously or in a very close time. Addi-tionally, the token-based approaches cannot help the SP determine which one is the legit deviceand which one is the pirate device, while device fingerprinting can enable the SP to confirmthe device identity. Therefore, there exists a need to combine these approaches to assist SPsin alleviating the certificate credential sharing problem. For this purpose, a risk managementsystem (RMS) is proposed and analyzed in this chapter.

5.1 Introduction

The RMS is a process that can enable the user to identify, quantify, control the risk and predictthe impact of the risk. The RMS approach has existed for many years and been applied indepository institutions, insurance companies, securities firms, commercial banks, and otherfinance companies [24]. In financial services industry, there exists many types of risk, suchas interest rate risk, credit risk, insolvency risk and other risks, which have impacts on thosefinance companies. In order to optimize returns to the individual or the company with minimalrisk, the RMS is applied to measure and manage risks. For example, Elsinger et al., proposeda risk management approach to assess systemic financial stability of a banking system [10]. Ingeneral, a RMS adopts an assessment process that involves risk identification, evaluation andsubsequent management [7]. For instance, in a mobile payment application, a RMS is based onfraud detection and fraud containment. The RMS first collects the status of user account, creditcard, transaction history and other information to real-time check whether the account has beencompromised or not. Once the RMS detects an abnormal online transaction or compromisedmobile device, the mobile payment application will implement containment measure to limitthe access to assets and stop the transaction.


CHAPTER 5. RISK MANAGEMENT SYSTEM

5.2 HS2.2 Case

5.2.1 The structure of the RMS

Due to the functions of the RMS, it can also be applied in the HS2.2 environment to enable theSP to detect and alleviate the certificate credential sharing problem. Figure 5.1 illustrates theRMS for SPs in HS2.2 networks. The RMS consists of the following blocks:

Figure 5.1: The risk management system for SPs in HS2.2 networks

• Certificate Credential: The certificate credential refers to the client certificate and averify message signed by the device’s private key.

• Token-based Parameter (Token-based Authentication): The token-based para-meter refers to the PPS MO ID or tokens generated by the device using the token-basedauthentication approaches as described in section 4.1.3.

• Validation: Validation refers to the process that the SP’s AAA server validates andverifies the credential provided by the client device. In the original process, the clientdevice shall provide the certificate credential to the SP’s AAA server during the EAP-TLS authentication as described in section 2.6. The AAA server will check the integrity



and validity of the certificate, and also validate the client device’s identity associated withthe received client certificate. In the new process of the RMS, apart from the certificatecredential, the AAA server needs to verify token-based parameters.

• Subscription Remediation: This block refers to the subscription remediation processthat the SP may request the client device to perform after the validation step (see section4.1.3 Approach 1).

• Location, consumption information (Remote Monitoring): This block refers tothe location and consumption information collected through the remote monitoring ap-proach as described in section 4.2.

• Device Identity (Passive Fingerprinting): This block refers to the device identific-ation information collected through the passive fingerprinting approach as described insection 4.3.

• Risk Assessment & Decision Process: This block refers to the risk assessment anddecision-making process. According to the information of previous blocks, a decision-making server will assess the risk and make the access decision regarding the access requestof the connected device.

• Device Identity (Active Fingerprinting): This block refers to the device identificationinformation collected through the active fingerprinting approach as described in section4.3.

• OSU credentials: The OSU credentials refers to the information, e.g. credit card,bank account number and other private information, that the user provides to the SP forcreating an account in the registration stage.

• Correction: This block refers to the correction measures that the SP could take toalleviate certificate credential sharing problem after detecting it. For example, the SPcould revoke the certificate or add the pirate device into a black list in case it reconnectsto the SP’s network.

• Reject: This block refers to the access reject message that the AAA server sends to theclient device. It indicates that the SP rejects the access request from the connected device,and the client device cannot get access to its subscription service.

• Accept: This block refers to the access accept message that the AAA server sends tothe client device. It indicates that the SP accepts the access request from the connecteddevice, and the client device can get the access to its subscription service.

5.2.2 The working process of the RMS

The yellow part in the Figure 5.1 shows the original validation and authentication process inthe HS2.2 standard. The purple part of the figure shows the newly added validation and au-thentication process based on five approaches.

In the original process, the client device shall provide its certificate credential to the SP’sAAA server during the EAP-TLS authentication. The AAA server will check the integrity



and validity of the certificate, and also validate the client device’s identity associated with thereceived client certificate. If the validation fails, the SP will reject the access request from thedevice. If the validation is successful, then the SP will accept the access request and enablenetwork access. Additionally, the SP will request the client device to perform the subscriptionremediation process in case the certificate nearly expires. However, if a pirate device extractssufficient information from a legit device and then impersonates this device, the SP cannotdetect certificate credential sharing and the validation will always be successful.

Figure 5.2 illustrates the working flow of the RMS:

Figure 5.2: The flow chart of the risk management system

Step 1. Apart from the certificate credential, the client device shall also provide token-basedparameters, tokens generated by the SP’s servers and PPS MO ID, for the purpose ofdetection. (PPS MO ID will be automatically sent to the AAA server during the 802.11association.) As like the certificate validation, the AAA server also needs to check thevalidity of the token, and verify the status of this token in the token database link tothe client device. Checking the validity is for examining whether the token is out of theexpiration time. Verifying the token status is for checking whether the token is associ-ated with this particular device and whether it has been used or not. If the token is notassociated with the device, then it will not be stored in the token database link to thisdevice. In other words, no identical token can be found in the token database. If thetoken has been used for authentication, then the SP will set its status to be invalid in the



token database. Since the SP cannot predict when the client device will reconnect to thenetwork, the expiration time will be set according to the SP’s policy. Consequently, it ispossible that the token does not expire but it has already been used.

As a result, in the validation step, the AAA server will send an access reject to theclient device under the following three situations:

1) The device identity contained in the client certificate is different from the identitystored in the server-side database;

2) The message signed by a private key cannot be verified by the public key that thedevice sent to the OSU server during the client certificate enrollment process;

3) The token cannot be found in the token database link to the client device;

4) The status of the token in the token database is invalid.

The token validation process is the same as shown in Figure 4.9.

The AAA server will request the client device to subscription remediation process when:

1) The client certificate is out of the expiration time;

2) The token is out of the expiration time.

Step 2. Next, if the validation of both certificate credential and token-based parameters issuccessful, the decision-making server needs to gather the device information, e.g. the geo-graphical location of the device, the consumption of the subscription service and deviceidentity, by using remote monitoring and passive fingerprinting. These device informationwill be used as the input of the risk assessment and decision-making process.

As explained in section 4.1, using token-based parameters can help the SP detect the pres-ence of certificate credential sharing when the unauthorized device B has not synchronizedwith authorized device A. Once synchronization is successfully completed, using token-based parameters becomes ineffective on credential sharing detection. Since the locationand service usage information of the client device cannot be affected by software synchron-ization, remote monitoring can still be used to detect the sharing of certificate credential.Besides this information, the AAA server also needs to collect the information for deviceidentity to distinguish legit devices from pirate devices. By using passive fingerprintingapproach, the SP can profile each client device during the communication with the devicefor the purpose of identity detection and sharing detection. As discussed in section 4.3.1,active fingerprinting can also be used to detect the device identity and the presence ofcredential sharing. But the challenge-response mechanism of active fingerprinting willresult in the delay of authentication and extra network traffic between the device and theSP’s network as the device needs to execute the challenge codes sent by the SP. In orderto reduce the time cost and network traffic, here the system uses passive fingerprintinginstead of the active one. Therefore, the location information of the device, consumptioninformation of the subscription service and unique device identity will be the input of therisk assessment and decision-making process.



Step 3. In this step, the SP will assess the risk and make the decision according to a functiongiven by:

f(x1, x2, ..., xn) =n∑

i=1

wi × xi, 0 ≤ xi ≤ 100 (5.1)

where f is the risk value of certificate credential sharing, xi is the risk value of the i-thapproach, wi is the weight of the i-th approach. In our case, n is equal to 2 as the systemonly uses passive fingerprinting and remote monitoring these two approaches.

n∑i=1

wi = 1 (5.2)

The sum of wi equals to 1 so as to ensure the final value of f() is between 0 and 100. Thevalue of wi is set by the SP according to its policy. The i-th approach will get a highervalue of wi if the SP pays more attention to the result of this approach.

Additionally, for the risk value f, I set up two threshold values which are given by:

0 < thresholdlow < thresholdhigh < 100 (5.3)

where thresholdlow is the highest value that the SP is willing to accept the risk, thresholdlowis the lowest value that the SP is willing to reject the risk. These two threshold values arerelated to the connection decision to be made by the SP, which is given by:

decision =

accept if 0 ≤ f ≤ thresholdlowreject if thresholdhigh ≤ f ≤ 100

uncertain if thresholdlow ≤ f ≤ thresholdhigh

(5.4)

After the computation, there are three situations:

1) If the value of f is between 0 and thresholdlow, which means the SP will take the riskand accept the access request from the connected device;

2) If the value of f is between thresholdhigh and 100, which means the SP will not takethe risk and reject the access request from the connected device;

3) If the value of f is between thresholdlow and thresholdhigh, which means the SP willutilize other methods to reassess the risk.

Step 4a. For the first situation in step 3, if the device receives an access accept, then itwill gain network access and use the subscription service. For the second situation, ifthe device receives an access reject, then it will dissociate from the AP or the hotspotnetwork. For the third situation, the SP could require that the user manually provide theOSU credentials, e.g. credit card, bank account number and other private information, tomake the decision.

1) If the user cannot manually provide the same OSU credentials as he/she provided inthe registration stage, then the SP will reject the access request from the connecteddevice;

2) If the user can manually provide the same OSU credentials, then the SP will accessthe access request from the connected device;



Step 4b. Alternatively, the SP could use active fingerprinting approach that the SP sendsspecific codes as the challenge to the device and analyze the challenge response to detectthe device identity.

1) If the device identity of the connected device is the same with the information stored inthe server-side database, then the SP will access the access request from the connecteddevice;

2) If the device identity of the connected device is considerably different with the inform-ation stored in the server-side database, then the SP will reject the access request fromthe connected device. As the user may change the fingerprint of the device, e.g. updatethe OS, this RMS allows for small changes over time.

5.3 Analysis of the RMS

The RMS uses a combined approach for alleviating the certificate credential sharing problem,consisting of token-based authentication, remote monitoring, and device fingerprinting. Basedon these approaches, the SP can use this system to detect the device identity and the presenceof certificate credential sharing, and then take measures to mitigate the problem by using dis-association function or de-authentication function.

For example, if a mobile device tries to access to a subscribed service in Eindhoven and ithas already successfully passed the validation step, but the SP detects that the location of thedevice was in Stockholm 30 minutes ago. In the meantime, the device identity detected throughthe passive fingerprinting approach is the same with the one stored in the server-side database.In this scenario, the SP raises the suspicion of certificate credential sharing. In order to ensurethat it is a pirate device, the SP can redirect the current authentication page to another webpage, and ask the user to submit his/her OSU credentials.

However, this RMS could fail in case of casual sharing. For example, the attacker has clonedtwo exactly the same non-SIM mobile devices and register one of the devices with a SP. Onedevice follows the HS2.2 working process and gets the legal certificate credentials from the SP.After that, the attacker shares the legal certificate credentials with the other device. Both ofthese two devices can pass the RMS and get access to the service but not simultaneously.

5.3.1 Discussion

Using this system will have the following impacts on the network architecture:

1) Structural Complexity: As the RMS combines different approaches, some componentsneed to be added to the SP’s network as shown in Figure 5.2. First, for the token-basedparameter block in the RMS, if the SP utilize the PPS MO ID as the token, a token serverneeds to be added to the SP’s network as discussed in section 4.1.3 Approach 1. If theSP utilize the one-time used token, then a token API, a token server and a token databaseneed to be added to the SP’s network as discussed in section 4.1.3 Approach 2. Second, inorder to collect the location and consumption information of client devices, the SP’s networkneeds to add another server to support the remote monitoring service as discussed in section4.2.3. Third, in order to support active fingerprinting and passive fingerprinting approaches,



the SP’s network needs to add the profiling servers and expand the server-side storage asdiscussed in section 4.3.3. At last, a decision-making sever needs to be added to the SP’snetwork to assess the risk and make the connection decision.

2) Latency: The more steps a mobile device goes through the RMS, the longer latency it willhave. For step 1, verifying the token-based parameter will extend the mutual authenticationtime. Equation 4.1 indicates the latency of using PPS MO ID as the token in the authen-tication process, while equation 4.6 indicates the latency of using newly generated token inthe authentication process. For step 2 and step 3, besides the time tpassive for using passivefingerprinting approach as described in section 4.3.3 approach 6, the SP also needs the timetremote for analyze the location and consumption of the device and the time tdesicion fordecision making process. For step 4, in case that active fingerprinting is required, the SPneeds the time tactive to check the device identity as described in section 4.3.3 approach 5.

3) Throughput: Using this RMS could result in high bandwidth usage and low throughputbecause the bandwidth usage will be increased when using newly generated tokens and activefingerprinting respectively in this RMS. As described in equation 4.8 and equation 4.12, thebandwidth usage will be increased along with the number of connection requests. In alarge-scale hotspot network, in case of millions of requests in a short time, the increase ofbandwidth consumption could be considerably high, which may result in lower throughputand longer response time.

This RMS also has an impact on the HS2.2 standard, especially the working process in thestandard. In particular, the OSU process will be modified when:

- tokens need to be generated as illustrated in Figure 4.9, and

- challenge codes need to be sent to the client device as illustrated in Figure 4.10.

The Secure Access stage will be modified when:

- subscription remediation frequency has been increased as illustrated in Figure 4.4,

- tokens need to be validated and verified as illustrated in Figure 4.9, and

- the device identity needs to be checked as illustrated in Figure 4.10.

Additionally, when using the passive fingerprinting, the OSU server and the AAA server willbe required to possess additional functionalities, profiling and identifying mobile devices.


Chapter 6

Conclusions and Future Works

This chapter concludes the entire project. First, I will conclude the contributions made duringthe project. After that, I will lay out some future works.

6.1 Conclusions

According to the analysis in Chapter 3, Chapter 4, and Chapter 5, the main contributions ofthis master project are:

1) Identify the certificate-based credential sharing problem in HS2.2 environment;

2) Propose various approaches to prevent certificate-based credential sharing problem or detectthe problem, and evaluate each approach in terms of their impacts on the HS2.2 architectureand the HS2.2 standard;

3) Propose a risk management system that combines most of the already evaluated approachesinto a system.

The first task of this project is to identify if the problem exists for the HS2.2, and identify indetail what information needs to be extracted from a legit device to a pirate device to makethe certificate credential sharing happen. Based on two use cases: casual sharing and credentialstealing, I analyze the required information for completing certificate credential sharing betweenthe legit device and the pirate device, which are the PPS MO, the client certificate, the device’sprivate key, DevInfo MO and DevDetail MO. I also analyze the technical feasibility of extractingthis information from the legitimate device.

The second task of this project is to investigate approaches for either sharing detection orprevention. For detection, two token-based approaches (generating new tokens and increasingremediation frequency) can be used for detecting the presence of credential sharing when thepirate device connects to the HS2.2 networks but does not complete the synchronization withthe legitimate device. Also, the remote monitoring approach can be used for detecting the pres-ence of credential sharing when two devices with the same identity appear in two distinguishedlocations at the same time or in a very close time. Additionally, two device fingerprinting ap-proaches (active approach and passive approach) can be used for detecting the device identityand the presence of credential sharing in case that the pirate device connects to the HS2.2networks. For prevention, two token-based approaches can be used for preventing simultaneous


CHAPTER 6. CONCLUSIONS AND FUTURE WORKS

usage of subscription services as tokens are designed to be one-time used. Also, the secure stor-age approach can be used for preventing sharing between the legitimate device and the piratedevice as all the necessary information is securely stored in the mobile device. Furthermore,I analyze the implication of each approach for HS2.2: the impact on the network architectureand the impact on the HS2.2 standard. Apart from that, I also discuss the limitation of eachapproach when they are applied for solving the certificate credential sharing problem in HS2.2networks.

The last task of this project is to design a risk management system for SPs to detect thecertificate-based credential sharing and alleviate the problem. By combining approaches pro-posed in Chapter 4, . In addition, the implications, advantages and disadvantages of this riskmanagement system are analyzed under the HS2.2 environment.

6.2 Future Works

This project accomplishes theoretical foundations of security identification of the certificate-based credential sharing in HS2.2 networks. Therefore, the future works of this project couldbe:

• It requires practical implementation to further analyze this problem by simulation or byusing mobile devices to realize certificate credential sharing.

• It also requires practical work to implement each approach proposed in this thesis toevaluate the feasibility, reliability, and performance of them.


Bibliography

[1] Martin Abadi, Krishna Bharat, and Johannes Marais. System and method for generatingunique passwords, October 31 2000. US Patent 6,141,760. 2

[2] Open Mobile Alliance. Oma device management standardized objects. Approved Version,1, 2008. 8

[3] Alysson Bessani, Miguel Correia, Bruno Quaresma, Fernando Andre, and Paulo Sousa.Depsky: dependable and secure storage in a cloud-of-clouds. ACM Transactions on Storage(TOS), 9(4):12, 2013. 42

[4] Christine Blakemore, Joao Redol, and Miguel Correia. Fingerprinting for web applications:from devices to related groups. In Trustcom/BigDataSE/I SPA, 2016 IEEE, pages 144–151.IEEE, 2016. 37

[5] John Jules Alexander Boyer and Eric Fernand Le Saint. Secure digital credential sharingarrangement, September 21 2010. US Patent 7,802,293. 2

[6] Sergey Bratus, Cory Cornelius, David Kotz, and Daniel Peebles. Active behavioral fin-gerprinting of wireless devices. In Proceedings of the first ACM conference on Wirelessnetwork security, pages 56–61. ACM, 2008. 38

[7] Ken Brown and Peter Moles. Credit risk management. Edinburgh Business School, Heriot-Watt University, UK, 2012. 44

[8] Emanuele Cesena, Hans Lohr, Gianluca Ramunno, Ahmad-Reza Sadeghi, and Davide Ver-nizzi. Anonymous authentication with tls and daa. In International Conference on Trustand Trustworthy Computing, pages 47–62. Springer, 2010. 2

[9] Dave Cooper. Internet x. 509 public key infrastructure certificate and certificate revocationlist (crl) profile. 2008. 16

[10] Helmut Elsinger, Alfred Lehar, and Martin Summer. Risk assessment for banking systems.Management science, 52(9):1301–1314, 2006. 44

[11] Ana Ferreira, Jean-Louis Huynen, Vincent Koenig, and Gabriele Lenzini. Socio-technicalsecurity analysis of wireless hotspots. In International Conference on Human Aspects ofInformation Security, Privacy, and Trust, pages 306–317. Springer, 2014. 1

[12] Benjamin D Goldstein. Method and apparatus for secure storage of data, October 5 1999.US Patent 5,963,642. 42


BIBLIOGRAPHY

[13] Suman Jana and Sneha K Kasera. On fast and accurate detection of unauthorized wirelessaccess points using clock skews. IEEE Transactions on Mobile Computing, 9(3):449–462,2010. 40

[14] Robert N Johnson, Ronald D Smith, Charlotte K Smith, Edward C Kight, and George HHarrop. Smart remote monitoring system and method, April 22 2003. US Patent 6,553,336.35

[15] Tadayoshi Kohno, Andre Broido, and Kimberly C Claffy. Remote physical device finger-printing. IEEE Transactions on Dependable and Secure Computing, 2(2):93–108, 2005.40

[16] Dongjiang Li, Cheng Cheng, and Bo Zhang. Vehicle remote monitoring system based onandroid. In Software Engineering and Service Science (ICSESS), 2016 7th IEEE Interna-tional Conference on, pages 722–725. IEEE, 2016. 35

[17] Takashi Matsunaka, Akira Yamada, and Ayumu Kubota. Passive os fingerprinting by dnstraffic analysis. In Advanced Information Networking and Applications (AINA), 2013 IEEE27th International Conference On, pages 243–250. IEEE, 2013. 40

[18] K. Metal and F. Hydraulic. Wi-Fi Alliance Hotspot 2.0 (Release 2) Technical Specification,December 2016. 1, 3, 5, 8, 9, 12

[19] Phyllis Michaelides. Generic token-based authentication system, December 9 2003. USPatent App. 10/731,629. 2

[20] Abdullah Na, William Isaac, Shashank Varshney, and Ekram Khan. An iot based systemfor remote monitoring of soil characteristics. In Information Technology (InCITe)-TheNext Generation IT Summit on the Theme-Internet of Things: Connect your Worlds,International Conference on, pages 316–320. IEEE, 2016. 35

[21] Nalini K. Ratha, Jonathan H. Connell, and Ruud M. Bolle. Enhancing security and privacyin biometrics-based authentication systems. IBM systems Journal, 40(3):614–634, 2001. 2

[22] Barry Ribbeck. Public key infrastructure. 2016. 16

[23] Kaimin Ruan, Chao Hu, Weixing Lin, Xianli Wang, and Changzhu Song. Remote monit-oring system for family health examination. In Information and Automation (ICIA), 2016IEEE International Conference on, pages 148–153. IEEE, 2016. 35

[24] Anthony Saunders and Marcia Millon Cornett. Financial institutions management: A riskmanagement approach. Irwin/McGraw-Hill, 2003. 44

[25] Aashish Sharma, Zbigniew Kalbarczyk, R Iyer, and James Barlow. Analysis of credentialstealing attacks in an open networked environment. In Network and System Security (NSS),2010 4th International Conference on, pages 144–151. IEEE, 2010. 2

[26] Chao Shen, Ruiyuan Lu, Saeid Samizade, and Liang He. Passive fingerprinting for wirelessdevices: A multi-level decision approach. In Identity, Security and Behavior Analysis(ISBA), 2017 IEEE International Conference on, pages 1–6. IEEE, 2017. 40


BIBLIOGRAPHY

[27] Dan Simon, Bernard Aboba, and Ryan Hurst. The eap-tls authentication protocol. Tech-nical report, 2008. 12

[28] John A Soltesz. System for the secure storage and transmission of data, June 25 1991. USPatent 5,027,401. 42

[29] Parekh Tanvi, Gawshinde Sonal, and Sharma Mayank Kumar. Token based authenticationusing mobile phone. In Communication Systems and Network Technologies (CSNT), 2011International Conference on, pages 85–88. IEEE, 2011. 2

[30] Bhavani Thuraisingham, XiaoFeng Wang, and Vinod Yegneswaran. Security and Privacyin Communication Networks: 11th International Conference, SecureComm 2015, Dallas,TX, USA, October 26-29, 2015, Revised Selected Papers, volume 164. Springer, 2016. 2

[31] WiFiAlliance. Wi-Fi CERTIFIED Passpoint (Release 2) Deployment Guidelines. December2016. 4, 7


eindhoven university of technology master credential

Documents