Veröffentlicht am

Verschlüsselung ist wichtiger denn je

GnuPG IconAngesichts der Späh-Affäre um #PRISM und #Tempora wird das Thema Verschlüsselung immer wichtiger. Damit ist vor Allem die Verschlüsselung der Kommunikation gemeint.

Eine Vollverschlüsselung der Festplatte schützt meine Daten im Falle eines Diebstahls des Notebooks vor unbefugtem Zugriff, ich verweise da gerne auf die Tuturials von Dave hier im Blog. Gegen Ausspähen des Datenverkehrs beim Versenden oder Empfang vom Mails oder beim Anfordern von Internetseiten hilft die Vollverschlüsselung natürlich nicht. Klar, wenn ich als User angemeldet bin, ist die Festplatte offen, sonst könnte ich ja die Daten selbst nicht lesen. Sensible Daten lassen sich noch in einen TrueCrypt-Container packen und nur bei Bedarf entschlüsseln, aber das schützt noch immer nicht den Datenverkehr.

Für den Datenverkehr, bzw. zum Schutz desselben, gibt es mehrere Möglichkeiten, je nach Anwendungszweck. HTTPS als sicheres Protokoll bei der Verbindung zu Internetseiten fällt hier jedoch aus, da Sicherheit hier eigentlich nur vorgegaukelt wird. Zu leicht kann man hier mit gefälschten Serverzertifikaten Daten abgreifen. Dies sollte beim Onlinebanking oder bei der Nutzung des Webmailers stets beachtet werden. Hier hilft es wirklich nur, die Internetadresse der Bankseite manuell einzugeben oder bestenfalls aus den eigenen Lesezeichen aufzurufen und genau darauf zu achten, dass das Zertifikat stimmt. Aktuelle Browser signalisieren dies in der Adressleiste. Natürlich sollte auch der Browser sowie das Betriebssystem auf dem aktuellen Stand gehalten werden.

GnuPG-verschlüsselte Mail
Ohne den richtigen Schlüssel und die zugehörige Passphrase sieht der Leser der Mail nur Buchstabensalat.
Beim Mailverkehr nutzt man am Besten GnuPG. Das ist kostenlose Opensource-Software, die es für alle gängigen Betriebssysteme gibt. Damit lassen sich E-Mails vor dem Versenden verschlüsseln, so dass sie nur vom Empfänger zu lesen sind. Cracker, die sich versprechen, hier Zugangsdaten zum Banking oder so abzugreifen, oder die NSA gucken da in die Röhre und sehen nur Buchstabensalat. Eine Anleitung zur Anwendung von GnuPG auf Linuxsystemen hat Dave hier im Blog schon verfasst, ich habe eine Anleitung nur Nutzung auf Android-Smartphones und -Tablets geschrieben. Darauf sei hier nur verwiesen. Die Einrichtung auf Windows- und MAC-System wird der auf einem Linux-System ähnlich sein, ob das auch für iOS gibt, entzieht sich meiner Kenntnis.

Für Chats spricht alles von Skype, weil hier per default eine verschlüsselte Verbindung und Kommunikation gewährleistet wird. Klingt natürlich erst mal gut. Aber Skype wurde von Microsoft einverleibt, der Quellcode ist geheim, und angeblich gibts Hintertüren für die Behörden. Überprüfen kann das niemand, man muss sich da auf die Aussagen eines gewissen Edward Snowden und auf Dementis von Microsoft verlassen.

Ich nutze zum Chatten lieber Jabber, das das offene XMPP-Protokoll verwendet. Dieses Protokoll lässt mit sich mit Off-the-Record (OTR) verschlüsseln, was die meisten Clients auch unterstützen, und sei es durch Plugins. Als Server für den Jabber-Chat eigenen sich z.B. die des Chaos Computer Club oder der Piratenpartei Deutschland. Wichtig: Man muss nicht auf dem gleichen Server wie der Gesprächspartner sein, die Kommunikation funktioniert serverübergreifend, wodurch ein dezentrales System entsteht. Auch das ist von Vorteil, weil es keinen angreifbaren Zentralserver gibt.

