question regarding hardware attestation / verified boot

Overlay1404

a few questions...

Is verified boot a deterent against physical attacks (ex: compromises by the refurbisher)?

Can verified boot prevent vulnerabilities in (even verified / unmodified) privileged blobs like bootloader / init / recovery / fastboot images?

Does GrapheneOS attestation detect extra hardware such as hidden microphone? Even if said hardware does not tamper with the system at all, assuming there’s enough available space in the case.

de0u

Overlay1404 Is verified boot a deterent against physical attacks (ex: compromises by the refurbisher)?

My understanding is that verified boot ensures that the bootloader, baseband firmware, and system partition are signed by either Google or the third-party signing key, and that the signing key hash is displayed if that is installed and used. So if a refurbisher were to install non-standard baseband firmware that hadn't been signed by Google that would be flagged by verified boot. However, verified boot, as a software mechanism, can't detect arbitrary tampering with hardware.

Overlay1404 Can verified boot prevent vulnerabilities in (even verified / unmodified) privileged blobs like bootloader / init / recovery / fastboot images?

If the question is whether verified boot can automatically inspect software on the device and detect all vulnerabilities, that is impossible.

Overlay1404 Does GrapheneOS attestation detect extra hardware such as hidden microphone? Even if said hardware does not tamper with the system at all, assuming there’s enough available space in the case.

If the question is whether software running on the motherboard has eyes that can see inside the case, despite it being dark, and report on small objects included inside, that is not possible.

ignoramous

de0u whether verified boot can automatically inspect software on the device and detect all vulnerabilities

This is a tall ask, but Fuschia defines Verified Execution as a defense against vulnerabilities (ref / mirror) and at its core it simply is "in higher privilege-modes execute carefully written verified/trusted code & deal with verified/trusted data only" (which seems similar to dm-verity on Android & ChromeOS, minus perhaps the carefully written part), while everything else is either sandboxed (3p code) or isolated (admin code).

de0u report on small objects included inside, that is not possible.

It is interesting to think about. I mean, the Kernel does know about the hardware that's brought-up post-boot (device trees / udev events). Aren't there mechanisms for Processors / SoC / elsewhere on the board, through its firmware (which is verified / trusted), to detect foreign plugins (pre-boot)?

de0u

ignoramous Many things are possible in theory (including Fuchsia). I believe the GrapheneOS developers have discussed wishing to move away from Linux to a code base that is smaller and simpler and more carefully written, which would be great. But I believe the original poster's question was whether the verified boot mechanisms in the bootloader can detect vulnerabilities in the firmware by inspection, which in a strong sense is provably not possible (Halting Problem).

ignoramous I mean, the Kernel does know about the hardware that's brought-up post-boot (device trees / udev events). Aren't there mechanisms for Processors / SoC / elsewhere on the board, through its firmware (which is verified / trusted), to detect foreign plugins (pre-boot)?

A standalone device that draws power from the battery but is not connected to any I/O bus would not be detectable by enumerating devices attached to I/O buses.

ignoramous

de0u A standalone device that draws power from the battery but is not connected to any I/O bus would not be detectable by enumerating devices attached to I/O buses.

Ah. A bug. Could inspections (say, ones as accessible as X-Rays?) make it cheaper then (as opposed to dumping the device altogether)?

I imagine severe damage likely comes from compromises capable of interfering with IO (as opposed to standalone bugs). So, to rephrase my original query:

Practically, can all such (attached) hardware be enumerated / discovered? Or, is it case that there exists designs where by these could "hide" even if, say, attached to buses?
If so, do high-end Android devices, esp Pixels (as part of Verified Boot or otherwise), alarm on such firmware/hardware it does not recognize / cannot verify?

Also, is it absurd to wonder if DICE (Device Identity Composition Engine or what I call a poor man's TPM) embedded into the battery or the power circuit (a "smart" battery, if you will) could potentially prevent standalone bugs (I get that the next stop in this cat & mouse game is bugs with pre-charged limited-use battery built-in).

de0u

ignoramous Ah. A bug.

That is my tentative interpretation of the original poster's question.

ignoramous Could inspections (say, ones as accessible as X-Rays?) make it cheaper then (as opposed to dumping the device altogether)?

This started somewhat speculative and arguably is increasingly so.

Personally, I assume that if somebody with sufficient resources decides to come after me in particular the chances of success are high. That is very different from the question of whether 100%, or 10%, or 1%, or 0.1%, of Pixels are systematically tampered with -- I don't think so, because I think repair shops would notice.

So for me if the question is "Could the Trilateral Commission plant a bug in my particular phone?", my bet would be "yes" (though this is not something I worry about, and I think they would be disappointed if they did). If the question is "Because it's theoretically possible that lots of Pixels might contain covert malicious hardware, shouldn't we look into countermeasures?", personally I don't plan to.

ignoramous

de0u "Because it's theoretically possible that lots of Pixels might contain covert malicious hardware, shouldn't we look into countermeasures?", personally I don't plan to.

Valid. I was mostly interested in this because there's so much effort going into building an open Root of Trust / Secure Element (viz lowRISC's OpenTitan), that if the board (like on Pixels) making use of such an advanced RoT/SE couldn't provide mitigations against tampering elsewhere on the chipset [0] (via trusted or verified or measured boot), then what's the point (of secure boot and RoT etc) ... [1]

[0] Attached, as in discounting: "A standalone device that draws power from the battery but is not connected to any I/O bus would not be detectable by enumerating devices attached to I/O buses."

[1] In my eyes, such a setup is like having an uber strict memory management for the userspace (MMU aside, with MTE, CFI, StackGuard, W^X and whole gamut) but straight up (no IOMMU) DMA to GPU and Baseband.

de0u

ignoramous I am actually a fan of open hardware efforts. It would be great to have a genuine phone (Wi-Fi, LTE including VoLTE, Bluetooth) based on open hardware with open firmware.

But, in my opinion, at present we are very far from that sort of situation. Also in my opinion the Pixel hardware is well ahead of anything else that's available, and also in my opinion the likelihood of a deliberate back door in the Pixel hardware is (a) small in an absolute sense, (b) small compared to other platforms, and (c) small compared the likelihood of an accidental vulnerability in Pixel hardware/firmware.

Finally, I believe that if a nation-state-level actor wanted to tap a specific device it would probably happen, even if it were an open-hardware/open-firmware device. For me the mass-surveillance / mass-malware-attack case seems to be pretty solidly addressed by GrapheneOS on Pixel devices, and the super-targeted well-resourced single-device case seems close to unwinnable.