SA#06: Access control defects in PKCS#11 keys

This advisory also available as PGP-signed plaintext.

December 2002

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 8004       
Customers in all other countries:             +44 1223 723675       

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.

1. 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:nfastbinpubkey-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:nfastbinnfkminfo -k pkcs11
     which will list the idents of all PKCS#11 objects in your Security World, in the form:
     AppName pkcs11 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.
2. Check whether the key(s) are affected by the problem: For each , run:
   /opt/nfast/bin/nfkmverify -U pkcs11
   or
   c:nfastbinnfkmverify.exe -U pkcs11
   
   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
   or
   c:nfastbinnfkminfo.exe -k pkcs11
   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
/opt/nfast/bin/nfkmverify -U -L pkcs11
/opt/nfast/bin/with-nfast --admin r
/opt/nfast/bin/nfkmverify -U -R pkcs11
or these two:
   c:nfastbinwith-nfast -A pkcs11 -K
c:nfastbinnfkmverify -U -L pkcs11
c:nfastbinwith-nfast --admin r
c:nfastbinnfkmverify -U -R pkcs11
   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.

1. 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.
2. Generate a new, secure, key, and verify its status (see below).
3. Test that your application works satisfactorily with the new key. In case of problems, consult nCipher Support.
4. 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.

1. 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:
2. Make a backup copy of your Security World host data directory /opt/nfast/kmdata or c:nfastkmdata.
3. Generate a new Security World (if the original key is module protected) or operator card set (if the original key is cardset protected).
4. Generate a new, secure, key, and verify its status (see below), protected by the new world or cardset.
5. Test that your application works satisfactorily with the new key. In case of problems, consult nCipher Support.
6. Obtain any necessary certification for the new key and inform all potential reliers of the new key value.
7. Put the new key into service.
8. 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.
9. 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.

1. 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:
2. Take a backup copy of your Security World host data directory /opt/nfast/kmdata or c:nfastkmdata.
3. 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.)
4. Generate a new Security World (if the key is module protected) or operator card set (if the key is cardset protected).
5. 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.
6. Verify the protection status of the new key (see below).
7. Test that your application works satisfactorily with the new key. In case of problems, consult nCipher Support.
8. Put the new copy of the key, and the new Security World or operator cardset, into service.
9. 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.
10. 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

1. 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.)
2. Fit the initialisation link (internal SCSI units), press and
3. hold the initialisation switch (external SCSI units), or set the mode switch to initialisation (PCI units), and then:
4. 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.
5. iv. Run:
   /opt/nfast/bin/initunit
   or
   c:nfastbininitunit.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
or
c:nfastbinwith-nfast --admin nso,r
c:nfastbinckfixsecure

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:nfastkmdatalocalkey_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: (passphrase) [1] [2]	Module-Protected (secured objects only supported very recently)	Cardset-Protected
Public Objects: (no passphrase) [1]	Module-Protected	Not allowed (only unsecured 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 16th 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 by sending a message with the single word 'subscribe' in the body to security-announce-request@ncipher.com.

 

© nCipher Corporation Ltd. 2002

All trademarks acknowledged.

$Id: advisory6.txt,v 1.38 2002/11/29 09:40:21 mknight Exp $