10. Sicherheitsmechanismen

Dieser Abschnitt beschreibt die Erzeugung und Verarbeitung von sicheren RPL-Nachrichten. Das höchstwertige Bit des RPL-Nachrichtencodes identifiziert, ob eine RPL-Nachricht sicher ist oder nicht. Zusätzlich zu sicheren Versionen grundlegender Kontrollnachrichten (DIS, DIO, DAO, DAO-ACK) hat RPL mehrere Nachrichten, die nur in Netzwerken relevant sind, in denen Sicherheit aktiviert ist.

Die Implementierungskomplexität und -größe ist ein zentrales Anliegen für LLNs, so dass es wirtschaftlich oder physisch unmöglich sein kann, ausgefeilte Sicherheitsvorkehrungen in eine RPL-Implementierung aufzunehmen. Darüber hinaus können viele Bereitstellungen Link-Layer- oder andere Sicherheitsmechanismen nutzen, um ihre Sicherheitsanforderungen zu erfüllen, ohne die Verwendung von Sicherheit in RPL zu erfordern.

Daher ist die Implementierung der in diesem Dokument beschriebenen Sicherheitsfunktionen OPTIONAL. Eine gegebene Implementierung KANN eine Teilmenge (einschließlich der leeren Menge) der beschriebenen Sicherheitsfunktionen unterstützen, zum Beispiel könnte sie Integrität und Vertraulichkeit unterstützen, aber keine Signaturen. Eine Implementierung SOLLTE klar spezifizieren, welche Sicherheitsmechanismen unterstützt werden, und es wird EMPFOHLEN, dass Implementierer die Sicherheitsanforderungen und die Verfügbarkeit von Sicherheitsmechanismen in ihrem Netzwerk sorgfältig prüfen.

10.1. Sicherheitsübersicht

RPL unterstützt drei Sicherheitsmodi:

• Ungesichert (Unsecured): In diesem Sicherheitsmodus verwendet RPL grundlegende DIS-, DIO-, DAO- und DAO-ACK-Nachrichten, die keine Sicherheitsabschnitte haben. Da ein Netzwerk andere Sicherheitsmechanismen verwenden könnte, wie z.B. Link-Layer-Sicherheit, impliziert der ungesicherte Modus nicht, dass alle Nachrichten ohne jeglichen Schutz gesendet werden.

• Vorinstalliert (Preinstalled): In diesem Sicherheitsmodus verwendet RPL sichere Nachrichten. Um einer RPL-Instanz beizutreten, muss ein Knoten einen vorinstallierten Schlüssel haben. Knoten verwenden diesen, um Nachrichtenvertraulichkeit, -integrität und -authentizität bereitzustellen. Ein Knoten kann unter Verwendung dieses vorinstallierten Schlüssels dem RPL-Netzwerk entweder als Host oder als Router beitreten.

• Authentifiziert (Authenticated): In diesem Sicherheitsmodus verwendet RPL sichere Nachrichten. Um einer RPL-Instanz beizutreten, muss ein Knoten einen vorinstallierten Schlüssel haben. Knoten verwenden diesen Schlüssel, um Nachrichtenvertraulichkeit, -integrität und -authentizität bereitzustellen. Unter Verwendung dieses vorinstallierten Schlüssels kann ein Knoten dem Netzwerk nur als Host beitreten. Um dem Netzwerk als Router beizutreten, muss ein Knoten einen zweiten Schlüssel von einer Schlüsselautorität erhalten. Diese Schlüsselautorität kann authentifizieren, dass der Anforderer berechtigt ist, ein Router zu sein, bevor sie ihm den zweiten Schlüssel bereitstellt. Der authentifizierte Modus kann nicht durch symmetrische Algorithmen unterstützt werden. Zum Zeitpunkt des Schreibens dieser Spezifikation unterstützt RPL nur symmetrische Algorithmen: der authentifizierte Modus ist zum Vorteil potenzieller zukünftiger kryptographischer Primitive enthalten. Siehe Abschnitt 10.3.

