We protect private keys from theft from VPS

At the beginning of each semester, students of the master's program of the Department of MIT of the Academic University (St. Petersburg) and representatives of partner companies get together. Representatives talk about projects that can be worked on, and students choose them.



In one of the projects made at Parallels Labs , our student explored the possibility of implementing a virtual Hardware Security Module (HSM) . As a result, he added his VHSM implementation to the open-source project OpenVZ . Read more about his decision under the cut.

What is HSM

Imagine an application that signs data sent to the server using a private key. Let the loss of this key is unacceptable for its owner. How to protect such valuable key from leakage as a result of remote hacking of the system? The HSM approach suggests that we should not give the vulnerable part of the system access to the key content at all. HSM is a physical device that itself stores digital keys or other secret data, controls them, generates them, and also performs cryptographic operations with them. All operations on the data are performed inside the HSM, and the user has access only to the results of these operations. The internal memory of the device is protected from physical access and hacking. At attempt of penetration all confidential data is destroyed.



To start using HSM, the user must authenticate themselves. If authentication is performed through the HSM client application running in the vulnerable part of the system, then an HSM password could be intercepted by an attacker. The intercepted password will allow an attacker to use HSM without obtaining the secret data stored in it. Thus, it is desirable to perform authentication bypassing the vulnerable part of the system, for example, using physical PIN input.

')

The main barrier to using HSM is their high cost. Depending on the class of the device, the price can vary from $ 10 (USB tokens, smart cards) to 30,000 + $ (devices with hardware accelerated cryptography, anti-burglary, high availability features). Providers of cloud solutions have not ignored the HSM market. For example, Amazon sells its cloudy HSM at an average price of $ 1,373 per month.



One of the main features of HSM is the isolation of the vulnerable part of the system using cryptographic services from the HSM executing these services. Note that individual instances (virtual machines, containers, etc.) are isolated from each other in the cloud, so if you take out the HSM functions outside the vulnerable instance in another instance that is isolated from the outside world, we will fairly accurately reproduce the functionality of the physical HSM. We called this approach Virtual HSM (VHSM) . Consider how it was implemented by our student for the OpenVZ project.

What is OpenVZ

OpenVZ is one of the technologies for running a variety of isolated Linux operating systems on a single Linux kernel. At the same time, they say that each Linux operating system runs in a separate container. If to simplify greatly, then in fact, a functionality is built into the Linux kernel that allows you to isolate applications assigned to different containers so that they are unaware of the existence of each other. Applications cannot change their container. For better isolation and security, communication between applications from different containers using IPC tools is prohibited. It is usually done using network connections. As a result, we see the similarity of containers with “ordinary” virtual machines. OpenVZ and technologies based on it are popular with hosting providers for creating VPS. The Academic University has already made projects related to container virtualization. For example habrahabr.ru/company/parallels/blog/174211 . Parallels is the main developer of OpenVZ. The implementation of VHSM for OpenVZ has become quite logical.

Virtual HSM Architecture

• Client VE is an OpenVZ container in which user applications are executed that require cryptographic services for their work, such as encryption, signature, etc. The container is available for remote attacks in order to steal digital keys.
• VHSM virtual environment (VHSM VE) - OpenVZ container in which the VHSM server is running - a daemon that receives commands from applications in Client VE and executes them. No other applications in VHSM VE are running. VHSM VE is isolated from regular custom containers using OpenVZ. The container has no network interfaces and is not accessible over the network.
• Transport is a Linux kernel module designed to transfer messages from Client VE to VHSM VE and back.
• VHSM API is a library that implements part of the standard for HSM PKCS # 11 interface, which sends application commands from ClientVE to VHSM server using transport, and returns the result of the command execution to the application in ClientVE.

Consider each component in more detail.

VHSM virtual environment

The VHSM server is responsible for authenticating users, interacting with the secret data store, and performing cryptographic operations. In addition to the VHSM server, VHSM VE contains Secure Storage, a database that stores sensitive information in encrypted form. Each VHSM user has his master key that encrypts his data. The master key is generated from the user's password using the PBKDF2 function. The salt transmitted to it at the input is stored in unencrypted form in the database. Thus, VHSM does not store the user's master key in the database, and the use of PBKDF2 significantly reduces the speed at which the original user password is searched for when the database is stolen.



The user is registered in VHSM by the administrator, in the role of which both the person and the program can act. When registering a user, the VHSM generates a 256-bit authentication key and encrypts it with a master key using AES-GCM . Further, before using VHSM, the user authenticates himself with a login-password pair. During authentication, a master key formed from a password and salt is used to decrypt the user authentication key. Using GCM allows you to verify the master key during decryption. The master key is obtained from the user password, and therefore checking its correctness allows you to check the user password itself, transmitted during authentication. After successful authentication, cryptographic services using the user's digital keys stored in the VHSM become available to the user.



VHSM requires an explicit choice of containers from which a particular user can work with VHSM. Information about the container from which the user’s command is received is provided to OpenVZ.

VHSM API

This is a C-library located in user containers and implementing part of the standard for HSM PKCS # 11 interface, which allows you to manage keys, data, sessions, digital signature, encryption, etc. Consider a specific example of using the VHSM API:

1. The application in the user container must sign the message being sent.
2. Using the VHSM API, the application generates a public-private key pair, obtains the private key ID and the public key.
3. The application sends the message to the VHSM API for signing with the private key with the desired ID. The VHSM API returns a signed message.
4. The signed message and the public key are transmitted to the recipient of the message. At the same time, the private key is not accessible to the client container.

In the client part of the project, the OpenSSL engine and the PAM module were also implemented, which allow working with VHSM in existing applications using OpenSSL and PAM. However, this part of the project is poorly developed and is rather a proof of concept.

VHSM Transport

As mentioned above, applications running in different containers cannot communicate with each other using the IPC Linux mechanisms. Therefore, to transport messages from clients to the server and back, its own loadable Linux kernel module was implemented. The module starts the Netlink server in the kernel, and the VHSM clients and the VHSM server connect to it. The netlink server is responsible for sending messages from the source (VHSM client) to the receiver (VHSM server) and back. Along the way, a message source container ID is added to messages so that, for example, the server can reject requests from containers from which a specific user is prohibited from using VHSM.

Conclusion

The main purpose of creating VHSM was to eliminate the possibility of stealing secret keys from the memory of user applications running in a user container. This goal was achieved because Secret data is only available in an insulated container (VHSM VE). Isolation is implemented by OpenVZ.



DB leakage from VHSM VE will not lead to immediate loss of secret data, since they are stored in encrypted form. The encryption key is not stored in the database, but is generated from the password of the user transmitted during its authentication.

Like any information protection technology, the above solution is another barrier to the attacker and does not provide complete information protection.