grub-devel
[Top][All Lists]
Advanced

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

Re: SHA-1 MBR


From: Jan Alsenz
Subject: Re: SHA-1 MBR
Date: Sat, 21 Feb 2009 01:32:06 +0100
User-agent: Thunderbird 2.0.0.19 (X11/20090104)

phcoder wrote:
>> It's not complete SHA-1, but the rest should be just a constant offset.
> I already said how it differs from standard one. If you feed padded
> byteswapped data to it and then byteswap the rsult back you obtain
> exactly normal SHA-1. But as I said if size is fixed it's compeletely
> equivalent in security to normal SHA-1 (you can easily prove formally
> that any successful attack on one variant immediately results in
> successful attack on another variant)
That's what I meant ;)

>> But I'm still not sure, what you are trying to do here, is the MBR
>> your root of
>> trust?
> 
> I'm trying to achieve universal verification scheme which is able to do
> what is needed to support tpm ("prolonging chain of trust" in tpm
> unstandard parlance) without using tpm itself. Such scheme can in future
> be useful in other applications as well.
Okay.
But I think it won't work.

>> If not, who checks the MBR?
> This can't be done by grub because it happens before any part of grub is
> loaded. to verify grub you need to rely on vendor/platform-specific
> mechanisms.
> I personally find "tpm without tpm" more attractive because it can be
> easily reused on another platform or any alternative to tpm (perhaps
> anybody here or coreboot folks will come up with something).
> Additionally it workarounds many bios and tpm bugs.
> I will continue working on sha-1 boot. My goal is to load core.img
> checked. After that point there is much more space and any signature
> based solution can be used.
Yes, that was my point. You need a trusted first step.
But the only thing besides a TPM, that can be used for this is the BIOS, which
can be flashed.
And even, if we assume, that we can construct a BIOS that only boots if the MBR
hash matches and can not be flashed prior to this point, there are still two
points missing:
- After the system has started, the BIOS could be flashed. This is a very
possible scenario in a multi user environment.
- They could take out the disk and put it in another machine, tamper with the
boot code and switch it on. And all your protection is gone.
  Ok, you could try to put a needed key in the BIOS too, but then we're back to
problem one - and the BIOS can not check if a request for the key is valid. I'm
not even sure, if something in the BIOS can be read protected.


Greets,

Jan

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]