close

IPsec

Zur Navigation gehen Zur Suche gehen
TCP/IP-Protokollfamilie
Anwendungsschicht
Transportschicht
Internet-Schicht
Verbindungsschicht
IPv6-Übergangsmechanismen

IPsec (Abkürzung für Internet Protocol Security ) ist eine Reihe von Protokollen, deren Funktion darin besteht, die Kommunikation über das Internet Protocol (IP) zu sichern, indem jedes IP-Paket in einem Datenstrom authentifiziert und/oder verschlüsselt wird. IPsec enthält auch Protokolle zum Einrichten von Verschlüsselungsschlüsseln . [ 1 ]

Zusammenfassung

IPsec -Protokolle agieren auf der Netzwerkschicht, Schicht 3 des OSI-Modells . Andere weit verbreitete Internet-Sicherheitsprotokolle wie SSL , TLS und SSH arbeiten auf der Anwendungsschicht (Schicht 7 des OSI-Modells). Dadurch wird IPsec flexibler, da es zum Schutz von Layer-4-Protokollen, einschließlich TCP und UDP , verwendet werden kann .

Sicherheitsarchitektur

IPsec wird durch eine Reihe kryptografischer Protokolle implementiert, um (1) den Paketfluss zu sichern, (2) die gegenseitige Authentifizierung sicherzustellen und (3) kryptografische Parameter festzulegen .

Die IP-Sicherheitsarchitektur verwendet das Security Association (SA)-Konzept als Grundlage für den Aufbau von Sicherheitsfunktionen auf IP . Eine Sicherheitszuordnung ist einfach das Bündel von Algorithmen und Parametern (z. B. Schlüsseln), das verwendet wird, um einen bestimmten Strom in eine Richtung zu verschlüsseln und zu authentifizieren. Daher werden im normalen Zwei-Wege-Verkehr die Flüsse durch ein Paar Sicherheitszuordnungen gesichert. Die endgültige Entscheidung über Verschlüsselungs- und Authentifizierungsalgorithmen (aus einer definierten Liste) liegt beim IPsec-Administrator.

Um zu entscheiden, welcher Schutz für ein ausgehendes Paket bereitgestellt werden soll, verwendet IPsec den Security Parameter Index (SPI), einen Index der Security Association Database (SADB), zusammen mit der Zieladresse im Paket-Header, die zusammen eine Sicherheit eindeutig identifizieren Zuordnung für dieses Paket. Ein ähnliches Verfahren wird für ein eingehendes Paket durchgeführt; In diesem Fall entnimmt IPsec die Verifizierungs- und Entschlüsselungsschlüssel aus der Sicherheitszuordnungsdatenbank.

Im Falle von Multicast wird der Gruppe eine Sicherheitszuordnung bereitgestellt und für alle autorisierten Empfänger in der Gruppe dupliziert. Es kann mehr als eine Sicherheitszuordnung für eine Gruppe geben, die unterschiedliche SPIs verwendet, wodurch mehrere Sicherheitsebenen und -sätze innerhalb einer Gruppe ermöglicht werden. Tatsächlich kann jeder Sender mehrere Sicherheitszuordnungen haben, die eine Authentifizierung ermöglichen, da ein Empfänger nur wissen kann, dass jemand, der die Schlüssel kennt, die Daten gesendet hat. Beachten Sie, dass der relevante Standard nicht beschreibt, wie die Zuordnung ausgewählt und in der gesamten Gruppe dupliziert wird; es wird davon ausgegangen, dass eine verantwortliche Partei die Wahl getroffen hat.

Aktueller Stand der Norm

IPsec war ein obligatorischer Bestandteil von IPv6 basierend auf der Definition von RFC 4294 , jedoch wurde dieser RFC 2011 durch RFC 6434 obsolet, was darauf hinweist, dass IPsec für IPv6 empfohlen und nicht obligatorisch ist. Für IPv4 ist seine Verwendung optional. Obwohl der Standard so konzipiert ist, dass er unabhängig von der IP-Version ist, beziehen sich die Bereitstellung und Erfahrung bis 2007 auf IPv4 -Implementierungen .

