Five Considerations for Developing Secure Devices in the IoT
Firma zum Thema
2. Adopt a Secure Platform Architecture
Thing platform security starts with a hardware root of trust, below all software. A hardware root of trust, in its simplest embodiment, is a tamper resistant key storage used, at a minimum, for secure boot of the firmware and associated security-critical components.
The boot sequence must utilize hardware-rooted keys to signature check these components before launching them. Subsequently, the hardware root of trust can be used also for remote attestation and for protection of keys used for authentication and encryption. If an attacker attempts to overwrite critical software with malicious code, the attestation process will detect it.
Once securely launched, the executive software (operating system, hypervisor, or TEE) is arguably the most important building block for secure Things. One cannot build secure applications or Things on top of an insecure operating system or hypervisor. Ideally, this software root of trust has the following characteristics:
- High assurance: design and implementation certifiable to the most stringent security standards (e.g. Common Criteria EAL 7), including formal proof of security
- Scalable: able to host lightweight, real-time workloads up to full blown Linux operating systems and stacks (and both at the same time)
- Open: offering a run-time environment and APIs that follow open standards, fostering interoperability and software reuse
The platform architecture principles described above give developers a powerful toolbox with which to build secure IoT systems. To demonstrate, let’s take a look at the Target Corporation (the second-largest discount retailer in the United States) breach and how it could have been easily prevented. Target (and The Home Depot, the largest home improvement retailer in the United States) PoS terminals were infiltrated by malware, which was able to gain privilege and memory scrape RAM to purloin personal information.
An evolved PoS architecture would use a de-privileged OS and a lightweight security critical application, called the tokenizer, to handle the processing of personal information. The tokenizer executes directly on a Thingvisor, a high assurance microkernel-based hypervisor, and manages the physical device used for card swipe. The tokenizer uses a secure connection to a back-end web service for mapping personal records to tokenized records and then issues a virtual card swipe, passing the token, to the PoS OS. While the OS may be infiltrated with malware, it has no personal information to steal.
The overall Thingvisor-based point-of-sale architecture is shown in Figure 1 and has been demonstrated at the NRF Big Show (US National Retail Federation's Annual Convention & EXPO); while Target may have missed out on the concept, it is not too late for Target and other retailers to require such a trustworthy approach of its PoS suppliers going forward.
The IoT is attracting an incredibly diverse set of new Thing developers, many of whom have limited professional embedded systems development experience. A typical scenario is to acquire a cheap Arduino, Raspberry Pi, or some other hardware platform, download some distribution of Linux or one of the mini-kernels (Contiki, TinyOS, RIOT) for a battery-powered design, and start slinging code.