Smart Meters – Threats and Attacks to PRIME Meters

A golden rule in the world of cybersecurity is that the system risk is greater than the aggregate risk of its component elements. This is because, as the number of vulnerable elements grows, the more sophisticated (and difficult to trace) the attacks against the system become.

The first necessary step to identify the risk of an element is to study the threats to which it is subjected and, subsequently, to study what makes it vulnerable to them. Thus, in an infrastructure of intelligent meters, the most pertinent threats are the following:

• Threats to meters
• Threats to the network hub
• Threats to the remote management network
• Threats to the distributor’s servers
• Threats to links

This article will list the threats to smart meters and, due to the relative lack of knowledge about the PRIME protocol, what kind of attacks on the PRIME protocol could make them possible.

The meter under threat

To put it simply, a smart meter is a device that allows:

1. Usage information to be measured and stored
2. Usage data to be sent to the distributor
3. Remote management orders to be received from the distributor
4. Update firmware
5. Display usage

With the exception of the usage data visualization functionality, the rest of the operations can be considered privileged and, therefore, any possible intentional alteration of the same poses a threat.

With regard to measuring usage, the main threat comes from its alteration. One way to do this would be, for example, to modify the transformation ratio of the meter. Another way would be by interacting with the hardware of the device and modifying the memory that stores these measurements. Fortunately—and except for the presence of other vulnerabilities—the first form is easily detectable, and the second is difficult to exploit.

Regarding the communication of usage data to the distributor, the greatest threat has to do with fraudulent frame injection along the line. Unfortunately, a combination of insecure protocols and poor isolation between the user’s outlets in the home and the meter’s PLC network makes this attack quite feasible. Due to the absence of filtering on these two lines, an attacker could flood the line with high frequency noise, inhibiting frames being sent to the network hub. At the same time, it could send fraudulent frames to the network hub using a PLC modem containing erroneous information. Although the degree of expertise necessary to carry out this attack is quite high, today there are facilities where it is technically possible.

With regard to the reception of remote management orders, two different threats are present, depending on the destination of these data. From the point of view of reception, the user could inject frames locally from their residence, supplanting the identity of the network hub and executing privileged operations. Regarding possibilities for sending, that same attacker could send frames to other meters connected to the same phase, modifying their parameters or even cutting off the supply of other users.

Finally, with regard to firmware updates, there are all the threats of attacks related to the absence of firmware integrity checks. This would imply all the previous threats, in addition to the potential of the attacker to take control of the meter.

Attacking from PRIME

Clearly, just because these threats exist does not mean they will occur. These threats depend on a related a vulnerability to make them possible.

Although a smart meter is a device with a more or less heterogeneous attack surface, the novelty of these devices is their PLC connectivity. For this reason, this article will focus exclusively on attacks carried out from a PRIME network.

Central nodes, peripheral nodes and switches

Although the PRIME networks are made up of a star topology (the centre of the network being the local network hub), the physical limitations in terms of transmission of the electrical lines force them to acquire a logical topology closer to that of a tree network. In this network topology we find the following types of nodes:

• Central node: there can be only one central node in the entire network, and it is identified with the tertiary network hub. It is ultimately responsible for determining who has access to the network, and what security profiles can be used. The association between central nodes and periphery nodes is referred to as the “log” in the PRIME specification.
• Peripheral node: the smart meter. A peripheral node, once turned on, will hear beacons in the PLC network coming from the central node. If it does not receive any in a given time (which is very common if the meter is too far away from the hub), it will begin to warn the entire network of what is happening, requesting that a nearby meter act as a repeater between the remote meter and the central node. This process is called a “request for promotion,” and requires the involvement of the central node in order for it to take place.
• Switch node: an smart meter that, due to the presence of meters far away from the central node, has been promoted to a repeater, and is in charge of forwarding the packets of one or more meters from the network to the central node and vice versa. Switch nodes can be demoted to peripheral nodes by the network hub in certain situations (for example, the presence of too many switch nodes in the network).

Numbering the attacks

The possible attacks to the nodes of the PRIME network have already been detailed in the article “Cybersecurity Vulnerability Analysis of the PLC PRIME Standard” (DOI: 10.1155/2017/7369684) in the journal Security and Communication Networks, 2017, by Miguel Seijo Simó, Gregorio López and José Ignacio Moreno Novella from Universidad Carlos III de Madrid. This article analyses the security of version 1.3 of the protocol and raises the possibility the following attacks:

1. Jamming in the physical layer.

This is perhaps the most basic attack that can be made against this protocol: a signal is injected along the line that interferes with the PRIME frames in order to prevent communication on the line.

