Global Sources
EE Times-Asia
Stay in touch with EE Times Asia
?
EE Times-Asia > Controls/MCUs
?
?
Controls/MCUs??

How to secure the Internet of Things (Part 2)

Posted: 29 Jan 2015 ?? ?Print Version ?Bookmark and Share

Keywords:IoT? DeepCover? microcontrollers? EEPROM? ROM?

In today's interconnected world, security of electronic devices is a must. There is plenty of evidence [1] to show that when the security of a device on the IoT is compromised, you must be cautious, even suspicious of that device and the whole IoT. You most certainly cannot rely on a hacked device for secure data exchange, processing, or storage.

In Part 1 of this series, we focused on the identification of security risks and argued that the best security is embedded in electronic devices. We emphasized countermeasures, specifically public key-based algorithms.

In Part 2 we concentrate on a secure boot, which is the "root of trust" and the cornerstone of an electronic device's trustworthiness. Note that this discussion assumes that the reader understands the difference between a private and public key in cryptography. You can refer to Part 1 to find plenty of discussion in a Google search of the terms. Here we will demonstrate how device security can be implemented conveniently and how devices can even be updated in the field. The DeepCover secure microcontrollers will serve as trust-enabling example devices to secure the IoT.

Root of trust starts with trusted software
The only solution to protect against attacks that try to breach the casing (i.e., the hardware) of an electronic device is to use a microcontroller that starts executing software from an internal, immutable memory. (Note that not every microcontroller has this setup and capability.) The software stored in the microcontroller is considered inherently trusted (i.e., the root of trust) because it cannot be modified.

Such impregnable protection can be achieved using read-only memory (ROM). Alternatively, flash (EEPROM) memory internal to the microcontroller can also be used to store the root-of-trust software, if suitable security exists. Either there is a fuse mechanism to make this flash memory non-modifiable (as a ROM) once the software has been written into it, or there is a proper authentication mechanism that allows only authorised persons to write the root-of-trust software in flash memory.

If this early software can be modified without control, trust cannot be guaranteed. "Early" means that it is the first piece of software executed when the microcontroller is powered on. Hence the requirement for inherent trustworthiness of this initial software. If this software is trustworthy, then it can be used for verifying the signature of the application before relinquishing the control of the microcontroller. It is like a castle built on strong foundations.

Booting into a secure state
At power-on, the device's microcontroller starts running the root-of-trust code from a trusted location (e.g., ROM, trusted internal flash). This code's primary task is to start the application code after successful verification of its signature. Verification of the signature is done using a public key previously loaded in the microcontroller using Method 1:Self-certification or Method 2:Hierarchical certification (both methods are discussed in Part 1).

These protected microcontrollers can still be used in their usual manner by developers for writing software, loading, and executing the software via JTAG, and debugging. A secure microcontroller does not make development harder.

Methods to guarantee a public key. Public key integrity, authenticity, and identity must all be guaranteed. This can be done in different ways:

Method 1: Self-certification. The recipient of the digital content receives the public key from the sender in person, or the sender transmits the public key in a way that leaves no doubt about the legitimate origin and ownership of the public key. Then this public key (also called a root key) can be trusted, as long as it is stored where it cannot be modified by unauthorised persons.

Method 2: Hierarchical certification. In this method a hierarchy of verifiers guarantees the origin of the public key. Public key infrastructures (PKIs) provide the definitions of such hierarchies. The physical association between a public key and the identity of the key owner is a certificate. Certificates are signed by intermediate entities (i.e., certification authorities) of the PKI hierarchy.

1???2???3???4???5?Next Page?Last Page



Article Comments - How to secure the Internet of Things...
Comments:??
*? You can enter [0] more charecters.
*Verify code:
?
?
Webinars

Seminars

Visit Asia Webinars to learn about the latest in technology and get practical design tips.

?
?
Back to Top