-2

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

pilotjack59
  • 1
  • 1
  • 5
    IV's should be rotated *every* time you encrypt data, not simply each "session". – Stephen Touset Feb 23 '15 at 06:16
  • 2
    Additionally it should be noted that using the final cipher block of the last message you send as IV for the next message you send is insecure. (Important to point out because it is one of those approaches that looks obviously correct at a first glance, but turns out to have a subtle security flaw, once you start analyzing it.) – kasperd Feb 23 '15 at 08:22

1 Answers1

0

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.

Community
  • 1
apsillers
  • 5,780
  • 27
  • 33
  • Appreciate your response! I plan on handling replay attacks using a short time-to-live embedded in the encrypted payload. We are not using cookies or headers other than the most basic to get the http post completed. Our system has the embedded device going online via cell modem a few times a day, posting status and receiving a reply. It appears, for this application, that the encrypted payload is sufficient. If the app expands we would have to go with https. – pilotjack59 Feb 25 '15 at 19:17