Thanks for pointing this out. My Chromebook is from the era when they still had a screw... :-)
Can you recover a modern Chromebook that has had all of its Flash memories tampered with or wiped externally, with just a USB cable? With a debug cable? That seems to be one of the major things that sets apart iDevices from others.
At least this design doc still says local attacks involving e.g. replacing writable storage are out of scope (which they very much aren't for iDevices):
From block diagrams it seems Cr50 security chip in recent Chromebooks just interfaces with AP Flash and the write protect pin, and thus verified boot isn't tied to silicon tamper resistance. That puts Chromebook at around the same level as T2 Macs in terms of tamper-resistance, in fact a bit worse (on T2s the T2 chip is the flash from the AP's point of view, so you can't just tamper with an external flash memory. You could MITM it in principle, though I heard the T2 Mac boards are also designed to make this difficult to pull off with buried traces).
Digging a bit more (the docs on this are really scattered...), it seems Cr50 RW storage can be recovered from the RO loader by using a physical USB-UART cable, but that requires taking apart the machine, since it won't work over USB, only UART. There is no mention of any Boot ROM recovery mechanism or of how the RO firmware is authenticated; RO is supposed to be "Read Only" in on-chip Flash, but eliminating every avenue for compromise of writable Flash is very hard (e.g. glitching the Boot ROM; I've seen too many "secure" microcontrollers compromised to bypass read or write protect in various ways...), so this approach is quite a bit weaker than Apple's: on these devices, you need specialized hardware to go to the lowest level of recovery, and you can't even recover from certain kinds of volatile storage loss or compromise, while on Apple devices any end user with no specialized knowledge can follow a few simple documented steps with another machine and a USB cable and an app in the App Store (or idevicerestore) to fully, securely, and confidently restore all the writable firmware on the machine to factory condition, and the process relies only on truly immutable mask ROM*.
* I can't say for sure there isn't any auxiliary writable flash that would let you brick the machine in some other way, but I haven't found anything yet. The prime suspect, the USB-PD controller chip that's in the path of the DFU USB connection (and thus could break it if it doesn't work), smells like it boots from ROM until the OS instructs it to launch the application image from Flash. It reports being in "DFU" mode until we issue the first power state switch command to bring it up, and we know these chips are custom Apple versions with Apple ROMs and the ROM does contain most of the USB-PD stack... so this sounds like the kind of thing Apple would get TI to do, since they really care about being resistant to bricks and persistent compromise.
(if you have unlocked CCD and didn't lock yourself out of it — you could e.g. forget the password)
you can do whatever you want using flashrom with the SPI flash chips for both AP and EC.
> this design doc
Hmm, there's no timestamp for the page itself but the picture attachments are dated 2009.
> Cr50 RW storage can be recovered from the RO loader by using a physical USB-UART cable
That sentence sounds weird, not sure why it wouldn't be recoverable via the SBU cable — the RO firmware is just an earlier build of the same firmware that does offer the GSC/Cr50 UART among its consoles via SBU.
"RO public key in ROM, RW public key in RO" so they thought of that, the root of the root of everything is truly immutable silicon.
> e.g. glitching the Boot ROM
There are likely measures against this, since this is a "secure chip" designed in modern days by Google rather than some shitty vendor.
But either way, attaching probes for voltage-glitching the root of trust is far beyond the capabilities of the proverbial "evil maid" :)
And the glitching question should apply to Apple and whoever else as well.
> any end user with no specialized knowledge can follow a few simple documented steps with another machine and a USB cable and an app in the App Store (or idevicerestore) to fully, securely, and confidently restore all the writable firmware
What Google does for the "normal people" AP flash recovery: only the RW CBFS partition is writable from the AP, and for recovery it boots from an RO partition: https://doc.coreboot.org/security/vboot/index.html#recovery-... (there's a theme to everything the CrOS team does haha… surprise, the EC also uses the RO+RW mechanism)
Yes, this doesn't protect against the "I'm a normal regular user with no debug access and someone desoldered my SPI flash, tampered with it and soldered it back" but… come on :) Especially considering hard-to-open laptop cases and WSON-8 flash chips, that's just a ridiculous scenario to care about.
Tell that to all the governments who keep trying to get Apple to break into their own devices... It's not ridiculous at all, the NSA does this all the time (supply chain intervention). And WSON-8 really isn't that hard to swap, a hot air rework station will do it in a couple minutes. I've done much worse than that ;)
Good to hear the RO partition is also authenticated, though. My mention of glitching was mostly around whether there was trust placed in Flash at any point, since then a one time glitching attack could compromise the machine. You could still brick it by screwing up RO, but at least not compromise it. And again, those attacks aren't nearly as hard as you think. People have productionized these things for console modchips; that's at the level where someone with a cheap soldering iron can do it.
As for chip design, I'm sure Google did a better job than most random vendors (they all keep making the same mistakes...), but Apple has been doing chip security for much longer so they also have had quite a lot of time to build up experience in this area. I would trust Apple's chips over Google's (at least design quality wise), and I say this as a xoogler ;)
Actually, I think I can come up with an apt comparison. Google has crazy good production system security, probably better than anyone else; they've just been doing it for long enough, have been targeted by governments (China incident, NSA wiretaps), and have the motivation to just keep pushing things forward. Apple is on a very similar level with system/silicon security, in part for similar reasons. They're both just in their own league in those categories.
No, it's just Flash so it's a point of persistency. If you rely on on-chip flash integrity for security, a one-time glitch can compromise the system forever. If you rely on it for availability, then a random glitch (or even just cell decay) can brick your system forever.
Can you recover a modern Chromebook that has had all of its Flash memories tampered with or wiped externally, with just a USB cable? With a debug cable? That seems to be one of the major things that sets apart iDevices from others.
At least this design doc still says local attacks involving e.g. replacing writable storage are out of scope (which they very much aren't for iDevices):
https://www.chromium.org/chromium-os/chromiumos-design-docs/...
From block diagrams it seems Cr50 security chip in recent Chromebooks just interfaces with AP Flash and the write protect pin, and thus verified boot isn't tied to silicon tamper resistance. That puts Chromebook at around the same level as T2 Macs in terms of tamper-resistance, in fact a bit worse (on T2s the T2 chip is the flash from the AP's point of view, so you can't just tamper with an external flash memory. You could MITM it in principle, though I heard the T2 Mac boards are also designed to make this difficult to pull off with buried traces).
Digging a bit more (the docs on this are really scattered...), it seems Cr50 RW storage can be recovered from the RO loader by using a physical USB-UART cable, but that requires taking apart the machine, since it won't work over USB, only UART. There is no mention of any Boot ROM recovery mechanism or of how the RO firmware is authenticated; RO is supposed to be "Read Only" in on-chip Flash, but eliminating every avenue for compromise of writable Flash is very hard (e.g. glitching the Boot ROM; I've seen too many "secure" microcontrollers compromised to bypass read or write protect in various ways...), so this approach is quite a bit weaker than Apple's: on these devices, you need specialized hardware to go to the lowest level of recovery, and you can't even recover from certain kinds of volatile storage loss or compromise, while on Apple devices any end user with no specialized knowledge can follow a few simple documented steps with another machine and a USB cable and an app in the App Store (or idevicerestore) to fully, securely, and confidently restore all the writable firmware on the machine to factory condition, and the process relies only on truly immutable mask ROM*.
* I can't say for sure there isn't any auxiliary writable flash that would let you brick the machine in some other way, but I haven't found anything yet. The prime suspect, the USB-PD controller chip that's in the path of the DFU USB connection (and thus could break it if it doesn't work), smells like it boots from ROM until the OS instructs it to launch the application image from Flash. It reports being in "DFU" mode until we issue the first power state switch command to bring it up, and we know these chips are custom Apple versions with Apple ROMs and the ROM does contain most of the USB-PD stack... so this sounds like the kind of thing Apple would get TI to do, since they really care about being resistant to bricks and persistent compromise.