当前位置：首页 > news >正文

【ZeroRange WebRTC】数字签名与 WebRTC 的应用（从原理到实践）

news 2025/11/11 7:27:09

数字签名与 WebRTC 的应用（从原理到实践）

本文面向工程实践，系统讲解数字签名的安全目标、典型算法（RSA-PSS、ECDSA、Ed25519）、与哈希/HMAC/加密的关系、在 PKI/X.509 中的角色，以及在 WebRTC 中如何通过 DTLS 证书指纹建立信任，防止中间人攻击。

概览：数字签名解决什么问题

目标：认证（谁发的）、完整性（未被篡改）、不可否认（事后不能否认）。
与哈希/HMAC的区别（深入理解）：
- 哈希（SHA-256/512/3）：
  - 核心性质：仅提供“内容指纹”，可检测改动，但不包含“是谁说的”。
  - 密钥与验证：不使用密钥，任何人可重新计算同一摘要；不具备认证与不可否认。
  - 典型用途：文件校验、证书指纹展示、密码存储的底层组件（需搭配加盐与专用函数）。
- HMAC（HMAC-SHA256 等）：
  - 核心性质：完整性 + 对称认证（双方共享同一个密钥）。
  - 密钥与验证：只有持有共享密钥的一方能生成/验证；第三方无法“公开验证”。
  - 不可否认性：不具备（双方都能生成，无法证明具体是谁发的）。
  - 典型用途：API 请求签名、TURN 临时凭证（用户名+时间戳的 HMAC）、Webhook 校验。
- 数字签名（RSA-PSS/ECDSA/Ed25519）：
  - 核心性质：完整性 + 认证 + 不可否认（公开可验证）。
  - 密钥与验证：发送者用私钥签名，任何人用公钥验证；无需共享密钥。
  - 典型用途：证书与握手（TLS/DTLS）、合同/票据签名、代码签名。

实际选择建议：

内部系统的点对点鉴别与速率控制：优先 HMAC（性能高、实现简单）。
需要公开可验证的身份证明或法律证据：必须使用数字签名（RSA-PSS/ECDSA/Ed25519）。

认证、完整性、不可否认：原理与实践

核心定义

认证：确认消息或连接的“发件人是谁”，把主体身份与其控制的秘密（私钥/凭证）绑定并可验证。
完整性：确保消息在传输/存储过程中未被更改，任何改动都会被检测出来。
不可否认：发送者事后不能否认“自己发过这条消息”，需公开可验证与有证据链。

技术实现

认证：
- 基于密钥/凭证（私钥签名、公钥验证；账号口令、多因子；设备证书、OIDC 会话）。
- 身份绑定（X.509）：由 CA 将公钥与主体标识绑定并签名，形成信任链。
完整性：
- 哈希（SHA-256/512/3）：生成摘要检测改动，但不具“认证”。
- HMAC：完整性+对称认证；共享密钥场景（API、TURN 临时凭证）。
- 数字签名：完整性+公开认证（RSA-PSS/ECDSA/Ed25519）。
不可否认：
- 数字签名为关键；任何人用公钥验证签名且只可能由私钥持有者产生。
- 证据链：可信时间源、证书链/撤销、审计日志（时间戳、会话/房间/设备ID）。

三者关系与对比

哈希：仅完整性；不能回答“谁发的”，也不具不可否认。
HMAC：完整性+对称认证；不具不可否认（双方都能生成）。
数字签名：完整性+认证+不可否认；适合公开验证场景（证书、合同、握手）。

在 WebRTC 中的体现

认证：
- 信令通道：WSS/HTTPS + 鉴权令牌（JWT/STS/OIDC）确认参与者与房间授权。
- 证书身份：DTLS 握手使用证书；双方在 SDP 交换 a=fingerprint 钉扎证书哈希。
完整性：
- 传输面：DTLS 完成后媒体走 SRTP（AES-GCM 或 AES-CTR+HMAC），包级完整性由 AEAD/MAC 保证。
- 信令面：结构校验与速率限制、防重放（jti/iat/exp）。
不可否认：
- 握手与证书：数字签名确保握手消息与证书归属公开可验证。
- 证据链：指纹匹配、握手/连接日志、证书有效性与撤销状态，支撑事后证明。

威胁与防护示例

指纹替换（MITM）：信令不安全或未鉴权，攻击者替换 SDP 的 a=fingerprint。
- 防护：强制 WSS/HTTPS + 鉴权；应用/后端按房间/设备白名单校验指纹；证书轮转前下发新指纹。
完整性破坏：篡改媒体包或信令消息。
- 防护：SRTP AEAD/MAC、DTLS 记录层完整性、信令的结构校验与速率限制、重放防护。
否认风险：缺日志或只用共享密钥。
- 防护：关键动作用签名或证书握手；保留可审计日志与时间戳；避免用共享密钥做“公共证据”。

实践建议

会话层：强制 WSS/HTTPS；短期令牌绑定用户/设备/房间，最小权限（join/publish/subscribe）。
证书层：DTLS 证书指纹钉扎；谨慎管理证书轮转与撤销。
传输层：优先 AEAD（AES-GCM/ChaCha20-Poly1305）；保证 nonce 唯一；开启 RTCP 反馈（NACK/PLI/TWCC）。
信令层：消息签名或 HMAC（如 TURN 临时凭证）；速率限制、防重放（jti/iat/exp）。
审计：握手失败、指纹不匹配与异常连接报警；保留会话与时间戳上下文。

