Systemverwaltungshandbuch: IP Services

Kapitel 22 Internet Key Exchange (Übersicht)

Internet Key Exchange (IKE) automatisiert das Schlüsselmanagement für IPsec. Dieses Kapitel enthält die folgenden Informationen zum IKE:

Anweisungen zur Implementierung von IKE finden Sie in Kapitel 23Konfiguration von IKE (Aufgaben). Referenzinformationen finden Sie in Kapitel 24Internet Key Exchange (Referenz). Referenzinformationen zu IPsec finden Sie in Kapitel 19IP Security Architecture (Übersicht).

Neuerungen bei IKE

Solaris 10 4/09: Ab dieser Version wird IKE in der Service Management Facility (SMF) als Service verwaltet. Standardmäßig ist der Service svc:/network/ipsec/ike:default deaktiviert. Ebenfalls in dieser Version wird das Rechteprofil für das Netzwerk-IPsec-Management (zur Verwaltung von IPsec und IKE) bereitgestellt.

Solaris 10 7/07: Ab diesem Release kann IKE den AES-Algorithmus benutzen und in der globalen Zone für die Verwendung in nicht-globalen Zonen konfiguriert werden.

Mit der Socket-Option SO_ALLZONES kann IKE Datenverkehr in nicht-globalen Zonen verarbeitet werden.
Eine vollständige Liste der neuen Funktionen in Solaris sowie eine Beschreibung der Solaris-Versionen finden Sie in Neuerungen in Oracle Solaris 9 10/10.

Schlüsselmanagement mit IKE

Die Verwaltung des Schlüsselmaterials für IPsec-Sicherheitszuordnungen (SAs) wird als Schlüsselmanagement bezeichnet. Für das automatische Schlüsselmanagement ist ein sicherer Kommunikationskanal erforderlich, damit Schlüsseln ordnungsgemäß erstellt, authentifiziert und ausgetauscht werden können. Das Solaris OS verwendet Internet Key Exchange (IKE) zum automatischen Schlüsselmanagement. IKE lässt sich mit einfachen Mitteln skalieren, um einen sicheren Kanal für hohen Datenverkehr bereitzustellen. IPsec SAs für IPv4- und IPv6-Pakete können von den Vorteilen von IKE profitieren.

Wird IKE auf einem System mit einem Sun Crypto Accelerator 1000-, einem Sun Crypto Accelerator 4000-oder einem Sun Crypto Accelerator 6000-Board betrieben, können die öffentlichen Schlüsselvorgänge an den Beschleuniger abgegeben werden. Die Betriebssystemressourcen werden dann nicht für PublicKey-Vorgänge genutzt. Wird IKE auf einem System mit einem Sun Crypto Accelerator 4000 oder einem Sun Crypto Accelerator 6000-Board verwendet, können die Zertifikate, Public Keys und Private Keys auf dem Board gespeichert werden. Die Schlüsselspeicherung findet außerhalb des Systems statt, um für eine zusätzliche Sicherheitsschicht zu sorgen.

IKE-Schlüsselaushandlung

Der IKE-Daemon in.iked sorgt für eine sichere Aushandlung und Authentifizierung des Schlüsselmaterials für SAs. Der Daemon verwendet Zufalls-Seeds für Schlüssel aus internen Funktionen, die von Solaris OS bereitgestellt werden. IKE bietet umfassende Sicherheit bei Weiterleitungen (PFS, Perfect Forward Secrecy). Bei PFS können die Schlüssel, mit denen die Datenübertragung geschützt wird, nicht zum Ableiten von weiteren Schlüsseln verwendet werden. Außerdem können Seeds, die zum Erstellen von Datenübertragungsschlüsseln verwendet werden, nicht wieder verwendet werden. Weitere Informationen finden Sie in der Manpage in.iked(1M).

Wenn der IKE-Daemon einen öffentlichen Chiffrierschlüssel eines Remote-Systems erfasst, kann das lokale System diesen Schlüssel verwenden. Das System verschlüsselt Nachrichten mithilfe des öffentlichen Schlüssels des Remote-Systems. Die Nachrichten können nur von diesem Remote-System gelesen werden. Der IKE-Daemon arbeitet in zwei Stufen. Diese Stufen werden als exchanges (Austauschvorgänge) bezeichnet.

IKE-Schlüssel – Terminologie

In der folgenden Tabelle sind Begriffe aufgeführt, die bei der Schlüsselaushandlung verwendet werden. Darüber hinaus sind Akronyme, Erklärungen und Verwendungsmöglichkeiten für jeden Begriff angegeben.

