Teil 3: Datenträger mit TPM und LUKS ver- und entschlüsseln, Zusammenfassung und Fazit

Nachdem ihr im zweiten Teil dieser Artikelserie erfahren habt, wie man mit den Linux-Werkzeugen für Trusted Platform Modules (TPM) Schlüssel und Zertifikate generiert, verwaltet und benutzt, wird sich dieser dritte und abschließende Teil mit dem Thema der Ver- und Entschlüsselung von Datenträgern mit TPM beschäftigen. Dabei besteht grundsätzlich die Wahl zwischen zwei Werkzeugen, “Clevis” und “systemd-cryptenroll”; beide werden vorgestellt.

Teil 2: Werkzeuge für TPM auf Linux installieren, Schlüssel und Zertifikate verwalten und benutzen

Im ersten Teil dieser Artikelserie wurde ein Überblick über die Möglichkeiten und Funktionen eines Trusted Platform Module (TPM) gegeben. Im zweiten Teil werdet ihr die praktische Benutzung mit den Werkzeugen auf Linux kennenlernen. Insbesondere wird es darum gehen, wie ein TPM unter Linux grundsätzlich eingerichtet wird und wie es über die PKCS11-Schnittstelle angesprochen werden kann.

Teil 1: Einleitung, Übersicht über die Funktionen und die Organisation von Schlüsseln und Daten mit TPM

„TPM“ ist die Abkürzung für „Trusted Platform Module“, was etwa mit „Vertrauenswürdiges Plattform-Modul“ übersetzt werden kann. Im Folgenden wird von „einem TPM“ als einer Komponente in einem Computer gesprochen.

In dieser dreiteiligen Artikelserie wird eine Übersicht über die Technologie TPM gegeben, und es wird anhand praktischer Beispiele die Benutzung von TPM mit dem Betriebssystem Linux gezeigt. Der erste Teil enthält eine Einleitung in das Thema und eine Übersicht über die Eigenschaften, Funktionen und Organisation der Daten einer TPM-Komponente. Die beiden späteren Teile sind praktischer Natur und zeigen den Umgang mit TPM auf Linux zur Verwaltung von kryptografischen Schlüsselpaaren für X.509-Zertifikate, OpenSSH sowie für die Datenträger-Verschlüsselung mit LUKS.

Verschlüsseltes DNS selber machen

Seit einiger Zeit gibt es Bestrebungen, die Namensauflösung kryptographisch abzusichern. Dafür existiert auf der einen Seite mit DNSsec eine Technik, die eigene Zone zu signieren und so gefälschte DNS-Antworten zu verhindern. Auf der anderen Seite existieren mit DNS over TLS (DoT) und DNS over HTTPS (DoH) zwei Techniken, mit denen die Anfragen zwischen Client und Resolver verschlüsselt werden können. Standardmäßig funktioniert die Namensauflösung komplett unverschlüsselt und kann beispielsweise vom Internet Service Provider oder dem Betreiber eines öffentlichen WLANs mitgelesen oder sogar verändert werden. Mit der Verschlüsselung kann das Mitlesen von DNS-Abfragen auf der Netzwerkverbindung zwischen Client und Resolver verhindert werden, zwischen Resolver und Nameserver bleibt sie unverschlüsselt. Auf dieser Verbindung ist eine Zuordnung der Anfragen zu einem Client in der Regel nicht möglich, weiterhin können viele Anfragen direkt aus dem Resolver-Cache beantwortet werden. Meist sind es jedoch große Konzerne, welche die dafür nötigen Resolver zur Verfügung stellen. Damit wird das eigentlich dezentrale DNS letztendlich doch wieder an wenigen Stellen zentralisiert.

Das muss aber nicht sein, denn der Betrieb eines eigenen Resolvers für DoT und DoH ist möglich. Die folgende Anleitung zeigt, wie das geht.