CoAP over DTLS在资源受限环境中的挑战

最新推荐文章于 2025-11-09 03:42:02 发布

原创最新推荐文章于 2025-11-09 03:42:02 发布 · 830 阅读

8 ·

CC 4.0 BY-SA版权

文章标签：

#DTLS # 能耗 # CoAP # 资源受限 # 握手

在资源受限环境中部署CoAP over DTLS的挑战

摘要

在物联网（IoT）世界中，大量资源受限设备可直接通过互联网访问。为了使资源受限设备能够交换信息，互联网工程任务组（IETF）标准组制定了运行在UDP/IP之上的受限应用协议（CoAP）。同时，建议使用数据报传输层安全（DTLS）绑定来保障CoAP的安全性。当启用DTLS时，设备可在三种安全模式中选择其一：预共享密钥模式、原始公钥模式和证书模式。特别是原始公钥模式，该模式使用非对称密钥对而不使用证书，是实现基于DTLS的受限应用协议所必须支持的模式。但在资源受限设备中使用基于非对称密钥的安全模式存在诸多挑战。本文比较了使用对称密钥的原始公钥模式和预共享密钥模式，以探讨DTLS在资源受限设备和网络中的性能。为进行比较，我们在Cooja模拟器以及真实测试平台中，基于由资源受限设备组成的IEEE 802.15.4无线网络构建了实验环境。随后，我们从代码大小、能耗以及处理和接收时间等方面分析了比较结果。

关键词 ：DTLS Handshake Energy消耗 Internet物联网 Cooja模拟器

1 引言

物联网（IoT）技术最近在世界范围内受到关注。每个物联网对象通过连接互联网与人类或其他对象进行通信。物联网提供上下文感知服务，因此对象应根据服务需要充当服务器或客户端。因此，在物联网环境中应考虑通用的客户端‐服务器模型中的安全威胁及相应的安全技术 [1]。

如今，各种安全技术正在应用于具有充足计算资源的设备中。特别是，非对称密钥加密算法被用于基于Web的电子商务、电子邮件和即时通讯广泛使用的传输层安全协议中[2]。已知非对称密钥加密算法比对称密钥加密算法慢数百倍。对于现有互联网中拥有充足资源的设备而言，这并不是问题。然而，在物联网设备中应用安全技术需要克服三个限制。首先，

物联网设备的计算资源有限，例如中央处理器、内存和电池。物联网设备通常以嵌入式设备的形式存在，因此即使包含嵌入式设备的产品（如汽车或冰箱）体积较大，其本身尺寸仍然较小。这意味着中央处理器、内存或存储性能较低。设备性能低下可能限制安全协议的选择。第二，许多情况下电源无法得到保障，因此依赖电池供电，并需确保用户可接受的运行时间。这意味着能耗在物联网安全中是一个非常重要的因素。第三，由于价格与设备性能之间的权衡，安全性往往被忽视。尽管设备尺寸相同，但成本会因性能不同而有所差异。为了满足产品生产企业的成本节约需求以及消费者希望购买更便宜产品的经济逻辑，物联网设备通常仅具备最低限度的性能。这意味着安全性可能会被牺牲。鉴于此，互联网工程任务组的LWIG工作组根据数据大小和代码大小对资源受限设备进行了分类，如表 1[3]所示。

0类设备没有足够的资源来安全且直接地连接互联网，完全受限。因此，0 类设备需要借助代理或网关等基础设施设备。1类设备在使用超文本传输协议、传输层安全协议（TLS）和基于XML的数据表示等完整协议栈连接互联网时仍存在一些限制。如果采用专为受限节点设计的基于UDP协议栈的受限应用协议（CoAP），1类设备便无需其他设备帮助即可连接互联网。2类设备支持现有互联网中使用的大多数协议。然而，建议使用轻量级协议栈以降低开发成本并提高互操作性[3]。

受限应用协议是物联网设备的应用层协议，由互联网工程任务组标准化 [4]。受限应用协议类似于超文本传输协议，但为了考虑传输效率，使用UDP而非TCP。在安全性方面，推荐使用基于UDP的传输层安全协议（即数据报传输层安全（DTLS））作为受限应用协议的事实标准安全协议。这一点类似于超文本传输协议使用传输层安全协议的安全机制 [5]。

