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
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.
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
http://www.ncsi.com/nsatc10/presentations/leong.pdf
https://www.blackhat.com/presentations/bh-dc-09/Wojtczuk_Rutkowska/BlackHat-...
On Tue, Aug 23, 2011 at 6:19 AM, Li, David LiD@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@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/trusted-computing
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.
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@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
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.
trusted-computing@lists.fedorahosted.org
-
august huber -
Li, David -
Stephen Smalley