Introduction
This Use Case has been developed for JISA’s CryptoBind HSM (Network Security Module by JISA Powered by LiquidSecurity) product. JISA’s HSM can be used in Certificate Authority use case to manage and protect digital certificates.
In cryptography, a certificate authority (CA) is an entity that issues digital certificates.
A digital certificate validates the identity of a owner such as website, company or an individual person.
CA binds a cryptographic key called as digital certificate or signature to the owner to prove their identity. This allows others (relying parties) to rely upon signatures or on assertions made about the private key that corresponds to the certified public key. A CA acts as a trusted third party—trusted both by the subject (owner) of the certificate and by the party relying upon the certificate. The format of these certificates is specified by the X.509 or EMV standard.
One particularly common use for certificate authorities is to sign certificates used in HTTPS, the secure browsing protocol for the World Wide Web. Another common use is in issuing identity cards by national governments for use in electronically signing documents.
Why to use CryptoBind HSM in this use case?
A CA issues digital certificates that contain a public key and the identity of the owner. The matching private key is not made available publicly, but kept secret by the end user who generated the key pair. The certificate is also a confirmation or validation by the CA that the public key contained in the certificate belongs to the person, organization, server or other entity noted in the certificate. A CA’s obligation in such schemes is to verify an applicant’s credentials, so that users and relying parties can trust the information in the CA’s certificates.
If the organization does not use HSM for storing the private keys, the keys would be stored on local server in a file folder or database. And if someone gets hold of these keys, they can steal identity of owner and sign the certificate as if the owner is signing the certificate. Hence HSM is an excellent way to protect private keys for a Certificate Authority, whose primary function is to sign Certificate Signing Requests.
Use Case Flow
To acquire a digital certificate, an applicant who needs the certificate, makes a request to certificate authority. The applicant generates a key pair consisting of a private key and a public key, along with certificate signing request (CSR). A CSR is an encoded file which include public key of applicant and information related to applicant (i.e. organization name, website address etc.) which is to be shown on the certificate. Key pair generation and CSR generation is done on the
server or machine on which the certificate will be installed. The private key is not made available to anyone and CSR is sent to CA. CA then verifies whether the information is correct and digitally signs the certificate with its own private key and send the certificate to the applicant. This flow is shown in below diagram.
For an instance when the certificate is presented to a user who accesses the website of certificate holder, the user can confirm the certificate by using CA’s public key. Additionally the user can use the certificate to confirm the signed content is sent someone who owns the respective private key. User can also confirm that the information is not tampered since it was signed.