9. Sicherung von CoAP

Dieser Abschnitt definiert die DTLS-Bindung für CoAP.

Während der Bereitstellungsphase werden einem CoAP-Gerät die benötigten Sicherheitsinformationen bereitgestellt, einschließlich Schlüsselmaterial und Zugriffskontrolllisten. Diese Spezifikation definiert die Bereitstellung für den Modus RawPublicKey in Abschnitt 9.1.3.2.1. Am Ende der Bereitstellungsphase befindet sich das Gerät in einem von vier Sicherheitsmodi mit den folgenden Informationen für den jeweiligen Modus. Die Modi NoSec und RawPublicKey sind für diese Spezifikation verpflichtend zu implementieren.

NoSec: Es gibt keine Sicherheit auf Protokollebene (DTLS ist deaktiviert). Alternative Techniken zur Bereitstellung von Sicherheit auf niedrigeren Schichten SOLLTEN verwendet werden, wenn dies angemessen ist. Die Verwendung von IPsec wird in [IPsec-CoAP] diskutiert. Bestimmte mit eingeschränkten Knoten verwendete Verbindungsschichten bieten ebenfalls Sicherheit auf der Verbindungsschicht, die bei ordnungsgemäßer Schlüsselverwaltung angemessen sein kann.

PreSharedKey: DTLS ist aktiviert, es gibt eine Liste vorinstallierter Schlüssel [RFC4279], und jeder Schlüssel enthält eine Liste der Knoten, mit denen er zur Kommunikation verwendet werden kann, wie in Abschnitt 9.1.3.1 beschrieben. Im Extremfall kann es einen Schlüssel für jeden Knoten geben, mit dem dieser CoAP-Knoten kommunizieren muss (Verhältnis Knoten zu Schlüssel von 1:1). Umgekehrt ermöglicht ein bestimmter vorinstallierter Schlüssel, wenn ihn mehr als zwei Entitäten gemeinsam nutzen, diesen Entitäten nur die Authentifizierung als Mitglied dieser Gruppe und nicht als spezifischer Peer.

RawPublicKey: DTLS ist aktiviert und das Gerät verfügt über ein asymmetrisches Schlüsselpaar ohne Zertifikat (einen rohen öffentlichen Schlüssel), das mithilfe eines Out-of-Band-Mechanismus [RFC7250] validiert wird, wie in Abschnitt 9.1.3.2 beschrieben. Das Gerät verfügt außerdem über eine aus dem öffentlichen Schlüssel berechnete Identität und eine Liste von Identitäten der Knoten, mit denen es kommunizieren kann.

Certificate: DTLS ist aktiviert und das Gerät verfügt über ein asymmetrisches Schlüsselpaar mit einem X.509-Zertifikat [RFC5280], das es an seinen Subject bindet und das von einer gemeinsamen Vertrauenswurzel signiert ist, wie in Abschnitt 9.1.3.3 beschrieben. Das Gerät verfügt außerdem über eine Liste von Vertrauensankern, die zur Validierung eines Zertifikats verwendet werden können.

Im Modus "NoSec" sendet das System die Pakete einfach über normales UDP über IP, was durch das Schema "coap" und den CoAP-Standardport angezeigt wird. Das System ist nur dadurch gesichert, dass Angreifer daran gehindert werden, Pakete vom Netzwerk mit den CoAP-Knoten zu senden oder zu empfangen; siehe Abschnitt 11.5 für eine zusätzliche Komplikation bei diesem Ansatz.

Die anderen drei Sicherheitsmodi werden mithilfe von DTLS erreicht und durch das Schema "coaps" und den DTLS-gesicherten CoAP-Standardport angezeigt. Das Ergebnis ist eine Sicherheitsassoziation, die zur Authentifizierung (im Rahmen des Sicherheitsmodells) und, auf dieser Authentifizierung aufbauend, zur Autorisierung des Kommunikationspartners verwendet werden kann. CoAP selbst bietet keine Protokollprimitive für Authentifizierung oder Autorisierung; wo dies erforderlich ist, kann es entweder durch Kommunikationssicherheit (d. h. IPsec oder DTLS) oder durch Objektsicherheit (innerhalb der Nutzlast) bereitgestellt werden. Von Geräten, die für bestimmte Vorgänge eine Autorisierung erfordern, wird erwartet, dass sie eine dieser beiden Sicherheitsformen verlangen. Notwendigerweise funktioniert Kommunikationssicherheit, wenn ein Vermittler beteiligt ist, nur dann, wenn dieser Vermittler Teil der Vertrauensbeziehungen ist. CoAP bietet keine Möglichkeit, unterschiedliche Autorisierungsstufen, die Clients gegenüber einem Vermittler haben, an weitere Vermittler oder Ursprungsserver weiterzuleiten -- daher kann es erforderlich sein, die gesamte Autorisierung beim ersten Vermittler durchzuführen.

