0

I am currently defining a PKI for code signing certificates on an embedded device (without internet connection). I define the behavior of the certificate issuer(FW release authority) as well as the FW code which will authenticate the certificate of the public key used to sign it upon FW update, I want to define a strategy for checking revocation status of code-signing certificates issued by a CA. the general system will work as follows :

1.firmware code shall be signed by a private key(key#1priv)

2.The public key paired with that private key(key#1pub) shall be sent in a csr (constructed by a HSM) to the CA and obtain a code signing certificate

3.CA's public key will be downloaded to the drive in a secured way

4.During FW update the FW will receive the certificate for key#1pub , authenticate it with CA's public key and then proceed with the authentication of the FW code using key#1pub

My question is:

In case the CA's private key was compromised, from my understanding , a csr shall be sent again to the CA and a new certificate shall be obtained signed by the revocated private key. according to what I understood from online reading , a OCSP request shall be sent to the CA is order to find the revocation status of the certificate according to its serial number , how does the certificate requester knows when to issue such OCSP request ? in other words , what is the common practice for a timing of sending OCSP requests to the CA?

Thanks.

Improve this question

1 Answer 1

Reset to default
1

I think you get it wrong. To describe the basic ideas of using a certificate agency and of revocation:

  • The CA should be locally trusted on the device by installing its root certificate on the device.
  • The CA issues the certificate based on the CSR.
  • The device can verify the trust into the certificate by using the locally installed root certificate of the CA.
  • The CA can revoke certificates it has issued. The revocation information are signed by the CA so that they can be verified using the locally installed root CA.
  • But the CA certificate itself can not be revoked. Since the root certificate of the CA is self-signed the revocation would have been signed by the private key of the CA itself - but the root certificate should be revoked because exactly this private key is compromised which means one cannot trust anything signed with this key. This means if the CA is compromised one has to remove it as trusted from the device. See How are root CA revocations handled? and Can a RootCA be revoked? for more information.

Thus, there is no way to check the revocation of the CA.
But one can check the revocation of the CA issued certificate. This should be done whenever the certificate is used, i.e. whenever the signature is verified in your case. Since this might be too often OCSP responses and certificate revocation lists (CRL) have some kind of life time and you might reuse the last result as long as it is still considered valid.

Improve this answer
2
  • Steffen , Thanks a lot for your comment. I got it now , since our organization is playing all roles of the PKI (including the CA) I can simply notify the FW release authority whenever there is a revocation and thus invalidate all the certificates which were signed with a compromised private key. please correct me if I am wrong.
    – Dima Shifrin
    Jun 11, 2017 at 11:07
  • @DimaShifrin: while you can declare all the issued certificates as invalid you have to do this outside the PKI (i.e. not using CRL or OCSP) since the root CA of the PKI can no longer be trusted. A common method of dealing with this problem is to have the certificates signed by an intermediate CA which itself got signed by the root CA. In this case the private key of the root CA can be locked away (i.e. taken offline) so that the chance of compromise is as small as possible. This way the issuer of the certs, i.e. the intermediate CA, can be revoked if needed.
    – Steffen Ullrich
    Jun 11, 2017 at 11:10

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .