轻量加密密钥交换协议 [英] Lightweight encryption key exchange protocol
问题描述
我正在探索加密传输中的数据的选项。 HTTPS似乎是逻辑选择，因为服务器端将需要很少的改变。但是，我的微控制器具有相对较小的闪存（256KB）和RAM（96KB），而只有HTTPS客户端才能找到商业产品。微控制器通过内置的AES加密查找表使加密更加简单，但我猜想我需要一种安全的方式来更换密钥。
SSL看起来很复杂。任何其他更轻的选项？
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）。
我有（专业的）实现了一个支持AES和3DES的TLS客户端，并执行基本的X.509验证（仅限RSA签名）。完整的代码适用于21 KB的ROM（对于ARM处理器，使用Thumb指令编译的C代码），并且只需要19 KB的RAM，其中16 KB用于输入缓冲区（输入记录的最大大小假设没有压缩的SSL约为16 KB）。因此，SSL 可以对于微控制器来说足够小。
通过先前选择的客户端选择的参数简化了SSL，您得到一个协议，它的重量就像它可以得到的那样：剩下的复杂性是内在的。如果您尝试获得更简单的东西，那么最终会有一些较弱的东西。
至于现有的实现，至少 PolarSSL 针对的是嵌入式设备，并且可以在开源许可证（GPLv2）下使用。我不知道它可以缩小多少。还有 CyaSSL ，这也可以根据GPLv2条款获得，并声称可以编译成30 KB代码占用（最小选项）。
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?
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).
这篇关于轻量加密密钥交换协议的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