There are several ways of jamming a communications channel. The simplest is through the injection of Gaussian noise: a very wide spectrum (the only limit on its width being the output filters of the noise generator) and requires very little knowledge about the signal to attack, just a vague idea about the frequency at which the signal to be interfered with operates. Note also that Gaussian noise generating circuits (especially with bandwidths of the order used in PLC communications) are extremely easy to build: just connect a noise generator to a coupling transformer.

Its low selectivity is at the same time its Achilles heel: most of the power injected into the channel is filtered by the PLC receiver, which only accepts a small portion of noise. In addition, these types of signals are OFDM modulated, using different error-correction codes, further reducing their effectiveness. For this attack to actually be effective, it must either increase the noise volume (something that is not always possible) or concentrate the power in a reduced frequency band in which the signal of interest is known to be. This is what is known in literature as colouring the signal.

The last form of jamming discussed is known as “jamming by correlation” and requires prior knowledge of the parameters of synchronization and modulation of the signal, as well as adequate hardware to be able to carry it out in real time. In this type of attack, a synchronization is made with the frame that is being sent and, from that synchronization, random symbols are injected that distort it irreversibly. Despite the technical difficulty of this type of attack, it is perhaps the most effective and optimal in terms of energy, since it is almost exclusively focused on altering the information encoded in the frame.

2. Jamming the access control protocol to the medium.

PRIME is a protocol that uses CSMA/CA to control media access and avoid collisions. In this jamming technique, the same strategy as CSMA/CA is used to sound out the occupation of the channel. However, when it is found that a frame is being sent, a small collision is forced to occur, obliging the sender to retransmit the frame. By forcing this collision several times, the issuer is made to desist and consider the frame transmission a failure.

3. Flood of promotion requests.

One of the peculiarities of PRIME is that it is able to compensate for losses in lines too far away from the network hub by using intermediate meters as repeaters. This is achieved when the remote meter, in the absence of network beacons, requests the promotion of a nearby meter (by sending a PnPDU frame). Each nearby meter that receives a PnPDU sends a promotion request to the network hub, which evaluates whether such a promotion should be made or not.

An attacker could take advantage of this behaviour by injecting a multitude of PnPDU frames with the wrong MAC address, amplifying network traffic by sending a promotion request for each meter received by the PnPDU. The network hub, for its part, will see that there are many meters with very poor connectivity, granting promotions to the rest of legitimate meters, increasing the complexity of the network’s logical topology, slowing it down and causing errors.

4. Overflow in the node log.

The first thing that every meter must do in order to interact with the network is to register in the hub (identified with its MAC address) and obtain a unique node identification (NID) in the network. This NID is a 22-bit number, divided into a switch identifier (LSID, 8 bits) and a local node identifier, within the switch (LNID, 14 bits). This means that in PRIME networks there can be up to 256 switches, with 16384 nodes each.

21	20	19	18	17	16	15	14	13	12	11	10	9	8	7	6	5	4	3	2	1	0
LSID								LNID
NID

When a node is registered, it can indicate through which switch it is doing so. This behaviour could allow an attacker to overflow the LNID for a given switch by sending multiple registration requests with different MAC addresses. The behaviour of the network hub before this eventuality is not contemplated in the PRIME specification: it may start de-registering the oldest nodes, stop accepting new registrations or, in case of poor firmware implementation, a buffer overflow may occur.

5. Identity theft in the node registry.

Another aspect not clarified by the PRIME specification is what happens when the same node attempts to register twice, meaning the behaviour depends on how they are implemented. Two outcomes, therefore, are possible:

1. The network hub rejects the registration until it is de-registered (either explicitly or by timeout).
2. The network hub grants a new NID to the MAC.

Both outcomes are vulnerable to attack: with the first, one could block access to the network of a certain meter, registering before the legitimate meter can. With the second, one could disconnect arbitrary meters from the network simply by knowing their MAC address.

6. Local switch identifier overflow (LSID)

If the flood of promotion requests is taken to the extreme, you could get the network hub to reach the maximum number of active switches on your network (256), after which two things could happen: either the network hub prevents more switches from being promoted, or it starts to degrade older switches, leaving entire sections of the network unconnected.

7. Impersonation of the central node.

By definition, in a PRIME network there can only be one central node (the network hub). If an attacker presented itself to the network as a central node and gets other peripheral nodes to connect to it, it could take usage measurements, modify billing periods or even turn off the power. Note that even if you have the PRIME 1 security profile, the malicious network hub could request a downgrade to profile 0, leaving the original profile powerless.

8. Impersonation in degradation / deregistration / disconnection messages.

In this attack, the attacker would pass through the central node and send various control messages to the peripheral nodes with the aim of causing a service rejection. Depending on the type of message, you could disconnect an existing connection, deregister the entire network hub or, in the case of a switch, disconnect it together with all the meters connected to it.

