Some New Applications of One-Time Passwords Burt Kaliski, RSA Laboratories October 2006
Jan 22, 2016
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 [email protected]://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