Ob die RPL-Instanz den ungesicherten Modus verwendet oder nicht, wird dadurch signalisiert, ob sie sichere RPL-Nachrichten verwendet. Ob ein gesichertes Netzwerk den vorinstallierten oder authentifizierten Modus verwendet, wird durch das 'A'-Bit der DAG-Konfigurationsoption signalisiert.

Diese Spezifikation spezifiziert CCM -- Counter with CBC-MAC (Cipher Block Chaining - Message Authentication Code) -- als kryptographische Basis für RPL-Sicherheit [RFC3610]. In dieser Spezifikation verwendet CCM AES-128 als zugrundeliegenden kryptographischen Algorithmus. Es gibt reservierte Bits im Sicherheitsabschnitt, um in Zukunft andere Algorithmen zu spezifizieren.

Alle gesicherten RPL-Nachrichten haben entweder einen MAC oder eine Signatur. Optional haben gesicherte RPL-Nachrichten auch einen Verschlüsselungsschutz für Vertraulichkeit. Gesicherte RPL-Nachrichtenformate unterstützen sowohl integrierte Verschlüsselungs-/Authentifizierungsschemata (z.B. CCM) als auch Schemata, die Pakete separat verschlüsseln und authentifizieren.

10.2. Beitritt zu einem sicheren Netzwerk

RPL-Sicherheit geht davon aus, dass ein Knoten, der einem gesicherten Netzwerk beitreten möchte, mit einem gemeinsamen Schlüssel für die Kommunikation mit Nachbarn und der RPL-Wurzel vorkonfiguriert wurde. Um einem sicheren RPL-Netzwerk beizutreten, hört ein Knoten entweder auf sichere DIOs oder löst sichere DIOs aus, indem er ein sicheres DIS sendet. Zusätzlich zu den DIO/DIS-Regeln in Abschnitt 8 haben sichere DIO- und DIS-Nachrichten diese Regeln:

1. Wenn gesendet, MUSS dieses initiale sichere DIS das Key Identifier Mode-Feld auf 0 (00) setzen und MUSS das Security Level-Feld auf 1 (001) setzen. Der verwendete Schlüssel MUSS der vorkonfigurierte Gruppenschlüssel (Key Index 0x00) sein.

2. Wenn ein Knoten seinen Trickle-Timer als Reaktion auf ein sicheres DIS zurücksetzt (Abschnitt 8.3), MUSS das nächste DIO, das er überträgt, ein sicheres DIO mit derselben Sicherheitskonfiguration wie das sichere DIS sein. Wenn ein Knoten mehrere sichere DIS-Nachrichten empfängt, bevor er ein DIO überträgt, MUSS das sichere DIO dieselbe Sicherheitskonfiguration wie das letzte DIS haben, auf das es antwortet.

3. Wenn ein Knoten ein DIO als Reaktion auf ein sicheres Unicast-DIS sendet (Abschnitt 8.3), MUSS das DIO ein sicheres DIO sein.

Die obigen Regeln erlauben es einem Knoten, einer gesicherten RPL-Instanz unter Verwendung des vorkonfigurierten gemeinsamen Schlüssels beizutreten. Sobald ein Knoten dem DODAG unter Verwendung des vorkonfigurierten gemeinsamen Schlüssels beigetreten ist, bestimmt das 'A'-Bit der Konfigurationsoption seine Fähigkeiten. Wenn das 'A'-Bit der Konfigurationsoption gelöscht ist, dann können Knoten diesen vorinstallierten, gemeinsamen Schlüssel verwenden, um Nachrichten normal auszutauschen: er kann DIOs, DAOs usw. ausgeben.

Wenn das 'A'-Bit der Konfigurationsoption gesetzt ist und die RPL-Instanz im authentifizierten Modus arbeitet:

