我以前一直都没咋注意数据安全,SSH 密钥从没加过 passphrase,系统也从没开过全盘加密,而相对的我积累的个人数据却变得越来越重要。
比如说如果我的 GitHub 私钥泄漏,比较有价值的仓库被篡改,以前我 GitHub 上没啥数据无所谓,但现在这个风险我无法容忍了。

另外我的 Homelab 去年坏掉了两块国产固态硬盘(阿斯加特跟光威弈 Pro 各一根),都是系统一启动就挂,没法磁盘格式化,然后直接被京东换货了,这很可能导致我的数据泄露...

为了避免 Github 私钥泄漏、区块链钱包助记词泄漏、个人隐私泄漏等可能,现在打算仔细研究下 ssh、gpg、2FA、Linux/Windows 全盘加密、age/sops 这些相关的安全手段,全面强化下自己的数据安全性。

随着这个计划的推进,我打算写一系列文章来记录我的这套全新的个人数据安全方案,这里先占个坑,顺便大家有任何想法跟资料也可以在这里讨论~

    补充下目前搜集到的一些资料:

    还有就是一定要注意如何避免记在本子上的钱包助记词/backup_code 被社工,一定要藏好了。另外如果要家里来亲戚啥的,更要考虑清楚这个...血泪教训...
    可以考虑把这些数据拆分成多个部分来记录,或者最好是用 age/sops 加密后多处备份,密钥还可以考虑用密钥分割法来拆分保存,这样即使泄漏部分数据,也还能确保安全性。

      ryan4yin 另外我的 Homelab 去年坏掉了两块国产固态硬盘(阿斯加特跟光威弈 Pro 各一根),都是系统一启动就挂,没法磁盘格式化,然后直接被京东换货了,这很可能导致我的数据泄露...

      硬盘挂了被换货导致的数据泄露我以前真的没有想到过,目前依赖苹果的全盘加密 😢

        数据隐私是一个很重要的问题,我也比较感兴趣数据存储大家都是什么解决方案呢?我实验室的学长主推个人NAS,但是我觉得这个并不适合我,因为感觉电费的话一年和云盘存储没有太大的区别,但是目前没有找到合适云盘来做数据管理

          0x0001 之前我特意查了下,据说类似手机维修、固态返厂、二手手机回收,这类场景下流出的不雅视频不在少数...
          这方面苹果确实做得比较好,不过新的安卓手机好像现在也都全盘加密了,直接拆存储芯片读不了数据。

          ryan4yin Linux/Windows 全盘加密

          软件加密不如硬件加密,有钱直接上企业级硬盘,自带加密功能。

          ryan4yin 在远程主机上进行 git 操作、ssh 到另一台主机等

          这里有个不重要的小问题,用于登录 ssh 的密钥和 git ssh 的密钥安全等级是一致的吗?同理跳板机和目标主机的 ssh 安全等级是一致的吗?

          此外, ssh agent forwarding 也有观点认为是不安全的(vulnerability)。

          yuex

          之前有另一个帖子讨论这个。如果你考虑云盘的话,感觉你的需求跟对象存储差不多,考虑下 OSS 的方案,比如 cloudflare r2价格公道经济实惠(狗头

            粗略看了下 sops ,网上搜到个用 git-filter 自动加解密 git 库中硬编码的密钥的实践,感觉可以试一试。

            不过它好像没说怎么用在 CI/CD 上。。我感觉不一定要用 age ,反正上 KMS 也行。

            3 个月 后

            更新一下当前的完成情况:

            1. GitHub 与公司的 Git 仓库密钥做了全面更新,区分了工作密钥、个人密钥,个人密钥也做了一些细分,而且所有密钥都设置了比较强的 passphrase。
              1. 这套方案用了两三个月,感觉很舒服,够安全,也不麻烦,每次开机后输入一次密码就行。
            2. 系统的全盘加密因为感觉略麻烦,还没有做。
            3. 比较有价值的 GitHub 仓库,都设置了禁止 force push 主分支,并且偶尔会手动同步到 gitee 作为备份。
              1. 后续应该把备份做成自动化的。

            回想起来,我是比较坚定的开源主义者,我个人的大多数笔记、博客、项目,都全部公开在 GitHub 上,隐私数据在 commit 之前先加密。

            实话说我也曾经在折腾博客仓库时泄漏过隐私数据,当时很慌。
            但现在回想起来,我仍然觉得用我的博客仓库来实践一些开源仓库的加密策略,帮我养成关注数据安全的意识与习惯,是很好的做法,这也让我学会了许多密码学相关的知识。

            这就类似 Google 的零信任架构,避免安全隐患最好的方法,或许就是把自己时刻暴露在安全风险之下。

            5 天 后

            不知楼主是否考虑过硬件密钥?有闭源的yubikey和国内厂商的开源canokey可选,体验不会差太多。这种硬件密钥的作用非常广泛,基本可以涵盖楼主所说的每一个点:

            • 存储OpenPGP私钥。如果有钱买备用硬件密钥(这也是我的推荐),完全可以把主私钥 (Certification) 与子密钥分开存储,进一步避免硬件密钥丢失导致不得不Revoke整个密钥。
            • 存储OpenSSH私钥。实现方式倒是很多,FIDO2 token存储,OpenPGP 认证子密钥 (Authentication),或者PIV证书,都可以作为SSH密钥对使用。我选择的是FIDO2, 不过这种实现比较麻烦,毕竟Windows上的硬件密钥策略使得OpenSSH不支持即插即用式FIDO2 SSH密钥。不过就我在各大Linux发行版上使用的体验来看,效果还是相当不错的。
            • 2FA. 存储TOTP密钥和直接使用硬件U2F作为双重认证都是常见的手段,MS甚至支持无密码账户使用硬件密钥作为1FA登录。

            说来可惜的是,Canokey虽然实现了FIDO2的HMAC-SHA1拓展,但KeepassXC似乎无法识别Canokey, 不然我就可以用便宜开源的Canokey加密我的密码库了。

            @xdd-ovo 我感觉硬件密钥会让我缺乏安全感——什么时候东西丢了,数据就永远找不回来了。

            另一方面 yubikey 也没那么容易买到,我想如果什么时候我有能力自己制作,我会考虑尝试使用它。

              ryan4yin 确实,使用硬件密钥并不代表不保存私钥的离线备份。比如,可以创建两个密钥,互相加密私钥备份,并离线保存,也可以单独离线保存私钥等等。
              如果想自己制作硬件密钥,那么Canokey给出了一个开源实现。Canokey官方文档中就给出了一个开源版本,使用nRF52840芯片。

              硬件密钥防止丢失这点,Apple的做法是,强制要求每个Hardware Key 2FA用户为自己的账户注册两个硬件密钥,以防止丢失。但这种方法的确无法防止OpenPGP私钥丢失,所以最合理的方法还是保存离线备份。
              我选择硬件密钥的主要原因是,我的工作环境无法确保所有软件尊重我的隐私不读取.gpg中的私钥(你知道我在说谁🤣),因而只能选择把密钥写在write-only的介质内。除此之外,便携私钥也可以满足我多设备签名的需求。

              5 个月 后

              过去大半年了,更新下当前进展:

              1. SSH: SSH 密钥已经做了一次全面的更新,旧的 KEY 全部删除,现在我的 PC/Macbook/Android 都分别使用本地生成的 SSH 私钥,并且都设置了 Passphrase 保护,日常使用 ssh-agent 来避免重复输入 Passphrase 解密 SSH Key.
              2. 个人账号密码:采用了 pass - the standard unix password manager 这套开源方案,目前所有站点、APP 的账号密码都全部使用此方案存储,使用 GPG 子密钥加密。GPG 主密钥及吊销证书均离线保存。
              3. 2FA: 目前是在我的手机与平板上分别导入了我所有的 2FA 信息,暂无备份,打算近期使用多个 LUKS 加密 U 盘做双备份。
              4. 桌面电脑:采用 LUKS2 全盘加密,启动阶段输入 16 位强密码解密后才能正常启动 NixOS,参数都设得挺高,感觉强度挺可以。
              5. 其他:近期打算再全面替换下 Homelab 以及其他重要账号的密码跟 backup code,然后 backup code 全部离线加密保存。

              目前感觉 argon2 加上比较高的迭代次数,安全性还是挺可以的,硬件密钥或许等下一次对安全感兴趣的时候再弄一弄了。

              近期可公开的一些进展:

              1. 注销印象笔记账号,使用 evernote-backup 跟 evernote2md 两个工具将个人的私密笔记迁移到了一个私有 Git 仓库,用 GitJournal APP 在手机上查看编辑笔记,电脑端则是用 Emacs/Neovim。用了三四天挺顺手的。
              2. 调研了跨平台的全盘加密方案,最后发现 rclone 的加密模式貌似是最好用的,看相关 issue 的讨论看安全性也还行(至少比 VeraCrypto 好不少...要是能自行设定一些密码学参数就更好了...),而且还能很方便地加密同步到国内的对象存储中做多备份,打算后续所有需要跨平台传输的或备份的数据,都用这个方案。所有 U 盘在完全清理后,将不再保存任何明文的重要数据,全部用 rclone 加密。
              3. 简单研究了下开源的硬件密钥方案,目前看 Canokey 比较 OK,列入备选计划,但暂时不打算实施。
              4. 基于上述的一些调研,近期梳理并形成了第二阶段的个人数据安全强化方案,打算在最近两三个月完成方案落地。
              5. 计划最近再深入学习下 GPG/OpenSSH/LUKS 的底层实现,确认下 GPG/OpenSSH 的 passphrase 安全性,以及 LUKS2 + passphrase 的安全强度。
              6. 学习下 appamor 及 bubblewrap 两项 Linux 下的安全限制方案,尝试应用在我的 NixOS PC 上。

              其他跟安全有一定关联的计划与进展:

              1. All in NixOS: 将 Homelab 中对我而言偏黑盒且可复现性差的 Ubuntu、Kubernetes 集群节点、OpenWRT 等 VM (乃至底层的 Proxmox VE)全面替换成更白盒且可复现性强的 NixOS,提升我对内网环境的掌控度,进而提升内网安全性。这是一个长期计划,没有明确的时间线,不过希望能在 2024 年完成这个工作。

              最近在安全上考虑了许多,越来越觉得安全是一场持久战,往下挖是没有底的。
              安全总是相对的,而且其中涉及的知识点不少,我去年自学密码学算是为此打下了个不错的基础,但目前看前头还有挺多知识点在等待着我。
              目前仍然打算以比较 casual 的心态去推进这件事情,什么时候有兴趣就推进一点点,到 2024 年底,我想应该能达到一个比较不错的状态。

              5 天 后

              2024-01-26 更新对 OpenSSH 密钥的生成逻辑调研文档

              OpenSSH 的 passphrase 是如何实现的?是否足够安全?

              首先 Google 了下,一些相关的文章:

              OpenSSH release notes 中搜索 passphrase 跟 kdf,关键信息如下:

              OpenSSH 9.4/9.4p1 (2023-08-10)
              
               * ssh-keygen(1): increase the default work factor (rounds) for the
                 bcrypt KDF used to derive symmetric encryption keys for passphrase
                 protected key files by 50%.
              
              ----------------------------------
              
              OpenSSH 6.5/6.5p1 (2014-01-30)
              
               * Add a new private key format that uses a bcrypt KDF to better
                 protect keys at rest. This format is used unconditionally for
                 Ed25519 keys, but may be requested when generating or saving
                 existing keys of other types via the -o ssh-keygen(1) option.
                 We intend to make the new format the default in the near future.
                 Details of the new format are in the PROTOCOL.key file.

              所以从 2014 年发布的 OpenSSH 6.5 开始,ed25519 密钥的 passphrase 才是使用 bcrypt KDF 生成的。
              而对于其他类型的密钥,仍旧长期使用基于 MD5 hash 的密钥格式,可以说毫无安全性可言。

              我进一步看了 man ssh-keygen 的文档,没找到任何修改 KDF 算法的参数,不过能通过 -a 参数来修改 KDF 的 rounds 数量,
              OpeSSh 9.4 的 man 信息中写了默认使用 16 rounds.

              因为大部分人都使用默认参数生成 Key,而且绝大部分用户都没有密码学基础,大概率不知道 KDF、Rounds 是什么意思。
              在 relase note 中我进一步找到这个:

              OpenSSH 9.5/9.5p1 (2023-10-04)
              
              Potentially incompatible changes
              --------------------------------
              
               * ssh-keygen(1): generate Ed25519 keys by default. Ed25519 public keys
                 are very convenient due to their small size. Ed25519 keys are
                 specified in RFC 8709 and OpenSSH has supported them since version 6.5
                 (January 2014).

              9.5 开始才是默认生成 ED25519 的 ssh key,所以可以推断出,目前大部分人使用的 ssh key,大概率加密方式都很糟糕。
              不加 passphrase 就是裸奔,加了也很容易被破解。

              总结下,在不考虑其他硬件密钥/SSH CA 的情况下,最佳的 SSH Key 生成方式应该是:

              ssh-keygen -t ed25519 -a 256 -C "xxx@xxx"

              即使用 ED25519 密钥,KDF rounds 也要调到比默认值更高,这样生成的密钥才能更安全。
              rounds 的值根据你本地的 CPU 性能来定,
              我在 Macbook Pro M2 上测了下,64 rounds 大概是 0.5s,128 rounds 大概需要 1s,256 rounds 大概 2s,用时与 rounds 值是线性关系。

              考虑到我的个人电脑性能都还挺不错,而且只需要在每次重启电脑后通过 ssh-add ~/.ssh/xxx 解锁一次,后续就一直使用内存中的密钥了,一两秒的时间还是可以接受的。

              SSH CA - 更安全合理的 SSH 密钥管理方案?

              搜到些资料:

              TODO

              以及对 OpenPGP 的密钥生成与 passphrase 安全性调研:

              0. How GnuGP generate & protect your keypair?

              Related Docs:

              GnuPG generate every secret key separately, and encrypt them with a symmetric key derived from your passphrase.
              OpenPGP standard defines String-to-Key (S2K)
              algorithm to derive a symmetric key from your passphrase.

              GnuPG's OpenPGP protocol specific options shows that:

              --s2k-cipher-algo name
              
                  Use name as the cipher algorithm for symmetric encryption with a passphrase if --personal-cipher-preferences and --cipher-algo are not given. The default is AES-128.
              --s2k-digest-algo name
              
                  Use name as the digest algorithm used to mangle the passphrases for symmetric encryption. The default is SHA-1.
              --s2k-mode n
              
                  Selects how passphrases for symmetric encryption are mangled. If n is 0 a plain passphrase (which is in general not recommended) will be used, a 1 adds a salt (which should not be used) to the passphrase and a 3 (the default) iterates the whole process a number of times (see --s2k-count).
              --s2k-count n
              
                  Specify how many times the passphrases mangling for symmetric encryption is repeated. This value may range between 1024 and 65011712 inclusive. The default is inquired from gpg-agent. Note that not all values in the 1024-65011712 range are legal and if an illegal value is selected, GnuPG will round up to the nearest legal value. This option is only meaningful if --s2k-mode is set to the default of 3.

              The strongest options should be:

              gpg --s2k-mode 3 --s2k-count 65011712 --s2k-digest-algo SHA512 --s2k-cipher-algo AES256 ...

              To use the strongest options globally, you can specify these options in your ~/.gnupg/gpg.conf.

              已根据今天的调研成果,重新生成了一遍我所有重要的带有 passphrase 的 SSH Key,以及
              OpenPGP Key.

              从去年发这个帖子到现在,我觉得我个人的数据安全性已经上升了一个次元(

              ryan4yin 更改标题为「学习并强化个人的数据安全性(持续更新)

              能加密则加密,鸡蛋分开放在不同的篮子里,这大概就是个人数据层面的 zero trust

              新进展:更新了一遍我所有重要账号的密码、Backup Codes 等数据,并且所有相关的备份数据全部使用 rclone/age 离线加密存储,这两个工具使用的 scrypt 跟 Chacha20-Poly1305/XSalsa20 都是非常现代的密码算法,我设置的 passphrase 跟对称密钥长度也都挺够,个人认为我当前的数据安全性已经挺 OK 了。

              30 多个账号改了大半天,微信、QQ、GitHub、Google、Meta、Apple、Macbook/NixOS 密码、等等一堆的账号。

              目前就只有一些不常用的站点懒得更新,重要账号的密码全部重新生成了一遍随机密码,通过 pass 存储,gpg 加密,用 git 仓库多端同步。

              做到这个程度,我觉得说句「固若金汤」不为过吧,再进一步的话就是硬件密钥了。

              下一步打算做的是 Homelab 跟 NAS 的安全加固,以及手机端照片视频等数据的加密同步,这部分以前也考虑得比较少,年后再折腾了~

              © 2018-2025 0xFFFF