9.1. DTLS-gesichertes CoAP

So wie HTTP mithilfe von Transport Layer Security (TLS) über TCP gesichert wird, wird CoAP mithilfe von Datagram TLS (DTLS) [RFC6347] über UDP gesichert (siehe Abbildung 13). Dieser Abschnitt definiert die Bindung von CoAP an DTLS zusammen mit den minimalen verpflichtend zu implementierenden Konfigurationen, die für eingeschränkte Umgebungen geeignet sind. Die Bindung wird durch eine Reihe von Deltas zum Unicast-CoAP definiert. In der Praxis ist DTLS TLS mit zusätzlichen Funktionen, um die Unzuverlässigkeit des UDP-Transports zu bewältigen.

+----------------------+
|      Application     |
+----------------------+
+----------------------+
|  Requests/Responses  |
|----------------------|  CoAP
|       Messages       |
+----------------------+
+----------------------+
|         DTLS         |
+----------------------+
+----------------------+
|          UDP         |
+----------------------+

Abbildung 13: Abstrakte Schichtung von DTLS-gesichertem CoAP

In einigen eingeschränkten Knoten (begrenzter Flash- und/oder RAM-Speicher) und Netzwerken (begrenzte Bandbreite oder hohe Skalierbarkeitsanforderungen) und je nach den verwendeten Chiffriersuiten sind möglicherweise nicht alle DTLS-Modi anwendbar. Einige DTLS-Chiffriersuiten können erhebliche Implementierungskomplexität sowie einen gewissen anfänglichen Handshake-Overhead verursachen, der beim Aufbau der Sicherheitsassoziation erforderlich ist. Nach Abschluss des anfänglichen Handshakes fügt DTLS einen begrenzten Overhead pro Datagramm von etwa 13 Bytes hinzu, ohne etwaige Initialisierungsvektoren/Nonces (z. B. 8 Bytes bei TLS_PSK_WITH_AES_128_CCM_8 [RFC6655]), Integritätsprüfwerte (z. B. 8 Bytes bei TLS_PSK_WITH_AES_128_CCM_8 [RFC6655]) und das von der Chiffriersuite geforderte Padding. Ob die Verwendung eines bestimmten DTLS-Modus für eine CoAP-basierte Anwendung geeignet ist, sollte sorgfältig abgewogen werden, wobei die möglicherweise anwendbaren Chiffriersuiten, die Frage, ob die Sitzungswartung mit den Anwendungsabläufen vereinbar ist, und ob ausreichende Ressourcen auf den eingeschränkten Knoten und für den zusätzlichen Netzwerk-Overhead verfügbar sind, zu berücksichtigen sind. (Für einige Verwendungsmodi von DTLS benennt diese Spezifikation eine verpflichtend zu implementierende Chiffriersuite. Dies ist eine Implementierungsanforderung zur Maximierung der Interoperabilität in den Fällen, in denen diese Chiffriersuiten tatsächlich angemessen sind. Die spezifischen Sicherheitsrichtlinien einer Anwendung können die tatsächlich verwendbare Menge von Chiffriersuiten bestimmen.) DTLS ist nicht auf Gruppenschlüsselung (Multicast-Kommunikation) anwendbar; es kann jedoch eine Komponente eines zukünftigen Gruppenschlüsselverwaltungsprotokolls sein.

9.1.1. Nachrichtenschicht

Der als CoAP-Client fungierende Endpunkt sollte auch als DTLS-Client fungieren. Er sollte eine Sitzung zum Server auf dem entsprechenden Port initiieren. Nach Abschluss des DTLS-Handshakes kann der Client die erste CoAP-Anfrage initiieren. Alle CoAP-Nachrichten MÜSSEN als DTLS-"Anwendungsdaten" gesendet werden.

Die folgenden Regeln werden für den Abgleich einer Acknowledgement-Nachricht oder einer Reset-Nachricht mit einer Confirmable-Nachricht bzw. einer Reset-Nachricht mit einer Non-confirmable-Nachricht hinzugefügt: Die DTLS-Sitzung MUSS dieselbe sein, und die Epoche MUSS dieselbe sein.

