From: Nicholas Brawn <ncbpobox.com>

> 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.

Gutmann's article is still the best I know of.

Prevent core dumps too: http://www.fish.com/security/murphy.html

There is this little work of mine from 2 years ago.

-----BEGIN PGP SIGNED MESSAGE-----

Peter Gutmann has an article describing the problems of data deletion.
    Secure Deletion of Data from Magnetic and Solid-State Memory
    first published in the Sixth USENIX Security Symposium
    Proceedings, San Jose, California, July 22-25, 1996
    http://www.cs.auckland.ac.nz/~pgut001/pubs/secure_del.html

The difficulty in deleting sensitive data such as private keys
after storage on disk or in RAM has implications for systems
at risk from hostile physical access.

Servers such as remailers could keep their private keys on
ramdisk and aim to run as long as possible between reboots.
They could generate a new RSA key pair at each boot and
publish the public key (signed with a non-volatile key).
Other desirable features are a swapless configuration to keep
private keys off disk and resistance to logical intrusion to
prevent key compromise by that route. None of the above address
the peristence of data in memory chips. Gutmann suggested
flipping the bits every second or so.

I have recently produced a patch for linux 2.2.12 to make
"volatile shared memory". This allows programs to store data
such as private keys in kernel memory where the bits are flipped
periodically by the scheduler.

There is a new system call (do_vshm) to use this memory. A single
block of memory of size VSHMSZ (=1024) bytes is supported for each
user account (and, apart from root's, only allocated if it is used).
Users can only acess their own block, and can do the following
operations.

    0 seed (or reseed) the LSFR used in bit flipping
    1 store data
    2 retrieve data
    3 destroy all VSHM data (root only)
    4 destroy your own VSHM data

The vshm structure used has 3 blocks of size VSHMSZ. Two of these
are maintained to keep their XOR holding the desired data. The
scheduler XORs both of these against the same stream of varying data
approximately every 2/3 second. The other block is a shift register
used to generate the stream for those XOR operations.
When storing data the shift register is automatically initialised if
it contains zeros. As with ordinary shared memory you can use it to
communicate between processes. I envisage a remailer being run in
its key-generation mode at boot-time and storing the private key in
vshm. Later executions of the remailer to handle incoming mail would
retrieve the private key (and destroy their userspace copy after use).
At shutdowns and reboots the vshm blocks are wiped.

Performance is not obviously degraded although I have made no measurements.

The patch and an example program will be at
   http://www.notatla.demon.co.uk/SOFTWARE/vshm_lx_2.2.12_patch.asc
in the next hour or so. Any bug reports welcome.

Happy new year to Feds of all kinds.

-----BEGIN PGP SIGNATURE-----
Version: 2.6.3i
Charset: noconv

iQCVAgUBOHEr0ErZ5ZQH9XIxAQHHRgQAj4KRqVVX98/Km0cKE+PG96CsedO0r7nc
FkOKuLx9sGbHIfOivC8qTtlxgrBoHgCpePqiKJYLd0Qe36y07LPOpKqq6IKUupCF
0QwNPOIey7XJJ0turV56tZTPWdBvcfIPBVy7Y/ZKHQFg6+FQplVkO6oR3yejAEJf
7rIXgBbVUQE=
=ah41
-----END PGP SIGNATURE-----

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]