7:08 p.m.
Hi,
I am new to TCG. My understanding is that in SRTM BIOS itself is assumed to be trustable.
It's not measured on a PC client during the boot since it's the first one being
loaded and executed. But it forms the basis of chain of trustable measurements. Is this
correct?
What if my BIOS can't be trusted? Can I still do remote attestation of the PC client
booted this way?
Thanks.
---
David Li
Cloudshield Technologies
SAIC
7:59 a.m.
On Mon, 2011-08-22 at 17:08 -0700, Li, David wrote:
Hi,
I am new to TCG. My understanding is that in SRTM BIOS itself is
assumed to be trustable. It’s not measured on a PC client during the
boot since it’s the first one being loaded and executed. But it forms
the basis of chain of trustable measurements. Is this correct?
It is measured, but at least the initial component (e.g. BIOS boot
block) can't be measured by an independent entity and thus must be
trusted as the core root of trust for measurement (CRTM). The CRTM
measures itself and the rest of BIOS among other things into PCR-0. In
some implementations, the CRTM may be the entire BIOS; in others, it may
be just the BIOS boot block.
What if my BIOS can’t be trusted? Can I still do remote attestation
of the PC client booted this way?
Can you define what you mean by "can't be trusted"? What's your threat
model? If you can't trust the static CRTM, then you should use DRTM
instead, e.g. Intel TXT (actually, that's preferable in general if your
hardware supports it). But even there you will have some residual
vulnerability to SMM and thus a dependency on the BIOS until STMs are
available.
--
Stephen Smalley
National Security Agency
8:19 a.m.
Hi Stephen,
>
>
> I am new to TCG. My understanding is that in SRTM BIOS itself is
> assumed to be trustable. It’s not measured on a PC client during the
> boot since it’s the first one being loaded and executed. But it forms
> the basis of chain of trustable measurements. Is this correct?
It is measured, but at least the initial component (e.g. BIOS boot
block) can't be measured by an independent entity and thus must be trusted
as the core root of trust for measurement (CRTM). The CRTM measures itself
and the rest of BIOS among other things into PCR-0. In some
implementations, the CRTM may be the entire BIOS; in others, it may be just
the BIOS boot block.
> What if my BIOS can’t be trusted? Can I still do remote attestation
> of the PC client booted this way?
Can you define what you mean by "can't be trusted"? What's your
threat
model? If you can't trust the static CRTM, then you should use DRTM instead,
e.g. Intel TXT (actually, that's preferable in general if your hardware supports
it). But even there you will have some residual vulnerability to SMM and thus
a dependency on the BIOS until STMs are available.
[Li, David] My threat model has to assume an attacker can gain physical access to the
motherboard and reflash the BIOS. That's why I worry about using TPM to ensure a
trusted boot.
I am aware of TXT (not in a detailed way). But what's STM? Any pointers?
--
Stephen Smalley
National Security Agency
8:36 a.m.
http://www.ncsi.com/nsatc10/presentations/leong.pdf
https://www.blackhat.com/presentations/bh-dc-09/Wojtczuk_Rutkowska/BlackH...
On Tue, Aug 23, 2011 at 6:19 AM, Li, David <LiD(a)cloudshield.com> wrote:
Hi Stephen,
>>
>>
>> I am new to TCG. My understanding is that in SRTM BIOS itself is
>> assumed to be trustable. It’s not measured on a PC client during the
>> boot since it’s the first one being loaded and executed. But it forms
>> the basis of chain of trustable measurements. Is this correct?
>
>It is measured, but at least the initial component (e.g. BIOS boot
>block) can't be measured by an independent entity and thus must be trusted
>as the core root of trust for measurement (CRTM). The CRTM measures itself
>and the rest of BIOS among other things into PCR-0. In some
>implementations, the CRTM may be the entire BIOS; in others, it may be just
>the BIOS boot block.
>
>> What if my BIOS can’t be trusted? Can I still do remote attestation
>> of the PC client booted this way?
>
>Can you define what you mean by "can't be trusted"? What's your
threat
>model? If you can't trust the static CRTM, then you should use DRTM instead,
>e.g. Intel TXT (actually, that's preferable in general if your hardware supports
>it). But even there you will have some residual vulnerability to SMM and thus
>a dependency on the BIOS until STMs are available.
>
[Li, David] My threat model has to assume an attacker can gain physical access to the
motherboard and reflash the BIOS. That's why I worry about using TPM to ensure a
trusted boot.
I am aware of TXT (not in a detailed way). But what's STM? Any pointers?
>--
>Stephen Smalley
>National Security Agency
_______________________________________________
Trusted-computing mailing list
Trusted-computing(a)lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/trusted-computing
8:45 a.m.
On Tue, 2011-08-23 at 06:19 -0700, Li, David wrote:
My threat model has to assume an attacker can gain physical access
to
the motherboard and reflash the BIOS. That's why I worry about using
TPM to ensure a trusted boot.
So, on the one hand, you are correct - the TCG considered physical
attack to be out of scope. But if you are including that in your threat
model, you already need to take further security measures to prevent
direct physical tampering with the box in general, not just with respect
to the BIOS or the TPM. Right? And I would expect that the same
solution that you apply to address that threat in general should also
assist in protecting the BIOS flash chip and the TPM from direct
physical access, or resetting the TPM in the event of such access.
I am aware of TXT (not in a detailed way). But what's STM? Any
pointers?
STM is SMI transfer monitor. A hypervisor for SMM that acts as a peer
to the main hypervisor. It can then protect the main hypervisor from
direct manipulation by the SMI handlers.
--
Stephen Smalley
National Security Agency
1:18 p.m.
We can't prevent others from tempering the firmware. That's a requirement.
What if the firmware update (e.g. BIOS or UEFI) has to be cryptographically verified? For
example the new firmware has to be hashed and signed by the authorized vendor. The
existing firmware has the capability to verify the hash and signature during the upgrade.
Is this strong enough to prevent firmware tempering?
-----Original Message-----
From: Stephen Smalley [mailto:sds@tycho.nsa.gov]
Sent: Tuesday, August 23, 2011 6:46 AM
To: Li, David
Cc: trusted-computing(a)lists.fedorahosted.org
Subject: RE: [Trusted-computing] Question on Trusted Boot
On Tue, 2011-08-23 at 06:19 -0700, Li, David wrote:
> My threat model has to assume an attacker can gain physical access to
> the motherboard and reflash the BIOS. That's why I worry about using
> TPM to ensure a trusted boot.
So, on the one hand, you are correct - the TCG considered physical attack to
be out of scope. But if you are including that in your threat model, you
already need to take further security measures to prevent direct physical
tampering with the box in general, not just with respect to the BIOS or the
TPM. Right? And I would expect that the same solution that you apply to
address that threat in general should also assist in protecting the BIOS flash
chip and the TPM from direct physical access, or resetting the TPM in the
event of such access.
> I am aware of TXT (not in a detailed way). But what's STM? Any pointers?
STM is SMI transfer monitor. A hypervisor for SMM that acts as a peer to the
main hypervisor. It can then protect the main hypervisor from direct
manipulation by the SMI handlers.
--
Stephen Smalley
National Security Agency
7:37 a.m.
On Sat, 2011-08-27 at 11:18 -0700, Li, David wrote:
We can't prevent others from tempering the firmware. That's
a
requirement.
I'm not sure what that means. Do you mean that you aren't allowed to
employ physical anti-tamper mechanisms at all?
What if the firmware update (e.g. BIOS or UEFI) has to be
cryptographically verified? For example the new firmware has to be
hashed and signed by the authorized vendor. The existing firmware has
the capability to verify the hash and signature during the upgrade.
Is this strong enough to prevent firmware tempering?
That only helps with firmware update via software mechanism, not via
direct re-flashing or replacement of the BIOS flash chip. And it only
helps if that software update mechanism is itself trustworthy and
unbypassable.
--
Stephen Smalley
National Security Agency
4622
days inactive
4628
days old
trusted-computing@lists.fedorahosted.org
6 comments
3 participants
participants (3)
-
august huber -
Li, David -
Stephen Smalley