1. Ein Knoten DARF KEINEN Rang außer INFINITE_RANK in sicheren DIOs ankündigen, die mit Key Index 0x00 gesichert sind. Bei der Verarbeitung von DIO-Nachrichten, die mit Key Index 0x00 gesichert sind, MUSS ein verarbeitender Knoten den angekündigten Rang als INFINITE_RANK betrachten. Jeder andere Wert führt dazu, dass die Nachricht verworfen wird.

2. Sichere DAOs unter Verwendung eines Key Index 0x00 DÜRFEN KEINE RPL Target-Option mit einem Präfix außer der Adresse des Knotens haben. Wenn ein Knoten eine gesicherte DAO-Nachricht unter Verwendung des vorinstallierten, gemeinsamen Schlüssels empfängt, bei der die RPL Target-Option nicht mit der IPv6-Quelladresse übereinstimmt, MUSS er die gesicherte DAO-Nachricht ohne weitere Verarbeitung verwerfen.

Die obigen Regeln bedeuten, dass in RPL-Instanzen, in denen das 'A'-Bit gesetzt ist, unter Verwendung von Key Index 0x00, ein Knoten der RPL-Instanz als Host, aber nicht als Router beitreten kann. Ein Knoten muss mit einer Schlüsselautorität kommunizieren, um einen Schlüssel zu erhalten, der es ihm ermöglicht, als Router zu agieren.

10.3. Installation von Schlüsseln

Der authentifizierte Modus erfordert, dass ein angehender Router dynamisch neue Schlüssel installiert, sobald er einem Netzwerk als Host beigetreten ist. Nachdem er als Host beigetreten ist, verwendet der Knoten Standard-IP-Nachrichtenübermittlung, um mit einem Autorisierungsserver zu kommunizieren, der neue Schlüssel bereitstellen kann.

Das Protokoll, um solche Schlüssel zu erhalten, liegt außerhalb des Geltungsbereichs dieser Spezifikation und soll in zukünftigen Spezifikationen ausgearbeitet werden. Diese Ausarbeitung ist erforderlich, damit RPL sicher im authentifizierten Modus arbeiten kann.

10.4. Konsistenzprüfungen

RPL-Knoten senden Konsistenzprüfungs-Nachrichten (Consistency Check - CC), um sich gegen Replay-Angriffe zu schützen und Zähler zu synchronisieren.

1. Wenn ein Knoten eine Unicast-CC-Nachricht mit gelöschtem 'R'-Bit empfängt und er Mitglied des assoziierten DODAG ist oder dabei ist, diesem beizutreten, SOLLTE er mit einer Unicast-CC-Nachricht an den Absender antworten. Diese Antwort MUSS das 'R'-Bit gesetzt haben, und sie MUSS dieselben CC-Nonce-, RPLInstanceID- und DODAGID-Felder haben wie die Nachricht, die er empfangen hat.

2. Wenn ein Knoten eine Multicast-CC-Nachricht empfängt, MUSS er die Nachricht ohne weitere Verarbeitung verwerfen.

Konsistenzprüfungs-Nachrichten erlauben es Knoten, eine Challenge-Response auszugeben, um den aktuellen Zählerwert eines Knotens zu validieren. Da die CC-Nonce vom Herausforderer generiert wird, ist es unwahrscheinlich, dass ein Gegner, der Nachrichten wiederholt, in der Lage ist, eine korrekte Antwort zu generieren. Der Zähler in der Konsistenzprüfungs-Antwort erlaubt es dem Herausforderer, die Zählerwerte zu validieren, die er hört.

10.5. Zähler

Im einfachsten Fall ist der Zählerwert eine vorzeichenlose Ganzzahl, die ein Knoten bei jeder gesicherten RPL-Übertragung um eins oder mehr erhöht. Der Zähler KANN einen Zeitstempel repräsentieren, der die folgenden Eigenschaften hat:

