假设有如下场景：XML 文件需要在客户端和服务器端进行传输，文件的内容分为两类：敏感信息 ( 如密码，证书内容 ) 和普通信息。客户端和服务器端都可以独立获得应用程序的 USERID 和 PASSWORD。传输方式不限 (SSL 通常建立在 TCP 之上 )。

　　AES 加密算法

　　数据的安全性跟一个好的密码算法是紧密相连的。一般的，加密算法有两种：对称加密算法和非对称加密算法。前者使用同一个密钥进行加解密，而后者则使用不同的加解密钥。根据我们的场景，客户端和服务器端都可以获得类似的信息，再通过计算可以得到相同的加密密钥，而无需通过不安全的网络进行直接传输，这样入侵者就无法直接利用网络监听来破获加密密钥，所以本文使用对称加密算法。

　　在过去的 20 多年中，国际上最常用的对称加密算法是数据加密标准 (data encryption standard,DES), 该算法已经被美国国家标准和技术协会 (NIST) 采用。但是，到 2001 年 4 月为止，DES 在许多应用领域中被认为是不安全的，因为它采用的密钥长度为 56 位，许多拥有中等计算资源的计算机就可以用穷尽法搜索出正确的密钥。因此，NIST 采用了另一种新的加密算法来代替 DES，该算法被称为高级加密标准 (advanced encryption standard,AES)。AES 一般具有 128 位的分组长度，密钥长度可分别为 128,192,256 位， 单就安全性而言，AES 的 128 位密钥比 DES 的 56 位密钥强 1021 倍还多。AES 是基于代替 - 置换网络设计的，不管用软 件还是硬件实现都非常高效。AES 算法的具体实现并不是本文的重点，互联网上已经存在了很多用各种语言实现的可用代码。 关于各种对称加密算法的比较分析可以参见参考文献中秦志光教授的《密码算法的现状和发展研究》。

　　敏感信息的加密方案

　　需要传输的 XML 文件如下，其中包含了敏感信息和普通信息。为了简单易懂，这里敏感信息仅以 password 为例。

清单 1. 需要传输的 XML 内容

<?xml　version="1.0"　encoding="UTF-8"?>　 　<app>　 　<!--　non　sensitive　data-->　 　<userid>USERID</userid>　 　<!--　sensitive　data-->　 　<password>PASSW0RD</password>　 </app>　 　

　　清单 1是我们需要传输的原始数据。如果直接传输敏感信息，是非常危险的，所以需要采用加密机制。为了在客户端和服务器端达成统一，我们在 xml 文件中需要指定目前双方所采用的加密算法。同时，我们设计这样的加密密钥：其只在一次传输操作中有效，而一旦离开当前会话立即失效。这样保证了密钥的安全，使数据得到进一步保障。经过加密机制处理后，XML 将呈现为如 清单 2所示的形式。其中，SessionID 用于标识本次会话，cipher 属性表示客户端和服务器端一致认可的加密算法。

清单 2. 加密机制处理后的 XML 文件

<?xml　version="1.0"　encoding="UTF-8"?>　 　<app　SessionID="App-001e3751a6e6-00000d34-000000004ba7589e-0">　 <!--　non　sensitive　data-->　 <userid>USERID</userid>　 <!--　sensitive　data-->　 <password　cipher="aes128">78DFC347E201F24742030E4E03B8A034C83A4F072EA78DF6C6　 3A9AF8DF06E57D42D73DC00D3A01773D1AB8A9DBCE759CACC324BD23D141A0CE4F68FA　 　E6332970FD272250014A1C1CC82EB1637487A430</password>　 </app>　 　

　　这样，经过加密机制的处理，敏感信息 password 的内容以加密后的形式呈现。 现在开始，将分步介绍本文对敏感信息的加密和解密机制，以了解上述 XML 文件中敏感信息 password 的加密值是如何得到的。主要步骤可分为数据对齐及初步保护，加密算法的密钥选取，加密内容的十六进制字符串呈现，以及相应的解密方法。下面以客户端加密、服务器端解密为例进行说明。因为加密和加密过程在客户端和服务器端是一致的 , 所以逆向加解密，即服务器端加密、客户端解密的过程与此类似。

　　加密过程

　　Step 1.1. 敏感信息的 Pack 操作，对齐字节并对数据进行初步保护

　　因为 AES 算法是一种分组算法，而且每个分组必须是 32 位的整数倍，并且最小值为 128 位，我们需要对加密的数据进行 数据对齐，这里采用 16 字节即 128 位对齐。并且，为了保证数据的完整性，对数据加入头部和尾部，其中头部和尾部都有 标识符来表征数据的完整性。以上整个过程我们称之为 Pack 操作。

