Protocole CoAP pour l'Internet des objets - étude du trafic

juin

2021

Protocole CoAP pour l'Internet des objets - étude du trafic

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

18 juin 2021 11:35

Grâce à WireShark, nous avons pu capturer deux paquets du nouveau protocole réseau CoAP.

Contrained Application Protocol (norme RFC 7252) est conçu pour l'Internet des objets et fonctionne sur la base d'UDP. Ce protocole simple permet aux machines de communiquer entre elles (M2M – machine to machine).

Le premier paquet est une requête de périphérique adressée au serveur 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]

Le deuxième paquet est la réponse du serveur

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]

Analyse des paquets CoAP :
Port de destination -5683, protocole UDP.
Le premier passe un pointeur (Requête Uri : cid=) dans le second, la valeur est renvoyée (Données).
Serveur static.226.167.34.188.clients.votre-serveur.de(188.34.167.226)
Longueur du paquet demandé 89 octet, la réponse consiste en 41 octet.

Comme vous pouvez le constater, dans ce cas, la réponse contient une chaîne sous la forme d'un ensemble de nombres hexadécimaux sans espaces :
31 38 38 2e 31 33 34 2e 38 36 2e 32 32 36 3a 35 36 39 31 31
(Ces données numériques peuvent contenir, par exemple, des commandes de contrôle pour l'appareil final ou, à l'inverse, des télémétries pour le serveur - champs de bits sur les boutons marche/arrêt de l'appareil, informations sur la température, la tension, le niveau de toner, le nombre de pages imprimées).

Qu'est-ce que le protocole CoAP de l'Internet des objets

Le protocole CoAP est un protocole HTTP simplifié fonctionnant sur UDP.
Contrairement au protocole HTTP, qui est strictement basé sur du texte, CoAP peut également transmettre des données binaires dans la requête et la réponse.

Puisque UDP ne garantit pas la livraison, un contrôle de réception est mis en œuvre.

Afin d'économiser les ressources du canal de transmission, le protocole CoAP utilise très souvent "Ferrouté" réponse. (En logistique dans le domaine du transport de marchandises, ce terme "ferroutage" signifie livraison de marchandises en transit). Ici, avec le récépissé, le résultat du traitement de la demande est immédiatement envoyé.

ДляLors de la transmission de texte dans les requêtes et les réponses, le codage UTF-8 est utilisé. Si une chaîne est utilisée comme requête ou charge utile, sa longueur ne dépasse pas 270 octets. Ce qui est fait pour les appareils à faible consommation (avec une petite quantité de RAM). Mais certaines balises peuvent être répétées plusieurs fois pour véhiculer toutes les informations nécessaires.

Sécurité: La réponse doit correspondre à la requête ("Request/Response Matching").
Dans une réponse superposée, le jeton de réponse doit correspondre au jeton de demande.

Demande :
demande

Réponse :

Je remarque que le temps entre la demande et la réponse est court – seulement 50 millisecondes.

Description des champs de requête et de réponse

Les options sont divisées en deux groupes : « critiques » et « facultatives ». La différence réside dans la manière dont les paramètres unrecognized sont traités par le point de terminaison :

Les paramètres facultatifs, si leur valeur n'est pas reconnue par le point d'extrémité, DOIVENT être ignorés en silence.
les paramètres non reconnus de la classe "critique" dans une requête correctement composée DOIVENT provoquer une erreur "Bad Option". Cette réponse doit inclure un message d'erreur lisible par l'homme.
tous les messages "critiques" non reconnus dans la réponse DOIVENT être rejetés avec un message de redémarrage
Les paramètres facultatifs dans la réponse du serveur non reconnus par le client DOIVENT être ignorés en silence.

Les messages critiques et facultatifs doivent être distingués des messages « obligatoires ». Aucune option en CoAP n’est obligatoire. Toutes ces règles sont conçues pour gérer les demandes et réponses non reconnues (ou non réalisées).

N°	Critique	Nom	Formater	Longueur, octets	Descriptif
1	OUI	Type de contenu	uint	0-2	Type de format de message 0 - texte/plain ; charset=utf-8 40 - application/link-format 41 - application/xml 42 - application/octet-stream 47 - application/exi 50 = application/json
2	non	Âge maximum	uint	0-4	60 secondes par défaut - temps de réponse maximum en secondes de 0 à 2^32-1
3	OUI	Proxy-Uri	chaîne	1-270	La demande est adressée au proxy et non au serveur. Contient un URI pour une demande à un proxy ; Proxy-Uri peut être considéré comme une requête vers un cache.
4	non	Etag	caché	1-8	« Raccourci » supplémentaire pour la vérification de sécurité. La réponse ne sera renvoyée que si la vérification Etag par le serveur réussit. Si la vérification réussit, le serveur est obligé d'envoyer une réponse.
5	OUI	Uri-Hôte	chaîne	1-270	Hôte Internet - un serveur servant les requêtes.
6		Emplacement-Chemin	chaîne	1-270	Similaire à Uri-Path, mais peut être spécifié plusieurs fois dans une requête
7	OUI	Uri-Port	uint	0-2	Port Internet sur le serveur
8		Localisation-Requête	chaîne	1-270	Similaire à Uri-Query, mais peut être spécifié plusieurs fois dans une requête
9	OUI	Uri-Chemin	chaîne	1-270	Internet - chemin absolu sur le serveur vers la ressource
11	OUI	Jeton	caché	1-8	Jeton de sécurité (le jeton en réponse et la demande doivent correspondre)
12	non	Accepter	uint	0-2	Pour les types de données acceptés par le client, voir Content-Type
13	OUI	Si-Match	caché	0-8	Conditions préalables. La réponse ne sera reçue que si la condition est remplie (avec la balise ETag) - utilisée pour les demandes simultanées de mise à jour des données de plusieurs clients afin d'éviter l'écrasement des données
15	OUI	Uri-Requête	chaîne	1-270	Le nom de la ressource de destination sur le serveur de destination. Peut contenir n'importe quel caractère sauf "." Et "..". L'encodage des lettres (russes) à l'aide de % n'est pas utilisé. Seuls les caractères UTF-8 sont implicites.
21	OUI	Si aucune correspondance	non	0	Inverser la condition If-Match. La réponse ne viendra que si la condition pas terminé. Voir If-Match - la logique de fonctionnement est inversée.

Conclusions :

L'étude des paquets de l'Internet des objets à l'aide de WireShark ne révèle que la partie externe du protocole (vous pouvez connaître l'adresse IP du serveur, la ressource URI demandée et la réponse - données sous forme codée ou autrement illisible pour les humains).
Bien que la requête et les données aient été décodées, il est impossible de comprendre la logique interne de l'application : savoir à quoi est destiné l'appareil et qui est le propriétaire du domaine où les données ont été envoyées.
Les paquets que j'ai interceptés sont très courts - environ 40 à 89 octets de long. Les paquets sont groupés : requête-réponse.
L'intervalle de temps entre les transmissions (paquets et groupes) dans la norme CoAP peut être assez important - de quelques minutes à plusieurs mois, voire plusieurs années.

Protéger CoAP avec DTLS

Si une sécurité accrue est nécessaire et une protection du contenu contre la lecture et la modification pendant la transmission, CoAP peut être utilisé ensemble.DTLS- implémentation de TLS sur UDP. Lors de l'utilisation de DTLS, les connexions et les protocoles sont protégés, ainsi que les données elles-mêmes.

Sources :

Blog sur la Radio et Linux