The IoT will enable tremendous improvements in many aspects of human life. With opportunity, however, comes a tremendous responsibility for Things developers: keep our data private!
The vast potential of the Internet of Things is threatened by several imposing challenges and Thing developers bear the burden of meeting many of them: • How can designers properly care for the privacy, safety and security of the information and functions entrusted to their Things? • How can a new breed of Thing developers, many with little or no professional embedded software experience, build reliable, efficient and secure products? • How can even the most experienced embedded developers navigate the technical and business maze involved in integrating their Things into the Cloud? While the challenges are daunting, Thing developers that navigate them successfully will be handsomely rewarded. Adopt a zero trust data privacy strategy One of the fallacies in IoT security is that solutions providers can focus their investment on cloud security and essentially ignore the security of things on the edge. This is dangerous thinking in the cloud era and downright folly in the IoT era: attackers search for the weakest link and if Things remain weakly protected, they will be targeted. Once a Thing is commandeered, attackers can use it to gain access to the data centres. Another fallacy is that there is not much worth protecting on the edge. Things generate a treasure trove of valuable information – including our health, our social activities, our location – and present a valuable target for hackers. As the IoT grows, it is not practical for developers to know how data will flow across the web nor the trustworthiness of various systems along the way. Developers and their customers must adopt a zero trust strategy, which divorces data protection responsibilities from devices, communications protocols and cloud services. Similar to the content protection problem for digital media, IoT data owners must have the tools required to create flexible policies for authorised sharing of data, regardless of how it transits the web. For example, a wearable health care device may encrypt information generated locally with a key that is controlled by the device owner and shared only with healthcare providers that have a need to know. Adopt a secure platform architecture Thing platform security starts with a hardware root of trust: in its simplest embodiment, a tamper resistant key storage used, at a minimum, for secure boot of the firmware and associated security-critical components. The boot sequence must use hardware rooted keys to validate these components before launching them. Subsequently, the root of trust can be used for remote attestation and protection of keys used for authentication and encryption. Once launched securely, 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 OS or hypervisor. Ideally, this software root of trust has the following characteristics: • High assurance: design and implementation certifiable to the most stringent security standards (for example, Common Criteria EAL 7), including formal proof of security • Scalable: able to host lightweight, real time workloads up to complete Linux stacks (and both at the same time) • Open: offering a run time environment that follows open standards, fostering interoperability and software reuse These platform architecture principles give developers a powerful toolbox with which to build secure IoT systems. To demonstrate, let's take a look at the Target breach – the second largest discount retailer in the US – and how it could have been easily prevented. Target point of sale (PoS) terminals were infiltrated by malware, which was able to gain privilege and memory scrape RAM to purloin personal information. An evolved PoS architecture uses a deprivileged 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 PoS architecture has been demonstrated at the US National Retail Federation's Big Show; while Target may have missed out on the concept, it is not too late for Target and other retailers to require a trustworthy approach of its PoS suppliers going forward. Adopt professional development tools The IoT is attracting a diverse set of new Thing developers; many of whom have limited professional embedded development experience. A typical scenario is to acquire a cheap Arduino, Raspberry Pi or similar prototyping platform, download some distribution of Linux or one of the mini kernels (Contiki, TinyOS, RIOT) for a battery powered design and start 'slinging' code. Many developers have no clue how to debug effectively (print statements is state of the art) and follow no rigorous process for developing a reliable product. This approach might work for hobby projects, but will fail when moving to large scale production or addressing markets that demand a high level of quality (including ISO 26262 for automotive and IEC 61508 for industrial, government medical device approval). When looking for a professional development environment, it is critical to find a solution that is easy to learn and use. Do not underestimate the long term impact of an optimised development, testing and maintenance cycle. For example, choosing a microprocessor that provides JTAG debugging and run time trace capabilities to help find complicated bugs faster may provide a huge developer cost and time to market benefit that often goes unappreciated in hardware selections focused on CPU cycles, RAM size and BOM dollars. Adopt Linux, carefully Some of the most popular Things, such as the Nest Thermostat and various smartwatches, run Linux. With its open source licensing and widespread availability of developers and applications, Linux has an important position in the run time strategy for IoT. However, Linux has problems scaling to lower end designs (footprint, battery life), real time limitations and lacks the safety and security pedigree one needs in a future-proofed IoT strategy. Here is where the Thingvisor wins again. Thingvisor converts Linux into a IoT optimised version of Linux, in which Linux runs atop the software root of trust. For example, in automotive Things, safety critical software (CAN drivers, rear-view camera, ADAS) may be hosted on the microkernel, while Linux is used for graphics and communications stacks. Adopt a web oriented communications strategy Many middleware solutions are staking a claim to be the information exchange backbone of the IoT. Competing consortia, such as AllSeen and Open Interconnect Consortium, and the myriad of protocol choices – MQTT, XMPP, AMQP, COAP, DDS – present a confusing alphabet soup for Thing developers. Factors to consider include the communications model (pubsub, peer-to-peer, client-server), service discovery model, data representation, overwrite versus queue, dependence upon reliable transport (TCP), quality of service (QoS) capabilities and more. A comprehensive discussion of these options is beyond the scope of this article. Ultimately, however, most devices will use the lingua franca of the web, RESTful web services via HTTP and COAP (for constrained wireless devices), because they enable Things to integrate more quickly and seamlessly into the Web. We find ourselves in the midst of an exciting time, when the number of objects has recently eclipsed the number of people (PCs, smartphones) on the web. Yet this is just the beginning of a world in which the Internet will be dominated by smart objects making our lives better and yielding incredible business opportunities for Thing developers, especially those that approach their craft with an effective, future proof strategy. Green Hills Software Founded in 1982, Green Hills Software is the largest independent software vendor for the Internet of Things. In 2008, the Green Hills INTEGRITY-178 RTOS was the first and only operating system to be certified by NIAP (National Information Assurance Partnership comprised of NSA and NIST) to EAL 6+, High Robustness, the highest level of security ever achieved for any software product. Our open architecture integrated development solutions address deeply embedded, absolute security and high-reliability applications for the military/avionics, medical, industrial, automotive, networking, consumer and other markets that demand industry-certified solutions. Green Hills Software is headquartered in Santa Barbara, CA, with European headquarters in the United Kingdom. David Kleidermacher is chief technology officer of Green Hills Software.