Using Cryptographic Hardware
148 RSA BSAFE Crypto-C Developer’s Guide
In real life, you may never have to use this feature. Mostly you will retrieve the
internalKey
from your database, use it, close out the session and be done. But if there
is some odd case where you have the key handle and want to pass it to Crypto-C, this
is the way to do it.

Random Numbers

In our sample, we say the random object you create will not be used. If random
numbers are needed, the token will use its own random number generator. But you
do have the option of seeding that generator. For some tokens, seeding may do
nothing. But for others, if you want to add your own seed, you can. You do this
through the PKCS #11 API.
This is not a Crypto-C API. You called on Crypto-C to create a session. In return, you
received a session handle and a pointer to an array of functions. One of those
functions is a seeding routine. This is the most basic information you need to know
about PKCS #11 seeding. There is certainly more t o learn about seeding, and the other
Cryptoki functions, in the PKCS #11 specification.
Hardware Issues
Working with hardware devices introduces new issues that must be addressed. A
cryptographic key on a hardware device might never leave the device; this is part of
the security. For instance, suppose you want to produce a digital envelope. You might
use a hardware accelerator to perform DES encryption of the bulk data, then want to
encrypt the DES key with the recipient’s public key. However, when you make the
call to retrieve the key, the hardware might return a handle to the key, rather than the
key itself. This enhances security, because the key never appears “in public.”
CK_RV rv;
rv =
((CK_FUNCTION_LIST_PT)(p11Session.cryptokiFunctions))->
C_SeedRandom
((CK_SESSION_HANDLE)(p11Session.sessionHandle),
(CK_BYTE_PTR)seedBuffer,
(CK_ULONG)seedLen);