Presentation is loading. Please wait.

Presentation is loading. Please wait.

ISG Distance Learning Weekend Conference 2011 Website Credential Storage and Two-Factor Web Authentication with a Java SIM Sunday 11 th September 2011.

Similar presentations


Presentation on theme: "ISG Distance Learning Weekend Conference 2011 Website Credential Storage and Two-Factor Web Authentication with a Java SIM Sunday 11 th September 2011."— Presentation transcript:

1 ISG Distance Learning Weekend Conference 2011 Website Credential Storage and Two-Factor Web Authentication with a Java SIM Sunday 11 th September 2011 Jon Hart, Network and Systems Manager, Information Security Group Royal Holloway University of London jon.hart@rhul.ac.ukjon.hart@rhul.ac.uk http://www.scc.rhul.ac.uk/http://www.scc.rhul.ac.uk/

2 Introduction and Acknowledgements MSc dissertation Smart Card Centre –Dr Kostas Markantonakis (k.markantonakis@rhul.ac.uk)k.markantonakis@rhul.ac.uk –Dr Keith Mayes (k.mayes@rhul.ac.uk)k.mayes@rhul.ac.uk Telefónica Europe plc (O2) –Development SIM cards

3 Overview 1.The problem with passwords 2.Why use a mobile phone and SIM for authentication? 3.The Proposed schemes 4.System architecture 5.Web credential storage and authentication (Scheme 1) 6.Two-factor OTP authentication (Scheme 2) 7.Security Analysis 8.Conclusions 9.Practical implementation and a demonstration

4 The problem with passwords Password proliferation –Exponential growth in the number of (web-based) e-commerce, entertainment and social networking services in the last decade –Many of these services authenticate a user by a username and password –How many passwords does the typical web user need to manage? 15 years ago, perhaps one or two? Me: About 40.. Perhaps I’m not typical! Survey in 2001 suggests 15 on a daily basis Some users report having in excess of 100 accounts!

5 The problem with passwords Research by Adams and Sasse report that the average user can typically only use 4 or 5 unrelated password successfully User coping strategies –Use the same (or similar) passwords on multiple web site –Recent Sophos survey has showed that 81% of users use do this! –Users may not realise that by reusing password on multiple sites the security of a well protected account is only as good as that of the poorly protected account. Described as the “Domino Effect” by Blakes Ives etc. al. Example: Rockyou.com –Users also often choose poor passwords that are easier to remember..

6 The problem with passwords – solutions? Use a password manager –A web browser plugin or software application that enables passwords to be stored in a database on a users computer or the internet –Default passwords managers supplied with IE and Firefox fail to adequately protect users credentials from Trojan’s or other users of the computer –Online password managers would appear to be a good solution, however reliant on vendors claims about security Alternatives –E.g. Single Sign On (SSO) - OpenID, Windows Live ID (.NET passport), SPP (Gouda et. al) –May require trust in third-party –Require significant changes to server infrastructure, slow adoption –Most websites still use password and use is likely to continue for the foreseeable future

7 Two-factor authentication –Typically used by financial institutions –User enters something they know (username/password) and something they have – often a One Time Password (OTP) from a hardware token or reader Not all card readers are compatible (users may require multiple readers/tokens) Other implementations in software (on mobile phone) or use SMS to provide OTPs

8 Summary Proliferation of passwords required for an ever increasing number of internet services –Problem of choosing and remembering a large number of secure passwords –PC based password managers may not be secure or require trust in third party –Alternative solutions require significant changes to web server infrastructure and/or trust in third party Two-Factor authentication –Inconvenience of often incompatible two-factor authentication tokens or readers –Software implementations subject to Trojans –SMS implementations subject to eavesdropping / hijack of subscribers number

9 Why use a mobile phone and SIM for authentication? Mobile phone –Portable, ubiquitous, high user acceptance –No need to carry additional hardware tokens –Theft is likely to be reported immediately SIM Card –Secure tamper resistance device –Can be easily transferred between handsets as required –Java SIM enables Java Applets to be developed to run on SIM card Applets are firewalled Applet lifecycle well defined Applet can generate keys (e.g. RSA key pair) when applet loaded Network operator has control of SIM and applets on SIM Why not software app on the phone (Java MIDP, Symbian, Android, iPhone etc..)? –Phone operating system vulnerabilities, Trojans.

