Track You: A Deep Dive into Safety Alerts for Apple AirTags

Bluetooth-based item trackers have sparked apprehension over their potential misuse in harmful stalking and privacy violations. In response, manufacturers have implemented safety alerts to notify victims of extended tracking by unknown item trackers. In this study, we specifically investigate the anti-stalking mechanism of Apple’s AirTag. We identify and analyze potential triggers of safety alerts that have not been examined in previous research, such as the local time, the victim’s device model, AirTag’s battery life, and the distance between the AirTag and the victim’s device. Furthermore, we demonstrate a novel possibility of developing a stealthy cloned AirTag capable of tracking victims directly on the Find My app while circumventing safety alerts on the victim’s device. Our experiments demonstrate that, despite regular updates to the public key and MAC address, our cloned AirTag can provide real-time location updates even with a four months old key, thereby highlighting the challenges in designing a robust anti-stalking framework. Furthermore, we propose practical solutions to mitigate stalking risks from cloned AirTags and enhance the existing anti-stalking safeguards for AirTags. These suggestions seek to provide a foundation for similar Bluetooth-based item trackers to improve their anti-stalking protections while ensuring optimal tracking efficiency. We conducted rigorous experiments to validate our findings, ensuring their accuracy and reliability. Our evaluation highlights that safety alerts take over 8 hours to appear during the day and are more prompt during the night, particularly after 11 pm.


INTRODUCTION
Item trackers such as Apple AirTags [6], Samsung Galaxy Smart-Tags [43], and Tile Mate [46] are small, affordable, battery-operated devices that can be attached to valuable items such as keys, wallets, cameras, and luggage to make them trackable.These devices are paired with a smart app that leverages Bluetooth Low Energy (BLE) [36] technology to help users easily locate their belongings.If an item tracker is not in range of the owner device, it relies on nearby smartphones (finder devices) to hear the BLE advertisements and update its location to a central server, enabling the owner to determine the tracker's location.The precision and effectiveness of an item tracker depend on the size of its finder network, as well as the number of participating devices in close proximity [32].Since 2013, Tile had established itself as the market leader, with over 35 million trackers in circulation [47].However, the introduction of AirTags brought about a profound paradigm shift as they leveraged the seamless integration of Apple's Find My network with the native Find My app [5], which has been pre-installed on all Apple devices since 2015.This resulted in a massive finder network of almost 1.2 billion devices [15], empowering AirTags with unmatched location precision and tracking capabilities.
Unfortunately, AirTags have also brought severe privacy concerns to the forefront, with more than 150 reported cases of unwanted tracking, stalking, and theft of high-end cars [16].In most cases, victims were unknowingly tracked, harassed, threatened, or even murdered [33] by their estranged partners or spouses who had secretly placed the AirTag in their belongings [3,9,13].These incidents have prompted two victims to file a class-action lawsuit against Apple [4].Digital privacy experts, tech safety watchdogs, and digital rights advocates worldwide have expressed concerns about the potential misuse of AirTags for stalking or human trafficking and raised questions about who would be liable if the technology is misused; the stalker or the manufacturer.These privacy concerns are exacerbated by other major smartphone manufacturers, such as Samsung and Google, who are following Apple's approach to BLE item trackers.For instance, Samsung has introduced SmartTags, which can be tracked using Samsung's Galaxy Find Network [39] and the SmartThings Find app [29] that is pre-installed on 0.2 billion devices [49].Reportedly, Google is also developing its tracker tags that are projected to have an even more extensive network of over 3 billion devices [41].As a result, these privacy concerns are only expected to escalate.Technology companies must take proactive measures to ensure that their products are not used to violate individuals' privacy and safety.
While item trackers operate within their unique finder networks and may differ in their implementation, they share the common fundamental functionality of locating lost items and are subject to similar privacy and security concerns.Given Apple's current market dominance, this paper explores privacy concerns related to BLE item trackers using Apple AirTags as a prime example.To address stalking concerns, Apple has incorporated various antistalking measures in iPhones, such as sending a time-sensitive safety alert to the victim's device when it detects an unknown AirTag moving along for an extended time (refer to Figure 1).The victim can locate the AirTag using Precision Finding or by playing a sound.However, such protections have limitations.For instance, if the Bluetooth of the victim's device is turned off, the device will not generate any alert.Also, to prevent false alarms for individuals close to the victim, safety alerts are typically triggered if the victim has been stalked for several hours or upon arrival at their home (or frequently visited location) with that unknown AirTag [27].Unfortunately, the victim's device generates the safety alert after few minutes of reaching home.By that time, the stalker may have already become aware of the victim's location, creating a significant security and privacy risk.Additionally, proactive safety alerts are not available to Android users.Although Apple released an Android application called "Tracker Detect" in December 2021 [7], it is highly insufficient, as the victim must conduct a manual scan to detect if an AirTag has been tracking them for a prolonged period.
Existing literature provides limited insights regarding safety alerts, primarily focusing on determining the minimal exposure time and distance required to trigger them [38].Consequently, additional research is needed to fully understand the scope and effectiveness of Apple's anti-stalking measures.In addition, the development of OpenHaystack [24], an open-source framework that enables stalkers to create fake AirTags and exploit Find My services highlights the urgent need for action.As finder iPhones are unable to distinguish between genuine and fake AirTags, they keep uploading location reports to the Apple server.This poses a persistent stalking risk until Apple devises effective measures to block fake AirTags.Several researchers have also demonstrated the feasibility of circumventing safety alerts by modifying specific bytes in the BLE payload [38], disabling the speaker [10], and periodically broadcasting new public keys [19] to avoid detection by the victim's device.These works reveal deficiencies in Apple's anti-stalking measures that need addressing to provide improved protection against stalking.In contrast to AirTags, other BLE item trackers even lack this essential proactive safety alert feature, rendering them more vulnerable to stalking.
Our study aims to answer the following research questions: (1) How do safety alerts work within the AirTag's ecosystem?(2) What are the limitations of the AirTag's ecosystem in effectively preventing stalking incidents?(3) What are the challenges associated with building a robust anti-stalking framework that effectively safeguards users' privacy, ensures efficient tracking functionality, and maintains wide applicability across different BLE item trackers?
Our study thoroughly evaluates the effectiveness of safety alerts, providing an unprecedented examination of the circumstances that trigger them, including the time of the day, the model and screen status of the victim's device, the mode and battery life of the AirTag, the victim's mode of transportation, the density of people in the vicinity, the distance between the AirTag and the victim's device, and whether the victim visited any "Significant locations" while being stalked.Our evaluation highlights that safety alerts take more than 8 hours to appear during day time, and are more prompt during late-night hours, particularly after 11 pm.Moreover, if the victim has activated the Significant Location feature on their device [27], which tracks frequently visited places, such as their home or workplace, safety alerts are activated within 10 minutes of arriving at such location.Based on the insights from the performance evaluation, we aim to identify any potential weaknesses that stalkers could exploit to circumvent safety alerts.To accomplish this, we developed a stealthy cloned AirTag that utilizes an ESP32 controller to broadcast the public key of a genuine AirTag.Unlike existing fake AirTags, our cloned AirTag allows uninterrupted tracking of victims directly through the Find My app, without relying on the OpenHaystack Framework.Our analysis of BLE advertisement frames revealed previously undisclosed bits that prevent safety alerts for unfamiliar AirTags on the victim's device, regardless of the distance traveled or exposure time.With this, we demonstrate that despite regular updates to public keys and MAC addresses, our stealthy cloned AirTag can stalk victims on the Find My app even with a four months old key, thereby exposing significant weakness in the Airtag's ecosystem.This occurs because the victim's device cannot distinguish between a genuine AirTag (which changes MAC address and public key daily) and a cloned AirTag (with unchanging attributes), resulting in continuous location updates on the server.Furthermore, the study provides practical solutions for improving existing anti-tracking deterrents and preventing the misuse of cloned AirTags, ultimately reducing the possibility of harmful stalking.Our recommendations can help manufacturers of other BLE item trackers implement effective anti-stalking measures.
Specifically, this paper presents the following contributions: (1) We thoroughly analyze Apple's safety alerts to gain insights into the functioning of the safety alert system and experimentally determine the conditions under which alerts are displayed to the user, such as the victim's location, mode of transportation, local time, and battery level of the AirTag.(2) We demonstrate how a stalker can use a stealthy cloned AirTag to track a victim on Apple's Find My app indefinitely, for a period of four months, without triggering any safety alert on the victim's device.This highlights potential weaknesses in AirTag's ecosystem.(3) We provide recommendations to improve anti-stalking measures for AirTags and other BLE item trackers.This includes slight modifications at the device and server to block cloned AirTags, validate public keys, enforce limits on the lifespan of these public keys, and offer an optional aggressive scanning feature for at-risk individuals.

BACKGROUND AND RELATED WORK
This section explains the functionality of AirTags, their BLE advertisement structure, and the anti-stalking measures implemented by Apple.It also covers relevant research conducted on this subject.

How AirTags Work
AirTags are offline item-tracking devices that do not have GPS, Wi-Fi, or cellular connectivity and utilize BLE for communication.
AirTags are compatible with any Apple device running iOS/ iPadOS 14.5 or later, including iPhones, iPads, and iPod Touch.To locate an item, the AirTag is paired with the owner device through the Find My app.The pairing process links the AirTag's unique serial number to the owner's Apple ID and generates an elliptic curve P-224 public-private key pair and a random secret.This pairing information is securely stored on Apple's backend for up to 25 days [25].The random secret is used to derive an infinite number of rotating key pairs that are synchronized across all owner devices signed in to the same Apple account via the iCloud keychain.When the AirTag is within BLE range of the owner device, it can be located directly on the Find My app.However, when the owner device is not in proximity, the AirTag relies on Apple's crowdsourcing network for location updates.The Offline Finding (OF) protocol, illustrated in Figure 2, outlines how these offline devices are tracked within the Find My ecosystem.The AirTag periodically broadcasts BLE advertisements containing a public key every 2 seconds.The public key is regularly rotated to prevent user tracking through these advertisements [31].When finder devices detect the BLE advertisements, they upload location reports encrypted with the advertised public key along with its hash to the Apple server using HTTPS POST request [24].These reports contain the current location, an estimate of location accuracy, the time the advertisement was received, and the attempted upload time.Each request is authenticated to ensure that only legitimate Apple devices can upload reports to the server.In order to retrieve the location reports, the owner device initiates an HTTPS POST request to the Apple server, authenticating itself using the associated Apple ID.This process generates a tokenized one-time password called AnisetteData, which is then used by the device to request the location reports for the most recent public keys of the AirTag [24].In response, the Apple server provides all the reports associated with the requested keys.The owner device decrypts these obtained reports using the corresponding private key and displays the AirTag's recent location on the Find My app.In short, Apple protects privacy by incorporating end-to-end encryption for location reports, frequent rotation of public-private key pairs to prevent user tracking, and utilizing anonymous location updates sourced from nearby finder devices.

AirTag's BLE Advertisement
The standard BLE advertisement has a maximum size of 37 bytes, of which 6 bytes are reserved for the MAC address and 31 bytes for the payload [35].However, to fit the 28-byte public key of the AirTag in the BLE advertisement, Apple stores the first 6 bytes of the key in the MAC address field and the remaining 22 bytes in the manufacturer data field, as illustrated in Figure 3.To identify the MAC address as a random static address (that does not require registration with IEEE), the first two bits of the MAC address field are set to 0b11.As a result, the first two bits of the public key are stored in the byte 29th of the BLE payload.
In addition, the BLE advertisement also includes other fields such as payload length, data length, status byte, data type, OF type, and hint byte.For AirTags, the data type is 0xFF (manufacturer-specific), and the company ID is 0x004C (Apple).The Offline Finding (OF) type indicates the type of service requested by offline devices, e.g., 0x12 for Find My services or 0x07 when the AirTag is unpaired.The status byte encodes the device type (e.g., Apple device1 , Find My device2 , AirTag, or AirPod) and its battery level (i.e., full, medium, low or critically low).For instance, a status byte value of 0x10 represents a fully charged AirTag, while 0x50 signifies a medium battery level.The hint byte changes every 15 minutes but is not part of the public key.Therefore, the public key of an AirTag remains unchanged for almost 24 hours until its MAC address and data bytes are modified.Finally, a CRC field is included in the BLE advertisement to ensure the packet's integrity.

AirTag's Operational States
The AirTag operates in four primary internal states; unpaired, connected, nearby, and disconnected [26].These states are determined by the AirTag's connectivity and distance from its owner device and dictate the content and frequency of its broadcasts.

Unpaired:
This is the AirTag's default setting before it is paired with an owner device or after it is removed from a paired account.In this state, the AirTag broadcasts BLE advertisements containing its default MAC address and a portion of its hashed serial number every 33 milliseconds, inviting other Find My compatible devices to pair with it.This is a DRAFT of the final version.DOI and page numbers are subject to change.
Track You! Proceedings on Privacy Enhancing Technologies 2023(4) 2.3.2Connected: When the AirTag is within the BLE range of the owner device, which consistently advertises a BLE beacon every 2 seconds, the AirTag enters the connected state and refrains from advertising its public key.

Nearby:
This short-lived state (lasting a few seconds to 15 minutes) starts immediately after the AirTag loses connection with the owner device.The AirTag transmits an incomplete BLE packet (i.e., part of the public key stored in the MAC address field) every 2 seconds.This incomplete advertisement prevents finder devices from uploading the AirTag's location to the server while the AirTag remains searching for its owner, who is presumed to be nearby.

Disconnected:
Beyond the nearby state, the AirTag transitions into the disconnected state.In this state, the AirTag transmits complete BLE payload every 2 seconds, enabling finder devices to update the location on the central server.
If an AirTag is disconnected from its owner device for more than three days, or the owner device manually sets the tag as lost, it enters lost mode.The lost mode allows supported devices to access a preset "Lost Message" to help reunite the AirTag with its owner.The AirTag transitions back to the connected state when the owner device is back in proximity.

Apple's Anti-Stalking Protections
The use of item trackers can pose privacy and safety risks if individuals are tracked without their knowledge or consent.To address this issue, Apple has implemented several anti-stalking features into AirTag and iPhone software (beyond i0S 14.5) [8]: • Safety Alert: Finder devices with Bluetooth, Find My, and Location Services enabled can listen to BLE beacons in the background.If an AirTag or Find My supported tracker is found moving with the victim's device, a time-sensitive safety alert; "AirTag Found Moving With You" is generated on the victim's device (refer to Figure 1).To reduce the likelihood of false positives, safety alerts are typically triggered when the victim arrives at a Significant Location [27].With the release of iOS 14.5, Significant Locations are enabled by default, allowing devices to track and store these frequent locations.
Unlike iOS devices, Android devices do not have built-in antistalking protections for AirTags.Therefore, Apple has released a proprietary Android app, Tracker Detect [7], that allows users to manually search for unknown AirTags in their surroundings.However, its limited functionality and usability are evident from a low rating of 2.3 stars on the Google Play store.

Related Work
2.5.1 Apple AirTags.Given the limited availability of technical specifications provided by Apple, researchers have endeavored to explore the intricacies of AirTags and associated BLE continuity services [12,34].This has involved analyzing AirTag's circuitry [1], extracting firmware through voltage glitching [42], and reverseengineering Apple's Find My (Offline Finding) protocol [24].The latter resulted in the development of an open-source framework named OpenHaystack, which enables researchers to construct fake AirTags.The stalker generates an elliptic curve P-224 public-private key pair and advertises the public key on a Micro:bit or ESP32 controller.This fake AirTag, emitting similar BLE advertisements like a genuine AirTag, appears legitimate to finder devices, which unknowingly forward the location reports to the Apple server.Open-Haystack framework then queries the server for location reports against the public key and uses the respective private key to decrypt the payload.Since this self-generated key pair is not registered with the Apple ID, the stalker cannot view the location of the fake AirTag on the Find My app and instead utilizes OpenHaystack graphical user interface (GUI) [23] or smart app [11] for location updates.In contrast, our cloned AirTags (Section 4) advertise the public key of a genuine AirTag, allowing us to track victims directly on the Find My app, without relying on any third-party framework.
Previous research has shown that it is possible to circumvent stalking protections by rapidly changing public keys [19] or by altering the status byte to 0x00, which tricks the victim's device into believing that the transmissions are from an iPhone 3 and does not trigger an alert [38].We identified additional yet previously undisclosed values of status byte that can also bypass safety alerts.
In practice, Apple's Tracker Detect app can not perform automatic background scans, which limits its ability to provide proactive safety alerts for Android users, especially for fake AirTags.Researchers have used a combination of dynamic and static analysis techniques to reverse-engineer Apple's anti-stalking protections in iOS and discovered that AirTags are considered suspicious after following a user for a minimum of 840 meters and at least 10 minutes [22].However, to prevent false positives, the alerts are delayed until a specific time.Building upon their findings, the team developed an open-sourced anti-tracking Android app named "AirGuard" which enables Android users to manually scan their surroundings for unknown AirTags and Tile trackers [44].
Furthermore, researchers have proposed a privacy-preserving protocol called Blind My to address the limitations of the Find My protocol [37].Blind My introduces partial blind signatures to add additional cryptographic verification to the Find My protocol and restricts AirTags to using only a bounded set of keys, thus preventing third-party (fake) AirTags from using Find My services.

BLE Item Trackers.
Commercially available BLE item trackers, listed in Table 1, can be broadly categorized into two groups: 1) those that are natively compatible with major smartphone manufacturers like Apple AirTag, Samsung Galaxy SmartTag [43], and Chipolo Plus [14], and 2) third-party trackers like Tile Mate and Tile Pro [46], Protag Duet [30], and Nut Find3 [40].Several researchers have conducted privacy analysis of popular item trackers [48], particularly Tile trackers and Samsung Galaxy SmartTags [49] to uncover any potential weaknesses that could enable stalking.However, these studies do not address proactive safety alerts since these trackers do not include such a feature.The current state of anti-stalking protections for item trackers is concerning, as there is no standardized approach, and each vendor has implemented their own safeguards.For instance, Tile trackers were launched in 2013 without any anti-stalking safeguards, and it was not until 2021, following AirTag's backlash on stalking incidents, that Tile introduced its "Scan and Secure" feature [32].This feature allows users to manually scan and detect unfamiliar Tile trackers in the surrounding area.However, to confirm the presence of an unfamiliar tracker, the tracker-associated app recommends the user isolate themselves and move for at least 10 minutes.This approach often leads to high false positives, causing unnecessary panic, particularly in crowded areas.In an effort to combat theft, Tile recently added an anti-theft mode to its trackers, rendering them undetectable by the "Scan and Secure" feature.This prevents thieves from knowing that a Tile tracker is nearby [45].However, it defeats Tile's anti-stalking protection by making it easier for stalkers to stay anonymous.In order to address both stalking and theft concerns, Tile enables anti-theft mode only after the user provides a valid government-issued ID and agrees to stringent usage terms, such as a $1 million penalty for misusing the tracker that could result in a court conviction.In contrast, for Samsung SmartTags, the safety alerts are only initiated on Android devices if they detect an unknown SmartTag in proximity for more than 24 hours.This solution may not be practical if the stalker is someone close to the victim, such as a roommate or partner.In summary, it is imperative to standardize anti-stalking features in all BLE-based item trackers, prioritizing user safety and privacy.
Recently, Apple and Google have issued a draft of an industry specification titled "Detecting Unwanted Location Trackers" [28], which outlines guidelines for manufacturers of BLE item trackers to ensure compatibility with unwanted tracking detection technologies across different smartphones.The aim is to enable users to detect, alert, and disable any unknown BLE item tracker, regardless of its manufacturer or smartphone platform.However, the specification merely extends AirTag-inspired anti-tracking technology to other trackers, such as utilizing sound or BLE/NFC to locate the trackers and retrieve the serial number.It cannot detect and block OpenHaystack-based fake AirTags or our stealthy cloned AirTags, ultimately falling short in its goal to fully prevent stalking.

EXPERIMENTAL ANALYSIS OF AIRTAG SAFETY ALERTS
With Apple's anti-stalking protections in place, any victim's device that detects an unfamiliar AirTag for a prolonged period generates a time-sensitive safety alert.However, there are inconsistencies in the available literature regarding the exact circumstances in which these alerts are generated on the victim's device.One study discovered that the alert is triggered when an AirTag moves with the victim's device over a distance of one mile [38].Another study reverse-engineered Apple's anti-stalking protections in iOS and uncovered that the victim's device marks the AirTag as suspicious if it detects an unknown AirTag for more than 840 meters (0.52 miles) and 10 minutes.However, safety alerts are delayed (staged) to a certain time, and researchers were unable to identify the trigger that generates them later on [22].Therefore, through this work, we perform a comprehensive evaluation of Apple's anti-stalking measures to determine the specific situations in which safety alerts are triggered, providing insights into the functionality of this feature.

Evaluation Scenario and Setup
3.1.1Real-world Scenario.We consider a practical scenario where a "stalker" uses an AirTag to covertly track the "victim" through the Find My app on their iPhone.To conceal their identity, the stalker registers the AirTag with an anonymous Apple ID, thereby mirroring recent stalking incidents involving AirTags [9,13].It is assumed that the stalker has an opportunity to hide the AirTag in the victim's belongings (e.g., bag or car) while the victim has access to a smartphone (iPhone or Android device) to detect any unfamiliar AirTag trailing them.
3.1.2Experimental Setup.Our device set for these experiments consisted of 4 iPhones (iPhone XR, iPhone 13 Pro, and 2 iPhone 13 mini), 1 Android device (LG V40 ThinQ), and 4 AirTags.We set up all iPhones with different Apple IDs.An iPhone 13 Mini acted as the stalker's device and was registered with all four AirTags.The remaining iPhones, designated as victim's devices, were expected to generate safety alerts as a result of the prolonged presence of unknown AirTags in their vicinity.From the stalker's perspective, these devices acted as finder devices that would upload the whereabouts of the disconnected AirTags to the Apple server, enabling them to stalk the victim covertly.The Android phone was equipped with Apple's proprietary Tracker Detect [7] app and third-party AirGuard app [44] to help detect unfamiliar AirTags.
In all experiments, the stalker's device remained at a fixed location while we, the victims, moved away with the AirTags and smartphones.To ensure accuracy, AirTags were reset and paired with the stalker's device before each experiment and Bluetooth and 136 This is a DRAFT of the final version.DOI and page numbers are subject to change.cellular data were enabled right at the beginning of the experiment (hereby referred to as start time).Consistent conditions were maintained throughout the experiments, including fully charging the devices and AirTags, ensuring devices are functioning normally, and refraining from visiting "significant locations", unless necessary for the experiment.We made deliberate efforts to avoid repeated visits to the same (random) locations to prevent Apple from categorizing them as significant locations.We recorded the time it took for safety alerts to be generated under various conditions and analyzed the difference in alert times in terms of the sample's standard deviation (s).Our results are based on the latest AirTag firmware 2.0.36 (released in Dec 2022) and have been verified for iOS 16.1.2.

Ethical Considerations.
It is crucial to emphasize that our study was conducted in an ethical and controlled manner, ensuring no individual was unwillingly or unknowingly subjected to stalking.Our team members assumed the roles of the victim and stalker, eliminating the need for Institutional Review Board (IRB) approval.

