draft-ietf-teep-architecture-02.txt		draft-ietf-teep-architecture-03.txt
	TEEP M. Pei		TEEP M. Pei
	Internet-Draft Symantec		Internet-Draft Symantec
	Intended status: Informational H. Tschofenig		Intended status: Informational H. Tschofenig
	Expires: September 12, 2019 Arm Limited		Expires: January 9, 2020 Arm Limited
	D. Wheeler		D. Wheeler
	Intel		Intel
	A. Atyeo		A. Atyeo
	Intercede		Intercede
	L. Dapeng		L. Dapeng
	Alibaba Group		Alibaba Group
	March 11, 2019		July 08, 2019
	Trusted Execution Environment Provisioning (TEEP) Architecture		Trusted Execution Environment Provisioning (TEEP) Architecture
	draft-ietf-teep-architecture-02		draft-ietf-teep-architecture-03
	Abstract		Abstract
	A Trusted Execution Environment (TEE) is designed to provide a		A Trusted Execution Environment (TEE) is designed to provide a
	hardware-isolation mechanism to separate a regular operating system		hardware-isolation mechanism to separate a regular operating system
	from security-sensitive application components.		from security-sensitive application components.
	This architecture document motivates the design and standardization		This architecture document motivates the design and standardization
	of a protocol for managing the lifecycle of trusted applications		of a protocol for managing the lifecycle of trusted applications
	running inside a TEE.		running inside a TEE.
	skipping to change at page 1, line 43 ¶		skipping to change at page 1, line 43 ¶
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at https://datatracker.ietf.org/drafts/current/.		Drafts is at https://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on September 12, 2019.		This Internet-Draft will expire on January 9, 2020.
	Copyright Notice		Copyright Notice
	Copyright (c) 2019 IETF Trust and the persons identified as the		Copyright (c) 2019 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(https://trustee.ietf.org/license-info) in effect on the date of		(https://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	skipping to change at page 2, line 40 ¶		skipping to change at page 2, line 40 ¶
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
	3. Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . 8		3. Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . 8
	4. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 8		4. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 8
	4.1. Payment . . . . . . . . . . . . . . . . . . . . . . . . . 8		4.1. Payment . . . . . . . . . . . . . . . . . . . . . . . . . 8
	4.2. Authentication . . . . . . . . . . . . . . . . . . . . . 9		4.2. Authentication . . . . . . . . . . . . . . . . . . . . . 9
	4.3. Internet of Things . . . . . . . . . . . . . . . . . . . 9		4.3. Internet of Things . . . . . . . . . . . . . . . . . . . 9
	4.4. Confidential Cloud Computing . . . . . . . . . . . . . . 9		4.4. Confidential Cloud Computing . . . . . . . . . . . . . . 9
	5. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 9		5. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 9
	5.1. System Components . . . . . . . . . . . . . . . . . . . . 9		5.1. System Components . . . . . . . . . . . . . . . . . . . . 9
	5.2. Different Renditions of TEEP Architecture . . . . . . . . 12		5.2. Different Renditions of TEEP Architecture . . . . . . . . 12
	5.3. Multiple TAMs and Relationship to TAs . . . . . . . . . . 13		5.3. Multiple TAMs and Relationship to TAs . . . . . . . . . . 14
	5.4. Client Apps, Trusted Apps, and Personalization Data . . . 15		5.4. Client Apps, Trusted Apps, and Personalization Data . . . 15
	5.5. Examples of Application Delivery Mechanisms in Existing		5.5. Examples of Application Delivery Mechanisms in Existing
	TEEs . . . . . . . . . . . . . . . . . . . . . . . . . . 16		TEEs . . . . . . . . . . . . . . . . . . . . . . . . . . 16
	5.6. TEEP Architectural Support for Client App, TA, and		5.6. TEEP Architectural Support for Client App, TA, and
	Personalization Data Delivery . . . . . . . . . . . . . . 17		Personalization Data Delivery . . . . . . . . . . . . . . 17
	5.7. Entity Relations . . . . . . . . . . . . . . . . . . . . 17		5.7. Entity Relations . . . . . . . . . . . . . . . . . . . . 17
	5.8. Trust Anchors in TEE . . . . . . . . . . . . . . . . . . 20		5.8. Trust Anchors in TEE . . . . . . . . . . . . . . . . . . 20
	5.9. Trust Anchors in TAM . . . . . . . . . . . . . . . . . . 20		5.9. Trust Anchors in TAM . . . . . . . . . . . . . . . . . . 20
	5.10. Keys and Certificate Types . . . . . . . . . . . . . . . 20		5.10. Keys and Certificate Types . . . . . . . . . . . . . . . 21
	5.11. Scalability . . . . . . . . . . . . . . . . . . . . . . . 23		5.11. Scalability . . . . . . . . . . . . . . . . . . . . . . . 23
	5.12. Message Security . . . . . . . . . . . . . . . . . . . . 23		5.12. Message Security . . . . . . . . . . . . . . . . . . . . 23
	5.13. Security Domain Hierarchy and Ownership . . . . . . . . . 23		5.13. Security Domain . . . . . . . . . . . . . . . . . . . . . 23
	5.14. SD Owner Identification and TAM Certificate Requirements 24		5.14. A Sample Device Setup Flow . . . . . . . . . . . . . . . 23
	5.15. Service Provider Container . . . . . . . . . . . . . . . 25		6. TEEP Broker . . . . . . . . . . . . . . . . . . . . . . . . . 24
	5.16. A Sample Device Setup Flow . . . . . . . . . . . . . . . 25		6.1. Role of the TEEP Broker . . . . . . . . . . . . . . . . . 25
	6. TEEP Broker . . . . . . . . . . . . . . . . . . . . . . . . . 26		6.2. TEEP Broker Implementation Consideration . . . . . . . . 25
	6.1. Role of the Agent . . . . . . . . . . . . . . . . . . . . 27		6.2.1. TEEP Broker Distribution . . . . . . . . . . . . . . 26
	6.2. Agent Implementation Consideration . . . . . . . . . . . 27		6.2.2. Number of TEEP Brokers . . . . . . . . . . . . . . . 26
	6.2.1. Agent Distribution . . . . . . . . . . . . . . . . . 27		7. Attestation . . . . . . . . . . . . . . . . . . . . . . . . . 26
	6.2.2. Number of Agents . . . . . . . . . . . . . . . . . . 27		7.1. Attestation Cryptographic Properties . . . . . . . . . . 28
	7. Attestation . . . . . . . . . . . . . . . . . . . . . . . . . 28		7.2. TEEP Attestation Structure . . . . . . . . . . . . . . . 29
	7.1. Attestation Cryptographic Properties . . . . . . . . . . 30		7.3. TEEP Attestation Claims . . . . . . . . . . . . . . . . . 31
	7.2. TEEP Attestation Structure . . . . . . . . . . . . . . . 31		7.4. TEEP Attestation Flow . . . . . . . . . . . . . . . . . . 31
	7.3. TEEP Attestation Claims . . . . . . . . . . . . . . . . . 32		7.5. Attestation Key Example . . . . . . . . . . . . . . . . . 31
	7.4. TEEP Attestation Flow . . . . . . . . . . . . . . . . . . 33		7.5.1. Attestation Hierarchy Establishment: Manufacture . . 32
	7.5. Attestation Key Example . . . . . . . . . . . . . . . . . 33		7.5.2. Attestation Hierarchy Establishment: Device Boot . . 32
	7.5.1. Attestation Hierarchy Establishment: Manufacture . . 33		7.5.3. Attestation Hierarchy Establishment: TAM . . . . . . 32
	7.5.2. Attestation Hierarchy Establishment: Device Boot . . 34		8. Algorithm and Attestation Agility . . . . . . . . . . . . . . 32
	7.5.3. Attestation Hierarchy Establishment: TAM . . . . . . 34		9. Security Considerations . . . . . . . . . . . . . . . . . . . 33
	8. Algorithm and Attestation Agility . . . . . . . . . . . . . . 34		9.1. TA Trust Check at TEE . . . . . . . . . . . . . . . . . . 33
	9. Security Considerations . . . . . . . . . . . . . . . . . . . 35		9.2. One TA Multiple SP Case . . . . . . . . . . . . . . . . . 33
	9.1. TA Trust Check at TEE . . . . . . . . . . . . . . . . . . 35		9.3. Broker Trust Model . . . . . . . . . . . . . . . . . . . 34
	9.2. One TA Multiple SP Case . . . . . . . . . . . . . . . . . 35		9.4. Data Protection at TAM and TEE . . . . . . . . . . . . . 34
	9.3. Agent Trust Model . . . . . . . . . . . . . . . . . . . . 35		9.5. Compromised CA . . . . . . . . . . . . . . . . . . . . . 34
	9.4. Data Protection at TAM and TEE . . . . . . . . . . . . . 36		9.6. Compromised TAM . . . . . . . . . . . . . . . . . . . . . 34
	9.5. Compromised CA . . . . . . . . . . . . . . . . . . . . . 36		9.7. Certificate Renewal . . . . . . . . . . . . . . . . . . . 34
	9.6. Compromised TAM . . . . . . . . . . . . . . . . . . . . . 36		10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35
	9.7. Certificate Renewal . . . . . . . . . . . . . . . . . . . 36		11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 35
	10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36		12. References . . . . . . . . . . . . . . . . . . . . . . . . . 35
	11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 37		12.1. Normative References . . . . . . . . . . . . . . . . . . 35
	12. References . . . . . . . . . . . . . . . . . . . . . . . . . 37		12.2. Informative References . . . . . . . . . . . . . . . . . 35
	12.1. Normative References . . . . . . . . . . . . . . . . . . 37		Appendix A. History . . . . . . . . . . . . . . . . . . . . . . 37
	12.2. Informative References . . . . . . . . . . . . . . . . . 37		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 37
	Appendix A. History . . . . . . . . . . . . . . . . . . . . . . 38
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 38
	1. Introduction		1. Introduction
	Applications executing in a device are exposed to many different		Applications executing in a device are exposed to many different
	attacks intended to compromise the execution of the application, or		attacks intended to compromise the execution of the application, or
	reveal the data upon which those applications are operating. These		reveal the data upon which those applications are operating. These
	attacks increase with the number of other applications on the device,		attacks increase with the number of other applications on the device,
	with such other applications coming from potentially untrustworthy		with such other applications coming from potentially untrustworthy
	sources. The potential for attacks further increase with the		sources. The potential for attacks further increase with the
	complexity of features and applications on devices, and the		complexity of features and applications on devices, and the
	skipping to change at page 5, line 9 ¶		skipping to change at page 5, line 9 ¶
	device 'root of trust' and the type of TEE included in a device.		device 'root of trust' and the type of TEE included in a device.
	- A TEE in a device needs to determine whether a Service Provider		- A TEE in a device needs to determine whether a Service Provider
	(SP) that wants to manage a TA in the device is authorized to		(SP) that wants to manage a TA in the device is authorized to
	manage TAs in the TEE, and what TAs the SP is permitted to manage.		manage TAs in the TEE, and what TAs the SP is permitted to manage.
	- The parties involved in the protocol must be able to attest that a		- The parties involved in the protocol must be able to attest that a
	TEE is genuine and capable of providing the security protections		TEE is genuine and capable of providing the security protections
	required by a particular TA.		required by a particular TA.
	- A Service Provider (SP) must be able to deterine if a TA exists		- A Service Provider (SP) must be able to determine if a TA exists
	(is installed) on a device (in the TEE), and if not, install the		(is installed) on a device (in the TEE), and if not, install the
	TA in the TEE.		TA in the TEE.
	- A Service Provider (SP) must be able to check whether a TA in a		- A Service Provider (SP) must be able to check whether a TA in a
	device's TEE is the most up-to-date version, and if not, update		device's TEE is the most up-to-date version, and if not, update
	the TA in the TEE.		the TA in the TEE.
	- A Service Provider (SP) must be able to remove a TA in a device's		- A Service Provider (SP) must be able to remove a TA in a device's
	TEE if the SP is no longer offering such services or the services		TEE if the SP is no longer offering such services or the services
	are being revoked from a particular user (or device). For		are being revoked from a particular user (or device). For
	example, if a subscription or contract for a particular service		example, if a subscription or contract for a particular service
	has expired, or a payment by the user has not been completed or		has expired, or a payment by the user has not been completed or
	has been recinded.		has been rescinded.
	- A Service Provider (SP) must be able to define the relationship		- A Service Provider (SP) must be able to define the relationship
	between cooperating TAs under the SP's control, and specify		between cooperating TAs under the SP's control, and specify
	whether the TAs can communicate, share data, and/or share key		whether the TAs can communicate, share data, and/or share key
	material.		material.
	2. Terminology		2. Terminology
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and		"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
	skipping to change at page 10, line 8 ¶		skipping to change at page 10, line 8 ¶
	5.1. System Components		5.1. System Components
	The following are the main components in the system. Full		The following are the main components in the system. Full
	descriptions of components not previously defined are provided below.		descriptions of components not previously defined are provided below.
	Interactions of all components are further explained in the following		Interactions of all components are further explained in the following
	paragraphs.		paragraphs.
	+-------------------------------------------+		+-------------------------------------------+
	| Device |		| Device |
	| +--------+ | Service Provider		| +--------+ | Service Provider
	| | |----------+ |		| +-------------+ | |----------+ |
	| +-------------+ | TEEP |---------+| |		| | TEE-1 | | TEEP |---------+| |
	| | TEE-1 |<------| Broker | | || +--------+ |		| | +--------+ | +----| Broker | | || +--------+ |
	| | | | |<---+ | |+-->| |<-+		| | | TEEP | | | | |<---+ | |+-->| |<-+
	| | | | | | | | +-| TAM-1 |		| | | Agent |<----+ | | | | | +-| TAM-1 |
	| | | | |<-+ | | +->| | |<-+		| | +--------+ | | |<-+ | | +->| | |<-+
	| | +---+ +---+ | +--------+ | | | | +--------+ |		| | | +--------+ | | | | +--------+ |
	| | |TA1| |TA2| | | | | | TAM-2 | |		| | +---+ +---+ | | | | | TAM-2 | |
	| +-->| | | | | +-------+ | | | +--------+ |		| +-->|TA1| |TA2| | +-------+ | | | +--------+ |
	| | | | | | |<---------| App-2 |--+ | | |		| | | | | | |<---------| App-2 |--+ | | |
	| | | +---+ +---+ | +-------+ | | | Device Administrator		| | | +---+ +---+ | +-------+ | | | Device Administrator
	| | +-------------+ | App-1 | | | |		| | +-------------+ | App-1 | | | |
	| | | | | | |		| | | | | | |
	| +--------------------| |---+ | |		| +--------------------| |---+ | |
	| | |--------+ |		| | |--------+ |
	| +-------+ |		| +-------+ |
	+-------------------------------------------+		+-------------------------------------------+
	Figure 1: Notional Architecture of TEEP		Figure 1: Notional Architecture of TEEP
	- Service Providers (SP) and Device Administrators (DA) utilize the		- Service Providers (SP) and Device Administrators (DA) utilize the
	services of a TAM to manage TAs on Devices. SPs do not directly		services of a TAM to manage TAs on Devices. SPs do not directly
	interact with devices. DAs may elect to use a TAM for remote		interact with devices. DAs may elect to use a TAM for remote
	administration of TAs instead of managing each device directly.		administration of TAs instead of managing each device directly.
	- TAM: A TAM is responsible for performing lifecycle management		- TAM: A TAM is responsible for performing lifecycle management
	activity on TA's and SD's on behalf of Service Providers and		activity on TA's on behalf of Service Providers and Device
	Device Administrators. This includes creation and deletion of		Administrators. This includes creation and deletion of TA's, and
	TA's and SD's, and may include, for example, over-the-air updates		may include, for example, over-the-air updates to keep an SP's TAs
	to keep an SP's TAs up-to-date and clean up when a version should		up-to-date and clean up when a version should be removed. TAMs
	be removed. TAMs may provide services that make it easier for SPs		may provide services that make it easier for SPs or DAs to use the
	or DAs to use the TAM's service to manage multiple devices,		TAM's service to manage multiple devices, although that is not
	although that is not required of a TAM.		required of a TAM.
	The TAM performs its management of TA's and SD's through an		The TAM performs its management of TA's through an interaction
	interaction with a Device's TEEP Broker. As shown in		with a Device's TEEP Broker. As shown in #notionalarch, the TAM
	#notionalarch, the TAM cannot directly contact a Device, but must		cannot directly contact a Device, but must wait for a the TEEP
	wait for a the TEEP Broker or a Client Application to contact the		Broker or a Client Application to contact the TAM requesting a
	TAM requesting a particular service. This architecture is		particular service. This architecture is intentional in order to
	intentional in order to accommodate network and application		accommodate network and application firewalls that normally
	firewalls that normally protect user and enterprise devices from		protect user and enterprise devices from arbitrary connections
	arbitrary connections from external network entities.		from external network entities.
	A TAM may be publicly available for use by many SPs, or a TAM may		A TAM may be publicly available for use by many SPs, or a TAM may
	be private, and accessible by only one or a limited number of SPs.		be private, and accessible by only one or a limited number of SPs.
	It is expected that manufacturers and carriers will run their own		It is expected that manufacturers and carriers will run their own
	private TAM. Another example of a private TAM is a TAM running as		private TAM. Another example of a private TAM is a TAM running as
	a Software-as-a-Service (SaaS) within an SP.		a Software-as-a-Service (SaaS) within an SP.
	A SP or Device Administrator chooses a particular TAM based on		A SP or Device Administrator chooses a particular TAM based on
	whether the TAM is trusted by a Device or set of Devices. The TAM		whether the TAM is trusted by a Device or set of Devices. The TAM
	skipping to change at page 11, line 33 ¶		skipping to change at page 11, line 33 ¶
	Any entity is free to operate a TAM. For a TAM to be successful,		Any entity is free to operate a TAM. For a TAM to be successful,
	it must have its public key or certificate installed in Devices		it must have its public key or certificate installed in Devices
	Trust Anchor list. A TAM may set up a relationship with device		Trust Anchor list. A TAM may set up a relationship with device
	manufacturers or carriers to have them install the TAM's keys in		manufacturers or carriers to have them install the TAM's keys in
	their device's Trust Anchor list. Alternatively, a TAM may		their device's Trust Anchor list. Alternatively, a TAM may
	publish its certificate and allow Device Administrators to install		publish its certificate and allow Device Administrators to install
	the TAM's certificate in their devices as an after-market-action.		the TAM's certificate in their devices as an after-market-action.
	- TEEP Broker: The TEEP Broker is an application running in a Rich		- TEEP Broker: The TEEP Broker is an application running in a Rich
	Execution Environment that enables the message protocol exchange		Execution Environment (REE) that enables the message protocol
	between a TAM and a TEE in a device. The TEEP Broker does not		exchange between a TAM and a TEE in a device. The TEEP Broker
	process messages on behalf of a TEE, but merely is responsible for		does not process messages on behalf of a TEE, but merely is
	relaying messages from the TAM to the TEE, and for returning the		responsible for relaying messages from the TAM to the TEE, and for
	TEE's responses to the TAM.		returning the TEE's responses to the TAM.
	A Client Application is expected to communicate with a TAM to		A Client Application is expected to communicate with a TAM to
	request TAs that it needs to use. The Client Application needs to		request TAs that it needs to use. The Client Application needs to
	pass the messages from the TAM to TEEs in the device. This calls		pass the messages from the TAM to TEEs in the device. This calls
	for a component in the REE that Client Applications can use to		for a component in the REE that Client Applications can use to
	pass messages to TEEs. An Agent is thus an application in the REE		pass messages to TEEs. The TEEP Broker is thus an application in
	or software library that can relay messages from a Client		the REE or software library that can relay messages from a Client
	Application to a TEE in the device. A device usually comes with		Application to a TEE in the device. A device usually comes with
	only one active TEE. A TEE may provide such an Agent to the		only one active TEE. A TEE may provide such a Broker to the
	device manufacturer to be bundled in devices. Such a TEE must		device manufacturer to be bundled in devices. Such a TEE must
	also include an Agent counterpart, namely, a processing module		also include a Broker counterpart, namely, a TEEP Agent inside the
	inside the TEE, to parse TAM messages sent through the Agent. An		TEE, to parse TAM messages sent through the Broker. A TEEP Broker
	Agent is generally acting as a dummy relaying box with just the		is generally acting as a dummy relaying box with just the TEE
	TEE interacting capability; it doesn't need and shouldn't parse		interacting capability; it doesn't need and shouldn't parse
	protocol messages.		protocol messages.
			- TEEP Agent: the TEEP Agent is a processing module running inside a
			TEE that receives TAM requests that are relayed via a TEEP Broker
			that runs in an REE. A TEEP Agent in the TEE may parse requests
			or forward requests to other processing modules in a TEE, which is
			up to a TEE provider's implementation. A response message
			corresponding to a TAM request is sent by a TEEP Agent back to a
			TEEP Broker.
	- Certification Authority (CA): Certificate-based credentials used		- Certification Authority (CA): Certificate-based credentials used
	for authenticating a device, a TAM and an SP. A device embeds a		for authenticating a device, a TAM and an SP. A device embeds a
	list of root certificates (Trust Anchors), from trusted CAs that a		list of root certificates (Trust Anchors), from trusted CAs that a
	TAM will be validated against. A TAM will remotely attest a		TAM will be validated against. A TAM will remotely attest a
	device by checking whether a device comes with a certificate from		device by checking whether a device comes with a certificate from
	a CA that the TAM trusts. The CAs do not need to be the same;		a CA that the TAM trusts. The CAs do not need to be the same;
	different CAs can be chosen by each TAM, and different device CAs		different CAs can be chosen by each TAM, and different device CAs
	can be used by different device manufacturers.		can be used by different device manufacturers.
	5.2. Different Renditions of TEEP Architecture		5.2. Different Renditions of TEEP Architecture
	There is nothing prohibiting a device from implementing multiple		There is nothing prohibiting a device from implementing multiple
	TEEs. In addition, some TEEs ( for example, SGX) present themselves		TEEs. In addition, some TEEs (for example, SGX) present themselves
	as separate containers within memory without a controlling manager		as separate containers within memory without a controlling manager
	within the TEE. In these cases, the rich operating system hosts		within the TEE. In these cases, the rich operating system hosts
	multiple TEEP brokers, where each broker manages a particular TEE or		multiple TEEP brokers, where each broker manages a particular TEE or
	set of TEEs. Enumeration and access to the appropriate broker is up		set of TEEs. Enumeration and access to the appropriate broker is up
	to the rich OS and the applications. Verification that the correct		to the rich OS and the applications. Verification that the correct
	TA has been reached then becomes a matter of properly verifying TA		TA has been reached then becomes a matter of properly verifying TA
	attestations, which are unforgeable. The multiple TEE approach is		attestations, which are unforgeable. The multiple TEE approach is
	shown in the diagram below. For brevity, TEEP Broker 2 is shown		shown in the diagram below. For brevity, TEEP Broker 2 is shown
	interacting with only one TAM and UA, but no such limitation is		interacting with only one TAM and UA, but no such limitation is
	intended to be implied in the architecture.		intended to be implied in the architecture.
	+-------------------------------------------+		+-------------------------------------------+
	| Device |		| Device |
	| +--------+ | Service Provider		| +--------+ | Service Provider
	| | |----------+ |		| | |----------+ |
	| +-------------+ | TEEP |---------+| |		| +-------------+ | TEEP |---------+| |
	| | TEE-1 |<------| Broker | | || +--------+ |		| | TEE-1 | +---| Broker | | || +--------+ |
	| | | | 1 |<---+ | |+-->| |<-+		| | | | | 1 |<---+ | |+-->| |<-+
			| | +-------+ | | | | | | | | |
			| | | TEEP | | | | | | | | | |
			| | | Agent |<------+ | | | | | | |
			| | | 1 | | | | | | | | |
			| | +-------+ | | | | | | | |
			| | | | | | | | | |
	| | +---+ +---+ | | | | | | +-| TAM-1 |		| | +---+ +---+ | | | | | | +-| TAM-1 |
	| | |TA1| |TA2| | | |<-+ | | +->| | |<-+		| | |TA1| |TA2| | | |<-+ | | +->| | |<-+
	| +-->| | | |<---+ +--------+ | | | | +--------+ |		| +-->| | | |<---+ +--------+ | | | | +--------+ |
	| | | +---+ +---+ | | | | | | TAM-2 | |		| | | +---+ +---+ | | | | | | TAM-2 | |
	| | | | | +-------+ | | | +--------+ |		| | | | | +-------+ | | | +--------+ |
	| | +-------------+ +-----| App-2 |--+ | | ^ |		| | +-------------+ +-----| App-2 |--+ | | ^ |
	| | +-------+ | | | | Device		| | +-------+ | | | | Device
	| +--------------------| App-1 | | | | | Administrator		| +--------------------| App-1 | | | | | Administrator
	| +------| | | | | |		| +------| | | | | |
	| +-----------|-+ | |---+ | | |		| +-----------|-+ | |---+ | | |
	| | TEE-2 | | | |--------+ | |		| | TEE-2 | | | |--------+ | |
	| | | | | |------+ | |		| | +------+ | | | |------+ | |
	| | +---+ | | +-------+ | | |		| | | TEEP | | | +-------+ | | |
	| | |TA3|<----+ | +----------+ | | |		| | | Agent|<-----+ | | |
	| | | | | | TEEP |<--+ | |		| | | 2 | | | | | | |
	| | +---+ |<---| Broker |----------------+		| | +------+ | | | | | |
			| | | | | | | |
			| | +---+ | | | | | |
			| | |TA3|<----+ | | +----------+ | | |
			| | | | | | | TEEP |<--+ | |
			| | +---+ | +--| Broker |----------------+
	| | | | 2 | |		| | | | 2 | |
	| | | | | |
	| +-------------+ +----------+ |		| +-------------+ +----------+ |
	| |		| |
	+-------------------------------------------+		+-------------------------------------------+
	Figure 2: Notional Architecture of TEEP wtih multiple TEEs		Figure 2: Notional Architecture of TEEP wtih multiple TEEs
	In the diagram above, TEEP Broker 1 controls interactions with the		In the diagram above, TEEP Broker 1 controls interactions with the
	TA's in TEE-1, and TEEP Broker 2 controls interactions with the TA's		TA's in TEE-1, and TEEP Broker 2 controls interactions with the TA's
	in TEE-2. This presents some challenges for a TAM in completely		in TEE-2. This presents some challenges for a TAM in completely
	managing the device, since a TAM may not interact with all the TEEP		managing the device, since a TAM may not interact with all the TEEP
	skipping to change at page 14, line 36 ¶		skipping to change at page 14, line 46 ¶
	situations, an SP may use only a single TAM - this is likely the case		situations, an SP may use only a single TAM - this is likely the case
	for enterprise applications or SPs serving a closed community. For		for enterprise applications or SPs serving a closed community. For
	broad public apps, there will likely be multiple TAMs in the manifest		broad public apps, there will likely be multiple TAMs in the manifest
	- one servicing one brand of mobile device and another servicing a		- one servicing one brand of mobile device and another servicing a
	different manufacturer, etc. Because different devices and different		different manufacturer, etc. Because different devices and different
	manufacturers trust different TAMs, the manifest will include		manufacturers trust different TAMs, the manifest will include
	different TAMs that support this SP's client app and TA. Multiple		different TAMs that support this SP's client app and TA. Multiple
	TAMs allow the SP to provide thier service and this app (and TA) to		TAMs allow the SP to provide thier service and this app (and TA) to
	multiple different devices.		multiple different devices.
	When the TEEP Broker recieves a request to contact the TAM for a		When the TEEP Broker receives a request to contact the TAM for a
	Client App in order to install a TA, a list of TAMs may be provided.		Client App in order to install a TA, a list of TAMs may be provided.
	The TEEP Broker selects a single TAM that is consistent with the list		The TEEP Broker selects a single TAM that is consistent with the list
	of trusted TAMs (trust anchors) provisioned on the device. For any		of trusted TAMs (trust anchors) provisioned on the device. For any
	client app, there should be only a single TAM for the TEEP Broker to		client app, there should be only a single TAM for the TEEP Broker to
	contact. This is also the case when a Client App uses multiple TAs,		contact. This is also the case when a Client App uses multiple TAs,
	or when one TA depends on anther TA in a software dependency (see		or when one TA depends on anther TA in a software dependency (see
	section TBD). The reason is that the SP should provide each TAM that		section TBD). The reason is that the SP should provide each TAM that
	it places in the Client App's manifest all the TAs that the app		it places in the Client App's manifest all the TAs that the app
	requires. There is no benefit to going to multiple different TAMs,		requires. There is no benefit to going to multiple different TAMs,
	and there is no need for a special TAM to be contacted for a specific		and there is no need for a special TAM to be contacted for a specific
	skipping to change at page 15, line 39 ¶		skipping to change at page 15, line 49 ¶
	user. This personalization data is dependent on the TEE, the TA and		user. This personalization data is dependent on the TEE, the TA and
	the SP; an example of personalization data might be username and		the SP; an example of personalization data might be username and
	password of the device user's account with the SP, or a secret		password of the device user's account with the SP, or a secret
	symmetric key used to by the TA to communicate with the SP. The		symmetric key used to by the TA to communicate with the SP. The
	personalization data must be encrypted to preserve the		personalization data must be encrypted to preserve the
	confidentiality of potentially sensitive data contained within it.		confidentiality of potentially sensitive data contained within it.
	Other than this requirement to support confidentiality, TEEP place no		Other than this requirement to support confidentiality, TEEP place no
	limitations or requirements on the personalization data.		limitations or requirements on the personalization data.
	There are three possible cases for bundling of the Client App, TA,		There are three possible cases for bundling of the Client App, TA,
	and personalizaiton data:		and personalization data:
	1. The Client App, TA, and personnalization data are all bundled		1. The Client App, TA, and personalization data are all bundled
	together in a single package by the SP and provided to the TEEP		together in a single package by the SP and provided to the TEEP
	Broker through the TAM.		Broker through the TAM.
	2. The Client App and the TA are bundled together in a single		2. The Client App and the TA are bundled together in a single
	binary, which the TAM or a publicly accessible app store		binary, which the TAM or a publicly accessible app store
	maintains in repository, and the personalization data is		maintains in repository, and the personalization data is
	separately provided by the SP. In this case, the personalization		separately provided by the SP. In this case, the personalization
	data is collected by the TAM and included in the InstallTA		data is collected by the TAM and included in the InstallTA
	message to the TEEP Broker.		message to the TEEP Broker.
	skipping to change at page 17, line 15 ¶		skipping to change at page 17, line 24 ¶
	5.6. TEEP Architectural Support for Client App, TA, and Personalization		5.6. TEEP Architectural Support for Client App, TA, and Personalization
	Data Delivery		Data Delivery
	This section defines TEEP support for the three different cases for		This section defines TEEP support for the three different cases for
	delivery of the Client App, TA, and personalization data.		delivery of the Client App, TA, and personalization data.
	[Note: discussion of format of this single binary, and who/what is		[Note: discussion of format of this single binary, and who/what is
	responsible for splitting these things apart, and installing the		responsible for splitting these things apart, and installing the
	client app into the REE, the TA into the TEE, and the personalization		client app into the REE, the TA into the TEE, and the personalization
	data into the TEE or TA. Obviously the decryption must be done by		data into the TEE or TA. Obviously the decryption must be done by
	the TEE but this may not be suported by all TAs.]		the TEE but this may not be supported by all TAs.]
	5.7. Entity Relations		5.7. Entity Relations
	This architecture leverages asymmetric cryptography to authenticate a		This architecture leverages asymmetric cryptography to authenticate a
	device to a TAM. Additionally, a TEE in a device authenticates a TAM		device to a TAM. Additionally, a TEE in a device authenticates a TAM
	and TA signer. The provisioning of Trust Anchors to a device may		and TA signer. The provisioning of Trust Anchors to a device may
	different from one use case to the other. A device administrator may		different from one use case to the other. A device administrator may
	want to have the capability to control what TAs are allowed. A		want to have the capability to control what TAs are allowed. A
	device manufacturer enables verification of the TA signers and TAM		device manufacturer enables verification of the TA signers and TAM
	providers; it may embed a list of default Trust Anchors that the		providers; it may embed a list of default Trust Anchors that the
	skipping to change at page 19, line 12 ¶		skipping to change at page 19, line 12 ¶
	The following diagram shows a system diagram about the entity		The following diagram shows a system diagram about the entity
	relationships between CAs, TAMs, SPs and devices.		relationships between CAs, TAMs, SPs and devices.
	------- Message Protocol -----		------- Message Protocol -----
	| |		| |
	| |		| |
	-------------------- --------------- ----------		-------------------- --------------- ----------
	| REE | TEE | | TAM | | SP |		| REE | TEE | | TAM | | SP |
	| --- | --- | | --- | | -- |		| --- | --- | | --- | | -- |
	| | | | | | |		| | | | | | |
	| Client | SD (TAs)| | SD / TA | | TA |		| Client | TEEP | | TA | | TA |
	| Apps | | | Mgmt | | |		| Apps | Agent | | Mgmt | | |
	| | | | | | | |		| | | | | | | |
	| | | List of | | List of | | |		| | | TAs | | | | |
			| TEEP | | | | | |
			| Broker | List of | | List of | | |
	| | Trusted | | Trusted | | |		| | Trusted | | Trusted | | |
	| Agent | TAM/SP | | FW/TEE | | |		| | TAM/SP | | FW/TEE | | |
	| | CAs | | CAs | | |		| | CAs | | CAs | | |
	| | | | | | |		| | | | | | |
	| |TEE Key/ | | TAM Key/ | |SP Key/ |		| |TEE Key/ | | TAM Key/ | |SP Key/ |
	| | Cert | | Cert | | Cert |		| | Cert | | Cert | | Cert |
	| | FW Key/ | | | | |		| | FW Key/ | | | | |
	| | Cert | | | | |		| | Cert | | | | |
	-------------------- --------------- ----------		-------------------- --------------- ----------
	| | |		| | |
	| | |		| | |
	------------- ---------- ---------		------------- ---------- ---------
	skipping to change at page 19, line 39 ¶		skipping to change at page 19, line 41 ¶
	------------- ---------- ---------		------------- ---------- ---------
	Figure 5: Keys		Figure 5: Keys
	In the previous diagram, different CAs can be used for different		In the previous diagram, different CAs can be used for different
	types of certificates. Messages are always signed, where the signer		types of certificates. Messages are always signed, where the signer
	key is the message originator's private key such as that of a TAM,		key is the message originator's private key such as that of a TAM,
	the private key of trusted firmware (TFW), or a TEE's private key.		the private key of trusted firmware (TFW), or a TEE's private key.
	The main components consist of a set of standard messages created by		The main components consist of a set of standard messages created by
	a TAM to deliver device SD and TA management commands to a device,		a TAM to deliver TA management commands to a device, and device
	and device attestation and response messages created by a TEE that		attestation and response messages created by a TEE that responds to a
	responds to a TAM's message.		TAM's message.
	It should be noted that network communication capability is generally		It should be noted that network communication capability is generally
	not available in TAs in today's TEE-powered devices. The networking		not available in TAs in today's TEE-powered devices. The networking
	functionality must be delegated to a rich Client Application. Client		functionality must be delegated to a rich Client Application. Client
	Applications will need to rely on an agent in the REE to interact		Applications will need to rely on an agent in the REE to interact
	with a TEE for message exchanges. Consequently, a TAM generally		with a TEE for message exchanges. Consequently, a TAM generally
	communicates with a Client Application about how it gets messages		communicates with a Client Application about how it gets messages
	that originate from a TEE inside a device. Similarly, a TA or TEE		that originate from a TEE inside a device. Similarly, a TA or TEE
	generally gets messages from a TAM via some Client Application,		generally gets messages from a TAM via some Client Application,
	namely, an agent in this protocol architecture, not directly from the		namely, a TEEP Broker in this protocol architecture, not directly
	network.		from the network.
	It is imperative to have an interoperable protocol to communicate		It is imperative to have an interoperable protocol to communicate
	with different TAMs and different TEEs in different devices. This is		with different TAMs and different TEEs in different devices. This is
	the role of the agent, which is a software component that bridges		the role of the Broker, which is a software component that bridges
	communication between a TAM and a TEE. The agent does not need to		communication between a TAM and a TEE. Furthermore the Broker
	know the actual content of messages except for the TEE routing		communicates with a Agent inside a TEE that is responsible to process
	information.		TAM requests. The Broker in REE does not need to know the actual
			content of messages except for the TEE routing information.
	5.8. Trust Anchors in TEE		5.8. Trust Anchors in TEE
	Each TEE comes with a trust store that contains a whitelist of Trust		Each TEE comes with a trust store that contains a whitelist of Trust
	Anchors that are used to validate a TAM's certificate. A TEE will		Anchors that are used to validate a TAM's certificate. A TEE will
	accept a TAM to create new Security Domains and install new TAs on		accept a TAM to create new Security Domains and install new TAs on
	behalf of an SP only if the TAM's certificate is chained to one of		behalf of an SP only if the TAM's certificate is chained to one of
	the root CA certificates in the TEE's trust store.		the root CA certificates in the TEE's trust store.
	A TEE's trust store is typically preloaded at manufacturing time. It		A TEE's trust store is typically preloaded at manufacturing time. It
	skipping to change at page 21, line 30 ¶		skipping to change at page 21, line 36 ¶
	| certificate | | a root | embedded in TEE | can be used |		| certificate | | a root | embedded in TEE | can be used |
	| | | CA | | by a TAM |		| | | CA | | by a TAM |
	| | | | | |		| | | | | |
	| 4. SP key | SP | SP | A SP uses a TAM. | 1 or |		| 4. SP key | SP | SP | A SP uses a TAM. | 1 or |
	| pair and | | signer | TA is signed by a | multiple |		| pair and | | signer | TA is signed by a | multiple |
	| certificate | | CA | SP signer. TEE | can be used |		| certificate | | CA | SP signer. TEE | can be used |
	| | | | delegates trust | by a TAM |		| | | | delegates trust | by a TAM |
	| | | | of TA to TAM. SP | |		| | | | of TA to TAM. SP | |
	| | | | signer is | |		| | | | signer is | |
	| | | | associated with a | |		| | | | associated with a | |
	| | | | SD as the owner. | |		| | | | TA as the owner. | |
	+-------------+----------+--------+-------------------+-------------+		+-------------+----------+--------+-------------------+-------------+
	Figure 6: Key and Certificate Types		Figure 6: Key and Certificate Types
	1. TFW key pair and certificate: A key pair and certificate for		1. TFW key pair and certificate: A key pair and certificate for
	evidence of trustworthy firmware in a device. This key pair is		evidence of trustworthy firmware in a device. This key pair is
	optional for TEEP architecture. Some TEE may present its trusted		optional for TEEP architecture. Some TEE may present its trusted
	attributes to a TAM using signed attestation with a TFW key. For		attributes to a TAM using signed attestation with a TFW key. For
	example, a platform that uses a hardware based TEE can have		example, a platform that uses a hardware based TEE can have
	attestation data signed by a hardware protected TFW key.		attestation data signed by a hardware protected TFW key.
	skipping to change at page 23, line 26 ¶		skipping to change at page 23, line 29 ¶
	existing roots without requiring that TAMs are updated with		existing roots without requiring that TAMs are updated with
	information about the new device factory. Likewise, new TAMs can		information about the new device factory. Likewise, new TAMs can
	join the ecosystem, providing they are issued a TAM certificate that		join the ecosystem, providing they are issued a TAM certificate that
	chains to an existing root whereby existing TEEs will be allowed to		chains to an existing root whereby existing TEEs will be allowed to
	be personalized by the TAM without requiring changes to the TEE		be personalized by the TAM without requiring changes to the TEE
	itself. This enables the ecosystem to scale, and avoids the need for		itself. This enables the ecosystem to scale, and avoids the need for
	centralized databases of all TEEs produced or all TAMs that exist.		centralized databases of all TEEs produced or all TAMs that exist.
	5.12. Message Security		5.12. Message Security
	Messages created by a TAM are used to deliver device SD and TA		Messages created by a TAM are used to deliver TA management commands
	management commands to a device, and device attestation and messages		to a device, and device attestation and messages created by the
	created by the device TEE to respond to TAM messages.		device TEE to respond to TAM messages.
	These messages are signed end-to-end and are typically encrypted such		These messages are signed end-to-end and are typically encrypted such
	that only the targeted device TEE or TAM is able to decrypt and view		that only the targeted device TEE or TAM is able to decrypt and view
	the actual content.		the actual content.
	5.13. Security Domain Hierarchy and Ownership		5.13. Security Domain
	The primary job of a TAM is to help an SP to manage its trusted
	applications. A TA is typically installed in an SD. An SD is
	commonly created for an SP.
	When an SP delegates its SD and TA management to a TAM, an SD is
	created on behalf of a TAM in a TEE and the owner of the SD is
	assigned to the TAM. An SD may be associated with an SP but the TAM
	has full privilege to manage the SD for the SP.
	Each SD for an SP is associated with only one TAM. When an SP
	changes TAM, a new SP SD must be created to associate with the new
	TAM. The TEE will maintain a registry of TAM ID and SP SD ID
	mapping.
	From an SD ownership perspective, the SD tree is flat and there is
	only one level. An SD is associated with its owner. It is up to the
	TEE implementation how it maintains SD binding information for a TAM
	and different SPs under the same TAM.
	It is an important decision in this architecture that a TEE doesn't
	need to know whether a TAM is authorized to manage the SD for an SP.
	This authorization is implicitly triggered by an SP Client
	Application, which instructs what TAM it wants to use. An SD is
	always associated with a TAM in addition to its SP ID. A rogue TAM
	isn't able to do anything on an unauthorized SP's SD managed by
	another TAM.
	Since a TAM may support multiple SPs, sharing the same SD name for
	different SPs creates a dependency in deleting an SD. An SD can be
	deleted only after all TAs associated with the SD are deleted. An SP
	cannot delete a Security Domain on its own with a TAM if a TAM
	decides to introduce such sharing. There are cases where multiple
	virtual SPs belong to the same organization, and a TAM chooses to use
	the same SD name for those SPs. This is totally up to the TAM
	implementation and out of scope of this specification.
	5.14. SD Owner Identification and TAM Certificate Requirements
	There is a need of cryptographically binding proof about the owner of
	an SD in a device. When an SD is created on behalf of a TAM, a
	future request from the TAM must present itself as a way that the TEE
	can verify it is the true owner. The certificate itself cannot
	reliably used as the owner because TAM may change its certificate.
	** need to handle the normal key roll-over case, as well as the less
	frequent key compromise case
	To this end, each TAM will be associated with a trusted identifier
	defined as an attribute in the TAM certificate. This field is kept
	the same when the TAM renew its certificates. A TAM CA is
	responsible to vet the requested TAM attribute value.
	This identifier value must not collide among different TAM providers,
	and one TAM shouldn't be able to claim the identifier used by another
	TAM provider.
	The certificate extension name to carry the identifier can initially
	use SubjectAltName:registeredID. A dedicated new extension name may
	be registered later.
	One common choice of the identifier value is the TAM's service URL.
	A CA can verify the domain ownership of the URL with the TAM in the
	certificate enrollment process.
	A TEE can assign this certificate attribute value as the TAM owner ID
	for the SDs that are created for the TAM.
	An alternative way to represent an SD ownership by a TAM is to have a
	unique secret key upon SD creation such that only the creator TAM is
	able to produce a proof-of-possession (PoP) data with the secret.
	5.15. Service Provider Container
	A sample Security Domain hierarchy for the TEE is shown in Figure 7.
	----------
	| TEE |
	----------
	|
	| ----------
	|----------| SP1 SD1 |
	| ----------
	| ----------
	|----------| SP1 SD2 |
	| ----------
	| ----------
	|----------| SP2 SD1 |
	----------
	Figure 7: Security Domain Hierarchy
	The architecture separates SDs and TAs such that a TAM can only		No security domain (SD) is explicitly assumed in a TEE for TA
	manage or retrieve data for SDs and TAs that it previously created		management. Some TEE, for example, some TEE compliant with Global
	for the SPs it represents.		Platform (GP), may continue to choose to use SD to organize resource
			partition and security boundaries. It is up to a TEE implementation
			to decide how a SD is attached to a TA installation, for example, one
			SD could be created per TA.
	5.16. A Sample Device Setup Flow		5.14. A Sample Device Setup Flow
	Step 1: Prepare Images for Devices		Step 1: Prepare Images for Devices
	1. [TEE vendor] Deliver TEE Image (CODE Binary) to device OEM		1. [TEE vendor] Deliver TEE Image (CODE Binary) to device OEM
	2. [CA] Deliver root CA Whitelist		2. [CA] Deliver root CA Whitelist
	3. [Soc] Deliver TFW Image		3. [Soc] Deliver TFW Image
	Step 2: Inject Key Pairs and Images to Devices		Step 2: Inject Key Pairs and Images to Devices
	1. [OEM] Generate TFW Key Pair (May be shared among multiple		1. [OEM] Generate TFW Key Pair (May be shared among multiple
	devices)		devices)
	2. [OEM] Flash signed TFW Image and signed TEE Image onto devices		2. [OEM] Flash signed TFW Image and signed TEE Image onto devices
	skipping to change at page 26, line 34 ¶		skipping to change at page 24, line 45 ¶
	[GPTEE] specifies one such architecture. This calls for a software		[GPTEE] specifies one such architecture. This calls for a software
	module in the REE world to handle the network communication. Each		module in the REE world to handle the network communication. Each
	Client Application in the REE might carry this communication		Client Application in the REE might carry this communication
	functionality but such functionality must also interact with the TEE		functionality but such functionality must also interact with the TEE
	for the message exchange.		for the message exchange.
	The TEE interaction will vary according to different TEEs. In order		The TEE interaction will vary according to different TEEs. In order
	for a Client Application to transparently support different TEEs, it		for a Client Application to transparently support different TEEs, it
	is imperative to have a common interface for a Client Application to		is imperative to have a common interface for a Client Application to
	invoke for exchanging messages with TEEs.		invoke for exchanging messages with TEEs.
	A shared agent comes to meet this need. An agent is an application		A shared module in REE comes to meet this need. A TEEP broker is an
	running in the REE of the device or an SDK that facilitates		application running in the REE of the device or an SDK that
	communication between a TAM and a TEE. It also provides interfaces		facilitates communication between a TAM and a TEE. It also provides
	for Client Applications to query and trigger TA installation that the		interfaces for Client Applications to query and trigger TA
	application needs to use.		installation that the application needs to use.
	It isn't always that a Client Application directly calls such an		It isn't always that a Client Application directly calls such a
	agent to interact with a TEE. A REE Application Installer might		Broker to interact with a TEE. A REE Application Installer might
	carry out TEE and TAM interaction to install all required TAs that a		carry out TEE and TAM interaction to install all required TAs that a
	Client Application depends. A Client Application may have a metadata		Client Application depends. A Client Application may have a metadata
	file that describes the TAs it depends on and the associated TAM that		file that describes the TAs it depends on and the associated TAM that
	each TA installation goes to use. The REE Application Installer can		each TA installation goes to use. The REE Application Installer can
	inspect the application metadata file and installs TAs on behalf of		inspect the application metadata file and installs TAs on behalf of
	the Client Application without requiring the Client Application to		the Client Application without requiring the Client Application to
	run first.		run first.
	This interface for Client Applications or Application Installers may		This interface for Client Applications or Application Installers may
	be commonly an OS service call for an REE OS. A Client Application		be commonly in a form of an OS service call for an REE OS. A Client
	or an Application Installer interacts with the device TEE and the		Application or an Application Installer interacts with the device TEE
	TAMs.		and the TAMs.
	6.1. Role of the Agent		6.1. Role of the TEEP Broker
	An agent abstracts the message exchanges with the TEE in a device.		A TEEP Broker abstracts the message exchanges with a TEE in a device.
	The input data is originated from a TAM or the first initialization		The input data is originated from a TAM or the first initialization
	call to trigger a TA installation.		call to trigger a TA installation.
	The agent may internally process a message from a TAM. At least, it		The Broker doesn't need to parse a message content received from a
	needs to know where to route a message, e.g., TEE instance. It does		TAM that should be processed by a TEE. When a device has more than
	not need to process or verify message content.		one TEE, one TEEP Broker per TEE could be present in REE. A TEEP
			Broker interacts with a TEEP Agent inside a TEE.
	The agent returns TEE / TFW generated response messages to the		A TAM message may indicate the target TEE where a TA should be
	caller. The agent is not expected to handle any network connection		installed. A compliant TEEP protocol should include a target TEE
	with an application or TAM.		identifier for a TEEP Broker when multiple TEEs are present.
	The agent only needs to return an agent error message if the TEE is		The Broker relays the response messages generated from a TEEP Agent
	not reachable for some reason. Other errors are represented as		in a TEE to the TAM. The Broker is not expected to handle any
	response messages returned from the TEE which will then be passed to		network connection with an application or TAM.
	the TAM.
	6.2. Agent Implementation Consideration		The Broker only needs to return an error message if the TEE is not
			reachable for some reason. Other errors are represented as response
			messages returned from the TEE which will then be passed to the TAM.
			6.2. TEEP Broker Implementation Consideration
	A Provider should consider methods of distribution, scope and		A Provider should consider methods of distribution, scope and
	concurrency on devices and runtime options when implementing an		concurrency on devices and runtime options when implementing a TEEP
	agent. Several non-exhaustive options are discussed below.		Broker. Several non-exhaustive options are discussed below.
	Providers are encouraged to take advantage of the latest		Providers are encouraged to take advantage of the latest
	communication and platform capabilities to offer the best user		communication and platform capabilities to offer the best user
	experience.		experience.
	6.2.1. Agent Distribution		6.2.1. TEEP Broker Distribution
	The agent installation is commonly carried out at OEM time. A user
	can dynamically download and install an agent on-demand.
	It is important to ensure a legitimate agent is installed and used.
	If an agent is compromised it may drop messages and thereby introduce
	a denial of service.
	6.2.2. Number of Agents		The Broker installation is commonly carried out at OEM time. A user
			can dynamically download and install a Broker on-demand.
	We anticipate only one shared agent instance in a device. The		6.2.2. Number of TEEP Brokers
	device's TEE vendor will most probably supply one agent.
	With one shared agent, the agent provider is responsible to allow		There should be generally only one shared TEEP Broker in a device.
	multiple TAMs and TEE providers to achieve interoperability. With a		The device's TEE vendor will most probably supply one Broker. When
	standard agent interface, each TAM can implement its own SDK for its		multiple TEEs are present in a device, one TEEP Broker per TEE may be
	SP Client Applications to work with this agent.		used.
	Multiple independent agent providers can be used as long as they have		When only one Broker is used per device, the Broker provider is
	standard interface to a Client Application or TAM SDK. Only one		responsible to allow multiple TAMs and TEE providers to achieve
	agent is expected in a device.		interoperability. With a standard Broker interface, each TAM can
			implement its own SDK for its SP Client Applications to work with
			this Broker.
	TAM providers are generally expected to provide an SDK for SP		Multiple independent Broker providers can be used as long as they
	applications to interact with an agent for the TAM and TEE		have standard interface to a Client Application or TAM SDK. Only one
	interaction.		Broker is generally expected in a device.
	7. Attestation		7. Attestation
	Attestation is the process through which one entity (an attestor)		Attestation is the process through which one entity (an attestor)
	presents a series of claims to another entity (a verifier), and		presents a series of claims to another entity (a verifier), and
	provides sufficient proof that the claims are true. Different		provides sufficient proof that the claims are true. Different
	verifiers may have different standards for attestation proofs and not		verifiers may have different standards for attestation proofs and not
	all attestations are acceptable to every verifier. TEEP attestations		all attestations are acceptable to every verifier. TEEP attestations
	are based upon the use of an asymmetric key pair under the control of		are based upon the use of an asymmetric key pair under the control of
	the TEE to create digital signatures across a well-defined claim set.		the TEE to create digital signatures across a well-defined claim set.
	In TEEP, the primary purpose of an attestation is to allow a device		In TEEP, the primary purpose of an attestation is to allow a device
	to prove to TAMs and SPs that a TEE in the device has particular		to prove to TAMs and SPs that a TEE in the device has particular
	properities, was built by a particular manufacturer, or is executing		properties, was built by a particular manufacturer, or is executing a
	a particular TA. Other claims are possible; this architecture		particular TA. Other claims are possible; this architecture
	specification does not limit the attestation claims, but defines a		specification does not limit the attestation claims, but defines a
	minimal set of claims required for TEEP to operate properly.		minimal set of claims required for TEEP to operate properly.
	Extensions to these claims are possible, but are not defined in the		Extensions to these claims are possible, but are not defined in the
	TEEP specifications. Other standards or groups may define the format		TEEP specifications. Other standards or groups may define the format
	and semantics of extended claims. The TEEP specification defines the		and semantics of extended claims. The TEEP specification defines the
	claims format such that these extended claims may be easily included		claims format such that these extended claims may be easily included
	in a TEEP attestation message.		in a TEEP attestation message.
	As of the writing of this specification, device and TEE attestations		As of the writing of this specification, device and TEE attestations
	have not been standardized across the market. Different devices,		have not been standardized across the market. Different devices,
	manufacturers, and TEEs support different attestation algorithms and		manufacturers, and TEEs support different attestation algorithms and
	mechanisms. In order for TEEP to be inclusive, the attestation		mechanisms. In order for TEEP to be inclusive, the attestation
	format shall allow for both proprietary attestation signatures, as		format shall allow for both proprietary attestation signatures, as
	well as a standardized form of attestation signature. Either form of		well as a standardized form of attestation signature. Either form of
	attesation signature may be applied to a set of TEEP claims, and both		attestation signature may be applied to a set of TEEP claims, and
	forms of attestation shall be considered conformant with TEEP.		both forms of attestation shall be considered conformant with TEEP.
	However, it should be recognized that not all TAMs or SPs may be able		However, it should be recognized that not all TAMs or SPs may be able
	to process all proprietary forms of attestations. All TAMs and SPs		to process all proprietary forms of attestations. All TAMs and SPs
	MUST be able to process the TEEP standard attestation format and		MUST be able to process the TEEP standard attestation format and
	attached signature.		attached signature.
	The attestation formats and mechanisms described and mandated by TEEP		The attestation formats and mechanisms described and mandated by TEEP
	shall convey a particular set of cryptographic properties based on		shall convey a particular set of cryptographic properties based on
	minimal assumptions. The cryptographic properties are conveyed by		minimal assumptions. The cryptographic properties are conveyed by
	the attestation; however the assumptions are not conveyed within the		the attestation; however the assumptions are not conveyed within the
	attestation itself.		attestation itself.
	skipping to change at page 30, line 21 ¶		skipping to change at page 28, line 33 ¶
	properties from the attestor to the verifier; in the case of TEEP,		properties from the attestor to the verifier; in the case of TEEP,
	the attestation must convey properties from the device to the TAM		the attestation must convey properties from the device to the TAM
	and/or SP. The properties required by TEEP include:		and/or SP. The properties required by TEEP include:
	- Non-repudiation, Unique Proof of Source - the cryptographic		- Non-repudiation, Unique Proof of Source - the cryptographic
	digital signature across the attestation, and optionally along		digital signature across the attestation, and optionally along
	with information in the attestion itself SHALL uniquely identify a		with information in the attestion itself SHALL uniquely identify a
	specific TEE in a specific device.		specific TEE in a specific device.
	- Integrity of claims - the cryptographic digital signature across		- Integrity of claims - the cryptographic digital signature across
	the attestation SHALL cover the entire attesation including all		the attestation SHALL cover the entire attestation including all
	meta data and all the claims in the attestation, ensuring that the		meta data and all the claims in the attestation, ensuring that the
	attestation has not be modified since the TEE signed the		attestation has not be modified since the TEE signed the
	attestation.		attestation.
	Standard public key algorithms such as RSA and ECDSA digital		Standard public key algorithms such as RSA and ECDSA digital
	signatures convey these properties. Group public key algorithms such		signatures convey these properties. Group public key algorithms such
	as EPID can also convey these properties, if the attestation includes		as EPID can also convey these properties, if the attestation includes
	a unique device identifier and an identifier for the TEE. Other		a unique device identifier and an identifier for the TEE. Other
	cryptographic operations used in other attestation schemes may also		cryptographic operations used in other attestation schemes may also
	convey these properties.		convey these properties.
	skipping to change at page 31, line 34 ¶		skipping to change at page 29, line 47 ¶
	|		|
	+------------+--(Contains)------+-----------------+--------------+		+------------+--(Contains)------+-----------------+--------------+
	| | | | |		| | | | |
	V V V V V		V V V V V
	+-------------+ +-------------+ +----------+ +-----------------+ +------------+		+-------------+ +-------------+ +----------+ +-----------------+ +------------+
	| Device | | TEE | | | | Action or | | Additional |		| Device | | TEE | | | | Action or | | Additional |
	| Identifying | | Identifying | | Liveness | | Operation | | or optional|		| Identifying | | Identifying | | Liveness | | Operation | | or optional|
	| Info | | Info | | Proof | | Specific claims | | Claims |		| Info | | Info | | Proof | | Specific claims | | Claims |
	+-------------+ +-------------+ +----------+ +-----------------+ +------------+		+-------------+ +-------------+ +----------+ +-----------------+ +------------+
	Figure 8: Structure of TEEP Attestation		Figure 7: Structure of TEEP Attestation
	The Attestation Header SHALL identify the "Attestation Type" and the		The Attestation Header SHALL identify the "Attestation Type" and the
	"Attestation Signature Type" along with an "Attestation Format		"Attestation Signature Type" along with an "Attestation Format
	Version Number." The "Attestation Type" identifies the minimal set		Version Number." The "Attestation Type" identifies the minimal set
	of claims that MUST be included in the attestation; this is an		of claims that MUST be included in the attestation; this is an
	identifier for a profile that defines the claims that should be		identifier for a profile that defines the claims that should be
	included in the attestation as part of the "Action or Operation		included in the attestation as part of the "Action or Operation
	Specific Claims." The "Attestation Signature Type" identifies the		Specific Claims." The "Attestation Signature Type" identifies the
	type of attestation signature that is attached. The type of		type of attestation signature that is attached. The type of
	attestation signature SHALL be one of the standard signatures types		attestation signature SHALL be one of the standard signatures types
	skipping to change at page 35, line 25 ¶		skipping to change at page 33, line 36 ¶
	A TA binary is signed by a TA signer certificate. This TA signing		A TA binary is signed by a TA signer certificate. This TA signing
	certificate/private key belongs to the SP, and may be self-signed		certificate/private key belongs to the SP, and may be self-signed
	(i.e., it need not participate in a trust hierarchy). It is the		(i.e., it need not participate in a trust hierarchy). It is the
	responsibility of the TAM to only allow verified TAs from trusted SPs		responsibility of the TAM to only allow verified TAs from trusted SPs
	into the system. Delivery of that TA to the TEE is then the		into the system. Delivery of that TA to the TEE is then the
	responsibility of the TEE, using the security mechanisms provided by		responsibility of the TEE, using the security mechanisms provided by
	the protocol.		the protocol.
	We allow a way for an (untrusted) application to check the		We allow a way for an (untrusted) application to check the
	trustworthiness of a TA. An agent has a function to allow an		trustworthiness of a TA. A TEEP Broker has a function to allow an
	application to query the information about a TA.		application to query the information about a TA.
	An application in the Rich O/S may perform verification of the TA by		An application in the Rich O/S may perform verification of the TA by
	verifying the signature of the TA. The GetTAInformation function is		verifying the signature of the TA. The GetTAInformation function is
	available to return the TEE supplied TA signer and TAM signer		available to return the TEE supplied TA signer and TAM signer
	information to the application. An application can do additional		information to the application. An application can do additional
	trust checks on the certificate returned for this TA. It might trust		trust checks on the certificate returned for this TA. It might trust
	the TAM, or require additional SP signer trust chaining.		the TAM, or require additional SP signer trust chaining.
	9.2. One TA Multiple SP Case		9.2. One TA Multiple SP Case
	A TA for multiple SPs must have a different identifier per SP. A TA		A TA for multiple SPs must have a different identifier per SP. They
	will be installed in a different SD for each respective SP.		should appear as different TAs when they are installed in the same
			device.
	9.3. Agent Trust Model		9.3. Broker Trust Model
	An agent could be malware in the vulnerable REE. A Client		A TEEP Broker could be malware in the vulnerable REE. A Client
	Application will connect its TAM provider for required TA		Application will connect its TAM provider for required TA
	installation. It gets command messages from the TAM, and passes the		installation. It gets command messages from the TAM, and passes the
	message to the agent.		message to the Broker.
	The architecture enables the TAM to communicate with the device's TEE		The architecture enables the TAM to communicate with the device's TEE
	to manage SDs and TAs. All TAM messages are signed and sensitive		to manage TAs. All TAM messages are signed and sensitive data is
	data is encrypted such that the agent cannot modify or capture		encrypted such that the TEEP Broker cannot modify or capture
	sensitive data.		sensitive data.
	9.4. Data Protection at TAM and TEE		9.4. Data Protection at TAM and TEE
	The TEE implementation provides protection of data on the device. It		The TEE implementation provides protection of data on the device. It
	is the responsibility of the TAM to protect data on its servers.		is the responsibility of the TAM to protect data on its servers.
	9.5. Compromised CA		9.5. Compromised CA
	A root CA for TAM certificates might get compromised. Some TEE trust		A root CA for TAM certificates might get compromised. Some TEE trust
	skipping to change at page 37, line 37 ¶		skipping to change at page 35, line 45 ¶
	12.2. Informative References		12.2. Informative References
	[GPTEE] Global Platform, "GlobalPlatform Device Technology: TEE		[GPTEE] Global Platform, "GlobalPlatform Device Technology: TEE
	System Architecture, v1.1", Global Platform GPD_SPE_009,		System Architecture, v1.1", Global Platform GPD_SPE_009,
	January 2017, <https://globalplatform.org/specs-library/		January 2017, <https://globalplatform.org/specs-library/
	tee-system-architecture-v1-1/>.		tee-system-architecture-v1-1/>.
	[I-D.ietf-teep-opentrustprotocol]		[I-D.ietf-teep-opentrustprotocol]
	Pei, M., Atyeo, A., Cook, N., Yoo, M., and H. Tschofenig,		Pei, M., Atyeo, A., Cook, N., Yoo, M., and H. Tschofenig,
	"The Open Trust Protocol (OTrP)", draft-ietf-teep-		"The Open Trust Protocol (OTrP)", draft-ietf-teep-
	opentrustprotocol-02 (work in progress), October 2018.		opentrustprotocol-03 (work in progress), May 2019.
	[RFC6024] Reddy, R. and C. Wallace, "Trust Anchor Management		[RFC6024] Reddy, R. and C. Wallace, "Trust Anchor Management
	Requirements", RFC 6024, DOI 10.17487/RFC6024, October		Requirements", RFC 6024, DOI 10.17487/RFC6024, October
	2010, <https://www.rfc-editor.org/info/rfc6024>.		2010, <https://www.rfc-editor.org/info/rfc6024>.
	[RFC7696] Housley, R., "Guidelines for Cryptographic Algorithm		[RFC7696] Housley, R., "Guidelines for Cryptographic Algorithm
	Agility and Selecting Mandatory-to-Implement Algorithms",		Agility and Selecting Mandatory-to-Implement Algorithms",
	BCP 201, RFC 7696, DOI 10.17487/RFC7696, November 2015,		BCP 201, RFC 7696, DOI 10.17487/RFC7696, November 2015,
	<https://www.rfc-editor.org/info/rfc7696>.		<https://www.rfc-editor.org/info/rfc7696>.
End of changes. 64 change blocks.
	266 lines changed or deleted		196 lines changed or added
This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/