Trying to solve security threats with software doesn’t work. The problem is much bigger and more complex than that.
As the things we use every day get both connected and smarter, the sensitivity and potential damage caused by breaches in security becomes larger. With the new generation of connectedness, we saw a 368% rise in exposed identities last year over the year prior with 552 million leaked identities in 2013, according to the 2014 Internet Security Threat Report.
Weak security is such an issue that researchers have shown simple attacks against cars, security cameras, television, and medical equipment… even baby monitors! Serious security related issues including malware, madware, and ransomware are now showing up dramatically on smart mobile devices such as phones and tablets. Weak security on smart phones has the potential to be a much more serious problem even more than weak security on our credit cards, with the risk of fraud looming large on the horizon with the prospect of moving cards from our wallets into our smartphones.
As chip designers, we have always looked at security from the perspective of the security software requirements. That is, we ask questions such as:
The underlying problem with approaching security from a software requirements perspective is that software just isn’t very secure! Not only is even stable software ripe with bugs and vulnerabilities, savvy attackers know precisely how to inject their own vulnerabilities since software, by definition, is soft, or, rather, changeable. The other concern with software-based security architectures is that software can be penetrated remotely by prospective attackers. This is great for SoC architects and designers, because it is now becoming very clear that really good security starts with the SoC design and architecture. For robust security, hardware is not even enough.
Some of us may wonder how it is that smartphones get ‘jail-broken’ so quickly. The fabless model for making chips has created a very complex supply chain that while highly adaptable, flexible and efficient, lacks security. Counterfeiting and gray markets, in addition to leaks that lead to security issues such as the ability to ‘root’ a device, often stem from crucial leaks of sensitive information that is exposed during the manufacturing process. The security exposure of smart connected devices is increasing dramatically as the amount of sensitive data going into these devices explodes. With the power of the features and capabilities of these smart devices, there is higher business risk and liability for not protecting the management of sensitive data and feature configuration during manufacturing. In short, really good security starts with the SoC architecture and design, robust security continues by securing the manufacturing supply chain and protecting the provisioning of sensitive data and features.
What is strongly needed is an end-to-end connected device services platform that manages the secure provisioning of sensitive data and features across a device’s lifecycle, beginning with the SoC’s design and continuing through all of the manufacturing steps on to the applications and connected life of the device. This is why Rambus Cryptography Research division has introduced a secure provisioning channel from a hosted device service in the cloud to a secure root of trust embedded in the SoC of a connected device. This system has been designed for full device lifecycle services.
As almost everything in our world gets connected with increasing embedded intelligence, security becomes one of our most valued device features. The need for a strong root of trust is now becoming clearer as SoC designers and architects begin to understand that security starts with the SoC device. As a key feature, robust security assures enterprises, end users, and consumers that the powerful capabilities included with these devices may be used safely, stemming the troubling trends from this past year.
Having a HW root of trust is great and all, but if someone is able to bypass all of that security by exploiting buggy SW or weaker passwords, then all that extra HW logic is just going to use up silicon area, burn power, increase production costs. Security is end to end, but shouldn’t we deal with the weakest link first?