Measuring Intel MEBx and AMT configurations to PCRs

Measuring Intel MEBx and AMT configurations to PCRs

Is there anyway to get Intel TXT or some other measured/trusted local component to measure the MEBx/AMT configurations into some PCR?

I have been doing some experiments on some Intel NUCs looking at how different aspects of the boot process affect the different PCRs and none of the PCRs seem to reflect changes in MEBx. No changes in the PCRs when MEBx passwords are changed. No changes in the PCRs when AMT is setup to allow remote access through KVM.

1) Shouldn't such changes show up in PCR 1 or PCR 7?

2) If not, doesn't this present a significant security hole, especially from an LCP  and remote-attestation perspective?

3) Is there any way for an application or the kernel running locally on a the machine to check that machine's MEBx or AMT configurations during run time?

11 posts / 0 new
Last post
For more complete information about compiler optimizations, see our Optimization Notice.

Are you familiar with the  "Measured AMT" feature of Intel® vPro™ technology ? It doesn't use Intel® TXT for measurement but instead does a SHA-1 hash of the AMT firmware  and puts it in an Extended Register of the ME firmware. . (Each ME  module has a hash in the manifest.) Then during ME boot,  the ROM code measures and compares that module to the hash in the manifest.  

Thank you for the fast response, Colleen. I am not actually familiar with "Measured AMT".

Does it just measure the firmware or does it measure the configuration settings and password as well?

While measuring the firmware would address concerns around bad firmware, it would not address concerns regarding a bad configuration.

I was hoping that there would be some mechanism based on whether or not AMT was even enabled. For example, I would like to be able to prevent launch if Intel AMT is enabled.

Also I would like a remote server to be able to determine if the system is in a trusted configuration where the state of Intel AMT (enabled or disabled) is taken into account as a part of that configuration.

ah - so Measured AMT we think only does the firmware module code, not the config.

I'll have to ask some real experts about what TPM might or might not be able to do.  Can you tell me what system you have? (CPU and TPM model please).

Also can you clarify what you mean about not booting if configured? Do you just want it to boot if AMT is NOT configured at all? or if it's configuration has changed?

The system I am experimenting with is an Intel NUC DC53427HYE.

tpm_version:
TPM 1.2 Version Info:
Chip Version:        1.2.13.12
Spec Level:           2
Errata Revision:    3
TPM Vendor ID:       STM
Vendor Specific data: 50
TPM Version:         01010000
Manufacturer Info:   53544d20

processor:
Intel(R) Core(TM) i5-3427U CPU @ 1.80GHz

Well, a part of Intel TXT is the launch-control policy (LCP). A launch control policy allows you to make a go/no go decision based on two things: 1) the values of a subset of the PCRs 2) the hash of the MLE you're trying to boot (e.g. tboot.gz). So, if your boot configuration changes, your BIOS version changes, or your Secure Boot keys change, there are changes to your PCR values. If the new PCR values are not one of the values authorized by your LCP, your system doesn't boot.

Now, I want you to consider the following scenario. You have setup your computer to use Secure Boot and Intel TXT, and you have disabled AMT. Your computer is safe and secure, so you go home. The evil maid gets hold of your computer, disconnects the RTC battery, changes the reset headers to boot your board in maintenance mode, and then changes it back. Now, your MEBx password is "admin". She then proceeds to configure AMT. 

You come back to your computer not suspecting anything. Since you think that AMT is disabled, you don't check anything regarding AMT. (Why would you? Its Disabled.) Your secure boot keys are the same, everything else is the same, so your computer boots without problem. All the while, the evil maid now has access to your computer through AMT.

I hope this scenario clarifies my concerns. On the other hand, if changes in MEBx configurations were reflected in the PCRs, you could take the state of AMT into account in your launch-control policy.

Hi Safayet,

Still working on what's possible but so far I've found out that AMT/MEBx are orthogonal to TXT (not host OS components)  Pieces of ME have to be handled by BIOS UEFI secure boot rules and the MEBx config handled as BIOS extensions. 
I'm still checking if there are any methods we can suggest, beyond Measured AMT. If I hear of anything.  I'll post it here.

 

 

Thank you Colleen. I appreciate all your time and help.

Here's further info which would be applicable to a client vPro system with Q chipset and so I assume similar for the NUC.

It's possible the measurement could be done by platform specific code in the BIOS as an optional PCR1 measurement (Non-Host Platform configuration information). But it would not be supported by the general, platform independent Tianocore or BP Measured Boot code.

Per TCG PC Client Specific Implementation Specification for Conventional BIOS v1.21 rev. 1.0 section  3.3.3.2 PCR[1], 
     Page 47 Entities that MAY be measured if the TPM is activated:   #8 
         Non-Host Platform configuration information. If the system contains a Non-Host Platform, the BIOS SHOULD use the event type EV_NONHOST_CONFIG to record any security-relevant configuration information or data.
   
Note: PCR7 is used on Windows* 8 systems for measurement of the UEFI Secure Boot variables:  PK, KEK, DB, DBX … only
Older TPM1.2 systems could use PCR7 for OEM specific measurements.

 

If I understand your last reply correctly, I have to build my own BIOS to be able to detect changes in MEBx/AMT settings through Intel TXT. Can you point me to relevant documentation or resources to be able to do that?

I have the question out to the NUC team. Will update when I have more info.  

Question - is this a project that is likely to go beyond the one model of NUC?

This will definitely go beyond the Intel NUC. The Intel NUC is our reference system for looking at Secure Boot and Intel TXT.  We will try to replicate our results on the Intel NUC to other platforms.

Leave a Comment

Please sign in to add a comment. Not a member? Join today