8. CBC-DES Symmetric Encryption Protocol (CBC-DES Symmetrisches Verschlüsselungsprotokoll)

Dieser Abschnitt beschreibt das CBC-DES symmetrische Verschlüsselungsprotokoll. Dieses Protokoll ist das erste Datenschutzprotokoll, das für das benutzerbasierte Sicherheitsmodell definiert wurde.

Dieses Protokoll wird durch usmDESPrivProtocol identifiziert.

Im Laufe der Zeit können andere Datenschutzprotokolle entweder als Ersatz für dieses Protokoll oder zusätzlich zu diesem Protokoll definiert werden.

8.1. Mechanisms (Mechanismen)

Das CBC-DES Verschlüsselungsprotokoll bietet folgende Mechanismen:

Data Confidentiality Support (Datenvertraulichkeitsunterstützung)

Zur Unterstützung der Datenvertraulichkeit ist ein Verschlüsselungsalgorithmus erforderlich. Ein geeigneter Teil der Nachricht wird vor der Übertragung verschlüsselt. Das benutzerbasierte Sicherheitsmodell gibt an, dass die scopedPDU der Teil der Nachricht ist, der verschlüsselt werden muss.

Secret Value and Timeliness (Geheimer Wert und Aktualität)

Ein geheimer Wert in Kombination mit einem Aktualitätswert wird verwendet, um den Ver-/Entschlüsselungsschlüssel und den Initialisierungsvektor zu erstellen. Der geheime Wert wird von allen SNMP-Engines geteilt, die berechtigt sind, Nachrichten im Namen des entsprechenden Benutzers zu generieren.

8.1.1. Symmetric Encryption Protocol (Symmetrisches Verschlüsselungsprotokoll)

Das in diesem Memo definierte symmetrische Verschlüsselungsprotokoll bietet Unterstützung für Datenvertraulichkeit. Der bezeichnete Teil einer SNMP-Nachricht wird verschlüsselt und als Teil der an den Empfänger gesendeten Nachricht eingefügt.

Zwei Organisationen haben Spezifikationen veröffentlicht, die DES definieren:

Das National Institute of Standards and Technology (NIST) DES-NIST
Das American National Standards Institute (ANSI) DES-ANSI

Es gibt eine begleitende Betriebsmodusspezifikation für jede Definition (DESO-NIST bzw. DESO-ANSI).

8.1.1.1. DES key and Initialization Vector (DES-Schlüssel und Initialisierungsvektor)

DES Key (DES-Schlüssel)

Die ersten 8 Oktetts des 16-Oktett-Geheimnisses (privater Datenschutzschlüssel) werden als DES-Schlüssel verwendet. Da DES nur 56 Bits verwendet, wird das niedrigstwertige Bit in jedem Oktett ignoriert.

Initialization Vector (IV) (Initialisierungsvektor)

Der Initialisierungsvektor für die Verschlüsselung wird mit dem folgenden Verfahren erhalten:

Schritt 1: Pre-IV (Vor-IV)

Die letzten 8 Oktetts des 16-Oktett-Geheimnisses (privater Datenschutzschlüssel) werden als Pre-IV verwendet.

Schritt 2: Salt Generation (Salz-Generierung)

Um sicherzustellen, dass der IV für zwei verschiedene Pakete, die mit demselben Schlüssel verschlüsselt wurden, nicht gleich sind (d.h. der IV sich nicht wiederholt), müssen wir den Pre-IV mit etwas pro Paket Eindeutigem "salzen". Eine 8-Oktett-Zeichenkette wird als "Salz" verwendet.

Die Verkettung der 32-Bit-snmpEngineBoots der generierenden SNMP-Engine und einer lokalen 32-Bit-Ganzzahl, die die Verschlüsselungs-Engine pflegt, wird in das "Salz" eingegeben. Die 32-Bit-Ganzzahl wird beim Booten auf einen beliebigen Wert initialisiert.

Schritt 3: Salt Encoding (Salz-Kodierung)

Die 32-Bit-snmpEngineBoots werden in die ersten 4 Oktetts (höchstwertiges Byte zuerst) unseres "Salzes" umgewandelt. Die 32-Bit-Ganzzahl wird dann in die letzten 4 Oktetts (höchstwertiges Byte zuerst) unseres "Salzes" umgewandelt.

Schritt 4: IV Calculation (IV-Berechnung)

Das resultierende "Salz" wird dann mit dem Pre-IV XOR-verknüpft, um den IV zu erhalten.

Schritt 5: privParameters (Datenschutzparameter)

Das 8-Oktett-"Salz" wird dann als OCTET STRING kodiert in das privParameters-Feld eingefügt. Die "Salz"-Ganzzahl wird dann modifiziert. Wir empfehlen, dass sie um eins erhöht wird und beim Erreichen des Maximalwerts umläuft.

