Applying Custom Algorithms in Windows Active Directory Certificate Services

The article presents a solution to the problem of not recognizing the O’zDst 1092:2009 algorithm by the operating system and the problem of using digital certificates generated using the O’zDst 1092:2009 algorithm and O’zDst 1106:2009 algorithm. These algorithms were adopted in 2009. But these algorithms are still not recognized by the operating system. For other cryptographic algorithms used in Windows, cryptographic service providers have been developed that provide cryptographic operation functions to other software. These cryptographic service providers do not support the above algorithms. From here it becomes necessary to develop the cryptographic provider supporting the O’zDSt 1106:2009 hashing algorithm and the O’zDSt 1092:2009 signature algorithm. But to work with digital certificates, one cryptographic provider is not enough. Special extensions are also required to encode and decode digital certificate data. Therefore, the development of an extension for cryptographic providers is given. Also, for managing digital certificates and key lifecycle, a method of integrating cryptographic providers with Windows Active Directory Certificate Services is presented. Developed cryptographic providers are composed of 3 types of providers such as hash provider, signature provider, and key storage provider. The architecture of the key storage provider, a method for secure storage of cryptographic keys, as well as key access control are proposed. The description of the O’zDst 1092:2009 algorithm and the implementation of the functions of the Key storage provider interface are shown. Keywords—O’zDSt 1106:2009 hashing algorithm; the O’zDSt 1092:2009 signature algorithm; active directory certificate services; digital certificate; key access control; key storage provider


I. INTRODUCTION
Electronic digital signature technology is widely used to ensure the integrity and identification of the owner of an electronic document. Presently in Uzbekistan, tools and methods that allow using O'zDst 1092:2009 signature algorithm do not provide document signing, signature validation and key management, through standard interfaces such as CryptoAPI, Cryptography Next Generation API [1] and PKCS [2], [3], [4], [5], [6]. This raises the problem of using the O'zDst 1092:2009 algorithm in information systems, such as not recognizing the O'zDst 1092:2009 algorithm by the operating system, working with digital certificates generated using the O'zDst 1092:2009 algorithm and O'zDst 1106:2009 algorithm. In Windows, cryptographic service providers are used to work with digital certificates, signing an electronic document, checking the digital signature. Starting with Windows Vista, Microsoft is offering a new Cryptography Next Generation API (CNG API) [1] to perform cryptography operations for applications. Microsoft provides several CNG providers that work with CNG API.
The list of CNG providers developed by Microsoft is shown in Table I. It performs operations on key pairs, especially persistent keys. It creates, exports, imports, deletes and stores key pairs. Key pairs generated by the Microsoft Primitive Provider are not persisted, so the Software Key Storage Provider is used for persistent keys.

Microsoft SSL Protocol Provider
It performs key management operations in SSL and TLS. It is used to establish a secure connection using SSL and TLS on Windows.

Microsoft Smart Card Key Storage Provider
It is used to store keys and digital certificates on smart cards. It creates, exports, imports, deletes, and stores key pairs as Software Key Storage Provider, but unlike it stores keys on smart cards.

