What's the deal with all the file encryption drivers

This is a meta post, sorry if that isn’t really allowed.

I’ve been working on a minifilter driver, and of course, been referencing this board often for advice from more seasoned kernel developers, and I’ve noticed a trend.

A huge amount of people are asking for help on the exact same problem – how to encrypt a file, and decrypt it only when opened by Notepad (or some other program). Why are so many people asking this? It almost sounds like a homework problem. This is such a narrow use case, seemingly able to be accomplished from usermode.

I’ve even discovered that OSR offers a commercial product for this, FESF, so presumably this problem is so prevalent that OSR can justify its existence and probably pulls in quite a bit of licensing fees from it.

Any insight for my idle curiosity is appreciated.

Security is a big business. People everywhere want to secure their files. Manufacturers don’t want CAD drawings to leave their plants. Governments want to be sure only specifically authorized people can read specific documents. And everyone wants to encrypt their “stuff” before they store it in the ubiquitous cloud. And, while just about everyone has settled on AES-256 these days, everyone has a laundry list of specifics of how they want their Key Management done.

Dynamic, per-file, transparent, encryption… where you store meta-data within the file… is shockingly difficult to implement correctly across multiple file systems and multiple versions of Windows. I mean really, really, hard. Multiply the complexity by approximately a factor of magnitude if you want to provide simultaneous “raw” and “cooked” views of the same file (thereby requiring you to write an Isolation Minifilter).

Multiply the above-described complexity by the number of OTHER Minifilters on a Windows system that you need to “play nice” with. For example antivirus. Or backup. Or license management. Or cloud filters (THERE’s one for the ages, right there).

Remember: The goal is for Arbitrary Application A to be able to open encrypted files for authorized users entirely transparently… and display and process clear text… and then write back changed data that is encrypted… without any change in said Arbitrary Application.

It’s a very, very, difficult problem.

I’ve even discovered that OSR offers a commercial product for this, FESF

That’s quite a “discovery”… it’s been one of our primary products, and described in detail on our web site, for several years. The fact that we have such a product allows me to be able to speak definitively on the complexity of accomplishing this goal.

It’s super-easy to throw some shit together and make a demo work. It’s reasonably easy to throw some shit together and make it work for a very specific, special-purposes, set of uses. The road is littered with the bodies of people who call us and say they are “one bug away” from having their stuff work. Sadly, they don’t yet know that they’re seeing a “false summit.”

So… that’s pretty much the story. I hope that works toward satisfying your curiosity.

Peter

If I were assigned to transparently cipher files, the absolute last approach I would have considered would be a minifilter, unless it needed to work on the block level or expose contents as a filesystem.

without any change in said Arbitrary Application

I suppose that’s the key here. I suppose I never really considered this problem before, despite how prevalent it seems to be. It was almost comical seeing the same question asked over and over again.

Thanks for your reply, Peter. I really appreciate your response.

If I were assigned to transparently cipher files, the absolute last approach I would have considered would be a minifilter, unless it needed to work on the block level or expose contents as a filesystem.

Perhaps that’s your Linux is showing? In Windows, if we wanted to encrypt at the block level insert a Filter at the Volume or Disk levels… but in any case, well below that of the file system.

Being a Minifilter allows us to insert ourself between the user’s Create/Close/Read/Write requests and the file system’s processing of those requests. So, at its simplest level, the user does a read, the file system reads the raw (encrypted data) and the Minifilter decrypts it before returning it to the user. That’s a lot of conceptual shorthand of course… there’s a BIT more to it than that. But that’s the idea.

Interestingly, in Linux we do it the same sort of way we do it on Windows: We use a layered file system mounted over the base/native file system (because there are no “filters” per se on Linux). More’s the pity :wink:

Everyone wants to “just use Word, Excel, and Powerpoint” to allow authorized users to operate on encrypted files transparently. Users don’t even know the files are encrypted, necessarily. Even the directory listing of the (encrypted) files shows the authorized user the “cooked” length of the file (that is, the same length as would be seen if there was no associated metadata or encryption). As opposed to the Office apps, your backup program sees the “raw” view of the file (assuming that’s what you want). So, when IT reads the file it gets the “raw” (encrypted) file contents + metadata. And when IT queries the file size or takes a directory listing IT see the “raw” file length.

When it works, it’s all very cool and automatic and transparent. When it works. WHEN it works.

Cheers,

Peter