Cryptographic solutions. From a cloud signature to a trusted environment
This article is a continuation of the article “Cryptographic solutions. From cryptographic providers to browser plugins ” and covers cryptographic solutions:
The concept of a cloud signature involves storing the private key and performing the procedure for signing / encrypting data directly on the server.
For the secure use of a cloud signature, it is required to solve the problem of strong authentication of the client when accessing his private key and the task of reliable storage of the private key on the server. An example of such a solution is CryptoPro DSS, which, as one of the authentication options, supports Rootoken WEB (strong two-factor authentication), and uses HSM to store the private key.
Problems:
Pros:
Browsers created on the basis of the open source projects Mozilla FireFox and Chromium use NSS or OpenSSL as the cryptocore. OpenSSL supports Russian cryptographic algorithms. There are also developments for NSS that provide support for Russian cryptographic algorithms. Some time ago, full-featured browsers with support for Russian cryptography appeared on the market.
Such a solution has great, at the moment 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, safe solutions have been created in which the most critical private key operations are performed on the “board” of the USB token, and the browser itself is stored in its FLASH memory protected from modification. Such a solution, in addition to a high level of security, is very convenient to use.
The picture shows the architecture of the solution implemented in the project to expand the NSS aToken.
Problems:
Pros:
Separate email clients with Russian cryptography make it possible to protect correspondence using electronic signature and message encryption for a subscriber / group of subscribers (S / MIME). This solution is convenient to use in systems built on a point-to-point basis, in which information is exchanged directly between subscribers, and the server is used only for routing messages.
The platform has a set of cryptographic classes that provide extension mechanisms with third-party algorithms. The most famous solution on the market for expanding the Microsoft.NET platform by Russian cryptographic algorithms is the product CryptoPro. NET, which is an add-on for CryptoPro CSP.
Installing CryptoPro.NET allows you to use Russian cryptographic algorithms, for example,
in ASP.NET-based WEB services, SOAP services, and MS.Silverlight client-side browser applications.
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 cryptographic formats PKCS # 7 / CMS, PKCS # 10, X.509 taking into account the specifics described in the RFC of Russian manufacturers CPSI. In addition, according to the developers, the library supports the CADES format with Russian cryptographic algorithms.
The architecture of the cryptographic system of the Java platform (Java Cryptography Architecture) allows you to expand the set of cryptographic algorithms supported in the platform. Given the high prevalence of Java, many of the Russian cryptocurrency developers offer certified JCP providers.
One of the options for using cryptographic information protection in a browser is their integration into Java applets.
In some cases, cryptographic information protection and cryptographic libraries do not require installation and are a native library. In this case, it is possible to integrate it directly “inside” the applet and call the CIPF functions through the JNI mechanism. With this scheme, the library will be installed in the user profile when you first load the Java applet in the browser and you will not need to install it separately.
Another option is to write a Java applet that calls the pre-installed cryptographic information protection system (CSP, JCP, etc.).
A more detailed example of such an implementation based on the use of Rootoken EDS and OpenSSL is described in the article habrahabr.ru/company/aktiv-company/blog / 134890 .
Examples:
PHP is one of the most common web development languages. The PHP cryptographic subsystem is based on OpenSSL, which has support for Russian cryptographic algorithms. But at the same time, in PHP itself, there is no support for Russian cryptographic algorithms. Some Russian manufacturers of cryptographic information protection tools began to formulate a patch for PHP, which would allow the use of Russian cryptography, but these works were not finalized.
The binary compatibility of CIPs such as MagPro CryptoPacket with OpenSSL would make this decision more legitimate.
Currently, many developers of PHP-based information systems use a direct call to the command-line utility OpenSSL to conduct crypto operations using Russian algorithms.
An exotic solution was implemented as part of the Rutoken WEB project. In the server component of the solution, signature verification 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-life Perl projects, developers usually use command-line utility calls from OpenSSL or some Linux-compatible cryptographic information protection tool.
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é, whose author implemented many cryptographic formats directly in JavaScript.
At the same time, cryptographic algorithms are used from the unified core of WebCrypto, which is now supported by most modern browsers.
habrahabr.ru/post/221857
Problems:
Pros:
A class of applications that provide a complete windowed user interface for conducting client crypto operations. As a rule, some cryptographic information protection tool is used as a cryptocore.
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 consider it in detail, but I want to note that conceptually, developers go the following ways:
I would like to dwell on the last method of forming a DS in more detail.
The Security Code company has proposed an interesting Jinn product that allows you to emulate a trusted environment on both a multi-core and single-core computers. The main idea of this solution is that the trusted environment runs on logical kernels that do not run the client OS itself. In the case of a single-core computer, the now-how solution allows emulating a separate physical computing device that is not visible to the OS (or, rather, access to it from the OS is very difficult).
For the case of a multi-core computer, the trusted environment operates on 2 cores, and the client OS operates on the other cores. The trusted environment is loaded before loading the client OS either from a flash drive or from the Sable electronic lock. The solution ensures that the client OS (and therefore potential malware) does not control the behavior of the trusted environment.
In fact, in the solution, two OSs are spaced across different cores of one computer and a data 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 recording.
To access the trusted environment from the client OS, a special library (COM object) is used. When signing a payment through this library, Jinn takes control of the graphics adapter and visualizes the payment on it. If the information provided is correct, then after user confirmation, Jinn signs a payment and returns control of the client OS.
- cloud signature
- separate browsers with Russian cryptography
- individual mail clients with Russian cryptography
- Russian cryptography in frameworks, platforms, interpreters
- desktop cryptographic applications
- trusted environment tools
Cloud signature
The concept of a cloud signature involves storing the private key and performing the procedure for signing / encrypting data directly on the server.
For the secure use of a cloud signature, it is required to solve the problem of strong authentication of the client when accessing his private key and the task of reliable storage of the private key on the server. An example of such a solution is CryptoPro DSS, which, as one of the authentication options, supports Rootoken WEB (strong two-factor authentication), and uses HSM to store the private key.
Platforms | Any with a browser and Internet connection. Authentication Method May Restrict |
Algorithms and Cryptographic Protocols | EDS, encryption, hash function, security, HMAC, VKO |
PKI Integration | X.509, PKCS # 10, CMS, CRL, OCSP, TSP |
EDS mechanisms | Sending a document to the server, signing the document on the server, returning the WEB API signature for integration into third-party services SOAP interface for integration into third-party services |
Authentication mechanisms | authentication protocol Rootoken WEB via SMS login-password |
Secure Message Formats | PKCS # 7, CMS, XMLSec, CADES |
Browser Integration | 100% |
Mobile platforms | iOS, Android |
Command line utility | there is |
Keystores | HSM protected database |
USB Token Interaction | There is a possibility of authentication in the cloud signing service by tokens (CryptoPro DSS and Rootoken WEB) |
Examples (GOST) | CryptoPro DSS “Cloud” signature SKB Kontur Service sign.me |
Problems:
- strong authentication in the service
- guarantees of protection of the private key against unauthorized access
- reduced system security -> application restriction
Pros:
- cross-platform, cross-browser compatibility
- convenience for the end user - nothing to install and configure at all
- convenient integration into information systems (WEB API)
Separate browsers with Russian cryptography
Browsers created on the basis of the open source projects Mozilla FireFox and Chromium use NSS or OpenSSL as the cryptocore. OpenSSL supports Russian cryptographic algorithms. There are also developments for NSS that provide support for Russian cryptographic algorithms. Some time ago, full-featured browsers with support for Russian cryptography appeared on the market.
Such a solution has great, at the moment 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, safe solutions have been created in which the most critical private key operations are performed on the “board” of the USB token, and the browser itself is stored in its FLASH memory protected from modification. Such a solution, in addition to a high level of security, is very convenient to use.
NSS based
The picture shows the architecture of the solution implemented in the project to expand the NSS aToken.
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, security protection, HMAC, VKO, TLS |
PKI Integration | X.509, PKCS # 10, CMS, CRL |
EDS mechanisms | Calling JavaScript functions built into the browser |
TLS-GOST | Built into the library and supported by the browser |
Secure Message Formats | PKCS # 7, CMS |
Browser Integration | 100% |
Mobile platforms | iOS, Android |
Keystores | Browser storage, USB tokens |
USB Token Interaction | Key and certificate storage Using hardware implementation of algorithms |
Installation | The installer, in general, does not require Portable system administrator rights . For example, launching a browser from a FLASH-memory USB-token |
Examples (GOST) | Mozilla FireFox, Chromium from Lissy Atoken project from R-Alpha (Mozilla FireFox) CryptoFox (PKCS11 token based on CryptoPro CSP) |
Problems:
- only one application with Russian cryptography - the browser itself
- browser update
- retrain user to use custom browser
- certification (no precedents)
Pros:
- cross-platform
- user transparency
- no restrictions for server side developers
- no installation, start from a USB flash token from FLASH
Selected email clients with Russian cryptography
Separate email clients with Russian cryptography make it possible to protect correspondence using electronic signature and message encryption for a subscriber / group of subscribers (S / MIME). This solution is convenient to use in systems built on a point-to-point basis, 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, security protection, HMAC, VKO, TLS |
PKI Integration | X.509, PKCS # 10, CMS, CRL |
EDS mechanisms | Calling JavaScript functions built into the browser |
TLS-GOST | Built into the library and supported by the browser |
Secure Message Formats | PKCS # 7, CMS |
Browser Integration | 100% |
Mobile platforms | iOS, Android |
Keystores | Browser storage, USB tokens |
USB Token Interaction | Key and certificate storage Using hardware implementation of algorithms |
Installation | The installer, in general, does not require Portable system administrator rights . For example, launching a browser from a FLASH-memory USB-token |
Examples (GOST) | Mozilla ThunderBird from Lissy DiPost from TS Factor |
Russian cryptography in frameworks, platforms, interpreters
Microsoft .NET
Class extensions
The platform has a set of cryptographic classes that provide extension mechanisms with third-party algorithms. The most famous solution on the market for expanding the Microsoft.NET platform by Russian cryptographic algorithms is the product CryptoPro. NET, which is an add-on for CryptoPro CSP.
Installing CryptoPro.NET allows you to use Russian cryptographic algorithms, for example,
in ASP.NET-based WEB services, SOAP services, and MS.Silverlight client-side browser applications.
Platforms | Microsoft .NET 2.0 and later |
Algorithms and Cryptographic Protocols | EDS, encryption, hash function, security protection, HMAC, VKO, TLS, SOAP |
PKI Integration | X.509, PKCS # 10, CMS, CRL |
EDS mechanisms | Set of classes. There are fully “managed” implementations. There are implementations based on Crypto API 2.0 and CNG |
Authentication mechanisms | client authentication within the framework of TLS authentication in SOAP services own authentication mechanisms based on EDS of random data |
TLS-GOST | Embedding |
Secure Message Formats | PKCS # 7, CMS, XMLSec, SOAP (OASIS Standard 200401), S / MIME |
Browser Integration | EDS and encryption through MS Silverlight |
Keystores | Registry, UBS Tokens |
USB Token Interaction | Key and Certificate Storage Using Algorithm Hardware Implementation Through Crypto API 2.0 |
Applications | Microsoft Lync 2010, Microsoft Office Forms Server 2007 and Microsoft SharePoint 2010, Microsoft XPS Viewer |
Installation | Microsoft NET has been included with Windows since Windows Vista. Support for Russian cryptographic algorithms 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 cryptographic formats PKCS # 7 / CMS, PKCS # 10, X.509 taking into account the specifics described in the RFC of Russian manufacturers CPSI. In addition, according to the developers, the library supports the CADES format with Russian cryptographic algorithms.
Java
The architecture of the cryptographic system of the Java platform (Java Cryptography Architecture) allows you to expand the set of cryptographic algorithms supported in the platform. Given the high prevalence of Java, many of the Russian cryptocurrency developers 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, security protection, HMAC, VKO, TLS |
PKI Integration | X.509, PKCS # 10, CMS, CRL, OCSP, TSP |
EDS mechanisms | Class set |
Authentication mechanisms | TLS client authentication |
TLS-GOST | A standalone TLS provider implemented in Java in accordance with the JavaTM Secure Socket Extension specification |
Secure Message Formats | PKCS # 7, CMS, XMLSec (for example, through the 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 |
USB Token Interaction | Storage of keys and certificates Using hardware implementation of cryptographic algorithms through PKCS # 11 (in Java products LCPKCS11 by Lissy and in Java provider for Rootoken EDS 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 Rootoken EDS Trusted Java |
Java applets
One of the options for using cryptographic information protection in a browser is their integration into Java applets.
In some cases, cryptographic information protection and cryptographic libraries do not require installation and are a native library. In this case, it is possible to integrate it directly “inside” the applet and call the CIPF functions through the JNI mechanism. With this scheme, the library will be installed in the user profile when you first load the Java applet in the browser and you will not need to install it separately.
Another option is to write a Java applet that calls the pre-installed cryptographic information protection system (CSP, JCP, etc.).
A more detailed example of such an implementation based on the use of Rootoken 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)
- RBS Bifit system
Php
PHP is one of the most common web development languages. The PHP cryptographic subsystem is based on OpenSSL, which has support for Russian cryptographic algorithms. But at the same time, in PHP itself, there is no support for Russian cryptographic algorithms. Some Russian manufacturers of cryptographic information protection tools began to formulate a patch for PHP, which would allow the use of Russian cryptography, but these works were not finalized.
The binary compatibility of CIPs such as MagPro CryptoPacket with OpenSSL would make this decision more legitimate.
Currently, many developers of PHP-based information systems use a direct call to the command-line utility OpenSSL to conduct crypto operations using Russian algorithms.
An exotic solution was implemented as part of the Rutoken WEB project. In the server component of the solution, signature verification 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-life Perl projects, developers usually use command-line utility calls from OpenSSL or some Linux-compatible cryptographic information protection tool.
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é, whose author implemented many cryptographic formats directly in JavaScript.
At the same time, cryptographic algorithms are used from the unified core of WebCrypto, which is now supported by most modern browsers.
habrahabr.ru/post/221857
Problems:
- No GOST
- The private key is located in the “repository for the browser”, and not in the alienated medium
- How to connect PKCS # 11-compatible devices?
Pros:
- cross-platform, cross-browser solution
- client signature
- PKI Support
- no installation at all required on the client
Desktop cryptographic applications
A class of applications that provide a complete windowed user interface for conducting client crypto operations. As a rule, some cryptographic information protection tool is used as a cryptocore.
Operations:
- file signature
- verification of the signature under the file, including chaining and checking the revocation list, OCSP, checking the time stamp
- file encryption, including for several respondents
- file decryption
- search and selection of user certificate
- view certificate
- maintaining a database of respondent certificates, integration with a directory service (via LDAP) to search for a respondent certificate
- key pair generation, certificate request generation
- key pair removal
- import / export of certificates (root, user, respondents)
- certificate deletion
Examples:
- CryptoARM
- CryptoNUTS
- File-PRO, Admin PKI
- Block host EDS
- Sign maker
- ViPNet Crypto File
Trust Environment 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 consider it in detail, but I want to note that conceptually, developers go the following ways:
- a separate device on which data intended for signature is visualized and the signature itself is made after user confirmation (trustscreen)
- installation of a set of information protection tools (MDZ, antiviruses, etc.) on the computer and client OS in order to minimize the possibility of malware infection on the computer
- boot a separate trusted OS in USB-live mode
- parallel operation of client OS and trusted environment on different kernels of one computer
I would like to dwell on the last method of forming a DS in more detail.
The Security Code company has proposed an interesting Jinn product that allows you to emulate a trusted environment on both a multi-core and single-core computers. The main idea of this solution is that the trusted environment runs on logical kernels that do not run the client OS itself. In the case of a single-core computer, the now-how solution allows emulating a separate physical computing device that is not visible to the OS (or, rather, access to it from the OS is very difficult).
For the case of a multi-core computer, the trusted environment operates on 2 cores, and the client OS operates on the other cores. The trusted environment is loaded before loading the client OS either from a flash drive or from the Sable electronic lock. The solution ensures that the client OS (and therefore potential malware) does not control the behavior of the trusted environment.
In fact, in the solution, two OSs are spaced across different cores of one computer and a data 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 recording.
To access the trusted environment from the client OS, a special library (COM object) is used. When signing a payment through this library, Jinn takes control of the graphics adapter and visualizes the payment on it. If the information provided is correct, then after user confirmation, Jinn signs a payment and returns control of the client OS.