1 / 37

Some New Applications of One-Time Passwords

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.

dong
Download Presentation

Some New Applications of One-Time Passwords

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Some New Applications of One-Time Passwords Burt Kaliski, RSA Laboratories October 2006

  2. 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

  3. 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

  4. 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

  5. 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

  6. 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

  7. 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

  8. 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

  9. 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].

  10. 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

  11. 314152 One Approach: Shared Secrets • Share the OTP seed among the servers • But introduces multiple points of compromise OTP server1 OTP user server2 token

  12. 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

  13. 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

  14. 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

  15. 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].

  16. 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

  17. 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

  18. 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

  19. 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

  20. 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

  21. 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

  22. 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”).

  23. 314152 4. Protecting Against Malware and MITM Attacks • Problem: How to protect OTPs against malware and MITM attacks OTP OTP $$ user server 314152271828161803… token

  24. 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

  25. 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

  26. 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

  27. 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

  28. 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

  29. 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].

  30. 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)

  31. 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)

  32. Possible Research and Prototyping Activities • Trustworthy user interfaces for authentication • OTP-authenticated key establishment • Open-source implementation and applications of OTPS

  33. 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)

  34. 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

  35. 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

  36. Contact Information • Burt KaliskiChief Scientist, RSA Laboratoriesburt@rsa.comhttp://www.rsasecurity.com/rsalabs/ • RSA is now The Security Division of EMC Corporation

  37. 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

More Related