Intel’s chief security architect Ernie Brickell laid out the processor maker’s view of what hardware designers need to do to create SoCs that build in good protection against hacks in his keynote address at the 51st Design Automation Conference (DAC) in San Francisco.
“Why is security hard?” Brickell asked. “Because we are building very complex systems. Due to market demand we have to rapidly add new capabilities to these systems.”
Sometimes the capabilities are so rich that they open up users’ personal information without even needing to be hacked. Brickell used the example of the Goldenshores Technologies Brightest Flashlight app available for smartphones. At one level, it was just a way of turning a phone into a torch. “But it also collected GPS information and sent that back so that it could send targeted ads,” said Brickell.
The app made it more or less impossible to opt out of the sending of data, one of the reasons why the US Federal Trade Commission (FTC) stepped in to force Goldenshores to stop the collection and delete consumer data.
Problems like this arise, Brickell said, “because we are not giving users reasonable things to choose from”.
Image Intel's Ernie Brickell speaking at DAC 2014
When it comes to breaking into applications and operating systems, Brickell said hackers are finding more and more ways to do it as the potential value of attacks, thanks to the desire to add financial applications to computers and mobile devices, increases. “Macafee is saying they find a thousand new pieces of malware a day.”
Hardware can help reduce the flood of malware and other problems, said Brickell. “We currently can’t solve the entire problem but it’s also not appropriate to say it’s purely a software problem. The first thing to do is not introduce security bugs ourselves.”
Intel’s security development lifecycle
Intel has adopted a security lifecycle model, Brickell explained. “The way to do security for a complex system is to determine what are the assets you are trying to protect, and then ask how can I design this architecture to have the absolute smallest attack surface.”
“The first question to answer is ‘does this product have any security objectives?’ The next step is the architecture review. This is the forum I run at Intel. Architects come to this forum to describe what are the security objectives of this platform.”
The review attempts to enumerate the many possible means of attack, with specialists providing insights on what is possible. “One person on the committee specializes in the security of debug. We need debug but we also need to make sure that the debug facilities don’t compromise security.”
Once the architecture has been reviewed and recommendations made, the next step in the lifecycle is actual implementation. “We find most security problems are injected during implementation. So we need to do thorough code reviews during implementation. Then there is a final review before shipping.”
A common theme in designing for security at Intel is a focus on the attack surface. “In software you find the principle of least privilege. That’s a fine way to think about things. But in security you have to think about things from different viewpoints because that’s what attackers do,” Brickell explained. “To have a small attack surface sounds simple but it takes people to get their heads around it.”
Questions of trust
The key is to ensure that individual components do not have inappropriate privileges or access. “You don’t want to give GPS data to your flashlight app. But with a mapping app you do. But you don’t then want to trust your mapping app with banking information. It’s not that you are saying you don’t trust the mapping app entirely. You are simply trying to minimize the attack surface around each asset.
“If you ask data-center owners, do they trust their admins? They say: ‘Yes. But we would like to trust them less’,” Brickell said.
“You can’t always have a small attack surface around assets. So there you want to work with software companies to reduce the risk of vulnerabilities,” Brickell explained.
Intel is steadily building in protection functions to limit the damage that malware can do once it gains a foothold in the system through a vulnerability. One example is physical damage from an overheated system. “We want to make sure that if malware gets on the machine, the malware can’t run the silicon out of range and damage it. We have applied the principle of reducing the attack surface to this problem. So, power management only takes a small set of instructions and operations. We also put checkpoints on the power and voltage sensors so that if they go out of bounds the system is stopped and shut down.”
This behavior works for corporate PCs and servers but Brickell added: “We have a market where people want to overclock and run out of range. We market those Extreme systems but keep them separate.
Protecting apps from the OS
The protection mechanisms are going further. “We not only want to protect data from attackers without system privileges who have gained kernel privilege. The first technology we worked on for this was virtualization. This has been out for several years. Here you can put in a hypervizor and then run a separate virtual machine. In practice it doesn’t always work very well.
“The next thing we did was put in a separate security processor where we can run a separate operating system. This is now in PCs, tablets and phones. It runs with its own memory space that is protected from the [main] operating system.
“We are now doing research on security through software guard extensions,” said Brickell, an approach that takes the attack-surface minimization technique into software applications themselves. “An app could be quite large if it’s something like a browser or word processor. Software guard extensions give any app the ability to defend secrets. The app has a brick wall around the part of it that it wants to secure.
“Say you want to perform financial transactions within the browser. The part that is protected has the smallest attack surface possible. The app writer can still write bad software and put in vulnerabilities to buffer-overflow attacks, but he knows that the security is only dependent on what he wrote, [not the underlying operating system]. It will be very useful for the data center to provide situations where even the admins don’t have access.
“We’re not going to get rid of malware,” said Brickell. But it is possible to stop it damaging the system, he claimed. “If you look at the lifecycle of malware. Once it is on the platform it tries to get higher privileges. Then it tries to extend its life, storing its code on the disk. Then it goes after compromising the target. We try to make each step in that lifecycle more difficult for the malware to achieve.
“One of the most common software vulnerabilities is buffer overflow. It would be easy to say ‘It’s a software problem, what can we do [as hardware engineers]? But we can put into the processor bounds checks, so the processor can effectively remove buffer overflow as an attack vector.
“There are some attacks that put code in ring three [low privilege] in user space then find a vulnerability in the kernel and then run that ring-three code from ring zero [kernel privilege]. We put in capabilities to remove that attack vector,” Brickell claimed, citing it as another way to reduce the overall attack surface of the system.
As a summary, Brickell provided a to-do list for hardware vendors:
- Don’t introduce security bugs
- Identify critical assets
- Design architectures so that each asset has the smallest possible attack surface
- Work with OEMs and software companies to implement solutions that minimize the attack surface
- For assets with a large attack surface, help software companies reduce the risk of vulnerabilities
- Build solid security primitives for use by software.