Linux 服务器中如何安全的存储私钥文件？

[raw0xff]

由于自己的应用需要用到私钥进行签名，所以私钥文件需要存储在服务器中。那么如何存储私钥文件比较靠谱呢？有没有什么方式再设置一层私钥的密钥，使人即便拥有了 root 权限也无法得知私钥？前提是应用可以正常获取私钥。

[tomychen]

你这个假设是 root 是不安全用户

这种场景下，怎么做才安全呢，你要解决的不是一个文件的存储问题，而是把场景切换的问题。

[EvineDeng]

以我极有限的知识，我仅知道 p12 证书可以再设置一层证书密码，使用时需要验证密码。

[virusdefender]

即使 p12 设置了密码，那 root 用户也能看到。如果真的需要那么高的安全性，你应该换硬件签名设备。

[adoal]

学术人：想办法搞一个可以没有 super user 的用户权限模型的操作系统。
运维人：限制无关人士登录/切换身份的权限。

[tomychen]

@adoal 这不就是等保最初的概念三权分立嘛

[tomychen]

app 要访问私钥进行签名...所以即使设置密码，密码也必然会在 app 内保存，至于怎么储存(加密）等，这些在 root 的面前，只是时间的问题。

[deplivesb]

假定 root 是不安全的，那就需要 yubikey 这种硬件设备了

[seers]

把签名封装成接口

[GeruzoniAnsasu]

私钥本来就可以用 passphrase 保护，要清除私钥的 passphrase 需要正确输入一次

这个机制可以理解为用对称加密将你的私钥额外加密一次，对称加密的 pass 放在你脑子里。

[proxychains]

@adoal 学院派和工程派

[a1274598858]

HSM 硬件安全模块

[flyingfz]

HashiCorp 有个 叫做 vault 的 东西， 就是专门处理这种机密信息的系统。
推荐看看。

[t123yh]

买一个 yubikey 或者 canokey

[yinmin]

如果是 docker 部署的，可以使用 docker secret 命令添加 pfx 密码，然后在 Docker Compose 中引入密码，程序使用 pfx+secret 密码去签名。

[yanqiyu]

HSM ，管理员物理带在身上，需要签名的时候插上去

[4kingRAS]

签名的频率大吗，不大就物理加密狗，大就做成服务，内网远程调用签名

[raw0xff]

@4kingRAS 签名不规律，均值在每秒一次。

[MetroWind]

把密钥相关功能单拎出来放到另一台 PKI 服务器上，上面可以跑个 HashiCorp Vault 或者 CFSSL 类似的东西，不用的时候关机断网。

[ltkun]

搞个 2FA 认证？

[Vieufoux]

Vault

[julyclyde]

@tomychen 等级保护那些，感觉是不太工程的人拍脑瓜随便写的

[kwest]

简单做法：对签名私钥加密生成加密文件，应用中内嵌（ hardcoded ）加密签名私钥的 passphrase ，这里假设应用程序是二进制 native 可执行文件，再加入一些混淆技术防止 hacker 轻松反编译。即使 hacker 获取了 root 权限，想获取加密签名私钥的 passphrase 也得先反汇编你的应用程序。这种内嵌 passphrase 的方式一般不推荐，不过如果是后台 daemon 程序有时候不得不这么做。当然，更安全的做法是等用户需要签名私钥时，弹出对话框提示用户输入 passphrase ，解密加密文件得到签名私钥，但这需要应用程序和用户交互。

复杂做法（可信计算）：上 TPM 芯片，签名根证书放在 TPM 中，建立从 Bootloader 到 OS ，从 OS 到 Application 的证书签名信任链。硬件启动 Bootloader 时验签，Bootloader 启动 OS 时验签，OS 启动 Application 时也验签，任一环节验签失败都不会进入下一环节。你的应用程序也需要被 TPM 中的根证书或下级证书签名，任何无签名或非 TPM 证书签名的命令行或应用程序都没法成功运行，这样即使 hacker 获取了 root 权限，也知晓了 TPM 的 API 接口，他自己写的程序也没法运行成功，因为他的程序没有被 TPM 证书或下级证书签名，不被 TPM 证书信任链信任。

[raw0xff]

@kwest
程序运行环境是云主机，所以与物理硬件相关的做法不现实。
程序也是无人操作的，等待用户输入 passphrase 也不现实。
按你说的将私钥加密，将 passphrase 写入代码，混淆后编译，甚至代码中再在运行时做些花样。我想知道这样操作一通究竟会给反编译造成多大的难度 有没有意义？我也不知道有什么恰当的比喻，有破解比特币以太坊钱包私钥难度的万分之一吗？毕竟还需要考虑自身价值值不值得别人去反编译。

[kwest]

@raw0xff
值不值得你花费大量时间去设计复杂的密码保护措施，取决于密钥的重要程度。
假设你的云主机有防火墙，Linux 系统也及时升级了安全补丁，你认为你的系统固若金汤，几乎不可能被 hacker 攻破获取到 root 权限，那你就把密钥明文存放在 Linux 的某个文件中，将文件权限设为 root 只读，这样也不是不可以。
假设你的云主机没有防火墙，Linux 系统也没有靠谱的管理员去维护升级安全补丁，甚至这台云主机还允许开发和测试随意登陆，那你的密钥保护措施就必须设计得很复杂很严密。
前置条件不同，你的密钥保护措施也截然不同，安全不是由单个因素决定的，是多个因素共同决定，没有什么银弹方案能确保绝对的万无一失。安全性取决于你的需求以及愿意付出的成本（时间成本，管理成本，人力成本，设备成本等等），安全是有成本的，抛开成本去谈安全就是耍流氓。
所以，你这个场景是要求 root 权限即使被 hacker 获取了也无法得知密钥，本身对密钥管理方式提出了很高的要求，毕竟在 Linux 系统下 root 是最高权限，而 root 权限是系统的安全底线，root 权限都被突破了还要保证密钥安全，势必要求付出更多的成本（比如我上面提到的 TPM 芯片 + 可信计算），你不能既要安全性又不肯付出 money ，世界上可没有两全其美的事。

[raw0xff]

@kwest 赞同老哥的观点。由于对没接触过汇编反编译，不知道从二进制文件中获取到哪怕混淆过的私钥片段再还原私钥的难度到底有多大，完全没概念。如果难度不是一般大的话，我觉得把 passphrase 写入二进制文件是比较适合我的。