安全 计时攻击原理以及 Rails 对应的防范

zgm · 2014年09月04日 · 最后由 zgm 回复于 2014年10月27日 · 10267 次阅读
本帖已被设为精华帖!

计时攻击 属于旁路攻击的一种, 所谓旁路攻击就是通过对系统的物理学分析和实现方式分析, 而不是密码学分析或暴力破解, 来尝试破解密码学系统的行为. 密码学系统的电力消耗, 电磁波泄露, 时间差等信息都有可能提供对破解系统有帮助的信息.

而计时攻击就是利用时间差来对计算机进行攻击, 那么它的原理是什么? 我们拿 Rails 中的一段代码进行分析:

# constant-time comparison algorithm to prevent timing attacks
def secure_compare(a, b)
  return false unless a.bytesize == b.bytesize

  l = a.unpack "C#{a.bytesize}"

  res = 0
  b.each_byte { |byte| res |= byte ^ l.shift }
  res == 0
end

这段代码的一个重要使用场景是验证签名 cookie 的有效性, 即外部传入的摘要与内部计算的摘要是否相等, 但是为什么不直接使用 a == b, 而是一个字符一个字符的比较, 并且看上去以一种十分低效的方式进行的?

原因正是为了预防计时攻击.

a == bRuby 内部使用 memcmp 函数进行比较, 当首次发现有两个字符不一致时, 便直接返回两个字符在 ASCII 码表中的差值. 在这样的机制下, CPU 运行的时间与字符串匹配度是有正关系的, 字符串匹配度越高, CPU 运行时间越长, 因此便可以通过对比时间差的方式逐一猜测破解.

预防计时攻击的方法通常也很简单, 使用 constant-time 的方式. 如上述比较摘要是否相等的示例代码, 当发现两个字符不一致时, 并没有立即返回, 而是继续比较下去, 因此使得计算时间不会变化.

虽然这样的处理, 时间复杂度提高了, 在语言级别的效率也降低了, 但在系统安全的关键部分, 付出了一点点性能的代价还是值得的.

也许你会觉得不解 (我也是), 每个请求在不同的情况下包括网络延迟, 计算机运行状态都是不可能完全一致的, 况且这么一点点的时间差在 Rails 处理整个复杂的请求过程中 (你应该知道, 在 Rails 中一个请求可能生成数以万计的 Ruby 对象) 也显得非常的微不足道, 应该是非常难以利用的, 计时攻击难道仅仅存活在理论当中吗? 这篇论文也许可以给我们带来一些参考.

原文链接

不明觉厉 :plus1:

原来是这样 当初看这段代码的时候也没完全理解呢

#2 楼 @iBachue 我也是特地查了一下, 也翻了一下 rails 的提交历史, 后面才加进来的.

Devise 里面对密码也是这样比较的,还特地加了注释说是预防 Timing attack,不过到现在都不明白 Timing attack 的攻击原理。

#4 楼 @darkbaby123 你看一下原文, 应该比较容易理解吧.

以前不仅不明而且没注意现在明觉厉 :plus1:

去年同事提到过这个有意思的事情,确实有黑客利用这个破解了,虽然需要的时间比较长。👍

在 devise 中,运用得很广。 👍

涨见识:thumbsup:

:plus1: 高大上

涨姿势了! :plus1:

涨姿势 :plus1:

开眼界 👏

这篇把攻击过程写的很详细:http://drops.wooyun.org/papers/1404

👍 涨姿势

#15 楼 @hooopo 互联网环境下 并且用 rails 这种框架 破解概率微乎其微

要整一个好的库,多么的不容易啊。

涨姿势啊!!!

涨姿势

涨姿势 :plus1:

好文啊 居然没在公司教教我

最近再看安全方面得东西,看到过几次 “计时攻击”,不过没去搞懂。。。 楼主简单描述就清楚了。。。

:plus1:

刚看到这个帖子 :plus1:

刚看到这段代码,正好解了心中的疑惑

@zgm 在看 devise 源码的过程中, 看到 secure_compare, 然后回想起来 你分享过 这个内容。

所以 这个 有个问题 想请教一下:

a == b 这么获取到 在 ASCII 码表中的差值?

#30 楼 @meeasyhappy 不是说 a == b 获取到 差值, 而是说 Ruby 在内部使用 C 函数 memcmp 来实现 == 方法, 你可以看一下这个 C 函数

victor Ruby 位运算符详解 中提及了此贴 03月16日 00:54
需要 登录 后方可回复, 如果你还没有账号请点击这里 注册