使用 TPM 安全地保存 SSH 私钥

[lyc8503]

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

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

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

[kenvix]

你可以在美国用中国 TPM ，在中国用美国 TPM

[dingwen07]

这么怕为什么不去买个 GPG 智能卡

顺便，TPM 哪里有后门，还是说你用的不是 Intel 、AMD 处理器？就算有后门也是在主板的安全启动证书上面。

国产 SSH 又是什么东西

[lyc8503]

@dingwen07 sorry 手贱我指的是国产 TPM, 用的就是虚拟智能卡, 关于 TPM 有没有后门可能有些争议, 但有些人认为国内的机型有, 没有实际证据.

[hyshuang2006]

SSH 私钥，设置上数十位密码，妥妥的安心。
TPM ？设备坏了怎么办？

[AS4694lAS4808]

海淘个 ThinkPad ，自带 tpm 芯片

[hikigaya58]

今天刚学习了 TPM ，按照您贴的 url 操作，换了 CPU 是不是再也找不到私钥了（ TPM 一般集成在 CPU 内？）？

[lindt99cocoa]

yubikey 可能更靠谱一点

[hikigaya58]

@hikigaya58 不过确实是一个很好的思路，可惜似乎没有足够的生态支持？尝试过基于浏览器的通行密钥（ passkey ），过程很丝滑。

[monster1priest]

《商用密码管理条例》规定了商用密码产品由国家密码管理机构指定的单位生产、销售，包括个人使用自行研制的或者境外生产的密码产品也是禁止的。

国内只能使用自主研发的 TCM

[feedcode]

这个方式备份是个问题。
可以先用 openssl 生成 pkcs12, 然后再导入到 windows 里并标记成不可导出，同时备份并删除 pkcs12 文件，可以参考

https://orca.pet/sshtpm/
https://playbooks.idmanagement.gov/piv/engineer/ssh/

[Owenjia]

tpm2 的可靠程度不如 openpgp card 吧……
怕丢可以干净环境生成 gpg 密钥离线备份然后 keytocard ，
日常通过 SSH_AUTH_SOCK 指向 gpg-agent 认证登录，
或者拿来做 ca 给 ssh key 签名设有效期，有条件的话还可以限制可用源地址，然后服务器只放 ca 公钥，本地 ssh key 加密码，泄漏就 revoke 。

[ihciah]

mac 有 Secure Enclave 提供你想要的这个能力，有一个基于这个机制实现的东西 github.com/maxgoedjen/secretive

[ysc3839]

@monster1priest 新修订的《商用密码管理条例》：大众消费类产品所采用的商用密码不实行进口许可和出口管制制度。
https://www.gov.cn/zhengce/content/202305/content_6875927.htm

[fsdrw08]

可以用 sops 做 key 文本加密

[lyc8503]

@hyshuang2006 @AS4694lAS4808 @feedcode TPM 的意义就在于密钥不可提取, 设备损坏或丢失密钥就没了, 要准备其他恢复方式, 比如 VPS 控制台重置, 物理接触服务器恢复等

@ihciah 看到过, 但我用的是 Windows 所以才研究出了这种方法

[jim9606]

我试过用 Intel 和 AMD 的 fTPM 生成 X.509 密钥（跟 vSC 密封在 TPM 内），但只能是 RSA 的，EC 貌似不支持。

这种方案是拿机器作为认证因子的，跟 YubiKey 等分离实体 key 用途不一样，两者可以类比（指纹+设备）认证和支付密码认证，前者由后者授权，前者追求便利，后者长期离线少暴露作为信任根使用。

个人感觉可以加上安全启动、VBS 、Credential Guard 和 TPM 保护的 Bitlocker 系统盘加密，关联的是 CPU/南桥+UEFI 固件+Windows 签名+用户证书存储区（在系统盘上）。这样就跟 Android 的 TEE 安全方案差不多强度了。正常途径换设备要重新授权。

[ysc3839]

@hikigaya58 是的。按网上说法，fTPM 的数据是用 CPU 内部不可导出的密钥加密的，存在 BIOS 芯片里，所以换 CPU 会使数据不可解密。但许多 BIOS 可以保留数据，换回 CPU 后还可以解密。

[suriv520]

1. 允许在境内合法销售的电子设备的密钥体系都必须要符合“国标化”要求的。这是法律要求，也是业界常识。
2. 境内合法销售的个人电脑、平板、手机上的 TPM/加密芯片硬件都必须是指定的公司生产的，这是可信计算的基石，比如境内销售的 Thinkpad 用的 NTZ TPM 芯片：www.nationstech.com
3. 国标对芯片中预埋的“国密”等算法做了要求，这也是强制标准
4. 严格意义来讲，你使用未经认证的 OpenSSL 加密境内服务器中的数据，是违法的。
5. 每一台合法销售的操作系统，包括你现在正在用的 Windows ，包括手机、系统都里已经预埋了中国机构签发的可信根证，安装的时候就埋好了。这也是上述法律要求的体现之一。（所以别跟我说什么 HTTPS 通信不能监听，那得看是谁想听）
6. 最近有一款和 Intel 合作的“国产”暴芯(Powerstar) CPU 处理器。除了国产化采购等目的，你猜猜里面预埋的证书和算法有没有做“合规”？

我上面说的没有做任何推断与猜测，仅列举事实。

“密钥”也不是法外之地。

[baobao1270]

@suriv520
1. 并不是这样。许多个人或商用电脑，都会带有国际标准的 TPM 芯片。它们不支持 SM 算法。一般国内销售时禁用，但是用户可以主动打开（会弹出警告「 TPM 可能在您的国家违法」之类的）。商用采购的时候，在 BOM 物料清单上会有一条「已禁用 TPM 」或「已移除 TPM 」以满足合规要求。
2. OpenSSL 作为软件，不在《条例》管辖范围内。《条例》仅针对硬件产品。
3. 操作系统里确实有国产根证书，但是只有一个 CFCA 。这个去根证书列表里看一下就知道了。我国没有法律规定操作系统必须安装国产证书。而且，预置证书与否，决定权在操作系统厂商，比如之前 CNNIC 的证书就被吊销了。而国产根也必须在国际的 CT 机制下行事，接受国际标准的审计，如果作恶也会被移出根证书列表。所以除非动用量子计算机，HTTPS 确实不能被监听，即使是国家级的力量也不行。如果你实在不放心，可以选择手动吊销 CFCA 证书。
4. 我没有听说过 CPU 里有「预装证书」的说法。但是国产的 CPU 基本都会选择支持 SM ，因为这是卖点。

[suriv520]

@baobao1270 多谢解释！看得出来你是做过研究的。

1. 针对电脑，DELL 有一篇知识库文章写得挺清楚了： https://support.hp.com/cn-zh/document/ish_5031748-5050162-16 ，包括前因后果与变更。你肯定也了解多年前很多电脑 /平板无法进入大陆市场的原因。在 Windows11 强制要求 TPM 之后，针对这个合规的谈判与拉扯又进行了很多轮，最终导致了现在“原则上不合规，实际上你们自己看着来，只要不是关键采购，我睁一只眼闭一只眼”的状态。

2. 无论是《密码法》还是《商用密码管理条例》，针对的都是“包含密码的产品”，不存在软硬件的区别。很多系统都是软硬件一体销售。

3. 谢谢进一步确认，并印证我说的。1. 埋了。2. 曾经还被抓包了。

4. 谢谢进一步确认，并印证我说的。CPU 的预埋 TPM ，参考 Intel PTT 与 AMD fTPM 。

[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 从一个地方集中读取公钥，但是这样一来又有新的加固点需要去维护

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