I\'m working on an embedded project that needs to communicate with a server. Bot
ID: 655751 • Letter: I
Question
I'm working on an embedded project that needs to communicate with a server. Both the server and the device have an AES key pre-installed.
I have a network device that provides http services but not https. My proposal is to AES encrypt the data in the body of the post command.
Given that I have the IP of the server, the AES key is unique to this device and I rotate IV's with each session (the sessions here are very short), what could be the downside as opposed to adding https on the embedded device?
I'm new to http and restful services. Is there a standard http header or use of S/MIME for this?
TIA
Explanation / Answer
As mentioned in the comments, you should rotate IVs every time you send a new message. There's simply no good reason to reuse IVs, and even mild IV reuse will very likely open subtle security flaws.
If you encrypt only the HTTP body, that leaves your HTTP method, HTTP path, and HTTP headers all exposed in plaintext. HTTPS would encrypt these components of your messages.
You may say you don't care about an eavesdropper overhearing these components, but consider the following issues:
- HTTP cookies are communicated by HTTP headers. If you plan to use session cookies, you will need to send them in a plaintext header, or completely reinvent HTTP cookies for use inside your encrypted message body.
- HTTPS ensures not only confidentiality, but also integrity. In your scheme, an active attacker can alter the exposed plaintext components, which may affect your system in unanticipated ways.
- Your scheme does not currently describe any way of preventing replay attacks. An attacker who overhears an encrypted message (even when it's encrypted with an IV) can resubmit that correctly-encrypted message to repeat a past operation. You must include some kind of counter mechanism to invalidate past messages. HTTPS is already secure against replay attacks.
- Perhaps your protocol doesn't currently expose any information via HTTP method, path, or headers (i.e., they are always the same; your server's encrypted functionality serves only one URL, for one HTTP verb, without cookies). However, one day, your protocol may expand to use variable HTTP headers and paths, and at that point you may expose sensitive information unless you upgrade your systems to HTTPS.