Problem:Comparing to Luna SA 5.4, we have performance slow-down on test cases with RSA, ECDSA, Digest, AES/DES3 (PE1746 is disabled) and DSA. The range is about 5-10%. Detailes are attached as spreadsheets.

AES/DES3 with PE1746 Enabled have over 20% slowing down.

.

Workaround: None. If performance is critical, do not update at this time.

Problem: After upgrading the firmware a Luna G5 HSM to firmware 6.22.0, HSM performance is reduced.

Workaround: Run the ureset utility (located in the Luna client root directory) to reset the USB driver after performing the firmware upgrade.

Problem: Comparing to release 5.4, Luna G5 release 6.0 performance numbers are reduced with:

RSA Encrypt/Decrypt

ECDSA

ECDH

ECIES

HMAC

ARIA

KCDSA

Workaround: None. If performance is critical, do not update at this time.

Problem: The PED client service from 32-bit binaries does not start on Solaris 11 Sparc T-5120 server.

Workaround: None

Problem: When Luna G5 is unplugged and then re-plugged, the client tools fail to detect it on Dell R710, Sun Fire v245 and Sparc T-5120 servers. 

Workaround: None

Problem: While testing remote backup with a single Remote PED case, it was found that timeout happens during backing up. To complete a backup, pedtimeout3 value must increase in the configuration file. For the change to take effect, pedclient and the client application must be restarted. Because peclient is shared with audit logging, restarting has an impact on audit logging. Pedclient should pick up the change without restarting.

Workaround: None. For Luna PCI-E, audit logging is affected when the restart is performed. In Luna SA, there is no provision to restart pedclient, and therefore no way to make a timeout change effective.

Problem: If you enable HA autorecovery on Luna G5, members of the HA group that go down might not be autorecovered when they come back online.

Workaround: Do not use the autorecover feature. If one of your HA members goes down, restart your applications to manually restore the member.

Problem:Setup: Two Luna SA appliances
1. Java with HA HAOnly
2. Run jMultitoken
3. Shut down the interface of 1 member
4. After four attempts at recovering, restart the interface (notice the error code of 0xC0000102
5. After reaching max retries, perform manual recover

The client sets up a session with the appliance but HA is never recovered.

Workaround: Reboot.

Problem: When restoring existing objects from an SFF token to an SA partition, existing objects are found and skipped, as expected, every 5-6 seconds or so. However, on occasion, there may be a lengthy pause (5 minutes or so), between objects.

Workaround: None. If you notice a pause, please be patient.

Problem:Logged in as the Auditor, set log level to log nothing.

Stopped the luna client services - HTL, SNMP, PED Server.

Renamed the "logtest" directory to something else.

Restarted the 3 services stopped earlier.

At this point the Luna G5 froze with its green light on. I couldn't get it back to life without a ureset.

Definitely an unlikely edge case, but interesting.

Workaround: Perform ureset to get Luna G5 going again.

Problem:Calling any lunash commands immediately after bonding enable or disable causes bonding to go into Fault-Tolerance mode causing unexpected behavior.

.

Workaround: None.

Problem:Tamper a Luna SA.
Reboot.
Perform hsm login - I and get "success" from lunash.

Note that the hsm still isn't really logged in, and requires a second login before I can do things that require SO authentication.

Workaround: After a tamper event, perform 'hsm login' twice.

Problem: KSP is only logging failures. It should also record successes, for auditing purposes.

Workaround: None.

Problem: kspcmd.exe has an option to specify a usage limit. The command appears to work and generates a registry entry that sets the limit specified for any key created via KSP (i.e. CA, etc.). However, when keys/certs are created via CA, the KSP log records error CKR_ATTRIBUTE_TYPE_INVALID. Reviewing the keys attributes in ckdemo does not show attributes CKA_USAGE_LIMIT or CKA_USAGE_COUNT. Without these set, the keys can be used an infinite number of times.

Workaround: After creating your CA, or after every renewal, launch ckdemo and manually add the usage limit attribute.

Problem: Luna Backup HSM with firmware 6.10.2 is undergoing FIPS evaluation.

To conform to FIPS evaluation, it must be used in FIPS approved operation mode. By default this HSM policy is OFF. There is no way to turn it on via lunash.

Workaround: Connect the Backup HSM to a standalone host computer and use lunacm to change the policy, then reconnect the Backup HSM to the Luna SA. Or perform remote backup.

Problem: Luna Backup HSM with f/w 6.10.2 is undergoing FIPS evaluation.

To conform to FIPS requirements, it must be used in FIPS approved operation mode and there must be a way to visually confirm this configuration.

There is no way via Lunash to query whether this HSM policy is on or off for a Luna Backup HSM.

Workaround: Connect the Backup HSM to a standalone host computer and use lunacm to view the status, then (if acceptable) reconnect the Backup HSM to the Luna SA. Or perform remote backup.

Problem: Attempting to perform a backup with "replace" option to a partition on the Luna Backup HSM that does not exist, Lunash prompts with a warning, but then gives  no opportunity to back out of the command:

[192.20.9.127] lunash:>partition backup -partition John1 -password userpin -serial 7000627 -replace -tokenpar

Warning: 'replace' mode specified, but no partition named FIPSBackup exists on the backup token. A new partition will be created.

Warning: You will need to connect Luna PED to the Luna Backup HSM to complete this operation.

You may use the same Luna PED that you used for Luna SA.

Please type 'proceed' and hit <enter> when you are ready to proceed> quit

Please type 'proceed' and hit <enter>

Workaround: Close the session, open a new SSH session to the Luna appliance, login to the HSM and try the backup again with a correct, existing partition name.

Problem: After installing Luna Client on windows server 2008 RC2, tried to run lunacm. Got "Cannot load library: The specified module could not be found".

Workaround: Open a new console/command-line window to allow the library path to be found.

Problem: Steps to reproduce:

1) Create a new user (somebody).

2) Run sysconf config backup

3) Run sysconf config factoryReset

4) Run sysconf config restore <backup file in step 2>

5) Login to appliance as "somebody", run "my file list" will get the following error.

[local_host] lunash:>my file list

/bin/ls: /home/somebody/lush_files: No such file or directory

Command Result : 0 (Success)

Workaround: Recreate the named user. Re-upload any files that were lost.

Problem: The command to move software NTLS keys into hardware is broken on password-authenticatedLuna SA.  Works properly for PED-authenticated Luna SA.

Workaround: If you prefer to use NTLS keys in hardware (inside the HSM, rather than on the Luna SA file system), then for PED-auth use the command options to generate them there, rather than generating in software and importing.

Problem: “partition archive backup –o” does not read the object handles correctly, when a single invalid handle is passed to "-o"; it just backs up everything found from Luna SA to etoken. If multiple invalid object handles are passed, it works correctly.

Workaround: Be aware of the discrepancy… and avoid passing invalid object handles.

Problem: When a Remote PED has been specified at the Luna SA via lunash commands, and then a different Remote PED is specified (for that Luna SA) via lunacm commands, the setting from lunash prevails. This could result in unexpected results when setting up Remote PED and remote Small Form-factor Backup.

1- Connect Luna SA to a Remote PED by issuing "hsm ped connect" from lunash.

2- From lunacm, run "ped connect" to connect to your Remote PED

3- then run "par login"

No prompt is presented at your Remote PED.

Following a timeout period one of the following might occur:

"Command Result : 0x8000002e (CKR_PED_UNPLUGGED)"

lunacm:>par login

Option -password was not supplied.  It is required.

Enter the password: *******

Please attend to the PED.

Command Result : 0x8000002e (CKR_PED_UNPLUGGED) --> If the PED device to which the Luna SA goes is not connected.

OR

Command Result : 0x80000024 (CKR_TIMEOUT) --> If the PED prompt went to a PED other than yours and nobody inserted the expected black key and pressed <ENTER>.

Workaround: For Remote PED authentication or remote Small Form-factor Backup of Luna SA, first run “hsm ped disconnect” from lunash, then run “ped connect and perform Small Form-factor Backup (or other PED-using operations) from lunacm.

Problem: Occasional errors or timeout occurred during local-PED data transfers (using SCP connection). This was probably always present, but went unnoticed during authentication operations due to the small data transactions. However, when PED is used in local mode for lengthy transactions, such as occur in SFF backup and restore operations, the instability is revealed.

