Securing Smart Meters with MULTOS Technical Overview

Transcription

1 Securing Smart Meters with MULTOS Technical Overview Introduction This paper is written for those involved in the specification, procuring and design of smart metering infrastructure at a technical level. Its purpose is to give an initial technical overview of MULTOS and demonstrate why it is a good fit for that marketplace. Further, in-depth, technical documentation is available at In this document the applications running within the MULTOS chip are termed firmware (as opposed to applications ) as this is more in line with the terminology used in smart metering. This document makes reference to some of the main specifications related to the UK market and highlights where MULTOS does implement or could help to implement those requirements. Suggestions are also made as to how MULTOS could improve the proposed scheme. Such sections are in green text. Referenced documents are: Smart Metering Implementation Programme Great Britain Companion Specification (GBCS) v0.7 rev 6 [GBCS] SMLT-SC-0002 ESME v0-22 CPA Security Characteristic Electricity Smart Metering Equipment [CAP ESME] (the Gas equivalent is very similar so not referenced separately) RFC 5934 Trust Anchor Management Protocol [RFC 5934] Technical Overview: Version 1, 8 th April MAOSCO Ltd

2 Problems in need of a solution, and how MULTOS helps MULTOS is a secure operating system for secure devices. Traditionally it has been used in payment cards, ID cards, passports and transit applications. The high level of security needed for those applications, and provided by MULTOS, makes it an ideal choice for securing high-value and infrastructure-critical assets in the power distribution network. This paper discusses how the features of MULTOS can be used to solve security problems associated with Smart Meters in particular. Providing secure communications The security mechanisms of communications channels used in metering networks cannot be relied upon. A more credible approach is to implement a cryptographically based secure channel that logically connects devices end-to-end over any and all intermediate channels. By using a MULTOS device in a smart meter, it is possible to implement a secure protocol based on modern, up-to-date, cryptographic standards for a low cost, including physical tamper protection. Knowing that you are talking to a genuine meter There are several key points in a meter s lifecycle when you need to know that you are talking to a genuine meter. Loading firmware and/or keys for the first time, possibly after the meter has been installed on site Updating firmware and/or keys after the meter has been installed on site When taking readings When issuing commands to write to, or control the meter At the heart of the MULTOS Scheme, is the Key Management Authority (KMA) the Certificate Authority for MULTOS. This is an extremely secure facility based in the UK but serves MULTOS globally. All keys related to identifying a MULTOS chip, its initialisation for use and the loading / deletion of firmware are generated and/or certified by the KMA. Only genuine, bonafide manufacturers and suppliers can register with the KMA. Each MULTOS chip has a unique serial number and transport key injected into it by the silicon manufacturer. These serial numbers and keys are based on master values held by the KMA. This is all done before a meter manufacturer would obtain the MULTOS chips, which are at this point generic MULTOS chips and could be used for anything. At some point, depending on the scenario, the generic chip gets bound to an owner through a step called Enablement. This is done by loading data generated by the KMA (which is encrypted by the unique transport key of each chip) into the chip. Technical Overview: Version 1, 8 th April MAOSCO Ltd

3 As well as setting the owner identifier and product identifier (e.g. to identify the model of the meter), the enablement data includes a unique asymmetric key pair and public key certificate which are used for loading and deleting firmware (see later). This certificate includes the owner identifier and serial number as well so it is possible to check if a MULTOS chip and (by extension the meter) is genuine by asking for its public key certificate and verifying it with the KMA public key. Once you have loaded the firmware to the MULTOS chip, the secure protocol it implements (whatever that may be) can be reliably used to verify the authenticity of the meter for commands related to its active state (readings, write commands etc). There are several issues with [GBCS ]: There is no mechanism for validating that the entity requesting a Device Certificate Signing Request (DCSR) is actually a genuine meter. It assumes that the meter is capable of generating sufficiently random key pairs. The process of protecting and handling the remote DCSR itself is complex. MULTOS can solve these issues as follows: The generation of the Device Key Pair and certificate can be done using a FIPS approved Hardware Security Module (HSM) off meter and embedded securely into the firmware load package (as discussed in Remotely loading and updating keys below). Note that this is the approach used in the finance industry. Because the firmware package is cryptographically linked to, and can only be loaded to the intended MULTOS chip (i.e. the intended meter) it is possible to guarantee that the correct and genuine credentials have been loaded to any meter. Providing secure processing and storage (at low cost & low power) Secure protocols based on cryptography need well implemented cryptographic functionality, a safe way of storing keys and a closed environment for the cryptographic computations. This is exactly what MULTOS chips are designed for, having been proven worldwide in over half a billion devices to date. Furthermore some MULTOS products already have Common Criteria certification, giving meter designers added reassurance they are using proven secure products. In addition to this, the low cost and low power requirements make them ideal. Firmware loaded into MULTOS chips is safe; it cannot be modified by unauthorised parties or infected with viruses. Confidential data (identity data, readings, UTRNs, tamper indicators) cannot be accessed or modified except by the firmware to which it belongs or through a secure process called Delegation. Using MULTOS satisfies at least the following requirements related to the secure environment: [RFC ] requirements for a Cryptographic Module as required by [GBCS ]. [CAP ESME DEV.M846] Secure failure recovery [CAP ESME DEV.M926] Protected software environment [CAP ESME DEV.1.M902] Check firmware integrity before execution* [CAP ESME DEV.2.M847] Minimise interfaces [CAP ESME DEV.4.M138 and DEV.4.M290 etc] on random number generation [CAP ESME DEV.4.M349] Sanitise temporary variables [CAP ESME DEV.5.M897] Protection of security-related physical structure** [CAP ESME DEV.6.M943 and DEV.6.M944] on PIN handling *[GBCS] does not seem to include provision for ensuring the integrity of firmware and data once it has been safely delivered to the meter. ** This includes the keys used. Technical Overview: Version 1, 8 th April MAOSCO Ltd

