Re: Security of data in memory

From: Peter Jeremy (peter.jeremy@alcatel.com.au)
Date: 12/27/01 

Date: Fri, 28 Dec 2001 09:58:38 +1100
From: Peter Jeremy <peter.jeremy@alcatel.com.au>
To: Nicholas Brawn <ncb@pobox.com>

On Wed, Dec 26, 2001 at 12:31:16AM +1100, Nicholas Brawn wrote:
>I have a unix program that reads in an encrypted file, decrypts it and
>works on it whilst in memory. What security considerations should I be
>aware of? I'm thinking of things like clearing the decrypted buffer
>prior to exiting, not storing any of the data in a temporary file, etc.

In no particular order, the things I can think of are:

The decryption key is at least as valuable as the decrypted file.
You need to ensure that the buffer used for the key is also wiped.

Any process with /dev/mem (or /dev/kmem) access could access the
decryption processes memory. These devices are usually readable
by a non-root group (eg kmem).

If you don't lock the process in memory (eg mlock(2)), sensitive data
will wind up in the swap device. The disadvantage is mlock is usually
restricted to root. Some OS's (eg FreeBSD) don't maintain a permanent
association between VM and swap pages[1]. In this case, over-writing
the buffer in RAM will still leave sensitive information in the freed
swap pages. Even where there is a permanent associated between VM and
swap, wiping the page and then exiting will probably leave the old
(sensitive) information in the newly freed swap pages (because there's
no reason to write the newly dirtied page if the process has exited).

[1] Once a page is dirtied, any existing backing page is released.
    If the page needs to be paged out, a new swap page will be
    allocated.

Peter

Relevant Pages

  • Re: MC2
    ... round) ... R = swap ... Decryption: ... x, y, z, temp, swap - 64-bit integer variables ...
    (sci.crypt)
  • Re: Is it possible to encrypt without a key ?
    ... Even if your viewer application decrypts the data into memory (NOT ... Given that the decryption program, and any needed key, is contained ... hardware and operating systems. ...
    (sci.crypt)
  • Re: Where to find the dlopen() source?
    ... and will waste a lot of memory. ... Not knowing much about Linux system structures etc. how easy would it be ... What complicates the planned decryption is that the library may end at different logical addresses with different processes. ... tauno voipio iki fi ...
    (comp.os.linux.development.apps)
  • Re: problems with 3des in cbc mode using openssl lib
    ... > the encrypted buffer properly. ... sound like improper handling of the IV during decryption. ... the same IV for each call to decryption, the first block of ... into the next function call to encrypt the next buffer. ...
    (sci.crypt)
  • Re: Swap function driver
    ... 1000 such shuffles -- each one being a 1/2G swap. ... Unless someone proposes a new way to swap memory, ... Having tried some experiments it seems to me that changing the buffer size ... even the cost of allocating a buffer disappears. ...
    (comp.programming)