Implementierungshinweis (Implementation Note):

Wie genau der Wert des "Salzes" (und damit des IV) variiert, ist eine Implementierungsfrage, solange Maßnahmen ergriffen werden, um die Erzeugung eines doppelten IV zu vermeiden.

Das "Salz" muss in das privParameters-Feld eingefügt werden, damit die empfangende Entität den korrekten IV berechnen und die Nachricht entschlüsseln kann.

8.1.1.2. Data Encryption (Datenverschlüsselung)

Der Datenverschlüsselungsprozess folgt diesen Schritten:

Schritt 1: Padding (Auffüllung)

Die zu verschlüsselnden Daten werden als Oktettsequenz behandelt. Ihre Länge sollte ein ganzzahliges Vielfaches von 8 sein - und wenn dies nicht der Fall ist, werden die Daten am Ende nach Bedarf aufgefüllt. Der tatsächliche Auffüllungswert ist irrelevant.

Schritt 2: Cipher Block Chaining Mode (Cipher-Block-Chaining-Modus)

Die Daten werden im Cipher-Block-Chaining-Modus verschlüsselt.

Schritt 3: Block Processing (Blockverarbeitung)

Der Klartext wird in 64-Bit-Blöcke aufgeteilt.

Der Klartext für jeden Block wird mit dem Chiffretext des vorherigen Blocks XOR-verknüpft, das Ergebnis wird verschlüsselt und die Ausgabe der Verschlüsselung ist der Chiffretext für den Block. Dieses Verfahren wird wiederholt, bis keine Klartextblöcke mehr vorhanden sind.

Schritt 4: First Block (Erster Block)

Für den allerersten Block wird der Initialisierungsvektor anstelle des Chiffretexts des vorherigen Blocks verwendet.

8.1.1.3. Data Decryption (Datenentschlüsselung)

Der Datenentschlüsselungsprozess folgt diesen Schritten:

Schritt 1: Length Verification (Längenüberprüfung)

Vor der Entschlüsselung wird die Länge der verschlüsselten Daten überprüft. Wenn die Länge des zu entschlüsselnden OCTET STRING kein ganzzahliges Vielfaches von 8 Oktetts ist, wird der Entschlüsselungsprozess gestoppt und eine entsprechende Ausnahme vermerkt. Beim Entschlüsseln wird die Auffüllung ignoriert.

Schritt 2: First Block Decryption (Entschlüsselung des ersten Blocks)

Der erste Chiffretextblock wird entschlüsselt, die Entschlüsselungsausgabe wird mit dem Initialisierungsvektor XOR-verknüpft, und das Ergebnis ist der erste Klartextblock.

Schritt 3: Subsequent Blocks (Nachfolgende Blöcke)

Für jeden nachfolgenden Block wird der Chiffretextblock entschlüsselt, die Entschlüsselungsausgabe wird mit dem vorherigen Chiffretextblock XOR-verknüpft, und das Ergebnis ist der Klartextblock.

8.2. Elements of the DES Privacy Protocol (Elemente des DES-Datenschutzprotokolls)

Dieser Abschnitt enthält Definitionen, die zur Realisierung des in diesem Abschnitt dieses Memos definierten Datenschutzmoduls erforderlich sind.

8.2.1. Users (Benutzer)

Der Datenschutz unter Verwendung dieses Datenschutzprotokolls nutzt einen definierten Satz von userName. Für jeden Benutzer, in dessen Namen eine Nachricht bei einer bestimmten SNMP-Engine ver-/entschlüsselt werden muss, muss diese SNMP-Engine Kenntnis von diesem Benutzer haben. Eine SNMP-Engine, die mit einer anderen SNMP-Engine kommunizieren möchte, muss auch Kenntnis von einem Benutzer haben, der dieser Engine bekannt ist, einschließlich Kenntnis der anwendbaren Attribute dieses Benutzers.

Ein Benutzer und seine Attribute sind wie folgt definiert:

`<userName>` (Benutzername)

Eine Zeichenkette, die den Namen des Benutzers darstellt.

`<privKey>` (Datenschutzschlüssel)

Der geheime Schlüssel eines Benutzers, der beim Ver-/Entschlüsseln von Nachrichten verwendet wird. Er MUSS für CBC-DES 16 Oktetts lang sein.

8.2.2. msgAuthoritativeEngineID (Autoritative Engine-ID)

Der in einer authentifizierten/verschlüsselten Nachricht enthaltene msgAuthoritativeEngineID-Wert gibt die autoritative SNMP-Engine für diese bestimmte Nachricht an (siehe die Definition von SnmpEngineID im SNMP-Architekturdokument RFC 3411).

