Using MS CRYPTO API in Caché

Speaking of databases as sources of knowledge, we always mean that it is not only a large warehouse of diverse, orderly (or not) information, but also a place for its safe storage. Security, as a rule, means the protection of digital data from unauthorized access during transmission via communication channels, but do not forget about the physical protection of data carriers. Nevertheless, I will not argue which armored doors should be placed in your server room and how many guards should be on duty at the checkpoint, but I will tell you about cryptography.

Cryptography, in the broadest sense of the word, is the science of methods for ensuring the confidentiality and authenticity of information. That is, it ensures the impossibility of reading your data by strangers, as well as the impossibility of secretly replacing data with third parties. Over the past four thousand years, scientists, engineers and other figures have developed many ingenious encryption devices and mechanisms, which are now replaced by one computer. Therefore, all the current variety of means of cryptographic protection of information (SKZI) is provided by a variety of algorithms, which are invented by many.

Attention, question! How can a developer, far from cryptographic wisdom, ensure data protection in each specific application? Do I need to invent my own ingenious encryption algorithm, or can I use a SKZI written by someone else, and if so, how? Fortunately, there is no need to reinvent the wheel. You can, for example, use a single software interface - MS CryptoAPI. It describes a wide range of cryptographic functions and algorithms that can be implemented by different ICTD development companies (also called cryptographic providers or CSP - Cryptography Service Provider) in their own way, but using a single API to access them.
To implement cryptographic functions in your application, do the following:

• First, decide which cryptographic algorithms you want to use. The choice may depend on the reliability of the cipher, on the speed of work, on the length of the key, or it may simply be registered in the technical assignment.
• secondly, to find which crypto-provider this algorithm has been implemented, certified and cheaper.
• thirdly, to become the happy owner of the license package for the SKPI and install it on your server.
• and, fourth, write in your solution a module that allows you to call the functions of the MISP to work inside the application.

The task I set for myself was to go through each of the listed steps, and, as a result, to get a solution that allows Caché to access the MS Crypto API functions.
Having studied the proposed approach, it is easy to find that it has two huge advantages:

• we do not need to study the device of polynomials to form our own algorithms for encrypting, hashing or signing data
• Many CPSPs are already certified according to GOST, and for many companies-customers, especially state ones, this is one of the most important requirements.

There is also one “small” minus - CryptoAPI works exclusively under Windows.

Suppose that the pros have inspired us, and the minuses did not disappoint, but the task is quite specific - to find an approach to using the functions of CryptoAPI for working with the Caché DBMS. Let, CSP is already installed and configured: how to work with it from Cach? One option is to use the Callout mechanism which is implemented in Caché. About him further and will be discussed.
')
Callout is intended for calling Caché functions from DLLs. In fact, this means that you can create code, for example in C ++, build it into a DLL, and then use it in your solutions. Also, this approach allows you to use when creating a DLL a variety of features of the Windows API, in particular, CryptoAPI.

At the planning stage, I immediately decided to create not only the DLL itself (it will be called ISCAPI), but also a testing and debugging tool (CryptoConsole).

The figure below shows this graphically. There is a base class CacheCommon ( ++), which implements functions that allow you to configure a crypto-provider, initialize the SKZI, get the context, keys, hashing data, create and verify a digital signature, encrypt, logging and much more. All these functions are consistently used in the debugging console and library (the console and DLL are written in C ++). A single form of calls plays a special role, because the DLL in Caché is very problematic to debug, so the main part of the load during development, debugging and testing lies on the console. The code for the entire solution is open, you can find it here .



On the server side, Caché interacts with ISCAPI.DLL through the iscapi.Signer class.



Here the callout mechanism is implemented, which means that you can directly access the CryptoAPI functions that exist in the DLL from the Caché class methods. Access is implemented through a call to the iscapi.Signer class method from the Caché Object Script. Among other things, it is also a cognitive example for novice developers, allowing to grasp the peculiarities of working with external libraries from Caché.

Now I want to say a few words about the functions that have been implemented. The most convenient way is to check them from the console application (CryptoConsole.exe). Immediately after its launch you can see all available commands and the order of their call. To enter parameters for a function, simply list them, separated by a space. Long parameters consisting of several words, as usual, are framed with quotes.
Console commands can be divided into three types:
1. Service teams
A typical example is the help command, which lists all the available commands in the process. The service also includes the showProviders and showProvParams commands that display the data on the crypto-providers installed in the system to the user.
2. Initialization commands
Initialization commands are needed to configure and run a crypto-provider. In general, to initialize its context, you need to specify:

• crypto provider type number (provID command). This number, which means almost nothing, but helps the system identify which CSP you want to work with.
• algorithm number (signAlgID command). Generally speaking, there may be several algorithms, in this case it is advisable to specify a hashing algorithm and data signing.
• key container name (contName command).
• PIN from key container (command contPIN). The key container settings are made during the installation and configuration of the crypto-provider.
• full name of the used CSP (command provName). This is usually a long string. It is necessary for the system to understand with which crypto-provider we are going to work with, and is an addition to the type of CSP that cannot uniquely identify it alone.

There are additional parameters that can be set to the system, such as encryption algorithm codes, but these five are necessary for the initial initialization of the CSP.
3. Cryptographic commands
When the CSP is initialized, we need to get the context of the crypto-provider (aContext command), and after that we can create hashes, sign data, encrypt - that is, do everything that this package was created for.
Basic commands:

• hashData, hashes the data string
• hashFile, hashes the data file
• signCurrentHash, signs current calculated hash
• signNewHash creates a new hash in the system and signs it.
• verifyHash, verifies that the signature matches the hash
• verifySignature, verifies the compliance of the signature with the original data
• encryptData, encrypts data in the string
• decryptData, decrypts previously encrypted data.

The list of commands is actually much wider than is shown here. And it's not just that the application is constantly under development. When debugging and testing, it is very advantageous to write temporary function scripts that call several related procedures in succession, check the final result, or initialize the CSP with values ​​pre-defined in the code.
As a rule, these functions are rarely documented, but if you look at the application code - they are striking.

If you want to add new functions, first implement them in CacheCommon, test using the console application, then add them to the DLL, and finally, access them through iscapi.Signer. Functions in the dynamic library should be called the same as in the console application. Please note that the DLL code in the "ZFBEGIN ... ZFEND" block necessarily contains an enumeration of all the available procedures.

The set of functions that are currently implemented is small, but I did not set the task to do absolutely everything. Already, you can create a hash of data, sign them and verify the digital signature. At least there is a basis which, which will allow every interested developer to quickly set up a cryptographic provider, initialize its context and start using it. Adding new functions will not take much time, since it is performed by analogy with existing ones.
I want to invite all Caché-developers to use the results of my project, and also to take part in its development.