COMP7906B-安全协议分析案例
案例
protocol1（Session fresh）
分析
- A与B通过KDC(key distribution center)实现共享密钥分发，A向N发送明文A，以及用Key(A)加密过的(B,K)，B为要进行共享密钥的对象K为要共享的密钥。
- 由于key(A)仅有A和KDC知道，所以链路上的密文无法破解
- 但如果密文整体被攻击者截获，在后续的任何时间里，攻击者可以向B发送密文，来使得密钥K再次生效。
思考
- 为什么无法判断是谁的发送的密文来保障安全性？
原因是A和KDC、B和KDC仅仅依靠Key(A)、Key(B)来判断身份，对于发送到B的密文，一旦可以使用Key(B)解密成功，B会认为确实是KDC转发过来的情况。
- 就算密文被劫持后重放，让K再次生效又如何呢，攻击者仍然无法知道K的具体值，不是仍然无法破解密文吗？
首先第一点，无法保障K没有在其他地方泄露；其次第二点，每次新建立连接的会话需要时fresh的，不应该与之前的会话有关联，否则会出现会话泄露的问题；这个地方的关键不在于一定需要解密密文（需要这实际是一个授权行为，可以进行重放授权就可以了，不一定需要把明文解出来），关键还是在会话需要”fresh”和”correct”。
防护
- 在A->B发送的加密内容中加入时间戳，这样在B接受到加密信息后，使用Key(B)解密后，首先判断时效性，如果超时了直接丢弃，就保证了会话的fresh。
protocal2
分析
- A需要向B证明自己的身份，A和B共享密钥K
- A首先向B发送随机字符串，B返回给A一个rB
- A对rB使用K进行加密，然后把加密后的结果返回给B，如果B能解开，则A的身份确认。
思考
- 这里的问题在于单向认证的缺陷，即B只验证A的身份，但A不验证B。
- 第一步B无法确认请求是A发起的，而且第二步的没法确认发送者的身份真的是B，如果我是攻击者，我伪装为A向B发送hello，拿到B返回的rB, 然后伪装为B向A发送rB，然后拿到Ek加密的rb，再发回给B,B就会以为攻击者是A了
双向认证防护
- A向B发请求的时候就使用rA;
- B回发A的时候使用key加密(rA,rB)，保障消息肯定是B针对自己的rA返回的
- 然后A解密得到rB再返回给B证明这肯定是A，这样中间人只能做转发，但没法解密数据，重放攻击靠rA/rB保障，但没法防御反射攻击。
反射攻击（要求AB完全协议对称）
- 【正常流程】A向B发送rA，发起A->B的认证
- 【嵌入攻击】攻击者伪装为B，向A发送rA，发起B->A的认证
- 【嵌入攻击】A返回给攻击者Ek(rA,RA’)
- 【嵌入攻击】攻击者伪装为B，将A返回的Ek(rA,RA’)转发给A
- 【正常流程】A解密Ek(rA,RA’)，并把RA’发送给攻击者
- 【正常流程】攻击者把RA’发送给A，A认为攻击者是B，伪造完成
防护反射攻击（打破AB的完全协议对称）
- 在加密消息体加入sender身份，比如B发送时为Ek(rA,rB，”B”)，A解密后自然能识别发送方身份，C就绝对无法伪造成功了，因为A接受到rA返回的消息为(rA,rA’，”A”)，被攻击者反射回A时，A能发现这个消息是自己发出去的而不是B返回回来的，所以反射攻击失败
protocal3
分析
- A向KDC发送请求，准备和B交接密钥
- KDC使用Key(A)将密钥加密，并返回给A
- A使用Key(A)解密得到共享密钥和使用Key(B)加密的密文，将密文发送给B
- B使用Key(B)解密密文得到共享密钥K，并用K加密挑战Rb发给A
- A使用共享密钥K解密得到Rb,返回给B挑战+1，认证完成
风险
- 重放攻击，在Step3时由攻击者重放请求，则K会再次生效，无法确认当前K是否为fresh。
防护
- 在step2KDC的返回中，将给A的消息和给B的消息都带上timestamp，B解密后先校验timestamp，timestamp有效才继续进行。
练习
protocol1
- 只有AB知道共享密钥，因此只有B能生成这个MAC，条件1满足
- B的回复需要依赖于A刚生成的rA，所以是fresh的，条件2满足
- B的回复是针对于A发动的rA回复的，所以条件3满足
protocol2
- 只有AB知道共享密钥，因此只有B能生成这个MAC，条件1满足
- B的回复需要依赖于A刚生成的timestamp，所以是fresh的，条件2满足
- B的回复需要针对于A刚生成的timestamp的消息回复的，条件3满足
protocol3
存在反射攻击，利用链路如下，主要是B的返回中不存在标识A身份的东西。
- C[B]->A：hello||idB||rA
- A->C[B]：rA||ok||MACk(rA||ok)
- A->B：hello||idA||rA
- C[B]->A：rA||ok||MACk(rA||ok)
protocol4
- 只有AB知道共享密钥，因此只有B能生成这个MAC，条件1满足
- B的回复需要依赖于A刚生成的rA，所以是fresh的，条件2满足
- B的回复是针对于A发动的rA回复的，所以条件3满足
protocol5
- 只有AB知道共享密钥，因此只有B能生成这个MAC，条件1满足
- 没法确认B的请求是针对于A的哪次special特殊回应的，缺陷依赖
- 没有fresh控制的随机数或者时间戳，无法保证fresh
protocol6
- B的私钥只有B知道，所以B的身份无可伪造，没啥问题
- B的回复需要依赖于A刚生成的rA，所以是fresh的，条件2满足
- B的回复是针对于A发动的rA回复的，所以条件3满足
本文作者：
yd0ng
本文链接： https://blog.yd0ng.top/2025/12/06/%E5%AE%89%E5%85%A8%E5%8D%8F%E8%AE%AE%E5%88%86%E6%9E%90/
版权声明： 本作品采用 知识共享署名-非商业性使用-相同方式共享 4.0 国际许可协议 进行许可。转载请注明出处！
本文链接： https://blog.yd0ng.top/2025/12/06/%E5%AE%89%E5%85%A8%E5%8D%8F%E8%AE%AE%E5%88%86%E6%9E%90/
版权声明： 本作品采用 知识共享署名-非商业性使用-相同方式共享 4.0 国际许可协议 进行许可。转载请注明出处！
