File: rfc9019.html

package info (click to toggle)
doc-rfc 20230121-1
links: PTS, VCS
area: non-free
in suites: bookworm, forky, sid, trixie
size: 1,609,944 kB
file content (2735 lines) | stat: -rw-r--r-- 127,548 bytes
<!DOCTYPE html>
<html lang="en" class="RFC">
<head>
<meta charset="utf-8">
<meta content="Common,Latin" name="scripts">
<meta content="initial-scale=1.0" name="viewport">
<title>RFC 9019: A Firmware Update Architecture for Internet of Things</title>
<meta content="Brendan Moran" name="author">
<meta content="Hannes Tschofenig" name="author">
<meta content="David Brown" name="author">
<meta content="Milosch Meriac" name="author">
<meta content="
       Vulnerabilities in Internet of Things (IoT) devices have raised
 the need for a reliable and secure firmware update mechanism
 suitable for devices with resource constraints. Incorporating such an
 update mechanism is a fundamental requirement for fixing vulnerabilities,
 but it also enables other important capabilities such as updating
 configuration settings
 and adding new functionality. 
       In addition to the definition of terminology and an architecture,
 this document provides the motivation for the standardization of a manifest format
 as a transport-agnostic means for describing and protecting firmware
 updates. 
    " name="description">
<meta content="xml2rfc 3.7.0" name="generator">
<meta content="IoT" name="keyword">
<meta content="update" name="keyword">
<meta content="software" name="keyword">
<meta content="firmware" name="keyword">
<meta content="constrained" name="keyword">
<meta content="Secure" name="keyword">
<meta content="Boot" name="keyword">
<meta content="9019" name="rfc.number">
<!-- Generator version information:
  xml2rfc 3.7.0
    Python 3.6.10
    appdirs 1.4.4
    ConfigArgParse 1.2.3
    google-i18n-address 2.3.5
    html5lib 1.0.1
    intervaltree 3.0.2
    Jinja2 2.11.2
    kitchen 1.2.6
    lxml 4.4.2
    pycairo 1.19.0
    pycountry 19.8.18
    pyflakes 2.1.1
    PyYAML 5.3.1
    requests 2.22.0
    setuptools 40.6.2
    six 1.14.0
    WeasyPrint 51
-->
<link href="rfc9019.xml" rel="alternate" type="application/rfc+xml">
<link href="#copyright" rel="license">
<style type="text/css">/*

  NOTE: Changes at the bottom of this file overrides some earlier settings.

  Once the style has stabilized and has been adopted as an official RFC style,
  this can be consolidated so that style settings occur only in one place, but
  for now the contents of this file consists first of the initial CSS work as
  provided to the RFC Formatter (xml2rfc) work, followed by itemized and
  commented changes found necssary during the development of the v3
  formatters.

*/

/* fonts */
@import url('https://fonts.googleapis.com/css?family=Noto+Sans'); /* Sans-serif */
@import url('https://fonts.googleapis.com/css?family=Noto+Serif'); /* Serif (print) */
@import url('https://fonts.googleapis.com/css?family=Roboto+Mono'); /* Monospace */

@viewport {
  zoom: 1.0;
  width: extend-to-zoom;
}
@-ms-viewport {
  width: extend-to-zoom;
  zoom: 1.0;
}
/* general and mobile first */
html {
}
body {
  max-width: 90%;
  margin: 1.5em auto;
  color: #222;
  background-color: #fff;
  font-size: 14px;
  font-family: 'Noto Sans', Arial, Helvetica, sans-serif;
  line-height: 1.6;
  scroll-behavior: smooth;
}
.ears {
  display: none;
}

/* headings */
#title, h1, h2, h3, h4, h5, h6 {
  margin: 1em 0 0.5em;
  font-weight: bold;
  line-height: 1.3;
}
#title {
  clear: both;
  border-bottom: 1px solid #ddd;
  margin: 0 0 0.5em 0;
  padding: 1em 0 0.5em;
}
.author {
  padding-bottom: 4px;
}
h1 {
  font-size: 26px;
  margin: 1em 0;
}
h2 {
  font-size: 22px;
  margin-top: -20px;  /* provide offset for in-page anchors */
  padding-top: 33px;
}
h3 {
  font-size: 18px;
  margin-top: -36px;  /* provide offset for in-page anchors */
  padding-top: 42px;
}
h4 {
  font-size: 16px;
  margin-top: -36px;  /* provide offset for in-page anchors */
  padding-top: 42px;
}
h5, h6 {
  font-size: 14px;
}
#n-copyright-notice {
  border-bottom: 1px solid #ddd;
  padding-bottom: 1em;
  margin-bottom: 1em;
}
/* general structure */
p {
  padding: 0;
  margin: 0 0 1em 0;
  text-align: left;
}
div, span {
  position: relative;
}
div {
  margin: 0;
}
.alignRight.art-text {
  background-color: #f9f9f9;
  border: 1px solid #eee;
  border-radius: 3px;
  padding: 1em 1em 0;
  margin-bottom: 1.5em;
}
.alignRight.art-text pre {
  padding: 0;
}
.alignRight {
  margin: 1em 0;
}
.alignRight > *:first-child {
  border: none;
  margin: 0;
  float: right;
  clear: both;
}
.alignRight > *:nth-child(2) {
  clear: both;
  display: block;
  border: none;
}
svg {
  display: block;
}
.alignCenter.art-text {
  background-color: #f9f9f9;
  border: 1px solid #eee;
  border-radius: 3px;
  padding: 1em 1em 0;
  margin-bottom: 1.5em;
}
.alignCenter.art-text pre {
  padding: 0;
}
.alignCenter {
  margin: 1em 0;
}
.alignCenter > *:first-child {
  border: none;
  /* this isn't optimal, but it's an existence proof.  PrinceXML doesn't
     support flexbox yet.
  */
  display: table;
  margin: 0 auto;
}

/* lists */
ol, ul {
  padding: 0;
  margin: 0 0 1em 2em;
}
ol ol, ul ul, ol ul, ul ol {
  margin-left: 1em;
}
li {
  margin: 0 0 0.25em 0;
}
.ulCompact li {
  margin: 0;
}
ul.empty, .ulEmpty {
  list-style-type: none;
}
ul.empty li, .ulEmpty li {
  margin-top: 0.5em;
}
ul.compact, .ulCompact,
ol.compact, .olCompact {
  line-height: 100%;
  margin: 0 0 0 2em;
}

/* definition lists */
dl {
}
dl > dt {
  float: left;
  margin-right: 1em;
}
/* 
dl.nohang > dt {
  float: none;
}
*/
dl > dd {
  margin-bottom: .8em;
  min-height: 1.3em;
}
dl.compact > dd, .dlCompact > dd {
  margin-bottom: 0em;
}
dl > dd > dl {
  margin-top: 0.5em;
  margin-bottom: 0em;
}

/* links */
a {
  text-decoration: none;
}
a[href] {
  color: #22e; /* Arlen: WCAG 2019 */
}
a[href]:hover {
  background-color: #f2f2f2;
}
figcaption a[href],
a[href].selfRef {
  color: #222;
}
/* XXX probably not this:
a.selfRef:hover {
  background-color: transparent;
  cursor: default;
} */

/* Figures */
tt, code, pre, code {
  background-color: #f9f9f9;
  font-family: 'Roboto Mono', monospace;
}
pre {
  border: 1px solid #eee;
  margin: 0;
  padding: 1em;
}
img {
  max-width: 100%;
}
figure {
  margin: 0;
}
figure blockquote {
  margin: 0.8em 0.4em 0.4em;
}
figcaption {
  font-style: italic;
  margin: 0 0 1em 0;
}
@media screen {
  pre {
    overflow-x: auto;
    max-width: 100%;
    max-width: calc(100% - 22px);
  }
}

/* aside, blockquote */
aside, blockquote {
  margin-left: 0;
  padding: 1.2em 2em;
}
blockquote {
  background-color: #f9f9f9;
  color: #111; /* Arlen: WCAG 2019 */
  border: 1px solid #ddd;
  border-radius: 3px;
  margin: 1em 0;
}
cite {
  display: block;
  text-align: right;
  font-style: italic;
}

/* tables */
table {
  width: 100%;
  margin: 0 0 1em;
  border-collapse: collapse;
  border: 1px solid #eee;
}
th, td {
  text-align: left;
  vertical-align: top;
  padding: 0.5em 0.75em;
}
th {
  text-align: left;
  background-color: #e9e9e9;
}
tr:nth-child(2n+1) > td {
  background-color: #f5f5f5;
}
table caption {
  font-style: italic;
  margin: 0;
  padding: 0;
  text-align: left;
}
table p {
  /* XXX to avoid bottom margin on table row signifiers. If paragraphs should
     be allowed within tables more generally, it would be far better to select on a class. */
  margin: 0;
}

/* pilcrow */
a.pilcrow {
  color: #666; /* Arlen: AHDJ 2019 */
  text-decoration: none;
  visibility: hidden;
  user-select: none;
  -ms-user-select: none;
  -o-user-select:none;
  -moz-user-select: none;
  -khtml-user-select: none;
  -webkit-user-select: none;
  -webkit-touch-callout: none;
}
@media screen {
  aside:hover > a.pilcrow,
  p:hover > a.pilcrow,
  blockquote:hover > a.pilcrow,
  div:hover > a.pilcrow,
  li:hover > a.pilcrow,
  pre:hover > a.pilcrow {
    visibility: visible;
  }
  a.pilcrow:hover {
    background-color: transparent;
  }
}

/* misc */
hr {
  border: 0;
  border-top: 1px solid #eee;
}
.bcp14 {
  font-variant: small-caps;
}

.role {
  font-variant: all-small-caps;
}

/* info block */
#identifiers {
  margin: 0;
  font-size: 0.9em;
}
#identifiers dt {
  width: 3em;
  clear: left;
}
#identifiers dd {
  float: left;
  margin-bottom: 0;
}
#identifiers .authors .author {
  display: inline-block;
  margin-right: 1.5em;
}
#identifiers .authors .org {
  font-style: italic;
}

/* The prepared/rendered info at the very bottom of the page */
.docInfo {
  color: #666; /* Arlen: WCAG 2019 */
  font-size: 0.9em;
  font-style: italic;
  margin-top: 2em;
}
.docInfo .prepared {
  float: left;
}
.docInfo .prepared {
  float: right;
}

/* table of contents */
#toc  {
  padding: 0.75em 0 2em 0;
  margin-bottom: 1em;
}
nav.toc ul {
  margin: 0 0.5em 0 0;
  padding: 0;
  list-style: none;
}
nav.toc li {
  line-height: 1.3em;
  margin: 0.75em 0;
  padding-left: 1.2em;
  text-indent: -1.2em;
}
/* references */
.references dt {
  text-align: right;
  font-weight: bold;
  min-width: 7em;
}
.references dd {
  margin-left: 8em;
  overflow: auto;
}

.refInstance {
  margin-bottom: 1.25em;
}

.references .ascii {
  margin-bottom: 0.25em;
}

/* index */
.index ul {
  margin: 0 0 0 1em;
  padding: 0;
  list-style: none;
}
.index ul ul {
  margin: 0;
}
.index li {
  margin: 0;
  text-indent: -2em;
  padding-left: 2em;
  padding-bottom: 5px;
}
.indexIndex {
  margin: 0.5em 0 1em;
}
.index a {
  font-weight: 700;
}
/* make the index two-column on all but the smallest screens */
@media (min-width: 600px) {
  .index ul {
    -moz-column-count: 2;
    -moz-column-gap: 20px;
  }
  .index ul ul {
    -moz-column-count: 1;
    -moz-column-gap: 0;
  }
}

/* authors */
address.vcard {
  font-style: normal;
  margin: 1em 0;
}

address.vcard .nameRole {
  font-weight: 700;
  margin-left: 0;
}
address.vcard .label {
  font-family: "Noto Sans",Arial,Helvetica,sans-serif;
  margin: 0.5em 0;
}
address.vcard .type {
  display: none;
}
.alternative-contact {
  margin: 1.5em 0 1em;
}
hr.addr {
  border-top: 1px dashed;
  margin: 0;
  color: #ddd;
  max-width: calc(100% - 16px);
}

/* temporary notes */
.rfcEditorRemove::before {
  position: absolute;
  top: 0.2em;
  right: 0.2em;
  padding: 0.2em;
  content: "The RFC Editor will remove this note";
  color: #9e2a00; /* Arlen: WCAG 2019 */
  background-color: #ffd; /* Arlen: WCAG 2019 */
}
.rfcEditorRemove {
  position: relative;
  padding-top: 1.8em;
  background-color: #ffd; /* Arlen: WCAG 2019 */
  border-radius: 3px;
}
.cref {
  background-color: #ffd; /* Arlen: WCAG 2019 */
  padding: 2px 4px;
}
.crefSource {
  font-style: italic;
}
/* alternative layout for smaller screens */
@media screen and (max-width: 1023px) {
  body {
    padding-top: 2em;
  }
  #title {
    padding: 1em 0;
  }
  h1 {
    font-size: 24px;
  }
  h2 {
    font-size: 20px;
    margin-top: -18px;  /* provide offset for in-page anchors */
    padding-top: 38px;
  }
  #identifiers dd {
    max-width: 60%;
  }
  #toc {
    position: fixed;
    z-index: 2;
    top: 0;
    right: 0;
    padding: 0;
    margin: 0;
    background-color: inherit;
    border-bottom: 1px solid #ccc;
  }
  #toc h2 {
    margin: -1px 0 0 0;
    padding: 4px 0 4px 6px;
    padding-right: 1em;
    min-width: 190px;
    font-size: 1.1em;
    text-align: right;
    background-color: #444;
    color: white;
    cursor: pointer;
  }
  #toc h2::before { /* css hamburger */
    float: right;
    position: relative;
    width: 1em;
    height: 1px;
    left: -164px;
    margin: 6px 0 0 0;
    background: white none repeat scroll 0 0;
    box-shadow: 0 4px 0 0 white, 0 8px 0 0 white;
    content: "";
  }
  #toc nav {
    display: none;
    padding: 0.5em 1em 1em;
    overflow: auto;
    height: calc(100vh - 48px);
    border-left: 1px solid #ddd;
  }
}

