Efficient Fault-Tolerant Certificate Revocation Rebecca Wright AT&T Labs Patrick Lincoln SRI International Jonathan Millen SRI International
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
Certificate Forwarding - Web of Trust Owner User Certificate Server User User
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 edge Graph is acyclic node
Parents and Dependers A B A is a parent of B B is a depender on A
Forwarding Revocation Notices Revocation Notice Owner ? Server ? User ? ? First problem: remember to whom the certificate was sent
Non-Redundant Depender Graph Owner User Revocation Notice Server User - Just like forwarding graph - But what if a node fails? User
Temporary Failure Owner User Revocation Notice Server User - Some users are notified - Solution: redundant paths User
k-Redundant Depender Graph (k-RDG) k parents per body node Example, k = 2 User Owner ROOT NODE Server User User Theorem: k -1 node failures cannot disconnect any body node Flooding protocol: send revocations to all dependers
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?
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
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 forwarding
Finding k Parents 1. Identify attachment node 2. Start with its parents 3. Find available nodes below them
Example: “Triangular” Graph For k = 3
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
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
Скачать презентацию Efficient Fault-Tolerant Certificate Revocation Rebecca Wright AT T Labs
c35b8ef485d6fffb7708e500f4336b46.ppt