Evaluation Metrics.
In our experiments, we aimed to investigate the impact of the following parameters on safety alerts: • iPhone models and capabilities (iPhone XR, iPhone 13 Pro, iPhone 13 Mini, and whether UWB chip is present),

Experimental Approach and Results
Below, we systematically analyze the impact of individual metrics on the generation of safety alerts in order to gain a comprehensive understanding of the specific metrics that activate these alerts.

Victim's Device Models.
Approach: We conducted a three-day experiment to investigate if safety alerts are impacted by different iPhone models (iPhone XR, 13 Pro, and 13 mini) and capabilities (with the latter two equipped with UWB chips and supporting Precision Finding).Starting at 9 am each day, we drove through the city, making intermittent stops, to observe when the safety alert would trigger on the victim's devices and recorded the alert times in Table 7 in Appendix B for reference.
Results: It is crucial to emphasize that throughout the experiments, safety alerts for all four AirTags were triggered simultaneously on each victim's device.Therefore, the recorded alert times in the tables below reflect the alert times for all four AirTags.For this experiment, despite variations in iPhone models and features, all three iPhones generated alerts almost simultaneously every day, with a maximum standard deviation of 1.5 minutes.This indicates that the alert system for detecting unknown AirTags is intended to function uniformly across all models under consideration, provided all devices were exposed to the same AirTags for the same duration.

Local Time.
Approach: In order to investigate whether the local time affects the safety alerts, we carried out a series of experiments over several days, shifting the start time by two-hour intervals each day.The time taken to generate the safety alert was recorded in Table 8 in Appendix B and visually represented in Figure 4.

Results:
The findings indicate that it took approximately eight hours for the safety alerts to be triggered during the daytime.The alert time gradually decreased after 3 pm until 11 pm, after which the alerts were triggered within an average of 30 minutes.The faster results obtained during nighttime may be attributed to the heightened risk of stalking being more detrimental during these hours and the lower possibility of false positives due to the lower population density.Another contributing factor might be the periodic update of the MAC address and public key of the disconnected AirTag around 4 am local time [1].This update results in the victim's device being unable to recognize the AirTag as the same device that it previously detected, potentially leading to prompt safety alerts.Furthermore, we observed that even if the AirTag and the victim's device are placed close for a substantial period prior to driving, the 8-hour timer would start only when the victim starts moving.
We conducted additional experiments starting at 9:30 pm to investigate further whether the safety alerts were expedited after 11 pm.Our findings, presented in Table 9 in Appendix B and visually illustrated in Figure 5, validate that victim's devices do indeed generate safety alerts more quickly beyond this time.

Victim's Mode of Transportation.
Approach: The previous experiments were conducted while driving across the city.To improve our understanding of whether the mode of transportation impacts safety alerts, we walked through the city with the victim's devices and AirTags.Knowing that safety alerts are promptly generated during night hours, we conducted subsequent experiments mostly during the night hours.This enabled us to repeat the experiments multiple times, ensuring the validity of the results while effectively managing our time.
Results: Our results, as presented in Table 2, are consistent with the findings from the driving experiment (Table 8) as the victim's device generated the safety alert after 8 hours of walking during daylight hours and after 30 minutes past 11 pm.This suggests that the victim's mode of transportation does not impact safety alerts, as long as the minimum exposure distance and time thresholds are met.Furthermore, we observed that in cases where the victim's device generates the safety alert after midnight, they are reminded about the alert within a time frame of 30 to 40 minutes, regardless of whether the victim's device is stationary or located at home.This continues until either the victim opens the safety alert notification or the public key of the AirTag is changed with its daily rollover.

Visiting Significant Location.
Approach: Find My app on iPhone automatically enables the Significant Locations feature when location services are activated.In our subsequent driving experiments, we aimed to assess the affect of visiting significant locations on safety alerts.To achieve this, we disabled the Significant Locations feature on one of the three victim's devices and cleared the existing history of locations.We then drove for over thirty minutes before returning home and recorded our observations in Table 10 in Appendix B for reference.

Results:
The two devices with the activated feature generated the safety alert within 10 minutes of arriving home, irrespective of the time of day.This prompt alert serves as an effective means of alerting the victim of potential stalking risks.It also helps minimize false positives by confirming the presence of an unknown AirTag following the user, rather than a random disconnected AirTag belonging to someone else in a public location.However, when the Significant Locations feature was disabled on the victim's device, the device stopped tracking safe locations and did not trigger any safety alert, even when the victim reached home.

AirTag's Mode.
Approach: Typically, users have the option to mark their misplaced or stolen AirTag as lost in the Find My app.To assess whether enabling the lost mode feature generates a safety alert, we marked two out of four AirTags as lost from the stalker's device and performed experiments for three consecutive days starting at 11 pm.
Results: In all trials, irrespective of whether the lost mode is enabled on AirTags or not, safety alerts for all 4 AirTags were consistently generated simultaneously on all victim's devices.This highlights Apple's commitment to maintaining this crucial feature, effectively preventing potential stalkers from exploiting the threat of theft to conceal their stalking activities and ensuring that the victim's device generates alerts even for the supposedly lost AirTag.

AirTag Battery.
Approach: We conducted further testing to see if different battery levels of the AirTags affect safety alerts.To accomplish this, we used CR2032 battery cells with varying charge levels (fully charged, medium, low, and critically low) in the AirTags and repeated the experiments for three consecutive days starting at 11 pm.
Results: Regardless of the battery level, all victim's devices generated safety alerts simultaneously for all four unknown AirTags in all three trials.This can be attributed to the fact that the frequency of BLE advertisements emitted by the AirTag remains consistent, even when the battery charge is low.Specifically, when the battery is critically low, the Find My app displays a low battery icon and generates a low battery notification on the victim's device.

Distance between AirTag and the Victim's Device.
Approach: Next, we attempted to ascertain the range at which a trailing AirTag would trigger a safety alert on the victim's device.Our objective was to evaluate the trade-off employed by Apple in specific scenarios, e.g., detecting concealed AirTags in the victim's vehicle while preventing false alerts for non-victims traveling on the same bus or train.These experiments were again conducted starting 11 pm owing to prompt safety alerts at this time.We placed 138 This is a DRAFT of the final version.DOI and page numbers are subject to change.
AirTags at a fixed point (x) and positioned team members, each holding a victim's device, at varying distances (1, 2, 3, and 4 meters) from the AirTags.We then repeated the experiment twice with a different set of distances as shown in Table 11 in Appendix B and recorded the time when the safety alert was generated.
Results: Our findings indicate that after more than 30 minutes, safety alerts were generated by the victim's devices within a proximity of 4 meters from the unknown AirTag on the bus.However, for passengers who were seated at a greater distance, their devices did not generate safety alerts.This may be one of the reasons why safety alerts are delayed during the day because otherwise, all passenger devices in the bus/ train that are up to 4 meters away from the disconnected AirTag would generate a safety alert, causing unnecessary panic and confusion.

Placement of Stalker's Device.
Approach: In the previous experiments, the stalker's device remained at a fixed location and was not carried along.We conducted additional experiments (post 11 pm) for three consecutive days where the stalker's device, with the Bluetooth turned off and cellular data enabled, was carried alongside the victim's devices.The objective was to determine if the victim's devices would still generate an alert in such a scenario.
Results: Our findings revealed that all victim's devices generated the safety alert after approximately 30 minutes, despite the presence of the stalker's device.Note that this is a false positive scenario that can occur in real-life situations where a benign device owner is traveling in public transport with a disconnected AirTag.