然而，DTLS协议并非为受限环境设计，而受限应用协议则是为受限的物联网环境设计的。此外，尽管DTLS使用UDP，但其性能仍低于传输层安全协议。原因是DTLS增加了额外的功能，以弥补UDP不提供可靠性的问题，而传输层安全协议则依赖于TCP提供的可靠性。DTLS协议分为两个独立的阶段[5]，如下所述。（1）支持相互认证和密钥协商的握手阶段。该阶段生成安全凭证（包括对称密钥）。（2）加密

表1. 资源受限设备的类别（来源：[3]）
| Name | 数据大小（例如，RAM）代 | 码大小（例如，Flash） |
| — | — | — |
| 类别0（C0）类别1（C1） | ≪ 10 KiB *10 KiB | ≪ 100 KiB |
| 类别2（C2） | *50 KiB | * 100 KiB |
| | | * 250 KiB |

使用握手阶段生成的安全密钥发送经过认证和加密的数据的数据传输阶段。

在握手阶段，可以使用基于对称密钥或非对称密钥的密码套件作为加密密钥交换算法。根据密码套件的选择，性能上会产生较大差异。如果使用基于 PSK的密码套件，性能优异，但需要预先设置共享安全密钥，存在一定的局限性。另一方面，基于非对称密钥的密码套件可以在无需设置PSK系统的情况下建立安全连接，但会带来其他负担，例如公钥认证和管理。此外，由于计算量巨大，其性能下降的问题也广为人知。在个人计算机和服务器上使用基于非对称密钥的TLS时，用户通常不会感受到明显的性能差异。然而，一般的非对称密钥算法在配备8*16 MHz CPU的资源受限设备上并不容易运行。尽管如此，仍定义了四种模式用于在CoAP中使用DTLS安全协议。特别是，在这四种模式中，使用非对称密钥的RawPublicKey模式被指定为强制性要求[4]。

本文中，我们研究了DTLS协议的性能问题，该协议被互联网工程任务组、 OneM2M和开放移动联盟等多个国际标准组织推荐为物联网设备的安全协议。特别是，我们希望讨论在资源受限环境中使用DTLS协议时存在的具体问题，如下所述。
- 在资源受限设备中实现DTLS时应考虑的代码大小。
- 在受限设备上使用DTLS的能耗。
- 低功耗有损网络（LLN）中的数据传输效率。

本文组织如下。在第2节中，我们讨论推荐使用受限应用协议/DTLS的标准趋势及相关工作。在第3节中，我们描述了用于分析的测试环境。在第4节中，对代码大小、能耗和数据传输速率进行了分析和讨论。最后，我们在第5节中进行总结。

2 预备知识

2.1 标准趋势

韩国的TTA、美国的TIA和ATIS、欧洲的ETSI、中国的CCSA，以及日本的TTC和 ARIB等七个区域性标准组织参与了OneM2M。OneM2M为智能家居、智能汽车和智能医疗等各种物联网应用服务定义了通用平台，即公共服务实体（CSE）和应用实体（AE）。OneM2M考虑采用TLS或DTLS来保障AE/CSE之间的安全通信。它定义了两种需应用的密码套件：TLS_PSK_WITH_AES_128_CCM_8 和 TLS ECDHE ECDSA _ _ _ _ _ _ _ _ _ WITH_AES_128_CCM_8。此外，OneM2M合作项目的技术全体会议通过提供 MQTT、受限应用协议、可扩展消息与存在协议和HTPP等多种传输技术的绑定作为通信协议，提高了各种协议的兼容性 [7]。

在DTLS上部署受限应用协议的挑战 271

在支持CSE和绑定的OneM2M协议中，MQTT通过传输层安全协议提供安全系统，但其基于TCP通信。然而，随着当前对基于UDP的通信系统的考虑，使用DTLS作为MQTT协议的安全协议也自然被提上日程。

此外，与互联网工程任务组类似，DTLS也被视为受限应用协议的事实安全协议。当使用DTLS时，提出了以下四种模式[4]：NoSec、PreSharedKey、 RawPublicKey和证书模式。其中，必须实现NoSec模式和RawPublicKey模式[4]。NoSec模式在传输层不提供加密。PreSharedKey模式要求设备具有预共享密钥，且需要1:1的节点/密钥比例，预共享密钥用于验证是否为该组的设备。在原始公钥模式中，通过验证是否为适当的设备来识别设备。在证书模式中，可通过基于证书的机制进行认证和密钥交换。然而，在计算资源受限的物联网环境中，使用DTLS可能会引发各种问题。因此，有必要分析在DTLS中使用每种密码套件时的性能。

2.2 相关工作

已有研究提出用于分析和解决在资源受限的物联网环境中使用DTLS时出现的性能问题。现有研究比较了握手过程中所需的时间和内存大小，并对比了能耗。

