1 / 19

ASYNCHRONOUS LARGE-SCALE CERTIFICATION BASED ON CERTIFICATE VERIFICATION TREES

ASYNCHRONOUS LARGE-SCALE CERTIFICATION BASED ON CERTIFICATE VERIFICATION TREES. Josep Domingo-Ferrer, Marc Alba and Francesc Sebé Dept. of Computer Engineering and Mathematics Universitat Rovira i Virgili. Introduction.

bat
Télécharger la présentation

ASYNCHRONOUS LARGE-SCALE CERTIFICATION BASED ON CERTIFICATE VERIFICATION TREES

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. ASYNCHRONOUS LARGE-SCALE CERTIFICATION BASED ON CERTIFICATE VERIFICATION TREES Josep Domingo-Ferrer, Marc Alba and Francesc Sebé Dept. of Computer Engineering and Mathematics Universitat Rovira i Virgili

  2. Introduction • The design of efficient large-scale public-key infrastructures is a hot topic of research • Digital certificates consist of a c-statement along with the CA’s signature • Two important bottlenecks are: • Certificate revocation • Design of manageable large-scale certification authorities (CAs)

  3. Solutions to deal with revocation • Certificate revocation lists (CRL) • Certificate revocation trees (CRT), reduce the huge size of CRLs • Short-validity certificates are good until their expiration date • Certificate revocation system (CRS) • Naor-Nissim system • Certificate verification trees (CVT): revocation information and the certificate directory are stored in the same Merkle tree

  4. Certificate verification trees (1/4) • The CA constructs a Merkle B-tree: • Each leaf is a c-statement plus the hash of that c-statement • Hash values of siblings in the B-tree are hashed together to get a hash value for their parents node • The CA signs the hash value of the root node, called RV, together with date and time • The cert-path for a c-statement is the path to the root along with the hash values needed to verify that path (the hash values of siblings of nodes along that path)

  5. Sign(RV||Date||Time) RV=h(H || H ) 5 6 H =h(H || H ) H =h(H || H ) 5 1 2 6 3 4 H =h(C ) H =h(C ) H =h(C ) H =h(C ) 1 1 2 2 3 3 4 4 C C C C 1 2 3 4 Certificate verification trees (2/4)

  6. Certificate verification trees (3/4) • A single signature certifies all public keys • Tree update is performed on a regular basis • Batches of new certificates are incorporated to the Merkle B-tree • Each CVT update only needs one signature on RV • CVTs allow the CA key to be changed with low computational cost (one signature on RV) • CVTs allow to deal with historical queries. The CA should store old CVT roots

  7. Certificate verification trees (4/4) • CVTs prove certificate non-existence • Top levels of a CVT can be cached by verifiers, reducing communication and computation • CVTs have the drawback of tying certificate issuance and revocation to CVT updates which are only carried out once in a period

  8. Our contribution • All advantages of CVTs are preserved • In addition, we provide • Asynchronous certificate renewal and revocation • Implicit revocation

  9. CVT-based asynchronous certification • Batches of certificates are requested ahead of time without the user having to store the corresponding private keys • The user can use a new certificate as soon as the current one has expired  asynchronous certification • The signer is represented by a smart card or another tamper-resistant device • The scheme is described by three protocols: set-up, signature and implicit revocation

  10. Protocol 1: Set-up 1 The signer’s smart card SC generates a key k for a symmetric block cipher (e.g. DES, AES) 2 For i=1 to m: (a) SC generates a public-private key pair (pki,ski) (b) SC encrypts ski under k to get Ek(ski) (c) SC sends (pki,Ek(ski)) to the CA (d) SC deletes pki, ski and Ek(ski) from its memory 3 CA stores the encrypted private keys Ek(ski) received 4 In the next CVT update, CA adds all received pki’s to the CVT

  11. Set-up • Key pairs are assumed to be valid in consecutive future time intervals • Certificate validity intervals are completely independent from CVT update periods • Protocol 1 is run frequently enough so that one never runs out of key pairs • The larger the batch size m, the less frequently the protocol needs to be run

  12. Protocol 2: Signature at time interval t 1 If the user’s SC stores a private key sktvalid for time interval t, the SC does: (a) If necessary get the cert-path for the pkt certificate from CVT directory 2 Otherwise SC does: (a) Delete from its memory the last skj stored, if any (b) Get Ek(skt) from the CA (c) Get the certificate and the cert-path of pktfrom the CVT directory (d) Decrypt Ek(skt) to get skt 3 Sign using skt

  13. Signature • SC stores no private key except the current one • SC can use a new certificate as soon as the current one has expired • Signing implies appending the corresponding cert-path to the signature

  14. Protocol 3: Implicit revocation 1 If the SC is stolen or lost, the user informs the CA 2 The CA stops serving encrypted private keys Ek(ski) to SC

  15. Implicit revocation • Protocol 3 implicitly revokes all certificates in the CVT which were requested for future time intervals • The current certificate is not revoked • To eliminate the need for explicit revocation of the current certificate, short-validity certificates can be used • An intruder will have little time to tamper with SC in order to have it sign under the private key SC is currently storing • Short-validity certificates do not survive more than one CVT update period

  16. Efficiency • Asynchronous certification. Requesting certificates ahead of time allows the SC to use new certificates as soon as the current one expires • Reduced storage. The user can request a batch of certificates, but her SC only stores the current key pair and the key of a symmetric block cipher • Implicit revocation. In the event of smart card loss or compromise, all certificates requested by that SC are implicitly revoked and CVT update is not required

  17. Implicit vs explicit revocation • Explicit revocation forces the CA to distribute CRLs or update CVTs and it also forces the signature verifier to check these CRLs or CVTs before accepting a signature • Implicit revocation is a much better alternative which prevents the private key corresponding to a revoked certificate from ever being used to sign • Explicit revocation of the current certificate can be made unnecessary if short-validity certificates are used

  18. Security • If implicit revocation protocol is run by the user at time interval t • Her SC will become useless from time interval t+1 onwards • Regarding interval t • If SC has not yet downloaded skt, SC is useless to the intruder • If SC has already downloaded skt • Short-validity certificates make it unlikely that the intruder can hack SC to sign with skt before certificate expiration • Long-lived certificates need explicit revocation (CRLs or CVT update)

  19. Conclusion • CVTs are a very convenient data structure for managing large-scale public key directories • Their drawback is that certificate issuance and revocation must be synchronized with a CVT update • We have proposed a scheme where certificates can be requested ahead of time without decreasing security • In the event of loss or compromise of the user’s smart card, implicit revocation is used

More Related