S20+, SD Karte vor/nach Reset einsetzen? Auch verschlüsseln?

John39

Cadet 4th Year
Registriert
März 2022
Beiträge
70
Hallo Freunde

Hab jetzt nach längerer Zeit Mal wieder ein Handy, in dem ich eine SD Karte nutzen möchte.

Das S20+ ist vorhin angekommen und hatte bereits einen Vorbesitzer.

Möchte natürlich gerne einen Performance optimierten Neuzustand.

Ich hab jetzt im 1. Schritt das Handy zurück gesetzt. Das sollte hoffentlich reichen. Wenn nicht, sagt bitte bescheid?

Die externe 512 GB SD Karte hab ich noch nicht eingesetzt. Tut man das im Laufenden Betrieb, nachdem man das Handy zurück gesetzt und neu gestartet hat etc, oder lieber davor schon?

Wo muss man alles die Einstellungen vornehmen, dass in Zukunft ja alles über die SD Karte läuft?

Gibt es generell Dinge, auf die ich bei einem Einsatz einer SD Karte achten muss?

Ich möchte zb vermeiden, dass speicherlastige Apps oder irgendwas übers Handy laufen, und irgendwann der interne 128 GB Speicher voll wird.

Weiterhin :

Würdet Ihr die SD Karte verschlüsseln? Auf der einen Seite ist das super! Gerade bei Bildern/ Videos etc, dann kommt jemand anders nicht mehr an die Daten ran, richtig?
Auf der anderen Seite hab ich noch die Info von früher, dass dies die Performance des Handys bemerkbar langsamer macht.

Ich spiele keine Games, aber länger warten zu müssen bei öffnen von Bilder, Apps, beim Surfen, usw. wäre nicht schön.

Danke für Euren Support :)
 
John39 schrieb:
Tut man das im Laufenden Betrieb, nachdem man das Handy zurück gesetzt und neu gestartet hat etc, oder lieber davor schon?
Das ist komplett egal. Steck sie einfach rein während das Handy läuft und gut.

John39 schrieb:
Ich möchte zb vermeiden, dass speicherlastige Apps oder irgendwas übers Handy laufen, und irgendwann der interne 128 GB Speicher voll wird.
Wie viele Apps hast du so installiert, dass das eine Gefahr wird? In vielen Fällen kannst du Apps gar nicht mehr auf SD-Karte installieren (weiß nicht wie es beim S20 ist) und oftmals will man das auch gar nicht, da der interne Speicher viel schneller ist und man entsprechend Ladezeiten verkürzen kann. Wenn dann würde ich eher Fotos auf der SD-Karte parken.
 
ob eine App auf der SD-Karte installiert bzw. ausgelagert werden kann, ist von der App abhängig und hat mit dem Telefon selber erstmal nichts zu tun.
Sollte die SD-Karte nur in dem einen Telefon zum Einsatz kommen, würde ich sie verschlüsseln. Das stellt sicher, das sie nur mit dem einen Telefon gelesen werden kann. Sollte man sein Telefon nämlich mal verlieren, kann kein anderer die Daten auf der SD-Karte lesen.
Sollte das Telefon zurückgesetzt werden und die SD-Karte ist verschlüsselt, sind die Daten übrigens auch weg.
 
Wird das Handy denn bedeutend langsamer, wenn man die SD Karte verschlüsselt? :)

Also ja Apps hab ich schon sehr sehr viele :D Ah okay, also ist alles so wie "früher".. man kann viele Apps nicht auslagern ..

Da fällt mir gerade WhatsApp ein, das wird ja auch sehr groß mit der Zeit, was da alles für Medien dranhängen.. Mal sehen ob ich das auslagern kann

Ansonsten gucke ich Mal, dass ich die SD Karte als Standard für alles einstellen kann , müsste Mal suchen
 
Also in der Geschwindigkeit ist mir jetzt kein großer Nachteil aufgefallen...
WhatsApp lässt sich ganz gut verwalten, wie ich finde. Must halt ab und an aufräumen und die Sachen, die man behalten will, verschieben bzw. sichern.
 
roger1377 schrieb:
WhatsApp lässt sich ganz gut verwalten, wie ich finde. Must halt ab und an aufräumen und die Sachen, die man behalten will, verschieben bzw. sichern.

Kannst du das noch ein wenig erläutern? :-)
 
John39 schrieb:
Da fällt mir gerade WhatsApp ein, das wird ja auch sehr groß mit der Zeit, was da alles für Medien dranhängen.. Mal sehen ob ich das auslagern kann
Du kannst keine Apps komplett auslagern.

