# Security of the shared secret key for a smart meter (Linky)

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, would the attacker be able to decrypt the communication of any meter? (For example, to tamper with it?)
• Is there any reason why not to choose an asymmetric public key mechanism instead, where the central system does not have to know the secret key of all meters? Does 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?)
• Is there any potential security risks of the chosen architecture?

Note: This question has been also asked on security.stackexchange.com.

• Some bad terminology is used in the question. AES keys are generally said secret, rather than private (that term is used for the non-public part of an asymmetric key). When an AES key is unique to a device, that's a unique device (secret) key. If that key is derived from a master key (held by a central server) and the device's serial number, that's a diversified (secret) key; that might be the case here, or not, we can't tell.
– fgrieu
May 18 '16 at 12:31
• Corrected... Disclaimer: I'm not a security expert, simply wondering about some specific choices made for this project. May 18 '16 at 13:24

Using asymmetric cryptography in the meters would have some benefits:

• it can make passive eavesdropping of meter/server communication useless, even to a party holding or able to use the server's private key; something not achieved with secret-key cryptography.
• it can ensure that any central key leak can not compromise the capability to authenticate messages from the meters.

But that's about all I see. In particular, even a full blown asymmetric public key mechanism can not solve the most serious problem that if the central system is hacked, and the hacker can communicate with the meters as the central system does, then all the capabilities the central system has (including reading any meter, or/and making any parametrization of the meters) are available to the hacker. A complete hacking of the central system is thus a disaster, no matter what.

That's why such central systems should be designed with multiple layers of security. In particular, they should hold secret keys, and the server's private key if some asymmetric cryptography is used, within devices intended to never leak such secrets, like HSMs or Smart Cards. That way, penetration of the outer layer (e.g. server's OS) simply can't leak secret or private keys (only, at worst, allow their use). After an attack, restoring the integrity of the server can hopefully restore security and functionality (unless the hacker managed to change the highest-level individual meter keys).

• Keeping secret keys on HSMs is probably obvious for a security-conscious organization; but I'm a bit afraid as there is no guarantee on that given by the company responsible for the management of this (anyway, that I am aware of). May 18 '16 at 13:44

If the central key database is hacked, does an attacker is able to decrypt the communication of any meter? To tamper it?

Indeed, if the central key database is hacked, then an attacker will know all the secret keys and so will be able to decrypt all communications.

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?)

Microprocessors used for smart meter devices are not necessarily powerful so manufacturers do not want to devote too much area for security. Asymmetric cryptography is very expensive in terms of power consumption, time execution and code size (unless the chip has a cryptographic hardware accelerator, but it increases the final cost considerably). That is why symmetric cryptography is often used. Note there are devices that cannot even run an AES because it is too heavy. To answer that, lightweight cryptography is well studied and aims to become a standard to secure the IoT.

• Compared to the cost of the whole meter, a dedicated asymmetric encryption micro-controller should not cost that much... And a well designed system could keep power consumption at a minimum, when no communicate takes place. The data bandwidth here is very low (2400 bps, probably no more than a few kb of data per day). May 18 '16 at 10:37
• Your link on lightweight cryptography is broken. May 18 '16 at 11:22
• @Raoul722 The link may be fixed, but the page you link to says Lightweight Cryptography. – There is currently no text in this page. You can search for this page title in other pages, or search the related logs, but you do not have permission to create this page. (see screenshot) I can only guess it’s not as fixed as you planned it to be. ;) May 18 '16 at 16:07
• @e-sushi Well that's very strange, on my computer the link seems correct! May 18 '16 at 18:26
• @Raoul722 Checked it again a few seconds ago and the page now indeed shows content. Guess they fiddled with the page as I tried to look at it. (Glad I took a screenshot, or I would call myself crazy right now.) If that’s OK with you, I’ll clean up these comments after you’ve read them… just tell me when. May 18 '16 at 18:29