Chrome OS基于EXT4 Encryption的用户数据安全保护机制

author : suezi(@suezi86) of IceSword Lab , Qihoo 360


概述 回页首

  自2015年开发的EXT4 Encryption经过两年的验证性使用,Google终于在年初的时候将EXT4 Encryption 合并入Chrome OS用于保护用户的隐私数据,完成与eCryptfs同样的功能,简称该技术为Dircrypto。当前,Chrome OS仍是eCryptfs和Dircrypto两种技术并存,但优先采用Dircrypto,这表明Dircrypto将成为以后的主流趋势。本文试图阐述该技术的实现原理。
  与eCryptfs一样,EXT4 Encryption用于完成文件(包括目录)和文件名的加密,以实现多用户系统中各个用户私有数据的安全,即使在设备丢失或被盗的情况下,用户隐私数据也不会轻易被人窥见。本文着重介绍文件内容加解密,文件名加解密留给读者自行研究,技术要点主要包括:加解密模型、密钥管理、EXT4 Encrytion功能的开/关及参数设定操作。

EXT4 Encryption 简述 回页首

  创立eCryptfs十年之后,其主要的作者Michael Halcrow已从之前的IBM转向服务Google。Google在保护用户数据隐私方面具有强烈的需求,应用在其旗下的Android、Chrome OS及数据中心,此时采用的文件系统都是EXT4,eCryptfs属于堆叠在EXT4上的文件系统,性能必定弱于直接在EXT4实现加密,恰好EXT4的主要维护者是Google的Theodore Ts’o ,因此由Michael Halcrow主导、Theodore Ts’o协助开发完成EXT4 Encryption,目标在于“Harder,Better,Faster,Stronger”。
  相比eCryptfs,EXT4 Encryption在内存使用上有所优化,表现在read page时,直接读入密文到page cache并在该page中解密;而eCryptfs首先需要调用EXT4接口完成读入密文到page cache,然后再解密该page到另外的page cache页,内存花销加倍。当然,write page时,两者都不能直接对当前page cache加密,因为cache的明文内容需要保留着后续使用。在对文件加密的控制策略上,两者都是基于目录,但相比eCryptfs使用的mount方法,EXT4 Encryption采用ioctl的策略显得更加方便和灵活。另外,在密钥管理方面,两者也不相同。
  EXT4 Encryption加/解密文件的核心思想是:每个用户持有一个64 Bytes的master key,通过master key的描述(master key descriptor,实际使用时一般采用key signature加上”ext4:”前缀)进行识别,每个文件单独产生一个16 Bytes的随机密钥称为nonce,之后以nonce做为密钥,采用AES-128-ECB算法加密master key,产生derived key。加/解密文件时采用AES-256-XTS算法,密钥是derived key。存储文件时,将包含有格式版本、内容加密算法、文件名加密算法、旗标、master key描述、nonce等信息在内的数据保存在文件的xattr扩展属性中。而master key由用户通过一些加密手段进行存储,在激活EXT4 Encryption前通过keys的系统调用以“logon”类型传入内核keyring,即保证master只能被应用程序创建及更新但不能被应用程序读取。加密是基于目录树的形式进行,加密策略通过EXT4_IOC_SET_ENCRYPTION ioctl对某个目录进行下发,其子目录或文件自动继承父目录的属性,ioctl下发的内容包括策略版本号、文件内容加密模式、文件名加密模式、旗标、master key的描述。文件read操作时,从磁盘block中读入密文到page cache并在该page中完成解密,然后拷贝到应用程序;文件write时采用write page的形式写入磁盘,但不是在当前page cache中直接加密,而是将加密后的密文保存在另外的page中。
  和eCryptfs一样,EXT4 Encryption在技术实现时利用了page cache机制的Buffered I/O,换而言之就是不支持Direct I/O。其加/解密的流程如图一所示。



图一 EXT4 Encryption加/解密流程

图一中,在创建加密文件时通过get_random_bytes函数产生16 Bytes的随机数,将其做为nonce保存到文件的xattr属性中;当打开文件时取出文件的nonce和master key的描述,通过master key描述匹配到应用程序下发的master key;然后以nonce做为密钥,采用AES-128-ECB算法加密master key后产生derived key,加/解密文件时采用该derived key做为密钥,加密算法由用户通过ioctl下发并保存到xattr的”contents_encryption_mode”字段,目前版本仅支持AES-256-XTS;加/解密文件内容时调用kernel crypto API完成具体的加/解密功能。
  下面分别从EXT4 Encryption使用的数据结构、内核使能EXT4 Encryption功能、如何添加master key到keyring、如何开启EXT4 Encryption功能、创建和打开加密文件、读取和解密文件、加密和写入加密文件等方面详细叙述。

EXT4 Encryption详述 回页首

EXT4 Encryption的主要数据结构 回页首

  通过数据结构我们可以窥视到EXT4 Encryption的密钥信息的保存和使用方式,非常有利于理解该加密技术。涉及到主要数据结构如下:
  master key的payload的数据表示如清单一所示,应用程序通过add_key系统调用将其和master key descriptor传入内核keyring。

清单一 master key

1
2
3
4
5
6
/* This is passed in from userspace into the kernel keyring */
struct ext4_encryption_key {
__u32 mode;
char raw[EXT4_MAX_KEY_SIZE];
__u32 size;
} __attribute__((__packed__));

  EXT4 Encryption的文件加密信息的数据存储结构如清单二结构体struct ext4_encryption_context所示,每个文件都对应保存着这样的一个数据结构在其xattr中,包含了加密版本、文件内容和文件名的加密算法、旗标、master key descriptor和随机密钥nonce。

清单二 加密信息存储格式

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
/**
* Encryption context for inode
*
* Protector format:
* 1 byte: Protector format (1 = this version)
* 1 byte: File contents encryption mode
* 1 byte: File names encryption mode
* 1 byte: Reserved
* 8 bytes: Master Key descriptor
* 16 bytes: Encryption Key derivation nonce
*/
struct ext4_encryption_context {
char format;
char contents_encryption_mode;
char filenames_encryption_mode;
char flags;
char master_key_descriptor[EXT4_KEY_DESCRIPTOR_SIZE];
char nonce[EXT4_KEY_DERIVATION_NONCE_SIZE];
} __attribute__((__packed__));

  设置EXT4 Encryption开启是通过对特定目录进行EXT4_IOC_SET_ENCRYPTION ioctl完成,具体策略使用清单三所示的struct ext4_encryption_policy 数据结构进行封装,包括版本号、文件内容的加密算法、文件名的加密算法、旗标、master key descriptor。每个加密文件保存的ext4_encryption_context信息均继承自该数据结构,子目录继承父目录的ext4_encryption_context。

清单三 Encryption policy

1
2
3
4
5
6
7
8
9
/* Policy provided via an ioctl on the topmost directory */
struct ext4_encryption_policy {
char version;
char contents_encryption_mode;
char filenames_encryption_mode;
char flags;
char master_key_descriptor[EXT4_KEY_DESCRIPTOR_SIZE];
} __attribute__((__packed__));
`

  open文件时将文件加密相关信息从xattr中读出并保存在清单四的struct ext4_crypt_info数据结构中,成员ci_ctfm用于调用kernel crypto,在文件open时做好key的初始化。从磁盘获取到加密信息后,将该数据结构保存到inode的内存表示struct ext4_inode_info中的i_crypt_info字段,方便后续的readpage、writepage时获取到相应数据进行加/解密操作。

清单四 保存加/解密信息及调用接口的数据结构

1
2
3
4
5
6
7
8
struct ext4_crypt_info {
char ci_data_mode;
char ci_filename_mode;
char ci_flags;
struct crypto_ablkcipher *ci_ctfm;
char ci_master_key[EXT4_KEY_DESCRIPTOR_SIZE];
};
`

  如清单五所示,采用struct ext4_crypto_ctx 表示在readpage、writepage时进行page加/解密的context。在writepage时因为涉及到cache机制,需要保存明文页,所以专门申请单独的bounce_page保存密文用于写入磁盘,用control_page来指向正常的明文页。在readpage时,通过bio从磁盘中读出数据到内存页,读页完成后通过queue_work的形式调用解密流程并将明文保存在当前页,因此context中存在work成员。另外,为了提高效率,在初始化阶段一次性申请了128个ext4_crypto_ctx的内存空间并通过free_list链表进行管理。

