Does this research mean that Titan M is compromised?

[NewDwarf]

The short answer is "No".
This research missed one important feature which is the key ladder' 'key manager'. This key manager is a part of the silicon which does at least sideloading of the AES, HMAC key into the internal key storage registers which are not visible for any part of software and not accessible via JTAG.
To derive the real key inside the key manager block, many personalization things are used like DeviceID, Root key, and other hardware secrets. Some of them are stored in OTP, but some are implemented as a gate array. Moreover the bus to this gate array is scrambled to obfuscate the optical reverse engineering of the hardware.
Internally, the key manager uses KMAC to derive the hidden keys inside the key ladder.
This means that that the Titan M is still safe.
The SW bug to be found and knowledge of data transferred between the Titan M and application processor is almost nothing for breaking security of Titan M as the key ladder' security is still not compromised.
This is a good news as originally, after reading the presentation and white paper, I thought how Google does such fatal mistake in the security design.

[max-r-b]

Hi. There are a lot of issues, not sure where to put my answer :) For further discussion, you can also contact us directly on mrossibellom@quarkslab.com and dmelotti@quarkslab.com.

Just to clarify something: we never claimed we broke Strongbox. But it is true that we did not identify the key ladder as part of the key elements to generate KEK. (We saw it, but didn't know why it was there). The fun fact (or not) is that the vendor reviewed the papers and did not comment anything on this matter.

Moreover the bus to this gate array is scrambled to obfuscate the optical reverse engineering of the hardware

We did not really looked the hardware internals of the chip itself (except the pinout and the phone PCB). But maybe you did? For the record, we performed our the static reverse analysis of Strongbox at the early stages of this research, so without the leak "feature". And we did not try to generate the KEK afterwards.

Anyway, thank you for reporting this. It is good to have someone double-checking what we did. I would like to perform further investigation on this before updating the paper. Anything you can share is welcomed.

[NewDwarf]

Just to clarify something: we never claimed we broke Strongbox.

That was my first false impression. Sorry for that.

The fun fact (or not) is that the vendor reviewed the papers and did not comment anything on this matter.

Probably, they don't want to reveal more information.

We did not really looked the hardware internals of the chip itself (expect the pinout and the phone PCB). But maybe you did?

In the best case, the external layer of the Titan M should be dissolved by concentrated nitric and sulphuric acids. This will expose silicon layer. If it is the Hardware Security Module, there can be additional shield layer to protect the key ladder area against optical attack and against the probes. There are two options here. To reverse engineer it by optical microscope or/and use the micro probes to read the key ladder bus. The bus lines can be scrambled to make difficult reversing.
In my opinion, it is useless to sniff the pinouts of the Titan M as nothing sensitive will not be exposed there.
No, I cannot implement such physical attack as I don't have required tools.

The more realistic option to break the key ladder is to implement fault injection in the middle of the 8-th and 9-th AES rounds (in case of AES-128). If Titan M has no adequate protection, faults can leak sensitive information to recover the real AES key. To sync the glitch pulse and execution of AES encryption in the key ladder, you have to make sure that the Titan M doesn't have internal clock driver with drifted clock frequency. Glitch detection is usually implemented via the non-maskable interrupt which just reset the chip.
To make glitching more effective and bypass the glitch sensors, you can decrease the VCC and try to find the minimal VCC level which is still able to run the chipset normally.

Moreover, you cannot extend the attack on other Titan M based devices as the unique key is generated in the key ladder to encrypt and authenticate the key blob.

[NewDwarf]

I believe the DFA attack against the AES should work. The attack scenario is simple

1. Send the GenerateKey request.
2. Calculate the delay of key ladder' Mix Column (13 round for AES-256) and inject the fault (VCC glitch).
3. Collect encrypted by AES-256-CTR responses.
4. Run statistical analysis of obtained results.

[max-r-b]

To reverse engineer it by optical microscope or/and use the micro probes to read the key ladder bus.

There is in fact a shield on the Titan M (https://www.techinsights.com/blog/google-pixel-3-xl-teardown). Not sure if it is active or not. Anyway we do not have the required tools or skills to perform such advanced hardware attack.

I believe the DFA attack against the AES should work. The attack scenario is simple

Yes I was curious about DFA (EM or VCC) attack at the early stage of this project, but at the time we had a little knowledge of the chip footprint and no code execution on it, plus I am a complete newbie on this (speaking only for myself)... Another thing that was scaring me was the risk to burn the chip. The price of the chip (even for broken chip, it is difficult to find one for less than 100 euros). In fact, I bricked one while probing the different components and test pins around the chip on the Pixel PCB...

[NewDwarf]

It is necessary to understand one important thing before applying the DFA attack. Do you have a possibility to push or create somehow the same plaintext key blob by exploiting the existing bugs in RW part of FW and then jump at key blob processing location? The main goal is to get the same cryptogram on each try. This is very important to understand for mounting further fault attack.
If it is possible, I am almost sure you can apply the DFA attack and get the real AES key in plaintext.

plus I am a complete newbie on this

It is not a big problem. Originally, I also thought it is difficult. I have some glitching experience and we can try to proceed together. I guess the best choice for now are the ChipWhisperer tools.

[doegox]

We know DFA, I'm the author of PhoenixAES (used by Yifan Lu on the Playstation Vita) and of a tutorial for the chipwhisperer.
Still, it is not currently on our plans and with a key specific to each device, the interest is quite limited.

[NewDwarf]

@doegox Yes, I am familiar with your awesome PhoenixAES tool. I used it for breaking commercial AES whitebox implementation. Thanks for making it publicly available!
@max-r-b Currently, it is normal practice to make hardware security more "personalized". The Titan M is one example. And the trivial attacks based on reverse engineering aimed to find the SW bugs are totally blocked by the underlying security hardware. So, regardless of like it or not, the modern attacker have to mount an attack which would break the whole security. In this particular case, the DFA attack is a real option. But in general case is to understand how expensive will be an attack aimed at the specific security hardware. Of cause, each research and its conclusions are totally dependant of the budget.

[max-r-b]

I am closing this issue. See my comment here: #7 (comment)