表2. 相关工作
| 论文 | [8] | [9] | [10] | [11] | [12] WisMote Z | 方案 1, Sky |
| — | — | — | — | — | — | — |
| 设备 | Opal传感器 | TelosB | WisMote | WisMote, STGreenNet | | |
| 安全模式 | 证书 | Raw 公共 Key tinyECC T | 证书 inyDTLS tin | 原始公共 Key yECC | PSK | 预共享密钥 & 原始公共 Key |
| 库 | OpenSSL, CyassL, tinyECC | | 证书 inyDTLS tin | | Lithe | TinyDTLS |
| 代码大小 | 已测试 | Not tested | 已测试 | 未测试 | 已测试 | 已测试 |
| 处理 Time | 已测试 | Not tested | 已测试 | 已测试 | 已测试 | 已测试 |
| 能源消耗 | 已测试 | 已测试 | 未测试 | 已测试 | 已测试 | 已测试 |

如果每种条件下的实验都已进行，我们在表 2 中每一行所需内存、处理时间和能耗处标记了 ‘test’。

尽管能耗是性能评估中的一个重要因素，但目前尚无研究从能耗角度准确聚焦于[4]中提出的四种模式。此外，由于各项研究使用了不同的设备和不同的库来获取结果，因此难以进行比较。

3 评估环境

本章介绍了我们用于分析资源受限网络中DTLS握手操作的代码大小、能耗以及传输效率的评估环境。DTLS握手阶段由六个子过程组成，每个过程如图fi所示称为一次flight，如图 1所示。握手处理的 DTLS 与 TLS 类似，但 DTLS 增加了第2和第3飞行阶段，以防止由 UDP 特性引起的拒绝服务攻击。与 TLS 一样，第4次飞行和第5次飞行中用虚线标示的部分仅在使用基于非对称密钥的密码套件时才使用，而在使用基于对称密钥的密码套件时则被忽略。

在实验环境中，我们使用了被称为最轻量级DTLS实现的TinyDTLS库。我们还使用了广泛用作物联网设备轻量级操作系统的Contiki操作系统。最新版本的TinyDTLS（即版本0.8.2）支持三种主要的加密原语——作为对称密钥的高级加密标准，以及基于非对称密钥、由C语言开发的椭圆曲线迪菲‐赫尔曼临时密钥交换和椭圆曲线数字签名算法。

通过使用这些原语，当前的TinyDTLS仅支持DTLS标准中规定的两种密码套件[5]。表3总结了我们在环境中使用的其他组件和工具。

请注意，我们的评估基于仿真和真实测试平台。我们使用了Contiki操作系统中包含的Cooja模拟器，特别是用于测量能耗。在真实测试平台网络中，采用了IEEE 802.15.4。该模拟器提供了与采用IEEE 802.15.4无线环境的轻量级设备规格相同的虚拟设备。

示意图0

在DTLS上部署受限应用协议的挑战 273

4 实验结果与分析

4.1 代码大小

Contiki操作系统的代码大小约为36*44KiB，具体取决于是否启用了提供的功能，以及缓冲区和队列等的优化方法。在本实验中，我们分析了将DTLS应用于被归类为1类的Zolteria Z1设备时的代码大小。由于固件大小超过了轻量级设备的ROM容量，因此无法使用Contiki中默认提供的配置状态构建包含 TinyDTLS的固件。为此，我们移除了实验中一些不必要的功能，以获得足够的内存空间。此外，我们禁用了TCP功能，并在‘contiki‐conf.h’文件中减小了部分QUEUE的大小。通过使用msp430‐gcc编译器生成ELF格式的固件文件，然后利用msp430‐objcopy命令处理该固件文件，获得了可上传至设备 ROM的固件大小。

表 4. Contiki OS的TinyDTLS固件大小（单位：字节）
| 设备角色预共享密钥 | 70,153 7 | ECC 8,061 7 | 预共享密钥 + 9,621 |
| — | — | — | — |
| 客户端 | 69,119 7 | 7,143 7 | 8,885 |
| 服务器 | | | |

椭圆曲线加密

274 H. Kwonet al.

在Cooja模拟器提供的13种轻量级设备中，实际可用于仿真的设备为五种设备。表 5详细描述了这五种轻量级设备。其中能够执行DTLS的设备有三种：WisMote，Zolteria Z1和Exp430F5438。尽管Tmote Sky与Zolteria Z1同属于1类，但其性能低达 2倍。由于ROM容量较小，甚至无法加载仅应用基于对称密钥的密码套件的代码。