清单五 用于表示加/解密page的context

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
struct ext4_crypto_ctx {
union {
struct {
struct page *bounce_page; /* Ciphertext page */
struct page *control_page; /* Original page */
} w;
struct {
struct bio *bio;
struct work_struct work;
} r;
struct list_head free_list; /* Free list */
};
char flags; /* Flags */
char mode; /* Encryption mode for tfm */
};
`

使能EXT4 Encryption 回页首

  Linux kernel具有良好的模块化设计,EXT4 Encryption属于一个EXT4 FS中一个可选的模块,在编译kernel前需通过配置选项使能该功能,如下:
CONFIG_EXT4_FS_SECURITY=y
CONFIG_EXT4_FS_ENCRYPTION=y

添加master key的流程 回页首

  将master key添加到内核keyring属于EXT4 Encryption的第一步,该步骤通过add_key系统调用完成,master key在不同的Linux发行版有不同的产生及保存方法,这里以Chrome OS为例。
  Chrome OS在cryptohomed守护进程中完成master key的获取和添加到keyring。因为兼容eCryptfs和EXT4 Encryption(为了跟Chrome OS保持一致,后续以Dircrypto代替EXT4 Encryption的称呼),而eCryptfs属于前辈,eCryptfs通过mount的方式完成加密文件的开启,为了保持一致性,cryptohomed同样是在mount的准备过程中解密出master key和开启Dircrypto,此master key即eCryptfs加密模式时用的FEK,master key descriptor即FEK的key signature,所以本节介绍Dircrypto流程时所谓的mount流程,望读者能够理解,在Dircrypto模式下,mount不是真正“mount”,千万不要混淆。cryptohomed的mount流程如下:

  1. cryptohomed在D-Bus上接收到持(包含用户名和密码)有效用户证书的mount请求,当然D-Bus请求也是有权限控制的;
  2. 假如是用户首次登陆,将进行:
    a. 建立/home/.shadow/[salt_hash_of_username]目录,采用SHA1算法和系统的salt对用户名进行加密,生成salt_hash_of_username,简称s_h_o_u;
    b. 生成vault keyset /home/.shadow/[salt_hash_of_username]/master.0和/home/.shadow/[salt_hash_of_username]/master.0.sum。master.0加密存储了包含有FEK和FNEK的内容以及非敏感信息如salt、password rounds等;master.0.sum是对master.0文件内容的校验和。
  3. 采用通过mount请求传入的用户证书解密keyset。当TPM可用时优先采用TPM解密,否则采用Scrypt库,当TPM可用后再自动切换回使用TPM。cryptohome使用TPM仅仅是为了存储密钥,由TPM封存的密钥仅能被TPM自身使用,这可用缓解密钥被暴力破解,增强保护用户隐私数据的安全。TPM的首次初始化由cryptohomed完成。这里默认TPM可正常使用,其解密机制如下图二所示,其中:
    UP:User Passkey,用户登录口令
    EVKK:Ecrypted vault keyset key,保存在master.0中的”tpm_key”字段
    IEVKK:Intermediate vault keyset key,解密过程生成的中间文件,属于EVKK的解密后产物,也是RSA解密的输入密文
    TPM_CHK: TPM-wrapped system-wide Cryptohome key,保存在/home/.shadow/cryptohome.key,TPM init时加载到TPM
    VKK:Vault keyset key
    VK:Vault Keyset,包含FEK和FNEK
    EVK:Encrypted vault keyset,保存在master.0里”wrapped_keyset”字段


图二 TPM解密VK的流程

图二中的UP(由发起mount的D-Bus请求中通过key参数传入)做为一个AES key用于解密EVKK,解密后得到的IEVKK;然后将IEVKK做为RSA的密文送入TPM,使用TPM_CHK做为密钥进行解密,解密后得到VKK;最后生成的VKK是一个AES key,用于解密master.0里的EVK,得到包含有FEK和FNEK明文的VK。经过三层解密,终于拿到关键的FEK,此FEK在Dircrypto模式下当做master key使用,FEK signature即做master key descriptor使用。
  最后通过add_key系统调用将master key及master key descriptor(在keyring中为了方便区分,master key descriptor由key sign加上前缀”ext4:”组成)添加到keyring,如下清单六代码所示

清单六 Chrome OS传入master key的核心代码

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
key_serial_t AddKeyToKeyring(const brillo::SecureBlob& key,
const brillo::SecureBlob& key_descriptor) {
//参数中的key即是master key,key_descriptor即sig
if (key.size() > EXT4_MAX_KEY_SIZE ||
key_descriptor.size() != EXT4_KEY_DESCRIPTOR_SIZE) {
LOG(ERROR) << "Invalid arguments: key.size() = " << key.size()
<< "key_descriptor.size() = " << key_descriptor.size();
return kInvalidKeySerial;
}

//在upstart中已经通过add_key添加dircrypt的会话keyring
key_serial_t keyring = keyctl_search(
KEY_SPEC_SESSION_KEYRING, "keyring", kKeyringName, 0);
if (keyring == kInvalidKeySerial) {
PLOG(ERROR) << "keyctl_search failed";
return kInvalidKeySerial;
}

//初始化struct ext4_encryption_key
ext4_encryption_key ext4_key = {};
ext4_key.mode = EXT4_ENCRYPTION_MODE_AES_256_XTS;
memcpy(ext4_key.raw, key.char_data(), key.size());
ext4_key.size = key.size();
//key_name就是最后的master key description,由”ext4:”+sig两部分组成
//kernel在request_key时同样是将”ext4:”+sig两部分组成master key description
std::string key_name = kKeyNamePrefix + base::ToLowerASCII(
base::HexEncode(key_descriptor.data(), key_descriptor.size()));
// kKeyType是“logon”,不允许应用程序获取密钥的内容
key_serial_t key_serial = add_key(kKeyType, key_name.c_str(), &ext4_key,
sizeof(ext4_key), keyring);
if (key_serial == kInvalidKeySerial) {
PLOG(ERROR) << "Failed to insert key into keyring";
return kInvalidKeySerial;
}
return key_serial;
}
`

Set Encryption Policy流程 回页首

  通过对目标目录的文件描述符进行ioctl 的 EXT4_IOC_SET_ENCRYPTION_POLICY 操作即完成了EXT4 Encryption的加/解密功能的开启,该步骤在完成添加master key后进行,Chrome OS中的相关代码如下清单七所示,通过struct ext4_encryption_policy指定了策略的版本号、文件内容和文件名的加密算法、旗标、master key的识别描述符。