Tabelle 22–1 Begriffe, Akronyme und Verwendungsmöglichkeiten bei der Schlüsselaushandlung


Begriff	Acronym	Definition und Verwendung
Key Exchange		Der Prozess zum Erzeugen von Schlüsseln für asymmetrische kryptografische Algorithmen. Die zwei wichtigsten Methoden sind die RSA-Protokolle und das Diffie-Hellman-Protokoll.
Diffie-Hellman- Protokoll	DH	Ein Key Exchange-Protokoll zur Erzeugung und Authentifizierung von Schlüsseln. Wird häufig auch als authentifizierter Schlüsselaustausch bezeichnet.
RSA-Protokoll	RSA	Ein Key Exchange-Protokoll zur Erzeugung und Verteilung von Schlüsseln. Das Protokoll ist nach seinen drei Autoren Rivest, Shamir und Adleman benannt.
Perfect Forward Secrecy	PFS	Gilt nur für authentifizierten Schlüsselaustausch. PFS stellt sicher, dass sich langfristig sicheres Schlüsselmaterial nicht negativ auf die Geheimhaltung von Schlüsseln auswirkt, die bei früheren Kommunikationen ausgetauscht wurden. Bei PFS kann der Schlüssel, der zum Schützen der Datenübertragung verwendet wird, nicht zum Ableiten weiterer Schlüssel verwendet werden. Außerdem wird die Quelle des Schlüssels, der zum Schützen von Datenübertragungen verwendet wird, niemals zum Ableiten weiterer Schlüssel verwendet.
Oakley-Methode		Eine Methode zum sicheren Erstellen der Schlüssel für Stufe 2. Das Protokoll ist analog zur Diffie-Hellman-Methode beim Key Exchange. Wie Diffie-Hellman führt der Schlüsselaustausch der Oakley-Methode Schlüsselerzeugung und Schlüsselauthentifizierung aus. Die Oakley-Methode dient zur Aushandlung von PFS.

IKE Phase 1 Exchange

Der Phase 1 Exchange wird als Hauptmodus bezeichnet. Im Phase 1 Exchange verwendet IKE Verschlüsselungsmethoden mit öffentlichem Schlüssel, um sich selbst gegenüber IKE-Peer- Entitäten zu authentifizieren. Das Ergebnis ist eine Internet Security Association and Key Management Protocol (ISAKMP)-Sicherheitszuordnung (SA). Eine ISAKMP SA ist ein sicherer Kanal für IKE zur Aushandlung des Schlüsselmaterials für IP-Datagramme. Im Gegensatz zu IPsec SAs sind ISAKMP SAs bidirektional, daher wird nur eine Sicherheitszuordnung benötigt.

Das Verfahren zur Aushandlung des Schlüsselmaterials durch IKE beim Phase 1 Exchange kann konfiguriert werden. IKE liest die Konfigurationsinformationen in der Datei /etc/inet/ike/config ein. Die Konfigurationsinformationen umfassen Folgendes:

Globale Parameter, z. B. die Namen der öffentlichen Schlüsselzertifikate
Ob Perfect Forward Secrecy (PFS) verwendet wird
Die betroffenen Schnittstellen
Die Sicherheitsprotokolle und deren Algorithmen
Die Authentifizierungsmethode

Die zwei Authentifizierungsmethoden sind PresharedKeys und PublicKey-Zertifikate. Die PublicKey-Zertifikate können selbst-signiert sein. Die Zertifikate können auch von einer Zertifizierungsstelle (Certificate authority, CA), einer PublicKey-Infrastruktur (PKI)-Organisation ausgegeben werden. Diese Organisationen sind z. B. beTrusted, Entrust, GeoTrust, RSA Security und Verisign.

IKE Phase 2 Exchange

Der Phase 2 Exchange wird als Schnellmodus bezeichnet. Beim Phase 2 Exchange erstellt und verwaltet IKE die IPsec SAs zwischen Systemen, die den IKE-Daemon ausführen. IKE verwendet den sicheren Kanal, der in Phase 1 erstellt wurde, für den Schutz der Übertragung des Schlüsselmaterials. Der IKE-Daemon erstellt die Schlüssel mithilfe des Geräts /dev/random aus einem Zufallszahlengenerator. Der Daemon aktualisiert die Schlüssel in einem konfigurierbaren Intervall. Das Schlüsselmaterial steht Algorithmen zur Verfügung, die in der Konfigurationsdatei für die IPsec-Richtlinie, ipsecinit.conf, angegeben sind.

