Measured Boot Support Is Heading To Coreboot

[DrYak]

Nope, the remote part can create an arbitrary amount of different challenges, you cant replicate them unless you pry out some keys from the remote part aswell.
The way it works, is that you send data to the TPM chip and it will hash them. You wont be able to get the initial hash(es), but you get some derived hashes after sending in additional data.

Again, how can you be sure that you're actually talking to a remote (to the TPM) ?
How can you be sure that the "talking to the remote part" part of the software hasn't been overwritten with "NOP"s and replaced with a routine that simply says "success" ?

Case in point, that's a (over simplified) view of how busting a gaming console's protection works.

Unless you actually need to rely on some process that *happens inside* the remote, and thus are *required* to contact the remote (e.g.: use the TPM to decrypt some DRMed media), the OS might unknowingly have been modified in such a way that it never actually contacts the remote. (1)

Again, once you let arbitrary code run, you can't guarantee anything anymore. Including the capability from within the unsigned OS to actually realize that the OS is indeed unsigned.

An unsigned OS could run any arbitrary command set that wasn't validated by the signatory. Including code that simply "NOP"s out any attempt at detecting the absence of signature.

That's why you have things like Sony's Xperia (and other opendevices), once they have been unlocked and allowed to run unsigned code, will always display a warning message instead of the standard boot logo.

Because indeed, there's no way to guarantee anything anymore.

----

(1) - which is also the only point where gaming console hacking is limited. As long as you only run games locally, you can patch out any attempt for the game to detect that its running on an unauthorised OS (E.g.: imports, pirate copies, etc.)
As soon as the game *needs* by design to talk to online servers (e.g.: for online multiplay) the game might be patching into thinking that everything is going well, but the remote server can detetc somethign fishy and ban the account.

[oiaohm]

https://www.lightbluetouchpaper.org/2019/02/26/struck-by-a-thunderbolt/

Turns out I had missed a third poison pill path. Yes this is done over thunderbolt but if PCI buses are not secured nothing stops this by being done as a Mini PCI Wireless Network replacement on many laptops. Again this results in a machine that looks fine but in reality you are hacked.

Yes it one thing to attempt to secure bios. Its another to secure enough of the machine that the machine is truly secure.

And I bet there are still tones more physical attack locations attacker could go after to infect machine with physical access to the machine.

Only thing signing firmware does is make it harder for a remote attacker without physical access life a lot harder. Those with physical access all it will do is change attack method to use other methods that are harder to detect with very little overhead to their operations otherwise.

Items like wifi and 3g/4g modems with black box firmware embedded in hardware are quite dangerous threats and this is why I have always had problems with the libre projects stripping blobs out of the kernel and fall back on these embedded blobs of unknown quality.

[oiaohm]

so you broke the root of trust (CPU).

Completely broke root of trust of the CPU.

And how do you control this separate additional chip?

As the attacker by any means it connected up by. So yes the BMC installed chip can be talking out by network card conditions without the main cpu hearing about it.

The nightmare here is that these additional chips don't have to provide any visibility of their existence to the software running on the main CPU. They have full access to basically everything.

If I dump the memory for a check , will it then automagically detect that, and dont provide the tampered data?

It all depends how the BMC class chip is using jtag to inject modified code. Jtag can have a trap when a particular memory is read into the instruction cache of the cpu then it modify it in the instruction cache. If this is the method it using dumping memory would find basically nothing while being totally infected. If it used the jtag to modify the memory in the MMU then you would find something. There is more than 1 method to use to pull off this attack.

Also from the BMC class chip sitting on the jtag it could be reading data straight out of ram as well without doing any modifications to the memory you can see from the operating system side or executing in the main cpu. So this class of attack other than physical inspection can be very hard to detect.

Heck, if I have physical access to a computer I could just add sniffers on any peripheral, TPM and measured boot protects the software - it cant do more.

One of the interfaces you can access hardware sniffers on is the system JTAG. Basically for hardware diagnostics there is a huge stack of sniffers inside you hardware that your software cannot see. Evil maid class attackers accessing these JTAG interfaces are a nightmare to detect other than performing proper physical security.

Like using tamper evident bags around your laptops and phones if you ever leave them unattended) and if you have been separated from your device where it was not physically protected against physical modification performing a proper audit..

Same could be said for seatbealts.

I agree that lot of people think seat bealts are safer than what they are but we do see crash test demos that show that seat belts are not perfectly safe.

[discordian]

He is on the right track that you don't need to defeat the TPM protection just wrong usage of ME.

There are two ways in x86 that bring this plan of protection failed completely. Intel ME is one of them.

Method 1 the Intel ME and AMD equal backdoor.
To do this perfectly you will need a custom motherboard firmware chip. The custom feature is quite simple. When chip starts up cold it displays one set of contents after it gets a second command it changes to the contents the end user expects.

First stage would be load a firmware into the ME that make it no longer accepting new firmware disables the back door functionality as such it only pretends to take the ME turn off firmware and sends message to firmware chip to change modes.
Second stage it does perfectly valid by TPM information boot using the original bios before the system got evil maid hit this way..
Third state the ME uses it direct memory access to do modifications that you thought was no longer running.

Result you have a machine that passes boot verification but is infected anyhow.

so you broke the root of trust (CPU).