清单七 Chrome OS set encryption policy的核心代码

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
bool SetDirectoryKey(const base::FilePath& dir,
const brillo::SecureBlob& key_descriptor) {
DCHECK_EQ(static_cast<size_t>(EXT4_KEY_DESCRIPTOR_SIZE),
key_descriptor.size());
/*这里的dir代表要开启EXT4 Encryption的目录 */
base::ScopedFD fd(HANDLE_EINTR(open(dir.value().c_str(),
O_RDONLY | O_DIRECTORY)));
if (!fd.is_valid()) {
PLOG(ERROR) << "Ext4: Invalid directory" << dir.value();
return false;
}
/*初始化struct ext4_encryption_policy对象
* 指定文件内容的加密算法是AES_256_XTS
*/
ext4_encryption_policy policy = {};
policy.version = 0;
policy.contents_encryption_mode = EXT4_ENCRYPTION_MODE_AES_256_XTS;
policy.filenames_encryption_mode = EXT4_ENCRYPTION_MODE_AES_256_CTS;
policy.flags = 0;
// key_descriptor即FEK 的key sig
memcpy(policy.master_key_descriptor, key_descriptor.data(),
EXT4_KEY_DESCRIPTOR_SIZE);
/*通过ioctl完成设置*/
if (ioctl(fd.get(), EXT4_IOC_SET_ENCRYPTION_POLICY, &policy) < 0) {
PLOG(ERROR) << "Failed to set the encryption policy of " << dir.value();
return false;
}
return true;
}
`

  内核对EXT4_IOC_SET_ENCRYPTION_POLICY的ioctl在ext4_ioctl函数中完成响应,从应用程序中接收ext4_encryption_policy,解析其参数,若是首次对该目录进行加密设置则生成一个ext4_encryption_context 数据结构保存包括版本号、文件内容的加密算法、文件名的加密算法、旗标、master key descriptor、nonce在内的所有信息到目录对应inode的xattr中。从此开始,以该目录做为EXT Encryption加密的根目录,其下文件和子目录的除了nonce需要再次单独产生外,其余加密属性均继承自该目录。若非首次对该目录进行EXT4 Encryption设置,则重点比较当前设置是否与先前的设置一致。首先介绍首次设置的情形, ext4_ioctl的函数调用关系如图三所示。



图三 首次进行EXT4 Encryption设置的函数调用关系

  应用程序进行ioctl系统调用经过VFS,最终调用ext4_ioctl函数,借助图三的函数调用可看到进行EXT4 Encryption policy设置时都进行了什么操作。首先判断目录所在的文件系统是否支持EXT4 Encryption操作,具体在ext4_has_feature_encrypt 函数中通过判断superblock的s_es->s_feature_incompat是否支持ENCRYPT属性;然后利用copy_from_user函数从用户空间拷贝ext4_encryption_policy到内核空间;紧接着在ext4_process_policy函数里将ext4_encryption_policy转换成ext4_encryption_context保存到inode的attr;最后将加密目录对应的inode的修改保存到磁盘。重点部分在ext4_process_policy函数,主要分三大步骤,第一步还是进行照例检查校验,包括:访问权限、ext4_encryption_policy的版本号、目标目录是否为空目录、目标目录是否已经存在ext4_encryption_context;第二步为目标目录生成ext4_encryption_context并保存到xattr;最后提交修改的保存请求。第一步的具体操作表现在函数操作上如下:
● inode_owner_or_capable() 完成DAC方面的权限检查
● 对ext4_encryption_policy的版本号version进行检查,当前仅支持版本0
● ext4_inode_has_encryption_context()尝试读取目标目录对应的inode的xattr的EXT4 Encryption字段”c”,看是否存在内容,若存在内容,则说明目标目录在先前已经进行过EXT4 Encryption设置
● S_ISDIR()校验目标目录是否真的是目录
● ext4_empty_dir()判断目标目录是否为空目录,在首次设置EXT4 Encryption时,仅支持对空目录进行操作。这点有别于eCryptfs,eCryptfs加密文件所在的目录下支持非加密和加密文件的同时存在;而EXT4 Encryption要么是全加密,要么是全非加密。
  第二步在ext4_create_encryption_context_from_policy函数中完成,具体如下:
● ext4_convert_inline_data()对inline data做处理
● ext4_valid_contents_enc_mode()校验ext4_encryption_policy的文件内容加密模式是否为AES_256_XTS,当前仅支持该算法的内容加密
● ext4_valid_filenames_enc_mode()校验ext4_encryption_policy的文件名加密模式是否为AES_256_CTS,当前仅支持该算法的内容名加密
● 对ext4_encryption_policy的flags做检验
● get_random_bytes()产生16 Bytes的随机数,赋值给ext4_encryption_context的nonce,其他如master key descriptor、flags、文件内容加密模式、文件名加密模式等值,从ext4_encryption_policy中获取,完成目标目录对应的ext4_encryption_context的初始化
● ext4_xattr_set()将用于目标目录的ext4_encryption_context保存到inode的xattr
● ext4_set_inode_flag()将目标目录对应inode的i_flags设置成EXT4_INODE_ENCRYPT,表明其属性。后续在文件open、read、write时通过该标志进行判断
  最后使用ext4_journal_start、ext4_mark_inode_dirty、ext4_journal_stop等函数完成xattr数据回写到磁盘的请求。
  若非首次对目标目录进行EXT4 Encryption设置,请流程如图四所示,通过ext4_xattr_get函数读取对应inode的xattr的EXT4 Encryption字段”c”对应的内容,即保存的ext4_encryption_context,将其与ext4_encryption_policy的相应值进行对比,若不一致返回-EINVAL。



图四 非首次进行EXT4 Encryption设置的函数调用关系

  相比eCryptfs,此EXT4_IOC_SET_ENCRYPTION_POLICY的ioctl的作用类似eCryptfs的”mount –t ecryptfs ”操作。

creat file流程 回页首

  creat file流程特指应用程序通过creat()函数或open( , O_CREAT, )在已经通过EXT4_IOC_SET_ENCRYPTION_POLICY ioctl完成EXT4 Encryption设置的目录下新建普通文件的过程。希望通过介绍该过程,可以帮助读者了解如何创建加密文件,如何利用master key和nonce生成derived key。
  应用程序使用creat()函数通过系统调用经由VFS,在申请到fd、初始化好nameidata 、struct file等等之后利用ext4_create()函数完成加密文件的创建,函数调用关系如图五所示。
  创建加密文件的核心函数ext4_create()的函数调用关系如图六所示,函数主要功能是创建ext4 inode节点并初始化,这里只关注EXT4 Encryption部分。在创建时首先判断其所在目录inode的i_flags是否已经被设置了EXT4_INODE_ENCRYPT属性(该属性在EXT4_IOC_SET_ENCRYPTION_POLICY ioctl或者在EXT4 Encryption根目录下的任何地方新建目录/文件时完成i_flags设置),若是则表明需要进行EXT4 Encryption;接着读取新文件所在目录,即其父目录的xattr属性获取到ext4_encryption_context,再为新文件生成新的nonce,将nonce替换父目录的ext4_encryption_context中的nonce生成用于新文件的ext4_encryption_context并保存到新文件对应inode的xattr中;然后用ext4_encryption_context中的master key descriptor匹配到keyring中的master key,将ext4_encryption_context中的nonce做为密钥对master key进行AES-128-ECB加密,得到derived key;最后使用derived key和AES-256-XTS初始化kernel crypto API,将初始化好的tfm保存到 ext4_crypt_info 的ci_ctfm成员中,再将ext4_crypt_info保存到ext4_inode_info的i_crypt_info,后续对新文件进行读写操作时直接取出ci_ctfm做具体的加/解密即可。



图五 creat和open file函数调用关系


图六 ext4_create函数调用关系

  具体到图六中ext4_create函数调用关系中各个要点函数,完成的功能如下:
● ext4_encrypted_inode()判断文件父目录的inode的i_flags是否已经被设置了EXT4_INODE_ENCRYPT属性
● ext4_get_encryption_info()读取父目录的xattr属性获取到ext4_encryption_context,并为父目录生成derived key,初始化好tfm并保存到其ext4_inode_info的i_crypt_info
● ext4_encryption_info()确认父目录的ext4_inode_info的i_crypt_info已经初始化好
● ext4_inherit_context()为新文件创建ext4_encryption_context并保存到其xattr中,并为新文件生成derived key,初始化好tfm并保存到其ext4_inode_info的i_crypt_info
  从上可看到ext4_get_encryption_info()和ext4_inherit_context()是最关键的部分,其代码如清单八和清单九所示,代码较长,但强烈建议耐心读完。

清单八 ext4_get_encryption_info函数

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
int ext4_get_encryption_info(struct inode *inode)
{
struct ext4_inode_info *ei = EXT4_I(inode);
struct ext4_crypt_info *crypt_info;
char full_key_descriptor[EXT4_KEY_DESC_PREFIX_SIZE +
(EXT4_KEY_DESCRIPTOR_SIZE * 2) + 1];
struct key *keyring_key = NULL;
struct ext4_encryption_key *master_key;
struct ext4_encryption_context ctx;
const struct user_key_payload *ukp;
struct ext4_sb_info *sbi = EXT4_SB(inode->i_sb);
struct crypto_ablkcipher *ctfm;
const char *cipher_str;
char raw_key[EXT4_MAX_KEY_SIZE];
char mode;
int res;

//若ext4_inode_info中的i_crypt_info有值,说明先前已经初始化好
if (ei->i_crypt_info)
return 0;
if (!ext4_read_workqueue) {
/*为readpage时解密初始化read_workqueue,为ext4_crypto_ctx预先创建128个
*cache,为writepage时用的bounce page创建内存池,为ext4_crypt_info创建slab
*/
res = ext4_init_crypto();
if (res)
return res;
}

/*从xattr中读取加密模式、master key descriptor、nonce等加密相关信息到
*ext4_encryption_context
*/
res = ext4_xattr_get(inode, EXT4_XATTR_INDEX_ENCRYPTION,
EXT4_XATTR_NAME_ENCRYPTION_CONTEXT,
&ctx, sizeof(ctx));
if (res < 0) {
if (!DUMMY_ENCRYPTION_ENABLED(sbi))
return res;
ctx.contents_encryption_mode = EXT4_ENCRYPTION_MODE_AES_256_XTS;
ctx.filenames_encryption_mode =
EXT4_ENCRYPTION_MODE_AES_256_CTS;
ctx.flags = 0;
} else if (res != sizeof(ctx))
return -EINVAL;
res = 0;

crypt_info = kmem_cache_alloc(ext4_crypt_info_cachep, GFP_KERNEL);
if (!crypt_info)
return -ENOMEM;

//根据获取到的ext4_encryption_context内容初始化ext4_crypt_info
crypt_info->ci_flags = ctx.flags;
crypt_info->ci_data_mode = ctx.contents_encryption_mode;
crypt_info->ci_filename_mode = ctx.filenames_encryption_mode;
crypt_info->ci_ctfm = NULL;
memcpy(crypt_info->ci_master_key, ctx.master_key_descriptor,
sizeof(crypt_info->ci_master_key));
if (S_ISREG(inode->i_mode))
mode = crypt_info->ci_data_mode;
else if (S_ISDIR(inode->i_mode) || S_ISLNK(inode->i_mode))
mode = crypt_info->ci_filename_mode;
else
BUG();

switch (mode) {
case EXT4_ENCRYPTION_MODE_AES_256_XTS:
cipher_str = "xts(aes)";
break;
case EXT4_ENCRYPTION_MODE_AES_256_CTS:
cipher_str = "cts(cbc(aes))";
break;
default:
printk_once(KERN_WARNING
"ext4: unsupported key mode %d (ino %u)\n",
mode, (unsigned) inode->i_ino);
res = -ENOKEY;
goto out;
}
if (DUMMY_ENCRYPTION_ENABLED(sbi)) {
memset(raw_key, 0x42, EXT4_AES_256_XTS_KEY_SIZE);
goto got_key;
}

//实际使用时将master key descriptor加上”ext4:”的前缀用于匹配master key
memcpy(full_key_descriptor, EXT4_KEY_DESC_PREFIX,
EXT4_KEY_DESC_PREFIX_SIZE);
sprintf(full_key_descriptor + EXT4_KEY_DESC_PREFIX_SIZE,
"%*phN", EXT4_KEY_DESCRIPTOR_SIZE,
ctx.master_key_descriptor);
full_key_descriptor[EXT4_KEY_DESC_PREFIX_SIZE +
(2 * EXT4_KEY_DESCRIPTOR_SIZE)] = '\0';

//使用master key descriptor为匹配条件向keyring申请master key
keyring_key = request_key(&key_type_logon, full_key_descriptor, NULL);
if (IS_ERR(keyring_key)) {
res = PTR_ERR(keyring_key);
keyring_key = NULL;
goto out;
}

//确保master key的type是logon类型,防止应用程序读取到key的内容
if (keyring_key->type != &key_type_logon) {
printk_once(KERN_WARNING
"ext4: key type must be logon\n");
res = -ENOKEY;
goto out;
}

down_read(&keyring_key->sem);
//从keyring中取出master key的payload
ukp = user_key_payload(keyring_key);
if (ukp->datalen != sizeof(struct ext4_encryption_key)) {
res = -EINVAL;
up_read(&keyring_key->sem);
goto out;
}

//取出master key的有效数据ext4_encryption_key
master_key = (struct ext4_encryption_key *)ukp->data;
BUILD_BUG_ON(EXT4_AES_128_ECB_KEY_SIZE !=
EXT4_KEY_DERIVATION_NONCE_SIZE);
if (master_key->size != EXT4_AES_256_XTS_KEY_SIZE) {
printk_once(KERN_WARNING
"ext4: key size incorrect: %d\n",
master_key->size);
res = -ENOKEY;
up_read(&keyring_key->sem);
goto out;
}

/*以nonce做为密钥,采用AES_128_ECB算法,利用kernel crypto API加密master
* key(master_key->raw),生成derived key保存在raw_key里
*/
res = ext4_derive_key_aes(ctx.nonce, master_key->raw,
raw_key);
up_read(&keyring_key->sem);
if (res)
goto out;
got_key:
//为AES_256_XTS加密算法申请tfm
ctfm = crypto_alloc_ablkcipher(cipher_str, 0, 0);
if (!ctfm || IS_ERR(ctfm)) {
res = ctfm ? PTR_ERR(ctfm) : -ENOMEM;
printk(KERN_DEBUG
"%s: error %d (inode %u) allocating crypto tfm\n",
__func__, res, (unsigned) inode->i_ino);
goto out;
}
crypt_info->ci_ctfm = ctfm;
crypto_ablkcipher_clear_flags(ctfm, ~0);
crypto_tfm_set_flags(crypto_ablkcipher_tfm(ctfm),
CRYPTO_TFM_REQ_WEAK_KEY);

//向kernel crypto接口里设置加密用的key为derived key
res = crypto_ablkcipher_setkey(ctfm, raw_key,
ext4_encryption_key_size(mode));
if (res)
goto out;

/*将初始化好的ext4_crypt_info 实例crypt_info拷贝到inode的ext4_inode_info 的*i_crypt_info。
*后续加/解密文件内容时直接取出ext4_inode_info的i_crypt_info,即可从中获取
*到已经初始化好的tfm接口c_ctfm,用其直接加/解密
*/
if (cmpxchg(&ei->i_crypt_info, NULL, crypt_info) == NULL)
crypt_info = NULL;
out:
if (res == -ENOKEY)
res = 0;
key_put(keyring_key);
ext4_free_crypt_info(crypt_info);
memzero_explicit(raw_key, sizeof(raw_key));
return res;
}
`

