PKCS#11 – Implementation Details#

Slots and Tokens#

A PKCS#11 token represents a combination of persistent object storage , and access to cryptographic hardware.

Supported PKCS#11 Token Types#

Four PKCS#11 token types are supported:

CCPLEX

Provides the most comprehensive support for cryptographic operations across available hardware.

TSEC

On Thor, the TSEC hardware is not used directly to provide cryptographic services. However, the TSEC token is emulated for backward compatibility.

Supports only AES CMAC sign and verify operations.
Requires keys to reside in the safety token.
To use TSEC: - Install the required keys into the dynamic token as token objects. - Commit the keys. - Reboot the system.

After reboot, the safety token can access and use the keys for CMAC operations.

TSECRADAR

Also emulated on Thor for backward compatibility. TSECRADAR is reserved for a specific radar sensor data authentication use case.

Uses AES CMAC sign and verify operations.
Keys are dynamically derived at runtime on the safety token and used immediately.

FSI

Used for key management only. Does not support any cryptographic operations.

Note

The PKCS#11 interfaces may be used to provision keys used in the FSI, but using those keys in the FSI requires a different interface. For additional information, see “Functional Safety Island (FSI)” in the NVIDIA DriveOS SDK Developer Guide.

Note

Key management operations C_CopyObject and C_SetAttribute are not supported for FSI token keys. This means FSI token key attributes cannot be changed after key creation and FSI token keys cannot be copied.

There is a requirement for object access control for CCPLEX. This is to allow different applications to use the same CCPLEX hardware, but with access to different sets of objects. For example, you can have an application that processes sensor data with one set of keys and a webstore application with a different set of keys. Each application must not be able to access the other set of objects but must execute operations on the same set of cryptographic hardware. This is implemented by having multiple PKCS#11 tokens for CCPLEX hardware, each with its own storage areas, access protection TA nodes, and Linux capabilities. It is recommended that each client application use a different CCPLEX token.

There is a requirement to protect safety applications from changes to token objects while they are running (UNECE 156a 7.2.2.1.3). There may also be other, non-safety critical applications that need the ability to change token objects at runtime. To allow for this, each configuration of hardware and access control has a dynamic token view and a safety token view. The dynamic token allows for token objects to be added, updated, and deleted , and once added can be used immediately. The safety token has a static view of the content of the persistent storage as it was at boot time - objects can be accessed, but not altered, added, or deleted in this view.

To alter the objects in the safety view:

Make the changes in the dynamic view of the same storage ID.
Call C_NVIDIA_CommitTokenObjects() with no PKCS#11 sessions open on any safety token (this is to prevent safety-critical operations stalling as the commit happens).
Either reboot, or go through an SC7 cycle (calling C_Finalize() before suspending and C_Initialize() after resuming).

Note

Transitioning without an SC7 cycle or reboot results in no change to the objects in the safety view.

Twenty nine tokens are supported, which have the following model names listed in the CK_TOKEN_INFO structure:

