多节点间加密通信的安全问题

多节点间通信，节点每 2 秒会收到 10<n<100 条加密数据，每 2 秒要发送 n<10 条，每条数据<1kb 。节点有自己的公私钥，ECC 算法，接收时用本地私钥解密收到的数据，发送时用接收方公钥加密。

请问这种场景选用 ECC 公钥加密私钥解密方式是否合理？会有哪些问题？大佬有什么建议？

我不太懂私钥安全性是否会有磨损，每天百万次解密运算是否可以长期使用？

另一个话题，私钥在本地如何安全存储？

72MpQOSsJhyLs88N

362 天前

TLS 不就是用这玩意交换加密密钥的吗？如果能磨损，那银行、谷歌之类的网站不得几分钟就换证书了

huangzhiyia

362 天前

你这个方案不如 MQTT 加 TLS 来得成熟可靠。

GeekGao

362 天前

ECC 加密和解密的计算复杂度较高，这可能会影响到系统的性能；
其次，如果私钥被泄露，那么所有的数据都可能会被解密，这对系统的安全性构成了威胁；
因此，需要确保私钥的安全，并定期更换私钥；
最后，ECC 加密和解密的过程可能会导致数据的增长，这可能会增加网络的压力；

私钥在本地如何安全存储？最简单直接的方式是使用可信的密钥管理系统 (KMS) ，例如 HashiCorp Vault

raw0xff

362 天前

@zmaplex MQTT 需要消息代理服务器，不适用

raw0xff

362 天前

@GeekGao 私钥泄露的问题，我认为可以降低私钥的重要性，节点接收到的信息都是用户私钥签名过的，不涉及敏感内容。所以即便私钥泄露，顶多节点不能使用，数据本身也是明文+用户签名，作恶者只有节点私钥没有用户私钥，做不得假。不知道这样想对不对？

KMS 不太适用于我这个场景。

每天百万次的加密解密用什么云主机起步？ 2c4g 应该能扛得住吧？

肉眼看 ECC 加密后数据量会增加 2 倍，买点流量应该能兑付

leonshaw

362 天前

为什么不用通行的密钥交换？私钥安全用硬件 TPM ，有钱上 HSM

raw0xff

362 天前

@leonshaw ECDH ？用 aes 比直接公钥加密的优势是？

私钥安全用硬件 TPM ，有钱上 HSM
用轻量云主机，没钱哈哈

GeekGao

362 天前

@raw0xff
一定程度是正确的，但是严格的讲是有现实隐患的：
首先,你忽略了一个重要事实,就是私钥泄露可能会带来严重安全问题。如果一个节点的私钥泄露了,攻击者就可以假冒这个节点,这对整个系统的安全都造成威胁。攻击者可能会伪造消息或者修改已经存在的消息,从而影响系统正常运行。

其次,即使数据本身是明文,私钥泄露也意味着攻击者可能会试图窃取或者修改这些数据。在某些情况下,这可能会带来严重后果,比如如果数据包含用户个人信息,那这些信息就可能泄露。

最后,你忽略了私钥泄露不仅意味着一个节点的私钥泄露,更可能会导致更多私钥泄露。比如,如果一个节点的私钥泄露了,攻击者就可以利用这个节点获取其他节点的私钥。到时候攻击者就可能控制整个系统了。

GeekGao

362 天前

假如 QPS < 100 ，加解密底层实现是基于 C/C++ 的，盲猜 2c4g 配置够用。

leonshaw

362 天前

@raw0xff 一方面是性能，一方面大概要自己实现分组加密的模式，容易有漏洞。用云主机就主打一个信任，做好常规安全加固吧。

baobao1270

362 天前

@GeekGao
@raw0xff

看来各位对密码学都有一定的误解。建议去把 HPKE 的 RFC 仔仔细细读一遍。总的来说：
1. 现代的加密手段不再使用固定的公钥/私钥对，也就是很多 HTTPS 科普中「使用证书的公钥/私钥来加密/解密」已经是错的了。现代的加密机制，每个 connection 都会进行一次独立的 DH/ECDH ，目前最快的算法是 X25519 。
2. 为什么要 AES 进行实际的加密/解密，而不是直接用公钥/私钥？因为慢。即使 ECC 比 RSA 快，但是和 AES 比仍然有十倍左右的速度差距。如果你的设备以嵌入式为主，CPU 没有 AES 加速功能，建议使用更快的 ChaCha20-Poly1305 算法。
3. 在进行加密通信时，永远使用 AEAD 而不是单纯的 AES——如果决定使用 AES ，必需使用 AES-GCM 模式；如果不使用 AES ，建议使用 ChaCha20-Poly1305 算法。
4. 现代的 TLS 流程：ECDH 交换随机数->用 HKDF 从随机数派生 AES/Poly1305 密钥 (此时服务端握手已经完毕) ->服务器用证书私钥签名发送给客户端 (发送的证书已经用派生密钥加密)->客户端验证证书 (1.5RTT 握手完成) -> 进入 Application Data 通信模式
5. 对于运行在云上的设备，KMS 永远是最好的存储密钥的方法。对于本地设备，建议使用 TPM/HSM ，其实 FIDO2 密钥也能当 HSM 用。

