Script: Verschlüsselten Ordner via Keyfile (.key) entschlüsseln

[steve02]

Ok, ich habs mit Google gefunden. Um aus dem Keyfile die selbst gewählte Passphrase auszulesen benötigt man das Standardpasswort. Der Befehl dazu sieht dann so aus:

printf "%s" "[FONT=&quot]\$1\<MY_PASSOWRD>[/FONT]" | ecryptfs-unwrap-passphrase keyfile.key -

Oder so:

ecryptfs-unwrap-passphrase keyfile.key "\$1\<MY_PASSOWRD>"

Getestet mit DSM 6.2 sowie unter Ubuntu 18.04.2 mit ecryptfs-utils. Ich hoffe das erspart anderen die lange Suche. Ich verstehe nicht warum das hier nicht schon viel früher gepostet wurde.

 

[peterhoffmann]

Ich verstehe nicht warum das hier nicht schon viel früher gepostet wurde.

Weil das PW verständlicherweise nicht so sehr an die Öffentlichkeit soll.

 

[steve02]

Weil das PW verständlicherweise nicht so sehr an die Öffentlichkeit soll.

Für mich ist das ehrlich gesagt überhaupt nicht verständlich. Einerseits schützt dieses Standardpasswort doch eine Datei, bei der ich ohnehin davon ausgehen muss, dass deren Besitzt mir ermöglicht meine Daten zu entschlüsseln. Und andererseits entsteht beim Einrichten der Verschlüsselung durch den automatisch gestarteten Download eben dieser Datei bei mir der Eindruck, dass ich mit dieser Datei jederzeit an meine verschlüsselten Daten komme. Wenn ich also in die Situation komme Daten von einem NAS Volume retten zu müssen ohne Zugriff auf die DSM Weboberfläche zu haben, dann wäre es doch gut wenn ich wenigstens im Internet zügig herausfinden kann, wie ich das machen kann wenn ich nur das Keyfile habe.

 

[peterhoffmann]

Das ist auch alles richtig.

Aber es macht einen Unterschied, wenn du und ein paar Leute das PW haben oder es hier öffentlich gepostet wird. Es wird ja niemanden vorenthalten, der es wirklich braucht (PN schicken).

 

[steve02]

Welchen Unterschied macht es denn? Wo ist der Nachteil, wenn dieses Passwort öffentlich im Internet bekannt wird?

 

[peterhoffmann]

Wenn du den Unterschied nicht erkennst, führt auch eine Diskussion zu keinem Ziel. Lass es uns begraben.

 

[steve02]

Naja gut, vielleicht ist die Frage nach dem Unterschied, den es macht, ob das Standardpasswort einfach oder schwierig zu bekommen ist, die falsche. Aber die Frage nach den Nachteilen eines öffentlich bekannten Standardpassworts bleibt. Ich denke hier gibt es Vor- und Nachteile. Ich habe bereits für eine allgemeine Veröffentlichung argumentiert. Was sind die Kontra-Punkte?

 

[PsychoHH]

Eventuell wird dann ein anderes genutzt und man muss es manuell per Konsole auslesen, bzw. Befehle abfangen oder es wird ein anderes Verfahren genutzt, sodass wir eventuell keine Möglichkeit haben diese Dinge per Script zu nutzen. Hab ich hier aber auch schon geschrieben. Und genau deswegen nie öffentlich gepostet.

 

[phynx]

@PsychoHH könntest Du mir bitte eine PN zusenden wie ich das Passwort aus der Keyfile auslesen kann?

 

[the_baker]

Hallo,

ich habe auch die hier beschriebene Herausforderung:

Die Diskstation muss sich selber entsperren können, solange sie nicht geklaut wurde. Dazu sollen die Keyfiles auf einem entfernten Speicher genutzt werden und nicht plain Passworte.

Wer hat mir den Tipp, wie das geht?

 

[peterhoffmann]

Auf der Konsole ist vieles möglich. Man muss es sich nur scripten, da gibt es nichts von der "Stange".

Ein paar Ideen:

• Wenn du nicht Passwörter bzw. Teile davon in Klartext übertragen willst, könntest du die Passwörter über https von einem Webserver holen (oder auch per ftps, etc.)
• Das Gleiche wäre auch mit den Keyfiles möglich.
• Denkbar wäre auch die Keyfiles in zwei Hälften zu zerschneiden und sie auf zwei verschiedenen Webservern zu lagern.
• Paranoidversion: In mehr als zwei Teile zerschneiden.
• 2. Paranoidversion: Man verschlüsselt noch mal die Teile und das Passwort dafür legt man wieder woanders ab. *aluhut-aufsetz*

Unterschied von Plain-Passwörter zu Keyfiles => keiner, da man mit dem richtigen Passwort, welches für jedermann erhältlich ist, aus dem Keyfile das Passwort auslesen kann.

 

[the_baker]

Unterschied von Plain-Passwörter zu Keyfiles => Security by obcurity. Man muss dieses Standard-Passwort erst einmal gesagt bekommen. Mir hat es bisher keiner verraten.

 

[peterhoffmann]

Security by obcurity

Nein, wenn jemand deine DS einsackt um nicht die Hardware zu bekommen, sondern an die Daten ran will, wird er auch in der Lage sein, einen Keyfile zu entschlüsseln, sprich das Passwort sich zu besorgen. Maximal verzögert es den Zugriff, verhindert ihn aber nicht.

Das Passwort findet man übrigens auf Unix-Seiten, Twitter, verschiedenen Blogs, Community von Synology, russischen Cryptoseiten, usw., usw.
Wenn ich das Passwort bei einer Suchmaschine eingebe, bekomme ich 61 Ergebnisse.

 

[hiddensurface]

Das Passwort findet man übrigens auf Unix-Seiten, Twitter, verschiedenen Blogs, Community von Synology, russischen Cryptoseiten, usw., usw.
Wenn ich das Passwort bei einer Suchmaschine eingebe, bekomme ich 61 Ergebnisse.

Stimmt, das ist ja einer der Gründe, weshalb dieses Keyfile grundsätzlich eine ziemlich schlechte Idee ist, denn es gaukelt einem Sicherheit vor, die de facto nicht existiert. Ich kann gar keinen Grund erkennen, was an dieser Funktion sinnvoll sein sollte.

Vielleicht wurde hier bei der Entwicklung ein Denkfehler begangen. Üblich bei der Festplattenverschlüsselung ist ja ein langer privater Schlüssel, mit dem alles verschlüsselt wird, der dann wiederum noch einmal mit einer Passphrase verschlüsselt auf dem Gerät abgelegt ist. So kann man seine Platte mit der Passphrase entschlüsseln, und wenn die Passphrase einmal aus irgendeinem Grund verbrannt/unsicher/öffentlich sein sollte, kann man sie ändern, ohne dass sich der private Schlüssel ändern muss (und alles neu verschlüsselt werden muss). Gleichzeitig ist die Passphrase auch sicherer, da sie nirgendwo gespeichert wird (weder verschlüsselt noch unverschlüsselt) und deshalb auch nicht extrahiert werden kann.

Stattdessen kann man sich für die Diskstation ein Keyfile exportieren und irgendwo speichern, was wahrscheinlich mehr Angriffspunkte bietet als die Passphrase die man im Kopf oder im Passwortmanager hat (wenn das Keyfile ein unerfahrener Nutzer irgendwo rumliegen lässt). Dass man zudem die Passphrase aus dem Keyfile exportieren kann (allein theoretisch) ist eine noch größere Sicherheitslücke. Wenn ein unerfahrener Nutzer seine Passphrase auch noch für etwas anderes verwendet, aber nicht genau weiß wie die beiden zusammenhängen, kann er damit unbeabsichtigt sein Passwort verbrennen.

Ich finde, diese Keyfile-Funktion sollte entweder ganz deaktiviert, oder mit einer fetten Warnung gekennzeichnet werden.

