Ralles personal blog

Nicht, dass der Verdacht aufkommt, das Projekt wäre ausgelaufen:

Das Durcharbeiten mehrerer Bücher hat nur etwas Zeit in Anspruch genommen. Besonders empfehlen möchte ich Bruce Schneier, renomierter Verschlüsselungsexperte. Eines seiner Bücher ist Secrets&Lies, das sich mit vielfältigen Angriffen etc. beschäftigt. Kurzresumee von meiner Seite: die aktuellen Verschlüsselungsalgorithmen sind sicher, sogar so sicher, dass sich eigentlich niemand mehr die Mühe macht, diese direkt anzugreifen. Vielmehr sind andere Vektoren deutlich einfacher und erfolgversprechender. Oftmals sind die Algorithmen schlecht oder sogar falsch implementiert, sodass sich die Komplexität deutlich reduziert. Social Engineering ist wohl auch sehr erfolgversprechend, häufige Berichte dazu untermauern diese Lücke. Daneben gibt es eine vielzahl von Seitenbandangriffen, die in vielen Fällen die eigentlich gute Verschlüsselung der Daten aushebeln. Wichtig ist Kerkhoff's Prinzip: obscurity fliegt irgendwann auf, d.h. der Algorithmus kann ruhig und soll sogar offengelegt werden. Nur der Schlüssel muss geheim bleiben, er kann geändert werden wenn er kompromittiert wurde. Mit dem Algorithmus ist das nicht mehr möglich.

Wichtig ist es, sich über alle möglichen Angriffe und Lücken schon beim Design Gedanken zu machen und diese gleich auszuschließen. Das hat mich dazu gebracht, die ursprünglich idealisierten Ziele zu modifizieren. Absolute Sicherheit ist wohl tatsächlich eine Illusion, man kann lediglich den Aufwand für Angreifer so hoch treiben, dass es sich nicht mehr lohnt.
In diesem Zuge werde ich für die Vorgaben neue Definitionen setzen und auch grafisch die Systeme analysieren (die Wände meines Studios sind bereits mit bekritzelten Plakaten gespickt). Gelegentlich werde ich das digital hier einfügen.

Praktisch hat sich auch etwas weiterentwickelt. Mein mobiles Arbeitspferd (Slimbook 13 aka Katana aka Infinity 13) habe ich jetzt auch voll verschlüsselt. Das hatte ich ohnehin entsprechend der vorgehenden Erkenntnisse vor, der Lieferant hat die aktuelle Ubuntu-Lücke mit der Vollverschlüsselung ab Installation zwischenzeitlich auch geschlossen. Das Prinzip ist das selbe, nur die Umsetzung wurde in das Installationsscript integriert. Das bedingt zwar eine bare-metal Installation, geht aber schneller als eine manuelle Umsetzung in mehreren Schritten. Wen es interessiert, die Anleitung dazu findet sich hier: https://www.tuxedocomputers.com/de/Infos/Hilfe-Support/Anleitungen/Verschluesselung-von-TUXEDO-Computers-Systemen-mit-LUKS-LVM.tuxedo. Man beachte, dass das Installer-Script (WebFAI) nur auf Tuxedo-Hardware funktionieren wird; mit den früher dargestellten Schritten lässt sich das aber manuell fast genauso einfach umsetzen.

Die Einrichtung des YubiKey war dann einfach und schnell in wenigen Minuten realisiert. Interessant und praktisch ist, dass kein neues Secret auf dem Key generiert werden muss und trotzdem ein neuer Kurzschlüssel genutzt werden kann. Somit habe ich jetzt zwei Notebooks mit Vollverschlüsselung, die beide mit dem selben Key, aber verschiedenen Kurzschlüsseln entschlüsselt werden können. Das war mir nach dem (zugegeben noch recht oberflächlichen) Studium der Key-Dokumentation noch nicht ganz klar, auch das hier zugrundeliegende Konzept werde ich mal grafisch darstellen.

