NEWS / BLOG auf DICKE-AERSCHE.DE

UK-Flag Click here to access my english BLOG US-Flag

Anzeige:
blog.dicke-aersche.de in 2D-QR-Barcode T-Shirt Shop von Dicke-Aersche.de blog.dicke-aersche.de in 2D-QR-Barcode



search 2013 adfgs

Nein, auch wenn der Titel es suggerieren mag, hier geht es nicht um einen Spanischen Robert, der die Cloud liebt und auch nicht um General Aldo, der aber mit seiner Aufforderung Recht hat…

Wie passend, vor gut einem Jahr versuchte ich aufzuzeigen, wie man sich Cloud-Systeme zu Nutze machen kann. Besonders, was Datenablage & Verschlüsselung betrifft. Nun hat der Cloud-Wahn natürlich nicht abgenommen, was irgendwie zu erwarten war, wenn Dinge gehyped werden.

Was mich massiv nervt, ist, daß die einzelnen Dienste einem heftig Steine in den Weg werfen, um den Nutzer in ihre Apps einzulullen um so natürlich Verschlüsselung auf Client- (also Nutzer-) Seite aus zu verhindern. Bisher gab es HiDrive von Strato und diverse andere Dienste (z.B. adrive.com oder sogar SkyDrive von Microsoft bis hin zur Amazon-Cloud) auf WebDAV-Basis. Wenn man
übrigens bei Strato löhnt, kriegt man auch SSHFS/CIFS-Anbindung (was wiederum zu meinem oben erwähnten Beitrag vom letzten Jahr führt). Aber das scheint eine krasse Ausnahme zu sein. Die meisten Dienste bieten WebDAV an, was nicht so simpel mit Client-seitiger Verschlüsselung betreibbar ist oder auch schlimmer: mit eigenem Client bzw. neumodisch gesagt, mit einer “App”. Der Client ist nämlich oft proprietär und deshalb gerade aus Linuxer-Sicht bäh. DARUM sollten sich die Datenschützer mal kümmern, das wäre produktiver als rechtlich die Wand anzubellen, ohne daß was passiert. Der Nutzer sollte die volle Kontrolle über seine Daten behalten können!

Aber es gibt auch Ausnahmen, die einem das Leben einfacher machen. DropBox z.B. Dieser Dienst bietet von Haus aus 2 GB Platz an mit der Möglichkeit über einen automatischen Filesync-Dienst Daten automatisch in die heiligen Hallen der Firma DropBox zu übertragen. Das ist insofern gut, weil dieser Client ohne Web auskommt, er bindet das DropBox-Filesystem in dem jeweiligen Filesystem meines Rechners transparent ein. Schreibt man hinter diesen Mount-Point Daten, dann werden diese automatisch in Richtung DropBox geschrieben (eben gesynced oder wie immer man das neudeutsch schreibt, vielleicht sollte ich “synchronisiert” sagen, aber das klingt auch Scheiße). So, nun sind die Daten noch nicht verschlüsselt, d.h., eine private Text-Datei oder ein paar private Daten rübersyncen bedeutet zwar nicht, daß sie jeder gleich sehen kann. Denn auch DropBox gibt erstmal nichts nach außen frei, wie andere Cloud-Dienste ja auch. Dazu müßte man ansagen, daß der Folder, in den die Daten wandern, public ist. Nichtsdestotrotz können DropBox und seine Angestellten natürlich die Daten einsehen. Offiziell sagen sie zwar, daß sie sowas nie tun würden, aber es gibt natürlich Szenarien, wo sie das selbst gar nicht verneinen dürften, z.B. bei polizeilichen Ermittlungen oder falls jemand permanent auf die Disk schreibt und somit Kollateralschäden verursacht usw. Und natürlich gibt es noch den Datenklau. Jemand bricht bei DropBox ein und sammelt alles zusammen, was er braucht. Ist wirklich kein theoretisches Szenario, wenn man alleine liest, wie oft großen Firmen wie Sony & Co. oder auch großen Behörden riesige private Daten ihrer Kunden/Nutzer/Bürger abhanden kommen, die dann frei im Netz rumgondeln.

