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

[LLaMA]

[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 ，虽然嵌入式设备硬件资源贫瘠，但我觉得你很难设计一个满足安全性要求的协议。