Encryption (AES-128) in automatic meters reading

Question

I have theoretical questions about encryption when there's a lot of devices involved. Specifically it's about reading meters (water/gas/heat meters).

Here's some introduction.

I was trying to read a water meter but it turned out data frames are encrypted with AES-128. What's not encrypted is the water meter number (actually its a radio thingy).

I was able to download a pretty old version of the software (released 8 years ago, I know there's newer version but I don't have access). It was written in .Net so I decompiled it with JustDecompile soft. I was looking for any classes responsible for encryption. What I found about AES is connected to USB stick, so I assume that all the decryption stuff (or the important one) is placed on USB stick.

And here's the question - remember - just theoretical one - how would you solve problem of encryption if you were the programmer/engineer behind it? Would it be just one decryption key? Or key would be generated based on device's number? What about device itself? Each would have different encryption KEY based on its numbers?

As I said - these are just theoretical questions. I know that I have no chance of decrypting it without some serious reverse engineering, but I've already spent hours on this, so I'm just curious.

Answer 1

I can see a few "types" of keys used here, I'll list each with it's pros and cons:

1. Hard-coded symmetric key

   (Pros) Hard-coded key is the easiest to implement. You don't need to worry about storing, loading or replacing keys. You don't need to worry about key distribution in the field and you do need to worry about key duration and multiple keys on the receiving end.

   (Cons) Once a single key is extracted from a meter, everything can be easily decrypted. Because meters are spread, left alone and aren't reasonably protected this can easily happen if someone is interested in getting those keys, however since the risks and damaged are probably not properly evaluated, this might very well be the case in many such devices.

2. Key derived from hardware configuration

   (Pros) It is no longer get-one-real-all, and still quite easy to implement on both the receiving and transmitting ends.

   (Cons) It is still quite easy to generate a key per device given the hardware configuration, and brute-forcing the hardware configuration values might be possible (especially when reading all devices' traffic is desired).

3. Single whole-deployment replaceable symmetric key

   (Pros) Once a key is known to have been exposed, it is possible (although not quite a simple task) to replace it with a new key. This enables mitigating key leaks in case they get too serious, at the cost of a big logistic operation.

   (Cons) Since replacing keys for the entire network is a difficult logistic task, this won't be used too often in real-live scenarios. Additionally, the extra effort of maintaining a key update mechanism is required regardless of it ever being used.

4. Per-device independent of hardware symmetric key

   (Pros) This guarantees complete protection between different meters, and increases the burden of retrieving the key for any meter an attacker is interested in reading. It also makes it possible to change individual keys with no added infrastructure.

   (Cons) Maintaining a record for all available keys (and their appropriate meters) just became a big burden, both development-wise and logistics-wise. The receiver now needs to keep a database of all keys and be able to fetch the correct key for the right meter.

5. Asymmetric key

   (Pros) Because of the nature of asymmetric cryptography, this makes it impossible to decrypt future or past messages even after gaining access to keys and code inside a meter, while every meter with the key can encrypt messages, only the receiver can decrypt them.

   (Cons) While this is probably the best encryption model for such a scenario, it is the most complex to implement and manage, and has a lot of ceavets that might render the encryption useless if used incorrectly. It also tends to be relatively slow to encrypt or decrpyt, unless symmetric encryption is used as part of the model (which complicates this even further).

The ones I would assume are most likely to be used in the scenario you describe are either 1 or 2, as security is rarely a consideration for those type of embedded devices today, let alone 10-20 years ago. I made this list more general then necessary in hopes it'll be useful for future readers.