TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

Show HN: Co-locating Debian Bullseye with an evil maid

6 点作者 reliefcrew大约 2 年前
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&#x27;ve enjoyed using ZFS for some time, I decided to rely on a natively encrypted ZFS root file system. Basically... I&#x27;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.<p>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&#x27;s running our software completely unmodified. As I understand things, Secure Boot is designed to help with this and therefore should be enabled.<p>However, by relying on Secure Boot alone, there will be no remote method of knowing that it hasn&#x27;t been disabled until <i>after</i> the ZFS pass-phrase is provided to the initramfs via dropbear. At that point it&#x27;s too late. An evil maid could have already subverted dropbear, for example, and just now stolen the pass-phrase.<p>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 &quot;sealing&quot; data to so-called Platform Configuration Registers (PCR). This feature allows the data to be accessed only if the &quot;measured&quot; system state matches some original expected state.<p>The TPM can fully start the system unattended but, if anything&#x27;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&#x27;ll know that we either need to update our sealed data after a grub&#x2F;kernel&#x2F;initramfs update... or someone&#x27;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.<p>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&#x27;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.<p>I&#x27;m reasonably satisfied with the outcome. However, the scripts haven&#x27;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&#x27;m not sure everything is exactly &quot;bullet-proof&quot; for this show HN. For example, I&#x27;m beginning to wonder if Secure Boot is necessary and if the TPM alone is sufficient.<p>So naturally, comments and criticisms regarding everything are greatly appreciated.<p>The script files can be found here: https:&#x2F;&#x2F;gist.github.com&#x2F;ReliefCrew&#x2F;6beeef4ca3d9afc8fe233c7fcac93799<p>and here: https:&#x2F;&#x2F;gist.github.com&#x2F;ReliefCrew&#x2F;5f15a87bb33734daa68f38b485e95f3f<p>Finally, I hope this effort will be useful to others facing similar needs.

暂无评论

暂无评论