CoAP-Protokoll für das Internet der Dinge – Verkehrsstudie

Juni

2021

CoAP-Protokoll für das Internet der Dinge – Verkehrsstudie

безопасность

18 Juni 2021 11:35

Mit WireShark konnten wir zwei Pakete des neuen CoAP-Netzwerkprotokolls erfassen.

Das Contrained Application Protocol (RFC 7252-Standard) ist für das Internet der Dinge konzipiert und basiert auf UDP. Dieses einfache Protokoll ermöglicht die Kommunikation von Maschinen untereinander (M2M – Machine to Machine).

Das erste Paket ist eine Geräteanfrage an Server 188.34.167.226:
Frame 13: 103 bytes on wire (824 bits), 103 bytes captured (824 bits) on interface 0
Ethernet II, Src: Keenetic_0f:40:ef (50:ff:20:0f:40:ef), Dst: router.lan (c4:ad:34:45:6a:fb)
Internet Protocol Version 4, Src: 192.168.0.73 (192.168.0.73), Dst: static.226.167.34.188.clients.your-server.de (188.34.167.226)
0100 .... = Version: 4
.... 0101 = Header Length: 20 bytes (5)
Differentiated Services Field: 0x00 (DSCP: CS0, ECN: Not-ECT)
Total Length: 89
Identification: 0xfaca (64202)
Flags: 0x4000, Don't fragment
Time to live: 64
Protocol: UDP (17)
Header checksum: 0x1ad3 [validation disabled]
[Header checksum status: Unverified]
Source: 192.168.0.73 (192.168.0.73)
Destination: static.226.167.34.188.clients.your-server.de (188.34.167.226)
User Datagram Protocol, Src Port: 56911 (56911), Dst Port: coap (5683)
Source Port: 56911 (56911)
Destination Port: coap (5683)
Length: 69
Checksum: 0x8392 [unverified]
[Checksum Status: Unverified]
[Stream index: 1]
Constrained Application Protocol, Confirmable, POST, MID:41783
01.. .... = Version: 1
..00 .... = Type: Confirmable (0)
.... 1000 = Token Length: 8
Code: POST (2)
Message ID: 41783
Token: 398d7e264ddd9768
Opt Name: #1: Uri-Path: a
Opt Name: #2: Uri-Query: cid=4cef9cfe-af0c-11e8-8f23-df6cd39224ef
Opt Name: #3: Uri-Query: r=ru
[Response In: 59]
[Uri-Path: /a]

Das zweite Paket ist die Serverantwort

Frame 59: 75 bytes on wire (600 bits), 75 bytes captured (600 bits) on interface 0
Ethernet II, Src: router.lan (c4:ad:34:45:6a:fb), Dst: Keenetic_0f:40:ef (50:ff:20:0f:40:ef)
Internet Protocol Version 4, Src: static.226.167.34.188.clients.your-server.de (188.34.167.226), Dst: 192.168.0.73 (192.168.0.73)
0100 .... = Version: 4
.... 0101 = Header Length: 20 bytes (5)
Differentiated Services Field: 0x40 (DSCP: CS2, ECN: Not-ECT)
Total Length: 61
Identification: 0xa920 (43296)
Flags: 0x4000, Don't fragment
Time to live: 52
Protocol: UDP (17)
Header checksum: 0x7859 [validation disabled]
[Header checksum status: Unverified]
Source: static.226.167.34.188.clients.your-server.de (188.34.167.226)
Destination: 192.168.0.73 (192.168.0.73)
User Datagram Protocol, Src Port: coap (5683), Dst Port: 56911 (56911)
Source Port: coap (5683)
Destination Port: 56911 (56911)
Length: 41
Checksum: 0x38a3 [unverified]
[Checksum Status: Unverified]
[Stream index: 1]
Constrained Application Protocol, Acknowledgement, 2.04 Changed, MID:41783
01.. .... = Version: 1
..10 .... = Type: Acknowledgement (2)
.... 1000 = Token Length: 8
Code: 2.04 Changed (68)
Message ID: 41783
Token: 398d7e264ddd9768
End of options marker: 255
[Request In: 13]
[Response Time: 0.049948917 seconds]
[Uri-Path: /a]
Payload: Payload Content-Format: application/octet-stream (no Content-Format), Length: 2
Data (20 bytes)
Data: 3138382e3133342e38362e3232363a3536393131
[Length: 20]