Model name	TA Node	Secure storage instance ID	Supported hardware, safety or dynamic	Notes
NVPKCS11_FSI_DYNAMIC_1_MODEL_NAME	NVTZVAULT_TA_02	1	FSI, dynamic
NVPKCS11_CCPLEX_SAFETY_2_MODEL_NAME	NVTZVAULT_TA_03	2	CCPLEX, safety
NVPKCS11_CCPLEX_DYNAMIC_2_MODEL_NAME	NVTZVAULT_TA_04	2	CCPLEX, dynamic
NVPKCS11_TSEC_SAFETY_3_MODEL_NAME	NVTZVAULT_TA_05	3	TSEC, safety	Token keys only. AES CMAC sign and verify support only.
NVPKCS11_TSEC_DYNAMIC_3_MODEL_NAME	NVTZVAULT_TA_06	3	TSEC, dynamic	No cryptographic operations support. AES key management support: using derive with CKM_SP800_108_COUNTER_KDF; using unwrap with CKM_AES_GCM or CKM_NVIDIA_AES_GCM_KEY_UNWRAP.
NVPKCS11_CCPLEX_SAFETY_4_MODEL_NAME	NVTZVAULT_TA_07	4	CCPLEX, safety
NVPKCS11_CCPLEX_DYNAMIC_4_MODEL_NAME	NVTZVAULT_TA_08	4	CCPLEX, dynamic
NVPKCS11_CCPLEX_SAFETY_5_MODEL_NAME	NVTZVAULT_TA_09	5	CCPLEX, safety
NVPKCS11_CCPLEX_DYNAMIC_5_MODEL_NAME	NVTZVAULT_TA_10	5	CCPLEX, dynamic
… etc
… etc
NVPKCS11_CCPLEX_SAFETY_12_MODEL_NAME	NVTZVAULT_TA_23	12	CCPLEX, safety	NVIDIA reserved for Camera *
NVPKCS11_CCPLEX_DYNAMIC_12_MODEL_NAME	NVTZVAULT_TA_24	12	CCPLEX, dynamic	NVIDIA reserved for Camera *
NVPKCS11_CCPLEX_SAFETY_13_MODEL_NAME	NVTZVAULT_TA_25	13	CCPLEX, safety	NVIDIA reserved for MACSEC
NVPKCS11_CCPLEX_DYNAMIC_13_MODEL_NAME	NVTZVAULT_TA_26	13	CCPLEX, dynamic	NVIDIA reserved for MACSEC
NVPKCS11_CCPLEX_SAFETY_14_MODEL_NAME	NVTZVAULT_TA_27	14	CCPLEX, safety	NVIDIA reserved for Drive Update
NVPKCS11_CCPLEX_DYNAMIC_14_MODEL_NAME	NVTZVAULT_TA_28	14	CCPLEX, dynamic	NVIDIA reserved for Drive Update
NVPKCS11_TSECRADAR_SAFETY_15_MODEL_NAME	NVTZVAULT_TA_29	15	TSECRADAR, safety	AES CMAC sign and verify support using session keys
NVPKCS11_TSECRADAR_DYNAMIC_15_MODEL_NAME	NVTZVAULT_TA_30	15	TSECRADAR, dynamic

*If using DriveOS with Sony IMX623 and IMX728 sensors

The PKCS#11 sample app demonstrates how to use C_GetTokenInfo to identify and open a token that matches that name (NVPKCS#11_CCPLEX_DYNAMIC_2_MODEL_NAME).

Accessing the Token

To use a token, your application must have access to both keys in a persistent storage area and access to cryptographic hardware engines. The permissions for these are handled using TA nodes and Linux capabilities.

Note

You must not run applications as root. If you run as root, then your application reserves resources from every token, even if you do not use them. This can lead to token resources running out and preventing other applications from working correctly.

Note

A maximum of eight applications can use a single token.

Note

Plan your usage of tokens and applications at the design stage. You should aim that if a set of keys and data objects is needed by one application, then those keys and data objects are placed in a token, and that no other application has permission to use them. If there are keys that need to be shared across applications, then aim for a single token for that sharing purpose.

There are 29 unique key storage area custom abilities, one for each of the supported tokens.

There is 1 nvtzvault/crypto_ability custom ability required by every PKCS#11 library application.

To use a CCPLEX or TSECRADAR token, your application must also have access permission to all three GP-SE channels, by adding nvvse/Engines:0-2 custom abilities.

While not recommended, where it is unavoidable and essential to allow a QM application to use INIT phase APIs in the Run/Operational state, add nvvse/allow_open_operational and nvtzvault/allow_open_operational custom abilities.

To use a TSEC or TSECRADAR token the application requires nvvse/Engines:6 custom ability.

The PKCS#11 sample app README file demonstrates how to run the sample app as non-root and to use NVPKCS11_CCPLEX_DYNAMIC_2_MODEL_NAME.

Choosing the Token

If your application is safety related , it should use a safety token. This is to prevent interference from any other applications or updates.

If your application needs to update objects in secure storage , it must use a dynamic token. Note that the safety token does not see those changes until after a reboot or an SC7 cycle has taken place.

If your application requires access to persistently stored objects , and also requires that those objects are not accessible to any other applications , then use a unique secure storage instance ID.

The following example shows how secure storage updates can be performed, and also how the isolation between safety and dynamic tokens works.

Step 1

System is powered off. Secure storage for ID 4 contains four keys.

Step 2

Power on. System boots. Two PKCS11 tokens are created for CCPLEX hardware with secure storage ID 4.

Each token contains a copy of the secure storage content.

Step 3

A safety critical application connects to the CCPLEX_SAFETY_4 token, and starts to use key 1 for an operation.

Step 4

An update app connects to CCPLEX_DYNAMIC_4. This is app is not safety critical. It also uses key 1.

Step 5

The update app needs to replace key 1. It begins by deleting that key. Note that the original key still exists in the safety token, and in secure storage.

The safety app continues to function without interruption.

Step 6