Eine Nachricht ist dieselbe, wenn sie innerhalb derselben DTLS-Sitzung und derselben Epoche gesendet wird und dieselbe Nachrichten-ID hat.

Hinweis: Wenn eine Confirmable-Nachricht erneut übertragen wird, wird für jeden Versuch eine neue DTLS-Sequenznummer (sequence_number) verwendet, obwohl die CoAP-Nachrichten-ID gleich bleibt. Ein Empfänger muss daher weiterhin die in Abschnitt 4.5 beschriebene Duplikaterkennung durchführen. Neuübertragungen DÜRFEN NICHT über Epochen hinweg durchgeführt werden.

DTLS-Verbindungen im Modus RawPublicKey und Certificate werden mit gegenseitiger Authentifizierung aufgebaut, sodass sie bestehen bleiben und für zukünftige Nachrichtenaustausche in beide Richtungen wiederverwendet werden können. Geräte können eine DTLS-Verbindung schließen, wenn sie Ressourcen zurückgewinnen müssen, im Allgemeinen sollten sie die Verbindung jedoch so lange wie möglich aufrechterhalten. Das Schließen der DTLS-Verbindung nach jedem CoAP-Nachrichtenaustausch ist sehr ineffizient.

9.1.2. Anfrage/Antwort-Schicht

Die folgenden Regeln werden für den Abgleich einer Antwort mit einer Anfrage hinzugefügt: Die DTLS-Sitzung MUSS dieselbe sein, und die Epoche MUSS dieselbe sein.

Das bedeutet, dass die Antwort auf eine DTLS-gesicherte Anfrage immer DTLS-gesichert sein MUSS, wobei dieselbe Sicherheitssitzung und dieselbe Epoche verwendet werden. Jeder Versuch, eine NoSec-Antwort auf eine DTLS-Anfrage zu liefern, passt einfach nicht zur Anfrage und MUSS daher abgelehnt werden (es sei denn, sie passt zu einer nicht zusammenhängenden NoSec-Anfrage).

9.1.3. Endpunkt-Identität

Geräte SOLLTEN die Server Name Indication (SNI) unterstützen, um ihre Autorität im Feld SNI HostName anzugeben, wie in Abschnitt 3 von [RFC6066] definiert. Dies ist erforderlich, damit ein Host, der als virtueller Server für mehrere Autoritäten fungiert, bei Empfang einer neuen DTLS-Verbindung weiß, welche Schlüssel für die DTLS-Sitzung zu verwenden sind.

9.1.3.1. Vorinstallierte Schlüssel

Beim Aufbau einer Verbindung zu einem neuen Knoten wählt das System einen geeigneten Schlüssel danach aus, welche Knoten es erreichen möchte, und baut dann eine DTLS-Sitzung unter Verwendung eines PSK-Modus (Pre-Shared Key) von DTLS auf. Implementierungen in diesen Modi MÜSSEN die verpflichtend zu implementierende Chiffriersuite TLS_PSK_WITH_AES_128_CCM_8 unterstützen, wie in [RFC6655] spezifiziert.

Je nach Inbetriebnahmemodell müssen Anwendungen möglicherweise ein Anwendungsprofil für Identitätshinweise definieren (wie in Abschnitt 5.2 von [RFC4279] gefordert und beschrieben), um die Verwendung von PSK-Identitätshinweisen zu ermöglichen.

Die Sicherheitsüberlegungen von Abschnitt 7 von [RFC4279] gelten. Insbesondere sollten Anwendungen sorgfältig abwägen, ob sie Perfect Forward Secrecy (PFS) benötigen, und eine geeignete Chiffriersuite auswählen (Abschnitt 7.1 von [RFC4279]). Die Entropie des PSK muss ausreichend sein, um Brute-Force-Angriffe und (wenn der PSK nicht zufällig, sondern von einem Menschen gewählt wird) Wörterbuchangriffe abzumildern (Abschnitt 7.2 von [RFC4279]). Die Klartextkommunikation von Client-Identitäten kann Daten preisgeben oder die Privatsphäre beeinträchtigen (Abschnitt 7.3 von [RFC4279]).

9.1.3.2. Zertifikate für rohe öffentliche Schlüssel

