Removing a key from a token with a non-recoverable key

Quite often, when issuing certificates for electronic signature keys, it is possible to observe intrusive PR tokens with an non-recoverable key. Vendors from certifying centers assure that by purchasing a CryptoPRO CSP SKPI from them and a key with a non-recoverable key ( Rutoken EDS or JaCarta GOST ), we will receive certified SKZI providing 100% protection against theft of keys from the token. But is it really? To answer this question, we will conduct a simple experiment ...

Testbed Configuration

Let's assemble a test stand with a configuration typical for machines participating in an electronic document management (EDM):

1. OS MS Windows 7 SP1
2. SKZI CryptoPRO CSP 3.9.8423
3. Rutoken drivers for Windows (x86 and x64). Version: v.4.1.0.0 of 06/20/2016, WHQL-certified
4. JaCarta and JaCarta SecurLogon Single Client. Version 2.9.0 build 1531
5. CryptoARM Standard Plus 5. Version 5.2.0.8847.

For testing, tokens with a non-tracked key will be used:

1. Rutoken EDS. Version 2/19/14/00 (02)
2. JaCarta GOST. Model Number JC001-2.F09 v2.1

Testing method

Let's model the typical process of preparation by the Information Security Administrator of key documents for the organization of the EDM:

1. a private key container and a request for a public key certificate are generated;
2. after passing the certification procedure in the certification authority, the certificate is obtained from the request;
3. The certificate in combination with the container of the private key forms ready-to-use key information. This key information recorded on the media will be called the original key document ;
4. from the original key document , copies are made, which are written to the alienable media (hereinafter we will call them working key documents ) and transferred to the authorized users;
5. after the production of the required number of working key documents, the original key document is destroyed or deposited with the cryptographic protection authority.

In our case, we will not use the services of certification authorities, but generate a key container with a self-signed certificate and place it in the computer registry (AWP for generating key information), this will be the original key document . Then we will copy the key information on Rutoken EDS and JaCarta GOST, having produced working key documents . After that, we will destroy the original key document , deleting the key container from the registry. And finally, let's try to copy key information from working key documents back to the registry.
')

Testing

1. Create the source key document .
2. Form the working key documents .

3. Destroy the original key document.

4. Copy the key information from the working key documents.

As we see, the key information was successfully copied or, in another language, extracted from tokens with an unrecoverable key. It turns out that the manufacturers of tokens and SKZI lie? In fact, no, and the situation is more complicated than it seems at first glance. Investigate materiel by tokens.

Materiel

The fact that the market is called a token with an unrecoverable key, properly called functional key carrier (FKN) ( additional info ).

The main difference between PCFs and ordinary tokens ( Rutoken S , JaCarta PKI , ...) is that when performing cryptographic transformations (for example, generating an electronic signature), the private key does not leave the device. While using regular tokens, the private key is copied from the token to the computer's memory.

The use of PCF requires a special organization of interaction between the applied cryptographic software and the CIPS library (cryptographic provider or, in a different way, CSP).



Here it is important to see that the software part of the SKZI library must know about the existence of an applet on the token that implements cryptographic functionality (for example, key generation, data signature, etc.) and be able to work with it.

Take a fresh look at our test bench

Rutoken EDS was used as one of the key carriers. Through the "Rutoken Control Panel" you can get the following information about it:



The last line contains the phrase “Support for CryptoPRO FKN: No”, which means that there is no applet on the token with which the CryptoPRO CSP can work. Thus, the implementation of PCF technology using SKZI and tokens described in the test bench configuration is impossible.

The situation is similar with JaCarta GOST. Moreover, the CryptoPRO CSP CPSS, at least the version used in the test bench, uses these key carriers as “ordinary tokens”, which, in turn, are just key carriers.

This statement is very simple to confirm. To do this, you need to put the CryptoPRO CSP SKZI on a clean machine without drivers from tokens and connect the JaCarta GOST token. Windows 7 will detect the JaCarta GOST token as "Microsoft Usbccid Smart Card Reader (WUDF)". Now you can try to create a key on the token and copy it to the computer’s registry. All the functionality of SKZI will successfully work.

How to make everything good?

In order to realize the FKN technology with the help of CRIPTO-PRO LLC products:

1. Buy a special version of the library SKZI:
- for Rutoken EDS - SKZI CryptoPRO Rutoken CSP .
- for JaCarta GOST - SKZI CryptoPro FKN CSP .

2. Simultaneously with the SKZI library, it is necessary to purchase specially prepared tokens containing software parts (applets) with which CryptoPRO Rutoken CSP or CryptoPro FCC CSP can work with, respectively.

It turns out that Rutoken EDS and JaCarta GOST are not tokens with non-recoverable keys?

Again, no. These devices can implement the functional FKN (but, perhaps, in a smaller volume than when used in conjunction with CryptoPRO), but for this you need software that can work with applets placed on tokens. Such software can be CryptoARM Standard 5 Plus . He knows how . When generating a key pair in the CryptoARM wizard, you can select a cryptographic provider to be used, for example, Rutoken ECP or eToken GOST. This will allow to use the token as a PCF.

findings

• Do not believe the sellers, nonsense to you the city. The use of conventional versions of the crypto-provider CryptoPRO CSP and the usual Rutoken EDS or JaCarta STOS do not allow the implementation of PCF technology.
• To use the PCF technology in conjunction with the products of CRIPTO-PRO LLC, both specially prepared tokens containing an applet with which the CPSM is able to work, and special versions of the crypto-provider CryptoPRO CSP that can work with the applet on tokens are necessary.
• Rutoken EDS and JaCarta GOST are able to independently implement the FKN technology, but this requires special software.