Analysis of Key Storage Mechanism of Asymmetric Key-Related Functions in CNG Crypto Library

Abstract

During the implementation of a crypto system, distributed cryptographic libraries are unable to endure situations where the execution environment rapidly changes because of a structural vulnerability that is by design. For this reason, Microsoft announced a CNG library to solve this problem; however, the CNG does not comprise verification tools regarding the execution results for developers, users, or experts to assess the crypto system. In addition, the CNG design means that it is difficult to ensure that the encryption or decryption keys can be found in real-time processing because almost all cryptographic functions are processed by handles. This paper analyzes the way that key information is found to assure the security of the implemented products or to debug them in the development process. For this reason, we analyze the key storage mechanism of asymmetric-key-related functions in the CNG library. This study provides more convenient ways to identify key-related information, such as debugging and evaluation, when a crypto system is implemented using the CNG library.

1. Introduction

Data protection technology using cryptography is an essential element for e-commerce, privacy protection, etc. [1,2,3]. Many organizations and companies have deployed cryptographic libraries to support the implementation of cryptographic systems, and these are often referred to as cryptographic APIs. There are many kinds of cryptographic libraries, and the current representative industry cryptography libraries are PKCS#11 of RSA and CAPI of Microsoft, which are applied to various cryptographic application systems. In particular, the industry needs to satisfy these requirements for hardware-dependent products, such as smart cards, USB tokens, and hardware security modules, because hardware security products require interoperability with cryptographic libraries. However, PKCS#11 and CAPI were designed without considering scalability, so this causes a problem for the development of a new library when new requirements are met. In the case of PKCS#11, this can be extended in various ways due to the source code being open to the public. Nevertheless, excessive transformation causes a problem. In the case of CAPI, it provides an SCP structure for scalability. However, CAPI also has problems in terms of cost and reliability since this is not a plug-in method provided in the existing infrastructure [4,5].

Thus, early-developed and relatively distributed existing libraries do not keep up with the diversification and rapid change in the execution environment, including the hardware platform, operating system, etc. This problem is caused by structural problems in library design. In particular, Microsoft has dominated the commercial operating market, and its operating system was rapidly upgraded to Vista, Windows 7, and Windows 8 in a short period of time, which led to the agility of CAPI. Microsoft released Cryptography API: Next Generation (CNG) to solve this problem [6]. CNG supports the latest cryptographic algorithms, kernel mode, and audit functions as a next-generation cryptographic library, and in particular, to compensate for the disadvantages of CAPI, agility is provided as the most important feature to flexibly cope with new requirements or environmental changes [7].

On the other hand, there is no verification tool to verify execution results for developers, users, or cryptographic system engineers using CNG. Moreover, CNG has difficulty proving keys in real-time processing because it performs functions through a handle that deals with cryptography-related operations, such as encryption and decryption [8]. Accordingly, it is necessary to trace the position where the encryption and decryption keys are stored from the handle so that the information about the key used for encryption and decryption can be confirmed. However, sufficient research of this kind has not previously been reported. Therefore, in this paper, we analyze the key storage mechanism in the NCrypt library of the CNG library. In detail, this is a study on the method for checking key information in real-time processing of the implemented program to verify the safety of the implemented product and debugging during the development process. To perform this, we analyze the programming techniques that utilize the CNG library and implement sample programs based on the analysis results. After that, we also analyze the key storage mechanism by reverse engineering based on the implemented programs. Finally, in this paper, we propose a method to verify the keys used by developers in real-time processing.

2. Background/Related Works

2.1. CNG Structure

To compensate for the disadvantages of CAPI, which has limitations in coping with rapidly changing environments, the proposed CNG replaces all existing cryptographic primitives. Moreover, it both supports all the cryptographic algorithms from CAPI and provides new algorithms. Hence, the developer can more actively intervene in how to perform various functions and how to provide various functions by using CNG in a complex manner. Thus, a more flexible design structure is supported. Figure 1 shows the overall structure of CNG [7,9].

