Comparing PTK to Luna FM SDK, and Porting FMs
This chapter describes how to compare the Luna FM SDK and PTK FM SDK to determine what solution is best for your application and how you would port a PTK FM to Luna.
The actual differences between the FM SDK products will change as new versions of the respective products are released.
In this chapter we compare :
|
Luna FM SDK |
7.4 |
|
PTK PPO |
5.7 |
FM source code designed for the PTK PPO SDK will need to be changed before it can be successfully compiled and linked with the Luna FM SDK.
The Luna FM SDK has an overlapping feature set with the PPO feature set.
There are functions available in Luna FM SDK but not in PPO and vice-versa.
The amount of effort to convert your FM source from PPO to Luna FM SDK will depend on which features your FM uses.
The following sections describe these differences.
Summary
This section summarizes the features that differ between PTK and Luna FM SDK and some suggestions on how to migrate FM code that uses them.
|
Feature |
Overview |
Details |
|---|---|---|
|
HSM Management and Security Features |
Luna has optional multifactor quorum authentication and tool set is different. |
|
|
Programming APIs |
Luna has new FMCE Api and limited CipherObj support, Cryptoki object and mechanism lists differ. |
|
|
Software Emulation |
Only PTK has an emulation for FM development |
|
|
Cryptoki function Patching |
Only the PTK can allow the FM to intercept and replace PKCS#11 function calls. |
|
|
Smart card key backup |
Luna HSM Firmware 7.4.0 and newer supports Cloning only to another FM Enabled HSM as a backup scheme. PTK can use smartcard as a PKCS#11 slot for data storage |
No Luna Backup HSM G5 supported for either Luna or PTK. |
|
Net server support for allow network access to a PCI HSM |
Luna has no equivalent |
|
|
Enter keys from components by keyboard + Verifone PinPad |
Keyboard entry on Luna is possible with special tool |
No pinpad support on Luna unless an FM implements that support itself. |
HSM Management and Security Features
Here is a description of roles and services, key management policy and authentication techniques for each HSM.
Configuration
The PTK HSM may be ordered with different performance levels but otherwise all configuration is done by the Administrator setting security policy flags.
The Luna HSM may be ordered with different Capabilities for performance, key extraction policy, maximum user tokens and, in addition, the Security Officer can change Security Policy settings.
Roles
|
HSM |
Administration Partition |
User Partition |
|---|---|---|
|
PTK |
Admin SO Administrator Auditor |
Security Officer User |
|
Luna |
HSM Security Officer Administrator Auditor |
Partition Security Officer Crypto Officer Crypto User
|
Authentication and Activation
Luna
Luna HSMs employ a model wherein all material on the HSM remains encrypted except when items are temporarily decrypted into volatile HSM memory for use. Thus any power loss or tamper event causes decrypted material to evaporate, with no overt action needed. Luna requires authentication to each partition before any cryptographic operation can be performed on that partition.
For a password-authenticated partition, that authentication is done by means of a password (something you know), so the FM can provide that password during C_Login.
If the Luna HSM is multifactor quorum-authenticated, then authentication is layered, requiring authentication with a physical token (something you have) before authentication with a challenge password (something you know), that can be provided by the FM during C_Login.
The first layer is called Activation and requires that the relevant PED key(s) be presented via the Luna PED. A multifactor quorum-authenticated HSM or partition requires appropriate PED keys for each of the HSM Security Officer, Administrator, Partition Security Officer, and Crypto Officer and Crypto User Roles.
For convenience of operation, Activation remains in force until interrupted or until logout is performed. Activation can be made persistent by enabling Auto-activation, which allows Activation to automatically reassert following interruptions or outages up to two hours in duration.
So your FM will not be able to access any keys on a Cryptoki partition until that partition is activated, but as long as the partition remains activated, the process of authentication by the FM is identical to the authentication process on a password-authenticated partition.
Activation occurs manually when a user is authenticated to the Token (logs in), or Automatically if Auto-Activation Policy is enabled.
In addition to the requirement for a physical token to place the partition in a state receptive to password login, some very high-security regimes can choose to employ additional factors for authentication:
>The PED keys can optionally be initialized with MofN split, or shared, secret (also called quorum), thus requiring that more than one trusted person must be present, with their portion of the split secret, in order to perform that operation. So, for example, if the HSM SO secret was initialized as M=2 and N=5, then 5 people would each be given a blue PED key containing a 1/5 portion of the secret, and 2 of those people (any two) would be needed whenever the HSM SO wanted to log in.
>Each PED key can optionally be assigned a multi-digit PIN that must be entered on the Luna PED keypad when that PED key is presented. A PIN is an optional (until invoked) Luna PED function, and is completely unrelated to the challenge password that is presented by applications and FMs.
PTK
PTK requires no Activation – it uses a Tamper Response model – so keys are always available unless the HSM has detected a Tamper event.
PTK can optionally require an OTP Token for Administrator and/or User Roles.
Both HSMs require a user to login before they can access private keys.
The FM can login with C_Login on PTK HSMs to access Private Objects in a partition.
What Does It Mean?
If your Luna partition uses a Luna PED then your client application needs to log in before calling FM functions. Once the SO has activated the partition with the appropriate PED key, authentication process is the same as for a password authenticated partition.
If your Luna partition uses passwords then you can perform login from the client or the FM.
Tool Set
The PTK and Luna have these tools :
| PTK Tool | Luna Tool |
|---|---|
|
Hsmreset |
LunaSH hsm reset lunareset /dev/k7kp0 |
|
Hsmstate |
LunaCM, LunaSH |
|
Ctconf |
LunaCM, LunaSH |
|
Ctkmu |
CMU, ckdemo |
|
Ctcert |
CMU |
|
Ctstat |
LunaCM, LunaSH |
|
Ctcheck |
LunaCM, LunaSH |
|
Graphical KMU |
- |
|
Windows ctbrowse |
- |
|
gctAdmin |
- |
|
- |
Salogin |
Per Partition SO introduced by Admin
PTK Requires Administrator role to create user partitions/Tokens, while Luna uses the Security Officer Role.
PTK in FIPS mode requires Administrator role to allow a user partition to be initialized with Partition SO (Admin introduces SO) but Luna never requires an SO for this.
FM Programming APIs
FMCE API and CipherObj
Luna has new FMCE API to provide raw key cryptography similar to the CipherObj model used in PTK.
The Luna FM SDK also has a limited CipherObj support to help with porting – refer to Luna FM SDK User Guide for a complete list.
The actual list of mechanism supported in FMCE, CipherObjs and Cryptoki interface overlap but differ between the HSMs. Refer to Luna and PTK User documentation for complete lists.
Public Key Certificate Management
PTK supports CSR and Public Key Certificate creation in firmware using extension mechanisms so these capabilities are available to PTK FMs.
Luna performs these operations in the client side CMU tool and so the FM has no access to these operations and must provide any implementations itself.
Cryptoki Attributes
The PTK Cryptoki provides extension attributes which are not in the Luna Cryptoki.
>CKA_ISSUER_STR
>CKA_SUBJECT_STR
>CKA_SERIAL_NUMBER_INT
>CKA_SERIAL_NUMBER_STR
>CKA_ENUM_ATTRIBUTE
>CKA_EXPORT
>CKA_EXPORTABLE
>CKA_IMPORT
>CKA_KEY_SIZE
>CKA_TIME_STAMP
>CKA_TRUSTED
Client and FM Extension Functions
These functions are not supported. There is no workaround.
>CT_InitToken()
>CT_ResetToken()
>CT_CopyObject
>CKM_DECODE_PKCS7
>FM_SetAppUserData
>FM_SetTokenUserData
>FM_SetTokenAppUserData
>FM_SetSlotUserData
>CT_PresentTicket
These functions are not supported but there is a workaround.
>FM_GetCurrentOid() and FM_GetCurrentPid()
>Use FM_GetCurrentAppId()
JHSM
PTK has JHSM, a Java interface for custom command dispatch i.e. Java version of MD_SendReceive(),
The PTK version should work with the Luna ethsm library.
Compatibility Header Files
In addition to the normal Luna FM SDK header set there are compat headers (detailed in the FM SDK User Guide).
These headers emulate PTK manifest constants and functions using the normal Luna headers. They are provided to ease PTK FM porting to Luna.
PTK Function Patching
OS_GetCprovFuncTable()
This function is not implemented in the Luna HSM.
Because this feature is missing it is not possible to patch/intercept Cryptoki calls to the HSM.
The reason is that Luna HSM Client functions are not equivalent to Cryptoki requests; they make up a custom protocol called PcProt.
PTK FMs developers had two reasons to patch the cryptoki table.
>Since all administration of the PTK HSM is done with Cryptoki calls the management of the HSM could be modified.
>Custom Mechanisms could be implemented.
Administration Patching
If the Cryptoki function patching is intended to enforce a new security policy (for example, controlling the slot on which an application can open a session on) then this type of FM capability cannot be ported to Luna FM SDK.
Read Only Tokens Solution
If the requirement is to have keys in a user slot visible to the Client but is otherwise Read-only, then the following solution can be used:
>Set Usage and extraction Attributes of all key objects to false
>Login the client application as Crypto User Role and pass object handles to the FM using Custom functions.
>The FM can use CT_SetPrivilageLevel to achieve Crypto Officer access to the keys/partition.
Custom Mechanisms
If the Cryptoki patching is used to implement a custom mechanism then you can use the following workaround.
Implement a custom request to the FM to replicate the functionality of the patched Cryptoki function call.
Several issues arise when designing a custom function to replace a Cryptoki call:
>Object handles: these must be passed to the Custom function. Users should assume they can be encoded as 32 bit Integers.
>Slot Numbers: slot numbers seen by the application must be converted to the equivalent embedded Cryptoki slot number using MD_GetEmbeddedSlotID() and associated HSM index number with MD_GetHsmIndexForSlot().
>Session Handles: session handles provided by the host side Cryptoki library to the application cannot be used by the FM because they will not be recognized by the Embedded Cryptoki library used by the FM.
Therefore the FM must open its own Cryptoki sessions.
Depending on the system architecture the developer can either:
•For multi-part commands: Implement a custom command to open a session and return the handle to the application where it can be passed in with each subsequent call or
•For Single Part Commands: find slot number of the Application session (use C_GetSessionInfo) and translate it to the matching embedded slot MD_GetEmbeddedSlotID() then send that slot number to with your custom command request. The FM can use that slot number to temporarily open a session locally to do the single part command.
>Object Attributes: the implementer needs to encode/decode any object attributes that will be passed in or out as part of the Custom command
FM source code designed for the legacy ProtectServer FM SDK will need to be converted to be successfully compiled and linked with the Luna FM SDK package.
The amount of effort to convert your FM source from PPO to Luna FM SDK package will depend on which features your FM uses.
A large number of PPO features are provided by Luna FM SDK package either directly or through the compatibility headers.
The following section lists features missing from Luna FM SDK package and provides some suggestions on how to migrate the FM code that uses them.
See Compiling FMs for more information on converting legacy PTK FMs for use with the Luna FM SDK package.
FM_GetCurrentOid() and FM_GetCurrentPid()
FM_SetAppUserData, FM_SetTokenUserData, FM_SetTokenAppUserData, FM_SetSlotUserData
These functions are not supported. There is currently no workaround.
OS_GetCprovFuncTable()
This is the largest change. As a result of this feature missing, it is not possible to patch Cryptoki calls to the HSM.
If the Cryptoki function patching is intended to enforce a new security policy (i.e controlling what slot an application can open a session on) then this feature cannot be ported to Luna FM SDK package.
However, if the patching is used to implement a custom mechanism, then the work around is to implement a custom request to the FM to replicate the functionality of the patched Cryptoki function call.
There are several issues which arise when designing a custom function to replace a Cryptoki call:
| Object Handles | These need to be passed to the Custom function. Users should assume they can be encoded as 32 bit integers. |
| Slot Numbers | Slot numbers seen by the application must be converted to the equivalent embedded Cryptoki slot number using MD_Get_EmbeddedSlotID() and the associated HSM index number with MD_GetHsmIndexForSlot(). |
| Session Handles |
Session handles provided by the host side Cryptoki library to the application cannot be used by the FM because they will not be recognisable by the embedded Cryptoki library. The FM must open its own Cryptoki sessions to make Cryptoki calls that need a session handle. Depending on the system architecture the developer can: >For multi-part commands: implement a custom command to open a session and return the handle to the application where it can be passed in with each subsequent call. >For single part commands: find the slot number of the Application session (use C_GetSessionInfo) and translate it to the matching embedded slot MD_GetEmbeddedSlotId() then send that slot number to the HSM with your custom command request. The FM can use that slot number to temporarily open a session locally due to the single part command. |
| Object Attributes | The implementer needs to encode/decode any object attributes that will be passed in or out of the custom command. |
