The OF protocol is based upon strong privacy goals such as non-trackable owner computers, anonymity of finder devices and confidential location reporting. But this analysis examines a considerable body of detailed and complex research into how well these goals have in fact been engineered into the overall solution to the problem of lost devices and reduce this weight of material into something more comprehensive1. Furthermore, the resulting impact of exposure to possible cyberattack, such as unauthorised access and correlation of device geographical location.
Apple successfully offered Offline Finding for a range of products in 2019, the idea being that finder devices would detect apparently lost devices by their employing Bluetooth Low Energy (BLE) emission, the finders then using their internet connectivity to report the location of a lost device back to the owner. Apple has made some very forceful statements about the robustness of the underpinning security of the service , but these are not born out in detailed cybersecurity analysis. However, the OF approach seems to provide two principal vulnerabilities:2
BLE is used between smart devices to advertise their presence in a confined locality. Apple devices use BLE in services such as AirDrop and Apple Wireless Direct Link (AWDL). The OF protocol uses ECC3 to encrypt location reports. Apple's OF implementation also employs internal Keychains and iCloud . In essence, Keychain is just a database of keys, passwords and certificates used in a plethora of other security enforcing functionality. Each keychain item contains a keychain access group which defines the use of keychain items, these being accessible via an entitlement architecture compiled into application binary files . This is a strong security architecture, but it can be circumvented by disabling Apple's system integrity protection approach, or employing use of 'jailbroken' devices, so it is far from impregnable protection. Using iCloud keychain, OF is able to share rolling key advertisement for all devices belonging to an owner and completes synchronisation, including their location by retrieving and decrypting location reports from finders, thus identifying devices without an internet connection and their geographic position in a specific timeframe. Apple attests to keep these details private, but their detailed explanation is somewhat wanting in such an assertion.
Owner devices share a common Apple Id, which is irrespective of the number of Apple Ids a single owner may actually have. A device without internet connection will consider itself lost and therefore start to emit BLE advertisements with a public key in the hope that other random finder devices in their vicinity will receive and transmit their approximate location back to Apple's iCloud servers (which is an ECC encrypted, end-to-end transaction). The owner's other devices can access these records and decrypt them to identify the geographic position of the owner's lost device.
A number of cyber attack models arise from the two aforementioned vulnerabilities, and this report is designed to be a layman's overview of a very complicated matter, therefore such detailed cybersecurity analysis of BLE and server communications/storage of encryption keys is resisted (but a more detailed analysis is available on request4). However, for owner's devices, offline finding can be reduced to stages that include device key synchronisation, device loss, device finding and device searching.
Master keys for advertisement and beaconing are created by each device. These include a public-private key pair that is expressed on a specific elliptic curve (see footnote 3) including a 32 byte symmetric key and these are never disclosed in the OF process of rolling advertisement key generation. The advertisement keys are synchronised across all the owner's devices and constitute an encrypted inventory of devices5 stored in Apple's database under the iCloud key chain. A finder device receiving advertisement from a lost device (including its public key), applies it own location to the lost device and encrypts both its device details and those of the lost device, using its public key (lodged within Apple iCloud beacon store) so both devices are now linked. OF enabled devices that loose internet connectivity emit BLE advertisements every 2 seconds (and will increment the advertisement public key every 15 minutes). Genuine finder devices6 scan for OF lost device advertisement and will transmit encrypted geographic location report and time in batches7, to Apple's iCloud servers.
Any of the owner's devices can be used to request the download8 of location reports for a lost device, and will reverse the report encryption process by using the private, synchronised advertisement key and receive genuine, time sequenced geolocation reports9 from verifiably genuine finder devices referring to the owner's lost device(s). Multiple report sources can be correlated by the owner, to achieve greater location accuracy and reconstruct movements of a lost device over a limited time span10.
Vulnerabilities are exposed at specific stages in the OF process. The finder and owner devices reveal identities via their Apple-Ids to the Apple iCloud servers and thus, the data becomes open to abuse, especially when the participants in such an interaction may be the subject of of non-beneficent interest to third parties and/or with the capability and motivation to exploit such process weaknesses.11
The risks arise from attackers ability to exploit macOS derived advertisement keys which are cached, unencrypted, on local devices and accessible by local applications, thus accessing what may be sensitive geographic location data. BLE is susceptible to attackers capability to transmit perfectly legitimate lost device advertisements at false geographical locations, therefore the reliability of the data is questionable (see foot notes 1, 2 and 6) and furthermore, the underpinning techniques may not be sufficiently dependable in the provision of critical services as specified in 12. Finally, the Apple iCloud servers identify proximity of both the lost and finder devices13 and this exposes the devices location (and by extension, the owners) to a style of correlation attack that may be highly undesirable, especially in civil societies that place high value on both freedom and privacy.
 Apple Inc. Apple Platform Security.2020.url:https://support.apple.com/guide/security/, (Page 139),(Visited on 06/05/2021)
 Apple Inc. Core Location. url:https://developer.apple.com/documentation/corelocation/ (Visited on 06/05/2021)
 Privacy Preserving Contact Tracing, covid19.apple.com/contacttracing (Particular reference to Bluetooth Specification) (visited 0n 09.05.2021)