1. Der Zeitstempel MUSS mindestens sechs Oktette lang sein.

2. Der Zeitstempel MUSS in 1024 Hz (binäre Millisekunde) Granularität sein.

3. Die Startzeit des Zeitstempels MUSS der 1. Januar 1970, 00:00:00 UTC sein.

4. Wenn der Zähler einen Zeitstempel repräsentiert, MUSS der Zählerwert ein wie folgt berechneter Wert sein. Sei T der Zeitstempel, S die Startzeit des verwendeten Schlüssels und E die Endzeit des verwendeten Schlüssels. Sowohl S als auch E werden unter Verwendung derselben drei Regeln wie der oben beschriebene Zeitstempel dargestellt. Wenn E > T < S, dann ist der Zähler ungültig und ein Knoten DARF KEIN Paket generieren. Andernfalls ist der Zählerwert gleich T-S.

5. Wenn der Zähler einen solchen Zeitstempel repräsentiert, KANN ein Knoten das 'T'-Flag des Sicherheitsabschnitts von gesicherten RPL-Paketen setzen.

6. Wenn das Counter-Feld keinen solchen Zeitstempel darstellt, dann DARF ein Knoten das 'T'-Flag NICHT setzen.

7. Wenn ein Knoten keinen lokalen Zeitstempel hat, der die obigen Anforderungen erfüllt, MUSS er das 'T'-Flag ignorieren.

Wenn ein Knoten solche Zeitstempel unterstützt und er eine Nachricht mit gesetztem 'T'-Flag empfängt, KANN er die in Abschnitt 10.7.1 beschriebene zeitliche Prüfung auf die empfangene Nachricht anwenden. Wenn ein Knoten eine Nachricht ohne gesetztes 'T'-Flag empfängt, DARF er diese zeitliche Prüfung NICHT anwenden. Die Sicherheitsrichtlinie eines Knotens KANN aus Anwendungsgründen das Ablehnen aller Nachrichten ohne gesetztes 'T'-Flag beinhalten.

Das 'T'-Flag ist vorhanden, weil viele LLNs heute bereits eine globale Zeitsynchronisation mit Sub-Millisekunden-Granularität für Sicherheit, Anwendung und andere Gründe aufrechterhalten. RPL zu erlauben, diese existierende Funktionalität zu nutzen, wenn vorhanden, vereinfacht Lösungen für einige Sicherheitsprobleme, wie z.B. Verzögerungsschutz, erheblich.

10.6. Übertragung von ausgehenden Paketen

Gegeben ein ausgehendes RPL-Kontrollpaket und der erforderliche Sicherheitsschutz, beschreibt dieser Abschnitt, wie RPL das gesicherte Paket zur Übertragung generiert. Er beschreibt auch die Reihenfolge der kryptographischen Operationen, um den erforderlichen Schutz bereitzustellen.

Die Anforderung für Sicherheitsschutz und das Sicherheitsniveau, das auf ein ausgehendes RPL-Paket angewendet werden soll, wird durch die Sicherheitsrichtlinien-Datenbank des Knotens bestimmt. Die Konfiguration dieser Sicherheitsrichtlinien-Datenbank für die Verarbeitung ausgehender Pakete ist implementierungsspezifisch.

Wo gesicherte RPL-Nachrichten übertragen werden sollen, MUSS ein RPL-Knoten den Sicherheitsabschnitt (T, Sec, KIM und LVL) im ausgehenden RPL-Paket setzen, um das angewendete Schutzniveau und die Sicherheitseinstellungen zu beschreiben (siehe Abschnitt 6.1). Das Security-Subfeld-Bit des RPL Message Code-Feldes MUSS gesetzt sein, um die sichere RPL-Nachricht anzuzeigen.