CNG provides cryptographic primitives related to random number generators, hash functions, signatures, and keys, and the core of its structure is BCrypt. NCrypt provides key storage to support hardware, such as asymmetric keys and smart cards; the B in BCrypt stands for base, while the N in NCrypt stands for new. These names come from the header or DLL filename in the development environment provided by CNG. In addition, CNG provides a framework to support user and kernel modes, unlike existing cryptographic libraries (BCrypt) or where the key storage feature is only supported in user mode (NCrypt).

There are two main perspectives on the cryptographic primitive provided by CNG. The first perspective considers CNG as a collection of local objects that provide queryable and changeable properties along with methods. These objects include algorithm providers, hash functions, keys, and a secret agreement. Additionally, random number generation is processed internally by the algorithm provider, while all others are provided by the key. Here, the key can be expressed in a symmetric or asymmetric form and is used to perform or verify a hash signature. The hash and key objects are obtained from the algorithm provider, and the secret agreement is obtained from the key object pairs. The second perspective is to regard CNG as a software router or intermediary for cryptographic operations. For example, when implementing a particular hash algorithm, CNG can be implemented using a hash interface without excluding hard coding because the API of CNG is built on a set of logical cryptographic interfaces. Most cryptographic APIs use an algorithm-centric approach. However, in the case of CNG, because it uses an interface-oriented approach, it is possible to quickly cope with the problem by providing better agility to the developer and to the application manager, who needs to replace the algorithm that is found to be defective in the application.

2.2. CNG Features

CNG provides key features, such as cryptographic agility, compliance with federal standards, support for Suite B, kernel mode support, and auditing, and its characteristics are as follows [7,9]:

• Cryptographic agility

One of the key values provided by CNG is cryptographic agility, which is termed cryptographically agnostic. Agility is demonstrated in the conversion of protocol implementations, such as SSL/TLS, CMS, IPSec, and Kerberos, to CNG; in fact, CNG had to replace all algorithm types, such as symmetric key, asymmetric key, hash function, random number generator, and other useful functions. Changes at the protocol level are considered very important because, in many cases, the protocol APIs needed to provide options for algorithm selection or other flexibility were not available.

• Compliance with federal standards

The goal of CNG is level 2 certification from the Federal Information Processing Standards 140-2 along with the Common Criteria for a specific platform, while the goal of other platforms is level 1 certification. These platforms perform the same CNG implementation but provide different authentication levels.

• Support for Suite B

One of the other important features is that it supports the Suite B algorithm. In February 2005, the U.S. National Security Agency released a well-organized set of cryptography called Suite B for use by the U.S. government, including symmetric key cryptography, secret agreement of the asymmetric key, known as key exchange, digital signatures, and hash functions. The U.S. government announced that the certified Suite B implementation is to be used to protect information classified as top-level confidential and personal information that was previously described as sensitive but unclassified (SBU). Therefore, supporting Suite B is very important both for Microsoft and for application providers and SI companies.

• Kernel mode support

CNG supports flexible cryptographic functions by using the same APIs in both the kernel and user modes. SSL/TLS and IPSec using CNG are added to the boot process and executed in kernel mode, but not all CNG functions are executed in kernel mode. All CNG functions can be called if the IRQL of the calling process is set to PASSIVE_LEVEL, except for the functions that are declared not callable in kernel mode. Ksecdd.sys, the Microsoft kernel security support provider interface, is a general-purpose software-based cryptographic module that resides at the Windows kernel mode level. This driver runs as an export driver in kernel mode and provides cryptographic services using a public interface for kernel components; however, exceptionally, the DSA algorithm does not support this. CNG does not provide the ability to always add algorithms or providers in kernel mode, while only the implementations that Microsoft provides through kernel mode APIs are supported in kernel mode.

• Auditing

In addition to providing the above security functions, many operations occurring in the CNG layer are audited by a key storage provider of Microsoft in order to satisfy some requirements of the Common Criteria. As a guideline, KSP must audit and generate audit records in the security log.

