1 / 16

Efficient Fault-Tolerant Certificate Revocation

This paper presents innovative methods for efficient and fault-tolerant certificate revocation, focusing on the construction of k-redundant depender graphs (k-RDGs). It addresses the challenges of notifying users about certificate revocations while ensuring that communication channels remain robust, even during node failures. Key findings include strategies for minimizing path lengths in communication, handling temporary and permanent node failures, and updating certificate authority structures. The proposed system enhances reliability in certificate forwarding, contributing to secure digital communications.

urielle-rodriquez
Télécharger la présentation

Efficient Fault-Tolerant Certificate Revocation

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Efficient Fault-Tolerant Certificate Revocation Rebecca Wright Patrick Lincoln Jonathan Millen AT&T 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 User Server 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 User Server User User User User User User - Just like forwarding graph - But what if a node fails?

  8. Temporary Failure Owner Revocation Notice User Server 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 User Server 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

More Related