Der Zählerwert, der bei der Konstruktion der AES-128 CCM-Nonce (Abbildung 31) zur Sicherung des ausgehenden Pakets verwendet wird, MUSS eine Erhöhung des letzten Zählers sein, der an die bestimmte Zieladresse übertragen wurde.

Wo die Sicherheitsrichtlinie die Anwendung von Verzögerungsschutz spezifiziert, MUSS der Zeitstempel-Zähler, der bei der Konstruktion der CCM-Nonce zur Sicherung des ausgehenden Pakets verwendet wird, gemäß den Regeln in Abschnitt 10.5 erhöht werden. Wo ein Zeitstempel-Zähler angewendet wird (angezeigt durch das gesetzte 'T'-Flag), MUSS der lokal gepflegte Zeitstempel-Zähler als Teil der übertragenen gesicherten RPL-Nachricht enthalten sein.

Der kryptographische Algorithmus, der bei der Sicherung des ausgehenden Pakets verwendet wird, wird durch die Sicherheitsrichtlinien-Datenbank des Knotens spezifiziert und MUSS im Wert des Sec-Feldes innerhalb der ausgehenden Nachricht angezeigt werden.

Die Sicherheitsrichtlinie für das ausgehende Paket bestimmt den anwendbaren KIM und Key Identifier, der den Sicherheitsschlüssel spezifiziert, der für die kryptographische Paketverarbeitung verwendet werden soll, einschließlich der optionalen Verwendung von Signaturschlüsseln (siehe Abschnitt 6.1). Die Sicherheitsrichtlinie wird auch den Algorithmus (Algorithm) und das Schutzniveau (Level) in Form von Authentifizierung oder Authentifizierung und Verschlüsselung sowie die potenzielle Verwendung von Signaturen spezifizieren, die auf das ausgehende Paket angewendet werden sollen.

Wo Verschlüsselung angewendet wird, MUSS ein Knoten die ursprüngliche Paketnutzlast durch jene Nutzlast ersetzen, die unter Verwendung des Sicherheitsschutzes, des Schlüssels und der CCM-Nonce verschlüsselt wurde, die im Sicherheitsabschnitt des Pakets spezifiziert sind.

Alle gesicherten RPL-Nachrichten enthalten Integritätsschutz. In Verbindung mit der Sicherheitsalgorithmus-Verarbeitung leitet ein Knoten entweder einen MAC oder eine Signatur ab, die als Teil des ausgehenden gesicherten RPL-Pakets enthalten sein MUSS.

10.7. Empfang von eingehenden Paketen

Dieser Abschnitt beschreibt den Empfang und die Verarbeitung eines gesicherten RPL-Pakets. Gegeben ein eingehendes gesichertes RPL-Paket, bei dem das Security-Subfeld-Bit des RPL Message Code-Feldes gesetzt ist, beschreibt dieser Abschnitt, wie RPL eine unverschlüsselte Variante des Pakets generiert und seine Integrität validiert.

Der Empfänger verwendet die RPL-Sicherheitskontrollfelder, um die notwendige Paketsicherheitsverarbeitung zu bestimmen. Wenn das beschriebene Sicherheitsniveau für den Nachrichtentyp und den Urheber unbekannt ist oder lokal gepflegte Sicherheitsrichtlinien nicht erfüllt, MUSS ein Knoten das Paket ohne weitere Verarbeitung verwerfen, KANN einen Management-Alarm auslösen und DARF KEINE Nachrichten als Antwort senden. Diese Richtlinien können Sicherheitsniveaus, verwendete Schlüssel, Quellidentifikatoren oder das Fehlen von zeitstempelbasierten Zählern (wie durch das 'T'-Flag angezeigt) beinhalten. Die Konfiguration der Sicherheitsrichtlinien-Datenbank für die Verarbeitung eingehender Pakete liegt außerhalb des Geltungsbereichs dieser Spezifikation (sie kann z.B. durch DIO-Konfiguration oder durch Out-of-Band administrative Router-Konfiguration definiert werden).

