LwM2M的身份认证漏洞调研

目录

LwM2M的身份认证漏洞调研

目录

简介

LwM2M的体系架构

LwM2M 的资源模型

LwM2M的关键特性

LwM2M的消息协议

Bootstrap

DTLS的安全性

DTLS 在身份认证上的潜在漏洞

DTLS 相关 CVE 漏洞及其对 LwM2M 的潜在影响

结论

简介

LwM2M（Lightweight Machine-to-Machine）是一个为物联网设备设计的轻量级协议，可用于快速部署客户端/服务器模式的物联网业务。LwM2M的传输层协议为UDP或者SMS，其安全协议为DTLS。其身份认证贯穿于设备与服务器交互的多个阶段。身份认证的目标是确保设备和服务器能够相互验证身份，建立安全通信通道。

LwM2M的体系架构

1. LwM2M 客户端：这是运行在设备上的组件，负责管理本地资源并与 LwM2M 服务器进行通信。

2. LwM2M 服务器：这是管理 LwM2M 客户端的远程实体。它处理诸如设备注册、读取和写入资源以及执行命令等任务。

3. 引导服务器：此服务器通过提供初始配置和凭证，帮助设备连接到 LwM2M 服务器

   

LwM2M 的资源模型

LwM2M 使能器（LWM2M Enabler）定义了一个简单的资源模型，其中 LwM2M 客户端提供的每条信息都被视为一个资源。资源在逻辑上被组织成对象。该图展示了这种结构，以及资源、对象和 LwM2M 客户端之间的关系。

OMA 轻量级 M2M（LwM2M）协议使用层次化的对象和资源模型来管理和与物联网设备交互。这一模型将设备的数据和功能组织成定义明确的对象和资源，使得监控、控制和管理设备的各个方面变得更加容易。

1. 对象（Object）：对象代表设备上特定类型的数据或功能。例如，一个对象可以是温度传感器、固件更新机制或连接监控器。

2. 资源（Resource）：每个对象由一个或多个资源组成。资源表示对象中的特定数据或功能。例如，一个温度传感器对象可能包含当前温度读数、传感器的测量单位和传感器状态等资源。

LwM2M的关键特性

1. 设备管理 ：LwM2M 支持设备的远程管理，包括固件更新、配置更改和诊断。

2. 互操作性 ：它通过提供标准化的设备管理和通信框架，确保不同制造商生产的设备之间的互操作性。

3. 高效数据传输 ：LwM2M 针对低功耗设备和带宽有限的网络进行了优化，使用高效的数据编码和传输协议。

4. 安全性 ：它集成了安全功能，如身份验证和加密，以保护数据和设备免受未经授权的访问。

5. 资源模型 ：LwM2M 使用资源模型，每个设备可以暴露一组资源（例如温度传感器读数、电池电量），这些资源可以被服务器访问或操作。

LwM2M的消息协议

LwM2M 协议专为物联网设备的高效管理而设计，它依赖多种传输绑定来实现 LwM2M 客户端、引导服务器和 LwM2M 服务器之间安全可靠的通信。下图描述了 LwM2M 协议栈中可用的各种传输绑定，展示了它们与消息协议的集成。这些传输选项包括基于不同层和技术（如 UDP、TCP、SMS 以及新兴的非 IP 协议）的 CoAP，确保 LwM2M 能够适应广泛的网络环境，实现无缝的设备通信和管理。此外，结合这些传输绑定的 OSCORE 的使用提供了增强的安全性，满足现代物联网部署的多样化需求。

Bootstrap

Bootstrap过程是LwM2M设备生命周期的起点，用于初始化设备并为其提供连接LwM2M Server所需的凭据和配置信息。它直接涉及身份认证，因为设备需要验证Bootstrap Server的身份，同时Bootstrap Server可能需要验证设备的合法性。

客户端发起的引导（PSK 模式）概述

