02/22/2005 Joint Seminer

Satoshi KogaSatoshi Koga

Information Technology & Security Lab.

Kyushu Univ.

A Distributed A Distributed Online Certificate Status Protocol Online Certificate Status Protocol with Low Communication Costswith Low Communication Costs

A preliminary version of this paper is presented at PKC 2004

2

BackgroundBackground

• 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 compromisedUser’s personal information is changed

– The verifier must check the revocation information

3

Certificate revocationCertificate revocation

• Compromise of private key, or changing personal information– The certificate must be revoked 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

certificateIs this certificate

valid? or revoked?

Certificate verifier

4

Certificate revocation systemsCertificate 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 Online Certificate Status Protocol (OCSP)(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

CAResponder

User

request

response

Revocationinformation

Back

6

OCSP (cont’d)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

MotivationMotivation

• 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 unavoidableunavoidable

8

Distributed OCSPDistributed 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-OCSPTraditional D-OCSP

CACAresponder’scertificate

CA’scertificate

UserUser

response+

signature

responder 1responder 1 responder responder nnresponder 2responder 2

PK1, SK1 PK2, SK2 PKn, SKn

To eliminate the validation of certificate revocation,

the CA issues responder’s certificate with short lifetime

10

Challenging issueChallenging 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 OCSPOur 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 ideaOur 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

• 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)

SK1 Lifetime

Period 1 Period 2

SKT

Period T

SK2

Key-insulated signature scheme (KIS)Key-insulated signature scheme (KIS)

Period i

SKi

PK

14

• 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*

SK1’SKT’

SK1

LifetimePeriod 1 Period 2

SKT

Period T

SK2

Update algorithm in KISUpdate algorithm in KIS

signer

15

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

Our methodOur method

16

• 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

CACA

responder 1responder 1 responder nresponder n

PK

Decentralization MethodDecentralization Method

Reponder’s public key

responder 2responder 2

SK1 SK2 SKn

The user must check that responder’s private key is not

revoked

17

• Use the NOVOMODO [M02]– Using one-way hash function h– Generating the following hash-chain

– At period t, the verifier checks the following equation

)(XhX tt

0

XInput value

h XTh h X0

Validation of responder’s private keyValidation of responder’s private key

XT-1h

18

• The CA produces n hash-chains and stores them securely

• The CA issues responder’s certificate D: certificate data

Responder 1

Responder n

Issuance of responder’s certificateIssuance of responder’s certificate

XT,1h XT-1, 1

h h X0, 1XT-2, 1h

XT,2h XT-1, 2

h h X0 ,2XT-2, 2h

XT,nh XT-1, n

h h X0, nXT-2, nh

Responder 2

Cres=SigCA(D, PKres, X0, 1, X0, 2 , …, X 0, n)

19

• 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

CA responder i

Validation processValidation process

Xt, i

X 0, i = ht(X t, i)

20

CACA

responder’scertificate

CA’scertificate

UserUser

Our Proposed D-OCSPOur Proposed D-OCSP

responder 1responder 1 responder responder nnresponder 2responder 2

SK1 SK2SKn

Response+

X t, i

Xt,1 Xt,2 Xt,i

21

DiscussionsDiscussions

• 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)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

EfficiencyEfficiency

Traditional Traditional

D-OCSP (DSA)D-OCSP (DSA)

Our proposed Our proposed D-OCSP (KIS)D-OCSP (KIS)

Size of a responseSize of a response 1750-1950 bytes 250-350 bytes

Verification costs Verification costs

(# of multiplications)(# of multiplications)

3+EX|q| t+2+3EX|q|

Signature costs Signature costs

(# of multiplications)(# of multiplications)

2+EX|q| 2+2EX|q|

・ 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

ConclusionConclusion

• 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