Population Density.
Approach: While evaluating anti-stalking protections in iOS, a previous study indicated that the people density scan is not activated in iOS 15.2 [22].We conducted two sets of experiments to investigate if finder devices density in the vicinity influences the generation of safety alerts in iOS 16.1.2.In the first set, we visited a deserted beach during the day to determine if the safety alerts are triggered quickly due to the low population density.We walked with one victim's device and unknown disconnected AirTags, gradually increasing the number of victim's devices to three.In the second set of experiments, we visited a sparsely populated road alongside a pond at 3 am and recorded our observations in Table 12.
Results: In the beach scenario, the victim's devices did not generate any safety alerts, even after 7 hours of the experiment.This indicates that the people density scan was not activated during the day.However, during the pond experiment conducted at 3 am, safety alerts were once triggered within 22 minutes.Such a prompt alert can be attributed to the increased risk factor during late-night hours, combined with the low population density in the area.

Status of the Victim's Device.
Approach: We aimed to investigate if safety alerts were triggered differently based on whether the victim's device is locked, unlocked, or in low-power mode.Hence, we set up the three victim's devices such that one was locked, another was unlocked, and the third was in the low-power mode with only 15% battery remaining.

Results:
The results of our study as shown in Table 3 indicate that there was no significant impact of the unlocked screen on the generation of safety alerts.In some instances, the device in low-power mode experienced a delay of up to 5 minutes before generating an alert, but this was not always the case.

Detection on Android Phone.
Approach: So far, we have evaluated the effectiveness of proactive safety alerts on iOS.However, as Android devices lack native antistalking capabilities, we relied on Tracker Detect and AirGuard apps to detect unfamiliar AirTags on the Android device.To ensure optimal performance, we granted these apps location access and disabled battery optimization.
Results: These apps function similarly to BLE scanners and displayed all disconnected AirTags discovered through BLE beacons, regardless of whether the AirTag followed the victim for an extended period or was merely present during the scan.Tracker Detect allowed us to locate the AirTags by playing a sound, provided the AirTags were detected for over 10 minutes.In contrast, Air-Guard marked the AirTags suspicious after the second scan, given that AirTags moved along for more than 30 minutes.

Summary of Results.
To conclude, relying solely on manual scans on Android devices is highly insufficient in ensuring the safety of victims.On the other hand, while iOS's proactive alert feature is commendable, it is also not a foolproof solution for identifying stalking.First, these alerts often come too late, after prolonged exposure to the AirTag, rendering it impossible for the victim to take immediate defensive measures.Secondly, triggering an alert when the victim reaches a significant location, means that the victim's location is exposed to the stalker, even before the victim becomes aware of the AirTag's presence, which is concerning.

USING CLONED AIRTAG TO CIRCUMVENT SAFETY ALERTS
This section delves deeper into examining Apple's anti-stalking protections using a cloned AirTag that broadcasts the public key of a genuine AirTag, allowing it to be located on the Find My app.We aim to modify BLE advertisements of our cloned AirTag in order to uncover any weaknesses that may compromise the effectiveness of the anti-stalking safeguards.Prior research found that modifying the status byte to 0x00 [38] or specific values that identify the device as an iPhone or Mac, does not activate safety alerts [22].We confirm that this vulnerability still exists in iOS 16.1.2.By carefully analyzing the structure of BLE advertisements (see Figure 3) and systematically modifying specific bytes in the BLE packet, we found that certain other byte values can enable the cloned AirTag to bypass anti-stalking protections.and ESP32 WROOM controllers [17].The MacBook was logged in with the same Apple ID as the stalker's iPhone 13 Mini.

Experimental Scenario and Setup
To clone an AirTag, we used UberTooth One to capture the BLE advertisements of a genuine AirTag and extracted the MAC address and data field bytes to recreate the public key (by reverse engineering Figure 3).Then we modified the status byte to one of the specific values that does not generate safety alerts (as detailed in Section 4.2).Using BLE GAP API [18], we advertised this public key on an ESP32 controller every 2 seconds.It is worth noting that ESP32 does not have a microphone, UWB, or NFC chip, which means anti-tracking measures, such as sound alerts and precision finding are unavailable to the victim.To render the cloned AirTag self-sufficient, we affixed a battery pack to the controller.Finally, we removed the battery of the genuine AirTag, allowing real-time tracking of the cloned AirTag on the Find My app.Note that the Find My app allows the owner (stalker) to only view the AirTag's last location.To track the victim's entire route, we relied on the MacOS cache, which continually updates the last location of all AirTags in the items.datafile located at \Users\Library\Caches\com.apple.findmy.fmipcore[2].To recreate the victim's route, our Python script retrieves the location and timestamp for the cloned AirTag from the items.datafile each time it is updated and plots the coordinates onto a digital map for real-time surveillance, as illustrated in Figure 6.

Ethical Considerations.
In addition to conducting our experiments ethically, we acted responsibly by disclosing our findings to Apple and are currently awaiting their response.

Defeating Safety Alerts.
In general, the status byte within the BLE advertisement serves to indicate the device type (such as Apple device, AirTag, AirPod, or compatible Find My device e.g., Chipolo One Spot) and its battery level [22].For instance, the AirTag transmits status bytes 0x10, 0x50, 0x90, and 0xD0 when the battery is full, medium, low, and very low, respectively.Our results in Section 3.2.6 indicate the victim's device generates safety alerts irrespective of the AirTag's battery level.We observed during experimentation that it is actually the Most Significant Nibble (MSN) of the status byte, i.e., the first four bits, that determines whether the alert should be generated.Hence, we conducted a series of experiments to determine which status byte values in the BLE advertisements can help bypass anti-stalking measures.Approach: We captured public keys for two AirTags, removed their battery, and prepared cloned AirTags on ESP32 controllers.These AirTags transmitted BLE beacons with specific status byte values in each round.We left the stalker's iPhone and MacBook at one location and moved away, as the victim, carrying the remaining smartphones, two genuine, and two cloned AirTags.The genuine AirTags were used as a baseline to determine when the actual alert would appear, while two cloned AirTags to make sure that the victim's device does not generate the alert for any of them.We stayed away from any Significant Location for more than 15 hours (9 am to 12 am).Throughout this time, we checked if safety alerts were triggered on 1) the Find My app on Finder iPhones or 2) Tracker Detect or AirGuard app on the Android phone.
Results for iPhone's Proactive Alerts: As indicated in Table 4, the victim's devices only generate a proactive safety alert for the cloned AirTag if the status MSN value corresponds to the device type; AirTags and AirPods.In the latter case, the cloned AirTag mimics an AirPod case, and the victim's device triggers the AirPod Found Moving With You alert (as seen in Figure 10, Appendix A).Knowing that device type "Apple Device" does not trigger an alert, our research goes further by demonstrating that transmitting BLE advertisements for "Find My device" with status MSN values set to This is a DRAFT of the final version.DOI and page numbers are subject to change.Results for Manual scanning on Android Device: The manual scan using Apple's Tracker Detect app could only detect genuine AirTags (i.e., when status MSN values were 1, 5, 9, or D), rendering it incapable of detecting cloned AirTags with other status MSN values.In contrast, AirGuard displayed the MAC address and device type of all BLE-based Apple devices that it detected, using the company ID field (e.g., 0x00FC for Apple) present in the BLE beacons.Consequently, the stealthy cloned AirTag promptly appeared in the device list as a distinct device type matching the status MSN value, even if it was switched on just a few seconds ago and had not moved with the victim.The AirGuard app triggered the safety alert for the specific device type after half an hour of exposure.

