[FOTA] Tech key point: time server
最后更新于
最后更新于
Uptane was born out of the TUF (The Update Framework) and adapted to the overall automotive environment. The design of TUF includes the following four concepts: trust separation, signature threshold, explicit and implicit key revocation mechanisms, and offline protection of critical keys. On the basis of retaining the above four design concepts, Uptane has added four key designs to adapt to client heterogeneity, limited resources, and no trusted communication mechanism between ECUs during the vehicle OTA process.
These four key points designs are:
Num
Describation
1
Based on the design of maintaining a remote software library in TUF, Uptane has added a library and divided the responsibilities of the original software library.
Image Repository: used to store images and image metadata files
Director Repository: used to manage rules of metadata files update.
2
ECU for different hardware resources can perform Full or Partial verification of metadata and image files.
3
Divide the primary (main) ECU and secondary ECU for the onboard. The primary ECU communicates directly with the software upgrade library, and the secondary ECU obtains updates through the primary ECU.
4
Set the Time server to provide time base for ECU that is without a reliable clock source.
This document mainly focuses on the fourth key point (time server for onboard ECU)
For some secure reasons:
Without access to a secure source of time, ECUs may be prevented from receiving the most recent updates. If the ECU’s time is set too far ahead, it will determine that the current valid metadata is expired and thus be unable to perform an update. If the ECU’s time is set too far behind, an attacker can freeze or replay old metadata to the ECU. (ECUs in Uptane will not accept an earlier time than what has been seen before and signed with the same key.) [ref: https://uptane.github.io/papers/uptane-deployment-best-practices-1.1.0.html#secure-source-of-time]
If an ECU does not have a secure clock, the Uptane recommends the use of a Time Server for time. In AUTOX XERO onboard ECU design, the arch is shown in the following figure:
The primary ECU may be the TCU or VDU that is performing the Linux OS. The clock base is from the onboard Real-time clock that is an un-secure clock. So the secure time server shall be deployed for the primary ECU.
The typical Uptane framework includes a Time server to provide a time synchronization service for ECUs without reliable clock signals. The primary ECU interacts with the Image Repository and the Director Repository. The interaction process includes signature verification, metadata verification, and image download. The secondary ECU interacts with the primary ECU, and the primary ECU helps the secondary ECU perform all metadata validation. The secondary ECU performs partial metadata validation under limited conditions.
A Time Server, as the name suggests, is a specialized server that is in charge of giving ECUs that would not otherwise have access to this data a safe source of the current time. Through signed records and an exchange of tokens, it provides information to ECUs in a cryptographically safe method. A list of tokens from vehicles is delivered to the Time Server, which then returns a list of signed records that includes every token from the initial set as well as at least one instance of the current time.
If the Time Server is used, it is CONDITIONALLY REQUIRED to conform to the following requirements:
The Time Server will provide one or more signed responses that include the time and the sequence of tokens it received from the vehicle. It MAY generate numerous signed time attestation documents, each containing the current time and one or more tokens, or a single document containing the current time and all tokens. The response must contain all tokens.
A public interface for communicating with Primaries will be made available via the Time Server. This exchange MAY take place through HTTP, HTTPS (prefer), SFTP, FTP, FTPS, or any other transport control the implementer deems appropriate.
By including the new key in the Director's Root metadata, the Time Server's key is rotated in the same way that other roles' keys are. Additionally, it is specified in the Targets metadata of the Director repository's Secondaries (for partial verification).
The metadata request issuing and downloading progress is shown in the following diagram:
Secondary ECUs issue the ECU version metadata and nonce to the primary ECU;
The primary ECU generates a manifest containing the vehicle version, then the manifest will be transformed into the Director Repo. Meanwhile, the nonce generated by the primary ECU is sent to the Time Server.
The signed time + nonce is returned from the time server. The primary ECU will check the signature.
After the primary ECU verified the signature, the primary ECU will download the metadata from the Director Repo and Image Repo.
In Director repository Root metadata, a representation of a Time Server's public key is CONDITIONALLY REQUIRED if one is operational.
A representation of the public key(s) for the Time Server, similar to the representation of public keys in Root metadata.
Listing the public key of the Time Server in Director Targets metadata is necessary to allow partial verification Secondaries to perform Time Server key rotation.
According to diagram Time Server in the flow, if the Time Server is implemented, the Primary is CONDITIONALLY REQUIRED to use the following procedure to verify the time. This procedure occurs after the vehicle version manifest is sent and will fulfill the Download and check current time step of the Uptane Standard:
The Primary SHALL load the current time from a secure source.
Gather the tokens from each Secondary ECU’s version report.
Send the list of tokens to the Time Server to fetch the current time. The Time Server responds, as described above in the Time Server subsection, by providing a cryptographic attestation of the last known time.
If the Time Server’s response meets the criteria below, update the Primary ECU’s clock and retain the Time Server’s response for distribution to Secondary ECUs. If it fails to meet this criteria, discard the response and continue the procedure without an updated time. The criteria for checking the Time Server’s response are:
The signature over the Time Server’s response is valid.
All the tokens provided to the Time Server are included in the response.
The time in the Time Server’s response is later than the last time verified in this manner.
Each Secondary's ECU version report will include a token that can be provided in any way the implementer decides to the Time Server.
The payload of the ECU version report sent from the Primary to the Director MAY contain the tokens sent to the Time Server, which is shown in the following figure:
In this case, if any token is removed or changed, the signature will not match. To detect a replay attack, each token SHOULD be unique per ECU. There will be sufficient tokens to enable this since the uptane anticipate that these updates will be very frequently (e.g., because of a finite number of write cycles).
ECUs MAY get an attestation of the current time as retrieved from the Time Server once the vehicle has been put assembled. As the first step to verifying metadata, described in the Standard for both the Primary and Secondaries:
5.4.3.1. Load and verify the latest attested time
The ECU SHALL load and verify the current time, or the most recent securely attested time.
5.4.2.2. Download and check current time
The Primary SHALL load the current time from a secure source.
The ECU SHOULD load and verify the most recent time from the Time Server using the following procedure:
Verify that the signatures on the downloaded time are valid.
Verify that the list of tokens in the downloaded time includes the token that the ECU sent in its version report.
Verify that the time downloaded is greater than the previous time.
If all three steps are completed without error, the ECU is CONDITIONALLY REQUIRED to overwrite its current attested time with the time it has just downloaded and to generate a new token for the next request to the Time Server.
5.4.3.6. Create and send version report
The ECU SHALL create a version report as described in Section 5.4.2.1.2, and send it to the Primary (or simply save it to disk, if the ECU is a Primary). The Primary SHOULD write the version reports it receives to disk and associate them with the Secondaries that sent them.
time_srv_get_current_time
time_srv_set_nonce(nonce)
time_srv_get_signed_time(nonce)
time_srv_refresh_key