Workaround: Use Remote PED SFF backup when backing up and restoring larger amounts of partition data. (Remote PED SFF backup operations have proven reliable over a reliable network.)

Problem: System gets rebooted when hsm reset command is issued on a G5 HA, running Solaris Sparc 11 (64-bit) Netra T5440 server.

Workaround: It is recommended to stop any running applications before issuing hsm reset command in lunacm.

Problem: If a Luna [Remote] Backup HSM is removed from its host after the RBS daemon is running, the RBS app will crash on attempted access.

Scenario 1:

- have running RBS daemon with Backup HSM connected, have remote host configured to use RBS

- power-off or remove USB cable from Backup HSM

- launch lunacm on remote host; RBS daemon will crash

Scenario 2:

- have running RBS daemon with Backup HSM connected, have remote host configured to use RBS

- launch lunacm on remote host

- power-off or remove USB cable from Backup HSM

- run remote backup; RBS daemon will crash

Workaround: The Backup HSM must be connected to the host computer to get the RBS daemon running, and RBS must be stopped before you disconnect the USB cable or power-off the Luna Backup HSM.

Problem: When a system is configured for auto-recovery, running the manual vtl haAdmin recovery option causes errors randomly.

Workaround: Avoid manual recovery when system is configured for HA auto-recovery.

Problem: Firmware allows only Crypto-Officer to clone objects. Currently, Crypto-User is not allowed to do cloning

The HA logic for object creation is to create on the primary and then propagate (using the cloning operation) to other members.

Workaround: Use Crypto Officer when using HA.

Problem: When trying to modify an already-installed Luna Client on Windows we have the option to select any extra component we want, but the selected additional components are not actually installed.
The installer gives no error message.

Workaround: When modifying an existing installed Luna Client, on Windows, choose to install a Luna Product and ALL its sub-features. THEN deselect any that are not needed, and the remaining desired files are installed correctly.

Problem: In an HA environment, configure for auto-recovery.

Launch multitoken with 10 threads performing key gens

Fail the secondary and recover - everything works.

Fail the primary - it switches over to do the key gens on the secondary.

Recover the primary and wait; the app fails with CKR_CANCEL

Workaround: None. Can be avoided if you do not have multiple clients connected to the HA slot.

Problem: In some instances, it might be desirable to perform a complete re-install of the Luna client, including replacing the current Chrystoki.conf file with the default version. Doing this on a Debian OS requires, after uninstalling the client, that the libcryptoki library be purged before the Chrystoki.conf.debsave backup file is deleted.

Workaround: Workaround:

To re-install the Luna client with the default Chrystoki.conf file on a Debian OS

1Uninstall the Luna client:

             /usr/safenet/lunaclient/bin/uninstall.sh

2Purge the libcryptoki library:

             dpkg -P libcryptoki

3Delete the backup Chrystoki.conf file:

             rm /etc/Chrystoki.conf.debsave

4Re-install the Luna client:

            <path>/install.sh 

Problem: During SFF backup over Remote PED, "Unknown Command" is observed on the PED followed by "Get Version".

This should be a message like "write to token..."

Workaround: Ignore.

Problem: Running ''cmu selfsign" ends with generating a key. If the command runs successfully, cmu is expected to display the new generated key handler, but it does not.

Workaround: Issue "cmu list" to verify that the new key has been created.

Problem: The cmu utility returns "Buffer too small" instead of "wrong password" against "cmu importkey" cmd.

Workaround: Be aware that the message is wrong, and re-try with the correct password.

Problem: After:
1) Run sysconf config backup

2) Run sysconf config factoryReset

any existing named user is no longer able to log in with public key authentication.

Workaround: Recreate the named user (see issue LHSM-9888). Upload a public key and re-establish public key authentication for each such user.

Problem: When performing any kind of multitoken cryptographic operation, and a Small Form Factor Backup operation is started on the same HSM, all other cryptographic operation ceases during the eToken initialization phase of the operation. This can take 2-3 minutes. After the eToken initialization stage, crypto operations recover somewhat, but not to full speed, until backup completes.

Workaround: Simply be aware that Luna PED operations and prompting have always blocked crypto operations on the attached HSM, and this continues with PED-mediated Small Form Factor Backup.

