🍆 🧗🏽 🎢 Infrastructure à clé publique basée sur la cryptographie russe: GnuTLS comme alternative à OpenSSL 👗 🌼 🧑🏽

L'infrastructure à clé publique ( PKI / PKI ) comprend de nombreux objets et mécanismes différents pour travailler avec eux, ainsi que des protocoles d'interaction d'objets entre eux (par exemple, TLS, OCSP). Les objets PKI incluent les demandes de certificats (PKCS # 10) et les certificats x509 eux-mêmes, les paires de clés (clés privées et publiques), les documents signés et chiffrés (PKCS # 7, CMS), les conteneurs sécurisés pour le stockage des clés privées (PKCS # 8) et certificats personnels avec clés (PKCS # 12), etc. Les mécanismes incluent non seulement des fonctions cryptographiques qui vous permettent de crypter et de signer des documents à l'aide de divers algorithmes, mais également des fonctions qui forment les objets PKI finaux. conformément aux normes (certificats, demandes, documents signés / chiffrés, packages de protocoles, etc., etc.). Oui, et comment ne pas rappeler l'objet central de la CEI / PKI - CA .

Aujourd'hui, il est difficile d'imaginer une vie commerciale du pays sans PKI , sans certificat x509 (sans certificats qualifiés), sans les services des services publics et le Service fédéral des impôts, où les documents sont acceptés sous forme électronique avec une signature électronique. Et de plus en plus de documents sont retournés au citoyen également sous forme électronique avec une signature électronique. Il n'est plus possible de présenter une procédure judiciaire sans signature électronique.

L'outil le plus avancé pour créer des outils logiciels fonctionnant avec des objets PKI est OpenSSL.

OpenSSL est un ensemble de bibliothèques et d'utilitaires cryptographiques open source complets qui prennent en charge presque tous les algorithmes de hachage de bas niveau, de cryptage et de signature numérique, et implémentent la plupart des normes cryptographiques populaires. Cependant, ces normes cryptographiques n'incluent pas la cryptographie russe. Pour un travail complet avec la cryptographie russe dans OpenSSL, il est nécessaire de connecter en plus le moteur gost .

Nous avons déjà écrit que la bibliothèque gcrypt peut être une alternative à openssl .... Et maintenant, la prise en charge de la cryptographie et des mécanismes cryptographiques russes a été implémentée dans le projet GnuTLS . GnuTLS prend en charge à la fois les anciens algorithmes cryptographiques et les nouveaux - GOST R 34.10-2012 (signature électronique), GOST R 34.11-2012 (hachage), GOST R 34.12-2015 et GOST R 34.13-2015 (algorithmes de cryptage Grasshopper et Magma).

Par analogie avec l'utilitaire openssl du projet OpenSSL, le projet GnuTLS a un utilitaire certtool, qui en termes de fonctionnalités n'est pas inférieur à l'utilitaire openssl.

C'est à propos de cet utilitaire et de ses capacités qui seront discutés.

Informations générales sur l'utilitaire certtool

Comme indiqué, l'utilitaire certtool a beaucoup en commun avec l'utilitaire openssl.

En règle générale, le premier paramètre de l'utilitaire certtool est un indicateur qui détermine la fonction à exécuter. Par exemple, l'indicateur «--certificate-info» indique qu'il est nécessaire d'analyser le certificat et l'indicateur «--generate-privkey» indique de générer une clé privée. Les données d'entrée, qui sont des objets PKI (clés, certificats, listes de révocation de certificats, etc.) nécessaires à l'exécution de la commande, sont saisies sous forme de structures ASN1 au format PEM (base64) ou DER. La valeur par défaut est le format PEM.

Si les données sont reçues au format DER, alors l'option "--inder" doit être spécifiée.

Le résultat de l'exécution de la fonction correspondante est une structure ASN1 (le même certificat, par exemple). Par défaut, la structure ASN1 de sortie est au format PEM. Si vous avez besoin de l'obtenir au format DER, ajoutez l'option "--outder". Avec la structure ASN1 par défaut (option "--text"), son contenu est également affiché sous forme de texte. S'il n'est pas nécessaire d'afficher la vue texte, l'option "--no-text" est spécifiée.

Tout cela peut être démontré par l'exemple de la conversion de fichiers de certificat du format PEM au format DER et 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
$

Pour obtenir de l'aide sur l'utilitaire certtool, exécutez la commande:

$ certtool --help

Aide de l'utilitaire Certtool

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>

Passons maintenant aux principales fonctions de l'utilitaire certtool.

Générer et afficher une paire

Pour générer une clé privée à l'aide de l'algorithme GOST R 34.10 2012, la commande suivante est utilisée:

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

Les paramètres cryptographiques (--curve) lors de la génération d'une paire de clés sont définis par les OID. Actuellement, TK-26 a défini les oid-s suivants pour les cryptoparamètres de l'algorithme de signature GOST R 34.10-2012 avec une clé de 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].

Dans le même temps, les paramètres dits OID de CryptoPro continuent à fonctionner:

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].