/* alternative layout for wide screens */
@media screen and (min-width: 1024px) {
  body {
    max-width: 724px;
    margin: 42px auto;
    padding-left: 1.5em;
    padding-right: 29em;
  }
  #toc {
    position: fixed;
    top: 42px;
    right: 42px;
    width: 25%;
    margin: 0;
    padding: 0 1em;
    z-index: 1;
  }
  #toc h2 {
    border-top: none;
    border-bottom: 1px solid #ddd;
    font-size: 1em;
    font-weight: normal;
    margin: 0;
    padding: 0.25em 1em 1em 0;
  }
  #toc nav {
    display: block;
    height: calc(90vh - 84px);
    bottom: 0;
    padding: 0.5em 0 0;
    overflow: auto;
  }
  img { /* future proofing */
    max-width: 100%;
    height: auto;
  }
}

/* pagination */
@media print {
  body {

    width: 100%;
  }
  p {
    orphans: 3;
    widows: 3;
  }
  #n-copyright-notice {
    border-bottom: none;
  }
  #toc, #n-introduction {
    page-break-before: always;
  }
  #toc {
    border-top: none;
    padding-top: 0;
  }
  figure, pre {
    page-break-inside: avoid;
  }
  figure {
    overflow: scroll;
  }
  h1, h2, h3, h4, h5, h6 {
    page-break-after: avoid;
  }
  h2+*, h3+*, h4+*, h5+*, h6+* {
    page-break-before: avoid;
  }
  pre {
    white-space: pre-wrap;
    word-wrap: break-word;
    font-size: 10pt;
  }
  table {
    border: 1px solid #ddd;
  }
  td {
    border-top: 1px solid #ddd;
  }
}

/* This is commented out here, as the string-set: doesn't
   pass W3C validation currently */
/*
.ears thead .left {
  string-set: ears-top-left content();
}

.ears thead .center {
  string-set: ears-top-center content();
}

.ears thead .right {
  string-set: ears-top-right content();
}

.ears tfoot .left {
  string-set: ears-bottom-left content();
}

.ears tfoot .center {
  string-set: ears-bottom-center content();
}

.ears tfoot .right {
  string-set: ears-bottom-right content();
}
*/

@page :first {
  padding-top: 0;
  @top-left {
    content: normal;
    border: none;
  }
  @top-center {
    content: normal;
    border: none;
  }
  @top-right {
    content: normal;
    border: none;
  }
}

@page {
  size: A4;
  margin-bottom: 45mm;
  padding-top: 20px;
  /* The follwing is commented out here, but set appropriately by in code, as
     the content depends on the document */
  /*
  @top-left {
    content: 'Internet-Draft';
    vertical-align: bottom;
    border-bottom: solid 1px #ccc;
  }
  @top-left {
    content: string(ears-top-left);
    vertical-align: bottom;
    border-bottom: solid 1px #ccc;
  }
  @top-center {
    content: string(ears-top-center);
    vertical-align: bottom;
    border-bottom: solid 1px #ccc;
  }
  @top-right {
    content: string(ears-top-right);
    vertical-align: bottom;
    border-bottom: solid 1px #ccc;
  }
  @bottom-left {
    content: string(ears-bottom-left);
    vertical-align: top;
    border-top: solid 1px #ccc;
  }
  @bottom-center {
    content: string(ears-bottom-center);
    vertical-align: top;
    border-top: solid 1px #ccc;
  }
  @bottom-right {
      content: '[Page ' counter(page) ']';
      vertical-align: top;
      border-top: solid 1px #ccc;
  }
  */

}

/* Changes introduced to fix issues found during implementation */
/* Make sure links are clickable even if overlapped by following H* */
a {
  z-index: 2;
}
/* Separate body from document info even without intervening H1 */
section {
  clear: both;
}


/* Top align author divs, to avoid names without organization dropping level with org names */
.author {
  vertical-align: top;
}

/* Leave room in document info to show Internet-Draft on one line */
#identifiers dt {
  width: 8em;
}

/* Don't waste quite as much whitespace between label and value in doc info */
#identifiers dd {
  margin-left: 1em;
}

/* Give floating toc a background color (needed when it's a div inside section */
#toc {
  background-color: white;
}

/* Make the collapsed ToC header render white on gray also when it's a link */
@media screen and (max-width: 1023px) {
  #toc h2 a,
  #toc h2 a:link,
  #toc h2 a:focus,
  #toc h2 a:hover,
  #toc a.toplink,
  #toc a.toplink:hover {
    color: white;
    background-color: #444;
    text-decoration: none;
  }
}

/* Give the bottom of the ToC some whitespace */
@media screen and (min-width: 1024px) {
  #toc {
    padding: 0 0 1em 1em;
  }
}

/* Style section numbers with more space between number and title */
.section-number {
  padding-right: 0.5em;
}

/* prevent monospace from becoming overly large */
tt, code, pre, code {
  font-size: 95%;
}

/* Fix the height/width aspect for ascii art*/
pre.sourcecode,
.art-text pre {
  line-height: 1.12;
}


/* Add styling for a link in the ToC that points to the top of the document */
a.toplink {
  float: right;
  margin-right: 0.5em;
}

/* Fix the dl styling to match the RFC 7992 attributes */
dl > dt,
dl.dlParallel > dt {
  float: left;
  margin-right: 1em;
}
dl.dlNewline > dt {
  float: none;
}

/* Provide styling for table cell text alignment */
table td.text-left,
table th.text-left {
  text-align: left;
}
table td.text-center,
table th.text-center {
  text-align: center;
}
table td.text-right,
table th.text-right {
  text-align: right;
}

/* Make the alternative author contact informatio look less like just another
   author, and group it closer with the primary author contact information */
.alternative-contact {
  margin: 0.5em 0 0.25em 0;
}
address .non-ascii {
  margin: 0 0 0 2em;
}

/* With it being possible to set tables with alignment
  left, center, and right, { width: 100%; } does not make sense */
table {
  width: auto;
}

/* Avoid reference text that sits in a block with very wide left margin,
   because of a long floating dt label.*/
.references dd {
  overflow: visible;
}

/* Control caption placement */
caption {
  caption-side: bottom;
}

/* Limit the width of the author address vcard, so names in right-to-left
   script don't end up on the other side of the page. */

address.vcard {
  max-width: 30em;
  margin-right: auto;
}

/* For address alignment dependent on LTR or RTL scripts */
address div.left {
  text-align: left;
}
address div.right {
  text-align: right;
}

/* Provide table alignment support.  We can't use the alignX classes above
   since they do unwanted things with caption and other styling. */
table.right {
 margin-left: auto;
 margin-right: 0;
}
table.center {
 margin-left: auto;
 margin-right: auto;
}
table.left {
 margin-left: 0;
 margin-right: auto;
}

/* Give the table caption label the same styling as the figcaption */
caption a[href] {
  color: #222;
}

@media print {
  .toplink {
    display: none;
  }

  /* avoid overwriting the top border line with the ToC header */
  #toc {
    padding-top: 1px;
  }

  /* Avoid page breaks inside dl and author address entries */
  .vcard {
    page-break-inside: avoid;
  }

}
/* Tweak the bcp14 keyword presentation */
.bcp14 {
  font-variant: small-caps;
  font-weight: bold;
  font-size: 0.9em;
}
/* Tweak the invisible space above H* in order not to overlay links in text above */
 h2 {
  margin-top: -18px;  /* provide offset for in-page anchors */
  padding-top: 31px;
 }
 h3 {
  margin-top: -18px;  /* provide offset for in-page anchors */
  padding-top: 24px;
 }
 h4 {
  margin-top: -18px;  /* provide offset for in-page anchors */
  padding-top: 24px;
 }
/* Float artwork pilcrow to the right */
@media screen {
  .artwork a.pilcrow {
    display: block;
    line-height: 0.7;
    margin-top: 0.15em;
  }
}
/* Make pilcrows on dd visible */
@media screen {
  dd:hover > a.pilcrow {
    visibility: visible;
  }
}
/* Make the placement of figcaption match that of a table's caption
   by removing the figure's added bottom margin */
.alignLeft.art-text,
.alignCenter.art-text,
.alignRight.art-text {
   margin-bottom: 0;
}
.alignLeft,
.alignCenter,
.alignRight {
  margin: 1em 0 0 0;
}
/* In print, the pilcrow won't show on hover, so prevent it from taking up space,
   possibly even requiring a new line */
@media print {
  a.pilcrow {
    display: none;
  }
}
/* Styling for the external metadata */
div#external-metadata {
  background-color: #eee;
  padding: 0.5em;
  margin-bottom: 0.5em;
  display: none;
}
div#internal-metadata {
  padding: 0.5em;                       /* to match the external-metadata padding */
}
/* Styling for title RFC Number */
h1#rfcnum {
  clear: both;
  margin: 0 0 -1em;
  padding: 1em 0 0 0;
}
/* Make .olPercent look the same as <ol><li> */
dl.olPercent > dd {
  margin-bottom: 0.25em;
  min-height: initial;
}
/* Give aside some styling to set it apart */
aside {
  border-left: 1px solid #ddd;
  margin: 1em 0 1em 2em;
  padding: 0.2em 2em;
}
aside > dl,
aside > ol,
aside > ul,
aside > table,
aside > p {
  margin-bottom: 0.5em;
}
/* Additional page break settings */
@media print {
  figcaption, table caption {
    page-break-before: avoid;
  }
}
/* Font size adjustments for print */
@media print {
  body  { font-size: 10pt;      line-height: normal; max-width: 96%; }
  h1    { font-size: 1.72em;    padding-top: 1.5em; } /* 1*1.2*1.2*1.2 */
  h2    { font-size: 1.44em;    padding-top: 1.5em; } /* 1*1.2*1.2 */
  h3    { font-size: 1.2em;     padding-top: 1.5em; } /* 1*1.2 */
  h4    { font-size: 1em;       padding-top: 1.5em; }
  h5, h6 { font-size: 1em;      margin: initial; padding: 0.5em 0 0.3em; }
}
/* Sourcecode margin in print, when there's no pilcrow */
@media print {
  .artwork,
  .sourcecode {
    margin-bottom: 1em;
  }
}
/* Avoid narrow tables forcing too narrow table captions, which may render badly */
table {
  min-width: 20em;
}
/* ol type a */
ol.type-a { list-style-type: lower-alpha; }
ol.type-A { list-style-type: upper-alpha; }
ol.type-i { list-style-type: lower-roman; }
ol.type-I { list-style-type: lower-roman; }
/* Apply the print table and row borders in general, on request from the RPC,
and increase the contrast between border and odd row background sligthtly */
table {
  border: 1px solid #ddd;
}
td {
  border-top: 1px solid #ddd;
}
tr:nth-child(2n+1) > td {
  background-color: #f8f8f8;
}
/* Use style rules to govern display of the TOC. */
@media screen and (max-width: 1023px) {
  #toc nav { display: none; }
  #toc.active nav { display: block; }
}
/* Add support for keepWithNext */
.keepWithNext {
  break-after: avoid-page;
  break-after: avoid-page;
}
/* Add support for keepWithPrevious */
.keepWithPrevious {
  break-before: avoid-page;
}
/* Change the approach to avoiding breaks inside artwork etc. */
figure, pre, table, .artwork, .sourcecode  {
  break-before: avoid-page;
  break-after: auto;
}
/* Avoid breaks between <dt> and <dd> */
dl {
  break-before: auto;
  break-inside: auto;
}
dt {
  break-before: auto;
  break-after: avoid-page;
}
dd {
  break-before: avoid-page;
  break-after: auto;
  orphans: 3;
  widows: 3
}
span.break, dd.break {
  margin-bottom: 0;
  min-height: 0;
  break-before: auto;
  break-inside: auto;
  break-after: auto;
}
/* Undo break-before ToC */
@media print {
  #toc {
    break-before: auto;
  }
}
/* Text in compact lists should not get extra bottim margin space,
   since that would makes the list not compact */
ul.compact p, .ulCompact p,
ol.compact p, .olCompact p {
 margin: 0;
}
/* But the list as a whole needs the extra space at the end */
section ul.compact,
section .ulCompact,
section ol.compact,
section .olCompact {
  margin-bottom: 1em;                    /* same as p not within ul.compact etc. */
}
/* The tt and code background above interferes with for instance table cell
   backgrounds.  Changed to something a bit more selective. */
tt, code {
  background-color: transparent;
}
p tt, p code, li tt, li code {
  background-color: #f8f8f8;
}
/* Tweak the pre margin -- 0px doesn't come out well */
pre {
   margin-top: 0.5px;
}
/* Tweak the comact list text */
ul.compact, .ulCompact,
ol.compact, .olCompact,
dl.compact, .dlCompact {
  line-height: normal;
}
/* Don't add top margin for nested lists */
li > ul, li > ol, li > dl,
dd > ul, dd > ol, dd > dl,
dl > dd > dl {
  margin-top: initial;
}
/* Elements that should not be rendered on the same line as a <dt> */
/* This should match the element list in writer.text.TextWriter.render_dl() */
dd > div.artwork:first-child,
dd > aside:first-child,
dd > figure:first-child,
dd > ol:first-child,
dd > div:first-child > pre.sourcecode,
dd > table:first-child,
dd > ul:first-child {
  clear: left;
}
/* fix for weird browser behaviour when <dd/> is empty */
dt+dd:empty::before{
  content: "\00a0";
}
/* Make paragraph spacing inside <li> smaller than in body text, to fit better within the list */
li > p {
  margin-bottom: 0.5em
}
/* Don't let p margin spill out from inside list items */
li > p:last-of-type {
  margin-bottom: 0;
}
</style>
<link href="rfc-local.css" rel="stylesheet" type="text/css">
<link href="https://dx.doi.org/10.17487/rfc9019" rel="alternate">
  <link href="urn:issn:2070-1721" rel="alternate">
  <link href="https://datatracker.ietf.org/doc/draft-ietf-suit-architecture-16" rel="prev">
  </head>
<body>
<script src="https://www.rfc-editor.org/js/metadata.min.js"></script>
<table class="ears">
<thead><tr>
<td class="left">RFC 9019</td>
<td class="center">IoT Firmware Update Architecture</td>
<td class="right">April 2021</td>
</tr></thead>
<tfoot><tr>
<td class="left">Moran, et al.</td>
<td class="center">Informational</td>
<td class="right">[Page]</td>
</tr></tfoot>
</table>
<div id="external-metadata" class="document-information"></div>
<div id="internal-metadata" class="document-information">
<dl id="identifiers">
<dt class="label-stream">Stream:</dt>
<dd class="stream">Internet Engineering Task Force (IETF)</dd>
<dt class="label-rfc">RFC:</dt>
<dd class="rfc"><a href="https://www.rfc-editor.org/rfc/rfc9019" class="eref">9019</a></dd>
<dt class="label-category">Category:</dt>
<dd class="category">Informational</dd>
<dt class="label-published">Published:</dt>
<dd class="published">
<time datetime="2021-04" class="published">April 2021</time>
    </dd>
