In recent weeks there has been some media speculation about the security of the Smart Metering System being rolled out across the UK. This article is not a full discussion of that entire system's security; you can read the GB Companion Specification, the Smart Energy Code and the assurance Security Characteristics for the individual pieces of equipment if you want that level of detail . Instead, this article outlines how the security has been developed, and what we're trying to protect against.
The Department of Energy & Climate Change (DECC) and GCHQ designed the Smart Metering System with proportionate, practical security controls so that no single compromise can have a significant impact. It’s important to remember that the system operates on a national scale. Some of the design considerations may at first seem counter-intuitive, but the Smart Metering System has been designed - from the start - as a system, not just a collection of meters, suppliers and other components.
Looking at any single component or function in isolation is likely to give erroneous results. Therefore this article explains how the components of the Smart Metering System all interact in planned ways in order to contribute to the overall security of the system.
High level system design
The high level system design, shown below, describes all the parties involved in the system. These are:
- Gas and electricity meters and related consumer equipment, and suppliers (all of which are self-explanatory).
- Distribution Network Operators (DNOs) who run the pipes and wires that push gas and electricity around.
- The Data Communication Company (DCC), a licensed entity that on one side provides an interface to the service users, runs a bunch of routing and management stuff in the middle, and on the other side has an interface to the control system that is the smart metering devices.
- Communication Service Providers (CSPs) that provide the communications from the DCC to the equipment in people's houses. For the sake of this discussion, assume the CSPs are just mobile network operators.
- Finally, the 'third parties', which as service users of the DCC could be price comparison websites or services. They could be authorised to obtain (for example) 13 months of meter readings to identify the best tariff for that consumer, given their energy usage. However they can only obtain these 13 months of readings with the consumer’s consent, and they don't get any other information or privilege (all whilst remaining under the control of the consumer).
High level system design of the Smart Metering System
A matter of trust….
One of the first tasks for the joint DECC/GCHQ security team was an exercise we called 'trust modelling'. This involves understanding how the parties in the system interact, and where trust needs to be managed. Just because you’re part of the system doesn’t mean anyone else should implicitly trust you.
For example, you need to trust your energy supplier to correctly set the tariff on your meter, but no-one else should be capable of doing this. One of the key design principles for the system is maintaining user privacy, so the meters should trust no-one with the meter readings unless they're the supplier, or have been specifically authorised by the consumer.
This is one just example of the many privileges and expectations within the system. What came out of the trust modelling exercise was a set of transactions (for example, 'read electricity meter', 'change tariff', 'change supplier', 'disconnect supply') that occur between parties.
- If the transaction contained data which could be deemed personal (for example consumption readings or debt values) it was deemed 'sensitive', and would need to be encrypted so only the intended recipient could see it.
- If the transaction could affect supply, it was deemed 'critical' and would need to be strongly authenticated (through cryptographic signatures) so no-one else could lie or pretend, again with encryption between the parties involved in the transaction.
One of our design principles was to minimise the number of entities we have to trust for each transaction. If we don’t need to trust it, we don't need any confidence in its security, and this makes the build of the system easier.
Plan for the worst – but don’t expect it
We also built a threat model, which is a set of hypothetical attacks, errors and failures that could cause an impact that would concern us. An example could be an electricity supplier's systems are compromised by an attacker, or someone finds a vulnerability in a widely deployed gas meter. Just because it's in the threat model doesn't mean it's happened (or even that it's likely to happen), but we need to design the system to cope in the unlikely event that it does occur. In this sense, security is similar to insurance; you're planning for the worst, but not necessarily expecting it.
Who are you?
To make effective trust decisions based on who you're talking to, you need to be able to identify other parties. However, the identity may be specific to a transaction. You also need someone to vouch for those identities and that’s managed through the Smart Metering Key Infrastructure (SMKI) and some DCC-specific key infrastructure. Both of the infrastructures are pretty standard designs with all the security things you’d expect, like HSMs, split authorities and so on.
For example, consider a supplier. They have one 'identity' to identify themselves to the DCC services, and a completely different ‘identity’ that is used to authenticate to meters. When a consumer changes supplier (which includes initial installation), a secure protocol allows the new supplier to 'take ownership' of the meter. The effect of taking ownership is that the meter ends up knowing the supplier's identity (the public key, certificated by a trust authority), and a new set of transport keys are agreed to further protect communication (elliptic curve Diffie-Hellman and ECDSA keys for the technically inclined).
The meter will now only accept certain commands if they are signed by the supplier. There's a similar (but separate) set of identities that the meters understand for other parties in the system, for example the DCC itself and DNOs. Each identity has a very specific set of tasks it can perform. For example, an identity that is a DNO can't set tariffs (or do other things that a DNO has no need for). So how does the supplier know it's talking to the appropriate meter? You can't simply buy a meter, plug it in and expect it to work with the GB Smart Metering System.
Meters have to be brought into the system by the DCC. In general, that's done as part of the commissioning process. Meters have identities inserted into them to show these are real, authorised GB smart meters. These are just normal certificated public/private key pairs, with the DCC holding a register of public keys. The keys are certificated by a certificate authority (CA) that the DCC runs. The smart bit is that each CA authorises a fixed number of meters, and is then destroyed. It's not needed once the keys are in the meters, and if it’s destroyed it can't be compromised.
Revocation is an odd concept in this system design, but be assured we have lifecycle management of the keys. Remember, these are just identities for the meters, any keys that we really care about (for example keys which protect consumer data or authenticate critical commands) are created as the various parties take ownership of the meter. So neither the DCC nor the manufacturer of the meters have keys that are important to others.
Security in an insecure world
During the design of the system, GCHQ and DECC assumed that vulnerabilities would be found in the various components during the life of the system. This is a reasonable assumption because not everyone who is building things for the Smart Metering System are cyber security experts, and building a system devoid of any vulnerabilities is very hard to do (to the point of probably being impossible).
In addition, setting the security bar very high for each component would make the system unaffordable, so we've gone for commercial good practice. If this means there will be issues found during the life of the Smart Metering System, how do we make the system tolerant to attack?
One of the first ways is to minimise the impact of a vulnerability in a meter. A vulnerability is only a concern if it can be exploited, and for most classes of vulnerability, an attacker needs to be able to ‘talk to’ the vulnerable code. Therefore, each message received by a meter is authenticated via a simple cryptographic algorithm (a keyed HMAC), where the meters all have unique authentication keys.
For clarity, that authentication code is unique to each message and each meter. Sending two messages to the same meter means each message has a different authentication code, and sending the same message to two meters results in different authentication codes. In order to start attacking the meter, you have to get past this authenticity check, and the only entity that can generate the authentication codes is either the DCC or the meter itself.
If you reverse engineer a meter, you get precisely enough information to compromise that specific meter. The data in that meter doesn't help you attack any other meter or any other party in the system. This authentication check is really easy to implement in equipment, and we can therefore do some robustness checking on that implementation. Exploiting a vulnerability in the meter is difficult because getting to talk to the vulnerable code (which should be after the message authentication check that we have some confidence in) is difficult. This has the side effect that only messages that have been through the DCC get processed by the meter at all. If the message authentication check doesn't pass, the message is discarded.
Looking for weirdness
Now, let's suppose that despite the security controls put in place by an energy supplier, an attacker compromises an electricity supplier system and starts sending lots of disconnect commands. Firstly, they can only send valid commands to meters where this supplier has ownership; they can't do anything at all to meters bound to other suppliers because they simply don't have the keys that those meters will trust.
Let’s also assume the attacker wants to disconnect all the meters that this supplier runs. Since he's compromised the supplier system, he can generate the disconnect messages and correctly sign them using the supplier's identity. He then sends them off to the DCC to have the authentication code (which only the DCC can generate) added to the message, and have the messages delivered to the meters. There's a function in the DCC called 'anomaly checking' and it does what it says on the tin - looks for weirdness. In the case of disconnect commands, we don't expect many to be sent on a daily basis. So, there's a simple counter in the DCC. If it sees too many disconnects being sent, it just raises an alarm and stops the messages being routed on.
So apart from the first few disconnects, nothing too concerning happens. But my attacker is now really clever; he's going to bypass the DCC, generating all the messages in the compromised energy supplier and getting them into the communications infrastructure directly. Unfortunately for our attacker, that means that the DCC authentication code hasn't been added to the messages for each meter, so when the messages are received, they're just discarded by the meters. In order to disconnect more than a handful of meters, the attacker would have to compromise a supplier (so he has access to the identity that allows him to command some meters) and the DCC itself so he can add the per-meter authentication code to the disconnect messages. Even then, he's limited because the communications infrastructure limits how many meters can be online with the system at any given time, and there's some more anomaly checking in the CSPs.
So to have a mass effect, he'd have to compromise the CSP network as well, which would represent three independent large scale compromises. Even then, there’s a limited number of meters that can be affected at any one time due to the physical way the communications work. For each entity involved in the system, there's a standards–based assurance scheme to make sure that the chance of each compromise is very low. Obviously, there's capability in the system to help recover securely in the case that some of the identities are compromised, so once the compromise is detected, there's a well understood process for fixing things.
Models that survive contact with reality
As the system design progressed, several weird constraints and edge cases came out of the woodwork. This is often true in real world security systems; the idealised, academic security model very rarely survives contact with reality.
One of the more challenging design constraints was that the gas meter had to be battery powered for safety reasons. Given the on-the-wall life of a meter is 15 years, we have a very constrained power budget. Cryptographic operations are heavy on maths, and that means they use a lot of power. So we had to ensure the gas meter’s battery couldn’t be exhausted (for example through repeated meter reading requests), while still ensuring that only the gas meter itself can decide to act on a critical message.
In the end we designed a 'gas proxy' into the comms hub (which is mains powered, via the electricity meter). This acts as the gas meter in some low-risk situations (for example sending stored meter reads), but just acts as a pass-through for anything critical.
Conclusion: delivering proportionate and practical security
We hope that this article has explained the thinking behind the design of the Smart Metering System. DECC, with support from GCHQ has security right at the top of the list of things it cares about. Of course, no system is completely secure, and nothing is invulnerable. However, we’re confident that the Smart Metering System strikes the best balance between security and business needs, whilst meeting broader policy and national security objectives.