在客户端发起的引导中，LwM2M 客户端主动联系 LwM2M 引导服务器（Bootstrap-Server），通过 CoAP 协议（基于 UDP）获取连接目标 LwM2M 服务器所需的配置和安全凭证。在 PSK 模式下，DTLS 使用预共享密钥进行双向认证和会话密钥生成，确保通信的安全性。PSK 模式因其计算开销低，非常适合资源受限的物联网设备。

目标

• 客户端从引导服务器获取新的安全对象实例（Security Object, Object ID: 0），用于后续与目标 LwM2M 服务器通信。

• DTLS（PSK 模式）保护客户端与引导服务器之间的 CoAP 通信。

前提条件

• 客户端预先配置了一个针对引导服务器的安全对象实例，包含引导服务器的 URI 和 PSK 凭证。

• 客户端和引导服务器共享一个预共享密钥（PSK）及其对应的身份（Identity）。

---

详细流程（PSK 模式）

以下是客户端发起引导的步骤，重点突出 DTLS 在 PSK 模式下的作用，以及密钥的具体使用。

1. 客户端准备

• 初始安全对象（针对引导服务器）

  • 在出厂时或通过其他方式（如智能卡）预置，存储在客户端的非易失性存储中。

  • 示例

  资源编号	资源名称	值	用途	格式
  0	LwM2M Server URI	coaps://bootstrap.example.com:5684	指定引导服务器的地址，coaps 表示使用 DTLS 的 CoAP。	URI
  1	Bootstrap-Server	true	表明这是一个引导服务器。	布尔值
  2	Security Mode	0	指定使用 PSK 模式。	整数
  3	Public Key or Identity	"client123"	PSK 身份标识（PSK Identity），用于在 DTLS 握手中标识客户端。	字符串，通常是唯一的客户端标识
  4	Server Public Key	空	PSK 模式不依赖公钥，因此此资源通常未使用。	空
  5	Secret Key	0x1a2b3c4d5e6f7g8h(16字节，128位)	预共享密钥（PSK），客户端和引导服务器共享的秘密值。	高熵随机值，避免使用低熵密码或可猜测的值

• 端点名称: 客户端的唯一标识，例如 urn:uuid:123e4567-e89b-12d3-a456-426655440000，用于引导请求。

2. DTLS 连接建立（PSK 模式）

• 目标: 客户端与引导服务器建立安全的 CoAP 通道。

• 协议: CoAP over UDP，使用 DTLS 1.2（RFC 6347）保护。

• DTLS 握手过程:

• DTLS 的作用:

  • 双向认证: 客户端和服务器通过共享的 PSK 验证对方身份。

  • 机密性: 会话密钥（例如 AES-128-CCM）加密数据。

  • 完整性: AEAD（如 CCM）或 MAC（如 SHA256）保护数据不被篡改。

  • 防重放: DTLS 序列号（每个数据包递增）防止重放攻击。

3. 发送引导请求

• CoAP 请求:

  • 方法: POST

  • 路径: /bs

  • 参数: ep={endpoint}

  • 示例: POST coaps://bootstrap.example.com:5684/bs?ep=urn:uuid:123e4567-e89b-12d3-a456-426655440000

  • 数据格式: 无需额外负载，端点名称在 URI 参数中。

  • 加密: DTLS 会话密钥加密请求（例如使用 AES-128-CCM）。

• 目的: 通知引导服务器客户端需要配置。

4. 引导服务器配置客户端

• 服务器响应:

  • 引导服务器通过 CoAP 操作向客户端写入新的安全对象实例（针对目标 LwM2M 服务器）。

  • 典型操作（假设仍使用 PSK 模式）:

    • PUT /0/1/0 -> coaps://server.example.com:5684（目标服务器 URI）

    • PUT /0/1/1 -> false（非引导服务器）

    • PUT /0/1/2 -> 0（PSK 模式）

    • PUT /0/1/3 -> "device456"（新 PSK 身份）

    • PUT /0/1/5 -> 0xa1b2c3d4e5f6g7h8（新 PSK 密钥，128 位）

    • PUT /0/1/10 -> 12345（Short Server ID）

  • 加密: 所有 PUT 请求通过 DTLS 会话密钥加密。

