A Distributed Online Certificate Status Protocol with Low Communication Costs

1. 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 Joint Seminer

2. 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

3. 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

4. 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

5. Online Certificate Status Protocol (OCSP) • 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 Responder request Revocation information CA response User Back

6. 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 (DoS) attacks

7. Motivation • Centralized OCSP • Compromise of responder’s private key affects the entire system • Protection of the private key • Hardware Security Module (FIPS140-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

8. 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

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

10. 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

11. 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

12. Our idea • To generate the responder’s private keys • Use the Key-Insulated Signature scheme (KIS) [DO03] • 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 [M02] [DO03] Y. Dodis et al. , “Strong Key-Insulated Signature Schemes”, PKC 2003. [M02] S. Micali, “NOVOMODO”, 1st Annual PKI Research Workshop, 2002.

13. 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 SK1 SKi SK2 SKT Lifetime Period 1 Period 2 Period T Period i

14. 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’ SK1’ SK1 SK2 SKT signer Lifetime Period 1 Period 2 Period T

15. 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

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

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

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

19. Validation process • If responder’s private key is valid at period t, the CA delivers the hash value to responder • 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 Xt, i CA responder i X 0, i = ht(X t, i)

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

21. 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

22. 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

23. Efficiency ・ OpenSSL ・ 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)

24. 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