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.