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