清单九 ext4_inherit_context函数

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
int ext4_inherit_context(struct inode *parent, struct inode *child)
{
struct ext4_encryption_context ctx;
struct ext4_crypt_info *ci;
int res;

//确保其父目录inode对应的i_crypt_info已经初始化好
res = ext4_get_encryption_info(parent);
if (res < 0)
return res;

//获取父目录的保存在i_crypt_info的ext4_crypt_info信息
ci = EXT4_I(parent)->i_crypt_info;
if (ci == NULL)
return -ENOKEY;
ctx.format = EXT4_ENCRYPTION_CONTEXT_FORMAT_V1;
if (DUMMY_ENCRYPTION_ENABLED(EXT4_SB(parent->i_sb))) {
ctx.contents_encryption_mode = EXT4_ENCRYPTION_MODE_AES_256_XTS;
ctx.filenames_encryption_mode =
EXT4_ENCRYPTION_MODE_AES_256_CTS;
ctx.flags = 0;
memset(ctx.master_key_descriptor, 0x42,
EXT4_KEY_DESCRIPTOR_SIZE);
res = 0;
} else {
/*使用父目录的文件内容加密模式、文件名加密模式、master key descriptor、flags
*初始化新文件的ext4_encryption_context
*/
ctx.contents_encryption_mode = ci->ci_data_mode;
ctx.filenames_encryption_mode = ci->ci_filename_mode;
ctx.flags = ci->ci_flags;
memcpy(ctx.master_key_descriptor, ci->ci_master_key,
EXT4_KEY_DESCRIPTOR_SIZE);
}

//产生16 bytes的随机数做为新文件的nonce
get_random_bytes(ctx.nonce, EXT4_KEY_DERIVATION_NONCE_SIZE);

//将初始化好的新文件的ext4_encryption_context保存到attr中
res = ext4_xattr_set(child, EXT4_XATTR_INDEX_ENCRYPTION,
EXT4_XATTR_NAME_ENCRYPTION_CONTEXT, &ctx,
sizeof(ctx), 0);
if (!res) {
//设置新文件的inode的i_flags为EXT4_INODE_ENCRYPT
ext4_set_inode_flag(child, EXT4_INODE_ENCRYPT);
ext4_clear_inode_state(child, EXT4_STATE_MAY_INLINE_DATA);

/*为新文件初始化好其inode对应的i_crypt_info,主要是完成其tfm的初始化
*为后续的读写文件时调用kernel crypto进行加/解密做好准备
*/
res = ext4_get_encryption_info(child);
}
return res;
}
`

  简单的说,creat时完成两件事:一是创建ext4_encryption_context保存到文件的xattr;二是初始化好ext4_crypt_info 保存到inode的i_crypt_info,后续使用时取出tfm,利用kernel crypto API即完成了加/解密工作。

open file流程 回页首

  这里open file特指打开已存在的EXT4 Encryption加密文件。仅加密部分而言,该过程相比creat少了创建ext4_encryption_context保存到文件的xattr的操作,其余部分基本一致。从应用程序调用open()函数开始到最终调用到ext4_file_open()函数的函数调用关系如上图五所示。本节主要描述ext4_file_open()函数,其函数调用关系如图七。



图七 ext4_file_open函数调用关系

图七所示各函数主要完成的功能如下:
● ext4_encrypted_inode() 判断欲打开文件对应inode的i_flags是否设置成EXT4_INODE_ENCRYPT,若是,表明是加密文件
● ext4_get_encryption_info() 从文件inode的xattr取出文件加密算法、文件名加密算法、master key descriptor、 随机密钥nonce;之后生成加密文件内容使用的密钥derived key并初始化好kernel crypto接口tfm,将其以ext4_crypt_info 形式保存到inode的i_crypt_info。详细代码见清单八
● ext4_encryption_info()确保文件对应inode在内存中的表示ext4_inode_info中的i_crypt_info已经做好初始化
● ext4_encrypted_inode(dir)判断判断欲打开文件的父目录inode的i_flags是否设置成EXT4_INODE_ENCRYPT
● ext4_is_child_context_consistent_with_parent()判断文件和其父目录的加密context是否一致,关键是master key descriptor是否一致
● dquost_file_open() 调用通用的文件打开函数完成其余的操作
  简单的说就是在open file的时候完成文件加/解密所需的所有context。

read file流程 回页首

  加密文件的解密工作主要是在read的时候进行。正常的Linux read支持Buffered I/O和Direct I/O两种模式,Buffered I/O利用内核的page cache机制,而Direct I/O需要应用程序自身准备和处理cache,当前版本的EXT4 Encryption不支持Direct I/O,其文件内容解密工作都在page cache中完成。自应用程序发起read操作到kernel对文件内容进行解密的函数调用关系如图八所示。



图八 read 加密文件的函数调用关系

  ext4 文件读的主要实现在ext4_readpage函数,文件内容的AES-256-XTS解密理所当然也在该函数里,这里主要介绍文件内容解密部分,其函数调用关系如图九所示。ext4 读写通过bio进行封装,描述块数据传送时怎样进行填充或读取块给driver,包括描述磁盘和内存的位置,其内部有一个函数指针bi_end_io,当读取完成时会回调该函数,如图九所示,ext4将bi_end_io赋值为mpage_end_io。mpage_end_io通过queue_work的形式调用completion_pages函数,在该函数中再调用ext4_decrypt函数完成page的解密。ext4_decrypt函数的代码非常简单,如清单十所示。核心的加密和解密函数都在ext4_page_crypto()中完成,因为在open file的时候已经初始化好了kernel crypto接口,所以这里主要传入表明是加密还是解密的参数以及密文页和明文页地址,代码比较简单,如清单十一所示。



图九 ext4_readpage函数调用关系

清单十 ext4_decrypt函数

1
2
3
4
5
6
7
8
int ext4_decrypt(struct page *page)
{
BUG_ON(!PageLocked(page));

return ext4_page_crypto(page->mapping->host, EXT4_DECRYPT,
page->index, page, page, GFP_NOFS);
}
`

清单十一 ext4_page_crypto 函数

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
static int ext4_page_crypto(struct inode *inode, ext4_direction_t rw, pgoff_t index, struct page *src_page,
struct page *dest_page, gfp_t gfp_flags) {
u8 xts_tweak[EXT4_XTS_TWEAK_SIZE];
struct ablkcipher_request *req = NULL;
DECLARE_EXT4_COMPLETION_RESULT(ecr);
struct scatterlist dst, src;
struct ext4_crypt_info *ci = EXT4_I(inode)->i_crypt_info;
struct crypto_ablkcipher *tfm = ci->ci_ctfm; //取出open时初始化好的tfm
int res = 0;
req = ablkcipher_request_alloc(tfm, gfp_flags);
if (!req) {
printk_ratelimited(KERN_ERR "%s: crypto_request_alloc() failed\n", __func__);
return -ENOMEM;
}
ablkcipher_request_set_callback(
req, CRYPTO_TFM_REQ_MAY_BACKLOG | CRYPTO_TFM_REQ_MAY_SLEEP,
ext4_crypt_complete, &ecr);
BUILD_BUG_ON(EXT4_XTS_TWEAK_SIZE < sizeof(index));
memcpy(xts_tweak, &index, sizeof(index));
memset(&xts_tweak[sizeof(index)], 0, EXT4_XTS_TWEAK_SIZE - sizeof(index));

sg_init_table(&dst, 1);
sg_set_page(&dst, dest_page, PAGE_CACHE_SIZE, 0);
sg_init_table(&src, 1);
sg_set_page(&src, src_page, PAGE_CACHE_SIZE, 0);
ablkcipher_request_set_crypt(req, &src, &dst, PAGE_CACHE_SIZE, xts_tweak);
if (rw == EXT4_DECRYPT)
res = crypto_ablkcipher_decrypt(req);
else
res = crypto_ablkcipher_encrypt(req);
if (res == -EINPROGRESS || res == -EBUSY) {
wait_for_completion(&ecr.completion);
res = ecr.res;
}
ablkcipher_request_free(req);
if (res) {
printk_ratelimited( KERN_ERR "%s: crypto_ablkcipher_encrypt() returned %d\n", __func__, res);
return res;
}
return 0;
}

`

write file流程 回页首

  在写入文件的时候会首先将page cache中的文件明文内容进行AES-256-XTS
加密,再通过bio写入磁盘,该工作主要在ext4_writepage()函数中完成,这里主要关注EXT4 Encryption部分,其函数调用关系如图十所示。



图十 ext4_writepage函数调用关系

  图十中,首先照例通过ext4_encrypted_inode()函数利用i_flags是否等于EXT4_INODE_ENCRYPT来判断是否是加密文件;然后使用ext4_encrypt()函数申请新的内存页用于保存密文,完成内容的加密,具体代码见清单十二,函数返回密文页的地址保存在data_page变量;紧着通过io_submit_add_bh()封装写入buffer页到磁盘的请求,这里通过判断data_page页是否空来决定是写入明文页还是密文页,巧妙的兼容了加密和非加密两种模式;最后通过ext4_io_submit()提交bio写盘请求。

清单十二 ext4_encrypt函数

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
struct page *ext4_encrypt(struct inode *inode,
struct page *plaintext_page,
gfp_t gfp_flags)
{
struct ext4_crypto_ctx *ctx;
struct page *ciphertext_page = NULL;
int err;

BUG_ON(!PageLocked(plaintext_page));

//从cache中获取一个ext4_crypto_ctx内存空间
ctx = ext4_get_crypto_ctx(inode, gfp_flags);
if (IS_ERR(ctx))
return (struct page *) ctx;

//从内存池中申请一个内存页,命名为bounce page,用于保存密文内容,同时将
//ext4_crypto_ctx的w.bounce_page指向该bounce page
/* The encryption operation will require a bounce page. */
ciphertext_page = alloc_bounce_page(ctx, gfp_flags);
if (IS_ERR(ciphertext_page))
goto errout;
ctx->w.control_page = plaintext_page;

//调用kernel crypto加密,将密文保存在bounce page
err = ext4_page_crypto(inode, EXT4_ENCRYPT, plaintext_page->index,
plaintext_page, ciphertext_page, gfp_flags);
if (err) {
ciphertext_page = ERR_PTR(err);
errout:
ext4_release_crypto_ctx(ctx);
return ciphertext_page;
}
SetPagePrivate(ciphertext_page);
set_page_private(ciphertext_page, (unsigned long)ctx);
lock_page(ciphertext_page);

//返回密文页bounce page地址
return ciphertext_page;
}

`

  因为在open file的时候已经初始化好了kernel crypto 所需的加密算法、密钥设置,并保存了tfm到文件inode的内存表示ext4_inode_info的成员i_crypt_info中,所以在readpage/writepage时进行加/解密的操作变得很简单。

