Intel’s Kill Switch

Once, not so very long ago, the basic idea underlying security strategies for corporations and other organizations was fairly simple.  There was a network “inside” the organization, which contained applications and data used to run the organization.  There was also the “outside” network (meaning, usually, the Internet), which was largely populated with Bad Guys and wild beasts.  In between, there was an organizational firewall, which functioned as a barrier to keep Bad Things from the outside from getting in, and Good Things from the inside from leaking out.  Of course, there was some traffic that had to be passed through the firewall: E-mail, and requests for Web pages and the responses to those requests, for example.  This approach has its potential pitfalls, but it was in theory a relatively tractable problem.

Unfortunately, the world did not stand still, and now that model is seriously outmoded.  We have seen, most recently in the WikiLeaks flap, that small transportable storage devices and media have made it very easy for internal data to slip out, with just a little assistance.  The proliferation of mobile devices, like laptops and smart phones, presents even more problems, since these devices can potentially access the “inside” from the “outside”; furthermore, users often want to store at least a subset of confidential information on them, to use while on the go.  The introduction of many new mobile devices (iThings and others) in the consumer market has also made it harder for IT departments to keep on top of what is being used.   This has led to the introduction of some new security features, especially for devices intended for the corporate market.  Some phones, for example, have a provision that allow their owners to remotely lock the device or delete the contents of its memory, if it is lost or stolen.

According to an article at ThreatPost and a diary entry at the SANS Internet Storm Center, Intel’s new line of processors (code named “Sandy Bridge”) and their associated chip sets will support a new capability called “Anti-Theft” that enables devices built with the chips to be disabled, by being sent a “poison pill”.  This can be triggered in two ways:

• Based on local rules configured into the device.  For example, it might be required that the device “check in” with a network server at least every N hours.
• Set by a remote command sent by an administrator if, for example, the device is reported as stolen.  For devices that incorporate 3G cellular connections, this can be initiated even when the device is powered off.  (It can be turned on remotely via the 3G link.  This is also used to enable administrators to “push” software updates even to devices that are off.)

The disabling action can prevent the device from booting; Intel claims that it can also prevent access to data on an encrypted storage device, even if that device is removed and put in another machine, apparently by deleting part of the cryptographic key information that is stored in non-volatile memory.

Intel also claims, in their white paper [PDF] on the new chipsets, that disabled devices that are recovered can be re-activated without loss of data, in one of two ways:

• By entry of a locally configured pass-phrase stored securely in the device.
• By entry of a “recovery token” that can be generated from the security administration workstation.

Now these capabilities have some obvious attractions from a security viewpoint; but their introduction has also sparked some significant debate.  Capabilities like this are almost always a two-edged sword: being able to disable a stolen device remotely is a plus, but if an attacker figures out how to send a counterfeit “poison pill”, he will have an excellent tool for a denial-of-service attack.  Similarly, being able to re-activate a disabled device is a good thing, but enabling it by means of a locally-configured pass-phrase potentially introduces all the problems associated with passwords (‘123456’, anyone?) that we’ve discussed many times before.

In implementing facilities like this, the devil is always in the details, and it’s all too easy to get the details wrong.  Intel, of course, has the resources and talent to get it right; time will tell whether they succeed.