• 密钥分配:

  • 引导服务器生成新的 PSK 身份和密钥：

    • PSK Identity: "device456"，唯一标识客户端与目标服务器的会话。

    • PSK: 0xa1b2c3d4e5f6g7h8，高熵随机值，由引导服务器生成并安全传输。

  • 安全性要求: 新 PSK 必须唯一且不可预测，避免重用初始 PSK。

5. 客户端保存配置并断开

• 客户端将新安全对象存储到非易失性存储中。

• 关闭 DTLS 会话:

  • 发送 CloseNotify 消息，通知服务器会话结束。

  • 释放会话密钥。

6. 后续连接目标服务器

• 使用新配置的安全对象（/0/1），通过 DTLS（PSK 模式）连接目标服务器：

  • URI: coaps://server.example.com:5684

  • PSK Identity: "device456"

  • PSK: 0xa1b2c3d4e5f6g7h8

• 重复 DTLS 握手过程，进入注册阶段。

---

DTLS 在 PSK 模式下的具体作用

1. 双向认证

2. 会话密钥生成

3. 数据保护

• 加密:

  • 使用 AES-128-CCM（认证加密模式，AEAD）。

  • 每个 CoAP 数据包加密后附加 8 字节标签（Tag），确保机密性。

• 完整性:

  • CCM 模式内置完整性检查，无需额外 MAC。

• 序列号:

  • DTLS 为每个数据包分配递增序列号，防止重放攻击。

基于 DTLS 的安全性

安全要求

对于通信中 LwM2M 实体的身份认证，LwM2M 协议要求 LwM2M 客户端与 LwM2M 服务器之间，以及 LwM2M 客户端与 LwM2M 引导服务器之间的所有通信必须使用双向认证进行验证。

对于通信中 LwM2M 实体之间信息的机密性和数据完整性，LwM2M 协议要求 LwM2M 客户端与 LwM2M 服务器之间，以及 LwM2M 客户端与 LwM2M 引导服务器之间的所有通信必须经过加密并保证完整性保护。这意味着：

由于引导信息的敏感性，必须特别注意确保这些数据的保护。使用 DTLS能够满足这些要求。

DTLS 的概述

CoAP使用 DTLS 1.2 版进行保护，该协议基于 TLS v1.2 [RFC5246]。DTLS 是为基于数据报的协议（如 UDP）设计的通信安全解决方案。它提供了安全的握手机制，包括会话密钥生成、双向认证、数据完整性和机密性。

DTLS 客户端和 DTLS 服务器应当尽可能长时间地保持安全状态，例如会话密钥、序列号、初始化向量以及其他通过 DTLS 建立的安全参数，前提是不会危及安全上下文的完整性。如果这些状态在睡眠周期中（此时 RAM 断电）仍然存在，则应当使用安全存储来保存安全上下文。

LwM2M 引导服务器、LwM2M 服务器和 LwM2M 客户端必须使用不同的密钥对。LwM2M 客户端必须使用对每个 LwM2M 客户端唯一的密钥。当一个 LwM2M 客户端被配置为使用多个 LwM2M 服务器时，LwM2M 引导服务器可以为这些 LwM2M 服务器配置不同的凭证。这种配置提供了更好的不可关联性，因为各个 LwM2M 服务器无法基于 LwM2M 客户端使用的凭证来关联请求。具体的部署和应用需求决定了采用何种方法。

密码套件

DTLS 支持密码套件的概念，这些套件在 DTLS 握手过程中被安全协商。LwM2M推荐使用有限数量的密码套件。所推荐的密码套件因其适合物联网设备、安全性原因以及提升互操作性而被选中，并且取决于所使用的凭证类型，因为密码套件的概念还指明了认证和密钥交换机制。LwM2M 客户端和 LwM2M 服务器可以支持符合最新安全要求的额外密码套件。

需要注意的是，在 DTLS 中使用基于 CBC（密码块链接）的密码套件时，必须谨慎处理以下两个原因：