Mit den bisher gewonnenen Erkenntnissen ist die Verschlüsselung einer externen Festplatte kein großes Thema mehr, für USB-Sticks gilt das gleiche.

Warum sollten externe Datenträger verschlüsselt werden?
Aus diesen Gründen: einerseits sind diese mobil und bergen damit ein größeres Risiko, vergessen oder verloren zu werden. Damit bräuchte man sich im Verlustfalle keine Sorgen über Enthüllungen oder sonstigen Missbrauch zu machen. Die Daten sind zwar immernoch weg, aber eben nicht woanders...
In Zeiten der DSGVO bleibt praktisch keine Alternative, der Verlust von Kundendaten kann sich (zurecht) zu einer unangenehmen und teuren Lehrstunde entwickeln.
Andererseits ist die Entsorgung sehr viel bequemer - einfach in den Elektronikschrott geben. Auch wenn sich ein Dumpster-Diver noch daran versuchen sollte, kommt er nicht an die Daten. Besonders beruhigend ist das, wenn der Datenträger (was bei mobilen durchaus häufiger vorkommt) den Geist aufgegeben hat. Dann ist nichts mehr mit "sicher löschen", eine sichere physikalische Zerstörung wäre dann der letzte Weg.

Damit die Daten nicht ganz weg sind, hat man natürlich (vorher!) ein entsprechendes Backup- und Redundanzkonzept umgesetzt. Dazu gelegentlich mehr.

Zurück zum Thema, eine gute Anleitung zum Verschlüsseln einer externen Festplatten gibt es hier: https://www.selbstdatenschutz.info/linux/externe_datentraeger_verschluesseln. Auch hier kommt wieder cryptsetup/luks zum Einsatz, beim Anstecken der externen Festplatte wird automatisch die Passphrase abgefragt und der Datenträger gemountet.
Die Anwendung eines Securitykeys ist genauso möglich, nach der folgenden Quelle soll der im vorhergehenden Schritt belegte Slot 2 sich auch für mehrere Anwendungen nutzen lassen: https://askubuntu.com/questions/599825/yubikey-two-factor-authentication-full-disk-encryption-via-luks. Das muss ich noch verifizieren, auf Anhieb bekomme ich es nicht hin, dass die Passphrase des Key akzeptiert wird (in der GUI wird der Key gar nicht angesprochen).

Zu dem Problem hat sich natürlich auch schon jemand Gedanken gemacht: https://blog.hannesrantzsch.de/yubikey-encrypted-drive.html, das probiere ich aber heute nicht mehr.

Ok, doch noch ausprobiert...
Funktioniert, allerdings nur auf der Commandline, dafür auch mit der Einrichtung auf Keyslot 7. So ganz rund aber auch noch noch nicht, muss ich später mal genauer testen.
Cool wäre das in Kombination mit einem Automount über udev, dann könnte man die Passphrase-Abfrage der GUI vielleicht auch unterdrücken?

Note to self: da das doch einen gewissen Umfang einnimmt, sollten die Vorgehensweisen im Wiki als Schritt-für-Schritt-Anleitung dokumentiert werden. Dazu sollten die Quellen gesichert werden und auch die aktuell verwendeten Sources. Nur so wegen der Paranoia, Webseiten gehen schon mal offline...

Mit der richtigen Anleitung funktioniert es schnell, einfach und korrekt:

https://www.golem.de/news/systemverschluesselung-yubikeys-zwei-faktor-authentifizierung-unter-linux-nutzen-1507-115155.html