9. Traffic interception.

This is the most basic way compromise the network privacy, and also the most difficult to detect (which is the point of the attack). If frames are not properly protected, an attacker could obtain usage data from users by simply capturing traffic.

Please note that even if security profile 1 is used, the privacy of communications is not fully ensured. This is a consequence of the limitations in the key policy used in PRIME based on pre-shared keys. It is enough to compromise the keys of a peripheral node to compromise all the communications carried out between it and the network hub.

10. CPU overload by SCRC in profile 1.

All things considered, this is an attack that exploits the reduced computational resources of the network nodes. In security profile 1, frame integrity is ensured by the SCRC (which acts as a CRC code above the frame content before being encrypted). Since in order to validate the SCRC the content of the frame has to be decrypted first, an attacker could flood the network with large packets and arbitrary content at a very small computational cost. Receiving nodes would be forced to decrypt frames, saturating their CPU and potentially rendering them unresponsive.

11. Traffic re-injection.

Finally, in traffic re-injection attacks, the attacker will capture frames (encrypted or not) and retransmit them trying to produce the same effect as the original frames.

The Achilles Heel of PRIME 1.3 Profile 1

The PRIME 1.3 standard details the procedure by which the different keys used by the protocol are derived. These keys are generated from different values used as a seed and generation key (GK) with a key derivation function (KDF) consisting of an AES-128 in ECB mode:

This key derivation strategy is used to generate the intermediate keys DSK (Device Specific Key), KDIV (Key Diversifier), USK (Unique Secret Key), WK0 and WK (Working Keys). The different phases of key generation are paired together as follows:

All the input data used to derive the key that is used to encrypt the content of the frames (working key, abbreviated as WK in the literature) appears in orange . Although at first glance it might appear that there are several sources of entropy for the computation of this key, most of them do not add security to the key:

• The Master Key 1 is administered in the central node. However, because the Device Specific Key of each meter is fixed (set when the meter is manufactured) and must be able to be calculated via derivation function through its MAC address and this Master Key 1, it is concluded that the Master Key 1 is also fixed.
• The MAC address of the devices cannot be changed and is also easily obtainable.
• The random seed SEC.RAN defined in registry messages is not encrypted when exchanged.

It can thus be concluded that the only really protected key material is the Master Key 1 and the Master Key 2, with two important weaknesses:

• Master Key 1 and 2 are used to derive keys from absolutely all devices in the network. Compromising one of these keys affects the communications of the entire network.
• Once the Master Key 1 has been compromised, changing it implies replacing all the meters in the network.

It is therefore concluded that the security of a PRIME 1.3 network is reduced to the maintenance of the secrecy of two unique keys MK1 and MK2, with the particularity that in addition, if the MK1 is compromised, the only way to remedy it is by replacing all the meters.

Mitigating as much as possible

Most of the attacks mentioned above can be made more difficult by raising the security profile in the PRIME 1.3 configuration and ensuring compliance with meter whitelists for the network hubs: By limiting which meters can register or request the promotion of a switch based on its MAC, most flood and overflow attacks are limited.

PRIME 1.3’s profile 1 simply complicates traffic analysis from traffic encryption by deriving keys from an immutable factory key, which the network hub can derive at any time from the MAC. If this derivation mechanism is compromised, all keys derived from all meters using profile 1 would be immediately compromised (this is corrected in PRIME 1.4’s profile 2). In addition, since attacks such as the introduction of false central nodes into the network render it ineffective (see attack #7), the only viable security option for PRIME is security profile 2, which is only available in version 1.4 of the protocol.

However, it should be noted that the PRIME 1.3 protocol is not very robust in terms of security: authentication is based on mutual knowledge of symmetric encryption keys (PRIME 1.3 standard, lines 1441-1442) and replay attacks could be possible even if the SCRC is in place due to the lack of NONCES (PRIME 1.4 improves security in this sense, introducing AES-128-CCM in its frames, 1691-1698). There is also a lack of forward secrecy, so keys should be changed regularly to prevent a compromised meter from decrypting all previous traffic. And finally, the encryption uses ECB: if the frames are very long, a sufficiently large analysis of frames could reveal the presence of patterns (and thus compromise the privacy of communications).

Profile 2 of PRIME 1.4 is a substantial improvement on profile 1. However, since PRIME is still a physical layer and link protocol, it is advisable to complement it with application layer security to provide the appropriate authorization mechanisms.

Thanks to Alfonso Muñoz for his evaluations and suggestions on our derivation mechanism analysis of PRIME 1.3 keys.

Discover our work and cybersecurity services at www.tarlogic.com