Die IPsec-Protokolle wurden ursprünglich in den 1995 veröffentlichten RFCs 1825 und 1829 definiert. 1998 wurden diese Dokumente durch die RFCs 2401 und 2412 ersetzt, die nicht mit 1825 und 1829 kompatibel sind, obwohl sie konzeptionell identisch sind. Die dritte Generation von Dokumenten, RFCs 4301 und 4309, wurden im Dezember 2005 erstellt. Sie sind größtenteils eine Obermenge von 2401 und 2412, bieten jedoch einen zweiten Internet Key Exchange -Standard . Diese dritte Dokumentengeneration standardisierte die IPsec-Abkürzung als Großbuchstaben „IP“ und Kleinbuchstaben „sec“.

Es ist selten, ein Produkt zu sehen, das sowohl RFC1825 als auch 1829 unterstützt. „ESP“ bezieht sich im Allgemeinen auf 2406, während ESPbis sich auf 4303 bezieht.

Designzweck

IPsec wurde entwickelt, um die Sicherheit des Paketverkehrs im Transportmodus (End-to-End) bereitzustellen, bei dem Endpunktcomputer die Sicherheitsverarbeitung durchführen, oder im Tunnelmodus (Tür-zu-Tür), bei dem die Verkehrssicherheit von Paketen für mehrere Computer bereitgestellt wird (sogar das gesamte lokale Netzwerk ) von einem einzigen Knoten.

IPsec kann zum Erstellen von VPNs in beiden Modi verwendet werden, und dies ist seine Hauptverwendung. Beachten Sie jedoch, dass die Auswirkungen auf die Sicherheit zwischen den beiden Betriebsmodi sehr unterschiedlich sind.

Die End-to-End-Kommunikationssicherheit im Internet hat sich langsamer als erwartet entwickelt. Das liegt zum Teil daran, dass sich keine universelle oder allgemein vertrauenswürdige Public-Key-Infrastruktur entwickelt hat (ursprünglich war DNSSEC dafür vorgesehen); Ein weiterer Teil ist, dass viele Benutzer ihre Bedürfnisse und die verfügbaren Optionen nicht gut genug verstehen, um ihre Aufnahme in die Produkte der Anbieter zu fördern.

Da das Internetprotokoll von Natur aus keine Sicherheitsfunktionen bereitstellt, wurde IPsec eingeführt, um Sicherheitsdienste bereitzustellen, wie zum Beispiel:

  1. Verschlüsseln Sie den Datenverkehr (damit er von niemand anderem als den Parteien gelesen werden kann, für die er bestimmt ist)
  2. Integritätsvalidierung (stellen Sie sicher, dass der Datenverkehr entlang seines Pfads nicht geändert wurde)
  3. Endpunkte authentifizieren (stellen Sie sicher, dass der Datenverkehr von einem vertrauenswürdigen Endpunkt kommt)
  4. Anti-Replay (Schutz vor sicherer Sitzungswiederholung).

Modi

Daher können wir je nach Ebene, auf der es agiert, zwei grundlegende Modi des IPsec -Betriebs festlegen : Transportmodus und Tunnelmodus .

Transportmodus

Im Transportmodus wird nur die Nutzlast (die übertragenen Daten) des IP-Pakets verschlüsselt oder authentifiziert. Das Routing bleibt erhalten, da der IP-Header nicht modifiziert oder verschlüsselt wird; Wenn jedoch der Authentifizierungsheader (AH) verwendet wird, können IP-Adressen nicht übersetzt werden , da dies den Hash ungültig machen würde . Die Transport- und Anwendungsschicht sind immer durch einen Hash gesichert, können also in keiner Weise verändert werden (z. B. durch Übersetzen von TCP- und UDP- Portnummern ). Der Transportmodus wird für die Computer-zu-Computer-Kommunikation verwendet .