Next method is like the ME but more generic. Take BMC like OpenBMC this is a independent micro-controller that can live on server motherboard it can be connected to your systems JTAG. By JTAG outside firmware and operating systems control memory modification can be performed. A controller like this could be added to a motherboard in the same way a playstation 2 mod chip was added.

This is the overlooked case that what you have validated as clean can be modified after you validated it. Firmware hashs were clean when they were generated and passed to the TPM just the ME or something connected to the JTAG made them unclean after you validated.

Not lying to the TPM but still lieing to the user by deceiving them that the system validated when in fact what has been validated was replaced.

And how do you control this separate additional chip?

If I dump the memory for a check , will it then automagically detect that, and dont provide the tampered data?
Heck, if I have physical access to a computer I could just add sniffers on any peripheral, TPM and measured boot protects the software - it cant do more.

Measured boot could make a user think system is safer than what it really is.

Same could be said for seatbealts.

[oiaohm]

Thats pretty naive, thankfully nowadays it is not working like that.

Challenges are more like "Process this randomly generated stuff with the inner state after the BIOS was measured(usually hashed), which you will never see directly unless you manage to pry out the TPM chip and reverse its state". You never see the raw "bits", you can only use them as kinda private-key signature.
You would have to attack/replace the root of the chain - means some internal bootrom/OTP Memory on the cpu or the TPM chip to get anywhere.

He is on the right track that you don't need to defeat the TPM protection just wrong usage of ME.

There are two ways in x86 that bring this plan of protection failed completely. Intel ME is one of them.

Method 1 the Intel ME and AMD equal backdoor.
To do this perfectly you will need a custom motherboard firmware chip. The custom feature is quite simple. When chip starts up cold it displays one set of contents after it gets a second command it changes to the contents the end user expects.

First stage would be load a firmware into the ME that make it no longer accepting new firmware disables the back door functionality as such it only pretends to take the ME turn off firmware and sends message to firmware chip to change modes.
Second stage it does perfectly valid by TPM information boot using the original bios before the system got evil maid hit this way..
Third state the ME uses it direct memory access to do modifications that you thought was no longer running.

Result you have a machine that passes boot verification but is infected anyhow.

Next method is like the ME but more generic. Take BMC like OpenBMC this is a independent micro-controller that can live on server motherboard it can be connected to your systems JTAG. By JTAG outside firmware and operating systems control memory modification can be performed. A controller like this could be added to a motherboard in the same way a playstation 2 mod chip was added.

This is the overlooked case that what you have validated as clean can be modified after you validated it. Firmware hashs were clean when they were generated and passed to the TPM just the ME or something connected to the JTAG made them unclean after you validated.

Not lying to the TPM but still lieing to the user by deceiving them that the system validated when in fact what has been validated was replaced.

TPM is good in theory for a secure enclave on a system who boot process cannot be modified by ME or JTAG connected parts. TPM as a enclave to lock a identity to a particular machine its a good thing. TPM as a solution to validate firmware only works as long as JTAG and ME like items don't exist in the system.

Really a write protected motherboard firmware with validation code to check bootloader and up would be over all as effective without the extra hardware of TPM.

Measured boot could make a user think system is safer than what it really is.

[discordian]

Nothing prevents compromised hardware from lying to the TPM during the measurement.

First, the IntelME boots the CPU with these bits: 0xdeadbeef.

Then: "hi Mr. TPM, I am the IntelME and the CPU and I just booted these bits: 0xfeedface"

Thats pretty naive, thankfully nowadays it is not working like that.

Challenges are more like "Process this randomly generated stuff with the inner state after the BIOS was measured(usually hashed), which you will never see directly unless you manage to pry out the TPM chip and reverse its state". You never see the raw "bits", you can only use them as kinda private-key signature.
You would have to attack/replace the root of the chain - means some internal bootrom/OTP Memory on the cpu or the TPM chip to get anywhere.

[Terrablit]

Uh, no one's saying that if you have a team of engineers and hackers dedicated to ripping out every piece of hardware and soldering in new chips with new keys that this will stop it. But it will stop some current software attacks that are possible to thwart by tackling the low-hanging fruit. Eventually we'll probably find security chips that are transparently hackable from the software side. They'll be replaced with new ones as it goes on.

There's no security that's completely safe, but that doesn't mean that we just give up because perfection is unattainable. And some good goals are finding out if the signatures have changed since last boot. Given an unattended window of a few hours you should be able to detect several known intrusions when you return. There's bound to be some 0days that can slip the leash, but they won't come every day.

I'm pretty sure most of us are safe from roving bands of post-apocalyptic hackers collaborating to compromise our systems. If not, I don't know how we'd find the time to log onto the internet for a bit of snark.

[starshipeleven]

Nothing prevents compromised hardware from lying to the TPM during the measurement.

The point here is how can it tell it the right lie to say if it does not know it?

This system isn't checking against known values, it is just reporting MEASURED values to something else, that will have to do the check with his own known good values.

[starshipeleven]

What nonsense. You're expecting a compromised system to honestly report its own measurement to you.

No, the security comes from the fact that even a compromised system does NOT know what the right values are.

The system here is just returning the MEASURED hashes to whoever is asking for them.

[WesternSemiconductor]

The way it works, is that you send data to the TPM chip and it will hash them.

Nothing prevents compromised hardware from lying to the TPM during the measurement.

First, the IntelME boots the CPU with these bits: 0xdeadbeef.

Then: "hi Mr. TPM, I am the IntelME and the CPU and I just booted these bits: 0xfeedface"