Kommentare zu folgendem Beitrag: GhostTouch: Gezielte Angriffe auf Touchscreens
An Orten wie einem Café, einer Bibliothek, einem Besprechungsraum oder einer Konferenzlobby könnten die Leute ihr Smartphone mit dem Bildschirm nach unten auf den Tisch legen. Ein Angreifer könnte die Angriffsausrüstung unter dem Tisch verstecken und Angriffe aus der Distanz starten.
Kai Wang
Sehr geehrter Herr Wang,
ich antworte ihnen mit…
…es ist wohl wahrscheinlicher, dass der Akku ihrer Angriffsgeräte unter dem Tisch eher schlapp macht, als das die Voraussetzungen alle so eintreffen, wie sie diese für den Angriff bräuchten! Außer, sie hätten mehr Glück als Verstand und die Tischplatte eine Fläche von nur 100 cm^2…
Als kostenfreien Tipp eines interessierten Lesers, kann ich ihnen gerne verraten, wie man die Reichweite der Antenne, mittels eines metallischen Fliegengitters, auf die gesamte Tischfläche ausweitet…
Dann müssten sie nur noch dafür sorgen, dass die Person das Telefon mit dem Display nach unten dort ablegt.
Der Satz ziemlich weit hinten im Artikel, wie man sein Gerät schützen kann, ist ja krass. Man soll sein Smartphone mittels PIN, Gesichtserkennung oder Fingerabdruck sichern, dann kann nichts passieren.
Gibt es wirklich SO viele Menschen, die keine dieser Möglichkeiten nutzen? Falls ja, dann haben Fieslinge auch ganz ohne technische Spezialausrüstung ein leichtes Spiel, nämlich wenn die Bequemlichkeitsdeppen ihr Gerät einfach mal wo liegenlassen, verlieren oder es geklaut wird.
Zwar ein wenig offtopic, aber gibt es eigentlich sowas wie veracrypt für android? Ich finde nur Apps, die gezielte Datein verschlüßeln, ich würde das gerne vorm Boot von Android haben. Notfalls kann man sensible Daten auf der Speicherkarte haben, diese dann verschlüßeln, das mache ich bereits mit Winrar und zich langen PW´s , würde aber lieber alles dicht haben.
edit
https://source.android.com/security/encryption
https://developer.android.com/training/articles/direct-boot
FDE: Full Disk Encryption
Die FDE-Verschlüsselung stand am Anfang bei Android. Technisch gesehen handelte es sich um eine Festplattenverschlüsselung auf Basis von dm-crypt. Insbesondere bei diesen tieferen Bereichen von Android merkt man oft die Linux-Basis, denn letztlich ist das nicht viel anderes als die LUKS-Vollverschlüsselung bei Linux.
Technisch war das natürlich etwas aufwendiger. Die Verschlüsselung erfolgte in der üblichen Blockdevice-Methode, bei der die gesamten Userdata-Partition verschlüsselt wurde. Die Verschlüsselung erfolgte mit einem einzigartigen Schlüssel, der gleichermaßen an den Benutzer-PIN gebunden und mittels TEE signiert wurde. Mit diesem Schlüssel wurden jene Bereiche verschlüsselt, in denen Android Benutzerdaten speichert.
Es gab nur ein grundlegendes Problem. Bei einem Neustart des Android-Smartphones waren viele Funktionen nicht verfügbar, bevor der Anwender seine Passphrase eingegeben hatte. Beispielsweise Wecker oder auch Telefonanrufe. Das war natürlich für ein Smartphone-Betriebssystem keine zufriedenstellende Lösung.
Android ab Version 10 nutzt nur noch die FBE-Methode.
FBE: File Based Encryption
Um diese Beschränkungen zu beheben, hat Google ab Android 7 die dateibasierte Verschlüsselung (FBE) eingeführt. Dabei handelte es sich um eine Neuentwicklung auf Basis des für Android verwendeten Dateisystems ext4. Die Umstellung hat je nach OEM-Hersteller etwas gedauert, weshalb zwischen den Versionen 7 und 9 die Verschlüsselung je nach Konfiguration und Hersteller unterschiedlich funktioniert hat, aber heute ist FBE die Standardverschlüsselung.
Ein netter Nebenaspekt: Diese Erweiterung des ext4-Dateisystems zog mit Kernel 4.1 bzw. 4.6 (fscrypt) direkt upstream ein und kommt dadurch allen Linux-Anwendern zugute. Die Adaption verzögerte sich hier etwas, aber mit systemd-homed steht nun erstmals eine praktikable Umsetzung für den Linux-Desktop zur Verfügung.
Technisch gibt es zwei Bereiche. Den Standarspeicherplatz (Credential Encrypted = CE), der erst nach der Entschlüsselung zur Verfügung steht und den sogenannten Device Encrypted (DE) Speicher, der während des Direct Boot-Verfahrens Anwendungen ermöglicht mit begrenztem Datenzugriff zu funktionieren.
Anfänglich war ein Nachteil der FDE-Methode die fehlende Verschlüsselung der Metadaten (Berechtigungen, Dateigröße, Verzeichnis-Layout etc.). Diese berechtigte Kritik kann man auch heute noch häufiger lesen, wenn es um Android-Verschlüsselung geht. Das Problem hat Google in Android 9 behoben und es ist somit nicht mehr aktuell.
Der wesentliche Unterschied für den Anwender: Mit FBE gesicherte Android-Geräte booten ganz normal in den Sperrbildschirm und bieten dort auch vor der Entschlüsselung durch den Anwender Funktionalitäten wie Anrufe, Wecker etc.
Sobald der Anwender einen PIN, eine Passphrase und/oder biometrische Merkmale hinterlegt hat, ist die Verschlüsselung aktiviert. Normalerweise geschieht dies bereits bei der Initialisierungsroutine. Anwender müssen mehrfache Warnungen überspringen, um ihre Geräte ohne entsprechenden Schutz nutzen zu können. Das ist meiner Ansicht nach die richtige Vorgehensweise. Überprüfen lässt sich der Status in den Einstellungen und Sicherheit und dort in Verschlüsselung und Anmeldedaten.