TinyDTLS 由多个模块组成，这些模块分别位于独立的 C files 中，包括算法、加密、哈希、会话管理、队列管理。在构建过程files 中生成每个模块的目标文件。通过使用 msp430‐size命令，我们确认了文本、数据和 bss 段的大小。构成 TinyDTLS 的主要模块的源代码名称及其大小如图 2.

dtls.c 是实现 DTLS 协议的核心文件，具有最大的代码大小。rijndael.c 文件包含对称密钥算法，其大小是包含非对称密钥算法的 ecc.c 文件的两倍。尽管 ecc.c 中的计算量更为复杂，但由于 rijndael.c 中使用了固定大小的替换盒（S‐BOX），其代码大小甚至比 ecc.c 更大。

通过本次实验，我们确认在1类设备上，若不进行优化，则无法使用当前分发状态下的TinyDTLS。TinyDTLS目前仅支持两种密码套件。然而，根据管理符合互联网标准的密码套件的互联网号码分配机构（IANA）标准，目前已有大约300种密码套件[14]。这意味着如果需要额外的密码套件以实现相互兼容，则必须添加加密相关的算法代码，从而导致代码大小增加。

表5. Cooja模拟器支持的设备
| Mote | 闪存 | RAM 4Kib 7 | CPU .37 MHz C 兆赫兹 | TinyD | TLS类 |
| — | — | — | — | — | — |
| MicaZ Exp430F5438 2 | 128 KiB 56千字节 3 256千字节 | 2千字节 8 32千字节 1 8千字节 | CPU .37 MHz C 兆赫兹 | | X |
| | 128 KiB 56千字节 3 256千字节 | 2千字节 8 32千字节 1 8千字节 | 6兆赫兹 | C2 | O |
| Wismote | 128 KiB 56千字节 3 256千字节 | 2千字节 8 32千字节 1 8千字节 | 8兆赫兹 | C2 | O |
| Zolteria Z1 | 92千字节 48 KiB 1 | 0KiB 3.9 | MHz | C1 | O |
| Tmote Sky | | 0KiB 3.9 | | C1 | X |

在DTLS上部署CoAP的挑战 275

4.2 能耗

轻量级设备中DTLS的能耗由握手阶段的密钥交换算法、数据加密算法以及网络条件决定。在硬件规格和加密算法确定后，由于操作引起的能耗在重复测量中通常保持恒定，不会发生显著变化。然而，在无线网络中，尽管环境相同，但由于无法控制的外部环境因素，测量结果存在较大的波动。因此，本文排除了网络设备带来的能耗，仅考虑对称密钥与非对称密钥算法运算操作所消耗的能源。在本实验中，我们使用了Cooja模拟器和Zolteria Z1设备。为了测量 Contiki中DTLS的能耗，我们还使用了一个内置函数energest_type_time()。该函数与硬件测量仪器[15]相比，已知具有94%的准确度。该函数返回从设备启动到调用该函数为止所使用的CPU时间。CPU时间以时钟节拍为单位进行测量，时钟节拍是设备实际使用中央处理器的基本时间单位。通过将获得的时钟节拍值应用于设备制造商提供的数据手册中的能耗参数，我们可以得到代码执行时所需的能耗。

276 H. Kwon等

我们分析了使用对称密钥时的能耗，并通过与非对称密钥方法的能耗进行比较来加以说明。图3显示了在握手阶段的每一次传递中，使用对称密钥算法时以毫安为单位的能耗量。fl 能耗’的总和，第1、3、5次飞行中的3.501毫安，是客户端在握手阶段消耗的能源量。同样，第2、4、6次飞行的总和4.654毫安，是服务器消耗的能源量。握手阶段的时间平均为6.6秒。为了计算每秒的能耗，我们将服务器和客户端的能耗除以总的握手时间。图4显示了基于图3中的能耗测量结果，在服务器和客户端重复执行DTLS会话时，不同电池容量下的寿命情况。

TinyDTLS存在一个漏洞，即在使用TLS_ECDHE_ECDSA_WITH_AES _128_CCM_8密码套件时，第4次飞行后程序会因堆栈溢出而立即停止。由于此问题，我们无法获取属于1*2类的轻量级设备上非对称密钥的能耗。

