轻量级加密密钥交换协议
我有一个嵌入式系统通过 HTTP 将数据发布到 JSON REST 服务。我目前使用 HMAC-SHA1 进行身份验证，与 的方式相同亚马逊 AWS 做到了。
我现在正在探索对传输中的数据进行加密的选项。 HTTPS 似乎是合理的选择，因为服务器端几乎不需要改变。然而，我的微控制器具有相对较小的闪存 (256KB) 和 RAM (96KB)，并且我能找到的只有 HTTPS 客户端是商业产品。微控制器通过内置的“AES 加密查找表”使加密变得更简单，但我猜我需要一种安全的方式来交换密钥。
我研究过 SSL，它看起来相当复杂。还有其他更轻的选择吗？
I have an embedded system posting data to a JSON REST service via HTTP. I'm currently using HMAC-SHA1 for authentication, the same way that Amazon AWS does it.
I'm now exploring options for encrypting the data in transit. HTTPS Seems like the logical choice as the server-end would need very little changed. However, my microcontroller has a relatively small flash (256KB) and RAM (96KB) and the only HTTPS clients I can find are commercial products. The microcontroller makes encryption simpler with built in 'AES encryption lookup tables', but I'm guessing I need a secure way to exchange the keys.
I've looked into SSL and it looks pretty complex. Any other lighter options?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
SSL 的复杂性大部分来自于高度模块化。客户端可以支持多个“密码套件”，服务器选择一个。数据可以被压缩。客户端可以通过提供自己的证书并使用相应的私钥来验证自己的身份。服务器公钥作为 X.509 证书发送，X.509 证书验证很复杂。
您可以通过对客户端选择进行硬编码来大幅简化 SSL。例如，您决定仅支持一种密码套件，例如 TLS_RSA_WITH_AES_128_CBC_SHA256。无压缩。您可以在客户端中硬编码服务器公钥，而忽略服务器发送的证书。如果可能，请使用 TLS 1.2，它需要使用单个哈希函数 (SHA -256），而不是以前协议版本的两个（MD5 和 SHA-1）（TLS 是 SSL 的标准名称；TLS 1.0 是 SSL 3.1）。
我（专业地）实现了一个 TLS 客户端，它支持 AES 和 3DES，并执行基本的 X.509 验证（仅限 RSA 签名）。完整的代码适合 21 KB 的 ROM（对于 ARM 处理器，用拇指指令编译的 C 代码），只需要 19 KB 的 RAM，其中 16 KB 用于输入缓冲区（输入记录的最大大小） SSL（假设没有压缩）约为 16 KB）。因此，对于微控制器来说，SSL可以足够小。
一旦您通过预先选择客户端选择的参数来简化 SSL，您就会得到一个尽可能轻量级的协议：剩余的复杂性是固有的。如果你试图让一些东西变得更简单，那么你最终会得到一些更弱的东西。
至于现有的实现，至少 PolarSSL 是针对嵌入式设备的，并且可以在开源许可证 (GPLv2) 下使用。我不知道它能缩小到多小。还有CyaSSL，也可以根据GPLv2条款获得，并声称可以编译成30 KByte 代码占用空间（具有最少的选项）。
Most of the complexity of SSL comes from the high modularity. The client may support several "cipher suites" and the server chooses one. Data could be compressed. The client may authenticate itself by presenting its own certificate and using the corresponding private key. The server public key is sent as an X.509 certificate, and X.509 certificate validation is complex.
You can substantially simplify SSL by hardcoding the client-side choices. For instance, you decide that you will support only one cipher suite, e.g. TLS_RSA_WITH_AES_128_CBC_SHA256. No compression. You can hardcode in the client the server public key, and just ignore the certificate that the server sends. If possible, use TLS 1.2, which requires the use of a single hash function (SHA-256) instead of two (MD5 and SHA-1) for the previous protocol versions (TLS is the standard name for SSL ; TLS 1.0 is SSL 3.1).
I have (professionally) implemented a TLS client which supports both AES and 3DES, and performs rudimentary X.509 validation (RSA signatures only). The complete code fits in 21 Kbytes of ROM (for an ARM processor, C code compiled with thumb instructions), and needs only 19 Kbytes of RAM, out of which 16 Kbytes are for the input buffer (the maximum size for an input record in SSL, assuming no compression, is about 16 Kbytes). So SSL can be small enough for a microcontroller.
Once you have simplified SSL through the a priori selection of the client-chosen parameters, you get a protocol which is about as lightweight as it can get: remaining complexity is intrinsic. If you try to get something simpler, then you end up with something weaker.
As for existing implementations, at least PolarSSL is aimed at embedded devices, and is available under an opensource license (GPLv2). I do not know how small it can shrink. There is also CyaSSL, which can also be obtained under the GPLv2 terms, and claims to be compilable into a 30 KByte code footprint (with minimal options).
SSL 使用 Diffie-Hellman (DH) 进行密钥交换。我认为您可以在代码中相对轻松地实现它（DH）。您需要考虑的唯一问题是 DH 本身无法抵御中间人 (MITM) 攻击。有多种选择可以解决这个问题。维基百科文章提到了它们，所以你可以从一些东西开始。
SSL uses Diffie-Hellman (DH) for key exchange. I think you can implement it (DH) relatively easily in your code. The only question you need to think of is that DH itself doesn't stand against man-in-the-middle (MITM) attack. There are several options to solve this problem. The Wikipedia article mentions them so you have something to start with.