Persistent Key Object Support

NVIDIA DRIVE OS Security Services provide the ability to persistently store custom key objects on dedicated secure storage media. The format of the objects adheres to the PKCS#11 specification. The NVIDIA DRIVE OS PDK provides users the ability to generate customized wrapped PKCS#11 Key Objects and reference code that demonstrates how to provision said objects into the dedicated secure SPI-NOR hardware.

The following section describes the annotations in the “Provisioning of Persistent PKCS#11 Objects” image above.

PKCS#11 Object Spec Files

These files are the input to the PKCS#11 Object Generation Tool that specify secret key material and metadata associated with each key object. These input files must be generated in a secure environment to prevent disclosure of secret key material and associated metadata.

Refer to the Generating PKCS#11 Key Objects section for more details.

PKCS#11 Object Generation Tool

The PKCS#11 Object Generation Tool takes the inputs from the PKCS#11 Spec files and a secret key (refer the Derivation From Fuse-based Keys section under PKCS#11 – Implementation Details) to generate binaries associated with each key object.

Refer to the Generating PKCS#11 Key Objects section for more details.

Wrapped PKCS#11 Key Objects

These are the binary outputs of the PKCS#11 Object Generation Tool. These wrapped objects are authenticated and encrypted and must be securely transferred over to the target file system where the application will access them.

Application to provision PKCS#11 Key Objects into Secure SPI-NOR hardware

Once the binary output files generated using the PKCS#11 Object Generation Tool are moved over to the Guest OS filesystem, and application must read these binaries and provision them into the Secure SPI-NOR hardware using the following PKCS#11 API:

C_UnwrapKey()

Refer to the Provisioning PKCS#11 Key Objects section for more information.

PKCS#11 Library (QNX)

The user-space library that exposes Security Services to applications in the QNX Guest OS. Refer to the PKCS#11 Interface for a detailed description and documentation.

Secure SPI-NOR Hardware

The dedicated secure storage media that stores the key objects persistently. This is the destination of the UnwrapKey operation.

Confidentiality, Authenticity and Integrity

The secure storage media, along with its software driver, provides confidentiality, authenticity and integrity for the objects stored using device-specific keys. Attackers cannot read out any part of the objects in plaintext. When there is tampering against the media, errors are returned to the PKCS#11 library.

Rollback Detection

The secure storage media, along with its software driver, provides rollback attack detection for the stored PKCS#11 Key Objects. When there are rollback attacks against the media, errors are returned to the PKCS#11 library.

SPI Error Reporting

When uncorrectable errors happen during Secure SPI-NOR data transfer through SPI bus, these errors are reported to FSI.

Configurable Persistent Storage Capacity

