40

There are a couple of files / tools which provide file-level encryption. I guess PDF and ZIP are probably the most commonly known ones.

I wonder what scenario they actually help with or if it just is a bad solution.

For example, if I want to be sure that no man in the middle gets information when I transfer a file over the internet, I think TLS is the solution to go with.

If I want to get some security that attackers who get data on my laptop when I loose the device, I would think of full disk encryption.

The only point I can see is a low-skill attacker which has access to the machine with the encrypted file. Essentially if a friend / family member has access and does not accidentally see something. Do I miss a scenario?

Martin Thoma
  • 3,902
  • 6
  • 30
  • 42
  • 22
    The concept for file encryption is "security at rest". You are focused on "security in transit" and your "at rest" scenario is limited entirely to your own laptop. – schroeder May 10 '20 at 13:27
  • 10
    @schroeder File encryption, such as encrypted zip archives, may *certainly* be useful for data in transit as well, when you don't have control over the transmission control. – vidarlo May 10 '20 at 18:15
  • 2
    @vidarlo yes, of course, but the context here is "I have TLS, I can't see the need for file encryption" – schroeder May 11 '20 at 08:30
  • 7
    You are thinking today. But file-level encryption is way older than that, from a time when neither full-disk encryption nor TLS were common. – Tom May 11 '20 at 14:46
  • Well, yes. If that was the only point, then file encryption should be deprecated. But there were a couple of answers that show how it's still of value today. – Martin Thoma May 11 '20 at 16:36

8 Answers8

81

File-level encryption can be useful in several cases, here's a few examples:

  • Sending data over insecure channels. You mentioned TLS, and that's enough when you have it. But what if you aren't sure every node actually uses TLS? And do you really trust every node? Think about emails, for example.
  • Storing data in untrusted places. You might trust your encrypted external HDD, but what about Google Drive? What about your hosting provider? If you want to be sure that nobody else is able to access your files (Google, employees at your hosting provider, cyber criminals who manage to breach those service, etc.), you will need to encrypt your files.
  • Defense in depth. Full-disk encryption will protect your data when your machine is turned off, but what if an attacker grabs your laptop while it's on? What if your machine gets infected and before you notice all your sensitive files are sent to the attacker? With file-level encryption, the attacker won't have access to the content of your sensitive files right away, so such attacks might fail.
reed
  • 15,398
  • 6
  • 43
  • 64
  • 5
    "but what if an attacker grabs your laptop while it's on" - it doesn't help if you have opened the file. But I guess I understand where you're going: By having multiple layers of security, the chance of all of them failing gets lower. Is that the idea of "defense in depth"? (+1, btw :-) ) – Martin Thoma May 10 '20 at 18:59
  • "do you really trust every node? Think about emails": I thought there are 3 connections: Sender (S) to senders mail provider (SMP). SMP to receivers mail provider (RMP). RMP to receiver (R). I have control over S->SMP and partially over SMP->RMP. If my receiver has bad security, then the file encryption doesn't help a lot as they need the key as well (yes, I know of asymmetric encryption... but that's way more complicated for users than having a mail provider which uses TLS always). Still, the defense in depth argument is true there. – Martin Thoma May 10 '20 at 19:14
  • 16
    @MartinThoma With encrypted files, you have no need to trust either of the mail providers, only the machines the files are actually processed on. Assuming of course you transfer the key via another method, such as phone call. – jpa May 10 '20 at 20:08
  • Partitioned security, such that different data sets have different protection. – chrylis -cautiouslyoptimistic- May 10 '20 at 22:01
  • @MartinThoma: You can have control over S->RMP if you want (including enforcing STARTTLS and validating key with DANE or some other method you consider appropriate). Not having it is a choice to delegate trust to your SMP. – R.. GitHub STOP HELPING ICE May 10 '20 at 23:48
  • 29
    @MartinThoma You're a lot more likely to have your laptop open than to have some particular file open. – cpast May 11 '20 at 03:24
  • 2
    @MartinThoma - Even in an ideal mail-transmission scenario such as you describe, where there is only a single SMTP connection are from SMP to RMP, those connections are still routed through some number of intermediate systems (unless the sending host and both mail servers are all on the same network segment). Those intermediate systems are capable of recording or packet-sniffing the data in transit through them, thus gaining access to the content of (unencrypted) email, unless the mail servers are using TLS, which is not ubiquitous for SMTP connections. – Dave Sherohman May 11 '20 at 09:21
  • I'm not really all that knowledgeable in the field on encryption myself, but I believe it's also possible for file-level encryption to function as a form of DRM, no? Meaning, even users who are legitimately allowed to *view* the file may be prevented from *editing it* due to in-built encryption schemes? Or am I completely out to lunch here? – Steve-O May 11 '20 at 13:28
  • @Steve-O, yes, cryptography is often used in DRM, but encryption by itself won't be enough to function as a form of DRM. DRM, as far as I know, in practice relies on some obscurity (closed-source software, hardware modules that are hard to reverse engineer, etc.) – reed May 11 '20 at 15:51
  • @cpast As a real-world example, Ross Ulbricht (creator of Silk Road) was caught with his laptop open, and it was literally grabbed from him. https://www.wired.com/2015/04/silk-road-1/ – mbomb007 May 15 '20 at 19:44
