这是一个创建于 1273 天前的主题，其中的信息可能已经有所发展或是发生改变。
yubikey 是一个硬件密钥。这里只讨论它的 PGP 智能卡功能。
目前来看，yubikey 是 write-only 的，即：私钥一旦导入，就无法导出。那么问题来了，它怎么实现加密（签名）的？
- 如果用了某种协议读取了里面的密钥。那是不是可以用这种协议导出密钥？
- 如果主机压根无法取得密钥，那谁执行的加密？难道是 yubikey 自己算的？
- 还是可以协商出一个临时密钥性质的东西，而这个临时密钥加密后，公钥也可以解密？（在的 RSA 认知中，好像不能这样吧）
 | 1 tavimori 2022-06-20 11:51:24 +08:00  2 的确是 yubikey 自己算的。 实际上现代的大部分包括银行卡、公交卡在内的智能卡都是自己计算加密的。 |
 | 2 likelylee 2022-06-20 11:59:26 +08:00 3 这玩意不用 yubikey ，所有的 U 盾、智能卡都是这么干的啊。PC 端对数据做 hash ，把 hash 结果送给 yubikey ，然后 yubikey 内部的主控芯片调用私钥对 hash 结果做签名，然后吐出来签名结果就完了。有些 key 甚至 hash 都是自己内部执行，外部只需要把数据原样过去就好了。当然在 PC 端和 key 端通信前会有建联和认证的过程，可以查看 iso7816 ，也可以看各家的 cos 指令，但是大概其都没太大的差别。 |
 | 3 ysc3839 2022-06-20 12:01:42 +08:00 via Android 2 卡自己算的，“智能卡”都是这样的，包括但不限于 SIM 、银行卡，卡本身就有个 CPU ，运算都在卡上的 CPU 进行。 |
 | 4 xiri 2022-06-20 12:10:26 +08:00 via Android 1 就是你说的第 2 种，yubikey 自己算的，应用从 yubikey 拿到的直接是算完的结果 |
| 7 xiri 2022-06-20 12:48:06 +08:00 via Android @Chenhe 大文件加密不会完全用非对称密钥去处理的，效率太低了，即使是在 PC 上完成计算也是一样。 参考 PGP/GPG 的做法，每次加密时随机生成一个对称加密密钥（具体的对称加密算法由客户端决定）用于实际的文件加密，再用固定的非对称密钥去加密该临时生成的对称密钥，最后将对称加密后的文件数据和非对称加密后的对称密钥数据以及使用的对称加密算法等打包在一起作为加密的结果输出。 解密时先用非对称密钥解密得到一个对称加密的密钥，再用该密钥去解密实际的文件数据。 另外包括 HTTPS 等其实也是这么做的，非对称密钥只用来加密协商一个对称密钥，而不是用于实际的通信数据加密 |
 | 8 imn1 2022-06-20 13:03:15 +08:00 2 智能卡、TOTP 、或者其他方式，下称为 key ，实际上就是传入一个值+“参数”，通过自己的算法，传出一个值，网站或者权限校验方，用相同算法和参数，计算并校验这个返回值就行，原理就这么简单 一般不会传入大文件的，可以 hash 后再传入啊 而上述参数就是这个 key 本身，每个硬件也好，TOTP 也好，只要区别每个 key 本身不同，就能做到人人不同，就是用户 A 和用户 B 即使买到同一款同一批次 yubikey ，参数也是不同的 所以即使同款 yubikey 算法相同，用户 B 也必须拿到用户 A 的 yubikey 实体，才能用 A 的参数算出用户 A 的密码 例如某批次的 yubikey 算法为 相加，用户 A 买到的出厂参数是 1 ，用户 B 是 2 那么网站发出 123 这个输入值，用户 A 的 yubikey 输出 124 ，用户 B 输出 125 |
 | 10 vfs 2022-06-20 16:00:23 +08:00 test |
| 11 vfs 2022-06-20 16:03:54 +08:00 1. 这里常用的协议是 pkcs#11. 这套规范中提供了如何操作密钥的 api ，然后和 pkcs#11 兼容的硬件需要实现这样的类库。但是这里的密钥是无法导出的，如果支持导出，那么如果保证安全性呢。 2. yubikey 自身实现了加密解密，签名，验证签名的功能。 通过于 pkcs#11 兼容的类库暴露出来。（购买 yubikey 的时候应该会附带这个类库） 3. 不太明白你这个问题什么意思 |
 | 12 julyclyde 2022-06-21 14:25:54 +08:00 签名是对 hash 签的，不是对完整文件签的 外面程序把 hash 算好送进卡里签名就行了 |
Select Language