The SPI-NOR space is divided into multiple secure storage instances on top of which the tokens are developed. Access (Read/Write) to each such instance is provided to client through a pair of Safety and Dynamic token (refer to: PKCS#11 – Implementation Details). The DRIVE OS supports configuring the maximum number of different PKCS#11 Persistent Objects that can be stored in an instance through PCT. The PCT is expected to be configured with the maximum number of objects for each supported PKCS#11 object type.

Update the tos_keystore_conf structure of the drive_av PCT guest configuration to configure secure storage instances with the required Object Capacity. The tos_keystore_conf is defined in the pct and details of the structure are below. In the PCT and some other scripts, we use the term `group` to refer to a secure storage instance for convenience, so the two terms can be treated interchangeably:

Examples

Following are examples of Object Capacity and the views of the tos_keystore_conf for the corresponding Object Capacity:

Example 1

If it is required that the...

1. NVPKCS11_TSEC_DYNAMIC_3_MODEL_NAME is expected to support a maximum number of 200 Symmetric Key Objects
2. NVPKCS11_CCPLEX_DYNAMIC_2_MODEL_NAME is expected to support a maximum of 16 Symmetric Keys, 4 RSA Public, 2 ECC Public, 2 ECC Private, 2 Generic Data Objects
3. NVPKCS11_CCPLEX_DYNAMIC_4_MODEL_NAME is expected to support a maximum of 0 Symmetric Keys, 0 RSA Public, 0 ECC Public, 0 ECC Private, 10 Generic Data Objects

.tos_keystore_conf = {
   .num_groups = 3,
   .ss_group_cfg[0] =
   {
      3U, // Group ID of the Secure Storage Group (for Token NVPKCS11_TSEC_DYNAMIC_3_MODEL_NAME)
      200U, // Max number of Symmetric keys to be supported on this group
      0U, // Max number of RSA Public Keys to be supported on this group
      0U, // Max number of ECC Public Keys to be supported on this group
      0U, // Max number of ECC Private Keys to be supported on this group
      0U, // Max number of Generic Data Objects to be supported on this group
   },
   .ss_group_cfg[1] =
   {
      2U, // Group ID of the Secure Storage Group (for Token NVPKCS11_CCPLEX_DYNAMIC_2_MODEL_NAME)
      16U, // Max number of Symmetric keys to be supported on this group
      4U, // Max number of RSA Public Keys to be supported on this group
      2U, // Max number of ECC Public Keys to be supported on this group
      2U, // Max number of ECC Private Keys to be supported on this group
      2U, // Max number of Generic Data Objects to be supported on this group
   },
   .ss_group_cfg[2] =
   {
      4U, // Group ID of the Secure Storage Group (for Token NVPKCS11_CCPLEX_DYNAMIC_4_MODEL_NAME)
      0U, // Max number of Symmetric keys to be supported on this group
      0U, // Max number of RSA Public Keys to be supported on this group
      0U, // Max number of ECC Public Keys to be supported on this group
      0U, // Max number of ECC Private Keys to be supported on this group
     10U, // Max number of Generic Data Objects to be supported on this group
   },
}

Example 2

If it is required that the...

1. NVPKCS11_TSEC_DYNAMIC_3_MODEL_NAME is expected to have a maximum number of 400 Symmetric Key Objects
2. NVPKCS11_CCPLEX_DYNAMIC_2_MODEL_NAME is expected to have 68 Symmetric Keys, 0 RSA Public, 0 ECC Public, 0 ECC Private, 5 Generic Data Objects
3. NVPKCS11_CCPLEX_DYNAMIC_4_MODEL_NAME is expected to have 16 Symmetric Keys, 0 RSA Public, 10 ECC Public, 10 ECC Private, 10 Generic Data Objects

.tos_keystore_conf = {
   .num_groups = 3,
   .ss_group_cfg[0] = {2U, 68U, 0U, 0U, 0U, 5U},
   .ss_group_cfg[1] = {3U, 400U, 0U, 0U, 0U, 0U},
   .ss_group_cfg[2] = {4U, 16U, 0U, 10U, 10U, 10U}
}

Example 3

If it is expected to support only NVPKCS11_TSEC_DYNAMIC_3_MODEL_NAME and expected to have a maximum number of 300 Symmetric Key Objects

.tos_keystore_conf = {
   .num_groups = 4,
   .ss_group_cfg[0] = {1U, 0U, 0U, 0U, 0U, 0U},
   .ss_group_cfg[1] = {2U, 0U, 0U, 0U, 0U, 0U},
   .ss_group_cfg[2] = {3U, 300U, 0U, 0U, 0U, 0U},
   .ss_group_cfg[3] = {4U, 0U, 0U, 0U, 0U, 0U}
}

Default Config

.ss_group_cfg[0] = {1U, 500U, 1U, 4U, 4U, 5U}, // Group corresponding to FSI token
.ss_group_cfg[1] = {2U, 68U, 16U, 16U, 16U, 16U}, // Group corresponding to Default CCPLEX 
.ss_group_cfg[2] = {3U, 3200U, 0U, 0U, 0U, 0U}, // Group corresponding to TSEC tokens
.ss_group_cfg[3] = {4U, 16U, 2U, 2U, 2U, 2U},
.ss_group_cfg[4] = {5U, 16U, 2U, 2U, 2U, 2U},
.ss_group_cfg[5] = {6U, 16U, 2U, 2U, 2U, 2U},

Validity of a PCT Configuration

The SPI-NOR available to the DRIVE-OS customers is 432 blocks (each block is 4KB). Dividing this space into multiple groups through the PCT configuration is allowed with certain restrictions. The DRIVE-OS clients are expected to configure the PCT with a valid configuration, where a valid configuration is

• Usage space of cumulative of all Secure Storage Groups cannot exceed 432 4KB-blocks.
• Total number of objects (sum of maximum supported of each object type) of a particular secure storage group cannot exceed 4000

The DRIVE-OS customers can confirm the validity of a PCT configuration with the Python3 script `token_size_validation.py` provided. The script `token_size_validation.py` can be used as below to validate a PCT configuration. The script can be found at this path on the DRIVE OS PDK:

drive-foundation/tools/security/pkcs11/token_size_validation/token_size_validation.py

The PCT configuration validation tool does the following things:

• Check the configuration does not violate the above restriction
• Provide the usage space of each token. Given the numbers and types of objects of a token, the script performs a depth-first-search algorithm to find the maximum space the token can occupy in case of worst fragmentation in the filesystem.
• Provide the remaining available space out of <customer_size> or report the configuration is too big and invalid

The steps to use the tool:

python3 token_size_validation.py --current-config <current_config.json> --new-config <new_config.json>
python3 token_size_validation.py --ignore-current-config --new-config <new_config.json>

Using a new configuration without comparing it with the existing configuration (via `--ignore-current-config`) should only be used in the following scenarios to avoid existing objects on the persistent SNOR exceeding the limit of the new configuration:

1. The board is a dev board (FUSE_SECURITY_MODE_0 is 0) and the developer is accepting the risk of Drive OS persistent object functionality becoming unfunctional.
2. The board is a dev board (FUSE_SECURITY_MODE_0 is 0) and the developer will use the 'wipe_secure_nor' MB2 BCT flag (adding in 6.0.7) to wipe the Secure SPI-NOR during the first boot after flash.
3. The board is new and hasn't been flashed before, which implies the SNOR is brand new.

Compatibility Restrictions

In production, customer cannot OTA a new version of DRIVE-OS with a PCT configuration that reduces the maximum number of objects supported for a particular group. For example, if in current release Secure Storage Instance 4 allows maximum 20 symmetric key objects, reducing it to 10 in the next OTA release will cause DRIVE OS to treat the existing objects as an error as they exceed the new limitation.

This will result in a functionality failure and will lead to the unavailability of PKCS#11 Persistent Object functionality.

It is strongly recommended to only configure the minimal required numbers of objects in each group to preserve space for future OTA releases.