1 6 th Workshop on Privacy Enhancing Technologies, June 28-30, 2006 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 6 th Workshop on Privacy Enhancing Technologies, June 28-30, 2006 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 6 th Workshop on Privacy Enhancing Technologies, June 28-30, 2006 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: 1. Source of the revocation query 2. Target of the query – Goal: Construct a simple, efficient, and flexible privacy-preserving method for revocation checking

4 6 th Workshop on Privacy Enhancing Technologies, June 28-30, 2006 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 6 th Workshop on Privacy Enhancing Technologies, June 28-30, 2006 Explicit Revocation Methods ● CRLs and Δ-CRLs ● Online Certificate Status Protocol (OCSP) – Certificate Revocation Trees (to enhance OCSP) – Skip Lists and 2-3 trees

6 6 th Workshop on Privacy Enhancing Technologies, June 28-30, 2006 Privacy Analysis Hides Target? Certificates Returned Bandwidth CRL & Δ-CRLs YesnO(n) OCSPNo1O(1) Skip-ListsNo1O(log n) CRTNo1O(log n)

7 6 th Workshop on Privacy Enhancing Technologies, June 28-30, 2006 Question: ● Is there a practical technique to provide privacy for current revocation methods?

8 6 th Workshop on Privacy Enhancing Technologies, June 28-30, 2006 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 6 th Workshop on Privacy Enhancing Technologies, June 28-30, 2006 Privacy Preserving Revocation Checking ● CRTs amenable to supporting privacy-preserving querying ● Modify CRT structure: 1. Range Queries 2. Permuted Ordering

10 6 th Workshop on Privacy Enhancing Technologies, June 28-30, 2006 CRT Details : Notation ● n sequentially sorted revoked nodes – lo, hi - lowest and highest numbered nodes ● C i - certificate with serial number i ● L i …L m – Leaf nodes of CRT ● N(L i ) – Serial number of leaf node L i ● H() – cryptographic hash function ● co-path – sequence of nodes representing siblings of all direct ancestors ● LCA – Least common ancestor of two nodes

11 6 th Workshop on Privacy Enhancing Technologies, June 28-30, 2006 CRT Construction ● Each leaf node L i contains: – 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 6 th Workshop on Privacy Enhancing Technologies, June 28-30, 2006 CRT Query ● Client queries certificate with serial number i ● If C i is not revoked, compose response: 1. Two adjacent leaf nodes L p, L p+1 st N(L p ) < i < N(L p+1 ) 2. Three partial co-paths: 1. L p to LCA 2. L p+1 to LCA 3. LCA to Root 3. Signed root node (maybe cached by client)

13 6 th Workshop on Privacy Enhancing Technologies, June 28-30, 2006 CRT Query ● If C i is revoked, then response: 1. Two adjacent sibling nodes L p, L p+1 st N(L p ) = i or N(L p+1 ) = i 2. Co-path starting from sibling of parent node 3. Signed root node ● Clients verify response 1. Re-compute root hash using returned leaf nodes and co-paths 2. Verify signature on root node ● CRT inherently guarantees completeness

14 6 th Workshop on Privacy Enhancing Technologies, June 28-30, 2006 CRT Example -CRT query for L 3

15 6 th Workshop on Privacy Enhancing Technologies, June 28-30, 2006 Privacy Preserving Revocation Checking ● CRTs amenable to include privacy ● Modify CRT structure: 1. Range Queries 2. Permuted Ordering

16 6 th Workshop on Privacy Enhancing Technologies, June 28-30, 2006 Range Queries ● Observation: MOST Certificates ARE NOT revoked! ● Query for a range of certificates ● Range size determined by: 1. Desired degree of privacy 2. Density/number of revoked nodes

17 6 th Workshop on Privacy Enhancing Technologies, June 28-30, 2006 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 6 th Workshop on Privacy Enhancing Technologies, June 28-30, 2006 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 6 th Workshop on Privacy Enhancing Technologies, June 28-30, 2006 Privacy Preserving Revocation Checking ● Modify CRT structure: 1. Range Queries 2. Permuted Ordering

20 6 th Workshop on Privacy Enhancing Technologies, June 28-30, 2006 Permuted Ordering ● CAs issue certificates sequentially – Pros: ● Allows for defined subclasses ● Easier management – Cons: ● Consecutive blocks possibly related (information leak) ● Solution: Permuted ordering

21 6 th Workshop on Privacy Enhancing Technologies, June 28-30, 2006 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 6 th Workshop on Privacy Enhancing Technologies, June 28-30, 2006 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 6 th Workshop on Privacy Enhancing Technologies, June 28-30, 2006 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:

24 6 th Workshop on Privacy Enhancing Technologies, June 28-30, 2006 Questions?