Man registriert sich einfach kostenlos auf dem Server seiner Wahl, und hat dann eine Adresse nach dem Schema nutzername@jabber.ccc.de oder nutzername@jabber.piratenpartei.de. diese Adresse und das zugehörige, meist selbstgewählte Passwort gibt man dann im Client seiner Wahl ein. Ich nutze hier den in KDE integrierten Telepathy, ein Fork von Empathy in GTK-basierten Umgebungen. Der unterstützt jedoch noch kein OTR, das wird aber sicher auch bald kommen. Am KDE-Desktop kann man ansonsten das ehemalige Standard-Programm Kopete nutzen, das OTR unterstützt. In GTK-Umgebungen empfiehlt sich die Nutzung von Pidgin, welches es auch für Windows gibt und das OTR-Unterstützung mitbringt. Am Androiden nutze ich Xabber, womit ich auch unterwegs OTR-verschlüsselt chatten kann.

Kopete und OTR
OTR in Kopete aktivieren
Nachdem der Client soweit eingerichtet ist, ggf. auch noch mit weiteren Zugängen wie z.B. ICQ oder Google Talk, geht man in die Einstellungen und findet dort Menüpunkte wie Module oder Plugins. Hier wird OTR aktiviert und dem Jabber-Account zugewiesen. Daraufhin wird der persönliche Schlüssel generiert, und dem verschlüsselten Chat steht nichts mehr im Wege. Außer natürlich, der Chatpartner nutzt kein OTR

Jetzt haben wir die Kommunikation verschlüsselt, aber was ist mit dem Erstellen von Mails oder Lesen von Chats? Mails und Chatnachrichten werden erst beim Versenden verschlüsselt und beim Empfänger vor dem Anzeigen wieder entschlüsselt. Mit einem Trojaner, z.B. dem eigentlich nicht zulässigen „Bundestrojaner” (und wer weiß, welche Sauereien NSA & Co. so einsetzen) können Mails und Chats schon beim Schreiben oder später beim Anzeigen einfach mitgelesen werden. Auch Daten, die ich über eine vermeintlich sichere HTTPS-Verbindung schicke, lassen sich beim Schreiben bereits abgreifen, bevor die Verschlüsselung greift.

Eine wirklich sichere Abhilfe gibt es hier nicht. Quellgeschlossene Betriebssysteme wie Windows oder MacOS sind zwar prinzipiell unsicherer als das quelloffene Linux, aber absolute Sicherheit gibt es auch hier nicht. Natürlich lassen sich in Linux durch die offenen Quellen und dem Viele-Augen-Prinzip schwieriger Hintertüten einbauen, aber über noch nicht entdeckte Sicherheitslücken ist nahezu jedes System angreifbar. Linux macht das Leben im Internet also sicherer, ist aber sicher auch kein Rundum-Sorglospaket.

Und eines darf nicht vergessen werden: Wenn wir wie hier beschrieben verschlüsseln, dann verschlüsseln wir nur die Inhalte. Meta-Daten, also wer-wann-mit-wem, ist natürlich noch immer lesbar. Und diese Meta-Daten sind für Geheimdienste und (Ermittlungs)Behörden oft noch interessanter als die eigentlichen Inhalte.

So, geschätzter Leser, das sind die Informationen, die ich Dir geben kann. Handeln und Dein System absichern musst Du selbst

Veröffentlicht am

GnuPG auf dem Androiden

Ich lege bekanntlich Wert auf sichere Kommunikation, wenn es um wichtige Dinge geht. Deshalb verwende ich am PC und Notebook GnuPG zur Verschlüsselung und digitalen Signatur von E-Mails. Was viele nicht wissen: Das geht auch am Smartphone, zumindest wenn es mit Android angetrieben wird.

Der Dave hat ja vor einiger Zeit hier schon mal beschrieben, wie man GnuPG am PC einrichtet. Deshalb gehe ich da auch nicht weiter drauf ein. Ich beschränke mich hier auf die Einrichtung von K-9 Mail und AGP auf dem Androiden.

APG
APG
Download QR-Code
APG
Entwickler: Thialfihar
Preis: Kostenlos

Als erstes wird sie App „APG” eingerichtet: APG sorgt für die Kommunikation mit den Keyservern und den Abgleich der Signaturen. Nachdem die App aus dem Play Store installiert ist, kopiert ihr das Verzeichnis .gnupg aus eurem Home-Verzeichnis am PC auf die Speicherkarte des Smartphone, und nehmt per Umbenennen den Punkt am Anfang weg. Jetzt habt ihr alle Schlüssel, eure privaten ebenso wie die ganzen gesammelten öffentlichen, ab Handy verfügbar.

