GrapheneOS-Schutzmechanismen gegen Datenextraktion aus gesperrten Geräten

 (discuss.grapheneos.org)
1 Punkte von GN⁺ 1 시간 전 | 1 Kommentare | Auf WhatsApp teilen
  • GrapheneOS kombiniert auf Basis von Android-17-Sicherheitsfunktionen und aktueller Pixel-Hardware Festplattenverschlüsselung, Schutz vor Brute-Force-Angriffen, Abmilderung von Angriffen auf das Betriebssystem und Abwehr bei physischem Zugriff
  • Das neueste Sicherheitselement begrenzt PIN- und Passworteingaben auf maximal 20 Versuche und verzögert nach 10 Fehlversuchen um 4 Stunden, nach 15 Fehlversuchen um bis zu 41 Tage; Firmware-Änderungen ohne Authentifizierung des Owners werden verhindert, wodurch auch Insider-Umgehungen blockiert werden
  • Unterstützt werden Passwörter mit bis zu 128 Zeichen sowie optional Fingerabdruck + zweite PIN, sodass sich 6 bis 8 zufällige Diceware-Wörter als Hauptpasswort nutzen lassen, während die alltägliche Entsperrung bequem bleibt
  • Im gesperrten Zustand werden neue USB-Verbindungen sowohl software- als auch hardwareseitig blockiert; automatische Neustarts nach 10 Minuten bis 72 Stunden und das Zurücksetzen des Speichers versetzen das Gerät wieder in den Zustand Before First Unlock
  • Duress-PINs und -Passwörter löschen das Gerät, wenn sie in einem Authentifizierungsfenster eines beliebigen Profils eingegeben werden; der generelle Datenschutz beruht jedoch nicht allein auf dieser Funktion, sondern auf Verschlüsselung, Hardware-Sicherheit und Angriffsminderung

Verschlüsselung und Begrenzung von Authentifizierungsversuchen

  • Die Festplattenverschlüsselung direkt zu brechen, ist selbst für die raffiniertesten Angreifer kein realistischer Weg; Angreifer müssen entweder Schwachstellen des Betriebssystems im Zustand After First Unlock ausnutzen oder PINs bzw. Passwörter per Brute Force erraten
  • Die Rate-Limiting-Funktion des Sicherheitselements in Android 16 QPR2 erhöht die Verzögerung je nach Anzahl der Fehlversuche stufenweise
    • Nach 10 Fehlversuchen gibt es 4 Stunden Verzögerung, nach 15 Fehlversuchen bis zu 41 Tage; insgesamt sind höchstens 20 Versuche erlaubt
    • Fünf verschiedene zuletzt fehlgeschlagene Werte werden frühzeitig abgelehnt, damit wiederholte Tippfehler nicht die Versuchszahl verschwenden
    • GrapheneOS unterstützt nur Geräte, die das Rate Limiting der neuesten Generation von Sicherheitselementen implementieren
  • Um die Firmware des Sicherheitselements auf unterstützten Geräten zu aktualisieren, sind nicht nur ein gültiger Signaturschlüssel und eine höhere Versionsnummer erforderlich, sondern auch eine Authentifizierung des Owner-Nutzers
    • Selbst wenn eine Regierung die Erstellung einer Firmware erzwingen würde, die das Rate Limiting entfernt, ließe sie sich nicht installieren, um die Beschränkung zu umgehen
    • Pixel-Geräte verwenden seit dem Ende 2017 erschienenen Pixel 2 Sicherheitselemente mit internem Timer und Schutz vor Insider-Angriffen; seither wurde auch die Integration mit dem Betriebssystem verbessert
  • GrapheneOS erhöht die maximale Passwortlänge von 16 auf 128 Zeichen, sodass passphrasen mit hoher Entropie auf Basis von Diceware genutzt werden können, ohne sich auf das Rate Limiting des Sicherheitselements verlassen zu müssen
  • Der optionale Fingerabdruck mit zweiter PIN unterstützt zugleich ein starkes Hauptpasswort und eine bequeme alltägliche Entsperrung
    • Vor dem ersten Entsperren (Before First Unlock) wird ein Hauptpasswort aus 6 bis 8 zufälligen Diceware-Wörtern verwendet; danach kann eine Kombination aus Fingerabdruck und kurzer PIN genutzt werden
    • Auch nach Erkennung eines gültigen Fingerabdrucks muss die zweite PIN eingegeben werden, damit Bildschirm und Hardware-Keystore entsperrt werden
    • Die zulässigen Fingerabdruckversuche sinken von 20 auf 5, und eine falsche zweite PIN zählt ebenfalls als Fehlversuch