IKE-Konfigurationsmöglichkeiten

Die Konfigurationsdatei /etc/inet/ike/config enthält Einträge für die IKE-Richtlinie. Damit zwei IKE-Daemons einander authentifizieren, müssen die Einträge gültig sein und das Schlüsselmaterial muss zur Verfügung stehen. Die Einträge in der Konfigurationsdatei bestimmen die Methode, in der das Schlüsselmaterial zur Authentifizierung des Phase 1 Exchange verwendet wird. Die Auswahlmöglichkeiten sind PresharedKeys oder PublicKey-Zertifikate.

Der Eintrag auth_method preshared legt fest, dass PresharedKeys verwendet werden. Andere Werte als preshared für auth_method kennzeichnen, dass PublicKey-Zertifikate verwendet werden. PublicKey-Zertifikate können selbst-signiert sein oder die Zertifikate können von einer PKI-Organisation installiert werden. Weitere Informationen finden Sie in der Manpage ike.config(4).

IKE mit PresharedKeys

PresharedKeys werden von einem Administrator auf einem System erstellt. Die Schlüssel werden dann außerbandig an die Administratoren der remoten Systeme weitergegeben. Achten Sie darauf, umfangreiche Zufallsschlüssel zu erzeugen und die Datei sowie die außerbandige Übertragung zu schützen. Die Schlüssel werden auf jedem System in der Datei /etc/inet/secret/ike.preshared abgelegt. Die Datei ike.preshared gilt für IKE , die Datei ipseckeys für IPsec. Eine Sicherheitsgefährdung der Schlüssel in der Datei ike.preshared gefährdet alle Schlüssel, die von den Schlüsseln in dieser Datei abgeleitet sind.

Ein Preshared-Schlüssel eines Systems muss identisch mit dem Schlüssel seines remoten Systems sein. Die Schlüssel sind an eine bestimmte IP-Adresse gebunden. Die Schlüssel sind am sichersten, wenn ein Administrator die kommunizierenden Systeme verwaltet. Weitere Informationen finden Sie in der Manpage ike.preshared(4).

IKE mit PublicKey-Zertifikaten

Mit PublicKey-Zertifikaten müssen kommunizierende Systeme kein geheimes außerbandiges Schlüsselmaterial mehr verwenden. PublicKeys verwenden das Diffie-Hellman-Protokoll (DH) zur Authentifizierung und Aushandlung von Schlüsseln. PublicKey-Zertifikate gibt es in zwei Ausführungen. Die Zertifikate können selbst-signiert sein, oder sie werden von einer Zertifizierungsstelle (Certificate authority, CA) zertifiziert.

Selbst-signierte PublicKey-Zertifikate werden von Ihnen, dem Administrator, erstellt. Mit dem Befehl ikecert certlocal -ks erstellen Sie den privaten Teil eines PublicKey-PrivateKey-Paars für das System. Dann erhalten Sie die selbst-signierte Zertifikatsausgabe im X.509-Format vom remoten System. Das Zertifikat des remoten Systems wird als öffentlicher Teil des Key-Paars in den Befehl ikecert certdb eingegeben. Die selbst-resignierten Zertifikate befinden sich in dem Verzeichnis /etc/inet/ike/publickeys der kommunizierenden Systeme. Wenn Sie die Option -T verwenden, befinden sich die Zertifikate auf einer angehängten Hardware.

Selbst-designierte Zertifikate stellen einen Kompromiss zwischen PresharedKeys und CAs dar. Im Gegensatz zu PresharedKeys kann ein selbst-signiertes Zertifikat auf einem mobilen Computer oder auf einem System verwendet werden, das neu nummeriert werden kann. Um ein Zertifikat für ein System ohne feststehende Nummer selbst zu signieren, verwenden Sie einen alternativen DNS-Namen (www.example.org) oder email (root@domain.org).

PublicKeys können von einer PK- oder einer CA-Organisation erstellt werden. Sie installieren die PublicKeys und deren begleitenden CAs im Verzeichnis /etc/inet/ike/publickeys. Wenn Sie die Option -T verwenden, befinden sich die Zertifikate auf einer angehängten Hardware. Anbieter veröffentlichen auch Listen der zurückgenommenen Zertifikate (Certificate Revocation-Lists, CRLs). Neben den Schlüsseln und CAs müssen Sie als Administrator auch die CRL im Verzeichnis /etc/inet/ike/crls installieren.

