👨🏾‍🎤 🗜️ 🏓 Public Key Infrastructure Based on Russian Cryptography: GnuTLS as an Alternative to OpenSSL 🏸 👨🏻‍🚀 🚊

Public Key Infrastructure ( PKI / PKI ) includes many different objects and mechanisms for working with them, as well as protocols for object interaction with each other (for example, TLS, OCSP). PKI objects include requests for certificates (PKCS # 10) and the x509 certificates themselves, key pairs (private and public keys), signed and encrypted documents (PKCS # 7, CMS), secure containers for storing private keys (PKCS # 8) and personal certificates with keys (PKCS # 12), etc. The mechanisms include not only cryptographic functions that allow you to encrypt and sign documents using various algorithms, but also functions that form the final PKI objects. in accordance with standards (certificates, requests, signed / encrypted documents, protocol packages, etc., etc.). Yes, and how not to recall the central object IEC / PKI - CA .

Today it is already difficult to imagine the country's business life without PKI , without x509 certificates (without qualified certificates), without GOSUSLUGI and FTS services, where documents are accepted in electronic form with an electronic signature. And more and more documents are returned to the citizen also in electronic form with an electronic signature. It is no longer possible to present legal proceedings without an electronic signature.

The most advanced tool for creating software tools working with PKI objects is OpenSSL.

OpenSSL is a set of complete open source cryptographic libraries and utilities that supports nearly all low-level hashing, encryption and digital signature algorithms, and implements most of the popular cryptographic standards. However, these cryptographic standards do not include Russian cryptography. For full-fledged work with Russian cryptography in OpenSSL, it is necessary to additionally connect the gost-engine .

We already wrote that the gcrypt library can be an alternative to openssl .... And now support for Russian cryptography and cryptographic mechanisms has been implemented in the GnuTLS project . GnuTLS supports both old cryptographic algorithms and new ones - GOST R 34.10-2012 (electronic signature), GOST R 34.11-2012 (hashing), GOST R 34.12-2015 and GOST R 34.13-2015 (encryption algorithms Grasshopper and Magma).

By analogy with the openssl utility in the OpenSSL project, the GnuTLS project has a certtool utility, which in terms of its functionality is not inferior to the openssl utility.

It is about this utility and its capabilities that will be discussed.

General information about the certtool utility

As noted, the certtool utility has a lot in common with the openssl utility.

The first parameter of the certtool utility, as a rule, is a flag that determines which function should be performed. For example, the "--certificate-info" flag indicates that it is necessary to parse the certificate, and the "--generate-privkey" flag instructs to generate a private key. Input data, which are PKI objects (keys, certificates, certificate revocation lists, etc.) required for command execution, are entered as ASN1 structures in PEM (base64) or DER format. The default is PEM format.

If the data will be received in DER format, the "--inder" option must be specified.

The result of executing the corresponding function is an ASN1 structure (the same certificate, for example). By default, the output ASN1 structure is in PEM format. If you need to get it in DER format, add the "--outder" option. Together with the default ASN1 structure (option "--text"), its contents are also displayed in text form. If there is no need to display the text view, then the "--no-text" option is specified.

All this can be demonstrated by the example of converting certificate files from PEM format to DER and vice versa:

#      PEM  DER
#   --outder,   --no-text   .
$certtool --certificate-info --infile certPEM.pem --outder --outfile certDER.der
#      DER  PEM
$certtool --certificate-info --inder --infile certDER.der --no-text  --outfile certPEM_new.pem
$

For help on the certtool utility, run the command:

$ certtool --help

Certtool utility help

certtool - GnuTLS certificate tool
Usage:  certtool [ -<flag> [<val>] | --<name>[{=| }<val>] ]...

   -d, --debug=num            Enable debugging
				- it must be in the range:
				  0 to 9999
   -V, --verbose              More verbose output
				- may appear multiple times
       --infile=file          Input file
				- file must pre-exist
       --outfile=str          Output file

Certificate related options:

   -i, --certificate-info     Print information on the given certificate
       --pubkey-info          Print information on a public key
   -s, --generate-self-signed  Generate a self-signed certificate
   -c, --generate-certificate  Generate a signed certificate
       --generate-proxy       Generates a proxy certificate
   -u, --update-certificate   Update a signed certificate
       --fingerprint          Print the fingerprint of the given certificate
       --key-id               Print the key ID of the given certificate
       --v1                   Generate an X.509 version 1 certificate (with no extensions)
       --sign-params=str      Sign a certificate with a specific signature algorithm

Certificate request related options:

       --crq-info             Print information on the given certificate request
   -q, --generate-request     Generate a PKCS #10 certificate request
				- prohibits the option 'infile'
       --no-crq-extensions    Do not use extensions in certificate requests

PKCS#12 file related options:

       --p12-info             Print information on a PKCS #12 structure
       --p12-name=str         The PKCS #12 friendly name to use
       --to-p12               Generate a PKCS #12 structure

Private key related options:

   -k, --key-info             Print information on a private key
       --p8-info              Print information on a PKCS #8 structure
       --to-rsa               Convert an RSA-PSS key to raw RSA format
   -p, --generate-privkey     Generate a private key
       --key-type=str         Specify the key type to use on key generation
       --bits=num             Specify the number of bits for key generation
       --curve=str            Specify the curve used for EC key generation
       --sec-param=str        Specify the security level [low, legacy, medium, high, ultra]
       --to-p8                Convert a given key to a PKCS #8 structure
   -8, --pkcs8                Use PKCS #8 format for private keys
       --provable             Generate a private key or parameters from a seed using a provable method
       --verify-provable-privkey  Verify a private key generated from a seed using a provable method
       --seed=str             When generating a private key use the given hex-encoded seed

CRL related options:

   -l, --crl-info             Print information on the given CRL structure
       --generate-crl         Generate a CRL
       --verify-crl           Verify a Certificate Revocation List using a trusted list
				- requires the option 'load-ca-certificate'

Certificate verification related options:

   -e, --verify-chain         Verify a PEM encoded certificate chain
       --verify               Verify a PEM encoded certificate (chain) against a trusted set
       --verify-hostname=str  Specify a hostname to be used for certificate chain verification
       --verify-email=str     Specify a email to be used for certificate chain verification
				- prohibits the option 'verify-hostname'
       --verify-purpose=str   Specify a purpose OID to be used for certificate chain verification
       --verify-allow-broken  Allow broken algorithms, such as MD5 for verification
       --verify-profile=str   Specify a security level profile to be used for verification

PKCS#7 structure options:

       --p7-generate          Generate a PKCS #7 structure
       --p7-sign              Signs using a PKCS #7 structure
       --p7-detached-sign     Signs using a detached PKCS #7 structure
       --p7-include-cert      The signer's certificate will be included in the cert list.
				- disabled as '--no-p7-include-cert'
				- enabled by default
       --p7-time              Will include a timestamp in the PKCS #7 structure
				- disabled as '--no-p7-time'
       --p7-show-data         Will show the embedded data in the PKCS #7 structure
				- disabled as '--no-p7-show-data'
       --p7-info              Print information on a PKCS #7 structure
       --p7-verify            Verify the provided PKCS #7 structure
       --smime-to-p7          Convert S/MIME to PKCS #7 structure

Other options:

       --get-dh-params        List the included PKCS #3 encoded Diffie-Hellman parameters
       --dh-info              Print information PKCS #3 encoded Diffie-Hellman parameters
       --load-privkey=str     Loads a private key file
       --load-pubkey=str      Loads a public key file
       --load-request=str     Loads a certificate request file
       --load-certificate=str Loads a certificate file
       --load-ca-privkey=str  Loads the certificate authority's private key file
       --load-ca-certificate=str Loads the certificate authority's certificate file
       --load-crl=str         Loads the provided CRL
       --load-data=str        Loads auxiliary data
       --password=str         Password to use
       --null-password        Enforce a NULL password
       --empty-password       Enforce an empty password
       --hex-numbers          Print big number in an easier format to parse
       --cprint               In certain operations it prints the information in C-friendly format
       --hash=str             Hash algorithm to use for signing
       --salt-size=num        Specify the RSA-PSS key default salt size
       --inder                Use DER format for input certificates, private keys, and DH parameters
				- disabled as '--no-inder'
       --inraw                an alias for the 'inder' option
       --outder               Use DER format for output certificates, private keys, and DH parameters
				- disabled as '--no-outder'
       --outraw               an alias for the 'outder' option
       --template=str         Template file to use for non-interactive operation
       --stdout-info          Print information to stdout instead of stderr
       --ask-pass             Enable interaction for entering password when in batch mode.
       --pkcs-cipher=str      Cipher to use for PKCS #8 and #12 operations
       --provider=str         Specify the PKCS #11 provider library
       --text                 Output textual information before PEM-encoded certificates, private
keys, etc
				- disabled as '--no-text'
				- enabled by default

Version, usage and configuration options:

   -v, --version[=arg]        output version information and exit
   -h, --help                 display extended usage information and exit
   -!, --more-help            extended usage information passed thru pager

Options are specified by doubled hyphens and their name or by a single
hyphen and the flag character.

Tool to parse and generate X.509 certificates, requests and private keys.
It can be used interactively or non interactively by specifying the
template command line option.

The tool accepts files or supported URIs via the --infile option.  In case
PIN is required for URI access you can provide it using the environment
variables GNUTLS_PIN and GNUTLS_SO_PIN.

Please send bug reports to:  <bugs@gnutls.org>

Now let's move on to the main functions of the certtool utility.

Generating and viewing a pair

To generate a private key using the GOST R 34.10 2012 algorithm, the following command is used:

$certtool --generate-privkey --key-type [gost12-256 | gost12-512] --curve < > [--no-text] [--outder] [--outfile <   >]
$

Crypto parameters (--curve) when generating a key pair are set by OIDs. Currently, TK-26 has defined the following oid-s for cryptoparameters of the GOST R 34.10-2012 signature algorithm with a key of 256:

1.2.643.7.1.2.1.1.1 (id-tc26-gost-3410-12-256-paramSetA) [TC26-256-A];

1.2.643.7.1.2.1.1.2 (id-tc26-gost-3410-12-256-paramSetB) [TC26-256-B];

1.2.643.7.1.2.1.1.3 (id-tc26-gost-3410-12-256-paramSetC) [TC26-256-C];

1.2.643.7.1.2.1.1.4 (id-tc26-gost-3410-12-256-paramSetD) [TC26-256-D].

At the same time, the so-called OID parameters from CryptoPro continue to operate:

1.2.643.2.2.35.1 (id-GostR3410-2001-CryptoPro-A-ParamSet) [CryptoPro-A];

1.2.643.2.2.35.2 (d-GostR3410-2001-CryptoPro-B-ParamSet) [CryptoPro-B];

1.2.643.2.2.35.3 (id-GostR3410-2001-CryptoPro-C-ParamSet) [CryptoPro-C];

1.2.643.2.2.36.0 (id-GostR3410-2001-CryptoPro-XchA-ParamSet) [CryptoPro-XchA];

1.2.643.2.2.36.1 (id-GostR3410-2001-CryptoPro-XchB-ParamSet) [CryptoPro-XchB].

Recall that the parameters of CryptoPro with OIDs 1.2.643.2.2.35.1, 1.2.643.2.2.35.2, 1.2.643.2.2.35.3 correspond to the parameters of TC-26 with OIDs 1.2.643.7.1.2.1.1.1 , 1.2.643.7.1.2.1.1.2, 1.2.643.7.1.2.1.1.3 respectively.

With crypto parameters for the signature algorithm GOST R 34.10-2012 with a key 512, it is easier:

1.2.643.7.1.2.1.2.1 (id-tc26-gost-3410-2012-512-paramSetA) [TC26-512-A];

1.2.643.7.1.2.1.2.2 (id-tc26-gost-3410-2012-512-paramSetB) [TC26-512-B];

1.2.643.7.1.2.1.2.3 (id-tc26-gost-3410-2012-512-paramSetC) [TC26-512-C];

GnuTLS has its own notation for crypto parameters and they are indicated in square brackets, for example [TC26-256-B]. Unfortunately, when generating a key, crypto parameters can only be set by their symbolic designation. Dotted OIDs are discarded.

But this is not the biggest drawback. Currently only two crypto parameters are supported in GnuTLS. For keys GOST 34.10-2012-256 (option --key-type gost12-256) this is a parameter with oid 1.2.643.7.1.2.1.1.2 (option --curve TC26-256), and for keys with a length of 512 bits this is a parameter with oid 1.2.643.7.1.2.1.2.1 (option --curve TC26-512-A).

So, create a private key (--generate-privkey flag) and view information about the key (--key-info flag):

#    --key-type gost12-256 --curve TC26-256-B
$certtool --generate-privkey --key-type gost12-256 --curve TC26-256-B --no-text --outder --outfile key256.der
Generating a 256 bit GOST R 34.10-2012-256 private key (TC26-256-B)...
#  
$certtool --key-info --inder --infile key256.der
Public Key Info:
   Public Key Algorithm: GOST R 34.10-2012-256
   Key Security Level: High (256 bits)

curve:   TC26-256-B
digest:  STREEBOG-256
paramset:   TC26-Z
private key:
   4b:df:cb:9e:cc:49:c5:a2:70:36:c9:d8:df:55:97:f5
   8b:be:ae:06:7b:34:76:39:b6:aa:57:af:3f:2d:98:36
x:
   0d:71:29:56:d2:39:59:6f:14:d3:4b:75:44:85:91:a9
   5d:fa:83:4a:93:9a:2c:20:b0:6b:5c:74:8c:76:5f:a5
y:
   2d:ac:da:23:f3:2f:45:d9:47:c4:a3:c1:d7:65:bd:46
   1d:ba:12:cd:15:e1:b0:8f:5a:99:f2:35:ea:fc:33:fc
   
Public Key PIN:
   pin-sha256:nrftlmdCrSf11N+ivohfuGXSQixa4Scnhl7GTsUTE2E=
Public Key ID:
   sha256:9eb7ed966742ad27f5d4dfa2be885fb865d2422c5ae12727865ec64ec5131361
   sha1:25927018f3775ed86996c625a99b7db86b2d0a7e
-----BEGIN PRIVATE KEY-----
MEACAQAwFwYIKoUDBwEBAQEwCwYJKoUDBwECAQECBCIEIDaYLT+vV6q2OXY0ewau
vov1l1Xf2Mk2cKLFScyey99L
-----END PRIVATE KEY-----
$

In the information about the key, we have full information about both the private (closed) key, including its asn1-structure, and the public key, including its value (x and y).

Now let's look at the asn1 structure of the private key. To do this, we will use the cryptoarmpkcs utility :

You will not find the value of the public key in this structure. The public key value is calculated through the private key. But the private key cannot be calculated from the public one, of course !!! Still, it's a shame that the asn1 structure of the public key is not available when viewing the private key (--key-info flag). It would be possible to enter the --pubkey-info option (there is such an option for a certificate), which would display the asn1-structure of the public key.

Of course, the private key must be stored securely, at least encrypted with a password. A PKCS8 container is used to securely store the private key, which provides the ability to encrypt the private key using encryption based on the user's password. Since here we are talking about the use of Russian cryptography and TK-26 recommendations, the command for generating a private key in a secure PKCS8 container will look like:

$certtool --generate-privkey --pkcs8 --pkcs-cipher gost28147-tc26z [--password <>] --key-type [gost12-256 | gost12-512] --curve < > [--no-text] [--outder] [--outfile <   >]
$

If the "--password" option is not specified, then the password for encrypting the private key will be prompted at the command line:

bash-5.1$ ./generate_key_parse_password.sh 
#    --key-type gost12-256 --curve TC26-256-B
$certtool --generate-privkey --pkcs8 --pkcs-cipher gost28147-tc26z --password 01234567  --key-type gost12-256 --curve TC26-256-B --no-text --outder --outfile key256_pkcs8.der
Generating a 256 bit GOST R 34.10-2012-256 private key (TC26-256-B)...
#   
$certtool --key-info --inder --infile key256.der
Encrypted structure detected...
Enter password: < >
PKCS #8 information:
   Cipher: GOST28147-TC26Z-CFB
   Schema: PBES2-GOST28147-89-TC26Z (1.2.643.7.1.2.5.1.1)
   Salt: 32b2798c23a5d0ab8c3144daf273745bdb
   Salt size: 17
   Iteration count: 5333

Public Key Info:
   Public Key Algorithm: GOST R 34.10-2012-256
   Key Security Level: High (256 bits)

curve:   TC26-256-B
digest:  STREEBOG-256
paramset:   TC26-Z
private key:
   05:20:c3:7a:93:a2:e1:b4:64:50:a4:fb:db:cc:74:43
   1a:14:d9:00:c4:82:dc:f5:94:8a:8a:65:a4:76:47:76   
x:
   1b:3e:0b:e0:3b:fc:1d:ee:62:10:63:66:72:fc:66:a6
   d5:b8:94:b1:fe:a4:ec:d6:d8:f1:18:63:95:a9:30:15   
y:
   fb:c0:24:10:41:12:98:7f:aa:15:cd:3b:7e:e7:64:bd
   c4:97:3d:18:04:82:f0:80:61:8e:ff:48:eb:d6:97:d5  
Public Key PIN:
   pin-sha256:eD6s4BQl4R0WY6H8KJZKDA6zuzd6A7JcNCh4FpUH1Rg=
Public Key ID:
   sha256:783eace01425e11d1663a1fc28964a0c0eb3bb377a03b25c342878169507d518
   sha1:62afc2d7c8bf77f1ac0820324170cd2262a63091

-----BEGIN PRIVATE KEY-----
MEACAQAwFwYIKoUDBwEBAQEwCwYJKoUDBwECAQECBCIEIHZHdqRlioqU9dyCxADZ
FBpDdMzb+6RQZLThopN6wyAF
-----END PRIVATE KEY-----
#    openssl  
/usr/local/lirssl_csp_64/bin/lirssl pkcs8 -inform DER -in key256_pkcs8.der  -outform PEM
-----BEGIN PRIVATE KEY-----
MEACAQAwFwYIKoUDBwEBAQEwCwYJKoUDBwECAQECBCIEIHZHdqRlioqU9dyCxADZ
FBpDdMzb+6RQZLThopN6wyAF
-----END PRIVATE KEY-----
bash-5.1$

Create a certificate request

With the private key in place, you can start creating your certificate request.

The --generate-request flag is used to create a request:

certtool --generate-request --load-privkey <   > --template <   > [--no-text]

Let's consider creating a certificate request for an individual. The certificate is planned to be used to generate and verify an electronic signature. In this case, the file with the request template can contain only the distinguished name (DN) of the owner of the certificate, which includes the following types of attributes / oids and their values:

# - oid=2.5.4.6
#country = RU
# 
dn_oid = "2.5.4.6 RU"
# - 2.5.4.8
state = "50  "
# 
#dn_oid = "2.5.4.6 RU"
#,  - 2.5.4.7
locality = ". "
# - 2.5.4.9
#street = "  ,    "
# 
#dn_oid = "2.5.4.9   ,    "
# - 2.5.4.10
#organization = "  "
# surname 2.5.4.4
#sn = ""
dn_oid = "2.5.4.4 "
#,  givenname - 2.5.4.42
#ginenName = " "
dn_oid = "2.5.4.42  "
#  commonName - 2.5.4.3
cn = " "

As you can see from the template, the attributes for the DN (distinguished name) can be specified using either the symbolic name of the attribute accepted in GnuTLS (for example, country = RU), or using the oid of the attribute:

dn_oid = "<oid > < >"

...

In this case, you can specify the country like this:

dn_oid = "2.5.4.6 RU"

If we want the distinguished name in the request to take into account the "Requirements for the form of the qualified certificate of the electronic signature verification key" , then we will have to add TIN and SNILS to it , if we are talking about an individual:

#   - /INN
dn_oid = "1.2.643.3.131.1.1  123456789012"
#     - /SNILS
dn_oid = "1.2.643.100.3 12345678901"

So let's say the private key is stored in the privkey.pem file and the template is in the templateP10.txt file. Then the request can be generated and viewed with the following command:

$certtool --generate-request --load-privkey privkey.pem --template templateP10.txt
Generating a PKCS #10 certificate request...
PKCS #10 Certificate Request Information:
   Version: 1
   Subject: EMAIL=gnutls@aa.ru,SNILS=12345678909,INN=123456789098,givenName=  ,surName=,street=  \,    ,C=RU,ST= ,L=. ,CN= 
   Subject Public Key Algorithm: GOST R 34.10-2012-256
   Algorithm Security Level: High (256 bits)
      Curve:   TC26-256-B
      Digest:  STREEBOG-256
      ParamSet: TC26-Z
      X:
         23:63:5c:72:6f:ac:bb:76:59:a6:65:d0:45:9b:29:ad
         3c:87:59:15:52:21:e2:91:5c:ca:da:16:3e:b9:f7:fa
      Y:
         4d:84:a0:79:a4:02:d4:20:b4:01:e6:4c:9b:da:5e:6a
         4a:cd:b4:7e:c0:01:7e:8d:29:0c:f4:a6:d7:b3:07:a0
   Signature Algorithm: GOSTR341012-256
   Attributes:
      Extensions:
         Subject Signing Tool(not critical):
            GnuTLS
         Basic Constraints (critical):
            Certificate Authority (CA): FALSE
         Key Usage (critical):
            Digital signature.
Other Information:
   Public Key ID:
      sha1:c0e53bf1cc35f14dce4b7e05ee091c90f497dadf
      sha256:eb3dc1375ea60f165b51a9349b32a1a4eab1614e5d49fd02bdf66785095984ea
   Public Key PIN:
      pin-sha256:6z3BN16mDxZbUak0mzKhpOqxYU5dSf0CvfZnhQlZhOo=

Self signature: verified

-----BEGIN NEW CERTIFICATE REQUEST-----
MIICajCCAhcCAQAwggFrMSQwIgYDVQQDDBvQqNGD0YDQsCDQkdCw0LvQsNCz0LDQ
vdC+0LIxHTAbBgNVBAcMFNCzLiDQmtC+0LfQtdC70YzRgdC6MSwwKgYDVQQIDCPQ
nNC+0YHQutC+0LLRgdC60LDRjyDQvtCx0LvQsNGB0YLRjDELMAkGA1UEBhMCUlUx
SDBGBgNVBAkMP9CS0L7RgiDQvNC+0Y8g0LTQtdGA0LXQstC90Y8sINCy0L7RgiDQ
vNC+0Lkg0LTQvtC8INGA0L7QtNC90L7QuTEbMBkGA1UEBAwS0JHQsNC70LDQs9Cw
0L3QvtCyMTEwLwYDVQQqDCjRgdGL0L0g0LvQtdC50YLQtdC90LDQvdGC0LAg0KjQ
vNC40LTRgtCwMRowGAYIKoUDA4EDAQESDDEyMzQ1Njc4OTA5ODEWMBQGBSqFA2QD
EgsxMjM0NTY3ODkwOTEbMBkGCSqGSIb3DQEJARYMZ251dGxzQGFhLnJ1MF4wFwYI
KoUDBwEBAQEwCwYJKoUDBwECAQECA0MABED697k+FtrKXJHiIVIVWYc8rSmbRdBl
pll2u6xvclxjI6AHs9em9AwpjX4BwH60zUpqXtqbTOYBtCDUAqR5oIRNoEMwQQYJ
KoZIhvcNAQkOMTQwMjARBgUqhQNkbwQIDAZHbnVUTFMwDAYDVR0TAQH/BAIwADAP
BgNVHQ8BAf8EBQMDB4AAMAoGCCqFAwcBAQMCA0EARPHu9P2dPb2GrhQTeOBkmbA0
Fw5I0HDF1S5YI7g0jJmdz70rv80XpozmkNKpARN9yYQx9t82fUXUGqwJK9A4RA==
-----END NEW CERTIFICATE REQUEST-----

$

Let's save the request for a certificate in the file request.pem, and go with it to the CA for a certificate.

For the sake of fairness, it should be noted that the certtool utility has great capabilities for generating not only requests for a certificate, but also the certificates themselves. These capabilities are in no way inferior to the capabilities of either openssl or nss.

Obtaining, Viewing and Verifying Certificates

To issue a certificate, we will still use the CAFL63 utility :

Suppose the issued certificate is stored in the certfromreq.pem file. Together with the certificate, users, as a rule, receive a certificate from the certification authority itself, i.e. certificate, the private key of which signed the received certificate. The presence of the CA certificate allows you to check the user certificate:

$certtool --verify --verify-profile normal   [--inder] --load-ca-certificate <   > --infile <   >

For example, if there is a user certificate saved in the certfromreq.pem file, and the CA certificate in the rootca_12_256_TC26.pem file, then to check it, just run the following command:

bash-5.1$ certtool --verify --verify-profile normal  --load-ca-certificate rootca_12_256_TC26.pem  --infile certfromreq.pem 
Loaded CAs (1 available)
        Subject: EMAIL=gnutls@aa.ru,SNILS=12345678909,INN=123456789098,givenName=  ,surName=,street=  \,    ,C=RU,ST= ,L=. ,CN= 
        Issuer: EMAIL=cafl63@mail.ru,OGRN=1234567890123,INN=001234567890,CN=  CAFL63,OU= ,O=  CAFL63,street=. \, . 4,L=. ,ST= ,C=RU
        Checked against: EMAIL=cafl63@mail.ru,OGRN=1234567890123,INN=001234567890,CN=  CAFL63,OU= ,O=  CAFL63,street=. \, . 4,L=. ,ST= ,C=RU
        Signature algorithm: GOSTR341012-256
        Output: Verified. The certificate is trusted. 

Chain verification output: Verified. The certificate is trusted. 

bash-5.1$

To view the received certificate, you need to use the --certificate-info flag:

bash-5.1$ certtool --certificate-info --infile CertFromReqGnuTLS_2.pem

X.509 Certificate Information:


   Version: 3
   Serial Number (hex): 1022
   Issuer: EMAIL=cafl63@mail.ru,OGRN=1234567890123,INN=001234567890,CN=  CAFL63,OU= ,O=  CAFL63,street=. \, . 4,L=. ,ST= ,C=RU
   Validity:
      Not Before: Tue Apr 27 11:50:00 UTC 2021
      Not After: Thu Apr 28 11:50:00 UTC 2022
   Subject: EMAIL=gnutls@aa.ru,SNILS=12345678909,INN=123456789098,givenName=  ,surName=,street=  \,    ,C=RU,ST= ,L=. ,CN= 
   Subject Public Key Algorithm: GOST R 34.10-2012-256
   Algorithm Security Level: High (256 bits)
      Curve:   TC26-256-B
      Digest:  STREEBOG-256
      ParamSet: TC26-Z
      X:
         23:63:5c:72:6f:ac:bb:76:59:a6:65:d0:45:9b:29:ad
         3c:87:59:15:52:21:e2:91:5c:ca:da:16:3e:b9:f7:fa
      Y:
         4d:84:a0:79:a4:02:d4:20:b4:01:e6:4c:9b:da:5e:6a
         4a:cd:b4:7e:c0:01:7e:8d:29:0c:f4:a6:d7:b3:07:a0
   Extensions:
      Basic Constraints (critical):
         Certificate Authority (CA): FALSE
      Issuer Signing Tool(not critical):
         SignTool:  -CSP
         CATool:   CAFL63
         SignToolCert: № -124/3917   29  2020 .
         CAToolCert:   №
      Subject Signing Tool(not critical):
         GnuTLS
      Certificate Policies (not critical):
         1.2.643.100.113.1 (Russian security class KC1)
         1.2.643.100.113.2 (Russian security class KC2)
      Key Usage (not critical):
         Digital signature.
      Key Purpose (not critical):
         1.2.643.6.3.1.2.2
         TLS WWW Client.
         Email protection.
         1.3.6.1.4.1.311.20.2.2
         1.2.643.5.1.28.2
         1.2.643.5.1.28.3
         TLS WWW Client.
         Email protection.
      Subject Key Identifier (not critical):
         ddc80c1857a797dd540b70825e251c2180f585d5
      Authority Key Identifier (not critical):
         directoryName: EMAIL=cafl63@mail.ru,OGRN=1234567890123,INN=001234567890,CN=  CAFL63,OU= ,O=  CAFL63,street=. \, . 4,L=. ,ST= ,C=RU
         serial: 00c79588557040f04e
         70c016b99db59d8466316ea4a51ee0d1026b5cfe
      Subject Alternative Name (not critical):
         RFC822Name: gnutls@aa.ru
      Issuer Alternative Name (not critical):
      Authority Information Access (not critical):
         Access Method: 1.3.6.1.5.5.7.48.2 (id-ad-caIssuers)
         Access Location URI: http://museum.lissi-crypto.ru/docs/ucfz_63/CAFL63.crt
   Signature Algorithm: GOSTR341012-256
   Signature:
      0b:51:a3:d9:77:9f:9e:7d:91:e0:d8:4d:d9:82:a9:71
      91:be:82:ee:5a:6c:c6:79:af:34:1d:30:69:d1:ae:4f
      a5:79:18:6d:46:08:8c:44:65:6f:2c:24:74:8c:09:7f
      30:52:dc:65:9c:f9:b6:46:81:14:a9:83:2a:c0:80:d3
Other Information:
   Fingerprint:
      sha1:d53b007e3d1c3880cb7f92b7e29263cf9c5605c3
      sha256:14bbeeeaeb4219147048dae551eceb2e62de5d00571c6c0ee862161ca2260755
   Public Key ID:
      sha1:c0e53bf1cc35f14dce4b7e05ee091c90f497dadf
      sha256:eb3dc1375ea60f165b51a9349b32a1a4eab1614e5d49fd02bdf66785095984ea
   Public Key PIN:
      pin-sha256:6z3BN16mDxZbUak0mzKhpOqxYU5dSf0CvfZnhQlZhOo=

-----BEGIN CERTIFICATE-----
MIIHXTCCBwigAwIBAgICECIwDAYIKoUDBwEBAwIFADCCAVsxCzAJBgNVBAYTAlJV
MSwwKgYDVQQIDCPQnNC+0YHQutC+0LLRgdC60LDRjyDQvtCx0LvQsNGB0YLRjDEf
MB0GA1UEBwwW0LMuINCu0LHQuNC70LXQudC90YvQuTEoMCYGA1UECQwf0YPQuy4g
0JvQtdC90LjQvdGB0LrQsNGPLCDQtC4gNDElMCMGA1UECgwc0KLQtdGB0YLQvtCy
0YvQuSDQo9CmIENBRkw2MzEwMC4GA1UECwwn0KPQtNC+0YHRgtC+0LLQtdGA0Y/R
jtGI0LjQuSDQptC10L3RgtGAMSUwIwYDVQQDDBzQotC10YHRgtC+0LLRi9C5INCj
0KYgQ0FGTDYzMRowGAYIKoUDA4EDAQESDDAwMTIzNDU2Nzg5MDEYMBYGBSqFA2QB
Eg0xMjM0NTY3ODkwMTIzMR0wGwYJKoZIhvcNAQkBFg5jYWZsNjNAbWFpbC5ydTAe
Fw0yMTA0MjcxMTUwMDBaFw0yMjA0MjgxMTUwMDBaMIIBazEkMCIGA1UEAwwb0KjR
g9GA0LAg0JHQsNC70LDQs9Cw0L3QvtCyMR0wGwYDVQQHDBTQsy4g0JrQvtC30LXQ
u9GM0YHQujEsMCoGA1UECAwj0JzQvtGB0LrQvtCy0YHQutCw0Y8g0L7QsdC70LDR
gdGC0YwxCzAJBgNVBAYTAlJVMUgwRgYDVQQJDD/QktC+0YIg0LzQvtGPINC00LXR
gNC10LLQvdGPLCDQstC+0YIg0LzQvtC5INC00L7QvCDRgNC+0LTQvdC+0LkxGzAZ
BgNVBAQMEtCR0LDQu9Cw0LPQsNC90L7QsjExMC8GA1UEKgwo0YHRi9C9INC70LXQ
udGC0LXQvdCw0L3RgtCwINCo0LzQuNC00YLQsDEaMBgGCCqFAwOBAwEBEgwxMjM0
NTY3ODkwOTgxFjAUBgUqhQNkAxILMTIzNDU2Nzg5MDkxGzAZBgkqhkiG9w0BCQEW
DGdudXRsc0BhYS5ydTBeMBcGCCqFAwcBAQEBMAsGCSqFAwcBAgEBAgNDAARA+ve5
PhbaylyR4iFSFVmHPK0pm0XQZaZZdrusb3JcYyOgB7PXpvQMKY1+AcB+tM1Kal7a
m0zmAbQg1AKkeaCETaOCA58wggObMAwGA1UdEwEB/wQCMAAwgZsGBSqFA2RwBIGR
MIGODBnQodCa0JfQmCDQm9CY0KDQodCh0JstQ1NQDBzQotC10YHRgtC+0LLRi9C5
INCj0KYgQ0FGTDYzDDTihJYg0KHQpC0xMjQvMzkxNyAg0L7RgiAyOSDRgdC10L3R
gtGP0LHRgNGPIDIwMjAg0LMuDB3QodC10YDRgtC40YTQuNC60LDRgiDQo9CmIOKE
ljAkBgUqhQNkbwQbDBnQodCa0JfQmCDQm9CY0KDQodCh0JstQ1NQMB0GA1UdIAQW
MBQwCAYGKoUDZHEBMAgGBiqFA2RxAjALBgNVHQ8EBAMCA6gwEQYJYIZIAYb4QgEB
BAQDAgWgMFkGA1UdJQRSMFAGCCqFAwYDAQICBggrBgEFBQcDAgYIKwYBBQUHAwQG
CisGAQQBgjcUAgIGByqFAwUBHAIGByqFAwUBHAMGCCsGAQUFBwMCBggrBgEFBQcD
BDAdBgNVHQ4EFgQU3cgMGFenl91UC3CCXiUcIYD1hdUwggGVBgNVHSMEggGMMIIB
iIAUcMAWuZ21nYRmMW6kpR7g0QJrXP6hggFjpIIBXzCCAVsxCzAJBgNVBAYTAlJV
MSwwKgYDVQQIDCPQnNC+0YHQutC+0LLRgdC60LDRjyDQvtCx0LvQsNGB0YLRjDEf
MB0GA1UEBwwW0LMuINCu0LHQuNC70LXQudC90YvQuTEoMCYGA1UECQwf0YPQuy4g
0JvQtdC90LjQvdGB0LrQsNGPLCDQtC4gNDElMCMGA1UECgwc0KLQtdGB0YLQvtCy
0YvQuSDQo9CmIENBRkw2MzEwMC4GA1UECwwn0KPQtNC+0YHRgtC+0LLQtdGA0Y/R
jtGI0LjQuSDQptC10L3RgtGAMSUwIwYDVQQDDBzQotC10YHRgtC+0LLRi9C5INCj
0KYgQ0FGTDYzMRowGAYIKoUDA4EDAQESDDAwMTIzNDU2Nzg5MDEYMBYGBSqFA2QB
Eg0xMjM0NTY3ODkwMTIzMR0wGwYJKoZIhvcNAQkBFg5jYWZsNjNAbWFpbC5ydYIJ
AMeViFVwQPBOMBcGA1UdEQQQMA6BDGdudXRsc0BhYS5ydTAJBgNVHRIEAjAAMFEG
CCsGAQUFBwEBBEUwQzBBBggrBgEFBQcwAoY1aHR0cDovL211c2V1bS5saXNzaS1j
cnlwdG8ucnUvZG9jcy91Y2Z6XzYzL0NBRkw2My5jcnQwDAYIKoUDBwEBAwIFAANB
AAtRo9l3n559keDYTdmCqXGRvoLuWmzGea80HTBp0a5PpXkYbUYIjERlbywkdIwJ
fzBS3GWc+bZGgRSpgyrAgNM=
-----END CERTIFICATE-----

bash-5.1$

And if instead of the --certificate-info flag we specify the --pubkey - info flag, then we will receive not only information about the public key, but also its asn1 structure:

bash-5.1$ certtool --pubkey-info  --infile CertFromReqGnuTLS_2.pem |expand -3
Public Key Information:
   Public Key Algorithm: GOST R 34.10-2012-256
   Algorithm Security Level: High (256 bits)
      Curve:   TC26-256-B
      Digest:  STREEBOG-256
      ParamSet: TC26-Z
      X:
         23:63:5c:72:6f:ac:bb:76:59:a6:65:d0:45:9b:29:ad
         3c:87:59:15:52:21:e2:91:5c:ca:da:16:3e:b9:f7:fa
      Y:
         4d:84:a0:79:a4:02:d4:20:b4:01:e6:4c:9b:da:5e:6a
         4a:cd:b4:7e:c0:01:7e:8d:29:0c:f4:a6:d7:b3:07:a0
Public Key Usage:
   Digital signature.
   Key encipherment.
   Key agreement.
Public Key ID:
   sha1:c0e53bf1cc35f14dce4b7e05ee091c90f497dadf
   sha256:eb3dc1375ea60f165b51a9349b32a1a4eab1614e5d49fd02bdf66785095984ea
Public Key PIN:
   pin-sha256:6z3BN16mDxZbUak0mzKhpOqxYU5dSf0CvfZnhQlZhOo=
#ASN1-    PEM-
-----BEGIN PUBLIC KEY-----
MF4wFwYIKoUDBwEBAQEwCwYJKoUDBwECAQECA0MABED697k+FtrKXJHiIVIVWYc8
rSmbRdBlpll2u6xvclxjI6AHs9em9AwpjX4BwH60zUpqXtqbTOYBtCDUAqR5oIRN
-----END PUBLIC KEY-----
bash-5.1$

Now that you have a certificate and its private key, as well as a CA certificate, you can put them all together in one secure PKCS # 12 container.

Working with a secure PKCS # 12 container

Working with Russian cryptography, when creating a secure PKCS # 12 container, of course, be guided by the TK-26 Recommendations describing the formation of transport key containers for keys created in accordance with GOST R 34.10.

Based on this, the command to create a PKCS # 12 container would look like this:

certtool --to-p12  --pkcs-cipher=gost28147-tc26z --hash streebog-512 [--inder] [--ask-pass | --password <  >]  [--p12-name "<friendly name>"]  --load-certificate <  > --load-privkey <    >  --load-ca-certificate <   > [--outder] [--outfile <   >]

Note that if the --password and / or --p12-name options are not specified, they will be prompted on the command line.

Let's create a PKCS # 12 container:

$ certtool --to-p12  --pkcs-cipher=gost28147-tc26z --hash streebog-512  --load-certificate certUser.pem  --load-privkey privkeyUser.pem  --load-ca-certificate certCA.pem --p12-name "TectP12GnuTLS" --password "01234567"        
Generating a PKCS #12 structure...
Loading private key list...
Loaded 1 private keys.

PKCS # 12 container in PEM format

bash-5.1$

It should be noted that today the PKCS # 12 secure container is popular.

The PKCS # 12 container created by the certtool utility has been successfully parsed by the openssl utility with GOST support. After that, we decided to use the cryptoarmpkcs utility , which allows you to extract the certificate and its private key from the PKCS # 12 container and install them on the PKCS # 11 token, as well as, using the container itself, sign documents.

And then I had to face an unpleasant surprise: The

surprise is that, when creating a PKCS # 12 container, GnuTLS does not take into account the latest requirements of TK-26, which read:

The integrity of the TCC is ensured using the HMAC_GOSTR3411_2012_512 algorithm in accordance with R 50.1.113— 2016.

The certtool utility uses the HMAC_GOSTR3411_2012_256 algorithm, which is hardcoded into the library code. But this is an easily fixable bug. To do this, it is enough to change the line in the _gnutls_pkcs_generate_key function (file ~ / gnutls-xxx / lib / x509 / pkcs7-crypt.c)

kdf_param->mac = GNUTLS_MAC_STREEBOG_256;

per line

kdf_param->mac = GNUTLS_MAC_STREEBOG_512;

After making this change, everything fell into place and the PKCS # 12 container from GnuTLS was adopted by the cryptoarmpkcs utility:

The above example of a PKCS # 12 container (----- BEGIN PKCS12 ----- ... ----- END PKCS12- ----) was formed taking into account the requirements of TC-26.

So, having a PKCS # 12 container and the cryptoarmpkcs utility, you can generate various types of signatures for documents (see screenshot). But we are now interested in the formation of an electronic signature using the certtool utility.

PKCS # 7 electronic signature

The command for generating an electronic signature looks like this:

$certtool --p7-sign [--p7-time] [--inder] --load-privkey <   > --load-certificate <  > --infile <  > [--outder] [--outfile <  >]

Explanation is required only for the --p7-time option, the presence of which prescribes to include in the signature itself (PKCS # 7 structure) the time of generation of the electronic signature.

By the way, to test the formation of an electronic signature, the certificate and its private key can be taken from the PKCS # 12 container given in the previous section:

$certtool --p12-info --no-text --infile <,     PKCS#12>

If the user's private key certificate was saved in the privkey.pem file, and the user certificate in the usercert.pem file, then signing the document from the doc.txt file with the signature saved in the signdoc.sig file will look like this:

$certtool --p7-sign --loadcertificate usercert.pem --load-privkey privkey.pem --infile doc.txt --outfile signdoc.sig
Enter password
$

If the signature is attached (and by default it is it that is created), then you can extract the signed document with the following command:

$certtool --p7-info --p7-show-data [--inder] --infile <  >

To view information about an electronic signature, use the --p7-info flag:

$certtool --p7-info [--inder]

To verify the electronic signature itself, a signatory certificate is required:

$certtool --p7-verify [--inder] --load-certificate <   > --infile <   >

Yes, the --p7-detached-sign option is used to generate a detached signature

Afterword

I did not intend to give a complete description of the certtool utility, much less write GnuTLS documentation. The authors did it well without me.

The goal was to show that there is such a tool as GnuTLS and it can be used along with OpenSSL or GCrypt to work with PKI based on Russian cryptography. How much this was possible is for the reader to judge.

Public Key Infrastructure Based on Russian Cryptography: GnuTLS as an Alternative to OpenSSL