Bug: sensitive data written to insecure memory

[Werner Koch]

On Tue, 3 Apr 2001, Andrew Archibald wrote:

> In a number of the cryptographic algorithms (for example, cast5.c and
> rijndael.c) sensitive data are written to temporary variables, which are
> stored on the stack.  The stack does not seem to be locked into physical

We have to distinguish 2 cases:

 a) encryption of user data (i.e. the messages to encrypt/decrypt)
 b) protection of then secret key
 
Because GnuPG can't secure the user data - it is everywhere in the
operating system in files and other memory areas - it has to protect
the session key.  So for a) we have to make sure that at least the key
scheduling is done in secure memory.

b) is different, here our user data is indeed very confidential and
we should try to protect it better.

Locking the stack is not possible (at least with the Linux kernel)
because then gnupg has to be run setuid(root) and can't drop these
priviliges.  And it is hard to do.

Avoiding the use of stack allocated variables is possible but it
has somed drawbacks: 

 * It makes the code much slower.  For secret key encryption this
   might be okay, but the we have to use 2 sets of encryption and
   hash functions.
   
 * We have to change the API to provide memory for local variables
 
 * The compiler might decide to use stack allocated variables for
   optimizing reasons anyway.
   
Given all the problems with the "secure memory" handling, the extra
complexity of the code, the problem of hibernation ("suspend to
disk"), the unavailibilty of "secure memory" under Windoze and many
other systems,  we might come to the conclusion that this design
issue was an error and we should better rely on the OS to protect
the swap space.  OpenBSD has the ability to encrypt the swap space
and Marcus is going to add this to the Hurd, someone should then
fix Linux and the proprietary vendors should provide something
similar - they could just adapt the OpenBSD code.

The concept of secure memory has nevertheless the advantage that it
make ist much easier to burn (set to 0) memory areas with sensitive
data.

What I am going to do is to burn local variables in the hash and
encryption functions, so that the OSes which don't zero out memory
previously used by other processes don't reveal sensitive
information.


  Werner








-- 
Werner Koch        Omnis enim res, quae dando non deficit, dum habetur
g10 Code           et non datur, nondum habetur, quomodo habenda est.
Privacy Solutions                                        -- Augustinus