Startet nun APG auf dem Androiden, drückt die Menütaste und wählt dann „Private Schlüssel verwalten”. Wenn ihr jetzt noch mal auf Menü drückt, könnt ihr entweder einen neuen Schlüssel erstellen, wenn ihr am Phone einen eigenen verwenden wollt, oder ihr importiert euren vorhandenen (oder auch mehrere) Schlüssel. Ich bevorzuge den letzten Weg, da meine Kommunikationspartner nur einen Schlüssel von mir benötigen. Im folgenden Dialog wählt das Verzeichnis aus, welches ihr eben vom PC aufs Handy kopiert habt. APG durchsucht das Verzeichnis, und importiert alle gefundenen privaten Schlüssel.

Damit ihr zum Abgleich von Signaturen und zum Versenden von verschlüsselten Mails die öffentlichen Keys eurer Kommunikationspartner zur Verfügung habt, müssen die natürlich auch importiert werden. Kehrt dazu wieder zum Startbildschirm von APG zurück und drückt auf die Menütaste. Jetzt ist die Wahl „Öffentliche Schlüssel verwalten”, die weiteren Schritte sind mit dem Import der privaten Schlüssel identisch.

Damit ist APG soweit abgeschlossen, dass wir es im Normalfall nicht mehr direkt anrühren. Jetzt geht es jetzt an die Integration ins Mailprogramm.

K-9 Mail
K-9 Mail
Download QR-Code
K-9 Mail
Entwickler: K-9 Dog Walkers
Preis: Kostenlos

Sowohl Google Mail, als auch Android-Mail unterstützen keine Drittprogramme oder Plugins, so dass wir auf K-9 Mail umsteigen. Hier lassen sich beliebig viele Mailkonten einrichten und via IMAP oder POP3 abrufen. K-9 unterstützt MS Exchange und WebDAV, beherrscht IMAP Push Mail und eben auch Verschlüsselung und Signatur über Drittanwendungen. Wie z.B. APG.

Ihr findet dazu in den Kontoeinstellungen den Menüpunkt „Kryptographie”. Hier wählt ihr als OpenPGP Provider APG aus und entscheidet, ob ihr Mails standardmäßig signieren und/oder verschlüsseln wollt. Ich signiere automatisch, verschlüssele aber nur manuell bei Bedarf.

K-9 Mail verfassen
K-9 Mail beim Verfassen einer neuen Mail. Bei mir ist sie Signatur ausgewählt, Verschlüsselung nicht.
Beim Verfassen einer neuen Mail findet ihr nun zwei Optionen: Signieren und Verschlüsseln. Wenn sich die Mailadresse des Absenders im Schlüssel wiederfindet, wird zum Signieren automatisch der richtige Schlüssel angeboten. Da ich automatisch signiere, ist hier der Haken bereits gesetzt.

Möchte ich eine Mail verschlüsseln, setze ich den entsprechenden Haken. Wenn anhand der Empfängeradresse ein Key zum Verschlüsseln identifiziert werden kann, wird dieser automatisch eingesetzt. Ansonsten zeigt K-9 einen Dialog, in dem der korrekte Schlüssel ausgewählt werden kann.

Beim Senden der Mail werdet ihr nach der Passphrase für euren privaten Schlüssel gefragt.

Wenn eine signierte Mail kommt, zeigt K-9 in der Mail-Ansicht einen „Verifizieren”-Button, über den APG aufgerufen wird. Ist der Schlüssel des Absenders bereits im eigenen Schlüsselbund vorhanden, wird direkt verglichen und das Ergebnis angezeigt. Also korrekte Signatur oder inkorrekte Signatur.

Ist der Schlüssel noch nicht im eigenen Schlüsselbund, bietet APG an, die Schlüsselserver zu durchsuchen. Wird dort der passende Schlüssel gefunden, wird der Import angeboten, wie man es auch vom PC her kennt. Nach erfolgreichem Import wird sie Signatur wie gewohnt verifiziert und das Ergebnis wie oben beschrieben angezeigt.

Erreicht euch eine verschlüsselte Mail, seht ihr in der Mailansicht von K-9 einen Haufen Buchstabensalat. Normalerweise werdet ihr automatisch nach der Passphrase für euren privaten Key gefragt, um die Mail zu entschlüsseln. Wenn nicht, tappt auf den „Entschlüsseln”-Button. APG sollte nun die Mail entschlüsseln, und K-9 zeigt euch den Klartext an.

Wie ihr seht, ist die vertrauliche Mail-Kommunikation auch am Android-Smartphone recht einfach zu bewerkstelligen, wenn man sich einmal zum Umstieg auf eine andere Mail-App und zur Einrichtung von APG durchgerungen hat. Danach läufts eigentlich von ganz alleine.

