The Tale of Cleopatra and Russian Cryptography (Continued)

With the advent of the GCrypt-1.7.0 library with support for Russian cryptography (GOST 28147-89, GOST R 34.11-94 / 2012 and GOST R 34.10-2001 / 2012), it became possible to talk about support for Russian PKI in projects such as Kleopatra and KMail .

KMail is an email client that, to ensure the security of your correspondence, allows you to sign and encrypt messages using the S / MIME protocol. Both are based on the PKI architecture, X509 certificates and CMS / PKCS # 7 protocols:



Kleopatpa is a graphical utility that not only allows you to sign and encrypt files, but also provides for the storage and management of certificates and private keys:
')


Both Kleopatpa and KMail do not have built-in cryptography: all cryptographic transformations for them are made by their suite and, above all, by the gpgsm module from the GnuPg package. Libcrypt library is used for cryptographic calculations. And for parsing X509 certificates, signed or encrypted messages (CMS / PKCS # 7, PKCS # 10, etc.) library libksba is used . We also mention the library libgpgme , but about its role a little later.

And if Kleopatpa itself and her faithful servant KMail have nothing against Russian cryptography, their retinue, with the exception of LibGCrypt , flatly refuses to be friends with it.

Let's start with the most innocent member of the suite, namely libgpgme library. First, let's look at the source code of the signed message:



In the “Content-Type” field there is a variable micalg, which indicates the type of hash used when generating or verifying a signature. For many email clients, including KMail, the lack of a value in this field does not affect the verification of the electronic signature, but not for Thunderbird and Seamonkey. Therefore, it is desirable that this field and KMail be filled. Especially since this will require minimal effort. All that is needed is to add the numbers of Russian hash algorithms to the gpgme.h.in file:

/* Hash algorithms (the values match those from libgcrypt). */ typedef enum { GPGME_MD_NONE = 0, . . . GPGME_MD_CRC24_RFC2440 = 304, /* from gcrypt.h.in !!!!*/ GPGME_MD_GOSTR3411_94 = 308, /* GOST R 34.11-94 */ GPGME_MD_STRIBOG256 = 309, /* GOST R 34.11-2012, 256 bit. */ GPGME_MD_STRIBOG512 = 310, /* GOST R 34.11-2012, 512 bit. */ GPSME_MD_GOSTR3411_CP = 311 , /* GOST R 34.11-94 with CryptoPro-A S-Box. */ } gpgme_hash_algo_t; 

Moreover, these numbers should be strictly correlated with the corresponding numbers from the libgcrypt library file gcrypt.h.in :

 /************************************ * Cryptograhic Hash Functions * ************************************/ /* Algorithm IDs for the hash functions we know about. Not all of them are implemented. */ enum gcry_md_algos { GCRY_MD_NONE = 0, . . GCRY_MD_TIGER2 = 307, /* TIGER2 variant. */ /*  */ GCRY_MD_GOSTR3411_94 = 308, /* GOST R 34.11-94. */ GCRY_MD_STRIBOG256 = 309, /* GOST R 34.11-2012, 256 bit. */ GCRY_MD_STRIBOG512 = 310, /* GOST R 34.11-2012, 512 bit. */ GCRY_MD_GOSTR3411_CP = 311, /* GOST R 34.11-94 with CryptoPro-A S-Box. */ . . . GCRY_MD_SHAKE256 = 317 }; 

That's all, libgpgme library sided with Russian cryptography.

The main refinement was in GnuPg ( gpg-protect-tool module), which is responsible, in particular, for importing personal X509 certificates from a secure PKCS # 12 container, the gpgsm module, which in particular is responsible for generating and parsing certificates, signed and encrypted messages (CMS, PKCS # 7) and his journeyman libksba library.

The rhetorical question is where to get a personal certificate, i.e. X509 certificate and private key? But today there are no questions with this, of course, in the Certification Authority (CA). Today in Russia there are more than one CA registered in the Ministry of Communications and Mass Media alone. However, we must remember that this service is paid! For testing (and even internal corporate protected workflow, including email correspondence) personal certificates in a secure PKCS # 12 container can be obtained using the openssl utility, or on one of the free test CAs . Here you can get a personal certificate right away in the PKCS # 12 container .

To import a personal certificate into Cleopatra’s environment (or rather, in the certificate store and private keys in GnuPg), you must unload the existing personal certificate (export) into the PKCS # 12 container. It may turn out that the container was formed in accordance with the requirements of TC-26 . Currently (we emphasize, at present) GnuPg does not get along with PKCS # 12 containers formed according to the requirements of TC-26, but this is not scary either. Having the openssl utility at hand (or even better the lirssl utility), we quickly get rid of this shortcoming by releasing a new container using a simple script:

 #cat CONVERT_P12_for_GPGSM.sh #   /etc/ssl/openssl.cnf    - engine export OPENSSL_CONF=/etc/ssl/openssl.cnf openssl pkcs12 -in $1.p12 -nodes -out $1.txt.p12 -nomacver openssl pkcs12 -export -in $1.txt.p12 -nodes -out $1\_openssl_cert_key.p12 rm –f $1.txt.p12 echo "    GPGSM: $1\_openssl_cert_key.p12" # #sh CONVERT_P12_for_GPGSM.sh -2001-2016 Enter Import Password: Enter Export Password: Verifying - Enter Export Password:     GPGSM: -2001-2016_openssl_cert_key.p12 # 

Now we have a PKCS # 12 container, which we will import:



After clicking the “Open” button , you will be prompted to enter a password to parse the PKCS # 12 container:



And then you will be prompted to enter and confirm a password that will access the private key of the imported certificate:



All personal certificate imported. Third-party certificates, as well as root certificates, are imported from both the DER format and the PEM format.

Now that Kleopatra owns the certificates, she can sign documents with her personal certificate:



entering the password to access the private key:



Confidential files can now be encrypted using the recipient's certificate:



When creating a CMC / PKCS # 7 with encryption, a VKO GOST R 34.10-2012 algorithm is used to generate a key encryption key (KEK) using the private key corresponding to the originatorKey publicKey key and the recipient's public key. Unfortunately, in the current version of GCrypt there is no implementation of this algorithm. The implementation of this algorithm was borrowed from the LCC-2016 library and added to the ecc-gost.c file .

And so, feel free to press the button "Continue" :



As for the KMail mail client, in order to protect the correspondence (electronic signature, encryption), you first need to choose a personal certificate (a certificate that has a private key) with which you will sign the mail messages, as well as a certificate that will be used in email encryption:



Click the “Launch Certificate Manager” button: Cleopatra will be at your service and you will be able to see in detail the properties of the selected certificate.

Now you can both sign and encrypt email messages:



After clicking “Send”, KMail will ask you to confirm the fact of encryption:



And will ask you to enter a password to access the private key:



But I want more. We are talking about the use of software and hardware tokens PKCS # 11 with the support of the same Russian cryptography. To connect PKCS # 11 tonens, you need to install a modified gnu-pkcs11-scd module into the system, and add the following lines to the gpg-agent.conf configuration file:

 scdaemon-program /usr/local/bin64/gnupg-pkcs11-scd pinentry-program /usr/bin/pinentry-qt 

After that, in the gnu-pkcs11-scd.conf configuration file, specify the PKCS # 11 libraries for the tokens to be used:

 #    -  #LS11USB2016 #  /usr/local/lib64/libls11usb2016.so … # Comma-separated list of available provider names. Then set # attributes for each provider using the provider-[name]-attribute # syntax. providers libls11usb2016 provider-libls11usb2016-library /usr/local/lib64/libls11usb2016.so provider-libls11usb2016-cert-private … 

Make sure that gpg-agent is running:

 $ gpg-agent --daemon --use-standard-socket GPG_AGENT_INFO=/home/a513/.gnupg/S.gpg-agent:19092:1; export GPG_AGENT_INFO; $ 

Now, after starting Kleopatra or KMail, the PIN code for access to the token will be requested:



To check the name of the token, you can use the free utility p11conf :

 $ /usr/local/bin64/p11conf -A /usr/local/lib64/libls11usb2016.so -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 bash-4.3$ 

To view the token import it is enough to run the following command:



After successfully entering the PIN, the entire list of certificates will be received, both from the GnuGPG repository and stored on the connected PKCS # 11 tokens / smart cards:



Moreover, now Russian cryptography in S / MIME can be used to sign and encrypt correspondence by other email clients (for example, Claws, Evolution ), which use the GnuPg / SMIME mechanisms for this:





That's all - Kleopatra and her royal retinue faithfully serve Russian cryptography!

What's next?

And then we hope that in the near future, Kleopatra will also generate PKCS # 10 requests for GOST R 34.10-2001 / 2012:



Which can then be transferred to the Verification Centers and eventually receive certificates.

But it will be another story.