Documentation

Mistake on this page? Email us

Authenticity Certificate

Authenticity certificate

The authenticity certificate and its fingerprint are used for verifying updates. The authenticity certificate and its fingerprint are stored as a certificate with the fingerprint as the key. See below for details.

The authenticity certificate is a container for a public key that the device trusts. This public key's use is restricted to Device Management Update to compartmentalize and protect Device Management Update in case information about any other key is leaked.

The update authenticity certificate allows the device to verify the authenticity of update manifests. You can also use it to delegate the trust that the device has in the authenticity certificate from this ultimate source of trust to another trusted party.

Generating authenticity certificates

The manifest tool can generate certificates for use in development. This is for convenience in development only. You should not use these generated certificates in a production environment. You should generate certificates for production in accordance with good security practices and use secure processes and HSM hardware when possible.

Verifying update manifests

Before accepting an update, the device's Update client uses public key cryptography to decide whether it trusts the update's author: It verifies the update's manifest using its public key signature (ECDSA with the secp256r1 curve). To trust manifests, the device must therefore trust the public key that it uses to verify the signature. This requires installing the public key on the device at time of manufacture, or in the initially flashed firmware. The device can then make a judgment about whether or not to trust a given manifest based on its trust of the key used to verify the manifest.

Device Management Update expects the public keys to be packaged in a certificate; Device Management Update and the manifest tool use DER certificates.

Ultimate source of trust

For enhanced security, you should change public keys sometimes. To do this, the device needs an ultimate source of trust, typically another public key. This public key corresponds to a high security system that is used to delegate trust to an intermediary.

For example:

  1. A company uses a Hardware Security Module (HSM) to sign developer certificates. The HSM is far more secure than a developer's computer, so there is less concern that it will be compromised.
  2. The developers in possession of the HSM-signed certificate can then sign manifests using their public keys.h.
  3. The device receives the developer certificate without security concerns, because the devices trust the authority of the HSM.

This scheme allows a signer to be someone other than the holder of the public key that the device trusts.

Production devices should use this scheme to ensure that updates are protected from the exposure of developers' private keys.

Currently, Device Management Update does not contain an example of trust delegation. You can implement it by replacing the default arm_uc_registered_certificate_api. To create a certificate for testing purposes, a self-signed certificate is adequate.