Outlook 2016: Creating a strong chain

The world is getting more and more connected. And it’s not just the devices you’d expect, such as smartphones, tablets and digital cameras; the burgeoning Internet of Things (IoT) will mean billions of devices will be capable of talking to each other.

While this vast amount of connectivity is taking many apps to a new level, this larger attack surface – all the different points where access could be gained – is opening things up to those looking to abuse the system.

Security is only as good as the weakest link in the chain; and ensuring security is much harder for those developing products than it is for those looking to ‘hack’ into them. If you’re a manufacturer, you have to find all the potential weaknesses in your system; hackers, by contrast, only need to find one weak point in the system in order to break in. To make things harder for hackers, those designing security into electronic products need to adopt a layered approach; with multiple layers, hackers have to find multiple weaknesses before they can gain entry. Developers also need to look at security from end of the chain to the other in order to make sure there are no back doors.

So what is the weakest link in the security chain? You might think it’s going to be hardware or software, but it’s the future. The IoT will have billions of devices connected to each other and many of these devices will be built by people who may not have experience of working within a supply chain.

Having established what the weakest link is, what can be done to strengthen it? Security systems often fail because of a lack of awareness of the issues and a lack of skills to deal with those issues. The recent ‘hack’ in the US, where control of the car was taken from the driver, was a wake up call; not only for the automotive industry, but also for anyone involved in security. Since that event, awareness of security – and its importance – has grown significantly.

Scaling is a problem

Scaling is another problem. While there are plenty of good security solutions available, can they scale? In other words, are the solutions capable of being deployed in huge numbers across a range of market sectors?

What solutions does ARM have to these security issues? It’s what we call a four compartment solution which can be used by silicon developers and product developers alike to protect valuable assets from attack. The four compartments – a rich domain, a protected domain, a trusted domain and a secure domain – combine not only to protect content, but also to ensure the user experience remains unaffected.

The latter factor is critical: if you’re looking to stream video to a handheld device, you don’t want that process affected by security procedures. Solutions, therefore, not only have to be strong, they also have to be invisible. And it’s the same if you’re looking to use your handheld device for online transactions – PayPal, for example.

But not every application requires the highest level of security. Device developers might want to include the kinds of security you might expect to find at Fort Knox, but those levels of security are hard to carry around. So there is an economic aspect to the levels of security you build into a system. If the value of what you’re looking to protect is relatively low, you may not want to use the same kind of security as you would for something more valuable.

These are economic judgements and hackers will make the same decisions: if it’s not economic to hack a target, they are less likely to attempt to.

Consider a system with public and private keys. In a properly designed public-private key encryption scheme, with every device having its own private key, hacking the private key will only give access to one device. In a more simplistic scheme, where devices share a key – very often encountered in symmetric encryption schemes – hacking the key will give access to a whole class of device.

Sensitive to risk

So, while the system needs to be secure, it needs to be sensitive to the degree of risk you are prepared to take – it’s a trade off between attack area, device performance and usability.

The four compartments in ARM’s solution relate to performance needs and the likelihood of attack. In a server farm, for example, you may not worry so much about a physical attack, but you would worry about a software or communications attack. In consumer electronics – tablets and phones, for example – performance is important, so you want the device to be responsive. Larger systems may be more vulnerable to physical attack, with the performance ‘hit’ being of less relevance.

Consider the ‘attack surface’ for a system. The largest attack surface is provided by applications and operating systems, which may comprise gigabytes of software. As you move along the chain, the attack surface gets smaller until you reach hardware, where it may only be a matter of kilobytes.

ARM has developed the TrustZone Trusted Execution Environment (TEE) to provide mobile devices with integrated hardware security. TEE brings together a hardware root of trust, secure peripheral access and secure application execution.

TrustZone technology has three steps. The first is to define a secure hardware architecture, with ‘normal’ and ‘secure’ domains separated from each other. This architecture is then implemented in an SoC, with a hardware root of trust. The SoC is then combined with trusted software to create a TEE (also called Trusted OS).

However, at some point, your system is going to need to know who it is ‘talking’ to. Currently, many systems rely on passwords, but these are getting longer and more complicated. It might be better to use something like a fingerprint or even an iris scan.

That’s one of the approaches being taken by the FIDO Alliance – Fast Identity Online. The Alliance has developed protocols that enable simple, but strong, authentication between users and providers, underpinned by secure hardware.

FIDO has two approaches, both based on public key cryptography. In the passwordless approach, users register their device via a biometric input – such as a fingerprint or iris scan. Once registered, the user no longer needs a password when using that device.

The second approach is based on the Universal Second Factor protocol. Here, an existing password is reinforced by a strong second factor, such a pressing a button on a secure dongle.

TEE can provide trusted services for the FIDO protocol via a Trusted OS, handling cryptography and algorithms in a hardware protected environment. The Trusted OS is part of the boot and operates before the device’s OS is booted. However, TEE needs only to house part of the software stack – the Trusted App. Security keys, as well as biometrics, can be encrypted in hardware and only decrypted and used within TEE.

Systems need to be protected against man-in-the-middle attacks, software attacks and hardware attacks. Developers need to remember that security cannot be added to a system as an afterthought; it needs to be designed in at the earliest opportunity.