I am currently working on a research on end-to-end security implementation for Advanced Metering Infrastructure (AMI). Pardon me if I a bit off topic or not asking the right question as I am relatively new in the cryptography field and hope to get more information.

So basically I am to research on implementing security for smart grid system ensuring data integrity, authenticity as well as confidentiality for AMI when message is passed from the smart meters, to a concentrator where it computes and aggregate data received and finally sent to the utility end. One important consideration is that smart meters have limited processing power. As such, the cryptography algorithm should not have a large processing overhead in this case.

So right now I have this in mind after some research and reading relevant literature:

  1. A shared master key across all the devices.
  2. Smart meters authenticate themselves using this master key together with their unique ID.
  3. After which this master key will be used to generate a session key for secure transmission.
  4. Using HMAC and related algorithm to sign data and transmit to concentrator. Concentrator perform checking base on the HMAC received. If integrity is verified, it is then send to the utility.

The usage of a symmetric key (master key) is to ensure that there will be lesser computation as compared to any asymmetric design.

  • $\begingroup$ This is a bit of a tangent, but if you're interested in learning about what some more sophisticated crypto can do in the specific context of smart meters, you might want to read up on work by George Danezis et al., e.g., www0.cs.ucl.ac.uk/staff/G.Danezis/papers/DFKZSEGS13.pdf. $\endgroup$ – Seth Oct 14 '14 at 17:50
  • $\begingroup$ hi Gilles, thanks for your input. Yes, i do need more, alot more information on crypto especially in the context of smart meters. Thanks for the direction. $\endgroup$ – kenAu89 Oct 15 '14 at 2:04
  • $\begingroup$ F.Y.I. The PRIME PLC protocol is a smart meter protocol. For security it uses a per-device key (known by the concentrator), and AES-CCM to protect packets. You can freely see the specs $\endgroup$ – Ruggero Nov 14 '14 at 8:34
  • $\begingroup$ Hello @Ruggero, thanks for pointing that out. I will look int out. Right now, we are looking into implementing Chameleon hashing to provide end to end security. Thanks! $\endgroup$ – kenAu89 Nov 24 '14 at 3:05
  • $\begingroup$ Have you actually determined that an asymmetric key agreement (or simply sealing computation) would be too expensive? Using primitives such as Curve25519 this is really quite cheap and implementation can be fast thanks to public domain code such as nacl. $\endgroup$ – Thomas M. DuBuisson Jan 12 '15 at 23:07

In distributed systems it is often bad practice to have "Shared Master Key". If a bad guy breaks in one of your devices he has the most important crypto piece of the system, and you're pretty much done. Rather have one key per device, and these keys are signed by an Authority I would say.

| improve this answer | |
  • $\begingroup$ hello Mr Cedric, thanks for your valuable input. I will consider changing my design regarding the shared master key. $\endgroup$ – kenAu89 Oct 15 '14 at 2:03
  • $\begingroup$ Key per device yes, but signing a secretkey doesn't make sense, especially on a low-capability device (even RSA verify is costlier than symmetric). It sounds like this application may have many devices maybe millions and historically cryptosystems often had trouble securely storing large numbers of keys; if true here, the classic solutions are for the central host to store devicekeys encrypted under a local masterkey, or to derive devicekeys from a masterkey hashed with uniqueid per device (like serialnumber) so the host can re-do this derivation on each transaction with a device. $\endgroup$ – dave_thompson_085 Oct 16 '14 at 9:40
  • $\begingroup$ helo @dave_thompson_085, thanks for the insight. after another week of researching, I am actually looking into what you mentioned, to use unique id, together with a masterkey and a nonce (probably timestamp) to generate a session for device to authenticate themselves. thanks! $\endgroup$ – kenAu89 Oct 27 '14 at 17:26

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.