[ggm]

I'm not seeking to criticise this product, I think this is a great development.

But, for almost all people this is shifting from one kind of "trust me bro" to .. another. We're not going to be able to formally prove the chip conforms to some (verilog?) model, has no backdoors, side channels, you-name-it. We're in the same place we were, with the same questions. Why do we trust this and the downstream developments? Because we do.

I know people who worked on cryptech, and I definitely had trust in their work, personal commitment to what they did, but that's "who you know" trust. The non transitive quality of this kind of trust is huge.

To be more critical my primary concern will be how deployment of this hardware is joined by significantly less benign design choices like locked bootloaders, removal of sideloads. To be very clear that's a quite distinct design choice, but I would expect to see it come along for the ride.

To be less critical, will this also now mean we get good persisting on device credentials and so can do things like X.509 certs for MAC addresses and have device assurance on the wire? Knowing you are talking to the chipset which signed the certificate request you asserted to before shipping is useful.

[benlivengood]

Take a look at how Matter handles this; manufacturer certificate to vouch for hardware integrity which gets superceded by the fabric's root CA on commissioning (enrollment in the fabric).

This is basically the best we can hope for until we get nanofabs at home and can build our own secure enclaves in our garages.

Trust decision theory goes like this; it it were possible for the manufacturer to fully control the device then competitors would not use it, so e.g. wide industry adoption of OpenTitan would be evidence of its security in that aspect. Finally, if devices had flaws that allowed them to be directly hacked or their keys stolen then demonstrating it would be straightforward and egg on the face of the manufacturer who baked their certificate on the device.

Final subject; 802.1x and other port-level security is mostly unnecessary if you can use mTLS everywhere which is what ubiquitous hardware roots of trust allows. Clearly it will take a while for the protocol side to catch up; but I hope that eventually we'll be running SPIFFE or something like it at home.

[nerdsniper]

These things should be manufactured to be IRIS-compatible. IRIS is the "Infra-Red, In Situ" technique which lets you image the silicon of a chip through the packaging to verify that you don't have a counterfeit.

https://arxiv.org/pdf/2303.07406

Like, for example, the Boachip-1x MCU.

https://www.cnx-software.com/2026/03/04/dabao-board-features...

[michaelt]

> To be more critical my primary concern will be how deployment of this hardware is joined by significantly less benign design choices like locked bootloaders, removal of sideloads. To be very clear that's a quite distinct design choice, but I would expect to see it come along for the ride.

A justifiable concern, given sentences like "strongest possible security guarantees that the code being executed is authorized and verified" and "can be used across the Google ecosystem and also facilitates the broader adoption of Google-endorsed security features across the industry"

[fc417fc802]

> not going to be able to formally prove the chip conforms to some (verilog?) model

Sure you can. Get together as a group. Purchase a large lot of chips. Select several at random. Shave them down layer by layer, imaging them with an SEM. You now have an extremely high level of confidence that all the chips in the lot are good.

Physical security aside, I share your concerns about the abusive corporate behavior that widespread deployment of such hardware might enable.

> Knowing you are talking to the chipset which signed the certificate request you asserted to before shipping is useful.

Can't an fTPM with a sealed secret already provide that assurance? Or at least the assurance that you actually care about - that the software you believe to be running actually is. At least assuming we stop getting somewhat regular exploits against the major CPU vendors.

[octagons]

This is the general premise behind Ken Thompson’s “Reflections on Trusting Trust” and I highly recommend you read it if this is something that interests you.

[PunchyHamster]

I'm more worried by the motivation for the whole secure chain. We will not own our devices and the encryption keys will be stored in vault of <ecosystem provider> like MS or Google, free to peruse by the government

The entire push seems to be motivated by actors that want to deny users access to their own devices in thinly veiled promises of "security".

It's basically asking someone to give their company your house keys on nothing more than "trust me bro".

And it's completely opposite of how it should be, it should be my device that I then can give the vendor app limited sandbox that I can access fully, not the other way around.

[pabs3]

Another thing to look up here is the bootstrappable.org community. They started at the software layer, how to create binaries from scratch without using any existing binaries. They are also interested in the hardware layer too.

[pabs3]

Look up bunnie's talks about hardware security, its basically impossible, there are too many parts to the chain leading up to the end user holding hardware in their hands that are all attackable.