SHA-1 MBR

SHA-1 MBR

[phcoder]

[-- Attachment #1: Type: text/plain, Size: 646 bytes --]

Hello, as promised I wrote an mbr which performs SHA-1. To squeeze the 
code I had to remove chs and to change the bootdrive installer will have 
to overwrite corresponding instruction. SHA-1 implemented in it is 
little-endian and without padding. Standard version is big-endian and 
with padding. In this case padding is unnecessary since a sector is 
always 512 bytes. Litt-le endian means just that data isn't byte-swapped 
before hashing. And the hash in sector has to be written in little 
endian and the double should be in order
h1,h2,h3,h4,h0
I also implemented the same thing as standalone program
Regards
Vladimir 'phcoder' Serbinenko

[-- Attachment #2: sha1.S --]
[-- Type: text/plain, Size: 4946 bytes --]

/* -*-Asm-*- */
/*
 *  GRUB  --  GRand Unified Bootloader
 *  Copyright (C) 2009  Free Software Foundation, Inc.
 *
 *  GRUB is free software: you can redistribute it and/or modify
 *  it under the terms of the GNU General Public License as published by
 *  the Free Software Foundation, either version 3 of the License, or
 *  (at your option) any later version.
 *
 *  GRUB is distributed in the hope that it will be useful,
 *  but WITHOUT ANY WARRANTY; without even the implied warranty of
 *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
 *  GNU General Public License for more details.
 *
 *  You should have received a copy of the GNU General Public License
 *  along with GRUB.  If not, see <http://www.gnu.org/licenses/>.
 */

/* The signature for bootloader.  */
#define GRUB_BOOT_MACHINE_SIGNATURE	0xaa55

/* The offset of a magic number used by Windows NT.  */
#define GRUB_BOOT_MACHINE_WINDOWS_NT_MAGIC	0x1b8

/* The offset of the start of the partition table.  */
#define GRUB_BOOT_MACHINE_PART_START	0x1be

/* The offset of the end of the partition table.  */
#define GRUB_BOOT_MACHINE_PART_END	0x1fe

/* The stack segment.  */
#define GRUB_BOOT_MACHINE_STACK_SEG	0x2000

/* The segment of disk buffer. The disk buffer MUST be 32K long and
   cannot straddle a 64K boundary.  */
#define GRUB_BOOT_MACHINE_BUFFER_SEG	0x7000

/* The flag for BIOS drive number to designate a hard disk vs. a
   floppy.  */
#define GRUB_BOOT_MACHINE_BIOS_HD_FLAG	0x80

/* The segment where the kernel is loaded.  */
#define GRUB_BOOT_MACHINE_KERNEL_SEG	0x800

/* The address where the kernel is loaded.  */
#define GRUB_BOOT_MACHINE_KERNEL_ADDR	(GRUB_BOOT_MACHINE_KERNEL_SEG << 4)

/* The size of a block list used in the kernel startup code.  */
#define GRUB_BOOT_MACHINE_LIST_SIZE	12
	

#define ABS(x) (x-_start+0x7c00)

	.code16

.globl _start; _start:
	jmp real_start
stack:
packet:
	.byte 0x10
	.byte 0
	.word 1
	.word 0,GRUB_BOOT_MACHINE_KERNEL_SEG
kernel_sector:
	.long	1, 0	
h1:
	.long 0xefcdab89
h2:
	.long 0x98badcfe
h3:
	.long 0x10325476
h4:
	.long 0xc3d2e1f0
h0:
	.long 0x67452301
real_start:	
	cli
	xorw	%ax, %ax
	movb 	$0x80, %dl
	movw	%ax, %ds
	movw	%ax, %es
	movw	%ax, %ss
	mov $ABS(stack), %sp
	movw	%sp, %si
	movb	$0x42, %ah
	int	$0x13
	add 	$0x10,%sp
	mov ABS(byteshashed), %si
block32:
	movw	$GRUB_BOOT_MACHINE_KERNEL_SEG, %ax
	movw 	%ax, %ds
	incb	%ah
	movw	%ax, %es
	xor %ax,%ax
	mov %ax, %di
	mov $0x40, %cx
	push %cx
	cld
	rep movsb
	pop %cx
	movw	$(GRUB_BOOT_MACHINE_KERNEL_SEG+0x100), %ax
	movw 	%ax, %ds
expand:	
	movl -12(%di), %eax
	xorl -32(%di), %eax
	xorl -56(%di), %eax
	xorl -64(%di), %eax
	shl  $1, %eax
	adc $0, %al
	mov %eax, (%di)
	add $4, %di
	decw %cx
	test %cx, %cx
	jnz expand
	xor %ax, %ax
	mov %ax, %ds
	mov %ax, %es
	movb $0x14, %cl
	movw %sp, %si
	subw %cx, %sp
	movw %sp, %di
	cld
	rep movsb
	mov %sp, %bp	
	xor %ax, %ax
	mov %ax, %si
	
main_loop:
	pop %eax
	pop %ebx
	pop %ecx
	push %ecx
	push %ebx
	push %eax
	cmp $320, %si
	je hashed64	
	cmp $240, %si
	jge phase4
	cmp $160, %si
	jge phase3
	cmp $80, %si
	jge phase2
phase1:
	//(b&c)|(~b & d)
	and %eax, %ebx
	not %eax
	and %ecx, %eax
	or %ebx, %eax
	add $0x5a827999, %eax
	jmp sharedphase
phase2:	
	xor %ebx, %eax
	xor %ecx, %eax
	add $0x6ed9eba1, %eax
	jmp sharedphase
phase3:
	mov %eax, %edx
	and %ebx, %edx
	and %ecx, %eax
	and %ecx, %ebx
	or %ebx, %eax
	or %edx, %eax
	add $0x8f1bbcdc, %eax
	jmp sharedphase
phase4:	
	xor %ebx, %eax
	xor %ecx, %eax
	add $0xca62c1d6, %eax
sharedphase:
	// here we have on stack: b,c,d,e,a
	// f+k in eax
	mov %bp, %di
	push %si
	xor %cx,%cx
	mov %cx, %ds
	mov %cx, %es
	mov %di, %si
	std
	mov $4, %cx
	add $12, %si
	add $16, %di
	mov (%di), %ebx
	rep movsl
	mov %ebx, (%bp)
	pop %si
	movw	$(GRUB_BOOT_MACHINE_KERNEL_SEG+0x100), %cx
	movw 	%cx, %ds

	// here we have on stack: b'=a,b,d'=c,e'=d,e
	// f+k in eax
	mov (%si), %ecx
	add %ecx, %eax
	add 16(%bp), %eax
	mov (%bp), %ecx
	mov %ecx, %ebx
	shl $5, %ecx
	shr $27, %ebx
	or %ecx, %ebx
	add %ebx, %eax
	mov %eax, 16(%bp)
	// here we have on stack: b'=a,b,d'=c,e'=d,a'
	mov 4(%bp), %eax
	mov %eax, %ebx
	shl $30, %ebx
	shr $2, %eax
	or %ebx, %eax
	mov %eax, 4(%bp)
	add $4, %si
	jmp main_loop

hashed64:
	xorw	%ax, %ax
	movw	%ax, %ds
	movw	%ax, %es
	movw 	$5, %cx
addv:	
	movl 	(%bp), %eax
	addl 	%eax, 20(%bp)
	addw	$4, %bp
	decw	%cx
	test	%cx, %cx
	jnz addv
	mov	%bp, %sp
	add	$64, ABS(byteshashed)
	mov 	ABS(byteshashed), %si
	cmpw	$512, %si
	jl	block32
	mov $ABS(hash), %si
	mov %sp, %di
	mov $20, %cx
	cld
	repe cmpsb
self:	
	jnz self
	ljmp	$0, $GRUB_BOOT_MACHINE_KERNEL_ADDR
byteshashed:	.word 0
. = _start + 0x1a4
hash:
	.long 0
	.long 0
	.long 0
	.long 0
	.long 0
	. = _start + GRUB_BOOT_MACHINE_WINDOWS_NT_MAGIC
nt_magic:	
	.long 0
	.word 0
part_start:	
	. = _start + GRUB_BOOT_MACHINE_PART_START
	. = _start + GRUB_BOOT_MACHINE_PART_END

/* the last 2 bytes in the sector 0 contain the signature */
	.word	GRUB_BOOT_MACHINE_SIGNATURE

[-- Attachment #3: sha1.c --]
[-- Type: text/x-csrc, Size: 2126 bytes --]

/* -*-Asm-*- */
/*
 *  GRUB  --  GRand Unified Bootloader
 *  Copyright (C) 2009  Free Software Foundation, Inc.
 *
 *  GRUB is free software: you can redistribute it and/or modify
 *  it under the terms of the GNU General Public License as published by
 *  the Free Software Foundation, either version 3 of the License, or
 *  (at your option) any later version.
 *
 *  GRUB is distributed in the hope that it will be useful,
 *  but WITHOUT ANY WARRANTY; without even the implied warranty of
 *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
 *  GNU General Public License for more details.
 *
 *  You should have received a copy of the GNU General Public License
 *  along with GRUB.  If not, see <http://www.gnu.org/licenses/>.
 */

#include <stdio.h>

unsigned
cs (unsigned a, unsigned b)
{
  return (a<<b)|(a>>(32-b));
}

#define grub_cputole32(x) (x)

int
main ()
{
  char buf[512];
  unsigned w[80];
  int i;
  unsigned h0 = 0x67452301;
  unsigned h1 = 0xefcdab89;
  unsigned h2 = 0x98badcfe;
  unsigned h3 = 0x10325476;
  unsigned h4 = 0xc3d2e1f0;
  unsigned a,b,c,d,e,f,k,t;


  while (fread (buf,1,64,stdin) == 64)
    {
      
      for (i = 0; i < 16; i++)
	{
	  w[i] = grub_cputole32 (((unsigned *)buf)[i]);
	  //	  printf ("%08x, ", w[i]);
	}
      //      printf ("\n\n");
      for (;i<80;i++)
	{
	  w[i] = cs(w[i-3]^w[i-8]^w[i-14]^w[i-16],1);
	  //	  printf ("%08x, ", w[i]);
	}
      //      printf ("\n\n");
      a = h0;
      b = h1;
      c = h2;
      d = h3;
      e = h4;

      for (i=0;i<80;i++)
	{
	  if (0 <= i && i<=19)
	    {
	      f = (b&c)|(~b & d);
	      k = 0x5a827999;
	    }
	  if (20 <= i && i<=39)
	    {
	      f = b^c^d;
	      k = 0x6ed9eba1;
	    }
	  if (40 <= i && i<=59)
	    {
	      f = (b & c) | (b & d) | (c & d);
	      k = 0x8f1bbcdc;
	    }
	  if (60 <= i && i<=79)
	    {
	      f = b^c^d;
	      k = 0xca62c1d6;
	    }
	  t = cs(a,5)+f+e+k+w[i];
	  e=d;
	  d=c;
	  c=cs(b,30);
	  b=a;
	  a=t;
	}
      h0 += a;
      h1 += b;
      h2 += c;
      h3 += d;
      h4 += e;
    }
  printf ("%08x,%08x,%08x,%08x,%08x\n", h1, h2, h3, h4, h0);
  return 0;
}

Re: SHA-1 MBR

[Jan Alsenz]

[-- Attachment #1: Type: text/plain, Size: 932 bytes --]

Hi!

Wow, cool work!
It's not complete SHA-1, but the rest should be just a constant offset.

But I'm still not sure, what you are trying to do here, is the MBR your root of
trust?
If not, who checks the MBR?

Greets,

Jan


phcoder wrote:
> Hello, as promised I wrote an mbr which performs SHA-1. To squeeze the
> code I had to remove chs and to change the bootdrive installer will have
> to overwrite corresponding instruction. SHA-1 implemented in it is
> little-endian and without padding. Standard version is big-endian and
> with padding. In this case padding is unnecessary since a sector is
> always 512 bytes. Litt-le endian means just that data isn't byte-swapped
> before hashing. And the hash in sector has to be written in little
> endian and the double should be in order
> h1,h2,h3,h4,h0
> I also implemented the same thing as standalone program
> Regards
> Vladimir 'phcoder' Serbinenko


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: SHA-1 MBR

[phcoder]

Hello
Jan Alsenz wrote:
> Hi!
> 
> Wow, cool work!
Thanks
> 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)
> 
> 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.
 > 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.
> 
> Greets,
> 
> Jan
> 
Regards
Vladimir 'phcoder' Serbinenko

Re: SHA-1 MBR

[Jan Alsenz]

[-- Attachment #1: Type: text/plain, Size: 2390 bytes --]

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 #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: SHA-1 MBR

[Isaac Dupree]

Jan Alsenz wrote:
> 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.

BIOS could be in ROM, un-flashable, including hash/keys and all!  Refuse to 
boot if the hash doesn't match!  Admittedly this poses some limitations on 
whether the system can be upgraded, depending how sophisticated you want to 
be.

Re: SHA-1 MBR

[Javier Martín]

[-- Attachment #1: Type: text/plain, Size: 2386 bytes --]

El vie, 20-02-2009 a las 20:02 -0500, Isaac Dupree escribió:
> Jan Alsenz wrote:
> > 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.
> 
> BIOS could be in ROM, un-flashable, including hash/keys and all!  Refuse to 
> boot if the hash doesn't match!  Admittedly this poses some limitations on 
> whether the system can be upgraded, depending how sophisticated you want to 
> be.

This paranoid security talk is growing some big pink elephants which are
being conveniently ignored: you people are trying to protect a HD within
a computer that could be stolen, but you trust that the BIOS chip (in
ROM and whatever you want), which performs the systems initialization
(including RAM and the TPM) cannot be tampered with or even replaced.
When someone pointed the key-in-RAM problem the answer was "I'll just
glue it with epoxy resin"! For crying out loud! Without taking into
account that most epoxy resins take weeks to solidify under 100 ºC, if
the computer is physically stolen it could be subjected to EM-field
analysis. What will be the next madness? Will you wrap every RAM module
in tinfoil, a-la Faraday cage? Will you build a plasma shield around
them? This is going way out of proportion: with non-interactive key
initialization, if the computer is stolen, you are screwed period,
because you have a Mallory-on-steroids-holding-Alice-ransom instead of a
tame Eve. It does not take a rocket scientist (what I'm studying) nor a
cryptographer (one of my hobbies) to notice!


-- 
-- Lazy, Oblivious, Rational Disaster -- Habbit

[-- Attachment #2: Esta parte del mensaje está firmada digitalmente --]
[-- Type: application/pgp-signature, Size: 835 bytes --]

Re: SHA-1 MBR

[Alex Besogonov]

T>his paranoid security talk is growing some big pink elephants which are
>being conveniently ignored: you people are trying to protect a HD within
>a computer that could be stolen, but you trust that the BIOS chip (in
>ROM and whatever you want), which performs the systems initialization
>(including RAM and the TPM) cannot be tampered with or even replaced.
The BIOS itself is checksummed and verified by the TPM. So a simple
reflashing won't work.

Please, don't think that all engineers who designed the TPM are complete idiots.

>When someone pointed the key-in-RAM problem the answer was "I'll just
>glue it with epoxy resin"! For crying out loud! Without taking into
>account that most epoxy resins take weeks to solidify under 100 ºC,
Uhm.. It takes about 8 hours for the resin with hardener to solidify
(speaking from experience).

>if the computer is physically stolen it could be subjected to EM-field
>analysis.
That's WAY more complex than just swapping chips.

Also, there's another small thing - I can just delete the key from my
key server, and then no amount of hacking will unlock hard drive. TPM
and other measures just buy time.

Re: SHA-1 MBR

[Jan Alsenz]

[-- Attachment #1: Type: text/plain, Size: 1378 bytes --]

>>> 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.
Ok, I revoke that statement!

This is most likely equivalent to being able to just read out the disk
encryption keys from memory, which we considered out of scope.

So if you can get the BIOS right, this might actually work for our scenario!

Greets,

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: SHA-1 MBR

[phcoder]

I agree that these measures aren't here to protect against serious 
cryptanalyst. Actually there is a way which is even in my reach to crack 
it. I would buy:
pci firewire card $10
Then I would download firewire debug tools and put pci card into target 
computer then wait that it boots and dump the whole memory (a bug in 
many firewire implementations allows to do it). Then the key can be 
easily found in this dump. However the first question of security is
-What are the threats faced?
(Bruce Schneier "Beyond Fear")
Classical cryptography works under some assumptions and this scheme is 
totally unsecure under these assumptions. However I recognise that it 
can be useful in some cases.
Regards
Vladimir 'phcoder' Serbinenko
Javier Martín wrote:
> El vie, 20-02-2009 a las 20:02 -0500, Isaac Dupree escribió:
>> Jan Alsenz wrote:
>>> 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.
>> BIOS could be in ROM, un-flashable, including hash/keys and all!  Refuse to 
>> boot if the hash doesn't match!  Admittedly this poses some limitations on 
>> whether the system can be upgraded, depending how sophisticated you want to 
>> be.
> 
> This paranoid security talk is growing some big pink elephants which are
> being conveniently ignored: you people are trying to protect a HD within
> a computer that could be stolen, but you trust that the BIOS chip (in
> ROM and whatever you want), which performs the systems initialization
> (including RAM and the TPM) cannot be tampered with or even replaced.
> When someone pointed the key-in-RAM problem the answer was "I'll just
> glue it with epoxy resin"! For crying out loud! Without taking into
> account that most epoxy resins take weeks to solidify under 100 ºC, if
> the computer is physically stolen it could be subjected to EM-field
> analysis. What will be the next madness? Will you wrap every RAM module
> in tinfoil, a-la Faraday cage? Will you build a plasma shield around
> them? This is going way out of proportion: with non-interactive key
> initialization, if the computer is stolen, you are screwed period,
> because you have a Mallory-on-steroids-holding-Alice-ransom instead of a
> tame Eve. It does not take a rocket scientist (what I'm studying) nor a
> cryptographer (one of my hobbies) to notice!
> 
> 
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/grub-devel

Re: SHA-1 MBR

[phcoder]

I consider the way how memory is protected or how integrity of mbr is 
ensured out of scope of grub2. It simply can do nothing against it. So 
my goals is just making verfication chain secure. Then I hope that 
someone more knowledge in chipsets will find a way to build a secure 
system on the top of it. I do only as much as I can and never claim to 
achieve something which is theoretically impossible
Regards
Vladimir 'phcoder' Serbinenko
Jan Alsenz wrote:
>>>> 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.
> Ok, I revoke that statement!
> 
> This is most likely equivalent to being able to just read out the disk
> encryption keys from memory, which we considered out of scope.
> 
> So if you can get the BIOS right, this might actually work for our scenario!
> 
> Greets,
> 
> Jan
> 
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/grub-devel

Re: SHA-1 MBR

[phcoder]

BTW some BIOSes have an option "boot virus protection" which checks the 
mbr and doesn't need tpm. Then password-protecting BIOS and storing key 
in flash and cutting write wire will achieve greater security that tpm
Regards
Vladimir 'phcoder' Serbinenko