Security in firmware update

We provide a secure firmware update solution, and our security model describes these responsibilities and relationships within the system.

Definitions

• Trust Anchor: A public key, installed on a device at the time of manufacture, that a device trusts completely for a particular task. You should not replace, revoke or expire Trust Anchors.

• Trust Delegate: A public key, signed by a Trust Anchor, or a Trust Delegate. Ultimately, each chain of delegation must end in a Trust Anchor. You may replace, revoke or expire Trust Delegates at any time.

1. Trust:
   1. At manufacturing time, each device is securely provisioned with one or more public keys that it trusts to update. These are Trust Anchors. Each update is verifiable with a Trust Anchor or a Trust Delegate.
   2. Trust Delegates may delegate further.
2. Manifests:
   1. A block of metadata, called a manifest, describe the update to the Update client.
   2. The update author signs the manifest.
   3. The update author signs the manifest on the update author's computer or on the update author's HSM.
   4. One or more Trust Anchors or Trust Delegates signs the manifest.
   5. The manifest contains:
      1. A digest of the payload.
      2. A UTC timestamp.
      3. The payload location.
      4. The payload digest.
      5. The payload size.
      6. The payload type.
      7. All instructions or parameters for applying the payload.
      8. Any rules that identify whether or not the Update client can use the payload on this device.
3. Payload:
   1. Once downloaded, Device Management Update signs the payload, which the Update client stores either:
      1. On-chip.
      2. Off-chip.
4. Devices:
   1. We recommend that devices enable any read-out protection options that are available in production.
   2. The device has a unique private key.
   3. When a device receives the manifest, it:
      1. Verifies the manifest signature.
      2. Verifies all manifest fields.

Verifying update validity with public key cryptography

The manifest tool and Device Management Update use elliptic curve cryptography (ECC), a type of public key cryptography. In particular, the manifest tool and Device Management Update use the Elliptic Curve Digital Signature Algorithm. This algorithm uses two pieces of information:

• A secret, called the private key.
• A number, called the public key, which corresponds to the secret.

To sign a document, the holder of the private key first computes a hash of the manifest using SHA256 and then transforms that hash using the private key. This new number, called the signature, is appended to the document. Later, anyone with the public key can verify that the signature matches the document by:

1. Computing a hash of the document using SHA256.
2. Transforming the signature back into a hash using the public key.
3. Comparing the computed hash and the signature hash.

If they are the same, then the verifier can be confident that the signer was in possession of the private key. This is because it is a computationally hard problem to determine a private key from a public key, even if you have many examples of a transformation done using the private key.

Public keys are generally packaged inside a certificate, which contains additional information about the public keys and who they belong to. This certificate is also signed, either by another authority (a Certificate Authority) or by itself (a self-signed certificate). A fingerprint, the SHA256 hash of the certificate, generally identifies certificates. Certificates must be ECC secp256r1 DER encoded. We use ECC instead of RSA because of its reduced key size and higher performance on computationally limited platforms. We also recommend that the certificate is signed by an authority the target device trusts.

Note: The certificate created with manifest-tool init is not suitable for production. Do not use it outside testing and development. To create a certificate for production purposes, we recommend that you use an air-gapped computer or hardware security module (HSM). Review security on your manifest signing infrastructure, since it is the core of the security guarantees for Update client.

Firmware authenticity

Authenticity is critical to any operation that can modify the behavior of a device, particularly firmware update. Validating the authenticity of firmware updates helps keep internet-exposed devices doing what their designers intended; failure to validate could lead to compromise or destruction of devices.

A signature provides both integrity and authenticity validation to the firmware. Regardless of authority, if the provided signature matches the firmware, then a device can be confident that the holder of the private keys for the signature has approved the firmware. This prevents impersonating someone when sending firmware to a device or modifying the firmware in transit.

Devices can decide which private keys to trust without knowing the private keys, by trusting the matching certificates. Provided that private keys are adequately protected, it is unlikely the device will install inauthentic firmware.

Authenticity of the manifest

A private key signs the manifest, which creates a signature. The device verifies a manifest's signature using the verification certificate. The manifest only has a valid signature if it was created with the same private key as the verification certificate, implying whoever created it has access to that key. If the signatures match, the Update client trusts the manifest. The device rejects an incorrectly signed manifest.

For more detailed information, see the manifest tool section.

Authenticity of the image

The manifest contains a SHA256 hash of the image. The signed manifest ensures that, regardless of the download method, the Update client can only use the manifest to install a full and unaltered copy of the intended firmware.