TABLE OF CONTENTS
- The Virtual Filesystem
- Why is the Virtual Filesystem needed?
- How does the Virtual Filesystem work?
- What are KAMA files?
The Virtual Filesystem
The Atakama Vault (C:\Users\<Username>\Atakama\Vault) is a virtual filesystem (VFS) that acts as an overlay, presenting encrypted files to the user as "normal" files. Opening (i.e., reading) a file from within the Atakama Vault, decrypts the file contents in RAM, while saving (i.e., writing) a file in the Atakama Vault encrypts the contents before the contents are saved to disk.
Why the VFS is Necessary
Saving (i.e., writing) the file to a temporary location creates a security risk.
- Security: Any data written to disk may be recoverable, for example if the computer crashes before the file is deleted, or by forensics experts with access to the drive. The VFS decrypts in memory only thereby mitigating these security issues. While there are exceptions (e.g., swap files or poorly-behaved applications), in general the VFS model renders data extraction more difficult.
- Performance: Decrypting the entirety of a large file can be time consuming. Instead, the VFS decrypts only those portions of the file the application requests.
- Compatibility: Existing applications can integrate with the VFS without the need for special configurations. For example, a service that stores scanned copies of documents can simply be pointed at the VFS without any other changes, with all the scanned files saved to the VFS automatically encrypted.
The VFS Functionality
Filesystem drivers are normally implemented as kernel extensions, giving them access to the entire system with unlimited privileges, and a kernel extension crash can bring down the entire operating system. To avoid these pitfalls, it is best to minimize the amount of code that runs in-kernel and instead to keep most logic in userspace.
Atakama accomplishes the split by using WinFSP, which acts as a kernel driver but forwards most filesystem operations to a userspace application. As a result, the VFS mostly operates with the same privilege level as the user running Atakama.
For example, suppose a user is trying to open an encrypted Microsoft Word document, secret.docx. Upon launch, Word attempts to read from secret.docx via the VFS. Windows forwards the request to WinFSP, which in turn forwards the request to the Atakama process. Atakama then determines if it needs to perform a MofNop to decrypt the file. Upon a successful MofNop, the encrypted content is read from the associated .kama file (secret.docx.kama), decrypted, and sent back to Word via WinFSP.
When interacting with .kama files, requests are routed through the VFS. When a file is double clicked in Windows Explorer, Atakama will translate the .kama file's path to an equivalent VFS path, which is the path that is opened. This ensures the security and compatibility guarantees of the Atakama Vault are maintained even when the user is not accessing the file directly through the Atakama Vault.
.kama files
.kama files are the binary file format used to store encrypted content and associated file metadata, including backups of key shards and indexes for MofNops.
.kama files are split internally into a number of segments, each of which can be modified independently. Conceptually, this is similar to a Zip file, where a single file contains a number of sub-files.
.kama files are also responsible for handling concurrent access across network shares. This serves two purposes: (i) to prevent corruption of the .kama file's internal structure, and (2) to prevent corruption of application-level data written via the VFS.