Alexander Heinrich*, Milan Stute*, Tim Kornhuber, and Matthias Hollick
Who Can Find My Devices? Security and Privacy of Apple’s Crowd-Sourced Bluetooth Location Tracking System, March 2021
 Electronic Communications - Statutory Instrument, Network and Information Systems Regulations - in force from 10th May 2018, uksi_20180506_en, (accessed on 08/05/2021-1415HRS)
 NCSC-Connected-Places-Cyber-Security-Principles-May-2020,(Page 3 final bullet), [Accessed 07.05.2021]
1This analysis should be of particular interest to those involved in the very similar locational architecture recently deployed in HM Government's NHS Track and Trace Application,  and whose implementation has accordingly, had mixed levels of success due to certain critical assumptions being false.
2These may not seem serious, but when coupled with a number of false assumptions around the Track and Trace Application,  things become very problematic due to the inevitable compounding of requirements (including specific security requirements that are presently unresolved) such as the present extension to include connectivity to health records in order to provide a Vaccination Passport Travel Service.
3Elliptic Curve Cryptography is a type of public key cryptographic technique employing mathematical operations (over finite fields) with both public and private keys. This is a very strong and effective way to protect information, but only if the key management is correct. Apple's OF implementation uses NIST P-224 elliptic curves and only offers a maximum of 112-bit encryption strength.
4These include cryptographic analytics, network traffic analytics, log analyses etc. but there is a great deal more technical information in the references provided.
5This critical information is encrypted using Advanced Encryption Standard – Galois Counter Mode (AES-GCM) using the keychain label 'Beacon Store' but the key length/complexity is limited.
6Such devices employ Apple's proprietary Secure Enclave Processor architecture as the Trusted Execution Environment...where present. Older Apple equipment may not offer this level of attestation, so the level of assurance will necessarily be much lower.
7A maximum of 4 reports from a single lost device, every 30 minutes.
8The genuine owner of the lost device will be required to authenticate with Apple's iCloud server using their Apple-Id accompanied by a search party token specific to the device. (The search-party-token varies according to a random, time-specific mechanism deployed by Apple and includes short lifetime anisette data for accommodating previously authenticated systems.)
9Genuine reports comprise a NIST approved Secure Hash Algorithm(SHA) processed owner's advertisement public key.
10It is not entirely clear how long Apple retain the geographic location information, but considering the volumes of data from such a network of IoT reporting, the OF service will probably represent quite a narrow window of opportunity available to owners of lost devices.
11Many countries' law enforcement may wish to employ legal powers of data seizure, placing 'perceived dissidents' at risk.
12As specified for network and information systems defined in legislative regulations  (pg.3 – 3(g)), HMG as operators of essential services and relevant digital service providers, especially regarding the enforcement of breach of duties.
13This is true even if the devices are in a quiesced state such as flight mode.
All rights reserved. CyberDefenceDynamics