Android Identifiers: Wie Android-Geräte und ihre Nutzer identifiziert werden

Dog Tags, © Postdlf (CC BY-SA)
Quelle: Wikipedia

In App-Rezensionen und Sicherheits-Berichten werden sie regelmäßig erwähnt: Identitäts-Informationen, auf welche Apps zugreifen möchten. Kennungen, die ausgelesen sowie unter Umständen „irgend wo hin übertragen“ werden. Dabei fallen dann Begriffe wie etwa „Google Werbe-ID“ oder „Android ID“.

Was hat es mit diesen auf sich, und welche „Identifier“ gibt es eigentlich? Wofür sind sie originär gedacht – und wofür werden sie im Alltag, ggf. missbräuchlich, verwendet?

Hintergrund

Nicht nur Apps, auch viele Webseiten und Online-Dienste versuchen, ihre Nutzer zu erkennen (und wiederzuerkennen). Dafür kann es verschiedene Gründe geben, wie beispielsweise:

Zugriffs-Analysen: Wie lange verweilt ein Anwender auf der Seite bzw. in der App, in welcher Reihenfolge folgt er den Informationen/Links, welche Seiten ruft er auf?
Schutz gegen Betrug: Von wo meldet sich ein Benutzer an seinem Konto an? Jemand, der sich gerade von Berlin aus angemeldet hat, kann dies kaum wenige Minuten später aus München tun. Auch ein Gerät, das nie zuvor hierfür verwendet wurde, kann auf einen Betrugsversuch (etwa mit gestohlenen Zugangsdaten) hindeuten.
Datenhandel: Erstellung von Nutzerprofilen für Marketing und Daten-Handel dürfte wohl das häufigste Anwendungsgebiet sein.

Der Erfassung dieser Daten hat der Anwender i. d. R. bei Installation der App über die Genehmigung der jeweiligen Zugriffsrechte (Permissions), oder bei Besuch einer Webseite über das Erfassen von Cookies zugestimmt. Den Wenigsten dürfte dabei jedoch klar (gewesen) sein, wie weitreichend die erfassten Informationen sind.

Es gibt zahlreiche derartige „Identifier“, die den Nutzer mehr oder weniger eindeutig „identifizieren“. Manche davon sind relativ unproblematisch – andere hingegen lassen weitreichende Rückschlüsse zu. Auf einige kann jede App oder Webseite zugreifen, andere wiederum sind durch ein Berechtigungssystem geschützt. Alle möglichen „Identifier“ aufzuführen und zu erklären, würde einen recht langen Artikel bedeuten. Ausgewählte Kandidaten sollen jedoch an dieser Stelle betrachtet werden.

Welche Identifier gibt es, und was ist ihr jeweiliger Zweck?

