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

Question

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.

Answer 1

In addition to the other answer

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

Answer 2

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.