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 n 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: n n Certificate revocation Design of manageable large-scale certification authorities (CAs)

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

Certificate verification trees (1/4) n The CA constructs a Merkle B-tree: n n Each leaf is a c-statement plus the hash of that cstatement 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)

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

Certificate verification trees (3/4) n n A single signature certifies all public keys Tree update is performed on a regular basis n n Batches of new certificates are incorporated to the Merkle Btree 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

Certificate verification trees (4/4) n n n 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

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

CVT-based asynchronous certification n n 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

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

Set-up n n 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

Protocol 2: Signature at time interval t 1 If the user’s SC stores a private key skt valid 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 pkt from the CVT directory (d) Decrypt Ek(skt) to get skt 3 Sign using skt

Signature n n n 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 certpath to the signature

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

Implicit revocation n 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 n n 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

Efficiency n n n 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

Implicit vs explicit revocation n 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

Security n If implicit revocation protocol is run by the user at time interval t n n Her SC will become useless from time interval t+1 onwards Regarding interval t n n If SC has not yet downloaded skt, SC is useless to the intruder If SC has already downloaded skt n n 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)

Conclusion n n 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