简介ASC X9 TR 34-2019 Preview 是美国国家标准学会认证的 X9 标准委员会于 2019 年 9 月注册发布的技术报告预览版聚焦金融行业对称密钥安全分发场景面向密码学工程师、金融信息安全从业者及标准研究人员。报告核心是阐述如何借助非对称技术基于因子分解的公钥加密实现对称密钥的可互操作分发内容涵盖范围界定、参考文献、术语与定义、符号缩略语以及 TR34 协议概述、证书颁发机构角色、高级协议架构、密钥交换元素、TR34 属性头、临时密钥与重放防护等模块并涉及两遍协议流程可帮助读者理解 CA 信任机制与密钥传输的完整设计思路。资源包为 1 个 PDF 文件大小约 1.07MB属官方预览版本便于快速把握标准框架与目录结构。目前已有 146 人学习下载适合需要对照 ANSI 标准开展密钥管理方案设计与合规评估的技术人员参考。1. 为什么金融支付圈绕不开 TR34 这份密钥分发报告做 POS、ATM、HSM 对接的工程师迟早会在某个接口文档里撞见TR-31、TR-34这两个词。TR-31 管的是密钥块Key Block长什么样TR-34 管的是这些密钥块怎么从一端安全地送到另一端。ASC X9 TR 34-2019 就是这套远程密钥分发Remote Key DistributionRKD方法的现行技术报告全称是《Interoperable Method for Distribution of Symmetric Keys using Asymmetric Techniques: Part 1 – Using Factoring-Based Public Key Cryptography Unilateral Key Transport》。名字很长但拆开看就三件事用非对称技术、单向传输、分发对称密钥。它解决的是一个很具体的痛点两台设备之间要共享一把对称密钥比如 PIN 加密密钥、数据加密密钥但双方没有安全信道也不能人工搬运密钥。TR-34 的做法是让接收方KDHKey Distribution Host生成一对 RSA 密钥把公钥交给发送方KRDKey Receiving Device发送方用这把公钥加密一把临时密钥再用临时密钥加密真正的对称密钥块最后签名打包发过去。整个过程是单向的接收方不需要回传任何密钥材料这也是它被大量用在 ATM 远程换密钥场景的原因。这份 2019 版预览文档覆盖了协议概述、密钥块属性、单向密钥传输、绑定/解绑/重绑定状态机以及 Annex A 的推荐算法和 Annex B 的测试向量。适合谁读做支付终端密钥管理、HSM 指令封装、密钥注入系统的工程师以及需要理解 TR-34 报文结构才能对接第三方密钥中心的开发者。下面按协议原理、报文构造、代码实现、排错验证的顺序拆开讲。2. TR34 单向密钥传输的协议原理与报文结构2.1 两个角色与一次单向传输TR-34 的参与方只有两个KRDKey Receiving Device密钥接收设备和 KDHKey Distribution Host密钥分发主机。注意命名有点反直觉——KRD 是接收密钥的一方KDH 是分发密钥的一方。在 ATM 场景里ATM 是 KRD后台密钥中心是 KDH。协议分两个阶段。第一阶段是绑定Bind双方交换证书和凭证令牌建立信任关系。第二阶段是密钥传输Key TransportKDH 把对称密钥块加密后发给 KRD。整个密钥传输阶段是单向的KDH 发KRD 收KRD 不回传任何密钥材料。这就是 Unilateral Key Transport 的含义。为什么强调单向因为很多终端设备部署在无人值守环境网络可能是单向的或者回传能力受限。单向传输让协议在弱网络下也能工作代价是消息新鲜性要靠时间戳或随机数来保证而不是靠挑战-应答。2.2 TR34 报文的三段式结构一条完整的 TR-34 密钥传输消息由三部分组成文档 5.4.9 节给出了完整定义字段含义关键点TR34 Attribute Header属性头标识协议版本、密钥用法等元信息TR34 Ephemeral Key临时密钥用 KRD 公钥加密的临时对称密钥TR34 Key Block密钥块用临时密钥加密的 TR-31 密钥块Signature签名KDH 对上述内容的数字签名属性头里最关键的是密钥用法和算法标识它决定了接收方怎么解析后面的密钥块。临时密钥是每次传输随机生成的用完即弃这样即使某次传输被破解也只影响那一次。密钥块本身遵循 TR-31 格式包含密钥版本号、算法、密文和完整性校验值。签名覆盖属性头、临时密钥和密钥块用的是 KDH 的私钥。KRD 收到后用 KDH 的公钥验签验签通过才继续解密。这个顺序很重要先验签再解密防止对密文做选择密文攻击。2.3 绑定、解绑、重绑定的状态机文档第 7 章把 KDH 的生命周期拆成几个阶段理解这个状态机是排错的基础Bind绑定KRD 和 KDH 交换证书建立初始信任。KRD 生成密钥对把公钥和证书发给 KDH。Unbind解绑解除绑定关系通常在设备退役或密钥轮换时触发。Rebind重绑定在保持信任链的前提下更换密钥对用于密钥更新。每个阶段都有对应的令牌Token交换。比如 Bind 阶段有 KRD Credential Token 和 KDH Credential TokenUnbind 阶段有 Unbind Token。这些令牌都带随机数和签名防止重放。注意绑定状态是持久化的。如果 KDH 侧记录了绑定关系但 KRD 侧丢失了状态后续密钥传输会直接失败报错通常是签名验证不通过或证书不匹配。生产环境里 KRD 的状态存储要有掉电保护。3. 用 Python 构造一条 TR34 密钥传输消息3.1 环境准备与依赖选择TR-34 本身不规定具体算法Annex A 给了推荐值。常见做法是 RSA-2048 做密钥传输SHA-256 做摘要RSA-PSS 或 RSA-PKCS1v15 做签名。Python 里用cryptography库就能覆盖这些原语不需要自己实现大数运算。pip install cryptography选cryptography而不是pycryptodome是因为它对 OAEP、PSS 这些填充模式的支持更完整而且 API 更贴近标准文档的描述。如果你要对接 HSM最终加密操作会走 PKCS#11但本地开发和测试用cryptography足够。3.2 生成 KRD 密钥对与自签名证书KRD 侧先生成 RSA 密钥对然后签发一张自签名证书生产环境应该由 CA 签发测试环境自签名即可from cryptography.hazmat.primitives.asymmetric import rsa from cryptography.hazmat.primitives import hashes, serialization from cryptography import x509 from cryptography.x509.oid import NameOID import datetime # 生成 KRD 的 RSA 密钥对公钥指数固定 65537 krd_private_key rsa.generate_private_key( public_exponent65537, key_size2048, ) # 构造自签名证书CN 用设备标识 subject issuer x509.Name([ x509.NameAttribute(NameOID.COMMON_NAME, uKRD-TERMINAL-001), ]) cert ( x509.CertificateBuilder() .subject_name(subject) .issuer_name(issuer) .public_key(krd_private_key.public_key()) .serial_number(x509.random_serial_number()) .not_valid_before(datetime.datetime.utcnow()) .not_valid_after(datetime.datetime.utcnow() datetime.timedelta(days365)) .sign(krd_private_key, hashes.SHA256()) ) # 导出私钥和证书私钥用 PKCS#8 格式 with open(krd_private.pem, wb) as f: f.write(krd_private_key.private_bytes( encodingserialization.Encoding.PEM, formatserialization.PrivateFormat.PKCS8, encryption_algorithmserialization.NoEncryption(), )) with open(krd_cert.pem, wb) as f: f.write(cert.public_bytes(serialization.Encoding.PEM))key_size2048是 Annex A 的最低推荐值金融场景里也有用 3072 或 4096 的但 2048 在性能和安全性之间平衡最好。public_exponent65537是标准值不要改成 3虽然理论上可行但很多 HSM 不接受。证书的 CN 用设备唯一标识方便 KDH 侧做白名单校验。3.3 KDH 侧加密临时密钥并封装密钥块KDH 拿到 KRD 的公钥后生成临时密钥用 KRD 公钥加密临时密钥再用临时密钥加密 TR-31 密钥块from cryptography.hazmat.primitives.asymmetric import padding from cryptography.hazmat.primitives.ciphers import Cipher, algorithms, modes import os # 加载 KRD 公钥 with open(krd_cert.pem, rb) as f: krd_cert x509.load_pem_x509_certificate(f.read()) krd_public_key krd_cert.public_key() # 生成 16 字节临时密钥AES-128 ephemeral_key os.urandom(16) # 用 KRD 公钥加密临时密钥OAEP 填充SHA-256 encrypted_ephemeral krd_public_key.encrypt( ephemeral_key, padding.OAEP( mgfpadding.MGF1(algorithmhashes.SHA256()), algorithmhashes.SHA256(), labelNone, ), ) # 构造一个简化的 TR-31 密钥块实际应遵循 TR-31 格式 key_block_plaintext bTR31_KEY_BLOCK_PLACEHOLDER_16B # 用临时密钥做 AES-CBC 加密IV 随机 iv os.urandom(16) cipher Cipher(algorithms.AES(ephemeral_key), modes.CBC(iv)) encryptor cipher.encryptor() # 实际需要 PKCS7 填充这里示意 key_block_ciphertext encryptor.update(key_block_plaintext) encryptor.finalize() # 组装消息属性头 加密临时密钥 IV 密钥块密文 message { header: bTR34\x01, # 版本标识 encrypted_ephemeral: encrypted_ephemeral, iv: iv, key_block: key_block_ciphertext, }padding.OAEP的三个参数必须和 KRD 侧解密时一致mgf和algorithm都选 SHA-256 是 Annex A 的推荐组合。临时密钥长度取决于后面用的对称算法AES-128 就是 16 字节。IV 必须随机且每次不同否则相同明文会产生相同密文泄露模式信息。3.4 对消息签名并序列化最后用 KDH 私钥对消息签名签名覆盖属性头、加密临时密钥和密钥块from cryptography.hazmat.primitives import hashes from cryptography.hazmat.primitives.asymmetric import padding # 加载 KDH 私钥 with open(kdh_private.pem, rb) as f: kdh_private_key serialization.load_pem_private_key(f.read(), passwordNone) # 拼接待签名数据 data_to_sign ( message[header] message[encrypted_ephemeral] message[iv] message[key_block] ) # RSA-PSS 签名盐长度用摘要长度 signature kdh_private_key.sign( data_to_sign, padding.PSS( mgfpadding.MGF1(hashes.SHA256()), salt_lengthpadding.PSS.DIGEST_LENGTH, ), hashes.SHA256(), ) message[signature] signaturepadding.PSS的salt_length用DIGEST_LENGTH是标准做法对应 SHA-256 就是 32 字节盐。有些老系统用 PKCS1v15 签名兼容性更好但安全性略低新系统建议 PSS。签名数据必须按固定顺序拼接任何字段顺序变化都会导致验签失败。4. KRD 侧验签解密与常见失败排查4.1 验签、解密临时密钥、解密密钥块KRD 收到消息后严格按「先验签、再解密」的顺序处理from cryptography.exceptions import InvalidSignature # 加载 KDH 公钥 with open(kdh_cert.pem, rb) as f: kdh_cert x509.load_pem_x509_certificate(f.read()) kdh_public_key kdh_cert.public_key() # 第一步验签 try: kdh_public_key.verify( message[signature], data_to_sign, padding.PSS( mgfpadding.MGF1(hashes.SHA256()), salt_lengthpadding.PSS.DIGEST_LENGTH, ), hashes.SHA256(), ) except InvalidSignature: raise RuntimeError(TR34 签名验证失败消息可能被篡改或 KDH 证书不匹配) # 第二步用 KRD 私钥解密临时密钥 ephemeral_key krd_private_key.decrypt( message[encrypted_ephemeral], padding.OAEP( mgfpadding.MGF1(algorithmhashes.SHA256()), algorithmhashes.SHA256(), labelNone, ), ) # 第三步用临时密钥解密密钥块 cipher Cipher(algorithms.AES(ephemeral_key), modes.CBC(message[iv])) decryptor cipher.decryptor() key_block_plaintext decryptor.update(message[key_block]) decryptor.finalize()验签失败直接终止不要尝试解密。这是防御选择密文攻击的基本要求。解密临时密钥时如果 OAEP 参数不匹配会抛ValueError错误信息通常是 Decryption failed不会告诉你具体哪里错了这是 OAEP 的设计。4.2 典型报错与定位方法实际对接中失败率最高的几个点报错现象可能原因排查方法签名验证失败KDH 证书不匹配、数据拼接顺序错打印双方data_to_sign的 hex 对比OAEP 解密失败填充参数不一致、公钥用错确认双方 mgf 和 hash 都是 SHA-256密钥块解密后乱码IV 不一致、临时密钥长度错检查 IV 是否随消息传输密钥校验值不匹配密钥块格式错、KCV 算法不一致用 Annex B 测试向量验证签名验证失败最常见的原因是数据拼接顺序。TR-34 规定签名覆盖属性头、临时密钥、密钥块但有些实现会把 IV 放在密钥块之后导致双方拼接结果不同。对接时先拿一份已知正确的测试向量跑通再换真实数据。提示Annex B 的测试向量是排错利器。文档里给了完整的输入输出对用这些向量验证你的加解密和签名逻辑能快速定位是算法实现问题还是报文组装问题。4.3 密钥校验值KCV验证密钥块解密后KRD 需要验证密钥是否正确。TR-34 用 KCVKey Check Value做这个校验通常是密钥加密全零块后的前几个字节from cryptography.hazmat.primitives.ciphers import Cipher, algorithms, modes def compute_kcv(key: bytes) - bytes: 计算 AES 密钥的 KCV取加密全零块的前 3 字节 zero_block b\x00 * 16 cipher Cipher(algorithms.AES(key), modes.ECB()) encryptor cipher.encryptor() encrypted encryptor.update(zero_block) encryptor.finalize() return encrypted[:3] # 验证解出的密钥 derived_key key_block_plaintext[:16] # 示意实际按 TR-31 格式解析 kcv compute_kcv(derived_key) print(fKCV: {kcv.hex().upper()})KCV 取 3 字节是行业惯例碰撞概率足够低。如果 KCV 和 KDH 侧声明的不一致说明密钥块解析错了重点检查 TR-31 头部的密钥版本号和算法标识。5. 用测试向量验证实现并处理密钥轮换5.1 拿 Annex B 测试向量做回归Annex B 提供了完整的密码学消息编码测试向量包含输入明文、密钥、期望密文和签名。把测试向量写成单元测试每次改代码跑一遍import pytest # 示意从 Annex B 提取的测试向量 TEST_VECTORS [ { name: TR34_RSA2048_SHA256_OAEP, krd_public_key: -----BEGIN PUBLIC KEY-----\n..., ephemeral_key: 00112233445566778899aabbccddeeff, expected_encrypted: a1b2c3..., }, ] pytest.mark.parametrize(vector, TEST_VECTORS) def test_ephemeral_key_encryption(vector): # 用向量里的公钥加密临时密钥比对密文 # 注意 OAEP 有随机性密文不会完全一致 # 正确做法是加密后再解密验证解出的是原密钥 passOAEP 填充带随机性同样的明文每次加密结果不同所以不能直接比对密文。正确的验证方式是加密后解密确认解出的是原始临时密钥。签名同理PSS 也带随机盐验证方式是验签通过而非比对签名字节。5.2 密钥轮换时的重绑定流程生产环境密钥需要定期轮换TR-34 用 Rebind 流程处理。Rebind 不改变信任根只更换密钥对KRD 生成新的密钥对用旧私钥对新公钥签名KRD 把新公钥和签名发给 KDHKDH 用旧公钥验签通过后更新绑定的公钥后续密钥传输用新公钥加密这个流程的关键是签名链不断裂。KDH 侧要保留旧公钥直到确认新公钥生效否则轮换期间的消息会验签失败。常见做法是设置一个过渡窗口窗口内新旧公钥都接受。5.3 时间戳与重放防护单向协议没有挑战-应答重放防护靠时间戳。文档 7.7.3 节规定消息里要带时间戳接收方检查时间戳是否在允许窗口内import time def check_timestamp(msg_timestamp: int, window_seconds: int 300) - bool: 检查消息时间戳是否在允许窗口内默认 5 分钟 now int(time.time()) if abs(now - msg_timestamp) window_seconds: raise RuntimeError(f消息时间戳超出窗口: {msg_timestamp} vs {now}) return True窗口设 5 分钟是常见值太短会因时钟偏差误判太长会给重放留空间。部署前确保 KRD 和 KDH 都走 NTP 同步时钟偏差超过窗口会导致所有消息被拒。如果设备时钟不可靠可以退回到随机数方案但需要额外的状态存储来记录已用过的随机数。本文还有配套的精品资源点击获取 金融支付密钥分发：TR34协议原理与Python实现详解
简介ASC X9 TR 34-2019 Preview 是美国国家标准学会认证的 X9 标准委员会于 2019 年 9 月注册发布的技术报告预览版聚焦金融行业对称密钥安全分发场景面向密码学工程师、金融信息安全从业者及标准研究人员。报告核心是阐述如何借助非对称技术基于因子分解的公钥加密实现对称密钥的可互操作分发内容涵盖范围界定、参考文献、术语与定义、符号缩略语以及 TR34 协议概述、证书颁发机构角色、高级协议架构、密钥交换元素、TR34 属性头、临时密钥与重放防护等模块并涉及两遍协议流程可帮助读者理解 CA 信任机制与密钥传输的完整设计思路。资源包为 1 个 PDF 文件大小约 1.07MB属官方预览版本便于快速把握标准框架与目录结构。目前已有 146 人学习下载适合需要对照 ANSI 标准开展密钥管理方案设计与合规评估的技术人员参考。1. 为什么金融支付圈绕不开 TR34 这份密钥分发报告做 POS、ATM、HSM 对接的工程师迟早会在某个接口文档里撞见TR-31、TR-34这两个词。TR-31 管的是密钥块Key Block长什么样TR-34 管的是这些密钥块怎么从一端安全地送到另一端。ASC X9 TR 34-2019 就是这套远程密钥分发Remote Key DistributionRKD方法的现行技术报告全称是《Interoperable Method for Distribution of Symmetric Keys using Asymmetric Techniques: Part 1 – Using Factoring-Based Public Key Cryptography Unilateral Key Transport》。名字很长但拆开看就三件事用非对称技术、单向传输、分发对称密钥。它解决的是一个很具体的痛点两台设备之间要共享一把对称密钥比如 PIN 加密密钥、数据加密密钥但双方没有安全信道也不能人工搬运密钥。TR-34 的做法是让接收方KDHKey Distribution Host生成一对 RSA 密钥把公钥交给发送方KRDKey Receiving Device发送方用这把公钥加密一把临时密钥再用临时密钥加密真正的对称密钥块最后签名打包发过去。整个过程是单向的接收方不需要回传任何密钥材料这也是它被大量用在 ATM 远程换密钥场景的原因。这份 2019 版预览文档覆盖了协议概述、密钥块属性、单向密钥传输、绑定/解绑/重绑定状态机以及 Annex A 的推荐算法和 Annex B 的测试向量。适合谁读做支付终端密钥管理、HSM 指令封装、密钥注入系统的工程师以及需要理解 TR-34 报文结构才能对接第三方密钥中心的开发者。下面按协议原理、报文构造、代码实现、排错验证的顺序拆开讲。2. TR34 单向密钥传输的协议原理与报文结构2.1 两个角色与一次单向传输TR-34 的参与方只有两个KRDKey Receiving Device密钥接收设备和 KDHKey Distribution Host密钥分发主机。注意命名有点反直觉——KRD 是接收密钥的一方KDH 是分发密钥的一方。在 ATM 场景里ATM 是 KRD后台密钥中心是 KDH。协议分两个阶段。第一阶段是绑定Bind双方交换证书和凭证令牌建立信任关系。第二阶段是密钥传输Key TransportKDH 把对称密钥块加密后发给 KRD。整个密钥传输阶段是单向的KDH 发KRD 收KRD 不回传任何密钥材料。这就是 Unilateral Key Transport 的含义。为什么强调单向因为很多终端设备部署在无人值守环境网络可能是单向的或者回传能力受限。单向传输让协议在弱网络下也能工作代价是消息新鲜性要靠时间戳或随机数来保证而不是靠挑战-应答。2.2 TR34 报文的三段式结构一条完整的 TR-34 密钥传输消息由三部分组成文档 5.4.9 节给出了完整定义字段含义关键点TR34 Attribute Header属性头标识协议版本、密钥用法等元信息TR34 Ephemeral Key临时密钥用 KRD 公钥加密的临时对称密钥TR34 Key Block密钥块用临时密钥加密的 TR-31 密钥块Signature签名KDH 对上述内容的数字签名属性头里最关键的是密钥用法和算法标识它决定了接收方怎么解析后面的密钥块。临时密钥是每次传输随机生成的用完即弃这样即使某次传输被破解也只影响那一次。密钥块本身遵循 TR-31 格式包含密钥版本号、算法、密文和完整性校验值。签名覆盖属性头、临时密钥和密钥块用的是 KDH 的私钥。KRD 收到后用 KDH 的公钥验签验签通过才继续解密。这个顺序很重要先验签再解密防止对密文做选择密文攻击。2.3 绑定、解绑、重绑定的状态机文档第 7 章把 KDH 的生命周期拆成几个阶段理解这个状态机是排错的基础Bind绑定KRD 和 KDH 交换证书建立初始信任。KRD 生成密钥对把公钥和证书发给 KDH。Unbind解绑解除绑定关系通常在设备退役或密钥轮换时触发。Rebind重绑定在保持信任链的前提下更换密钥对用于密钥更新。每个阶段都有对应的令牌Token交换。比如 Bind 阶段有 KRD Credential Token 和 KDH Credential TokenUnbind 阶段有 Unbind Token。这些令牌都带随机数和签名防止重放。注意绑定状态是持久化的。如果 KDH 侧记录了绑定关系但 KRD 侧丢失了状态后续密钥传输会直接失败报错通常是签名验证不通过或证书不匹配。生产环境里 KRD 的状态存储要有掉电保护。3. 用 Python 构造一条 TR34 密钥传输消息3.1 环境准备与依赖选择TR-34 本身不规定具体算法Annex A 给了推荐值。常见做法是 RSA-2048 做密钥传输SHA-256 做摘要RSA-PSS 或 RSA-PKCS1v15 做签名。Python 里用cryptography库就能覆盖这些原语不需要自己实现大数运算。pip install cryptography选cryptography而不是pycryptodome是因为它对 OAEP、PSS 这些填充模式的支持更完整而且 API 更贴近标准文档的描述。如果你要对接 HSM最终加密操作会走 PKCS#11但本地开发和测试用cryptography足够。3.2 生成 KRD 密钥对与自签名证书KRD 侧先生成 RSA 密钥对然后签发一张自签名证书生产环境应该由 CA 签发测试环境自签名即可from cryptography.hazmat.primitives.asymmetric import rsa from cryptography.hazmat.primitives import hashes, serialization from cryptography import x509 from cryptography.x509.oid import NameOID import datetime # 生成 KRD 的 RSA 密钥对公钥指数固定 65537 krd_private_key rsa.generate_private_key( public_exponent65537, key_size2048, ) # 构造自签名证书CN 用设备标识 subject issuer x509.Name([ x509.NameAttribute(NameOID.COMMON_NAME, uKRD-TERMINAL-001), ]) cert ( x509.CertificateBuilder() .subject_name(subject) .issuer_name(issuer) .public_key(krd_private_key.public_key()) .serial_number(x509.random_serial_number()) .not_valid_before(datetime.datetime.utcnow()) .not_valid_after(datetime.datetime.utcnow() datetime.timedelta(days365)) .sign(krd_private_key, hashes.SHA256()) ) # 导出私钥和证书私钥用 PKCS#8 格式 with open(krd_private.pem, wb) as f: f.write(krd_private_key.private_bytes( encodingserialization.Encoding.PEM, formatserialization.PrivateFormat.PKCS8, encryption_algorithmserialization.NoEncryption(), )) with open(krd_cert.pem, wb) as f: f.write(cert.public_bytes(serialization.Encoding.PEM))key_size2048是 Annex A 的最低推荐值金融场景里也有用 3072 或 4096 的但 2048 在性能和安全性之间平衡最好。public_exponent65537是标准值不要改成 3虽然理论上可行但很多 HSM 不接受。证书的 CN 用设备唯一标识方便 KDH 侧做白名单校验。3.3 KDH 侧加密临时密钥并封装密钥块KDH 拿到 KRD 的公钥后生成临时密钥用 KRD 公钥加密临时密钥再用临时密钥加密 TR-31 密钥块from cryptography.hazmat.primitives.asymmetric import padding from cryptography.hazmat.primitives.ciphers import Cipher, algorithms, modes import os # 加载 KRD 公钥 with open(krd_cert.pem, rb) as f: krd_cert x509.load_pem_x509_certificate(f.read()) krd_public_key krd_cert.public_key() # 生成 16 字节临时密钥AES-128 ephemeral_key os.urandom(16) # 用 KRD 公钥加密临时密钥OAEP 填充SHA-256 encrypted_ephemeral krd_public_key.encrypt( ephemeral_key, padding.OAEP( mgfpadding.MGF1(algorithmhashes.SHA256()), algorithmhashes.SHA256(), labelNone, ), ) # 构造一个简化的 TR-31 密钥块实际应遵循 TR-31 格式 key_block_plaintext bTR31_KEY_BLOCK_PLACEHOLDER_16B # 用临时密钥做 AES-CBC 加密IV 随机 iv os.urandom(16) cipher Cipher(algorithms.AES(ephemeral_key), modes.CBC(iv)) encryptor cipher.encryptor() # 实际需要 PKCS7 填充这里示意 key_block_ciphertext encryptor.update(key_block_plaintext) encryptor.finalize() # 组装消息属性头 加密临时密钥 IV 密钥块密文 message { header: bTR34\x01, # 版本标识 encrypted_ephemeral: encrypted_ephemeral, iv: iv, key_block: key_block_ciphertext, }padding.OAEP的三个参数必须和 KRD 侧解密时一致mgf和algorithm都选 SHA-256 是 Annex A 的推荐组合。临时密钥长度取决于后面用的对称算法AES-128 就是 16 字节。IV 必须随机且每次不同否则相同明文会产生相同密文泄露模式信息。3.4 对消息签名并序列化最后用 KDH 私钥对消息签名签名覆盖属性头、加密临时密钥和密钥块from cryptography.hazmat.primitives import hashes from cryptography.hazmat.primitives.asymmetric import padding # 加载 KDH 私钥 with open(kdh_private.pem, rb) as f: kdh_private_key serialization.load_pem_private_key(f.read(), passwordNone) # 拼接待签名数据 data_to_sign ( message[header] message[encrypted_ephemeral] message[iv] message[key_block] ) # RSA-PSS 签名盐长度用摘要长度 signature kdh_private_key.sign( data_to_sign, padding.PSS( mgfpadding.MGF1(hashes.SHA256()), salt_lengthpadding.PSS.DIGEST_LENGTH, ), hashes.SHA256(), ) message[signature] signaturepadding.PSS的salt_length用DIGEST_LENGTH是标准做法对应 SHA-256 就是 32 字节盐。有些老系统用 PKCS1v15 签名兼容性更好但安全性略低新系统建议 PSS。签名数据必须按固定顺序拼接任何字段顺序变化都会导致验签失败。4. KRD 侧验签解密与常见失败排查4.1 验签、解密临时密钥、解密密钥块KRD 收到消息后严格按「先验签、再解密」的顺序处理from cryptography.exceptions import InvalidSignature # 加载 KDH 公钥 with open(kdh_cert.pem, rb) as f: kdh_cert x509.load_pem_x509_certificate(f.read()) kdh_public_key kdh_cert.public_key() # 第一步验签 try: kdh_public_key.verify( message[signature], data_to_sign, padding.PSS( mgfpadding.MGF1(hashes.SHA256()), salt_lengthpadding.PSS.DIGEST_LENGTH, ), hashes.SHA256(), ) except InvalidSignature: raise RuntimeError(TR34 签名验证失败消息可能被篡改或 KDH 证书不匹配) # 第二步用 KRD 私钥解密临时密钥 ephemeral_key krd_private_key.decrypt( message[encrypted_ephemeral], padding.OAEP( mgfpadding.MGF1(algorithmhashes.SHA256()), algorithmhashes.SHA256(), labelNone, ), ) # 第三步用临时密钥解密密钥块 cipher Cipher(algorithms.AES(ephemeral_key), modes.CBC(message[iv])) decryptor cipher.decryptor() key_block_plaintext decryptor.update(message[key_block]) decryptor.finalize()验签失败直接终止不要尝试解密。这是防御选择密文攻击的基本要求。解密临时密钥时如果 OAEP 参数不匹配会抛ValueError错误信息通常是 Decryption failed不会告诉你具体哪里错了这是 OAEP 的设计。4.2 典型报错与定位方法实际对接中失败率最高的几个点报错现象可能原因排查方法签名验证失败KDH 证书不匹配、数据拼接顺序错打印双方data_to_sign的 hex 对比OAEP 解密失败填充参数不一致、公钥用错确认双方 mgf 和 hash 都是 SHA-256密钥块解密后乱码IV 不一致、临时密钥长度错检查 IV 是否随消息传输密钥校验值不匹配密钥块格式错、KCV 算法不一致用 Annex B 测试向量验证签名验证失败最常见的原因是数据拼接顺序。TR-34 规定签名覆盖属性头、临时密钥、密钥块但有些实现会把 IV 放在密钥块之后导致双方拼接结果不同。对接时先拿一份已知正确的测试向量跑通再换真实数据。提示Annex B 的测试向量是排错利器。文档里给了完整的输入输出对用这些向量验证你的加解密和签名逻辑能快速定位是算法实现问题还是报文组装问题。4.3 密钥校验值KCV验证密钥块解密后KRD 需要验证密钥是否正确。TR-34 用 KCVKey Check Value做这个校验通常是密钥加密全零块后的前几个字节from cryptography.hazmat.primitives.ciphers import Cipher, algorithms, modes def compute_kcv(key: bytes) - bytes: 计算 AES 密钥的 KCV取加密全零块的前 3 字节 zero_block b\x00 * 16 cipher Cipher(algorithms.AES(key), modes.ECB()) encryptor cipher.encryptor() encrypted encryptor.update(zero_block) encryptor.finalize() return encrypted[:3] # 验证解出的密钥 derived_key key_block_plaintext[:16] # 示意实际按 TR-31 格式解析 kcv compute_kcv(derived_key) print(fKCV: {kcv.hex().upper()})KCV 取 3 字节是行业惯例碰撞概率足够低。如果 KCV 和 KDH 侧声明的不一致说明密钥块解析错了重点检查 TR-31 头部的密钥版本号和算法标识。5. 用测试向量验证实现并处理密钥轮换5.1 拿 Annex B 测试向量做回归Annex B 提供了完整的密码学消息编码测试向量包含输入明文、密钥、期望密文和签名。把测试向量写成单元测试每次改代码跑一遍import pytest # 示意从 Annex B 提取的测试向量 TEST_VECTORS [ { name: TR34_RSA2048_SHA256_OAEP, krd_public_key: -----BEGIN PUBLIC KEY-----\n..., ephemeral_key: 00112233445566778899aabbccddeeff, expected_encrypted: a1b2c3..., }, ] pytest.mark.parametrize(vector, TEST_VECTORS) def test_ephemeral_key_encryption(vector): # 用向量里的公钥加密临时密钥比对密文 # 注意 OAEP 有随机性密文不会完全一致 # 正确做法是加密后再解密验证解出的是原密钥 passOAEP 填充带随机性同样的明文每次加密结果不同所以不能直接比对密文。正确的验证方式是加密后解密确认解出的是原始临时密钥。签名同理PSS 也带随机盐验证方式是验签通过而非比对签名字节。5.2 密钥轮换时的重绑定流程生产环境密钥需要定期轮换TR-34 用 Rebind 流程处理。Rebind 不改变信任根只更换密钥对KRD 生成新的密钥对用旧私钥对新公钥签名KRD 把新公钥和签名发给 KDHKDH 用旧公钥验签通过后更新绑定的公钥后续密钥传输用新公钥加密这个流程的关键是签名链不断裂。KDH 侧要保留旧公钥直到确认新公钥生效否则轮换期间的消息会验签失败。常见做法是设置一个过渡窗口窗口内新旧公钥都接受。5.3 时间戳与重放防护单向协议没有挑战-应答重放防护靠时间戳。文档 7.7.3 节规定消息里要带时间戳接收方检查时间戳是否在允许窗口内import time def check_timestamp(msg_timestamp: int, window_seconds: int 300) - bool: 检查消息时间戳是否在允许窗口内默认 5 分钟 now int(time.time()) if abs(now - msg_timestamp) window_seconds: raise RuntimeError(f消息时间戳超出窗口: {msg_timestamp} vs {now}) return True窗口设 5 分钟是常见值太短会因时钟偏差误判太长会给重放留空间。部署前确保 KRD 和 KDH 都走 NTP 同步时钟偏差超过窗口会导致所有消息被拒。如果设备时钟不可靠可以退回到随机数方案但需要额外的状态存储来记录已用过的随机数。本文还有配套的精品资源点击获取