Efficient Fault-Tolerant Certificate Revocation

1
Efficient Fault-Tolerant Certificate Revocation

• Rebecca Wright
• Patrick Lincoln
• Jonathan Millen

ATT Labs SRI International SRI International
2
Public Key Certificate Revocation

• Reasons for revocation
• Key compromise or loss
• Change of employment or status
• Revocation certificate or notice - single
• ID of invalid certificate
• Signed by owner or introducer
• Available in PGP for web of trust
• Certificate revocation list (CRL) - multiple
• List of serial numbers of revoked certificates
• Signed by CA that authorized the certificates
• Either one must be distributed to relying parties

3
Certificate Forwarding - Web of Trust
Owner
Owner
Certificate
Server
User
User
User
User
User
User
User
4
Depender Graph Model

• Graph nodes and directed edges
• One depender graph for each certificate
• Graph nodes are certificate holders
• Graph edges are communication links on which
  certificates are forwarded
• Owner of certificate is the graph root
• Graph is acyclic

edge
node
5
Parents and Dependers
A
A is a parent of B
B is a depender on A
B
6
Forwarding Revocation Notices
Owner
Revocation Notice
Server
User
?
?
?
?
First problem remember to whom the certificate
was sent
7
Non-Redundant Depender Graph
Owner
Revocation Notice
Server
User
User
User
User
User
User
User
- Just like forwarding graph - But what if a node
fails?
8
Temporary Failure
Owner
Revocation Notice
Server
User
User
User
User
User
User
- Some users are not notified - Solution
redundant paths
9
k-Redundant Depender Graph (k-RDG)
Owner
k parents per body node Example, k 2
ROOT NODE
Server
User
User
User
User
User
User
User
Theorem k -1 node failures cannot disconnect
any body node Flooding protocol send revocations
to all dependers
10
Depender Graph Construction

• Construct k-RDG by adding nodes one at a time,
  starting with root and its dependers
• Assume each new node can support k dependers
• More is possible but not required
• New node added in relation to existing node
• Nodes have neighbor addresses only
• k parents must be found... how?

11
Finding Parents

• Definition a node is available if its maximum
  number of dependers has not been allocated
• Theorem any k available nodes can be used as the
  parents of a new node
• (A poor choice cannot prevent future nodes from
  being added)
• Theorem there are k available nodes below any
  set of k nodes

12
Proof Existence of k Available Nodes

• Given start set of k nodes
• If each has an available slot, we are done
• Else one node has k dependers - use them as new
  start set recursively
• Procedure must terminate in finite acyclic graph

• This is the basis of a protocol for parent
  search
• Start set parents of attachment node
• Better use highest available nodes
• to minimize average path length for forwarding

13
Finding k Parents
1. Identify attachment node 2. Start with its
parents 3. Find available nodes below them
14
Example Triangular Graph
For k 3
15
Reconfiguration After Permanent Failure

• After permanent failures
• Neighbor (parent, depender) information in each
  node is duplicated in one parent (or child?)
• Role of failed node is taken over by one of
• last node added
• next node added
• a depender (recursive call to replace depender)
• But how is a failure detected?
• Unnecessary replacement is OK, restore node as new

16
Other Issues

• Protocol design issues
• Minimization of path length
• Updating revived nodes
• Reconfiguration around failed nodes
• Structure sharing over multiple certificates
• Multiple root (revocation) authority
• (in case of lost key, failure of owner, or higher
  authority)
• Realistic use of servers
• Edge failures
• Underlying network failures may disable many
  edges
• Other applications
• Certificate updates, re-keying, reliable multicast