Did you *really* zeroize that key?

Trei, Peter ptrei at rsasecurity.com
Wed Nov 6 08:22:50 PST 2002


>From RISKS:
http://catless.ncl.ac.uk/Risks/22.35.html#subj6

Those of us who write code need to be reminded of this 
now and then.

Peter Trei

---------------
Software leaves encryption keys, passwords lying around in memory

       Monty Solomon <monty at roscom.com> 
       Wed, 30 Oct 2002 22:31:46 -0500


         http://online.securityfocus.com/archive/82/297827

       Date: Thu, 31 Oct 2002 05:11:31 +1300 (NZDT)
       From: pgut001 at cs.auckland.ac.nz (Peter Gutmann)
       Subject: Software leaves encryption keys, passwords lying around in
memory

       The following problem was first pointed out (in private mail) by
Michael
       Howard from Microsoft.  His writeup is now available at
 
http://msdn.microsoft.com/library/en-us/dncode/html/secure10102002.asp.
       From a representative check of a few widely-used open source crypto
       programs, this affects quite a bit of software.

       The problem he points out is that clearing sensitive information such
as
       encryption keys from memory may not work as expected because an
optimising
       compiler removes the memset() if it decides it's redundant.  Consider
for
       example the following:

       int encrypt( const void *key )
         {
         puts( key );     /* Normally we'd encrypt here */
         }

       void main( void )  /* Because we can */
         {
         char key[ 16 ];

         strcpy( key, "secretkey" );
         encrypt( key );
         memset( key, 0, 16 );
         }

       When compiled with any level of optimisation using gcc, the key
clearing
       call goes away because of dead code elimination (see the MSDN article
for
       more details on this, which uses VC++ to get the same effect).  While
you
       can kludge enough stuff around a custom memory-clear call to fool the
       optimiser (hacks with 'volatile', touching the memory after it's
cleared and
       hoping the optimiser is fooled, etc etc) there's no guarantee that
it'll
       work for anything but the compiler(s) you happen to test it with -
any
       future enhancement to the optimiser may turn it back into a nop.
What it
       really needs is the addition of a #pragma
dont_remove_this_code_you_bastard
       in the compiler.  Until then, a lot of security code will be affected
by
       this problem.

         [In RISKS, I tend never to alter British spellings.  However,
         in American English, an "optimiser" must be the ultimate miser.]





More information about the cypherpunks-legacy mailing list