Introduction
This document presents comments on Draft ETSI EN 304 634 V1.0.0, which specifies cybersecurity requirements for personal wearable devices.
This draft standard addresses cybersecurity requirements for personal wearable devices, including devices designed for children with parental control functions.
My comments focus on several areas:
Manufacturer responsibilities: Clarifying the situation where one manufacturer supplies hardware or software platforms to another, with some security decisions already fixed in the original design.
Software updates: Defining more precisely when software can be considered immutable, and how manufacturers should handle vulnerabilities in components that cannot be updated.
Authentication and cryptography: Considering alternatives to passwords, which are often impractical on wearable devices, and questioning the use of 112-bit cryptographic security strength.
Data transparency: Adding a requirement to inform users about the categories of data collected, stored and processed by their devices, particularly for products intended for children.
Clarity and consistency: Addressing ambiguous terminology, incorrect references, inconsistent table numbering and non-inclusive language.
Below are our comments on the draft, reproduced as submitted.
This review was made possible thanks to a grant from the CYBERSTAND programme.
Implementation
Comment 1 – 4.5.2 – Manufacturers supplying other manufacturers
The clause does not address manufacturers supplying devices or boards to other manufacturers rather than end users. The final manufacturer decides on the feature set, but some hardware and software security properties are already defined by the original manufacturer, for example the presence of cryptographic keys in the hardware trust anchor.
=> Proposed change:
Include this use case and clarify the responsibilities of the original and final manufacturers.
Comment 2 – 5.3.1 – Informative reference used as a requirement
The clause refers to informative reference [i.5], effectively making it a requirement.
=> Proposed change:
Make the requirement self-contained or change the reference to normative.
Comment 3 – 5.4.3 – Gender-neutral language
The clause refers to the user as “him”. This is not gender-neutral and excludes female users.
=> Proposed change:
Use “the user” or “them” instead.
Comment 4 – 5.4.2 – Unclear security deviations
The expression “deviations due to security” is unclear. Installed security updates should not be removed when restoring the device.
=> Proposed change:
Use “except for installed security updates”. Remove NOTE 1.
Comment 5 – 5.4.6 – Missing reference to monitoring mechanism
The clause refers to a “monitoring mechanism” without specifying where it is defined.
=> Proposed change:
Add a reference to clause 5.14.
Comment 6 – 5.4.8 and 5.4.9 – 112-bit security strength
Why is 112-bit security strength required? This is not aligned with current security recommendations, for example those from ANSSI.
=> Proposed change:
Remove the 112-bit requirement or justify the choice.
Comment 7 – 5.4.10 – Authentication mechanisms
The clause only addresses passwords, not other authentication mechanisms such as biometrics or cryptographic keys. It also does not mention multi-factor authentication.
Password entry, especially with special characters, is often impractical on wearable devices.
=> Proposed change:
Consider non-password authentication mechanisms and multi-factor authentication for access to sensitive data.
Comment 8 – 5.5.1 – Immutability due to technical reasons
“Immutable due to technical reasons” is too broad and could mean almost anything.
=> Proposed change:
Define “technical reasons” in the normative text, not in a NOTE.
If software components cannot be updated, require the manufacturer to document the reason and associated risks in the risk assessment, including how exploitable vulnerabilities in these components will be handled.
Comment 9 – 5.5.2 – Immutability due to security reasons
“Immutable due to security” is too broad and not clearly defined.
=> Proposed change:
Define what may be considered immutable for security reasons. Require the technical documentation to identify such components, justify their immutability and describe how risks from exploitable vulnerabilities will be handled.
Comment 10 – 5.5.2 – Unclear NOTE 1
NOTE 1 is unclear. Does it mean that an application does not provide its own update mechanism because it relies on the operating system?
The manufacturer remains responsible for providing application security updates.
=> Proposed change:
Clarify NOTE 1, distinguishing between providing updates and the mechanism used to install them.
Comment 11 – 5.7.1 – Table numbering and markings
The table numbering is inconsistent: Table 7 follows Table 3. There are also no entries marked [1], only [*].
=> Proposed change:
Correct the table numbering and markings.
Comment 12 – General – Missing data transparency requirement
The document does not require manufacturers to provide users with a clear list of data collected, stored or processed by the device.
This is particularly important for wearable devices, including those intended for children.
=> Proposed change:
Add a requirement to make the categories of collected, stored and processed data available to users, including parents or guardians where applicable.
