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. 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 314 152 OTP user server token 314 152 271 828 161 803 … OTPs can be a function of time, counter, and/or challenge

4. Four New Applications 1. How to authenticate to a laptop computer with an OTP token —without storing long-term secrets on the computer 2. How to use the same token to authenticate to multiple servers —without sharing secrets or relying on a third party 3. How to set up a strong, shared key between parties that only share a short OTP value 4. How to protect OTPs against malware and MITM attacks

5. 314 152 1. Authenticating to a Laptop with an OTP Problem: How to authenticate to a laptop computer with an OTP token X OTP user laptopserver token

6. 314 152 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. 314 152 (setup) OTPs 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 user laptop 314 152 271 828 161 803 … token server

8. 314 152 New Approach: Hashed OTP Values Download the hashes of OTP values to the laptop —Extra work to reverse hash deters attacker OTP user laptop (setup) H (OTP)s H (314 152) H (271 828) H (161 803) … token server

9. Details Setup: Laptop stores a range of hashed OTPs (with salts): H (OTP i, salt i ), salt i H (OTP i + 1, salt i + 1 ), salt i + 1 H (OTP i + 2, salt i + 2 ), salt i + 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. 314 152 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 user server 1 server 2 OTP token

11. 314 152 One Approach: Shared Secrets Share the OTP seed among the servers —But introduces multiple points of compromise OTP user server 1 server 2 OTP token

12. 314 152 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 user server 1 server 2 OTP master server token

13. 314 152 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 OTP 2 user server 1 server 2 OTP 1 select token

14. 314 152 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 OTP 2 user server 1 server 2 OTP 1 seeds (setup) seeds select derivederive token master server

15. Details Server-specific seeds S 1, S 2, … derived from master seed S: S 1 = H (S, ID 1 ) S 2 = H (S, ID 2 ) … 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. 314 152 3. Setting Up an Encryption Key Problem: How to set up a strong, shared key, given only a short OTP user server 314 152 271 828 161 803 … token

17. May need to repeat protocols for each server OTP that is acceptable at a given time 314 152 One Approach: Key Derivation Derive a shared key from the shared OTP —But key is only as strong as the OTP (plus any slowdown) user server 314 152 271 828 161 803 … K A = H (OTP A ) K B = H (OTP B ) token

18. 314 152 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) user server 314 152 271 828 161 803 … OTP A OTP B KAKA KBKB PAKE token

19. 314 152 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 user server 314 152 271 828 161 803 … KAKA KBKB Key Agreement H (K A, OTP A ) H (K B, OTP B ) token

20. 314 152 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 user server 314 152 271 828 161 803 … Key Agreement OTP-KCOTP A OTP B KAKA KBKB 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 C A,i = H (K A, OTP A [i], R A,i ), R A,i random Server commits: Sends C B,i = H (K B, OTP B [i], R B,i ), R B,i random User decommits: Reveals R A,i —Server checks C A,i =? H (K B, OTP B [i], R A,i ) Server decommits: Reveals R B,i Variant: Confirm messages from key establishment protocol instead of, or in addition to key See Ref. [3] (aka “SHAKE”).

23. 314 152 4. Protecting Against Malware and MITM Attacks Problem: How to protect OTPs against malware and MITM attacks user server 314 152 271 828 161 803 … token OTP $$

24. 314 152 One Approach: Server Certificates Check server certificate before continuing —But phishers can get certificates too – or mimic them user server 314 152 271 828 161 803 … token OTP $$ X X X

25. 314 152 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! user server 314 152 271 828 161 803 … token OTP OTP’ $$ OTP’

26. 314 152 OTP A OTP B PAKE Yet Another Approach: Password- Authenticated Key Establishment Run a password-authenticated key establishment protocol —But how do you know you’re really running it? user server 314 152 271 828 161 803 … token $$ “”

27. 314 152 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 user server 314 152 271 828 161 803 … token H (OTP, ID M ) $$ X expects H (OTP, ID server ) Hashing done by trustworthy interface

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 —POTP R = H (OTP, ID R ) – H is a slow hash function —requester ID = URL, cert, and/or public key PPM forwards POTP to requester Adversary obtains POTP adversary, but needs POTP server —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.http://www.rsasecurity.com/rsalabs/otps 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. Authentication Server Specifications and Integration Points Provisioning Retrieval Validation Transport (EAP-POTP, OTP-TLS, OTP-Kerberos) (OTP-WSS-Token, OTP-Validation Service) (CT-KIP, CT-KIP-PKCS#11, 1-pass and 2-pass CT-KIP) (OTP-PKCS#11, OTP-CAPI)

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: 1. 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? 2. 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: 1. What is the formal model for OTP-authenticated key establishment? —Generalization of PAKE, where password can be revealed to adversary after protocol 2. How does the proposed protocol fare in that model – provably secure, or insecure? 3. 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 Kaliski Chief Scientist, RSA Laboratories burt@rsa.com http://www.rsasecurity.com/rsalabs/ burt@rsa.com http://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 http://www.rsasecurity.com/rsalabs/node.asp?id=2002