*Hardware Security*

•

This category collects recommendations for designing IoT devices based on the Root of Trust (RoT) concept and the characteristics such a component should demonstrate.

A Root of Trust is a unit that consists of a computing engine, low level code and data (e.g., cryptographic keys). It provides security services/features necessary to establish trust and security within the platform it is a part of. Its vital characteristics are *immutability* and predictability—the produced results have to be consistent for the same input data. The hardware implementation of an RoT enables the fulfillment of these conditions [37,38].

A Root of Trust can provide the following independent security services—identification, authentication, confidentiality, integrity and measurement (state of the platform), as well as composite services (relying on the independent ones)—authorization, verification, reporting, secure storage and update.

Unsurprisingly, almost every analyzed document provided some guidance on the hardware role in the security of the final product, ENISA [27] and the GSMA [30] being the most elaborate. It proves that protecting an IoT device must start at the hardware level.

#### *Trust and Integrity Management*

This section focuses on requirements regarding trust establishment and ensuring integrity, which are fundamental to IoT device security.

An inherently trusted, immutable (hardware) Root of Trust is the trust anchor, from which trust is extended to the whole platform through a secure boot process. A Hardware Root of Trust (HWRoT) utilizes its security services to verify the integrity of subsequently executed software modules (a cryptographic signature of code is checked). Verified software modules then become the next *Chain of Trust* elements. If the integrity verification check fails during one of the secure boot stages, the whole process has to be aborted and the system can only be trusted up to the given *Chain of Trust* level. Depending on which advanced capabilities of the system are available at this point, the device might have to reboot, attempt to return into last known secure state or remain as it is, that is, for reporting purposes.

Apart from NIST and IETF/IRTF publications, every considered paper included recommendations on this matter.

#### *Data Protection and Software Design*

This category considers recommendations on data handling and fundamental principles of software architecture. Data confidentiality must be protected through encryption. Additionally, the designer of the system must also ensure that applications processing data operate on minimum privilege and are isolated from each other (e.g., through memory compartmentalization). These subjects were discussed in the majority of analyzed documents.

#### *Device Configuration and Software Update*

The question of software updates is highly stressed in the subject matter. All organizations agree on its importance—a lack of identified vulnerability patching and protection against the latest threats is a large security risk in IoT. Thus, keeping the device up-to-date strongly improves its protection. The capability to *securely* update device software by an authorized entity is a must, preferably this process should be automatic and/or remotely available.

#### *Secure Interfaces and Communication*

This category analyzes guidance on secure communication, starting from interfaces, through protocols, to data. The usage of device interfaces should be configurable and, by default, only those required should be active. Systems should utilize state-of-the-art, standardized security protocols, with emphasis on using the versions that are intended for IoT, if available. The majority of publications stress the necessity for making only intentional and required connections (preceded by mutual authentication of the peers), which are used to transmit confidential and integral data. Recommendations apply to all layers of IoT devices—hardware, firmware and software.

#### *Cybersecurity Event Monitoring and Logging*

Event logging is a key requirement for security managemen<sup>t</sup> in an IoT device and this category summarizes guidelines on this matter. Adequate level of details aids to solve issues with security incidents, while preventing exposure of sensitive information. The confidentiality and integrity of logs must be protected so that they are reliable—only authorized entities should be able to examine them and they should be unmodifiable.

Furthermore, the GSMA suggests creating a reference model of the IoT device behavior and perform anomaly detection—situations when the device erratically reboots, reconnects to the network or sends multiple poorly-formed messages might indicate a security issue.

Only the ioXt Alliance did not offer guidance on this subject.

#### *Cryptography and Key Management*

Each of the evaluated documents provided an insight for this category. It is clearly advised to use standardized, *proven* cryptographic algorithms with secure implementations and sufficient key lengths. Documents highlight the need to support algorithm agility in security protocols—to enable the usage of lightweight cryptography and specialized algorithms for IoT applications, to allow various node types for algorithm and key length negotiation so they can communicate or ensure the ability to change the algorithm or used key length in case it is compromised.

A secure and scalable key managemen<sup>t</sup> policy must be introduced in the IoT system and every IoT device should be provisioned with a *unique* private key (possibly per application, e.g., device identification, code signature, server communication, etc.). With this approach, every device becomes a separate attack surface and the whole system is secure even if one of them is compromised.

#### *Device Identification, Authentication and Strong Default Security*

This section discusses the identity of both the device and its user. The device must be labelled and recognized in a credible way, given that it will operate in a wider network. It should also be protected from undesired access and provide security for user data. As for the software developer and the user, this category includes guidance on password managemen<sup>t</sup> and general authentication procedures.