• Failure of key and key-pair generation with self-test failure.
• Importing and exporting keys.
• Key revocation failure.
• When a persistent key is read from and written to a file.
• Failure of a key-pair consistency check.
• Failure of secret key validation, such as a parity check on a 3-DES key.
• Failure of encryption, decryption, hash function, signature, verification, key exchange, random number generation, etc.
• Cryptographic self-diagnosis.

2.3. CNG Programming Technique Analysis

The following typical steps are required to implement the CNG API [7,9]. To program with the CNG API, the following steps are typically needed: a BCryptOpenAlgorithmProvider function to open the algorithm provider; a BCryptGetProperty or BCryptSetProperty function to obtain or set the property of the algorithm, respectively; a BCryptGenerateSymmetricKey or BCryptGenerateKeyPair function for key generation; a BCryptImportKey or BCryptImportKeyPair function for importing the key; a BCryptExportKey function for exporting the key; a BCryptEncrypt or BCryptDecrypt function to perform cryptographic operations; and a BCryptCloseAlgorithmProvider function to close the algorithm provider [7].

• Open the algorithm provider with the BCryptOpenAlgorithmProvider function.
• Obtain and set the algorithm properties with the BCryptGetProperty and BCryptSetProperty functions.
• Generate and import the key with BCryptGenerateSymmetricKey and BCryptGenerateKeyPair for key generation and BCryptImportKey and BCryptImportKeyPair for importing the key.
• Perform cryptographic operations with the BCryptEncrypt and BCryptDecrypt functions.
• Close the algorithm provider with the BCryptCloseAlgorithmProvider function.

For this paper, we analyzed the programming method of asymmetric key cryptography among the features of CNG, such as algorithm provider, random number generation, hash function, symmetric and asymmetric key cryptography, and signature and verification features, based on the above steps [10,11]. In this paper, we describe asymmetric key cryptography.

Asymmetric key cryptography solves the sharing problem of initialization vectors and secret information by using a public key scheme that maintains a private key and a public key, where the public key is open to anyone. The key pair is used to decrypt the cipher text, which is encrypted with the public key, using the corresponding private key. To realize this feature, there is a price. When comparing the calculation amounts, asymmetric key cryptography is known to be considerably different from symmetric cryptography. However, it is very useful for communication because it includes a structure to mutually share secret key information. Figure 2 shows the procedure for asymmetric key cryptography.

3. Methodology

3.1. Research Question

As described above, the CNG cannot obtain information on the actual key because it is not directly receiving the key information during the encryption and decryption processes due to the fact that the key is processed through the handle obtained from the import and export processes (Question 1). Thus, when given the handle address of a key, the goal of this paper is to analyze the location of the actual key from the key handle address, namely to analyze the key storage mechanism (Question 2).

The functions related to encryption and decryption in CNG are classified into BCrypt, SSL, and NCrypt. The encryption and decryption functions of BCrypt are called BCryptEncrypt and BCryptDecrypt, respectively. The encryption and decryption functions of SSL are called SslEncryptPacket and SslDecryptPacket, respectively. The encryption and decryption functions of NCrypt are called NCryptEncrypt and NCryptDecrypt, respectively. In this paper, we analyze the key storage mechanism of NCrypt and the asymmetric-key-based RSA algorithm.

The analysis environment is based on Intel^® Core™ i5-2410M CPU 2.30 GHz, 4 GB RAM, a PC installed with Microsoft Windows 7 Home Premium K operating system, CNG SDK 2.0, Windows SDK 7.1, and .NET Framework 4 installation, Visual Studio 2005 to implement proof-of-concept tools, CNG Demo Sample Code installation for CNG sample source code reference, and OllyDbg v1.10 reverse engineering tool to analyze the key storage mechanism.

To analyze the key location in NCrypt-related functions, we first implemented a sample program based on the RSA algorithm where the plain text is “SignThis” and the key is “test2” by referring to the example of Windows CNG Demo Sample Code. As a result, the implemented program executes encryption and decryption operations, as shown in Figure 3, and outputs the result, as shown in Figure 4.

