OTA Connect Developer Guide

OTA Connect security: The Uptane framework

HERE OTA Connect aligns with the Uptane security framework. Uptane was developed in response to the clear need for a comprehensive security model for automotive updates, and is the first security system that provides serious compromise resilience in that space[1].

Uptane structure

The most important concept in Uptane is that there are two sets of metadata, from separate sources, that must agree with each other and have valid cryptographic signatures.

The first comes from the image Repository[2]. The image repository contains metadata for update packages that are valid install targets, and its metadata is signed by a chain of trust with offline keys.

The second comes from the Director, which controls what updates (selected from the valid install targets) should actually be installed on devices. The Director uses online keys, and is part of the OTA Connect service.

Uptane metadata

The Uptane specification defines several different types of metadata, but the two main files that you need to manage are as follows:

  • root.json:

    This file contains information about all the roles that can sign software metadata.

    To see an example of this metadata, open the sample root.json file from the TUF (The Update Framework) website.

  • targets.json:

    The instance of targets.json in your image repository contains information about all the valid software files.

    As mentioned previously, there are two versions of each metadata file, one in your image repository and one in the Director service.

    The other instance of targets.json is in the Director service. It only contains information about the software files that are included in a specific update. The entries in this file are cross-referenced with the corresponding entries in targets.json for your image repository.

    Basically this comparison is answering the question:

    "Can I be sure that the files in this update really come from my offical software repository?".

    To see an example of this metadata, open the sample targets.json file from the TUF (The Update Framework) website.

Signing updates of system images

OTA Connect manages the Director for you. When you create an update campaign, we update the Director behind the scenes, signing the metadata for each image-device tuple in the campaign.

The keys for the metadata in your image repository should be managed on your side; we provide tooling to help you do just that. When you build a new device, bitbake automatically signs the image for you, using keys that you specify in the build’s local.conf[3]. Your initial key is created by HERE OTA Connect, delivered to you inside your credentials.zip file, and kept online for convenience and bootstrapping; for any production use you should manage the keys for software metadata yourself and store them securely offline[4].

Primary and Secondary ECUs

In the Uptane framework, an ECU is categorized as either a Primary or a Secondary ECU. In most cases, a vehicle has one Primary ECU and several Secondary ECUs. The Primary ECU is responsible for downloading and distributing software to the Secondary ECUs. In many cases, the Telematics Control Unit (TCU) serves the role of Primary ECU. A Primary ECU also verifies and distributes the Uptane-compliant metadata associated with each piece of software.

Secondary ECUs, such as the Transmission or Body control modules, receive the software and should also perform some form of metadata verification. If the ECU has sufficient processing capabilities, it should perform a full verification of the Uptane-compliant metadata, otherwise it should at least perform a partial verification.

To get an overview of the ECUs detected in a device, open the OTA Connect web application and navigate to the device details for the device. This view shows the ECUs grouped according to whether they are Primary and Secondary ECUs.


1. "Uptane is the first compromise-resilient software update security system for the automotive industry.", https://uptane.github.io
2. This image repository is based on TUF (The Update Framework).
3. These keys are packed inside the zip file specified by the SOTA_PACKED_CREDENTIALS line.
4. Proceed with caution! Once you take the key offline, HERE Technologies cannot recover it.