This is from email I sent a couple of years back upon my success in dealing with the problem

I am happy to report that I found a way to deal with the problem and I am now able to concatenate keys (or keys and data).

The initial problem was due to Eracom's CK implementation not supporting 'simple derivation operations' on keys other than CKK_GENERIC_SECRET, and concatenation is such an operation.

The PKCS standard does not dictate any such preference to key type but it is easy to see what a hassle properly concatenating keys of various types can be. So the ProtectToolkitC programmer's manual states: "Simple derivation mechanisms are restricted to working on secret keys of type CKK_GENERIC_SECRET"

I originally thought that I could simply convert my DES2 key into a generic one and perform my operation on it; however all my attempts to derive a generic key out of a DES2 key failed and late last night I was pulling virtual hair.

Two minutes to midnight I thought that maybe the assumption that we start with a DES2 key was not necessary. DES2 keys are basically randomized 16-byte blocks although some restraints do apply in order to avoid weak keys and there is a CK mechanism for generating generic secret keys of arbitrary length. So, we could basically as well be working with 16-byte generic keys instead of DES2 keys; the catch being that the HSM token should be able to store such keys.

This morning I tested creation and token storage operations for generic keys and they worked fine. Then, on revision 211, I tried the concatenation operation and it worked with no problems at all. The concatenation involved 8 bytes of data plus a 16 byte key and I could derive from that either a 24 byte generic key or a DES3 key. I was also able to wrap (encrypt) that key with the imported MS public RSA key. All operations were tested successfully with the adapter set on FIPS 140-2 L3 mode of operation.

Note here that storing these keys in the HSM as generic keys appears to be the only way if one wants to be able to perform secure (in HSM) concatenation operations. However, if we so wish we can probably convert these 16 byte generic keys to DES2 keys (with their parity bits properly set) before we wrap and disseminate them. The programmer's manual unambiguously states that DES type of keys can be derived out of generic ones.

So, we will need a keygen utility after all but thanks to all the needed functionality already being implemented in the CK wrapper class this will be a cinch. It will just be a cpp file that links to the wrapper and within its main() calls a few wrapper methods to create the needed keys. I am thinking of naming it something like 'setupToken' as it will do all the following:

* create the needed named keys in the token
* make the token read only
* make the token use a secure PIN path (PIN pad)

The last two are not implemented yet but they do not seem too frightening.

I will now proceed with putting together this utility while awaiting input on the latest developments.

I forgot to mention that instead of using the CKM_CONCATENATE_DATA_AND_BASE mechanism (which is listed in the programmer's manual as non FIPS compliant) I am converting the data, that needs to be prepended to the key, into an 8 byte generic key and then using the CKM_CONCATENATE_BASE_AND_KEY to concatenate the two keys. Although this mechanism is Eracom proprietary it is listed as FIPS compliant.