├── _config.yml ├── .gitignore ├── Dockerfile-CI ├── Dockerfile ├── .github └── workflows │ └── main.yml ├── ci-entrypoint.sh ├── SECURITY.md ├── CONTRIBUTING.md ├── Makefile ├── README.md ├── LICENSE ├── uptane-standard.md └── release-artifacts └── ieee-isto-6100.1.0.0.uptane-standard.html /_config.yml: -------------------------------------------------------------------------------- 1 | theme: jekyll-theme-slate -------------------------------------------------------------------------------- /.gitignore: -------------------------------------------------------------------------------- 1 | *.xml 2 | *.html 3 | *.txt 4 | -------------------------------------------------------------------------------- /Dockerfile-CI: -------------------------------------------------------------------------------- 1 | FROM uptane/rfc2629 2 | 3 | RUN apk add git make 4 | 5 | ADD ci-entrypoint.sh /entrypoint.sh 6 | ENTRYPOINT ["/entrypoint.sh"] 7 | -------------------------------------------------------------------------------- /Dockerfile: -------------------------------------------------------------------------------- 1 | FROM ruby:alpine 2 | 3 | RUN apk add py-setuptools py-six py-requests py3-pip \ 4 | && pip install xml2rfc \ 5 | && gem install kramdown-rfc2629 6 | -------------------------------------------------------------------------------- /.github/workflows/main.yml: -------------------------------------------------------------------------------- 1 | name: 'Uptane Standard CI Job' 2 | 3 | on: 4 | push: 5 | branches: 6 | - master 7 | 8 | jobs: 9 | build: 10 | runs-on: ubuntu-latest 11 | steps: 12 | - name: Build and publish artifacts 13 | env: 14 | ACCESS_TOKEN: ${{ secrets.GITHUB_ACCESS_TOKEN }} 15 | uses: docker://uptane/uptane-standard-ci 16 | -------------------------------------------------------------------------------- /ci-entrypoint.sh: -------------------------------------------------------------------------------- 1 | #!/bin/sh 2 | 3 | set -e 4 | 5 | if [ -z "$ACCESS_TOKEN" ] 6 | then 7 | echo "Error: Needs an access token with commit rights to uptane/uptane-standard set as ACCESS_TOKEN." 8 | exit 1 9 | fi 10 | 11 | git config --global user.email "noreply@uptane.github.io" && \ 12 | git config --global user.name "Uptane CI" && \ 13 | 14 | git clone "https://${ACCESS_TOKEN}@github.com/uptane/uptane-standard.git" && \ 15 | cd uptane-standard && \ 16 | make html plaintext && \ 17 | mkdir build_tmp && \ 18 | mv uptane-standard.html uptane-standard.txt uptane-standard.xml build_tmp/ && \ 19 | git checkout gh-pages && \ 20 | mv build_tmp/* . && \ 21 | git commit -am "Rendered documents from commit $(git rev-parse master)" --quiet && \ 22 | git push origin gh-pages && \ 23 | echo "Deployment succesful!" 24 | -------------------------------------------------------------------------------- /SECURITY.md: -------------------------------------------------------------------------------- 1 | # Security Policy 2 | 3 | The Uptane community is committed to maintaining a reliable and consistent Standard. If you believe you have identified errata—including security issues—in the Uptane Standard, please follow these guidelines for responsible disclosure. 4 | 5 | ## Supported Versions 6 | 7 | We release updates to the Uptane specification to address errata. You may report errata for the most recent version of the Uptane Standard. We will not retroactively make changes to older versions. 8 | 9 | ## Reporting Errata 10 | 11 | Please report (suspected) errata in the specification. You can create an issue in the appropriate repository or send feedback directly to our mailing list at uptane-standards [at] googlegroups [dot] com. 12 | 13 | ## Guidelines 14 | 15 | We're committed to working with security researchers to resolve errata they discover. You can help us by following these guidelines: 16 | 17 | * Please give as much detail as possible for a suspected errata in Uptane including: 18 | * Version in which it was found 19 | * Description of errata 20 | * Examples (if applicable) 21 | * We are committed to acknowledging the contributions of security researchers (if desired) 22 | * If you have found a vulnerability related to a certain vendor's implementation of the Uptane standard, please report it directly to that solution provider 23 | -------------------------------------------------------------------------------- /CONTRIBUTING.md: -------------------------------------------------------------------------------- 1 | ## Contributing 2 | 3 | The standard is being written in [RFC 2629](https://tools.ietf.org/html/rfc2629)/[RFC 7749](https://tools.ietf.org/html/rfc7749) format, using Markdown as a source. Comments, issues, and pull requests are welcome. 4 | 5 | We use [GitHub Flow](https://guides.github.com/introduction/flow/) for contributing content. When you are working on a section, make a branch off the current master, and submit a pull request when it's ready to merge. If GitHub reports any merge conflicts in the PR, please rebase until the merge can be done cleanly. 6 | 7 | ### Commit messages and squashes 8 | 9 | Use clear, informative commit messages, and squash any minor commits that do not represent an actual contribution of content (e.g. typo fixes). It is not necessary to squash all your commits when submitting a PR, but please try to keep the commit history reasonably clean. 10 | 11 | ### Text formatting 12 | 13 | Don't use fixed-width columns. The `plaintext` rendering target will produce a text file with fixed-width columns; using fixed-width columns in the Markdown source just makes the diffs harder to read. 14 | 15 | ### Style guide 16 | 17 | Capitalize proper nouns and titles of things, such as the names of roles, repositories, and specific types of metadata. Do not capitalize the words role, repository, and metadata, however. For example, write "Targets role" and "Director repository." 18 | 19 | For headings and sub-headings, capitalize only the first word in a heading UNLESS the heading contains a proper noun. 20 | 21 | Do not hyphenate the adjectival phrase "partial verification Secondary". 22 | 23 | Use American English spellings (i.e. write "color" instead of "colour" and "artifacts" instead of "artefacts"). 24 | 25 | Links to the Standard (from outside the Standard) should point to the latest rendered released version. It is preferred to link by section name, not number, as the numbers tend to change more than the names. Internal links within the Standard should use the standard cross-link syntax. 26 | 27 | Links to the Deployment Best Practices should point to the [deployed web pages](https://uptane.github.io/deployment-considerations/index.html). 28 | 29 | When referring to actions in the Standard that require compliance, the word SHALL will be used, rather than the word MUST. 30 | -------------------------------------------------------------------------------- /Makefile: -------------------------------------------------------------------------------- 1 | .PHONY: clean help html xml open plaintext html-docker xml-docker open-docker plaintext-docker 2 | .DEFAULT_GOAL := help 3 | 4 | OPEN=$(word 1, $(wildcard /usr/bin/xdg-open /usr/bin/open /bin/echo)) 5 | MKD := uptane-standard.md 6 | HTML := uptane-standard.html 7 | RAWHTML := uptane-standard-raw.html 8 | XML := uptane-standard.xml 9 | TXT := uptane-standard.txt 10 | RAWTXT := uptane-standard.raw.txt 11 | 12 | clean: ## Remove the generated files 13 | @rm -rf $(HTML) $(XML) $(TXT) .refcache/ 14 | 15 | help: ## Print this message and exit 16 | @echo "\033[1;37mRequires Docker or 'gem install kramdown-rfc2629' and 'apt-get install xml2rfc'\033[0m" 17 | @awk 'BEGIN {FS = ":.*?## "} /^[0-9a-zA-Z_-]+:.*?## / {printf "\033[36m%s\033[0m : %s\n", $$1, $$2}' $(MAKEFILE_LIST) \ 18 | | column -s ':' -t 19 | 20 | open: html ## Create an HTML version from the markdown, then open it in a browser 21 | @$(OPEN) $(HTML) 22 | 23 | html: xml ## Create an HTML version from the markdown 24 | @xml2rfc --v2 --html --out=$(RAWHTML) $(XML) 25 | @mv $(HTML) $(RAWHTML) 26 | @cat $(RAWHTML) |sed '//,/<\/table>/d;/

/,/except as an Internet-Draft.<\/p>/d' > $(HTML) 27 | @rm $(RAWHTML) 28 | 29 | xml: ## Create an XML version from the markdown 30 | @kramdown-rfc2629 -v2 $(MKD) > $(XML) 31 | 32 | plaintext: xml ## Create an RFC plaintext version from the markdown 33 | @xml2rfc --v2 --out=$(RAWTXT) --raw $(XML) 34 | @cat $(RAWTXT) |sed '/Status of This Memo/,/may not be published except as an Internet-Draft/d' |tail -n +10 > $(TXT) 35 | @rm $(RAWTXT) 36 | 37 | open-docker: html-docker ## Create an HTML version from the markdown using docker, then open it in a browser 38 | @$(OPEN) $(HTML) 39 | 40 | html-docker: xml-docker ## Create an HTML version from the markdown, using docker 41 | @docker run --rm -it -w /workdir -v $(PWD):/workdir uptane/rfc2629 xml2rfc --v2 --html --out=$(RAWHTML) $(XML) 42 | @cat $(RAWHTML) |sed '/

/,/<\/table>/d;/

