idnits 2.17.1 draft-wang-iot-devices-security-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 (15 March 2021) is 1137 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force B. Wang, Ed. 3 Internet-Draft X. Wang, Ed. 4 Intended status: Standards Track L. Wan, Ed. 5 Expires: 16 September 2021 Hikvision 6 W.Y. Xu, Ed. 7 Zhejiang University 8 C.H. Wang, Ed. 9 IIE, CAS 10 15 March 2021 12 Security Technical Specification for Smart Devices of IoT 13 draft-wang-iot-devices-security-00 15 Abstract 17 With the development of IoT, security of smart devices becomes an 18 important issues for us to discuss. This draft for smart devices of 19 Internet of Things (IoT), proposes a security framework and detailed 20 requirements in terms of hardware, system, data, network, and 21 management to ensure the security of IoT smart devices. 22 Specifically, hardware security includes interface security and 23 security components. System security includes firmware security, 24 security audit, etc. Data security includes data verification and 25 sensitive data protection. Network security includes stream 26 protection and session security, etc. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at https://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on 16 September 2021. 45 Copyright Notice 47 Copyright (c) 2021 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 52 license-info) in effect on the date of publication of this document. 53 Please review these documents carefully, as they describe your rights 54 and restrictions with respect to this document. Code Components 55 extracted from this document must include Simplified BSD License text 56 as described in Section 4.e of the Trust Legal Provisions and are 57 provided without warranty as described in the Simplified BSD License. 59 Table of Contents 61 1. Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 3. Terms and Definitions . . . . . . . . . . . . . . . . . . . . 3 64 3.1. Smart device . . . . . . . . . . . . . . . . . . . . . . 3 65 3.2. Smart Video Surveillance Device . . . . . . . . . . . . . 4 66 3.3. Sensitive Information . . . . . . . . . . . . . . . . . . 4 67 3.4. Vulnerability . . . . . . . . . . . . . . . . . . . . . . 4 68 3.5. Brute Force Attack . . . . . . . . . . . . . . . . . . . 4 69 3.6. Network Port . . . . . . . . . . . . . . . . . . . . . . 4 70 3.7. Video Stream . . . . . . . . . . . . . . . . . . . . . . 4 71 3.8. Device Activation . . . . . . . . . . . . . . . . . . . . 4 72 4. Abbreviations and Acronyms . . . . . . . . . . . . . . . . . 5 73 5. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 5 74 6. Security Function Requirement . . . . . . . . . . . . . . . . 7 75 6.1. Hardware Security . . . . . . . . . . . . . . . . . . . . 7 76 6.1.1. Interface Security . . . . . . . . . . . . . . . . . 7 77 6.1.2. Security Components . . . . . . . . . . . . . . . . . 7 78 6.2. System Security . . . . . . . . . . . . . . . . . . . . . 7 79 6.2.1. Firmware Security . . . . . . . . . . . . . . . . . . 7 80 6.2.2. Time Synchronization . . . . . . . . . . . . . . . . 8 81 6.2.3. Cryptography Management . . . . . . . . . . . . . . . 8 82 6.2.4. Authentication . . . . . . . . . . . . . . . . . . . 8 83 6.2.5. Access Control . . . . . . . . . . . . . . . . . . . 9 84 6.2.6. Security Audit . . . . . . . . . . . . . . . . . . . 10 85 6.3. Data Security . . . . . . . . . . . . . . . . . . . . . . 10 86 6.3.1. Data Verification . . . . . . . . . . . . . . . . . . 10 87 6.3.2. Sensitive Data Protection . . . . . . . . . . . . . . 10 88 6.4. Network Security . . . . . . . . . . . . . . . . . . . . 11 89 6.4.1. Access Security . . . . . . . . . . . . . . . . . . . 11 90 6.4.2. Port Security . . . . . . . . . . . . . . . . . . . . 11 91 6.4.3. Service and Protocol Security . . . . . . . . . . . . 11 92 6.4.4. Session Security . . . . . . . . . . . . . . . . . . 11 93 6.4.5. Transmission Security . . . . . . . . . . . . . . . . 12 94 6.4.6. Video Stream Protection . . . . . . . . . . . . . . . 12 95 6.5. Security Management . . . . . . . . . . . . . . . . . . . 12 96 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 97 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 98 9. Informative References . . . . . . . . . . . . . . . . . . . 12 99 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 101 1. Preface 103 The new paradigm of IoT is recognized as one of the most important 104 actors in the Information and Communication Technology industry for 105 next years [Miorandi2012]. The introduction of IPv6 [RFC6568] and 106 CoAP [RFC7252] as fundamental building blocks for IoT applications 107 allows connecting IoT hosts to the Internet. [RFC7744] provides an 108 overview of relevant IoT use cases. With the development of IoT in 109 recent years, the industry of smart devices gains great momentum, 110 resulting in a large-scale production and application of smart 111 devices. However, the absence of unified security standards leads to 112 various security defense measures, which imposes huge threats on IoT 113 security. Until today, smart devices have become a favored target of 114 hackers, which leads to frequent security incidents. [Qiu2020] and 115 [Neshenko2019] conducted a detailed survey on the security issues of 116 IoT. 118 This draft proposes detailed security requirements to ensure smart 119 devices can work in a security condition. 121 2. Scope 123 This draft proposes some basic security requirements that should be 124 met by smart devices in IoT. 126 This draft is proposed for specifying security functions of smart 127 devices in IoT to improve the security of devices, which can prevent 128 devices from being maliciously exploited by attackers and safeguard 129 users' privacy. 131 This draft is also applicable to instructing the design and 132 implementation of security functions of smart devices in IoT. 134 3. Terms and Definitions 136 3.1. Smart device 138 Smart device is a kind of device that can perceive and process video, 139 image or other information. For example, video device, access 140 control device, radar, etc. Smart device can directly be connected 141 to IoT platform, or be a gateway connecting the agent sub-device to 142 IoT platform. 144 3.2. Smart Video Surveillance Device 146 Video surveillance device is a typical smart device, which can 147 collect and process video image signals, and communicate with other 148 devices via the Internet. 150 3.3. Sensitive Information 152 Information that is confidential and is of actual or potential value. 153 The loss, improperly use or unauthorized access of this information 154 may cause harm to society, business or individuals. 156 3.4. Vulnerability 158 A flaw in the specific implementation of a software (hardware or 159 protocol) or the security strategy of a system, leaving it open to 160 the potential for exploitation in the form of unauthorized access or 161 malicious behaviors. 163 3.5. Brute Force Attack 165 Check all possible passwords systematically to find the correct one. 167 3.6. Network Port 169 Network port is an endpoint of communication in an operating system, 170 which identifies a specific process or a type of network service 171 running on that system, such as service ports in TCP/IP with port 172 numbers ranging from 0 to 65535. 174 3.7. Video Stream 176 The data stream of video information in network transmission. 178 3.8. Device Activation 180 To set the administrator's password when the user uses the device for 181 the first time, and the password must meet the requirements of 182 password security policy. 184 4. Abbreviations and Acronyms 186 The following abbreviations and acronyms are used in this draft: 187 Abbreviations and Acronyms | Full Name --------|-----: JTAG | Joint 188 Test Action Group IP | Internet Protocol TLS | Transport Layer 189 Security HTTPS | Hyper Text Transfer Protocol Secure SSH | Secure 190 Shell SFTP | Secure File Transfer Protocol OTP | One Time 191 Programmable Read Only Memory TEE | Trusted Execution Environment 192 Table: Abbreviations and Acronyms 194 5. Overview 196 The framework of IoT consists of three layers. From bottom to top, 197 they are the perception layer, the network layer and the application 198 layer. Smart devices reside in the perception layer, aim to capture 199 and process video information, and interact with IoT system through 200 communication modules. The framework of smart devices is shown as 201 follow: 203 +-------------------------------------------------------+ 204 | Application | 205 +----------------------------+--------------------------+ 206 | | | 207 | Media & Algorithm library | | 208 | | | 209 | +-------+ +-------------+ | | 210 | | Video | | Algorithm A | | Network | 211 | +-------+ +-------------+ | communication | 212 | +------+ +-------------+ | | 213 | | Audio| | Algorithm B | | | 214 | +------+ +-------------+ | | 215 +----------------------------+--------------------------+ 216 | Operating System & Bootloader | 217 +-------------------------------------------------------+ 218 | Hardware | 219 |(Lens/Sensors/ISP/AIchips/Memory/Interface/Serial port)| 220 +-------------------------------------------------------+ 222 Figure 1: framework of smart devices 224 The draft adopts the strategy of layered security and multi-level 225 defense, and proposes a security function framework of smart devices, 226 shown as follow: 228 +------------------------------------------------------------------+ 229 | Smart Devices of IoT | 230 | +-----------------------------------------------------+--------+ | 231 | | +------------+ +-----------+ +-----------------+ | | | 232 | | | Access | | Port | |Service & | N | | | 233 | | | Security | | Security | |Protocol Security| E | | | 234 | | +------------+ +-----------+ +-----------------+ T | S | | 235 | | +------------+ +-------------+ +---------------+ W | E | | 236 | | |Transmission| | Stream | | Session | O | C | | 237 | | | Security | | Protection | | Security | R | U | | 238 | | +------------+ +-------------+ +---------------+ K | R | | 239 | +-----------------------------------------------------+ I | | 240 | | +------------+ +----------------+ D | T | | 241 | | | Data | |Sensitive Data | A | Y | | 242 | | |Verification| | Protection | T | | | 243 | | +------------+ +----------------+ A | M | | 244 | +-----------------------------------------------------+ A | | 245 | | +------------+ +------------+ +-------------+ | N | | 246 | | | Firmware | | Security | | Password | S | A | | 247 | | | Security | | Audit | | Management | Y | G | | 248 | | +------------+ +------------+ +-------------+ S | E | | 249 | | +----------------+ +----------------+ +--------+ T | M | | 250 | | | Authentication | | Time | | Access | E | E | | 251 | | | | | Synchronization| | Control| M | N | | 252 | | +----------------+ +----------------+ +--------+ | T | | 253 | +-----------------------------------------------------+ | | 254 | | +----------------------+ +----------------+ | | | 255 | | | Interface | | Security | HARD | | | 256 | | | Security | | Component | WARE | | | 257 | | +----------------------+ +----------------+ | | | 258 | +--------------------------------------------------------------+ | 259 +------------------------------------------------------------------+ 261 Figure 2: Security function framework 263 Hardware security mainly focuses on the hardware feature of the 264 device, including two aspects. The first one is whether there is any 265 unused hardware interface on the device, and the second one is 266 whether the device can provide security support better owe to the 267 security component. 269 System security refers to the secure application of the device's 270 software resources, including bootloader, operating system and 271 applications. 273 Data security aims to protect the data in the device, including 274 device management data and user business data. The special attention 275 should be paid to the sensitive data. 277 Network security realizes the security of the connection to the IoT's 278 network layer and protects against the attack from the network. 280 Security management is mainly about how to securely use and manage 281 the smart devices. 283 6. Security Function Requirement 285 6.1. Hardware Security 287 Hardware security contains interface security and security 288 components. Interface security refers to that the device does not 289 expose any physical interface with security risks. Security 290 component refers to that when designing the hardware, the hardware 291 with security function support shall be prioritized. 293 6.1.1. Interface Security 295 Before the smart devices leave the factory, 297 a) JTAG debugging interface should be disabled. 299 b) serial ports should be disabled, or improved by developing an 300 authentication mechanism 302 6.1.2. Security Components 304 a) For the smart device, chips that support OTP, Secure boot and TEE 305 are recommended, and the relevant security functions should be 306 enabled. 308 b) If possible, it is recommended to add a security chip with 309 cryptography service function. The selection of security chip should 310 follow the corresponding national cryptography management policy. 312 6.2. System Security 314 System security includes firmware security, time synchronization, 315 cryptography management, authentication, security audit and access 316 control, etc. 318 6.2.1. Firmware Security 320 a) The firmware should only contain the necessary components and 321 applications. 323 b) For third-party open source software, the version without known 324 vulnerabilities (or has been patched) can be applied. 326 c) Debug codes in the device should be deleted before device leaves 327 the factory. 329 d) Administrator should have access to check the current version of 330 the device. 332 e) Firmware upgrading should be available. 334 f) When generated, firmware upgrade package should be digitally 335 signed. 337 g) The signature information of the upgrade package shall be verified 338 when the firmware is being upgraded. 340 6.2.2. Time Synchronization 342 The smart device should have real-time clock and support time 343 synchronization calibration function. 345 6.2.3. Cryptography Management 347 a) The smart device should apply publicly standard algorithms 349 b) The smart device should apply industry standard cryptographic 350 algorithm and regularly assess and update the encryption algorithm 351 and its strength. 353 c) The smart device should apply secure random numbers. 355 d) The smart device should forbid the hard coding of secret key. 357 e) The smart device should apply irreversible encryption algorithm in 358 the scenario where the recovery of the password's plaintext is not 359 required. 361 6.2.4. Authentication 363 a) Users' accounts should be unique. 365 b) At least two user roles should be set: administrator and user. 367 c) When the user account is deleted, the corresponding online user 368 should be logged out. 370 d) Permissions assigned to administrators and users should be 371 different. 373 e) Users can manage and control the device only after successful 374 authentication. 376 f) If adopted, a random password should be generated as default 377 before device leaves the factory. The user should be prompted to 378 change the default password. 380 g) If an activation mechanism is adopted, the user should set a 381 secure password that meets security requirements when initializing 382 the device. 384 h) Password complexity check should be in place, and the password 385 should have at least 8 characters, with at least two kinds of the 386 following types: numbers, lowercase, uppercase and special character. 388 i) The password entered by the user must be masked by default, and 389 the password copying must be disabled. 391 j) The password should be encrypted when stored and transmitted. 393 k) The authentication for remote access users should be performed on 394 the server. 396 l) The feedback should not include clear reasons for the 397 authentication failure and should prompt the user with "user name or 398 password error". 400 m) Illegal login lock should be applied to defend against brute force 401 attacks during user authentication. Login attempts from the IP 402 address or account will be rejected for a period of time if it has 403 been failed for certain times. 405 6.2.5. Access Control 407 a) For the smart device, the access to video streams should be 408 authenticated and authorized. 410 b) Only the administrator has the privilege to import (or export) the 411 parameter profile of the device. 413 c) Only the administrator has the privilege to use interactive 414 command console. 416 d) The command console is not allowed to provide user management 417 commands. 419 6.2.6. Security Audit 421 a) The smart device should support security audit. Operations that 422 need to be audited include: 424 1. Enable/disable security audit function, 426 2. User creation, deletion or modification, 428 3. User login/logout, 430 4. Firmware upgrade, 432 5. Configuration change. 434 b) The audit information should include account, IP address, 435 operation time, operation type, operation result, etc. 437 c) The handling mechanism, such as loop coverage or warning, should 438 be in place for scenario where the size of logs is over the preset 439 limit. 441 d) Only authenticated users have the privilege to view logs. 443 e) Log information should be presented in a form that is easy for 444 users to understand. 446 6.3. Data Security 448 6.3.1. Data Verification 450 The IoT smart device should check the validity of the input data, and 451 this process should be carried out on the server. 453 6.3.2. Sensitive Data Protection 455 a) For the smart device, internal sensitive information, such as 456 passwords, configuration information, should be stored as cipher 457 text. 459 b) For the smart device, sensitive information should be encrypted 460 when transmitted. 462 c) For the smart device, log records and information printouts should 463 not contain any sensitive information. 465 d) For the smart device, user interfaces for local, remote, web, and 466 other operations should not show sensitive information. 468 6.4. Network Security 470 6.4.1. Access Security 472 a) The smart device should have unique network identifier. 474 b) If the device accesses the network layer via wireless networks, 475 such as Wi-Fi, the wireless network protection mechanism, such as 476 WPA2, should be applied. 478 6.4.2. Port Security 480 a) The smart device should only enable the necessary network port by 481 default. 483 b) All available network ports of the device should be open to users. 485 6.4.3. Service and Protocol Security 487 a) The smart device should apply secure protocols, including but not 488 limited to TLS, HTTPS, SSH, SFTP, etc. 490 b) The smart device should remove high-risk services, including but 491 not limited to telnet service, FTP service, etc. 493 c) The on-off mechanism of the service should be provided and be off 494 by default when protocols with imperfect security mechanism are 495 applied. A security risk alert is required when the user apply for 496 the service using these insecure protocols. 498 d) If a Web service is provided, the Web security mechanism should be 499 implemented, including checking the validity of input and output, and 500 taking measures to prevent code vulnerabilities such as 501 authentication vulnerabilities, permission vulnerabilities, session 502 vulnerabilities, injection vulnerabilities, file upload 503 vulnerabilities, etc. 505 6.4.4. Session Security 507 a) The smart device should allow the user to initiatively end the 508 communication. 510 b) The session should be ended if there is no operation for a long 511 duration, and the duration time can be set by the administrator. 513 c) The smart device should restrict the address of remote 514 connections, such as IP address filtering, etc. 516 d) Limit the number of concurrent network connections. 518 6.4.5. Transmission Security 520 a) The smart device should provide a trusted communication path (Such 521 as TLS) for the remote user to protect the communication data from 522 leakage. 524 b) Remote users should be allowed to initiate communication via a 525 trusted path. 527 c) A trusted path is required when processing user authentication. 529 d) A trusted path between the device and another trusted IT product 530 should be provided to protect communication data from modification or 531 leakage. 533 6.4.6. Video Stream Protection 535 The smart device should support integrity and confidentiality 536 protection during stream transmission. 538 6.5. Security Management 540 a) The smart device should be able to be managed and configured 541 remotely. 543 b) The smart device should be able to inquire and export log 544 information. 546 c) The smart device should be able to upgrade firmware remotely. 548 d) The smart device should be able to manage activation/non- 549 activation service remotely. 551 e) The smart device should follow a lifetime policy, which clarifies 552 the security risks of overdue and declares that manufacturer will no 553 longer update firmware of the device if overdue. 555 7. Security Considerations 557 This entire memo deals with security issues. 559 8. IANA Considerations 561 This documents has no IANA actions. 563 9. Informative References 565 [Miorandi2012] 566 Miorandi, D., Sicari, S., Pellegrini, F.D., and I. 567 Chlamtac, "Internet of things: Vision, applications and 568 research challenges", 2012, 569 . 571 [Neshenko2019] 572 Neshenko, D., Bou-Harb, E., Crichigno, J., Kaddoum, G., 573 and N. Ghani, "Demystifying IoT Security: An Exhaustive 574 Survey on IoT Vulnerabilities and a First Empirical Look 575 on Internet-Scale IoT Exploitations", 2019, 576 . 578 [Qiu2020] Qiu, J., Tian, Z.h., Du, C.l., Zuo, Q., Su, S., and B.x. 579 Fang, "A Survey on Access Control in the Age of Internet 580 of Things", 2020, 581 . 583 [RFC6568] Kim, E., Kaspar, D., and JP. Vasseur, "Design and 584 Application Spaces for IPv6 over Low-Power Wireless 585 Personal Area Networks (6LoWPANs)", DOI 10.17487/RFC6568, 586 April 2012, . 588 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 589 Application Protocol (CoAP)", DOI 10.17487/RFC7252, June 590 2014, . 592 [RFC7744] Seitz, L., Ed., Gerdes, S., Ed., Selander, G., Mani, M., 593 and S. Kumar, "Use Cases for Authentication and 594 Authorization in Constrained Environments", 595 DOI 10.17487/RFC7744, January 2016, 596 . 598 Authors' Addresses 600 Bin Wang (editor) 601 Hikvision 602 555 Qianmo Road, Binjiang District 603 Hangzhou 604 310051 605 China 607 Phone: +86 571 8847 3644 608 Email: wbin2006@gmail.com 609 Xing Wang (editor) 610 Hikvision 611 555 Qianmo Road, Binjiang District 612 Hangzhou 613 310051 614 China 616 Phone: +86 571 8847 3644 617 Email: xing.wang.email@gmail.com 619 Li Wan (editor) 620 Hikvision 621 555 Qianmo Road, Binjiang District 622 Hangzhou 623 310051 624 China 626 Phone: +86 571 8847 3644 627 Email: dzwanli@126.com 629 Wenyuan Xu (editor) 630 Zhejiang University 631 866 Yuhangtang Rd 632 Hangzhou 633 310058 634 China 636 Email: wyxu@zju.edu.cn 638 Chonghua Wang (editor) 639 IIE, CAS 640 Beijing 641 100093 642 China 644 Phone: +86 185 1894 5987 645 Email: chonghuaw@live.com