结语 回页首

  与eCryptfs类似,EXT4 Encryption建立在内核安全可信的基础上,核心安全组件是master key,若内核被攻破导致密钥泄露,EXT4 Encryption的安全性将失效。同样需要注意page cache中的明文页有可能被交换到磁盘的swap区。早期版本的Chrome OS禁用了swap功能,当前版本的swap采取的是zram机制,与传统的磁盘swap有本质区别。相比eCryptfs做为一个独立的内核加密模块,现在EXT4 Encryption原生的存在于EXT4文件系统中,在使用的便利性和性能上都优于eCryptfs,相信推广将会变得更加迅速。

参考资料 回页首

  1. Linux kernel-V4.4.79 sourcecode
  2. Chromium OS platform-9653 sourcecode

ChromeOS基于eCryptfs的用户数据安全保护机制

author : suezi(@suezi86) of IceSword Lab , Qihoo 360


概述 回页首

  Chromebook的使用场景模式是允许多人分享使用同一台设备,但是同时也要保护每个用户数据的私密性,使得每个使用者都不允许访问到对方的隐私数据,包括:账户信息、浏览历史记录和cache、安装的应用程序、下载的内容以及用户自主在本地产生的文本、图片、视频等。本文试图从较高的角度阐述ChromeOS是如何通过eCryptfs机制保护用户数据隐私。

eCryptfs简介 回页首

  eCryptfs在Linux kernel 2.6.19由IBM公司的Halcrow,Thompson等人引入,在Cryptfs的基础上实现,用于企业级的文件系统加密,支持文件名和文件内容的加密。本质上eCryptfs 就像是一个内核版本的 Pretty Good Privacy(PGP)服务,插在 VFS和下层物理文件系统之间,充当一个“过滤器”的角色。用户应用程序对加密文件的写请求,经系统调用层到达 VFS 层,VFS 转给 eCryptfs 文件系统组件处理,处理完毕后,再转给下层物理文件系统;读请求流程则相反。
  eCryptfs 的设计受到OpenPGP规范的影响,核心思想:eCryptfs通过一种对称密钥加密算法来加密文件的内容或文件名,如AES-128,密钥 FEK(File Encryption Key)随机产生。而FEK通过用户口令或者公钥进行保护,加密后的FEK称EFEK(Encrypted File Encryption Key),口令/公钥称为 FEFEK(File Encryption Key Encryption Key)。在保存文件时,将包含有EFEK、加密算法等信息的元数据(metadata)放置在文件的头部或者xattr扩展属性里(本文默认以前者做为讲解),打开文件前再解析metadata。



图一 eCryptfs的系统架构

  eCryptfs的系统架构如图一所示,eCryptfs堆叠在EXT4文件系统之上,工作时需要用户程序和内核同时配合,用户程序主要负责获取密钥并通过(add_key/keyctl/request_key)系统调用传送到内核的keyring,当某个应用程序发起对文件的读写操作前,由eCryptfs对其进行加/解密,加/解密的过程中需要调用Kernel的Crypto API(AES/DES etc)来完成。以对目录eCryptfs-test进行加密为例,为方便起见,在Ubuntu系统下测试eCryptfs的建立流程,如图二所示,通过mount指令发起eCryptfs的建立流程,然后在用户应用程序eCryptfs-utils的辅助下输入用于加密FEK的用户口令及选择加密算法等,完成挂载后意味着已经开始对测试目录eCryptfs-test的所有内容进行加密处理。测试中在eCryptfs-test目录下增加需要加密的文件或目录的内容,当用户umount退出对eCryptfs-test目录的挂载后再次查看该目录时,发现包括文件名和文件内容都进行了加密,如图三所示。



图二 eCryptfs使用时的建立流程


图三 eCryptfs加密后的文件


图四 eCryptfs对文件的加解密流程

  实现上,eCryptfs对数据的加/解密流程如图四所示,对称密钥加密算法以块为单位进行加密/解密,如AES-128。eCryptfs 将加密文件分成多个逻辑块,称为 extent,extent 的大小可调,但是不能大于实际物理页,默认值等于物理页的大小,如32位的系统下是 4096 字节。加密文件的头部存放元数据,包括元数据长度、标志位、旗标、EFEK及相应的signature,目前元数据的最小长度为 8192 字节。加/解密开始前,首先解密FEKEK取出FEK。当读入一个 extent 中的任何部分的密文时,整个 extent 被读入 Page Cache,通过 Kernel Crypto API 进行解密;当 extent 中的任何部分的明文数据被写回磁盘时,需要加密并写回整个 extent。

eCryptfs详述 回页首

  eCryptfs在内核中的实现代码位于kernel/fs/ecryptfs,下面以eCryptfs使用到的关键数据结构、eCryptfs init、eCryptfs mount、file creat、file open、file read、file write的顺序分别介绍eCryptfs是如何工作。另外,eCryptfs还实现了/dev/ecryptfs的misc设备,用于内核与应用程序间的消息传递,如密钥请求与响应,属于非必选项,因此这里不对其进行介绍。

eCryptfs相关的数据结构 回页首

  eCryptfs关键的数据结构包括eCryptfs 文件系统相关file、dentry、inode、superblock、file_system_type描述、auth token认证令牌描述、eCryptfs加密信息描述等。
  eCryptfs文件系统相关的数据结构如清单一所示,下文将会重点介绍file_system_type中的mount函数,即ecryptfs_mount。

清单一 eCryptfs文件系统相关的数据结构

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
/* ecryptfs file_system_type */
static struct file_system_type ecryptfs_fs_type = {
.owner = THIS_MODULE,
.name = "ecryptfs",
.mount = ecryptfs_mount,
.kill_sb = ecryptfs_kill_block_super,
.fs_flags = 0
};

/* superblock private data. */
struct ecryptfs_sb_info {
struct super_block *wsi_sb;
struct ecryptfs_mount_crypt_stat mount_crypt_stat;
struct backing_dev_info bdi;
};

/* inode private data. */
struct ecryptfs_inode_info {
struct inode vfs_inode;
struct inode *wii_inode;
struct mutex lower_file_mutex;
atomic_t lower_file_count;
struct file *lower_file;
struct ecryptfs_crypt_stat crypt_stat;
};

/* dentry private data. Each dentry must keep track of a lower vfsmount too. */
struct ecryptfs_dentry_info {
struct path lower_path;
union {
struct ecryptfs_crypt_stat *crypt_stat;
struct rcu_head rcu;
};
};

/* file private data. */
struct ecryptfs_file_info {
struct file *wfi_file;
struct ecryptfs_crypt_stat *crypt_stat;
};

  eCryptfs支持对文件名(包括目录名)进行加密,因此特意使用了struct ecryptfs_filename的结构封装文件名,如清单二所示。

清单二 文件名的数据结构

1
2
3
4
5
6
7
8
9
10
11
struct ecryptfs_filename {
struct list_head crypt_stat_list;
u32 flags;
u32 seq_no;
char *filename;
char *encrypted_filename;
size_t filename_size;
size_t encrypted_filename_size;
char fnek_sig[ECRYPTFS_SIG_SIZE_HEX];
char dentry_name[ECRYPTFS_ENCRYPTED_DENTRY_NAME_LEN + 1];
};

  struct ecryptfs_auth_tok用于记录认证令牌信息,包括用户口令和非对称加密两种类型,每种类型都包含有密钥的签名,用户口令类型还包含有算法类型和加盐值等,如清单三所示。为了方便管理,使用时统一将其保存在struct ecryptfs_auth_tok_list_item链表中。

清单三 认证令牌信息的数据结构

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
struct ecryptfs_auth_tok {
u16 version; /* 8-bit major and 8-bit minor */
u16 token_type;
u32 flags;
struct ecryptfs_session_key session_key;
u8 reserved[32];
union {
struct ecryptfs_password password; //用户口令类型
struct ecryptfs_private_key private_key; //非对称加密类型
} token;
}

struct ecryptfs_password {
u32 password_bytes;
s32 hash_algo;
u32 hash_iterations;
u32 session_key_encryption_key_bytes;
u32 flags;
/* Iterated-hash concatenation of salt and passphrase */
u8 session_key_encryption_key[ECRYPTFS_MAX_KEY_BYTES];
u8 signature[ECRYPTFS_PASSWORD_SIG_SIZE + 1];
/* Always in expanded hex */
u8 salt[ECRYPTFS_SALT_SIZE];
};

struct ecryptfs_private_key {
u32 key_size;
u32 data_len;
u8 signature[ECRYPTFS_PASSWORD_SIG_SIZE + 1];
char pki_type[ECRYPTFS_MAX_PKI_NAME_BYTES + 1];
u8 data[];
};

  eCryptfs在mount时会传入全局加解密用到密钥、算法相关数据,并将其保存在struct ecryptfs_mount_crypt_stat,如清单四所示

清单四 mount时传入的密钥相关数据结构

