对称加密与攻击案例分析
输出:
在密钥未知的情况下,依然成功还原了1.txt的明文内容。防御这种攻击的方法就是尽可能不要重用流加密的密钥,常见的实现是在加密前将密钥与随机数nonce进行运算。 2. ECB块重排攻击 前文说过,在块加密中ECB模式中每个块都是独立加密的。因此攻击者可以在未知密钥的情况下,对密文中的块进行重新排列,组合成合法的可解密的新密文。 考虑这么一种场景,某CMS的cookie格式为DES-ECB加密后的数据,而明文格式如下:
由于DES使用的块大小是8字节,因此上述明文可以切分成三个块,其中@为填充符号:
假设我们可以控制自己的用户名(在注册时),那么有什么办法可以在不知道密钥的情况下将自己提取为管理员呢(即admin=1)?首先将用户名设置为pan@@@@admin=1;,此时明文块的内容如下:
我们所需要做的,就是在加密完成后,将服务器返回的cookie使用最后一个块替换第一个块,这样一来就获得了一个具有管理员权限的合法cookie了。 完整例子就不整了,这里只证明一下这种方式的可行性,首先使用DES-ECB加密明文:
然后修改密文,将前两个块(8字节)替换,然后使用相同的密钥进行解密:
可以看到,该攻击方法确实是对ECB块加密算法有效的。 类似的利用方式还有在能够解密的情况下,将其他密文的对应块替换到自己的密文块中,从而获取其他密文块的明文数据。比如上述例子如果可以通过cookie获取用户名,那么可以将其他密文块放到用户名部分从而获取其他加密的信息。 该攻击和其他类似的攻击其实有一个共同点,我们无法获取和猜解原始数据,但可以通过修改密文数据并让服务器去成功解密。因此应对此攻击的方法就很明显了,即在加密后再添加MAC校验。 注意这里说的是先加密后MAC,如果顺序反了,那在处理数据时就要先解密再校验MAC,这有可能会导致一系列安全问题,比如下面将提到的密文填塞(Padding Oracle)攻击。 3. Padding Oracle Attack 在介绍该攻击之前,可以先回顾一下关于填充的知识。在PKCS#7系统中,我们可以通过最后一个块的最后一个字节得知填充的大小以及校验填充是否合法。 (编辑:云计算网_泰州站长网) 【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容! |