Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Clevis and Tang: Securing your Secrets at Rest

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

Fraser Tweedale

January 15, 2020
Tweet

More Decks by Fraser Tweedale

Other Decks in Technology

Transcript

  1. 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
  2. Tang - assumptions Tang server only accessible from “secure network”

    secrets and keys are safe in client memory sufficient entropy at provisioning and decryption
  3. 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
  4. 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
  5. 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
  6. 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!
  7. 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)
  8. 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
  9. 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)
  10. 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
  11. Tang - threats and caveats MitM during provisioning Tang server

    is DoS target Good entropy needed for ephemeral key X Quantum computing (SIDH?)
  12. ???

  13. To what other things can we bind secrets? Trusted Platform

    Module (TPM) Smart Card Bluetooth LE beacon ? Escrowed key Biometrics ???
  14. Unlock policy Security is not binary Policy should be driven

    by business needs (not tech) How can we support arbitrarily complex unlock policy?
  15. 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)
  16. LUKS integration Linux Unified Key Setup LUKS (v1): Tang only

    LUKS 2: full Clevis support dracut, systemd and udisks2 unlockers clevis-luks-unlockers(7)
  17. 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
  18. 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
  19. You can help! Try it (+ file bugs) Explain your

    use cases Contribute Clevis pins Implement for other OSes Publish blog posts / tutorials / demos
  20. 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 [email protected] Twitter @hackuador