ETSI 303-645
ETSI EN 303 645, also known as “Cyber Security for Consumer Internet of Things: Baseline Requirements,” is a standard developed by the European Telecommunications Standards Institute (ETSI).
The standard includes provisions for secure software updates, data protection, secure communication, and the minimization of exposed attack surfaces, among other things. It is part of a broader effort to address the challenges and risks associated with IoT devices.
Full version of the standard can be found here.
Terminology
administrator |
user who has the highest-privilege level possible for a user of the device, which can mean they are able to change any configuration related to the intended functionality. |
associated services |
digital services that, together with the device, are part of the overall consumer IoT product and that are typically required to provide the product’s intended functionality. |
authentication mechanism |
method used to prove the authenticity of an entity. |
authentication value |
individual value of an attribute used by an authentication mechanism. |
best practice cryptography |
cryptography that is suitable for the corresponding use case and has no indications of a feasible attack with current readily available techniques. |
constrained device |
device which has physical limitations in either the ability to process data, the ability to communicate data, the ability to store data or the ability to interact with the user, due to restrictions that arise from its intended use. |
consumer |
natural person who is acting for purposes that are outside her/his trade, business, craft or profession. |
consumer IoT device |
network-connected (and network-connectable) device that has relationships to associated services and are used by the consumer typically in the home or as electronic wearables. |
critical security parameter |
security-related secret information whose disclosure or modification can compromise the security of a security module. |
debug interface |
physical interface used by the manufacturer to communicate with the device during development or to perform triage of issues with the device and that is not used as part of the consumer-facing functionality |
defined support period |
minimum length of time, expressed as a period or by an end-date, for which a manufacturer will provide security updates. |
device manufacturer |
entity that creates an assembled final consumer IoT product, which is likely to contain the products and components of many other suppliers. |
factory default |
state of the device after factory reset or after final production/assembly. |
initialization |
process that activates the network connectivity of the device for operation and optionally sets authentication features for a user or for network access. |
initialized state |
state of the device after initialization. |
IoT product |
consumer IoT device and its associated services. |
isolable |
able to be removed from the network it is connected to, where any functionality loss caused is related only to that connectivity and not to its main function; alternatively, able to be placed in a self-contained environment with other devices if and only if the integrity of devices within that environment can be ensured |
logical interface |
software implementation that utilizes a network interface to communicate over the network via channels or ports. |
manufacturer |
relevant economic operator in the supply chain (including the device manufacturer). |
network interface |
physical interface that can be used to access the functionality of consumer IoT via a network. |
owner |
user who owns or who purchased the device. |
personal data |
Any information relating to an identified or identifiable natural person. |
physical interface |
physical port or air interface (such as radio, audio or optical) used to communicate with the device at the physical layer. |
public security parameter |
security related public information whose modification can compromise the security of a security module. |
remotely accessible |
intended to be accessible from outside the local network. |
security module |
set of hardware, software, and/or firmware that implements security functions. |
security update |
software update that addresses security vulnerabilities either discovered by or reported to the manufacturer. |
sensitive security parameters |
critical security parameters and public security parameters. |
software service |
software component of a device that is used to support functionality. |
telemetry |
data from a device that can provide information to help the manufacturer identify issues or information related to device usage. |
unique per device |
unique for each individual device of a given product class or type. |
user |
natural person or organization. |
Provisions Assessment
The following table is a self-assessment using Table B.1 from ETSI EN 303 645, specifically focusing on the Zephyr RTOS as a component within IoT products.
According with ETSI 303 645, table B.1 provides a mechanism to give information about the implementation of the provisions presented in the standard. Zephyr has adopted the following notations used in the standard:
M |
the provision is a mandatory requirement |
R |
the provision is a recommendation |
M C |
the provision is a mandatory requirement and conditional |
R C |
the provision is a recommendation and conditional |
Y |
The provision is supported by Zephyr |
N |
The provision is not supported by Zephyr |
N/A |
The provision is not applicable to Zephyr or it is product makers responsibility |
Provision |
Description |
Status |
Support |
Detail |
|---|---|---|---|---|
Provision 5.1-1 |
Where passwords are used and in any state other than the factory default, all consumer IoT device passwords shall be unique per device or defined by the user. |
M C |
N/A |
|
Provision 5.1-2 |
Where pre-installed unique per device passwords are used, these shall be generated with a mechanism that reduces the risk of automated attacks against a class or type of device. |
M C |
N/A |
|
Provision 5.1-3 |
Authentication mechanisms used to authenticate users against a device shall use best practice cryptography, appropriate to the properties of the technology, risk and usage. |
M |
N/A |
|
Provision 5.1-4 |
Where a user can authenticate against a device, the device shall provide to the user or an administrator a simple mechanism to change the authentication value used. |
M C |
N/A |
|
Provision 5.1-5 |
When the device is not a constrained device, it shall have a mechanism available which makes brute-force attacks on authentication mechanisms via network interfaces impracticable. |
M C |
N |
TODO |
Provision 5.2-1 |
The manufacture shall make a vulnerability disclosure policy publicly available. |
M |
Y |
|
Provision 5.2-2 |
Disclosed vulnerabilities should be acted on in a timely manner. |
R |
Y |
|
Provision 5.2-3 |
Manufacturers should continually monitor for, identify and rectify security vulnerabilities within products and services they sell, produce, have produced and services they operate during the defined support period. |
R |
Y |
Modules are covered |
Provision 5.3-1 |
All software components in consumer IoT devices should be securely updatable. |
R |
Y |
|
Provision 5.3-2 |
When the device is not a constrained device, it shall have an update mechanism for the secure installation of updates. |
M C |
Y |
|
Provision 5.3-3 |
An update shall be simple for the user to apply. |
M C |
N/A |
|
Provision 5.3-4 |
Automatic mechanisms should be used for software updates. |
R C |
N/A |
|
Provision 5.3-5 |
The device should check after initialization, and then periodically, whether security updates are available. |
R C |
N/A |
|
Provision 5.3-6 |
If the device supports automatic updates and/or update notifications, these should be enabled in the initialized state and configurable so that the user can enable, disable, or postpone installation of security updates and/or update notifications. |
R C |
N/A |
|
Provision 5.3-7 |
The device shall use best practice cryptography to facilitate secure update mechanisms. |
M C |
Y |
|
Provision 5.3-8 |
Security updates shall be timely. |
M C |
N/A |
|
Provision 5.3-9 |
The device should verify the authenticity and integrity of software updates. |
R C |
Y |
Functionality provided by MCUboot <https://github.com/zephyrproject-rtos/mcuboot>. Also see Device Firwmware Upgrade |
Provision 5.3-10 |
Where updates are delivered over a network interface, the device shall verify the authenticity and integrity of each update via a trust relationship. |
M |
N/A |
|
Provision 5.3-11 |
The manufacturer should inform the user in a recognizable and apparent manner that a security update is required together with information on the risks mitigated by that update. |
R C |
N/A |
|
Provision 5.3-12 |
The device should notify the user when the application of a software update will disrupt the basic functioning of the device. |
R C |
N/A |
Zephyr provides this information for its updates. Anyone using Zephyr in their products must check if they are affected |
Provision 5.3-13 |
The manufacturer shall publish, in an accessible way that is clear and transparent to the user, the defined support period. |
M |
Y |
|
Provision 5.3-14 |
For constrained devices that cannot have their software updated, the rationale for the absence of software updates, the period and method of hardware replacement support and a defined support period should be published by the manufacturer in an accessible way that is clear and transparent to the user. |
R C |
N/A |
|
Provision 5.3-15 |
For constrained devices that cannot have their software updated, the product should be isolable and the hardware replaceable. |
R C |
N/A |
|
Provision 5.3-16 |
The model designation of the consumer IoT device shall be clearly recognizable, either by labelling on the device or via a physical interface. |
M |
N/A |
|
Provision 5.4-1 |
Sensitive security parameters in persistent storage shall be stored securely by the device. |
M |
N |
There is not secure storage within Zephyr |
Provision 5.4-2 |
Where a hard-coded unique per device identity is used in a device for security purposes, it shall be implemented in such a way that it resists tampering by means such as physical, electrical or software. |
M C |
N/A |
|
Provision 5.4-3 |
Hard-coded critical security parameters in device software source code shall not be used. |
M |
Y |
|
Provision 5.4-4 |
Any critical security parameters used for integrity and authenticity checks of software updates and for protection of communication with associated services in device software shall be unique per device and shall be produced with a mechanism that reduces the risk of automated attacks against classes of devices. |
M |
N/A |
|
Provision 5.5-1 |
The consumer IoT device shall use best practice cryptography to communicate securely. |
M |
Y |
|
Provision 5.5-2 |
The consumer IoT device should use reviewed or evaluated implementations to deliver network and security functionalities, particularly in the field of cryptography. |
R |
Y |
|
Provision 5.5-3 |
Cryptographic algorithms and primitives should be updatable. |
R |
N |
The whole image must be updated |
Provision 5.5-4 |
Access to device functionality via a network interface in the initialized state should only be possible after authentication on that interface. |
R |
N/A |
|
Provision 5.5-5 |
Device functionality that allows security-relevant changes in configuration via a network interface shall only be accessible after authentication. The exception is for network service protocols that are relied upon by the device and where the manufacturer cannot guarantee what configuration will be required for the device to operate. |
M |
N/A |
|
Provision 5.5-6 |
Critical security parameters should be encrypted in transit, with such encryption appropriate to the properties of the technology, risk and usage. |
R |
Y |
|
Provision 5.5-7 |
The consumer IoT device shall protect the confidentiality of critical security parameters that are communicated via remotely accessible network interfaces. |
M |
Y |
|
Provision 5.5-8 |
The manufacturer shall follow secure management processes for critical security parameters that relate to the device. |
M |
N/A |
|
Provision 5.6-1 |
All unused network and logical interfaces shall be disabled. |
M |
Y |
|
Provision 5.6-2 |
In the initialized state, the network interfaces of the device shall minimize the unauthenticated disclosure of security-relevant information. |
M |
Y |
|
Provision 5.6-3 |
Device hardware should not unnecessarily expose physical interfaces to attack. |
R |
Y |
|
Provision 5.6-4 |
Where a debug interface is physically accessible, it shall be disabled in software. |
M C |
Y |
|
Provision 5.6-5 |
The manufacturer should only enable software services that are used or required for the intended use or operation of the device. |
R |
Y |
|
Provision 5.6-6 |
Code should be minimized to the functionality necessary for the service/device to operate. |
R |
Y |
|
Provision 5.6-7 |
Software should run with least necessary privileges, taking account of both security and functionality. |
R |
Y |
|
Provision 5.6-8 |
The device should include a hardware-level access control mechanism for memory. |
R |
Y |
|
Provision 5.6-9 |
The manufacturer should follow secure development processes for software deployed on the device. |
R |
Y |
|
Provision 5.7-1 |
The consumer IoT device should verify its software using secure boot mechanisms. |
R |
Y |
Functionality provided by MCUboot <https://github.com/zephyrproject-rtos/mcuboot>. Also see Security Overview |
Provision 5.7-2 |
If an unauthorized change is detected to the software, the device should alert the user and/or administrator to the issue and should not connect to wider networks than those necessary to perform the alerting function. |
R |
N |
Zephyr does not provide runtime detection / notification. |
Provision 5.8-1 |
The confidentiality of personal data transiting between a device and a service, especially associated services, should be protected, with best practice cryptography. |
R |
Y |
|
Provision 5.8-2 |
The confidentiality of sensitive personal data communicated between the device and associated services shall be protected, with cryptography appropriate to the properties of the technology and usage. |
M |
Y |
|
Provision 5.8-3 |
All external sensing capabilities of the device shall be documented in an accessible way that is clear and transparent for the user. |
M |
Y |
|
Provision 5.9-1 |
Resilience should be built in to consumer IoT devices and services, taking into account the possibility of outages of data networks and power. |
R |
Y |
|
Provision 5.9-2 |
Consumer IoT devices should remain operating and locally functional in the case of a loss of network access and should recover cleanly in the case of restoration of a loss of power. |
R |
Y |
|
Provision 5.9-3 |
The consumer IoT device should connect to networks in an expected, operational and stable state and in an orderly fashion, taking the capability of the infrastructure into consideration. |
R |
Y |
|
Provision 5.10-1 |
If telemetry data is collected from consumer IoT devices and services, such as usage and measurement data, it should be examined for security anomalies. |
R C |
N/A |
|
Provision 5.11-1 |
The user shall be provided with functionality such that user data can be erased from the device in a simple manner. |
M |
N/A |
|
Provision 5.11-2 |
The consumer should be provided with functionality on the device such that personal data can be removed from associated services in a simple manner. |
R |
N/A |
|
Provision 5.11-3 |
Users should be given clear instructions on how to delete their personal data. |
R |
N/A |
|
Provision 5.11-4 |
Users should be provided with clear confirmation that personal data has been deleted from services, devices and applications. |
R |
N/A |
|
Provision 5.12-1 |
Installation and maintenance of consumer IoT should involve minimal decisions by the user and should follow security best practice on usability. |
R |
N/A |
|
Provision 5.12-2 |
The manufacturer should provide users with guidance on how to securely set up their device. |
R |
N/A |
|
Provision 5.12-3 |
The manufacturer should provide users with guidance on how to check whether their device is securely set up. |
R |
N/A |
|
Provision 5.13-1 |
The consumer IoT device software shall validate data input via user interfaces or transferred via Application Programming Interfaces (APIs) or between networks in services and devices. |
M |
Y |
|
Provision 6.1-1 |
The manufacturer shall provide consumers with clear and transparent information about what personal data is processed, how it is being used, by whom, and for what purposes, for each device and service. This also applies to third parties that can be involved, including advertisers. |
M |
N/A |
|
Provision 6.1-2 |
Where personal data is processed on the basis of consumers’ consent, this consent shall be obtained in a valid way. |
M C |
N/A |
|
Provision 6.1-3 |
Consumers who gave consent for the processing of their personal data shall have the capability to withdraw it at any time. |
M |
N/A |
|
Provision 6.1-4 |
If telemetry data is collected from consumer IoT devices and services, the processing of personal data should be kept to the minimum necessary for the intended functionality. |
R C |
N/A |
|
Provision 6.1-5 |
If telemetry data is collected from consumer IoT devices and services, consumers shall be provided with information on what telemetry data is collected, how it is being used, by whom, and for what purposes. |
M C |
N/A |