Quote:
Originally Posted by Rupan
Impressive! If I've understood you correctly, you conducted a known plaintext attack between 4.50 and 4.70 to recover the XOR key, then confirmed your guess by applying the XOR key to 4.46 and observed that the result is identical to the same byte area in 4.70. Then they reused the same encryption key? They won't make that mistake again.
Why do you say that this won't help for 4.76 and up?
|
I found it better explained on
Wikipedia
If you encrypt 2 different messages with the same key/iv (e.g. device keys in FW4.50 and FW4.70) and you know the plaintext for 1 of these messages (yes because FW4.50 = FW4.46 keys, I guess this because the device masks are identical) you also know the plaintext from the other message (i.e. device keys for FW4.70)
It doesn't work for FW4.76 because FW4.76 keys are not the same as FW4.70. So even though we have the different device keys encrypted with the same key/iv (e.g. FW4.76 and FW4.82) we don't know the plaintext for FW4.76 so we can't get the plaintext for FW4.82.
Well some keys will still be the same as in FW4.70 probably, but those are revoked and useless. We need the XOR for the changed keys. (update: Actually we can find keys that change from 4.76 to 4.81/4.82 if the key in the same position doesn't change from 4.70 to 4.76)
Maybe there is some other attack possible, I barely know anything about AES encryption. But I'm guessing we need someone using a debugger to figure out how to get the aes-ctr key sets for FW4.50-FW4.70 and FW4.76-FW4.82 that are used to encrypt the device keys. Maybe it has gotten easier since we now also know the plaintext FW4.70 device keys. Maybe the aes-ctr keys are in the aacs module but encrypted with a different key, or the keys are being sent to the aacs module by another module...