Re: Wahh wah
"A 256-bit AES key that’s burned into each processor at manufacture. It cannot be read
by firmware or software, and is used only by the processor’s hardware AES engine."
All well and good, but that suggests the hardware AES only uses a UID that the device itself can only access. Which means it isn't that which is shared for messaging. From watching an iPhone's behaviour it seems to act in the following way when you start a conversation with a new contact:
Query Apple's servers to see if the details you have exist in their list of known devices. (your message button turns blue when it comes back)
Apple's server returns a UUID for the other phone's messaging path, this will then be stored against the contact.
On typing a message Apple checks if the other device has notified the server of its online status recently.
The message is sent and encrypted by two keys only known to each device, this I may have incorrectly assumed would be 3DES above.
If the hardware AES can take supplied keys they have a variety of options (and we can select as many as we like from the menu, as long as the CPU is able to keep up with our consumption) as a UUID is 128bits, the AES takes 256 bits, we have two UUIDs.:
Multiple encryption - similar to 3DES, encrypt with key A, decrypt with key B, encrypt with key A
Generated key - splice the two keys in your chosen recipe
Whilst working with Mifare cards there was a solution forwarded about using the UID of the card, and a cheap processing algorithm to generate the key, thus to render an attack you would need to know how to create the key.