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