Security Vanity: Public Key Crypto for Secure Boot

For the last few months there’s been a bit of chatter about the restrictions Microsoft will be imposing on hardware vendors, requiring them to implement a specific flavor of “secure boot” where the hardware verifies the signature of the bootloader. The claim is that signing code from the hardware up will improve security, especially helping defeat boot loader viruses. This mechanism obviously makes installing other operating systems more difficult. In the case of ARM processors, there are further restrictions, basically preventing manual circumvention.

The responses from the organizations interested in other operating systems and consumer interests have been mixed. Some, like Fedora and Ubuntu, have drafted courses that seem surprisingly compliant, while others, like FSF, don’t seem to be so keen on the idea. Linus provided a fairly apathetic response noting that the proposed method for secure boot doesn’t help security much but probably doesn’t hurt usability that much either. Most of these responses make sense considering the interests they represent.

It may be fine for non-security folk to trust the advice of security professionals when we say that something is necessary for “security”. However, we do ourselves and society a great disservice when we allow security to be used as a cover for actions based in ulterior motives or when we support ineffective controls. Whether you are on the conspiracy theory or the incompetence more likely than malice side of the house, allowing the cause of security to be used recklessly hurts. It hurts our reputation and ability to enact sensible security measures in the future. It hurts the very cause we are professing to support, which for me is securing liberty. For example, I believe it will take years for our society to recognize how harmful the security theater of airport screening is. On the flip side, there has been no coherent demonstration of any significant effect in preventing terrorism, but our efforts have been fabulously effective at magnifying terror.

We have to call out security vanity when we see it. The use of public key crypto (without much of the complementary infrastructure) in secure boot needs to be questioned. Code signing, and digital signatures in general, can add a high degree of trust to computing. However, experience has shown that PKI, and crypto in general, gets busted over time, especially through key disclosure. It only takes one disclosure to cause a serious issue, especially if robust key management regimes are not in place. By design, there will be no practical way keep this PKI up to date without significant effort on the part of the user. No removal of broken root keys, no certificate revocations, etc. So the type of mechanisms that are used for keeping current code signing, SSL, etc up to date can’t apply here. Note that all of these mechanisms for key management are used by necessity—examples of individual keys/certificates being revoked occurs in the wild, even if you exclude really spooky attacks like Stuxnet or the RSA breach. The whole class of things designed to restrict how users use their devices, things like DVD’s CSS and HDCP, illustrate an important principle. It’s not a question of whether these mechanisms can be defeated; it’s a question of whether anyone cares to do it and how long it will take. It doesn’t matter how good the crypto algorithms are in a PKI based secure boot system, if proper key management can’t occur, the system is critically flawed.

If someone is pushing a defective by design security mechanism, are people justified questioning in their motives? I believe so. The purpose of this post isn’t to rant about anti-competitive practices, anti-consumer restrictions on hardware devices, use of “digital locks” laws to inhibit otherwise legal activity, etc. It is to point out that the use of PKI based secure boot is either based in motives other than security or it is based in bad engineering.

Let’s give Microsoft the benefit of the doubt. Let’s say that boot loader viruses are an issue that need to be addressed. At least we believe it is something that could become an issue during the life of the systems that will be shipping in the near future. The question at this point is, why use PKI? Are there alternatives? Granted there aren’t too many options for trust at this level, but I believe there are options. For example, I’ve long thought it would be useful for both desktop and mobile systems to have a small portion of storage which is writable only with a physical switch which would typically be in the read only position. This sort of thing could be really useful for things like bootloaders, which are updated relatively infrequently. You can criticize this approach, and debate whether it’s more likely for a lay person to be able to make the correct decision about when to press the button to make their secure storage area readable or for them to do manual key management, but the point is that there are alternatives. Note that I’ve intentionally ignored the stiffer requirements for ARM devices.

Using public key crypto for secure boot where proper key management cannot occur is a horrible idea. It will not provide security against determined threats over time. It is incumbent on the security community to clarify this, so that an effective solution can be implemented or the true motives can be discussed. The security community cannot tacitly be party to security vanity.