Federated Authentication mechanism for mobile services Dasun Weerasinghe, Saritha Arunkumar, M Rajarajan, Veselin Rakocevic Mobile Networks Research Group School of Engineering and Mathematical Sciences City 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 Relation Payment Service 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 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 Data Decryption (Triple DES) Decrypted Data Data Utilization Locate the RAM address Shuffle 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
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