rfc9397xml2.original.xml   rfc9397.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.6.6 (Ruby
2.6.8) -->
<!DOCTYPE rfc [ <!DOCTYPE rfc [
<!ENTITY nbsp "&#160;"> <!ENTITY nbsp "&#160;">
<!ENTITY zwsp "&#8203;"> <!ENTITY zwsp "&#8203;">
<!ENTITY nbhy "&#8209;"> <!ENTITY nbhy "&#8209;">
<!ENTITY wj "&#8288;"> <!ENTITY wj "&#8288;">
]> ]>
<?rfc rfcedstyle="yes"?> <!-- generated by https://github.com/cabo/kramdown-rfc2629 version 1.6.6 (Ruby 2
<?rfc tocindent="yes"?> .6.8) -->
<?rfc strict="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc text-list-symbols="-o*+"?>
<?rfc docmapping="yes"?>
<rfc ipr="trust200902" docName="draft-ietf-teep-architecture-19" category="info" <rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft
tocInclude="true" sortRefs="true" symRefs="true"> -ietf-teep-architecture-19" number="9397" submissionType="IETF" category="info"
consensus="true" tocInclude="true" sortRefs="true" symRefs="true" updates="" obs
oletes="" xml:lang="en" version="3">
<!-- xml2rfc v2v3 conversion 3.15.3 -->
<front> <front>
<title abbrev="TEEP Architecture">Trusted Execution Environment Provisioning (TEEP) Architecture</title> <title abbrev="TEEP Architecture">Trusted Execution Environment Provisioning (TEEP) Architecture</title>
<seriesInfo name="RFC" value="9397"/>
<author initials="M." surname="Pei" fullname="Mingliang Pei"> <author initials="M." surname="Pei" fullname="Mingliang Pei">
<organization>Broadcom</organization> <organization>Broadcom</organization>
<address> <address>
<email>mingliang.pei@broadcom.com</email> <email>mingliang.pei@broadcom.com</email>
</address> </address>
</author> </author>
<author initials="H." surname="Tschofenig" fullname="Hannes Tschofenig"> <author initials="H." surname="Tschofenig" fullname="Hannes Tschofenig">
<organization>Arm Limited</organization> <organization></organization>
<address> <address>
<email>hannes.tschofenig@arm.com</email> <email>hannes.tschofenig@gmx.net</email>
</address> </address>
</author> </author>
<author initials="D." surname="Thaler" fullname="Dave Thaler"> <author initials="D." surname="Thaler" fullname="Dave Thaler">
<organization>Microsoft</organization> <organization>Microsoft</organization>
<address> <address>
<email>dthaler@microsoft.com</email> <email>dthaler@microsoft.com</email>
</address> </address>
</author> </author>
<author initials="D." surname="Wheeler" fullname="David Wheeler"> <author initials="D." surname="Wheeler" fullname="David Wheeler">
<organization>Amazon</organization> <organization>Amazon</organization>
<address> <address>
<email>davewhee@amazon.com</email> <email>davewhee@amazon.com</email>
</address> </address>
</author> </author>
<date year="2023" month="July"/>
<date year="2022" month="October" day="24"/> <area>sec</area>
<workgroup>teep</workgroup>
<area>Security</area>
<workgroup>TEEP</workgroup>
<keyword>Internet-Draft</keyword>
<abstract> <abstract>
<t>A Trusted Execution Environment (TEE) is an environment that <t>
enforces that any code within that environment cannot be tampered with, A Trusted Execution Environment (TEE) is an environment that
and that any data used by such code cannot be read or tampered with enforces the following: any code within the environment cannot be tampered
by any code outside that environment. with, and any data used by such code cannot be read or tampered with by any
This architecture document motivates the design and standardization code outside the environment.
of a protocol for managing the lifecycle of trusted applications This architecture document discusses the motivation for designing and
running inside such a TEE.</t> standardizing a protocol for managing
the lifecycle of Trusted Applications running inside such a TEE.
</t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<section anchor="introduction">
<section anchor="introduction"><name>Introduction</name> <name>Introduction</name>
<t>Applications executing in a device are exposed to many different attacks <t>Applications executing in a device are exposed to many different attack
s
intended to compromise the execution of the application or reveal the intended to compromise the execution of the application or reveal the
data upon which those applications are operating. These attacks increase data upon which those applications are operating. These attacks increase
with the number of other applications on the device, with such other with the number of other applications on the device, with such other
applications coming from potentially untrustworthy sources. The applications coming from potentially untrustworthy sources. The
potential for attacks further increases with the complexity of features potential for attacks further increases with the complexity of features
and applications on devices, and the unintended interactions among those and applications on devices and the unintended interactions among those
features and applications. The risk of attacks on a system increases features and applications. The risk of attacks on a system increases
as the sensitivity of the applications or data on the device increases. as the sensitivity of the applications or data on the device increases.
As an example, exposure of emails from a mail client is likely to be of As an example, exposure of emails from a mail client is likely to be of
concern to its owner, but a compromise of a banking application raises concern to its owner, but a compromise of a banking application raises
even greater concerns.</t> even greater concerns.</t>
<t>
<t>The Trusted Execution Environment (TEE) concept is designed to let The Trusted Execution Environment (TEE) concept is designed to let
applications execute in a protected environment that enforces that any code applications execute in a protected environment that enforces that any code with
within that environment cannot be tampered with, in that
and that any data used by such code environment cannot be tampered with and that any data used by such code
cannot be read or tampered with by any code outside that environment, cannot be read or tampered with by any code outside that environment,
including by a commodity operating system (if present). including by a commodity operating system (if present). In a system with
In a system with multiple TEEs, this also means that code in one TEE multiple TEEs, this also means that code in one TEE cannot be read or tampered
cannot be read or tampered with by code in another TEE.</t> with by code in another TEE.</t>
<t>This separation reduces the possibility
<t>This separation reduces the possibility
of a successful attack on application components and the data contained inside t he of a successful attack on application components and the data contained inside t he
TEE. Typically, application components are chosen to execute inside a TEE becaus e TEE. Typically, application components are chosen to execute inside a TEE becaus e
those application components perform security sensitive operations or operate on those application components perform security-sensitive operations or operate on
sensitive data. An application component running inside a TEE is commonly referr ed to sensitive data. An application component running inside a TEE is commonly referr ed to
(e.g., in <xref target="GPTEE"/>, <xref target="OP-TEE"/>, etc.) as a (e.g., in <xref target="GPTEE"/> and <xref target="OP-TEE"/>) as a
Trusted Application (TA), while an application running outside any TEE, i.e., in the Trusted Application (TA), while an application running outside any TEE, i.e., in the
Rich Execution Environment (REE), Rich Execution Environment (REE),
is referred to as an Untrusted Application (UA). In the example of a banking app is referred to as an Untrusted Application (UA).
lication, In the example of a banking application,
code that relates to the authentication protocol could reside in a TA while the code that relates to the authentication protocol could reside in a TA while the
application logic including HTTP protocol parsing could be contained in the application logic including HTTP protocol parsing could be contained in the
Untrusted Application. In addition, processing of credit card numbers or accoun t balances could be done in a TA as it is sensitive data. Untrusted Application. In addition, processing of credit card numbers or accoun t balances could be done in a TA as it is sensitive data.
The precise code split is ultimately a decision of the The precise code split is ultimately a decision of the
developer based on the assets the person wants to protect according to the threa t model.</t> developer based on the assets the person wants to protect according to the threa t model.</t>
<t>TEEs are typically used in cases where software or data assets need to
<t>TEEs are typically used in cases where software or data assets need to be pro be protected from unauthorized access
tected from unauthorized access where threat actors may have physical or administrative access to a device.
where threat actors may have physical or administrative access to a device. Thi This situation arises, for example, in gaming consoles where anti-cheat
s protection is a concern, devices such as ATMs or IoT devices placed in
situation arises for example in gaming consoles where anti-cheat protection is a locations where attackers might have physical access, cell phones or other
concern, devices used for mobile payments, and hosted cloud environments. Such
devices such as ATMs or IoT devices placed in locations where attackers might ha environments can be thought of as hybrid devices where one user or
ve physical administrator controls the REE and a different (remote) user or administrator
access, cell phones or other devices used for mobile payments, and hosted cloud controls a TEE in the same physical device. In
environments. Such environments some constrained devices, it may also be the case that there is no REE (only a T
can be thought of as hybrid devices where one user or administrator controls the EE) and no
REE and a local "user" per se, but only a remote TEE administrator. For further discussio
different (remote) user or administrator controls a TEE in the same physical dev n
ice.<br /> of such confidential computing use cases and threat model, see <xref
It may also be the case in some constrained devices that there is no REE (only a target="CC-Overview"/> and <xref target="CC-Technical-Analysis"/>.</t>
TEE) and there <t>TEEs use hardware enforcement combined with software protection to secu
may be no local "user" per se, only a remote TEE administrator. re TAs and
For further discussion of such confidential computing use cases and threat model their data. TEEs typically offer a more limited set of services to TAs than what
, see is
<xref target="CC-Overview"/> and <xref target="CC-Technical-Analysis"/>.</t>
<t>TEEs use hardware enforcement combined with software protection to secure TAs
and
their data. TEEs typically offer a more limited set of services to TAs than is
normally available to Untrusted Applications.</t> normally available to Untrusted Applications.</t>
<t>However, not all TEEs are the same. Different vendors may have differen
<t>Not all TEEs are the same, however, and different vendors may have different t
implementations of TEEs with different security properties, different implementations of TEEs with different security properties, features, and contro
features, and different control mechanisms to operate on TAs. Some l mechanisms to operate on TAs.
vendors may themselves market multiple different TEEs with different Some
vendors may market multiple different TEEs themselves, with different
properties attuned to different markets. A device vendor may integrate properties attuned to different markets. A device vendor may integrate
one or more TEEs into their devices depending on market needs.</t> one or more TEEs into their devices depending on market needs.</t>
<t>To simplify the life of TA developers interacting
<t>To simplify the life of TA developers interacting
with TAs in a TEE, an interoperable protocol for managing TAs running in with TAs in a TEE, an interoperable protocol for managing TAs running in
different TEEs of various devices is needed. This software update protocol different TEEs of various devices is needed. This software update protocol
needs to make sure that compatible trusted and untrusted components (if any) of an needs to make sure that compatible trusted and Untrusted Components (if any) of an
application are installed on the correct device. In this TEE ecosystem, application are installed on the correct device. In this TEE ecosystem,
there often arises a need for an external trusted party to verify the the need often arises for an external trusted party to verify the
identity, claims, and permissions of TA developers, devices, and their TEEs. identity, claims, and permissions of TA developers, devices, and their TEEs.
This external trusted party is the Trusted Application Manager (TAM).</t> This external trusted party is the Trusted Application Manager (TAM).</t>
<t>The Trusted Execution Environment Provisioning (TEEP) protocol addresse
<t>The Trusted Execution Environment Provisioning (TEEP) protocol addresses s
the following problems:</t> the following problems:</t>
<ul spacing="normal">
<t><list style="symbols"> <li>An installer of an Untrusted Application that depends on a given TA
<t>An installer of an Untrusted Application that depends on a given TA
wants to request installation of that TA in the device's TEE wants to request installation of that TA in the device's TEE
so that the installation of Untrusted Application can complete, but the TEE so that the installation of the Untrusted Application can complete, but the TEE
needs to verify whether such a TA is actually authorized to needs to verify whether such a TA is actually authorized to
run in the TEE and consume potentially scarce TEE resources.</t> run in the TEE and consume potentially scarce TEE resources.</li>
<t>A TA developer providing a TA whose code itself is considered <li>A TA developer providing a TA whose code itself is considered
confidential wants to determine confidential wants to determine
security-relevant information of a device before allowing their security-relevant information of a device before allowing their
TA to be provisioned to the TEE within the device. An example TA to be provisioned to the TEE within the device. An example
is the verification of is the verification of
the type of TEE included in a device and that it is capable of the type of TEE included in a device and its capability of
providing the security protections required.</t> providing the security protections required.</li>
<t>A TEE in a device needs to determine whether an entity <li>A TEE in a device needs to determine whether an entity
that wants to manage a TA in the device is authorized to manage TAs that wants to manage a TA in the device is authorized to manage TAs
in the TEE, and what TAs the entity is permitted to manage.</t> in the TEE and what TAs the entity is permitted to manage.</li>
<t>A Device Administrator wants to determine if a TA exists (is
installed) on a device (in the TEE), and if not, install the TA in <li>A Device Administrator wants to determine if a TA exists on a device
the TEE.</t> (i.e., is installed in the TEE) and, if not, install the TA in the TEE.
<t>A Device Administrator wants to check whether a TA in a </li>
<li>A Device Administrator wants to check whether a TA in a
device's TEE is the most up-to-date version, and if not, update the device's TEE is the most up-to-date version, and if not, update the
TA in the TEE.</t> TA in the TEE.</li>
<t>A Device Administrator wants to remove a TA from a device's TEE if <li>A Device Administrator wants to remove a TA from a device's TEE if
the TA developer is no longer maintaining that TA, when the TA has the TA developer is no longer maintaining that TA, when the TA has
been revoked, or is not used for other reasons anymore (e.g., due to an been revoked, or if the TA is not used for other reasons (e.g., due to an
expired subscription).</t> expired subscription).</li>
</list></t> </ul>
<t>For TEEs that simply verify and load signed TAs from an untrusted
<t>For TEEs that simply verify and load signed TA's from an untrusted
filesystem, classic application distribution protocols can be used filesystem, classic application distribution protocols can be used
without modification. The problems in the bullets above, on the other hand, without modification. On the other hand, the problems listed in the bullets abo
require a new protocol, i.e., the TEEP protocol. The TEEP protocol is ve
require a new protocol -- the TEEP protocol. The TEEP protocol is
a solution for TEEs that can install and enumerate TAs in a TEE-secured a solution for TEEs that can install and enumerate TAs in a TEE-secured
location where another domain-specific protocol standard (e.g., <xref target="GS location where another domain-specific protocol standard (e.g., <xref target="GS
MA"/>, MA"/> and <xref target="OTRP"/>) that meets the needs is not already in use.</t>
<xref target="OTRP"/>) that meets the needs is not already in use.</t> </section>
<section anchor="terminology">
</section> <name>Terminology</name>
<section anchor="terminology"><name>Terminology</name> <t>The following terms are used:</t>
<dl newline="false" spacing="normal">
<t>The following terms are used:</t> <dt>App Store:</dt><dd>An online location from which Untrusted Applicati
ons can be downloaded.</dd>
<t><list style="symbols"> <dt>Device:</dt><dd>A physical piece of hardware that hosts one or more
<t>App Store: An online location from which Untrusted Applications can be down TEEs,
loaded.</t>
<t>Device: A physical piece of hardware that hosts one or more TEEs,
often along with often along with
an REE.</t> an REE.</dd>
<t>Device Administrator: An entity that is responsible for administration <dt>Device Administrator:</dt><dd>An entity that is responsible for admi
nistration
of a device, which could be the Device Owner. A Device Administrator of a device, which could be the Device Owner. A Device Administrator
has privileges on the device to install and remove Untrusted Applications and TA s, has privileges on the device to install and remove Untrusted Applications and TA s,
approve or reject Trust Anchors, and approve or reject TA developers, approve or reject Trust Anchors, and approve or reject TA developers,
among possibly other privileges on the device. A Device Administrator can among other possible privileges on the device. A Device Administrator can
manage the list of allowed TAMs by modifying the list of Trust manage the list of allowed TAMs by modifying the list of Trust
Anchors on the device. Although a Device Administrator may have Anchors on the device. Although a Device Administrator may have
privileges and device-specific controls to locally administer a privileges and device-specific controls to locally administer a
device, the Device Administrator may choose to remotely device, the Device Administrator may choose to remotely
administer a device through a TAM.</t> administer a device through a TAM.</dd>
<t>Device Owner: A device is always owned by someone. In some cases, it is com <dt>Device Owner:</dt><dd>A device is always owned by someone. In some c
mon for ases, it is common for
the (primary) device user to also own the device, making the device the (primary) device user to also own the device, making the device
user/owner also the Device Administrator. In enterprise environments user/owner also the Device Administrator. In enterprise environments,
it is more common for the enterprise to own the device, and for any device it is more common for the enterprise to own the device and for any device
user to have no or limited administration rights. In this case, the user to have no or limited administration rights. In this case, the
enterprise appoints a Device Administrator that is not the device enterprise appoints a Device Administrator that is not the Device
owner.</t> Owner.</dd>
<t>Device User: A human being that uses a device. Many devices have <dt>Device User:</dt><dd>A human being that uses a device. Many devices
have
a single device user. Some devices have a primary device user with a single device user. Some devices have a primary device user with
other human beings as secondary device users (e.g., a parent allowing other human beings as secondary device users (e.g., a parent allowing
children to use their tablet or laptop). Other devices are not used children to use their tablet or laptop). Other devices are not used
by a human being and hence have no device user.</t> by a human being; hence, they have no device user.</dd>
<t>Personalization Data: A set of configuration data that is specific to <dt>Personalization Data:</dt><dd>A set of configuration data that is sp
ecific to
the device or user. The Personalization Data may depend on the type of the device or user. The Personalization Data may depend on the type of
TEE, a particular TEE instance, the TA, and even the user of the device; TEE, a particular TEE instance, the TA, and even the user of the device.
an example of Personalization Data might be a secret symmetric key used An example of Personalization Data might be a secret symmetric key used
by a TA to communicate with some service.</t> by a TA to communicate with some service.</dd>
<t>Raw Public Key: A raw public key consists of only the algorithm identifier <dt>Raw Public Key:</dt><dd>A raw public key consists of only the algori
thm identifier
(type) of the key and the cryptographic public key material, such as the (type) of the key and the cryptographic public key material, such as the
SubjectPublicKeyInfo structure of a PKIX certificate <xref target="RFC5280"/>. O ther SubjectPublicKeyInfo structure of a PKIX certificate <xref target="RFC5280"/>. O ther
serialization formats that do not rely on ASN.1 may also be used.</t> serialization formats that do not rely on ASN.1 may also be used.</dd>
<t>Rich Execution Environment (REE): An environment that is provided <dt>Rich Execution Environment (REE):</dt><dd>An environment that is pro
vided
and governed by a typical OS (e.g., Linux, Windows, Android, iOS), and governed by a typical OS (e.g., Linux, Windows, Android, iOS),
potentially in conjunction with other supporting operating systems potentially in conjunction with other supporting operating systems
and hypervisors; it is outside of the TEE(s) managed by the TEEP protocol. This environment and and hypervisors; it is outside of the TEE(s) managed by the TEEP protocol. This environment and
applications running on it are considered untrusted (or more precisely, applications running on it are considered untrusted (or more precisely,
less trusted than a TEE).</t> less trusted than a TEE).</dd>
<t>Trust Anchor: As defined in <xref target="RFC6024"/> and <xref target="RFC9 <dt>Trust Anchor:</dt><dd>As defined in <xref target="RFC6024"/> and <xr
019"/>, ef target="RFC9019"/>,
"A trust anchor represents an authoritative entity via a public a Trust Anchor "represents an authoritative entity via a public
key and associated data. The public key is used to verify digital key and associated data. The public key is used to verify digital
signatures, and the associated data is used to constrain the types signatures, and the associated data is used to constrain the types
of information for which the trust anchor is authoritative." of information for which the trust anchor is authoritative."
The Trust Anchor may be a certificate, a raw public key or other structure, The Trust Anchor may be a certificate, a raw public key, or other structure,
as appropriate. It can be a non-root certificate when it is a certificate.</t> as appropriate. It can be a non-root certificate when it is a certificate.</dd>
<t>Trust Anchor Store: As defined in <xref target="RFC6024"/>, "A trust anchor <dt>Trust Anchor Store:</dt><dd>As defined in <xref
store is a set of one or more trust anchors stored in a device... target="RFC6024"/>, a "trust anchor store is a set of one
A device may have more than one trust anchor store, each of which or more trust anchors stored in a device... A device may have more
may be used by one or more applications." As noted in <xref target="RFC9019"/>, than one trust anchor store, each of which may be used by one or more
a Trust Anchor Store must resist modification against unauthorized applications." As noted in <xref target="RFC9019"/>, "a trust anchor
insertion, deletion, and modification.</t> store must resist modification against unauthorized insertion,
<t>Trusted Application (TA): An application (or, in some implementations, an a deletion, and modification."</dd>
pplication component) that runs in a TEE.</t> <dt>Trusted
<t>Trusted Application Manager (TAM): An entity that manages Trusted Application (TA):</dt><dd>An application (or, in some implementations,
Applications and other Trusted Components running in TEEs of various devices.</t an application component) that runs in a TEE.</dd>
> <dt>Trusted Application Manager (TAM):</dt><dd>An entity that manages Tr
<t>Trusted Component: A set of code and/or data in a TEE managed as a unit usted Applications and other Trusted Components running in TEEs of various devic
es.</dd>
<dt>Trusted Component:</dt><dd>A set of code and/or data in a TEE manage
d as a unit
by a Trusted Application Manager. Trusted Applications and by a Trusted Application Manager. Trusted Applications and
Personalization Data are thus managed by being included in Personalization Data are thus managed by being included in
Trusted Components. Trusted OS code or trusted firmware can also be Trusted Components. Trusted OS code or trusted firmware can also be
expressed as Trusted Components that a Trusted Component depends on.</t> expressed as Trusted Components that a Trusted Component depends on.</dd>
<t>Trusted Component Developer: An entity that develops one or <dt>Trusted Component Developer:</dt><dd>An entity that develops one or
more Trusted Components.</t> more Trusted Components.</dd>
<t>Trusted Component Signer: An entity that signs a Trusted Component with <dt>Trusted Component Signer:</dt><dd>An entity that signs a Trusted Com
ponent with
a key that a TEE will trust. The signer might or might not be the a key that a TEE will trust. The signer might or might not be the
same entity as the Trusted Component Developer. For example, a Trusted Component might same entity as the Trusted Component Developer. For example, a Trusted Component might
be signed (or re-signed) by a Device Administrator if the TEE will be signed (or re-signed) by a Device Administrator if the TEE will
only trust the Device Administrator. A Trusted Component might also be encrypted only trust the Device Administrator.
, A Trusted Component might also be encrypted
if the code is considered confidential, for example, when a developer wants to if the code is considered confidential, for example, when a developer wants to
provide a TA without revealing its code to others.</t> provide a TA without revealing its code to others.</dd>
<t>Trusted Execution Environment (TEE): An execution environment that enforces
that <dt>Trusted Execution Environment (TEE):</dt><dd>An execution environment that e
only authorized code can execute within the TEE, and data used by that nforces that
only authorized code can execute within the TEE and data used by that
code cannot be read or tampered with by code outside the TEE. code cannot be read or tampered with by code outside the TEE.
A TEE also generally has a device unique credential that cannot be cloned. A TEE also generally has a unique device credential that cannot be cloned.
There are multiple technologies that can be used to implement There are multiple technologies that can be used to implement
a TEE, and the level of security achieved varies accordingly. a TEE, and the level of security achieved varies accordingly.
In addition, TEEs typically use an isolation mechanism between Trusted Applicati ons to ensure In addition, TEEs typically use an isolation mechanism between Trusted Applicati ons to ensure
that one TA cannot read, modify or delete the data and code of another that one TA cannot read, modify, or delete the data and code of another
TA.</t> TA.</dd>
<t>Untrusted Application (UA): An application running in an REE. An Untrusted <dt>Untrusted Application (UA):</dt><dd>An application running in an REE
Application . An Untrusted Application
might depend on one or more TAs.</t> might depend on one or more TAs.</dd>
</list></t> </dl>
</section>
</section> <section anchor="use-cases">
<section anchor="use-cases"><name>Use Cases</name> <name>Use Cases</name>
<section anchor="payment">
<section anchor="payment"><name>Payment</name> <name>Payment</name>
<t>A payment application in a mobile device requires high security and
<t>A payment application in a mobile device requires high security and
trust in the hosting device. Payments initiated from a mobile trust in the hosting device. Payments initiated from a mobile
device can use a Trusted Application device can use a Trusted Application
to provide strong identification and proof of transaction.</t> to provide strong identification and proof of transaction.</t>
<t>For a mobile payment application, some biometric identification
<t>For a mobile payment application, some biometric identification
information could also be stored in a TEE. The mobile payment information could also be stored in a TEE. The mobile payment
application can use such information for unlocking the device and application can use such information for unlocking the device and local identifi
for local identification of the user.</t> cation of the user.</t>
<t>A trusted user interface (UI) may be used in a mobile device or point
<t>A trusted user interface (UI) may be used in a mobile device or point-of-sale -of-sale device to
device to
prevent malicious software from stealing sensitive user input data. prevent malicious software from stealing sensitive user input data.
Such an implementation often relies on a TEE for providing access Such an implementation often relies on a TEE for providing access
to peripherals, such as PIN input or a trusted display, so that to peripherals, such as PIN input or a trusted display, so that
the REE cannot observe or tamper with the user input or output.</t> the REE cannot observe or tamper with the user input or output.</t>
</section>
</section> <section anchor="authentication">
<section anchor="authentication"><name>Authentication</name> <name>Authentication</name>
<t>For better security of authentication, a device may store its
<t>For better security of authentication, a device may store its keys and cryptographic libraries inside a TEE, limiting access to
keys and cryptographic libraries inside a TEE limiting access to
cryptographic functions via a well-defined interface and thereby cryptographic functions via a well-defined interface and thereby
reducing access to keying material.</t> reducing access to keying material.</t>
</section>
</section> <section anchor="internet-of-things">
<section anchor="internet-of-things"><name>Internet of Things</name> <name>Internet of Things</name>
<t>Weak security in Internet of Things (IoT) devices has been posing thr
<t>Weak security in Internet of Things (IoT) devices has been posing threats to eats to
critical infrastructure, i.e., assets that are essential for the functioning critical infrastructure, i.e., assets that are essential for the functioning
of a society and economy. It is desirable that IoT devices can prevent malware of a society and economy. It is desirable that IoT devices can prevent malware
from manipulating actuators (e.g., unlocking a door), or from manipulating actuators (e.g., unlocking a door) or
stealing or modifying sensitive data, such as authentication credentials stealing or modifying sensitive data, such as authentication credentials
in the device. A TEE can be one of the best ways to implement such IoT in the device. A TEE can be one of the best ways to implement such IoT
security functions. For example, <xref target="GPTEE"/> uses the term "trusted p eripheral" to refer to such things being security functions. For example, <xref target="GPTEE"/> uses the term "trusted p eripheral" to refer to such things being
accessible only from the TEE, and this concept is used, and this concept is used accessible only from the TEE, and this concept is used in some GlobalPlatform-co
in some GlobalPlatform-compliant devices today.</t> mpliant devices today.</t>
</section>
</section> <section anchor="confidential-cloud-computing">
<section anchor="confidential-cloud-computing"><name>Confidential Cloud Computin <name>Confidential Cloud Computing</name>
g</name> <t>A tenant can store sensitive data, such as customer details or credit
<t>A tenant can store sensitive data, such as customer details or credit
card numbers, in a TEE in a cloud computing card numbers, in a TEE in a cloud computing
server such that only the tenant can access the data, preventing server such that only the tenant can access the data, which prevents
the cloud hosting provider from accessing the data. A tenant can the cloud hosting provider from accessing the data. A tenant can
run TAs inside a server TEE for secure operation and enhanced run TAs inside a server TEE for secure operation and enhanced
data security. This provides benefits not only to tenants with data security. This provides benefits not only to tenants with
better data security but also to cloud hosting providers for reduced better data security but also to cloud hosting providers for reduced
liability and increased cloud adoption.</t> liability and increased cloud adoption.</t>
</section>
</section> </section>
</section> <section anchor="architecture">
<section anchor="architecture"><name>Architecture</name> <name>Architecture</name>
<section anchor="system-components">
<section anchor="system-components"><name>System Components</name> <name>System Components</name>
<t><xref target="notionalarch"/> shows the main components in a typical
<t><xref target="notionalarch"/> shows the main components in a typical device w device with an REE and a
ith an REE and a
TEE. Full descriptions of TEE. Full descriptions of
components not previously defined are provided below. Interactions of components not previously defined are provided below. Interactions of
all components are further explained in the following paragraphs.</t> all components are further explained in the following paragraphs.</t>
<figure anchor="notionalarch">
<name>Notional Architecture of TEEP</name>
<artwork><![CDATA[
+---------------------------------------------+
| Device | Trusted Component
| +--------+ | Signer
| +---------------+ | |--------------+ |
| | TEE-1 | | TEEP |-----------+ | |
| | +--------+ | +--| Broker | | | | +-------+ |
| | | TEEP | | | | |<-----+ | | +-->| |<-+
| | | Agent |<------+ | | | | | +-| TAM-1 |
| | +--------+ | | |<---+ | | +--->| | |<-+
| | | +--------+ | | | | +-------+ |
| | +----+ +----+ | | | | | TAM-2 | |
| +-->|TA-1| |TA-2| | +-------+ | | | +-------+ |
| | | | | | |<---------| UA-2 |--+ | | |
| | | +----+ +----+ | +-------+ | | | Device
| | +---------------+ | UA-1 | | | | Administrator
| | | | | | |
| +--------------------| |-----+ | |
| | |----------+ |
| +-------+ |
+---------------------------------------------+
]]></artwork>
</figure>
<figure title="Notional Architecture of TEEP" anchor="notionalarch"><artwork><![ <dl newline="false" spacing="normal">
CDATA[ <dt>Trusted Component Signer and Device Administrator:</dt><dd>Trusted
+---------------------------------------------+ Component Signers and Device Administrators utilize the services
| Device | Trusted Component
| +--------+ | Signer
| +---------------+ | |--------------+ |
| | TEE-1 | | TEEP |-----------+ | |
| | +--------+ | +--| Broker | | | | +-------+ |
| | | TEEP | | | | |<-----+ | | +-->| |<-+
| | | Agent |<------+ | | | | | +-| TAM-1 |
| | +--------+ | | |<---+ | | +--->| | |<-+
| | | +--------+ | | | | +-------+ |
| | +----+ +----+ | | | | | TAM-2 | |
| +-->|TA-1| |TA-2| | +-------+ | | | +-------+ |
| | | | | | |<---------| UA-2 |--+ | | |
| | | +----+ +----+ | +-------+ | | | Device
| | +---------------+ | UA-1 | | | | Administrator
| | | | | | |
| +--------------------| |-----+ | |
| | |----------+ |
| +-------+ |
+---------------------------------------------+
]]></artwork></figure>
<t><list style="symbols">
<t>Trusted Component Signers and Device Administrators utilize the services
of a TAM to manage TAs on devices. Trusted Component Signers do not directly int eract of a TAM to manage TAs on devices. Trusted Component Signers do not directly int eract
with devices. Device Administrators may elect to use a TAM for remote administra tion with devices. Device Administrators may elect to use a TAM for remote administra tion
of TAs instead of managing each device directly.</t> of TAs instead of managing each device directly.</dd>
<t>Trusted Application Manager (TAM): A TAM is responsible for performing lif
ecycle <dt>Trusted Application Manager (TAM):</dt><dd><t>A TAM is responsib
management activity on Trusted Components on behalf of Trusted Component Signers le for
and Device Administrators. This includes installation and performing lifecycle management activity on Trusted Components on
deletion of Trusted Components, and may include, for example, over-the-air behalf of Trusted Component Signers and Device Administrators.
updates to keep Trusted Components up-to-date and clean up when Trusted Componen This includes installation and deletion of Trusted Components and
ts may include, for example, over-the-air updates to keep Trusted
should be removed. TAMs may provide services that make it easier for Components up-to-date and clean up when Trusted Components should
Trusted Component Signers or Device Administrators to use the TAM's service to m be removed. TAMs may provide services that make it easier for
anage multiple devices, Trusted Component Signers or Device Administrators to use the
although that is not required of a TAM. <vspace blankLines='1'/> TAM's service to manage multiple devices, although that is not
required of a TAM.</t>
<t>
The TAM performs its management of Trusted Components on the device through The TAM performs its management of Trusted Components on the device through
interactions with a device's TEEP Broker, which relays interactions with a device's TEEP Broker, which relays
messages between a TAM and a TEEP Agent running inside the TEE. messages between a TAM and a TEEP Agent running inside the TEE.
TEEP authentication is performed between a TAM and a TEEP Agent. <vspace blankL TEEP authentication is performed between a TAM and a TEEP Agent. </t>
ines='1'/> <t>
When the TEEP Agent runs in a user or enterprise device, network and application firewalls When the TEEP Agent runs in a user or enterprise device, network and application firewalls
normally protect user and enterprise devices from arbitrary connections from ext ernal network normally protect user and enterprise devices from arbitrary connections from ext ernal network
entities. In such a deployment, a TAM outside that network might not be able to directly entities. In such a deployment, a TAM outside that network might not be able to directly
contact a TEEP Agent, but needs to wait for the TEEP Broker to contact it. contact a TEEP Agent but needs to wait for the TEEP Broker to contact it.
The architecture in <xref target="notionalarch"/> accommodates this case as well as other less restrictive cases The architecture in <xref target="notionalarch"/> accommodates this case as well as other less restrictive cases
by leaving such details to an appropriate TEEP transport protocol (e.g., <xref t arget="I-D.ietf-teep-otrp-over-http"/>, by leaving such details to an appropriate TEEP transport protocol (e.g., <xref t arget="I-D.ietf-teep-otrp-over-http"/>,
though other transport protocols can be defined under the TEEP protocol for othe though other transport protocols can be defined under the TEEP protocol for othe
r cases). <vspace blankLines='1'/> r cases). </t>
<t>
A TAM may be publicly available for use by many Trusted Component Signers, or a TAM A TAM may be publicly available for use by many Trusted Component Signers, or a TAM
may be private, and accessible by only one or a limited number of may be private and accessible by only one or a limited number of
Trusted Component Signers. It is expected that many enterprises, manufacturers, and network carriers Trusted Component Signers. It is expected that many enterprises, manufacturers, and network carriers
will run their own private TAM. <vspace blankLines='1'/> will run their own private TAM.</t>
<t>
A Trusted Component Signer or Device Administrator chooses a particular TAM base d on A Trusted Component Signer or Device Administrator chooses a particular TAM base d on
whether the TAM is trusted by a device or set of devices. The whether the TAM is trusted by a device or set of devices. The
TAM is trusted by a device if the TAM's public key is, or chains up to, TAM is trusted by a device if the TAM's public key is, or chains up to,
an authorized Trust Anchor in the device, and conforms with all constraints defi ned in an authorized Trust Anchor in the device and conforms with all constraints defin ed in
the Trust Anchor. A Trusted Component Signer or Device Administrator may run the Trust Anchor. A Trusted Component Signer or Device Administrator may run
their own TAM, but the devices they wish to manage must include their own TAM, but the devices they wish to manage must include
this TAM's public key or certificate, or a certificate it chains up to, in the this TAM's public key or certificate, or a certificate it chains up to, in the
Trust Anchor Store. <vspace blankLines='1'/> Trust Anchor Store.</t>
<t>
A Trusted Component Signer or Device Administrator is free to utilize multiple T AMs. This may A Trusted Component Signer or Device Administrator is free to utilize multiple T AMs. This may
be required for managing Trusted Components on multiple different types of devic es be required for managing Trusted Components on multiple different types of devic es
from different manufacturers, or mobile devices on from different manufacturers or mobile devices on
different network carriers, since different network carriers, since
the Trust Anchor Store on these different devices may contain keys the Trust Anchor Store on these different devices may contain keys
for different for different
TAMs. A Device Administrator may be able to add their own TAM's TAMs. To overcome this limitation, Device Administrator may be able to add their
public key or certificate, or a certificate it chains up to, to the Trust Anchor own TAM's
Store on all their devices, public key or certificate, or a certificate it chains up to, to the Trust Anchor
overcoming this limitation. <vspace blankLines='1'/> Store on all their devices.</t>
<t>
Any entity is free to operate a TAM. For a TAM to be successful, it must Any entity is free to operate a TAM. For a TAM to be successful, it must
have its public key or certificate installed in a device's Trust Anchor Store. have its public key or certificate installed in a device's Trust Anchor Store.
A TAM may set up a relationship with device manufacturers or network carriers A TAM may set up a relationship with device manufacturers or network carriers
to have them install the TAM's keys in their device's Trust Anchor Store. to have them install the TAM's keys in their device's Trust Anchor Store.
Alternatively, a TAM may publish its certificate and allow Device Alternatively, a TAM may publish its certificate and allow Device
Administrators to install the TAM's certificate in their devices as Administrators to install the TAM's certificate in their devices as
an after-market action.</t> an aftermarket action.</t></dd>
<t>TEEP Broker: A TEEP Broker is an application component running in a Rich <dt>TEEP Broker:</dt><dd>A TEEP Broker is an application component run
Execution Environment (REE) that enables the message protocol exchange between ning
a TAM and a TEE in a device. A TEEP Broker does not process messages in a Rich Execution Environment (REE) that enables the message
on behalf of a TEE, but merely is responsible for relaying messages from protocol exchange between a TAM and a TEE in a device. A TEEP Broker
the TAM to the TEE, and for returning the TEE's responses to the TAM. does not process messages on behalf of a TEE but is merely
In devices with no REE (e.g., a microcontroller where all code runs responsible for relaying messages from the TAM to the TEE and for
in an environment that meets the definition of a Trusted Execution returning the TEE's responses to the TAM. In devices with no REE
Environment in <xref target="terminology"/>), the TEEP Broker would be absent an (e.g., a microcontroller where all code runs in an environment that
d meets the definition of a Trusted Execution Environment in <xref
instead the target="terminology"/>), the TEEP Broker would be absent, and
TEEP protocol transport would be implemented inside the TEE itself.</t> the TEEP protocol transport would be implemented inside the TEE
<t>TEEP Agent: The TEEP Agent is a processing module running inside itself.</dd>
<dt>TEEP Agent:</dt><dd>The TEEP Agent is a processing module running
inside
a TEE that receives TAM requests (typically relayed via a TEEP Broker a TEE that receives TAM requests (typically relayed via a TEEP Broker
that runs in an REE). A TEEP Agent in the TEE may parse requests or that runs in an REE). A TEEP Agent in the TEE may parse or
forward requests to other processing modules in a TEE, which is forward requests to other processing modules in a TEE, which is
up to a TEE provider's implementation. A response message up to a TEE provider's implementation.
A response message
corresponding to a TAM request is sent back to the TAM, again typically corresponding to a TAM request is sent back to the TAM, again typically
relayed via a TEEP Broker.</t> relayed via a TEEP Broker.</dd>
<t>Certification Authority (CA): A CA is an entity that issues digital <dt>Certification Authority (CA):</dt><dd>A CA is an entity that issue
s digital
certificates (especially X.509 certificates) and vouches for the certificates (especially X.509 certificates) and vouches for the
binding between the data items in a certificate <xref target="RFC4949"/>. binding between the data items in a certificate <xref target="RFC4949"/>.
Certificates are then used for authenticating a device, a TAM, or a Certificates are then used for authenticating a device, a TAM, or a
Trusted Component Signer, as discussed in <xref target="trustanchors"/>. The CA s do not need to be the same; Trusted Component Signer, as discussed in <xref target="trustanchors"/>. The CA s do not need to be the same;
different CAs can be chosen by each TAM, and different device CAs different CAs can be chosen by each TAM, and different device CAs
can be used by different device manufacturers.</t> can be used by different device manufacturers.</dd>
</list></t> </dl>
</section>
</section> <section anchor="multiple-tees-in-a-device">
<section anchor="multiple-tees-in-a-device"><name>Multiple TEEs in a Device</nam <name>Multiple TEEs in a Device</name>
e> <t>Some devices might implement multiple TEEs.
<t>Some devices might implement multiple TEEs.
In these cases, there might be one shared TEEP Broker In these cases, there might be one shared TEEP Broker
that interacts with all the TEEs in the device. that interacts with all the TEEs in the device.
However, some TEEs (for example, SGX <xref target="SGX"/>) present themselves as separate containers However, some TEEs (for example, SGX <xref target="SGX"/>) present themselves as separate containers
within memory without a controlling manager within the TEE. As such, within memory without a controlling manager within the TEE. As such,
there might be multiple TEEP Brokers in the REE, there might be multiple TEEP Brokers in the REE,
where each TEEP Broker communicates with one or more TEEs associated with it.</t > where each TEEP Broker communicates with one or more TEEs associated with it.</t >
<t>It is up to the REE and the Untrusted Applications
<t>It is up to the REE and the Untrusted Applications
how they select the correct TEEP Broker. Verification that the correct TA how they select the correct TEEP Broker. Verification that the correct TA
has been reached then becomes a matter of properly verifying TA attestations, has been reached then becomes a matter of properly verifying TA attestations,
which are unforgeable.</t> which are unforgeable.</t>
<t>The multiple TEEP Broker approach is shown in the diagram below.
<t>The multiple TEEP Broker approach is shown in the diagram below. For brevity, TEEP Broker 2 is shown interacting with only one TAM, Untrusted App
For brevity, TEEP Broker 2 is shown interacting with only one TAM and Untrusted lication, and TEE, but no such limitations are intended to be implied in the arc
Application and only one TEE, but hitecture.</t>
no such limitations are intended to be implied in the architecture.</t> <figure anchor="notionalarch2">
<name>Notional Architecture of TEEP with multiple TEEs</name>
<figure title="Notional Architecture of TEEP with multiple TEEs" anchor="notiona <artwork><![CDATA[
larch2"><artwork><![CDATA[ +-------------------------------------------+
+-------------------------------------------+ | Device | Trusted Component
| Device | Trusted Component | | Signer
| | Signer | +---------------+ | |
| +---------------+ | | | | TEE-1 | | |
| | TEE-1 | | | | | +-------+ | +--------+ | +--------+ |
| | +-------+ | +--------+ | +--------+ | | | | TEEP | | | TEEP |------------->| |<-+
| | | TEEP | | | TEEP |------------->| |<-+ | | | Agent |<----------| Broker | | | | TA
| | | Agent |<----------| Broker | | | | TA | | | 1 | | | 1 |---------+ | |
| | | 1 | | | 1 |---------+ | | | | +-------+ | | | | | | |
| | +-------+ | | | | | | | | | | | |<---+ | | | |
| | | | |<---+ | | | | | | +----+ +----+ | | | | | | +-| TAM-1 | Policy
| | +----+ +----+ | | | | | | +-| TAM-1 | Policy | | |TA-1| |TA-2| | | |<-+ | | +->| | |<-+
| | |TA-1| |TA-2| | | |<-+ | | +->| | |<-+ | +-->| | | |<---+ +--------+ | | | | +--------+ |
| +-->| | | |<---+ +--------+ | | | | +--------+ | | | | +----+ +----+ | | | | | | TAM-2 | |
| | | +----+ +----+ | | | | | | TAM-2 | | | | | | | +-------+ | | | +--------+ |
| | | | | +-------+ | | | +--------+ | | | +---------------+ +---| UA-2 |--+ | | ^ |
| | +---------------+ +---| UA-2 |--+ | | ^ | | | +-------+ | | | | Device
| | +-------+ | | | | Device | +--------------------| UA-1 | | | | | Administrator
| +--------------------| UA-1 | | | | | Administrator | +------| | | | | |
| +------| | | | | | | +-----------|---+ | |---+ | | |
| +-----------|---+ | |---+ | | | | | TEE-2 | | | |--------+ | |
| | TEE-2 | | | |--------+ | | | | +------+ | | | |-------+ | |
| | +------+ | | | |-------+ | | | | | TEEP | | | +-------+ | | |
| | | TEEP | | | +-------+ | | | | | | Agent|<-------+ | | |
| | | Agent|<-------+ | | | | | | 2 | | | | | | |
| | | 2 | | | | | | | | | +------+ | | | | | |
| | +------+ | | | | | | | | | | | | | |
| | | | | | | | | | +----+ | | | | | |
| | +----+ | | | | | | | | |TA-3|<---+ | | +---------+ | | |
| | |TA-3|<---+ | | +---------+ | | | | | | | | | | TEEP |<-+ | |
| | | | | | | TEEP |<-+ | | | | +----+ | +---| Broker | | |
| | +----+ | +---| Broker | | | | | | | 2 |--------------+
| | | | 2 |--------------+ | +---------------+ +---------+ |
| +---------------+ +---------+ | | |
| | +-------------------------------------------+
+-------------------------------------------+ ]]></artwork>
]]></artwork></figure> </figure>
<t>In the diagram above, TEEP Broker 1 controls interactions with the TA
<t>In the diagram above, TEEP Broker 1 controls interactions with the TAs in TEE s in TEE-1,
-1, and TEEP Broker 2 controls interactions with the TAs in TEE-2.
and TEEP Broker 2 controls interactions with the TAs in TEE-2. This presents som This presents some challenges for a TAM in completely managing the device,
e since a TAM may not interact with all the TEEP Brokers on a particular
challenges for a TAM in completely managing the device, since a TAM may not platform. In addition, since TEEs may be physically separated, with wholly
interact with all the TEEP Brokers on a particular platform. In addition, since different resources, there may be no need for TEEP Brokers to share
TEEs may be physically separated, with wholly different resources, there may be information on installed Trusted Components or resource usage.</t>
no </section>
need for TEEP Brokers to share information on installed Trusted Components or re <section anchor="multiple-tams-and-relationship-to-tas">
source usage.</t> <name>Multiple TAMs and Relationship to TAs</name>
<t>As shown in <xref target="notionalarch2"/>, a TEEP Broker provides co
</section> mmunication between
<section anchor="multiple-tams-and-relationship-to-tas"><name>Multiple TAMs and one or more TEEP Agents and one or more TAMs. The selection of which TAM to inte
Relationship to TAs</name> ract with might be
made with or without input from an Untrusted Application but is ultimately
<t>As shown in <xref target="notionalarch2"/>, a TEEP Broker provides communicat
ion between
one or more TEEP Agents and
one or more TAMs. The selection of which TAM to interact with might be
made with or without input from an Untrusted Application, but is ultimately
the decision of a TEEP Agent.</t> the decision of a TEEP Agent.</t>
<t>For any given Trusted Component, a TEEP Agent is assumed to be able to determ
<t>A TEEP Agent is assumed to be able to determine, for any given Trusted Compon ine whether that Trusted Component is installed (or minimally, is running) in a
ent, TEE with
whether that Trusted Component is installed (or minimally, is running) in a TEE
with
which the TEEP Agent is associated.</t> which the TEEP Agent is associated.</t>
<t>Each Trusted Component is digitally signed, protecting its integrity
<t>Each Trusted Component is digitally signed, protecting its integrity, and lin and linking
king the Trusted Component back to the Trusted Component Signer. The Trusted Componen
the Trusted Component back to the Trusted Component Signer. The Trusted Componen t Signer is often the Trusted Component Developer but, in
t Signer is often the Trusted Component Developer, but in some cases, might be another party such as a Device Administrator
some cases might be another party such as a Device Administrator
or other party or other party
to whom the code has been licensed (in which case the same code might to whom the code has been licensed (in which case, the same code might
be signed by multiple licensees and distributed as if it were different TAs).</t > be signed by multiple licensees and distributed as if it were different TAs).</t >
<t>A Trusted Component Signer selects one or more TAMs and communicates
<t>A Trusted Component Signer selects one or more TAMs and communicates the Trus the Trusted Component(s) to the TAM.
ted Component(s) to the TAM.
For example, the Trusted Component Signer might choose TAMs based upon the marke ts into which the TAM can provide access. There For example, the Trusted Component Signer might choose TAMs based upon the marke ts into which the TAM can provide access. There
may be TAMs that provide services to specific types of devices, or device may be TAMs that provide services to specific types of devices, device
operating systems, or specific geographical regions or network carriers. A Trust operating systems, specific geographical regions, or network carriers. A Trusted
ed Component Signer may be Component Signer may be
motivated to utilize multiple TAMs in order to maximize market penetration motivated to utilize multiple TAMs in order to maximize market penetration
and availability on multiple types of devices. This means that the same Trusted Component and availability on multiple types of devices. This means that the same Trusted Component
will often be available through multiple TAMs.</t> will often be available through multiple TAMs.</t>
<t>When the developer of an Untrusted Application that depends on a Trus
<t>When the developer of an Untrusted Application that depends on a Trusted Comp ted Component publishes
onent publishes
the Untrusted Application to an app store or other app repository, the developer the Untrusted Application to an app store or other app repository, the developer
optionally binds the Untrusted Application with a manifest that identifies optionally binds the Untrusted Application with a manifest that identifies
what TAMs can be contacted for what TAMs can be contacted for
the Trusted Component. In some situations, a Trusted Component may only be avail able via a single TAM - this is likely the case the Trusted Component. In some situations, a Trusted Component may only be avail able via a single TAM; this is likely the case
for enterprise applications or Trusted Component Signers serving a closed commun ity. For broad public apps, for enterprise applications or Trusted Component Signers serving a closed commun ity. For broad public apps,
there will likely be multiple TAMs in the Untrusted Application's manifest - one there will likely be multiple TAMs in the Untrusted Application's manifest, one
servicing one brand of mobile servicing one brand of mobile
device and another servicing a different manufacturer, etc. Because different de device and another servicing a different manufacturer, etc. Because different de
vices vices and manufacturers trust different TAMs, the manifest can include multiple
and different manufacturers trust different TAMs, the manifest can include multi
ple
TAMs that support the required Trusted Component.</t> TAMs that support the required Trusted Component.</t>
<t>When a TEEP Broker receives a request (see the RequestTA API in <xref
<t>When a TEEP Broker receives a request (see the RequestTA API in <xref target= target="apis"/>) from an Untrusted Application to install a Trusted Component,
"apis"/>) from an Untrusted Application to install a Trusted Component,
a list of TAM URIs may be provided for that Trusted Component, and the request i s passed to the TEEP Agent. a list of TAM URIs may be provided for that Trusted Component, and the request i s passed to the TEEP Agent.
If the TEEP Agent decides that the Trusted Component needs to be installed, the TEEP Agent selects a single TAM URI If the TEEP Agent decides that the Trusted Component needs to be installed, the TEEP Agent selects a single TAM URI
that is consistent with the list of trusted TAMs provisioned in the TEEP Agent, invokes the that is consistent with the list of trusted TAMs provisioned in the TEEP Agent, invokes the
HTTP transport for TEEP to connect to the TAM URI, and begins a TEEP protocol ex change. When the TEEP Agent HTTP transport for TEEP to connect to the TAM URI, and begins a TEEP protocol ex change. When the TEEP Agent
subsequently receives the Trusted Component to install and the Trusted Component 's manifest indicates dependencies subsequently receives the Trusted Component to install and the Trusted Component 's manifest indicates dependencies
on any other trusted components, each dependency can include a list of TAM URIs for the on any other Trusted Components, each dependency can include a list of TAM URIs for the
relevant dependency. If such dependencies exist that are prerequisites to insta ll the Trusted Component, relevant dependency. If such dependencies exist that are prerequisites to insta ll the Trusted Component,
then the TEEP Agent recursively follows the same procedure for each dependency t hat needs to be installed then the TEEP Agent recursively follows the same procedure for each dependency t hat needs to be installed
or updated, including selecting a TAM URI that is consistent with the list of tr usted TAMs provisioned or updated, including selecting a TAM URI that is consistent with the list of tr usted TAMs provisioned
on the device, and beginning a TEEP exchange. If multiple TAM URIs are consider on the device and beginning a TEEP exchange. If multiple TAM URIs are considere
ed trusted, d trusted,
only one needs to be contacted and they can be attempted in some order until one only one needs to be contacted, and they can be attempted in some order until on
responds.</t> e responds.</t>
<t>Separate from the Untrusted Application's manifest, this framework re
<t>Separate from the Untrusted Application's manifest, this framework relies on lies on the use of the manifest
the use of the manifest
format in <xref target="I-D.ietf-suit-manifest"/> for expressing how to install a Trusted Component, as well as any format in <xref target="I-D.ietf-suit-manifest"/> for expressing how to install a Trusted Component, as well as any
dependencies on other TEE components and versions. dependencies on other TEE components and versions.
That is, dependencies from Trusted Components on other Trusted Components can be expressed in a SUIT manifest, That is, dependencies from Trusted Components on other Trusted Components can be expressed in a Software Update for the Internet of Things (SUIT) manifest,
including dependencies on any other TAs, trusted OS code (if any), or trusted fi rmware. including dependencies on any other TAs, trusted OS code (if any), or trusted fi rmware.
Installation steps can also be expressed in a SUIT manifest.</t> Installation steps can also be expressed in a SUIT manifest.</t>
<t>For example, TEEs compliant
<t>For example, TEEs compliant
with GlobalPlatform <xref target="GPTEE"/> may have a notion of a "security doma in" (which is a grouping of with GlobalPlatform <xref target="GPTEE"/> may have a notion of a "security doma in" (which is a grouping of
one or more TAs installed on a device, that can share information within such a group) one or more TAs installed on a device that can share information within such a g roup)
that must be created and into which one or more TAs can then be installed. It is thus up that must be created and into which one or more TAs can then be installed. It is thus up
to the SUIT manifest to express a dependency on having such a security domain ex isting to the SUIT manifest to express a dependency on having such a security domain ex isting
or being created first, as appropriate.</t> or being created first, as appropriate.</t>
<t>Updating a Trusted Component may cause compatibility issues with any
<t>Updating a Trusted Component may cause compatibility issues with any Untruste Untrusted Applications or other
d Applications or other
components that depend on the updated Trusted Component, just like updating the OS or a shared library components that depend on the updated Trusted Component, just like updating the OS or a shared library
could impact an Untrusted Application. Thus, an implementation needs to take in could impact an Untrusted Application. Thus, an implementation needs to take su
to ch issues into account.</t>
account such issues.</t> </section>
<section anchor="untrusted-apps-trusted-apps-and-personalization-data">
</section> <name>Untrusted Apps, Trusted Apps, and Personalization Data</name>
<section anchor="untrusted-apps-trusted-apps-and-personalization-data"><name>Unt <t>In TEEP, there is an explicit relationship and dependence between an
rusted Apps, Trusted Apps, and Personalization Data</name> Untrusted Application
<t>In TEEP, there is an explicit relationship and dependence between an Untruste
d Application
in an REE and one or more TAs in a TEE, as shown in <xref target="notionalarch2" />. in an REE and one or more TAs in a TEE, as shown in <xref target="notionalarch2" />.
For most purposes, an Untrusted Application that uses one or more TAs in a TEE For most purposes, an Untrusted Application that uses one or more TAs in a TEE
appears no different from any other Untrusted Application in the REE. However, t he way appears no different from any other Untrusted Application in the REE. However, t he way
the Untrusted Application and its corresponding TAs are packaged, delivered, and installed on the Untrusted Application and its corresponding TAs are packaged, delivered, and installed on
the device can vary. The variations depend on whether the Untrusted Application and TA are bundled the device can vary. The variations depend on whether the Untrusted Application and TA are bundled
together or are provided separately, and this has implications to the management of together or provided separately, and this has implications to the management of
the TAs in a TEE. In addition to the Untrusted Application and TA(s), the TA(s) and/or TEE may the TAs in a TEE. In addition to the Untrusted Application and TA(s), the TA(s) and/or TEE may
also require additional data to personalize the TA to the device or a user. also require additional data to personalize the TA to the device or a user.
Implementations of the TEEP protocol must support encryption to preserve the con fidentiality of such Personalization Data, Implementations of the TEEP protocol must support encryption to preserve the con fidentiality of such Personalization Data,
which may potentially contain sensitive data. The encryption is used to ensure t hat no personalization data which may potentially contain sensitive data. The encryption is used to ensure t hat no personalization data
is sent in the clear. Implementations must also support mechanisms for integrity protection of such Personalization Data. is sent in the clear. Implementations must also support mechanisms for integrity protection of such Personalization Data.
Other than the requirement to support confidentiality and integrity protection, Other than the requirement to support confidentiality and integrity protection,
the TEEP architecture places no limitations or requirements on the Personalizati on Data.</t> the TEEP architecture places no limitations or requirements on the Personalizati on Data.</t>
<t>There are multiple possible cases for bundling of an Untrusted Applic
<t>There are multiple possible cases for bundling of an Untrusted Application, T ation, TA(s), and Personalization Data.
A(s), and Personalization Data.
Such cases include (possibly among others):</t> Such cases include (possibly among others):</t>
<ol spacing="normal" type="1"><li>The Untrusted Application, TA(s), and
<t><list style="numbers"> Personalization Data are all bundled together in a single
<t>The Untrusted Application, TA(s), and Personalization Data are all bundled package by a Trusted Component Signer and either provided to the TEEP Broker thr
together in a single ough the TAM or provided separately (with encrypted Personalization Data), with
package by a Trusted Component Signer and either provided to the TEEP Broker thr
ough the TAM, or provided separately (with encrypted Personalization Data), with
key material needed to decrypt and install the Personalization key material needed to decrypt and install the Personalization
Data and TA provided by a TAM.</t> Data and TA provided by a TAM.</li>
<t>The Untrusted Application and the TA(s) are bundled together in a single pa <li>The Untrusted Application and the TA(s) are bundled together in a
ckage, which a TAM or single package, which a TAM or
a publicly accessible app store maintains, and the Personalization Data a publicly accessible app store maintains, and the Personalization Data
is separately provided by the Personalization Data provider's TAM.</t> is separately provided by the Personalization Data provider's TAM.</li>
<t>All components are independent packages. The Untrusted Application is insta <li>All components are independent packages. The Untrusted Application
lled through some is installed through some
independent or device-specific mechanism, and one or more TAMs provide (directly or indirectly by reference) independent or device-specific mechanism, and one or more TAMs provide (directly or indirectly by reference)
the TA(s) and Personalization Data.</t> the TA(s) and Personalization Data.</li>
<t>The TA(s) and Personalization Data are bundled together into a package prov <li>The TA(s) and Personalization Data are bundled together into a pac
ided by a TAM, kage provided by a TAM,
while the Untrusted Application is installed through some independent while the Untrusted Application is installed through some independent
or device-specific mechanism such as an app store.</t> or device-specific mechanism, such as an app store.</li>
<t>Encrypted Personalization Data is bundled into a package distributed with t <li>Encrypted Personalization Data is bundled into a package distribut
he Untrusted ed with the Untrusted
Application, while the TA(s) and key material needed to decrypt and install the Personalization Data Application, while the TA(s) and key material needed to decrypt and install the Personalization Data
are in a separate package provided by a TAM. Personalization Data is encrypted w ith a key are in a separate package provided by a TAM. Personalization Data is encrypted w ith a key
unique to that specific TEE, as discussed in <xref target="trustanchors"/>.</t> unique to that specific TEE, as discussed in <xref target="trustanchors"/>.</li>
</list></t> </ol>
<t>The TEEP protocol can treat each TA, any dependencies the TA has, and
<t>The TEEP protocol can treat each TA, any dependencies the TA has, and Persona Personalization Data as
lization Data as separate Trusted Components with separate installation steps that are expressed
separate Trusted Components with separate installation steps that are expressed in SUIT manifests, and a SUIT manifest might contain or reference multiple binar
in SUIT manifests, ies (see <xref target="I-D.ietf-suit-manifest"/>
and a SUIT manifest might contain or reference multiple binaries (see <xref targ
et="I-D.ietf-suit-manifest"/>
for more details). The TEEP Agent is responsible for handling any installation s teps for more details). The TEEP Agent is responsible for handling any installation s teps
that need to be performed inside the TEE, such as decryption of private TA binar ies or that need to be performed inside the TEE, such as decryption of private TA binar ies or
Personalization Data.</t> Personalization Data.</t>
<t>In order to better understand these cases, it is helpful to review ac
tual implementations of TEEs and their application delivery mechanisms.</t>
<section anchor="example-application-delivery-mechanisms-in-intel-sgx">
<t>In order to better understand these cases, it is helpful to review actual imp <name>Example: Application Delivery Mechanisms in Intel SGX</name>
lementations of TEEs and their application delivery mechanisms.</t> <t>In Intel Software Guard Extensions (SGX), the Untrusted
Application and TA are typically bundled into the same package (Case
<section anchor="example-application-delivery-mechanisms-in-intel-sgx"><name>Exa 2). The TA exists in the package as a shared library (.so or
mple: Application Delivery Mechanisms in Intel SGX</name> .dll). The Untrusted Application loads the TA into an SGX enclave
when the Untrusted Application needs the TA. This organization makes
<t>In Intel Software Guard Extensions (SGX), the Untrusted Application and TA ar it easy to maintain compatibility between the Untrusted Application
e typically bundled into the and the TA, since they are updated together. It is entirely possible
same package (Case 2). The TA to create an Untrusted Application that loads an external TA into an
exists in the package as a shared library (.so or .dll). The Untrusted Applicati SGX enclave and use that TA (Cases 3-5). In this case, the
on loads the TA into Untrusted Application would require a reference to an external file
an SGX enclave when the Untrusted Application needs the TA. This organization ma or download such a file dynamically, place the contents of the file
kes it easy to maintain into memory, and load that as a TA. Obviously, such file or
compatibility between the Untrusted Application and the TA, since they are updat downloaded content must be properly formatted and signed for it to
ed together. It is be accepted by the SGX TEE.</t>
entirely possible to create an Untrusted Application that loads an external TA i <t>In SGX, any
nto an SGX enclave, and
use that TA (Cases 3-5). In this case, the Untrusted Application would require a
reference to an external
file or download such a file dynamically, place the contents of the file into me
mory, and
load that as a TA. Obviously, such file or downloaded content must be properly f
ormatted
and signed for it to be accepted by the SGX TEE.</t>
<t>In SGX, any
Personalization Data is normally loaded into the SGX enclave (the TA) after the TA has Personalization Data is normally loaded into the SGX enclave (the TA) after the TA has
started. Although it is possible with SGX to include the Untrusted Application i started.
n an encrypted Although it is possible with SGX to include the Untrusted Application in an encr
package along with Personalization Data (Cases 1 and 5), there are no instances ypted
of this known to package along with Personalization Data (Cases 1 and 5), there are currently no
be in use at this time, since such a construction would require a special instal known instances of this in use, since such a construction would require a specia
lation l installation
program and SGX TA (which might or might not be the TEEP Agent itself based on t he implementation) program and SGX TA (which might or might not be the TEEP Agent itself based on t he implementation)
to receive the encrypted package, decrypt it, separate it into the to receive the encrypted package, decrypt it, separate it into the
different elements, and then install each one. This installation is complex different elements, and then install each one. This installation is complex
because the Untrusted Application decrypted inside the TEE must be passed out of the TEE to an because the Untrusted Application decrypted inside the TEE must be passed out of the TEE to an
installer in the REE which would install the Untrusted Application. installer in the REE that would install the Untrusted Application.
Finally, the Personalization Data would need to be sent out of the Finally, the Personalization Data would need to be sent out of the
TEE (encrypted in an SGX enclave-to-enclave manner) to the REE's installation ap p, which TEE (encrypted in an SGX enclave-to-enclave manner) to the REE's installation ap p, which
would pass this data to the installed Untrusted Application, which would in turn send this data would pass this data to the installed Untrusted Application, which would in turn send this data
to the SGX enclave (TA). This complexity is due to the fact that each SGX enclav e is separate to the SGX enclave (TA). This complexity is due to the fact that each SGX enclav e is separate
and does not have direct communication to other SGX enclaves.</t> and does not have direct communication to other SGX enclaves.</t>
<t>As long as signed files (TAs and/or Personalization Data) are insta
<t>As long as signed files (TAs and/or Personalization Data) are installed into lled into
an untrusted filesystem and trust is verified by the TEE at load time, classic an untrusted filesystem and trust is verified by the TEE at load time, classic
distribution mechanisms can be used. Some uses of SGX, however, allow a model distribution mechanisms can be used. However, some uses of SGX allow a model
where a TA can be dynamically installed into an SGX enclave that where a TA can be dynamically installed into an SGX enclave that
provides a runtime platform. The TEEP protocol can be used in provides a runtime platform. The TEEP protocol can be used in
such cases, where the runtime platform could include a TEEP Agent.</t> such cases, where the runtime platform could include a TEEP Agent.</t>
</section>
<section anchor="example-application-delivery-mechanisms-in-arm-trustzon
e">
<name>Example: Application Delivery Mechanisms in Arm TrustZone</name>
<t>In Arm TrustZone <xref target="TrustZone"/> for A-class devices,
the Untrusted Application and TA may or may not be bundled
together.
This differs from SGX since in TrustZone, the TA lifetime
is not inherently tied to a specific Untrusted Application process
lifetime as occurs in SGX. A TA is loaded by a trusted OS running
in the TEE, such as a TEE compliant with GlobalPlatform <xref target="
GPTEE"/>,
where the trusted OS is separate from the OS in the REE. Thus,
Cases 2-4 are equally applicable.
</section> In addition, it is possible for
<section anchor="example-application-delivery-mechanisms-in-arm-trustzone"><name TAs to communicate with each other without involving any Untrusted
>Example: Application Delivery Mechanisms in Arm TrustZone</name> Application; thus, the complexity of Cases 1 and 5 are lower than
in the SGX example, though still more complex than Cases 2-4.</t>
<t>In Arm TrustZone <xref target="TrustZone"/> for A-class devices, the Untruste <t>A trusted OS running in the TEE (e.g., OP-TEE <xref target="OP-TEE"
d Application and TA may or may not be />) that supports loading and verifying signed TAs from
bundled together. This differs from SGX since in TrustZone the TA lifetime is no
t inherently tied
to a specific Untrusted Application process lifetime as occurs in SGX. A TA is
loaded by
a trusted OS running in the TEE such as a GlobalPlatform <xref target="GPTEE"/>
compliant TEE, where the trusted OS is
separate from the OS in the REE.
Thus Cases 2-4 are equally applicable. In addition, it is possible for TAs to c
ommunicate
with each other without involving any Untrusted Application, and so the complexi
ty of Cases 1 and 5
are lower than in the SGX example, though still more
complex than Cases 2-4.</t>
<t>A trusted OS running in the TEE (e.g., OP-TEE <xref target="OP-TEE"/>) that s
upports loading and verifying signed TAs from
an untrusted filesystem can, like SGX, use classic file distribution an untrusted filesystem can, like SGX, use classic file distribution
mechanisms. If secure TA storage is used (e.g., a Replay-Protected mechanisms. If secure TA storage is used (e.g., a Replay-Protected
Memory Block device) on the other hand, the TEEP protocol can be used Memory Block device) on the other hand, the TEEP protocol can be used
to manage such storage.</t> to manage such storage.</t>
</section>
</section> </section>
</section> <section anchor="entity-relations">
<section anchor="entity-relations"><name>Entity Relations</name> <name>Entity Relations</name>
<t>This architecture leverages asymmetric cryptography to
<t>This architecture leverages asymmetric cryptography to
authenticate a device to a TAM. Additionally, a TEEP Agent authenticate a device to a TAM. Additionally, a TEEP Agent
in a device authenticates a TAM. The in a device authenticates a TAM. The
provisioning of Trust Anchors to a device may be different from provisioning of Trust Anchors to a device may be different from
one use case to the other. A Device Administrator may want to one use case to the other. A Device Administrator may want to
have the capability to control what TAs are allowed. have the capability to control what TAs are allowed.
A device manufacturer enables verification by one or more TAMs and by Trusted Co mponent Signers; A device manufacturer enables verification by one or more TAMs and by Trusted Co mponent Signers;
it may embed a list of default Trust Anchors into the TEEP Agent it may embed a list of default Trust Anchors into the TEEP Agent
and TEE for TAM trust verification and TA signature verification.</t> and TEE for TAM trust verification and TA signature verification.</t>
<figure anchor="experience">
<figure title="Example Developer Experience" anchor="experience"><artwork><![CDA <name>Example Developer Experience</name>
TA[ <artwork><![CDATA[
(App Developers) (App Store) (TAM) (Device with TEE) (CAs) (App Developers) (App Store) (TAM) (Device with TEE) (CAs)
| | | | | | | | | |
| | | (Embedded TEE cert) <--| | | | (Embedded TEE cert) <--|
| | | | | | | | | |
| <--- Get an app cert -----------------------------------| | <--- Get an app cert -----------------------------------|
| | | | | | | | | |
| | | <-- Get a TAM cert ---------| | | | <-- Get a TAM cert ---------|
| | | | | | | | | |
1. Build two apps: | | | | 1. Build two apps: | | | |
| | | | | | | |
(a) Untrusted | | | | (a) Untrusted | | | |
App - 2a. Supply --> | | | | App - 2a. Supply --> | | | |
| | | | | | | |
(b) TA -- 2b. Supply ----------> | | | (b) TA -- 2b. Supply ----------> | | |
| | | | | | | |
| --- 3. Install ------> | | | --- 3. Install ------> | |
| | | | | | | |
| | 4. Messaging-->| | | | 4. Messaging-->| |
]]></artwork></figure> ]]></artwork>
</figure>
<t><xref target="experience"/> shows an example where the same developer builds <t><xref target="experience"/> shows an example where the same developer
and signs builds and signs
two applications: (a) an Untrusted Application; (b) a TA two applications: (a) an Untrusted Application and (b) a TA
that provides some security functions to be run inside that provides some security functions to be run inside
a TEE. This example assumes that the developer, the TEE, and the TAM have a TEE. This example assumes that the developer, the TEE, and the TAM have
previously been provisioned with certificates.</t> previously been provisioned with certificates.</t>
<t>At step 1, the developer authors the two applications.</t> <t>At step 1, the developer authors the two applications.</t>
<t>At step 2, the developer uploads the
<t>At step 2, the developer uploads the
Untrusted Application (2a) to an Application Store. Untrusted Application (2a) to an Application Store.
In this example, the developer is also the Trusted Component Signer, and so gene rates In this example, the developer is also the Trusted Component Signer and thus gen erates
a signed TA. a signed TA.
The developer can then either bundle the signed TA The developer can then either bundle the signed TA
with the Untrusted Application, or the developer can provide a signed Trusted Co mponent containing the TA with the Untrusted Application or provide a signed Trusted Component containing the TA
to a TAM that will be managing the TA in various devices.</t> to a TAM that will be managing the TA in various devices.</t>
<t>At step 3, a user
<t>At step 3, a user
will go to an Application Store to download the Untrusted will go to an Application Store to download the Untrusted
Application (where the arrow indicates the direction of data transfer).</t> Application (where the arrow indicates the direction of data transfer).</t>
<t>At step 4, since the Untrusted Application depends on the TA, install
<t>At step 4, since the Untrusted Application depends on the TA, ing the Untrusted Application will trigger TA installation
installing the Untrusted Application will trigger TA installation
via communication with a TAM. The TEEP Agent via communication with a TAM. The TEEP Agent
will interact with the TAM via a TEEP Broker that facilitates communications bet ween the TAM will interact with the TAM via a TEEP Broker that facilitates communications bet ween the TAM
and the TEEP Agent.</t> and the TEEP Agent.</t>
<t>Some Trusted Component installation implementations might ask for a user's co nsent. In other <t>Some implementations that install Trusted Components might ask for a user's c onsent. In other
implementations, implementations,
a Device Administrator might choose what Untrusted Applications and related Trus ted Components to a Device Administrator might choose the Untrusted Applications and related Trust ed Components to
be installed. A user consent flow is out of scope of the TEEP architecture.</t> be installed. A user consent flow is out of scope of the TEEP architecture.</t>
<t>The main components of the TEEP protocol
<t>The main components of the TEEP protocol
consist of a set of standard messages created by consist of a set of standard messages created by
a TAM to deliver Trusted Component management commands to a device, a TAM to deliver Trusted Component management commands to a device
and device attestation and response messages created by a TEE that and device attestation and response messages created by a TEE that
responds to a TAM's message.</t> responds to a TAM's message.</t>
<t>It should be noted that network communication capability is generally
<t>It should be noted that network communication capability is generally
not available in TAs in today's TEE-powered devices. Consequently, Trusted not available in TAs in today's TEE-powered devices. Consequently, Trusted
Applications generally rely on a broker in the REE to provide access to Applications generally rely on a Broker in the REE to provide access to
network functionality in the REE. A broker does not need to know the actual network functionality in the REE. A Broker does not need to know the actual
content of messages to facilitate such access.</t> content of messages to facilitate such access.</t>
<t>Similarly, since the TEEP Agent runs inside a TEE, the TEEP Agent gen
<t>Similarly, since the TEEP Agent runs inside a TEE, the TEEP Agent generally erally
relies on a TEEP Broker in the REE to provide network access, and relay relies on a TEEP Broker in the REE to provide network access, relay
TAM requests to the TEEP Agent and relay the responses back to the TAM.</t> TAM requests to the TEEP Agent, and relay the responses back to the TAM.</t>
</section>
</section> </section>
</section> <section anchor="trustanchors">
<section anchor="trustanchors"><name>Keys and Certificate Types</name> <name>Keys and Certificate Types</name>
<t>This architecture leverages the following credentials, which allow
<t>This architecture leverages the following credentials, which allow
achieving end-to-end security between a TAM and a TEEP Agent.</t> achieving end-to-end security between a TAM and a TEEP Agent.</t>
<t><xref target="keys"/> summarizes the relationships between various keys
<t><xref target="keys"/> summarizes the relationships between various keys and w and where
here they are stored. Each public/private key identifies a Trusted Component Signer,
they are stored. Each public/private key identifies a Trusted Component Signer, TAM, or TEE
TAM, or TEE, and gets a certificate that chains up to some Trust Anchor.
and gets a certificate that chains up to some trust anchor. A list of trusted A list of trusted
certificates is used to check a presented certificate against.</t> certificates is used to check a presented certificate against.</t>
<t>Different CAs can be used for different
<t>Different CAs can be used for different
types of certificates. TEEP messages are always signed, where the signer types of certificates. TEEP messages are always signed, where the signer
key is the message originator's private key, such as that of a TAM key is the message originator's private key, such as that of a TAM
or a TEE. In addition to the keys shown in <xref target="keys"/>, or a TEE. In addition to the keys shown in <xref target="keys"/>,
there may be additional keys used for attestation or encryption. Refer to the there may be additional keys used for attestation or encryption. Refer to the
RATS Architecture <xref target="I-D.ietf-rats-architecture"/> for more discussio RATS Architecture <xref target="RFC9334"/> for more discussion.</t>
n.</t>
<figure title="Signature Keys" anchor="keys"><artwork><![CDATA[
Cardinality & Location of
Location of Private Key Trust Anchor
Purpose Private Key Signs Store
Authenticating 1 per TEE TEEP responses TAM
TEEP Agent
Authenticating TAM 1 per TAM TEEP requests TEEP Agent
Code Signing 1 per Trusted TA binary TEE
Component
Signer
]]></artwork></figure>
<t>Note that Personalization Data is not included in the table above. <table anchor="keys">
<name>Signature Keys</name>
<thead>
<tr>
<th>Purpose</th>
<th>Cardinality &amp; Location of Private Key</th>
<th>Private Key Signs</th>
<th>Location of Trust Anchor Store</th>
</tr>
</thead>
<tbody>
<tr>
<td>Authenticating TEEP Agent</td>
<td>1 per TEE</td>
<td>TEEP responses</td>
<td>TAM</td>
</tr>
<tr>
<td>Authenticating TAM</td>
<td>1 per TAM</td>
<td>TEEP requests</td>
<td>TEEP Agent</td>
</tr>
<tr>
<td>Code Signing</td>
<td>1 per Trusted Component Signer</td>
<td>TA binary</td>
<td>TEE</td>
</tr>
</tbody>
</table>
<t>Note that Personalization Data is not included in the table above.
The use of Personalization Data is dependent on how TAs are used The use of Personalization Data is dependent on how TAs are used
and what their security requirements are.</t> and what their security requirements are.</t>
<t>TEEP requests from a TAM to a TEEP Agent are signed with the TAM
<t>TEEP requests from a TAM to a TEEP Agent are signed with the TAM
private key (for authentication and integrity protection). private key (for authentication and integrity protection).
Personalization Data and TA binaries can be encrypted with a key Personalization Data and TA binaries can be encrypted with a key
unique to that specific TEE, unique to that specific TEE.
established with a content-encryption key established with Conversely, TEEP responses from a TEEP Agent to a TAM can be signed with the
the TEE public key (to provide confidentiality). Conversely, TEE private key.</t>
TEEP responses from a TEEP Agent to a TAM can be signed with the TEE
private key.</t>
<t>The TEE key pair and certificate are thus used for authenticating the TEE <t>The TEE key pair and certificate are thus used for authenticating the TEE
to a remote TAM, and for sending private data to the TEE. Often, to a remote TAM and for sending private data to the TEE. Often,
the key pair is burned into the TEE by the the key pair is burned into the TEE by the
TEE manufacturer and the key pair and its certificate are valid for TEE manufacturer, and the key pair and its certificate are valid for
the expected lifetime of the TEE. A TAM provider is responsible the expected lifetime of the TEE. A TAM provider is responsible
for configuring the TAM's Trust Anchor Store with the manufacturer certificates or CAs for configuring the TAM's Trust Anchor Store with the manufacturer certificates or CAs
that are used to sign TEE keys. This is discussed further in that are used to sign TEE keys. This is discussed further in
<xref target="trust-anchors-in-tam"/> below. Typically, <xref target="trust-anchors-in-tam"/>. Typically,
the same key TEE pair is used for both signing and encryption, though separate the same TEE key pair is used for both signing and encryption, though separate
key pairs might also be used in the future, as the joint security of key pairs might also be used in the future, as the joint security of
encryption and signature with a single key remains to some extent an open encryption and signature with a single key remains, to some extent, an open
question in academic cryptography.</t> question in academic cryptography.</t>
<t>The TAM key pair and certificate are used for authenticating a TAM
<t>The TAM key pair and certificate are used for authenticating a TAM to a remote TEE and for sending private data to the TAM (separate key
to a remote TEE, and for sending private data to the TAM (separate key
pairs for authentication vs. encryption could also be used in the future). A TA M provider pairs for authentication vs. encryption could also be used in the future). A TA M provider
is responsible for acquiring a is responsible for acquiring a
certificate from a CA that is trusted by the TEEs it manages. This certificate from a CA that is trusted by the TEEs it manages. This
is discussed further in <xref target="trust-anchors-in-teep-agent"/> below.</t> is discussed further in <xref target="trust-anchors-in-teep-agent"/>.</t>
<t>The Trusted Component Signer key pair and certificate are used to sign
<t>The Trusted Component Signer key pair and certificate are used to sign Truste Trusted Components that the TEE
d Components that the TEE
will consider authorized to execute. TEEs must be configured with will consider authorized to execute. TEEs must be configured with
the certificates or keys that it considers authorized to sign TAs the certificates or keys that it considers authorized to sign TAs
that it will execute. This is discussed further in that it will execute. This is discussed further in
<xref target="trust-anchors-in-tee"/> below.</t> <xref target="trust-anchors-in-tee"/>.</t>
<section anchor="trust-anchors-in-teep-agent">
<section anchor="trust-anchors-in-teep-agent"><name>Trust Anchors in a TEEP Agen <name>Trust Anchors in a TEEP Agent</name>
t</name> <t>A TEEP Agent's Trust Anchor Store contains a list of Trust Anchors, w
hich are typically CA certificates that sign various TAM certificates. The list
<t>A TEEP Agent's Trust Anchor Store contains a list of Trust Anchors, which is usually preloaded at manufacturing time and
are typically CA certificates that sign various TAM certificates. The list
is typically preloaded at manufacturing time, and
can be updated using the TEEP protocol if the TEE has some form of can be updated using the TEEP protocol if the TEE has some form of
"Trust Anchor Manager TA" that has Trust Anchors in its configuration data. "Trust Anchor Manager TA" that has Trust Anchors in its configuration data.
Thus, Trust Anchors can be updated similarly to the Personalization Data Thus, Trust Anchors can be updated similarly to the Personalization Data
for any other TA.</t> for any other TA.</t>
<t>When a Trust Anchor update is carried out, it is imperative that any
<t>When Trust Anchor update is carried out, it is imperative that any update update
must maintain integrity where only an authentic Trust Anchor list from must maintain integrity where only an authentic Trust Anchor list from
a device manufacturer or a Device Administrator is accepted. Details a device manufacturer or a Device Administrator is accepted. Details
are out of scope of the architecture and can be addressed in a protocol are out of scope of this architecture document and can be addressed in a protoco l
document.</t> document.</t>
<t>Before a TAM can begin operation in the marketplace to support a
<t>Before a TAM can begin operation in the marketplace to support a
device with a particular TEE, it must be able to get its raw public device with a particular TEE, it must be able to get its raw public
key, or its certificate, or a certificate it chains up to, listed in key, its certificate, or a certificate it chains up to listed in
the Trust Anchor Store of the TEEP Agent.</t> the Trust Anchor Store of the TEEP Agent.</t>
</section>
</section> <section anchor="trust-anchors-in-tee">
<section anchor="trust-anchors-in-tee"><name>Trust Anchors in a TEE</name> <name>Trust Anchors in a TEE</name>
<t>The Trust Anchor Store in a TEE contains a list of Trust Anchors (raw
<t>The Trust Anchor Store in a TEE contains a list of Trust Anchors (raw public public keys
keys
or certificates) that are used to determine whether TA binaries are allowed to e xecute by or certificates) that are used to determine whether TA binaries are allowed to e xecute by
checking if their signatures can be verified. The list checking if their signatures can be verified. The list
is typically preloaded at manufacturing time, and is typically preloaded at manufacturing time and
can be updated using the TEEP protocol if the TEE has some form of can be updated using the TEEP protocol if the TEE has some form of
"Trust Anchor Manager TA" that has Trust Anchors in its configuration data. "Trust Anchor Manager TA" that has Trust Anchors in its configuration data.
Thus, Trust Anchors can be updated similarly to the Personalization Data Thus, Trust Anchors can be updated similarly to the Personalization Data
for any other TA, as discussed in <xref target="trust-anchors-in-teep-agent"/>.< /t> for any other TA, as discussed in <xref target="trust-anchors-in-teep-agent"/>.< /t>
</section>
</section> <section anchor="trust-anchors-in-tam">
<section anchor="trust-anchors-in-tam"><name>Trust Anchors in a TAM</name> <name>Trust Anchors in a TAM</name>
<t>The Trust Anchor Store in a TAM consists of a list of Trust
<t>The Trust Anchor Store in a TAM consists of a list of Trust Anchors, which Anchors, which are certificates that sign various device TEE
are certificates that sign various device TEE certificates. A TAM will accept a certificates. A TAM will accept a device for Trusted Component
device for Trusted Component management if the TEE in the device uses a TEE cert management if the TEE in the device uses a TEE certificate that is
ificate chained to a certificate or raw public key that the TAM trusts, is
that is chained to a certificate or raw public key that the TAM trusts, is conta contained in an allow list, is not found on a block list, and/or
ined in an allow list, fulfills any other policy criteria.</t>
is not found on a block list, and/or fulfills any other policy criteria.</t> </section>
<section anchor="scalability">
</section> <name>Scalability</name>
<section anchor="scalability"><name>Scalability</name> <t>This architecture uses a PKI (including self-signed
certificates). Trust Anchors exist on the devices to enable the TEEP
<t>This architecture uses a PKI (including self-signed certificates). Trust Anch Agent to authenticate TAMs and the TEE to authenticate Trusted
ors exist on the devices to Component Signers, and TAMs use Trust Anchors to authenticate TEEP
enable the TEEP Agent to authenticate TAMs and the TEE to authenticate Agents. When a PKI is used, many intermediate CA certificates can
Trusted Component Signers, and TAMs use Trust Anchors to chain to a root certificate, each of which can issue many
authenticate TEEP Agents. When a PKI is used, many intermediate CA certificates. This makes the protocol highly scalable. New factories
certificates can chain to a root certificate, each of which can issue that produce TEEs can join the ecosystem. In this case, such a
many certificates. This makes the protocol highly scalable. New factory can get an intermediate CA certificate from one of the
factories that produce TEEs can join the ecosystem. In this case, existing roots without requiring that TAMs are updated with
such a factory can get an intermediate CA certificate from one of the information about the new device factory. Likewise, new TAMs can join
existing roots without requiring that TAMs are updated with the ecosystem, providing they are issued a TAM certificate that chains
information about the new device factory. Likewise, new TAMs can to an existing root whereby existing TAs in the TEE will be allowed to
join the ecosystem, providing they are issued a TAM certificate that be personalized by the TAM without requiring changes to the TEE
chains to an existing root whereby existing TAs in the TEE will be allowed to itself. This enables the ecosystem to scale and avoids the need for
be personalized by the TAM without requiring changes to the TEE centralized databases of all TEEs produced, all TAMs that exist, or
itself. This enables the ecosystem to scale, and avoids the need for all Trusted Component Signers that exist.
centralized databases of all TEEs produced or all TAMs that exist or </t>
all Trusted Component Signers that exist.</t> </section>
<section anchor="message-security">
</section> <name>Message Security</name>
<section anchor="message-security"><name>Message Security</name> <t>Messages created by a TAM are used to deliver Trusted Component
<t>Messages created by a TAM are used to deliver Trusted Component
management commands to a device, and device attestation and management commands to a device, and device attestation and
messages are created by the device TEE to respond to TAM messages.</t> messages are created by the device TEE to respond to TAM messages.</t>
<t>These messages are signed end-to-end between a TEEP Agent and a TAM.
<t>These messages are signed end-to-end between a TEEP Agent and a TAM.
Confidentiality is provided by encrypting sensitive payloads (such as Confidentiality is provided by encrypting sensitive payloads (such as
Personalization Data and attestation evidence), rather than encrypting the Personalization Data and attestation evidence), rather than encrypting the
messages themselves. Using encrypted payloads is important to ensure messages themselves. Using encrypted payloads is important to ensure
that only the targeted device TEE or TAM is able to decrypt and view that only the targeted device TEE or TAM is able to decrypt and view
the actual content.</t> the actual content.</t>
</section>
</section> </section>
</section> <section anchor="broker">
<section anchor="broker"><name>TEEP Broker</name> <name>TEEP Broker</name>
<t>A TEE and TAs often do not have the capability to directly communicate
<t>A TEE and TAs often do not have the capability to directly communicate
outside of the hosting device. For example, GlobalPlatform outside of the hosting device. For example, GlobalPlatform
<xref target="GPTEE"/> specifies one such architecture. This calls for a softwa re <xref target="GPTEE"/> specifies one such architecture. This calls for a softwa re
module in the REE world to handle network communication with a TAM.</t> module in the REE world to handle network communication with a TAM.</t>
<t>A TEEP Broker is an application component
<t>A TEEP Broker is an application component
running in the REE of the device or an SDK that facilitates running in the REE of the device or an SDK that facilitates
communication between a TAM and a TEE. It also provides interfaces for communication between a TAM and a TEE. It also provides interfaces for
Untrusted Applications to query and trigger installation of Trusted Components t hat the Untrusted Applications to query and trigger installation of Trusted Components t hat the
application needs to use.</t> application needs to use.</t>
<t>An Untrusted Application might communicate with a TEEP Broker at runtime <t>
to trigger Trusted Component installation itself, or an Untrusted Application mi An Untrusted Application might communicate with a TEEP Broker at
ght simply runtime to trigger Trusted Component installation itself. Alternatively, an
have a metadata file that describes the Trusted Components it depends on and the Untrusted Application might simply have a metadata file that
associated TAM(s) for each Trusted Component, describes the Trusted Components it depends on and the associated
and an REE Application Installer can inspect this TAM(s) for each Trusted Component. An REE Application Installer
application metadata file and invoke the TEEP Broker to trigger Trusted Componen can inspect this application metadata file and invoke the TEEP Broker
t installation to trigger Trusted Component installation on behalf of the Untrusted
on behalf of the Untrusted Application without requiring the Untrusted Application to run first.
Application without requiring the Untrusted Application to run first.</t> </t>
<section anchor="role-of-the-teep-broker">
<section anchor="role-of-the-teep-broker"><name>Role of the TEEP Broker</name> <name>Role of the TEEP Broker</name>
<t>A TEEP Broker interacts with a TEEP Agent inside a TEE,
<t>A TEEP Broker interacts with a TEEP Agent inside a TEE,
relaying messages between the TEEP Agent and the TAM, and may also interact with relaying messages between the TEEP Agent and the TAM, and may also interact with
one or more Untrusted Applications (see <xref target="apis"/>). one or more Untrusted Applications (see <xref target="apis"/>).
The Broker cannot parse encrypted TEEP messages between a TAM and a TEEP agent The Broker cannot parse encrypted TEEP messages exchanged between a TAM and a TE
but merely relays them.</t> EP Agent but merely relays them.</t>
<t>When a device has more than one TEE, one TEEP Broker per TEE could
<t>When a device has more than one TEE, one TEEP Broker per TEE could be present in the REE, or a common TEEP Broker could be used by multiple TEEs
be present in the REE or a common TEEP Broker could be used by multiple TEEs
where the transport protocol (e.g., <xref target="I-D.ietf-teep-otrp-over-http"/ >) allows where the transport protocol (e.g., <xref target="I-D.ietf-teep-otrp-over-http"/ >) allows
the TEEP Broker to distinguish which TEE is relevant for each message from a TAM .</t> the TEEP Broker to distinguish which TEE is relevant for each message from a TAM .</t>
<t>The Broker only needs to return a (transport) error message to the TAM if the TEE is <t>The Broker only needs to return an error message to the TAM if the TEE is
not reachable for some reason. Other errors are represented as not reachable for some reason. Other errors are represented as
TEEP response messages returned from the TEE which will then be passed to TEEP response messages returned from the TEE, which will then be passed to
the TAM.</t> the TAM.</t>
</section>
<section anchor="teep-broker-implementation-consideration">
<name>TEEP Broker Implementation Consideration</name>
<t>As depicted in <xref target="broker-models"/>, there are multiple way
s in which a TEEP Broker
can be implemented with more or fewer layers being inside the TEE.
For example, in model A (the model with the smallest TEE footprint), only the
TEEP implementation is inside the TEE, whereas the TEEP/HTTP implementation is
in the TEEP Broker outside the TEE.</t>
<figure anchor="broker-models">
<name>TEEP Broker Models</name>
<artwork><![CDATA[
Model: A B C
</section> TEE TEE TEE
<section anchor="teep-broker-implementation-consideration"><name>TEEP Broker Imp +----------------+ | | |
lementation Consideration</name> | TEEP | Agent | | | Agent
| implementation | | | |
<t>As depicted in <xref target="broker-models"/>, there are multiple ways in whi +----------------+ v | |
ch a TEEP Broker | | |
can be implemented, with more or fewer layers being inside the TEE. For example +----------------+ ^ | |
, in | TEEP/HTTP | Broker | | |
model A, the model with the smallest TEE footprint, only the TEEP implementation | implementation | | | |
is inside +----------------+ | v |
the TEE, whereas the TEEP/HTTP implementation is in the TEEP Broker outside the | | |
TEE.</t> +----------------+ | ^ |
| HTTP(S) | | | |
<figure title="TEEP Broker Models" anchor="broker-models"><artwork><![CDATA[ | implementation | | | |
Model: A B C +----------------+ | | v
| | |
TEE TEE TEE +----------------+ | | ^
+----------------+ | | | | TCP or QUIC | | | | Broker
| TEEP | Agent | | | Agent | implementation | | | |
| implementation | | | | +----------------+ | | |
+----------------+ v | | REE REE REE
| | | ]]></artwork>
+----------------+ ^ | | </figure>
| TEEP/HTTP | Broker | | | <t>In other models, additional layers are moved into the TEE, increasing
| implementation | | | | the TEE footprint,
+----------------+ | v |
| | |
+----------------+ | ^ |
| HTTP(S) | | | |
| implementation | | | |
+----------------+ | | v
| | |
+----------------+ | | ^
| TCP or QUIC | | | | Broker
| implementation | | | |
+----------------+ | | |
REE REE REE
]]></artwork></figure>
<t>In other models, additional layers are moved into the TEE, increasing the TEE
footprint,
with the Broker either containing or calling the topmost protocol layer outside of the TEE. with the Broker either containing or calling the topmost protocol layer outside of the TEE.
An implementation is free to choose any of these models.</t> An implementation is free to choose any of these models.</t>
<t>TEEP Broker implementers should consider methods of distribution, sco
<t>TEEP Broker implementers should consider methods of distribution, scope and pe, and
concurrency on devices and runtime options.</t> concurrency on devices and runtime options.</t>
<section anchor="apis">
<name>TEEP Broker APIs</name>
<t>The following conceptual APIs exist from a TEEP Broker to a TEEP Ag
ent:</t>
<ol spacing="normal">
<section anchor="apis"><name>TEEP Broker APIs</name> <li>RequestTA: A notification from an REE application (e.g., an
installer or an Untrusted Application) that the application
<t>The following conceptual APIs exist from a TEEP Broker to a TEEP Agent:</t> depends on a given Trusted Component, which may or may not already
be installed in the TEE.
<t><list style="numbers"> </li>
<t>RequestTA: A notification from an REE application (e.g., an installer, <li>UnrequestTA: A notification from an REE application (e.g., an
or an Untrusted Application) that it depends on a given Trusted Component, which installer or an Untrusted Application) that the application no
may or may not longer depends on a given Trusted Component, which may or may not
already be installed in the TEE.</t> already be installed in the TEE. For example, if the Untrusted
<t>UnrequestTA: A notification from an REE application (e.g., an installer, Application is uninstalled, the uninstaller might invoke this
or an Untrusted Application) that it no longer depends on a given conceptual API.</li>
Trusted Component, which may or may not already be installed in the TEE. <li>ProcessTeepMessage: A message arriving from the network, to be delivered
For example, if the Untrusted Application is uninstalled, the uninstaller to the TEEP Agent for processing.</li>
might invoke this conceptual API.</t> <li>RequestPolicyCheck: A hint (e.g., based on a timer) that the TEE
<t>ProcessTeepMessage: A message arriving from the network, to be delivered P Agent
to the TEEP Agent for processing.</t> may wish to contact the TAM for any changes without the device itself
<t>RequestPolicyCheck: A hint (e.g., based on a timer) that the TEEP Agent needing any particular change.</li>
may wish to contact the TAM for any changes, without the device itself <li>ProcessError: A notification that the TEEP Broker could not deli
needing any particular change.</t> ver an outbound
<t>ProcessError: A notification that the TEEP Broker could not deliver an outb TEEP message to a TAM.</li>
ound </ol>
TEEP message to a TAM.</t> <t>For comparison, similar APIs may exist on the TAM side, where a Bro
</list></t> ker may or may not
<t>For comparison, similar APIs may exist on the TAM side, where a Broker may or
may not
exist, depending on whether the TAM uses a TEE or not:</t> exist, depending on whether the TAM uses a TEE or not:</t>
<ol spacing="normal">
<t><list style="numbers"> <li>ProcessConnect: A notification that a new TEEP session is being requested by
<t>ProcessConnect: A notification that a new TEEP session is being requested b a TEEP Agent.</li>
y a TEEP Agent.</t> <li>ProcessTeepMessage: A message arriving at an existing TEEP sessi
<t>ProcessTeepMessage: A message arriving at an existing TEEP session, to be d on, to be delivered
elivered to the TAM for processing.</li>
to the TAM for processing.</t> </ol>
</list></t> <t>For further discussion on these APIs, see <xref target="I-D.ietf-te
ep-otrp-over-http"/>.</t>
<t>For further discussion on these APIs, see <xref target="I-D.ietf-teep-otrp-ov </section>
er-http"/>.</t> <section anchor="teep-broker-distribution">
<name>TEEP Broker Distribution</name>
</section> <t>The Broker installation is commonly carried out at device manufactu
<section anchor="teep-broker-distribution"><name>TEEP Broker Distribution</name> ring time. A user
may also dynamically download and install a Broker on demand.</t>
<t>The Broker installation is commonly carried out at device manufacturing time. </section>
A user </section>
may also dynamically download and install a Broker on-demand.</t> </section>
<section anchor="attestation">
</section> <name>Attestation</name>
</section> <t>Attestation is the process through which one entity (an Attester) prese
</section> nts "evidence" in the form
<section anchor="attestation"><name>Attestation</name> of a series of claims to another entity (a Verifier) and provides sufficient pro
<t>Attestation is the process through which one entity (an Attester) presents "e of that the claims
vidence", in the form are true. Different Verifiers may require different degrees of confidence in att
of a series of claims, to another entity (a Verifier), and provides sufficient p estation proofs,
roof that the claims
are true. Different Verifiers may require different degrees of confidence in att
estation proofs
and not all attestations are acceptable to every Verifier. A third entity (a Re lying Party) and not all attestations are acceptable to every Verifier. A third entity (a Re lying Party)
can then use "attestation results", in the form of another series of claims, fro can then use "attestation results" in the form of another series of claims from
m a Verifier a Verifier
to make authorization decisions. (See <xref target="I-D.ietf-rats-architecture" to make authorization decisions. (See <xref target="RFC9334"/> for more discuss
/> for more discussion.)</t> ion.)</t>
<t>In TEEP, as depicted in <xref target="attestation-roles"/>,
<t>In TEEP, as depicted in <xref target="attestation-roles"/>,
the primary purpose of an attestation is to allow a device (the Attester) to pro ve to a TAM the primary purpose of an attestation is to allow a device (the Attester) to pro ve to a TAM
(the Relying Party) that a TEE in the device has particular properties, was buil t by a particular (the Relying Party) that a TEE in the device has particular properties, was buil t by a particular
manufacturer, and/or is executing a particular TA. Other claims are possible; TE EP manufacturer, and/or is executing a particular TA. Other claims are possible; TE EP
does not limit the claims that may appear in evidence or attestation results, does not limit the claims that may appear in evidence or attestation results,
but defines a minimal set of attestation result claims but it defines a minimal set of attestation result claims
required for TEEP to operate properly. Extensions to these claims are possible. required for TEEP to operate properly. Extensions to these claims are possible.
Other standards or groups may define the format and semantics Other standards or groups may define the format and semantics
of extended claims.</t> of extended claims.</t>
<figure anchor="attestation-roles">
<figure title="TEEP Attestation Roles" anchor="attestation-roles"><artwork><![CD <name>TEEP Attestation Roles</name>
ATA[ <artwork><![CDATA[
+----------------+ +----------------+
| Device | +----------+ | Device | +----------+
| +------------+ | Evidence | TAM | Evidence +----------+ | +------------+ | Evidence | TAM | Evidence +----------+
| | TEE |------------->| (Relying |-------------->| Verifier | | | TEE |------------->| (Relying |-------------->| Verifier |
| | (Attester) | | | Party) |<--------------| | | | (Attester) | | | Party) |<--------------| |
| +------------+ | +----------+ Attestation +----------+ | +------------+ | +----------+ Attestation +----------+
+----------------+ Result +----------------+ Result
]]></artwork></figure> ]]></artwork>
</figure>
<t>As of the writing of this specification, device and TEE attestations have not <t>At the time of writing this specification, device and TEE attestations
been standardized have not been standardized
across the market. Different devices, manufacturers, and TEEs support different attestation across the market. Different devices, manufacturers, and TEEs support different attestation
protocols. In order for TEEP to be inclusive, it is agnostic to the format of ev idence, protocols. In order for TEEP to be inclusive, it is agnostic to the format of ev idence,
allowing proprietary or standardized formats to be used between a TEE and a Veri fier (which may or may not allowing proprietary or standardized formats to be used between a TEE and a Veri fier (which may or may not
be colocated in the TAM), as long as the format supports encryption of be colocated in the TAM), as long as the format supports encryption of
any information that is considered sensitive.</t> any information that is considered sensitive.</t>
<t>However, it should be recognized
<t>However, it should be recognized
that not all Verifiers may be able to process all proprietary forms of attestati on evidence. that not all Verifiers may be able to process all proprietary forms of attestati on evidence.
Similarly, the TEEP protocol is agnostic as to the format of attestation results , and the protocol Similarly, the TEEP protocol is agnostic as to the format of attestation results and the protocol
(if any) used between the TAM and a Verifier, as long as they convey at least th e required set of claims (if any) used between the TAM and a Verifier, as long as they convey at least th e required set of claims
in some format. Note that the respective attestation algorithms are not defined in the TEEP protocol itself; in some format. Note that the respective attestation algorithms are not defined in the TEEP protocol itself;
see <xref target="I-D.ietf-rats-architecture"/> and <xref target="I-D.ietf-teep- see <xref target="RFC9334"/> and <xref target="I-D.ietf-teep-protocol"/> for mor
protocol"/> for more discussion.</t> e discussion.</t>
<t>There are a number of considerations that need to be considered when appraisi
ng
evidence provided by a TEE, including:</t>
<t><list style="symbols">
<t>What security measures a manufacturer takes when provisioning keys into dev
ices/TEEs;</t>
<t>What hardware and software components have access to the attestation keys o
f the TEE;</t>
<t>The source or local verification of claims within an attestation prior to a
TEE signing a set of claims;</t>
<t>The level of protection afforded to attestation keys against exfiltration,
modification, and side channel attacks;</t>
<t>The limitations of use applied to TEE attestation keys;</t>
<t>The processes in place to discover or detect TEE breaches; and</t>
<t>The revocation and recovery process of TEE attestation keys.</t>
</list></t>
<t>Some TAMs may require additional claims in order to properly authorize a devi <t>Considerations when appraising evidence provided by a TEE include the f
ce or TEE. The specific ollowing:
</t>
<ul spacing="normal">
<li>What security measures a manufacturer takes when provisioning keys i
nto devices/TEEs;</li>
<li>What hardware and software components have access to the attestation
keys of the TEE;</li>
<li>The source or local verification of claims within an attestation pri
or to a TEE signing a set of claims;</li>
<li>The level of protection afforded to attestation keys against exfiltr
ation, modification, and side channel attacks;</li>
<li>The limitations of use applied to TEE attestation keys;</li>
<li>The processes in place to discover or detect TEE breaches; and</li>
<li>The revocation and recovery process of TEE attestation keys.</li>
</ul>
<t>Some TAMs may require additional claims in order to properly authorize
a device or TEE. The specific
format for these additional claims are outside the scope of this specification, but the TEEP protocol format for these additional claims are outside the scope of this specification, but the TEEP protocol
allows these additional claims to be included in the attestation messages.</t> allows these additional claims to be included in the attestation messages.</t>
<t>For more discussion of the attestation and appraisal process, see
<t>For more discussion of the attestation and appraisal process, see the RATS Architecture <xref target="RFC9334"/>.</t>
the RATS Architecture <xref target="I-D.ietf-rats-architecture"/>.</t> <t>The following information is required for TEEP attestation:</t>
<ul spacing="normal">
<t>The following information is required for TEEP attestation:</t> <li>Device Identifying Information: Attestation information may need to
uniquely identify a device to the TAM.
<t><list style="symbols">
<t>Device Identifying Information: Attestation information may need to uniquel
y identify a device to the TAM.
Unique device identification allows the TAM to provide services to the device, s uch as managing installed Unique device identification allows the TAM to provide services to the device, s uch as managing installed
TAs, and providing subscriptions to services, and locating device-specific keyin TAs, providing subscriptions to services, and locating device-specific keying ma
g material to terial to
communicate with or authenticate the device. In some use cases it may be suffici communicate with or authenticate the device. In some use cases, it may be suffic
ent to identify ient to identify
only the model or class of the device, for example, a DAA Issuer's group public key ID when the only the model or class of the device, for example, a DAA Issuer's group public key ID when the
attestation uses DAA, see <xref target="I-D.ietf-rats-daa"/>. Another example of models is the hwmodel (Hardware Model) as attestation uses DAA; see <xref target="I-D.ietf-rats-daa"/>. Another example of models is the hwmodel (Hardware Model) as
defined in <xref target="I-D.ietf-rats-eat"/>. The security and privacy requirem ents regarding device identification defined in <xref target="I-D.ietf-rats-eat"/>. The security and privacy requirem ents regarding device identification
will vary with the type of TA provisioned to the TEE.</t> will vary with the type of TA provisioned to the TEE.</li>
<t>TEE Identifying Information: The type of TEE that generated this attestatio <li>TEE Identifying Information: The type of TEE that generated this att
n must be identified. estation must be identified.
This includes version identification information for hardware, firmware, and sof tware version of the TEE, as applicable by the This includes version identification information for hardware, firmware, and sof tware version of the TEE, as applicable by the
TEE type. TEE manufacturer information for the TEE is TEE type. TEE manufacturer information for the TEE is
required in order to disambiguate the same TEE type created by different manufac turers and required in order to disambiguate the same TEE type created by different manufac turers and
address considerations around manufacturer provisioning, keying and support for address considerations around manufacturer provisioning, keying, and support for
the TEE.</t> the TEE.</li>
<t>Freshness Proof: A claim that includes freshness information must be includ <li>Freshness Proof: A claim that includes freshness information must be
ed, such as a nonce included, such as a nonce
or timestamp.</t> or timestamp.</li>
</list></t> </ul>
</section>
</section> <section anchor="algorithm-and-attestation-agility">
<section anchor="algorithm-and-attestation-agility"><name>Algorithm and Attestat <name>Algorithm and Attestation Agility</name>
ion Agility</name> <t><xref target="RFC7696"/> outlines the requirements to migrate from one
<t><xref target="RFC7696"/> outlines the requirements to migrate from one
mandatory-to-implement cryptographic algorithm suite to another over time. mandatory-to-implement cryptographic algorithm suite to another over time.
This feature is also known as crypto agility. Protocol evolution This feature is also known as "crypto agility". Protocol evolution
is greatly simplified when crypto agility is considered is greatly simplified when crypto agility is considered
during the design of the protocol. In the case of the TEEP during the design of the protocol. In the case of the TEEP
protocol the diverse range of use cases, from trusted app protocol, the diverse range of use cases (from trusted app
updates for smartphones and tablets to updates of code on updates for smartphones and tablets to updates of code on
higher-end IoT devices, creates the need for different higher-end IoT devices) creates the need for different
mandatory-to-implement algorithms already from the start.</t> mandatory-to-implement algorithms from the start.</t>
<t>Crypto agility in TEEP concerns the use of symmetric as well as asymmet
<t>Crypto agility in TEEP concerns the use of symmetric as well as asymmetric ric
algorithms. In the context of TEEP, symmetric algorithms are used for algorithms. In the context of TEEP, symmetric algorithms are used for
encryption and integrity protection of TA binaries and Personalization Data encryption and integrity protection of TA binaries and Personalization Data,
whereas the asymmetric algorithms are used for signing messages and managing whereas the asymmetric algorithms are used for signing messages and managing
symmetric keys.</t> symmetric keys.</t>
<t>In addition to the use of cryptographic algorithms in TEEP, there
<t>In addition to the use of cryptographic algorithms in TEEP, there
is also the need to make use of different attestation technologies. is also the need to make use of different attestation technologies.
A device must provide techniques to inform a TAM about the A device must provide techniques to inform a TAM about the
attestation technology it supports. For many deployment cases it attestation technology it supports. For many deployment cases, it
is more likely for the TAM to support one or more attestation is more likely for the TAM to support one or more attestation
techniques whereas the device may only support one.</t> techniques, whereas the device may only support one.</t>
</section>
</section> <section anchor="security-considerations">
<section anchor="security-considerations"><name>Security Considerations</name> <name>Security Considerations</name>
<section anchor="broker-trust-model">
<section anchor="broker-trust-model"><name>Broker Trust Model</name> <name>Broker Trust Model</name>
<t>The architecture enables the TAM to communicate, via a TEEP Broker, w
ith the device's TEE to manage Trusted Components.
<t>The architecture enables the TAM to communicate, via a TEEP Broker, with the However, since the TEEP Broker runs in a potentially vulnerable REE,
device's TEE the TEEP Broker could be malware or be infected by malware.
to manage Trusted Components. Since the TEEP Broker runs in a potentially vulne
rable REE,
the TEEP Broker could, however, be (or be infected by) malware.
As such, all TAM messages are signed and sensitive As such, all TAM messages are signed and sensitive
data is encrypted such that the TEEP Broker cannot modify or capture data is encrypted such that the TEEP Broker cannot modify or capture
sensitive data, but the TEEP Broker can still conduct DoS attacks sensitive data, but the TEEP Broker can still conduct DoS attacks
as discussed in <xref target="compromised-ree"/>.</t> as discussed in <xref target="compromised-ree"/>.</t>
<t>A TEEP Agent in a TEE is responsible for protecting against potential
<t>A TEEP Agent in a TEE is responsible for protecting against potential attacks attacks
from a compromised from a compromised
TEEP Broker or rogue malware in the REE. A rogue TEEP Broker TEEP Broker or rogue malware in the REE. A rogue TEEP Broker
might send corrupted data to the TEEP Agent, or launch a DoS attack by sending a flood might send corrupted data to the TEEP Agent, launch a DoS attack by sending a fl ood
of TEEP protocol requests, or simply drop or delay notifications to a TEE. The T EEP Agent of TEEP protocol requests, or simply drop or delay notifications to a TEE. The T EEP Agent
validates the signature of each TEEP protocol request validates the signature of each TEEP protocol request
and checks the signing certificate against its Trust Anchors. To mitigate and checks the signing certificate against its Trust Anchors. To mitigate
DoS attacks, it might also add some protection DoS attacks, it might also add some protection
scheme such as a threshold on repeated requests or number of TAs that can be ins scheme such as a threshold on repeated requests or the number of TAs that can be
talled.</t> installed.</t>
<t>Due to the lack of any available alternative, some implementations mi
<t>Some implementations might rely on (due to lack of any available alternative) ght rely on the use of
the use of
an untrusted timer or other event to call the RequestPolicyCheck API (<xref targ et="apis"/>), which an untrusted timer or other event to call the RequestPolicyCheck API (<xref targ et="apis"/>), which
means that a compromised REE can cause a TEE to not receive policy changes and t hus be out of date means that a compromised REE can cause a TEE to not receive policy changes and t hus be out of date
with respect to policy. The same can potentially be done by any other manipulat or-in-the-middle with respect to policy. The same can potentially be done by any other manipulat or-in-the-middle
simply by blocking communication with a TAM. Ultimately such outdated complianc e simply by blocking communication with a TAM. Ultimately, such outdated complian ce
could be addressed by using attestation in secure communication, where the attes tation could be addressed by using attestation in secure communication, where the attes tation
evidence reveals what state the TEE is in, so that communication (other than rem ediation evidence reveals what state the TEE is in, so that communication (other than rem ediation
such as via TEEP) from an out-of-compliance TEE can be rejected.</t> such as via TEEP) from an out-of-compliance TEE can be rejected.</t>
<t>Similarly, in most implementations, the REE is involved in the mechan
<t>Similarly, in most implementations the REE is involved in the mechanics of in ics of installing new TAs.
stalling new TAs.
However, the authority for what TAs are running in a given TEE is between the TE EP Agent and the TAM. However, the authority for what TAs are running in a given TEE is between the TE EP Agent and the TAM.
While a TEEP Broker can in effect make suggestions as discussed in Section <xref target="apis"/>, it cannot decide or enforce what runs where. While a TEEP Broker can, in effect, make suggestions as discussed in <xref targe t="apis"/>, it cannot decide or enforce what runs where.
The TEEP Broker can also control which TEE a given installation request is direc ted at, but a TEEP The TEEP Broker can also control which TEE a given installation request is direc ted at, but a TEEP
Agent will only accept TAs that are actually applicable to it and where installa tion instructions Agent will only accept TAs that are actually applicable to it and where installa tion instructions
are received by a TAM that it trusts.</t> are received by a TAM that it trusts.</t>
<t>The authorization model for the UnrequestTA operation is, however, we
<t>The authorization model for the UnrequestTA operation is, however, weaker in aker in that it
that it
expresses the removal of a dependency from an application that was untrusted to begin with. expresses the removal of a dependency from an application that was untrusted to begin with.
This means that a compromised REE could remove a valid dependency from an Untrus ted Application This means that a compromised REE could remove a valid dependency from an Untrus ted Application
on a TA. Normal REE security mechanisms should be used to protect the REE and U ntrusted Applications.</t> on a TA. Normal REE security mechanisms should be used to protect the REE and U ntrusted Applications.</t>
</section>
</section> <section anchor="data-protection">
<section anchor="data-protection"><name>Data Protection</name> <name>Data Protection</name>
<t>It is the responsibility of the TAM to protect data on its servers.
<t>It is the responsibility of the TAM to protect data on its servers.
Similarly, it is the responsibility of the TEE implementation to provide protect ion of Similarly, it is the responsibility of the TEE implementation to provide protect ion of
data against integrity and confidentiality attacks from outside the TEE. data against integrity and confidentiality attacks from outside the TEE.
TEEs that provide isolation among TAs within the TEE are likewise TEEs that provide isolation among TAs within the TEE are likewise
responsible for protecting TA data against the REE and other TAs. responsible for protecting TA data against the REE and other TAs.
For example, this can be used to protect one user's or tenant's data For example, this can be used to protect the data of one user or tenant
from compromise by another user or tenant, even if the attacker has TAs.</t> from compromise by another user or tenant, even if the attacker has TAs.</t>
<t>The protocol between TEEP Agents and TAMs is similarly responsible fo
<t>The protocol between TEEP Agents and TAMs similarly is responsible for r
securely providing integrity and confidentiality protection against securely providing integrity and confidentiality protection against
adversaries between them. It is a design choice at what layers to best adversaries between them.
provide protection against network adversaries. As discussed in <xref target="br The layers at which to best provide protection against network
oker"/>, adversaries is a design choice.
As discussed in <xref target="broker"/>,
the transport protocol and any security mechanism associated with it (e.g., the Transport Layer Security protocol) under the transport protocol and any security mechanism associated with it (e.g., the Transport Layer Security protocol) under
the TEEP protocol may terminate outside a TEE. If it does, the TEEP protocol the TEEP protocol may terminate outside a TEE. If it does, the TEEP protocol
itself must provide integrity protection and confidentiality protection to itself must provide integrity and confidentiality protection to
secure data end-to-end. For example, confidentiality protection for secure data end-to-end. For example, confidentiality protection for
payloads may be provided by utilizing encrypted TA binaries and encrypted payloads may be provided by utilizing encrypted TA binaries and encrypted
attestation information. See <xref target="I-D.ietf-teep-protocol"/> for how a s pecific attestation information. See <xref target="I-D.ietf-teep-protocol"/> for how a s pecific
solution addresses the design question of how to provide integrity and solution addresses the design question of how to provide integrity and
confidentiality protection.</t> confidentiality protection.</t>
</section>
</section> <section anchor="compromised-ree">
<section anchor="compromised-ree"><name>Compromised REE</name> <name>Compromised REE</name>
<t>It is possible that the REE of a device is compromised.
<t>It is possible that the REE of a device is compromised.
We have already seen examples of attacks on the public Internet with a large num ber We have already seen examples of attacks on the public Internet with a large num ber
of compromised devices being used to mount DDoS attacks. A compromised of compromised devices being used to mount DDoS attacks. A compromised
REE can be used for such an attack but it cannot tamper with the TEE's REE can be used for such an attack, but it cannot tamper with the TEE's
code or data in doing so. A compromised REE can, however, launch DoS attacks code or data in doing so. A compromised REE can, however, launch DoS attacks
against the TEE.</t> against the TEE.</t>
<t>The compromised REE
<t>The compromised REE may terminate the TEEP Broker such that TEEP transactions cannot reach the TEE
may terminate the TEEP Broker such that TEEP transactions cannot reach the TEE,
or might drop, replay, or delay messages between a TAM and a TEEP Agent. or might drop, replay, or delay messages between a TAM and a TEEP Agent.
However, while a DoS attack cannot be prevented, the REE cannot access However, while a DoS attack cannot be prevented, the REE cannot access
anything in the TEE if the TEE is implemented correctly. anything in the TEE if the TEE is implemented correctly.
Some TEEs may have some watchdog scheme to observe REE state and mitigate DoS Some TEEs may have some watchdog scheme to observe REE state and mitigate DoS
attacks against it but most TEEs don't have such a capability.</t> attacks against it, but most TEEs don't have such a capability.</t>
<t>In some other scenarios, the compromised REE may ask a TEEP Broker
<t>In some other scenarios, the compromised REE may ask a TEEP Broker
to make repeated requests to a TEEP Agent in a TEE to install or to make repeated requests to a TEEP Agent in a TEE to install or
uninstall a Trusted Component. An installation or uninstallation request constr ucted uninstall a Trusted Component. An installation or uninstallation request constr ucted
by the TEEP Broker or REE will be rejected by the TEEP Agent because by the TEEP Broker or REE will be rejected by the TEEP Agent because
the request won't have the correct signature from a TAM to pass the request the request won't have the correct signature from a TAM to pass the request
signature validation.</t> signature validation.</t>
<t>This can become a DoS attack by exhausting resources in a TEE with
<t>This can become a DoS attack by exhausting resources in a TEE with
repeated requests. In general, a DoS attack threat exists when the REE repeated requests. In general, a DoS attack threat exists when the REE
is compromised, and a DoS attack can happen to other resources. The TEEP is compromised and a DoS attack can happen to other resources. The TEEP
architecture doesn't change this.</t> architecture doesn't change this.</t>
<t>A compromised REE might also request initiating the full flow of
<t>A compromised REE might also request initiating the full flow of
installation of Trusted Components that are not necessary. installation of Trusted Components that are not necessary.
It may also repeat a prior legitimate Trusted Component installation It may also repeat a prior legitimate Trusted Component installation
request. A TEEP Agent implementation is responsible for ensuring that it request. A TEEP Agent implementation is responsible for ensuring that it
can recognize and decline such repeated requests. It is also responsible can recognize and decline such repeated requests. It is also responsible
for protecting the resource usage allocated for Trusted Component management.</t > for protecting the resource usage allocated for Trusted Component management.</t >
</section>
</section> <section anchor="trust-anchor-compromise">
<section anchor="trust-anchor-compromise"><name>CA Compromise or Expiry of CA Ce <name>CA Compromise or Expiry of CA Certificate</name>
rtificate</name> <t>A root CA for TAM certificates might get compromised, its certificate
might
<t>A root CA for TAM certificates might get compromised, or its certificate migh
t
expire, or a Trust Anchor other than a root CA certificate may also expire or expire, or a Trust Anchor other than a root CA certificate may also expire or
be compromised. be compromised.
TEEs are responsible for validating the entire TAM certificate path, TEEs are responsible for validating the entire TAM certification path,
including the TAM certificate and any intermediate certificates up to including the TAM certificate and any intermediate certificates up to
the root certificate. See Section 6 of <xref target="RFC5280"/> for details. the root certificate. See <xref target="RFC5280" sectionFormat="of" section="6" /> for details.
Such validation generally includes checking for certificate Such validation generally includes checking for certificate
revocation, but certificate status check protocols may revocation, but certificate status check protocols may
not scale down to constrained devices that use TEEP.</t> not scale down to constrained devices that use TEEP.</t>
<t>To address the above issues, a certification path update mechanism
<t>To address the above issues, a certificate path update mechanism
is expected from TAM operators, so that the TAM can get is expected from TAM operators, so that the TAM can get
a new certificate path that can be validated by a TEEP Agent. a new certification path that can be validated by a TEEP Agent.
In addition, the Trust Anchor in the TEEP Agent's Trust Anchor Store In addition, the Trust Anchor in the TEEP Agent's Trust Anchor Store
may need to be updated. To address this, some TEE Trust Anchor update may need to be updated.
mechanism is expected from device OEMs, such as using the TEEP protocol To address this, a TEE Trust Anchor update
mechanism is expected from device equipment manufacturers (OEMs), such as using
the TEEP protocol
to distribute new Trust Anchors.</t> to distribute new Trust Anchors.</t>
<t>Similarly, a root CA for TEE certificates might get compromised, its
<t>Similarly, a root CA for TEE certificates might get compromised, or its certi certificate might
ficate might
expire, or a Trust Anchor other than a root CA certificate may also expire or expire, or a Trust Anchor other than a root CA certificate may also expire or
be compromised. be compromised.
TAMs are responsible for validating the entire TEE certificate path, TAMs are responsible for validating the entire TEE certification path,
including the TEE certificate and any intermediate certificates up to including the TEE certificate and any intermediate certificates up to
the root certificate. Such validation includes checking for certificate the root certificate. Such validation includes checking for certificate
revocation.</t> revocation.</t>
<t>If a TEE certification path validation fails, the TEE
<t>If a TEE certificate path validation fails, the TEE
might be rejected by a TAM, subject to the TAM's policy. might be rejected by a TAM, subject to the TAM's policy.
To address this, some certificate path update mechanism To address this, a certification path update mechanism
is expected from device OEMs, so that the TEE can get is expected from device OEMs, so that the TEE can get
a new certificate path that can be validated by a TAM. a new certification path that can be validated by a TAM.
In addition, the Trust Anchor in the TAM's Trust Anchor Store In addition, the Trust Anchor in the TAM's Trust Anchor Store
may need to be updated.</t> may need to be updated.</t>
</section>
<section anchor="compromised-tam">
<name>Compromised TAM</name>
</section> <t>Device TEEs are responsible for validating the supplied TAM
<section anchor="compromised-tam"><name>Compromised TAM</name> certificates. A compromised TAM may bring multiple threats and damage
to user devices that it can manage and thus to the Device Owners.
<t>Device TEEs are responsible for validating the supplied TAM certificates. Information on devices that the TAM manages may be leaked to a bad
A compromised TAM may bring multiple threats actor. A compromised TAM can also install many TAs to launch a DoS
and damage to user devices that it can manage and thus to the Device Owners. attack on devices, for example, by filling up a device's TEE resources
Information on devices that the TAM manages may be leaked to a bad actor. reserved for TAs such that other TAs may not get resources to be
A compromised TAM can also install many TAs to launch a DoS attack on devices, installed or properly function. It may also install malicious TAs to
for example, by filling up a device's TEE resources reserved for TAs such that potentially many devices under the condition that it also has a
other TAs may not get resources to be installed or properly function. It may Trusted Component signer key that is trusted by the TEEs. This makes
also install malicious TAs to potentially many devices under the condition that TAMs high-value targets. A TAM could be compromised without impacting
it also has a Trusted Component signer key that is trusted by the TEEs. its certificate or raising concern from the TAM's operator.</t>
This makes TAMs high value targets. A TAM could be compromised without impacting <t>To mitigate this threat, TEEP Agents and Device Owners have several o
its certificate or ptions for detecting and mitigating a compromised TAM,
raising concern from the TAM's operator.</t> including but potentially not limited to the following:</t>
<ol spacing="normal" type="1"><li>Apply an ACL to the TAM key, limiting
<t>To mitigate this threat, TEEP Agents and Device Owners have several options, which Trusted Components the TAM is permitted to install or update.</li>
including but potentially not limited to those listed below, for detecting and m
itigating a compromised TAM:</t>
<t><list style="numbers">
<t>Apply an ACL to the TAM key, limiting which Trusted Components the TAM is p
ermitted to install or update.</t>
<t>Use a transparency log to expose a TAM compromise: TAMs publish an
out-of-band record of Trusted Component releases, allowing a TEE to cross-check
the Trusted Components
delivered against the Trusted Component installs in order to detect a TAM compro
mise.</t>
<t>Use remote attestation of the TAM to prove trustworthiness.</t>
</list></t>
</section>
<section anchor="malicious-ta-removal"><name>Malicious TA Removal</name>
<t>It is possible that a rogue developer distributes a malicious Untrusted
Application and intends to get a malicious TA installed. Such a TA
might be able to escape from malware detection by the REE, or access trusted
resources within the TEE (but could not access other TEEs, or access other
TA's if the TEE provides isolation between TAs).</t>
<t>It is the responsibility <li>Use a transparency log to expose a TAM compromise. TAMs publish
an out-of-band record of Trusted Component releases, allowing a TEE to
cross-check the Trusted Components delivered against the Trusted
Components installed in order to detect a TAM compromise.
</li>
<li>Use remote attestation of the TAM to prove trustworthiness.</li>
</ol>
</section>
<section anchor="malicious-ta-removal">
<name>Malicious TA Removal</name>
<t>It is possible that a rogue developer distributes a malicious Untrust
ed
Application and intends to have a malicious TA installed. Such a TA
might be able to escape from malware detection by the REE or access trusted
resources within the TEE (but could not access other TEEs or other
TAs if the TEE provides isolation between TAs).</t>
<t>It is the responsibility
of the TAM to not install malicious TAs in the first place. The TEEP of the TAM to not install malicious TAs in the first place. The TEEP
architecture allows a TEEP Agent to decide which TAMs it trusts via Trust Anchor architecture allows a TEEP Agent to decide which TAMs it trusts via Trust Anchor
s, s
and delegates the TA authenticity check to the TAMs it trusts.</t> and delegate the TA authenticity check to the TAMs it trusts.</t>
<t>A TA that was previously considered trustworthy may later be
<t>It may happen that a TA was previously considered trustworthy but is later
found to be buggy or compromised. found to be buggy or compromised.
In this case, the TAM can initiate the removal of the TA by notifying devices In this case, the TAM can initiate the removal of the TA by notifying devices
to remove the TA (and potentially the REE or Device Owner to remove any Untruste d to remove the TA (and potentially notify the REE or Device Owner to remove any U ntrusted
Application that depend on the TA). If the TAM does not currently have a Application that depend on the TA). If the TAM does not currently have a
connection to the TEEP Agent on a device, such a notification would occur connection to the TEEP Agent on a device, such a notification would occur
the next time connectivity does exist. That is, to recover, the TEEP Agent the next time connectivity does exist.
must be able to reach out to the TAM, for example whenever the That is, to recover, the TEEP Agent
must be able to reach out to the TAM, for example, whenever the
RequestPolicyCheck API (<xref target="apis"/>) is invoked by a timer or other ev ent.</t> RequestPolicyCheck API (<xref target="apis"/>) is invoked by a timer or other ev ent.</t>
<t>Furthermore, the policy in the Verifier in an attestation process can
<t>Furthermore, the policy in the Verifier in an attestation process can be be
updated so that any evidence that includes the malicious TA would result updated so that any evidence that includes the malicious TA would result
in an attestation failure. There is, however, a time window during which in an attestation failure. There is, however, a time window during which
a malicious TA might be able to operate successfully, which is the a malicious TA might be able to operate successfully, which is the
validity time of the previous attestation result. For example, if validity time of the previous attestation result. For example, if
the Verifier in <xref target="attestation-roles"/> is updated to treat a previou sly the Verifier in <xref target="attestation-roles"/> is updated to treat a previou sly
valid TA as no longer trustworthy, any attestation result it previously valid TA as no longer trustworthy, any attestation result it previously
generated saying that the TA is valid will continue to be used until generated saying that the TA is valid will continue to be used until
the attestation result expires. As such, the TAM's Verifier should the attestation result expires. As such, the TAM's Verifier should
take into account the acceptable time window when generating attestation take into account the acceptable time window when generating attestation
results. See <xref target="I-D.ietf-rats-architecture"/> for further discussion. results. See <xref target="RFC9334"/> for further discussion.</t>
</t> </section>
<section anchor="tee-certificate-expiry-and-renewal">
</section> <name>TEE Certificate Expiry and Renewal</name>
<section anchor="tee-certificate-expiry-and-renewal"><name>TEE Certificate Expir <t>TEE device certificates are expected to be long-lived, longer
y and Renewal</name>
<t>TEE device certificates are expected to be long-lived, longer
than the lifetime of a device. A TAM certificate usually has a than the lifetime of a device. A TAM certificate usually has a
moderate lifetime of 1 to 5 years. A TAM should get renewed or moderate lifetime of 1 to 5 years. A TAM should get renewed or
rekeyed certificates. The root CA certificates for a TAM, which are rekeyed certificates. The root CA certificates for a TAM, which are
embedded into the Trust Anchor Store in a device, should have long embedded into the Trust Anchor Store in a device, should have long
lifetimes that don't require device Trust Anchor updates. On the lifetimes that don't require device Trust Anchor updates. On the
other hand, it is imperative that OEMs or device providers plan for other hand, it is imperative that OEMs or device providers plan for
support of Trust Anchor update in their shipped devices.</t> support of a Trust Anchor update in their shipped devices.</t>
<t>For those cases where TEE devices are given certificates for which no
<t>For those cases where TEE devices are given certificates for which no good good
expiration date can be assigned the recommendations in Section 4.1.2.5 of expiration date can be assigned, the recommendations in <xref target="RFC5280" s
<xref target="RFC5280"/> are applicable.</t> ectionFormat="of" section="4.1.2.5"/> are applicable.</t>
</section>
</section> <section anchor="keeping-secrets-from-the-tam">
<section anchor="keeping-secrets-from-the-tam"><name>Keeping Secrets from the TA <name>Keeping Secrets from the TAM</name>
M</name> <t>In some scenarios, it is desirable to protect the TA binary or Person
alization Data
<t>In some scenarios, it is desirable to protect the TA binary or Personalizatio
n Data
from being disclosed to the TAM that distributes them. In such a scenario, from being disclosed to the TAM that distributes them. In such a scenario,
the files can be encrypted end-to-end between a Trusted Component Signer and a T EE. However, there the files can be encrypted end-to-end between a Trusted Component Signer and a T EE. However, there
must be some means of provisioning the decryption key into the TEE and/or some must be some means of provisioning the decryption key into the TEE and/or some
means of the Trusted Component Signer securely learning a public key of the TEE that it can use to means of the Trusted Component Signer securely learning a public key of the TEE that it can use to
encrypt. The Trusted Component Signer cannot necessarily even trust the encrypt. The Trusted Component Signer cannot necessarily even trust the
TAM to report the correct public key of a TEE for use with encryption, since the TAM might instead TAM to report the correct public key of a TEE for use with encryption, since the TAM might instead
provide the public key of a TEE that it controls.</t> provide the public key of a TEE that it controls.</t>
<t>One way to solve this is for the Trusted Component Signer to run
<t>One way to solve this is for the Trusted Component Signer to run its own TAM its own TAM that is only used to distribute the decryption key via the
that is only used to TEEP protocol and the key file can be a dependency in the manifest of
distribute the decryption key via the TEEP protocol, and the key file can be a the encrypted TA. Thus, the TEEP Agent would look at the Trusted
dependency in the manifest of the encrypted TA. Thus, the TEEP Agent would Component manifest to determine if there is a dependency with a TAM
look at the Trusted Component manifest, determine there is a dependency with a T URI of the Trusted Component Signer's TAM. The Agent would then
AM URI of the install the dependency and continue with the Trusted Component
Trusted Component Signer's TAM. The Agent would then install the dependency, and installation steps, including decrypting the TA binary with the
then continue with relevant key.</t>
the Trusted Component installation steps, including decrypting the TA binary wit </section>
h the relevant key.</t> <section anchor="ree-privacy">
<name>REE Privacy</name>
</section> <t>The TEEP architecture is applicable to cases where devices have a TEE
<section anchor="ree-privacy"><name>REE Privacy</name> that protects data
<t>The TEEP architecture is applicable to cases where devices have a TEE that pr
otects data
and code from the REE administrator. In such cases, the TAM administrator, not the REE administrator, and code from the REE administrator. In such cases, the TAM administrator, not the REE administrator,
controls the TEE in the devices. As some examples:</t> controls the TEE in the devices. Examples include:</t>
<ul spacing="normal">
<t><list style="symbols"> <li>A cloud hoster may be the REE administrator where a customer admin
<t>a cloud hoster may be the REE administrator where a customer administrator istrator controls the TEE hosted in the cloud.</li>
controls the TEE hosted in the cloud.</t> <li>A device manufacturer might control the TEE in a device purchased
<t>a device manufacturer might control the TEE in a device purchased by a cust by a customer.</li>
omer</t> </ul>
</list></t> <t>The privacy risk is that data in the REE might be susceptible to
disclosure to the TEE administrator. This risk is not introduced by
<t>The privacy risk is that data in the REE might be susceptible to disclosure t the TEEP architecture, but it is inherent in most uses of TEEs. This
o the TEE administrator. risk can be mitigated by making sure the REE administrator explicitly
This risk is not introduced by the TEEP architecture, but is inherent in most us chooses to have a TEE that is managed by another party. In the cloud
es of TEEs. hoster example, this choice is made by explicitly offering a service
This risk can be mitigated by making sure the REE administrator is aware of and to customers to provide TEEs for them to administer. In the device
explicitly chooses manufacturer example, this choice is made by the customer choosing to
to have a TEE that is managed by another party. In the cloud hoster example, th buy a device made by a given manufacturer.</t>
is choice is made </section>
by explicitly offering a service to customers to provide TEEs for them to admini </section>
ster. In the device <section anchor="iana-considerations">
manufacturer example, this choice is made by the customer choosing to buy a devi <name>IANA Considerations</name>
ce made by a given <t>This document has no IANA actions.</t>
manufacturer.</t> </section>
</section>
</section>
<section anchor="iana-considerations"><name>IANA Considerations</name>
<t>This document does not require actions by IANA.</t>
</section>
<section anchor="contributors"><name>Contributors</name>
<t><list style="symbols">
<t>Andrew Atyeo, Intercede (andrew.atyeo@intercede.com)</t>
<t>Liu Dapeng, Alibaba Group (maxpassion@gmail.com)</t>
</list></t>
</section>
<section anchor="acknowledgements"><name>Acknowledgements</name>
<t>We would like to thank Nick Cook, Minho Yoo, Brian Witten, Tyler Kim, Alin Mu
tu, Juergen Schoenwaelder, Nicolae Paladi, Sorin Faibish, Ned Smith, Russ Housle
y, Jeremy O'Donoghue, Anders Rundgren, and Brendan Moran for their feedback.</t>
</section>
</middle> </middle>
<back> <back>
<references title='Informative References'> <displayreference target="I-D.ietf-rats-daa" to="RATS-DAA"/>
<displayreference target="I-D.ietf-rats-eat" to="EAT"/>
<displayreference target="I-D.ietf-suit-manifest" to="SUIT-MANIFEST"/>
<displayreference target="I-D.ietf-teep-otrp-over-http" to="TEEP-HTTP"/>
<displayreference target="I-D.ietf-teep-protocol" to="TEEP"/>
<references>
<name>Informative References</name>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.602
4.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.933
4.xml"/>
<reference anchor='RFC6024' target='https://www.rfc-editor.org/info/rfc6024'> <!-- [I-D.ietf-rats-daa] IESG state I-D Exists -->
<front>
<title>Trust Anchor Management Requirements</title>
<author fullname='R. Reddy' initials='R.' surname='Reddy'><organization/></autho
r>
<author fullname='C. Wallace' initials='C.' surname='Wallace'><organization/></a
uthor>
<date month='October' year='2010'/>
<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='I-D.ietf-rats-architecture'> <xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.ie
<front> tf-rats-daa.xml"/>
<title>Remote Attestation Procedures Architecture</title>
<author fullname='Henk Birkholz' initials='H.' surname='Birkholz'>
<organization>Fraunhofer SIT</organization>
</author>
<author fullname='Dave Thaler' initials='D.' surname='Thaler'>
<organization>Microsoft</organization>
</author>
<author fullname='Michael Richardson' initials='M.' surname='Richardson'>
<organization>Sandelman Software Works</organization>
</author>
<author fullname='Ned Smith' initials='N.' surname='Smith'>
<organization>Intel Corporation</organization>
</author>
<author fullname='Wei Pan' initials='W.' surname='Pan'>
<organization>Huawei Technologies</organization>
</author>
<date day='28' month='September' year='2022'/>
<abstract>
<t> In network protocol exchanges it is often useful for one end of a
communication to know whether the other end is in an intended
operating state. This document provides an architectural overview of
the entities involved that make such tests possible through the
process of generating, conveying, and evaluating evidentiary claims.
An attempt is made to provide for a model that is neutral toward
processor architectures, the content of claims, and protocols.
</t> <!-- [I-D.ietf-rats-eat] IESG state I-D Exists -->
</abstract>
</front>
<seriesInfo name='Internet-Draft' value='draft-ietf-rats-architecture-22'/>
<format target='https://www.ietf.org/archive/id/draft-ietf-rats-architecture-
22.txt' type='TXT'/>
</reference>
<reference anchor='I-D.ietf-rats-daa'> <xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.ie
<front> tf-rats-eat.xml"/>
<title>Direct Anonymous Attestation for the Remote Attestation Procedures
Architecture</title>
<author fullname='Henk Birkholz' initials='H.' surname='Birkholz'>
<organization>Fraunhofer SIT</organization>
</author>
<author fullname='Christopher Newton' initials='C.' surname='Newton'>
<organization>University of Surrey</organization>
</author>
<author fullname='Liqun Chen' initials='L.' surname='Chen'>
<organization>University of Surrey</organization>
</author>
<author fullname='Dave Thaler' initials='D.' surname='Thaler'>
<organization>Microsoft</organization>
</author>
<date day='7' month='September' year='2022'/>
<abstract>
<t> This document maps the concept of Direct Anonymous Attestation (DA
A)
to the Remote Attestation Procedures (RATS) Architecture. The role
DAA Issuer is introduced and its interactions with existing RATS
roles is specified.
</t> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.901
</abstract> 9.xml"/>
</front>
<seriesInfo name='Internet-Draft' value='draft-ietf-rats-daa-02'/>
<format target='https://www.ietf.org/archive/id/draft-ietf-rats-daa-02.txt' t
ype='TXT'/>
</reference>
<reference anchor='I-D.ietf-rats-eat'> <!-- [I-D.ietf-suit-manifest] IESG state I-D Exists -->
<front>
<title>The Entity Attestation Token (EAT)</title>
<author fullname='Laurence Lundblade' initials='L.' surname='Lundblade'>
<organization>Security Theory LLC</organization>
</author>
<author fullname='Giridhar Mandyam' initials='G.' surname='Mandyam'>
<organization>Qualcomm Technologies Inc.</organization>
</author>
<author fullname='Jeremy O&#39;Donoghue' initials='J.' surname='O&#39;Dono
ghue'>
<organization>Qualcomm Technologies Inc.</organization>
</author>
<author fullname='Carl Wallace' initials='C.' surname='Wallace'>
<organization>Red Hound Software, Inc.</organization>
</author>
<date day='22' month='October' year='2022'/>
<abstract>
<t> An Entity Attestation Token (EAT) provides an attested claims set
that describes state and characteristics of an entity, a device like
a smartphone, IoT device, network equipment or such. This claims set
is used by a relying party, server or service to determine how much
it wishes to trust the entity.
An EAT is either a CBOR Web Token (CWT) or JSON Web Token (JWT) with <xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.ie
attestation-oriented claims. tf-suit-manifest.xml"/>
</t> <!-- [I-D.ietf-teep-otrp-over-http] IESG state Waiting for Writeup -->
</abstract>
</front>
<seriesInfo name='Internet-Draft' value='draft-ietf-rats-eat-17'/>
<format target='https://www.ietf.org/archive/id/draft-ietf-rats-eat-17.txt' t
ype='TXT'/>
</reference>
<reference anchor='RFC9019' target='https://www.rfc-editor.org/info/rfc9019'> <xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.ie
<front> tf-teep-otrp-over-http.xml"/>
<title>A Firmware Update Architecture for Internet of Things</title>
<author fullname='B. Moran' initials='B.' surname='Moran'><organization/></autho
r>
<author fullname='H. Tschofenig' initials='H.' surname='Tschofenig'><organizatio
n/></author>
<author fullname='D. Brown' initials='D.' surname='Brown'><organization/></autho
r>
<author fullname='M. Meriac' initials='M.' surname='Meriac'><organization/></aut
hor>
<date month='April' year='2021'/>
<abstract><t>Vulnerabilities in Internet of Things (IoT) devices have raised the
need for a reliable and secure firmware update mechanism suitable for devices w
ith resource constraints. Incorporating such an update mechanism is a fundamenta
l requirement for fixing vulnerabilities, but it also enables other important ca
pabilities such as updating configuration settings and adding new functionality.
</t><t>In addition to the definition of terminology and an architecture, this do
cument provides the motivation for the standardization of a manifest format as a
transport-agnostic means for describing and protecting firmware updates.</t></a
bstract>
</front>
<seriesInfo name='RFC' value='9019'/>
<seriesInfo name='DOI' value='10.17487/RFC9019'/>
</reference>
<reference anchor='I-D.ietf-suit-manifest'> <!-- [I-D.ietf-teep-protocol] IESG state I-D Exists -->
<front>
<title>A Concise Binary Object Representation (CBOR)-based Serialization F
ormat for the Software Updates for Internet of Things (SUIT) Manifest</title>
<author fullname='Brendan Moran' initials='B.' surname='Moran'>
<organization>Arm Limited</organization>
</author>
<author fullname='Hannes Tschofenig' initials='H.' surname='Tschofenig'>
<organization>Arm Limited</organization>
</author>
<author fullname='Henk Birkholz' initials='H.' surname='Birkholz'>
<organization>Fraunhofer SIT</organization>
</author>
<author fullname='Koen Zandberg' initials='K.' surname='Zandberg'>
<organization>Inria</organization>
</author>
<author fullname='Øyvind Rønningstad' initials='O.' surname='Rønningstad'>
<organization>Nordic Semiconductor</organization>
</author>
<date day='7' month='October' year='2022'/>
<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 firmware for an IoT device), where to find the that code/data,
the devices to which it applies, and cryptographic information
protecting the manifest. Software updates and Trusted Invocation
both tend to use sequences of common operations, so the manifest
encodes those sequences of operations, rather than declaring the
metadata.
</t> <xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.ie
</abstract> tf-teep-protocol.xml"/>
</front>
<seriesInfo name='Internet-Draft' value='draft-ietf-suit-manifest-20'/>
<format target='https://www.ietf.org/archive/id/draft-ietf-suit-manifest-20.t
xt' type='TXT'/>
</reference>
<reference anchor='I-D.ietf-teep-otrp-over-http'> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.769
<front> 6.xml"/>
<title>HTTP Transport for Trusted Execution Environment Provisioning: Agen <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.528
t Initiated Communication</title> 0.xml"/>
<author fullname='Dave Thaler' initials='D.' surname='Thaler'>
<organization>Microsoft</organization>
</author>
<date day='14' month='October' year='2022'/>
<abstract>
<t> The Trusted Execution Environment Provisioning (TEEP) Protocol is
used to manage code and configuration data in a Trusted Execution
Environment (TEE). This document specifies the HTTP transport for
TEEP communication where a Trusted Application Manager (TAM) service
is used to manage code and data in TEEs on devices that can initiate
communication to the TAM.
</t> <reference anchor="CC-Overview" target="https://confidentialcomputing.io/w
</abstract> p-content/uploads/sites/85/2021/03/confidentialcomputing_outreach_whitepaper-8-5
</front> x11-1.pdf">
<seriesInfo name='Internet-Draft' value='draft-ietf-teep-otrp-over-http-14'/> <front>
<format target='https://www.ietf.org/archive/id/draft-ietf-teep-otrp-over-htt <title>Confidential Computing: Hardware-Based Trusted Execution for Ap
p-14.txt' type='TXT'/> plications and Data</title>
</reference> <author>
<organization>Confidential Computing Consortium</organization>
</author>
<date year="2022" month="November"/>
</front>
</reference>
<reference anchor='I-D.ietf-teep-protocol'> <reference anchor="CC-Technical-Analysis" target="https://confidentialcomputing.
<front> io/wp-content/uploads/sites/10/2023/03/CCC-A-Technical-Analysis-of-Confidential-
<title>Trusted Execution Environment Provisioning (TEEP) Protocol</title> Computing-v1.3_unlocked.pdf">
<author fullname='Hannes Tschofenig' initials='H.' surname='Tschofenig'> <front>
<organization>Arm Ltd.</organization> <title>A Technical Analysis of Confidential Computing</title>
</author> <author>
<author fullname='Mingliang Pei' initials='M.' surname='Pei'> <organization>Confidential Computing Consortium</organization>
<organization>Broadcom</organization> </author>
</author> <date year="2022" month="November"/>
<author fullname='Dave Wheeler' initials='D. M.' surname='Wheeler'> </front>
<organization>Amazon</organization> <refcontent>v1.3</refcontent>
</author> </reference>
<author fullname='Dave Thaler' initials='D.' surname='Thaler'>
<organization>Microsoft</organization>
</author>
<author fullname='Akira Tsukamoto' initials='A.' surname='Tsukamoto'>
<organization>AIST</organization>
</author>
<date day='28' month='July' year='2022'/>
<abstract>
<t> This document specifies a protocol that installs, updates, and
deletes Trusted Components in a device with a Trusted Execution
Environment (TEE). This specification defines an interoperable
protocol for managing the lifecycle of Trusted Components.
</t> <reference anchor="GPTEE" target="https://globalplatform.org/specs-library
</abstract> /tee-system-architecture/">
</front> <front>
<seriesInfo name='Internet-Draft' value='draft-ietf-teep-protocol-10'/> <title>TEE System Architecture v1.3</title>
<format target='https://www.ietf.org/archive/id/draft-ietf-teep-protocol-10.t <author>
xt' type='TXT'/> <organization>GlobalPlatform</organization>
</reference> </author>
<date year="2022" month="May"/>
</front>
<seriesInfo name="GlobalPlatform" value="GPD_SPE_009"/>
</reference>
<reference anchor='RFC7696' target='https://www.rfc-editor.org/info/rfc7696'> <reference anchor="GSMA" target="https://www.gsma.com/esim/wp-content/uplo
<front> ads/2020/06/SGP.22-v2.2.2.pdf">
<title>Guidelines for Cryptographic Algorithm Agility and Selecting Mandatory-to <front>
-Implement Algorithms</title> <title>SGP.22 RSP Technical Specification</title>
<author fullname='R. Housley' initials='R.' surname='Housley'><organization/></a <author>
uthor> <organization>GSM Association</organization>
<date month='November' year='2015'/> </author>
<abstract><t>Many IETF protocols use cryptographic algorithms to provide confide <date year="2020" month="June"/>
ntiality, integrity, authentication, or digital signature. Communicating peers </front>
must support a common set of cryptographic algorithms for these mechanisms to wo <refcontent>Version 2.2.2</refcontent>
rk properly. This memo provides guidelines to ensure that protocols have the ab </reference>
ility to migrate from one mandatory-to-implement algorithm suite to another over <reference anchor="OP-TEE" target="https://optee.readthedocs.io/en/latest/
time.</t></abstract> ">
</front> <front>
<seriesInfo name='BCP' value='201'/> <title>OP-TEE Documentation</title>
<seriesInfo name='RFC' value='7696'/> <author>
<seriesInfo name='DOI' value='10.17487/RFC7696'/> <organization>TrustedFirmware.org</organization>
</reference> </author>
</front>
</reference>
<reference anchor='RFC5280' target='https://www.rfc-editor.org/info/rfc5280'> <reference anchor="OTRP" target="https://globalplatform.org/specs-library/
<front> tee-management-framework-open-trust-protocol/">
<title>Internet X.509 Public Key Infrastructure Certificate and Certificate Revo <front>
cation List (CRL) Profile</title> <title>TEE Management Framework: Open Trust Protocol (OTrP) Profile
<author fullname='D. Cooper' initials='D.' surname='Cooper'><organization/></aut v1.1</title>
hor> <author>
<author fullname='S. Santesson' initials='S.' surname='Santesson'><organization/ <organization>GlobalPlatform</organization>
></author> </author>
<author fullname='S. Farrell' initials='S.' surname='Farrell'><organization/></a <date year="2020" month="July"/>
uthor> </front>
<author fullname='S. Boeyen' initials='S.' surname='Boeyen'><organization/></aut <seriesInfo name="GlobalPlatform" value="GPD_SPE_123"/>
hor> </reference>
<author fullname='R. Housley' initials='R.' surname='Housley'><organization/></a
uthor>
<author fullname='W. Polk' initials='W.' surname='Polk'><organization/></author>
<date month='May' year='2008'/>
<abstract><t>This memo profiles the X.509 v3 certificate and X.509 v2 certificat
e revocation list (CRL) for use in the Internet. An overview of this approach a
nd model is provided as an introduction. The X.509 v3 certificate format is des
cribed in detail, with additional information regarding the format and semantics
of Internet name forms. Standard certificate extensions are described and two
Internet-specific extensions are defined. A set of required certificate extensi
ons is specified. The X.509 v2 CRL format is described in detail along with sta
ndard and Internet-specific extensions. An algorithm for X.509 certification pa
th validation is described. An ASN.1 module and examples are provided in the ap
pendices. [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='5280'/>
<seriesInfo name='DOI' value='10.17487/RFC5280'/>
</reference>
<reference anchor="CC-Overview" target="https://confidentialcomputing.io/wp-cont <reference anchor="SGX" target="https://www.intel.com/content/www/us/en/ar
ent/uploads/sites/85/2021/03/confidentialcomputing_outreach_whitepaper-8-5x11-1. chitecture-and-technology/software-guard-extensions.html">
pdf"> <front>
<front> <title>Intel(R) Software Guard Extensions (Intel (R) SGX)</title>
<title>Confidential Computing: Hardware-Based Trusted Execution for Applicat <author>
ions and Data</title> <organization>Intel</organization>
<author > </author>
<organization>Confidential Computing Consortium</organization> </front>
</author> </reference>
<date year="2021" month="January"/>
</front>
</reference>
<reference anchor="CC-Technical-Analysis" target="https://confidentialcomputing.
io/wp-content/uploads/sites/85/2022/01/CCC-A-Technical-Analysis-of-Confidential-
Computing-v1.2.pdf">
<front>
<title>A Technical Analysis of Confidential Computing, v1.2</title>
<author >
<organization>Confidential Computing Consortium</organization>
</author>
<date year="2021" month="October"/>
</front>
</reference>
<reference anchor="GPTEE" target="https://globalplatform.org/specs-library/tee-s
ystem-architecture/">
<front>
<title>GlobalPlatform Device Technology: TEE System Architecture, v1.3</titl
e>
<author >
<organization>GlobalPlatform</organization>
</author>
<date year="2022" month="May"/>
</front>
<seriesInfo name="GlobalPlatform" value="GPD_SPE_009"/>
</reference>
<reference anchor="GSMA" target="https://www.gsma.com/esim/wp-content/uploads/20
20/06/SGP.22-v2.2.2.pdf">
<front>
<title>GP.22 RSP Technical Specification, Version 2.2.2</title>
<author >
<organization>GSM Association</organization>
</author>
<date year="2020" month="June"/>
</front>
</reference>
<reference anchor="OP-TEE" target="https://optee.readthedocs.io/en/latest/">
<front>
<title>OP-TEE Documentation</title>
<author >
<organization>TrustedFirmware.org</organization>
</author>
<date year="2022"/>
</front>
</reference>
<reference anchor="OTRP" target="https://globalplatform.org/specs-library/tee-ma
nagement-framework-open-trust-protocol/">
<front>
<title>Open Trust Protocol (OTrP) Profile v1.1</title>
<author >
<organization>GlobalPlatform</organization>
</author>
<date year="2020" month="July"/>
</front>
<seriesInfo name="GlobalPlatform" value="GPD_SPE_123"/>
</reference>
<reference anchor="SGX" target="https://www.intel.com/content/www/us/en/architec
ture-and-technology/software-guard-extensions.html">
<front>
<title>Intel(R) Software Guard Extensions (Intel (R) SGX)</title>
<author >
<organization>Intel</organization>
</author>
<date year="n.d."/>
</front>
</reference>
<reference anchor="TrustZone" target="https://developer.arm.com/ip-products/secu
rity-ip/trustzone">
<front>
<title>Arm TrustZone Technology</title>
<author >
<organization>Arm</organization>
</author>
<date year="n.d."/>
</front>
</reference>
<reference anchor='RFC4949' target='https://www.rfc-editor.org/info/rfc4949'> <reference anchor="TrustZone" target="https://www.arm.com/technologies
<front> /trustzone-for-cortex-a">
<title>Internet Security Glossary, Version 2</title> <front>
<author fullname='R. Shirey' initials='R.' surname='Shirey'><organization/></aut <title>TrustZone for Cortex-A</title>
hor> <author>
<date month='August' year='2007'/> <organization>Arm</organization>
<abstract><t>This Glossary provides definitions, abbreviations, and explanations </author>
of terminology for information system security. The 334 pages of entries offer </front>
recommendations to improve the comprehensibility of written material that is gen </reference>
erated in the Internet Standards Process (RFC 2026). The recommendations follow
the principles that such writing should (a) use the same term or definition when
ever the same concept is mentioned; (b) use terms in their plainest, dictionary
sense; (c) use terms that are already well-established in open publications; and
(d) avoid terms that either favor a particular vendor or favor a particular tec
hnology or mechanism over other, competing techniques that already exist or coul
d be developed. This memo provides information for the Internet community.</t><
/abstract>
</front>
<seriesInfo name='FYI' value='36'/>
<seriesInfo name='RFC' value='4949'/>
<seriesInfo name='DOI' value='10.17487/RFC4949'/>
</reference>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.494 9.xml"/>
</references> </references>
<section anchor="acknowledgements" numbered="false">
<name>Acknowledgments</name>
<t>We would like to thank <contact fullname="Nick Cook"/>, <contact
fullname="Minho Yoo"/>, <contact fullname="Brian Witten"/>, <contact
fullname="Tyler Kim"/>, <contact fullname="Alin Mutu"/>, <contact
fullname="Juergen Schoenwaelder"/>, <contact fullname="Nicolae
Paladi"/>, <contact fullname="Sorin Faibish"/>, <contact fullname="Ned
Smith"/>, <contact fullname="Russ Housley"/>, <contact fullname="Jeremy
O'Donoghue"/>, <contact fullname="Anders Rundgren"/>, and <contact
fullname="Brendan Moran"/> for their feedback.</t>
</section>
<section anchor="contributors" numbered="false">
<name>Contributors</name>
<contact fullname="Andrew Atyeo">
<organization>Intercede</organization>
<address>
<email>andrew.atyeo@intercede.com</email>
</address>
</contact>
<contact fullname="Liu Dapeng">
<organization>Alibaba Group</organization>
<address>
<email>maxpassion@gmail.com</email>
</address>
</contact>
</section>
</back> </back>
<!-- ##markdown-source:
H4sIAB/SVmMAA+29W5cbx7Em+p6/oha11qh7CIAibXlvU3s8hkhJ5ti0esjW
yGcetlcBKDTKBKqwqwrdhEnOb5+4Z2RdmqS2j9d5OP1AdgNVeY2MjMsXEfP5
PHRlty+eZtfNqe2KTfbd22J96sq6yr6rbsumrg5F1WVXTX1btvBpWd1kF9ff
fXd1mS2b9a7sinV3aoqQr1ZNcQvNwFfpN5t6XeUH6GHT5NtuXhbddt4VxXGe
u6fmj38b1nlX3NTN+WlWVts6hPLYPM06HNaTr7767VdPQt4U+dPsNYyvKbtz
uKubNzdNfTpyr+FNcYaPNk+zF1VXNFXRzZ9jjyG0XV5t/prv6wpGcS7acCyf
hixrtuti03bnvXyaZV29dr+W1Qamrh+0ddM1xba1v8+H5M+uKdf28Lo+4LLZ
t2W1L6vYTfG2m+/LtptDI6t6D4/N6//6EL6BtTrkxyMsMj+bn7pd3cBg5/Al
/ZQVPP1ykV0VpX7Eq/sSXtqXOWyP+6pubvKq/HuO+/k0+7ap8w0MTb8tDnm5
f5od9M3FsSh/v5KHFvhgv+M/LLLrdr2rt0VV3qT9/yGvqqId+Todw7I5ZH8q
D7Dvm94wdtTAorMGfp8346N4DqPY5fuiSUfwPL8tel+kfb8s103d1kASac+b
jl76/UG/n+r1511RjHVbbvpf9SZ9yP9eV/1eYbh38Nbvc/qW+0TKbw7w2m2B
JPrq+2e/+erJr/HXF/PnCzo7Td61ydkZfrvJ8+GHRd5Jk7/96vFvk+/bU9nN
DzDgbdF2yTd0UOuugX9ui2a+67rj8PtjU8NxqffS/L/85re/kV+/fvKvXz3N
4Pdnz+Y/QgO3ZXH3lNbBKFuX62n2rK62JR65Mt/DH4cjsCEgZ/gYz155YroV
dvVg/Gmkw2ZzB5xi/m3eAjsbsjVY4Gx5PO7LNe1OmwFzgE3s8gfU/ga40NPs
yVdPHs+/esw95s1NAUcbJ98+ffRo7Xpea8eLsn50d5zDdx188+h03MMxah+1
sEnto3/9+hE2+OirX42//Nf6BLwlX+/+eoe7esyPsNb/Ov/67ePH88eL42bL
K3hdrHcVDHs/X1b5/tyW7T9oLZeZNZ1p01m9nWhllt0+XjwZrNbjr/6hq/Xk
0VePHz2DWS9H5j2vt3M/uLkNbo5jkyX74Qruhckl+mFfr/L91T7v8Mgl65F+
lT0vbst1wWtU7+ubM1042eszUNYhuexoaX7VW5on86++Hl2aG+rmKN0sYFSP
2mOxbuFuWDV5c34EpwuuCOwlOfCPqLW2aMqiRYah00qHDTO8ev7X11ff/RVu
T1yN1y+X04vx+mW2bFu49OhQpKtxtXjyJHv1+spRyWsYZ7mVIzTL/lfRoHCQ
PYG171PGV/OvfjM6/bu7u8VNe8iR8z2CmRzGSAIbePTVbx69plHMb6kH2d8f
r+b3bbAc/e/L5oAMAdc3mRe/nj2v1ye8rGkq/a0bHXh9hI1ZwIGFi6OAK7tF
ci6qR7DwwD9xd368fnX1Swjvx2NR8bhR4iKmml38eN2AtAV/b8t9gQT2eLjC
//LLCQz4fn5T4ArMtw3caChWzWsYyJxkL+Pun0t1j5/8Cp54/cNfJhcC5bR9
Mn/65OLVZfYabmHctOyHE/Bz4N5AFC1x6wt6JqOHfvjL5YNJ0irxOaItpSn4
9NGpxZ1KRE/g/3CP6dl+1ErX8xvsel5Y14tdd8Dh0v78bxQmpya27G0rCj32
luMj44PfFLfFHjagWYgA9KikO3ZzWnfAI0X8nZfHR7RBIDsUIczn8yxfgRSa
r0HiXX5EnEcJ/jIr8e7LCvc5CEJdKFAGWYMsh3/BE2cQZzdFdld2u7LiD/07
a5Db6i5bFTCRA4waOsVHZwHvVWsCiDXPTngjr85Ze1rvuNH4Mh4nWL20kQAP
2wDgkmyB4Q9GsAjXO5yK21MUpOlQZ4caZCk8l/AafAyke1PRjU9KAWywCGkB
rrs8U1onIYEOBt6a+OYeZKP1eQ0HEB7sZHFzJ0aE5lSRdgTCIo6S5pjjRbHg
3TmUm80edip8kSHl835iz4kwUvB+UTvw+oavHjwJxdtjjevX1TgyWNFyu4WF
gjnmXZev37QBKR50FnoEr9qmPpRtQcMvjAxw+PCBGzquOuhuBbB1+CbwTh3h
cxBGYA5A3W3yfEvDQQLN6S4HmbvAJ3gUMO417GVbBNxA6qs6HVZFgz3X8GeT
tlVXsjM40RntOq8dPRuSZ2FSuDJbmFh2rDu++/fn7FTRjgDn6nZAXfUJyZfG
Fewx2lId4/bU0Eh0rG1mg8WF2xdv4YThgLcgNQM9tUTM/XHzmNtZxpRewDhs
C/AXPIu8XoeayAgWMmiLWb9FGm/WlO0b7FhHWiMVsAwQRxtyJucWORPQtwy2
t68tbiztZrLGsZlFWDIHeJvjnGdMYnh8oDHSUlpe6zzDP7L1vkRyg7O2L98U
sO5AZyt8OACHXYPKjR+UHfR7VxXNLFudgDY9JdIZW+XVG9xFT4FNXuK0gAir
7AYGB2uXSZswyoAL8ykMjV450gj5pPNZ2BddSkd8Ggo+YnjmgWvAo31OmE1w
wvC5rDD7JF4YPsIMs09hhtAX7O/+tMElxhfIFlFviET0yCpBXZRbmD4c3qq7
XIQXjtSov8Np35VAGMjEgMo74rL7FvhPkVeyKDQYWAu62ECa+pRJ6Dt5xfyA
eSQx8RaUn0ZoogAGKXwbyLItV+UezT5ERLBq8F27Pe3lpNBBcRSFVAdjqrrW
TictO8oCeVnRCZUFLAIOILs+H1G03Z9nkw3ByVjjISZCj0RE7RCrh2mvc9jZ
MGCavh1YDdIr9Cq3c2xcVQ4v/wWfViE+gtNYgJo23nrWu4Z4WGXLZFDBoW0K
uDYaOhnholjcLGa4F+/ekbb04cMMfmXJGH8vuvXiMgN2kwc9gO66gmO3vJzh
PQFEkqcj0nEooSLlQqPQ2aLgLnHlX+ENM3GkX8GRngUYuhsxDaXKfqq6sdH8
tLxcwN0qNx4xtUmeAweF6JCouCn2LCPUzERBpMNbQ9o1qWBdn/YbeJgmRMzj
eimzx9c8k8lAvivXWTyLf7i+vootAZW3+Cm3uCoSuuTGRue4QNkhyzdwnmkO
0CCeA1robQZ8Hb4ANgQiM1+6REb5GrqBFQUxPa/wSFmvGzy2OhFY2pJ4Z4/W
iP0Cm1gjC6c1a2E89CQyiAOs3P5MssqaTMR6FQUTZKFn5HZyDeVtW3RyrmGE
KGjkeCxg8YUX04gbWjbZkW6HtwJIcxuQ6bOAJ5bPY6enlhkqzGXN9zkwFhio
qhF6E0rfVcHUtCoc+6er7lSxPF/+HeU7YjKB25IhwJ1ew7Ie8nO2Q4PjcXdu
SSXGhd6AfFKiEE6rx68T1crdC9uHbC7A8p6YTPIGbz4STpRiYQ43+YGpo2rr
vc0GVqmcr3c4Chk1toBMWS/LWRCZRMTPNltevyQaeFFfq7ySgUK45rXa13ol
Sg/ES5FsDuXNrktnGHg+s2xd7IGCdzXae5FLERPXxmkbSHyuV3gwjvmZTOEs
JQFbxKVe7+tTct+C9JO9xiH7z/Auoct0V59wNHiU22x3XjXlxvrjgSMdQ89N
bxdqEiNA1t4zvQFLYbkrROn5oilASSguP/a+cFKm4RYU5bj1trnhRUeUQbfk
irkC0iO+1tYHOubYMB10nQFxoI6mAXtZ1TTKC+LV1Oel3mBNEbBxaBcewq3b
Zw9w0A/wHMGpnWXyEs+IxptMZhG+hxmp8Lsp2/Wp1RMrcogz+Jm1DldGjhWP
JJ7FGXRbhHfvnH33wwd6ij4bWu4+fFjI6cVGd2KsVUmLpaj6sKIFYl1Aj7Aj
eThRdHfCFEmC3cB9W5SNXI3UeuQLNW40irB1g2ocuR7gdSKnFoe8ZsaPTcFW
0IEKFVrh8e38FiTffIUcvh6/dlBA/TNIPPB4FtmS0MgMKP4O2GDD5B+pDiTd
TcJH7KtQIhcwixQZYqldWo7YgkkPsDCw/12JmkhsRfWMfsdCzyDDrWGyZXug
yUdJA9dhkb0GYg1+jDChQ1vsbwv8s3kDy2fSYWx7ZJghjg65y0lE8vgOtwZd
LlU/4W6pV9SibnBgAQ84MZWGxVH8iq6GMrKeTXGEV+kurHSUyOlJhQCSwYUt
t2fT52llqVu+ptqotVU3rL4iUfD9iKILEgc+QauFNDFuL8CXohgWeusDnd4C
169PrQ285Bup2CwyloKV5k9HNPLFbgJNh00Ab9DG0BQqhh+OQC5Ep2qcgG0/
GcE68ROlfpDGLomfVqnUgp2C5NgBMccLG+7iBm9lZXMkYcEwkb8U65pVhllg
FgZDL+xay/mmJdUb9Uz0y6KZQQYFUlBHWiQcENmYwOynAyl8vc/Lg9AvLDho
kK2dB79rs4EiXpJO0YphaKLbkq+EMbH2JZlEGxRvX15+kv455h+3XQNxDQ4i
KrjY4bbe7+s7fA4egA07tE9DyLI5ivS69I3szbicSzvOxC4GgpsSNefrJdkT
TZpqiv84FW2nrebR/gPvwxKW3izwJe0n23hru5MG746PCC9qNpx0Bev9tLTS
nhGtbDNc2XQBqYlsSTLMGkQi4rhR/gINBd+Hs6RjvZYLHO/RE17BzgrUgty7
5kdgucUIJEubUAwu/G1JjEIk+Fol27IDJrdlfYkUqEb81MnNaCu8gfkCYQJv
EuO42GZBnyhuc7SVqD+XV88Meqtii5wsV1IgoqU2YDwmmDJJMcfU2ZvtobDz
uDQTDg9DKJtW22x8W/6OhOnzsZBbRRQUlgajuVGtFSzlr/MjcTttIy4fG6Hi
PSQXdEukV8LaxfVn2cm6MJqIS6hkQTZpZAEyYBiHLTg7K4RoUqtWm1KOPgrM
mBfFCIjZxB0fAl4q7g/bIEbTdb4Jm4P4AZeJfDhCC8hfcYDFW3gK+a2OQPjq
JR9aGfhFHNklDw3er+pupi/wtzhf20G2mHzKqEBdWL+JSyvrlrMDyR18JZoD
COhw7cy7ek5Xzy179tKBybWE7FpINs7hE8eFIuqtbKTYGNPhbONk/dFlCXlf
V8ifDyBIo9bMpEj7idaIotL3djkv/aoo0KB0W78pNjOUI6iZLiorrMOgWZQR
AWcSNMQ8sjmR9Id3JTZWvD0iaQP7WrXrpjwixeMtgbI1y544FJI2zsrycPXQ
oZmJVfJ6+aXaVqt4Swf08Ml1itcfXHjrxKiywYUsV6fELNFmoifhbEhsqU8k
ntvpJ7WzsPtGd2t1AmpEu9YKtmKmtz0vBciGm1mQY0z3+J11qDYc2fFo1mAT
dvIRSdM5XCn7iL6Ii7TO7c6jJSoqYOokiHrBa87C/iaoumr6sKieNRLCvBWf
dOxbfTy6ke/eoRP8w4cZaCzoov3w4ZLHcSjUIsF8Scgj36MNE8VQXNsFuW6u
6ZCT+y5790UX//rAckK83vE71gZwY/SSPx6z13ASiqfItmvChZkazhTBbpdx
XUO3elPfVUhPxmH5tEGjUSs9lsWamLZpWTRXVMHbrC9Pz4i0RXjD48X+N3Jw
VqiRJv2kp/ppRlcQ81C+N/AGaI94heLFse3ZRgRg4C7EmczaLFO4F9LXj+hN
WExwFGoIjjlsenkLp+em6LmUyCfhSEwYz8Ty4hNAerwacPIafJb8Y39DCZhd
88tqDfeMiJsjDyXCKbdEDiC2YqNKSmQ7NeKpqeLeU2tys7Ea07JdBImO+MrL
Fk3sdPrP0XnJT9HwqQmZwqDjPdtaYF9GR6DaqogBNn5SMemFeAqj4UWMFSjb
SWt4FbkraOa3e9gjDBUFNLk10NrIi+oas83eNTJ+WImUZImMnkY1k5wZd/mZ
3VXsiwGtFw4GaThsrkGjx0zFILKgIzHb1XQBawCKJuhS0ijZkPCuQAMQtJv4
NkFn0x3hj6gdfOURecz4ramloFEVqH4eUblKLWUkX9Ao6UTHoap4o291w2Hh
5rGGdu6PCx8n6wTcufCEWk/Ss5w1aCtso16IqzYz6cB1DmelLsmTMr7ZyjuQ
9/ZWiRYo3dCfWt7P3elATNGkgBOrnkrUL+PE2ki9cCch7rXwO8d2j+RZchDS
HidbbMxRbss4hBZtlHBh1XjzJC+1eg3lqIGS416uCtYwduUe9ESybp3YbV+i
8wwYaEeLnx+7+ni5yH5M7K3I11WUYVkHLYB+TcjuWlTrwrbST5mX9IoM8fle
0BCEh8S1FTsZaT83J9lvsqTrXtl5Z2XNMV4YMy8qXotjHdDhZj1WGZGoJtgS
S+qkrJfr0z5vRIfAS11ZBsp7JDfciszHNtytG8Y3ga8w5w8aHwsZvFe44bB7
Dcy7PR8OBcK6szfF2daXlpeVNDxlJzRvdoXaKg+F2hRlYV/ld9nVaQU3TPbH
4oxL2sAnR/4E2yU9k27kLZtvyUWyvwFFptsdMtY5t6VAiy9wgS51hvi+ejfX
zRno46bJjzsUgWIH6J9pQGudmU9AT+br0wovLB4ejO4FKKsIZD8xhoau56s/
vvhLtkYD3pYn+u6d4Ho/fBBSNFxYXFFWekXI29REoA16ieC75es/Lx4nVnJc
WnTq0Hp9xCH4lEWNnqMeFTdSSuUM4KLcIGJZGHuu9uDsx9d6Cv9UVqe3s+zn
sgJhCpj8sto0dQnqQfnj60u+tr11AT1LdfW3U8UmaNrvWswYwNYaMpT3Peyt
jWYH+wZ00cKl+41wavWMymYCdV+0l3K506hH5Ws0aLnpo/FbZJUoxZjvtcKu
yG1t1gxnE7xQAVCce/szT3tPXit5iEzi7IcQkvZCEGwHmjG36rkk6kDIunkB
BG+OQje2/WDJLcO3+D5QhQAQyK8rGnzH/jORKG/LHPkAUSm1oWSfC2AVfSlk
+WctJ5J+Ke6oaHralDfQOoMOURXzNnLxTfomfQvmujFG1aoU6608eJMqcKpI
5xpNFDzBBeP/zLooa5qJkyf35w5ZYY9zmNpqR1aEzZaFUri34EW4ljvVGkCN
q6t5U8Np9EeaNGamyaTPkf023WVq12f9Healxre4fblRvP7hH2/52cQetVgs
WGjVm8WcJvw6Uii2lyw2NTPLEFWP/dGWiPR8VqaDh8wPJIFjPchwlsC53Bw9
JecjC5Md8BMECLSpBp7lNzleXYl/Wa1CuOJoYtkUcNWbsSVR4N1OjEAwnvbh
IHCyZ+Zz7PmTZn2khrkGRBkG7hF173t6TqzkT/sqIPOxVt/kDeyrWoL/kcaf
RR9FdJ9MOU16A7N3E6mFcCebR+r910kZk8Wjgqi9LkpO98x0kY192xoPHpUr
WO8+tZ6xs1zmTK/MBwbL4DqEe4txX41x5q0A2+l0y12qBiryN9D8RhaXgWjD
b5xPYWp1UfZmzXaw4aLzqmmBzxqZF4bzmmr9NVrHhk0jp25HRxyNFMQSdWZk
J9+Lx4cFUDK8NSLm1fqLwvVEIiK3vvScp/6hkSVYZN9H2MZsdHzUi5gg1fZ3
QdfenP+6ZKobVYdKEwxoNnzbkIhIjGdaUVxOjcRELlAHUF4sNszLpCd2gXjf
R+L3mHmYihhac2ebNeOu8xKIiVetkowzJurvWu4PNVJkAy0z+YQy7gF7MpHY
9/djN+PSOR+BAtANyedcK+YmSLCa1tSnYNcN6RihmmIg57uMXFm4HTcFECbJ
mLs86q3Ilv7jVBCmS9xOajKVXtcY0LpZqAzRMEzc3PIW0lAWztqqNx9axfRe
0OtM50wmI9xVhkiIewcu0hI+3BAjRsVTMVr7M48hAab1QBio0BK0ohZXosEP
YETdXaFhL33WijjLCt3c0RdESNOlrgMu/UzMXYTywjuU15oBX5VsNDlUa9NX
rpfChKahhINb1V1KYhPFJ8YbYPZHZy5quInRddmSQfknWJlnBOoOX3yRXTFa
CiM4BDiVjIAuMAFWCZmIib7NdtCZ2y0ExRCbEIpGsy8OXq0i0hPe9LBluQHg
tH1BkhHR0O6NbVBgzB6dc+A+aORUhVXlHnTeg8S55biJvGoZFC/+krwHE0sR
miS+rMpa1PC06eClbrYbK3fzIiRje8mz5TtKUA86R1KQ+8L8qdrX657hjqYV
8FuGYfUmLRqd2FeWdmOTdYIQJNscPX8/vbhMxNGR7YUuyGaGEY9tvndW7XBE
ZkoIGpgIiUaGG6GdhC6Z1UY8pwzgCJyYoZ2EucODmciI4gcAjb0sBGGA3Arn
61znjG4kEgDl6rhDJtZGK8PViz9LV7TPugabsj3u8/NMUQZBcXlyoOsVGlCK
yE5jaIYbPeo+pw5+W9CxWSaAXSYt4CsdweLkRCADSB6bRV6LmyA6StdiIgEW
T1ObCgfN4Yok2GoyiroFwfsvfXErRoNWVNm7Yr+fR/VJycFQfnBxBEK/p63C
sPADteegxQSmrskOyL6/QwNkCD8X+Zs4caCq4UPZxYv6+tKZOlt2kh7rlkkd
MX46mbIj2wmcjCaPyqZ4AQ3Om7OpASXPGHFDiBeZP1o6Gb0POnbBTAoBRFV9
OJOaKnEbjK2iBj1sFU+po3kk9ECEjpHrx9M+l11AaG0dra3x/MJ213VziQ7g
YIeD+LE6S1Lkc6TlHiA83skYdNVz3VwzLVNkTGXWnRUCccjb4G9e7gAmGWy3
jFh60qUB9Nm8TcaFojlkDwzVZIfwAbtKtmy/py463nRSPATHS545koloEROp
h834MZoGudP0N6ZppqGgc0IElXnV2RZ29SYHaYEINw0uJ0CwRXET0yyqnGNq
5GhObc4a5g+9493fUcwSusoICR88En4W1T/6hTHIBnINxHYaXS4SNMQa60ai
p3GngxCCxAZIgqZG9a6Vq7GRm3WtUH19HcklNo4RhOL3FvYiQ1LeK5hXixER
l/kO7eEbjttTMhJLoQwAN74CftOxa4UnVkvXrURaMrtMWuEILnJK1RNTY+g6
x+psAuw2R+kwXEQCzRTvnW/qo9z9X6Q5YpAeJJw+aokhvHsHwy1RpcbgTiD9
dlffCU4lL5OYGtpSNfIKV6eLgyU1QX2TMPD9aY+PGHaj5Qg2awqXCLcVr9T9
2excgkEmIzOs576+WzBf1Sg/aAWdzL2AIUVbg1K+TwI8HA4wb3K6K1Ai/D/w
g8Ljw/nn/GDymOy9qoOf9PM+GzU6BPtq9MeG9bDXUPxhJd7a6U/kYfrS+7Fv
Y9vWzHtCgjzu9fqeDeRpMw8HY/LNpDN4TwN8j7lx3sAuvXftv+dXHrpWXTOx
Z2nmvZ/Uv8WBcA+/ex+/epg0s7zBi0BfSQb/3v57r2v5Hh3bsAz3zijrD+Uh
t4EP/u59NjGU3pJlWdbf7vduku+nFuYhfyb/jZFS2gzO54m8HGxHfvf+ejl/
DE/Cf0/ikJNOXTMPk2GGuGi2zHFX8Od99hO0S2TzMNk5P0zXzGBSSYeeBpKf
5+bAfu9XLCFUGMjjZNeSdgZgl4nBxk1NG4orOvyxVxLieX8fB0hfGW7/yE+6
UtbQL+FxxBvfPc2+8NcCZ1n4bw/+LJ8lN4vAXK8efLjf5ChZgEasaSDidHCl
/V1iOiRgJOKXgHxTtKmLDF/c0594RTclQuv3Zws9oJY5hkIbGR8W6izFHgFH
AhjgsfB1TPE/45ArkTA6slltY9QCeUrk5tRRfbr1nyDWL8eAXxLtil1YEgUH
Y2Ktf61R7NWYwbpGaXqX77cGYhpbUvO1jq6XSERidG9TYLta8NUDM9qPuAk5
LoVa6RlEKUUWUMk8Fyw342RFeSuOY1NzUFvSOPcF2iKObFwdPs9W6p2i5BjM
hmEjiPvCkZk1xiKb2BnzBlVb2OO2RHFUzPPT1AnTGqe6CE7BPr9stSN3BmJg
kIRl8MYotMyDfBQmbkeJCE5cokBOQjstWYsdvYxuTx/3x1AwcbI5OY3FwgRu
fCX3v8IQMR74zIt9AJmdHFlqp+RjRvKkZDu8GYm7VmMvGwLpuZ4SWVogOMmT
9zUuq/KzIZuTbkX41fBFh7dShBdo/pjVp59yAj1IxR0cAp6pxbxpFC61yDpG
r0nFLjerssNEQqgRVor9p68s6Eb6VihYiZFgDLDj6I9NcdzXZ05dwLNPUhvo
0BN3jcbjKZsSm3zV5esuWTiORbFYg7sczoBaJdy2i3ufXi87s6inKWXIB9zT
R9AGjtkVJMGMYN9QKUUbD/7PHk5CVABjpCSRqMESsFCdjnDmb8n6cCIOzEos
A86dI58HTCZUhJtElLOBm+/L2qdeazmEPKxhYxFgLFrPqUL9dYBEcaB5msql
kCjfAmLTZKxCEkS5ZVAYQVQpI8AUB5qx1RBa8057hJwyGKLS6Gy6Z8iPvzdn
fm5IRUs9cz+/U+sTKGkcC64u7LOj/RYRnNVpmxM9KP5XCXSdN02ptxA5H1Gd
ZxAfIi5l6I7JjXnpeDxT7FeQsG0PFgcrrgH23LtEewiTptAO6Wl1jkZPsigQ
L43iikV0TL6lTkli/gnWhrZsvUOcA95gXS2Mv/JOtwQzUQ6BqOhvJI7PXJr0
acHddAnmxDC4vsVx1+dHFhVpC/ZKG5T9ggnGSLYYqg0zvSvbXXLdkZOFBAJp
A2Mj++uDa+PhPESmHoWDiRv84mmKDCPcBGnyy2moRA5dEP9UyTYmegExQgQl
WBX1W9stnUa5jl7AI1HBBJVyZEbN0iXho4CTgxXTB+jKC2nHN/rnboZ43nUx
ShYCzmH5oPVj0+YJZs4pOHC3ZIzoT7RAZjkX7SQ8X2Fbcjnlm01KTl9yq/8p
mtBAwNHJSaxYjIiWoA64AyRzFpEm8cYIK8JggLOLgFPi0JBwlsuy75UfS3hi
zMBD+PiDRhYQLgvFtcl5ugBjB/L6sh2l8vRSQX4FK5FzwhaUNnbl0WtLKSFh
x6P8WWHtsFqHXpgdHltyAJVVspj3jW9Psg5e7JQ9yIZLSwDMgrAObgHo9kLr
nzMQjAjaw4Glq5hudpa3xm+3MKC5RMCbv5U0uSj0PGVfhclAnA3wY0mFYHav
FEl3D0xXMRh4GMRgy3J0lCCKt4gAuClU9lUUgpd/ExRgb7ybulBbLeXAMUld
wB5OZRRsA3LzQ0E45BE9lWR+crCpxI88KvITpvzETcKvAa1VatWHr760pmNC
Ibr0saUXZhtgqtVsHxoYQCmoJXIGw8Al0I2uQRCJUdoXhWYsdaOLY6Obsoxx
xwNEDe+ga4DkWx/P9uHShfjJot+p5pmvWg8/VoOCXViJsBjlTHvfXGDFpqcy
SQy2J1iS5Z/G4EJWfQhO6hIggRx+2hc9RSxiWwTcWKyLErNY4H5KgHxLsHpB
qhAZIMqFXLVu7hGBYjoXuRYujTBlWDFSnXhA3rRF7Ek0b6CcO/RN2eeKghpO
yCegYO1U4onpSpC5qTsGiC915ePglByVskVdavhzTbOU+yWRNFCYM2r9xlHx
jIGsEdlDbU2umWziM2NbSI9LwUCfs4tnhLLJni0tF6mPIWxPmNSDEdss7zn+
h/5dij2hXfvL4uuvfpt8zVlzbmvQqSS/Ek6BRZqSJ61Kt4GFyk6iY/NeyMN/
f/X9s1//9te/xZgHauKZH4gkfKliOLFX9dnxrCIuLyLdpfeqJOhX1ww9CkAm
cVxg0jgSOhDPlmZLdFmtOsk/801PasKnRcOTTHYg25Pljzc3SRUjV+oziaD3
8LHVefhccvUyLuOlzyDICys3XkgirVi7j27xJPMgLPkLldwkII9gEjFkB9W+
dpejiOqZVWA6EtuPUynkfLapArIIf9BcPeTNpicuEgvf6x/+AvsA/2LksAQu
kBAhqXFyy2AYM7qByCHAwkNxqJuzYSFzDZHcM6yD7akpCHGBGHS0C2h6FZuz
XyKdsU0I2NJM0pbx5rpVcVFLsiSD3DouCoIeQJtIYA2ZmY5idhQtOB5NG3Yg
4ZDK1Iqh2iWT8VwC84dH/mC5R+zRZTB8CqXJJwUdabeAyZA6fMjJe11vJRuS
Rd5zPh5MPQRcTQDwgdkoRWajtnlToJhCaeV24wvLdpiceC85oS0hyaZE1+1B
HMIMPELfMSaw8Q088W9akiFdfzFdqOwzDikkwLw9KgJNqAThEaX6VrL4xGTA
ct+W0fnsLVu/0Omc+HM+1/38y5zPE83EH1F944hG5tTzME81lX3c+fy5bYz4
DIf+9J5Dc8rt7L28o05w53Ke8jk7f+jQA/4++Y8dtVnSyONkCPyvLFEcyMO0
kY+sRt/zHR24Iw30FrrXwL/No5P4vhH0PNXpCNTzjn53dbxnVzUcybNfihFX
dbL26v11vne/JwYP8H7qhz0aMMfv+1HaGHVS91EQrg32uqdu9/f9F/T5Uad7
Dxpwn5P74Xza4/7vrrf7/NueXPpucv0/cbdPuLyju32slTF3++g4/EuDhkZ5
z3tdQHnIHY7hi8xwnvguBq73h+MvPky+HXnRVrD3orCR9/Zi33P/fvJF4ifG
TgYcdvrFJ24FhuQ3+WJ/jp/8Yv+Jz+vx4S94EbnCr/REy4uRLB7e82Iy4vfy
nHB6ZisfG2r829i7vnH/4sS/ZYuybADU+sgF+7D39/0gkbGfz4aITABEnnwS
QmQk5TmCRl6kYp6kSvKS3eOY6WToZma1uZU4xvljroqRCoaf/voTg3VKyDTq
KWG9Q2NqdSNqLuvxZUzItz+npSxUFyV7ubNWwpoFHcJAV4oqBoUDOPeTlZdJ
A4DYGk/qhDrvJDERpuoTJWkjBR/udjV+HFVKS+Bnup4mvg2WUTIZFQKddyz3
uox7lbM1j/krGusI1FpO9ZZorYiqwA175c3NnCs2YPEEUwVSz/ATjINODCER
iRvVr5JslGyC6Oc3FWMSx5amYUMvpVIE61Ri4GONRmyU6SaqxhgOuVRxwcZU
CeVwCs1ENqp4sOE0yfYdmI5ivu8eWiE1iJFCeTqYLmLue82YN7P8M5LIsr9V
pMyKTzPvRowmZet2mvIawDV+4Gz+pYUTX0YIOGGeY5z+YLii/8JcviMFeqxH
MU0hPVMs58xSIEp8I6evJV2QEsCVlIU+jIeVJpa2CavQIiYLGHP5UdW2TkEi
04GrsqNViEmOXP4TyarGWVItAmI8+5ahAOhpjAWCo3yIwaSmtwMxFRVajjDd
oeT6yttoqOLHOVw2hsoiTEAPo7Sg2aY0Ex5HOZdbdELdIadw6XaXhEu4x0fK
Z6iXDU0PfWIoGV1RzNfhLfxJwMZ9+yirLYmtOGkXefCp7g7j2yktMqc5dnQK
J5zjYCS4lpxwC47/1Ozg1B4dlCEarHYJe3p+2RnHT5IIPUhkQl/aqzeFBjfB
bdoUN6UUrOg72+71x/Nog1Zo2kx6pPHU1s2GcTqH/G15oEfYvXUsoFNBOJLf
iLEmHIXgHdL96aqfO9YyMVoc2iUI0MFnC49ITAou+cZSD3oIBtWK0dGfl9F3
uGriTJQswhPtKGhIQmbseOJHTYHBXfD5eZYOLXBYBnEytI230zY9Bc9psVAx
1WuSIqyVQGk4X0YzM+Oq+M4eZ30x35rVRWgnwulzAfokm8BuB0nnhSdkzo5u
V6hox2yOQjaLJCFZUi1pGhBJJ4hM+es9leES7oChNmz0w+ye4vOGZls12BLl
yDBWI4Q9udRftnGV52ziplPMiX0K6JEMgttevC6dAWHh8YV8AmvBFV6yb7ls
zRAYEVKPQOpd5/hiz29fsrwWB84JPgkbY1MPkT9J6iR6x1AmQ/qQ85RKVObJ
y81pddEWfKO84g+ul9ny6gXLZ/kRiw9c3i/qJMkix8SQPOZSBDr76dWLKN1q
aNC2npJSYnS987Id81bi8VM5ZBFebPuiCUpcG1cxYoReDeu4cjiLWb8hvfeS
UwOzCQrOlaxkmmKD3teZ67rRNvos1WUfnYoYJsy5yynHqAJOdAWbCM/gy0qQ
7HrLwWh4vVZwvVStbv4APrAYxcUGTM6Li1x15NMVUhlfs16G0NGH/GlE9yFL
Bcyyi2qNrI9M9GeDVvbz7s8UYS+vnJPDMUJY4rMMlkw8voplgLaKF41D4IzT
mYXigp5Ip4rq6g4QJUPq7sYAxhgL2BK0RULW2nhRkrN6g1o0Mdbe/ATAO0KQ
KDcyOB7zrVmNJFFpJC87LUP2n6HIUA8BhkROlfSB03SEBGvq+TNvQy99mvQ1
C+aK8TOMt51Q0tlyb3UgRh07Fy3LIs0Jbs49tSPueBQfXqsT0UJzP3ZFSHk2
q+Dqgvc7Dp3XSGQj48CKMrPH8VrgHz5IhAMlFMJFI5fe/UzSw5/hQISEQlFd
7KToW79Im+Qap7oNtOmzlLppMcZhh5OJpGT1Y0ok0gBf//TiOi6dq5jXH2s8
0JgV2AhNszFpKY3ZWF4mrKjnYkzgu2PrczXdOyjJj2HaBBlSLKCai5P0ylTH
CHHLj4YJ3yIG6IHF9XLG7AfZhQJK4NsbkGSPXEisZ3HwurXLXD/LLKvM0PQi
bmwB+VPbl3y7EF52RYltcj0oTsvpd43Ni7M3DkPx2pRY63QMcm8kK8g1+miF
OcxA2RKMbucA9y7cmZeFuSglK2gkVZeOFba2ZQL3GfZC+Al5mfCUUaGVxSut
0sLKiQBcJEr5PJWSWmV4H6Ls9AU74cxOx87j33DFUQTlh9QOCERM5kJBTkhN
6MCpVEoYKQZTTAhKBD45cS65Xu4QY4cdBR3BzgYtQMf5VWjabGlL2obWrpO/
kDLGcqqRVRZ5txoHBTz0FodXdik4lFNTy+Yb2HByYsFwXeJv7x8ES5R0n/WP
TQFUS+F4arBuLy/VPdofZXWY6g6z1RR5Q7UPorwtoqxyqPHGIyJkkRm+BT+5
y8/3aJJ0KilFl4eJUbktFCzy9RtMZkc5C0E2aDQ9hGcUIV69dIpvgbrYgIUZ
pIS6IxH7qIXpMSGWo8HSBdUG5YiuvuG3kJJ9gL5amPdnl7cCrVEEhHDppeRK
jJFlwRndJX2QM2zrK/eN8KJV5CT+qhkIFRAYiP1bZQVpF7MWUFrlWooi5hZz
ysmG3WLSqeXkQi+GtcJMfjNRmTiuqlqS+U2mQp6E5lYq1bmMHJIxh07s2BlU
EA1BHF2aXAXR9+uV4ra7rl1eVc7vJcKin71LNh0UjijUjGGSmBC9N3uaKC2v
ztZVOdvWTTTI+mpy901zEX5Us3PltdSD6A3aT3/p5FIbdDYLtj1JcBmVZOTS
Jg7HQ/4J68+EufGBhuthDjipOKA2XlwCOjlSL3Ta4i9EPMWBJXEUt6oqzIXV
N+ByB5zV75IKXzxmCvhlvdGcUNqUU5/ZqacjyiosQRSVMaWpPAeWR4ppLBVu
ywzDK+AaFSjGPcO+1s0YgwEpCq9wS6k4OofLWcxVmaTllspv7A+hFjwjHdtv
buO5ZrcD9hDTkpxdGO2Te9Y8KrrMoiJLHV1cXVdFIEugJmOZLTkz7nyMyYtW
SC3T4/Isj17r1FgsAl3sz8nMpt7z4Ged+6+wlsUgFwso7iIJdDqj9r5FSrxK
Sg3kc+WhuubMdB4LYBjvmY2IEi8tOU92YTkAiEPZXyup1YxyyyX3mFwqU3wg
y34tfqJ7n5zadIKC6zkaUBaHFLmix5+5cn7RuKn7Vi66n5xVm6b49SL77t4D
h0PQ2fUm5X1HZkuwefCoEv4UZxuX9D93hh3BM2GSGiJK/+TiLyZnGpmPGOhh
eNy8pBHtpKafrbEKsfdjzKX2YSJOkEZGJWAFOD6T0iFOdRa5BQSu+9h6G2zO
I6o7l1TQB8qhLh1TznlFOlECWwZc9JRrdb+JrELXrBy0eHeuyoqz/ZFVedpC
ErZ6qiV0+3IxEqnSjzbC+lp7rs5xHplbMNuZVgO0VAFptExMgyaUJxJNDDeO
EwF+PcEyXjgHmyQCo8BvKqCVQu85T/yu2B+3pz0nmsOqv1K/sZ9s3IrXxsqc
ST0z1h7OTk4jxfCL7Ds2fDxNuMpzffxlFOsku+Eesfk0EflLU2H+cMI4m+/e
diiQ4ogu4EGRzz+qZsSwoISVoFWW7Z9yUi8wg2v2RHd+mQWp/Sfyqj5HjvRU
384uFi0V11ls9vvL+24jrPdlJ4v16ooiEoBu92jtscp34++LYk7vi/Ozbm5g
GYUWMElIK1lCzuxq5Xs7pHYLHzbzMeFCUUZkCY0VbeOFI5acgKIzReaZyIpu
ATK7fERx5mXx5WVlebJ0eYgRBU5ewvVPadfa7Ffzry9HihdNOUDJPBIL40XO
wT3qKKiWH11uUqpNrU30+eZc5QcmrRkL/6qBdSzpsx5Hz9JcOHaE50CtMfMj
vwjs5o8rSVcn/KDfOXkiqG2zv1mgBBvt8ObDfRPkBWlLnQJ21pjuMUphuKpc
G+AFLTFdAKO8hRO9SF4RGYgeoYR2L5heLjl21d0fAXhQg0icWJyMWZARCt0T
2BbZpVkXuUcykchJuS+DHU0rejd+WQmxPCbi/vpSTU9cfinTskSyczC8NxXV
2aoD2S05QVPHX3XlweB3QhSc5OC0HiUxCXNLrgmsq82IRBgO7cdSrbmTKe6T
K4kL3WreCPo65d2XgZg7ec7o6yhjmDag0k7ZzdxN3UUuGY1VBTcddYBY+ZFr
dGDdNUnR5G7DUqzexVtYSLaiTu+tDGdwSUaaZ2crAt+ipYQPboi1l6PJTNQd
3hAvzo0bRcP3ZcVHelJX4abcxU5mjTggRExmF3GpmVzdScF0UXpoQAgBddYw
SK8o+DhNbHU8is4WuGdcAaZCNTfRzpusPqGhp+uQYcgzjnwTmwpjhxoOtGyq
bKLkGNioRAosLl9rxn4kA/+6UwUZh6AR3+TbYD2ph6e0MFrXDooUy5ZqxpLV
VhgcllrFEbZqoBtV23sV0fXajUWUYslWJmzOud5K9eXCF3LK5LYSBiAFXkNS
1NUZrFy85SLjynRsJN4yz92pNZdTCWDmcJCnJOwvlxz5lMsnXja9qfRoi/Yh
GFQ1R9wkjtVhfEcqvPq4UMQUmmVoJuHrZDfrtSQZ26P7O8GPfq4EuGzEMfi/
gY3QrZR8AtK7/S4uzeWclj9i3z4qDxL2qFGkNCLX+sqzkDrzPHFX4uoypy8r
NyC53zAhHi2L5EMrqx1xS4QslWTeVvaPKtv48DT9gbWFWafW6LQnbeiHvyw4
gwbBofgGXp1D7n2ZLr2DkmrEfU56GWN6Z4lN1712LWP133bgzMYvolsioCeJ
ayBkT+a/Zo3uP6QYPE+UwjNTfHlPCCA0ybLtleVjPynfL8QWIuz5tt7fqv41
wfRIHKpFMDP2BccvEQUCjherr4qVWGZGxypiQdkA0iEYDHXFIA3yKzb3pFrA
+MZIqogfr+b417t3/ItVMhaDNG+1Vn+MobBWflqyW0yxMjjTM3YZEqsh56XU
o2b51fGs4JQ3xqVwnmogObTXoHCl5n7Lc/GqwCIA8ys2jAOlv+TY6G8xV7sc
ysuRitQj3g1f/DpmZSL6le7Z1/gd5xYwKD+aNtBx6M3wWPWkodwfeaz+6JL5
o1oUXHB/EfNiaQYFkFPNpSPZYCIqyaUz8TkCilbfBe4aDMAiVnqfdobzwvmy
Baui5xEk5/1JFHa9ZWvmT/dkLsLiPTg7zYsDrx8VRivp8RpYbcF3tmqTx6rD
i+Aqs0WAoKV/ufXR3b2Sa4a2Xt2TDO6bLJTsRy8OK4QMGPJnU2zz075XmDlq
GG7pJe5GGMVLuaiToQmjt7qAybcYHs5h0hdYw9uw9O1llvFHlBGI/sKUqBzD
dPHcpSK/xsQ4mPSiFXPuREBUP6xx8EUMj/rUNi6+w4VD3k+4m6LpLrN/m88/
q41PGAeGuWU/FJ3aa7Gj7BMit/7R47ivjX/TITKYPhnhP2YcjxfZt6cSpJvu
riYs8NNfPpexn89o4wIk2Hi7/bI28Afpe549yRfZa7hg4GKez3/3T5/L6hKP
J2zfk5Ubh/787p81jnvaQPL/FdqSWFMcHdg/Yxz6/68XIChjzh+4SnxCAG7D
oiUx7WVTshGLQyVF+I5sDsRxfQbDIt+9i+9YXQZXZTkKg2QnjVEQKzwYzPGp
ql+QM2KYjKdEs1Mmv2+ICvDoBh/g0mrp5X4RFVGyMRWn5IMSSIdU0pXhcnya
A1ZvYqiUGdqjVfMllxF3RSK4do7DQhPD9/mIoEsQ7joy72ePexEYkiFTyrr0
VmQR33vSf+90NKtwmKhk9iS/FNOk/5jT10lmnbgS/fZRQNKi9PekKmJBmQvZ
dRg1EAXNBXmQYouG5xMHPCtRTCr6Thh65VLJXLI5pa3GgoPa0GDA4vGxbG3L
YImvaOspWGNVpPGyZE4eKT+qm/KrmcBxOEropp5abvIPqjU49TkmOxYPT940
oNlHvDlNmuwe4uZhIw5i6kECvHSD+rWzvE9ayyzeSIz1agPTmU+FAFFlzfLm
hmCxqVkSY3FSk4w4JFW89TIZtZRGq+oBG6QS4w0C2RJFUlqMpJs2cUtg2mA7
rt6wQFaUkWDOxOTYRxVx5cz2jYRX41Z/yYB0DV5igGa/0G6YqOuZBP+RQD0B
/cQpEJhxjJhbMy4bKHbJKbtlZNkWzUJcaJxATms4KglCrJcF6Ho3rKszBigL
gsVnVLHkECZXIbraLH2igmbJ2iChyeLwG0XJGgYPNzavNomuw35cVZ1iNidZ
ozTBne/bJf8LirA3Ze1LyxrJCa5iZn2u+5ykIE/J2qlHsMRWwzOgGSeGppVa
0YlLX3G2+fkRrQXFxnhJhsWwLFzFYLAhIYZYJpT8ZATEXknqzmiwdgUZrXJc
0BnotcgYNY8MBdJZ9dJqqo0aHRnMjMjDG9SPhJFnutzwWDyZYjviyFQ4cuUB
FqMh15RxpGEG+1hRbxCtFBe3V5Ew5i4dXQBLe09DmdlxOock+eNAV4wPCuRP
s3n2kiFSHas/arFAlxIwu6ZY03dfJGiK+w0OZAu3klCuwpxhrvC7wFVYqV5H
tWFfwMbV6/pYGYF37zC3LUpsJzhjmJK7lTlGyHRkpXrnWUFEupmCOXO5ziZQ
D8XIMwjskSIPKCm4BYbeA8ebGbgON5/O+U3R9WrR81H0yZBZ5GM1Ppfs39my
HxMUkpSRDna63hWwmbnm0kAHqc/Qy+XaYcWej+VOtESPMT20hRf3hD5afjso
bDWhOoCaM8CJylw4i7Op0yeaNLeG27as8PLApOJxgSP6gyvWSRWNwGlA6GCP
YJdpOx14nUnCMgxKGusITKbnY25Lx3wpmlZhJ9DZKy06iN2EV8vr12muFYei
gauwnfuzIIZ5RtIwKIl8apacbvDzLMf6w8zM/svYA3+qhVlL/v/7HsA/r2Rl
4UzT196qFK4YyJ820H+DU9C17gmS/MLQ5AFfTf5Ff6cfhGWaUlR+HiMwiC64
TEgtciv+QXJwIle/HeQTsR3+Q9oR9mifSAPPMPAJZ+mGYQ2ooUFhR+f4BIYx
jG5Cmv5v5EcKypm6SvQoiuprM9YhI0bV9M+1cotpQIIl7Leg1Y6ua0rvA1oR
SkISMjfViIN+VhQVp0ZROiiBuSVrk6WrQpvgufOGs04m6y1VmEVgypN7qTEl
yQvLwbPci37+WQ3mGEGjX0Lv48g8toQackyj6EZQhlm4D2EYkFVw3gJ7SQSI
uQsHwHYGTypU3meSv3DXew9zD5MBKQpjCCnoI/ROgy5rXE1T/WR2g5WFrv3S
RjAkDeWYl4wkT+4NYuWndjIVsDTMeqfU6bLUu1zkk0NttGPvpmeOnv2IeShm
vD42EoK7NpXH1+BI2fscOPjE2eZVO0pmMshTjzZwWNyYu8EKpJi3MSoIC83U
b2VPU9wjASVp027gLJhy/XI0s37chmTYyW0Oz2JuYoOB6tWOG6nbZHW/PNJV
a3KWVRDE61yEtHlZzbv8AHeRVPhEUU5wWsHMWbhoRJiy8LbZqxohq8IbuXKS
0nh0AiqkQZfeNEwJC9WSuiQRnrjUcs7ywN+wFLgvaR3cIVKbGrNDOWyC38e+
gNpIelLRCZFqJOxiqYcqEPtRhNQ63xSHnu9L6R92+F76n86CjbwqIXyfSP9e
woc+L8yPTFyHV26E2d3ClrtVSSvDD9f2ckC2YQSum6+RbdMsvESpXOXZMtM4
dVXkI+yDMJWs3go1hglqzMaoEWs55ciwjChlH6aiWz6+OXZGRmwKlloCmBTZ
ZzT23VfxodBaLCRQsITbxqheOd/CSLkocu/Q8v1N69VZ822vfR6gHu9SbHOu
18891UXhFvCLLwYuw/RyEN1tYifSDGfjDExsja1P7eC7VFxWijMGSkqWi69U
XAtVxtRr5XWMHedCQLqKTYFmI3iP3GduIc5LACTEkqpCI7DcU+suKedkLyNa
DoMoiX8QHARY0INk8loX8nr5gAePzw/WmkNLmVRinB9DQWa9x3tDbNWeoMxh
NLRCE8pp8L7mkEnGyk0SxpASVhEyUKEl5YFzYAksilrjFwIRu6KjnWTFqhwl
hpCqV8SX0k6JGBh8Meo1J91tqnKTInGxKCgFGxD5jBn4EjMDcQLJQ7HZ+KQD
ZtPb1OvTgY0E3xbbuikS4eimrFzd8dLnKBP0coyFzDUVkVxBvlQZMvwyYpA1
EyDo+0QSTX4n0l4g7ZZAyO3nFknCFWYsmrkterWS+pl17uMIE6zgg+PCaev2
4sc4QHYR58tVp9JCSa1gejzftpyJFi/t5XQHynA8Gu+iQPYOwhJtVSdRWcGO
mGIW/3+W8iksZTJ8aur6nqYyOGdjVAaC6EeoDA8oG+Nbtv589Kr5yO0iR1dR
Iu6SYSGJbmHmQvGgb0dTpzmLvtvrpOQGA1rzfncxDRWea6bl9MxjyFZydpzg
ouCediZ5g7pciwZS8hX0iuAyzSisHI0B2/pUSWqTFQHQ+GvBBW9P+y3MunWb
f6QU8CAdlxQAyBv7Gs6IuATGTL0y1as/vsAcmC7l0XYummdy9Bc9QuHUTklC
I7LtM8iqb8HGBfMwNYNZ6Tb0HgiT2KuZGANekpozAKOlaDiXuVbzcvGMRUma
cU1Ncvkdig2VNX22TG20eDZp33nXmxo2KLkAGM65tSyiFacUCdT0QDKiUoaS
giwynx1oXJi3lbaMwKV/Lu4CcrO6KfVgwNOb01pkeOwH1S9qp1jXDJRkA2sM
HAoa5EMtcfKnG8ZD9SadDdQIgsVxEIBmoKHZt4ZaZeMRs1NNs+iDqkji9ll4
8lUtFSyr4k7PnIwNhv6n8k1xV7ZUIfjOsjaG4TRnohwJJ2frP636xuGovKk+
yJWsQVFuPiwmYd0h/VRdZEKb6oWPN1ngCEhNixG1K+JI/cXhfF7esROkppjC
PlxdOpsjiTBAD1pd9rYuJVxOM04DnVYgivEI8HJZ5YLHR7APUYmQzIakFPzQ
Uh3K+W0CfTyZZzI+K7moxQPwWnT+EF6O+zjR35PICROO1vAxR2s27WgNiR/D
9e84ujAXcbVysuyX5gBh3dV7ap1N03m0nCMrdctJeoNnvXwbZZtES6v+TwxW
E5Ec8zODZS7EaTJt+/TzLrBVDMGfwZXTWTIQ1wWe2OgKtWpQQG0/teypi4FT
MgTWL0BaZtStJEHhe4/0B7ZJN8A7zE9MSyvoVbxcLIt2jDjHSNwQfbVqaiVH
pfeXvvuCvb2qyAqP1/TRUk9sAgpsCQo80F6Ldotovav5ZGvpxixJZpaGFIQY
UiC2Y8mExNvkMQpyflEY1WT3rQT6Bin/54O36ma/4VqfhDEad+Q7fIqp9R8v
iRl60HzsT+busvRU2evnfxwgV8J4Dvie0xavFjEKGsqN7pAtpYpBfjQBG4EZ
/8cJg2Q4IImBOgnERQXEcdtPyIdRwzVyFlygqVhcDak3krCF9WW0Og0EonAx
xRB9BI9DvHsmC3pf7y0icM5BUt8dQEMmI+KWszdQyrQWZLbVVCZQstT5NMwi
MLl6aLBFmAHC0l2O5YilDLxEEX6ILyy+kPN+Iq1zQGiy3umo2XODOVSjhBdr
1n/aAoba10Kdxp2NSRn3JJpGTCXlw+OL6lW9TxVrqZrZP1K9anxJTKoHgYRh
PdYE4ZVeCyIM8OWFHmw6Nwm0LElqOHFyJNWD5Apm6KKWzcsrKjZL5TwjR0/d
+5P4C9IAgytAS7Pj2yKmNxbOgeotjZIuGqv2Jr/EkhKWRfO035CEJAUJPUsi
YwkcyrpK3l0rzkmrOSaFT4KP5dJ8vSY7SxCP8+WTklt3DfwDMsd813VHDEgi
+a0NI4S7YcHvhMWRpXQFqoZod5dct3bAFAIR3aJi/5bW6LY0JsXVeOG5Cxv4
ZVY0De67NORcCl4tbQm5ReUFc7X6k00CPmoJ3MCZwKgxFluaIoJHQJpIHI6R
JnhIKEFq+Nt1DCwuOZ64csHJIO06fFF6b6cJzwg1hrZzPuYY5ArMq1x3ao3g
S35OcaGI8Mi6YYowwqJYTYaEXaslx9XqlXotB0kuvy0w7A2LvzatpMpMI6/7
N39ZBRpNtpRE4fSH+fpaTBSACVo4UqfujsCHulkUiWh0vYSTpcLHlNIEUyM+
M3zlEeWeHntvwFZVkNEJ3IM/wZ+XOAGK71jyB98KpiHcC9FXRET6H78yKHnk
62ml5ZskDuC9tXflv5Yqf70XGcYhf/SWpF8ga9DTvWO7HXuj397Yz2f08e+T
84/7LB+kBQ37b/xDZ/4+XYBPmHn62Wf08e/JG/whzvri9WW/3X/izHUBPn3m
n9/4v8cpXz+7QvbzP3968ezeKfvS3f/vzvz+iBz6ecXnPP4XEU0Jo1Zok+dK
xGa0IBnbIPnhmQfqCSMm/g43cQoFoUTryBWdOd7x2BhzIV1KfIYLmUDvhIsO
6OojZ7hVwYC6z3qaIPHQ5SBLMOUqLzjLDwPhybpK77RyL7SU6S0VH+0qalpF
a5uDGkTnXb3hGi8uPnkmjjGpVQ+Pr09No6mg1ZRKmF9JUsD1UDQVle9/efUC
cb0kILIY4jC70HBxJL2bHmOLj8cdRQHIy71PA0YMWskKLIiO6YQtLFUrVlBO
Yh8nIsHUschZQ9n57tGTLs3tnhSbmaq6lcUcrzHzAXaR74GQNuckJ7e7TGHh
nixgBM0/d06YPbWuUCEazo4I6dMm+NHZURncVKzZ3qMroe276tXiiB8Qc5L6
56rosdvCERMs6K8W2RVnergGaVuMgLiuKteiB5uA4SZnir1jJkFwlqoZexyC
3rec3XTNif6hx18bUXLF22foQcQedwhCkp2yBEI5eQCbywRBchWlDYoxR3lf
gsnzdXTXqGdNDLczU0WdOYWtANgSCvuaucH5lqWKQwhf20p9h7L6gPbSASYK
Ee6+Wk5R9Tp1K3QNGRdyOoSqIt8TqO0AAylbrntIvkRmARSy7h03OFtkVgr7
zrX/3hmjl7T8AVf8SRJkYzvOd4alt2phJDL3Z1xSZXz2ORv8cUptQThrwg+S
AC+H1gXPRCf5k08mQgJMOAu/6+peehRqSAjxe3LCMbgnIsNlSeGywKXG/FPF
R3XSEY7+3Gey8IrlSBqqA+khDiuS5d0Qw6HecI3HCmaP8Il4LBDQZwrNo1Y7
3xRomyfT7TKao4P7XaMENAOM5lmNhRQKznlxgdGI9B4eUKse+kBN2w9mholD
e6yEdXHOyC0m/iixABy5clj2sHaz/8WQgUbSN8d43NMWSK6kTLtNTfe6nDpu
jmFPzQlWKUZYaGN8cDQBmi9KddMUMihxAHBiHW+vp+64cBUz873/WjAS5MBW
C3pBGYW0c3J1Aw9uNm6ar4o92aKusMzhZbAgVnSJPvC9w9qCZt2mK8q5tq0m
V29dRULQ/jmJyZvC8HCW26zk6ihZdvG6+EWxFJeuckLeNxa4WcybGrRwCQlB
QOYBkfxSyUASh+c9OqwtDZUcCMroF6lOgNuRdwZ6IF1Y5U5DoADaxHzRWUpe
2JV0WWCNyVO575hhxadCWulM3PkU7Iy4GMakenQSJlJkoZe2hisKSIahb2jd
goXHUZ52R9A8dDrqVKsBx6/nK+uFzQiRzMgguCm2ZUWcXGqWakTl8A09O1Yq
zdfQYnhWzOu48ElPmb22xdjMNMe9RnASRpMqtvA55AEaMedscW2RPcHKtcgu
CEpMSSapeWc0GapQXAZaAG49ZSrrq11JKXF+82GqkMGb3+kys27IQSz4a/wi
bZQb4j7F+pJWt/7d++xCKbNX9xq+0pOqJa3h4UjnvdLg8IeQdmb10eXHPfd+
ampTi+JvgcHU7lVbR/RSoq2ojA4YQaKQ+p7R5g9Kqe1PWFrA8F1TdpK/iORZ
jQqRAH5XrJDcj55Bk/uGU6wVlVElOt1Dvm7qtnXgQ397WCq3pErhTDtpDaAY
LxTXb1A1tuWIbkqH7M8XaQPr/QlroSlGNL+p0NG5tmSGfD7wRAjpzUKu+iEX
DCo65KV1k0xMXtR0FWyU9y5w8SUY5V2MamaEv95jTJtTWJYvL4nba/5DN05L
Fubw8vU2MEQnokiSEmxcBc286nDUrapM6QOom2Jd31S0a1Lag+/i9I53GFCV
YvAhv1Q4jrbPD3V5Fz68eARj6LYob4e7NMaUzZ9k0Fit8pXui4qr6c70l5oq
otwiYgaujCJve7UuhdULX9fKcDzARRZD2fglchkilCHBZexvQErodsLVWYXZ
lv2CjHFNSJH6JrQflyFwan2RWtuZEDEyX4cE1IzTYcW1b9feVyG3pUuD6miL
0lhjfa28RAUg2C3ay4cvJi0G0lGVkXn2MwEaNT7mAAtO+NY8hVh3BAijfpJk
axSYQDYz4SWPkG9845rewYGltOKc8kRyjLt8Cex71sh79h67zaIeomVMmkat
Q8rQI0C8xqrKSWYyIxGtq5b3Zd6yjnalGIGU0pfrDePO95wn3urg5Nstcj1G
W/bHLAHRcNNvQdJqhI0f6o1j6hyAhJF5O0xMS3J3vn6T9Our22w5KzKaSrjX
3lVAPbuXhUMQDiIz2DkSH6p4XEgCJ8OBb+TKK9pvyO5nbTTFrcb8cpQ/vXs2
7sP56gejsNQhiOfyyomzvsoO+WLVlmPbYluifMxXi0Ct9XrUmoxS+7Md60AQ
/+alcrD/4UW7OnVDHsB3UjvZg7vtXIisXxOH5/p+yAUsBqGXp0MOdb7X5Sat
nZSMz40VX/Str/7CIkdyX0R2g3maMUGIEPqCsxSQtPciNvM0kXV8+3TfCu/i
6Ne95To4JykhzZOL8tFPHCirBi3JjaDUGEurSujvWPH2qBHF0H9LVhTLq5Jg
u2y9Ts71DleIfzkaTEib5gdJcoiorViPBU4AATG03ElXUw8DsE8ajFe40cYS
35qZUqLiSARwxgLM4a4LSZ2Y65ddxXXDiUhTsNVMypSKOTbPni+X2QvEp2LC
BNJlPFb8xfNYK4E68YRKZjV4f2BRIirc5DkQX7ZUQ4gkEKMy3OS8EZvM7o7H
e/EHvTHIhXOJG0Zduju630eRY7AA8wW9yngjy9t83Yshb4obSoNwM0FX1Bnh
DLD+XnS1Y74KLjec5C3zkcbCNYEdTp6Qa9+SpNmxPGCSHTzhGxL4Y4lBNnw0
JPE7MZxWC8H2p+KPINdQ4aWdWcnVWXovazvxwtXanZJUWMOjVRHEqSyyQbB0
v2MHGsE3jdd41g/cMD+sypuTHgSKHNZOPHh2qry6+Ks0YqsvQeUNRS0kA/XS
zEyPLS2JqD5u9Ave3u+h7V2F7V+h4QyNuXQLiNSvW7K1xxJGqNspV8XM5Y2u
0IPBR7gheyjQwOHI9kwVWWlsnssubyR+4t27V98/+5ff/PY3IGfCZbcnE4kT
nQ+SAQtdJ42H0KPRZ4PhcmfEEpu/0EcyozJgI8BqPoW3bZIsQfZbDuLYFhxQ
ranwuLBD3kqLIBnRkMkyLqXJb+s925MxMxRuNIYaUOFJyghPvCd9O1WvwiYG
yMPiY3yOkLDe4FKvRJL8OtidqbH8ckn5ELIGXSMqcEludnYTib8KjkTgKALG
1bagXnfHXV2JZ5Rspbzg+hjJ9OjnrQJGUxQNAbdf1NdREWciT0H0LmXOxE55
hUY8cebSomIgQEPPeqsn6DbymjUV9ygJPGIiZ1+XOn4aYn9xVRE3/bYTrnY1
842k6pYFu/cj8adKTSbhelOVsYIHMOUf71wF/oiqZ87AckGIDYgsO5IUSFZr
4pi0usSCIQs+MaSKQmS1lnZGbSwZrMOuqvf1TYmiY8wafWotlSc/g4KSVKwn
A7oAKjWcJYw2eiYLhNg0FuShPUhlsn19Zi4gkgeOn4RWzHHONXC86KXs0kNG
va3IjdHvlEvLTWKLa4b4ngZxpMC9lmB+4vjh+CqSFVjCTWLIfOCKDNUJYbNh
1sRZvPB5cJyBziVKH4KgsdhEmqhNxiaZ2tBo7iq+3p72eN3jbfoKcbujnlVX
rQKuiwtMlUH1wjmZyOp8CcPZc9H0ZUuXyEzjZ0ZDRdgCLTaosBlUwaNraNzR
yzhe0lzPDGk54tqGtGJtT3OKL0sSf+AQmxOoms/r16rmhmE4KBoGgHWV8MG8
KVht8ZkDYqzwSM4J5Rt4hYv2betufYrzyHUkmW/UkQjbVt+cCl3fJOvfUr7z
mE9B0iMvx9rPJ1rOXhIaGT1B8vf5qSLgaFwJFGo0m0eOWSjrTRBOGs1Qmu+I
GmHgfrYBdZnV+D1bNE32a824MUgiSglq7JqJCVDQCJszsnjYLbkHKSQ6vkYY
nmEOOAosTsIeYQgod3TlDUa+OArg2PaYzAV4LCs98QoILfR6KJyc1O1QtKr3
hKJoiiPLhZYOCl37ZkSjCheUCE+QuZb7U+wT47lLNWHkhdTd2eMmkRvv7HJV
5nuqXIZH4NJfCWmRCEJ5WFF69J2y1rbW0khDzAg66LMLg9VrNPKhyNUQmBIw
goIoCpTKPeUaUsb4bK5HpQG4EunHJtsTQhg0GcLGyn+I3ZRUanpNbS4okFPi
YMfNEJeAXB9NjBbui8Uej6c9yioUl70r5odys9kD02DChacpcJhhYFPZb7Of
9rB6XNiW9h+GyoGbWkpljYVBxIAeEzVA6xxEn/hcK62zkXTo8wn6G8uMqA3s
GBAnJydrO9VOhAeViGCRRF7pRC7qzmLfUPzecAX3oISMVw8etUvDdsHs5vV2
HufG0QpMuU3xN+L9aYJQmBRBCvtkLByLR4iVW6JVSoqPrEkgdfmLOaIVpIyk
6L3Y4Tq+8ZNiFi6gyxBx3OXH404W4WcqEZsPbgv0Am/xmmPpqD3d3HCapXaQ
PeC1CIl6UIibyHWF3v9NwfkWYeRryRtMNzJt+CIWanW9ExeKpTs00ELnl0Bc
hONwTp2GL+a843uQ5xV43mRM4CQnnAfAuBJDK7p+6R6S47qYQLQHrYmV7xgV
ImfcBbYqwI/D+sX0l8Ij2NqiYpyDHvq0Ja0TQ+6K3DLHUutBq8iqnnmo4Wrh
rApW2/Zs1O1Ri5w7PG89m6wlawoyANEk72d4UvQPgbvwNaddG+l3FGMYOCPu
EuPYqdoiNen8IFYsKzroNFJY7iY7Y7hN4+FRHI9CCspVvNDCi06NXibBsFam
aqmZM6kfkiU4rI/sj6D/JF688mPN4aFMwcTOWJooWywY2j1uGhld/r0IYrnC
xY7QDwIh/7GvOABjrLXGHlW7x0MgzhkdZS76BYbYh3ukOyDSZKB+JzTZCKxR
gjiVlAPV2E5KASA0feJ5AKWBclRRlT6aXqQ9vue4E8odbi/M6GpXZCuvDlVh
ank04dqZI4xFRvbYxrwRMb3KUMoNfIlZqXfmwPdtlPdY8YKFfINUxDq1Y9YH
KS5LB5isKCC+cVg7s0/By9NZhXUPI0Ske2K5pGNXID8PBH4Jq/4g2RlHouc4
OvQ8cjh9mCmJDaWhbImirK0/Ec7elElt+pJrNmdRA7NOUSPlvEGUPEWoW+Tp
F1sChNdaBS99VVInpDr6qHHjI5sFqyybzdQeo/0XKZj6njbI0GJB9OI98G7h
Eyhn5d/ToPu+xSXWfs3H/TuL7PUIlrTn+N4R1s1cJKEVm5/JbWoSIMKz5IrA
xPBNx7FSag/Ts2f2+6x3b7z7oq9kKkeOlZRVD5YgdXNQSV1OeXmRhZ8LcWCL
3a3FkyQboxgM4pICZxafCpbcbuCEqLS7x8QForYEshPGMWu8BYONlXUdarg6
s+dOlyIYpnsxvIrCY7R7kfBZmd556pzMhOZmKfmndP0lxt6zHMU2A8x1QJ6x
ut+faiFOZBBVN1H5HcsWn8n1rui3E9Lz17cqRGMFY43woOdSv0bmQs5sc2IE
KyKBGvMMtUZgZbOoOn88IFkQ3SYc34n86rR46ZoDi28l/FPJSL5kpAMihvDm
SwoVJsG1PoaU7AqUQWIhTnVKIAnDJtojhfku79a7TQ0bw+oy4htXJC2wZNNx
XfCNqeE48KDUGTV3IglSKagTUO2+lLwWWnjZUluwWZR6F6TuukCuUQtb7NMG
QT3bN72QWTWDDhX5fjJnM/10teG/4T60yJCxjPlIpD2xHdMYVqOCvNWUhsOz
Og+oDl585ZLtqEKW+Ud5pFJ4Oaj7BRu/iyvJi0Nb6swvaRprKTts7wdXZI/t
N8zgrqNYs8ad6JuVirc7GAqnEioYMuMy9VGY/2DlyaovNSRmaYtoe9F8O230
CeORTXmj5ATqHQ+Y//FYuKrDNqZopQqJARdvWVw4NlyQFEcmwQFxRSOS6WUV
kHpMIr09wb5RhReQcz81uYcCxKoCj23eANG/6GK+BF46ygqJeKI9KDBssPhY
hgkZI1oUPYUPQv76QjClvbF8VqCDrcm6IMhByUS0Rucfn9exve3MM9fPNe1E
bFEnGGN14lCVvSIlP5a+Ti7epbt78fR89/ZYNlwPdplU/0hT+c3j3lK6HUqB
BW9oIcok+RnvO2YMS4hvmAeTn0SdtWw0KWaSJdCZa3LrM2lAd53bQN6zSric
aD2skqf7pmdWVhalFa7lmfRwzLsd1pTSXHeqDCZGVhGHk+xoyZJQUk/mPb1U
cOioKAqzm/wGt4L8xl8/+devREzbcJpUuGmQfiKvceV0zMdtKTK3aR7OEEFj
bA7xE8Cr6CTvmtRM1xkllKCMYhTsI4FvmMyVgB+Www9Jn1LrwclBFlibx580
LyxJwLnWEKYzWGBNYmtqRKAAB0nTTlwY15ytIJQLUu17th2coy5wUNigfW9v
Vlv7SGxYUpyZ9RVHjWXfejaaMzl4YFXMz4n2Wr8oJU1C0BRjCX1jReJssBgi
+v743cs2ohUmcpQGSVVC8WGcQy91BCTGyzw92r0Mmv9fO9qaO/ATj3Y6m/Gj
3XvmP3u0ewf2c44pynLbYV5RJmjX5hZ5g2m94vvqCUM5JxZqT6u/iRdBDg6W
4mF/Qhgnz19wVFPq9AdVtJ9feFDRRP1pJ3SiHsPU0RzopBjZFZ5bwrpPIjL0
kxMGeJDbvCcakTsYtX4SGiyHDYtxLVdd2eQHCdElg1bCZlk5VNe3eY1kT2XU
P95hJkaqjRmRTi5TQMI8Ja+/2iL2aFWWfLUrDO7EVJtjszDrvEr7hFSQCvZj
PtU4gFlIwI6wwZielrTpo+n27Od3QjIGfTa3Ku2Ik53nEszIaCHwyKbiu4oH
1lj4WgPw9rHUKklieOv1ZgUHRNLWt+yBi742AWfwqrLtSsA3Ck2h0ZUiCO/y
8SpibSx7cE8RBrXBE/SfuB+ilpAST5ppsV1IkmPzwfld05h0kGpzFir7fBuN
UxK0oEgkl/SJDpZew3zPm/JK1lym4tnAhpqQpSivVDZur4kqMJOxsWIUUPwq
W7CiojsxhlNSpFM5hJkKSgo2iGo1e/B7tMth5ksqv4yBxc/+5KO3KW879Ycv
i89pTB0pNJHlEQ0jnQwvasLCYhaUSoL8wGxNzTl1x76+4RTnFJOay77pQJ/y
FpN9qiUTURB35Eph/81mVFOiFGSMkLPILdPTKfxszrKecdBkYsGi2hNz/qT+
lMYLSPxCfzYLzP6AayB1U5ISbH0ny60UxburG7TJcBFGzCTrjmL2ir1b46bC
XGAhsbxuFII4lkZbin6iJJOg4t8ktSwlQE5YgQMu8D2PM47XrwVmg/R8FFOC
4leETjGn4VmVdRaSJOhGMhtG7tXzylyQBG/pHuQ1YYHAKHxjXNf1egkn15mz
YjpO8wGZ/2PZXi6mXWIh3S0uRDbGKTV4HPMrcqjLlEVB4gYS0xJnhUXjspw/
PAvmP2VXfZofXqqrgsZvSBrYJQPzoyFaqN5Oept4ZMWMoAYRCeNeklfU1cl2
YV6RSM9suG0zrHTbBM7GznfO6nRzwygtL7wmKbcTPUaMJEXfhSsTWgmq6Bzx
8iA1UN5A8rvKYxeEtnc81IznTcKNs/gmXmUTp0Eyj6InN6YBwbJDLyIxWFg5
pyZCwDAb4tEfUEUPSs8yV8eskarMpNk+7ojO6zU0Gxiq+bYjCE+m7d7i3lL3
nHUasTF0ic54dhQf1S/JGvoFPNg+TehMI5AkKIOMa8WtXPHhoyAhhXq8URF2
DHeE0UecFwQRmjxIQQbJAbKA2bGYOY74Yok5WC0IEbpxQw00k2LhCXbiudmd
+O4pjnrYE2oZmr2Y4A8eh8AzAyZVbeq7TIDfUq4h7WXAHjXiHzYeZ4IWwbOm
NGL2w+A4ytvsarXpeRwJfx3ka9yG/jKOZoqgJEeygpSYVu2IevJ5JMRUWpeo
yTGBGcPRhkkPys63E4NLWk4P68RxHAX3o5WrQAhhyJt6jTDD1z700FHaE6vL
5HpSEGoU3WwNGEIRMIiUg0XhsiD3FbXqMou4fSXTsgy9h+QKEng88DpOZfUY
psKxRKGJGVLsk8jLXkHPd8AJqdakKpmJKo5Xq6mivF64RXMUZjYz2a5ANgec
pi//pxzIaoR4mfjUMhqIhHfK/Ukk699/jP19nZ2LvIl1RgSnwnoIDJ60Dlgq
EC+LzbDKQzFmB9EU4cSLJL8paLLFYVVsNkl2vInyKsZZeTDEkXElgg5flEF2
K1m+GlF+h4YpHOuPtICicmFi8ql6U2gDYI8eNafV6VoUByqGTii8fDtqBWMW
iIV+diXcyq7cOAdtsibAiHjGZUXiYIJglNhgRXkp4RDfILKXDo3kqCELj9SZ
agWqzTcxggmLaiN4Pod2+/Xi8eLJ4msCmnrjLWHJDEK2wOwSX2C17eKI5wfe
bgotlipnNPrvnOeO1xa98I1LNGCAp1inFuY1XvUHe2BnNR64fd26KDnFpnn5
mIEnFO/IF7KOhqHxmNZ7pKDqeO2DqRJ/Pkm8xzc2hd3MtBCMOOMw7xjmzriE
pPhqUjNUEuVgC8FaGNdiZDwG4gHVqZHQcxdv6ZBb3gyDRm+qYENDEQF3qgtx
OKvnqtyfGaDEBcDxSIlQ3RR0KLxXMh1KLpkvCfHE8ABfptMVqUf7jmTmg0Hl
GwMIOexD0qgraoiQSxSMf6woxzJFlSBwlSXXso0hJ1MzlhzraGVA90EEQraM
vhTsRHAW6pGdRWF/YNiOSS7wEco0r8c2OMyh1XmrgN9JWfVdkv18Sdz31PYF
RBaJwr6u32T5lAqs7c5cVbNOJKQUdBlR1NlPr15olZyplfuyZbw10pMbDb5j
znNZKu3BFqSKUoPVr/xIfQL47ti6VBS2A+byUh5jUBRLc85lhTF9PlDPFcf3
hgjlTTS9su1haj3rVrYttQ+MGIXZCfqPIVqbIvJNwhn6KoOOdUmgoB6F5LEZ
aSujLcyCkr+d+iSXl8pXXIOWsUVPQ/ivaGna16cNFQ+RlIirYrwPS58IElBX
o2aQfj0YAbVpoHHqZ0FdjpVg1FoWjJt2k7DHjyfYmbxV5URHoahIidMu2zcs
iOed4Y10OibNt6cWRcZSy7nwJYMb7llyskVsytTm2YrQaeUhj9/w9DNTLbus
dhyZp2j7k1QxcmZSaltYglopuU5A/oYzCTRTO4NkSpYaCjDZoFSJSgwVjKFM
vy0q3H06LSWPgayoQFIxOdtZa2wVKXn0oLCM7KRmNkUgqIj1W2MsoiZEaTQ3
g25a69F45LIQ1kwloXRyRRPHwUSQpJe7dzi6J0astBDEH0DSPp09GfLTmrXW
d0EhhNmL5Z+Xg/hB2jOt4BmNCZakRMBk0DC+Tg09Q+rGW6NuoIE5yI6bprjL
lt25qGeM6ANqKsgWAl8scvzi96V+vgCB7hJe+1N5AjkJ2OjNLFvuy1W+yrMf
KN/CxSF/i7Af6Pn3NwdQgfkVDP9eYwz1vtgwvAK6/7kQFo1waab7vHqT/blc
v4GB1m9m2Uug2jr7f2oY27dNCYT5M5qM4bq+PmNJlT+WB+q/yl6eutMs+x+n
ogHOn72GlS6qu7zYb1BEggbrfV5kV/k+35Sz7HUNZJF9n5ersgVl789Afa+B
3OHXV6BZgWgFKifas/8HHJjDOfvxy+d1Vd/sTrDNy4qE8VenanPTFJL95tsG
ZVwYRN3kliqgxDoJxWaVr9/Ays/n8wx/Df8XAcvekHw3AQA=
</rfc> </rfc>
 End of changes. 242 change blocks. 
2012 lines changed or deleted 1119 lines changed or added

This html diff was produced by rfcdiff 1.48.