Eine Möglichkeit, IPsec-Nachrichten zu kapseln, um NAT zu durchlaufen, wurde von RFCs definiert, die den NAT-Traversal- Mechanismus beschreiben .

Tunnelmodus

Im Tunnelmodus wird das gesamte IP-Paket (Daten plus Nachrichtenheader) verschlüsselt bzw. authentifiziert. Es muss dann in ein neues IP-Paket eingekapselt werden, damit das Routing funktioniert. Der Tunnelmodus wird für Netzwerk-zu-Netzwerk-Kommunikationen (sichere Tunnel zwischen Routern, zB für VPNs ) oder Computer-zu-Netzwerk- oder Computer-zu-Computer-Kommunikationen über das Internet verwendet .

Protokolle

IPsec besteht aus drei Protokollen, die entwickelt wurden, um Sicherheit auf Paketebene für IPv4 und IPv6 bereitzustellen :

  • Authentication Header (AH) bietet Integrität, Authentifizierung und Unbestreitbarkeit, wenn die geeigneten kryptografischen Algorithmen ausgewählt werden.
  • Encapsulating Security Payload (ESP) bietet Vertraulichkeit und die dringend empfohlene Option der Authentifizierung und des Integritätsschutzes.
  • Internet Key Exchange ( IKE ) verwendet einen geheimen Diffie-Hellman- Schlüsselaustausch , um das gemeinsame Geheimnis der Sitzung festzulegen . Üblicherweise werden Public-Key- oder Pre-Shared- Key-Kryptographiesysteme verwendet

Zu den für die Verwendung mit IPsec definierten kryptografischen Algorithmen gehören HMAC – SHA-1 für den Integritätsschutz sowie Triple DES – CBC und AES – CBC für die Vertraulichkeit. Weitere Einzelheiten in RFC 4305 .

Authentication Header (AH)

AH zielt darauf ab, die Integrität, Verbindungslosigkeit und Authentifizierung der Quelldaten von IP-Datagrammen sicherzustellen. Dazu berechnet es einen Hash Message Authentication Code ( HMAC ) durch einen Hash -Algorithmus , der mit einem geheimen Schlüssel, dem Inhalt des IP-Pakets und den unveränderlichen Teilen des Datagramms arbeitet. Dieses Verfahren schränkt die Möglichkeit der Verwendung von NAT ein, was mit NAT-Traversal implementiert werden kann . Andererseits kann AH optional vor Replay-Angriffen schützen, indem es die Sliding-Window -Technik verwendet und alte Pakete verwirft. AH schützt die IP-Nutzdaten und alle Felder im Header eines IP-Datagramms mit Ausnahme von mutierenden Feldern, d. h. solchen, die während der Übertragung geändert werden können. In IPv4 umfassen mutierende (und daher nicht authentifizierte) IP-Header-Felder TOS , Flags, Fragment Offset, TTL und Header Checksum . AH arbeitet direkt auf IP unter Verwendung der IP-Protokollnummer 51. Ein AH- Header ist 32 Bit lang, hier ist ein Diagramm, wie sie angeordnet sind:

0 - 7 Bit 8 - 15 Bit 16 - 23 Bit 24 - 31 Bit
Nächste Überschrift Nutzlastlänge RESERVIERT
Sicherheitsparameterindex (SPI)
Sequenznummer

Authentifizierungscode für Hash-Nachricht (variabel)

Bedeutung der Felder:

Nächste Überschrift
Identifiziert das Protokoll der übertragenen Daten.
Nutzlastlänge
AH-Paketgröße
RESERVIERT
Reserviert für zukünftige Verwendung (bis dahin alle Nullen).
Sicherheitsparameterindex (SPI)
Gibt die Sicherheitsparameter an, die in Kombination mit der IP-Adresse die mit diesem Paket implementierte Sicherheitszuordnung identifizieren.
Sequenznummer
Eine ständig steigende Zahl, die verwendet wird, um Replay-Angriffe zu verhindern.
HMAC
Enthält den Integritätsprüfwert (ICV), der zum Authentifizieren des Pakets erforderlich ist; kann Füllstoffe enthalten.

