Carnegie Mellon
Title Goes Here
Toward Fixing the
Compliance Defects
of Public Key Cryptography
Mike Reiter
Professor of ECE and CS
Carnegie Mellon University
1
Compliance Defects in PKI
Carnegie Mellon
[Davis 1996]
Certification
Authority (CA)
Directory
Certificate
Public key
+
attributes
“tomato”
Compliance defect
Inability to verify the
CA’s public key.
Compliance defect
Inability to adequately
protect the private key.
Public key
Local Registration
Authority (LRA)

Compliance defect: “a rule of operation that is difficult to
follow and that cannot be enforced”
2
Carnegie Mellon
Compliance Defects as a User Interface Issue

Users have neither

The patience to verify a large string of hex digits
0x4CA682F9D910BF7343B29C502A15F5D8
versus
0x4CA682F9D910BF7843B28C502A15F5D8

The capacity to remember strong cryptographic keys
0x4CA682F9D910BF7343B29C502A15F5D8

Problem gets worse with longer keys and hashes
3
Carnegie Mellon
Keeping it in Perspective

Compliance defects are not unique to PKI



Surety’s digital notary service relies on users to compare a hash
published in the New York Times to a computed one
File encryption poses similar challenges as protecting a private key
does
These compliance defects are not the only user interface
problem for cryptographic (or security) systems [Kent 1997;
Whitten & Tygar 1999; …]
4
Carnegie Mellon
How to Fix Compliance Defects

Remember, a compliance defect is:
“A rule of operation that is
difficult to follow  cannot be enforced”

To fix a compliance defect, one conjunct must be negated

That is, either


Improve the user interface
Impose an enforcement mechanism
5
Carnegie Mellon
Imposing an Enforcement Mechanism

Protecting the private key




Give the user her private key on
a PIN-activated smartcard
Choose the password for the user
Force the user to choose a
stronger password (e.g.,
proactive password checking)
Changes the user
interface for the worse,
e.g., [Bishop 1991]
Verifying the root’s public key

Somehow do it for the user (a la
Firefox and IE)
Difficult to do well at the
scale of the Internet
6
Carnegie Mellon
Improving the User Interface
Make the user interface more pleasant …
 Pleasant  graphical
 Pictures are easier to remember than words
 Some cognitive theories:


Pictures share fewer common perceptual features and so must be
discriminated from a smaller set of possible alternatives
Human brain has separate verbal and non-verbal memories
 Recognizing a face but not the person’s name
 Recognizing a melody but not its name
… Or keep the same interface but make it more effective
7
Snowflakes
Carnegie Mellon
[Levien 1996]

A graphical approach to displaying hash outputs

Computed in < 200 lines of C
8
Random Art
Carnegie Mellon
[Bauer 1998; Perrig & Song 1999]

Another approach to visualizing hash outputs


Hash value used as seed to generate a function f: [1,1]2  [1,1]3
f(x, y) is the RGB triple for pixel at (x, y)
9
Carnegie Mellon
Random Art: How it Works

Function f is generated from a grammar that permits coin flips

All coin flips generated pseudorandomly from seed
f x, y  :: Cx, y , Cx, y , Cx, y 
 Ax, y  with probabilit y 1/4

C x, y  ::  ( x  y ) / 2 with probabilit y 3/8
 xy
with probabilit y 3/8


Grammar can include
other functions, e.g.,



c  R  1,1 with probabilit y 1/3

Ax, y  :: 
x
with probabilit y 1/3

y
with probabilit y 1/3


sin
cos
exp
square root
10
Carnegie Mellon
Graphical Passwords
[Blonder 1996; Jermyn et al. 1998]


Suitable mainly for PDAs permitting stylus input
Useful for encrypting private key, or seeding its generation
pen-up
Sequence = (2,2)(3,2),(3,3),(2,3),(2,2),(2,1),(5,5)
Key = hash(Sequence)
11
Carnegie Mellon
Security of Graphical Passwords

How might one argue that graphical passwords are more
secure than text ones?


Show that number of memorable graphical passwords exceeds
number of memorable text passwords
How does one quantify the memorable graphical passwords?
Hypothesis
A memorable password is one for which there exists a short
algorithm to generate it.
12
Carnegie Mellon
“Complexity” of a Graphical Password
Grammar
Program : Digit Digit Block

