Conversation

Replying to
TrustZone supports arbitrary code so it doesn't really provide anything that can't be done with TrustZone, but it does many things that aren't possible with a TPM. The reason for moving away from TrustZone is that the implementation has massive attack surface and other issues.
1
Replying to and
Pixel 2 security chip was a standard embedded Java smart card able to run applets, with signature verification / downgrade protection. It could essentially do the same things with far less attack surface than TrustZone, but a lot more than a custom implementation from Google.
1
Replying to and
An extension to twitter.com/DanielMicay/st would be enforcing the configured limit on number of attempts before a wipe with hardware. It's all stuff they could have done on the Pixel 2 Java smart card (or with TrustZone) but they want minimal attack surface and more control over it.
Quote Tweet
Replying to @DanielMicay and @dwizzzleMSFT
Weaver performs a form of key escrow where random tokens are stored there for each credential derived authentication token and only provided to the OS if it provides the correct authentication token. That's used to implement exponentially increasing throttling on key derivation.
1
1
Replying to and
Checked recent tweets from people that work on Pixel security and here's a confirmation that they're moving the Pixel 2 security chip functionality to their own chip, which I had just assumed: twitter.com/redpig/status/.
Quote Tweet
Replying to @ThomasBertani
Yup - implements AVB state storage, Weaver HAL, and the new Keymaster Strongbox HAL which is accessed with new flags to Keystore. Strongbox impl have a separate batch key for atteststion too (for differentiation from the TEE impl), also Protected Confirmation test-of-presence