Hi Brian,
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.
On Mon, May 1, 2023 at 2:20 PM Brian Milliron Brian.Milliron@foresite.com wrote:
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.
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).
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.
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.
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.
------------------------------
*From:* Andrey Pronin apronin@chromium.org *Sent:* Monday, May 1, 2023 12:30 PM *To:* Brian Milliron Brian.Milliron@foresite.com *Cc:* coreboot@coreboot.org coreboot@coreboot.org; rminnich@gmail.com < rminnich@gmail.com> *Subject:* Re: [coreboot] Re: How open is Google CR50?
---------- Forwarded message --------- From: *Brian Milliron via coreboot* coreboot@coreboot.org Date: Fri, Apr 28, 2023 at 4:52 PM Subject: [coreboot] Re: How open is Google CR50? To: ron minnich rminnich@gmail.com CC: coreboot@coreboot.org coreboot@coreboot.org
Thanks. I'm not really looking to build my own custom hardware, just evaluate what's already out there. I was hoping someone here would know if this chip is fully open or not.
Hi Brian, I'm leading the h/w security (that includes cr50 firmware) team at ChromeOS and I had this message forwarded to me as I'm not on the coreboot mailing list. Not sure if there was more discussion since, but here are some top-level details re cr50/GSC openness. Let me know if you have further questions.
- Google security chip is not an open hardware, the datasheet for it is
not generally available. And you won't be able to run arbitrary code on it
- it accepts only firmware signed with Google keys.
- The bootloader firmware stage for Google security chip is not open
source.
- cr50 is the name of the main firmware stage that runs on the chip.
cr50 implements the applications required for ChromeOS. It is open source on chromium.org.
I also liked the suggestion earlier in the thread of looking at opentitan.org if you are interested in open hardware.
*From:* ron minnich rminnich@gmail.com *Sent:* Friday, April 28, 2023 5:28 PM *To:* Brian Milliron Brian.Milliron@foresite.com *Cc:* coreboot@coreboot.org coreboot@coreboot.org *Subject:* Re: [coreboot] How open is Google CR50?
if you want the open source part, you want to go with opentitan.org, I can put you in touch with folks if your company has interest.
On Fri, Apr 28, 2023 at 2:52 PM Brian Milliron via coreboot < coreboot@coreboot.org> wrote:
I'm trying to decide if the Google Titan Security chip CR50 is trustworthy or not. I see it has some open source, but I'm not certain if the whole thing is open source or if there are some binary blobs included. Does anyone here know?
coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
-- Andrey