“路径验证通过后,还要按应用协议进行服务身份匹配:例如连接目标是 ,客户端应比较自己事先期望的reference identifier与叶证书适当的subjectAltName条目。不能把对方…”
形式陈述
握手不是一个单独的群运算,而是两个局部会话在不可信网络上的交互。每个会话保存本地角色、期望对端、协商参数、收发记录、临时秘密和接受状态。攻击者可以截获、修改、重放、穿插多个会话;诚实方只有通过规定的全部验证才产生 accept(peer, context, key)。
认证目标至少要说明:一个未受损会话接受为与某对端交互时,是否存在该对端的匹配会话,双方在身份、角色、协议参数及相关transcript上是否一致。若要求唯一匹配,则还需会话新鲜性与重放控制。密钥不可区分是另一项游戏:对允许被测试的会话,攻击者区分真实会话密钥与同长随机串的优势应很小。必须明确哪些长期密钥、临时秘密或会话密钥泄漏会取消测试资格。
本单元固定一项教学构造。双方的签名验证公钥预先与 client.test、server.test 可信绑定;不从对方自报的名字推出信任。双方生成临时DH公钥
E(protocol,version,client-auth,H(T0)) 与 E(protocol,version,server-auth,H(T0)),先核对期望身份、公钥、参数及签名。再构造
直觉
原始DH证明双方算到同一个群元素,却没有证明网络另一端是谁。攻击者可以把自己的临时公钥分别发给两端,建立两把自己都知道的密钥。签名若只覆盖一个长期名字,仍没有把这次临时交换绑定到那个身份。
transcript可以理解为“双方同意正在进行哪一次、用什么参数、与谁进行”的字节账本。签完整账本把临时值与身份联系起来,方向标签则防止同一份签名被当作另一个角色的声明。账本哈希还依赖抗碰撞假设,不能无限压缩而不记安全条件。
例子与边界
假设服务端只签
本教学实验使用固定公开测试种子创建真实X25519和Ed25519对象。正确的T0摘要为
9be9b549ddd5ffe8632cccd4df8deabdce0ac2fb9b0bab2bee11dd35e52421fe。
检查器保留同一服务端签名,把签名域的 server-auth 改成 client-auth,或把版本1改成2,均会验证失败。这里失败事件对应签名消息改变;攻击者若能在原公钥下为未签过的改动上下文制造有效签名,才进入相应不可伪造游戏。
自签证书、攻击者自己生成的一对签名密钥、以及“对方能正确签名”都不保证期望服务身份。验证前必须知道应该信任哪个公钥或哪条信任路径。公开随机数也不能替代临时秘密的不可预测性。
推论与应用
TLS1.3的CertificateVerify、Finished和HKDF调度展示了这几层绑定,但本教学构造没有完整TLS消息语法、版本协商、重传、错误处理、扩展及证明,不能部署为安全协议。X25519与Ed25519都是真实算法,也不会自动使新组合获得成熟AKE定理。
阅读协议时应分别列出匹配关系、接受门、签名覆盖串、KDF上下文与泄漏资格,再检查每个反例破坏哪一项。固定向量可以验证两端是否计算同一transcript;网络攻击下的会话认证和密钥保密还需要覆盖所有交互的证明。