RU2633186C1 - Personal device for authentication and data protection - Google Patents

Abstract

FIELD: information technology.

SUBSTANCE: token includes a tunneling setting module and application layer protocol commands and/or communication layer units which encapsulates the data blocks in such a way so that the length of the data block of the communication layer in which tunneling is performed is a multiple of the length of the data blocks of the application and transport layers, or that the length of the application and transport layer data blocks is a multiple of the length of the data block of the communication layer to which tunneling is performed, as well as depending on the data conversion instruction, the token selects the communication layer protocol to which the tunneling is performed in such a way that when the data obtained from the computer is implemented in the volume of the computer, or smartphone by repeatedly executing the same instruction only to check the end result of executing the entire instruction sequence, after completion of each execution of this instruction without checking separately the results of each execution of this instruction.

EFFECT: increased rate of the token data exchange with a computer, tablet or smart phone without reducing the level of information protection.

3 cl, 4 dwg

Description

FIELD OF THE INVENTION

The present invention relates to the field of information security in the framework of computer and telecommunication systems and, in particular, in the exchange of electronic data between providers and users of Internet services (services).

State of the art

To ensure reliable protection of electronic data transmitted over the network channels, as a rule, cryptographic transformations of information are implemented.

Such transformations include data encryption / decryption, creation and verification of electronic signatures (ES) of the parties under specific blocks (packets) of data or entire files and documents, as well as additional hashing procedures (special cryptographically strong compression) of data necessary for implementing these basic transformations, before signing them, as well as generating and storing keys for encryption and electronic signature.

The use of an electronic signature for authentication of electronic data receives a significant expansion of the scope and acquires a significantly higher level of practical significance if the electronic data certified with its help acquire the status of official (electronic) documents within the framework of existing laws and regulations.

Giving electronic data the status of documents within the framework of the current legislation provides for the exact and unconditional fulfillment of all requirements of existing laws and other regulatory acts, in particular, the provisions of the RF Law “On Electronic Signature”. This law, in particular, provides for the full responsibility of the user for the reliable preservation of his private key to create an electronic signature inaccessible to outsiders. It also requires ensuring the correctness of cryptographic transformations — hashing data, creating and verifying electronic signatures, for which the manufacturer of electronic means is directly responsible.

In addition, Article 12 of Federal Law-63 “On Electronic Signatures” requires that a particular electronic signature means to visualize information for a user that is authenticated by his electronic signature. Therefore, developers of modern electronic devices have suggested using specialized compact electronic devices with a screen to visualize signed information (called “Touch Screen type devices”), which are usually connected to a user's computer via a USB connector, to implement electronic technology together with a computer. The simplicity and functional limitations of such a visualization device and its operating system provide some protection against possible infection of the programs executed on it with malware through the network to which the computer is connected.

The use of encryption programs according to any of the classical symmetric methods for protecting data transmitted via communication channels also ensures their guaranteed protection against unauthorized access and changes only if the encrypted method parameters, encryption keys, are kept inaccessible to the attacker.

The use of any of the currently known methods of so-called “asymmetric encryption” (public key encryption) for encrypting large amounts of data, for which the encryption key can be public (public), cannot compete in speed with symmetric encryption.

The requirements of the current laws listed above lead to the fact that in many cases, for users of cryptographic transformations, they do not use programs protected under the control system of a computer, tablet or smartphone, but separate protected hardware devices (modules) connected via a physical or electromagnetic channel to their computers, tablets or smartphones. Physically, they can be executed as hardware tokens, smart cards, Touch Memory tablets, etc.

In the future, to designate any of such external hardware devices (modules), a single term is used - a hardware token or just a token, if it is clear from the context that this is a hardware module.

Such specialized hardware modules (tokens) provide more reliable than in the software modules on the computer, the preservation of private parameters of cryptographic transformations - private keys. However, at the same time, they significantly reduce the processing speed of protected information compared to the implementation of the same cryptographic transformations using application or system software modules on a more powerful main microprocessor device of a user - a computer, tablet or smartphone.

The objective of the present invention is to provide a secure compact personal device (hardware module) for authentication and data protection, connected via a physical or electromagnetic channel to a computer, tablet or smartphone and allowing to increase the rate of token data exchange with a computer, tablet or smartphone without reducing the level of information protection, to to which it is connected.