1
2
3
4
5
6
7
8
9
10
11
struct ecryptfs_mount_crypt_stat {
u32 flags;
struct list_head global_auth_tok_list;
struct mutex global_auth_tok_list_mutex;
size_t global_default_cipher_key_size;
size_t global_default_fn_cipher_key_bytes;
unsigned char global_default_cipher_name[ECRYPTFS_MAX_CIPHER_NAME_SIZE + 1];
unsigned char global_default_fn_cipher_name[
ECRYPTFS_MAX_CIPHER_NAME_SIZE + 1];
char global_default_fnek_sig[ECRYPTFS_SIG_SIZE_HEX + 1];
};

  eCryptfs读写文件时首先需要进行加/解密,此时使用的密钥相关数据保存在struct ecryptfs_crypt_stat结构中,其具体数值在open时初始化,部分从mount时的ecryptfs_mount_crypt_stat复制过来,部分从分析加密文件的metadata获取,该数据结构比较关键,贯穿eCryptfs的文件open、read、write、close等流程,如清单五所示。

清单五 ecryptfs_crypt_stat数据结构

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
struct ecryptfs_crypt_stat {
u32 flags;
unsigned int file_version;
size_t iv_bytes;
size_t metadata_size;
size_t extent_size; /* Data extent size; default is 4096 */
size_t key_size;
size_t extent_shift;
unsigned int extent_mask;
struct ecryptfs_mount_crypt_stat *mount_crypt_stat;
struct crypto_ablkcipher *tfm;
struct crypto_hash *hash_tfm; /* Crypto context for generating
* the initialization vectors */
unsigned char cipher[ECRYPTFS_MAX_CIPHER_NAME_SIZE + 1];
unsigned char key[ECRYPTFS_MAX_KEY_BYTES];
unsigned char root_iv[ECRYPTFS_MAX_IV_BYTES];
struct list_head keysig_list;
struct mutex keysig_list_mutex;
struct mutex cs_tfm_mutex;
struct mutex cs_hash_tfm_mutex;
struct mutex cs_mutex;
};

eCryptfs init过程 回页首

  使用eCryptfs前,首先需要通过内核的配置选项“CONFIG_ECRYPT_FS=y”使能eCryptfs,因为加解密时使用到内核的crypto和keystore接口,所以要确保“CONFIG_CRYPTO=y”,“CONFIG_KEYS=y”,“CONFIG_ENCRYPTED_KEYS=y”,同时使能相应的加解密算法,如AES等。重新编译内核启动后会自动注册eCryptfs,其init的代码如清单六所示。

清单六 eCryptfs init过程

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
static int __init ecryptfs_init(void)
{
int rc;
//eCryptfs的extent size不能大于page size
if (ECRYPTFS_DEFAULT_EXTENT_SIZE > PAGE_CACHE_SIZE) {
rc = -EINVAL; ecryptfs_printk(KERN_ERR,…); goto out;
}
/*为上文列举到的eCryptfs重要的数据结构对象申请内存,如eCryptfs的auth token、superblock、inode、dentry、file、key 等*/
rc = ecryptfs_init_kmem_caches();

//建立sysfs接口,该接口中的version各bit分别代表eCryptfs支持的能力和属性
rc = do_sysfs_registration();

//建立kthread,为后续eCryptfs读写lower file时能借助内核函数得到rw的权限
rc = ecryptfs_init_kthread();

//在chromeos中该函数为空,直接返回0
rc = ecryptfs_init_messaging();

//初始化kernel crypto
rc = ecryptfs_init_crypto();

//注册eCryptfs文件系统
rc = register_filesystem(&ecryptfs_fs_type);

return rc;
}

eCryptfs mount过程 回页首

  在使能了eCryptfs的内核,当用户在应用层下发“mount –t ecryptfs src dst options”指令时触发执行上文清单一中的ecryptfs_mount函数进行文件系统的挂载安装并初始化auth token,成功执行后完成对src目录的eCryptfs属性的指定,eCryptfs开始正常工作,此后任何在src目录下新建的文件都会被自动加密处理,若之前该目录已有加密文件,此时会被自动解密。
  ecryptfs_mount涉及的代码比较多,篇幅有限,化繁为简,函数调用关系如图五所示。



图五 eCryptfs mount的函数调用关系图

  从图五可看到mount时首先利用函数ecryptfs_parse_options()对传入的option参数做解析,完成了如下事项:

  1. 调用函数ecryptfs_init_mount_crypt_stat()初始化用于保存auth token相关的 struct ecryptfs_mount_crypt_stat 对象;
  2. 调用函数ecryptfs_add_global_auth_tok()将从option传入的分别用于FEK和FNEK(File Name Encryption Key,用于文件名加解密)的auth token的signature保存到struct ecryptfs_mount_crypt_stat 对象;
  3. 分析option传入参数,初始化struct ecryptfs_mount_crypt_stat 对象的成员,如global_default_cipher_name、global_default_cipher_key_size、flags、global_default_fnek_sig、global_default_fn_cipher_name、global_default_fn_cipher_key_bytes等;
  4. 调用函数ecryptfs_add_new_key_tfm()针对FEK和FNEK的加密算法分别初始化相应的kernel crypto tfm接口;
  5. 调用函数ecryptfs_init_global_auth_toks()将解析option后得到key sign做为参数利用keyring的request_key接口获取上层应用传入的auth token,并将auth token添加入struct ecryptfs_mount_crypt_stat 的全局链表中,供后续使用。
      接着为eCryptfs创建superblock对象并初始化,具体如下:通过函数sget()创建eCryptfs类型的superblock;调用bdi_setup_and_register()函数为eCryptfs的ecryptfs_sb_info 对象初始化及注册数据的回写设备bdi;初始化eCryptfs superblock对象的各成员,如s_fs_info、s_bdi、s_op、s_d_op等;然后获取当前挂载点的path并判断是否已经是eCryptfs,同时对执行者的权限做出判断;再通过ecryptfs_set_superblock_lower()函数将eCryptfs的superblock和当前挂载点上底层文件系统对应的VFS superblock产生映射关系;根据传入的mount option参数及VFS映射点superblock的值初始化eCryptfs superblock对象flag成员,如关键的MS_RDONLY属性;根据VFS映射点superblock的值初始化eCryptfs superblock对象的其他成员 ,如s_maxbytes、s_blocksize、s_stack_depth;最后设置superblock对象的s_magic为ECRYPTFS_SUPER_MAGIC。这可看出eCryptfs在Linux kernel的系统架构中,其依赖于VFS并处于VFS之下层,实际文件系统之上层。
      下一步到创建eCryptfs的inode并初始化,相应工作通过函数ecryptfs_get_inode()完成,具体包括:首先获取当前挂载点对应的VFS的inode;然后调用函数iget5_locked()在挂载的fs中获取或创建一个eCryptfs的inode,并将该inode与挂载点对应的VFS的inode建立映射关系,与superblock类似,eCryptfs的inode对象的部分初始值从其映射的VFS inode中拷贝,inode operation由函数ecryptfs_inode_set()发起初始化,根据inode是符号链接还是目录文件还是普通文件分别进行不同的i_op 赋值,如ecryptfs_symlink_iops/ecryptfs_dir_iops/ecryptfs_main_iops;同时对i_fop file_operations进行赋值,如ecryptfs_dir_fops/ecryptfs_main_fops 。
      然后调用d_make_root()函数为之前创建的superblock设置eCryptfs的根目录s_root。
      最后通过ecryptfs_set_dentry_private()函数为eCryptfs设置dentry。

加密文件creat过程 回页首

  creat过程特指应用层通过creat系统调用创建一个新的加密文件的流程。以应用程序通过creat()函数在以eCryptfs挂载的目录下创建加密文件为例,其函数调用流程如图六所示,creat()通过系统调用进入VFS,后经过层层函数调用,最终调用到eCryptfs层的ecryptfs_create()函数,该部分不属于eCryptfs的重点,不详述。



图六 create经由VFS调用ecryptfs_create的流程


图七 eCryptfs创建加密文件的函数调用过程

  eCryptfs层通过ecryptfs_create() 函数完成最终的加密文件的创建,关键代码的调用流程如图七所示,以代码做为视图,分为三大步骤:一、通过ecryptfs_do_create()函数创建eCryptfs 文件的inode并初始化;二、通过函数ecryptfs_initialize_file()将新创建的文件初始化成eCryptfs加密文件的格式,添加入诸如加密算法、密钥信息等,为后续的读写操作初始化好crypto接口;三、通过d_instantiate()函数将步骤一生成的inode信息初始化相应的dentry。具体如下:
一.为新文件创建inode
  首先借助ecryptfs_dentry_to_lower()函数根据eCryptfs和底层文件系统(在chromeos里就是ext4)的映射关系获取到底层文件系统的dentry值。然后调用vfs_create()函数在底层文件系统上创建inode,紧接着利用__ecryptfs_get_inode()函数创建eCryptfs的inode 对象并初始化以及建立其与底层文件系统inode间的映射关系,之后通过fsstack_copy_attr_times()、fsstack_copy_inode_size()函数利用底层文件系统的inode对象的值初始化eCryptfs inode的相应值。