Problem: Attempted to back up 2 symmetric keys with SFF symmetric policy turned off for the partition.

The objects did not backup, but an overall message said success backing up 2 objects.

lunacm:> par archive backup -slot eToken -label G5Backup

WARNING: continuing the backup operation will wipe out all keys on the backup token!

Are you sure you wish to continue?

Type 'proceed' to continue, or 'quit' to quit now -> proceed

Operation in progress, please wait.

(1/2): Backing up object with handle 22... Failure

(2/2): Backing up object with handle 25... Failure

WARNING: Errors occurred while backup up one or more keys.

Backup Complete.

2 objects have been backed up to partition G5Backup

on the backup device

Command Result : 0x63 (CKR_KEY_TYPE_INCONSISTENT)

lunacm:>

If some objects do not backup due to policy settings, a better message should be presented, such as "Some or all objects failed to backup due to policy restrictions on the current partition" or similar. This should replace the current bad grammar warning: "WARNING: Errors occurred while backup up one or more keys."

Workaround: Ignore messages like  “2 objects have been backed up to partition” when other messages indicate individual failures.

Problem: During the full client install this warning/error appeared:

Unpacking lunajmt (from lunajmt_5.3.0-9_amd64.deb) ...

Setting up lunajmt (5.3.0-9) ...

Adding new version of lunajcprov

/usr/safenet/lunaclient/debian_pkgs

Use of uninitialized value $postinst in length at /usr/share/perl5/Alien/Package/Deb.pm line 741.

Workaround: The error appears to be a harmless coding issue in /usr/share/perl5/Alien/Package/Deb.pm which comes with the alien package.   Ignore the message.

Problem: The AES-CTR mechanism incorrectly encrypts multi-part operations on the HSM (single-part operations are fine). The multi-part operation succeeds and data is encrypted. But the wrong IV gets used for second and subsequent updates in the multi-part operation. The encrypted data can later be decrypted by the HSM. However, the encrypted data cannot be decrypted by non-Gemalto HSMs that support the AES-CTR mechanism. This issue applies to Luna SA and Luna PCI-E only. It does not occur on Luna G5.

Resolution: This issue is fixed in firmware 6.22.0. Decrypt data previously encrypted, upgrade the firmware to 6.22.0 and re-encrypt the data.

Problem: If you use an AES key for a GCM operation with an AAD (additional authentication data) length that is a multiple of 4-bytes, and later use the same key for another GCM operation with an AAD length that is not a multiple of 4 bytes, the HSM will halt.

This issue applies to Luna SA and Luna PCI-E only. It does not occur on Luna G5.

Resolution: This issue is fixed in firmware 6.22.0 and Multitoken.

Problem: It was found that several LunaClient services, on Windows platforms, depend on print “Spooler” services. That dependency should be removed.

Resolution: Printer service "Spooler" dependency is now removed from all LunaClient services on Windows.

Problem: the KSP version of ms2luna migrates keys, but does not change the proper pointers for Luna to take over; if applications are stopped they might not restart, complaining that they can no longer find the private key for the certificate.

Steps to reproduce:

• create a software CA
• Install/configure base Luna client,
• register partition via KSP
• run ms2luna and provide the thumbprint of the cert that the CA is using
• verify that keys have been copied to HSM
• in CA Management see what provider is being used – it shows that the Microsoft RSA Provider (or whatever was selected) is still in use
• stop/restart the CA – this fails and generates an error.

Resolution: This issue is fixed in release 6.0.

Problem: Some Javadoc entries that are available in Linux are not found when LunaClient 5.4.1/5.4.2 is installed on Windows.

Resolution: Fixed in Luna HSM 6.0.

Problem: multitoken generates an error when attempting RSA 2048 or RSA 4096 sigver against an HSM in FIPS approved operation mode. Due to FIPS restrictions on data size, smaller sizes are refused when the HSM is in FIPS mode. However, 2048 is the new minimum size and should have been accepted by multitoken.

Resolution: This is expected behavior due to the new FIPS-compliance changes that were enacted in Luna HSM release 5.4.

Problem: With this release, we provide only the 32bit library on windows 64bit OS to support customer's 32bit app in windows 64bits OS; we do not support our tools - like lunacm, vtl etc..

Resolution: Installation documentation updated.