Ergo: die clientseitige Verschlüsselung, bei der die Verschlüsselung auf der Nutzer-Seite geschieht (verschlüsselt wird beim Nutzer und der PC überträgt nur noch verschlüsselte Daten in Richtung Clound-Provider), ist ein absolutes Muß! Da hilft auch nicht, daß Provider eigene Verschlüsselung anbieten, diese wäre gegenüber obigen Szenarien nutzlos. Und siehe da, auf Linux-Seite gibt es 2 Möglichkeiten, Dateibäume zu verschlüsseln. Einmal das im Userland arbeitende Tool encfs und einmal das Toolkit ecryptfs, welches tiefer im Kernel ansetzt.

Fangen wir also an mit encfs. Vorraussetzung ist, daß wir ein laufendes DropBox-System haben, welches z.B. unter $HOME/DropBox seinen Verzeichnisbaum aufmacht. Alles, was ich nach $HOME/DropBox kopiere, wird automatisch auf DropBox-Cloud-Server kopiert/synchronisiert. Auch, wenn ich dort etwas lösche, wird es auf DropBox-Seite gelöscht. Nun erzeugen wir dort ein Unterverzeichnis namens crypted:

mkdir $HOME/DropBox/crypted

Wichtig wäre jetzt, den DropBox-Sync zur Sicherheit auszuschalten, das macht man, indem man mit der rechten Maustaste auf das DropBox-Icon geht und “Synchronisation pausieren” anklickt. Das ist eigentlich erst einmal nur zur Sicherheit. encfs benötigt nämlich eine Key-Datei, die normalerweise im verschlüsselten Verzeichnis erzeugt wird (bis heute ist mir schleierhaft, wie man auf so eine blöde Idee kommen kann). Um es noch sicherer zu machen, daß diese bestimmte Datei auf keinen Fall in Richtung DropBox synchronisiert wird, muß man sie excluden. Da sie einen bestimmten Namen hat, ist das einfach, in unserem Beispiel wäre das so:

dropbox exclude add $HOME/DropBox/crypted/.encfs6.xml

Das kann man auch schon eingeben, obwohl die Datei noch gar nicht vorhanden ist. Nun erzeugt man die nötigen encfs-Daten, zuerst wird ein Verzeichnis erstellt, in dem die Daten immer unverschlüsselt liegen, wenn encfs aktiv ist (ist es nicht aktiv, ist dieser Ordner leer):

mkdir $HOME/DropUnCrypt

Nun erzeugen wir den Key und damit den Zusammenhang zwischen den beiden Verzeichnissen $HOME/DropBox/crypted und $HOME/DropUnCrypt. Man beachte, daß $HOME/DropUnCrypt außerhalb des DropBox-Trees liegen muß!

encfs $HOME/DropBox/crypted $HOME/DropUnCrypt

Um etwas bessere Verschlüsselung zu haben, sollte man nun den Paranoia-Mode wählen (p drücken). Nun verlangt encfs eine Key-Eingabe. Der Key sollte nicht länger als 500 Bytes sein, was aber wohl nur mittels Maus-Cut-And-Paste geht. Kürzere Paßworte dagegen werden deutlich schwächer sein, aber das muß jeder für sich entscheiden. Nach der Wiederholung des Paßwortes ist das Verzeichnis eingehängt, die Datei $HOME/DropBox/crypted/.encfs6.xml erzeugt und nun kann man den Sync von Dropbox wieder anwerfen. Nimmt man das Web-Interface, sollte der Ordner “crypted” auf DropBox-Seite leer bleiben. Also die Datei .encfs6.xml darf dort nicht auftauchen! Kopiert man nun ein Bild in das Verzeichnis $HOME/DropUnCrypt, dann wird es verschlüsselt in das Verzeichnis $HOME/DropBox/crypted kopiert, welches dann in Richtung DropBox synchronisiert wird. Der Dateiname sieht dann ungefähr so aus:

hoJhGFskT0BokLBDrqhGsxEbUzi50j,CuklU65R5k,bzhkRbnIdKENGfjaqG3LLmXjKe7KZi3COTL-IdyeXiKNGvG

Man kann die Datei auch in verschlüsselter Form ansehen. Macht man ein “less” darauf, bekommt man nur wirre Zeichen, aber daß das ein Bild ist und welches Format das Bild hat, das ist nicht mehr erkennbar. Theoretisch kann man Dateibäume dieser Art sogar komplett öffentlich kennzeichnen, es dürfte recht schwierig sein, wenn man ein gutes Paßwort hat (ich würde mal sagen >= 50 Zeichen), dieses zu knacken. Natürlich bleiben einem Angreifer Hinweise im Gegensatz zur vollständigen Verschlüsselung ganzer Partitionen. Hier kann man die Größe der Datei sehen, durch Gruppierung von Ordnern könnte man Zusammenhänge zwischen Dateien sehen uvm. Aber all das sind erstmal semantische Auswertungen, die gar nicht so simpel automatisierbar sind, da müßte man relativ viel Gehirnschmalz investieren, um hier vorwärts zu kommen.

Zu guter Letzt: wie schmeißt man das Verzeichnis aus seinem Dateibaum? So:

fusermount -u $HOME/DropUnCrypt

Nun noch das DropBox-Tool stoppen und auch der Kontakt zum DropBox-Server ist damit weg. $HOME/DropUnCrypt ist nun leer, aber in $HOME/DropBox/crypted liegen die verschlüsselten Daten noch, denn DropBox synchronisiert ja nur, d.h., Daten werden immer kopiert, aber nicht verschoben. Übrigens, wem das mit der Key-Datei immer noch zu heikel ist (z.B. könnte durch einen DropBox-Fehler die Datei trotzdem synchronisiert werden), der kann diese Datei auch woanders hinlegen und mittels Environment-Variable ansagen, wo sie liegt:

mkdir $HOME/.encfs
mv $HOME/DropBox/crypted/.encfs6.xml $HOME/.encfs
ENCFS6_CONFIG=”$HOME/.encfs/.encfs6.xml” encfs $HOME/DropBox/crypted $HOME/DropboxUnCrypt

Übrigens wird nun nicht mehr nach Paranoia-Mode gefragt, sondern nur noch nach der Passphrase, die man bei der Erstellung des Key-Files benutzt hat. Gibt man diese ein, ist die Verbindung zwischen beiden Verzeichnissen wieder da (die Verschlüsselung geht übrigens lokal natürlich auch ohne DropBox, DropBox leistet lediglich den Cloud-Sync).

Das zweite System, das etwas performanter sein soll (Kernel-Mode statt User-Mode, immer schneller), ist ecryptfs. ecryptfs ist komplizierter im Aufbau, weil es mehr Möglichkeiten hat. Interessanterweise bringt es aber Tools mit, die seine Handhabung extrem einfacher machen als encfs. Allerdings ist man ein bißchen eingeschränkt, was die Namen der Platzhalter betrifft, wenn man sich’s einfach machen will. Das Tool

ecryptfs-setup-private

macht hier den Anfang, mit diesem Tool kann man ohne große Parameter 2 Verzeichnisse erzeugen:

$HOME/Private und
$HOME/.Private

