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:
Injecting the software image
Generating device keys (above diagram), certificates and configuration parameters for the device
Using a factory tool to inject the generated keys, certificates and configuration parameters to the device on the manufacturing line
Using a key configuration manager and factory configurator client (FCC) APIs in the device to validate the information
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.
3. Secure Communications
The introduction of the Advanced Metering Infrastructure (AMI) assists utility companies with the automation of monitoring, billing, connection, and disconnection. It’s the culmination of smart meters, communications networks, and data management systems that enable two-way communication between providers and customers. This additional layer of communication facilitated by the low power, long-range functionality of low bandwidth connectivity exposes utility providers to additional risk. Therefore, communication between the device and the IoT platform, then onwards to the utilities provider’s web application, is secured by using standard TLS.
click for larger image
Figure 3: An example of chip to cloud TLS encryption. (Source: Arm Pelion IoT platform)
TLS is a cryptographic protocol that provides end-to-end communications security over possibly untrusted networks and is widely used for IoT device communication to the cloud. The basic steps to communicate over a secure communication channel using TLS include initialize an SSL/TLS context, perform an SSL/TLS handshake and establish a secure connection between smart meter and cloud, send/receive data between smart meter and cloud, and notify a peer that a connection is being closed.
This industry-standard method not only acts as a cryptographic protocol, but it also removes the need for cumbersome and insecure passwords. This is because the act of presenting a signed certificate presents the utility provider’s account with a validated unique device ID, removing the need for other forms of identification. With the use of Device Language Message Specification (DLMS), communication to meter goes over DLMS using Security Suite 1 which is PKI based for authentication and key agreement, and uses AES-GCM-128 for authenticated encryption.
4. Trusting update sources
Updating devices in the field is key to a successful smart meter deployment, some of which could last for more than 20 years. During this time, OTA updates can offer additional functionality for both end user and utility provider post-deployment including fixing bugs, extending the serviceable life, and thus the overall lifecycle cost of a unit. Remote updates are also an effective means of protection from the latest threats or newly discovered vulnerabilities without the rigmarole and cost of manually updating in the field.
Yet, conversely, the very act of updating a device to administer protection from the latest threat could pose its own risks if the update itself is unverified.
Devices need to make important decisions about firmware in a suggested update. For example, is the update trustworthy and applicable to the device? A way to verify if the firmware update image is trusted is using metadata (known as the manifest). The manifest is digitally signed to authenticate the integrity of the update itself before any action is taken. The author of the firmware owns the keys to provide end-to-end verification of the update. The authoring and signing of a firmware manifest ensure that only trusted updates (those with a verifiable chain of trust) are applied to the correct devices.
The easiest way to create manifests is to use a manifest tool, which runs on your PC to create, sign and upload manifests and test the entire end-to-end update flow.
5. Secure, Confidential Update Campaigns
Just as OTA is key to a secure device lifecycle, security itself is key to a successful OTA update. Firmware security updates deployed by an IoT platform are segregated from transfer protocol, which means the delivery network is treated as untrustworthy. This facilitates a secure update at scale by taking a packaged update, creating a campaign and then deploying that campaign securely to the connected device.
The Device Management Client waits for update notifications, then verifies the package, applies the update and reverts to the device’s original state if the update fails, before reporting any issues. What’s more, individual devices can be monitored for suspicious behavior during the campaign.
Rollback protection prevents meters from being maliciously rolled back to an older, more vulnerable firmware version and updates can only proceed if the associated firmware manifest is a later version. Downgrades to previous meter versions are available, but they require authenticated service operator authorization.
6. In-field Certificate Management
There are several scenarios where the utilities companies may want to prevent a deployed smart meter from connecting to the cloud. For example, If the integrity of in-field smart meter is breached and the certificates are compromised, suspension of the compromised devices by the utility company is key to ensure overall security of the broader AMI ecosystem. Utility providers also want to make sure that they can renew the certificate for the smart meters deployed in-field. Certificate renewal is necessary if the existing certificate of a smart meter is about to expire, and once expired, the smart meter will not be able to connect to services online.
The process of renewing device certificates involves an IoT device management platform such as the Pelion Device Management platform and its Device Management Client. This five-stage process typically involves:
Calling the Device Management API from the Device Management Portal, or from a smart meter.
The smart meter generates a new key, creates a certificate signing request (CSR) based on the existing certificate, and sends the CSR to Device Management.
The device management platform sends the CSR tothird-party certificate authority (CA) for signing of certificate.
The internal Device Management CA signs LwM2M certificates and sends it back to device management platform.
The device management platform then sends the signed certificate back to the smart meter in the field.
Utility companies are capitalizing upon the efficiencies and additional revenue opportunities presented by smart meters made possible by the IoT. Yet the speed and scale of this growth presents significant opportunities for cyber criminals as the attack surface increases with each device deployed and every update administered. An effective IoT device management platform can help establish a secure foundation that permeates through the meter’s operational life to foster streamlined, scalable deployments and ensure both utility companies and their customers remain protected.
Mohit Kedia is a staff product manager at Arm’s IoT Services group. Based in Austin, Mohit is focused on making IoT products a reality using Pelion Device Management, industry leading IoT SaaS product and Mbed OS, the most advanced open source IoT operating system platform in the world. Mohit previously held variety of roles in product management and solutions architecture at AMD and NXP leading hardware, software and silicon products for Internet of Things and emerging embedded markets. Mohit holds MBA from University of Texas at Austin and Graduate degree in Electrical and Electronic Engineering from Texas A&M University.