10 Introduction Propose two distinct authentication schemes, both using a mobile phone and SIM:- Scheme 1 (Password authentication management) Enables authentication credentials (username + password) to be stored and securely retrieved from a mobile handset and SIM Main goal is to provide secure storage of authentication credentials, with minimal changes to existing infrastructure, i.e. it should work with existing web servers without any significant services Should not require any special hardware on the user’s PC Scheme 2 (One-Time passwords) A more secure scheme using One-Time Passwords (OTPs) generated within the SIM For web services requiring an enhanced level of authentication, i.e. financial institutions May optionally be used with Scheme 1, i.e. (storage of username + password and a OTP)

11 System Architecture SIM Application Toolkit (SAT) Applet The SAT Java Applet executes on the users SIM card. The applet provides credential storage and authentication services for the two authentication schemes. Web Browser Extension (WBE) The WBE extension integrates into the users web browser, and receives credentials stored on the SAT Applet and enters them into the web page logon fields. SMS Gateway Server (SMSGS) The SMSGS role is to translate mobile network SMS messages to and from the SAT applet to HTTPS commands that are sent over a TCP/IP based network. SMS messages are sent using secure GSM 03.48

12 Scheme 1 - Web credential storage and authentication Web credentials are stored on the user’s SIM card. The credentials are requested on-demand when a user visits a website requesting authentication. The protocol starts with a one off-initialisation step that sets up authentication and encryption keys for the remainder of the protocol. The user installs the WBE on a host PC and chooses a username U and passphrase P, from which an authentication hash AUTH and symmetric key WBE-SYM are created in volatile memory: WBE-SYM = h(P||U) AUTH = h (WBE-SYM) The above hashes are created using a collision resistant hash function such as SHA-256. WBE-SYM is used by the SAT applet to send credentials to the WBE. AUTH is used to authenticate the user to the SMSGS.

13 Scheme 1 - Web credential storage and authentication (Initialisation phase) Web credentials are stored on the user’s SIM card. The credentials are requested on-demand when a user visits a website requesting authentication. Message (1.4) followed by PIN confirmation completes the initialisation phase. To recap, at the end of this phase a user account has been created on the SMSGS and has been associated with the user’s mobile number. A symmetric key has also be exchanged between the WBE and SAT applet. The initialisation phase is only carried out when the WBE passphrase is initially set or subsequently changed. A message is sent from the WBE to the SMSGS to associate the username U with mobile number N in a database maintained by the SMSGS. (1.1) In response to the receipt of message (1.1) the SMSGS stores a permanent user record in its database and sends a message to the SAT applet identified by mobile number N, requesting the applet sends the WBE its RSA public key. (1.2) The SAT applet responds to message (1.2) with the applets RSA public key SAT-PUB and forwards it via the SMSGS to the WBE. (1.3) The WBE responds with the WBE-SYM symmetric key, enciphered under the SAT applet’s RSA key, via the SMSGS gateway. (1.4)

14 On receipt of message (1.6) the SAT applet checks the internal credential store and following confirmation by the user entering their PIN, responds with the user’s website credential username CRED_UID and password CRED_PWD. If no credentials are currently stored the user is given the opportunity to enter them. The credentials are then enciphered with the previous exchanged symmetric key WBE- SYM and sent to the WBE. (1.7). On receipt of message (1.7) the WBE deciphers the credentials received using the pre- shared symmetric key and enters them into the web page logon form. This completes the protocol run. Scheme 1 - Web credential storage and authentication (Login phase) Web credentials are stored on the user’s SIM card. The credentials are requested on-demand when a user visits a website requesting authentication. Following initialisation the WBE may request a user’s credentials for a web page by supplying the username U, authentication hash AUTH (derived from passphrase P; as before) and the website hostname S to the SMSGS. (1.5 and 1.6)

15 System Architecture Authentication Server (AS) Third party institution operated AS. The AS shares an institution generated subscriber specific secret key with each subscribers SAT applet. The institution and SAT applet are the only two entities that share this secret

