John Solis and Gene Tsudik University of California, Irvine

1

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

John Solis and Gene TsudikUniversity of California, Irvine


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:

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


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 AnalysisHides Target?

Certificates Returned

Bandwidth

CRL & Δ-CRLs Yes n O(n)

OCSP No 1 O(1)

Skip-Lists No 1 O(log n)

CRT No 1 O(log n)

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:

1. Range Queries

2. 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 Li 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


CRT Query● Client queries certificate with serial number i

● If Ci is not revoked, compose response:

1. Two adjacent leaf nodes Lp, Lp+1 st N(Lp) < i < N(Lp+1)

2. Three partial co-paths:

1. Lp to LCA

2. Lp+1 to LCA

3. LCA to Root

3. Signed root node (maybe cached by client)

13


CRT Query● If Ci is revoked, then response:

1. Two adjacent sibling nodes Lp, Lp+1 st N(Lp) = i or N(Lp+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


CRT Example-CRT query for L3

15



● CRTs amenable to include privacy


1. Range Queries


16


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


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

1

1

jk

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

n

mrSizeRange

*

19




1. Range Queries


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?

Documents

John Solis and Gene Tsudik University of California, Irvine