Damit ist eine Teilaufgabe gelöst: Die Festplatte eines Notebooks ist verschlüsselt (root und swap), damit bräuchte man sich im Verlustfalle keine Sorgen um die Daten zu machen.
Die Entschlüsselung beim Systemstart erfolgt per Securitykey und relativ enfacher Passphrase. Verlöre man den Securitykey zusammen mit dem Notebook, fehlte die Passphrase - also sicher.
Verlöre man nur den Securitykey oder vergäße die Passphrase, so könnte man auch noch mit der Master-Passphrase arbeiten, den verlorenen Key löschen und ggf. den Ersatz gleich wieder eintragen.

Was haben wir gelernt:

• unter Ubuntu (und Derivaten/Flavors) ist die Festplattenverschlüsselung relativ einfach
  • dabei bleibt die boot-Partition unverschlüsselt, von irgendwas muss das System ja starten
  • die Verschlüsselung muss vor oder bei der Installation des Systems erfolgen; nachträglich ist vorstellbar, aber unnötig aufwändig
• die luks-Verschlüsselung ermöglicht 8 (0..7) Schlüssel, mindestens einer muss vergeben werden
• der Yubikey kann recht einfach einen dieser Schlüssel-Slots belegen
• damit ist diese Kombination möglich und sinnvoll:
  • eine ausreichend lange und komplexe Passphrase (wenn der Yubikey nicht zur Verfügung steht)
  • bei Mehrbenutzersystemen kann jeder User seine eigene Passphrase bekommen (max. 8 )
  • eine relativ einfache Passphrase in Verbindung mit dem Yubikey, der auch nur während der Abfrage eingesteckt sein muss

Was ist noch weiter zu verfolgen?

1. wie sicher ist das Challenge-Response Verfahren HMAC-SHA1 Hash mit 64 Byte Länge?
2. wie lange und komplex sollte die Master-Passphrase sein, um ausreichend sicher zu sein?
3. wie definieren wir eigentlich "ausreichend sicher"?
4. wie lange und komplex sollte die kurze Passphrase in Verbindung mit dem Securitykey sein, um ausreichend sicher zu sein?

Für 1. muss ich mich noch weiter einlesen.
Die Fragen 2. und 4. hängen einerseits von 3. ab, andererseits auch von eventuellen weiteren Sicherheitsmaßnahmen, etwa die Anzahl der möglichen Fehlversuche, Zeitsperren etc.
Erste Tests ergaben, dass nach 3 falschen Eingaben erst einmal 60 Sekunden nichts mehr geht. Das wiederholt sich, damit ist (zumindest solange die Festplatte im System eingebaut ist) die Anzahl der möglichen Versuche pro Zeit begrenzt. Durch Ausbau der Platte wird das nicht mehr zum Tragen kommen.

Eine ganz gute Einschätzung für eine erste Bewertung zu 2. liefert https://gitlab.com/cryptsetup/cryptsetup/wikis/FrequentlyAskedQuestions#5-security-aspects. Die Autoren von cryptsetup empfehlen 14 Zeichen, wobei die Entropie wichtig ist (also wirklich durcheinander und keine gebräuchlichen Wörter). Paranoide Naturen mögen 18 Zeichen nehmen (entspräche etwa 85 bit), ich habe mir für "wichtige" Dinge ohnehin schon 20 Zeichen angewöhnt - ist das jetzt visionär oder paranoid?

Zu 4. muss ich mir noch Gedanken machen, hier kommt der 2FA-Gedanke ins Spiel (zwei Faktor Authentifizierung). Der eine Faktor ist der physikalische Besitz sowohl des Notebooks/der Festplatte und des Security-Keys. Der zweite Faktor ist das Wissen der kurzen Passphrase. Da dies normalerweise nicht unbeabsichtigt zusammenfällt, sollte es also sicherer als nur mit Passphrase sein. Die Frage ist: gibt es hier auch zusätzliche Sicherheitsmaßnahmen?

to be continued...

