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

314 152

OTP

userserver

token

314 152271 828161 803

…

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

314 152

1. Authenticating to a Laptop with an OTP

• Problem: How to authenticate to a laptop computer with an OTP token

XOTP

userlaptop server

token

314 152

One Approach: Embedded Server

• Embed the server in the laptop

— But need trusted hardware to protect the long-term seed

OTP

userlaptop

token

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

userlaptop

314 152271 828161 803

…

token

server

314 152

New Approach: Hashed OTP Values

• Download the hashes of OTP values to the laptop

— Extra work to reverse hash deters attacker

OTP

userlaptop

(setup)

H (OTP)sH (314 152)H (271 828)H (161 803)

…

token

server

Details

• Setup: Laptop stores a range of hashed OTPs (with salts):

H (OTPi, salti), salti

H (OTPi + 1, salti + 1), salti + 1

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

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

OTPuserserver1

server2

OTP

token

314 152

One Approach: Shared Secrets

• Share the OTP seed among the servers

— But introduces multiple points of compromise

OTPuserserver1

server2

OTP

token

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

OTPuserserver1

server2

OTP

masterserver

token

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

OTP2user

server1

server2

OTP1

select

token

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

OTP2user

server1

server2

OTP1seeds(setup)

seeds

select

derive

token

master server

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

314 152

3. Setting Up an Encryption Key

• Problem: How to set up a strong, shared key, given only a short OTP

userserver

314 152271 828161 803

…

token

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)

userserver

314 152271 828161 803

…

KA = H (OTPA)

KB = H (OTPB)

token

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)

userserver

314 152271 828161 803

…

OTPA OTPB

KA KB

PAKE

token

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

userserver

314 152271 828161 803

…

KA KB

Key Agreement

H (KA, OTPA)

H (KB, OTPB)

token

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

userserver

314 152271 828161 803

…

Key Agreement

OTP-KCOTPA OTPB

KA KB

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

314 152

4. Protecting Against Malware and MITM Attacks

• Problem: How to protect OTPs against malware and MITM attacks

userserver

314 152271 828161 803

…

token

OTP OTP

$$

314 152

One Approach: Server Certificates

• Check server certificate before continuing

— But phishers can get certificates too – or mimic them

userserver

314 152271 828161 803

…

token

OTP OTP

$$

XX

X

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!

userserver

314 152271 828161 803

…

token

OTP OTP

OTP’

$$

OTP’

314 152

OTPA OTPBPAKE

Yet Another Approach: Password-Authenticated Key Establishment

• Run a password-authenticated key establishment protocol

— But how do you know you’re really running it?

userserver

314 152271 828161 803

…

token

$$

“ ”

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

userserver

314 152271 828161 803

…

token

H (OTP, IDM) H (OTP, ID

M)

$$ X

expects H (OTP, IDserver)

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

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

AuthenticationServer

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 (http://crypto.stanford.edu/TIPPI)

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