Wo das Nachrichtensicherheitsniveau (LVL) eine verschlüsselte RPL-Nachricht anzeigt, verwendet der Knoten die durch das KIM-Feld identifizierten Schlüsselinformationen sowie die CCM-Nonce als Eingabe für die Nachrichten-Nutzlast-Entschlüsselungsverarbeitung. Die CCM-Nonce wird aus dem Nachrichten-Counter-Feld und anderen empfangenen und lokal gepflegten Informationen abgeleitet (siehe Abschnitt 10.9.1). Der Klartext-Nachrichteninhalt wird durch Aufrufen des inversen kryptographischen Betriebsmodus erhalten, der durch das Sec-Feld des empfangenen Pakets spezifiziert ist.

Der Empfänger verwendet die CCM-Nonce und die identifizierten Schlüsselinformationen, um die Integrität des eingehenden Pakets zu prüfen. Wenn die Integritätsprüfung gegen den empfangenen MAC fehlschlägt, MUSS ein Knoten das Paket verwerfen.

Wenn die empfangene Nachricht einen initialisierten (Nullwert) Zählerwert hat und der Empfänger einen eingehenden Zähler hat, der aktuell für den Urheber der Nachricht gepflegt wird, MUSS der Empfänger eine Zähler-Resynchronisation initiieren, indem er eine Konsistenzprüfungs-Antwortnachricht (siehe Abschnitt 6.6) an die Nachrichtenquelle sendet. Die Konsistenzprüfungs-Antwortnachricht wird mit dem aktuellen vollen ausgehenden Zähler geschützt, der für die bestimmte Knotenadresse gepflegt wird. Dieser ausgehende Zähler wird im Sicherheitsabschnitt der Nachricht enthalten sein, während der eingehende Zähler in der Konsistenzprüfungs-Nachrichtennutzlast enthalten sein wird.

Basierend auf der spezifizierten Sicherheitsrichtlinie KANN ein Knoten Replay-Schutz für eine empfangene RPL-Nachricht anwenden. Die Replay-Prüfung SOLLTE vor der Authentifizierung des empfangenen Pakets durchgeführt werden. Der Zähler, wie aus dem eingehenden Paket erhalten, wird gegen das Wasserzeichen des eingehenden Zählers verglichen, der für die gegebene Urheber-Knotenadresse gepflegt wird. Wenn der empfangene Nachrichtenzählerwert ungleich Null und kleiner als das gepflegte eingehende Zähler-Wasserzeichen ist, wird ein potenzielles Paket-Replay angezeigt und der Knoten MUSS das eingehende Paket verwerfen.

Wenn Verzögerungsschutz als Teil der Sicherheitsrichtlinienprüfungen für eingehende Pakete spezifiziert ist, wird der Zeitstempel-Zähler verwendet, um die Rechtzeitigkeit der empfangenen RPL-Nachricht zu validieren. Wenn der Zeitstempel-Zählerwert der eingehenden Nachricht eine Nachrichtenübertragungszeit vor dem lokal gepflegten Übertragungszeit-Zähler für die Urheberadresse anzeigt, wird eine Replay-Verletzung angezeigt und der Knoten MUSS das eingehende Paket verwerfen. Wenn der empfangene Zeitstempel-Zählerwert eine Nachrichtenübertragungszeit anzeigt, die früher als die aktuelle Zeit abzüglich der akzeptablen Paketverzögerung ist, wird eine Verzögerungsverletzung angezeigt und der Knoten MUSS das eingehende Paket verwerfen.

Sobald eine Nachricht entschlüsselt wurde, wo anwendbar, und erfolgreich ihre Integritätsprüfung, Replay-Prüfung und optional Verzögerungsschutzprüfungen bestanden hat, kann der Knoten seine lokalen Sicherheitsinformationen aktualisieren, wie z.B. den erwarteten Zählerwert der Quelle für den Replay-Vergleich.

