© Wutthichai Piyaphantawong, 123RF.com

Ipsec gilt für viele als der Standard unter den VPN-Technologien. Wer dabei ganz auf Nummer sicher gehen will, speichert seine Zugangsberechtigung in Form von X.509-Zertifikaten auf verschlüsselten Tokens oder USB-Sticks. Wie das geht, zeigt dieser Artikel am Beispiel von Strongswan.

Wo früher dedizierte Telefonleitungen für den sicheren Remote-Zugriff sorgten, brauchen Admins heute ausgefuchste Sicherheitstechnologien: VPNs – virtuelle private Netze – bauen sichere Verbindungen über unsichere Transfernetze auf. Statt teurer Einwahlverbindungen nutzen Administratoren das Internet, um Filialnetze und Telearbeitsplätze kostengünstig mit dem zentralen Unternehmensnetz zu verbinden.

Industriestandard IPsec

Wer heute sichere VPNs bauen will, kommt am Industriestandard des IP Security Protocol (IPsec, [1]) nicht vorbei. Zwar haben verschiedene Hersteller andere, meist proprietäre Lösungen für den Aufbau von VPNs entwickelt, doch diese Produkte funktionieren oft nicht auf allen Betriebssystemen oder nur mit bestimmten Softwarepaketen. Mit IPsec setzt der Administrator dagegen eine Protokollfamilie ein, die fast alle Hersteller unterstützen und für die sie auch Software anbieten.

Sicherlich muss ein Administrator auch bei IPsec Probleme in heterogenen Netzen lösen, jedoch lassen sich, entsprechende Erfahrungen vorausgesetzt [2], auch VPNs zwischen den Geräten beliebiger Hersteller aufbauen. IPsec unterstützt verschiedenste Authentifizierungsverfahren – zu den typischen und sichersten Methoden gehören Zertifikate, deren private Schlüssel auf sicheren Smartcards oder USB-Token liegen.

Volle Auswahl

Unter Linux stehen mit Openswan [3], Strongswan [4] und den Ipsec-tools [6] mehrere, recht unterschiedliche Implementierungen bereit. Wie jedes typische VPN übernehmen sie drei Aufgaben:

• Die Authentifizierung der Kommunikationspartner
• Die Verschlüsselung der übertragenen Daten
• Den Schutz vor Modifikationen mit der eingebauten
  Integritätsprüfung

Die letzte dieser Aufgaben implementiert die IPsec-Protokollfamilie mit mehreren Protokollen:

• ESP (Encapsulated Security Payload)
• AH (Authentication Header)
• IKE (Internet Key Exchange)

Das AH-Protokoll garantiert lediglich die Authentizität und Integrität der Daten. Es verschlüsselt die Daten nicht und sorgt auch nicht für ihre Vertraulichkeit. ESP dagegen bietet alle drei Funktionen. Daher nutzen moderne VPNs meist nur noch dieses Protokoll.

Sowohl ESP als auch AH benötigen für ihre Funktion Schlüssel, die der Admin manuell spezifizieren kann. Besser ist es jedoch, wenn die Software diese regelmäßig wechselt. Allerdings müssen dann die Kommunikationspartner die Schlüssel für ESP und AH automatisch aushandeln, und genau darum kümmert sich IKE, das Internet Key Exchange Protocol [6].

IKE verläuft in mehreren Phasen

Das IKE-Protokoll, meist in Version 1 eingesetzt, macht den kompliziertesten Bestandteil von IPsec aus. Mit seiner Hilfe erzeugen Admins die von ESP benötigten kryptographischen Schlüssel. Grob gesehen unterscheidet IKE zwei so genannte Phasen, in denen es zunächst (in Phase 1) die Kommunikationspartner identifiziert. Dabei dient der Diffie-Hellman-Schlüsselaustausch zur gegenseitigen Authentifizierung. Erst in Phase 2 erzeugen die Partner die Schlüssel für das ESP-Protokoll.

Phase 1 kennt zwei verschiedene Verfahren: Aggressive Mode und Main Mode. Administratoren sollten – wenn möglich – nur den Main Mode einsetzen, da der Aggressive Mode die Identifikation der Kommunikationspartner im Klartext überträgt. Der Main Mode erlaubt die Authentifizierung wiederum mit mehreren Verfahren. Hierbei kann die Authentifizierung mit einem Preshared Key (vergleichbar einem Kennwort), RSA-Signaturen oder RSA-Verschlüsselung erfolgen. Neuere Implementierungen nutzen allerdings die letzte Variante in der Regel nicht mehr.

Während ein Preshared Key eine einfache Authentifizierung der Kommunikationspartner im VPN vornimmt, ist die Nutzung der RSA-Signatur die sicherere Variante. Hierzu muss der Admin RSA-Schlüsselpaare für die Kommunikationspartner erzeugen. Als Format nutzen die meisten Implementierungen X.509-Zertifikate, weil diese weitere Vorteile mitbringen.

X.509-Zertifikate verfallen

Mit den durch eine Zertifikatsautorität (CA, Certificate Authority) beglaubigten öffentliche Schlüsseln baut der Admin sehr einfach ein VPN zwischen vielen Kommunikationspartnern auf. Er erzeugt für jeden Kommunikationspartner ein RSA-Schlüsselpaar und signiert die öffentlichen Keys mit einer eigens für diesen Zweck erzeugten CA.

Danach konfiguriert er die Kommunikationspartner (Peers) so, dass sie allen anderen VPN-Teilnehmern automatisch vertrauen. Dafür muss er nur das Zertifikat seiner CA auf allen Rechnern hinterlegen. Die eigentlichen Zertifikate der Peers tauscht das IKE-Protokoll automatisch aus, ähnlich wie bei HTTPS.

Derartige Zertifikate weisen einen beschränkten Gültigkeitszeitraum auf. Anfangs sehen das manche Administratoren als Nachteil an, da nach dessen Ablauf das VPN nicht mehr funktioniert. Bei genauerem Hinsehen erweist sich das Konzept jedoch als Vorteil, weil vergessene Zertifikate nicht automatisch eine Sicherheitslücke reißen, sondern von alleine auslaufen.

Gültige, benötigte Zertifikate muss der Admin regelmäßig und rechtzeitig verlängern und sich so immer wieder mit seiner Security beschäftigen. Nicht mehr benötigte oder kompromittierte Zertifikate widerruft er einfach, nach Veröffentlichung auf einer Wiederrufliste (CRL, Certificate Revocation List) erfahren alle Kommunikationspartner automatisch davon.

Strongswan und Smartcards

Die Authentifizierung mit RSA-Schlüsseln ist zweifellos dem Einsatz von Preshared Keys vorzuziehen. Dennoch könnte ein Angreifer bei einem erfolgreichen Einbruch den privaten Schlüssel und das zugehörige Zertifikat stehlen und anschließend selbst eine Verbindung zum VPN aufbauen.

Schwerer hat es ein Hacker oder Dieb, wenn die Zertifikate und Keys auf einer Cryptocard oder einem verschlüsselten USB-Stick gespeichert sind. Derartige Smartcards schützen den privaten Key: Sie verhindern ein Auslesen des Schlüssel und so auch das Erstellen jedweder Kopie. Für die Authentifizierung muss die IPsec-Software die relevanten Informationen an die Smartcard senden. Diese signiert die Daten und schickt sie zurück an die IPsec-Software, die sich damit beim Peer authentifiziert.

Die eingebaute Unterstützung für X.509-Zertifikate in der ersten, weit verbreiteten Linux-IPsec-Implementierung Freeswan hat Andreas Steffen [6] entwickelt, der (basierend auf dem Code des Freeswan-Projekts) später mit Strongswan auch eine der umfangreichsten, mächtigsten und verbreitetsten IPsec-Implementierungen in der Open-Source-Welt schuf.

Open SC, PCSC und der PKCS#11-Standard

Das Benutzen von einfachen Smartcards, die X.509-Zertifikate mit 1024- oder 2048-Bit-Schlüsseln nach dem PKCS#15-Standard [7] unterstützen, ist leicht: Zunächst installiert der Admin die notwendige Libraries, für die Unterstützung des Kartenlesers sind die Pcsc-Tools [8] und Open SC [9] erforderlich. Das Kürzel PCSC steht für den Personal Computer Smartcard Standard, den die meisten Lesegeräte unterstützen.

Auf Debian-Distributionen installiert der Administrator dazu die Pakete »pcsc-tools«, »libccid« und »opensc«. Open SC ist nötig, da Strongswan den PKCS#11-Standard [10] für die Kommunikation mit der Karte verwendet und das Softwarepaket diese Schnittstelle für die meisten üblichen Lesegeräte und Karten zur Verfügung stellt. Entgegen mancher Anleitung sollte der Admin das Open-CT-Paket [11] jedoch nicht installieren, denn es erweist sich als inkompatibel zum PCSC-/Open-SC-Paket und ist für zahlreiche Probleme verantwortlich und Gegenstand vieler Diskussionen auf den Mailinglisten.

01 $ opensc-tool -l
02 Readers known about:
03 Nr.   Driver   Name
04 0     pcsc     Broadcom 5801 Built-in (0123456789ABCD) 00 00

Direkt nach der Installation der Pakete und dem Start des PC/SC-Daemon (»pcscd«) sollte der Kartenleser einsatzbereit sein. Im Listing 1 nutzt der Admin den in aktuellen Dell-Latitude-Laptops eingebauten Kartenleser. Zeigt das Tool hier weitere Lesegeräte an oder erscheinen Fehlermeldungen bezüglich Open CT, hilft der Weg in die Konfigurationsdatei »/etc/opensc.conf«. Dort reicht der Eintrag »reader_drivers = pcsc;«. Ob der Leser die Karte erkennt, prüft anschließend »opensc-tool -n«:

$ opensc-tool -n
Using reader with a card: Broadcom 5801
 Built-in (0123456789ABCD) 00 00
Cryptoflex 8K

Nun lassen sich die Karte löschen, Schlüssel und Zertifikate erzeugen und auf den Datenträger übertragen. Hierzu nutzt der Admin »pkcs15-init«. Listing 2 zeigt die notwendigen Schritte.

01 # Löschen der Karte
02 pkcs15-init --use-default-transport-keys --erase-card
03 # Erzeugen der PKCS#15 Struktur
04 pkcs15-init --use-default-transport-keys --profile pkcs15+onepin
05 --create-pkcs15
06 # Erzeugung des sicheren Speichers
07 pkcs15-init --auth-id 1 --store-pin --label "VPN" --use-default-transport-keys
08 # Speicherung des privaten Schlüssels
09 pkcs15-init --auth-id 1 --store-private-key /etc/openvpn/hub_keys/laptop.key --id 45 --use-default-transport-keys
10 # Speicherung des Zertifikates
11 pkcs15-init --auth-id 1 --store-certificate /etc/openvpn/hub_keys/laptop.crt --id 45
12 # Überprüfung
13 pkcs15-tool --list-certificates --list-pins --list-keys

Für die Generierung der Schlüssel nutzt der Admin am besten PKI-Software wie Tinyca2 (Abbildung 1, [12]). Alternativ erzeugt auch der Befehl »pkcs15-init« mit der Option »–generate-key« den Schlüssel direkt auf der Karte. Diese Variante hat den Vorteil, dass der private Schlüssel nie die Karte verlässt und sich daher auch nicht kompromittieren lässt. Leider unterstützt nicht jede Smartcard diese Funktion.

Abbildung 1: Mit Tinyca2 legt der Admin komfortabel Zertifikate an, speichert und exportiert sie. Das GTK-Tool verwaltet auch Revoke-Listen mit widerrufenen Zugangsberechtigungen.

Strongswan konfigurieren

Damit Strongswan den privaten Schlüssel von der Karte liest, gilt es, die Konfiguration anzupassen. Strongswan verwaltet wie Openswan und Freeswan die VPN-Tunnel in der »ipsec.conf«. Diese Datei enthält für jeden VPN-Tunnel einen »conn«-Block:

conn vpn
  right=vpngw.spenneberg.net
  rightid=@vpngw.spenneberg.net
  left=%defaultroute
  leftcert=%smartcard
  auto=add

Jede Tunnelbeschreibung beginnt mit dem Schlüsselwort »conn« und einem willkürlichen, nur lokal bedeutsamen Namen. Strongswan nutzt diesen, um die verschiedenen Tunnel in der Administration zu unterscheiden.

Der Parameter »right« spezifiziert die IP-Adresse oder den DNS-Namen des VPN-Partners. Beide Kommunikationspartner authentifizieren sich mit privaten Schlüsseln und den jeweils zugehörigen Zertifikaten, »rightid« enthält die Identität des Partners. Die muss mit den Informationen aus dem Zertifikat übereinstimmen.

Damit der Admin bei Clients mit dynamischen IP-Adressen diese nicht jedes Mal ermitteln und die Konfigurationsdatei anpassen muss, weist er mit dem Parameter »%defaultroute« Strongswan an, automatisch die IP-Adresse zu nutzen, über die das System sein Default-Gateway erreicht. Für die Authentifizierung braucht Strongswan noch das eigene Zertifikat und den zugehörigen Schlüssel. Statt einer Datei gibt der Admin hier den Parameter »%smartcard« an.

Jetzt greift Strongswan auf das erste Schlüsselpaar auf der Smartcard zu. Sind mehrere vorhanden, listet Strongswan diese mit dem Befehl »ipsec listcards« auf. Der Admin kann dann das richtige Paar auswählen. Durch die Angabe von »auto=add« startet Strongswan den Tunnel nicht automatisch, sondern wartet auf die Aufforderung durch den Anwender mit »ipsec up vpn«.

Da die meisten Smartcards mit einem PIN-Code geschützt sind, muss auch Strongswan diese PIN beim Zugriff auf die Smartcard übertragen. Entweder der Anwender trägt den PIN-Code fest in die Datei »ipsec-secrets« ein oder Strongswan fragt ihn bei dem Start des Tunnels. Im ersten Fall enthält die Datei folgende Zeile:

: PIN %smartcard "1111"

Im zweiten Fall trägt der Anwender stattdessen ein:

: PIN %smartcard %prompt

Falls das Smartcard-Lesegerät über ein eigenes PIN-Pad verfügt, kann Strongswan auch dies nutzen:

: PIN %smartcard %pinpad

In diesem Fall sollte der Admin zusätzlich die Option »pkcs11keepstate=yes« setzen. Ansonsten muss der Benutzer die PIN bei jeder erneuten Verlängerung des Tunnels eingeben, weil der Reader die PIN nicht zwischenspeichert.

Geht noch nicht: Die Open-PGP-Smartcard

Strongswan benötigt für den Zugriff auf die Smartcard einen PKCS#11-Provider. Peter Koch stellt auf seiner Webseite [13] eine binäre Bibliothek in einer Debugversion zur Verfügung. Er hat diese Bibliothek für den Zugriff von Firefox auf die Open-PGP-Smartcard und damit auch den Cryptostick entwickelt. Leider scheitert das Zusammenspiel mit Strongswan noch, der Entwickler erwägt aber auch eine Erweiterung für IPsec.

Wenn diese funktioniert, läuft das Ganze so: Die Bibliothek benötigt für das Lesen vom Cryptostick den Pcscd-Daemon. Debian-Lenny-Anwender installieren das Paket »pcscd« mit allen Abhängigkeiten. Weil darin die passenden Treiber für den Cryptostick nicht enthalten sind, sind von [14] noch die passenden Pakete für Lenny oder Ubuntu nötig.

Admins sollten die Pakete »cryptostick_ 1.0_all« und »lenny-libccid_1.3.8-1+cryptostick1_i386« installieren, sie enthalten eine Udev-Regel und einen aktualisierten Pcsclite-Treiber. Ist anschließend der Pcscd neu gestartet, gelingt es, auch den Cryptostick mit dem Pkcs11tool anzusprechen (Abbildung 2). Ein neuer Cryptostick hat als PIN 123456. Auf einem leeren Stick sind jedoch noch keine Objekte (Abbildung 3).

Abbildung 2: Den Open-PGP-Cryptostick sollte IPsec über die PKCS#11-Schnittstelle ansprechen, doch leider fehlt dafür noch das passende PKCS#11-Modul für IPsec.

Abbildung 3: Pkcs11tool kann bei Eingabe der PIN auch die Objekte anzeigen.

Neue Keys nur mit Windows

Auch die Schlüssel kann ein Linux-System leider noch nicht mit dem Pkcs11-Tool erzeugen. Hierzu benötigt der Admin Zugriff auf ein Windows-System, wo er mit der entsprechenden Windows-PKCS11-DLL von [13] die privaten Schlüssel und Zertifikate anfertigt. Für die Verwendung mit Strongswan bindet die folgende Direktive in der Datei »ipsec.conf« das PKCS11-Provider-Modul ein:

config setup
  pkcs11module=/usr/lib/libOpenPGP11.so

Jetzt sollte Strongswan die Smartcard und Schlüssel mit »ipsec listcards« anzeigen.

Mehr Sicherheit

Ein Angreifer kann von dem vorgestellten Setup die Schlüssel nicht ohne Wissen des Benutzers stehlen, er müsste die Karte oder den Stick entwenden und braucht auch noch die passende PIN. Deshalb sollte ein Client diese nicht in der Datei »ipsec.secrets« speichern, sondern sie vom Anwender bei jeder Verwendung erneut einfordern. (mfe)