Gestern Abend noch schnell einen zweiten Satellite installiert, diesmal mit Kali und ebenfalls mit verschlüsselter Festplatte - was hier per Setup problemlos funktioniert hat und im Grunde genauso aufgebaut ist (luks und LVM2).
Der heißt jetzt "anna1" und kann als Angreifer herhalten, auch den Aspekt möchte ich mir ansehen. Aber erst später, ist vermutlich nicht ohne zusätzlichen Aufwand zu machen.

Heute im Newsreader fand ich einen Bericht zu Security Keys: https://www.golem.de/news/fido-sticks-im-test-endlich-schlechte-passwoerter-1903-139953.html. Das beruhigt mich insoweit, als dass der mehr oder weniger spontan gewählte Yubikey durchaus in der Profiliga mitspielt und alle aktuellen Standards unterstützt. Weiterhin gehe ich davon aus, dass sich dieses Feld entwickeln wird und dass es für die typischen Anwendungsfälle auch genug HowTos geben wird.

See you...

Ein erster Erfolg hat sich eingestellt, die Vollverschlüsselung eines Linuxrechners konnte erfolgreich nachvollzogen werden.

Dabei hilft Ubuntu nur beschränkt: neuere Versionen bieten die Verschlüsselung bei der Installation nicht an, bei der getesteten Lubuntu 17.10 i386 (lag gerade im Schubber obendrauf und passt zu otto1 - einem alten Satellite A200, das hier zufällig in doppelter Ausführung rumlag) brach das mit dem Hinweis auf eine nicht verschlüsselte SWAP-Partition ab. Whatever, hat vielleicht was mit dem Boot-USB-Stick zu tun.

Aber das Ubuntu-Wiki hilft hier weiter: https://wiki.ubuntuusers.de/System_verschl%C3%BCsseln/

In Kurzform: vom Stick ins Live-Linux starten, dann manuell die Festplatte konfigurieren: eine kleine boot-Partition und den Rest per cryptsetup als LVM anlegen, / (root) anlegen und ein bisschen dran rumbasteln. Dann die Installation starten, die vorbereiteten Partitionen manuell entsprechend zuweisen und am Ende der Installation noch ein paar kleine Anpassungen und aufräumen. Nach dem Neustart erscheint dann tatsächlich die Abfrage nach dem Schlüssel.

Erstes Teilziel somit erreicht!

Nächster Schritt: tiefer mit luks etc. beschäftigen und dann das ganze so umbauen, dass der aktuelle Schlüssel richtig komplex gewählt wird und später nur noch für Notfälle dienen soll. Die eigentliche Anmeldung soll dann mit einem genauso komplexen Schlüssel erfolgen, der aber praktischerweise vom Yubikey kommen soll. Und damit der nicht der einzige Faktor bleibt, wird dieser mit einem relativ einfachen Schlüssel getriggert. Geht der Key mal 'verschütt', kommt man mit dem obigen Notfallschlüssel immer noch rein.

Aber heute nicht mehr, es läuft gerade "mein Mix der Woche" auf Spotify...

So, diese Einträge dienen nun zur Dokumentation meiner praktischen Umsetzungsversuche im Gebiet der Kryptographie. Sie sind, im Gegensatz zu den meisten anderen Einträgen, öffentlich sichtbar. Alles hier geschriebene ist jedoch ausdrücklich nur für den privaten Gebrauch bestimmt und dient lediglich mir selbst und ggf. anderen zum Nachvollziehen der Schritte. Genannte Warenzeichen, Markennamen etc. dienen lediglich der Verdeutlichung, ich mache mir die keinesfalls zu eigen und Werbung ist in keiner Weise beabsichtigt. Ich stehe mit keinem der genannten Unternehmen, Produkten oder Personen in Verbindung und bekomme für Nennung o.ä. auch keine Leistungen irgendwelcher Art; diese Seite ist privat finanziert und betrieben. Alle Links dienen nur zur Ergänzung und als Quellenbeleg; ich distanziere mich von den darin enthaltenen Inhalten.

Mein Ziel ist folgendes:

• Entwickeln eines tieferen Verständnisses zum Thema
• Schaffung einer nachvollziehbaren, sicheren Ablage für Passwörter und Kennungen
  • webbasiert (eine gültige Ablage, möglichst aber lokale Caches)
  • Zugriff von Rechnern mit Windows und Linux
  • Zugriff von Android-Smartphones
• Schaffung einer nachvollziehbaren, sicheren Verschlüsselung für Festplatten und USB-Sticks, die als Offline-Sicherung und sichere Offline-Transportmedien dienen sollen
• Einrichtung einer nachvollziehbaren, sicheren Verschlüsselung auf Notebooks für das laufende Betriebssystem
• Bewertung verschiedener Alternativen
• Dokumentation des Vorgehens
  • zum Nachprüfen des Konzepts
  • zum Nachvollziehen für den Recoveryfall und für andere
• Nebenziel: ausreichende Festigung des Themas für Vorträge, Lehrinhalte etc.

Ziel ist also jeweils eine geeignete Lösung zu finden und/oder auszuarbeiten, diese ausreichend zu durchdringen, die Sicherheit bewerten zu können, sie anzuwenden und schließlich zu dokumentieren. Ein wichtiger Auslöser war für mich die Lektüre des Romans Cryptonomicon von Neal Stevenson, die mir sowohl die Notwendigkeit vor Augen geführt, als auch auf unterhaltsame Art mein Interesse geweckt hat. Dieses Buch ist inzwischen definitiv in meiner Top-10 (und ich lese sehr viel!) und steht im Regal zwischen Alastair Reynolds und JRR Tolkien.

Vorhandene Grundlagen:

• Stephenson, Neal: Cryptonomicon. Avon, New York 2002. ISBN: 978-0060512804

• Ertel, Wolfgang: Angewandte Kryptographie. Hanser, München 2001. ISBN: 3446215492 (aus der Unibibliothek entliehen)

• Ertel, Wofgang; Löhmann Ekkehard: Angewandte Kryptographie, 5., üb. und erw. Aufl.. Hanser, München 2018. ISBN: 978-3-446-45468-2 (aufgrund der Aktualität gekauft)

• Crypttool Portal: Seite des CryptTool Projekts für einfachen Zugang zur Kryptographie für jedermann, mit kostenfreien Tools. Webseite: https://www.cryptool.org/de/

• Dokumentation des Passwortsafe-Tools KeePass: ausgewählt wegen der persönlich als gut empfundenen Usability sowie der Verfügbarkeit auf allen drei Zielplattformen, außerdem Open Source. Webseite: https://keepass.info/

• Dokumentation von der Seite des Anbieters von Sicherheitsschlüsseln Yubico: aus Interesse ausgewählt, weil ich mir von dem beschafften Modell 5 mit NFC vielfältige Nutzungsoptionen und hohe Sicherheit auf allen Plattformen erwarte. Webseite: https://www.yubico.com/

• weitere Webseiten, die ich im Verlauf angeben und kurz beschreiben werde

• weitere Publikationen und Druckwerke, die ich ebenfalls bei Bedarf angeben werde

Die beiden Primärsysteme für die Umsetzung laufen unter Ubuntu 18.10 bzw. Ubuntu Budgie 18.04 LTS. Ein System hat zusätzlich Windows 10 über dual boot, auf dem anderen System können mehrere VMs von Minix 3.0 über Kali bis Windows 2000 zu Entwicklungs-, Analyse- und Testzwecken gestartet werden. Das dritte Zielsystem ist ein Smartphone mit LineageOS 16.0/Android 9. Als Datenspeicher kommt neben einem NAS-System die eigene Cloud (unter Nextcloud 15.0.x) zum Einsatz - wofür bereits SSL über let's encrypt-Zertifikate zum Einsatz kommt.

So, das waren erst einmal die Grundlagen. Alles weitere wird nach Fortschritt dokumentiert.