1.. _etsi_303645: 2 3ETSI 303-645 4############ 5 6 7**ETSI EN 303 645**, also known as "Cyber Security for Consumer Internet 8of Things: Baseline Requirements," is a standard developed by the 9European Telecommunications Standards Institute (ETSI). 10 11The standard includes provisions for secure software updates, data 12protection, secure communication, and the minimization of exposed 13attack surfaces, among other things. It is part of a broader effort to 14address the challenges and risks associated with IoT devices. 15 16Full version of the standard can be found `here <https://www.etsi.org/deliver/etsi_en/303600_303699/303645/02.01.01_60/en_303645v020101p.pdf>`_. 17 18 19Terminology 20*********** 21 22.. list-table:: ETSI 303645 terminology 23 :widths: 17 43 24 25 * - administrator 26 - user who has the highest-privilege level possible for a user of the device, 27 which can mean they are able to change any configuration related to the intended 28 functionality. 29 30 * - associated services 31 - digital services that, together with the device, are part of the overall consumer 32 IoT product and that are typically required to provide the product's intended 33 functionality. 34 35 * - authentication mechanism 36 - method used to prove the authenticity of an entity. 37 38 * - authentication value 39 - individual value of an attribute used by an authentication mechanism. 40 41 * - best practice cryptography 42 - cryptography that is suitable for the corresponding use case and has no 43 indications of a feasible attack with current readily available techniques. 44 45 * - constrained device 46 - device which has physical limitations in either the ability to process data, the 47 ability to communicate data, the ability to store data or the ability to interact 48 with the user, due to restrictions that arise from its intended use. 49 50 * - consumer 51 - natural person who is acting for purposes that are outside her/his trade, 52 business, craft or profession. 53 54 * - consumer IoT device 55 - network-connected (and network-connectable) device that has relationships to 56 associated services and are used by the consumer typically in the home or as 57 electronic wearables. 58 59 * - critical security parameter 60 - security-related secret information whose disclosure or modification can compromise 61 the security of a security module. 62 63 * - debug interface 64 - physical interface used by the manufacturer to communicate with the device during 65 development or to perform triage of issues with the device and that is not used as part 66 of the consumer-facing functionality 67 68 * - defined support period 69 - minimum length of time, expressed as a period or by an end-date, for which a 70 manufacturer will provide security updates. 71 72 * - device manufacturer 73 - entity that creates an assembled final consumer IoT product, which is likely to contain 74 the products and components of many other suppliers. 75 76 * - factory default 77 - state of the device after factory reset or after final production/assembly. 78 79 * - initialization 80 - process that activates the network connectivity of the device for operation and 81 optionally sets authentication features for a user or for network access. 82 83 * - initialized state 84 - state of the device after initialization. 85 86 * - IoT product 87 - consumer IoT device and its associated services. 88 89 * - isolable 90 - able to be removed from the network it is connected to, where any functionality loss 91 caused is related only to that connectivity and not to its main function; alternatively, 92 able to be placed in a self-contained environment with other devices if and only if the 93 integrity of devices within that environment can be ensured 94 95 * - logical interface 96 - software implementation that utilizes a network interface to communicate over the network 97 via channels or ports. 98 99 * - manufacturer 100 - relevant economic operator in the supply chain (including the device manufacturer). 101 102 * - network interface 103 - physical interface that can be used to access the functionality of consumer IoT via a network. 104 105 * - owner 106 - user who owns or who purchased the device. 107 108 * - personal data 109 - Any information relating to an identified or identifiable natural person. 110 111 * - physical interface 112 - physical port or air interface (such as radio, audio or optical) used to communicate with the 113 device at the physical layer. 114 115 * - public security parameter 116 - security related public information whose modification can compromise the security of a 117 security module. 118 119 * - remotely accessible 120 - intended to be accessible from outside the local network. 121 122 * - security module 123 - set of hardware, software, and/or firmware that implements security functions. 124 125 * - security update 126 - software update that addresses security vulnerabilities either discovered by or reported 127 to the manufacturer. 128 129 * - sensitive security parameters 130 - critical security parameters and public security parameters. 131 132 * - software service 133 - software component of a device that is used to support functionality. 134 135 * - telemetry 136 - data from a device that can provide information to help the manufacturer identify issues 137 or information related to device usage. 138 139 * - unique per device 140 - unique for each individual device of a given product class or type. 141 142 * - user 143 - natural person or organization. 144 145Provisions Assessment 146********************* 147 148 The following table is a self-assessment using Table B.1 from ETSI EN 149 303 645, specifically focusing on the Zephyr RTOS as a component 150 within IoT products. 151 152 According with ETSI 303 645, table B.1 provides a mechanism to give information 153 about the implementation of the provisions presented in the standard. Zephyr has 154 adopted the following notations used in the standard: 155 156.. list-table:: ETSI 303645 Table B.1 notations 157 :widths: 17 43 158 159 * - M 160 - the provision is a mandatory requirement 161 162 * - R 163 - the provision is a recommendation 164 165 * - M C 166 - the provision is a mandatory requirement and conditional 167 168 * - R C 169 - the provision is a recommendation and conditional 170 171 * - Y 172 - The provision is supported by Zephyr 173 174 * - N 175 - The provision is not supported by Zephyr 176 177 * - N/A 178 - The provision is not applicable to Zephyr or it is product makers responsibility 179 180.. raw:: latex 181 182 \begin{landscape} 183 184.. list-table:: ETSI 303645 provisions assessment using table B.1 185 :header-rows: 1 186 :widths: 25 80 15 15 60 187 188 * - Provision 189 - Description 190 - Status 191 - Support 192 - Detail 193 194 .. _ETSI_Provision_5_1_1: 195 * - Provision 5.1-1 196 - Where passwords are used and in any state other than the 197 factory default, all consumer IoT device passwords shall be 198 unique per device or defined by the user. 199 - M C 200 - N/A 201 - 202 203 .. _ETSI_Provision_5_1_2: 204 * - Provision 5.1-2 205 - Where pre-installed unique per device passwords are used, 206 these shall be generated with a mechanism that reduces the 207 risk of automated attacks against a class or type of device. 208 - M C 209 - N/A 210 - 211 212 .. _ETSI_Provision_5_1_3: 213 * - Provision 5.1-3 214 - Authentication mechanisms used to authenticate users against a 215 device shall use best practice cryptography, appropriate to 216 the properties of the technology, risk and usage. 217 - M 218 - N/A 219 - 220 221 .. _ETSI_Provision_5_1_4: 222 * - Provision 5.1-4 223 - Where a user can authenticate against a device, the device 224 shall provide to the user or an administrator a simple 225 mechanism to change the authentication value used. 226 - M C 227 - N/A 228 - 229 230 .. _ETSI_Provision_5_1_5: 231 * - Provision 5.1-5 232 - When the device is not a constrained device, it shall have a 233 mechanism available which makes brute-force attacks on 234 authentication mechanisms via network interfaces 235 impracticable. 236 - M C 237 - N 238 - **TODO** 239 240 .. _ETSI_Provision_5_2_1: 241 * - Provision 5.2-1 242 - The manufacture shall make a vulnerability disclosure policy publicly 243 available. 244 - M 245 - Y 246 - :ref:`Vulnerability Management <reporting>` 247 248 .. _ETSI_Provision_5_2_2: 249 * - Provision 5.2-2 250 - Disclosed vulnerabilities should be acted on in a timely manner. 251 - R 252 - Y 253 - :ref:`Vulnerability Timeline <vulnerability_timeline>` 254 255 .. _ETSI_Provision_5_2_3: 256 * - Provision 5.2-3 257 - Manufacturers should continually monitor for, identify and rectify security 258 vulnerabilities within products and services they sell, produce, have produced 259 and services they operate during the defined support period. 260 - R 261 - Y 262 - `Modules <https://github.com/zephyrproject-rtos/>`_ are covered 263 264 .. _ETSI_Provision_5_3_1: 265 * - Provision 5.3-1 266 - All software components in consumer IoT devices should be securely updatable. 267 - R 268 - Y 269 - :ref:`Device firwmware upgrade <dfu>` 270 271 .. _ETSI_Provision_5_3_2: 272 * - Provision 5.3-2 273 - When the device is not a constrained device, it shall have an update mechanism 274 for the secure installation of updates. 275 - M C 276 - Y 277 - :ref:`Device firwmware upgrade <dfu>` 278 279 .. _ETSI_Provision_5_3_3: 280 * - Provision 5.3-3 281 - An update shall be simple for the user to apply. 282 - M C 283 - N/A 284 - 285 286 .. _ETSI_Provision_5_3_4: 287 * - Provision 5.3-4 288 - Automatic mechanisms should be used for software updates. 289 - R C 290 - N/A 291 - 292 293 .. _ETSI_Provision_5_3_5: 294 * - Provision 5.3-5 295 - The device should check after initialization, and then periodically, whether 296 security updates are available. 297 - R C 298 - N/A 299 - 300 301 .. _ETSI_Provision_5_3_6: 302 * - Provision 5.3-6 303 - If the device supports automatic updates and/or update notifications, these 304 should be enabled in the initialized state and configurable so that the user 305 can enable, disable, or postpone installation of security updates and/or 306 update notifications. 307 - R C 308 - N/A 309 - 310 311 .. _ETSI_Provision_5_3_7: 312 * - Provision 5.3-7 313 - The device shall use best practice cryptography to facilitate secure update mechanisms. 314 - M C 315 - Y 316 - :ref:`West Sign <west-sign>` 317 318 .. _ETSI_Provision_5_3_8: 319 * - Provision 5.3-8 320 - Security updates shall be timely. 321 - M C 322 - N/A 323 - 324 325 .. _ETSI_Provision_5_3_9: 326 * - Provision 5.3-9 327 - The device should verify the authenticity and integrity of software updates. 328 - R C 329 - Y 330 - Functionality provided by `MCUboot <https://github.com/zephyrproject-rtos/mcuboot>`_. 331 Also see :ref:`Device Firwmware Upgrade <dfu>`. 332 333 .. _ETSI_Provision_5_3_10: 334 * - Provision 5.3-10 335 - Where updates are delivered over a network interface, the device shall verify 336 the authenticity and integrity of each update via a trust relationship. 337 - M 338 - N/A 339 - 340 341 .. _ETSI_Provision_5_3_11: 342 * - Provision 5.3-11 343 - The manufacturer should inform the user in a recognizable and apparent manner 344 that a security update is required together with information on the risks 345 mitigated by that update. 346 - R C 347 - N/A 348 - 349 350 .. _ETSI_Provision_5_3_12: 351 * - Provision 5.3-12 352 - The device should notify the user when the application of a software update 353 will disrupt the basic functioning of the device. 354 - R C 355 - N/A 356 - Zephyr provides this information for its updates. Anyone using Zephyr in their products must check if they are affected 357 358 .. _ETSI_Provision_5_3_13: 359 * - Provision 5.3-13 360 - The manufacturer shall publish, in an accessible way that is clear and 361 transparent to the user, the defined support period. 362 - M 363 - Y 364 - :ref:`Release Life Cycle and Maintenance <zephyr_release_cycle>` 365 366 .. _ETSI_Provision_5_3_14: 367 * - Provision 5.3-14 368 - For constrained devices that cannot have their software updated, the rationale 369 for the absence of software updates, the period and method of hardware replacement 370 support and a defined support period should be published by the manufacturer in an 371 accessible way that is clear and transparent to the user. 372 - R C 373 - N/A 374 - 375 376 .. _ETSI_Provision_5_3_15: 377 * - Provision 5.3-15 378 - For constrained devices that cannot have their software updated, the product 379 should be isolable and the hardware replaceable. 380 - R C 381 - N/A 382 - 383 384 .. _ETSI_Provision_5_3_16: 385 * - Provision 5.3-16 386 - The model designation of the consumer IoT device shall be clearly recognizable, 387 either by labelling on the device or via a physical interface. 388 - M 389 - N/A 390 - 391 392 .. _ETSI_Provision_5_4_1: 393 * - Provision 5.4-1 394 - Sensitive security parameters in persistent storage shall be stored securely by the device. 395 - M 396 - N 397 - There is not secure storage within Zephyr 398 399 .. _ETSI_Provision_5_4_2: 400 * - Provision 5.4-2 401 - Where a hard-coded unique per device identity is used in a device for security purposes, 402 it shall be implemented in such a way that it resists tampering by means such as physical, 403 electrical or software. 404 - M C 405 - N/A 406 - 407 408 .. _ETSI_Provision_5_4_3: 409 * - Provision 5.4-3 410 - Hard-coded critical security parameters in device software source code shall not be used. 411 - M 412 - Y 413 - :ref:`Hardening Tool <hardening>` 414 415 .. _ETSI_Provision_5_4_4: 416 * - Provision 5.4-4 417 - Any critical security parameters used for integrity and authenticity checks of software 418 updates and for protection of communication with associated services in device software 419 shall be unique per device and shall be produced with a mechanism that reduces the risk 420 of automated attacks against classes of devices. 421 - M 422 - N/A 423 - 424 425 .. _ETSI_Provision_5_5_1: 426 * - Provision 5.5-1 427 - The consumer IoT device shall use best practice cryptography to communicate securely. 428 - M 429 - Y 430 - 431 432 .. _ETSI_Provision_5_5_2: 433 * - Provision 5.5-2 434 - The consumer IoT device should use reviewed or evaluated implementations to deliver 435 network and security functionalities, particularly in the field of cryptography. 436 - R 437 - Y 438 - 439 440 .. _ETSI_Provision_5_5_3: 441 * - Provision 5.5-3 442 - Cryptographic algorithms and primitives should be updatable. 443 - R 444 - N 445 - The whole image must be updated 446 447 .. _ETSI_Provision_5_5_4: 448 * - Provision 5.5-4 449 - Access to device functionality via a network interface in the initialized state should 450 only be possible after authentication on that interface. 451 - R 452 - N/A 453 - 454 455 .. _ETSI_Provision_5_5_5: 456 * - Provision 5.5-5 457 - Device functionality that allows security-relevant changes in configuration via a 458 network interface shall only be accessible after authentication. The exception is for 459 network service protocols that are relied upon by the device and where the manufacturer 460 cannot guarantee what configuration will be required for the device to operate. 461 - M 462 - N/A 463 - 464 465 .. _ETSI_Provision_5_5_6: 466 * - Provision 5.5-6 467 - Critical security parameters should be encrypted in transit, with such encryption 468 appropriate to the properties of the technology, risk and usage. 469 - R 470 - Y 471 - 472 473 .. _ETSI_Provision_5_5_7: 474 * - Provision 5.5-7 475 - The consumer IoT device shall protect the confidentiality of critical security 476 parameters that are communicated via remotely accessible network interfaces. 477 - M 478 - Y 479 - 480 481 .. _ETSI_Provision_5_5_8: 482 * - Provision 5.5-8 483 - The manufacturer shall follow secure management processes for critical security 484 parameters that relate to the device. 485 - M 486 - N/A 487 - 488 489 .. _ETSI_Provision_5_6_1: 490 * - Provision 5.6-1 491 - All unused network and logical interfaces shall be disabled. 492 - M 493 - Y 494 - :ref:`Kconfig <kconfig>` 495 496 .. _ETSI_Provision_5_6_2: 497 * - Provision 5.6-2 498 - In the initialized state, the network interfaces of the device shall minimize the 499 unauthenticated disclosure of security-relevant information. 500 - M 501 - Y 502 - 503 504 .. _ETSI_Provision_5_6_3: 505 * - Provision 5.6-3 506 - Device hardware should not unnecessarily expose physical interfaces to attack. 507 - R 508 - Y 509 - :ref:`Kconfig <kconfig>` and :ref:`Hardening Tool <hardening>` 510 511 .. _ETSI_Provision_5_6_4: 512 * - Provision 5.6-4 513 - Where a debug interface is physically accessible, it shall be disabled in software. 514 - M C 515 - Y 516 - :ref:`Hardening Tool <hardening>` 517 518 .. _ETSI_Provision_5_6_5: 519 * - Provision 5.6-5 520 - The manufacturer should only enable software services that are used or required for 521 the intended use or operation of the device. 522 - R 523 - Y 524 - :ref:`Kconfig <kconfig>` and :ref:`Hardening Tool <hardening>` 525 526 .. _ETSI_Provision_5_6_6: 527 * - Provision 5.6-6 528 - Code should be minimized to the functionality necessary for the service/device to operate. 529 - R 530 - Y 531 - :ref:`Kconfig <kconfig>` 532 533 .. _ETSI_Provision_5_6_7: 534 * - Provision 5.6-7 535 - Software should run with least necessary privileges, taking account of both security 536 and functionality. 537 - R 538 - Y 539 - :ref:`Security Overview <security-overview>` 540 541 .. _ETSI_Provision_5_6_8: 542 * - Provision 5.6-8 543 - The device should include a hardware-level access control mechanism for memory. 544 - R 545 - Y 546 - :ref:`Memory protection <memory_domain>` 547 548 .. _ETSI_Provision_5_6_9: 549 * - Provision 5.6-9 550 - The manufacturer should follow secure development processes for software deployed on 551 the device. 552 - R 553 - Y 554 - :ref:`Security Overview <security-overview>` and :ref:`Coding guidelines <coding_guidelines>` 555 556 .. _ETSI_Provision_5_7_1: 557 * - Provision 5.7-1 558 - The consumer IoT device should verify its software using secure boot mechanisms. 559 - R 560 - Y 561 - Functionality provided by `MCUboot <https://github.com/zephyrproject-rtos/mcuboot>`_. 562 Also see :ref:`Security Overview <west-sign>`. 563 564 .. _ETSI_Provision_5_7_2: 565 * - Provision 5.7-2 566 - If an unauthorized change is detected to the software, the device should alert the 567 user and/or administrator to the issue and should not connect to wider networks than 568 those necessary to perform the alerting function. 569 - R 570 - N 571 - Zephyr does not provide runtime detection / notification. 572 573 .. _ETSI_Provision_5_8_1: 574 * - Provision 5.8-1 575 - The confidentiality of personal data transiting between a device and a service, 576 especially associated services, should be protected, with best practice cryptography. 577 - R 578 - Y 579 - 580 581 .. _ETSI_Provision_5_8_2: 582 * - Provision 5.8-2 583 - The confidentiality of sensitive personal data communicated between the device and 584 associated services shall be protected, with cryptography appropriate to the 585 properties of the technology and usage. 586 - M 587 - Y 588 - 589 590 .. _ETSI_Provision_5_8_3: 591 * - Provision 5.8-3 592 - All external sensing capabilities of the device shall be documented in an accessible 593 way that is clear and transparent for the user. 594 - M 595 - Y 596 - :ref:`sensing` 597 598 .. _ETSI_Provision_5_9_1: 599 * - Provision 5.9-1 600 - Resilience should be built in to consumer IoT devices and services, taking into 601 account the possibility of outages of data networks and power. 602 - R 603 - Y 604 - 605 606 .. _ETSI_Provision_5_9_2: 607 * - Provision 5.9-2 608 - Consumer IoT devices should remain operating and locally functional in the case of a 609 loss of network access and should recover cleanly in the case of restoration of a 610 loss of power. 611 - R 612 - Y 613 - 614 615 .. _ETSI_Provision_5_9_3: 616 * - Provision 5.9-3 617 - The consumer IoT device should connect to networks in an expected, operational and 618 stable state and in an orderly fashion, taking the capability of the infrastructure 619 into consideration. 620 - R 621 - Y 622 - 623 624 .. _ETSI_Provision_5_10_1: 625 * - Provision 5.10-1 626 - If telemetry data is collected from consumer IoT devices and services, such as usage 627 and measurement data, it should be examined for security anomalies. 628 - R C 629 - N/A 630 - 631 632 .. _ETSI_Provision_5_11_1: 633 * - Provision 5.11-1 634 - The user shall be provided with functionality such that user data can be erased from 635 the device in a simple manner. 636 - M 637 - N/A 638 - 639 640 .. _ETSI_Provision_5_11_2: 641 * - Provision 5.11-2 642 - The consumer should be provided with functionality on the device such that personal 643 data can be removed from associated services in a simple manner. 644 - R 645 - N/A 646 - 647 648 .. _ETSI_Provision_5_11_3: 649 * - Provision 5.11-3 650 - Users should be given clear instructions on how to delete their personal data. 651 - R 652 - N/A 653 - 654 655 .. _ETSI_Provision_5_11_4: 656 * - Provision 5.11-4 657 - Users should be provided with clear confirmation that personal data has been deleted 658 from services, devices and applications. 659 - R 660 - N/A 661 - 662 663 .. _ETSI_Provision_5_12_1: 664 * - Provision 5.12-1 665 - Installation and maintenance of consumer IoT should involve minimal decisions by the 666 user and should follow security best practice on usability. 667 - R 668 - N/A 669 - 670 671 .. _ETSI_Provision_5_12_2: 672 * - Provision 5.12-2 673 - The manufacturer should provide users with guidance on how to securely set up their device. 674 - R 675 - N/A 676 - 677 678 .. _ETSI_Provision_5_12_3: 679 * - Provision 5.12-3 680 - The manufacturer should provide users with guidance on how to check whether their 681 device is securely set up. 682 - R 683 - N/A 684 - 685 686 .. _ETSI_Provision_5_13_1: 687 * - Provision 5.13-1 688 - The consumer IoT device software shall validate data input via user interfaces or 689 transferred via Application Programming Interfaces (APIs) or between networks in 690 services and devices. 691 - M 692 - Y 693 - :ref:`Syscall verification <syscall_verification>` and :ref:`Coding guidelines <coding_guidelines>` 694 695 .. _ETSI_Provision_6_1_1: 696 * - Provision 6.1-1 697 - The manufacturer shall provide consumers with clear and transparent information about 698 what personal data is processed, how it is being used, by whom, and for what purposes, 699 for each device and service. This also applies to third parties that can be involved, 700 including advertisers. 701 - M 702 - N/A 703 - 704 705 .. _ETSI_Provision_6_1_2: 706 * - Provision 6.1-2 707 - Where personal data is processed on the basis of consumers' consent, this consent 708 shall be obtained in a valid way. 709 - M C 710 - N/A 711 - 712 713 .. _ETSI_Provision_6_1_3: 714 * - Provision 6.1-3 715 - Consumers who gave consent for the processing of their personal data shall have 716 the capability to withdraw it at any time. 717 - M 718 - N/A 719 - 720 721 .. _ETSI_Provision_6_1_4: 722 * - Provision 6.1-4 723 - If telemetry data is collected from consumer IoT devices and services, the 724 processing of personal data should be kept to the minimum necessary for the 725 intended functionality. 726 - R C 727 - N/A 728 - 729 730 .. _ETSI_Provision_6_1_5: 731 * - Provision 6.1-5 732 - If telemetry data is collected from consumer IoT devices and services, consumers 733 shall be provided with information on what telemetry data is collected, how it is 734 being used, by whom, and for what purposes. 735 - M C 736 - N/A 737 - 738 739.. raw:: latex 740 741 \end{landscape} 742