Ein Knoten DARF seine Sicherheitsinformationen NICHT aktualisieren bei Empfang einer Nachricht, die Sicherheitsrichtlinienprüfungen oder andere angewendete Integritäts-, Replay- oder Verzögerungsprüfungen nicht besteht.

10.7.1. Zeitstempel-Schlüssel-Prüfungen

Wenn das 'T'-Flag einer Nachricht gesetzt ist und ein Knoten einen lokalen Zeitstempel hat, der den Anforderungen in Abschnitt 10.5 folgt, dann KANN ein Knoten die zeitliche Konsistenz der Nachricht prüfen. Der Knoten berechnet die Übertragungszeit der Nachricht durch Addition des Zählerwertes zur Startzeit des assoziierten Schlüssels. Wenn diese Übertragungszeit nach der Endzeit des Schlüssels liegt, KANN der Knoten die Nachricht ohne weitere Verarbeitung verwerfen. Wenn die Übertragungszeit zu weit in der Vergangenheit oder Zukunft im Vergleich zur lokalen Zeit auf dem Empfänger liegt, KANN er die Nachricht ohne weitere Verarbeitung verwerfen.

10.8. Abdeckung von Integrität und Vertraulichkeit

Für eine RPL-ICMPv6-Nachricht liegt das gesamte Paket im Geltungsbereich der RPL-Sicherheit.

MACs und Signaturen werden über das gesamte ungesicherte IPv6-Paket berechnet. Bei der Berechnung von MACs und Signaturen werden veränderliche IPv6-Felder als mit Nullen gefüllt betrachtet, gemäß den Regeln in Abschnitt 3.3.3.1 von [RFC4302] (IPsec Authenticated Header). MAC- und Signaturberechnungen werden vor jeder Komprimierung durchgeführt, die untere Schichten anwenden können.

Wenn eine RPL-ICMPv6-Nachricht verschlüsselt wird, beginnt die Verschlüsselung beim ersten Byte nach dem Sicherheitsabschnitt und setzt sich bis zum letzten Byte des Pakets fort. Der IPv6-Header, ICMPv6-Header und die RPL-Nachricht bis zum Ende des Sicherheitsabschnitts werden nicht verschlüsselt, da sie benötigt werden, um das Paket korrekt zu entschlüsseln.

Zum Beispiel verwendet ein Knoten, der eine Nachricht mit LVL=1, KIM=0 und Algorithm=0 sendet, den CCM-Algorithmus [RFC3610], um ein Paket mit Attributen ENC-MAC-32 zu erstellen: er verschlüsselt das Paket und hängt einen 32-Bit-MAC an. Der Blockchiffreschlüssel wird durch den Key Index bestimmt. Die CCM-Nonce wird wie in Abschnitt 10.9.1 beschrieben berechnet; die zu authentifizierende und zu verschlüsselnde Nachricht ist die RPL-Nachricht, die beim ersten Byte nach dem Sicherheitsabschnitt beginnt und mit dem letzten Byte des Pakets endet. Die zusätzlichen Authentifizierungsdaten beginnen mit dem Anfang des IPv6-Headers und enden mit dem letzten Byte des RPL-Sicherheitsabschnitts.

10.9. Kryptographischer Betriebsmodus

Der in dieser Spezifikation beschriebene kryptographische Betriebsmodus (Algorithm = 0) basiert auf CCM und der Blockchiffre AES-128 [RFC3610]. Dieser Betriebsmodus wird von bestehenden Implementierungen breit unterstützt. Der CCM-Modus erfordert eine Nonce (CCM-Nonce).

10.9.1. CCM-Nonce

Ein RPL-Knoten konstruiert eine CCM-Nonce wie folgt:

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    +                       Source Identifier                       +
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                            Counter                            |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |KIM|Resvd| LVL |
    +-+-+-+-+-+-+-+-+

                        Abbildung 31: CCM-Nonce

