CKM_SHA1_RSA_PKCS_TIMESTAMP
Supported Operations
Encrypt and Decrypt |
No |
Sign and Verify |
Sign only |
SignRecover and VerifyRecover |
No |
Digest |
No |
Generate Key/Key-Pair |
No |
Wrap and Unwrap |
No |
Derive |
No |
FIPS-approved |
No* |
* All RSA signing operations performed under FIPS mode are carried out only if the specified key has a modulus of 2048 bits or greater. Any attempt to create an RSA key smaller than 2048 bits while running in FIPS mode results in a CKR_KEY_SIZE_RANGE
or CKA_TEMPLATE_INCONSISTENT
error.
Key Size Range (bytes) and Parameters
Minimum | 512 |
FIPS Minimum |
N/A |
Maximum | 4096 |
Parameter | CK_TIMESTAMP_PARAMS
|
Description
The PKCS#11 mechanism CKM_SHA1_RSA_PKCS_TIMESTAMP provides time stamping functionality. The supported signing functions are C_Sign_Init and C_Sign. This mechanism supports single and multiple-part digital signatures and verification with message recovery. The mechanism uses the SHA1 hash function to generate the message digest. The mechanism only supports one second granularity in the timestamp although the timestamp format will provide for future sub-second granularity.
A monotonic counter object is used to generate the unique serial number that forms part of the timestamp. The monotonic counter object is automatically created when a token is initialized and exists by default in the Admin Token.
The following structure is used to provide the optional mechanism parameters in the CK_MECHANISM structure. The CK_MECHANISM structure is defined in the PKCS #11 v2.10: Cryptographic Token Interface Standard, RSA Laboratories December 1999.
typedef struct CK_TIMESTAMP_PARAMS {
CK_BBOOL useMilliseconds;
CK_TIMESTAMP_FORMAT timestampFormat;
} CK_TIMESTAMP_PARAMS;
The useMilleseconds parameter specifies whether the timestamp should include millisecond granularity. The default value for this parameter is FALSE
. If the mechanism parameters are specified then the useMilliseconds parameter must be set to FALSE
as only one-second granularity is provided in the first release of the mechanism’s implementation.
The "timeStampFormat" parameter specifies the input/output format of the data to be timestamped. This provides the ability to introduce future support for timestamping protocols such as those defined in RFC3161. The default value for this parameter is CK_TIMESTAMP_FORMAT_PTKC
. If the mechanism parameters are specified then the timeStampType parameter must be set to CK_TIMESTAMP_FORMAT_PTKC
as only this format is supported in the first release.
For CK_TIMESTAMP_FORMAT_PTKC
the mechanism expects the input data to be a stream of bytes for which a message digest must be computed and a timestamp generated according to the format defined below. If mechanism parameters are passed and the two parameters are not set as defined above, the C_SignInit function returns CKR_MECHANISM_PARAM_INVALID
.
C_Sign is defined in the PKCS #11 standard as:
CK_DEFINE_FUNCTION(CK_RV, C_Sign)(
CK_SESSION_HANDLE hSession,
CK_BYTE_PTR pData,
CK_ULONG ulDataLen,
CK_BYTE_PTR pSignature,
CK_ULONG_PTR pulSignatureLen );
The parameter formats are defined in the following tables.
C-Definition |
Description |
---|---|
unsigned char Data |
Transaction data (variable length), maximum of 3k |
C-Definition |
Contents on Output |
---|---|
Unsigned char serialnumber[20] |
This is a unique number for each timestamp, padded with zeroes in a Big Endian 20 byte array. The number is read from the CKH_MONOTONIC_COUNTER hardware feature object on the same token as the signing key. By this read action the value contained by the object is automatically increased by 1. |
Unsigned char timestamp[15] |
This is the timestamp in the format of GeneralizedTime specified in RFC3161. The syntax is: YYYYMMDDhhmmss[.s...]Z The sub-second component is optional and not supported in the intial release but still defined to ensure backward compatibility in the future. |
Unsigned char sign[128] |
RSA Signature |
NOTE Please see the PKCS #11 v2.10: Cryptographic Token Interface Standard, RSA Laboratories December 1999 for a definition of types.
NOTE It is highly recommended that the RFC3161 format timestamp provided by the HSM be stored on the host to allow future independent third party timestamp verification.
The mechanism will perform the following:
>Input data that is provided by the calling host.
>Obtain the time from within the ProtectHost.
>Calculate a signature across the merged input data and time data using PKCS#1 type 01 padding as follows:
Signature = Sign(SHA1(Data || serialnumber || timestamp)
>Output part of the input data, the time data and the signature.
Verification of the signature can be performed using the CKM_SHA1_RSA_PKCS_TIMESTAMP mechanism with C_Verify or C_VerifyRecover. The difference between the two functions is that C_Verify calculates the hash but does not return it to the caller where as C_VerifyRecover() returns the hash. The following is passed as input data: <data><serialnumber><timestamp>
Return to SafeNet ProtectToolkit-C Mechanisms