21 Aug
2013
21 Aug
'13
9:18 a.m.
On 8/20/2013 8:49 PM, Cory Smelosky wrote:
(Oops. Sent this to cctech by accident. It really belongs here as this isn?t exactly
?classic?)
Evening all,
I?ve been thinking (I don?t actually have a secureboot-capable device nor have I read the
spec) about one would theoretically circumvent it.
I was initially thinking of it in terms of how TSX as booted on the PDP-11 (starting at
RT-11, loading TSX as ash application and having it replace RT-11). That approach has
some flaws, however:
1). In the case of WinRT, user mode apps wouldn?t have the privileges to replace WinRT?s
memory.
Secure computing on intel starts in the hardware. You have to have the
correct signature to run out of reset.
2). Kernel modules providing a shim would need to be
signed else they wouldn?t load.
3). You couldn?t modify a driver without the checksum matching. Which brings me to this:
Does SecureBoot actually check if the checksum matches, or just the public and private
key?
There is no horse out of the barn, so you can probe the memory. However
they go out of the way to have secure signed blocks that come from
whatever area necessary into internal registers which are decrypted to
have correct execution privilege masks for any change that requires access.
You have a number of execution states in the intel system, and some may
or may not have secured enabled. For instance the normal problem
execution state (including system privilege execution) would of course
be secured, but perhaps the SM state that is executed might not be.
Also of these states, probe mode is like a normal citizen of this space
and at one time did not have to have security. My understanding is now
that you probably will have to even have keys in probe mode to do much
but enter probe mode and look at some few MSR's and memory. I would
imagine you can run and stop the processor but not much else w/o the
correct keys.
You know they have to have keys that are in the code you boot in, and of
course reverse engineering would show the locations that the key blocks
come from as you debug or disassemble. But these blocks are securely
locked with code that will not allow you to figure them out.
The controversy is that Intel essentially handed the bios signing to
microsoft. If you sub in your own bios or efi, you will have your own
set of secure keys and can run anything you like, but not a MS signed os.
I don't know the reason for this, since the idea behind uefi was that
you could run different bios type layers or just have your OS boot and
run on top of uefi (this would mean there would be some machine specific
layers w/o the bios layers to provide apis, but still doable).
I suspect they screwed something up and still want to obsucure some bios
details so they had to give out control of that and the control of the
secure execution over to their biggest client (or in the eyes of MS they
are the biggest).
Alternatively, how securely is the key stored? Would it be possible to retrieve the key
from memory? If that?s doable, it would be easier to implement this.
Are there any steps in the modern NT boot procedure I?m forgetting that would let you
inject a ?boot loader? to ?jump? to either windows or Another OS that would circumvent
SecureBoot?
Thoughts/comments greatly appreciated!.