I. Overview
Encryption is the most common data security protection technology, which is applied in all stages of the data life cycle. In terms of application scenarios and technical implementation, there are various classifications and corresponding solutions according to the dimensions of encrypted objects, whether users perceive them, and encryption algorithms, and are widely used in mainstream operating systems such as Windows, Linux, and Android.
This article is the second part of the Linux kernel security technology series, which mainly introduces disk encryption technology and mainstream implementation solutions. Firstly, it introduces the background of disk encryption technology, including application scenarios, threat models, technical route classification, etc.; secondly, it introduces two implementation schemes of disk encryption, namely, full disk encryption FDE and file system encryption FBE, focusing on Linux system and kernel mainstream FBE implementation schemes; Finally, take eCryptfs as an example to analyze its principle and application in detail.
Linux Kernel Security Technology Series Part 1: Linux Kernel Security Technology - Review of Open Source Evolution
1.1. Description
There are many information security risks of data at each stage of its life cycle, such as counterfeiting, tampering, leakage, unauthorized access, DoS denial of access, etc. Some mature solutions can usually solve and reduce multiple risks. This article mainly introduces disk encryption technology, mainly focusing on data leakage and confidentiality dimensions, and other dimensions of risk and protection are not covered too much.
1.2. Abbreviations and terms
Abbreviations and terminology used in this document are explained below:
2. Technical background introduction
2.1. Threat Model
Data Lifecycle Management (Data Lifecycle Management) usually divides data into several stages of production, storage, use, sharing, destruction, and archiving. From the perspective of information security protection, data is generally divided into three states, namely: Data in Use, Data in Motion/Transit, and Data at Rest.
Data in Motion/Transit, that is, the data transmission scenario, is the most familiar security scenario with the most mature technology development. For example, Https application based on SSL/TLS protocol, SCP/SFTP application based on SSH protocol, etc. The security protection of data by these technologies includes not only encrypted transmission, but also two-way identity authentication and integrity protection.
Data in Use, that is, data usage scenarios. At this time, the data is cached in the system DRAM, Cache, and CPU Register, and generally exists in plain text. However, in some high-security scenarios, in order to prevent side-channel attacks (such as Cold Boot Attack to obtain key information in DRAM), the industry has also proposed the Full Memory Encryption full memory encryption technology. Such as Intel's TME (Total Memory Encryption), AMD's SME (Secure Memory Encryption), etc. When FME is enabled, all system DRAM data is encrypted and stored. The CPU performs decryption and encryption operations when reading and writing data through a specific hardware encryption and decryption engine. The encryption and decryption key is generally uniquely generated each time it is booted.
Data at Rest, that is, data (persistent) storage scenarios. At this time, the data belongs to the inactive state and is not used, and is stored in non-volatile media such as disks. Security risks mainly include unauthorized access, data leakage due to equipment loss, etc. Common protection methods include isolation and access control at the physical/network level, and data (disk) encryption. For encrypted storage disk data, even if the device (such as PC/mobile phone) is lost and the attacker removes the hard disk or Flash device, he can only read the ciphertext in the device to ensure the confidentiality of key data.
2.2. Technical route
Encryption is an effective means to prevent data leakage and ensure confidentiality. According to different dimensions, encryption technologies/schemes can be classified into various categories, which are briefly summarized as follows:
It should be noted that several dimensions are not mutually exclusive, and a solution usually conforms to/adopts multiple features/technologies. For example, Disk Encryption, the disk encryption technology to be introduced in this article, generally encrypts the entire disk or file system, but it belongs to the Data at Res Encryption technology from the perspective of data state, it belongs to transparent encryption technology from the perspective of user perception, and it belongs to transparent encryption technology from the dimension of encryption algorithm. Symmetric encryption is used.
The following briefly introduces the technical concepts/terms involved in several classifications. For details, please refer to the reference link at the end of the article and the detailed analysis in subsequent chapters.
Data at Rest Encryption
The technology of keeping data encrypted in the at Rest state, refer to https://wiki.archlinux.org/title/Data-at-rest_encryption description, the encrypted objects are generally disks (block devices), file system directories, and the encryption and decryption process is transparent Encryption Technology.
Transparent Encryption
Transparent encryption, also known as real-time encryption or on-the-fly encryption. The feature is that the data is automatically encrypted and decrypted during use without user intervention.
3. Disk encryption technology
As mentioned in the previous section, the goal of Disk Encryption is to protect the confidentiality of data at Rest. The object of encryption is the entire disk/partition or file system, using real-time encryption and decryption technology. For more introduction, please refer to https://en.wikipedia.org/wiki/Disk_encryption.
Disk encryption technology can also be classified into various categories from the dimensions of encrypted objects, software and hardware implementation, and file system characteristics. First, depending on whether the encryption object is the entire disk or the file system, it can be divided into two categories: Full-Disk Encryption and Filesystem-Level Encryption (also known as File-Based Encryption).
3.1、FDE
Full-Disk Encryption can be implemented in two ways: hardware and software. The core principles of the two are similar. The difference is that the main body of the encryption and decryption functions is software or hardware. In addition, the software solution generally cannot really encrypt the entire hard disk (the boot partition is not encrypted), while the hardware solution Hardware-based Full-Disk Encryption has the entire hard disk encryption. ability. The hardware FDE solution products are mainly Self Encryption Drive self-encrypting hard disks, which are generally provided by storage device manufacturers and security manufacturers. For the hardware FDE solution and SED product technology, please refer to the Hardware-based Full Disk Encryption and SED related links at the end of the article.
The core principles and processes of the hardware and software FDE solutions are similar, and the unified abstract description is as follows:
When initializing or creating FDE, a disk data encryption DEK (Disk Encryption Key, which the user does not perceive) will be randomly generated, and the user is required to enter an AK (Authentication Key) to encrypt and protect the DEK. When in use, the user needs to enter the AK to verify and decrypt the DEK, and then the operating system can use the DEK to access the data on the encrypted disk. The figure below is a description of a software FDE.
Since a specific program needs to be executed to display the UI to provide the user to input and verify the AK, this part of the startup code cannot be encrypted. Therefore, the concepts of Pre-Boot Authentication and PBA environment are introduced.
In terms of PBA implementation, the hardware FDE solution (SED product) is generally embedded with a Pre-Boot environment (small OS or bootloader) when it leaves the factory. After power-on, the Pre-Boot program is run first and the AK is verified, and then the normal loading and booting is performed.
The software FDE solution adopts the method of not encrypting the boot partition, and generally integrates the PBA function in the initial ramdisk and completes the verification.
Software FDE solutions have a long history of development, and mainstream OS environments have mature solutions, such as BitLocker under Windows, FileVault under Apple OS/X, and dm-crypt/LUKS under Linux/UNIX ecology. In addition, there are three-party FDE solutions that do not depend on the operating system, such as TrueCrypt, VeraCrypt, etc. For more software FDE solutions, please refer to the link https://en.wikipedia.org/wiki/Comparison_of_disk_encryption_software and the figure below.
Students who are interested in the dm-crypt/LUKS solution under Linux can test and research on the Ubuntu virtual machine. The following are screenshots of several key scenarios: enabling disk encryption configuration during Ubuntu virtual machine installation, PBA verification during startup, and the encrypted disk type of the system's main partition sda5 (you can see that the boot partition sda1 is not encrypted).
3.2、FBE
File-Based Encryption, also known as Filesystem-Level Encryption, file system encryption. Compared with FBE, the second name can better reflect the technical characteristics of the solution based on the file system. Based on the characteristics of the file system, on the one hand, it is determined that it can only be realized by software, and on the other hand, the differences between the various solutions are mainly related to the file system.
Common FBE solutions are generally divided into Stackable cryptographic filesystem and Native/General filesystem with encryption.
The first is to add an encryption and decryption file system, which is stacked on a certain layer of the existing storage software stack. For example, the Linux kernel has been supported since v2.6.19. The mature and stable eCryptfs solution is to add new encryption and decryption file system support between the VFS -> Native FS layer. There are also various schemes based on the user-mode file system FUSE.
The second is to introduce encryption and decryption functions into the existing file system. For example, the Linux kernel supports Ext4 file system encryption since v4.1, F2FS file system encryption since v4.2, and UBIFS file system encryption since v4.10. It should be noted that Ext4, F2FS, and ubifs in the kernel share the encryption and decryption function module, that is, the kernel fscrypt feature. In addition, the FBE scheme introduced by the Android system, the underlying kernel implementation is also based on F2FS+fscrypt.
Two types and more FBE implementations in the industry, please refer to the link https://en.wikipedia.org/wiki/List_of_cryptographic_file_systems and the following figure:
Compared with the FDE scheme, FBE has several notable features:
1. Support separate directory or file encryption, which is convenient and flexible to use and configure. Only the target object is encrypted, and the entire disk is not encrypted, which reduces the system encryption and decryption load overhead.
2. Support different directories/files to use different encryption keys.
3. Encrypted directory and non-encrypted directory coexist (even encrypted and non-encrypted files can coexist in an encrypted directory). The backup transmission of encrypted directory files is flexible and convenient.
For more detailed comparisons between FDE and FBE, and the specific implementation of FBE in Linux, please refer to the subsequent chapters.
3.2、FDE vs FBE
It has been known from the previous analysis that the software FDE and FBE are both based on the file system, and the difference is mainly in the implementation of the file system. The comparison is as follows:
[Description] Software FDE/FBE mainly means that the main body of its encryption and decryption functions is implemented in software (file system), which does not mean that hardware is not used. On the contrary, in order to improve performance, hardware engines such as Crypto Engine will also be used to accelerate.
From the analysis of the software and hardware architecture of the entire system, the relationship between hardware FDE, software FDE, FBE implementation and system software and hardware architecture can be described as follows:
In the figure above, for the disk encryption scheme, the higher the upper layer is, the more flexible the user configuration is, but the performance is poor; the lower the layer is, the less flexible the implementation is, but the more transparent it is to the user and the better the performance. Combined with the previous description, the differences between the FDE and FBE schemes are compared and sorted out as follows:
3.3, Linux system FBE
From the perspective of Linux system software architecture, typical FDE and FBE implementation solutions are distributed as shown in the figure below, including software FDE solutions based on dm-crypt, fscrypt FBE solutions based on general file systems, eCryptfs FBE solutions based on VFS, and many FBE solutions based on FUSE .
The previous chapters have briefly introduced the verification of the dm-crypt-based FDE scheme on the ubuntu virtual machine. Here, we briefly introduce several software FBE implementation schemes and characteristics of the Linux system and kernel. The following chapters will take eCryptfs as an example for detailed analysis. .
FUSE-Based
FUSE is Filesystem in Userspace, the user mode file system. The original intention of FUSE design is to facilitate users to implement a custom file system in user space without modifying the compiled kernel. The principle and implementation of the FUSE architecture are shown in the figure below. Kernel-mode FUSE and user-mode libfuse serve the App –> VFS -> User File System link, and the user-customized implementation is mainly in the User-Level Filesystem part.
Due to the natural flexibility, there are many solutions to implement FBE based on FUSE, such as gocryptfs, EncFS, CryFS, securefs, etc. However, the overhead of multiple system calls and copies introduced by FUSE also leads to poor performance of FBE solutions based on FUSE. The gocryptfs project has a comparative analysis of stackable FBE schemes (link https://nuetzlich.net/gocryptfs/comparison/), the analysis data also verified the advantages and disadvantages of the FUSE FBE scheme.
The first is the introduction and overall characteristics of various stackable FBE solutions. In terms of quantity, FUSE FBE solutions account for the vast majority, and non-FUSE solutions only include eCryptfs.
Secondly, compared with eCryptfs, the FUSE solution is at a disadvantage overall in terms of performance. Although gocryptfs performs well in sequential read and write, it has obvious disadvantages in other tests such as decompression, MD5 calculation, and directory recursive access/deletion. This is consistent with our comparison of FDE and FBE in Chapter 3.2, and the analysis of the difference in the effect of disk encryption at different levels of the software stack.
For more information about the features of each FUSE FBE solution, such as file content encryption, file name encryption, etc., please refer to the above comparison link or the homepage of each solution, and will not introduce them in detail here.
eCryptfs
eCryptfs is derived from the Cryptfs project, and the early schemes and design ideas come from two papers in 2005 and 2007, namely "eCryptfs: an enterprise-class cryptographic filesystem for Linux" and "eCryptfs: a Stacked Cryptographic Filesystem". The eCryptfs project is divided into the kernel part and the user mode part. The kernel mode code was merged into the community mainline in version v2.6.19, and the user mode code is maintained in the software package ecryptfs-utils.
Like the FUSE solution introduced above, eCryptfs also belongs to the stackable FBE type, so it does not depend on the underlying file system type of the OS, and can be stacked on various file systems with great flexibility. It also supports encryption of different files and directories, as well as file name encryption.
The current eCryptfs project open source community is not very active, and early users/products are also migrating, but its scheme and design principles are still worthy of in-depth study and analysis. For detailed test verification and principle analysis, please refer to Chapter 4.
fscrypt
fscrypt is a native FBE solution implemented on the kernel file system. The fscrypt feature also includes kernel state and user state. The kernel state part is a public encryption and decryption module implemented in the fs/crypto directory, which supports the integrated use of ext4, F2FS, and UBIFS file systems. The user mode tool fscrypt implements various command line tools for user convenience.
As an FBE solution, fscrypt supports different keys for different directories/files. For metadata, fscrypt supports filename encryption, and other metadata such as timestamp, size, and attribute are not encrypted. The biggest application of fscrypt is the FBE solution adopted by Android, combined with the F2FS file system, to protect the data on the mobile phone with data at rest encryption. This article is limited by space, so no detailed analysis is done.
4. Detailed eCryptfs
In this chapter, we first use a simple use case to verify the characteristics of eCryptfs encryption effect, so that everyone can have an overall perceptual understanding of the solution, and also provide a C version use case for reference. Secondly, conduct a preliminary analysis of the test results, then analyze the architecture principle and core mechanism of the eCryptfs solution in detail, and finally briefly sort out the key business process codes.
The test environment uses the Ubuntu 20.04 virtual machine. Because the Ubuntu system opens the eCryptfs kernel configuration (CONFIG_ECRYPT_FS=y) by default, you only need to apt install the user mode tool ecryptfs-utils.
4.1. Test cases
The figure below is a script based test case. First create the test directory and the file hello, and then use the mount -t ecryptfs method to encrypt the test directory. To avoid command line interaction, pass all encryption parameters (passwd, cipher, key size, etc.) through the command line -o. Create a new file hello_encrypted in the test directory after encryption. Finally, umount cancels the directory encryption.
The phenomena/features that can be observed from the first test case are:
1. Execute mount, after writing the contents of the hello_encrypted file, it can be accessed correctly, but after umount, it will be ciphertext. Explain that eCryptfs, as a stacked encrypted file system, is enabled through mount/unmount operations. When the function is turned on, the user cannot perceive the data encryption and decryption process during read and write operations, that is, transparent encryption.
2. The content of the hello file is written before the mount, and can be accessed correctly before and after the mount (the use case only tests the read operation, and the actual write is also possible). Explain that eCryptfs supports mixed storage of non-encrypted files and encrypted files in a directory, and can be accessed correctly (actual operation is strongly not recommended, see the next use case).
3. For the encrypted file hello_encrypted, the length is 16 Bytes in the plaintext state and 12KB in the encrypted state. The change is obvious.
If you slightly modify the above test cases, adjust the mount -t ecryptfs parameters, such as changing passwd, cancel the no_sig_cache=y configuration, and enable the file name encryption parameter, that is, ecryptfs_enable_filename_crypto=y, the test results are as follows:
The phenomena/features that can be observed from the second modified use case are:
4. ecryptfs supports file name encryption. Because the file name encryption key FNEK is not specified in the parameter, mount helper will prompt/default to use the file content encryption key (that is, fnek_sig and fs_sig in the figure are the same, it should be noted that the encryption key is not passwd in the parameter, and the subsequent architecture and The key management chapter will explain).
5. Although the ecryptfs_passthrough feature is still enabled, which allows encrypted and non-encrypted files to coexist, the effect is different from the previous use case. After the file name is encrypted and mounted, the unencrypted file hello cannot be displayed in the test, and it can be accessed normally after umount. The passthrough feature behaves differently under different parameters in the two use cases, so in practical applications, it is strongly not recommended to store encrypted and non-encrypted files in the same directory.
Add another phenomenon/feature:
6. After umount, the encrypted test directory can be directly transferred/copied to other hosts/networks for storage and backup. When other users use it, they only need to remount with the same parameters to access it correctly.
The relevant parameters of the mount -t ecryptfs command in the use case are summarized as follows. For details, refer to the man ecryptfs manual and the source code of ecryptfs-utils. Some parameters and meanings will be further explained in the architecture analysis and key management chapters.
It should be noted that the functions of the above script use cases can basically be realized by using the interface API provided by ecryptfs-utils. The following is a partial code reference of a C use case implemented by the author. Because the C program needs to refer to the ecryptfs.h header file and use related API functions, it is necessary to install the libecryptfs-dev software package, and specify -lecryptfs to link the corresponding library file when compiling.
In the C use case, it should be noted that ecryptfs_add_passphrase_key_to_keyring must be performed before the mount operation, that is, the passphrase is converted into the corresponding key (actually FEKEK, see subsequent analysis), and registered to the kernel keyring, and a key_sig is returned to the user for subsequent use.
4.2. Result Analysis
From the test results in the previous section, the relevant test items and eCryptfs effect characteristics are summarized in the following table. There are two points that need to be explained:
One is the effect of repeatedly mounting the test directory and using a different key each time. From the use case in the figure below, the files generated after the corresponding passwd mount can only be accessed correctly in the mount context. This use case is just a simple illustration. In the case of parameter changes, such as file name encryption, the situation may be more complicated and uncertain, so it is not recommended.
The second is the problem of file size change after encryption. The reason for this lies in the design of the eCryptfs solution itself. The figure below shows the mapping relationship between eCryptfs plaintext and ciphertext and the description in the paper, which are from the 2006 design document "eCryptfs v0.1 Design Document" and the 2007 paper "eCryptfs: a Stacked Cryptographic Filesystem". It can be seen that the encrypted file format will add an additional header information (reserve a page). For file content, it is encrypted by page and block. For comprehensive performance considerations, the file size is page-aligned, with a minimum of 12KB.
From the perspective of scheme design and file format, encryption is a bit expensive for small files, and the larger the file, the smaller the impact. The figure below shows the test comparison results with 4M, 40M, and 400M files respectively. Regardless of the size of the source file, the size of the encrypted file increases by 8KB.
4.3. Overall structure
The overall architecture of eCryptfs is shown in the figure below, mainly including the kernel module eCryptfs and the user mode process ecryptfsd. The ecryptfsd process is only required when the key type is openssl mode, not when the passphrase mode (such as the above test case) is used. ecryptfs-utils can be used as a user-mode auxiliary tool or a C interface programming reference.
When an application program initiates a system call, it first passes through the VFS, and calls the registration function of the eCryptfs module when it determines that the directory type is eCryptfs. After that, eCryptfs finds the corresponding key (FEKEK) from the keyring according to the key signature parameter saved in the mount session, and then calls the crypto module API to complete file encryption and decryption.
The core encryption and decryption mechanism of eCryptfs is shown in the figure below, and the main features are summarized as follows:
1. FEK (File Encryption Key) is unique, that is, the encryption key of each file is different, and it is a random number generated when the file is created.
2. The FEK of each file is encrypted and protected by FEKEK (File Encryption Key Encryption Key). After encryption, the FEK is called EFEK (Encrypted File Encryption Key), and is stored in the header information of the eCryptfs encrypted file (such as the aforementioned page 0 area).
3. In the passphrase mode, FEKEK is derived based on the user passphrase_passwd, and the derivation method is hash calculation (refer to the code analysis section).
4. The file content is encrypted in blocks according to the page size (Data Extent).
The core process can be simply described as:
1. When a new file is encrypted, a random number FEK is generated, and the file content is encrypted and stored in blocks. Find the corresponding FEKEK from the keyring according to the key_sig parameter passed by the user, encrypt the FEK with FEKEK, generate an EFEK and save it in the file header.
2. When decrypting, use key_sig to find FEKEK, use FEKEK to decrypt EFEK to get FEK, and then use FEK to decrypt the file content.
4.4. Key management
From the previous section, we learned that there are mainly two KEYs in the core mechanism of eCryptfs, namely FEKEK and FEK. The former is related to the user input passphrase_passwd, and the latter is a unique random number for each file. The following combines the source code of ecryptfs-utils to introduce the generation process of these two KEYs.
1. Conversion from user passphrase_passwd to FEKEK
It can be seen from the C test case that the opt parameter only has key_sig information, and does not specify FEKEK. And the premise of the mount operation is that the corresponding key (FEKEK) has been added to the kernel keyring. The script command is actually the mount helper assisting (implicitly) to complete the operation of adding the keyring.
The core function is ecryptfs_add_passphrase_key_to_key_ring called in the C use case. The calling relationship of this function is as follows:
First, ecryptfs_generate_passphrase_auth_tok will perform hash calculation in the generate_passphrase_sig function according to the passphrases information and salt information entered by the user (specified by parameters, ecryptfs-utils has a default value of ECRYPTFS_DEFAULT_SALT as shown in the figure below), and record the result in the variable fekek, and then perform a hash calculation on fekek A hash calculation, the result is recorded as passphrase_sig/auth_token_sig, and returned to the user for subsequent use (key_sig).
generate_payload creates an auth_tok structure for each session to record more information about encryption and decryption.
Finally, call ecryptfs_add_auth_tok_to_keyring to add the corresponding FEKEK, key_sig, salt and other information to the keyring. So far, the conversion from passphrase_passwd to FEKEK and the addition of kernel keyring have been completed.
2. The generation process of FEK
FEK is used as the encryption key of the file content, which is a unique random number for each file. The timing of generation is in the stage of the create system call, specifically in the kernel functions ecryptfs_new_file_context and ecryptfs_generate_new_key, see the code below.
4.5, code analysis
This section simply sorts out and lists the code calling relationship of the core process of the eCryptfs solution, for readers' reference and comparative reading, without detailed analysis.
1. The key function call of the Mount process.
It can be seen from the mount_crypt_stat key structure and the tokens structure that mount opt only accepts key signature information.
2. The key function call of the Create process.
A new file is created during the create process. At this time, the encryption parameter information of each file is stored in the ecryptfs_crypt_stat structure.
3. The key function call of the open process.
4. The key function call of the read & write process.
V. Summary
This paper first introduces the background of disk encryption technology, including threat model, technical route and characteristics, and then introduces FDE and FBE two disk encryption schemes according to the difference of encrypted objects, including software and hardware implementation, file system implementation differences, etc., and makes a Comparative analysis. Finally, it mainly introduces the typical FBE scheme and characteristics in Linux system, and takes eCryptfs as an example for detailed analysis.
Hope to help readers have a better understanding of the concept of disk encryption technology, the difference between FDE and FBE, the characteristics of FBE solutions in the industry, and the key technologies of FBE implementation. Due to limited space, many technical details and solutions cannot be further developed, such as fscrypt. I hope that in the follow-up articles, we can further share fscrypt in combination with Android FBE.
References:
Data in use https://en.wikipedia.org/wiki/Data_in_use
Data in transit https://en.wikipedia.org/wiki/Data_in_transit
Data at rest https://en.wikipedia.org/wiki/Data_at_rest
Data at rest encryption https://wiki.archlinux.org/title/Data-at-rest_encryption
Disk Encryption https://en.wikipedia.org/wiki/Disk_encryption
Full Disk Encryption https://en.wikipedia.org/wiki/Disk_encryption#Full_disk_encryption
Pre-boot Authentication https://en.wikipedia.org/wiki/Pre-boot_authentication
What is full disk encryption https://specopssoft.com/blog/what-is-full-disk-encryption/
Hardware-based full disk encryption https://en.wikipedia.org/wiki/Hardware-based_full_disk_encryption
Self Encryption Drives https://wiki.archlinux.org/title/Self-encrypting_drives
Disk Encryption Software https://en.wikipedia.org/wiki/Disk_encryption_software
Comparison of disk encryption software https://en.wikipedia.org/wiki/Comparison_of_disk_encryption_software
Filesystem-level encryption https://en.wikipedia.org/wiki/Filesystem-level_encryption
List of cryptographic filesystems https://en.wikipedia.org/wiki/List_of_cryptographic_file_systems
Filesystem in Userspace，FUSE https://en.wikipedia.org/wiki/Filesystem_in_Userspace
Comparison of FUSE-Based FBE https://nuetzlich.net/gocryptfs/comparison/
fscrypt kernel documentation https://docs.kernel.org/filesystems/fscrypt.html
eCryptfs documentation https://www.ecryptfs.org/documentation
eCryptfs Linux Manual Page https://linux.die.net/man/7/ecryptfs
2005.07 eCryptfs: an enterprise-class cryptographic filesystem for Linux https://web.archive.org/web/20080916022422/http://www.linuxsymposium.org/2005/linuxsymposium_procv1.pdf
2006.03 eCryptfs v0.1 Design Document http://www.dubeyko.com/development/FileSystems/eCryptfs/ecryptfs_design_doc_v0_1.pdf
2007.05 eCryptfs: a Stacked Cryptographic Filesystem http://www.dubeyko.com/development/FileSystems/eCryptfs/ecryptfs-article.pdf
2016.01 Review of Dynamic Encryption Technology, Liang Jinqian http://blog.nsfocus.net/dynamic-encryption-technology-review/
2017.09 File-system and Block-layer Encryption: Theory, Practice, and Improvement https://www.snia.org/educational-library/file-system-and-block-layer-encryption-theory-practice-and-improvement-2017
Long press to follow Kernel Craftsman WeChat
Linux Kernel Black Technology | Technical Articles | Featured Tutorials