Tang and clevis - Network-Bound Disk Encryption


One of the interesting features appearing in RHEL 7.4 is NBDE, or Network Bound Disk Encryption. This manages the seemingly impossible - through the magic of asymmetric cryptography it allows a machine with an encrypted disk to boot, without the disk's encryption key having to be entered at boot time - but only when the machine is on the correct network, and without storing the encryption key in plain text, or storing it off the machine, or transmitting data across the network in such a way that a thief could make use of it. Try to boot the machine when it's not on its home network and you'll need to enter the encryption key if you want to steal its data make progress.

For more details of NBDE in general see these sources:

  • The GitHub pages for Tang and Clevis, and for their associated helper software LUKSMeta and José.
  • A 43 minute talk by Nathaniel McCallum of Red Hat, New Cryptography for Binding Data to Third Parties. This explains the cryptography and goes on to explain some of the possibilities it offers, such as how you can use Shamir Secret Sharing to give your encrypted data arbitrarily complex decryption rules.
  • A half hour talk by Brian J. Atkisson of Red Hat, Network-Based LUKS Volume Decryption with Tang. This explains how to enable a machine with an encrypted disk to decrypt it securely on unattended boot.


Here's what I did to get a machine with a LUKS-encrypted disk to decrypt it at boot time with no outside intervention (no need to type in the LUKS password):
  1. Abandon any thought of getting it going on RHEL 7.4, at least unless you have more understanding of its licensing and channel intricacies than I do. Even using Red Hat's generous offer of a free developer's subscription, I was unable to get a test RHEL 7.4 VM to the point of being able to install tang or clevis.
  2. Instead, go for Fedora. I installed Fedora 26 Server (Fedora Server homepage) on a test VM with no difficulty, then found it child's play to install the NBDE software packages - all were available to install with yum.
  3. (Update: apparently it's now available with Scientific Linux 7.4.)
  4. You'll need two machines, one to be a tang server and the other on which to test clevis encryption and decryption. Install your clevis machine with disk encryption (an option in the Fedora installer).
  5. On both machines, disable SELinux: edit /etc/selinux/config to set the SELINUX variable to disabled. Then reboot.
  6. Disable the firewall daemon firewalld with systemctl stop firewalld; systemctl disable firewalld.
  7. On the clevis test machine at least, yum update. My LUKS-encrypted volume would not do its unattended decryption trick until I had done this.
  8. On the tang server, install tang (yum install tang) and start it running as described in its man page (man tang). It boils down to this: sudo systemctl enable tangd.socket --now then reboot. This generates a public-private key pair, which you should back up. Apart from this, the tang server is entirely stateless, and knows nothing about any other encryption keys. It doesn't even need any certificates. There's no need for SSL since everything is multiply encrypted, so tang and clevis communication goes over HTTP. There is support to allow you to transition to a new tang key from time to time, should you want to.
  9. On the clevis test machine, yum install clevis clevis-dracut clevis-luks.
  10. You can now encrypt a test file with clevis and the tang pin, then clevis decrypt it again, as described in the clevis page and in the various man pages (clevis, clevis-encrypt-tang, clevis-decrypt, etc.). When you clevis decrypt your test data, you won't need to enter a password, at least if the tang server is up and running. Ta da!
  11. To test network-bound LUKS encryption, your clevis test machine will need both a LUKS-encrypted LVM physical volume and a separate /boot partition. Our DICE Linux machines don't normally have either of these, but Fedora 26 Server partitions machines this way by default, if you accept the Fedora installer's suggested disk partitioning and choose "Encrypt my data".
  12. On your clevis test machine with its LUKS-encrypted LVM volume, bind the volume's encryption to the tang server using the clevis bind-luks command as described in man clevis-bind-luks.
  13. Also on that machine, rebuild the initrd, to install in the initramfs the clevis tools it'll need if it's going to decrypt the volume at boot time (dracut -f).
Having done all this, when your test machine reboots, it will (as normal) prompt for the root partition's LUKS password. The new behaviour is that if the tang server is running, the prompt will disappear after a few seconds, as the machine manages to clevis decrypt the root partition by itself. Boot then resumes and completes as normal.

Shamir's Secret Sharing

So, it's possible to encrypt something in such a way that it can only be decrypted when a particular tang server can be contacted via http. As long as the tang server's traffic is not routed outside the local network, and its public/private key pair hasn't been stolen, our secret (for instance, our LUKS-encrypted disk) cannot be decrypted once the machine has been taken from the premises. (Unless, in the case of LUKS, the thief knows the passphrase that was used for the original LUKS encryption. That remains valid even after the encryption has been clevis bound to the tang server.)

But what if something bad happens to the tang server? Automated decryption would then be just as impossible. That's the whole point of this scheme - but still, a single server seems like a fragile thing to which to entrust our data. This is where the clevis "sss" pin (i.e. plugin) comes into play. "sss" stands for Shamir's Secret Sharing (Wikipedia: Secret Sharing). Secret Sharing is where you can encrypt your secret using a key which can be broken into several parts, and you define a threshold; when it's time to decrypt, you only need to retrieve and combine any threshold number of those parts in order to be able to decrypt your secret.

In the context of clevis, the sss pin can be used to combine decryption conditions. We could for instance have several tang servers and specify a threshold of 1, so that decryption would be possible if any tang server was contactable.


We've shown that the technology works, but a lot of work would be needed to deploy it. Here are some points to think about:
  • We'd need to think carefully about why we're doing this. Is the motivation solely to have all disks encrypted, or can we also define threats from which this encryption could credibly protect us? The nature of the threats we're defending against should help shape our defences, including for instance the number and placement of our tang servers.
  • What arrangement of tang servers might we want? Might we want, for instance, one tang server per site, with its traffic routed to all DICE wires but not outside Informatics, and decryption possible if any of the three could be contacted? Or would that just offer a temptation to a determined thief to nick a tang server?
  • What other pins (clevis plugins) might we want to add to the mix? Manual password entry? Bluetooth proximity? HTTP key escrow?
  • We'd need to change the way we partition DICE machines. For a start we would need a separate /boot partition to contain the kernel and the initramfs which would do the clevis decryption at boot time. Fedora has a separate /boot partition, then other "partitions" are LVM logical volumes in an LVM physical volume which uses the rest of the disk. If you add encryption, the Fedora installer puts that LVM physical volume inside a LUKS container. At the moment DICE does not use LVM (except on a few specialised servers) and /boot is just a directory in the root partition.
  • Can LCFG manage the required configuration? For a while now we have wanted to redevelop the fstab component so that we could reliably add extra functionality to it, not least the ability to configure LVM as needed. That work might well be needed for us to be able to deploy LVM, never mind LUKS and clevis, across all DICE machines. We'd also need to revisit our installation technology.
  • We could offer this as a service to users. For instance, it could offer a nifty way to decrypt USB keys on DICE machines, but still have them accessible by password on other machines; and self-managed machines could use it to enable safe unattended decryption while on the premises.


  • The name comes from the clevis fastener, a simple security device which consists of a tang, a clevis and a pin.
  • The originators of the software pronounce "clevis" to rhyme with "Ben Nevis", rather than with Saint Kitts and Nevis.

-- ChrisCooke - 01 Aug 2017

Topic revision: r9 - 10 Oct 2017 - 13:16:53 - ChrisCooke
DICE.MPUTangAndClevisTrial moved from DICE.MPUTangAndClevis on 01 Aug 2017 - 15:31 by ChrisCooke - put it back
This site is powered by the TWiki collaboration platformCopyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback
This Wiki uses Cookies