14

Full disk encryption provides no protection whatsoever against attacker with remote access while your machine is powered (as by definition FDE requires data to be decrypted on every access). So in order to use machine at all, you must unlock all data.

To contrast, encrypted files are decrypted only on explicit user request providing password. That means even when machine is compromised, those file are secure until user provides valid password, which gives extra time to detect attacker and protect yourself. This also provides much higher granularity (as the password can be different on every one of them, or depending on sensitivity of data, or the group of users it is shared with), providing extra security via principle of least privilege

For example, my cooking recipes which I use every day could be protected by one password, my checking banking accounts which I pay once per month by another one, and my will which I change once every 10 years by yet third password. So the attacker would have to remain undetected for 10 years is he hopes to see my will. With FDE, he would have access to it immediately with everything else.

Also, separately encrypted files are compatible with shared fileserver, which is accessed by users with different privileges (and thus knowing only a subset of shared passwords the documents are encrypted with).

TLS itself has a lots of problems, like MiTM attacks or CA compromises (do you really trust all that CAs in your web browser? I certainly don't for anything serious - you could delete all of them and use only your own CA, which would be secure, but no one does it as it would preclude you from accessing you bank etc).

Encrypted files on the other hand depend only on secrecy of password shared by you and others that need to access that information - and you have complete control over that.

Encrypted files are also end-to-end protected when you transmit them, so they don't care if the path in between you and the recipient is compromised. You attach encrypted file to you email, and you known nobody can read it unless they know the password. If you instead rely in ISPs to properly implement TLS in SMTP, you are about to be in the world of pain (SMTP STARTTLS stripping MiTM, default SMTP fallback to plaintext, files being stored in plaintext at recipient IMAP server and depending on ISP's security and goodwill of its disgruntled employees etc.)

Also, think of defense in depth. You can (and should, if you care enough) use encrypted files and TLS and FDE to achive best security.

Matija Nalis
  • 2,115
  • 12
  • 18
12

The only point I can see is a low-skill attacker which has access to the machine with the encrypted file. Essentially if a friend / family member has access and does not accidentally see something. Do I miss a scenario?

Your assumption that the only way an attacker can have access to your computer is by being physically present is completely wrong.While i wont talk about skills of said attacker,he still has many ways to run malicious code in your computer,once he can do that he can also exfiltrate data to his C2.

I wonder what scenario they actually help with or if it just is a bad solution.

Encrypting data helps in the scenario of data storage and is a defence in depth concept.Look at just last year how many companies have been breached and had their data stolen,think of all the passwords/credit card numbers that were stored plaintext.In my opinion file encryption of sensitive data is a must and should be in threat model of everyone.

yeah_well
  • 3,699
  • 1
  • 13
  • 30
  • "Your assumption that the only way an attacker can have access to your computer is by being physically present " - I never wrote that. One scenario I thought if is when the attacker can execute code as root. But then the attacker can install a keylogger and file-encryption is useless. – Martin Thoma May 10 '20 at 18:52
  • "many companies have been breached and had their data stolen" - the cases I'm aware of are mostly SQL injections / some service running and exposing data. There it's of no help if the data is encrypted when it's on disk. – Martin Thoma May 10 '20 at 18:53
  • 1
    @MartinThoma the link i mentioned in my answer is a site that finds and compiles all the ways that attackers have used to get inside network,move laterally and do blackhat stuff.SQL injection/exploit vulnerable service is not the only way to do it. – yeah_well May 11 '20 at 06:59
  • "One scenario I thought if is when the attacker can execute code as root. But then the attacker can install a keylogger and file-encryption is useless"-Yes,if an attacker can just wait for you to decrypt it then they can just take the decrypted data as well,there is no 100% security to begin with,hence the defence in depth concept that you mess up on one end there is another to protect you.(attacker executes code on your system,the data is still encrypted) – yeah_well May 11 '20 at 07:01
  • 1
    @MartinThoma the attacker temporarily being able to execute code as root means that the attacker can grab and exfiltrate data from your computer until the attack is detected. If the files are encrypted at rest, the assumption is that they are decrypted *rarely* and that this likely won't happen during the window of the attack. – Peteris May 11 '20 at 11:44