Device ID (auch Device Serial): Wie bei nahezu jedem Gerät, gibt es auch bei Androiden eine „Seriennummer“. Diese sollte den Gegenstand eigentlich eindeutig identifizieren, was jedoch beim Device Serial nicht immer zutrifft: Bei manchen NoName-Geräten (und custom ROMs) ist sie einfach nur mit 0123456789ABCDEF belegt. Genutzt wird sie z. B. von der Android Debug Bridge (ADB¹), um zwischen mehreren gleichzeitig angeschlossenen Geräten unterscheiden zu können. Der Befehl adb devices listet sie für diese auf. Man kann sie jedoch auch auf dem Gerät selbst finden, und zwar unter Einstellungen › Über das Telefon › Serial.
Device Build Fingerprint: Identifiziert das ROM in der spezifischen Version. Beispiel: Das Wileyfox Swift ist im Auslieferungszustand (mit CyanogenOS 12.1 / Android 5.1.1) als Wileyfox/Swift/crackling 5.1.1/LMY48B/YOG4PAS33J user/release-keys gekennzeichnet. Gespeichert ist der Fingerprint in der build.prop, welche Bestandteil des ROMs ist – weshalb sie auch einen Factory-Reset überlebt. Sie hilft z. B. auch herauszufinden, um welche exakte Variante des Smartphones es sich handelt.
MAC: Die MAC-Adresse identifiziert die jeweilige „Netzwerk-Karte“. Sie ist daher weltweit unique, abgesehen vielleicht einmal von „Fakes“ und „NoName Nachbauten“. WiFi und Bluetooth haben jeweils ihre eigene MAC-Adresse. Ab Android-6 können sie nur noch System-Apps auslesen, alle anderen erhalten immer den Standardwert "02:00:00:00:00:00"²; bei älteren Android-Versionen ist für den Zugriff die Permission ACCESS_NETWORK_STATE, ACCESS_WIFI_STATE bzw. BLUETOOTH erforderlich (von ca. 70%, 30% bzw. 10% aller Apps verlangt).³
Die MAC-Adresse ist fest im jeweiligen Chip gespeichert, und wird zur eindeutigen Identifizierung des Gerätes im Netzwerk benötigt: etwa zur Zuteilung einer IP-Adresse vom DHCP Server, oder zur Absicherung eines Netzwerks vor unliebsamen Teilnehmern (siehe MAC-Filter). Sie übersteht somit nicht nur einen Factory-Reset, sondern auch System-Updates sowie das Flashen eines custom ROM.
IMEI: Die „International Mobile Station Equipment Identity“ ist eine weltweit eindeutige ID für Mobilfunkgeräte (bei CDMA-Geräten: MEID sowie dessen Vorläufer ESN). Dies ist die eigentliche Seriennummer des Gerätes, und somit normalerweise fest im Gerät gespeichert – es gibt jedoch Ausnahmen (z.B. Samsung: /efs Partition). Daher ist sie auch resistent gegen einen etwaigen Factory-Reset sowie gegen das Flashen eines custom ROM, und übersteht beides problemlos.
Die IMEI wird beim Kontakt zum Mobilfunknetz an den Netzbetreiber übertragen. Einige Netzbetreiber sperren Geräte anhand der IMEI, wenn diese als gestohlen gemeldet werden. Will eine App diese ID auslesen, benötigt sie dafür die Berechtigung READ_PHONE_STATE, die jedoch etwa jede dritte App verlangt. Meist mit der Begründung, die eigene Aktivität bei eingehenden Telefonaten zu pausieren: Es wäre doch ärgerlich, wenn etwa der Musik- oder Video-Player im Hintergrund weiter Geräusche von sich gibt – oder man den Level in einem Spiel verpasst, weil sich die Telefon-App in den Vordergrund drängt. Warum dies nur (unbewusst) „vorgeschoben“ ist, lässt sich u. a. diesem Artikel bei Stack Exchange (ganz am Ende) entnehmen.
IMSI: Die International Mobile Subscriber Identity identifiziert die SIM-Karte in GSM-, UMTS- und LTE-Mobilfunknetzen, und ist daher auch auf dieser gespeichert. Es handelt sich hierbei um einen eindeutigen Identifier – an dem u. a. der jeweilige Netzanbieter entscheidet, ob das Gerät sein Netzwerk nutzen darf, und wie diese Nutzung abgerechnet wird (Tarif, Roaming, etc.). Ebenso wie bei der IMEI benötigen Apps auch hier für den Zugriff die Permission READ_PHONE_STATE. Die IMSI überlebt also sogar noch einen Gerätewechsel ohne Probleme.
Für die Telefonnummer benötigen Apps wiederum die Permission READ_PHONE_STATE – auf das eingebuchte Netzwerk (MNC / MCC) erhalten sie jedoch Zugriff, ohne über jegliche Permissions zu verfügen. Ebenso können sie den aktuellen „Call State“ (ob also gerade ein Gespräch eingeht oder geführt wird) sowie Roaming-Status direkt einsehen.

Was eine App ohne die Berechtigung READ_PHONE_STATE zu sehen bekommt

