[Docs] [txt|pdf|xml] [Tracker] [Email] [Nits]



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
               draft-liu-opentrustprotocol-usecase-00.txt

Abstract

   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 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 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
   (http://trustee.ietf.org/license-info) 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




Liu, et al.            Expires September 14, 2017               [Page 1]


Internet-Draft              opentrustprotocol                 March 2017


   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Scenario and Use Cases of OtrP  . . . . . . . . . . . . . . .   4
     3.1.  Use Case 1 - Payment  . . . . . . . . . . . . . . . . . .   6
     3.2.  Use Case 2 - IoT  . . . . . . . . . . . . . . . . . . . .   7
   4.  Use Case and Functional Requirements related to deployment
       scenario  . . . . . . . . . . . . . . . . . . . . . . . . . .   8
     4.1.  Use Case 1 - Resource-constrained scenario  . . . . . . .   8
     4.2.  Use Case 2 - TA and SD management owned by OEM and SP . .   8
     4.3.  Use Case 3 - Batch mode . . . . . . . . . . . . . . . . .   9
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   9
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .   9
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   9
     7.1.  Normative References  . . . . . . . . . . . . . . . . . .   9
     7.2.  Informative References  . . . . . . . . . . . . . . . . .  10
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  10

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.





Liu, et al.            Expires September 14, 2017               [Page 2]


Internet-Draft              opentrustprotocol                 March 2017


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

2.  Terminology

   OTrP:  Open Trust Protocol

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



   Device:  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.






Liu, et al.            Expires September 14, 2017               [Page 3]


Internet-Draft              opentrustprotocol                 March 2017


   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.



   CA: Certificate Authority

   SD: Security Domain

   TFW:  Trusted Firmware

   TSM:  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:















Liu, et al.            Expires September 14, 2017               [Page 4]


Internet-Draft              opentrustprotocol                 March 2017


                 ---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      |
                             --------------

   o  The use of open environments: In general, some new kind device
      will be equipped with open environment to provide the operating
      system.  This has the advantage that users can add applications at
      any time, and there is little need to worry about their impact on
      the stability and security of the device.  However, the open
      environment makes the device face more and more foreign attacks.
      Device manufacturers want to take advantage of this operating
      system, but need to effectively control the behavior of the
      software running on the device.

   o  Verification: The traditional user authentication method requires
      a username and password.  At present, this approach is
      increasingly considered safe, after all, consumers will use a less
      confidential password or re-use the existing password, and hackers
      are increasingly able to invade the consumer's account.  Because
      an application or service provider typically stores personal
      verification and sensitive information on its own server, such
      hacking is the headline of the news, causing consumers to fear and
      shaken business confidence.  Therefore, there is a need for a more
      sophisticated validation mechanism to ensure that the openers of



Liu, et al.            Expires September 14, 2017               [Page 5]


Internet-Draft              opentrustprotocol                 March 2017


      the application enjoy the necessary flexibility while protecting
      the consumer.

   o  Privacy: The device stores more and more personal information
      (such as contact information, photos, photos and video clips), and
      even sensitive data (including credentials, passwords, medical
      data, etc.).  In order to prevent this information from being
      exposed to loss, theft, malware or other negative events, we need
      adequate security to store, process and distribute such personal
      data.

   o  Content protection: Today, more and more devices with high-
      definition (HD) video playback and video streaming, mobile TV
      playback and host 3D games and other functions.  They can even
      become content gateway devices, and to replace the traditional
      set-top boxes or game consoles.  In this case, the playback
      function of the device becomes less important, and the security
      requirements are more and more prominent.  Therefore, not only to
      protect the mobile device on the full HD or ultra-high-definition
      content, but also to protect the device to send the content to the
      TV through the channel.

   o  Enterprise Data Access: Enterprise IT professionals often exercise
      caution when opening access to their internal network, fearing
      that the device will carry malware, the device will be stolen, or
      when used outside the company, there will be attacks from the
      internal network The As a result, IT departments often establish
      green lists and red lists of equipment based on the security
      performance of the device.  They are also concerned about the
      characteristics of these devices always open and the
      implementation of password protection and device lockout functions
      in shutdown mode.

   o  Financial risk: Financial transactions through networking devices,
      especially mobile devices, are becoming increasingly common.
      These transactions include booking, remote payments, near-field
      payments and financial electronic transactions.  Moreover, the use
      of mobile devices in the retail outlets shopping has become
      increasingly common.  Moreover, mobile devices become a point-of-
      sale terminal, especially mobile point of sale, and this use case
      is now growing.

3.1.  Use Case 1 - Payment

   Payment technology (Especially mobile payments) is growing rapidly.






Liu, et al.            Expires September 14, 2017               [Page 6]


Internet-Draft              opentrustprotocol                 March 2017


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

   o  Identification: Personal identification password and biometric.
      Because TEE can provides larger amount of memory and data
      transfer, TEE can store a trusted application that is used to
      complete a personal password acquisition or biological
      identification.  For the development of the relevant TA of SP, the
      use of OTrP can easily send the latest trusted application to the
      device.  At the same time, because TA and REE applications are
      independent of each other, REE side of the corresponding
      application only need to make little changes because of the OTrP.

   o  Security interface: Mobile payment is inseparable from the
      security interaction between end users and consumer devices.  For
      example, the user needs to confirm the sensitive information
      displayed on the screen and enter the sensitive information (such
      as a password) through the keyboard.  A TA such as keyboard in tee
      is needed.  When designing a keyboard in tee, you should consider
      how to make a timely update when an application has a
      vulnerability to ensure that user sensitive data is not
      compromised.In this case, it is necessary to use OTrP

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



Liu, et al.            Expires September 14, 2017               [Page 7]


Internet-Draft              opentrustprotocol                 March 2017


   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:

   o  The OEM wants to ensure that no service provider can talk to the
      TEE without the OEM's prior approval.  Once approved, the Service
      Provider is allowed to create security domains and install trusted
      apps.  The OEM doesn't require to be involved in that process.

   o  The OEM wants to ensure that no service provider can talk to the
      TEE without the OEM's prior approval.  Once approved, the Service
      Provider is allowed to perform lifecycle management of trusted
      apps within a particular security domain but cannot create any new
      security domains without the OEM's involvement.

   o  The OEM and Service provider both want to be involved in every
      transaction with TEE and only when they both agree the TEE can
      accept the OTrP message and perform actions.

   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.




Liu, et al.            Expires September 14, 2017               [Page 8]


Internet-Draft              opentrustprotocol                 March 2017


   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

   TBD.

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,
              <http://www.rfc-editor.org/info/rfc2119>.

   [RFC7515]  Jones, M., Bradley, J., and N. Sakimura, "JSON Web
              Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May
              2015, <http://www.rfc-editor.org/info/rfc7515>.

   [RFC7516]  Jones, M. and J. Hildebrand, "JSON Web Encryption (JWE)",
              RFC 7516, DOI 10.17487/RFC7516, May 2015,
              <http://www.rfc-editor.org/info/rfc7516>.

   [RFC7517]  Jones, M., "JSON Web Key (JWK)", RFC 7517,
              DOI 10.17487/RFC7517, May 2015,
              <http://www.rfc-editor.org/info/rfc7517>.

   [RFC7518]  Jones, M., "JSON Web Algorithms (JWA)", RFC 7518,
              DOI 10.17487/RFC7518, May 2015,
              <http://www.rfc-editor.org/info/rfc7518>.





Liu, et al.            Expires September 14, 2017               [Page 9]


Internet-Draft              opentrustprotocol                 March 2017


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: maxpassion@gmail.com


   Mingliang Pei
   Symantec
   Mountain View, CA
   USA

   Email: mpei@yahoo.com


   Hannes Tschofenig
   ARM Ltd.
   110 Fulbourn Rd Cambridge, CB1  9NJ
   Great Britain

   Email: Hannes.tschofenig@arm.com


   Qiang Fang
   Alibaba Group
   Beijing
   Beijing

   Phone: +86-15210569677
   Email: qiangwu.fq@alibaba-inc.com









Liu, et al.            Expires September 14, 2017              [Page 10]


Html markup produced by rfcmarkup 1.124, available from https://tools.ietf.org/tools/rfcmarkup/