1. 在 TLS 1.1 之前，初始化向量（IV）的选择存在缺陷。解决方法是使用 TLS 1.1 或更高版本，对于早期版本可以通过记录分割（record splitting）来解决。由于本规范依赖 DTLS 1.2，此问题不适用。

2. 实现经过认证的解密（检查填充和消息认证码，MAC）时，避免任何侧信道攻击非常困难（参见 Lucky 13 攻击及其变种）。解决方法是使用 RFC 7366 中定义的“先加密后MAC”（encrypt-then-mac）扩展，这一扩展是推荐使用的。

DTLS的安全性

DTLS 在身份认证上的潜在漏洞

DTLS虽然设计上继承了TLS的安全性，但在实际应用中，尤其是在物联网场景下，存在一些漏洞或弱点。这些漏洞可能源于协议实现、配置错误或资源受限环境的限制。以下是详细分析：

1. 弱密码套件（Weak Cipher Suites）

• 漏洞描述：DTLS支持多种密码套件（如TLS_RSA_WITH_AES_128_CBC_SHA），但如果使用过时或不安全的套件，可能被破解。例如，CBC模式易受填充预言攻击（Padding Oracle Attack），而弱密钥长度（如56位DES）可被暴力破解。

• LwM2M相关性：LwM2M设备常在低功耗环境下运行，可能默认使用弱套件。

1. 证书验证不严格（Improper Certificate Validation）

• 漏洞描述：在证书模式下，如果客户端未正确验证服务器证书（如忽略吊销状态或信任链），可能接受伪造证书。服务器也可能未要求客户端证书（单向认证），降低身份验证强度。

1. PSK管理问题（Pre-Shared Key Exposure）

• 漏洞描述：PSK模式依赖预共享密钥，如果密钥在设备端存储不安全（如明文存储）或重复使用，可能被提取并用于伪造身份。

1. 重放攻击（Replay Attack）

• 漏洞描述：DTLS握手中的消息（如ClientHello）如果未正确使用随机数或时间戳保护，可能被捕获并重放，欺骗服务器接受旧会话。

• LwM2M相关性：在Registration过程中，如果服务器未验证会话新鲜性，可能接受重放请求。

DTLS 相关 CVE 漏洞及其对 LwM2M 的潜在影响

分析已知的 DTLS 相关的 CVE 漏洞，重点探讨它们是否可能影响 LwM2M 客户端发起的引导过程，特别是基于 PSK 模式的 DTLS 的安全性。由于 LwM2M 依赖 DTLS 提供通信安全，任何 DTLS 的漏洞都可能间接影响 LwM2M 的安全性。

---

以下是一些已知的 DTLS 相关 CVE 漏洞，以及它们是否可能影响 LwM2M 客户端发起的引导过程（特别是 PSK 模式）的分析：

1. CVE-2020-11501 (GnuTLS DTLS ClientHello.random 漏洞)

• 描述:

  • GnuTLS（一个常见的 DTLS 实现库）在版本 3.6.3 至 3.6.12 中存在漏洞，客户端在 DTLS 的 ClientHello 消息中始终发送全零的 random 值，而不是随机值。

  • 影响: 如果使用 PSK 模式且没有临时密钥交换（如 ECDHE），攻击者可能利用重复的 random 值执行重放攻击或明文恢复。

  • CVSS 分数: 5.9（中等）。

• 对 LwM2M 的影响:

  • 适用性: LwM2M 客户端在引导过程中使用 DTLS 发送 ClientHello，如果底层实现使用受影响的 GnuTLS 版本，此漏洞可能导致握手中的随机性不足。在纯 PSK 模式（无 ECDHE）下，random 值是会话密钥生成的重要输入。全零 random 可能使会话密钥可预测，从而削弱加密强度，允许攻击者解密引导请求或伪造响应。

  • 具体场景: 如果客户端与引导服务器之间的 DTLS 会话被拦截，攻击者可能重复利用旧的握手数据，伪造配置信息（如新的安全对象），误导客户端连接到恶意服务器。

  • 缓解措施: 更新 GnuTLS 到修复版本（3.6.13 或更高），或确保使用带 ECDHE 的密码套件（LwM2M 规范推荐但非强制）。

