Asaf Ashkenazi of Cryptography Research (now part of Rambus) talked about provisioning devices securely at the recent Linley Mobile & Wearables Conference. The heart of all security and cryptography are keys. Security by obscurity is no security. Keys are used to authenticate the device (is it the device that is meant to be connecting?), to authenticate the server (am I connected to the right cloud?), and to protect data on the device from unauthorized access and unauthorized alteration. So the device needs to get the correct keys into it. But it's not that simple. There is a semiconductor manufacturer who may need to provision the device with keys. The box manufacturer may need to. There is perhaps a service company such as a mobile operator. All these people may need to update keys securely, update the code securely, disable keys that have been compromised, and so on. It is a big problem. Further, these keys cannot all be the same or else each device is identical and cannot be separately authenticated. He started out by explaining the chicken and egg problem that in order to put keys into a device securely, there already need to be a key in the device. But to get that key into the device securely, requires another key...and the problem is obvious. One way to do key provisioning is to put a global key in the device at manufacture (well, really at design time). This key can then be used to provision the device with other keys. At manufacturing time, it can be provisioned with a unique key. That key also needs to be transmitted up into the cloud in some way so that the device, once in the wild, can authenticate itself. This is not ideal. It requires a trusted manufacturing floor (and probably offshore in China or somewhere). There are additional manufacturing costs. Getting the keys up to the cloud requires online service and can itself be a security risk. Easier and cheaper is over-the-air provisioning. But this has a lot of risk. The key is exposed during transmission and the device is not authenticated properly (because it is not yet unique) before being provided with keys. There are also issues with supply chain inflexibility. Cars are going to need keys for security as they become connected, but you are not going to change the way that cars are built. Asaf was asked during the panel about using public key cryptography but he said that only works one way. You put the public key on the device, but the server cannot authenticate the device since everyone has the public key (it is public, after all). Asaf went on to describe the Rambus CryptoManager platform. This is a hardware core that is embedded in a chip manufacturer's SoC to establish a robust root of trust. It uses a small IP block that adds a unique key for each chip manufactured (not sure how this works exactly, it is part of their secret sauce). Then this root of trust can be used to provision unique keys to each SoC during silicon manufacturing and test. The company building the device (smartphone, credit card, etc.) builds the product using the SoC. They do not need to take any steps to provision keys. The service providers can then securely provision keys over the air. The verticals that have this key management problem most acutely are entertainment (digital rights management), banking (mobile payments), and ID. Just as with the InsideSecure solution that Barry Scheidner presented, there are really three levels of security that vary in flexibility and cost: Hardware core Trusted execution engine (TEE) implemented in a protected part of a trusted OS Pure software solution These three techniques get progressively less secure (more open to attack), but also deliver increasing device flexibility. Care needs to be taken with physical and other attacks, too. Differential power analysis (coincidentally a technique discovered by Cryptography Research back when they were independent), for example, that I saw demonstrated at EDPS and wrote about in Anything Beats Attacking the Crypto Directly . His parting comments: "Security is solved. But people make mistakes or cut corners." Next: Piloted Driving: Audi's View Previous: Who Put the Silicon in Silicon Valley?Image may be NSFW.
Clik here to view.
Clik here to view.