16 Following the one off-initialisation above, the AS may then authenticate a user and SIM when requested by the Web Sever (WS), for example to authenticate a login, or approve a transaction. An authentication message is sent from the AS to the SAT applet. (2.2) Where AS-RAND is a random number from a good and unpredictable source of randomness. The AS receives message (2.3) and compares it with a locally generated expected response. If the SAT applet response matches the expected response the user and SIM are authenticated, otherwise the authentication fails. This marks the end of the protocol run. The SAT applet decrypts message (2.2) using its private RSA key and if a seed value has been previously stored for an AS with identity AS-IDENTITY then asks the user to enter their PIN to confirm the authentication. If confirmed the SAT applet generates a response to the challenge AS-RAND, using a keyed MAC function. (2.3) Scheme 2 – Two-factor authentication scheme OTP password based challenge-response based scheme, where the SIM generates a response to a random challenge sent by the authentication institution The protocol starts with a one off-initialisation step that sends the AS OTP seeding key to the SAT applet. (The seeding key is enciphered under the SAT applets public RSA key, SAT-PUB, obtained in the same way as in the previous scheme. The seeding key AS-SEED is then sent to the SAT applet along with the AS’s identity AS-IDENTITY The SAT applet stores the AS’s identity AS-IDENTITY and seeding key AS-SEED, after confirming this action with the user on the handset by requesting a PIN. SubsKey1 SubsKey2

17 Security Analysis - 1 RSA public key –use by both authentication schemes to exchange symmetric encryption keys used later on in the protocol RSA private key –generated internally within the SIM, no external method provide to retrieve NOTE: PKI is not implemented to verify the authenticity of the SIM’s public RSA key Web authentication credentials are entered into the handset, and are only stored on the SIM Credentials are encrypted –before they leave the SIM applet with the symmetric key of the destination entity. End-to-end encryption and protection of credentials should the SMSGS be compromised To guard against eavesdropping, man-in-the-middle and relay attacks: –Secure GSM 03.48 SMS –HTTPS (SSL/TLS)

18 Security Analysis - 2 Security of WBE? –May be vulnerable to screen scrapers, malicious plug-ins, Trojans as it does not operate within a secure environment –Same risks apply when entering credentials directly into the browser For the two-factor authentication scheme each AS shares a user specific individual secret key with the SIM only. As a result, if an AS were compromised only the keys owned by that AS would be vulnerable Both methods implement a PIN lockout function on the SAT applet to prevent exhaustive PIN search should the handset be lost or stolen

19 Conclusions Two novel authentication schemes presented Web credential storage and authentication Does not require any modification to existing websites and reduces the risk of password re-use as a user no longer needs to remember their credentials for individual websites and can choose a more secure or ever randomly generated password Protection against phishing attacks Acknowledged that as the scheme still uses existing form based password authentication it is still subject to attacks in the web browser on this authentication method Two-factor authentication Provides and enhanced level of authentication as the user’s SIM is authenticated in real- time using a random challenge generated by the authenticating parties AS A single SIM could therefore replace the multiple and often incompatible OTP tokens and card readers

20 Conclusions – Future work Implement generation of passwords on the SIM What happens if a SIM breaks or is stolen? –Currently all data and keys lost A challenge to the wider scale implementation is network operators ownership and control of the SIM –Use a JAVA MIDP applet on the phone to implement UI functionality, but store credentials on the SIM (using a lightweight SAT applet or writing data directly to the SIM file system) –Security of MIDP applets not guaranteed as they execute within phone OS Compromise security for accessibility?

21 Practical implementation SMSGS implemented using broadband modem, to send and receive SMS messages and PHP web scripts to implement SMSGS application logic PHP scripts hosted on Apache web server with mySQL database back-end for storage of data Kannel open source SMS/WAP gateway used to send and receive SMS network messages –Almost complete control over bit and bytes in SMS headers, enabling ability to send and received GSM 03.48 secure SMS messages

22 Practical implementation SAT applet developed using Gemalto Developer Studio –Integrated Development Environment (IDE) –SIM emulator –Phone Emulator –SMS server simulator –Debugging and testing

23 Practical implementation Web Browser Extension (WBE) –Developed for Firefox, but could have been done in Internet Explorer or any one of the other popular browsers that supports extensions –Key technologies in Firefox extension development XML User Interface Language (XUL) Document Object Module JavaScript Together known as AJAX (Asynchronous JavaScript and XML) –WBE scan pages for login fields, characterised by a page containing a field with an HTML input field followed by an HTML password field, also copes with multiple forms on a single page.

24 Demonstration SAT applet loaded onto development SIM card using SIM alliance loader (< 10KB size) Handset is a Nokia N95, also tested on much older handsets –Video 1: Authenticating against RHUL Outlook Web Access –Video 2: Adding a new set of credentials to the SIM for googlemail

25 Questions? Any questions? Jon Hart M.Sc. M.Eng. MIET Information Security Group, Royal Holloway University of London  : +44 (0)1784 443111  : jon.hart@rhul.ac.ukjon.hart@rhul.ac.uk

26 Website Credential Storage and Two-Factor Web Authentication with a Java SIM Sunday 11 th September 2011


Download ppt "ISG Distance Learning Weekend Conference 2011 Website Credential Storage and Two-Factor Web Authentication with a Java SIM Sunday 11 th September 2011."

Similar presentations


Ads by Google