Talk:GID Key

drg

Would this be vulnerable to a cold boot attack?

geohot

I really doubt the AES key is ever in memory. This is an attack against drive encryption, not hardware coprocessors. Fault analysis or timing would be our best bet.

Vaumnou

Unless you can cause read faults by browning out the chip or the ROM is external, you can't use fault analysis. And if the ROM is external, it would probably be easier to unsolder it and read it directly.

pumpkin

it isn't external

Vaumnou

Then the only way to do fault analysis would be to poke around on the chip directly. Is it known whether the die is face-down or face-up on the PCB?

ta

this sounds like a job for leet hacking super hero TA Mobile!

geohot

Hopefully the amount of time varies from encrypt to encrypt, although I believe most AES engines are fixed in time.

Browning out the chip is more what I was thinking. Probing the chip is far beyond my abilities, but I could brown the chip out for a clock cycle or two and determine where in the pipeline I am. I would need to know a lot more about the coprocessor design. It is standard? HDL model out there?

Vaumnou

According to Wikipedia, the known timing attacks for AES are *cache* timing attacks. This won't work if the hardware crypto engine has one-cycle read access to its ROM, and I know of no reason why it wouldn't.

side-channel attack

Some super-smart guy should try that http://m.technologyreview.com/communications/39855/ --M2m 09:53, 12 March 2012 (MDT)

Keys

I think we should list the keys for all processors here. Anyone agree? --5urd 16:29, 17 June 2012 (MDT)

The problem is that nobody knows the GID-key. Or were you talking about the derived key 0x837? For key 0x837 we don't need to list all, because only the S5L8900-one is useful. Is there anything else you would want to list here? --http 00:54, 18 June 2012 (MDT)

Is there any possible way to dump it? (Debug the decryption engine?) Or is it encrypted itself? --5urd 16:41, 18 June 2012 (MDT)