In diesem Modus verfügt das Gerät über ein asymmetrisches Schlüsselpaar, jedoch ohne X.509-Zertifikat (als roher öffentlicher Schlüssel bezeichnet); beispielsweise wird das asymmetrische Schlüsselpaar vom Hersteller erzeugt und auf dem Gerät installiert (siehe auch Abschnitt 11.6). Ein Gerät DARF mit mehreren rohen öffentlichen Schlüsseln konfiguriert werden. Typ und Länge des rohen öffentlichen Schlüssels hängen von der verwendeten Chiffriersuite ab. Implementierungen im Modus RawPublicKey MÜSSEN die verpflichtend zu implementierende Chiffriersuite TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 unterstützen, wie in [RFC7251], [RFC5246] und [RFC4492] spezifiziert. Der verwendete Schlüssel MUSS ECDSA-fähig sein. Die Kurve secp256r1 MUSS unterstützt werden [RFC4492]; diese Kurve ist äquivalent zur NIST-P-256-Kurve. Der Hash-Algorithmus ist SHA-256. Implementierungen MÜSSEN die Erweiterungen Supported Elliptic Curves und Supported Point Formats verwenden [RFC4492]; das unkomprimierte Punktformat MUSS unterstützt werden; [RFC6090] kann als Implementierungsmethode verwendet werden. Einige Hinweise zur Implementierung dieser Chiffriersuite finden sich in [W3CXMLSEC]. Der Mechanismus zur Verwendung roher öffentlicher Schlüssel mit TLS ist in [RFC7250] spezifiziert.

Implementierungshinweis: Konkret bedeutet dies, dass die in Abbildung 14 aufgeführten Erweiterungen mit mindestens den angegebenen Werten im DTLS-Handshake vorhanden sein werden.

   Extension: elliptic_curves
    Type: elliptic_curves (0x000a)
    Length: 4
    Elliptic Curves Length: 2
    Elliptic curves (1 curve)
      Elliptic curve: secp256r1 (0x0017)

   Extension: ec_point_formats
    Type: ec_point_formats (0x000b)
    Length: 2
    EC point formats Length: 1
    Elliptic curves point formats (1)
      EC point format: uncompressed (0)

   Extension: signature_algorithms
    Type: signature_algorithms (0x000d)
    Length: 4
    Data (4 bytes): 00 02 04 03
      HashAlgorithm: sha256 (4)
      SignatureAlgorithm: ecdsa (3)

Abbildung 14: Für TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 vorhandene DTLS-Erweiterungen

9.1.3.2.1. Bereitstellung

Der Modus RawPublicKey wurde entwickelt, um in M2M-Bereitstellungen einfach provisioniert werden zu können. Es wird angenommen, dass auf jedem Gerät ein geeignetes asymmetrisches öffentliches Schlüsselpaar installiert ist. Ein Bezeichner wird vom Endpunkt aus dem öffentlichen Schlüssel berechnet, wie in Abschnitt 2 von [RFC6920] beschrieben. Alle Implementierungen, die die Prüfung von RawPublicKey-Identitäten unterstützen, MÜSSEN mindestens den Modus sha-256-120 unterstützen (SHA-256 auf 120 Bit gekürzt). Implementierungen SOLLTEN auch längere Bezeichner unterstützen und DÜRFEN kürzere Längen unterstützen. Beachten Sie, dass kürzere Längen weniger Sicherheit gegen Angriffe bieten und ihre Verwendung NICHT EMPFOHLEN wird.

Je nachdem, wie Bezeichner an das System übergeben werden, das sie überprüft, muss die Unterstützung für URI-, Binär- und/oder für Menschen lesbares Format [RFC6920] implementiert werden. Alle Implementierungen SOLLTEN den Binärmodus unterstützen, und Implementierungen mit einer Benutzeroberfläche SOLLTEN auch das für Menschen lesbare Format unterstützen.

Während der Bereitstellung wird der Bezeichner jedes Knotens gesammelt, beispielsweise durch Lesen eines Barcodes auf der Außenseite des Geräts oder durch Beschaffung einer vorkompilierten Liste der Bezeichner. Diese Bezeichner werden dann im entsprechenden Endpunkt installiert, beispielsweise einem M2M-Datenerfassungsserver. Der Bezeichner wird für zwei Zwecke verwendet: um den Endpunkt mit weiteren Geräteinformationen zu verknüpfen und um die Zugriffskontrolle durchzuführen. Während der (anfänglichen und fortlaufenden) Bereitstellung SOLLTE außerdem eine Zugriffskontrollliste der Bezeichner, mit denen das Gerät DTLS-Sitzungen beginnen darf, installiert und gepflegt werden.

