Communicating emergency information using satellites
Users with iPhone 14 or later can communicate over satellite links to provide various services. Satellite links impose significant bandwidth constraints and require security protocols with minimal bandwidth overhead. Regardless of communication type (Emergency SOS, SMS, or iMessage), Apple establishes a secure session between the off-grid device and an Apple datacenter. Devices preregister public key material with the server over cellular or Wi-Fi to save bandwidth while off-grid.
Core security architecture
When a device requests a satellite service, it establishes a secure connection with the Apple datacenter by referencing a truncated hash of its public key for key exchange. Each public-private key pair supports only a single session, with a maximum validity of eight hours. The server generates a corresponding public-private key pair for every client key pair in advance and shares the public key with the client.
After the session expires or finishes, Apple servers and the device remove the corresponding private keys, providing forward secrecy. Apple and devices register additional keys at regular intervals and after coming back online following a private key use, providing post-compromise security for satellite communications. Observers can’t identify users from session identifiers, as each device rotates identifiers on every session to prevent linking.
Emergency and Roadside Assistance over satellite
When users employ SOS or Roadside Assistance over Satellite, the secure connection to Apple (described above) protects the communication content. An additional encryption layer ensures that the content remains encrypted all the way to the application server, which forwards these messages to Apple emergency services and road assistance partners with transport encryption.
iMessage over satellite
When exchanging iMessages over Wi-Fi or cellular, devices exchange key material along with messages if any device in the sender’s or receiver’s group supports satellite service. Through this mechanism, devices receive regularly updated keys that enable them to encrypt and decrypt messages when cellular connectivity is unavailable and the device connects to satellite. Due to key lifetime limitations, users need to exchange messages within the last 30 days to communicate off-grid.
Each device generates symmetric key material and distributes it using iMessage encryption to encrypt its own outgoing messages. Each message uses a unique symmetric key derived through a Hash-based Key Derivation Function (HKDF) ratchet for its corresponding message counter. Upon receiving a message, the recipient’s devices look up the sender’s symmetric key material to derive the corresponding message key. When the device comes back online, new symmetric keys are distributed for subsequent sessions.
The sending device sends iMessages using Satellite only after it receives a signed payload from the recipient confirming that the device can receive messages over satellite.
Note: iMessage using satellite supports one-to-one messaging only, not groups.
SMS over satellite
When users send or receive SMS messages using satellite, the messages go to or come from a network Interworking Function (IWF). The IWF receives messages destined to the off-grid client from the sender’s carrier (the client appears roaming while off-grid, as it isn’t on the carrier’s local network). Similarly, the IWF delivers outgoing messages from the off-grid client to the recipient’s home carrier. Encryption and authentication protect SMS messages exchanged between the off-grid client and the IWF, preventing both Apple and those with satellite signal access from accessing or modifying the messages.
A Diffie-Hellman key exchange over the NIST P256 curve begins while a client is on-grid and completes when the client goes off-grid and establishes the initial satellite connection. Using HKDF-SHA-256, Apple and the device derive several keys from this key exchange. One key symmetrically encrypts (using AES-GCM with a 256-bit key) client information necessary for proper SMS routing (IMSI and SMSC). Another set provides bidirectional encryption of messages between the client and the IWF, also using AES-GCM with a 256-bit key.
Because satellite connections have lower bandwidth and higher latency than traditional cellular communications, not all incoming SMS messages reach the client immediately when it connects off-grid to prevent spam or low-value messages from delaying critical SMS retrieval. Instead, the system transmits inbound messages to the client only if either:
1. The client, while off-grid, has sent a message to the sender within the recent 24-hour period.
2. The sender is an approved sender (in the user’s emergency contacts or iCloud family members).
Otherwise, Apple stores the message encrypted on its servers until the client comes back online and retrieves the messages over traditional networks. To maintain user privacy, Apple ensures that the IWF doesn’t learn the user’s approved sender list.
The client uses HMAC-SHA-256 with a key derived from the session’s primary key to generate random pseudonyms for each phone number in each session. On session establishment, the client sends the pseudonyms for each phone number on the allow list to the Apple server. Similarly, it generates and sends a pseudonym to Apple each time the client sends an SMS to a phone number. This allows Apple to maintain a list of permitted sender pseudonyms for the session.
When someone sends the client an SMS after session establishment, the IWF encrypts the message and calculates the sender’s phone number pseudonym. It communicates this along with the encrypted message to Apple’s servers. The server compares the incoming message’s sender pseudonym against the allow list and forwards the encrypted message if there is a match.