Network Working Group D. Liu
Internet-Draft Alibaba Group
Intended status: Informational M. Pei
Expires: September 14, 2017 Symantec
H. Tschofenig
ARM Ltd.
Q. Fang
Alibaba Group
March 13, 2017

USe Cases and Problem Statement of Open Trust Protocol


This document discusses use cases of a open trust protocol.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

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

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 September 14, 2017.

Copyright Notice

Copyright (c) 2017 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 ( in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

Table of Contents

1. Introduction

Chips used on smart phones, tablets, and many consumer appliances today have built-in support for a so-called Trusted Execution Environment (TEE). The TEE is a security concept that separates normal operating systems, like Linux, from code that requires higher security protection, like security-related code. The underlying idea of this sandboxing approach is to have smaller code that is better reviewed and test and to provide it with more rights. They run on the so-called Secure World (in comparison to the Linux operating system that would run in the Normal World).

TEEs have been on the market for a while and have been successfully used for a number of applications, such as payment etc. However, the technology hasn't reached its full potential since ordinary developers who could make use of such functionality have a hard time getting access to it, and to write applications for it.

The industry has been working on an application layer security protocol that allows to configure security credentials and software running on a Trusted Execution Environment (TEE) for sometime. Today, TEEs are, for example, found home routers, set-top boxes, smart phones, tablets, wearables, etc. Unfortunately, there have been mostly proprietary protocols used in this environment.

This document discusses the use cases and features of open trust protocol.

2. Terminology

Open Trust Protocol
Client Application:
An application running on a rich OS, such as an Android, Windows, or iOS application, provided by a SP.

A physical piece of hardware that hosts symmetric key cryptographic modules

OTrP Agent:
An application running in the rich OS allowing communication with the TSM and the TEE.

Rich Application:
Alternative name of "Client Application". In this document we may use these two terms interchangably.

Rich Execution Environment (REE)
An environment that is provided and governed by a rich OS, potentially in conjunction with other supporting operating systems and hypervisors; it is outside of the TEE. This environment and applications running on it are considered un-trusted.

Secure Boot Module (SBM):
A firmware in a device that delivers secure boot functionality. It is also referred as Trusted Firmware (TFW) in this document.

Service Provider (SP):
An entity that wishes to supply Trusted Applications to remote devices. A Service Provider requires the help of a TSM in order to provision the Trusted Applications to the devices.

Trust Anchor:
A root certificate that a module trusts. It is usually embedded in one validating module, and used to validate the trust of a remote entity's certificate.

Trusted Application (TA):
Application that runs in TEE.

Trusted Execution Environment (TEE):
An execution environment that runs alongside but isolated from an REE. A TEE has security capabilities and meets certain security-related requirements: It protects TEE assets from general software attacks, defines rigid safeguards as to data and functions that a program can access, and resists a set of defined threats. There are multiple technologies that can be used to implement a TEE, and the level of security achieved varies accordingly.

Certificate Authority
Security Domain
Trusted Firmware
Trusted Service Manager

3. Scenario and Use Cases of OtrP

OTrP is an open interoperable protocol that allows TSM to manage security domains and TAs running in different Trusted Execution Environment (TEE) of various devices.

Figure 1: OTrP System Overview:

              ---OTrP Message Protocol--
              |                        |
              |                        |
 --------------------           ---------------   ----------
 |  REE   |  TEE    |           |    TSM      |   |  SP    |
 |  ---   |  ---    |           |    ---      |   |  --    |
 |        |         |           |             |   |        |
 | Client | SD (TAs)|           |   SD / TA   |   |  TA    |
 |  Apps  |         |           |     Mgmt    |   |        |
 |   |    |         |           |             |   |        |
 |   |    |         |           |             |   |        |
 | OTrP   | Trusted |           |  Trusted    |   |        |
 | Agent  |  CAs    |           | FW, TEE CAs |   |        |
 |        |         |           |             |   |        |
 |        |TEE Key/ |           |  TSM Key/   |   |SP Key/ |
 |        |  Cert   |           |    Cert     |   | Cert   |
 |        | FW Key/ |           |             |   |        |
 |        |  Cert   |           |             |   |        |
 ------------------             ---------------   ----------
              |                        |              |
              |                        |              |
                          |    CA      |

3.1. Use Case 1 - Payment

Payment technology (Especially mobile payments) is growing rapidly.

The TEE-based identity authentication application has a strong need for using OTrP. The types of TA involved mainly include the following two kinds:

3.2. Use Case 2 - IoT

In the field of Internet of Things, the purpose of TA is to use TEE to perform the functions of storing and managing sensitive data (eg, encryption keys) and performing sensitive operations (eg, authentication or encryption) in a secure environment in devices

In the smart home industry, a lot of security equipment are used TEE program to protect users of sensitive data, such as smart door locks. Some smart door locks even use biometrics, which makes this application in smart home very similar to the payment industry. Similarly, security products also need a secure and trusted remote update protocol to update the TA program in the device.

In the automotive (and bike) sharing industry, smart door locks use TEE technology to protect users' identity information. Operators who share automotive products need to remotely update trusted applications in smart locks.

Some high-value consumer electronics devices also have the need to use TEE and complete TA remote updates. For example, UAV (Unmanned Aerial Vehicle) devices use TEE to store sensitive operational instructions to prevent hackers from controlling the UAV's takeoff or landing by tampering with GPS location information. The manufacturer of the UAV needs to consider the easy management of the safety instructions in the UAV. For example, when the geographical location information of the prohibited flight area is changed, the equipment manufacturer should be able to update all the corresponding information stored in the device .

4. Use Case and Functional Requirements related to deployment scenario

4.1. Use Case 1 - Resource-constrained scenario

As mentioned earlier, in the shared automotive industry, smart door locks have the requirement to use OTrP. In this scenario, the update of TA in the smart door locks is facing with the problem of communication bandwidth limitation. Software and firmware updates often comprise quite a large amount of data. Therefore, it may overload the LPWAN which is typically used to transfer only small amounts of data. Binary encoding solution will be a better choice in the scenario of Low-power and Lossy Networks (LLNs), Low Power Personal Area Network (LPPAN)and Low Power Wide Area Network (LPWAN).

4.2. Use Case 2 - TA and SD management owned by OEM and SP

There are three configurations to manage TA and SD in TEE:

The first kind of configuration can give OEM greater management authority. It could be very convenient for the management of SD and TA.

The second configuration can give OEM a certain degree of control, TA can be easily issued to SD by SP. But at the same time, how to protect the security of TAM platform and TEE terminal should be considered.

The third configuration can reduce the security risk caused by the insecure TA program but it will also increase the complexity of deployment and maintenance.

4.3. Use Case 3 - Batch mode

Batch mode operation could be more efficient in some deployment scenario. For example, some OEM may want to provision TA into many devices they know with the same device key (for privacy and batch validation purpose). A TAM may issue one OTrP message to create SD and install the TA and send to many devices without requiring each device to submit their own device attestation. The batch support will reduce the load on the service side (TAM).

5. IANA Considerations

This memo includes no request to IANA.

6. Security Considerations


7. References

7.1. Normative References

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997.
[RFC7515] Jones, M., Bradley, J. and N. Sakimura, "JSON Web Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May 2015.
[RFC7516] Jones, M. and J. Hildebrand, "JSON Web Encryption (JWE)", RFC 7516, DOI 10.17487/RFC7516, May 2015.
[RFC7517] Jones, M., "JSON Web Key (JWK)", RFC 7517, DOI 10.17487/RFC7517, May 2015.
[RFC7518] Jones, M., "JSON Web Algorithms (JWA)", RFC 7518, DOI 10.17487/RFC7518, May 2015.

7.2. Informative References

, "
[draft-pei-opentrustprotocol]The Open Trust Protocol (OTrP)", January 2017.
[GPTEE] Global Platform, Global Platform, GlobalPlatform Device Technology: TEE System Architecture, v1.0", 2013.

Authors' Addresses

Dapeng Liu Alibaba Group Beijing, Beijing Phone: +86-1391788933 EMail:
Mingliang Pei Symantec Mountain View, CA, USA EMail:
Hannes Tschofenig ARM Ltd. 110 Fulbourn Rd Cambridge, CB1 9NJ, Great Britain EMail:
Qiang Fang Alibaba Group Beijing, Beijing Phone: +86-15210569677 EMail: