Federated Authentication mechanism for mobile services

Dasun Weerasinghe, Saritha Arunkumar, M Rajarajan, Veselin Rakocevic Mobile Networks Research GroupSchool of Engineering and Mathematical SciencesCity University London.

Outline of the Presentation

Motivation factor Our approach to authentication Mobile Service Environment Technology Security Capsule Possible security attacks Conclusion

Use of mobile devices Study in 2006 December

2.7 billion mobile users worldwide 1.1 billion Internet users worldwide India is in world’s No. 3 in mobile phone users

Prediction for 2011 3.96 billion mobile users worldwide 2 billion Internet users worldwide

Rapid growth in 3G network More services over the phone rather than voice communication By 2011 there will be 1.06 billion 3G users in Western Europe

and US

Services available in your mobile Daily activities over the Internet

Banking Pay utility bills; Shop online

Mobile phone has the same capabilities Extra services to mobile devices

Location based services (e.g. find the nearest parking) Services while mobility (e.g. Healthcare)

Authentication and Payments over the mobile devices Authenticate your self ??? Pay by credit card ???

Emerging Services in a mobile

Our approach to authentication Introduce a Single-Sign-On server Mobile user authenticate with the mobile

operator Confirmation of mobile operator authentication

will be used in the Single-Sign-On sever Single-Sign-On server acts as an identity

provider Mobile user authenticates to these services

based on the authentication with the Single-Sign-On server

Mobile Service Environment

Mobile Operator

Mobile Device Identity Provider

(SSO)

Vendor

Secure Connectivity

Existing R

elation

Payment Service

Secure link

Secure link

Authentication Service

8

Core Technology: GAA Mobile operators to enable 3G authentication

as a service: 3GPP This framework is know as Generic Access

Authentication (GAA) USIM Identity

IMPI - IP Multimedia Private Identity Session key generation for secure

communication GAA reference model:

NAF in different network from BSF Secure communication between NAF and BSF BSF generates session keys for the

communication between UE and NAF

HSS

UE

NAFBSF

UaUb

Zn

Zh

Bootstrapping Server Function (BSF)Home subscriber System (HSS)Network Application Function (NAF)

Security and Privacy protection for the mobile users Data communications are secured

Mobile and the SSO is secured with session key Mobile and the vendor is secured with derived session or PKI

keys XML Security methods are applied in the messages

Communication between the Mobile and the Vendor is not visible to the SSO server. Separate key generation

Anonymous authentication for mobile users Real identity of the user is protected at the SSO SSO generates a temporary identity for the communcation e.g. Healthcare: record linkage, drug store

Operations inside the mobile Security capsule is the application that connects the

mobile device with SSO and vendors Encrypted content from the vendor to the mobile Decryption key can only be generated inside the mobile

with the combination of, IMPI – From mobile operator IMEI – From mobile device PIN validation – From user Session Key – From vendor

Content can’t be transmitted to other mobile devices or can’t be stolen by someone else

Operations inside the mobile (Contd.)

IMPI

IMEI

User PIN

Vendor Key

Key Generation

(SHA 1)192 bit key

Encrypted DataDecryption

(Triple DES)Decrypted Data

Data UtilizationLocate the RAM

addressShuffle data in

the RAM address

Threats to the mobile services Mobile operator impersonate Identity provider impersonate Mobile user impersonate SIM card cloning Man-in-the middle attacks

Message monitoring Message altering

Phone lost or stolen

Threats to mobile devices

Any message sent to the network is assumed to be received by a malicious user

Any message received from the network is assumed to be from the malicious user

Dolev-Yao threat scenario

Bob sendsmessage to

Alice

Alice receives amessage

Public Network

Maliceintercepts the

message

Dolev-Yao threat model

Assuming that Malice can do a lot, Dolev-Yao threat model proves that Malice cannot do the following: Malice cannot guess a random number which is chosen

from a sufficiently large space. Without the correct secret (or private) key, Malice cannot

retrieve plain-text from given cipher-text, and cannot create valid cipher-text from given plaintext, with respect to the perfect encryption algorithm.

Malice cannot find the private component, i.e., the private key, matching a given public key.

Our system We prove the Dolev-Yao

threat model for our system knowing that Malice cannot retreive information as Malice will never have Retailer Session key and user PIN , so he will not be able to generate the key to decrypt the message

Mobile Phone Compromised

There are 3 scenarios for a phone to be compromised Attacks from the Internet Infection from compromised PC during data

synchronize Peer smart-phone attack or infection

Mobile Phone Attacks

Base Station DoS DDoS to call centers Spamming Identity theft and spoofing Wiretapping

Defence

Phone hardening OS hardening Hardware hardening

Internet side protection Telecom side protection

Conclusion

USIM based approach for mobile user authentication

Single-Sign-On methodology Security Capsule based data security Possible security attacks on our model Counter measures

Q & A