Standardkonfiguration von EncFs und Volume-Key¶

Quelle: Wikipedia: EncFS

"[...] Verschlüsselt werden die Daten dabei mit einem großen, in einer Datei vorliegenden Schlüssel, dem sogenannten Volume-Key. Dieser ist nochmals mit einem Passwort geschützt, um Entschlüsselung bei Kenntnis des Volume-Keys zu verhindern. [...]"

1
2
3
4
5

.Data_EncFS/                  <- Basisverzeichnis
├── kadfZkkad8435hölkqehlh,a  <- verschlüsselte Dateien und Ordner
├── jfajds4lkfasHmd9asdfsasd
├── [...]
└── .encfs6.xml               <- volume-key hier

Hat ein Angreifer Zugriff auf diese Daten, benötigt er zur Entschlüsselung des Verzeichnisses nur das Benutzerpasswort um an die Daten zu gelangen. Software um Passwörter zu entschlüsseln leistet heute enormes. Eine Entzifferung ist für einen Angreifer nur eine Frage der Zeit.

Und genau hier liegt die Chance für den Angreifer. Das Web bietet ihm einen ständigen Zugang, er kann automatisiert und in aller Ruhe den Server angreifen, dann die encfs6.xml auslesen und entschlüsseln.

Das Problem dabei ist: In der Regel bleiben die Daten zur Verschlüsselung der Daten auf dem Server über lange Zeit unverändert bestehen:

• Den Schlüssel (Volume-Key) bleibt für die gesamte Laufzeit des Verzeichnisses erhalten und kann nicht geändert werden 🇬🇧!

• Wer verwendet wirklich ein starkes, zufallsgeneriertes Passwort und verwendet ausschließlich (Passwortgenerator- und -manager wie KeePassXC oder pwgen)?

• Wer ändert die Passwörter regelmäßig?

Kryptographische Aspekte des Volume-Key¶

Die zentrale und einzige Konfigurationsdatei für ein EncFs-Dateisystem ist eine XML-Datei. Sie enthält alle wichtigen Konfigurationsdaten, darunter zwei kryptografisch wichtige Sequenzen, die zur Entschlüsselung benötigt werden:

1. Der Volume-Key - ein privater Schlüssel, welcher durch ein Kennwort verschleiert ist.

1
2
3

<encodedKeyData>
  fd7as87dffaldfkahdflkahfdsölkfadsfad8fßa09d8f0WFlSd2m6gfk43682435j432hhsjwfbK9INfz27adf==
</encodedKeyData>

2. Der Salt - ein zusätzlicher Schlüssel, um die allgemeine Sicherheit gegenüber Entschlüsselungsalgorithmen zu erhöhen.

1
2
3

<saltData>
LwYW6nBVtDj/wv+2jlmyS3TZ5LA=
</saltData>

Warum ist dies kritisch?:

Die Konfigurationsdaten zur Verschlüsselung sowie der private Schlüssel sollten normalerweise getrennt aufbewahrt werden. In der Regel ist sogar eine physikalische Trennung und Speicherung auf einem externen Datenträger oder zumindest an einem besonders geschützten Ort sinnvoll - z. B. ein separates, verschlüsseltes Verzeichnis.

Ein einfaches Beispiel um den Sachverhalt zu verstehen: Die Karte enthält den elektronischen Schlüssel, dieser ist nur durch ein Passwort geschützt (die PIN in diesem Fall). Kein Mensch würde seine EC-Karte offen irgendwo hinlegen.

Die Standardkonfiguration von EncFs sieht folgendes vor: Der Schlüssel und die verschlüsselten Daten werden zusammen in ein Verzeichnis gelegt. Ein potentieller Angreifer kann nach erfolgreichem Knacken des Passwortes die privaten Daten des Nutzers in aller Ruhe auslesen, ohne dass dieser etwas davon mitbekommt. Da die meisten Anwender weder ihr Owncloud-Zuganspasswort noch das Passwort des EncFs-Verzeichnisses regelmäßig ändern, stehen die Benutzerdaten in der Owncloud für einen Angreifer wahrscheinlich für sehr lange Zeit wie ein Scheunentor offen.

Bei derzeit rasant steigender Nutzung von Cloud-Systemen ist die Wahrscheinlichkeit hoch, dass Angreifer potentielle Sicherheitslücken in Systemen angreifen, um an Nutzerdaten zu gelangen. Dies trifft insbesondere auf einfach zu verwendende Systeme wie Dropbox 🇬🇧 oder im privaten Serverumfeld leicht aufzusetzende wie Owncloud 🇬🇧 zu. Die Hürde in Sachen Sicherheit kann man also nicht hoch genug legen.

Sicherstellen, dass der Volume-Key nicht in der Cloud landet¶

Da in der Regel beim Anlegen eines EncFs-Verzeichnisses im Cloud-Ordner der Volume-Key standardmäßig gleich mit erstellt und im Datenverzeichnis abgelegt wird, würde dieser sofort in die Cloud synchronisiert (und versioniert!).