Encapsulating Security Payload (ESP)

Das ESP-Protokoll bietet Authentizität des Ursprungs, Integrität und Vertraulichkeitsschutz eines Pakets. ESP unterstützt auch reine Verschlüsselungs- und reine Authentifizierungskonfigurationen, aber von der Verwendung von Verschlüsselung ohne Authentifizierung wird dringend abgeraten, da sie unsicher ist [ 2 ] ​[ 3 ]​ . [ 4 ] Im Gegensatz zu AH wird der IP-Paket-Header nicht durch ESP geschützt (obwohl im Tunnelmodus ESP das gesamte innere IP-Paket geschützt wird, einschließlich des inneren Headers; der äußere Header bleibt ungeschützt). ). ESP arbeitet direkt über IP und verwendet das IP-Protokoll Nummer 50.

Ein ESP-Paketdiagramm:

0 - 7 Bit 8 - 15 Bit 16 - 23 Bit 24 - 31 Bit
Sicherheitsparameterindex (SPI)
Sequenznummer


Nutzdaten (variabel)


  Auffüllen (0-255 Bytes)  
    Polsterlänge Nächste Kopfzeile

Authentifizierungsdaten (variabel)


Bedeutung der Felder

Sicherheitsparameterindex (SPI)
Identifiziert die Sicherheitsparameter in Kombination mit der IP-Adresse.
Sequenznummer
Eine ständig steigende Zahl, die verwendet wird, um Replay-Angriffe zu verhindern.
Nutzdaten
Die zu übertragenden Daten.
Polsterung
Wird von einigen kryptografischen Algorithmen verwendet, um Blöcke vollständig zu füllen.
Polsterlänge
Füllgröße in Byte.
Nächste Überschrift
Identifiziert das Protokoll der übertragenen Daten.
Authentifizierungsdatum
Enthält die Daten, die zur Authentifizierung des Pakets verwendet werden.

Implementierungen

Die IPsec-Unterstützung wird normalerweise im Kernel implementiert, wobei die Schlüsselverwaltung und die ISAKMP / IKE - Aushandlung im Benutzerbereich durchgeführt werden. Vorhandene IPsec-Implementierungen umfassen typischerweise beide Funktionalitäten. Da es jedoch eine Standardschnittstelle für die Schlüsselverwaltung gibt, ist es möglich, einen Kern-IPsec-Stack mit den Schlüsselverwaltungstools einer anderen Implementierung zu steuern.

Aus diesem Grund herrscht Verwirrung über die Ursprünge der IPsec-Implementierung im Linux -Kernel . Das FreeS/WAN -Projekt erstellte die erste vollständige Open-Source-Implementierung von IPsec für Linux . Es besteht aus einem KLIPS-Kern-IPsec-Stack , zusammen mit einem Daemon (Pluto) und vielen Shell- Skripten . Das FreeS/WAN-Projekt wurde im März 2004 eingestellt. Openswan und strongSwan sind Fortsetzungen von FreeS/WAN. Das KAME-Projekt implementierte auch volle IPsec-Unterstützung für NetBSD und FreeBSD . Sein Schlüsselverwaltungs-Daemon heißt racoon . OpenBSD hat seinen eigenen ISAKMP/IKE-Daemon entwickelt, der einfach isakmpd heißt (und auf andere Systeme portiert wurde, einschließlich Linux ).

Allerdings wurde keiner dieser Kern-IPsec-Stacks in Linux integriert. Alexey Kuznetsov und David S. Miller haben gegen Ende 2002 eine Kernel-IPsec-Implementierung für Linux von Grund auf geschrieben. Dieser Stack wurde später als Teil von Linux 2.6 veröffentlicht und wird von vielen als "nativ" oder "NETKEY" bezeichnet.

