Issuing digital certificates for Extended Validation Code Signing or Adobe Document Signing requires the generation of a key with certain security properties. When generated, the key must be flagged as “sensitive” (meaning that the key cannot be shown in plaintext) and, more importantly, non-exportable (cannot be revealed even when encrypted) from the HSM. There are several paths to follow for this procedure, like obtaining a secure token from SSL.com with pre-installed certificates. This article focuses on the case where clients opt to use their own physical HSM or cloud HSM account and employ a qualified professional of their choice to attest the proper execution of this process.
What is Attestation?
Before SSL.com can sign and issue EV Code Signing or Adobe-Trusted Document Signing certificates, we must first obtain proof that the customer’s private signing key has been generated by and is securely stored in a FIPS 140-2 Level 2 (or greater) certified device, from which it cannot be exported. The act of proving that a private key meets these requirements is known as attestation. The exact procedures for private key attestation vary between devices and cloud computing platforms.
Some services, like Google Cloud HSM, provide remote attestation by issuing a unique certificate for every HSM used, which when combined with the unique certificate issued by the HSM’s manufacturer is enough to provide certainty that the generated key possesses the required attributes and is PKCS #11 compliant. Such an attestation is considered sufficient evidence for SSL.com to ensure the eligibility of the key.
However, there are services, most notably AWS, that do not provide remote key attestation. In this case, the attestation is done by a manual procedure which is called Key Generation Ceremony (KGC). The KGC requires validation from an auditor that is highly skilled in the field. The client can utilize an in-house expert from SSL.com, but can also opt to use an independent professional of their choice. This is referred to as Bring Your Own Auditor (BYOA). In order to ensure that the process provides adequate validation, the following fields need to be controlled:
- The eligibility of the chosen professional (auditor) who shall provide a proper KGC
- The KGC preparation and execution process
- The minimum requirements that ought to be checked and reported by the auditor
KGC process: Preparation and guidelines
BYOA is a valid alternative for clients, but it requires thorough preparation, otherwise, there is a significant risk of rejection for the generated key. This could happen if the device used is not compliant, or the auditor is not qualified, or the auditor’s report does not cover the requirements of the process. In such a case, the ceremony and its witnessing have to be repeated, resulting in added costs and delays for the client.
To avoid such scenarios, SSL.com’s customer support and/or validation specialists communicate with the customer before the KGC to provide guidance and ensure the following:
- The auditor is approved according to the criteria described below
- The ceremony preparations requirements as wells as the ceremony script are clear and followed thoroughly, so as the KGC environment is well prepared
- Any restrictions and/or BYOA-specific terms and conditions are clear and accepted by the customer
Eligibility of KGC auditor
Customers requesting EV Code Signing or Adobe-Trusted Document Signing certificates can present the Certificate Signing Request (CSR) and a confirmation from an independent professional (BYOA) that the key pair was generated and stored in an approved HSM, under an approved operating environment, and in compliance with all PKCS #11 attributes.
SSL.com has set a series of criteria to ensure the competency and ethics of the professional that the client chooses. These criteria, which are also used to evaluate and approve SSL.com’s affiliated auditors, are in place to ensure the security and conformance of the signing product (EV Code Signing or Adobe-Trusted Document Signing certificate).
The criteria that are considered for the acceptance or rejection of certification from an auditor are:
- Technical competency: The auditor needs to be qualified in the field of digital certification and cybersecurity
- Auditing competency: The auditor needs to prove the qualification of his auditing capacity through an appropriate personal certification or professional capacity (e.g. Webtrust/ETSI auditor, Cloud Security Alliance CCAK).
- Ethics: A check that there is a binding Code of Ethics in place, e.g. as part of the auditor’s certification.
- The ability to verify the above auditor information: A check against a public source (e.g. auditors registry) to verify the certification.
These criteria are checked by SSL.com validation specialists before being accepted. SSL.com maintains a list of BYOA-approved certifications for the above criteria, along with a list of affiliated auditors for the clients’ convenience.
This information is disclosed to the customer during the preparation phase. For more information, please contact support@stg.ssl.com.
KGC attestation requirements
The preparation phase is crucial to avoid mishaps in the ceremony which could lead to added costs and delays. The customer care in SSL.com ensures that all auditing requirements are communicated to both the customer and the qualified auditor before a ceremony script is selected. To further assist, SSL.com has prepared material to support AWS Cloud HSM, such as Ceremony preparation requirements and a Ceremony Script, which are available by contacting support@stg.ssl.com during the preparation phase.
The client can opt to create their own script through the Qualified Auditor (QA) but in this case, we highly recommend that the Ceremony Script is reviewed and approved by our own engineers before use.
In any case, the Qualified Auditor must personally verify and attest to the following, regarding the Private Key Generation Ceremony:
- Private Key Material was created in an HSM compliant with at least FIPS 140-2 Level 2 and is operating in at least FIPS 140-2 Level 2 mode.
- The HSM and firmware used in the ceremony were genuine and the firmware version is not associated with any known vulnerabilities
- The software used for the ceremony was official HSM software provided by the manufacturer and its integrity was verified by the QA
- All communications with the HSM during the key generation process were encrypted and mutually authenticated via cryptographic means
- Private Key Material was created inside the HSM and was not imported
- Private Key Material is not marked as extractable (PKCS #11 attribute “CKA_EXTRACTABLE/CKA_EXPORTABLE”) and it never was.
- Private Key Material is marked as sensitive (PKCS #11 attribute “CKA_SENSITIVE”) and it always was.
- Access to the generated key material requires user authentication
- The QA was present, has followed all the ceremony processes, and there was no suspicion or evidence of foul play.
In addition to the above requirements, the QA attests that the Subscriber’s operating environment achieves a level of security at least equivalent to that of FIPS 140-2 Level 2.
Conclusion
BYOA is a valid and useful alternative for the cases that remote attestation is not available for Extended Validation Code Signing and Adobe Approved Trust List certificates. SSL.com makes sure that customers are thoroughly prepared for the procedure and provided with top-level support in the case they utilize this option.