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

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 token … OTPs can be a function of time, counter, and/or challenge

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

Authenticating to a Laptop with an OTP Problem: How to authenticate to a laptop computer with an OTP token X OTP user laptopserver token

One Approach: Embedded Server Embed the server in the laptop —But need trusted hardware to protect the long-term seed OTP user laptop token

(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 … token server

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 ( ) H ( ) H ( ) … token server

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

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

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

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

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

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

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

Setting Up an Encryption Key Problem: How to set up a strong, shared key, given only a short OTP user server … token

May need to repeat protocols for each server OTP that is acceptable at a given time 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 … K A = H (OTP A ) K B = H (OTP B ) token

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 … OTP A OTP B KAKA KBKB PAKE token

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 … KAKA KBKB Key Agreement H (K A, OTP A ) H (K B, OTP B ) token

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 … Key Agreement OTP-KCOTP A OTP B KAKA KBKB 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 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”).

Protecting Against Malware and MITM Attacks Problem: How to protect OTPs against malware and MITM attacks user server … token OTP $$

One Approach: Server Certificates Check server certificate before continuing —But phishers can get certificates too – or mimic them user server … token OTP $$ X X X

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 … token OTP OTP’ $$ OTP’

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 … token $$ “”

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 … token H (OTP, ID M ) $$ X expects H (OTP, ID server ) Hashing done by trustworthy interface

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

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

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)

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: 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 (

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

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 Kaliski Chief Scientist, RSA Laboratories 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, [2]System and Method for Authentication Seed Distribution. US Patent No. 6,985,583, January 10, [3]J.-O. Larsson. Higher Layer Key Exchange Techniques for Bluetooth Security. Open Group Conference, Amsterdam, October [4]Enhancing One-Time Passwords for Protection against Real- Time Phishing Attacks. RSA Laboratories Technical Note, January 16, RSA Laboratories Technical notes are available via