nCipher Support
21/12/02, 01:46
nCipher Security Advisory No. 6
Access control defects in PKCS#11 keys
--------------------------------------
SUMMARY
=======
As a function of internal QA testing, nCipher has identified that,
under certain unusual circumstances, keys created by the nCipher
PKCS#11 library, which should be secure, may be exportable from the
hardware security module in plaintext or equivalent, or have other
defects in their access control.
nCipher believes that only a very small number of installations may
be affected. Whether a key is affected depends on the application,
the version of the nCipher PKCS#11 library in use, and the system
configuration.
nCipher is providing tools, in an accompanying patch kit, that
allows customers to check their current access controls, in order
to affirm that their keys are not vulnerable in unexpected ways.
The detailed advice below allows a customer to first determine if
their particular circumstances expose them to this problem, and if
the customer concludes a vulnerability exists, explains how this
can be eliminated.
ISSUE DESCRIPTION
=================
1. Problem
----------
nCipher modules can be used from a number of industry standard
APIs. Among these, nCipher supplies a cryptographic library that
is compatible with the RSA Laboratories PKCS#11 Cryptographic Token
Interface Standard (Cryptoki).
The nCipher PKCS#11 library translates calls from the PKCS#11
Standard API to underlying nCore primitives. The interpretation
of PKCS#11 calls and attributes from the standard, and the mapping
to the underlying nCore API, is extremely complex.
nCipher is issuing this advisory in response to implementation
errors found in the nCipher PKCS#11 library. However, differences
in interpretation of the PKCS#11 standard between nCipher and
application vendors, and potentially, errors in applications, can
also cause keys to have incorrect or unexpectedly weak protection.
2. Impact
---------
If a key is improperly secured then in the worst case, an attacker
who can issue commands to any module in the same Security World,
and can obtain a copy of current or old host-side Security World
data, can obtain the key plaintext from the module.
This may apply to existing keys, or to newly-generated keys.
3. Who May Be Affected
----------------------
All installations which use the nCipher PKCS#11 library are potentially
affected. Installations that do not use the nCipher PKCS#11
implementation are NOT affected.
You are NOT affected in the following situations:
* The following applications are NOT affected because they do
not integrate with nCipher products via PKCS#11:
Apache
IBM Websphere (using BHAPI interface only)
iPlanet Proxy Server
Microsoft Exchange Server
Microsoft Internet Information Server (IIS)
Microsoft ISA Server
Microsoft Windows 2000 Certificate Server
Netscape Enterprise Server 3.x (but iPlanet may be affected)
Stronghold webserver
Tivoli Access Manager, Web Seal version 3.9
Oracle 9i R2 Database Advanced Security Option
* Applications written using the following APIs are NOT affected:
nCore/NFKM (previously known as `the nFast API')
CHIL (also known as `hwcrhk')
Microsoft CAPI
OpenSSL
BHAPI
nCipher supplied JCA and/or JCE providers
* The nFast 800 or previous nFast products which provide only
acceleration and do not support key management are NOT affected.
(Note that the name `nFast' has been used in the past to refer
to key management products.)
If you cannot rule out the possibility that you may be affected,
you should obtain the patch kit and perform the test, below.
4. Obtaining the Patch Kit
--------------------------
You can obtain copies of this advisory, and supporting documentation,
from the nCipher updates site:
http://www.ncipher.com/support/advisories/
We regret that due to export control regulations, we are unable to
make the patch kit available on the web site. Please contact nCipher
support who will advise you on obtaining the patch kit, either via
Internet download or on CDROM.
The patch kit is available for the following platforms:
AIX 4.3.3
AIX 5L (32 bit only)
HP-UX 10.20 / HP-UX 11
Linux libc6 / Linux libc6.1
Solaris 2.6 / Solaris 2.7 / Solaris 2.8 / Solaris 2.9
Trusted Solaris 2.8
Windows NT 4 / Windows 2000
Customers using other platforms should contact nCipher support.
5. Contents of the Patch Kit
----------------------------
The patch kit contains:
* This advisory `advis6.txt' and supporting documentation.
* A platform specific `read-me.txt' file that contains detailed
patch kit installation instructions.
* Tool for finding private keys from X.509 PEM format files:
pubkey-find
* Updated tool for checking key generation certificates and current
security properties of keys:
nfkmverify
* Updated `with-nfast' utility.
* Updated `postrocs' utility.
* Specially prepared vulnerability check and fix program:
ckfixsecure
* Tools for transferring keys between security worlds:
mk-reprogram and key-xfer-im
These tools are documented in `kmigrate.txt'.
6. 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 GMT).
How To Tell If You Are Affected
===============================
If you have existing keys and have not ruled out the possibility
that you may be vulnerable, perform the steps below for those keys.
Before proceeding you must follow the earlier guidance on obtaining
the patch kit, and install this in accordance with the enclosed
`read-me.txt' installation instructions.
If you are generating new keys, and have not ruled out the possibility
that they may be generated vulnerable, perform the steps below after
generating the key(s) but before putting them into service. For
example, with an SSL webserver, perform the test below after
generating the key but before sending your certificate request to
your certificate authority.
i. Establish the identity in your Security World of the long-term
key(s) which are important to your installation:
* If you are using an SSL/TLS/HTTPS webserver, a certificate
authority, or another X.509 certificate based application,
the relevant keys can be found from your X.509 certificate(s)
using the nCipher-supplied pubkey-find utility.
For each key, put the certificate, or your certificate request
or self-certificate, in PEM format in a file. Assuming
you have named the file `certificate.pem', then run:
/opt/nfast/bin/pubkey-find certificate.pem
or
c:\nfast\bin\pubkey-find.exe certificate.pem
This will report the `ident' of the corresponding private
key.
* If you are using another application, nCipher recommends that
you assume that all long-term key(s), stored via the PKCS#11
interface by your application, are important. In cases of
doubt, the `cklist' and `nfkminfo' utilities, and the
`pubkey-find' program supplied with this advisory, may be
of use.
In this case, use the command:
/opt/nfast/bin/nfkminfo -k pkcs11
or
c:\nfast\bin\nfkminfo -k pkcs11
which will list the idents of all PKCS#11 objects in your
Security World, in the form:
AppName pkcs11 Ident <ident>
Note that some PKCS#11 applications will create temporary
key(s), and other keys which do not require long-term
protection by the module, as long term keys to be stored by
the PKCS#11 library. Customers for whom this is true will
be identified by nCipher Support, according to the process
below.
ii. Check whether the key(s) are affected by the problem:
For each <ident>, run:
/opt/nfast/bin/nfkmverify -U pkcs11 <ident>
or
c:\nfast\bin\nfkmverify.exe -U pkcs11 <ident>
If nfkmverify produces a report of the protection status of
the key, the key is properly protected. Confirm that the
protection details are correct. In particular, check that
the key is protected by the correct operator cardset.
nfkmverify may also report discrepancies and problems in a
number of situations:
UNVERIFIED SECURITY WORLD !
This indicates that the Security World was generated
by older nCipher software which did not store a signed
audit trail of the Security World generation. With
respect to the detection of problems with the PKCS#11
library, this is not an issue, since the PKCS#11 library
is not involved with Security World creation.
PROBLEM: application key pkcs11 ...: no key generation signature
This indicates that the application key was generated
by older nCipher software which did not store a signed
audit trail of the key generation. Alternatively, the
object may not be a key at all, since PKCS#11 provides
for the storage of data as well as keys.
If you get this message, firstly check that the object is
actually a key. Run:
/opt/nfast/bin/nfkminfo -k pkcs11 <ident>
or
c:\nfast\bin\nfkminfo.exe -k pkcs11 <ident>
Look for the `protection' near the top of the output. If
you see:
protection NoKey
the object is not a key and therefore cannot be insecure
and is not affected by the issues discussed in this
Advisory.
If you see:
protection CardSet
or
protection Module
then the object is a key. You must check that the key,
including its key recovery information, is correct.
Run these two commands:
/opt/nfast/bin/with-nfast -A pkcs11 -K <ident> \
/opt/nfast/bin/nfkmverify -U -L pkcs11 <ident>
/opt/nfast/bin/with-nfast --admin r \
/opt/nfast/bin/nfkmverify -U -R pkcs11 <ident>
or these two:
c:\nfast\bin\with-nfast -A pkcs11 -K <ident>
c:\nfast\bin\nfkmverify -U -L pkcs11 <ident>
c:\nfast\bin\with-nfast --admin r
c:\nfast\bin\nfkmverify -U -R pkcs11 <ident>
The first command will need the relevant Operator Cards
and the second will need the Administrator Cards.
Note that you should not insert your Administrator
Cards, nor enter their passphrases, into a module unless
it is attached to a fully trusted host - nCipher
recommends the use of a host not attached to a network.
To confirm that your keys are secure you should now
check that the output is as you expect in both cases.
Other discrepancies and problems
If the key has been the subject of a key transfer between
security worlds, or of an operator cardset recovery,
nfkmverify is expected to report discrepancies, as the
original key generation certificates will no longer
correspond to the current protection status. In this
case, use nfkmverify -R as described above to confirm
that your keys are secure.
If any other discrepancies or problems are reported,
contact nCipher Support. Not all other messages indicate
security problems, but expert advice will be required
to determine whether you are at risk. Please supply
nCipher Support with the complete report from nfkmverify.
If any of the key(s) specified are not fully protected by the
module security mechanisms, nfkmverify will report extensive
details about the affected key(s).
Note that, as stated above, the existence of keys not protected
by the hardware security mechanisms does not in itself
necessarily indicate that your system is vulnerable; it may
be that the unprotected keys are ephemeral SSL webserver
session keys or other keys whose security against attacks
from the local host is not important to the overall system
security.
You must determine whether the extractable key(s) are important.
nCipher recommends that you either assume that all the affected
key(s) are important and attempt to make them secure, or
urgently contact nCipher support for advice.
REMEDY
======
1. Available Remedies
---------------------
A. New keys
After generating any new keys with the nCipher PKCS#11 library,
perform the checks above to determine if they are vulnerable.
If you have just generated keys which, after checking as detailed
above, cannot be determined to be secure, contact nCipher
Support. nCipher Support will advise a configuration change
or workaround to allow the generation of keys that are not
vulnerable. nCipher Support will advise you to discard any
vulnerable keys, or confirm that the reports from nfkmverify
do not indicate a vulnerability.
B. Existing keys
If you have existing keys which have been determined to be
vulnerable, there are three courses of remedial action available.
If you are affected by the problems you should follow one as
soon as possible. The remedies are:
1. Revoke your existing key and generate a new, secure, key.
The key must be revoked at all possible reliers or counter
parties.
2. Generate a new, secure, key, and make the old key unusable.
All modules in your existing Security World will have to be
erased.
3. Correct the protection status of the existing key. You will
have to transfer the key to a new Security World and erase
all modules in the old Security World.
If you can reliably inform all other reliers and counter parties
that your existing key is compromised, you should choose 1.
However, in many applications (for example, in SSL as used for
HTTPS) this is not possible.
Otherwise, you should choose 2 if you can conveniently generate
and distribute a new key, including obtaining any necessary
certificates on the existing key.
If you are not able to prevent reliers using the existing key,
and it is not convenient to generate a new key, choose 3.
The protection status of non-recoverable keys cannot be changed;
if your Security World has recovery disabled, you must choose 1
or 2.
2. Revoking and Generating a New Key
------------------------------------
See `Available remedies', above, regarding the choice of the
appropriate course of remedial action.
i. If you are able to suspend use of the old key, revoke it
immediately by informing the appropriate revocation authority,
or all reliers, in the appropriate way. Note that there is
no effective revocation mechanism for webserver SSL certificates;
for such keys you must choose option 2 or 3.
ii. Generate a new, secure, key, and verify its status (see below).
iii. Test that your application works satisfactorily with the new
key. In case of problems, consult nCipher Support.
iv. Inform all of your reliers or counter parties, including
your revocation authority, of the new key. The details will
depend on the protocol you are using.
3. Generating a New Key and Making the Old Key Unusable
-------------------------------------------------------
See `Available remedies', above, regarding the choice of the
appropriate course of remedial action.
i. If you are able to suspend use of the old key while
implementing the remedy, immediately erase all of the modules
in your Security World. (See instructions for erasing a
module, below.) Whether or not you are continuing operation
with the old key, continue with the remedial action as
follows:
ii. Make a backup copy of your Security World host data directory
/opt/nfast/kmdata or c:\nfast\kmdata.
iii. Generate a new Security World (if the original key is module
protected) or operator card set (if the original key is
cardset protected).
iv. Generate a new, secure, key, and verify its status (see below),
protected by the new world or cardset.
v. Test that your application works satisfactorily with the new
key. In case of problems, consult nCipher Support.
vi. Obtain any necessary certification for the new key and inform
all potential reliers of the new key value.
vii. Put the new key into service.
viii. If you created a new Security World in (ii) above, because the
old key was module protected, erase all of the modules in
the old Security World if you have not already done so.
ix. Keep the old Security World administrator cards, or old
operator cards, in a safe place alongside your (new)
administrator cards. Note that your old operator cardset
should no longer be used as an operator cardset, unless
exceptional access to the vulnerable old keys is required.
4. Securing the Existing Key
----------------------------
See `Available remedies', above, regarding the choice of the
appropriate course of remedial action.
i. If you are able to suspend use of the key while implementing
the remedy, immediately erase all but one of the modules in
your Security World. (See instructions for erasing a module,
below.) Take the remaining module and attach it to a trusted
host, preferably not one connected to a network, and use it
for the next steps. Whether or not you require continuous
use of the key, continue with the remedial action as follows:
ii. Take a backup copy of your Security World host data directory
/opt/nfast/kmdata or c:\nfast\kmdata.
iii. Use the nCipher access-control-list change utility (details
below) to make a secure version of the key and store its
encrypted key blob in your Security World host data directory.
(That is, a copy of the key with a correct, safe, access
control list.)
iv. Generate a new Security World (if the key is module protected)
or operator card set (if the key is cardset protected).
v. If the key is module protected, use the nCipher key transfer
utilities to transfer the modified version of the key from
the old to the new Security World (see below). If the key
is cardset protected, use `rocs' to transfer it to the new
operator cardset.
vi. Verify the protection status of the new key (see below).
vii. Test that your application works satisfactorily with the new
key. In case of problems, consult nCipher Support.
viii. Put the new copy of the key, and the new Security World or
operator cardset, into service.
ix. If you created a new Security World in (vi) above, because the
key is module protected, erase all of the (remaining) modules
in the old Security World.
x. Keep the old Security World administrator cards, or old
operator cards, in a safe place alongside your (new)
administrator cards. Note that your old operator cardset
should no longer be used as an operator cardset, unless
exceptional access to the vulnerable forms of the keys is
required.
DETAILED INSTRUCTIONS FOR REMEDIAL ACTIONS
==========================================
nCipher recommends that you contact nCipher Support if remedial
action may be required, as the operations involved can be very
complex.
Consult the previous section to determine which remedial actions
are required, and in which order they should be performed.
1. Erasing a Module
-------------------
i. Confirm that there are no key(s) in the Security World which you
still wish to use. This will be either because you have
decided to shut down your application while the security is
ensured, or because you have secured your application by
changing keys or security worlds, and wish to put the old
keys beyond use.
(Note that the Administrator Cards can, with the old host
data, be used to once more program a module into the world,
should this be required. Ensure that have your Administrator
Cards and know the passphrases. Note that you should not
insert your Administrator Cards, nor enter their passphrases,
into a module not attached to a fully trusted host - nCipher
recommends the use of a host not attached to a network.)
ii. Fit the initialisation link (internal SCSI units), press and
hold the initialisation switch (external SCSI units), or set
the mode switch to initialisation (PCI units), and then:
iii. reset the unit using the front panel clear switch (SCSI) or the
rear panel recessed clear switch (PCI). The module should
come up into Pre-Initialisation mode, flashing a distinctive
pattern on its LED: repeating a single short flash.
iv. Run:
/opt/nfast/bin/initunit
or
c:\nfast\bin\initunit.exe
If no output is produced the module has been reinitialised.
2. Generating a New Key, Securely
---------------------------------
If you choose to generate a new key as part of your remedy, or as
part of a new installation, you must ensure that it will not be
affected by the original problem.
A version of the nCipher PKCS#11 library which has the original
problems corrected is in preparation. However, at present nCipher
recommends avoiding the use of module-protected keys with the PKCS#11
library. Cardset-protected keys are less likely to be affected by
the problems.
In any case, after you have generated a new key, or transferred an
existing key, you should check that the problem has not recurred,
by using nfkmverify as described below.
If you find you are unable to generate a key whose security can be
established using nfkmverify, contact nCipher Support, who will
advise on a configuration change or workaround, if necessary, or -
if appropriate - confirm for you that the reports from nfkmverify
are harmless and do not indicate a vulnerability.
3. Making a Key Secure, Regardless of its Previous Vulnerability
----------------------------------------------------------------
This advisory's supporting patch kit includes a tool which will
make any PKCS#11 object stored by the nCipher PKCS#11 library secure,
regardless of the security wishes of the application, and regardless
of any previous security status.
To use this tool, run the command:
/opt/nfast/bin/with-nfast --admin nso,r \
/opt/nfast/bin/ckfixsecure <ident>
or
c:\nfast\bin\with-nfast --admin nso,r
c:\nfast\bin\ckfixsecure <ident>
ckfixsecure will, if successful, report the key's security status
and advise that it is changed the access control lists.
Notes:
* This will require your Administrator Cards. Note that you should
not insert your Administrator Cards, nor enter their passphrases,
into a module not attached to a fully trusted host - nCipher
recommends the use of a host not attached to a network.
* ckfixsecure can only operate on recoverable keys. If your security
world has recovery disabled, you must generate new keys.
* Following the use of ckfixsecure the key will not be usable until
it has been transferred to a new Security World (for module-protected
keys) or a new operator card set (for cardset-protected keys).
Furthermore, to correct any vulnerability that may have existed,
it is necessary to prevent an attacker from loading previous
versions of the host key data, which contain, encrypted, copies
of the key with vulnerable access control lists. Thus the old
Security World or cardset must be taken out of use, so that these
key blobs can no longer be used.
* Some PKCS#11 applications perform doubtful operations such as
exporting the key plaintext value to the host. These operations
are forbidden for secure keys, and therefore such applications
may fail after their keys are made secure.
4. Transferring a Key to Another Security World
-----------------------------------------------
This advisory's supporting patch kit contains the utilities
`mk-reprogram' and `key-xfer-im', and documentation on their use
in `kmigrate.txt'. These utilities can be used to transfer keys
between security worlds without the key material leaving the module.
Transferring a key to another Security World requires the use of
the Administrator Cards to authorise the override of the existing
security arrangements. Note that you should not insert your
Administrator Cards, nor enter their passphrases, into a module not
attached to a fully trusted host - nCipher recommends the use of a
host not attached to a network.
Note also that keys in non-recoverable security worlds, or
non-recoverable keys in recoverable worlds, do not allow even the
Administrator Cardset to override their security arrangements, and
cannot be transferred.
The use of the transfer utilities is complex and difficult. nCipher
recommends that customers who need to do this consult nCipher
Support.
If you choose to go ahead without consulting nCipher support, note
that fixing keys related to this advisory requires the use of the
--aclbase-working option to key-xfer-im. It is also necessary to
run the postrocs utility after the transfer. Before running the
postrocs utility, it is necessary to first temporarily move the
following files:
/opt/nfast/kmdata/local/key_pkcs11_ua*
or
c:\nfast\kmdata\local\key_pkcs11_ua*
to another directory. These should be restored once postrocs has
completed successfully.
BACKGROUND
==========
1. PKCS#11, and the `sensitive' and `extractable' Flags
-------------------------------------------------------
In PKCS#11 terminology, a key may be `sensitive' (meaning it cannot
be exported in plain text); it may also be `non-extractable' (meaning
it cannot be exported in ciphertext form either). These options
are specified by the PKCS#11 object attributes CKA_SENSITIVE and
CKA_EXTRACTABLE.
However, for keys which are sensitive but extractable, the PKCS#11
Standard does not provide any restrictions on which keys can be
used as key transport keys (`wrapping keys') when the target key
is extracted in encrypted form, so that any extractable key is not
significantly more secure: an attacker who wishes to obtain the key
can simply ask for it to be provided encrypted using the attacker's
own key.
The facility for applications to generate and export insecure keys
(that is, keys which are not protected by the module's security
mechanisms) is a feature of the PKCS#11 standard which is important
for many applications, for example for use as session keys, or for
bulk key generation.
Therefore, whether a key is sensitive, or non-extractable, may be
specified by the application; alternatively, the application may
leave the sensitivity and extractability unspecified, in which case
the PKCS#11 implementation may choose a default.
The PKCS#11 standard specifies some circumstances in which combinations
of extractability and/or sensitivity are mandatory or forbidden,
and also specifies the default for some situations. In other
circumstances the permissibility and/or defaults are unspecified
by the standard and the PKCS#11 implementation provider must choose
defaults.
The PKCS#11 standard also distinguishes between `Private' and
`Public' objects: Private objects require the application to `log
in' by supplying a passphrase before they are used. This corresponds
to the CKA_PRIVATE attribute.
2. Security World, Module and Cardset Protection
------------------------------------------------
nCipher's key management modules (nForce/nShield) are generally
used with nCipher's suite of utilities for managing a `Security
World'. A Security World is a collection of cryptographic keys,
smart cards, modules and associated data stored on host computers.
A Security World is designed to prevent unauthorized access to
application keys while maintaining scalability and key availability.
The core Security World secrets are protected by Administrator Cards
written by the initialization software and kept safe by the user.
Application keys can either be made available to any nCipher module
appropriately programmed with the user's Administrator Cards (Module
Protected keys) or they can be protected by further smart cards
known as Operator Cards that provide an additional layer of security.
3. nCipher's PKCS#11 Library
----------------------------
The nCipher PKCS#11 library presents two kinds of `slots' to
applications: `accelerator slots' which correspond to an individual
module or to the system, and `cardset slots' which correspond to a
module cardreader or to an Operator Card Set.
nCipher's PKCS#11 library protects sensitive, non-extractable PKCS#11
objects, including keys, as follows:
Accelerator Slot: Cardset Slot:
Private objects: Module-Protected Cardset-Protected
(Passphrase) (secured objects only
[1] [2] supported very recently)
Public objects: Module-Protected Not allowed (only unsecured
(No passphrase) [1] objects are supported)
Non-sensitive, or extractable, objects are not protected by the
module's security mechanisms, as discussed above and as required
by the PKCS#11 standard.
[1] Note that `Private' and `Public' here refer to the PKCS#11
CKA_PRIVATE attribute, which is not related to whether the key is
a secret key, private key, or public key, and is related only in a
complex way to its security properties, as discussed above.
[2] Private objects here include objects created by using the
CKNFAST_FAKE_ACCELERATOR_LOGIN feature to force the creation of Public
objects by applications which insist on calling C_Login and will only
attempt to create Private objects. This feature is typically used to
allow certain applications, including iPlanet, to create and use
module-protected keys.
STATUS OF THIS ADVISORY, AND RELEASE SCHEDULE
=============================================
This advisory is being released early to nCipher customers and
partners, so that remedial action can be taken as soon as possible.
This period of limited private disclosure will last for two weeks.
If you receive this advisory during the period of limited disclosure
please treat this advisory as confidential.
In order to ensure that any remaining customers are informed, nCipher
intends to publish this advisory on 20th December 2002.
nCipher will supply this advisory and the supporting patch kit with
all shipments of affected products until the contents of the patch
kit and associated changes have been incorporated into updated
versions of these products.
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. 2002
All trademarks acknowledged.
$Id: advisory6.txt,v 1.40 2002/12/20 09:38:27 mknight Exp $
Access control defects in PKCS#11 keys
--------------------------------------
SUMMARY
=======
As a function of internal QA testing, nCipher has identified that,
under certain unusual circumstances, keys created by the nCipher
PKCS#11 library, which should be secure, may be exportable from the
hardware security module in plaintext or equivalent, or have other
defects in their access control.
nCipher believes that only a very small number of installations may
be affected. Whether a key is affected depends on the application,
the version of the nCipher PKCS#11 library in use, and the system
configuration.
nCipher is providing tools, in an accompanying patch kit, that
allows customers to check their current access controls, in order
to affirm that their keys are not vulnerable in unexpected ways.
The detailed advice below allows a customer to first determine if
their particular circumstances expose them to this problem, and if
the customer concludes a vulnerability exists, explains how this
can be eliminated.
ISSUE DESCRIPTION
=================
1. Problem
----------
nCipher modules can be used from a number of industry standard
APIs. Among these, nCipher supplies a cryptographic library that
is compatible with the RSA Laboratories PKCS#11 Cryptographic Token
Interface Standard (Cryptoki).
The nCipher PKCS#11 library translates calls from the PKCS#11
Standard API to underlying nCore primitives. The interpretation
of PKCS#11 calls and attributes from the standard, and the mapping
to the underlying nCore API, is extremely complex.
nCipher is issuing this advisory in response to implementation
errors found in the nCipher PKCS#11 library. However, differences
in interpretation of the PKCS#11 standard between nCipher and
application vendors, and potentially, errors in applications, can
also cause keys to have incorrect or unexpectedly weak protection.
2. Impact
---------
If a key is improperly secured then in the worst case, an attacker
who can issue commands to any module in the same Security World,
and can obtain a copy of current or old host-side Security World
data, can obtain the key plaintext from the module.
This may apply to existing keys, or to newly-generated keys.
3. Who May Be Affected
----------------------
All installations which use the nCipher PKCS#11 library are potentially
affected. Installations that do not use the nCipher PKCS#11
implementation are NOT affected.
You are NOT affected in the following situations:
* The following applications are NOT affected because they do
not integrate with nCipher products via PKCS#11:
Apache
IBM Websphere (using BHAPI interface only)
iPlanet Proxy Server
Microsoft Exchange Server
Microsoft Internet Information Server (IIS)
Microsoft ISA Server
Microsoft Windows 2000 Certificate Server
Netscape Enterprise Server 3.x (but iPlanet may be affected)
Stronghold webserver
Tivoli Access Manager, Web Seal version 3.9
Oracle 9i R2 Database Advanced Security Option
* Applications written using the following APIs are NOT affected:
nCore/NFKM (previously known as `the nFast API')
CHIL (also known as `hwcrhk')
Microsoft CAPI
OpenSSL
BHAPI
nCipher supplied JCA and/or JCE providers
* The nFast 800 or previous nFast products which provide only
acceleration and do not support key management are NOT affected.
(Note that the name `nFast' has been used in the past to refer
to key management products.)
If you cannot rule out the possibility that you may be affected,
you should obtain the patch kit and perform the test, below.
4. Obtaining the Patch Kit
--------------------------
You can obtain copies of this advisory, and supporting documentation,
from the nCipher updates site:
http://www.ncipher.com/support/advisories/
We regret that due to export control regulations, we are unable to
make the patch kit available on the web site. Please contact nCipher
support who will advise you on obtaining the patch kit, either via
Internet download or on CDROM.
The patch kit is available for the following platforms:
AIX 4.3.3
AIX 5L (32 bit only)
HP-UX 10.20 / HP-UX 11
Linux libc6 / Linux libc6.1
Solaris 2.6 / Solaris 2.7 / Solaris 2.8 / Solaris 2.9
Trusted Solaris 2.8
Windows NT 4 / Windows 2000
Customers using other platforms should contact nCipher support.
5. Contents of the Patch Kit
----------------------------
The patch kit contains:
* This advisory `advis6.txt' and supporting documentation.
* A platform specific `read-me.txt' file that contains detailed
patch kit installation instructions.
* Tool for finding private keys from X.509 PEM format files:
pubkey-find
* Updated tool for checking key generation certificates and current
security properties of keys:
nfkmverify
* Updated `with-nfast' utility.
* Updated `postrocs' utility.
* Specially prepared vulnerability check and fix program:
ckfixsecure
* Tools for transferring keys between security worlds:
mk-reprogram and key-xfer-im
These tools are documented in `kmigrate.txt'.
6. 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 GMT).
How To Tell If You Are Affected
===============================
If you have existing keys and have not ruled out the possibility
that you may be vulnerable, perform the steps below for those keys.
Before proceeding you must follow the earlier guidance on obtaining
the patch kit, and install this in accordance with the enclosed
`read-me.txt' installation instructions.
If you are generating new keys, and have not ruled out the possibility
that they may be generated vulnerable, perform the steps below after
generating the key(s) but before putting them into service. For
example, with an SSL webserver, perform the test below after
generating the key but before sending your certificate request to
your certificate authority.
i. Establish the identity in your Security World of the long-term
key(s) which are important to your installation:
* If you are using an SSL/TLS/HTTPS webserver, a certificate
authority, or another X.509 certificate based application,
the relevant keys can be found from your X.509 certificate(s)
using the nCipher-supplied pubkey-find utility.
For each key, put the certificate, or your certificate request
or self-certificate, in PEM format in a file. Assuming
you have named the file `certificate.pem', then run:
/opt/nfast/bin/pubkey-find certificate.pem
or
c:\nfast\bin\pubkey-find.exe certificate.pem
This will report the `ident' of the corresponding private
key.
* If you are using another application, nCipher recommends that
you assume that all long-term key(s), stored via the PKCS#11
interface by your application, are important. In cases of
doubt, the `cklist' and `nfkminfo' utilities, and the
`pubkey-find' program supplied with this advisory, may be
of use.
In this case, use the command:
/opt/nfast/bin/nfkminfo -k pkcs11
or
c:\nfast\bin\nfkminfo -k pkcs11
which will list the idents of all PKCS#11 objects in your
Security World, in the form:
AppName pkcs11 Ident <ident>
Note that some PKCS#11 applications will create temporary
key(s), and other keys which do not require long-term
protection by the module, as long term keys to be stored by
the PKCS#11 library. Customers for whom this is true will
be identified by nCipher Support, according to the process
below.
ii. Check whether the key(s) are affected by the problem:
For each <ident>, run:
/opt/nfast/bin/nfkmverify -U pkcs11 <ident>
or
c:\nfast\bin\nfkmverify.exe -U pkcs11 <ident>
If nfkmverify produces a report of the protection status of
the key, the key is properly protected. Confirm that the
protection details are correct. In particular, check that
the key is protected by the correct operator cardset.
nfkmverify may also report discrepancies and problems in a
number of situations:
UNVERIFIED SECURITY WORLD !
This indicates that the Security World was generated
by older nCipher software which did not store a signed
audit trail of the Security World generation. With
respect to the detection of problems with the PKCS#11
library, this is not an issue, since the PKCS#11 library
is not involved with Security World creation.
PROBLEM: application key pkcs11 ...: no key generation signature
This indicates that the application key was generated
by older nCipher software which did not store a signed
audit trail of the key generation. Alternatively, the
object may not be a key at all, since PKCS#11 provides
for the storage of data as well as keys.
If you get this message, firstly check that the object is
actually a key. Run:
/opt/nfast/bin/nfkminfo -k pkcs11 <ident>
or
c:\nfast\bin\nfkminfo.exe -k pkcs11 <ident>
Look for the `protection' near the top of the output. If
you see:
protection NoKey
the object is not a key and therefore cannot be insecure
and is not affected by the issues discussed in this
Advisory.
If you see:
protection CardSet
or
protection Module
then the object is a key. You must check that the key,
including its key recovery information, is correct.
Run these two commands:
/opt/nfast/bin/with-nfast -A pkcs11 -K <ident> \
/opt/nfast/bin/nfkmverify -U -L pkcs11 <ident>
/opt/nfast/bin/with-nfast --admin r \
/opt/nfast/bin/nfkmverify -U -R pkcs11 <ident>
or these two:
c:\nfast\bin\with-nfast -A pkcs11 -K <ident>
c:\nfast\bin\nfkmverify -U -L pkcs11 <ident>
c:\nfast\bin\with-nfast --admin r
c:\nfast\bin\nfkmverify -U -R pkcs11 <ident>
The first command will need the relevant Operator Cards
and the second will need the Administrator Cards.
Note that you should not insert your Administrator
Cards, nor enter their passphrases, into a module unless
it is attached to a fully trusted host - nCipher
recommends the use of a host not attached to a network.
To confirm that your keys are secure you should now
check that the output is as you expect in both cases.
Other discrepancies and problems
If the key has been the subject of a key transfer between
security worlds, or of an operator cardset recovery,
nfkmverify is expected to report discrepancies, as the
original key generation certificates will no longer
correspond to the current protection status. In this
case, use nfkmverify -R as described above to confirm
that your keys are secure.
If any other discrepancies or problems are reported,
contact nCipher Support. Not all other messages indicate
security problems, but expert advice will be required
to determine whether you are at risk. Please supply
nCipher Support with the complete report from nfkmverify.
If any of the key(s) specified are not fully protected by the
module security mechanisms, nfkmverify will report extensive
details about the affected key(s).
Note that, as stated above, the existence of keys not protected
by the hardware security mechanisms does not in itself
necessarily indicate that your system is vulnerable; it may
be that the unprotected keys are ephemeral SSL webserver
session keys or other keys whose security against attacks
from the local host is not important to the overall system
security.
You must determine whether the extractable key(s) are important.
nCipher recommends that you either assume that all the affected
key(s) are important and attempt to make them secure, or
urgently contact nCipher support for advice.
REMEDY
======
1. Available Remedies
---------------------
A. New keys
After generating any new keys with the nCipher PKCS#11 library,
perform the checks above to determine if they are vulnerable.
If you have just generated keys which, after checking as detailed
above, cannot be determined to be secure, contact nCipher
Support. nCipher Support will advise a configuration change
or workaround to allow the generation of keys that are not
vulnerable. nCipher Support will advise you to discard any
vulnerable keys, or confirm that the reports from nfkmverify
do not indicate a vulnerability.
B. Existing keys
If you have existing keys which have been determined to be
vulnerable, there are three courses of remedial action available.
If you are affected by the problems you should follow one as
soon as possible. The remedies are:
1. Revoke your existing key and generate a new, secure, key.
The key must be revoked at all possible reliers or counter
parties.
2. Generate a new, secure, key, and make the old key unusable.
All modules in your existing Security World will have to be
erased.
3. Correct the protection status of the existing key. You will
have to transfer the key to a new Security World and erase
all modules in the old Security World.
If you can reliably inform all other reliers and counter parties
that your existing key is compromised, you should choose 1.
However, in many applications (for example, in SSL as used for
HTTPS) this is not possible.
Otherwise, you should choose 2 if you can conveniently generate
and distribute a new key, including obtaining any necessary
certificates on the existing key.
If you are not able to prevent reliers using the existing key,
and it is not convenient to generate a new key, choose 3.
The protection status of non-recoverable keys cannot be changed;
if your Security World has recovery disabled, you must choose 1
or 2.
2. Revoking and Generating a New Key
------------------------------------
See `Available remedies', above, regarding the choice of the
appropriate course of remedial action.
i. If you are able to suspend use of the old key, revoke it
immediately by informing the appropriate revocation authority,
or all reliers, in the appropriate way. Note that there is
no effective revocation mechanism for webserver SSL certificates;
for such keys you must choose option 2 or 3.
ii. Generate a new, secure, key, and verify its status (see below).
iii. Test that your application works satisfactorily with the new
key. In case of problems, consult nCipher Support.
iv. Inform all of your reliers or counter parties, including
your revocation authority, of the new key. The details will
depend on the protocol you are using.
3. Generating a New Key and Making the Old Key Unusable
-------------------------------------------------------
See `Available remedies', above, regarding the choice of the
appropriate course of remedial action.
i. If you are able to suspend use of the old key while
implementing the remedy, immediately erase all of the modules
in your Security World. (See instructions for erasing a
module, below.) Whether or not you are continuing operation
with the old key, continue with the remedial action as
follows:
ii. Make a backup copy of your Security World host data directory
/opt/nfast/kmdata or c:\nfast\kmdata.
iii. Generate a new Security World (if the original key is module
protected) or operator card set (if the original key is
cardset protected).
iv. Generate a new, secure, key, and verify its status (see below),
protected by the new world or cardset.
v. Test that your application works satisfactorily with the new
key. In case of problems, consult nCipher Support.
vi. Obtain any necessary certification for the new key and inform
all potential reliers of the new key value.
vii. Put the new key into service.
viii. If you created a new Security World in (ii) above, because the
old key was module protected, erase all of the modules in
the old Security World if you have not already done so.
ix. Keep the old Security World administrator cards, or old
operator cards, in a safe place alongside your (new)
administrator cards. Note that your old operator cardset
should no longer be used as an operator cardset, unless
exceptional access to the vulnerable old keys is required.
4. Securing the Existing Key
----------------------------
See `Available remedies', above, regarding the choice of the
appropriate course of remedial action.
i. If you are able to suspend use of the key while implementing
the remedy, immediately erase all but one of the modules in
your Security World. (See instructions for erasing a module,
below.) Take the remaining module and attach it to a trusted
host, preferably not one connected to a network, and use it
for the next steps. Whether or not you require continuous
use of the key, continue with the remedial action as follows:
ii. Take a backup copy of your Security World host data directory
/opt/nfast/kmdata or c:\nfast\kmdata.
iii. Use the nCipher access-control-list change utility (details
below) to make a secure version of the key and store its
encrypted key blob in your Security World host data directory.
(That is, a copy of the key with a correct, safe, access
control list.)
iv. Generate a new Security World (if the key is module protected)
or operator card set (if the key is cardset protected).
v. If the key is module protected, use the nCipher key transfer
utilities to transfer the modified version of the key from
the old to the new Security World (see below). If the key
is cardset protected, use `rocs' to transfer it to the new
operator cardset.
vi. Verify the protection status of the new key (see below).
vii. Test that your application works satisfactorily with the new
key. In case of problems, consult nCipher Support.
viii. Put the new copy of the key, and the new Security World or
operator cardset, into service.
ix. If you created a new Security World in (vi) above, because the
key is module protected, erase all of the (remaining) modules
in the old Security World.
x. Keep the old Security World administrator cards, or old
operator cards, in a safe place alongside your (new)
administrator cards. Note that your old operator cardset
should no longer be used as an operator cardset, unless
exceptional access to the vulnerable forms of the keys is
required.
DETAILED INSTRUCTIONS FOR REMEDIAL ACTIONS
==========================================
nCipher recommends that you contact nCipher Support if remedial
action may be required, as the operations involved can be very
complex.
Consult the previous section to determine which remedial actions
are required, and in which order they should be performed.
1. Erasing a Module
-------------------
i. Confirm that there are no key(s) in the Security World which you
still wish to use. This will be either because you have
decided to shut down your application while the security is
ensured, or because you have secured your application by
changing keys or security worlds, and wish to put the old
keys beyond use.
(Note that the Administrator Cards can, with the old host
data, be used to once more program a module into the world,
should this be required. Ensure that have your Administrator
Cards and know the passphrases. Note that you should not
insert your Administrator Cards, nor enter their passphrases,
into a module not attached to a fully trusted host - nCipher
recommends the use of a host not attached to a network.)
ii. Fit the initialisation link (internal SCSI units), press and
hold the initialisation switch (external SCSI units), or set
the mode switch to initialisation (PCI units), and then:
iii. reset the unit using the front panel clear switch (SCSI) or the
rear panel recessed clear switch (PCI). The module should
come up into Pre-Initialisation mode, flashing a distinctive
pattern on its LED: repeating a single short flash.
iv. Run:
/opt/nfast/bin/initunit
or
c:\nfast\bin\initunit.exe
If no output is produced the module has been reinitialised.
2. Generating a New Key, Securely
---------------------------------
If you choose to generate a new key as part of your remedy, or as
part of a new installation, you must ensure that it will not be
affected by the original problem.
A version of the nCipher PKCS#11 library which has the original
problems corrected is in preparation. However, at present nCipher
recommends avoiding the use of module-protected keys with the PKCS#11
library. Cardset-protected keys are less likely to be affected by
the problems.
In any case, after you have generated a new key, or transferred an
existing key, you should check that the problem has not recurred,
by using nfkmverify as described below.
If you find you are unable to generate a key whose security can be
established using nfkmverify, contact nCipher Support, who will
advise on a configuration change or workaround, if necessary, or -
if appropriate - confirm for you that the reports from nfkmverify
are harmless and do not indicate a vulnerability.
3. Making a Key Secure, Regardless of its Previous Vulnerability
----------------------------------------------------------------
This advisory's supporting patch kit includes a tool which will
make any PKCS#11 object stored by the nCipher PKCS#11 library secure,
regardless of the security wishes of the application, and regardless
of any previous security status.
To use this tool, run the command:
/opt/nfast/bin/with-nfast --admin nso,r \
/opt/nfast/bin/ckfixsecure <ident>
or
c:\nfast\bin\with-nfast --admin nso,r
c:\nfast\bin\ckfixsecure <ident>
ckfixsecure will, if successful, report the key's security status
and advise that it is changed the access control lists.
Notes:
* This will require your Administrator Cards. Note that you should
not insert your Administrator Cards, nor enter their passphrases,
into a module not attached to a fully trusted host - nCipher
recommends the use of a host not attached to a network.
* ckfixsecure can only operate on recoverable keys. If your security
world has recovery disabled, you must generate new keys.
* Following the use of ckfixsecure the key will not be usable until
it has been transferred to a new Security World (for module-protected
keys) or a new operator card set (for cardset-protected keys).
Furthermore, to correct any vulnerability that may have existed,
it is necessary to prevent an attacker from loading previous
versions of the host key data, which contain, encrypted, copies
of the key with vulnerable access control lists. Thus the old
Security World or cardset must be taken out of use, so that these
key blobs can no longer be used.
* Some PKCS#11 applications perform doubtful operations such as
exporting the key plaintext value to the host. These operations
are forbidden for secure keys, and therefore such applications
may fail after their keys are made secure.
4. Transferring a Key to Another Security World
-----------------------------------------------
This advisory's supporting patch kit contains the utilities
`mk-reprogram' and `key-xfer-im', and documentation on their use
in `kmigrate.txt'. These utilities can be used to transfer keys
between security worlds without the key material leaving the module.
Transferring a key to another Security World requires the use of
the Administrator Cards to authorise the override of the existing
security arrangements. Note that you should not insert your
Administrator Cards, nor enter their passphrases, into a module not
attached to a fully trusted host - nCipher recommends the use of a
host not attached to a network.
Note also that keys in non-recoverable security worlds, or
non-recoverable keys in recoverable worlds, do not allow even the
Administrator Cardset to override their security arrangements, and
cannot be transferred.
The use of the transfer utilities is complex and difficult. nCipher
recommends that customers who need to do this consult nCipher
Support.
If you choose to go ahead without consulting nCipher support, note
that fixing keys related to this advisory requires the use of the
--aclbase-working option to key-xfer-im. It is also necessary to
run the postrocs utility after the transfer. Before running the
postrocs utility, it is necessary to first temporarily move the
following files:
/opt/nfast/kmdata/local/key_pkcs11_ua*
or
c:\nfast\kmdata\local\key_pkcs11_ua*
to another directory. These should be restored once postrocs has
completed successfully.
BACKGROUND
==========
1. PKCS#11, and the `sensitive' and `extractable' Flags
-------------------------------------------------------
In PKCS#11 terminology, a key may be `sensitive' (meaning it cannot
be exported in plain text); it may also be `non-extractable' (meaning
it cannot be exported in ciphertext form either). These options
are specified by the PKCS#11 object attributes CKA_SENSITIVE and
CKA_EXTRACTABLE.
However, for keys which are sensitive but extractable, the PKCS#11
Standard does not provide any restrictions on which keys can be
used as key transport keys (`wrapping keys') when the target key
is extracted in encrypted form, so that any extractable key is not
significantly more secure: an attacker who wishes to obtain the key
can simply ask for it to be provided encrypted using the attacker's
own key.
The facility for applications to generate and export insecure keys
(that is, keys which are not protected by the module's security
mechanisms) is a feature of the PKCS#11 standard which is important
for many applications, for example for use as session keys, or for
bulk key generation.
Therefore, whether a key is sensitive, or non-extractable, may be
specified by the application; alternatively, the application may
leave the sensitivity and extractability unspecified, in which case
the PKCS#11 implementation may choose a default.
The PKCS#11 standard specifies some circumstances in which combinations
of extractability and/or sensitivity are mandatory or forbidden,
and also specifies the default for some situations. In other
circumstances the permissibility and/or defaults are unspecified
by the standard and the PKCS#11 implementation provider must choose
defaults.
The PKCS#11 standard also distinguishes between `Private' and
`Public' objects: Private objects require the application to `log
in' by supplying a passphrase before they are used. This corresponds
to the CKA_PRIVATE attribute.
2. Security World, Module and Cardset Protection
------------------------------------------------
nCipher's key management modules (nForce/nShield) are generally
used with nCipher's suite of utilities for managing a `Security
World'. A Security World is a collection of cryptographic keys,
smart cards, modules and associated data stored on host computers.
A Security World is designed to prevent unauthorized access to
application keys while maintaining scalability and key availability.
The core Security World secrets are protected by Administrator Cards
written by the initialization software and kept safe by the user.
Application keys can either be made available to any nCipher module
appropriately programmed with the user's Administrator Cards (Module
Protected keys) or they can be protected by further smart cards
known as Operator Cards that provide an additional layer of security.
3. nCipher's PKCS#11 Library
----------------------------
The nCipher PKCS#11 library presents two kinds of `slots' to
applications: `accelerator slots' which correspond to an individual
module or to the system, and `cardset slots' which correspond to a
module cardreader or to an Operator Card Set.
nCipher's PKCS#11 library protects sensitive, non-extractable PKCS#11
objects, including keys, as follows:
Accelerator Slot: Cardset Slot:
Private objects: Module-Protected Cardset-Protected
(Passphrase) (secured objects only
[1] [2] supported very recently)
Public objects: Module-Protected Not allowed (only unsecured
(No passphrase) [1] objects are supported)
Non-sensitive, or extractable, objects are not protected by the
module's security mechanisms, as discussed above and as required
by the PKCS#11 standard.
[1] Note that `Private' and `Public' here refer to the PKCS#11
CKA_PRIVATE attribute, which is not related to whether the key is
a secret key, private key, or public key, and is related only in a
complex way to its security properties, as discussed above.
[2] Private objects here include objects created by using the
CKNFAST_FAKE_ACCELERATOR_LOGIN feature to force the creation of Public
objects by applications which insist on calling C_Login and will only
attempt to create Private objects. This feature is typically used to
allow certain applications, including iPlanet, to create and use
module-protected keys.
STATUS OF THIS ADVISORY, AND RELEASE SCHEDULE
=============================================
This advisory is being released early to nCipher customers and
partners, so that remedial action can be taken as soon as possible.
This period of limited private disclosure will last for two weeks.
If you receive this advisory during the period of limited disclosure
please treat this advisory as confidential.
In order to ensure that any remaining customers are informed, nCipher
intends to publish this advisory on 20th December 2002.
nCipher will supply this advisory and the supporting patch kit with
all shipments of affected products until the contents of the patch
kit and associated changes have been incorporated into updated
versions of these products.
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. 2002
All trademarks acknowledged.
$Id: advisory6.txt,v 1.40 2002/12/20 09:38:27 mknight Exp $