Upload
georgia-duran
View
43
Download
1
Embed Size (px)
DESCRIPTION
Password Enabled Public-Key Infrastructure (PKI): Virtual Smartcards vs. Virtual Soft Tokens. Ravi Sandhu Chief Scientist SingleSignOn.Net & Professor, George Mason University. Mihir Bellare Chief Cryptographer SingleSignOn.Net & Professor, Univ. of California--San Diego. Ravi Ganesan - PowerPoint PPT Presentation
Citation preview
1
Ravi SandhuChief Scientist
SingleSignOn.Net&
Professor, George Mason University
Mihir BellareChief Cryptographer
SingleSignOn.Net&
Professor, Univ. of California--San Diego
Ravi GanesanChief Executive
OfficerSingleSignOn.Net
11417 Sunset Hills Rd., Reston, VA 20190
Password Enabled Public-Key Infrastructure (PKI):Virtual Smartcards vs. Virtual Soft Tokens
2
Why Password-Enabled PKI
• Smartcards have not happened– It’s 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 10’s or even 100’s 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
Weak Password Systems
Strong PKI Systems
PKI Hardened Passwords
PKI with Password
Convenience
Result
• Phased migration path
• No “quantum jump”
• PKI integral, not silo’d
Password Usability
PKI Capability
No change for users
No change for issuer
Eliminate weaknesses
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)– don’t 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– don’t 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
– 100’s 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 TokenUse 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 user’s password is stored on an on-line serverEpwd(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
• User’s “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 user’s password
• User’s private key is retrieved by means of “hardened password”
• Once retrieved the user’s private key can be freely used on this computer
15
Step 5: Ask for C
redentials
Long term private key is lockedwith ‘hardened password’ H.
Need duplicate credentials serverfor redundancy.
Credential Servers 1 & 2S
tep 6: C
heck if Cert
is revoked
OCSP server to check for revocation
Revocation Servers 1 & 2
Step 7: R
eturn C
ert an
d H (D
)
Step 8: Use H to decrypt
private key D
Step 2: Client Computer starts process
ClientComputer
Security server with partial knowledge of ‘H’ (H1). Need duplicate server
for redundancy.
Security Servers 1 & 2
Step 3: Get H
1
Security server with remaining knowledge of ‘H’ (H2). Need duplicate server
for redundancy.
Security Servers 3 & 4
Step
4: G
et H
2
Step 9: Finally get around to logonor sign operation!
Alice knows Password, Pa
Step 1: Alice sends Pa
16
Approaches
How to marry PKI and Passwords?
• Approach 1: Virtual Soft TokenUse 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:
2. Alice takes A
And creates A A
1. Appliance takes
And creates A
3. But (presto!)
A A A
ACC C
A
ID: Castle CorpFN: CastleLN: Corp..
19
The Practical PKITM Approach
Password
Secure Identity
Appliance
A
A• A Secure Identity Appliance has key d2 for Alice which ONLY it knows.
CA
CC C
A
ID: Castle CorpFN: CastleLN: Corp..
• As before, Alice has public cert, with public key e, signed by a CA.
Process1. Alice authenticates to appliance, sets up
secure channel and sends M.2. Appliance performs partial signature on M
with its key for Alice d2.3. Alice completes signature with her key d1.
• Alice has password P which ONLY she knows. Password P expands to key d1 on computer.
A
A
20
ComparisonTraditional PKI
Keys:a) Alice Public = eb) Alice Private = d
c) Alice Cert = C
Signing:a) S = Sign (M,d)
Send [S, C] to Bob
Bob:Gets e from CDoes Verify(S,e) = M?
Practical PKITM
Keys:a) Alice Public = eb) Alice PKCS5(password, salt,
iteration count) = d1c) Alice Cert = Cd) Alice appliance key = d2
Signing:a) Alice logs on to appliance using
d1 and creates secure channela) Spartial = Sign(M,d2)b) S = Sign(Spartial,d1)
Send [S, C] to Bob
Bob:Gets e from CDoes Verify(S,e) = M?
21
ComparisonTraditional PKI
Keys:a) Alice Public = eb) Alice Private = d
c) Alice Cert = C
Signing:a) S = Sign (M,d)
Send [S, C] to Bob
Bob:Gets e from CDoes Verify(S,e) = M?
Practical PKITM
Keys:a) Alice Public = eb) Alice PKCS5(password, salt,
iteration count) = d1c) Alice Cert = Cd) Alice appliance key = d2
Signing:a) Alice logs on to appliance using
d1 and creates secure channela) Spartial = Sign(M,d2)b) S = Sign(Spartial,d1)
Send [S, C] to Bob
Bob:Gets e from CDoes Verify(S,e) = M?
Difference #1: Alice has short convenient password
Difference #2: Alice has to interact with appliance to
sign.
22
ComparisonTraditional PKI
Keys:a) Alice Public = eb) Alice Private = d
c) Alice Cert = C
Signing:a) S = Sign (M,d)
Send [S, C] to Bob
Bob:Gets e from CDoes Verify(S,e) = M?
Practical PKITM
Keys:a) Alice Public = eb) Alice PKCS5(password, salt,
iteration count) = d1c) Alice Cert = Cd) Alice appliance key = d2
Signing:a) Alice logs on to appliance using
d1 and creates secure channela) Spartial = Sign(M,d2)b) S = Sign(Spartial,d1)
Send [S, C] to Bob
Bob:Gets e from CDoes Verify(S,e) = M?
NOTHING ELSE CHANGES!!!!
23
Strong Fraud Management
ID stolen
Theft detected
Theft reported
CA revokes ID
A
CA
ID: AliceFN: AliceLN: SmithEmail:[email protected] ..
CA
Recipient (we hope)stops accepting ID
Velocity Checking
Easy to report
ID CANNOT BE USED ANY FURTHER!INSTANT, COMPLETE, REVOCATION
24
Strong Fraud Management
ID stolen
Theft detected
Theft reported
CA revokes ID
A
CA
ID: AliceFN: AliceLN: SmithEmail:[email protected] ..
CA
Recipient (we hope)stops accepting ID
Velocity Checking
Easy to report
ID CANNOT BE USED ANY FURTHER!INSTANT, COMPLETE, REVOCATION
Consumer or CSR can use password to revoke instantly!
Every signature requires appliance interaction. So appliance logs can be used for velocity
checking.
Every signature requires appliance interaction. Once
revoked key cannot be used 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).