A Distributed Online Certificate Status Protocol with Low

A Distributed Online Certificate Status Protocol with Low Communication Costs Satoshi Koga Information Technology & Security Lab. Kyushu Univ. A preliminary version of this paper is presented at PKC 2004 02/22/2005 Joint Seminer

Background • Public Key Infrastructure (PKI) – secure e-mail, authentication system etc. . • Certificate revocation problem – The certificate must be revoked if ü The user’s private key is compromised ü User’s personal information is changed – The verifier must check the revocation information 2

Certificate revocation • Compromise of private key, or changing personal information – The certificate must be revoked • If a certificate is revoked… – Certificate owner sends a revocation requests to the CA who issues certificates – The CA should publish revocation information – The certificate verifier should check the status of certificate Is this certificate valid? or revoked? Certificate verifier 3

Certificate revocation systems • Certificate Revocation List (CRL) • The list of revoked certificates • The size of the CRL is long • High communication costs • Online Certificate Status Protocol (OCSP) • Provide the up-to-date response to certificate status queries • Low Communication costs 4

Online Certificate Status Protocol (OCSP) n Responder checks the status of a certificate instead of users – User requests the status of a certificate – Responder sends the response including the status of requested certificate – Mitigate the load of user – Reduce the communication costs, compared with CRL Revocation information request Responder User CA response Back 5

OCSP (cont’d) • Security – Responses are signed by OCSP responder • Communication costs – A user receives response – Independent on number of revoked certificates • problem – High computation costs of OCSP responder It is vulnerable to Denial-of-Service (Do. S) attacks 6

Motivation • Centralized OCSP ü Compromise of responder’s private key affects the entire system • Protection of the private key ü Hardware Security Module (FIPS 140 -2 by NIST) ü Threshold cryptography : each server holds a shared private key and a predetermined number of servers must cooperate in order to perform the operation • Private key exposures appear to be unavoidable 7

Distributed OCSP • Minimize the damage caused by responder’s key exposures • A Distributed OCSP(D-OCSP) composed of the multiple responders – Each responder has the different private key If a responder’s private key is compromised, the others are not derived 8

Traditional D-OCSP CA’s certificate To eliminate the validation of certificate revocation, the CA issues responder’s certificate with short lifetime responder’s certificate CA User response + signature responder 1 responder 2 responder n PK 1, SK 1 PK 2, SK 2 PKn, SKn 9

Challenging issue • Responder’s certificate with a short lifetime Ø In case that the client receives the response, she must download responder’s certificate Communication costs is inefficient • Responder’s certificate with a long lifetime Ø The client needs to obtain the different responder’s certificates The client must store the multiple certificates 10

Our Proposed Distributed OCSP • To mitigate the damage caused by responder’s private key exposure A distributed OCSP (D-OCSP) • Propose an efficient D-OCSP – The client can verify any responses by using a single public key The client just obtains a single certificate 11

Our idea • To generate the responder’s private keys – Use the Key-Insulated Signature scheme (KIS) [DO 03] – Each responder has the different private key, but corresponding public key remains fixed – The client can verify any responses by using a single public key • To validate responder’s private key – Use the NOVOMODO [M 02] [DO 03] Y. Dodis et al. , “Strong Key-Insulated Signature Schemes”, PKC 2003. [M 02] S. Micali, “NOVOMODO”, 1 st Annual PKI Research Workshop, 2002. 12

Key-insulated signature scheme (KIS) • The lifetime of protocol is divided into short time periods • The beginning of period i, a private key is updated • The private key is updated frequently, but the corresponding public key is fixed • Even if SKi is exposed, the attacker cannot forge signature for any time periods (key-insulated security) PK SK 1 Period 1 SK 2 SKi SKT Period 2 Period i Period T Lifetime 13

Update algorithm in KIS • • • The master key SK* is stored on the secure device The Secure-device computes the partial key SKi ’ The user derives Ski+1 using partial key SKi ’ and SKi Once Ski+1 is derived, SKi is deleted If an attacker can know SKi, she cannot derive any other private keys (as long as SK* is secure) Secure device SK* SKT’ SK 1 signer Period 1 SK 2 SKT Period 2 Period T Lifetime 14

Our method ü All signatures can be verified by using a fixed public key ü Key-insulated security • Responder’s private keys are generated using Key-Insulated signature scheme • n (= the number of responders) private keys are generated at first stage 15

Decentralization Method • The CA stores the master key The private keys using key update • The CA generates n user must check that responder’s private key is not algorithm in KIS revoked • The CA delivers a private key to each responder securely Reponder’s public key CA SK 1 responder 1 SK 2 responder 2 SKn responder n 16

Validation of responder’s private key • Use the NOVOMODO [M 02] – Using one-way hash function h – Generating the following hash-chain X h XT-1 h h X 0 Input value – At period t, the verifier checks the following equation 17

Issuance of responder’s certificate • The CA produces n hash-chains and stores them securely h h XT, 1 XT-1, 1 XT-2, 1 X 0, 1 Responder 1 XT, 2 h XT, n h XT-1, 2 h XT-1, n h XT-2, 2 h h X 0 , 2 Responder 2 XT-2, n h h X 0, n Responder n • The CA issues responder’s certificate Cres=Sig. CA(D, PKres, X 0, 1, X 0, 2 , …, X 0, n) D: certificate data 18

Validation process • If responder’s private key is valid at period t, the CA delivers the hash value to responder CA Xt, i responder i • The responder sends both the signed response and this hash value • The user checks the following equation at period t – The user can verify the responder’s private key using hash function X 0, i = ht(X t, i) 19

Our Proposed D-OCSP CA’s certificate responder’s certificate CA User Response + X t, i Xt, 1 Xt, 2 responder 1 responder 2 SK 1 SK 2 Xt, i responder n SKn 20

Discussions • Security – If one private key is exposed, the attacker can not derive the others (Key-insulated security) – If the attacker obtains the hash value, she cannot derive the next hash value (one-way function) Minimize the impact of responder’s private key exposure 21

Discussions (cont’d) • Communication costs – The client can check any responses using a single public key – The client simply obtains one responder’s certificate the communication cost is efficient – The client only stores one certificate the memory space is small • Computational costs – Signing cost and verification cost are less efficient 22

Efficiency Traditional Our proposed D -OCSP (KIS) D-OCSP (DSA) Size of a response 1750 -1950 bytes 250 -350 bytes Verification costs (# of multiplications) 3+EX|q| t+2+3 EX|q| Signature costs (# of multiplications) 2+EX|q| 2+2 EX|q| ・ Open. SSL ・ CA’s key size： 2048 bit ・ Responder’s key size： 1024 bit ・ EX ： # of multiplication required to compute a exponentiation ・ |q| =160 ・ t = (# of responders) 23

Conclusion • Centralized OCSP – Compromise of private key affects the entire system – Mitigate the damage caused by compromise of responder • Efficient distributed OCSP – Apply key-insulated signature scheme and NOVOMODO – Any responses can be checked by using fixed public key 24