Implementing EFECT Easy 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

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

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

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

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

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

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

EFECT Revocation Solution 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) No revocation!

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

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

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

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

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

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

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

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

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

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

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

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