support in Rutoken devices

Rutoken Module: principles of integration

Devices of the Rutoken Module line are designed to ensure the security of machine-to-machine communication (M2M), the protection of automated process control systems (APCS) and the Internet of Things (IoT). USB, UART, USART or SPI buses can be used as interfaces for embedded devices.

Rutoken Module devices run the same operating system as Rutoken EDS tokens and smart cards. They have the same APDU interface and are supported by a similar middleware stack, at the top of which is at least an implementation of the PKCS#11 standard. PKCS#11 is a flexible interface that allows you to manage connected devices, cryptographic keys and certificates on them and perform cryptographic operations of encryption, signing, generating a derivative key, etc. For the convenience of developers, additional software products are built on top of the PKCS#11 interface that help, using Rutoken devices, to support secure storage and exchange of data using applied cryptography standards, such as Cades, XMLDSig, TLS. To support these standards, Rutoken has a number of mechanisms in its arsenal that allow the use of devices through high-level interfaces, both opensource (cryptographic libraries OpenSSL, BouncyCastle) and proprietary (for example, the Rutoken Plugin web interface or a related native interface PKI-Core).

Often, adding new functionality to a device requires implementing changes at one or more middleware levels. In the case of support for the CRISP protocol, changes affected the APDU command interface, required an expansion of the standard PKCS#11 library interface, and also led to the development of new software interfaces.

To understand the reasons for such extensive changes, we will have to delve a little deeper into the details of the CRISP protocol.

CRISP protocol

The description of the CRISP protocol has evolved from the methodological recommendations of TK26 MP 26.4.001-2019 “Secure exchange protocol for industrial systems (CRISP 1.0)” to standardization recommendations R 1323565.1.029-2019 “Information technology. Cryptographic information protection. Secure exchange protocol for industrial systems”.
Released in 2022 Amendment No. 1 to R 1323565.1.029-2019previously published as MP 26.4.003-2021 “Cryptographic sets CS = 3 and CS = 4 for the secure exchange protocol for industrial systems CRISP 1.0”. Finally, in 2024, the CRISP protocol was adopted as a standard GOST R 71252–2024 “Information technology. Cryptographic information protection. Secure exchange protocol for industrial systems”. The protocol was developed by the InfoTeKS company. To familiarize yourself with the protocol, you can use the following materials:

• webinar “Cryptographic protocol CRISP. What? Where? When?”: infotecs.ru, youtube;

• presentation by Olga Shemyakina “Secure Exchange Protocol for Industrial Systems (CRISP 1.0)” at RusCrypto 2019: ruscrypto.ru.

Cryptography in the protocol

The CRISP protocol involves the exchange of authenticated or authenticated and encrypted messages. It is assumed that the parties exchanging messages have a pre-agreed common key – the base key. Optionally it can be identified from a set of public keys.

Messages consist of a header, payload, and trailer.

The header contains service fields:

• version of the CRISP protocol,

• identifier of the cryptosuite used,

• message sequence number,

• the base key identifier or an indication that the base key identification is done outside the protocol.

The trailer contains a simulated message insertion.

The crypto sets used involve calculating the imitative insertion according to GOST R 34.13—2015 block cipher “Magma” according to GOST R 34.12—2015 (for cryptographic suites CS=1, CS=2 MAC length 4 bytes, for cryptosuites CS=3, CS=4 MAC length 8 bytes) and encryption with the Magma block cipher according to GOST R 34.12—2015 in gamma mode according to GOST R 34.13—2015 (for crypto sets CS=1, CS=3). When using cryptographic suites CS=2, CS=4, encryption is not performed.

Encryption and message insertion keys are derived from the base key Key by concatenating several results of a pseudo-random function (PRF). The function CMAC(Key, Data) is used as a PRF, where CMAC is the function for generating imitation inserts using the Magma block cipher.

The scheme for generating derivative encryption keys and simulating insertion is worthy of attention. The general principle of constructing the derivative key generation scheme used in the CRISP protocol is presented in NIST 800-108, clause 4.1 – “KDF in Counter Mode” scheme.

According to this scheme, the derived key material is the concatenation of the results of performing a pseudo-random transformation on the concatenation of the fixed data and the counter value.

Where

• || – concatenation,

• K_IN – basic key,

• [x]₂ — binary representation of number x with length r bits,

• L — length of the output key material in bits,

