使用 TPM 安全地保存 SSH 私钥

[lyc8503]

和这个帖子中有一样的担忧 https://www.v2ex.com/t/873915
后来给私钥加了密码, 但密码太简单等于没加, 足够复杂输入起来又很麻烦(而且密码也可能被 keylogger 盗取)

所以研究了一下在 Windows 下如何使用 TPM 来进行 SSH 的鉴权: https://blog.lyc8503.site/post/ssh-with-tpm/

感觉这种方式更加安全, 虽说国产 SSH 可能有后门, 但至少比以文件形式保存私钥安全了. (据我所知, 要利用 TPM 的漏洞 /后门至少需要物理接触.)

[HikariLan]

@suriv520 我没记错的话，TPM 1.0 不支持 SM1/SM2 ，但是 TPM 2.0 是支持的啊。Windows 11 的最低操作系统要求就是 TPM 2.0 。这也是后来在中国大陆销售的计算机可以内置并默认启用 TPM 的原因。

[suriv520]

@HikariLan 你前面说的都是对的。但是“这也是后来在中国大陆销售的计算机可以内置并默认启用 TPM 的原因”这句话没有得到充分论证。
P.S. 我认为国密算法和其它几种主流算法一样都是安全的。

[HikariLan]

@suriv520 TPM 2.0 主要是提供了足够的可拓展性，允许不同的加密算法使用 TPM 。早年在中国销售的计算机都是默认关闭 TPM 的，即使是 2.0 ，Windows 11 发布后才逐渐开放（我朋友的鸿基笔记本就是这么个情况，还需要去官网下载固件来解锁 TPM ）

[Jirajine]

@baobao1270 如果我理解的不错的话，CT 可以保证无法在公网环境下大规模部署 mitm 攻击，但不能防止部署于私域网络下和针对特定目标的攻击。
也就是对于国家级机构的高价值目标来说使用 PKI 的 HTTPS 可以认为是不安全的，无论吊销哪家 CA ，你都不能确定其他 CA 中没有和国家级力量合作。
所以除非像 GFW 一样部署广泛的 mitm 解密，不然没有必要规定预置专有根证书也足以监控特定目标的流量。

[baobao1270]

@Jirajine

首先现有的 PKI 体系有两个攻击面，一个是 CA 角度的，也就是利用 CA 的错误或者让 CA 故意颁发错误的证书。一个是在客户端角度的，也就是修改客户端的根证书列表。

「 CT 可以保证无法在公网环境下大规模部署 MITM 攻击」：CT 并不能保证什么，它只能有限地增加安全性。必须意识到这一点，没有绝对的安全，CT 只不过是加了一把钥匙。CT 是针对 CA 的，如果 MITM 有能力在客户端植入证书，那么 CT 无能为力。

「但不能防止部署于私域网络下和针对特定目标的攻击」：可以，最简单的例子就是：只要不安装客户端，公司的审计软件就无法获取到你的 HTTPS 浏览记录（当然 SNI 是明文的可以被获取）



「高价值目标来说使用 PKI 的 HTTPS 可以认为是不安全的」：高价值目标应该有选择性的信任 CA ，并吊销信用不好的证书。我自己的习惯就是任何设备到手先删掉 CFCA 。

「无论吊销哪家 CA ，你都不能确定其他 CA 中没有和国家级力量合作」：还是那句话，没有绝对的安全。你总归有个东西要去信任的。没有绝对不受限制的东西，你只能做到「在中国用 Pixel ，在美国用华为」。

「没有必要规定预置专有根证书也足以监控特定目标的流量」：和公司监控员工的例子一样，你总得想个办法给人家的设备里塞根证书。问题是这很难做到。我很难说攻击特定设备和控制 CA 哪个难一点，说实话我觉得在现代社会都挺难的。

[Jirajine]

@baobao1270 是我表达不清晰，应该为“CT 可以保证无法在不被察觉的情况下公网大规模部署 mitm”，但无法暴露 CA 在私域网络下和针对特定目标的攻击。
所以在此情况下甚至无需在客户端植入额外的证书。

高价值目标不应该信任任何非自建自己掌控私钥的 CA ，CFCA 和其他的有点差别，但差别不大。
“在中国同 pixel ，在美国用华为” 高价值目标不应盲目假定 pixel 不会和中国合作，华为不会和美国合作。

[MoeMoesakura]

@Jirajine 高价值目标确实如此，钱给的够多那谁都难说
所以高价值目标还是用装了 GrapheneOS 的 Pixel 吧（笑

[a33291]

借楼请教下,已经在 id_rsa 文件中的私钥,之前没有加密码,现在是否可以补加密码?

[xyjincan]

cool

[nothingistrue]

SSH 私钥的密码，属于本地 pin ，不网络传输，且只能暴力破解。再目前的安全框架下，本地 pin ，哪怕就是 4 位数字，也是物理级别安全的。

[m1a0]

还是搞两个 yubikey 比较靠谱。

[CodeCodeStudy]

@a33291 #28 可以的，你用 xshell 试一下，加上密码后，私钥会多两行
```
Proc-Type: 4,ENCRYPTED
DEK-Info: DES-EDE3-CBC,F93AC78849AF6892
```

Proc-Type: 4,ENCRYPTED 是固定的，表示私钥已经加密，DEK-Info 的值的逗号前的 DES-EDE3-CBC 是加密算法，逗号后的 F93AC78849AF6892 是 IV ，也拿来做 salt

公钥保持不变

代码可参考 python 的 Cryptodome 包，在 Cryptodome/IO/PEM.py ，这个文件不到两百行

```python
if lines[1].startswith('Proc-Type:4,ENCRYPTED'):
DEK = lines[2].split(':')
algo, salt = DEK[1].split(',')
if algo == "DES-EDE3-CBC":
key = _EVP_BytesToKey(passphrase, salt, 24)
objdec = DES3.new(key, DES3.MODE_CBC, salt)


def _EVP_BytesToKey(data, salt, key_len):
d = [ b'' ]
m = (key_len + 15 ) // 16
for _ in range(m):
nd = MD5.new(d[-1] + data + salt).digest()
d.append(nd)
return b"".join(d)[:key_len]
```

[CodeCodeStudy]

@CodeCodeStudy #32 代码 https://github.com/Legrandin/pycryptodome/blob/master/lib/Crypto/IO/PEM.py

[xabcstack]

在微信收藏里

[flyqie]

这类方案是一个设备一组公私钥？

安全是安全，就是换设备的时候好像不是一般的麻烦。。

[lyc8503]

@flyqie 先用旧设备登录, 添加新设备的公钥, 然后新设备登录删除旧设备的公钥. 一个设备一组公私钥应该是推荐的做法, 私钥本来就不应该离开当前的物理设备.

[adoal]

@lyc8503 到一大堆服务器上添加新的公钥，然后遗漏了一小堆……不过话说如果要登录的服务器数量多的话，应该用签过的密钥，或者用 AuthorziedKeysCommand 从一个地方集中读取公钥，但是这样一来又有新的加固点需要去维护

私钥不离物理设备当然是按理正确的，但还有一个尴尬问题是，旧设备突然物理损坏了，还没来得及用来添加新设备的公钥……