Letzteres ist dabei das verschlüsselte Verzeichnis. Schlüssellängen sind hier bei 64 Zeichen begrenzt, die sollte man schon nutzen. Ich empfehle, auch noch den Parameter “-w” zu setzen, dann hat man zwar praktisch 2 Paßworte, eins, um den Schlüssel zu verschlüssel und den Schlüssel selbst, aber man ist unabhängig von der UserID und dem lokalen Paßwort, welches sonst automatisch als Key-Wrap-Passphrase benutzt würde. In einem anderen Blog hatte ich einen netten Trick gefunden, nämlich nun einfach einen symbolischen Link in Richtung DropBox zu erzeugen:

ln -s $HOME/.Private $HOME/DropBox/ecrypted

Nun kann man das System einhängen:

ecryptfs-mount-private

Natürlich wird man nach der wrapping-Passphrase gefragt und nach Eingabe sind die Verzeichnisse $HOME/Private (unverschlüsselt) und $HOME/.Private (verschlüsselt) miteinander verbunden. Wenn nun die DropBox läuft, wird alles, was in $HOME/.Private liegt, automatisch synchronisiert. Auch hier sind normalerweise die Dateinamen unkenntlich, z.B. so:

ECRYPTFS_FNEK_ENCRYPTED.FWZIVNhmTC77m-SSa424JjELgAPvo8lj.YkH8fNguSFYc0NfT6v4u4KZck–

Hier sieht man allerdings deutlicher, welches Tool die Datei erzeugt hat. Gerade auf Reisen könnte man sich bei encfs irgendwie rausreden (“Die Dateien macht irgendein Programm”), während das hier bestimmt nicht so einfach wäre.

Zum Entkoppeln gibt man ecryptfs-umount-private ein und die verschlüsselten Daten sind nicht mehr unverschlüsselt einsehbar. Der Vorteil, neben Speed, ist hier die Key-Datei, die unter $HOME/.ecryptfs/ abgelegt wird, man muß sich um einen versehentlichen Sync auf “die böse Seite” keinen Kopf machen. Als Nachteil wirkt neben der offensichtlichen Ansage, daß hier ecryptfs im Spiel ist, daß man nun bei allen möglichen Tools nach der wrapping-passphrase gefragt wird. Das passiert deshalb, weil ecryptfs das z.B. auch für das Home-Verzeichnis leisten kann und darauf einen auto-mount machen kann, es hat sich dafür unter /etc/pam.d in diversen Config-Files verewigt. Wem das nicht gefällt, der löscht einfach diese Dateien:

rm $HOME/.ecryptfs/auto-mount $HOME/.ecryptfs/auto-umount

Und schon nervt bei sudo oder dem screensaver keine zusätzliche Abfrage mehr.

Fazit: mein Favorit bleiben die Partitionen-Vollverschlüsselungen, denn hier kann man keinerlei Aussagen über die Struktur der verschlüsselten Daten machen. Zwischen encfs & ecryptfs tendiere ich, trotz der ofensichtlichen Dateinamensherkunft zu ecryptfs. Es ist performanter, einfacher bedienbar und hat auch durch mehr Möglichkeiten, wie z.B. Public/Private-Key-Verschlüsselung, die Nase vorn. Da ecryptfs aber mehr so ein Linux-Kernel-Ding ist, dürfte für Mac- und Windows-Nutzer encfs die bessere Wahl sein. Aber das müssen andere beurteilen.

Ähnliches soll übrigens auch für UbuntuOne, dem Cloud-Dienst von Ubuntu-Systemen machbar sein. Angesichts der Tatsache, daß ich da bisher keinen Account habe, sollte jemand anders den Test machen, wobei es viele Artikel in Blogs gibt, die das ganz gut beschreiben. Nun bräuchten wir so eine Beschreibung nur noch für Google-Drive, HiDrive von Strato, SkyDrive von Microsoft undundund…:)

Kommentar schreiben


vier − = 2

Kategorien

Archiv

Oktober 2017
M D M D F S S
« Jun    
 1
2345678
9101112131415
16171819202122
23242526272829
3031  
-->


Blog-Seiten aufgerufen seit 9. Januar 2006:
digit digit digit digit digit digit digit digit
  Impressum