• Label And Context — fixed data.

The standard allows that one or more fields from the set {Label,0x00, Context, [L]₂} may not be used.

In relation to CRISP, this scheme looks like this:

• function is used as PRF CMAC(Key, Data)implemented using the Magma block cipher according to GOST R 34.12—2015 in the simulation insertion calculation mode according to GOST R 34.13—2015;

• Label takes values ​​depending on the crypto set:

  • {'m', 'a', 'c', 'e', 'n', 'c', 0x06} for CS=1 and CS=3,

  • {'m', 'a', 'c', 'm', 'a', 'c', 0x06} for CS=2 and CS=4,

• separating Label And Context byte 0x00 is not used,

• Context constructed as a concatenation ContextBodyconsisting of 5 zero bits, 35 high bits of the message sequence number, the name of the message sender, the cipher suite number, and ContextBodyLength — one-byte binary representation of length ContextBody,

• L := 512 for CS=1 and CS=3, L := 256 for CS=2 and CS=4.

For all cipher suites:

For cipher suites with encryption:

Due to the fact that the 35 most significant bits of the 48-bit message sequence number are involved in key generation, it turns out that cryptographic processing of 8192 consecutive messages is carried out using the same key material.

Protocol flow control

The CRISP protocol provides numbering for messages transmitted from the sender to the recipient. It is assumed that the sender increments the message sequence number when sending each new message.

The recipient keeps a record of received messages based on a sliding window of a fixed size. The message window is determined by the minimum and maximum window number. The received messages window is managed as follows:

• Before starting a transmit/receive session, the recipient sets the expected minimum and maximum window numbers to 0.

• Messages with a number less than the minimum window number are not accepted.

• When a message with a number greater than the maximum window number is received, the message number becomes the maximum window number—the window moves.

• Within the window, a record of the numbers of received messages is kept.

• Messages containing the number of an already received message are not accepted.

In addition to taking into account message numbers, the recipient naturally performs other actions to check the consistency of the received message, for example:

• protocol version control (version must be supported by the recipient),

• control of the key identifier value (the recipient must know which key to use for cryptographic operations),

• control of message integrity using cryptographic methods – checking the value of the imitative insert.

CRISP protocol support by Rutoken products

As already mentioned, the changes caused by the addition of support for the CRISP protocol affected the operating system of Rutoken devices (expansion of functionality and addition of the APDU interface), required the design and implementation of an extension to the PKCS#11 interface and led to the development of additional software modules that implement the logic of the CRISP protocol and use as a cryptography provider for the Rutoken EDS 3.0 device or Rutoken Module via the PKCS#11 interface.

Changes in Rutoken OS

Over the twenty-year history, the operating system of devices of the Rutoken family has acquired quite extensive functionality. When designing OS functionality, developers try to anticipate future needs and for this purpose create flexible and extensible interfaces. Largely due to this, changes in the Rutoken OS turned out to be minimal: the OS allows you to manage cryptographic keys stored on the device and perform cryptographic operations using them. The only thing that had to be added was a new mode for generating a derived key, in accordance with the algorithm described above from the CRISP protocol specification. At the same time, no new APDU commands appeared in the APDU interface, but a new mode appeared for the CHANGE REFERENCE DATA APDU command, which uses the added functionality.

Changes in the implementation of the PKCS#11 interface

An international version of the PKCS#11 interface specification is being developed by OASIS Open. The PKCS#11 interface itself allows for its expansion: adding new types, object attributes, and cryptographic mechanisms.

The PKCS#11 interface is being expanded to support domestic cryptographic algorithms and mechanisms working group 2.4 as part of TC26. This working group is credited to MP 26.2.007-2017 “Extension of PKCS#11 for the use of Russian standards GOST R 34.10-2012 and GOST R 34-11-2012” (English version available for download) and not yet published, but already supported manufacturers of smart cards MP “Extension of PKCS#11 for the use of GOST 34.12-2018 and GOST 34.13-2018 standards.”

The expansion of the PKCS#11 interface to support mechanisms specific only to specific devices is also being done by the manufacturers of these devices, which are developing an implementation of the PKCS#11 interface for these devices. With the support of the CRISP protocol, our company followed this path. We have developed an interface extension specification”PKCS#11 extension to support CRISP protocol”. The extension adds:

• Mechanism for generating a derived key CKM_VENDOR_KDF_CRISP_CMAC. This mechanism allows you to develop from a basic key type CKK_MAGMA or a derived key CKK_MAGMAused to count imitations, or a dual key CKK_MAGMA_TWIN_KEY, which is a pair of symmetric keys used for encryption and counting imitations. The type of derived key depends on the specified mechanism parameters.

• Authenticated encryption mechanism on dual Magma keys in accordance with the CRISP protocol CK_VENDOR_CRISP_AEAD_PARAMS.

Rutoken CRISP SDK

The changes made to the Rutoken operating system and to the implementation of the PKCS#11 interface are, in principle, sufficient to state that the CRISP protocol is supported by Rutoken devices: there are all the necessary cryptographic mechanisms for creating and processing CRISP protocol messages and a public interface for their use. But it often happens that cryptographic solutions integrators perceive the PKCS#11 interface as too complex, and providing this interface alone sets a fairly high barrier to entry for integration. To reduce the entry threshold, our company develops high-level modules that operate on abstractions such as X.509 certificates, certificate requests in PKCS#10 format, encrypted and signed messages in CMS, CAdES and XAdES formats. For this purpose, pki-core modules have been implemented (documentationreview), Rutoken Plugin (documentationexperience of use), integration module in OpenSSL (documentationusage experience).

Rutoken CRISP SDK was implemented as a high-level interface for supporting the CRISP protocol, which includes:

• rtcrisp module – implementation of the non-cryptographic part of the CRISP protocol, to which, in order to process messages, a cryptographic module must be connected, implementing the management of cryptographic keys and performing cryptographic operations in accordance with the CRISP protocol;

• module rtcrisp-crypto-rtpkcs11ecp – implementation of an adapter for connecting the library rtPKCS11ECP as a cryptographic module for rtcrisp.

The rtcrisp module is developed using an object-oriented approach and provides an interface in C language. The entities of the sender and recipient of CRISP messages are identified. Objects of these entities have an internal state that is set during initialization and partially changed during use.

Using the message sender entity, the function of creating a new CRISP message is implemented. When this function is executed, the sequence number of the message is changed and the cryptographic keys for encrypting and counting imitations of message insertion can be regenerated.

Using the message recipient entity, the function of obtaining data from a CRISP message is implemented. Calling this function changes the internal state of the received messages window and can also lead to key regeneration. When retrieving data, the integrity of the message is monitored and decrypted.
In addition, a function has been defined that allows you to extract service fields from a CRISP message without performing message integrity checks.
You can view the full documentation of Rutoken CRISP SDK at this link. IN Rutoken SDK An example of using modules is presented.

Rutoken CRISP SDK modules as part of Rutoken SDK are distributed in the form of binary components assembled for the Windows x86/x64, Linux x86/x64, macOS x64+arm64 platforms. These platforms are selected for demonstration purposes. At the same time, upon request, it is possible to assemble modules for a target platform that embeds Rutoken Module or Rutoken EDS 3.0.

Quality control and compatibility

The functionality added to support the CRISP protocol was tested at various levels. The implementation of changes to the Rutoken firmware is covered by automatic tests that interact with the device at the level of APDU commands; With the implementation of PKCS#11, the set of automatic tests using the device is similarly expanded. The implementation of Rutoken CRISP SDK was covered by unit tests (which was facilitated by its modular architecture) and integration tests (testing of the entire software stack, including access to the device).

The correctness of the implementation of cryptographic mechanisms was verified using test examples contained in the standardization recommendations. To verify the correct implementation of the CRISP protocol itself, cross-testing was performed with the InfoTecs product ViPNet SIES. Cross-testing experience has shown that based on Rutoken EDS 3.0 or Rutoken Module using Rutoken CRISP SDK, a SIES node compatible with ViPNet SIES nodes based on ViPNet SIES Unit.

Conclusion

The described process of adding support for the CRISP protocol can be considered typical for our company. A large group of specialists is involved in the development of new functionality in Rutoken devices: analysts, architects, software developers of various levels, testing specialists and project managers with experience in the field of computer security. The relatively new line of Rutoken Module devices expands the possibilities of using the results of many man-years of work of these specialists in solving the problem of cryptographic protection of processed data in embedded systems. Support for the CRISP protocol is not the limit; it is rather an example of the product’s capabilities and its readiness to adapt to the specific needs of the integrator and customer.