eCryptfs文件格式解析与标签格式详解

套用云计算常用的“Xxx as a Service”，eCryptfs是“Gnupg as a filesystem”。加密文件的密钥信息或者存储在文件的头部，或者存储在文件的扩展属性“user.ecryptfs”之中。

用于加密/解密eCryptfs文件系统中文件的密钥来源于内核生成的一个随机数。这个密钥并没有存储在eCryptfs文件系统的文件头或文件的扩展属性之中。那么存在文件头或扩展属性中的是什么呢？存储的是对这个密钥的一个加密后的结果。用于加密这个密钥的密钥称为FEKEK（File Encryption Key Encryption Key）。在打开文件时，内核要用FEKEK对存储于文件头或文件扩展属性中的加密后的密钥信息进行解密，将解密后的密钥保存起来，供文件读写操作使用。

下面看一下eCryptfs中的文件格式（假设密钥存储在文件头部），见表17-1。

表17-1 eCryptfs文件格式

㊀ 幻数（magic number）的头4个字节是m_1，尾4个字节是m_2，m_1和m_2满足条件：m_1^0x3c81b7f5==m_2。

㊁ 标记用到了4个bit，分别标记ENABLE_HMAC、ENCRYPTED、METADATA_IN_XATTR、ENCRYPT_FILENAMES

㊂ 当版本大于或等于1时有此域。

㊃ 当版本大于或等于1时有此域。

上表中的密钥和加密算法信息有两种格式：tag_3_packet和tag_1_packet，均来自rfc2440下面分别讲解。

（1）tag_3_packet

tag_3_packet的格式见表17-2。

表17-2 tag 3_packet格式

㊄ 此处变长，1～2B，本表按2B计算。

Tag 3 ID是0x8c。版本号是4。算法编码的相关数据结构为

(www.xing528.com)

几个相关的定义是：

S2K标记固定为3。Hash ID固定为1，表示使用MD5算法。

tag_3_packet之后紧跟着一个tag_11_packet，见表17-3。tag_3_packet包含密钥信息tag_11_packet包含密钥的名字。

表17-3 tag_11_packet格式

㊀ 此处变长，1～2B，本表按2B计算。

Tag 11 ID为0xed。格式描述符固定为0x62。文件名长度固定为8。文件名和日期都被eCryptfs的加解密逻辑忽略，它们的存在是由于eCryptfs使用了rfc2440提供的格式，在rfc2440提供的格式中包含文件名和日期。

这里有一个容易混淆的地方，在rfc2440中Tag 11的内容部分用来存储签名信息。eCryptfs的Tag 11的内容部分存储的不是签名，而是一个密钥的名字（描述），这个密钥就是用于加密密钥的密钥——FEKEK。

Tag 3和Tag 11一起用来描述eCryptfs使用口令生成FEKEK的情况。口令是一个字符串，经过若干次哈希迭代最终生成一个定长的密钥，它就是FEKEK。用FEKEK加密实际的密钥，存储为表17-2中的“加密后的密钥”。而Tag 11中的内容是密钥的名字（描述），内核将对FEKEK再额外多做一次哈希迭代的结果作为密钥（FEKEK）的名字。

（2）Tag_1_packet

前面介绍了tag_3_packet，下面介绍另一种格式tag_1_packet，其格式见表17-4。

表17-4 tag_1_packet包格式

Tag 1 ID固定为0x01。版本号固定为3。

在表17-1中的“密钥和加密算法信息”中可以包含多个单元，每个单元或者是一个tag_3_packet加一个tag_11_packet，或者是一个tag_1_packet。