* SHA-1 MBR
@ 2009-02-20 21:50 phcoder
2009-02-20 23:06 ` Jan Alsenz
0 siblings, 1 reply; 11+ messages in thread
From: phcoder @ 2009-02-20 21:50 UTC (permalink / raw)
To: The development of GRUB 2
[-- 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;
}
^ permalink raw reply [flat|nested] 11+ messages in thread* Re: SHA-1 MBR
2009-02-20 21:50 SHA-1 MBR phcoder
@ 2009-02-20 23:06 ` Jan Alsenz
2009-02-20 23:41 ` phcoder
0 siblings, 1 reply; 11+ messages in thread
From: Jan Alsenz @ 2009-02-20 23:06 UTC (permalink / raw)
To: The development of GRUB 2
[-- 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 --]
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: SHA-1 MBR
2009-02-20 23:06 ` Jan Alsenz
@ 2009-02-20 23:41 ` phcoder
2009-02-21 0:32 ` Jan Alsenz
0 siblings, 1 reply; 11+ messages in thread
From: phcoder @ 2009-02-20 23:41 UTC (permalink / raw)
To: The development of GRUB 2
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
^ permalink raw reply [flat|nested] 11+ messages in thread* Re: SHA-1 MBR
2009-02-20 23:41 ` phcoder
@ 2009-02-21 0:32 ` Jan Alsenz
2009-02-21 1:02 ` Isaac Dupree
2009-02-21 8:56 ` Jan Alsenz
0 siblings, 2 replies; 11+ messages in thread
From: Jan Alsenz @ 2009-02-21 0:32 UTC (permalink / raw)
To: The development of GRUB 2
[-- 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 --]
^ permalink raw reply [flat|nested] 11+ messages in thread* Re: SHA-1 MBR
2009-02-21 0:32 ` Jan Alsenz
@ 2009-02-21 1:02 ` Isaac Dupree
2009-02-21 1:21 ` Javier Martín
2009-02-21 8:56 ` Jan Alsenz
1 sibling, 1 reply; 11+ messages in thread
From: Isaac Dupree @ 2009-02-21 1:02 UTC (permalink / raw)
To: grub-devel
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.
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: SHA-1 MBR
2009-02-21 1:02 ` Isaac Dupree
@ 2009-02-21 1:21 ` Javier Martín
2009-02-21 9:43 ` phcoder
0 siblings, 1 reply; 11+ messages in thread
From: Javier Martín @ 2009-02-21 1:21 UTC (permalink / raw)
To: The development of GRUB 2
[-- 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 --]
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: SHA-1 MBR
2009-02-21 1:21 ` Javier Martín
@ 2009-02-21 9:43 ` phcoder
0 siblings, 0 replies; 11+ messages in thread
From: phcoder @ 2009-02-21 9:43 UTC (permalink / raw)
To: The development of GRUB 2
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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: SHA-1 MBR
2009-02-21 0:32 ` Jan Alsenz
2009-02-21 1:02 ` Isaac Dupree
@ 2009-02-21 8:56 ` Jan Alsenz
2009-02-21 13:27 ` phcoder
1 sibling, 1 reply; 11+ messages in thread
From: Jan Alsenz @ 2009-02-21 8:56 UTC (permalink / raw)
To: The development of GRUB 2
[-- 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 --]
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: SHA-1 MBR
2009-02-21 8:56 ` Jan Alsenz
@ 2009-02-21 13:27 ` phcoder
2009-02-21 14:12 ` phcoder
0 siblings, 1 reply; 11+ messages in thread
From: phcoder @ 2009-02-21 13:27 UTC (permalink / raw)
To: The development of GRUB 2
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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: SHA-1 MBR
@ 2009-02-21 2:21 Alex Besogonov
0 siblings, 0 replies; 11+ messages in thread
From: Alex Besogonov @ 2009-02-21 2:21 UTC (permalink / raw)
To: grub-devel
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.
^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2009-02-21 14:12 UTC | newest]
Thread overview: 11+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2009-02-20 21:50 SHA-1 MBR phcoder
2009-02-20 23:06 ` Jan Alsenz
2009-02-20 23:41 ` phcoder
2009-02-21 0:32 ` Jan Alsenz
2009-02-21 1:02 ` Isaac Dupree
2009-02-21 1:21 ` Javier Martín
2009-02-21 9:43 ` phcoder
2009-02-21 8:56 ` Jan Alsenz
2009-02-21 13:27 ` phcoder
2009-02-21 14:12 ` phcoder
-- strict thread matches above, loose matches on Subject: below --
2009-02-21 2:21 Alex Besogonov
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.