Featured Post

Show HN: LegendAI-Amazon Sales Tracker https://ift.tt/Qmk4XB9

Show HN: LegendAI-Amazon Sales Tracker Get Actual Not Estimate Amazon Product Data! Real-Time Amazon Sales and Data Insights. Get accurate s...

Wednesday, March 8, 2023

Show HN: Co-locating Debian Bullseye with an evil maid https://ift.tt/5IwQOHk

Show HN: Co-locating Debian Bullseye with an evil maid In order to facilitate the secure co-location of a server, I looked into protecting a Debian Bullseye system from evil maid attacks. In addition, since I've enjoyed using ZFS for some time, I decided to rely on a natively encrypted ZFS root file system. Basically... I'd like to take a system containing sensitive information, box it up, and drop it in the mail without worrying about losing it or having it wind up in the wrong hands. A couple of things became clear while researching how to do this. First, there should be little chance that a rogue data-center admin can insert malicious software. When the system reaches the data center and gets powered on we should be confident that it's running our software completely unmodified. As I understand things, Secure Boot is designed to help with this and therefore should be enabled. However, by relying on Secure Boot alone, there will be no remote method of knowing that it hasn't been disabled until after the ZFS pass-phrase is provided to the initramfs via dropbear. At that point it's too late. An evil maid could have already subverted dropbear, for example, and just now stolen the pass-phrase. To avoid this I realized that a second requirement of using a TPM device to automatically unlock the ZFS root was in order. TPM devices have the ability of "sealing" data to so-called Platform Configuration Registers (PCR). This feature allows the data to be accessed only if the "measured" system state matches some original expected state. The TPM can fully start the system unattended but, if anything's unexpectedly meddled with, act like a tripwire requiring the pass-phrase to be typed in manually. If we ssh in and reach dropbear requesting the pass-phrase, we'll know that we either need to update our sealed data after a grub/kernel/initramfs update... or someone's been messing with our start up code. This window of opportunity will be too small for an evil maid to take practical advantage of. This sounded like the right track and I set out to try and configure both, Secure Boot and TPM unlocking of an encrypted ZFS root. I thought it'd take a few hours at most but it actually turned out to be a fair challenge. After a few failed attempts I started tenaciously documenting every avenue. Ultimately I developed helper scripts that can reproduce the configuration should the time come to actually ship a machine out the door. I'm reasonably satisfied with the outcome. However, the scripts haven't been reviewed and neither has the overall process itself. There were a lot of guides I followed that contained typos, bugs, dubious information or simply different requirements. I'm not sure everything is exactly "bullet-proof" for this show HN. For example, I'm beginning to wonder if Secure Boot is necessary and if the TPM alone is sufficient. So naturally, comments and criticisms regarding everything are greatly appreciated. The script files can be found here: https://ift.tt/voDQCa0 and here: https://ift.tt/YQbgDxf Finally, I hope this effort will be useful to others facing similar needs. March 8, 2023 at 04:19AM

No comments:

Post a Comment