这是一个创建于 493 天前的主题，其中的信息可能已经有所发展或是发生改变。
由于自己的应用需要用到私钥进行签名，所以私钥文件需要存储在服务器中。那么如何存储私钥文件比较靠谱呢？有没有什么方式再设置一层私钥的密钥，使人即便拥有了 root 权限也无法得知私钥？前提是应用可以正常获取私钥。
 |
1
tomychen 2023-07-20 12:02:27 +08:00
你这个假设是 root 是不安全用户
这种场景下，怎么做才安全呢，你要解决的不是一个文件的存储问题，而是把场景切换的问题。 |
 |
2
EvineDeng 2023-07-20 12:03:49 +08:00
以我极有限的知识，我仅知道 p12 证书可以再设置一层证书密码，使用时需要验证密码。
|
 |
3
virusdefender 2023-07-20 12:05:31 +08:00
即使 p12 设置了密码，那 root 用户也能看到。如果真的需要那么高的安全性，你应该换硬件签名设备。
|
 |
4
adoal 2023-07-20 12:07:20 +08:00  1
学术人：想办法搞一个可以没有 super user 的用户权限模型的操作系统。
运维人：限制无关人士登录/切换身份的权限。 |
|
6
tomychen 2023-07-20 12:10:13 +08:00
app 要访问私钥进行签名...所以即使设置密码，密码也必然会在 app 内保存，至于怎么储存(加密）等，这些在 root 的面前，只是时间的问题。
|
 |
7
deplivesb 2023-07-20 12:28:13 +08:00
假定 root 是不安全的，那就需要 yubikey 这种硬件设备了
|
 |
8
seers 2023-07-20 13:07:05 +08:00 via Android
把签名封装成接口
|
 |
9
GeruzoniAnsasu 2023-07-20 13:10:00 +08:00
私钥本来就可以用 passphrase 保护，要清除私钥的 passphrase 需要正确输入一次
这个机制可以理解为用对称加密将你的私钥额外加密一次，对称加密的 pass 放在你脑子里。 |
 |
10
proxychains 2023-07-20 13:38:39 +08:00
@adoal 学院派和工程派
|
 |
11
a1274598858 2023-07-20 14:08:33 +08:00
HSM 硬件安全模块
|
 |
12
flyingfz 2023-07-20 15:03:20 +08:00
HashiCorp 有个 叫做 vault 的 东西， 就是专门处理这种机密信息的系统。
推荐看看。 |
 |
13
t123yh 2023-07-20 15:05:03 +08:00
买一个 yubikey 或者 canokey
|
 |
14
yinmin 2023-07-20 16:01:36 +08:00
如果是 docker 部署的，可以使用 docker secret 命令添加 pfx 密码，然后在 Docker Compose 中引入密码，程序使用 pfx+secret 密码去签名。
|
 |
15
yanqiyu 2023-07-20 16:03:50 +08:00
HSM ，管理员物理带在身上，需要签名的时候插上去
|
 |
16
4kingRAS 2023-07-20 16:08:16 +08:00
签名的频率大吗，不大就物理加密狗，大就做成服务，内网远程调用签名
|
 |
18
MetroWind 2023-07-21 02:41:57 +08:00
把密钥相关功能单拎出来放到另一台 PKI 服务器上，上面可以跑个 HashiCorp Vault 或者 CFSSL 类似的东西，不用的时候关机断网。
|
 |
19
ltkun 2023-07-21 08:01:10 +08:00 via Android
搞个 2FA 认证？
|
 |
20
Vieufoux 2023-07-21 08:38:37 +08:00
Vault
|
 |
22
kwest 2023-08-02 00:00:25 +08:00
简单做法：对签名私钥加密生成加密文件，应用中内嵌（ 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 证书信任链信任。 |
 |
23
raw0xff OP @kwest
程序运行环境是云主机，所以与物理硬件相关的做法不现实。 程序也是无人操作的，等待用户输入 passphrase 也不现实。 按你说的将私钥加密，将 passphrase 写入代码，混淆后编译，甚至代码中再在运行时做些花样。我想知道这样操作一通究竟会给反编译造成多大的难度 有没有意义？我也不知道有什么恰当的比喻，有破解比特币以太坊钱包私钥难度的万分之一吗？毕竟还需要考虑自身价值值不值得别人去反编译。 |
|
24
kwest 2023-08-02 21:02:23 +08:00
@raw0xff
值不值得你花费大量时间去设计复杂的密码保护措施，取决于密钥的重要程度。 假设你的云主机有防火墙，Linux 系统也及时升级了安全补丁，你认为你的系统固若金汤，几乎不可能被 hacker 攻破获取到 root 权限，那你就把密钥明文存放在 Linux 的某个文件中，将文件权限设为 root 只读，这样也不是不可以。 假设你的云主机没有防火墙，Linux 系统也没有靠谱的管理员去维护升级安全补丁，甚至这台云主机还允许开发和测试随意登陆，那你的密钥保护措施就必须设计得很复杂很严密。 前置条件不同，你的密钥保护措施也截然不同，安全不是由单个因素决定的，是多个因素共同决定，没有什么银弹方案能确保绝对的万无一失。安全性取决于你的需求以及愿意付出的成本（时间成本，管理成本，人力成本，设备成本等等），安全是有成本的，抛开成本去谈安全就是耍流氓。 所以，你这个场景是要求 root 权限即使被 hacker 获取了也无法得知密钥，本身对密钥管理方式提出了很高的要求，毕竟在 Linux 系统下 root 是最高权限，而 root 权限是系统的安全底线，root 权限都被突破了还要保证密钥安全，势必要求付出更多的成本（比如我上面提到的 TPM 芯片 + 可信计算），你不能既要安全性又不肯付出 money ，世界上可没有两全其美的事。 |
Select Language