<dt class="label-issn">ISSN:</dt>
<dd class="issn">2070-1721</dd>
<dt class="label-authors">Authors:</dt>
<dd class="authors">
<div class="author">
      <div class="author-name">B. Moran</div>
<div class="org">Arm Limited</div>
</div>
<div class="author">
      <div class="author-name">H. Tschofenig</div>
<div class="org">Arm Limited</div>
</div>
<div class="author">
      <div class="author-name">D. Brown</div>
<div class="org">Linaro</div>
</div>
<div class="author">
      <div class="author-name">M. Meriac</div>
<div class="org">Consultant</div>
</div>
</dd>
</dl>
</div>
<h1 id="rfcnum">RFC 9019</h1>
<h1 id="title">A Firmware Update Architecture for Internet of Things</h1>
<section id="section-abstract">
      <h2 id="abstract"><a href="#abstract" class="selfRef">Abstract</a></h2>
<p id="section-abstract-1">Vulnerabilities in Internet of Things (IoT) devices have raised
 the need for a reliable and secure firmware update mechanism
 suitable for devices with resource constraints. Incorporating such an
 update mechanism is a fundamental requirement for fixing vulnerabilities,
 but it also enables other important capabilities such as updating
 configuration settings
 and adding new functionality.<a href="#section-abstract-1" class="pilcrow">¶</a></p>
<p id="section-abstract-2">In addition to the definition of terminology and an architecture,
 this document provides the motivation for the standardization of a manifest format
 as a transport-agnostic means for describing and protecting firmware
 updates.<a href="#section-abstract-2" class="pilcrow">¶</a></p>
</section>
<div id="status-of-memo">
<section id="section-boilerplate.1">
        <h2 id="name-status-of-this-memo">
<a href="#name-status-of-this-memo" class="section-name selfRef">Status of This Memo</a>
        </h2>
<p id="section-boilerplate.1-1">
            This document is not an Internet Standards Track specification; it is
            published for informational purposes.<a href="#section-boilerplate.1-1" class="pilcrow">¶</a></p>
<p id="section-boilerplate.1-2">
            This document is a product of the Internet Engineering Task Force
            (IETF).  It represents the consensus of the IETF community.  It has
            received public review and has been approved for publication by the
            Internet Engineering Steering Group (IESG).  Not all documents
            approved by the IESG are candidates for any level of Internet
            Standard; see Section 2 of RFC 7841.<a href="#section-boilerplate.1-2" class="pilcrow">¶</a></p>
<p id="section-boilerplate.1-3">
            Information about the current status of this document, any
            errata, and how to provide feedback on it may be obtained at
            <span><a href="https://www.rfc-editor.org/info/rfc9019">https://www.rfc-editor.org/info/rfc9019</a></span>.<a href="#section-boilerplate.1-3" class="pilcrow">¶</a></p>
</section>
</div>
<div id="copyright">
<section id="section-boilerplate.2">
        <h2 id="name-copyright-notice">
<a href="#name-copyright-notice" class="section-name selfRef">Copyright Notice</a>
        </h2>
<p id="section-boilerplate.2-1">
            Copyright (c) 2021 IETF Trust and the persons identified as the
            document authors. All rights reserved.<a href="#section-boilerplate.2-1" class="pilcrow">¶</a></p>