Überhaupt ist dieser ganze Verschlüsselungsstack im DSM hochproblematisch. Wenn man den Key Manager ohne externen Key Store verwendet, wird das Keyfile auf der Systempartition abgelegt. Gut denkt man sich, ist es bestimmt wie immer, und das Keyfile ist mit dem Login-Passwort verschlüsselt, damit wenigstens etwas Sicherheit da ist. Denkste! Das Keyfile ist mit einem "Unique Hardware Key" verschlüsselt, den man ebenfalls auslesen kann. Damit ist die Sicherheit gleich Null:

Quelle:
https://community.synology.com/enu/forum/1/post/131812
https://blog.elcomsoft.com/2019/11/...on-forensic-analysis-of-synology-nas-devices/

Es ist mir schleierhaft, wieso es überhaupt möglich ist, diese Methode zu wählen.

Ein Externer Key Store hat übrigens das gleiche Problem, wenn man "Mount on Boot" aktiviert hat, selbst wenn man dafür eine Passphrase vergibt.

Mindestens braucht die UI eine klare Warnung, was hier die Probleme sind. Die Dokumentation ist leider auch Unklar, was diese Sicherheitsprobleme angeht.

 

[MrFangtooth]

Habe dazu ein kleines Script geschrieben, vielleicht hilft euch das weiter.

Dabei wird ein Teil des Passworts von einer URL ausgelesen. Im Gegensatz zum Key-File ist die Datei alleine nichts Wert, ihr könnt sie einfach auf Free-Webspace hochladen. Sollte natürlich trotzdem sehr random erstellt sein. Die Entschlüsselung schlägt fehl sobald ihr die Datei einfach löscht. Meine Empfehlung ist ein kleines PHP Script, das die Datei bei Aufruf einer URL löscht oder man macht das manuell per FTP (-App).

Systemsteuerung > Aufgabenplaner > Erstellen (root, beim hochfahren)

SIMPLES BEISPIEL
Passwort: Q2Q96g47qLUzM5XDZDyR
Passwort indv. geteilt: Q2Q96g47qL + UzM5XDZDyR
Datei-URL: deineurl.de/3N7TUCmDh8gw7bEQ6f
Datei-Inhalt: "ktFwQgSIq6Z5BdcKgCOQ2Q96g47qL0smyOk4XUrgY7o4aYANNkMv72Xj2lw8VSLHRoHmSB4bJzCHkjrRHWP16xKpqTxw2zFLMo2uH6J4RPv0B6"

# Ordner zum entschlüsseln angeben
folder=(homes ordner1 ordner2 ordner3)
# Datei von URL holen
file=`curl deineurl.de/3N7TUCmDh8gw7bEQ6f`
# Passwort auslesen (Position bsp. 20-30)
password=`echo $file | cut -b20-30`
# Passwort zusammensetzen und Ordner entschlüsseln
for i in ${folder[@]}; do
/usr/syno/sbin/synoshare --enc_mount $i $password"UzM5XDZDyR"
done

 

[peterhoffmann]

Herzlich Willkommen im Forum @MrFangtooth

Angenommen, man ist im Urlaub, liegt am Strand und man hat vergessen die Datei zu löschen bzw. lässt sie online, damit bei einem Stromausfall das NAS neustarten und die Ordner mounten kann. In diesem Fall würde bei einem Diebstahl das NAS in einem anderen Netzwerk die Ordner dennoch mounten, da alle Teile vom Passwort für das NAS greifbar sind.

Passwort indv. geteilt

Hier empfehle ich die Passwortteile mindestens auf eine externe und interne Quelle zu verteilen.

Beispiel:
Teil 1 => externer Webserver (wie vorgeschlagen)
Teil 2 => Quelle im eigenen Netzwerk, z.B. NAS-Funktion der Fritzbox, Smarthome, Raspberry, etc.

In diesem Fall würde beim Diebstahl und Start vom NAS im fremden Netzwerk Teil2 vom Passwort fehlen und das Mounten fehlschlagen.

 

[MrFangtooth]

Gute Idee, lässt sich ja an einer Fritzbox ähnlich aufbauen wie die externe Datei und im Script einfach ergänzen.

 

[kev.lin]

Ich habe das jetzt mit folgendem Script aufgebaut:

#!/bin/bash
server="server"
# locations
remotepath="//192.168.nnn.nnn/share/folder"
mountpoint="/volume1/homes/user/crypt1/"
local="/volume1/homes/user/crypt2/"
# userdata
username="username"
password="password"
# mount external directory
mount -t cifs -o vers=3.0,username="$username",password="$password" "$remotepath" "$mountpoint"
# folders to decrypt
folders=(share1 share2)
for i in ${folders[@]}; do
pwremotepart1=$(<$mountpoint${server}${i}part1)
pwlocalpart2=$(<$local${server}${i}part2)
pw="$pwremotepart1$pwlocalpart2"
/usr/syno/sbin/synoshare --enc_mount $i $pw
done
# un-mount external directory
umount $mountpoint

Dieses Script wird dann im Aufgabenplaner als root-User beim Start aufgerufen.
Die Passworte für die Ordner sind dabei in 2 Teile aufgeteilt nach dem Schema:

<server><shares><part[1|2]>

Beim Herunterfahren wird ein Script aufgerufen, dass die Ordner entsprechend wieder aushängt.

 

[kev.lin]

Nach diesem guten Hinweis, hier eine Version, die ein paar mehr Kommentare enthält. Anzupassen (nach Euren Begebenheiten) sind alle Stellen, die rot hervorgehoben sind: "server", "remotepath", "mountpoint", usw.

#!/bin/bash
### Eine Variable, die den Namen des lokalen Servers (DiskStation) enthaelt
server="server"
### Adresse/Pfad des SMB-Ordners, der auf einem anderen Server liegt. Dieser Server kann im LAN oder in der Cloud sein
remotepath="//192.168.nnn.nnn/share/folder"
### Adresse/Pfad, wo "remotepath" lokal eingebunden werden soll
mountpoint="/volume1/homes/user/crypt1/"
### der Ordner, der den lokalen Teil des Passwords enthaelt
local="/volume1/homes/user/crypt2/"
### Username und Passwort fuer den Nutzer des einzubindenden Servers - SMB/CIFS-Verbindung
username="username"
password="password"
### das Share wird lokal unter "mountpoint" eingebunden
mount -t cifs -o vers=3.0,username="$username",password="$password" "$remotepath" "$mountpoint"
### Namen der Ordner, die entschluesselt werden sollen
### es wird ein Ordern nach dem anderen durchgegangen (Schleife)
folders=(share1 share2)
for i in ${folders[@]}; do
pwremotepart1=$(<$mountpoint${server}${i}part1)
pwlocalpart2=$(<$local${server}${i}part2)
pw="$pwremotepart1$pwlocalpart2"
/usr/syno/sbin/synoshare --enc_mount $i $pw
done
### Der Ordner "remotepath", der unter "mountpoint" eingehaengt war, wird wieder ausgehangen
umount $mountpoint

Bei Fragen: fragen!

 

[peterhoffmann]

Das Skript finde ich gut, ähnlich läuft es bei mir und das schon über Jahre sehr zuverlässig.

Ich finde aber die Begrifflichkeit "externer Server" etwas irritierend. Unter externem Server verstehe ich einen Server, der extern sitzt, also nicht im eigenen Netzwerk.

Ein externer Server wäre in meinen Augen z.B. ein Webserver, der irgendwo auf der Welt steht. Da könnte man einen Passwortteil ablegen und mit

PWTEIL1=$(curl http://DOMAIN.tld/DATEI)

abfragen.
Man könnte dies auch noch mit sed, alternativ head, tail, cut kombinieren um aus einer einfachen Textdatei einen Passwortschnipsel raus zu fischen.

Das hätte den Vorteil, dass auch bei vollständigem Verlust der Hardware in der Häuslichkeit man die Textdatei auf dem Webserver löscht und das NAS nicht entschlüsselt werden kann.