Betriebssystem- und Schutzmaßnahmen bei physischem Zugriff

  • GrapheneOS erhöht mit einem gehärteten Memory Allocator und hardwaregestützten Funktionen wie Hardware Memory Tagging (MTE) die Schwierigkeit von Angriffen auf das Betriebssystem; Details stehen unter Exploit-Schutzfunktionen
  • Um Angriffe mit physischem Zugriff auf das Gerät zu verhindern, werden neue USB-Verbindungen im gesperrten Zustand standardmäßig auf Software- und Hardwareebene blockiert; sobald eine aktive USB-Verbindung verschwindet, werden Datenfunktionen ebenfalls sofort deaktiviert
  • Der im Juni 2021 eingeführte Timer für automatische Neustarts gesperrter Geräte kann auf 10 Minuten bis 72 Stunden eingestellt werden
    • Der Standardwert lag zunächst bei 72 Stunden, wurde später jedoch auf 18 Stunden gesenkt
    • Durch Herunterfahren und erneutes Booten des Betriebssystems wird der Speicher zurückgesetzt und das Gerät in den Zustand Before First Unlock zurückversetzt
    • Im April 2024 wurde das Zurücksetzen des Speichers auch für das Booten in den Firmware-fastboot-Modus von Pixel ergänzt
    • Apple und Google haben automatische Neustarts gesperrter Geräte ebenfalls in iOS 18.1 und Android 16 ergänzt; unter Android lässt sich dies über den Advanced Protection Mode aktivieren
  • Android verwendet für sekundäre Nutzer und jeden Private Space eigene Verschlüsselungsschlüssel
    • In GrapheneOS können diese Bereiche durch das Beenden einer sekundären Nutzersitzung und über die jeweiligen Umschalter ohne Neustart wieder in den Zustand Before First Unlock zurückversetzt werden
    • Um die Daten des Hauptnutzers wieder in einen verschlüsselten Ruhezustand zu versetzen, verbleibende Daten im RAM vollständig zu löschen und sogar Updates des Sicherheitselements zu blockieren, ist ein vollständiger Neustart des Geräts besser

Datenlöschung in Zwangssituationen

  • Eine Duress-PIN bzw. ein Duress-Passwort löscht das Gerät, wenn es in einem beliebigen Authentifizierungsfenster des Betriebssystems eingegeben wird, das die PIN bzw. das Passwort des aktuellen Profils verlangt
    • Es funktioniert nicht nur auf dem Sperrbildschirm, sondern in allen Fenstern, die eine Authentifizierung erfordern, etwa bei sensiblen Einstellungsänderungen
    • Es kann in allen Profilen verwendet werden, einschließlich Hauptnutzer, sekundären Nutzern und Private Space
    • Es funktioniert auch bei Eingabe als zweite PIN für die Entsperrung per Fingerabdruck, gilt jedoch nicht für die SIM-PIN
  • Man kann eine Duress-PIN bzw. ein Duress-Passwort auch auf einem Zettel in der Handyhülle oder im Portemonnaie notieren; da das Löschen eines Geräts in einer tatsächlichen Zwangssituation jedoch physische und rechtliche Folgen haben kann, sollte die Nutzung sorgfältig abgewogen werden
  • Die Duress-Funktion beseitigt die Möglichkeit einer Datenwiederherstellung vollständig, selbst wenn die PINs und Passwörter aller Profile bekannt sind; sie ist jedoch kein zwingend notwendiger Schutzmechanismus. Die gesamte Schutzfunktionalität ist in der Funktionsliste von GrapheneOS und im Release-Changelog zu finden
  • Derzeit bietet nur Pixel die von GrapheneOS geforderten Hardware-Sicherheitsfunktionen und Updates, dies soll sich jedoch durch die Zusammenarbeit mit Motorola Mobility und Fortschritte bei Qualcomm ab 2027 ändern

Verwandte Beiträge