Life of a Cloned AirTag.
Approach: Our experiments validate the prior discovery that disconnected AirTags effectively prevent unwanted tracking by frequently updating their MAC address and public key, typically around 4 am local time [1].However, to test whether Apple would identify that our cloned AirTags had not altered its key, we conducted a 16-weeks trial in which our cloned AirTags consistently advertised the same MAC address and public key.We regularly monitored the stalker's Find My app to verify that the location for the cloned AirTags was successfully updated.
Results: As indicated in Table 5, the stalker's iPhone successfully received updated location for the cloned AirTags during the initial two weeks.However, for two days in the third week, the iPhone's Find My app only updated the location when the device's BLE was turned on and not otherwise.We believed that this occurred because finder iPhones unknowingly update location reports on the server, regardless of the public key's age, but the stalker's device stopped fetching location reports if the AirTag's key had not changed in over two weeks.To investigate this further, we set up a fresh clone of the genuine AirTag using the same approach, which worked without any issues beyond 2 weeks.This indicates that Apple does not impose a limit on the lifespan of public keys.However, the exact technical issue that caused the temporary interruption remains undetermined.Interestingly, after two days, the stalker's iPhone's Find My app resumed location updates for the cloned AirTag 1 and has continued to do so, without detection, despite using a 16-weekold public key.In contrast, the Find My app on the MacBook did not limit the lifespan of the public key at any time, allowing indefinite tracking without triggering any safety alert.To mitigate the risk of unauthorized and prolonged tracking, we strongly recommend that Apple limits the lifespan of the public key to a maximum of two days.Otherwise, these stealthy AirTags will go undetected by the victim unless they independently discover and remove them.

Susceptibility to Location Spoofing.
Approach: Previously, we removed the battery of the genuine AirTag to enable our cloned AirTags to function.Next, we sought to explore the scenario where both genuine and cloned AirTags transmit same public key simultaneously from different locations.
Results: We conducted this experiment thrice and each time the owner's Find My app alternated between displaying the location of the genuine AirTag and the cloned AirTag.This happens because finder iPhones cannot differentiate between them, and continue to send location reports to the server.The owner's Find My app retrieves the location report from the server and displays the most recent location.It is important to highlight that an adversary can easily capture Bluetooth traffic using a wireless sniffer.They could capture multiple AirTag beacons in a crowded area and then advertise all public keys on ESP32 controllers located elsewhere.This can deceive all AirTag users into falsely believing that their AirTag or the attached item is in a different location for a certain period.

MITIGATING THE RISK OF COUNTERFEIT AIRTAGS
In this paper, we categorize counterfeit AirTags into two types: (1) Cloned AirTags, which advertise the public key of a genuine AirTag and can be located on the Find My app (Section 4), and (2) Fake AirTags that utilize the OpenHaystack framework and broadcast a self-generated public key (Section 2.5).It is crucial to note that iPhones currently lack the capability to distinguish between genuine, fake, and cloned AirTags, thereby enabling the stalker to exploit Find My services.While blocking cloned AirTags provides some level of protection, the absence of serial numbers in fake AirTags poses a significant challenge for Apple to track the stalker, leaving individuals vulnerable to potential stalking incidents.Hence, it is imperative to block both cloned and fake AirTags to ensure comprehensive protection against unwanted tracking.This section presents key insights into how counterfeit AirTags exploit vulnerabilities to access Find My services and bypass anti-stalking protections.Consequently, we propose server and device-side approaches to effectively detect and block them.

Key Insights into the Find My Architecture
5.1.1Lack of Key Authentication and Verification.From a security standpoint, it is crucial for Apple to authenticate both the finder and owner devices to ensure that only genuine Apple devices can upload or fetch location reports to and from the Apple server.However, the current framework lacks mechanisms to verify two essential aspects: 1) the uploaded location reports actually belong to a registered AirTag, and 2) the device requesting the location reports is the legitimate owner of the AirTag.This loophole allows fake AirTags to broadcast self-generated public keys and utilize Apple servers to store and retrieve location information.To gain a deeper understanding, we modified the OpenHaystack code and analyzed real location reports retrieved from Apple's backend.Besides location data, these reports also include additional details such as upload timing and assumed accuracy.It is worth noting that our modified code allowed us to request and receive encrypted reports for any public key, including those associated with genuine AirTags registered to other users (see Figure 11 in Appendix C).Does that imply that Apple can not verify if a certain public key belongs to a registered AirTag and is associated with an Apple account?However, several facts and evidence bolster the notion that Apple maintains an internal log that connects AirTag's serial numbers, public keys, and Apple IDs.For instance, an AirTag (with a unique serial number) can only be registered to a single Apple ID, and all devices registered under that Apple ID have access to the keying information required to locate the AirTag.Additionally, even if the AirTag is reset manually (by removing the battery five times), the owner device must delete the AirTag before it can be paired again.This deletion process requires an active internet connection to communicate with the Apple servers.Moreover, Apple itself states that, with a valid subpoena, they can determine the Apple ID associated with the serial number of the AirTag being used for unwanted tracking [25].Finally, although fake AirTags can request location reports from the server, they can not display their location on the Find My app.These indications suggest that Apple can authenticate and associate public keys with their corresponding Apple IDs.A straightforward solution to prevent fake AirTags from uploading location reports for unregistered keys is to maintain a mapping between the Apple ID and the hash of associated public keys and verify the association.Unlike storing actual public keys, storing their hash does not enable Apple or third parties to track the victim's location.Similarly, the server endpoint responsible for handling fetch requests should also cross-reference this key hash-Apple ID database to authenticate whether the keys used to request location reports are genuinely associated with the initiating device.It's important to note that the key authentication mechanism can effectively block fake AirTags but not cloned ones, underscoring the necessity to explore alternative approaches.

Inconsistencies in AirTag's Detection and Alert Mechanism.
As shown in Section 4, finder devices upload location reports to the central server, regardless of the status byte value in the BLE advertisements.This enables the stalker to track the location of their counterfeit AirTag on the Find My or OpenHaystack app, depending on the type of public key used.In contrast, the victim's device only triggers a safety alert if the status byte in the BLE advertisement is identified as belonging to either an AirTag or AirPod.It is not generated for other Apple devices, e.g., iPhones or iPads, which are deemed unsuitable for tracking victims owing to their size and low battery life.This inconsistency in the AirTag's detection and alert generation mechanisms allows the stalker to effectively circumvent the anti-stalking protections without being noticed.

Lack of Device Type
Validation.Currently, the owner device fetches location reports from the server against a set of public keys and updates the latest location on the Find My app, without verifying the device type.This enables the stalker to advertise BLE packets with the status MSN values that do not trigger safety alerts on the victim's device, but still receive updated location on the Find My app.Our analysis of items.datafile in the MAC cache reveals that  A,E for stealth 0 for stealth the file does store device type along with location coordinates.To prevent the stalker from getting real-time updates of their stealthy counterfeit AirTags, it is important that AirTag's location must only be updated if the device type corresponds to AirTag.

Device-side Mitigations
Our analysis of BLE advertisements from genuine and counterfeit AirTags identified key differences, summarized in Table 6, that finder devices can leverage to filter out fake BLE advertisements.

Distinct
Packet Data Unit (PDU) Type.To conserve battery, Open Haystack-based fake AirTags advertise their public key using Non-connecting Advertising Indicator (ADV_NONCONN_IND), while genuine AirTags (as well as cloned AirTags) broadcast their public key as an Advertising Indicator (ADV_IND) seeking a connection with central devices.While the difference is clear, it is also trivial for an adversary to modify the PDU type of the fake AirTag to transmit ADV_IND packets, making further detection necessary.

Different Channel Selection Algorithms (CSA)
. CSA aims to identify the most effective channel for transmitting wireless data.When both the BLE master and slave devices are equipped with Bluetooth version 5.0 or higher, CSA 2 is the default channel selected.As a result, when the iPhone (master) and AirTag (slave) communicate, they use CSA 2 as depicted in Figure 7. On the other hand, current counterfeit AirTags developed using ESP32 or other supported hardware only support Bluetooth v4.2 [17], causing them to use CSA 1 for communication.It is worth noting that although the slave device can request the master to change the CSA, it cannot do so independently.Hence, finder devices should reject CSA change requests or disregard AirTag beacons using CSA1.It is important to anticipate stalkers might use hardware for developing counterfeit AirTags that inherently support CSA2 and thus this measure alone is not sufficient to filter fake BLE beacons.

