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

Presentation Transcript

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

Chief Executive

Officer

SingleSignOn.Net

11417 Sunset Hills Rd., Reston, VA 20190

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

Solve PKI Gap and Silo Problem

Result
Phased migration path
No “quantum jump”
PKI integral, not silo’d

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

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.

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.

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

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

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

“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

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.

Trivial Insecure Virtual Soft Token

Private key encrypted with user’s 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

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

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

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

Credential Servers 1 & 2

Alice knows Password,Pa

Step 5: Ask for Credentials

Step 1: Alice sends Pa

Long term private key is locked

with ‘hardened password’ H.

Need duplicate credentials server

for redundancy.

Client

Computer

Step 2: Client Computer starts process

Step 6: Check if Cert

is revoked

Step 7: Return Cert and H (D)

Step 3: Get H1

Security Servers 1 & 2

Step 4: GetH2

Step 9: Finally get around to logon

or sign operation!

Revocation Servers 1 & 2

Security server with partial knowledge

of ‘H’ (H1). Need duplicate server

for redundancy.

Security Servers 3 & 4

OCSP server to check for revocation

Security server with remaining knowledge

of ‘H’ (H2). Need duplicate server

for redundancy.

Step 8: UseH to decrypt

private key D

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.

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

M

A

M

And creates

A

ID: Castle Corp

FN: Castle

LN: Corp

.

Alice takes

M

And creates

CC

But (presto!)

!!!

M

CA

M

=

A

We want:

Appliance takes

Password

M

Alice has password P which ONLY she knows. Password P expands to key d1 on computer.

CA

A

ID: Castle Corp

FN: Castle

LN: Corp

.

A Secure Identity Appliance has key d2 for Alice which ONLY it knows.

As before, Alice has public cert, with public key e, signed by a CA.

CC

CA

A

Secure Identity Appliance

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.

Comparison

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?

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

Difference #1: Alice has short convenient password

Difference #2: Alice has to interact with appliance to sign.

Comparison

Practical PKITM
Keys:

Alice Public = e
Alice Cert = C

Signing:

Send [S, C] to Bob
Bob:

Gets e from C

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

NOTHING ELSE CHANGES!!!!

Comparison

Practical PKITM
Keys:

Alice Public = e
Alice Cert = C

Signing:

Send [S, C] to Bob
Bob:

Gets e from C

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

A

Velocity

Checking

Easy

to report

ID: Alice

FN: Alice

LN: Smith

Email:alice@cc.com

.

CA

ID

stolen

Theft

detected

Theft

reported

CA revokes

ID

Recipient (we hope)

stops accepting ID

Strong Fraud Management

ID CANNOT BE USED ANY FURTHER!

INSTANT, COMPLETE, REVOCATION

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!

Consumer or CSR can use password to revoke instantly!

A

Velocity

Checking

Easy

to report

ID: Alice

FN: Alice

LN: Smith

Email:alice@cc.com

.

CA

ID

stolen

Theft

detected

Theft

reported

CA revokes

ID

Recipient (we hope)

stops accepting ID

Strong Fraud Management

ID CANNOT BE USED ANY FURTHER!

INSTANT, COMPLETE, REVOCATION

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

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