Tang and Clevis: shackling secrets to the network

Full disk encryption and, more generally, encryption of secrets at
rest are part of the information security doctrine. Unfortunately
these practices have costs in the form of latency (downtime),
repetition (productivity loss), proneness to error (typos; "was that
'1' or 'l'?") or other challenges in supplying a decryption
passphrase when needed (e.g. headless systems). These hurdles,
aside from the inherent costs, have resulted in an alarming
incidence of advice on the web to, e.g. leave TLS private keys
sitting around in the clear.

We can do better.

*Tang* [1] is a protocol and (along with the client-side *Clevis*)
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 novel two-party protocol based on ElGamal encryption
that allows Alice to cooperate with Bob to encrypt and decrypt a
secret without Bob (let alone Eve) being able to learn the secret.

In this talk I will outline the use cases, explain McCallum-Relyea
exchange and provide an overview of the network protocol, design and
implementation of Tang and Clevis. There will be a live demo
showing the setup and operation of Tang and Clevis to automatically
decrypt LUKS volume keys and TLS private keys in Apache. The talk
will conclude with a discussion of assumptions, limitations and
threats in the Tang protocol, and how the protocol can play a part
in more complex access policies (wherein *Shamir's Secret Sharing*
makes an appearance).

*Note: Tang and Clevis were formerly a single project called Deo[2].*

[1] https://github.com/npmccallum/tang
[2] https://github.com/npmccallum/deo

Transcript

1. Tang and Clevis Shackling Secrets to the Network Fraser Tweedale @hackuador May 25, 2016
2. Intro
3. CC BY-SA 3.0 https://commons.wikimedia.org/wiki/File:Laptop-hard-drive-exposed.jpg
6. Demo
7. Tang Simple provisioning of encryption for secrets Automated decryption when Tang server is available secret is bound to network Secret never leaves the client
8. Tang - assumptions Tang server only accessible from “secure network” Secrets and keys are safe in client memory
9. Diffie-Hellman exchange Key agreement protocol Alice and Bob agree on a shared secret Eve cannot learn shared key
10. Integrated Encryption Scheme Encryption protocol based on DH Derive symmetric key from shared secret Alice encrypts a message to Bob’s public key; sends it Bob can decrypt the message, Eve cannot
11. McCallum-Relyea exchange Encryption protocol based on IES due to Nathaniel McCallum and Robert Relyea: https://marc.info/?m=144173814525805 Alice encrypts a message to Bob’s public key; doesn’t send it 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 cyclic group G of order n, with hard problem Z∗ p (discrete log) elliptic curve E(Fq ) (point factorisation) generator g ∈ G key derivation function KDF symmetric encryption algorithm Enc message m to be encrypted
14. McCallum-Relyea - encryption Client Server A ∈R [1, n − 1] B ∈R [1, n − 1] b ← gB ← b K ← KDF(bA) = KDF(gAB) a ← gA, c ← Enc(K, m) ∅ ← A, K
15. McCallum-Relyea - decryption Client Server X ∈R [1, p − 1] x ← a · gX = gA · gX x → x ← xB = gAB · gXB ← x K ← KDF(x · (bX )−1) = KDF(gAB · gXB · g−XB) = KDF(gAB) 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 UDP ASN.1 (DER) No encryption (none needed) Trust On First Use (TOFU) Signed messages allow key rotation OOB fingerprint validation / key pinning are possibilities
18. Tang - threats and caveats MitM during provisioning Tang server is DoS target Good entropy needed for ephemeral key X Quantum computing
19. Mission accomplished
20. ???
21. To what other things can we bind secrets? Trusted Platform Module (TPM) Smartcard Bluetooth LE beacon Biometrics “Master unlock key”
22. Unlock policy Security is not binary Policy should be driven by business needs, not technology How can we support arbitrarily complex unlock policy? e.g. stage1 ← S ⊂ {pwd, tang, smartcard, fingerprint}, |S| ≥ 2 stage2 ← {stage1, tpm} unlock ← S ⊂ {stage2, pwd}, |S| ≥ 1
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
25. Demo
26. Clevis Client-side, pluggable key management based on SSS pins (plugins) tang, password, . . . JSON configuration C; minimal dependencies (openssl, libjansson)
27. 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
28. LUKS integration Linux Unified Key Setup LUKS (v1) integration: Tang only LUKSMeta library LUKS2 (future) Designed for extensibility Full Clevis support (hopefully!)
29. USBGuard integration Automatic encryption/decryption of USB storage media Allow only Tang-provisioned volumes to be accessed Can’t be accessed outside network perimeter
30. Ongoing development Key rotation Audit logging
31. Stuff I wish I had time to do right now TPM Clevis pin Let’s Encrypt integration (encrypt private keys) Blog post on Apache integration: https://is.gd/hQcpuM
32. Availability Fedora 24 COPR (unofficial package repo): npmccallum/tang Source code (GPLv3+) https://github.com/latchset/tang https://github.com/latchset/clevis
33. You can help! Crypto / protocol / code review Try it out! Tell us your use cases Contribute Clevis pins
34. Fin © 2016 Red Hat, Inc. Except where otherwise noted this work is licensed under http://creativecommons.org/licenses/by/4.0/ Blog blog-ftweedal.rhcloud.com Email ftweedal@redhat.com Twitter @hackuador