Private Key Protection

Private keys shall be protected using a Trustworthy System and private key holders shall take necessary precautions to prevent the loss, disclosure, modification, or unauthorized use of such Private Keys in accordance with this CP § 6.2, the Security and Audit Requirements Guide (in the case of VeriSign and Affiliates. This requirement applies to end-user Subscribers, Managed PKI Customers using Managed PKI Key Manager, Gateway Customers, and Processing Centers, which protect their own private keys and those of the Client Service Centers, Managed PKI Customers, and ASB Customers within their respective Subdomains. End-user Subscribers have the option of protecting their private keys in a smart card or other hardware token. The private keys of Roaming Subscribers, however, reside on an Enterprise Roaming Server in an encrypted form and the symmetric keys to encrypt or decrypt the private key are split between, and reside on, the VeriSign Roaming Server and the Enterprise Roaming Server. VeriSign and Managed PKI Customers shall protect private key segments on these servers using a Trustworthy System.

6.2.1 Standards for Cryptographic Modules (Class 1-3)

Processing Centers shall perform all CA cryptographic operations with their own private keys and the private keys of the Client Service Centers, Managed PKI Customers, and ASB

Customers within their Subdomains, on cryptographic modules rated at a minimum of FIPS 140-1 level 2. Service Centers shall perform all RA cryptographic operations on a cryptographic module rated at FIPS 140-1 level 2. VeriSign recommends that Managed PKI Customers perform all Automated Administration RA cryptographic operations on a cryptographic module rated at FIPS 140-1 level 2 and that Gateway Class 1 Customers perform all CA cryptographic operations on a cryptographic module rated at FIPS 140-1 level 1. The requirements for ratings in this section are subject to any applicable local requirements for higher ratings.

6.2.2 Private Key (m out of n) Multi-Person Control (Class 1-3)

Multi-person control shall be enforced to protect the activation data needed to activate CA private keys held by Processing Centers in accordance with the Key Ceremony Reference Guide and Security and Audit Requirements Guide. Processing Centers shall use “Secret Sharing” to split the private key or activation data needed to operate the private key into separate parts called

“Secret Shares” held by individuals called “Shareholders.” Some threshold number of Secret Shares (m) out of the total number of Secret Shares (n) shall be required to operate the private key.

Processing Centers shall utilize Secret Sharing to protect the activation data needed to activate their own private keys, and those of the Client Service Centers, Managed PKI Customers, and ASB Customers within their respective Subdomains, in accordance with the Key Ceremony Reference Guide and Security and Audit Requirements Guide. Processing Centers shall also use Secret Sharing to protect the activation data needed to activate private keys located at their respective disaster recovery sites. Processing Centers shall implement Secret Sharing.

The threshold number of shares needed to sign a CA certificate is 3. It should be noted that the number of shares distributed for disaster recovery tokens may be less than the number distributed for operational tokens, while the threshold number of required shares remains the same. Secret Shares are protected in accordance with CP § 6.4.2.

6.2.3 Private Key Escrow (Class 1-3)

Managed PKI Customers using the Managed PKI Key Management service (or an equivalent service approved by VeriSign) are permitted to escrow end-user Subscribers’ private key as described in CP §1.1.2.3.2.. Escrowed private keys shall be stored in encrypted form using the Managed PKI Key Manager software. Except for Managed PKI Customers using the Managed PKI Key Manager Service (or an equivalent service approved by VeriSign), the private keys of CAs or end-user Subscribers shall not be escrowed.

End-user Subscriber private keys shall only be recovered under the circumstances permitted within the Managed PKI Key Management Service Administrator’s Guide, under which:

• Managed PKI Customers using Managed PKI Key Manager shall confirm the identity of any person purporting to be the Subscriber to ensure that a purported Subscriber request for the Subscriber’s private key is, in fact, from the Subscriber and not an imposter,

• Such Managed PKI Customers shall recover a Subscriber’s private key without the Subscriber’s request only for their legitimate and lawful purposes, such as to comply with judicial or administrative process or a search warrant, and not for any illegal, fraudulent, or other wrongful purpose, and

• Such Managed PKI Customers shall have personnel controls in place to prevent Key Management Service Administrators and other persons from obtaining unauthorized access to private keys.

6.2.4 Private Key Backup (Class 1-3)

Processing Centers and Gateway Customers shall back up their own private keys so as to be able to recover from disasters and equipment malfunction in accordance with the Key Ceremony Reference Guide and Security and Audit Requirements Guide. Processing Centers shall also back up the private keys of Client Service Centers, Managed PKI Customers, and ASB Customers within their Subdomains in accordance with these documents. Back-ups shall be made by copying such private keys and entering them onto back-up cryptographic modules in accordance with CP § 6.2.6.

Private keys that are backed up are to be protected from unauthorized modification or disclosure through physical or cryptographic means. Back ups shall be protected with a level of physical and cryptographic protection equal to or exceeding that for cryptographic modules within the Processing Center’s or Gateway Customer’s CA site, such as at a disaster recovery site or at another secure facility off-site, such as a bank safe.

The backup of end-user Subscriber private keys subject to the Managed PKI Key Manager service, is governed by CP § 6.2.3. VeriSign recommends that Managed PKI Customers having Automated Administration tokens and Class 3 end-user Subscribers who are not subject to the Managed PKI Key Manager service back up their private keys and protect them from

unauthorized modification or disclosure by physical or cryptographic means. The database of encrypted private keys stored on an Enterprise Roaming Server and the databases of segments of symmetric keys (used to encrypt and decrypt these private keys) stored on the VeriSign Roaming Server and Enterprise Roaming Servers shall be backed up for disaster recovery and business continuity purposes.

6.2.5 Private Key Archival (Class 1-3) No stipulation.

6.2.6 Private Key Entry into Cryptographic Module (Class 1-3)

The mechanisms of entry of a private key into a cryptographic module shall prevent loss, theft, modification, unauthorized disclosure, or unauthorized use of such private key. CA or RA private keys held on hardware cryptographic modules shall be stored in encrypted form.

Processing Centers generating CA or RA private keys on one hardware cryptographic module and transferring them into another shall securely transfer such private keys into the second cryptographic module to the extent necessary to prevent loss, theft, modification, unauthorized disclosure, or unauthorized use of such private keys. Such transfers shall be limited to making backup copies of the private keys on tokens in accordance with the Security and Audit

Requirements and the Key Ceremony Reference Guide. Private keys shall be encrypted during such transfer.

VTN Participants pregenerating private keys and transferring them into a hardware token, for example transferring generated end-user Subscriber private keys into a smart card, shall securely

transfer such private keys into the token to the extent necessary to prevent loss, theft, modification, unauthorized disclosure, or unauthorized use of such private keys.

6.2.7 Method of Activating Private Key

All VTN Participants shall protect the activation data for their private keys against loss, theft, modification, unauthorized disclosure, or unauthorized use.

6.2.7.1 End-User Subscriber Private Keys

This section states the VTN Standards for protecting activation data for end-user Subscribers’

private keys, although Subscribers have the option of using enhanced private key protection mechanisms available today including the use of smart cards, biometric access devices, and other hardware tokens to store private keys.

6.2.7.1.1 Class 1 Certificates

The VTN Standard for Class 1 private key protection is for Subscribers to take commercially reasonable measures for the physical protection of the Subscriber’s workstation to prevent use of the workstation and its associated private key without the Subscriber’s authorization. In

addition, VeriSign recommends that Subscribers use a password in accordance with CP § 6.4.1.1 or security of equivalent strength to authenticate the Subscriber before the activation of the private key, which includes, for instance, a password to operate the private key, a Windows logon or screen saver password, or a network logon password.

6.2.7.1.2 Class 2 Certificates

The VTN Standard for Class 2 Private Key protection is for Subscribers to:

• Use a password in accordance with CP § 6.4.1.1 or security of equivalent strength to authenticate the Subscriber before the activation of the private key, which includes, for instance, a password to operate the private key, a Windows logon or screen saver password, a network logon password, or a password in conjunction with the VeriSign Roaming Service;

and

• Take commercially reasonable measures for the physical protection of the Subscriber’s workstation to prevent use of the workstation and its associated private key without the Subscriber’s authorization.

When deactivated, private keys shall be kept in encrypted form only.

6.2.7.1.3 Class 3 Certificates Other Than Administrator Certificates

The VTN Standard for Class 3 private key protection (other than Administrators) is for Subscribers to:

• Use a smart card, biometric access device, password in conjunction with the VeriSign Roaming Service, or security of equivalent strength to authenticate the Subscriber before the activation of the private key; and

• Take commercially reasonable measures for the physical protection of the Subscriber’s workstation to prevent use of the workstation and its associated private key without the Subscriber’s authorization.

Use of a password along with a smart card or biometric access device in accordance with CP

§ 6.4.1.1 is recommended. When deactivated, private keys shall be kept in encrypted form only.

6.2.7.2 Administrators’ Private Keys (Class 3) 6.2.7.2.1 Administrators

The VTN Standard for Administrators’ private key protection requires them to:

• Use a smart card, biometric access device, password in accordance with CP § 6.4.1.2, or security of equivalent strength to authenticate the Administrator before the activation of the private key, which includes, for instance, a password to operate the private key, a Windows logon or screen saver password, or a network logon password; and

• Take commercially reasonable measures for the physical protection of the Administrator’s workstation to prevent use of the workstation and its associated private key without the Administrator’s authorization.

VeriSign recommends that Administrators use a smart card, biometric access device, or security of equivalent strength along possibly with the use of a password in accordance with CP § 6.4.1.2 to authenticate the Administrator before the activation of the private key.

When deactivated, private keys shall be kept in encrypted form only.

6.2.7.2.2 Managed PKI Administrators using a Cryptographic Module (with Automated Administration or with Managed PKI Key Manager Service)

The VTN Standard for private key protection for Administrators using such a cryptographic module requires them to:

• Use the cryptographic module along with a password in accordance with CP § 6.4.1.2 to authenticate the Administrator before the activation of the private key; and

• Take commercially reasonable measures for the physical protection of the workstation housing the cryptographic module reader to prevent use of the workstation and the private key associated with the cryptographic module without the Administrator’s authorization.

6.2.7.3 Gateway Customers’ Private Keys (Class 1)

The VTN Standard for Gateway Customers private key protection requires them to:

• Use a password (or security of equivalent strength) in accordance with CP § 6.4.1.3 to authenticate the Gateway Customer before the activation of the private key, which is associated with an account with administrator privileges on the Gateway server; and

• Take commercially reasonable measures for the physical protection of the Gateway server to prevent use of the server and the private key associated with the server without the Gateway Customer’s authorization.

Once the private key is activated, the private key can be active for an indefinite period until deactivated when the Gateway CA system goes offline.

6.2.7.4 Private Keys Held by Processing Centers (Class 1-3)

This section applies to a Processing Center’s own CAs and of the CAs of the Client Service Centers, Managed PKI Customers, and ASB Customers within its Subdomain. An online CA’s private key shall be activated by a threshold number of Shareholders, as defined in CP § 6.2.2, supplying their activation data (stored on secure media). Once the private key is activated, the private key may be active for an indefinite period until it is deactivated when the CA goes offline. Similarly, a threshold number of Shareholders shall be required to supply their

activation data in order to activate an offline CA’s private key. Once the private key is activated, it shall be active only for one time.

6.2.8 Method of Deactivating Private Key 6.2.8.1 End-User Subscribers

6.2.8.1.1 Class 1 Certificates No stipulation.

6.2.8.1.2 Class 2 Certificates No stipulation.

6.2.8.1.3 Class 3 Certificates

End-user Subscribers have an obligation to protect their private keys under CP § 6.2.7.1. Such obligations extend to protection of the private key after a private key operation has taken place.

6.2.8.2 Gateway Customers (Class 1) No stipulation

6.2.8.3 Processing Centers (Class 1-3)

This section applies to a Processing Center’s own CAs and of the CAs of the Client Service Centers, Managed PKI Customers, and ASB Customers within its Subdomain. When an online CA is taken offline, the Processing Center’s personnel shall remove the token containing such CA’s private key from the reader in order to deactivate it. With respect to the private keys of offline CAs, after the completion of a Key Generation Ceremony (see CP § 6.1.1) in which such private keys are used for private key operations, the Processing Center’s personnel shall remove the token containing such CAs’ private keys from the reader in order to deactivate them. Once removed from the reader, tokens shall be protected in accordance to the Security and Audit Requirements Guide.

6.2.9 Method of Destroying Private Key

Private keys shall be destroyed in a way that prevents their loss, theft, modification, unauthorized disclosure, or unauthorized use.

6.2.9.1 Gateway Customers (Class 1)

Gateway Customers shall decommission their private keys upon termination of CA operations to prevent loss, theft, modification, unauthorized disclosure, or unauthorized use.

6.2.9.2 Processing Centers (Class 1-3)

Upon termination of the operations of a Processing Center’s CA, or that of a Client Service Center, Managed PKI Customer, or ASB Customer within its Subdomain, Processing Center personnel shall decommission the CA’s private key by deleting it using functionality of the token containing such CA’s private key so as to prevent its recovery following deletion, or the loss, theft, modification, unauthorized disclosure, or unauthorized use of such private key, while not adversely affecting the private keys of other CAs contained on the token. This process shall be witnessed in accordance with the Security and Audit Requirements Guide and the Key

Ceremony Reference Guide.