By: Igor ((Not Given)), July 23, 2004 9:42 pm
Room: Moderated Discussions
Anonymous (nospam@nospam.com) on 7/23/04 wrote:
---------------------------
>Jan (jvorbrueggen@mediasec.de) on 7/23/04 wrote:
>---------------------------
>>>Now, how long before someone hacks the Intel encoding of their processor patches ?
>>
>>If they did it properly using asymmetric cryptography, you won't.
>>
>
>It's most likely a one time pad combined with a special CRC algorithm. Public key
>encryption was far too complex to implement in microcode or hardware back when Intel
>designed the update format for the Pentium II around 1996. That same basic format
>is used today (although the specific encryption algorithm might have changed.)
>
>An extremely well equipped engineer could probably analyze the P4 die itself to
>extract the key mask and maybe the signature algorithm; it's fairly well established
>where in the circuitry this takes place. However, it's unlikely someone would waste
>the time and money doing this just out of curiosity. Only major competitors would
>be interested, which basically means AMD - and they clearly have no problem developing
>their own technology without reverse engineering Intel's design.
>
Just one thing, new Prescott chips have variable microcode size (stored in previously reserved fields of the header). I have seen updates 4000 bytes long (before it was 2000 bytes max). They also have added something to the end of the update data called extended signature table which is meant to signalize that the said update supports more multiple processors steppings and/or models.
Regarding the key mask and signature, would it be possible to use any simpler method?
Assuming that the CPU does not load the update directly into the microcode ROM/RAM because it needs to authenticate and decrypt it first, there is a possibility that it performs decryption/authentication in the L1 or L2 cache. Would it be possible to break it using ITP debug thing and read the decrypted update from cache?
---------------------------
>Jan (jvorbrueggen@mediasec.de) on 7/23/04 wrote:
>---------------------------
>>>Now, how long before someone hacks the Intel encoding of their processor patches ?
>>
>>If they did it properly using asymmetric cryptography, you won't.
>>
>
>It's most likely a one time pad combined with a special CRC algorithm. Public key
>encryption was far too complex to implement in microcode or hardware back when Intel
>designed the update format for the Pentium II around 1996. That same basic format
>is used today (although the specific encryption algorithm might have changed.)
>
>An extremely well equipped engineer could probably analyze the P4 die itself to
>extract the key mask and maybe the signature algorithm; it's fairly well established
>where in the circuitry this takes place. However, it's unlikely someone would waste
>the time and money doing this just out of curiosity. Only major competitors would
>be interested, which basically means AMD - and they clearly have no problem developing
>their own technology without reverse engineering Intel's design.
>
Just one thing, new Prescott chips have variable microcode size (stored in previously reserved fields of the header). I have seen updates 4000 bytes long (before it was 2000 bytes max). They also have added something to the end of the update data called extended signature table which is meant to signalize that the said update supports more multiple processors steppings and/or models.
Regarding the key mask and signature, would it be possible to use any simpler method?
Assuming that the CPU does not load the update directly into the microcode ROM/RAM because it needs to authenticate and decrypt it first, there is a possibility that it performs decryption/authentication in the L1 or L2 cache. Would it be possible to break it using ITP debug thing and read the decrypted update from cache?