[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Secure Boot. Why don't you take the wind out of their sails?
From: |
Andreas Born |
Subject: |
Re: Secure Boot. Why don't you take the wind out of their sails? |
Date: |
Tue, 10 Jul 2012 01:49:33 +0200 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120615 Thunderbird/13.0.1 |
Am 10.07.2012 00:38, schrieb Graham Cunnington:
The above is incomprehensible to most users who are not developers.
Why not just say:
"You can password-protect Grub. This will secure it against malware
and anybody taking over your computer."
This is in no way comparable to Secure Boot or TPM measure in general. A
password just prevents THIS instance of grub and THIS grub configuration
from being used to boot systems in an unintended manner by unauthorized
individuals. It can be easily circumvented by e.g. booting from a CDROM
or USB drive (hardware access is the key here). Password-based menus are
inherently insecure when used with physical access. It's commonly
described as security by obscurity. Just locking the one most obvious
entry in a secure manner doesn't make the whole building safe if there
are other slightly hidden, unlocked entries. Security AND obscurity
combined can offer additional security (e.g. all doors locked and hidden).
Furthermore password-based menus don't prevent that installation of grub
to be replaced by a malicious modified instance of grub which could e.g.
log your password and could load a maliciously modified kernel. That's
because unlike other measure like Secure Boot it does not verify the
code executed. Instead you're just trusting the code to correctly verify
the password and it does not even check the kernel. To be protected
against malicious code there needs to be a secure component that checks
every code executed by the computer at any point for trustworthiness.
That's simply put and sort of an optimal scenario. In reality you won't
be able to check more than a sensible selection for administrative
reasons (except for clearly defined use cases like some embedded
devices) and it's somewhat more complicated.
So we have two completely different use cases here:
- passwords: verification of the user i.e. the human individual trying
to use that bootloader instance (not anything else), could be
ineffective with malicious code which is not checked here
- TPM or Secure Boot: verification of the actual code executed i.e. no
malicious software is executed if everything is verified (practically
impossible) and if nobody is able to get his malicious code trusted due
to human or administrative mistakes e.g.
AFAIK as with Secure Boot almost nothing is verified the glamorously
advertised, all-encompassing, magic protection is actually a fallacy and
just very limited. If it weren't for the seemingly obvious true concerns
of global companies, it could actually be quite an interesting technology.
Andreas Born