传输经 AES 加密的数据， TLS 是不是就没意义了

[pagxir]

啥，有高铁就没有手机什么事了

[wheat0r]

这是个啥问题…

[iqoo]

密钥怎么协商，用固定的？ TLS 不是就是帮你协商密钥之后再 AES 了。

[LLaMA]

@iqoo #3 公钥内置在客户端中

[LLaMA]

@pagxir
@wheat0r
@iqoo 场景是嵌入式设备要快速实现向服务器加密通信

[LLaMA]

因为服务端是私有化部署，TLS 弄起来比较麻烦

[wxxxcxx]

传输协议和加密算法怎么能放一起比较，TLS 本来就设计可以使用不同的加密算法吧。

[zagfai]

2023 年 3 月 14 注册

[wwbfred]

问题的核心是你这个问题问得不对，让大家一头雾水。最好先了解下基础知识再问问题。

[mejee]

#3 公钥内置在客户端中和 AES 有什么关系？还是说你门自己基于公钥来协商密钥？感觉和 TLS 是两码事，如果不使用 TLS ，你们自己用公钥来协商密钥，很容易出现被中间人拦截、伪造的情况

[SilencerL]

楼上说的都啥啥啥，行就行不行就不行，冷嘲热讽的有，文不对题的也有。
单说 http(s) 通信，嵌入式设备为了节约资源直接用 http 的很正常，某些方案寸土寸金的存储空间引入一个 TLS 库就崩，所以如楼主所说把密钥内置在设备和服务端，本地加密后(再通过 http)传输(对链路来说是明文的)加密信息完全没问题，反正只要保证密钥不泄露，链路上拿到「明文的密文」随便他们……

[o00o]

@zagfai #8 强烈建议出一个按注册时间屏蔽用户的功能😄

[crazytec]

@benrezzagmehamed #4 首先，AES 是对称加密，没有公钥私钥之说
正确使用 AES 加密不会泄漏内容，但是搞起来麻烦程度肯定不亚于 TLS （ padding ，防重放，侧信道之类）
所以 TLS 安全性肯定是高于你自己实现的 AES 的
如果一定不要 TLS ，请至少用下 AEAD 算法...

[SilencerL]

p.s, 我就自己脑补楼主说的「公钥内置在客户端中」是手滑把「密钥」打成「公钥」了

[BeautifulSoap]