John39 schrieb:
Wird das Handy denn bedeutend langsamer, wenn man die SD Karte verschlüsselt? :)
Nein, denn beim starten des Handys wird sie einmalig entschlüsselt und das war es.
 
roger1377 schrieb:
ob eine App auf der SD-Karte installiert bzw. ausgelagert werden kann, ist von der App abhängig und hat mit dem Telefon selber erstmal nichts zu tun.
Ah okay. Mein letztes Smartphone mit SD-Slot ist leider ne Weile her, aber ich dachte dass die Hersteller teilweise die Funktion komplett unterdrücken.

siggi%%44 schrieb:
Nein, denn beim starten des Handys wird sie einmalig entschlüsselt und das war es.
So funktioniert das ziemlich sicher nicht. Dann bräuchte man den gleichen Speicherplatz nochmal, um dort die entschlüsselten Daten abzulegen und der Bootvorgang würde ewig dauern.

Moderne Chips haben aber Hardwarebeschleunigung für gängige Verschlüsselungsalgorithmen. Selbst ein Mobile SOC liest verschlüsselte Daten mit mehr als genug Tempo.
 
Conqi schrieb:
So funktioniert das ziemlich sicher nicht. Dann bräuchte man den gleichen Speicherplatz nochmal, um dort die entschlüsselten Daten abzulegen und der Bootvorgang würde ewig dauern.
Komisch, bis Android 10 war das eine anerkannte Verschlüsselungsmethode für den internen Speicher. Hab bisher nichts davon gelesen, dass man nur den halben Speicher belegen darf oder deswegen der Bootvorgang extrem lange dauert. Wenn du nicht weißt, ob es eine Full Disk oder File Based Encryption ist, können wir hier lange diskutieren.
 
@siggi%%44 Ich glaube, du hast bei der Erklärung bezüglich File Based und Full Disk was missverstanden. Auch bei Full Disk Encryption sind alle Daten auf der Festplatte durchgängig verschlüsselt. Sie sind lediglich alle mit dem gleichen Schlüssel verschlüsselt und für Apps auf dem System ergibt sich kein Unterschied, da immer die ganze Disk "freigeschaltet" wird. Intern werden die Daten aber schon bei jedem einzelnen Dateizugriff entschlüsselt. Man kann nicht mit einem Schlag eine ganze SD-Karte beim Starten ent- und beim Ausschalten wieder verschlüsseln.

Also egal welche Art der Verschlüsselung man wählt, man hat auf jeden Fall einen Performancenachteil. Bei modernen Systemen ist dieser allerdings in den meisten Fällen vernachlässigbar.
 
So wie ich das verstehe bezieht sich der Artikel mit "decrypt" auf die Betrachtung aus Anwender/System-Sicht für den ab diesem Zeitpunkt das Verzeichnis zugreifbar ist und nicht auf die tatsächliche Speicherebene.

Wie sollte das technisch auch sonst ablaufen? Der komplette Inhalt des /data Verzeichnisses müsste unverschlüsselt nochmal abgelegt werden und wäre dann bei einem ungeplanten Herunterfahren immer noch vorhanden. Das ist weder praktikabel, noch sicher. Die einzige Alternative wäre, alle entschlüsselten Daten im RAM zu halten und das geht aus nachvollziehbaren Gründen nicht.
 
@Conqi
This is what happens when you boot up an encrypted device that has a set password
So lautet der erste Satz. Weiter heißt es...
vold then mounts the decrypted real /data partition and prepares the new partition [...] This causes init.rc to start services in class main again and also start services in class late_start for the first time since boot.
Wäre mir neu, dass init.rc Services (main!) startet, wenn das Betriebssystem bereits läuft. Und hier ist ganz klar schon vorher /data gemountet und zwar entschlüsselt. Wenn erst bei Zugriff entschlüsselt wird, nennt man das File-Based Encryption.
 
siggi%%44 schrieb:
Wäre mir neu, dass init.rc Services (main!) startet, wenn das Betriebssystem bereits läuft.
Es ist doch relativ klar beschrieben, dass zum Entschlüsseln eine temporäre /data Partition genutzt wird, die anschließend die Schlüssel an das eigentliche System übergibt.

siggi%%44 schrieb:
Und hier ist ganz klar schon vorher /data gemountet und zwar entschlüsselt.
Ich werde jetzt zum dritten Mal fragen, wie das denn funktionieren soll. Sagen wir mal konservativ du hast 5 Gigabyte verschlüsselte Systemdaten. Wie sollen die komplett entschlüsselt werden ohne 5 GB im RAM zu belegen? Verschlüsselung heißt ja nicht, die Daten sind nur zugriffsgeschützt und können eben entsperrt werden, sondern da muss schon aktiv jedes Byte "wiederhergestellt" und dann irgendwo abgelegt werden.
 
