Linux Archive

Linux Archive (http://www.linux-archive.org/)
-   Debian Development (http://www.linux-archive.org/debian-development/)
-   -   Proposal for stage-1 boot loader for use with SecureBoot (http://www.linux-archive.org/debian-development/680582-proposal-stage-1-boot-loader-use-secureboot.html)

Rick Thomas 07-06-2012 12:39 AM

Proposal for stage-1 boot loader for use with SecureBoot
 
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?


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 38B1A676-40D9-4C0D-9DBB-6B50B533EEA4@pobox.com">http://lists.debian.org/38B1A676-40D9-4C0D-9DBB-6B50B533EEA4@pobox.com

Russell Coker 07-06-2012 04:58 AM

Proposal for stage-1 boot loader for use with SecureBoot
 
On Fri, 6 Jul 2012, Rick Thomas <rbthomas@pobox.com> wrote:
> 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?)

There is no reason why GPL source can't be used for an unchangable binary. As
long as the source is supplied then it's not a problem.

Every Debian package is an unchangable binary, we don't change binaries we
just replace them with newer versions.

There is a huge range of embedded devices with the Linux kernel (and other GPL
software) in ROM which almost never get updated. A Linux kernel in a mobile
phone which has a locked boot loader is no different in terms of license from
a secure boot loader under the GPL.

Using GPL licensed software to enforce signature checks is not a problem
either. We have GPG (and many other programs) for checking signatures and
doing encryption and we have SE Linux (and many other options) for access
control.

--
My Main Blog http://etbe.coker.com.au/
My Documents Blog http://doc.coker.com.au/


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 201207061458.32921.russell@coker.com.au">http://lists.debian.org/201207061458.32921.russell@coker.com.au

Bastian Blank 07-06-2012 09:02 AM

Proposal for stage-1 boot loader for use with SecureBoot
 
On Thu, Jul 05, 2012 at 05:39:07PM -0700, Rick Thomas wrote:
> The fundamental problem we must solve is allowing the *user* to
> securely choose which OS she wants to install.

No. The user can disable secure boot.

> 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!)

No, this is not voluntary. If we get a loader signed by an external
entity, it have to fulfill the requirements, aka no execution of
unsigned code in the kernel.

> Would this work? What have I missed?

You show a fundamental missinterpretation of the goals of secure boot. I
see nothing worth commenting on.

Bastian

--
The man on tops walks a lonely street; the "chain" of command is often a noose.


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20120706090215.GB19856@wavehammer.waldi.eu.org">ht tp://lists.debian.org/20120706090215.GB19856@wavehammer.waldi.eu.org

Ben Hutchings 07-07-2012 01:02 AM

Proposal for stage-1 boot loader for use with SecureBoot
 
On Fri, 2012-07-06 at 11:02 +0200, Bastian Blank wrote:
> On Thu, Jul 05, 2012 at 05:39:07PM -0700, Rick Thomas wrote:
> > The fundamental problem we must solve is allowing the *user* to
> > securely choose which OS she wants to install.
>
> No. The user can disable secure boot.
>
> > 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!)
>
> No, this is not voluntary. If we get a loader signed by an external
> entity, it have to fulfill the requirements, aka no execution of
> unsigned code in the kernel.

That was my first reaction. But I'm not sure it's correct.

> > Would this work? What have I missed?
>
> You show a fundamental missinterpretation of the goals of secure boot. I
> see nothing worth commenting on.

The goal is to prevent malware from persistently subverting a legitimate
OS kernel, even if it tricks the user or the kernel into letting it
install a boot loader or kernel module.

So, if some hypothetical boot loader handles the appearance of some
unsigned boot payload by asking 'do you really want to boot this?', of
course the naive user will answer 'yes, I want to boot my computer'.
Malware will then use that boot loader as its first stage and it will
end up blacklisted. However, if the process of making the hypothetical
boot loader trust new boot code involves a more active decision on the
user's part (and if that decision cannot be automated by malware), it
might possibly be sufficient to keep it from being exploited and
blacklisted. But perhaps there are formal requirements that I'm not
aware of, that would still forbid this.

Ben.

--
Ben Hutchings
When in doubt, use brute force. - Ken Thompson


All times are GMT. The time now is 12:40 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.