Geekly Articles each Day
📜 ⬆️ ⬇️

PKCS # 11 Tokens: generation of a key pair and the non-recoverability of a private key (Continued)

image In the previous article “PKCS # 11 Tokens: Certificates and Private Keys ”, we looked at how to unambiguously associate the three Certificate x Public Key x Private Key stored on a token / smarter with the PKCS # 11 interface v.2.40. In this article we will talk about generating a key pair. We will rely, as last time, on “GOST R 34.10-2012 Information technology. Cryptographic protection of information. Processes of formation and verification of electronic digital signature .

So what is a key pair?


Key pair includes two keys:


It should be remembered that the private and public keys are not only their values ​​(for the public key GOST R 34.10-2001 is 512 bits), but also the parameters of the digital signature scheme (clause 5.2 of GOST R 34.10-2012 ). In the future, the parameters of the digital signature scheme for simplicity will be called the parameters (crypto parameters) of the key pair.

The public key of the signature is calculated as the value of a certain function of the private key, but knowledge of the public key does not make it possible to determine the private key.

For key pairs of GOST R 34.10-2001 and GOST R 34.10-2012 with the length of the private key of 256 bits (respectively, the public key is 512 bits), the following crypto parameters are defined :

  1. id-GostR3410-2001-CryptoPro-A-ParamSet;
  2. id-GostR3410-2001-CryptoPro-B-ParamSet;
  3. id-GostR3410-2001-CryptoPro-C-ParamSet;
  4. id-GostR3410-2001-CryptoPro-XchA-ParamSet;
  5. id-GostR3410-2001-CryptoPro-XchB-ParamSet.

For key pairs of GOST R 34.10-2012 with the private key length of 512 bits (respectively, the public key is 1024 bits), the following crypto parameters are defined ( "Information technology. Cryptographic information protection. Parameters of elliptic curves for cryptographic algorithms and protocols" ):

  1. id-tc26-gost-3410-2012-512-paramSetA;
  2. id-tc26-gost-3410-2012-512-paramSetB.

The composition of the crypto parameters is defined in clause 5.2 in GOST R 34.10-2012 . This structure includes a prime number q - the order of a subgroup of a group of points of an elliptic curve:

image

And it determines the length of the private / public key and the correctness of the private key:

image - the length of the private key is 256 bits;

image - the length of the private key 512 bits.
And so, the public key is obtained from the private key.

And where does the private key come from?


To obtain the private key, you must first decide how long the private key will be (256 or 512 bits), then decide on the key pair crypto parameters. Now we take the random number sensor and get a random number of the appropriate length. Actually this is a random number and should be the d value of the private key (the d key of the signature). This value should satisfy the following rule:

0 <d <q , where q is a prime number from cryptoparameters.

What if this condition is not met? If d == 0 , then just generate a new random number. Otherwise, it is enough to take the remainder of dividing by integer the value of d that exceeds q by q (d% q) . The remainder will become the value of the private key.

That is why the regulator (FSB of Russia) places special demands on the random number sensor.

As an example of the main source to fill the buffer:


As additional sources for filling this buffer can be:


Thus, in order for a PKCS # 11 token / smartcard to generate a key pair within itself, it is necessary to have a built-in hardware random number generator token / smartcard that meets the requirements of the regulator. And only then can we talk about the inability of the private key.

To generate a key pair, the C_GenerateKeyPair function is used . Depending on which key pair (how long the private key is 256 or 512 bits) we generate, it will use the appropriate mechanism:


When generating a key pair, its attributes are set, for example, crypto parameters:

image

We are interested in the attributes of the extractability of the private key.


This is the first attribute CKA_SENSITIVE, responsible for the possibility of obtaining the value of the private key. If the value of the CKA_SENSITIVE attribute is set to CK_TRUE, then the private key cannot be extracted from the token in the open form. The second attribute CKA_EXTRACTABLE allows you to receive the private key in an encrypted form. For this, it is necessary to set CK_TRUE.

Setting the CKA_SENSITIVE attribute to CK_TRUE and the CKA_EXTRACTABLE attribute to CK_FALSE when generating a key pair makes the private key completely non-recoverable. The ability to determine whether the export key is removable is available in the Redfox browser :

image

Someone will say - what if you change the values ​​of these attributes. As a rule, this cannot be done, protection cannot be lowered, just as “the degree cannot be lowered”. Similarly, the private key can be made non-recoverable after it is imported to the token (if, of course, the token / smartcard is allowed to be imported). After the creation (or during creation) of the object CKO_PRIVATE_KEY, you must set CKA_SENSITIVE = CK_TRUE , and the attribute CKA_EXTRACTABLE = CK_FALSE .

In the latter case (when importing), it should be borne in mind that although the private key became non-recoverable, it appeared from the side (for example, from PKCS # 12 ), and there is no guarantee that there is no duplicate somewhere else.

And here it would not hurt to remind you, dear reader, that security is ensured only by the COMPLEX of organizational and technical measures . Therefore, it will not be possible to patch the holes in organizational security at the expense of technical means and vice versa - everything must be organically coordinated. Including, when accessing the value of the private key.

Make sure that the token / smartcard contains full-featured PKCS # 11 objects (CKO_PRIVATE_KEY, CKO_PUBLIC_KEY, CKO_CERTIFICATE) that participate in cryptographic operations on the token itself conveniently using the free download p11conf utility:

$ /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) 2011-2016 $

In order to see which objects are on a token, it suffices to execute a command of the form:

 bash-4.3$ /usr/local/bin64/p11conf -A /usr/local/lib64/libls11sw2016.so -c 0 -e Enter user PIN: ******** Token objects: 1: CKO_PRIVATE_KEY label: 'LS11SW2016:; ..;0x23855(145493)' 2: CKO_PUBLIC_KEY label: 'LS11SW2016:; ..;0x23855(145493)' 3: CKO_CERTIFICATE label: 'LS11SW2016:; ..;0x23855(145493)' … OK bash-4.3$

