防重放
使用场景 :
当系统需要与云平台进行对接时,常常会使用api鉴权对权限进行鉴定,我们使用的api鉴权方式即为aksk鉴权,简单而言就是通过签名验证是否具有权限。
假设 :
AKSK鉴权并非该帖子的主题,先略过,假设目前组件与云平台都存在一个对称加密的密匙,且组件内提供了一些API给云平台进行调用。
为什么需要防重放 :
当云平台需要调用组件的api时,需要API鉴权。鉴权方案大概为 :
云平台 :
1) 云平台生成一个随机数,将随机数与api参数一起进行哈希然后利用秘钥进行加密(类似于签名)生成一个code,然后将随机数,api参数和code发送给客户端。
2) 经过SSL加密到达服务端
组件 :
1) 从SSL取得解密的数据
2) 将随机数与api参数一起进行哈希然后利用秘钥进行加密(类似于签名)生成另一个code与收到的code进行比对。
问题 : 虽然上述方案看起来很严谨,又是哈希又是加密还有SSL保护,但仍然存在漏洞。
例如 : 攻击方不一定需要知道你的秘钥是什么,他只需要将你的包再次发送给客户端,他就可以获取到api的返回结果。
如若是获取root用户当前密码或者重置root用户当前密码的api。那么可能直接对方就获取到了root权限。
防重放方案v1 :
方案 :
其实很简单,在服务器端存储一个随机数集,每个随机数只能使用一次,组件在1,2步骤中加一个步骤 : 查询随机数是否处于随机数集中,如若存在,返回重复随机数错误,如若不存在将其则加入随机数集。
为什么方案有效 :
由于会进行签名检验,故而如若你抓到包,然后更改为一个未曾使用过的随机数 + api参数 + code,即使api参数不变,code也不可能与随机数 + api参数的签名结果相同。
新的问题 :
由于有些api可能是间隔时间访问,例如 : 获取组件的运行状态。
如若不清除随机数集 那么势必会导致 随机数 不够用,由于查询 随机数 时间过长导致api访问失败。甚至 磁盘被写满(假设随机数足够长)。
防重放方案v2 :
方案 :
随机数集中的随机数具有有效期,且定期清除。
避免的问题 :
定期清除避免v1的几乎所有问题,如若设置一个月甚至半年的有效期,也不存在太大的安全隐患(一般没人留着包等半年后去攻击你,但不排除这种可能性)。
问题 :
查询时间长,占用磁盘的旧问题并未完全解决,如若遇到高频率访问的api完全有可能重现这些问题。
新问题 : 有效期后的重放攻击无法避免。
防重放方案v3 ：
云平台 :
1) 云平台生成一个随机数 rand,记录当前时间time ,将rand + time + api参数一起进行哈希然后利用秘钥进行加密(类似于签名)生成一个code,然后rand + time + api参数 + code发送给客户端。
2) 经过SSL加密到达服务端
组件 :
1) 从SSL取得解密的数据
2) 检测 time 与服务端当前时间是否超过 2 * TTL。
3) 将rand + time + api参数一起进行哈希然后利用秘钥进行加密(类似于签名)生成另一个code与收到的code进行比对。
4) 遍历检测当前随机数集是否存在超出有效期(2*TTL)的随机数,如若有则删除。
3) 遍历检测当前随机数集是否存在rand。
4) 将rand和time写入随机数集。
5) 提供服务并返回结果。
原理 :
1) 利用签名保证了 time 和 rand 的可靠性。
2) 利用 time 排除了time < server_time 和 time > server_time + 2*TTL 的包。
3) 利用 具有有效期的随机数集 保证了 在 server_time <= time <= server_time + 2*TTL 内的包 rand 不重复。
优势 :
维护的 具有有效期的随机数集 小,所以不会因为鉴权导致更高的时间与空间上的过度浪费,安全。