I think it's more complicated than that IMO, by controlling the platform i.e. by signing keys and authenticating users they certainly can impersonate clients to others clients, but I doubt they can collect users private keys generated on users devices (of course they could if their app was explicitly sending private key to their servers but I doubt they do and I don't see a reason why they'd do it, in any case they don't need to do it).
When IOS 6.1.4 gets pushed to your iPhone in the future, consider how difficult it would be for Apple to add code that copies your privately generated keys back to Apple for "key-escrow purposes".
That's a claim that hasn't been independently verified. Absent such proof, I'd expect there to be a ready mechanism to get key material off the chip.
Even if the claim is correct, there is no guarantee that the implementation that does use the key material can use it in a way that doesn't reveal the key in another way.
Other supposedly secure key storage mechanisms have had disappointingly little luck against determined attackers. Ask any cryptographer about attacks that reveal key info in deployed and implemented crypto-systems.
I'm doing my best to track this conversation, but it's a bit over my head. So say the key cannot be read. What is to prevent Apple from delivering an iMessage software update which just POSTs each message to api.nsa.gov/warrants?
If I can copy-paste an iMessage, it's getting turned into plain text at some point...