xiangyuecn

362 天前

几 kb 数据量，直接非对称加密就行，没有压力。

存储，密钥随便放就行，只要不被匿名访问到，不要有压力。你要相信，当你的密钥可以被别人访问到，你做什么努力都是白费的。

raw0xff

362 天前

@GeekGao
首先,你忽略了一个重要事实,就是私钥泄露可能会带来严重安全问题。如果一个节点的私钥泄露了,攻击者就可以假冒这个节点,这对整个系统的安全都造成威胁。攻击者可能会伪造消息或者修改已经存在的消息,从而影响系统正常运行。
-- 同意私钥泄露是严重的安全问题，我们假定节点是可以被攻击者取得 root 权限的，我们又不能用 KMS ，也不能用 TPM 硬件存私钥，那么我们能做的且有效的是降低节点私钥的重要性。比如明文且有签名的信息是类似微博的内容，敏感信息如用户名用户设置等用用户公钥加密，只有客户端有私钥才能看到和修改。您认为这个思路可行吗？

其次,即使数据本身是明文,私钥泄露也意味着攻击者可能会试图窃取或者修改这些数据。在某些情况下,这可能会带来严重后果,比如如果数据包含用户个人信息,那这些信息就可能泄露。
-- 节点私钥泄露不代表攻击者拥有用户私钥，所以做不到伪造和篡改数据，节点只存用户公钥。假如攻击者新增或删除了用户公钥，我们前提是“多节点间”，其他节点并不认可，所以只能使此节点不能正常运转，不影响整个网络。（假定攻击者只能 root 其中一个节点）

最后,你忽略了私钥泄露不仅意味着一个节点的私钥泄露,更可能会导致更多私钥泄露。比如,如果一个节点的私钥泄露了,攻击者就可以利用这个节点获取其他节点的私钥。到时候攻击者就可能控制整个系统了。
-- 这种情况有考虑到，有对应的方案

还是想确认 ecc 公钥加密私钥解密用在每天数百万次加解密场景中是否合适，对比的方案是 ECDH+aes ，还请大佬给分析一下。

raw0xff

362 天前

@xiangyuecn 字数虽少，特别认同，就是不知道正不正确。

raw0xff

362 天前

@baobao1270 看来还是得换 x25519 。使用 ECDH 的话一定要用 TLS 吗？交换的随机数即使暴露了好像也没关系吧？已知没搞明白。还有，抗量子性方面有什么建议吗？ AI 发展这么快，有点担心。

mantouboji

362 天前

这种还不如直接 https 或者建一堆 wireguard 连接得了，何必自己瞎写。

GeekGao

362 天前

针对你提到的“看来各位对密码学都有一定的误解。建议去把 HPKE 的 RFC 仔仔细细读一遍”
我也给你找点反例吧：
1. 性能问题：每次连接都需要进行密钥交换，💡这会增加加密和解密的计算开销，特别是在资源受限的设备上，例如轻量级的物联网设备

2.安全性问题：尽管 X25519 算法在理论上是安全的，但在实际应用中可能存在一些问题。例如，如果在密钥交换过程中随机数值泄露，任何知道该随机数值的人都可以使用该随机数产生签名值恢复私钥。此外，如果同一个用户对两个不同的消息签名时，采用了相同的随机数，则任何人都可以通过两个签名值恢复出私钥。怎么实施保护性措施？
💡除非你假设 OP 一定会科学恰当的使用现代成熟的 TLS 方案。

3.兼容性问题：使用 X25519 算法的设备可能与使用其他加密算法的设备不兼容，这可能会限制它们的互操作性。💡除非你假设了 OP 无所谓自己的学习曲线、也无需考虑后续入方的接入成本。

GeekGao

362 天前

对于 ECDH+AES 的方案，ECDH 可以用来生成一个共享密钥，然后使用 AES 进行数据的加密和解密。
这种方案的优点：ECDH 的密钥交换速度快，适合于需要频繁交换密钥的场景，而 AES 的加密和解密速度快，适合于需要大量加解密的场景。

ECDH+AES 的缺点：它需要两种不同的加密算法，这可能会增加系统的复杂性和实现难度。

关于对抗量子计算的攻破，已知道的是 ECC 在面对量子计算机的攻击时有概率会被破解。因为量子计算机的构建和实现还在初级阶段，重点是：目前还没有量子计算机能够实现大规模的量子比特控制和稳定性。
因此，如果一个大规模的量子计算机能够实现，并且能够破解 ECC ，那么 RSA 的破解也就不会远了 1 。
微软的研究团队正在研究如何使用量子计算机来破解 ECC ，他们发现，要破解 ECC ，需要的量子比特数量是 RSA 的 6 倍。