Rappelons que les paramètres de CryptoPro avec les OID 1.2.643.2.2.35.1, 1.2.643.2.2.35.2, 1.2.643.2.2.35.3 correspondent aux paramètres du TC-26 avec les OID 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 respectivement.

Avec les paramètres cryptographiques pour l'algorithme de signature GOST R 34.10-2012 avec une clé 512, c'est plus simple:

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 a sa propre notation pour les paramètres cryptographiques et ils sont indiqués entre crochets, par exemple [TC26-256-B]. Malheureusement, lors de la génération d'une clé, les paramètres cryptographiques ne peuvent être définis que par leur désignation symbolique. Les OID pointés sont ignorés.

Mais ce n'est pas le plus gros inconvénient. Actuellement, seuls deux paramètres cryptographiques sont pris en charge dans GnuTLS. Pour les clés GOST 34.10-2012-256 (option --key-type gost12-256) c'est un paramètre avec oid 1.2.643.7.1.2.1.1.2 (option --curve TC26-256), et pour les clés avec une longueur de 512 bits c'est un paramètre avec oid 1.2.643.7.1.2.1.2.1 (option --curve TC26-512-A).

Alors, créez une clé privée (indicateur --generate-privkey) et affichez les informations sur la clé (indicateur --key-info):

#    --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-----
$

Dans les informations sur la clé, nous avons des informations complètes sur la clé privée (fermée), y compris sa structure asn1, et la clé publique, y compris sa valeur (x et y).

Regardons maintenant la structure de la clé privée asn1. Pour ce faire, nous utiliserons l'utilitaire cryptoarmpkcs :

Vous ne trouverez pas la valeur de la clé publique dans cette structure. La valeur de la clé publique est calculée via la clé privée. Mais la clé privée ne peut pas être calculée à partir de la clé publique, bien sûr !!! Pourtant, il est dommage que la structure asn1 de la clé publique ne soit pas disponible lors de l'affichage de la clé privée (indicateur --key-info). Il serait possible d'entrer l'option --pubkey-info (il existe une telle option pour le certificat), qui afficherait la structure asn1 de la clé publique.

Bien entendu, la clé privée doit être stockée de manière sécurisée, au moins cryptée avec un mot de passe. Un conteneur PKCS8 est utilisé pour stocker en toute sécurité la clé privée, ce qui permet de chiffrer la clé privée à l'aide du chiffrement basé sur le mot de passe de l'utilisateur. Puisque nous parlons ici de l'utilisation de la cryptographie russe et des recommandations TK-26, la commande de génération d'une clé privée dans un conteneur PKCS8 sécurisé ressemblera à:

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

Si l'option "--password" n'est pas spécifiée, le mot de passe pour le chiffrement de la clé privée sera demandé sur la ligne de commande:

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$

Créer une demande de certificat

Une fois la clé privée en place, vous pouvez commencer à créer votre demande de certificat.

L'indicateur --generate-request est utilisé pour créer une requête:

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

Considérons la création d'une demande de certificat pour un individu. Le certificat devrait être utilisé pour générer et vérifier une signature électronique. Dans ce cas, le fichier avec le modèle de demande ne peut contenir que le nom distinctif (DN) du propriétaire du certificat, qui comprend les types d'attributs / oids suivants et leurs valeurs:

# - 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 = " "

Comme vous pouvez le voir sur le modèle, les attributs d'un DN (nom distinctif) peuvent être spécifiés en utilisant soit le nom symbolique de l'attribut accepté dans GnuTLS (par exemple, country = RU), soit en utilisant l'oid de l'attribut:

dn_oid = "<oid > < >"

...

Dans ce cas, vous pouvez spécifier le pays comme ceci:

dn_oid = "2.5.4.6 RU"

Si nous voulons que le nom distinctif dans la demande prenne en compte les «Exigences pour le formulaire du certificat qualifié de la clé de vérification de signature électronique» , alors nous devrons y ajouter TIN et SNILS , si nous parlons d'un individu :

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

Supposons que la clé privée soit stockée dans le fichier privkey.pem et que le modèle se trouve dans le fichier templateP10.txt. Ensuite, la demande peut être générée et affichée avec la commande suivante:

$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-----

$

Sauvegardons la demande de certificat dans le fichier request.pem et accompagnons-la auprès de l'autorité de certification pour obtenir un certificat.

Par souci d'équité, il convient de noter que l'utilitaire certtool a de grandes capacités pour générer non seulement des demandes de certificat, mais également les certificats eux-mêmes. Ces capacités ne sont en aucun cas inférieures aux capacités d'openssl ou de nss.

Obtention, affichage et vérification des certificats

Pour émettre un certificat, nous utiliserons toujours l'utilitaire CAFL63 :

Supposons que le certificat émis soit stocké dans le fichier certfromreq.pem. En règle générale, avec le certificat, les utilisateurs reçoivent un certificat de l'autorité de certification elle-même, c'est-à-dire certificat, dont la clé privée a signé le certificat reçu. La présence du certificat CA vous permet de vérifier le certificat utilisateur:

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

Par exemple, s'il existe un certificat utilisateur enregistré dans le fichier certfromreq.pem et le certificat CA dans le fichier rootca_12_256_TC26.pem, alors pour le vérifier, exécutez simplement la commande suivante:

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$