Microsoft Key Protection Provider
It provides secure storage of keys. Also it allows you to protect content to a group in an Active Directory forest.
Vendors such as "CryptoPro", "Infoteks", "Validata", "Signal-COM" and "Lissi-Soft" develop CNG providers that support both algorithms of international standards and Russian cryptographic algorithms. CNG also offers a mechanism for implementing a new cryptographic algorithm in the operating system. For each algorithm, a separate cryptographic provider is developed, which is registered in the system for a certain class of algorithms. To manage cryptographic keys of digital signature algorithm, the tools, that supports this algorithm, are required. Only some digital signature algorithms support such tools. These tools can be hardware or software.Some implementations of hardware key management provide hardware-level key management ca-PKI uses public key cryptography to identification of electronic exchange participants, control the integrity of information.
A Certificate Authority (CA) is main part of the PKI that issues a certificate to validate the rights of users or systems requesting. It creates the certificate and signs it using the CA private key. Another important part of PKI is the Certificate repository. Certificate repository is a store of valid certificates and certificate revocation lists (CRLs). Applications check the validity of the certificate using the CRL in the repository.
PKI performs the following main functions: 1) Registration is the process of collecting information about a user and verifying its authenticity. 2) Certificate Issuance. Once the CA has signed the certificate, it is issued to the applicant and/or sent to the certificate store. CA affixes a validity period to the certificates, thus requiring periodic renewal of the certificate. 3) Certificate Revocation. A certificate can become invalid before expiration for various reasons: the user has left the company, changed his name, or if his private key has been compromised. Under these circumstances, the CA will revoke the certificate by entering its serial number on the CRL. 4) Key Recovery. A PKI function that allows to recover data or key. 5) Key and certificate Lifecycle Management -maintenance of certificates in PKI, including renewal, recovery and archiving of keys.
All international PKI standards are based on the ITU-T X.509 standard [8], which defines the format of the digital certificate and CRL.
In CNG to manage keys, the key storage providers are used. Windows provides Active Directory Certificate Services (ADCS) for working with key store providers. ADCS is PKI system for Windows clients. ADCS by default works with signature algorithms such as RSA [9], Diffie Hellman (DH) [10], [11], Elliptic Curve Diffie Hellman (ECDH) [12] and Elliptic Curve Digital Signature Algorithm (ECDSA) [13].
Only a key storage provider is not sufficient to perform cryptographic operations. The CNG provides the following types of providers for this purpose: hash provider, cipher provider, asymmetric encryption provider, random number generator provider, secret agreement provider, signature provider, key derivation provider. Applications interact with CNG providers through CNG routers that provide CNG APIs [14]. The CNG API is divided into two groups: 1) BCrypt API -CNG Cryptographic Primitive Functions for cryptographic operations such as hashing, signing and signature verification, random number generation, encryption, asymmetric encryption, key derivation; 2) NCrypt API -CNG Key Storage Functions for working with cryptographic keys and CNG SSL Provider Functions.
Each type of algorithms has its own type of CNG router. Several CNG providers can be implemented for the algorithm.
The organizational structure of this article is as follows. Section 2 refers to related work. Section 3 provides a description of the O'zDSt 1092: 2009 signature algorithm, such as key pair generation, signing, and verification process. Section 4 provides the system architecture of the created ARH Primitive provider and ARH Key Storage provider. Section 5 presents the OIDs of the algorithms and the main parameters of the algorithms. Section 6 describes the implementations of the Key Storage provider interface functions. Section 7 describes the implementations of the Provider extension interface functions. The results will be presented and discussed in Section 8. Finally, Section 9 contains the conclusion.

II. RELATED WORK
A review of Microsoft's next-generation providers and the analysis of their supporting algorithms, types of providers were discussed in [15]. Windows default CNG providers do not support signature algorithm O'zDSt 1092:2009 [15]. The design and implementation of the key storage provider, which provides management keys' life cycle, were discussed in [16]. But the detailed description and integration with the Active Directory certification service has not been discussed. K. Lee and others [17] analyzed the possible vulnerabilities of the CNG library. The structures, functionality, and security issues of CNG have been discussed in [18], [19]. Cryptographic modules are not only developed as a cryptographic provider. The design and implementation of such elliptic curve cryptographic electronic signature systems were discussed in [20], [21], [22], [23]. But such cryptographic modules are not compatible with CNG, and therefore such solutions are not suitable for new custom algorithms. The development of a cryptographic provider for the hashing algorithm and the encryption algorithm was considered in the work [24]. It proposes a method of applying the symmetric algorithm O'zDSt 1105:2009, and the hashing algorithm O'zDSt 1106:2009 to ensure the confidentiality of electronic documents in MS Office. The authors of [25] discussed the development of a cryptographic provider that supports the CryptoAPI interface. They gave a detailed review of the cryptographic transformations of the encryption algorithm O'zDst 1005:2009, presented the architecture and modules of the CryptoAPI provider that they developed. But the CryptoAPI is already being replaced by a more advanced CNG API.
The above works analyze CNG libraries, the security of their key storage, provide a review of CNG API, discuss the development of the Key storage provider and the CryptoAPI provider. But the application of the new algorithm presented in this article in ADCS was not provided, and the problem of not recognizing digital certificates based on the O'zDSt 1092:2009 signature algorithm has not been resolved. Therefore, we created CNG providers that support the above algorithms and provider extensions to address the issue of Windows digital certificates not being recognized. This article presents the architecture of these providers, describes the functions and modules, and proposes a solution to the problem of unrecognizing digital certificates. The standard includes two algorithms for creating and verifying an electronic digital signature. In this article, the first algorithm of the standard is discussed.

