idnits 2.17.1 draft-liu-opentrustprotocol-usecase-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 13, 2017) is 2600 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2119' is defined on line 376, but no explicit reference was found in the text == Unused Reference: 'RFC7515' is defined on line 381, but no explicit reference was found in the text == Unused Reference: 'RFC7516' is defined on line 385, but no explicit reference was found in the text == Unused Reference: 'RFC7517' is defined on line 389, but no explicit reference was found in the text == Unused Reference: 'RFC7518' is defined on line 393, but no explicit reference was found in the text == Unused Reference: 'GPTEE' is defined on line 402, but no explicit reference was found in the text Summary: 0 errors (**), 0 flaws (~~), 7 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group D. Liu 3 Internet-Draft Alibaba Group 4 Intended status: Informational M. Pei 5 Expires: September 14, 2017 Symantec 6 H. Tschofenig 7 ARM Ltd. 8 Q. Fang 9 Alibaba Group 10 March 13, 2017 12 USe Cases and Problem Statement of Open Trust Protocol 13 draft-liu-opentrustprotocol-usecase-00.txt 15 Abstract 17 This document discusses use cases of a open trust protocol. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on September 14, 2017. 36 Copyright Notice 38 Copyright (c) 2017 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 3. Scenario and Use Cases of OtrP . . . . . . . . . . . . . . . 4 56 3.1. Use Case 1 - Payment . . . . . . . . . . . . . . . . . . 6 57 3.2. Use Case 2 - IoT . . . . . . . . . . . . . . . . . . . . 7 58 4. Use Case and Functional Requirements related to deployment 59 scenario . . . . . . . . . . . . . . . . . . . . . . . . . . 8 60 4.1. Use Case 1 - Resource-constrained scenario . . . . . . . 8 61 4.2. Use Case 2 - TA and SD management owned by OEM and SP . . 8 62 4.3. Use Case 3 - Batch mode . . . . . . . . . . . . . . . . . 9 63 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 64 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 65 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 66 7.1. Normative References . . . . . . . . . . . . . . . . . . 9 67 7.2. Informative References . . . . . . . . . . . . . . . . . 10 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 70 1. Introduction 72 Chips used on smart phones, tablets, and many consumer appliances 73 today have built-in support for a so-called Trusted Execution 74 Environment (TEE). The TEE is a security concept that separates 75 normal operating systems, like Linux, from code that requires higher 76 security protection, like security-related code. The underlying idea 77 of this sandboxing approach is to have smaller code that is better 78 reviewed and test and to provide it with more rights. They run on 79 the so-called Secure World (in comparison to the Linux operating 80 system that would run in the Normal World). 82 TEEs have been on the market for a while and have been successfully 83 used for a number of applications, such as payment etc. However, the 84 technology hasn't reached its full potential since ordinary 85 developers who could make use of such functionality have a hard time 86 getting access to it, and to write applications for it. 88 The industry has been working on an application layer security 89 protocol that allows to configure security credentials and software 90 running on a Trusted Execution Environment (TEE) for sometime. 91 Today, TEEs are, for example, found home routers, set-top boxes, 92 smart phones, tablets, wearables, etc. Unfortunately, there have 93 been mostly proprietary protocols used in this environment. 95 This document discusses the use cases and features of open trust 96 protocol. 98 2. Terminology 100 OTrP: Open Trust Protocol 102 Client Application: An application running on a rich OS, such as an 103 Android, Windows, or iOS application, provided by a SP. 105 Device: A physical piece of hardware that hosts symmetric key 106 cryptographic modules 108 OTrP Agent: An application running in the rich OS allowing 109 communication with the TSM and the TEE. 111 Rich Application: Alternative name of "Client Application". In this 112 document we may use these two terms interchangably. 114 Rich Execution Environment (REE) An environment that is provided and 115 governed by a rich OS, potentially in conjunction with other 116 supporting operating systems and hypervisors; it is outside of 117 the TEE. This environment and applications running on it are 118 considered un-trusted. 120 Secure Boot Module (SBM): A firmware in a device that delivers 121 secure boot functionality. It is also referred as Trusted 122 Firmware (TFW) in this document. 124 Service Provider (SP): An entity that wishes to supply Trusted 125 Applications to remote devices. A Service Provider requires the 126 help of a TSM in order to provision the Trusted Applications to 127 the devices. 129 Trust Anchor: A root certificate that a module trusts. It is 130 usually embedded in one validating module, and used to validate 131 the trust of a remote entity's certificate. 133 Trusted Application (TA): Application that runs in TEE. 135 Trusted Execution Environment (TEE): An execution environment that 136 runs alongside but isolated from an REE. A TEE has security 137 capabilities and meets certain security-related requirements: It 138 protects TEE assets from general software attacks, defines rigid 139 safeguards as to data and functions that a program can access, 140 and resists a set of defined threats. There are multiple 141 technologies that can be used to implement a TEE, and the level 142 of security achieved varies accordingly. 144 CA: Certificate Authority 146 SD: Security Domain 148 TFW: Trusted Firmware 150 TSM: Trusted Service Manager 152 3. Scenario and Use Cases of OtrP 154 OTrP is an open interoperable protocol that allows TSM to manage 155 security domains and TAs running in different Trusted Execution 156 Environment (TEE) of various devices. 158 Figure 1: OTrP System Overview: 160 ---OTrP Message Protocol-- 161 | | 162 | | 163 -------------------- --------------- ---------- 164 | REE | TEE | | TSM | | SP | 165 | --- | --- | | --- | | -- | 166 | | | | | | | 167 | Client | SD (TAs)| | SD / TA | | TA | 168 | Apps | | | Mgmt | | | 169 | | | | | | | | 170 | | | | | | | | 171 | OTrP | Trusted | | Trusted | | | 172 | Agent | CAs | | FW, TEE CAs | | | 173 | | | | | | | 174 | |TEE Key/ | | TSM Key/ | |SP Key/ | 175 | | Cert | | Cert | | Cert | 176 | | FW Key/ | | | | | 177 | | Cert | | | | | 178 ------------------ --------------- ---------- 179 | | | 180 | | | 181 ----------------------------------------- 182 | 183 | 184 -------------- 185 | CA | 186 -------------- 188 o The use of open environments: In general, some new kind device 189 will be equipped with open environment to provide the operating 190 system. This has the advantage that users can add applications at 191 any time, and there is little need to worry about their impact on 192 the stability and security of the device. However, the open 193 environment makes the device face more and more foreign attacks. 194 Device manufacturers want to take advantage of this operating 195 system, but need to effectively control the behavior of the 196 software running on the device. 198 o Verification: The traditional user authentication method requires 199 a username and password. At present, this approach is 200 increasingly considered safe, after all, consumers will use a less 201 confidential password or re-use the existing password, and hackers 202 are increasingly able to invade the consumer's account. Because 203 an application or service provider typically stores personal 204 verification and sensitive information on its own server, such 205 hacking is the headline of the news, causing consumers to fear and 206 shaken business confidence. Therefore, there is a need for a more 207 sophisticated validation mechanism to ensure that the openers of 208 the application enjoy the necessary flexibility while protecting 209 the consumer. 211 o Privacy: The device stores more and more personal information 212 (such as contact information, photos, photos and video clips), and 213 even sensitive data (including credentials, passwords, medical 214 data, etc.). In order to prevent this information from being 215 exposed to loss, theft, malware or other negative events, we need 216 adequate security to store, process and distribute such personal 217 data. 219 o Content protection: Today, more and more devices with high- 220 definition (HD) video playback and video streaming, mobile TV 221 playback and host 3D games and other functions. They can even 222 become content gateway devices, and to replace the traditional 223 set-top boxes or game consoles. In this case, the playback 224 function of the device becomes less important, and the security 225 requirements are more and more prominent. Therefore, not only to 226 protect the mobile device on the full HD or ultra-high-definition 227 content, but also to protect the device to send the content to the 228 TV through the channel. 230 o Enterprise Data Access: Enterprise IT professionals often exercise 231 caution when opening access to their internal network, fearing 232 that the device will carry malware, the device will be stolen, or 233 when used outside the company, there will be attacks from the 234 internal network The As a result, IT departments often establish 235 green lists and red lists of equipment based on the security 236 performance of the device. They are also concerned about the 237 characteristics of these devices always open and the 238 implementation of password protection and device lockout functions 239 in shutdown mode. 241 o Financial risk: Financial transactions through networking devices, 242 especially mobile devices, are becoming increasingly common. 243 These transactions include booking, remote payments, near-field 244 payments and financial electronic transactions. Moreover, the use 245 of mobile devices in the retail outlets shopping has become 246 increasingly common. Moreover, mobile devices become a point-of- 247 sale terminal, especially mobile point of sale, and this use case 248 is now growing. 250 3.1. Use Case 1 - Payment 252 Payment technology (Especially mobile payments) is growing rapidly. 254 The TEE-based identity authentication application has a strong need 255 for using OTrP. The types of TA involved mainly include the 256 following two kinds: 258 o Identification: Personal identification password and biometric. 259 Because TEE can provides larger amount of memory and data 260 transfer, TEE can store a trusted application that is used to 261 complete a personal password acquisition or biological 262 identification. For the development of the relevant TA of SP, the 263 use of OTrP can easily send the latest trusted application to the 264 device. At the same time, because TA and REE applications are 265 independent of each other, REE side of the corresponding 266 application only need to make little changes because of the OTrP. 268 o Security interface: Mobile payment is inseparable from the 269 security interaction between end users and consumer devices. For 270 example, the user needs to confirm the sensitive information 271 displayed on the screen and enter the sensitive information (such 272 as a password) through the keyboard. A TA such as keyboard in tee 273 is needed. When designing a keyboard in tee, you should consider 274 how to make a timely update when an application has a 275 vulnerability to ensure that user sensitive data is not 276 compromised.In this case, it is necessary to use OTrP 278 3.2. Use Case 2 - IoT 280 In the field of Internet of Things, the purpose of TA is to use TEE 281 to perform the functions of storing and managing sensitive data (eg, 282 encryption keys) and performing sensitive operations (eg, 283 authentication or encryption) in a secure environment in devices 285 In the smart home industry, a lot of security equipment are used TEE 286 program to protect users of sensitive data, such as smart door locks. 287 Some smart door locks even use biometrics, which makes this 288 application in smart home very similar to the payment industry. 289 Similarly, security products also need a secure and trusted remote 290 update protocol to update the TA program in the device. 292 In the automotive (and bike) sharing industry, smart door locks use 293 TEE technology to protect users' identity information. Operators who 294 share automotive products need to remotely update trusted 295 applications in smart locks. 297 Some high-value consumer electronics devices also have the need to 298 use TEE and complete TA remote updates. For example, UAV (Unmanned 299 Aerial Vehicle) devices use TEE to store sensitive operational 300 instructions to prevent hackers from controlling the UAV's takeoff or 301 landing by tampering with GPS location information. The manufacturer 302 of the UAV needs to consider the easy management of the safety 303 instructions in the UAV. For example, when the geographical location 304 information of the prohibited flight area is changed, the equipment 305 manufacturer should be able to update all the corresponding 306 information stored in the device . 308 4. Use Case and Functional Requirements related to deployment scenario 310 4.1. Use Case 1 - Resource-constrained scenario 312 As mentioned earlier, in the shared automotive industry, smart door 313 locks have the requirement to use OTrP. In this scenario, the update 314 of TA in the smart door locks is facing with the problem of 315 communication bandwidth limitation. Software and firmware updates 316 often comprise quite a large amount of data. Therefore, it may 317 overload the LPWAN which is typically used to transfer only small 318 amounts of data. Binary encoding solution will be a better choice in 319 the scenario of Low-power and Lossy Networks (LLNs), Low Power 320 Personal Area Network (LPPAN)and Low Power Wide Area Network (LPWAN). 322 4.2. Use Case 2 - TA and SD management owned by OEM and SP 324 There are three configurations to manage TA and SD in TEE: 326 o The OEM wants to ensure that no service provider can talk to the 327 TEE without the OEM's prior approval. Once approved, the Service 328 Provider is allowed to create security domains and install trusted 329 apps. The OEM doesn't require to be involved in that process. 331 o The OEM wants to ensure that no service provider can talk to the 332 TEE without the OEM's prior approval. Once approved, the Service 333 Provider is allowed to perform lifecycle management of trusted 334 apps within a particular security domain but cannot create any new 335 security domains without the OEM's involvement. 337 o The OEM and Service provider both want to be involved in every 338 transaction with TEE and only when they both agree the TEE can 339 accept the OTrP message and perform actions. 341 The first kind of configuration can give OEM greater management 342 authority. It could be very convenient for the management of SD and 343 TA. 345 The second configuration can give OEM a certain degree of control, TA 346 can be easily issued to SD by SP. But at the same time, how to 347 protect the security of TAM platform and TEE terminal should be 348 considered. 350 The third configuration can reduce the security risk caused by the 351 insecure TA program but it will also increase the complexity of 352 deployment and maintenance. 354 4.3. Use Case 3 - Batch mode 356 Batch mode operation could be more efficient in some deployment 357 scenario. For example, some OEM may want to provision TA into many 358 devices they know with the same device key (for privacy and batch 359 validation purpose). A TAM may issue one OTrP message to create SD 360 and install the TA and send to many devices without requiring each 361 device to submit their own device attestation. The batch support 362 will reduce the load on the service side (TAM). 364 5. IANA Considerations 366 This memo includes no request to IANA. 368 6. Security Considerations 370 TBD. 372 7. References 374 7.1. Normative References 376 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 377 Requirement Levels", BCP 14, RFC 2119, 378 DOI 10.17487/RFC2119, March 1997, 379 . 381 [RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web 382 Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May 383 2015, . 385 [RFC7516] Jones, M. and J. Hildebrand, "JSON Web Encryption (JWE)", 386 RFC 7516, DOI 10.17487/RFC7516, May 2015, 387 . 389 [RFC7517] Jones, M., "JSON Web Key (JWK)", RFC 7517, 390 DOI 10.17487/RFC7517, May 2015, 391 . 393 [RFC7518] Jones, M., "JSON Web Algorithms (JWA)", RFC 7518, 394 DOI 10.17487/RFC7518, May 2015, 395 . 397 7.2. Informative References 399 [draft-pei-opentrustprotocol] 400 "The Open Trust Protocol (OTrP)", January 2017. 402 [GPTEE] Global Platform, "Global Platform, GlobalPlatform Device 403 Technology: TEE System Architecture, v1.0", 2013. 405 Authors' Addresses 407 Dapeng Liu 408 Alibaba Group 409 Beijing 410 Beijing 412 Phone: +86-1391788933 413 Email: maxpassion@gmail.com 415 Mingliang Pei 416 Symantec 417 Mountain View, CA 418 USA 420 Email: mpei@yahoo.com 422 Hannes Tschofenig 423 ARM Ltd. 424 110 Fulbourn Rd Cambridge, CB1 9NJ 425 Great Britain 427 Email: Hannes.tschofenig@arm.com 429 Qiang Fang 430 Alibaba Group 431 Beijing 432 Beijing 434 Phone: +86-15210569677 435 Email: qiangwu.fq@alibaba-inc.com