TinyDTLS不仅可在Contiki上运行，还具有可在Linux上运行的兼容性。因此，在本文中，作为替代方案，我们通过比较在Linux环境下运行相同TinyDTLS时对称密钥与非对称密钥算法各自的CPU时间，来估算轻量级设备上的能耗。在本次非对称密钥实验所使用的设备中，包括一台配备700兆赫CPU并安装 Raspbian Linux的树莓派，以及一台配备3.2吉赫CPU并安装Ubuntu Linux 的一般个人计算机。编译器采用gcc，编译器优化选项的应用方式与Contiki中使用的选项相同。此外，与Contiki中的energest_type_time()函数类似，它使用clock_gettime()函数来测量计算量，该函数返回进程所使用的CPU时间。

表 6. 基于非对称密钥的握手的替代结果
| 实验 | 树莓派预共享密钥 ECC | 树莓派预共享密钥 ECC | 个人计算机预共享密钥 ECC | 个人计算机预共享密钥 ECC |
| — | — | — | — | — |
| 实验 | | | 0.003 0 | .108 |
| 经过时间（秒） 0.058 2.053 | | | | |
| CPU 时间（时钟周期） | 5978 | 2,052,804 260 | | 109,429 |

在DTLS上部署CoAP的挑战 277

在轻量级设备中使用非对称密钥算法并结合表6中的数值时，预期值如下。首先，如果握手耗时假设增加35倍，则预期耗时约为3分钟以及51秒。就CPU时间而言，这是决定能耗的最主要因素，即使粗略假设增长速率为200倍，与使用AA型电池基础下可使用约6个月的对称密钥相比，非对称密钥很难使用超过一周。

4.3 握手时间

无线环境中的数据传输性能通常受传输延迟和分片的影响。特别是，分片越多，传输延迟率越高，而传输量越大以及多跳网络环境会使传输延迟率增加至 NlogN。同样，如果DTLS握手消息发生分片，则数据处理性能会进一步恶化。当使用非对称密钥时，如图中实线部分所示，1处理过程中传输数据会变大。

在无线标准IEEE 802.15.4中，该标准被开发用于个人网络（低功耗个人局域网），为提高无线性能效率，链路层的MTU定义为127字节。换言之，在链路层中超过127字节的较大帧总是会发生分片。为了防止在子层中产生因分片而导致的数据丢失，DTLS标准已定义为可在DTLS层直接支持分片。

为了确认DTLS协议在802.15.4环境中的影响，我们在真实测试平台上搭建了两个独立的 802.15.4网络，具体如下：首先，两个独立的低功耗有损网络通过边界路由器连接到互联网

278 H. Kwon等

充当网关。出于实验效率考虑，未使用TinyDTLS代码，而是实现了作为Contiki操作系统服务器/客户端程序的虚假DTLS。虚假DTLS模拟了TinyDTLS中每个飞行阶段的传输大小。通过在Tmote Sky设备上应用虚假DTLS，使服务器和客户端能够通过互联网相互访问。此外，通过在边界路由器和测量设备之间添加一个设备，我们测量了基于多跳的时间。各设备放置在室内实验室走廊中，间隔为10米。

表 7显示了握手阶段中每个飞行阶段发送的数据大小及是否发生分片的情况。通过此数据可以确定DTLS握手传输数据大小在802.15.4无线环境下的影响。在本文的实验环境中，当应用数据超过59字节时会发生分片。在基于对称密钥的握手阶段，10次传输中有3次发生分片；而在基于非对称密钥的握手阶段，15次传输中有8次发生分片。这意味着基于非对称密钥的握手阶段发生网络延迟的概率更高。

当应用表7中的分片时，各多跳的握手阶段耗时如图5所示。耗时在虚假 DTLS中测量，不包括处理时间。在基于对称密钥的握手情况下，HOP4的时间比HOP 1增加了9.05秒。相比之下，基于非对称密钥的握手时间增加了22.76秒。这是因为传输次数、通信量和分片率均高于基于对称密钥的情况。fic和分片率均高于基于对称密钥的情况。

在DTLS上部署CoAP的挑战 279

5 结论

本文讨论了在资源受限环境中DTLS的性能问题。我们比较了CoAP/DTLS绑定中规定的RawPublicKey模式和PreSharedKey模式，并从代码大小、能耗以及处理和接收时间方面分析了比较结果。结果表明，属于1类的设备（例如 Zolteria Z1）可以使用PreSharedKey模式。我们还表明，RawPublicKey模式无法在1类和2类设备，尽管在DTLS上实现受限应用协议是强制性的。作为一个替代实验，我们可以了解到，在资源受限环境中使用原始公钥模式存在困难。我们期望分析结果可用于设计安全的物联网环境。