Context-aware Authentication

A context-aware authentication mechanism uses the context of a user for authenticating the user. There are numerous such mechanisms. Here, a few of the most influential works are reviewed.

In [39], the authors have presented a secure and usable context-aware user authentication mechanism to be used in a hospital environment. The mechanism consists of several compo- nents such as clients, context monitors and context servers. A client is essentially a service provider equipped with a smartcard reader. Each user is provided with a smartcard with the capability to execute an applet. The applet is initialised with an RSA key pair generated using the identifier and password of the user. The identifier, the password and the private key are stored in the smartcard whereas the respective public key is stored in the context server along with the user identifier. A context monitor consists of different external sensors that determine the location of a user. Each context monitor is connected to the context server which is aware of the locations of all context monitors. To determine the location of a user, the context server uses either an RFID tag belonging to a user or the WLAN signal emitted by devices belonging to a user. Using these components, the authentication protocol is as follows. A user comes nearby to a context monitor and the monitor detects the presence of the RFID tag. The identifier of the RFID tag is transmitted to the context server which determines the identifier of the user using the identifier of the RFID tag. The server also determines the location of the user using the identifier of the user and the location of the monitor. Next, the user inserts her smartcard into the reader. The reader reads the encrypted identifier from the card and transmits it to the server via the client. The server decrypts the user identifier and then uses it to determine the user’s location. The location is transferred back to the client and then the client determines if the user is allowed to access a service. The proposed mechanism is assessed to be secure against different attacks. The proposal has only considered the identifier to determine the identity of a user ignoring other attributes which may constitute the identity of the user. In addition, the proposal did not consider how it could be used for identity management.

2.5. Context-aware Identity Management 23

A framework for authenticating a user based on the proximity to external sensors is presented in [40]. The authors argued that detecting a user inside a building could be quite tricky and suggested on using proximity sensors. The paper illustrates two situations discussed below. The first scenario is known as the Personal Beacon Authentication in which a user can be authenticated using her mobile device and an external sensor known as the Personal Beacon. The beacon and the mobile device can communicate with each other using Bluetooth or near-field magnetic communication. The beacon uses a PKI for authenticating a user where the administrator of the beacon generates the pair of RSA keys and obtains a certificate containing the public key signed by a CA. The root certificate of the CA is installed in the mobile device. When the mobile device comes near to the beacon, the authentication mechanism is activated. If the device and the beacon communicate for the first time, an initial phase, known as the enrolment phase, takes place where the mobile device obtains the certificate containing the public key of the beacon. The mobile device validates the certificate by using the root certificate. Once validated, the enrolment phase concludes. This allows the mobile device to participate in a challenge-response protocol for authentication with the beacon every time they are nearby. For this, the device generates a random value (A) and passes to the beacon for signing. Upon receiving the random value, the beacon generates another random value (B) and concatenates two random values (A||B). Then, the concatenated random values are signed by the beacon and returned to the device. The device validates the signature of the concatenated random values and retrieves B which is then returned to the beacon. Once the beacon receives B, the user of the device is considered authenticated. After authentication, how the user accesses services is not explored in the paper.

The second scenario is known as the Organisation Authentication Beacon in which a device does not have any location information. Instead, the location information is retrieved from the installed proximity sensor known as the organisational beacon. Like before, a mobile device and an organisational beacon communicate using Bluetooth. The administrator of the beacon sets up the X.509 certificate whereas the root certificate is installed in the device. During communication, a Transport Layer Security (TLS) connection is established using the X.509 certificate. The location information is securely transmitted using this TLS connection from the beacon to the device. Upon receiving the location information, the device switches itself to the authenticated mode. What is achieved in this mode is not further explored in the paper.

The proposal and its implementations did not consider mutual authentication since the iden- tities of the beacons are verified using certificates whereas the identity of the device remains unverified. The lack of identity verification of a user will allow every user nearby to the beacon to access same services without any personalisation. Furthermore, an SP will not be able to provide restricted services to a user without knowing her identity. Also, the paper did

2.5. Context-aware Identity Management 24

not consider how this setting could be explored for identity management.

Another paper that describes how contextual data can be used for mutual authentication of users can be found in [41]. The authors have proposed a mechanism consisting of two enti- ties: users and context providers. The context of a user consists of several information such as: time, location and activity. A context provider is responsible for providing secure and verifiable contexts of a user retrieved using different external sensors. Two users authen- ticate each other by retrieving their respective contextual data from the respective context provider and exchanging them with each other. The proposed mechanism utilises Identity Based Encryption (IBE) for secure exchange of contextual information and a combination of timed fuzzy logic and private set intersection for privacy-preserving calculation of con- fidence that determines if a user can be considered authenticated to another user. Since the proposal deals with mutual authentication of two users, it is impractical to be integrated with online services. Furthermore, the authors did not consider the suitability of their proposal for identity management.

In [42] Hsieh et al. have presented an One Time Password (OTP) authentication scheme that utilises contextual information such as time and location of a user device. A service provider, regarded as the Application Server in the paper, utilises such contextual information to provide services to a user. The user is identified using the International Mobile Subscriber Identity (IMSI), a unique identifier for the mobile device of the user whereas an OTP is generated by concatenating the location of the mobile device retrieved using the GPS sensor of the device and the time of service request. According to the proposal, this information is transferred in encrypted format to the service provider where the provider decrypts and retrieves such information using PKI. Unfortunately, the proposal is quite sketchy in the sense that the authors did not elaborate the mechanism by which PKI could be established for their proposal and the location could be extracted from the concatenated OTP. In addition, the absence of any security analysis undermines the credibility of the proposal. Furthermore, it is not clear if this approach could be used for identity management.

In order to strike a balance between security and usability, the authors in [43] present a prob- abilistic model for authenticating a user (generally the owner) in a mobile device. The model utilises two factors: active authentication factor and passive factor. An active authentication factor symbolises the existing mechanisms for authenticating a user in the current genera- tion of smart mobile devices, namely, PIN, Password and No-PIN, whereas, a passive factor represents the context of a user, namely, in the form of locations and the time of a day. The model automatically chooses an active authentication factor based on the combination of a specific location or time. For example, the model relaxes the restriction of using a PIN or password when a user is at her home or at her workplace, however, imposes the restriction of a PIN or password for other places. Another example is that a PIN can be used at a user’s home or workplace and a password can be used for other places. A user can set her preferred

2.5. Context-aware Identity Management 25

mode of active authentication factor for different contexts. The proposed model has been implemented in a smartphone app which has been used for an extensive user study. The result of the study suggests an enhancement in usability without compromising security. The focus of this work is to authenticate a user on a mobile phone and hence, it does not con- sider the issue of identity management using contexts. Moreover, since the authentication is conducted on a mobile device, it is impractical for integrating into online services.