2. CVE-2016-2181 (OpenSSL DTLS 重放漏洞)

• 描述: OpenSSL 的 DTLS 实现中存在重放保护缺陷。服务器在验证消息的 MAC（消息认证码）之前更新了重放保护窗口，导致攻击者可以发送未来的 epoch（时期）的记录，绕过重放检查。

漏洞原理

DTLS 使用序列号和 epoch 来防止重放攻击。在正常情况下：

• 每个数据包有唯一的序列号（6 字节，包括 epoch 和 sequence number）。

• 服务器维护一个滑动窗口，丢弃已处理或过期的序列号。

• MAC 验证失败的记录应被丢弃，且不更新窗口。

在受影响的 OpenSSL 版本中：

• 当收到未来 epoch 的记录时，服务器在验证 MAC 之前更新了重放窗口。

• 如果攻击者伪造并重复发送畸形记录，服务器可能接受这些记录，导致重放攻击得逞。

底层实现细节

问题出在 OpenSSL 的 DTLS 记录处理逻辑（ssl/d1_pkt.c）。以下是可能的错误代码重构：

/* 假设的 OpenSSL DTLS 记录处理（受影响版本） */
 #include <openssl/ssl.h>
 ​
 typedef struct {
     unsigned char epoch;        // 1 字节 epoch
     unsigned char seq[5];       // 5 字节序列号
     unsigned char *data;        // 数据
     size_t len;                 // 数据长度
 } dtls_record_t;
 ​
 static int dtls_process_record(SSL *s, dtls_record_t *rec) {
     // 检查 epoch 和序列号
     if (rec->epoch > s->d1->current_epoch) {
         // 漏洞点：在验证 MAC 前更新窗口
         dtls_update_replay_window(s, rec->epoch, rec->seq);
     }
 ​
     // 验证 MAC
     if (!dtls_verify_mac(s, rec)) {
         return -1; // MAC 失败，但窗口已更新
     }
 ​
     // 处理记录
     dtls_handle_record(s, rec);
     return 0;
 }
 ​
 static void dtls_update_replay_window(SSL *s, unsigned char epoch, unsigned char *seq) {
     // 更新重放窗口，滑动到新 epoch
     s->d1->current_epoch = epoch;
     // 更新 bitmap 或序列号范围
 }

• 问题点:

  • dtls_update_replay_window() 在 dtls_verify_mac() 之前调用。

  • 如果 MAC 验证失败，窗口已更新，导致后续合法记录可能被误判为重放而丢弃。

修复版本调整了顺序：

 static int dtls_process_record(SSL *s, dtls_record_t *rec) {
     // 先验证 MAC
     if (!dtls_verify_mac(s, rec)) {
         return -1; // MAC 失败，不更新窗口
     }
 ​
     // MAC 通过后再更新窗口
     if (rec->epoch > s->d1->current_epoch) {
         dtls_update_replay_window(s, rec->epoch, rec->seq);
     }
 ​
     dtls_handle_record(s, rec);
     return 0;
 }

对 LwM2M 的影响

• 场景: LwM2M 客户端发起引导，使用 PSK 模式（TLS_PSK_WITH_AES_128_CCM_8）连接引导服务器。 攻击者可重放客户端的 POST /bs 请求，诱导服务器重复发送新安全对象（如新 PSK 0xa1b2c3d4e5f6g7h8）。若服务器未检测到重放，新 PSK 可能被拦截，导致后续与目标服务器的通信暴露。

3. CVE-2016-6304 (OpenSSL DTLS PSK 密钥处理溢出)

• 描述: OpenSSL 在处理 DTLS PSK 模式下的密钥时存在缓冲区溢出漏洞。攻击者可通过发送超长的 PSK Identity 或畸形握手消息，导致服务器内存溢出，可能引发拒绝服务或潜在的代码执行。

漏洞原理