A new key (5) is added to CCPLEX_DYNAMIC_4. The new key is visible to any app that uses the CCPLEX_DYNAMIC_4 token.

The CCPLEX_SAFETY_4 token has no way to see this key. It is not yet in secure storage, so would be lost if a reboot were to happen.

Step 7

The update app now checks that key 5 is functional by performing some operations with it.

Secure storage cannot be updated yet, as the safety app is still using CCPLEX_SAFETY_4.

Step 8

Safety app has terminated. The update app then commits the changes to secure storage by calling C_NVIDIA_CommitTokenObjects().

Step 9

A reboot then takes place. Key 1 is no longer usable by CCPLEX_SAFETY_4 or CCPLEX_DYNAMIC_4, and both tokens can use key 5.

Underlying Resource Limitations#

Functionality

Limited by

Details

Avoidance

Digest

NVVSE digest context availability

One digest per channel, per application (each application can run a single digest).

To share a digest channel within an application:

Place a mutex around all digest operations, from C_DigestInit to the end of the digest operation - so C_DigestInit/ C_Digest, or C_DigestInit / C_DigestUpdate / C_DigestFinal.

To run multiple digests in parallel within an application:

Use C_NVIDIA_InitializeChannel to open a dedicated digest channel, and then C_NVIDIA_OpenSession to set up a session to use that channel.

AES operations

Keyslot availability

Limited number of keyslots per SE instance. Refer to the “SE Keyslot Assignment” topic in the NVIDIA DriveOS SDK Developer Guide.

Configure tokens to have keyslot limits enforced

Plan software such that the resource usage matches the number of keyslots

Asymmetric (RSA, ECDSA, EDDSA) signing and verification

Keyslot availability

VM	Keyslot count
VM0	3 or 2 if VM1 is configured
VM1	1 (only if VM1 is configured)
Drive Update	1

There are fewer asymmetric keyslots than AES keyslots, so it is more difficult to plan for sharing across multiple applications.

Add a retry mechanism to C_SignInit and C_VerifyInit for asymmetric operations in case of other threads or applications accessing at the same time.

Multi-Threaded Application#

PKCS#11 library only supports multi-threaded access by an application using the native operating system primitives.

Session Type#

PKCS#11 library supports read/write (R/W) user sessions on dynamic tokens, and read-only (R/O) user sessions on all tokens. To update secure storage in a R/W session, C_NVIDIA_CommitTokenObjects() must be called as outlined previously.

Active Operation Abandonment#

PKCS#11 library fails any cryptographic initialization functions for a session if there are any active operations of the same type on that session. The active operation resets and return to the idle state.

Operations of different types can be called in any combination on the same session, where different types means these 10 different operations:

FIND_OBJECTS, DIGEST, SIGN, MESSAGE_SIGN, VERIFY, MESSAGE_VERIFY, ENCRYPT, MESSAGE_ENCRYPT, DECRYPT, MESSAGE_DECRYPT

PKCS#11 library additionally allows C_MessageSignInit and C_MessageVerifyInit to be called with pMechanism set to NULL_PTR to terminate an active operation

.

Operations That Cannot Be Canceled by C_SessionCancel#

PKCS#11 library shall return CKR_OPERATION_CANCEL_FAILED if any of the following operations are included in the request to C_SessionCancel:

CKF_GENERATE_KEY_PAIR
CKF_GENERATE
CKF_WRAP
CKF_UNWRAP
CKF_DERIVE

User Type#

PKCS#11 library only supports the user type: normal user.

Read-Only User Authentication#

PKCS#11 library supports normal user login to a read only session without the need for a PIN.

pPin from client application is NULL_PTR.

Read/Write User Authentication#

PKCS#11 library supports login of an authenticated normal user login to a Read/Write session without the need for a PIN.

pPin from client application is NULL_PTR.

Maximum Input Data Size Limits for AES and Digest Operations#

Maximum input data size limits for any operations using GP-SE or GC-SE cryptographic hardware are determined by the max_buf_size and gcmdec_buf_size configuration parameters described in the “VSE IVC Queue Configuration” topic.

Encrypt Input Data Length#

PKCS#11 library restricts the data length of all multi-part encrypt update operations using CKM_AES_CBC_PAD mechanism to be a multiple of the cryptographic operation block size. The exception is the last encrypt update part, which does not have to be a multiple of the block size.

Encrypt operations using CKM_AES_CTR mechanism restricts data length to multiples of 16 bytes only.

Decrypt Input Data length#

PKCS#11 library restricts the data length of multi-part decrypt update operations to be a multiple of the cryptographic operation block size.

