Der Inhalt des ganzen Vortrags von Jürgen Pabel dreht sich um die Möglichkeiten, eine komplette Festplatte, insbesondere die Systemplatte zu verschlüsseln. Das kann entweder in Software oder neu auch in Hardware erfolgen. Dabei geht es nicht um verschlüsselte Container oder Archivdateien sondern tatsächlich um Verschlüsselung auf Plattenebene. Die gängigen Varianten sind:
- USB/Firewire-Festplatte mit Crypto-Controller (Fingerprint/PIN-Authentication)
- Festplatte mit SATA Security Option
- Software-Treiber
- Hardware-Modul (PC-Card)
Kritisch ist die Pre-Boot-Authentication. Normalerweise lädt das BIOS diese Software von einem unverschlüsselten Bereich der Platte. Bei Linux muss das in die Boot-Partition integriert werden. Von dort werden die Schlüssel zum Zugriff auf die verschlüsselten Bereiche bereitgestellt. Unter Linux wird dann einfach die Systempartition durch Device Driver Hooking gemountet, in Windows muss der NT-Kernel um die Verschlüsselungsfunktion mittels Low-Level Filter Driver erweitert werden.
Für den Anwender ist die wichtigste Unterscheidung vermutlich, dass es unter Linux noch keine „in-place“ Verschlüsselung gibt, auf einer verschlüsselten Platte muss immer erst ein neues Filesystem angelegt werden. Windows-Software kann bestehende Partitionen in der Regel bei der Installation nachverschlüsseln.
Die detaillierte Produktvorstellung fand ich jetzt nicht so spannend, ich schätze das ist ein Abfallprodukt seiner Consulting-Arbeit. Ich persönlich verwende Utimaco SafeGuard Easy und TrueCrypt, mit beidem habe ich gute Erfahrung gemacht. Utimaco verschlüsselt die ganze Platte und TrueCrypt nochmal einzelne Container. Und meine Passwörter liegen in einem KeePass-Safe in einem TrueCrypt-Container auf einer Utimaco-verschlüsselten Platte. Und für die ganz wichtigen Sachen gibt es bei TrueCrypt noch Hidden Volumes. Ich denke, das dürfte ausreichen.
Als Übersicht der verschiedenen Möglichkeiten und Technologien fand ich den Vortrag jedoch ganz interessant.
Thank you for covering my presentation, from what I understand you’re fairly happy with it. I expected that there would be parts that are somewhat boring to people who’ve already had some experience with FDE products, but I was willing to take this risks in order to give a more complete introduction for those who haven’t had any previous exposure to this technology.
Also, one correction: encrypting existing filesystems („in-place/on-the-fly encryption“) is possible on Linux, just not with open-source solutions (LUKS/dm-crypt, …). However, both commercial products with Linux support (mentioned in the slides) actually implement in-place encryption.
Comment by Juergen Pabel — 28. Dezember 2008 @ 17:47
Ja, ich arbeite ja auch als Security Consultant, da sind eine Menge Sachen in der Präsentation, die ich gut brauchen kann. Ich bin ja eigentlich auch nur Anwender und habe mich bisher nicht mit den technischen Details beschäftigt.
Was ist eigentlich an der In-Place Encryption eines Linux-Filesystems so schwierig, daß das noch kein Open Source Produkt implementiert hat?
Eine andere Frage, die mein Nachbar aufgeworfen hat ist, wie es denn mit der Sicherheit der Algorithmen bestellt ist. Kann man sich darauf verlassen, daß z.B. die AES-Implementierung fehlerfrei ist und nicht etwa Key-Informationen leaked? Es gab ja mal gerüchteweise so VPN-Tunnnel mit Hintertüren, bei denen Schlüsselinformationen z.B. in Sequenznummern geleakt sind.
Comment by Christian — 28. Dezember 2008 @ 18:23
Ooops, hab gerade erst bemerkt, dass ich den Kommentar auf Englisch geschrieben habe.
Comment by Juergen Pabel — 28. Dezember 2008 @ 18:24
Macht nix 🙂 Die meisten Leser können englisch aber ich schreibe (auch aus Bequemlichkeit) lieber deutsch. Es darf auch mal was deutschsprachiges in der IT geben.
Comment by Christian — 28. Dezember 2008 @ 18:33
Die In-Place Verschlüsselung ist eigentlich recht trivial zu implementieren: der Treiber muss nur an der richtigen Stelle im Kernel eingehängt werden und wissen, bis zu welchem Sektor (gar nicht, mittendrin, fertig) schon initial-verschlüsselt wurde. Problematisch wird es mit den notwendigen Metadaten, wie eben auch den gerade angesprochenen Status der Verschlüsselung – das muss ja irgendwo persistiert werden. Und dafür muss man irgendwo auf dem Speichermedium (Festplatte) einen ansonsten bisher unbelegten Platz finden. Wie vorgetragen hat TrueCrypt dafür die unbelegen Sektoren zwischen dem MBR und der ersten Partition genutzt. Das könnte man auch unter Linux so machen – das wäre aber genau so ein Workaround/Hack wie bei TrueCrypt. Ansonsten muss man eben auch Filesystem-Shrinkage implementieren (oder eine existierende Implementierung nutzen).
Meine persönliche Meinung zu einer fehlenden OSS Unterstützung ist, dass die meisten Linux Benutzer sich schon bei der Installation darüber Gedanken machen und von „Anfang an verschlüsseln“. Oder neuinstallieren, oder oder oder … Aber ich denke schon sehr bald wird es eine kritische Masse geben, die dieses Feature fordern.
Und abschliessend: rein aus dem Bauch würde ich behaupten, dass insbesondere die Programmierung für dm-crypt recht trivial sein sollte. Möglicherweise lässt sich im LUKS header ja auch noch ein Platz für die Verschlüsselungs-Statusinformationen finden? Das sollte am besten backward-compatible sein (evtl. kann man als ersten Hack einen LUKS keyslot dafür missbrauchen?).
Comment by Juergen Pabel — 28. Dezember 2008 @ 18:41
Danke 😉
Comment by Christian — 29. Dezember 2008 @ 22:35
Kommentare gesperrt wegen Spam
Comment by Christian — 27. Februar 2009 @ 21:44