CAs haben den Vorteil, dass sie von einer außenstehenden Organisation und nicht vom Standort-Administrator zertifiziert werden. In gewisser Hinsicht sind CAs notariell beglaubigte Zertifikate. Wie auch selbst-signierte Zertifikate können CAs auf einem mobilen Computer oder auf einem System verwendet werden, dass neu nummeriert werden kann. Im Gegensatz zu selbst-signierten Zertifikaten können CAs leicht skaliert werden, um zahlreiche miteinander kommunizierende Systeme zu schützen.

IKE und Hardwarebeschleunigung

IKE-Algorithmen erfordern umfangreiche Berechnungen, insbesondere beim Phase 1 Exchange. Systeme, die zahlreiche Austauschvorgänge verarbeiten müssen, sollten ein Sun Crypto Accelerator 1000-Board zur Verarbeitung der PublicKey-Vorgänge verwenden. Die Sun Crypto Accelerator 6000- und Sun Crypto Accelerator 4000-Boards können auch für teuere Phase 1-Berechnungen verwendet werden.

Weitere Informationen, wie Sie IKE zum Ausführen der Berechnungen auf dem Beschleunigerboard konfigurieren, finden Sie unter So konfigurieren Sie IKE zur Suche nach dem Sun Crypto Accelerator 1000-Board. Informationen zum Speichern von Schlüsseln finden Sie unterSo konfigurieren Sie IKE zur Suche nach dem Sun Crypto Accelerator 4000-Board und in der Manpage cryptoadm(1M).

IKE und Hardware-Speicherung

Public Key-Zertifikate, Private Keys und Public Keys können auf einem Sun Crypto Accelerator 6000- oder einem Sun Crypto Accelerator 4000-Board gespeichert werden. Bei der RSA-Verschlüsselung unterstützt das Sun Crypto Accelerator 4000-Board Schlüssel bis zu einer Länge von 2048 Bit. Bei der DSA-Verschlüsselung unterstützt das Board Schlüssel bis zu einer Länge von 1024 Bit. Das Sun Crypto Accelerator 6000-Board unterstützt die SHA-512- und ECC-Algorithmen.

Informationen zur Konfiguration von IKE für den Zugriff auf das Board finden Sie unter So konfigurieren Sie IKE zur Suche nach dem Sun Crypto Accelerator 1000-Board. Informationen zum Hinzufügen von Zertifikaten und PublicKeys zum Board finden Sie unter So erzeugen Sie PublicKey-Zertifikate und speichern sie auf angehängter Hardware.

IKE-Dienstprogramme und Dateien

In der folgenden Tabelle sind die Konfigurationsdateien für die IKE-Richtlinie, die Speicherorte für IKE-Schlüssel und die verschiedenen IKE-Befehle und -Services zusammengefasst. Weitere Informationen zu Services finden Sie in Kapitel 18, Managing Services (Overview) in System Administration Guide: Basic Administration.

Tabelle 22–2 IKE-Konfigurationsdateien, Speicherorte für Schlüssel, Befehle und Services


