Reboot vs. Screen-Lock von GrapheneOS

Hallo

habe gesehen, dass der Reboot-Intervall von GrapheneOS definiert werden kann. Dies wird als Sicherheitsfeature „angepriesen“.

Frage:
Was ist der Vorteil eines Reboots? Ist zum Beispiel der Zugriff auf das Dateisystem eines neu gestarteten Mobiles komplizierter, als wenn das Handy nur mit „Screen-Lock“ gesperrt ist?

Vielen Dank im Voraus!

Ein Neustart bringt das System in den „Before First Unlock Mode“, wodurch die Schlüssel zum Entschlüssen der Nutzerdaten von allen Nutzerprofilen nicht mehr im Speicher sind und dadurch viel höheren Schutz für physischen Angriffen bietet. Das kannst du für sekundäre Nutzerprofile auch durch Beenden der Sitzung erreichen. Der Sinn eines Auto-Reboots ist also dem Angreifer nicht genügend Zeit zu geben um das laufende Gerät zu knacken. Zudem greift beim (Neu-)Start „Verified Boot“, was die ganze Bootkette inklusive Betriebssystem (im Grunde alles außerhalb der App-Sandboxen) ausgehend von einer sogenannten „Immutable Root of Trust“ verifiziert, als letzte Verteidigungslinie eines „Deep System Compromise“.

4 „Gefällt mir“

Bei der forensischen Datenextraktion gibt es zwei Zustände von Bedeutung BFU und AFU. Der Zustand AFU (After first Unlock) ist gut denn der Verschlüsselungsschlüssel liegt bereits im RAM des Gerätes. Der Zustand BFU ist schwierig da alles vollverschlüsselt ist. Bei AFU ist es völlig egal ob per Fingerabdruck oder Code abgesichert, es besteht die Möglichkeit das Daten aus euren Geräten extrahiert werden können.

Wird euer Gerät zB von einer Behörde sichergestellt, kommt es unmittelbar in eine spezielle Transporttasche (ein farradayscher Käfig, also völlig abgeschirmt) damit das Gerät im Nachhinein nicht aus der Ferne gelöscht werden kann. Dann im Labor / Büro gibt es ebensolche spezielle Räumlichkeiten damit am Gerät gearbeitet werden kann. Näheres werde ich hier nun nicht erläutern.

Graphene OS hat hier eine Optiion implementiert die dafür das das Gerät nach einer vordefinierten Zeit in den Status BFU schaltet (es rebootet also). Bei mir ist diese Zeit auf 4 Stunden gesetzt. Wenn das Gerät also 4 Stunden nicht entsperrt wird, rebootet es.

Die Zeitspanne zwischen Sicherstellung eines Smartphones bis zur Abgabe im Labor ist schon nicht so lang aber ich denke das ich mit 4 Stunden auf der sicheren Seite bin :wink:

In Deutschland wird von den Behörden in der Regel die Cellebrite Touch verwendet die durchaus auch bei iphones in der Lage ist Daten auszulesen.

Die einzigen Gegner dieser Methode sind Iphones und Google Pixel Geräte. Optimal ist tatsächlich nur Graphene OS

Ein Samsung s23 ist zB in jedem Status auslesbar (unsere Regierungsgeräte sind Samsung und Iphones allerdings beide mit speziellen konfigurationen)

1 „Gefällt mir“

So wie ich verstanden habe ist das nicht so… " Probleme gefunden:

  1. Sobald der private Speicherplatz einmal entsperrt wurde, bleiben alle App-Daten und Dateidaten bis zum nächsten Neustart des Geräts unverschlüsselt verfügbar. Es hilft nicht einmal, das Profil explizit zu sperren"
    https://discuss.grapheneos.org/d/17236-new-security-audit-done-i-found-a-private-space-encryption-issue

Private Space und Work Profile ist nicht das was unter Android mit sekundären Benutzerprofilen gemeint.

Ob das ein Problem ist hängt vom Threat Model des Private Space ab. Er schreibt selbst:

This may be unexpected, but is probably as designed

Im GrapheneOS Issue tracker wird es als „enhancement“ kategorisiert, von daher nehme ich an, dass die bisherige Implementierung dem Threat Model entspricht.

Wobei zumindest noch unter Android 10 das Arbeitsprofil nach Deaktivierung wirklich wieder verrammelt wurde, d.h. auf die zugehörigen Dateien auch mit root nicht zugegegriffen werden kann.

An Geräten mit höherer Android-Version kann ich es leider nicht testen, „Verwaltetes Gerät“ und „Arbeitsprofil“ schließen sich leider seit Android 11 aus, ersteres ist mir wichtiger, „private space“ ist dadurch allerdings jetzt auch nicht möglich.

Mit dem root-Benutzer alleine gewinnst du sowieso keinen Blumentopf unter Android, da Selinux noch als Schutz da ist. Man bräuchte zusätzlich z.B. noch einen Selinux-Bypass.

Das, also SeLinux, ist dann wieder ein anderes Thema.
Ja, auch mit id 2000 (shell), wie mittels „adb shell“, sieht man z.T. Dinge, die root standardmäßig verborgen bleiben.