Sorry all, the formatting came out badly. I'm forced to use Outlook for work and it doesn't do quoting or inline well. I'm resending with better formatting.
It probably makes sense to switch to direct messages going forward to avoid spamming coreboot.org with these details further. So, moving everybody else to Bcc.
I think the community is interested in these discussions and it is not spam, so I'll continue forwarding to the list unless this is all Top Secret or something.
Thanks for the reply Andrey and thank you Ron for forwarding the message. So, only the bootloader portion is not open source, but everything else is? How big is the bootloader portion in either bytes or lines of code?
Up to 16K.
That's a bigger black box than I'm comfortable with. Why can't it be open sourced so people can see what this code is doing? I don't think anyone here is eager to have another Intel ME situation where there is a closed source chip which can't be disabled doing mysterious things no one can know about.
My understanding of the chip is that there is no networking capability. It has no internal NIC and isn't wired into the main PCI bus so it can't communicate with the NIC on the mainboard.
Correct.
This is important for security as we don't want the risk of anyone remotely flashing the bios with malware for example.
Are you talking about chromebooks? You won't be able to use a Google security chip with cr50 on your own product that is not a chromebook (or in some rare cases some other Google device that uses ChromeOS).
Whatever hardware that ships with it. Chromebooks certainly. I'm not interested in any custom hardware at the moment.
However, I want to be sure my understanding is correct because the documentation here https://chromium.googlesource.com/chromiumos/platform/ec/+/cr50_stab/docs/ca... lists a capability of "OpenNoLongPP IfOpened Allow opening GSC without physical presence" Opening the GSC without physical presence implies some remote operation capability.
Case closed debugging capabilities that you are looking at in that doc are accessible (after proper authorization) over a USB-C port, which is directly attached to the Google security chip on chromebooks. "opening GSC without physical presence" in this context refers to the "CCD Open" procedure described in that doc. The owner can change the configuration, including what authorization is needed to change those policies.
So if the only way to access the CCD is through physical presence, why is there a setting to disable the physical presence proof?
Is there any way for the end user to verify the loaded CR50 firmware is correct and hasn't been tampered with?
Bootloader performs firmware verification on every Google security chip reset and wouldn't boot a firmware image, which was tampered with. And after it was verified, the active firmware image is protected from modification at run-time. So, if it runs, it is not tampered with. And if you care about physical attacks in your model, you can establish a secure comm channel to cr50 firmware, and verify that you are not talking to an interposer the usual way you would do it with a TPM: read and verify EK certificate, use ActivateCredential with EK to certify a restricted TPM signing key, then, for example, use Certify with that restricted key to ensure that a salting key that you created for your auth session is actually a TPM key, and encrypt you session salt with it.
So the chip verifies itself. That's all well and good, but I'd really like to be able to verify it myself, manually. Something like deterministic builds which I can compile on my local system and then verify what's running on the chip matches what's in the source repository or at the very least get some kind of checksum that matches a checksum Google has published.
If the AP or EC firmware is overwritten does that clear/reset the TPM registers?
Sorry, didn't quite understand the question. If you overwrite AP/EC firmware, you can trigger TPM owner clear, but that depends more on what AP firmware does with the TPM. Cr50 is (mostly) following what a TPM would do to handle resets, TPM2_Startup and TPM2_Clear commands, where the latter is available with lockout/platform auth. There are some additional protection for some configuration data even through owner clear, but overall the owner clear flow is very similar to what a spec-compliant TPM would use. Opening CCD also usually clears the TPM state.
My question was regarding secure state. So if I have some keys stored in TPM registers which are required to unlock the encrypted hard drive, I want to only unlock if the computer is in a verified secure state. If someone has flashed the EC or AP firmware without my knowing about it that would no longer be a secure state and I would hope the CR50 would force a reset of the TPM if the firmware has been modified so I don't try to boot a computer in an insecure state and possibly expose passwords or other encryption keys. So when you say opening the CCD clears the TPM state, does that clear the TPM registers that are used for verified boot and/or store HD encryption keys?