Originally, the SafeNet Luna HSMs kept all key material within the HSM, performed crypto operations within the HSM, and allowed only the results of those operations to be available outside the HSM. The only exception was for backup and restore, for which we devised a very secure, hardware-mediated transaction called cloning - sensitive material could be moved directly between HSMs in secure fashion, but was never allowed to exist outside the HSMs (so, never in computer memory or exposed on a computer bus during transactions). This was a very secure mode of operation, but it did have limitations in some areas. One such limitation was in the handling of very large masses of keys, profiles, and such material, beyond the storage capability of the HSM. We could make bigger HSMs, but somebody would always make a bigger database.
Some providers approached this growing market requirement by allowing key material to be stored off the HSM, in databases or other frameworks that permitted high-volume storage and management. SafeNet wished to address this market need, but without weakening the security (or the reputations) of our HSMs. Simply allowing the calling application to make the decision, as is done by some competing products, could not be permitted - not all application vendors consider security as strongly as they might. This is not necessarily a criticism of those application vendors. Their products fill very real needs in spaces where security, while important, takes second place to other considerations; which is a valid and growing niche. Nevertheless, we could not leave the security of key materials and the reputation of the Luna products in the hands of third parties.
The solution was to offer HSMs in two flavors addressing the different application requirements.
The two are mutually exclusive. The non-exporting version can store and handle sensitive objects only on the HSM, and can move/copy them only directly to another such non-exporting HSM via the secure cloning operation.
The exporting version can wrap key material off the HSM and unwrap key material onto the HSM, but cannot perform cloning.
One version cannot be made into the other without destroying all contents (zeroizing the HSM). The export model of Luna HSM provides the key export capability while running in full FIPS 140-2 level 3 validated mode of operation. You are not required to downgrade the security of your HSM in order for this key export to be allowed happen - in fact, you cannot. This is why we have a specifically targeted device for this purpose. As an extension of this, and as part of the continuing theme of security, the export Luna HSM does not support key cloning (which in this context you can think of as 'backup'). We wanted to ensure that customers who demand the most stringent key security cannot have this weakened by the ability for an attacker to clone keys from a non-export HSM to an export-capable HSM.
If you have need of both capabilities in your organization, you might need mixed populations of Luna HSM servers to address the respective requirements.
The configuration of your Luna HSM was set at the factory. If you need to change that configuration, contact Customer Support about the possibility of shipping it back for re-manufacture.