I'm very happy to see that a vulnerability introduced in a May 2022 was found, diagnosed, and fixed in a June 2022 update.

After something went wrong, a bunch of things went right very quickly. Nice to have good news on a Monday morning.

> Thanks to the leak functionality that we built with this exploit, we can now read arbitrary memory on the chip. This means we can now have access to any readable address. As a consequence, we can dump the secrets stored in the chip (such as the Root of Trust sent by the Pixel bootloader when the Titan M is updated).

> One of the most interesting consequences of this attack is the ability to retrieve any StrongBox protected key, defeating the highest level of protection of the Android Keystore. Similarly to what happens in TrustZone, these keys can only be used inside Titan M, while they are stored in an encrypted key blob on the device.

I thought the whole point of making a hardware security chip (rather than using a general purpose microcontroller, possibly with crypto acceleration hardware) is that the private keys would be protected by the hardware design. So you could use the private key to e.g. create a digital signature but its impossible to read out the private key itself, outside of potential side-channels.

This is amazing work!

I was surprised to see that the reward was set at 10k initially. Granted, it was bumped to 75k later, but even that seems on the low side considering the degree of compromise that occurred here.

I may have given up too early during my (fairly brief) research on CVE-2019-9465. I let the lack of firmware source code availability stop me at the time, but in hindsight the presence of "0dd0adde0dd0adde" in the ciphertext likely indicated a crash in Titan M as well. Perhaps there would have been a similarly interesting path to exploitation there.

They missed the opportunity to call the article "Attack on Titan M".

undefined

Very cool.

I wonder why companies still leave the UART pins accessible. Fine they're on the chip, but just remove the trace and slow down attack evolution is worth the cost of a board revision surely...

The one bit I didn’t understand was how they bypassed W/RX. How did they manage to get the new code to be marked as RX after writing?

I thought I read the whole thing. Did I miss that explanation?

undefined

Sounds like an amateur hour at that Google team. While post authors are putting blame on the un-safeness of C, absence of user input validation, like that integer from a message, is a path to a very unhappy place independent of language. The rest of the exploited places of that Titan software seem to be similarly sloppy.

This is an elegant attack that effectively compromises all Titan M chips. They were even able to dump all securely stored private cryptographic keys, which Google acknowledges in the disclosure timeline.

Even still though, the award Google initially gave was only $10k USD(!). They finally bumped it to $75k USD after complaint and review, but Google's bug bounty program claims up to $1 Million USD.

If fully compromising Google's own security chip to dump all private keys isn't worth the full $1 Million bounty, I honestly don't know what is.

Really, what would, in the mind of those on the internal committee, constitute justification for the $1 Million bounty?

> As a reminder, there are two conditions to perform this attack. First, we need to be able to send commands to the chip, either from a rooted device (required to use nosclient), or physically accessing the SPI bus.

> Then, we need a way to access the key blobs on the Android file system, which can be done again by being root, or with some exploit to bypass File Based Encryption or the uid access control.

For a moment I thought this is something related to the anime

A lot of software can be cracked "with only one byte". Finding which one is the hard part.

Don't lose sight of the fact that the purpose of this and other TPM-like devices is to hide secrets from its owner.