idnits 2.17.1 draft-liu-opentrustprotocol-usecase-01.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 (July 3, 2017) is 2482 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2119' is defined on line 478, but no explicit reference was found in the text == Unused Reference: 'RFC7515' is defined on line 483, but no explicit reference was found in the text == Unused Reference: 'RFC7516' is defined on line 487, but no explicit reference was found in the text == Unused Reference: 'RFC7517' is defined on line 491, but no explicit reference was found in the text == Unused Reference: 'RFC7518' is defined on line 495, but no explicit reference was found in the text == Unused Reference: 'GPTEE' is defined on line 501, 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 Q. Fang 4 Intended status: Informational Alibaba Group 5 Expires: January 4, 2018 July 3, 2017 7 A Protocol for Dynamic Trusted Execution Environment Enablement 8 draft-liu-opentrustprotocol-usecase-01 10 Abstract 12 This document describes features of a open trust protocol and related 13 use cases. With the Open Trust Protocol, see 14 https://tools.ietf.org/html/draft-pei-opentrustprotocol-03, we have 15 been trying to develop this application layer security protocol that 16 allows the management of credentials and the update of such 17 applications. 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 January 4, 2018. 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. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . . 2 54 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 55 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 4. Scenario and usecase of OtrP . . . . . . . . . . . . . . . . 4 57 4.1. Use Case 1 - Payment . . . . . . . . . . . . . . . . . . 7 58 4.2. Use Case 2 - IoT . . . . . . . . . . . . . . . . . . . . 8 59 5. The functional requirements generated by the scenario and 60 usecase . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 61 5.1. Use Case 1 - Resource-constrained interaction and 62 multicast . . . . . . . . . . . . . . . . . . . . . . . . 9 63 5.2. Use Case 2 - TA and SD management owned by OEM and SP . . 9 64 5.3. Use Case 3 - Batch mode . . . . . . . . . . . . . . . . . 10 65 5.4. Use Case 4 - personalization data management . . . . . . 10 66 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 67 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 68 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 69 8.1. Normative References . . . . . . . . . . . . . . . . . . 11 70 8.2. Informative References . . . . . . . . . . . . . . . . . 11 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 73 1. Acronyms 75 CA Certificate Authority 77 OTrP Open Trust Protocol 79 REE Rich Execution Environment 81 SD Security Domain 83 SP Service Provider 85 SBM Secure Boot Module 87 TA Trusted Application 89 TEE Trusted Execution Environment 91 TFW Trusted Firmware 93 TSM Trusted Service Manager 95 2. Introduction 97 Chips used on smart phones, tablets, and many consumer appliances 98 today have built-in support for a so-called Trusted Execution 99 Environment (TEE). The TEE is a security concept that separates 100 normal operating systems, like Linux, from code that requires higher 101 security protection, like security-related code. The underlying idea 102 of this sandboxing approach is to have smaller code that is better 103 reviewed and test and to provide it with more rights. They run on 104 the so-called Secure World (in comparison to the Linux operating 105 system that would run in the Normal World). 107 TEEs have been on the market for a while and have been successfully 108 used for a number of applications, such as payment. However, the 109 technology hasn't reached its full potential since ordinary 110 developers who could make use of such functionality have a hard time 111 getting access to it, and to write applications for it . 113 The industry has been working on an application layer security 114 protocol that allows to configure security credentials and software 115 running on a Trusted Execution Environment (TEE) for sometime. 116 Today, TEEs are, for example, found home routers, set-top boxes, 117 smart phones, tablets, wearables, etc. Unfortunately, there have 118 been mostly proprietary protocols used in this environment. 120 This document describes features of a open trust protocol and related 121 use cases. 123 3. Terminology 125 Client Application: An application running on a rich OS, such as an 126 Android, Windows, or iOS application, provided by a SP. 128 Device: A physical piece of hardware that hosts symmetric key 129 cryptographic modules 131 OTrP Agent: An application running in the rich OS allowing 132 communication with the TSM and the TEE. 134 Rich Application: Alternative name of "Client Application". In this 135 document we may use these two terms interchangably. 137 Rich Execution Environment (REE) An environment that is provided and 138 governed by a rich OS, potentially in conjunction with other 139 supporting operating systems and hypervisors; it is outside of 140 the TEE. This environment and applications running on it are 141 considered un-trusted. 143 Secure Boot Module (SBM): A firmware in a device that delivers 144 secure boot functionality. It is also referred as Trusted 145 Firmware (TFW) in this document. 147 Service Provider (SP): An entity that wishes to supply Trusted 148 Applications to remote devices. A Service Provider requires the 149 help of a TSM in order to provision the Trusted Applications to 150 the devices. 152 Trust Anchor: A root certificate that a module strusts. It is 153 usually embedded in one validating module, and used to validate 154 the trust of a remote entity's certificate. 156 Trusted Application (TA): Application that runs in TEE. 158 Trusted Execution Environment (TEE): An execution environment that 159 runs alongside but isolated from an REE. A TEE has security 160 capabilities and meets certain security-related requirements: It 161 protects TEE assets from general software attacks, defines rigid 162 safeguards as to data and functions that a program can access, 163 and resists a set of defined threats. There are multiple 164 technologies that can be used to implement a TEE, and the level 165 of security achieved varies accordingly. 167 4. Scenario and usecase of OtrP 169 OTrP Message is an open interoperable protocol that allows 170 trustworthy TSM to manage security domains and contents running in 171 different Trusted Execution Environment (TEE) of various devices. 173 Figure 1: OTrP System Diagram 175 ---OTrP Message Protocol-- 176 | | 177 | | 178 -------------------- --------------- ---------- 179 | REE | TEE | | TSM | | SP | 180 | --- | --- | | --- | | -- | 181 | | | | | | | 182 | Client | SD (TAs)| | SD / TA | | TA | 183 | Apps | | | Mgmt | | | 184 | | | | | | | | 185 | | | | | | | | 186 | OTrP | Trusted | | Trusted | | | 187 | Agent | CAs | | FW, TEE CAs | | | 188 | | | | | | | 189 | |TEE Key/ | | TSM Key/ | |SP Key/ | 190 | | Cert | | Cert | | Cert | 191 | | FW Key/ | | | | | 192 | | Cert | | | | | 193 ------------------ --------------- ---------- 194 | | | 195 | | | 196 ----------------------------------------- 197 | 198 | 199 -------------- 200 | CA | 201 -------------- 203 TEE is usually used to solve the following security issues.In theory, 204 in order to solve the above security issues, TEE which can exist in 205 the corresponding TA to complete the corresponding security 206 features.In conjunction with the description in Figure 1, the SP is 207 responsible for developing the appropriate security application and 208 becoming the end user of the OTrP protocol. 210 o The use of open environments: In general, some new kind device 211 will be equipped with open environment to provide the operating 212 system. This has the advantage that users can add applications at 213 any time, and there is little need to worry about their impact on 214 the stability and security of the device. However, the open 215 environment makes the device face more and more foreign attacks. 216 Device manufacturers want to take advantage of this operating 217 system, but need to effectively control the behavior of the 218 software running on the device. 220 o Verification: The traditional user authentication method requires 221 a username and password. At present, this approach is 222 increasingly considered safe, after all, consumers will use a less 223 confidential password or re-use the existing password, and hackers 224 are increasingly able to invade the consumer's account. Because 225 an application or service provider typically stores personal 226 verification and sensitive information on its own server, such 227 hacking is the headline of the news, causing consumers to fear and 228 shaken business confidence. Therefore, there is a need for a more 229 sophisticated validation mechanism to ensure that the openers of 230 the application enjoy the necessary flexibility while protecting 231 the consumer. 233 o Privacy: The device stores more and more personal information 234 (such as contact information, photos, photos and video clips), and 235 even sensitive data (including credentials, passwords, medical 236 data, etc.). In order to prevent this information from being 237 exposed to loss, theft, malware or other negative events, we need 238 adequate security to store, process and distribute such personal 239 data. 241 o Content protection: Today, more and more devices with high- 242 definition (HD) video playback and video streaming, mobile TV 243 playback and host 3D games and other functions. They can even 244 become content gateway devices, and to replace the traditional 245 set-top boxes or game consoles. In this case, the playback 246 function of the device becomes less important, and the security 247 requirements are more and more prominent. Therefore, not only to 248 protect the mobile device on the full HD or ultra-high-definition 249 content, but also to protect the device to send the content to the 250 TV through the channel. 252 o Enterprise Data Access: Enterprise IT professionals often exercise 253 caution when opening access to their internal network, fearing 254 that the device will carry malware, the device will be stolen, or 255 when used outside the company, there will be attacks from the 256 internal network The As a result, IT departments often establish 257 green lists and red lists of equipment based on the security 258 performance of the device. They are also concerned about the 259 characteristics of these devices always open and the 260 implementation of password protection and device lockout functions 261 in shutdown mode. 263 o Financial risk: Financial transactions through networking devices, 264 especially mobile devices, are becoming increasingly common. 265 These transactions include booking, remote payments, near-field 266 payments and financial electronic transactions. Moreover, the use 267 of mobile devices in the retail outlets shopping has become 268 increasingly common. Moreover, mobile devices become a point-of- 269 sale terminal, especially mobile point of sale, and this use case 270 is now growing. 272 OTrP can be more efficient than the traditional OTA model, which can 273 also reduce management overhead.The following two scenarios are used 274 to explain why OTrP is required instead of OTA: 276 o Use Case 1 - Security vulnerability fixes:Imagining a fingerprint 277 application stored in TEE appear an error, OTrP can help to fix 278 this by several programers in one small team, but OTA may need to 279 update the whole application by several teams in a company. 281 o Use Case 2 - Personalization data update: In IoT,there are lots of 282 scenes that only need to update the personalized data without 283 having to update the entire application like OTA. 285 Based on current research, this document provides an example of the 286 application in the payment and IoT industry. 288 4.1. Use Case 1 - Payment 290 Payment technology(Especially mobile payments) is growing rapidly, in 291 which the payment system continues to expand their trusted payment 292 applications through existing technology and new technologies. 294 The TEE-based identity authentication application has a strong need 295 for using otrp. The types of TA involved mainly include the 296 following two kinds. 298 o Identification:Personal identification password and 299 biometric.Because TEE can provides larger amount of memory and 300 data transfer, TEE can store a trusted application that is used to 301 complete a personal password acquisition or biological 302 identification.For the development of the relevant TA of SP, the 303 use of OTrP can easily send the latest trusted application to the 304 device. At the same time, because TA and REE applications are 305 independent of each other, REE side of the corresponding 306 application only need to make little changes because of the OTrP. 308 o Security interface:Mobile payment is inseparable from the security 309 interaction between end users and consumer devices. For example, 310 the user needs to confirm the sensitive information displayed on 311 the screen and enter the sensitive information (such as a 312 password) through the keyboard.A TA such as keyboard in tee is 313 needed.When designing a keyboard in tee, you should consider how 314 to make a timely update when an application has a vulnerability to 315 ensure that user sensitive data is not compromised.In this case, 316 it is necessary to use OTrP 318 4.2. Use Case 2 - IoT 320 In the field of Internet of Things, the purpose of TA is to use TEE 321 to perform the functions of storing and managing sensitive data (eg, 322 encryption keys) and performing sensitive operations (eg, 323 authentication or encryption) in a secure environment in devices 325 In the smart home industry, a lot of security equipment are used TEE 326 program to protect users of sensitive data, such as smart door locks. 327 Some smart door locks even use biometrics, which makes this 328 application in smart home very similar to the payment industry. 329 Similarly, security products also need a secure and trusted remote 330 update protocol to update the TA program in the device. 332 In the automotive (and bike) sharing industry, smart door locks use 333 TEE technology to protect users' identity information. Operators who 334 share automotive products need to remotely update trusted 335 applications in smart locks. 337 Some high-value consumer electronics devices also have the need to 338 use TEE and complete TA remote updates.For example, UAV devices use 339 TEE to store sensitive operational instructions to prevent hackers 340 from controlling the UAV's takeoff or landing by tampering with GPS 341 location information.The manufacturer of the UAV needs to consider 342 the easy management of the safety instructions in the UAV. For 343 example, when the geographical location information of the prohibited 344 flight area is changed, the equipment manufacturer should be able to 345 update all the Corresponding information stored in the device . 347 In the automotive (and bike) sharing industry, smart door locks use 348 TEE technology to protect users' identity information. Operators who 349 share automotive products need to remotely update trusted 350 applications in smart locks. 352 5. The functional requirements generated by the scenario and usecase 354 OTrP need to consider the requirements of OEM, SP, CA, TEE 355 manufacturers, it will be helpfull to analysis the scenario and 356 usecase to improve the functions of OTrP and solve the problems 357 encountered in the deployment process. 359 The following lists the scenarios that OTrP users have already 360 submitted. This section will continue to update according to the 361 actual deployment of OTrP. 363 5.1. Use Case 1 - Resource-constrained interaction and multicast 365 In draft-pei-opentrustprotocol-03,OTrP is defined with a protocol 366 which relies on IETF-defined end-to-end security mechanisms, namely 367 JSON Web Encryption (JWE), JSON Web Signature (JWS), and JSON Web 368 Key(JWK). Using JSON makes OTrP easier to accept by the developer, 369 but in the case of limited resources, the use of Json is not a good 370 choice, especially Json need to do some of the contents of the base64 371 transcoding. 373 As mentioned earlier, in the shared automotive industry, smart door 374 locks have the requirement to use OTrP. In this scenario, the update 375 of TA in the smart door locks is facing with the problem of 376 communication bandwidth limitation and multicast demand. software and 377 firmware updates often comprise quite a large amount of data. 378 Therefore, it can overload a LLN that is otherwise typically used to 379 deal with only small amounts of data, on an infrequent base. Rather 380 than sending software and firmware updates as unicast messages to 381 each individual device, multicasting such updated data to a larger 382 group of devices at once displays a number of benefits.Binary 383 solutions will be a better choice in the scenario such as low-power 384 and lossy networks (LLNs),Low Power Personal Area Network(LWPAN)and 385 Low Power Wide Area Network (LWAN). 387 As descrypted above, public key infrastructure (PKI) is used to do 388 identiy authentication and securely exchange data over network. But, 389 this is not a good choice for resource-constrained devices, 390 especailly for IoT, to manage certificates and process TLS protocols, 391 which need much memory and processing time. 393 5.2. Use Case 2 - TA and SD management owned by OEM and SP 395 There are three permission settings to manage TA and SD in TEE: 397 o The OEM wants to ensure that no service provider can talk to the 398 TEE without the OEM's prior approval. Once approved, the Service 399 Provider is allowed to create security domains and install trusted 400 apps. The OEM doesn't require to be involved in that phase. 402 o The OEM wants to ensure that no service provider can talk to the 403 TEE without the OEM's prior approval. Once approved, the Service 404 Provider is allowed to perform lifecycle management of trusted 405 apps within a particular security domain but cannot create any new 406 security domains without the OEM being involved and agreeing to 407 it. 409 o The OEM and Service provider both want to be involved in every 410 transaction with the TEE, and only when they both agree should the 411 TEE accept the OTrP message and perform the action. 413 The first kind of permission setting can give SP manufacturers 414 greater management authority, which can be very convenient management 415 of SD and TA, but the security between SDs which set up by different 416 vendors will not be able to be protected. 418 The second permission setting can give SP manufacturers a certain 419 degree of control, TA can be easily issued to SD by SP. But at the 420 same time, how to protect the security of TAM platform and TEE 421 terminal should be considered. 423 The third permission setting can guarantee the management right of 424 the OEM to the terminal, and avoid the terminal security risk caused 425 by the insecurity of the TA program to a certain extent. However, in 426 this authority set, the service provider to maintain the convenience 427 of TA will be significantly reduced. 429 5.3. Use Case 3 - Batch mode 431 In draft-pei-opentrustprotocol-03, the following steps have to be 432 done for deploying TA to device: establish trust between TEE and TSM, 433 create Security Domain, and finally install TA in the device. This 434 procedure will take at least three back and forth between TSM server 435 and the device. While there are huge amount of IoT devices, this 436 mechanism will make the burden of TSM server raise considerably. 438 In order to reduce the burden of TSM server, this procedure can be 439 simplified by batch mode: TSM server will sign every command which 440 runs in the device, pack them together in a command package, and send 441 this package to a batch of devices. This one-time communication can 442 significantly reduce the burden of TSM server. To make this happen, 443 the DSI of these devices should be the same. DSI information can be 444 organized by manufacture or by device model. 446 5.4. Use Case 4 - personalization data management 448 In many scenes, TAM only need to manage TA and SD personalization 449 data, without having to update the entire TA or SD. Therefore, 450 personalization data management function is required.The detail 451 functions involved are as follows: 453 o Service provider key management(SD personalization data 454 management). For example: In the field of IoT,a hotel(Service 455 provider)an use this function to update a pair of keys to the lock 456 of the door and the IoT device of customer. 458 o TUI management(TA personalization data management).For example:In 459 the field of financial, a bank can use this function to update the 460 keyboard(Or other Trusted User Interfaces) of E-banking. 462 o Other business data management.For example:In the field of 463 payment,a company can use this function to update the QR code 464 stored in TEE which is used for payment. 466 6. IANA Considerations 468 This memo includes no request to IANA. 470 7. Security Considerations 472 TBD. 474 8. References 476 8.1. Normative References 478 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 479 Requirement Levels", BCP 14, RFC 2119, 480 DOI 10.17487/RFC2119, March 1997, 481 . 483 [RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web 484 Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May 485 2015, . 487 [RFC7516] Jones, M. and J. Hildebrand, "JSON Web Encryption (JWE)", 488 RFC 7516, DOI 10.17487/RFC7516, May 2015, 489 . 491 [RFC7517] Jones, M., "JSON Web Key (JWK)", RFC 7517, 492 DOI 10.17487/RFC7517, May 2015, 493 . 495 [RFC7518] Jones, M., "JSON Web Algorithms (JWA)", RFC 7518, 496 DOI 10.17487/RFC7518, May 2015, 497 . 499 8.2. Informative References 501 [GPTEE] Global Platform, "Global Platform, GlobalPlatform Device 502 Technology: TEE System Architecture, v1.0", 2013. 504 Authors' Addresses 506 Dapeng Liu 507 Alibaba Group 508 Beijing 509 Beijing 511 Phone: +86-1391788933 512 Email: maxpassion@gmail.com 514 Qiang Fang 515 Alibaba Group 516 Beijing 517 Beijing 519 Phone: +86-15210569677 520 Email: qiangwu.fq@alibaba-inc.com