This post was originally published here by sergei odnoval.
As you likely know, using cloud services means that you’re storing data on servers you don’t own. Mistakes made in the cloud are therefore more likely to become public and the impact can range from embarrassment, to losing all of your data. And one of the most important ways to protect your data is encryption.
The are many ways to encrypt data, but one of the most challenging has historically been encrypting root volumes under Linux OS. That’s why I’m so excited to demonstrate a new RedHat Network-Bound Disk Encryption (NBDE) technology, which is going to make your DevOps and security encryption practices so much easier.
So how did we get here? Well when we developed our latest CloudPassage CSM module for the RedHat Enterprise Linux 7.4 policy template we immediately noticed that the OS was using new technology that makes root volume encryption possible. The technology is Network-Bound Disk Encryption, or NBDE, and it allows the user to encrypt root volumes without requiring you to manually enter a password when the operating system is restarted. All needed packages have been added to RHEL 7.4 and are supported. It is also available for Fedora 24+.
In Red Hat Enterprise Linux 7, NBDE is implemented through the following components and technologies: the Clevis framework or the Tang server.
Tang
Tang is a server for binding data to a network presence. It makes a system containing your data available when the system is bound to a certain secure network. Tang is stateless and does not require TLS or authentication. Unlike escrow-based solutions, where the server stores all encryption keys and has knowledge of every key ever used, Tang never sees a single client key; so it never gains any identifying information from the client.
Clevis
Clevis is a pluggable framework for automated decryption. In NBDE, Clevis provides automated unlocking of LUKS volumes and it shows the client side of the feature. A Clevis Pin is a plugin into the Clevis framework. One of such PINs is a plugin that implements interactions with the NBDE server; aka Tang.
Together Clevis and Tang are generic client-and-server components that provide network-bound encryption. In Red Hat Enterprise Linux 7, they’re used in conjunction to encrypt and decrypt root volumes of hard drives to accomplish the Network-Bound Disk Encryption. Both client and server-side components use the José library to perform encryption and decryption operations.
The Clevis Pin for the Tang server gets a list of the Tang server’s advertised asymmetric keys. Alternatively, since the keys are asymmetric, a list of Tang’s public keys can be distributed out of the band so that clients can operate without access to the Tang server. This mode is called offline provisioning. The Clevis Pin for Tang uses one of the public keys to generate a unique, cryptographically-strong encryption key.
Once the data is encrypted using this key, the key is then discarded. The client should store the state produced by this provisioning operation in a convenient location. This process of encrypting data is the provisioning step. The provisioning state for NBDE is stored in the LUKS header leveraging the luksmeta package.
When the client is ready to access its data, it loads the metadata produced in the provisioning step and it responds to recover the encryption key. This process is the recovery step. In NBDE, Clevis binds a LUKS volume using a PIN so that it can be automatically unlocked. After successful completion of the binding process, the disk can be unlocked using the provided Dracut unlocker.
Secure NBDE configuration
NBDE is based on client-server technology, so in order to properly take advantage of it, we need configure both server and client. It’s recommended to use several Tang servers, but in an effort to avoid redundancy, in my example I will install only one.
Server installation:
Ensure, that server is up-to-date and has latest software packages:
#yum check-update
If needed, install updates:
#yum -y update
Install Tang server:
#yum -y install tang
Start Tang server:
#systemctl enable tangd.socket –now
Tang server works on port 80, HTTP, don’t forget to open ports in your firewall software or create rules in the cloud and make server name or IP address static.
Server setup is completed.
Client installation:
For test purposes, I installed 2 operating systems: RedHat 7.4 and CentOS 7.4 in my virtual environment. I also enabled encryption of the root file system. I set out to test only the functionality of NDBE, so I will not describe in this note possible options for deploying the operating system.
After systems are installed it’s time to install client-side packages. Conveniently, the next steps for both operational systems (RedHat and CentOS) are the same.
Ensure, that client is up-to-date and has latest software packages:
#yum check-update
If needed, install updates:
#yum -y update
Install necessary packages:
#yum -y install clevis clevis-luks clevis-dracut
Binding our luks-volume to Tang-server
#clevis bind luks -d /dev/xvda tang ‘{“url”:”http://tang_server_ip“}’
In my case, it was something like this:
clevis bind luks -d /dev/xvda tang ‘{“url”:”http://ec2-18-220-30-166.us-east-2.compute.amazonaws.com”}’
You can check if binding was successful:
#luksmeta show -d /dev/xvda
You can see something like this:
0 active empty
1 active cb6e8904-81ff-40da-a84a-07ab9ab5715e
2 inactive empty
3 inactive empty
4 inactive empty
5 inactive empty
6 inactive empty
7 inactive empty
Upon successful completion of this binding process, the disk can be unlocked using Dracut.
The Dracut unlocker attempts to automatically unlock volumes during early boot. This permits automated root volume encryption. Rebuilding initramfs after installing Clevis to enable the Dracut:
#dracut -f
The Linux operating system provides the “/etc/crypttab” file to open encrypted volumes automatically. With the possibility to mount the volume without user interaction, the volume can be mounted on system startup.
To configure the encrypted volume in crypttab, the UUID (the unique identifier) of the volume is needed. This identifier can be retrieved again using “cryptsetup luksUUID” command.
Content of files /etc/crypttab and /etc/fstab:
#cat /etc/crypttab
#cat /etc/fstab
During the system startup, you will see a prompt for entering a passphrase for encrypted volume, however this only appears for few seconds. If the Tang server is accessible the volume will be decrypted automatically and the system will continue loading.
Once the configuration is complete you can test. In my scenario, I placed virtual machines with encrypted root volume at a local computer and server with Tang package on the cloud. I rebooted the virtual machines and emulated scenarios like inaccessible networks or a Tang server shutdown. When the Tang server was accessible, virtual machines started without any issues, when Tang server was inaccessible, virtual machines can’t start without entering LUKS passphrase.
If you removed the passphrase, you will not be able to boot the server while Tang servers is inaccessible.
Main concept of technology is encryption data stored in the cloud, but you can use it in another case: you can store Tang servers in the cloud and encrypt root file system on workstations, placed in your office and connected with the cloud through private network. So, if you delete initial passphrase, outside the office anybody can’t decrypt data, stored on workstations.
In conclusion, safeguarding data is the primary and most important security concern. New technologies like NBDE can be used for safeguarding data in physical, virtual or EC2 type of cloud infrastructures. You must remember that only the owner is responsible for the safety of own data.
Photo:WinMagic
