Feature: Software
it is imperative that developers incorporate a secure-by-design approach, protecting devices and networks as they evolve throughout their life.
Essential steps With the many complexities and vulnerabilities within IoT devices, it is crucial to have a foundation for understanding and identifying vulnerabilities and how to safeguard them. Hence, developers must have a robust starting point to work from, and the European Telecommunications Standards Institute (ETSI) is ensuring that engineers have the best tools to fight off threats with its “ETSI EN 303 645 – Cyber Security for Consumer Internet Of Tings: Baseline Requirements” specification, published in June 2020. It brings together best security practices for the whole ecosystem of embedded technology and Internet-connected devices. It outlines several measures that must be taken to guarantee the best protection against cyber threats. From limiting the use of default passwords, to making sure there is a way of reporting vulnerabilities to the manufacturer and ensuring soſtware integrity – these are essential steps to create a solid foundation for eliminating most weak spots and target entry points for attacks. Tis standard is intended to be complemented by others
IoT devices must rely on security-first approach
By Dennis Mattoon, Co-Chair, Trusted Computing Marketing Work Group, and Principal Software Engineer, Microsoft Research
W
ith 127 new IoT devices connecting to the Internet every second, a wave of potential security risks is coming that we must protect against – especially when a typical consumer owns an average of four IoT devices that communicate with
the cloud. As an example, in 2016, the Mirai botnet attack infected over 600,000 IoT devices. If security is an aſterthought for developers, their devices present
a vulnerability for hackers to exploit. Just imagine the personal information a baby monitor or smart fridge can give away. Tus,
26 July/August 2022
www.electronicsworld.co.uk
defining more specific provisions and fully testable and verifiable requirements, such as the principles and technologies set out by the Trusted Computing Group (TCG). Primarily it relies on the Device Identifier Composition Engine (DICE) architecture that combines hardware identity and measurements to help secure the device boot sequence and resist compromise.
Root of Trust Te DICE hardware Root of Trust (RoT) is leveraged for attestation, authentication and certification of soſtware, regardless of the presence of a Trusted Platform Module, which provides an alternative way of achieving RoT. Te boot sequence in devices is oſten organised into layers or stages, and DICE is no different. Beginning early in the boot process, the DICE RoT uses the Unique Device Secret in combination with measurements of the next layer to anchor the device’s trust chain. As the boot progresses, the trust chain is extended using measurements of each layer. Boot layers each receive a DICE secret derived by combining preceding DICE secrets with the measurement of the current layer. Tis means any time there is a variation in a layer, the measurements and secrets for that layer will be different. Tis approach to measurements and secrets has two important
aspects: First, device firmware uses a DICE secret to secure its data and protect it from disclosure, since successfully modifying a layer means that a layer does not receive the same DICE secret. Also, if a flaw is discovered in the firmware, an update will automatically assign a new key to it. Second, the DICE architecture removes sources of compromise
by offering strong attestation of firmware and security, device identity and secure deployment of updates. Tis makes it a great tool for developers and manufacturers of IoT devices, since
Page 1 |
Page 2 |
Page 3 |
Page 4 |
Page 5 |
Page 6 |
Page 7 |
Page 8 |
Page 9 |
Page 10 |
Page 11 |
Page 12 |
Page 13 |
Page 14 |
Page 15 |
Page 16 |
Page 17 |
Page 18 |
Page 19 |
Page 20 |
Page 21 |
Page 22 |
Page 23 |
Page 24 |
Page 25 |
Page 26 |
Page 27 |
Page 28 |
Page 29 |
Page 30 |
Page 31 |
Page 32 |
Page 33 |
Page 34 |
Page 35 |
Page 36 |
Page 37 |
Page 38 |
Page 39 |
Page 40 |
Page 41 |
Page 42 |
Page 43 |
Page 44 |
Page 45 |
Page 46 |
Page 47 |
Page 48 |
Page 49 |
Page 50 |
Page 51 |
Page 52
