轻量级加密密钥交换协议 [英] Lightweight encryption key exchange protocol
问题描述
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屋！
