[ROM-Patch] Defyluks: Systemverschlüsselung für das Defy(+) mit CM7

[Defier]

Defyluks - Systemverschlüsselung für das Defy(+)

Thread bei XDA​

Achtung: Dieser Patch ist momentan nur für Leute geeignet, die sich mit Linux und LUKS auskennen und deshalb genau wissen, was sie tun! Ich übernehme keine Verantwortung für Schäden jeglicher Art an euren Geräten!​

Vor dem Ausprobieren rate ich dringend zu einem kompletten Backup eures Geräts! Eine Deinstallation ist momentan nicht möglich, ausser durch Rücksetzen des Geräts via sbf-flash.

Stand: 02.12.2012

== Motivation ==
Bislang gibt es keine Möglichkeit, die Datenpartition und die SD-Karte eines Defy(+) komplett zu verschlüsseln. Eine solche Möglichkeit ist zwar theoretisch ab Android3 direkt im System eingebaut, in den derzeitigen Builds von CM9/CM10/CM10.1 ist das Feature jedoch noch nicht implementiert. Viele Defy-Nutzer sind der Ansicht, dass Android 2.3 (u.a. durch den geringeren RAM-Bedarf) auf dem Defy besser läuft als Android 4, daher ist die Möglichkeit der Verschlüsselung für Android 2.3 selbst dann interessant, wenn es diese auch in einem Android4-basierenden CM irgendwann in der Zukunft geben sollte.

Ein generelles Problem dieser eingebauten Verschlüsselung ist zudem, dass die Datenpartition nicht optional auf der SD-Karte gehalten werden kann - dadurch ist bei einem Geräteschaden (z.B. Sturz) ohne weiteres kein Zugriff von extern auf die Daten möglich. Liegt die Datenpartition jedoch auf der SD-Karte, kann diese einfach aus dem Gerät entnommen und mit auf anderen Systemen verfügbaren Werkzeugen (LUKS und Linux, FreeOFTE unter Windows) eingehängt werden.


== Verwandte Projekte ==
Es gibt ein paar verwandte Projekte, diese eignen sich jedoch nur für andere Geräte (HTC Wildfire, Nexus One):

