Cryptographic solutions. From the cloud signature to the trusted environment
This article is a continuation of the article “Cryptographic solutions. From crypto-providers to browser plug-ins " and covers cryptographic solutions:
The concept of a cloud signature involves storing the private key and performing the procedure of signing / encrypting data directly on the server.
To securely use a cloud signature, you need to solve the problem of strict client authentication when accessing its private key and the task of storing the private key securely on the server. An example of such a solution is CryptoPro DSS, which supports Rutoken WEB (strong two-factor authentication) as one of the authentication options, and uses HSM for storing the private key.
')
Problems:
Pros:
Browsers based on Mozilla FireFox and Chromium open source projects use NSS or OpenSSL as a crypto core. OpenSSL supports Russian cryptographic algorithms. For NSS, there are also developments that provide support for Russian cryptoalgorithms. Some time ago, full-featured browsers with support for Russian cryptography appeared on the market.
This solution has a large, currently unclaimed potential, as it allows you to create secure standard WEB clients for systems with high security requirements. Another advantage of this browser is its "portability". Taking into account the existence of USB tokens with secure FLASH memory, secure solutions are created in which the most critical operations with the private key are performed on the “board” of the USB token, and the browser itself is stored in its protected from modification of the FLASH memory. Such a solution, in addition to a high level of security, is very convenient to use.
The picture shows the solution architecture implemented in the NSS aToken extension project.
Problems:
Pros:
Separate mail clients with Russian cryptography allow realizing the protection of correspondence using electronic signature and letter encryption for a subscriber / group of subscribers (S / MIME). This solution is convenient to use in systems built on a point-to-point prince, in which information is exchanged directly between subscribers, and the server is used only for routing messages.
There is a set of cryptographic classes in the platform, in which extension mechanisms are provided by third-party algorithms. The best-known solution in the market for expanding the Microsoft.NET platform with Russian cryptoalgorithms is the CryptoPro product. NET, which is a superstructure above the CryptoPro CSP.
Installing CryptoPro.NET allows you to use Russian cryptoalgorithms, for example,
in WEB-services based on ASP.NET, SOAP-services, in client browser applications MS.Silverlight.
BouncyCastle is an open source library that implements its own cryptographic class system for the Microsoft .NET platform. The library supports both basic cryptographic algorithms GOST 28147-89, GOST R 34.10-2001, GOST R 34.11-94, and the cryptographic formats PKCS # 7 / CMS, PKCS # 10, X.509 taking into account the specifics described in the RFC of Russian manufacturers SKZI. In addition, according to the developers, the library supports the CADES format with Russian cryptoalgorithms.
The Java cryptographic system architecture (Java Cryptography Architecture) allows you to extend the set of cryptographic algorithms supported in the platform. Given the high prevalence of Java, many of the Russian developers of cryptographic tools offer certified JCP providers.
One of the options for using SKZI in the browser is their integration into Java applets.
In a number of cases, the CMIS and cryptographic libraries do not require installation and are a native library. In this case, it is possible to integrate directly “inside” the applet and call the functions of the MISS via the JNI mechanism. With this scheme, the library will be installed in the user profile when the Java applet is first loaded in the browser and its separate installation is not required.
Another option is to write a Java applet, which calls pre-installed in the system SKZI (CSP, JCP, etc.)
A more detailed example of such an implementation, based on the use of Rutoken EDS and OpenSSL, is described in the article habrahabr.ru/company/aktiv-company/blog/134890 .
Examples:
PHP is one of the most common languages for web development. The cryptographic subsystem of PHP is built on the basis of OpenSSL, in which there is support for Russian cryptoalgorithms. But at the same time in PHP itself there is no support for Russian cryptoalgorithms. Some Russian producers of SKZI started forming a patch for PHP, which would allow the use of Russian cryptography, but these works were not completed.
Binary compatibility of SKZI such as MagPro CryptoPack with OpenSSL would give this solution legitimacy.
Currently, many developers of information systems based on PHP use a direct call to the command line utility OpenSSL for conducting crypto operations using Russian algorithms.
The exotic solution is implemented in the framework of the project Rutoken WEB. In the server component of the solution, the verification of the signature of GOST R 34.10-2001 is implemented directly in PHP using mathematical primitives from the native library.
Another exotic example is the implementation of encryption according to GOST 28147-89 directly on Perl http://search.cpan.org/~ams/Crypt-GOST-1.00/GOST.pm .
At the same time, in real Perl projects, developers usually use command line utility calls from OpenSSL or some Linux-compatible SKZI.
Ruby uses openssl as a crypto core, which allowed the author of this article, habrahabr.ru/post/231261, to patch it to support Russian cryptography.
Some time ago an article appeared on Habré, the author of which implemented many cryptographic formats directly in JavaScript
At the same time, cryptoalgorithms are used from the unified WebCrypto kernel, which is already supported by most modern browsers.
habrahabr.ru/post/221857
Problems:
Pros:
A class of applications that provide a complete window user interface for client crypto operations. As a rule, use some SKZI as a cryptokernel.
Operations:
Examples:
The problem of creating a trusted environment for performing crypto operations, in particular, EDS, is a separate big topic. This article does not plan to examine it in detail, but I would like to note that, conceptually, developers follow the following paths:
I would like to dwell on the latter method of forming the DS.
The Security Code company offered an interesting product Jinn, which allows you to emulate a trusted environment on both a multi-core and single-core computer. The main idea of this solution is that the trusted environment runs on logical cores on which the client OS itself is not running. In the case of a single-core computer, the now-how solution allows the emulation of a separate physical computing device that the OS cannot see (or, more precisely, access to it from the OS is very difficult).
For the case of a multi-core computer, the trusted environment operates on 2 cores, on the other cores the client OS operates. The trusted environment is loaded before loading the client OS either from a USB flash drive or from the Sable electronic lock. The solution ensures that the client OS (and therefore the potential malware) does not control the behavior of the trusted environment.
In fact, in the solution, the two operating systems are separated into different cores of the same computer and the data transmission channel is configured between them. At the same time, one of the OS (trusted environment) is designed in such a way that its infection options are minimized and its functionality serves solely the purpose of safe data visualization and copying.
To access the trusted environment from the client OS, a special library (COM object) is used. When signing a payment card through this library, Jinn intercepts the control of the graphics adapter and visualizes the payment card on it. If the information provided is correct, after confirming the user, Jinn signs the payment order and returns control to the client OS.
- cloud signature
- individual browsers with Russian cryptography
- individual mail clients with Russian cryptography
- Russian cryptography in frameworks, platforms, interpreters
- desktop cryptographic applications
- means of forming a trusted environment
Cloud signature
The concept of a cloud signature involves storing the private key and performing the procedure of signing / encrypting data directly on the server.
To securely use a cloud signature, you need to solve the problem of strict client authentication when accessing its private key and the task of storing the private key securely on the server. An example of such a solution is CryptoPro DSS, which supports Rutoken WEB (strong two-factor authentication) as one of the authentication options, and uses HSM for storing the private key.
| Platforms | Any with a browser and Internet access. Authentication method may impose restrictions |
| Algorithms and cryptographic protocols | EDS, encryption, hash function, imitation protection, HMAC, VKO |
| PKI Integration | X.509, PKCS # 10, CMS, CRL, OCSP, TSP |
| EDS mechanisms | Sending the document to the server, signing the document on the server, returning the signature WEB API for integration into third-party services SOAP-interface for integration into third-party services |
| Authentication mechanisms | by authentication protocol Rutoken WEB by SMS Login: Password |
| Secure Message Formats | PKCS # 7, CMS, XMLSec, CADES |
| Browser Integration | 100% |
| Mobile platforms | iOS, Android |
| Commandline utility | there is |
| Keystores | HSM protected DB |
| Interacting with USB tokens | It is possible to authenticate in the cloud signature service by tokens (CryptoPRO DSS and Rutoken WEB) |
| Examples (GOST) | CryptoPro DSS Cloud signature of SKB Kontur Service sign.me |
')
Problems:
- strong authentication in the service
- guarantees protecting the private key from unauthorized access
- reduced system security -> limiting use
Pros:
- cross-platform, cross-browser compatibility
- convenience for the end user - in general, nothing needs to be installed and configured
- convenient integration into information systems (WEB API)
Separate browsers with Russian cryptography
Browsers based on Mozilla FireFox and Chromium open source projects use NSS or OpenSSL as a crypto core. OpenSSL supports Russian cryptographic algorithms. For NSS, there are also developments that provide support for Russian cryptoalgorithms. Some time ago, full-featured browsers with support for Russian cryptography appeared on the market.
This solution has a large, currently unclaimed potential, as it allows you to create secure standard WEB clients for systems with high security requirements. Another advantage of this browser is its "portability". Taking into account the existence of USB tokens with secure FLASH memory, secure solutions are created in which the most critical operations with the private key are performed on the “board” of the USB token, and the browser itself is stored in its protected from modification of the FLASH memory. Such a solution, in addition to a high level of security, is very convenient to use.
Based on NSS
The picture shows the solution architecture implemented in the NSS aToken extension project.
| Specification | NSS using PKCS # 11 tokens, software and hardware |
| Platforms | Windows family, GNU \ Linux, OS X, iOS, Android |
| Algorithms and cryptographic protocols | EDS, encryption, hash function, imitation protection, HMAC, VKO, TLS |
| PKI Integration | X.509, PKCS # 10, CMS, CRL |
| EDS mechanisms | Calling from JavaScript functions embedded in the browser |
| TLS-GOST | Built in library and supported by browser |
| Secure Message Formats | PKCS # 7, CMS |
| Browser Integration | 100% |
| Mobile platforms | iOS, Android |
| Keystores | Browser storage, USB tokens |
| Interacting with USB tokens | Keys and Certificates Store Use of hardware implementation of algorithms |
| Installation | The installer, in general, does not require system administrator rights. Portable. For example, launching a browser with a USB token FLASH |
| Examples (GOST) | Mozilla FireFox, Chromium from Lissi Project atoken by R-Alpha (Mozilla FireFox) CryptoFox (PKCS11 token based on CryptoPro CSP) |
Problems:
- Only one application with Russian cryptography - the browser itself
- browser update
- retrain the user to use custom browser
- certification (no precedent)
Pros:
- cross platform
- transparency of use for the user
- no restrictions for server side developers
- installation is not required; launch from USB flash token
Separate mail clients with Russian cryptography
Separate mail clients with Russian cryptography allow realizing the protection of correspondence using electronic signature and letter encryption for a subscriber / group of subscribers (S / MIME). This solution is convenient to use in systems built on a point-to-point prince, in which information is exchanged directly between subscribers, and the server is used only for routing messages.
| Platforms | Windows family, GNU \ Linux, OS X, iOS, Android |
| Algorithms and cryptographic protocols | EDS, encryption, hash function, imitation protection, HMAC, VKO, TLS |
| PKI Integration | X.509, PKCS # 10, CMS, CRL |
| EDS mechanisms | Calling from JavaScript functions embedded in the browser |
| TLS-GOST | Built in library and supported by browser |
| Secure Message Formats | PKCS # 7, CMS |
| Browser Integration | 100% |
| Mobile platforms | iOS, Android |
| Keystores | Browser storage, USB tokens |
| Interacting with USB tokens | Keys and Certificates Store Use of hardware implementation of algorithms |
| Installation | The installer, in general, does not require system administrator rights. Portable. For example, launching a browser with a USB token FLASH |
| Examples (GOST) | Mossilla ThunderBird by Lissi DiPost from TS Factor |
Russian cryptography in frameworks, platforms, interpreters
Microsoft.NET
Class extensions
There is a set of cryptographic classes in the platform, in which extension mechanisms are provided by third-party algorithms. The best-known solution in the market for expanding the Microsoft.NET platform with Russian cryptoalgorithms is the CryptoPro product. NET, which is a superstructure above the CryptoPro CSP.
Installing CryptoPro.NET allows you to use Russian cryptoalgorithms, for example,
in WEB-services based on ASP.NET, SOAP-services, in client browser applications MS.Silverlight.
| Platforms | Microsoft .NET 2.0 and older |
| Algorithms and cryptographic protocols | EDS, encryption, hash function, imitation protection, HMAC, VKO, TLS, SOAP |
| PKI Integration | X.509, PKCS # 10, CMS, CRL |
| EDS mechanisms | A set of classes. There are fully “managed” implementations. There are implementations based on Crypto API 2.0 and CNG |
| Authentication mechanisms | client authentication within TLS authentication in SOAP services own authentication mechanisms based on random data e-signature |
| TLS-GOST | Embedding |
| Secure Message Formats | PKCS # 7, CMS, XMLSec, SOAP (OASIS Standard 200401), S / MIME |
| Browser Integration | EDS and encryption via MS Silverlight |
| Keystores | Registry, UBS Tokens |
| Interacting with USB tokens | Keys and Certificates Store Use of hardware implementation of algorithms Through Crypto API 2.0 |
| Applications | Microsoft Lync 2010, Microsoft Office Forms Server 2007 and Microsoft SharePoint 2010, Microsoft XPS Viewer |
| Installation | Microsoft. NET is included with Windows starting with Windows Vista. Support for Russian cryptoalgorithms requires the installation of additional software |
| Examples (GOST) | CryptoPro. NET (based on CryptoPro CSP) |
Separate libraries
BouncyCastle is an open source library that implements its own cryptographic class system for the Microsoft .NET platform. The library supports both basic cryptographic algorithms GOST 28147-89, GOST R 34.10-2001, GOST R 34.11-94, and the cryptographic formats PKCS # 7 / CMS, PKCS # 10, X.509 taking into account the specifics described in the RFC of Russian manufacturers SKZI. In addition, according to the developers, the library supports the CADES format with Russian cryptoalgorithms.
Java
The Java cryptographic system architecture (Java Cryptography Architecture) allows you to extend the set of cryptographic algorithms supported in the platform. Given the high prevalence of Java, many of the Russian developers of cryptographic tools offer certified JCP providers.
Jcp
| Specification | Java Cryptography Architecture, JavaTM Cryptography Extension, JavaTM Secure Socket Extension |
| Platforms | Sun Java 2 Virtual Machine |
| Algorithms and cryptographic protocols | EDS, encryption, hash function, imitation protection, HMAC, VKO, TLS |
| PKI Integration | X.509, PKCS # 10, CMS, CRL, OCSP, TSP |
| EDS mechanisms | Class set |
| Authentication mechanisms | client authentication within TLS |
| TLS-GOST | Separate TLS provider implemented in Java according to Java TM Secure Socket Extension specification |
| Secure Message Formats | PKCS # 7, CMS, XMLSec (for example, via Apache XML Security API), S / MIME; |
| Browser Integration | EDS / encryption via Java applets, loading applets via Java TLS |
| Directory Service Integration | with arbitrary LDAP directory |
| Mobile platforms | Android |
| Keystores | Registry, files, UBS-tokens, MicroSD-tokens |
| Interacting with USB tokens | Keys and Certificates Store Using hardware implementation of cryptographic algorithms through PKCS # 11 (in Lissi company's Java LCPKCS11 products and in a Java provider for Rutoken DS of Active) |
| Installation | Setup program requires system administrator rights |
| Examples (GOST) | CryptoPro JCP, CryptoPro JTLS Signal-COM JCP, Signal-COM Java TLS LCJCE, LCJSSE, LCPKCS11 Java provider for Rutoken EDS Trusted java |
Java applets
One of the options for using SKZI in the browser is their integration into Java applets.
In a number of cases, the CMIS and cryptographic libraries do not require installation and are a native library. In this case, it is possible to integrate directly “inside” the applet and call the functions of the MISS via the JNI mechanism. With this scheme, the library will be installed in the user profile when the Java applet is first loaded in the browser and its separate installation is not required.
Another option is to write a Java applet, which calls pre-installed in the system SKZI (CSP, JCP, etc.)
A more detailed example of such an implementation, based on the use of Rutoken EDS and OpenSSL, is described in the article habrahabr.ru/company/aktiv-company/blog/134890 .
Examples:
- Applet ETP "Stroytorgi" (implemented in accordance with the architecture shown in the diagram)
- DBO System Bifit
Php
PHP is one of the most common languages for web development. The cryptographic subsystem of PHP is built on the basis of OpenSSL, in which there is support for Russian cryptoalgorithms. But at the same time in PHP itself there is no support for Russian cryptoalgorithms. Some Russian producers of SKZI started forming a patch for PHP, which would allow the use of Russian cryptography, but these works were not completed.
Binary compatibility of SKZI such as MagPro CryptoPack with OpenSSL would give this solution legitimacy.
Currently, many developers of information systems based on PHP use a direct call to the command line utility OpenSSL for conducting crypto operations using Russian algorithms.
The exotic solution is implemented in the framework of the project Rutoken WEB. In the server component of the solution, the verification of the signature of GOST R 34.10-2001 is implemented directly in PHP using mathematical primitives from the native library.
Perl
Another exotic example is the implementation of encryption according to GOST 28147-89 directly on Perl http://search.cpan.org/~ams/Crypt-GOST-1.00/GOST.pm .
At the same time, in real Perl projects, developers usually use command line utility calls from OpenSSL or some Linux-compatible SKZI.
Ruby
Ruby uses openssl as a crypto core, which allowed the author of this article, habrahabr.ru/post/231261, to patch it to support Russian cryptography.
Javascript
Some time ago an article appeared on Habré, the author of which implemented many cryptographic formats directly in JavaScript
At the same time, cryptoalgorithms are used from the unified WebCrypto kernel, which is already supported by most modern browsers.
habrahabr.ru/post/221857
Problems:
- No guests
- The private key is in the “browser repository”, and not in a removable medium
- How to connect PKCS # 11 compatible devices?
Pros:
- cross-platform, cross-browser solution
- client signature
- PKI support
- no installation at all on the client is required
Desktop cryptographic applications
A class of applications that provide a complete window user interface for client crypto operations. As a rule, use some SKZI as a cryptokernel.
Operations:
- file signature
- verification of the signature under the file, including building a chain and checking the revocation list, OCSP, timestamp checking
- file encryption, including for several respondents
- file decryption
- search and select user certificate
- view certificate
- maintaining the database of respondent certificates, integration with the directory service (via LDAP protocol) to search for the respondent certificate
- generating a key pair, generating a certificate request
- key pair removal
- import / export certificates (root, user, respondents)
- certificate deletion
Examples:
- CryptoARM
- Crypto NUCLEU
- File-PRO, Admin PKI
- Blockhost EDS
- Sign maker
- ViPNet Crypto File
Trusted environment formation tools
The problem of creating a trusted environment for performing crypto operations, in particular, EDS, is a separate big topic. This article does not plan to examine it in detail, but I would like to note that, conceptually, developers follow the following paths:
- a separate device on which the data intended for the signature is visualized and the signature itself is produced after user confirmation (trustscreen)
- installation on the computer and client OS of a complex of information security tools (MDZ, antivirus, etc.), in order to minimize the possibility of computer infection by malware
- download a separate trusted OS in USB-live mode
- parallel operation of client OS and trusted environment on different cores of the same computer
I would like to dwell on the latter method of forming the DS.
The Security Code company offered an interesting product Jinn, which allows you to emulate a trusted environment on both a multi-core and single-core computer. The main idea of this solution is that the trusted environment runs on logical cores on which the client OS itself is not running. In the case of a single-core computer, the now-how solution allows the emulation of a separate physical computing device that the OS cannot see (or, more precisely, access to it from the OS is very difficult).
For the case of a multi-core computer, the trusted environment operates on 2 cores, on the other cores the client OS operates. The trusted environment is loaded before loading the client OS either from a USB flash drive or from the Sable electronic lock. The solution ensures that the client OS (and therefore the potential malware) does not control the behavior of the trusted environment.
In fact, in the solution, the two operating systems are separated into different cores of the same computer and the data transmission channel is configured between them. At the same time, one of the OS (trusted environment) is designed in such a way that its infection options are minimized and its functionality serves solely the purpose of safe data visualization and copying.
To access the trusted environment from the client OS, a special library (COM object) is used. When signing a payment card through this library, Jinn intercepts the control of the graphics adapter and visualizes the payment card on it. If the information provided is correct, after confirming the user, Jinn signs the payment order and returns control to the client OS.
Source: https://habr.com/ru/post/242603/
All Articles