Irregularity in Lifespan of MAC Addresses and Public Keys.
AirTags are designed to protect against unauthorized tracking by regularly changing their MAC address and public key.However, counterfeit AirTags use a static key to track the user.In order to prevent unwanted tracking, Apple must restrict the lifespan of the public key to no more than one or two days.Accordingly, the finder iPhone should cease sending location reports if it detects an AirTag with the same MAC address and public key for more than two days, and alert the user.Similarly, the owner's Find My app should stop updating the location of such AirTag to prevent unwanted tracking and force the stalker to reset the AirTag.
To ensure security, it is also crucial to block Find You-like setups that continuously alter public keys every 2 seconds to avoid being flagged as a suspicious AirTag and evade anti-stalking measures [19].As this irregular behavior is challenging to detect, we suggest that iPhones wait for multiple advertisements (e.g., for 10 seconds) before uploading the first location report for any AirTag.

Generate Safety
Alert irrespective of the Status Byte.Addressing the limitation highlighted in Section 5.1.2,the victim's devices should generate a safety alert whenever any device remains in close proximity for an extended period, regardless of the value of the status byte.This will prevent stalkers from bypassing safety alerts.

Validating Device Type before Updating Location on the Find
My App.To address the limitation identified in Section 5.1.3,the Find My app should only update the location of the AirTag if the device type also corresponds to AirTag.

5.2.6
Blocking Unauthorized Plugins.OpenHaystack utilizes a custom Apple Mail plugin, inheriting entitlements to authenticate as a genuine Apple user and fetch location reports for its self-generated public keys from the server [21].Apple can implement strict plugin validation to prevent fake AirTags from accessing Find My services.

Server-side Mitigations
While some device-side mitigations can be bypassed by the stalker, we suggest following server-side measures that can effectively prevent stealthy counterfeit AirTags from misusing Find My services.

Authenticating Public Keys.
Apple servers currently allow uploading and fetching location reports under any public key (whether registered or unregistered).Thus, before storing any location report, the server must validate the mapping between the hash of the report's public key and Apple ID to confirm that the public key is not self-generated and is linked to a registered AirTag.Similarly, when the owner device requests a location report, the server must revalidate the public key's hash and Apple ID mapping to ensure that only the legitimate owner device requests its AirTag's location, and that the request is not originated from the OpenHaystack framework.Although this measure may introduce slight processing time, it plays a crucial role in effectively blocking fake AirTags and significantly enhancing the security of the system.

Blocking
Persistent Public Keys.In general, both fake and cloned AirTags advertise the public key of the AirTag in the disconnected state, i.e., the location type for the reports is labeled as "crowdsourced" 4 .Thus, Apple's servers should flag an AirTag as suspicious if its location reports are consistently stored with the same public key hash for more than two days.The servers already have the ability to store location reports for up to seven days, meaning there is an existing infrastructure to filter and identify reports from counterfeit AirTags.We have briefly summarized the server-side mitigations in Figure 8.

RECOMMENDATIONS TO IMPROVE ANTI-STALKING MEASURES
The risk of stalking is not limited to AirTags alone, as other BLE item trackers such as SmartTags and Tile can also be misused for unwanted tracking.Unfortunately, the lack of adequate anti-stalking protections in these trackers makes it challenging for victims to identify and counter stalking attempts.This places an onus on tracking device manufacturers to prevent, detect, and proactively inform victims of any stalking activities.However, designing a robust anti-stalking framework that rapidly and accurately identifies an unfamiliar tracker, while also minimizing false alerts to prevent victims from disregarding genuine stalking alerts, poses a significant challenge.Building on our comprehensive analysis of Apple AirTags, we present insightful recommendations to improve anti-stalking safeguards and shed light on the challenges associated with their implementation.This information will be valuable to manufacturers of other BLE item trackers seeking to enhance their anti-stalking protections.We recommend manufacturers prioritize the implementation of the following crucial anti-stalking measures: Early Proactive Safety Alerts.As victims have limited control over stalking, it is crucial to notify users of any unfamiliar trackers trailing them.Currently, proactive alerts are only generated for unknown AirTags on iOS, while users have to manually scan for unknown AirTags and SmartTags on Android OS and for unknown Tile trackers on both iOS on Android.Manual scans are ineffective as users are unlikely to actively search for potential threats unless they have suspicions.Moreover, implementing continuous manual scanning at the application level in the background can negatively impact battery life and other Bluetooth-capable features.To tackle this challenge, tracker manufacturers must closely collaborate with smartphone manufacturers to enable background scanning within the OS and facilitate the activation of proactive safety alerts.
Although Apple AirTags offer proactive safety alerts, the prolonged delay of over 8 hours in triggering them is a significant concern, as it undermines the victim's ability to respond promptly to potential threats.This makes it crucial to reduce the alert times substantially.Furthermore, safety alerts should be triggered regardless of the victim's mode of transportation, time of the day, and the battery or operational mode of the victim's device or tracker.The alert should also be generated irrespective of the victim's location to prevent the disclosure of their significant locations to the stalker before they can identify and disable the tracker.These measures can inadvertently increase false positives, where genuine disconnected trackers are mistakenly flagged as suspicious, especially in public transportation or crowded areas.Therefore, a trade-off between prompt alerts and minimizing false positives must be carefully balanced to ensure the effectiveness of the anti-stalking mechanism.
Interoperability.If all manufacturers implement proactive alerts, it becomes possible to achieve interoperability among tracker apps, enabling them to also detect trackers from other manufacturers.This eliminates the need for users to download multiple apps to ensure their security.Recognizing the need for a unified solution, Apple and Google have recently joined forces [28], showcasing their commitment to enhancing users' safety and privacy.
Optional Aggressive Scanning Mode.Manufacturers can consider implementing an optional aggressive scanning mode within the tracker-associated app, allowing potential victims of stalking, such as divorced spouses, celebrities, activists, and journalists in hostile territory, to opt-in for enhanced security.This mode will trigger quick alerts if an unfamiliar tracker remains in close proximity for a period exceeding a predefined threshold, such as 1 hour.Considering the potential for false positives, it is essential to develop methods to accurately distinguish between suspicious trackers and harmless coincidental scenarios to maintain user confidence.
Audible Alerts.Tracker must emit a chirp if it remains separated from the owner device for an extended period, such as 2 days.This serves to alert the victim if the safety alert has gone unnoticed.
Preventing Unauthorized Tracking by External Parties.All location reports must be end-to-end encrypted to prevent unauthorized tracking by the manufacturer or third parties.Additionally, to prevent unwanted tracking using BLE beacons, manufacturers must regularly rotate the tracker's MAC address and public key and ensure identifiers are not reused or used beyond 2 days.
Tracker Sharing.It is important that static users, such as those attending the same class or party, do not receive safety alerts for an unknown disconnected tracker if an attendee (owner) has their device's Bluetooth turned off.Although the anti-stalking algorithm already identifies a stalking attempt based on sustained movement with the tracker, our experiments reveal that alerts are generated even when the owner device has Bluetooth turned off while traveling together.To address this, manufacturers could consider implementing Tracker Sharing feature, inspired by Tile trackers.This optional functionality would facilitate collaborative tracking, allowing users to invite trusted individuals, such as their partners or family members, to connect to their item tracker.Consequently, users will not receive unnecessary safety alerts while traveling together or borrowing items with an attached tracker.
Post-detection Measures.Once the unknown tracker is discovered, the user should be able to retrieve its serial number using NFC or BLE technology, enabling them to inquire the manufacturer about the stalker's identity.Like AirTags, users must be able to view the owner's mobile number partially to allow them to verify if the tracker belongs to their partners or friends.Moreover, it should be fairly easy for the user to remove the battery and deactivate the tracker to prevent further location updates.Finally, users must have the provision to report stalking attempts to the manufacturers.
Legal Concerns.With a valid subpoena, the manufacturer must disclose stalker's information to the victim, and cooperate with law enforcement authorities to pursue legal action against the stalker.User Awareness.Merely displaying a warning during the tracker's registration process, cautioning against misuse, is inadequate in preventing stalking.Manufacturers must educate users about potential stalking risks and the implications of misusing trackers via social media and awareness campaigns.

