- If you remote wipe the phone then the device will be erased including keys if it is online or if it is offline it will be erased when it comes online.
- If it is offline but someone extracts the keys from it those keys are still useless as they are only able to decrypt messages specifically encrypted for that device and if you've remote wiped the phone then Apple won't tell other iMessage devices to encrypt messages to be sent to that device.
- If you change your iCloud password then your device will no longer be able to use the iMessage service and will also render the keys useless.
- If you remote wipe the phone but the phone is kept offline and the thief can access your phone (e.g. - break your passcode) then they can read old messages that were received before you did so. In this case the iMessage keys don't come into play and normal passcode/TouchID security is what safeguards the messages already received by that device.
- You cannot directly manage the iMessage keys for your iOS devices but you manage their access to iMessage by managing the device itself. When you remove a device from your iCloud account you implicitly remove the iMessage keys and render them useless
- Sniffing the connection between your stolen phone and Apple would not reveal your private iMessage keys because they are never sent over the connection and besides this it is difficult to sniff these connections since they are encrypted. Only public iMessage keys are sent over the connection.
The detail of this is mostly covered by Apple's iOS Security Guide which describes the mechanism iMessage uses in detail, see excerpt below.
Apple iMessage is a messaging service for iOS devices, Apple Watch, and Mac
computers. iMessage supports text and attachments such as photos, contacts,
and locations. Messages appear on all of a user’s registered devices so that a
conversation can be continued from any of the user’s devices. iMessage makes
extensive use of the Apple Push Notification service (APNs). Apple doesn’t log
the contents of messages or attachments, which are protected by end-to-end
encryption so no one but the sender and receiver can access them. Apple can’t
decrypt the data.
When a user turns on iMessage on a device, the device generates two pairs
of keys for use with the service: an RSA 1280-bit key for encryption and an
ECDSA 256-bit key on the NIST P-256 curve for signing. The private keys for
both key pairs are saved in the device’s Keychain and the public keys are sent
to Apple’s directory service (IDS), where they are associated with the user’s
phone number or email address, along with the device’s APNs address.
As users enable additional devices for use with iMessage, their encryption
and signing public keys, APNs addresses, and associated phone numbers are
added to the directory service. Users can also add more email addresses, which
are verified by sending a confirmation link. Phone numbers are verified by the
carrier network and SIM. With some networks, this requires using SMS (the
user will be presented with a confirmation dialog if the SMS is not zero rated).
Phone number verification may be required for several system services in
addition to iMessage, such as FaceTime and iCloud. All of the user’s registered
devices display an alert message when a new device, phone number, or email
address is added.
How iMessage sends and receives messages
Users start a new iMessage conversation by entering an address or name. If
they enter a phone number or email address, the device contacts the IDS to
retrieve the public keys and APNs addresses for all of the devices associated
with the addressee. If the user enters a name, the device first utilizes the user’s
Contacts app to gather the phone numbers and email addresses associated
with that name, then gets the public keys and APNs addresses from the IDS.
The user’s outgoing message is individually encrypted for each of the receiver’s
devices. The public RSA encryption keys of the receiving devices are retrieved
from IDS. For each receiving device, the sending device generates a random
88-bit value and uses it as an HMAC-SHA256 key to construct a 40-bit
value derived from the sender and receiver public key and the plaintext. The
concatenation of the 88-bit and 40-bit values makes a 128-bit key, which
encrypts the message with it using AES in CTR mode. The 40-bit value is
used by the receiver side to verify the integrity of the decrypted plaintext.
This per-message AES key is encrypted using RSA-OAEP to the public key of
the receiving device. The combination of the encrypted message text and the
encrypted message key is then hashed with SHA-1, and the hash is signed
with ECDSA using the sending device’s private signing key. The resulting
messages, one for each receiving device, consist of the encrypted message
text, the encrypted message key, and the sender’s digital signature. They are then dispatched to the APNs for delivery. Metadata, such as the timestamp
and APNs routing information, isn’t encrypted. Communication with APNs is
encrypted using a forward-secret TLS channel.
APNs can only relay messages up to 4KB or 16KB in size, depending on iOS
version. If the message text is too long, or if an attachment such as a photo is
included, the attachment is encrypted using AES in CTR mode with a randomly
generated 256-bit key and uploaded to iCloud. The AES key for the attachment,
its URI (Uniform Resource Identifier), and a SHA-1 hash of its encrypted
form are then sent to the recipient as the contents of an iMessage, with their
confidentiality and integrity protected through normal iMessage encryption,
as shown in the following diagram.
On the receiving side, each device receives its copy of the message from APNs,
and, if necessary, retrieves the attachment from iCloud. The incoming phone
number or email address of the sender is matched to the receiver’s contacts so
that a name can be displayed when possible.
As with all push notifications, the message is deleted from APNs when it is
delivered. Unlike other APNs notifications, however, iMessage messages are
queued for delivery to offline devices. Messages are currently stored for up to
The basics of the section above is this:
- Someone writes a message destined for you
- Their device contacts apple and retrieves the public keys for all your current devices
- Their device encrypts their message for each of your devices and sends it to Apple
- Apple forwards each individually encrypted message to your corresponding devices and will cache undelivered messages for up to 30 days
If your lost/stolen phone is no longer associated with your iCloud account (because you removed it) then the sender's phone would not receive a public key from Apple with which to encrypt a message for that device so a copy of that message would not be sent to your lost/stolen device which renders the keys on that device useless, so even if someone managed to pull your iMessage keys from the device, as long as that device isn't registered to you anymore they'll never receive a message that can be decrypted with them.
If you haven't removed the device from iCloud then sniffing on the connection between your device and Apple's servers
shouldn't be possible will be very difficult since it's done over a forward-secret TLS connection and the connection would fail if the device did not get a valid TLS certificate signed by the expected Certificate Authority which should make it difficult to perform a Man-In-The-Middle-Attack
If your phone was not deactivated with Find My iPhone and you did not change your iCloud password then the thief could just use your lost phone to read your messages as you would expect, however if you follow Apple's instructions for lost iPhones then the phone would either be inaccessible and/or not receive new messages, they have no way to extract your iMessage keys from your iPhone so they can't just put them on another device and if you put the phone in Lost Mode they can't even get into it to read your old messages without a passcode.
There is no way for you to directly manage your iMessage keys, they are managed under the covers by the devices registered to your iCloud account. When you remove a device from iCloud Apple will no longer send that device's public keys out when an iMessage sender asks Apple to send you a message. The keys on the device no longer matter as no new messages would be encrypted with the public keys so no new messages can be decrypted with the private keys on the device.
It is then down to your device security (passcode/touch-ID and on-device encryption) to protect the contents of the phone i.e. your old messages.
You can also read about some ideas on weaknesses in this security model at the links below:
I've added this section to address specific concerns of the OP on the iMessage key-thief sniffing their network.
You seem particularly concerned about the following scenario;
Your iPhone has been stolen (or hacked) and is now back in your possession but your iMessage keys have been stolen by a thief who is now going to sniff the network your phone is on so that they can read your messages.
Let's firstly say straight off the bat that what you are worried about is entirely possible, since anything is possible, and any system can be hacked with enough time and effort unless it is completely powered off (battery out and unplugged) and never connected to a network. So with that out of the way, let's explore how likely this is. In order for someone to obtain your iMessage keys and sniff your network to read your messages here's a list of what would need to happen.
- your phone would need to be stolen and returned to you
- the thief would need to have hacked your phone and extracted your iMessage private keys, defeating any device security that was in place such as TouchID, passcode or device encryption to do this and would then need to hack the OS or the hardware to extract the keys as there's no provided way to get at them
- your would either need to not know your phone was stolen or you may know but choose not to remove it from your iCloud account (thereby requiring the keys be renewed)
- the thief would then need to gain access to the same network as you, for example your home WiFi network. This will be relatively easy if it's unencrypted which is not typical and it will be relatively difficult if encrypted and password protected or has a MAC address whitelist for example. I can't comment on how secure your specific home WiFi is however.
- the thief would then need to intercept (or "sniff") packets destined for your phone and determine if they are iMessage messages and decrypt those using the keys, but there's a further hurdle, the traffic between your device and Apple is encrypted using a forward-TLS connection. So the thief would need to also crack that encryption to manage to read the message data, then use the keys they had extracted to decrypt the messages within after reassembling the messages over the TCP stream.
Frankly, all of the above is incredibly complex and unless you're Edward Snowden, or some other Enemy of the State I don't think anyone could be bothered that much to read your messages