[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Proposal for stage-1 boot loader for use with SecureBoot [Re: [Long] UEFI support]

The fundamental problem we must solve is allowing the *user* to securely choose which OS she wants to install. Whether that OS follows thru and verifies all its parts is between the user and the person or group who provided the OS (could be the user, herself, of course!)

We need a "stage-1" boot loader, signed by somebody trusted (FSF? SFLC?) with a key that will be recognized by the SecureBoot BIOS. This is an un-changable binary blob, so it can't be GPL (is this a problem?) but at least we can publish the source code, and anybody who wants to can verify that the blob is the result of compiling that source code. Whoever did the original signing can publish signed updated blobs in the future if changes become necessary or desirable. Hopefully, the limited functionality in the original version will be enough to get the job done so changes will be infrequent to non- existent.

The stage-1 boot loader blob has the following functionality:

1) It can ask the user to enter a password, which it hashes into a the private half of a cryptographic signing key. Without the user's password, the private half of the key is unknowable. The public half of the key is, of course, freely available and should be cached in some kind of write-once/read-many memory if such is available (You can buy USB keys with a physical write-enable switch. Would something like that be good for this application? Does the UEFI API have a way of stashing such a thing along with its keys?)

2) It can keep a cache of (location, description, signature) triplets for stage-2 bootloaders in some place where it can be retrieved without further user intervention. Would the boot block be a good place? The cache will be publicly readable -- and writable -- so it needs to be signed by the private part of the user's key, and verifiable with the public part of that key.

3) When it's loaded by the UEFI bios, it reads the cache and verifies the signature using the public part of the user's key. Based on keyboard input (or lack thereof, after a short timeout) it picks one entry from the cache and loads that stage-2 boot loader, verifies its signature, and pass control to it.

4) Other things the user can do if she has access to the keyboard before the time-out expires:

a) Request a menu of, and choose one of, the available stage-2 boot loaders, taken from the description part of the cached triplets.

b) Designate one from the above menu as the "default" for future boots if the timeout expires.

c) Request to add a new entry to the stage-2 boot loaders cache, providing the location and description. It then requests and verifies the user's password and uses it to compute the signature of the new stage-2, then sign and write the modified cache.

d) Request deletion of a cache entry. It then requests and verifies the user's password and uses it to sign and write the modified cache.

e) Request to change her password, providing the old password as verification of her right to do so.

f) Request to chain-load another stage-1 boot loader from removable media. This program would need to be signed with one of the keys known to the SecureBoot BIOS, or, if not, have explicit permission to be loaded from the user at the keyboard. This is the rat-hole we provide for installation of new OS's.

Would this work?  What have I missed?

Reply to: