Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

I saw that KeePass not only encrypts its password-database-file, it also can encrypt the passwords it holds in memory. This is just an example. I thinking of a new project dealing with sensitve / personal data and now I ask myself if I should encrypt the data hold in memory, too. This project would be implemented with Java SE and an additional android application. There will be no data stored in the cloud or on a server in this special case. Data from android will be imported by the Java SE Desktop application via cable connection.

But why is this necessary at all? Don't modern operating systems work with virtual memory management so that it is not possible for user-space / user-mode processes to access other processes memory?

Is it just another defense line if there is an OS vulnerability making foreign memory access possible? In that case I think it would be much easier to steal the data file and use a key-logger to catch the password the user enters instead of stealing the data through memory access.

share|improve this question

migrated from stackoverflow.com Sep 18 '12 at 12:16

This question came from our site for professional and enthusiast programmers.

1  
The problem with encryption is that it only shifts the problem to where to store the key. –  CodesInChaos Sep 18 '12 at 8:47
1  
Data may be swapped out to the page file, and many OS do not clear the page file when shutting down. With physical access to the machine the page file can be easily accessed and searched (and there are ways to make it more likely that data of intrest is swapped out, and then one could pull the power cord to prevent the OS from shutting down...). Still, in memory encryption only makes it more work to access the encrypted data, since the code and key to decrypt it can be obtained by the same method... –  Durandal Sep 18 '12 at 11:21

4 Answers 4

In a perfect world, you are right: there should be no point in keeping data encrypted in RAM. The OS should keep strong separation between processes, clear RAM when it is reallocated to another process, and, if the attack model allows for an attacker stealing the device afterwards and doing some harddisk analysis, encrypt the swap (or use no swap at all, which may make more sense for a device with Flash-based storage).

In a realistic world, where operating systems and system administration are human endeavours and thus inherently non-perfect, you might want to add some safeguards, including keeping data encrypted in RAM and instructing the OS not to write data in swap space (on Unix-like systems, this is done with mlock()). Still, this encrypt-in-RAM things is more a psychological ritual than a true defense; its main virtue is in making the developer feel better.

Don't bother with doing that in Java, anyway. The garbage collector will copy objects in RAM transparently (this is part of the most efficient GC algorithms and you cannot prevent it) so no level of encryption by your application will guarantee that no clear version of the keys exist in RAM at any time.

share|improve this answer

Modern operating systems work with virtual memory management so that by default it is not possible for user-space / user-mode processes to directly access other processes memory.

But in Windows (don't know if this apply to Linux, too) there are interfaces that allow standard users to access the process memory of other processes running with the same credentials.

There are many programs that use this interface. A very simple example is HxD - a freeware hex editor that allows to view and even edit the process memory of other processes.

share|improve this answer
1  
But encryption doesn't help here, since you can use the same API to read the key. These memory APIs are also restricted, so only sufficiently privileged processes can read the memory of another process, by default they need to run on the same user, or be an admin. –  CodesInChaos Sep 18 '12 at 13:40
    
You are right, in that case it is only for obfuscation purposes. –  Robert Sep 18 '12 at 14:06
    
In Linux you can do this by reading /proc/$pid/mem (as the process you want to read, or root). –  Brendan Long Sep 18 '12 at 15:58
    
@CodesInChaos, doesn't this only apply to keys stored in ram? If a generated key is used, for which only some sort of initialization vector exist in memory it would not be easily visible. But this still tend to be obfuscation only. I agree –  Samuel 7 hours ago

Memory can become visible to other processes by:

  1. being available once the original process using it has returned it to the OS. Memory isn't cleared and a successive process could perform a malloc() and retrieve info belonging to a previously running process (note chapter 8 of Linux Device Drivers - particularly the footnote on the first page)
  2. pages being swapped out to disk by the OS. These can then become available to a process watching the disk/storage.

Consequently unencrypted memory can become visible to other processes.

This is a very interesting link, and note this quote:

This volatility depends greatly on the computer in question, however - for when a computer isn't doing anything anonymous memory can persist for long periods of time. For instance in some computers passwords and other precalculated data were easily recovered days many after being typed or loaded into memory

share|improve this answer
1  
Can you name a modern OS that has property 1? Windows NT does clear the memory before handing it out again. Property 2 requires admin privs, so you should not worry about other processes doing this, but about data remaining on the disk after the program terminates or the system restarts. –  CodesInChaos Sep 18 '12 at 8:40
    
I don't know about Windows NT, but I wouldn't expect Linux to return you a cleared memory block from malloc() or sbrk() –  Brian Agnew Sep 18 '12 at 8:41
    
I know attributes of Java objects are cleaned / initialized at instantiation time. But what after memory release / JVM termination. Will there be a cleanup? –  user573215 Sep 18 '12 at 8:53
3  
malloc might reuse memory used by the same process earlier without clearing it. But an OS reusing uncleared memory across processes seems very dumb. –  CodesInChaos Sep 18 '12 at 10:02
2  
The link talks about kernel memory. Memory allocations of usermode processes are something different entirely. –  CodesInChaos Sep 18 '12 at 11:17

There are some issues that are specific to the Java world that you have to consider. It is a normal practice that one makes heap dumps of the JVM if a technical issue rises. I'm dealing with an app that even has a dedicated UI for that. This might be incredibly valuable e.g. for finding memory leaks. And sure - yeah - the sensitive information goes into the dump. So if someone breaks in the app (e.g. bypasses the login with an SQL Injection :) )... :X. Or if the administrative user is a curious person ... :X

I know that this should not happen in the "ideal world".

Also you may configure the JVM to make a dump on out of memory exceptions. Since Java 1.4 this might look like this:

-XX:-HeapDumpOnOutOfMemoryError  -XX:HeapDumpPath=<path to dump file>

An attacker may find an exploit that makes the app crash with out of memory and may find another exploit (e.g. file path traversal bug) to steal your dump!

The other thing that you should think about is that some sensitive data will have to make its way into your app somehow. So in certain moments you'll have it in memory. There is little or nothing you can do about it. But what you can do is to clean it faster. For example take a user password. If you store it in a String instance then you do not have much control on when it will be garbage collected. Thus usually nice API-s do process such data in character arrays (char[]) that can be zeroed after usage.

share|improve this answer
    
Can you tell me the Java language specification part where it is said that writing to a char[] actually performs the writes in-place? –  user1050755 Mar 19 at 10:58

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.