CONCLUSION
Despite their usefulness in helping locate misplaced or lost personal items, BLE item trackers, particularly Apple AirTags, present a significant security threat as they can be used to stalk unsuspecting individuals.This study evaluated the performance of Apple's anti-stalking measures with a focus on identifying previously unexplored circumstances that activate safety alerts, including local time, the victim's device model and screen status, the mode and battery life of the AirTag, the distance between the AirTag and the victim's device, and whether the victim visited any "Significant locations" while being stalked.The study also highlighted the ease with which cloned AirTags can be weaponized, as evidenced by our discovery that changing the status byte to specific values can bypass the anti-stalking measures offered by Apple, making it feasible for the stalker to track the victim even with a four-months-old public key.We proposed several countermeasures to address this issue and provided additional recommendations to harden the antistalking protections against unknown AirTags, including adding an optional aggressive scanning mode, authenticating public keys before storing the location reports, and enforcing a limit on the life span of the public keys.These recommendations also serve as a basis for enhancing anti-stalking measures for other BLE item trackers.Our findings were verified through a series of experiments, reinforcing the need for improved security measures in BLE item trackers.Overall, it is crucial to address the security concerns associated with these devices to ensure that they are used responsibly and do not threaten individuals' privacy and safety.

A SAFETY ALERTS
Figure 9 shows the safety alerts generated by the victim's device when three standard AirTags and one cloned AirTag (mimicking an AirPod with the MSN value of the Status byte in the BLE advertisement set to 3) consistently followed the victim.It is worth noting that during the experiments, all genuine AirTags consistently triggered safety alerts simultaneously on all devices, except for this specific case where there was a 2-minutes delay.This anomaly can be attributed to the presence of malformed packets and incorrect CRC packets in some of the BLE advertisements emitted by the ESP32 hardware utilized to prepare the cloned AirTag.In addition, Figure 10 shows the route displayed to the victim when he opens up the safety alert for the AirPod.As ESP32 does not have a microphone, the victim can not play sound to locate the cloned AirTag, and thus we see that the play command is queued.

B EXPERIMENT RESULTS
This section presents the supporting results for some of the experiments conducted in Section 3. As such, we investigated the effect of various metrics on the generation of safety alerts, for instance, the victim's device model in Table 7, mode of transportation as driving in Table 8, accelerated alerts post-11 pm in Table 9, significant locations in Table 10, distance between AirTag and victim's device in Table 11 and people density in Table 12.
To quantify the differences in timings in minutes among victims' devices, we utilized the sample's standard deviation (s).Note that the results of Table 8 and Table 9 have been illustrated in Figure 4 and Figure 5.For other experiments, the variance between the alert times was very low (approximately 1 to 2 minutes) for experiments spanning over 8+ hours, thereby meaning that those metrics do not impact the generation of safety alerts.validates the mapping between the hash of the public key sent in the fetch request and the Apple ID requesting it.

D FINDER DEVICE'S REPORTING DYNAMICS
In our research, we aimed to determine the frequency at which a single iPhone reports the location of nearby AirTags to Apple's servers in an hour.To achieve this, we utilized OpenHaystack-based fake AirTags to control the number of advertisements sent by a genuine AirTag as a reference.Typically, an AirTag broadcasts BLE advertisements once every 2 seconds in disconnected mode.The experiment was conducted inside an RF shield (Faraday cage) to ensure that only one finder device uploads the location reports for subject tags.To allow the finder device to hear BLE advertisements and upload the location reports on the server, we set up a router inside the RF shield and enabled the device's Wi-Fi and Bluetooth.The results, shown in Table 13, indicate that a finder device does not upload location reports for every public key it listens to and uploads more reports when the finder device is turned on (i.e., the screen is not locked).

Figure 1 :
Figure 1: Time-sensitive Safety Alert generated by victim's device due to prolonged detection of an unknown AirTag.

Figure 2 :
Figure 2: Overview of how the Offline Finding (OF) protocol enables long-range location tracking for Apple AirTags.
Local time (day or night), • Victim's mode of transportation (driving or walking), • Victim visited any Significant location (e.g., home or workplace) or not during the experiment, • AirTag's mode (normal or marked lost in the Find My app), • Battery level of AirTags (full, medium, low or critically low), • Distance between the AirTag and the victim's device, • Placement of the stalker's device (carried along or not), • Population density (in the city or in a deserted area), • Status of the victim's device (screen locked, unlocked, or in Low Power Mode), • Detection on the Android phone equipped with Tracker Detect and AirGuard App.

Figure 4 :
Figure 4: Investigating the Impact of Local Time on Safety Alerts across different phone models.

Figure 6 :
Figure 6: Tracking the tracker: Route of the cloned AirTag retrieved by the stalker using Python script on Mac.

Figure 7 :
Figure 7: BLE Link Layer packet header of the beacon transmitted by a genuine AirTag depicting the use of CSA 2.

Figure 8 :
Figure 8: Suggested Server-side Approach to Mitigate the Stalking Risks from Counterfeit AirTags.

Figure 9 :
Figure 9: Time-sensitive Safety Alert generated by the victim's device for 3 genuine AirTags and one stealthy cloned tag disguised as AirPod.

Table 8 :
Supporting Data for Figure 4 -Investigating the Impact of Mode of Transportation (Driving) on Safety Alerts.(Here, s = Sample's standard deviation in minutes.)Start Time

Figure 11 :
Figure 11: Encrypted Location Report retrieved for an AirTag that belongs to another user

Table 1 :
Commercially available BLE Item Trackers.

Table 2 :
Investigating the Impact of Mode of Transportation (Walking) on Safety Alerts.The standard deviation of the sample (s) indicates the variation in results in minutes.

Table 3 :
Investigating the Impact of Device Status on Safety Alerts.The standard deviation of the sample (s) indicates the variation in results in minutes.

Table 4 :
Investigating Impact of Changing Status Byte on Detection Efficiency of Find My, Tracker Detect, and AirGuard.

Table 5 :
Investigating Lifespan of Cloned AirTag: How long could the stalker locate the cloned AirTag on Find My app?

Table 7 :
Investigating the Impact of Phone Model on Safety Alerts.(s = Sample's standard deviation in minutes.) Time after alert generated s iPhone XR iPhone 13 Pro iPhone 13 mini 5 am 8 hrs 21 mins 8 hrs 21 mins 8 hrs 22 mins 0.58 7 am 8 hrs 36 mins 8 hrs 36 mins 8 hrs 35 mins 0.58 9 am 8 hrs 16 mins 8 hrs 15 mins 8 hrs 18 mins 1.53 11 am 8 hrs 07 mins 8 hrs 06 mins 8 hrs 05 mins 1 1 pm 8 hrs 27 mins 8 hrs 14 mins 8 hrs 14 mins 7.5 3 pm 8 hrs 06 mins 8 hrs 05 mins 8 hrs 05 mins 0.58 5 pm 6 hrs 11 mins 6 hrs 11 minsFigure 11 shows the encrypted location report retrieved through our modified OpenHaystack code for the public key of a legitimate AirTag.Although the adversary requires a private key to decrypt 146 This is a DRAFT of the final version.DOI and page numbers are subject to change.

Table 9 :
Supporting Data for Figure5-Investigating Accelerated Safety Alerts after 11 pm.The standard deviation of the sample (s) indicates the variation in results in minutes.

Table 10 :
Investigating the Impact of Visiting Significant Locations (SL) on Safety Alerts.

Table 11 :
Investigating Impact of Distance between AirTag and the Victim's Device on the Safety Alerts.

Table 12 :
Investigating the Impact of People Density on Safety Alerts.Apple servers must not allow any user to fetch reports for anyone else.As recommended, this is possible if the server

Table 13 :
Impact of Broadcast Intervals on Upload Timings: An Hour-Long Study of iPhones with the locked and unlocked screen.