Trusted Boot in Fedora

[Camilo Mesias]

On Fri, Jun 24, 2011 at 1:21 PM, Jon Ciesla <limb at jcomserv.net> wrote:
>
>> On Fri, Jun 24, 2011 at 10:01:45AM +0100, Camilo Mesias wrote:
>>> I am still struggling to see real applications for this. I don't know
>>> how a networked system using the technology could be differentiated
>>> from an (insecure) software simulation of the same from a remote
>>> viewer's perspective. Also I don't see how it would be used in the
>>
>> Afaik it would allow to securely enter hard disk encryption passwords
>> via network on a Fedora system, because one can ensure that the correct
>> (untampered) initrd / kernel is loaded.
>> You cannot simulate this afaik because the used cryptographic keys are
>> only stored in the TPM module and cannot be accessed from the outside.
>> Therefore one needs to tamper with the TPM module instead of only with
>> the unencrypted /boot partition, which is a lot harder from my point of
>> view.
>
> So you can't possibly duplicate the keys elsewhere and modify the software
> calling them to look in that place, allowing you to virtualize a whole
> cluster of the same "trusted" machine?

I think I can imagine how it might work - assuming that each device
has unique key material, you could do cryptographic operations that
ensure that the device you are talking to still has the same key
(without exposing the key). So you infer the identity of the device
you are talking to is that expected (ie the same device and not a
replacement). This would enable a booting client to request disk
passwords from a server after ensuring that the server is the one it
is configured to recognise. The server would also be able to give the
keys to the client, knowing that it was the genuine client and not an
impostor.

You could implement the whole thing in software, but the point is the
key material is stored securely, so could not be copied in the same
way you could take a copy of a private key stored in a filesystem.

The other way for this to be used would be for the device to have
non-unique material - ie. a 'ChipCorp' key - that is the same in many
devices. Then external entities would be able to challenge a device to
sign something with that key and verify that the device was a
'genuine' one. You would be unable to implement this in software
unless you knew the secret stored inside the device.

-Cam