Conqi schrieb:
Es ist doch relativ klar beschrieben, dass zum Entschlüsseln eine temporäre /data Partition genutzt wird, die anschließend die Schlüssel an das eigentliche System übergibt.
Also, noch mal von vorne:
Die Partition /data ist komplett verschlüsselt und nicht lesbar. Um aber eine funktionstüchtige Entschlüsselung mittels PIN/Passwort/Muster inkl. Eingabe am Display bereitstellen zu können, muss ein gewisser Teil nicht verschlüsselt zugänglich sein. Ohne /data, keine Funktionen. Ganz simpel.
Hier kommt das tmpfs ins Spiel.
[...] In order to encrypt, decrypt or wipe /data, /data must not be mounted. However, in order to show any user interface (UI), the framework must start and the framework requires /data to run. To resolve this conundrum, a temporary filesystem is mounted on /data. This allows Android to prompt for passwords, show progress, or suggest a data wipe as needed. [...]


Conqi schrieb:
Ich werde jetzt zum dritten Mal fragen, wie das denn funktionieren soll.
Ich weiß nicht, wo du hier ein Problem siehst. Eine Full-Disk Encryption ist nichts anderes als eine Festplatte, SD-Karte oder USB-Stick mit einer Verschlüsselung inkl. Passwortschutz. Vetschlüsselte SSDs können doch auch nicht nur aufgrund einer integrierten Verschlüsselung die halbe Speicherkapazität in Anspruch nehmen. Warum sollte das plötzlich bei einem Handy anders sein? Dort sitzt auch nur ein kleiner Flashspeicherchip auf dem Motherboard, der mit einer GUID-Partitionstabelle (GPT) formatiert ist. Wie bei jeder SD-Karte auch.
 
siggi%%44 schrieb:
Hier kommt das tmpfs ins Spiel.
Genau. Wi wodersprechen wir uns jetzt?

siggi%%44 schrieb:
Ich weiß nicht, wo du hier ein Problem siehst. [...] Vetschlüsselte SSDs können doch auch nicht nur aufgrund einer integrierten Verschlüsselung die halbe Speicherkapazität in Anspruch nehmen.
Ja und eine verschlüsselte SSD entschlüsselt die Daten daher auch erst beim Lesen, was einen gewissen Performancenachteil mit sich bringt. Darum geht es. Die Daten liegen niemals wirklich unverschlüsselt vor.

siggi%%44 schrieb:
Dort sitzt auch nur ein kleiner Flashspeicherchip auf dem Motherboard, der mit einer GUID-Partitionstabelle (GPT) formatiert ist. Wie bei jeder SD-Karte auch.
Das spielt dafür eh keine Rolle. Man verschlüsselt nicht nur die Partitionstabelle, da es sonst trivial wäre, ohne Passwort Daten wiederherzustellen.
 
Conqi schrieb:
So wie ich das verstehe bezieht sich der Artikel mit "decrypt" auf die Betrachtung aus Anwender/System-Sicht für den ab diesem Zeitpunkt das Verzeichnis zugreifbar ist und nicht auf die tatsächliche Speicherebene.

Conqi schrieb:
Es ist doch relativ klar beschrieben, dass zum Entschlüsseln eine temporäre /data Partition genutzt wird, die anschließend die Schlüssel an das eigentliche System übergibt.
Wenn ich diese beiden Aussagen im Kontext betrachte, ist aus deiner Sicht das tmpfs ein dauerhaftes Dateisystem, das permanent zur Entschlüsselung der aktuell genutzten Daten verwendet wird. Somit wäre dann eine komplette Entschlüsselung von /data hinfällig.

Einerseits wäre dies eine File-Based Encryption und andererseits wird das tmpfs nur einmalig angelegt, um z.B. das Display entsperren zu können. Das tmpfs wird also nur genutzt, um /data komplett zu entschlüsseln. Sobald dies erledigt ist, wird /data gemountet und das tmpfs ausgehangen.


Conqi schrieb:
Das spielt dafür eh keine Rolle. Man verschlüsselt nicht nur die Partitionstabelle, da es sonst trivial wäre, ohne Passwort Daten wiederherzustellen.
Das habe ich doch nicht behauptet, dass nur die Partitionstabelle verschlüsselt wird. In Wahrheit ist nämlich auch genau andersrum.
Dein Handyspeicher ist vom Aufbau her auch nichts anderes als eine SD-Karte oder vergleichbares. Die kann auch komplett ver-/entschlüsselt werden. Sie kann aber auch mit einer File-Based Encryption verschlüsselt sein. Beides kein Problem, v.a. was den Speicherbedarf betrifft.

