Title: Implementing EFECT Easy Fast Efficient Certification Technique
1Implementing 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
2Network Communication
Listen to messages Modify messages Forge messages
Man in the Middle
can
3Public 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
4PKI 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
5Certificate 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 IDs and
corresponding certificates
6Problem of Certificate Revocation
- Private keys may be stolen before a certificate
expires - Digital signatures cant 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
7Existing 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
8EFECT 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)
9Certificate Verification Tree
Root (RV) hashinfo
Signed by CA
h7h(h5,h6)
h6h(h3,h4)
h5h(h1,h2)
h2h(h(cert3),h(cert4))
h4h(h(cert7),h(cert8))
h1h(h(cert1),h(cert2))
h3h(h(cert5),h(cert6))
cert1
cert2
cert3
cert4
cert8
cert7
cert6
cert5
10EFECT 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
11More 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
12No Isolated Forgeries
- In current schemes, isolated forgeries can go
undetected - With EFECT, forgery is detectable by anyone using
the system
13Efficient 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
14Non-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
15Atomic 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
16Truly 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
17Implementing EFECT
- Certificate Verification Tree
- implemented the Btree in C for maximum speed
- used openSSL to overlay the hashes on the Btree,
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
18Implementing 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
19Optimizing EFECT
- Order of the Btree (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
20EFECT 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