CoAP-Paketanalyse:
Zielhafen -5683, Protokoll UDP.
Der erste übergibt einen Zeiger (Uri-Abfrage: cid=) in der Sekunde wird der Wert zurückgegeben (Daten).
Server static.226.167.34.188.clients.your-server.de(188.34.167.226)
Paketlänge anfordern 89 byte, aus dem die Antwort besteht 41 byte.

Wie Sie sehen, enthält die Antwort in diesem Fall eine Zeichenfolge in Form einer Reihe von Hexadezimalzahlen ohne Leerzeichen:
31 38 38 2e 31 33 34 2e 38 36 2e 32 32 36 3a 35 36 39 31 31
(Diese digitalen Daten können beispielsweise Steuerbefehle für das Endgerät oder umgekehrt Telemetrie für den Server enthalten – Bitfelder über Ein-/Aus-Gerätetasten, Informationen über Temperatur, Spannung, Tonerstand, Anzahl der gedruckten Seiten).

Was ist das Internet-of-Things-Protokoll CoAP?

Das CoAP-Protokoll ist ein vereinfachtes HTTP-Protokoll, das über UDP läuft.
Im Gegensatz zum rein textbasierten HTTP-Protokoll kann CoAP in der Anfrage und Antwort auch binäre Daten übertragen.

Da UDP keine Zustellung garantiert, ist eine Empfangskontrolle implementiert.

Um Übertragungskanalressourcen zu sparen, verwendet das CoAP-Protokoll sehr häufig „ Huckepack " antworten. (In der Logistik im Bereich Gütertransport ist dieser Begriff „Huckepack" bedeutet vorbeifahrende Frachtlieferung). Hier wird zusammen mit der Quittung sofort das Ergebnis der Bearbeitung der Anfrage übermittelt.

ДляBei der Übertragung von Text in Anfragen und Antworten wird die UTF-8-Kodierung verwendet. Wird ein String als Request oder Payload verwendet, darf seine Länge 270 Byte nicht überschreiten. Was wird für Geräte mit geringem Stromverbrauch (mit wenig RAM) getan? Einige Tags können jedoch mehrmals wiederholt werden, um alle erforderlichen Informationen zu übermitteln.

Sicherheit: Die Antwort muss mit der Anfrage übereinstimmen („Request/Response Matching“_).
Bei einer Huckepack-Antwort muss das Antworttoken mit dem Anforderungstoken übereinstimmen.

Anfrage:
Anfrage

Antwort:
Antwort

Ich stelle fest, dass die Zeit zwischen Anfrage und Antwort kurz ist – nur 50 Millisekunden.

Beschreibung der Anfrage- und Antwortfelder

Die Optionen werden in zwei Gruppen unterteilt: „kritisch“ und „optional“. Der Unterschied besteht darin, wie nicht erkannte Parameter vom Endpunkt verarbeitet werden:

Optionale Parameter MÜSSEN stillschweigend ignoriert werden, wenn ihr Wert vom Endpunkt nicht erkannt wird.
Nicht erkannte Parameter der „kritischen“ Klasse in einer korrekt verfassten Anfrage MÜSSEN einen „Bad Option“-Fehler verursachen. Diese Antwort muss eine für Menschen lesbare Fehlermeldung enthalten.
alle nicht erkannten „kritischen“ Nachrichten in der Antwort MÜSSEN mit einer Neustartnachricht abgelehnt werden
Optionale Parameter in der Serverantwort, die vom Client nicht erkannt werden, MÜSSEN stillschweigend ignoriert werden.

Kritische und optionale Meldungen sind von „erforderlichen“ Meldungen zu unterscheiden. Keine Option in CoAP ist obligatorisch. Alle diese Regeln sind darauf ausgelegt, unerkannte (oder nicht realisierte) Anfragen und Antworten zu verarbeiten.

Nein.	Kritisch	Name	Formatieren	Länge, Bytes	Beschreibung
1	JA	Inhaltstyp	uint	0-2	Nachrichtenformattyp 0 – Text/Plain; charset=utf-8 40 – application/link-format 41 – application/xml 42 – application/octet-stream 47 – application/exi 50 = application/json
2	nein	Maximales Alter	uint	0-4	Standardmäßig 60 Sekunden – maximale Antwortzeit in Sekunden von 0 bis 2^32-1
3	JA	Proxy-URI	Zeichenfolge	1-270	Die Anfrage richtet sich an den Proxy, nicht an den Server. Enthält einen URI für eine Anfrage an einen Proxy; Proxy-Uri kann als Anfrage an einen Cache betrachtet werden.
4	nein	ETag	versteckt	1-8	Zusätzliche „Verknüpfung“ zur Sicherheitsüberprüfung. Die Antwort wird nur zurückgegeben, wenn die Etag-Prüfung durch den Server erfolgreich ist. Wenn die Überprüfung erfolgreich ist, ist der Server verpflichtet, eine Antwort zu senden.
5	JA	Uri-Host	Zeichenfolge	1-270	Internet-Host – ein Server, der Anfragen bearbeitet.
6		Standort-Pfad	Zeichenfolge	1-270	Ähnlich wie Uri-Path, kann jedoch in einer Anfrage	mehrmals angegeben werden
7	JA	Uri-Hafen	uint	0-2	Internet-Port auf dem Server
8		Standort-Abfrage	Zeichenfolge	1-270	Ähnlich wie Uri-Query, kann jedoch in einer Abfrage	mehrmals angegeben werden
9	JA	Uri-Pfad	Zeichenfolge	1-270	Internet – absoluter Pfad auf dem Server zur Ressource
11	JA	Token	versteckt	1-8	Sicherheitstoken (Token in Antwort und Anfrage müssen übereinstimmen)
12	nein	Akzeptieren	uint	0-2	Informationen zu den vom Client akzeptierten Datentypen finden Sie unter Content-Type
13	JA	If-Match	versteckt	0-8	Voraussetzungen. Die Antwort wird nur empfangen, wenn die Bedingung erfüllt ist (zusammen mit dem ETag-Tag) – wird für gleichzeitige Anfragen zum Aktualisieren von Daten von mehreren Clients verwendet, um ein Überschreiben von Daten zu vermeiden
15	JA	Uri-Abfrage	Zeichenfolge	1-270	Der Name der Zielressource auf dem Zielserver. Kann alle Zeichen außer „.“ enthalten. Und "..". Die Kodierung von (russischen) Buchstaben mit % wird nicht verwendet. Es sind nur UTF-8-Zeichen impliziert.
21	JA	If-None-Match	nein	0	Umgekehrte If-Match-Bedingung. Die Antwort erfolgt nur, wenn die Bedingung erfüllt ist nicht abgeschlossen. Siehe If-Match – die Betriebslogik ist umgekehrt.

Schlussfolgerungen:

Die Untersuchung von Internet-of-Things-Paketen mit WireShark enthüllt nur den externen Teil des Protokolls (Sie können die IP-Adresse des Servers, die angeforderte URI-Ressource und die Antwort herausfinden – Daten in verschlüsselter oder anderweitig für Menschen unleserlicher Form).
Obwohl die Anfrage und die Daten entschlüsselt wurden, ist es unmöglich, die interne Logik der Anwendung zu verstehen: herauszufinden, wofür das Gerät bestimmt ist und wer der Eigentümer der Domain ist, an die die Daten gesendet wurden.
Die von mir abgefangenen Pakete sind sehr kurz – etwa 40–89 Byte lang. Pakete kommen in Gruppen: Anfrage-Antwort.
Der Zeitraum zwischen Übertragungen (Paketen und Gruppen) kann im CoAP-Standard sehr groß sein – von mehreren Minuten bis hin zu vielen Monaten und sogar Jahren.

CoAP mit DTLS schützen

Wenn erhöhte Sicherheit und Schutz der Inhalte vor dem Lesen und Ändern während der Übertragung erforderlich sind, kann CoAP zusammen verwendet werden DTLS- Implementierung von TLS über UDP. Bei der Verwendung von DTLS werden Verbindungen und Protokolle sowie die Daten selbst geschützt.

Quellen:

Blog über Radio und Linux