Systemverschlüsselung

[debianx]

Hallo,

bei der Installationsroutine habe ich nicht viele Einstellmöglichkeiten gesehen, daher hätte ein paar grundsätzliche Fragen zur Systemverschlüsselung von Debian.

- Gibt es für die Systemverschlüsselung ähnlich wie bei Vercrypt/Truecrypt ein Audit? Wie sicher ist die Vollverschlüsselung unter Debian einzuordnen?
- Gibt es die Möglichkeit eine kaskadierte Vollverschlüsselung zu erreichen bei der verschiedene Verfahren kombiniert werden? (Sinn und Unsinn jetzt mal außen vor gelassen).
- Wie kommt man bei der Installation an mehr Einstellmöglichkeiten zu dem Thema um zB ein bestimmtes Verfahren einzustellen oder eine Kaskade zu erstellen?

Grüße

[TRex]

- Gibt es für die Systemverschlüsselung ähnlich wie bei Vercrypt/Truecrypt ein Audit? Wie sicher ist die Vollverschlüsselung unter Debian einzuordnen?

Und wer auditiert dann das Audit davon?

- Gibt es die Möglichkeit eine kaskadierte Vollverschlüsselung zu erreichen bei der verschiedene Verfahren kombiniert werden? (Sinn und Unsinn jetzt mal außen vor gelassen).

Klar, du könntest innerhalb des Luks-Containers nochmal LVM mit Luks verschlüsseln... und dann darin nochmal mit ecryptfs arbeiten...

- Wie kommt man bei der Installation an mehr Einstellmöglichkeiten zu dem Thema um zB ein bestimmtes Verfahren einzustellen oder eine Kaskade zu erstellen?

Das ist verschwendete Entwicklerzeit. Wenn du so speziell werden willst, nimm am besten gleich debootstrap.

[breakthewall]

- Gibt es für die Systemverschlüsselung ähnlich wie bei Vercrypt/Truecrypt ein Audit? Wie sicher ist die Vollverschlüsselung unter Debian einzuordnen?

Einen Audit nicht direkt, aber dafür verdammt viel Erfahrung. Denn bei dieser Implementierung hat man sich etwas gedacht, und letztendlich arbeiten daran keine unfähigen Menschen. Bis zum heutigen Tage ist dieses Verfahren unüberwindbar, ohne den richtigen Schlüssel. Und in der Vergangenheit wurde schon oft versucht es zu knacken. Hier wird jedenfalls sehr gewissenhaft gearbeitet, und es kommen stets nur solide Konfigurationen und Verschlüsselungsverfahren zum Einsatz.

Und apropos Audit: Gerade Truecrypt wurde jahrelang genutzt, unter kritischen unbekannten Sicherheitslücken, ohne dass hier jemals einmal in den Quellcode gesehen wurde. Die Entwickler sind bis heute völlig unbekannt. Dagegen basiert dm-crypt/LUKS seit jeher auf offenen und Langzeit erprobten Verfahren, die kontinuierlich weiterentwickelt wurden. Damit verglichen war Truecrypt zum Großteil experimenteller Code, zum Teil unsinnig als auch abenteuerlich, was man bspw. an der Kaskaden-Verschlüsselung sah.

- Gibt es die Möglichkeit eine Vollverschlüsselung zu erreichen bei der verschiedene Verfahren kombiniert werden? (Sinn und Unsinn jetzt mal außen vor gelassen).

Nein gibt es nicht. Ist allerdings auch nicht notwendig, da alle modernen Verschlüsselungsverfahren wie, AES, Twofish oder Serpent, praktisch berechnungssicher sind. Beziehungsweise auch nach weit über 10 Jahren, noch keine praktikablen Angriffe existieren. Bei Twofish existiert nicht einmal ein vollständiger theoretischer Angriff, der den ganzen Verschlüsselungsalgorithmus umfasst. Und das nach 19 Jahren seit der Veröffentlichung. Man muss hier wahrhaftig keine Kaskaden errichten, bei dem was bereits existiert.

Wenn man unbedingt mit Kaskaden-Verschlüsselung arbeiten will, dann kann man auch gpg nutzen, was man beliebig oft in einer Pipe in Reihe schalten kann. Und das mit jeweils unterschiedlichen Schlüsseln und Verschlüsselungsverfahren. Also damit werden selbst enorm paranoide Menschen glücklich.

Doch mehrere Verschlüsselungsverfahren in Reihe zu schalten, die mit ein und demselben Schlüssel verschlüsselt werden, ist nicht wirklich clever. Und dabei ist es egal ob jede Kaskade intern einen anderen Masterkey nutzt, die Schwachstelle bleibt der Schlüssel bzw. das Passwort des Nutzers, der nahezu immer schwächer ist. Hinzu kommt, dass das je nach Datenträger eine ziemliche Belastung darstellt.

Zwar ist Diversität natürlich generell etwas Gutes, weshalb man das auch ausschöpfen sollte. Es gibt so viele Optionen, ob nun gpg oder eCryptfs, dm-crypt/LUKS oder die interne Ext4-Verschlüsselung. Nichts hält einen davon ab alle zu nutzen, die Verschlüsselung der Festplatte selbst ist nur ein möglicher Teil.

- Wie kommt man bei der Installation an mehr Einstellmöglichkeiten zu dem Thema um zB ein bestimmtes Verfahren einzustellen oder eine Kaskade zu erstellen?

Was fehlt denn? Man kann die Verschlüsselungsverfahren doch selbst wählen, und der Rest ist sinnvoll voreingestellt. Standardmäßig ist das Hash-Verfahren sha256, die Hash-Iterationen liegen bei zwei Sekunden, und als Verschlüsselungsverfahren ist aes-xts-plain64 vorgegeben. Will man bei der grafischen Installation alles selbst definieren, muss man auf das Terminal wechseln, oder man installiert Debian komplett via Debootstrap.

[schwedenmann]

Hallo

@breakthewall

Für truecrypt gab es dagegen ein audit und der förderte keine Unzulänglichkeiten, oder Hintertüren zu Tage, von daher ist also truecrypt als sicherer zu bewerten als
luks.

Nur weil der code quellofen ist, heißt das ja nicht, das der sich auch intensiv angeschaut wird und a propo gute Programmierer, wie war das denn mit der random funktion im Kernel oder der "foo-cow-bug" der dann nach Jahren geflickt wurde um dann wieder eine neuen bug zu erzeugen, weil der Code Scheiße war.
Opensource heißt nicht sicherer und Opensourceprogrammierer sind per se keine Genies.

mfg
schwedenmann

[breakthewall]

Keine Unzulänglichkeiten?

https://ostif.org/the-veracrypt-audit-results

Soviel dazu. Und hier sind die Sicherheitslücken vom Truecrypt-Audit selbst garnicht enthalten. Da waren genug haarsträubende Probleme dabei. Wo sind denn vergleichbare Probleme bezüglich dm-crypt/LUKS, die unmittelbar die Sicherheit des Verfahrens untergraben haben?

Nebenbei kann eine Software die keiner Entwicklung mehr unterliegt, nicht sicherer sein. Und auch Veracrypt ist nicht automatisch sicher, nur weil es lediglich auf Truecrypt basiert, und dazu noch in einem Überwachungsstaat entwickelt wird. Das stinkt alles.

Zusätzlich stehen beide Sicherheitslücken in keinem Verhältnis zum Thema hier.