If such objects are absent on the token, and they say that the PKCS # 11 token with the non-recoverable key is used, then this is probably not the case. Most likely the token is used simply as a flash drive with a PIN code, and the certificate and keys are stored as CKO_DATA objects.

And finally, in order to see not only which types of objects are stored on the token, but objects with all attributes, you must use the additional –d flag:

 bash-4.3$ /usr/local/bin64/p11conf -A /usr/local/lib64/libls11sw2016.so -c 0 –e -d Enter user PIN: ******** Token objects: 1: CKO_PRIVATE_KEY label: 'LS11SW2016:; ..;0x23855(145493)' ================================== Object handle: 0x1 ---------------------------------- CKA_CLASS 0x03, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, CKA_TOKEN 0x01, CKA_PRIVATE 0x01, CKA_LABEL 0x4c, 0x53, 0x31, 0x31, 0x53, 0x57, 0x32, 0x30, 0x31, 0x36, 0x3a, 0xd0, 0x9e, 0xd0, 0x9e, 0xd0, 0x9e, 0x20, 0xd0, 0x9b, 0xd0, 0x98, 0xd0, 0xa1, 0xd0, 0xa1, 0xd0, 0x98, 0x2d, 0xd0, 0xa1, 0xd0, 0xbe, 0xd1, 0x84, 0xd1, 0x82, 0x3b, 0xd0, 0x9c, 0xd0, 0xb0, 0xd1, 0x81, 0xd0, 0xbb, 0xd0, 0xbe, 0x20, 0xd0, 0x90, 0x2e, 0xd0, 0x90, 0x2e, 0x3b, 0x30, 0x78, 0x32, 0x33, 0x38, 0x35, 0x35, 0x28, 0x31, 0x34, 0x35, 0x34, 0x39, 0x33, 0x29, CKA_VALUE: attribute sensitive CKA_KEY_TYPE 0x03, 0x10, 0x32, 0xd4, 0x00, 0x00, 0x00, 0x00, CKA_SUBJECT 0x30, 0x81, 0x9b, 0x31, 0x0b, 0x30, 0x09, 0x06, 0x03, 0x55, 0x04, 0x06, 0x13, 0x02, 0x52, 0x55, 0x31, 0x1a, 0x30, 0x18, 0x06, 0x03, 0x55, 0x04, 0x03, 0x0c, 0x11, 0xd0, 0x9c, 0xd0, 0xb0, 0xd1, 0x81, 0xd0, 0xbb, 0xd0, 0xbe, 0x20, 0xd0, 0x90, 0x2e, 0xd0, 0x90, 0x2e, 0x31, 0x1c, 0x30, 0x1a, 0x06, 0x03, 0x55, 0x04, 0x0a, 0x0c, 0x13, 0xd0, 0x9b, 0xd0, 0x98, 0xd0, 0xa1, 0xd0, 0xa1, 0xd0, 0x98, 0x2d, 0xd0, 0xa1, 0xd0, 0xbe, 0xd1, 0x84, 0xd1, 0x82, 0x31, 0x1f, 0x30, 0x1d, 0x06, 0x09, 0x2a, 0x86, 0x48, 0x86, 0xf7, 0x0d, 0x01, 0x09, 0x01, 0x16, 0x10, 0x61, 0x6d, 0x61, 0x73, 0x6c, 0x6f, 0x76, 0x40, 0x6c, 0x69, 0x73, 0x73, 0x69, 0x2e, 0x72, 0x75, 0x31, 0x31, 0x30, 0x2f, 0x06, 0x03, 0x55, 0x04, 0x08, 0x0c, 0x28, 0x35, 0x30, 0x20, 0x20, 0xd0, 0x9c, 0xd0, 0xbe, 0xd1, 0x81, 0xd0, 0xba, 0xd0, 0xbe, 0xd0, 0xb2, 0xd1, 0x81, 0xd0, 0xba, 0xd0, 0xb0, 0xd1, 0x8f, 0x20, 0xd0, 0xbe, 0xd0, 0xb1, 0xd0, 0xbb, 0xd0, 0xb0, 0xd1, 0x81, 0xd1, 0x82, 0xd1, 0x8c, 0x20, CKA_ID 0x97, 0x46, 0x4e, 0xcc, 0x7c, 0xa9, 0xea, 0xb1, 0x0a, 0xda, 0xec, 0x10, 0xf4, 0x49, 0x7e, 0x7f, 0x2d, 0x71, 0x4b, 0xa7, CKA_SENSITIVE 0x01, . . . CKA_GOSTR3410_PARAMS 0x06, 0x09, 0x2a, 0x85, 0x03, 0x07, 0x01, 0x02, 0x01, 0x02, 0x01, CKA_GOSTR3411_PARAMS 0x06, 0x08, 0x2a, 0x85, 0x03, 0x07, 0x01, 0x01, 0x02, 0x03, CKA_GOST28147_PARAMS 0x06, 0x07, 0x2a, 0x85, 0x03, 0x02, 0x02, 0x1f, 0x01, … OK bash-4.3$

Everything said here is true for a token / smartcard with a PKCS # 11 interface, including a cloud token .

In conclusion, we remind you that PKCS # 11 tokens / smartcards are widely used in Mozilla projects (browsers, email clients), in Google's Chrome browsers and other projects. If we talk about Russia, then tokens / smartcards with the PKCS # 11 interface are successfully used to access the portal of public services.

Source: https://habr.com/ru/post/400943/

More articles:


All Articles