Problem: Occasionally pedserver can fail stop/start with message.

PedServer.exe mode start

LOGGER_init failed

Failed to initialize the logger. Exiting

Resolution: Instructions now emphasize that pedserver.exe must run in an Administrator Command Prompt, and will fail if run in a non-Administrator command session.

Problem: With command lunacm:>ha list

HA Group Number displays a negative number.

However command "slot list" displays a proper number for HSM Serial Number

In ckdemo choose option (11) Slot Info, then select an HA Virtual Card Slot, no serial number information displayed for group or member. However option (12) Token Info has more details about the slot.

Resolution: Fixed.

Problem: Seeing "err Luna PED Client[2228]: error : 0 : Error scanning log files", and all logs remain in HSM and are not transferred to host.

Resolution: Fixed in Luna HSM 6.0.

Problem: The local PED uses a communication protocol that was not designed to carry the large amounts of data required to perform some SFF backup operations.

Resolution: SFF Backup documentation amended to recommend using Remote PED.

Problem: During Small Form Factor backup, if power outage or machine reboot occurs at pedserver host, backup fails with "device error". If eToken contents are checked, output shows a huge number objects obviously not correct:

lunacm:>par ar c -s etoken

Listing all objects...

Found 412316860869 backup objects:

Partition: etoken_bck

Object Type: Partition

Object UID: 6b00000c48180000ee5a0200

backup failure

(14231/14232): Backing up object with handle 14322... Failure (CKR_DEVICE_ERROR)

(14232/14232): Backing up object with handle 11817... Failure (CKR_DEVICE_ERROR)

...

Backup Complete.

14232 objects have been backed up to partition etoken_bck

Resolution: Fixed in Luna HSM 6.0.

Problem: When restart is issued, the NET-SNMP subagent loses its connection when the snmp service stops; as it should.  -However it does not reconnect once the service is back up.

Resolution: Fixed in Luna HSM 6.0.

Problem: "my public-key list" does not show the ECDSA fingerprint.

Steps to reproduce.

1) On a linux client with openssh6.2 that supports ECDSA, generate ECDSA key pair "ssh-keygen -q -t ecdsa -f id_ecdsa -N "" "

2) Copy the ecdsa pub key to SA appliance.

3) Add the key "my public-key add id_ecdsa.pub"

4) Try ssh access the SA using the ecdsa key and it is successful.

-sh-3.2# ssh admin@172.20.9.62 -i id_ecdsa

Last login: Mon Feb 3 10:06:26 2014 from 172.20.9.61

Luna SA 5.4.1-1 Command Line Shell - Copyright (c) 2001-2014 SafeNet, Inc. All rights reserved.

[local_host] lunash:>exit

5) Run "my public-key list", the ecdsa key is not displayed

Resolution: Fixed in Luna HSM 6.0.

Problem: In Luna SA, from lunash command line, run "hsm driver timeout set" without including a value; lunash shows 'success' and no error message.
Example:

[myluna] lunash:>hsm driver timeout set

Command Result : 0 (Success).

Resolution: Fixed in Luna HSM 6.0.

Problem: Command "ntls certificate monitor disable" in lunashshows that cert monitor was disabled, but in fact the command failed to shut down certmonitord service.

Resolution: Fixed in Luna HSM 6.0.

Problem: The command “package listf” should return only uploaded-but-not-yet-installed packages, but successfully installed packages are shown as well.

Resolution: Fixed in Luna HSM 6.0.

Problem: After three consecutive hsm login failures, "HSM Admin login attempts left" in output of hsm show command still shows "1 before HSM zeroization!" while the HSM has been zeroized. It should show "hsm zeroized".

Resolution: Fixed in Luna HSM 6.0.

Problem:After migrating a Luna SA from version 5.0, found that unmasking in HSM policy has been set as disallowed which potentially blocks key migration from a SIM configuration. This is a very rare case and requires a destructive capability/policy change; a general solution is not contemplated, due to the small number of customers potentially affected.

Resolution: Fixed in Luna HSM 6.0.

SafeNet, Inc.
4690 Millennium Drive
Belcamp, Maryland 21017

USA

www.safenet-inc.com/support

Provides access to the SafeNet Knowledge Base and quick downloads for various products.