Embed Size (px)
Citation preview
Lost and Found: Stopping Bluetooth Finders fromLeaking Private Information
Mira WellerSecure Mobile Networking Lab
TU Darmstadt, [email protected]
Jiska ClassenSecure Mobile Networking Lab
TU Darmstadt, [email protected]
Fabian UllrichSecure Mobile Networking Lab
TU Darmstadt, [email protected]
Denis WaßmannSecure Mobile Networking Lab
TU Darmstadt, [email protected]
Erik TewsEEMCS Department, SCS GroupUniversity of Twente, Netherlands
ABSTRACTA Bluetooth finder is a small battery-powered device that can beattached to important items such as bags, keychains, or bikes. Thefinder maintains a Bluetooth connection with the user’s phone, andthe user is notified immediately on connection loss. We providethe first comprehensive security and privacy analysis of currentcommercial Bluetooth finders. Our analysis reveals several signifi-cant security vulnerabilities in those products concerning mobileapplications and the corresponding backend services in the cloud.We also show that all analyzed cloud-based products leak moreprivate data than required for their respective cloud services.
Overall, there is a big market for Bluetooth finders, but noneof the existing products is privacy-friendly. We close this gap bydesigning and implementing PrivateFind, which ensures locationsof the user are never leaked to third parties. It is designed to run onsimilar hardware as existing finders, allowing vendors to updatetheir systems using PrivateFind.
CCS CONCEPTS• Security and privacy → Systems security; Software secu-
rity engineering; Software reverse engineering; • Networks →Application layer protocols.KEYWORDS
Bluetooth, Privacy, Localization, Internet of ThingsACM Reference Format:Mira Weller, Jiska Classen, Fabian Ullrich, Denis Waßmann, and Erik Tews.2020. Lost and Found: Stopping Bluetooth Finders from Leaking PrivateInformation. In 13th ACM Conference on Security and Privacy in Wireless andMobile Networks (WiSec ’20), July 8–10, 2020, Linz (Virtual Event), Austria.ACM,NewYork, NY, USA, 11 pages. https://doi.org/10.1145/3395351.3399422
WiSec ’20, July 8–10, 2020, Linz (Virtual Event), Austria© 2020 Association for Computing Machinery.This is the author’s version of the work. It is posted here for your personal use. Not forredistribution. The definitive Version of Record was published in 13th ACM Conferenceon Security and Privacy in Wireless and Mobile Networks (WiSec ’20), July 8–10, 2020,Linz (Virtual Event), Austria, https://doi.org/10.1145/3395351.3399422.
1 INTRODUCTIONBluetooth finders are small devices that track an item’s location. Thefinder’s owner installs a smartphone app that maintains a BluetoothLow Energy (BLE) connection with the finder. If the connection isinterrupted, the app assumes that the corresponding item is lost andalerts the owner—for example, when leaving the house without thewallet. The limited BLE range allows triggering alarms accurately.In case a user is attempting to locate a nearby misplaced item, theapp is able to play a sound on a given finder within wireless range.Localization also works in the reverse direction: Upon pressing thefinder’s button the smartphone plays a sound.
In addition to the sound-based localization, the app saves thesmartphone’s Global Positioning System (GPS) location and asso-ciates it with the finder. Position accuracy depends on the GPS fixand the maximum distance between finder and smartphone. Theowner is then able to retrieve the last known location of the finder.Position data is saved locally or on a remote server.
A tracked item can move while it is out of its owner’s Bluetoothrange. For that reason, some finders allow other users to searchfor a lost item. All apps are continuously scanning for currentlydisconnected finders in the background and report these to theserver. Once a lost finder is spotted by another user, the owneris informed. Figure 1 depicts the ecosystem architecture that isrequired to support external position reporting and searching.
Bluetooth finders became popular in 2013 when Tile raised $ 2.6million with a crowdfunding campaign [6]. Since then, variousfinders were introduced to the market. In this work, we analyzetop-ranked finders sold worldwide: Nut Find3, Tile Mate, Tile Pro,musegear finder, Pearl Callstel Key Finder, Gigaset g-tag, and CubeTracker. Additionally, we analyze a couple of lesser known brandsbased on the ST17H26 chip that can be managed over various smart-phone apps including iTracing, iSearching, and FindELFI. Our anal-ysis uncovers severe security and privacy issues. We reported allissues to the vendors, and most have been fixed by now. However,despite being one of the top-selling finders, Nut still has majorsecurity issues. We communicated these more than a year ago overvarious communication channels and contacted two ComputerEmergency Response Teams (CERTs), but Nut servers are still leak-ing user data. This demonstrates how even today adequate productsecurity is still being neglected by some low-cost Internet of Things(IoT) vendors.
arX
iv:2
005.
0820
8v1
[cs
.CR
] 1
7 M
ay 2
020
WiSec ’20, July 8–10, 2020, Linz (Virtual Event), Austria Weller et al.
Owner
Reporter
FinderServer
Finder information
GPS GPS
Lost finder report
Found your finder
Figure 1: Bluetooth finder ecosystem overview. The finder’s owner lost connectivity, but the moving finder is no longer at itslast known position. A reporter within Bluetooth range sends their GPS position to the owner via the server.
Despite the variety of available Bluetooth finders, a solutionmaintaining privacy has yet to be proposed. Therefore, we designand implement the privacy-preserving secure finder protocol Pri-vateFind for an IoT platform similar to those seen on low-budgetfinders. Our contributions are as follows:
• A comprehensive analysis of features, security, and privacyin popular Bluetooth finder ecosystems.
• Uncovering severe security and privacy breaches in the mostpopular finders Tile and Nut.
• Generalized findings of common design flaws in IoT ecosys-tems that compromise security and privacy.
• Design of a new solution PrivateFind supporting all observedfeatures but providing anonymity and privacy.
• Implementation of PrivateFind as an open-source project ona low-cost IoT platform similar to existing finder hardware.
This paper is structured as follows. We list previous securityresearch in Section 2. In Section 3, we analyze popular finder fea-tures, with a focus on their infrastructure and security. We solvethe identified issues while providing all important features with Pri-vateFind in Section 4. Our results are discussed in Section 5. Finally,our work is concluded in Section 6.
2 RELATEDWORKHeiland and Compton discovered and disclosed 12 vulnerabilitiesin TrackR Bravo, iTrack Easy, and Nut [4]. Their analysis focusedon the Bluetooth interface and forging finder identities to accessdata. We assume that they used the same standard procedure toanalyze all Bluetooth finders since the vulnerabilities found arevery similar. Their most outstanding findings are: GPS positionsof TrackR Bravo can be queried by finder identifier (CVE-2016-6540); duplicate registration of the same iTrack Easy finder allowsto access the device’s GPS data (CVE-2016-6543); and Nut transmitsreusable session tokens without using Transport Layer Security(TLS), thereby allowing Machine-in-the-Middle (MITM) attackson specific accounts (CVE-2016-6548). The first and second attackrequire a valid device identifier, meaning that an attacker musteither guess it or launch a targeted attack. The third attack’s severitydepends on the attacker’s network position. However, the securityanalysts did not find any Tile issues despite analyzing it. Yet, we
were able to uncover security issues and data leaks, detailed inSection 3.2.2. To the best of our knowledge, Heiland and Comptonare the only ones who did security research on Bluetooth finders.No more vulnerabilities on the products we analyzed were listed inthe Common Vulnerabilities and Exposures (CVE) database.
Only recently, Apple added the Find My protocol on most of theirdevices [1]. As of now, Find My only runs on powerful devices thathave a regularly charged battery. All these devices are associatedwith a validated iCloud account. This enablesApple to run a complexencryption scheme. In comparison, the finders in this paper arepowered by a button cell for more than a year, and PrivateFind doesnot enforce the privacy-invasive equivalent of an iCloud account.
3 ANALYSIS OF EXISTING FINDERSIn Section 3.1 we compare features of top-selling finders. This isfollowed by a security analysis in Section 3.2. We conclude commonfeatures and issues in Section 3.3.
3.1 Feature ComparisonIn this section, we compare the features of a large selection of find-ers. An overview is shown in Table 1. Despite being sold underdifferent names, finders often share the same slightly customizedfirmware and Application Programming Interface (API). We per-form an initial app analysis to avoid buying finders that are hard-ware or app duplicates by inspecting the app’s code structure andAPI calls. We unpack and analyze the Android apps by searchingfor strings and logic analysis based on jadx [20].
3.1.1 Nut. The Nut finders support group search for lost devicesand silent zones [8]. Group search means that the user can sharethe finder to friends with a QR code which can then help to locatethe finder [7]. Nut is ranked #2 on Amazonwithin the category GPS,Finders & Accessories.
The Android and iOS apps differ a lot. Only the iOS app hasbuttons for a lost finder search, but it never issued a request tothe server in practice. An API call requesting lost finders existsin the dissected Android app but is never called. We assume someparts of the app were never implemented. Nonetheless, both appsreport all found devices and forward them to the Nut servers inthe background. Locations are uploaded frequently—while the app
Lost and Found: PrivateFind WiSec ’20, July 8–10, 2020, Linz (Virtual Event), Austria
Table 1: Finder features compared.
XXXXXXXFeatureApp
NutSmart Tracker
Tile musegear finder,iTrackEasy
Cube Tracker keeper iTracing, iSearching,FindELFI
Device Nut Find3 Tile Mate,Tile Pro
musegear finder,Pearl Callstel Key Finder
Cube Tracker Gigaset g-tag Based on ST17H26
Declare lost ✓ ✓ ✓ ✓ × ×Reports locationto server
yes yes yes yes ? no
Login Email/Phone+PW,Social Login
Email+PW,Social Login
Email+PW Email+PW,Social Login
Email+PW(Gigaset elements account)
×
is connected to the finder or when it senses other disconnectedfinders. Even though locations are sent to the server, the searchfeature is not available for users.
3.1.2 Tile. The leading finder onAmazon, ranked #1 inGPS, Finders& Accessories, is Tile. While Nut and Tile features are similar, Tile ismore expensive and most features require a monthly subscription.Basic Tile features are to let the finder play a sound and to usefinders to locate a smartphone. Users can add multiple smartphonesto their profile and also associate a limited subset of paired non-Tile Bluetooth devices. Tile comes with a crowd search feature andclaims to have the largest finding community [21]. Once a useraccount is associated to a Tile, the account and the tracker arepermanently bound. Losing account access bricks all associatedTiles.
The location is reported every few minutes to the servers. Inaddition to the exact location, each click action in the app sendsmetadata to the server, such as the currently used Wi-Fi name andMAC address, which also allows inferring a location. Similar datais transferred every few minutes if no action is performed.
3.1.3 musegear & iTrackEasy. Several finders with a similar casingdesign appear on the first page of the Amazon category GPS, Finders& Accessories under various product names. One variant of thisis the Pearl Callstel Key Finder. This type of finder uses the sameAPI hosted on different servers. The user’s location is reportedto a server every 30min even in the absence of a finder, whichis more privacy-violating than the Nut implementation that onlyworks with physically present finders. Also, the user’s location istransferred when the user logs in and when a lost finder is reported.When a user marks a finder as lost [10], the server will report itslocation to the owner once it is found.
3.1.4 Cube Tracker. The Cube Tracker is also amongst the mostpopular finders. The Cube Pro has twice the range as the basic CubeTracker. Both finders have a crowd search, a replaceable battery,and a photo trigger function [3]. Also, they can play a sound on thefinder and make the phone ring. Similar to Tile, the Cube Trackerhas an online sign-in that can be used to locate a finder.
3.1.5 keeper. We chose the Gigaset g-tag for its different technolo-gies and app codebase, although it is not a top-selling finder. Theapp requires a unique Gigaset elements account. Users can edit theirprofile with the app, but the account is not required for anything—except that it is enforced to have an account. Locations are storedlocally in a Realm [17] database and seem to be never transmittedto the server. The app’s rating is poor because users expect to seetheir finder’s location within their profile.
3.1.6 iTracing, iSearching, FindELFI. We selected the family ofiTracing, iSearching and FindELFI finders because they are one ofthe cheapest top-sellers on AliExpress. They look identical and alsoshare the same hardware design. They are all based on the ST17H26chip. Due to their simple hardware design, there is no possibility toupdate the finder’s firmware. The apps lack all cloud-based features.
3.2 Security AnalysisWe perform a technology and security analysis for all finders. Pos-sible attack vectors strongly depend on server-related features. Thegeneral analysis follows the same categories. In addition to thesecategories, we perform a device-specific analysis. This analysis in-cludes app and cloud services. An overview of the common analysisresults is shown in Table 2, and the individual security issues arediscussed in the corresponding subsections.
The common analysis steps and categories are as follows. De-pending on the TLS certificate validation scheme, MITM trafficanalysis requires installing a root certificate to the smartphone, ora server certificate needs to be replaced within the app. For MITMtraffic analysis, we use mitmproxy and Burp Suite [9, 15]. The cat-egory API authentication summarizes how the app authenticateswith the server. Typically, such API authentication credentials canbe exfiltrated from the app. Firmware location and encryption refersto firmware updates if the finder supports it. Updates are forwardedby the app to the finder because it only communicates via Bluetooth.The app caches the update in some location, ideally encrypted. Insome cases, we were able to download firmware updates directlyfrom the server or to decrypt the updates once they were down-loaded by the app. Ideally, the Over-the-Air (OTA) update keeps thefirmware encrypted at all times until it is decrypted and verifiedon the finder. If the app is obfuscated, analyzing or changing itsfunctions is more complicated. Non-obfuscated apps come withfunction names. All apps contained debug strings, which madede-obfuscation easier. The package name and class structure of Javaapplications as well as API endpoints, hint to a shared codebasebetween differently branded products.
3.2.1 Nut. The Nut ecosystem implements a rich set of featuresbut comes with the most security issues.
Traffic Interception. The first step for analysis of the app is anMITM attack on TLS to inspect the app’s behavior. Instead of check-ing TLS certificates, the app ignores any CertificateExceptionwithin the class X509TrustManager. Thus, even an obvious MITMattack with invalid certificates is possible without installing newcertificates to a victim’s smartphone. Anyone with access to thesame network can sniff and manipulate Nut app traffic.
WiSec ’20, July 8–10, 2020, Linz (Virtual Event), Austria Weller et al.
Table 2: Common finder analysis results.
XXXXXXXAnalysisApp Nut
Smart TrackerTile musegear finder,
iTrackEasyCube Tracker keeper iTracing, iSearching,
FindELFITLS cert validation ignored yes pinning pinning yes n/aAPI authentication no AWS
credentialsClientcertificate
AWScredentials
Clientcertificate
Basicauthentication
FW location Servervia HTTP
Amazon AWSvia HTTPS
n/a App App n/a
FW encryption App none n/a none Finder n/aApp obfuscation ✓ × × ✓ × ✓Package name com.nut.
blehuntercom.thetileapp
com.antilost.finder,com.antilost.app3
com.blueskyhomesales.cube,com.shenzhen.android.cube
com.gigaset.elements.android.app.gtag2
com.fb.antiloss,com.lenzetech.antilost,com.zoqin.findelfi
API endpoint https://api.find.nutspace.com/,https://qa-find.nutspace.com/
https://production.tile-api.com,https://locations-prod.tile-api.com
https://api.musegear.net:8092/CommApiEx,https://api.ieasytec.com:8092/CommApiEx
AWS https://api.gigaset-elements.de/api/v1/,https://im.gigaset-elements.de/identity/api/v1/
-
Individual issues Leakage of all userand location data
MQTT data leakageand ring control
Static TLS keystore,registration XSS
Outdated software, fake accountregistration, prototype pollutioninternal server error
— Duplicate apps,usage statistics
Disclosure 10/7/2018, unfixed 5/2/2019 5/13/2019 1/28/2020 — —
Figure 2: Anonymized snapshot most recent Nut reports.
Firmware Leakage. All Nut firmware, including unreleased prod-uct series, can be retrieved from the server. They are encrypted, butbefore installing an OTA update to a finder it is locally decryptedin the app with a static key.
Group Sharing. A group sharing link allows location informationaccess to other Nut users. We are able to generate arbitrary groupshare links for known finders of other users without using theapp’s QR code group share feature [7]. Share links are supposedto be generated locally inside the app. They contain the finder’sdeviceUUID, an expirationTime, and something internally calledhmac. This hmac is not what the name suggests since it is missing anencryption key. Instead, it is generated only from known values:
hmac=sha1( userUUID|deviceUUID|expirationTime)
This share link is used to request a shareRecordUUID from theserver. In the next step, a shareRecordUUID can be used to obtaina shareRecord. This shareRecord contains the share’s userUUID aswell as the userUUID of all users the finder is shared with. Moreover,some privacy-concerning details such as the last known positionof a finder are included.
This results in two vulnerabilities. First, an attacker can createshare links for all devices with a known deviceUUID and userUUID.Second, an attacker can generate a new share link and invite them-self even if the previous share expired or was revoked by the ownersince deviceUUID and userUUID leak with a share link.
Retrieving All Lost Finder Reports. All users of the Nut app reportlost finders. Only lost finders appear during a Bluetooth device scan,connected finders are invisible. Besides the lost finder’s ID and GPSposition, a report also contains the reporter’s identity, includingtheir mail address, phone number, and password hash.
An undocumented endpoint in the API leaks all recently seendevices to the public, which represents a severe privacy issue. Theendpoint is contained in the app, but is never accessed duringnormal app operation. Nut did not close this issue more than ayear after reporting it. Thus, we do not reveal the actual API call.Figure 2 illustrates an anonymized example of the attack’s impact.We limited the request to the server to the last few lost finders.Even though the API function requires the user’s device_id as anargument, it is ignored.
Responsible Disclosure. We wrote Nut an email on October 7,2018. On January 18, 2019 we sent them a letter to their mailbox inCalifornia. We also sent them a Twitter direct message on February4, 2019. Due to our unsuccessful attempts, we reported the issueto BSI CERT on March 5, 2019 who then forwarded it to US CERTwithout further response. Thus, BSI forwarded the information toCERT/CC on April 30 2019. We contacted Nut again over Facebookon April 3, 2019 and called the number listed on their Facebook sitebut were not able to contact them. We were also able to obtain theemail address of one of the developers—we sent them an email inChinese on April 5, 2019. CERT/CC recommended us to publiclyrequest CVEs disclose our findings. The missing certificate valida-tion in the app was assigned CVE-2019-16252. However, server-sideissues in custom applications, as it is the case for the remainingissues, are not eligible for a CVE.
3.2.2 Tile. Cloud features in the Tile ecosystem are more securethan in the Nut ecosystem. The notification backend is based onMessage Queuing Telemetry Transport (MQTT) and properly usingTLS and authentication. Yet, specific implementation details maketheir infrastructure vulnerable.
Firmware Leakage. Firmware is available on the server in plain-text. A valid link for the associated finder type can be extractedduring the firmware update process.
Lost and Found: PrivateFind WiSec ’20, July 8–10, 2020, Linz (Virtual Event), Austria
Public Static Credentials for MQTT Server. The app uses anMQTTserver to allow remotely ringing the phone via another device.Credentials for MQTT access are requested over a public API end-point. This way, credentials are not stored inside the app—and couldchange regularly. However, the MQTT credentials returned by theAPI are static and the same for all users. Thus, there is insufficientauthentication towards the MQTT backend and no user separation.
Controlling Other Users’ Phones. Once connected to the MQTTserver, a request to ring any connected phone can be issued. A validrequest must contain a tileUUID, but no further access control isperformed on requests. A tileUUID can leak over various ways. Forexample, it can be requested from any nearby Tile via Bluetooth,and remote attackers can extract it with the attack described next.
User Data Leakage. In MQTT, data is exchanged by publishingit to topics to which clients can be subscribed. Topic subscriptionsallow for wildcards by default [14, p. 57]. Tile blacklisted multi-levelwildcards represented with #, but did not include blacklist single-level wildcards with +. When subscribing to the wildcard topic +,an attacker can receive all MQTT messages, including messagesmeant for all Tiles and system messages. Specific messages that canbe intercepted include regular status messages of the type CONTROL
_STATUS_CHANGED sent by the phones, which include the user’s mailaddress, the user’s UUID, client UUID, and tileUUID. Combined withthe previous knowledge, the tileUUID can be used to ring the user’sphone. An attacker can also subscribe to the wildcard topic $sys
/#, the so-called sys topics. The broker responds with its uptime,program name, and version (Erlang MQTT Broker 2.2), as well asreal-time notifications of other clients connecting and disconnect-ing, including their client UUID, user name, and IP address.
Responsible Disclosure. We disclosed all issues with detailed ex-planations to Tile on May 2, 2019. They replied within one day andapplied fixes in a timely manner.
3.2.3 musegear & iTrackEasy. Attacks found in themusegear finderfamily are rather weak. However, they indicate design flaws thatmight originate from insufficient security testing.
Keystore. For customization, the app allows the vendor to con-figure different server locations. Since servers use individual TLScertificates, the app also has a local keystore with trusted certifi-cates. The password to protect this keystore is static and the samein both apps, musegear, and iTrackEasy. This enabled us to modifythe app and run a MITM attack for further analysis.
Registration Link. After creating an account, the user receivesan email with a registration confirmation link. It is possible toinclude Cross-Site Scripting (XSS) contents in the link to changethe website’s appearance in the browser.
Responsible Disclosure. We informed MS kajak7 UG and KKMCompany Limited, the companies behind musegear and iTrack Easy,on May 13, 2019. musegear reacted within less than an hour to ourfirst contact attempt, and we discussed all findings.
3.2.4 Cube Tracker. While we could not find any severe data leak-age within the Cube ecosystem, there are a lot of minor security is-sues. Their infrastructure is hosted on AmazonWeb Services (AWS),
and all traffic passes an Nginx server. Further services running inthe backend are AngularJS, ExpressJS, Mongoose, and MongoDB.
Firmware Leakage. The firmware is stored locally in the app. Itis neither signed nor encrypted.
Query Existing Users. The login website displays different errormessages for login failures versus non-existing users.
Fake Account Generation. Instead of confirming an email on ac-count generation, a user can call the API endpoint PUT /users/<
id>/edit. This allows the attacker to create an endless amount ofaccounts without the mail overhead.
Profile Picture. The profile picture can be set to an external URL.However, as far as we observed its usage, this picture is only pre-sented to the user themself.
Server-side JavaScript Prototype Pollution. It is possible to alterJavaScript values by sending malicious JSON payloads toMongoose.For example, we were able to pass a payload that turns the User
type into a generic Object type. When User-related methods arethen called on the Object, this causes an internal error of type 500
because themethod is not found. Note that this happens only withinthat request, it does not escalate into the whole web service. Wecannot exclude that remote code execution becomes possible viathis issue as we do not have access to the server’s implementation,but assume that this is very unlikely.
Outdated Software. The Nginx webserver indicates nginx/1.13.7in the header, which is an outdated version with multiple publiclyknown CVEs. Also, the AngularJS version 1.3.20 is out of support.
Responsible Disclosure. We contacted Cube Tracker on January28, 2020, and also sent a second mail containing more details. Theypromptly confirmed the reception, but communication did not con-tinue later, likely due to COVID-19.
3.2.5 keeper. We could not find anything remarkable. The appdoes not have any connected functionality besides the account,which is never used except for logging in.
3.2.6 iTracing, iSearching, FindELFI. Even though the apps for find-ers based on the ST17H26 chip do not report locations to the serveraccording to what we observed, their apps lack privacy and user-friendliness.
Usage Statistics. During installation, the app connects once to aserver to transmit usage statistics. The statistics only contain finderinformation but no user account.
App Duplicates. There seem to be around 15 copies of the orig-inal app in Android’s Google Play Store. In the best case, it is justcustomization for different resellers. However, it might be that somecopies contain malware or leak location data, even though Googleregularly checks for malware in apps.
3.3 Analysis ResultsThe hardware implementation of all Bluetooth finders is rathersimple. Finders themselves are not aware of locations or user data.Logic to find lost items is implemented in the app and cloud. Acommon architecture issue is that the cloud is retrieving GPS data
WiSec ’20, July 8–10, 2020, Linz (Virtual Event), Austria Weller et al.
from all users in plaintext. No matter if there is a vulnerability inthe implementation or not, users need to trust the cloud operatorto keep their location information private. Most apps continuouslytransmit finder locations to the cloud, regardless of their lost state.In the Tile and Cube ecosystems, which feature a Web platformwhere users can view their device locations from anywhere, thisis reasonable. In contrast, Nut finders are bound to a smartphoneinstallation anyway. Location traces are very privacy-sensitive asthey reveal a lot about the user’s habits—and, thus, could be soldfor marketing purposes and similar. Our security analysis showsthat even the leading vendors fail to protect location and user datain their clouds from being extracted by external attackers.
We claim that existing Bluetooth finders are privacy-invasive bydesign. In most situations, GPS data could be stored locally insidethe app. Only in lost mode, reporters need to transmit locationinformation to the owner—which can be end-to-end encrypted.Minimizing private data transferred and stored in plaintext reducesthe risk of data leakage if there are security issues.
4 PrivateFind: AN OPEN, SECURE, ANDANONYMOUS FINDER SOLUTION
In the following, we describe PrivateFind, which features a similararchitecture and hardware design as existing commercial products.PrivateFind enables finder crowd search without leaking privatedata. It prevents data leakage by design, as the server never seesany GPS locations in plaintext. Moreover, it enables anonymoususage of the crowd search ecosystem. It aims at preventing trackingby both the server infrastructure as well as other users. PrivateFindis publicly available on https://github.com/seemoo-lab/privatefind.
We define two setup variants with different security and privacyguarantees in Section 4.1. An anonymous lost finder reportingsystem is introduced in Section 4.2. Reports are independent ofthe setup procedure and, thus, compatible with both variants. Wediscuss protocol design decisions in Section 4.3. The hardware usedfor our open-source prototype and the corresponding Android appis shown in Section 4.4.
4.1 Setup ProcedureThe setup procedure establishes an end-to-end encryption key andidentifiers, proves that the owner currently owns the finder, andcomes in two variants.
End-to-end Encryption Key. During the setup, the finder and thesmartphone establish a pre-shared key e2e-key. The e2e-key canbe reset by running the setup procedure again. Keys are individualper device; any leaked key will only compromise one finder. Thee2e-key is symmetric due to the finder’s hardware limitations.
After the setup, this key never leaves the finder and the smart-phone. However, the finder can receive plaintext messages andencrypt them with this key, such that only the smartphone candecrypt it. This mechanism is used to hide GPS locations of reportsfrom the server by using the finder to encrypt reports about itself.Moreover, generating reports requires the physical presence of therespective finder. Based on these reporting properties, the reportercan stay anonymous when sending reports to the server.
Initial and Randomized Identifier. Moreover, the finder reveals itsfixed identifier idinit during setup. This identifier never changes,even if the finder is reset by repeating the setup procedure. Theformat of this identifier is implementation-specific, e.g., it could bea 256 bit random value. Both, the smartphone and the finder, use itin conjunction with the e2e-key, to derive randomized identifiersin fixed time intervals:
idrand,n+1= hmac(e2e-key, idrand,n)
While idinit never leaves the finder and the smartphone (but isknown to the server in the manufacturer-verified setup), the ran-domized idrand can be requested by nearby devices if the owner’ssmartphone lost the connection and if the finder internally can con-firm that it has not seen its owner since a while. Thus, PrivateFindfurther increases privacy by only revealing idrand if necessary. Thefinder does not appear in scan results while it has a connection toits owner, and it can choose to refuse excessive identity requests,even on the randomized and regularly changing identifier.
Proving Ownership. The setupmode that resets e2e-key and leaksthe unique identity idinit can only be performed by the finder’sowner. To enter the setup mode, the owner pushes and holds thefinder’s button. Only after pressing the button like this, the finderenters setup mode. Otherwise, it will not accept a reconfiguration.Once the setup is finished, the setup mode must be reactivatedagain by pressing the button if needed. We assume an attacker withphysical access whowants to steal an item attached to a finder couldas well remove the finder’s battery or shield it in tinfoil. This issimilar to the security assumptions made by other finder products.
Setup Variants. While both setup variants establish an e2e-key,exchange the idinit , and ensure ownership by physical access, theyslightly differ. The local variant in Section 4.1.1 features a modethat enables compatibility between different finder manufacturers.The manufacturer-verified variant in Section 4.1.2 enables the man-ufacturer to verify a finder’s identity and provides further securityto the Bluetooth communication. While we recommend using thelocal variant to improve privacy, manufacturers might prefer themanufacturer-verified variant, as it is closer to the ecosystems pro-vided by existing products. Both variants do not require the user toregister a personal account.
4.1.1 Local Setup. The local setup, which is shown as a sequencediagram in Figure 3a, ensures that the user has physical access to afinder. Moreover, the setup exchanges e2e-key and idinit . There isno third party involved in the local setup and there is no registrationwith a server. Note that in this local variant idinit can also bereset to a random value during the setup, as there are no externaldependencies on it.
4.1.2 Manufacturer-Verified Setup. The manufacturer-verified set-up increases security at the cost of privacy. It provides the samesecurity properties as the local setup. On top, it enables the man-ufacturer to validate that the finder is indeed one they created,and adds manufacturer-verified encryption to the Bluetooth setup.Even though finder validation makes the server able to identifya finder during setup, messages containing precise GPS locationdata will always be end-to-end encrypted between the finder andthe user who registered a finder with their smartphone. Thus, also
Lost and Found: PrivateFind WiSec ’20, July 8–10, 2020, Linz (Virtual Event), Austria
Owner Finder Phone
Push and holdbutton
SelectDevice(idinit )
e2e-key = random()e2e-key = random()
Setup(e2e-key)
SetupOK(idinit )
Store(idinit , e2e-key)
(a) Local setup without proof of ownership.
Owner Finder Phone Server
Push and holdbutton
SelectDevice(idinit )
RegisterInit(idinit )
setup-key = random()setup-key = random()
StartEncryptedSetup(setup-key,Enc(mf-key, setup-key))
Forward Enc(mf-key, setup-key))
Encrypted with setup-key e2e-key = random()e2e-key = random()
Setup(e2e-key)
Store e2e-key
SetupOK(idinit )
Store(idinit , e2e-key)
(b) Manufacturer-verified setup that proofs ownership of a legitimate device to the manufacturer.
Figure 3: Initial setup and registration variants.
this protocol variant ensures more privacy than any finder ecosys-tem we encountered in the wild. The overall process is depicted inFigure 3b.
Manufacturing Requirements. The manufacturer might want toverify their manufactured devices. To this end, the manufacturerinstalls an individual manufacturing key mf-key on each finder,which is associated with its identifier idinit . The mf-key is the rootof trust between server and finder. Each finder has an individualmf-key, which is never transmitted in plaintext but can be identifiedby its idinit .
Verification During Setup. The finder notifies the server thatidinit is now active. PrivateFind does not enforce any accountregistration, but in case the manufacturer would like to add this as
a property, they could add a mf-key-based setup challenge in thisstep. Note that, depending on the remaining implementation, thiswould also add reporter identities to the encrypted location reports.
Encrypting Bluetooth Communication. We assume communica-tion between app and server is not compromised since it can beprotected with TLS [18]. The server certificate must be validatedand ideally is pinned [19]. Encryption methods employed by TLSare not feasible on a low-cost finder device. Hence, the server gen-erates a temporary random setup-key, which is used to encrypt thesetup procedure. The communication during the setup, encryptedwith setup-key, is marked with an orange dotted box in Figure 3b.The setup-key is transferred to the app in two formats: plaintextand encrypted. The plaintext setup-key is for the app; the app does
WiSec ’20, July 8–10, 2020, Linz (Virtual Event), Austria Weller et al.
not have the mf-key to decrypt the encrypted one. The app for-wards the encrypted setup-key to the finder via Bluetooth. Only alegitimate finder can decrypt it with its mf-key.
This possibility of securing the registration procedure with themf-key improves security. We do not consider Bluetooth encryptionto be sufficient. Since the finder neither has a display nor a keyboard,Just Works pairing is applied. Assuming BLE 4.0 or 4.1 on at leastone of the involved devices, this mode is susceptible to passiveMITM attacks due to weak encryption methods [2, p. 277]. Evenin BLE 4.2 and higher, Just Works can be actively eavesdropped,as stated in the Bluetooth 5.2 specification [2, p. 274]. Using themf-key as an additional root of trust mitigates this MITM risk.
4.2 Privately Reporting Lost FindersBased on the initial setup information, finders can be located, asshown in the sequence diagram in Figure 4. This mechanism doesnot leak the lost finder’s location to the server, and the reporter’sidentity is not revealed.
A lost finder can be found by anyone because it will be discov-erable in Bluetooth scanning if it is not connected to the owner’ssmartphone. The reporter can send a message to a lost finder thatcontains the current GPS position. The finder answers this with anencrypted message that can only be decrypted by the owner withe2e-key. The finder only answers this message if it has not seen theowner for a few minutes to ensure that no unnecessary reports aregenerated. Finder and owner can use a pseudo-random sequence,if available on the finder, to prevent a replay of old locations. Thecurrent PrivateFind implementation prevents this with a counterand an authenticated encryption mode. The owner can look upreports by its calculated recent list of idrand .
4.3 Implementation VariantsIn the following, we discuss implementation variants and point outthe current state of the PrivateFind implementation.
Identity Randomization. The finder should randomize its MACaddress as mac_addrrand to prevent tracking by nearby devices.
Thus, the finder changes its address in regular intervals—otherwise,the randomization of the finder’s identifier idrand could be by-passed. This MAC address randomization feature is already in-cluded in the Bluetooth specification to ensure privacy for BLE [2,p. 3064ff]. Usually, this address changes every 15min, but the in-terval can be lowered to increase privacy. The interval of the MACaddress change and idrand update should be synchronized to pre-vent tracking via asynchronous changes.
Note that the current PrivateFind code release is not using MACaddress randomization, because it requires MAC addresses for asimplified, non-randomized finder identification during locationreports.
Report Delivery Modes. PrivateFind uses direct delivery of reportsto an owner. For direct delivery, the owner messages the server withthe currently valid idrand or a sequence of recently valid identities.
An alternative approach would be broadcast delivery. Since re-ports are encrypted, locations would not leak. This form of broad-cast delivery hides the fact which finder was lost and found atwhich point in time from the server. However, someone who lostan item needs to observe all reports, which causes a lot of trafficand leaks recently valid identities.
In the current PrivateFind implementation, a reporter is notgetting any feedback. Reporters cannot verify if a finder exists. Thisincreases security against attackers trying to leak valid identities.
Verifying Reporters and Reports. PrivateFind does not verify areporter’s identity on the server-side to increase privacy. Ownerscan check locally if a report was indeed created by their lost finderif it decrypts correctly and contains a valid number of a pseudo-random sequence. Moreover, anonymous location reports can bedisplayed differently inside the app than locations observed by theuser. This helps the user to check themself if the reported locationseems legit.
The server could verify if the reported finder is real by sendinga challenge similar to the one in the setup. The challenge can againmake use of the mf-key shared between server and finder, but withthe reporter as a relay. Such a challenge would make it impossible
Phone (Reporter) Finder Server Phone (Owner)
Finds unpaired devicewith unknown mac-addrrand
Finds unpaired devicewith unknown mac-addrrand
AreYouLost(geo-location)
e2e-message =Enc(e2e-key,geo-location || prng)
e2e-message =Enc(e2e-key,geo-location || prng)
IAmLost(idrand , e2e-message)
FoundResponse(idrand ,e2e-message)
Search(idrand,n..idrand,m)
Found(idrand , e2e-message)
Figure 4: Anonymous report of witnessed device.
Lost and Found: PrivateFind WiSec ’20, July 8–10, 2020, Linz (Virtual Event), Austria
to replay reports already on the server-side. A disadvantage ofthis approach is an increased load on the server for a property theowner can also verify locally. Moreover, it would require the serverto ask for idinit to look up the according mf-key, which woulddeanonymize reports.
The server could also restrict usage of their ecosystem to thoseuserswho legitimately purchased a finder. For this, themanufacturer-verified setup needs to be extended as follows. The server can senda challenge bound to a finder’s mf-key that can only be answered bya legitimate finder. If this challenge is answered correctly, the servercan either confirm a user’s account registration with this, or issuean account-less access token. Later, when users report lost findersor search for them, these actions can be bound to that account ortoken. While the GPS locations in such an approach remain en-crypted, this always reveals the user’s or finder’s identity. However,even this extension would still be more privacy-preserving thanexisting approaches that all share GPS locations to the server. Thecurrent PrivateFind code release has an option for such a token.
Deciding if a Finder is Lost. A finder that lost the connectionto the owner’s smartphone appears in Bluetooth scan results ofother smartphones. This might create a lot of reports in crowdedplaces with bad connection quality. Hence, the reporter asks thefinder if it has been disconnected for a while, instead of reportingit immediately. Yet, this still imposes a privacy issue. There is apossibility that an owner lost the connection but still knows theitem’s location, e.g., if the smartphone battery is empty. The reportincludes the reporter’s IP address, which can be used to make a rawguess on the finder’s geolocation.
Our PrivateFind implementation enables users to opt-out fromreceiving reports by setting a flag in the finder that disables thegeneration of reports. As long as this flag is set, the finder will neveranswer to an AreYouLost message.
The server can keep track of owners who report their finder aslost and propagate this information to reporters. Even though thisenables all users to see which finders are currently lost, the publicinformation is not associated with an IP address and the includedidrand is randomized.
Metadata on the Server. Users still need to trust the server insome means. The server can estimate the geolocation by IP ad-dresses. Message timing also allows it to guess whether reporterand owner are nearby and know each other. However, in PrivateFindthis information is only transferred if the finder confirms to be lost.In contrast to the default behavior in most commercial products,the amount of reports is minimized and additionally anonymized.In general, users being concerned about geolocations leaking by IPaddresses should use anonymization techniques such as Tor [16].Users could be selfish and not send reports for anything they foundbut still profit from other reporters if they are concerned aboutleaking information when reporting.
Identity Export. A user might use a finder with multiple phonesor backup the finder association in case of phone loss, the e2e-
key could be exported with a QR code. Without export, only onesmartphone at a time is supported. To replace the smartphone, thefinder must run through the setup procedure again, which resetsthe e2e-key.
4.4 PrivateFind ImplementationIn the following section, we detail how we realized PrivateFind inhardware, firmware, and as an Android app.
Hardware Platform. After disassembling common Bluetooth find-ers, we became aware of the nRF51822 Bluetooth Smart BeaconKit [13]. Its diameter is as small as 20mm, and it comes with allthe important features. During development, we used the BluetoothLow Energy Development Kit for the nRF51 Series [11]. It is based onthe same chip but meant for development, which means the boardcomes with additional input and output possibilities and is easierto flash—limitations for firmware running on the chip stay similar.
The development platform already comes with a basic finderexample, which triggers an alarm on Bluetooth connection loss.Only the PrivateFind setup, registration, and report procedures hadto be implemented.
Hardware Optimization. The development platform already of-fers some encryption methods, such as Advanced Encryption Stan-dard (AES). Encryption in the lost finder reporting is AuthenticatedEncryption with Associated Data (AEAD), e.g., AES-CTRwith a ran-dom nonce for the associated data and SHA256-HMAC for authen-tication. Depending on the hardware platform, different encryptionmethods can be used.
Android Application. The app runs in the background and main-tains a Bluetooth connection with the finder established. This isimplemented using the Android BLE library by Nordic Semiconduc-tor [12]. The last known position of a finder is saved locally andcan be displayed as shown in Figure 5b. Once the connection is lost,it plays a sound on the smartphone or on the finder, according tothe user’s preferences. Moreover, the app searches for other lostfinders in the background and reports these. To preserve battery onthe smartphone, we use the hardware offloading of the Bluetoothcontroller if supported.
(a) The twonRFplatforms:nRF51-DK (bottom) and nRF51822 (top). (b) Mobile app.
Figure 5: PrivateFind implementation.
WiSec ’20, July 8–10, 2020, Linz (Virtual Event), Austria Weller et al.
5 DISCUSSIONCrowd Search. Distributed item search requires a large user base
with the app installed and running. For example, finders of threedifferent brands were marked as lost, and the crowd search featurewas not able to find them near a busy train station in Germanywith approximately 250 000 people passing by in 2017 [5]. A lostitem can only be found within communities that commonly usefinders. This problem gets worse with the diverse finder marketsince reporting systems are not compatible at all. We observed thatonline shop ratings of the same finders differ a lot, depending onthe platform and region where they are sold, and assume this isdue to the distinct communities using these finders.
Privacy Policies. Besides the technical problems we uncovered incommon Bluetooth finders, their basic concept is already privacy-invasive depending on how data is handled exactly. Thus, we did acheck on the privacy policies of finders with online functionality.
Nut There are two different privacy policies forNut. One is pub-licly available on their website but only refers to data theirwebserver collects while browsing their sites, and anotherone that is displayed when installing the app. We considerthe policy in the app to be more relevant. Yet, the app privacypolicy of Nut is surprisingly short and written in very vagueterms. The policy does not even state that Nut is collectinglocation data. We assume that such a policy is not acceptableunder the EU General Data Protection Regulation (GDPR).
Tile Two privacy policies were in place at the same time beforeour report. When a user tried to create an account in theapp, a privacy policy from 2016 was shown. However, onthe website of Tile, a new policy from 2018 is shown [22].The policy of the app states that the location of the user istransmitted periodically. It also states that Tilemay collect in-formation for statistical purposes that cannot be traced backto an individual user anymore. In general, we consider theprivacy policy of Tile to be well-written and understandable.
musegear The privacy policy by the musegear app looks verysimilar to Tile. Their privacy policy states that location datashould be regularly saved on the device, but does notmentionthe regular transmission of this data. Also, their policy ishard to read due to formatting mistakes.
CubeTracker The privacy policy of Cube Tracker is surpris-ingly well-written, but still contains a placeholder where thetax identifier of the company should be inserted. It allowsCube Tracker to share data with third parties and also toupdate the policy, and the user will be notified about signif-icant changes. Also, it does not differentiate which data iscollected by the app locally and which data is shared withthe cloud service and third parties.
To summarize, the privacy policies of all tested Bluetooth finderswith connected features do not accurately reflect what the findersand corresponding apps are doing. Therefore, we would like toencourage the manufacturers to update their privacy policies. Ageneral issue is that the privacy policies in the apps differ fromthe ones on the websites, and the policies are subject to change.This makes the privacy policies very opaque in addition to missingdetails on how data is processed and stored.
6 CONCLUSIONWe conducted a comprehensive analysis of the most popular Blue-tooth finders currently on the market and analyzed their securityand privacy. None of the market-leading products is designed ina privacy-friendly way, and several of them have serious securityflaws on multiple levels:
• All products tested were designed and implemented withouta focus on privacy.
• Some of the tested products forced the user to create anaccount for a cloud service not immediately required forusing the product. Other products automatically reportedthe user’s location to a cloud service without an observablereason.
• Some of the products hadminor security vulnerabilities, suchas insufficient protection of the API against unauthorizedcommunication. Furthermore, some products omitted properTLS certificate validation of the backend services.
• A few products had serious security vulnerabilities in theircorresponding backend that enabled attackers to obtain ac-cess to private data of other users.
• One vendor ignored our reports about those weaknesses formore than a year, despite multiple attempts to get in touchwith them over several communication channels. Until to-day, the corresponding cloud service leaks private customerinformation that can be accessed easily.
Some implementations are highly suspicious, and we cannotrule out that this data may be collected for other purposes. Manyof those security and privacy problems can be fixed easily in theapp and the corresponding backend services, for example by notsending any unnecessary data to the cloud service. We decidedon a more thorough approach and designed and implemented theprivacy-friendly Bluetooth finder PrivateFind that prevents locationleakage to the cloud service. Users are able to report a lost andfound Bluetooth finder anonymously, and we believe our systemachieves a more advanced security and privacy standard than anycommercial system we analyzed. Our system provides the samefeatures as most commercial products and runs on the same orcomparable hardware. This shows that privacy-friendly and secureBluetooth finders can be built without increasing expenses for thehardware and without a loss of features for the user.
ACKNOWLEDGMENTSWe thank Max Maass and Nils Ole Tippenhauer for the discussionabout the PrivateFind protocol, Vanessa Hahn for the graphicsdesign, and Matthias Hollick for his support.
This work has been funded by the German Federal Ministry ofEducation and Research and the Hessen State Ministry for HigherEducation, Research and the Arts within their joint support of theNational Research Center for Applied Cybersecurity ATHENE.
REFERENCES[1] Apple. 2019. Set up Find My on your iPhone, Mac, and other devices. https:
//support.apple.com/en-us/HT210400.[2] Bluetooth SIG. 2020. Bluetooth Core Specification 5.2. https://www.bluetooth.
com/specifications/bluetooth-core-specification.[3] Cube Tracker. 2020. Cube Tracker – Instructions. https://cdn.shopify.com/s/files/
1/0257/8998/8936/files/cube_tracker_instructions_EN.pdf.
Lost and Found: PrivateFind WiSec ’20, July 8–10, 2020, Linz (Virtual Event), Austria
[4] Deral Heiland and Adam Compton. 2016. Multiple Bluetooth Low Energy (BLE)Tracker Vulnerabilities. https://blog.rapid7.com/2016/10/25/multiple-bluetooth-low-energy-ble-tracker-vulnerabilities/
[5] Jan-Keno Janssen, Michael Link, and Stefan Porteck. 2017. Verliermeinnicht:Neun Bluetooth-Tags im Test.
[6] Natasha Lomas. 2013. Tile Grabs $2.6M Via Selfstarter For Its Lost Property-Finding Bluetooth Tags Plus App. https://techcrunch.com/2013/07/24/tile-grabs-2-6m-via-selfstarter-for-its-lost-property-finding-bluetooth-tags-plus-app/
[7] NutTag Australia PTY LTD. 2019. Group Share. https://nuttag.com.au/blogs/user-guide/group-share
[8] NutTag Australia PTY LTD. 2019. Silent Zones - Region (iOS). https://nuttag.com.au/blogs/user-guide/silent-zones
[9] Mitmproxy Project. 2020. mitmproxy - an interactive HTTPS proxy. https://mitmproxy.org/.
[10] musegear.net 2019. Musegear Finder User Manual. musegear.net. https://musegear-finder.net/wp-content/uploads/2019/01/Bedienungsanleitung_original.pdf.
[11] Nordic Semiconductor. 2019. Bluetooth Low Energy Development Kit for thenRF51 Series. https://www.nordicsemi.com/Software-and-Tools/Development-Kits/nRF51-DK
[12] Nordic Semiconductor. 2019. Nordic BLE Library. https://github.com/NordicSemiconductor/Android-BLE-Library
[13] Nordic Semiconductor. 2019. nRF51822 Bluetooth Smart Beacon Kit. https://www.nordicsemi.com/Software-and-Tools/Reference-Designs/nRF51822-Beacon-Kit
[14] OASIS. 2014. MQTT Version 3.1.1. Technical Report. OASIS. http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/os/mqtt-v3.1.1-os.pdf.
[15] PortSwigger. 2020. Burp Suite - Cybersecurity Software from PortSwigger.https://portswigger.net/burp.
[16] Tor Project. 2019. Tor Project | Anonymity Online. https://www.torproject.org[17] Realm. 2019. Realm Database. https://realm.io/products/realm-database[18] E. Rescorla. 2018. The Transport Layer Security (TLS) Protocol Version 1.3. RFC
8446. RFC Editor.[19] David Sounthiraraj, Justin Sahs, Garret Greenwood, Zhiqiang Lin, and
Latifur Khan. 2014. SMV-Hunter: Large Scale, Automated Detectionof SSL/TLS Man-in-the-Middle Vulnerabilities in Android Apps. In 21stAnnual Network and Distributed System Security Symposium, NDSS 2014,San Diego, California, USA, February 23-26, 2014. The Internet Soci-ety. https://www.ndss-symposium.org/ndss2014/smv-hunter-large-scale-automated-detection-ssltls-man-middle-vulnerabilities-android-apps
[20] Maddie Stone. 2020. Android App Reverse Engineering 101. https://maddiestone.github.io/AndroidAppRE/.
[21] Tile. 2019. How it Works. https://www.thetileapp.com/en-us/how-it-works[22] Tile. 2019. Privacy Policy. https://www.thetileapp.com/en-us/privacy-policy
