|
||||||||||
| PREV CLASS NEXT CLASS | FRAMES NO FRAMES | |||||||||
| SUMMARY: NESTED | FIELD | CONSTR | METHOD | DETAIL: FIELD | CONSTR | METHOD |
java.lang.Object com.joelhockey.jacknji11.Native
public class Native
JNA direct mapping interface for PKCS#11 functions. Loads native library 'cryptoki' - either cryptoki.dll or libcryptoki.so or whatever the normal native thing is on your exotic platform. jacknji11 provides 3 interfaces for calling cryptoki functions.
Native
provides the lowest level
JNA direct mapping to the 'C_*'
functions. There is little
reason why you would ever want to invoke it directly, but you can.
C
provides the exact same functions
as Native
by calling through to the
corresponding native method. The 'C_'
at the start of the
function name is removed since the 'C.'
when you call the
static methods of this class looks similar. In addition to calling
the native methods, C
provides logging
throug apache commons logging and handles some of the low-level JNA
plumbing such as updating some values if they are changed within the
native call on a function. You can use this if you require fine-grain
control over something such as checking
CKR
return codes.
CE
(Cryptoki
with Exceptions) provides the most user-friendly interface
and is the preferred interface to use. It calls
related function(s) in C
,
and converts any non-zero return values into a
CKRException
. It automatically resizes
arrays and other helpful things.
| Constructor Summary | |
|---|---|
Native()
|
| Method Summary | |
|---|---|
static int |
C_CancelFunction(com.sun.jna.NativeLong hSession)
In previous versions of Cryptoki, C_CancelFunction cancelled a function running in parallel with an application. |
static int |
C_CloseAllSessions(com.sun.jna.NativeLong slotID)
C_CloseAllSessions closes all sessions an application has with a token. |
static int |
C_CloseSession(com.sun.jna.NativeLong hSession)
C_CloseSession closes a session between an application and a token. |
static int |
C_CopyObject(com.sun.jna.NativeLong hSession,
com.sun.jna.NativeLong hObject,
Template pTemplate,
com.sun.jna.NativeLong ulCount,
LongRef phNewObject)
C_CopyObject copies an object, creating a new object for the copy. |
static int |
C_CreateObject(com.sun.jna.NativeLong hSession,
Template pTemplate,
com.sun.jna.NativeLong ulCount,
LongRef phObject)
C_CreateObject creates a new object. |
static int |
C_Decrypt(com.sun.jna.NativeLong hSession,
byte[] pEncryptedData,
com.sun.jna.NativeLong ulEncryptedDataLen,
byte[] pData,
LongRef pulDataLen)
C_Decrypt decrypts encrypted data in a single part. |
static int |
C_DecryptDigestUpdate(com.sun.jna.NativeLong hSession,
byte[] pEncryptedPart,
com.sun.jna.NativeLong ulEncryptedPartLen,
byte[] pPart,
LongRef pulPartLen)
C_DecryptDigestUpdate continues a multiple-part combined decryption and digest operation, processing another data part. |
static int |
C_DecryptFinal(com.sun.jna.NativeLong hSession,
byte[] pLastPart,
LongRef pulLastPartLen)
C_DecryptFinal finishes a multiple-part decryption operation. |
static int |
C_DecryptInit(com.sun.jna.NativeLong hSession,
CKM pMechanism,
com.sun.jna.NativeLong hKey)
C_DecryptInit initializes a decryption operation. |
static int |
C_DecryptUpdate(com.sun.jna.NativeLong hSession,
byte[] pEncryptedPart,
com.sun.jna.NativeLong ulEncryptedPartLen,
byte[] pData,
LongRef pulDataLen)
C_DecryptUpdate continues a multiple-part decryption operation, processing another encrypted data part. |
static int |
C_DecryptVerifyUpdate(com.sun.jna.NativeLong hSession,
byte[] pEncryptedPart,
com.sun.jna.NativeLong ulEncryptedPartLen,
byte[] pPart,
LongRef pulPartLen)
C_DecryptVerifyUpdate continues a multiple-part combined decryption and verification operation, processing another data part. |
static int |
C_DeriveKey(com.sun.jna.NativeLong hSession,
CKM pMechanism,
com.sun.jna.NativeLong hBaseKey,
Template pTemplate,
com.sun.jna.NativeLong ulAttributeCount,
LongRef phKey)
C_DeriveKey derives a key from a base key, creating a new key object. |
static int |
C_DestroyObject(com.sun.jna.NativeLong hSession,
com.sun.jna.NativeLong hObject)
C_DestroyObject destroys an object. |
static int |
C_Digest(com.sun.jna.NativeLong hSession,
byte[] pData,
com.sun.jna.NativeLong ulDataLen,
byte[] pDigest,
LongRef pulDigestLen)
C_Digest digests data in a single part. |
static int |
C_DigestEncryptUpdate(com.sun.jna.NativeLong hSession,
byte[] pPart,
com.sun.jna.NativeLong ulPartLen,
byte[] pEncryptedPart,
LongRef ulEncryptedPartLen)
C_DigestEncryptUpdate continues multiple-part digest and encryption operations, processing another data part. |
static int |
C_DigestFinal(com.sun.jna.NativeLong hSession,
byte[] pDigest,
LongRef pulDigestLen)
C_DigestFinal finishes a multiple-part message-digesting operation, returning the message digest. |
static int |
C_DigestInit(com.sun.jna.NativeLong hSession,
CKM pMechanism)
C_DigestInit initializes a message-digesting operation. |
static int |
C_DigestKey(com.sun.jna.NativeLong hSession,
com.sun.jna.NativeLong hKey)
C_DigestKey continues a multiple-part message-digesting operation by digesting the value of a secret key. |
static int |
C_DigestUpdate(com.sun.jna.NativeLong hSession,
byte[] pPart,
com.sun.jna.NativeLong ulPartLen)
C_DigestUpdate continues a multiple-part message-digesting operation, processing another data part. |
static int |
C_Encrypt(com.sun.jna.NativeLong hSession,
byte[] pData,
com.sun.jna.NativeLong ulDataLen,
byte[] pEncryptedData,
LongRef pulEncryptedDataLen)
C_Encrypt encrypts single-part data. |
static int |
C_EncryptFinal(com.sun.jna.NativeLong hSession,
byte[] pLastEncryptedPart,
LongRef pulLastEncryptedPartLen)
C_EncryptFinal finishes a multiple-part encryption operation. |
static int |
C_EncryptInit(com.sun.jna.NativeLong hSession,
CKM pMechanism,
com.sun.jna.NativeLong hKey)
C_EncryptInit initializes an encryption operation. |
static int |
C_EncryptUpdate(com.sun.jna.NativeLong hSession,
byte[] pPart,
com.sun.jna.NativeLong ulPartLen,
byte[] pEncryptedPart,
LongRef pulEncryptedPartLen)
C_EncryptUpdate continues a multiple-part encryption operation, processing another data part. |
static int |
C_Finalize(com.sun.jna.Pointer pReserved)
C_Finalize is called to indicate that an application is finished with the Cryptoki library. |
static int |
C_FindObjects(com.sun.jna.NativeLong hSession,
LongArray phObject,
com.sun.jna.NativeLong ulMaxObjectCount,
LongRef pulObjectCount)
C_FindObjects continues a search for token and session objects that match a template, obtaining additional object handles. |
static int |
C_FindObjectsFinal(com.sun.jna.NativeLong hSession)
C_FindObjectsFinal terminates a search for token and session objects. |
static int |
C_FindObjectsInit(com.sun.jna.NativeLong hSession,
Template pTemplate,
com.sun.jna.NativeLong ulCount)
C_FindObjectsInit initializes a search for token and session objects that match a template. |
static int |
C_GenerateKey(com.sun.jna.NativeLong hSession,
CKM pMechanism,
Template pTemplate,
com.sun.jna.NativeLong ulCount,
LongRef phKey)
C_GenerateKey generates a secret key or set of domain parameters, creating a new object. |
static int |
C_GenerateKeyPair(com.sun.jna.NativeLong hSession,
CKM pMechanism,
Template pPublicKeyTemplate,
com.sun.jna.NativeLong ulPublicKeyAttributeCount,
Template pPrivateKeyTemplate,
com.sun.jna.NativeLong ulPrivateKeyAttributeCount,
LongRef phPublicKey,
LongRef phPrivateKey)
C_GenerateKeyPair generates a public/private key pair, creating new key objects. |
static int |
C_GenerateRandom(com.sun.jna.NativeLong hSession,
byte[] RandomData,
com.sun.jna.NativeLong ulRandomLen)
C_GenerateRandom generates random or pseudo-random data. |
static int |
C_GetAttributeValue(com.sun.jna.NativeLong hSession,
com.sun.jna.NativeLong hObject,
Template pTemplate,
com.sun.jna.NativeLong ulCount)
C_GetAttributeValue obtains the value of one or more attributes of an object. |
static int |
C_GetFunctionStatus(com.sun.jna.NativeLong hSession)
In previous versions of Cryptoki, C_GetFunctionStatus obtained the status of a function running in parallel with an application. |
static int |
C_GetInfo(CK_INFO pInfo)
C_GetInfo returns general information about Cryptoki. |
static int |
C_GetMechanismInfo(com.sun.jna.NativeLong slotID,
com.sun.jna.NativeLong type,
CK_MECHANISM_INFO pInfo)
C_GetMechanismInfo obtains information about a particular mechanism possibly supported by a token. |
static int |
C_GetMechanismList(com.sun.jna.NativeLong slotID,
LongArray pMechanismList,
LongRef pulCount)
C_GetMechanismList is used to obtain a list of mechanism types supported by a token. |
static int |
C_GetObjectSize(com.sun.jna.NativeLong hSession,
com.sun.jna.NativeLong hObject,
LongRef pulSize)
C_GetObjectSize gets the size of an object in bytes. |
static int |
C_GetOperationState(com.sun.jna.NativeLong hSession,
byte[] pOperationState,
LongRef pulOperationStateLen)
C_GetOperationState obtains a copy of the cryptographic operations state of a session, encoded as a string of bytes. |
static int |
C_GetSessionInfo(com.sun.jna.NativeLong hSession,
CK_SESSION_INFO pInfo)
C_GetSessionInfo obtains information about a session. |
static int |
C_GetSlotInfo(com.sun.jna.NativeLong slotID,
CK_SLOT_INFO pInfo)
C_GetSlotInfo obtains information about a particular slot in the system. |
static int |
C_GetSlotList(byte tokenPresent,
LongArray pSlotList,
LongRef pulCount)
C_GetSlotList is used to obtain a list of slots in the system. |
static int |
C_GetTokenInfo(com.sun.jna.NativeLong slotID,
CK_TOKEN_INFO pInfo)
C_GetTokenInfo obtains information about a particular token in the system. |
static int |
C_Initialize(CK_C_INITIALIZE_ARGS pInitArgs)
C_Initialize initializes the Cryptoki library. |
static int |
C_InitPIN(com.sun.jna.NativeLong hSession,
byte[] pPin,
com.sun.jna.NativeLong ulPinLen)
C_InitPIN initializes the normal user’s PIN. |
static int |
C_InitToken(com.sun.jna.NativeLong slotID,
byte[] pPin,
com.sun.jna.NativeLong ulPinLen,
byte[] pLabel32)
C_InitToken initializes a token. |
static int |
C_Login(com.sun.jna.NativeLong hSession,
com.sun.jna.NativeLong userType,
byte[] pPin,
com.sun.jna.NativeLong ulPinLen)
C_Login logs a user into a token. |
static int |
C_Logout(com.sun.jna.NativeLong hSession)
C_Logout logs a user out from a token. |
static int |
C_OpenSession(com.sun.jna.NativeLong slotID,
com.sun.jna.NativeLong flags,
com.sun.jna.Pointer application,
CK_NOTIFY notify,
LongRef phSession)
C_OpenSession opens a session between an application and a token in a particular slot. |
static int |
C_SeedRandom(com.sun.jna.NativeLong hSession,
byte[] pSeed,
com.sun.jna.NativeLong ulSeedLen)
C_SeedRandom mixes additional seed material into the token’s random number generator. |
static int |
C_SetAttributeValue(com.sun.jna.NativeLong hSession,
com.sun.jna.NativeLong hObject,
Template pTemplate,
com.sun.jna.NativeLong ulCount)
C_SetAttributeValue modifies the value of one or more attributes of an object. |
static int |
C_SetOperationState(com.sun.jna.NativeLong hSession,
byte[] pOperationState,
com.sun.jna.NativeLong pulOperationStateLen,
com.sun.jna.NativeLong hEncryptionKey,
com.sun.jna.NativeLong hAuthenticationKey)
C_SetOperationState restores the cryptographic operations state of a session from a string of bytes obtained with C_GetOperationState. |
static int |
C_SetPIN(com.sun.jna.NativeLong hSession,
byte[] pOldPin,
com.sun.jna.NativeLong ulOldLen,
byte[] pNewPin,
com.sun.jna.NativeLong ulNewLen)
C_SetPIN modifies the PIN of the user that is currently logged in, or the CKU_USER PIN if the session is not logged in. |
static int |
C_Sign(com.sun.jna.NativeLong hSession,
byte[] pData,
com.sun.jna.NativeLong ulDataLen,
byte[] pSignature,
LongRef pulSignatureLen)
C_Sign signs data in a single part, where the signature is an appendix to the data. |
static int |
C_SignEncryptUpdate(com.sun.jna.NativeLong hSession,
byte[] pPart,
com.sun.jna.NativeLong ulPartLen,
byte[] pEncryptedPart,
LongRef pulEncryptedPartLen)
C_SignEncryptUpdate continues a multiple-part combined signature and encryption operation, processing another data part. |
static int |
C_SignFinal(com.sun.jna.NativeLong hSession,
byte[] pSignature,
LongRef pulSignatureLen)
C_SignFinal finishes a multiple-part signature operation, returning the signature. |
static int |
C_SignInit(com.sun.jna.NativeLong hSession,
CKM pMechanism,
com.sun.jna.NativeLong hKey)
C_SignInit initializes a signature operation, where the signature is an appendix to the data. |
static int |
C_SignRecover(com.sun.jna.NativeLong hSession,
byte[] pData,
com.sun.jna.NativeLong ulDataLen,
byte[] pSignature,
LongRef pulSignatureLen)
C_SignRecover signs data in a single operation, where the data can be recovered from the signature. |
static int |
C_SignRecoverInit(com.sun.jna.NativeLong hSession,
CKM pMechanism,
com.sun.jna.NativeLong hKey)
C_SignRecoverInit initializes a signature operation, where the data can be recovered from the signature. |
static int |
C_SignUpdate(com.sun.jna.NativeLong hSession,
byte[] pPart,
com.sun.jna.NativeLong ulPartLen)
C_SignUpdate continues a multiple-part signature operation, processing another data part. |
static int |
C_UnwrapKey(com.sun.jna.NativeLong hSession,
CKM pMechanism,
com.sun.jna.NativeLong pUnwrappingKey,
byte[] pWrappedKey,
com.sun.jna.NativeLong ulWrappedKeyLen,
Template pTemplate,
com.sun.jna.NativeLong ulAttributeCount,
LongRef hKey)
C_UnwrapKey unwraps (i.e. |
static int |
C_Verify(com.sun.jna.NativeLong hSession,
byte[] pData,
com.sun.jna.NativeLong ulDataLen,
byte[] pSignature,
com.sun.jna.NativeLong ulSignatureLen)
C_Verify verifies a signature in a single-part operation, where the signature is an appendix to the data. |
static int |
C_VerifyFinal(com.sun.jna.NativeLong hSession,
byte[] pSignature,
com.sun.jna.NativeLong ulSignatureLen)
C_VerifyFinal finishes a multiple-part verification operation, checking the signature. |
static int |
C_VerifyInit(com.sun.jna.NativeLong hSession,
CKM pMechanism,
com.sun.jna.NativeLong hKey)
C_VerifyInit initializes a verification operation, where the signature is an appendix to the data. |
static int |
C_VerifyRecover(com.sun.jna.NativeLong hSession,
byte[] pSignature,
com.sun.jna.NativeLong ulSignatureLen,
byte[] pData,
LongRef pulDataLen)
C_VerifyRecover verifies a signature in a single-part operation, where the data is recovered from the signature. |
static int |
C_VerifyRecoverInit(com.sun.jna.NativeLong hSession,
CKM pMechanism,
com.sun.jna.NativeLong hKey)
C_VerifyRecoverInit initializes a signature verification operation, where the data is recovered from the signature. |
static int |
C_VerifyUpdate(com.sun.jna.NativeLong hSession,
byte[] pPart,
com.sun.jna.NativeLong ulPartLen)
C_VerifyUpdate continues a multiple-part verification operation, processing another data part. |
static int |
C_WaitForSlotEvent(com.sun.jna.NativeLong flags,
LongRef pSlot,
com.sun.jna.Pointer pReserved)
C_WaitForSlotEvent waits for a slot event, such as token insertion or token removal, to occur. |
static int |
C_WrapKey(com.sun.jna.NativeLong hSession,
CKM pMechanism,
com.sun.jna.NativeLong hWrappingKey,
com.sun.jna.NativeLong hKey,
byte[] pWrappedKey,
LongRef pulWrappedKeyLen)
C_WrapKey wraps (i.e., encrypts) a private or secret key. |
| Methods inherited from class java.lang.Object |
|---|
clone, equals, finalize, getClass, hashCode, notify, notifyAll, toString, wait, wait, wait |
| Constructor Detail |
|---|
public Native()
| Method Detail |
|---|
public static int C_Initialize(CK_C_INITIALIZE_ARGS pInitArgs)
If pInitArgs is non-NULL_PTR, C_Initialize should cast it to a CK_C_INITIALIZE_ARGS_PTR and then dereference the resulting pointer to obtain the CK_C_INITIALIZE_ARGS fields CreateMutex, DestroyMutex, LockMutex, UnlockMutex, flags, and pReserved. For this version of Cryptoki, the value of pReserved thereby obtained must be NULL_PTR; if it’s not, then C_Initialize should return with the value CKR_ARGUMENTS_BAD.
If the CKF_LIBRARY_CANT_CREATE_OS_THREADS flag in the flags field is set, that indicates that application threads which are executing calls to the Cryptoki library are not permitted to use the native operation system calls to spawn off new threads. In other words, the library’s code may not create its own threads. If the library is unable to function properly under this restriction, C_Initialize should return with the value CKR_NEED_TO_CREATE_THREADS.
A call to C_Initialize specifies one of four different ways to support multi-threaded access via the value of the CKF_OS_LOCKING_OK flag in the flags field and the values of the CreateMutex, DestroyMutex, LockMutex, and UnlockMutex function pointer fields:
If some, but not all, of the supplied function pointers to C_Initialize are non- NULL_PTR, then C_Initialize should return with the value CKR_ARGUMENTS_BAD.
A call to C_Initialize with pInitArgs set to NULL_PTR is treated like a call to C_Initialize with pInitArgs pointing to a CK_C_INITIALIZE_ARGS which has the CreateMutex, DestroyMutex, LockMutex, UnlockMutex, and pReserved fields set to NULL_PTR, and has the flags field set to 0.
C_Initialize should be the first Cryptoki call made by an application, except for calls to C_GetFunctionList. What this function actually does is implementation-dependent; typically, it might cause Cryptoki to initialize its internal memory buffers, or any other resources it requires.
If several applications are using Cryptoki, each one should call C_Initialize. Every call to C_Initialize should (eventually) be succeeded by a single call to C_Finalize.
pInitArgs
- recommend setting null for mutexes and flags to CK_C_INITIALIZE_ARGS.CKF_OS_LOCKING_OK
CKR.ARGUMENTS_BAD
, CKR.CANT_LOCK
,
CKR.CRYPTOKI_ALREADY_INITIALIZED
, CKR.FUNCTION_FAILED
,
CKR.GENERAL_ERROR
, CKR.HOST_MEMORY
,
CKR.NEED_TO_CREATE_THREADS
, CKR.OK
public static int C_Finalize(com.sun.jna.Pointer pReserved)
If several applications are using Cryptoki, each one should call C_Finalize. Each application’s call to C_Finalize should be preceded by a single call to C_Initialize; in between the two calls, an application can make calls to other Cryptoki functions. See Section 6.6 for more details.
Despite the fact that the parameters supplied to C_Initialize can in general allow for safe multi-threaded access to a Cryptoki library, the behavior of C_Finalize is nevertheless undefined if it is called by an application while other threads of the application are making Cryptoki calls. The exception to this exceptional behavior of C_Finalize occurs when a thread calls C_Finalize while another of the application’s threads is blocking on Cryptoki’s C_WaitForSlotEvent function. When this happens, the blocked thread becomes unblocked and returns the value CKR_CRYPTOKI_NOT_INITIALIZED. See C_WaitForSlotEvent for more information.
pReserved
- reserved for future use, must be null
CKR.ARGUMENTS_BAD
, CKR.CRYPTOKI_NOT_INITIALIZED
,
CKR.FUNCTION_FAILED
, CKR.GENERAL_ERROR
, CKR.HOST_MEMORY
,
CKR.OK
public static int C_GetInfo(CK_INFO pInfo)
pInfo
- location that receives information
CKR.ARGUMENTS_BAD
, CKR.CRYPTOKI_NOT_INITIALIZED
,
CKR.FUNCTION_FAILED
, CKR.GENERAL_ERROR
, CKR.HOST_MEMORY
,
CKR.OK
public static int C_GetSlotList(byte tokenPresent, LongArray pSlotList, LongRef pulCount)
Because C_GetSlotList does not allocate any space of its own, an application will often call C_GetSlotList twice (or sometimes even more times—if an application is trying to get a list of all slots with a token present, then the number of such slots can (unfortunately) change between when the application asks for how many such slots there are and when the application asks for the slots themselves). However, multiple calls to C_GetSlotList are by no means required.
All slots which C_GetSlotList reports must be able to be queried as valid slots by C_GetSlotInfo. Furthermore, the set of slots accessible through a Cryptoki library is checked at the time that C_GetSlotList, for list length prediction (NULL pSlotList argument) is called. If an application calls C_GetSlotList with a non-NULL pSlotList, and then the user adds or removes a hardware device, the changed slot list will only be visible and effective if C_GetSlotList is called again with NULL. Even if C_ GetSlotList is successfully called this way, it may or may not be the case that the changed slot list will be successfully recognized depending on the library implementation. On some platforms, or earlier PKCS11 compliant libraries, it may be necessary to successfully call C_Initialize or to restart the entire system.
tokenPresent
- only slots with tokens?pSlotList
- receives array of slot IDspulCount
- receives number of slots
CKR.ARGUMENTS_BAD
, CKR.BUFFER_TOO_SMALL
,
CKR.CRYPTOKI_NOT_INITIALIZED
, CKR.FUNCTION_FAILED
,
CKR.GENERAL_ERROR
, CKR.HOST_MEMORY
, CKR.OK
public static int C_GetSlotInfo(com.sun.jna.NativeLong slotID, CK_SLOT_INFO pInfo)
slotID
- the ID of the slotpInfo
- receives the slot information
CKR.ARGUMENTS_BAD
, CKR.CRYPTOKI_NOT_INITIALIZED
,
CKR.DEVICE_ERROR
, CKR.FUNCTION_FAILED
, CKR.GENERAL_ERROR
,
CKR.HOST_MEMORY
, CKR.OK
, CKR.SLOT_ID_INVALID
public static int C_GetTokenInfo(com.sun.jna.NativeLong slotID, CK_TOKEN_INFO pInfo)
slotID
- ID of the token's slotpInfo
- receives the token information
CKR.CRYPTOKI_NOT_INITIALIZED
, CKR.DEVICE_ERROR
,
CKR.DEVICE_MEMORY
, CKR.DEVICE_REMOVED
, CKR.FUNCTION_FAILED
,
CKR.GENERAL_ERROR
, CKR.HOST_MEMORY
, CKR.OK
,
CKR.SLOT_ID_INVALID
, CKR.TOKEN_NOT_PRESENT
,
CKR.TOKEN_NOT_RECOGNIZED
, CKR.ARGUMENTS_BAD
public static int C_WaitForSlotEvent(com.sun.jna.NativeLong flags, LongRef pSlot, com.sun.jna.Pointer pReserved)
At present, the only flag defined for use in the flags argument is CKF_DONT_BLOCK: Internally, each Cryptoki application has a flag for each slot which is used to track whether or not any unrecognized events involving that slot have occurred. When an application initially calls C_Initialize, every slot’s event flag is cleared. Whenever a slot event occurs, the flag corresponding to the slot in which the event occurred is set.
If C_WaitForSlotEvent is called with the CKF_DONT_BLOCK flag set in the flags argument, and some slot’s event flag is set, then that event flag is cleared, and the call returns with the ID of that slot in the location pointed to by pSlot. If more than one slot’s event flag is set at the time of the call, one such slot is chosen by the library to have its event flag cleared and to have its slot ID returned.
If C_WaitForSlotEvent is called with the CKF_DONT_BLOCK flag set in the flags argument, and no slot’s event flag is set, then the call returns with the value CKR_NO_EVENT. In this case, the contents of the location pointed to by pSlot when C_WaitForSlotEvent are undefined.
If C_WaitForSlotEvent is called with the CKF_DONT_BLOCK flag clear in the flags argument, then the call behaves as above, except that it will block. That is, if no slot’s event flag is set at the time of the call, C_WaitForSlotEvent will wait until some slot’s event flag becomes set. If a thread of an application has a C_WaitForSlotEvent call blocking when another thread of that application calls C_Finalize, the C_WaitForSlotEvent call returns with the value CKR_CRYPTOKI_NOT_INITIALIZED.
Although the parameters supplied to C_Initialize can in general allow for safe multi- threaded access to a Cryptoki library, C_WaitForSlotEvent is exceptional in that the behavior of Cryptoki is undefined if multiple threads of a single application make simultaneous calls to C_WaitForSlotEvent.
flags
- blocking/non-blocking flagpSlot
- location that receives the slot IDpReserved
- reserved. Should by NULL_PTR
CKR.ARGUMENTS_BAD
, CKR.CRYPTOKI_NOT_INITIALIZED
,
CKR.FUNCTION_FAILED
, CKR.GENERAL_ERROR
, CKR.HOST_MEMORY
,
CKR.NO_EVENT
, CKR.OK
public static int C_GetMechanismList(com.sun.jna.NativeLong slotID, LongArray pMechanismList, LongRef pulCount)
There are two ways for an application to call C_GetMechanismList:
Because C_GetMechanismList does not allocate any space of its own, an application will often call C_GetMechanismList twice. However, this behavior is by no means required.
slotID
- ID of token's slotpMechanismList
- gets mech. arraypulCount
- gets # of mechs.
CKR.BUFFER_TOO_SMALL
,
CKR.CRYPTOKI_NOT_INITIALIZED
, CKR.DEVICE_ERROR
,
CKR.DEVICE_MEMORY
, CKR.DEVICE_REMOVED
, CKR.FUNCTION_FAILED
,
CKR.GENERAL_ERROR
, CKR.HOST_MEMORY
, CKR.OK
,
CKR.SLOT_ID_INVALID
, CKR.TOKEN_NOT_PRESENT
,
CKR.TOKEN_NOT_RECOGNIZED
, CKR.ARGUMENTS_BAD
public static int C_GetMechanismInfo(com.sun.jna.NativeLong slotID, com.sun.jna.NativeLong type, CK_MECHANISM_INFO pInfo)
slotID
- ID of the token's slottype
- type of mechanismpInfo
- receives mechanism info
CKR.CRYPTOKI_NOT_INITIALIZED
, CKR.DEVICE_ERROR
,
CKR.DEVICE_MEMORY
, CKR.DEVICE_REMOVED
, CKR.FUNCTION_FAILED
,
CKR.GENERAL_ERROR
, CKR.HOST_MEMORY
, CKR.MECHANISM_INVALID
,
CKR.OK
, CKR.SLOT_ID_INVALID
, CKR.TOKEN_NOT_PRESENT
,
CKR.TOKEN_NOT_RECOGNIZED
, CKR.ARGUMENTS_BAD
public static int C_InitToken(com.sun.jna.NativeLong slotID, byte[] pPin, com.sun.jna.NativeLong ulPinLen, byte[] pLabel32)
When a token is initialized, all objects that can be destroyed are destroyed (i.e., all except for "indestructible" objects such as keys built into the token). Also, access by the normal user is disabled until the SO sets the normal user’s PIN. Depending on the token, some "default" objects may be created, and attributes of some objects may be set to default values.
If the token has a "protected authentication path", as indicated by the CKF_PROTECTED_AUTHENTICATION_PATH flag in its CK_TOKEN_INFO being set, then that means that there is some way for a user to be authenticated to the token without having the application send a PIN through the Cryptoki library. One such possibility is that the user enters a PIN on a PINpad on the token itself, or on the slot device. To initialize a token with such a protected authentication path, the pPin parameter to C_InitToken should be NULL_PTR. During the execution of C_InitToken, the SO’s PIN will be entered through the protected authentication path.
If the token has a protected authentication path other than a PINpad, then it is token- dependent whether or not C_InitToken can be used to initialize the token. A token cannot be initialized if Cryptoki detects that any application has an open session with it; when a call to C_InitToken is made under such circumstances, the call fails with error CKR_SESSION_EXISTS. Unfortunately, it may happen when C_InitToken is called that some other application does have an open session with the token, but Cryptoki cannot detect this, because it cannot detect anything about other applications using the token. If this is the case, then the consequences of the C_InitToken call are undefined.
The C_InitToken function may not be sufficient to properly initialize complex tokens. In these situations, an initialization mechanism outside the scope of Cryptoki must be employed. The definition of "complex token" is product specific.
slotID
- ID of the token's slotpPin
- the SO's initial PINulPinLen
- length in bytes of the PINpLabel32
- 32-byte token label (blank padded)
CKR.CRYPTOKI_NOT_INITIALIZED
, CKR.DEVICE_ERROR
,
CKR.DEVICE_MEMORY
, CKR.DEVICE_REMOVED
,
CKR.FUNCTION_CANCELED
, CKR.FUNCTION_FAILED
,
CKR.GENERAL_ERROR
, CKR.HOST_MEMORY
, CKR.OK
,
CKR.PIN_INCORRECT
, CKR.PIN_LOCKED
, CKR.SESSION_EXISTS
,
CKR.SLOT_ID_INVALID
, CKR.TOKEN_NOT_PRESENT
,
CKR.TOKEN_NOT_RECOGNIZED
, CKR.TOKEN_WRITE_PROTECTED
,
CKR.ARGUMENTS_BAD
public static int C_InitPIN(com.sun.jna.NativeLong hSession, byte[] pPin, com.sun.jna.NativeLong ulPinLen)
C_InitPIN can only be called in the "R/W SO Functions" state. An attempt to call it from a session in any other state fails with error CKR_USER_NOT_LOGGED_IN. If the token has a "protected authentication path", as indicated by the CKF_PROTECTED_AUTHENTICATION_PATH flag in its CK_TOKEN_INFO being set, then that means that there is some way for a user to be authenticated to the token without having the application send a PIN through the Cryptoki library. One such possibility is that the user enters a PIN on a PINpad on the token itself, or on the slot device. To initialize the normal user’s PIN on a token with such a protected authentication path, the pPin parameter to C_InitPIN should be NULL_PTR. During the execution of C_InitPIN, the SO will enter the new PIN through the protected authentication path.
If the token has a protected authentication path other than a PINpad, then it is token- dependent whether or not C_InitPIN can be used to initialize the normal user’s token access.
hSession
- the session's handlepPin
- the normal user's PINulPinLen
- length in bytes of the PIN
CKR.CRYPTOKI_NOT_INITIALIZED
, CKR.DEVICE_ERROR
,
CKR.DEVICE_MEMORY
, CKR.DEVICE_REMOVED
,
CKR.FUNCTION_CANCELED
, CKR.FUNCTION_FAILED
,
CKR.GENERAL_ERROR
, CKR.HOST_MEMORY
, CKR.OK
, CKR.PIN_INVALID
,
CKR.PIN_LEN_RANGE
, CKR.SESSION_CLOSED
, CKR.SESSION_READ_ONLY
,
CKR.SESSION_HANDLE_INVALID
, CKR.TOKEN_WRITE_PROTECTED
,
CKR.USER_NOT_LOGGED_IN
, CKR.ARGUMENTS_BAD
public static int C_SetPIN(com.sun.jna.NativeLong hSession, byte[] pOldPin, com.sun.jna.NativeLong ulOldLen, byte[] pNewPin, com.sun.jna.NativeLong ulNewLen)
If the token has a "protected authentication path", as indicated by the CKF_PROTECTED_AUTHENTICATION_PATH flag in its CK_TOKEN_INFO being set, then that means that there is some way for a user to be authenticated to the token without having the application send a PIN through the Cryptoki library. One such possibility is that the user enters a PIN on a PINpad on the token itself, or on the slot device. To modify the current user’s PIN on a token with such a protected authentication path, the pOldPin and pNewPin parameters to C_SetPIN should be NULL_PTR. During the execution of C_SetPIN, the current user will enter the old PIN and the new PIN through the protected authentication path. It is not specified how the PINpad should be used to enter two PINs; this varies.
If the token has a protected authentication path other than a PINpad, then it is token- dependent whether or not C_SetPIN can be used to modify the current user’s PIN.
hSession
- the session's handlepOldPin
- the old PINulOldLen
- length of the old PINpNewPin
- the new PINulNewLen
- length of the new PIN
CKR.CRYPTOKI_NOT_INITIALIZED
, CKR.DEVICE_ERROR
,
CKR.DEVICE_MEMORY
, CKR.DEVICE_REMOVED
,
CKR.FUNCTION_CANCELED
, CKR.FUNCTION_FAILED
,
CKR.GENERAL_ERROR
, CKR.HOST_MEMORY
, CKR.OK
,
CKR.PIN_INCORRECT
, CKR.PIN_INVALID
, CKR.PIN_LEN_RANGE
,
CKR.PIN_LOCKED
, CKR.SESSION_CLOSED
,
CKR.SESSION_HANDLE_INVALID
, CKR.SESSION_READ_ONLY
,
CKR.TOKEN_WRITE_PROTECTED
, CKR.ARGUMENTS_BAD
public static int C_OpenSession(com.sun.jna.NativeLong slotID, com.sun.jna.NativeLong flags, com.sun.jna.Pointer application, CK_NOTIFY notify, LongRef phSession)
When opening a session with C_OpenSession, the flags parameter consists of the logical OR of zero or more bit flags defined in the CK_SESSION_INFO data type. For legacy reasons, the CKF_SERIAL_SESSION bit must always be set; if a call to C_OpenSession does not have this bit set, the call should return unsuccessfully with the error code CKR_PARALLEL_NOT_SUPPORTED.
There may be a limit on the number of concurrent sessions an application may have with the token, which may depend on whether the session is "read-only" or "read/write". An attempt to open a session which does not succeed because there are too many existing sessions of some type should return CKR_SESSION_COUNT. If the token is write-protected (as indicated in the CK_TOKEN_INFO structure), then only read-only sessions may be opened with it.
If the application calling C_OpenSession already has a R/W SO session open with the token, then any attempt to open a R/O session with the token fails with error code CKR_SESSION_READ_WRITE_SO_EXISTS (see Section 6.7.7). The Notify callback function is used by Cryptoki to notify the application of certain events. If the application does not wish to support callbacks, it should pass a value of NULL_PTR as the Notify parameter. See Section 11.17 for more information about application callbacks.
slotID
- the slot's IDflags
- from CK_SESSION_INFOapplication
- passed to callbacknotify
- callback functionphSession
- gets session handle
CKR.CRYPTOKI_NOT_INITIALIZED
, CKR.DEVICE_ERROR
,
CKR.DEVICE_MEMORY
, CKR.DEVICE_REMOVED
, CKR.FUNCTION_FAILED
,
CKR.GENERAL_ERROR
, CKR.HOST_MEMORY
, CKR.OK
,
CKR.SESSION_COUNT
, CKR.SESSION_PARALLEL_NOT_SUPPORTED
,
CKR.SESSION_READ_WRITE_SO_EXISTS
, CKR.SLOT_ID_INVALID
,
CKR.TOKEN_NOT_PRESENT
, CKR.TOKEN_NOT_RECOGNIZED
,
CKR.TOKEN_WRITE_PROTECTED
, CKR.ARGUMENTS_BAD
public static int C_CloseSession(com.sun.jna.NativeLong hSession)
If this function is successful and it closes the last session between the application and the token, the login state of the token for the application returns to public sessions. Any new sessions to the token opened by the application will be either R/O Public or R/W Public sessions.
Depending on the token, when the last open session any application has with the token is closed, the token may be "ejected" from its reader (if this capability exists). Despite the fact this C_CloseSession is supposed to close a session, the return value CKR_SESSION_CLOSED is an error return. It actually indicates the (probably somewhat unlikely) event that while this function call was executing, another call was made to C_CloseSession to close this particular session, and that call finished executing first. Such uses of sessions are a bad idea, and Cryptoki makes little promise of what will occur in general if an application indulges in this sort of behavior.
hSession
- the session's handle
CKR.CRYPTOKI_NOT_INITIALIZED
, CKR.DEVICE_ERROR
,
CKR.DEVICE_MEMORY
, CKR.DEVICE_REMOVED
, CKR.FUNCTION_FAILED
,
CKR.GENERAL_ERROR
, CKR.HOST_MEMORY
, CKR.OK
,
CKR.SESSION_CLOSED
, CKR.SESSION_HANDLE_INVALID
.public static int C_CloseAllSessions(com.sun.jna.NativeLong slotID)
When a session is closed, all session objects created by the session are destroyed automatically.
After successful execution of this function, the login state of the token for the application returns to public sessions. Any new sessions to the token opened by the application will be either R/O Public or R/W Public sessions.
Depending on the token, when the last open session any application has with the token is closed, the token may be "ejected" from its reader (if this capability exists).
slotID
- the token's slot
CKR.CRYPTOKI_NOT_INITIALIZED
, CKR.DEVICE_ERROR
,
CKR.DEVICE_MEMORY
, CKR.DEVICE_REMOVED
, CKR.FUNCTION_FAILED
,
CKR.GENERAL_ERROR
, CKR.HOST_MEMORY
, CKR.OK
,
CKR.SLOT_ID_INVALID
, CKR.TOKEN_NOT_PRESENT
public static int C_GetSessionInfo(com.sun.jna.NativeLong hSession, CK_SESSION_INFO pInfo)
hSession
- the session's handlepInfo
- received session info
CKR.CRYPTOKI_NOT_INITIALIZED
, CKR.DEVICE_ERROR
,
CKR.DEVICE_MEMORY
, CKR.DEVICE_REMOVED
, CKR.FUNCTION_FAILED
,
CKR.GENERAL_ERROR
, CKR.HOST_MEMORY
, CKR.OK
,
CKR.SESSION_CLOSED
, CKR.SESSION_HANDLE_INVALID
,
CKR.ARGUMENTS_BAD
public static int C_GetOperationState(com.sun.jna.NativeLong hSession, byte[] pOperationState, LongRef pulOperationStateLen)
Although the saved state output by C_GetOperationState is not really produced by a "cryptographic mechanism", C_GetOperationState nonetheless uses the convention described in Section 11.2 on producing output. Precisely what the "cryptographic operations state" this function saves is varies from token to token; however, this state is what is provided as input to C_SetOperationState to restore the cryptographic activities of a session.
Consider a session which is performing a message digest operation using SHA-1 (i.e., the session is using the CKM_SHA_1 mechanism). Suppose that the message digest operation was initialized properly, and that precisely 80 bytes of data have been supplied so far as input to SHA-1. The application now wants to "save the state" of this digest operation, so that it can continue it later. In this particular case, since SHA-1 processes 512 bits (64 bytes) of input at a time, the cryptographic operations state of the session most likely consists of three distinct parts: the state of SHA-1’s 160-bit internal chaining variable; the 16 bytes of unprocessed input data; and some administrative data indicating that this saved state comes from a session which was performing SHA-1 hashing. Taken together, these three pieces of information suffice to continue the current hashing operation at a later time.
Consider next a session which is performing an encryption operation with DES (a block cipher with a block size of 64 bits) in CBC (cipher-block chaining) mode (i.e., the session is using the CKM_DES_CBC mechanism). Suppose that precisely 22 bytes of data (in addition to an IV for the CBC mode) have been supplied so far as input to DES, which means that the first two 8-byte blocks of ciphertext have already been produced and output. In this case, the cryptographic operations state of the session most likely consists of three or four distinct parts: the second 8-byte block of ciphertext (this will be used for cipher-block chaining to produce the next block of ciphertext); the 6 bytes of data still awaiting encryption; some administrative data indicating that this saved state comes from a session which was performing DES encryption in CBC mode; and possibly the DES key being used for encryption (see C_SetOperationState for more information on whether or not the key is present in the saved state).
If a session is performing two cryptographic operations simultaneously (see Section 11.13), then the cryptographic operations state of the session will contain all the necessary information to restore both operations. An attempt to save the cryptographic operations state of a session which does not currently have some active savable cryptographic operation(s) (encryption, decryption, digesting, signing without message recovery, verification without message recovery, or some legal combination of two of these) should fail with the error CKR_OPERATION_NOT_INITIALIZED.
An attempt to save the cryptographic operations state of a session which is performing an appropriate cryptographic operation (or two), but which cannot be satisfied for any of various reasons (certain necessary state information and/or key information can’t leave the token, for example) should fail with the error CKR_STATE_UNSAVEABLE.
hSession
- the session's handlepOperationState
- gets statepulOperationStateLen
- gets state length
CKR.BUFFER_TOO_SMALL
,
CKR.CRYPTOKI_NOT_INITIALIZED
, CKR.DEVICE_ERROR
,
CKR.DEVICE_MEMORY
, CKR.DEVICE_REMOVED
, CKR.FUNCTION_FAILED
,
CKR.GENERAL_ERROR
, CKR.HOST_MEMORY
, CKR.OK
,
CKR.OPERATION_NOT_INITIALIZED
, CKR.SESSION_CLOSED
,
CKR.SESSION_HANDLE_INVALID
, CKR.STATE_UNSAVEABLE
, CKR.ARGUMENTS_BAD
public static int C_SetOperationState(com.sun.jna.NativeLong hSession, byte[] pOperationState, com.sun.jna.NativeLong pulOperationStateLen, com.sun.jna.NativeLong hEncryptionKey, com.sun.jna.NativeLong hAuthenticationKey)
The state need not have been obtained from the same session (the "source session") as it is being restored to (the "destination session"). However, the source session and destination session should have a common session state (e.g., CKS_RW_USER_FUNCTIONS), and should be with a common token. There is also no guarantee that cryptographic operations state may be carried across logins, or across different Cryptoki implementations.
If C_SetOperationState is supplied with alleged saved cryptographic operations state which it can determine is not valid saved state (or is cryptographic operations state from a session with a different session state, or is cryptographic operations state from a different token), it fails with the error CKR_SAVED_STATE_INVALID. Saved state obtained from calls to C_GetOperationState may or may not contain information about keys in use for ongoing cryptographic operations. If a saved cryptographic operations state has an ongoing encryption or decryption operation, and the key in use for the operation is not saved in the state, then it must be supplied to C_SetOperationState in the hEncryptionKey argument. If it is not, then C_SetOperationState will fail and return the error CKR_KEY_NEEDED. If the key in use for the operation is saved in the state, then it can be supplied in the hEncryptionKey argument, but this is not required.
Similarly, if a saved cryptographic operations state has an ongoing signature, MACing, or verification operation, and the key in use for the operation is not saved in the state, then it must be supplied to C_SetOperationState in the hAuthenticationKey argument. If it is not, then C_SetOperationState will fail with the error CKR_KEY_NEEDED. If the key in use for the operation is saved in the state, then it can be supplied in the hAuthenticationKey argument, but this is not required. If an irrelevant key is supplied to C_SetOperationState call (e.g., a nonzero key handle is submitted in the hEncryptionKey argument, but the saved cryptographic operations state supplied does not have an ongoing encryption or decryption operation, then C_SetOperationState fails with the error CKR_KEY_NOT_NEEDED.
If a key is supplied as an argument to C_SetOperationState, and C_SetOperationState can somehow detect that this key was not the key being used in the source session for the supplied cryptographic operations state (it may be able to detect this if the key or a hash of the key is present in the saved state, for example), then C_SetOperationState fails with the error CKR_KEY_CHANGED.
An application can look at the CKF_RESTORE_KEY_NOT_NEEDED flag in the flags field of the CK_TOKEN_INFO field for a token to determine whether or not it needs to supply key handles to C_SetOperationState calls. If this flag is true, then a call to C_SetOperationState never needs a key handle to be supplied to it. If this flag is false, then at least some of the time, C_SetOperationState requires a key handle, and so the application should probably always pass in any relevant key handles when restoring cryptographic operations state to a session.
C_SetOperationState can successfully restore cryptographic operations state to a session even if that session has active cryptographic or object search operations when C_SetOperationState is called (the ongoing operations are abruptly cancelled).
hSession
- the session's handlepOperationState
- holds statepulOperationStateLen
- holds state lengthhEncryptionKey
- en/decryption keyhAuthenticationKey
- sign/verify key
CKR.CRYPTOKI_NOT_INITIALIZED
, CKR.DEVICE_ERROR
,
CKR.DEVICE_MEMORY
, CKR.DEVICE_REMOVED
, CKR.FUNCTION_FAILED
,
CKR.GENERAL_ERROR
, CKR.HOST_MEMORY
, CKR.KEY_CHANGED
,
CKR.KEY_NEEDED
, CKR.KEY_NOT_NEEDED
, CKR.OK
,
CKR.SAVED_STATE_INVALID
, CKR.SESSION_CLOSED
,
CKR.SESSION_HANDLE_INVALID
, CKR.ARGUMENTS_BAD
public static int C_Login(com.sun.jna.NativeLong hSession, com.sun.jna.NativeLong userType, byte[] pPin, com.sun.jna.NativeLong ulPinLen)
When the user type is either CKU_SO or CKU_USER, if the call succeeds, each of the application's sessions will enter either the "R/W SO Functions" state, the "R/W User Functions" state, or the "R/O User Functions" state. If the user type is CKU_CONTEXT_SPECIFIC , the behavior of C_Login depends on the context in which it is called. Improper use of this user type will result in a return value CKR_OPERATION_NOT_INITIALIZED..
If the token has a "protected authentication path", as indicated by the CKF_PROTECTED_AUTHENTICATION_PATH flag in its CK_TOKEN_INFO being set, then that means that there is some way for a user to be authenticated to the token without having the application send a PIN through the Cryptoki library. One such possibility is that the user enters a PIN on a PINpad on the token itself, or on the slot device. Or the user might not even use a PIN—authentication could be achieved by some fingerprint-reading device, for example. To log into a token with a protected authentication path, the pPin parameter to C_Login should be NULL_PTR. When C_Login returns, whatever authentication method supported by the token will have been performed; a return value of CKR_OK means that the user was successfully authenticated, and a return value of CKR_PIN_INCORRECT means that the user was denied access.
If there are any active cryptographic or object finding operations in an application’s session, and then C_Login is successfully executed by that application, it may or may not be the case that those operations are still active. Therefore, before logging in, any active operations should be finished.
If the application calling C_Login has a R/O session open with the token, then it will be unable to log the SO into a session (see Section 6.7.7). An attempt to do this will result in the error code CKR_SESSION_READ_ONLY_EXISTS.
C_Login may be called repeatedly, without intervening C_Logout calls, if (and only if) a key with the CKA_ALWAYS_AUTHENTICATE attribute set to CK_TRUE exists, and the user needs to do cryptographic operation on this key. See further Section 10.9.
hSession
- the session's handleuserType
- the user typepPin
- the user's PINulPinLen
- the length of the PIN
CKR.ARGUMENTS_BAD
, CKR.CRYPTOKI_NOT_INITIALIZED
,
CKR.DEVICE_ERROR
, CKR.DEVICE_MEMORY
, CKR.DEVICE_REMOVED
,
CKR.FUNCTION_CANCELED
, CKR.FUNCTION_FAILED
,
CKR.GENERAL_ERROR
, CKR.HOST_MEMORY
, CKR.OK
,
CKR.OPERATION_NOT_INITIALIZED
, CKR.PIN_INCORRECT
,
CKR.PIN_LOCKED
, CKR.SESSION_CLOSED
,
CKR.SESSION_HANDLE_INVALID
, CKR.SESSION_READ_ONLY_EXISTS
,
CKR.USER_ALREADY_LOGGED_IN
,
CKR.USER_ANOTHER_ALREADY_LOGGED_IN
,
CKR.USER_PIN_NOT_INITIALIZED
, CKR.USER_TOO_MANY_TYPES
,
CKR.USER_TYPE_INVALID
public static int C_Logout(com.sun.jna.NativeLong hSession)
When C_Logout successfully executes, any of the application’s handles to private objects become invalid (even if a user is later logged back into the token, those handles remain invalid). In addition, all private session objects from sessions belonging to the application are destroyed.
If there are any active cryptographic or object-finding operations in an application’s session, and then C_Logout is successfully executed by that application, it may or may not be the case that those operations are still active. Therefore, before logging out, any active operations should be finished.
hSession
- the session's handle
CKR.CRYPTOKI_NOT_INITIALIZED
, CKR.DEVICE_ERROR
,
CKR.DEVICE_MEMORY
, CKR.DEVICE_REMOVED
, CKR.FUNCTION_FAILED
,
CKR.GENERAL_ERROR
, CKR.HOST_MEMORY
, CKR.OK
,
CKR.SESSION_CLOSED
, CKR.SESSION_HANDLE_INVALID
,
CKR.USER_NOT_LOGGED_IN
public static int C_CreateObject(com.sun.jna.NativeLong hSession, Template pTemplate, com.sun.jna.NativeLong ulCount, LongRef phObject)
If a call to C_CreateObject cannot support the precise template supplied to it, it will fail and return without creating any object.
If C_CreateObject is used to create a key object, the key object will have its CKA_LOCAL attribute set to CK_FALSE. If that key object is a secret or private key then the new key will have the CKA_ALWAYS_SENSITIVE attribute set to CK_FALSE, and the CKA_NEVER_EXTRACTABLE attribute set to CK_FALSE.
Only session objects can be created during a read-only session. Only public objects can be created unless the normal user is logged in.
hSession
- the session's handlepTemplate
- the objects's templateulCount
- attributes in templatephObject
- gets new object's handle
CKR.ARGUMENTS_BAD
, CKR.ATTRIBUTE_READ_ONLY
,
CKR.ATTRIBUTE_TYPE_INVALID
, CKR.ATTRIBUTE_VALUE_INVALID
,
CKR.CRYPTOKI_NOT_INITIALIZED
, CKR.DEVICE_ERROR
,
CKR.DEVICE_MEMORY
, CKR.DEVICE_REMOVED
,
CKR.DOMAIN_PARAMS_INVALID
, CKR.FUNCTION_FAILED
,
CKR.GENERAL_ERROR
, CKR.HOST_MEMORY
, CKR.OK
, CKR.PIN_EXPIRED
,
CKR.SESSION_CLOSED
, CKR.SESSION_HANDLE_INVALID
,
CKR.SESSION_READ_ONLY
, CKR.TEMPLATE_INCOMPLETE
,
CKR.TEMPLATE_INCONSISTENT
, CKR.TOKEN_WRITE_PROTECTED
,
CKR.USER_NOT_LOGGED_IN
public static int C_CopyObject(com.sun.jna.NativeLong hSession, com.sun.jna.NativeLong hObject, Template pTemplate, com.sun.jna.NativeLong ulCount, LongRef phNewObject)
The template may specify new values for any attributes of the object that can ordinarily be modified (e.g., in the course of copying a secret key, a key’s CKA_EXTRACTABLE attribute may be changed from CK_TRUE to CK_FALSE, but not the other way around. If this change is made, the new key’s CKA_NEVER_EXTRACTABLE attribute will have the value CK_FALSE. Similarly, the template may specify that the new key’s CKA_SENSITIVE attribute be CK_TRUE; the new key will have the same value for its CKA_ALWAYS_SENSITIVE attribute as the original key). It may also specify new values of the CKA_TOKEN and CKA_PRIVATE attributes (e.g., to copy a session object to a token object). If the template specifies a value of an attribute which is incompatible with other existing attributes of the object, the call fails with the return code CKR_TEMPLATE_INCONSISTENT.
If a call to C_CopyObject cannot support the precise template supplied to it, it will fail and return without creating any object. Only session objects can be created during a read-only session. Only public objects can be created unless the normal user is logged in.
hSession
- the session's handlehObject
- pTemplate
- template for new objectulCount
- attributes in templatephNewObject
- receives handle of copy
CKR.ARGUMENTS_BAD
, CKR.ATTRIBUTE_READ_ONLY
,
CKR.ATTRIBUTE_TYPE_INVALID
, CKR.ATTRIBUTE_VALUE_INVALID
,
CKR.CRYPTOKI_NOT_INITIALIZED
, CKR.DEVICE_ERROR
,
CKR.DEVICE_MEMORY
, CKR.DEVICE_REMOVED
, CKR.FUNCTION_FAILED
,
CKR.GENERAL_ERROR
, CKR.HOST_MEMORY
,
CKR.OBJECT_HANDLE_INVALID
, CKR.OK
, CKR.PIN_EXPIRED
,
CKR.SESSION_CLOSED
, CKR.SESSION_HANDLE_INVALID
,
CKR.SESSION_READ_ONLY
, CKR.TEMPLATE_INCONSISTENT
,
CKR.TOKEN_WRITE_PROTECTED
, CKR.USER_NOT_LOGGED_IN
public static int C_DestroyObject(com.sun.jna.NativeLong hSession, com.sun.jna.NativeLong hObject)
hSession
- the session's handlehObject
- the objects's handle
CKR.CRYPTOKI_NOT_INITIALIZED
, CKR.DEVICE_ERROR
,
CKR.DEVICE_MEMORY
, CKR.DEVICE_REMOVED
, CKR.FUNCTION_FAILED
,
CKR.GENERAL_ERROR
, CKR.HOST_MEMORY
,
CKR.OBJECT_HANDLE_INVALID
, CKR.OK
, CKR.PIN_EXPIRED
,
CKR.SESSION_CLOSED
, CKR.SESSION_HANDLE_INVALID
,
CKR.SESSION_READ_ONLY
, CKR.TOKEN_WRITE_PROTECTED
public static int C_GetObjectSize(com.sun.jna.NativeLong hSession, com.sun.jna.NativeLong hObject, LongRef pulSize)
Cryptoki does not specify what the precise meaning of an object’s size is. Intuitively, it is some measure of how much token memory the object takes up. If an application deletes (say) a private object of size S, it might be reasonable to assume that the ulFreePrivateMemory field of the token’s CK_TOKEN_INFO structure increases by approximately S.
hSession
- the session's handlehObject
- the object's handlepulSize
- receives size of object
CKR.ARGUMENTS_BAD
, CKR.CRYPTOKI_NOT_INITIALIZED
,
CKR.DEVICE_ERROR
, CKR.DEVICE_MEMORY
, CKR.DEVICE_REMOVED
,
CKR.FUNCTION_FAILED
, CKR.GENERAL_ERROR
, CKR.HOST_MEMORY
,
CKR.INFORMATION_SENSITIVE
, CKR.OBJECT_HANDLE_INVALID
, CKR.OK
,
CKR.SESSION_CLOSED
, CKR.SESSION_HANDLE_INVALID
public static int C_GetAttributeValue(com.sun.jna.NativeLong hSession, com.sun.jna.NativeLong hObject, Template pTemplate, com.sun.jna.NativeLong ulCount)
For each (type, pValue, ulValueLen) triple in the template, C_GetAttributeValue performs the following algorithm:
In the special case of an attribute whose value is an array of attributes, for example CKA_WRAP_TEMPLATE, where it is passed in with pValue not NULL, then if the pValue of elements within the array is NULL_PTR then the ulValueLen of elements within the array will be set to the required length. If the pValue of elements within the array is not NULL_PTR, then the ulValueLen element of attributes within the array must reflect the space that the corresponding pValue points to, and pValue is filled in if there is sufficient room. Therefore it is important to initialize the contents of a buffer before calling C_GetAttributeValue to get such an array value. If any ulValueLen within the array isn't large enough, it will be set to –1 and the function will return CKR_BUFFER_TOO_SMALL, as it does if an attribute in the pTemplate argument has ulValueLen too small. Note that any attribute whose value is an array of attributes is identifiable by virtue of the attribute type having the CKF_ARRAY_ATTRIBUTE bit set.
Note that the error codes CKR_ATTRIBUTE_SENSITIVE, CKR_ATTRIBUTE_TYPE_INVALID, and CKR_BUFFER_TOO_SMALL do not denote true errors for C_GetAttributeValue. If a call to C_GetAttributeValue returns any of these three values, then the call must nonetheless have processed every attribute in the template supplied to C_GetAttributeValue. Each attribute in the template whose value can be returned by the call to C_GetAttributeValue will be returned by the call to C_GetAttributeValue.
hSession
- the session's handlehObject
- the object's handlepTemplate
- specifies attrs; gets valsulCount
- attributes in template
CKR.ARGUMENTS_BAD
, CKR.ATTRIBUTE_SENSITIVE
,
CKR.ATTRIBUTE_TYPE_INVALID
, CKR.BUFFER_TOO_SMALL
,
CKR.CRYPTOKI_NOT_INITIALIZED
, CKR.DEVICE_ERROR
,
CKR.DEVICE_MEMORY
, CKR.DEVICE_REMOVED
, CKR.FUNCTION_FAILED
,
CKR.GENERAL_ERROR
, CKR.HOST_MEMORY
,
CKR.OBJECT_HANDLE_INVALID
, CKR.OK
, CKR.SESSION_CLOSED
,
CKR.SESSION_HANDLE_INVALID
public static int C_SetAttributeValue(com.sun.jna.NativeLong hSession, com.sun.jna.NativeLong hObject, Template pTemplate, com.sun.jna.NativeLong ulCount)
The template may specify new values for any attributes of the object that can be modified. If the template specifies a value of an attribute which is incompatible with other existing attributes of the object, the call fails with the return code CKR_TEMPLATE_INCONSISTENT.
Not all attributes can be modified; see Section 9.7 for more details.
hSession
- the session's handlehObject
- the object's handlepTemplate
- specifies attrs and valuesulCount
- attributes in template
CKR.ARGUMENTS_BAD
, CKR.ATTRIBUTE_READ_ONLY
,
CKR.ATTRIBUTE_TYPE_INVALID
, CKR.ATTRIBUTE_VALUE_INVALID
,
CKR.CRYPTOKI_NOT_INITIALIZED
, CKR.DEVICE_ERROR
,
CKR.DEVICE_MEMORY
, CKR.DEVICE_REMOVED
, CKR.FUNCTION_FAILED
,
CKR.GENERAL_ERROR
, CKR.HOST_MEMORY
,
CKR.OBJECT_HANDLE_INVALID
, CKR.OK
, CKR.SESSION_CLOSED
,
CKR.SESSION_HANDLE_INVALID
, CKR.SESSION_READ_ONLY
,
CKR.TEMPLATE_INCONSISTENT
, CKR.TOKEN_WRITE_PROTECTED
,
CKR.USER_NOT_LOGGED_IN
public static int C_FindObjectsInit(com.sun.jna.NativeLong hSession, Template pTemplate, com.sun.jna.NativeLong ulCount)
After calling C_FindObjectsInit, the application may call C_FindObjects one or more times to obtain handles for objects matching the template, and then eventually call C_FindObjectsFinal to finish the active search operation. At most one search operation may be active at a given time in a given session. The object search operation will only find objects that the session can view. For example, an object search in an "R/W Public Session" will not find any private objects (even if one of the attributes in the search template specifies that the search is for private objects).
If a search operation is active, and objects are created or destroyed which fit the search template for the active search operation, then those objects may or may not be found by the search operation. Note that this means that, under these circumstances, the search operation may return invalid object handles.
Even though C_FindObjectsInit can return the values CKR_ATTRIBUTE_TYPE_INVALID and CKR_ATTRIBUTE_VALUE_INVALID, it is not required to. For example, if it is given a search template with nonexistent attributes in it, it can return CKR_ATTRIBUTE_TYPE_INVALID, or it can initialize a search operation which will match no objects and return CKR_OK.
hSession
- the session's handlepTemplate
- attribute values to matchulCount
- attrs in search template
CKR.ARGUMENTS_BAD
, CKR.ATTRIBUTE_TYPE_INVALID
,
CKR.ATTRIBUTE_VALUE_INVALID
, CKR.CRYPTOKI_NOT_INITIALIZED
,
CKR.DEVICE_ERROR
, CKR.DEVICE_MEMORY
, CKR.DEVICE_REMOVED
,
CKR.FUNCTION_FAILED
, CKR.GENERAL_ERROR
, CKR.HOST_MEMORY
,
CKR.OK
, CKR.OPERATION_ACTIVE
, CKR.PIN_EXPIRED
,
CKR.SESSION_CLOSED
, CKR.SESSION_HANDLE_INVALID
public static int C_FindObjects(com.sun.jna.NativeLong hSession, LongArray phObject, com.sun.jna.NativeLong ulMaxObjectCount, LongRef pulObjectCount)
The search must have been initialized with C_FindObjectsInit.
hSession
- the session's handlephObject
- gets obj handlesulMaxObjectCount
- max handles to getpulObjectCount
- actual # returned
CKR.ARGUMENTS_BAD
, CKR.CRYPTOKI_NOT_INITIALIZED
,
CKR.DEVICE_ERROR
, CKR.DEVICE_MEMORY
, CKR.DEVICE_REMOVED
,
CKR.FUNCTION_FAILED
, CKR.GENERAL_ERROR
, CKR.HOST_MEMORY
,
CKR.OK
, CKR.OPERATION_NOT_INITIALIZED
, CKR.SESSION_CLOSED
,
CKR.SESSION_HANDLE_INVALID
public static int C_FindObjectsFinal(com.sun.jna.NativeLong hSession)
hSession
- the session's handle
CKR.CRYPTOKI_NOT_INITIALIZED
, CKR.DEVICE_ERROR
,
CKR.DEVICE_MEMORY
, CKR.DEVICE_REMOVED
, CKR.FUNCTION_FAILED
,
CKR.GENERAL_ERROR
, CKR.HOST_MEMORY
, CKR.OK
,
CKR.OPERATION_NOT_INITIALIZED
, CKR.SESSION_CLOSED
,
CKR.SESSION_HANDLE_INVALID
public static int C_EncryptInit(com.sun.jna.NativeLong hSession, CKM pMechanism, com.sun.jna.NativeLong hKey)
The CKA_ENCRYPT attribute of the encryption key, which indicates whether the key supports encryption, must be CK_TRUE. After calling C_EncryptInit, the application can either call C_Encrypt to encrypt data in a single part; or call C_EncryptUpdate zero or more times, followed by C_EncryptFinal, to encrypt data in multiple parts. The encryption operation is active until the application uses a call to C_Encrypt or C_EncryptFinal to actually obtain the final piece of ciphertext. To process additional data (in single or multiple parts), the application must call C_EncryptInit again.
hSession
- the session's handlepMechanism
- the encryption mechanismhKey
- handle of encryption key
CKR.CRYPTOKI_NOT_INITIALIZED
, CKR.DEVICE_ERROR
,
CKR.DEVICE_MEMORY
, CKR.DEVICE_REMOVED
,
CKR.FUNCTION_CANCELED
, CKR.FUNCTION_FAILED
,
CKR.GENERAL_ERROR
, CKR.HOST_MEMORY
,
CKR.KEY_FUNCTION_NOT_PERMITTED
, CKR.KEY_HANDLE_INVALID
,
CKR.KEY_SIZE_RANGE
, CKR.KEY_TYPE_INCONSISTENT
,
CKR.MECHANISM_INVALID
, CKR.MECHANISM_PARAM_INVALID
, CKR.OK
,
CKR.OPERATION_ACTIVE
, CKR.PIN_EXPIRED
, CKR.SESSION_CLOSED
,
CKR.SESSION_HANDLE_INVALID
, CKR.USER_NOT_LOGGED_IN
public static int C_Encrypt(com.sun.jna.NativeLong hSession, byte[] pData, com.sun.jna.NativeLong ulDataLen, byte[] pEncryptedData, LongRef pulEncryptedDataLen)
C_Encrypt uses the convention described in Section 11.2 on producing output. The encryption operation must have been initialized with C_EncryptInit. A call to C_Encrypt always terminates the active encryption operation unless it returns CKR_BUFFER_TOO_SMALL or is a successful call (i.e., one which returns CKR_OK) to determine the length of the buffer needed to hold the ciphertext.
C_Encrypt can not be used to terminate a multi-part operation, and must be called after C_EncryptInit without intervening C_EncryptUpdate calls.
For some encryption mechanisms, the input plaintext data has certain length constraints (either because the mechanism can only encrypt relatively short pieces of plaintext, or because the mechanism’s input data must consist of an integral number of blocks). If these constraints are not satisfied, then C_Encrypt will fail with return code CKR_DATA_LEN_RANGE.
The plaintext and ciphertext can be in the same place, i.e., it is OK if pData and pEncryptedData point to the same location. For most mechanisms, C_Encrypt is equivalent to a sequence of C_EncryptUpdate operations followed by C_EncryptFinal.
hSession
- the session's handlepData
- the plaintext dataulDataLen
- bytes of plaintextpEncryptedData
- gets ciphertextpulEncryptedDataLen
- gets c-text size
CKR.ARGUMENTS_BAD
, CKR.BUFFER_TOO_SMALL
,
CKR.CRYPTOKI_NOT_INITIALIZED
, CKR.DATA_INVALID
,
CKR.DATA_LEN_RANGE
, CKR.DEVICE_ERROR
, CKR.DEVICE_MEMORY
,
CKR.DEVICE_REMOVED
, CKR.FUNCTION_CANCELED
,
CKR.FUNCTION_FAILED
, CKR.GENERAL_ERROR
, CKR.HOST_MEMORY
,
CKR.OK
, CKR.OPERATION_NOT_INITIALIZED
, CKR.SESSION_CLOSED
,
CKR.SESSION_HANDLE_INVALID
public static int C_EncryptUpdate(com.sun.jna.NativeLong hSession, byte[] pPart, com.sun.jna.NativeLong ulPartLen, byte[] pEncryptedPart, LongRef pulEncryptedPartLen)
C_EncryptUpdate uses the convention described in Section 11.2 on producing output. The encryption operation must have been initialized with C_EncryptInit. This function may be called any number of times in succession. A call to C_EncryptUpdate which results in an error other than CKR_BUFFER_TOO_SMALL terminates the current encryption operation.
The plaintext and ciphertext can be in the same place, i.e., it is OK if pPart and pEncryptedPart point to the same location.
hSession
- the session's handlepPart
- the plaintext dataulPartLen
- plaintext data lenpEncryptedPart
- gets ciphertextpulEncryptedPartLen
- gets c-text size
CKR.ARGUMENTS_BAD
, CKR.BUFFER_TOO_SMALL
,
CKR.CRYPTOKI_NOT_INITIALIZED
, CKR.DATA_LEN_RANGE
,
CKR.DEVICE_ERROR
, CKR.DEVICE_MEMORY
, CKR.DEVICE_REMOVED
,
CKR.FUNCTION_CANCELED
, CKR.FUNCTION_FAILED
,
CKR.GENERAL_ERROR
, CKR.HOST_MEMORY
, CKR.OK
,
CKR.OPERATION_NOT_INITIALIZED
, CKR.SESSION_CLOSED
,
CKR.SESSION_HANDLE_INVALID
public static int C_EncryptFinal(com.sun.jna.NativeLong hSession, byte[] pLastEncryptedPart, LongRef pulLastEncryptedPartLen)
C_EncryptFinal uses the convention described in Section 11.2 on producing output. The encryption operation must have been initialized with C_EncryptInit. A call to C_EncryptFinal always terminates the active encryption operation unless it returns CKR_BUFFER_TOO_SMALL or is a successful call (i.e., one which returns CKR_OK) to determine the length of the buffer needed to hold the ciphertext.
For some multi-part encryption mechanisms, the input plaintext data has certain length constraints, because the mechanism’s input data must consist of an integral number of blocks. If these constraints are not satisfied, then C_EncryptFinal will fail with return code CKR_DATA_LEN_RANGE.
hSession
- the session's handlepLastEncryptedPart
- last c-textpulLastEncryptedPartLen
- gets last size
CKR.ARGUMENTS_BAD
, CKR.BUFFER_TOO_SMALL
,
CKR.CRYPTOKI_NOT_INITIALIZED
, CKR.DATA_LEN_RANGE
,
CKR.DEVICE_ERROR
, CKR.DEVICE_MEMORY
, CKR.DEVICE_REMOVED
,
CKR.FUNCTION_CANCELED
, CKR.FUNCTION_FAILED
,
CKR.GENERAL_ERROR
, CKR.HOST_MEMORY
, CKR.OK
,
CKR.OPERATION_NOT_INITIALIZED
, CKR.SESSION_CLOSED
,
CKR.SESSION_HANDLE_INVALID
public static int C_DecryptInit(com.sun.jna.NativeLong hSession, CKM pMechanism, com.sun.jna.NativeLong hKey)
The CKA_DECRYPT attribute of the decryption key, which indicates whether the key supports decryption, must be CK_TRUE.
After calling C_DecryptInit, the application can either call C_Decrypt to decrypt data in a single part; or call C_DecryptUpdate zero or more times, followed by C_DecryptFinal, to decrypt data in multiple parts. The decryption operation is active until the application uses a call to C_Decrypt or C_DecryptFinal to actually obtain the final piece of plaintext. To process additional data (in single or multiple parts), the application must call C_DecryptInit again
hSession
- the session's handlepMechanism
- te decryption mechanismhKey
- handle of decryption key
CKR.ARGUMENTS_BAD
, CKR.CRYPTOKI_NOT_INITIALIZED
,
CKR.DEVICE_ERROR
, CKR.DEVICE_MEMORY
, CKR.DEVICE_REMOVED
,
CKR.FUNCTION_CANCELED
, CKR.FUNCTION_FAILED
,
CKR.GENERAL_ERROR
, CKR.HOST_MEMORY
,
CKR.KEY_FUNCTION_NOT_PERMITTED
, CKR.KEY_HANDLE_INVALID
,
CKR.KEY_SIZE_RANGE
, CKR.KEY_TYPE_INCONSISTENT
,
CKR.MECHANISM_INVALID
, CKR.MECHANISM_PARAM_INVALID
, CKR.OK
,
CKR.OPERATION_ACTIVE
, CKR.PIN_EXPIRED
, CKR.SESSION_CLOSED
,
CKR.SESSION_HANDLE_INVALID
, CKR.USER_NOT_LOGGED_IN
public static int C_Decrypt(com.sun.jna.NativeLong hSession, byte[] pEncryptedData, com.sun.jna.NativeLong ulEncryptedDataLen, byte[] pData, LongRef pulDataLen)
C_Decrypt uses the convention described in Section 11.2 on producing output. The decryption operation must have been initialized with C_DecryptInit. A call to C_Decrypt always terminates the active decryption operation unless it returns CKR_BUFFER_TOO_SMALL or is a successful call (i.e., one which returns CKR_OK) to determine the length of the buffer needed to hold the plaintext.
C_Decrypt can not be used to terminate a multi-part operation, and must be called after C_DecryptInit without intervening C_DecryptUpdate calls. The ciphertext and plaintext can be in the same place, i.e., it is OK if pEncryptedData and pData point to the same location.
If the input ciphertext data cannot be decrypted because it has an inappropriate length, then either CKR_ENCRYPTED_DATA_INVALID or CKR_ENCRYPTED_DATA_LEN_RANGE may be returned. For most mechanisms, C_Decrypt is equivalent to a sequence of C_DecryptUpdate operations followed by C_DecryptFinal.
hSession
- the session's handlepEncryptedData
- ciphertextulEncryptedDataLen
- ciphertext lengthpData
- gets plaintextpulDataLen
- gets p-text size
CKR.ARGUMENTS_BAD
, CKR.BUFFER_TOO_SMALL
,
CKR.CRYPTOKI_NOT_INITIALIZED
, CKR.DEVICE_ERROR
,
CKR.DEVICE_MEMORY
, CKR.DEVICE_REMOVED
,
CKR.ENCRYPTED_DATA_INVALID
, CKR.ENCRYPTED_DATA_LEN_RANGE
,
CKR.FUNCTION_CANCELED
, CKR.FUNCTION_FAILED
,
CKR.GENERAL_ERROR
, CKR.HOST_MEMORY
, CKR.OK
,
CKR.OPERATION_NOT_INITIALIZED
, CKR.SESSION_CLOSED
,
CKR.SESSION_HANDLE_INVALID
, CKR.USER_NOT_LOGGED_IN
public static int C_DecryptUpdate(com.sun.jna.NativeLong hSession, byte[] pEncryptedPart, com.sun.jna.NativeLong ulEncryptedPartLen, byte[] pData, LongRef pulDataLen)
C_DecryptUpdate uses the convention described in Section 11.2 on producing output. The decryption operation must have been initialized with C_DecryptInit. This function may be called any number of times in succession. A call to C_DecryptUpdate which results in an error other than CKR_BUFFER_TOO_SMALL terminates the current decryption operation.
The ciphertext and plaintext can be in the same place, i.e., it is OK if pEncryptedPart and pPart point to the same location.
hSession
- the session's handlepEncryptedPart
- encrypted dataulEncryptedPartLen
- input lengthpData
- gets plaintextpulDataLen
- gets p-text size
CKR.ARGUMENTS_BAD
, CKR.BUFFER_TOO_SMALL
,
CKR.CRYPTOKI_NOT_INITIALIZED
, CKR.DEVICE_ERROR
,
CKR.DEVICE_MEMORY
, CKR.DEVICE_REMOVED
,
CKR.ENCRYPTED_DATA_INVALID
, CKR.ENCRYPTED_DATA_LEN_RANGE
,
CKR.FUNCTION_CANCELED
, CKR.FUNCTION_FAILED
,
CKR.GENERAL_ERROR
, CKR.HOST_MEMORY
, CKR.OK
,
CKR.OPERATION_NOT_INITIALIZED
, CKR.SESSION_CLOSED
,
CKR.SESSION_HANDLE_INVALID
, CKR.USER_NOT_LOGGED_IN
public static int C_DecryptFinal(com.sun.jna.NativeLong hSession, byte[] pLastPart, LongRef pulLastPartLen)
The decryption operation must have been initialized with C_DecryptInit. A call to C_DecryptFinal always terminates the active decryption operation unless it returns CKR_BUFFER_TOO_SMALL or is a successful call (i.e., one which returns CKR_OK) to determine the length of the buffer needed to hold the plaintext.
If the input ciphertext data cannot be decrypted because it has an inappropriate length, then either CKR_ENCRYPTED_DATA_INVALID or CKR_ENCRYPTED_DATA_LEN_RANGE may be returned.
hSession
- the session's handlepLastPart
- gets plaintextpulLastPartLen
- gets p-text size
CKR.ARGUMENTS_BAD
, CKR.BUFFER_TOO_SMALL
,
CKR.CRYPTOKI_NOT_INITIALIZED
, CKR.DEVICE_ERROR
,
CKR.DEVICE_MEMORY
, CKR.DEVICE_REMOVED
,
CKR.ENCRYPTED_DATA_INVALID
, CKR.ENCRYPTED_DATA_LEN_RANGE
,
CKR.FUNCTION_CANCELED
, CKR.FUNCTION_FAILED
,
CKR.GENERAL_ERROR
, CKR.HOST_MEMORY
, CKR.OK
,
CKR.OPERATION_NOT_INITIALIZED
, CKR.SESSION_CLOSED
,
CKR.SESSION_HANDLE_INVALID
, CKR.USER_NOT_LOGGED_IN
public static int C_DigestInit(com.sun.jna.NativeLong hSession, CKM pMechanism)
hSession
- the session's handlepMechanism
- the digesting mechanism
CKR.ARGUMENTS_BAD
, CKR.CRYPTOKI_NOT_INITIALIZED
,
CKR.DEVICE_ERROR
, CKR.DEVICE_MEMORY
, CKR.DEVICE_REMOVED
,
CKR.FUNCTION_CANCELED
, CKR.FUNCTION_FAILED
,
CKR.GENERAL_ERROR
, CKR.HOST_MEMORY
, CKR.MECHANISM_INVALID
,
CKR.MECHANISM_PARAM_INVALID
, CKR.OK
, CKR.OPERATION_ACTIVE
,
CKR.PIN_EXPIRED
, CKR.SESSION_CLOSED
,
CKR.SESSION_HANDLE_INVALID
, CKR.USER_NOT_LOGGED_IN
public static int C_Digest(com.sun.jna.NativeLong hSession, byte[] pData, com.sun.jna.NativeLong ulDataLen, byte[] pDigest, LongRef pulDigestLen)
C_Digest uses the convention described in Section 11.2 on producing output. The digest operation must have been initialized with C_DigestInit. A call to C_Digest always terminates the active digest operation unless it returns CKR_BUFFER_TOO_SMALL or is a successful call (i.e., one which returns CKR_OK) to determine the length of the buffer needed to hold the message digest. C_Digest can not be used to terminate a multi-part operation, and must be called after C_DigestInit without intervening C_DigestUpdate calls.
The input data and digest output can be in the same place, i.e., it is OK if pData and pDigest point to the same location.
C_Digest is equivalent to a sequence of C_DigestUpdate operations followed by C_DigestFinal.
hSession
- the session's handlepData
- data to be digestedulDataLen
- bytes of data to digestpDigest
- gets the message digestpulDigestLen
- gets digest length
CKR.ARGUMENTS_BAD
, CKR.BUFFER_TOO_SMALL
,
CKR.CRYPTOKI_NOT_INITIALIZED
, CKR.DEVICE_ERROR
,
CKR.DEVICE_MEMORY
, CKR.DEVICE_REMOVED
,
CKR.FUNCTION_CANCELED
, CKR.FUNCTION_FAILED
,
CKR.GENERAL_ERROR
, CKR.HOST_MEMORY
, CKR.OK
,
CKR.OPERATION_NOT_INITIALIZED
, CKR.SESSION_CLOSED
,
CKR.SESSION_HANDLE_INVALID
public static int C_DigestUpdate(com.sun.jna.NativeLong hSession, byte[] pPart, com.sun.jna.NativeLong ulPartLen)
The message-digesting operation must have been initialized with C_DigestInit. Calls to this function and C_DigestKey may be interspersed any number of times in any order. A call to C_DigestUpdate which results in an error terminates the current digest operation.
hSession
- the session's handlepPart
- data to be digestedulPartLen
- bytes of data to be digested
CKR.ARGUMENTS_BAD
, CKR.CRYPTOKI_NOT_INITIALIZED
,
CKR.DEVICE_ERROR
, CKR.DEVICE_MEMORY
, CKR.DEVICE_REMOVED
,
CKR.FUNCTION_CANCELED
, CKR.FUNCTION_FAILED
,
CKR.GENERAL_ERROR
, CKR.HOST_MEMORY
, CKR.OK
,
CKR.OPERATION_NOT_INITIALIZED
, CKR.SESSION_CLOSED
,
CKR.SESSION_HANDLE_INVALID
public static int C_DigestKey(com.sun.jna.NativeLong hSession, com.sun.jna.NativeLong hKey)
The message-digesting operation must have been initialized with C_DigestInit. Calls to this function and C_DigestUpdate may be interspersed any number of times in any order.
If the value of the supplied key cannot be digested purely for some reason related to its length, C_DigestKey should return the error code CKR_KEY_SIZE_RANGE.
hSession
- the session's handlehKey
- the secret key to digest
CKR.CRYPTOKI_NOT_INITIALIZED
, CKR.DEVICE_ERROR
,
CKR.DEVICE_MEMORY
, CKR.DEVICE_REMOVED
,
CKR.FUNCTION_CANCELED
, CKR.FUNCTION_FAILED
,
CKR.GENERAL_ERROR
, CKR.HOST_MEMORY
,
CKR.KEY_HANDLE_INVALID
, CKR.KEY_INDIGESTIBLE
,
CKR.KEY_SIZE_RANGE
, CKR.OK
, CKR.OPERATION_NOT_INITIALIZED
,
CKR.SESSION_CLOSED
, CKR.SESSION_HANDLE_INVALID
public static int C_DigestFinal(com.sun.jna.NativeLong hSession, byte[] pDigest, LongRef pulDigestLen)
C_DigestFinal uses the convention described in Section 11.2 on producing output. The digest operation must have been initialized with C_DigestInit. A call to C_DigestFinal always terminates the active digest operation unless it returns CKR_BUFFER_TOO_SMALL or is a successful call (i.e., one which returns CKR_OK) to determine the length of the buffer needed to hold the message digest.
hSession
- the session's handlepDigest
- gets the message digestpulDigestLen
- gets byte count of digest
CKR.ARGUMENTS_BAD
, CKR.BUFFER_TOO_SMALL
,
CKR.CRYPTOKI_NOT_INITIALIZED
, CKR.DEVICE_ERROR
,
CKR.DEVICE_MEMORY
, CKR.DEVICE_REMOVED
,
CKR.FUNCTION_CANCELED
, CKR.FUNCTION_FAILED
,
CKR.GENERAL_ERROR
, CKR.HOST_MEMORY
, CKR.OK
,
CKR.OPERATION_NOT_INITIALIZED
, CKR.SESSION_CLOSED
,
CKR.SESSION_HANDLE_INVALID
public static int C_SignInit(com.sun.jna.NativeLong hSession, CKM pMechanism, com.sun.jna.NativeLong hKey)
The CKA_SIGN attribute of the signature key, which indicates whether the key supports signatures with appendix, must be CK_TRUE.
After calling C_SignInit, the application can either call C_Sign to sign in a single part; or call C_SignUpdate one or more times, followed by C_SignFinal, to sign data in multiple parts. The signature operation is active until the application uses a call to C_Sign or C_SignFinal to actually obtain the signature. To process additional data (in single or multiple parts), the application must call C_SignInit again.
hSession
- the session's handlepMechanism
- the signature mechanismhKey
- handle of signature key
CKR.ARGUMENTS_BAD
, CKR.CRYPTOKI_NOT_INITIALIZED
,
CKR.DEVICE_ERROR
, CKR.DEVICE_MEMORY
, CKR.DEVICE_REMOVED
,
CKR.FUNCTION_CANCELED
, CKR.FUNCTION_FAILED
,
CKR.GENERAL_ERROR
, CKR.HOST_MEMORY
,
CKR.KEY_FUNCTION_NOT_PERMITTED
, CKR.KEY_HANDLE_INVALID
,
CKR.KEY_SIZE_RANGE
, CKR.KEY_TYPE_INCONSISTENT
,
CKR.MECHANISM_INVALID
, CKR.MECHANISM_PARAM_INVALID
, CKR.OK
,
CKR.OPERATION_ACTIVE
, CKR.PIN_EXPIRED
, CKR.SESSION_CLOSED
,
CKR.SESSION_HANDLE_INVALID
, CKR.USER_NOT_LOGGED_IN
public static int C_Sign(com.sun.jna.NativeLong hSession, byte[] pData, com.sun.jna.NativeLong ulDataLen, byte[] pSignature, LongRef pulSignatureLen)
C_Sign uses the convention described in Section 11.2 on producing output. The signing operation must have been initialized with C_SignInit. A call to C_Sign always terminates the active signing operation unless it returns CKR_BUFFER_TOO_SMALL or is a successful call (i.e., one which returns CKR_OK) to determine the length of the buffer needed to hold the signature.
C_Sign can not be used to terminate a multi-part operation, and must be called after C_SignInit without intervening C_SignUpdate calls.
For most mechanisms, C_Sign is equivalent to a sequence of C_SignUpdate operations followed by C_SignFinal.
hSession
- the session's handlepData
- the data to signulDataLen
- count of bytes to signpSignature
- gets the signaturepulSignatureLen
- gets signature length
CKR.ARGUMENTS_BAD
, CKR.BUFFER_TOO_SMALL
,
CKR.CRYPTOKI_NOT_INITIALIZED
, CKR.DATA_INVALID
,
CKR.DATA_LEN_RANGE
, CKR.DEVICE_ERROR
, CKR.DEVICE_MEMORY
,
CKR.DEVICE_REMOVED
, CKR.FUNCTION_CANCELED
,
CKR.FUNCTION_FAILED
, CKR.GENERAL_ERROR
, CKR.HOST_MEMORY
,
CKR.OK
, CKR.OPERATION_NOT_INITIALIZED
, CKR.SESSION_CLOSED
,
CKR.SESSION_HANDLE_INVALID
, CKR.USER_NOT_LOGGED_IN
,
CKR.FUNCTION_REJECTED
public static int C_SignUpdate(com.sun.jna.NativeLong hSession, byte[] pPart, com.sun.jna.NativeLong ulPartLen)
The signature operation must have been initialized with C_SignInit. This function may be called any number of times in succession. A call to C_SignUpdate which results in an error terminates the current signature operation.
hSession
- the session's handlepPart
- the data to signulPartLen
- count of bytes to sign
CKR.ARGUMENTS_BAD
, CKR.CRYPTOKI_NOT_INITIALIZED
,
CKR.DATA_LEN_RANGE
, CKR.DEVICE_ERROR
, CKR.DEVICE_MEMORY
,
CKR.DEVICE_REMOVED
, CKR.FUNCTION_CANCELED
,
CKR.FUNCTION_FAILED
, CKR.GENERAL_ERROR
, CKR.HOST_MEMORY
,
CKR.OK
, CKR.OPERATION_NOT_INITIALIZED
, CKR.SESSION_CLOSED
,
CKR.SESSION_HANDLE_INVALID
, CKR.USER_NOT_LOGGED_IN
public static int C_SignFinal(com.sun.jna.NativeLong hSession, byte[] pSignature, LongRef pulSignatureLen)
C_SignFinal uses the convention described in Section 11.2 on producing output. The signing operation must have been initialized with C_SignInit. A call to C_SignFinal always terminates the active signing operation unless it returns CKR_BUFFER_TOO_SMALL or is a successful call (i.e., one which returns CKR_OK) to determine the length of the buffer needed to hold the signature.
hSession
- the session's handlepSignature
- gets the signaturepulSignatureLen
- gets signature length
CKR.ARGUMENTS_BAD
, CKR.BUFFER_TOO_SMALL
,
CKR.CRYPTOKI_NOT_INITIALIZED
, CKR.DATA_LEN_RANGE
,
CKR.DEVICE_ERROR
, CKR.DEVICE_MEMORY
, CKR.DEVICE_REMOVED
,
CKR.FUNCTION_CANCELED
, CKR.FUNCTION_FAILED
,
CKR.GENERAL_ERROR
, CKR.HOST_MEMORY
, CKR.OK
,
CKR.OPERATION_NOT_INITIALIZED
, CKR.SESSION_CLOSED
,
CKR.SESSION_HANDLE_INVALID
, CKR.USER_NOT_LOGGED_IN
,
CKR.FUNCTION_REJECTED
public static int C_SignRecoverInit(com.sun.jna.NativeLong hSession, CKM pMechanism, com.sun.jna.NativeLong hKey)
After calling C_SignRecoverInit, the application may call C_SignRecover to sign in a single part. The signature operation is active until the application uses a call to C_SignRecover to actually obtain the signature. To process additional data in a single part, the application must call C_SignRecoverInit again.
hSession
- the session's handlepMechanism
- the signature mechanismhKey
- handle of the signature key
CKR.ARGUMENTS_BAD
, CKR.CRYPTOKI_NOT_INITIALIZED
,
CKR.DEVICE_ERROR
, CKR.DEVICE_MEMORY
, CKR.DEVICE_REMOVED
,
CKR.FUNCTION_CANCELED
, CKR.FUNCTION_FAILED
,
CKR.GENERAL_ERROR
, CKR.HOST_MEMORY
,
CKR.KEY_FUNCTION_NOT_PERMITTED
, CKR.KEY_HANDLE_INVALID
,
CKR.KEY_SIZE_RANGE
, CKR.KEY_TYPE_INCONSISTENT
,
CKR.MECHANISM_INVALID
, CKR.MECHANISM_PARAM_INVALID
, CKR.OK
,
CKR.OPERATION_ACTIVE
, CKR.PIN_EXPIRED
, CKR.SESSION_CLOSED
,
CKR.SESSION_HANDLE_INVALID
, CKR.USER_NOT_LOGGED_IN
public static int C_SignRecover(com.sun.jna.NativeLong hSession, byte[] pData, com.sun.jna.NativeLong ulDataLen, byte[] pSignature, LongRef pulSignatureLen)
C_SignRecover uses the convention described in Section 11.2 on producing output. The signing operation must have been initialized with C_SignRecoverInit. A call to C_SignRecover always terminates the active signing operation unless it returns CKR_BUFFER_TOO_SMALL or is a successful call (i.e., one which returns CKR_OK) to determine the length of the buffer needed to hold the signature.
hSession
- the session's handlepData
- the data to signulDataLen
- count of bytes to signpSignature
- gets the signaturepulSignatureLen
- gets signature length
CKR.ARGUMENTS_BAD
, CKR.BUFFER_TOO_SMALL
,
CKR.CRYPTOKI_NOT_INITIALIZED
, CKR.DATA_INVALID
,
CKR.DATA_LEN_RANGE
, CKR.DEVICE_ERROR
, CKR.DEVICE_MEMORY
,
CKR.DEVICE_REMOVED
, CKR.FUNCTION_CANCELED
,
CKR.FUNCTION_FAILED
, CKR.GENERAL_ERROR
, CKR.HOST_MEMORY
,
CKR.OK
, CKR.OPERATION_NOT_INITIALIZED
, CKR.SESSION_CLOSED
,
CKR.SESSION_HANDLE_INVALID
, CKR.USER_NOT_LOGGED_IN
public static int C_VerifyInit(com.sun.jna.NativeLong hSession, CKM pMechanism, com.sun.jna.NativeLong hKey)
The CKA_VERIFY attribute of the verification key, which indicates whether the key supports verification where the signature is an appendix to the data, must be CK_TRUE. After calling C_VerifyInit, the application can either call C_Verify to verify a signature on data in a single part; or call C_VerifyUpdate one or more times, followed by C_VerifyFinal, to verify a signature on data in multiple parts. The verification operation is active until the application calls C_Verify or C_VerifyFinal. To process additional data (in single or multiple parts), the application must call C_VerifyInit again.
hSession
- the session's handlepMechanism
- the verification mechanismhKey
- verification key
CKR.ARGUMENTS_BAD
, CKR.CRYPTOKI_NOT_INITIALIZED
,
CKR.DEVICE_ERROR
, CKR.DEVICE_MEMORY
, CKR.DEVICE_REMOVED
,
CKR.FUNCTION_CANCELED
, CKR.FUNCTION_FAILED
,
CKR.GENERAL_ERROR
, CKR.HOST_MEMORY
,
CKR.KEY_FUNCTION_NOT_PERMITTED
, CKR.KEY_HANDLE_INVALID
,
CKR.KEY_SIZE_RANGE
, CKR.KEY_TYPE_INCONSISTENT
,
CKR.MECHANISM_INVALID
, CKR.MECHANISM_PARAM_INVALID
, CKR.OK
,
CKR.OPERATION_ACTIVE
, CKR.PIN_EXPIRED
, CKR.SESSION_CLOSED
,
CKR.SESSION_HANDLE_INVALID
, CKR.USER_NOT_LOGGED_IN
public static int C_Verify(com.sun.jna.NativeLong hSession, byte[] pData, com.sun.jna.NativeLong ulDataLen, byte[] pSignature, com.sun.jna.NativeLong ulSignatureLen)
The verification operation must have been initialized with C_VerifyInit. A call to C_Verify always terminates the active verification operation. A successful call to C_Verify should return either the value CKR_OK (indicating that the supplied signature is valid) or CKR_SIGNATURE_INVALID (indicating that the supplied signature is invalid). If the signature can be seen to be invalid purely on the basis of its length, then CKR_SIGNATURE_LEN_RANGE should be returned. In any of these cases, the active signing operation is terminated. C_Verify can not be used to terminate a multi-part operation, and must be called after C_VerifyInit without intervening C_VerifyUpdate calls.
For most mechanisms, C_Verify is equivalent to a sequence of C_VerifyUpdate operations followed by C_VerifyFinal.
hSession
- the session's handlepData
- signed dataulDataLen
- length of signed datapSignature
- signatureulSignatureLen
- signature length
CKR.ARGUMENTS_BAD
, CKR.CRYPTOKI_NOT_INITIALIZED
,
CKR.DATA_INVALID
, CKR.DATA_LEN_RANGE
, CKR.DEVICE_ERROR
,
CKR.DEVICE_MEMORY
, CKR.DEVICE_REMOVED
,
CKR.FUNCTION_CANCELED
, CKR.FUNCTION_FAILED
,
CKR.GENERAL_ERROR
, CKR.HOST_MEMORY
, CKR.OK
,
CKR.OPERATION_NOT_INITIALIZED
, CKR.SESSION_CLOSED
,
CKR.SESSION_HANDLE_INVALID
, CKR.SIGNATURE_INVALID
,
CKR.SIGNATURE_LEN_RANGE
public static int C_VerifyUpdate(com.sun.jna.NativeLong hSession, byte[] pPart, com.sun.jna.NativeLong ulPartLen)
The verification operation must have been initialized with C_VerifyInit. This function may be called any number of times in succession. A call to C_VerifyUpdate which results in an error terminates the current verification operation.
hSession
- the session's handlepPart
- signed dataulPartLen
- length of signed data
CKR.ARGUMENTS_BAD
, CKR.CRYPTOKI_NOT_INITIALIZED
,
CKR.DATA_LEN_RANGE
, CKR.DEVICE_ERROR
, CKR.DEVICE_MEMORY
,
CKR.DEVICE_REMOVED
, CKR.FUNCTION_CANCELED
,
CKR.FUNCTION_FAILED
, CKR.GENERAL_ERROR
, CKR.HOST_MEMORY
,
CKR.OK
, CKR.OPERATION_NOT_INITIALIZED
, CKR.SESSION_CLOSED
,
CKR.SESSION_HANDLE_INVALID
public static int C_VerifyFinal(com.sun.jna.NativeLong hSession, byte[] pSignature, com.sun.jna.NativeLong ulSignatureLen)
The verification operation must have been initialized with C_VerifyInit. A call to C_VerifyFinal always terminates the active verification operation. A successful call to C_VerifyFinal should return either the value CKR_OK (indicating that the supplied signature is valid) or CKR_SIGNATURE_INVALID (indicating that the supplied signature is invalid). If the signature can be seen to be invalid purely on the basis of its length, then CKR_SIGNATURE_LEN_RANGE should be returned. In any of these cases, the active verifying operation is terminated.
hSession
- the session's handlepSignature
- signature to verifyulSignatureLen
- signature length
CKR.ARGUMENTS_BAD
, CKR.CRYPTOKI_NOT_INITIALIZED
,
CKR.DATA_LEN_RANGE
, CKR.DEVICE_ERROR
, CKR.DEVICE_MEMORY
,
CKR.DEVICE_REMOVED
, CKR.FUNCTION_CANCELED
,
CKR.FUNCTION_FAILED
, CKR.GENERAL_ERROR
, CKR.HOST_MEMORY
,
CKR.OK
, CKR.OPERATION_NOT_INITIALIZED
, CKR.SESSION_CLOSED
,
CKR.SESSION_HANDLE_INVALID
, CKR.SIGNATURE_INVALID
,
CKR.SIGNATURE_LEN_RANGE
public static int C_VerifyRecoverInit(com.sun.jna.NativeLong hSession, CKM pMechanism, com.sun.jna.NativeLong hKey)
The CKA_VERIFY_RECOVER attribute of the verification key, which indicates whether the key supports verification where the data is recovered from the signature, must be CK_TRUE.
After calling C_VerifyRecoverInit, the application may call C_VerifyRecover to verify a signature on data in a single part. The verification operation is active until the application uses a call to C_VerifyRecover to actually obtain the recovered message.
hSession
- the session's handlepMechanism
- the verification mechanismhKey
- verification key
CKR.ARGUMENTS_BAD
, CKR.CRYPTOKI_NOT_INITIALIZED
,
CKR.DEVICE_ERROR
, CKR.DEVICE_MEMORY
, CKR.DEVICE_REMOVED
,
CKR.FUNCTION_CANCELED
, CKR.FUNCTION_FAILED
,
CKR.GENERAL_ERROR
, CKR.HOST_MEMORY
,
CKR.KEY_FUNCTION_NOT_PERMITTED
, CKR.KEY_HANDLE_INVALID
,
CKR.KEY_SIZE_RANGE
, CKR.KEY_TYPE_INCONSISTENT
,
CKR.MECHANISM_INVALID
, CKR.MECHANISM_PARAM_INVALID
, CKR.OK
,
CKR.OPERATION_ACTIVE
, CKR.PIN_EXPIRED
, CKR.SESSION_CLOSED
,
CKR.SESSION_HANDLE_INVALID
, CKR.USER_NOT_LOGGED_IN
public static int C_VerifyRecover(com.sun.jna.NativeLong hSession, byte[] pSignature, com.sun.jna.NativeLong ulSignatureLen, byte[] pData, LongRef pulDataLen)
C_VerifyRecover uses the convention described in Section 11.2 on producing output. The verification operation must have been initialized with C_VerifyRecoverInit. A call to C_VerifyRecover always terminates the active verification operation unless it returns CKR_BUFFER_TOO_SMALL or is a successful call (i.e., one which returns CKR_OK) to determine the length of the buffer needed to hold the recovered data.
A successful call to C_VerifyRecover should return either the value CKR_OK (indicating that the supplied signature is valid) or CKR_SIGNATURE_INVALID (indicating that the supplied signature is invalid). If the signature can be seen to be invalid purely on the basis of its length, then CKR_SIGNATURE_LEN_RANGE should be returned. The return codes CKR_SIGNATURE_INVALID and CKR_SIGNATURE_LEN_RANGE have a higher priority than the return code CKR_BUFFER_TOO_SMALL, i.e., if C_VerifyRecover is supplied with an invalid signature, it will never return CKR_BUFFER_TOO_SMALL.
hSession
- the session's handlepSignature
- signature to verifyulSignatureLen
- signature lengthpData
- gets signed datapulDataLen
- gets signed data len
CKR.ARGUMENTS_BAD
, CKR.BUFFER_TOO_SMALL
,
CKR.CRYPTOKI_NOT_INITIALIZED
, CKR.DATA_INVALID
,
CKR.DATA_LEN_RANGE
, CKR.DEVICE_ERROR
, CKR.DEVICE_MEMORY
,
CKR.DEVICE_REMOVED
, CKR.FUNCTION_CANCELED
,
CKR.FUNCTION_FAILED
, CKR.GENERAL_ERROR
, CKR.HOST_MEMORY
,
CKR.OK
, CKR.OPERATION_NOT_INITIALIZED
, CKR.SESSION_CLOSED
,
CKR.SESSION_HANDLE_INVALID
, CKR.SIGNATURE_LEN_RANGE
,
CKR.SIGNATURE_INVALID
public static int C_DigestEncryptUpdate(com.sun.jna.NativeLong hSession, byte[] pPart, com.sun.jna.NativeLong ulPartLen, byte[] pEncryptedPart, LongRef ulEncryptedPartLen)
C_DigestEncryptUpdate uses the convention described in Section 11.2 on producing output. If a C_DigestEncryptUpdate call does not produce encrypted output (because an error occurs, or because pEncryptedPart has the value NULL_PTR, or because pulEncryptedPartLen is too small to hold the entire encrypted part output), then no plaintext is passed to the active digest operation.
Digest and encryption operations must both be active (they must have been initialized with C_DigestInit and C_EncryptInit, respectively). This function may be called any number of times in succession, and may be interspersed with C_DigestUpdate, C_DigestKey, and C_EncryptUpdate calls (it would be somewhat unusual to intersperse calls to C_DigestEncryptUpdate with calls to C_DigestKey, however).
hSession
- the session's handlepPart
- the plaintext dataulPartLen
- plaintet lengthpEncryptedPart
- gets ciphertextulEncryptedPartLen
- gets c-text length
CKR.ARGUMENTS_BAD
, CKR.BUFFER_TOO_SMALL
,
CKR.CRYPTOKI_NOT_INITIALIZED
, CKR.DATA_LEN_RANGE
,
CKR.DEVICE_ERROR
, CKR.DEVICE_MEMORY
, CKR.DEVICE_REMOVED
,
CKR.FUNCTION_CANCELED
, CKR.FUNCTION_FAILED
,
CKR.GENERAL_ERROR
, CKR.HOST_MEMORY
, CKR.OK
,
CKR.OPERATION_NOT_INITIALIZED
, CKR.SESSION_CLOSED
,
CKR.SESSION_HANDLE_INVALID
public static int C_DecryptDigestUpdate(com.sun.jna.NativeLong hSession, byte[] pEncryptedPart, com.sun.jna.NativeLong ulEncryptedPartLen, byte[] pPart, LongRef pulPartLen)
C_DecryptDigestUpdate uses the convention described in Section 11.2 on producing output. If a C_DecryptDigestUpdate call does not produce decrypted output (because an error occurs, or because pPart has the value NULL_PTR, or because pulPartLen is too small to hold the entire decrypted part output), then no plaintext is passed to the active digest operation.
Decryption and digesting operations must both be active (they must have been initialized with C_DecryptInit and C_DigestInit, respectively). This function may be called any number of times in succession, and may be interspersed with C_DecryptUpdate, C_DigestUpdate, and C_DigestKey calls (it would be somewhat unusual to intersperse calls to C_DigestEncryptUpdate with calls to C_DigestKey, however).
Use of C_DecryptDigestUpdate involves a pipelining issue that does not arise when using C_DigestEncryptUpdate, the "inverse function" of C_DecryptDigestUpdate. This is because when C_DigestEncryptUpdate is called, precisely the same input is passed to both the active digesting operation and the active encryption operation; however, when C_DecryptDigestUpdate is called, the input passed to the active digesting operation is the output of the active decryption operation. This issue comes up only when the mechanism used for decryption performs padding.
In particular, envision a 24-byte ciphertext which was obtained by encrypting an 18-byte plaintext with DES in CBC mode with PKCS padding. Consider an application which will simultaneously decrypt this ciphertext and digest the original plaintext thereby obtained.
After initializing decryption and digesting operations, the application passes the 24-byte ciphertext (3 DES blocks) into C_DecryptDigestUpdate. C_DecryptDigestUpdate returns exactly 16 bytes of plaintext, since at this point, Cryptoki doesn’t know if there’s more ciphertext coming, or if the last block of ciphertext held any padding. These 16 bytes of plaintext are passed into the active digesting operation.
Since there is no more ciphertext, the application calls C_DecryptFinal. This tells Cryptoki that there’s no more ciphertext coming, and the call returns the last 2 bytes of plaintext. However, since the active decryption and digesting operations are linked only through the C_DecryptDigestUpdate call, these 2 bytes of plaintext are not passed on to be digested.
A call to C_DigestFinal, therefore, would compute the message digest of the first 16 bytes of the plaintext, not the message digest of the entire plaintext. It is crucial that, before C_DigestFinal is called, the last 2 bytes of plaintext get passed into the active digesting operation via a C_DigestUpdate call.
Because of this, it is critical that when an application uses a padded decryption mechanism with C_DecryptDigestUpdate, it knows exactly how much plaintext has been passed into the active digesting operation. Extreme caution is warranted when using a padded decryption mechanism with C_DecryptDigestUpdate.
hSession
- the session's handlepEncryptedPart
- ciphertextulEncryptedPartLen
- ciphertext lengthpPart
- gets plaintextpulPartLen
- gets plaintext length
CKR.ARGUMENTS_BAD
, CKR.BUFFER_TOO_SMALL
,
CKR.CRYPTOKI_NOT_INITIALIZED
, CKR.DEVICE_ERROR
,
CKR.DEVICE_MEMORY
, CKR.DEVICE_REMOVED
,
CKR.ENCRYPTED_DATA_INVALID
, CKR.ENCRYPTED_DATA_LEN_RANGE
,
CKR.FUNCTION_CANCELED
, CKR.FUNCTION_FAILED
,
CKR.GENERAL_ERROR
, CKR.HOST_MEMORY
, CKR.OK
,
CKR.OPERATION_NOT_INITIALIZED
, CKR.SESSION_CLOSED
,
CKR.SESSION_HANDLE_INVALID
public static int C_SignEncryptUpdate(com.sun.jna.NativeLong hSession, byte[] pPart, com.sun.jna.NativeLong ulPartLen, byte[] pEncryptedPart, LongRef pulEncryptedPartLen)
C_SignEncryptUpdate uses the convention described in Section 11.2 on producing output. If a C_SignEncryptUpdate call does not produce encrypted output (because an error occurs, or because pEncryptedPart has the value NULL_PTR, or because pulEncryptedPartLen is too small to hold the entire encrypted part output), then no plaintext is passed to the active signing operation.
Signature and encryption operations must both be active (they must have been initialized with C_SignInit and C_EncryptInit, respectively). This function may be called any number of times in succession, and may be interspersed with C_SignUpdate and C_EncryptUpdate calls.
hSession
- the session's handlepPart
- the plaintext dataulPartLen
- plaintext lengthpEncryptedPart
- gets ciphertextpulEncryptedPartLen
- gets c-text length
CKR.ARGUMENTS_BAD
, CKR.BUFFER_TOO_SMALL
,
CKR.CRYPTOKI_NOT_INITIALIZED
, CKR.DATA_LEN_RANGE
,
CKR.DEVICE_ERROR
, CKR.DEVICE_MEMORY
, CKR.DEVICE_REMOVED
,
CKR.FUNCTION_CANCELED
, CKR.FUNCTION_FAILED
,
CKR.GENERAL_ERROR
, CKR.HOST_MEMORY
, CKR.OK
,
CKR.OPERATION_NOT_INITIALIZED
, CKR.SESSION_CLOSED
,
CKR.SESSION_HANDLE_INVALID
, CKR.USER_NOT_LOGGED_IN
public static int C_DecryptVerifyUpdate(com.sun.jna.NativeLong hSession, byte[] pEncryptedPart, com.sun.jna.NativeLong ulEncryptedPartLen, byte[] pPart, LongRef pulPartLen)
C_DecryptVerifyUpdate uses the convention described in Section 11.2 on producing output. If a C_DecryptVerifyUpdate call does not produce decrypted output (because an error occurs, or because pPart has the value NULL_PTR, or because pulPartLen is too small to hold the entire encrypted part output), then no plaintext is passed to the active verification operation.
Decryption and signature operations must both be active (they must have been initialized with C_DecryptInit and C_VerifyInit, respectively). This function may be called any number of times in succession, and may be interspersed with C_DecryptUpdate and C_VerifyUpdate calls.
Use of C_DecryptVerifyUpdate involves a pipelining issue that does not arise when using C_SignEncryptUpdate, the "inverse function" of C_DecryptVerifyUpdate. This is because when C_SignEncryptUpdate is called, precisely the same input is passed to both the active signing operation and the active encryption operation; however, when C_DecryptVerifyUpdate is called, the input passed to the active verifying operation is the output of the active decryption operation. This issue comes up only when the mechanism used for decryption performs padding.
In particular, envision a 24-byte ciphertext which was obtained by encrypting an 18-byte plaintext with DES in CBC mode with PKCS padding. Consider an application which will simultaneously decrypt this ciphertext and verify a signature on the original plaintext thereby obtained.
After initializing decryption and verification operations, the application passes the 24- byte ciphertext (3 DES blocks) into C_DecryptVerifyUpdate.
C_DecryptVerifyUpdate returns exactly 16 bytes of plaintext, since at this point, Cryptoki doesn’t know if there’s more ciphertext coming, or if the last block of ciphertext held any padding. These 16 bytes of plaintext are passed into the active verification operation.
Since there is no more ciphertext, the application calls C_DecryptFinal. This tells Cryptoki that there’s no more ciphertext coming, and the call returns the last 2 bytes of plaintext. However, since the active decryption and verification operations are linked only through the C_DecryptVerifyUpdate call, these 2 bytes of plaintext are not passed on to the verification mechanism.
A call to C_VerifyFinal, therefore, would verify whether or not the signature supplied is a valid signature on the first 16 bytes of the plaintext, not on the entire plaintext. It is crucial that, before C_VerifyFinal is called, the last 2 bytes of plaintext get passed into the active verification operation via a C_VerifyUpdate call.
Because of this, it is critical that when an application uses a padded decryption mechanism with C_DecryptVerifyUpdate, it knows exactly how much plaintext has been passed into the active verification operation. Extreme caution is warranted when using a padded decryption mechanism with C_DecryptVerifyUpdate.
hSession
- the session's handlepEncryptedPart
- ciphertextulEncryptedPartLen
- ciphertext lengthpPart
- gets plaintextpulPartLen
- gets p-text length
CKR.ARGUMENTS_BAD
, CKR.BUFFER_TOO_SMALL
,
CKR.CRYPTOKI_NOT_INITIALIZED
, CKR.DATA_LEN_RANGE
,
CKR.DEVICE_ERROR
, CKR.DEVICE_MEMORY
, CKR.DEVICE_REMOVED
,
CKR.ENCRYPTED_DATA_INVALID
, CKR.ENCRYPTED_DATA_LEN_RANGE
,
CKR.FUNCTION_CANCELED
, CKR.FUNCTION_FAILED
,
CKR.GENERAL_ERROR
, CKR.HOST_MEMORY
, CKR.OK
,
CKR.OPERATION_NOT_INITIALIZED
, CKR.SESSION_CLOSED
,
CKR.SESSION_HANDLE_INVALID
public static int C_GenerateKey(com.sun.jna.NativeLong hSession, CKM pMechanism, Template pTemplate, com.sun.jna.NativeLong ulCount, LongRef phKey)
Since the type of key or domain parameters to be generated is implicit in the generation mechanism, the template does not need to supply a key type. If it does supply a key type which is inconsistent with the generation mechanism, C_GenerateKey fails and returns the error code CKR_TEMPLATE_INCONSISTENT. The CKA_CLASS attribute is treated similarly.
If a call to C_GenerateKey cannot support the precise template supplied to it, it will fail and return without creating an object.
The object created by a successful call to C_GenerateKey will have its CKA_LOCAL attribute set to CK_TRUE.
hSession
- the session's handlepMechanism
- key generation mec.pTemplate
- template for new keyulCount
- # of attrs in templatephKey
- gets handle of new key
CKR.ARGUMENTS_BAD
, CKR.ATTRIBUTE_READ_ONLY
,
CKR.ATTRIBUTE_TYPE_INVALID
, CKR.ATTRIBUTE_VALUE_INVALID
,
CKR.CRYPTOKI_NOT_INITIALIZED
, CKR.DEVICE_ERROR
,
CKR.DEVICE_MEMORY
, CKR.DEVICE_REMOVED
,
CKR.FUNCTION_CANCELED
, CKR.FUNCTION_FAILED
,
CKR.GENERAL_ERROR
, CKR.HOST_MEMORY
, CKR.MECHANISM_INVALID
,
CKR.MECHANISM_PARAM_INVALID
, CKR.OK
, CKR.OPERATION_ACTIVE
,
CKR.PIN_EXPIRED
, CKR.SESSION_CLOSED
,
CKR.SESSION_HANDLE_INVALID
, CKR.SESSION_READ_ONLY
,
CKR.TEMPLATE_INCOMPLETE
, CKR.TEMPLATE_INCONSISTENT
,
CKR.TOKEN_WRITE_PROTECTED
, CKR.USER_NOT_LOGGED_IN
public static int C_GenerateKeyPair(com.sun.jna.NativeLong hSession, CKM pMechanism, Template pPublicKeyTemplate, com.sun.jna.NativeLong ulPublicKeyAttributeCount, Template pPrivateKeyTemplate, com.sun.jna.NativeLong ulPrivateKeyAttributeCount, LongRef phPublicKey, LongRef phPrivateKey)
Since the types of keys to be generated are implicit in the key pair generation mechanism, the templates do not need to supply key types. If one of the templates does supply a key type which is inconsistent with the key generation mechanism, C_GenerateKeyPair fails and returns the error code CKR_TEMPLATE_INCONSISTENT. The CKA_CLASS attribute is treated similarly.
If a call to C_GenerateKeyPair cannot support the precise templates supplied to it, it will fail and return without creating any key objects.
A call to C_GenerateKeyPair will never create just one key and return. A call can fail, and create no keys; or it can succeed, and create a matching public/private key pair. The key objects created by a successful call to C_GenerateKeyPair will have their CKA_LOCAL attributes set to CK_TRUE.
Note carefully the order of the arguments to C_GenerateKeyPair. The last two arguments do not have the same order as they did in the original Cryptoki Version 1.0 document. The order of these two arguments has caused some unfortunate confusion.
hSession
- the session's handlepMechanism
- key-gen mech.pPublicKeyTemplate
- template for pub. keyulPublicKeyAttributeCount
- # pub attrs.pPrivateKeyTemplate
- template for priv. keyulPrivateKeyAttributeCount
- # priv. attrs.phPublicKey
- gets pub key handlephPrivateKey
- gets priv key handle
CKR.ARGUMENTS_BAD
, CKR.ATTRIBUTE_READ_ONLY
,
CKR.ATTRIBUTE_TYPE_INVALID
, CKR.ATTRIBUTE_VALUE_INVALID
,
CKR.CRYPTOKI_NOT_INITIALIZED
, CKR.DEVICE_ERROR
,
CKR.DEVICE_MEMORY
, CKR.DEVICE_REMOVED
,
CKR.DOMAIN_PARAMS_INVALID
, CKR.FUNCTION_CANCELED
,
CKR.FUNCTION_FAILED
, CKR.GENERAL_ERROR
, CKR.HOST_MEMORY
,
CKR.MECHANISM_INVALID
, CKR.MECHANISM_PARAM_INVALID
, CKR.OK
,
CKR.OPERATION_ACTIVE
, CKR.PIN_EXPIRED
, CKR.SESSION_CLOSED
,
CKR.SESSION_HANDLE_INVALID
, CKR.SESSION_READ_ONLY
,
CKR.TEMPLATE_INCOMPLETE
, CKR.TEMPLATE_INCONSISTENT
,
CKR.TOKEN_WRITE_PROTECTED
, CKR.USER_NOT_LOGGED_IN
public static int C_WrapKey(com.sun.jna.NativeLong hSession, CKM pMechanism, com.sun.jna.NativeLong hWrappingKey, com.sun.jna.NativeLong hKey, byte[] pWrappedKey, LongRef pulWrappedKeyLen)
C_WrapKey uses the convention described in Section 11.2 on producing output. The CKA_WRAP attribute of the wrapping key, which indicates whether the key supports wrapping, must be CK_TRUE. The CKA_EXTRACTABLE attribute of the key to be wrapped must also be CK_TRUE.
If the key to be wrapped cannot be wrapped for some token-specific reason, despite its having its CKA_EXTRACTABLE attribute set to CK_TRUE, then C_WrapKey fails with error code CKR_KEY_NOT_WRAPPABLE. If it cannot be wrapped with the specified wrapping key and mechanism solely because of its length, then C_WrapKey fails with error code CKR_KEY_SIZE_RANGE.
C_WrapKey can be used in the following situations:
Of course, tokens vary in which types of keys can actually be wrapped with which mechanisms.
To partition the wrapping keys so they can only wrap a subset of extractable keys the attribute CKA_WRAP_TEMPLATE can be used on the wrapping key to specify an attribute set that will be compared against the attributes of the key to be wrapped. If all attributes match according to the C_FindObject rules of attribute matching then the wrap will proceed. The value of this attribute is an attribute template and the size is the number of items in the template times the size of CK_ATTRIBUTE. If this attribute is not supplied then any template is acceptable. Attributes not present are not checked. If any attribute mismatch occurs on an attempt to wrap a key then the function shall return CKR_KEY_HANDLE_INVALID.
hSession
- the session's handlepMechanism
- the wrapping mechanismhWrappingKey
- wrapping keyhKey
- key to be wrappedpWrappedKey
- gets wrapped keypulWrappedKeyLen
- gets wrapped key size
CKR.ARGUMENTS_BAD
, CKR.BUFFER_TOO_SMALL
,
CKR.CRYPTOKI_NOT_INITIALIZED
, CKR.DEVICE_ERROR
,
CKR.DEVICE_MEMORY
, CKR.DEVICE_REMOVED
,
CKR.FUNCTION_CANCELED
, CKR.FUNCTION_FAILED
,
CKR.GENERAL_ERROR
, CKR.HOST_MEMORY
,
CKR.KEY_HANDLE_INVALID
, CKR.KEY_NOT_WRAPPABLE
,
CKR.KEY_SIZE_RANGE
, CKR.KEY_UNEXTRACTABLE
,
CKR.MECHANISM_INVALID
, CKR.MECHANISM_PARAM_INVALID
, CKR.OK
,
CKR.OPERATION_ACTIVE
, CKR.PIN_EXPIRED
, CKR.SESSION_CLOSED
,
CKR.SESSION_HANDLE_INVALID
, CKR.USER_NOT_LOGGED_IN
,
CKR.WRAPPING_KEY_HANDLE_INVALID
,
CKR.WRAPPING_KEY_SIZE_RANGE
,
CKR.WRAPPING_KEY_TYPE_INCONSISTENT
public static int C_UnwrapKey(com.sun.jna.NativeLong hSession, CKM pMechanism, com.sun.jna.NativeLong pUnwrappingKey, byte[] pWrappedKey, com.sun.jna.NativeLong ulWrappedKeyLen, Template pTemplate, com.sun.jna.NativeLong ulAttributeCount, LongRef hKey)
The CKA_UNWRAP attribute of the unwrapping key, which indicates whether the key supports unwrapping, must be CK_TRUE.
The new key will have the CKA_ALWAYS_SENSITIVE attribute set to CK_FALSE, and the CKA_NEVER_EXTRACTABLE attribute set to CK_FALSE. The CKA_EXTRACTABLE attribute is by default set to CK_TRUE. Some mechanisms may modify, or attempt to modify. the contents of the pMechanism structure at the same time that the key is unwrapped. If a call to C_UnwrapKey cannot support the precise template supplied to it, it will fail and return without creating any key object. The key object created by a successful call to C_UnwrapKey will have its CKA_LOCAL attribute set to CK_FALSE.
To partition the unwrapping keys so they can only unwrap a subset of keys the attribute CKA_UNWRAP_TEMPLATE can be used on the unwrapping key to specify an attribute set that will be added to attributes of the key to be unwrapped. If the attributes do not conflict with the user supplied attribute template, in ‘pTemplate’, then the unwrap will proceed. The value of this attribute is an attribute template and the size is the number of items in the template times the size of CK_ATTRIBUTE. If this attribute is not present on the unwrapping key then no additional attributes will be added. If any attribute conflict occurs on an attempt to unwrap a key then the function shall return CKR_TEMPLATE_INCONSISTENT.
hSession
- the session's handlepMechanism
- unwrapping mechanismpUnwrappingKey
- uwrapping keypWrappedKey
- the wrapped keyulWrappedKeyLen
- wrapped key lenpTemplate
- new key templateulAttributeCount
- template lengthhKey
- gets new handle
CKR.ARGUMENTS_BAD
, CKR.ATTRIBUTE_READ_ONLY
,
CKR.ATTRIBUTE_TYPE_INVALID
, CKR.ATTRIBUTE_VALUE_INVALID
,
CKR.BUFFER_TOO_SMALL
, CKR.CRYPTOKI_NOT_INITIALIZED
,
CKR.DEVICE_ERROR
, CKR.DEVICE_MEMORY
, CKR.DEVICE_REMOVED
,
CKR.DOMAIN_PARAMS_INVALID
, CKR.FUNCTION_CANCELED
,
CKR.FUNCTION_FAILED
, CKR.GENERAL_ERROR
, CKR.HOST_MEMORY
,
CKR.MECHANISM_INVALID
, CKR.MECHANISM_PARAM_INVALID
, CKR.OK
,
CKR.OPERATION_ACTIVE
, CKR.PIN_EXPIRED
, CKR.SESSION_CLOSED
,
CKR.SESSION_HANDLE_INVALID
, CKR.SESSION_READ_ONLY
,
CKR.TEMPLATE_INCOMPLETE
, CKR.TEMPLATE_INCONSISTENT
,
CKR.TOKEN_WRITE_PROTECTED
,
CKR.UNWRAPPING_KEY_HANDLE_INVALID
,
CKR.UNWRAPPING_KEY_SIZE_RANGE
,
CKR.UNWRAPPING_KEY_TYPE_INCONSISTENT
,
CKR.USER_NOT_LOGGED_IN
, CKR.WRAPPED_KEY_INVALID
,
CKR.WRAPPED_KEY_LEN_RANGE
public static int C_DeriveKey(com.sun.jna.NativeLong hSession, CKM pMechanism, com.sun.jna.NativeLong hBaseKey, Template pTemplate, com.sun.jna.NativeLong ulAttributeCount, LongRef phKey)
The values of the CK_SENSITIVE, CK_ALWAYS_SENSITIVE, CK_EXTRACTABLE, and CK_NEVER_EXTRACTABLE attributes for the base key affect the values that these attributes can hold for the newly-derived key. See the description of each particular key-derivation mechanism in Section 11.17.2 for any constraints of this type.
If a call to C_DeriveKey cannot support the precise template supplied to it, it will fail and return without creating any key object. The key object created by a successful call to C_DeriveKey will have its CKA_LOCAL attribute set to CK_FALSE.
hSession
- the session's handlepMechanism
- key deriv. mech.hBaseKey
- base keypTemplate
- new key templateulAttributeCount
- phKey
- gets new handle
CKR.ARGUMENTS_BAD
, CKR.ATTRIBUTE_READ_ONLY
,
CKR.ATTRIBUTE_TYPE_INVALID
, CKR.ATTRIBUTE_VALUE_INVALID
,
CKR.CRYPTOKI_NOT_INITIALIZED
, CKR.DEVICE_ERROR
,
CKR.DEVICE_MEMORY
, CKR.DEVICE_REMOVED
,
CKR.DOMAIN_PARAMS_INVALID
, CKR.FUNCTION_CANCELED
,
CKR.FUNCTION_FAILED
, CKR.GENERAL_ERROR
, CKR.HOST_MEMORY
,
CKR.KEY_HANDLE_INVALID
, CKR.KEY_SIZE_RANGE
,
CKR.KEY_TYPE_INCONSISTENT
, CKR.MECHANISM_INVALID
,
CKR.MECHANISM_PARAM_INVALID
, CKR.OK
, CKR.OPERATION_ACTIVE
,
CKR.PIN_EXPIRED
, CKR.SESSION_CLOSED
,
CKR.SESSION_HANDLE_INVALID
, CKR.SESSION_READ_ONLY
,
CKR.TEMPLATE_INCOMPLETE
, CKR.TEMPLATE_INCONSISTENT
,
CKR.TOKEN_WRITE_PROTECTED
, CKR.USER_NOT_LOGGED_IN
public static int C_SeedRandom(com.sun.jna.NativeLong hSession, byte[] pSeed, com.sun.jna.NativeLong ulSeedLen)
hSession
- the session's handlepSeed
- the seed materialulSeedLen
- length of seed material
CKR.ARGUMENTS_BAD
, CKR.CRYPTOKI_NOT_INITIALIZED
,
CKR.DEVICE_ERROR
, CKR.DEVICE_MEMORY
, CKR.DEVICE_REMOVED
,
CKR.FUNCTION_CANCELED
, CKR.FUNCTION_FAILED
,
CKR.GENERAL_ERROR
, CKR.HOST_MEMORY
, CKR.OK
,
CKR.OPERATION_ACTIVE
, CKR.RANDOM_SEED_NOT_SUPPORTED
,
CKR.RANDOM_NO_RNG
, CKR.SESSION_CLOSED
,
CKR.SESSION_HANDLE_INVALID
, CKR.USER_NOT_LOGGED_IN
public static int C_GenerateRandom(com.sun.jna.NativeLong hSession, byte[] RandomData, com.sun.jna.NativeLong ulRandomLen)
hSession
- the session's handleRandomData
- receives the random dataulRandomLen
- # of bytes to generate
CKR.ARGUMENTS_BAD
, CKR.CRYPTOKI_NOT_INITIALIZED
,
CKR.DEVICE_ERROR
, CKR.DEVICE_MEMORY
, CKR.DEVICE_REMOVED
,
CKR.FUNCTION_CANCELED
, CKR.FUNCTION_FAILED
,
CKR.GENERAL_ERROR
, CKR.HOST_MEMORY
, CKR.OK
,
CKR.OPERATION_ACTIVE
, CKR.RANDOM_NO_RNG
,
CKR.SESSION_CLOSED
, CKR.SESSION_HANDLE_INVALID
,
CKR.USER_NOT_LOGGED_IN
public static int C_GetFunctionStatus(com.sun.jna.NativeLong hSession)
hSession
- the session's handle
CKR.CRYPTOKI_NOT_INITIALIZED
}, CKR.FUNCTION_FAILED
,
CKR.FUNCTION_NOT_PARALLEL
, CKR.GENERAL_ERROR
,
CKR.HOST_MEMORY
, CKR.SESSION_HANDLE_INVALID
,
CKR.SESSION_CLOSED
public static int C_CancelFunction(com.sun.jna.NativeLong hSession)
hSession
- the session's handle
CKR.CRYPTOKI_NOT_INITIALIZED
}, CKR.FUNCTION_FAILED
,
CKR.FUNCTION_NOT_PARALLEL
, CKR.GENERAL_ERROR
,
CKR.HOST_MEMORY
, CKR.SESSION_HANDLE_INVALID
,
CKR.SESSION_CLOSED
|
||||||||||
| PREV CLASS NEXT CLASS | FRAMES NO FRAMES | |||||||||
| SUMMARY: NESTED | FIELD | CONSTR | METHOD | DETAIL: FIELD | CONSTR | METHOD |