Clevis and Tang: Securing your Secrets at Rest

Full disk encryption and, more generally, encryption of secrets at
rest are essential tools in the security toolbox. But deploying
encryption at rest can have costs: latency (downtime), repetition
(productivity loss), proneness to error (typos; "was that '1' or
'l'?"), challenges in supplying a passphrase when needed (e.g.
headless systems). Automated decryption often relies on delivery of
escrowed keys (a third party knows your secret).

We can do better.

_Tang_ [1] is a protocol and (along with the client-side program
_Clevis_ [2]) software implementation of *network bound encryption*;
that is, automatic decryption of secrets when a client has access to
a particular server on a secure network. It uses McCallum-Relyea
exchange, a two-party key computation protocol based on Diffie-Hellman
where only the client can compute the key! _Clevis_ [2] uses the
amazing *Shamir's Secret Sharing* algorithm to implement unlock
policies with thresholds that can include passphrases, Tang servers
and TPM-sealed secrets.

In this talk I will outline the use cases, explain the algorithms
and demonstrate these tools. The live demo will set up a machine to
automatically decrypt a LUKS volume when a required number of Tang
servers are available. I will conclude with a discussion of
limitations, assumptions and threats.

[1] https://github.com/latchset/tang
[2] https://github.com/latchset/clevis

Transcript

1. Clevis and Tang Securing your secrets at rest Fraser Tweedale @hackuador January 15, 2020
2. CC BY-SA 3.0 https://commons.wikimedia.org/wiki/File:Laptop-hard-drive-exposed.jpg
5. Demo
6. Tang Simple provisioning of encryption for secrets Automated decryption when Tang server is available secret is “bound to the network” Secret never leaves the client
7. Tang - assumptions Tang server only accessible from “secure network” secrets and keys are safe in client memory sufficient entropy at provisioning and decryption
9. Diffie-Hellman (DH) key agreement Alice and Bob agree on a shared secret Eve (the eavesdropper) cannot learn shared key Parameters: cyclic group G of order n, with hard problem Z× p (discrete log) elliptic curve E(Fq) (point factorisation) generator g ∈ G
10. Diffie-Hellman key agreement Client Server 1. A ∈R [1, n − 1] B ∈R [1, n − 1] 2. a ← gA b ← gB 3. a → ← b 4. K ← bA = gAB K ← aB = gAB
11. Integrated Encryption Scheme (IES) Encryption protocol based on Diffie-Hellman Derive symmetric key from shared secret Alice encrypts a message to Bob’s public key; sends it Bob can decrypt the message, Eve cannot
12. McCallum-Relyea exchange Encryption protocol based on DH/IES due to Nathaniel McCallum and Robert Relyea: https://marc.info/?m=144173814525805 Alice encrypts to Bob’s public key; doesn’t send message To decrypt, Alice asks Bob to encrypt an ephemeral key uses reply to recover secret Eve cannot decrypt the message and neither can Bob!
13. McCallum-Relyea - parameters G, n, g ∈ G (same as DH) key derivation function KDF (e.g. SHA-256) symmetric encryption algorithm Enc (e.g. AES-GCM) message m to be encrypted e.g. content encryption key (CEK)
14. McCallum-Relyea - provisioning Client Server 1. A ∈R [1, n − 1] B ∈R [1, n − 1] 2. b ← gB 3. ← b 4. K ← KDF(bA = gAB) 5. a ← gA, c ← Enc(K, m) 6. ∅ ← A, K
15. McCallum-Relyea - decryption Client Server 1. X ∈R [1, n − 1] 2. x ← a · gX = gA · gX 3. x → 4. x ← xB = gAB · gXB 5. ← x 6. K ← KDF(x · (bX)−1) = KDF(gAB · gXB · g−XB) = KDF(gAB) 7. m ← Enc−1(K, c)
16. Tang - implementation Server-side daemon and Clevis pin C Extensive test suite Small and fast (>30k req/sec)
17. Tang - protocol JSON / JOSE objects over HTTP No TLS (not needed) Trust On First Use (TOFU) signed messages allow key rotation offline provisioning is possible
18. Tang - threats and caveats MitM during provisioning Tang server is DoS target Good entropy needed for ephemeral key X Quantum computing (SIDH?)
19. Mission accomplished
20. ???
21. To what other things can we bind secrets? Trusted Platform Module (TPM) Smart Card Bluetooth LE beacon ? Escrowed key Biometrics ???
22. Unlock policy Security is not binary Policy should be driven by business needs (not tech) How can we support arbitrarily complex unlock policy?
23. Shamir’s Secret Sharing k points describe a polynomial of degree k − 1 Free coefficient ← secret, other coefficients ←R Distribute n points (n ≥ k, x = 0) Given k points, compute Lagrange polynomial secret ← f(0)
24. Shamir’s Secret Sharing CC BY-SA 3.0 https://en.wikipedia.org/wiki/File:Lagrange_polynomial.svg
26. Clevis Client-side, pluggable key management based on SSS pins (plugins) tang, tpm2, sss, ... JSON configuration C
27. Demo
28. LUKS integration Linux Unified Key Setup LUKS (v1): Tang only LUKS 2: full Clevis support dracut, systemd and udisks2 unlockers clevis-luks-unlockers(7)
29. History Feb ’15: Deo project begins (δεω, to bind) Used TLS for privacy and X.509 encryption cert (complexity!) Server decrypts and returns secret (thus learning it; bad!) Sep ’15: McCallum-Relyea discovered; rewrite begins Dec ’15: Project split into Tang and Clevis
30. Availability Fedora ≥ 24 RHEL ≥ 7.4 Debian ≥ 10 (buster) Ubuntu ≥ 18.04 LTS (bionic) Source code (GPLv3+) https://github.com/latchset/tang https://github.com/latchset/clevis
31. You can help! Try it (+ file bugs) Explain your use cases Contribute Clevis pins Implement for other OSes Publish blog posts / tutorials / demos
32. RHEL documentation https://github.com/latchset © 2020 Red Hat, Inc. Except where otherwise noted this work is licensed under http://creativecommons.org/licenses/by/4.0/ Blog frasertweedale.github.io/blog-redhat Email ftweedal@redhat.com Twitter @hackuador