How should a front-end handle a stored passphrase

David Shaw dshaw@jabberwocky.com
Thu Jan 17 05:58:02 2002


On Wed, Jan 16, 2002 at 07:40:05PM -0800, elf@florence.buici.com wrote:
> I am revisiting a program I started about three years ago.  As it may
> sign more than one file during an execution run, it asks the user to
> enter the passphrase which it later passes to gpg using a file
> descriptor.  The descriptor prevents the passphrase from appearing on
> a command line or within a file.  Still, the passphrase is stored in
> memory during program execution.  Is there some precation I should
> take with how it is stored?

The first thing to do is think about your threat model: what are you
protecting against?  This ranges from protecting the user against root
on the same box (pretty much impossible) to protecting the user
against someone on a different box altogether (not nearly as hard).

Think about all the steps that touch on that passphrase.  Can the
keyboard be tapped via X11 or a hardware device a la Scarfo?  Can the
passphrase be read out of /dev/mem?  Is the box physically secure?
Consider each spot and decide what - if anything - you want to do
about it.  It is reasonable to conclude there are certain attacks you
won't address - for example, if an attacker has root on the box you
are running your application on, there is really very little you can
do.

This is not to say that even if there is nothing you can do, you
should actually do nothing.  Doing something even if there are some
attacks you are still vulnerable to raises the bar against attackers
in general, and as such is a good thing.

All that said, to answer your question - while this doesn't protect
you from root, you can take a few precations with the memory the
passphrase is stored in by:

* ensuring that the chunk of memory holding the passphrase doesn't get
  swapped out to disk.  Various Unix-like systems have various
  different ways to lock a chunk in memory.  You might take a look at
  the code in gpg for this - see the file util/secmem.c.

* Disable core dumps, just in case the attacker can make you crash
  with the passphrase in memory.

* When you are done with the passphrase, you can "burn" that block of
  memory, but read Peter Gutmann's comments on this at
  http://www.cs.auckland.ac.nz/~pgut001/secure_del.html

David

-- 
   David Shaw  |  dshaw@jabberwocky.com  |  WWW http://www.jabberwocky.com/
+---------------------------------------------------------------------------+
   "There are two major products that come out of Berkeley: LSD and UNIX.
      We don't believe this to be a coincidence." - Jeremy S. Anderson