2

Goal: Encrypt/secure and access sensitive files (PDFs, etc.) locally.

Method 1: Store files in a VeraCrypt file-hosted volume (container).

Concern: Data Leaks. When mounting and reading files from a VeraCrypt container, there is a possibility that

. . . operating system and third-party applications may write to unencrypted volumes (typically, to the unencrypted system volume) unencrypted information about the data stored in the VeraCrypt volume . . . or the data itself in an unencrypted form (temporary files, etc.) . . .

Method 2 Store VeraCrypt container as an attachment inside a KeePass 2.x database.

When accessing a file attachment inside a KeePass 2.x database, the following message appears:

KeePass has extracted the attachment to a (EFS-encrypted) temporary file and opened it using an external application. After view/editing and closing the file in the external application, please choose how to continue:

  • Import: replace the attachment by the (modified) temporary file.

  • Discard Changes: discard changes made to the temporary file and do not modify the current attachment.

In any case, KeePass will securely delete the temporary file afterwards.

Questions

  1. Does method 2 address data leak vulnerabilities present when accessing files via method 1?
  2. Is there a "better" way to secure and access files?
Community
  • 1
WHY
  • 123
  • 4

3 Answers3

4

Does method 2 address data leak vulnerabilities present when accessing files via method 1?

Not at all. It just ensures that the already-protected VeraCrypt container will be saved to an encrypted space when extracted for mounting and removed safely on unmount.

All applications used to open and process the files stored inside the VeraCrypt container will behave in the same way as in the method 1 and the possibility of storing temporary files on non-protected disks remains.

Is there a "better" way to secure and access files?

For the concern specified in the question: the machine used to run the applications opening/processing the files must use full disk encryption for all its disks.

This KeePass feature is intended to protect for example a plain text file stored in the KeePass database. When you open such file, KeePass has to save it in the filesystem so that an application (like Notepad) can open it (because Notepad does not know how to read directly from the KeePass database).

KeePass ensures no trace of this file, which KeePass itself temporarily saves in the filesystem, will remain. But it cannot limit what the application can do with this file/data. Applications run in a regular namespace (they are not sandboxed by KeePass in any way) and can store temporary files wherever they "want" (i.e. were configured to).

techraf
  • 9,141
  • 11
  • 44
  • 62
  • ". . .the already protected VeraCrypt container will be saved to an encrypted space . . ." Is that encrypted space still vulnerable when open/read, even if I were opening the file directly instead of the Veracrypt container? i.e., I assume the encrypted temporary file is decrypted when being viewed by an external application. – WHY Aug 03 '16 at 08:39
  • That space won't be used for anything else than storing the VeraCrypt container. You would be effectively encrypting the already-encrypted container. Any data from the container could be temporarily stored outside. – techraf Aug 03 '16 at 08:44
  • Updated the answer with an explanation what this KeePass feature is intended for. – techraf Aug 03 '16 at 09:13
2

If you're concerned about data alteration

operating system and third-party applications may write to unencrypted volumes

If you're concerned about writing and not reading then, can't you just check the signature of the file? (sha-1, sha-2, etc.). Or if the file is small enough, read the content?

If you are concern about protecting your files while using them

In which situation, would you not trust your own OS? If the OS is compromised, anything that ever appear on the screen could be a lie. You can't rely on anything if you don't trust your own OS.

I can't think of any process in which the unencrypted files wouldn't be stored either in RAM or on the disk. And, if it is stored in RAM or disk then any compromised OS can access and alter it. You have to trust your OS somehow. The recommendations on this page from your question includes a few way to setup a trusted OS

Maybe, you can also try to decrypt your files on an air-gap laptop on a VM you just built from a trusted image? (you can look up for vagrant but don't use images from Atlas) That's one more process to put you a situation where you can moderately trust your OS.

It seems to defeat the purpose of encrypting the files in the first place

The purpose of encryption is to prevent access to your file if:

  • you send those file over a network
  • your computer is turned off
  • your files aren't being accessed (temporary files deleted and decryption key/passphrase not in RAM).

You can't protect files while using them. You need to use the following process: open encrypted files in a trusted environment -> use the files (files at risk) -> close and re-encrypt the files (if they're modified) and delete temporary files -> send files over an untrusted network/in an untrusted environment.

If you're concerned about temporary files and how to ensure their deletion

It depends a lot of the softwares that use those files and what they do with it. (if they copy those files somewhere else, keep it in RAM, etc.)

Matthieu
  • 316
  • 2
  • 10
  • Perhaps I misunderstand VeraCrypt's warning, but my concern lies in the unencrypted temporary files created by the OS when reading the files from the encrypted volume. It seems to defeat the purpose of encrypting the files in the first place. – WHY Aug 03 '16 at 07:11
  • 1
    I can't think of any process in which the unencrypted files wouldn't be stored either in RAM or on the disk. If it is stored in RAM or disk then any compromised OS can access and alter it. You have to trust your OS somehow. The recommendations on this page includes a few way to setup a trusted OS (+ my suggestion of a temporary VM): https://veracrypt.codeplex.com/wikipage?title=Data%20Leaks to – Matthieu Aug 03 '16 at 07:19
  • "It seems to defeat the purpose of encrypting the files in the first place" The purpose of encryption is to prevent access to your file if: you send those file over a network or your computer is off or your files aren't being accessed (temporary files deleted and decryption key/passphrase not in RAM). You can't protect files while using them. You need to use the following process: open encrypted files in a trusted environment -> use the files (files at risk) -> close and reencrypt files (and delete temporary files) -> send files over an untrusted network/in an untrusted environment. – Matthieu Aug 03 '16 at 07:27
  • "You can't protect files while using them." A good way to summarize some of my concerns. As for those temporary files, how can I make sure that that data is destroyed once the files are no longer accessed? – WHY Aug 03 '16 at 07:31
  • I don't know much about veraCrypt, but it would be a terrible software if it didn't destroy those temporary files. Maybe edit your question, and ask about checking that temporary files are gone, that's a little much for comments. – Matthieu Aug 03 '16 at 07:36
1

You could use a Live CD, for ex. TAILS and mount the encrypted volume using tools available on that system. That way the data never touches your drive - all operations are done in RAM.

You can also run the Live CD in a VM, which does not force you to reboot your regular OS but then your host OS has some degree of control over the system run from Live CD.

It's up to you how airtight you need the solution to be - physical Live CD is safer but Live CD in a VM is more convenient.

TermoTux
  • 111
  • 2