<p id="section-boilerplate.2-2">
            This document is subject to BCP 78 and the IETF Trust's Legal
            Provisions Relating to IETF Documents
            (<span><a href="https://trustee.ietf.org/license-info">https://trustee.ietf.org/license-info</a></span>) in effect on the date of
            publication of this document. Please review these documents
            carefully, as they describe your rights and restrictions with
            respect to this document. Code Components extracted from this
            document must include Simplified BSD License text as described in
            Section 4.e of the Trust Legal Provisions and are provided without
            warranty as described in the Simplified BSD License.<a href="#section-boilerplate.2-2" class="pilcrow">¶</a></p>
</section>
</div>
<div id="toc">
<section id="section-toc.1">
        <a href="#" onclick="scroll(0,0)" class="toplink">▲</a><h2 id="name-table-of-contents">
<a href="#name-table-of-contents" class="section-name selfRef">Table of Contents</a>
        </h2>
<nav class="toc"><ul class="toc compact ulEmpty">
<li class="toc compact ulEmpty" id="section-toc.1-1.1">
            <p id="section-toc.1-1.1.1" class="keepWithNext"><a href="#section-1" class="xref">1</a>.  <a href="#name-introduction" class="xref">Introduction</a></p>
</li>
          <li class="toc compact ulEmpty" id="section-toc.1-1.2">
            <p id="section-toc.1-1.2.1"><a href="#section-2" class="xref">2</a>.  <a href="#name-conventions-and-terminology" class="xref">Conventions and Terminology</a></p>
<ul class="toc compact ulEmpty">
<li class="toc compact ulEmpty" id="section-toc.1-1.2.2.1">
                <p id="section-toc.1-1.2.2.1.1" class="keepWithNext"><a href="#section-2.1" class="xref">2.1</a>.  <a href="#name-terms" class="xref">Terms</a></p>
</li>
              <li class="toc compact ulEmpty" id="section-toc.1-1.2.2.2">
                <p id="section-toc.1-1.2.2.2.1" class="keepWithNext"><a href="#section-2.2" class="xref">2.2</a>.  <a href="#name-stakeholders" class="xref">Stakeholders</a></p>
</li>
              <li class="toc compact ulEmpty" id="section-toc.1-1.2.2.3">
                <p id="section-toc.1-1.2.2.3.1"><a href="#section-2.3" class="xref">2.3</a>.  <a href="#name-functions" class="xref">Functions</a></p>
</li>
            </ul>
</li>
          <li class="toc compact ulEmpty" id="section-toc.1-1.3">
            <p id="section-toc.1-1.3.1"><a href="#section-3" class="xref">3</a>.  <a href="#name-architecture" class="xref">Architecture</a></p>
</li>
          <li class="toc compact ulEmpty" id="section-toc.1-1.4">
            <p id="section-toc.1-1.4.1"><a href="#section-4" class="xref">4</a>.  <a href="#name-invoking-the-firmware" class="xref">Invoking the Firmware</a></p>
<ul class="toc compact ulEmpty">
<li class="toc compact ulEmpty" id="section-toc.1-1.4.2.1">
                <p id="section-toc.1-1.4.2.1.1"><a href="#section-4.1" class="xref">4.1</a>.  <a href="#name-the-bootloader" class="xref">The Bootloader</a></p>
</li>
            </ul>
</li>
          <li class="toc compact ulEmpty" id="section-toc.1-1.5">
            <p id="section-toc.1-1.5.1"><a href="#section-5" class="xref">5</a>.  <a href="#name-types-of-iot-devices" class="xref">Types of IoT Devices</a></p>
<ul class="toc compact ulEmpty">
<li class="toc compact ulEmpty" id="section-toc.1-1.5.2.1">
                <p id="section-toc.1-1.5.2.1.1"><a href="#section-5.1" class="xref">5.1</a>.  <a href="#name-single-mcu" class="xref">Single MCU</a></p>
</li>
              <li class="toc compact ulEmpty" id="section-toc.1-1.5.2.2">
                <p id="section-toc.1-1.5.2.2.1"><a href="#section-5.2" class="xref">5.2</a>.  <a href="#name-single-cpu-with-partitionin" class="xref">Single CPU with Partitioning between Secure Mode and Normal Mode</a></p>
</li>
              <li class="toc compact ulEmpty" id="section-toc.1-1.5.2.3">
                <p id="section-toc.1-1.5.2.3.1"><a href="#section-5.3" class="xref">5.3</a>.  <a href="#name-symmetric-multiple-cpus" class="xref">Symmetric Multiple CPUs</a></p>
</li>
              <li class="toc compact ulEmpty" id="section-toc.1-1.5.2.4">
                <p id="section-toc.1-1.5.2.4.1"><a href="#section-5.4" class="xref">5.4</a>.  <a href="#name-dual-cpu-shared-memory" class="xref">Dual CPU, Shared Memory</a></p>
</li>
              <li class="toc compact ulEmpty" id="section-toc.1-1.5.2.5">
                <p id="section-toc.1-1.5.2.5.1"><a href="#section-5.5" class="xref">5.5</a>.  <a href="#name-dual-cpu-other-bus" class="xref">Dual CPU, Other Bus</a></p>
</li>
            </ul>
</li>
          <li class="toc compact ulEmpty" id="section-toc.1-1.6">
            <p id="section-toc.1-1.6.1"><a href="#section-6" class="xref">6</a>.  <a href="#name-manifests" class="xref">Manifests</a></p>
</li>
          <li class="toc compact ulEmpty" id="section-toc.1-1.7">
            <p id="section-toc.1-1.7.1"><a href="#section-7" class="xref">7</a>.  <a href="#name-securing-firmware-updates" class="xref">Securing Firmware Updates</a></p>
</li>
          <li class="toc compact ulEmpty" id="section-toc.1-1.8">
            <p id="section-toc.1-1.8.1"><a href="#section-8" class="xref">8</a>.  <a href="#name-example" class="xref">Example</a></p>
</li>
          <li class="toc compact ulEmpty" id="section-toc.1-1.9">
            <p id="section-toc.1-1.9.1"><a href="#section-9" class="xref">9</a>.  <a href="#name-iana-considerations" class="xref">IANA Considerations</a></p>
</li>
          <li class="toc compact ulEmpty" id="section-toc.1-1.10">
            <p id="section-toc.1-1.10.1"><a href="#section-10" class="xref">10</a>. <a href="#name-security-considerations" class="xref">Security Considerations</a></p>
</li>
          <li class="toc compact ulEmpty" id="section-toc.1-1.11">
            <p id="section-toc.1-1.11.1"><a href="#section-11" class="xref">11</a>. <a href="#name-informative-references" class="xref">Informative References</a></p>
</li>
          <li class="toc compact ulEmpty" id="section-toc.1-1.12">
            <p id="section-toc.1-1.12.1"><a href="#section-appendix.a" class="xref"></a><a href="#name-acknowledgements" class="xref">Acknowledgements</a></p>
</li>
          <li class="toc compact ulEmpty" id="section-toc.1-1.13">
            <p id="section-toc.1-1.13.1"><a href="#section-appendix.b" class="xref"></a><a href="#name-authors-addresses" class="xref">Authors' Addresses</a></p>
</li>
        </ul>
</nav>
</section>
</div>
<div id="introduction">
<section id="section-1">
      <h2 id="name-introduction">
<a href="#section-1" class="section-number selfRef">1. </a><a href="#name-introduction" class="section-name selfRef">Introduction</a>
      </h2>
<p id="section-1-1">Firmware updates can help to fix security vulnerabilities, and
 performing updates is an important building block in securing
 IoT devices. Due to rising concerns about insecure IoT devices, the Internet
 Architecture Board (IAB) organized the Internet of Things Software Update (IoTSU) Workshop <span>[<a href="#RFC8240" class="xref">RFC8240</a>]</span> to take a look at
 the bigger picture. The workshop revealed a number of challenges for developers
 and led to the formation of the IETF
 Software Updates for Internet of Things (SUIT) Working Group.<a href="#section-1-1" class="pilcrow">¶</a></p>
<p id="section-1-2">Developing secure IoT devices is not an easy
 task, and supporting a firmware update solution requires skillful
 engineers. Once devices are deployed, firmware updates play a
 critical part in their life-cycle management, particularly when devices have a
 long lifetime or are deployed in remote or inaccessible areas where manual
 intervention is cost prohibitive or otherwise difficult. Firmware updates
 for IoT devices are expected to work automatically, i.e., without user
 involvement. Conversely, non-IoT devices are expected to account for user
 preferences and consent when scheduling updates.
 Automatic updates that do not require human intervention
 are key to a scalable solution for fixing software vulnerabilities.<a href="#section-1-2" class="pilcrow">¶</a></p>
<p id="section-1-3">Firmware updates are done not only to fix bugs                                                  but also to add new functionality and to reconfigure
 the device to work in new environments or to behave differently in
 an already-deployed context.<a href="#section-1-3" class="pilcrow">¶</a></p>
<p id="section-1-4">The manifest specification has to allow the following:<a href="#section-1-4" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-1-5.1">The firmware image is authenticated and integrity protected.
 Attempts to flash a maliciously modified firmware image or an image from
 an unknown, untrusted source must be prevented. This document
 uses asymmetric cryptography in examples because it is the preferred approach by
 many IoT deployments. The use of symmetric credentials is also supported
 and can be used by very constrained IoT devices.<a href="#section-1-5.1" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-1-5.2">The firmware image can be confidentiality protected so that
 attempts by an adversary to recover the plaintext binary can
 be mitigated or at least made more difficult. Obtaining the firmware is often one of
 the first steps to mounting an attack since it gives the adversary
 valuable insights into the software libraries used, configuration
 settings, and generic functionality. Even though reverse
 engineering the binary can be a tedious process, modern reverse
 engineering frameworks have made this task a lot easier.<a href="#section-1-5.2" class="pilcrow">¶</a>
</li>
      </ul>
<p id="section-1-6">Authentication and integrity protection of firmware images must be used in a deployment, but the confidential protection of firmware is optional.<a href="#section-1-6" class="pilcrow">¶</a></p>
<p id="section-1-7">While the standardization work has been informed by and optimized for firmware
 update use cases of Class 1 devices (according to the device class
 definitions in RFC 7228 <span>[<a href="#RFC7228" class="xref">RFC7228</a>]</span>), there is nothing in
 the architecture that restricts its use to only these constrained IoT devices.
 Moreover, this architecture is not limited to managing firmware and software updates
 but can also be applied to managing the delivery of arbitrary data, such
 as configuration information and keys. Unlike higher-end devices, like
 laptops and desktop PCs, many IoT devices do not have user interfaces; therefore,
 support for unattended updates is essential for the design
 of a practical solution. Constrained IoT devices often use a
 software engineering model where a developer is responsible for creating
 and compiling all software running on the device into a single, monolithic
 firmware image. On higher-end devices, application software is, on the other
 hand, often downloaded separately and even obtained from developers different
 from the developers of the lower-level software. The details for how to obtain
 those application-layer software binaries then depend heavily on the platform,
 the programming language used, and the sandbox in which the software is executed.<a href="#section-1-7" class="pilcrow">¶</a></p>
<p id="section-1-8">While the IETF standardization work has been focused on the
 manifest format, a fully interoperable solution needs more than a standardized
 manifest. For example, protocols for transferring firmware images
 and manifests to the device need to be available, as well as the status tracker
 functionality. Devices also require a mechanism to discover the status
 tracker(s) and/or firmware servers, for example, using preconfigured hostnames
 or DNS-based Service Discovery (DNS-SD) <span>[<a href="#RFC6763" class="xref">RFC6763</a>]</span>.
 These building blocks have been developed by various organizations
 under the umbrella of an IoT device management solution. The Lightweight Machine-to-Machine (LwM2M) protocol <span>[<a href="#LwM2M" class="xref">LwM2M</a>]</span> is one
 IoT device management protocol.<a href="#section-1-8" class="pilcrow">¶</a></p>
<p id="section-1-9">However, there are several areas that (partially) fall outside the scope of the IETF
 and other standards organizations but need to be considered by firmware authors
 as well as device and network operators. Here are some of them, as highlighted during
 the IoTSU workshop:<a href="#section-1-9" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-1-10.1">Installing firmware updates in a robust fashion so that the
 update does not break the device functionality of the environment
 in which this device operates. This requires proper testing and offering of recovery strategies when a firmware update is unsuccessful.<a href="#section-1-10.1" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-1-10.2">Making firmware updates available in a timely fashion considering the
 complexity of the decision-making process for updating devices,
 potential recertification requirements, the length of a supply chain
 an update needs to go through before it reaches the end customer,
 and the need for user consent to install updates.<a href="#section-1-10.2" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-1-10.3">Ensuring an energy-efficient design of a battery-powered IoT device; a
 firmware update, particularly radio communication and writing the firmware image
 to flash, is an energy-intensive task for a device.<a href="#section-1-10.3" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-1-10.4">Creating incentives for device operators to use a firmware update mechanism and to
 require its integration from IoT device vendors.<a href="#section-1-10.4" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-1-10.5">Ensuring that firmware updates addressing critical flaws can be
 obtained even after a product is discontinued or a vendor goes out of
 business.<a href="#section-1-10.5" class="pilcrow">¶</a>
</li>
      </ul>
<p id="section-1-11">This document starts with a terminology list followed by a description of the architecture.
 We then explain the bootloader and how it integrates with the firmware update mechanism.
 Subsequently, we offer a categorization of IoT devices in terms of their hardware
 capabilities relevant for firmware updates. Next, we talk about the manifest structure
 and how to use it to secure firmware updates. We conclude with a more detailed example of a message flow for distributing a firmware image to a device.<a href="#section-1-11" class="pilcrow">¶</a></p>
</section>
</div>
<div id="terminology">
<section id="section-2">
      <h2 id="name-conventions-and-terminology">
<a href="#section-2" class="section-number selfRef">2. </a><a href="#name-conventions-and-terminology" class="section-name selfRef">Conventions and Terminology</a>
      </h2>
<div id="terms">
<section id="section-2.1">
        <h3 id="name-terms">
<a href="#section-2.1" class="section-number selfRef">2.1. </a><a href="#name-terms" class="section-name selfRef">Terms</a>
        </h3>
<p id="section-2.1-1">This document uses the following terms:<a href="#section-2.1-1" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlNewline" id="section-2.1-2">
          <dt id="section-2.1-2.1">Firmware Image:</dt>
          <dd style="margin-left: 1.5em" id="section-2.1-2.2">
            <p id="section-2.1-2.2.1">The firmware image, or simply the "image", is a binary
 that may contain the complete software of a device or a subset of
 it. The firmware image may consist of multiple images if
 the device contains more than one microcontroller. Often,
 it is also a compressed archive that contains code,
 configuration data, and even the entire file system. The
 image may consist of a differential update for performance
 reasons.<a href="#section-2.1-2.2.1" class="pilcrow">¶</a></p>
<p id="section-2.1-2.2.2">
 The terms "firmware image", "firmware", and "image" are used in this
 document and are interchangeable. We use the term "application firmware
 image" to differentiate it from a firmware image that
 contains the bootloader. An application firmware image, as the
 name indicates, contains the application program often including
 all the necessary code to run it (such as protocol stacks and
 an embedded operating system (OS)).<a href="#section-2.1-2.2.2" class="pilcrow">¶</a></p>
</dd>
          <dd class="break"></dd>
<dt id="section-2.1-2.3">Manifest:</dt>
          <dd style="margin-left: 1.5em" id="section-2.1-2.4">The manifest contains metadata about the firmware
 image. The manifest is protected against modification and
 provides information about the author.<a href="#section-2.1-2.4" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-2.1-2.5">Microcontroller:</dt>
          <dd style="margin-left: 1.5em" id="section-2.1-2.6">A microcontroller unit (MCU) is a
 compact integrated circuit designed for use in embedded systems.
 A typical microcontroller includes a processor, memory (RAM and
 flash), input/output (I/O) ports, and other features connected via
 some bus on a single chip. The term "system on chip" (SoC) is
 often used interchangeably with MCU, but MCU tends to imply more
 limited peripheral functions.<a href="#section-2.1-2.6" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-2.1-2.7">Rich Execution Environment (REE):</dt>
          <dd style="margin-left: 1.5em" id="section-2.1-2.8"> An environment that is provided
 and governed by a typical OS (e.g., Linux, Windows, Android, iOS),
 potentially in conjunction with other supporting operating systems
 and hypervisors; it is outside of the Trusted Execution Environment (TEE).  This environment and the applications running on it are considered untrusted.<a href="#section-2.1-2.8" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-2.1-2.9">Software:</dt>
          <dd style="margin-left: 1.5em" id="section-2.1-2.10"> Similar to firmware but typically dynamically loaded by an
 OS. Used interchangeably with firmware in this document.<a href="#section-2.1-2.10" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-2.1-2.11">System on Chip (SoC):</dt>
          <dd style="margin-left: 1.5em" id="section-2.1-2.12"> An SoC is an integrated circuit that
 contains all components of a computer, such as the CPU, memory,
 I/O ports, secondary storage, a bus to connect the
 components, and other hardware blocks of logic.<a href="#section-2.1-2.12" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-2.1-2.13">Trust Anchor:</dt>
          <dd style="margin-left: 1.5em" id="section-2.1-2.14"> A trust anchor, as defined in RFC 6024 <span>[<a href="#RFC6024" class="xref">RFC6024</a>]</span>, represents
 an authoritative entity via a public key and associated data.  The
 public key is used to verify digital signatures, and the associated
 data is used to constrain the types of information for which the
 trust anchor is authoritative.<a href="#section-2.1-2.14" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-2.1-2.15">Trust Anchor Store:</dt>
          <dd style="margin-left: 1.5em" id="section-2.1-2.16"> A trust anchor store, as defined in <span>[<a href="#RFC6024" class="xref">RFC6024</a>]</span>,
 is a set of one or more trust anchors stored in a device.  A device
 may have more than one trust anchor store, each of which may be used
 by one or more applications. A trust anchor store must resist
 modification against unauthorized insertion, deletion, and modification.<a href="#section-2.1-2.16" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-2.1-2.17">Trusted Applications (TAs):</dt>
          <dd style="margin-left: 1.5em" id="section-2.1-2.18"> An application component that runs in
 a TEE.<a href="#section-2.1-2.18" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-2.1-2.19">Trusted Execution Environments (TEEs):</dt>
          <dd style="margin-left: 1.5em" id="section-2.1-2.20">An execution environment
 that runs alongside of, but is isolated from, an REE. For more
 information about TEEs, see <span>[<a href="#I-D.ietf-teep-architecture" class="xref">TEEP-ARCH</a>]</span>.<a href="#section-2.1-2.20" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
</dl>
</section>
</div>
<div id="stakeholders">
<section id="section-2.2">
        <h3 id="name-stakeholders">
<a href="#section-2.2" class="section-number selfRef">2.2. </a><a href="#name-stakeholders" class="section-name selfRef">Stakeholders</a>
        </h3>
<p id="section-2.2-1">The following stakeholders are used in this document:<a href="#section-2.2-1" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlNewline" id="section-2.2-2">
          <dt id="section-2.2-2.1">Author:</dt>
          <dd style="margin-left: 1.5em" id="section-2.2-2.2">The author is the entity that creates the firmware image.
 There may be multiple authors involved in producing firmware running
 on an IoT device. <a href="#device" class="xref">Section 5</a> talks about those IoT device deployment cases.<a href="#section-2.2-2.2" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-2.2-2.3">Device Operator:</dt>
          <dd style="margin-left: 1.5em" id="section-2.2-2.4"> The device operator is responsible for the day-to-day operation
 of a fleet of IoT devices. Customers of IoT devices, as the owners of
 IoT devices (such as enterprise customers or end users), interact
 with their IoT devices indirectly through the device operator via
 the Web or smartphone apps.<a href="#section-2.2-2.4" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-2.2-2.5">Network Operator:</dt>
          <dd style="margin-left: 1.5em" id="section-2.2-2.6"> The network operator is responsible for the operation of a
 network to which IoT devices connect.<a href="#section-2.2-2.6" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-2.2-2.7">Trust Provisioning Authority (TPA):</dt>
          <dd style="margin-left: 1.5em" id="section-2.2-2.8">The TPA distributes
 trust anchors and authorization policies to devices and various stakeholders.
 The TPA may also delegate rights to stakeholders. Typically, the
 original equipment manufacturer (OEM) or original design manufacturer
 (ODM) will act as a TPA; however, complex supply chains may require
 a different design. In some cases, the TPA may decide to remain in
 full control over the firmware update process of their products.<a href="#section-2.2-2.8" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-2.2-2.9">User:</dt>
          <dd style="margin-left: 1.5em" id="section-2.2-2.10">The end user of a device. The user may interact with devices
 via the Web or smartphone apps, as well as through direct user interfaces.<a href="#section-2.2-2.10" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
</dl>
</section>
</div>
<div id="functions">
<section id="section-2.3">
        <h3 id="name-functions">
<a href="#section-2.3" class="section-number selfRef">2.3. </a><a href="#name-functions" class="section-name selfRef">Functions</a>
        </h3>
<span class="break"></span><dl class="dlNewline" id="section-2.3-1">
          <dt id="section-2.3-1.1">(IoT) Device:</dt>
          <dd style="margin-left: 1.5em" id="section-2.3-1.2"> A device refers to the entire IoT product, which
 consists of one or many MCUs, sensors, and/or actuators. Many IoT
 devices sold today contain multiple MCUs; therefore, a single
 device may need to obtain more than one firmware image and
 manifest to successfully perform an update.<a href="#section-2.3-1.2" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-2.3-1.3">Status Tracker:</dt>
          <dd style="margin-left: 1.5em" id="section-2.3-1.4">
            <p id="section-2.3-1.4.1">The status tracker has a client and a server component
 and performs three tasks:<a href="#section-2.3-1.4.1" class="pilcrow">¶</a></p>
<ol start="1" type="1" class="normal type-1" id="section-2.3-1.4.2">
 <li id="section-2.3-1.4.2.1">It communicates the availability of a new firmware version. This
    information will flow from the server to the client.<a href="#section-2.3-1.4.2.1" class="pilcrow">¶</a>
</li>
              <li id="section-2.3-1.4.2.2">It conveys information about the software and hardware characteristics of
    the device. The information flow is from the client to the server.<a href="#section-2.3-1.4.2.2" class="pilcrow">¶</a>
</li>
              <li id="section-2.3-1.4.2.3">It can remotely trigger the firmware update process. The
    information flow is from the server to the client.<a href="#section-2.3-1.4.2.3" class="pilcrow">¶</a>
</li>
            </ol>
<p id="section-2.3-1.4.3">
 For example, a device operator may want to read the installed firmware
 version number running on the device and information
 about available flash memory. Once an update has been triggered, the device
 operator may want to obtain information about the state of the firmware
 update. If errors occurred, the device operator may want to
 troubleshoot problems by first obtaining diagnostic information (typically
 using a device management protocol).<a href="#section-2.3-1.4.3" class="pilcrow">¶</a></p>
<p id="section-2.3-1.4.4">
 We make no
 assumptions about where the server-side component is deployed.
 The deployment of status trackers is flexible: they may
     be found at cloud-based servers or on-premise servers,
     or they may be embedded in edge computing devices. A status tracker server component may even be
 deployed on an IoT device. For example, if the IoT device contains
 multiple MCUs, then the main MCU may act as a status tracker towards the
 other MCUs. Such deployment is useful when updates have to be
 synchronized across MCUs.<a href="#section-2.3-1.4.4" class="pilcrow">¶</a></p>
<p id="section-2.3-1.4.5">
 The status tracker may be operated by any suitable stakeholder,
 typically the author, device operator, or network operator.<a href="#section-2.3-1.4.5" class="pilcrow">¶</a></p>
</dd>
          <dd class="break"></dd>
<dt id="section-2.3-1.5">Firmware Consumer:</dt>
          <dd style="margin-left: 1.5em" id="section-2.3-1.6"> The firmware consumer is the recipient of the
 firmware image and the manifest. It is responsible for parsing
 and verifying the received manifest and for storing the obtained
 firmware image. The firmware consumer plays the role of the
 update component on the IoT device, typically running in the
 application firmware. It interacts with the firmware server and
 the status tracker client (locally).<a href="#section-2.3-1.6" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-2.3-1.7">Firmware Server:</dt>
          <dd style="margin-left: 1.5em" id="section-2.3-1.8"> The firmware server stores firmware images and
 manifests and distributes them to IoT devices. Some deployments
 may require a store-and-forward concept, which requires storing
 the firmware images and/or manifests on more than one entity before they reach the device. There is typically some interaction between the
 firmware server and the status tracker, and these two entities are often
 physically separated on different devices for scalability reasons.<a href="#section-2.3-1.8" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-2.3-1.9">Bootloader:</dt>
          <dd style="margin-left: 1.5em" id="section-2.3-1.10"> A bootloader is a piece of software that is
 executed once a microcontroller has been reset. It is
 responsible for deciding what code to execute.<a href="#section-2.3-1.10" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
</dl>
</section>
</div>
</section>
</div>
<div id="architecture">
<section id="section-3">
      <h2 id="name-architecture">
<a href="#section-3" class="section-number selfRef">3. </a><a href="#name-architecture" class="section-name selfRef">Architecture</a>
      </h2>
<p id="section-3-1">More devices than ever before are connected to the Internet,
 which drives the need for firmware updates to be provided over the
 Internet rather than through traditional interfaces, such as USB or
 RS-232. Sending updates over the Internet requires the device to fetch
 the new firmware image as well as the manifest.<a href="#section-3-1" class="pilcrow">¶</a></p>
<p id="section-3-2">Hence, the following components are necessary on a device for a firmware
 update solution:<a href="#section-3-2" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-3-3.1">The Internet protocol stack for firmware downloads. 


Firmware images are often multiple kilobytes, sometimes
 exceeding one hundred kilobytes, for low-end IoT devices and can even be
 several megabytes for IoT devices running full-fledged operating systems
 like Linux. The protocol mechanism for retrieving these images needs
 to offer features like congestion control, flow control, fragmentation
 and reassembly, and mechanisms to resume interrupted or corrupted transfers.<a href="#section-3-3.1" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-3-3.2">The capability to write the received firmware image to
 persistent storage (most likely flash memory).<a href="#section-3-3.2" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-3-3.3">A manifest parser with code to verify a digital
 signature or a message authentication code (MAC).<a href="#section-3-3.3" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-3-3.4">The ability to unpack, decompress, and/or decrypt the
 received firmware image.<a href="#section-3-3.4" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-3-3.5">A status tracker.<a href="#section-3-3.5" class="pilcrow">¶</a>
</li>
      </ul>
<p id="section-3-4">The features listed above are most likely provided by code in the application firmware
 image running
 on the device rather than by the bootloader itself. Note that
 cryptographic algorithms will likely run in a trusted execution
 environment on a separate MCU in a hardware security module or in a secure element
 rather than in the same context as the application code.<a href="#section-3-4" class="pilcrow">¶</a></p>
<p id="section-3-5"><a href="#arch-figure" class="xref">Figure 1</a> shows the architecture where a
 firmware image is created by an author and made available to a firmware
 server. For security reasons, the author will not have the permissions to
 upload firmware images to the firmware server and to initiate an update directly.
 Instead, authors will make firmware images available to the device operators. Note that
 there may be a longer supply chain involved to pass software updates from the author all
 the way to the authorizing party, which can then finally make a decision to deploy it with IoT devices.<a href="#section-3-5" class="pilcrow">¶</a></p>
<p id="section-3-6">As a first step in the firmware update process, the status tracker
 server needs to inform the status tracker client that a new firmware
 update is available. This can be accomplished via polling (client initiated), 
 push notifications (server initiated), or more complex mechanisms (such as a hybrid approach):<a href="#section-3-6" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-3-7.1">Client-initiated updates take the form of a status tracker client proactively
 checking (polling) for updates.<a href="#section-3-7.1" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-3-7.2">With server-initiated updates, the server-side component of the status tracker
learns about a new firmware version and determines which devices qualify for a
firmware update. Once the relevant devices have been selected, the
status tracker informs these devices, and the firmware consumers obtain those
images and manifests. Server-initiated updates are important because they allow a quick
response time. Note that in this mode, the client-side status tracker needs to be reachable by the server-side
component. This may require devices to keep reachability information on the
server side up to date and the state at NATs and stateful packet filtering
firewalls alive.<a href="#section-3-7.2" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-3-7.3">Using a hybrid approach, the server side of the status tracker
pushes update availability notifications to the client side and requests that
the firmware consumer pull the manifest and the firmware image from the
firmware server.<a href="#section-3-7.3" class="pilcrow">¶</a>
</li>
      </ul>
<p id="section-3-8">Once the device operator triggers an update via the status tracker, it will keep
track of the update process on the device. This allows the device operator to know what
devices have received an update and which of them are still pending an update.<a href="#section-3-8" class="pilcrow">¶</a></p>
<p id="section-3-9">Firmware images can be conveyed to devices in a variety of ways,
including USB,  Universal Asynchronous Receiver Transmitter (UART), WiFi, Bluetooth Low Energy (BLE), low-power WAN technologies, mesh networks and many more.
At the application layer,
a variety of protocols are also available: Message Queuing Telemetry Transport (MQTT), Constrained Application Protocol (CoAP), and HTTP are the
most popular application-layer protocols used by IoT devices. This architecture
does not make assumptions about how the firmware images are distributed to the
devices and therefore aims to support all these technologies.<a href="#section-3-9" class="pilcrow">¶</a></p>
<p id="section-3-10">In some cases, it may be desirable to distribute firmware images using a multicast
or broadcast protocol. This architecture does not make recommendations for any
such protocol. However, given that broadcast may be desirable for some networks,
updates must cause the least disruption possible both in the metadata
and firmware transmission. For an update to be broadcast friendly, it cannot rely on link-layer, network-layer, or transport-layer security. A solution has
to rely on security protection applied to the manifest and firmware image
instead. In addition,
the same manifest must be deliverable to many devices, both those
to which it applies and those to which it does not, without a
chance that the wrong device will accept the update. Considerations
that apply to network broadcasts apply equally to the use of
third-party content distribution networks for payload distribution.<a href="#section-3-10" class="pilcrow">¶</a></p>
<span id="name-architecture-2"></span><div id="arch-figure">
<figure id="figure-1">
        <div class="artwork art-text alignCenter" id="section-3-11.1">
<pre>
                                                      +----------+
                                                      |          |
                                                      |  Author  |
                                                      |          |
                                                      +----------+
                       Firmware + Manifest                 |
              +----------------------------------+         | Firmware +
              |                                  |         | Manifest
              |                               ---+-------  |
              |                           ----   |       --|-
              |                         //+----------+     | \\
             -+--                      // |          |     |   \
        ----/ |  ----                |/   | Firmware |&lt;-+  |    \
      //      |      \\              |    | Server   |  |  |     \
     /        |        \             /    |          |  +  +      \
    /         |         \           /     +----------+   \ /       |
   / +--------+--------+ \         /                      |        |
  /  |        v        |  \       /                       v        |
 |   | +------------+  |   |     |          +----------------+      |
 |   | |  Firmware  |  |   |     |          |     Device     |      |
 |   | |  Consumer  |  |   |     |          |     Management |      |
|    | +------------+  |    |    |          |                |      |
|    | +------------+  |    |    |          |    +--------+  |      |
|    | |  Status    |&lt;-+--------------------+-&gt;  |        |  |      |
|    | |  Tracker   |  |    |    |          |    | Status |  |      |
|    | |  Client    |  |    |    |          |    | Tracker|  |     |
 |   | +------------+  |   |     |          |    | Server |  |     |
 |   |    Device       |   |      |         |    +--------+  |     |
 |   +-----------------+   |       \        |                |    /
  \                       /         \       +----------------+   /
   \       Network       /           \                          /
    \     Operator      /             \     Device Operator    /
     \\               //               \\                    //
        ----     ----                     ----           ----
            -----                             -----------
</pre>
</div>
<figcaption><a href="#figure-1" class="selfRef">Figure 1</a>:
<a href="#name-architecture-2" class="selfRef">Architecture</a>
        </figcaption></figure>
</div>
<p id="section-3-12">Firmware images and manifests may be conveyed as a bundle or detached. The
manifest format must support both approaches.<a href="#section-3-12" class="pilcrow">¶</a></p>
<p id="section-3-13">For distribution as a bundle, the firmware image is embedded into the manifest.
This is a useful approach for deployments where devices are not connected
to the Internet and cannot contact a dedicated firmware server for the firmware
download. It is also applicable when the firmware update happens via USB sticks or short-range radio technologies (such as Bluetooth Smart).<a href="#section-3-13" class="pilcrow">¶</a></p>
<p id="section-3-14">Alternatively, the manifest is distributed detached from the firmware image.
Using this approach, the firmware consumer is presented with the manifest first
and then needs to obtain one or more firmware images as dictated in the
manifest.<a href="#section-3-14" class="pilcrow">¶</a></p>
<p id="section-3-15">The pre-authorization step involves verifying whether the entity
signing the manifest is indeed authorized to perform an update.
The firmware consumer must also determine whether it should fetch and
process a firmware image, which is referenced in a manifest.<a href="#section-3-15" class="pilcrow">¶</a></p>
<p id="section-3-16">A dependency resolution phase is needed when more than one
component can be updated or when a differential update is used.
The necessary dependencies must be available prior to installation.<a href="#section-3-16" class="pilcrow">¶</a></p>
<p id="section-3-17">The download step is the process of acquiring a local copy of the
firmware image.  When the download is client initiated, this means
that the firmware consumer chooses when a download occurs and initiates
the download process.  When a download is server initiated,
this means that the status tracker tells
the device when to download or that it initiates the transfer
directly to the firmware consumer. For example, a download from an
HTTP/1.1-based firmware server is client initiated. Pushing a manifest
and firmware image to the Package Resource of the LwM2M
Firmware Update Object <span>[<a href="#LwM2M" class="xref">LwM2M</a>]</span> is a server-initiated update.<a href="#section-3-17" class="pilcrow">¶</a></p>
<p id="section-3-18">If the firmware consumer has downloaded a new firmware image and is ready to
install it, to initiate the installation, it may<a href="#section-3-18" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-3-19.1">need to wait for a trigger from the status tracker,<a href="#section-3-19.1" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-3-19.2">trigger the update automatically, or<a href="#section-3-19.2" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-3-19.3">go through a more complex decision-making process to determine  
      the appropriate timing for an update.<a href="#section-3-19.3" class="pilcrow">¶</a>
</li>
      </ul>
<p id="section-3-20"> Sometimes the final decision may
require confirmation of the user of the device for safety reasons.<a href="#section-3-20" class="pilcrow">¶</a></p>
<p id="section-3-21">Installation is the act of processing the payload into a format that
the IoT device can recognize, and the bootloader is responsible for
then booting from the newly installed firmware image.
This process is different when a bootloader is not involved. For example,
when an application is updated in a full-featured OS, the
updater may halt and restart the application in isolation. 
Devices must not fail when a disruption, such as a power failure or network
interruption, occurs during the update process.<a href="#section-3-21" class="pilcrow">¶</a></p>
</section>
</div>
<div id="invocation">
<section id="section-4">
      <h2 id="name-invoking-the-firmware">
<a href="#section-4" class="section-number selfRef">4. </a><a href="#name-invoking-the-firmware" class="section-name selfRef">Invoking the Firmware</a>
      </h2>
<p id="section-4-1"><a href="#architecture" class="xref">Section 3</a> describes the steps for getting the firmware image and the manifest
from the author to the firmware consumer on the IoT device. Once the firmware consumer
has retrieved and successfully processed the manifest and the firmware image, it needs
to invoke the new firmware image. This is managed in many different ways depending
on the type of device, but it typically involves halting the current version of the
firmware, handing over control to firmware with a higher privilege or trust level
(the firmware verifier),
verifying the new firmware's authenticity and integrity, and then invoking it.<a href="#section-4-1" class="pilcrow">¶</a></p>
<p id="section-4-2">In an execute-in-place microcontroller, this is often done by rebooting into a
bootloader (simultaneously halting the application and handing over control to the higher
privilege level) then executing a secure boot process (verifying and invoking
the new image).<a href="#section-4-2" class="pilcrow">¶</a></p>
<p id="section-4-3">In a rich OS, this may be done by halting one or more processes and then invoking
new applications. In some OSes, this implicitly involves the kernel verifying
the code signatures on the new applications.<a href="#section-4-3" class="pilcrow">¶</a></p>
<p id="section-4-4">The invocation process is security sensitive. An attacker will typically try to
retrieve a firmware image from the device for reverse engineering or will try to get
the firmware verifier to execute an attacker-modified firmware image. Therefore,
firmware verifier will have to perform security checks on the
firmware image before it can be invoked. These security checks by the
firmware verifier happen in addition to the security checks that took place
when the firmware image and the manifest were downloaded by the firmware consumer.<a href="#section-4-4" class="pilcrow">¶</a></p>
<p id="section-4-5">The overlap between the firmware consumer and the firmware verifier
functionality comes in two forms, namely:<a href="#section-4-5" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-4-6.1">A firmware verifier must verify the firmware image it boots as
part of the secure boot process. Doing so requires metadata to be
stored alongside the firmware image so that the firmware verifier can
cryptographically verify the firmware image before booting it to
ensure it has not been tampered with or replaced. This metadata
used by the firmware verifier may well be the same manifest obtained with the
firmware image during the update process.<a href="#section-4-6.1" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-4-6.2">An IoT device needs a recovery strategy in case the firmware
update/invocation process fails. The recovery
strategy may include storing two or more application firmware images
on the device or offering the ability to invoke a recovery image to
perform the firmware update process again using firmware updates over
serial, USB, or even wireless connectivity like Bluetooth Smart.
In the latter case, the firmware consumer functionality is contained in the
recovery image and requires the necessary functionality for
executing the firmware update process, including manifest parsing.<a href="#section-4-6.2" class="pilcrow">¶</a>
</li>
      </ul>
<p id="section-4-7">While this document assumes that the firmware verifier itself is
distinct from the role of the firmware consumer and therefore does not
manage the firmware update process, this is not a requirement, and these
roles may be combined in practice.<a href="#section-4-7" class="pilcrow">¶</a></p>
<p id="section-4-8">Using a bootloader as the firmware verifier requires some special
considerations, particularly when the bootloader
implements the robustness requirements identified by the IoTSU workshop <span>[<a href="#RFC8240" class="xref">RFC8240</a>]</span>.<a href="#section-4-8" class="pilcrow">¶</a></p>
<div id="bootloader">
<section id="section-4.1">
        <h3 id="name-the-bootloader">
<a href="#section-4.1" class="section-number selfRef">4.1. </a><a href="#name-the-bootloader" class="section-name selfRef">The Bootloader</a>
        </h3>
<p id="section-4.1-1">In most cases, the MCU must restart in order to hand over control to the bootloader.
Once the MCU has initiated a restart, the bootloader determines whether a newly available
firmware image should be executed. If the bootloader concludes that the newly available
firmware image is invalid, a recovery strategy is necessary. There are only two
approaches for recovering from invalid firmware: either the bootloader must be able
to select different, valid firmware or it must be able to obtain new, valid firmware.
Both of these approaches have implications for the architecture of the update system.<a href="#section-4.1-1" class="pilcrow">¶</a></p>
<p id="section-4.1-2">Assuming the first approach, there are (at least) three firmware images available
on the device:<a href="#section-4.1-2" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-4.1-3.1">First, the bootloader is also firmware. If a bootloader is updatable, then its
firmware image is treated like any other application firmware image.<a href="#section-4.1-3.1" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-4.1-3.2">Second, the firmware image that has to be replaced is still available on the
device as a backup in case the freshly downloaded firmware image does not
boot or operate correctly.<a href="#section-4.1-3.2" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-4.1-3.3">Third, there is the newly downloaded firmware image.<a href="#section-4.1-3.3" class="pilcrow">¶</a>
</li>
        </ul>
<p id="section-4.1-4">Therefore, the firmware consumer must know where to store the new firmware.
In some cases, this may be implicit (for example, replacing the least recently used
firmware image). In other cases, the storage location of the new firmware must be
explicit, for example, when a device has one or more application firmware images
and a recovery image with limited functionality, sufficient only to perform an update.<a href="#section-4.1-4" class="pilcrow">¶</a></p>
<p id="section-4.1-5">Since many low-end IoT devices do not use position-independent code,
either the bootloader needs to copy the newly downloaded application firmware image
into the location of the old application firmware image and vice versa or
multiple versions of the firmware need to be prepared for different locations.<a href="#section-4.1-5" class="pilcrow">¶</a></p>
<p id="section-4.1-6">In general, it is assumed that the bootloader itself, or a minimal part of it,
will not be updated since a failed update of the bootloader poses a
reliability risk.<a href="#section-4.1-6" class="pilcrow">¶</a></p>
<p id="section-4.1-7">For a bootloader to offer a secure boot functionality, it needs to
implement the following functionality:<a href="#section-4.1-7" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-4.1-8.1">The bootloader needs to fetch the manifest
from nonvolatile storage and parse its
contents for subsequent cryptographic verification.<a href="#section-4.1-8.1" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-4.1-8.2">Cryptographic libraries with hash functions, digital signatures
(for asymmetric crypto), and message authentication codes (for symmetric
crypto) need to be accessible.<a href="#section-4.1-8.2" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-4.1-8.3">The device needs to have a trust anchor store to verify the
digital signature. Alternatively, access to a key store for use
with the message authentication code may be used.<a href="#section-4.1-8.3" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-4.1-8.4">There must be an ability to expose boot-process-related data to the application
firmware (such as the status tracker).  This allows
information sharing about the current firmware version and the
status of the firmware update process and whether errors have occurred.<a href="#section-4.1-8.4" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-4.1-8.5">Produce boot measurements as part of an attestation solution; see
<span>[<a href="#I-D.ietf-rats-architecture" class="xref">RATS-ARCH</a>]</span> for more information (optional).<a href="#section-4.1-8.5" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-4.1-8.6">The bootloader must be able to decrypt firmware images in case confidentiality protection
was applied. This requires a solution for key management (optional).<a href="#section-4.1-8.6" class="pilcrow">¶</a>
</li>
        </ul>
</section>
</div>
</section>
</div>
<div id="device">
<section id="section-5">
      <h2 id="name-types-of-iot-devices">
<a href="#section-5" class="section-number selfRef">5. </a><a href="#name-types-of-iot-devices" class="section-name selfRef">Types of IoT Devices</a>
      </h2>
<p id="section-5-1">Today, there are billions of MCUs used in devices produced by a large
number of silicon manufacturers. While MCUs can vary significantly
in their characteristics, there are a number of similarities that allow us to categorize them into groups.<a href="#section-5-1" class="pilcrow">¶</a></p>
<p id="section-5-2">The firmware update architecture, and the manifest format in particular,
needs to offer enough flexibility to cover these common deployment cases.<a href="#section-5-2" class="pilcrow">¶</a></p>
<div id="single-mcu">
<section id="section-5.1">
        <h3 id="name-single-mcu">
<a href="#section-5.1" class="section-number selfRef">5.1. </a><a href="#name-single-mcu" class="section-name selfRef">Single MCU</a>
        </h3>
<p id="section-5.1-1">The simplest and currently most common architecture consists of
a single MCU along with its own peripherals.  These SoCs generally
contain some amount of flash memory for code and fixed data, as
well as RAM for working storage.  A notable characteristic of these
SoCs is that the primary code is generally execute in place (XIP).
Due to the non-relocatable nature of the code, the firmware image
needs to be placed in a specific location in flash memory since the code
cannot be executed from an arbitrary location therein. Hence, when
the firmware image is updated, it is necessary to swap the old and
the new image.<a href="#section-5.1-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="single-cpu-with-secure-normal-mode-partitioning">
<section id="section-5.2">
        <h3 id="name-single-cpu-with-partitionin">
<a href="#section-5.2" class="section-number selfRef">5.2. </a><a href="#name-single-cpu-with-partitionin" class="section-name selfRef">Single CPU with Partitioning between Secure Mode and Normal Mode</a>
        </h3>
<p id="section-5.2-1">Another configuration consists of a similar architecture to the
one previously discussed: it contains a single CPU.  However, this CPU supports a security
partitioning scheme that allows memory and other system components to be divided into secure and normal mode.  There will generally be
two images: one for secure mode and one for normal mode.  In this
configuration, firmware upgrades will generally be done by the CPU
in secure mode, which is able to write to both areas of the flash
device. In addition, there are requirements to be able to update
either image independently as well as to update them together
atomically, as specified in the associated manifests.<a href="#section-5.2-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="symmetric-multiple-cpus">
<section id="section-5.3">
        <h3 id="name-symmetric-multiple-cpus">
<a href="#section-5.3" class="section-number selfRef">5.3. </a><a href="#name-symmetric-multiple-cpus" class="section-name selfRef">Symmetric Multiple CPUs</a>
        </h3>
<p id="section-5.3-1">In more complex SoCs with symmetric multiprocessing support, advanced
operating systems, such as Linux, are often used. These SoCs frequently
use an external storage medium, such as raw NAND flash or an embedded Multimedia Card (eMMC). Due to
the higher quantity of resources, these devices are often capable of
storing multiple copies of their firmware images and selecting the most
appropriate one to boot. Many SoCs also support bootloaders that are
capable of updating the firmware image; however, this is typically a last
resort because it requires the device to be held in the bootloader while
the new firmware is downloaded and installed, which results in downtime
for the device. Firmware updates in this class of device are typically
not done in place.<a href="#section-5.3-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="dual-cpu-shared-memory">
<section id="section-5.4">
        <h3 id="name-dual-cpu-shared-memory">
<a href="#section-5.4" class="section-number selfRef">5.4. </a><a href="#name-dual-cpu-shared-memory" class="section-name selfRef">Dual CPU, Shared Memory</a>
        </h3>
<p id="section-5.4-1">This configuration has two or more heterogeneous CPUs in a single SoC that
share memory (flash and RAM).  Generally, there will be a mechanism to prevent
one CPU from unintentionally accessing memory currently allocated to the other.
Upgrades in this case will typically be done by one of the CPUs and is
similar to the single CPU with secure mode.<a href="#section-5.4-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="dual-cpu-other-bus">
<section id="section-5.5">
        <h3 id="name-dual-cpu-other-bus">
<a href="#section-5.5" class="section-number selfRef">5.5. </a><a href="#name-dual-cpu-other-bus" class="section-name selfRef">Dual CPU, Other Bus</a>
        </h3>
<p id="section-5.5-1">This configuration has two or more heterogeneous CPUs, each having their own memory.
There will be a communication channel between them, but it will be
used as a peripheral, not via shared memory.  In this case, each CPU
will have to be responsible for its own firmware upgrade.  It is
likely that one of the CPUs will be considered the primary CPU and will
direct the other CPU to do the upgrade.  This configuration is
commonly used to offload specific work to other CPUs.  Firmware
dependencies are similar to the other solutions above: sometimes
allowing only one image to be upgraded, other times requiring several
to be upgraded atomically.  Because the updates are happening on
multiple CPUs, upgrading the two images atomically is challenging.<a href="#section-5.5-1" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
<div id="manifests">
<section id="section-6">
      <h2 id="name-manifests">
<a href="#section-6" class="section-number selfRef">6. </a><a href="#name-manifests" class="section-name selfRef">Manifests</a>
      </h2>
<p id="section-6-1">In order for a firmware consumer to apply an update, it has to make several decisions
using manifest-provided information and data available on the device itself. For more
detailed information and a longer list of information elements in the manifest, consult the
information model specification <span>[<a href="#I-D.ietf-suit-information-model" class="xref">SUIT-INFO-MODEL</a>]</span>, which offers justifications
for each element, and the manifest specification <span>[<a href="#I-D.ietf-suit-manifest" class="xref">SUIT-MANIFEST</a>]</span> for details about how this
      information is included in the manifest.<a href="#section-6-1" class="pilcrow">¶</a></p>
<span id="name-example-firmware-update-dec"></span><div id="manifest-info">
<table class="center" id="table-1">
        <caption>
<a href="#table-1" class="selfRef">Table 1</a>:
<a href="#name-example-firmware-update-dec" class="selfRef">Example Firmware Update Decisions</a>
        </caption>
<thead>
          <tr>
            <th class="text-right" rowspan="1" colspan="1">Decision</th>
            <th class="text-left" rowspan="1" colspan="1">Information Elements</th>
          </tr>
        </thead>
        <tbody>
          <tr>
            <td class="text-right" rowspan="1" colspan="1">Should I trust the author of the firmware?</td>
            <td class="text-left" rowspan="1" colspan="1">Trust anchors and authorization policies on the device</td>
          </tr>
          <tr>
            <td class="text-right" rowspan="1" colspan="1">Has the firmware been corrupted?</td>
            <td class="text-left" rowspan="1" colspan="1">Digital signature and MAC covering the firmware image</td>
          </tr>
          <tr>
            <td class="text-right" rowspan="1" colspan="1">Does the firmware update apply to this device?</td>
            <td class="text-left" rowspan="1" colspan="1">Conditions with Vendor ID, Class ID, and Device ID</td>
          </tr>
          <tr>
            <td class="text-right" rowspan="1" colspan="1">Is the update older than the active firmware?</td>
            <td class="text-left" rowspan="1" colspan="1">Sequence number in the manifest (1)</td>
          </tr>
          <tr>
            <td class="text-right" rowspan="1" colspan="1">When should the device apply the update?</td>
            <td class="text-left" rowspan="1" colspan="1">Wait directive</td>
          </tr>
          <tr>
            <td class="text-right" rowspan="1" colspan="1">How should the device apply the update?</td>
            <td class="text-left" rowspan="1" colspan="1">Manifest commands</td>
          </tr>
          <tr>
            <td class="text-right" rowspan="1" colspan="1">What kind of firmware binary is it?</td>
            <td class="text-left" rowspan="1" colspan="1">Unpack algorithms to interpret a format</td>
          </tr>
          <tr>
            <td class="text-right" rowspan="1" colspan="1">Where should the update be obtained?</td>
            <td class="text-left" rowspan="1" colspan="1">Dependencies on other manifests and firmware image URI in the manifest</td>
          </tr>
          <tr>
            <td class="text-right" rowspan="1" colspan="1">Where should the firmware be stored?</td>
            <td class="text-left" rowspan="1" colspan="1">Storage location and component identifier</td>
          </tr>
        </tbody>
      </table>
</div>
<span class="break"></span><dl class="dlParallel" id="section-6-3">
        <dt id="section-6-3.1">(1):</dt>
        <dd style="margin-left: 3.0em" id="section-6-3.2">A device presented with an old but valid manifest and firmware
must not be tricked into installing such firmware since a
vulnerability in the old firmware image may allow an attacker to
gain control of the device.<a href="#section-6-3.2" class="pilcrow">¶</a>
</dd>
      <dd class="break"></dd>
</dl>
<p id="section-6-4">Keeping the code size and complexity of a manifest parser small is important
for constrained IoT devices. Since the manifest parsing code may
also be used by the bootloader, it can be part of the trusted computing base.<a href="#section-6-4" class="pilcrow">¶</a></p>
<p id="section-6-5">A manifest may be used to protect not only firmware images but also
configuration data such as network credentials or personalization data
related to the firmware or software.
Personalization data demonstrates the need for confidentiality to be
maintained between two or more stakeholders that deliver images to
the same device. Personalization data is used with
TEEs, which
benefit from a protocol for managing the life cycle of TAs running inside a TEE. TEEs may obtain TAs
from different authors, and those TAs may require personalization data,
such as payment information, to be securely conveyed to the TEE. The
TA's author does not want to expose the TA's code to any other stakeholder
or third party.
The user does not want to expose the payment information to any other
stakeholder or third party.<a href="#section-6-5" class="pilcrow">¶</a></p>
</section>
</div>
<div id="securing">
<section id="section-7">
      <h2 id="name-securing-firmware-updates">
<a href="#section-7" class="section-number selfRef">7. </a><a href="#name-securing-firmware-updates" class="section-name selfRef">Securing Firmware Updates</a>
      </h2>
<p id="section-7-1">Using firmware updates to fix vulnerabilities in devices is important, but securing this
update mechanism is equally important since security problems are
exacerbated by the update mechanism. An update is essentially authorized
remote code execution, so any security problems in the update process
expose that remote code execution system. Failure
to secure the firmware update process will help attackers take control of devices.<a href="#section-7-1" class="pilcrow">¶</a></p>
<p id="section-7-2">End-to-end security mechanisms are used to protect the firmware
image and the manifest. The following assumptions are made to allow
the firmware consumer to verify the received firmware image and
manifest before updating the software:<a href="#section-7-2" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-7-3.1">Authentication ensures that the device can cryptographically identify
the author(s) creating firmware images and manifests. Authenticated
identities may be used as input to the authorization process. Not all
entities creating and signing manifests have the same
permissions. A device needs to determine whether the requested action
is indeed covered by the permission of the party that signed the manifest.
Informing the device about the permissions of the different parties
also happens in an out-of-band fashion and is a duty of the
Trust Provisioning Authority.<a href="#section-7-3.1" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-7-3.2">Integrity protection ensures that no third party can modify the manifest
or the firmware image. To accept an update, a device needs to verify the signature covering
the manifest. There may be one or multiple manifests that need to be
validated, potentially signed by different parties. The device needs
to be in possession of the trust anchors to verify those signatures.
Installing trust anchors to devices via the Trust Provisioning Authority
happens in an out-of-band fashion prior to the firmware update process.<a href="#section-7-3.2" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-7-3.3">

  Confidentiality protection of the firmware image must be done in such a
way that no one aside from the intended firmware consumer(s) and other authorized parties can decrypt it. The information
that is encrypted individually for each device/recipient must be done in a way that is 
usable with Content Distribution Networks (CDNs), bulk storage, and
broadcast protocols. For confidentiality protection of firmware images, the author needs
to be in possession of the certificate/public key or a pre-shared key
of a device. The use of confidentiality protection of firmware images
is optional.<a href="#section-7-3.3" class="pilcrow">¶</a>
</li>
      </ul>
<p id="section-7-4">A manifest specification must support different cryptographic algorithms
and algorithm extensibility. Moreover, since signature
schemes based on RSA and Elliptic Curve Cryptography (ECC) may become vulnerable to quantum-accelerated key extraction in the
future, unchangeable bootloader code in ROM is recommended to use post-quantum
secure signature schemes such as hash-based signatures <span>[<a href="#RFC8778" class="xref">RFC8778</a>]</span>. A
bootloader author must carefully consider the service lifetime of their
product and the time horizon for quantum-accelerated key extraction.
At the time of writing, the worst-case estimate for the time horizon to key
extraction with quantum acceleration is approximately 2030, based on
current research <span>[<a href="#quantum-factorization" class="xref">quantum-factorization</a>]</span>.<a href="#section-7-4" class="pilcrow">¶</a></p>
<p id="section-7-5">When a device obtains a monolithic firmware image from a single author
without any additional approval steps, the authorization flow is
relatively simple. However, there are other cases where more complex
policy decisions need to be made before updating a device.<a href="#section-7-5" class="pilcrow">¶</a></p>
<p id="section-7-6">In this architecture, the authorization policy is separated from
the underlying communication architecture. This is accomplished
by separating the entities from their permissions. For example,
an author may not have the authority to install a firmware image
on a device in critical infrastructure without the authorization
of a device operator. In this case, the device may be programmed
to reject firmware updates unless they are signed both by the
      firmware author and by the device operator.<a href="#section-7-6" class="pilcrow">¶</a></p>
<p id="section-7-7">Alternatively, a device may trust precisely one entity that
does all permission management and coordination. This entity
allows the device to offload complex permissions
calculations for the device.<a href="#section-7-7" class="pilcrow">¶</a></p>
</section>
</div>
<div id="example">
<section id="section-8">
      <h2 id="name-example">
<a href="#section-8" class="section-number selfRef">8. </a><a href="#name-example" class="section-name selfRef">Example</a>
      </h2>
<p id="section-8-1"><a href="#firmware-update" class="xref">Figure 2</a> illustrates an example message flow
for distributing a firmware image to a device. The firmware
and manifest are stored on the same firmware server and
      distributed in a detached manner.<a href="#section-8-1" class="pilcrow">¶</a></p>
<span id="name-first-example-flow-for-a-fi"></span><div id="firmware-update">
<figure id="figure-2">
        <div class="artwork art-text alignCenter" id="section-8-2.1">
<pre>
+--------+    +-----------------+    +-----------------------------+
|        |    | Firmware Server |    |         IoT Device          |
| Author |    | Status Tracker  |    | +------------+ +----------+ |
+--------+    | Server          |    | |  Firmware  | |Bootloader| |
  |           +-----------------+    | |  Consumer  | |          | |
  |                   |              | +------------+ +----------+ |
  |                   |              |      |                |     |
  |                   |              |  +-----------------------+  |
  | Create Firmware   |              |  | Status Tracker Client |  |
  |--------------+    |              |  +-----------------------+  |
  |              |    |               `''''''''''''''''''''''''''''
  |&lt;-------------+    |                     |        |       |
  |                   |                     |        |       |
  | Upload Firmware   |                     |        |       |
  |------------------&gt;|                     |        |       |
  |                   |                     |        |       |
  | Create Manifest   |                     |        |       |
  |---------------+   |                     |        |       |
  |               |   |                     |        |       |
  |&lt;--------------+   |                     |        |       |
  |                   |                     |        |       |
  | Sign Manifest     |                     |        |       |
  |-------------+     |                     |        |       |
  |             |     |                     |        |       |
  |&lt;------------+     |                     |        |       |
  |                   |                     |        |       |
  | Upload Manifest   |                     |        |       |
  |------------------&gt;|  Notification of    |        |       |
  |                   |  new firmware image |        |       |
  |                   |-----------------------------&gt;|       |
  |                   |                     |        |       |
  |                   |                     |Initiate|       |
  |                   |                     | Update |       |
  |                   |                     |&lt;-------|       |
  |                   |                     |        |       |
  |                   |   Query Manifest    |        |       |
  |                   |&lt;--------------------|        .       |
  |                   |                     |        .       |
  |                   |   Send Manifest     |        .       |
  |                   |--------------------&gt;|        .       |
  |                   |                     | Validate       |
  |                   |                     | Manifest       |
  |                   |                     |--------+       |
  |                   |                     |        |       |
  |                   |                     |&lt;-------+       |
  |                   |                     |        .       |
  |                   |  Request Firmware   |        .       |
  |                   |&lt;--------------------|        .       |
  |                   |                     |        .       |
  |                   | Send Firmware       |        .       |
  |                   |--------------------&gt;|        .       |
  |                   |                     | Verify .       |
  |                   |                     | Firmware       |
  |                   |                     |--------+       |
  |                   |                     |        |       |
  |                   |                     |&lt;-------+       |
  |                   |                     |        .       |
  |                   |                     | Store  .       |
  |                   |                     | Firmware       |
  |                   |                     |--------+       |
  |                   |                     |        |       |
  |                   |                     |&lt;-------+       |
  |                   |                     |        .       |
  |                   |                     |        .       |
  |                   |                     |        .       |
  |                   |                     |        |       |
  |                   |                     | Update |       |
  |                   |                     |Complete|       |
  |                   |                     |-------&gt;|       |
  |                   |                              |       |
  |                   |  Firmware Update Completed   |       |
  |                   |&lt;-----------------------------|       |
  |                   |                              |       |
  |                   |  Reboot                      |       |
  |                   |-----------------------------&gt;|       |
  |                   |                     |        |       |
  |                   |                     |        |       |
  |                   |                     |        |Reboot |
  |                   |                     |        |------&gt;|
  |                   |                     |        |       |
  |                   |                     |        .       |
  |                   |                 +---+----------------+--+
  |                   |                S|   |                |  |
  |                   |                E|   | Verify         |  |
  |                   |                C|   | Firmware       |  |
  |                   |                U|   | +--------------|  |
  |                   |                R|   | |              |  |
  |                   |                E|   | +-------------&gt;|  |
  |                   |                 |   |                |  |
  |                   |                B|   | Activate new   |  |
  |                   |                O|   | Firmware       |  |
  |                   |                O|   | +--------------|  |
  |                   |                T|   | |              |  |
  |                   |                 |   | +-------------&gt;|  |
  |                   |                P|   |                |  |
  |                   |                R|   | Boot new       |  |
  |                   |                O|   | Firmware       |  |
  |                   |                C|   | +--------------|  |
  |                   |                E|   | |              |  |
  |                   |                S|   | +-------------&gt;|  |
  |                   |                S|   |                |  |
  |                   |                 +---+----------------+--+
  |                   |                     |        .       |
  |                   |                     |        |       |
  |                   |                     .        |       |
  |                   |  Device running new firmware |       |
  |                   |&lt;-----------------------------|       |
  |                   |                     .        |       |
  |                   |                              |       |
</pre>
</div>
<figcaption><a href="#figure-2" class="selfRef">Figure 2</a>:
<a href="#name-first-example-flow-for-a-fi" class="selfRef">First Example Flow for a Firmware Update</a>
        </figcaption></figure>
</div>
<p id="section-8-3"><a href="#firmware-update2" class="xref">Figure 3</a> shows an exchange that starts with the
status tracker querying the device for its current firmware version.
Later, a new firmware version becomes available, and since this
device is running an older version, the status tracker server interacts
with the device to initiate an update.<a href="#section-8-3" class="pilcrow">¶</a></p>
<p id="section-8-4">The manifest and the firmware are stored on different servers in this
example. When the device processes the manifest, it learns where to
download the new firmware version. The firmware consumer downloads
the firmware image with the newer version X.Y.Z after successful validation
of the manifest. Subsequently, a reboot is initiated, and the secure
boot process starts. Finally, the device reports the successful boot
of the new firmware version.<a href="#section-8-4" class="pilcrow">¶</a></p>
<span id="name-second-example-flow-for-a-f"></span><div id="firmware-update2">
<figure id="figure-3">
        <div class="artwork art-text alignCenter" id="section-8-5.1">
<pre>
 +---------+   +-----------------+    +-----------------------------+
 | Status  |   | Firmware Server |    | +------------+ +----------+ |
 | Tracker |   | Status Tracker  |    | |  Firmware  | |Bootloader| |
 | Server  |   | Server          |    | |  Consumer  | |          | |
 +---------+   +-----------------+    | |  +Status   | +----------+ |
      |                |              | |  Tracker   |        |     |
      |                |              | |  Client    |        |     |
      |                |              | +------------+        |     |
      |                |              |      |  IoT Device    |     |
      |                |               `''''''''''''''''''''''''''''
      |                |                     |                |
      |        Query Firmware Version        |                |
      |-------------------------------------&gt;|                |
      |        Firmware Version A.B.C        |                |
      |&lt;-------------------------------------|                |
      |                |                     |                |
      |         &lt;&lt;some time later&gt;&gt;          |                |
      |                |                     |                |
    _,...._         _,...._                  |                |
  ,'       `.     ,'       `.                |                |
 |   New     |   |   New     |               |                |
 \ Manifest  /   \ Firmware  /               |                |
  `.._   _,,'     `.._   _,,'                |                |
      `''             `''                    |                |
      |            Push manifest             |                |
      |----------------+--------------------&gt;|                |
      |                |                     |                |
      |                '                     |                '
      |                |                     | Validate       |
      |                |                     | Manifest       |
      |                |                     |---------+      |
      |                |                     |         |      |
      |                |                     |&lt;--------+      |
      |                | Request firmware    |                |
      |                | X.Y.Z               |                |
      |                |&lt;--------------------|                |
      |                |                     |                |
      |                | Firmware X.Y.Z      |                |
      |                |--------------------&gt;|                |
      |                |                     |                |
      |                |                     | Verify         |
      |                |                     | Firmware       |
      |                |                     |--------------+ |
      |                |                     |              | |
      |                |                     |&lt;-------------+ |
      |                |                     |                |
      |                |                     | Store          |
      |                |                     | Firmware       |
      |                |                     |-------------+  |
      |                |                     |             |  |
      |                |                     |&lt;------------+  |
      |                |                     |                |
      |                |                     |                |
      |                |                     | Trigger Reboot |
      |                |                     |---------------&gt;|
      |                |                     |                |
      |                |                     |                |
      |                |                     | __..-------..._'
      |                |                    ,-'               `-.
      |                |                   |      Secure Boot    |
      |                |                   `-.                 _/
      |                |                     |`--..._____,,.,-'
      |                |                     |                |
      | Device running firmware X.Y.Z        |                |
      |&lt;-------------------------------------|                |
      |                |                     |                |
      |                |                     |                |
</pre>
</div>
<figcaption><a href="#figure-3" class="selfRef">Figure 3</a>:
<a href="#name-second-example-flow-for-a-f" class="selfRef">Second Example Flow for a Firmware Update</a>
        </figcaption></figure>
</div>
</section>
</div>
<div id="iana-considerations">
<section id="section-9">
      <h2 id="name-iana-considerations">
<a href="#section-9" class="section-number selfRef">9. </a><a href="#name-iana-considerations" class="section-name selfRef">IANA Considerations</a>
      </h2>
<p id="section-9-1">This document has no IANA actions.<a href="#section-9-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="security-considerations">
<section id="section-10">
      <h2 id="name-security-considerations">
<a href="#section-10" class="section-number selfRef">10. </a><a href="#name-security-considerations" class="section-name selfRef">Security Considerations</a>
      </h2>
<p id="section-10-1">This document describes the terminology, requirements, and an architecture for
firmware updates of IoT devices. The content of the document is thereby
focused on improving the security of IoT devices via firmware update mechanisms
and informs the standardization of a manifest format.<a href="#section-10-1" class="pilcrow">¶</a></p>
<p id="section-10-2">An in-depth examination of the security considerations of the
architecture is presented in <span>[<a href="#I-D.ietf-suit-information-model" class="xref">SUIT-INFO-MODEL</a>]</span>.<a href="#section-10-2" class="pilcrow">¶</a></p>
</section>
</div>
<section id="section-11">
      <h2 id="name-informative-references">
<a href="#section-11" class="section-number selfRef">11. </a><a href="#name-informative-references" class="section-name selfRef">Informative References</a>
      </h2>
<dl class="references">
<dt id="LwM2M">[LwM2M]</dt>
      <dd>
<span class="refAuthor">Open Mobile Alliance</span>, <span class="refTitle">"Lightweight Machine to Machine Technical Specification"</span>, <span class="seriesInfo">Version 1.0.2</span>, <time datetime="2018-02" class="refDate">February 2018</time>, <span>&lt;<a href="http://www.openmobilealliance.org/release/LightweightM2M/V1_0_2-20180209-A/OMA-TS-LightweightM2M-V1_0_2-20180209-A.pdf">http://www.openmobilealliance.org/release/LightweightM2M/V1_0_2-20180209-A/OMA-TS-LightweightM2M-V1_0_2-20180209-A.pdf</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="quantum-factorization">[quantum-factorization]</dt>
      <dd>
<span class="refAuthor">Jiang, S.</span>, <span class="refAuthor">Britt, K.A.</span>, <span class="refAuthor">McCaskey, A.J.</span>, <span class="refAuthor">Humble, T.S.</span>, and <span class="refAuthor">S. Kais</span>, <span class="refTitle">"Quantum Annealing for Prime Factorization"</span>, <span class="seriesInfo">Scientific Reports 8</span>, <time datetime="2018-12" class="refDate">December 2018</time>, <span>&lt;<a href="https://www.nature.com/articles/s41598-018-36058-z">https://www.nature.com/articles/s41598-018-36058-z</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="I-D.ietf-rats-architecture">[RATS-ARCH]</dt>
      <dd>
<span class="refAuthor">Birkholz, H.</span>, <span class="refAuthor">Thaler, D.</span>, <span class="refAuthor">Richardson, M.</span>, <span class="refAuthor">Smith, N.</span>, and <span class="refAuthor">W. Pan</span>, <span class="refTitle">"Remote Attestation Procedures Architecture"</span>, <span class="refContent">Work in Progress</span>, <span class="seriesInfo">Internet-Draft, draft-ietf-rats-architecture-12</span>, <time datetime="2021-04-23" class="refDate">23 April 2021</time>, <span>&lt;<a href="https://tools.ietf.org/html/draft-ietf-rats-architecture-12">https://tools.ietf.org/html/draft-ietf-rats-architecture-12</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC6024">[RFC6024]</dt>
      <dd>
<span class="refAuthor">Reddy, R.</span> and <span class="refAuthor">C. Wallace</span>, <span class="refTitle">"Trust Anchor Management Requirements"</span>, <span class="seriesInfo">RFC 6024</span>, <span class="seriesInfo">DOI 10.17487/RFC6024</span>, <time datetime="2010-10" class="refDate">October 2010</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc6024">https://www.rfc-editor.org/info/rfc6024</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC6763">[RFC6763]</dt>
      <dd>
<span class="refAuthor">Cheshire, S.</span> and <span class="refAuthor">M. Krochmal</span>, <span class="refTitle">"DNS-Based Service Discovery"</span>, <span class="seriesInfo">RFC 6763</span>, <span class="seriesInfo">DOI 10.17487/RFC6763</span>, <time datetime="2013-02" class="refDate">February 2013</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc6763">https://www.rfc-editor.org/info/rfc6763</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC7228">[RFC7228]</dt>
      <dd>
<span class="refAuthor">Bormann, C.</span>, <span class="refAuthor">Ersue, M.</span>, and <span class="refAuthor">A. Keranen</span>, <span class="refTitle">"Terminology for Constrained-Node Networks"</span>, <span class="seriesInfo">RFC 7228</span>, <span class="seriesInfo">DOI 10.17487/RFC7228</span>, <time datetime="2014-05" class="refDate">May 2014</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7228">https://www.rfc-editor.org/info/rfc7228</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8240">[RFC8240]</dt>
      <dd>
<span class="refAuthor">Tschofenig, H.</span> and <span class="refAuthor">S. Farrell</span>, <span class="refTitle">"Report from the Internet of Things Software Update (IoTSU) Workshop 2016"</span>, <span class="seriesInfo">RFC 8240</span>, <span class="seriesInfo">DOI 10.17487/RFC8240</span>, <time datetime="2017-09" class="refDate">September 2017</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8240">https://www.rfc-editor.org/info/rfc8240</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8778">[RFC8778]</dt>
      <dd>
<span class="refAuthor">Housley, R.</span>, <span class="refTitle">"Use of the HSS/LMS Hash-Based Signature Algorithm with CBOR Object Signing and Encryption (COSE)"</span>, <span class="seriesInfo">RFC 8778</span>, <span class="seriesInfo">DOI 10.17487/RFC8778</span>, <time datetime="2020-04" class="refDate">April 2020</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8778">https://www.rfc-editor.org/info/rfc8778</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="I-D.ietf-suit-information-model">[SUIT-INFO-MODEL]</dt>
      <dd>
<span class="refAuthor">Moran, B.</span>, <span class="refAuthor">Tschofenig, H.</span>, and <span class="refAuthor">H. Birkholz</span>, <span class="refTitle">"A Manifest Information Model for Firmware Updates in IoT Devices"</span>, <span class="refContent">Work in Progress</span>, <span class="seriesInfo">Internet-Draft, draft-ietf-suit-information-model-11</span>, <time datetime="2021-04-06" class="refDate">6 April 2021</time>, <span>&lt;<a href="https://tools.ietf.org/html/draft-ietf-suit-information-model-11">https://tools.ietf.org/html/draft-ietf-suit-information-model-11</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="I-D.ietf-suit-manifest">[SUIT-MANIFEST]</dt>
      <dd>
<span class="refAuthor">Moran, B.</span>, <span class="refAuthor">Tschofenig, H.</span>, <span class="refAuthor">Birkholz, H.</span>, and <span class="refAuthor">K. Zandberg</span>, <span class="refTitle">"A Concise Binary Object Representation (CBOR)-based Serialization Format for the Software Updates for Internet of Things (SUIT) Manifest"</span>, <span class="refContent">Work in Progress</span>, <span class="seriesInfo">Internet-Draft, draft-ietf-suit-manifest-12</span>, <time datetime="2021-02-22" class="refDate">22 February 2021</time>, <span>&lt;<a href="https://tools.ietf.org/html/draft-ietf-suit-manifest-12">https://tools.ietf.org/html/draft-ietf-suit-manifest-12</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="I-D.ietf-teep-architecture">[TEEP-ARCH]</dt>
    <dd>
<span class="refAuthor">Pei, M.</span>, <span class="refAuthor">Tschofenig, H.</span>, <span class="refAuthor">Thaler, D.</span>, and <span class="refAuthor">D. Wheeler</span>, <span class="refTitle">"Trusted Execution Environment Provisioning (TEEP) Architecture"</span>, <span class="refContent">Work in Progress</span>, <span class="seriesInfo">Internet-Draft, draft-ietf-teep-architecture-14</span>, <time datetime="2021-02-22" class="refDate">22 February 2021</time>, <span>&lt;<a href="https://tools.ietf.org/html/draft-ietf-teep-architecture-14">https://tools.ietf.org/html/draft-ietf-teep-architecture-14</a>&gt;</span>. </dd>
<dd class="break"></dd>
</dl>
</section>
<div id="acknowledgements">
<section id="section-appendix.a">
      <h2 id="name-acknowledgements">
<a href="#name-acknowledgements" class="section-name selfRef">Acknowledgements</a>
      </h2>
<p id="section-appendix.a-1">We would like to thank the following individuals for their feedback:<a href="#section-appendix.a-1" class="pilcrow">¶</a></p>
<ul class="compact">
<li class="compact" id="section-appendix.a-2.1">
          <p id="section-appendix.a-2.1.1"><span class="contact-name">Geraint Luff</span><a href="#section-appendix.a-2.1.1" class="pilcrow">¶</a></p>
</li>
        <li class="compact" id="section-appendix.a-2.2">
          <p id="section-appendix.a-2.2.1"><span class="contact-name">Amyas Phillips</span><a href="#section-appendix.a-2.2.1" class="pilcrow">¶</a></p>
</li>
        <li class="compact" id="section-appendix.a-2.3">
          <p id="section-appendix.a-2.3.1"><span class="contact-name">Dan Ros</span><a href="#section-appendix.a-2.3.1" class="pilcrow">¶</a></p>
</li>
        <li class="compact" id="section-appendix.a-2.4">
          <p id="section-appendix.a-2.4.1"><span class="contact-name">Thomas Eichinger</span><a href="#section-appendix.a-2.4.1" class="pilcrow">¶</a></p>
</li>
        <li class="compact" id="section-appendix.a-2.5">
          <p id="section-appendix.a-2.5.1"><span class="contact-name">Michael Richardson</span><a href="#section-appendix.a-2.5.1" class="pilcrow">¶</a></p>
</li>
        <li class="compact" id="section-appendix.a-2.6">
          <p id="section-appendix.a-2.6.1"><span class="contact-name">Emmanuel Baccelli</span><a href="#section-appendix.a-2.6.1" class="pilcrow">¶</a></p>
</li>
        <li class="compact" id="section-appendix.a-2.7">
          <p id="section-appendix.a-2.7.1"><span class="contact-name">Ned Smith</span><a href="#section-appendix.a-2.7.1" class="pilcrow">¶</a></p>
</li>
        <li class="compact" id="section-appendix.a-2.8">
          <p id="section-appendix.a-2.8.1"><span class="contact-name">Jim Schaad</span><a href="#section-appendix.a-2.8.1" class="pilcrow">¶</a></p>
</li>
        <li class="compact" id="section-appendix.a-2.9">
          <p id="section-appendix.a-2.9.1"><span class="contact-name">Carsten Bormann</span><a href="#section-appendix.a-2.9.1" class="pilcrow">¶</a></p>
</li>
        <li class="compact" id="section-appendix.a-2.10">
          <p id="section-appendix.a-2.10.1"><span class="contact-name">Cullen Jennings</span><a href="#section-appendix.a-2.10.1" class="pilcrow">¶</a></p>
</li>
        <li class="compact" id="section-appendix.a-2.11">
          <p id="section-appendix.a-2.11.1"><span class="contact-name">Olaf Bergmann</span><a href="#section-appendix.a-2.11.1" class="pilcrow">¶</a></p>
</li>
        <li class="compact" id="section-appendix.a-2.12">
          <p id="section-appendix.a-2.12.1"><span class="contact-name">Suhas Nandakumar</span><a href="#section-appendix.a-2.12.1" class="pilcrow">¶</a></p>
</li>
        <li class="compact" id="section-appendix.a-2.13">
          <p id="section-appendix.a-2.13.1"><span class="contact-name">Phillip Hallam-Baker</span><a href="#section-appendix.a-2.13.1" class="pilcrow">¶</a></p>
</li>
        <li class="compact" id="section-appendix.a-2.14">
          <p id="section-appendix.a-2.14.1"><span class="contact-name">Marti Bolivar</span><a href="#section-appendix.a-2.14.1" class="pilcrow">¶</a></p>
</li>
        <li class="compact" id="section-appendix.a-2.15">
          <p id="section-appendix.a-2.15.1"><span class="contact-name">Andrzej Puzdrowski</span><a href="#section-appendix.a-2.15.1" class="pilcrow">¶</a></p>
</li>
        <li class="compact" id="section-appendix.a-2.16">
          <p id="section-appendix.a-2.16.1"><span class="contact-name">Markus Gueller</span><a href="#section-appendix.a-2.16.1" class="pilcrow">¶</a></p>
</li>
        <li class="compact" id="section-appendix.a-2.17">
          <p id="section-appendix.a-2.17.1"><span class="contact-name">Henk Birkholz</span><a href="#section-appendix.a-2.17.1" class="pilcrow">¶</a></p>
</li>
        <li class="compact" id="section-appendix.a-2.18">
          <p id="section-appendix.a-2.18.1"><span class="contact-name">Jintao Zhu</span><a href="#section-appendix.a-2.18.1" class="pilcrow">¶</a></p>
</li>
        <li class="compact" id="section-appendix.a-2.19">
          <p id="section-appendix.a-2.19.1"><span class="contact-name">Takeshi Takahashi</span><a href="#section-appendix.a-2.19.1" class="pilcrow">¶</a></p>
</li>
        <li class="compact" id="section-appendix.a-2.20">
          <p id="section-appendix.a-2.20.1"><span class="contact-name">Jacob Beningo</span><a href="#section-appendix.a-2.20.1" class="pilcrow">¶</a></p>
</li>
        <li class="compact" id="section-appendix.a-2.21">
          <p id="section-appendix.a-2.21.1"><span class="contact-name">Kathleen Moriarty</span><a href="#section-appendix.a-2.21.1" class="pilcrow">¶</a></p>
</li>
        <li class="compact" id="section-appendix.a-2.22">
          <p id="section-appendix.a-2.22.1"><span class="contact-name">Bob Briscoe</span><a href="#section-appendix.a-2.22.1" class="pilcrow">¶</a></p>
</li>
        <li class="compact" id="section-appendix.a-2.23">
          <p id="section-appendix.a-2.23.1"><span class="contact-name">Roman Danyliw</span><a href="#section-appendix.a-2.23.1" class="pilcrow">¶</a></p>
</li>
        <li class="compact" id="section-appendix.a-2.24">
          <p id="section-appendix.a-2.24.1"><span class="contact-name">Brian Carpenter</span><a href="#section-appendix.a-2.24.1" class="pilcrow">¶</a></p>
</li>
        <li class="compact" id="section-appendix.a-2.25">
          <p id="section-appendix.a-2.25.1"><span class="contact-name">Theresa Enghardt</span><a href="#section-appendix.a-2.25.1" class="pilcrow">¶</a></p>
</li>
        <li class="compact" id="section-appendix.a-2.26">
          <p id="section-appendix.a-2.26.1"><span class="contact-name">Rich Salz</span><a href="#section-appendix.a-2.26.1" class="pilcrow">¶</a></p>
</li>
        <li class="compact" id="section-appendix.a-2.27">
          <p id="section-appendix.a-2.27.1"><span class="contact-name">Mohit Sethi</span><a href="#section-appendix.a-2.27.1" class="pilcrow">¶</a></p>
</li>
        <li class="compact" id="section-appendix.a-2.28">
          <p id="section-appendix.a-2.28.1"><span class="contact-name">Éric Vyncke</span><a href="#section-appendix.a-2.28.1" class="pilcrow">¶</a></p>
</li>
        <li class="compact" id="section-appendix.a-2.29">
          <p id="section-appendix.a-2.29.1"><span class="contact-name">Alvaro Retana</span><a href="#section-appendix.a-2.29.1" class="pilcrow">¶</a></p>
</li>
        <li class="compact" id="section-appendix.a-2.30">
          <p id="section-appendix.a-2.30.1"><span class="contact-name">Barry Leiba</span><a href="#section-appendix.a-2.30.1" class="pilcrow">¶</a></p>
</li>
        <li class="compact" id="section-appendix.a-2.31">
          <p id="section-appendix.a-2.31.1"><span class="contact-name">Benjamin Kaduk</span><a href="#section-appendix.a-2.31.1" class="pilcrow">¶</a></p>
</li>
        <li class="compact" id="section-appendix.a-2.32">
          <p id="section-appendix.a-2.32.1"><span class="contact-name">Martin Duke</span><a href="#section-appendix.a-2.32.1" class="pilcrow">¶</a></p>
</li>
        <li class="compact" id="section-appendix.a-2.33">
          <p id="section-appendix.a-2.33.1"><span class="contact-name">Robert Wilton</span><a href="#section-appendix.a-2.33.1" class="pilcrow">¶</a></p>
</li>
      </ul>
<p id="section-appendix.a-3">We would also like to thank the WG chairs, <span class="contact-name">Russ Housley</span>, <span class="contact-name">David Waltermire</span>, and <span class="contact-name">Dave Thaler</span> for their support and review.<a href="#section-appendix.a-3" class="pilcrow">¶</a></p>
</section>
</div>
<div id="authors-addresses">
<section id="section-appendix.b">
      <h2 id="name-authors-addresses">
<a href="#name-authors-addresses" class="section-name selfRef">Authors' Addresses</a>
      </h2>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Brendan Moran</span></div>
<div dir="auto" class="left"><span class="org">Arm Limited</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:Brendan.Moran@arm.com" class="email">Brendan.Moran@arm.com</a>
</div>
</address>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Hannes Tschofenig</span></div>
<div dir="auto" class="left"><span class="org">Arm Limited</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:hannes.tschofenig@arm.com" class="email">hannes.tschofenig@arm.com</a>
</div>
</address>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">David Brown</span></div>
<div dir="auto" class="left"><span class="org">Linaro</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:david.brown@linaro.org" class="email">david.brown@linaro.org</a>
</div>
</address>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Milosch Meriac</span></div>
<div dir="auto" class="left"><span class="org">Consultant</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:milosch@meriac.com" class="email">milosch@meriac.com</a>
</div>
</address>
</section>
</div>
<script>const toc = document.getElementById("toc");
toc.querySelector("h2").addEventListener("click", e => {
  toc.classList.toggle("active");
});
toc.querySelector("nav").addEventListener("click", e => {
  toc.classList.remove("active");
});
</script>
</body>
</html>