370 likes | 526 Views
Some New Applications of One-Time Passwords. Burt Kaliski, RSA Laboratories October 2006. Outline. One-time password systems Four new applications – all based on research at RSA Laboratories RSA Laboratories’ One-Time Password Specifications Suggested research projects.
E N D
Some New Applications of One-Time Passwords Burt Kaliski, RSA Laboratories October 2006
Outline • One-time password systems • Four new applications – all based on research at RSA Laboratories • RSA Laboratories’ One-Time Password Specifications • Suggested research projects Disclaimer: Some techniques herein may be subject to RSA patents and patent applications
314152 One-Time Password Systems • Token generates a sequence of passwords from a seed • Server verifies the passwords – each can be used one time • Due to skew, more than one may be acceptable at a given time OTP user server 314152271828161803… OTPs can be a function of time, counter, and/or challenge token
Four New Applications • How to authenticate to a laptop computer with an OTP token • without storing long-term secrets on the computer • How to use the same token to authenticate to multiple servers • without sharing secrets or relying on a third party • How to set up a strong, shared key between parties that only share a short OTP value • How to protect OTPs against malware and MITM attacks
314152 1. Authenticating to a Laptop with an OTP • Problem: How to authenticate to a laptop computer with an OTP token OTP X user laptop server token
314152 One Approach: Embedded Server • Embed the server in the laptop • But need trusted hardware to protect the long-term seed OTP user laptop token
314152 Another Approach: Downloaded OTP Values • Download a range of OTP values to the laptop • But easy for attacker who steals the laptop to impersonate user OTP OTPs 314152271828161803… (setup) user laptop server token
314152 New Approach: Hashed OTP Values • Download the hashes of OTP values to the laptop • Extra work to reverse hash deters attacker OTP H (OTP)s H (314152)H (271828)H (161803)… (setup) user laptop server token
Details • Setup: Laptop stores a range of hashed OTPs (with salts): H (OTPi, salti), saltiH (OTPi+ 1, salti+ 1), salti + 1H (OTPi+ 2, salti+ 2), salti+ 2… • H should be a slow hash – increases effective search space • Salt prevents precomputation attacks • PIN should be included to increase search space further • Goal: Economically unattractive to recover OTP before it expires • See Ref. [1].
314152 2. Authenticating to Multiple Servers with the Same OTP Token • Problem: How to authenticate to more than one server with the same OTP token OTP server1 OTP user server2 token
314152 One Approach: Shared Secrets • Share the OTP seed among the servers • But introduces multiple points of compromise OTP server1 OTP user server2 token
314152 Another Approach: Third-Party Server • Relay the request to a third party that stores the seed • But not suitable when a server is offline OTP server1 OTP user masterserver server2 token
314152 Yet Another Approach: Multi-Seeded Token • Store multiple seeds in the token, one for each server • Different OTP per server, but hard to add new ones • Requires user interface to select OTP1 server1 OTP2 user select server2 token
314152 New Approach: Seed Derivation • Derive server-specific seeds as a function of master seed • Easy to add new servers • Still, requires user interface to select seeds OTP1 (setup) server1 OTP2 user seeds master server derive select server2 token
Details • Server-specific seeds S1, S2, … derived from master seed S: S1 = H (S, ID1)S2 = H (S, ID2)… • Setup: Master server distributes server-specific seeds to servers • User provides server ID to token • Token derives server-specific seed, then generates OTP from it • Authentication process at server same as with regular seeds • See Ref. [2].
314152 3. Setting Up an Encryption Key • Problem: How to set up a strong, shared key, given only a short OTP user server 314152271828161803… token
314152 One Approach: Key Derivation • Derive a shared key from the shared OTP • But key is only as strong as the OTP (plus any slowdown) KA = H (OTPA) KB = H (OTPB) user server 314152271828161803… May need to repeat protocols for each server OTP that is acceptable at a given time token
314152 Another Approach: Password-Authenticated Key Establishment • Run a password-authenticated key establishment protocol • But might be too much computation after OTP entered in constrained environments (e.g., device pairing) OTPA PAKE OTPB KA KB user server 314152271828161803… token
314152 Yet Another Approach: Public-Key Agreement + OTP Hashing • Run a classic key agreement protocol (e.g., Diffie-Hellman), then confirm keys by hashing with OTPs • But may be vulnerable to MITM attack – assuming no certificates Key Agreement KA KB user server H (KA, OTPA) 314152271828161803… H (KB, OTPB) token
314152 New Approach: OTP-Based Key Confirmation • Run a classic key agreement protocol, then confirm keys by multiple rounds of bit commitment • Lightweight; just a lot of messages Key Agreement OTPA OTP-KC OTPB user server KA KB 314152271828161803… token
Details • Bit-wise confirmation via commitments: • User commits to i-th bit of OTP • Server commits to i-th bit • User decommits, server checks • Server decommits, user checks • Key is confirmed in the context of the commitment • Probability of forgery is 1/2 each round, so 2-k for a k-bit OTP • Adversary in DH MITM attack can gradually learn bits of OTP by pretending to be server, dropping protocol when incorrect • Lock-out policy can limit exposure
Details (cont’d) • Let OTP[i] denote the i-th bit of the OTP • User commits:Sends CA,i = H (KA, OTPA[i], RA,i), RA,i random • Server commits: Sends CB,i = H (KB, OTPB[i], RB,i), RB,i random • User decommits: Reveals RA,i • Server checks CA,i =? H (KB, OTPB[i], RA,i) • Server decommits: Reveals RB,i • Variant: Confirm messages from key establishment protocol instead of, or in addition to key • See Ref. [3] (aka “SHAKE”).
314152 4. Protecting Against Malware and MITM Attacks • Problem: How to protect OTPs against malware and MITM attacks OTP OTP $$ user server 314152271828161803… token
314152 One Approach: Server Certificates • Check server certificate before continuing • But phishers can get certificates too – or mimic them OTP X OTP X $$ X user server 314152271828161803… token
314152 Another Approach: Server OTP • Send next OTP back from server so user can check before continuing • Stops password phishers, but man is still in the middle! OTP OTP OTP’ OTP’ user server $$ 314152271828161803… token
314152 Yet Another Approach: Password-Authenticated Key Establishment • Run a password-authenticated key establishment protocol • But how do you know you’re really running it? “ ” OTPA PAKE OTPB $$ user server 314152271828161803… token
314152 New Approach: Trustworthy User Interface with Password Hashing • Invoke a more trustworthy user interface that hashes the OTP with requester’s ID before sending • MITM / malware won’t get anything useful expects H (OTP, IDserver) H (OTP, IDM) H (OTP, IDM) $$ X user server Hashing done by trustworthy interface 314152271828161803… token
Details • Password-protection model (PPM) with trustworthy user interface is invoked via Secure Attention Sequence (SAS) • e.g., CTRL-ALT-DEL • User enters OTP into PPM • PPM hashes OTP, requester ID to produce a protected OTP • POTPR = H (OTP, IDR) – H is a slow hash function • requester ID = URL, cert, and/or public key • PPM forwards POTP to requester • Adversary obtains POTPadversary, but needs POTPserver • Economically unattractive to recover OTP before it expires
Details (cont’d) • Mutual authentication extension: Server returns its own hash, PPM checks • Contemporaneous work: • Stanford University PwdHash automatically hashes passwords with requester ID, initially without SAS • Aaron Emigh proposal combines SAS, certificate check, encryption, initially without requester ID hash • RSA Laboratories, Stanford collaborating on OTP extensions to PwdHash • See Ref. [4].
One-Time Password Specifications (OTPS) • RSA Laboratories has developed multiple open specifications for integrating OTP technology into applications • Algorithm-independent: How OTPs are passed, not how they’re generated • One-Time Password Specifications (OTPS) process is an informal collaboration with experts • Visit http://www.rsasecurity.com/rsalabs/otps for documents, mailing list, etc. • 10 documents in series – several already submitted to standards bodies • Mostly oriented to “conventional” OTP, but some support for new applications described here (e.g., EAP-POTP)
Transport Validation Retrieval Provisioning Specifications and Integration Points (EAP-POTP, OTP-TLS,OTP-Kerberos) (OTP-WSS-Token, OTP-Validation Service) (OTP-PKCS#11, OTP-CAPI) Authentication Server (CT-KIP, CT-KIP-PKCS#11,1-pass and 2-pass CT-KIP)
Possible Research and Prototyping Activities • Trustworthy user interfaces for authentication • OTP-authenticated key establishment • Open-source implementation and applications of OTPS
Trustworthy User Interfaces for Authentication Research questions: • How can a trusted UI for authentication be deployed low enough in the O/S stack to prevent malware, yet still integrate with browser authentication? • Will users employ such an interface correctly, in the face of an attack? TIPPI Workshop at Stanford University addresses research in this area (http://crypto.stanford.edu/TIPPI)
OTP-Authenticated Key Establishment Research questions: • What is the formal model for OTP-authenticated key establishment? • Generalization of PAKE, where password can be revealed to adversary after protocol • How does the proposed protocol fare in that model – provably secure, or insecure? • Are there better protocols? This is a research topic of general interest
Open Source Implementation and Applications of OTPS Documents • One-Time Password Specifications (OTPS) documents are intended for broad industry adoption • Reference implementations are welcome • New applications based on these documents – e.g., mobile phone-based OTP – are encouraged RSA Laboratories will invite “best student projects” in this area to present at a future OTPS event
Contact Information • Burt KaliskiChief Scientist, RSA Laboratoriesburt@rsa.comhttp://www.rsasecurity.com/rsalabs/ • RSA is now The Security Division of EMC Corporation
References [1] DAUTH: Secure Offline Verification of One-Time Passwords. RSA Laboratories Technical Note, May 12, 2005. [2] System and Method for Authentication Seed Distribution. US Patent No. 6,985,583, January 10, 2006. [3] J.-O. Larsson. Higher Layer Key Exchange Techniques for Bluetooth Security. Open Group Conference, Amsterdam, October 2001. [4] Enhancing One-Time Passwords for Protection against Real-Time Phishing Attacks. RSA Laboratories Technical Note, January 16, 2006. • RSA Laboratories Technical notes are available via http://www.rsasecurity.com/rsalabs/node.asp?id=2002