ARM calls for Internet Protocol to the edge in security play
ARM CTO Mike Muller put forward the company’s view of how security needs to be addressed in IoT designs at a recent NMI seminar at the former code-breaking station of Bletchley Park in the UK, arguing that the Internet Protocol needs to go right to the edge even for those devices that might not have a direct connection to the network.
In-built support for cryptography and the ability to perform secure firmware updates are two of the features that Muller presented as being crucial to the design of devices in the field that can avoid being permanently compromised by a successful attack.
“The ugly truth is that, as a designer you have to find all the flaws in the system and the attacker just one. You will fail. So you have to plan for that failure,” Muller said. “You have to build systems on the assumption they will get hacked. It means you have to be able to refresh them. But you give up security at the beginning, you will never get it back.
Device pwned?
“I’m less worried that the data is stolen. I’m worried about the device being stolen. Once a hacker owns it, it’s game over. You can only trust the big data if you can trust the little data, and that depends on the device,” Muller added.
“There are whole new classes of attacks out there, such as new types of denial-of-service attack. All it does is flatten the battery on a device.”
The device also needs mechanisms to make sure security updates stick, Muller said: “You have to get to the root of insecure firmware updates: stop people doing spoof rollbacks. How you manage and control firmware updates is a key part of making these systems scale.”
As well as having enough power to deal with security and reflashing, support for the internet protocol (IP) will be important to all devices, Muller argued: “I believe in IP to the edge. I believe we need to trust in Moore’s Law. Even today, MCUs that can handle IP stacks costs less than $1.”
Connection by proxy
“Even devices that don’t have access to the internet, you can architect them so they can,” said Muller, using the example of an electronic door lock activated by a mobile device such as a phone.
A key problem for this type of device is ensuring it opens the door only to people who still have a valid pass. But how can the lock check that this is the case if it does not have access to the servers that contain the list of valid and revoked security certificates used to demonstrate identity? Muller’s solution is to tunnel through to them using the phone of the person trying to open the door.
“This is all channel independent. It’s the responsibility of the device to determine whether it has a secure channel,” said Muller. But in common with other speakers at the seminar he argued that well-known protocols developed for the internet already exist that can be used and offer better long-term protection than homebrew options.
ARM has chosen to build its upcoming secure version of mBed OS around the IP stack and its SSL/TLS encryption protocol to try to prevent eavesdropping and impersonation. The company aims to provide a degree of hardware support for this for microcontrollers based on its architecture that will enable the running of a secure partition ARM calls the ‘crypto box’, analogous to the SIM of a mobile phone where all cryptographically sensitive operations are carried out.
Privacy split
“The aim is to split memory into private and public non-critical areas. The private area has a smaller footprint to allow exhaustive verification. The public code operates on crypto secrets using defined APIs but is never allowed access to raw keys. And you use hardware memory protection to keep the two separate. You hope flaws are in the public side and not in the other, but you can change the public side faster while the private side is slow and stable.
“ARM bought a TLS stack and cut it up into three bits. A lot of the SSL is on the application side,” Muller explained, with the other components either in the non-hardware protected OS partition and the sensitive components isolated by the crypto box.
In common with the approach recommended by Green Hills Software and others, the approach is designed to minimize the amount of software that needs to be exhaustively verified for flaws.
“It’s all about reducing the attack surface on any one device,” said Muller, adding that the approach can make, in his view, secure design more accessible.
“Very few developers have an understanding of security. We need to change [the approach] and provide a lot of security for you. We can’t take the software community and turn them all into security experts. We need to remove from them the security choices they have to make. It’s bad in that it takes away choice but good in that reducing the number of options and getting it right. Rather than knowing most will get it wrong if they get no help,” he argued.
Squeezed resources
He added device developers will not have much room to manoeuvre in terms of resources: “I don’t believe there is any money in end-client devices. It’s not an area where you can make money. Products are going from being dumb products to being provided as part of a service. There isn’t money there. It’s where margin is being squeezed out.“
But he maintained that device makers will see a need to add the more heavyweight processing needed for for IP stack and absorb its cost. “I believe the cost of putting this in is low. In my view it is the cost of doing business. The incremental cost is cents, as well as time and effort.
“You have to look at who is buying. If it’s a service the hardware comes for free. It’s not going to take many incidents for brand owners to say ‘I can’t afford to be embarrassed’. People with a brand will say they can’t tolerate that level of embarrassment.”
Muller conceded that providing the core components will not prevent poor security from being implemented if developers ignore the guidelines. But existing and new classes of attack will focus attention on security practices. He pointed to the adoption of practices based on the ISO 26262 standard in the autmotive industry. “What we do in automotive today we may have to do in IoT in the future. We will see requirements for higher levels of quality in software development.”