Daher sollte man das EncFS-Verzeichnis erst einmal lokal anlegen und dann den Volume-Key an einen anderen Ort verschieben. Danach kann man das EncFs-Datenverzeichnis - ohne Volume-Key - in die Cloud verschieben.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

mkdir -p ~/Mein_EncFs_01                            # Mountpunkt für EncFs
mkdir -p ~/.Mein_EncFs_01_Crypt                     # Wurzelverzeichnis für EncFs
mkdir -p ~/.Meine_EncFs_Schluessel                  # Hier kommt der Volume-Key hinein

encfs ~/.Mein_EncFs_01_Crypt ${HOME}/Mein_EncFs_01    # Erstellen des Volume-Key

# Verschieben des Volume-Key in ein lokales Verzeichnis ...
mv  ~/.Mein_EncFs_01_Crypt/.encfs6.xml \
    ~/.Meine_EncFs_Schluessel/Mein_EncFs_01_Volume-Key.xml

# ... und des Wurzelverzeichnisses in die Cloud
mv ~/.Mein_EncFs_01_Crypt ~/OwnCloud

Einstellungen im Client der Cloudsoftware¶

Man sollte sicherheitshalber den Dateinamen .encfs6.xml von der Synchronisation ausschließen.

Das geht so:

Owncloud: In den Owncloud Einstellungen kann eine Ignorierliste bearbeitet werden (siehe Abbildung rechts).

Dropbox: Hier lässt sich dies meiner Kenntnis derzeit noch nicht realisieren (das könnte aber noch kommen). Abhilfe schafft die unten beschriebene Methode unter Verwendung eines symbolischen Links.

Symbolische Links werden weder in der OwnCloud noch in der Dropbox synchronisiert. Daher ist dies auch auch die empfohlene Methode um EncFs "mitzuteilen", wo sich der VolumeKey befindet.

Sicheres Zufallspasswort und hohe Verschlüsselungsstufe verwenden¶

Da bei Zugriff auf das verschlüsselte Verzeichnis ein starkes Passwort wichtig ist, sollte man zur Erstellung einen Passwortgenerator- und -manager wie KeePassX verwenden.

Das Passwort kann mit dem Werkzeug encfsctl geändert werden.

1

encfsctl passwd Wurzelverzeichnis

Die Daten sollten mit der Option paranoia verschlüsselt werden (256 bit AES).

Externen Volume-Key einbinden¶

EncFS muss beim Aktivieren ("mount") wissen, wo sich das Wurzelverzeichnis und das Zugriffsverzeichnis (Mountpunkt) befinden (Quelle: Manpage von encfs):

1

encfs WURZELVERZEICHNIS MOUNTPUNKT

Der Volume-Key wird von EncFs standardmäßig als .encfx6.xml bezeichnet und im Datenverzeichnis gespeichert.

Es gibt zwei Möglichkeiten, um einen externen Volume-Key beim Aktivieren ("mount") einzubinden:

1. im Datenverzeichnis wird ein symbolischer Link zum Volume-Key erstellt (empfohlene Methode)

2. beim Mounten gibt man den Ort des Volume-Key über eine Umgebungsvariable mit an

1.: Um einen symbolischen Link zu erstellen, geht man folgendermaßen vor:

cd ~/OwnCloud/.Mein_EncFs_01_Crypt
ln -s ~/Meine_Schluessel/Mein_EncFs_01_Volume-Key.xml ~/OwnCloud/.Mein_EncFs_01_Crypt/.encfs6.xml

# Jetzt kann ganz normal gemounted werden:
encfs ~/OwnCloud/.Mein_EncFs_01_Crypt ${HOME}/Mein_EncFs_01

2.: Um den Ort für den Volume-Key direkt beim Aktivieren an EncFS zu übergeben, kann die Umgebungsvariable ENCFS6_CONFIG gesetzt werden. Der Pfad zur Datei muss relativ (!) zum Datenverzeichnis angegeben werden. Der Volume-Key wird in unserem Beispiel folgendermaßen referenziert:

ENCFS6_CONFIG=../Meine_Schluessel/Mein_EncFs_01_Volume-Key.xml; encfs ~/.Mein_EncFs_01_Crypt ~/Mein_EncFs_01

Zusätzliche Sicherheitsmaßnahmen¶

Volume-Key wurde versehentlich in die Cloud synchronisiert¶

Hier gibt es leider nur die Möglichkeit, auf dem Server im Verzeichnis /owncloud/data/USERNAME/files_versions nach der Datei zu suchen und diese zu löschen.

Ab Owncloud Version 8.2 wird das Löschen von Versionen mit dem Dienstprogramm occ unterstützt:

• lies u.a. Github: #9652 - trashbin/version cleanup occ command

Unter Dropbox ist mir keine Möglichkeit bekannt.

Mein Volume-Key wurde kompromittiert¶

Der erstellte Volume-Key kann für die gesamte Laufzeit des EncFs-Verzeichnisses nicht mehr geändert werden! Es muss ein neues EncFs-Verzeichnis erstellt, und die Daten mpüssen dort hineinkopiert werden.