偷偷跟 lz 说，https 的数据传输是先用非对称加密方式交换随机秘钥，然后实际的数据传输还是用的对称加密哦(AES, DES 之类）

稍微了解一下密码学或相关底层原理，就不会问出这种奇怪的问题了

[leloext]

看了第 5 楼就理解楼主为什么想要这么做了，嵌入式用 TLS 的话，设备有机会重启，原因是内存太小，可能会爆内存不断重启(ESP8266 上经常遇到)，用 AES 的话只要确保 key 不被别人获取就可以了。AES 是对称加密，没有公私钥的概念。

[SilencerL]

顺便吐个槽，刚刚调一厂给的板子，连电话带密码给我直接 http get 出去了，楼主这至少还考虑加个密的，这连 POST 都舍不得用（虽然 http post 一样漏出去，至少不会在 url 直接看到，傻逼等级 100 降到 99.5 而已）

[mingl0280]

确保你的数据经正确的 AES 加密，确实可以不用 TLS 。
我这边一般操作是先用 AES 加密个时间相关的随机数上去，可以避免被重放了……

[swulling]

这个分为两个安全问题：

1. AES 密钥放到板子上行不行？
答：不建议，AES 没有 Public Key ，是对称加密。安全角度上，将对称密钥放到板子上风险较大，意味着一旦你一个板子被人读到了密钥，那么所有的通讯的加密都无效了

优化方案 为每个板子生成单独的 Key ，如果不便于烧录，可以采用首次连接通过固定 bootstrap key 签发单独的 key 的方案，这样哪怕 bootstrap key 泄漏，获得 key 也不能用于之前的设备。

这个方案进化后就是签客户端证书，不过都证书了，那用 https mtls 是最简单的。


2. 传输层手搓 HTTP + AES ，行不行？
答：一般安全需求下（防脚本小子），可行。高安全需求（涉及到金钱、个人关键隐私信息等等），不可行。


成本可以接受的高安全需求环境下，建议使用 ATECC608 之类的安全芯片，可以自带客户端证书或者私钥，无法通过技术手段读取。而且加解密都是通过安全芯片进行的，也减轻了 MCU 的计算负担。

[iseki]

如果对安全性无要求，可以不用，这种我甚至建议考虑直接明文传输，反正你对安全没要求。
如果对安全性有要求，请尽量使用 TLS ，虽然嵌入式设备硬件资源贫瘠，但我觉得你很难设计一个满足安全性要求的协议。

[lslqtz]

如果你是为了保护不被中间人, 并且产品是定制产品, 那么 TLS 是没有必要的.
如果你的产品不是定制产品, 那么意味着密钥唯一且易被泄漏, 中间人可以通过密钥进行解密, TLS 显著更安全.
另外内存太小建议加内存.

[iyaozhen]

可以的。我们一般是先通过 RSA 交换 AES 的密钥，做到一次 session （我们是长链）一次密码，你可以一段时间

[churchmice]

@mejee 不会啊，内置了对方的公钥，那就可以通过签名来认证对方了，中间人无法攻击

[lovelylain]

@crazytec @SilencerL 可能是 RSA 与 AES 结合，客户端随机生成 AES 密钥然后用公钥加密，用 AES 密钥加密实际内容，再把两个加密后的内容传给服务端，服务端先解密出 AES 密钥再解密出内容。

[shawnsh]

密码学关键字，基础知识

[HENQIGUAI]

确实要注意所有设备用同一个密钥时密钥泄露的风险

[leefor2020]

AES 哪来的公私钥？

[DCELL]

建议直接上非对称加密，每次传输后，都需要破解个 1w 年。更加安全

[InkStone]

你自己实现密钥协商，肯定是不安全的。
攻破 TLS 需要 0day ，攻破你这种加密可能试几个常用的脚本就行。

如果不做密钥协商直接加密那更是跟明牌不加密差别不大……

[janus77]

@SilencerL #17 UA 笑死我了

[cnuser002]

TLS 是一揽子解决方案，除了信道加密以外，它还有其它机制来提供身份验证、防中间人攻击、防重放攻击。

你仅仅搞个 AES 加密，防不了那么多东西。

但或许对你的需求而言也无所谓。至少加密后传输的东西，中间人确实解不了，内容中加时间戳，可以防重放攻击。

想破解还是得攻破终端，拿到密钥。

能做到这一步了，哪怕用 TLS 搞双向验证，私钥也是在终端上的，同样是不安全的。

[ren2881971]

一个是信道加密，一个是信源加密， 两者保护的东西不一样。 两个东西。

[nyxsonsleep]

@InkStone 不考虑侧信道，aes CBC 之类的模式破解除非超级计算机过来。或者美国人拿 aes 漏洞来攻击

[InkStone]

@nyxsonsleep 要啥侧信道，密钥协商环节没实现好，密钥裤底子都漏出去了。
如果是直接硬编码在设备上那更是等着人逆。

[unco020511]

可以当然可以,问题是你如何保证你的对称秘钥不被窃取

[sofukwird]

最后你会重新发明 tls

[mayunqing1230]

AES 是对称加密，TLS 是非对称加密，没啥可比性。如果非要用 AES 加密来传输，那问题就是交换密钥。例如，你服务器提前存密钥了才可以直接加密传输而不用考虑如何安全地交换密钥。另外，你密钥不换？ TLS 每次密钥都是随机的。

[nyxsonsleep]

@InkStone
嵌入式内置密钥，协商什么？
大多嵌入式设备压根就没读取内置程序的能力，源码都没有逆向什么？逆向硬件没几千万还是别想这种事情吧。

[nyxsonsleep]

@mayunqing1230 AES 是对称加密，TLS 是非对称加密。这句话对吗
AES 是一种对称加密算法，也就是说加密和解密使用的是同一个密钥。TLS 是一种安全传输协议，它使用了混合加密系统，也就是说它结合了非对称加密和对称加密两种方式。

[mayunqing1230]

@nyxsonsleep 我承认我表达错误，AES 确实是对称加密没有错，TLS 是协议，仅仅从词来解释和加密无关。