First, you should define precisely what kind of attack you are trying to defend against:
- Do you fear attackers who spy on the messages exchanged between the sensor and the server, and learn the contents of the messages ?
- Do you fear attackers who impersonate the server and talk to the sensor as if they were the server ?
- Do you fear attackers who impersonate the sensor, and send fake requests to the server ?
- Do you fear attackers who drop, duplicate, replay and reorder messages between client and server ?
A symmetric-only lightweight protocol which covers all of the above -- to some extent -- looks like this:
- For any communication channel between the sensor and the server, there are two symmetric keys which both the server and the sensor know, one for data sent by the server to the sensor, and one for data sent by the sensor to the server.
- Every message sent by either the server or the sensor is encrypted with AES in EAX mode.
- EAX mode requires a non-repeating IV; the sensor and the server will use counters.
- Each message contains the IV (counter value) for that message, followed by the AES-EAX encryption of the message.
- For each communication channel, the sensor stores the current counter value for the message it sends, and the IV of the last message it received from the server over that channel.
- When it sends a new message, the sensor increments its counter (for that channel), stores the new value, and then (only then) uses the new value as IV for AES-EAX.
- When it receives a message from the server, the sensor checks that the new message uses an IV which is strictly greater than the last received from the server; the sensor stores that new IV and then (only then) decrypts and processes the message from the server.
- The server employs the same techniques than the sensor (counter for the messages it send, saved IV from the last message from the sensor, and so on).
Assuming that counters start at 0, this means that the first message that the sensor will send will use 1 as IV; the second message will use 2, and so on. Similarly for the messages sent by the server. This enables the server and the sensor to detect replayed messages, out-of-order messages, and missing messages; what they should do in such a case is up to you to decide.
On EAX: combining encryption and MAC together with a given key is not completely easy. Reusing the same key for the encryption and the MAC is, theoretically, risky. An authenticated encryption mode such as EAX takes care of the fine details. As a fine bonus, EAX does not need uniformly random, unpredictable IV, as CBC does; it only requires IV values never to be repeated (for a given key), so a counter is fine -- as long as you can store the current IV value in a resilient way, and do it at the right time. Beware of an attacker switching the sensor off in order to force an IV reset !
On keys: I have talked here about bidirectional channels. You need one key per channel direction. This means two keys for the HTTP thing (one for requests, one for responses), and one key for the command channel, assuming it to be unidirectional (commands from the server to the sensor, no response from the sensor). If storing three 128-bit keys is problematic, you can store a single 128-bit key (a "master key") and dynamically rebuild the three keys from that, with a key derivation function. Since you are in a constrained environment, and EAX uses AES only, I suggest using AES for that too: using the master key as key, encrypt three fixed constant values (e.g. "0", "1" and "2") with a single raw AES invocation for each; this will yield three 128-bit blocks which will do fine as your channel keys.
On tamper resistance: I suppose that the sensors will be deployed "on the field", so an attacker may succeed in catching a sensor, opening it, and then trying to recover its logical contents. Unless the sensor is specially hardened against tampering (as a smartcard would be), this means that the attacker will be able to learn the sensor keys, and, from that moment, "emulate" the sensor as seen by the server. At a minimum, every deployed sensor should have its own keys, and the server will have to know the keys of all deployed sensors.