Document Number
CR-1423
Change Level
8
Security Level
Page Number
21 of 27
the subject is associated and one of the following two conditions holds:
1.
The object is a "Public" object, i.e., the PRIVATE attribute is FALSE, or
2.
The subject is bound to the Partition User that owns the object.
·
Allowed operations are those permitted by the object attribute definitions within the constraints of
the Module and Partition Capability and Policy settings.
3.5.1.
Object Re-use
The access control policy is supported by an object re-use policy. The object re-use policy requires that the
resources allocated to an object be cleared of their information content before they are re-allocated to a
different object.
3.5.2.
Privileged Functions
The module shall restrict the performance of the following functions to the SO role only:
·
Module initialization
·
Partition creation and deletion
·
Configuring the module and partition policies
·
Module zeroization
·
Firmware update
3.6.
Cryptographic Material Management
Cryptographic material (key) management functions protect the confidentiality of key material throughout its life-
cycle. The FIPS PUB 140-2 approved key management functions provided by the module are the following:
(1) Pseudo random number generation in accordance with ANSI X9.31, Appendix A.
(2) Cryptographic key generation in accordance with the following indicated standards:
a.
RSA 1024, 2048 and 4096 bits key pairs in accordance with FIPS PUB 186-2.
b.
3DES 112, 168 bits (FIPS PUB 46-3, ANSI X9.52).
c.
AES 128, 192, 256 bits (FIPS PUB 197).
d.
DSA 1024 bits key pairs in accordance with FIPS PUB 186-2.
(3) Secure key storage and key access following the PKCS #11 standard.
(4) Destruction of cryptographic keys is performed in one of three ways as described below in
accordance with the PKCS #11 and FIPS PUB 140-2 standards:
a.
An object on the K3 that is destroyed using the PKCS #11 function C_DestroyObject is marked
invalid and remains encrypted with the Partition User's key or the K3's general secret key until
such time as its memory locations (flash or RAM) are re-allocated for additional data on the K3,
at which time they are purged and zeroized before re-allocation.
b.
Objects on the K3 that are destroyed as a result of authentication failure are zeroized (all flash
blocks in the Partition User's memory turned to 1's). If it is an SO authentication failure all flash
blocks used for key and data storage on the K3 are zeroized.
c.
Objects on the K3 that are destroyed through C_InitToken (the SO-accessible command to
initialize the K3 available through the API) are zeroized, along with the rest of the flash memory
being used by the SO and Partition Users.