A Framework for Distributed OCSP without Responders Certificate Young-Ho Park (pyhoya@mail1.pknu.ac.kr) Kyung-Hyune Rhee (khrhee@pknu.ac.kr) Pukyong National University WISA 2004

Public Key Certificate Public Key Infrastructure(PKI) The main architecture for security services over the Internet Public Key Certificate Bind a public key to the owner’s identity information Digitally signed and certified by a trusted certificate authority(CA) Certificates Revocation Compromising of the key or abuse of the owner Certificates Revocation List (CRL) Online Certificate Status Protocol (OCSP) In a PKI, every user must obtain a public key certificate issued by a trusted certificate authority for secure transaction over the Internet. This certificate is digitally signed by the CA and used for authentication to identify the owner of the public key. Certificate is a long term credential, and it may be revoked before the expiration date due to the compromising of the key or abuse of the owner. Hence, before using a certificate, you must check if the certificate is valid or revoked by CRL or OCSP. Lab. of Information security & Internet Applications, PKNU

Online Certificate Status Protocol To check the validity of a certificate at the time of a given transaction OCSP responder provides a digitally signed response Client can retrieve timely certificate status with a moderated resource usage Single Responder Most workloads converge into the responder Digital signature is a computation consuming operation Denial of service CA Responder X.500 directory Request Response Good, Revoked or Unknown Validity Interval . . . . . Signature Online certificate status protocol is one means to check the validity of a certificate. If a timeliness status information is required, OCSP is preferred. When clients request status information for wanted certificate to OCSP responder, the responder examines the status of the requested certificate and then returns a response including OCSP responder’s digital signature for the response message. At this moment, the status of the response is one of good, revoked ore unknown. When client receives the response message, client first verifies the responder’s signature and then accept the response. Generally, OCSP responder is a single server, and digital signature is a computation consuming operation, so if many clients are converged into the one responder single-point-of-failure problem or DoS is possible because of the heavy burden of all response processing. Lab. of Information security & Internet Applications, PKNU

Lab. of Information security & Internet Applications, PKNU Distributed OCSP Composed of multiple OCSP responders Sharing and balancing the workload of OCSP response Client can choose one responder Certificate of responder is required to verify the signature in response of both OCSP and D-OCSP In D-OCSP Using the same private signing key for every responder Easy key management but high risk for key exposure Using different private key Increasing the complexity of key management Distributed OCSP is a countermeasure to the single OCSP responder. DOCSP is composed of multiple responders and each responder shares the burden of OCSP response. Clients can select one those responders and each responder returns response including its digital signature. To verify the responder’s signature, client must obtain the replying responder’s certificate and check the status of the responder certificate again. Therefore efficient key management is required for multiple responders. If all responders have the same private key for digital signature, key management is easy but the risk of key exposure is very critical to system because the compromising of one responder is equal to the compromising of all responders. However, if every responders have different key, the system is more secure but key management is more complex. Lab. of Information security & Internet Applications, PKNU

Lab. of Information security & Internet Applications, PKNU KIS-D-OCSP (1) [S. Koga and K. Sakurai, PKC 2004] One solution for efficient certificate management of multiple responders Key insulated signature(KIS) scheme and hash chain Different private key for every responders but the same public key for signature verification Only one certificate is required for multiple responders Private key exposure of one responder does not effect other responders Hash chain is used for checking the validity of a responder at the given time period Koga and Sakurai proposed one solution for efficient certificate management scheme in DOCSP. This scheme use key insulated signature and hash chains for responders certificates management. By using key insulated signature scheme, different private key but just one corresponding public key is possible. So only one certificate is needed for every responders. And to check the timeliness of responder, hash chain is used. Lab. of Information security & Internet Applications, PKNU

Lab. of Information security & Internet Applications, PKNU KIS-D-OCSP (2) Key Generation CA distributes private keys for every responders CA Private key for signature R1 Key Generator R2 . . . . Master Key Rn Public Key Secure channel To generate and distribute every responders private key for digital signature, CA chooses a master secret and calculates its corresponding public key. Then, if the number of responders is n, CA generates n private keys for responders by applying KIS key generating algorithm and securely distributes the keys to each responder. Lab. of Information security & Internet Applications, PKNU

Lab. of Information security & Internet Applications, PKNU KIS-D-OCSP (3) Hash chain For total time periods and responders CA provides at time period to responder Validity checks at for responder Checking if is true Responder Certificate: CA keeps securely Then, CA generates hash chains to be used for timeliness checking. If the total time periods is T, CA generates T chained hash values for each responder and keeps the first elements securely. Each hash value is used for given time period. If the time period is one day, 365 hash values are generated per responder. Client checks the timeliness of a responder by checking (hash chain) at the given time period. CA issues the certificate for all responders. This certificate includes KIS public key and the first hash values in the hash chain of all responders. SN : serial number I, J : Issuer and Subject V : Valid time period Lab. of Information security & Internet Applications, PKNU