In meinem Link oben wird die genaue Methode zur FDE genannt: AES-128-CBC mit ESSIV:SHA256
AES ist bekannt dafür, kaum Ressourcen zu verbrauchen. Denn grundsätzlich werden nur Speicherblöcke verschlüsselt. Bei ext4-Dateisystemen entspricht 1 Block = 4096 Byte (4KiB). Selbst der anfängliche Algorithmus für AES aus den 1970ern braucht pro Block max. 32 Byte. Das sind nur rd. 0,8% des zu verschlüsselnden Speichers.
Ergänzung ()

Ein ganz einfaches Beispiel:
Erstelle dir mit 7z ein beliebiges Archiv mit beliebiger Größe und setze für das Archiv ein Passwort. Bei 7z kannst du sogar noch AES-256 dazu wählen.
Egal, wie groß oder umfangreich das Archiv auch sein mag, das Entpacken des gesamten Archivs ist sofort nach Eingabe des Passwortes möglich. Öffnest du es ohne Passwort mit einem Hexviewer, hast du aufgrund der Verschlüsselung nur Datenmüll.

Vom Prinzip her ist das nichts anderes als eine Full-Disk Encryption.
 
Zuletzt bearbeitet:
siggi%%44 schrieb:
Wenn ich diese beiden Aussagen im Kontext betrachte, ist aus deiner Sicht das tmpfs ein dauerhaftes Dateisystem, das permanent zur Entschlüsselung der aktuell genutzten Daten verwendet wird.
Nein, ist es natürlich nicht wie der Name schon sagt. Der Teil, der für die Entschlüsselung notwendig ist, wird aber während das Handy läuft dauerhaft im RAM gehalten. Anders als andere Teile des Systems, die vom internen Speichern gelesen werden müssen und dabei entschlüsselt werden.

siggi%%44 schrieb:
Erstelle dir mit 7z ein beliebiges Archiv mit beliebiger Größe und setze für das Archiv ein Passwort. Bei 7z kannst du sogar noch AES-256 dazu wählen.
Egal, wie groß oder umfangreich das Archiv auch sein mag, das Entpacken des gesamten Archivs ist sofort nach Eingabe des Passwortes möglich.
Auch hier ist das aber nur augenscheinlich so. Das Archiv ist nicht ab dem Moment entschlüsselt wo man das Passwort eingibt, sondern erst sobald man die Daten tatsächlich öffnet, verschiebt oder sonst was damit macht. Die Daten liegen ansonsten immer noch in der gleichen Form wie vorher vor. Würde man jetzt eine uralte CPU nehmen, die AES nicht beschleunigen kann, würde man das auch in der Geschwindigkeit merken.

Wenn ich 10 GB verschlüsselte Daten habe und das Passwort eingebe, wie werden daraus dann auf einen Schlag 10 GB unverschlüsselte Daten und wo sind die ursprünglichen Daten hin? Es sieht lediglich für den Anwender so aus als wären die Daten jetzt entschlüsselt, aber auf der Festplatte liegen immer noch die genau gleichen Bits wie vorher bis zu dem Punkt wo ich das Archiv tatsächlich entpacke und die Daten unverschlüsselt auf die Platte schreibe. Ab dem Punkt habe ich die Daten aber halt auch doppelt.

siggi%%44 schrieb:
Vom Prinzip her ist das nichts anderes als eine Full-Disk Encryption.
Nein, ist es nicht. Full-Disk und File-Based Encryption ändern daran gar nichts.
 
Conqi schrieb:
Der Teil, der für die Entschlüsselung notwendig ist, wird aber während das Handy läuft dauerhaft im RAM gehalten. Anders als andere Teile des Systems, die vom internen Speichern gelesen werden müssen und dabei entschlüsselt werden.
Und das steht wo? Oder hast du das irgendwo mal gehört?

Conqi schrieb:
Ab dem Punkt habe ich die Daten aber halt auch doppelt.
Da ist nichts doppelt gespeichert, so funktioniert die Entschlüsselung nicht. Die Partition /data ist komplett unverschlüsselt gemountet! Es steht doch auch so in der Beschreibung:
6. Mount /data
vold then mounts the decrypted real /data partition and prepares the new partition
 
Zurück
Oben