Minutes 2025-10-30: Difference between revisions

From MTU LUG Wiki
Jump to navigation Jump to search
(initial commit)
 
No edit summary
 
(One intermediate revision by the same user not shown)
Line 3: Line 3:
### Refresher: Disk Encryption
### Refresher: Disk Encryption
### On Linux usually use Linux Unified Key System (LUKS)
### On Linux usually use Linux Unified Key System (LUKS)
#### See: Noah's LUKS presentation (LINK HERE)
#### See: Noah's LUKS presentation ([[Minutes 2025-10-02]])
### Why?
### Why?
### Protects data against unauthorized access
### Protects data against unauthorized access
Line 100: Line 100:
### Allows for unattended unlocking, improves practicality of FDE systems
### Allows for unattended unlocking, improves practicality of FDE systems
### Tang/Clevis and Mandos
### Tang/Clevis and Mandos
[[Category:Meeting Minutes]]

Latest revision as of 03:33, 31 October 2025

  1. Network Bound Disk Encryption by Simone!
    1. Background
      1. Refresher: Disk Encryption
      2. On Linux usually use Linux Unified Key System (LUKS)
        1. See: Noah's LUKS presentation (Minutes 2025-10-02)
      3. Why?
      4. Protects data against unauthorized access
        1. AKA Theft/Loss
      5. Nice when decommissioning hardware
        1. Peace of mind that the data is inaccessible
      6. However, typically requires a password to unlock
        1. Does not work when rebooting remote servers
    2. What about TPM?
      1. Can allow for automatic unlocking of disk
      2. But... security issues
        1. Key sniffing attacks
        2. Backdoor concerns
          1. TPMs made by third-party manufacturers
        3. fTPM
          1. Potentially vulnerable to firmware attacks
      3. Not always available on all hardware platforms
    3. This leads into Network Bound Disk Encryption
      1. Don't have to manually enter password
      2. Typically involves a keyserver
      3. Allow decryption under some circumstances
        1. On a trusted network, during a time interval, etc
      4. Clevis/Tang
        1. Pushed by RedHat, but Distro agnostic
        2. Clevis = Key retrieval for LUKS volumes
        3. Tang = Stateless HTTP endpoint for Clevis
        4. Because stateless, prevents sniffing/replay attacks on a network
        5. Supports root and secondary devices
      5. Mandos
        1. Older, less well-known
        2. Specific to Ubuntu(/Debian)
        3. Stateful, stores secret on the server
        4. Uses TLS
        5. Time-based, checks if a client goes offline
        6. Root filesystem only
        7. Refuses to send decryption key if device has been offline for too long
          1. Protect against tampering/lost devices being turned on again
    4. How it works
      1. Key exchange to get decryption key
      2. LUKS volume can still be decrypted with a password, if manual maintenance is ever required or the keyserver breaks
    5. Live Demo!
      1. Two VMs
        1. Client and Server
      2. Can reboot client
        1. Boots into initramfs
          1. Gets IP via DHCP
          2. Connects to Tang server
          3. Received needed secrets, continues boot process
      3. Wireshark capture of client booting
        1. Data is transmitted via JSON over HTTP
        2. Data is ephemeral, not useful beyond this current initial session
      4. Multiple keyslots to decrypt the LUKS volume
        1. Keyslot 0 = Decrypted with a password (for manual decryption)
        2. Keyslot 1 = Used by Clevis for the network-bound decrypt
    6. Common implementations
      1. Headless servers
      2. Remote offices
      3. Devices spread across wide geographical regions
      4. Cloud/VM environments
        1. Allow each guest to have its own encryption rather than managed at the hypervisor-level
    7. Security
      1. Clevis/Tang
        1. Designed for a trusted network
        2. McCallum-Relyea key exchange means data is meaningless to an attacker
    8. NBDE over the internet is possible
      1. Clevis can use HTTPS
      2. Mandos uses TLS
      3. However, more common to just run it through a site-to-site VPN
        1. Also reduces your infrastructure's attack service
          1. Only the VPN port is exposed to the internet rather than Clevis
    9. Limitations
      1. Requires Server and client have network connection and be available at the same time
        1. Server outage means clients can't get their decryption keys
        2. Can run redundant Tang/Mandos servers ti be keyservers for each other
      2. Linux-only
        1. Windows apparently has a similar feature in Windows AD with Bitlocker
        2. Obscure and extremely limited
      3. No user authentication
      4. Live attacks
      5. Freezing DIMMs to read memory contents and extract key content
        1. Mitigated by encrypting RAM contents
      6. Consider your threat model/attacker
        1. Works against the common thief/burglar
        2. Maybe not against a nation state adversary, but you'll have bigger problems to worry about
    10. Future extensions
      1. MFA authentication
        1. Tang+TPM for dual control
        2. Security keys/smartcards
      2. More user-friendly UX/interfaces
      3. Direct VPN integration
        1. Wireguard tunnel inside initramfs for encryption-across-internet use-cases
      4. Support beyond just LUKS
        1. ZFS/Bitlocker/FileVault?
        2. Realistically integration extremely unlikely, especially knowing Apple (in this case, for FileVault)
    11. Summary
      1. Allows for unattended unlocking, improves practicality of FDE systems
      2. Tang/Clevis and Mandos