Der (private) Datenschutzschlüssel des Benutzers ist normalerweise bei jeder autoritativen SNMP-Engine unterschiedlich, und daher wird die snmpEngineID verwendet, um den richtigen Schlüssel für den Ver-/Entschlüsselungsprozess auszuwählen.

8.2.3. SNMP Messages Using this Privacy Protocol (SNMP-Nachrichten mit diesem Datenschutzprotokoll)

Nachrichten, die dieses Datenschutzprotokoll verwenden, enthalten ein msgPrivacyParameters-Feld als Teil von msgSecurityParameters.

Für dieses Protokoll ist das msgPrivacyParameters-Feld der serialisierte OCTET STRING, der das "Salz" darstellt, wie in Abschnitt 8.1.1.1 beschrieben.

8.2.4. Services Provided by the DES Privacy Module (Von dem DES-Datenschutzmodul bereitgestellte Dienste)

Dieser Abschnitt beschreibt die Eingaben und Ausgaben, die das DES-Datenschutzmodul erwartet und produziert, wenn das benutzerbasierte Sicherheitsmodul das DES-Datenschutzmodul für Dienste aufruft.

8.2.4.1. Services for Encrypting an Outgoing SNMP Message (Dienste zur Verschlüsselung einer ausgehenden SNMP-Nachricht)

Das DES-Datenschutzprotokoll geht davon aus, dass die Auswahl des privKey vom Aufrufer durchgeführt wird und dass der Aufrufer den zu verwendenden geheimen Schlüssel übergibt.

Nach Abschluss gibt das Datenschutzmodul statusInformation zurück und, wenn der Verschlüsselungsprozess erfolgreich war, die encryptedPDU.

Die abstrakte Dienstprimitive lautet:

statusInformation =              -- Erfolg oder Misserfolg
  encryptData(
  IN   privKey                   -- geheimer Schlüssel für die Verschlüsselung
  IN   dataToEncrypt             -- zu verschlüsselnde scopedPDU
  OUT  encryptedData             -- verschlüsselte scopedPDU
  OUT  privParameters            -- serialisierter "Salz"-Wert
       )

Parameter (Parameters):

statusInformation: Eine Anzeige, ob der Verschlüsselungsprozess erfolgreich war. Wenn nicht, ist es eine Anzeige des Problems.
privKey: Der geheime Schlüssel, der vom Verschlüsselungsalgorithmus verwendet werden soll. Die Länge dieses Schlüssels MUSS 16 Oktetts betragen.
dataToEncrypt: Die zu verschlüsselnde scopedPDU.
encryptedData: Die verschlüsselte scopedPDU bei der Ausgabe.
privParameters: Der für diese Verschlüsselung verwendete "Salz"-Wert, der in msgPrivacyParameters gesendet werden soll.

8.2.4.2. Services for Decrypting an Incoming SNMP Message (Dienste zur Entschlüsselung einer eingehenden SNMP-Nachricht)

Das DES-Datenschutzprotokoll geht davon aus, dass die Auswahl des privKey vom Aufrufer durchgeführt wird und dass der Aufrufer den zu verwendenden geheimen Schlüssel übergibt.

Nach Abschluss gibt das Datenschutzmodul statusInformation zurück und, wenn der Entschlüsselungsprozess erfolgreich war, die decryptedPDU.

Die abstrakte Dienstprimitive lautet:

statusInformation =              -- Erfolg oder Misserfolg
  decryptData(
  IN   privKey                   -- geheimer Schlüssel für die Entschlüsselung
  IN   privParameters            -- wie in msgPrivacyParameters empfangen
  IN   encryptedData             -- verschlüsselte scopedPDU
  OUT  decryptedData             -- entschlüsselte scopedPDU
       )

Parameter (Parameters):

statusInformation: Eine Anzeige, ob der Entschlüsselungsprozess erfolgreich war. Wenn nicht, ist es eine Anzeige des Problems.
privKey: Der geheime Schlüssel, der vom Entschlüsselungsalgorithmus verwendet werden soll. Die Länge dieses Schlüssels MUSS 16 Oktetts betragen.
privParameters: Der in msgPrivacyParameters empfangene "Salz"-Wert.
encryptedData: Die zu entschlüsselnde verschlüsselte scopedPDU.
decryptedData: Die entschlüsselte scopedPDU bei der Ausgabe.

8.3. Elements of Procedure (Prozesselemente)

Dieser Abschnitt beschreibt die Verfahren für das CBC-DES-Datenschutzprotokoll.

8.3.1. Processing an Outgoing Message (Verarbeitung einer ausgehenden Nachricht)

Dieser Abschnitt beschreibt das Verfahren, dem eine SNMP-Engine folgt, wenn sie eine Nachricht mit Datenschutz (Verschlüsselung) im Namen eines Benutzers generiert.