1 Kommentare

 
GN⁺ 1 시간 전
Meinungen auf Hacker News

  • Dieser Beitrag scheint als Reaktion auf den Fall veröffentlicht worden zu sein, in dem ein Pixel bei einer US-Grenzdurchsuchung per Zwangs-PIN zurückgesetzt wurde und es anschließend zu einer Anklage kam, um klarzustellen, dass GrapheneOS auch ohne Zwangs-PIN einen starken Schutz gegen Datenextraktion bietet.
    Kürzlich erschien außerdem ein Artikel von Computer Weekly, dem zufolge der automatische Neustart nach 18 Stunden von GrapheneOS ein Gerät wieder in den Zustand vor der ersten Entsperrung (BFU) versetzt und so die Schlüssel-Extraktion verhindert hat, wodurch Recherchedaten eines Journalisten und vertrauliche Quellen geschützt wurden.

    • Ich frage mich weiterhin, wie man jemanden nach Gesetzen anklagen kann, die nur in den USA gelten, wenn die betreffende Person sich nicht auf US-Territorium befand.
    • Das Zitat im ersten Artikel, wonach „GrapheneOS grundsätzlich kriminell sei“, ist ziemlich suggestiv. Am Ende entsteht dadurch das Framing, dass Schutz kriminell und Verwundbarkeit gesetzestreu sei.
    • Das Intervall für automatische Neustarts lässt sich auf mindestens 10 Minuten reduzieren. Wenn eine Beschlagnahmung absehbar ist, etwa beim Grenzübertritt oder bei einer Demonstration, ist es besser, es vorübergehend kurz einzustellen oder das Gerät selbst neu zu starten, um es in den BFU-Zustand zu versetzen.
    • Der Guardian-Artikel wurde in einem früheren HN-Thread diskutiert, der Computer-Weekly-Artikel wurde dagegen nur eingereicht und kaum weiter diskutiert.

  • GrapheneOS braucht eine vollständige Backup- und Wiederherstellungsfunktion, damit man ein Telefon vor dem Grenzübertritt vorsorglich zurücksetzen kann. Es wäre gut, wenn sich wie bei Google Cloud oder iCloud alle Apps und Daten auf einem privaten SSH-/SFTP-Server sichern und wiederherstellen ließen.
    Statt eine Zwangs-PIN zu verwenden und eine Anklage zu riskieren, würde ich lieber das Telefon zurücksetzen, dann selbst ein paar Kontakte, eine Passkopie und das Flugticket als PDF darauflegen und bei der Einreisekontrolle auf Verlangen die echte PIN herausgeben. Für die Reise müsste man sich nur den Passwortmanager oder die Passphrase für einen entfernten SSH-Server merken, bei Bedarf nur die nötigen Daten wiederherstellen und sie jederzeit wieder löschen.
    Wenn das allerdings zur Standardfunktion wird, könnten Ermittlungsbehörden bei allen GrapheneOS-Nutzern Remote-Speicher vermuten und Zugriff sowie Wiederherstellung verlangen; daher könnte eine separate Konfiguration besser sein. Eine weitere Möglichkeit wäre, ein unauffällig wirkendes Fake-Google-Konto vorzubereiten, das nur für gewöhnliche Käufe und YouTube-Abos genutzt wird.
    In drei Wochen steht bei mir eine einmonatige Auslandsreise an, und ich überlege, ob ich mein Telefon zurücksetzen oder das Haupttelefon zu Hause lassen und ein neues Gerät für 150 Euro mitnehmen soll, auf dem nur Notfallkontakte der Familie gespeichert sind. Immerhin verrät der Sperrbildschirm allein nicht, dass es sich nicht um normales Pixel-Android handelt.

    • GrapheneOS hat bereits ein verschlüsseltes Backup-System, das deutlich mehr Daten abdeckt als Googles Cloud-Backup. Es funktioniert im Geräte-zu-Geräte-Übertragungsmodus, sichert auch Apps mit allowBackup="false" und unterstützt beliebige Synchronisierungsdienste, die eine kompatible API bereitstellen.
      Da Backups profilbezogen sind, kann man sie auch in einem sekundären Nutzer wiederherstellen und testen. Eine umfassende Überarbeitung ist geplant, um Implementierung und Nutzererlebnis einfacher und sauberer zu machen; derzeit werden zunächst andere Apps überarbeitet.
    • Ein Ersatz für SeedVault ist geplant: verschlüsselte Backup-Funktion, zugehöriges Issue
    • Nützlicher erscheint mir eine Funktion, mit der man mit einem anderen Passwort eine versteckte Datenpartition bootet und die Alltagspartition verbirgt. Wie bei LUKS sähe ein Speicher-Dump dann wie Zufallsdaten aus, und nur das richtige Passwort würde die passende versteckte Partition finden und entschlüsseln.
      Wenn die Eingabe einer speziellen PIN auf dem Sperrbildschirm nach kurzer Verzögerung in eine Köderpartition bootet, hätte man nicht nur bei erwarteten Grenzkontrollen, sondern auch bei spontanen Kontrollen eine plausible Bestreitbarkeit.
    • Ein vollständiges Backup auf einem persönlichen verschlüsselten Server mit Wiederherstellung per Knopfdruck ist unbedingt nötig. Wenn das Telefon beschädigt oder gestohlen wird, muss man sonst stundenlang Dinge neu installieren und neu konfigurieren, die SeedVault übersehen hat, und ich sorge mich auch, den Zugriff auf Konten zu verlieren, die an Schlüssel im Secure Element gebunden sind.
    • Ich frage mich, ob man in zivilisierten westlichen Ländern tatsächlich an der Grenze ins Visier geraten kann, nur weil auf einem Pixel GrapheneOS installiert ist.

  • Die Android-Mustersperre bietet nur Log2(389112) ≈ 18,57 Bit Entropie. Sie ist schwächer als drei zufällige Zeichen, vier Kleinbuchstaben oder sogar eine sechsstellige dezimale PIN.
    Lange Passwörter kann man sich mit Merktechniken merken, aber die Eingabe ist unbequem. Wenn sie zu lang sind, könnte man doch etwa die Verwendung eines Hash-Digests erlauben; starke Passwörter selbst zu verhindern, fördert Wiederverwendung oder schlechte Gewohnheiten wie das Zusenden an sich selbst.

    • GrapheneOS unterstützt Passwörter mit bis zu 128 Zeichen für Diceware-Passphrasen. Mit einer starken Passphrase muss man sich nicht auf das Secure Element verlassen, und eine zufällige sechsstellige PIN ist dank der Versuchsbeschränkung des Secure Elements sicher. Da insgesamt nur 20 Versuche möglich sind, kann sogar eine zufällige vierstellige PIN ausreichen.
      Für die Fingerabdrucksperre lässt sich eine zweite Authentifizierungs-PIN hinzufügen, sodass man eine starke Passphrase bequem verwenden kann, ohne die Nachteile einer rein biometrischen Authentifizierung. Die Mustersperre verleitet dazu, nur einen winzigen Teil der tatsächlich möglichen Kombinationen zu nutzen, und ist damit weit schwächer als die Berechnung nahelegt; weil sie ein falsches Sicherheitsgefühl vermittelt, haben wir sie vor Jahren entfernt. Eine integrierte Funktion zur Erzeugung zufälliger PINs und Passphrasen ist ebenfalls in Arbeit.
    • GrapheneOS reduziert die Zahl der Fingerabdruckversuche von 20 auf 5 und kann auch nach einem korrekten Fingerabdruck eine zweite PIN verlangen. In BFU kann man 6 bis 8 zufällige Diceware-Wörter verwenden und im Alltag bequem Fingerabdruck plus kurze PIN kombinieren.
      Die AOSP-Beschränkung wurde geändert, sodass Passwörter mit bis zu 128 Zeichen erlaubt sind. Lange Passphrasen muss man nur nach einem Neustart eingeben; ein Vorteil ist, dass sie selbst dann schützen, wenn das Secure Element ausgenutzt wird.
    • Aktuelle Pixel-Geräte haben ein TPM-ähnliches Bauteil, das Brute-Force-Angriffe verhindert. Wenn das Muster nicht offensichtlich ist, hat ein Angreifer nur 20 Versuche, bevor zusätzliches Schlüsselmaterial gelöscht wird und der Verschlüsselungsschlüssel verloren geht.
      Seitenkanalangriffe auf den Sicherheitschip sind theoretisch möglich, erfordern aber bereits bekannte, geprüfte Angriffsmethoden sowie das Zerlegen des Geräts und präzise, destruktive Arbeiten.
    • Ich habe selbst auf GrapheneOS ein 35-Zeichen-Passwort eingerichtet, und es funktioniert völlig problemlos.

  • Es ist absurd, dass man wie ein Krimineller behandelt wird, wenn man Sicherheitsgarantien wie bei Apple-Geräten möchte. Auch Apple hat automatische Neustarts, vollständige Verschlüsselung und den Lockdown Mode.

    • Die Behörden haben nicht nur an GrapheneOS, sondern auch an Apple etwas auszusetzen, aber iPhone-Nutzer als Kriminelle zu bezeichnen, macht einen leicht zur Zielscheibe von Spott. Dagegen lässt sich die Installation eines Drittanbieter-Betriebssystems leicht als fremd darstellen und marginalisieren, nur weil sie ungewohnt ist.

  • Das Ergebnis der Eingabe eines Duress-Passworts sollte für die Person, die das Telefon übernimmt, nicht erkennbar sein. Die echten Kontoinformationen sollten gelöscht werden, aber es sollte ein Betriebssystem mit plausiblen Inhalten angezeigt werden, etwa höflichen, bedeutungslosen E-Mails, damit Ermittler etwas durchsehen können.

    • Das ist eher eine Funktion, die man Köder-Passwort nennen würde, nicht Duress-Passwort.
    • Man könnte Apps und einen Teil der Daten in einen separat gesperrten Bereich legen und nach dem Entsperren des Geräts eine zusätzliche PIN verlangen. Eine Duress-PIN könnte beim Öffnen des Geräts diesen Bereich löschen und es so aussehen lassen, als sei der sichere Bereich nie eingerichtet gewesen.
      Google Photos, Samsung und verschiedene andere Betriebssysteme und Dienste bieten Funktionen für gesperrte Daten an.
    • Die Duress-PIN bzw. das Duress-Passwort von GrapheneOS gibt nicht vor, ein heimlicher Reset zu sein, sondern führt den vom Nutzer erwarteten Reset sicher aus. Es ist nicht Aufgabe des Projekts zu entscheiden, wie die Funktion in Situationen mit Strafverfolgungsbehörden genutzt werden soll, oder Rechtsberatung zu leisten; Gesetze unterscheiden sich je nach Rechtsraum und Kontext stark, daher sollte man einen Anwalt fragen.
      Beim Löschen eines Profils bleiben Metadaten, die dessen Existenz belegen, auf dem Gerät und im verschlüsselten Speicher des Eigentümerprofils zurück. Auch ob und wann ein Reset durchgeführt wurde, lässt sich per ADB leicht feststellen; daher kann keine plausible Abstreitbarkeit geboten werden, und Nutzer in dem Glauben zu lassen, dies sei heimlich, würde sie gefährden.
      Auch das Verbergen von Androids Private Space kaschiert ihn nur notdürftig in der Benutzeroberfläche; es gibt mehrere öffentlich bekannte Erkennungsmethoden, und ihn selbst gegenüber ADB vollständig zu verstecken, ist realistisch kaum machbar. Unvollständige Funktionen werden durch Online-Diskussionen schnell bekannt und in LLMs, Forensik-Tools und Leitfäden integriert werden.
      GrapheneOS-Funktionen müssen auch gegenüber Angreifern funktionieren, die von der Existenz der Funktion wissen. Eine Duress-PIN ist nicht von der echten PIN zu unterscheiden, sodass selbst bei einer von einem Nutzer erhaltenen PIN, der die Funktion gar nicht verwendet, die Möglichkeit einer Duress-PIN in Betracht gezogen werden muss.
      Für künftige Geräte soll Duress-PIN-Unterstützung als Teil der Weaver-Begrenzung für Fehlversuche direkt in das Secure Element integriert werden, damit sie auch nicht über Betriebssystem-Schwachstellen umgangen werden kann.

  • Ich frage mich, ob das Gerät auch nach der ersten Entsperrung (AFU) geschützt ist, wenn es gesperrt bleibt. Da man es häufig nutzt, bringt es wenig, wenn AFU-Daten nicht geschützt sind, selbst wenn man es sperrt, bevor Ermittlungsbehörden oder Angreifer es in die Hände bekommen; Behörden können mit Tools wie Cellebrite auch noch am selben Tag eine Analyse durchführen.
    Das ist ähnlich wie bei VeraCrypt, wenn man den PC eingeschaltet lässt, weil ein Neustart lästig ist; in diesem Fall kann über einen Speicherabzug entschlüsselt werden.

    • GrapheneOS schützt auch gesperrte Profile im AFU-Zustand stark. Standardmäßig wird 18 Stunden nach dem Sperren automatisch neu gestartet, um das Zeitfenster für funktionierende Exploit-Angriffe zu begrenzen; Nutzer können den Wert bis auf 10 Minuten senken.
      Die 18 Stunden sind so gewählt, dass der Neustart selbst bei Menschen, die ihr Telefon nur ein paar Mal am Tag benutzen, fast nie ausgelöst wird. Meist reicht es, etwas länger als die maximale Schlafdauer zu sein; ein Neustart mitten in der Nacht ist an sich in Ordnung, kann aber dazu führen, dass man Notfallkontakte oder Ähnliches verpasst, die keine Mobilfunkanrufe sind.
      Auch aus den jüngst veröffentlichten Cellebrite-Premium-Dokumenten geht hervor, dass es keine Angriffsmethode gegen gesperrte GrapheneOS-Geräte gibt, die seit einem bestimmten Patchstand aus dem Jahr 2022 aktualisiert wurden.

  • Ich frage mich, ob die Zusammenarbeit zwischen GrapheneOS und Motorola noch läuft und wann Motorola-Geräte erscheinen werden.

  • Wenn ich durch TSA- oder Einreisekontrollen gehe, schalte ich Telefon und Laptop immer aus. In den USA kann man meiner Ansicht nach nicht gezwungen werden, ein Passwort herauszugeben, und wenn das Gerät ausgeschaltet ist, ist es schwer, das Passwort zu knacken, selbst wenn es beschlagnahmt wird.

    • Durch Ausschalten oder Neustarten den BFU-Zustand herzustellen, ist deutlich sicherer. Nach den aktuellen Cellebrite-Leaks scheint GrapheneOS selbst im AFU-Zustand nicht angreifbar zu sein.
      Der automatische Neustart von GrapheneOS lässt sich auf minimal 10 Minuten setzen; Standard sind 18 Stunden. Danach haben auch Google und Apple einen festen 72-Stunden-Timer eingeführt.
      Allerdings wäre in GrapheneOS eine schnellere Ausschalt-Verknüpfung wünschenswert. Soweit ich weiß, muss man derzeit eine physische Taste drücken und dann noch einmal auf dem Bildschirm bestätigen.

  • Passender xkcd: https://xkcd.com/538/

    • Ich mag dieses Meme nicht. Der Kernpunkt ist, den Angreifer zumindest dazu zu bringen, mit dem 5-Dollar-Schraubenschlüssel Gewalt anzuwenden und damit, je nach Land, eine schwerere Straftat zu begehen als die, die dem Nutzer vorgeworfen wird.
    • Laut einem entsprechenden Artikel klagt das US-Justizministerium den Einwohner von Atlanta Samuel Tunick an, weil er einem Grenzbeamten bei der Durchsuchung eines Google Pixel eine GrapheneOS-Duress-PIN gegeben haben soll.
      Er hat zwar ein Passwort herausgegeben, aber offenbar eines, das das Telefon zurücksetzt, statt es zu entsperren. Überraschend ist, dass er das Gerät vor der Durchsuchung nicht gesichert hat.

  • Man könnte eine abgeschwächte Duress-PIN bauen, die nur ausgewählte Apps löscht, ohne aufzufallen. Oder App-Daten auf einen festgelegten Wiederherstellungspunkt zurücksetzen, sodass es aussieht, als sei nichts passiert, und auch die Einrichtung nicht nachverfolgbar machen; das könnte helfen, rechtliche Risiken zu verringern.

    • Für zuverlässiges Löschen braucht man Hardware-Unterstützung, um Schlüssel zu vernichten. Android verwendet pro Nutzer und Private Space separate Schlüssel, sodass sich die gesamten Daten oder bestimmte Profile zuverlässig löschen lassen; um verbleibende Spuren im Speicher zu beseitigen, ist auch ein Neustart wichtig.
      Die Existenz und der Löschzeitpunkt eines bestimmten Profils bleiben jedoch in Dateisystem- und Betriebssystem-Metadaten klar erkennbar. Auch Spuren kopierter und geänderter Dateien bleiben überall auf der SSD zurück; nach längerer normaler Nutzung ist es für eine sichere Löschung bestimmter Bereiche zu spät, und eine Wiederherstellung kann möglich sein. Schon die Tatsache, dass erwartete Metadaten und Statistiken fehlen, wird zum Beweis.
      Möglich wäre eine Funktion, die in reserviertem Speicher alle Passphrasen als gültig akzeptiert und bei nicht eingerichteten oder falschen Fällen Zufallsausgaben liefert. Für eine saubere Implementierung bräuchte man virtuelle Maschinen und standardmäßig reservierten Speicher, dennoch könnte eine Low-Level-Analyse der SSD möglicherweise belegen, dass die Funktion genutzt wurde.
    • Eine auch gegen forensische Analyse sichere Methode ist unmöglich. Wenn man keine robuste plausible Abstreitbarkeit implementiert, erzeugt das ein falsches Sicherheitsgefühl und bringt Nutzer in Gefahr; GrapheneOS wird so etwas daher nicht einführen.