DTLS PSK 模式在握手中通过 ClientKeyExchange 消息传输 PSK Identity，服务器根据此身份查找对应的 PSK 并生成会话密钥。OpenSSL 的实现中：

• PSK Identity 的长度字段未正确验证。

• 若客户端发送超长 Identity（如超过预期缓冲区大小），会导致堆溢出。

正常流程：

• 客户端发送 ClientKeyExchange，包含 PSK Identity（如 "client123"）。

• 服务器验证长度并分配内存。

漏洞情况：

• 攻击者发送超长 PSK Identity（如 10KB 数据），超过服务器缓冲区限制。

• 未检查长度直接分配内存，导致溢出。

底层实现细节

问题出在 OpenSSL 的 ssl/s3_srvr.c 或 ssl/d1_srvr.c（DTLS 服务器端）。以下是可能的错误代码重构：

 /* 假设的 OpenSSL DTLS PSK 处理（受影响版本） */
 #include <openssl/ssl.h>
 ​
 #define MAX_PSK_IDENTITY_LEN 128 // 预期最大长度
 ​
 static int dtls_process_psk_identity(SSL *s, unsigned char *data, int len) {
     unsigned int id_len = (data[0] << 8) | data[1]; // Identity 长度（2 字节）
     unsigned char *identity = data + 2;
 ​
     // 漏洞点：未检查 id_len 是否超出缓冲区
     unsigned char *psk_id = OPENSSL_malloc(id_len + 1); // 多分配 1 字节用于 null 终止
     if (!psk_id) return -1;
 ​
     memcpy(psk_id, identity, id_len);
     psk_id[id_len] = '\0';
 ​
     // 查找 PSK
     unsigned char psk[32];
     int psk_len = s->psk_server_callback(s, (char*)psk_id, psk, sizeof(psk));
     if (psk_len <= 0) {
         OPENSSL_free(psk_id);
         return -1;
     }
 ​
     // 使用 PSK 生成会话密钥
     // ...
     OPENSSL_free(psk_id);
     return 0;
 }

• 问题点:

  • id_len 未与 MAX_PSK_IDENTITY_LEN 比较。

  • 超长 id_len 导致 OPENSSL_malloc() 分配过大内存，溢出堆，覆盖关键数据。

修复版本增加了长度检查：

static int dtls_process_psk_identity(SSL *s, unsigned char *data, int len) {
     unsigned int id_len = (data[0] << 8) | data[1];
     unsigned char *identity = data + 2;
 ​
     // 修复：检查长度
     if (id_len > MAX_PSK_IDENTITY_LEN || id_len + 2 > len) {
         return -1;
     }
 ​
     unsigned char *psk_id = OPENSSL_malloc(id_len + 1);
     if (!psk_id) return -1;
 ​
     memcpy(psk_id, identity, id_len);
     psk_id[id_len] = '\0';
 ​
     unsigned char psk[32];
     int psk_len = s->psk_server_callback(s, (char*)psk_id, psk, sizeof(psk));
     if (psk_len <= 0) {
         OPENSSL_free(psk_id);
         return -1;
     }
 ​
     OPENSSL_free(psk_id);
     return 0;
 }

对 LwM2M 的影响

• 影响:

  • 消息泄露 :若溢出覆盖服务器内存中的 PSK 或会话密钥，攻击者可能通过后续交互提取这些数据。例如，新分配的 PSK（0xa1b2c3d4e5f6g7h8）可能泄露，危及与目标服务器的通信。

  • PSK 模式是 LwM2M 的核心认证方式，漏洞直接影响引导过程中客户端与服务器的双向认证。

  • 安全对象传输（如新 PSK）是引导的关键步骤，泄露会导致整个信任链崩溃。

4. CVE-2018-0732 (OpenSSL DTLS PSK 会话密钥生成缺陷)

• 描述: OpenSSL DTLS 在 PSK 模式下处理密钥交换时存在缺陷，攻击者可通过发送畸形握手消息，诱导服务器生成弱会话密钥，导致加密数据可被解密。

漏洞原理