LUKS/LuksApp (https://github.com/guardianproject/LUKS)
Luksunlock (https://github.com/guardianproject/luksunlock)
Yaffsunlock (https://github.com/scintill/yaffsunlock)


== Was macht dieser Patch? ==
Zunächst einmal erweitert der Patch CM7 um folgende Bestandteile:
- das cryptsetup binary (von GuardianProject/LUKS)
- Kernel-Module für jbd2 und ext4 (aus Quarx2k's Custom Kernel für CM10)
- angepasstes init.rc aus Cyanogenmod 7.2-stable (Achtung: existierendes init.rc wird ersetzt!)
- (temporär) mitgelieferter Beispielschlüssel für die Verschlüsselung

Nach der Installation des Patches wird die existierende Datenpartition beim Bootvorgang ignoriert und nicht mehr eingehängt! Stattdessen wird eine verschlüsselte Datenpartition auf der SD-Karte genutzt!


== Status ==
Der Patch befindet sich momentan noch in der Entwicklung. Die aktuelle Version 0.1 soll nur einen Vorgeschmack auf die noch kommende Funktionalität bieten. Er bietet im Moment keinen großen Sicherheitsgewinn (siehe TODOs). Die Geschwindigkeitseinbußen sind erträglich und treten vor allem beim Schreiben auf den internen Speicher auf - die Lesegeschwindigkeit ist nur wenig betroffen. Siehe dazu auch die beigefügten Benchmarks.


== Voraussetzungen ==
- Grundlagenwissen über LUKS
- gerootetes Defy mit CWM und CM7.2-stable
- mSD-Karte im Defy


== Installation ==
1. Schritt: Schlüssel für die spätere Verschlüsselung erzeugen:

dd if=/dev/random of=lukskey bs=1 count=32

2. Schritt: SD-Karte extern (oder über CWM) neu partitionieren. Im folgenden gehe ich davon aus, dass die SD-Karte als Gerät "/dev/sdb" verfügbar ist. Sie sollte nun wie folgt umpartitioniert werden:

/dev/sdb1: das bisherige FAT32 (ggf. existierende Partition verkleinern)
/dev/sdb2: eine neue Partition vom Typ Linux (82)

3. Schritt: Zweite Partition der SD-Karte mit dem zuvor erstellten Schlüssel verschlüsseln (unter Linux):

cryptsetup -c cipher=aes-cbc-plain luksFormat /dev/sdb2 /path/to/lukskey

4. Schritt: Partition einhängen und ext4-Dateisystem auf verschlüsselter Partition erzeugen:

cryptsetup --key-file /path/to/lukskey luksOpen /dev/sdb2 encrypteddata
mkfs.ext4 /dev/mapper/encrypteddata
cryptsetup luksClose /dev/mapper/encrapteddata

5. Schritt: Schlüsseldatei system/etc/lukskey im Archiv defyluks.zip ersetzen (Archiv entpacken, Schlüssel ersetzen, Archiv wieder zusammenpacken)

6. Schritt: Das neu zusammengepackte defyluks.zip via CWM installieren und das Defy booten.


== Versionshistorie ==
0.1 (02.12.2012): First pre-release


== Ausblick / TODO (geordnet nach Priorität) ==
- Eingehängte Datenpartition beim Herunterfahren aushängen, um Datenverluste zu vermeiden
- Schlüsseleingabe über minui ermöglichen (der hart verdrahtete Schlüssel bietet keine echte Sicherheit. Es sei denn, einem wird nur die SD-Karte ohne das Gerät gestohlen oder z.B. der Touchscreen geht kaputt und man möchte das Gerät ohne seine Daten zur Reparatur einschicken)
- Loopback-Devices auf existierender SD-Karte (ohne Umpartitionierung) unterstützen
- Anderen Cipher als aes-cbc-essiv unterstützen (Modul fehlt leider in Defy Stock-Kernel)
- Installation vereinfachen (Setup-GUI ähnlich LuksApp)
- Dokumentation verbessern (Handbuch...)
- Speicherung des Images optional auch im internen Flash unterstützen (ich sehe hier zwar einige Nachteile, aber okay)
- Andere Dateisysteme, evtl. auch yaffs2 unterstützen (yaffs2 macht auf der SD-Karte wenig Sinn, im internen Flash hingegen schon)
- Verschlüsselung der SD-Karte (mnt/sdcard/*) unterstützen
- Weitere Defy-ROMs unterstützen
- Vorkompilierte Binaries durch selbst übersetzte Binaries ersetzen
- Aktuell im Einsatz befindliches Pfusch-Skript durch anständiges Build-System ersetzen
- Mehr Werbung für das Projekt machen (GitHub-Seite etc.)
- Andere Geräte mit Android 2.3 unterstützen
- Bootvorgang beim ersten Start beschleunigen (erster Boot dauert über 3 Minuten)

Feedback ist willkommen! Wenn mich jemand bei der weiteren Entwicklung unterstützen möchte bitte ich um eine kurze PM.

 

[Johan]

Da hänge ich mich mal ran:

Auf meinem E90 (Symbian) konnte man die SD-Karte über eine PIN (oder Passwort) sperren (die Daten wurden dabei nicht verschlüsselt), so dass sie nur auf meinem E90 gelesen werden konnte (habe ich schmerzlich festgestellt, als der E90 mal zur Reparatur war, und ich die SD-Karte in meinem PC auslesen wollte), bzw. wenn man die PIN eingab (was aber Windows XP anscheinend nicht unterstützt, habe zumindest nichts gefunden).

Das ist meines Wissens ein Feature des SD-Card-Standards und würde wohl bei den meisten völlig ausreichen (Verschlüsselung ist IMO nur bei hochsicherheitskritischen Sachen notwendig). Gibt es da irgendwelche Apps oder Erweiterungen, die das unter Android unterstützen?

 

[Defier]

Zu dem von dir angesprochenen Feature des SD-Karten-Standards kann ich leider nichts finden. Wenn du einen Link hast wo das beschrieben ist - gerne, würde mich interessieren!

Für mich sieht es allerdings eher danach aus, als wäre die "Sicherheit" dieses Sperr-Features beim N90 so implementiert worden, dass das Dateisystem einfach korrumpiert wird wodurch es nicht ohne weiteres automatisch am PC erkannt werden kann. Sowas lässt sich aber relativ leicht umgehen:

NokiaPort.de - Forum - Speicherkarte/microSD Passwort vergessen

Angenommen dem wäre nicht so und dieses Feature wäre wirklich halbwegs sicher (vergleichbar etwa mit einem Festplattenpasswort nach ATA-Standard, der sich afaik nicht rein softwareseitig aushebeln lässt), dann würde es dir nur etwas bringen, wenn du deine Datenpartition auf die SD-Karte verfrachten würdest - so wie das defyluks derzeit schon tut. Von Fotos abgesehen legen die persönlichen Daten, die man üblicherweise schützen möchte (Kontakte, SMS, Anruflisten...) ja standardmässig auf der Datenpartition, und die befindet sich im internen MTD-Flash.

Es wäre aber vielleicht durchaus ein interessanter Patch, wenn man (z.B. aus Performancegründen) auf die Verschlüsselung verzichten könnte und die Daten einfach nur in einen Container oder eine extra Partition auf die SD-Karte verfrachten würde. Wenn sowas gewünscht wird kann ich das gerne realisieren.

 

[Johan]

Ich werde das, sobald ich Zeit finde, mit dem in dem von Dir angegebenen Link genannten PC-Programm mal testen, nachdem ich im E90 die SD-Card mit Passwort geschützt habe.

 

[Johan]

So, habe es jetzt mit dem Programm PCI File Recovery (PC Inspector kostenlos) getestet.

Im Windows Explorer wird die Karte als Laufwerk D: angezeigt. Klickt man es an,
dauert es einige Zeit, dann kommt die Fehlermeldung:

Legen Sie einen Datenträger in Laufwerk D: ein.

Wenn ich in File Recovery so vorgehe, wie in dem von Dir verlinkten Thread, Beitrag 19, vorgehe, wird mir das logische Laufwerk D: aber erst gar nicht angezeigt, habe es mehrmals suchen lassen.

Gehe ich in FR auf "Informationen" "System" wird zwar D: angezeigt, aber keinerlei Informationen dazu.

Also so einfach lässt sich der Passwort-Schutz für die SD-Karte nicht aushebeln. Der Autor hatte auch ein Nokia C02. Der Commi ist aber ein E-Series Gerät, d. h. für Business-Anwendungen. Die hatten teilweise deutlich höhere Sicherheitsstandards (z. B. auch Remote sperren serienmäßig).

Falls Du Interesse haben solltest, könnte ich mir ja mal eine kleine SD-Karte mit 2 oder 4 GByte kaufen, bischen was draufspielen, mit Passwort sperren und Dir zusenden. Dann kannst Du selbst mal probieren, ich bin nicht der File-System-Spezialist.

 

[Defier]

Gerne - ich kann dir auch einfach eine leere Karte zuschicken, du bespielst sie mit irgendwas und schickst sie mir zurück. Oder wir finden gleich irgendwo im Netz ein paar Infos über diese Sicherheitsfunktion, wer weiss - vielleicht verschlüsselt der Communicator die Inhalte ja auch?

 

[Johan]

Ich gucke erst mal, ob ich irgendwo eine günstige auftreiben kann. An Verschlüsselung glaube ich eher nicht, das müsste ja einige Zeit dauern, nachdem man ein Passwort eingegeben hat(?), der Commi ist aber sofort wieder bereit zur Eingabe.

 

[Defier]

Mit "dauern" meinst du die Zeit für die Aktivierung der Verschlüsselung oder für das Speichern einer Datei? Normalerweise gibt es bei transparent arbeitetenden Verschlüsselungen kaum einen (spürbaren) Impact...

 

[Johan]

Ersteres, d. h. ich setze ein Passwort, dann muss er ja, falls er die Dateien verschlüsseln sollte, alle Dateien verschlüsseln, was sicher einige Zeit in Anspruch nehmen dürfte.

BTW: Karte habe ich mittlerweile besorgt, muss ich jetzt noch was drauf spielen.

 

[Defier]

Okay. Das heisst aber, du kannst das Passwort auch setzen, obwohl schon Daten drauf sind? In dem Fall wird es sicherlich keine Verschlüsselung sein, die da zum Zug kommt...

 

[Defier]

Johan hat mir freundlicherweise seine SD-Karte geschickt und ich habe mir die Sache mal angesehen. Der Schutz scheint tatsächlich gar nicht so schlecht zu sein: Beim Einstecken der Karte kommt folgende Fehlermeldung:

mmc0: error -110 whilst initialising SD card

Ich habe mit verschiedenen Parametern für das Modul sdhci-pci und sdhci rumgespielt, bislang kriege ich die Karte aber nicht erkannt. Ich vermutete zunächst, dass Nokia irgendwas in den Controller der Karte reinschreibt was dafür sorgt, dass gängige SD-Kartentreiber die Karte nicht erkennen wollen. Nach einiger Recherce fand ich aber die Antwort in der SD-Karten-Spezifikation:
https://www.sdcard.org/downloads/pl...ified_Specification_Ver_3.01_Final_100518.pdf

Dort wird auf die CPRM-Spezifikation verwiesen, über die sich eine kleine vereinfachte Erklärung hier finden lässt:

http://www.mrkehm.com/pages/4c/docs/How CPRM Works.pdf

Die SD-Karte wird also tatsächlich mit einem 56bit-Schlüssel verschlüsselt und dürfte damit recht sicher sein. Natürlich ist das Verfahren nicht mehr ganz modern und vermutlich wird jemand der es darauf anlegt einen so schwachen Schlüssel auch knacken können, der Aufwand dafür ist jedoch schon beträchtlich (es sei denn es gibt ein Tool, das ich noch nicht kenne).

Leider scheint die Spezifikation dafür geheim zu sein (bzw. man muss dafür zählen), sonst wäre vermutlich im SDHCI-Treiber für Linux die Sache implementiert und man könnte SD-Karten ähnlich einfach une ohne Performance-Einbußen oder Eingriffe ins Init schützen wie (S)ATA-Laufwerke.

 

[Johan]

Hallo Defier, frohe Weihnachten!

Das heißt also, dass wir (weil kommerziell) den Schutz von den Nokia E-Series-Geräten (Verschlüsselung) nicht für Android einbauen können?

 

[Defier]

Jep, so sieht es wohl aus. Wenn man den Schutz einbauen wöllte müsste man viel tiefer ansetzen und schon das SD-Karten-Modul für den Linux-Kernel anpassen. Wenn die Spezifikationen dafür frei wären, hätte das wahrscheinlich eh schon jemand gemacht und das somit für alle Linux-tauglichen Geräte umgesetzt.