Lab. of Information security & Internet Applications, PKNU KIS-D-OCSP (4) System Responder Certificate - Verifying CA signature and checking expiration of the certificate Checking hash chain - Verifying signature in response Provides hash values for the current time period Generates and distributes private keys for every responders CA Response, KIS-Signature, Requests for service to one responder . . . . R1 Rn Lab. of Information security & Internet Applications, PKNU

Lab. of Information security & Internet Applications, PKNU IBS-D-OCSP (1) Applying identity-based signature(IBS) scheme Motivations It is possible to generate different private keys from the same master key with different identifier strings Identifier itself can be used function for public key Removing the overhead of certificate management for responders KIS-D-OCSP requires at least one certificate Date information can be encoded into keying material Date is common knowledge Hash chain is not required to check the validity for the given time period OCSP responders certificates for certificate management? KIS-D-OCSP is one solution for efficient key management for multiple responders. However, it still requires at least one certificate management. Our main contribution is removing the overhead of certificate management for responders, so we applied identity-based signature scheme. Identity-based cryptosystems is an alternative system to reduce the certificate management in a PKI. Recently, identity-based systems is the one of main research issue in public key cryptosystems. In ID-based system, generating different private keys from the same master key with different identifier string is possible. The identifier itself of communicating party can be used for public key function. Therefore, if identifier of the communicating party can be known to the system, a certificate to bind a public key and the owner can be removed. Furthermore, during the key generation processing, date information can be encoded into keying material, a hash chain as in KIS-D-OCSP is not required. Lab. of Information security & Internet Applications, PKNU

Lab. of Information security & Internet Applications, PKNU IBS-D-OCSP (2) Implementing Issues Identity-based Signature Scheme [J. Cha and J. Cheon, PKC2003] Bilinear Pairing Weil and Tate pairing on elliptic curve Identifiers of responders Certificate contains OCSP_URI Certified by the CA Ex.) Keying ID = “CA || Responder_URI || 20040818” ID itself is public key for IBS verification To design our system, we apply the IBS proposed by Cha and Cheon. Most of recently proposed ID-based schemes are based on pairings defined on an elliptic curve. One of the main issues to implement ID-based system is what we can use an identifier for keying material. Generally, when CA issues a certificate, the certificate contains OCSP_URI for OCSP request service and the contents in the certificate is certified by the CA. Therefore we can immediately use the OCSP_URI and current date as keying materials for IBS signature if the time period is one day. Lab. of Information security & Internet Applications, PKNU

Lab. of Information security & Internet Applications, PKNU IBS-D-OCSP (3) Key Generation CA generates private keys for responders’ identifiers CA Date info. R1 Key Generator . . . . Master Key identifier1 Secure channel Rn To distribute each responder’s private key, CA first choose its master secret and calculates its corresponding public key. Then, CA computes each responder’s private key from the identifier of each responder and current date and securely distributes the keys. Lab. of Information security & Internet Applications, PKNU

Lab. of Information security & Internet Applications, PKNU IBS-D-OCSP (4) System - Calculating public key with responder identifier and date info. Verifying signature in response Distributes private keys for given time period CA Requests for service to one of responders Response, IBS-Signature . . . . R1 Rn Lab. of Information security & Internet Applications, PKNU

Lab. of Information security & Internet Applications, PKNU Security of a signature is relying on the underlying IBS Assuming that CA is a trusted authority Master key is not disclosed Difficult to compute private key from identifier without knowing the master key DLP(Discrete Logarithm Problem) Date information is encoded in keying material Keys are only valid for the given time period Lab. of Information security & Internet Applications, PKNU

Lab. of Information security & Internet Applications, PKNU Efficiency KIS-D-OCSP IBS-D-OCSP Compare KIS-D-OCSP & IBS-D-OCSP Master public key size is proportional to the number of responders Master public key size is constant to the number of responders At least one certificate for responders No certificate for responders CA stores hash values securely CA stores no hash values Return : {response, signature, hash} Return : {response, signature} 2 signature verifications + ( t-I ) hashing 1 signature verification Hash chains to check timely validity Encoding date info. into keying material Refresh private keys every time period Update hash values every time period Lab. of Information security & Internet Applications, PKNU

Lab. of Information security & Internet Applications, PKNU Conclusion Public key certificate is essential for secure Internet Certificate validity checking is required OCSP is one solution Proposed an efficient D-OCSP framework IBS-D-OCSP Remove responders certificate Don’t require additional certificate management Any other efficient IBS schemes can be applied to the system Lab. of Information security & Internet Applications, PKNU