I have a question about a monitoring software architecture.

Think about 50 different locations in different cities. Assume that these locations are small plants.

In every location there are approximately 50 devices which produce small amounts of data which is a string and an integer counter.

I need to take these data from devices and save them in a server database within the plant.

Periodically I need to send these data from the server to HQ for reporting. I don't want to send data from plant to HQ in realtime as the connection might be down for a day or 2 between the plant and the HQ.

Assume that we don't trust plant operators and products can be stolen. E.g. 50 products are produced in the plant but only 40 are reported to HQ.

Basically, a string and an integer should be taken from a device and transmitted to the HQ in another city.

There are 3 places where data should be secured, I guess.

  1. Between device and server. (Both are in the plant, they will be connected via ethernet or serial)
  2. On the server
  3. Between the server and HQ

1) For the first path; device will be in a hard case which can't be opened by anyone except authorized personnel. Software on the device will have a SHA key and it will encrypt data and send to the server over serial or ethernet. Server will write encrypted or decrypted data to a database.

  • Is encrypting data and sending it over TCP socket secure enough?
  • As the device can't have a Hardware Security Module, the encryption key will be hardcoded and it will be in memory. Is there a way to secure the key other than locking it in a steel case?
  • If the server has the same SHA key which is on the device, should it be on a Hardware Security Module?

2) The server will be secured by a hard case and will be accessible by the HQ over the remote desktop connection as well. Antivirus and firewall software will be installed and configured.

3) Should I again encrypt data on the server and send it over TCP sockets and decrypt at the center?

  • Should I use a protocol like https and use REST?
  • Do you recommend another solution?

1 Answer 1


I will assume the devices will transmit tuples (serial, counter, key, value) where:

  • serial: an unique id for the device (ideally set at the factory).
  • counter: a keeps track of the number of messages sent to the central server
  • key: name of the parameter you are sending
  • value: the number

Make the devices encrypt that big message with the public key of the center (if you can afford also having a private key per device, add a digital signature, too. Otherwise, use a fixed part on the serial id field that was generated at random and is not known to third parties).

The plant server only ever sees encrypted messages, so he can't modify them. It could choose to miss some messages, but you would notice the gap in the counter. Or that a given device stopped sending data two weeks ago.

Note that we go from "securing data on three places" to just "secure between device and center". Of course, there's no reason the plant server couldn't additionally use https when connecting with the central server, but that wouldn't be necessary for the confidentiality of the messages themselves.

You talk about "SHA key", which doesn't make much sense (SHA is used for message digests…). Simply use asymmetric cryptography. Your devices can probably use elliptic curve crypto.

You still need to get the other bits right, like using an authenticated encryption mode (eg. GCM) or else performing additionally checks, an attacker that compromised the whole device, could impersonate that device (but only that). The central server should check that things make sense... but otherwise this should provide a good basis to start.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .