Linux VPN HOWTO: Verschlüsselungsarten

Das Kapitel 1 Einführung sollte unbedingt gelesen werden, da hier u.a. die Hintergründe erklärt und das in den Beispielen benutzte Netzwerk beschrieben werden.

IPSEC (Internet Protocol SECurity) ist, wie schon in der Einführung erwähnt, die Norm für authentifizierten und vertraulichen Datenaustausch im Internet auf IP-Ebene. Authentifizierungbedeutet, man kann gewährleisten, dass ein IP-Paket von dem Absender stammt, von dem es behauptet (im Authentication-Header - AH) zu kommen. Vertraulichkeit heißt, dass nur der Empfänger (also noch nicht einmal der Versender!) die Daten des IP-Pakets entschlüsseln kann.

Für die Authentifizierung wird der Authentication Header, ein Feld, das zwischen den bisherigen IP-Header und die bisherigen Nutzdaten geschoben wird benutzt. Bei einer Gateway-to-Gateway-Kommunikation (G2G), wird vom einen VPN-Gateway das gesamte Paket genommen und in ein neues verschlüsseltes ESP-Paket (Encapsulated Security Payload) verpackt und auf der Gegenseite wieder entpackt (Tunnel) OFFEN - stimmt da so?. Ein Hacker sieht damit nur noch Pakete zwischen zwei Gateways laufen, nicht jedoch die tatsächlichen Quell- und Zieladressen oder die Daten - denn die 'echten' Pakete wurden in die anderen Paketen verpackt.

Man unterscheidet zwischen symmetrischer und asymmetrischer Verschlüsselung. Bei symmetrischer Verschlüsselung werden Daten mit demselben Schlüssel ver- und entschlüsselt. Bei asymmetrischer Verschlüsselung wird mit dem den Public Key verschlüsselt und mit dem Private Key entschlüsselt. Der Vorteil der symmetrischen Verschlüsselung ist die Geschwindigkeit. Das Ver- und Entschlüsseln dauert im Gegensatz zur Asymmetrischen deutlich weniger lang, da der Schlüssel schon ab 90 Bit als sicher gilt - der Asymetrische sollte mindestens 1024 Bit lang sein. Der Nachteil ist, der gegenseitige Schlüsselaustausch. Und wenn jemand an den Schlüssel kommt, kann er alles entschlüsseln. Bei asymmetrischer Verschlüsselung kann jeder den Public Key kennen - er dient ja nur zum Verschlüsseln. Das Entschlüsseln ist mit diesem nicht möglich. Allerdings dauert die Ver- und Entschlüsselung länger als bei der Symmetrischen.
Der VPN-Gateway übernimmt die Authentifizierung der Gegenstelle und Verschlüsselung der Daten. Am besten eignet sich hierzu das Public-Key-Verfahren. FreeS/WAN benutzt dazu standardmäßig RSA-Keys. Clients mit Windows 2000 oder XP können hiermit jedoch nichts anfangen und erwarten ein vollwertiges X.509-Zertifikat.

3.1 RSA

Wenn man nur Linux-Linux-Verbindungen herstellen will und ein sicherer Schlüsselaustausch gewährleistet ist reicht eine RSA-Verschlüsselung (Windows-Clients unterstützen nur X.509-Zertifikate!). Hierbei wird für beide VPN-Gateways je ein Private- und ein Public-RSA-Key erstellt. Dieser sollte mindestens eine Länge von 1024 Bit haben. Der Private-Key muß dann später in die Datei ipsec.secrets und der Public Key in die ipsec.conf eingetragen werden.

3.1.1 RSA generieren

Um einen Private- und Public-RSA-Key zu generieren kann man das Tool rsasigkey benutzen:

# Erstellt einen 1024 Bit RSA-Key und
# leitet ihn in eine Datei um
ipsec rsasigkey 1024 > rsa.zentrale
.
.
# oder mit Hostnamen:
ipsec rsasigkey 1024 --hostname zweigstelle > rsa.zweigstelle

In der Datei rsa.zentrale befinden sich nun ein auskommentierter Public Key und der Private Key. In der ersten Zeile stehen als Information die Länge und der Name des Keys. Hier ein Beispiel:

# RSA 1024 bits   zentrale   Sat Jun 28 11:27:41 2003
# for signatures only, UNSAFE FOR ENCRYPTION
#pubkey=0sAQPw2Dwc21EwObP/ROdqJpKpiTzY+dofMj3CmMZ80aeDkO...
#IN KEY 0x4200 4 1 AQPw2Dwc21EwObP/ROdqJpKpiTzY+dofMj3Cm...
# (0x4200 = auth-only host-level, 4 = IPSec, 1 = RSA)
Modulus: 0xf0d83c1cdb513039b3ff44e76a2692a9893cd8f9da1f3...
PublicExponent: 0x03
# everything after this point is secret
PrivateExponent: 0x28240a04cf3832b448aa8b7be7066dc6ec34c...
Prime1: 0xfc561fe98e02f4230cebf6b27915a92a1943f659e740e1...
Prime2: 0xf45765e2ab6bcef6ac64415fca0e66ea805ca34ec78cd0...
Exponent1: 0xa8396a9bb401f8175df2a476fb63c61c10d7f99144d...
Exponent2: 0xa2e4ee971cf289f9c842d63fdc0999f1aae86cdf2fb...
Coefficient: 0x926239dbc46303f8af89b2168945b5485efc4630c...

3.2 X.509-Zertifikate

Anm.: Wer nur RSA-Verschlüsselung benutzen will kann dieses Kapitel überspringen.

Das Problem bei einem Public Key ist, dass man (manchmal) nicht genau weiß ob der Key wirklich von demjenigen stammt, dessen Name er trägt. Hier kommen nun die Zertifikate zum Zug. Ein Zertifikat ist ein Public Key, bei dem eine Zertifizierungsstelle (Certification Authority - CA) mit ihrer digitalen Unterschrift bestätigt, dass die angegebene Identität korrekt ist. Speziell hierzu haben sich die X.509-Zertifikate etabliert (standardisiert von der International Telecommunications Union (ITU) und der ISO). Ein X.509-Zertifikat beinhaltet die Identität in Form eines ‘X.500 Distinguished Name’ (DN), einen Public Key und die digitale Signatur einer X.509 Certification Authority (CA).

Beispiel für den Distinguished Name:

Distinguished Name: 'C=DE, O=rf Software GmbH, OU=Zentrale, CN=zentrale@rf-software.de'

enthält das Land 'DE'
die Organisation 'rf Software GmbH'
ein Abteilungsname (OU) 'Zentrale'
und als Common Name (CN) die E-Mail-Adresse 'zentrale@rf-software.de'
Optional: u.a. das Bundesland (ST) oder eine Ortsbezeichnung (L)

der Name sollte so ausführlich wie möglich sein - um Verwechselungen zu vermeiden.

Bei Aufbau einer Verbindung werden zunächst die Zertifikate der Gegenstellen ausgetauscht und anhand der CA überprüft. Ist alles korrekt, kann der VPN-Gateway sicher sein, dass der jeweils enthaltene Public-Key sicher ist.

Anm.: Zum Erstellen der Zertifikate habe ich verschiedene Scripte angefügt die u.a. aus einem Artikel der Zeitschrift c't stammen (mit Erlaubnis des Authors Jürgen Schmidt :) ). Ich habe diese leicht überarbeitet bzw. mit Kommentaren versehen und an die Howto angepasst. Es müssen also nicht alle Befehle die nun beschrieben werden auch von Hand eingegeben werden (außer 3.2.1). Die Skripte erstellen jedoch nur die Zertifikate - kopieren muß man sie von Hand.

3.2.1 Zertifikate generieren - OpenSSL

X.509-Zertifikate kann man von einer Fremdfirma ausstellen lassen oder auch mit Hilfe von OpenSSL eine eigene Zertifizierungsstelle (Certification Authority - CA) erstellen und sie dann selbst generieren. Vorab sollte man sich jedoch folgende Verzeichnisstruktur im Zielverzeichnis der Zertifikate erstellen damit in dieser die selbst erstellten Zertifikate abgelegt werden können (siehe auch openssl.conf; bei Benutzung der Scripte ist dies nicht notwendig). Ich benutze als Zielpfad für die CA das Verzeichnis /usr/ssl:

Vor der Erstellung der eigenen CA sollte man noch die Datei openssl.conf in /usr/ssl/ kopieren und muß diese ein evtl. wenig anpassen. Hier ein Auszug:

[ CA_default ]

dir		= /usr/ssl		# Zielverzeichnis der CA
.
.
[ policy_match ]
countryName		= match
localityName		= optional
organizationName	= supplied
organizationalUnitName	= optional
commonName		= supplied
.
.
[ req_distinguished_name ]
countryName			= Country Name (2 letter code)
countryName_default		= DE
countryName_min			= 2
countryName_max			= 2
.
.
0.organizationName		= Organization Name (eg, company)
0.organizationName_default	= rf Software GmbH
.
.

3.2.2 Eigene Certification Authority - CA

Die eigene CA benötigt einen möglichst 2048 Bit langen RSA Private Key (cakey.pem), der mit einer Passphrase (-des3) geschützt werden sollte - damit niemand außer dem der diese Passphrase kennt Zertifikate erstellen kann. Danach wird mit diesem Key ein CA-Root-Zertifikat (cacert.pem) erstellt. Mit diesem Zertifikat werden später die Zertifikate 'unterschrieben' bzw. beglaubigt.
Dann kann man im Zielverzeichnis der Zertifikate das CA-Root-Zertifikat erstellen:

# 2048 Bit langer Private Key:
openssl genrsa -des3 -out private/cakey.pem 2048

# Root CA-Zertifikat mit 4 Jahren Gültigkeit
openssl req -new -x509 -days 1460 -key private/cakey.pem -out cacert.pem 

# Überprüfung (zeigt den Schlüssel in lesbarer Form an)
openssl x509 -in cacert.pem -noout -text

Das CA-Root-Zertifikat mit dem Namen cacert.pem muss in das Verzeichnis /etc/ipsec.d/cacerts/ kopiert werden. Anm.: dieser Schritt ist natürlich nur einmal notwendig.

Ein Script zur Erstellung einer CA ist hier zu finden (Script 'make_ca')

3.2.3 Eigene Zertifikate

Nach der Einrichtung einer eigenen CA kann man für die VPN-Gateways und Roadwarrios eigene Zertifikate erstellen. D.h. für die Linux-Linux-Verbindung wird ein Zertifikat für die Zentrale und eins für die Zweigstelle erstellt.
Man benötigt zuerst einen RSA Private Key (im Beispiel ZweigstelleKey.pem). Dieser sollte auch mit dem Parameter '-des3' per Passphrase geschützt werden. Diese muß später in der Datei /etc/ipsec.secrets zusätzlich mit angegeben werden. Dann wird mit diesem RSA-Key eine Anfrage auf ein Zertifikat (Certificate Request) erstellt. Diese Anfrage wird von der CA 'unterschrieben' und damit beglaubigt:

# 1024 Bit langer Private Key:
openssl genrsa -des3 -out private/ZweigstelleKey.pem 1024

# Antrag auf ein Zertifikat erstellen OFFEN index.txt
openssl req -new -key private/ZweigstelleKey.pem -out ZweigstelleReq.pem

# Zertifikat 'unterschreiben'
openssl ca -notext -in ZweigstelleReq.pem -out ZweigstelleCert.pem

# bei Linux muss das Zertifikat auch in binärem DER-Format vorliegen (OFFEN)
#openssl x509 -in ZweigstelleCert.pem -outform der -out x509cert.der 

# und noch ein Windows-Konformes Zertifikat (Zweigstelle.p12)
#openssl pkcs12 -export -in ZweigstelleCert.pem -inkey private/ZweigstelleKey.pem -ce

Der Private Key (ZweigstelleKey.pem) eines Zertifikates muss auf dem entsprechenden Rechner nach /etc/ipsec.d/private/ kopiert werden. In die Datei /etc/ipsec.secrets muss man den Dateinamen des Private Key sowie gegebenenfalls die Passphrase eintragen:

 : RSA ZweigstelleKey.pem "Passphrase"

Ein Eintrag endet immer mit einer Leerzeile (siehe auch ipsec.secrets)!

Das Zertifikat (Public Key - ZweigstelleCert.pem) sollte auf beiden Rechnern unter /etc/ipsec.d abgelegt werden. D.h. auf der Zentrale und der Zweigstelle liegen später beide Zertifikate (dies ist je nach Konfiguration notwendig - OFFEN). Das Importieren von Windows-Zertifikaten wird hier beschrieben.
Beim Erstellen der Zertifikate per Skript können diese gleich in Archive (Linux: tgz, Windows: zip) verpackt werden. Die Namen werden dann in der Datei index.txt eingetragen. Eine Kopie des Zertifikats liegt unter ./newcerts - allerdings als ist die Bezeichnung eine laufende Nummer (01.pem, 02.pem, usw.). Die Zuordnung welche Kopie zu welchem Zertifikat gehört sateht ebenfalls in der Datei index.txt.

Auf das Verzeichnis /etc/ipsec.d/private/ und die Datei /etc/ipsec.secrets darf nur der Benutzer root Zugriffsrechte besitzen!

Ein Script zur Erstellung einer CA ist hier zu finden (Script 'make_cert NAME'; als Parameter (NAME) wird der Name des Zertifikats übergeben )

3.2.4 Certificate Revocation List - CRL

Die CRL ist eine Widerrufliste in der die ungültigen Zertifikate eingetragen sind und Zugänge aufgehoben werden können (z.B. beim Ausscheiden eines Mitarbeiters). Dazu wird periodisch eine gültige CRL erstellt. Einzelne Zertifikate können dann manuell entfernt werden. Die Sperrung erfolgt dann beim nächsten Anlegen der Liste. Daher sollte die Liste entweder sofort nach deaktivieren eines Zertifikats oder, je nach Dringlichkeit, täglich oder wöchentlich per Cronjob erstellt werden.

# gültige CRL erstellen
openssl ca -gencrl -out crls/crl.pem

# das Zertifikat von 'meier' entfernen
openssl ca -revoke meiercert.pem  # oder 'openssl ca -revoke ./newcerts/03.pem'

# Nummern der gesperrten Zertifikate anzeigen
openssl crl -in crls/crl.pem -noout -text

# CRL in das binäre DER-Format umwandeln
openssl crl -in crls/crl.pem -outform der -out crls/cert.crl

Die Datei ./crls/crl.pem muß nach /etc/ipsec.d/crls/ kopiert werden.

Ein Script zur Erstellung einer CA ist hier zu finden (Script 'make_crl')

3.3 Zertifikate austauschen

Die unter 3.2.3 erstellten Zertifikate (je nach System die Datei Zweigstelle.tgz oder Roadworrio.zip) sollten auf sichere Art auf das Zielsystem übertragen werden (also per eMail ;) ) und dort in einem sicheren Verzeichnis gespeichert werden.

3.3.1 Linux

Die Ablage der Dateien bei Linux-Rechnern wurde in den obigen Punkten bereits erwähnt. Hier jedoch noch einmal eine Zusammenfassung:

VPN-Gateway (mit CA):

CA-Root-Zertifikat	/etc/ipsec.d/cacerts	(Datei 'cacert.pem')
CRL-Liste		/etc/ipsec.d/crls	(Datei 'crl.pem')
Private Key		/etc/ipsec.d/private	(Datei 'ZentraleKey.pem')
Zertifikate		/etc/ipsec.d		(Dateien 'ZentraleCert.pem' & 'ZweigstelleCert.pem')

VPN-Gateway/ -Client:

Private Key		/etc/ipsec.d/private	(Datei 'ZweigstelleKey.pem)	
Zertifikate		/etc/ipsec.d		(Dateien 'ZentraleCert.pem' & 'ZweigstelleCert.pem')

Ein Beispiel für die Konfiguration einer Verbindung zwischen zwei Linux-Gateways mit Zertifikaten ist hier zu finden.

3.3.2 Windows 2000/XP

Der Zugang mit Windows ist nur per X.509-Zertifikaten möglich! Man kann dieses mit der Microsoft Management Console (mmc) wie folgt importieren:

Startmenü Start -> Ausführen
Eingabe mmc und OK klicken
Menü Konsole -> Snap-In hinzufügen/entfernen
Klick auf Hinzufügen
Auswahl Zertifikate und Hinzufügen klicken
Auswahl Computerkonto und Weiter klicken
Auswahl Lokalen Computer: (...) und Fertig stellen klicken
Klick auf Schließen
Klick auf OK

Diesen Ablauf kann man unter Konsole -> Speichern unter abspeichern und bei späterem Gebrauch über Konsole -> Öffnen wieder laden. Nun kann das eigentliche Zertifikat installiert werden:

Öffnen des Zweiges Zertifikate (Lokaler Computer) in der MMC
mit der rechten Maustaste auf Eigene Zertifikate klicken und Alle Tasks -> Importieren ... wählen
mit dem Zertifikatsimport-Assistenten kann nun die *.p12 *.pfx Datei importiert werden

Ein Beispiel für die Konfiguration einer Verbindung zwischen einem Linux-Gateway und eines Roadwarriors mit Windows als Betriebssystem ist hier zu finden.

3. Verschlüsselungsarten