The main problems that people have to deal with when disk devices are concerned are related to when the device leaves the owner’s control. The most common cases are when the device is decommissioned at its end of life, end of lease, or is returned for warranty or repair. In all of those cases, a device that contains non-encrypted data can be used by an unauthorized party to reveal possibly sensitive data that resides on it. Even if a company puts rigorous requirements for cleansing the device’s data before it leaves the property, this is not 100% fool proof, and sometimes can’t really be achieved if the device is not functioning properly. The process can take hours or days and can leave portions of data on the device, especially in the case of SSDs where virtual pages are being used.
These data cleansing issues and the increasing risk of data exposure have increased the interest in encryption. Encryption automatically secures the data when it leaves the owner’s control without the need for human interaction and costly, time-consuming, imperfect processes.
How does DataCore implement encryption?
First, there is some research that needs to be done. The main constraint we put on encryption is that we are implementing data-at-rest encryption. That means that the data stored on the backend will be encrypted. Data in transit will remain plain-text. Furthermore, there are two classes of encryption algorithms – symmetric and asymmetric. Asymmetric encryption is used when a public/private key pair is required. It is relatively slower than symmetric encryption. This makes the symmetric encryption the better choice when high/real-time performance needs to be achieved. We don’t want to use an encryption algorithm that makes the I/O processing significantly slower.
Next, we want to use an algorithm that doesn’t change the length of the data after encryption. This has the benefit of preserving the disk usage to the original level. The downside of this is that data manipulation can’t be detected because there are no authentication tags. This is considered a good tradeoff for data-at-rest encryption. The main idea is that unauthorized users that have the ability to freely monitor and/or manipulate the data on the disks can, at minimum, revert the entire disk to a previous consistent state even without breaking the encryption algorithm. This will render any encryption useless, since it will flip the data on the disk from one valid state to another without any error detection mechanism noticing it.
Now that we know what type of encryption we want to use; how do we provide it to users? Obviously, we don’t want to reinvent the wheel. We could implement an encryption algorithm from scratch. This raises a very interesting question which is especially valid when encryption and security are concerned – how do we convince people that our implementation is safe and correct? We can certify such an implementation but this opens a plethora of problems itself, starting with the successful completion of the certification process and making sure we have covered the certification requirements that are regulatory requirements for our users in the different parts of the world. This is a process that will drastically increase the time-to-market of our solution.
The need for cryptographic agility
Another approach would be to use an existing implementation of a standard algorithm and incorporate it in our product. This allows us to use an implementation that is already certified which is the most concerning part of any encryption-related project. There are many such implementations but we have one other limiting factor – we wanted our encryption algorithm to be able to work in a Windows driver, that is, in kernel mode. This by itself limits significantly the choices we have.
Enter Microsoft’s CNG library – Crypto Next Generation. It has an implementation for AES-XTS which is exactly what we need for our purposes and is actually one of the best alternatives when disk encryption is required. It has Windows driver support since Windows Server 2016. It also has a FIPS 140-2 certificate.
The rest is, almost, straight-forward. We just have to incorporate it into our drivers and provide the necessary support for the user to be able to create encrypted virtual disks. We verified we can execute multiple calls in parallel which was crucial in order to achieve adequate performance. Our test runs confirmed that – the performance drop when using encryption is within 5% provided the test is performed on a machine that has the AES-NI set turned on.
A final recommendation
Keeping a copy of the encryption key is crucial in order to prevent data loss. If anything happens that results in the loss of the encryption key, it will make the data completely unreadable. Imagine a door that you put an extra effort to make unbreakable and which can’t be bypassed in any way. Imagine you put behind it your most critical data and then lock it with the only existing key. Then, something happens and you lose the key. There is no way to get your data back. Or maybe there is, but since we use 256-bit encryption, you need to be prepared to wait significant number of years before that happens. As a rule of thumb, ALWAYS make backup copies of your keys and store them in a secure location.
Have a question on data protection or encryption in your storage environment? Request a live demo or fully-functional free trial of the most advanced technology to accelerate performance, increase resource efficiency, and achieve zero-downtime availability for your storage systems.
