ScramFS encryption deep dive.
Featuring transparent data encryption for files in use and at rest, with quantum resistant cryptography, comprehensive security analysis and multiple peer reviews.
ScramFS brings world-class cryptography into everyday use, providing security for both local and cloud- based storage file systems.
Using the most up-to-date primitives, it offers long term, post-quantum security for files and data in use and at rest.
Most importantly, ScramFS was designed and peer reviewed by noted leading cryptographers from around the world, and comes with a comprehensive security analysis.
Cryptographic file system architecture
The following sections describe the encryption design and security properties of ScramFS. It is an implicit assumption that, as with any cryptosystem, security is assured when the encryption key is kept secret.
Stackable encryption for both cloud and local storage
The stackable design of ScramFS allows it to encrypt data on a wide variety of underlying storage file systems – whether data is stored locally or in the cloud.
ScramFS has been carefully designed to support a wide variety of local storage (NTFS, ext4, HFS, and many others) and cloud storage (Google Drive, DropBox, OneDrive, WebDAV).
1:1 mapping between plaintext and ciphertext files
ScramFS provides transparent encryption for files. The only difference that a user will notice is that all data written to storage is encrypted.
There is a 1:1 correspondence between the plaintext view of files presented to the user or application, and the ciphertext files written to storage. Due to the regular space overheads involved in cryptography (for storing authentication tags and initialization vectors), there is a small increase in size of the ciphertext file, as explained below.
Encryption for file contents and file names
A basic requirement for confidentiality and integrity is to encrypt all file contents and file names. ScramFS not only meets this requirement, but exceeds it, additionally ensuring that all ciphertext file names and content are indistinguishable from random.
Surprisingly, not all cryptographic filesystems provide file name encryption.
|ScramFS||Microsoft NTFS EFS Built into Windows||eCryptFS
Built into Linux
|Encrypted file contents|
|Entire file content is indistinguishable from random|
|Encrypted file names|
|Entire file name is indistinguishable from random|
|Encrypted directory names|
|Entire directory name is indistinguishable from random|
Detailed description of ScramFS file system encryption
Each file in ScramFS is broken up into file segments that are encrypted separately using AES-256 GCM with a unique encryption key and random initialization vector, and then tagged using a 128-bit authenticator. Each file segment tag is further authenticated together with other properties of the file, such as the file name authentication tag and forensic timestamps, to provide an overall file authentication tag, which guarantees the authenticity of the file.
Random keys are used to encrypt the contents of every file, meaning that:
- files can be re-encrypted if needed, and
- ScramFS provides semantic security for file contents.
Meanwhile, for performance reasons, deterministic encryption is used to encrypt file names and directory names (collectively referred to as path names). While this does not provide semantic security for path names, the trade-off provides fast file access: to open a specific file, it is not necessary to obtain a full directory listing and decrypt all files, which would be needed if using probabilistic encryption. This scheme provides deterministic chosen plaintext attack security for path names. In addition, because each directory has a different encryption key for encrypting paths in that directory, files with the same filename in different directories have different ciphertexts – thus deterministic CPA (chosen-plaintext attack) security is provided on the full path of files and directories.
ScramFS has been designed to detect changes in any file name, directory name, file content and file timestamp. In ScramFS, all these fields are encrypted and authenticated. In comparison, other file systems offer a lower level of security.
|ScramFS||Microsoft NTFS EFS Built into Windows||eCryptFS
Built into Linux
|Authenticated directory names|
|Authenticated file contents|
|Authenticated file names|
|Authenticated file timestamps|
Authentication of file names and directory names
A file or directory having a name ciphertext that fails integrity checking is automatically treated as “foreign” and is ignored by ScramFS. Consequently, it is impossible for an attacker to inject malicious files into the encrypted file system.
This feature is particularly important in protecting against attacks such as file injection attacks and malicious code execution attacks.
Authentication of file contents
ScramFS provides integrity checking for file contents in a highly efficient manner having minimal impact on performance. Each file segment is authenticated independently and on-demand as data is read, so it is unnecessary to read the entire file’s contents to authenticate only a subset of that file. Any unauthorised changes to the file's contents are detected by authenticating against the segment authentication tags, while unauthorised changes to the segment authentication tags are detected by authenticating against the file's authentication tag.
Integrity checking for timestamps
ScramFS stores two timestamps within the ciphertext of the file:
- Creation time
- Modification time
Any changes to these timestamps result in a change to the file’s authentication tag. Consequently, such changes are easily detected.
Therefore this feature protects against an attacker tampering with evidence or attempting to cover his or her tracks by changing timestamps, something that would otherwise be easy to do on a storage file system.
ScramFS authentication tag vs. conventional hash
Conventionally, hashes are used to guarantee the integrity of files. For example, it is commonplace for hashes to be used to detect modifications for data collected by forensic investigators. However, conventional usage of these hashes can only provide assurances of integrity limited to just the file contents.
The ScramFS file authentication tag provides a much higher level of integrity guarantee, as it also detects modifications in the paths of files and even the timestamps. For example, if an attacker attempts to alter the path of a file or its forensic timestamps, this will be detected by the ScramFS authentication tag.
|ScramFS authentication tag||Conventional file hash (e.g. SHA-256)|
|Detects modifications in file contents|
|Detects modifications in file name or directory name|
|Detects modifications in file timestamps|
The extra authentication features enable ScramFS to be used in situations that require the forensic preservation and authentication of data, such as evidence collection, while also providing confidentiality via encryption.
Hiding exact file lengths
Some secure applications may require hiding the exact file lengths of the plaintext files.
ScramFS achieves this by allowing the user to specify the file segment size on a per-file basis, overriding a global default. Each plaintext file is padded out to the next complete segment.
If hiding the exact file length is not important, then choosing a small segment size will result in more efficient file storage.
An example of file length hiding can be seen in the following table:
|Plaintext file size||Ciphertext file size –1KiB segment||Ciphertext file size –100KiB segment||Ciphertext file size –1MiB segment|
|23.1 KiB||24.6 KiB||100 KiB||1.0 MiB|
|963 KiB||986 KiB||1.0 MiB||1.0 MiB|
|1.42 MiB||1.45 MiB||1.5 MiB||2.0 MiB|
|2.52 MiB||2.58 MiB||2.6 MiB||3.0 MiB|
|425 MiB||435 MiB||426 MiB||425 MiB|
The overhead in authentication tags scales linearly per segment: 48 bytes – comprising one 16-byte initialization vector, and 2 authentication tags.
Modern cryptographic design for long term security
Uses only the latest primitives
ScramFS uses only the latest modern cryptographic primitives that have been carefully chosen to ensure the long term security of the encrypted data.
Block cipher: AES-256.
Authenticated encryption with associated data (AEAD) scheme: AES-256 block cipher used in the Galois counter mode as described in Morris J. Dworkin, "Recommendation for block cipher modes of operation: Galois/counter mode (GCM) and GMAC", 2007. NIST special publication 800-38D.
Deterministic authenticated encryption with associated data scheme: AES-256 block cipher used in the SIV authenticated encryption mode algorithm described in P. Rogaway and T. Shrimpton, "Deterministic Authenticated-Encryption", 2007.
Fixed input-length pseudorandom function: AES-256 block cipher with key length 256 bits and input length 128 bits generating a pseudorandom output of length 128 bits.
Variable input-length pseudorandom function: Uses the authentication tag generated by the authenticated encryption (AEAD) scheme with the initialization vector set to the input and empty plaintext and associated data.
Filename character encoding (non-cryptographic): choice of using a custom encoding known as Base32k, or standard Base64 or Base32.
Resistance to quantum attack
Unlike the majority of cryptographic file systems currently available, ScramFS uses quantum-resistant ciphers, while avoiding ciphers that are known to be vulnerable to attack by quantum computers.
In particular, ScramFS does not use any ciphers relying on integer factorization, discrete logarithms or elliptic-curve discrete logarithms. Such ciphers are not long-term secure; for example, RSA-2048 encryption is estimated to be breakable by the year 2029, according to Matteo Mariantoni from the Institute of Quantum Computing.
Instead, ScramFS follows and exceeds the recommendations outlined in the PQCRYPTO paper, "Initial recommendations of long-term secure post-quantum systems".
|PQCrypto interim minimum recommendation||ScramFS implementation|
|Symmetric encryption||AES-256 to provide 2128 post-quantum security||AES-256|
|Symmetric authentication||GCM using a 96-bit nonce and 128-bit authenticator||GCM using a 128-bit nonce and 128-bit authenticator|
In conrast, many other common file-based cryptosystems use a mixture of public-key and symmetric crypto algorithms. Therein lies the probelm. Regarding public-key encryption, it has been mathematically proven that the currently used algorithms based on RSA and ECC will be easily broken by quantum computers. This means that files encrypted by these cryptosystems cannot be considered secure for the long term. The two most commonly available ways of encrypting files are using Microsoft’s EFS and OpenPGP.
|ScramFS||Microsoft NTFS with EFS||OpenPGP (RFC-4880)|
|Algorithms||AES-256 GCM||AES-256 (since Windows XP)
ECC since Windows 7
RSA since Windows 2000
RSA, Elgamal, DSA
|Long term secure||Yes||No||No|
Security properties of ScramFS
ScramFS is implemented such that the encryption keys only exists on the client device, and all encryption and decryption is performed on the client side. Therefore, no unauthorized party can decrypt your data or gain access to your encryption keys from the storage medium or service.
Encryptions and decryptions are performed in memory, so ScramFS never writes any plaintext to disk (otherwise this would leave plaintext data vulnerable to forensic disk analysis). In contrast, Microsoft’s EFS writes each file firstly in plaintext, then encrypts it, before deleting the plaintext file. Aside from being inefficient, this leaves the plaintext file retrievable by reading the appropriate sectors from disk and is a major security hole.
Post-quantum security even with insecure TLS transport
Because all data is already encrypted using quantum resistant methods before leaving the client device, any data sent to the cloud via a HTTPS connection is also post-quantum safe.
Data is decrypted in real-time. This means that data can be decrypted on an "as needed" basis, and processing can commence immediately without needing to decrypt the entire data set.
For instance, running a "grep" on a set of encrypted log files is efficient: it can start immediately without preprocessing, and requires no temporary storage space.
Designed and peer-reviewed at world-leading research institutions
The age-old question with cryptography products remains: how do I know this is trustworthy? There is no shortage of products which claim to provide security, but whose claims are either vague or unverifiable. Many security experts refer to such products as snake oil.
That’s why we have engaged experienced, leading cryptographers from world leading research institutions, to design and peer review ScramFS.
We have publicly released a comprehensive security analysis of ScramFS and peer-reviews of ScramFS and invite further comment and review.