idnits 2.17.1
draft-ietf-teep-architecture-15.txt:
Checking boilerplate required by RFC 5378 and the IETF Trust (see
https://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/checklist :
----------------------------------------------------------------------------
No issues found here.
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the IETF Trust and authors Copyright Line does not
match the current year
-- The document date (July 12, 2021) is 1019 days in the past. Is this
intentional?
Checking references for intended status: Informational
----------------------------------------------------------------------------
== Outdated reference: A later version (-22) exists of
draft-ietf-rats-architecture-12
== Outdated reference: A later version (-25) exists of
draft-ietf-suit-manifest-14
== Outdated reference: A later version (-15) exists of
draft-ietf-teep-otrp-over-http-11
== Outdated reference: A later version (-18) exists of
draft-ietf-teep-protocol-05
Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 TEEP M. Pei
3 Internet-Draft Broadcom
4 Intended status: Informational H. Tschofenig
5 Expires: January 13, 2022 Arm Limited
6 D. Thaler
7 Microsoft
8 D. Wheeler
9 Amazon
10 July 12, 2021
12 Trusted Execution Environment Provisioning (TEEP) Architecture
13 draft-ietf-teep-architecture-15
15 Abstract
17 A Trusted Execution Environment (TEE) is an environment that enforces
18 that any code within that environment cannot be tampered with, and
19 that any data used by such code cannot be read or tampered with by
20 any code outside that environment. This architecture document
21 motivates the design and standardization of a protocol for managing
22 the lifecycle of trusted applications running inside such a TEE.
24 Status of This Memo
26 This Internet-Draft is submitted in full conformance with the
27 provisions of BCP 78 and BCP 79.
29 Internet-Drafts are working documents of the Internet Engineering
30 Task Force (IETF). Note that other groups may also distribute
31 working documents as Internet-Drafts. The list of current Internet-
32 Drafts is at https://datatracker.ietf.org/drafts/current/.
34 Internet-Drafts are draft documents valid for a maximum of six months
35 and may be updated, replaced, or obsoleted by other documents at any
36 time. It is inappropriate to use Internet-Drafts as reference
37 material or to cite them other than as "work in progress."
39 This Internet-Draft will expire on January 13, 2022.
41 Copyright Notice
43 Copyright (c) 2021 IETF Trust and the persons identified as the
44 document authors. All rights reserved.
46 This document is subject to BCP 78 and the IETF Trust's Legal
47 Provisions Relating to IETF Documents
48 (https://trustee.ietf.org/license-info) in effect on the date of
49 publication of this document. Please review these documents
50 carefully, as they describe your rights and restrictions with respect
51 to this document. Code Components extracted from this document must
52 include Simplified BSD License text as described in Section 4.e of
53 the Trust Legal Provisions and are provided without warranty as
54 described in the Simplified BSD License.
56 Table of Contents
58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
59 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
60 3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 7
61 3.1. Payment . . . . . . . . . . . . . . . . . . . . . . . . . 7
62 3.2. Authentication . . . . . . . . . . . . . . . . . . . . . 8
63 3.3. Internet of Things . . . . . . . . . . . . . . . . . . . 8
64 3.4. Confidential Cloud Computing . . . . . . . . . . . . . . 8
65 4. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 8
66 4.1. System Components . . . . . . . . . . . . . . . . . . . . 8
67 4.2. Multiple TEEs in a Device . . . . . . . . . . . . . . . . 11
68 4.3. Multiple TAMs and Relationship to TAs . . . . . . . . . . 13
69 4.4. Untrusted Apps, Trusted Apps, and Personalization Data . 14
70 4.4.1. Example: Application Delivery Mechanisms in Intel SGX 16
71 4.4.2. Example: Application Delivery Mechanisms in Arm
72 TrustZone . . . . . . . . . . . . . . . . . . . . . . 17
73 4.5. Entity Relations . . . . . . . . . . . . . . . . . . . . 17
74 5. Keys and Certificate Types . . . . . . . . . . . . . . . . . 19
75 5.1. Trust Anchors in a TEEP Agent . . . . . . . . . . . . . . 21
76 5.2. Trust Anchors in a TEE . . . . . . . . . . . . . . . . . 21
77 5.3. Trust Anchors in a TAM . . . . . . . . . . . . . . . . . 21
78 5.4. Scalability . . . . . . . . . . . . . . . . . . . . . . . 21
79 5.5. Message Security . . . . . . . . . . . . . . . . . . . . 22
80 6. TEEP Broker . . . . . . . . . . . . . . . . . . . . . . . . . 22
81 6.1. Role of the TEEP Broker . . . . . . . . . . . . . . . . . 23
82 6.2. TEEP Broker Implementation Consideration . . . . . . . . 23
83 6.2.1. TEEP Broker APIs . . . . . . . . . . . . . . . . . . 24
84 6.2.2. TEEP Broker Distribution . . . . . . . . . . . . . . 25
85 7. Attestation . . . . . . . . . . . . . . . . . . . . . . . . . 25
86 8. Algorithm and Attestation Agility . . . . . . . . . . . . . . 27
87 9. Security Considerations . . . . . . . . . . . . . . . . . . . 28
88 9.1. Broker Trust Model . . . . . . . . . . . . . . . . . . . 28
89 9.2. Data Protection . . . . . . . . . . . . . . . . . . . . . 28
90 9.3. Compromised REE . . . . . . . . . . . . . . . . . . . . . 29
91 9.4. CA Compromise or Expiry of CA Certificate . . . . . . . . 30
92 9.5. Compromised TAM . . . . . . . . . . . . . . . . . . . . . 30
93 9.6. Malicious TA Removal . . . . . . . . . . . . . . . . . . 31
94 9.7. Certificate Expiry and Renewal . . . . . . . . . . . . . 31
95 9.8. Keeping Secrets from the TAM . . . . . . . . . . . . . . 32
96 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32
97 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 32
98 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 32
99 13. Informative References . . . . . . . . . . . . . . . . . . . 32
100 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 34
102 1. Introduction
104 Applications executing in a device are exposed to many different
105 attacks intended to compromise the execution of the application or
106 reveal the data upon which those applications are operating. These
107 attacks increase with the number of other applications on the device,
108 with such other applications coming from potentially untrustworthy
109 sources. The potential for attacks further increases with the
110 complexity of features and applications on devices, and the
111 unintended interactions among those features and applications. The
112 danger of attacks on a system increases as the sensitivity of the
113 applications or data on the device increases. As an example,
114 exposure of emails from a mail client is likely to be of concern to
115 its owner, but a compromise of a banking application raises even
116 greater concerns.
118 The Trusted Execution Environment (TEE) concept is designed to
119 execute applications in a protected environment that enforces that
120 any code within that environment cannot be tampered with, and that
121 any data used by such code cannot be read or tampered with by any
122 code outside that environment, including by a commodity operating
123 system (if present). In a system with multiple TEEs, this also means
124 that code in one TEE cannot be read or tampered with by code in the
125 other TEE.
127 This separation reduces the possibility of a successful attack on
128 application components and the data contained inside the TEE.
129 Typically, application components are chosen to execute inside a TEE
130 because those application components perform security sensitive
131 operations or operate on sensitive data. An application component
132 running inside a TEE is referred to as a Trusted Application (TA),
133 while an application running outside any TEE, i.e., in the Rich
134 Execution Environment (REE), is referred to as an Untrusted
135 Application. In the example of a banking application, code that
136 relates to the authentication protocol could reside in a TA while the
137 application logic including HTTP protocol parsing could be contained
138 in the Untrusted Application. In addition, processing of credit card
139 numbers or account balances could be done in a TA as it is sensitive
140 data. The precise code split is ultimately a decision of the
141 developer based on the assets he or she wants to protect according to
142 the threat model.
144 TEEs use hardware enforcement combined with software protection to
145 secure TAs and its data. TEEs typically offer a more limited set of
146 services to TAs than is normally available to Untrusted Applications.
148 Not all TEEs are the same, however, and different vendors may have
149 different implementations of TEEs with different security properties,
150 different features, and different control mechanisms to operate on
151 TAs. Some vendors may themselves market multiple different TEEs with
152 different properties attuned to different markets. A device vendor
153 may integrate one or more TEEs into their devices depending on market
154 needs.
156 To simplify the life of TA developers interacting with TAs in a TEE,
157 an interoperable protocol for managing TAs running in different TEEs
158 of various devices is needed. This software update protocol needs to
159 make sure that compatible trusted and untrusted components (if any)
160 of an application are installed on the correct device. In this TEE
161 ecosystem, there often arises a need for an external trusted party to
162 verify the identity, claims, and rights of TA developers, devices,
163 and their TEEs. This trusted third party is the Trusted Application
164 Manager (TAM).
166 The Trusted Execution Environment Provisioning (TEEP) protocol
167 addresses the following problems:
169 - An installer of an Untrusted Application that depends on a given
170 TA wants to request installation of that TA in the device's TEE so
171 that the Untrusted Application can complete, but the TEE needs to
172 verify whether such a TA is actually authorized to run in the TEE
173 and consume potentially scarce TEE resources.
175 - A TA developer providing a TA whose code itself is considered
176 confidential wants to determine security-relevant information of a
177 device before allowing their TA to be provisioned to the TEE
178 within the device. An example is the verification of the type of
179 TEE included in a device and that it is capable of providing the
180 security protections required.
182 - A TEE in a device wants to determine whether an entity that wants
183 to manage a TA in the device is authorized to manage TAs in the
184 TEE, and what TAs the entity is permitted to manage.
186 - A Device Administrator wants to determine if a TA exists (is
187 installed) on a device (in the TEE), and if not, install the TA in
188 the TEE.
190 - A Device Administrator wants to check whether a TA in a device's
191 TEE is the most up-to-date version, and if not, update the TA in
192 the TEE.
194 - A Device Administrator wants to remove a TA from a device's TEE if
195 the TA developer is no longer maintaining that TA, when the TA has
196 been revoked or is not used for other reasons anymore (e.g., due
197 to an expired subscription).
199 For TEEs that simply verify and load signed TA's from an untrusted
200 filesystem, classic application distribution protocols can be used
201 without modification. The problems in the bullets above, on the
202 other hand, require a new protocol, i.e., the TEEP protocol, for TEEs
203 that can install and enumerate TAs in a TEE-secured location and
204 where another domain-specific protocol standard (e.g., [GSMA],
205 [OTRP]) that meets the needs is not already in use.
207 2. Terminology
209 The following terms are used:
211 - Device: A physical piece of hardware that hosts one or more TEEs,
212 often along with an REE.
214 - Device Administrator: An entity that is responsible for
215 administration of a device, which could be the Device Owner. A
216 Device Administrator has privileges on the device to install and
217 remove Untrusted Applications and TAs, approve or reject Trust
218 Anchors, and approve or reject TA developers, among possibly other
219 privileges on the device. A Device Administrator can manage the
220 list of allowed TAMs by modifying the list of Trust Anchors on the
221 device. Although a Device Administrator may have privileges and
222 device-specific controls to locally administer a device, the
223 Device Administrator may choose to remotely administer a device
224 through a TAM.
226 - Device Owner: A device is always owned by someone. In some cases,
227 it is common for the (primary) device user to also own the device,
228 making the device user/owner also the Device Administrator. In
229 enterprise environments it is more common for the enterprise to
230 own the device, and any device user has no or limited
231 administration rights. In this case, the enterprise appoints a
232 Device Administrator that is not the device owner.
234 - Device User: A human being that uses a device. Many devices have
235 a single device user. Some devices have a primary device user
236 with other human beings as secondary device users (e.g., parent
237 allowing children to use their tablet or laptop). Other devices
238 are not used by a human being and hence have no device user.
239 Relates to Device Owner and Device Administrator.
241 - Personalization Data: A set of configuration data that is specific
242 to the device or user. The Personalization Data may depend on the
243 type of TEE, a particular TEE instance, the TA, and even the user
244 of the device; an example of Personalization Data might be a
245 secret symmetric key used by a TA to communicate with some
246 service.
248 - Raw Public Key: The raw public key only consists of the
249 SubjectPublicKeyInfo structure of a PKIX certificate [RFC5280]
250 that carries the parameters necessary to describe the public key.
251 Other serialization formats that do not rely on ASN.1 may also be
252 used.
254 - Rich Execution Environment (REE): An environment that is provided
255 and governed by a typical OS (e.g., Linux, Windows, Android, iOS),
256 potentially in conjunction with other supporting operating systems
257 and hypervisors; it is outside of any TEE. This environment and
258 applications running on it are considered untrusted (or more
259 precisely, less trusted than a TEE).
261 - Trust Anchor: As defined in [RFC6024] and
262 [I-D.ietf-suit-manifest], "A trust anchor represents an
263 authoritative entity via a public key and associated data. The
264 public key is used to verify digital signatures, and the
265 associated data is used to constrain the types of information for
266 which the trust anchor is authoritative." The Trust Anchor may be
267 a certificate or it may be a raw public key along with additional
268 data if necessary such as its public key algorithm and parameters.
270 - Trust Anchor Store: As defined in [RFC6024], "A trust anchor store
271 is a set of one or more trust anchors stored in a device. A
272 device may have more than one trust anchor store, each of which
273 may be used by one or more applications." As noted in
274 [I-D.ietf-suit-manifest], a Trust Anchor Store must resist
275 modification against unauthorized insertion, deletion, and
276 modification.
278 - Trusted Application (TA): An application (or, in some
279 implementations, an application component) that runs in a TEE.
281 - Trusted Application Manager (TAM): An entity that manages Trusted
282 Applications and other Trusted Components running in TEEs of
283 various devices.
285 - Trusted Component: A set of code and/or data in a TEE managed as a
286 unit by a Trusted Application Manager. Trusted Applications and
287 Personalization Data are thus managed by being included in Trusted
288 Components. Trusted OS code or trusted firmware can also be
289 expressed as Trusted Components that a Trusted Component depends
290 on.
292 - Trusted Component Developer: An entity that develops one or more
293 Trusted Components.
295 - Trusted Component Signer: An entity that signs a Trusted Component
296 with a key that a TEE will trust. The signer might or might not
297 be the same entity as the Trusted Component Developer. For
298 example, a Trusted Component might be signed (or re-signed) by a
299 Device Administrator if the TEE will only trust the Device
300 Administrator. A Trusted Component might also be encrypted, if
301 the code is considered confidential.
303 - Trusted Execution Environment (TEE): An execution environment that
304 enforces that only authorized code can execute within the TEE, and
305 data used by that code cannot be read or tampered with by code
306 outside the TEE. A TEE also generally has a device unique
307 credential that cannot be cloned. There are multiple technologies
308 that can be used to implement a TEE, and the level of security
309 achieved varies accordingly. In addition, TEEs typically use an
310 isolation mechanism between Trusted Applications to ensure that
311 one TA cannot read, modify or delete the data and code of another
312 TA.
314 - Untrusted Application: An application running in an REE. An
315 Untrusted Application might depend on one or more TAs.
317 3. Use Cases
319 3.1. Payment
321 A payment application in a mobile device requires high security and
322 trust in the hosting device. Payments initiated from a mobile device
323 can use a Trusted Application to provide strong identification and
324 proof of transaction.
326 For a mobile payment application, some biometric identification
327 information could also be stored in a TEE. The mobile payment
328 application can use such information for unlocking the device and for
329 local identification of the user.
331 A trusted user interface (UI) may be used in a mobile device to
332 prevent malicious software from stealing sensitive user input data.
334 Such an implementation often relies on a TEE for providing access to
335 peripherals, such as PIN input or a trusted display, so that the REE
336 cannot observe or tamper with the user input or output.
338 3.2. Authentication
340 For better security of authentication, a device may store its keys
341 and cryptographic libraries inside a TEE limiting access to
342 cryptographic functions via a well-defined interface and thereby
343 reducing access to keying material.
345 3.3. Internet of Things
347 The Internet of Things (IoT) has been posing threats to critical
348 infrastructure because of weak security in devices. It is desirable
349 that IoT devices can prevent malware from manipulating actuators
350 (e.g., unlocking a door), or stealing or modifying sensitive data,
351 such as authentication credentials in the device. A TEE can be the
352 best way to implement such IoT security functions.
354 3.4. Confidential Cloud Computing
356 A tenant can store sensitive data, such as customer details or credit
357 card numbers, in a TEE in a cloud computing server such that only the
358 tenant can access the data, preventing the cloud hosting provider
359 from accessing the data. A tenant can run TAs inside a server TEE
360 for secure operation and enhanced data security. This provides
361 benefits not only to tenants with better data security but also to
362 cloud hosting providers for reduced liability and increased cloud
363 adoption.
365 4. Architecture
367 4.1. System Components
369 Figure 1 shows the main components in a typical device with an REE.
370 Full descriptions of components not previously defined are provided
371 below. Interactions of all components are further explained in the
372 following paragraphs.
374 +-------------------------------------------+
375 | Device | Trusted Component
376 | +--------+ | Signer
377 | +-------------+ | |-----------+ |
378 | | TEE-1 | | TEEP |---------+ | |
379 | | +--------+ | +----| Broker | | | | +--------+ |
380 | | | TEEP | | | | |<---+ | | +->| |<-+
381 | | | Agent |<----+ | | | | | +-| TAM-1 |
382 | | +--------+ | | |<-+ | | +->| | |<-+
383 | | | +--------+ | | | | +--------+ |
384 | | +---+ +---+ | | | | | TAM-2 | |
385 | +-->|TA1| |TA2| | +-------+ | | | +--------+ |
386 | | | | | | |<---------| App-2 |--+ | | |
387 | | | +---+ +---+ | +-------+ | | | Device Administrator
388 | | +-------------+ | App-1 | | | |
389 | | | | | | |
390 | +--------------------| |---+ | |
391 | | |--------+ |
392 | +-------+ |
393 +-------------------------------------------+
395 Figure 1: Notional Architecture of TEEP
397 - Trusted Component Signers and Device Administrators utilize the
398 services of a TAM to manage TAs on devices. Trusted Component
399 Signers do not directly interact with devices. Device
400 Administators may elect to use a TAM for remote administration of
401 TAs instead of managing each device directly.
403 - Trusted Application Manager (TAM): A TAM is responsible for
404 performing lifecycle management activity on Trusted Components on
405 behalf of Trusted Component Signers and Device Administrators.
406 This includes installation and deletion of Trusted Components, and
407 may include, for example, over-the-air updates to keep Trusted
408 Components up-to-date and clean up when one should be removed.
409 TAMs may provide services that make it easier for Trusted
410 Component Signers or Device Administators to use the TAM's service
411 to manage multiple devices, although that is not required of a
412 TAM.
414 The TAM performs its management of Trusted Components on the
415 device through interactions with a device's TEEP Broker, which
416 relays messages between a TAM and a TEEP Agent running inside the
417 TEE. TEEP authentication is performed between a TAM and a TEEP
418 Agent.
420 As shown in Figure 1, the TAM cannot directly contact a TEEP
421 Agent, but must wait for the TEEP Broker to contact the TAM
422 requesting a particular service. This architecture is intentional
423 in order to accommodate network and application firewalls that
424 normally protect user and enterprise devices from arbitrary
425 connections from external network entities.
427 A TAM may be publicly available for use by many Trusted Component
428 Signers, or a TAM may be private, and accessible by only one or a
429 limited number of Trusted Component Signers. It is expected that
430 many manufacturers and network carriers will run their own private
431 TAM.
433 A Trusted Component Signer or Device Administrator chooses a
434 particular TAM based on whether the TAM is trusted by a device or
435 set of devices. The TAM is trusted by a device if the TAM's
436 public key is, or chains up to, an authorized Trust Anchor in the
437 device. A Trusted Component Signer or Device Administrator may
438 run their own TAM, but the devices they wish to manage must
439 include this TAM's public key or certificate, or a certificate it
440 chains up to, in the Trust Anchor Store.
442 A Trusted Component Signer or Device Administrator is free to
443 utilize multiple TAMs. This may be required for managing Trusted
444 Components on multiple different types of devices from different
445 manufacturers, or mobile devices on different network carriers,
446 since the Trust Anchor Store on these different devices may
447 contain different TAMs. A Device Administrator may be able to add
448 their own TAM's public key or certificate to the Trust Anchor
449 Store on all their devices, overcoming this limitation.
451 Any entity is free to operate a TAM. For a TAM to be successful,
452 it must have its public key or certificate installed in a device's
453 Trust Anchor Store. A TAM may set up a relationship with device
454 manufacturers or network carriers to have them install the TAM's
455 keys in their device's Trust Anchor Store. Alternatively, a TAM
456 may publish its certificate and allow Device Administrators to
457 install the TAM's certificate in their devices as an after-market-
458 action.
460 - TEEP Broker: A TEEP Broker is an application component running in
461 a Rich Execution Environment (REE) that enables the message
462 protocol exchange between a TAM and a TEE in a device. A TEEP
463 Broker does not process messages on behalf of a TEE, but merely is
464 responsible for relaying messages from the TAM to the TEE, and for
465 returning the TEE's responses to the TAM. In devices with no REE
466 (e.g., a microcontroller where all code runs in an environment
467 that meets the definition of a Trusted Execution Environment in
468 Section 2), the TEEP Broker would be absent and instead the TEEP
469 protocol transport would be implemented inside the TEE itself.
471 - TEEP Agent: The TEEP Agent is a processing module running inside a
472 TEE that receives TAM requests (typically relayed via a TEEP
473 Broker that runs in an REE). A TEEP Agent in the TEE may parse
474 requests or forward requests to other processing modules in a TEE,
475 which is up to a TEE provider's implementation. A response
476 message corresponding to a TAM request is sent back to the TAM,
477 again typically relayed via a TEEP Broker.
479 - Certification Authority (CA): A CA is an entity that issues
480 digital certificates (especially X.509 certificates) and vouches
481 for the binding between the data items in a certificate [RFC4949].
482 Certificates are then used for authenticating a device, a TAM, or
483 a Trusted Component Signer, as discussed in Section 5. The CAs do
484 not need to be the same; different CAs can be chosen by each TAM,
485 and different device CAs can be used by different device
486 manufacturers.
488 4.2. Multiple TEEs in a Device
490 Some devices might implement multiple TEEs. In these cases, there
491 might be one shared TEEP Broker that interacts with all the TEEs in
492 the device. However, some TEEs (for example, SGX [SGX]) present
493 themselves as separate containers within memory without a controlling
494 manager within the TEE. As such, there might be multiple TEEP
495 Brokers in the REE, where each TEEP Broker communicates with one or
496 more TEEs associated with it.
498 It is up to the REE and the Untrusted Applications how they select
499 the correct TEEP Broker. Verification that the correct TA has been
500 reached then becomes a matter of properly verifying TA attestations,
501 which are unforgeable.
503 The multiple TEEP Broker approach is shown in the diagram below. For
504 brevity, TEEP Broker 2 is shown interacting with only one TAM and
505 Untrusted Application and only one TEE, but no such limitations are
506 intended to be implied in the architecture.
508 +-------------------------------------------+ Trusted
509 | Device | Component
510 | | Signer
511 | +-------------+ | |
512 | | TEE-1 | | |
513 | | +-------+ | +--------+ | +--------+ |
514 | | | TEEP | | | TEEP |------------->| |<-+
515 | | | Agent |<----------| Broker | | | | TA
516 | | | 1 | | | 1 |---------+ | |
517 | | +-------+ | | | | | | |
518 | | | | |<---+ | | | |
519 | | +---+ +---+ | | | | | | +-| TAM-1 |Policy
520 | | |TA1| |TA2| | | |<-+ | | +->| | |<-+
521 | +-->| | | |<---+ +--------+ | | | | +--------+ |
522 | | | +---+ +---+ | | | | | | TAM-2 | |
523 | | | | | +-------+ | | | +--------+ |
524 | | +-------------+ +-----| App-2 |--+ | | ^ |
525 | | +-------+ | | | | Device
526 | +--------------------| App-1 | | | | | Administrator
527 | +------| | | | | |
528 | +-----------|-+ | |---+ | | |
529 | | TEE-2 | | | |--------+ | |
530 | | +------+ | | | |------+ | |
531 | | | TEEP | | | +-------+ | | |
532 | | | Agent|<-----+ | | |
533 | | | 2 | | | | | | |
534 | | +------+ | | | | | |
535 | | | | | | | |
536 | | +---+ | | | | | |
537 | | |TA3|<----+ | | +----------+ | | |
538 | | | | | | | TEEP |<--+ | |
539 | | +---+ | +--| Broker | | |
540 | | | | 2 |----------------+
541 | +-------------+ +----------+ |
542 | |
543 +-------------------------------------------+
545 Figure 2: Notional Architecture of TEEP with multiple TEEs
547 In the diagram above, TEEP Broker 1 controls interactions with the
548 TAs in TEE-1, and TEEP Broker 2 controls interactions with the TAs in
549 TEE-2. This presents some challenges for a TAM in completely
550 managing the device, since a TAM may not interact with all the TEEP
551 Brokers on a particular platform. In addition, since TEEs may be
552 physically separated, with wholly different resources, there may be
553 no need for TEEP Brokers to share information on installed Trusted
554 Components or resource usage.
556 4.3. Multiple TAMs and Relationship to TAs
558 As shown in Figure 2, a TEEP Broker provides communication between
559 one or more TEEP Agents and one or more TAMs. The selection of which
560 TAM to communicate with might be made with or without input from an
561 Untrusted Application, but is ultimately the decision of a TEEP
562 Agent.
564 A TEEP Agent is assumed to be able to determine, for any given
565 Trusted Component, whether that Trusted Component is installed (or
566 minimally, is running) in a TEE with which the TEEP Agent is
567 associated.
569 Each Trusted Component is digitally signed, protecting its integrity,
570 and linking the Trusted Component back to the Trusted Component
571 Signer. The Trusted Component Signer is often the Trusted Component
572 Developer, but in some cases might be another party such as a Device
573 Administrator or other party to whom the code has been licensed (in
574 which case the same code might be signed by multiple licensees and
575 distributed as if it were different TAs).
577 A Trusted Component Signer selects one or more TAMs and communicates
578 the Trusted Component(s) to the TAM. For example, the Trusted
579 Component Signer might choose TAMs based upon the markets into which
580 the TAM can provide access. There may be TAMs that provide services
581 to specific types of devices, or device operating systems, or
582 specific geographical regions or network carriers. A Trusted
583 Component Signer may be motivated to utilize multiple TAMs in order
584 to maximize market penetration and availability on multiple types of
585 devices. This means that the same Trusted Component will often be
586 available through multiple TAMs.
588 When the developer of an Untrusted Application that depends on a
589 Trusted Component publishes the Untrusted Application to an app store
590 or other app repository, the developer optionally binds the Untrusted
591 Application with a manifest that identifies what TAMs can be
592 contacted for the Trusted Component. In some situations, a Trusted
593 Component may only be available via a single TAM - this is likely the
594 case for enterprise applications or Trusted Component Signers serving
595 a closed community. For broad public apps, there will likely be
596 multiple TAMs in the Untrusted Application's manifest - one servicing
597 one brand of mobile device and another servicing a different
598 manufacturer, etc. Because different devices and different
599 manufacturers trust different TAMs, the manifest can include multiple
600 TAMs that support the required Trusted Component.
602 When a TEEP Broker receives a request (see the RequestTA API in
603 Section 6.2.1) from an Untrusted Application to install a Trusted
604 Component, a list of TAM URIs may be provided for that Trusted
605 Component, and the request is passed to the TEEP Agent. If the TEEP
606 Agent decides that the Trusted Component needs to be installed, the
607 TEEP Agent selects a single TAM URI that is consistent with the list
608 of trusted TAMs provisioned in the TEEP Agent, invokes the HTTP
609 transport for TEEP to connect to the TAM URI, and begins a TEEP
610 protocol exchange. When the TEEP Agent subsequently receives the
611 Trusted Component to install and the Trusted Component's manifest
612 indicates dependencies on any other trusted components, each
613 dependency can include a list of TAM URIs for the relevant
614 dependency. If such dependencies exist that are prerequisites to
615 install the Trusted Component, then the TEEP Agent recursively
616 follows the same procedure for each dependency that needs to be
617 installed or updated, including selecting a TAM URI that is
618 consistent with the list of trusted TAMs provisioned on the device,
619 and beginning a TEEP exchange. If multiple TAM URIs are considered
620 trusted, only one needs to be contacted and they can be attempted in
621 some order until one responds.
623 Separate from the Untrusted Application's manifest, this framework
624 relies on the use of the manifest format in [I-D.ietf-suit-manifest]
625 for expressing how to install a Trusted Component, as well as any
626 dependencies on other TEE components and versions. That is,
627 dependencies from Trusted Components on other Trusted Components can
628 be expressed in a SUIT manifest, including dependencies on any other
629 TAs, or trusted OS code (if any), or trusted firmware. Installation
630 steps can also be expressed in a SUIT manifest.
632 For example, TEEs compliant with GlobalPlatform may have a notion of
633 a "security domain" (which is a grouping of one or more TAs installed
634 on a device, that can share information within such a group) that
635 must be created and into which one or more TAs can then be installed.
636 It is thus up to the SUIT manifest to express a dependency on having
637 such a security domain existing or being created first, as
638 appropriate.
640 Updating a Trusted Component may cause compatibility issues with any
641 Untrusted Applications or other components that depend on the updated
642 Trusted Component, just like updating the OS or a shared library
643 could impact an Untrusted Application. Thus, an implementation needs
644 to take into account such issues.
646 4.4. Untrusted Apps, Trusted Apps, and Personalization Data
648 In TEEP, there is an explicit relationship and dependence between an
649 Untrusted Application in an REE and one or more TAs in a TEE, as
650 shown in Figure 2. For most purposes, an Untrusted Application that
651 uses one or more TAs in a TEE appears no different from any other
652 Untrusted Application in the REE. However, the way the Untrusted
653 Application and its corresponding TAs are packaged, delivered, and
654 installed on the device can vary. The variations depend on whether
655 the Untrusted Application and TA are bundled together or are provided
656 separately, and this has implications to the management of the TAs in
657 a TEE. In addition to the Untrusted Application and TA(s), the TA(s)
658 and/or TEE may also require additional data to personalize the TA to
659 the device or a user. Implementations must support encryption of
660 such Personalization Data to preserve the confidentiality of
661 potentially sensitive data contained within it and support integrity
662 protection of the Personalization Data. Other than the requirement
663 to support confidentiality and integrity protection, the TEEP
664 architecture places no limitations or requirements on the
665 Personalization Data.
667 There are three possible cases for bundling of an Untrusted
668 Application, TA(s), and Personalization Data:
670 1. The Untrusted Application, TA(s), and Personalization Data are
671 all bundled together in a single package by a Trusted Component
672 Signer and either provided to the TEEP Broker through the TAM, or
673 provided separately (with encrypted Personalization Data), with
674 key material needed to decrypt and install the Personalization
675 Data and TA provided by a TAM.
677 2. The Untrusted Application and the TA(s) are bundled together in a
678 single package, which a TAM or a publicly accessible app store
679 maintains, and the Personalization Data is separately provided by
680 the Trusted Component Signer's TAM.
682 3. All components are independent. The Untrusted Application is
683 installed through some independent or device-specific mechanism,
684 and the TAM provides the TA and Personalization Data from the
685 Trusted Component Signer. Delivery of the TA and Personalization
686 Data may be combined or separate.
688 The TEEP protocol can treat each TA, any dependencies the TA has, and
689 Personalization Data as separate Trusted Components with separate
690 installation steps that are expressed in SUIT manifests, and a SUIT
691 manifest might contain or reference multiple binaries (see
692 [I-D.ietf-suit-manifest] for more details). The TEEP Agent is
693 responsible for handling any installation steps that need to be
694 performed inside the TEE, such as decryption of private TA binaries
695 or Personalization Data.
697 In order to better understand these cases, it is helpful to review
698 actual implementations of TEEs and their application delivery
699 mechanisms.
701 4.4.1. Example: Application Delivery Mechanisms in Intel SGX
703 In Intel Software Guard Extensions (SGX), the Untrusted Application
704 and TA are typically bundled into the same package (Case 2). The TA
705 exists in the package as a shared library (.so or .dll). The
706 Untrusted Application loads the TA into an SGX enclave when the
707 Untrusted Application needs the TA. This organization makes it easy
708 to maintain compatibility between the Untrusted Application and the
709 TA, since they are updated together. It is entirely possible to
710 create an Untrusted Application that loads an external TA into an SGX
711 enclave, and use that TA (Case 3). In this case, the Untrusted
712 Application would require a reference to an external file or download
713 such a file dynamically, place the contents of the file into memory,
714 and load that as a TA. Obviously, such file or downloaded content
715 must be properly formatted and signed for it to be accepted by the
716 SGX TEE. In SGX, for Case 2 and Case 3, the Personalization Data is
717 normally loaded into the SGX enclave (the TA) after the TA has
718 started. Although Case 1 is possible with SGX, there are no
719 instances of this known to be in use at this time, since such a
720 construction would require a special installation program and SGX TA
721 to receive the encrypted binary, decrypt it, separate it into the
722 three different elements, and then install all three. This
723 installation is complex because the Untrusted Application decrypted
724 inside the TEE must be passed out of the TEE to an installer in the
725 REE which would install the Untrusted Application; this assumes that
726 the Untrusted Application package includes the TA code also, since
727 otherwise there is a significant problem in getting the SGX enclave
728 code (the TA) from the TEE, through the installer, and into the
729 Untrusted Application in a trusted fashion. Finally, the
730 Personalization Data would need to be sent out of the TEE (encrypted
731 in an SGX enclave-to-enclave manner) to the REE's installation app,
732 which would pass this data to the installed Untrusted Application,
733 which would in turn send this data to the SGX enclave (TA). This
734 complexity is due to the fact that each SGX enclave is separate and
735 does not have direct communication to other SGX enclaves.
737 As long as signed files (TAs and/or Personalization Data) are
738 installed into an untrusted filesystem and trust is verified by the
739 TEE at load time, classic distribution mechanisms can be used. Some
740 uses of SGX, however, allow a model where a TA can be dynamically
741 installed into an SGX enclave that provides a runtime platform. The
742 TEEP protocol can be used in such cases, where the runtime platform
743 could include a TEEP Agent.
745 4.4.2. Example: Application Delivery Mechanisms in Arm TrustZone
747 In Arm TrustZone [TrustZone] for A-class devices, the Untrusted
748 Application and TA may or may not be bundled together. This differs
749 from SGX since in TrustZone the TA lifetime is not inherently tied to
750 a specific Untrused Application process lifetime as occurs in SGX. A
751 TA is loaded by a trusted OS running in the TEE such as a
752 GlobalPlatform compliant TEE, where the trusted OS is separate from
753 the OS in the REE. Thus Cases 2 and 3 are equally applicable. In
754 addition, it is possible for TAs to communicate with each other
755 without involving any Untrusted Application, and so the complexity of
756 Case 1 is lower than in the SGX example. Thus, Case 1 is possible as
757 well, though still more complex than Cases 2 and 3.
759 A trusted OS running in the TEE (e.g., OP-TEE) that supports loading
760 and verifying signed TAs from an untrusted filesystem can, like SGX,
761 use classic file distribution mechanisms. If secure TA storage is
762 used (e.g., a Replay-Protected Memory Block device) on the other
763 hand, the TEEP protocol can be used to manage such storage.
765 4.5. Entity Relations
767 This architecture leverages asymmetric cryptography to authenticate a
768 device to a TAM. Additionally, a TEEP Agent in a device
769 authenticates a TAM. The provisioning of Trust Anchors to a device
770 may be different from one use case to the other. A Device
771 Administrator may want to have the capability to control what TAs are
772 allowed. A device manufacturer enables verification by one or more
773 TAMs and by Trusted Component Signers; it may embed a list of default
774 Trust Anchors into the TEEP Agent and TEE for TAM trust verification
775 and TA signature verification.
777 (App Developers) (App Store) (TAM) (Device with TEE) (CAs)
778 | | | | |
779 | | | (Embedded TEE cert) <--|
780 | | | | |
781 | <--- Get an app cert -----------------------------------|
782 | | | | |
783 | | | <-- Get a TAM cert ---------|
784 | | | | |
785 1. Build two apps: | | | |
786 | | | |
787 (a) Untrusted | | | |
788 App - 2a. Supply --> | --- 3. Install ------> | |
789 | | | |
790 (b) TA -- 2b. Supply ----------> | 4. Messaging-->| |
791 | | | |
793 Figure 3: Example Developer Experience
795 Figure 3 shows an example where the same developer builds and signs
796 two applications: (a) an Untrusted Application; (b) a TA that
797 provides some security functions to be run inside a TEE. This
798 example assumes that the developer, the TEE, and the TAM have
799 previously been provisioned with certificates.
801 At step 1, the developer authors the two applications.
803 At step 2, the developer uploads the Untrusted Application (2a) to an
804 Application Store. In this example, the developer is also the
805 Trusted Component Signer, and so generates a signed TA. The
806 developer can then either bundle the signed TA with the Untrusted
807 Application, or the developer can provide a signed Trusted Component
808 containing the TA to a TAM that will be managing the TA in various
809 devices.
811 At step 3, a user will go to an Application Store to download the
812 Untrusted Application (where the arrow indicates the direction of
813 data transfer).
815 At step 4, since the Untrusted Application depends on the TA,
816 installing the Untrusted Application will trigger TA installation by
817 initiating communication with a TAM. The TEEP Agent will interact
818 with TAM via a TEEP Broker that faciliates communications between a
819 TAM and the TEEP Agent in TEE.
821 Some Trusted Component installation implementations might ask for a
822 user's consent. In other implementations, a Device Administrator
823 might choose what Untrusted Applications and related Trusted
824 Components to be installed. A user consent flow is out of scope of
825 the TEEP architecture.
827 The main components consist of a set of standard messages created by
828 a TAM to deliver Trusted Component management commands to a device,
829 and device attestation and response messages created by a TEE that
830 responds to a TAM's message.
832 It should be noted that network communication capability is generally
833 not available in TAs in today's TEE-powered devices. Consequently,
834 Trusted Applications generally rely on broker in the REE to provide
835 access to network functionality in the REE. A broker does not need
836 to know the actual content of messages to facilitate such access.
838 Similarly, since the TEEP Agent runs inside a TEE, the TEEP Agent
839 generally relies on a TEEP Broker in the REE to provide network
840 access, and relay TAM requests to the TEEP Agent and relay the
841 responses back to the TAM.
843 5. Keys and Certificate Types
845 This architecture leverages the following credentials, which allow
846 delivering end-to-end security between a TAM and a TEEP Agent.
848 Figure 4 summarizes the relationships between various keys and where
849 they are stored. Each public/private key identifies a Trusted
850 Component Signer, TAM, or TEE, and gets a certificate that chains up
851 to some trust anchor. A list of trusted certificates is then used to
852 check a presented certificate against.
854 Different CAs can be used for different types of certificates. TEEP
855 messages are always signed, where the signer key is the message
856 originator's private key, such as that of a TAM or a TEE. In
857 addition to the keys shown in Figure 4, there may be additional keys
858 used for attestation. Refer to the RATS Architecture
859 [I-D.ietf-rats-architecture] for more discussion.
861 Cardinality & Location of
862 Location of Private Key Trust Anchor
863 Purpose Private Key Signs Store
864 ------------------ ----------- ------------- -------------
865 Authenticating 1 per TEE TEEP responses TAM
866 TEEP Agent
868 Authenticating TAM 1 per TAM TEEP requests TEEP Agent
870 Code Signing 1 per Trusted TA binary TEE
871 Component
872 Signer
874 Figure 4: Signature Keys
876 Note that Personalization Data is not included in the table above.
877 The use of Personalization Data is dependent on how TAs are used and
878 what their security requirements are.
880 TEEP requests from a TAM to a TEEP Agent are signed with the TAM
881 private key (for authentication and integrity protection).
882 Personalization Data and TA binaries can be encrypted with a key that
883 is established with a content-encryption key established with the TEE
884 public key (to provide confidentiality). Conversely, TEEP responses
885 from a TEEP Agent to a TAM can be signed with the TEE private key.
887 The TEE key pair and certificate are thus used for authenticating the
888 TEE to a remote TAM, and for sending private data to the TEE. Often,
889 the key pair is burned into the TEE by the TEE manufacturer and the
890 key pair and its certificate are valid for the expected lifetime of
891 the TEE. A TAM provider is responsible for configuring the TAM's
892 Trust Anchor Store with the manufacturer certificates or CAs that are
893 used to sign TEE keys. This is discussed further in Section 5.3
894 below.
896 The TAM key pair and certificate are used for authenticating a TAM to
897 a remote TEE, and for sending private data to the TAM. A TAM
898 provider is responsible for acquiring a certificate from a CA that is
899 trusted by the TEEs it manages. This is discussed further in
900 Section 5.1 below.
902 The Trusted Component Signer key pair and certificate are used to
903 sign Trusted Components that the TEE will consider authorized to
904 execute. TEEs must be configured with the certificates or keys that
905 it considers authorized to sign TAs that it will execute. This is
906 discussed further in Section 5.2 below.
908 5.1. Trust Anchors in a TEEP Agent
910 A TEEP Agent's Trust Anchor Store contains a list of Trust Anchors,
911 which are CA certificates that sign various TAM certificates. The
912 list is typically preloaded at manufacturing time, and can be updated
913 using the TEEP protocol if the TEE has some form of "Trust Anchor
914 Manager TA" that has Trust Anchors in its configuration data. Thus,
915 Trust Anchors can be updated similar to updating the Personalization
916 Data for any other TA.
918 When Trust Anchor update is carried out, it is imperative that any
919 update must maintain integrity where only an authentic Trust Anchor
920 list from a device manufacturer or a Device Administrator is
921 accepted. Details are out of scope of the architecture and can be
922 addressed in a protocol document.
924 Before a TAM can begin operation in the marketplace to support a
925 device with a particular TEE, it must obtain a TAM certificate from a
926 CA or the raw public key of a TAM that is listed in the Trust Anchor
927 Store of the TEEP Agent.
929 5.2. Trust Anchors in a TEE
931 A TEE determines whether TA binaries are allowed to execute by
932 verifying whether their signature can be verified using
933 certificate(s) or raw public key(s) in the TEE's Trust Anchor Store.
934 The list is typically preloaded at manufacturing time, and can be
935 updated using the TEEP protocol if the TEE has some form of "Trust
936 Anchor Manager TA" that has Trust Anchors in its configuration data.
937 Thus, Trust Anchors can be updated similar to updating the
938 Personalization Data for any other TA, as discussed in Section 5.1.
940 5.3. Trust Anchors in a TAM
942 The Trust Anchor Store in a TAM consists of a list of Trust Anchors,
943 which are certificates that sign various device TEE certificates. A
944 TAM will accept a device for Trusted Component management if the TEE
945 in the device uses a TEE certificate that is chained to a certificate
946 or raw public key that the TAM trusts, is contained in an allow list,
947 is not found on a block list, and/or fulfills any other policy
948 criteria.
950 5.4. Scalability
952 This architecture uses a PKI (including self-signed certificates).
953 Trust Anchors exist on the devices to enable the TEE to authenticate
954 TAMs and Trusted Component Signers, and TAMs use Trust Anchors to
955 authenticate TEEs. When a PKI is used, many intermediate CA
956 certificates can chain to a root certificate, each of which can issue
957 many certificates. This makes the protocol highly scalable. New
958 factories that produce TEEs can join the ecosystem. In this case,
959 such a factory can get an intermediate CA certificate from one of the
960 existing roots without requiring that TAMs are updated with
961 information about the new device factory. Likewise, new TAMs can
962 join the ecosystem, providing they are issued a TAM certificate that
963 chains to an existing root whereby existing TEEs will be allowed to
964 be personalized by the TAM without requiring changes to the TEE
965 itself. This enables the ecosystem to scale, and avoids the need for
966 centralized databases of all TEEs produced or all TAMs that exist or
967 all Trusted Component Signers that exist.
969 5.5. Message Security
971 Messages created by a TAM are used to deliver Trusted Component
972 management commands to a device, and device attestation and messages
973 created by the device TEE to respond to TAM messages.
975 These messages are signed end-to-end between a TEEP Agent and a TAM.
976 Confidentiality is provided by encrypting sensitive payloads (such as
977 Personalization Data and attestation evidence), rather than
978 encrypting the messages themselves. Using encrypted payloads is
979 important to ensure that only the targeted device TEE or TAM is able
980 to decrypt and view the actual content.
982 6. TEEP Broker
984 A TEE and TAs often do not have the capability to directly
985 communicate outside of the hosting device. For example,
986 GlobalPlatform [GPTEE] specifies one such architecture. This calls
987 for a software module in the REE world to handle network
988 communication with a TAM.
990 A TEEP Broker is an application component running in the REE of the
991 device or an SDK that facilitates communication between a TAM and a
992 TEE. It also provides interfaces for Untrusted Applications to query
993 and trigger installation of Trusted Components that the application
994 needs to use.
996 An Untrusted Application might communicate with a TEEP Broker at
997 runtime to trigger Trusted Component installation itself, or an
998 Untrusted Application might simply have a metadata file that
999 describes the Trusted Components it depends on and the associated
1000 TAM(s) for each Trusted Component, and an REE Application Installer
1001 can inspect this application metadata file and invoke the TEEP Broker
1002 to trigger Trusted Component installation on behalf of the Untrusted
1003 Application without requiring the Untrusted Application to run first.
1005 6.1. Role of the TEEP Broker
1007 A TEEP Broker abstracts the message exchanges with a TEE in a device.
1008 The input data is originated from a TAM or the first initialization
1009 call to trigger a Trusted Component installation.
1011 The Broker doesn't need to parse a message content received from a
1012 TAM that should be processed by a TEE (see the ProcessTeepMessage API
1013 in Section 6.2.1). When a device has more than one TEE, one TEEP
1014 Broker per TEE could be present in the REE. A TEEP Broker interacts
1015 with a TEEP Agent inside a TEE.
1017 A TAM message may indicate the target TEE where a Trusted Component
1018 should be installed. A compliant TEEP protocol should include a
1019 target TEE identifier for a TEEP Broker when multiple TEEs are
1020 present.
1022 The Broker relays the response messages generated from a TEEP Agent
1023 in a TEE to the TAM.
1025 The Broker only needs to return a (transport) error message if the
1026 TEE is not reachable for some reason. Other errors are represented
1027 as response messages returned from the TEE which will then be passed
1028 to the TAM.
1030 6.2. TEEP Broker Implementation Consideration
1032 As depicted in Figure 5, there are multiple ways in which a TEEP
1033 Broker can be implemented, with more or fewer layers being inside the
1034 TEE. For example, in model A, the model with the smallest TEE
1035 footprint, only the TEEP implementation is inside the TEE, whereas
1036 the TEEP/HTTP implementation is in the TEEP Broker outside the TEE.
1038 Model: A B C ...
1040 TEE TEE TEE
1041 +----------------+ | | |
1042 | TEEP | Agent | | | Agent
1043 | implementation | | | |
1044 +----------------+ v | |
1045 | | |
1046 +----------------+ ^ | |
1047 | TEEP/HTTP | Broker | | |
1048 | implementation | | | |
1049 +----------------+ | v |
1050 | | |
1051 +----------------+ | ^ |
1052 | HTTP(S) | | | |
1053 | implementation | | | |
1054 +----------------+ | | v
1055 | | |
1056 +----------------+ | | ^
1057 | TCP or QUIC | | | | Broker
1058 | implementation | | | |
1059 +----------------+ | | |
1060 REE REE REE
1062 Figure 5: TEEP Broker Models
1064 In other models, additional layers are moved into the TEE, increasing
1065 the TEE footprint, with the Broker either containing or calling the
1066 topmost protocol layer outside of the TEE. An implementation is free
1067 to choose any of these models.
1069 TEEP Broker implementers should consider methods of distribution,
1070 scope and concurrency on devices and runtime options.
1072 6.2.1. TEEP Broker APIs
1074 The following conceptual APIs exist from a TEEP Broker to a TEEP
1075 Agent:
1077 1. RequestTA: A notification from an REE application (e.g., an
1078 installer, or an Untrusted Application) that it depends on a
1079 given Trusted Component, which may or may not already be
1080 installed in the TEE.
1082 2. UnrequestTA: A notification from an REE application (e.g., an
1083 installer, or an Untrusted Application) that it no longer depends
1084 on a given Trusted Component, which may or may not already be
1085 installed in the TEE. For example, if the Untrusted Application
1086 is uninstalled, the uninstaller might invoke this conceptual API.
1088 3. ProcessTeepMessage: A message arriving from the network, to be
1089 delivered to the TEEP Agent for processing.
1091 4. RequestPolicyCheck: A hint (e.g., based on a timer) that the TEEP
1092 Agent may wish to contact the TAM for any changes, without the
1093 device itself needing any particular change.
1095 5. ProcessError: A notification that the TEEP Broker could not
1096 deliver an outbound TEEP message to a TAM.
1098 For comparison, similar APIs may exist on the TAM side, where a
1099 Broker may or may not exist, depending on whether the TAM uses a TEE
1100 or not:
1102 1. ProcessConnect: A notification that an incoming TEEP session is
1103 being requested by a TEEP Agent.
1105 2. ProcessTeepMessage: A message arriving from the network, to be
1106 delivered to the TAM for processing.
1108 For further discussion on these APIs, see
1109 [I-D.ietf-teep-otrp-over-http].
1111 6.2.2. TEEP Broker Distribution
1113 The Broker installation is commonly carried out at OEM time. A user
1114 can dynamically download and install a Broker on-demand.
1116 7. Attestation
1118 Attestation is the process through which one entity (an Attester)
1119 presents "evidence", in the form of a series of claims, to another
1120 entity (a Verifier), and provides sufficient proof that the claims
1121 are true. Different Verifiers may require different degrees of
1122 confidence in attestation proofs and not all attestations are
1123 acceptable to every verifier. A third entity (a Relying Party) can
1124 then use "attestation results", in the form of another series of
1125 claims, from a Verifier to make authorization decisions. (See
1126 [I-D.ietf-rats-architecture] for more discussion.)
1128 In TEEP, as depicted in Figure 6, the primary purpose of an
1129 attestation is to allow a device (the Attester) to prove to a TAM
1130 (the Relying Party) that a TEE in the device has particular
1131 properties, was built by a particular manufacturer, and/or is
1132 executing a particular TA. Other claims are possible; TEEP does not
1133 limit the claims that may appear in evidence or attestation results,
1134 but defines a minimal set of attestation result claims required for
1135 TEEP to operate properly. Extensions to these claims are possible.
1136 Other standards or groups may define the format and semantics of
1137 extended claims.
1139 +----------------+
1140 | Device | +----------+
1141 | +------------+ | Evidence | TAM | Evidence +----------+
1142 | | TEE |------------->| (Relying |-------------->| Verifier |
1143 | | (Attester) | | | Party) |<--------------| |
1144 | +------------+ | +----------+ Attestation +----------+
1145 +----------------+ Result
1147 Figure 6: TEEP Attestation Roles
1149 As of the writing of this specification, device and TEE attestations
1150 have not been standardized across the market. Different devices,
1151 manufacturers, and TEEs support different attestation protocols. In
1152 order for TEEP to be inclusive, it is agnostic to the format of
1153 evidence, allowing proprietary or standardized formats to be used
1154 between a TEE and a verifier (which may or may not be colocated in
1155 the TAM), as long as the format supports encryption of any
1156 information that is considered sensitive.
1158 However, it should be recognized that not all Verifiers may be able
1159 to process all proprietary forms of attestation evidence. Similarly,
1160 the TEEP protocol is agnostic as to the format of attestation
1161 results, and the protocol (if any) used between the TAM and a
1162 verifier, as long as they convey at least the required set of claims
1163 in some format. Note that the respective attestation algorithms are
1164 not defined in the TEEP protocol itself; see
1165 [I-D.ietf-rats-architecture] and [I-D.ietf-teep-protocol] for more
1166 discussion.
1168 There are a number of considerations that need to be considered when
1169 appraising evidence provided by a TEE, including:
1171 - What security measures a manufacturer takes when provisioning keys
1172 into devices/TEEs;
1174 - What hardware and software components have access to the
1175 attestation keys of the TEE;
1177 - The source or local verification of claims within an attestation
1178 prior to a TEE signing a set of claims;
1180 - The level of protection afforded to attestation keys against
1181 exfiltration, modification, and side channel attacks;
1183 - The limitations of use applied to TEE attestation keys;
1185 - The processes in place to discover or detect TEE breaches; and
1187 - The revocation and recovery process of TEE attestation keys.
1189 Some TAMs may require additional claims in order to properly
1190 authorize a device or TEE. The specific format for these additional
1191 claims are outside the scope of this specification, but the TEEP
1192 protocol allows these additional claims to be included in the
1193 attestation messages.
1195 For more discussion of the attestation and appraisal process, see the
1196 RATS Architecture [I-D.ietf-rats-architecture].
1198 The following information is required for TEEP attestation:
1200 - Device Identifying Information: Attestation information may need
1201 to uniquely identify a device to the TAM. Unique device
1202 identification allows the TAM to provide services to the device,
1203 such as managing installed TAs, and providing subscriptions to
1204 services, and locating device-specific keying material to
1205 communicate with or authenticate the device. In some use cases it
1206 may be sufficient to identify only the class of the device. The
1207 security and privacy requirements regarding device identification
1208 will vary with the type of TA provisioned to the TEE.
1210 - TEE Identifying Information: The type of TEE that generated this
1211 attestation must be identified. This includes version
1212 identification information for hardware, firmware, and software
1213 version of the TEE, as applicable by the TEE type. TEE
1214 manufacturer information for the TEE is required in order to
1215 disambiguate the same TEE type created by different manufacturers
1216 and address considerations around manufacturer provisioning,
1217 keying and support for the TEE.
1219 - Freshness Proof: A claim that includes freshness information must
1220 be included, such as a nonce or timestamp.
1222 8. Algorithm and Attestation Agility
1224 RFC 7696 [RFC7696] outlines the requirements to migrate from one
1225 mandatory-to-implement cryptographic algorithm suite to another over
1226 time. This feature is also known as crypto agility. Protocol
1227 evolution is greatly simplified when crypto agility is considered
1228 during the design of the protocol. In the case of the TEEP protocol
1229 the diverse range of use cases, from trusted app updates for smart
1230 phones and tablets to updates of code on higher-end IoT devices,
1231 creates the need for different mandatory-to-implement algorithms
1232 already from the start.
1234 Crypto agility in TEEP concerns the use of symmetric as well as
1235 asymmetric algorithms. In the context of TEEP, symmetric algorithms
1236 are used for encryption and integrity protection of TA binaries and
1237 Personalization Data whereas the asymmetric algorithms are used for
1238 signing messages and managing symmetric keys.
1240 In addition to the use of cryptographic algorithms in TEEP, there is
1241 also the need to make use of different attestation technologies. A
1242 device must provide techniques to inform a TAM about the attestation
1243 technology it supports. For many deployment cases it is more likely
1244 for the TAM to support one or more attestation techniques whereas the
1245 device may only support one.
1247 9. Security Considerations
1249 9.1. Broker Trust Model
1251 The architecture enables the TAM to communicate, via a TEEP Broker,
1252 with the device's TEE to manage Trusted Components. Since the TEEP
1253 Broker runs in a potentially vulnerable REE, the TEEP Broker could,
1254 however, be (or be infected by) malware. As such, all TAM messages
1255 are signed and sensitive data is encrypted such that the TEEP Broker
1256 cannot modify or capture sensitive data, but the TEEP Broker can
1257 still conduct DoS attacks as discussed in Section 9.3.
1259 A TEEP Agent in a TEE is responsible for protecting against potential
1260 attacks from a compromised TEEP Broker or rogue malware in the REE.
1261 A rogue TEEP Broker might send corrupted data to the TEEP Agent, or
1262 launch a DoS attack by sending a flood of TEEP protocol requests.
1263 The TEEP Agent validates the signature of each TEEP protocol request
1264 and checks the signing certificate against its Trust Anchors. To
1265 mitigate DoS attacks, it might also add some protection scheme such
1266 as a threshold on repeated requests or number of TAs that can be
1267 installed.
1269 9.2. Data Protection
1271 It is the responsibility of the TAM to protect data on its servers.
1272 Similarly, it is the responsibility of the TEE implementation to
1273 provide protection of data against integrity and confidentiality
1274 attacks from outside the TEE. TEEs that provide isolation among TAs
1275 within the TEE are likewise responsible for protecting TA data
1276 against the REE and other TAs. For example, this can be used to
1277 protect one user's or tenant's data from compromise by another user
1278 or tenant, even if the attacker has TAs.
1280 The protocol between TEEP Agents and TAMs similarly is responsible
1281 for securely providing integrity and confidentiality protection
1282 against adversaries between them. It is a design choice at what
1283 layers to best provide protection against network adversaries. As
1284 discussed in Section 6, the transport protocol and any security
1285 mechanism associated with it (e.g., the Transport Layer Security
1286 protocol) under the TEEP protocol may terminate outside a TEE. If it
1287 does, the TEEP protocol itself must provide integrity protection and
1288 confidentiality protection to secure data end-to-end. For example,
1289 confidentiality protection for payloads may be provided by utilizing
1290 encrypted TA binaries and encrypted attestation information. See
1291 [I-D.ietf-teep-protocol] for how a specific solution addresses the
1292 design question of how to provide integrity and confidentiality
1293 protection.
1295 9.3. Compromised REE
1297 It is possible that the REE of a device is compromised. We have
1298 already seen examples of attacks on the public Internet of billions
1299 of compromised devices being used to mount DDoS attacks. A
1300 compromised REE can be used for such an attack but it cannot tamper
1301 with the TEE's code or data in doing so. A compromised REE can,
1302 however, launch DoS attacks against the TEE.
1304 The compromised REE may terminate the TEEP Broker such that TEEP
1305 transactions cannot reach the TEE, or might drop or delay messages
1306 between a TAM and a TEEP Agent. However, while a DoS attack cannot
1307 be prevented, the REE cannot access anything in the TEE if it is
1308 implemented correctly. Some TEEs may have some watchdog scheme to
1309 observe REE state and mitigate DoS attacks against it but most TEEs
1310 don't have such a capability.
1312 In some other scenarios, the compromised REE may ask a TEEP Broker to
1313 make repeated requests to a TEEP Agent in a TEE to install or
1314 uninstall a Trusted Component. An installation or uninstallation
1315 request constructed by the TEEP Broker or REE will be rejected by the
1316 TEEP Agent because the request won't have the correct signature from
1317 a TAM to pass the request signature validation.
1319 This can become a DoS attack by exhausting resources in a TEE with
1320 repeated requests. In general, a DoS attack threat exists when the
1321 REE is compromised, and a DoS attack can happen to other resources.
1322 The TEEP architecture doesn't change this.
1324 A compromised REE might also request initiating the full flow of
1325 installation of Trusted Components that are not necessary. It may
1326 also repeat a prior legitimate Trusted Component installation
1327 request. A TEEP Agent implementation is responsible for ensuring
1328 that it can recognize and decline such repeated requests. It is also
1329 responsible for protecting the resource usage allocated for Trusted
1330 Component management.
1332 9.4. CA Compromise or Expiry of CA Certificate
1334 A root CA for TAM certificates might get compromised or its
1335 certificate might expire, or a Trust Anchor other than a root CA
1336 certificate may also expire or be compromised. TEEs are responsible
1337 for validating the entire TAM certificate path, including the TAM
1338 certificate and any intermediate certificates up to the root
1339 certificate. Such validation includes checking for certificate
1340 revocation. See Section 6 of [RFC5280] for details.
1342 If a TAM certificate path validation fails, the TAM might be rejected
1343 by a TEEP Agent. To address this, some certificate path update
1344 mechanism is expected from TAM operators, so that the TAM can get a
1345 new certificate path that can be validated by a TEEP Agent. In
1346 addition, the Trust Anchor in the TEEP Agent's Trust Anchor Store may
1347 need to be updated. To address this, some TEE Trust Anchor update
1348 mechanism is expected from device OEMs.
1350 Similarly, a root CA for TEE certificates might get compromised or
1351 its certificate might expire, or a Trust Anchor other than a root CA
1352 certificate may also expire or be compromised. TAMs are responsible
1353 for validating the entire TEE certificate path, including the TEE
1354 certificate and any intermediate certificates up to the root
1355 certificate. Such validation includes checking for certificate
1356 revocation.
1358 If a TEE certificate path validation fails, the TEE might be rejected
1359 by a TAM, subject to the TAM's policy. To address this, some
1360 certificate path update mechanism is expected from device OEMs, so
1361 that the TEE can get a new certificate path that can be validated by
1362 a TAM. In addition, the Trust Anchor in the TAM's Trust Anchor Store
1363 may need to be updated.
1365 9.5. Compromised TAM
1367 Device TEEs are responsible for validating the supplied TAM
1368 certificates to determine that the TAM is trustworthy.
1370 9.6. Malicious TA Removal
1372 It is possible that a rogue developer distributes a malicious
1373 Untrusted Application and intends to get a malicious TA installed.
1374 Such a TA might be able to escape from malware detection by the REE,
1375 or access trusted resources within the TEE (but could not access
1376 other TEEs, or access other TA's if the TEE provides isolation
1377 between TAs).
1379 It is the responsibility of the TAM to not install malicious TAs in
1380 the first place. The TEEP architecture allows a TEEP Agent to decide
1381 which TAMs it trusts via Trust Anchors, and delegates the TA
1382 authenticity check to the TAMs it trusts.
1384 It may happen that a TA was previously considered trustworthy but is
1385 later found to be buggy or compromised. In this case, the TAM can
1386 initiate the removal of the TA by notifying devices to remove the TA
1387 (and potentially the REE or Device Owner to remove any Untrusted
1388 Application that depend on the TA). If the TAM does not currently
1389 have a connection to the TEEP Agent on a device, such a notification
1390 would occur the next time connectivity does exist. That is, to
1391 recover, the TEEP Agent must be able to reach out to the TAM, for
1392 example whenever the RequestPolicyCheck API (Section 6.2.1) is
1393 invoked by a timer or other event.
1395 Furthermore the policy in the Verifier in an attestation process can
1396 be updated so that any evidence that includes the malicious TA would
1397 result in an attestation failure. There is, however, a time window
1398 during which a malicious TA might be able to operate successfully,
1399 which is the validity time of the previous attestation result. For
1400 example, if the Verifier in Figure 6 is updated to treat a previously
1401 valid TA as no longer trustworthy, any attestation result it
1402 previously generated saying that the TA is valid will continue to be
1403 used until the attestation result expires. As such, the TAM's
1404 Verifier should take into account the acceptable time window when
1405 generating attestation results. See [I-D.ietf-rats-architecture] for
1406 further discussion.
1408 9.7. Certificate Expiry and Renewal
1410 TEE device certificates are expected to be long lived, longer than
1411 the lifetime of a device. A TAM certificate usually has a moderate
1412 lifetime of 2 to 5 years. A TAM should get renewed or rekeyed
1413 certificates. The root CA certificates for a TAM, which are embedded
1414 into the Trust Anchor Store in a device, should have long lifetimes
1415 that don't require device Trust Anchor updates. On the other hand,
1416 it is imperative that OEMs or device providers plan for support of
1417 Trust Anchor update in their shipped devices.
1419 For those cases where TEE devices are given certificates for which no
1420 good expiration date can be assigned the recommendations in
1421 Section 4.1.2.5 of [RFC5280] are applicable.
1423 9.8. Keeping Secrets from the TAM
1425 In some scenarios, it is desirable to protect the TA binary or
1426 Personalization Data from being disclosed to the TAM that distributes
1427 them. In such a scenario, the files can be encrypted end-to-end
1428 between a Trusted Component Signer and a TEE. However, there must be
1429 some means of provisioning the decryption key into the TEE and/or
1430 some means of the Trusted Component Signer securely learning a public
1431 key of the TEE that it can use to encrypt. One way to do this is for
1432 the Trusted Component Signer to run its own TAM so that it can
1433 distribute the decryption key via the TEEP protocol, and the key file
1434 can be a dependency in the manifest of the encrypted TA. Thus, the
1435 TEEP Agent would look at the Trusted Component manifest, determine
1436 there is a dependency with a TAM URI of the Trusted Component
1437 Signer's TAM. The Agent would then install the dependency, and then
1438 continue with the Trusted Component installation steps, including
1439 decrypting the TA binary with the relevant key.
1441 10. IANA Considerations
1443 This document does not require actions by IANA.
1445 11. Contributors
1447 - Andrew Atyeo, Intercede (andrew.atyeo@intercede.com)
1449 - Liu Dapeng, Alibaba Group (maxpassion@gmail.com)
1451 12. Acknowledgements
1453 We would like to thank Nick Cook, Minho Yoo, Brian Witten, Tyler Kim,
1454 Alin Mutu, Juergen Schoenwaelder, Nicolae Paladi, Sorin Faibish, Ned
1455 Smith, Russ Housley, Jeremy O'Donoghue, and Anders Rundgren for their
1456 feedback.
1458 13. Informative References
1460 [GPTEE] GlobalPlatform, "GlobalPlatform Device Technology: TEE
1461 System Architecture, v1.1", GlobalPlatform GPD_SPE_009,
1462 January 2017, .
1465 [GSMA] GSM Association, "GP.22 RSP Technical Specification,
1466 Version 2.2.2", June 2020, .
1469 [I-D.ietf-rats-architecture]
1470 Birkholz, H., Thaler, D., Richardson, M., Smith, N., and
1471 W. Pan, "Remote Attestation Procedures Architecture",
1472 draft-ietf-rats-architecture-12 (work in progress), April
1473 2021.
1475 [I-D.ietf-suit-manifest]
1476 Moran, B., Tschofenig, H., Birkholz, H., and K. Zandberg,
1477 "A Concise Binary Object Representation (CBOR)-based
1478 Serialization Format for the Software Updates for Internet
1479 of Things (SUIT) Manifest", draft-ietf-suit-manifest-14
1480 (work in progress), July 2021.
1482 [I-D.ietf-teep-otrp-over-http]
1483 Thaler, D., "HTTP Transport for Trusted Execution
1484 Environment Provisioning: Agent-to- TAM Communication",
1485 draft-ietf-teep-otrp-over-http-11 (work in progress), July
1486 2021.
1488 [I-D.ietf-teep-protocol]
1489 Tschofenig, H., Pei, M., Wheeler, D., Thaler, D., and A.
1490 Tsukamoto, "Trusted Execution Environment Provisioning
1491 (TEEP) Protocol", draft-ietf-teep-protocol-05 (work in
1492 progress), February 2021.
1494 [OTRP] GlobalPlatform, "Open Trust Protocol (OTrP) Profile v1.1",
1495 GlobalPlatform GPD_SPE_123, July 2020,
1496 .
1499 [RFC4949] Shirey, R., "Internet Security Glossary, Version 2",
1500 FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007,
1501 .
1503 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
1504 Housley, R., and W. Polk, "Internet X.509 Public Key
1505 Infrastructure Certificate and Certificate Revocation List
1506 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
1507 .
1509 [RFC6024] Reddy, R. and C. Wallace, "Trust Anchor Management
1510 Requirements", RFC 6024, DOI 10.17487/RFC6024, October
1511 2010, .
1513 [RFC7696] Housley, R., "Guidelines for Cryptographic Algorithm
1514 Agility and Selecting Mandatory-to-Implement Algorithms",
1515 BCP 201, RFC 7696, DOI 10.17487/RFC7696, November 2015,
1516 .
1518 [SGX] Intel, "Intel(R) Software Guard Extensions (Intel (R)
1519 SGX)", n.d., .
1523 [TrustZone]
1524 Arm, "Arm TrustZone Technology", n.d.,
1525 .
1528 Authors' Addresses
1530 Mingliang Pei
1531 Broadcom
1533 EMail: mingliang.pei@broadcom.com
1535 Hannes Tschofenig
1536 Arm Limited
1538 EMail: hannes.tschofenig@arm.com
1540 Dave Thaler
1541 Microsoft
1543 EMail: dthaler@microsoft.com
1545 David Wheeler
1546 Amazon
1548 EMail: davewhee@amazon.com