Password Enabled Public-Key Infrastructure (PKI): Virtual Smartcards vs. Virtual Soft Tokens

1
Password Enabled Public-Key Infrastructure
(PKI)Virtual Smartcards vs. Virtual Soft
Tokens
Ravi Sandhu Chief Scientist SingleSignOn.Net Pro
fessor, George Mason University
Mihir Bellare Chief Cryptographer SingleSignOn.Net
Professor, Univ. of California--San Diego
Ravi Ganesan Chief Executive Officer SingleSignOn.
Net 11417 Sunset Hills Rd., Reston, VA 20190
2
Why Password-Enabled PKI

• Smartcards have not happened
• Its the smartcard readers stupid!
• Roaming capability is critical
• Even DoD is stretched in large-scale deployment
• Trends are not in favor of smartcards
• Deployment scale of 10s or even 100s of
  millions of users
• Computing devices are proliferating
• Large installed base of reader-less computers
• Smartcards are likely to remain a high-assurance
  niche application

3
Solve PKI Gap and Silo Problem

• Result
• Phased migration path
• No quantum jump
• PKI integral, not silod

Strong PKI Systems
PKI with Password Convenience
Password Usability PKI Capability
PKI Hardened Passwords
No change for users No change for
issuer Eliminate weaknesses
Weak Password Systems
4
A Common Misperception

• Fact Password based systems are often vulnerable
  to attacks
• Myth Passwords are inherently insecure.
• Fact It is completely possible to design a
  sufficiently secure password system.
• Designing sufficiently secure password-based
  systems is non-trivial but it is possible.

5
Another Common Misperception

• Fact Users hate current password systems that
  require
• too many passwords and
• force too many changes
• Myth Users inherently hate passwords.
• Fact It is completely possible to design a user
  friendly password system with PKI-enabled Single
  Sign On.
• Designing user-friendly and sufficiently secure
  password-enabled PKI systems is non-trivial but
  it is possible.

6
Password Vulnerabilities and Counter-Measures

• Bad password selection
• enforce complexity rules
• On-line guessing attack
• throttling mechanism
• Off-line guessing (dictionary attacks)
• dont reveal required information (we know how to
  design such protocols)
• Undetected theft and sharing
• online intrusion detection to discover
• deter sharing, e.g., sharing reveals sensitive
  user information
• Use of same password at strong and weak servers
• user awareness and education
• Password reuse
• dont force unnecessary password changes
• Server spoofing
• use secure protocols to prove knowledge of
  password w/o sending it
• limit password exposure to trusted servers
• Server compromise
• use hardened servers or multiple servers

7
Password Benefits

• Instant roaming capability
• Proven user acceptance
• 100s of millions of passwords usages per day in
  cyberspace
• Cheap
• Self-maintained
• Password resets
• Password change

8
Traditional Public-Key Infrastructure (PKI)

• How to distribute public-keys
• Digital Certificates
• Certificate Revocation Lists
• How to distribute private-keys (long-term)
• Smartcards
• The private key never leaves the smartcard
• Often called a hard token
• How to distribute private-keys (short-term)
• Password protected on the hard disk
• Not very mobile
• Password protected on a floppy disk
• Often called a soft token

9
Modern Public-Key Infrastructure (PKI)

• How to distribute public-keys
• Digital Certificates
• Certificate Revocation Lists
• On-line servers for certificate validation
• How to distribute private-keys (long-term)
• Smartcards
• The private key never leaves the smartcard
• Often called a hard token
• How to distribute private-keys (short-term)
• Password protected on the hard disk
• Not very mobile
• Password protected on a floppy disk
• Often called a soft token
• On-line servers for password-enabled mobility

10
Approaches

• How to marry PKI and Passwords?
• Approach 1 Virtual Soft Token
• Use password to encrypt private key and store it
  on remote server(s).
• Need password to RETREIVE private key.
• Approach 2 Virtual Smartcard
• The password is part of the composite private
  key.
• Need password to USE private key.

11
Trivial Insecure Virtual Soft Token

• Private key encrypted with users password is
  stored on an on-line server
• Epwd(private-key)
• Anyone is allowed to retrieve the encrypted
  private key
• Only the user can decrypt it using the password
• Unacceptable risk due to dictionary attack

12
Cryptographic Camouflage, Hoover and Kausik

• Epwd(private-key)
• Dictionary attack
• Knowledge of public key allows attacker to obtain
  known plaintext
