A Root of Trust, commonly shortened to RoT, is the foundational security component of a connected device. While precise definitions can vary considerably, a RoT can be described as a set of implicitly trusted functions that the rest of the system or device can use to ensure security; it is the foundation on which a device maker can build their “tower of trust”.
Why is a Root of Trust Important for IoT Security?
As increasing numbers of IoT devices come online, most will be exposed to remote software attacks and some will also need to mitigate hacks where the attacker is physically present. IoT devices that lack adequate security create opportunities for cybercriminals and hackers to brick devices, take them over to form botnets, introduce unauthorized code, steal data, or take advantage in other ways.
Securing IoT devices is essential to protect the device makers reputation with consumers and businesses. Increasingly it is also covered by law, regulation and standards so security cannot be added as an afterthought.
The RoT can provide essential trusted functions such as trusted boot, cryptography, attestation and secure storage. One of the most basic uses of a RoT is to keep private crypto keys (encrypted data) confidential, protected by hardware mechanisms and away from the system software that is easier to hack. The RoT’s secure storage and crypto functions should be able to handle the keys and trusted processing necessary for authentication of the device, verifying claims and encrypting or decrypting data. This functionality is essential for the ecosystem as Cloud Service Providers and OEMs want to know which devices they are talking to when exchanging data, rolling out updates or cryptographically checking and verifying claims made by the device (otherwise known as attestation).
A RoT also provides an important function when a device is switched on. Before the device software and other system software start to run, the device needs to boot and establish the software running is authentic and has not been tampered with. This process is known as trusted boot and is one of the essential functions of a well-designed RoT.
Typically, the RoT is built into modern microcontrollers and application processors and is not accessible directly from outside of the chip. Chip makers combine trusted hardware such as a processing engine, crypto accelerators, fuses, private storage and random number generators with a small amount of trusted software to provide the trusted functions. These trusted functions, and their complexity, are usually hidden behind a software interface so that software developers who are not security experts can use them. Increasingly, chip vendors are providing a reference Root of Trust with their chips to make life easier for device manufacturers.
Choosing an Adequately Secure RoT
One of the first steps an IoT device maker can take is to select a microcontroller or application processor with an adequately secure Root of Trust (RoT) suitable for their end market. That’s easier said than done, how is an OEM to choose a chip knowing it has a RoT that is sufficiently secure for their use case?
PSA Certified provides organizations with an independent security assessment that can be used to help build in the right level of security for connected devices from the ground up. Once the developer has decided the level of protection required for their device by doing a threat model, PSA Certified can help them choose a chip with a suitably secure PSA-RoT.
PSA Certified provides three levels of progressively increasing security robustness and assurance:
- PSA Certified Level 1 ensures good security principles have been used
- PSA Certified Level 2 demonstrates protection against software attacks and requires the PSA-RoT to have passed 25 days of test lab evaluation
- PSA Certified Level 3 increases the sophistication of the attacks and includes analysis of protection against physical and side-channel attacks.
A designer of a connected fridge might decide that a PSA Certified Level 2 chip is suitable, if they choose to use unique keys per device, as this would protect them from the primary threat of a remote software attack.
In contrast, a smart door lock for a home or hotel might need a PSA Certified Level 3 chip to protect against someone using side-channel attacks in the night to open the door.
Device makers who use the PSA-RoT simply have to decide how secure their IoT device needs to be. Questions to consider:
The PSA Root of Trust
The PSA Root of Trust (PSA-RoT) was developed specifically for IoT and designed to assist developers looking to cost-effectively implement IoT security, even on low cost microcontrollers. It provides an easy-to-use security component implemented by most of the world’s leading chip vendors. The PSA-RoT is usually provided by the chip vendor and integrated in their Software Development Kits. It is accessible to platform and device software via a high level, easy-to-use software interface and consists of nine security functions designed to address 10 key security goals.
|PSA Root of Trust Security Functions|
|Initialization||A secure initialization process ensures the authenticity and integrity of the firmware, and prevents firmware installation from unknown sources.|
|Software isolation||Isolation between secure and non-secure processing environments and between PSA-RoT and other executable code prevents outside software from tampering with protected assets.|
|Secure storage||Protects the confidentiality and integrity of assets by preventing access.|
|Firmware update||Verifies the integrity and authenticity of updates before they’re executed, preventing installation of obsolete or external firmware.|
|Secure state||Enters a secure state upon initialization errors or software failure detection—before any exposure of sensitive data—and ensures the correct operation of security functions, protects against programmer errors and the violation of best practices, controls access to services and prevents exploitation of abnormal situations.|
|Cryptography||Uses state-of-the-art cryptographic algorithms to protect assets based on recommendations from national security agencies or academia, preventing the exploitation of cryptographic weaknesses.|
|Attestation||Reports on the identity, firmware measurements and runtime state of the device in order to mitigate impersonation via a cryptographic proof of identity.|
|Audit||Maintains log of security events and allows access and analysis of these logs for authorized users.|
|Debug||Restricts access to debug features by unauthorized users.|