Check In security
Check In allows a user to choose a contact thatโs notified if the userโs supported device doesnโt arrive at a predetermined destination. When the user chooses a contact to start Check In with, an iMessage is sent to that contact with details about the session including their destination. The initiating userโs device also generates an access token and Check In encryption key. The Check In encryption key is sent in a second iMessage; however, this message is held by iMessage servers rather than being immediately delivered. Because this message is end-to-end encrypted between the user and their designated contact, its contents are not available to Apple.
While the initiating userโs device is making progress toward its destination, it periodically sends a heartbeat message to iMessage servers, which extends the expiry time before the Check In encryption key message is delivered. If the device is turned off or loses connectivity, iMessage servers automatically release the iMessage containing the encryption key to the contact when the expiry time is reached. The Check In encryption key message can also be released if the device isnโt making progress toward its destination. When released in this fashion, the access token is included.
During a Check In session, the initiating userโs device periodically collects relevant Check In data (for example, location and battery level), encrypts it with the Check In key, and uploads it to iCloud. Apple doesnโt have access to the Check In key and canโt access the uploaded data.
Ending a Check In session requires user authentication. If the user cancels a session, the encrypted data and iMessage containing the Check In encryption key are securely deleted from the server.
If the Check In device hasnโt arrived at its destination as expected, or the configured timer expires, the chosen contact receives the iMessage containing the Check In encryption key. There are two scenarios where this could happen:
After a loss of connectivity: In this case, the designated contact doesnโt have the access token and the contactโs device performs a second check to determine whether enough time has elapsed since the last heartbeat. The contactโs device requests the encrypted Check In data from the server, and the server performs a third check to further confirm if sufficient time has passed since the last heartbeat. If so, the server provides the contact with the encrypted Check In data, and the contact can decrypt it with their Check In key.
After the userโs device determines they arenโt making progress toward their destination: In this case, unless the user cancels or extends the Check In when prompted, the designated contact is provided both the access token and Check In encryption key. The contactโs device provides the access token to the server, allowing it to download the encrypted Check In data. The data can then be decrypted with the Check In key.