• Source Identifier (Quellidentifikator): 8 Bytes. Source Identifier wird auf den logischen Identifikator des Urhebers des geschützten Pakets gesetzt.

• Counter (Zähler): 4 Bytes. Counter wird auf den (unkomprimierten) Wert des entsprechenden Feldes in der Sicherheitsoption der RPL-Kontrollnachricht gesetzt.

• Key Identifier Mode (KIM): 2 Bits. KIM wird auf den Wert des entsprechenden Feldes in der Sicherheitsoption der RPL-Kontrollnachricht gesetzt.

• Security Level (LVL): 3 Bits. Security Level wird auf den Wert des entsprechenden Feldes in der Sicherheitsoption der RPL-Kontrollnachricht gesetzt.

Nicht zugewiesene Bits der CCM-Nonce sind reserviert. Sie MÜSSEN bei der Konstruktion der CCM-Nonce auf Null gesetzt werden.

Alle Felder der CCM-Nonce werden in der Reihenfolge des höchstwertigen Oktetts und höchstwertigen Bits zuerst dargestellt.

10.9.2. Signaturen

Wenn der KIM die Verwendung von Signaturen anzeigt (ein Wert von 3), dann hängt ein Knoten eine Signatur an die Datennutzlast des Pakets an. Das Security Level (LVL)-Feld beschreibt die Länge dieser Signatur. Das Signaturschema in RPL für Sicherheitsmodus 3 ist eine Instanziierung des RSA-Algorithmus (RSASSA-PSS) wie in Abschnitt 8.1 von [RFC3447] definiert. Als öffentlicher Schlüssel verwendet es das Paar (n,e), wobei n ein 2048-Bit oder 3072-Bit RSA-Modul ist und wobei e=2^{16}+1. Es verwendet den CCM-Modus [RFC3610] als Verschlüsselungsschema mit M=0 (als Stromchiffre). Beachten Sie, dass obwohl [RFC3610] den CCM-Modus mit M=0 verbietet, RPL explizit den CCM-Modus mit M=0 erlaubt, wenn er in Verbindung mit einer Signatur verwendet wird, da die Signatur eine ausreichende Datenauthentifizierung bietet. Hier wird der CCM-Modus mit M=0 wie in [RFC3610] spezifiziert, aber wobei das M'-Feld in Abschnitt 2.2 auf 0 gesetzt werden MUSS. Es verwendet die SHA-256-Hashfunktion, die in Abschnitt 6.2 von [FIPS180] spezifiziert ist. Es verwendet die Nachrichtenkodierungsregeln von Abschnitt 8.1 von [RFC3447].

Sei 'a' eine Verkettung einer 6-Byte-Darstellung des Zählers und des Nachrichten-Headers. Die Paketnutzlast ist die Rechtsverkettung von Paketdaten 'm' und der Signatur 's'. Dieses Signaturschema wird mit der Rechtsverkettung der Nachrichtenteile a und m aufgerufen, während die Signaturverifikation mit der Rechtsverkettung der Nachrichtenteile a und m und mit Signatur s aufgerufen wird.

RSA-Signaturen dieser Form bieten ausreichenden Schutz für RPL-Netzwerke. Falls erforderlich, liegen alternative Signaturschemata, die prägnantere Signaturen erzeugen, außerhalb des Geltungsbereichs dieser Spezifikation und können Gegenstand einer zukünftigen Spezifikation sein.

Eine Implementierung, die RSA-Signierung mit entweder 2048-Bit- oder 3072-Bit-Signaturen unterstützt, SOLLTE die Verifikation von sowohl 2048-Bit- als auch 3072-Bit-RSA-Signaturen unterstützen. Dies geschieht unter Berücksichtigung der Bereitstellung eines Upgrade-Pfads für eine RPL-Bereitstellung.