nCipher Advisory #7: Unexpected copies of imported software keys

[nCipher Support <technotifications () us ncipher com>]

                 nCipher Security Advisory No. 7
       Unexpected duplicates of imported software based keys
       -----------------------------------------------------

SUMMARY
-------

When either the command line utility generatekey or the KeySafe
graphical application is used to import a software based key into
an nCipher nShield or nForce hardware security module, the key is
successfully imported.  However copies of the original key file are
incorrectly left on the host file system.


BACKGROUND
----------

nCipher provides tools to support importing software based keys
into an nForce or nShield hardware security module.  This operation
is not usually recommended, since:

* It cannot be known whether the key has already been stolen through
  a compromised host, prior to the key import procedure.

* It is hard to securely delete all copies of the software based
  key from host memory and file system.  Computer systems routinely
  copy and store the data they are processing, including software
  based keys, in ways that are difficult to trace and control.

* The properties of the random number generator used to generate the key
  may be poor.

However it is recognised that some customers require existing
software based keys to be imported into an nCipher module to reduce
the risk of a future successful attack, without revoking and replacing
these keys.


ISSUE DESCRIPTION
-----------------

1. Cause
--------

While importing a software based key into a security world the
generatekey utility makes temporary copies of the source key contained
in the specified PEM file in order to convert it into DER format
ready for importing onto an nCipher module.  However, the software
fails to delete the temporary copies of the source key and leaves
them on the file system after the key has been imported into the
module.

The KeySafe graphical utility uses generatekey, and is therefore
also affected by this problem.


2. Impact
---------

After a successful import operation two additional copies of the
key are left on the file system in files named key.pem and key.der
in the current directory.

If these files are not deleted manually by the operator then these
copies may be found by an attacker if the security of the host is
compromised.


3. Who Is *Not* Affected
------------------------

You are *not* affected if:

* You have never imported a software based key contained in a
  PEM file into an nCipher module.

* You have only used generatekey or KeySafe to generate a new key within
  an nCipher module.

* You have only used a third party application to generate a new key
  within an nCipher module.

* You have only ever imported a software based key contained in a
  PEM file using nCipher support software from CD version 7.00 or
  later.


4. Who May Be Affected
----------------------

The bug exists in all versions of generatekey that is supplied with
the nCipher support software earlier than CD version 7.00.

You *are* affected if you have at any time imported a software based
key contained in a PEM file using generatekey, KeySafe or a custom
kmjava application which uses the AppKeyGenerator or KeyGenerator
classes, and have not taken steps to remove temporary key material
from your host.


5. How To Tell If You Are Affected
----------------------------------

Search the contents of the file system, and backups as necessary, of
any host which may have been affected.  Search for files named key.pem
and key.der.  Any such file may be the result of the vulnerability
described here; alternatively, it may be a different key legitimately
held in software, or a key indicator file containing only a reference
to the filename of a key previously imported.

For information on key indicator files please refer to nCipher
product documentation.

Note that you may have multiple key.pem and key.der files in different
directories if you have imported multiple keys.  Only the most
recent key.pem and key.der will remain in any one directory.

