File system features
ScramFS has many carefully designed features to maximize usability while maintaining security. Many features have never before been offered in an encrypting file system.
The brilliant simplicity of a regular file system
The beauty of ScramFS lies in its brilliant simplicity: to users, it looks just like a regular file system. All of the complexities of encryption are handled in the behind-the-scenes.
By adopting a paradigm that everyone is already familiar with, users can be instantly productive. There's virtually no learning curve or changes to work patterns required.
Through all its four interfaces, ScramFS empowers users to encrypt with minimal effort.
|Everyone||Graphical User Interface (GUI)||Encrypt files by drag and drop; easily secure data copied to USB devices and cloud storage|
|Everyone||Virtual mount||Use your encrypted files normally, just like regular files. Data is automatically encrypted and decrypted on demand, in the background.|
|System administrators and integrators||Command Line Interface (CLI)||Script encryption operations; add encryption into existing workflows and automated scheduled tasks.|
|Software developers||Application Programming Interface (API)||Add encryption to applications rapidly, error-free and without re-architecting.|
Support for standard file and directory operations
ScramFS supports all the regular functions that you would expect from a file system.
|ScramFS function||Posix equivalent||Description|
|CreateFile||touch||Create file with zero length|
|Open||fopen||Open a file and return it|
|Read||fread||Read from a file|
|Write||fwrite||Write to a file|
|OpenForResume||N/A||Open a file to resume an interrupted transfer. Provided for efficiency when writing files to the cloud.|
|Flush||fflush||Flush buffers to disk|
|Close||fclose||Close the file and write out any pending buffers and tags|
|SetContents||N/A||Saves entire file. Automatically calls Open(), Write() and Close().|
|GetContents||N/A||Loads entire file and return its contents. Automatically calls Open(), Read() and Close().|
|Seek||fseek||Seek to specific position|
|Tell||ftell||Get the current position|
|Operations on files|
|Rename||rename||Rename a file|
|Copy||N/A||Copy a file. This is provided for efficiency.|
|Remove||remove||Remove a file.|
|Getinfo||stat||Get the file’s forensic creation time, modified time, plaintext file length.|
|Settimes||utime||Set the file’s forensic creation time, modified time.|
|Isfile||stat||Check if a file exists|
|Isdir||stat||Check if a directory exists|
|Operations on directories|
|MakeDir||mkdir||Make a directory|
|RemoveDir||remove / rmdir||Remove a directory|
|ListDir||readdir||Get directory listing|
|Movedir||N/A||Recursively move a directory and all its files and subdirectories|
|Copydir||N/A||Recursively move a directory and all its files and subdirectories|
1:1 mapping between input and output files and directories
ScramFS features a direct 1:1 mapping between input and output files and directories. (There is a corner-case exception noted below.)
While this does not hide the directory and file structure on the underlying storage filesystem, we purposefully chose to use a 1:1 mapping for the following reasons:
- Robustness: a corruption (malicious or otherwise) in one file will not affect other files. Alternative approaches, such as segmenting data and storing in associative storage can result in multiple files being affected with a single corruption.
- Avoids storage speed degradation: on local storage, the 1:1 mapping means that the encrypted file is no more fragmented on the physical disk than would be without encryption. In contrast, systems that chunk and encrypt data separately (as in deduplicating file systems) suffer badly from fragmentation and performance degradation.
- Lightweight versatility: the intent of ScramFS is to provide a transparent cryptographic layer on top of storage. This provides a lightweight and versatile platform to build upon. For low-powered devices such as IoT and mobile devices, minimising processor overhead is a key requirement.
- Hiding the directory and file structure is better implemented at the application layer: given that ScramFS already hides the exact lengths of files, directory names and file names, hiding the directory and file structure is only required in a minority of cases. Therefore, building this directly into ScramFS would impose unnecessary complexity and compromises upon all other applications. However, where hiding the directory and file structure is a requirement, it is possible to implement a solution at a higher layer in the solution stack (above ScramFS) while benefitting from the encryption and authenticated integrity checking provided by ScramFS.
In summary, users of ScramFS can expect a direct 1:1 mapping between ciphertext and plaintext files and directories. There is a small exception is for long directory names – if a directory is created with a name longer than the underlying filesystem will support, ScramFS will truncate the directory name and place the overflow in a small meta file.
File and directory name features
Case sensitive, Unicode file and directory names
All file and directory names in ScramFS are Unicode.
File and directory names in ScramFS are always case sensitive, regardless of the underlying storage filesystem. This avoids the problems of FAT (not case sensitive but case preserving) and NTFS (case sensitive, but API calls are case in-sensitive) and provides consistency across all platforms.
Fast file open
As part of its cloud-friendly design, ScramFS is designed to minimize the delays associated with slow networks. ScramFS therefore uses deterministic encryption for file and directory names. This provides a fast file open capabilities, where an Open function call will translate into a single open call to the underlying filesystem.
In contrast, using probabilistic encryption for path names would be much slower. This would require a directory list operation, decryption of all filenames and search for a match, before opening the file.
Immensely long file and directory names
ScramFS overcomes the barriers imposed by different underlying storage file systems by supporting immensely long file and directory names. This means it is possible to create a file in ScramFS with more characters in its name than would be supported by underlying storage.
When ScramFS writes this file to disk in ciphertext, it will write a ciphertext filename that is automatically compatible with the underlying storage file system by splitting the ciphertext of the filename into two:
- the first part of the ciphertext file name together with the file name authenticated MAC is embedded into the ciphertext filename on underlying storage, and
- the remainder of the ciphertext file name (that is, the overflow) is embedded into the ciphertext file contents.
While providing consistent support for long paths across all underlying storage file systems, great care has also been taken to ensure that the performance impact of overflow ciphertext is minimized. This includes:
- careful coding of file names to maximize the information stored in the first part of the ciphertext filename, and
- using the cryptographic MAC provided by the SIV mode of encryption, the possibility of clashes in the truncated file name is negligible (2128).
Thus ScramFS provides the best performance possible on file systems of limited capability.
The net benefit is that developers can code their applications using ScramFS without having to worry about storage inconsistencies between different operating systems and storage file systems.
File content features
Decryption and encryption on-the-fly, behind the scenes
ScramFS commands Read() and Write() will automatically decrypt and encrypt data on demand. The specific design features that make this possible is described in our Encryption Deep Dive, but the benefits can be summarised as:
- Delay free: no need to decrypt an entire file before accessing it.
- Space efficient: no need to write temporary files to disk.
- Avoid leakage: no leakage of plaintext to disk.
- Minimal impact: all the encryption and decryption happens behind the scenes, so users don’t notice any difference.
Random access: seek, read and write
ScramFS supports random access: seeking to various locations within a file and reading and writing. This functionality mirrors the functionality provided by standard filesystems.
Additionally, the seek operation is fast: it is not necessary for ScramFS to read the entire file up to the point being sought.
This makes it possible to perform advanced tasks such as playing an encrypted MP4 video file, which requires random access.
Two forensic time stamps
ScramFS implements two special time stamps that are authenticated – meaning they cannot be forged and therefore can be used for forensic purposes.
- File creation time
- File modification time
These two time stamps are independent from the time stamps provided by underlying storage. Therefore these time stamps are preserved if the underlying ciphertext files are copied from one storage file system to another.