Note
|
We recommend that you view this article in our documentation portal. Not all of our articles render correctly in GitHub. |
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.
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 intargets.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.
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].
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.
SOTA_PACKED_CREDENTIALS
line.