## UEFI

There's been a bit of discussion about UEFI recently, and, in particular, "Window 8 Certification", which means your new computer has UEFI on it and it only boots an operating system which has been pre-approved by Microsoft, unless perhaps, the computer manufacturer has left in some escape mechanism to disable UEFI altogether.

Which is a big problem for those who want the freedom to install whatever operating system they want to on their computers.

You might have noticed that open source software has never made much use of various digital signing schemes to verify software. When your computer tells you that the MSI file you are using to install an application into Microsoft Windows is verified by a digital signature, that application is almost always a proprietary closed-source application. Similar for signed Java applets (if you remember those). So when you do install some open source software, you almost always get a warning saying that it isn't digitally signed, and therefore perhaps can't be trusted. But you install it anyway.

## Keeping Secrets versus Not Keeping Secrets

Signing content with public/private key pairs seems like a clever way to guarantee the integrity of digital data. And if there's one kind of digital data we would want to verify the integrity of, it's operating systems. So digitally signed operating systems, and computers that verify those digital signatures, should be a good thing.

However, there is a basic contradiction between digital signatures and open source.

On the one hand, digital signatures are about secrets. A digital signing key contains a secret, i.e. the private signing key. Someone somewhere is entrusted with keeping that secret. That someone is also entrusted with using the power conferred by their secret both wisely and ethically.

Open source, on the other hand, is all about not having secrets. It is also about not giving special powers to selected individuals or institutions. The open source developer says: "Here is the code I have written, and as author I relinquish all special powers that might have been conferred upon me due to being the author." Free software goes one step further, and says "here is the code, which you are free to change and redistribute, as long as you relinquish those powers yourself, and you pass the requirement to relinquish those special powers on to anyone that you distribute the software to".

Open source software has traditionally made some use of data verification technology, in particular the cryptographic hash. A cryptographic hash, like a digital signature, uses a small amount of data to verify an arbitrary larger amount of data. An important difference is that a cryptographic hash verifies data without there being any secrets.

The downside of cryptographic hashes is that they can only be used to verify existing data, and a hash cannot be used to verify future not-yet-known data. So cryptographic hashes are less convenient that digital signatures. Which means there is a grave danger that we will trade away our freedom, in exchange for a minor convenience. (And it won't be the first time that has happened.)

## Having to Keep Secrets versus Not Wanting to Keep Secrets

Knowing the secret used to verify other people's data gives you power over other people. If you want to have power over other people, which is typically the case when your business model is selling closed-source software, then the costs of keeping that secret will not seem significant.

If you have already decided that you don't want to have that power, because your software is open source, and especially if you don't really have any business model at all (other than perhaps hoping for a bit of kudos due to the greatness of the software you are distributing), then the cost of keeping a secret indefinitely is a cost that you really don't want to pay.

If you are an open source developer, and if there is a need to apply data verification to the software that you distribute, you would much rather that the verification could be done using cryptographic hashing, and not by digital signing.

A recent example of the direct clash between free software and verification using digital signatures is when VLC for iPhone and iPad was pulled from Apple's App Store.

## A Catalogue of Practical Data Verification Technologies

There are actually only two basic types of data verification technology, being the two I have already mentioned:

- Digital signing, using a public/private key pair
- Cryptographic hashing

In other words, if we need to do data verification, then we have to use either cryptographic hashing or digital signatures. There is no known alternative.

## Chaining of Verification Methods

One interesting fact about data verification methods is that any verification method can be used to verify the verification data of any other verification method. In particular:

- A cryptographic hash can be used to verify a digital signing key – this is called a fingerprint.
- A digital signing key can be used to verify a cryptographic hash. In fact, given that all known digital signature algorithms only directly verify relatively small amounts of data, all practical digital signature algorithms use a cryptographic hash to convert the problem of verifying a large amount of data into the problem of verifying a smaller amount of data.
- One digital signing key can be used to verify another digital signing key. This is what happens with SSL certificate chains.
- A cryptographic hash can be used to verify another cryptographic hash, or even a large number of cryptographic hashes. (This can be an efficient way of managing the cryptographic hashing of a file which consists of a large number of component files, where occasionally one component file changes, and you want to be able to efficiently recalculate the overall hash when this happens.)

So it would seem, that whatever choice we make about choice of verification technology, we can "convert" to a different verification technology by chaining the first choice and the second choice together.

But ...

## Whatever verification technology is used, there always has to be a starting point.

Case in point: SSL certicates used to verify the contents of web pages delivered to a web client via HTTPS protocol. In this case there is a somewhat loosely defined set of certificate authorities, which come pre-loaded in your web browser, and, until fairly recently, the default verification algorithm was to treat any one of those certificate authorities as a completely trusted entity.

If we are going to have a system for enforcing verification of the operating system that boots on our computers, we have to decide what starting point gets built into our computers for this purpose.

Which is what UEFI Secure Boot seems to be all about.

## What Open-Source-friendly Secure Boot Would Look Like

Digital signing keys are intrinsically incompatible with open source. So whatever an open-source secure boot system looks like, it cannot have a digital signing key.

In other words, the solution to the "UEFI problem" for Linux cannot be just a matter for substituting Microsoft's public key with some other Linux-friendly public key.

The solution to the UEFI problem is to not start with a signing key at all.

And there is only one alternative to digital signatures, which is cryptographic hashes.

An open-source-friendly secure boot system has to have a cryptographic hash as a starting point.

This cryptographic hash has to be editable by the user, because software always changes, and unlike digital signatures, which give the signing authority the power to verify new digital data files, cryptographic hashes can only be used to verify existing known data. (Unless of course the cryptographic hash is used to verify a digital signing key. However, to fully support the freedom to install any operating system on a computer, a secure boot system should be designed to operate without necessarily requiring the use of any digital signing key anywhere in the verification chain.)

Exactly how verification hashes should be editable is a question of design. That is, how can we design a boot system that is both secure and which gives a computer's owner control over their own computer? Two possible approaches are:

- Any new cryptographic hash for the initial system boot program must be entered into the firmware, one character at a time, as part of pre-boot firmware setup.
- Alternatively, when new system boot software becomes available (and the user chooses an option to install it and apply it on the next system reboot), this is installed in such a manner that the firmware detects it, calculates the hash, and then asks the user if it is acceptable to use that updated version of the boot software.

It is a fact that any secure boot depending on cryptographic hashes is going to be less convenient in some way than a secure boot depending on a digital signing key – given that, in the latter case, all the work is done by the owner of the signing key, and the user just accepts whatever operating system updates are downloaded and verified by the signing key. Whereas, for a cryptographic hash, at some point the user has to be aware that there is a cryptographic hash, which may change, and where they have to verify that change, somehow, for example, verifying an updated hash that has been published by some means independent of internet download, or at least independent of the computer owner's own internet connection.

Some of this inconvenience can be mitigated, for example a user choosing to install Ubuntu with all future updates might be willing to install initial boot software, which includes an Ubuntu public signing key, verify the hash (just once), and thereafter forget about it, unless there is some future security crisis where the initial version of the boot software is found to have security bugs in it, or the Ubuntu signing key somehow gets compromised.

### And in conclusion ...

So, even if we get to the point where secure boot by default depends on a user-editable cryptographic hash, there will still be choices to be made about how software updates are managed.

But what we shouldn't be doing is arguing about which digital signing key is going to be the "root signing key" for all the world's computers.

The only choice which gives control, freedom and security to the computer owner is a secure boot that starts with a cryptographic hash.