Documentation

Mistake on this page? Email us
Docs › Updating device firmware › Device Management Update concepts › Update-related client concepts

Update-related client concepts

To enable the client (Device Management Client and Client Lite) to verify that firmware updates Device Management sends are compatible with the device and authenticate the firmware manifest, you must provide the client with:

These identifiers are publicly accessible and do not constitute an identity in themselves.

For information about additional FOTA-related configuration, see advanced configuration options.

Unique identifiers

To check compatibility of a firmware update with the device, the client uses these unique identifiers:

  • Vendor ID - Identifies the device manufacturer.
  • Class ID - Identifies the device model.

We recommend using RFC-4122 Type 5 UUIDs for these values.

Vendor ID

We recommend deriving the vendor ID from the manufacturer's domain name using the algorithm in RFC-4122, Section 4.3.

Class ID

We recommend:

  • The device class ID conforms to RFC-4122, Type 5.
  • You use the vendor ID as the namespace. The ID within the namespace is arbitrary.
  • You use a model name and revision number as the ID.

How to use Vendor ID and Class ID

When the device receives a manifest, it verifies the unique identifiers to ensure compatibility of the firmware.

When the device connects to Device Management, Device Management receives and stores these parameters. Operators can then create device filters to find specific device types.

Together, these act as a "double check" of firmware compatibility - through accurate cloud-based targeting using filters and a final check by the device before downloading and installing the firmware.

Authenticity certificate

Update client requires the verification certificate for authorizing updates.

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.

Generating authenticity certificates

The manifest tool can generate certificates for use in development, but 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 the time of manufacture, or in the initially flashed firmware. The device can then make a judgement about whether or not to trust a given manifest based on its trust of the key used to verify the manifest.

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

Update storage in the Update client

To store the update image, the Update client uses block device storage, which can be mapped to an internal or external flash. If the update image is stored in an external flash, the image can be encrypted with a symmetric key.

You must make sure the bootloader has been compiled to use block device storage.

There are reference Update clients and compatible bootloaders for a number of platforms available from the Update client and bootloader repositories.

Previous Next