Veröffentlicht am

tinc-VPN als sicheren Exit-Node

Guten Morgen,

nachdem der letzte Eintrag jetzt ja doch wieder ein Weilchen her ist (keine Sorge, ich habe auch die Artikelserie zum Thema Sicherheit nicht vergessen, ich bin nur aktuell 1. beschäftigt und 2. nicht sonderlich motiviert) habe ich hier mal wieder ein Goodie für euch:

Ein Script, das dafür sorgt, dass man seinen tinc-VPN-Server als Exitnode für einen Tunnel nehmen kann ohne sich dabei die Finger zu brechen.

Warnung: YMMV, ich habe alles auf der Konsole gemacht, ich habe keine Ahnung, ob sich das Script mit GUI-Foo wie z.B. dem network-manager verträgt.

Vorbereitung:

tinc installieren:

# apt-get install tinc

tinc.conf erstellen: 

# echo "# Kurzname des Routers/Computers
Name = $NAME_DES_NODES
# Mit folgenden Computern versuchen zu verbinden
ConnectTo = $DEIN_SERVER
# Arbeitsweise des VPN
Mode = Router
# alternativen Port zu 655 verwenden
Port = 8656" > /etc/tinc/$DEIN_NETZWERK/tinc.conf

tinc-up erstellen: 

# echo "#!/bin/sh
ip addr add dev $INTERFACE 1.2.3.4/24 broadcast 1.2.255.255
ip link set dev $INTERFACE up" > /etc/tinc/$DEIN_NETZWERK/tinc-up

tinc-down erstellen: 

# echo "#!/bin/sh
ip route del default
ip route add default via $ORIGINAL_GATEWAY dev $INTERFACE" > /etc/tinc/$DEIN_NETZWERK/tinc-down

Dateien ausführbar machen: 

# chmod +x /etc/tinc/$DEIN_NETZWERK/tinc-*

Keys erstellen: 

# mkdir /etc/tinc/$DEIN_NETZWERK/hosts
# tincd -n $DEIN_NETZWERK -K

Dieser Befehl erstellt einen private- und einen public-key. Bitte beim private-key einfach mit Enter bestätigen und beim public-key
den Speicherort /etc/tinc/$DEIN_NETZWERK/hosts/$NAME_DES_NODES wählen.

Jetzt passt Du die host-Datei an 

# vi /etc/tinc/$DEIN_NETZWERK/hosts/$NAME_DES_NODES

Folgende Eintragungen sind vor dem Key zu machen: 

Address = $IP_DES_NODES
Address = $FQDN_DES_NODES_1
Address = $FQDN_DES_NODES_2
Port = 8656

Geh jetzt die gleichen Schritte auf Deinem Server nochmals durch. Du solltest jetzt auf Client und Server jeweils ein Exemplar der host-Datei haben, diese sollten natürlich unterschiedliche IPs haben und unterschiedliche Namen. Mein Laptop z.B. heißt loki, der Server heißt bifroest.

Jetzt kopierst Du die host-Datei von Deinem Client auf den Server und umgekehrt: 

# scp /etc/tinc/$DEIN_NETZWERK/hosts/$NAME_DES_NODES root@server.

Wenn beide Dateien ausgetauscht sind sollten die beiden Rechner miteinander reden können: 

# tincd -d 3 -n $DEIN_NETZWERK

startet den tinc-daemon mit log-level 3. 

# tail -f /var/log/syslog

zeigt euch den Output. Wenn keine Fehlermeldungen aufblinken sollte es so weit tun.

Bis hierher ist das alles noch nichts besonderes, ihr habt jetzt also den ersten Schritt gemacht und könnt euren Server über ein VPN erreichen. So lange jetzt aber nicht alle Verbindungen über diesen Server geroutet werden, bringt euch das nicht wirklich weit.

Um sicherzustellen, dass das ganze Ding jetzt tut, was es soll, müsst ihr zunächst dem Server beibringen, das Richtige ™ zu tun.

Einsatz als Exitnode:

Dazu verbindet ihr euch mit dem Server: 

$ ssh root@server.tld

und führt dort folgende Befehle durch: 

# iptables -t nat --append POSTROUTING -i $DEIN_NETZWERK -j MASQUERADE
iptables -t nat --append POSTROUTING -j MASQUERADE
iptables -t nat --append PREROUTING -i $DEIN_NETZWERK -j ACCEPT
cat /proc/sys/net/ipv4/ip_forward

Das sorgt dafür, dass euer Server Verbindungen einfach durchschleift und sie nicht zwischendrin blockiert.

Wenn der Server so weit vorbereitet ist, könnt ihr das folgende Script auf dem Client ausführen: 

#!/bin/sh
#I don't think that this is necessary but I'll do it anyway:
#License: CC
 
#define variables
 
GW="$(ip r get 8.8.8.8 | gawk '{print $3}')"
TUN="$IP_DES_SERVERS_IM_VPN"
INTERFACE="$(ip r get 8.8.8.8 | gawk '{print $5}')"
EXIT="$IP_DEINES_SERVERS/32"
 
# change routes
ip route del default
ip route add $EXIT via ${GW%0x*} dev ${INTERFACE%0x*}
ip route add $TUN dev $DEIN_NETZWERK
ip route add default via $TUN dev $DEIN_NETZWERK
echo 'nameserver 8.8.8.8' > /etc/resolv.conf
echo "routes established"
ip r show

Ja, das sind mindestens 2 dirty hacks: awk den Hex-Wert abgewöhnen und die resolv.conf überschreiben aber es funktioniert. Ich habe
das Script unter /etc/tinc/$DEIN_NETZWERK/tinc-route gespeichert. Außerdem habe ich ein weiteres Script angelegt: 

# echo "#!/bin/sh
tincd -n $DEIN_NETZWERK" > /etc/tinc/$DEIN_NETZWERK/tinc-auto

Dieses dient dazu, beim Start der Netzwerkverbindung den tinc-daemon automatisch anlaufen zu lassen.

Meine /etc/network/interfaces habe ich angepasst wie folgt: 

# dhcp-basiertes Kabelnetz
iface auto inet dhcp
pre-up "/etc/tinc/bifroest/tinc-auto"
post-up "/etc/tinc/bifroest/tinc-route"

Damit startet zunächst der tinc-daemon, dann bezieht das interface eine IP und dann werden die Routen angepasst.

Wenn ihr jetzt # mtr eingebt, sollte eure Route über euren Server verlaufen.

Fragen oder Anmerkungen wie immer jederzeit gern in den Kommentaren.

Veröffentlicht am

Kommunikationsverschlüsselung: GPG

Heute schreibe ich über E-Mails, deren latente Unsicherheit und wie man daraus noch etwas ordentliches macht.

Zunächst einmal sollte man wohl beim Thema E-Mails ansetzen. Eine E-Mail ist, wie der Name schon sagt, eine elektronisch versendete Nachricht. Die Einzelheiten dazu findet ihr hier und hier.

Die Besonderheit dabei ist, dass E-Mails mitnichten mit Briefen gleichzusetzen sind, wie allenthalben angenommen wird. Vielmehr sind E-Mails das digitale Äquivalent zur Postkarte: Billig, schnell und lesbar von jedem, der sie auf dem Weg vom Sender zum Empfänger in die Hände bekommt. Mit ein wenig Geschick sind sie sogar manipulierbar und bergen damit ein großes Potenzial für Misslichkeiten aller Arten.

Dagegen hilft nicht viel, die einzige Möglichkeit um aus einer Postkarte eine sichere (siehe dazu auch einen älteren Eintrag) Möglichkeit zur Kommunikation zu machen ist, sie in einen Umschlag zu stecken und den Umschlag zu versiegeln. Wird das Siegel gebrochen weiß der Empfänger, dass die Nachricht nicht mehr in dem Zustand ist, in dem sie den Sender verlassen hat.

Das gleiche kann man problemlos auch bei E-Mails tun: Umschläge und Siegel benutzen.

Dazu installiert man sich das FOSS-Programm GPG, mit dessen Hilfe man sich die Umschläge und das Siegel selbst bauen kann. In den meisten Linux-Distributionen zählt GPG als Bordmittel und ist dementsprechend vorinstalliert. Der Grund dafür ist, dass GPG weit mehr kann, als nur E-Mails verschlüsseln. Was das ist kann man bei Interesse auf der Projektwebsite nachlesen.

Im Interesse der Benutzerfreundlichkeit empfehle ich außerdem, das Programm “Mozilla Thunderbird” sowie dessen Extension “Enigmail” zu installieren. Beides ist in den Debian-Repositories hinterlegt.

Wenn alles installiert ist könnt ihr loslegen. Eine bebilderte Schritt-für-Schritt-Anleitung, die selbst der letzte n00b verstehen sollte findet ihr hier.

Ich möchte gar nicht viel zum eigentlichen Einrichten sagen, da ich finde, dass das die Jungs vom CryptoCD-Team verdammt gut gelöst haben.

Zur Benutzung möchte ich euch allerdings einige Hinweise an die Hand geben.

Stellt euch die Technik vor, als würdet ihr jedem, der euch eine Nachricht schicken möchte, einen Stapel Stahlkisten zuschicken. Jede dieser Stahlkisten hat ein Schloss, das nur mit einem bestimmten Schlüssel zu öffnen ist. Diesen Schlüssel habt ihr allein. Wenn ein Freund euch jetzt eine Nachricht schicken will, nimmt er eine dieser Stahlkisten von seinem Stapel und steckt die Nachricht hinein. Dann schlägt er die Tür zu. Ab jetzt kann die Kiste nur noch mit dem richtigen Schlüssel geöffnet werden. Jetzt setzt sich der Bote ans Steuer seines LKW und fährt die Kiste zu euch. Ihr macht die Kiste auf und  siehe da – die Nachricht hat euch erreicht, ohne, dass jemand anderes sie lesen oder verändern konnte. Und damit ihr sicher sein könnt, dass die Nachricht auch von eurem Freund kommt, hat der sie unterschrieben und sein Siegel auf der Nachricht hinterlassen. Für die Antwort nehmt ihr eine Stahlkiste vom Stapel, den er euch geschickt hat und los gehts.

Prinzip klar? Wunderbar.

Dann noch einige Sicherheitshinweise:

1. Erstellt ein Backup eures geheimen Schlüssels an einem sicheren Ort. Wenn der Schlüssel verloren geht könnt ihr alle damit verschlüsselten E-Mails abschreiben.

2. Gebt den Schlüssel nicht aus der Hand. Jeder, der Zugriff auf den Schlüssel hat, kann in eurem Namen E-Mails verschicken. Und eure E-Mails lesen.

3. Unterstützt das Web of Trust der GPG-Nutzer und geht zu Keysigning-Partys oder veranstaltet selbst welche. Wenn ihr Hilfe braucht meldet euch bei mir.

4. Verschlüsselt so viele Nachrichten wie möglich und helft so, den Umschlag als Standard zu etablieren und die Postkarte zur Ausnahme zu machen.

Falls noch Fragen offen sind meldet euch in den Kommentaren.

Anmerkung: Das Bild zeigt eine graphische Darstellung meines GPG-Web-of-Trust. Erstellt wurde die Darstellung mit sig2dot und springgraph, vielen Dank an Darxus für diese epischen Tools!

Veröffentlicht am

Verschlüsselte Container

Da ich ein wunderbares HowTo gefunden habe muss ich zum Vorgehen keine weiteren Ausführungen machen, denke ich. Falls jemand Fragen hat sollten sie hier in den Kommentaren gepostet werden.

Mit dem Einverständnis von Aaron Spettl kopiere ich das HowTo nach hier. Redundanz schadet nie.

Die einzige Anpassung, die ich vornehme, ist das Dateisystem von ext2 auf ext4 zu aktualisieren.

Ziel:

Ein verschlüsselter Container, den man bei Bedarf in das Dateisystem einbindet. Dies soll ohne Neukompilieren des Kernels funktionieren und keine besonderen Pakete benötigen – sowie in meinem Fall auch unter Debian Testing lauffähig sein.

Pakete:

Wir installieren cryptsetup und loop-aes-utils.

1. Erstellen der Containerdatei

An einem beliebigen Ort legen wir die Datei an, die unsere Daten speichern soll – hier 10 GB groß (mit Zufallsdaten gefüllt): 

dd if=/dev/urandom of=/home/user/daten.safe bs=1M count=10240

2. Loop-Device

Als root legen wir ein Device an, das einfach auf diese Datei verweist: 

losetup /dev/loop0 /home/user/daten.safe

3. Verschlüsselung einrichten

Wir richten nun die Verschlüsselung (Standard: AES mit 256 Bit) auf diesem Device ein – dabei muss das Kennwort angegeben werden: 

cryptsetup -y create datensafe /dev/loop0

4. Formatierung

Der Container ist nun im System unverschlüsselt unter /dev/mapper/datensafe vorhanden. Nun richten wir das Dateisystem ein (hier ext4): 

mkfs.ext4 /dev/mapper/datensafe

5. Mount

Nach der Formatierung können wir das Device unter einem beliebigen Verzeichnis einhängen (das existieren muss): 

mount -t ext4 /dev/mapper/datensafe /mnt/datensafe

Nun kann man auf /mnt/datensafe ganz normal arbeiten, also speziell auch Zugriffsberechtigungen (restriktiv) setzen.

6. Aushängen

umount funktioniert ganz normal, danach noch den Container schließen und das Loopdevice freigeben: 

umount /mnt/datensafe/
cryptsetup remove datensafe
losetup -d /dev/loop0

Tipp: Automatisierung mit sudo

Der mount/umount-Prozess inklusive Öffnen/Schließen des Loopdevices und des Containers kann man in ein Skript packen (und auf einem Ubuntu-System dem User mit sudo die Rechte dafür geben). 

1
2
3
4
5
6
7
8
9
10
11
12

#!/bin/sh
# datensafe_mount.sh
 
LOOPDEV=/dev/loop0
SAFE=/home/user/datensafe
CRYPTNAME=datensafe
MNT=/mnt/datensafe
FS=ext4
 
/sbin/losetup $LOOPDEV $SAFE
/sbin/cryptsetup create $CRYPTNAME $LOOPDEV
/bin/mount -t $FS /dev/mapper/$CRYPTNAME $MNT

und 

1
2
3
4
5
6
7
8
9
10
11

#!/bin/sh
# datensafe_umount.sh
 
LOOPDEV=/dev/loop0
SAFE=/home/user/datensafe
CRYPTNAME=datensafe
MNT=/mnt/datensafe
 
/bin/umount $MNT
/sbin/cryptsetup remove $CRYPTNAME
/sbin/losetup -d $LOOPDEV
Veröffentlicht am

Full-Disk-Encryption

Zu einer FDE kommt man heute mit jedem handelsüblichen Debian oder *buntu-System auf denkbar einfache Weise. Ich gehe davon aus, dass das auch bei den meisten anderen Standard-Distros so ist, kann das aber weder verifizieren noch falsifizieren.

Man startet die Installation, hangelt sich durch bis zum Partitionsmenü und stellt dann auf “Geführt, verwende vollständige Festplatte mit verschlüsseltem LVM” um. Danach folgt man den Anweisungen weiter, installiert das Grundsystem und fertig ist der Lack.

Zu einfach?

Richtig.

Für den Standardfall “eine Festplatte im Rechner verbaut und der Rechner ist ein Linux-Only-Gerät” reicht diese Vorgehensweise aus, man muss sich also dank der grandiosen Vorarbeit der Debian-Developers nicht mal mehr groß Gedanken darum machen.

Wenn man jetzt allerdings mehr als eine Platte hat und diese auch alle nutzen möchte, sieht das Ganze schon etwas schwieriger aus.

Dazu folgt man ebenfalls dem Standard-Installations-Menü bis zur Partitionierung und wählt dann “Manuell” aus.

Je nach Einsatzzweck ist zunächst das Software-RAID zu konfigurieren. Wenn man die Festplatten nicht redundant genutzt werden sollen sondern sämtlicher Speicherplatz ausgenutzt wird kann man sich das RAID sparen.

Dann konfiguriert man den LVM. Dabei steht LVM für Logical Volume Manager, der Link geht dabei zum sehr gut recherchierten und aufbereiteten Wikieintrag bei den Ubuntuusers. Das dort hinterlegte Wissen ist von hier ab als gegeben angenommen. Ich empfehle, alle nicht benutzten Partitionen zu einer LVG (Logical Volume Group), im Folgenden als lvg bezeichnet, zusammenzufassen und dort dann die Volumes anzulegen. Die wichtigen Volumes sind:

– lvg-boot, ca. 200MB bis 1GB, abhängig davon, wie viel Platz man zur Verfügung hat. Ich lasse bei meinen Systemen immer gern Luft nach oben, um für eventuelle Erweiterungen des Codes gerüstet zu sein.
– lvg-swap, sollte ca. doppelt so groß sein wie der Arbeitsspeicher.
– lvg-main, kann der verbleibende Rest des Speicherplatzes sein, falls keine separate /home-Partition angelegt werden soll. Hier finden wir später die /-Partition wieder.
– ggf. lvg-home, falls eine eigene /home-Partition angelegt wird.

Wenn die Volumes angelegt sind wird im Partitionsmenü der Punkt “Verschlüsselte Datenträger konfigurieren” aufgerufen. Hierbei werden alle Volumes außer lvg-boot ausgewählt. Die boot-Partition darf natürlich nicht verschlüsselt werden, sonst bekommt man eine hässliche Fehlermeldung und kann von vorn anfangen.

