rfc9019xml2.original.xml   rfc9019.xml 
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc2629 version 1.3.24 -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
]>
<?rfc rfcedstyle="yes"?>
<?rfc toc="yes"?>
<?rfc tocindent="yes"?>
<?rfc sortrefs="yes"?>
<?rfc symrefs="yes"?>
<?rfc strict="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc text-list-symbols="-o*+"?>
<?rfc docmapping="yes"?>
<rfc ipr="trust200902" docName="draft-ietf-suit-architecture-16" category="info"
>
<front>
<title abbrev="A Firmware Update Architecture for IoT">A Firmware Update Arc
hitecture for Internet of Things</title>
<author initials="B." surname="Moran" fullname="Brendan Moran">
<organization>Arm Limited</organization>
<address>
<email>Brendan.Moran@arm.com</email>
</address>
</author>
<author initials="H." surname="Tschofenig" fullname="Hannes Tschofenig">
<organization>Arm Limited</organization>
<address>
<email>hannes.tschofenig@arm.com</email>
</address>
</author>
<author initials="D." surname="Brown" fullname="David Brown">
<organization>Linaro</organization>
<address>
<email>david.brown@linaro.org</email>
</address>
</author>
<author initials="M." surname="Meriac" fullname="Milosch Meriac">
<organization>Consultant</organization>
<address>
<email>milosch@meriac.com</email>
</address>
</author>
<date year="2021" month="January" day="27"/>
<area>Security</area>
<workgroup>SUIT</workgroup>
<keyword>Internet-Draft</keyword>
<abstract>
<t>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
as well as adding new functionality.</t>
<t>In addition to the definition of terminology and an architecture
this document motivates the standardization of a manifest format
as a transport-agnostic means for describing and protecting firmware
updates.</t>
</abstract>
</front>
<middle>
<section anchor="introduction" title="Introduction">
<t>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 a ‘Workshop on Internet of Things
(IoT) Software Update (IOTSU)’ <xref target="RFC8240"/> 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.</t>
<t>Developing secure Internet of Things (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 lifecycle 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<vspace
/>
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.</t>
<t>Firmware updates are done not only to fix bugs, but also to add new functiona <!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
lity and to reconfigure
the device to work in new environments or to behave differently in
an already deployed context.</t>
<t>The manifest specification has to allow that</t>
<t><list style="symbols">
<t>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. In examples this document
uses asymmetric cryptography 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.</t>
<t>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 on
e of
the first steps to mount 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.</t>
</list></t>
<t>Authentication and integrity protection of firmware images must be used in a
deployment
but the confidential protection of firmware is optional.</t>
<t>While the standardization work has been informed by and optimized for firmwar
e
update use cases of Class 1 devices (according to the device class
definitions in RFC 7228 <xref target="RFC7228"/>), 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 upd
ates,
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;
and support for unattended updates is, therefore, 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
to the developers of the lower level software. The details for how to obtain
those application layer software binaries then depends heavily on the platform,
programming language used and the sandbox in which the software is executed.</t>
<t>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 pre-configured hostnames
or DNS-SD <xref target="RFC6763"/>.
These building blocks have been developed by various organizations
under the umbrella of an IoT device management solution. The LwM2M protocol <xre
f target="LwM2M"/> is one
IoT device management protocol.</t>
<t>There are, however, 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 d
uring
the IOTSU workshop:</t>
<t><list style="symbols">
<t>Installing firmware updates in a robust fashion so that the
update does not break the device functionality of the environment
this device operates in. This requires proper testing and offering
recovery strategies when a firmware update is unsuccessful.</t>
<t>Making firmware updates available in a timely fashion considering the
complexity of the decision making process for updating devices,
potential re-certification 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.</t>
<t>Ensuring an energy efficient design of a battery-powered IoT device because
a
firmware update, particularly radio communication and writing the firmware image
to flash, is an energy-intensive task for a device.</t>
<t>Creating incentives for device operators to use a firmware update mechanism
and to
demand the integration of it from IoT device vendors.</t>
<t>Ensuring that firmware updates addressing critical flaws can be
obtained even after a product is discontinued or a vendor goes out of
business.</t>
</list></t>
<t>This document starts with a terminology followed by the description of the ar
chitecture.
We then explain the bootloader and how it integrates with the firmware update me
chanism.
Subsequently, we offer a categorization of IoT devices in terms of their hardwar
e
capabilities relevant for firmware updates. Next, we talk about the manifest str
ucture
and how to use it to secure firmware updates. We conclude with a more detailed e
xample.</t>
</section>
<section anchor="terminology" title="Conventions and Terminology">
<section anchor="terms" title="Terms">
<t>This document uses the following terms:</t>
<t><list style="symbols">
<t>Firmware Image: 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. <vspace blankLines='1'/>
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
embedded operating system).</t>
<t>Manifest: The manifest contains meta-data about the firmware
image. The manifest is protected against modification and
provides information about the author.</t>
<t>Microcontroller (MCU for microcontroller unit): An 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.</t>
<t>Rich Execution Environment (REE): 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 TEE. This environment and
applications running on it are considered un-trusted.</t>
<t>Software: Similar to firmware, but typically dynamically loaded by an
Operating System. Used interchangeably with firmware in this document.</t>
<t>System on Chip (SoC): An SoC is an integrated circuit that
contains all components of a computer, such as CPU, memory,
input/output ports, secondary storage, a bus to connect the
components, and other hardware blocks of logic.</t>
<t>Trust Anchor: A trust anchor, as defined in <xref target="RFC6024"/>, repre
sents
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.</t>
<t>Trust Anchor Store: A trust anchor store, as defined in <xref target="RFC60
24"/>,
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.</t>
<t>Trusted Applications (TAs): An application component that runs in
a TEE.</t>
<t>Trusted Execution Environments (TEEs): An execution environment
that runs alongside of, but is isolated from, an REE. For more
information about TEEs see <xref target="I-D.ietf-teep-architecture"/>.</t>
</list></t>
</section> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draf
<section anchor="stakeholders" title="Stakeholders"> t-ietf-suit-architecture-16" number="9019" obsoletes="" updates="" submissionTyp
e="IETF" category="info" consensus="true" xml:lang="en" tocInclude="true"
sortRefs="true" symRefs="true" version="3">
<t>The following stakeholders are used in this document:</t> <front>
<title abbrev="IoT Firmware Update Architecture">A Firmware Update Architec
ture for Internet of Things</title>
<seriesInfo name="RFC" value="9019"/>
<author initials="B." surname="Moran" fullname="Brendan Moran">
<organization>Arm Limited</organization>
<address>
<email>Brendan.Moran@arm.com</email>
</address>
</author>
<author initials="H." surname="Tschofenig" fullname="Hannes Tschofenig">
<organization>Arm Limited</organization>
<address>
<email>hannes.tschofenig@arm.com</email>
</address>
</author>
<author initials="D." surname="Brown" fullname="David Brown">
<organization>Linaro</organization>
<address>
<email>david.brown@linaro.org</email>
</address>
</author>
<author initials="M." surname="Meriac" fullname="Milosch Meriac">
<organization>Consultant</organization>
<address>
<email>milosch@meriac.com</email>
</address>
</author>
<date year="2021" month="April"/>
<area>Security</area>
<workgroup>SUIT</workgroup>
<t><list style="symbols"> <keyword>IoT</keyword>
<t>Author: The author is the entity that creates the firmware image. <keyword>update</keyword>
There may be multiple authors involved in producing firmware running <keyword>software</keyword>
on an IoT device. <xref target="device"/> talks about those IoT device deploymen <keyword>firmware</keyword>
t cases.</t> <keyword>constrained</keyword>
<t>Device Operator: The device operator is responsible for the day-to-day oper <keyword>Secure</keyword>
ation <keyword>Boot</keyword>
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
web or smart phone apps.</t>
<t>Network Operator: The network operator is responsible for the operation of
a
network to which IoT devices connect.</t>
<t>Trust Provisioning Authority (TPA): 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.</t>
<t>User: The end-user of a device. The user may interact with devices
via web or smart phone apps, as well as through direct user interfaces.</t>
</list></t>
</section> <abstract>
<section anchor="functions" title="Functions"> <t>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.</t>
<t>In addition to the definition of terminology and an architecture,
this document provides the motivation for the standardization of a manifest for
mat
as a transport-agnostic means for describing and protecting firmware
updates.</t>
</abstract>
</front>
<middle>
<section anchor="introduction" numbered="true" toc="default">
<name>Introduction</name>
<t>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 (IoTS
U) Workshop <xref target="RFC8240" format="default"/> 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.</t>
<t>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.</t>
<t>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.</t>
<t>The manifest specification has to allow the following:</t>
<ul spacing="normal">
<li>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 b
y
many IoT deployments. The use of symmetric credentials is also supported
and can be used by very constrained IoT devices.</li>
<li>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 o
ne 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.</li>
</ul>
<t>Authentication and integrity protection of firmware images must be use
d in a deployment, but the confidential protection of firmware is optional.</t>
<t>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 <xref target="RFC7228" format="default"/>), there is no
thing in
the architecture that restricts its use to only these constrained IoT devices.
Moreover, this architecture is not limited to managing firmware and software up
dates
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; therefor
e,
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 execute
d.</t>
<t>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) <xref target="RFC6763" format="default"
/>.
These building blocks have been developed by various organizations
under the umbrella of an IoT device management solution. The Lightweight Machin
e-to-Machine (LwM2M) protocol <xref target="LwM2M" format="default"/> is one
IoT device management protocol.</t>
<t><list style="symbols"> <t>However, there are several areas that (partially) fall outside the sco
<t>(IoT) Device: A device refers to the entire IoT product, which pe of the IETF
consists of one or many MCUs, sensors and/or actuators. Many IoT and other standards organizations but need to be considered by firmware authors
devices sold today contain multiple MCUs and therefore a single as well as device and network operators. Here are some of them, as highlighted
device may need to obtain more than one firmware image and during
manifest to successfully perform an update.</t> the IoTSU workshop:</t>
<t>Status Tracker: The status tracker has a client and a server component <ul spacing="normal">
and performs three tasks: <li>Installing firmware updates in a robust fashion so that the
1) It communicates the availability of a new firmware version. This update does not break the device functionality of the environment
information will flow from the server to the client. <vspace /> in which this device operates. This requires proper testing and offering of rec
2) It conveys information about software and hardware characteristics of overy strategies when a firmware update is unsuccessful.</li>
the device. The information flow is from the client to the server. <vspace /> <li>Making firmware updates available in a timely fashion considering th
3) It can remotely trigger the firmware update process. The e
information flow is from the server to the client. <vspace blankLines='1'/> complexity of the decision-making process for updating devices,
For example, a device operator may want to read the installed firmware potential recertification requirements, the length of a supply chain
version number running on the device and information an update needs to go through before it reaches the end customer,
about available flash memory. Once an update has been triggered, the device and the need for user consent to install updates.</li>
operator may want to obtain information about the state of the firmware <li>Ensuring an energy-efficient design of a battery-powered IoT device;
update. If errors occurred, the device operator may want to a
troubleshoot problems by first obtaining diagnostic information (typically firmware update, particularly radio communication and writing the firmware imag
using a device management protocol). <vspace blankLines='1'/> e
We make no to flash, is an energy-intensive task for a device.</li>
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 c
omponent 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. <vspace blankLines='1'/>
The status tracker may be operated by any suitable stakeholder;
typically the Author, Device Operator, or Network Operator.</t>
<t>Firmware Consumer: 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
with the status tracker client (locally).</t>
<t>Firmware Server: 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/manifests on more than one entity before<vspace />
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.</t>
<t>Bootloader: 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.</t>
</list></t>
</section> <li>Creating incentives for device operators to use a firmware update me
</section> chanism and to
<section anchor="architecture" title="Architecture"> require its integration from IoT device vendors.</li>
<li>Ensuring that firmware updates addressing critical flaws can be
obtained even after a product is discontinued or a vendor goes out of
business.</li>
</ul>
<t>More devices today than ever before are connected to the Internet, <t>This document starts with a terminology list followed by a description
which drives the need for firmware updates to be provided over the of the architecture.
Internet rather than through traditional interfaces, such as USB or We then explain the bootloader and how it integrates with the firmware update m
RS-232. Sending updates over the Internet requires the device to fetch echanism.
the new firmware image as well as the manifest.</t> Subsequently, we offer a categorization of IoT devices in terms of their hardwa
re
capabilities relevant for firmware updates. Next, we talk about the manifest st
ructure
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.</t>
</section>
<section anchor="terminology" numbered="true" toc="default">
<name>Conventions and Terminology</name>
<section anchor="terms" numbered="true" toc="default">
<name>Terms</name>
<t>This document uses the following terms:</t>
<dl newline="true">
<dt>Firmware Image:</dt><dd><t>The firmware image, or simply the "im
age", 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. </t>
<t>
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)).</t></dd>
<dt>Manifest:</dt><dd>The manifest contains metadata about the firmwar
e
image. The manifest is protected against modification and
provides information about the author.</dd>
<t>Hence, the following components are necessary on a device for a firmware <dt>Microcontroller:</dt><dd>A microcontroller unit (MCU) is a
update solution:</t> 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.</dd>
<dt>Rich Execution Environment (REE):</dt><dd> 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). Thi
s environment and the applications running on it are considered untrusted.</dd>
<dt>Software:</dt><dd> Similar to firmware but typically dynamically l
oaded by an
OS. Used interchangeably with firmware in this document.</dd>
<dt>System on Chip (SoC):</dt><dd> An SoC is an integrated circuit tha
t
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.</dd>
<dt>Trust Anchor:</dt><dd> A trust anchor, as defined in RFC 6024 <xre
f target="RFC6024" format="default"/>, 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.</dd>
<dt>Trust Anchor Store:</dt><dd> A trust anchor store, as defined in <
xref target="RFC6024" format="default"/>,
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.</dd>
<dt>Trusted Applications (TAs):</dt><dd> An application component that
runs in
a TEE.</dd>
<dt>Trusted Execution Environments (TEEs):</dt><dd>An execution enviro
nment
that runs alongside of, but is isolated from, an REE. For more
information about TEEs, see <xref target="I-D.ietf-teep-architecture" format="d
efault"/>.</dd>
</dl>
</section>
<section anchor="stakeholders" numbered="true" toc="default">
<name>Stakeholders</name>
<t>The following stakeholders are used in this document:</t>
<dl newline="true">
<dt>Author:</dt><dd>The author is the entity that creates the firmware
image.
There may be multiple authors involved in producing firmware running
on an IoT device. <xref target="device" format="default"/> talks about those Io
T device deployment cases.</dd>
<dt>Device Operator:</dt><dd> The device operator is responsible for t
he 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.</dd>
<dt>Network Operator:</dt><dd> The network operator is responsible for
the operation of a
network to which IoT devices connect.</dd>
<dt>Trust Provisioning Authority (TPA):</dt><dd>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.</dd>
<dt>User:</dt><dd>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.</dd>
</dl>
</section>
<section anchor="functions" numbered="true" toc="default">
<name>Functions</name>
<dl newline="true">
<dt>(IoT) Device:</dt><dd> 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.</dd>
<t><list style="symbols"> <dt>Status Tracker:</dt><dd><t>The status tracker has a client and a
<t>the Internet protocol stack for firmware downloads. Because firmware images server component
are often multiple kilobytes, sometimes and performs three tasks:</t>
exceeding one hundred kilobytes, for low-end IoT devices and even <ol type="1">
several megabytes for IoT devices running full-fledged operating systems <li>It communicates the availability of a new firmware version. This
like Linux, the protocol mechanism for retrieving these images needs information will flow from the server to the client. </li>
to offer features like congestion control, flow control, fragmentation <li>It conveys information about the software and hardware character
and reassembly, and mechanisms to resume interrupted or corrupted transfers.</t> istics of
<t>the capability to write the received firmware image to the device. The information flow is from the client to the server. </li>
persistent storage (most likely flash memory).</t> <li>It can remotely trigger the firmware update process. The
<t>a manifest parser with code to verify a digital information flow is from the server to the client. </li></ol>
signature or a message authentication code.</t> <t>
<t>the ability to unpack, to decompress and/or to decrypt the For example, a device operator may want to read the installed firmware
received firmware image.</t> version number running on the device and information
<t>a status tracker.</t> about available flash memory. Once an update has been triggered, the device
</list></t> 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). </t>
<t>
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. </t>
<t>
The status tracker may be operated by any suitable stakeholder,
typically the author, device operator, or network operator.</t>
</dd>
<dt>Firmware Consumer:</dt><dd> 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).</dd>
<t>The features listed above are most likely offered by code in the application <dt>Firmware Server:</dt><dd> The firmware server stores firmware im
firmware ages and
image running manifests and distributes them to IoT devices. Some deployments
on the device rather than by the bootloader itself. Note that may require a store-and-forward concept, which requires storing
cryptographic algorithms will likely run in a trusted execution the firmware images and/or manifests on more than one entity before they reach
environment, on a separate MCU, in a hardware security module, or in a secure el the device. There is typically some interaction between the
ement firmware server and the status tracker, and these two entities are often
rather than in the same context with the application code.</t> physically separated on different devices for scalability reasons.</dd>
<dt>Bootloader:</dt><dd> 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.</dd>
</dl>
</section>
</section>
<section anchor="architecture" numbered="true" toc="default">
<name>Architecture</name>
<t>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.</t>
<t>Hence, the following components are necessary on a device for a firmwa
re
update solution:</t>
<ul spacing="normal">
<t><xref target="arch-figure"/> shows the architecture where a <li>The Internet protocol stack for firmware downloads.
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. No
te that
there may be a longer supply chain involved to pass software updates from the au
thor all
the way to the party that can then finally make a decision to deploy it with IoT
devices.</t>
<t>As a first step in the firmware update process, the status tracker Firmware images are often multiple kilobytes, sometimes
server needs to inform the status tracker client that a new firmware exceeding one hundred kilobytes, for low-end IoT devices and can even be
update is available. This can be accomplished via polling (client-initiated), several megabytes for IoT devices running full-fledged operating systems
push notifications (server-initiated), or more complex mechanisms (such as a hyb like Linux. The protocol mechanism for retrieving these images needs
rid approach):</t> to offer features like congestion control, flow control, fragmentation
and reassembly, and mechanisms to resume interrupted or corrupted transfers.</l
i>
<li>The capability to write the received firmware image to
persistent storage (most likely flash memory).</li>
<li>A manifest parser with code to verify a digital
signature or a message authentication code (MAC).</li>
<li>The ability to unpack, decompress, and/or decrypt the
received firmware image.</li>
<li>A status tracker.</li>
</ul>
<t>The features listed above are most likely provided by code in the appl
ication 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 elem
ent
rather than in the same context as the application code.</t>
<t><xref target="arch-figure" format="default"/> shows the architecture w
here 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 directl
y.
Instead, authors will make firmware images available to the device operators. N
ote that
there may be a longer supply chain involved to pass software updates from the a
uthor all
the way to the authorizing party, which can then finally make a decision to dep
loy it with IoT devices.</t>
<t>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 hy
brid approach):</t>
<ul spacing="normal">
<li>Client-initiated updates take the form of a status tracker client pr
oactively
checking (polling) for updates.</li>
<t><list style="symbols"> <li>With server-initiated updates, the server-side component of the stat
<t>Client-initiated updates take the form of a status tracker client proactive us tracker
ly
checking (polling) for updates.</t>
<t>With Server-initiated updates the server-side component of the status track
er
learns about a new firmware version and determines which devices qualify for a learns about a new firmware version and determines which devices qualify for a
firmware update. Once the relevant devices have been selected, the firmware update. Once the relevant devices have been selected, the
status tracker informs these devices and the firmware consumers obtain those status tracker informs these devices, and the firmware consumers obtain those
images and manifests. Server-initiated updates are important because they allow a quick 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 response time. Note that in this mode, the client-side status tracker needs to b e reachable by the server-side
component. This may require devices to keep reachability information on the component. This may require devices to keep reachability information on the
server-side up-to-date and state at NATs and stateful packet filtering server side up to date and the state at NATs and stateful packet filtering
firewalls alive.</t> firewalls alive.</li>
<t>Using a hybrid approach the server-side of the status tracker <li>Using a hybrid approach, the server side of the status tracker
pushes notifications of availability of an update to the client side and request pushes update availability notifications to the client side and requests that
s the firmware consumer pull the manifest and the firmware image from the
the firmware consumer to pull the manifest and the firmware image from the firmware server.</li>
firmware server.</t> </ul>
</list></t> <t>Once the device operator triggers an update via the status tracker, it
will keep
<t>Once the device operator triggers an update via the status tracker, it will k
eep
track of the update process on the device. This allows the device operator to kn ow what track of the update process on the device. This allows the device operator to kn ow what
devices have received an update and which of them are still pending an update.</ t> devices have received an update and which of them are still pending an update.</ t>
<t>Firmware images can be conveyed to devices in a variety of ways,
<t>Firmware images can be conveyed to devices in a variety of ways, including USB, Universal Asynchronous Receiver Transmitter (UART), WiFi, Blueto
including USB, UART, WiFi, BLE, low-power WAN technologies, mesh networks and ma oth Low Energy (BLE), low-power WAN technologies, mesh networks and many more.
ny more. At the application layer,
At the application layer a variety of protocols are also available: Message Queuing Telemetry Transport (
a variety of protocols are also available: MQTT, CoAP, and HTTP are the MQTT), Constrained Application Protocol (CoAP), and HTTP are the
most popular application layer protocols used by IoT devices. This architecture most popular application-layer protocols used by IoT devices. This architecture
does not make assumptions about how the firmware images are distributed to the does not make assumptions about how the firmware images are distributed to the
devices and therefore aims to support all these technologies.</t> devices and therefore aims to support all these technologies.</t>
<t>In some cases, it may be desirable to distribute firmware images using
<t>In some cases it may be desirable to distribute firmware images using a multi a multicast
cast
or broadcast protocol. This architecture does not make recommendations for any or broadcast protocol. This architecture does not make recommendations for any
such protocol. However, given that broadcast may be desirable for some networks, such protocol. However, given that broadcast may be desirable for some networks,
updates must cause the least disruption possible both in metadata updates must cause the least disruption possible both in the metadata
and firmware transmission. For an update to be broadcast friendly, it cannot rel and firmware transmission. For an update to be broadcast friendly, it cannot rel
y on link y on link-layer, network-layer, or transport-layer security. A solution has
layer, network layer, or transport layer security. A solution has
to rely on security protection applied to the manifest and firmware image to rely on security protection applied to the manifest and firmware image
instead. In addition, instead. In addition,
the same manifest must be deliverable to many devices, both those the same manifest must be deliverable to many devices, both those
to which it applies and those to which it does not, without a to which it applies and those to which it does not, without a
chance that the wrong device will accept the update. Considerations chance that the wrong device will accept the update. Considerations
that apply to network broadcasts apply equally to the use of that apply to network broadcasts apply equally to the use of
third-party content distribution networks for payload distribution.</t> third-party content distribution networks for payload distribution.</t>
<figure anchor="arch-figure">
<figure title="Architecture." anchor="arch-figure"><artwork><![CDATA[ <name>Architecture</name>
<artwork name="" type="" align="center" alt=""><![CDATA[
+----------+ +----------+
| | | |
| Author | | Author |
| | | |
+----------+ +----------+
Firmware + Manifest | Firmware + Manifest |
+----------------------------------+ | Firmware + +----------------------------------+ | Firmware +
| | | Manifest | | | Manifest
| ---+------- | | ---+------- |
| ---- | --|- | ---- | --|-
| //+----------+ | \\ | //+----------+ | \\
-+-- // | | | \ -+-- // | | | \
----/ | ---- |/ | Firmware |<-+ | \ ----/ | ---- |/ | Firmware |<-+ | \
// | \\ | | Server | | | \ // | \\ | | Server | | | \
/ | \ / | | + + \ / | \ / | | + + \
/ | \ / +----------+ \ / | / | \ / +----------+ \ / |
/ +--------+--------+ \ / | | / +--------+--------+ \ / | |
/ | v | \ / v | / | v | \ / v |
| | +------------+ | | | +----------------+ | | | +------------+ | | | +----------------+ |
| | | Firmware | | | Device | | | | | Firmware | | | | | Device | |
| | | Consumer | | | | | Management | | | | | Consumer | | | | | Management | |
| | +------------+ | | | | | | | | +------------+ | | | | | |
| | +------------+ | | | | +--------+ | | | | +------------+ | | | | +--------+ | |
| | | Status |<-+--------------------+-> | | | | | | | Status |<-+--------------------+-> | | | |
| | | Tracker | | | | | | Status | | | | | | Tracker | | | | | | Status | | |
| | | Client | | | | | | Tracker| | | | | | Client | | | | | | Tracker| | |
| | +------------+ | | | | | Server | | | | | +------------+ | | | | | Server | | |
| | Device | | | | +--------+ | | | | Device | | | | +--------+ | |
| +-----------------+ | \ | | / | +-----------------+ | \ | | /
\ / \ +----------------+ / \ / \ +----------------+ /
\ Network / \ / \ Network / \ /
\ Operator / \ Device Operator / \ Operator / \ Device Operator /
\\ // \ \ // \\ // \\ //
---- ---- ---- ---- ---- ---- ---- ----
----- ----------- ----- -----------
]]></artwork></figure> ]]></artwork>
</figure>
<t>Firmware images and manifests may be conveyed as a bundle or detached. The <t>Firmware images and manifests may be conveyed as a bundle or detached.
The
manifest format must support both approaches.</t> manifest format must support both approaches.</t>
<t>For distribution as a bundle, the firmware image is embedded into the m
<t>For distribution as a bundle, the firmware image is embedded into the manifes anifest.
t.
This is a useful approach for deployments where devices are not connected 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 to the Internet and cannot contact a dedicated firmware server for the firmware
download. It is also applicable when the firmware update happens via a download. It is also applicable when the firmware update happens via USB sticks
USB sticks or short range radio technologies (such as Bluetooth Smart).</t> or short-range radio technologies (such as Bluetooth Smart).</t>
<t>Alternatively, the manifest is distributed detached from the firmware i
<t>Alternatively, the manifest is distributed detached from the firmware image. mage.
Using this approach, the firmware consumer is presented with the manifest first 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 and then needs to obtain one or more firmware images as dictated in the
manifest.</t> manifest.</t>
<t>The pre-authorization step involves verifying whether the entity
<t>The pre-authorisation step involves verifying whether the entity
signing the manifest is indeed authorized to perform an update. signing the manifest is indeed authorized to perform an update.
The firmware consumer must also determine whether it should fetch and The firmware consumer must also determine whether it should fetch and
process a firmware image, which is referenced in a manifest.</t> process a firmware image, which is referenced in a manifest.</t>
<t>A dependency resolution phase is needed when more than one
<t>A dependency resolution phase is needed when more than one
component can be updated or when a differential update is used. component can be updated or when a differential update is used.
The necessary dependencies must be available prior to installation.</t> The necessary dependencies must be available prior to installation.</t>
<t>The download step is the process of acquiring a local copy of the
<t>The download step is the process of acquiring a local copy of the firmware image. When the download is client initiated, this means
firmware image. When the download is client-initiated, this means
that the firmware consumer chooses when a download occurs and initiates that the firmware consumer chooses when a download occurs and initiates
the download process. When a download is server-initiated, the download process. When a download is server initiated,
this means that the status tracker tells this means that the status tracker tells
the device when to download or that it initiates the transfer the device when to download or that it initiates the transfer
directly to the firmware consumer. For example, a download from an directly to the firmware consumer. For example, a download from an
HTTP/1.1-based firmware server is client-initiated. Pushing a manifest HTTP/1.1-based firmware server is client initiated. Pushing a manifest
and firmware image to the Package resource of the LwM2M and firmware image to the Package Resource of the LwM2M
Firmware Update object <xref target="LwM2M"/> is server-initiated update.</t> Firmware Update Object <xref target="LwM2M" format="default"/> is a server-initi
ated update.</t>
<t>If the firmware consumer has downloaded a new firmware image and is ready to <t>If the firmware consumer has downloaded a new firmware image and is rea
dy to
install it, to initiate the installation, it may</t> install it, to initiate the installation, it may</t>
<ul spacing="normal">
<t><list style="symbols"> <li>need to wait for a trigger from the status tracker,</li>
<t>either need to wait for a trigger from the status tracker,</t> <li>trigger the update automatically, or</li>
<t>or trigger the update automatically,</t> <li>go through a more complex decision-making process to determine
<t>or go through a more complex decision making process to determine</t> the appropriate timing for an update.</li></ul><t> Sometimes the final dec
</list></t> ision may
<t>the appropriate timing for an update. Sometimes the final decision may
require confirmation of the user of the device for safety reasons.</t> require confirmation of the user of the device for safety reasons.</t>
<t>Installation is the act of processing the payload into a format that
<t>Installation is the act of processing the payload into a format that the IoT device can recognize, and the bootloader is responsible for
the IoT device can recognize and the bootloader is responsible for
then booting from the newly installed firmware image. then booting from the newly installed firmware image.
This process is different when a bootloader is not involved. For example, This process is different when a bootloader is not involved. For example,
when an application is updated in a full-featured operating system, the when an application is updated in a full-featured OS, the
updater may halt and restart the application in isolation. updater may halt and restart the application in isolation.
Devices must not fail when a disruption, such as a power failure or network Devices must not fail when a disruption, such as a power failure or network
interruption, occurs during the update process.</t> interruption, occurs during the update process.</t>
</section>
<section anchor="invocation" numbered="true" toc="default">
<name>Invoking the Firmware</name>
</section> <t><xref target="architecture" format="default"/> describes the steps for
<section anchor="invocation" title="Invoking the Firmware"> getting the firmware image and the manifest
<t><xref target="architecture"/> describes the steps for getting the firmware im
age and the manifest
from the author to the firmware consumer on the IoT device. Once the firmware co nsumer from the author to the firmware consumer on the IoT device. Once the firmware co nsumer
has retrieved and successfully processed the manifest and the firmware image it has retrieved and successfully processed the manifest and the firmware image, it
needs needs
to invoke the new firmware image. This is managed in many different ways, depend to invoke the new firmware image. This is managed in many different ways dependi
ing ng
on the type of device, but it typically involves halting the current version of the on the type of device, but it typically involves halting the current version of the
firmware, handing control over to a firmware with a higher privilege/trust level firmware, handing over control to firmware with a higher privilege or trust leve l
(the firmware verifier), (the firmware verifier),
verifying the new firmware’s authenticity &amp; integrity, and then invoking it. verifying the new firmware's authenticity and integrity, and then invoking it.</
</t> t>
<t>In an execute-in-place microcontroller, this is often done by rebooting
<t>In an execute-in-place microcontroller, this is often done by rebooting into into a
a bootloader (simultaneously halting the application and handing over control to t
bootloader (simultaneously halting the application &amp; handing over to the hig he higher
her
privilege level) then executing a secure boot process (verifying and invoking privilege level) then executing a secure boot process (verifying and invoking
the new image).</t> the new image).</t>
<t>In a rich OS, this may be done by halting one or more processes and the
<t>In a rich OS, this may be done by halting one or more processes, then invokin n invoking
g new applications. In some OSes, this implicitly involves the kernel verifying
new applications. In some OSs, this implicitly involves the kernel verifying
the code signatures on the new applications.</t> the code signatures on the new applications.</t>
<t>The invocation process is security sensitive. An attacker will typicall
<t>The invocation process is security sensitive. An attacker will typically try y try to
to
retrieve a firmware image from the device for reverse engineering or will try to get 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. The the firmware verifier to execute an attacker-modified firmware image. Therefore,
firmware verifier will therefore have to perform security checks on the firmware verifier will have to perform security checks on the
firmware image before it can be invoked. These security checks by 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 firmware verifier happen in addition to the security checks that took place
when the firmware image and the manifest were downloaded by the firmware consume r.</t> when the firmware image and the manifest were downloaded by the firmware consume r.</t>
<t>The overlap between the firmware consumer and the firmware verifier
<t>The overlap between the firmware consumer and the firmware verifier functionality comes in two forms, namely:</t>
functionality comes in two forms, namely</t> <ul spacing="normal">
<li>A firmware verifier must verify the firmware image it boots as
<t><list style="symbols"> part of the secure boot process. Doing so requires metadata to be
<t>A firmware verifier must verify the firmware image it boots as
part of the secure boot process. Doing so requires meta-data to be
stored alongside the firmware image so that the firmware verifier can stored alongside the firmware image so that the firmware verifier can
cryptographically verify the firmware image before booting it to cryptographically verify the firmware image before booting it to
ensure it has not been tampered with or replaced. This meta-data 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 used by the firmware verifier may well be the same manifest obtained with the
firmware image during the update process.</t> firmware image during the update process.</li>
<t>An IoT device needs a recovery strategy in case the firmware <li>An IoT device needs a recovery strategy in case the firmware
update / invocation process fails. The recovery update/invocation process fails. The recovery
strategy may include storing two or more application firmware images strategy may include storing two or more application firmware images
on the device or offering the ability to invoke a recovery image to on the device or offering the ability to invoke a recovery image to
perform the firmware update process again using firmware updates over perform the firmware update process again using firmware updates over
serial, USB or even wireless connectivity like Bluetooth Smart. serial, USB, or even wireless connectivity like Bluetooth Smart.
In the latter case the firmware consumer functionality is contained in the In the latter case, the firmware consumer functionality is contained in the
recovery image and requires the necessary functionality for recovery image and requires the necessary functionality for
executing the firmware update process, including manifest parsing.</t> executing the firmware update process, including manifest parsing.</li>
</list></t> </ul>
<t>While this document assumes that the firmware verifier itself is
<t>While this document assumes that the firmware verifier itself is
distinct from the role of the firmware consumer and therefore does not distinct from the role of the firmware consumer and therefore does not
manage the firmware update process, this is not a requirement and these manage the firmware update process, this is not a requirement, and these
roles may be combined in practice.</t> roles may be combined in practice.</t>
<t>Using a bootloader as the firmware verifier requires some special
<t>Using a bootloader as the firmware verifier requires some special
considerations, particularly when the bootloader considerations, particularly when the bootloader
implements the robustness requirements identified by the IOTSU workshop <xref ta implements the robustness requirements identified by the IoTSU workshop <xref ta
rget="RFC8240"/>.</t> rget="RFC8240" format="default"/>.</t>
<section anchor="bootloader" numbered="true" toc="default">
<section anchor="bootloader" title="The Bootloader"> <name>The Bootloader</name>
<t>In most cases, the MCU must restart in order to hand over control to
<t>In most cases the MCU must restart in order to hand over control to the bootl the bootloader.
oader.
Once the MCU has initiated a restart, the bootloader determines whether a newly available 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 av ailable firmware image should be executed. If the bootloader concludes that the newly av ailable
firmware image is invalid, a recovery strategy is necessary. There are only two firmware image is invalid, a recovery strategy is necessary. There are only two
approaches for recovering from an invalid firmware: either the bootloader must b approaches for recovering from invalid firmware: either the bootloader must be a
e able ble
to select a different, valid firmware, or it must be able to obtain a new, valid to select different, valid firmware or it must be able to obtain new, valid firm
firmware. ware.
Both of these approaches have implications for the architecture of the update sy stem.</t> Both of these approaches have implications for the architecture of the update sy stem.</t>
<t>Assuming the first approach, there are (at least) three firmware imag
<t>Assuming the first approach, there are (at least) three firmware images avail es available
able
on the device:</t> on the device:</t>
<ul spacing="normal">
<t><list style="symbols"> <li>First, the bootloader is also firmware. If a bootloader is updatab
<t>First, the bootloader is also firmware. If a bootloader is updatable then i le, then its
ts firmware image is treated like any other application firmware image.</li>
firmware image is treated like any other application firmware image.</t> <li>Second, the firmware image that has to be replaced is still availa
<t>Second, the firmware image that has to be replaced is still available on th ble on the
e
device as a backup in case the freshly downloaded firmware image does not device as a backup in case the freshly downloaded firmware image does not
boot or operate correctly.</t> boot or operate correctly.</li>
<t>Third, there is the newly downloaded firmware image.</t> <li>Third, there is the newly downloaded firmware image.</li>
</list></t> </ul>
<t>Therefore, the firmware consumer must know where to store the new fir
<t>Therefore, the firmware consumer must know where to store the new firmware. mware.
In some cases, this may be implicit, for example replacing the least-recently-us In some cases, this may be implicit (for example, replacing the least recently u
ed sed
firmware image. In other cases, the storage location of the new firmware must be firmware image). In other cases, the storage location of the new firmware must b
explicit, for example when a device has one or more application firmware images e
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 u pdate.</t> and a recovery image with limited functionality, sufficient only to perform an u pdate.</t>
<t>Since many low-end IoT devices do not use position-independent code,
<t>Since many low end IoT devices do not use position-independent code,
either the bootloader needs to copy the newly downloaded application firmware im age either the bootloader needs to copy the newly downloaded application firmware im age
into the location of the old application firmware image and vice versa or 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.</ t> multiple versions of the firmware need to be prepared for different locations.</ t>
<t>In general, it is assumed that the bootloader itself, or a minimal pa
<t>In general, it is assumed that the bootloader itself, or a minimal part of it rt of it,
,
will not be updated since a failed update of the bootloader poses a will not be updated since a failed update of the bootloader poses a
reliability risk.</t> reliability risk.</t>
<t>For a bootloader to offer a secure boot functionality, it needs to
<t>For a bootloader to offer a secure boot functionality it needs to
implement the following functionality:</t> implement the following functionality:</t>
<ul spacing="normal">
<t><list style="symbols"> <li>The bootloader needs to fetch the manifest
<t>The bootloader needs to fetch the manifest
from nonvolatile storage and parse its from nonvolatile storage and parse its
contents for subsequent cryptographic verification.</t> contents for subsequent cryptographic verification.</li>
<t>Cryptographic libraries with hash functions, digital signatures <li>Cryptographic libraries with hash functions, digital signatures
(for asymmetric crypto), message authentication codes (for symmetric (for asymmetric crypto), and message authentication codes (for symmetric
crypto) need to be accessible.</t> crypto) need to be accessible.</li>
<t>The device needs to have a trust anchor store to verify the <li>The device needs to have a trust anchor store to verify the
digital signature. (Alternatively, access to a key store for use digital signature. Alternatively, access to a key store for use
with the message authentication code.)</t> with the message authentication code may be used.</li>
<t>There must be an ability to expose boot process-related data to the applica <li>There must be an ability to expose boot-process-related data to th
tion e application
firmware (such as to the status tracker). This allows firmware (such as the status tracker). This allows
sharing information about the current firmware version, and the information sharing about the current firmware version and the
status of the firmware update process and whether errors have occurred.</t> status of the firmware update process and whether errors have occurred.</li>
<t>Produce boot measurements as part of an attestation solution. See <li>Produce boot measurements as part of an attestation solution; see
<xref target="I-D.ietf-rats-architecture"/> for more information. (optional)</t> <xref target="I-D.ietf-rats-architecture" format="default"/> for more informatio
<t>The bootloader must be able to decrypt firmware images, in case confidentia n (optional).</li>
lity protection <li>The bootloader must be able to decrypt firmware images in case con
was applied. This requires a solution for key management. (optional)</t> fidentiality protection
</list></t> was applied. This requires a solution for key management (optional).</li>
</ul>
</section> </section>
</section> </section>
<section anchor="device" title="Types of IoT Devices"> <section anchor="device" numbered="true" toc="default">
<name>Types of IoT Devices</name>
<t>There are billions of MCUs used in devices today produced by a large <t>Today, there are billions of MCUs used in devices produced by a large
number of silicon manufacturers. While MCUs can vary significantly number of silicon manufacturers. While MCUs can vary significantly
in their characteristics, there are a number of similiaries allowing in their characteristics, there are a number of similarities that allow us to ca
us to categorize in groups.</t> tegorize them into groups.</t>
<t>The firmware update architecture, and the manifest format in particular
<t>The firmware update architecture, and the manifest format in particular, ,
needs to offer enough flexibility to cover these common deployment cases.</t> needs to offer enough flexibility to cover these common deployment cases.</t>
<section anchor="single-mcu" numbered="true" toc="default">
<section anchor="single-mcu" title="Single MCU"> <name>Single MCU</name>
<t>The simplest and currently most common architecture consists of
<t>The simplest, and currently most common, architecture consists of
a single MCU along with its own peripherals. These SoCs generally a single MCU along with its own peripherals. These SoCs generally
contain some amount of flash memory for code and fixed data, as contain some amount of flash memory for code and fixed data, as
well as RAM for working storage. A notable characteristic of these well as RAM for working storage. A notable characteristic of these
SoCs is that the primary code is generally execute in place (XIP). SoCs is that the primary code is generally execute in place (XIP).
Due to the non-relocatable nature of the code, the firmware image Due to the non-relocatable nature of the code, the firmware image
needs to be placed in a specific location in flash since the code needs to be placed in a specific location in flash memory since the code
cannot be executed from an arbitrary location in flash. Hence, when cannot be executed from an arbitrary location therein. Hence, when
the firmware image is updated it is necessary to swap the old and the firmware image is updated, it is necessary to swap the old and
the new image.</t> the new image.</t>
</section>
<section anchor="single-cpu-with-secure-normal-mode-partitioning" numbered
="true" toc="default">
</section> <name>Single CPU with Partitioning between Secure Mode and Normal Mode</
<section anchor="single-cpu-with-secure-normal-mode-partitioning" title="Single name>
CPU with Secure - Normal Mode Partitioning"> <t>Another configuration consists of a similar architecture to the
one previously discussed: it contains a single CPU. However, this CPU supports
<t>Another configuration consists of a similar architecture to the a security
previous, with a single CPU. However, this CPU supports a security partitioning scheme that allows memory and other system components to be divided
partitioning scheme that allows memory (in addition to other things) into secure and normal mode. There will generally be
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
two images, one for secure mode, and one for normal mode. In this
configuration, firmware upgrades will generally be done by the CPU configuration, firmware upgrades will generally be done by the CPU
in secure mode, which is able to write to both areas of the flash 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 device. In addition, there are requirements to be able to update
either image independently, as well as to update them together either image independently as well as to update them together
atomically, as specified in the associated manifests.</t> atomically, as specified in the associated manifests.</t>
</section>
</section> <section anchor="symmetric-multiple-cpus" numbered="true" toc="default">
<section anchor="symmetric-multiple-cpus" title="Symmetric Multiple CPUs"> <name>Symmetric Multiple CPUs</name>
<t>In more complex SoCs with symmetric multiprocessing support, advanced
<t>In more complex SoCs with symmetric multi-processing support, advanced
operating systems, such as Linux, are often used. These SoCs frequently operating systems, such as Linux, are often used. These SoCs frequently
use an external storage medium, such as raw NAND flash or eMMC. Due to 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 the higher quantity of resources, these devices are often capable of
storing multiple copies of their firmware images and selecting the most storing multiple copies of their firmware images and selecting the most
appropriate one to boot. Many SoCs also support bootloaders that are appropriate one to boot. Many SoCs also support bootloaders that are
capable of updating the firmware image, however this is typically a last 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 resort because it requires the device to be held in the bootloader while
the new firmware is downloaded and installed, which results in down-time the new firmware is downloaded and installed, which results in downtime
for the device. Firmware updates in this class of device are typically for the device. Firmware updates in this class of device are typically
not done in-place.</t> not done in place.</t>
</section>
</section> <section anchor="dual-cpu-shared-memory" numbered="true" toc="default">
<section anchor="dual-cpu-shared-memory" title="Dual CPU, shared memory"> <name>Dual CPU, Shared Memory</name>
<t>This configuration has two or more heterogeneous CPUs in a single SoC
<t>This configuration has two or more heterogeneous CPUs in a single SoC that that
share memory (flash and RAM). Generally, there will be a mechanism to prevent share memory (flash and RAM). Generally, there will be a mechanism to prevent
one CPU from unintentionally accessing memory currently allocated to the other. 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 Upgrades in this case will typically be done by one of the CPUs and is
similar to the single CPU with secure mode.</t> similar to the single CPU with secure mode.</t>
</section>
</section> <section anchor="dual-cpu-other-bus" numbered="true" toc="default">
<section anchor="dual-cpu-other-bus" title="Dual CPU, other bus"> <name>Dual CPU, Other Bus</name>
<t>This configuration has two or more heterogeneous CPUs, each having th
<t>This configuration has two or more heterogeneous CPUs, each having their own eir own memory.
memory.
There will be a communication channel between them, but it will be 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 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 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 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 direct the other CPU to do the upgrade. This configuration is
commonly used to offload specific work to other CPUs. Firmware commonly used to offload specific work to other CPUs. Firmware
dependencies are similar to the other solutions above, sometimes dependencies are similar to the other solutions above: sometimes
allowing only one image to be upgraded, other times requiring several allowing only one image to be upgraded, other times requiring several
to be upgraded atomically. Because the updates are happening on to be upgraded atomically. Because the updates are happening on
multiple CPUs, upgrading the two images atomically is challenging.</t> multiple CPUs, upgrading the two images atomically is challenging.</t>
</section>
</section> </section>
</section> <section anchor="manifests" numbered="true" toc="default">
<section anchor="manifests" title="Manifests"> <name>Manifests</name>
<t>In order for a firmware consumer to apply an update, it has to make sev
<t>In order for a firmware consumer to apply an update, it has to make several d eral decisions
ecisions
using manifest-provided information and data available on the device itself. For more 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 c detailed information and a longer list of information elements in the manifest,
onsult the consult the
information model specification <xref target="I-D.ietf-suit-information-model"/> information model specification <xref target="I-D.ietf-suit-information-model" f
, which offers justifications ormat="default"/>, which offers justifications
for each element, and the manifest specification <xref target="I-D.ietf-suit-man for each element, and the manifest specification <xref target="I-D.ietf-suit-man
ifest"/> for details about how this ifest" format="default"/> for details about how this
information is included in the manifest.</t> information is included in the manifest.</t>
<t><xref target="manifest-info"/> provides examples of decisions to be made.</t>
<texttable title="Firmware Update Decisions." anchor="manifest-info">
<ttcol align='right'>Decision</ttcol>
<ttcol align='left'>Information Elements</ttcol>
<c>Should I trust the author of the firmware?</c>
<c>Trust anchors and authorization policies on the device</c>
<c>Has the firmware been corrupted?</c>
<c>Digital signature and MAC covering the firmware image</c>
<c>Does the firmware update apply to this device?</c>
<c>Conditions with Vendor ID, Class ID and Device ID</c>
<c>Is the update older than the active firmware?</c>
<c>Sequence number in the manifest (1)</c>
<c>When should the device apply the update?</c>
<c>Wait directive</c>
<c>How should the device apply the update?</c>
<c>Manifest commands</c>
<c>What kind of firmware binary is it?</c>
<c>Unpack algorithms to interpret a format.</c>
<c>Where should the update be obtained?</c>
<c>Dependencies on other manifests and firmware image URI in Manifest</c>
<c>Where should the firmware be stored?</c>
<c>Storage Location and Component Identifier</c>
</texttable>
<t>(1): A device presented with an old, but valid manifest and firmware <table anchor="manifest-info" align="center">
<name>Example Firmware Update Decisions</name>
<thead>
<tr>
<th align="right">Decision</th>
<th align="left">Information Elements</th>
</tr>
</thead>
<tbody>
<tr>
<td align="right">Should I trust the author of the firmware?</td>
<td align="left">Trust anchors and authorization policies on the dev
ice</td>
</tr>
<tr>
<td align="right">Has the firmware been corrupted?</td>
<td align="left">Digital signature and MAC covering the firmware ima
ge</td>
</tr>
<tr>
<td align="right">Does the firmware update apply to this device?</td
>
<td align="left">Conditions with Vendor ID, Class ID, and Device ID<
/td>
</tr>
<tr>
<td align="right">Is the update older than the active firmware?</td>
<td align="left">Sequence number in the manifest (1)</td>
</tr>
<tr>
<td align="right">When should the device apply the update?</td>
<td align="left">Wait directive</td>
</tr>
<tr>
<td align="right">How should the device apply the update?</td>
<td align="left">Manifest commands</td>
</tr>
<tr>
<td align="right">What kind of firmware binary is it?</td>
<td align="left">Unpack algorithms to interpret a format</td>
</tr>
<tr>
<td align="right">Where should the update be obtained?</td>
<td align="left">Dependencies on other manifests and firmware image
URI in the manifest</td>
</tr>
<tr>
<td align="right">Where should the firmware be stored?</td>
<td align="left">Storage location and component identifier</td>
</tr>
</tbody>
</table>
<dl indent="6" newline="false"><dt>(1):</dt><dd>A device presented with an
old but valid manifest and firmware
must not be tricked into installing such firmware since a must not be tricked into installing such firmware since a
vulnerability in the old firmware image may allow an attacker to vulnerability in the old firmware image may allow an attacker to
gain control of the device.</t> gain control of the device.</dd></dl>
<t>Keeping the code size and complexity of a manifest parser small is impo
<t>Keeping the code size and complexity of a manifest parsers small is important rtant
for constrained IoT devices. Since the manifest parsing code may 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.</t> also be used by the bootloader, it can be part of the trusted computing base.</t
>
<t>A manifest may be used to protect not only firmware images but also <t>A manifest may be used to protect not only firmware images but also
configuration data such as network credentials or personalization data configuration data such as network credentials or personalization data
related to firmware or software. related to the firmware or software.
Personalization data demonstrates the need for confidentiality to be Personalization data demonstrates the need for confidentiality to be
maintained between two or more stakeholders that both deliver images to maintained between two or more stakeholders that deliver images to
the same device. Personalization data is used with the same device. Personalization data is used with
Trusted Execution Environments (TEEs), which TEEs, which
benefit from a protocol for managing the lifecycle of trusted benefit from a protocol for managing the life cycle of TAs running inside a TEE.
applications (TAs) running inside a TEE. TEEs may obtain TAs TEEs may obtain TAs
from different authors and those TAs may require personalization data, from different authors, and those TAs may require personalization data,
such as payment information, to be securely conveyed to the TEE. The 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 TA's author does not want to expose the TA's code to any other stakeholder
or third party. or third party.
The user does not want to expose the payment information to any other The user does not want to expose the payment information to any other
stakeholder or third party.</t> stakeholder or third party.</t>
</section>
</section> <section anchor="securing" numbered="true" toc="default">
<section anchor="securing" title="Securing Firmware Updates"> <name>Securing Firmware Updates</name>
<t>Using firmware updates to fix vulnerabilities in devices is important,
<t>Using firmware updates to fix vulnerabilities in devices is important but sec but securing this
uring this
update mechanism is equally important since security problems are update mechanism is equally important since security problems are
exacerbated by the update mechanism: update is essentially authorized exacerbated by the update mechanism. An update is essentially authorized
remote code execution, so any security problems in the update process remote code execution, so any security problems in the update process
expose that remote code execution system. Failure expose that remote code execution system. Failure
to secure the firmware update process will help attackers to take control over d to secure the firmware update process will help attackers take control of device
evices.</t> s.</t>
<t>End-to-end security mechanisms are used to protect the firmware
<t>End-to-end security mechanisms are used to protect the firmware
image and the manifest. The following assumptions are made to allow image and the manifest. The following assumptions are made to allow
the firmware consumer to verify the received firmware image and the firmware consumer to verify the received firmware image and
manifest before updating software:</t> manifest before updating the software:</t>
<ul spacing="normal">
<t><list style="symbols"> <li>Authentication ensures that the device can cryptographically identif
<t>Authentication ensures that the device can cryptographically identify y
the author(s) creating firmware images and manifests. Authenticated the author(s) creating firmware images and manifests. Authenticated
identities may be used as input to the authorization process. Not all identities may be used as input to the authorization process. Not all
entities creating and signing manifests have the same entities creating and signing manifests have the same
permissions. A device needs to determine whether the requested action permissions. A device needs to determine whether the requested action
is indeed covered by the permission of the party that signed the manifest. is indeed covered by the permission of the party that signed the manifest.
Informing the device about the permissions of the different parties Informing the device about the permissions of the different parties
also happens in an out-of-band fashion and is a duty of the also happens in an out-of-band fashion and is a duty of the
Trust Provisioning Authority.</t> Trust Provisioning Authority.</li>
<t>Integrity protection ensures that no third party can modify the manifest <li>Integrity protection ensures that no third party can modify the mani
fest
or the firmware image. To accept an update, a device needs to verify the signatu re covering or the firmware image. To accept an update, a device needs to verify the signatu re covering
the manifest. There may be one or multiple manifests that need to be the manifest. There may be one or multiple manifests that need to be
validated, potentially signed by different parties. The device needs validated, potentially signed by different parties. The device needs
to be in possession of the trust anchors to verify those signatures. to be in possession of the trust anchors to verify those signatures.
Installing trust anchors to devices via the Trust Provisioning Authority Installing trust anchors to devices via the Trust Provisioning Authority
happens in an out-of-band fashion prior to the firmware update process.</t> happens in an out-of-band fashion prior to the firmware update process.</li>
<t>For confidentiality protection of the firmware image, it must be done in su <li>
ch a
way that the intended firmware consumer(s), other authorized parties, Confidentiality protection of the firmware image must be done in such a
and no one else can decrypt it. The information way that no one aside from the intended firmware consumer(s) and other authorize
d parties can decrypt it. The information
that is encrypted individually for each device/recipient must be done in a way t hat is that is encrypted individually for each device/recipient must be done in a way t hat is
usable with Content Distribution Networks, bulk storage, and usable with Content Distribution Networks (CDNs), bulk storage, and
broadcast protocols. For confidentiality protection of firmware images the autho broadcast protocols. For confidentiality protection of firmware images, the auth
r needs or needs
to be in possession of the certificate/public key or a pre-shared key 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 of a device. The use of confidentiality protection of firmware images
is optional.</t> is optional.</li>
</list></t> </ul>
<t>A manifest specification must support different cryptographic algorithms <t>A manifest specification must support different cryptographic algorithm
and algorithm extensibility. Moreover, since RSA- and ECC-based signature s
schemes may become vulnerable to quantum-accelerated key extraction in the 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 future, unchangeable bootloader code in ROM is recommended to use post-quantum
secure signature schemes such as hash-based signatures <xref target="RFC8778"/>. A secure signature schemes such as hash-based signatures <xref target="RFC8778" fo rmat="default"/>. A
bootloader author must carefully consider the service lifetime of their bootloader author must carefully consider the service lifetime of their
product and the time horizon for quantum-accelerated key extraction. product and the time horizon for quantum-accelerated key extraction.
The worst-case estimate, at time of writing, for the time horizon to key At the time of writing, the worst-case estimate for the time horizon to key
extraction with quantum acceleration is approximately 2030, based on extraction with quantum acceleration is approximately 2030, based on
current research <xref target="quantum-factorization"/>.</t> current research <xref target="quantum-factorization" format="default"/>.</t>
<t>When a device obtains a monolithic firmware image from a single author
<t>When a device obtains a monolithic firmware image from a single author
without any additional approval steps, the authorization flow is without any additional approval steps, the authorization flow is
relatively simple. There are, however, other cases where more complex relatively simple. However, there are other cases where more complex
policy decisions need to be made before updating a device.</t> policy decisions need to be made before updating a device.</t>
<t>In this architecture, the authorization policy is separated from
<t>In this architecture the authorization policy is separated from
the underlying communication architecture. This is accomplished the underlying communication architecture. This is accomplished
by separating the entities from their permissions. For example, by separating the entities from their permissions. For example,
an author may not have the authority to install a firmware image an author may not have the authority to install a firmware image
on a device in critical infrastructure without the authorization on a device in critical infrastructure without the authorization
of a device operator. In this case, the device may be programmed of a device operator. In this case, the device may be programmed
to reject firmware updates unless they are signed both by the to reject firmware updates unless they are signed both by the
firmware author and by the device operator.</t> firmware author and by the device operator.</t>
<t>Alternatively, a device may trust precisely one entity, which <t>Alternatively, a device may trust precisely one entity that
does all permission management and coordination. This entity does all permission management and coordination. This entity
allows the device to offload complex permissions allows the device to offload complex permissions
calculations for the device.</t> calculations for the device.</t>
</section>
</section> <section anchor="example" numbered="true" toc="default">
<section anchor="example" title="Example"> <name>Example</name>
<t><xref target="firmware-update" format="default"/> illustrates an exampl
<t><xref target="firmware-update"/> illustrates an example message flow e message flow
for distributing a firmware image to a device. The firmware for distributing a firmware image to a device. The firmware
and manifest are stored on the same firmware server and and manifest are stored on the same firmware server and
distributed in a detached manner.</t> distributed in a detached manner.</t>
<figure title="First Example Flow for a Firmware Update." anchor="firmware-updat <figure anchor="firmware-update">
e"><artwork><![CDATA[ <name>First Example Flow for a Firmware Update</name>
<artwork name="" type="" align="center" alt=""><![CDATA[
+--------+ +-----------------+ +-----------------------------+ +--------+ +-----------------+ +-----------------------------+
| | | Firmware Server | | IoT Device | | | | Firmware Server | | IoT Device |
| Author | | Status Tracker | | +------------+ +----------+ | | Author | | Status Tracker | | +------------+ +----------+ |
+--------+ | Server | | | Firmware | |Bootloader| | +--------+ | Server | | | Firmware | |Bootloader| |
| +-----------------+ | | Consumer | | | | | +-----------------+ | | Consumer | | | |
| | | +------------+ +----------+ | | | | +------------+ +----------+ |
| | | | | | | | | | | |
| | | +-----------------------+ | | | | +-----------------------+ |
| Create Firmware | | | Status Tracker Client | | | Create Firmware | | | Status Tracker Client | |
|--------------+ | | +-----------------------+ | |--------------+ | | +-----------------------+ |
skipping to change at line 932 skipping to change at line 884
| | |Complete| | | | |Complete| |
| | |------->| | | | |------->| |
| | | | | | | |
| | Firmware Update Completed | | | | Firmware Update Completed | |
| |<-----------------------------| | | |<-----------------------------| |
| | | | | | | |
| | Reboot | | | | Reboot | |
| |----------------------------->| | | |----------------------------->| |
| | | | | | | | | |
| | | | | | | | | |
| | |Reboot | | | | |Reboot |
| | | |------>| | | | |------>|
| | | | | | | | | |
| | | . | | | | . |
| | +---+----------------+--+ | | +---+----------------+--+
| | S| | | | | | S| | | |
| | E| | Verify | | | | E| | Verify | |
| | C| | Firmware | | | | C| | Firmware | |
| | U| | +--------------| | | | U| | +--------------| |
| | R| | | | | | | R| | | | |
| | E| | +------------->| | | | E| | +------------->| |
skipping to change at line 964 skipping to change at line 916
| | S| | +------------->| | | | S| | +------------->| |
| | S| | | | | | S| | | |
| | +---+----------------+--+ | | +---+----------------+--+
| | | . | | | | . |
| | | | | | | | | |
| | . | | | | . | |
| | Device running new firmware | | | | Device running new firmware | |
| |<-----------------------------| | | |<-----------------------------| |
| | . | | | | . | |
| | | | | | | |
]]></artwork></figure> ]]></artwork>
</figure>
<t><xref target="firmware-update2"/> shows an exchange that starts with the <t><xref target="firmware-update2" format="default"/> shows an exchange th
at starts with the
status tracker querying the device for its current firmware version. status tracker querying the device for its current firmware version.
Later, a new firmware version becomes available and since this Later, a new firmware version becomes available, and since this
device is running an older version the status tracker server interacts device is running an older version, the status tracker server interacts
with the device to initiate an update.</t> with the device to initiate an update.</t>
<t>The manifest and the firmware are stored on different servers in this
<t>The manifest and the firmware are stored on different servers in this example. When the device processes the manifest, it learns where to
example. When the device processes the manifest it learns where to
download the new firmware version. The firmware consumer downloads download the new firmware version. The firmware consumer downloads
the firmware image with the newer version X.Y.Z after successful validation the firmware image with the newer version X.Y.Z after successful validation
of the manifest. Subsequently, a reboot is initiated and the secure of the manifest. Subsequently, a reboot is initiated, and the secure
boot process starts. Finally, the device reports the successful boot boot process starts. Finally, the device reports the successful boot
of the new firmware version.</t> of the new firmware version.</t>
<figure anchor="firmware-update2">
<figure title="Second Example Flow for a Firmware Update." anchor="firmware-upda <name>Second Example Flow for a Firmware Update</name>
te2"><artwork><![CDATA[ <artwork name="" type="" align="center" alt=""><![CDATA[
+---------+ +-----------------+ +-----------------------------+ +---------+ +-----------------+ +-----------------------------+
| Status | | Firmware Server | | +------------+ +----------+ | | Status | | Firmware Server | | +------------+ +----------+ |
| Tracker | | Status Tracker | | | Firmware | |Bootloader| | | Tracker | | Status Tracker | | | Firmware | |Bootloader| |
| Server | | Server | | | Consumer | | | | | Server | | Server | | | Consumer | | | |
+---------+ +-----------------+ | | +Status | +----------+ | +---------+ +-----------------+ | | +Status | +----------+ |
| | | | Tracker | | | | | | | Tracker | | |
| | | | Client | | | | | | | Client | | |
| | | +------------+ | | | | | +------------+ | |
| | | | IoT Device | | | | | | IoT Device | |
| | `'''''''''''''''''''''''''''' | | `''''''''''''''''''''''''''''
skipping to change at line 1048 skipping to change at line 1000
| | | __..-------..._' | | | __..-------..._'
| | ,-' `-. | | ,-' `-.
| | | Secure Boot | | | | Secure Boot |
| | `-. _/ | | `-. _/
| | |`--..._____,,.,-' | | |`--..._____,,.,-'
| | | | | | | |
| Device running firmware X.Y.Z | | | Device running firmware X.Y.Z | |
|<-------------------------------------| | |<-------------------------------------| |
| | | | | | | |
| | | | | | | |
]]></artwork></figure> ]]></artwork>
</figure>
</section> </section>
<section anchor="iana-considerations" title="IANA Considerations"> <section anchor="iana-considerations" numbered="true" toc="default">
<name>IANA Considerations</name>
<t>This document does not require any actions by IANA.</t> <t>This document has no IANA actions.</t>
</section>
</section> <section anchor="security-considerations" numbered="true" toc="default">
<section anchor="security-considerations" title="Security Considerations"> <name>Security Considerations</name>
<t>This document describes the terminology, requirements, and an architect
<t>This document describes terminology, requirements and an architecture for ure for
firmware updates of IoT devices. The content of the document is thereby firmware updates of IoT devices. The content of the document is thereby
focused on improving security of IoT devices via firmware update mechanisms focused on improving the security of IoT devices via firmware update mechanisms
and informs the standardization of a manifest format.</t> and informs the standardization of a manifest format.</t>
<t>An in-depth examination of the security considerations of the
<t>An in-depth examination of the security considerations of the architecture is presented in <xref target="I-D.ietf-suit-information-model" form
architecture is presented in <xref target="I-D.ietf-suit-information-model"/>.</ at="default"/>.</t>
t> </section>
</section>
<section anchor="acknowledgements" title="Acknowledgements">
<t>We would like to thank the following persons for their feedback:</t>
<t><list style="symbols">
<t>Geraint Luff</t>
<t>Amyas Phillips</t>
<t>Dan Ros</t>
<t>Thomas Eichinger</t>
<t>Michael Richardson</t>
<t>Emmanuel Baccelli</t>
<t>Ned Smith</t>
<t>Jim Schaad</t>
<t>Carsten Bormann</t>
<t>Cullen Jennings</t>
<t>Olaf Bergmann</t>
<t>Suhas Nandakumar</t>
<t>Phillip Hallam-Baker</t>
<t>Marti Bolivar</t>
<t>Andrzej Puzdrowski</t>
<t>Markus Gueller</t>
<t>Henk Birkholz</t>
<t>Jintao Zhu</t>
<t>Takeshi Takahashi</t>
<t>Jacob Beningo</t>
<t>Kathleen Moriarty</t>
<t>Bob Briscoe</t>
<t>Roman Danyliw</t>
<t>Brian Carpenter</t>
<t>Theresa Enghardt</t>
<t>Rich Salz</t>
<t>Mohit Sethi</t>
<t>Eric Vyncke</t>
<t>Alvaro Retana</t>
<t>Barry Leiba</t>
<t>Benjamin Kaduk</t>
<t>Martin Duke</t>
<t>Robert Wilton</t>
</list></t>
<t>We would also like to thank the WG chairs, Russ Housley, David Waltermire, an
d
Dave Thaler, for their support and their reviews.</t>
</section>
</middle> </middle>
<back> <back>
<references title='Informative References'> <displayreference target="I-D.ietf-suit-information-model" to="SUIT-INFO-MODEL"/
>
<reference anchor="RFC8240" target='https://www.rfc-editor.org/info/rfc8240'> <displayreference target="I-D.ietf-teep-architecture" to="TEEP-ARCH"/>
<front> <displayreference target="I-D.ietf-suit-manifest" to="SUIT-MANIFEST"/>
<title>Report from the Internet of Things Software Update (IoTSU) Workshop 2016< <displayreference target="I-D.ietf-rats-architecture" to="RATS-ARCH"/>
/title>
<author initials='H.' surname='Tschofenig' fullname='H. Tschofenig'><organizatio
n /></author>
<author initials='S.' surname='Farrell' fullname='S. Farrell'><organization /></
author>
<date year='2017' month='September' />
<abstract><t>This document provides a summary of the Internet of Things Software
Update (IoTSU) Workshop that took place at Trinity College Dublin, Ireland on t
he 13th and 14th of June, 2016. The main goal of the workshop was to foster a d
iscussion on requirements, challenges, and solutions for bringing software and f
irmware updates to IoT devices. This report summarizes the discussions and lists
recommendations to the standards community.</t><t>Note that this document is a
report on the proceedings of the workshop. The views and positions documented i
n this report are those of the workshop participants and do not necessarily refl
ect IAB views and positions.</t></abstract>
</front>
<seriesInfo name='RFC' value='8240'/>
<seriesInfo name='DOI' value='10.17487/RFC8240'/>
</reference>
<reference anchor="RFC6024" target='https://www.rfc-editor.org/info/rfc6024'>
<front>
<title>Trust Anchor Management Requirements</title>
<author initials='R.' surname='Reddy' fullname='R. Reddy'><organization /></auth
or>
<author initials='C.' surname='Wallace' fullname='C. Wallace'><organization /></
author>
<date year='2010' month='October' />
<abstract><t>A trust anchor represents an authoritative entity via a public key
and associated data. The public key is used to verify digital signatures, and t
he associated data is used to constrain the types of information for which the t
rust anchor is authoritative. A relying party uses trust anchors to determine i
f a digitally signed object is valid by verifying a digital signature using the
trust anchor's public key, and by enforcing the constraints expressed in the ass
ociated data for the trust anchor. This document describes some of the problems
associated with the lack of a standard trust anchor management mechanism and de
fines requirements for data formats and push-based protocols designed to address
these problems. This document is not an Internet Standards Track specificatio
n; it is published for informational purposes.</t></abstract>
</front>
<seriesInfo name='RFC' value='6024'/>
<seriesInfo name='DOI' value='10.17487/RFC6024'/>
</reference>
<reference anchor="RFC6763" target='https://www.rfc-editor.org/info/rfc6763'>
<front>
<title>DNS-Based Service Discovery</title>
<author initials='S.' surname='Cheshire' fullname='S. Cheshire'><organization />
</author>
<author initials='M.' surname='Krochmal' fullname='M. Krochmal'><organization />
</author>
<date year='2013' month='February' />
<abstract><t>This document specifies how DNS resource records are named and stru
ctured to facilitate service discovery. Given a type of service that a client i
s looking for, and a domain in which the client is looking for that service, thi
s mechanism allows clients to discover a list of named instances of that desired
service, using standard DNS queries. This mechanism is referred to as DNS-based
Service Discovery, or DNS-SD.</t></abstract>
</front>
<seriesInfo name='RFC' value='6763'/>
<seriesInfo name='DOI' value='10.17487/RFC6763'/>
</reference>
<reference anchor="RFC7228" target='https://www.rfc-editor.org/info/rfc7228'>
<front>
<title>Terminology for Constrained-Node Networks</title>
<author initials='C.' surname='Bormann' fullname='C. Bormann'><organization /></
author>
<author initials='M.' surname='Ersue' fullname='M. Ersue'><organization /></auth
or>
<author initials='A.' surname='Keranen' fullname='A. Keranen'><organization /></
author>
<date year='2014' month='May' />
<abstract><t>The Internet Protocol Suite is increasingly used on small devices w
ith severe constraints on power, memory, and processing resources, creating cons
trained-node networks. This document provides a number of basic terms that have
been useful in the standardization work for constrained-node networks.</t></abs
tract>
</front>
<seriesInfo name='RFC' value='7228'/>
<seriesInfo name='DOI' value='10.17487/RFC7228'/>
</reference>
<reference anchor="RFC8778" target='https://www.rfc-editor.org/info/rfc8778'>
<front>
<title>Use of the HSS/LMS Hash-Based Signature Algorithm with CBOR Object Signin
g and Encryption (COSE)</title>
<author initials='R.' surname='Housley' fullname='R. Housley'><organization /></
author>
<date year='2020' month='April' />
<abstract><t>This document specifies the conventions for using the Hierarchical
Signature System (HSS) / Leighton-Micali Signature (LMS) hash-based signature al
gorithm with the CBOR Object Signing and Encryption (COSE) syntax. The HSS/LMS a
lgorithm is one form of hash-based digital signature; it is described in RFC 855
4.</t></abstract>
</front>
<seriesInfo name='RFC' value='8778'/>
<seriesInfo name='DOI' value='10.17487/RFC8778'/>
</reference>
<reference anchor="I-D.ietf-suit-information-model">
<front>
<title>An Information Model for Firmware Updates in IoT Devices</title>
<author initials='B' surname='Moran' fullname='Brendan Moran'>
<organization />
</author>
<author initials='H' surname='Tschofenig' fullname='Hannes Tschofenig'>
<organization />
</author>
<author initials='H' surname='Birkholz' fullname='Henk Birkholz'>
<organization />
</author>
<date month='October' day='28' year='2020' />
<abstract><t>Vulnerabilities with Internet of Things (IoT) devices have raised t
he need for a reliable and secure firmware update mechanism that is also suitabl
e for constrained devices. Ensuring that devices function and remain secure ove
r their service life requires such an update mechanism to fix vulnerabilities, t
o update configuration settings, as well as adding new functionality. One compo
nent of such a firmware update is a concise and machine- processable meta-data d
ocument, or manifest, that describes the firmware image(s) and offers appropriat
e protection. This document describes the information that must be present in t
he manifest.</t></abstract>
</front>
<seriesInfo name='Internet-Draft' value='draft-ietf-suit-information-model-08' /
>
<format type='TXT'
target='http://www.ietf.org/internet-drafts/draft-ietf-suit-information-
model-08.txt' />
</reference>
<reference anchor="I-D.ietf-teep-architecture">
<front>
<title>Trusted Execution Environment Provisioning (TEEP) Architecture</title>
<author initials='M' surname='Pei' fullname='Mingliang Pei'>
<organization />
</author>
<author initials='H' surname='Tschofenig' fullname='Hannes Tschofenig'>
<organization />
</author>
<author initials='D' surname='Thaler' fullname='Dave Thaler'>
<organization />
</author>
<author initials='D' surname='Wheeler' fullname='David Wheeler'>
<organization />
</author>
<date month='November' day='2' year='2020' />
<abstract><t>A Trusted Execution Environment (TEE) is an environment that enforc
es that any code within that environment cannot be tampered with, and that any d
ata used by such code cannot be read or tampered with by any code outside that e
nvironment. This architecture document motivates the design and standardization
of a protocol for managing the lifecycle of trusted applications running inside
such a TEE.</t></abstract>
</front>
<seriesInfo name='Internet-Draft' value='draft-ietf-teep-architecture-13' />
<format type='TXT'
target='http://www.ietf.org/internet-drafts/draft-ietf-teep-architecture
-13.txt' />
</reference>
<reference anchor="I-D.ietf-suit-manifest">
<front>
<title>A Concise Binary Object Representation (CBOR)-based Serialization Format
for the Software Updates for Internet of Things (SUIT) Manifest</title>
<author initials='B' surname='Moran' fullname='Brendan Moran'>
<organization />
</author>
<author initials='H' surname='Tschofenig' fullname='Hannes Tschofenig'>
<organization />
</author>
<author initials='H' surname='Birkholz' fullname='Henk Birkholz'>
<organization />
</author>
<author initials='K' surname='Zandberg' fullname='Koen Zandberg'>
<organization />
</author>
<date month='December' day='8' year='2020' />
<abstract><t>This specification describes the format of a manifest. A manifest
is a bundle of metadata about code/data obtained by a recipient (chiefly the fir
mware for an IoT device), where to find the that code/data, the devices to which
it applies, and cryptographic information protecting the manifest. Software up
dates and Trusted Invocation both tend to use sequences of common operations, so
the manifest encodes those sequences of operations, rather than declaring the m
etadata.</t></abstract>
</front>
<seriesInfo name='Internet-Draft' value='draft-ietf-suit-manifest-11' />
<format type='TXT'
target='http://www.ietf.org/internet-drafts/draft-ietf-suit-manifest-11.
txt' />
</reference>
<reference anchor="I-D.ietf-rats-architecture">
<front>
<title>Remote Attestation Procedures Architecture</title>
<author initials='H' surname='Birkholz' fullname='Henk Birkholz'>
<organization />
</author>
<author initials='D' surname='Thaler' fullname='Dave Thaler'>
<organization />
</author>
<author initials='M' surname='Richardson' fullname='Michael Richardson'>
<organization />
</author>
<author initials='N' surname='Smith' fullname='Ned Smith'>
<organization />
</author>
<author initials='W' surname='Pan' fullname='Wei Pan'> <references>
<organization /> <name>Informative References</name>
</author> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
.8240.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
.6024.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
.6763.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
.7228.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
.8778.xml"/>
<date month='December' day='8' year='2020' /> <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.i etf-suit-information-model.xml"/>
<abstract><t>In network protocol exchanges it is often the case that one entity requires believable evidence about the operational state of a remote peer. Such evidence is typically conveyed as claims about the peer's software and hardware platform, and is subsequently appraised in order to assess the peer's trustwort hiness. The process of generating and appraising this kind of evidence is known as remote attestation. This document describes an architecture for remote atte station procedures that generate, convey, and appraise evidence about a peer's o perational state.</t></abstract> <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.i etf-teep-architecture.xml"/>
</front> <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.i etf-suit-manifest.xml"/>
<seriesInfo name='Internet-Draft' value='draft-ietf-rats-architecture-08' /> <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.i
<format type='TXT' etf-rats-architecture.xml"/>
target='http://www.ietf.org/internet-drafts/draft-ietf-rats-architecture
-08.txt' />
</reference>
<reference anchor="quantum-factorization" target="https://www.nature.com/article <reference anchor="quantum-factorization" target="https://www.nature.com/a
s/s41598-018-36058-z"> rticles/s41598-018-36058-z">
<front> <front>
<title>Quantum Annealing for Prime Factorization</title> <title>Quantum Annealing for Prime Factorization</title>
<author initials="S." surname="Jiang" fullname="Shuxian Jiang"> <author initials="S." surname="Jiang" fullname="Shuxian Jiang">
<organization>Department of Computer Science, Purdue University</organizat <organization>Department of Computer Science, Purdue University</org
ion> anization>
</author> </author>
<author initials="K.A." surname="Britt" fullname="Keith A. Britt"> <author initials="K.A." surname="Britt" fullname="Keith A. Britt">
<organization>Quantum Computing Institute, Oak Ridge National Laboratory</ <organization>Quantum Computing Institute, Oak Ridge National Labora
organization> tory</organization>
</author> </author>
<author initials="A.J." surname="McCaskey" fullname="Alexander J. McCaskey"> <author initials="A.J." surname="McCaskey" fullname="Alexander J. McCa
<organization>Quantum Computing Institute, Oak Ridge National Laboratory</ skey">
organization> <organization>Quantum Computing Institute, Oak Ridge National Labora
</author> tory</organization>
<author initials="T.S." surname="Humble" fullname="Travis S. Humble"> </author>
<organization>Quantum Computing Institute, Oak Ridge National Laboratory</ <author initials="T.S." surname="Humble" fullname="Travis S. Humble">
organization> <organization>Quantum Computing Institute, Oak Ridge National Labora
</author> tory</organization>
<author initials="S." surname="Kais" fullname="Sabre Kais"> </author>
<organization>Department of Chemistry, Physics and Birck Nanotechnology Ce <author initials="S." surname="Kais" fullname="Sabre Kais">
nter, Purdue University</organization> <organization>Department of Chemistry, Physics and Birck Nanotechnol
</author> ogy Center, Purdue University</organization>
<date year="2018" month="December" day="05"/> </author>
</front> <date year="2018" month="December"/>
</reference> </front>
<reference anchor="LwM2M" target="http://www.openmobilealliance.org/release/Ligh <seriesInfo name="Scientific Reports" value="8"/>
tweightM2M/V1_0_2-20180209-A/OMA-TS-LightweightM2M-V1_0_2-20180209-A.pdf"> </reference>
<front>
<title>Lightweight Machine to Machine Technical Specification, Version 1.0.2
</title>
<author initials="." surname="OMA" fullname="Open Mobile Alliance">
<organization></organization>
</author>
<date year="2018" month="February" day="09"/>
</front>
<format type="PDF" target="http://www.openmobilealliance.org/release/Lightweig
htM2M/V1_0_2-20180209-A/OMA-TS-LightweightM2M-V1_0_2-20180209-A.pdf"/>
</reference>
<reference anchor="LwM2M" target="http://www.openmobilealliance.org/releas
e/LightweightM2M/V1_0_2-20180209-A/OMA-TS-LightweightM2M-V1_0_2-20180209-A.pdf">
<front>
<title>Lightweight Machine to Machine Technical Specification</title>
<author>
<organization>Open Mobile Alliance</organization>
</author>
<date year="2018" month="February"/>
</front>
<seriesInfo name="Version" value="1.0.2"/>
</reference>
</references> </references>
<section anchor="acknowledgements" numbered="false" toc="default">
<name>Acknowledgements</name>
<t>We would like to thank the following individuals for their feedback:</t
>
<ul spacing="compact">
<li><t><contact fullname="Geraint Luff"/></t></li>
<li><t><contact fullname="Amyas Phillips"/></t></li>
<li><t><contact fullname="Dan Ros"/></t></li>
<li><t><contact fullname="Thomas Eichinger"/></t></li>
<li><t><contact fullname="Michael Richardson"/></t></li>
<li><t><contact fullname="Emmanuel Baccelli"/></t></li>
<li><t><contact fullname="Ned Smith"/></t></li>
<li><t><contact fullname="Jim Schaad"/></t></li>
<li><t><contact fullname="Carsten Bormann"/></t></li>
<li><t><contact fullname="Cullen Jennings"/></t></li>
<li><t><contact fullname="Olaf Bergmann"/></t></li>
<li><t><contact fullname="Suhas Nandakumar"/></t></li>
<li><t><contact fullname="Phillip Hallam-Baker"/></t></li>
<li><t><contact fullname="Marti Bolivar"/></t></li>
<li><t><contact fullname="Andrzej Puzdrowski"/></t></li>
<li><t><contact fullname="Markus Gueller"/></t></li>
<li><t><contact fullname="Henk Birkholz"/></t></li>
<li><t><contact fullname="Jintao Zhu"/></t></li>
<li><t><contact fullname="Takeshi Takahashi"/></t></li>
<li><t><contact fullname="Jacob Beningo"/></t></li>
<li><t><contact fullname="Kathleen Moriarty"/></t></li>
<li><t><contact fullname="Bob Briscoe"/></t></li>
<li><t><contact fullname="Roman Danyliw"/></t></li>
<li><t><contact fullname="Brian Carpenter"/></t></li>
<li><t><contact fullname="Theresa Enghardt"/></t></li>
<li><t><contact fullname="Rich Salz"/></t></li>
<li><t><contact fullname="Mohit Sethi"/></t></li>
<li><t><contact fullname="Éric Vyncke"/></t></li>
<li><t><contact fullname="Alvaro Retana"/></t></li>
<li><t><contact fullname="Barry Leiba"/></t></li>
<li><t><contact fullname="Benjamin Kaduk"/></t></li>
<li><t><contact fullname="Martin Duke"/></t></li>
<li><t><contact fullname="Robert Wilton"/></t></li>
</ul>
<t>We would also like to thank the WG chairs, <contact fullname="Russ Hous
ley"/>, <contact fullname="David Waltermire"/>, and <contact fullname="Dave Thal
er"/> for their support and review.</t>
</section>
</back> </back>
<!-- ##markdown-source:
H4sIACw5EWAAA+19+3Lb2Jnn/3gKVLpqYsUk5XYyuXh6syPL7rST9mUsOZ6d
6qoOSIIiIhBgAFAy0/bWvsa+3j7Jfr/vci4AKEt2Z3q3alyptEgC5/Kd7347
0+k06YquzB+lJ+nXRbO5zpo8fbNdZl2enjSLddHli25H363qJn1WdXlT5V1a
r9LzdVFdtEk2nzf51e3ers+TZb2osg3NtmyyVTct8m41bXdFN82Cp6df/jpZ
0BAXdbN/lBbVqk6SYts8Srtm13YPHzz43YOHCc2UPUrP8sWuKbp9cl03lxdN
vdvSd2+enSeX+Z6+Wj5ya54+wYxJ0nZZtfw+K+uKVrHP22RbPErStFkt8mXb
7Uv9Nk27ehH8WVTLvOrsi7ZuuiZfte7zfhN97Jpi4R5e1JsNvet+LaqyqPw0
+btuWhZtN6VB5nVJj03rX9ynXwhWm2y7JTDLs9muW9cNLXZKP/K/oqKnH8/S
53WTVfalwPdxk1fLrIp/qpuLrCr+nnVFXdGRNZv022JDUF/aA/kmK0r38oxf
/tes2cxoD0l/4m9m6Xm7WNervCou4tm/yaoqb0d+vu0K1jzArHMDHFzFkxkt
t77ubf9JdlUs4x/iqb8tqqype7Mu8dZsjrf+teQHZvTWYMrnBPG8KbJFPOfz
oqxpvb3f4mlP66rdlYSCXW/qjbz8rxt+WXYKzG829OZVDhR9/fXpbx/+6oH+
+esHD39lf/7m17/UP3/z8OFv7dnf/Ib/fDZ9MvN05sasq+mmXuZl9EiX59uI
FIcDbGg3q7ztol+arGsH7wVr+NuOdrzbTFfZoqsbgwaDoMuai5xoZd112/bR
8fH19fWsyjAGgHCcNV2xKPP2uP3Vl//8u99OH3z52+kvf/3gn387/bu8Lszr
32SC9ITQJqOju2CO86opNnn6dTgpvwT+9Ch9iLG+fDh98M/8pSMv/udOXI78
bJb+scgqh8e9Y32Sb2mhoHKwxtN6s90R10nPFkVeLfJJ+mrXLHfEGSs6yqYF
v7JxBHXO1rt3NHw0R28Ff5qdANOLrjuwBgOBzA4QPKtaAg+tZJK+zC7T18Xy
Ik9f8ONZmX6bzYm8CTL9xfwpL7p12putt5qT2R+JCBanWUuM9h+9oJMyf0dM
mwA6nLS3rvMZndQ3u828zP/RqzpviFu0aX++IeL8KSvaHx1vbhxnnW9IoDR7
GmC9b4tFmxL40sdFs7ikjVU1Eem6qsv6Yp+e5pCPt8DQjOS8beXb6+cPnw/J
V6m33ubVpp4XJVFiSQi9yMFFj5ucvmjz42+Li3V3neP/aZTjP3/5/YPvH05B
jA8ePvjd9OT45fOT6fnZNH5uOnhutl2uQhbws+CF9HlGvKjKSXK7P8+x6WJB
R3q2zRfFiv4E8Cbpn7Hhukq/nD2YPfzZCC/gg6RVJSFAXtIuSbpim4Sgss8+
c3lAzOV3/KUwXRvw1ZOvfzKIJdPpNM3mhB7EFpPkz7uyypuM5i66gkR2UY1o
eek90t2O0mV+VSzomXV2lacNoQKJ7W6dp1WeL5nfZiktuciIGBjhWihnpPuZ
YrgTxXBDB0G4224SCBR+Gi/b6NfgPk3e1rtmkZPyVGGpBelPM1rZom62IEfQ
bbsjYUvKTX/YlKgyS1c7UmFAEXTgTf63XdHkTB+YalW8wwBX8d6T+a5Liy7N
yrZO8woLa9OaNtikxYZmhdROF9nWA0tW0MrGaMSEVrsqLnYNYxbtv+tESaZd
5WWJR7PlElNX+TVWuBAmQ+Q2S5JnFf/KrxLeArLLfFVU8g0dBh3LplC6BXxJ
YIQyl86Cdk5a4443uqlJcSDAtDwSq71Zs1SWgeGy1GS5oifWmZGSnVUttjvN
LqqaWOOCQEtf6SG1i6aYYwtYwbYBL+HTsFPW42hngmmbYrkk3ph8kQKvmnq5
4z0nydcxVrQE2Spd5+UWe6cDEuwhyPSPaYKZk23eYNGY2QbAsVfBUc13RcnA
npc1Mb6i0iHpnAidDd9m6ZMd84mmaPEwHeGC0J/GmtfAh0qxOHiFAWpUkkR2
zuOaYEzkcvL4yFg00UaW/vwt2Sftut6m9RiBJUJgZ/WqC02oe89enp+9Ofp5
+sMPqvx9+MCokV0ShaVlXV+mdGxYzry4uCBE3Ra8DtLM6btrm5MsNOIsvJCK
ZBU9RzMTtZRlXl3kdrJXeUmMqCF0pZPF04qETmFkHMTWn55/nfTW2h4wENN7
MMeOeC0AL9tohBtPZDqmYwXwx9gOnS+JLpwxccV90pEaIGxmt8WRM04OmE1b
lzteu/IAItrLoixXuzKhvZNcoA3P0pd05m4evL3Mt2W9z5eT/oBtui0zIr+E
yKBjaQLJC+QiyBRNWhJBLfaksYK4sgvmORN+pljsyqwp9+n1miRHxEuzhMzR
C363I411koKXBqvA8MS+iNbwCxkmC3q1LZjPkhncYsiGZ9xlJZkNBMgrmhfb
JqAtiIhBqWuiW9gSGIPZ2jVx8HRZrFZYWjdLBySZJmq3R7DJ35H87AQ/cKyQ
ljUwhKBRks5RzAj/wMVBP7s2b2hFV3V5xbCYwQSCipHj0YqskJuGp43WO2Xa
PNKWzGzaasUP09lDPIDZMUzJfsqXuzLgCbPkxNbmNtWts464JOOSIkW63m3A
OgLAwb+QkprJq6CRs5IFlUOnQIy0Rgk9RjUbYXJ8qjVpI5i9rsq9cbv57oI4
GyQQix/MulwOxQRvGswqN1GTJyIoAEB3IoQveDWvroqmrtj7gFOnn+c5YxxO
HXDsaAUFbZYkSUmYtNx7nKMJ4JugXYCXOFHRhsoToW/Lay3L+pohS1yfeY8j
m2JDVMC8mXQqwBaenSXvA/C+YBavciRfzkhDOum6fLPteOBVmbVrllRlsSjq
XUvrJbOVFgCVI54DRFPp36uGDOgUn3fVZUX2/IT+YPcRvaeqxYY+ETxo8hyH
TpMTDyL0yzbbkvEkkKY0FuEfbaLdbzY53Dvpotlvu/qiybbrPQ2zyOgBqA+F
yAfB1AZb3dL2SAlN51CqCZB7JSkAms9G2DXeJ94XzpDD6VQQRjAAgRjK7Nhh
wgRAW5zzu0saPyXK2nudib4LJd2Bs9EhGKF0vuhMUuAjjpZmtKOZ71n7WIKS
s2ZvKEkfZfMlNDbCHpJLFX5fsBOKZtkQaVwwBuC4uhQaLukq2ZJ+qpuIHb2c
dzQKKKyLFk2ovOqI3EFGNUwA/RnI2eVbxpsNsw0ssesyEv4k2hd8OhfEAOWA
3OJphKus3DF9k7iH+gw9WKWfo+6ymDdZA7UPwJ6kka4Hp59qe3wsFzlxAjrC
WMdLnxKipWCMF2sWysQG6U0TRLZVDzNAjDSyfAnUx4mA74MASFIeGGDVkNbL
kl9kC4OWcVkEJmkNHQRokTeEECeeKEHOo1Spkj/GmtaRD6MeMZwswOiUdWns
JcSqgwPSiW4FSjOSOcnbNYyqMa2VmRt4zjzPq1R8WYL4WDkG2bDCJdw5UkiZ
vBYZiBgmMvGVNv3SCZ57kDQNa4tO9WaOusCDidfD2UIiZSyFp030Mvz14cPR
BK/Jboi5Q4EBZ2VMCzVEFj+kh7CLmEbrGJ8wq4iDdd7mhyn4OdEIqGwiRxqN
rPpRKQ5VpgKoIKFyLvqSYbQKpQkf1oJlQFszym23ZdEbQmBSFsxhYD00pE00
wFMaJJuwLQQDIjaBAncjz00Slbjdm6osSINdE6kRw8jpe93gJMUPSZkRZ90K
JZHFcUkf0len9GvAPOXcVI4zpkNBEBm+yui3f0kC5VA0iAr8q1rSzrzNoMdG
v5PeRdSlqIrnZcvEEKqEzaUtTGbW+UwNYG1m7KSUReFks8QBPKRTdr6q4pZ5
7RunSNixpWELs4xJDoh5KRrPZluwjkNC159ls6uYVdZViL3MxTJwv4uStrep
yXokxaxYJDE1QwMeOQ5BBOUNbirATKdhNTIhs5v4oex4SbK2rDPAuIVTiqBc
CnVCyKY183RQKAnowObwCkni6c9+U7ODVAxaXonv3WJEci5zGrUUE2QNRaTW
iYj86jaPtkHaO43iNsO8thCRAK18S9snzplnVwWtW7dJ4qwDHk9I/4TE37Dd
WWbVxQ4ClDkgK2ZgWfTHvH4HNnFNgF7HQoRON39H9g6rOgGjg0n1EW63IlUE
E8makp7tPmGXR8nqHFEAABcrrHDStCJjiQWBXfvpSJuw4cgKICCqEjRhjl0v
aoUtuwag1UQ8ReQBI6eN0va4KHuIOuEtV3RU4iLyXhHl9R0JOfilLgmpepLz
iWEkWJSp7Vng9KHRl0XrVRAZLtHh7rVHOKHjQC4QfjYQoBPemu6YzhJ7I+Vt
6hTsJeFU28Hr1yb05JMXZ9OzJ8L6EXn58GEGDZnQLHY4qPzlszNkFh2NEA7i
PHThtsmOHdxYOVnoDcElYy5bBVwlMCkDDgQCYIesOyxaG3/x4QOL1ipPxsew
50nopqzlN2xPTkBDOQuZFv8hfidWJouue2zLwtI7SldgQWTltcVS5fWCNhm5
CVgusw/N0K23cbZ5AvyA6KPhGoGVF1zskSVZFWCN7ghTVHnH1MJ439Ww6b/R
7RCoNramzQTvgdGVUPNojqU4hHi9cLY4p8mjJEl/wbEB+GRDfHeyA0TU1HPo
QSsyU4RJCpRAoQRVVT2WdS6ymQ42uwwJIzbuFHCB2YZBxBCR52V/PDlOnoWF
+jW2TPSkLLaduedq8NRCIkqqnu8RnEZsHTyPreahz4RG3VUkz6FsEk+ZMSSe
Z5ejUPD0zPCA/4KYkMHDTlM1CCwEAqzM3wX7XZJFyR74jcxhei7LbHWtOg0B
Q2xJjRQxDTrNCR+dQRq4ekW0p/BxdWtxeEIboNURzyg4Egj7UPYs7JFQ8AIn
2LCGPmetAFYDHdtirXYD5CNx4o6wqpnIIML5nRucFRHzTNCQhSCRd0oAnk8J
wo0cVApj4WKf5jB9CrwkWoeseQ6lpdlPtxB/kZbhrM4My+idTM/p1GRkQ3Aq
wq4Ktf1ruLEGJhY4OqOeWuATda7KQqcQMXSuxN3YphDXv6xJNneqGksKs6vq
2ObyPn5PpZiAN3A4SKAeD6xmmW8M1mKkOK8kHRErFAFsSNtYgg/EwGbiHOLw
ctnAoQb3r7n1aN/XrdpgmNxpLqzHZCvE6aASskcb4GHpQ3utdmrc6hIIo6AP
7joxVonf0UQ0GztWQoc9IUnTafwji5z9qxr+FeGIqpTSOrehTza0BGbJ21z0
mfwdW+JiVdZ1x5pZwyCFngRvhQLSAi8RHvTPYpac7eYtURg7jibEiIXF0HI1
XycIL4TaMJZA+zFVriA1jSQBW2dRQAURr6vMRWniY5qlL/J3Hc9K5HSpDvou
ck51zU5iIbZFRbCCCXE8IEUDv2W5syh3JMcU/uKNYMUShy7qwYwDGezBrER6
YZ7z4Kh++CI4uA/0+Bf8c9s/bPYmiXcdZ8u4iedI7PzCO2KfgRAfjTht2EXc
FputmIzpz/jbnwmdqgOBPSMZnCvsEuoMEYQBd4FWynzGaLNhPknHrAhbdLMx
r5GO2hYte+w3u7IroECJNkgLMc+MGdKyglAFhQNnUyyI29cIDZVl3pAhAjOC
p3U+r4yXDAqFng1Ev1I72g26IGtqwrlWofUplqkzPoR7dwWjAHTjfdvlG94d
JhzbVuYNE4gbJQhgpwagNOwL/YjeArdhYPFZYkH9Y7PPsiz9knFR3SiQ9pL8
JYjCgb5GOF4DOrzIIW0ZZ9lxoLNFRo7zfdi2WDt2G+lyxzGz/rmqp89BNmYd
s/SkGp3JbaVVOQ99mRa9ZH9vO4kHDEdQk0rtx4KpUHQWyEwRrFAH2CVWLyVW
t6uwg3sWgHWabwtvn4YIkVs1z5cwRUXgsLOez/xoBjJ7bqlMaeTh9phK1D8F
DgWspg/ZWfxu0QZ+0+wCw3TqsPZCl96lh65IL2pjB4mbRbRdWWRMIOm956dv
GAF7lEMqW9EdPcL54AnQjuQebrNFwOZJdymaxa4wHcOrLEA+BzABU8vu+LTb
b1kk9meUs4L8NJWtJpthkxOF79N7r0+e62ZZhTgillBtd90x7ZH+k957dvzy
KIVvRpioGAmrnFO/2I1UCRSviowzLjcwsGDOOIcG6XHFduboLf0//+t/y7rx
EH5L753Vp0f0dco05Xwyyx417YXpE9wkBAMAduwIgPbGTBZci4Yw5xrhU7Fd
s21kKnzLx/UaJv9TNvFxpE+9Kk8QefpUDihQ8IWPCdoAI8yvfwFlvVLfpjuB
l2fpvXx2MZsgf3H3bpK+JQqrrwnhT6plUxdLAvLLsyMwHqcjs0sA8PyrLlQ2
q0aZj532aaTVlaz39MNVQWfb/otyZTP5VPc4f/p0loo1Eu5MDj8g9Tb0UiHR
oonMvV011QgNQ9ICzI/SMwI6abESKjP2yQ5mAQvtcLknfqN/q/uJncK0gJdu
X2fK798cxADPzao4/iMrcsh16pCLz5P+sOyDIZ31GSq4GsiSpB+H5VYq33ac
h2Uc7fTVGyOlCecMB6TDRAPjnMZcZmzS1Y1wXyaRrjbyUV7sp5sEtGYqmLkr
aCWktBQL3us5ToL2tkAeFHgAf87480SM7xWrwwQpcYU8ePirDx8mJAkhqTGX
xN+ElRUdp7Gy+EVKR5GBaezmhBocZWUpR/xjUTDswHQZpbD64LFCgi/YIZFH
saKDLy4KpPiAlwnrmDiDzA+YcFpWFr7vXOwiQQnJGQIhPwZjdD48aDMBDCyi
6bY2gFp6RqeS92HHZ5XfBEGcNliqKGAS5WpUawoGamUkF3ph4wvcWv7kSONe
Q0CRxjW2Gpi3mEx2ixc1sIOg3T5aQ0jPs9HNSWSIToJ0KCwjkn4qEneVAu/v
vIMWNjxy8ZZkAMhf7E4MXvXwpTdOQqZy7/ykFToM1QqH8xpx2XHoBjjJ/Coc
bZRdY9ynT3Xg3D0R+2b80CgouFCmKMypQHShLhmfoWphS+lrsMqvFZZM133x
j0np7HPCicNp2fA5sm1xhlSgdV0ukbfDgXpvT7TBbwMV03E2NjhOJN+RRakc
jIWxlWBF24ZVb2ZLHD8QtbfJDXecOaB+u1RTQHh+MZojb5IKBgjpKnZ6zggQ
8hdyn8jua52eBNd+YPEH4UeO8/EZi99YhYBtseeGGIu5sOWS7addTRrg3oQj
B3qZY6/KXOgzSiU7Vb9Q2/vF9OK0vq7kV2TPBwby1DF+zsfdNkjNWfjRJCwD
xxKeZdmF9M3UGe1F0zO4l2TmLDo2D8Wb1Y1sXHSr63zO5uQGmUzbNaidKKkV
t/AvyOoW32oMw77H9RAQHeQYbjAM9EXkqjC7Cdetcitgpq+gF8E7CHw5UY5L
6uX5q5MjWQn9BedL1xREdlJTE/FJli3KbdTkqJFNkrOkdKEueso88yHlKGrz
LEButkjBppDFkDaSLQDfQvhOem6ayURlx0t6skA++dO/7YotIymZHzsURBA9
k1r/8ulzpAz6B5+IDzB8isa59/IJPXddwANO8p0zNmlpzmdv7tXI1dnyytU1
yizQGYNqBnDqC+vYTDriObUtwz+rdheqVSrho4g2pWoNpC7s0vcdmS/XOX7U
YybUSZqYohOh95T9poEvwqXFNLwMw3rBeT03JG+QMnEAhSdxkEkIQSijHy6e
MT/92pR5rE7SD4WDPHKSNeXEHhfhUocCkFi3NhG8Fp0PQrAN5Tgi2GRfsP5W
tYqfiEvhjDV08VzD3FBbFD1JkkBtWQa+HMdjMZwpPRLJdiaSG4EhaGEW8WX2
9IKeH0C0d2fYAsNdRIDwSt0f3oMuGrLE8M4l6CYnG8f1OJ5JCm9ZOOeGBuK8
xFbDQ6fgg8vF1dwig/7Lo/RZF7iyLZ9HAhGFRVIyyZ6zXV1Jlr9ETRLN6/fC
lylqhSw2dotwMEuWpecsK2aemKYPdQnVVb4fs+GdZ40NKNOziRaBv6S4Iqta
pUAaeskE4yMdFEsi1upWpZCz7CReo67ql7KqzJJFwfwbyQu+gTTN/9UDyGDi
g+Cgd6OYcTYQM8C960xWjSxDdeFzVCTI4wMtay2GpimPZzVIlpJbKtCFoe5D
UZI2KOaTZvf6UI+LqCtwkMzlR4eAH1u30sy4vwY47szhYDtKGumzVZo3DYi9
Xix2TW/K0QlZjNU7FCGs65qDtfT3ptWoKNyTLj9uWbhU/XB995x9zOmLkiB9
OAx8xN7Lt/jtEgmqgGvb7jZb9XTzbiVhxePDlHVer2xzqFIySE1yBnoZ0hsj
dsCJjSuEA+eo4aFx9wCC1snMoUbswCMIrct6t5zOs5YzSzhyz4nM1ZTszQ3U
JYvnJ1Yh5YbDQM61BTcXKrwWrgDMqW8nfWbV50w8GPuS58JaNVd2qLRGFFFo
QNzrquYNAIsN2fhE4jYS1CjElcdah8n63gK7+ppD6qJkiF2PcWbpGfTJAPRi
+hLzlqivhb7YQOTIO5xse1KZyLqRooVFU5Pg5tHMrd2bXUGrQWl1uexTV9YT
6ET/Anx27hrsT3S5SV9D58hGX+WcRVERLqLdmHxxbG2hX5vpQlK+2BaKdgKg
oYyL4kcz8M8RPXabNa26pKElsufBgqY0S17AsHGiEs+s1Bi2pyx6OFjD7MAe
UGWg26jL3O9AeZjHSGWNHrcmAZyNf4qXI/bGuUll16pcjYUBlQpEI3A/93BB
5dK9suapj+IjO+Mhegem47LToB3kl8YKiCYDejWf0zmAuZEBdgYVNsisVjeI
TxjiyaY01pSOCLQjBT9b09qCOhE5Pp9fHK7u2K+r7itSajJr9kAqA+wlh6Av
6yUlzB8Yq+B2FjikOVFCnld9/PVHMnYW+jWiQ9e1rKfQ4oNaw2tbLgyVOTVP
j9lYaBiI5smozPUPolr5UNcv0scuMAT9OIgwsweLiG8hKe2mDqmzG6EZzYJL
axbOg9iCE9JwJhphcqAtJk22TYDi1xIPFDtFR2cnSdyI4ocvIj9Kwhm1vrCL
FWw+STam9AyVMitXl9IFBWCTRBBn2bjUcpcJMsg0kBwn8/U7sylxxU90EGv+
Lqu85Y7kDS1H9gaL9xW/OXtMTDN5fTZ9+MuHRANkS4V1cc4285MYjgc6CJzr
eUdmi2zgesAr42w9xzKT5BupVY6D2YGHG2P4EF7t3ZWaONJP1LbUtkeoV4jW
HYf5Yghb4ikxgceaFjPgKIb/XuZeFmU933OAEqSH7KU2yd8t6ABF70RtULWE
nzV4FBPTPqfwyUTlSxppTixvbpNfZPyONUBxjxpnhjU1JQWINJJhmLJNOE9a
Yz0dV5UoBHx+DEZuUDBCI4u0ad2OOasJGbWSpuGiazwsYfQFksUkTQuENxGt
339qsgsuoZWKKNodiL8lVQqODfbQ2jJa0e0hvARHm91WqzwWtX2w/FEpRWEz
wrI/uIQEyUh5LFX70WlopUgKJkEgOTMc+UjvbVDkhm0h+SzQ/o94qqDUFbKc
QMFizNiFxhIyiyZAFbJ4giREbIC9F3lYxCRwW+ZuL8FGdtWWEHQi/iVLXjBD
X75E9ZBy9QOb1ZXHvF3LsYKTZBc2KedXwqdCQPCpi17GW9Vgx2imgMDX/LCx
wRUyJU1BCnl91+blapa+qDtNHwhKo8gkyUokBnXrTStWti6OY/icMqhueOdk
TwIn+0QDviqjJEbLrzmz2hUKb+rlrpTUmEJe4nSfvGQ7Jwl3oZBokaSghW5e
s4nDCHzCP/wAsTGVhOAPH1Kyya7bQeKVpfP3suu5CJN950srnFLdV3Kml2FW
NCfsu1Mx+x7mhNunSuBJkCogkHWlEMwqkIfUtmy7EdnstjiuAU+0Gt8xxQKZ
i4Wki3jr2fzKswS5sWTMT5yPn9fAxuOA84bbGzF82xB7ujCQgHql6kIj1ebP
9NEEGm6LSp5+TYt3Wyh8SNNhyXad7W0NyI+0yAZLWyTZw/WKcL9UWLvMVKZZ
aJWIWzOixIV1J62cmtagGX4dcLlMRpQ2PWqfiCqW/A2qNq889nIlPoPXgVzz
hK2abMEO4qJdS2oFfOGc3nxPRp3akS+PJmmy3REjJaxyUbg2vad2f/icxQbN
9xxIBZeiQwS7nzeFL4c8Yvl+2pvVa0o4AdEpmo1m746CgUdDBLbcJ4t1vuAU
4nu6rSOfRKwFkG9xeGe9PQTFwYccG+rc6R1amWe+V8C4x1GrmCQtkJOuWVtU
PeBvu6yE7GFVKOnhi7quRCBqZmRUOM4aMnFfVkwl1NADkmBRq2pBqKhE+Gl2
Z2t+Lo6uJd4U84bY7DD0hOJd/wVVw9j6kQrhjPZbLC4T1eJzThcPaN9FJze1
VhQoVvJh9LbmKGWei3HFDEblU3CIiTtEJYXQIvSaf3qZ51sbSCR56EzTspsQ
OXZbCQ92WlfHTkDaxIuT89Z/A5cLtIEcicdlJwn5BPj8mmCCwLEkD0zTN+qh
69HJACfHMRGkKlUGAbGCbPpuccfJI09uykOLive3Hc45GUUQ5rg7TcyLXB5D
K9kx4aQnXmi7DrH7LlB1yrbBQsGmhjueCCumpeDgpNDHYNMPPoXajCIBI2Q7
vgTChYqwFSZlEje9MU3NL46T6JmktcREak46LGyrllgYJPm6Jxp99fVVvheJ
FmRNZxyTzOXoSHa1k8RlSMLum6RvTl6fIw/s62KSPv726YQNE64VSN+evEhd
qyfunEJq7NoCsI6sJbltlpx0A+2Hi+WSaBG+IozjG5yfa6LmUfr8385pNaf1
yStRbr45P3+ViuWfJ6yabustShJGavL8yFbNHrl2zvsFr4krqxFpPfBVc/73
0HcjTRicJ8kM+qTHHC2SVohtY4WkmpQK3hWAluuWoxAqsFN1GIRYG9N+/MSD
dZmLnq1TGqRDudmcmMASH4JyrQEo0hgUqPVBz8mlsgEWLtU+YVnsh/nGyrxQ
FF8JA/bTDRbPjiDszxBoYr1+JOPHcXst6qedwu6TgLu2K5nXJH0Resy7DBlZ
bFQ6OLB9qEqr6LwRt6LV+OWtCCOrJfcbYf1N2nlIzSZJ/suEkWri0g30o1Ux
8llqLajq1ez/t3LJdcZ2s43odO+ghD2okh4ww14pTSGqMkfZrcfTJHEWiHvV
auq10NpwhonUpZIwDEU+uxwKZFPycgx9a6kpd78agkxcZ5YsgZK2UMHLunFT
u2iIpRjANRqwVCl4RsKmli2KEsqqOU1nwHbH1OpvOfSc0qne0uoCDaua5VT0
cLbCqs7ThxStKqsSL/yeTZjwCWKo/5P+Jekn/bs/df/uf+IQ74M/P30IiYV8
1hCfu4rbwMLJrvsud364lN7LwbiH/t0P9uGn6I3zPv3ov/fBX7a+O46C1eiq
hlu56WV5wz0ynb6f3vrt4+P7fWC8T7/7Ln4f6zr0enT+7v/9ABiXH9JVxus6
TiPAv/8Ka+BhbITj42gL3303srP3ahbI5/f2sA5xHC8PP8R7iH7jP+/z//wY
x+GPI4PI7z1Ifude48M89r/7P4JRjtPRf25CDHIcfL4KnrBRDowRPJvwAO9j
0lCY++PTfwP6ud8b5X1Alx7uozvQUGswQziKhVXdKIO1yJ/PfeqAG0VRYGxH
wf+l/QGjLz5hlPv9p4JR6D+ajoSPX01HGdH96e/D4x0dRbOZgt9H1/Lephsf
RRwd6cdH0encKHdDl5gWh4OkERaEg0TscxS2OsgQkPeDt7+LBgn/8RfHSZ/0
/T9POfbEKPJjCPeEZQr0Rzg8i42gD1iKwXAAe6KXoOAHGHDC4wHtfze6jOPj
iDXHf/T/9X7Ax6T/+wHJED4h/0Rb+uFR+kXgz5YOuv/tZ2GgdPazD0NbNW7x
oQaCs1zZyTffkVLOQRPUzqIhn+SX9dqViKZrNhVrtObvkMZ5GCDUBIPBJ2Ou
BtQe+Qyfnko+k+JbDkprEozzrkgQ2SUMqAs/bEgIy8JFf609jYtJahM2fajj
RB16fal97vqOdUuLdh5bi1ta7olY1GIcQ/2/tnygvi95TQ/lZNxxLU2CGDAS
wC45K6pdA6wNipu08j80Vr1T9nG5y7sa0D9D5iyCZSdwUVWZOFQnsWUjVe7O
brYT9s72fgBLXFrSqkoB3ju9MGlHC4doQBeK8WgD33qipnnlfX/qrgwrVAbm
Pla96Pg4irh5jkbT0O5FM8RbbXYkTnyOMrRBxg+dhgaRLM8jQaTQ0nxCSOHG
iNxnnmuwYpg2O57/w/ShuebqOnaTkzlHB7wrlxKxl3646urq1/NaWgtnNWnr
TK0ZCoBwop2P6Nc9915WK3hLZrA0FqOt4FwA+yjbxTtXXStC3hdHfrW/yFgJ
tVZiyfZ9doBbRhF0mPPRo21TiH9Ok0etMojTDJWQ9OysC6NLP88W8PiKh4WT
lAjYW+tBMuiHlb41unPjIojSi1ZoGzbuj5w4O3p4mot1Xbe+4YobkrNBW01o
lTHF7+qecEm6sqAsWk4/FDNJ/HK8Wd9PGczLsg2bhgqHqYNVNeqM7/yqeCSL
3ye+uKQe3/FskBJsg0vVeZXAM3j85exLTens88kRYM/SV7t2rS4yM++GzhZb
0yvaLoe0rZW4+oa5NZIXbdpquZ7/FUUBUeekPni9E/fZ6sBBI20paIGWjWbS
VEshR7Rb7erE2sMU3SSKuXY+SVo71YtLEbECXNGgIRB282RFp9k0lvHt87Zj
rzne9m720Fset/HV54J2OFkc5DvUtacLWFaSqEe5qYl0eVPFxm7n8DyQ0/Y4
90bBikynYPx9YuEa7u/Qa0dtZSMBSrOrMlvlUbraswCWxh8grsWpvdAGMBIZ
Fk+Tts9TlcWC01EeLyfbL+oL5My6MEicCNdLWUtYgOERadepx0SIwpXa/aR4
E6WswRiMi6BhnjGVeFLoIxYlj4kxkefjasmidXybZYOkJUmSyTAvSSKN8kKj
daZlp9EjbmMziCQgaM/VkOzaTaydG7N4rHVFLN7LC3Mc+xw3BKoR08BzmpWj
zsHEpRvxC8pSlzuXe9svd0BO4DMCzaU94HjBD18AZLLiD5b04Wsute/O3LXU
R7NZoNqFtH4d00v7KcZJPzHhEAcdJvYG0eDB0wkYj2aBaTPCuFxHNp/HizkU
tys6nzkGiGgkfsjLNBTBMVU4BRh7xFvt0RNRKxXsQWoRKq5Bepa0rJcv+FRY
p30Btwy6XDxBg1psvSe9J7g4aqlt/IPCtDCnxhr8aLtL4ktXRZlf5MdSNcj9
JZN7EVRY/yvy5miSxMnfIUR+HrS4RqTgn3wnXVeSLpkrjHhFp1c+WHVxToJm
ui2zxaApjmoZrvExNxCfg7UZFxFGlQQs4F5bbPiiqVyaZodADOnynxzEDFJ4
QmCTONgIVI5kC5qnxXJYU6zmWqHCzOmeh5EoNrJjl1jKmHOku08baKcvz0yT
0qCT7tBWHar3hspWK+HGx9hxdboF5F6etQZD5L7Q8YT4hXVdwpgrvaLPi+Wc
Od9YwChyMI/on551hGzaBY5Q7cft96WFDrelzjVvKyiM4F7aiVHysD2PYx+B
pNNG0FF7WUsJkwHBoZJRlA6ypX27bFJ6DjRZF2N+OIrM5YKmVlVi5o6DAifo
GCT7aXK+356aEsJ7xIPQ5oNRJNVjZDViGrMk612o0h9ClGTco8GUlwyt7XE2
nl7nQc6x78w2VIQFOUBcZbYN0/lHWP6AHduO4m6oUMG0qdp1zdoJoTf6LZWs
G56MnDLLWU1zHWf4IGHYygnfZ2E5JkPynqVParn1wKeR+0ZJUkmknSl8T4SR
KYNOmSPrRb/4KIuUqePwBhR1HD/kCrocXf94c5CO3H+TYU96EKfFSh8c0A8f
/tLSg2w3ieUhjK+Ri/WQEj/XgrgolOv6BZovo4/thzUUPsSo8au4O7JBE09p
7ZO1MYQtC/B4jCdBgdILB2y0xI0mZdbSB8+VLxGOjTT/GPT/jVOGUZqn3UdF
5vjkaNUogt243G7jF2P+LufhQAsRzZUY1FdgPORoFVk50boIqde7LpBB17oO
AyTYaDWcB99zgiGxVbIYuPHmELyeXmOq5KtWKj11dTT1tmj5Va74wns+4rFg
J3g5ewM4Jr5jWpzjTl8EHabD1oOcKJO3N5GfpHSj4gb+Ppqh84InqEc7zMJU
DljWQSLq4c0bMSWHL/mJ7uxy9UwJJg88z5u5AVt7s8M4tzy6sOFle2CjvtoL
egLfbZKVySLKcRi7vie28hKoFdJzVkGEpsBo8hn1o03lIgQWq8pV4p7D4T1P
0o8AZOqLrMhA8ZN+YAWKc6ok4Qjjcb2ott/p9GKiulmKnF9z7ycpaBXtWKVi
0N/PJ+ZhKPBN7/7IbNRJ38qN0lvFSZmpReucd33+py5MlOZaR/RU/SrByNaW
M0DXj4zLrtcrIiNkpo9xzNZTndXgcWUQX79wXSc+EKHaFY/gjHWuHuDxHT49
Mn9Mb/HOgYllcv9RZOqGHtFJGo8kxQtd9Gbg5mag9t+ZJY/rztIP2zwIpIge
JjpvkArG/DjMHouzJrUtJpLaiaYD/tN2sRdfAXfPrnGBfYBODQez/2MZ8Qg5
c1NY3+0QoywSEhSprgZODl6wgIgtAa73HKJDp7UXzO1hnEqd9GFhxhL4jNur
jQabGBX16iNOPhb9gfV9Tvz0HmvVdK1zAUexSMPebWPJTYS1Rhs7r1D2tQXj
pKyLQbpK0TVXV2lBBl/vUzTL4CYSTy8Hh55p63e5AWOcqzM6ak4s1//X2uqr
bwTP4iTI2Koz4yvuuC/QMzRjRJoizxYthqfcg6xvgtAUcoJBrxorBCtN31Gc
jnwWSlUJ2iIPF2LeJzkqHO+BvmcD1UfamPRkPet91i8yku7warlW33YJ2FhD
lTO+tYj9Kcie75cb6uUnSKbb1i3bOVNEnSSE0mlT3HHW5AJoHAQZRZPDO05c
hLUPbnSpOfyelM9Ld+6mzVC06iox1aPTDlSL4G6AbYMyMK2t9R4mW4Q4eeXu
Jeh/2kKY1Z2llx+D0rWJ1viRpNvYhX7cVHySuLKqILAld0llrEm7oIAtOxh8
yyGfLJE7UbV4umgvNbwdMTNXohm7VHoKZueOzWscAixXdxu9wRU2rEOMnbwE
DyPnZJqKjKtqOEcIqKWnLG7Jg+JJ5bOWsakV4q4xeBpX/4mq5Xr40XpOo9/9
tVpMMGuUbrqWqpOR/o6Y+h7HD/p3sR1NbqrTbOUt9xJvQd6L7idxdyvOHPQi
K4wVKXbNjLQ+9MWknTTVGax/lt7rhdhlRnFSosmljKRdeTGGj4bfUIV6ZKv1
fI4dOt7uIq6HrODQmCdGW7qGm6YNBvTLCGGE6LIGzJcSBZaOrAWsFFbgzXad
NeKdHOuZY67cfr2Uc5byEDJHnyf0TUKuwRC9U/vs8BFZsx05yVfcnksBsCE5
szO9HB2klejFBwY1Vy89smtWznJeUNCVcXDp/YcP0piZnVh+z3Tidr3Z0RhB
9nU9Kw7uSZmJ0xgO3NSn53WdtZaa3r8iJIvvr7zk7jiWzBcvM/kCPexy18jQ
AjY/fKHNGIMLY1LCsdJ4Nzcjs06TcV8F6Y9mPY1L3Bye+PtoW0LUBYf7fMM7
tOZnC5ZHhVfwivvdIuUCTAU6QuLuXu311wp11PDi2xbthAvhOZnyzUTb5tot
BlwrzXfVmnu3j3vhwU+G/kGNGcIydcbjJPFpK8zs84oDq9L/yNGpu8OIj3qz
qaux1pZo/ildsAk2skS+DyCHMs1JSUJf3Lu67XSkSaz4Bw3qEtdVG4Yfu+6E
8eCGOlIKgpbXrbTmpeWd1aetyVuUX2pnOlYAM7mDERf9BfX4cqFZrbVmq+Kd
Mh906kuswQRah3PzXb00WEUQt7clYcyEEh+2s34SXlIRmIvbhujHescXwXKd
3xuHxHGXe//+7NXRLNELoVkpIpWKeCQUDJ7VegIIP2IFa8RASMLSRLMNuCJd
L0/1elNRKXhEq7BRE00pC6xjZ336m/cGo+DWI27GAV02GS4sivN2kSnMOv11
tvVqXLWMQzYR0p2+eiPocSbqyjR9AYwv0+cA8yvgfCdNO8mOrFRdjy5nCJsj
ZkKUKAuL7kqUwixc0Iq+nBML3bVuDYQSroqJTQ2sS9MKW1OmkKW1DVbEFwVv
1IzTOkDrWt+LGdSqO+Niz6NEDnRZSPMWVoJVW+M7qAQAKF2dmSRm/dFjHNke
cKcaQ+e2i1bZn/Ob2qBbf4iHfKa3Q0RwjG6oJqVqmbfDWV1ADQdKIErsMnSb
1CWJmRDSVhy15mby/V8mhYFpicWkw4qmgOFGfi/VrHRoQUCzSxQvvdnCKlHQ
bKZ2FWDS8OmC5XySdfXGWqzSY0pZzvMadhP3pcuCwU5tfG7GB4GkVXdakOHC
rIRRzmuabK9Mg3wRRbYJ7pNFOdUyGXRx8VkM2snFN6LhHLiQma4au14n4YuR
EG5lbbF0ijgZM8Vu4wdtsuv0xcmLJ8pIYNE+f35q99ozDWus+2+7THpT0Ula
WpSIyTZOeZXFcXMWdvYmFgxw5hqZjUUetHUd6d6l7i6XG1kjXStIBeJm5DVr
QtrylCEQXnMcqEnK0TO7Mkic0O56sCGv8y1xzbHsw6zQPmg1gEHjC9WLg52R
CHvXeelwK1DerqGejPRMitPAOAyumT2+0VhLwOQwHh6dIv8p8deOahvBfoDD
CuT5XlqfPyE1tq7dI0QHk7ylFAjmP9kRGvHNAlDNQRnM9fRuopg9s3srCP2s
4eKtwVTQIRkEoyJNeDGuQOAEKR7ZsVO9v5v2TzIdJsIfjCsZs2BeNR/c5aiX
cifYBHg6C79dxTePiZKKY1wYFep8XucBW5cMbJXkzMlnyRvjkQ6Q0Kh7UfiA
Ycol08Y39XIB4sGtv5OCbaGeVAyYax/0IlLmu/YTwa7d+snAUbwn6oN+pt1O
k/MeWOM73wBiZDoEgeiNS77RlyTuKUlXTumbsBsEyeYR7nixxJDUxUHE8GC+
veSgc5vplX3xhRG52Zv2CWKy7x2D215wfUio6zGg2Sqk5zRb1WMBHxMnvKrb
2+YdOQ8Wt9CcaSV2dQQp75JobNqc9TN3o0NDNtJNopxmTnGNcUdvYlHLrJVe
TmE/MjNSxFfIZG2JrnO3/KVhluRRCiNjISS9yJL46dTLT1rrY9+qI2rmIYkU
MrV31QkWykjGe71aE4zMIdE1uB4yUy6kHZ9VZorAleBU3AguajYh9cPOKzqx
cD6XRV/m7opSSxdtEwkNm9CfumZ7/buo5Wannqfe+Kk1tXJ3Nbir4PrDuA5F
pd4ZFj6QW1iwsKau/pIpsH/Wb8MX5Fpowyz5LvA5oLXqNHh+ys/j3hXrQcG9
yf+6a4M2ICxVmC51OSP26s0z2mPq4bD7lsM2C0Qo4T44CseRu2V/79xOyx0P
XqJh3YVY6o1X2aZnqqiOVln09vv0ieUGvyfu4yd9atB+n7yXeqdHQQUZqvHO
JOj4TH13nc/D7LmY/jtX4t3yGoEYdTDPN/2IM2eeuE54/x3VcE/6rkGe4vnJ
aeoCjiMWHEZ/Uvdv4TCnhBXiB3fGYiendbXU6+tZPP1ZbqZ89mSSnrIi8ewJ
T66lbvQJ0zxrw7Agt/FNtTElZ07jQp8QXmesusJRKr6WPs7f+/KIx+VKBg3/
BnDTxbsZMeRbJLYL/8ZsDFpCt9u9/NwT2wY3h7Y6O8mTy4Kvxw3Oh69MZLTt
8O4b7uAX9q7jzBW+mwNVX+rgmdmGmjxclIJs7hv/YswnoSCoLYgVd7jtnfab
188ARreT0dkCJNNLgfg01Fz41pwEGP7UVes8s1wErhLlksCIJq0osF8oYaTX
coUgHWlwM0KvgAsVQuVStAsJWY/2yEhcEjgSqcjIujTjuvC3L7Ox44tEJAST
XO1KqJOuXZNzXvTAKBd3cAeqIPeSjCPOJXK5wmENAfGZP+X51iUeSy6oJvnH
dxgPuku2uIgCFR2tb4eViONLL53Kl72+xc7700/ikZlRA8GGkd7LNNqG0dIm
www+a67ou52j3oZLvnzXEX/fk6je7E7mE2GNo2/b4TyxmNgRIfLUjFLrBLIg
bBRPNRcmonUnB6f+7t9JLAjR+XA/FzFqT79Z8mrkLdwGLNC06iTXdbfvH5ek
RPRT1+Qsp/wGinZ0W5K0wqn5mhHuxOLbJfquLWajja7ObhoDISS3umjKrg2Z
k66/8tdzuo6vK7k9JLtwoXI6vcV+odlYMkWSDW7GCpqAS48vua+P75nCyWtq
CT0qtQk+rmp9HX1HGXoo6p42dpyTxN3KmWnreS+iJyrJxT4q91HfK2xK1kZK
0fnJz+2GNd/dyC5j0FAWv4DnrJGrT+4IjjNhm7poltLxUUoOuWjopnFHFh/N
kAQzpP0ZoOeyYxRw73FQxFBa/e2DZasNEhmZFt6lIYMrxGp13cEC5sIkaYOK
Mja4RxsV0tqFx78njDTsbiSXTIAtkya2yJu5tS0N5Job9FFQzomcfLtw0he9
JnIViZyQ6/AK60auChjMrEw8jvAl7mBw39rYiO4y36+lQCjxvtmbIodipObl
1kkFCW9m0h/Zl5D4Vp9PqyXa/uXs4LLOs77hJU/S46ThCpJDVw+cR3H8qJtZ
I6ov4x8eONyaL8iQPtRCGX59x/o1b9q50YznulvhgjCzpFMHkZWgBm6Yq625
jvvE69j3iBkt7Gb4MYdh0GMymJuQSAZjCgiFFWcn4kZMi1zH6rklrL+o2c2f
uDHcIthLqfXbXg9zLXTB5pOgj+7MqzouwjMszxbgcxNFvkaDA7O+IJyVe09S
fngT2UFfWr2hN7aexOIxKWD6r4urh31/TaNxLJ3DIOxSaGvXQaDgKiR6f1qv
pnNWzbJ2bSojd01Y7jpXKn3TvWx8K8Azq3sKu6VF2FPVIb9kDOKCk32cjtLr
leBKUGprTBa4BbLByQS04E0sM62SAfE1ruewpX2Zv8NjhizeJYskrNVKIXh4
364e23w/hPxskFCijplCuuTlESrEF9mFewI39DkxMytuZazov2QSw/po3nSA
yceRwhXh38BY5faPEV0swIh+Uod67YPsV3Vhq1KZXGd7z3zYExxlMxofvAdd
SlM8ffMFhf8kkVCd3NRRtsK+LOXC7roPb5eyC5rJbsMzbJtwCFBkqfOtCJSP
/a0z/V1kqdsADZfsWunvAUvpVJvfPQlbnrywNosk3cvL4JJfYuDDrpDt7Bbw
7jPdwP/xUVxc4I5W9hDlx8GVvOy5QwMNdQvTd8nYHX4Y5k6LA8u0hBRur3ly
yFsV9ZLxFHeoC72ka9pHjq/BLc025CzFfSA1x5NFN3p9djJlPvj09NSunzK6
SySQbEIJZVlOY5NYJ0fcdpsp+FWptyQBajSp3fCilSKrnWSS7Cp3KXUvEV4a
+L9++VyKyrXFp/AizQHtpjphorqPZ3y2VFPOkWjX30+rBQi/+c1vP3wgYRcW
lCqaaKfPJpe6YvO/C5fFPeELMUzghXbRwURvRnRaD//KlKmpSB+Hk6jtRBC0
SY7Z4OqKjbD+LrXpELYmfjZxee7RTNzkeZ8EwGfq08lTN7k6MDlY+Y4noa0+
fPDLB5NUIEZswdLX4PJA0gKBzjaB7CWnhnAlx9sotVgsrpYbKlQ1oR3wc6zO
00XXBPiJa91JmrMF3TPtZXTFEeJ8G10LYKqQXuYnljanHWqyUFAA4eKlkzC7
WhO+w7h4wn7PfeCdDdInWU/ta5WZ96lYsCjO8xjqbjIFF9Da7UQACYvtHWF9
U+71mpkguBUO6kvTw5b3ydzdd2QKlNMKrcKpaNJI54uaJ7jLG+RCzfDCBbsO
fB80qBkU8Cbh/TfwPQFhF3yxz6ohft7s9CYJPeoBaELm6lpWz3pBuEAxVJ2G
MIQ4IXGMpbS15W4nA6tzV3GNXMcd25V9QJGBJ6RfbWsXK1ROle0vatBMKgsX
JWrKFvKyzTWuJS2VzBPC5nnGfbSdjhzcWyiOuLpZFpXmWfKJa1umYX/vIHJn
GR7BOSd0CMjSi8tkHN5+kaZPtU7ghy8UG7hFhMFjKjBE55iy3JlfivM35DVL
3gUtJquovxmTyLCLTSxDnQEZWkrabJzLbevgTpN+Ox3oDGHrLr00Xvt3bRAT
bqyXbtj471C3v4+0db2fhD0Vo/aivjNh2CLQp5j6tnXwdWtj3LjBomvION4v
MmoB+r63naBNabzAXhvN977q7j23/QzbGR6AyaCLZtSXsT9INH/48ebt3HKQ
sW+DPo63HOTQKd+3QU65tCqA3Mggg3PTVpjvdZBRSN55JcOd9Lf4l5/f8C/h
HqEfW0gfUPbHLSF68+tv5Iaew7C88fUhaH7/n7l4RYSgLfRnLP7+HV8feegu
r3/1o84ePXib18/0mnffT/uTQXc/fvCuix90k/3o61/9iLP3HrzN60oyPw7W
Kcm8CG5QgUlxx8WPNHy7/esHmFyPnn8U0N369Wda//2ps2vc+BNfNwT7T9j7
v+1QvBkS4u1f/2rswNyTs89b/G1ex6WfB5jIR1+/Edk+efF/Vt/oJ77eu2Dg
jq/HLOk/m2S++nFmvwXkX0ucYVRp+OjrPzHSMsoGC7/b6/8gpBX/+qe+3t/N
fyHtrV8/46rX/4L8p8/+nyBl/nGv/zTaxSn7gT5Zt/k8xWzw8w2v97PwbOHL
27w+yucHDP8ft/jX3KfyE1+/ce0/kUo89vqNDx54XQHzqbMbDH6Svd+d3uHC
GV7oIddN3WqEs/dj376/wxqeyggq5T9lhFMZYai23HqENzJCDxJ3GeG1jPB+
8Nhd4RCv4fd3GSH97LN4LCOcILMbLA2G891GePnZZ/Hys8/i/LPPIv3ss3j1
2WehGAWft57DXUf4/LM4/eyzePrZZ3H22Wfx+Tzq8/lk/O1PopjN+j/f8LrG
fSxNOXKgffT1f4Ruc5fF3/TPv+5uXepFC4MiCzLiLcD4NaL1UhLX0/u45mIQ
c3z44QPKQa413Cj5I5pAiHaNre9B27sL5G9wefUyCa0281B/nlnyLdr+Tw5d
dy55MEHXP82ylAIHtBTV4HfrjlwKRWg9NkY3aC/k7gVBCU626NrEdUXy4V13
dUbYRO08LKoYdFiO46c+eUimc2XCiUZxZ8G9MFbzou3I4+qNgnsi4m5465jn
bnrSYoUh6OI4r8/rtRfbsY4eDgw0YgDBf5/9j9l/pNkKHWz9TQCpJixqHkGc
A3nmWnhJrF7ay0sln2sBqvCT9KIk6vsuuIaa9coVeBuUmlw6cvC7fjl43xYy
ChG73tXzQxjJnxiTTl0kMu1Jqzgo/ZEArLuiT0c5EJV+f3NA2QeidZSDYemb
Isq3ggu/dt9dhvh+GFIeZWYDOfq+dxdi+NidRonuQvy0UfqXIX7aKPafOP3g
bqN8NK58q0EOPdZ/X4IUDrH+rOT+0fdvJA37N4wYD+YfzHwyezw7/fj8N8tp
+/fx+Q/O9JH53TdffcXdqTgvEGVnze9/f6f3P2X+7ycz+ve9+7b/+eb3Jz/X
D38RxaT/+SPv47sXqtObchp+/tj73wWhGNxv+V3A1vr3XY6u/y+y1e8nuvD+
54+9z+/8PH62//lj70c/4BoxL6lv9/6AsX4i/Ryc6Q7rx7/R7Y88dtf5R6J2
d3p/JGx3l/f7LP2T4We8/Y7vf3X7+S30tgpM3rucv2hoH1nV4fdvDt7dYv6x
f3d533GBYCN3eP8npp+D+N9zDd71/ZE41F3e7zGZz9z/+0/H/x9l/k+An4YB
P/n9HxP+9z8T/95/Bv/5MeZPf4L3z/VeySC0cZf3Bwzh/7f9f//9bKaLh4p3
N/k7mfbF+l+ms7uMoN9pT87HGnW70yZoxsF33x/fEQx/kd3j32Qyo239aMfQ
cxauRoTQTe//P2OG3PX9Qx7Eh+ZClOsqbutD/IJs3pMXJ+xb8DfdaEc6d1OQ
649g/R648Ehas6PoA0NIbcSZVcJ/ZEB/gSYXTeNC8v0kbhbK1XlxLQ9fhzS8
62kV91A5X+fWk94VPtvEchVGk8/3yYq+kxou9EFAESw3SdP1x4NyyWy/xNUX
+yfS2JFvYDOfZbXMmqWVMcXNYbRlEBriojHjMt92ay4P0QKW6NY1uectBKbV
X0eQia5NL27VK4xP7GSB6zzKfCnFNHRSb1Fdh5ZCfE0Kl/dm1aV4S11bAmn4
4epj0Pgzz5e40YQ7BqR/yNHdpku/3a1W+Hyy2Wdt+mqNBuHbFt88obN9XfOf
5+t6Q78+LRbor5s3+O45fcjyMn2N/zZLmgzfPkX/ph19/Zhr9MoCX76gHZ9t
0F+FPvyx2KRn9Eq2xKfTrGnRwfQx9l7xEKc7tKFL/5gz4+D5X5bZKn2cNxf2
zNkOneVe4Awvd5uMF6RrT7/B1cGb6ePsUheKemKaoCyu5MGTatn8Pf8rWZd/
Xzb1dXtZ6GOXuzb9Ay2+lBe/yQmqj4vmcl2Xf5elV11Wp/+x3jFQaIJ2XeC/
GWo0eZQ/Zot6TkvF0mt88aesW5doYfO8bgrU0OPLx3imKdpFnePja4JuBXjv
y+Kaf6dHK8BmC3Rp5AiIKNosfVpdANwdv4dGcmeZLO55TbhG5N3JQp6iB+6f
99Xikqc4KWnzNQl7wvuMp8iaZp9+mxfzLOXPefVX4DcteLm7TB3gaF27S13l
PG+69G1RdnTWHgu5Q8EQFd/+AR0Fi6adpK93bZt+g+tNc+IhT7KrYpm+zUrm
LNqTPXmC4rzzdca3qHqktWJhdWcXfIdmkV/z3XvTKV/Rk/xfwhIg2hzjAAA=
</rfc> </rfc>
 End of changes. 123 change blocks. 
1467 lines changed or deleted 863 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/