Skip to main content

5.7 拥有证明负载 (Proof of Possession Payload)

拥有证明(Proof of Possession, POP)负载用于证明发送方拥有某个私钥。在GDOI中,POP负载主要用于GROUPKEY-PUSH消息的源认证。

POP负载格式​

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Next Payload  !   RESERVED    !         Payload Length        !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
!                                                               !
~                         Signature                             ~
!                                                               !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

字段说明:

  • Next Payload: 下一个负载的类型
  • Payload Length: 负载的总长度
  • Signature: 数字签名数据

POP的用途​

在GDOI中,POP负载用于:

源认证​

证明GROUPKEY-PUSH消息确实来自授权的GCKS:

  • 防止伪造: 防止攻击者伪造GROUPKEY-PUSH消息
  • 非对称认证: 使用公钥密码学提供源认证
  • 补充KEK保护: 在KEK加密的基础上增加额外的认证层

委托密钥管理​

当使用委托密钥管理时,POP负载证明代理GCKS被授权发送GROUPKEY-PUSH消息。

签名计算​

签名覆盖GROUPKEY-PUSH消息的以下部分:

签名输入​

Signature = SIGN(
  ISAKMP Header |
  SEQ Payload |
  SA Payload (if present) |
  KD Payload (if present) |
  Delete Payload (if present)
)

注意:

  • 签名在KEK加密之前计算
  • 签名不包括POP负载本身
  • 签名使用GCKS的私钥

签名算法​

签名算法在SA KEK负载的SIG_ALGORITHM属性中指定,可以是:

  • RSA签名: RSA with SHA-1, RSA with SHA-256等
  • DSA签名: DSA with SHA-1
  • ECDSA签名: ECDSA with SHA-256等

具体的签名算法参数在SA KEK负载中定义(见5.3.7节)。

在GROUPKEY-PUSH中的使用​

包含POP负载​

GCKS可以 (MAY) 在GROUPKEY-PUSH消息中包含POP负载:

HDR*, SEQ, [SA,] [KD,] [POP,] [D]

何时使用POP​

POP负载在以下情况下推荐使用:

  1. 委托密钥管理: 多个GCKS可以发送GROUPKEY-PUSH时
  2. 高安全要求: 需要额外源认证保证的群组
  3. KEK妥协担忧: 担心KEK可能被妥协的环境

POP负载的位置​

POP负载通常放在GROUPKEY-PUSH消息的末尾,在所有其他负载之后。

验证过程​

GCKS的操作​

发送带POP的GROUPKEY-PUSH时,GCKS:

  1. 构造消息: 构造包含SEQ, SA, KD, D等负载的消息
  2. 计算签名: 使用私钥对消息内容签名
  3. 添加POP: 将签名添加到POP负载中
  4. 加密消息: 使用KEK加密整个消息(包括POP)

组成员的操作​

接收带POP的GROUPKEY-PUSH时,组成员:

  1. 解密消息: 使用KEK解密消息
  2. 提取签名: 从POP负载中提取签名
  3. 验证签名: 使用GCKS的公钥验证签名
  4. 检查有效性: 确保签名覆盖所有相关负载
  5. 处理消息: 如果签名有效,处理消息内容

如果签名验证失败,组成员必须 (MUST) 拒绝该消息。

公钥分发​

为了验证POP,组成员需要GCKS的公钥:

公钥获取方式​

  1. 第1阶段: 在ISAKMP第1阶段交换中通过证书获取
  2. 预配置: 预先配置GCKS的公钥或证书
  3. 带外: 通过安全的带外机制获取
  4. 证书链: 从可信的证书颁发机构(CA)验证证书链

证书验证​

组成员应该 (SHOULD) 验证GCKS证书:

  • 有效期: 检查证书是否在有效期内
  • 撤销状态: 检查证书是否已被撤销(如通过CRL或OCSP)
  • 信任链: 验证到可信根CA的证书链
  • 用途: 确保证书被授权用于GDOI签名

与KEK认证的关系​

GROUPKEY-PUSH消息受到双重保护:

KEK加密和认证​

  • 加密: KEK提供机密性
  • 完整性: KEK(通过AEAD或HMAC)提供完整性
  • 对称认证: 任何拥有KEK的成员都可以解密和验证消息

POP签名​

  • 源认证: POP证明消息来自特定的GCKS
  • 非对称认证: 只有GCKS可以生成签名,所有成员可以验证
  • 防止内部攻击: 防止拥有KEK的恶意成员伪造GROUPKEY-PUSH

两者结合提供更强的安全保证。

性能考虑​

POP负载增加了计算和通信开销:

计算开销​

  • 签名生成: GCKS需要为每个GROUPKEY-PUSH执行签名操作
  • 签名验证: 所有组成员需要验证签名

通信开销​

  • 签名大小:
    • RSA-2048: ~256字节
    • ECDSA-256: ~64字节
  • 带宽影响: 在大型群组中,额外的字节可能显著影响网络带宽

优化策略​

  • 选择性使用: 仅在必要时使用POP(如委托场景)
  • ECDSA: 使用ECDSA减少签名大小
  • 批处理: 在多个更新之间批处理以减少签名次数

安全考虑​

POP负载提供额外的安全保证:

优势​

  • 防止伪造: 防止攻击者伪造GROUPKEY-PUSH消息
  • 委托支持: 支持安全的密钥管理委托
  • 内部攻击防护: 防止拥有KEK的恶意成员的攻击
  • 责任追溯: 提供消息来源的可审计证据

要求​

  • 私钥保护: GCKS的私钥必须 (MUST) 受到严格保护
  • 签名强度: 签名算法必须 (MUST) 具有足够的强度
  • 证书管理: 需要适当的证书生命周期管理
  • 时钟同步: 证书验证需要合理准确的时钟

限制​

  • 不防止KEK妥协: 如果KEK被妥协,POP无法防止密钥材料泄露
  • 性能开销: 增加计算和通信开销
  • 复杂性: 增加实现和管理复杂性

示例​

带POP的GROUPKEY-PUSH​

GCKS生成:
  构造消息体:
    SEQ = 100
    KD = [新的TEK密钥]
  
  计算签名:
    sig_input = HDR | SEQ | KD
    signature = RSA-Sign(sig_input, GCKS_private_key)
  
  添加POP:
    POP = { signature }
  
  加密:
    encrypted_msg = KEK-Encrypt(HDR | SEQ | KD | POP)

组成员验证:
  解密:
    HDR | SEQ | KD | POP = KEK-Decrypt(encrypted_msg)
  
  提取签名:
    signature = POP.signature
  
  验证签名:
    sig_input = HDR | SEQ | KD
    result = RSA-Verify(sig_input, signature, GCKS_public_key)
  
  如果result == valid:
    处理KD负载,安装新TEK
  否则:
    拒绝消息,记录错误
Last updated on