4

I'm working on a C++ application that stores (and frequently accesses) its data across many files within a single directory via numerous classes, database libraries, etc. I would like to start encrypting all this data on disk using a key managed by the application.

On windows, programmatically enabling EFS for the directory would be perfect if the application could set the encryption key directly rather than using one based on the logged-in user's password. This does not seem possible.

Because there are numerous places in the code that read/write files, some with full random-access, a library that exports something akin to the OS file operation API would be easiest in the absence of direct OS support.

Windows is the biggest user base but something usable on Mac and Linux would be a big plus.

Any suggestions?

tshepang
  • 12,111
  • 21
  • 91
  • 136
Brian White
  • 8,332
  • 2
  • 43
  • 67
  • Is the intention to secure the data from the user or to provide at-rest security (like EFS)? – Alex K. Jan 21 '13 at 16:18
  • I need the data readable only by the application. When the application is not running, the data should be inaccessible even to the owner of the account under which it runs, administrators of the machine, etc. The actual encryption key will be held off of the local machine, retrieved by the application when it starts, and forgotten when it exits. – Brian White Jan 21 '13 at 16:23

4 Answers4

2

Configure the application to run as a service account, intended only for it. Then, configure EFS. Since the application's service account will own the files, its user-specific keys should be the only valid EFS keys for it, so only the application (which will be the only thing running under this new service account) will be able to access the files.

  • That's interesting. What versions of Windows support this? Is the data in that service account then accessible only to a single application? (And the system admin, of course, which may also be a problem but let's ignore that for the moment.) In other words, is it possible to write a new malware program, install it as the OS user who normally uses my application, and have that malware program access the encrypted data of my application? – Brian White Jan 27 '13 at 19:15
  • If the malware has admin rights, it can do **anything**, and no matter what you do, it can be made able to read your data. If it doesn't have admin rights, the data should be secure. – Jan Schejbal Jan 28 '13 at 13:52
  • Even local-user malware can install a keylogger and get the access password (or even more-sensitive information). I'm not trying to protect against an ongoing attack. Once the program is closed, however, it must not be possible for anyone, even an administrator of the machine, or any program to be able to read the data. – Brian White Jan 29 '13 at 16:02
1

Have you considered storing the files in an encrypted archive, such as a zip file? Not knowing what language you're working in makes it difficult to give a more specific answer.

Jim Nutt
  • 1,736
  • 12
  • 10
  • C++. I really need all the access a true filesystem provides such as random-access read & write. I'll update the question. – Brian White Jan 18 '13 at 18:45
1

I am not an expert but I have a few suggestions,
('user' is considered Male here)

In Windows, when an user is logged in, he will have all the rights to manipulate a file or folder which belongs to him.
But, if he tries to manipulate files or folders which belong to other users, he is not allowed to do so. So, he can't manipulate other user's files.
If the user is administrator, he will have all the rights to manipulate the file.
In your case, I believe the user is not administrator.

So, I suggest to you to:
Create a user for this application, say Bob(Bob is not the user who is going to use this application).
Then you create a folder to store your files and give all permission only to Bob(and the admin).
For all others, there no permission to do anything to the folder.
Your application must be installed by administrator.

When you start, Your application asks Bob's password from current user.
If the password is correct,
Using your application allow full access folder permission to the current user. Then application can work as you wish.
If the user quits the application,
Remove all permission for current user so that after quitting this application others can't access that content.
But Administrator can still access this content.

This is similar like Linux user management.
When you are getting a shell you can change user using su username when finishes the work and he quits the shell then others can't use those files. But root user can do anything in Linux.

But there is one problem.
Administrator can get full content and access since he can modify the permissions.
To disallow this, save the files by zipping using any technique and by using a password. That password is only known by the user who uses it. Before saving a file to the folder, zip it using a password. Before using the file, unzip it using the password.

If the zipping password is same as user password, then there is a problem.
The administrator can reset user password to something and open his account.
To prevent this you can use the following technique:
Use zip password as reverse of user password, so that if his password is 1234 the zipping password is 4321, or use hash value of user password as zipping password.
If the zip password is hash value like MD5 hash or SHA-1 then brute force on zip file won't work due to the password length.
I don't know if this is a working solution or not or if this can be implemented or not.
But you can take some ideas out of this, if you think there is some good ideas in this.

pradyunsg
  • 18,287
  • 11
  • 43
  • 96
sujeesh
  • 488
  • 2
  • 7
  • 15
  • If we could convince users to actually use different OS accounts, we wouldn't have this problem. People are remarkably stubborn on this fact (not that I blame them -- multiple OS accounts is a pain). Encrypting after-the-fact isn't workable either because simply pulling the plug on the computer would leave it vulnerable, as would the plain-text remnants that would continue on the disk after the move to an encrypted file. – Brian White Jan 24 '13 at 16:55
  • @BrianWhite regarding encryption i have a option. When the user need to access data, change permission of folder, read the file, soon the reading operation completes reset the permission. I don't think reading will take more than few seconds. So i don't think the user will pull the plug before resetting the permission. It's like, if you want to write a file, change permission, write, then reset permission. This won't take much time. – sujeesh Jan 25 '13 at 04:48
  • Any writing of plaintext data to disk is a security problem as the sectors continue to contain the data even if the file is deleted. – Brian White Jan 27 '13 at 19:17
  • @BrianWhite to delete the file properly you can do a simple technique. Before deleting the file fill null character or any other character to the file. Then save it and then delete it. This will help you to delete original data even if you deleted the file. – sujeesh Jan 28 '13 at 04:38
  • That isn't reliable. SSD drives, for example, write new data to new sectors in order to "load balance" the writes. Beyond that, overwriting data does not prevent it being recovered using advanced techniques. And then there is the "window of vulnerability" while the plain-text data is there. – Brian White Jan 29 '13 at 15:56
  • @BrianWhite then try to search for any api or library which will allow you to leave worries about key management and encryption part. But I don't know which tools does that. But surely there will be a tool for that. I don't know this is a tool for that, but i recommend you to have a look at Win32 Crypto API. – sujeesh Jan 30 '13 at 04:43
  • Well... That was my original request -- a library that provides a file-like API for managing encrypted data on disk. My searches have found nothing and, judging from the lack of pointers to such among the responses, I'm guessing that none exist (much to my surprise). The Win32Crypto API encrypts only with the OS user's account credentials, making it insufficient in the case of multiple people using the same OS account. – Brian White Jan 31 '13 at 22:07
  • @BrianWhite I think in windows environment it's difficult to get a api which you are looking for. Apart from Win32 Crypto API i don't know any other. But I will update you if got such api. – sujeesh Feb 01 '13 at 03:59
1

Unless I've missed something in your question, TrueCrypt seems to be an ideal solution for you.

It will allow to:

  1. Utilize existing OS file API (as the mounted volume will behave just like regular volume)
  2. Programmatically manage access key (password)
  3. Limit access to the mounted volume (by OS mechanics)
  4. Utilize same principles on all the platforms (Windows, Mac, Linux)

Or, if you want, you can encrypt/decrypt individual files with it.

There's a number of examples on how to use it around.

DarkWanderer
  • 8,739
  • 1
  • 25
  • 56
  • TrueCrypt is a great product and I use it personally. However, it's not automatic or controllable by an application (i.e. a user has to set it up and manage it manually) and I can't just ship it with our product. That's _more_ work than using separate OS accounts and already I can't get my users to use those. – Brian White Jan 29 '13 at 15:59