SUMMARY OF THE INVENTION

The technical result of the invention is to increase the speed of exchanging token data with the computer, tablet or smartphone to which it is connected, without compromising the level of information security.

A personal authentication and data protection device (token) includes a central processor (CPU), random access memory (RAM), non-volatile memory (NVM) connected by a common bus, which has an interface for connecting to a connector used to connect the token to a computer, tablet or smartphone via physical or electromagnetic channel, tuner tuning module for data blocks and application protocol protocol commands and / or communication level blocks. The tunneling tuning module is configured to encapsulate data blocks so that the length of the data block of the communication layer into which tunneling is a multiple of the length of the data blocks of the application and transport layers, or so that the length of the data blocks of the application and transport layers is a multiple of the block length data of the communication level to which tunneling is performed, and is also configured to, depending on the data conversion command, select a gap of the communication level to which tunneling is performed, so that when implementing data tokens received from a computer, tablet or smartphone by repeatedly executing the same command, only check the final result of the entire sequence of commands that make up the conversion completion without separately controlling the results of each execution of this command.

Brief Description of the Drawings

In FIG. 1 is a diagram of the interaction of the parties, illustrating an example of a scenario in which a hardware token is used for secure access via network channels to a remote server of a provider of remote electronic services.

In FIG. 2 shows a block diagram of the top-level architecture of a secure hardware token.

In FIG. 3a shows the levels of the data exchange protocols of the hardware token and the computer or tablet to which it is connected.

In FIG. 3b shows the frequently used protocols of the hardware token and the computer or tablet to which it is connected.

DETAILED DESCRIPTION OF THE INVENTION

According to the interaction pattern of the parties shown in FIG. 1, user 111 has a general-purpose electronic microprocessor device 103 (this may include a personal computer, tablet, smartphone, etc.). It also has a personal hardware device (module) for authentication and data protection 101 (token) connected to it via a physical or electromagnetic channel 105. With the help of the latter transmitted over the channels of the network 107, for example, over the channels of the Internet, the data is protected from extraneous (unauthorized) access and / or change.

The user 111 wishes to access the remote electronic service 113 provided through the remote server 109. Assume for example that the service 113 requires the user 111 to identify himself by providing a name (login) and password.

If user 111 cannot trust a computer, tablet or smartphone 103, believing that there is a great risk that the latter can have programs that can intercept the name and password of user 111 when they are entered from the device’s keyboard (referring to the so-called “malicious programs ”installed in the RAM of a computer, tablet or smartphone), then he must protect himself from this.

Let the user already write down his name and password in the memory of token 101 (or the remote service provider did it for him). In this case, user 111 can command token 101 to transfer the name and password directly to the remote service 113. However, this is also unsafe. Malicious software installed on the computer 103 or somewhere in the path between the token 101 and the remote service 113 (for example, on one or more intermediate nodes of the Internet) can steal the user name and password by intercepting data transmitted on the network.

Reliable ways to protect the data transmitted through the channels of the network 107 from unauthorized access or changes in modern tokens 101 are implemented in the form of cryptographic transformations of the stored and transmitted data.

A general diagram of a hardware token 101 is shown in FIG. 2. Its architecture includes a central processing unit 201 (CPU), random access memory 201 (RAM), non-volatile memory 205 (NVM) connected by a common bus 207 having an interface 209 for connecting to a connector 105 for connecting a token to a computer or tablet 103.

When implementing cryptographic transformations on a separate hardware compact token 101, it is necessary to provide data exchange between a user’s computer or tablet 103 and the connected token 101 according to some of the protocols adopted in the industry of information technology.

As shown in FIG. 3a, there are three main levels of data exchange protocols between application programs executed on a computer, tablet or smartphone 103 and token 101: upper (applied), middle (communication) and lower (transport).

The data exchange protocol between the computer 103 and the token 101, in turn, can be divided into the protocol of the lower (transport) level 305 (for modern tokens, this is usually the USB protocol), the protocol of the middle (communication) level 303 (for modern tokens as a rule, the MSC or CCID protocols) and the protocol of the upper (application) layer 301 (Fig. 3b).

When transmitting data from a computer or tablet 103 to the token 101, the information blocks of the protocol of the upper (application) layer 301 are converted into information blocks (packets) of the middle layer protocol 303 (for example, into CCID protocol packets or MSC protocol packets), and then the latter are converted into blocks information (packets) of the lower (transport) level (USB) 305 and transfer the latter to the token.

In the memory of token 101, the packets of the lower level protocol 305 are converted into packets of the protocol of the middle level 303, and then the packets of data of the protocol of the upper level 301 are restored from them, which are already transmitted directly to the processing by program modules implemented in the token 101. When transmitting data from the token 101 to a computer, tablet, or smartphone 103 produces similar data conversion sequences.

All these transformations of the data packets of the protocol of the upper (application) layer 301 into data packets of the lower (transport) layer 305, and then the inverse transformations of the data packets of the lower (transport) layer 305 to the data packets of the upper (application) layer 301 cause such time delays in the process information processing, which can reduce the speed of receiving data from the token compared to the speed of information processing by the token 101 several times.

For example, if the protocol USB 1.1 or USB 2.0 (full speed) is used as the protocol of the lower (transport) level 305, then the data packet of the lower level has a length of 64 Bytes. If at the same time the widespread CCID protocol is used as the mid-level protocol 303, then its data packet consists of 271 Bytes, of which exactly 255 Bytes make up the data itself.

In this case, to transfer one block of information from 255 Bytes to the token, you have to generate, transmit and wait for confirmation of the correctness of the transfer of each of the five 64-Byte packets via the lower-level USB 2.0 protocol (full speed).

This causes a noticeable decrease in the real speed of receiving data with a token. This process can be visualized as follows:

If the protocol USB 2.0 (high speed) is used as the protocol of the lower (transport) level 305, the packets of which contain 512 Bytes each, then when using the CCID protocol as a medium level protocol 303, the packet contains 255 Bytes of data and an additional 16 Bytes of service information, it is necessary to transfer to the token 101 of each data block of 255 Bytes to transmit on the channel the whole packet of the lower level protocol 305 USB 2.0 (high speed) of 512 Bytes.

This also leads to almost a double loss of the real speed of receiving data with token 101. This process can be clearly illustrated as follows:

Another significant factor that reduces the real speed of receiving and processing information by token 101 is that the most commonly used medium protocol 303 is the well-known CCID protocol that is currently used most often when a user device — a computer, tablet, or smartphone 103 — with tokens 101 is used.

When using it, after the computer sends each packet, the computer, tablet or smartphone 103 expects from the token 101 to confirm the correct reception and processing of this packet by the token 101. In this case, it turns out that the power of the central processor of the token 201 is used very inefficiently, it is forced to “stand idle” while waiting completion of the process of obtaining the next data packet.

With some cryptographic transformations of the information performed by the token 101, one can not expect the token 101 to respond to the processing of each individual medium-level packet 303 without losing data processing reliability. You can only verify the correctness of the transmission and processing by the token 101 of the entire sequence of medium-level protocol data packets that implement the transmission of the whole application layer data block (4KB). Moreover, in some cases, it is possible to verify the correctness of data processing by the token only after the completion of processing of all data transferred from the application layer as a whole.

So, if an error in the transmission or processing of the next packet automatically causes an error in the processing of each subsequent packet, then you can verify the correctness of the transfer of the entire array of information and its processing by token 101 only after completion of the entire process of processing the data array by token 101.

For example, the process of hashing data with a token consists in the sequential execution by the central processor 201 of the following APDU commands:

- hash.init

- N * hash.update

- hash.final

with N-times repeating the hash.update command.

If the number of blocks of sequentially hashed data N is large, then numerous empirical tests for tokens based on common modern microcontrollers show that the delay in waiting for the token to respond to the processing result of each block for tokens with typical modern microcontrollers as their central processor can be about 30% - 40% of the total processing time of the sequence of data blocks with a token.

Therefore, with a small fraction of the erroneously transferred by the computer, tablet or smartphone 103 to the token 101 and processed by the token 101 from the total number of transmitted packets (blocks) of the upper or transport level 305, you can not check the correctness of the execution of each command, but check the correctness of the result only after the entire conversion for example, hashing the entire large block of data of the upper level) with a whole packet of the middle 303 and even the upper (applied) level 301.