Datei, Speicherort, Befehl oder Service	Beschreibung	Weitere Informationen
`svc:/network/ipsec/ike`	Der SMF-Service, der in der aktuellen Version die IKE-Verwaltung übernimmt.	smf(5)
`/usr/lib/inet/in.iked`-Daemon	Internet Key Exchange (IKE)-Daemon. Aktiviert die automatisierte Schlüsselverwaltung. In der aktuellen Version wird dieser Daemon durch den `ike`-Service aktiviert. In älteren Versionen wird der `in.iked`-Befehl verwendet.	in.iked(1M)
`/usr/sbin/ikeadm`-Befehl	IKE-Verwaltungsbefehl zum Anzeigen und Ändern der IKE-Richtlinie.	ikeadm(1M)
`/usr/sbin/ikecert`-Befehl	Befehl zur Verwaltung der Zertifikatdatenbank, mit dem lokale Datenbanken geändert werden können, die PublicKey-Zertifikate enthalten. Die Datenbanken können auch auf einem angehängtem Sun Crypto Accelerator 4000-Board gespeichert werden.	ikecert(1M)
`/etc/inet/ike/config`-Datei	Standardkonfigurationsdatei für die IKE-Richtlinie im Verzeichnis `/etc/inet`. Enthält die Regeln des Standorts für passende eingehende IKE-Anforderungen und zur Vorbereitung von abgehenden IKE-Anforderungen. Falls diese Datei vorhanden ist, wird in der aktuellen Version der `in.iked`-Daemon gestartet, sobald der `ike`-Service aktiviert wird. Der Speicherort dieser Datei kann über den Befehl `svccfg` geändert werden.	ike.config(4)
`ike.preshared`-Datei	PresharedKeys-Datei im Verzeichnis `/etc/inet/secret.` Enthält sicheres Schlüsselmaterial für die Authentifizierung im Phase 1 Exchange. Wird bei der Konfiguration von IKE mit PresharedKeys verwendet.	ike.preshared(4)
`ike.privatekeys`-Verzeichnis	PrivateKeys-Verzeichnis im Verzeichnis `/etc/inet/secret.` Enthält die privaten Schlüssel, die Teil eines PublicKey-PrivateKey-Paares sind.	ikecert(1M)
`publickeys`-Verzeichnis	Verzeichnis im `/etc/inet/ike`-Verzeichnis, in dem PublicKeys und Zertifikatsdateien gespeichert sind. Enthält die öffentlichen Schlüssel, die Teil eines PublicKey-PrivateKey-Paares sind.	ikecert(1M)
`crls`-Verzeichnis	Verzeichnis im `/etc/inet/ike`-Verzeichnis, in dem Widerrufslisten (CRLs) für PublicKeys und Zertifikatsdateien gespeichert sind.	ikecert(1M)
Sun Crypto Accelerator 1000-Board	Hardware, mit der PublicKey-Vorgänge beschleunigt werden, indem die Berechnung dieser Vorgänge für das Betriebssystem übernommen werden.	ikecert(1M)
Sun Crypto Accelerator 4000-Board	Hardware, mit der PublicKey-Vorgänge beschleunigt werden, indem die Berechnung dieser Vorgänge für das Betriebssystem übernommen werden. Außerdem können PublicKeys, PrivateKeys und PublicKey-Zertifikate auf dem Board gespeichert werden.	ikecert(1M)

Änderungen an IKE für das Release Solaris 10

Nach dem Release Solaris 9 wurde IKE um die folgenden Leistungsmerkmale erweitert:

IKE kann zur Automatisierung des Schlüsselaustauschs für IPsec über IPv6-Netzwerke verwendet werden. Weitere Informationen finden Sie unter Schlüsselmanagement mit IKE.

Hinweis –
IKE kann nicht zur Verwaltung von Schlüsseln für IPsec in einer nicht-globalen Zone verwendet werden.
PublicKey-Vorgänge in IKE können mithilfe eines Sun Crypto Accelerator 1000-Boards oder eines Sun Crypto Accelerator 4000-Boards beschleunigt werden. Die Berechnungen der Vorgänge können vom Board übernommen werden. Durch die Entlastung der CPU wird die Verschlüsselung beschleunigt und somit der Bedarf an Betriebssystemressourcen reduziert. Weitere Informationen finden Sie unter IKE und Hardwarebeschleunigung. Anweisungen finden Sie unter Konfiguration von IKE zum Suchen angehängter Hardware (Übersicht der Schritte).
PublicKey-Zertifikate, PrivateKeys und PublicKeys können auf einem Sun Crypto Accelerator 4000-Board gespeichert werden. Weitere Informationen zur Schlüsselspeicherung finden Sie unter IKE und Hardware-Speicherung.
IKE kann zur Automatisierung des Schlüsselaustauschs für IPsec hinter einer NAT-Box verwendet werden. Der Datenverkehr muss ein IPv4-Netzwerk nutzen. Außerdem können NAT-durchlaufende IPsec ESP-Schlüssel nicht Hardware-beschleunigt werden. Weitere Informationen finden Sie unter IPsec und NAT Traversal. Anweisungen finden Sie unter Konfiguration von IKE für mobile Systeme (Übersicht der Schritte).
Der Datei /etc/inet/ike/config wurden Parameter zur erneuten Übertragung und zur Paket-Zeitüberschreitung hinzugefügt. Diese Parameter optimieren die Aushandlung in der IKE Phase 1 (Hauptmodus) zur Verarbeitung von Netzwerkstörungen, starkem Netzwerkverkehr und zur Interoperation mit Plattformen, die andere Implementierungen des IKE-Protokolls verwenden. Einzelheiten zu den Parametern finden Sie in der Manpage ike.config(4) Anweisungen finden Sie unter Ändern der IKE-Übertragungsparameter (Übersicht der Schritte).