4

The scenario is as follows: an encryption key should be stored temporarily, so that multiple instances of an application can access it (sequentially). After use, the key should of course be removed from the system. However, this imposes a problem. I accept that the system is vulnerable as long as the key is stored, but I want the system to be secure before and after the key is stored.

Simply writing the key to a file and overwriting it afterwards will not work in all cases: some filesystem write changes to different parts of the disk, instead of to the same location. In that case, the key can still be retrieved afterwards. I cannot rely on the user having full-disk encryption.

Then the most logical option seems to use an other process that keeps the key in memory, but the operating system might write the memory to the disk at certain points, resulting in the same problem as described above.

Encrypting the key is possible, but this is not more secure. The whole point of storing the key temporarily, is that the user need not type it in for every run of the program. This means that the key used to encrypt the key must also be stored somewhere, or it must be based on known data. If the key is stored, then of course we now have the problem of securely storing this key. If it is based on known data, that means the key can be generated again when necessary, so encryption has little use.

I know some operating systems offer APIs to protect data, but this usually relies on generating an encryption key based on the user account information. Even if this is session-specific, the data will not be secure until the session ends (which can be long after the key should be erased).

Is there any solution to this problem at all (that does not rely on special hardware, does not require full-disk encryption, etc.)? If there is not, what is the best I can do in this case?

Edit for clarification: The key need not be secure when it is stored in memory; at this point, the user should guarantee that no physical access is possible, and that the system is free of viruses. After the key has been used, it should be erased from the system, such that afterwards anyone with physical access, or any program, can inspect all memory and disks, and not find a single (usable) trace of the key any more.

Ruud
  • 3,118
  • 3
  • 39
  • 51
  • Unless you can go all the way to a FIPS-140 cryptomodule, these are very tough problems to solve. Generally, the first step to dealing with security issues is to decide what kind of attackers you're trying to defend yourself from. Do they have physical access to the system? How much time do they have? How much money do they have? You're not going to be able to defend your product from somebody that has physical access to the machine and all the time they like using only software, but you may be able to identify a viable solution if you set your sights a little lower. – tbroberg Jul 14 '12 at 21:59
  • An attacker might have physical access, but only before the key is stored and after the key has been removed. Time and money will generally be limited, but I would like to have a solution that is safe regardless of who the attacker is. I found that it is possible to prevent swapping on Windows using `VirtualLock` and `mlock` on Linux. This is a good starting point, but how would I securely communicate between the processes? – Ruud Jul 15 '12 at 08:53
  • So, the usage case is: A) The room is purged of all bad guys. B) User logs in with a password. C) User does stuff while logged in and various processes use the key contents. D) User logs off and all vestiges of the key(s) are destroyed. E) Bad guys reenter the room and scour the machine for clues to the key. We're allowed to make the user enter a password once. The objective is to make absolutely sure that the key is expunged before the bad guys arrive in E). Right? – tbroberg Jul 16 '12 at 04:23
  • If I'm were your bad guy, I would try to attack not the key, but the point where the key is validated. I would examine the code, find the branch instruction right after it checks the key and modify it to always accept the key unconditionally. It's *really hard* to defend against somebody with time on his hands who has physical access to the machine. Efforts to secure the system then become an exercise in obfuscation to make it more difficult to find the key and where it is validated. – tbroberg Jul 16 '12 at 04:37
  • What do you mean by make the user enter a password once? The user enters his password once (to generate the key) when the room is free of bad guys; your usage case is correct. However, the key is not used for validation, but to decrypt/encrypt data. (Of course this data should be secured in the same way as the key; the ultimate goal is to hide this encrypted data from the bad guys.) However, the encrypted data can be handled in one process, so everything can be handled in memory. – Ruud Jul 16 '12 at 07:52
  • I didn't understand initially that part of the key was stored off-system in a user's head, which definitely simplifies things. Thanks for clarifying. – tbroberg Jul 16 '12 at 07:54

1 Answers1

6

You could use ramdisks (not tmpfs). See http://www.kernel.org/doc/Documentation/filesystems/tmpfs.txt:

"Another similar thing is the RAM disk (/dev/ram*), which simulates a fixed size hard disk in physical RAM, where you have to create an ordinary filesystem on top. Ramdisks cannot swap and you do not have the possibility to resize them."

So basically, you need to create a filesystem on /dev/ram* and then mount it somewhere. However, this mount point can then be accessed by all processes, not only specific ones.

PhilMasteG
  • 3,095
  • 1
  • 20
  • 27
  • This is a very interesting solution. Public access is not a very big problem; memory can be accessed by other processes as well; one can only make it hard for them to access it. Do you have any idea how to achieve the same effect, with no-swap guarantee, on platforms without ramdisk support (like Windows)? – Ruud Jul 18 '12 at 17:59
  • 2
    Well... I believe, you could (theoretically speaking) write a dummy hardware driver, which is then loaded to RAM and as such not swapped. However, the key would have been stored in that driver files. So you'd need to write a dummy driver you can communicate with to read/write the key. I have no concrete knowledge of windows' memory management internals though. – PhilMasteG Jul 20 '12 at 15:53