PKCS # 11 (Cryptoki) is a standard developed by RSA Laboratories for programs to interact with cryptographic tokens, smart cards and other similar devices using a unified programming interface that is implemented through libraries. It should be noted that in the Republic of Belarus there is a State standard "Information exchange interface with a hardware and software carrier of cryptographic information (Token)", which concerns exactly the standardization of the PKCS # 11 interface.
Cryptographic tokens provide both the storage of certificates and key pairs (public and private keys) and the performance of cryptographic operations. The weak link here is the storage of the private key. If the public key has disappeared, then it can always be restored using the private key or taken from the certificate. The loss / destruction of a token with an unrecoverable private key has sad consequences, for example, you will not be able to decrypt files encrypted on your public key, you will not be able to put an electronic signature (ES). But the last problem is solved by generating a new key pair and, for a certain amount of money, obtaining a new certificate in one of the certification centers computer engineering description.
PKCS # 11 Cloud Token
Currently, software, firmware and hardware tokens are common. And now we are considering another type of PKCS # 11 cryptographic token - a cloud token.
Today you will not surprise anyone with a cloud flash drive . All the advantages and disadvantages of a cloud flash drive are almost one in one inherent in a cloud token.
The main thing here is the security of the data stored in the cloud token, first of all, the private keys. Could this cloud token provide? We say - YES!
And so how does a cloud token work?
Naturally, the PKCS # 11 cloud, like any network resource, has an IP / port entry point. We will consider a real LS11CLOUD cloud that exists on the Internet at pkcs11.ru:4444.
Cloud registration
The first step is to register the client in the token cloud. The ls11cloud_cjnfig utility is used for registration:
bash-4.3 $ / usr / local / bin64 / ls11cloud_config
LS11CLOUD User Utility
usage: / usr / local / bin64 / ls11cloud_config <command> [-p <password>] [-n <new password>]
Commands:
register <host> <port> <id> - register new user on the server
duplicate <host > <port> <id> - duplicate user account on other computer
change_pswd - change SESPAKE authentication password
status - display current configuration data
log - display server log file
recreate - re-create token to initial empty state
unregister - remove all user files from the server
NB: Don't use non-latin letters to avoid encoding problems!
Copyright (C) LISSI-Soft, Ltd (http://soft.lissi.ru) 2017-2018
bash-4.3 $
The "register" command of the ls11cloud_config utility performs registration of the user under the nickname ("id" field) in the cloud. The user's interaction with the cloud is carried out via an encrypted channel. To generate an agreed key, on the basis of which traffic between the client and the server will be protected / encrypted, the SESPAKE protocol is used - a protocol for generating a shared key with password-based authentication . The password for the SESPAKE protocol is also set when registering in the cloud. Immediately, we note that this password has nothing to do with the PIN-codes of the token, which the user will have in the cloud. This is the password that is involved in creating a secure (encrypted) channel between the cloud and the user:
It is through this secure channel that access to the token in the cloud takes place. Note that it would be good practice to change the password (the "change_pswd" command) before starting or ending each session. The ls11cloud_config utility has a graphical shell that greatly facilitates the process of interacting with the cloud:
In this case, registration looks like this:
And after setting the password, the user will be registered in the LS11CLOUD cloud:
There is a second registration scheme in the cloud, it may be preferable, for example, for a corporate cloud or the user already has a cloud token. The administrator registers a number of nicknames in the cloud and gives them initial passwords. Then these nicknames along with passwords are given to employees. In this case, the employee must first duplicate the nickname from the cloud at his workplace:
Then he will be prompted for the password that the PKCS # 11 cloud administrator gave him or that he already has, and if everything went well, the employee will have access to the cloud:
If the user has duplicated the token given to him by the cloud token administrator, then the employee needs to change the password. This is a fairly standard procedure where the current password will be prompted and then a new one twice.
PKCS # 11 Cloud Token Management
After registering in the cloud, the user must initialize his personal token in the cloud, which will be available to him and only to him. Initializing a cloud token is no different from initializing any other PKCS # 11 token and consists of setting the token token and, most importantly, setting secret PINs. Tokens have two types of PIN-code: user PIN-code (USER PIN) and administrator PIN-code (SO PIN)). The user PIN-code should be known only to the owner of the token and set by him. As for the SO PIN, the token holders often do not pay attention to it. It is not right. And if we are talking about a cloud token, its security, then only the owner of such a token should own both types of PIN-code. These operations should only be carried out over a secure / encrypted channel.pk11conf :
bash-4.3 $ / usr / local / bin64 / p11conf
usage: / usr / local / bin64 / p11conf [-hitsmIupPredf] -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
-e enumerate objects
-d dump all object attributes (additional to -e and to -f)
-r remove all objects
-e -r remove enumerated objects with prompt
-f enumerate certificates and write them to DER-files with prompt
Version 5.7
Copyright (C) 2011-2018
bash-4.3 $
Before going further, let's talk about the main thing. You can get distributions with everything you need to work with the PKCS # 11 cloud on computers with Linux and Windows operating systems here .
The p11conf utility, like the ls11cloud_config utility, has a graphical shell, which is found in the distributions:
The distributions also contain the ls11cloud library, which actually provides users with the PKCS # 11 interface. By choosing the ls11cloud cloud token library, you can initialize the cloud token:
When initializing the token, keep in mind that the default SO PIN is 87654321. After the token is initialized, it needs to be changed. And so, if everything went well, then the user will receive the following information:
Everything, after completing these steps, the cloud token is ready for use. It should be noted that currently the LS11CLOUD cloud token supports only Russian cryptography (in accordance with the standards GOST R 34.10-2001 / 2012, GOST R 34.11-94 / 2012, GOST 28147-89, GOST R 34.12-2015 and GOST R 34.13- 2015). You can see which cryptographic mechanisms are supported by the cloud token using the same P11CONF utility:
Cloud Token Testing
The cloud token can be used in any applications that work with cryptographic providers using the PKCS # 11 protocol.
The easiest way to test the operation of a cloud token is to install a version of Mozills Firefox with support for Russian cryptography. You can download this version under the name RedFox here . After the RedFox browser is installed , you need to connect the cloud token (Edit-> Settings-> Additional-> Security devices-> Download):
After connecting, the browser will ask for a PIN code to access the cloud token. Now, when the cloud token is connected, Russian cryptography is connected, you can try to establish an anonymous TLS connection with any web server using Russian ciphers, for example, at this address (https://soft.lissi.ru/):
If you disable the cloud token, then you will not be able to establish a connection. In order to use authorized https / tls or secure email, you must have personal certificates in the cloud token. They can be installed with the same browser from a secure PKCS # 12 container (password 01234567) or obtained from a certification authority (CA) using the same browser.
No comments:
Post a Comment