nCipher supplies a utility, `pubkey-find', which can parse and describe
RSA private keys stored as (unencrypted) files in .pem format.  If
you would like to use the pubkey-find utility, and it is not installed
on your host system, please contact nCipher Support.

For each key.der file, convert it to a .pem file by running
   /opt/nfast/bin/openssl rsa -inform der -in key.der -outform pem -out k.pem
 or
   c:\nfast\bin\openssl rsa -inform der -in key.der -outform pem -out k.pem

and then run pubkey-find on the resulting k.pem file:

   /opt/nfast/bin/pubkey-find k.pem
 or
   c:\nfast\bin\pubkey-find k.pem

For each key.pem file, run
   /opt/nfast/bin/pubkey-find key.pem
 or
   c:\nfast\bin\pubkey-find key.pem

pubkey-find should produce one of the following sets of output:

 *  $ /opt/nfast/bin/pubkey-find key.pem
     PEM `key' file really contains only key indicator
     input format privkey
     nCore hash 0ac165c1ab77613e7d5387365b10098b298b9074

     name `www.example.com'
     appname embed
     ident 15b939a2d275f8ec6c3bd9c3381455619ee18b53
    $

      This indicates that the file does not contain a private key.
      It is one of the intended results of importing or
      generating a key for use with OpenSSL-based applications, namely
      the key indicator file containing the key identifier.  This file
      is *not* the result of the vulnerability discussed here.

 *  $ /opt/nfast/bin/pubkey-find key.pem
     input format privkey
     nCore hash c1021d41ca85a8fdde67fedbd4cb95faa931e458
     no matching key in current security world host data area
    $

      The key is an unprotected private key, but there does not
      appear to be a hardware-protected key with the same value in
      the current security world.  Perhaps the key is a test key
      or other irrelevant key.  Perhaps it is an important key which
      was imported using this system but whose hardware-protected
      copy has been moved to another host.  If in doubt consider
      the history of the computer system, the filesystem area in
      which the file was found, and the file timestamps.  If you
      cannot satisfy yourself that the file is not relevant, assume
      that it is the result of the vulnerability and consult the
      remedies below.

 *  $ /opt/nfast/bin/pubkey-find key.pem 
     input format privkey
     nCore hash 5323e16eeadaf7b5795dd8677d9ed741342e3f65

     name `name'
     appname ssleay
     ident 1cc01592072c518368cf1c84117dcac91159b086
    $

      This indicates that the file contains a private key, but that
      there is also a copy of the key stored protected by the HSM in
      the security world.  This key.pem file is a result of the
      vulnerability.

 *  $ /opt/nfast/bin/pubkey-find key.pem 
    could not parse input
    $

      The input file is not a PEM-format unencrypted RSA private key.

      Firstly, check that it is not a .der file.  If it is a .der
      file, run openssl as above to convert it to a .pem file first,
      and then run pubkey-find.

      Secondly, it may not be an RSA key.  Examine the first line of
      the file.  For an RSA key, it will be:
          -----BEGIN RSA PRIVATE KEY-----
      If the key is for another algorithm, eg
          -----BEGIN DSA PRIVATE KEY-----
      then the key is not the result of the vulnerability discussed
      here.  If in doubt, consult nCipher Support.

      Thirdly, it may be encrypted.  Examine the first few lines of
      the file.  If they look like this:
          -----BEGIN RSA PRIVATE KEY-----
          Proc-Type: 4,ENCRYPTED
          DEK-Info: DES-EDE3-CBC,BA26229A1653B7FF
      then the key is encrypted.  Encrypted key files are *not* the
      result of the vulnerability discussed here.

      If you cannot establish what the file contains, consult nCipher
      Support.  Do *not* send nCipher Support any .pem or .der files
      as these may contain sensitive key material !


REMEDY
------

nCipher recommends that customers avoid importing software based
keys if at all possible.  Customers who have previously imported
software based keys may wish to review their original decision, and
consider revoking and generating new keys.

If this is not feasible, best practice with any key import would
be to completely erase, using specialist third party tools, all
computer systems and any media which have processed and may contain
the software based key material.  However, this is frequently
impractical.

In this case, you should delete any key.pem or key.der file which you
have identified as containing a key which you have imported into an
nCipher module, and any k.pem file created as part of the analysis,
above.  The key should be deleted from the following places:

    * Any live host file system
    * Any spare or redundant file systems
    * Any backup media that are not stored securely
    * Any legacy systems that contain the key

Customers should be aware that securely deleting files from file
systems is generally difficult, and should seek expert operating
system specific advice if in any doubt.


SOFTWARE DISTRIBUTION AND REFERENCES
------------------------------------

The current maintenance release of nCipher support software (CD
version 7.00 or later), contains an updated version of the generatekey
program.  This version will attempt to remove any temporary files
that are created during the import process, using standard operating
system facilities.  However, since the underlying physical media
may continue to contain the imported key material, use of this
version does *not* eliminate the security vulnerabilities associated
with importing keys.  This version does *not* check for or remove,
any key.pem of key.der files that remain from earlier import
operations.

You can obtain copies of this advisory, and any supporting
documentation, from the nCipher updates site:

    http://www.ncipher.com/support/advisories/

Due to export control regulations, we are unable to make the updated
software available on the web site.  Please contact nCipher Support
who will advise you on obtaining updated software, either via
Internet download or on CDROM.


NCIPHER SUPPORT
---------------

nCipher customers who require support or further information regarding
this problem should contact support () ncipher com.

nCipher Support can also be reached by telephone:

    Customers in the USA or Canada:   +1 781 994 4008
    Customers in all other countries: +44 1223 723666

Customers in all other countries outside of the USA and Canada can
call the USA number in the event that they receive the advisory
outside of UK support hours (09:00 - 17:30).


Further Information
-------------------

General information about nCipher products:
    http://www.ncipher.com/

nCipher Developer's Guide and nCipher Developer's Reference
    http://www.ncipher.com/documentation.html

If you would like to receive future security advisories from nCipher,
please subscribe to the low volume nCipher security-announce mailing
list.  To do this, send a mail with the single word `subscribe' in 
the message body to: security-announce-request () ncipher com.

(c) nCipher Corporation Ltd.  2003

    All trademarks acknowledged.  nCipher, KeySafe, nForce and
    nShield are trade marks and registered trade marks respectively
    of nCipher Corporation Limited.

$Id: advisory7.txt,v 1.12 2003/02/18 12:08:51 mknight Exp $