12 | 怎么利用加密端攻击？

最新推荐文章于 2024-04-08 07:00:00 发布

_Rye_

最新推荐文章于 2024-04-08 07:00:00 发布

阅读量156

点赞数

分类专栏：密码学文章标签：安全网络

本文链接：https://blog.csdn.net/qq_37756660/article/details/133854516

版权

密码学专栏收录该内容

20 篇文章 8 订阅

订阅专栏

上一讲，我们讨论了怎么利用解密端攻击 CBC 模式的对称密钥分组算法。那么，加密端的攻击方案是怎么进行的？有什么办法可以规避加密端的攻击？这是我们这一次要解决的问题。

虽然我们之前说，CBC 模式应该退休了，但是现实中，它还有广泛的应用。我们花了很多篇幅来讨论 CBC 模式，除了提醒你 CBC 模式的缺陷外，还希望你了解缺陷修补的办法，这样你就可以修复现有的应用了。

这一次的讨论，比起上一次，稍显烧脑。因为，这是一个相对较新的攻击技术。不过，我可以保证，如果你了解了这种攻击技术，将会有一个巨大的收获。

怎么利用加密端攻击？

我们先来看看是怎么利用加密端攻击的？其实，CBC 模式针对加密端的攻击，和针对解密端的攻击方案一样，最常见的攻击方式也是通过异或运算展开的。

攻击面应该怎么选？

要想了解针对加密端的攻击方案，我们先来回顾一下 CBC 模式的加密过程。在这个过程中，一个明文分组的加密，需要如下的输入数据：

上一次的密文分组 Ci-1；

这一次的明文分组 Pi；

加密和解密共享的密钥 K。

这一次的明文分组 Pi 和上一次的密文分组 Ci-1 进行异或运算，获得中间结果 Ti。

异或运算获得的中间结果 Ti，Ti = Ci-1 ^ Pi

然后，异或运算获得的中间结果 Ti 和密钥 K，通过加密函数的运算，产生密文分组：

密文分组 Ci

而加密端的异或运算，发生在明文分组和上一次的密文分组（对于第一次运算，上一次的密文分组就是初始化向量）之间。针对加密端的攻击，同样，我们也是在明文分组和上一次的密文分组或者初始化向量上想办法。

攻击理论上可行吗？

假设目标明文分组是 Pi，但是攻击者并不知道 Pi 的明文内容，而他攻击的目的就是解密出 Pi 的明文数据。由于密文数据不是保密的，所以攻击者可以知道所有的密文分组，包括参与 Pi 加密运算的上一次密文分组 Ci-1 和这一次的密文分组 Ci。

如果攻击者可以使用加密接口，攻击者就可以构造明文分组，然后调用加密运算，观测加密运算后的密文分组。如果攻击者观测到密文分组和目标明文分组对应的密文分组相同，那么他就可以确定目标明文分组的具体数据了。

那明文分组该怎么构造呢？像解密端的攻击方案一样，我们还是要利用异或运算的归零律和恒等律。假设已经知道了 Pi，当前的加密运算需要使用上一次的密文分组 Cj-1，如果攻击使用的明文可以构造成下面的形式，那么攻击就能够成功：

Pj = Pi ^ Ci-1 ^ Cj-1

加密运算后的结果，就是目标明文分组对应的密文分组。

Tj = Pj ^ Cj-1

= Pi ^ Ci-1 ^ Cj-1 ^ Cj-1

=Pi ^ Ci-1

= Ti

=>

Ek（Tj）= Ek（Ti）

=>

Cj = Ci

Tj ^ Ci-1 = Ti ^ Ci-1 = Pi ^ Ci-1 ^ Ci-1 = Pi

Pi = Tj ^ Ci-1 = Pj ^ Cj-1 ^ Ci-1

假设终归是假设，攻击者要是知道明文分组，也就不需要实施攻击了。似乎，这个美好的运算并不能够执行。对于 AES 算法来说，一个明文分组有 16 个字节，也就是 128 位。如果一位一位地尝试，需要 2^128 次运算。这种数量级的运算，现在的计算能力还是无能为力的。

攻击实践上可行吗？

那么，既然完整破解有 16 个字节的明文分组不可行，能不能只破解一个字节？

怎么破解一个字节呢？我们还要继续从假设开始。假设攻击者已经知道了明文分组里的 15 个字节，只剩下最后一个字节未知。攻击者能不能破解出这个字节？这样的破解太简单了。

攻击者只需要改动最后一个字节，按照上述的构造明文分组的方式，他最多尝试 255 次，最后一个字节就可以破解了。原则上，只要有一个字节能够被破解，这个算法就算是被破解了。

不过，我们还需要验证这个假设有没有实际的可能性，也就是说，一个明文分组里，攻击者有没有可能会知道 15 个字节，只有 1 个字节是未知的？

遗憾的是，网络里的数据，大部分都是格式化的，比如 HTTP 的数据。下面的数据是我在写这些文字的时候，从 geekbang.org 登录页面记录下来的 HTTP 请求的头部数据。

这里面的数据，除了 Cookie 之外，大部分都是重复的数据。

POST /account/sms/login HTTP/1.1
Host: account.xxx.org
Connection: keep-alive
Content-Length: 371
sec-ch-ua: "\\Not;A\"Brand";v="99", "Google Chrome";v="85", "Chromium";v="85"
Accept: application/json, text/plain, */*
sec-ch-ua-mobile: ?0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/85.0.4183.102 Safari/537.36
Content-Type: application/json
Origin: https://account.xxx.org
Sec-Fetch-Site: same-origin
Sec-Fetch-Mode: cors
Sec-Fetch-Dest: empty
Referer: https://account.xxx.org/signin
Accept-Encoding: gzip, deflate, br
Accept-Language: en-US,en;q=0.9
Cookie: <deleted>

以及 HTTP 的请求内容。请求的内容，除了电话号码（cellphone）和手机验证码之外（code），其他的数据也都是重复的。

{"country":86,"cellphone":"12345678901","code":"123456","ucode":"","platform":3,"appid":1,"remember":1,"source":"","sc":{"uid":"","report_source":"Web","utm_identify":"","utm_source":"","utm_medium":"","utm_campaign":"","utm_content":"","utm_term":"","share_code":false,"original_id":"1746eb1327656f-05d10c17083f0f-f7b1332-2073600-1746eb132773ba","refer":"xxx"}}

所以，攻击者知道 15 个字节，甚至整个明文分组，这种情况在实际中，是经常出现的。

我们真正关心的是敏感数据，比如手机验证码，是不是能够被破解。那么，首先，我们要了解的是，攻击者能不能破解手机验证码的第一个字节呢？

如果手机验证码的第一个字节刚好是一个明文数据分组的最后一个字节，前面我们已经讨论过了，这个字节就是可以破解的。由于手机验证码只能是数字，破解这个字节最多需要 9 次计算。比起 255 次，9 次计算就更简单了。