This allows us to reduce the total processing time of the entire data array with a token by almost all those 30-40% that are spent in tokens produced and widely used at present to wait for the result of the token processing of each individual data packet of the lower level.

This process of including or “encapsulating” packets of one protocol in packets of another protocol of the same or higher level is called tunneling in the field of open system interaction protocols (OSI) (see GOST R ISO / IEC 7498-1-99. - “OSI. Basic reference model. Part 1. Base model. ”- ACS: 35.100.70. - Effective from 01.01.2000. - 62 p. [1]) and is usually used to increase the reliability of data transfer or to protect it using encryption. However, tunneling can be used for various protocols of the same level, as well as not for all packets transmitting control commands and data, but only for those protocol and data commands that allow to speed up the process of exchanging data between a computer and a token with their processing on token processor.

For example, if you encapsulate CCID mid-level protocol packets into packets of another MSC mid-level protocol packet, as well as PC_to_RDR_XfrBlock, RDR_to_PC_DataBlock commands, then the process of transferring to a token and processing a 4KB application layer block is reduced by encapsulating 17 CCID protocol blocks into 9 MSC protocol blocks, which are transmitted and processed on the token processor 30-40% faster than this without such tunneling of commands and data. This process can be visualized as follows:

Moreover, if the hardware implementation of the token is configured in such a way that it can only receive data via the CCID protocol, then the tunneling module unencapsulates the received MSC protocol data blocks into CCID protocol blocks. Also, if necessary, the tunneling module unencapsulates the received data blocks from the application layer protocol into which the tunneling was performed, into the application layer protocol suitable for the token.

When performing cryptographic transformations such as hashing large amounts of data (long strings) from N 4KB blocks, each of this process of reducing the data exchange time between the token and the main device (computer, tablet or smartphone) can be schematically depicted as follows:

That is, with a high reliability of the data exchange channel between a computer, tablet or smartphone and a token directly connected to it via a physical or electromagnetic channel, and it, as a rule, is quite reliable in modern devices, it is possible to check the correctness of the hashing process only at its very end, which can significantly reduce the processing time of the entire sequence of data packets.

A similar technique can be applied when encrypting data with a token in the mode of gamming, gamming with feedback or the mode of generating an insert (according to the standards for data encryption GOST 28147-89 and GOST R 34.12-2015).

In this case, it is also possible not to check the correct execution by token 101 of each individual encryption command of the transport protocol data block 305, but to control only the correctness of the transfer to the token and encryption of the whole block (packet) of the protocol of the upper (application) layer 301 or the whole block (packet) of the protocol middle (communication) level 303.

Thus, if for the implementation of cryptographic transformations of information during user authentication and / or authentication of individual data blocks, as well as when protecting data with encryption, use a personal external hardware module (token) 101:

- which is connected to a computer, tablet, or smartphone of user 103 via a physical or electromagnetic channel 105 (this may be a physical USB connector, electromagnetic channels NFC, Bluetooth, etc.);

- for which the protocol for exchanging data with a computer is divided into a protocol of the upper (application) level 301, a protocol of the middle (communication) level 303 and a protocol of the lower (transport) level 305;

- in which packets of the upper (application) layer 301 or packets of the protocol of the middle (communication) level 303 can be encapsulated in another protocol of the same level with a packet length that is a multiple of the length of the packets of the upper (application) 301 and lower (transport) layer 305;

- for which a protocol is used as a medium-level protocol for exchanging data 303 with computer 103, which allows information to be converted in token 101, providing for the multiple execution of the same command, without waiting for the result of each copy of this command, but only for the result of the entire sequence the commands that make up the whole transformation

then without reducing the security level of information protected by encryption and without reducing the reliability of user and data authentication with an electronic signature, the data processing speed with the help of such a token will be significantly increased compared to the similar use of hardware tokens produced and currently used.

For example, let a personal authentication and data protection device (token) 101 be connected to the personal computer of the user 101 directly through the USB connector 105.

