陶慎亮 朱 涛
（江苏警官学院计算机信息与网络安全系 南京 210031）
在密码学中，通常都会提出一个前提：即该密码算法的执行环境（终端）是可信任的，因此密钥的安全性就成为最先关注的问题。然而在现实生活中，这个前提往往得不到满足，这就使得密钥的安全性受到了极大的威胁。例如，当用户打开一个视频播放器，该视频播放器可以自行对加密的视频信号进行解密，此时该视频播放器的运行环境可以看作是不安全的，那么该软件的整个解密过程对于此用户（或攻击者）而言是可见的，这样可以轻而易举得到密钥信息。
针对以上所描述的问题，Chow 等在2002 年提出了一个概念：白盒攻击环境［1］。所谓的白盒攻击环境就是指攻击者对软件执行过程完全可见的环境。依照上文所述，用户（或攻击者）通过运行密码软件或者直接观察便能轻而易举地获取到密钥信息。在这种状况下，如果依旧对密钥进行保护无异于“亡羊补牢，为时晚矣”，此时就迫切地需要对于密钥的特殊保护，需要用密码算法的实现来对密钥信息进行隐藏，由此，白盒密码应运而生。它的目的和作用很明确，即将密钥信息隐藏于白盒攻击环境之中，避免密钥在密码软件执行过程中被攻击者强行获取。
Chow 等对白盒密码的设计思想［2］就是混淆—打乱明文到密文之间的映射关系即将密码算法的输入和输出进行置乱，使得密码算法被混淆，从而避免攻击者强行得出密钥信息。根据此思路，白盒DES 算法［1］便被设计出来用于避免攻击者强行得出密钥信息；
在2003年，Chow等又提出白盒AES算法［3］，用查找表的形式来代替密码算法的执行全程，而密钥信息就隐藏在查找表中，攻击者从查找表中侦听到密钥信息将很困难。2005年Billet等提出了针对该白盒AES 算法的攻击方法［4］，通过对查找表的分析，在230的时间复杂度内可以恢复查找表所混淆的信息，从而获取密钥信息。在2010 年，肖雅莹和来学嘉提出一种能够抵抗BGE 攻击的白盒AES 的可靠实现［5］，将密码算法的实现由查找表和矩阵乘法共同完成，此算法可以得到更高的复杂度和安全性，但也需要耗费更大的内存空间，在PC上需要几秒钟的运行时间。另外还有其他一些相关工作［8～17］，性能均有待提高。
为了验证与改善Chow等提出的白盒AES算法的性能，本文设计并实现了Chow白盒AES算法，并且针对算法的不同功能模块建立了相应的加速查找表，选择合理有效的数据结构，改进了白盒AES算法各主要功能模块的性能。实验证明本文设计的白盒AES 算法优化方案可在白盒攻击环境下对字符进行高效地加密和解密操作，同时能够有效地保护密钥信息。
Chow 等提出的白盒AES 算法的主要实现难度在于对于有限域GF运算的实现以及各查找表的构建与相关数据结构和函数的设计；
本文设计合适的数据结构建立算法中相应的各类查找表，实现白盒AES 算法中的各主要功能模块，能够提高白盒AES算法的性能，总体设计流程图如图1所示。
图1 白盒AES算法实现总体设计流程图
执行白盒AES算法的前后需要进行有关PKCS（The Public-Key Cryptography Standards，公钥密码标准）5Padding 的操作。在加密之前需要对明文进行PKCS 5Padding 填充，明文由UI 传入之后先分组，每一组大小16bits，如果最后一组刚好是16bits，那么填充一组“16”，如果不满，则填充缺少的那个字符。
本文针对白盒AES 的改进主要在于对于各种类型查找表的构造，首先分析整个算法的查找表查找流程、各查找表之间的关系、数量情况以及占用内存情况。
域具备加法和乘法上的封闭性，就是说对域中的元素进行加法或乘法运算后的结果仍然是域中的元素；
这里所说的加法和乘法分别对应与运算和异或运算。有限域是指元素个数为有限个数的域。而GF（28）中的元素都为多项式：
这些多项式与256 个数一一对应，将数的运算变成了多项式的运算，而此多项式又对应着一个数，由此达到混淆的目的。Galois（伽罗华）域SDK—m4ri 对GF（28）的有关运算提供了支持。以AES-128为例的普通AES算法流程如图2。
图2 普通AES加密流程
白盒AES 算法流程如图3 所示，其改变了每一轮的局限，把AddRoundKeys 和下一轮的SubBytes两个步骤联合起来作为一个新的步骤，将这个新的步骤称之为T-Box（T盒）。这样密钥信息就被隐藏在SubBytes（即S盒中）。
图3 白盒AES加密流程
其中T 为T 盒，是由AddRoundKey 和SubBytes所组成的；
T盒能够用以下公式表示：
S 为S 盒，是 固 定 的8bits 输 入8bits 输 出 的 置换；
mbi为线性变换，用于对T 盒进行混淆作用；
MB为一个32×32（bits）的双射，用于对MC 进行混淆；
mbi 和MB 的混淆作用都需要用额外的计算来进行抵消。
在算法的实现过程中密钥是事先选定的，因此T 盒是可以计算出来的，根据式（3）和式（4）可以知道T 盒也是由8bits 输入到8bits 输出，由于明文为128bits，所以每一轮需要16 个T 盒来支持变换，总共需要160个T盒。
白盒密码的首要目标就是保护密钥信息，而密钥信息隐藏在T 盒里面，因此对于T 盒的保护就变成了首要目标，由此避免攻击者获取密钥信息。
在AES 中的每一轮状态都可以用一个4×4（bits）的单元进行表示，128bits 的明文在此变为了128×128（bits）的矩阵，为了符合4×4单元，将32×32看作是4×4 矩阵中的一个元素，而MixColumn 变换操作一次执行一列，因此可以看作是一个32×32（bits）的矩阵MC 乘以一个32bits 的列向量进行表示，需要一次性占用B232×32=16G 的内存。可以将MC按列分为4个MCi，在这之前还需要左乘一个32×32（bits）的双射MB 进行混淆，因此整个过程可以表示为
式（4）的hi是T 盒经过混淆之后进行的一部分MixColumn 的结果，可以用一个8bits 输入32bits 输出的查找表进行表示，这个查找表加入置乱编码后就形成了类型Ⅱ查找表（如图4）。h0⊕h1⊕h2⊕h3中的三个异或加入置乱编码之后则可以用类型Ⅳ查找表来表示（如图5）。
图4 TypeⅡ查找表结构
图5 TypeⅣ查找表结构
图6 TypeⅢ查找表结构
而对于所有的输入输出是用了两个128bits 到128bits 的双射，此双射包含了抵消混淆效果的mbi-1，对此双射的置乱编码可以用类型Ⅰ查找表（如图7）进行表示。
图7 TypeⅠ查找表结构
总结一下四个类型的查找表：类型Ⅰ表具有2个4位的输入编码，一个128×8的矩阵，和32个4位的输出编码；
类型Ⅱ表具有2个4位输入编码，一个8×8 混合双射，一个T 盒，一个32×8 的代表（MB·MCi-1）的矩阵，8个4位的输出编码；
类型Ⅲ表具有2 个4 位的输入编码，一个32×8 的矩阵，和8 个4 位的输出编码。类型Ⅳ表具有2 个4 位输入编码，已知的异或操作和一个4位输出编码
总体的查找表访问流程如图8。
图8 白盒AES查找表流程
由此可以计算出总共的查找表的数量和总共所需的占用内存：
TypeⅡ和TypeⅢ：9×2×4×2＝288 个表，每个表大小为28×32＝8192bytes；
用于支持TypeⅡ和TypeⅢ的TypeⅣ：9×2×4×8 × 3＝1728 个 表，每 个 表 的 大 小 为28× 4＝1024bytes；
TypeⅠ：2×4＝32个表，每个表的大小为28×4＝1024bytes；
用于支持TypeⅠ的TypeⅣ：2×32×15＝960 个表，每个表的大小为8192bytes。
因此总的查找表大小为770048B（752KB）。
Type II and III：288 次查找访问；
支持II，III 的Type IV：1728次查找访问；
Type I：32×4＝128 次查找访问；
支持I 的Type IV：960次查找访问。
在此白盒AES加密算法函数实现基础上，由于相关的各类型查找表的构造、访问，都已实现好，因此增加了相应的白盒AES解密功能，解密步骤如下：
1）对解密密钥进行赋值；
2）白盒AES解密算法的初始化；
3）循环对每一段密文进行解密；
4）对解密后的密文进行拼接；
5）删除填充字符并计算明文长度；
6）释放资源。
解密所得到的明文将返回给UI 界面显示出来，并与普通AES算法得出的明文进行比对。
在加密操作的第三步和解密操作的第四步中，都有一个对字符填充的操作。在加密的时候，需要对明文进行PKCS 5Padding填充。填充过程伪代码如下：
1）if（明文字长为16的整数倍）
2）｛填充一组（一组16 字节）全为‘16’的字符串｝
3）else
4）｛最后一组的末尾填充字符，字符为需要填充的个数｝
如此进行填充完之后才可执行之后的加密操作。
同理，在解密操作时，需要对解密操作之后的字符串进行删除填充操作才能得到相应的明文，而删除操作实际上只要得出真正明文的长度来即可。于是只需减掉最后一个字符个数，即可得出真实明文长度。根据此长度循环获取明文字符即可。
为了判别算法实现的准确性，设计了算法演示UI，在UI 中加入了AES 对照组用于检验加解密结果是否正确。实验中，采用Java编写，在配置为Xeon2.3GHz*24*6 核，64GB 内存，512GB 硬盘的服务器上运行。
密钥的设置由文件输入传入，将带有密钥的。txt 文本输入即可（在实际应用过程中可由加密者自己设置，写入实现代码中以防止被攻击者通过其他方式），通过加密这个动作将密钥和明文这两个信息传给后端程序执行加密操作，得出的密文返回至UI 上进行显示。另外，由于AES 算法的密钥分别有128bits，192bits和256bits，因此UI应能够选择哪一种密钥，利用UI界面执行下述实验测试。
执行白盒AES加解密算法的程序，首先需要提供存储密钥的文本文件，输入明文，执行加密操作，可以看到普通AES密文和白盒AES密文，再将密文复制到解密组的密文输入框中，执行解密操作，可以得到普通AES明文和白盒AES明文。
通过UI 可以看到白盒AES 加解密的中间步骤，可以看到明文经过PKCS5Padding 填充之后的字符。明文“0123456789abcde”为16 位，因此需要在后面再填充16×16，本文实验将它们作2 位16 进制输出。
而后可以看见，白盒AES 加密先对前16 个字符进行了加密，因为是128bits 的白盒AES 加密。先进行类型Ⅰ查找表的访问和类型Ⅳ查找表的访问；
根据实验结果所示，访问之后变为了e0e83946 5340009e 4e007a3e f2d185b6，UI 界面显示了该明文在10轮过程中的变化情况。
之后便是对下一组16 个字符的加密操作，经过10 轮的变换后所得出的字符与之前所得到的字符进行拼接，得出密文。
同样，实验验证了解密的中间过程。可以看到解密过程也是先对128bits 的密文进行操作，完成10 轮变换之后得到一组明文，然后再对下一个128bits 的密文进行解密操作，得到一组明文，将这两组明文拼接起来，再进行去PKCS5Padding 填充操作，去掉16×16 之后，得到正确的明文“0123456789abcde”。
当明文的位数不是16 的整数倍的时候，PKCS5Padding填充将会把此明文填充至16 的整数倍，填充的字符为缺少个数的数字。明文为
00112233445566778899aabbcce
实验中有关查找表的构建需要用到GF（28）的运算，而有关GF 运算的编程实现有伽罗华域SDK m4ri 来提供支持，改进的白盒AES 算法将原有的AES算法改成关于查找表的查找操作，对所需查找表的个数以及所要占用的内存进行详细的分析与计算：总共需要查找表3008 个，所需要访问次数为3104次，查找表占用内存752KB，算法运算加、解密时间均在0.1s内，获得了良好的性能。
本文分析普通AES 算法在白盒攻击环境下存在的安全隐患，考虑到伽罗瓦域运算［6］的需求，选用了合适的SDK，构造相应的数据结构来支持建立白盒AES算法所需的各类型查找表；
设计各种查找表的访问改进了白盒AES算法的主要功能模块，如ByteRotation，MixColumn和ByteSubstitution等；
选用多个测试用例，根据所实现的白盒AES算法对加解密结果做出相应的测试和分析，并和普通AES的结果进行了对比。实验证明改进的白盒AES 算法具有良好的准确性和效率，对于不同类型的复杂字符都能实现白盒AES算法。