From d74cb95bed90dfa719ad88ecf04789cb586c6c06 Mon Sep 17 00:00:00 2001 From: Yasho Bapat <93445114+Yasho-Bapat@users.noreply.github.com> Date: Sat, 20 Apr 2024 12:47:46 +0530 Subject: [PATCH 1/5] Update ecus.md updated with reference to ISO 802.1AR for hardware identifiers and their keys --- ecus.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/ecus.md b/ecus.md index a9ce052..890b6d4 100644 --- a/ecus.md +++ b/ecus.md @@ -36,7 +36,7 @@ Partial verification ECUs are expected to have the Root and Targets metadata pre **Figure 1.** *An arrangement that an OEM SHOULD use when using symmetric ECU keys.* -ECUs are permitted to use either symmetric or asymmetric keys. This choice is effectively a performance vs. security trade-off. Symmetric keys allow for faster cryptographic operations, but expose a larger attack surface because the Director will need online access to the key. Asymmetric ECU keys are not affected by this problem, because the Director only needs access to the ECU's public key. +ECUs are permitted to use either symmetric or asymmetric keys. This choice is effectively a performance vs. security trade-off. Symmetric keys allow for faster cryptographic operations, but expose a larger attack surface because the Director will need online access to the key. Asymmetric ECU keys SHOULD be cryptographically generated (e.g., IEEE 802.1AR and cryptographically verified (e.g., secure hash of the Public Key that is signed with the Private Key) before use in software update processes (see section 8.0.3). Basically, choosing symmetric keys increases the performance of the common case (checking signatures and decrypting images), but makes disaster recovery harder, because a compromised key server could require updating ECU keys on every vehicle. @@ -81,4 +81,4 @@ distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License. ---> \ No newline at end of file +--> From 6d63e1ba8a0c2586158339de66fc21384b79918a Mon Sep 17 00:00:00 2001 From: Yasho Bapat <93445114+Yasho-Bapat@users.noreply.github.com> Date: Sat, 20 Apr 2024 12:55:44 +0530 Subject: [PATCH 2/5] Update repositories.md --- repositories.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/repositories.md b/repositories.md index c2722df..60928b1 100644 --- a/repositories.md +++ b/repositories.md @@ -132,7 +132,7 @@ Unlike the Image repository, the Director repository does not delegate images. T An OEM SHOULD define a private API for the Director repository that is able to: (1) upload images, and (2) update the inventory database. This API is private in the sense that only the OEM should be able to perform these actions. -This API SHOULD require authentication, so that each user is allowed to access only certain information. The OEM is free to use any authentication method as long as it is suitably strong. Examples include [client certificates](https://docs.microsoft.com/en-us/archive/blogs/kaushal/client-certificates-vs-server-certificates), a password, or an API key encrypted over TLS. For additional security, the OEM may use [multi-factor authentication](https://en.wikipedia.org/wiki/Multi-factor_authentication) that utilizes more than one authentication method. +This API SHOULD require authentication, so that each user is allowed to access only certain information. The OEM is free to use any authentication method as long as it is suitably strong. Examples include [client certificates](https://docs.microsoft.com/en-us/archive/blogs/kaushal/client-certificates-vs-server-certificates), a password, or an API key encrypted over TLS. For additional security, the OEM SHOULD use [multi-factor authentication](https://en.wikipedia.org/wiki/Multi-factor_authentication) that utilizes more than one authentication method. Note: Most biometric authentication methods have been successfully attacked and these SHOULD NOT be used in the Private API. 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. @@ -159,7 +159,7 @@ The API MAY require authentication, depending on the OEM's requirements. Sending an update from the Director repository to a Primary requires the following five steps, as shown in Figure 3. 1. The Primary sends its latest vehicle version manifest to the Director repository via an automated process. -2. 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, and adds the manifest to the inventory database. Then, 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, so the OEM can be alerted to a potential risk. Repository administrators MAY then take manual steps to correct the problem, such as instructing the vehicle owner to visit the nearest dealership. +2. The automated process performs a dependency resolution. It reads associated information about this vehicle, such as ECU identifiers and keys (see section 8.0.3), from the inventory database. It checks that the signatures on the manifest are correct, and adds the manifest to the inventory database. Then, 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, so the OEM can be alerted to a potential risk. Repository administrators MAY then take manual steps to correct the problem, such as instructing the vehicle owner to visit the nearest dealership. 3. 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. Optionally, 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. 4. The Primary downloads the metadata and image files. @@ -203,9 +203,9 @@ Every delegation SHOULD be prefixed with the unique name of a tier-1 supplier, s #### Public API to download files -An OEM SHOULD define a public API for Primaries to use when downloading metadata and images to the Image repository. This API can be defined in whatever manner the OEM wishes. +An OEM SHOULD define a Public API for Primaries to use when downloading metadata and images from the Image repository. This API can be defined in whatever manner the OEM wishes. -Depending on the OEM's requirements, this API MAY require authentication before Primaries are allowed to download updates. Such a choice affects only how certain the OEM can be that it is communicating with authentic Primaries, and not how resilient ECUs are to a repository compromise. The OEM is free to use any authentication method. +This Public API SHOULD require authentication before Primaries are allowed to download updates. Such a choice affects only how certain the OEM can be that it is communicating with authentic Primaries, and not how resilient ECUs are to a repository compromise. #### Using images from multiple locations @@ -248,4 +248,4 @@ distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License. ---> \ No newline at end of file +--> From 1f9b2c9a7ca101fcd9d29de5c9e76920b3aaf100 Mon Sep 17 00:00:00 2001 From: Yasho Bapat <93445114+Yasho-Bapat@users.noreply.github.com> Date: Sat, 20 Apr 2024 13:02:38 +0530 Subject: [PATCH 3/5] Update security_considerations.md updated with references to RFC 9393 (regarding CoSWID tags for strong software identifiers) and ISO 802.1AR for strong hardware identifiers --- security_considerations.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/security_considerations.md b/security_considerations.md index 94adb59..b4dbc07 100644 --- a/security_considerations.md +++ b/security_considerations.md @@ -14,23 +14,23 @@ Before an ECU installs a new image, it SHOULD always check the hardware type of Consider the following example in which attackers have compromised the Director repository. If certain mitigating steps have been taken, such as using release counters, they cannot rollback software updates. Furthermore, without an additional key compromise, attackers cannot cause arbitrary software attacks on Primaries and full verification Secondaries. However, attackers can cause the ECUs of one hardware type to install images intended for another hardware type. To use an analogy, this is similar to causing [Linksys](https://www.linksys.com/us/) routers to install images intended for [NetGear](https://www.netgear.com/) routers. -Simply having ECU identifiers (e.g., serial numbers) specified in the Targets metadata signed by the Director repository does not solve this problem because: (1) they are used by the Director repository only to instruct which ECU should install which image, and (2) they are not specified in the Targets metadata signed on the Image repository because it is impractical to list all ECU identifiers that pertain to an image. +Simply having ECU identifiers (see section 8.0.3) specified in the Targets metadata signed by the Director repository does not solve this problem because: (1) they are used by the Director repository only to instruct which ECU should install which image, and (2) they are not specified in the Targets metadata signed on the Image repository because it is impractical to list all ECU identifiers that pertain to an image. -In order to avoid this problem, the custom Targets metadata about unencrypted images on the Image repository SHOULD always include hardware identifiers. A hardware identifier allows an OEM and/or its suppliers to succinctly capture an entire class of ECUs without listing each of their identifiers. Note that the OEM and/or its suppliers SHOULD ensure that hardware identifiers are unique across different hardware types of ECUs, so that attackers who compromise the Director repository cannot cause ECUs of one type to install images intended for another type. +In order to avoid this problem, the custom Targets metadata about unencrypted images on the Image repository SHOULD always include strong hardware identifiers (see section 8.0.3). A strong hardware identifier allows an OEM and/or its suppliers to succinctly capture an entire class of ECUs without listing each of their identifiers. Note that the OEM and/or its suppliers SHOULD ensure that hardware identifiers are unique across different hardware types of ECUs, so that attackers who compromise the Director repository cannot cause ECUs of one type to install images intended for another type. ### Integrating software supply chain security into Uptane -As new legislation emerges in the wake of several high profile supply chain attacks, automakers need to consider implementing more effective end-to-end security measures for software. Both the UNECE WP.29 regulations that went into effect in some parts of the world in June 2020, and the ISO/SAE 21434 Standard published in the summer of 2021 require OEMs to ensure that the entire automotive supply chain is secure. In the United States, [Executive Order 14028](https://www.whitehouse.gov/briefing-room/presidential-actions/2021/05/12/executive-order-on-improving-the-nations-cybersecurity/) observes that "The development of commercial software often lacks transparency, sufficient focus on the ability of the software to resist attack, and adequate controls to prevent tampering by malicious actors," and calls for a concerted effort to correct this situation. +As new legislation emerges in the wake of several high profile supply chain attacks, automakers need to consider implementing more effective end-to-end security measures for software. The UNECE WP.29 regulations R155 and R156 that went into effect in Europe and many other countries in June 2020, the ISO/SAE 21434 Standard published in August 2021, and the ISO 24089 Standard published in February 2023 require OEMs to ensure that the entire automotive supply chain is secure. In the United States, [Executive Order 14028](https://www.whitehouse.gov/briefing-room/presidential-actions/2021/05/12/executive-order-on-improving-the-nations-cybersecurity/) observes that "The development of commercial software often lacks transparency, sufficient focus on the ability of the software to resist attack, and adequate controls to prevent tampering by malicious actors," and calls for a concerted effort to correct this situation. There are a number of complementary supply chain security technologies that might be adapted for these purposes. The [in-toto](https://in-toto.io/) framework is a common link between a number of these efforts. The framework breaks down the software supply chain into a series of steps, each of which has a “functionary,” human or otherwise, authorized to perform it. A policy is defined for each supply chain and it is then cryptographically signed by the supply chain owner. As each functionary performs its task, it captures separate signed metadata that documents the artifacts involved. The metadata is then validated against the policy, ensuring only authorized actions or operations were performed in the supply chain. in-toto has already been successfully adopted or integrated into several major open source software projects, including those hosted by the Cloud Native Computing Foundation, a part of the Linux Foundation. It has already been used in tandem with The Update Framework (TUF) to provide both end-to-end security and compromise resilience for [Datadog](https://www.datadoghq.com/blog/engineering/secure-publication-of-datadog-agent-integrations-with-tuf-and-in-toto/). Using this integration as a guide, the Uptane community published [Scudo](https://uptane.github.io/papers/scudo-whitepaper.pdf), a whitepaper that describes how to use in-toto and Uptane together to provide security guarantees for the development _and_ delivery of automotive software. A [Proposed Uptane Revision and Enhancement (PURE)](https://github.com/uptane/pures) describing [Scudo's implementation details](https://github.com/uptane/pures/blob/main/pure3.md) was accepted on 2/28/23. -### Secure alternatives to conventional software and identifiers +### Secure alternatives to conventional software and hardware identifiers Having an unambiguous way to reference all of its components is a crucial attribute within any system. Therefore, taking a closer look at a system’s identifiers—both hardware and software—can be a worthwhile investment in enhancing system security. A system that lacks a standardized and widely accepted system of identifying components presents a potential vulnerability that can impact both the efficiency and reliability of operations. Thus, designers, suppliers, and OEMs have come to realize that the identifiers used for both the hardware or software element on a vehicle are not trivial details. Despite the emergence of alternative ECU and software ID strategies, the utilization of VIN numbers, often as the only hardware identifier on a vehicle, is still all too common a practice. Uptane recognizes the need to adopt stronger identifiers, and future versions of this document will present strategies for upgrading the security and reliability of both ECU and software IDs. In both cases, we will consult and comply with the latest regulations and international standards. For ECU IDs, any design proposals will likely follow the example presented in the [IEEE Standard 802.1AR Device Identity](https://1.ieee802.org/security/802-1ar/), which specifies “Secure Device Identifiers (DevIDs) designed to be used as interoperable secure device authentication credentials with Extensible Authentication Protocol (EAP) and other industry standard authentication and provisioning protocols.” The document makes the case that utilizing a standardized device identity makes the authentication of interoperable secure devices easier, and simplifies secure device deployment and management. -For software ID tags any proposed actions will likely be guided by the Internet Engineering Task Force’s in-process Standard on [Concise Software Identification Tags](https://datatracker.ietf.org/doc/draft-ietf-sacm-coswid/). This Standard describes a new type of Software Identification (SWID) tag that “supports a similar set of semantics and features as SWID tags, as well as new semantics” that “allow the tags to describe additional types of information, all in a more memory efficient format.” The “Co” in CoSWID stands for concise, as it significantly reduces the amount of data transported as compared to a typical SWID tag. To make this happen, CoSWIDs use the technique of Concise Binary Object Representation (CBOR), first defined in [RFC8949](https://datatracker.ietf.org/doc/html/rfc8949). According to [Wikipedia](https://en.wikipedia.org/wiki/CBOR), CBOR “is a binary data serialization format loosely based on JSON” that “allows the transmission of data objects that contain name–value pairs, but in a more concise manner.” Though this increases processing and transfer speeds at the cost of human readability, the process is designed to automate a task that previously would require human intervention. Therefore, any trade-off in the readability of content would be negligible compared to the enhanced security value. +For software ID tags any proposed actions will likely be guided by the [Internet Engineering Task Force’s Standard on Concise Software Identification Tags (RFC 9393)](https://datatracker.ietf.org/doc/rfc9393/) published in June 2023. This Standard describes a new type of Software Identification (SWID) tag that “supports a similar set of semantics and features as SWID tags, as well as new semantics” that “allow the tags to describe additional types of information, all in a more memory efficient format.” The “Co” in CoSWID stands for concise, as it significantly reduces the amount of data transported as compared to a typical SWID tag. To make this happen, CoSWIDs use the technique of Concise Binary Object Representation (CBOR), first defined in [RFC8949](https://datatracker.ietf.org/doc/html/rfc8949). According to [Wikipedia](https://en.wikipedia.org/wiki/CBOR), CBOR “is a binary data serialization format loosely based on JSON” that “allows the transmission of data objects that contain name–value pairs, but in a more concise manner.” Though this increases processing and transfer speeds at the cost of human readability, the process is designed to automate a task that previously would require human intervention. Therefore, any trade-off in the readability of content would be negligible compared to the enhanced security value. At this point, Uptane is not planning any imminent change in its Standard to mandate what qualifies as secure hardware or software identifiers, but we do strongly suggest adopters consider alternatives beyond just VIN numbers. Given the growing desirability of automotive systems as targets of hacking, identity is too important for security to trust to just a part number. From 329cd4286e951a31d0d2768d98bd265bb1b26f5b Mon Sep 17 00:00:00 2001 From: Yasho Bapat <93445114+Yasho-Bapat@users.noreply.github.com> Date: Tue, 23 Apr 2024 19:16:01 +0530 Subject: [PATCH 4/5] Update ecus.md --- ecus.md | 1 + 1 file changed, 1 insertion(+) diff --git a/ecus.md b/ecus.md index 890b6d4..8896d3b 100644 --- a/ecus.md +++ b/ecus.md @@ -13,6 +13,7 @@ To bootstrap an Uptane-capable ECU, a few things need to be provisioned into the * **A secure way to know what time it is**, so the ECU cannot be tricked into accepting expired metadata. The ECU must receive a fairly recent time as soon as it is powered on (or reset to factory settings) to prevent the possibility of freeze attacks. * **ECU key(s)**, to sign the ECU's [version reports](https://uptane.github.io/papers/uptane-standard.2.0.0.html#version_report), and optionally to decrypt images. These signing keys should be unique to the ECU, and the public keys will need to be stored in the Director repository's inventory database. * **Information about repository locations**, generally in the form of a [repository mapping file](https://uptane.github.io/papers/uptane-standard.2.0.0.html#repo_mapping_meta). This is a metadata file that tells the ECU the URIs of the repositories (if it is a Primary ECU), as well as which images should be fetched from which repository. (Images that are encrypted or customized per-device would generally come from the Director repository, and all others from the Image repository.) +* **A strong, unique hardware identifier**, to identify itself to the director and inventory repositories (see section 8.0.3). ## ECU implementation choices From 436dddd9296ec2d6be13e67653f1293777a8e3c5 Mon Sep 17 00:00:00 2001 From: Yasho Bapat <93445114+Yasho-Bapat@users.noreply.github.com> Date: Tue, 23 Apr 2024 19:29:14 +0530 Subject: [PATCH 5/5] Update security_considerations.md --- security_considerations.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/security_considerations.md b/security_considerations.md index b4dbc07..cb55ff5 100644 --- a/security_considerations.md +++ b/security_considerations.md @@ -28,7 +28,7 @@ in-toto has already been successfully adopted or integrated into several major o ### Secure alternatives to conventional software and hardware identifiers Having an unambiguous way to reference all of its components is a crucial attribute within any system. Therefore, taking a closer look at a system’s identifiers—both hardware and software—can be a worthwhile investment in enhancing system security. A system that lacks a standardized and widely accepted system of identifying components presents a potential vulnerability that can impact both the efficiency and reliability of operations. Thus, designers, suppliers, and OEMs have come to realize that the identifiers used for both the hardware or software element on a vehicle are not trivial details. Despite the emergence of alternative ECU and software ID strategies, the utilization of VIN numbers, often as the only hardware identifier on a vehicle, is still all too common a practice. -Uptane recognizes the need to adopt stronger identifiers, and future versions of this document will present strategies for upgrading the security and reliability of both ECU and software IDs. In both cases, we will consult and comply with the latest regulations and international standards. For ECU IDs, any design proposals will likely follow the example presented in the [IEEE Standard 802.1AR Device Identity](https://1.ieee802.org/security/802-1ar/), which specifies “Secure Device Identifiers (DevIDs) designed to be used as interoperable secure device authentication credentials with Extensible Authentication Protocol (EAP) and other industry standard authentication and provisioning protocols.” The document makes the case that utilizing a standardized device identity makes the authentication of interoperable secure devices easier, and simplifies secure device deployment and management. +Uptane recognizes the need to adopt stronger identifiers, and future versions of this document will present strategies for upgrading the security and reliability of both ECU and software IDs. In both cases, we will consult and comply with the latest regulations and international standards. For strong ECU IDs, any design proposals will likely follow the example presented in the [IEEE Standard 802.1AR Device Identity](https://1.ieee802.org/security/802-1ar/), which specifies “Secure Device Identifiers (DevIDs) designed to be used as interoperable secure device authentication credentials with Extensible Authentication Protocol (EAP) and other industry standard authentication and provisioning protocols.” The document makes the case that utilizing a standardized device identity makes the authentication of interoperable secure devices easier, and simplifies secure device deployment and management. For software ID tags any proposed actions will likely be guided by the [Internet Engineering Task Force’s Standard on Concise Software Identification Tags (RFC 9393)](https://datatracker.ietf.org/doc/rfc9393/) published in June 2023. This Standard describes a new type of Software Identification (SWID) tag that “supports a similar set of semantics and features as SWID tags, as well as new semantics” that “allow the tags to describe additional types of information, all in a more memory efficient format.” The “Co” in CoSWID stands for concise, as it significantly reduces the amount of data transported as compared to a typical SWID tag. To make this happen, CoSWIDs use the technique of Concise Binary Object Representation (CBOR), first defined in [RFC8949](https://datatracker.ietf.org/doc/html/rfc8949). According to [Wikipedia](https://en.wikipedia.org/wiki/CBOR), CBOR “is a binary data serialization format loosely based on JSON” that “allows the transmission of data objects that contain name–value pairs, but in a more concise manner.” Though this increases processing and transfer speeds at the cost of human readability, the process is designed to automate a task that previously would require human intervention. Therefore, any trade-off in the readability of content would be negligible compared to the enhanced security value.