John Solis and Gene Tsudik University of California, Irvine

1. John Solis and Gene Tsudik University of California, Irvine 6th Workshop on Privacy Enhancing Technologies, June 28-30, 2006 Simple and Flexible Revocation Checking with Privacy

2. Digital Certificates • PK Certificate • Binds public key to identity-string (name) • Signed by issuer (CA) • Valid from XXXX, Expires on YYYY • Premature revocation: • Private key loss/compromise • Algorithm weakness • Subject becomes malicious • Change in security policy • Job change/Promotions

3. Revocation Checking Issues • Validate certificates prior to communication: • Verify signature(s) • Check revocation status (each time, even if cached) • Implies subsequent communication • Privacy leak – third parties find out about: • Source of the revocation query • Target of the query • Goal: Construct a simple, efficient, and flexible privacy-preserving method for revocation checking

4. Revocation Classes • Implicit • Certificate owner supplies proof of non-revocation, e.g., CRS • Explicit • CA issues (signed) data structure containing revocation information, e.g., CRL

5. Explicit Revocation Methods • CRLs and Δ-CRLs • Online Certificate Status Protocol (OCSP) • Certificate Revocation Trees (to enhance OCSP) • Skip Lists and 2-3 trees

6. Privacy Analysis

7. Question: • Is there a practical technique to provide privacy for current revocation methods?

8. Related Work • H. Kikuchi “Privacy-preserving revocation check in pki” • Identifies problem • Proposed heavy-weight (inefficient) cryptographic technique • Private Information Retrieval (PIR) • Obscures targets of database queries • Multi-round protocols/Expensive crypto • Overkill

9. Privacy Preserving Revocation Checking • CRTs amenable to supporting privacy-preserving querying • Modify CRT structure: • Range Queries • Permuted Ordering

10. CRT Details : Notation • n sequentially sorted revoked nodes • lo,hi - lowest and highest numbered nodes • Ci - certificate with serial number i • Li…Lm– Leaf nodes of CRT • N(Li ) – Serial number of leaf node Li • H() – cryptographic hash function • co-path – sequence of nodes representing siblings of all direct ancestors • LCA – Least common ancestor of two nodes

11. CRT Construction • Each leaf node Licontains: • Certificate hash • Date/time of revocation • Reason for revocation • Each non leaf node computed as hash of child nodes • H(parent) = H(L||R) • CA digital signs root node and distributes

12. CRT Query • Client queries certificate with serial number i • If Ci is not revoked, compose response: • Two adjacent leaf nodes Lp, Lp+1 st N(Lp) < i < N(Lp+1) • Three partial co-paths: • Lp to LCA • Lp+1 to LCA • LCA to Root • Signed root node (maybe cached by client)

13. CRT Query • If Ci is revoked, then response: • Two adjacent sibling nodes Lp, Lp+1 st N(Lp) = i or N(Lp+1) = i • Co-path starting from sibling of parent node • Signed root node • Clients verify response • Re-compute root hash using returned leaf nodes and co-paths • Verify signature on root node • CRT inherently guarantees completeness

14. CRT Example -CRT query for L3

15. Privacy Preserving Revocation Checking • CRTs amenable to include privacy • Modify CRT structure: • Range Queries • Permuted Ordering

16. Range Queries • Observation: MOST Certificates ARE NOT revoked! • Query for a range of certificates • Range size determined by: • Desired degree of privacy • Density/number of revoked nodes

17. Range Queries • Query for a range of (permuted) certificate serial numbers (j,k) st j ≤ i ≤ k • Hide target certificate in range • Pr[Correctly guessing i] = • Statistical privacy • Range size determines privacy level • Highest level => size = n (CRL) • Lowest level => size = 1 (Existing solutions) • Flexible => Let client decide: trade-off privacy/bandwidth

18. Optimal Range Size • Inputs: • Desired privacy level • e.g. – If Pr[guessing] = .001 then k-j+1 = 1000 • Revocation density • Not all certificates in range returned • To have r certificates returned

19. Privacy Preserving Revocation Checking • Modify CRT structure: • Range Queries • Permuted Ordering

20. Permuted Ordering • CAs issue certificates sequentially • Pros: • Allows for defined subclasses • Easier management • Cons: • Consecutive blocks possibly related (information leak) • Solution: Permuted ordering

21. Permuted Ordering • Certificates not revoked uniformly • Different ranges could have dramatically different densities • Solution: Use PRP to guarantee uniform distribution • No collisions • Uniform distribution • Sort certificates along permuted serial numbers • Ex: DES, Blowfish, RC4

22. Some issues • Repeated queries for same target by same client • Change range or keep same? • Better keep same range • Multiple queries for same target by different clients • Ideally would have same range • How? • Intersection (narrowing) attack possible… if adversary aware of target being same (e.g., temporal proximity)

23. Conclusions • Proposed solution is a simple/novel approach that addresses privacy concerns in revocation checking • Configurable levels of privacy on a per-query basis • Bandwidth vs Privacy • Can be applied to other revocation methods • Skip-Lists (Appendix) • CRLs (paper in preparation) • Prototype available at: http://sconce.ics.uci.edu/ppr

24. Questions?