Yvo Desmedt October 31, 2002 SECURITY PROBLEMS WITH ON-LINE REVOCATION By Yvo Desmedt Dept. Of Computer Science Florida State University [email protected]

Yvo Desmedt October 31, 2002

SECURITY PROBLEMS WITH ON-LINE REVOCATION

By Yvo Desmedt

Dept. Of Computer Science

Florida State University

[email protected]

http://www.cs.fsu.edu/~desmedt

and

Royal Holloway, Univ. of London, U.K.


Overview

1. Why on-line revocation

2. What is on-line revocation

3. Learning from ATM/POS

4. Security problems

5. Security tools from a client's perspective

6. Security tools from a server's perspective

7. Conclusion



a) history

basis of X500/X509 predates internet, when:

- physical security was much higher:

» Few computers

»security guards

»Vaults

- communication was expensive, in particular on-line (uucp)



a) history: consequences–viewed that a revocation would be an

exception–Off-line

So CRL (Certificate Revocation List) was a natural evolution and standard.



b) CRL: implementation problems–Some CAs do not publish CRLs, worse –Many implementations do not use them

Anderson-type conclusion: since it works without, there is no need for CRL.

Answer: see later.


1. Why on-line revocation b) CRL: conceptual problems

–DELAY:

•meanwhile fraud is possible.

• Accumalated fraud could be too high–SIZE: proportional in:

•Number of revoked keys

•Accumalated aspect


1. Why on-line revocation b) CRL: conceptual problems

–DELAY–SIZE(Daniel-Rubin: still no reason for on-line

revocation: could publish very frequently CRL.)

Answer: see later.


1. Why on-line revocation c) Aggravation aspect Technology has changed since first effort on

X500/X509:

CPU was slow and Public Key technology requires many operations: viewed that special hardware was required.

Today most have been implemented in software.

Implications:


1. Why on-line revocation c) Aggravation aspect Technology has changed:

Implications:

–Computer insecurity:• Then: No computer viruses/worms,

Now: there are! Example of problem: www of US State Dept.

• Then: Operating System security was taken seriously Now: it is mainly advertisement!



Implications:

– Hardware insecurity Then: Chip-cards and dedicated hardware

believed to be significantly more secure than software

Now: Many attacks are known (see CHES, PKC 2003, etc.)


1. Why on-line revocationPhysical insecurity

Now:

–Handheld/Handless devices

–Laptops:

»US State Dept.: stolen laptops with “code level” information

»UK: MI5/MI6: stolen or lost laptops

– Sensors:


1. Why on-line revocationPhysical insecurity

• Now: Sensors:

–Inexpensive: massive number

–Example of use:

»Eco-disaster,

»Hostage taking

»Explore adversial situtation

–Use wireless technology

–Need to authenticate

– Could fall in the hands of bad guys


1. Why on-line revocation Physical insecurity

• Now: Common problem:

–Could easily be Stolen

– Fall in the hands of the wrong guys



Implications:

–Key of device, not of user Then: Users would have public keys Now: Devices, or applications (ssh) have

public keys (new machine, old name). Implies: User does not regard key as

his/her and does not take precautions.


1. Why on-line revocation c) Aggravation aspect

– Key of device, not of user Implies:

•If device belongs to third party (rented: e.g. cell phone or employer), at the end of the contract public key should be changed: increasing revocations


1. Why on-line revocation c) Aggravation aspect: conclusion Technology has changed:

Implications:

Future applications of Public Key: -) Secret keys are much more vulnerable,

and -) There will be an increased need for

revocation -) Depending on application (non-financial),

delay may be unacceptable


2. What is on-line revocation Instead of having a blacklist (CRL) one checks on-line whether a certificate

is still valid (see e.g. Rivest FC 98).

Basic use: no lifetime of validity.

Instead: only the time the certificate was issued is part of the signed “message”.


2. What is on-line revocation COST: requires: -) On-line access -) CA needs to sign more


3. Learning from ATM/POS Daniel-Rubin vs. Rivest: -) black or white -) real world is not black or white

ATM/POS history-) in 1970-1980's debate was online or

offline revocation of credit/debit cards -) Offline: * POS: booklet !! * ATM: daily floppy


3. Learning from ATM/POS ATM/POS history -) debate: * Online: +: less delay

-: what if line goes dead: do/do not provide

-) Offline: viewed as more reliable! -) Fraud became too big to fit in a

booklet and online: won. Extra cost not that high.


3. Learning from ATM/POS ATM/POS history -) online: what if the line is dead?? * Depends on size of transaction, so

not black or white

ATM/POS lesson: -) Not black or white -) Need for online: depends on

accumulated fraud risk: not necessarily financial: e.g. Bosnia


3. Learning from ATM/POS

– The more PKI becomes important and the more frequently important Public Keys are hacked, the more online will dominate!

–Currently Anderson-type arguments are close to correct! Future will change once PKI takes off.


4. Security problems Being on-line and when PKI becomes

truly important , CAs will become the “next target of hackers.”

On-line aspects seriously aggravates the issue!

•CAs capability of signing is now on-line, making the secret key vulnerable!


4. Security problems Two viewpoints:

– Client: (Rivest: takes the risk: often false!!) How can the client deal with CAs taken over by an enemy?

– Server: To maintain credibility (future: to reduce liability): How can the server deal with hacking of the secret key?



Client should not rely on trusting a vulnerable CA since CAs:

– Today: are not responsible!

– Future: may go bankruptSolution: do not rely on single CA,indepedently proposed by Reiter-

Stubblebine and Burmester-Desmedt-Kabatianskii.



– Solution: similar to PGP: trust graph of certificates. However, we require that the trust graph is 2k+1 connected. If (at most) k “CA”s have been hacked:

majority vote solves issue.

–Alternative Solution: see IWAP 2000 (to appear Communications of ACM):



– Alternative Solution: see IWAP 2001 (to appear Communications of ACM):

Gave nodes using same operating system different colors. Enemy can take over k colors: many more nodes may be affected.



– Daniel-Rubin:

To deal with increased load, one needs to replicate the CA.

– Our solution: Servers should use threshold

cryptography.



– What is threshold cryptography:

n servers have share of the secret, of which k are needed to co-sign.

note: (if n>1) no server ever sees secret key and k-1 cannot sign (if underlying

signature scheme is secure)



– Compare with Daniel-Rubin:

replicate, however use it to increase security (provided k>1)!

–Why can this not deal with client security issues?

Threshold Cryptography is too transparent. What comes out is a signature as coming out from a single entity.



– Why can this not deal with client security issues?

Moreover co-signing can be simulated. Note: robust variant may achieve the

goal if one trust these are independent!!!



– Why can this not deal with client security issues?

Moreover co-signing can be simulated. Note: robust variant may achieve the

goal if one trust these are independent!!!


7. Conclusion

– On-line revocation: to keep in mind once public key is heavily used and relied on.

–ATM/POS: learn from history.

– Security issue: much more severe issue

– Client/Server: Different goals, different interests, so need for different approaches.

Documents

Yvo Desmedt October 31, 2002 SECURITY PROBLEMS WITH ON-LINE REVOCATION By Yvo Desmedt Dept. Of Computer Science Florida State University [email protected]