Die Android-ID (aka SSAID für Settings.Secure#ANDROID_ID) wird bei der ersten Inbetriebnahme erstellt und identifiziert das Gerät (bzw. bei Multi-User den jeweiligen User). Anders als die GSF Android-ID (siehe nächster Punkt) ist sie auf jedem Android-Gerät vorhanden, und wird im lokalen Dateisystem in einer Datenbank gespeichert, auf die man nur mit root-Rechten zugreifen kann. Ein Factory-Reset macht ihr den Garaus – aber natürlich wird dann beim nächsten Start eine neue SSAID erstellt.
Ab Android 8 (Oreo) ist die SSAID nicht länger global: Jede App erhält ihre eigene SSAID. Damit soll das Tracking über App-Grenzen hinweg eingeschränkt werden.
Die GSF Android-ID wird vom Google Services Framework (GSF) bei dessen Initialisierung erstellt, und ist somit nur auf Androiden mit installierten Google-Apps vorhanden. Sie dient als ID für sämtliche Google Services (Playstore, Google Cloud Messaging (GCM), etc.), und ist im lokalen Dateisystem in einer Datenbank gespeichert, auf die man nur mit root-Rechten zugreifen kann. Auch ihr macht ein Factory-Reset den Garaus (siehe vorigen Punkt).
Die Google Werbe ID (aka GAID, Google Advertising ID) ist „eine eindeutige ID für Werbezwecke, die von den Google Play-Diensten bereitgestellt wird“. Auch sie wird im lokalen Dateisystem in einer Datenbank gespeichert, auf die man nur mit root-Rechten zugreifen kann. Der Anwender kann sie jedoch unter Google Einstellungen › Werbung zurücksetzen. Für den Zugriff auf diese ID benötigen Apps lediglich die Permission INTERNET – welche ca. 80% aller Android-Apps auch anfordern.
Hostname: Dieser dient zur Identifikation im Netzwerk. Er wird u. a. an DHCP-Server übertragen, wenn man sich in Hotspots einbucht. Vom Benutzer in den Entwickler-Einstellungen einseh- und änderbar.
IP Adressen dienen sowohl im WLAN als auch im mobilen Netzwerk zur Identifikation des Gerätes. Gewöhnlich werden sie vom jeweiligen DHCP-Server zugewiesen. Der Anwender selbst kann sie nicht verändern (außer durch Festlegung des entsprechenden Adressbereiches im eigenen WLAN-Router). Auch hier benötigen Apps eine Permission für den Zugriff: ACCESS_NETWORK_STATE (70%) für das mobile Datennetz bzw. ACCESS_WIFI_STATE (30%) für das WLAN Interface.
Nachbarzellen („neighboring cells“) und sichtbare WLANs: Wer sich häufig am gleichen Ort aufhält (etwa zu Hause), kann auch darüber identifiziert werden (der Standort ebenfalls). Für sich allein ist dies keine „eindeutige Identifizierung“ – zusammen mit anderen Merkmalen aber schon. Lässt sich nur beeinflussen, indem man z. B. in den Flugzeugmodus wechselt.
Eingerichtete Accounts („Konten“) und Email-Adressen sind i. d. R. ziemlich eindeutig. Über die Permission GET_ACCOUNTS erhalten Apps darauf Zugriff: Auf die Konten generell, aber oftmals auch auf die Email-Adressen, da diese häufig das jeweilige Konto identifizieren (etwa hansmustermann@gmail.com für das Google-Konto).
Eigentümer-Info: Dies ist der sogenannte „Me“ oder „Ich“ Kontakt, der gewöhnlich vom Anwender selbst im Adressbuch gepflegt werden muss. Hat man hier nichts hinterlegt, gibt es auch nichts zu holen – selbst wenn eine App über die dafür notwendige Berechtigung READ_PROFILE verfügt.
Auf die Liste installierter Apps darf jede App mit der Berechtigung GET_TASKS (etwa 10% aller Apps) zugreifen. Die Kombination installierter Apps (und ihrer Versionen) identifiziert ein Gerät schon recht genau. Noch ein paar andere „grobe Merkmale“ dazu, und die Eindeutigkeit ist nahe.

An welcher Berechtigung erkenne ich, dass eine App Zugriff auf diese ID hat?

In obiger Liste bereits mit aufgeführt, sei dies hier nochmals kurz zusammengefasst:

Device_ID/Serial/Build Fingerprints: NONE
IMEI/IMSI/Telefonnummer/verbundene und erreichbare Mobilfunknetze: READ_PHONE_STATE
MAC: READ_NETWORK_STATE, READ_PHONE_STATE bzw. BLUETOOTH
Android_ID: hier konnte ich keinen Beleg finden; evtl. READ_SECURE_SETTINGS?
GSF Android_ID: READ_GSERVICES
GAID: INTERNET
Hostname: ACCESS_NETWORK_STATE?
IP Adressen, verfügbare Datennetze (incl. sichtbarer WLANs): ACCESS_NETWORK_STATE bzw. ACCESS_WIFI_STATE
Benachbarte Mobilfunkzellen: READ_PHONE_STATE
Accounts: GET_ACCOUNTS
Owner-Info: READ_PROFILE
installierte Apps: GET_TASKS

Mögliche Schutzmaßnahmen

Wie kann man sich gegen missbräuchliche Zugriffe auf die genannten Identifiers schützen?

Ohne root

… sind die Möglichkeiten, wie gewöhnlich, begrenzt. Das Naheliegenste ist natürlich, vor der Installation einen Blick auf die Berechtigungen zu werfen, die eine App verlangt. Der Google Play Store (und insbesondere die zugehörige App) machen dies nicht gerade einfach: Bei beiden sind die gewünschten Informationen gut versteckt. Einfacher (und vollständiger) geht dies etwa bei AppBrain – oder auch, sofern dort vorhanden, in den hiesigen App-Listen. Gehen dabei die Augenbrauen hoch, lässt man lieber die Finger von der App. Oder erkundigt sich zuvor in Bewertungen sowie Foren, was es mit den „ungewöhnlichen Berechtigungen“ auf sich hat.

Wie – zu spät? App bereits installiert? Nun, diese Kandidaten lassen sich mit einem Permission Checker abklopfen. Und im Anschluss gegebenenfalls deinstallieren, sowie durch eine geeignete Alternative ersetzen. Im Zweifelsfall konsultiert man auch hier einschlägige Foren, was es damit auf sich hat.

Vorbeugend kann man auch in den Entwickler-Einstellungen den Hostnamen auf etwas generischeres ändern – anbieten würde sich dafür etwa localhost. In Grenzen lassen sich ab Android 4.3 bis vor Android 6.0 mit AppOps FrontEnds bzw. ab Android 6.0 nativ Apps einzelne Berechtigungen wieder entziehen. Doch das ist eher eine Farce als eine wirkliche Hilfe, wie der Security-Experte Mike Kuketz feststellt⁴.

Gelegentlich hilft es auch, den Entwickler der betroffenen App zu kontaktieren. Dieser ist sich oftmals nicht bewusst, welch tiefe Eingriffe sich von ihm verwendete Werbe- und Analytics-Module⁵ gönnen – und daher nach Kenntnisnahme durchaus bereit, selbige durch etwas „harmloseres“ zu ersetzen.

Mit root

Xprivacy: Zufallswerte

… ist schon wesentlich mehr möglich:

mittels XPrivacy allzu neugierigen Apps Fake-IDs unterjubeln. Mit der gleichen App lassen sich auch wunderbar und sehr feingranular Apps einzelne Berechtigungen entziehen.⁶
Das Device Serial lässt sich mittels Shell-Zugriff ändern: echo -n {neues Serial} > /sys/class/android_usb/android0/iSerial erledigt dies bis zum nächsten Boot. Für eine dauerhafte Lösung integriert man diesen Aufruf in der Datei /system/etc/install-recovery.sh.
Für die Änderung der MAC-Adresse (ahem, i. d. R. nicht wirklich ändern, sondern eher „überlagern“) gibt es diverse Netzwerk Spoofer.
Die Android-IDs ließen sich mittels sqlite direkt in der jeweiligen Datenbank manipulieren. Wer dies vor hat, sollte jedoch recht genau wissen, was er tut.

Weiterführendes

Was sind „Identifier“? (Android)
Is there a unique Android device ID?
What´s the difference between the GSF ID and the Android ID?
auslesen per ADB: z. B. mit Adebar
Best Practices for Unique Identifiers
- avoid using SSAID and IMEI
- only use Advertising ID for profiling/ads
- (use self-generated, app specific IDs whenever possible)
What Are Mobile Device Identifiers?
The Many Identifiers in Our Pockets
District court rules a unique device identifier is PII (and what companies do with it)
Android-Device-ID und IMEI herausfinden: So klappts
Device Identifiers – Chartboost Help Site (inkl. Formate)
IMEI vs. MEID what is the difference?

appsprivacy

Für Details zur ADB sei auf den Artikel ADB für Anwender hier bei IzzyOnDroid verwiesen ↩︎
Laut ArsTechnica ist der Zugriff für „normale Apps“ über die Permissions ACCESS_FINE_LOCATION resp. ACCESS_COARSE_LOCATION möglich. ↩︎
Die Statistiken, wie viele Apps eine bestimmte Permission anfordern, beruhen auf der Analyse der über dreizehn tausend hier bei IzzyOnDroid gelisteten Apps, Stand 8/2016 ↩︎
Mike´s Blog ist auf Sicherheitsthemen fokussiert. In seinem Artikel Das Android Berechtigungsmodell: Ein perfides Konstrukt setzt er sich detailliert mit dem Android Berechtigungsmodell auseinander. Absolute Lese-Empfehlung! ↩︎
So ist beispielsweise Flurry Analytics recht intrusiv, siehe App Analytics Raises Privacy Concerns ↩︎
Zu Xprivacy und dem XPosed Framework, siehe auch den Artikel Xposed: Die mächtige Android-Toolbox hier bei IzzyOnDroid ↩︎

2016-08-21 (2017-09-12)

IzzyOnDroid