Schritt 1: Datenschutzschlüssel erhalten

Den 16-Oktett-privKey für den Benutzer erhalten.

Schritt 2: DES-Schlüssel extrahieren

Die ersten 8 Oktetts als DES-Schlüssel extrahieren.

Schritt 3: Pre-IV erhalten

Die letzten 8 Oktetts als Pre-IV extrahieren.

Schritt 4: Salz generieren

Einen 8-Oktett-Salzwert unter Verwendung von snmpEngineBoots und einem lokalen Zähler generieren.

Schritt 5: IV berechnen

Das Salz mit dem Pre-IV XOR-verknüpfen, um den Initialisierungsvektor zu erhalten.

Schritt 6: Daten auffüllen

Die scopedPDU bei Bedarf auffüllen, um sie zu einem Vielfachen von 8 Oktetts zu machen.

Schritt 7: Verschlüsseln

Die aufgefüllte scopedPDU mit CBC-DES unter Verwendung des DES-Schlüssels und IV verschlüsseln.

Schritt 8: privParameters setzen

Das Salz in das msgPrivacyParameters-Feld einfügen.

Schritt 9: Ergebnis zurückgeben

Die encryptedPDU und privParameters zurückgeben.

8.3.2. Processing an Incoming Message (Verarbeitung einer eingehenden Nachricht)

Dieser Abschnitt beschreibt das Verfahren, dem eine SNMP-Engine folgt, wenn sie eine Nachricht mit Datenschutz (Verschlüsselung) verarbeitet.

Schritt 1: Datenschutzschlüssel erhalten

Den 16-Oktett-privKey für den Benutzer erhalten.

Schritt 2: DES-Schlüssel extrahieren

Die ersten 8 Oktetts als DES-Schlüssel extrahieren.

Schritt 3: Pre-IV erhalten

Die letzten 8 Oktetts als Pre-IV extrahieren.

Schritt 4: Salz extrahieren

Das Salz aus msgPrivacyParameters extrahieren.

Schritt 5: IV berechnen

Das Salz mit dem Pre-IV XOR-verknüpfen, um den Initialisierungsvektor zu erhalten.

Schritt 6: Länge überprüfen

Überprüfen, dass die Länge der verschlüsselten Daten ein Vielfaches von 8 Oktetts ist. Wenn nicht, einen Fehler zurückgeben.

Schritt 7: Entschlüsseln

Die encryptedPDU mit CBC-DES unter Verwendung des DES-Schlüssels und IV entschlüsseln.

Schritt 8: Auffüllung entfernen

Jegliche Auffüllung aus den entschlüsselten Daten entfernen.

Schritt 9: Ergebnis zurückgeben

Die entschlüsselte scopedPDU zurückgeben.

Implementation Notes (Implementierungshinweise)

Schlüssellänge (Key Length): Der privKey MUSS für CBC-DES genau 16 Oktetts lang sein
DES-Schlüsselverwendung (DES Key Usage): Nur die ersten 8 Oktetts werden als DES-Schlüssel verwendet; die letzten 8 Oktetts werden für die IV-Generierung verwendet
Salzeinzigartigkeit (Salt Uniqueness): Das Salz muss für jede Nachricht eindeutig sein, um die IV-Einzigartigkeit zu gewährleisten
Auffüllung (Padding): Implementierungen müssen die Auffüllung korrekt handhaben und sicherstellen, dass die verschlüsselten Daten immer ein Vielfaches von 8 Oktetts sind
Zählerverwaltung (Counter Management): Der Salzzähler sollte beim Booten initialisiert und für jede Nachricht inkrementiert werden

Security Considerations (Sicherheitsüberlegungen)

DES-Veraltung (DES Deprecation): DES gilt nach modernen Standards als kryptografisch schwach. Die effektive Schlüssellänge von 56 Bits ist anfällig für Brute-Force-Angriffe
Migrationsempfehlung (Migration Recommendation): Neue Implementierungen sollten die Verwendung stärkerer Verschlüsselungsalgorithmen wie AES in Betracht ziehen
IV-Einzigartigkeit (IV Uniqueness): Es ist entscheidend, dass der IV für denselben Schlüssel niemals wiederholt wird. Implementierungen müssen eine ordnungsgemäße Salzverwaltung gewährleisten
Schlüsselverwaltung (Key Management): Der 16-Oktett-privKey muss geheim gehalten und ordnungsgemäß verwaltet werden
CBC-Modus (CBC Mode): Während der CBC-Modus Vertraulichkeit bietet, bietet er keine Integrität. Das Datenschutzprotokoll sollte immer zusammen mit der Authentifizierung verwendet werden