AES加密的安全问题

aes加密简介

AES算法全称Advanced Encryption Standard,是DES算法的替代者，旨在取代DES成为广泛使用的标准，于2001年11月26日发布于FIPS PUB 197，并在2002年5月26日成为有效的标准。2006年，高级加密标准已然成为对称密钥加密中最流行的算法之一。

AES是典型的对称加密算法，对称加密不同于md5 sha的哈希摘要算法，对称加密是可逆的，通常是明文+密钥，再利用算法来加密成密文，如果要还原也很简单，只要根据密钥+密文+生成算法的逆运算，即可解出，对称加密特点为可逆，并且加密解密都是使用同一个密钥，而非对称加密则是公钥私钥加解密模式这里不做讨论。

aes加密五种模式

aes加密的方式有五种工作体制。

1.电码本模式（Electronic Codebook Book (ECB)）

这种模式主要是将明文划分为几个明文段，分块加密，但是加密密钥是相同的。

2.密码分组链接模式（Cipher Block Chaining (CBC)）

这种模式是先将明文切分成若干小段，然后每一小段与初始块或者上一段的密文段进行异或运算后，再与密钥进行加密。

3.计算器模式（Counter (CTR)）

4.密码反馈模式（Cipher FeedBack (CFB)）

5.输出反馈模式（Output FeedBack (OFB)）

其中分组如，aes-128-ecb即为16字节为一组，16字节即为128位。

其他三种模式较为复杂，本文仅讨论前两种加密的安全性。

aes-ecb加密

aes-ecb加密是将一段明文，按照固定长度分组，然后对每一个分组，按照算法使用固定的密钥进行加密。假设123456加密。那么123为一组加密，456为一组加密，然后两段明文加密后的密文拼在一起，就算完整的密文。

注意：这里每一组的加密都是使用相同的密钥，相同的算法，所以在这种机制下，很可能出现安全问题。

比如：在身份认证中，查询用户是否是管理员还是普通用户，如果is_root=1则为管理员，如果不为1则为普通用户，如果采用aes-ecb加密，对原文进行分组加密。

明文：user_id:1.000000 is_root:0（其中is_root来判断是否为管理员。） 然后用一段密钥加算法进行加密。

这种提交的加密数据是在cookie中提交，明文不可控，但是密文是可控的，但由于是进行分组进行，所以我们可以推算出每一分组明文对应的密文，假设明文八个一组来进行加密，分组后变为（提示：仅仅是假设理想情况八位，实际并不是）

第一组：is_user 第二组：1.000000 第三组: is_root: 第四组： 0（不够的八位自动填充）其中user_id 通常情况下我们前端可以修改，进行修改为1.000000，此时原文被加密之后为四组 每组为八个数字的密文假设加密后密文为 c4ca4238a0b923820dcc509a6f75849b 在cookie中被提交，将密文分为四组c4ca4238a0b923820dcc509a6f75849b

此时密文我们是可控的，如果正常提交，服务器解密之后为user_id:1.000000 is_root:0，很显然我们不是管理员，但是如果将第二组密文和第四组密文替换呢，那么user_id就是0，is_root就是1.000000。服务器就解析为user_id:0xxxxxxx(xx为填充字符) is_root:1.000000，显然我们不需要知道密钥，同样可以进行绕过。

还有一则在转账中，如果采用aes-128-ecb加密，在cookie中使用ecb分组加密，比如

付款人账户：

XXX //假设密文abc

收款人账户：

XXX //假设密文efg

试想一下，一旦这个分组是刚好分为四组，我们仅仅将abc与efg交换，那不就造成了支付收款反转，几乎不需要什么技术就可以造成严重的攻击。

ctf-案例

接下来以真实题目来进行详解。

ctf address：https://mixer-f3834380.challenges.bsidessf.net/（国外的一道ctf）