Advertisement

Enhancing privacy and security in the smart meter lifecycle

June 19, 2019

Mohit Kedia-June 19, 2019

The Internet of Things (IoT) is growing at a spectacular rate. The ability to control devices remotely and gain valuable data insights is driving us towards what is expected to be a trillion connected devices by 2035, delivering orders of magnitude more data than we see today. One area where we’re seeing a heavy growth in the number of connected devices is around smart meters. According to iHS Markit, spend on Advanced Metering Infrastructure (AMI) is expected to rise to $13 billion in 2023, compared to $9 billion in 2018. The companies providing our heat, light, and water are benefitting from automated meter readings, precise billing, plus remote connection and disconnection capabilities – all with less resource than was previously possible.

But this unprecedented growth creates an ever-expanding attack surface for cybercriminals to prey on essential infrastructure, or infiltrate and steal information from individuals and enterprises. For example, malware hackers utilized ‘Crash Override’ malware to gain control of Ukraine’s power grid in December 2016 and shut down 30 substations, blacking out the city of Kiev and reducing the city to one-fifth of its power capacity.

Security threats can take many different forms throughout a smart meter’s operational life. Utilities must consider various factors and be prepared for different attack vectors to ensure their customers are protected. For example, a side channel attack involves snooping and analyzing data consumption via Correlation Power Analysis (CPA) to gain credentials and access to infrastructure. Energy suppliers and the original equipment manufacturers (OEMs) need to enforce security from device to cloud. They also need to be able to update their firmware over-the-air (OTA) to ensure resiliency for a device’s lifecycle. So how can utility companies ensure their smart metering deployments maintain security and privacy for all stakeholders?

Important customer usage data, some of which may be Personally Identifiable Information (PII), resides inside the meters, meaning that smart meter security has direct implications on privacy. The data may be used by utilities to forecast energy demand, configure demand response, and offer recommendations on energy consumption. That data needs to be accessed in a responsible manner and managed in accordance with a range of regulations like the European Union’s General Data Protection Regulation (GDPR). Such policy enforcement requires a foundation for trusted data with security infused into data collection, data analytics, and the device itself. This requires root of trust in the devices, authentication-based access, plus encryption of data at rest and in transit.

Six ways an IoT platform enables secure and private smart meters

Ensuring smart meter security and data privacy requires a lifecycle approach extending from manufacturing through on-boarding and regular use (Figure 1). With an IoT platform such as the Arm Pelion IoT platform, the necessary lifecycle support is integrated in the platform’s device management and access control capabilities. The following sections describe six ways an IoT platform addresses lifecycle security requirements so critical for ensuring privacy.


Figure 1: An example of a secure device lifecycle. (Source: Arm Pelion IoT platform)

1. Ensuring a Root of Trust for the Large Volume of Smart Meter Deployment at Scale During Factory Provisioning

The production facilities tasked with manufacturing smart meters need to balance scalability with resilience that will ensure a device is trusted, offering a secure foundation for the meter’s life in the field. A root of trust (ROT) constitutes a series of functions within a secure enclave that is trusted by the smart meter’s operating system. Injecting credentials onto a single device can mitigate this risk, but the ability to scale this process to the millions of devices is key in maintaining the balance between efficiency and security. The matter of trusting a factory becomes more of a concern when you consider that utility companies are not manufacturers themselves and often outsource production and trust to OEMs. So how do we make a third-party factory ‘trusted’?

Trust is instilled by administering certificating authorities that cross-reference the IoT platform, bootstrap, and lightweight M2M (LwM2M) servers. A range of tools provided by the IoT platform provider offers a linear process for the configuration of the certificate authority (CA) that ensures only meters that possess a certificate signed by a CA and a public key can establish a connection between the device and its device manager.

click for larger image

Figure 2: An example of secure factory provisioning (Source: Arm Pelion IoT platform)

Once the CA is configured and linked to the manufacturer’s individual account the factory line is ready to mass-provision devices. This five-stage process involves:

  1. Injecting the software image

  2. Generating device keys (above diagram), certificates and configuration parameters for the device

  3. Using a factory tool to inject the generated keys, certificates and configuration parameters to the device on the manufacturing line

  4. Using a key configuration manager and factory configurator client (FCC) APIs in the device to validate the information

  5. Finalizing the provisioning process and blocking the FCC code in the production image to ensure that it cannot be accessed following provisioning

2. Trusted Connections with the Grid During On-boarding

As mentioned previously, OEMs producing smart meters can often be one step removed from the end user, meaning flexibility in the provisioning process is often required to meet their existing processes. For instance, some choose to create their keys and certificates in-house before bundling them into a factory configurator utility (FCU). The FCU sits within the factory line and works alongside the manufacturer’s factory tool to configure and inject a device with the credentials, which in turn validates the smart meter’s operational parameters. Alternatively, some choose to inject directly onto the device. While the former is a more efficient method, both are equally secure.

Because the OEM has no idea at the point of manufacturing where the smart meter will be deployed or the account it will be associated with, it is essential that the eventual connection with the grid is a trusted action. Therefore, manufacturers and utility companies utilize pre-shared keys (PSK) involving an enrollment list. This process verifies the unique ID to match the credentials to the enrollment information in a specific Device Management account, the device is then assigned to that account. This only happens if the device ID matches the ID uploaded in the utility provider’s IoT portal.

PSKs provide both devices and the IoT platform with a common key that has been securely provisioned into a device and constitutes the most basic level of security. It’s deemed basic because there is a risk that the credential passed to the smart meter during manufacturing and the confidential list of credentials stored on the servers could be compromised, leaving millions of meters and users’ data exposed. However, a public key infrastructure (PKI) is a more secure approach.

PKI makes the introduction between a device and the IoT platform and adds a layer of asymmetric cryptography that tethers the cryptographic signature to the third party that authenticates the meter. Using this third party is a far more secure way to authenticate, as credentials are only generated on the device itself and exist nowhere else.

Whilst providing this level of flexibility for an OEM, any IoT partner worth their salt will maintain security and ensure a unique identity during the bootstrap stage. The interaction takes place as part of the data transfer with the Bootstrap Server over encrypted transport layer security (TLS) communications, which is designed to prevent eavesdropping, tampering or message forgery.

Continue reading on page two, Secure Communications >>

< Previous
Page 1 of 2
Next >

Loading comments...