AKA协议
AKA协议，即认证的密钥协商协议（Authenticated key Agreement,AKA）,使用一个协议完成身份认证与密钥分发
身份认证
通俗地说就是，A要求B证明自己的身份，B提供证明信息给A，A再去核验这个证明信息与B的真实身份是否相符
正式地说：一方实体向另一方实体提供证据证明自己的身份，另一方通过相应的机制来验证证据，以确定该实体是否与证据所宣称的身份一致
密钥分发
即如何安全地把密钥分发到目标手中
- 对称密钥分发：机密性和真实性；这个很好理解，如果对称密钥泄露了，那么通信内容将被解密，机密性被破坏；同时，如果密钥被攻击者篡改，通信内容看似是被加密的，实则攻击者可以直接进行解密，机密性和安全性都被破坏
- 公钥分发：真实性；公钥可以被所有人看到，需要防止公钥被伪造；如果攻击者的公钥被当做真实的公钥，那么用公钥加密的通信内容就可以被攻击者使用其私钥解密
挑战与应答
应用场景：好比你正在线上交易，对方声称自己是官方工作人员，让你告诉他你自己的密码，你会直接相信他的身份并告诉他吗？
面对这种不能直接传输密码口令等敏感信息的情况下，证明自己拥有相应的身份标识，这就是挑战与应答要做的事情
前提：双方共有一些知识
流程可分为3步：挑战、响应、验证
- 挑战：即要求对方证明自己拥有相应的身份标识；验证方B向待认证方A发送一个挑战（可以是随机的一次性字符串/随机数等）
- 响应：对方提供证明材料给自己；即待认证方A回送一个对挑战的响应
- 验证：去验证对方提供的证明材料的真伪；即验证方B检查此响应，验证待认证方A的身份
如何区分待认证方和验证方？
- 谁应答谁就是待认证方
根据加密算法类型，可分为基于对称加密和和基于非对称加密的认证，根据认证的模式，又可分为单向认证和双向认证
单向认证
我们前面提到的场景其实都是单向认证，比如客户验证工作人员的身份，而工作人员则不关系客户是否是真的客户
双向认证
顾名思义，就是通信双方互相验证对方的身份，并交换对话密钥
这里有两个要点：机密性和及时性
如何去理解呢？
机密性：交换会话密钥和身份敏感信息时，肯定要是以密文的的形式进行传输的（不然费老大劲生成的密钥用明文传输就白瞎了）
及时性：这个主要是为了抵抗重放攻击
上面提到的密文形式传输身份敏感信息与会话密钥，那么这个密文是用什么加密？
所以双向认证的前提是双方预先存有对称密钥或者拥有对方的公钥
基于非对称加密的AKA协议
基于非对称加密的单向认证
前提：验证方已安全获取待认证方的公钥
认证可以分为两种：基于公钥和私钥
- 基于公钥：挑战是用待认证方的公钥加密的
验证方B事先已经获得了待认证方A的公钥PU_A
- 待认证方A首先向B表明自己的身份
- 验证方B向待认证方A发起挑战，使用A的公钥PU_A加密挑战R，并发送给A
- 待认证方A接收到
E(PU_A,R)后，使用自己的私钥PR_A解密后，将得到的原文R'发给验证者B - 验证者B去验证R'==R是否成立，若成立，则可以证明A的身份
- 基于私钥：应答用待认证方的私钥加密
- 待认证方A首先向B表明自己的身份
- 验证方B向待认证方A发送挑战R
- A收到挑战R后，使用自己的私钥PR_A加密挑战R并发送给B
- B收到
E(PR_A,R)后，使用A的公钥PU_A进行解密，得到R',随后验证R'==R，若相等，则完成B对A的身份验证
这样做很简单，并且可以防监听（挑战R是用公钥PU_A加密的），但是不能抵抗中间人攻击
为什么？
假设信道中存在攻击者E
在待认证者A向验证者B表明身份ID_A时,攻击者E拦截ID_A,转而将自己的ID_E发送给B
对于第一种方案，那么B就会发送E(PU_E,R)给攻击者E，这样一来E就可以拿到挑战R，使用A的公钥加密后再发给A
对于第二种方案，更简单，E只负责在第三条消息时，用A的公钥解密消息，随即验证A的身份，并用自己的私钥加密挑战再发回给B
基于非对称加密的双向认证
双方使用握手协议交换密钥，N1、N2是双方产生的随机数
前提：进行认证前，双方都已安全地获取到了对方的公钥
步骤1-2为A验证B的身份，而步骤3-4为B验证A的身份，A分发密钥
- A向B发送 使用B的公钥加密的、带有挑战N1以及自己身份信息的密文
E(PU_b,[N1||ID_A]) - B收到密文后，使用自己的私钥
PR_b进行解密,拿到挑战N1，并在本地生成新的挑战N2，将N1||N2使用A的公钥加密发送给A - A收到
E(PU_a,N1||N2)后，使用自己的私钥PR_a进行解密,首先去验证B解密的挑战N1是否正确，若正确，则A验证了B的身份；同时A也拿到了B生成的挑战N2，使用B的公钥PU_b加密N2，并发送给B；B收到E(PU_b,N2)后，解密验证N2是否正确，完成对A的身份验证 - 随后，A向B发送使用B的公钥
PU_b加密的密文，密文为用A的私钥PR_a加密的会话密钥K_s,此时AB双方都已完成身份验证，B可以解密获取会话密钥K_s
验证方 B (Bob) 待认证方 A (Alice) 验证方 B (Bob) 待认证方 A (Alice) 前提：双方已安全获取对方公钥 PU_a, PU_b 第一阶段：双向身份认证 (挑战-应答) 1. 使用 PR_b 解密 2. 提取 N1 和 ID_A 1. 使用 PR_a 解密 2. 验证 N1 是否匹配 3. 若匹配，则 A 信任 B 的身份 1. 使用 PR_b 解密 2. 验证 N2 是否匹配 3. 若匹配，则 B 信任 A 的身份 第二阶段：会话密钥分发 1. 使用 PR_b 解密外层 2. 使用 PU_a 解开内层(验证签名) 3. 获取会话密钥 K_s 认证完成：后续通信使用 K_s 进行对称加密 E(PU_b, [N1 || ID_A]) 1 E(PU_a, [N1 || N2]) 2 E(PU_b, N2) 3 E(PU_b, E(PR_a, K_s)) 4
重放攻击
可分为:
-
简单重放攻击：攻击者只是复制消息，然后重放给消息接收者
- 协议场景：无状态的UDP服务支付请求
- 漏洞出处：验证者的验证逻辑是无状态的，所以它区分不了哪个数据包是已经被处理过的，导致同一个数据包可以无限的重放
-
记录重放攻击：攻击者在有效的时间窗口内重放一个时间戳给接收者
- 协议场景：带时间戳的无状态UDP服务支付请求
- 攻击案例：此攻击针对使用时间戳作为防重放机制的协议；因为要考虑到网络时延等因素，消息的时间戳合法性是用一个时间窗口来衡量的；合法消息的时间戳需要在一个可接受的时间窗口
Δt内 - 漏洞所在：当攻击者截获了时间戳为T的消息M(T),若
当前时间T_current-T <= Δt，那么重放该消息到目标服务器时，目标服务器会认为这条重放消息合法；时间戳只能保证新鲜度，但是不能保证唯一性 - 攻击结果：服务器会认为用户发起了一次新的认证请求
-
截获重放攻击：截获原始消息使之不能到达，只有重放消息可以到达接收者
- 协议场景：一个设计拙劣的基于TCP的挑战-应答协议
- 攻击案例：服务器Bob假定：任何能正确完成TCP三次握手并且发来正确认证包的人，就是TCP会话的合法所有者
- 正常流程：
- Alice向Bob发送TCP SYN请求连接
- Bob回复SYN-ACK
- Alice回复ACK，TCP Established
- Alice发送认证包
M=E(K,"LOGIN_NAME") - Bob验证M并且授权此TCP会话
- 攻击流程：攻击者Eve监视者Alice
- 一旦Alice发送认证包，Eve就拦截这个认证包，同时向Alice发送伪造的RST包中断Alice与Bob之间的TCP连接
- Eve与Bob完成三次握手，建立新的TCP连接
- Eve将截获的Alice的认证包重放，则Bob验证Eve通过
- 脆弱点：TCP的三次握手与应用层认证像是硬凑在一起的，没有进行密码学绑定
-
无更改的重放攻击（反射攻击）：针对对称的协议，发送不同的报文可以使A/B即是验证者也是待认证者，会被充当加密机或者解密机
-
漏洞成因：由自己和别人发送的挑战无法被区分
-
攻击案例：一个基于共享密钥的拙劣相互认证协议
-
攻击流程
- Alice发起挑战，发送
N_A=114514给Bob,但是被攻击者Eve截获 - Eve并不会把这个消息转发给Bob，而是直接反射回Alice
- 因为挑战中不附带身份信息，Alice收到
N_A=114514后会以为这是Bob向他发起了新的挑战，于是返回E(K,N_A+1) E(K,N_A+1)被Eve截获，Eve再将E(K,N_A+1)发送给Alice，于是Alice认证Eve通过
- Alice发起挑战，发送
-
防御手段：
- 应答的时候要带上身份信息
攻击者 Eve (冒充 Bob) 受害者 Alice 攻击者 Eve (冒充 Bob) 受害者 Alice 共享密钥 K 【会话 1】Alice 发起认证请求 Eve 无法计算 E(K, N_A+1) 于是启动反射 【会话 2】Eve 开启新连接 (或反射) Alice 以为这是 "Bob" 发来的新挑战 【回到会话 1】 Alice 收到会话 1 的应答 验证正确！ N_A (挑战) 1 N_A (将挑战反射给 Alice) 2 E(K, N_A + 1) (Alice 帮忙算出了答案) 3 E(K, N_A + 1) 4 认证通过：Eve 就是 Bob 5
-