4 Remotely loading/updating firmware This presents a number of challenges:- Ensuring the right firmware gets loaded to the intended meter(s), and only the intended meter(s). Ensuring that the firmware arrives unaltered. Ensuring that only authorised firmware is loaded. Keeping the firmware s associated data confidential during transit. With MULTOS, all load and delete actions require a valid load or delete certificate issued from the KMA. These certificates prove the authenticity of an application, its integrity and the right to be loaded / deleted on the target chip. Load certificates contain: The firmware identifier: each certificate is specific to a single firmware identifier and this is checked against the identifier of the firmware package. The owner identifier: this must match that loaded into the chip during enablement. This gives permission for the firmware to be loaded. A hash of the code segment of the firmware: to allow the chip to check the integrity and identity of the code specifically. A list of valid products: it is possible to ensure that firmware can only be loaded to particular (meter) products (as defined in the chip s enablement data). A signature of the whole firmware package, using a firmware signing key: The signing public key is also contained in the load certificate, allowing the chip to check the firmware signature when loading, guaranteeing authenticity and integrity. The serial number of the chip the certificate is for (optional): usually certificates are issued for a whole class of chips belonging to an owner, but it is possible to issue, and therefore control loading permission, at a per-chip level. Confidentiality of the data contained in the firmware load package is achieved by encrypting the data with each chip s unique public key. In that way, only the target chip can successfully decrypt the confidential data, as only it has the corresponding private key. If firmware for an external chip needs to be updated, it is still possible to use the MULTOS chip to provide the cryptographic validation of that external firmware. Because you can securely load the MULTOS chip s firmware, you are able to trust it fully to validate the external firmware. Using MULTOS hugely simplifies the process for downloading firmware images ref [GBCS 11.3] and eliminates any concerns around secure handling of firmware updates in transport as they are cryptographically protected from source. There is no need to define a totally new process or build a completely new infrastructure to support it. Remotely loading and updating keys Any secure protocol running within the firmware loaded into the MULTOS chip will use cryptographic keys. MULTOS provides the perfect option for populating the original keys needed. This is because, as detailed above in the section on remotely loading firmware, the firmware package can contain data, and that data can include keys and be encrypted using the individual public keys of the target chips. To issue a new set of firmware keys to an active meter, there are two options: use the secure protocol of the firmware itself or load a new firmware package containing new keys. Having used MULTOS to safely deliver firmware and data (including certificates and keys) to a meter, with respect to [GBCS] there is the opportunity to redefine, and massively simplify, the whole communication protocol basing it around symmetric keys managed by the suppliers (or their subcontractors) instead. Technical Overview: Version 1, 8 th April MAOSCO Ltd

5 Example Scenario This is one possible scenario in which MULTOS could be used to secure Smart Meters. The exact function of the MULTOS chip in the overall architecture of the meter is not specified but is assumed to at least include all the functionality related to secure communications, secure firmware updates and storage of critical data items. Meter Manufacturers Serial Number List Data File The meter manufacturer requests enablement data* from the KMA for a batch of meters. This is done on-line. The meter manufacturer loads the enablement data to the MULTOS chips in the meters. * Using the owner ID of the Meter Asset Provider who is buying the meters. Along with the meters, they deliver the MULTOS public key certificate for each meter and the firmware for that meter model. Meter Asset Provider (MAP) These companies actually own the meters installed in homes and businesses and the owner identifier in the MULTOS chip is set to them. It is their role to control the issuing of MULTOS load and delete certificates to Energy Suppliers. They do this by using the on-line interface to the KMA. Energy Suppliers Each supplier has an asymmetric key used for signing firmware. On receipt of new firmware from a meter manufacturer, the supplier requests a load certificate for that firmware from each MAP (which contains the public part of the Energy Supplier s signing key). The firmware identifier is unique to the supplier and model of meter. For each meter they are supplying, they need to record The meter owner, serial number and model (all of which are MULTOS identifiers) The MULTOS public key certificate (so they can encrypt firmware to send to that meter) The firmware version currently deployed If taking over supply from another supplier, the new supplier obtains the following The meter owner, serial number and model details (from the old supplier) The MULTOS public key certificate for the meter (from the old supplier) A MULTOS delete certificate for that meter s current firmware (from the MAP) A MULTOS load certificate (from the MAP) for the firmware for that meter model, if they don t already have one. The supplier then personalises the firmware for that make and model of meter with the data needed. For example: Customer Reference number Keys specific to that meter and customer as used by the secure protocol Remote Party security credentials Credit limits / Prepaid unit cost applicable to that customer Technical Overview: Version 1, 8 th April MAOSCO Ltd

6 The resulting firmware package is encrypted by the MULTOS public key for the meter and signed using the private part of the supplier s signing key. This personalisation process should make use of a Hardware Security Module (HSM). The supplier connects to the meter (using whatever communication channel is in place) and Submits the delete certificate to erase any old firmware o either from an old supplier or because the firmware is being upgraded Submits the new personalised firmware and load certificate. If the meter is not genuine, or not the intended meter, the delete and load processes will fail (as described earlier). Any of the above processes could be outsourced by the supplier to a secure, competent third party (including the KMA itself). There are many to choose from who do this all the time, many of whom are MULTOS Consortium members. More about the KMA As well as providing the keys needed for the MULTOS scheme, the KMA has the capability to Securely host third-party systems in its high security vault Provide data preparation and key management services to energy companies Provide firmware management services to energy companies Technical Overview: Version 1, 8 th April MAOSCO Ltd