16. Data Security and Private Key Protection

The requirements in BR Sections 6.1 and 6.2 apply equally to Code Signing Certificates. In addition:

16.1 Timestamp Authority Key Protection

1.Each CA MUST operate an RFC-3161-compliant Timestamp Authority that is available for use by customers of its Code Signing Certificates. CAs MUST recommend to Subscribers that they use the CA’s Timestamping Authority to time-stamp signed code.

2.A Timestamp Authority MUST protect its signing key using a process that is at least to FIPS 140-2 Level 3, Common Criteria EAL 4+ (ALC_FLR.2), or higher. The CA MUST protect its signing operations in accordance with the CA/Browser Forum’s Network Security Guidelines. Any changes to its signing process MUST be an auditable event.

3.The Timestamp Authority MUST ensure that clock synchronization is maintained when a leap second occurs. A Timestamp Authority MUST synchronize its timestamp server at least every 24 hours with a UTC(k) time source. The timestamp server MUST automatically detect and report on clock drifts or jumps out of synchronization with UTC. Clock adjustments of one second or greater MUST be auditable events.

16.2 Signing Service Requirements

The Signing Service MUST ensure that a Subscriber’s private key is generated, stored, and used in a secure environment that has controls to prevent theft or misuse. A Signing Service MUST enforce multi-factor authentication to access and authorize Code Signing and obtain a representation from the Subscriber that they will securely store the tokens required for multi-factor access. A system used to host a Signing Service MUST NOT be used for web browsing. The Signing Service MUST run a regularly updated antivirus solution to scan the service for possible virus infection. The Signing Service MUST comply with the Network Security Guidelines as a “Delegated Third Party”.

16.3 Subscriber Private Key Protection

The CA MUST obtain a representation from the Subscriber that the Subscriber will use one of the following options to generate and protect their Code Signing Certificate private keys:

1. A Trusted Platform Module (TPM) that generates and secures a key pair and that can document the Subscriber’s private key protection through a TPM key attestation.

2. A hardware crypto module with a unit design form factor certified as conforming to at least FIPS 140 Level 2, Common Criteria EAL 4+, or equivalent.

3. Another type of hardware storage token with a unit design form factor of SD Card or USB token (not necessarily certified as conformant with FIPS 140 Level 2 or Common Criteria EAL 4+). The Subscriber MUST also warrant that it will keep the token physically separate from the device that hosts the code signing function until a signing session is begun.

A CA MUST recommend that the Subscriber protect Private Keys using the method described in Section 16.3(1) or 16.3(2) over the method described in Section 16.3(3) and obligate the Subscriber to protect Private Keys in accordance with 10.3.2(2).