To analyze the key location, we confirmed the related parameters of the NCryptDecrypt function after setting a breakpoint on the NCryptDecrypt function. As a result, we found that the first parameter is the address associated with the key handle, as shown in Figure 5. Nevertheless, there was no specific information related to the key, as shown in Figure 6, after checking the key handle address 0x0051A288 in detail.

Since there is no way to obtain key-related information through the key handle address, we, therefore, derived clues about the key location by checking the key-related information when the key is loaded.

Figure 7 analyzes the key-related parameters after setting a breakpoint on the NCryptImportKey function and shows that the sixth parameter stores the key information, while the seventh parameter stores the key size. The sixth parameter for storing the key information is the address 0x004BE880, and it stores a value that starts with “RSA2”, as shown in Figure 8. Nevertheless, Figure 9 shows that as a result of inferring the location from the key handle based on the key information when the key is loaded, the exact location could not be analyzed (response to Question 1).

3.2. Key Storage Mechanism Analysis

We considered that it was difficult to analyze the location of the NCrypt key based on the above result. Hence, after analyzing the location of the keys in BCrypt, the NCrypt key location was analyzed by deriving clues to key locations.

First, the BCrypt sample program was implemented based on the decryption key information utilized by NCrypt to derive the key structure difference between NCrypt and BCrypt. Figure 10 shows the program flow of the BCrypt sample, while Figure 11 shows the execution result.

To derive the key structural differences between NCrypt and BCrypt based on the implemented sample code when importing the NCrypt key into BCrypt, Figure 12 compares these structures and shows their structural differences.

The Magic of NCrypt starts with “RSA2”, while BCrypt starts with “RSAk”, and the size and information contained inside are also different.

Figure 13 analyzes the key location for the RSA algorithm in BCrypt, the result of setting a breakpoint on the BCryptDecrypt function. The breakpoint address is 0x00414DE8, and the key handle address is 0x0051BF70.

Inside the BCryptDecrypt function, the address that is a value (0x1E) of the address (0x051CB30) obtained by adding 0x90 to offset 0x08 from the key handle address is pushed, and the other function is then called. The function called here is a function to check the value (0x1E) obtained by adding 0x90 to offset 0x08 from the key handle address. The address of the breakpoint is 0x72AB6B29, and Figure 14 shows the result of the breakpoint being set.

If the value 0x1E of the address obtained by adding 0x90 to the address 0x8 from the key handle address is successfully confirmed, another function is called after pushing the address (0x0051BF70), which is the address of offset 0xC from the key handle address. The address of the breakpoint is 0x72AB192B, and Figure 15 shows the state where the breakpoint is set. Inside the function, another function is called after pushing the address (0x0051BF70), which is again the address of offset 0xC from the key handle address. The function called here is a function that checks Magic (“KRSM”). The address of the breakpoint is 0x72A9A4B5, and Figure 16 shows the result of setting the breakpoint.

When Magic is confirmed, a specific function is called after pushing 0x100, and the function called here is a function that allocates memory. The address of the breakpoint is 0x72A9A512, and Figure 17 shows the result of setting the breakpoint. When the memory is allocated successfully, the function is called after pushing a value of the address of offset 0x18 of the address of offset 0xC of the key handle address and the cipher text. The address of the breakpoint is 0x72A9A542, and Figure 18 shows the result of setting the breakpoint.

Inside the function, the code compares the “RSAK” of Magic for the key handle. The address of the breakpoint that compares the Magic to the key handle is 0x72AA0E89, and Figure 19 shows the result of setting the breakpoint. If the Magic of the key handle is confirmed, the memory allocation function is called after pushing eax. The address of the breakpoint is 0x732A0EE2, and Figure 20 shows the result of setting the breakpoint.