Block
: Stmt Block
Stmt
: Instr | Repeat Digit Block End
Instr
: Up | Down | Right | Left |
Penup | Pendown
Digit
:1|2|3|4|5
Complexity = length of shortest
program that generates the password
11
repeat 2
pendown
down
right
up
penup
left
repeat 3
down
end
pendown
down
right
up
penup
repeat 3
up
end
right
end
pendown
repeat 4
down
end
penup
Complexity = 26
13
Carnegie Mellon
Memorable Password Space
Comp.
Comp = 24
Comp = 39
Comp = 42
3
4
5
6
7
8
9
10
11
12
Passwords
25
165
398
1,645
7,370
34,026
165,760
614,660
2,279,241
Surpasses size of the dictionary
used in [Klein 1990].
14
Carnegie Mellon
Encryption Application for Palm Pilot
Plaintext
Password input
Internal representation
Internal representation
Password input
15
Carnegie Mellon
The Challenge of Graphical Schemes

How secure are they, really?

Can an attacker generate a key for which the snowflake or art
depiction fools someone with non-negligible probability?

Depends on lighting, size of representation, printer quality, …

Is the entropy of a graphical password really better than a text
password?

Only user studies will tell …
16
Carnegie Mellon
Making the Old Interface More Effective

Mainly applies to private key protection

Less so for root key validation

“Old interface” = password

“Making it more effective” = making dictionary attacks harder

Two approaches we will discuss here


Use the network
Use the user
17
Carnegie Mellon
Using the Network
[Lomas et al. 1989; Bellovin & Merritt 1992; …; Perlman & Kaufman 1999]

Store private key in a protected server that authenticates user
before sending the private key
“tomato”
Use “tomato” to set up
strong encryption key


User:Bob
Pwd :tomato
Key :
Eavesdropper gains nothing to use in offline dictionary attack
Forces dictionary attacks to occur online


Server
Server can detect and stop them
But … break-in at server leaks private key

Possibly after an offline dictionary attack
18
Carnegie Mellon
Reducing Trust in the Server
[MacKenzie & Reiter 2001]

Keep the key at the client, but in a disabled state
“tomato”


Server confirms that
current user = user who
initialized device
Server
Break-in at server leaks nothing
Online dictionary attack possible only after device is captured


Server can again detect and stop the attack
Offline attack requires capture of both client device and server
19
Carnegie Mellon
Reducing Trust in the Client
[MacKenzie & Reiter 2001; Boneh et al. 2001; c.f., Ganesan 1985]

Can disable the device if stolen

Even if attacker knows the user’s password
“tomato”
Server confirms that
current user = user who
initialized device
Server
p  start(
s  finish(


, p, m)
, m)
p
Same properties as before, plus disabling
Known techniques depend on particular form of private key

All use function sharing primitives
20
Carnegie Mellon
Server Delegation

Delegation enables use of local server

Or a smartcard for “offline” operation
(2)
(1)
(3)

(4)
Device can unilaterally revoke delegated servers
21
Carnegie Mellon
Using the User
[Soutar et al. 1996; Davida et al. 1998; Juels & Wattenberg 1999;
Monrose et al. 1999; …]

Use biometric features during entry of a password to
construct a hardened password


Hardened password useful for key encryption
Portables not equipped with hardware for most biometric
techniques, but do typically have
a microphone
a keyboard
or
22
Carnegie Mellon
Initialization
(3) Arrange in a
2-column table
(1) Choose hardened password
(2) Break it into “shares”
(4) Encrypt with text password
23
Carnegie Mellon
Reconstructing the Hardened Password


Table decrypted using entered
password
Biometric features induce “cut”
through table


Hardened
password
One element per row is selected
Selected elements used to reconstruct
hardened password
24
Carnegie Mellon
Hardening the Hardened Password
Repeated
logins



System “learns” user’s biometric
features over repeated logins
Pieces not used by correct user are
destroyed
Enhances protection even against
imposter who knows the password
Imposter
25
Carnegie Mellon
Dictionary Attacks

For each incorrect password guess,
decrypted table is random

For the correct password guess,
decrypted table is correct one
attack slowdown factor  time to tell these apart
26
Carnegie Mellon
Keystroke Experiments
20 users
100
90
80
70
60
50
40
30
20
10
0
35
30
% False Negatives
% of Max Guessing
Entropy
20 users
2 errors corrected
25
3 errors corrected
20
15
10
5
0.1 0.15 0.2 0.25 0.3 0.35 0.4 0.45 0.5 0.55 0.6 0.65
k
Guessing Entropy
0
0.1 0.15 0.2 0.25 0.3 0.35 0.4 0.45 0.5 0.55 0.6 0.65
k
False Negative Rate
481 recorded logins from 20 users typing the same 8-character
password. 15 features.
27