Apple handles handoffs securely, whether from one device to another, between a native app and a website — even handoffs of large amounts of data.
How Handoff works securely
With Handoff, when a user’s iOS, iPadOS and macOS devices are near each other, the user can automatically pass whatever they’re working on from one device to the other. Handoff lets the user switch devices and instantly continue working.
When a user signs in to iCloud on a second Handoff-capable device, the two devices establish a Bluetooth Low Energy (BLE) 4.2 pairing out-of-band using APNs. The individual messages are encrypted much like messages in iMessage are. After the devices are paired, each device generates a symmetric 256-bit AES key that gets stored in the device’s keychain. This key can encrypt and authenticate the BLE advertisem*nts that communicate the device’s current activity to other iCloud-paired devices using AES256 in GCM mode, with replay protection measures.
The first time a device receives an advertisem*nt from a new key, it establishes a BLE connection to the originating device and performs an advertisem*nt encryption key exchange. This connection is secured using standard BLE 4.2 encryption as well as encryption of the individual messages, which is similar to how iMessage is encrypted. In some situations, these messages are sent using APNs instead of BLE. The activity payload is protected and transferred in the same way as an iMessage.
Handoff between native apps and websites
Handoff allows an iOS, iPadOS or macOS native app to resume user activity on a web page in domains legitimately controlled by the app developer. It also allows the native app user activity to be resumed in a web browser.
To help prevent native apps from claiming to resume websites not controlled by the developer, the app must demonstrate legitimate control over the web domains it wants to resume. Control over a website domain is established using the mechanism for shared web credentials. For details, see App access to saved passwords. The system must validate an app’s domain name control before the app is permitted to accept user activity Handoff.
The source of a web page Handoff can be any browser that has adopted the Handoff APIs. When the user views a web page, the system advertises the domain name of the web page in the encrypted Handoff advertisem*nt bytes. Only the user’s other devices can decrypt the advertisem*nt bytes.
On a receiving device, the system detects that an installed native app accepts Handoff from the advertised domain name and displays that native app icon as the Handoff option. When launched, the native app receives the full URL and the title of the web page. No other information is passed from the browser to the native app.
In the opposite direction, a native app may specify a fallback URL when a Handoff receiving device doesn’t have the same native app installed. In this case, the system displays the user’s default browser as the Handoff app option (if that browser has adopted Handoff APIs). When Handoff is requested, the browser is launched and given the fallback URL provided by the source app. There is no requirement that the fallback URL be limited to domain names controlled by the native app developer.
Handoff of larger data
In addition to using the basic feature of Handoff, some apps may elect to use APIs that support sending larger amounts of data over Apple-created peer-to-peer Wi-Fi technology (much like AirDrop). For example, the Mail app uses these APIs to support handoff of a mail draft, which may include large attachments.
When an app uses these APIs, the exchange between the two devices starts off just as in Handoff. But after receiving the initial payload using Bluetooth Low Energy (BLE), the receiving device initiates a new connection over Wi-Fi. This connection is encrypted (with TLS), and it derives trust from an identity shared through iCloud Keychain. The identity in the certificates is verified against the user’s identity. Further payload data is sent over this encrypted connection until the transfer is complete.
Universal Clipboard
Universal Clipboard leverages Handoff to securely transfer the content of a user’s clipboard across devices so they can copy on one device and paste on another. Content is protected in the same way as other Handoff data and is shared by default with Universal Clipboard unless the app developer chooses to disallow sharing.
Apps have access to clipboard data regardless of whether the user has pasted the clipboard into the app. With Universal Clipboard, this data access extends to apps on the user’s other devices (as established by their iCloud sign-in).