If the memory is successfully allocated, the internal function is called after pushing the edi, 0x0B, and address of the cipher text, and the internal function copies the cipher text in reverse to the allocated memory. The breakpoint address is 0x72AA0F13, and Figure 21 shows the result of setting the breakpoint. When the cipher text is copied successfully, the internal function is called after pushing the address to which the cipher text is copied to the allocated memory, 0x20, the address assigned to the memory address by adding 0x100, and the address of offset 0x50 of the address of offset 0xC of the key handle address (0x005BBFF0). The address of the breakpoint is 0x72AA0F58, and Figure 22 shows the result of setting the breakpoint.

Inside the function, the internal function is called after pushing the address to which the cipher text is copied to the allocated memory, 0x20, the value of edi by adding 20, the address of offset 0x80 of the address of offset 0x0C of the key handle address (0x005BCDB0), and 0x10. The internal function is a function that compares constant values. The breakpoint address is 0x72A7E57C, and Figure 23 shows the result of setting the breakpoint. After that, the memory allocation function is called after pushing 0 and 0x10. The breakpoint address is 0x72A88F48, and Figure 24 shows the result of setting the breakpoint.

When the memory is allocated, the internal function is called after pushing the allocated memory, 0, the address of offset 0x64 of the address of offset 0xC of the key handle address (0x005BC004), 0x10, the address of offset 0x70 of the address of offset 0xC of the key handle address (0x005BCDB0), 0x20, and the address to which the cipher text is copied to the allocated memory. The breakpoint address is 0x72A88F67, and Figure 25 shows the result of setting the breakpoint. Inside the function, the code copies the address of the cipher text to the allocated memory backward by 4 bytes. The breakpoint address is 0x72A9075A, and Figure 26 shows the results of setting the breakpoint.

After copying the cipher text backward by 4 bytes, the internal function is called with the copied address of the cipher text from offset 0x40 of the allocated memory, the address of offset 0x70 of the address of offset 0x0C of the key handle address (0x005BCDB0), and 0x10. The address of the breakpoint is 0x72A9076D, and Figure 27 shows the result of setting the breakpoint. Inside the function, the code loops around and performs the operation using the value of the cipher text from offset 0x40 of the allocated memory and the address of offset 0x70 of the address of offset 0x0C of the key handle address (0x005BCDB0). A total of 20 loop operations are performed. The breakpoint address is 0x72A7D71F, and Figure 28 shows the result of setting the breakpoint. These operations are performed eight times in total, and the cipher text is decrypted based on the operation result. A total of eight operations are performed by those four operations being called twice, and Figure 29 shows the first calling process, which is the calculation process. The information used in the operation is the copied value of the cipher text backward and the address of offset 0x70 of the address of offset 0xC of the key handle address, and the address of the breakpoint is 0x72AA0F58.

When the first operation is completed, the second operation is performed using the result of the first operation, the address of offset 0x70 of the address of offset 0xC of the key handle address, and the address of offset 0x40 of the address of offset 0xC of the key handle address. The breakpoint address is 0x72AA0F6F, and Figure 30 shows the result of setting the breakpoint. When the second operation is completed, the third operation is performed using the result of the second operation, the address of offset 0x70 of the address of offset 0xC of the key handle address, and the address of offset 0x48 of the address of offset 0xC of the key handle address. The breakpoint address is 0x72AA0F85, and Figure 31 shows the result of setting the breakpoint.

When the third operation is completed, the fourth operation is performed using the result of the third operation and the address of offset 0xAC of the address of offset 0x0C of the key handle address. The breakpoint address is 0x72AA0FA3, and Figure 32 shows the result of setting the breakpoint. When the fourth operation is completed, the fifth operation is performed so that the first operation is performed again using the result of the third operation and the address of offset 0xAC of the address of offset 0xC of the key handle address. The breakpoint address is 0x72AA0F58, and Figure 33 shows the result of setting the breakpoint.

When the fifth operation is completed, the sixth operation is performed using the result of the fifth operation, the address of offset 0xAC of the address of offset 0xC of the key handle address, and the address of offset 0x44 of the address of offset 0xC of the key handle address. The breakpoint address is 0x72AA0F6F, and Figure 34 shows the result of setting the breakpoint. When the sixth operation is completed, the seventh operation is performed using the result of the sixth operation, the address of offset 0xAC of the address of offset 0x0C of the key handle address, and the address of offset 0x4C of the address of offset 0xC of the key handle address. The breakpoint address is 0x72AA0F85, and Figure 35 shows the result of setting the breakpoint.