二.初始化eCryptfs新文件
  经过步骤一完成了在底层文件系统上新建了文件,现在通过函数ecryptfs_initialize_file()将该文件设置成eCryptfs加密文件的格式。

  1. ecryptfs_new_file_context()函数完成初始化文件的context,主要包括加密算法cipher、auth token、生成针对文件加密的随机密钥等,这里使用的关键数据结构是struct ecryptfs_crypt_stat,具体如清单五所示,初始化文件的context基本可以看成是初始化struct ecryptfs_crypt_stat对象,该对象的cipher、auth token、key sign等值从mount eCryptfs传入的option并保存在struct ecryptfs_mount_crypt_stat (详见清单四)对象中获取。具体是:首先由ecryptfs_set_default_crypt_stat_vals()函数完成flags、extent_size、metadata_size、cipher、key_size、file_version、mount_crypt_stat等ecryptfs_crypt_stat对象的缺省值设置;然后再通过ecryptfs_copy_mount_wide_flags_to_inode_flags()函数根据mount时设置的ecryptfs_mount_crypt_stat的flags重新设置ecryptfs_crypt_stat对象flags;接着由ecryptfs_copy_mount_wide_sigs_to_inode_sigs()函数将mount时保存的key sign赋值给ecryptfs_crypt_stat对象的keysig_list中的节点对象中的keysig;然后继续将ecryptfs_mount_crypt_stat的cipher、key_size等值赋给ecryptfs_crypt_stat对象中的相应值;再调用函数ecryptfs_generate_new_key()生成key并保存到ecryptfs_crypt_stat对象的key;最后通过ecryptfs_init_crypt_ctx()函数完成kernel crypto context的初始化,如tfm,为后续的写操作时的加密做好准备。
  2. ecryptfs_get_lower_file()通过调用底层文件系统的接口打开文件,需要注意的是ecryptfs_privileged_open(),该函数唤醒了上文清单六提到kthread,借助该内核线程,eCryptfs巧妙避开了底层文件的读写权限的限制。
  3. ecryptfs_write_metadata()完成关键的写入eCryptfs文件格式到新创建的文件中。
      关键函数ecryptfs_write_headers_virt()的代码如清单七所示,eCryptfs保存格式如清单七的注释(也可参考上文的图四),其格式传承自OpenPGP,最后在ecryptfs_generate_key_packet_set()完成EFEK的生成,并根据token_type的类型是ECRYPTFS_PASSWORD还是ECRYPTFS_PRIVATE_KEY生成不同的OpenPGP的Tag,之后保存到eCryptfs文件头部bytes 26开始的地方。这里以ECRYPTFS_PASSWORD为例,因此bytes 26地址起存放的内容是Tag3和Tag11,对应着EFEK和Key sign。否则保存的是Tag1,即EFEK。Tag3或Tag1的具体定义详见OpenPGP的描述文档RFC2440.
      之后将生成的eCryptfs文件的头部数据保存到底层文件系统中,该工作由ecryptfs_write_metadata_to_contents()完成。
  4. 最后通过ecryptfs_put_lower_file()将文件改动的所有脏数据回写入磁盘。
    三.最后通过d_instantiate()函数将步骤一生成的inode信息初始化相应的dentry,方便后续的读写操作。

    清单七 写入eCryptfs格式文件的关键函数

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    26
    27
    28
    29
    30
    31
    32
    33
    34
    35
    36
    37
    38
    39
    40
    41
    /* Format version: 1
    * Header Extent:
    * Octets 0-7: Unencrypted file size (big-endian)
    * Octets 8-15: eCryptfs special marker
    * Octets 16-19: Flags
    * Octet 16: File format version number (between 0 and 255)
    * Octets 17-18: Reserved
    * Octet 19: Bit 1 (lsb): Reserved
    * Bit 2: Encrypted?
    * Bits 3-8: Reserved
    * Octets 20-23: Header extent size (big-endian)
    * Octets 24-25: Number of header extents at front of file (big-endian)
    * Octet 26: Begin RFC 2440 authentication token packet set
    * Data Extent 0: Lower data (CBC encrypted)
    * Data Extent 1: Lower data (CBC encrypted)
    * ...
    */
    static int ecryptfs_write_headers_virt(char *page_virt, size_t max,
    size_t *size,
    struct ecryptfs_crypt_stat *crypt_stat,
    struct dentry *ecryptfs_dentry)
    {
    int rc;
    size_t written;
    size_t offset;

    offset = ECRYPTFS_FILE_SIZE_BYTES;
    write_ecryptfs_marker((page_virt + offset), &written);
    offset += written;
    ecryptfs_write_crypt_stat_flags((page_virt + offset), crypt_stat,
    &written);
    offset += written;
    ecryptfs_write_header_metadata((page_virt + offset), crypt_stat,
    &written);
    offset += written;
    rc = ecryptfs_generate_key_packet_set((page_virt + offset), crypt_stat,
    ecryptfs_dentry, &written,
    max - offset);

    return rc;
    }

加密文件open过程 回页首

  这里open过程主要指通过open系统调用打开一个已存在的加密文件的流程。当应用程序在已完成eCryptfs挂载的目录下open一个已存在的加密文件时(这里以普通文件为例),其系统调用流程如图八所示,经由层层调用后进入ecryptfs_open()函数,由其完成加密文件的metadata分析,然后取出EFEK并使用kernel crypto解密得到FEK。另外在文中”create过程”分析时,着重介绍了创建eCryptfs格式文件的过程,省略了在完成lookup_open()函数调用后的vfs_open()的分析,它与这里介绍的vfs_open()流程是一样的。需要特别指出的是在do_dentry_open函数里初始化了struct file的f_mapping成员,让其指向inode->i_mapping;而在上图五的inode的创建函数ecryptfs_inode_set中存在”inode->i_mapping->a_ops = &ecryptfs_aops”的赋值语句,这为后续的加密文件的页读写时使用的关键对象struct address_space_operations a_ops做好了初始化。
  下面重点介绍ecryptfs_open()函数,其主要的函数调用关系如图九所示。eCryptfs支持Tag3和Tag1的形式保存EFEK,这里的分析默认是采用了Tag3的方式。



图八 create经由VFS调用ecryptfs_create的流程


图九 eCryptfs创建加密文件的函数调用过程

  ecryptfs_open()函数的完成的主要功能包括读取底层文件,分析其文件头部的metadata,取出关键的EFEK及key sign,之后根据key sign从ecryptfs_mount_crypt_stat对象中匹配到相应的auth token,再调用kernel crypto解密EFEK得到FEK,最后将FEK保存到ecryptfs_crypt_stat的key成员中,完成ecryptfs_crypt_stat对象的初始化,供后续的文件加解密使用。具体如下:

  1. ecryptfs_set_file_private()巧妙的将struct ecryptfs_file_info保存到struct file的private_data中,完成VFS和eCryptfs之间的链式表达及映射;
  2. ecryptfs_get_lower_file()借助kthread 内核线程巧妙的获取到底层文件的RW权限;
  3. ecryptfs_set_file_lower()完成struct ecryptfs_file_info的wfi_file和底层文件系统文件lower_file之间的映射;
  4. read_or_initialize_metadata()完成了ecryptfs_open的大部分功能,首先通过ecryptfs_copy_mount_wide_flags_to_inode_flags()从文件对应的ecryptfs_mount_crypt_stat中拷贝flags对ecryptfs_crypt_stat的flags进行初始化;之后使用函数ecryptfs_read_lower()读取文件的头部数据,紧接着利用ecryptfs_read_headers_virt()进行数据分析和处理,包括:
    1) 利用ecryptfs_set_default_sizes()初始化ecryptfs_crypt_stat对象的extent_size、iv_bytes、metadata_size等成员的默认值;
    2) 使用ecryptfs_validate_marker()校验文件的marker标记值是否符合eCryptfs文件格式;
    3) 通过ecryptfs_process_flags()取出文件metadata保存的flag并修正ecryptfs_crypt_stat对象成员flags的值,同时初始化对象成员file_version;
    4) 在parse_header_metadata()分析文件的metadata的大小并保存到ecryptfs_crypt_stat对象成员metadata_size;
    5) 通过ecryptfs_parse_packet_set()解析Tag3和Tag11的OpenPGP格式包,获取EFEK及key sign,后根据key sign匹配到auth token,再调用kernel crypto解密EFEK得到FEK。对应的代码实现逻辑是:parse_tag_3_packet()解析Tag3,获取EFEK和cipher,同时将cipher保存到ecryptfs_crypt_stat对象成员cipher;parse_tag_11_packet()解析出key sign,保存到auth_tok_list链表中;ecryptfs_get_auth_tok_sig()从auth_tok_list链表中获取到key sign;然后通过ecryptfs_find_auth_tok_for_sig()根据key sign从ecryptfs_mount_crypt_stat对象中匹配到相应的auth token;再利用decrypt_passphrase_encrypted_session_key()使用分析得到的auth token、cipher解密出FEK,并将其保存在ecryptfs_crypt_stat的key成员;之后在ecryptfs_compute_root_iv()函数里初始化ecryptfs_crypt_stat的root_iv成员,在ecryptfs_init_crypt_ctx()函数里初始化ecryptfs_crypt_stat的kernel crypto接口tfm。至此,ecryptfs_crypt_stat对象初始化完毕,后续文件在读写操作时使用到的加解密所需的所有信息均在该对象中获取。

加密文件read过程 回页首

  read过程指应用程序通过read()函数在eCryptfs挂载的目录下读取文件的过程。因为挂载点在挂载eCryptfs之前可能已经存在文件,这些已存在的文件属于非加密文件,只有在完成eCryptfs挂载后的文件才自动保存成eCryptfs格式的加密文件,所以读取文件时需要区分文件是否属于加密文件。从应用程序发起read()操作到eCryptfs层响应的函数调用关系流程图如十所示,读取时采用page read的机制,涉及到page cache的问题,图中以首次读取文件,即文件内容还没有被读取到page cache的情况为示例。自ecryptfs_read_update_atime()起进入到eCryptfs层,由此函数完成从底层文件系统中读取出文件内容,若是加密文件则利用kernel crypto和open时初始化好的ecryptfs_crypt_stat对象完成内容的解密,之后将解密后的文件内容拷贝到上层应用程序,同时更新文件的访问时间,其中touch_atime()完成文件的访问时间的更新;generic_file_read_iter()函数调用内核函数do_generic_file_read(),完成内存页的申请,并借助mapping->a_ops->readpage()调用真正干活的主力ecryptfs_readpage()来完成解密工作,最后通过copy_page_to_iter()将解密后的文件内容拷贝到应用程序。到了关键的解密阶段,描述再多也不如代码来的直观,ecryptfs_readpage()的核心代码如清单八、九、十所示。



图十 create经由VFS调用ecryptfs_create的流程

