IPsec umfasst zwei Sicherheitsprotokolle zum Schutz von Daten:
Authentication Header (AH)
Encapsulating Security Payload (ESP)
Ein AH schützt Daten mit einem Authentifizierungsalgorithmus. Eine ESP schützt Daten mit einem Verschlüsselungsalgorithmus. Optional kann eine ESP Daten mit einem Authentifizierungsalgorithmus schützen. Jede Implementierung eines Algorithmus wird als ein Mechanismus bezeichnet.
Der Authentication Header bietet Datenauthentifizierung, starke Integrität und Replay-Schutz für IP-Datagrammen. AH schützt den größten Teil des IP-Datagramms. Wie die folgende Abbildung zeigt, wird der AH zwischen IP-Header und Transport-Header eingefügt.
Der Transport-Header kann TCP, UDP, SCTP oder ICMP sein. Wenn ein Tunnel verwendet wird, kann der Transport-Header ein anderer IP-Header sein.
Das Encapsulating Security Payload (ESP)-Modul bietet Vertraulichkeit für Inhalte, die durch ESP eingekapselt sind. ESP stellt auch Services bereit, die vom AH angeboten werden. ESP stellt seinen Schutz jedoch nur dem Teil des Datagramms zur Verfügung, den ESP einkapselt. ESP bietet optionale Authentifizierungsservices, um die Integrität des geschützten Pakets sicherzustellen. Da ESP eine verschlüsselungskonforme Technologie verwendet, könnte ein System zur ESP-Bereitstellung den Gesetzen zu Exportbeschränkungen unterliegen.
ESP kapselt seine Daten ein, so dass ESP nur die Daten schützt, die seinem Anfang im Datagramm folgen, wie in der folgenden Abbildung gezeigt.
In einem TCP-Paket kapselt ESP nur den TCP-Header und dessen Daten ein. Handelt es sich bei dem Paket um ein IP-in-IP-Datagramm, schützt ESP das innere IP-Datagramm. Die für einen Socket geltende Richtlinie ermöglicht eine Selbst-Einkapselung, so dass ESP gegebenenfalls auch IP-Optionen einkapseln kann.
Bei aktivierter Selbst-Einkapselung wird eine Kopie des IP-Headers erstellt, um ein IP-in-IP-Datagramm zu konstruieren. Ist die Selbst-Einkapselung nicht auf ein TCP-Socket gesetzt, wird das Datagramm in dem folgenden Format gesendet:
[ IP(a -> b) options + TCP + data ] |
Ist die Selbst-Einkapselung auf ein TCP-Socket gesetzt, wird das Datagramm in dem folgenden Format gesendet:
[ IP(a -> b) + ESP [ IP(a -> b) options + TCP + data ] ] |
Weitere Informationen finden Sie unter Transport- und Tunnelmodi in IPsec.
In der folgenden Tabelle werden AH und ESP hinsichtlich des gebotenen Schutzes miteinander verglichen.
Tabelle 19–2 Von AH und ESP in IPsec gebotener Schutz
Die IPsec-Sicherheitsprotokolle verwenden zwei Arten von Algorithmen: Authentifizierung und Verschlüsselung. Das AH-Modul verwendet Authentifizierungsalgorithmen. Das ESP-Modul kann sowohl Verschlüsselungs- als auch Authentifizierungsalgorithmen verwenden. Eine Liste der auf Ihrem System verwendeten Algorithmen und deren Eigenschaften können Sie durch Eingabe des Befehls ipsecalgs anzeigen. Weitere Informationen finden Sie in der Manpage ipsecalgs(1M) Mit den in der Manpage getipsecalgbyname(3NSL) beschriebenen Funktionen können Sie auch die Eigenschaften der Algorithmen abrufen.
IPsec auf einem Solaris-System verwendet die kryptografische Grundstruktur in Solaris, um auf die Algorithmen zuzugreifen. Die Grundstruktur bietet neben anderen Services auch ein zentrales Repository für Algorithmen. Mithilfe der Grundstruktur kann IPsec von den leistungsstarken kryptografischen Hardwarebeschleunigern profitieren. Darüber hinaus stellt die Grundstruktur Resource Control-Funktionen zur Verfügung. Beispielsweise können Sie mit der Grundstruktur die Zeit beschränken, die die CPU für kryptografischen Vorgänge im Kernel aufwendet.
Weitere Informationen finden Sie hier:
Authentifizierungsalgorithmen erzeugen eine Integritätsprüfsumme (digest), die auf den Daten und einem Schlüssel basiert. Das AH-Modul verwendet Authentifizierungsalgorithmen. Das ESP-Modul kann ebenfalls Authentifizierungsalgorithmen verwenden.
Verschlüsselungsalgorithmen verschlüsseln Daten mithilfe eines Schlüssels. Das ESP-Modul in IPsec verwendet Verschlüsselungsalgorithmen. Der Algorithmus arbeitet mit Daten in Einheiten von jeweils einer Blockgröße.
Verschiedene Versionen des Betriebssystems Solaris 10 enthalten verschiedenene Standard-Verschlüsselungsalgorithmen.
Ab Solaris 10 7/07 brauchen Sie das Solaris Encryption Kit auf Ihrem System nicht zusätzlich zu installieren. Das Kit stuft den Patch-Level zur Verschlüsselung auf Ihrem System herab. Das Kit ist mit der Verschlüsselung auf Ihrem System nicht kompatibel.
Ab Release Solaris 10 7/07 wird der Inhalt des Solaris Encryption Kit vom Solaris-Installationsdatenträger installiert. Bei dieser Version sind die SHA2-Authentifizierungsalgorithmen sha256, sha384 und sha512 hinzugefügt. Die SHA2-Implementierungen entsprechen der Spezifikation RFC 4868. Bei dieser Version werden größere Diffie-Hellman-Gruppen hinzugefügt: 2048-Bit (Gruppe 14), 3072-Bit (Gruppe 15) und 4096-Bit (Gruppe 16). Bei Sun-Systemen mit CoolThreads-Technologie wird nur die 2048-Bit-Gruppe beschleunigt.
Vor Release Solaris 10 7/07 enthielt der Solaris-Installationsdatenträger grundlegende Algorithmen und Sie konnten stärkere Algorithmen aus dem Solaris Encryption Kit installieren.
Standardmäßig sind die Algorithmen DES-CBC, 3DES-CBC, AES-CBC und Blowfish-CBC installiert. Die von den AES-CBC- und Blowfish-CBC-Algorithmen unterstützte Schlüsselgröße beträgt 128 Bit.
AES-CBC- und Blowfish-CBC-Algorithmen, die Schlüsselgrößen von mehr als 128 Bit unterstützen, stehen IPsec zur Verfügung, wenn Sie das Solaris Encryption Kit installieren. Jedoch stehen nicht alle Verschlüsselungsalgorithmen auch außerhalb der Vereinigten Staaten von Amerika zur Verfügung. Das Kit ist als eine separate CD erhältlich, die nicht im Solaris 10-Installationspaket enthalten ist. Die Installation des Kit ist im Solaris 10 Encryption Kit Installation Guide beschrieben. Weitere Informationen finden Sie auf der Sun Downloads-Website. Zum Herunterladen des Kits klicken Sie auf die Registerkarte „Downloads A-Z“ und dann auf den Buchstaben S. Das Solaris 10 Encryption Kit befindet sich unter den 20 ersten Einträgen.