Volla Forum

Meine Frage gilt natürlich nur dann, wenn die Verschlüsselung auch aktiviert ist. Bezüglich des Gerätepassworts: das ist dann ja theoretisch (?) noch mal eine andere PIN als die PIN zum entsperren des Bildschirms.

Ich glaub das war die Gleiche, aber kann sein, dass ich einfach das gleiche Passwort genommen hab

Aber ganz davon abgesehen, die PIN ist sicherlich nicht der Schlüssel für die Verschlüsselung, wenn dann nur eine Untermenge der Schlüssel die dafür verwendet werden.

Irgendwie macht es für mich keinen Sinn, wenn die Verschlüsselung aktiviert wird, aber dass dann durch deaktivieren der Bildschirm PIN wieder rückgängig gemacht wird.

Das kann ich leider nicht beantworten, da müsste ich mich mal mit den Android Verschlüsselungsverfahren auseinandersetzen, aber ich denke das wird bei allen Androiden gleich sein, es wird niemand eine Extrawurst dafür braten.

Die Frage müsste eigentlich lauten:

"Ist im VollaOS die abfrage der PIN während des Bootvorgangs aktiviert, auch wenn ich den Screenlock deaktiviert habe?"

Auch "normale" Android Geräte unterscheiden ziwschen PIN Abfrage beim booten und nach dem Screenlock (...es wird dafür die selbe Zahlen bzw. Zeichenkombination verwendet - allerdings gibt es unterschieldliche "Eingabe-Situationen"). Die frühzeitige Eingabe der PIN beim Booten ("Geräte-PIN" bzw. "Device PIN") erfolgt unlogischerweise nur, wenn der Screenlock eingeschaltet ist, - also genau wie beim VollaPhone.

Es stellt sich die Frage, warum die Abfrage der PIN beim booten entfällt, sofern die Abfrage der PIN nach dem Screenlock deaktiviert wurde. IMO ist das nicht richtig, weil die Wahlfreiheit fehlt. Nur weil ich die Screenlock Pin deaktiviere, will ich doch nicht, dass die PIN beim Booten deaktiviert wird.

Im Gegenschluss bleibt die Frage, warum wird die PIN überhaupt beim Booten abgefragt, sofern der Screenlock eingeschaltet ist? Prinzipiell kann der Boot doch ohne PIN Eingabe erfolgen - die PIN wird dann ja nochmal später beim Screenlock abgefragt. Also warum vorher abfragen? Welche Vorteile soll das bringen? Welche Notwendigkeit gibt es dafür? Das Verhalten ist konträr zu dem von Desktop-PC's. Dort wird ganz logisch zwischen dem BIOS/UEFI Passwort und dem Passwort vom OS unterschieden.

Die PIN ist Schlüssel-Fragement für die File-Based-Encryption, diese kann nicht funktionieren ohne PIN - aber die PIN Eingabe wird nicht getätigt wenn Screenlock deaktiviert ist, also wie soll das dann funktionieren mit dem Entschlüsseln? Fragen über Fragen.

Gute Frage ich glaube, das ist zumindest bei mir so, dass das Passwort abgefragt wird, bevor das Betriebssystem gestartet wird, also benötigt um den Datenspeicher zu entsperren. So mache ich es bei allen meinen Betriebssystemen. Wenn es nicht so ist und der Datenspeicher eh automatisch entsperrt wird bringt es natürlich so gut wie nix (das ganze TPM geschisse am PC ) . Wie es beim Volla genau abläuft, bzw. Android, da muss ich echt passen, damit hab ich mich bis jetzt nicht so genau beschäftigt.

Übrigens, wenn man die Passwortsperre entfernen will sagt das Telefon ja eindeutig, dass der Geräteschutz entfernt wird, das bedeutet für mich auch, dass die Verschlüsselung dann weg ist. Möglicherweise sind die Daten dann zwar Verschlüsselt auf dem Datenträger aber natürlich ohne Passwort und damit von jedem und jederzeit lesbar.

Stingray hat geschrieben: ↑Sa 6. Aug 2022, 01:19 Übrigens, wenn man die Passwortsperre entfernen will sagt das Telefon ja eindeutig, dass der Geräteschutz entfernt wird, das bedeutet für mich auch, dass die Verschlüsselung dann weg ist.

Ja, wenn man die Screenlock-PIN nachträglich deaktiviert, kommt so eine Meldung. Wenn man sie aber gar nicht eingerichtet hatte vor der FBE oder FDE erscheint keine Meldung, dass der Prozess, - der ja eine Weile in Anspruch nimmt - sinnlos gewesen sein wird/ist/wäre/gewesen ist, oder dass das einrichten einer PIN oder einem äquivalent dafür essentiell ist.

Bei Gelegenheit werde ich das nochmal durchgehen .

Häufig werden die Begriffe Full-Disk-Encryption und File-Based-Encryption als XOR im Sprachgebrauch definiert. Das ist natürlich Quatsch. Beides ergänzt sich, bzw. kann sich ergänzen.

File-Based-Encryption inkl. Verschlüsselung der Metadaten (z.B. Dateigröße) wäre eigentlich die Norm, weil es in der Natur der Sache liegt:

Verschlüsselung sollte/darf keinen Rückschluss auf die Dateigröße zulassen (und diese Aussage ist AFAIK & de-facto Standard), aber ist das in der Realität von File-Based-Encryption wirklich so? Ich schätze es so ein, das eine 500 Byte Datei nach der Verschlüsselung immer noch deutlich kleiner ist als eine 1000 Mega-Byte Datei.

Von daher, erscheint es mir sinnvoll beide Methoden additionell zu verwenden.

Stingray hat geschrieben: ↑Di 21. Jun 2022, 13:39 Ein oft missverstandenes Prinzip . Mehr Sicherheit heißt nicht weniger Freiheit. Man muss auch in der Linux Welt auf Sicherheitsempfehlungen oder Richtlinien achten.

Wenn "mehr Sicherheit heißt nicht weniger Freiheit" bedeutet, dann frage ich Dich, was Du von mehr "Mehr Freiheit heißt mehr Sicherheit" hältst?.

Es gab doch mal diesen Slogan: "Freiheit stirbt mit Sicherheit".

Deine Aussage geht ja eher in die Richtung: "Sicherheit korreliert nicht mit Freiheit", oder übersehe ich da gerade etwas

Mehr Freiheit muss nicht mehr Sicherheit bedeuten und umgekehrt. Beides hat nur bedingt miteinander zu tun. Natürlich lässt sich mit weniger Freiheit vermeintlich mehr Sicherheit erkaufen, nur ist diese "Sicherheit" zumeist nur trügerisch und teuer erkauft.
Frei nach Yoda: "Die dunkle Seite der Macht ist nur schneller, leichter, verführerischer..."