Daher stammt der Linux-IPsec-Stack entgegen der landläufigen Meinung nicht aus dem KAME-Projekt. Da es das standardmäßige PF KEY -Protokoll ( RFC 2367 ) und die native XFRM- Schnittstelle für die Schlüsselverwaltung unterstützt, kann der Linux-IPsec-Stack in Verbindung mit pluto von Openswan / strongSwan , isakmpd des OpenBSD -Projekts, racoon des KAME -Projekts oder ohne verwendet werden ein ISAKMP-Daemon. /IKE (mit manuellen Schlüsseln).

Neue Netzwerkprozessorarchitekturen, einschließlich Multicore-Prozessoren mit eingebetteten Verschlüsselungsmodulen, haben die Art und Weise verändert, wie IPsec-Stacks entworfen werden. Ein dedizierter Fast Path wird verwendet, um die Verarbeitung von IPsec-Aufgaben (SA, SP-Lookups, Verschlüsselung usw.) auszulagern. Diese Fast-Path-Stacks müssen auf dedizierten Kerneln gemeinsam mit Linux oder RTOS integriert werden, die auf anderen Kerneln ausgeführt werden. Diese Betriebssysteme sind die Steuerungsebene, auf der ISAKMP/IKE des IPsec Fast Path-Stapels ausgeführt wird.

Es gibt einige Implementierungen der IPsec- und ISAKMP/IKE-Protokolle. Unter anderem:

Liste von RFCs im Zusammenhang mit IPsec

  • RFC 2327 : PF_KEY-Schnittstelle
  • RFC 2367 : PF_KEY-Schnittstelle
  • RFC 2401 (ersetzt RFC 1825 und wurde durch RFC 4301 ersetzt ): Sicherheitsarchitektur für das Internetprotokoll
  • RFC 2402 (ersetzt durch RFC 4302 und RFC 4305 ): Authentifizierungs-Header
  • RFC 2403 : Die Verwendung von HMAC-MD5-96 in ESP und AH
  • RFC 2404 : Die Verwendung von HMAC-SHA-1-96 in ESP und AH
  • RFC 2405 : Der ESP-DES-CBC-Verschlüsselungsalgorithmus mit explizitem IV
  • RFC 2406 (ersetzt durch RFC 4303 und RFC 4305 ): Encapsulating Security Payload
  • RFC 2407 (ersetzt durch RFC 4306 ): IPsec Domain of Interpretation for ISAKMP (IPsec DoI)
  • RFC 2408 (ersetzt durch RFC 4306 ): Internet Security Association and Key Management Protocol (ISAKMP)
  • RFC 2409 (ersetzt durch RFC 4306 ): Internet Key Exchange (IKE)
  • RFC 2410 : Der NULL-Verschlüsselungsalgorithmus und seine Verwendung mit IPsec
  • RFC 2411 : IP-Sicherheitsdokument-Roadmap
  • RFC 2412 : (ersetzt RFC 1829 ) Das OAKLEY Key Determination Protocol
  • RFC 2451 : Die ESP-CBC-Modus-Verschlüsselungsalgorithmen
  • RFC 2857 : Die Verwendung von HMAC-RIPEMD-160-96 innerhalb von ESP und AH
  • RFC 3526 : More Modular Exponential (MODP) Diffie-Hellman-Gruppen für Internet Key Exchange (IKE)
  • RFC 3706 : Eine datenverkehrsbasierte Methode zur Erkennung toter IKE-Peers (Internet Key Exchange).
  • RFC 3715 : IPsec-Network Address Translation (NAT)-Kompatibilitätsanforderungen
  • RFC 3947 : Aushandlung von NAT-Traversal in IKE
  • RFC 3948 : UDP-Kapselung von IPsec-ESP-Paketen
  • RFC 4106 : Die Verwendung von Galois/Counter Mode (GCM) in IPsec Encapsulating Security Payload (ESP)
  • RFC 4301 (ersetzt RFC 2401 ): Sicherheitsarchitektur für das Internetprotokoll
  • RFC 4302 (ersetzt RFC 2402 ): IP-Authentifizierungs-Header
  • RFC 4303 (ersetzt RFC 2406 ): IP Encapsulating Security Payload (ESP)
  • RFC 4304 : Extended Sequence Number (ESN) Addendum zu IPsec Domain of Interpretation (DOI) für Internet Security Association and Key Management Protocol (ISAKMP)
  • RFC 4305 (ersetzt durch RFC 4835 ): Implementierungsanforderungen für kryptografische Algorithmen für die Kapselung von Sicherheitsnutzdaten (ESP) und Authentifizierungs-Header (AH)
  • RFC 4306 (ersetzt RFC 2407 , RFC 2408 und RFC 2409 ): Internet Key Exchange ( IKEv2 ) Protocol
  • RFC 4307 : Kryptografische Algorithmen zur Verwendung im Internet Key Exchange Version 2 ( IKEv2 )
  • RFC 4308 : Kryptografische Suiten für IPsec
  • RFC 4309 : Verwenden des Advanced Encryption Standard (AES) CCM-Modus mit IPsec Encapsulating Security Payload (ESP)
  • RFC 4478 : Repeated Authentication in Internet Key Exchange (IKEv2) Protocol
  • RFC 4543 : Die Verwendung des Galois Message Authentication Code (GMAC) in IPsec ESP und AH
  • RFC 4555 : IKEv2-Mobilitäts- und Multihoming-Protokoll (MOBIKE)
  • RFC 4621 : Design des IKEv2 Mobility and Multihoming (MOBIKE) Protocol
  • RFC 4718 : IKEv2-Klarstellungen und Implementierungsrichtlinien
  • RFC 4806 : Online Certificate Status Protocol (OCSP)-Erweiterungen zu IKEv2
  • RFC 4809 : Anforderungen für ein IPsec-Zertifikatverwaltungsprofil
  • RFC 4835 (ersetzt RFC 4305 ): Implementierungsanforderungen für kryptografische Algorithmen für die Kapselung von Sicherheitsnutzdaten (ESP) und Authentifizierungs-Header (AH)
  • RFC 4945 : Das PKI-Profil für Internet-IP-Sicherheit von IKEv1/ISAKMP, IKEv2 und PKIX

Referenzen

  1. ↑ Marquis, William (12. Januar 2016). IPsec und virtuelle private Netzwerke . Lulu.com. ISBN  978-1-329-82419-5 . Abgerufen am 3. Oktober 2021 . 
  2. ^ Bellovin, Steven M. (1996). "Problembereiche für die IP-Sicherheitsprotokolle" . Proceedings of the Sixth Usenix Unix Security Symposium . San Jose, CA. pp. 1-16 . Abgerufen am 13. November 2007 .  
  3. ↑ K. G. Paterson und A. Yau (2006). "Kryptographie in Theorie und Praxis: Der Fall der Verschlüsselung in IPsec" . Eurocrypt 2006, Lecture Notes in Computer Science Vol. 4004 . pp. 12-29 . Abgerufen am 13. November 2007 . Text « Berlin » ignoriert ( Hilfe )  
  4. ^ JP Degabriele und K. G. Paterson (2007). "Angriff auf die IPsec-Standards in reinen Verschlüsselungskonfigurationen" . IEEE-Symposium zu Sicherheit und Datenschutz, IEEE Computer Society . pp. 335-349 . Abgerufen am 13. November 2007 . Text "Oakland, CA" ignoriert ( Hilfe )  
Erhalten von « https://es.wikipedia.org/w/index.php?title=IPsec&oldid=144686535 »