• So prohibit knowledge of public key resulting in
  closed public-key system

13
EKE Roaming, Bellovin-Merritt et al

• Store Epwd(private-key) on server
• Transmit EK(Epwd(private-key)) where K is a
  strong symmetric key
• K is established using password-based
  authenticated key exchange protocol (such as EKE
  or SPEKE)
• Immune to off-line dictionary attack

14
Hardened Password Roaming, Kaliski-Ford

• Users hardened password is retrieved at any
  computer from two on-line servers
• Compromise of both servers is required to
  compromise hardened password
• Successful retrieval of hardened password
  requires knowledge of users password
• Users private key is retrieved by means of
  hardened password
• Once retrieved the users private key can be
  freely used on this computer

15
Step 8 Use H to decrypt private key D
16
Approaches

• How to marry PKI and Passwords?
• Approach 1 Virtual Soft Token
• Use password to encrypt private key and store it
  on remote server(s).
• Need password to RETREIVE private key.
• Approach 2 Virtual Smartcard
• The password is part of the composite private
  key.
• Need password to USE private key.

17
Trivial Insecure Virtual Smart Card

• Keep the private key on an on-line server
• Use the password as authentication to enable use
  of the private key on the server
• Lose non-repudiation

18
We want

1. Appliance takes

19
The Practical PKITM Approach

• Process
• Alice authenticates to appliance, sets up secure
  channel and sends M.
• Appliance performs partial signature on M with
  its key for Alice d2.
• Alice completes signature with her key d1.

20
Comparison

• Traditional PKI
• Keys
• Alice Public e
• Alice Private d
• Alice Cert C
• Signing
• a) S Sign (M,d)
• Send S, C to Bob
• Bob
• Gets e from C
• Does Verify(S,e) M?

• Practical PKITM
• Keys
• Alice Public e
• Alice PKCS5(password, salt, iteration count) d1
• Alice Cert C
• Alice appliance key d2
• Signing
• Alice logs on to appliance using d1 and creates
  secure channel
• Spartial Sign(M,d2)
• S Sign(Spartial,d1)
• Send S, C to Bob
• Bob
• Gets e from C
• Does Verify(S,e) M?

21
Comparison

• Traditional PKI
• Keys
• Alice Public e
• Alice Private d
• Alice Cert C
• Signing
• a) S Sign (M,d)
• Send S, C to Bob
• Bob
• Gets e from C
• Does Verify(S,e) M?

• Practical PKITM
• Keys
• Alice Public e
• Alice PKCS5(password, salt, iteration count) d1
• Alice Cert C
• Alice appliance key d2
• Signing
• Alice logs on to appliance using d1 and creates
  secure channel
• Spartial Sign(M,d2)
• S Sign(Spartial,d1)
• Send S, C to Bob
• Bob
• Gets e from C
• Does Verify(S,e) M?

22
Comparison

• Traditional PKI
• Keys
• Alice Public e
• Alice Private d
• Alice Cert C
• Signing
• a) S Sign (M,d)
• Send S, C to Bob
• Bob
• Gets e from C
• Does Verify(S,e) M?

• Practical PKITM
• Keys
• Alice Public e
• Alice PKCS5(password, salt, iteration count) d1
• Alice Cert C
• Alice appliance key d2
• Signing
• Alice logs on to appliance using d1 and creates
  secure channel
• Spartial Sign(M,d2)
• S Sign(Spartial,d1)
• Send S, C to Bob
• Bob
• Gets e from C
• Does Verify(S,e) M?

23
Strong Fraud Management
ID CANNOT BE USED ANY FURTHER! INSTANT, COMPLETE,
REVOCATION
24
Strong Fraud Management
ID CANNOT BE USED ANY FURTHER! INSTANT, COMPLETE,
REVOCATION
25
SingleSignOn.Net

• Practical PKITM solution
• Ease of use password based
• Quick to deploy
• Simple to manage with least privilege
• Velocity checking and instant revocation
• Reusable for multiple applications
• Web, Wireless, VPN, email, etc.
• Use existing standards and widely deployed
  technologies

26
Summary

• Password enabled solutions are poised to jump
  start the stalled PKI car.
• Major vendors jumping into password enabled
  solutions using on-line servers is a good sign.
• Many servers are not all good, and have
  quality/security downside.
• Making password a part of the composite private
  key (virtual smartcards) provides substantial
  advantages over using password to retrieve
  private key (virtual soft tokens).