Building Trust in a Connected World
A one-size-fits-all policy cannot be adopted for connected security. Vincent Korstanje, Vice President Marketing and Software Systems, ARM, explains how a multi-layer approach to embedded system design is the safest route.
Whether at home, at the office, in the car driving from one to the other, or anywhere in-between, we expect to be connected to the Internet. The number of connected devices per household continues to increase and Strategy Analytics forecasts that the estimated 12 billion Internet connected devices in 2014 will nearly triple, to 33 billion by 2020, or from 1.7 devices per person to 4.3 per person worldwide. On the roads, IHS Automotive estimates that the number of cars connected to the Internet, worldwide, will grow from today’s 23 million to 152 million by 2020 and the number of Internet-connected homes will rise to between 500 million and 700 million in five years’ time.
A connected device, defines Korstanje, is “anything with an IP address and connected to the Internet—this could be cars, mobile phones, IoT devices.” This proliferation of connectivity brings multiple products and services to networked systems, from home entertainment systems to sensor networks controlling environmental conditions.
While connectivity is convenient, it also makes a device vulnerable. Considering that connected devices can range from a sensor on a wall to a server farm or an automated factory, the number of potential targets, and routes to attack those potential targets, is vast. A hacker could be after data, ID, access to the power grid or simply trawling for targets of opportunity. Korstanje observes that “The recent emphasis has been based on economics—whether something is valuable enough to be protected and how easy it is to build that protection.” However, in a fully connected environment, even a seemingly low-value device such as a light bulb can be used as a bridge into more critical systems and data.
For Korstanje, the solution lies in a multi-layered architecture built on a foundation of trusted hardware. Rejecting unauthorized access to that hardware base is critical, but assuming that the system is designed in the right way, safety and security are inherent within each layer. The challenge for design engineers is that they have to find all the bugs in a system during development “whereas the attacker only has to find one.” In a multi-layered system, an attacker has to go through several layers, and breaking through one does not undermine the others (see Figure 1). For Korstanje, this is much like a building’s security, where someone has to get past the security guard at the front desk, the door entry on a particular floor of the building, and through the office to steal the wallet left locked in your desk.
“A device on the Internet means everyone, in theory, could access it, leading to different classes of attacks,” says Korstanje “—hardware, software and communications attacks.” A system approach, where the CPU has a protective hardware infrastructure around it, then software and communications layers (see sidebar: ARM adds new layer of security), makes security sense.
For the operating system, a hypervisor offers an additional layer of protection, says Korstanje. A hypervisor with hardware support separates large pieces of code, keeping the OS in ‘containers’. This is used by Android for example, to keep work and personal data separate on a single device. It is also a popular approach with real-time operating systems used in avionics and military systems.
A further layer of protection is a certifiable Trusted Execution Environment (TEE), located inside an application processor and isolated from the Rich Execution Environment through hardware. The TEE hosts trusted Applications for use by higher layers of software in Rich Execution Environment (REE). And a TEE can be securely and physically isolated from the REE with ARM® TrustZone® technology to protect key functions against software attacks.
ARM takes a system-wide approach with TrustZone technology, explains Korstanje. Integrated into the ARM processor, TrustZone will provide the hardware platform for a Trusted Execution Environment (TEE) where, as described by Korstanje, trusted applications will run on top of a trusted OS. These applications can be written by different service providers. The TEE can load Trusted Applications (e.g. Digital Rights Management (DRM) applications from a company such as Netflix, or a Payment application from a company such as China Union Pay). The Trusted OS in TrustZone is separate from the main OS. The Trusted Applications perform tasks that require isolation and complete trust, such as decrypting an encryption key or collecting authentication and identity materials.
Earlier this year, ARM bought IoT security software company, Offspark. The company specializes in IoT communications security. Its PolarSSL is an embedded Transport Layer Security (TLS) technology that is used in sensor modules, communication modules and smartphones. Following the acquisition in February 2015, the technology will remain open source, assures the company, but will be re-branded as ARM mbed™ TLS and be made available for standalone use and as part of mbed OS to support TLS and Datagram Transport Layer Security (DTLS) communications protocols.
Another acquisition this summer was that of Israel’s Sansa Security, a hardware security IP and SoC software provider. The company currently enables over 150 million IoT products a year, across smart connected devices and enterprise systems. It isolates security operations from the main application processor.
ARM TrustZone separates the CPU state of the trusted domain from other tasks and thus secures peripherals from software attack, says Korstanje. A single, physical processor executes code from both the Rich Execution Environment (i.e. running the OS) and the Trusted Execution Environment (i.e. running a trusted OS, trusted applications and a system monitor).
A root of trust is the starting point (Figure 3) for a secure system. This code is the most trusted and can never be changed. It forms the basis of the security system, with knowledge of the operating system code and its identity. Security based in hardware cannot be changed, maintains Korstanje. A root of trust runs digital code to set up the device and performs a trusted boot of the TEE and then the REE to check that all the connections are correct, identifying any known bugs or vulnerabilities, he continues.
Having an industry standard “chain” makes designing a secure system easy, says Korstanje, who also believes that the ARM ecosystem has the technology and expertise to help developers create the secure connected world.