Decrypt operations using CKM_AES_CTR mechanism restricts data length to multiples of 16 bytes only.

Session Object Limit#

PKCS#11 library restricts the number of session objects that may be created, generated, derived, or unwrapped across all sessions of a single application to a total of 88 keys split as 64 secret, 8 RSA public, 8 EC public and 8 EC private keys and 8 data objects, subject to the support of those objects by the tokens in use.

Cryptoki Function Calls#

PKCS#11 library does not support every function in the Cryptoki API. It has a stub for every unsupported function and returns the value CKR_FUNCTION_NOT_SUPPORTED.

Callback Function Not Supported#

PKCS#11 library does not support surrender callbacks.

C_GetInterface Usage to Return Pointer to NV_CK_FUNCTION_LIST#

Pass “Vendor NVIDIA” as pInterfaceName, use NULL pointer for pVersion, and flags is 0:

C_GetInterface((CK_UTF8CHAR_PTR)NVIDIA_INTERFACE_NAME, NULL, &pInterface, 0)

Find Objects#

PKCS#11 library supports finding token and session objects - either all objects, or with a template to narrow the search. The template can have up to one entry each for CKA_TOKEN, CKA_CLASS and CKA_ID, but must have at least one attribute specified (and none repeated).

If a search operation is active, and objects are created or destroyed which fit the scope of the search, the search operation fails upon a C_FindObjects() call continuing the search and returns CKR_NVIDIA_OBJECTS_CHANGED. In this event, there may be duplicate object handles returned. You should re-initialize the search.

Deriving Additional Key#

PKCS#11 library limits key derivation to a single derived key per one C_DeriveKey() call when using CKM_SP800_108_COUNTER_KDF mechanism.

Derivation From Fuse-based Keys#

The support for NV_OEM_KEY1 and NV_OEM_KEY2 for key derivation using SP800-108-Counter-KDF-HMAC-SHA256(Key=FUSE_KEYS_KDK0_0_0 (ODM_KDK0), L=256, Label=, Context=) scheme has been added. Refer to the following table for derivation data values. The purpose of these keys are set to HMAC in the key manifest, meaning the API is responsible for preparing the input in the format mentioned in the scheme. PKCS#11 Library provides interfaces for key derivation using these two keys.

The two (2) keys (NV_OEM_KEY1 and NV_OEM_KEY2) are derived from ODM_KDK0 using the same SP800-108-Counter-KDF-HMAC-SHA256 scheme. However, the two keys are different in the sense that the label and context used to derive these keys from ODM_KDK0 are different. While NV_OEM_KEY1 is same for all devices, if ODM KDK0 is a class key i.e. same for all devices, NV_OEM_KEY2 is a device-specific key as Exclusive Chip ID (ECID), which is unique to each device, is used as the context for the derivation of this key.

Fused Key Hierarchy

Refer to the following table for derivation data values of NV_OEM_KEY1 and NV_OEM_KEY2

PRF Input	Data Field Identifier	Format	Value
[i]	CK_SP800_108_ITERATION_VARIABLE	Big Endian 32 bit integer	Value for NV_OEM_KEY1 & NV_OEM_KEY2 is 0x00000001
Label	CK_SP800_108_BYTE_ARRAY	1 to 32 bytes	NV_OEM_KEY1 - “NV_OEM_DERIVED_1”NV_OEM_KEY2 - “NV_OEM_DERIVED_2”
0x00	CK_SP800_108_BYTE_ARRAY	1 byte	“00” in HexString Format
Context	CK_SP800_108_BYTE_ARRAY	1 to 32 bytes	Value for NV_OEM_KEY1 - “00” in hex string format and size is 1 byte. Value for NV_OEM_KEY2 - and size is 16 bytes.
[L]	CK_SP800_108_DKM_LENGTH	Big Endian 32 bit integer.	Key Length for NV_OEM_KEY1 and NV_OEM_KEY2 is 256 bits. Calue is 0x00000100.

PKCS#11 library supports derivation from the following named fuse-based keys:

CKA_ID
“NV_OEM_KEY1”	A general purpose OEM-defined key
“NV_OEM_KEY2”	A general purpose device-unique key

CKM_SP800_108_COUNTER_KDF Input Parameters#

PKCS#11 library limits the counter mode key derivation function, denoted CKM_SP800_108_COUNTER_KDF, to use the following PRF input data definitions.

SP800-108 section 5.1 outlines a sample Counter Mode KDF, which defines the following PRF input:

PRF (KI,[i] || Label || 0x00 || Context ||[L])

where || is the concatenation operation in which the order of the values are defined and KI is the base key being derived from.

The following table lists the PRF input data field types, meanings, limitations, and order that are supported within the CK_PRF_DATA_PARAM structure:

PRF Input	Data Field Identifier	Format	Description	Comment
[i]	CK_SP800_108_ITERATION_VARIABLE	Big Endian 8 or 32 bits wide	Counter integer that is the iteration variable. Value shall be 1 for SHA_256_HMAC or AES_CMAC PRF	Default: Use 32 bits wide. 8 bits wide support is for MACSEC wpa-supplicant application
Label	CK_SP800_108_BYTE_ARRAY	1 to 32 bytes	Client Application supplied byte array that identifies the purpose for the derived keying material. The byte 0x00 is not allowed.
0x00	CK_SP800_108_BYTE_ARRAY	1 byte	An all zero octet. Used to indicate a separation of different variable length data fields
Context	CK_SP800_108_BYTE_ARRAY	1 to 32 bytes	Client Application supplied byte array containing the information related to the derived key.
[L]	CK_SP800_108_DKM_LENGTH	Big Endian 16 or 32 bits wide	An integer specifying the length (in bits) of the derived key.	Default: Use 32 bits wide. 16 bits wide support is for MACSEC wpa-supplicant application

Secret Key Material Protection#

PKCS#11 library does not allow access to secret key material or secret key check value.

Limit AES Block Count within AES-CTR Encryption#

It is assumed that users of Security Services keep the total number of AES blocks less than 2^32 (2 to the power of 32) within an AES-CTR encryption operation when operating using a particular key. This prevents collisions of the Initialization Vector (IV) used for these blocks, which can lower the security of AES-CTR cipher.

Added Allowed Function Return Values#

PKCS#11 library allows CKR_OPERATION_ACTIVE return value for C_Digest, C_Encrypt, and C_Decrypt functions. The current operation resets and returns to idle state upon returning CKR_OPERATION_ACTIVE. The approach taken warns of a potential programming error rather than silently accepting it.

PKCS#11 library allows CKR_MECHANISM_INVALID return value for C_xxUpdate, C_xxFinal if C_xxInit is called with mechanism CKM_AES_GCM.

PKCS#11 library allows CKR_OPERATION_NOT_INITIALIZED return value for C_xxMessageBegin, C_EncryptMessage, C_DecryptMessage functions.

PKCS#11 library allows CKR_OPERATION_ACTIVE return value for C_xxMessageNext and CxxMessage functions. The current operation resets and returns to idle state upon returning CKR_OPERATION_ACTIVE. The approach taken warns of a potential programming error rather than silently accepting it.

PKCS#11 library allows CKR_SESSION_READ_ONLY_EXISTS return value for C_OpenSession function.

PKCS#11 library allows CKR_ARGUMENTS_BAD return value for C_EncryptMessageBegin function.

PKCS#11 library allows CKR_MECHANISM_INVALID return value for C_xxMessageBegin functions.

PKCS#11 library allows CKR_MECHANISM_PARAM_INVALID return value for C_xxMessageBegin, C_EncryptMessage, C_DecryptMessage functions.

PKCS#11 library allows CKR_FUNCTION_NOT_SUPPORTED return value for C_SignUpdate, C_SignFinal, C_VerifyUpdate, and C_VerifyFinal functions.

PKCS#11 library allows C_VerifyMessage and C_VerifyMessageNext to continue on CKR_SIGNATURE_INVALID.

PKCS#11 library allows CKR_TEMPLATE_INCONSISTENT return value for C_FindObjectsInit function.

PKCS#11 library allows vendor-specified CKR_NVIDIA_OBJECTS_CHANGED return value for C_FindObjects function.

PKCS#11 library allows vendor-specified CKR_NVIDIA_CRYPTOKI_UNAVAILABLE return value for all functions that can be called after the library has been initialized.

PKCS#11 library allows vendor-specified CKR_NVIDIA_FUNCTION_NOT_ALLOWED_IN_SYSTEM_STATE return value for C_Initialize and C_Finalize functions.

Symmetric Key Block Mode#

When using PKCS#11 APIs to generate, derive, or unwrap symmetric keys, you must specify at most one block mode in the CKA_ALLOWED_MECHANISMS template attribute for any particular key.

Exception: Specifying CKM_AES_CBC and CKM_AES_CBC_PAD for the same key is acceptable.

CMAC Message Length#