/,/except as an Internet-Draft.<\/p>/d' > $(HTML) 43 | @rm $(RAWHTML) 44 | 45 | xml-docker: ## Create an XML version from the markdown, using docker 46 | @docker run --rm -it -w /workdir -v $(PWD):/workdir uptane/rfc2629 kramdown-rfc2629 -2 $(MKD) > $(XML) 47 | 48 | plaintext-docker: xml-docker ## Create an RFC plaintext version from the markdown, using docker 49 | @docker run --rm -it -w /workdir -v $(PWD):/workdir uptane/rfc2629 xml2rfc --v2 --out=$(RAWTXT) --raw $(XML) 50 | @cat $(RAWTXT) |sed '/Status of This Memo/,/may not be published except as an Internet-Draft/d' |tail -n +10 > $(TXT) 51 | @rm $(RAWTXT) 52 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # Uptane Standard 2 | 3 | [Uptane](https://uptane.org) is the first compromise-resilient software update security system for the automotive industry. In 2018, a working group under [IEEE-ISTO](https://ieee-isto.org/) began the process of describing the system's design, implementation, and deployment as a formal standard. On July 31, 2019 IEEE/ISTO released *IEEE-ISTO 6100.1.0.0: Uptane Standard for Design and Implementation* (see link below under documentation). Uptane is now a [Linux Foundation Joint Development Foundation](http://www.jointdevelopment.org/) project. The most recent version of the Standard [version 2.1.0](https://uptane.org/docs/standard/uptane-standard) was released on June 27, 2023. 4 | 5 | This repository is the public home of all standardization work for Uptane. 6 | 7 | As the Standard is a living document, updates are made in real time as needed. However, these changes will not be considered formally adopted until the release of the next minor or major version. 8 | 9 | Major and minor release dates are set by the Uptane Standards committee. All final releases will be approved by the committee, either by voice vote at a designated bimonthly meeting of the Uptane Standard group or by responding "approve" in a designated mailing list or repository thread. A release will be deemed approved if it receives a simple majority of positive responses by active group members. "Active" here is defined as an individual who regularly appears at bimonthly meetings, or participates in the preparation or review of pull requests, or engages in discussion of issues on the mailing list threads. Upcoming votes will be announced at least two weeks prior to taking or finalizing votes. 10 | 11 | ## Existing documentation 12 | 13 | The Uptane Standards document should be considered the authoritative resource for the framework. Several other documents and materials are available or currently in development. The information in all of these other guidelines should be viewed as complementary to the official Uptane Standard, and as recommendations rather than mandatory instructions. 14 | 15 | * [Uptane Standard v.2.1.0](https://uptane.org/docs/2.1.0/standard/uptane-standard) 16 | * [Deployment Best Practices v.2.1.0](https://uptane.org/docs/2.1.0/deployment/best-practices) 17 | * [Uptane POUF (Protocols, Operations, Usage, and Formats) Guidelines](https://uptane.org/enhancements/pouf/pouf-main) 18 | * [Example POUF](https://uptane.org/docs/enhancements/pouf/pouf1) 19 | 20 | ## Building/rendering the document 21 | 22 | We use [kramdown-rfc2629](https://github.com/cabo/kramdown-rfc2629) to render the Markdown source into xml, and [xml2rfc](https://xml2rfc.tools.ietf.org/) to render the XML into HTML or plaintext. A Makefile is included for convenience. You can also render using [Docker](https://www.docker.com/) if you don't wish to install the tools. See `make help` for options. 23 | 24 | -------------------------------------------------------------------------------- /LICENSE: -------------------------------------------------------------------------------- 1 | # Community Specification License 1.0 2 | 3 | **The Purpose of this License.** This License sets forth the terms under which 1) Contributor will participate in and contribute to the development of specifications, standards, best practices, guidelines, and other similar materials under this Working Group, and 2) how the materials developed under this License may be used. It is not intended for source code. Capitalized terms are defined in the License’s last section. 4 | 5 | **1. Copyright.** 6 | 7 | **1.1. Copyright License.** Contributor grants everyone a non-sublicensable, perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable (except as expressly stated in this License) copyright license, without any obligation for accounting, to reproduce, prepare derivative works of, publicly display, publicly perform, and distribute any materials it submits to the full extent of its copyright interest in those materials. Contributor also acknowledges that the Working Group may exercise copyright rights in the Specification, including the rights to submit the Specification to another standards organization. 8 | 9 | **1.2. Copyright Attribution.** As a condition, anyone exercising this copyright license must include attribution to the Working Group in any derivative work based on materials developed by the Working Group. That attribution must include, at minimum, the material’s name, version number, and source from where the materials were retrieved. Attribution is not required for implementations of the Specification. 10 | 11 | **2. Patents.** 12 | 13 | **2.1. Patent License.** 14 | 15 | **2.1.1. As a Result of Contributions.** 16 | 17 | **2.1.1.1. As a Result of Contributions to Draft Specifications.** Contributor grants Licensee a non-sublicensable, perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable (except as expressly stated in this License) license to its Necessary Claims in 1) Contributor’s Contributions and 2) to the Draft Specification that is within Scope as of the date of that Contribution, in both cases for Licensee’s Implementation of the Draft Specification, except for those patent claims excluded by Contributor under Section 3. 18 | 19 | **2.1.1.2. For Approved Specifications.** Contributor grants Licensee a non-sublicensable, perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable (except as expressly stated in this License) license to its Necessary Claims included the Approved Specification that are within Scope for Licensee’s Implementation of the Approved Specification, except for those patent claims excluded by Contributor under Section 3. 20 | 21 | **2.1.2. Patent Grant from Licensee.** Licensee grants each other Licensee a non-sublicensable, perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable (except as expressly stated in this License) license to its Necessary Claims for its Implementation, except for those patent claims excluded under Section 3. 22 | 23 | **2.1.3. Licensee Acceptance.** The patent grants set forth in Section 2.1 extend only to Licensees that have indicated their agreement to this License as follows: 24 | 25 | **2.1.3.1. Source Code Distributions.** For distribution in source code, by including this License in the root directory of the source code with the Implementation; 26 | 27 | **2.1.3.2. Non-Source Code Distributions.** For distribution in any form other than source code, by including this License in the documentation, legal notices, via notice in the software, and/or other written materials provided with the Implementation; or 28 | 29 | **2.1.3.3. Via Notices.md.** By issuing pull request or commit to the Specification’s repository’s Notices.md file by the Implementer’s authorized representative, including the Implementer’s name, authorized individual and system identifier, and Specification version. 30 | 31 | **2.1.4. Defensive Termination.** If any Licensee files or maintains a claim in a court asserting that a Necessary Claim is infringed by an Implementation, any licenses granted under this License to the Licensee are immediately terminated unless 1) that claim is directly in response to a claim against Licensee regarding an Implementation, or 2) that claim was brought to enforce the terms of this License, including intervention in a third-party action by a Licensee. 32 | 33 | **2.1.5. Additional Conditions.** This License is not an assurance (i) that any of Contributor’s copyrights or issued patent claims cover an Implementation of the Specification or are enforceable or (ii) that an Implementation of the Specification would not infringe intellectual property rights of any third party. 34 | 35 | **2.2. Patent Licensing Commitment.** In addition to the rights granted in Section 2.1, Contributor agrees to grant everyone a no charge, royalty-free license on reasonable and non-discriminatory terms to Contributor’s Necessary Claims that are within Scope for: 36 | 1) Implementations of a Draft Specification, where such license applies only to those Necessary Claims infringed by implementing Contributor's Contribution(s) included in that Draft Specification, and 37 | 2) Implementations of the Approved Specification. 38 | 39 | This patent licensing commitment does not apply to those claims subject to Contributor’s Exclusion Notice under Section 3. 40 | 41 | **2.3. Effect of Withdrawal.** Contributor may withdraw from the Working Group by issuing a pull request or commit providing notice of withdrawal to the Working Group repository’s Notices.md file. All of Contributor’s existing commitments and obligations with respect to the Working Group up to the date of that withdrawal notice will remain in effect, but no new obligations will be incurred. 42 | 43 | **2.4. Binding Encumbrance.** This License is binding on any future owner, assignee, or party who has been given the right to enforce any Necessary Claims against third parties. 44 | 45 | **3. Patent Exclusion.** 46 | 47 | **3.1. As a Result of Contributions.** Contributor may exclude Necessary Claims from its licensing commitments incurred under Section 2.1.1 by issuing an Exclusion Notice within 45 days of the date of that Contribution. Contributor may not issue an Exclusion Notice for any material that has been included in a Draft Deliverable for more than 45 days prior to the date of that Contribution. 48 | 49 | **3.2. As a Result of a Draft Specification Becoming an Approved Specification.** Prior to the adoption of a Draft Specification as an Approved Specification, Contributor may exclude Necessary Claims from its licensing commitments under this Agreement by issuing an Exclusion Notice. Contributor may not issue an Exclusion Notice for patents that were eligible to have been excluded pursuant to Section 3.1. 50 | 51 | **4. Source Code License.** Any source code developed by the Working Group is solely subject the source code license included in the Working Group’s repository for that code. If no source code license is included, the source code will be subject to the MIT License. 52 | 53 | **5. No Other Rights.** Except as specifically set forth in this License, no other express or implied patent, trademark, copyright, or other rights are granted under this License, including by implication, waiver, or estoppel. 54 | 55 | **6. Antitrust Compliance.** Contributor acknowledge that it may compete with other participants in various lines of business and that it is therefore imperative that they and their respective representatives act in a manner that does not violate any applicable antitrust laws and regulations. This License does not restrict any Contributor from engaging in similar specification development projects. Each Contributor may design, develop, manufacture, acquire or market competitive deliverables, products, and services, and conduct its business, in whatever way it chooses. No Contributor is obligated to announce or market any products or services. Without limiting the generality of the foregoing, the Contributors agree not to have any discussion relating to any product pricing, methods or channels of product distribution, division of markets, allocation of customers or any other topic that should not be discussed among competitors under the auspices of the Working Group. 56 | 57 | **7. Non-Circumvention.** Contributor agrees that it will not intentionally take or willfully assist any third party to take any action for the purpose of circumventing any obligations under this License. 58 | 59 | **8. Representations, Warranties and Disclaimers.** 60 | 61 | **8.1. Representations, Warranties and Disclaimers.** Contributor and Licensee represents and warrants that 1) it is legally entitled to grant the rights set forth in this License and 2) it will not intentionally include any third party materials in any Contribution unless those materials are available under terms that do not conflict with this License. IN ALL OTHER RESPECTS ITS CONTRIBUTIONS ARE PROVIDED "AS IS." The entire risk as to implementing or otherwise using the Contribution or the Specification is assumed by the implementer and user. Except as stated herein, CONTRIBUTOR AND LICENSEE EXPRESSLY DISCLAIM ANY WARRANTIES (EXPRESS, IMPLIED, OR OTHERWISE), INCLUDING IMPLIED WARRANTIES OF MERCHANTABILITY, NON-INFRINGEMENT, FITNESS FOR A PARTICULAR PURPOSE, CONDITIONS OF QUALITY, OR TITLE, RELATED TO THE CONTRIBUTION OR THE SPECIFICATION. IN NO EVENT WILL ANY PARTY BE LIABLE TO ANY OTHER PARTY FOR LOST PROFITS OR ANY FORM OF INDIRECT, SPECIAL, INCIDENTAL, OR CONSEQUENTIAL DAMAGES OF ANY CHARACTER FROM ANY CAUSES OF ACTION OF ANY KIND WITH RESPECT TO THIS AGREEMENT, WHETHER BASED ON BREACH OF CONTRACT, TORT (INCLUDING NEGLIGENCE), OR OTHERWISE, AND WHETHER OR NOT THE OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. Any obligations regarding the transfer, successors in interest, or assignment of Necessary Claims will be satisfied if Contributor or Licensee notifies the transferee or assignee of any patent that it knows contains Necessary Claims or necessary claims under this License. Nothing in this License requires Contributor to undertake a patent search. If Contributor is 1) employed by or acting on behalf of an employer, 2) is making a Contribution under the direction or control of a third party, or 3) is making the Contribution as a consultant, contractor, or under another similar relationship with a third party, Contributor represents that they have been authorized by that party to enter into this License on its behalf. 62 | 63 | **8.2. Distribution Disclaimer.** Any distributions of technical information to third parties must include a notice materially similar to the following: “THESE MATERIALS ARE PROVIDED “AS IS.” The Contributors and Licensees expressly disclaim any warranties (express, implied, or otherwise), including implied warranties of merchantability, non-infringement, fitness for a particular purpose, or title, related to the materials. The entire risk as to implementing or otherwise using the materials is assumed by the implementer and user. IN NO EVENT WILL THE CONTRIBUTORS OR LICENSEES BE LIABLE TO ANY OTHER PARTY FOR LOST PROFITS OR ANY FORM OF INDIRECT, SPECIAL, INCIDENTAL, OR CONSEQUENTIAL DAMAGES OF ANY CHARACTER FROM ANY CAUSES OF ACTION OF ANY KIND WITH RESPECT TO THIS DELIVERABLE OR ITS GOVERNING AGREEMENT, WHETHER BASED ON BREACH OF CONTRACT, TORT (INCLUDING NEGLIGENCE), OR OTHERWISE, AND WHETHER OR NOT THE OTHER MEMBER HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.” 64 | 65 | **9. Definitions.** 66 | 67 | **9.1. Affiliate.** “Affiliate” means an entity that directly or indirectly Controls, is Controlled by, or is under common Control of that party. 68 | 69 | **9.2. Approved Specification.** “Approved Specification” means the final version and contents of any Draft Specification designated as an Approved Specification as set forth in the accompanying Governance.md file. 70 | 71 | **9.3. Contribution.** “Contribution” means any original work of authorship, including any modifications or additions to an existing work, that Contributor submits for inclusion in a Draft Specification, which is included in a Draft Specification or Approved Specification. 72 | 73 | **9.4. Contributor.** “Contributor” means any person or entity that has indicated its acceptance of the License 1) by making a Contribution to the Specification, or 2) by entering into the Community Specification Contributor License Agreement for the Specification. Contributor includes its Affiliates, assigns, agents, and successors in interest. 74 | 75 | **9.5. Control.** “Control” means direct or indirect control of more than 50% of the voting power to elect directors of that corporation, or for any other entity, the power to direct management of such entity. 76 | 77 | **9.6. Draft Specification.** “Draft Specification” means all versions of the material (except an Approved Specification) developed by this Working Group for the purpose of creating, commenting on, revising, updating, modifying, or adding to any document that is to be considered for inclusion in the Approved Specification. 78 | 79 | **9.7. Exclusion Notice.** “Exclusion Notice” means a written notice made by making a pull request or commit to the repository’s Notices.md file that identifies patents that Contributor is excluding from its patent licensing commitments under this License. The Exclusion Notice for issued patents and published applications must include the Draft Specification’s name, patent number(s) or title and application number(s), as the case may be, for each of the issued patent(s) or pending patent application(s) that the Contributor is excluding from the royalty-free licensing commitment set forth in this License. If an issued patent or pending patent application that may contain Necessary Claims is not set forth in the Exclusion Notice, those Necessary Claims shall continue to be subject to the licensing commitments under this License. The Exclusion Notice for unpublished patent applications must provide either: (i) the text of the filed application; or (ii) identification of the specific part(s) of the Draft Specification whose implementation makes the excluded claim a Necessary Claim. If (ii) is chosen, the effect of the exclusion will be limited to the identified part(s) of the Draft Specification. 80 | 81 | **9.8. Implementation.** “Implementation” means making, using, selling, offering for sale, importing or distributing any implementation of the Specification 1) only to the extent it implements the Specification and 2) so long as all required portions of the Specification are implemented. 82 | 83 | **9.9. License.** “License” means this Community Specification License. 84 | 85 | **9.10. Licensee.** “Licensee” means any person or entity that has indicated its acceptance of the License as set forth in Section 2.1.3. Licensee includes its Affiliates, assigns, agents, and successors in interest. 86 | 87 | **9.11. Necessary Claims.** “Necessary Claims” are those patent claims, if any, that a party owns or controls, including those claims later acquired, that are necessary to implement the required portions (including the required elements of optional portions) of the Specification that are described in detail and not merely referenced in the Specification. 88 | 89 | **9.12. Specification.** “Specification” means a Draft Specification or Approved Specification included in the Working Group’s repository subject to this License, and the version of the Specification implemented by the Licensee. 90 | 91 | **9.13. Scope.** “Scope” has the meaning as set forth in the accompanying Scope.md file included in this Specification’s repository. Changes to Scope do not apply retroactively. If no Scope is provided, each Contributor’s Necessary Claims are limited to that Contributor’s Contributions. 92 | 93 | **9.14. Working Group.** “Working Group” means this project to develop specifications, standards, best practices, guidelines, and other similar materials under this License. 94 | 95 | 96 | 97 | *The text of this Community Specification License is Copyright 2020 Joint Development Foundation and is licensed under the Creative Commons Attribution 4.0 International License available at https://creativecommons.org/licenses/by/4.0/.* 98 | 99 | SPDX-License-Identifier: CC-BY-4.0 100 | -------------------------------------------------------------------------------- /uptane-standard.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: Uptane Standard for Design and Implementation 3 | abbrev: UPTANE 4 | docname: uptane-standard-design 5 | category: info 6 | 7 | ipr: noDerivativesTrust200902 8 | area: TODO 9 | workgroup: TODO 10 | keyword: Internet-Draft 11 | 12 | stand_alone: yes 13 | pi: [toc, sortrefs, symrefs] 14 | 15 | author: 16 | - ins: Members of the Uptane Community 17 | name: Uptane Community 18 | organization: Joint Development Foundation Projects, LLC, Uptane Series (c/o Prof. Justin Cappos) 19 | email: uptane-standards@googlegroups.com 20 | street: 6 MetroTech 21 | country: USA 22 | region: NY 23 | city: Brooklyn 24 | code: 11201 25 | 26 | normative: 27 | # Keyword def (SHALL, RECOMMENDED, SHOULD, etc.) 28 | RFC2119: 29 | # Network Unicode for comparing strings 30 | RFC5198: 31 | # Unicode Normalization Form C 32 | NFC: 33 | target: https://www.unicode.org/reports/tr15/ 34 | title: "Unicode Standard Annex #15: Unicode Normalization Forms" 35 | author: 36 | - ins: M. Davis 37 | - ins: M. Duerst 38 | date: 2018-10 39 | # TAP 3 at rev d0818e5 40 | TAP-3: 41 | target: https://github.com/theupdateframework/taps/blob/d0818e580c322815a473520f2e8cc5f5eb8df499/tap3.md 42 | title: The Update Framework TAP 3 - Multi-role delegations 43 | author: 44 | - ins: T.K. Kuppusamy 45 | - ins: S. Awwad 46 | - ins: E. Cordell 47 | - ins: V. Diaz 48 | - ins: J. Moshenko 49 | - ins: J. Cappos 50 | date: 2018-01-18 51 | # TAP 4 at rev 2cb67d9 52 | TAP-4: 53 | target: https://github.com/theupdateframework/taps/blob/2cb67d913ec19424d1e354b38f862886fbfd4105/tap4.md 54 | title: The Update Framework TAP 4 - Multiple repository consensus on entrusted targets 55 | author: 56 | - ins: T.K. Kuppusamy 57 | - ins: S. Awwad 58 | - ins: E. Cordell 59 | - ins: V. Diaz 60 | - ins: J. Moshenko 61 | - ins: J. Cappos 62 | date: 2017-12-15 63 | # TUF at rev 2b4e184 64 | TUF-spec: 65 | target: https://github.com/theupdateframework/specification/blob/2b4e18472fe25d5b57f36f6fa50104967c8faeaa/tuf-spec.md 66 | title: The Update Framework Specification 67 | author: 68 | - ins: J. Samuel 69 | - ins: N. Mathewson 70 | - ins: G. Condra 71 | - ins: V. Diaz 72 | - ins: T.K. Kuppusamy 73 | - ins: S. Awwad 74 | - ins: S. Tobias 75 | - ins: J. Wright 76 | - ins: H. Mehnert 77 | - ins: E. Tryzelaar 78 | - ins: J. Cappos 79 | - ins: R. Dingledine 80 | date: 2018-09-19 81 | 82 | informative: 83 | MERCURY: 84 | target: https://www.usenix.org/system/files/conference/atc17/atc17-kuppusamy.pdf 85 | title: "Mercury: Bandwidth-Effective Prevention of Rollback Attacks Against Community Repositories" 86 | author: 87 | - ins: T.K. Kuppusamy 88 | - ins: V. Diaz 89 | - ins: J. Cappos 90 | seriesinfo: 91 | ISBN: 978-1-931971-38-6 92 | date: 2017-07-12 93 | UPTANEESCAR: 94 | target: https://ssl.engineering.nyu.edu/papers/kuppusamy_escar_16.pdf 95 | title: "Securing Software Updates for Automobiles" 96 | author: 97 | - ins: T.K. Kuppusamy 98 | - ins: A. Brown 99 | - ins: S. Awwad 100 | - ins: D. McCoy 101 | - ins: R. Bielawski 102 | - ins: C. Mott 103 | - ins: S. Lauzon 104 | - ins: A. Weimerskirch 105 | - ins: J. Cappos 106 | date: 2016-10-16 107 | PEP-458: 108 | target: https://www.python.org/dev/peps/pep-0458/ 109 | title: "Secure PyPI downloads with signed repository metadata" 110 | author: 111 | - ins: T.K. Kuppusamy 112 | - ins: V. Diaz 113 | - ins: M. Moore 114 | - ins: L. Pühringer 115 | - ins: J. Locke 116 | - ins: L.A. DeLong 117 | - ins: J. Cappos 118 | date: 2019-11-13 119 | DEPLOY: 120 | target: https://uptane.github.io/deployment-considerations/index.html 121 | title: "Uptane Deployment Best Practices" 122 | author: 123 | - ins: Members of the Uptane Community 124 | USATODAY: 125 | target: https://www.usatoday.com/story/tech/columnist/2016/06/28/your-average-car-lot-more-code-driven-than-you-think/86437052/ 126 | title: Your average car is a lot more code-driven than you think 127 | author: 128 | - ins: B. O'Donnell 129 | date: 2016-06-28 130 | CR-OTA: 131 | target: https://www.consumerreports.org/automotive-technology/automakers-embrace-over-the-air-updates-can-we-trust-digital-car-repair/ 132 | title: Automakers Embrace Over-the-Air Updates, but Can We Trust Digital Car Repair? 133 | author: 134 | - ins: K. Barry 135 | date: 2018-04-20 136 | IN-TOTO: 137 | target: https://in-toto.io/ 138 | title: "in-toto: A framework to secure the integrity of software supply chains" 139 | date: 2018-10-29 140 | 141 | --- abstract 142 | 143 | This document describes a framework for securing ground vehicle software update systems. 144 | 145 | --- middle 146 | 147 | 148 | # Introduction 149 | 150 | Uptane is a secure software update framework for ground vehicles. This document describes procedures to enable programmers for OEMs and suppliers to securely design and implement this framework in a manner that better protects connected units on ground vehicles. Integrating Uptane as outlined in the sections that follow can reduce the ability of attackers to compromise critical systems. It also assures a faster and easier recovery process when a compromise occurs. 151 | 152 | These instructions delineate the set of requirements necessary for specific ECU implementations to satisfy all conformance stipulations of the Uptane Standard. ISO/IEC 13210:1999 Information Technology, as cited in 153 | the [ISO Online Browsing Platform](https://www.iso.org/obp/ui) defines a 154 | "conformance requirement" as "a requirement stated in a *base standard* that identifies a specific 155 | requirement in a finite, measurable, and unambiguous manner. A *conformance requirement* by itself or in conjunction with other conformance requirements corresponds to an *assertion.*" Individual implementers can make their own technological choices within those requirements. This flexibility makes Uptane adaptable to the many customized update solutions used by manufacturers. If implementers wish to have compatible formats, they can use POUFs. POUFs contain a description of implementation choices as well as data binding formats. An implementer who adopts a POUF, as well as the Uptane Standard, will be able to interoperate with other implementations using that POUF. 156 | 157 | # Terminology 158 | 159 | With the exception of the Conformance terminology and Uptane role terminology presented below, please refer to the [glossary](https://uptane.github.io/deployment-considerations/glossary.html) in the Deployment Best Practices volume for definitions of all terms used in this Standard. 160 | 161 | ## Conformance terminology 162 | 163 | The keywords REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, and RECOMMENDED in this document are to be interpreted as described in {{RFC2119}}. Given the importance of interpreting these terms correctly, we present these definitions here. Note that when referring to actions in the Standard that mandate conformance, the word SHALL will be used, rather than the word MUST. 164 | 165 | *SHALL* This word or the term "REQUIRED" mean that the definition is an absolute requirement of the specification. 166 | *SHALL NOT* This phrase means that the definition is an absolute prohibition of the specification. 167 | *SHOULD* This word or the adjective "RECOMMENDED" mean that, in particular circumstances, there could exist valid reasons to ignore a particular item, but the full implications will be understood and carefully weighed before choosing a different course. 168 | *SHOULD NOT* This phrase or the phrase "NOT RECOMMENDED" mean that there could exist valid reasons in particular circumstances when the particular behavior is acceptable or even useful, but the full implications will be understood and the case carefully weighed before implementing any behavior described with this label. 169 | 170 | In order to be considered conformant to the Uptane Standard, an implementation SHALL follow all of these rules as specified in the document. 171 | 172 | Note that, following the recommendations of {{RFC2119}}, imperatives of the type defined here will be used only when essential for security. 173 | 174 | ## Uptane role terminology 175 | 176 | These terms are defined in greater detail in {{roles}}. 177 | 178 | *Delegation*: A process by which the responsibility of signing metadata about images is assigned to another party. 179 | 180 | *Role*: A party (human or machine) responsible for signing a certain type of metadata. The role controls keys and is responsible for signing the metadata entrusted to it with these keys. The roles mechanism of Uptane allows the system to distribute signing responsibilities so that the compromise of one key does not necessarily impact the security of the entire system. 181 | 182 | * *Root role*: Signs metadata that distributes and revokes public keys used to verify the Root, Timestamp, Snapshot, and Targets role metadata. 183 | * *Snapshot role*: Signs metadata that indicates which images the repository has released at the same time. 184 | * *Targets role*: Signs metadata used to verify the image, such as cryptographic hashes and file size. 185 | * *Timestamp role*: Signs metadata that indicates if there are any new metadata or images on the repository. 186 | 187 | 188 | ## Acronyms and abbreviations 189 | 190 | *CDN*: Content Delivery Network 191 | 192 | *ECUs*: Electronic Control Units, the computing units on a vehicle 193 | 194 | *LIN Bus*: Local Interconnect Bus 195 | 196 | *OBD*: On-board diagnostics 197 | 198 | *SOTA*: Software Updates Over-the-Air 199 | 200 | *UDS*: Unified Diagnostic Services 201 | 202 | *VIN*: Vehicle Identification Number 203 | 204 | # Rationale for and scope of the Uptane Standard 205 | 206 | This Standard document provides the essential components for the secure design, implementation, and deployment of Uptane by OEMs and suppliers. These guidelines contribute to compromise resilience, or the ability to minimize the extent of the threat posed by any given attack. 207 | 208 | However, this specification is intended as an implementation guide, and not as a detailed technical argument about the security properties that Uptane provides. Readers interested in such documentation can refer to published papers that cover this topic. {{UPTANEESCAR}} 209 | 210 | ## Why Uptane requires a standards document 211 | 212 | A standards document that can guide the safe design, integration, and deployment of Uptane in vehicles is needed at this time because: 213 | 214 | * The number of connected units on the average vehicle continues to grow, with mainstream cars now containing up to 100 million lines of code. {{USATODAY}} 215 | * The expanded use of software over-the-air strategies creates new attack surfaces for malicious parties. {{CR-OTA}} 216 | * Legacy update strategies, such as SSL/TLS or GPG/RSA, are not feasible for use on vehicle ECUs because they force manufacturers to chose between enhanced security and customizability. 217 | * Conventional strategies are also complicated by the differing resources of the ECUs, which can vary greatly in memory, storage space, and Internet connectivity. 218 | * The design of Uptane makes it possible to offer improved design flexibility without sacrificing security. 219 | * This added design flexibility, however, could be a liability if the framework is implemented incorrectly. 220 | * Standardization of crucial steps in the design, implementation, and use of Uptane can assure that customizability does not impact security or functionality. 221 | 222 | ## Scope of Standard coverage 223 | 224 | This document sets guidelines for implementing Uptane in most systems capable of updating software on connected units in ground vehicles, including passenger vehicles, light-duty trucks, heavy-duty trucks, and motorcycles. Uptane could potentially also be applied to other ground vehicles, such as automated shuttles, recreational vehicles, and military ground vehicles. Uptane could even be applied to domains such as IoT devices, medical devices, and autonomous aerial vehicles. In this section, we define the scope of that applicability by providing sample use cases and possible exceptions, aspects of software update security that are not applicable to Uptane, and the design requirements governing the preparation of these standards. 225 | 226 | ### Assumptions 227 | 228 | We assume the following system preconditions for Uptane: 229 | 230 | * Vehicles have the ability to establish connectivity to required backend services. For example, this could be done through cellular, Wi-Fi, or hard-wired mechanisms. 231 | * ECUs are either directly connected to the communication channel, or are indirectly connected via some sort of network gateway. 232 | * ECUs are programmable and provide sufficient performance to be updated. 233 | * ECUs SHALL be able to perform public key cryptography operations and calculate hashes of images and metadata files. 234 | * There are state-of-the-art secure servers in place, such as the Director and Image repository servers. 235 | * The initial Uptane required data, such as Uptane metadata, have been securely provisioned into the ECUs by the time they are installed in the vehicle. 236 | 237 | It is important that any bugs detected in Uptane implementations be patched promptly. Failure to do so could interfere with the effectiveness of Uptane's operations. 238 | 239 | ### Use cases 240 | 241 | The following use cases provide a number of scenarios illustrating the manner in which software updates could be accomplished using Uptane. 242 | 243 | #### OEMs initializing Uptane at the factory using SOTA 244 | 245 | An OEM plans to install Uptane on new vehicles. This entails the following components: code to perform full and partial verification, the latest copy of the relevant metadata, the public keys, and an accurate attestation of the latest time. The OEM then either requires its tier-1 suppliers to provide these materials to the suppliers' assembly lines or can choose to add the materials later at the OEM's assembly lines. The OEM's in-vehicle implementation is Uptane-conformant if: 246 | 247 | 1. all Primaries perform full verification; 248 | 1. all Secondaries that are updated via OTA at least perform partial verification; and 249 | 1. any ECUs that do not perform any type of verification cannot be updated via OTA. 250 | 251 | #### Updating one ECU with a complete image 252 | 253 | A tier-1 supplier completes work on a revised image for an electronic brake control module. This module will control the brakes on all models of an SUV produced by the OEM mentioned above. Assuming supplier delegation is supported by the OEM for this ECU, each tier-1 supplier digitally signs the image, then delivers the signature, all of its metadata, including delegations, and associated images to the OEM. The OEM adds these metadata and images to its Image repository, along with information about any dependencies and conflicts between this image and those for other ECUs used in the OEM's vehicles. The OEM also updates the inventory database, so that the Director repository can instruct the ECU on how to install these updated images. 254 | 255 | #### Updating individual ECUs on demand 256 | 257 | An OEM has issued a recall to address a problem with a keyless entry device that has been locking people out of their cars. The OEM prepares an updated flash image in the manner described above. The OEM then ships USB flash drives to vehicle owners and dealerships that allow those parties to update the firmware of their vehicles. 258 | 259 | #### Update one ECU with multiple deltas 260 | 261 | The OEM wants to use delta updates to save over-the-air bytes. The delta images contain only the code and/or data that has changed from the previous image version. To do so, the OEM will first modify the Director repository, using the vehicle version manifest and dependency resolution to determine the differences between the previous and latest images. The OEM will then add the following to the custom Targets metadata used by the Director repository: (1) the algorithm used to apply a delta image, and (2) the Targets metadata about the delta image. The OEM will also check whether the delta images match the Targets metadata from the Director repository. 262 | 263 | ## Exceptions 264 | 265 | There are a number of factors that could impede the completion of the above scenarios: 266 | 267 | * ECUs can be lacking the necessary resources to function as designated. These insufficient resources could include limited CPU or RAM inadequate for performance of public key cryptography; a lack of sufficient storage to undo installation of bad software; or a location on a low-speed network (e.g., LIN). 268 | * ECUs can reside on different network segments, and cannot directly reach each other, requiring a gateway to facilitate communication. 269 | * A user can replace OEM-installed ECUs with aftermarket ECUs. 270 | * A vehicle can download only a limited amount of data via a cellular channel (e.g. due to limits on a data plan). 271 | * A system can lack sufficient power to download or install software updates. 272 | * Vehicles can be offline for extended periods of time, thus missing required updates (e.g., key rotations). 273 | * OEMs can be unwilling to implement costly security or hardware requirements. 274 | 275 | ## Out of scope 276 | 277 | The following topics will not be addressed in this document, as they represent threats outside the scope of Uptane: 278 | 279 | * Physical attacks, such as manual tampering with ECUs outside the vehicle. 280 | * Compromise of the packaged software, such as malware embedded in a trusted package. 281 | * Compromise of the supply chain (e.g., build system, version control system, packaging process). The focus of Uptane is end device security and secure delivery. It addresses one part of the solution, but it is designed to pair well with more holistic solutions, like in-toto {{IN-TOTO}}, git signing, TPMs, etc. Recently, the Uptane community approved [Scudo](https://github.com/uptane/pures/blob/main/pure3.md) as an Uptane augmentation that could be adopted as a formal recommendation in the Uptane Deployment Best Practices in the future. 282 | * Problems associated with OBD or UDS programming of ECUs, such as authentication of communications between ECUs. 283 | * Malicious mirrors of package repositories, which could substitute original packages with malicious packages with matching version numbers {{MERCURY}}. 284 | 285 | ## Design requirements 286 | 287 | The design requirements for this document are governed by the following principal parameters: 288 | 289 | * to clearly mandate the design and implementation steps that are security critical and will be followed as is, while offering flexibility in the implementation of non-critical steps. In this manner, users can adapt to support different use models and deployment scenarios. 290 | * to ensure that, if Uptane is implemented, the security practices mandated or suggested in this document do not interfere with the functionality of ECUs, vehicles, or the systems that maintain them. 291 | * to delineate guidelines to ensure that, when any part of the SOTA mechanism of a vehicle is attacked, an attacker has to compromise two or more modules to breach the SOTA mechanism. 292 | 293 | # Threat model and attack strategies 294 | 295 | The overarching goal of Uptane is to provide a system that is resilient in the face of various types of compromise. In this section, we describe the goals an attacker could have ({{attacker_goals}}) and the capabilities they could have or could develop ({{capabilities}}). We then describe and classify types of attacks on the system according to the attacker's goals ({{threats}}). 296 | 297 | ## Attacker goals {#attacker_goals} 298 | 299 | We assume that attackers could want to achieve one or more of the following goals, in increasing order of severity: 300 | 301 | * Read the contents of updates to discover confidential information, reverse-engineer firmware, or compare two firmware images to identify security fixes and hence determine the fixed security vulnerability. 302 | * Deny installation of updates to prevent vehicles from fixing software problems. 303 | * Cause one or more ECUs in the vehicle to fail, denying use of the vehicle or of certain functions. 304 | * Control ECUs within the vehicle, and possibly the vehicle itself, through malicious software updates and installations. 305 | 306 | ## Attacker capabilities {#capabilities} 307 | 308 | Uptane is designed with resilience to compromise in mind. We assume that attackers could develop one or more of the following capabilities: 309 | 310 | * Intercept and modify network traffic (i.e., perform man-in-the-middle attacks). This capability could be developed in two domains: 311 | * Outside the vehicle, intercepting and modifying traffic between the vehicle and software repositories. 312 | * Inside the vehicle, intercepting and modifying traffic on one or more vehicle buses (e.g., via an OBD port or by using a compromised ECU as a vector). 313 | * Compromise and control either a Director repository or Image repository server, and any keys stored on that repository, but not both the Director and Image repositories. 314 | * Compromise either a Primary ECU or a Secondary ECU, but not both in the same vehicle. 315 | 316 | ## Description of threats {#threats} 317 | 318 | Uptane's threat model includes the following types of attacks, organized according to the attacker goals listed in {{attacker_goals}}. 319 | 320 | ### Read updates {#read_updates} 321 | 322 | * *Eavesdrop attack:* Read sensitive or confidential information from an update intended to be encrypted for a specific ECU. (Note: Not all implementations will have a need to protect information in this way.) 323 | 324 | ### Deny installation of updates {#deny_updates} 325 | 326 | An attacker seeking to deny the installation of updates could attempt one or more of the following strategies: 327 | 328 | * *Drop-request attack:* Block network traffic outside or inside the vehicle. 329 | * *Slow retrieval attack:* Slow down network traffic, in the extreme case sending barely enough packets to avoid a timeout. Similar to a drop-request attack, except that both the sender and receiver of the traffic still think network traffic is unimpeded. 330 | * *Freeze attack:* Continue to send a properly signed, but old, update bundle to the ECUs, even if newer updates exist. 331 | * *Partial bundle installation attack:* Install a valid (signed) update bundle, and then block selected updates within the bundle. 332 | * *Denial of service attack* against the Uptane repositories or infrastructure. 333 | 334 | ### Interfere with ECU functionality {#change_functionality} 335 | 336 | Attackers seeking to interfere with the functionality of vehicle ECUs in order to cause an operational failure or unexpected behavior could do so in one of the following ways: 337 | 338 | * *Rollback attack:* Cause an ECU to install a previously valid software revision that is older than the currently installed version. 339 | * *Endless data attack:* Send a large amount of data to an ECU until it runs out of storage, possibly causing the ECU to fail to operate. 340 | * *Mix-and-match attack:* Install a malicious software bundle in which some of the updates do not interoperate properly. This could be accomplished even if all of the individual images being installed are valid, as long as valid versions exist that are mutually incompatible. 341 | 342 | ### Control an ECU or vehicle {#control_ecu} 343 | 344 | Full control of a vehicle, or one or more ECUs within a vehicle, is the most severe threat. 345 | 346 | * *Arbitrary software attack:* Cause an ECU to install and run arbitrary code of the attacker's choice. 347 | 348 | # Detailed design of Uptane {#design} 349 | 350 | Uptane does not specify implementation details. Instead, this Standard describes the components necessary for a conformant implementation and leaves it up to individual implementers to make their own technology choices within those requirements. 351 | 352 | At a high level, Uptane requires: 353 | 354 | * Two software repositories: 355 | * An Image repository containing: 356 | * binary images 357 | * signed metadata about the binary images 358 | * A Director repository connected to an inventory database that can sign metadata on demand for images in the Image repository. 359 | * Repository tools for generating Uptane-specific metadata about images. 360 | * A public key infrastructure supporting the required metadata production and signing roles on each repository: 361 | * Root - The certificate authority for the Uptane ecosystem. Distributes public keys for verifying all the other roles' metadata. 362 | * Timestamp - Indicates whether there are new metadata or images. 363 | * Snapshot - Indicates images released by the repository at a point in time via signing metadata about Targets metadata. 364 | * Targets - Indicates metadata about images, such as hashes and file sizes. 365 | * A secure way for ECUs to know the time. 366 | * An ECU capable of downloading images and associated metadata from the Uptane servers. 367 | * An in-vehicle client on a Primary ECU capable of verifying the signatures on all update metadata and downloading updates on behalf of its associated Secondary ECUs. The Primary ECU can be the same ECU that communicates with the server. 368 | * A client or library on each Secondary ECU capable of performing either full or partial verification of metadata. 369 | 370 | ## Roles on repositories {#roles} 371 | 372 | A repository contains images and metadata. Each role has a particular type of metadata associated with it, as described in {{meta_structures}}. 373 | 374 | ### The Root role {#root_role} 375 | 376 | A repository's Root role SHALL produce and sign Root metadata as described in {{root_meta}}. 377 | 378 | ### The Targets role {#targets_role} 379 | 380 | A repository's Targets role SHALL produce and sign metadata about images and delegations as described in {{targets_meta}}. 381 | 382 | #### Delegations {#targets_role_delegations} 383 | 384 | The Targets role on the Image repository can delegate the responsibility of signing metadata to other, custom-defined roles referred to as delegated targets. If it does, it SHALL do so as specified in {{delegations_meta}}. 385 | 386 | As responsibility for signing images or a subset of images could be delegated to more than one role, it is possible that two different roles will be trusted to sign a particular image. For this reason, delegations SHALL be prioritized. 387 | 388 | A particular delegation for a subset of images could be designated as **terminating**. For terminating delegations, the client SHALL NOT search any further if it does not find validly signed metadata about those images. Delegations SHOULD NOT be terminating by default; terminating delegations SHOULD only be used when there is a compelling technical reason to do so. 389 | 390 | A delegation for a subset of images could be a multi-role delegation {{TAP-3}}. A multi-role delegation indicates that multiple roles are needed to sign a particular image and each of the delegatee roles SHALL sign the same metadata. 391 | 392 | Delegations only apply to the Image repository. The Targets role on the Director repository SHALL NOT delegate metadata signing responsibility. 393 | 394 | ### The Snapshot role {#snapshot_role} 395 | 396 | A repository's Snapshot role SHALL produce and sign metadata about all Targets metadata the repository releases, including the current version number of the top-level Targets metadata, and the version numbers of all delegated Targets metadata, as described in {{snapshot_meta}}. 397 | 398 | ### The Timestamp role {#timestamp_role} 399 | 400 | A repository's Timestamp role SHALL produce and sign metadata indicating whether there are new metadata or images on the repository. It SHALL do so by signing the metadata about the Snapshot metadata file. 401 | 402 | ## Metadata structures {#meta_structures} 403 | 404 | Uptane's security guarantees all rely on properly created metadata that follows a designated structure. The Uptane Standard **does not** mandate any particular format or encoding for the metadata as a whole. ASN.1 (with any encoding scheme like BER, DER, XER, etc.), JSON, XML, or any other encoding format that is capable of providing the required structure can be used. 405 | 406 | However, string comparison is required as part of metadata verification. To ensure an accurate basis for comparing strings, all strings SHALL be encoded in the Unicode Format for Network Interchange as defined in {{RFC5198}}, including normalization into Unicode Normalization Form C ({{NFC}}). 407 | 408 | The *Deployment Best Practices* ({{DEPLOY}}), Joint Development Foundation Projects, LLC, Uptane Series provides some examples of metadata structures in ASN.1 and JSON that conform to the Standard. 409 | 410 | ### Common metadata structures {#common_metadata} 411 | 412 | Every public key SHALL be represented using a public key identifier. A public key identifier is EITHER all of the following: 413 | 414 | * The value of the public key itself (which could be, for example, formatted as a PEM string) 415 | * The public key cryptographic algorithm used by the key (such as RSA or ECDSA) 416 | * The particular scheme used to verify the signature (such as `rsassa-pss-sha256` or `ecdsa-sha2-nistp256`) 417 | 418 | OR a secure hash over at least the above components (such as the keyid mechanism in TUF). 419 | 420 | All four Uptane roles (Root, Targets, Snapshot, and Timestamp) share a common structure. They SHALL contain the following two attributes: 421 | 422 | * A payload of metadata to be signed 423 | * An attribute containing the signature(s) of the payload, where each entry specifies: 424 | * The public key identifier of the key being used to sign the payload 425 | * A signature with this key over the payload 426 | 427 | The payload differs depending on the role. However, the payload for all roles shares a common structure. It SHALL contain the following four attributes: 428 | 429 | * An indicator of the type of role (Root, Targets, Snapshot, or Timestamp) 430 | * An expiration date and time 431 | * An integer version number, which SHOULD be incremented each time the metadata file is updated 432 | * The role-specific metadata for the role indicated 433 | 434 | The following sections describe the role-specific metadata. All roles SHALL follow the common structures described here. 435 | 436 | ### Root metadata {#root_meta} 437 | 438 | A repository's Root metadata distributes the public keys of the top-level Root, Targets, Snapshot, and Timestamp roles, as well as revocations of those keys. It SHALL contain two attributes: 439 | 440 | * A representation of the public keys for all four roles. Each key SHALL have a unique public key identifier. 441 | * An attribute mapping each role to (1) its public key(s), and (2) the threshold of signatures required for that role. 442 | 443 | ### Targets metadata {#targets_meta} 444 | 445 | The Targets metadata on a repository contains all of the information about images to be installed on ECUs. This includes filenames, hashes, and file sizes. It can also include other useful information, such as what types of hardware are compatible with a particular image. 446 | 447 | Targets metadata can also contain metadata about delegations, allowing one Targets role to delegate its authority to another. This means that an individual Targets metadata file might contain only metadata about delegations, only metadata about images, or some combination of the two. The details of how ECUs traverse the delegation tree to find valid metadata about images is specified in {{resolve_delegations}}. 448 | 449 | #### Metadata about images {#targets_images_meta} 450 | 451 | To be available to install on clients, all images on the repository SHALL have their metadata listed in a Targets role. Each Targets role can provide a list of some images on the repository. This list SHALL provide, at a minimum, the following information about each image: 452 | 453 | * The image filename 454 | * The size of the image in bytes 455 | * One or more hashes of the image file, along with the hashing function used 456 | 457 | If there are no images included in the Targets metadata from the Director repository, then the metadata SHALL include a vehicle identifier in order to avoid a replay attack. 458 | 459 | ##### Custom metadata about images 460 | 461 | In addition to what is required, Targets metadata files can contain extra metadata for images on the repository. This metadata can be customized for a particular use case. Examples of use cases for different types of custom metadata can be found in the *Deployment Best Practices* document ({{DEPLOY}}). However, there are a few important pieces of custom metadata that SHOULD be present in most implementations. In addition, there is one element in the custom metadata that SHALL be present in the Targets metadata from the Director. 462 | 463 | Custom metadata can also contain a demarcated field or section that SHALL match whenever two pieces of metadata are checked against each other, such as when Targets metadata from the Director repository is checked against Targets metadata from the Image repository. 464 | 465 | The information listed below SHOULD be provided for each image on both the Image repository and the Director repository. If a "SHALL match section" is to be implemented, that is where this information SHOULD be placed. 466 | 467 | * A release counter, to be incremented each time a new version of the image is released. This can be used to prevent rollback attacks even in cases where the Director repository is compromised. 468 | * A hardware identifier, or list of hardware identifiers, representing models of ECUs with which the image is compatible. This can be used to ensure that an ECU cannot be ordered to install an incompatible image, even in cases where the Director repository is compromised. 469 | 470 | The following information is CONDITIONALLY REQUIRED for each image on the Director repository IF that image is encrypted: 471 | 472 | * Information about filenames, hashes, and file size of the encrypted image. 473 | * 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. 474 | 475 | The following information SHALL be provided from the Director repository for each image in the Targets metadata: 476 | 477 | * An ECU identifier (such as a serial number), specifying the ECU that SHOULD install the image. 478 | 479 | The Director repository could provide a download URL for the image file. This may be useful, for example, when the image is on a public CDN and the Director wishes to provide a signed URL. 480 | 481 | #### Metadata about delegations {#delegations_meta} 482 | 483 | A Targets metadata file on the Image repository (but not the Director repository) SHALL be able to delegate signing authority to other entities. For example, it could delegate signing authority for a particular ECU's firmware to that ECU's supplier. A metadata file can contain any number of delegations and SHALL keep the delegations in prioritized order. 484 | 485 | Any metadata file with delegations SHALL provide the following information: 486 | 487 | * A list of public keys of all delegatees. Each key SHOULD have a unique public key identifier and a key type. 488 | * A list of delegations, each of which contains: 489 | * A list of the filenames to which this role applies. This could be expressed using wildcards, or by enumerating a list, or a combination of the two. 490 | * An optional list of the hardware identifiers to which this role applies. If this is omitted, any hardware identifier will match. 491 | * An indicator of whether or not this is a terminating delegation. (See {{targets_role_delegations}}.) 492 | * A list of the roles to which this delegation applies. Each role needs to specify: 493 | * A name for the role (e.g., "supplier1-qa") 494 | * The key identifiers for each key this role uses 495 | * A threshold of keys that SHALL sign for this role 496 | 497 | Note that **any** Targets metadata file stored on the Image repository can contain delegations, and these delegations can be in chains of arbitrary length. 498 | 499 | ### Snapshot metadata {#snapshot_meta} 500 | 501 | The Snapshot metadata lists version numbers and filenames of all Targets metadata files. It protects against mix-and-match attacks if a delegated supplier key is compromised. 502 | 503 | For each Targets metadata file on the repository, the Snapshot metadata SHALL contain the following information: 504 | 505 | * The filename and version number of the Targets metadata file. 506 | 507 | The Snapshot metadata could also list the Root metadata filename and version number for the purpose of backwards compatibility. Historically, this was a requirement in TUF, but it is no longer required and does not provide a significant security benefit. 508 | 509 | ### Timestamp metadata {#timestamp_meta} 510 | 511 | The Timestamp metadata SHALL contain the following information: 512 | 513 | * The filename and version number of the latest Snapshot metadata on the repository. 514 | * One or more hashes of the Snapshot metadata file, along with the hashing function used. 515 | 516 | ### Repository mapping metadata {#repo_mapping_meta} 517 | 518 | As described in the introduction to {{design}}, Uptane requires a Director repository and an Image repository. However, it is possible to have an Uptane-conformant implementation that has more than two repositories. 519 | 520 | Repository mapping metadata informs a Primary ECU about which repositories to trust for images or image paths. {{TAP-4}} describes how to make use of more complex repository mapping metadata in order to have more than the two required repositories. 521 | 522 | Repository mapping metadata, or the equivalent informational content, SHALL be present on all Primary ECUs, and SHALL contain the following information: 523 | 524 | * A list of repository names and one or more URLs at which the named repository can be accessed. At a minimum, this SHALL include the Director and Image repositories. 525 | * A list of mappings of image paths to repositories, each of which contains: 526 | * A list of image paths. Image paths could be expressed using wildcards, or by enumerating a list, or a combination of the two. 527 | * A list of repositories that SHALL provide signed Targets metadata for images stored at those paths. 528 | 529 | For example, in the most basic Uptane case, the repository mapping metadata would contain: 530 | 531 | * The name and URL of the Director repository. 532 | * The name and URL of the Image repository. 533 | * A single mapping indicating that all images (`*`) SHALL be signed by both the Director and Image repository. 534 | 535 | Note that the metadata need not be in the form of a metadata file. For example, in the basic case where there is only one Director and one Image repository, and all images need to have signed metadata from both repositories, it would be sufficient to have a configuration file with URLs for the two repositories and a client that always checks for metadata matches between them. In this case, no explicit mapping would be defined, because the mapping is defined as part of the Uptane client implementation. 536 | 537 | The *Uptane Deployment Best Practices* document ({{DEPLOY}}) provides more guidance on how to implement repository mapping metadata for more complex use cases. It also discusses strategies for updating repository mapping metadata, if required. 538 | 539 | ### Rules for filenames in repositories and metadata {#metadata_filename_rules} 540 | 541 | There is a difference between the filename in a metadata file or an ECU, and the filename on a repository. This difference exists in order to avoid race conditions, where metadata and images are read from, and written to, at the same time. For more details, the reader can read the TUF specification {{TUF-spec}} and PEP 458 {{PEP-458}}. 542 | 543 | Unless stated otherwise, all files SHALL be written to repositories in accordance with the following two rules: 544 | 545 | 1. Metadata filenames SHALL be qualified with version numbers. If a metadata file A is specified as FILENAME.EXT in another metadata file B, then it SHALL be written as VERSION.FILENAME.EXT, where VERSION is A's version number, as defined in {{common_metadata}}, with one exception: If the version number of the Timestamp metadata file is not be known in advance by a client, it could be read from, and written to, a repository using a filename without a version number qualification, i.e., FILENAME.EXT. 546 | 1. If an image is specified in a Targets metadata file as FILENAME.EXT, it SHALL be written to the repository as HASH.FILENAME.EXT, where HASH is one of the hash digests of the file, as specified in {{targets_images_meta}}. The file SHALL be written to the repository using *n* different filenames, one for each hash digest listed in its corresponding Targets metadata. 547 | 1. Filenames of images SHOULD be encoded to prevent a path traversal on the client system, either by using URL encoding or by limiting the allowed character set in the filename. 548 | 549 | For example: 550 | 551 | * The version number of the Snapshot metadata file is 61, and its filename in the Timestamp metadata is *snapshot.json*. The filename on the repository will be *61.snapshot.json*. 552 | * There is an image with the *filename acme_firmware.bin* specified in the Targets metadata, with a SHA3-256 of *aaaa* and a SHA-512/224 of *bbbb*. It will have two filenames on the repository: *aaaa.acme_firmware.bin* and *bbbb.acme_firmware.bin*. 553 | 554 | ## Server / repository implementation requirements 555 | 556 | An Uptane implementation SHALL make the following services available to vehicles: 557 | 558 | * Image repository 559 | * Director repository 560 | 561 | Additionally, an Uptane implementation requires ECUs to have a secure way to know the current time. 562 | 563 | ### Image repository 564 | 565 | The Image repository exists to allow an OEM and/or its suppliers to upload images and their associated metadata. It makes these images and their metadata available to vehicles. The Image repository is designed to be primarily controlled by human actors, and updated relatively infrequently. 566 | 567 | The Image repository SHALL expose an interface permitting the download of metadata and images. This interface SHOULD be public. 568 | 569 | The Image repository SHALL require authorization for writing metadata and images. 570 | 571 | The Image repository SHALL provide a method for authorized users to upload images and their associated metadata. It SHALL check that a user writing metadata and images is authorized to do so for that specific image by checking the chain of delegations as described in {{delegations_meta}}. 572 | 573 | The Image repository SHALL implement storage that permits authorized users to write an image file using a unique filename, and later read the same file using the same name. It could use any filesystem, key-value store, or database that fulfills this requirement. 574 | 575 | The Image repository could require authentication for read access. 576 | 577 | ### Director repository {#director_repository} 578 | 579 | The Director repository instructs ECUs as to which images will 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. 580 | 581 | The Director repository SHALL expose an interface for Primaries to upload vehicle version manifests ({{vehicle_version_manifest}}) and download metadata. This interface SHOULD be public. 582 | 583 | The Director could encrypt images for ECUs that require them, either by encrypting on-the-fly or by storing encrypted images on the repository. 584 | 585 | The Director repository SHALL implement storage that permits an automated service to write generated metadata files. It could use any filesystem, key-value store, or database that fulfills this requirement. 586 | 587 | #### Directing installation of images on vehicles 588 | 589 | Here is the process for the Director repository managing the installation of software images on a vehicle. 590 | 591 | 1. The Director SHOULD first identify the vehicle. This could be done when the Director receives a vehicle version manifest sent by a Primary (as described in {{construct_manifest_primary}}), decodes the manifest, and determines the unique vehicle identifier. Additionally, the Director could utilize other mechanisms to uniquely identify a vehicle (e.g., 2-way TLS with unique client certificates). 592 | 1. Using the vehicle identifier, the Director queries its inventory database (as described in {{inventory_db}}) for relevant information about each ECU in the vehicle. 593 | 1. The Director SHALL check the manifest for accuracy compared to the information in the inventory database. If any of the required checks fail, the Director SHOULD drop the request. An implementer can make additional checks if desired. At a minimum, the Director SHOULD check the following: 594 | * Each ECU recorded in the inventory database is also represented in the manifest. 595 | * The signature of the manifest matches the ECU key of the Primary that sent it. 596 | * The signature of each Secondary's contribution to the manifest matches the ECU key of that Secondary. 597 | * The time sent in the ECU version report. 598 | 1. The Director SHOULD check that the nonce or counter in each ECU version report has not been used before to prevent a replay of the ECU version report. If the nonce or counter is reused the Director SHOULD drop the request. 599 | 1. The Director extracts information about currently installed images from the vehicle version manifest. Using this information, it determines if the vehicle is already up-to-date, and if not, determines a set of images that could be installed. The exact process by which this determination takes place is out of scope for this Standard. However, the Director SHALL take into account *dependencies* and *conflicts* between images and SHOULD consult well-established techniques for dependency resolution. 600 | 1. The Director could encrypt images for ECUs that require it. 601 | 1. The Director generates new metadata representing the desired set of images to be installed on the vehicle, based on the dependency resolution in step 4. This includes Targets ({{targets_meta}}), Snapshot ({{snapshot_meta}}), and Timestamp ({{timestamp_meta}}) metadata. It then sends this metadata to the Primary as described in {{download_meta_primary}}. 602 | 603 | #### Inventory Database {#inventory_db} 604 | 605 | The Director SHALL use a private inventory database to store information about ECUs and vehicles. An implementer could use any durable database for this purpose. 606 | 607 | The inventory database SHALL record the following pieces of information: 608 | 609 | * Per vehicle: 610 | * A unique identifier (such as a VIN) 611 | * Per ECU: 612 | * A unique identifier (such as a serial number) 613 | * The vehicle identifier the ECU is associated with 614 | * An ECU key (symmetric or asymmetric; for asymmetric keys, only the public part SHOULD be stored) 615 | * The ECU key identifier (as defined in {{common_metadata}}) 616 | * Whether the ECU is a Primary or a Secondary 617 | 618 | The inventory database can record other information about ECUs and vehicles. It SHOULD record a hardware identifier for each ECU to protect against the possibility of directing the ECU to install incompatible firmware. 619 | 620 | ## In-vehicle implementation requirements 621 | 622 | An Uptane-conformant ECU SHALL be able to download and verify image metadata and image binaries before installing a new image and SHALL have a secure way of verifying the current time, or a sufficiently recent attestation of the time. 623 | 624 | All ECUs SHALL monitor the download speed of image metadata and image binaries to detect and respond to a slow retrieval attack. If the download is slower than a pre-defined threshold, the ECU SHOULD send an alert to the Director repository, for example as part of the next vehicle version manifest. 625 | 626 | Each ECU receiving over-the-air updates in a vehicle is either a Primary or a Secondary ECU. A Primary ECU collects and delivers to the Director vehicle manifests ({{vehicle_version_manifest}}) that contain information about which images have been installed on ECUs in the vehicle. It also verifies the time, and downloads and verifies the latest metadata and images for itself and for its Secondaries. A Secondary ECU verifies the time, and downloads and verifies the latest metadata and images for itself from its associated Primary ECU. It also sends signed information about its installed images to its associated Primary. 627 | 628 | All ECUs SHALL verify image metadata as specified in {{metadata_verification}} before installing an image or making it available to other ECUs. A Primary ECU SHALL perform full verification ({{full_verification}}). A Secondary ECU SHOULD perform full verification if possible. If a Secondary cannot perform full verification, it SHALL, at the very least, perform partial verification. In addition, it can also perform some steps from the full verification process. See the *Uptane Deployment Best Practices* document ({{DEPLOY}}) for a discussion of how to choose between partial and full verification. 629 | 630 | ECUs SHALL have a secure source of time. An OEM/Uptane implementer can use any external source of time that is demonstrably secure. 631 | 632 | ### Build-time prerequisite requirements for ECUs 633 | 634 | For an ECU to be capable of receiving Uptane-secured updates, it SHALL have the following data provisioned at the time it is manufactured or installed in the vehicle: 635 | 636 | 1. A sufficiently recent copy of required Uptane metadata at the time of manufacture or install. This is necessary for the ECU to authenticate that the remote repository is legitimate when it first downloads metadata in the field. See *Uptane Deployment Best Practices* ({{DEPLOY}}) for more information. 637 | * Partial verification Secondary ECUs SHALL have the Root and Targets metadata from the Director repository (to reduce the scope of rollback and replay attacks). These ECUs can also have metadata from other roles or the Image repository if they will be used by the Secondary. 638 | * Full verification ECUs SHALL have a complete set of metadata (Root, Targets, Snapshot, and Timestamp) from both repositories (to prevent rollback and replay attacks), as well as the repository mapping metadata ({{repo_mapping_meta}}). Delegations are not required. 639 | 2. The current time, or a secure attestation of a sufficiently recent time. 640 | 3. **ECU identity keys**. These keys, which are unique to each ECU, are used to sign ECU version reports and decrypt images. ECU identity keys can be either symmetric asymmetric key. If asymmetric keys are used, there SHOULD be separate keys for encryption and signing. For the purposes of this Standard, the set of keys that an ECU uses is referred to as the ECU key (singular), even if it is actually multiple keys used for different purposes. Note that while identity keys are required to be unique to the ECU to avoid replay attacks, the secret keys used to decrypt images need not be unique. 641 | 642 | ### What the Primary does 643 | 644 | A Primary downloads, verifies, and distributes the latest time, metadata, and images. To do so, it SHALL perform the following seven steps: 645 | 646 | 1. Construct and send vehicle version manifest ({{construct_manifest_primary}}) 647 | 1. Download and check current time ({{check_time_primary}}) 648 | 1. Download and verify metadata ({{download_meta_primary}}) 649 | 1. Download and verify images ({{download_images_primary}}) 650 | 1. Send latest time to Secondaries ({{send_time_primary}}) 651 | 1. Send metadata to Secondaries ({{send_metadata_primary}}) 652 | 1. Send images to Secondaries ({{send_images_primary}}) 653 | 654 | Note that the subsequent sections concerning requirements for a Primary do not prohibit implementing Primary capabilities on an ECU that does not communicate directly with the Uptane repositories. This allows for implementations to have multiple ECUs within the vehicle performing functions equivalent to a Primary. 655 | If multiple such Primaries are included within a vehicle, each Primary SHOULD have a designated set of Secondaries and each Secondary SHALL have at least one Primary responsible for providing its updates 656 | 657 | #### Construct and send vehicle version manifest {#construct_manifest_primary} 658 | 659 | The Primary SHALL build a *vehicle version manifest* as described in {{vehicle_version_manifest}}. 660 | 661 | Once the complete manifest is built, the Primary can send the manifest to the Director repository. However, it is not strictly required that the Primary send the manifest until step three. If permitted by the implementation, a Primary could send only a diff of the manifest to save bandwidth. If an implementation permits diffs, the Director SHOULD have a way to request a full manifest. 662 | 663 | Secondaries can send their version reports at any time so that they are already stored on the Primary when it wishes to check for updates. Alternatively, the Primary can request a version report from each Secondary at the time of the update check. 664 | 665 | ##### Vehicle version manifest {#vehicle_version_manifest} 666 | 667 | The vehicle version manifest is a metadata structure that SHALL contain the following information: 668 | 669 | * An attribute containing the signature(s) of the payload, each specified by: 670 | * The public key identifier of the key being used to sign the payload 671 | * The signing method (i.e., ed25519, rsassa-pss, etc.) 672 | * A hash of the payload to be signed 673 | * The hashing function used (i.e., SHA3-256, SHA-512/224, etc.) 674 | * The signature of the hash 675 | * A payload representing the installed versions of each software image on the vehicle. This payload SHALL contain: 676 | * The vehicle's unique identifier (e.g., the VIN) 677 | * The Primary ECU's unique identifier (e.g., the serial number) 678 | * A list of ECU version reports as specified in {{version_report}} 679 | 680 | Note that one of the ECU version reports SHOULD be the version report for the Primary itself. 681 | 682 | ##### ECU version report {#version_report} 683 | 684 | An ECU version report is a metadata structure that SHALL contain the following information: 685 | 686 | * An attribute containing the signature(s) of the payload, each specified by: 687 | * The public key identifier of the key being used to sign the payload 688 | * The signing method (i.e., ed25519, rsassa-pss, etc.) 689 | * A hash of the payload to be signed 690 | * The hashing function used (i.e., SHA3-256, SHA-512/224, etc.) 691 | * The signature of the hash 692 | * A payload containing: 693 | * The ECU's unique identifier (e.g., the serial number) 694 | * The filename, length, and hashes of its currently installed image (i.e., the non-custom Targets metadata for this particular image) 695 | * An indicator of any detected security attack 696 | * The latest time the ECU can verify at the time this version report was generated 697 | * A nonce or counter to prevent a replay of the ECU version report. This value SHALL change each update cycle. 698 | 699 | #### Download and check current time {#check_time_primary} 700 | 701 | The Primary SHALL load the current time from a secure source. 702 | 703 | #### Download and verify metadata {#download_meta_primary} 704 | 705 | The Primary SHALL download metadata for all targets and perform a full verification on it as specified in {{full_verification}}. 706 | 707 | #### Download and verify images {#download_images_primary} 708 | 709 | The Primary SHALL download and verify images for itself and for all of its associated Secondaries. Images SHALL be verified by checking that the hash of the image file matches the hash specified in the Director's Targets metadata for that image. 710 | 711 | There could be several different filenames that all refer to the same image binary, as described in {{metadata_filename_rules}}. If the Primary has received multiple hashes for a given image binary via the Targets role (see {{targets_images_meta}}) then it SHALL verify every hash for this image even though the image is identified by a single hash as part of its filename. 712 | 713 | #### Send latest time to Secondaries {#send_time_primary} 714 | 715 | The Primary SHOULD send the time to each ECU. 716 | 717 | #### Send metadata to Secondaries {#send_metadata_primary} 718 | 719 | The Primary SHALL make available to each of its associated Secondaries all new metadata required for verification on that Secondary. For full verification Secondaries, this includes the metadata for all four roles from both repositories, plus any delegated Targets metadata files the Secondary will recurse through to find the proper delegation. For partial verification Secondaries, this could include fewer metadata files; at a minimum, it includes only the Targets metadata file from the Director repository. 720 | 721 | The Primary SHOULD determine the minimal set of metadata files to send to each Secondary by performing delegation resolution as described in {{full_verification}}. 722 | 723 | Each Secondary SHALL store the latest copy of all metadata required for its own verification. 724 | 725 | #### Send images to Secondaries {#send_images_primary} 726 | 727 | The Primary SHALL send the latest image to each of its associated Secondaries that have sufficient storage to receive it. 728 | 729 | For Secondaries without sufficient storage to store a copy of the image, the Primary SHOULD wait for a request from the Secondary to stream the new image file to it. The Secondary will send the request once it has verified the metadata sent in the previous step. 730 | 731 | ### Installing images on Primary or Secondary ECUs 732 | 733 | An ECU SHALL perform the following steps when attempting to install a new image: 734 | 735 | 1. Verify latest attested time. This is optional if the ECU does not have the capacity to verify a time message ({{verify_time}}) 736 | 2. Verify metadata ({{verify_metadata}}) 737 | 3. Download latest image ({{download_image}}) 738 | 4. Verify image ({{verify_image}}) 739 | 5. Install image ({{install_image}}) 740 | 6. Create and send version report ({{create_version_report}}) 741 | 742 | #### Load and verify the latest attested time {#verify_time} 743 | 744 | IF the ECU has the capability to verify a time message, the ECU SHOULD load and verify the current time, or the most recent securely attested time. 745 | 746 | #### Verify metadata {#verify_metadata} 747 | 748 | The ECU SHALL verify the latest downloaded metadata ({{metadata_verification}}) using either full or partial verification. If the metadata verification fails for any reason, the ECU SHALL jump to the final step ({{create_version_report}}). 749 | 750 | #### Download latest image {#download_image} 751 | 752 | If the ECU has limited secondary storage, i.e., insufficient buffer storage to temporarily store the latest image before installing it, it SHALL download the latest image from the Primary. (If the ECU has sufficient secondary storage, it will already have the latest image in its secondary storage as specified in {{send_images_primary}}, and SHALL skip to the next step.) The ECU SHOULD first create a backup of its previous working image and store it elsewhere (e.g., the Primary). 753 | 754 | The filename used to identify the latest known image (i.e., the file to request from the Primary) SHALL be determined as follows: 755 | 756 | 1. Load the Targets metadata file from the Director repository. 757 | 2. Find the Targets metadata associated with this ECU identifier. 758 | 3. Construct the Image filename using the rule in {{metadata_filename_rules}}, or use the download URL specified in the Director metadata. 759 | 4. If there is no Targets metadata about this image, abort the update cycle and report that there is no such image. Additionally, in the case of failure, the ECU SHALL retain its previous Targets metadata instead of using the new Targets metadata. Otherwise, download the image (up to the number of bytes specified in the Targets metadata) and verify it according to {{verify_image}}. 760 | 761 | When the Primary responds to the download request, the ECU SHALL overwrite its current image with the downloaded image from the Primary. 762 | 763 | If any part of this step fails, the ECU SHALL jump to the final step ({{create_version_report}}). 764 | 765 | #### Verify image {#verify_image} 766 | 767 | The ECU SHALL verify that the latest image matches the latest metadata as follows: 768 | 769 | 1. Load the latest Targets metadata file from the Director. 770 | 2. Find the Targets metadata associated with this ECU identifier. 771 | 3. Check that the hardware identifier in the metadata matches the ECU's hardware identifier. 772 | 4. Check that the image filename is valid for this ECU. This could be a comparison against a wildcard path, which restricts the ECUs to which a delegation will apply. 773 | 5. Check that the release counter of the image in the previous metadata, if it exists, is less than or equal to the release counter in the latest metadata. 774 | 6. If the image is encrypted, decrypt the image with a decryption key to be chosen as follows: 775 | * If the ECU key is a symmetric key, the ECU SHALL use the ECU key for image decryption. 776 | * If the ECU key is asymmetric, the ECU SHALL check the Targets metadata for an encrypted symmetric key. If such a key is found, the ECU SHALL decrypt the symmetric key using its ECU key, and use the decrypted symmetric key for image decryption. 777 | * If the ECU key is asymmetric and there is no symmetric key in the Targets metadata, the ECU SHALL use its ECU key for image decryption. 778 | 7. Check that all hashes listed in the metadata match the corresponding hashes of the image. 779 | 780 | If the ECU has enough secondary storage capacity to store the image, the checks SHOULD be performed on the image in secondary storage before it is installed. 781 | 782 | When checking hashes, the ECU SHALL additionally check that the length of the image matches the length listed in the metadata. 783 | 784 | NOTE: See {{DEPLOY}} for guidance on how to deal with Secondary ECU failures for ECUs that have limited secondary storage. 785 | 786 | If any step fails, the ECU SHALL jump to the final step ({{create_version_report}}). 787 | 788 | 789 | #### Install image {#install_image} 790 | 791 | The ECU SHALL attempt to install the update. This installation SHOULD occur at a time when all pre-conditions are met. These pre-conditions could include ensuring the vehicle is in a safe environment for an installation (e.g., the vehicle is parked when updating a specific ECU). Other pre-conditions could include ensuring the ECU has a backup of its current image and metadata in case the current installation fails. 792 | 793 | #### Create and send version report {#create_version_report} 794 | 795 | The ECU SHALL create a version report as described in {{version_report}}, 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. 796 | 797 | ### Metadata verification procedures {#metadata_verification} 798 | 799 | A Primary ECU SHALL perform full verification of metadata. A Secondary ECU SHOULD perform full verification of metadata. If a Secondary cannot perform full verification, it SHALL, at the very least, perform partial verification. 800 | 801 | If a step in the following workflows does not succeed (e.g., the update is aborted because a new metadata file was not signed), an ECU SHOULD still be able to update again in the future. Errors raised during the update process SHOULD NOT leave ECUs in an unrecoverable state. 802 | 803 | #### Partial verification {#partial_verification} 804 | 805 | In order to perform partial verification, an ECU SHALL perform the following steps: 806 | 807 | 1. Load the current time or the most recent securely attested time. The time SHOULD be loaded from a source other than the Primary ECU. 808 | 2. Download and check the Targets metadata file from the Director repository, following the procedure in {{check_targets}}. 809 | 810 | Note that this verification procedure is the smallest set of Uptane checks permissible for an Uptane Secondary ECU. An ECU can additionally implement more metadata checks. 811 | 812 | For example, an ECU could also fetch and verify Root metadata from the Director (following the procedure in {{check_root}}) before checking Targets metadata. Performing this additional check would provide the ECU with a secure way to receive and validate a rotation of the Director's Targets key. 813 | 814 | See {{DEPLOY}} for more discussion on this topic. 815 | 816 | #### Full verification {#full_verification} 817 | 818 | Full verification of metadata means that the ECU checks that the Targets metadata about images from the Director repository matches the Targets metadata about the same images from the Image repository. This provides resilience to a key compromise in the system. 819 | 820 | Full verification SHALL be performed by Primary ECUs and SHOULD be performed by Secondary ECUs. In the following instructions, whenever an ECU is directed to download metadata, it applies only to Primary ECUs. 821 | 822 | Before starting full verification, the repository mapping metadata SHALL be consulted to determine where to download metadata from. This procedure assumes the basic Uptane case: there are only two repositories (Director and Image), and all image paths are required to be signed by both repositories. If a more complex repository layout is being used, refer to {{DEPLOY}} for guidance on how to determine where metadata could be downloaded from. 823 | 824 | In order to perform full verification, an ECU SHALL perform the following steps: 825 | 826 | 1. Load the current time or the most recent securely attested time. Secondary ECUs SHOULD load a time from a source other than the Primary ECU. 827 | 1. Download and check the Root metadata file from the Director repository, following the procedure in {{check_root}}. 828 | 1. Download and check the Timestamp metadata file from the Director repository, following the procedure in {{check_timestamp}}. 829 | 1. Check the previously downloaded Snapshot metadata file from the Directory repository (if available). If the hashes and version number of that file match the hashes and version number listed in the new Timestamp metadata, there are no new updates and the verification process SHALL be stopped and considered complete. Otherwise, download and check the Snapshot metadata file from the Director repository, following the procedure in {{check_snapshot}}. 830 | 1. Download and check the Targets metadata file from the Director repository, following the procedure in {{check_targets}}. 831 | 1. If the Targets metadata from the Directory repository indicates that there are no new targets that are not already currently installed, the verification process SHOULD be stopped and considered complete. Optionally, implementors can order vehicles to check image repo root metadata when desirable, even in the absence of an update. Otherwise, download and check the Root metadata file from the Image repository, following the procedure in {{check_root}}. 832 | 1. Download and check the Timestamp metadata file from the Image repository, following the procedure in {{check_timestamp}}. 833 | 1. Check the previously downloaded Snapshot metadata file from the Image repository (if available). If the hashes and version number of that file match the hashes and version number listed in the new Timestamp metadata, the ECU SHALL skip to the last step. Otherwise, download and check the Snapshot metadata file from the Image repository, following the procedure in {{check_snapshot}}. 834 | 1. Download and check the top-level Targets metadata file from the Image repository, following the procedure in {{check_targets}}. 835 | 1. Verify that Targets metadata from the Director and Image repositories match. A Primary ECU SHALL perform this check on metadata for all images listed in the Targets metadata file from the Director repository downloaded in step 6. A Secondary ECU can elect to perform this check only on the metadata for the image it will install. (That is, the image metadata from the Director that contains the ECU identifier of the current ECU.) To check that the metadata for an image matches, complete the following procedure: 836 | 1. Locate and download a Targets metadata file from the Image repository that contains an image with exactly the same filename listed in the Director metadata, following the procedure in {{resolve_delegations}}. 837 | 2. Check that the Targets metadata from the Image repository matches the Targets metadata from the Director repository: 838 | 1. Check that the non-custom metadata (i.e., length and hashes) of the unencrypted or encrypted image are the same in both sets of metadata. Note: the Primary is responsible for validating encrypted images and associated metadata. The target ECU (Primary or Secondary) is responsible for validating the unencrypted image and associated metadata. 839 | 1. Check that all SHALL match custom metadata (e.g., hardware identifier and release counter) are the same in both sets of metadata. 840 | 1. Check that the release counter, if one is used, in the previous Targets metadata file is less than or equal to the release counter in this Targets metadata file. 841 | 842 | If any step fails, the ECU SHALL return an error code indicating the failure. If a check for a specific type of security attack fails (i.e., rollback, freeze, arbitrary software, etc.), the ECU SHOULD return an error code that indicates the type of attack. 843 | 844 | #### How to check Root metadata {#check_root} 845 | 846 | To properly check Root metadata, an ECU SHOULD: 847 | 848 | 1. Load the previous Root metadata file. 849 | 2. Update to the latest Root metadata file. 850 | 1. Let N denote the version number of the latest Root metadata file (which at first could be the same as the previous Root metadata file). 851 | 2. Try downloading a new version N+1 of the Root metadata file, up to some X number of bytes. The value for X is set by the implementer. For example, X could be tens of kilobytes. The filename used to download the Root metadata file is of the fixed form VERSION_NUMBER.FILENAME.EXT (e.g., 42.root.json). If this file is not available, the current Root metadata file is the latest; continue with step 3. 852 | 3. Version N+1 of the Root metadata file SHALL have been signed by the following: (1) a threshold of unique keys specified in the latest Root metadata file (version N), and (2) a threshold of unique keys specified in the new Root metadata file being validated (version N+1). If version N+1 is not signed as required, discard it, abort the update cycle, and report the signature failure. On the next update cycle, begin at version N of the Root metadata file. (Checks for an arbitrary software attack.) 853 | 4. The version number of the latest Root metadata file (version N) SHALL be less than or equal to the version number of the new Root metadata file (version N+1). Effectively, this means checking that the version number signed in the new Root metadata file is indeed N+1. If the version of the new Root metadata file is less than the latest metadata file, discard it, abort the update cycle, and report the rollback attack. On the next update cycle, begin at step 1 and version N of the Root metadata file. (Checks for a rollback attack.) 854 | 5. Set the latest Root metadata file to the new Root metadata file. 855 | 6. Repeat steps 2.1 to 2.6. 856 | 3. Check that the current (or latest securely attested) time is lower than the expiration timestamp in the latest Root metadata file. (Checks for a freeze attack.) 857 | 4. If the Timestamp and/or Snapshot keys have been rotated, delete the previous Timestamp and Snapshot metadata files. (Checks for recovery from fast-forward attacks {{MERCURY}}.) 858 | 859 | #### How to check Timestamp metadata {#check_timestamp} 860 | 861 | To properly check Timestamp metadata, an ECU SHOULD: 862 | 863 | 1. Download up to Y number of bytes. The value for Y is set by the implementer. For example, Y could be tens of kilobytes. The filename used to download the Timestamp metadata file is of the fixed form FILENAME.EXT (e.g., timestamp.json). 864 | 2. Check that it has been signed by the threshold of unique keys specified in the latest Root metadata file. If the new Timestamp metadata file is not properly signed, discard it, abort the update cycle, and report the signature failure. (Checks for an arbitrary software attack.) 865 | 3. Check that the version number of the previous Timestamp metadata file, if any, is less than or equal to the version number of this Timestamp metadata file. If the new Timestamp metadata file is older than the trusted Timestamp metadata file, discard it, abort the update cycle, and report the potential rollback attack. (Checks for a rollback attack.) 866 | 4. Check that the current (or latest securely attested) time is lower than the expiration timestamp in this Timestamp metadata file. If the new Timestamp metadata file has expired, discard it, abort the update cycle, and report the potential freeze attack. (Checks for a freeze attack.) 867 | 868 | 869 | #### How to check Snapshot metadata {#check_snapshot} 870 | 871 | To properly check Snapshot metadata, an ECU SHOULD: 872 | 873 | 1. Download up to the number of bytes specified in the Timestamp metadata file, constructing the metadata filename as defined in {{metadata_filename_rules}}. 874 | 2. The hashes and version number of the new Snapshot metadata file SHALL match the hashes and version number listed in the Timestamp metadata. If the hashes and version number do not match, discard the new Snapshot metadata, abort the update cycle, and report the failure. (Checks for a mix-and-match attack.) 875 | 3. Check that it has been signed by the threshold of unique keys specified in the latest Root metadata file. If the new Snapshot metadata file is not signed as required, discard it, abort the update cycle, and report the signature failure. (Checks for an arbitrary software attack.) 876 | 4. Check that the version number of the previous Snapshot metadata file, if any, is less than or equal to the version number of this Snapshot metadata file. If this Snapshot metadata file is older than the previous Snapshot metadata file, discard it, abort the update cycle, and report the potential rollback attack. (Checks for a rollback attack.) 877 | 5. Check that the version number listed by the previous Snapshot metadata file for each Targets metadata file is less than or equal to its version number in this Snapshot metadata file. If this condition is not met, discard the new Snapshot metadata file, abort the update cycle, and report the failure. (Checks for a rollback attack.) 878 | 6. Check that each Targets metadata filename listed in the previous Snapshot metadata file is also listed in this Snapshot metadata file. If this condition is not met, discard the new Snapshot metadata file, abort the update cycle, and report the failure. (Checks for a rollback attack.) 879 | 7. Check that the current (or latest securely attested) time is lower than the expiration timestamp in this Snapshot metadata file. If the new Snapshot metadata file is expired, discard it, abort the update cycle, and report the potential freeze attack. (Checks for a freeze attack.) 880 | 881 | #### How to check Targets metadata {#check_targets} 882 | 883 | To properly check Targets metadata, an ECU SHOULD: 884 | 885 | 1. Download up to Z number of bytes, constructing the metadata filename as defined in {{metadata_filename_rules}}. The value for Z is set by the implementer. For example, Z could be tens of kilobytes. 886 | 1. The version number of the new Targets metadata file SHALL match the version number listed in the latest Snapshot metadata. If the version number does not match, discard it, abort the update cycle, and report the failure. (Checks for a mix-and-match attack.) This step can be skipped when checking Targets metadata on a partial verification ECU, as these ECUs might not have Snapshot metadata. 887 | 1. Check that the Targets metadata has been signed by the threshold of unique keys specified in the relevant metadata file. (Checks for an arbitrary software attack.): 888 | 1. If checking top-level Targets metadata, the threshold of keys is specified in the Root metadata. 889 | 1. If checking delegated Targets metadata, the threshold of keys is specified in the Targets metadata file that delegated authority to this role. 890 | 1. Check that the version number of the previous Targets metadata file, if any, is less than or equal to the version number of this Targets metadata file. (Checks for a rollback attack.) 891 | 1. Check that the current (or latest securely attested) time is lower than the expiration timestamp in this Targets metadata file. (Checks for a freeze attack.) 892 | 1. If checking Targets metadata from the Director repository, verify that there are no delegations. 893 | 1. If checking Targets metadata from the Director repository, check that no ECU identifier is represented more than once. 894 | 1. If checking Targets metadata from the Director repository, and the ECU performing the verification is the Primary ECU, check that all listed ECU identifiers correspond to ECUs that are actually present in the vehicle. 895 | 896 | #### How to resolve delegations {#resolve_delegations} 897 | 898 | To properly check Targets metadata for an image, an ECU SHALL locate the metadata file(s) for the role (or roles) that have the authority to sign the image. This metadata might be located in the top-level Targets metadata, but it could also be delegated to another role or to multiple roles. Therefore, all delegations SHALL be resolved using the following recursive procedure, beginning with the top-level Targets metadata file. 899 | 900 | 1. Download and check the current metadata file, following the procedure in {{check_targets}}. If the file cannot be loaded, or if any verification step fails, abort the delegation resolution, and indicate that image metadata cannot be found because of a missing or invalid role. 901 | 2. If the current metadata file contains signed metadata about the image, end the delegation resolution and return the metadata to be checked. 902 | 3. If the current metadata file was reached via a terminating delegation and does not contain signed metadata about the image, abort the delegation resolution for this image and return an error indicating that image metadata could not be found. 903 | 4. Search the list of delegations, in listed order. For each delegation: 904 | 1. Check if the delegation applies to the image being processed. For the delegation to apply, it SHALL include the hardware identifier of the target, and the target name SHALL match one of the delegation's image paths. If either of these tests fail, move on to the next delegation in the list. 905 | 2. If the delegation is a multi-role delegation, follow the procedure described in {{multirole_delegations}}. If the multi-role delegation is terminating and no valid image metadata is found, abort the delegation resolution and return an error indicating that image metadata could not be found. 906 | 3. If the delegation is a normal delegation, perform delegation resolution, starting at step 1. Note that this could recurse an arbitrary number of levels deep. If a delegation that applies to the image is found but no image metadata is found in the delegated roles or any of its sub-delegations, simply continue on with the next delegation in the list. The search is only completed or aborted if image metadata or a terminating delegation that applies to the image is found. 907 | 5. If the end of the list of delegations in the top-level metadata is reached without finding valid image metadata, return an error indicating that image metadata could not be found. 908 | 909 | #### Multi-role delegations {#multirole_delegations} 910 | 911 | It is possible to delegate signing authority to multiple delegated roles as described in {{TAP-3}}. Each multi-role delegation effectively contains a list of ordinary delegations, plus a threshold of those roles that SHALL be in agreement about the non-custom metadata for the image. All multi-role delegations SHALL be resolved using the following procedure. Note that there could be sub-delegations inside multi-role delegations. 912 | 913 | 1. For each of the roles in the delegation, find and load the image metadata following the procedure in {{resolve_delegations}}. 914 | 2. Inspect the non-custom part of the metadata loaded in step 1: 915 | 1. Locate all sets of roles that have agreeing (i.e., identical) non-custom metadata and "SHALL match" custom metadata. Discard any set of roles with a size smaller than the threshold of roles that SHALL be in agreement for this delegation. 916 | 2. Check for a conflict. A conflict exists if there is more than one agreeing set of roles, yet each set has different metadata. If a conflict is found, choose and return the metadata from the set of roles that include the earliest role in the multi-delegation list. 917 | 3. If there is no conflict, check if there is any single set of roles with matching non-custom metadata. If there is, choose and return the metadata from this set. 918 | 4. If no agreeing set can be found that meets the agreement threshold, return an error indicating that image metadata could not be found. 919 | 920 | 935 | -------------------------------------------------------------------------------- /release-artifacts/ieee-isto-6100.1.0.0.uptane-standard.html: -------------------------------------------------------------------------------- 1 | 3 | 4 | 5 | 6 | 7 | 8 | IEEE-ISTO 6100.1.0.0 Uptane Standard for Design and Implementation 9 | 10 | 375 | 376 | 377 | 378 | 379 | 380 | 381 | 382 | 383 | 384 | 385 | 386 | 387 | 388 | 389 | 390 | 391 | 392 | 393 | 394 | 395 | 396 | 397 | 398 | 399 | 400 | 401 | 402 | 403 | 404 | 405 | 406 | 407 | 408 | 409 | 410 | 411 | 412 | 413 | 414 | 415 | 416 | 417 | 418 | 419 | 420 | 421 | 422 | 423 | 424 | 425 | 426 | 427 | 428 | 429 | 430 | 431 | 432 | 433 | 434 | 435 | 436 | 437 | 438 | 439 | 440 | 441 |

IEEE-ISTO 6100.1.0.0 Uptane Standard for Design and Implementation
442 | uptane-standard-design

443 | 444 |

Abstract

445 |

This document describes a framework for securing ground vehicle software update systems.

446 | 447 | 448 |
449 |

Table of Contents

450 | 551 | 552 |

553 | 1. Introduction 554 |

555 |

Uptane is a secure software update framework for ground vehicles. This document describes procedures to enable programmers for OEMs and suppliers to securely design and implement this framework in a manner that better protects connected units on ground vehicles. Integrating Uptane as outlined in the sections that follow can reduce the ability of attackers to compromise critical systems. It also assures a faster and easier recovery process should a compromise occur.

556 |

These instructions specify the components necessary for a compliant implementation. Individual implementors can make their own technological choices within those requirements. This flexibility makes Uptane adaptable to the many customized update solutions used by manufacturers. If implementors wish to have compatible formats, they may use POUFs. POUFs contain a description of implementation choices as well as data binding formats. An implementor who adopts a POUF, as well as the Uptane Standard, will be able to interoperate with other implementations using that POUF.

557 |

558 | 2. Terminology 559 |

560 |

561 | 2.1. Conformance terminology 562 |

563 |

The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL in this document are to be interpreted as described in [RFC2119].

564 |

In order to be considered “Uptane-compliant,” an implementation MUST follow all of these rules as specified in the document.

565 |

566 | 2.2. Terminology 567 |

568 |

Bundle: A set of images released by the repository that is meant to be installed by one or more target ECUs on a vehicle during the same update cycle.

569 |

Bus: An internal communications network that interconnects components within a vehicle. A vehicle can have a number of buses that will vary in terms of power, speed and resources.

570 |

ECU Identifier: An attribute used to identify a specific ECU (e.g., such as a unique serial number).

571 |

ECU Version Manifest: Metadata which details the software version currently installed on the ECU.

572 |

Hardware Identifier: An attribute used to identify a model of an ECU.

573 |

Image: File containing software for an ECU to install. May contain a binary image to flash, installation instructions, and other necessary information for the ECU to properly apply the update. Each ECU typically holds only one image, although this may vary in some cases.

574 |

Metadata: Information describing the characteristics of data including, for example, structural metadata describing data structures (e.g., data format, syntax, and semantics) and descriptive metadata describing data contents (e.g., information security labels). As used in Uptane, metadata can be described as information associated with a role or an image that contains the characteristics or parameters thereof (e.g. cryptographic material parameters, file names and versions.)

575 |

Primary/Secondary ECUs: Terms used to describe the control units within a ground vehicle. A primary ECU downloads and verifies update images and metadata for itself and for secondary ECUs, and distributes images and metadata to secondaries. Thus, it requires extra storage space and a means to download images and metadata. Secondary ECUs receive their update images and metadata from the primary, and only need to verify and install their own metadata and images.

576 |

POUF: A document that contains the protocol, operations, usage, and formats (POUF) of a specific Uptane implementation. The POUF contains decisions about SHOULDs and MAYs in an implementation, as well as descriptions of data binding formats. POUFs MAY be used to create compatible Uptane implementations.

577 |

Repository: A server containing metadata about images. May also contain the images themselves. Other data may be stored on the repository to be accessed by ECUs during the update process.

578 |

Suppliers: Independent companies to which auto manufacturers may outsource the production of ECUs. Tier-1 suppliers directly serve the manufacturers. Tier-2 suppliers are those that perform outsourced work for Tier-1 suppliers.

579 |

Vehicle Version Manifest: A compilation of all ECU version manifests on a vehicle. It serves as a master list of all images currently running on all ECUs in the vehicle.

580 |

581 | 2.3. Uptane Role terminology 582 |

583 |

These terms are defined in greater detail in Section 5.1.

584 |

Delegations: A process by which the responsibility of signing metadata about images is assigned to another party.
Role: A party (human or machine) responsible for signing a certain type of metadata. The role controls keys and is responsible for signing metadata entrusted to it with these keys. The roles mechanism of Uptane allows the system to distribute signing responsibilities so that the compromise of one key does not necessarily impact the security of the entire system.

585 |

586 | 587 | 597 |

598 | 2.4. Acronyms and abbreviations 599 |

600 |

CAN Bus: Controller Area Network bus standard

601 |

CDN: Content Delivery Network

602 |

ECUs: Electronic Control Units, the computing units on a vehicle

603 |

LIN Bus: Local Interconnect Bus

604 |

OBD: On-board diagnostics

605 |

SOTA: Software Updates Over-the-Air

606 |

UDS: Unified Diagnostic Services

607 |

VIN: Vehicle Identification Number

608 |

609 | 3. Rationale for and scope of Uptane Standards 610 |

611 |

This Standards document clarifies the essential components and best practices for the secure design, implementation and deployment of Uptane by OEMs and suppliers. These practices contribute to compromise resilience, or the ability to minimize the extent of the threat posed by any given attack.

612 |

However, this specification is intended as an implementation guide, and not as a detailed technical argument about the security properties that Uptane provides. Readers interested in such documentation should refer to published papers that cover this topic. [UPTANEESCAR]

613 |

614 | 3.1. Why Uptane requires a standards document 615 |

616 |

A standards document that can guide the safe design, integration and deployment of Uptane in vehicles is needed at this time because:

617 |

618 | 619 | 630 |

631 | 3.2. Scope of Standards coverage 632 |

633 |

This document sets guidelines for implementing Uptane in most systems capable of updating software on connected units in ground vehicles, including passenger vehicles, light-duty trucks, heavy-duty trucks, and motorcycles. Uptane could potentially also be applied to other ground vehicles, such as automated shuttles, recreational vehicles, and military ground vehicles. Uptane could even be applied to domains such as IoT devices, medical devices, and unmanned aerial vehicles. In this section, we define the scope of that applicability by providing sample use cases and possible exceptions, aspects of software update security that are not applicable to Uptane, and the design requirements governing the preparation of these standards.

634 |

635 | 3.2.1. Assumptions 636 |

637 |

We assume the following system preconditions for Uptane:

638 |

639 | 640 | 647 |

It is important that any bugs detected in Uptane implementations be patched promptly. Failure to do so could interfere with the effectiveness of Uptane’s operations.

648 |

649 | 3.2.2. Use cases 650 |

651 |

The following use cases provide a number of scenarios illustrating the manner in which software updates could be accomplished using Uptane.

652 |

653 | 3.2.2.1. OEMs initializing Uptane at the factory using SOTA 654 |

655 |

An OEM plans to install Uptane on new vehicles. This entails the following components: code to perform full and partial verification, the latest copy of the relevant metadata, the public keys, and an accurate attestation of the latest time. The OEM then either requires its tier-1 suppliers to provide these materials to the suppliers’ assembly lines or can choose to add the materials later at the OEM’s assembly lines. The OEM’s implementation is Uptane-compliant if:

656 |

657 | 658 |
    659 |
  1. all primaries perform full verification;
    2. 660 |
  2. all secondaries that are updated via OTA perform full or partial verification; and
    3. 661 |
  3. all other ECUs that do not perform verification cannot be updated via OTA.
    4. 662 |
663 |

664 | 3.2.2.2. Updating one ECU with a complete image 665 |

666 |

A tier-1 supplier completes work on a revised image for an electronic brake control module. This module will control the brakes on all models of an SUV produced by the OEM mentioned above. Assuming supplier delegation is supported by the OEM for this ECU, each tier-1 supplier digitally signs the image, then delivers the signature and all of its metadata, including delegations, and associated images to the OEM. The OEM adds these metadata and images to its image repository, along with information about any dependencies and conflicts between this image and those for other ECUs used in the OEM’s vehicles. The OEM also updates the inventory database, so that the director repository can instruct the ECU on how to install these updated images.

667 |

668 | 3.2.2.3. Updating individual ECUs on demand 669 |

670 |

An OEM has issued a recall to address a problem with a keyless entry device that has been locking people out of their cars. The OEM prepares an updated flash image in the manner described above. The OEM then ships USB flash drives to vehicle owners and dealerships that allow those parties to update the firmware of their vehicles.

671 |

672 | 3.2.2.4. Update one ECU with multiple deltas 673 |

674 |

The OEM wants to use delta updates to save over-the-air bytes. The delta images contain only the code and/or data that has changed from the previous image version. To do so, the OEM must first modify the Director repository, using the vehicle version manifest and dependency resolution to determine the differences between the previous and latest images. The OEM then adds the following to the custom Targets metadata used by the Director repository: (1) the algorithm used to apply a delta image, and (2) the Targets metadata about the delta image. The OEM will also check whether the delta images match the Targets metadata from the Director repository.

675 |

676 | 3.3. Exceptions 677 |

678 |

There are a number of factors that could impede the completion of the above scenarios:

679 |

680 | 681 | 690 |

691 | 3.4. Out of Scope 692 |

693 |

The following topics will not be addressed in this document, as they represent threats outside the scope of Uptane:

694 |

695 | 696 | 702 |

703 | 3.5. Design requirements 704 |

705 |

The design requirements for this document are governed by the following principal parameters:

706 |

707 | 708 | 713 |

714 | 4. Threat model and attack strategies 715 |

716 |

The overarching goal of Uptane is to provide a system that is resilient in the face of various types of compromise. In this section, we describe the goals an attacker may have (Section 4.1) and the capabilities they may have or could develop (Section 4.2). We then describe and classify types of attacks on the system according to the attacker’s goals (Section 4.3).

717 |

718 | 4.1. Attacker goals 719 |

720 |

We assume that attackers may want to achieve one or more of the following goals, in increasing order of severity:

721 |

722 | 723 | 729 |

730 | 4.2. Attacker capabilities 731 |

732 |

Uptane is designed with resilience to compromise in mind. We assume that attackers may develop one or more of the following capabilities:

733 |

734 | 735 | 744 |

745 | 4.3. Description of threats 746 |

747 |

Uptane’s threat model includes the following types of attacks, organized according to the attacker goals listed in Section 4.1.

748 |

749 | 4.3.1. Read updates 750 |

751 |

752 | 753 | 755 |

756 | 4.3.2. Deny installation of updates 757 |

758 |

An attacker seeking to deny the installation of updates may attempt one or more of the following strategies, among others:

759 |

760 | 761 | 772 |

773 | 4.3.3. Interfere with ECU functionality 774 |

775 |

Attackers seeking to interfere with the functionality of vehicle ECUs in order to cause an operational failure or unexpected behavior may do so in one of the following ways:

776 |

777 | 778 | 786 |

787 | 4.3.4. Control an ECU or vehicle 788 |

789 |

Full control of a vehicle, or one or more ECUs within a vehicle, is the most severe threat.

790 |

791 | 792 | 794 |

795 | 5. Detailed design of Uptane 796 |

797 |

Uptane is a secure software update framework for automobiles. We do not specify implementation details. Instead, we describe the components necessary for a compliant implementation and leave it up to individual implementors to make their own technological choices within those requirements.

798 |

At a high level, Uptane requires:

799 |

800 | 801 | 820 |

821 | 5.1. Roles on repositories 822 |

823 |

A repository contains images and metadata. Each role has a particular type of metadata associated with it, as described in Section 5.2.

824 |

825 | 5.1.1. The Root role 826 |

827 |

A repository’s Root role SHALL be responsible for a Certificate Authority as defined in [RFC3647]. A repository’s Root role SHALL produce and sign Root metadata as described in Section 5.2.2. A repository’s Root role SHALL sign the public keys used to verify the metadata produced by the Timestamp, Snapshot, and Targets roles. A repository’s Root role SHALL revoke keys for the other roles, in case of compromise.

828 |

829 | 5.1.2. The Targets role 830 |

831 |

A repository’s Targets role SHALL produce and sign metadata about images and delegations as described in Section 5.2.3.

832 |

833 | 5.1.2.1. Delegations 834 |

835 |

The Targets role on the Image repository MAY delegate the responsibility of signing metadata to other, custom-defined roles referred to as delegated targets. If it does, it MUST do so as specified in Section 5.2.3.2.

836 |

Responsibility for signing images or a subset of images MAY be delegated to more than one role and therefore it is possible for two different roles to be trusted for signing a particular image. For this reason, delegations MUST be prioritized.

837 |

A particular delegation for a subset of images MAY be designated as terminating. For terminating delegations, the client SHALL NOT search any further if it does not find validly signed metadata about those images. Delegations SHOULD NOT be terminating by default; terminating delegations SHOULD only be used when there is a compelling technical reason to do so.

838 |

A delegation for a subset of images MAY be a multi-role delegation [TAP-3]. A multi-role delegation indicates that multiple roles are needed to sign a particular image and each of the delegatee roles MUST sign the same metadata.

839 |

Delegations only apply to the Image repository. The Targets role on the Director repository MUST NOT delegate metadata signing responsibility.

840 |

841 | 5.1.3. The Snapshot role 842 |

843 |

A repository’s Snapshot role SHALL produce and sign metadata about all Targets metadata the repository releases, including the current version number of the top-level Targets metadata, and the version numbers of all delegated Targets metadata, as described in Section 5.2.4.

844 |

845 | 5.1.4. The Timestamp role 846 |

847 |

A repository’s Timestamp role SHALL produce and sign metadata indicating whether there are new metadata or images on the repository. It MUST do so by signing the metadata about the Snapshot metadata file.

848 |

849 | 5.2. Metadata structures 850 |

851 |

Uptane’s security guarantees all rely on properly created metadata that follows a designated structure. The Uptane standard does not mandate any particular format or encoding for the metadata as a whole. ASN.1 (with any encoding scheme like BER, DER, XER, etc.), JSON, XML, or any other encoding format that is capable of providing the required structure MAY be used.

852 |

However, string comparison is required as part of metadata verification. To ensure an accurate basis for comparing strings, all strings MUST be encoded in the Unicode Format for Network Interchange as defined in [RFC5198], including normalization into Unicode Normalization Form C ([NFC]).

853 |

In the Deployment Considerations document, the Uptane Alliance provides some examples of compliant metadata structures in ASN.1 and JSON.

854 |

855 | 5.2.1. Common metadata structures 856 |

857 |

Every public key MUST be represented using a public key identifier. A public key identifier is EITHER all of the following:

858 |

859 | 860 | 865 |

OR a secure hash over at least the above components (such as the keyid mechanism in TUF).

866 |

All four Uptane roles (Root, Targets, Snapshot, and Timestamp) share a common structure. They SHALL contain the following two attributes:

867 |

868 | 869 | 877 |

The payload differs depending on the role. However, the payload for all roles shares a common structure. It SHALL contain the following four attributes:

878 |

879 | 880 | 886 |

The following sections describe the role-specific metadata. All roles SHALL follow the common structures described here.

887 |

888 | 5.2.2. Root metadata 889 |

890 |

A repository’s Root metadata distributes the public keys of the top-level Root, Targets, Snapshot, and Timestamp roles, as well as revocations of those keys. It SHALL contain two attributes:

891 |

892 | 893 | 897 |

Additionally, it MAY contain a mapping of roles to a list of valid URLs from which the role metadata can be downloaded. If this mapping of URLs is used, the implementer SHOULD implement this functionality following [TAP-5] to avoid adding unforeseen security risks.

898 |

899 | 5.2.3. Targets metadata 900 |

901 |

The Targets metadata on a repository contains all of the information about images to be installed on ECUs. This includes filenames, hashes, file sizes, and MAY also include other useful information about images, such as what types of hardware are compatible with a particular image.

902 |

Targets metadata can also contain metadata about delegations, allowing one Targets role to delegate its authority to another. This means that an individual Targets metadata file might contain only metadata about delegations, only metadata about images, or some combination of the two. The details of how ECUs traverse the delegation tree to find valid metadata about images is specified in Section 5.4.4.7.

903 |

904 | 5.2.3.1. Metadata about images 905 |

906 |

To be available to install on clients, all images on the repository MUST have their metadata listed in a Targets role. Each Targets role MAY provide a list of some images on the repository. This list MUST provide, at a minimum, the following information about each image:

907 |

908 | 909 | 914 |

915 | 5.2.3.1.1. Custom metadata about images 916 |

917 |

In addition to the required metadata, Targets metadata files MAY contain extra metadata for images on the repository. This metadata can be customized for a particular use case. Examples of use cases for different types of custom metadata can be found in the Deployment Considerations document. However, there are a few important pieces of custom metadata that SHOULD be present in most implementations. In addition, there is one element in the custom metadata that MUST be present in the Targets metadata from the Director.

918 |

Custom metadata MAY also contain a demarcated field or section that MUST match whenever two pieces of metadata are checked against each other, such as when Targets metadata from the Director repository is checked against Targets metadata from the Image repository.

919 |

The information listed below SHOULD be provided for each image on both the Image repository and the Director repository. If a “MUST match section” is to be implemented, that is where this information SHOULD be placed.

920 |

921 | 922 | 926 |

The following information is CONDITIONALLY REQUIRED for each image on the Director repository IF that image is encrypted:

927 |

928 | 929 | 933 |

The following information MUST be provided for each image in the Targets metadata from the Director repository:

934 |

935 | 936 | 937 |

The Director repository MAY provide a download URL for the image file. This may be useful, for example, when the image is on a public CDN and the director wishes to provide a signed URL.

938 |

939 | 5.2.3.2. Metadata about delegations 940 |

941 |

A Targets metadata file on the Image repository (but not the Director repository) MAY delegate signing authority to other entities. For example, it could delegate signing authority for a particular ECU’s firmware to that ECU’s supplier. A metadata file MAY contain more than one delegation and MUST keep the delegations in prioritized order.

942 |

A list of delegations MUST provide the following information:

943 |

944 | 945 | 960 |

Note that any Targets metadata file stored on the Image repository may contain delegations, and these delegations can be in chains of arbitrary length.

961 |

962 | 5.2.4. Snapshot metadata 963 |

964 |

The Snapshot metadata lists version numbers and filenames of all Targets metadata files. It protects against mix-and-match attacks if a delegated supplier key is compromised.

965 |

For each Targets metadata file on the repository, the Snapshot metadata SHALL contain the following information:

966 |

967 | 968 | 969 |

The Snapshot metadata MAY also list the Root metadata filename and version number. This is not required, particularly for implementations of [TAP-5], but MAY be included in all cases for backward compatibility.

970 |

971 | 5.2.5. Timestamp metadata 972 |

973 |

The Timestamp metadata SHALL contain the following information:

974 |

975 | 976 | 980 |

981 | 5.2.6. Repository mapping metadata 982 |

983 |

As described in the introduction to Section 5, Uptane requires a Director repository and an Image repository. However, it is possible to have an Uptane-compliant implementation that has more than two repositories.

984 |

Repository mapping metadata informs a Primary ECU about which repositories to trust for images or image paths. [TAP-4] describes how to make use of more complex repository mapping metadata in order to have more than the two required repositories.

985 |

Repository mapping metadata, or the equivalent informational content, MUST be present on all Primary ECUs, and MUST contain the following information:

986 |

987 | 988 | 996 |

For example, in the most basic Uptane case, the repository mapping metadata would contain:

997 |

998 | 999 | 1004 |

Note that the metadata need not be in the form of a metadata file. For example, in the basic case where there is only one Director and one Image repository, and all images need to have signed metadata from both repositories, it would be sufficient to have a configuration file with URLs for the two repositories, and a client that always checks for metadata matches between them. In this case, no explicit mapping would be defined, because the mapping is defined as part of the Uptane client implementation.

1005 |

The Deployment Considerations document ([DEPLOY]) gives more guidance on how to implement repository mapping metadata for more complex use cases. It also discusses strategies for updating repository mapping metadata, if required.

1006 |

1007 | 5.2.7. Rules for filenames in repositories and metadata 1008 |

1009 |

There is a difference between the file name in a metadata file or an ECU, and the file name on a repository. This difference exists in order to avoid race conditions, where metadata and images are read from, and written to, at the same time. For more details, the reader should read the TUF specification [TUF-spec] and PEP 458 [PEP-458].

1010 |

Unless stated otherwise, all files SHALL be written to repositories in accordance with the following two rules:

1011 |

1012 | 1013 |
    1014 |
  1. Metadata filenames SHALL be qualified with version numbers. If a metadata file A is specified as FILENAME.EXT in another metadata file B, then it SHALL be written as VERSION.FILENAME.EXT, where VERSION is A’s version number, as defined in Section 5.2.1, with one exception: If the version number of the Timestamp metadata file might not be known in advance by a client, it MAY be read from, and written to, a repository using a filename without a version number qualification, i.e. FILENAME.EXT.
    2. 1015 |
  2. If an image is specified in a Targets metadata file as FILENAME.EXT, it SHALL be written to the repository as HASH.FILENAME.EXT, where HASH is one of the hash digests of the file, as specified in Section 5.2.3.1. The file MUST be written to the repository using n different filenames, one for each hash digest listed in its corresponding Targets metadata.
    3. 1016 |
1017 |

For example:

1018 |

1019 | 1020 | 1024 |

1025 | 5.3. Server / repository implementation requirements 1026 |

1027 |

An Uptane implementation SHALL make the following services available to vehicles:

1028 |

1029 | 1030 | 1034 |

Additionally, an Uptane implementation requires ECUs to have a secure way to know the current time.

1035 |

1036 | 5.3.1. Image repository 1037 |

1038 |

The Image repository exists to allow an OEM and/or its suppliers to upload images and their associated metadata. It makes these images and their metadata available to vehicles. The Image repository is designed to be primarily controlled by human actors, and updated relatively infrequently.

1039 |

The Image repository SHALL expose an interface permitting the download of metadata and images. This interface SHOULD be public.

1040 |

The Image repository SHALL require authorization for writing metadata and images.

1041 |

The Image repository SHALL provide a method for authorized users to upload images and their associated metadata. It SHALL check that a user writing metadata and images is authorized to do so for that specific image by checking the chain of delegations as described in Section 5.2.3.2.

1042 |

The Image repository SHALL implement storage which permits authorized users to write an image file using a unique filename, and later read the same file using the same name. It MAY use any filesystem, key-value store, or database that fulfills this requirement.

1043 |

The Image repository MAY require authentication for read access.

1044 |

1045 | 5.3.2. Director repository 1046 |

1047 |

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.

1048 |

The Director repository SHALL expose an interface for primaries to upload vehicle version manifests (Section 5.4.2.1.1) and download metadata. This interface SHOULD be public. The Director MAY encrypt images for ECUs that require them, either by encrypting on-the-fly or by storing encrypted images in the repository.

1049 |

The Director repository SHALL implement storage which permits an automated service to write generated metadata files. It MAY use any filesystem, key-value store, or database that fulfills this requirement.

1050 |

1051 | 5.3.2.1. Directing installation of images on vehicles 1052 |

1053 |

A Director repository MUST conform to the following six-step process for directing the installation of software images on a vehicle.

1054 |

1055 | 1056 |
    1057 |
  1. The Director SHOULD first identify the vehicle. This MAY be done when the Director receives a vehicle version manifest sent by a Primary (as described in Section 5.4.2.1), decodes the manifest, and determines the unique vehicle identifier. Additionally, the Director MAY utilize other mechanisms to uniquely identify a vehicle (e.g., 2-way TLS with unique client certificates).
    2. 1058 |
  2. Using the vehicle identifier, the Director queries its inventory database (as described in Section 5.3.2.2) for relevant information about each ECU in the vehicle.
    3. 1059 |
  3. The Director SHALL check the manifest for accuracy compared to the information in the inventory database. If any of the required checks fail, the Director MAY drop the request. An implementer MAY make additional checks if desired. At a minimum, the Director SHALL check the following: 1064 |
    4. 1065 |
  4. The Director extracts information about currently installed images from the vehicle version manifest. Using this information, it determines if the vehicle is already up-to-date, and if not, determines a set of images that should be installed. The exact process by which this determination takes place is out of scope of this standard. However, the Director MUST take into account dependencies and conflicts between images and SHOULD consult well-established techniques for dependency resolution.
    5. 1066 |
  5. The Director MAY encrypt images for ECUs that require it.
    6. 1067 |
  6. The Director generates new metadata representing the desired set of images to be installed on the vehicle, based on the dependency resolution in step 4. This includes Targets (Section 5.2.3), Snapshot (Section 5.2.4), and Timestamp (Section 5.2.5) metadata. It then sends this metadata to the Primary as described in Section 5.4.2.3.
    7. 1068 |
1069 |

1070 | 5.3.2.2. Inventory Database 1071 |

1072 |

The Director SHALL use a private inventory database to store information about ECUs and vehicles. An implementor MAY use any durable database for this purpose.

1073 |

The inventory database MUST record the following pieces of information:

1074 |

1075 | 1076 | 1088 |

The inventory database MAY record other information about ECUs and vehicles. It SHOULD record a hardware identifier for each ECU to protect against the possibility of directing the ECU to install incompatible firmware.

1089 |

1090 | 5.4. In-vehicle implementation requirements 1091 |

1092 |

An Uptane-compliant ECU SHALL be able to download and verify Image metadata and image binaries before installing a new image and MUST have a secure way of verifying the current time, or a sufficiently recent attestation of the time.

1093 |

Each ECU in a vehicle receiving over-the-air updates is either a Primary or a Secondary ECU. A Primary ECU collects and delivers vehicle manifests to the Director (Section 5.4.2.1.1) that contain information about which images have been installed on ECUs in the vehicle. It also verifies the time and downloads and verifies the latest metadata and images for itself and for its secondaries. A Secondary ECU verifies the time, and downloads and verifies the latest metadata and images for itself from its associated Primary ECU. It also sends signed information about its installed images to its associated Primary.

1094 |

All ECUs MUST verify image metadata as specified in Section 5.4.4 before installing an image or making it available to other ECUs. A Primary ECU MUST perform full verification (Section 5.4.4.2). A Secondary ECU SHOULD perform full verification if possible. If a Secondary cannot perform full verification, it SHALL perform partial verification. See Uptane Deployment Considerations for a discussion of how to choose between partial and full verification.

1095 |

ECUs MUST have a secure source of time. An OEM/Uptane implementor MAY use any external source of time that is demonstrably secure. The Uptane deployment considerations ([DEPLOY]) describe one way to implement an external time server to cryptographically attest time, as well as the security properties required. When “loading time” is referenced in procedures in this standard, it should be understood to mean loading into memory the current time (if the ECU has its own secure clock), or the most recent attested time.

1096 |

1097 | 5.4.1. Build-time prerequisite requirements for ECUs 1098 |

1099 |

For an ECU to be capable of receiving Uptane-secured updates, it MUST have the following data provisioned at the time it is manufactured or installed in the vehicle:

1100 |

1101 | 1102 |
    1103 |
  1. A sufficiently recent copy of required Uptane metadata at the time of manufacture or install. See Uptane Deployment Considerations for more information. 1107 |
    2. 1108 |
  2. The current time, or a secure attestation of a sufficiently recent time.
    3. 1109 |
  3. An ECU key. This is a private key, unique to the ECU, used to sign ECU version manifests and decrypt images. An ECU key MAY be either a symmetric key or an asymmetric key. If it is an asymmetric key, there MAY be separate keys for encryption and signing. For the purposes of this standard, the set of private keys that an ECU uses is referred to as the ECU key (singular), even if it is actually multiple keys used for different purposes.
    4. 1110 |
1111 |

1112 | 5.4.2. What the Primary does 1113 |

1114 |

A Primary downloads, verifies, and distributes the latest time, metadata and images. To do so, it SHALL perform the following seven steps:

1115 |

1116 | 1117 |
    1118 |
  1. Construct and send vehicle version manifest (Section 5.4.2.1)
    2. 1119 |
  2. Download and check current time (Section 5.4.2.2)
    3. 1120 |
  3. Download and verify metadata (Section 5.4.2.3)
    4. 1121 |
  4. Download and verify images (Section 5.4.2.4)
    5. 1122 |
  5. OPTIONAL: Send latest time to secondaries (Section 5.4.2.5)
    6. 1123 |
  6. Send metadata to Secondaries (Section 5.4.2.6)
    7. 1124 |
  7. Send images to Secondaries (Section 5.4.2.7)
    8. 1125 |
1126 |

Note that the subsequent sections concerning requirements for a Primary do not prohibit implementing Primary capabilities on an ECU that does not communicate directly with the Uptane repositories. This allows for implementations to have multiple ECUs within the vehicle performing functions equivalent to a Primary. If multiple such Primaries are included within a vehicle, each Secondary ECU SHALL have a single Primary responsible for providing its updates.

1127 |

1128 | 5.4.2.1. Construct and send vehicle version manifest 1129 |

1130 |

The Primary SHALL build a vehicle version manifest as described in Section 5.4.2.1.1.

1131 |

Once the complete manifest is built, the Primary MAY send the manifest to the Director repository. However, it is not strictly required that the Primary send the manifest until step three. If permitted by the implementation, a Primary MAY send only a diff of the manifest to save bandwidth. If an implementation permits diffs, the Director SHOULD have a way to request a full manifest.

1132 |

Secondaries MAY send their version report at any time so that it is already stored on the Primary when it wishes to check for updates. Alternatively, the Primary MAY request a version report from each Secondary at the time of the update check.

1133 |

1134 | 5.4.2.1.1. Vehicle version manifest 1135 |

1136 |

The vehicle version manifest is a metadata structure that MUST contain the following information:

1137 |

1138 | 1139 | 1156 |

Note that one of the ECU version reports should be the version report for the Primary itself.

1157 |

1158 | 5.4.2.1.2. ECU version report 1159 |

1160 |

An ECU version report is a metadata structure that MUST contain the following information:

1161 |

1162 | 1163 | 1181 |

1182 | 5.4.2.2. Download and check current time 1183 |

1184 |

The Primary SHALL load the current time from a secure source.

1185 |

1186 | 5.4.2.3. Download and verify metadata 1187 |

1188 |

The Primary SHALL download metadata for all targets and perform a full verification on it as specified in Section 5.4.4.2.

1189 |

1190 | 5.4.2.4. Download and verify images 1191 |

1192 |

The Primary SHALL download and verify images for itself and for all of its associated Secondaries. Images SHALL be verified by checking that the hash of the image file matches the hash specified in the Director’s Targets metadata for that image.

1193 |

There may be several different filenames that all refer to the same image binary, as described in Section 5.2.7. If the primary has received multiple hashes for a given image binary via targets role (see Section 5.2.3.1) then it SHALL verify every hash for this image despite the fact that just one hash is enough to obtain the image itself.

1194 |

1195 | 5.4.2.5. Send latest time to Secondaries 1196 |

1197 |

Unless the Secondary ECU has its own way of verifying the time or does not have the capacity to verify a time message, the Primary is CONDITIONALLY REQUIRED to send the time to each ECU. The Secondary will verify the time message, then overwrite its current time with the received time.

1198 |

1199 | 5.4.2.6. Send metadata to Secondaries 1200 |

1201 |

The Primary SHALL send its latest downloaded metadata to all of its associated Secondaries. The metadata it sends to each Secondary MUST include all of the metadata required for verification on that Secondary. For full verification Secondaries, this includes the metadata for all four roles from both repositories, plus any delegated Targets metadata files the Secondary will recurse through to find the proper delegation. For partial verification Secondaries, this includes only the Targets metadata file from the Director repository.

1202 |

The Primary SHOULD determine the minimal set of metadata files to send to each Secondary by performing delegation resolution as described in Section 5.4.4.2.

1203 |

Each Secondary SHALL store the latest copy of all metadata required for its own verification.

1204 |

1205 | 5.4.2.7. Send images to Secondaries 1206 |

1207 |

The Primary SHALL send the latest image to each of its associated Secondaries that have storage to receive it.

1208 |

For Secondaries without storage, the Primary SHOULD wait for a request from the Secondary to stream the new image file to it. The Secondary will send the request once it has verified the metadata sent in the previous step.

1209 |

1210 | 5.4.3. Installing images on Primary or Secondary ECUs 1211 |

1212 |

An ECU SHALL perform the following steps when attempting to install a new image:

1213 |

1214 | 1215 |
    1216 |
  1. Verify latest attested time (Section 5.4.3.1)
    2. 1217 |
  2. Verify metadata (Section 5.4.3.2)
    3. 1218 |
  3. Download latest image (Section 5.4.3.3)
    4. 1219 |
  4. Verify image (Section 5.4.3.4)
    5. 1220 |
  5. Install image (Section 5.4.3.5)
    6. 1221 |
  6. Create and send version report (Section 5.4.3.6)
    7. 1222 |
1223 |

1224 | 5.4.3.1. Load and verify the latest attested time 1225 |

1226 |

The ECU SHALL load and verify the current time, or the most recent securely attested time.

1227 |

1228 | 5.4.3.2. Verify metadata 1229 |

1230 |

The ECU SHALL verify the latest downloaded metadata (Section 5.4.4) using either full or partial verification. If the metadata verification fails for any reason, the ECU SHALL jump to the fifth step (Section 5.4.3.6).

1231 |

1232 | 5.4.3.3. Download latest image 1233 |

1234 |

If the ECU does not have secondary storage, i.e. buffer storage to temporarily store the latest image before installing it, it SHALL download the latest image from the Primary. (If the ECU has secondary storage, it will already have the latest image in its secondary storage as specified in Section 5.4.2.7, and should skip to the next step.) The ECU MAY first create a backup of its previous working image and store it elsewhere (e.g., the primary).

1235 |

The filename used to identify the latest known image (i.e., the file to request from the Primary) SHALL be determined as follows:

1236 |

1237 | 1238 |
    1239 |
  1. Load the Targets metadata file from the Director repository.
    2. 1240 |
  2. Find the Targets metadata associated with this ECU identifier.
    3. 1241 |
  3. Construct the Image filename using the rule in Section 5.2.7, or use the download URL specified in the Director metadata.
    4. 1242 |
  4. If there is no Targets metadata about this image, abort the update cycle and report that there is no such image. Additionally, in the case of failure, the ECU SHALL retain its previous Targets metadata instead of using the new Targets metadata. Otherwise, download the image (up to the number of bytes specified in the Targets metadata), and verify that its hashes match the Targets metadata.
    5. 1243 |
1244 |

When the Primary responds to the download request, the ECU SHALL overwrite its current image with the downloaded image from the Primary.

1245 |

If any part of this step fails, the ECU SHALL jump to the fifth step (Section 5.4.3.6).

1246 |

1247 | 5.4.3.4. Verify image 1248 |

1249 |

The ECU SHALL verify that the latest image matches the latest metadata as follows:

1250 |

1251 | 1252 |
    1253 |
  1. Load the latest Targets metadata file from the Director.
    2. 1254 |
  2. Find the Targets metadata associated with this ECU identifier.
    3. 1255 |
  3. Check that the hardware identifier in the metadata matches the ECUs hardware identifier.
    4. 1256 |
  4. Check that the image filename is valid for this ECU. This MAY be a comparison against a wildcard path, which restricts the ECUs to which a delegation will apply.
    5. 1257 |
  5. Check that the release counter of the image in the previous metadata, if it exists, is less than or equal to the release counter in the latest metadata.
    6. 1258 |
  6. If the image is encrypted, decrypt the image with a decryption key to be chosen as follows: 1263 |
    7. 1264 |
  7. Check that the hash of the image matches the hash in the metadata.
    8. 1265 |
1266 |

If the ECU has secondary storage, the checks SHOULD be performed on the image in secondary storage before it is installed.

1267 |

NOTE: See [DEPLOY] for guidance on how to deal with Secondary ECU failures for ECUs that do not have secondary storage.

1268 |

If any step fails, the ECU SHALL jump to the (Section 5.4.3.6) step.

1269 |

1270 | 5.4.3.5. Install image 1271 |

1272 |

The ECU SHALL attempt to install the update. This installation SHOULD occur at a time when all pre-conditions are met. These pre-conditions MAY include ensuring the vehicle is in a safe environment for install (e.g., the vehicle is parked when updating a specific ECU). Another pre-condition MAY include ensuring the ECU has a backup of its current image and metadata in case the current installation fails.

1273 |

1274 | 5.4.3.6. Create and send version report 1275 |

1276 |

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.

1277 |

1278 | 5.4.4. Metadata verification procedures 1279 |

1280 |

A Primary ECU MUST perform full verification of metadata. A Secondary ECU SHOULD perform full verification of metadata. If a Secondary cannot perform full verification, it SHALL perform partial verification instead.

1281 |

If a step in the following workflows does not succeed (e.g., the update is aborted because a new metadata file was not signed), an ECU SHOULD still be able to update again in the future. Errors raised during the update process SHOULD NOT leave ECUs in an unrecoverable state.

1282 |

1283 | 5.4.4.1. Partial verification 1284 |

1285 |

In order to perform partial verification, an ECU SHALL perform the following steps:

1286 |

1287 | 1288 |
    1289 |
  1. Load and verify the current time or the most recent securely attested time.
    2. 1290 |
  2. Download and check the Targets metadata file from the Director repository, following the procedure in Section 5.4.4.6.
    3. 1291 |
1292 |

1293 | 5.4.4.2. Full verification 1294 |

1295 |

Full verification of metadata means that the ECU checks that the Targets metadata about images from the Director repository matches the Targets metadata about the same images from the Image repository. This provides resilience to a key compromise in the system.

1296 |

Full verification MAY be performed by either Primary or Secondary ECUs. In the following instructions, whenever an ECU is directed to download metadata, it applies only to Primary ECUs.

1297 |

If [TAP-5] is supported and a Primary has an external connection to the Uptane repositories, a Primary ECU SHALL download metadata and images following the rules specified in that TAP. If [TAP-5] is not supported, or if the Primary does not have an external connection to the Uptane repositories, the download SHOULD follow the [TUF-spec] and the metadata file renaming rules specified in Section 5.2.7.

1298 |

Before starting full verification, the repository mapping metadata MUST be consulted to determine where to download metadata from. This procedure assumes the basic Uptane case: there are only two repositories (Director and Image), and all image paths are required to be signed by both repositories. If a more complex repository layout is being used, refer to [DEPLOY] for guidance on how to determine where metadata should be downloaded from.

1299 |

In order to perform full verification, an ECU SHALL perform the following steps:

1300 |

1301 | 1302 |
    1303 |
  1. Load and verify the current time or the most recent securely attested time.
    2. 1304 |
  2. Download and check the Root metadata file from the Director repository, following the procedure in Section 5.4.4.3.
    3. 1305 |
  3. Download and check the Timestamp metadata file from the Director repository, following the procedure in Section 5.4.4.4.
    4. 1306 |
  4. Download and check the Snapshot metadata file from the Director repository, following the procedure in Section 5.4.4.5.
    5. 1307 |
  5. Download and check the Targets metadata file from the Director repository, following the procedure in Section 5.4.4.6.
    6. 1308 |
  6. Download and check the Root metadata file from the Image repository, following the procedure in Section 5.4.4.3.
    7. 1309 |
  7. Download and check the Timestamp metadata file from the Image repository, following the procedure in Section 5.4.4.4.
    8. 1310 |
  8. Download and check the Snapshot metadata file from the Image repository, following the procedure in Section 5.4.4.5.
    9. 1311 |
  9. Download and check the top-level Targets metadata file from the Image repository, following the procedure in Section 5.4.4.6.
    10. 1312 |
  10. Verify that Targets metadata from the Director and Image repositories match. A Primary ECU MUST perform this check on metadata for all images listed in the Targets metadata file from the Director repository downloaded in step 6. A Secondary ECU MAY elect to perform this check only on the metadata for the image it will install. (That is, the target metadata from the Director that contains the ECU identifier of the current ECU.) To check that the metadata for an image matches, complete the following procedure:
      1313 |
    1. Locate and download a Targets metadata file from the Image repository that contains an image with exactly the same file name listed in the Director metadata, following the procedure in Section 5.4.4.7.
      2. 1314 |
    2. Check that the Targets metadata from the Image repository matches the Targets metadata from the Director repository:
        1315 |
      1. Check that the non-custom metadata (i.e., length and hashes) of the unencrypted or encrypted image are the same in both sets of metadata. Note: the Primary is responsible for validating encrypted images and associated metadata. The target ECU (Primary or Secondary) is responsible for validating the unencrypted image and associated metadata.
        2. 1316 |
      2. Check that all “MUST match” custom metadata (e.g., hardware identifier and release counter) are the same in both sets of metadata.
        3. 1317 |
      3. Check that the release counter in the previous Targets metadata file is less than or equal to the release counter in this Targets metadata file.
        4. 1318 |
      1319 |
      3. 1320 |
    1321 |
    11. 1322 |
1323 |

If any step fails, the ECU MUST return an error code indicating the failure. If a check for a specific type of security attack fails (e.g. rollback, freeze, arbitrary software, etc.), the ECU SHOULD return an error code that indicates the type of attack.

1324 |

If the ECU performing the verification is the Primary ECU, it SHOULD also ensure that the Targets metadata from the Director repository doesn’t contain any ECU identifiers for ECUs not actually present in the vehicle.

1325 |

1326 | 5.4.4.3. How to check Root metadata 1327 |

1328 |

To properly check Root metadata, an ECU SHOULD:

1329 |

1330 | 1331 |
    1332 |
  1. Load the previous Root metadata file.
    2. 1333 |
  2. Update to the latest Root metadata file.
      1334 |
    1. Let N denote the version number of the latest Root metadata file (which at first could be the same as the previous root metadata file).
      2. 1335 |
    2. Try downloading a new version N+1 of the Root metadata file, up to some X number of bytes. The value for X is set by the implementor. For example, X may be tens of kilobytes. The filename used to download the Root metadata file is of the fixed form VERSION_NUMBER.FILENAME.EXT (e.g., 42.root.json). If this file is not available, the current Root metadata file is the latest; continue with step 3.
      3. 1336 |
    3. Version N+1 of the Root metadata file MUST have been signed by the following: (1) a threshold of keys specified in the latest Root metadata file (version N), and (2) a threshold of keys specified in the new Root metadata file being validated (version N+1). If version N+1 is not signed as required, discard it, abort the update cycle, and report the signature failure. On the next update cycle, begin at version N of the Root metadata file. (Checks for an arbitrary software attack.)
      4. 1337 |
    4. The version number of the latest Root metadata file (version N) must be less than or equal to the version number of the new Root metadata file (version N+1). Effectively, this means checking that the version number signed in the new Root metadata file is indeed N+1. If the version of the new Root metadata file is less than the latest metadata file, discard it, abort the update cycle, and report the rollback attack. On the next update cycle, begin at step 0 and version N of the Root metadata file. (Checks for a rollback attack.)
      5. 1338 |
    5. Set the latest Root metadata file to the new Root metadata file.
      6. 1339 |
    6. Repeat steps 2.1 to 2.6.
      7. 1340 |
    1341 |
    3. 1342 |
  3. Check that the current (or latest securely attested) time is lower than the expiration timestamp in the latest Root metadata file. (Checks for a freeze attack.)
    4. 1343 |
  4. If the Timestamp and/or Snapshot keys have been rotated, delete the previous Timestamp and Snapshot metadata files. (Checks for recovery from fast-forward attacks [MERCURY].)
    5. 1344 |
1345 |

1346 | 5.4.4.4. How to check Timestamp metadata 1347 |

1348 |

To properly check Timestamp metadata, an ECU SHOULD:

1349 |

1350 | 1351 |
    1352 |
  1. Download up to Y number of bytes. The value for Y is set by the implementor. For example, Y may be tens of kilobytes. The filename used to download the Timestamp metadata file is of the fixed form FILENAME.EXT (e.g., timestamp.json).
    2. 1353 |
  2. Check that it has been signed by the threshold of keys specified in the latest Root metadata file. If the new Timestamp metadata file is not properly signed, discard it, abort the update cycle, and report the signature failure. (Checks for an arbitrary software attack.)
    3. 1354 |
  3. Check that the version number of the previous Timestamp metadata file, if any, is less than or equal to the version number of this Timestamp metadata file. If the new Timestamp metadata file is older than the trusted Timestamp metadata file, discard it, abort the update cycle, and report the potential rollback attack. (Checks for a rollback attack.)
    4. 1355 |
  4. Check that the current (or latest securely attested) time is lower than the expiration timestamp in this Timestamp metadata file. If the new Timestamp metadata file has expired, discard it, abort the update cycle, and report the potential freeze attack. (Checks for a freeze attack.)
    5. 1356 |
1357 |

1358 | 5.4.4.5. How to check Snapshot metadata 1359 |

1360 |

To properly check Snapshot metadata, an ECU SHOULD:

1361 |

1362 | 1363 |
    1364 |
  1. Download up to the number of bytes specified in the Timestamp metadata file, constructing the metadata filename as defined in Section 5.2.7.
    2. 1365 |
  2. The hashes and version number of the new Snapshot metadata file MUST match the hashes and version number listed in Timestamp metadata. If the hashes and version number do not match, discard the new Snapshot metadata, abort the update cycle, and report the failure. (Checks for a mix-and-match attack.)
    3. 1366 |
  3. Check that it has been signed by the threshold of keys specified in the latest Root metadata file. If the new Snapshot metadata file is not signed as required, discard it, abort the update cycle, and report the signature failure. (Checks for an arbitrary software attack.)
    4. 1367 |
  4. Check that the version number of the previous Snapshot metadata file, if any, is less than or equal to the version number of this Snapshot metadata file. If this Snapshot metadata file is older than the previous Snapshot metadata file, discard it, abort the update cycle, and report the potential rollback attack. (Checks for a rollback attack.)
    5. 1368 |
  5. Check that the version number listed by the previous Snapshot metadata file for each Targets metadata file is less than or equal to its version number in this Snapshot metadata file. If this condition is not met, discard the new Snapshot metadata file, abort the update cycle, and report the failure. (Checks for a rollback attack.)
    6. 1369 |
  6. Check that each Targets metadata filename listed in the previous Snapshot metadata file is also listed in this Snapshot metadata file. If this condition is not met, discard the new Snapshot metadata file, abort the update cycle, and report the failure. (Checks for a rollback attack.)
    7. 1370 |
  7. Check that the current (or latest securely attested) time is lower than the expiration timestamp in this Snapshot metadata file. If the new Snapshot metadata file is expired, discard it, abort the update cycle, and report the potential freeze attack. (Checks for a freeze attack.)
    8. 1371 |
1372 |

1373 | 5.4.4.6. How to check Targets metadata 1374 |

1375 |

To properly check Targets metadata, an ECU SHOULD:

1376 |

1377 | 1378 |
    1379 |
  1. Download up to Z number of bytes, constructing the metadata filename as defined in Section 5.2.7. The value for Z is set by the implementor. For example, Z may be tens of kilobytes.
    2. 1380 |
  2. The version number of the new Targets metadata file MUST match the version number listed in the latest Snapshot metadata. If the version number does not match, discard it, abort the update cycle, and report the failure. (Checks for a mix-and-match attack.) Skip this step if checking Targets metadata on a partial-verification ECU; partial-verification ECUs will not have Snapshot metadata.
    3. 1381 |
  3. Check that the Targets metadata has been signed by the threshold of keys specified in the relevant metadata file (Checks for an arbitrary software attack):
      1382 |
    1. If checking top-level Targets metadata, the threshold of keys is specified in the Root metadata.
      2. 1383 |
    2. If checking delegated Targets metadata, the threshold of keys is specified in the Targets metadata file that delegated authority to this role.
      3. 1384 |
    1385 |
    4. 1386 |
  4. Check that the version number of the previous Targets metadata file, if any, is less than or equal to the version number of this Targets metadata file. (Checks for a rollback attack.)
    5. 1387 |
  5. Check that the current (or latest securely attested) time is lower than the expiration timestamp in this Targets metadata file. (Checks for a freeze attack.)
    6. 1388 |
  6. If checking Targets metadata from the Director repository, verify that there are no delegations.
    7. 1389 |
  7. If checking Targets metadata from the Director repository, check that no ECU identifier is represented more than once.
    8. 1390 |
1391 |

1392 | 5.4.4.7. How to resolve delegations 1393 |

1394 |

To properly check Targets metadata for an image, an ECU MUST locate the metadata file(s) for the role (or roles) that have the authority to sign the image. This metadata might be located in the top-level Targets metadata, but it also may be delegated to another role or to multiple roles. Therefore, all delegations MUST be resolved using the following recursive procedure, beginning with the top-level Targets metadata file.

1395 |

1396 | 1397 |
    1398 |
  1. Download the current metadata file, and check it following the procedure in Section 5.4.4.6. If the file cannot be loaded, or if any verification step fails, abort the delegation resolution, and indicate that Image metadata cannot be found because of a missing or invalid role.
    2. 1399 |
  2. If the current metadata file contains signed metadata about the image, end the delegation resolution and return the metadata to be checked.
    3. 1400 |
  3. If the current metadata file was reached via a terminating delegation and does not contain signed metadata about the image, abort the delegation resolution for this image and return an error indicating that image metadata could not be found.
    4. 1401 |
  4. Search the list of delegations, in listed order. For each delegation:
      1402 |
    1. Check if the delegation applies to the image being processed. For the delegation to apply, it MUST include the hardware identifier of the target, and the target name must match one of the delegation’s image paths. If either of these tests fail, move on to the next delegation in the list.
      2. 1403 |
    2. If the delegation is a multi-role delegation, follow the procedure described in Section 5.4.4.8. If the multi-role delegation is terminating and no valid Image metadata is found, abort the delegation resolution and return an error indicating that image metadata could not be found.
      3. 1404 |
    3. If the delegation is a normal delegation, perform delegation resolution, starting at step 1. Note that this may recurse an arbitrary number of levels deep. If a delegation that applies to the image is found but no image metadata is found in the delegated roles or any of its sub-delegations, simply continue on with the next delegation in the list. The search is only completed/aborted if image metadata or a terminating delegation that applies to the image is found.
      4. 1405 |
    1406 |
    5. 1407 |
  5. If the end of the list of delegations in the top-level metadata is reached without finding valid image metadata, return an error indicating that image metadata could not be found.
    6. 1408 |
1409 |

1410 | 5.4.4.8. Multi-role delegations 1411 |

1412 |

It is possible to delegate signing authority to multiple delegated roles as described in [TAP-3]. Each multi-role delegation effectively contains a list of ordinary delegations, plus a threshold of those roles that must be in agreement about the non-custom metadata for the image. All multi-role delegations MUST be resolved using the following procedure. Note that there may be sub-delegations inside multi-role delegations.

1413 |

1414 | 1415 |
    1416 |
  1. For each of the roles in the delegation, find and load the image metadata (or error) following the procedure in Section 5.4.4.7.
    2. 1417 |
  2. Inspect the non-custom part of the metadata loaded in step 1:
      1418 |
    1. Locate all sets of roles which have agreeing (i.e. identical) non-custom metadata and “MUST match” custom metadata. Discard any set of roles with a size smaller than the threshold of roles that must be in agreement for this delegation.
      2. 1419 |
    2. Check for a conflict. A conflict exists if there remains more than one agreeing set of roles, each set having different metadata. If a conflict is found, choose and return the metadata from the set of roles which includes the earliest role in the multi-delegation list.
      3. 1420 |
    3. If there is no conflict, check if there is any single set of roles with matching non-custom metadata. If there is, choose and return the metadata from this set.
      4. 1421 |
    4. If no agreeing set can be found that meets the agreement threshold, return an error indicating that image metadata could not be found.
      5. 1422 |
    1423 |
    3. 1424 |
1425 |

1426 | 6. References

1427 |

1428 | 6.1. Normative References

1429 |
1430 | 1431 | 1432 | 1434 | 1435 | 1436 | 1437 | 1439 | 1440 | 1441 | 1442 | 1444 | 1445 | 1446 | 1447 | 1449 | 1450 | 1451 | 1452 | 1454 | 1455 | 1456 | 1457 | 1459 | 1460 | 1461 | 1462 | 1464 | 1465 | 1466 | 1467 | 1469 | 1470 |
[NFC] 1433 | Davis, M. and M. Duerst, "Unicode Standard Annex #15: Unicode Normalization Forms", October 2018.
[RFC2119] 1438 | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997.
[RFC3647] 1443 | Chokhani, S., Ford, W., Sabett, R., Merrill, C. and S. Wu, "Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices Framework", RFC 3647, DOI 10.17487/RFC3647, November 2003.
[RFC5198] 1448 | Klensin, J. and M. Padlipsky, "Unicode Format for Network Interchange", RFC 5198, DOI 10.17487/RFC5198, March 2008.
[TAP-3] 1453 | Kuppusamy, T., Awwad, S., Cordell, E., Diaz, V., Moshenko, J. and J. Cappos, "The Update Framework TAP 3 - Multi-role delegations", January 2018.
[TAP-4] 1458 | Kuppusamy, T., Awwad, S., Cordell, E., Diaz, V., Moshenko, J. and J. Cappos, "The Update Framework TAP 4 - Multiple repository consensus on entrusted targets", December 2017.
[TAP-5] 1463 | Kuppusamy, T., Awwad, S., Cordell, E., Diaz, V., Moshenko, J. and J. Cappos, "The Update Framework TAP 5 - Setting URLs for roles in the root metadata file", January 2018.
[TUF-spec] 1468 | Samuel, J., Mathewson, N., Condra, G., Diaz, V., Kuppusamy, T., Awwad, S., Tobias, S., Wright, J., Mehnert, H., Tryzelaar, E., Cappos, J. and R. Dingledine, "The Update Framework Specification", September 2018.
1471 |

1472 | 6.2. Informative References

1473 | 1474 | 1475 | 1476 | 1478 | 1479 | 1480 | 1481 | 1483 | 1484 | 1485 | 1486 | 1487 | 1488 | 1489 | 1490 | 1492 | 1493 | 1494 | 1495 | 1497 | 1498 | 1499 | 1500 | 1502 | 1503 | 1504 | 1505 | 1507 | 1508 |
[CR-OTA] 1477 | Barry, K., "Automakers Embrace Over-the-Air Updates, but Can We Trust Digital Car Repair?", April 2018.
[DEPLOY] 1482 | Members of the Uptane Alliance Community, ., "Uptane Deployment Guidelines", n.d..
[IN-TOTO]"in-toto: A framework to secure the integrity of software supply chains", October 2018.
[MERCURY] 1491 | Kuppusamy, T., Diaz, V. and J. Cappos, "Mercury: Bandwidth-Effective Prevention of Rollback Attacks Against Community Repositories", ISBN 978-1-931971-38-6, July 2017.
[PEP-458] 1496 | Kuppusamy, T., Diaz, V., Stufft, D. and J. Cappos, "PEP 458 -- Surviving a Compromise of PyPI", September 2013.
[UPTANEESCAR] 1501 | Kuppusamy, T., Brown, A., Awwad, S., McCoy, D., Bielawski, R., Mott, C., Lauzon, S., Weimerskirch, A. and J. Cappos, "Securing Software Updates for Automobiles", October 2016.
[USATODAY] 1506 | O'Donnell, B., "Your average car is a lot more code-driven than you think", June 2016.
1509 |

Author's Address

1510 |
1511 |
1512 | 1513 | Uptane Alliance Community 1514 | 1517 | 1518 | Uptane Alliance (c/o Prof. Justin Cappos) 1519 | 1520 | 6 MetroTech 1521 | 1522 | 1523 | Brooklyn, 1524 | NY 1525 | 11201 1526 | 1527 | USA 1528 | 1529 | EMail: uptane-standards@googlegroups.com 1530 | 1531 |
1532 |
1533 | 1534 | 1535 | 1536 | --------------------------------------------------------------------------------