Implementing EFECT Easy Fast Efficient Certification Technique

1. Implementing EFECTEasy Fast Efficient Certification Technique Ivan Nestlerode Bell Labs Lucent Technologies Based on EFECT paper by: Phil MacKenzie, Bell Labs, Lucent Technologies, Irene Gassko, Bell Labs, Lucent Technologies, and Peter S. Gemmell, University of New Mexico

2. Network Communication Listen to messages Modify messages Forge messages Man in the Middle can

3. Public Key Infrastructure (PKI) • Each party has an associated key pair: one public and one private • Private keys are not divulged • Public keys are published • Infrastructure enables both encryption and digital signatures (to thwart man in the middle) • Problem: public key spoofing by the man in the middle

4. PKI Bootstrapping Problem • A spoofed public key can render an otherwise secure communication insecure • Problem: need a way to guarantee that a public key actually belongs to a specific individual • Answer: trusted authorities who sign public keys

5. Certificate Authorities • Certificate - a digitally signed document binding an ID to a public key • Certificate Authority - a trusted third party who signs certificates • CA public key must be known to verify certificates • Certificate directory lists all ID’s and corresponding certificates

6. Problem of Certificate Revocation • Private keys may be stolen before a certificate expires • Digital signatures can’t be undone (on the certificate in question) • CA must issue a signed revocation statement, invalidating the certificate in question • CA must also issue a new signed certificate to the party in question

7. Existing Revocation Solutions • Existing solutions • X.509 Certificate Revocation Lists (CRL) • SDSI (online reconfirmation) • Valicert - Certificate Revocation Trees (CRT) • Notice: certificates are not very valuable in these schemes

8. EFECT Revocation Solution No revocation! • All certificates reissued each day • Infeasible with current schemes which have a signature on each certificate • Possible with EFECT because CA does one signature each day for all certificates • Use hashing instead of normal signing/verifying (10,000 times faster) • The trick is the data structure: Certificate Verification Tree (a Merkle tree)

9. Certificate Verification Tree Root (RV)= hash+info Signed by CA h7=h(h5,h6) h6=h(h3,h4) h5=h(h1,h2) h2=h(h(cert3),h(cert4)) h4=h(h(cert7),h(cert8)) h1=h(h(cert1),h(cert2)) h3=h(h(cert5),h(cert6)) cert1 cert2 cert3 cert4 cert5 cert6 cert7 cert8

10. EFECT for Credit Cards • One signature per day for CA • One signature verification per day per CA for vendor • Offline shopping using a smartcard (store hashes from the tree path; smaller than signatures) • Better security than current schemes and no online revocation checks

11. More EFECT Advantages • One signature allows better security (threshold signatures, larger keys, etc.) • Fewer signatures for cryptanalysis (one a day) • No isolated forgeries • Efficient recovery from compromise of CA keys • Archival storage • Atomic Certificates • Truly untrusted certificate directories

12. No Isolated Forgeries • In current schemes, isolated forgeries can go undetected • With EFECT, forgery is detectable by anyone using the system

13. Efficient Recovery from CA Key Compromise • Notify interested parties about compromise and supply new key out of band (NY Times) • Sign root hash of the day with the new key • Go drink coffee

14. Non-repudiation and Archival Storage • CA keys can become too short with time • CA keys can be stolen • Signature algorithms may eventually be broken Solution • Archive old roots and resign them with new keys • Keep path at signature time with the document • Directories archive old tree roots

15. Atomic Certificates • Users may not want each peer to see entire certificate • Suggested solution: Atomic Certificates (PKIX draft) • Problem: too many signatures with old schemes (smartcard constraint) • EFECT: one signature fits all

16. Truly Untrusted Directories • Current PKI schemes distribute certificate directories beyond the CA • Creates a trust problem • Directories may lie (bribery possible) • EFECT directories can prove non-existence of certificates, so we need not trust them

17. Implementing EFECT • Certificate Verification Tree • implemented the B+tree in C++ for maximum speed • used openSSL to overlay the hashes on the B+tree, creating a Merkle tree • Client Software • implemented a cross-platform GUI in Java • allows the user to get certificates from any networked directory and save/restore them to/from the local hard drive

18. Implementing EFECT • Certificate Directory Server • holds the CVT and allows clients to query for individual certificates • designed a simple query protocol (EQP) to be spoken between the client software and the directory server • implemented the Directory Server in C • speaks EQP over TCP connections • single threaded, but handles multiple simultaneous queries

19. Optimizing EFECT • Order of the B+tree (k) • determines the branching factor of the tree • determines the size of the certificate paths • determines the lookup speed • Math shows that smallest paths occur when k = 2 • Experimental trials show that queries are fastest when k = 4 • Some tradeoff between space and speed

20. EFECT Conclusions • EFECT allows one to obtain both a certificate and its validity simultaneously • Efficient recovery from CA key compromise • More protection for CA keys • Archiving and non-repudiation made easy • More certificates on a smartcard • Other useful properties