search

quarkslab / titanm

This repository contains the tools we used in our research on the Google Titan M chip
Apache License 2.0
182 stars 14 forks source link

Another one inaccuracy in the EU-21-Rossi_Bellom-2021_A_Titan_M_Odyssey.pdf paper #9

Closed NewDwarf closed 2 years ago

NewDwarf commented 2 years ago

Sorry, guys for reporting about more issues. Maybe they exist because of some reasons (Google asked or something else). The presentation describes incorrect range of the key blob structure which should be encrypted. The claimed range is 0x2c0 - 0x3c4. Actually, this range is 0x2c0 - 0x5e0. That looks weird (as it is already doesn't look like a typo) but you missed padding (0xdc... array) from this range.

dmell commented 2 years ago

Hello,

Thank you again for your contributions to this project. I took another look at how the key material is manipulated, and indeed in the decryption flow a buffer of size 800 is being manipulated, suggesting that this was the one being decrypted. I will correct the inaccuracy, although the precise details behind this are still hard to be determined, due to the use of hardware features. Did you also notice this error by looking at how the buffers are passed and copied around, or did you find any other evidence?

Please let us know if there is anything further you would like to add on the topic, and of course feel free to reach out via email/twitter as well.

NewDwarf commented 2 years ago

Did you also notice this error by looking at how the buffers are passed and copied around, or did you find any other evidence?

Originally, I noticed that the presentation claims the padding is outside of the buffer being encrypted. As I never saw such implementations, I reversed this part in the RW_* firmware to confirm an inaccuracy in the presentation.

NewDwarf commented 2 years ago

Regarding the key blob structure. Not sure whether the key blob' header is really called 'header'. I would name it 'magic' which has 4 bytes length. Then the integer value follows which is constant equal to 2. I guess it is key blob version number integer stored in little endian. 0x00x40x8.

Regarding the 'Alg code'. It is delivered as an integer in little endian or 4 byte array. But it doesn't matter. The presentation doesn't mention for the key blobs for the symmetric and asymmetric algorithms. For the symmetric algorithms, NOT only AES (0x3) is delivered. The 3DES key can be delivered encoded by 0x4 integer as well as HMAC key encoded by 0x5. As I mentioned it occupies 4 bytes in the range 0x2b4 - 0x2b7. I would name this field 'key_purpose' (AES/3DES/HMAC) Asymmetric algorithms are RSA (0x1) and EC (0x2).
... That's not all. I will add more a bit later.

dmell commented 2 years ago

I reply to your previous comment for now, but still feel free to add more later, as you anticipated.

Let me start by saying that the slide we are discussing about is a backup slide that we added to the presentation to address potential questions on StrongBox and how keys are effectively exchanged with Titan M and stored on device. The figure is just an example of a key blob (in this case, for an AES key). Of course also other ciphers are supported, as you correctly pointed out, but we never claimed the opposite.

Regarding the names we gave to the various fragments, please note that those derive simply from our choice/interpretation. We can call the first bytes "header", "magic", or anything else. I don't think that is particularly important, as long as the purpose is correct.