9.1.3.3. X.509-Zertifikate

Implementierungen im Modus Certificate MÜSSEN die verpflichtend zu implementierende Chiffriersuite TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 unterstützen, wie in [RFC7251], [RFC5246] und [RFC4492] spezifiziert. Das Zertifikat enthält nämlich eine SubjectPublicKeyInfo, die einen Algorithmus id-ecPublicKey mit namedCurves secp256r1 angibt [RFC5480]; das Format des öffentlichen Schlüssels ist unkomprimiert [RFC5480]; der Hash-Algorithmus ist SHA-256; sofern enthalten, gibt die key usage-Erweiterung digitalSignature an. Zertifikate MÜSSEN mit ECDSA unter Verwendung von secp256r1 signiert werden, und die Signatur MUSS SHA-256 verwenden. Der verwendete Schlüssel MUSS ECDSA-fähig sein. Die Kurve secp256r1 MUSS unterstützt werden [RFC4492]; diese Kurve ist äquivalent zur NIST-P-256-Kurve. Der Hash-Algorithmus ist SHA-256. Implementierungen MÜSSEN die Erweiterungen Supported Elliptic Curves und Supported Point Formats verwenden [RFC4492]; das unkomprimierte Punktformat MUSS unterstützt werden; [RFC6090] kann als Implementierungsmethode verwendet werden.

Der Subject im Zertifikat würde aus einem langfristigen eindeutigen Bezeichner für das Gerät aufgebaut, wie etwa der EUI-64 [EUI64]. Der Subject könnte auch auf dem vollqualifizierten Domänennamen (FQDN) basieren, der als Host-Teil der CoAP-URI verwendet wurde. Die IP-Adresse des Geräts sollte jedoch typischerweise nicht als Subject verwendet werden, da sie sich im Laufe der Zeit ändern würde. Der im System verwendete Erkennungsprozess würde die Zuordnung zwischen den IP-Adressen der jeweiligen Geräte und dem Subject für jedes Gerät aufbauen. Einige Geräte könnten mehr als einen Subject haben und würden mehr als ein einzelnes Zertifikat benötigen.

Wenn eine neue Verbindung aufgebaut wird, muss das Zertifikat des entfernten Geräts verifiziert werden. Wenn der CoAP-Knoten über eine Quelle absoluter Zeit verfügt, SOLLTE der Knoten prüfen, ob die Gültigkeitsdaten des Zertifikats im Bereich liegen. Das Zertifikat MUSS entsprechend den Sicherheitsanforderungen validiert werden, wobei eine Funktionalität verwendet wird, die dem in Abschnitt 6 von [RFC5280] spezifizierten Algorithmus entspricht. Wenn das Zertifikat einen SubjectAltName enthält, MUSS die Autorität der Anfrage-URI mit mindestens einer der Autoritäten jeder CoAP-URI übereinstimmen, die in einem Feld vom Typ URI in der SubjectAltName-Menge gefunden wird. Wenn kein SubjectAltName im Zertifikat vorhanden ist, MUSS die Autorität der Anfrage-URI mit dem Common Name (CN) übereinstimmen, der im Zertifikat gefunden wird, wobei die in [RFC3280] definierten Übereinstimmungsregeln gelten, mit der Ausnahme, dass Zertifikate mit Platzhaltern nicht zulässig sind.

Die CoRE-Unterstützung für die Prüfung des Zertifikatsstatus erfordert weitere Untersuchungen. Da eine Abbildung des Online Certificate Status Protocol (OCSP) [RFC6960] auf CoAP derzeit nicht definiert ist und OCSP möglicherweise auch nicht in allen Umgebungen leicht anwendbar ist, könnte ein alternativer Ansatz die Verwendung der TLS Certificate Status Request-Erweiterung (Abschnitt 8 von [RFC6066]; auch bekannt als "OCSP-Stapling") oder vorzugsweise der Multiple Certificate Status Extension ([RFC6961]) sein, sofern verfügbar.

Wenn das System zusätzlich zum Zertifikat über einen gemeinsamen Schlüssel verfügt, SOLLTE eine Chiffriersuite verwendet werden, die den gemeinsamen Schlüssel enthält, wie etwa TLS_ECDHE_PSK_WITH_AES_128_CBC_SHA [RFC5489].