类比

认证：快递员出示带照片的工作证（证书+签名），你用“公钥”验证其真伪。
完整性：包裹封条未破损（AEAD/MAC），动过手就能看出来。
不可否认：签收单上有快递员签名与时间记录（公开可验证签名+审计）。

签名算法与安全性质

常用算法：
- RSA-PSS（推荐）：基于 RSA，使用 PSS 填充以抵御多种攻击；签名输入通常是消息哈希。
- ECDSA（P-256 等）：椭圆曲线签名，性能好；必须确保随机数 k 不泄露（泄露会暴露私钥），建议使用 RFC 6979 的“确定性 k”。
- Ed25519（EdDSA）：现代曲线签名，简洁高效；平台/库支持需要确认。
安全要点：
- 签名对象是“消息的哈希”，而不是原文直接；确保哈希算法安全（SHA-256/512，或 SHA-3）。
- 选择正确的填充/参数：RSA 应使用 PSS；避免历史的 PKCS#1 v1.5。
- 密钥长度：RSA ≥ 2048（建议 3072），椭圆曲线常用 P-256；Ed25519 固定参数。

数字签名与 PKI（X.509 证书）

证书用途：将“公钥 + 实体标识（域名/组织）”绑定，并由上级 CA 用其私钥签名，形成信任链。
验证：客户端验证证书链（Root→Intermediate→Leaf）、域名（SAN）、有效期与撤销状态（OCSP/CRL）。
指纹：证书的哈希（例如 SHA-256）可作为“指纹”在应用层进行“证书钉扎”（pinning）。

flowchart LRLeaf[站点证书(公钥+标识+签名)] --> IntCA[中间 CA]IntCA --> Root[根 CA]Client[客户端] -->|验证链与域名| LeafClient --> Root

WebRTC 中的签名与信任是如何实现的

DTLS 证书与指纹：
- WebRTC 使用 DTLS 握手进行密钥协商，双方各自提供“DTLS 证书”。
- 证书指纹（如 SHA-256）通过 SDP 的 a=fingerprint 字段交换，双方在握手前“钉扎”对端证书哈希。
- 握手成功后，派生 SRTP/SRTCP 会话密钥，媒体走加密的 SRTP。
关键点：
- WebRTC 的 DTLS 证书通常是自签名（不依赖公共 CA），其信任来源是“指纹一致性”。
- 因此“信令通道必须安全且鉴权”——否则攻击者可替换 SDP 中的指纹，导致中间人攻击。
简化流程：

与传统 TLS 的异同：
- 传统 HTTPS 依赖公共 CA 链与浏览器信任库；WebRTC DTLS 通常采用“指纹钉扎”的信任模型。
- 两者都通过数字签名确保握手消息不可伪造，最终建立对称密钥进行 AEAD（如 AES-GCM）加密。

示例与实践

生成 DTLS（自签）证书与指纹（开发场景示例）：

# 生成 ECDSA 私钥（P-256）
openssl ecparam -genkey -name prime256v1 -noout -out dtls.key
# 生成自签证书（365天，包含 SAN）
cat > dtls.conf <<'EOF'
[ req ]
prompt = no
distinguished_name = dn
req_extensions = req_ext
[ dn ]
CN = webrtc.local
[ req_ext ]
subjectAltName = @alt_names
[ alt_names ]
DNS.1 = webrtc.local
EOF
openssl req -new -key dtls.key -out dtls.csr -config dtls.conf
openssl x509 -req -in dtls.csr -signkey dtls.key -days 365 -out dtls.crt -extensions req_ext -extfile dtls.conf
# 提取 SHA-256 指纹
openssl x509 -in dtls.crt -noout -fingerprint -sha256

在应用层校验 SDP 指纹（示意）：

// 假设通过鉴权的 WSS 信令拿到对端的“期望指纹”（由远端或服务端提供）
const expectedFingerprint = 'AA:BB:...:ZZ';
function parseFingerprint(sdp) {const m = sdp.match(/a=fingerprint:sha-256\s+([A-F0-9:]+)/i);return m ? m[1].toUpperCase() : null;
}
const remoteFp = parseFingerprint(remoteOfferSdp);
if (remoteFp && remoteFp === expectedFingerprint) {// 指纹匹配，接受连接流程
} else {throw new Error('Fingerprint mismatch');
}

注意：浏览器不提供直接验证 API；通常由应用逻辑在“安全的信令层”对比指纹，或由后端在路由层做校验。

常见风险与防护

风险：
- 指纹替换（MITM）：信令不安全或未鉴权 → 攻击者替换 a=fingerprint。
- 证书旋转：新旧证书指纹不一致导致连接失败；需要平滑策略。
防护：
- 信令强制 WSS/HTTPS + 鉴权（短期令牌/会话绑定），并在服务端做指纹校验与速率限制。
- 指纹钉扎与白名单：对特定设备/房间保存历史指纹，证书更换时先下发新指纹再切换。
- TURN 安全：企业网络下走 turns:443；TLS 证书与 SNI 正确。