Tunneled TLS for Multi-Factor Authentication
Contents
1. SYMMETRIC KEY K A PUBLIC PRIVATE KEY PAIR IS REPRESENTED AS Kz AND Kz RESPECTIVELY FUNCTION T LS EXECUTES ALL STEPS OF THE TLS PROTOCOL WITH SERVER AUTH ONLY FUNCTION cert s Ka REPRESENTS A CERTIFICATE FOR S S PUBLIC KEY ISSUED BY A TRUSTED AUTHORITY WITH A PUBLIC KEY K FINALLY ID REPRESENTS THE SECRET DEVICE ID UNIQUE TO p solutions is a full software implementation on a smartphond with Bluetooth We consider the last solution rather appealing and in Section pay special attention to an implementation of our protocol on such a device Application The research community has been enamored with authentication solutions that particularly apply to Internet caf s ICs see Section V Such an objective could not be more restricting considering the fact that there exist roughly 3 4 million ICs worldwide compared to tens of millions of points of sale that literally drive the entire world economy Later in Section we emphasize the benefits and draw backs of our proposal with respect to a list of applications Il TUNNELED TLS In this section we provide the objectives and details of the proposed authentication protocol A Preliminaries ENTITIES We consider the following entities s denotes a server which manages a database of user accounts It uses a standard certificate based public key infrastructure to authenticate itself to an arbitrary client c denotes a client computing platform personal computer terminal o2. a slight change to the server is required so that it can handle the tunneled TLS protocol The fact that the server receives a signal that a specific terminal is not trusted when a user connects via a trusted device calls for an action to reduce read access to identifying data with the user account This stresses the point that the server side is likely to change opportunistically rather than due to a necessity to accommodate our protocol 8For anonymity we did not include access to the protocol specification for the AVISPA verifier The final version will certainly include such a pointer CPUs in current smartphones are commonly clocked in excess of 400MHz e terminal side in order to perform the tunneling the terminal needs two components First it needs to install a browser plug in e g similar to Adobe Flash or Microsoft SilverLight Second the terminal must be able to connect to p using a wired or wireless connection In case Blue tooth is used the terminal would also have to be armed with a Bluetooth transceiver As opposed to most modern smartphones that do have Bluetooth many terminals are not equipped with it Upcoming standards such as the Wireless USB aim at facilitating this scenario e trusted device has to install an application reminiscent of a stripped down Web browser to handle the user interface to our protocol Similarly to the server side we believe that consumers are likely to act opportunistically
3. en wikipedia org wiki Tunneling_protocol for an informal description of tunneled protocols Fidelitycom Accounts amp Trade Investment Produ Log Out Open an Account Research Retirement amp Guidance Accounts amp Trade gt Portfolio Total 14 38 Log In Log In Fidelitycom Fidelitycom Accounts amp Trade Resear Accounts amp Trade Researq Summary Portfolio Positions Portfolio Research Portfolio Analysis Statements Rec Name Categorize or Hide Accounts Investment Accounts BROKERAGE 7 01 Select Action v Brokerage seeeeee97 5 LOG IN LOG IN Customer ID SSN Customer ID SSN Total 7 01 p Retirement Accounts y m y 2 C Login via mobile phone Login via mobile phone ROTH IAA _ 3 22 Select Action rj PIN Visible devices ee TESTAREA Darko Mobile v Total 3 22 Darko Mobile __ Go To optional Chris Mobile Savings Checking and Spending Accounts Start Page J Helen Mobile Select a device start Page mySmart Cash Account 4 15 Select Action v Cash Account eeeeeee98 L E Total 4 15 Need help logging in Need help logging in Portfolio Total 14 38 Security Notice Security Notice Fig 2 left An example of a user interface offered by the server to authenticate a user using a locally accessible personal and trusted mobile device right An example of how the server upon authentication marks account numbers to pr
4. a payment with it The user experience for this payment engine is similar to a payment with a traditional credit card I INTRODUCTION According to a market research report a surprising 9 of US online consumers have experienced identity theft 1 Those who fall prey are not online novices 52 purchased goods online in the past three months they have an above average online tenure of 5 6 years and 69 are technology optimists 1 Another report estimates that roughly half of the US consumers online are extremely concerned 5 on a 1 5 scale about computer malware online identity theft and interception of personal data as a consequence more than 75 of all US consumers chose to deploy free 24 paid and 1 no software for malware protection 2 This does not resolve fear as for example roughly one third of US online consumers chose not to use online banking from fear of identity theft security as a top competitive differentiator is used by 43 of banks to attract the remainder of the online population 3 The consequences are e direct identity theft results in billions of dollars worth of damage to the world economy 4 and e indirect the threat of identity theft limits consumers engagement in the online economy thus hurting the IT industry as well as numerous businesses that have found a more efficient way to conduct business by going online e g banking insurance financial services etc Phishing and key
5. accesses A from a trusted computer then s could either generate id p and send it to p for permanent storage or p could generate id p store it locally and register it with s id could also be a permanent number hardwired to each device ii p could disclose receive its id p during an SMS or other type of data communication with s where the user would authenticate herself to s by demonstrating knowledge of A With certain risks p could be enrolled from a distrusted terminal Then s would accept a login via p that is based upon the username and its password only 1 e a regular login to get to a point where registration of id p is performed This is an action that should be avoided as it can be done from any p For example a shoulder surfed password would turn any device into a valid p Device revocation via an 1 800 phone call or other form of direct connection to s would entail removing id p from the list of devices allowed to access A The user would be given an opportunity to register a new device using a trusted computer or a timed say during a phone call to a service center device registration via a distrusted computer D Design Choices for p The proposed functionality can be programmed into the mobile phone or onto a smart card SIM card used to transfer account features from one mobile phone to another Compared to general purpose computing platforms it is arguable whether mobile devices offer better or worse secur
6. device and the server 39 An alternative that does not use tokens has been deployed in Telcordia s S KEY a one time password system based upon Lamport s authentication protocol 40 Most of the vulnerabilities of traditional one time password systems could be resolved by using a PKI based protocol that authenticates the remote server as a starting point to a successful user server hand shake Since we follow this authentication paradigm we do not compare our protocol to one time passwords A Two factor Authentication Researchers have proposed several schemes that use a trusted personal device such as a mobile phone to improve the security of Web surfing Balfanz and Felten introduced the splitting trust paradigm that partitions an application e mail client in their case between a trusted portable device and a distrusted PC 8 An application installed on a hand held computer would prompt the user to selectively approve the process of digitally signing and sending a message to a server Although not tailored for MFA objectives their work was the first to use a general purpose portable device as a source of trust Parno et al proposed an anti phishing technology based on server certificates resident on the client Jackson et al introduced the notion of a transaction gen erator TG where instead of relying on stolen credentials a TG simply waits for the user to log in to his account and then issue transactions on behalf of th
7. etc are confirmed by a user action executed on p Finally p periodically e g say every 30 seconds 13 sends a ping signal to s over the tunneled TLS to assure of the continuous proximity between c and p The user can logoff by either walking out on c at which point the proximity between c and p is broken or by specifically sending a logoff signal from p to s again via the tunneled TLS The connectivity of the parties of interest in our protocol is illustrated using Figure 1 Section M reviews the construction and properties of the proposed protocol in detail We assume a broad threat model where among other as sumptions we consider e A virtual machine VM fully controlled by the adver sary is executing all operations on c i e the VM can manipulate the data and control flows of client s browser or any other resource at will e A ghost user interface is available to the malicious party who is in control of c The adversary can render an instance of an on going https session on a ghost display a display hidden from the user possibly being rendered on another computer and under the full control of the malicious party Within our objectives and considering the above security assumptions further detailed in Section we formally veri fied the proposed protocol using a publicly available off the shelf package AVISPA 15 In a brute force simulation of considered adversarial scenarios the v
8. intrusion robustness com pared to a general purpose computer however at additional design costs Certainly the design strategy for a mobile phone used for MFA should emphasize intrusion prevention as a premier design criterion Historically the critical entry points for malware on mobile devices have been Bluetooth SMS messaging and e mail 23 Finally the option to use a dedicated hardware device that offers tamper resistance and custom built intrusion prevention is certainly real However due to the strong recent trend for convergence of most mobile applications portable MP3 player digital camera GPS WiFi etc onto a single device our objective to fit the functionality of the proposed protocol onto a mobile phone is appealing II THE THREAT MODEL In this section we consider several threats and address them informally in our security analysis Case 1 Loss of p and the account password Since the authentication system is based upon the What I have p and What I know password authentication principles it is just to acknowledge that if the user loses p to a malicious party m who knows her password then m will have full access to user s account A in a classic case of identity theft Typically m will be able to impersonate the user until she notifies s of her loss of p All two factor authentication systems are prone to this attack see Section V Case 2 Intrusion into p This is a special case of the
9. less danger to the user identity compared to state of the art in modern detection based anti virus anti phishing and anti key logger technologies Compared to authentica tion technologies such as SecurID we point the Reader to the fact that our system addresses a novel problem where we do not focus on providing token based one time strong passwords instead we focus on fulfilling a small set of security requirements to enable a personal mobile device as an enabling technology to making an https or some other type of a login session secure on a fully distrusted client computer terminal Due to the wireless nature of the c p connectivity our protocol is designed to be robust to man in the middle attacks as opposed to SecurID 24 Compared to the most related work by Mannan and van Oorschot 11 we do extend their threat model to handle ghost displays and we offer a significantly simpler protocol that can be handled by traditional TLS handshakes only We also introduce several additional functionalities that aim at limiting a malicious party who is in control of c to read user s account state only at times when p and s are connected i e p responds to s s pings over the tunneled TLS channel IV REDUCTION TO PRACTICE A Formal Verification via AVISPA In order to formally verify the security of the proposed protocol we first described it using the High Level Protocol Specification Language which included a description
10. loggers are simple and popular identity theft methods Most tools that aim at addressing this problem by detecting such malware do suffer from being detected themselves and then circumvented In addition some of the available software for protection from malware is malware itself The core of the problem lies in the ease of collapsing the circle of trust between the user the remote server that offers service of interest to the user at cost and the IT infrastructure that connects them In this paper we look at multi factor authentication as one way to address this problem and opportunistically seek for novel applications mostly aiming at points of sale A The Problem Informally the problem statement is simple A remote server hosting a user account wants to authenticate that a client who is logging under the user s name is indeed controlled exclusively by the user herself himself It is rather difficult to formalize this simple problem description within the existing computing milieux The research community has tried to resolve the problem of user authentication from a fully distrusted computer using a broad set of methodologies based upon multi factor authen tication MFA MFA approaches rely upon at least two of the following three authentication paradigms e what I know the most commonly deployed mecha nism a password suffers from the following issues it is easy to intercept thus opens doors to a range o
11. never observes these credentials in plain text and A solid informal survey of standard MFA techniques can be found on ii write confirmation faced with the threat of transaction generators TG 9 and cross site scripting XSS attacks 10 the server s would seek a confirmation for each write to the user s account state via p I Instead of relying on stolen credentials a TG simply waits for the user to login to her account and then issue transactions on behalf of the user 9 Cross site scripting XSS is a type of computer security vulnerability typically found in web applications which allow code injection by malicious web users into the web pages viewed by other users An exploited cross site scripting vulnerability can be used by attackers to bypass access controls such as the same origin policy In recent years XSS surpassed buffer overflows to become the most common of all publicly reported security vulnerabilities 12 secure logoff a periodic ping from the trusted device 13 as well as an explicit logoff signal issued by the user from p are two system actions that can ensure s about the proper lifetime of a secure session Since XSS attacks rely on the existence of established secure sessions at victim s computer enabling secure logoff is as important as enabling the secure login iii adversary TA Server Account distrusted Terminal trusted personal Device Fig 1 Par
12. of TLS and SRP adopted from 26 Descriptions of the adver Sarial scenarios were more demanding compared to standard two party protocols because our protocol encompassed four entities including the intruder this additional complexity con tributed to uncharacteristically long and resource consuming verification efforts Next we verified the protocol specification using the Automated Validation of Internet Security Protocols and Applications analysis tool AVISPA 15 26 AVISPA is positioned as an industrial strength technology for the analysis of large scale Internet security sensitive protocols and appli cations The ofmc theorem prover attached to AVISPA 27 reported a search time of 36 7 seconds 18207 visited nodes and a search depth of 15 plies The alternative cl atse theorem prover 28 also part of the AVISPA distribution reported analyzing 6092736 states within a space of reachable 699886 states in 156 3 seconds Both theorem provers found no attacks on the protocol B Implementation Implementation of the proposed protocol is straightforward as it involves only existing building blocks TLS auth can be executed with a variety of public key cryptosystems such as RSA or elliptic curves which all yield different computational costs at s c and p At the server each TLS handshake costs approximately one expensive if RSA is used private public key operation and at the client each TLS handshake costs approximately tw
13. Based Protocols Secure Against Dictionary Attacks IEEE Security and Privacy Oakland May 1992 31 M Bellare et al Authenticated Key Exchange Secure against Dictionary Attacks Eurocrypt 2000 32 V Boyko et al Provably Secure Password Authenticated Key Exchange Using Diffie Hellman Eurocrypt 2000 33 O Goldreich and Y Lindell Session Key Generation Using Human Passwords Only Crypto 2001 34 J Katz et al Efficient Password Authenticated Key Exchange Using Human Memorable Passwords Eurocrypt 2001 35 A Biryukov et al Cryptanalysis of the alleged SecurID hash function SAC 2003 36 A Biryukov et al Recent attacks on alleged SecurID and their practical implications Computers amp Security Vol 24 no 5 pp 364 370 2005 37 S Contini and Y L Yin Fast software based attacks on SecurID Fast Software Encryption Workshop pp 454 471 2004 http en wikipedia org wiki Identity_theft 38 Netcraft Phishing attacks continue to grow in sophistication January 2007 http news netcraft com archives 2007 01 15 39 G G Xie et al Quantifying effect of network latency and clock drift on time driven key sequencing ICDCS 2002 40 L Lamport Password Authentication with Insecure Communication Communications of the ACM Vol 24 no 11 pp 770 772 1981 41 B Parno et al Authentication and fraud detection Phoolproof phishing prevention FC 2006 42 M Wu et al Secure web authentication
14. D is a dedicated device that uses token based authentication to enable strong one time passwords 13 24 SecurID consists of a token a piece of hardware e g USB attachment or software e g a soft token for a cell phone assigned to a computer user that generates an authentication code at fixed interval using a built in clock and the card s factory encoded random key known as the seed The seed is different for each token and is loaded into the SecurID server The token llWe do not review the related work in mobile payment mechanisms because most methods in use are touch less RFID based and as such prone to skimming Usually 30 or 60 seconds hardware is designed to be tamper resistant to deter its reverse engineering The seed is the secret key used to generate one time passwords A user authenticating to a network resource needs to enter both a personal identification number and the number being displayed at that moment on their token The server which also has a real time clock and a database of valid cards with the associated seeds computes what number the token is supposed to be showing at that moment checks it against what the user entered and makes the decision to allow or deny access SecurID is prone to the man in the middle attack 35 36 as experienced by the Citibank in July 2006 38 Passwords generated by time based generators may face time synchronization issues between a client
15. Springer 2007 7 T Matsumoto et al Impact of artificial gummy fingers on fingerprint systems SPIE Vol 4677 2002 8 D Balfanz and E Felten Hand held computers can be better smart cards USENIX Security Symposium 1999 9 C Jackson et al Transaction generators root kits for the web USENIX Workshop on Hot Topics in Security 2007 10 J Rafail Cross Site Scripting Vulnerabilities CERT Coordination Cen ter Carnegie Mellon University 2001 http www cert org archive pdf 11 M Mannan and P C van Oorschot Using a personal device to strengthen password authentication from untrusted computer FC 2007 12 S Christey and R A Martin Vulnerability Type Distributions in CVE version 1 1 MITRE Corporation May 22 2007 documents vuln trends index html 13 RSA SecurID Securing Your Future with Two Factor Authentication http www rsa com node aspx id 1156 14 T Dierke and E Rescorla The Transport Layer Security TLS Protocol Version 1 2 IETF draft TLS RFC5246 2008 tfc5246 15 A Armando et al The AVISPA Tool for the automated validation of internet security protocols and applications International Conference on Computer Aided Verification Vol 3576 pp 281 285 2005 16 T Dierks and C Allen RFC 2246 The TLS Protocol Version 1 0 January 1999 Status Proposed Standard 17 L C Paulson Inductive analysis of the internet protocol TLS ACM Trans on Computer and System Security Vol 2 no 3
16. Tunneled TLS for Multi Factor Authentication Darko Kirovski and Christopher A Meek Microsoft Research Redmond WA USA Contact darkok microsoft com TECHNICAL REPORT MSR TR 2009 50 APRIL 2009 MICROSOFT RESEARCH ONE MICROSOFT Way REDMOND WA 98052 USA http research microsoft com Tunneled TLS for Multi Factor Authentication Darko Kirovski and Christopher A Meek Microsoft Research One Microsoft Way Redmond WA 98052 Abstract When logging onto a remote server from a distrusted terminal one can leak secrets such as passwords and account data to various forms of malware To address this problem we take an existing approach of using a trusted personal device as the interface available to users for entering their login credentials In our proposal such a device would send the credentials to a server using a tunneled TLS session routed via a distrusted terminal The tunneling would be done within an existing TLS session established between the terminal s browser and the server Upon validating the credentials the server would enable the terminal to access the user account Consequently the terminal would never see in plain text the login credentials We show that the proposed protocol resists arbitrary key loggers phishing agents cross site scripting and invasive virtual machines As a powerful and surprising application if the distrusted terminal is at a point of sale the trusted device could use our protocol to execute
17. adversary m would have a virtual display resolution twice as large as c s display One half of the virtual display would be connected to c s screen the other half to another machine m controlled by m Cm would also have a parallel user input augmented into c s I O This attack is relatively easy to do by running a malicious virtual machine on c When the user logs onto s via c m would open another browser window in the part of the virtual display that s visible only to Cm and use the parallel I O to browse the data from A at will Since every write generated by m would need to be confirmed by the user via p it is unlikely that m could perform any writes into A s state By realizing that such an attack is a possibility s could offer viewing only part of the data related to A over a tunneled TLS connection that minimizes the damage that a ghost display attack could cause Case 5 Cm gt lt p The case when the user mistakenly connects p to a malicious computer c instead of a desired physical unit c is equivalent in the worst case to the consequences of the ghost display attack Still the user is more likely to detect the Cm X lt p attack as the expected Web pages from s will not appear on c although p would show a successful tunneled TLS connection with s The user would prevent m from browsing her data by instantly disconnecting p from s Finally note that all realistic threats in this system pose substantially
18. e user The authors discuss rootkit like methods that allow TGs to hide their tracks and explore a number of mitigation techniques including transaction confirmation 9 The most related research is that of Mannan and van Oorschot who introduced a protocol which cryptographi cally separates a user s long term secret input from c c would perform most computations but would have access only to temporary secrets The user s password would be input through p p would provide user s long term secrets to a c only after encrypting them using a pre installed correct public key of s We expand upon this protocol by proposing a tunneled TLS channel between p and s that could be used for verification of connectivity between p c and s in addition to sending credentials Thus we provide better protection from ghost user interfaces 1 e transaction generators for both reads and writes to the server managed account state 13 Alternatively known as OPIE or OTP Wu et al were the first to propose a proxy based authen tication scheme that employed a trusted proxy server which stored user s credentials 42 In their informal proposal a user would use a distrusted machine to send an access request and her username to the trusted proxy which would respond with a random session name The same session name is then sent to the users mobile phone as an SMS message The user would compare the displayed session names and acce
19. eir customer s mobile phones Here s would represent a bank or a credit card company c a cash register at say a supermarket and p would represent a customer s mobile phone Instead of typing in a password a PIN could facilitate the data entry at the consumer s side The consumer would approve of a transaction after browsing through a downloaded shopping cart and agree ing to the price with an entry of a PIN The cost of this transaction for both the merchant as well as the credit card company would be significantly lower than when running a transaction via a dedicated communication channel 10See http en wikipedia org wiki Wireless_USB for more details In addition this payment mechanism offers a significant advantage over credit cards because of the impossibility of skimming Although the cardinality of this setting is in the order of 10 locations points of sale drive virtually the entire world economy Thus the applicability of our scheme to this scenario is of particular importance Finally the type of applications that would benefit from our platform include various financial services e g credit card companies banks investment brokers etc account man agement for on line bill payments vaults for health records government agencies storage and application services for cloud computing personal communication systems such as e mail or instant messaging etc Note that the system that we propose does not establ
20. el Sewrs Temmie Dwep Kse TLS Ks I cert s Ks II html html m Ekg html gt c login ogr page Wi ogm via p opaon with login via p opion g e R EN Ks all further communication between s gt c is tunneled via this TLS channel DKs m1 display html pairs wihp paswihe all TLS messaging between s p is passed through the s c tunnel on its way to from p User visits https www s com rom c checks login via p installs device discovery app at c controls pairing UI at p and c visits https www s com rom p all further messaging between s gt p is tunneled via the s p TLS channel the s p TLS channel is always tunneled via the s c TLS channel on its way from to c to from s m2 Ek html p t html z gt P form to enter username pwd x challenge r Dkp m3 if f r 2 h password ID then m4 Ex html gt c html page with account info html html x Drp m2 display html r f x h pwd ID m3 Ex r gt s visits https www s com from p enters credentials pwd password D kse m4 display html accesses account at s from c TABLE I DESCRIPTION OF THE TUNNELED TLS PROTOCOL STEP V WAS INTENTIONALLY SKIPPED FUNCTIONS f AND f t REPRESENT RESPONSE AND VERIFICATION FUNCTIONS TO A CHALLENGE amp RESPECTIVELY FUNCTIONS D g AND Eg DECRYPT AND ENCRYPT RESPECTIVELY USING A
21. er interfaces of both c and p This could be achieved using several mechanisms e g V 1 p would generate a large random number r send it to s and display it on p Then s could display r on c and ask the user to confirm that c and p both show r The confirmation must be made on p s user interface Step VI Login Now s sends a Web page to p asking the user to provide the login credentials the username and the password After entering the data p sends out the information tagged with its identifier id p e g a random long number that s associates with A This number is stored with p and s when the account is open and or p registered with s by the user The purpose of zd p is to impose a limitation that A is accessed only by devices approved by the user and s they could associate several devices with A The s e id p e p association procedure is detailed later in this section Login credentials username password and id p could be sent over the encrypted p s TLS channel using an arbitrary password authentication protocol including weak ones such as a hash of the plain text password In the formal verification of the proposed protocol we used a variant of the Secure Remote Password SRP protocol SRP 6 detailed in 18 19 Another elegant way to implement the verification of credentials is via a challenge response scheme where s would send a challenge random number x to p p would compute a 6See Wikipedia entry http
22. erifier did not find a single vulnerability Section IV details this effort as the main experimental result C Preliminary Discussion Server change A server must be cognizant of the fact that a specific secure session is launched from a terminal which the user does not trust hence the server in its own as well as in the interest of the user should restrict display of identifying data on such a terminal e g account number birthdate as well as ask for a confirmation for each crucial write to user s account Although most related work has pursued authentication systems which do not pose demand for server side alterations see Section V we stress that this objective is flawed as servers must address the fact that all data sent to and from the browser that resides in c is assumed public To that extent we anticipate that reliable MFA would require changes to s and thus propose a protocol that also asks for additional minor steps from s Choice of trusted device We acknowledge that the design of the trusted personal device p could be realized so to reach different security vs cost configurations The top end would be represented by an intrusion proof tamper resistant dedicated personal device with a full user I O interface e g keyboard and display similar to a mobile phone and a Web browser with minimal HTML parsing rendering capabilities e g scripting and dynamic content disabled One of the least expensive S
23. event data sniffing response r f id p x h password where x represents a random nonce h represents a cryptographic hash function such as SHA 256 that operates over the concatenation of its arguments and f is a response function such as h or a public key signing function such as RSA with id p being used as the private key Once s receives r since it has access to x h password and id p in case f h or id p in case f is a public key signature i e the public key that corresponds to id p it can validate the authenticity of the credentials by verifying against r If s positively authenticates the information sent from p it would allow c access to A As a precautionary action s should present only limited content about A on c for this logon case specifically The primary objective is to prevent a potential data sniffing agent at c to obtain crucial information about A such as the account number and the username An example of a Web page that avoids presenting crucial account information is presented in Figure 2 right Finally it is important to stress that all data sent between s and p is encrypted with Ksp That way c cannot fool p into revealing its credentials to a third party or c Only a party who owns the private key correspondent to s s certificate will be able to read this cipher text This cipher text is additionally encrypted with Kse on its way from c to s Post auth step VII a Write confirmat
24. f attacks from key logging to shoulder surfing and even modest entropy implies a memorization challenge 1 e passwords are prone to directory attacks 5 e what I have the user proves to the remote server dur ing authentication that he she is in possession of a trusted device 1 e its secrets This method is used predominantly as an amplifier of trust during authentication Apart from inadequate security protocols the only problem related to this authentication paradigm is the fact that it cannot be used exclusively i e anyone who has access to the device could impersonate the users whose secrets are stored on it e what I am scan of user s biometric traits is used as a discriminator during authentication 6 This method is plagued by many issues human assistance during verification is necessary because it is rather easy to fool the measurement equipment 7 poor practical error rates 6 cost privacy and inconvenience at use Considering the strengths of individual authentication paradigms most proposals rely upon passwords and authen tication hardware The body of research work that introduces protocols that leverage upon these two approaches is fairly diverse and we review it in Section V We recognize several crucial objectives i secure login the initiative for migrating the input of user credentials from the distrusted terminal c onto a personal trusted device p with an objective that c
25. inal c b s authenticates the user by using the what I have device p and what I know account password authentication paradigms c the credentials that answer the authentication questions are never communicated in plaintext via c clearly they are entered using p d a session between s and c is alive as long as the user continuously demonstrates that she can answer what I have to s and e all critical actions with the account are verified by an action from p Since we assume that the system I O at c could be inter cepted recorded and or modified by a malicious party the best that the account user could hope for is that the adversary i cannot gain access to login credentials thus cannot access the account at a later time ii Cannot initiate or interfere with critical actions during a s X c session Note that editing the system I O in real time i e terminal screen is an attack possibility although difficult that should not have serious conse quences as all critical actions cash transfers payments stock transactions with the account are verified via p A question arises if p is a trusted platform why not access the account entirely from p Mobile computing devices commonly do not have user interface options that enable comfortable data display and entry thus combining the convenience of the desktop user interface with the trust associ ated with personal computing devices makes
26. ion Once c starts accessing information about A at s under the assumption that the entire I O to c is controlled by the adversary there exists a demand to verify all critical data writes i e cash transfers stock transactions etc into A initiated from c This is done by asking for explicit approval from p for each critical write into A initiated by c Post auth step VII b Read validation In addition as we assume that c is in control of a ghost display it could fool the owner of p into an action by presenting false information on its terminal 1 e false stock price or missing credit card transaction To that extent we allow the user to ask for specific parts of Web pages presented on c to be forwarded by s to p for content verification Such requests could be handled by a simple AJAX script augmented into a Web page served by s onto c Post auth step VII c Continuous What I have Finally in order to prevent the adversary from browsing data on A when p loses power or connection to c s would continuously ping p to resume the session with c This way p can logout from a current session by ceasing to respond to pings from s One simple implementation of a ping could be a challenge to p to encrypt a counter using Ksp The counter would increment after each challenge and start from a large random value set by s during the initial TLS handshake in step IV An alternative method for logging off is a
27. ish user identities our protocol solely enables authentication with substantially improved security especially against nowadays most common attacks such as cross site scripting key loggers and phishing V RELATED WORK In light of an industry and government driven demand for secure authentication several schemes that utilize various approaches have been proposed to date For example the US federal banking regulators have concluded that the basic user ID and password are not sufficient to protect against fraud and issued guidelines for banks to implement multi factor authentication to mitigate risks in online banking 29 Password Authenticated Key Exchange The first successful password authenticated key agreement method was the Encrypted Key Exchange EKE protocol 30 Although several of the first methods were flawed the surviving and enhanced forms of EKE effectively amplified a shared password into a shared key which could then be used for encryption and or message authentication The first provably secure PAKE protocols were given in and 32 These protocols were proven secure in the so called random oracle model the first protocols proven secure under standard assumptions were 33 and 34 In our work we rely on a tra ditional PKI TLS based key exchange thus we do not review and compare our work to non PKI password authenticated key exchange protocols One Time Password Systems RSA s security key fob SecurI
28. ity with respect to viral malware We review certain design parameters for mobile devices that could be advantageous e All or most of the software on a mobile phone is controlled by the service provider This feature typically redirects the responsibility for virus protection from the owner of the device to its service provider e On most mobile phones the real time hardware stack that handles the voice communication is isolated from the general purpose programmable unit The latter hosts the general purpose OS and resident applications These hidden computing resources offer an inexpensive alter native to smart cards for incorporating security features that adversaries cannot access with malware installed on the programmable unit e It is relatively easy to implement a non programmable and tamper resistant operational mode on a mobile phone e The system design of a mobile phone is self contained and allows deployment of more radical intrusion man agement platforms such as randomized instruction sets 21 or intrusion prevention via code signing 22 e Finally it is more difficult to write robust malware for mobile phones as software development kits available for most embedded OSs do not offer full support to all features of the underlying OS This development hurdle has kept the list of attacks on mobile phones relatively short 23 Considering the above arguments one could expect that a mobile phone should achieve better
29. n installed on c by s or some other not necessarily trusted source such as an OS manufacturer credit card company or phone manufacturer would seek for neighboring Bluetooth devices The user would then select c and p as pairing choices on p and c respectively An example of an interface that would enable the selection of a specific p on c is presented in Figure 2 left Bluetooth does not offer any cryptographic guarantees that two specific units are connected directly Fortunately in our setup such a guarantee is not required From c s perspective the correct identity of p is not important because c only serves as a user interface to the account that p s credentials can access From p s perspective connecting to the correct c is important because of usability issues but irrelevant for In the remainder of this article when we refer to c we mean c s Web browser unless otherwise stated Details of the Transport Layer Security TLS protocol and its predecessor Secure Sockets Layer SSL protocol can be found at http en wikipedia org wiki Secure_Sockets_Layer security as we already assume in our threat model that the adversary has full access to c We address the convenience of a correct connection to a specific c in step V of our protocol Step IV Tunneled TLS handshake s x p wW server only auth Once c and p are connected p would use the c p communication channel to initiate a new TLS hand
30. o inexpensive public operations TABLE II PERFORMANCE OF BASIC PUBLIC KEY ROUTINES ON A 13MHZ ARM PROCESSOR WE DISPLAY THE REQUIRED MEMORY FOOTPRINT FOR THE CODE STACK AND HEAP FOR EACH OF THE ROUTINES AND THE NUMBER OF CYCLES REQUIRED TO EXECUTE IT ALL PERFORMANCE NUMBERS ARE FOR PETER MONTGOMERY S IMPLEMENTATION OF RSA 1024 BIT AND ECC WTLS 163 BIT CURVE 3 Code size Stack Heap Cycles EC DH 2 7M 150ms EC DSA SignVer 5 4M 300ms RSA PubEnc 3 8M 210ms RSA PrivDec 198M Ils We present the performance of basic public key routines on an outdated 13MH ARM TDMI720T processor in Table We display the required memory footprint for the code stack and heap for each of the routines and the number of cycles required to execute it All performance numbers are for Peter Montgomery s implementation of RSA 1024 bit and ECC ECDH and ECDSA considered over WTLS 163 bit curve 3 One can notice that the proposed protocol doubles the computational cost on the server as two TLS sessions are required per login Still in most applications crypto related computations per TLS session are dwarfed by overall compu tation costs of an average TLS session hence such an overhead is acceptable considering the benefit of MFA C Applications In order to evaluate the applicability of our protocol we outline its disadvantages regardless of comparisons to similar technologies Our platform induces several changes e server side
31. pp 332 351 1999 18 T Wu The Secure Remote Password Protocol Internet Society Network and Distributed System Security Symposium pp 97 111 1998 19 T Wu SRP 6 Improvements and Refinements to the Secure Remote Password Protocol IEEE P1363 Working Group 2002 http srp stanford edu design html 20 Y Lu et al The Conditional Correlation Attack A Practical Attack on Bluetooth Encryption CRYPTO 2005 21 G S Kc et al Countering code injection attacks with instruction set randomization ACM Conference on Computer and Communications Security pp 272 280 2003 22 D Kirovski and M Drinic A Hardware Software Platform for Intrusion Prevention IEEE MICRO 37 2004 23 N Leavitt Mobile phones the next frontier for hackers Computer Vol 38 no 4 pp 20 23 2005 24 Wikipedia RSA SecurID 25 The High Level Protocol Specification Language AVISPA project 2003 26 Avispa a tool for Automated Validation of Internet Security Protocols http www avispa project org package user manual pdf 27 D A Basin et al Ofmc A symbolic model checker for security protocols International Journal on Information Security Vol 4 no 3 pp 181 208 2005 28 M Turuani The cl atse protocol analyser RTA Vol 4098 pp 277 286 2006 29 Federal Financial Institutions Examination Council Authentica tion in an internet banking environment 30 S M Bellovin and M Merritt Encrypted Key Exchange Password
32. previous attack where the adversary penetrates p with an arbitrary program that enables full visibility of its internal storage To prevent this attack the construction of p must be such that software resident on p should not be able to read id p into p s general purpose registers reads and writes of id p requested by s should be done using a hardware only mechanism That way intrusion into p via a Trojan virus would equal to password leakage In a more complicated version of this attack if the malicious code installed on p takes control over its user interface 1 e it could both read from and write to the variables that constitute the user interface this code could launch arbitrary malicious actions from p on behalf of the user Such an attack should demand great sophistication of the malicious party and is unlikely on most modern mobile phones as their operating systems are custom built and difficult to reverse engineer Case 3 Phishing p A traditional phishing attack onto p via the c amp p connection is not possible by construction When p is registered with s our protocol establishes a device identifier id p and stores it at p along with the id p lt s association At a later time only a TLS protocol with s and no other entity is allowed to access id p thus any phishing attempt from c will be outward rejected by p Case 4 Ghost display would probably be the most realistic and unnerving attack to the user Here the
33. pt the session on the mobile phone if there were a match The proxy would use the stored credentials to login to the desired server One effective constructive protocol for proxy based authentication has been proposed by Florencio and Herley 43 Proxy based schemes leave a lot to be desired as they require users to trust the proxy i e a sophisticated intrusion into the proxy would reveal users passwords and their system cost is linearly proportional to the traffic exhibited over the proxy Our and related protocols do not suffer from these problems however proxy based authentication could be set up so that the server application is intact 43 Finally we review some benefits that our scheme introduces compared to related work A third party such as a proxy does not participate in our protocol thus the user does not need to trust anyone else but c and to a certain extent p To run the protocol the trusted device does not need to be connected to a global data network via SMS WiFi or other data channels Thus our protocol is robust to outage of the voice and or data wireless service The users in our scheme do not need to type long dynamic passwords onto their personal devices they also do not need to carry with them at all times print outs of lists of viable one time passwords We allow the protocol to run via the set of functionalities included in most generic smart phones which greatly facilitates implementation efforts Lo
34. r even virtual machine which is not trusted by its users The assumption is that the full user interface e g keyboard mouse display could be intercepted al tered and stored by a malicious party who has unlimited access to c e g via a Trojan virus or otherwise p denotes a personal computing device such as a mobile phone trusted by the user This device can establish a connection to any c via a common public wireless or wired communication protocol such as Bluetooth or USB 3See Wikipedia entry http en wikipedia org wiki Smartphone for infor mal definition We assume that the incoming networking stack into p 1s built to be robust to intrusion attacks Hence we assume that the existence of a relevant data sniffing mechanism on p is unlikely Section II D discusses these assumptions in detail DEVICE PAIRING A wireless connection between c and p is of particular importance due to its convenience We assume that the pairing protocol between c and p which initiates their wireless communication does not guarantee to p that it has connected to a specific physical unit c We also assume that c is previously unknown to p i e they have never had a mutual connection The fact that security is not imposed during the pairing process simplifies this step as cumbersome trusted pairing protocols are not required OBJECTIVE A user wants to log onto her account at s so that a access is granted from to a specific physical term
35. rather than due to a necessity c personal computer c public terminal c point of sale TABLE II EASE OF USAGE AND DEPLOYMENT OF THE PROPOSED PROTOCOL WITH RESPECT TO A GRID OF POTENTIAL APPLICATION TARGETS VS SYSTEM COMPONENTS THAT DEMAND ALTERATIONS TO OPERATE THE PROTOCOL SYMBOL v DENOTES CONVENIENT DEPLOYMENT SYMBOL o DENOTES LIKELY DIFFICULTIES IN USAGE It is important to evaluate how the burden on c imposed by our protocol would resonate in the main application domains We identify three main settings for c and illustrate their fit with respect to our protocol in Table e personal computers include home office mobile computing devices with full I O These devices are under the control of one or a few users who are not likely to find installation of a browser plug in difficult Similarly those who appreciate the value of MFA are likely to support their authentication mechanisms with a Bluetooth transceiver costs less than US 5 We point the Reader to the fact that the cardinality of this setting is in the order of 10 machines worldwide e public terminals located at public computing centers and Internet caf s could be under a ban on installing any browser plug ins because of fears for system security In such a setting our platform would not gain ground The cardinality of this setting is in the order of 10 machines worldwide e points of sale could use our protocol to run transactions against th
36. shake tunneled via the existing s c TLS session In other words all the TLS messaging between s and p would be encrypted decrypted using Kse as c relays receives it to from s By using tunneling we ensure that all attacks on our protocol must involve full control over c We assume that p holds a correct public key of the trusted authority who signed s s certificate used in the TLS handshake Similar to step I p would authenticate s but not otherwise The result of the TLS handshake a session master secret Ksp would be used for encrypted communication between s and p Similar to the s amp p handshake all further communication between s and p already encrypted with Ksp would be additionally encrypted with Kse Step V Verifying c p Before accessing A p wants to ensure that it is connected to the correct c This is a mere convenience feature as the user does not want to connect accidentally to incorrect terminals in the computer center Since all data displayed on c is considered public at this point the user understands that her actions with accessing the account could be seen by others It is the responsibility of s to anonymize the presented account data in such a way that a malicious observer cannot figure out the identity of p s owner The key idea behind assuring the owner of p that her device is connected to the correct c is in showing that some secret data or user action is shared on the us
37. specific log off signal sent to s by p this approach achieves an instant termination of the s X c TLS connection The described protocol I VI VII a c is specifically con structed to address the objectives presented in Subsection II A Key steps of the protocol all but step V are illustrated in Figure 3 Note that although c and p communicate over a non secure BlueTooth connection EO used in Bluetooth has been proven vulnerable to several attacks 20 the platform still achieves its objective The protocol proposed in this section could be used for numerous other applications such as a universal payment method without any e cash stored on p coupons etc Other commonly used devices such as PocketPCs mobile music players etc could be used to provide these functionalities 7See Wikipedia entry for Asynchronous JavaScript and XML at http en wikipedia org wiki AJAX initial Knowledge knowledge 2 a D trusted personal distrusted iam Server Device Terminal Sx Ue A adversary Public key Kpya s Public key Kpus t Public key Kpup t Certificate for Kpup s initial aN signed by t initial Knowledge yi c s TLS handshake with server auth only o Device discovery Symmetric session 24 key Kc Symmetric session gt key Kgc p s TLS handshake Encrypted p s TLS handshake
38. ss of the trusted device is not a threat to security as long as the corresponding passwords are not compromised otherwise the device itself does not store any passwords Our threat model assumes that the adversary has full access to the distrusted terminal And last but not least our protocol can use any public communication channel between c and p such as Bluetooth VI SUMMARY We propose a simple TLS based protocol that enables an off the shelf smartphone to assist a password based user authentication from a fully distrusted terminal The set of appealing applications includes a mobile payment platform that is robust to skimming and loss of the payment device while being convenient for use In the general computing milieux our protocol prevents phishing key loggers cross site scripting invasive virtual machines and transactional generators from achieving their objectives REFERENCES 1 K Delhagen et al Consumer Concerns Over Identity Theft And Fraud Forrester Research report June 21 2004 2 N Lambert et al Consumers Combat Their Internet Fears With Free Protection Measures Forrester Research report June 19 2008 3 B Cundiff et al Online Banking Jupiter research report BNKO5 C03 April 1 2005 10 4 Wikipedia Identity theft 5 D V Klein Foiling the Cracker A Survey of and Improvements to Unix Password Security USENIX Security Workshop 1990 6 A K Jain et al Handbook of Biometrics
39. this and similar proposals appealing secure and ubiquitous We review several design choices for p in Subsection I D B The Protocol Let s assume the scenario of logging onto a banking account A using a public computer c located at a university comput ing center The owner of the account also has a mobile phone p at her disposal By following a standard login procedure login credentials for A would be exposed to a key logger installed on c Here is the proposed remedy its steps are illustrated in Table Step I TLS handshake s x c wW server only auth Using c s Web browsel the user would establish a TLS session https with the provider of the service A s Here only c would verify the authenticity of s using stan dard public key cryptography not the other way around An established TLS connection assumes a successful symmetric key exchange The exchanged master secret Kse is used for encrypted communication between s and c Details of TLS can be found in with a formal verification in 17 Step II Login choice Then s would provide a Web page to c with a log in fill out form username and password as well as a user interface to select the type of login Web only or via p that the user can check select to log via a Bluetooth enabled device An example is presented in Figure 2 left Step II c p device discovery In the latter case which is of interest here a small applicatio
40. ties of interest in multi factor authentication a server s hosting a user account a terminal c assumed to be fully under the control of the adversary and a trusted device p in the hands of the account owner B The Contribution We address i iii by proposing an authentication system based upon a simple tunneled TLS connection from p to s The simplicity of the proposed protocol as well as the fact that it addresses effectively several challenging and important problems in authentication represent the key contribution of this work In our protocol first c authenticates s using a standard PKI based TLS connection 14 Next c connects to p using a local wired or wireless near field communication channel such as BlueTooth We do not require that this connection is authenticated and or private hence cumbersome trusted pairing protocols are avoided Then s initiates a separate TLS connection tunneled via c into p in order to achieve the MFA objective obtain a password a device identifier and or a biometric template from the user As a consequence c never observes in plain text the authentication credentials Upon validating the credentials s grants c access to the user We refer to the Transport Layer Security protocol and its predecessor the Secure Sockets Layer as means of authentication via a public key infrastructure account so that all writes to the account state 1 e stock purchase money transfer sending an email
41. with with server auth only Symmetric session key Ksp device knowledge user knowledge Encrypt Decrypt with Ksc server auth only Symmetric session key Ksp lt q Hash Device ID Password Hash Device ID Password periodic device Device Alive i signal Decrypt Encrypt Encrypt Decrypt with Ksp lt gt Encrypt Decrypt with Ksc lt gt with Ksp writes to A by the terminal are verified by the device using the same communication channel as in step Fig 3 Encrypt Decrypt with Ksc lt display A lt t grant read access Block diagram of protocol steps c and s start with a TLS handshake then c and p discover each other next p starts a TLS handshake with s that gets tunneled via c M lt s finally p sends the login credentials so that only s can read them Post authentication signals among the protocol entities include device alive i e a continuous what I have signal that assures s that p is still connected to c and A data command sent by c to s via c Xs which initiates a write confirmation signal from s to p via p X s s would execute A data only if p responds affirmatively C Enrollment and Revocation It is important to describe how s enrolls p to access A This can be done in several ways i when the user
42. with mobile phones DIMACS Workshop on Usable Privacy and Security Software 2004 43 D Florencio and C Herley One time Password Access to Any Server Without Changing the Server ISC 2008 11
Download Pdf Manuals
Related Search