问题
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?
回答1:
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).
回答2:
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.
来源：https://stackoverflow.com/questions/5246831/lightweight-encryption-key-exchange-protocol