SECURITY PROBLEMS WITH ON-LINE REVOCATION

1. 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. 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. 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. 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. 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. 1. Why on-line revocation b) CRL: conceptual problems • DELAY: • meanwhile fraud is possible. • Accumalatedfraud could be too high • SIZE: proportional in: • Number of revoked keys • Accumalated aspect

7. 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. 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. 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. 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. 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. 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. 1. Why on-line revocation Physical insecurity • Now: Common problem: • Could easily be Stolen • Fall in the hands of the wrong guys

14. 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. 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. 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. 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. 2. What is on-line revocation COST: requires: -) On-line access -) CA needs to sign more

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