　一旦该数据被意外截断，就可以通过头尾部检测到，无论发送方还是接收方都会丢弃此类数据，以保证系统安全。以下是 Pack 操作的具体步骤：

　　读取用户提供的需要加密的内容，对 password 的实际值 PASSWORD 进行 Pack 操作，使用到的数据结构参见 清单 3中的示例。数据在 Pack 操作后呈现的结构如 图 1所示：

清单 3. 头部结构的定义

struct　DataHeader　{　 　#pragma　pack(push,　1)　//　使结构体　1　字节对齐　 　　UINT32　　canary1;　　//　标识，用于检测数据是否截断，设置值为　(0xDEADC0DE)　 　　UINT8　　version;　　//　头部版本（以　0　开始）　 　　UINT8　　reserved1;　//　保留位　 　　UINT16　　offset;　　//　从开始到有效负载数据的偏移量（头部长度）　 　　UINT32　　size;　　　//　有效负载数据的长度　 　　UINT16　　reserved2;　//　保留位　 　　UINT8　　reserved3;　//　保留位　.　 　　UINT8　　UIDsize;　　//　UID　的长度　 　#pragma　pack(pop)　 　}　header;　 　//　备注　:　接下来的两个字段可以根据实际需要设置　 　//　　　　文件的其余部分结构如下设置　 　//　char[]　　UID;　　　　//　UID　指每次会话的　SessionID（不含结尾的　NULL　符）　 　//　UINT8[]　payload;　　//　需要传输的数据，即有效负载数据　 　//　UINT32　　canary2;　　//　标识，用于检测数据是否截断，设置值为　(0xDEADC0DE)　

图 1. Pack 后的数据结构图

为什么我们在敏感数据的头尾部加上标识 canary 呢？这出自这样一个传说。大家知道 canary 是金丝雀的意思。古代挖煤的工人由于没有像现在 这么高级的瓦斯探测仪，所以往往不知道前方是不是危险区域，该不该进入。所以有一个工人想到了一个妙招，在挖煤的地点放一只金丝雀，如果 发现金丝雀站立不稳，就知道这里是危险区域，应马上离开。所以我们在数据的头尾部加上这样的标识，一旦数据发生异动，就可以及时丢弃异常数据， 报告错误。

　　对上述头部结构体的内容进行赋值之后，需要把特定内容转换为网络序以便网络传输， 如 清单 4所示：

清单 4. 设置头部结构的网络序

//　从主机序转换为网络序，以便网络传输　.　 　　header.canary1　=　htonl(header.canary1);　 　　header.offset　=　htons(header.offset);　 　　header.size　　=　htonl(header.size);　 　　Canary2　=　header.canary1;

　　然后，对整个数据进行 16 字节的对齐操作，如 清单 5所示。

清单 5. 数据的 16 字节对齐

UINT32　size　=　sizeof(header)　+　UID.size()　+　payload.size()　+　sizeof(header.canary1);　 　　if(size　%　16)　 　　　　　　size　+=　16　-　(size　%　16);　 　//　原数据需　copy　到上述　size　的结构中

　　这样就会产生 0 到 15 个字节的空位，在图 1 中用 Padding dummy 表示。 Padding dummy 的长度在 0 到 15 个字节，其取决于 DataHeader, UID, Payload 和 Canary2 的长度和。 padding dummy 的值可以用空值填充。

　　由此可以看到，数据进行打包后，在数据的头部和尾部都含由一个符合网络序的校验码 0xDEADC0DE，并且在头部结构体中包含了整 个数据各部分内容的偏移量等信息，这个机制保证了，一旦数据在传输过程中被截断或者被更改就可以很容易的检测到，对数据提供了初步的保护。

　　Step 1.2 AES 加密算法密钥的获取

　　下面我们考虑 AES 的密钥如何选取。一般的，可以用用户密码的 MD5 值作为 AES 密钥，但是一旦入侵者监听到散列后的密码值，则比较危险。 而且，目前 MD5 算法已被破解。所以直接采用 MD5 来对用户密码进行散列得到密钥的做法是不太安全的。

　　如果我们在散列算法中加入特殊的密钥，来结合用户密码产生 AES 密钥，双重保证可以大大提高安全性。HMAC(Keyed-Hash Message Authentication Code) 刚好可以实现此策略。 HMAC 是一种经加密的散列消息验证码，是一种使用加密散列函数和密钥计算出来的一种消息验证码（MAC）。就像任何 MAC 一样，它也可以对信息数据的完 整性和真实性进行同步检查。查看参考资料中的“HMAC”获得更多关于 HMAC 的信息。