A. Definition
The following definitions are defined in the algorithm: M -message to be signed, represented in binary code, arbitrary finite length; p -module, prime number, for software cryptographic module p < 2 1023 ; q -a prime number that is a factor (prime factor) of p − 1, where 2 254 < q < 2 256 ; R -a natural number, parameter; (x, u) -a pair of integers -the private key of the signature algorithm; (y, z) -a pair of integers -the public key of the signature algorithm; (r, s) -a pair of integers -the signature value of M ; H(M ) -hash function that computes the hash value of M ; md -mode of signing; for the mode with a session key md = 1, and for the mode without a session key md = 0. R 1 -an integer number -the control key y 1 -an integer number -the session key B. Special Operations X \e (mod p) -the operation of raising the base x to the power e modulo p with the parameter R. For example, for e = 41.
X * * Y (mod p) -the operation of multiplication of two integer numbers modulo p with parameter R. It is defined as follows: ' X \−1 -the operation of the modular inverse of an integer X modulo p with parameter R. It is defined as follows:

C. Key Generation
Algorithm 1 uses a one-way function in a group with a parameter, which is used in multiplication, exponentiation, and group inversion. Each user of Algorithm 1 has a private key and a public key: 1) (x, u) -private key numbers, randomly or pseudorandomly generated integers satisfying the condition 1 < x, u < q; 2) (y, z) -public key numbers calculated by the formula: where g is a private or public parameter, which is an integer, calculated according to the formula: where: h < p -is a natural number satisfying the condition g ω (modp) ≡ 0, ω in the range of values Step 2: k = H(m + (1 + mR)c) Step 3: if (k = 0) then c = c + 2 and go to Step 2.
Step 16: return {r, s, y 1 } as signature values. Step 1: m = H(M ) Step 2: if L(s) ≤ L(q) and L(r) ≤ L(p) then go to Step 3 else signature is not valid Step 3: z 0 ≡ z \s (mod p) with parameter R Step 4: r ′ ≡ r(mod q) Step 5: y 2 ≡ y \r ′ (mod p) with parameter R Step 6: Step 7: Step 8: if (md = 0) and (m = y 3 ) then signature is valid else if (md = 0) and (m = y 3 ) then go to Step 9, else if (m ̸ = y 3 ) then signature is not valid; Step 9: Step 10: s 1 ≡ sR 1 (mod q) Step 11: Step 12: Step 13: y 4 ≡ y 1 (mod p) Step 14: Step 15: y 5 ≡ y \r1 4 (mod p) with parameter RR 1 Step 16: Step 17: if (g 3 = g 4 ) then signature is valid else signature is not valid IV. SYSTEM ARCHITECTURE Applications for working with cryptographic keys use the key storage provider, for symmetric encryption they use the cipher provider, for hashing data they use the hash provider, for signing and verifying the signature they use the signature provider, etc. In turn, the key storage provider uses the signature provider to generate, export and import keys, sign data and verify the signature. To encrypt data with simmetric algorithms it uses the cipher provider, to compute a hash value of data, it uses the hash provider. Therefore, a key storage provider and a custom algorithm provider were developed to integrate with ADCS. The custom algorithm provider implements three  • GetKeyStorageInterface function • Key storage provider interface functions: The GetKeyStorageInterface function is used by the CNG router to get the address of the Key storage provider interface functions. The function takes the name of the key storage provider as an input parameter. An object of the NCRYPT KEY STORAGE FUNCTION TABLE structure is returned as an output parameter, which stores the addresses of the key storage provider interface functions. Later, the GNG router uses it to call interface functions of the Key storage provider.
The OpenProvider function is called by the CNG router when an application establishes a connection to the key storage provider. The function takes the name of the key storage provider as an input parameter and returns the handle of the provider. This handle serves as an identifier for the current connection. Also, this handle is used as an input parameter in many interface functions. The function initializes a provider object of type ALPKSP PROVIDER and returns provider object addresses as handle of the provider. The CreatePersistedKey function is called by the CNG router when generation of a key pair is required. It takes as input parameters the handle of the provider, the name of the algorithm, the name of the key, the type of key { AT KEYEXCHANGE the key is a key exchange key, AT SIGNATURE the key is a signature key, 0}, as well as a flag indicating the key of the current user or the local computer. If the key was created for the current user, then the user who created the key can use this key. In the case of a local computer, the key can be used by all users of the local computer. This method is often used in service applications. The function initializes a key object of type ALPKSP KEY. The function will not generate key pair, it starts the key generation process of the key pair. Typically, after calling the CreatePersistedKey function, the SetKeyProperty function is used to specify the length of the key, and the value of other parameters. The key generation process ends with a call to the FinalizeKey function. To generate the key pair, the CreatePersistedKey function uses the ARH Primitive Provider through the signature interface and calls the GenerateKeyPair function. The FinalizeKey function is called by the CNG router when an application needs to complete the key pair generation process. The function takes as input parameters the handle of the provider, the handle of the key. This function sequentially calls ARH Primitive Provider signature interface functions such as FinalizeKeyPair and ExportKey. The function encrypts the key blob and stores it on disk. If a pin code is specified, then the key is encrypted using the formula (6): Kp -the encryption key, Kb -the generated private key, E -the O'zDst 1105:2009 encryption algorithm.
The encryption key Kp calculated using the formula (7): pin -the pin code value, H -the O'zDst 1106:2009 hash function.
If the pin code is not specified, then the private key is encrypted using the CryptProtectData function.
The "system" and "hidden" attributes are set for the key file. If the key is applied to the local computer, full permission on the key file is assigned to the System account and the Administrators group, otherwise, to the current user account.
The GetProviderProperty function is used by the CNG router when an application needs to determine the value of the Key storage provider properties.
The GetKeyProperty function is used by the CNG router when an application needs to determine the value of the key properties. The function takes the handle of the key, property name as input parameters and returns the attribute value as an output parameter.
The SetProviderProperty function is used by the CNG router when an application needs to set the value of the Key storage provider properties.
The SetKeyProperty function is used by the CNG router when the value of the key attributes needs to be set. The function accepts the handle of the key, the attribute name, the new value of the attribute as input parameters.
The OpenKey function is called by the CNG router when an application opens an existing key. The function accepts as input parameters the handle of the provider, the key name, the key type, a flag indicating whether the key is for the current user or the local computer. The function initializes the key object of the ALPKSP KEY type from the key file.
The DeleteKey function takes the handle of the key as an input parameter, deletes the key file from persistent storage, and also destroys the key object.
The FreeProvider function is called by the CNG router when an application closes the current connection to the key storage provider. The function takes the handle of the provider as an input parameter, frees the memory occupied by the provider object, which was created when calling the OpenProvider function. It closes the session with the pkcs11 module.
The FreeKey function takes the handle of the key as an input parameter and destroys the key object.
The FreeBuffer function takes a buffer address as an input parameter and frees memory.
The Encrypt function encrypts a block of data. The function uses the ARH Primitive Provider.
The Decrypt function decrypts the data block. The function uses the ARH Primitive Provider.
The ImportKey function imports the key that is exported by the ExportKey function. The function takes a key blob, a key blob type {BCRYPT PUBLIC KEY BLOB -public key blob, BCRYPT PRIVATE KEY BLOB -private key blob} as input parameters, and returns the handle of the key. If the key blob type is BCRYPT PRIVATE KEY BLOB, then it saves the key to a file. The function initializes a key object of type ALPKSP KEY.
The ExportKey function exports the key. The function takes as input parameters, the handle of the key, the key blob type, and returns the key blob through the pbOutput output parameter. The public key blob consists of the key identifier, key version, OID of the key, algorithm parameter values, and public key parameters. The private key blob consists of the key identifier, key version, OID of the key, algorithm parameter values, public/private key.
The SignHash function is used by the CNG router when an application needs to sign data. The function takes the handle of the key, a hash value as input parameters, and returns the generated signature. The function uses the ARH Primitive Provider.
The VerifySignature function is called by the CNG router when the signature needs to be verified. The function takes as input parameters the handle of the key, a hash value, the signature to be verified, and returns the verification result. The function uses the ARH Primitive Provider.
To integrate CNG providers with Windows Active Directory Certificate Services, they must be registered with the CNG router.
Therefore, the ARH Primitive Provider is registered to the hash, signature and cipher interface.
The ARH Key Storage Provider is registered to the key storage provider interface.