Let the application software module on the computer 103 to control the exchange of data with the token 101 process the data in such a way that the data in the computer 103 from the upper (application) level 301 is fed into the protocol of the middle (communication) level 303 in 4 KB blocks. This is a very common option for converting and transmitting data at the application level in modern computer networks.

Suppose that packets are encapsulated in packets of the protocol MSC (Mass Storage Communications) widely used in the world with a data block length of 512 bytes in the protocol of the middle (communication) level 303.

As the protocol of the lower (transport) level 305, let us use the widespread USB 2.0 protocol (high speed) also with a data block length of 512 bytes.

Then the maximum consistency of the lengths of the protocol blocks of the middle 303 and lower 305 levels means their equality.

The data token transformation, which consists in repeatedly executing the same command, is data hashing (according to Russian hashing standards GOST R 34.11-94 or GOST R 34.11-2012 or international standards SHA-1, SHA-256, SHA-3) with repeating repeatedly by the hash.update command, the result of which is not controlled by the mid-level protocol 303.

As a specific example of the implementation of the proposed technical solution, we can consider the following device (token), connected via USB to a computer or tablet. A personal authentication and data protection device made in the form of a hardware token, including a central processor (CPU), random access memory (RAM), non-volatile memory (NVM) connected by a common bus that has an interface for connecting to a connector used to connect the token to a computer, a tablet or smartphone via a physical or electromagnetic channel, in which data in a computer from the upper (applied) level is transmitted to the protocol of the middle (communication) level in 4 KB blocks, medium-level protocol packets they are encapsulated (tunneled) into packets of the MSC protocol (Mass Storage Communications) with a data block length of 512 bytes, the USB 2.0 High Speed protocol is also used with a data block length of 512 bytes as a protocol of the lower (transport) level, and as a data conversion with a token, which consists in executing the same command repeatedly, hashing the data with the hash.update command repeated many times, the result of which is not controlled by the MSC protocol (Mass Storage Communications) until the completion of the entire sequence NOSTA hashing command during the processing of all the top-level block or even the entire sequence of blocks of information data.

A personal authentication and data protection device can be connected to a microprocessor device with a screen (device like Touch Screen) to visualize the information transmitted for processing through a USB connector or via an electromagnetic channel.

A smart card can be used as a token, and the connector with a computer, tablet or smartphone is a smart card reader connected to a computer, tablet or smartphone via a USB reader through a physical or electromagnetic channel or built into it.

Also, a personal authentication and data protection device, made in the form of a smart card, can be connected to a microprocessor device with a screen for visualizing the information transmitted for processing, which also contains a built-in smart card reader.

In another example implementation, a personal authentication and data protection device can be made in the form of a microprocessor device with a screen for visualizing information transmitted to the processing connected to a computer, tablet or smartphone via a USB connector or via an electromagnetic channel.

Claims (3)

1. Personal authentication and data protection device (token), including a central processor (CPU), random access memory (RAM), non-volatile memory (NVM) connected by a common bus, which has an interface for connecting to a connector used to connect the token to a computer, tablet or a smartphone via a physical or electromagnetic channel, a tuner for configuring the tunneling of data blocks and application level protocol commands and / or communication level blocks, configured to encapsulate protocol data blocks so that the length of the data block of the communication layer into which tunneling is performed is a multiple of the length of the data blocks of the application and transport layers, or so that the length of the data block of the application and transport layers is a multiple of the length of the data block of the communication layer into which the tunneling is performed, and also made with the possibility, depending on the data conversion command, the token to select the protocol of the communication level to which tunneling is performed, so that When implementing in the token the transformations of data received from a computer, tablet or smartphone by repeatedly executing the same command, check only the final result of the entire sequence of commands that make up the conversion, upon its completion, without separately controlling the results of each execution of this command. 2. A personal authentication and data protection device according to claim 1, characterized in that the token is a smart card, and the connector with a computer, tablet or smartphone is a smart card reader that connects to a computer, tablet or smartphone via a USB reader by physical or electromagnetic channel or built into it. 3. A personal authentication and data protection device according to claim 1, characterized in that the token is a microprocessor device with a screen for visualizing the information transmitted for processing, connected to a computer, tablet or smartphone via a USB connector or via an electromagnetic channel.

Images