PKCS#11 library does not support signature requests using CKM_AES_CMAC with a 0 (zero)-length message.

Mutually Exclusive KDF Mechanism Support#

When using PKCS#11 APIs to derive from a base key, that base key can support either one of CKM_SP800_108_COUNTER_KDF or CKM_NVIDIA_SP800_56c_TWO_STEPS_KDF but not both together.

C_Finalize Prior to SC7 Entry#

All applications that use PKCS#11 library must call C_Finalize prior to SC7 entry. If this is not done, then you receive unexpected errors when attempting to use PKCS#11 APIs.

C_WrapKey with CKM_AES_CBC Output IV Handling#

For C_WrapKey with CKM_AES_CBC mechanism the IV buffer provided by the caller as part of the mechanism parameters is an output and is overwritten by an internally generated random IV.

GCM with Zero-Length Data#

PKCS#11 library supports encrypt or decrypt operations using CKM_AES_GCM with 0 (zero)-length data.

ECDSA and EDDSA Signature Encoding#

PKCS#11 library supports ECDSA signatures that are ASN.1 DER encoded, an NVIDIA limitation.

PKCS#11 library supports EDDSA signatures that are in the raw (bit string) format.

EDDSAph Message Hash Expectations#

When using CKM_EDDSA, the mechanism parameter is optional:

Not using the parameter selects the PureEdDSA algorithm ed25519.
Setting the pre-hashed flag (phFlag) to TRUE (with pContextData and ulContextDataLen to NULL and 0 respectively) selects the HashEdDSA algorithm ed25519ph.

For ed25519ph the message is expected to be a SHA-512 hash, an NVIDIA limitation.

Exclusive extension CMAC Mechanism Support#

The key used with the NVIDIA extension mechanism CKM_NVIDIA_PSC_AES_CMAC shall only have this mechanism in its CKA_ALLOWED_MECHANISMS list.

C_Initialize and C_Finalize are per Application not per Thread#

When designing your application that uses PKCS#11, consider the following:

C_Initialize must be called exactly once, ahead of any cryptographic operations. If C_Initialize is called again, the error CKR_CRYPTOKI_ALREADY_INITIALIZED is returned. Do not call C_Initialize from multiple threads/locations.
C_Finalize terminates all cryptographic operations across all threads. It must therefore only be called once all cryptographic operations have completed, and no new operations are needed. Do not call C_Finalize from multiple threads/locations.
If you are using libraries that also use PKCS#11 functionality in their code, then they should document how and when they should be called.
Typically the application should call C_Initialize and then start the library functionality.
Calls to C_Finalize need to be co-ordinated with the individual libraries, and also the customer developed state transition application to ensure that it is called during the DEINIT phase.

C_Finalize When No Other Threads Call PKCS#11 APIs#

The PKCS#11 specification states that, “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.”

Do not call C_Finalize when other threads are calling PKCS#11 APIs.

If you call C_Finalize when other threads are calling PKCS#11 APIs, the library waits for up to 1 second for those other PKCS11 operations to complete.
If PKCS#11 calls are still outstanding after 1s, C_Finalize returns CKR_FUNCTION_FAILED. You can retry C_Finalize if required.

C_Finalize is an INIT/DEINIT Phase API#

NVIDIA does not recommend calling C_Finalize in the Run/Operational state.

Restrict PKCS#11 Mechanisms#

PKCS#11 mechanisms may be selectively disabled to restrict user access to specific functionalities on designated tokens. Configuration of these restrictions is achievable through the Policy Configuration Tool (PCT). Following is a suggested use case for this feature.

.tos_keystore_conf = {

    .tos_keystore_api_conf[0U] = {
                    .cmdId = 0x00007006,   //To block RSA OAEP WRAP which uses RSA-2k pub key
                    .token_block =
                                    {true, true, true, true, true, true,    //Blocking status on each token i.e from [2, 30]
                                    true, true, true, true, true, true,
                                    true, true, true, true, true, true,
                                    true, true, true, true, true, true,
                                    true, true, true, true, true, true,
                                    true},
              },

    .num_apis_blocked = 1U,

}

Here, the PKCS11 mechanism RSA-OAEP wrap, which is denoted by the command Id 0x00007006, is blocked for all tokens, such as for token IDs ranging from 2 to 30. Each index of the token_block array denotes the corresponding token Id (indexes 0 and 1 can be ignored). RSA-OAEP Wrap should only be used when using DriveOS with Omnivision Ox5B sensors so they can be blocked when that is not the case.