When the seventh operation is completed, the eighth operation is performed using the result of the seventh operation and the address of offset 0x70 of the address of offset 0x0C of the key handle address. The breakpoint address is 0x72AA0FA3, and Figure 36 shows the result of setting the breakpoint. When a total of eight operations are completed, the final decryption is performed using the result of the fourth operation, the result of the eighth operation, and the address of offset 0x70 of the address of offset 0x0C of the key handle address. The breakpoint address is 0x72AA0FDE, and Figure 37 shows the result of setting the breakpoint.

3.3. Discussion

The derived information that is used for the decryption based on the result of the analysis is the copied value of the cipher text backward, the address of offset 0x70 of the address of offset 0xC of the key handle address, the address of offset 0x40 of the address of offset 0xC of the key handle address, the address of offset 0x48 of the address of offset 0xC of the key handle address, the address of offset 0xAC of the address of offset 0xC of the key handle address, the address of offset 0x44 of the address of offset 0xC of the key handle address, and the address of offset 0x4C of the address of offset 0xC of the key handle address. Figure 38, Figure 39, Figure 40 and Figure 41 show the decryption process (response to Question 2).

Finally, we tried to analyze the key storage location of NCrypt based on the analyzed BCrypt decryption process. The result of calling the internal function after setting the breakpoint on the NCryptDecrypt function, the NdrSendReceive function of the rpcrt4 library, is called from the inside, as shown in Figure 42. Inside the NdrSendReceive function, the I_RpcSendReceive function is called, as shown in Figure 43, and the ZwAlpcSendWaitReceivePort function of the ntdll library is called inside the I_RpcSendReceive function, as shown in Figure 44. Inside the ZwAlpcSendWaitReceivePort function, the kernel code is executed in the kernel, and the decryption result is returned after the function is called, as shown in Figure 45.

This article analyzed the key storage mechanism in the asymmetric-key-related functions of the CNG library and derived two research questions. The first question is whether it is possible to verify real key information from the obtained handle because CNG does not directly receive key information during the encryption and decryption processes. The second question is as follows: “If the handle address of an encryption or decryption key is given, can the location of the real key information be analyzed from the key handle address?” In answer to the first question, it was not possible to analyze the exact location using the key handle based on the key information obtained when the key was loaded in NCrypt. As shown in Figure 41, the response to the second question accurately analyzed the key storage mechanism in asymmetric-key-related functions in BCrypt. Based on these questions and responses, the analyzed results can be used for the purpose of verifying key-related information, such as debugging and verification, when developing various cryptographic systems and application programs using CNG. Furthermore, if a tool for extracting key information is implemented, we believe that an automated key verification method can be developed.

4. Conclusions

In this paper, we analyze the key storage mechanisms of a CNG library. To perform this, we analyzed the programming techniques using the CNG library and implemented a sample program based on the analysis results. Based on the implemented program, we analyzed the key storage mechanism using reverse engineering and the key storage mechanism of RSA, which is the asymmetric key algorithm, in BCrypt and NCrypt. According to the analysis results, the memory is allocated for encryption, and then the cipher text is copied backward. After that, the internal function is called three times by passing parameters related to the cipher text and the key. In the last function, the internal function circulates 20 times and copies the cipher text to the allocated memory backward by 4 bytes. Then, it calls the internal function that performs the operation by passing the cipher text and key-related parameters. Finally, the cipher text is decrypted by performing these operations eight times in total. NCrypt calls specific functions of the rpcrt4 and ntdll libraries and then enters the kernel to perform the decryption.

The results of this paper will provide a more convenient way to verify key-related information, such as debugging and verification, when implementing a cryptographic system using CNG. In the future, we will research the key storage mechanisms of more diverse algorithms and derive a formal key storage mechanism for CNG based on the results of this paper.