[FOTA] Tech key point: repositories role for onboard
最后更新于
最后更新于
The attack on is a clear example of the issue with numerous software updating methods. Systems that rely on single-key code signing and transport layer security (TLS) may still be vulnerable to a variety of assaults since hostile actors may attack the updating system itself. Productions that update systems must be aware that no system is impenetrable and take steps to lessen the effects of any attacks that do occur. Designers can try to make systems resistant to assault by comprehending the objectives of the attacker. Code signing and secure transport are not enough.
Attackers of update systems intend to:
Read the contents of updates to discover confidential information, reverse-engineer firmware, or compare two firmware images to highlight changes between versions and perhaps identify vulnerable code sections.
Deny installation of updates to prevent vehicles from fixing software problems.
Disrupt functionality in the vehicle, denying use of the vehicle or of certain functions.
Control ECUs within the vehicle, and possibly the vehicle itself.
Modify software to execute their own code.
A malicious update could be signed or new patches could be blocked by an attacker who has access to the update system or signing key. It could be challenging, if not impossible, to repair a vehicle after a malicious update has been loaded without replacing the damaged ECU. Therefore, before installing updates, it's crucial to make sure they can be trusted.
To provide this flexibility, Uptane uses two separate data repositories with different signing authorities:
The is a database that contains all of the signed images that an OEM can deploy. Images are signed using offline keys that are signed by a root signing authority. Because offline keys require physical access and can support additional security features such as 2-factor authentication, they are more difficult to compromise remotely.
The takes advantage of the flexibility of online keys for machine-to-machine communication. The director will sign metadata for a particular update campaign instructing the vehicle to install a particular software bundle of software packages. This includes coordinating software updates with multiple ECUs.
The Director repository instructs ECUs as to which images should be installed by producing signed metadata on demand. Unlike the Image repository, it is mostly controlled by automated, online processes. It also consults a private inventory database containing information on vehicles, ECUs, and software revisions. For the inventory database, please refer to the link.
In the Uptane framework, some rules shall be followed:
Public: This interface SHOULD be public;
Encryption: The Director MAY encrypt images for ECUs that require them, either by encrypting on-the-fly or by storing encrypted images on the repository.
For back-end requirements: The Director repository SHALL implement storage that permits an automated service to write generated metadata files.
In order to initialize the repository, an OEM SHOULD perform the following steps:
Set up the storage mechanism according to the directions for the chosen protocol. For example, the OEM might need to set up a ZFS filesystem.
Set up the transport protocol, following the details of the chosen systems. For example, the OEM may need to set up an HTTP server with SSL/TLS enabled.
Set up the private and public APIs to interact over the chosen transport protocol.
Set up the Root, Timestamp, Snapshot, and Targets roles.
If the Director will be serving per-device encrypted images, copy all relevant images from the Image repository.
Initialize the inventory database with the information necessary for the Director repository to perform dependency resolution, or encrypt images per ECU. This information includes:
metadata about all available images for all ECUs on all vehicles;
dependencies and conflicts between images;
ECU keys.
Set up and run the automated process that communicates with Primaries.
The Director repository does not manage images. Therefore, the Director repository SHOULD contain only the Root, Timestamp, Snapshot, and Targets role as illustrated in the following figure:
2.1.3.1 Inventory database (private API)
Some of the private APIs shall be defined in the Director repository:
upload images
update the inventory database
In order to allow automated processes on the Director repository to perform their respective functions, without also allowing any attackers who might compromise the repository to tamper with the inventory database, it is strongly RECOMMENDED that these processes should have some boundaries. That is, the automated processes SHOULD be able to read any record in the database and write new records, but SHOULD NOT be able to update or delete existing records.
2.1.4.1 interacting with primaries (public API)
We SHOULD define a public API for the Director repository so that it is able to send updates to vehicles:
Can be designed to the wishes of the vehicles;
Can use either a push or pull model to send updates to Primaries
In the push and pull model, we SHOULD define the frequency at which Primaries pull updates. There is also no significant difference between these methods when it comes to resistance to denial-of-service (DoS) attacks or flash crowds.
Note, the API SHOULD require authentication.
Sending an update from the Director repository to a Primary requires the following five steps:
The Primary sends its latest vehicle version manifest to the Director repository via an automated process.
The automated process performs a dependency resolution. It reads associated information about this vehicle, such as ECU identifiers and keys, from the inventory database.
It checks that the signatures on the manifest are correct;
Adds the manifest to the inventory database.
using the given manifest, it computes which images SHOULD be installed next by these ECUs.
It SHOULD record the results of this computation on the inventory database so there is a record of what was chosen for installation.
If there is an error at any point of this step, due to incorrect signatures, or anything unusual about the set of updates installed on the vehicle, then the Director repository SHOULD also record it.
Using the results of the dependency resolution, the automated process signs fresh Timestamp, Snapshot, and Targets metadata about the images that SHOULD be installed next by these ECUs.
If the OEM requires it, it MAY encrypt images per ECU, and write them to its storage mechanism.
If there are no images to be installed or updated, then the Targets metadata SHOULD contain an empty set of targets.
The Primary downloads the metadata and image files.
The Image repository differs from the Director repository in a number of ways:
it is managed by human administrators who use offline keys to sign Targets metadata.
it also MAY manage images to suppliers;
it provides the same metadata to all Primaries.
it does not encrypt images per ECU, and it updates its metadata and images relatively infrequently (e.g., every two weeks or monthly).
In order to set up delegations, Image Repo suppliers use the configuration of roles illustrated in the following figure:
There are two important points:
The AUTOX maintains the Root, Timestamp, Snapshot, and Targets roles, with the Targets role delegating images to their respective tier-1 suppliers.
There SHOULD be a delegated Targets role for every tier-1 supplier, so that the Uptane can:
limit the impact of a key compromise.
precisely control which Targets metadata vehicles need to download.
The metadata for each tier-1 supplier(uptane) MAY be signed by the AUTOX. In turn, a tier-1 supplier MAY delegate images to members of its organization, such as supplier C who has delegated a subset of its images to one of its developers, or to its tier-2 suppliers who MAY delegate further to tier-3 suppliers
Every delegation SHOULD be prefixed with the unique name of a tier-1 supplier, so that the filenames of images do not conflict with each other. Other than this constraint, a tier-1 supplier is free to name its images however it likes. For example, it MAY use the convention “supplier-X-ECU-Y-version-Z.img” to denote an image produced by supplier X, for ECU model Y, and with a version number Z.
The AUTOX SHOULD define a public API for Primaries to use when downloading metadata and images to the Image repository. Same, the API SHOULD require authentication.
This chapter will introduce security topics as follows:
PKI and Provisioning
Sign Key
Sign and Verify Progress
Encryption
The FOTA solution uses mutual TLS for transport security and device authentication. This means that:
every device needs to have its own X.509 certificate,
every device needs to have a way to trust the X.509 certificate of the server’s device gateway, and
the server needs to have a way to decide whether it trusts each vehicle’s X.509 certificate.
The vehicle knows it can trust the gateway because each frontend account gets a unique device gateway URL, with its own unique X.509 certificate. We then include that certificate in the credentials.zip you download, and it gets baked into the image as a pinned certificate authority (CA).
The device gateway decides whether to allow a device to connect based on the device’s X.509 certificate. Every frontend account has one or more Fleet Root CAs which are responsible for signing device certificates. When a device connects, your device gateway checks whether its certificate is signed by a trusted Fleet Root CA, and if not, rejects the connection.
Device provisioning, therefore, is simply the process of providing a device with:
an X.509 certificate
that is unique to the vehicle
and is signed by a Fleet Root CA that your frontend account trusts.
In this method, the following steps occur:
Download credentials.zip with the provisioning key inside.
The first time each device comes online, it connects to a special endpoint on the device gateway and says, “Hi, I’m a new device, and I don’t have a TLS certificate yet. Here’s my provisioning key.”
The backend crypto service generates a new keypair and X.509 certificate for the device, signs that certificate with the private Fleet Root CA and sends the whole bundle to the vehicle.
The backend crypto service deletes the vehicle’s private key and the device stores its new keypair and certificate.
Uptane uses four design principles that help to achieve compromise-resilience:
Different types of metadata are signed using different signing keys so that the impact of a key compromise is minimized and does not necessarily affect the security of the whole system;
A threshold number of signatures may be required to sign a metadata file so that a single key compromise is insufficient to publish malicious images;
There must be a way to revoke keys when they are compromised. Keys can be revoked explicitly by publishing new keys to replace old ones, or they can be revoked implicitly by setting expiration timestamps in metadata files;
The use of offline keys can minimize the risk of a key compromise for high-value roles whose compromise can lead to malicious images.
To solve this problem, we use offline keys (In Signing Server) that are not accessible from the repository, to sign all metadata. The offline private/secret keys are protected by the signing server which cannot export any private key to the external storage. Only some signing APIs can be called to sign the data.
Director Repo
The signing process is shown in the following figure in the director repository
The director repository instructs vehicles on what should be installed next, given information about what they have currently installed. This repository uses online keys to sign fresh timestamp, snapshot, and targets metadata for each vehicle that indicates which images from the image repository should be installed next.
Repository administrators SHOULD use offline keys to sign the Root metadata on the Director repository, so attackers cannot tamper with this file after a repository compromise. The Timestamp, Snapshot, and Targets metadata SHOULD be signed using online keys so that an automated process can instantly generate fresh metadata.
Image Repo
On the Image repository, there are two options for signing the Timestamp and Snapshot metadata, each with the opposite trade-off from the other.
In the first option, the OEM uses online keys, meaning automated processes for renewing the Timestamp and Snapshot metadata when new Targets metadata and/or images are available. With this option, fresh metadata can be instantly generated by the automated process. On the other hand, if attackers compromise a supplier’s key as well as the Image repository, they could instantly publish malicious images. If these attackers also compromise the Director repository, then they can execute arbitrary software attacks by selecting these malicious images on the Image repository for installation. Such an attack could also facilitate mix-and-match attacks.
In the second option, the OEM uses offline keys to sign Timestamp and Snapshot metadata, which reduces the risk of attackers immediately publishing malicious images. Here again, though, there is a trade-off, in this case, related to the metadata expiration dates. If the Timestamp and Snapshot metadata expire relatively quickly, then it may be cumbersome to use offline keys to renew their signatures. Yet, if a longer expiration time is used, it would give a man-in-the-middle attacker more time to execute freeze attacks, hence defeating the purpose of the Timestamp role.
There are two types of ECUs. A primary downloads, verifies, and distributes images and metadata to secondaries. A secondary receives them from a primary and installs a new image only if it has been successfully verified against the signed metadata. There are two types of metadata verification designed to accommodate ECUs with different security and cost requirements:
Full verification
Partial verification
Full verification requires checking that the images chosen for installation by the director repository match the same images on the image repository. Primaries always perform full verification in order to protect secondaries from security attacks.
Partial verification requires checking only that the signatures from the director repository are valid. Uptane is designed with automotive requirements in mind, and one of the difficulties in that space is that ECUs requiring OTA updates might have very slow and or memory-limited microcontrollers.
If follow the highest security recommendations, you’ll need to manage several different keys.
Key Name
Purpose
Description
Fleet Root
Device Identity
The private key of your Fleet Root CA. This is used to sign the individual device certificates for your fleet of devices. The backend server can then validate device certificates to ensure that a connecting device is part of your fleet.
Uptane Root
Software Integrity
This key is used to sign the "root" metadata file for your software repository. This file contains information about all the roles that can sign software metadata.
Uptane Targets
Software Integrity
This key is used to sign the "targets" metadata file for software updates. This file contains information about all the valid software files in your software repository.
Uptane Snapshot
Software Integrity
This key is used to sign the "snapshot" metadata file for software updates. This file contains information about all the valid software files in your software repository.
Uptane Timestamp
Software Integrity
This key is used to sign the "timestamp" metadata file for software updates. This file contains information about all the valid software files in your software repository.
Since the Root role keys on the Director repository are not expected to be revoked and replaced often, its metadata file MAY expire after a relatively long time, such as one year.
The Timestamp, Snapshot, and Targets metadata files SHOULD expire relatively quickly, such as in a day, because they are used to indicate whether updated images are available.
For the Image repository, each role MAY use as many keys as is desired, though the greater the impact of key compromise for a given role, then the greater the number of keys that it SHOULD use. Also, a threshold number of keys SHOULD be required, so that a single key compromise is generally insufficient to sign new metadata. To further increase compromise resilience, each key SHOULD be unique across all roles.
Root Role
Since the Root role has the highest impact when its keys are compromised, it SHOULD use a sufficiently large threshold number of keys. Each key MAY belong to a different repository administrator. For example, if there are 8 administrators, then at least 5 keys SHOULD be required to sign the Root metadata file, so that a quorum is required to trust the metadata.
Targets Role
Since the Targets role also has a high impact when its keys are compromised, it SHOULD also use a sufficiently large threshold number of keys. For example, 3 out of 4 keys MAY be required to sign the Targets metadata file.
Timestamp & Snapshot
Since the Timestamp and Snapshot roles have a relatively low impact when its keys are compromised, each role MAY use a small threshold number of keys. For example, each role MAY use 1 out of 2 keys to sign its metadata file.
In the metadata, thresholds can be configured by roles node , which is shown in the follow block.
The Uptane Standard requires all metadata files to have expiration times in order to prevent or limit freeze attacks (refer to appendix). If ECUs know the time, then attackers cannot indefinitely replay outdated metadata, and hence, images. In general, the expiration date for a metadata file depends on how often it is updated. The more frequently it is updated, then the faster it SHOULD expire so that man-in-the-middle attackers are unable to execute freeze attacks for too long. Even if it is not updated frequently, it SHOULD expire after a bounded period of time, so that stolen or lost keys can be revoked and replaced.
Note, Since the Root role keys are expected to be revoked and replaced relatively rarely, its metadata file MAY expire after a relatively long time, such as one year.
The Director could encrypt images for ECUs that require them, either by encrypting on-the-fly or by storing encrypted images on the repository.
The following information is CONDITIONALLY REQUIRED for each image on the Director repository IF that image is encrypted:
Information about filenames, hashes, and file size of the encrypted image.
Information about the encryption method, and other relevant information–for example, a symmetric encryption key encrypted by the ECU’s asymmetric key could be included in the Director repository metadata.
The encryption progress is shown in the following figure:
is a plain image file that is uploaded by the admin;
is a symmetric key, also called ECU key, red key;
The encrypted image is generated by the symmetric algorithm along with the red key and the plain image.
The director repository makes use of the asymmetric public key to encrypt the red key to the black key.
The asymmetric algorithm can be the RSA or ECC.
The public key will encrypt the ECU key to an encrypted key named black key.
The black key is populated into the target metadata as a node, meanwhile, the filename, hash, and file size of the encrypted image shall be recorded in the target metadata too.
The encrypted image is transformed into the image repository by private API calling.
The encryption and decryption process is shown in the following figure:
The vehicle downloads the targets metadata and the encrypted image from the backend.
Parsing the metadata gets the black key.
Decrypting the black key into the red using the asymmetric private key.
Decrypting the encrypted image into the plain image using the symmetric key (ECU key, red key).
By the above introduction, we feel the so important thing is the asymmetric key pair that is required by the ECU key encryption. The asymmetric key shall be provisioned by Chapter 3.1 PKI and Provisioning.
he ECU key encryption. The asymmetric key shall be provisioned by Chapter 3.1 PKI and Provisioning.
A freeze attack is a physical attack method where hackers or attackers use freezing agents or gases to lower the temperature of the target device, causing it to enter an abnormal state or malfunction. This type of attack leverages the effects of temperature changes on hardware and software to disrupt the operation or compromise the security of the targeted device.
Freeze attacks can be directed at various devices and applications, including computers, embedded systems, encryption chips, and more. Here are some potential impacts and targets of freeze attacks:
Clock Vulnerabilities: Lowering the device's temperature can affect the clock speed inside the device, disrupting normal timing and sequencing.
Power Management Interference: Low temperatures may cause battery performance to decrease or impact battery charging and discharging processes.
Encryption Exploitation: Some encryption devices' circuits may exhibit different behaviors under low temperatures, providing attackers an opportunity to exploit encryption algorithms through side-channel attacks or other means.
Electronic Component Failures: Low temperatures may cause electronic components to contract or become brittle, increasing the risk of failures.
To mitigate freeze attacks, several measures can be taken:
Physical Security: Protect devices from unauthorized access and limit physical contact.
Hardware Safeguards: Integrate temperature sensors within devices to detect abnormal temperature changes and trigger alerts or shutdown mechanisms.
Software Monitoring: Monitor the device's temperature state within software. If abnormal temperature is detected, appropriate security measures can be taken, such as disabling critical functions or triggering alerts.
Encryption and Authentication: Ensure devices remain secure against cooling attacks by using encryption and authentication mechanisms.
Freeze attacks are relatively uncommon, but it's still important to consider preventative measures during device design and implementation to ensure proper device functionality and data security.
Uploading and Download: The Director repository SHALL expose an interface for Primaries to upload vehicle version manifests () and download metadata.
This API SHOULD require authentication so that each user is allowed to access only certain information. Examples include , a password, or an API key encrypted over TLS. For additional security, the OEM may use that utilizes more than one authentication method.
Some security systems use online keys, or signing keys that are accessible from the repository, to sign metadata, protecting ECUs from attacks. Unfortunately, the downside of using an online key to sign all metadata is that attackers who compromise the repository can also immediately abuse this key to sign and distribute malware. This is true even if the online key is protected behind a Hardware Security Module (HSM).
If you are using non-OSTree software images, you’ll have to use to manage your metadata. About how to make use of the garage-sign tool, you can refer to
The encryption process is included in the backend referring to , while the decryption process is invoked in the vehicle’s primary ECU. We can find this process in the .