3

You mentioned most of it, mitm, family/friend access to files, losing of devices.

Another thing most people overlooked would be in the corporate side of things, compliance is another factor to look at. Data protection policies etc.

How about hosting your encrypted files in another person or organization's infrastructure? Cloud services is a huge thing now, AWS does take measures to encrypt & safe-keep your data but it's best you add your own 'layer' as well!

mallocation
  • 1,668
  • 5
  • 20
matthey
  • 53
  • 8
  • 1
    "complience": That is a bad reason. Just because the law says so does not mean it adds security. I think Bruce Schneier coined the term "security concert" for things that seem to help, but actually just make you feel save. Images like [this](https://www.pinterest.de/pin/265853184224878648/) come to my mind. – Martin Thoma May 10 '20 at 18:58
  • 1
    @Martin, I believe the term you're thinking of is "security theater"? – Harry Johnston May 10 '20 at 22:08
  • 6
    @MartinThoma For compliance, it's not "security theatre". The encryption is just as real, but the difference is that multiple people in the organisation may have access. For compliance purposes though, the people with access are specifically identified as requiring access to do their job, and the rest of the organisation who don't need it, don't have access. Employee records might be an example. – Graham May 10 '20 at 22:46
  • @HarryJohnston Oh, right - I can't edit my comment, though :-) – Martin Thoma May 11 '20 at 09:08
2

Where you wish to email or share (on a file-share or online system) where you don't trust or have no assurance in the trust of the messaging or file-system admins? TLS between mailservers doesn't mean that the attachment is encrypted in your inbox*.

In a corporate environment, for example, you might want to share a Doctor's report with your manager and the Occupational Health team but not with Bob from IT.

Or, in the current environment, somebody might want to share a sensitive draft for your review, but because of, whatever, all you have available is Dropbox (not to pick on them and other services are available.)

  • It is in many email systems but would be automatically decrypted for any legitimate, in IT access terms, user - you and the admins.
mwapemble
  • 41
  • 2
2

Think about devices that are always powered on. The number one example is phones. Here, full-disk encryption won't help a lot if the device falls into the hands of the attacker because the single key that allows to decrypt the entire disk will be held in memory when the device is in your pocket. File-based encryption allows more fine-grained control over which files are decryptable (or technically speaking, which keys are available in memory) at a specific point in time.

For this reason, file-based encryption is indeed used in iOS and in Android. This makes it possible to evict certain keys for certain files from memory, e.g., when the device is locked. A blog post by Matthew Green explains all of this in good detail. It's a few years old, so it may be slightly outdated when it comes to implementation specifics in iOS and Android but his general considerations regarding the threat model are of course still accurate and to the point.

real-or-random
  • 121
  • 2
  • "the entire disk is is an decrypted state when the device is in your pocket." - is it? I thought those encryptions would work on blocks and decrypt what is necessary when it's loaded from disk into memory. On my computer, the disk is WAY bigger than my memory. Where is the decrypted version when I'm logged in? – Martin Thoma May 11 '20 at 10:43
  • 1
    Yes, the accurate version of this is that the (short) key to decrypt the entire disk is held in memory. I'll edit the answer to make this clearer. – real-or-random May 11 '20 at 11:30
2

They're very different things, so it's hard to bring them under one hood.

PDF protection/encryption is a kind of joke, really. All in all, it's not made to withstand actual attacks. So the "benefit" is mainly to prevent your 8-year-old (or your 80-year-old parent) from reading a document. PDF protection is much like hiding caller ID when making a phone call. The device is asked to kindly comply with your request to deny the user certain functionality. A software that simply doesn't care will reveal the document.
PDF encryption, on the other hand, is actual encryption (making the text unreadable and unrecoverable). Except... unluckily, they're only using 40 bits from your password hash (at least, that was the case last time I looked), and 40 bits is, err... well... not really awesome. That's not just something you could brute-force in theory, it's something you can brute-force (without even resorting to the help of a dictionary) in a very reasonable amount of time with no-special stuff. As in, 2-3 hours on a modern desktop PC running single-threadedly. Or, well, a couple of minutes full throttle, for that matter.

On the other hand, ZIP/7z encryption is actually quite good. While still derived from a password, it uses a 256 bit key and AES encryption. Sure enough, few passwords, if any, have that much entropy, so... the 256 bits should be seen as "up to..." figure. But in general, as far as the implementation's limitations go, it's pretty good. The rest, that's your responsibility.

Now, what is the advantage when transmitting data over an insecure channel like TLS? Wait, did I say insecure? Indeed, I did.

TLS is secure only under the assumption that you can trust your certificate chain. Which, unluckily, is as far from the truth as it could possibly be. Not only do many antivirus tools on the end-user's computer install custom root certificates and intercept/decode TLS (and, at its own discretion, forward data to some hopefully trustworthy third party in e.g. Tomsk). Not only do CAs get compromised. Not only do several governmental agencies subvert the certificate chain, deliberately and systematically, only to decrypt your traffic. There exist companies (which are also Root CAs) that have packaged the whole eavesdropping thing into ready-to-use-no-tech-skill-necessary boxes, and are selling these to whoever is paying for it.

Sure enough, if you do not want (or cannot afford) someone on the internet to read your precious documents, then file-level encryption does add a benefit because now, all of a sudden, eavesdropping is no longer automatic, online-realtime, and trivial. Well, the actual eavesdropping still is... it's just that what you get isn't very meaningful. Assuming a good password and barring a wrench attack, it's very hard to get to the data.

Encrypted archives (not all, not necessarily, but usually) also have the benefit of hiding metadata such as the filename or size, i.e. you can't even tell what may be the topic, or whether it's worth an attack.
If you send an encrypted file named plan_to_kill_president.doc, you can be sure to get monitored closely (or questioned) soon, regardless of whether the contents can be deciphered or not. If you send a document patent_application_fusion_battery.doc, it's obvious to an eavesdropper that an attack on the encryption may be worth the effort. If you send a file stuff.7z, nobody can tell. It could be anything and everything, or nothing. Fun fact: two identical archives encrypted with the same password are not even identical (that can come as quite a bit of a surprise to unsuspecting users!).

What about full disk encryption? Well, that sure is a kind of a hurdle for a laptop thief or a drive thief, but otherwise... the sad truth is that if you can read it during normal operation, someone else probably can, too. Getting to the data while you are logged in is, compared to breaking encryption, pretty easy, almost trivial.
An encrypted file on an encrypted volume is still encrypted, if I can access it. Sure, there are means of getting the password, but it's an extra hurdle that isn't all trivial.

Damon
  • 5,001
  • 1
  • 19
  • 26
  • If I encrypted a file, I would use gpg with my `rsa3072` key. I guess that is save and then I can ignore all the others (zip/pdf or whatever there might be?) – Martin Thoma May 12 '20 at 19:28
  • I was also thinking of this from a developers perspective. Maybe I want my users who I can't force to learn how to use gpg to have some critical files stored encrypted locally. As a python developer I would use [`fernet`](https://cryptography.io/en/latest/fernet/) (AES in CBC mode with a 128-bit key for encryption; using PKCS7 padding). Assuming the user chooses a reasonable save key (or is fine with storing a keyfile generated by a cryptograph random number generator), is that currently considered save? – Martin Thoma May 12 '20 at 19:31
  • CBC may be troublesome (see e.g. https://en.wikipedia.org/wiki/Padding_oracle_attack), but in this usage case it should be perfectly good (much different scenario!). Keyfile is a reasonably good compromise as long as the keyfile itself is properly encrypted (note that password managers like Keepass are nothing but exactly that, only "password" instead of "key", but it's all the same). Of course no keyfile, and some sort of _magic solution_ instead would be preferrable, but that's unluckily not a _practical_ approach. I personally don't trust RSA much because although factorization is hard... – Damon May 13 '20 at 12:23
  • ... it is a real thing, and getting easier and faster (and nobody knows exactly about quantum computing in 5 years for sure). It's one of the things that can be done covertly in a trouble-free manner, too. Covertly extracting the password from my brain, on the other hand side, is not a realistic scenario in the foreseeable future. Thus, that gives me a better overall feeling. – Damon May 13 '20 at 12:26
0

File-level encryption has its uses, although usually relies on passwords or passphrases which can be the weakest link in the protection mechanism if they are short or easy to guess. If you want to send someone a file, you can do this using file-based encryption and not necessarily rely on encryption of data in transit. In addition if the file is intercepted from source or destination, it will be more difficult to retrieve the comments.

Conversely, as you rightly pointed out, full disk encryption provides assurance of data confidentiality at rest. If your laptop is stolen it makes it very difficult to extract data from the storage device - again depending on the methodology and strength of password or passphrase. From that point of view, exchanging a particular file unencrypted would have the security of the transfer susceptible to the protocols used and storage on the destination side (and during transfer transfer since some file transfer mechanisms are brokered by cloud services). So in some respects, full disk encryption and file based encryption are not additive assurances.

Pedro
  • 3,911
  • 11
  • 25