Upload
christian-owen
View
215
Download
1
Embed Size (px)
Citation preview
Yvo Desmedt October 31, 2002
SECURITY PROBLEMS WITH ON-LINE REVOCATION
By Yvo Desmedt
Dept. Of Computer Science
Florida State University
http://www.cs.fsu.edu/~desmedt
and
Royal Holloway, Univ. of London, U.K.
Yvo Desmedt October 31, 2002
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
Yvo Desmedt October 31, 2002
1. Why on-line revocation
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)
Yvo Desmedt October 31, 2002
1. Why on-line revocation
a) history: consequences–viewed that a revocation would be an
exception–Off-line
So CRL (Certificate Revocation List) was a natural evolution and standard.
Yvo Desmedt October 31, 2002
1. Why on-line revocation
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.
Yvo Desmedt October 31, 2002
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
Yvo Desmedt October 31, 2002
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.
Yvo Desmedt October 31, 2002
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:
Yvo Desmedt October 31, 2002
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!
Yvo Desmedt October 31, 2002
1. Why on-line revocation c) Aggravation aspect Technology has changed:
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.)
Yvo Desmedt October 31, 2002
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:
Yvo Desmedt October 31, 2002
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
Yvo Desmedt October 31, 2002
1. Why on-line revocation Physical insecurity
• Now: Common problem:
–Could easily be Stolen
– Fall in the hands of the wrong guys
Yvo Desmedt October 31, 2002
1. Why on-line revocation c) Aggravation aspect Technology has changed:
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.
Yvo Desmedt October 31, 2002
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
Yvo Desmedt October 31, 2002
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
Yvo Desmedt October 31, 2002
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”.
Yvo Desmedt October 31, 2002
2. What is on-line revocation COST: requires: -) On-line access -) CA needs to sign more
Yvo Desmedt October 31, 2002
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
Yvo Desmedt October 31, 2002
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.
Yvo Desmedt October 31, 2002
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
Yvo Desmedt October 31, 2002
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.
Yvo Desmedt October 31, 2002
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!
Yvo Desmedt October 31, 2002
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?
Yvo Desmedt October 31, 2002
5. Security tools from a client's perspective
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.
Yvo Desmedt October 31, 2002
5. Security tools from a client's perspective
– 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):
Yvo Desmedt October 31, 2002
5. Security tools from a client's perspective
– 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.
Yvo Desmedt October 31, 2002
6. Security tools from a server's perspective
– Daniel-Rubin:
To deal with increased load, one needs to replicate the CA.
– Our solution: Servers should use threshold
cryptography.
Yvo Desmedt October 31, 2002
6. Security tools from a server's perspective
– 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)
Yvo Desmedt October 31, 2002
6. Security tools from a server's perspective
– 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.
Yvo Desmedt October 31, 2002
6. Security tools from a server's perspective
– 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!!!
Yvo Desmedt October 31, 2002
6. Security tools from a server's perspective
– 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!!!