Developer

Resources

Operational Security

There are a number of industry best practices to employ in the protection of the private signing keys. The following are only high level suggestions for how to secure a private signing key. The list below is not exhaustive, nor is it intended as a substitute for having the necessary security expertise to securely deploy a public key infrastructure.

Private root key vs. private signing key security

The nature of private root keys is such that they should be accessed infrequently, only to issue subordinate signing certificates. This is by design and because a compromised private root key forever marginalizes physical security for all the devices that were shipped with its corresponding root certificate. The physical and procedural security for private root keys should be the best possible. The cost and inconvenience of stringent security measures are outweighed by the results of a compromise and manageable by virtue of the infrequency of interactions requiring the private root key.

Conversely, day to day signing operations necessitate that private signing keys be more frequently accessed to generate the necessary signatures. For this reason, signing certificates are given finite life spans (typically less than 2 years) to mitigate any consequences resulting from their compromise. That said, as much operational security as possible should be implemented around signing operations and the way in which private keys are stored, accessed, and used in the issuance of digital signatures.

Store private keys in a hardware token

Tamper-resistant hardware tokens are helpful in the secure storage of private keys in that they never allow the key to be removed. They support only the following operations

  • Input of key data
  • Encryption or signature generation within the token

The keys in such tokens may never be copied by an attacker, even if the attacker has access to the host in which the token is installed. The only way to steal the key is to physically take it within the token. Note however that if an attacker has overrun the host in which the token is installed, they can sign apps until they are discovered and locked out.

Keep private keys offline

Private keys can be stored on a stand-alone system which is not connected to a network. For example, signing operations could take place on an isolated system in a secured facility. Code deemed trustworthy enough to be signed might be physically brought into the secure signing room on removable storage such as a USB Flash drive. (Note that for operations that leverage countersigning, a network connection may be unavoidable.)

Operational security

Good operational security is a must in all cases, and the hosts used for signing should be well managed. For example, web browsers and wireless modems should be disabled. Passwords that protect against access to the private key for signing operations should be long, strong pass phrases. Only a known and limited number of people should have access to the signing operations. Auditable signing procedures, records of signing activity, and access to the signing facility are absolutely required.

Digital signing environments

When considering digital signing for devices, there are two distinct environments with different requirements for the signing services that serve them and different requirements for the handling of root keys and signing keys.

  • Commercial Device Environments - for devices to be delivered to retailers, consumers, or operators for use by end-users running commercial software.
  • Device Development Environments - wherein a manufacturer is developing, building, and testing pre-commercial releases of the device software.

Commercial device environments

For signing in commercial device environments, it is critical that the confidentiality of the private root key and private signing keys be maintained, and that signing operations be strictly controlled to prevent the signing of code not intentionally approved by the signing authority. Commercial environments require that the confidentiality and control of private keys be maintained from the moment they are generated.

Device development environments

In a device development environment, where the current device image is not intended to be shipped in commercial handsets, device manufacturers are able to operate a less secure signing solution with little or no control of private keys and signature generation. In these device development environments, there is little or no concern about the threat of malware or what code is permitted to run on these devices. For this reason, there is no need to implement strong controls around use of the Device Root Private Key or the Signing Certificates in such an environment.

Reasonable care should be taken to prevent these pre-commercial builds including pre-commercial root certificates from being used to re-flash devices already in the field.

Common signing deployment across environments

Because the operational security and private key management requirements are higher for a commercial device environment than for a device development environment, it is practical to use a commercial signing solution for a device development environment. However, it is not practical to extend a device development signing solution into a commercial deployment.

  • Follow