PKCS # 11 Tokens: Certificates and Private Keys

PKCS # 11 tokens perform not only cryptographic functions (generating key pairs, generating and verifying electronic signatures, and others), but also serve as a repository for public (public, PUBLIC KEY) and private (private, PRIVATE KEY) keys. Certificates can also be stored on the token. As a rule, personal certificates are stored on the token along with the key pair. In this case, several personal certificates can be stored on the token.

There is a dilemma how to determine which private key (and the public one too) corresponds to a particular certificate.

Such a correspondence is usually established by setting identical CKA_ID and / or CKA_LABEL parameters for three objects: a certificate ( CKO_CERTIFICAT E), a public key ( CKO_PUBLIC_KEY ) and a private key ( CKO_PRIVATE_KEY ).

The question arises - how to set these values ​​so that at least there is no conflict, and how safe it is from the point of view of obtaining the correct result.
')
The most common way to set the CKA_ID is to use the hash value of the value of the public key. This is the way to link the top three objects used in the NSS project (Network Security Services) and Redfox browser. In this case, the SHA1 algorithm is used as a hash function. Taking into account the fact that hardly more than a dozen personal certificates will actually be stored on the token, then from the point of view of the appearance of a collision, this method is good. However, the CKA_ID for this triple can be set at any time and any value. This is the whole problem. If RFC or TK-26 Recommendations required setting the CKA_ID parameter at the moment an object appeared on the token (for example, when generating the CKM_GOSTR3410_KEY_GEN_PAIR key pair) and it could not be changed, then this narration could be completed. Unfortunately, this is not the case. As already mentioned, CKA_ID can be set at any time with any value. Thus, there is always a chance that the certificate will be associated with someone else's private key. No need to explain how this will lead to consequences.

But in general, is there a rigorous mathematical algorithm that allows you to tie the CKO_CERTIFICATE x CKO_PRIVATE_KEY x CKO_PUBLIC_KEY three together?

Yes, such an algorithm based on the cryptographic mechanisms ( CKM_ ) of the token exists. A bunch of certificate and public key is checked easily and simply. Take the value of the public key and its parameters from the certificate and are compared with similar values ​​of the public key.

As for the certificate and private key, until recently this algorithm looked as follows. Using a private key, a signature is formed under some text (for example, “search for a private key”), and then with the public key obtained from the certificate, the correctness of the received signature is verified. If the signature is correct, then we received the private key for the selected certificate. If not, the next private key on the token is selected.

All, we now do not depend on CKA_ID , nor on CKA_LABEL .

But the document “METHODICAL RECOMMENDATIONS. The expansion of PKCS # 11 for the use of Russian standards GOST R 34.10-2012, GOST R 34.11-2012, GOST R 34.12-2015 and GOST R 34.13-2015 ” , in which a new mechanism CKM_GOSTR3410_PUBLIC_KEY_DERIVE appears - the mechanism for creating a public key from a private key. This mechanism is used in C_DeriveKey . Now the search for the private key for the certificate is greatly simplified. It is enough to get a list of private keys on the token, then for each private key to get the public key:

… CK_OBJECT_HANDLE priv_key = CK_INVALID_HANDLE; CK_OBJECT_HANDLE pub_key = CK_INVALID_HANDLE; CK_MECHANISM mechanism_der_desc = { CKM_GOSTR3410_PUBLIC_KEY_DERIVE, NULL, 0 }; CK_MECHANISM_PTR mechanism_der = &mechanism_der_desc; … //      rc = funcs->C_DeriveKey(sess, mechanism_der, priv_key, NULL, 0, &pub_key); … 

And then we compare the values ​​of the received public key with the values ​​of the public key in the certificate.

Using any of these algorithms eliminates the need to keep track of the CKA_ID / CKA_LABEL values and makes the use of certificates and private keys stored on PKCS # 11 tokens both safe and secure.

Using the CKM_GOSTR3410_PUBLIC_KEY_DERIVE mechanism implies its implementation on one or another token. It is convenient to view the list of implemented mechanisms using the p11conf utility available for free download:

 $ /usr/local/bin64/p11conf -h usage: /usr/local/bin64/p11conf [-hitsmIupPred] -A APIpath [-c slotID -U userPin -S SOPin -n newPin -L label] -h display usage -i display PKCS#11 library info -s display slot(s) info (-c slotID is optional) -t display token(s) info (-c slotID is optional) Others must use -c slotID -m display mechanism list -I initialize token -u initialize user PIN -p set the user PIN -P set the SO PIN -r remove all objects -e enumerate objects -d dump all object attributes Copyright(C) LISSI-Soft Ltd (http://soft.lissi.ru) 2011-2016 $ 

The list of available mechanisms can be viewed as follows:

 $ /usr/local/bin64/p11conf -A /usr/local/lib64/libls11usb2016.so -m -c 0|grep GOSTR3410 Mechanism: CKM_GOSTR3410_KEY_PAIR_GEN (0x1200) Mechanism: CKM_GOSTR3410_512_KEY_PAIR_GEN (0xD4321005) Mechanism: CKM_GOSTR3410 (0x1201) Mechanism: CKM_GOSTR3410_512 (0xD4321006) Mechanism: CKM_GOSTR3410_WITH_GOSTR3411 (0x1202) Mechanism: CKM_GOSTR3410_WITH_GOSTR3411_12_256 (0xD4321008) Mechanism: CKM_GOSTR3410_WITH_GOSTR3411_12_512 (0xD4321009) Mechanism: CKM_GOSTR3410_DERIVE (0x1204) Mechanism: CKM_GOSTR3410_12_DERIVE (0xD4321007) Mechanism: CKM_GOSTR3410_KEY_WRAP (0x1203) Mechanism: CKM_GOSTR3410_PUBLIC_KEY_DERIVE (0xD432100A) Mechanism: CKM_LISSI_GOSTR3410_PUBLIC_KEY_DERIVE (0xD4321037) $ 

And lastly, are there any tokens that have been developed in accordance with the document “METHODICAL RECOMMENDATIONS. Expansion of PKCS # 11 for the use of Russian standards GOST R 34.10-2012, GOST R 34.11-2012, GOST R 34.12-2015 and GOST R 34.13-2015 " ?

Yes, there is, this is a family of tokens LS11 .