--- 1/draft-ietf-teep-architecture-04.txt 2019-12-12 18:13:14.103075334 -0800 +++ 2/draft-ietf-teep-architecture-05.txt 2019-12-12 18:13:14.163076867 -0800 @@ -1,25 +1,23 @@ TEEP M. Pei Internet-Draft Symantec Intended status: Informational H. Tschofenig -Expires: June 8, 2020 Arm Limited +Expires: June 14, 2020 Arm Limited + D. Thaler + Microsoft D. Wheeler Intel - A. Atyeo - Intercede - L. Dapeng - Alibaba Group - December 06, 2019 + December 12, 2019 Trusted Execution Environment Provisioning (TEEP) Architecture - draft-ietf-teep-architecture-04 + draft-ietf-teep-architecture-05 Abstract A Trusted Execution Environment (TEE) is an environment that enforces that only authorized code can execute with that environment, and that any data used by such code cannot be read or tampered with by any code outside that environment. This architecture document motivates the design and standardization of a protocol for managing the lifecycle of trusted applications running inside a TEE. @@ -31,21 +29,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on June 8, 2020. + This Internet-Draft will expire on June 14, 2020. Copyright Notice Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -68,56 +66,56 @@ than English. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.1. Payment . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.2. Authentication . . . . . . . . . . . . . . . . . . . . . 7 3.3. Internet of Things . . . . . . . . . . . . . . . . . . . 7 - 3.4. Confidential Cloud Computing . . . . . . . . . . . . . . 8 + 3.4. Confidential Cloud Computing . . . . . . . . . . . . . . 7 4. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 8 4.1. System Components . . . . . . . . . . . . . . . . . . . . 8 4.2. Different Renditions of TEEP Architecture . . . . . . . . 10 4.3. Multiple TAMs and Relationship to TAs . . . . . . . . . . 12 4.4. Untrusted Apps, Trusted Apps, and Personalization Data . 13 4.5. Examples of Application Delivery Mechanisms in Existing TEEs . . . . . . . . . . . . . . . . . . . . . . . . . . 14 4.6. Entity Relations . . . . . . . . . . . . . . . . . . . . 15 5. Keys and Certificate Types . . . . . . . . . . . . . . . . . 17 5.1. Trust Anchors in TEE . . . . . . . . . . . . . . . . . . 18 - 5.2. Trust Anchors in TAM . . . . . . . . . . . . . . . . . . 18 - 5.3. Scalability . . . . . . . . . . . . . . . . . . . . . . . 18 + 5.2. Trust Anchors in TAM . . . . . . . . . . . . . . . . . . 19 + 5.3. Scalability . . . . . . . . . . . . . . . . . . . . . . . 19 5.4. Message Security . . . . . . . . . . . . . . . . . . . . 19 6. TEEP Broker . . . . . . . . . . . . . . . . . . . . . . . . . 19 6.1. Role of the TEEP Broker . . . . . . . . . . . . . . . . . 20 6.2. TEEP Broker Implementation Consideration . . . . . . . . 20 6.2.1. TEEP Broker APIs . . . . . . . . . . . . . . . . . . 20 6.2.2. TEEP Broker Distribution . . . . . . . . . . . . . . 21 6.2.3. Number of TEEP Brokers . . . . . . . . . . . . . . . 21 - 7. Attestation . . . . . . . . . . . . . . . . . . . . . . . . . 21 + 7. Attestation . . . . . . . . . . . . . . . . . . . . . . . . . 22 7.1. Information Required in TEEP Claims . . . . . . . . . . . 23 8. Algorithm and Attestation Agility . . . . . . . . . . . . . . 24 - 9. Security Considerations . . . . . . . . . . . . . . . . . . . 24 - 9.1. TA Trust Check at TEE . . . . . . . . . . . . . . . . . . 24 + 9. Security Considerations . . . . . . . . . . . . . . . . . . . 25 + 9.1. TA Trust Check at TEE . . . . . . . . . . . . . . . . . . 25 9.2. One TA Multiple SP Case . . . . . . . . . . . . . . . . . 25 9.3. Broker Trust Model . . . . . . . . . . . . . . . . . . . 25 9.4. Data Protection at TAM and TEE . . . . . . . . . . . . . 25 - 9.5. Compromised CA . . . . . . . . . . . . . . . . . . . . . 25 - 9.6. Compromised TAM . . . . . . . . . . . . . . . . . . . . . 25 + 9.5. Compromised CA . . . . . . . . . . . . . . . . . . . . . 26 + 9.6. Compromised TAM . . . . . . . . . . . . . . . . . . . . . 26 9.7. Certificate Renewal . . . . . . . . . . . . . . . . . . . 26 9.8. Keeping Secrets from the TAM . . . . . . . . . . . . . . 26 - 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 - 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 26 - 12. Informative References . . . . . . . . . . . . . . . . . . . 26 - Appendix A. History . . . . . . . . . . . . . . . . . . . . . . 28 + 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 + 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 27 + 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 27 + 13. Informative References . . . . . . . . . . . . . . . . . . . 27 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28 1. Introduction Applications executing in a device are exposed to many different attacks intended to compromise the execution of the application, or reveal the data upon which those applications are operating. These attacks increase with the number of other applications on the device, with such other applications coming from potentially untrustworthy sources. The potential for attacks further increase with the @@ -138,24 +136,23 @@ This separation reduces the possibility of a successful attack on application components and the data contained inside the TEE. Typically, application components are chosen to execute inside a TEE because those application components perform security sensitive operations or operate on sensitive data. An application component running inside a TEE is referred to as a Trusted Application (TA), while an application running outside any TEE is referred to as an Untrusted Application (UA). - The TEE typically uses hardware to enforce protections on the TA and - its data, but also presents a more limited set of services to - applications inside the TEE than is normally available to Untrusted - Applications. + TEEs use hardware enforcement combined with software protection to + secure TAs and its data. TEEs typically offer a more limited set of + services to TAs than is normally available to Untrusted Applications. But not all TEEs are the same, and different vendors may have different implementations of TEEs with different security properties, different features, and different control mechanisms to operate on TAs. Some vendors may themselves market multiple different TEEs with different properties attuned to different markets. A device vendor may integrate one or more TEEs into their devices depending on market needs. To simplify the life of developers and service providers interacting @@ -166,50 +163,52 @@ devices, and their TEEs. This trusted third party is the Trusted Application Manager (TAM). The Trusted Execution Provisioning (TEEP) protocol addresses the following problems: - A Service Provider (SP) intending to provide services through a TA to users of a device needs to determine security-relevant information of a device before provisioning their TA to the TEE within the device. An example is the verification of the type of - TEE included in a device. + TEE included in a device and that it is capable of providing the + security protections required by a particular TA. - 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 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 - TEE is genuine and capable of providing the security protections - required by a particular TA. - - 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 TA in the TEE. - 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 the TA in the TEE. - 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 are being revoked from a particular user (or device). For example, if a subscription or contract for a particular service has expired, or a payment by the user has not been completed or has been rescinded. - A Service Provider (SP) must be able to define the relationship between cooperating TAs under the SP's control, and specify whether the TAs can communicate, share data, and/or share key material. + Note: The Service Provider requires the help of a TAM to provision + the Trusted Applications to remote devices and the TEEP protocol + exchanges messages between a Trusted Application Manager (TAM) and a + TEEP Agent via a TEEP Broker. + 2. Terminology The following terms are used: - Untrusted Application: An application running in a Rich Execution Environment, such as an Android, Windows, or iOS application. - Trusted Application Manager (TAM): An entity that manages Trusted Applications (TAs) running in different TEEs of various devices. @@ -225,22 +224,21 @@ Anchor to be removed or disabled. - Rich Execution Environment (REE): An environment that is provided and governed by a typical OS (e.g., Linux, Windows, Android, iOS), potentially in conjunction with other supporting operating systems and hypervisors; it is outside of any TEE. This environment and applications running on it are considered untrusted. - Service Provider (SP): An entity that wishes to provide a service on Devices that requires the use of one or more Trusted - Applications. A Service Provider requires the help of a TAM in - order to provision the Trusted Applications to remote devices. + Applications. - Device User: A human being that uses a device. Many devices have a single device user. Some devices have a primary device user with other human beings as secondary device users (e.g., parent allowing children to use their tablet or laptop). Other devices are not used by a human being and hence have no device user. Relates to Device Owner and Device Administrator. - Device Owner: A device is always owned by someone. In some cases, it is common for the (primary) device user to also own the device, @@ -297,47 +295,43 @@ 3.1. Payment A payment application in a mobile device requires high security and trust about the hosting device. Payments initiated from a mobile device can use a Trusted Application to provide strong identification and proof of transaction. For a mobile payment application, some biometric identification information could also be stored in a TEE. The mobile payment - application can use such information for authentication. + application can use such information for unlocking the phone and for + local identification of the user. - A secure user interface (UI) may be used in a mobile device to + A trusted user interface (UI) may be used in a mobile device to prevent malicious software from stealing sensitive user input data. - Such an application implementation often relies on a TEE for user - input protection. + Such an implementation often relies on a TEE for providing access to + peripherals, such as PIN input. 3.2. Authentication - For better security of authentication, a device may store its - sensitive authentication keys inside a TEE, providing TEE-protected - security key strength and trusted code execution. + For better security of authentication, a device may store its keys + and cryptographic libraries inside a TEE limiting access to + cryptographic functions via a well-defined interface and thereby + reducing access to keying material. 3.3. Internet of Things - The Internet of Things (IoT) has been posing threats to networks and - national infrastructures because of existing weak security in - devices. It is very desirable that IoT devices can prevent malware - from manipulating actuators (e.g., unlocking a door), or stealing or - modifying sensitive data such as authentication credentials in the - device. A TEE can be the best way to implement such IoT security - functions. - - TEEs could be used to store variety of sensitive data for IoT - devices. For example, a TEE could be used in smart door locks to - store a user's biometric information for identification, and for - protecting access the locking mechanism. + The Internet of Things (IoT) has been posing threats to critical + infrastructure because of weak security in devices. It is desirable + that IoT devices can prevent malware from manipulating actuators + (e.g., unlocking a door), or stealing or modifying sensitive data, + such as authentication credentials in the device. A TEE can be the + best way to implement such IoT security functions. 3.4. Confidential Cloud Computing A tenant can store sensitive data in a TEE in a cloud computing server such that only the tenant can access the data, preventing the cloud hosting provider from accessing the data. A tenant can run TAs inside a server TEE for secure operation and enhanced data security. This provides benefits not only to tenants with better data security but also to cloud hosting provider for reduced liability and increased cloud adoption. @@ -383,22 +377,22 @@ performing lifecycle management activity on TA's on behalf of Service Providers and Device Administrators. This includes creation and deletion of TA's, and may include, for example, over- the-air updates to keep an SP's TAs up-to-date and clean up when a version should be removed. TAMs may provide services that make it easier for SPs or DAs to use the TAM's service to manage multiple devices, although that is not required of a TAM. The TAM performs its management of TA's through an interaction with a Device's TEEP Broker. As shown in Figure 1, the TAM cannot - directly contact a Device, but must wait for the TEEP Broker to - contact the TAM requesting a particular service. This + directly contact a TEEP Agent, but must wait for the TEEP Broker + to contact the TAM requesting a particular service. This architecture is intentional in order to accommodate network and application firewalls that normally protect user and enterprise devices from arbitrary connections from external network entities. 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. It is expected that manufacturers and carriers will run their own private TAM. Another example of a private TAM is a TAM running as a Software-as-a-Service (SaaS) within an SP. @@ -453,24 +447,24 @@ There is nothing prohibiting a device from implementing multiple TEEs. In addition, some TEEs (for example, SGX) present themselves as separate containers within memory without a controlling manager within the TEE. In these cases, the Rich Execution Environment hosts multiple TEEP brokers, where each Broker manages a particular TEE or set of TEEs. Enumeration and access to the appropriate TEEP Broker is up to the Rich Execution Environment and the Untrusted Applications. Verification that the correct TA has been reached then becomes a matter of properly verifying TA attestations, which are - unforgeable. The multiple TEE approach is shown in the diagram - below. For brevity, TEEP Broker 2 is shown interacting with only one - TAM and UA, but no such limitation is intended to be implied in the - architecture. + unforgeable. The multiple TEEP Broker approach is shown in the + diagram below. For brevity, TEEP Broker 2 is shown interacting with + only one TAM and UA, but no such limitation is intended to be implied + in the architecture. +-------------------------------------------+ | Device | | +--------+ | Service Provider | | |----------+ | | +-------------+ | TEEP |---------+| | | | TEE-1 | +---| Broker | | || +--------+ | | | | | | 1 |<---+ | |+-->| |<-+ | | +-------+ | | | | | | | | | | | | TEEP | | | | | | | | | | @@ -605,26 +599,26 @@ uses one or more TA's in a TEE appears no different from any other Untrusted Application in the REE. However, the way the Untrusted Application and its corresponding TA's are packaged, delivered, and installed on the device can vary. The variations depend on whether the Untrusted Application and TA are bundled together or are provided separately, and this has implications to the management of the TAs in the TEE. In addition to the Untrusted Application and TA, the TA and/or TEE may require some additional data to personalize the TA to the service provider or the device or a user. This personalization data is dependent on the TEE, the TA and the SP; an example of - personalization data might be username and password of an account - with the SP, or a secret symmetric key used by the TA to communicate - with the SP. The personalization data must be encrypted to preserve - the confidentiality of potentially sensitive data contained within - it. Other than this requirement to support confidentiality, TEEP - place no limitations or requirements on the personalization data. + personalization data might be a secret symmetric key used by the TA + to communicate with the SP. The personalization data must be + encrypted to preserve the confidentiality of potentially sensitive + data contained within it. Other than this requirement to support + confidentiality, TEEP place no limitations or requirements on the + personalization data. There are three possible cases for bundling of the Untrusted Application, TA, and personalization data: 1. The Untrusted Application, TA, and personalization data are all bundled together in a single package by the SP and provided to the TEEP Broker through the TAM. 2. The Untrusted Application and the TA are bundled together in a single package, which a TAM or a publicly accessible app store @@ -679,26 +673,26 @@ otherwise there is a significant problem in getting the SGX enclave code (the TA) from the TEE, through the installer and into the Untrusted Application in a trusted fashion. Finally, the personalization data would need to be sent out of the TEE (encrypted in an SGX encalve-to-enclave manner) to the REE's installation app, which would pass this data to the installed Untrusted Application, which would in turn send this data to the SGX enclave (TA). This complexity is due to the fact that each SGX enclave is separate and does not have direct communication to other SGX enclaves. - In ARM TrustZone based environments, the Untrusted Application and TA - may or may not be bundled together. This differs from SGX since in - TrustZone the TA lifetime is not inherently tied to a specific - Untrused Application process lifetime as occurs in SGX. A TA is - loaded by a trusted OS running in the TEE, where the trusted OS is - separate from the OS in the REE. Thus Cases 2 and 3 are equally + In Arm TrustZone for A- and R-class devices, the Untrusted + Application and TA may or may not be bundled together. This differs + from SGX since in TrustZone the TA lifetime is not inherently tied to + a specific Untrused Application process lifetime as occurs in SGX. A + TA is loaded by a trusted OS running in the TEE, where the trusted OS + is separate from the OS in the REE. Thus Cases 2 and 3 are equally applicable. In addition, it is possible for TAs to communicate with each other without involving the Untrusted Application, and so the complexity of Case 1 is lower than in the SGX example, and so Case 1 is possible as well though still more complex than Cases 2 and 3. 4.6. Entity Relations This architecture leverages asymmetric cryptography to authenticate a 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 be @@ -721,20 +715,26 @@ Untrusted Application TA | | Untrusted Application -- 2a. --> | ----- 3. Install -------> | TA ----------------- 2b. Supply ------> | 4. Messaging-->| | | | | Figure 3: Developer Experience + Note that Figure 3 shows the app developer as a TA signer and not the + SP. However, the App Developer is either closely associated with the + SP or the SP delegates the signing authority to the app developer. + For the purpose of this document there is no difference between the + SP and the app developer. + Figure 3 shows an application developer building two applications: 1) an Untrusted Application; 2) a TA that provides some security functions to be run inside a TEE. At step 2, the application developer uploads the Untrusted Application (2a) to an Application Store. The Untrusted Application may optionally bundle the TA binary. Meanwhile, the application developer may provide its TA to a TAM provider that will be managing the TA in various devices. 3. A user will go to an Application Store to download the Untrusted Application. The Untrusted Application will trigger TA installation by initiating communication with a TAM. This is the step 4. The @@ -759,22 +759,21 @@ with different TAMs and different TEEs in different devices. This is the role of the Broker, which is a software component that bridges communication between a TAM and a TEE. Furthermore the Broker communicates with a Agent inside a TEE that is responsible to process TAM requests. The Broker in REE does not need to know the actual content of messages except for the TEE routing information. 5. Keys and Certificate Types This architecture leverages the following credentials, which allow - delivering end-to-end security between a TAM and a TEEP Agent, - without relying on any transport security. + delivering end-to-end security between a TAM and a TEEP Agent. Figure 4 summarizes the relationships between various keys and where they are stored. Each public/private key identifies an SP, TAM, or TEE, and gets a certificate that chains up to some CA. A list of trusted certificates is then used to check a presented certificate against. Different CAs can be used for different types of certificates. TEEP messages are always signed, where the signer key is the message originator's private key such as that of a TAM, or a TEE's private @@ -787,20 +786,24 @@ Purpose Private Key Signs CA Certs ------------------ ----------- ------------- ------------- Authenticating TEE 1 per TEE TEEP responses TAM Authenticating TAM 1 per TAM TEEP requests TEEP Agent Code Signing 1 per SP TA binary TEE Figure 4: Keys + Note that personalization data is not included in the table above. + The use of personalization data is dependent on how TAs are used and + what their security requirements are. + The TEE key pair and certificate are used for authenticating the TEE to a remote TAM. Often, the key pair is burned into the TEE by the TEE manufacturer and the key pair and its certificate are valid for the expected lifetime of the TEE. A TAM provider is responsible for configuring its TAM with the manufacturer certificates or CAs that are used to sign TEE keys. The TAM key pair and certificate are used for authenticating a TAM to a remote TEE. A TAM provider is responsible for acquiring a certificate from a CA that is trusted by the TEEs it manages. @@ -1057,28 +1060,29 @@ Some TAMs may require additional claims in order to properly authorize a device or TEE. These additional claims may help clear up any assumptions for which the TAM wants to alleviate. The specific format for these additional claims are outside the scope of this specification, but the TEEP protocol allows these additional claims to be included in the attestation messages. 7.1. Information Required in TEEP Claims - - Device Identifying Info: TEEP attestations must uniquely identify - a device to the TAM and SP. This identifier allows the TAM to - provide services unique to the device, such as managing installed - TAs, and providing subscriptions to services, and locating device- - specific keying material to communicate with or authenticate the - device. Additionally, device manufacturer information must be - provided to provide better universal uniqueness qualities without - requiring globally unique identifiers for all devices. + - Device Identifying Info: TEEP attestations may need to uniquely + identify a device to the TAM and SP. Unique device identification + allows the TAM to provide services to the device, such as managing + installed TAs, and providing subscriptions to services, and + locating device-specific keying material to communicate with or + authenticate the device. In some use cases it may be sufficient + to identify only the class of the device. The security and + privacy requirements regarding device identification will vary + with the type of TA provisioned to the TEE. - TEE Identifying info: The type of TEE that generated this attestation must be identified. Standard TEE types are identified by an IANA number, but also must include version identification information such as the hardware, firmware, and software version of the TEE, as applicable by the TEE type. TEE manufacturer information for the TEE is required in order to disambiguate the same TEE type created by different manufacturers and resolve potential assumptions around manufacturer provisioning, keying and support for the TEE. @@ -1199,85 +1203,81 @@ dependency in the manifest of the encrypted TA. Thus, the TEEP Agent would look at the TA manifest, determine there is a dependency with a TAM URI of the SP's TAM. The Agent would then install the dependency, and then continue with the TA installation steps, including decrypting the TA binary with the relevant key. 10. IANA Considerations This document does not require actions by IANA. -11. Acknowledgements +11. Contributors - Some content of this document is based on text in a previous OTrP - protocol document [I-D.ietf-teep-opentrustprotocol]. We thank the - former co-authors Nick Cook and Minho Yoo for the initial document - content, and contributors Brian Witten, Tyler Kim, and Alin Mutu. + - Andrew Atyeo -12. Informative References + - Intercede + + - andrew.atyeo@intercede.com + + - Liu Dapeng + + - Alibaba Group + + - maxpassion@gmail.com + +12. Acknowledgements + + We would like to thank Nick Cook, Minho Yoo, Brian Witten, Tyler Kim, + Alin Mutu, Juergen Schoenwaelder, Nicolae Paladi, Sorin Faibish, Ned + Smith, Russ Housley, Jeremy O'Donoghue, and Anders Rundgren for their + feedback. + +13. Informative References [GPTEE] Global Platform, "GlobalPlatform Device Technology: TEE System Architecture, v1.1", Global Platform GPD_SPE_009, January 2017, . [I-D.ietf-suit-manifest] Moran, B., Tschofenig, H., and H. Birkholz, "A Concise Binary Object Representation (CBOR)-based Serialization Format for the Software Updates for Internet of Things (SUIT) Manifest", draft-ietf-suit-manifest-02 (work in progress), November 2019. - [I-D.ietf-teep-opentrustprotocol] - Pei, M., Atyeo, A., Cook, N., Yoo, M., and H. Tschofenig, - "The Open Trust Protocol (OTrP)", draft-ietf-teep- - opentrustprotocol-03 (work in progress), May 2019. - [I-D.ietf-teep-otrp-over-http] Thaler, D., "HTTP Transport for Trusted Execution Environment Provisioning: Agent-to- TAM Communication", draft-ietf-teep-otrp-over-http-03 (work in progress), November 2019. [RFC6024] Reddy, R. and C. Wallace, "Trust Anchor Management Requirements", RFC 6024, DOI 10.17487/RFC6024, October 2010, . [RFC7696] Housley, R., "Guidelines for Cryptographic Algorithm Agility and Selecting Mandatory-to-Implement Algorithms", BCP 201, RFC 7696, DOI 10.17487/RFC7696, November 2015, . -Appendix A. History - - RFC EDITOR: PLEASE REMOVE THIS SECTION - - IETF Drafts - - draft-00: - Initial working group document - Authors' Addresses Mingliang Pei Symantec EMail: mingliang_pei@symantec.com Hannes Tschofenig Arm Limited EMail: hannes.tschofenig@arm.com + Dave Thaler + Microsoft + + EMail: dthaler@microsoft.com + David Wheeler Intel EMail: david.m.wheeler@intel.com - - Andrew Atyeo - Intercede - - EMail: andrew.atyeo@intercede.com - - Liu Dapeng - Alibaba Group - - EMail: maxpassion@gmail.com