物联网 CoAP 协议 - 流量研究 | 关于无线电和 Linux 的博客

6月

2021

物联网 CoAP 协议 - 流量研究

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

18 6月 2021 11:35

使用 WireShark，我们能够捕获新 CoAP 网络协议的两个数据包。

受限应用协议（RFC 7252 标准）是为物联网设计的，基于 UDP 运行。这个简单的协议允许机器相互通信（M2M - 机器对机器）。

第一个数据包是对服务器 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]

第二个数据包是服务器响应

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数据包分析：
目的港-5683, 协议 UDP协议。
第一个传递一个指针（ Uri 查询：cid= ）在第二个值返回（数据）。
服务器 static.226.167.34.188.clients.your-server.de(188.34.167.226)
请求数据包长度 89 字节，响应包括 41 字节。

正如您所看到的，在这种情况下，响应包含一组不带空格的十六进制数字形式的字符串：
31 38 38 2e 31 33 34 2e 38 36 2e 32 32 36 3a 35 36 39 31 31
（例如，该数字数据可以包含用于终端设备的控制命令，或者相反，用于服务器的遥测——有关开/关设备按钮的位字段、有关温度、电压、墨粉水平、打印页数的信息）。

什么是物联网协议CoAP

CoAP 协议是运行在 UDP 上的简化 HTTP 协议。
与严格基于文本的 HTTP 协议不同，CoAP 还可以在请求和响应中传输二进制数据。

由于UDP不保证传送，因此实现接收控制。

为了节省传输信道资源，CoAP协议经常使用“小猪背着”回答。（在货物运输领域的物流中，这个术语“背驮式“ 的意思是 过路货物交付 ）。在这里，处理请求的_结果_与收据一起立即发送。

Для在请求和响应中传输文本时，使用 UTF-8 编码。如果使用字符串作为请求或负载，则其长度不超过 270 字节。针对低功耗设备（具有少量 RAM）所做的事情。但某些标签可能会重复多次以传达所有必要的信息。

安全性 ：响应必须与请求匹配（“请求/响应匹配”）。
在捎带响应中，响应令牌必须与请求令牌匹配。

要求：

答：

我注意到请求和响应之间的时间很短 - 仅 50 毫秒。

请求和响应字段的描述

选项分为两组：“关键”和“可选”。区别在于端点如何处理_无法识别的_参数：

可选参数，如果端点无法识别它们的值，则必须默默地忽略它们。
正确组成的请求中“关键”类的无法识别的参数必须导致“错误选项”错误。此响应必须包含人类可读的错误消息。
响应中所有无法识别的“关键”消息必须通过重新启动消息来拒绝
客户端无法识别的服务器响应中的可选参数必须被静默忽略。

关键和可选消息应与“强制”消息区分开来。 CoAP 中的选项不是强制性的。所有这些规则都是为了处理无法识别（或未实现）的请求和响应而设计的。

编号	关键	名称	格式	长度，字节	描述
1	是	内容类型	单位	0-2	消息格式类型 0 - 文本/纯文本； charset=utf-8 40 - 应用程序/链接格式 41 - 应用程序/xml 42 - 应用程序/八位字节流 47 - 应用程序/exi 50 = application/json
2	没有	最大年龄	单位	0-4	默认情况下 60 秒 - 最大响应时间（以秒为单位）从 0 到 2^32-1
3	是	代理 Uri	字符串	1-270	1-270请求是发送给代理的，而不是发送给服务器的。包含向代理请求的 URI； Proxy-Uri 可以被认为是对缓存的请求。
4	没有	电子标签	隐藏	1-8	1-8安全验证的附加“捷径”。只有服务器 Etag 检查成功后才会返回响应。如果验证成功，服务器“有义务”发送响应。
5	是	Uri-主机	字符串	1-270	1-270互联网主机 - 服务请求的服务器。
6		位置-路径	字符串	1-270	1-270与Uri-Path类似，但可以在一个请求中指定多次
7	是	乌里港	单位	0-2	服务器上的 Internet 端口
8		位置查询	字符串	1-270	1-270与Uri-Query类似，但可以在一个查询中指定多次
9	是	Uri路径	字符串	1-270	1-270互联网-服务器上资源的绝对路径
11	11是	代币	隐藏	1-8	1-8安全令牌（响应中的令牌和请求必须匹配）
12	12没有	接受	单位	0-2	对于客户端接受的数据类型，请参阅 Content-Type
13	是	如果匹配	隐藏	0-8	先决条件。仅当满足条件（与 ETag 标记一起）时才会收到响应 - 用于从多个客户端更新数据的并发请求，以避免数据覆盖
15	是	Uri 查询	字符串	1-270	1-270目标服务器上的目标资源的名称。可以包含除“.”之外的任何字符和 ”..”。不使用使用 % 的（俄语）字母编码。仅隐含 UTF-8 字符。
21	21是	如果-无-匹配	没有	0	反转 If-Match 条件。仅当条件满足时才会出现响应未完成。请参阅 If-Match - 操作逻辑相反。

结论：

使用 WireShark 研究物联网数据包仅揭示协议的外部部分（您可以找到服务器的 IP 地址、请求的 URI 资源和响应 - 编码或其他人类无法读取形式的数据）。
尽管请求和数据已被解码，但无法理解应用程序的内部逻辑：找出设备的用途以及发送数据的域的所有者是谁。
我截获的数据包非常短——大约 40-89 字节长。数据包分组：请求-响应。
CoAP 标准中的传输（数据包和组）之间的时间周期可能相当长——从几分钟到几个月甚至几年。

使用 DTLS 保护 CoAP

如果需要提高安全性并保护内容在传输过程中不被读取和修改，可以一起使用CoAP 数据传输层安全- 通过 UDP 实施 TLS。使用 DTLS 时，连接和协议以及数据本身都受到保护。

资料来源：

关于无线电和 Linux 的博客