Freitag, 31. August 2012


Topthema

Donnerstag, 25. Januar 2007 | Topthema

About Security #90: Virtuelle Private Netze — IPsec (2)

(Link zum Artikel: http://www.entwickler.de/php/kolumnen/033919)
  • Teilen
  • kommentieren
  • empfehlen
  • Bookmark and Share

IP Encapsulating Security Payload (ESP), spezifiziert in RFC 4303, ist das zweite IPsec-Protokoll. Im Gegensatz zu dem in About Security #89 vorgestellten IP Authentication Header ist hiermit zus�tzlich zur Authentifizierung und Sicherstellung der Integrit�t auch die Sicherstellung der Vertraulichkeit durch Verschl�sselung der Daten m�glich.

Header des IP-Encapsulating-Security-Payload-(ESP-)Protokolls
Security Parameter Index (SPI)
(32 Bit)
Sequenznummer
(32 Bit)
Initialisierungsvektor (IV)
 
 
Daten
 
 
Padding
 
                             
Padding Length
(8 Bit)
 Next Header  
(8 Bit)
 
Integrity Check Value (ICV)
 

Schutzma�nahmen: Verschl�sselt, Signiert

N E U ! Security aktuell
T�glich aktuelle Security-Infos!

  • Security Parameter Index (SPI)
    definiert zusammen mit der IP-Adresse und dem IPsec-Protokoll die Sicherheitsassoziation (Security Association).
    Diese legt die von den IPsec-Protokollen verwendeten Parameter fest, s.u.
  • Sequenznummer
    zur Verhinderung von Replay-Angriffen, s. About Security #89
  • Payload
    der Bereich, der die verschl�sselten Nutzdaten enth�lt:
    • Initialisierungsvektor (Initialization Vector, IV)
      ist der Initialisierungsvektor f�r den im Cipher-Block-Chaining-Modus eingesetzten symmetrischen Verschl�sselungsalgorithmus.
      Die L�nge ist abh�ngig vom eingesetzten Algorithmus und betr�gt z.B. im Fall von 3DES 64 Bit.
    • Daten
      die eigentlichen Daten, verschl�sselt mit dem eingesetzten Algorithmus
  • Padding (F�llbytes)
    dient zum Auff�llen der Daten bis zur n�chsten Blockgrenze des Blockalgorithmus, die L�nge liegt zwischen 0 und 255 Byte.
  • Padding Length
    gibt die L�nge des verwendeten Paddings an, um es nach der Entschl�sselung entfernen zu k�nnen.
  • Next Header
    definiert das Protokoll der im Paket �bertragenen Daten.
    Im Transportmodus enth�lt es die Protokollnummer des jeweiligen h�heren Protokolls, im Tunnelmodus mit IPv4 eine 4.
  • Integrity Check Value (ICV)
    enth�lt ggf. die Authentifizierungsdaten.
    Der ICV wird erst nach abgeschlossener Verschl�sselung berechnet, um beim Empf�nger bei fehlgeschlagener Authentifizierung die Entschl�sselung zu sparen.
    Im Gegensatz zum IP-Authentication-Header-Protokoll wird der IP-Header nicht in die Berechnung des ICV einbezogen. Gesch�tzt werden nur der ESP-Header und die verschl�sselten Nutzdaten. Dies erm�glich prinzipiell den Einsatz von Network Adress Translation (NAT), da eine nachtr�gliche �nderung der IP-Adressen nicht zur Ung�ltigkeit des ICV f�hrt.
Sicherheitsassoziation und Security Policy

Die Sicherheitsassoziation (Security Association, SA, spezifiziert in RFC 4301) legt die von den IPsec-Protokollen zu verwendenden Parameter wie Verschl�sselungs- und Authentifizierungsalgorithmus und deren Schl�ssel etc. sowie weitere Informationen wie z.B. die Lebensdauer der SA und die Betriebsart (Transport- oder Tunnelmodus) fest. Alle Sicherheitsassoziationen werden in der so genannte Security Association Database (SAD) gespeichert. Jeder Eintrag enth�lt mindestens folgende Daten:

  • Security Parameter Index (SPI)
    ein vom Empf�nger gew�hlter Wert zur eindeutigen Identifizierung der SA. Bei ausgehenden Verbindungen wird der Wert f�r den Aufbau des AH- bzw. ESP-Headers verwendet. Bei eingehenden Verbindungen wird dar�ber die passende SA bestimmt.
  • Sequence Number Counter
    ist ein 64-Bit-Z�hler f�r die aktuelle Sequenznummer.
  • Sequence Counter Overflow
    ist ein Flag, das die Regeln im Fall eines Sequenznummer�berlaufs festlegt.
  • Anti-Replay-Empfangsfenster
  • AH-Authentifizierungsalgorithmus, Schl�ssel etc. (nur wenn erforderlich)
  • ESP-Verschl�sselungs- und -Authentifizierungsalgorithmus sowie deren Schl�ssel etc. (nur wenn erforderlich)
  • Lebensdauer der Sicherheitsassoziation
  • Betriebsart (Transport- oder Tunnelmodus)
  • Quell- und Zieladresse f�r den Tunnelmodus (nur wenn erforderlich)
  • einige weitere Felder, auf die hier nicht eingegangen werden soll

W�hrend die Sicherheitsassoziation festlegt, wie die Daten gesch�tzt werden, legt die Security Policy (SP, spezifiziert in RFC 4301) fest, welche/wann Daten gesch�tzt werden.

About Security: Die komplette Serie

Die Security Policies werden in der Security Policy Database (SPD) gespeichert. F�r jedes die IPsec-Grenze passierende Paket (egal ob aus- oder eingehend) wird in der SPD nachgesehen, wie das Paket zu behandeln ist. Dabei sind drei Aktionen m�glich:

  • DISCARD, das Paket darf die IPsec-Grenze nicht passieren und wird verworfen
  • BYPASS, das Paket darf die IPsec-Grenze unver�ndert passieren
  • PROTECT, das Paket wird entsprechend der zust�ndigen SA ge�ndert.

Die Auswahl der anzuwendenden Security Policy erfolgt auf Grundlage der lokalen und entfernten IP-Adressen und des verwendeten Protokolls. So k�nnte z.B. die HTTP-Verbindung zwischen zwei ganz bestimmten Rechnern mit IPsec gesch�tzt werden, w�hrend alle anderen HTTP-Verbindungen ungesch�tzt bleiben.

In der n�chsten Folge wird das f�r den Schl�sselaustausch verwendete Internet Key Exchange Protocol (IKEv2) beschrieben.

Wenn Sie Fragen oder Themenvorschl�ge haben, k�nnen Sie diese gerne an die angegebene E-Mail-Adresse senden oder im Security-Forum einbringen!

Carsten Eilers

About Security � �bersicht zum aktuellen Thema "VPN � Virtuelle Private Netze"

Kommentare

Folgende Links könnten Sie auch interessieren