How to use CKO_VENDOR_DEFINED in pkcs#11

Question

Has anyone used CKO_VENDOR_DEFINED to create a key or a data object?

There is hardly any documentation (including the mother load from Oasis) about how to do it, or

Answer 1

You can take a look at OpenPGP extension to PKCS #11 where CKC_OPENPGP is defined as:

#define CKC_OPENPGP  (CKC_VENDOR_DEFINED|0x00504750)

I've seen also commercial implementations introducing CK*_VENDOR_DEFINED extensions this way.

Answer 2

(AFAIK) vendor defined object types must be implemented inside the HSM unit firmware (in theory, the host-side cryptoki library could introduce some additional "virtual" object types, but this probably would not make any sense as the overall security model would stay the same -- because the host-side cryptoki code runs in an untrusted execution environment).

If you need more control than provided by the vanilla PKCS#11 you have some choices:

1. Use existing vendor extensions -- some vendors add their own extensions designed to solve common use-cases. Read your documentation or contact your vendor directly.

2. Implement a custom firmware -- some products allow the end-user to run a custom code inside the HSM device. You can implement your model this way.

SafeNet ProtectServer:

SafeNet ProtectServer HSMs offer a unique level of flexibility for application developers to create their own firmware and execute it within the secure confines of the HSM. Known as functionality modules, the toolkits provide a comprehensive facility to develop and deploy custom firmware.

Thales nShield:

Most nShield HSMs also support the unique ability to host critical applications within the hardened security boundary, so you can establish tamper-resistant business processes in addition to protecting cryptographic operations.

Utimaco CryptoServer:

The CryptoServer Software Development Kit (SDK) is the professional development environment for all Utimaco Hardware Security Modules. It enables integrators and end-users to create specific applications, e.g. proprietary algorithms, custom key derivation procedures or complex protocols that run in the tamper-proof environment of the CryptoServer Hardware Security Module. As the SDK provides full access to the Utimaco base firmware, custom firmware modules can be developed in a very short time frame.

3. Use some other technology -- do not use HSMs at all and leverage some other secure device. Specifically smartcards might be a viable alternative as some of them can be programmed (at least Java Card or MULTOS ones). On the other hand the performance and range of supported algorithms is quite limited here (depends on your use-case).