VII. IMPLEMENTATION OF INTEGRATION FUNCTIONS
The Provider extension is developed to work with digital certificates. It implements the following callback functions: The The function PFN CRYPT VERIFY ENCODED SIGNATURE FUNC decodes the signature and verifies the signature. The function takes as input parameters the type of encoding, the address of an object of type CERT PUBLIC KEY INFO, which contains the public key, the OID of the signature algorithm, the identifier of the signature algorithm, signature parameters, the identifier of the hash algorithm, hash value, the signature to be verified, and returns the verification result. The function uses the ARH Primitive Provider.
These callback functions are called by the operating system to decode the algorithm OID fields in the certificate and to validate the certificate.
The provider extension is registered in the system using the CryptRegisterOIDInfo function to encode and decode the data of the digital certificate generated using the O' "Dll" = "C:\Program Files\ARHCrypto\ARHCNG\provext64.dll" "FuncName" = "ARHVerifyEncodedSignature".
"ARHVerifyEncodedSignature" is the name of the PFN CRYPT VERIFY ENCODED SIGNATURE FUNC function implemented in the provider extension.

Registered
providers are in the path HKEY LOCAL MACHINE\SYSTEM\ControlSet001\Control \Cryptography\Providers.
The comparison results by supported algorithms of Microsoft CNG providers with the created CNG providers are shown in Table II and Table III. (Fig. ??,  Fig. ??).  This certificate is recognized by Windows that has both the ARH Primitive Provider and the ARH Key Storage Provider installed (Fig. ??, Fig. ??).

IX. CONCLUSION
The architecture of the custom algorithm provider and key storage provider was provided. The description of the key storage provider interface functions was discussed. The implementation of the key storage provider interface functions was presented. The ARH Primitive Provider has been developed which implements the signature interface, the hash interface and the cipher interface, and also supports the O'zDst 1105:2009, O'zDst 1106:2009 and O'zDst 1092:2009 algorithms. The ARH Key Storage Provider has been developed, which implements the key storage provider interface. The ARH Key Storage Provider provides secure storage, use, export and import of national signature algorithm keys. The ARH Key Storage Provider supports storage, export/import of signature keys in PKCS#7 and PKCS#8 formats, as well as generation of PKCS#10 requests for a digital certificate via the CertEnroll API. The description and implementation of the ADCS integration functions were provided. The methods proposed here can be used to apply other signature algorithms that are not supported by the Windows by default.
In addition, these CNG providers provide the ability to use these algorithms in existing information systems that work with other CNG providers. Because they already work with the CNG API to perform cryptographic operations. Sometimes this is achieved with just a few system settings, as a result, it is very easy to apply different algorithms in the system without additional costs and resources.
ACKNOWLEDGMENT I would like to acknowledge the reviewers for their valuable feedback.