1.    Yvo Desmedt October 31, 2002 SECURITY PROBLEMS WITH ON-LINE REVOCATION By Yvo Desmedt Dept. Of Computer Science Florida State University desmedt@cs.fsu.edu http://www.cs.fsu.edu/~desmedt and Royal Holloway, Univ. of London, U.K.

2.    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

3.    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)

4.    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.

5.    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.

6.    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

7.    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.

8.    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:

9.    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!

10.    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.)

11.    Yvo Desmedt October 31, 2002 1. Why on-line revocation Physical insecurity Now: – Handheld/Handless devices – Laptops: » US State Dept.: stolen laptops with “code level” information » UK: MI5/MI6: stolen or lost laptops – Sensors:

12.    Yvo Desmedt October 31, 2002 1. Why on-line revocation Physical 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

13.    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

14.    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.

15.    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

16.    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

17.    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”.

18.    Yvo Desmedt October 31, 2002 2. What is on-line revocation COST: requires: -) On-line access -) CA needs to sign more

19.    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

20.    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.

21.    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

22.    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.

23.    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!

24.    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?

25.    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 bankrupt Solution: do not rely on single CA, indepedently proposed by Reiter- Stubblebine and Burmester-Desmedt- Kabatianskii.

26.    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):

27.    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.

28.    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.

29.    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)

30.    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.

31.    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!!!

32.    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!!!

33.    Yvo Desmedt October 31, 2002 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.