Die Installationsroutine geht jetzt ein Volume nach dem anderen durch und lässt die Einstellungen abnicken, mit denen die Verschlüsselung eingeleitet wird.

Achtung: Ubuntu setzt hier mehr auf Geschwindigkeit als auf Sicherheit und schlägt vor, die Daten auf den Platten nicht zu löschen. DAVON RATE ICH STRIKT AB! Wenn man größtmögliche Sicherheit haben will, lässt man die Daten überschreiben. Mehrfach. Dazu muss allerdings bei Ubuntu in besagtem Einstellungsmenü ausgewählt werden, dass man die Daten löschen möchte. Das passiert dann automatisch, kann allerdings abhängig von der Partitionsgröße und der Rechenpower eine Weile dauern.

Wenn man die Verschlüsselungs-Einstellungen hinter sich hat landet man wieder im Partitionsmenü. Hier werden jetzt die angelegten Volumes ausgewählt und mit Dateisystemen und Mountpoints versehen. lvg-boot bekommt ein ext3-Dateisystem und wird auf /boot eingehängt, lvg-swap_crypt wird als Auslagerungsspeicher verwendet, dadurch fällt der Mountpoint weg und lvg-main_crypt bekommt ein ext4-Dateisystem und wird auf / eingehängt.

Jetzt werden die Änderungen gespeichert und die Installation fortgesetzt. Ab hier läuft wieder alles nach Standard-Vorgehensweise und die Installationsroutine tut ihre Arbeit.

Wem das jetzt immer noch zu einfach war, dem lege ich diese Anleitung zur Installation eines verschlüsselten Linux Mint Debian Edition (LMDE) ans Herz.

Auch die exzellenten Artikel des Linux-Magazins bzw. des Linux-Users kann ich dazu sehr empfehlen, die Heftnummern reiche ich auf Wunsch gern nach.

Veröffentlicht am

Festplattenverschlüsselung – Wie?

Nachdem ich schon im letzten Artikel erklärt habe, warum die Verschlüsselung einer Festplatte so wichtig ist, komme ich heute endlich dazu, aufzuschreiben, wie man sein System nun absichert.

Die Verzögerung begründet sich in einer längeren Geschichte, in der unter anderem ein widerspenstiger Eee-PC, ein Campingurlaub und ein kaputter USB-Stick eine Rolle spielen. Dazu vielleicht in einem anderen Blogeintrag mehr.

Zunächst ist es wichtig, zwischen der Vollverschlüsselung (Full Disk Encryption, FDE) und einem so genannten Container zu unterscheiden.

Bei der Vollverschlüsselung wird, wie schon der Name sagt, die komplette Festplatte (bis auf die boot-Partition) verschlüsselt. Bei einem Container wird ein einzelner Ordner (oder auch eine ganze Partition, z.B. /home) verschlüsselt.

Die Container-Lösung ist immer dann sinnvoll, wenn man Daten möglichst sicher über ein unsicheres Medium transferieren will. Man erstellt einen Container, legt seine Daten dort ab und kopiert den Container in seinen Webspace, von wo aus zwar jeder die Daten herunterladen kann, aber nur diejenigen auch etwas damit anfangen können, die das Passwort dazu haben. Wichtig dabei ist: Wenn man Dateien in einen Container legt, kann es immer noch sein, dass Teile davon im Swap-Bereich verbleiben, wo sie dann von einem Angreifer gefunden werden könnten. Das heißt, dass Container per se weniger sicher sind als die FDE. Dennoch haben sie, wie oben bereits angeführt, ihre Berechtigung.

Auf der sicheren Seite, wenn es darum geht, seine eigenen Daten vor Unbefugten zu schützen ist man, wenn man sein System vollverschlüsselt.

ACHTUNG: Auch hier gilt, wie bei allen anderen Sicherheitssystemen auch: Sobald ein physischer Zugriff auf das System möglich ist, kann die Sicherheit nicht mehr gewährleistet werden. Wie man an diesem Beispiel sieht, muss man davon ausgehen, dass jeder Fremdzugriff das System kompromittiert. Mit einer FDE wäre der Geschäftsmann vermutlich besser gefahren, hätte sich aber im Zweifel nicht schützen können. Dennoch, so lange man es nicht mit Sicherheitsbehörden zu tun hat, die überdurchschnittlich viel Zeit und Geld haben, ist eine Vollverschlüsselung sinnvoll.

Der guten Ordnung halber trenne ich den Artikel hier in die Anleitung für FDE und die Anleitung für Container.