Pour afficher le certificat reçu, vous devez utiliser l'indicateur --certificate-info:

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

Informations sur le certificat X.509:


   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$

Et si au lieu de l'indicateur --certificate-info nous spécifions l'indicateur --pubkey - info, nous recevrons non seulement des informations sur la clé publique, mais aussi sa structure asn1:

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$

Maintenant que vous disposez du certificat et de sa clé privée, ainsi que du certificat CA, vous pouvez tous les rassembler dans un conteneur PKCS # 12 sécurisé.

Travailler avec un conteneur PKCS # 12 sécurisé

En travaillant avec la cryptographie russe, lors de la création d'un conteneur PKCS # 12 sécurisé, bien sûr, soyez guidé par les recommandations TK-26 , qui décrivent la formation de conteneurs de clés de transport pour les clés créées conformément à GOST R 34.10.

Sur cette base, la commande pour créer un conteneur PKCS # 12 ressemblerait à ceci:

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 <   >]

Notez que si les options --password et / ou --p12-name ne sont pas spécifiées, elles seront invitées sur la ligne de commande.

Créons un conteneur PKCS # 12:

$ 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.

Conteneur PKCS # 12 au format PEM

bash-5.1$

Il convient de noter qu'aujourd'hui le conteneur sécurisé PKCS # 12 est populaire.

Le conteneur PKCS # 12 créé par l'utilitaire certtool a été analysé avec succès par l'utilitaire openssl avec prise en charge de GOST. Après cela, nous avons décidé d'utiliser l'utilitaire cryptoarmpkcs , qui vous permet d'extraire le certificat et sa clé privée du conteneur PKCS # 12 et de les installer sur le jeton PKCS # 11, ainsi que, à l'aide du conteneur lui-même, de signer des documents.

Et puis j'ai dû faire face à une mauvaise surprise: la

surprise est que, lors de la création d'un conteneur PKCS # 12, GnuTLS ne prend pas en compte les dernières exigences du TK-26, qui se lisaient:

L'intégrité du TCC est assurée à l'aide de l'algorithme HMAC_GOSTR3411_2012_512 conformément à R 50.1.113-2016.

L'utilitaire certtool utilise l'algorithme HMAC_GOSTR3411_2012_256, qui est codé en dur dans le code de la bibliothèque. Mais c'est un bogue facilement réparable. Pour ce faire, il suffit de changer la ligne dans la fonction _gnutls_pkcs_generate_key (fichier ~ / gnutls-xxx / lib / x509 / pkcs7-crypt.c)

kdf_param->mac = GNUTLS_MAC_STREEBOG_256;

par ligne

kdf_param->mac = GNUTLS_MAC_STREEBOG_512;

Après avoir effectué ce changement, tout s'est mis en place et le conteneur PKCS # 12 de GnuTLS a été adopté par l'utilitaire cryptoarmpkcs:

L'exemple ci-dessus d'un conteneur PKCS # 12 (----- BEGIN PKCS12 ----- ... - ---- END PKCS12- ----) a été créé en tenant compte des exigences du TC-26.

Ainsi, avec un conteneur PKCS # 12 et l'utilitaire cryptoarmpkcs, vous pouvez générer différents types de signatures pour les documents (voir capture d'écran). Mais nous nous intéressons maintenant à la formation d'une signature électronique à l'aide de l'utilitaire certtool.

Signature électronique PKCS # 7

La commande de génération d'une signature électronique ressemble à ceci:

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

Seule l'option --p7-time nécessite une clarification, dont la présence indique d'inclure dans la signature elle-même (structure PKCS # 7) l'heure de génération de la signature électronique.

D'ailleurs, pour tester la formation d'une signature électronique, le certificat et sa clé privée peuvent être extraits du conteneur PKCS # 12 donné dans la section précédente:

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

Si le certificat de clé privée de l'utilisateur a été enregistré dans le fichier privkey.pem et le certificat utilisateur dans le fichier usercert.pem, la signature du document à partir du fichier doc.txt avec la signature enregistrée dans le fichier signdoc.sig ressemblera à ceci :

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

Si la signature est jointe (et par défaut c'est elle qui est créée), vous pouvez extraire le document signé avec la commande suivante:

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

Pour afficher des informations sur une signature électronique, utilisez l'indicateur --p7-info:

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

Pour vérifier la signature électronique elle-même, un certificat de signature est requis:

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

Oui, l'option --p7-détaché-sign est utilisée pour générer une signature détachée

Épilogue

Je n'avais pas l'intention de donner une description complète de l'utilitaire certtool, encore moins d'écrire de la documentation GnuTLS. Les auteurs l'ont bien fait sans moi.

L'objectif était de montrer qu'il existe un outil tel que GnuTLS et qu'il peut être utilisé avec OpenSSL ou GCrypt pour travailler avec PKI basée sur la cryptographie russe. Le lecteur doit juger dans quelle mesure cela était possible.

Infrastructure à clé publique basée sur la cryptographie russe: GnuTLS comme alternative à OpenSSL