Reading the specs of a new electricity smart meter (called Linky in France), I was surprised about the chosen encryption method (128 bits symmetric key AES), based on a single secret key (called CCC in the specs), that is shared between the meter and the central system, used to generate session keys to encrypt data.

Some context from the documentation:

5. PLC COMMUNICATION SECURITY - Each meter must have a CCC secret key, a unique CC_LAN key, a unique CC_LOCALE key and two session keys for the LAN interface and a session key for the Local interface, transmitted when the application association with the Client concerned was created

5.1 Encryption method - 128-bit AES symmetrical key algorithm, GCM operation mode. It is used to ensure data confidentiality and authentication.

5.2 "CCC" secret key - The CCC key is used to reprogram the "CC_LAN" key or the "CC_LOCALE" key in a meter. This key is never used to encrypt the communications between the concentrator and the meter. It is known only to the meter and the IS (Central server). When the CC_LAN (and the CC_LOCALE respectively) is generated, the IS encrypts it with the CCC and transfers it to the meter via the concentrator. This transfer is completely transparent for the concentrator which sends the encrypted data to the meter. The meter that knows the CCC is responsible for decryption the data in order to retrieve the CC_LAN (and the CC_LOCALE respectively). The CCC key is not accessible in read mode.

5.3 Unique "CC_LAN" and "CC_LOCALE" keys - The CC_LAN and CC_LOCALE keys are only used during the application association phase between the concentrator and the meter, and the TSP and the meter respectively. They are used to crypt the service allowing this application association. This service transfers the session key that will then be used, in the context defined by t his application association, to crypt the communications between the concentrator/TSP and the meter. The CC_LAN and CC_LOCALE keys cannot be accessed in read mode.

A quick note on the architecture: the meter communicates with the local transformer using PLC on open power lines, the transformer communicates with the central system with GPRS. The local transformer, apart from local network management, only forward data packets "as-is" to the central system.

(More information on the architecture is available here. Security is chapter 5, pages 39-40).

  • What is the security implication of having a central repository of secret keys?
  • If the central key database is hacked, does an attacker is able to decrypt the communication of any meter? To tamper it?
  • Why not choosing an asymmetric public key mechanism instead, where the central system does not have to know the private key of all meters? Is this has to do with the complexity of securely communicating the public key once generated? (since the central system has to ensure the authenticity of the public key maybe a manual intervention would be needed?)
  • Could you please elaborate on the architecture, in particular on the key usage ? I read the specs you linked and I'm not 100% sure of what part you're talking about. This is a specific case that (IMNSHO) requires a specific answer but I'm not exactly sure what part of the spec you're referring to. (in general, it's always nice to have questions that are self-contained since public links have a bad tendency to disappear after a couple of year, making it hard for later readers to understand the context)
    – Stephane
    Commented May 18, 2016 at 10:03
  • I added some context inline from the documentation. But apart from what's in the document, I do not know that much of the system, it has been designed as a "black box" (that's part of my concern too). Commented May 18, 2016 at 10:38
  • I'm sorry but looking into your question I realized it is simply too broad: the whole protocol could be analyzed in a paper and each of your questions require a different answer. Could you please edit your topic and narrow down its scope to one specific question ?
    – Stephane
    Commented May 18, 2016 at 11:32
  • Is this OSGP? eprint.iacr.org/2015/428.pdf
    – symcbean
    Commented May 18, 2016 at 11:45
  • 1


Browse other questions tagged .