DTLS PSK 模式中，会话密钥通过伪随机函数（PRF）从 PSK、客户端随机值（ClientHello.random）和服务器随机值（ServerHello.random）生成。受影响的 OpenSSL 版本中：

• 处理畸形 ClientKeyExchange 时，未正确验证 PSK 参数。

• 若客户端发送无效或截断的 Identity，服务器可能使用部分数据生成密钥，导致弱密钥。

正常流程：

• 客户端发送 ClientKeyExchange，PSK Identity 为 "client123"。

• 服务器使用完整 PSK 和随机值生成 master_secret。

漏洞情况：

• 客户端发送畸形 Identity（如长度为 0 或超短），服务器未拒绝，而是用默认或错误数据生成密钥。

• 会话密钥强度降低，可被暴力破解。

底层实现细节

问题可能出在 ssl/d1_both.c 的密钥生成逻辑。以下是错误代码重构：

/* 假设的 OpenSSL DTLS PSK 密钥生成（受影响版本） */
 #include <openssl/ssl.h>
 ​
 static int dtls_generate_master_secret(SSL *s, unsigned char *psk, int psk_len, 
                                       unsigned char *client_random, 
                                       unsigned char *server_random) {
     unsigned char premaster[32];
 ​
     // 漏洞点：未检查 PSK 是否有效
     if (psk_len <= 0) {
         // 使用默认值或截断数据
         psk_len = 16; // 假设默认长度
         memset(premaster, 0, psk_len); // 弱密钥
     } else {
         memcpy(premaster, psk, psk_len);
     }
 ​
     // 生成 master_secret
     s->session->master_key_length = 48;
     ssl3_generate_master_secret(s, s->session->master_key, premaster, 
                                 client_random, server_random);
     return 0;
 }
 ​
 void ssl3_generate_master_secret(SSL *s, unsigned char *out, unsigned char *premaster, 
                                 unsigned char *client_random, unsigned char *server_random) {
     // PRF 实现（简化）
     // out = PRF(premaster, "master secret", client_random + server_random)
 }

• 问题点:

  • 未验证 psk_len 的有效性。

  • 若 PSK 数据无效，生成弱 premaster，导致 master_secret 可预测。

修复版本添加了验证：

 static int dtls_generate_master_secret(SSL *s, unsigned char *psk, int psk_len, 
                                       unsigned char *client_random, 
                                       unsigned char *server_random) {
     // 修复：检查 PSK 长度
     if (psk_len <= 0 || psk_len > 32) {
         SSLerr(SSL_F_DTLS_GENERATE_MASTER_SECRET, SSL_R_INVALID_PSK);
         return -1;
     }
 ​
     unsigned char premaster[32];
     memcpy(premaster, psk, psk_len);
 ​
     s->session->master_key_length = 48;
     ssl3_generate_master_secret(s, s->session->master_key, premaster, 
                                 client_random, server_random);
     return 0;
 }

对 LwM2M 的影响

• 影响:

1. 消息泄露:弱会话密钥可被暴力破解，解密引导请求（POST /bs）和响应（新 PSK 0xa1b2c3d4e5f6g7h8）。

2. 身份认证威胁:攻击者利用弱密钥伪造客户端或服务器身份，破坏 PSK 认证。

3. 连接中断:若服务器检测到异常，可能拒绝连接，导致引导失败。

结论

LwM2M作为物联网设备管理的轻量级协议，其身份认证过程依赖DTLS在Bootstrap和Registration阶段确保设备与服务器的双向信任。然而，DTLS在实际应用中的安全性并非无懈可击，尤其在物联网资源受限环境下，其弱密码套件、证书验证不严格、PSK管理问题及重放攻击等潜在漏洞显著威胁LwM2M的认证安全。调研中分析的CVE案例表明DTLS的实现缺陷和配置错误可能直接导致LwM2M设备身份认证被攻破，进而引发未授权访问或数据泄露风险。这些漏洞不仅揭示了LwM2M对DTLS的深度依赖，也凸显了针对其身份认证机制进行深入漏洞调研的必要性。