CoAP（受限应用协议）作为物联网领域轻量级RESTful通信协议，通常承载在UDP之上。由于UDP本身无连接且不可靠，直接在公网或共享网络中传输CoAP报文会面临数据泄露与伪造风险。DTLS（Datagram Transport Layer Security）是TLS的UDP适配版本，能在保留无连接特性的同时提供加密、完整性校验与身份认证。Ruby语言虽不以嵌入式著称，但在物联网网关、边缘代理以及测试工具开发中常被使用，因此用Ruby实现CoAP的DTLS安全传输具有实际工程价值。本文将围绕预共享密钥（PSK）与证书认证（Certificate）两种模式，说明其原理、Ruby代码组织方式以及落地注意事项。
预共享密钥模式的工作原理与Ruby实现
预共享密钥模式是指通信双方预先协商好一组密钥标识（PSK Identity）和对应的密钥值（PSK Key），在DTLS握手阶段的ClientKeyExchange与ServerKeyExchange中，直接使用这些材料派生会话密钥，而不依赖非对称加密做密钥交换。该模式计算量小，适合CPU与内存受限的传感器节点，缺点是密钥分发与管理复杂，且不具备前向保密能力（若PSK泄露，历史流量可被解密）。
在Ruby中，可以使用openssl标准库配合支持DTLS的底层绑定，或采用coap与dtls相关gem。下面示例展示一个基于OpenSSL的DTLS客户端使用PSK的简单骨架。代码中的psk_identity与psk_key需与服务端一致。
require 'openssl'
require 'socket'
udp = UDPSocket.new
udp.connect('192.168.0.1', 5684)
ctx = OpenSSL::SSL::SSLContext.new
ctx.dtls = true
ctx.ciphers = 'PSK-AES128-CCM8'
ctx.psk_identity = 'device-001'
ctx.psk_key = OpenSSL::PKCS5.pbkdf2_hmac('shared-secret', 'salt', 1000, 16, 'sha256')
ssl = OpenSSL::SSL::SSLSocket.new(udp, ctx)
ssl.connect
ssl.puts('GET /sensor/temp')
puts ssl.gets
ssl.close
上述代码通过ctx.psk_identity和ctx.psk_key设置预共享材料，并强制使用PSK系列加密套件。实际工程中，PSK Key不应硬编码在源码，而应从安全存储或环境变量读取。同时，服务端需开启对应UDP端口的DTLS监听，并校验Identity合法性，防止非法设备接入。
PSK模式虽简单，但运维时需建立密钥轮换机制。例如每台设备出厂烧录独立PSK，云端按设备ID管理密钥生命周期。若某设备被攻破，可单独吊销其PSK而不影响其他节点。Ruby侧可借助配置中心或数据库动态加载PSK列表，在握手回调中匹配Identity。
证书认证模式的握手流程与代码配置
证书认证模式沿用TLS的X.509证书体系，客户端与服务端各自持有私钥与证书，握手时互相验证对方证书链，再通过非对称加密协商出会话密钥。该模式支持双向认证（mTLS），安全性强，且可结合CA签发实现大规模身份管理。代价是握手阶段需进行RSA或ECDSA运算，对极低端设备不够友好，但在Ruby网关或边缘服务器上完全可行。
以下示例展示Ruby DTLS服务端加载证书与私钥，并要求客户端证书的配置方式。注意证书文件需提前由CA签发，且verify_mode设为对等验证。
require 'openssl'
require 'socket'
server = UDPSocket.new
server.bind('0.0.0.0', 5684)
ctx = OpenSSL::SSL::SSLContext.new
ctx.dtls = true
ctx.cert = OpenSSL::X509::Certificate.new(File.read('server.crt'))
ctx.key = OpenSSL::PKey::RSA.new(File.read('server.key'))
ctx.ca_file = 'ca.crt'
ctx.verify_mode = OpenSSL::SSL::VERIFY_PEER | OpenSSL::SSL::VERIFY_FAIL_IF_NO_PEER_CERT
ctx.ciphers = 'ECDHE-ECDSA-AES128-CCM8'
loop do
ssl = OpenSSL::SSL::SSLSocket.new(server, ctx)
ssl.accept
data = ssl.gets
ssl.puts("echo: #{data}")
ssl.close
end
代码中VERIFY_FAIL_IF_NO_PEER_CERT确保客户端必须提供证书，否则握手中断。若仅需服务端认证（单向TLS），可去掉该标志，但CoAP物联网场景推荐双向认证以防伪造终端。Ruby的OpenSSL绑定对DTLS支持依赖底层C库版本，部署前应确认系统OpenSSL高于1.1.1，否则可能出现dtls属性不可用。
证书模式还可结合OCSP或CRL做实时吊销检查，不过UDP场景超时敏感，通常改为定期拉取吊销列表缓存。此外，证书有效期管理是关键，Ruby程序可集成定时任务，在证书临近过期前自动向CA申请续签并热加载，避免链路中断。
两种模式的选型对比与混合部署建议
从安全等级看，证书模式提供完整的身份信任链与前向保密，适合网关、云平台以及高价值设备；PSK模式以轻量取胜，适合电池供电且算力弱的终端。二者并非互斥，实际系统常采用混合架构：终端与本地网关用PSK通信，网关与云端用证书模式，既降低终端开销又保障核心链路安全。
下表从多个维度对比两种模式在Ruby实现中的差异：
| 维度 | 预共享密钥 | 证书认证 |
|---|---|---|
| 握手计算量 | 低，无公钥运算 | 高，需ECDSA/RSA |
| 身份管理 | 扁平密钥表 | CA层级、可吊销 |
| 前向保密 | 不支持 | 支持（ECDHE） |
| Ruby依赖 | OpenSSL PSK接口 | OpenSSL X509全套 |
在混合部署时，Ruby边缘程序可同时监听两个DTLS端口或根据SNI扩展分流。例如设备上报使用PSK端口5684，管理后台使用证书端口5685。代码层面可用同一SSLContext模板克隆后分别修改psk_key与cert属性，减少重复逻辑。此外，无论哪种模式，都应启用DTLS的丢包重传与超时参数，因为UDP在弱网易丢包，Ruby默认超时可能过长导致CoAP请求堆积。
最后需要提醒，CoAP的DTLS载荷仍受UDP单包大小限制，证书模式因证书链较长，握手包可能分片，需确保网络MTU或DTLS重传机制正常工作。Ruby测试时可借助wireshark抓UDP 5684端口观察握手是否完整，从而提前发现加密套件不匹配或证书域名校验失败等问题。