使用 TPM 安全地保存 SSH 私钥 - V2EX
V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
请不要在回答技术问题时复制粘贴 AI 生成的内容
lyc8503
V2EX    程序员

使用 TPM 安全地保存 SSH 私钥

  •  
      lyc8503 2023-06-08 22:23:44 +08:00 5732 次点击
    这是一个创建于 922 天前的主题,其中的信息可能已经有所发展或是发生改变。
    和这个帖子中有一样的担忧 t/873915
    后来给私钥加了密码, 但密码太简单等于没加, 足够复杂输入起来又很麻烦(而且密码也可能被 keylogger 盗取)

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

    感觉这种方式更加安全, 虽说国产 SSH 可能有后门, 但至少比以文件形式保存私钥安全了. (据我所知, 要利用 TPM 的漏洞 /后门至少需要物理接触.)
    37 条回复    2023-06-12 16:17:17 +08:00
    kenvix
        1
    kenvix  
       2023-06-08 22:32:02 +08:00   4
    你可以在美国用中国 TPM ,在中国用美国 TPM
    dingwen07
        2
    dingwen07  
       2023-06-08 22:35:49 +08:00 via Android   1
    这么怕为什么不去买个 GPG 智能卡

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

    国产 SSH 又是什么东西
    lyc8503
        3
    lyc8503  
    OP
       2023-06-08 22:39:57 +08:00
    @dingwen07 sorry 手贱我指的是国产 TPM, 用的就是虚拟智能卡, 关于 TPM 有没有后门可能有些争议, 但有些人认为国内的机型有, 没有实际证据.
    hyshuang2006
        4
    hyshuang2006  
       2023-06-08 22:41:37 +08:00
    SSH 私钥,设置上数十位密码,妥妥的安心。
    TPM ?设备坏了怎么办?
    AS4694lAS4808
        5
    AS4694lAS4808  
       2023-06-08 22:44:53 +08:00 via Android
    海淘个 ThinkPad ,自带 tpm 芯片
    hikigaya58
        6
    hikigaya58  
       2023-06-08 22:56:40 +08:00
    今天刚学习了 TPM ,按照您贴的 url 操作,换了 CPU 是不是再也找不到私钥了( TPM 一般集成在 CPU 内?)?
    lindt99cocoa
        7
    lindt99cocoa  
       2023-06-08 22:57:17 +08:00
    yubikey 可能更靠谱一点
    hikigaya58
        8
    hikigaya58  
       2023-06-08 23:00:22 +08:00
    @hikigaya58 不过确实是一个很好的思路,可惜似乎没有足够的生态支持?尝试过基于浏览器的通行密钥( passkey ),过程很丝滑。
    monster1priest
        9
    monster1priest  
       2023-06-08 23:19:49 +08:00 via iPhone
    《商用密码管理条例》规定了商用密码产品由国家密码管理机构指定的单位生产、销售,包括个人使用自行研制的或者境外生产的密码产品也是禁止的。

    国内只能使用自主研发的 TCM
    feedcode
        10
    feedcode  
       2023-06-08 23:25:48 +08:00
    这个方式备份是个问题。
    可以先用 openssl 生成 pkcs12, 然后再导入到 windows 里并标记成不可导出,同时备份并删除 pkcs12 文件,可以参考

    https://orca.pet/sshtpm/
    https://playbooks.idmanagement.gov/piv/engineer/ssh/
    Owenjia
        11
    Owenjia  
       2023-06-08 23:26:56 +08:00
    tpm2 的可靠程度不如 openpgp card 吧……
    怕丢可以干净环境生成 gpg 密钥离线备份然后 keytocard ,
    日常通过 SSH_AUTH_SOCK 指向 gpg-agent 认证登录,
    或者拿来做 ca 给 ssh key 签名设有效期,有条件的话还可以限制可用源地址,然后服务器只放 ca 公钥,本地 ssh key 加密码,泄漏就 revoke 。
    ihciah
        12
    ihciah  
       2023-06-08 23:35:45 +08:00
    mac 有 Secure Enclave 提供你想要的这个能力,有一个基于这个机制实现的东西 github.com/maxgoedjen/secretive
    ysc3839
        13
    ysc3839  
       2023-06-08 23:41:00 +08:00 via Android   1
    @monster1priest 新修订的《商用密码管理条例》:众消费类产品所采用的商用密码不实行进口许可和出口管制制度。
    https://www.gov.cn/zhengce/content/202305/content_6875927.htm
    fsdrw08
        14
    fsdrw08  
       2023-06-08 23:47:54 +08:00 via Android
    可以用 sops 做 key 文本加密
    lyc8503
        15
    lyc8503  
    OP
       2023-06-09 00:13:58 +08:00
    @hyshuang2006 @AS4694lAS4808 @feedcode TPM 的意义就在于密钥不可提取, 设备损坏或丢失密钥就没了, 要准备其他恢复方式, 比如 VPS 控制台重置, 物理接触服务器恢复等

    @ihciah 看到过, 但我用的是 Windows 所以才研究出了这种方法
    jim9606
        16
    jim9606  
       2023-06-09 00:39:55 +08:00
    我试过用 Intel 和 AMD 的 fTPM 生成 X.509 密钥(跟 vSC 密封在 TPM 内),但只能是 RSA 的,EC 貌似不支持。

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

    个人感觉可以加上安全启动、VBS 、Credential Guard 和 TPM 保护的 Bitlocker 系统盘加密,关联的是 CPU/南桥+UEFI 固件+Windows 签名+用户证书存储区(在系统盘上)。这样就跟 Android 的 TEE 安全方案差不多强度了。正常途径换设备要重新授权。
    ysc3839
        17
    ysc3839  
       2023-06-09 00:52:56 +08:00 via Android
    @hikigaya58 是的。按网上说法,fTPM 的数据是用 CPU 内部不可导出的密钥加密的,存在 BIOS 芯片里,所以换 CPU 会使数据不可解密。但许多 BIOS 可以保留数据,换回 CPU 后还可以解密。
    suriv520
        18
    suriv520  
       2023-06-09 01:11:45 +08:00
    1. 允许在境内合法销售的电子设备的密钥体系都必须要符合“国标化”要求的。这是法律要求,也是业界常识。
    2. 境内合法销售的个人电脑、平板、手机上的 TPM/加密芯片硬件都必须是指定的公司生产的,这是可信计算的基石,比如境内销售的 Thinkpad 用的 NTZ TPM 芯片:www.nationstech.com
    3. 国标对芯片中预埋的“国密”等算法做了要求,这也是强制标准
    4. 严格意义来讲,你使用未经认证的 OpenSSL 加密境内服务器中的数据,是违法的。
    5. 每一台合法销售的操作系统,包括你现在正在用的 Windows ,包括手机、系统都里已经预埋了中国机构签发的可信根证,安装的时候就埋好了。这也是上述法律要求的体现之一。(所以别跟我说什么 HTTPS 通信不能监听,那得看是谁想听)
    6. 最近有一款和 Intel 合作的“国产”暴芯(Powerstar) CPU 处理器。除了国产化采购等目的,你猜猜里面预埋的证书和算法有没有做“合规”?

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

    “密钥”也不是法外之地。
    baobao1270
        19
    baobao1270  
       2023-06-09 01:28:14 +08:00   1
    @suriv520
    1. 并不是这样。许多个人或商用电脑,都会带有国际标准的 TPM 芯片。它们不支持 SM 算法。一般国内销售时禁用,但是用户可以主动打开(会弹出警告「 TPM 可能在您的国家违法」之类的)。商用采购的时候,在 BOM 物料清单上会有一条「已禁用 TPM 」或「已移除 TPM 」以满足合规要求。
    2. OpenSSL 作为软件,不在《条例》管辖范围内。《条例》仅针对硬件产品。
    3. 操作系统里确实有国产根证书,但是只有一个 CFCA 。这个去根证书列表里看一下就知道了。我国没有法律规定操作系统必须安装国产证书。而且,预置证书与否,决定权在操作系统厂商,比如之 CNNIC 的证书就被吊销了。而国产根也必须在国际的 CT 机制下行事,接受国际标准的审计,如果作恶也会被移出根证书列表。所以除非动用量子计算机,HTTPS 确实不能被监听,即使是国家级的力量也不行。如果你实在不放心,可以选择手动吊销 CFCA 证书。
    4. 我没有听说过 CPU 里有「预装证书」的说法。但是国产的 CPU 基本都会选择支持 SM ,因为这是卖点。
    suriv520
        20
    suriv520  
       2023-06-09 01:53:48 +08:00
    @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
        21
    HikariLan  
       2023-06-09 02:07:27 +08:00
    @suriv520 我没记错的话,TPM 1.0 不支持 SM1/SM2 ,但是 TPM 2.0 是支持的啊。Windows 11 的最低操作系统要求就是 TPM 2.0 。这也是后来在中国大陆销售的计算机可以内置并默认启用 TPM 的原因。
    suriv520
        22
    suriv520  
       2023-06-09 02:17:11 +08:00
    @HikariLan 你前面说的都是对的。但是“这也是后来在中国大陆销售的计算机可以内置并默认启用 TPM 的原因”这句话没有得到充分论证。
    P.S. 我认为国密算法和其它几种主流算法一样都是安全的。
    HikariLan
        23
    HikariLan  
       2023-06-09 03:59:03 +08:00
    @suriv520 TPM 2.0 主要是提供了足够的可拓展性,允许不同的加密算法使用 TPM 。早年在中国销售的计算机都是默认关闭 TPM 的,即使是 2.0 ,Windows 11 发布后才逐渐开放(我朋友的鸿基笔记本就是这么个情况,还需要去官网下载固件来解锁 TPM )
    Jirajine
        24
    Jirajine  
       2023-06-09 06:30:39 +08:00
    @baobao1270 如果我理解的不错的话,CT 可以保证无法在公网环境下大规模部署 mitm 攻击,但不能防止部署于私域网络下和针对特定目标的攻击。
    也就是对于国家级机构的高价值目标来说使用 PKI 的 HTTPS 可以认为是不安全的,无论吊销哪家 CA ,你都不能确定其他 CA 中没有和国家级力量合作。
    所以除非像 GFW 一样部署广泛的 mitm 解密,不然没有必要规定预置专有根证书也足以监控特定目标的流量。
    baobao1270
        25
    baobao1270  
       2023-06-09 06:44:26 +08:00
    @Jirajine

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

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

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



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

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

    「没有必要规定预置专有根证书也足以监控特定目标的流量」:和公司监控员工的例子一样,你总得想个办法给人家的设备里塞根证书。问题是这很难做到。我很难说攻击特定设备和控制 CA 哪个难一点,说实话我觉得在现代社会都挺难的。
    Jirajine
        26
    Jirajine  
       2023-06-09 06:52:57 +08:00
    @baobao1270 是我表达不清晰,应该为“CT 可以保证无法在不被察觉的情况下公网大规模部署 mitm”,但无法暴露 CA 在私域网络下和针对特定目标的攻击。
    所以在此情况下甚至无需在客户端植入额外的证书。

    高价值目标不应该信任任何非自建自己掌控私钥的 CA ,CFCA 和其他的有点差别,但差别不大。
    “在中国同 pixel ,在美国用华为” 高价值目标不应盲目假定 pixel 不会和中国合作,华为不会和美国合作。
    MoeMoesakura
        27
    MoeMoesakura  
       2023-06-09 07:27:27 +08:00 via Android
    @Jirajine 高价值目标确实如此,钱给的够多那谁都难说
    所以高价值目标还是用装了 GrapheneOS 的 Pixel 吧(笑
    a33291
        28
    a33291  
       2023-06-09 08:42:04 +08:00
    借楼请教下,已经在 id_rsa 文件中的私钥,之前没有加密码,现在是否可以补加密码?
    xyjincan
        29
    xyjincan  
       2023-06-09 08:46:46 +08:00
    cool
    nothingistrue
        30
    nothingistrue  
       2023-06-09 09:28:23 +08:00
    SSH 私钥的密码,属于本地 pin ,不网络传输,且只能暴力破解。再目前的安全框架下,本地 pin ,哪怕就是 4 位数字,也是物理级别安全的。
    m1a0
        31
    m1a0  
       2023-06-09 09:41:56 +08:00
    还是搞两个 yubikey 比较靠谱。
    CodeCodeStudy
        32
    CodeCodeStudy  
       2023-06-09 09:43:13 +08:00   1
    @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]
    ```
    xabcstack
        34
    xabcstack  
       2023-06-09 09:53:08 +08:00
    在微信收藏里
    flyqie
        35
    flyqie  
       2023-06-09 14:38:14 +08:00
    这类方案是一个设备一组公私钥?

    安全是安全,就是换设备的时候好像不是一般的麻烦。。
    lyc8503
        36
    lyc8503  
    OP
       2023-06-09 22:08:56 +08:00
    @flyqie 先用旧设备登录, 添加新设备的公钥, 然后新设备登录删除旧设备的公钥. 一个设备一组公私钥应该是推荐的做法, 私钥本来就不应该离开当前的物理设备.
    adoal
        37
    adoal  
       2023-06-12 16:17:17 +08:00
    @lyc8503 到一大堆服务器上添加新的公钥,然后遗漏了一小堆……不过话说如果要登录的服务器数量多的话,应该用签过的密钥,或者用 AuthorziedKeysCommand 从一个地方集中读取公钥,但是这样一来又有新的加固点需要去维护

    私钥不离物理设备当然是按理正确的,但还有一个尴尬问题是,旧设备突然物理损坏了,还没来得及用来添加新设备的公钥……
    关于     帮助文档     自助推广系统     博客     API     FAQ     Solana     4771 人在线   最高记录 6679       Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 36ms UTC 01:11 PVG 09:11 LAX 17:11 JFK 20:11
    Do have faith in what you're doing.
    ubao msn snddm index pchome yahoo rakuten mypaper meadowduck bidyahoo youbao zxmzxm asda bnvcg cvbfg dfscv mmhjk xxddc yybgb zznbn ccubao uaitu acv GXCV ET GDG YH FG BCVB FJFH CBRE CBC GDG ET54 WRWR RWER WREW WRWER RWER SDG EW SF DSFSF fbbs ubao fhd dfg ewr dg df ewwr ewwr et ruyut utut dfg fgd gdfgt etg dfgt dfgd ert4 gd fgg wr 235 wer3 we vsdf sdf gdf ert xcv sdf rwer hfd dfg cvb rwf afb dfh jgh bmn lgh rty gfds cxv xcv xcs vdas fdf fgd cv sdf tert sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf shasha9178 shasha9178 shasha9178 shasha9178 shasha9178 liflif2 liflif2 liflif2 liflif2 liflif2 liblib3 liblib3 liblib3 liblib3 liblib3 zhazha444 zhazha444 zhazha444 zhazha444 zhazha444 dende5 dende denden denden2 denden21 fenfen9 fenf619 fen619 fenfe9 fe619 sdf sdf sdf sdf sdf zhazh90 zhazh0 zhaa50 zha90 zh590 zho zhoz zhozh zhozho zhozho2 lislis lls95 lili95 lils5 liss9 sdf0ty987 sdft876 sdft9876 sdf09876 sd0t9876 sdf0ty98 sdf0976 sdf0ty986 sdf0ty96 sdf0t76 sdf0876 df0ty98 sf0t876 sd0ty76 sdy76 sdf76 sdf0t76 sdf0ty9 sdf0ty98 sdf0ty987 sdf0ty98 sdf6676 sdf876 sd876 sd876 sdf6 sdf6 sdf9876 sdf0t sdf06 sdf0ty9776 sdf0ty9776 sdf0ty76 sdf8876 sdf0t sd6 sdf06 s688876 sd688 sdf86