清单八 ecryptfs_readpage()关键代码

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
static int ecryptfs_readpage(struct file *file, struct page *page)
{
struct ecryptfs_crypt_stat *crypt_stat =
&ecryptfs_inode_to_private(page->mapping->host)->crypt_stat;
int rc = 0;

if (!crypt_stat || !(crypt_stat->flags & ECRYPTFS_ENCRYPTED)) {

//读取非加密文件
rc = ecryptfs_read_lower_page_segment(page, page->index, 0,
PAGE_CACHE_SIZE,
page->mapping->host);
} else if (crypt_stat->flags & ECRYPTFS_VIEW_AS_ENCRYPTED) {

//直接读取密文给上层,此时应用程序读到的是一堆乱码
if (crypt_stat->flags & ECRYPTFS_METADATA_IN_XATTR) {
rc = ecryptfs_copy_up_encrypted_with_header(page, crypt_stat);

} else {
rc = ecryptfs_read_lower_page_segment(
page, page->index, 0, PAGE_CACHE_SIZE,
page->mapping->host);

}
} else {

//读取密文并调用kernel crypto解密
rc = ecryptfs_decrypt_page(page);

}

return rc;
}

清单九 ecryptfs_decrypt_page()核心代码

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
int ecryptfs_decrypt_page(struct page *page)
{

ecryptfs_inode = page->mapping->host;

//获取包含有FEK、cipher、crypto context tfm信息的ecryptfs_crypt_stat
crypt_stat = &(ecryptfs_inode_to_private(ecryptfs_inode)->crypt_stat);

//计算加密文件内容在底层文件中的偏移
lower_offset = lower_offset_for_page(crypt_stat, page);
page_virt = kmap(page);

//利用底层文件系统的接口读取出加密文件的内容
rc = ecryptfs_read_lower(page_virt, lower_offset, PAGE_CACHE_SIZE, ecryptfs_inode);
kunmap(page);

for (extent_offset = 0;
extent_offset < (PAGE_CACHE_SIZE / crypt_stat->extent_size);
extent_offset++) {

//解密文件内容
rc = crypt_extent(crypt_stat, page, page,
extent_offset, DECRYPT);

}

}

清单十 crypt_extent()核心加解密函数的关键代码

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
static int crypt_extent(struct ecryptfs_crypt_stat *crypt_stat,
struct page *dst_page,
struct page *src_page,
unsigned long extent_offset, int op)
{
//op 指示时利用该函数进行加密还是解密功能
pgoff_t page_index = op == ENCRYPT ? src_page->index : dst_page->index;
loff_t extent_base;
char extent_iv[ECRYPTFS_MAX_IV_BYTES];
struct scatterlist src_sg, dst_sg;
size_t extent_size = crypt_stat->extent_size;
int rc;

extent_base = (((loff_t)page_index) * (PAGE_CACHE_SIZE / extent_size));
rc = ecryptfs_derive_iv(extent_iv, crypt_stat,
(extent_base + extent_offset));

sg_init_table(&src_sg, 1);
sg_init_table(&dst_sg, 1);

sg_set_page(&src_sg, src_page, extent_size,
extent_offset * extent_size);
sg_set_page(&dst_sg, dst_page, extent_size,
extent_offset * extent_size);

//调用kernel crypto API进行加解密
rc = crypt_scatterlist(crypt_stat, &dst_sg, &src_sg, extent_size, extent_iv, op);

return rc;
}

  理顺了mount、open的流程,知道FEK、cipher、kernel crypto context的值及存放位置,同时了解了加密文件的格式,解密的过程显得比较简单,感兴趣的同学可以继续查看crypt_scatterlist()的代码,该函数纯粹是调用kernel crypto API进行加解密的过程,跟eCryptfs已经没有关系。

加密文件write过程 回页首

  eCryptfs 文件write的流程跟read类似,在写入lower file前先通过ecryptfs_writepage()函数进行文件内容的加密,这里不再详述。

ChromeOS使用eCryptfs的方法及流程 回页首

  Chromeos在保护用户数据隐私方面可谓不遗余力,首先在系统分区上专门开辟出专用于存储用户数据的stateful partition,当用户进行正常和开发者模式切换时,该分区的数据将会被自动擦除;其次该stateful partition的绝大部分数据采用dm-crypt进行加密,在系统启动时用户登录前由mount-encrypted完成解密到/mnt/stateful_partition/encrypted,另外完成以下几个mount工作:将/Chromeos/mnt/stateful_partition/home bind mount 到/home;将/mnt/stateful_partition/encrypted/var bind mount到/var目录;将/mnt/stateful_partition/encrypted/chromos bind mount 到/home/chronos。最后在用户登录时发起对该用户私有数据的eCryptfs加解密的流程,具体工作由cryptohomed守护进程负责完成,eCryptfs加密文件存放在/home/.shadow/[salted_hash_of_username]/vault目录下,感兴趣的读者可通过ecryptfs-stat命令查看其文件状态和格式,mount点在/home/.shadow/[salted_hash_of_username]/mount,之后对/home/.shadow/[salted_hash_of_username]/mount下的user和root建立bind mount点,方便用户使用,如将/home/.shadow/[salted_hash_of_username]/mount/user bind mount到/home/user/[salted_hash_of_username]和/home/chronos/u-[salted_hash_of_username] ;将/home/.shadow/[salted_hash_of_username]/mount/root bind mount到/home/root/[salted_hash_of_username]。用户在存取数据时一般是对目录/home/chronos/u-[salted_hash_of_username]进行操作。
  eCryptfs在Chromeos中的应用架构如图十所示。系统启动后开启cryptohomed的守护进程,由该进程来响应eCryptfs的挂载和卸载等,进程间采用D-Bus的方式进行通信,cryptohome应用程序主用于封装用户的动作命令,后通过D-Bus向cryptohomed发起请求。如可通过cryptohome命令”cryptohome -–action=mount -–user=[account_id]”来发起eCryptfs的挂载;通过命令”cryptohome -–action=unmount”卸载eCryptfs的挂载,执行成功此命令后,用户的所有个人数据将无法访问,如用户先前下载的文件内容不可见、安装的应用程序不可使用,/home/.shadow/[salted_hash_of_username]/mount内容为空。



图十一 eCryptfs在Chromeos中的架构图

  cryptohomed特色的mount流程如下:

  1. cryptohomed在D-Bus上接收到持(包含用户名和密码)有效用户证书的mount请求,当然D-Bus请求也是有权限控制的;
  2. 假如是用户首次登陆,将进行:
    a. 建立/home/.shadow/[salted_hash_of_username]目录,采用SHA1算法和系统的salt对用户名进行加密,生成salted_hash_of_username,简称s_h_o_u;
    b. 生成vault keyset /home/.shadow/[salted_hash_of_username]/master.0和/home/.shadow/[salted_hash_of_username]/master.0.sum。 master.0加密存储了包含有FEK和FNEK的内容以及非敏感信息如salt、password rounds等;master.0.sum是对master.0文件内容的校验和。
  3. 采用通过mount请求传入的用户证书解密keyset。当TPM可用时优先采用TPM解密,否则采用Scrypt库,当TPM可用后再自动切换回使用TPM。cryptohome使用TPM仅仅是为了存储密钥,由TPM封存的密钥仅能被TPM自身使用,这可用缓解密钥被暴力破解,增强保护用户隐私数据的安全。TPM的首次初始化由cryptohomed完成。这里默认TPM可正常使用,其解密机制如下图十二所示,其中:
    UP:User Passkey,用户登录口令
    EVKK:Ecrypted vault keyset key,保存在master.0中的”tpm_key”字段
    IEVKK:Intermediate vault keyset key,解密过程生成的中间文件,属于EVKK的解密后产物,也是RSA解密的输入密文
    TPM_CHK: TPM-wrapped system-wide Cryptohome key,保存在/home/.shadow/cryptohome.key,TPM init时加载到TPM
    VKK:Vault keyset key
    VK:Vault Keyset,包含FEK和FNEK
    EVK:Encrypted vault keyset,保存在master.0里”wrapped_keyset”字段
    图十二中的UP(由发起mount的D-Bus请求中通过key参数传入)做为一个AES key用于解密EVKK,解密后得到的IEVKK;然后将IEVKK做为RSA的密文送入TPM,使用TPM_CHK做为密钥进行解密,解密后得到VKK;最后生成的VKK是一个AES key,用于解密master.0里的EVK,得到包含有FEK和FNEK明文的VK。经过三层解密,终于拿到关键的FEK,那么问题来了,Chromeos的FEK的保存及解密流程与上文介绍的eCryptfs时不一致,FEK不应该是open时从加密文件的头部metadata里的EFEK中解密出来的么?不过一次解密出FEK,全局使用,效率的确比每次读取文件时解析FEK高很多,之后通过key的系统调用将key传入内核的keyring,使用时通过key sign匹配。最后跟上文所述实属异曲同工。
  4. 通过mount系统调用传入option完成挂载。
    该部分与正常的Linux做法一致,在mount的option里传入关键的cipher、key sign、key bytes等信息。


图十二 TPM解密VK的流程

结语 回页首

  ecryptfs建立在系统安全可信的基础上,保护用户数据的安全,核心基础组件是加密密钥,若在内核被攻破后密钥被通过某些手段窃取,ecryptfs的安全性将同样被攻破。另外page cache中加密文件的明文页有可能被交换到swap区,在chromeos中已经禁用了swap,因此不会产生影响,但是其他版本的Linux系统需要注意该问题。
  eCryptfs首次实现到现在已经十年有余,直到近几年才在chromeos和Ubuntu上使用,个人认为除了之前人们的安全意识不如现在强烈外,更重要的是随着处理器性能的增强,eCryptfs加解密引起的文件读写性能下降的问题已经得到缓解。但实际的性能损耗如何,有待继续研究。或许出于性能的原因,年初的时候Google在chromeos实现了基于ext4 crypto的 dircrypto,用于实现跟eCryptfs同样的功能,目前chromeos同时支持eCryptfs和dircrypto,但在60版本后优先采用dircrypto技术,相关技术在另外的文章中进行介绍。
  最后,文中必有未及细看而自以为是的东西,望大家能够去伪存真,更求不吝赐教。

参考资料 回页首

  1. 企业级加密文件系统 eCryptfs 详解
  2. eCryptfs: a Stacked Cryptographic Filesystem
  3. Linux kernel-V4.4.79 sourcecode
  4. chromiumos platform-9653 sourcecode