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

2023-11-25 17:12:30 +08:00
 raw0xff

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

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

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

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

5744 次点击
所在节点    程序员
43 条回复
72MpQOSsJhyLs88N
2023-11-25 17:21:31 +08:00
TLS 不就是用这玩意交换加密密钥的吗?如果能磨损,那银行、谷歌之类的网站不得几分钟就换证书了
huangzhiyia
2023-11-25 17:32:29 +08:00
你这个方案不如 MQTT 加 TLS 来得成熟可靠。
GeekGao
2023-11-25 17:41:53 +08:00
ECC 加密和解密的计算复杂度较高,这可能会影响到系统的性能;
其次,如果私钥被泄露,那么所有的数据都可能会被解密,这对系统的安全性构成了威胁;
因此,需要确保私钥的安全,并定期更换私钥;
最后,ECC 加密和解密的过程可能会导致数据的增长,这可能会增加网络的压力;

私钥在本地如何安全存储? 最简单直接的方式是使用可信的密钥管理系统 (KMS) ,例如 HashiCorp Vault
raw0xff
2023-11-25 18:14:21 +08:00
@zmaplex MQTT 需要消息代理服务器,不适用
raw0xff
2023-11-25 18:35:27 +08:00
@GeekGao 私钥泄露的问题,我认为可以降低私钥的重要性,节点接收到的信息都是用户私钥签名过的,不涉及敏感内容。所以即便私钥泄露,顶多节点不能使用,数据本身也是明文+用户签名,作恶者只有节点私钥没有用户私钥,做不得假。不知道这样想对不对?

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

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

肉眼看 ECC 加密后数据量会增加 2 倍,买点流量应该能兑付
leonshaw
2023-11-25 18:47:21 +08:00
为什么不用通行的密钥交换?私钥安全用硬件 TPM ,有钱上 HSM
raw0xff
2023-11-25 19:07:27 +08:00
@leonshaw ECDH ? 用 aes 比直接公钥加密的优势是?

私钥安全用硬件 TPM ,有钱上 HSM
用轻量云主机,没钱哈哈
GeekGao
2023-11-25 19:40:41 +08:00
@raw0xff
一定程度是正确的,但是严格的讲是有现实隐患的:
首先,你忽略了一个重要事实,就是私钥泄露可能会带来严重安全问题。如果一个节点的私钥泄露了,攻击者就可以假冒这个节点,这对整个系统的安全都造成威胁。攻击者可能会伪造消息或者修改已经存在的消息,从而影响系统正常运行。

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

最后,你忽略了私钥泄露不仅意味着一个节点的私钥泄露,更可能会导致更多私钥泄露。比如,如果一个节点的私钥泄露了,攻击者就可以利用这个节点获取其他节点的私钥。到时候攻击者就可能控制整个系统了。
GeekGao
2023-11-25 19:44:37 +08:00
假如 QPS < 100 ,加解密底层实现是基于 C/C++ 的,盲猜 2c4g 配置够用。
leonshaw
2023-11-25 20:27:11 +08:00
@raw0xff 一方面是性能,一方面大概要自己实现分组加密的模式,容易有漏洞。用云主机就主打一个信任,做好常规安全加固吧。
baobao1270
2023-11-25 21:06:14 +08:00
@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
2023-11-25 21:15:04 +08:00
几 kb 数据量,直接非对称加密就行,没有压力。

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

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

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

还是想确认 ecc 公钥加密私钥解密用在每天数百万次加解密场景中是否合适,对比的方案是 ECDH+aes ,还请大佬给分析一下。
raw0xff
2023-11-25 21:39:00 +08:00
@xiangyuecn 字数虽少,特别认同,就是不知道正不正确。
raw0xff
2023-11-25 21:56:18 +08:00
@baobao1270 看来还是得换 x25519 。 使用 ECDH 的话一定要用 TLS 吗?交换的随机数即使暴露了好像也没关系吧?已知没搞明白。 还有,抗量子性方面有什么建议吗? AI 发展这么快,有点担心。
mantouboji
2023-11-25 23:46:23 +08:00
这种还不如直接 https 或者建一堆 wireguard 连接得了,何必自己瞎写。
GeekGao
2023-11-25 23:56:52 +08:00
针对你提到的“看来各位对密码学都有一定的误解。建议去把 HPKE 的 RFC 仔仔细细读一遍”
我也给你找点反例吧:
1. 性能问题:每次连接都需要进行密钥交换,💡这会增加加密和解密的计算开销,特别是在资源受限的设备上,例如轻量级的物联网设备

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

3.兼容性问题:使用 X25519 算法的设备可能与使用其他加密算法的设备不兼容,这可能会限制它们的互操作性。💡除非你假设了 OP 无所谓自己的学习曲线、也无需考虑后续入方的接入成本。
GeekGao
2023-11-26 00:04:00 +08:00
对于 ECDH+AES 的方案,ECDH 可以用来生成一个共享密钥,然后使用 AES 进行数据的加密和解密。
这种方案的优点:ECDH 的密钥交换速度快,适合于需要频繁交换密钥的场景,而 AES 的加密和解密速度快,适合于需要大量加解密的场景。

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

关于对抗量子计算的攻破,已知道的是 ECC 在面对量子计算机的攻击时有概率会被破解。因为量子计算机的构建和实现还在初级阶段,重点是:目前还没有量子计算机能够实现大规模的量子比特控制和稳定性。
因此,如果一个大规模的量子计算机能够实现,并且能够破解 ECC ,那么 RSA 的破解也就不会远了 1 。
微软的研究团队正在研究如何使用量子计算机来破解 ECC ,他们发现,要破解 ECC ,需要的量子比特数量是 RSA 的 6 倍。
raw0xff
2023-11-26 01:38:47 +08:00
@mantouboji wireguard 行,我去了解学习一下先


@GeekGao 感谢对 OP 的考虑,是这样的,在选择方案上特别耗精力。查阅资料给出的特性不一定完全适用于自己的场景,实践的精力成本还是比较高的,所以才开贴求助一下有经验的大佬给点建议。
keepMyselfClam
2023-11-26 03:14:33 +08:00
这样的方案有很多问题,基础完整性保护都没有.
直接用成熟的 TLS/DTLS 就行了,不要用自己随便拍脑袋的想法和行业几十年的积累去比较
抗量子性啥的压根就不用考虑,遵循现在的主流标准就够了.天塌有高个子顶着,民用产品担心啥.

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://www.v2ex.com/t/995144

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX