Gentoo Logo
Gentoo Spaceship




Note: Due to technical difficulties, the Archives are currently not up to date. GMANE provides an alternative service for most mailing lists.
c.f. bug 424647
List Archive: gentoo-dev
Navigation:
Lists: gentoo-dev: < Prev By Thread Next > < Prev By Date Next >
Headers:
To: gentoo-dev@g.o
From: Florian Philipp <lists@...>
Subject: Re: Re: UEFI secure boot and Gentoo
Date: Sun, 17 Jun 2012 22:30:15 +0200
Am 17.06.2012 20:56, schrieb Sascha Cunz:
> On Sunday, 17. June 2012 20:00:51 Florian Philipp wrote:
>> Am 17.06.2012 19:34, schrieb Sascha Cunz:
>>> [...]
>>>
>>>> It doesn't. It's just a very long wooden fence; you just didn't find
>>>> the hole yet.
>>>
>>> Given the fact that the keys in the BIOS must somehow get there and it
>>> must
>>> also be able to update them (how to revoke or add keys else?).
>>>
>>> Unless this is completely done in hardware, there must be a software doing
>>> it. Software can - by design - be reverse engineered; in some countries
>>> even legally without any further agreement or license.
>>>
>>> So, you can sign, encrypt, obfuscate or use some other foobar-mechanism on
>>> this blob of software - at some point it must be readable from the
>>> processor, so you have to provide the mechanisms to verify signs, undo
>>> encryption etc somewhere (either in hardware or another software).
>>>
>>> Even if you somehow manage to embed all of this in the hardware stack, it
>>> would still require some kind of interface to get updated / revoked keys
>>> to
>>> operate on.
>>>
>>> It's not a matter of *if this can* be broken by someone who cares, it's a
>>> matter of *how long does it take* for someone who cares to break it.
>>>
>>> In the end, this is just another kind of "seems to be secure for a day or
>>> two". Admittedly a complex one - but there will always be a "kid in a
>>> garage" that is able to set everyone else out of business.
>>>
>>> SaCu
>>
>> Okay, a few points here:
>>
>> First: On an abstract level, the key innovation in Secure Boot and
>> driver signing is that it establishes a trust relationship between
>> platform owner and platform firmware (using a so called Platform Key) as
>> well as trust between operating system and platform firmware (using Key
>> Exchange Keys).
> 
> You've said yourself, that "some removable media might not require signatures" 
> in order to boot. Well, if that is the case, then isn't this defeating the 
> whole point of Secure Boot at that stage?
> 

No. If that was the case, then UEFI shouldn't allow deactivating Secure
Boot, should it? Secure Boot's primary purpose is to prevent malware
from installing itself into the bootloader or (by extension) the kernel
image.

>> Under the assumption that the implementation is correct, nothing on the
>> operating system level can inject drivers, boot loaders or whatever else
>> into the firmware unless it is properly signed. The platform will not
>> allow anything unless it is bit-by-bit verified to come from the
>> platform owner or a trusted third party. The recommended algorithms for
>> signing and verifying code are SHA-256 and RSA-2048. Good luck breaking
>> that in "a day or two"!
>>
>> Second point: Secure Boot is not designed to protect against an attacker
>> with physical access to the machine. So you can leave your soldering
>> iron and memory stick at home when you try to prove that Secure Boot can
>> be broken.
> 
> I was under the impression that it should at least help in that scenario. 
> OTOH, if it takes a compromised system or physical access to the machine in 
> order to manipulate the boot sequence, then I no longer understand what the 
> boot sequence in such a system must be protected against (Assuming that the 
> primary reason for boot sequence manipulation is to later on compromise the 
> system).
> 

Well, it does help, especially when you also prevent changing UEFI
settings with a password. However, there are so many variables and
possibilities when talking about attacks on physically accessible
systems, that you're usually screwed anyway.

Again, the point is that malware, even if it gets temporary access to
your system, even if it gets root access, cannot install itself into the
boot process. It cannot persist in kernel space.

>> Third point: Of course Secure Boot will be broken! A mainboard maker
>> will screw up, there will be a bug in the specs or RSA will be broken.
>> And when one of these happens, it will be fixed. Plain and simple. We
>> didn't abandon SSL just because version 1 and 2 were broken. Why should
>> we abandon Secure Boot?
> 
> "Plain and simple" here probably means, that all (at least many) sold system 
> up to that date are downgraded to "unsecure". Not every user out there is 
> reachable by any channel telling that it is just now a hard requirement to 
> update the system - and even getting the message to the user won't cause 100% 
> of the reached users to go that upgrade path.
> 

Yes, you are right here. But ultimately, any bugs will be fixed. Even if
it means waiting for the next device generation.

Regards,
Florian Philipp


Attachment:
signature.asc (OpenPGP digital signature)
Replies:
Re: Re: UEFI secure boot and Gentoo
-- Rich Freeman
References:
UEFI secure boot and Gentoo
-- Greg KH
Re: Re: UEFI secure boot and Gentoo
-- Sascha Cunz
Re: Re: UEFI secure boot and Gentoo
-- Florian Philipp
Re: Re: UEFI secure boot and Gentoo
-- Sascha Cunz
Navigation:
Lists: gentoo-dev: < Prev By Thread Next > < Prev By Date Next >
Previous by thread:
Re: Re: UEFI secure boot and Gentoo
Next by thread:
Re: Re: UEFI secure boot and Gentoo
Previous by date:
Re: UEFI secure boot and Gentoo
Next by date:
[pre-GLEP] Optional runtime dependencies via runtime-switchable USE flags


Updated Jun 29, 2012

Summary: Archive of the gentoo-dev mailing list.

Donate to support our development efforts.

Copyright 2001-2013 Gentoo Foundation, Inc. Questions, Comments? Contact us.