S-EG-05—Specifications for the approval of software controlled electricity and gas metering devices

GEN-40—Application and implementation of Measurement Canada's specifications for the approval of both software controlled electricity and gas meters and event loggers

Category: Electricity and Gas
Specification: S-EG-05
Issue date: 2011-11-07
Effective date: 2011-11-07

1.0 Purpose
2.0 Scope
3.0 Authority
4.0 References
5.0 Terminology
6.0 Policy
7.0 Modification of legally relevant and legally non-relevant software or parameters using a traced software update
8.0 Modification of legally relevant and legally non-relevant software or parameters without using a traced software update
- 8.1 Non-legally relevant software updates
- 8.2 Non-legally relevant parameter modifications
9.0 Design requirements
10.0 Technical requirements
- 10.1 Measuring systems
11.0 Administrative requirements
- 11.1 General
- 11.2 Type approval documentation
Annex A—Traced update approval process flow - new device type
Annex B—Traced update process flow - new software version approval
Annex C—Signature generation process
Annex D—Signature verification process
Annex E—Certificate generation process
Annex F—Certificate verification process

1.0 Purpose

The purpose of this specification is to establish the meter design, construction, performance and sealing / security requirements for the approval of software controlled electricity and gas meters. This specification also establishes requirements for the approval of metering devices which are intended to accept updates to legally relevant or legally non-relevant software and parameters, without necessitating removal and/or reverification of the subject devices.

2.0 Scope

This specification applies to software controlled electricity and gas meters and electronic ancillary devices approved by Measurement Canada pursuant to the requirements of the Act and Regulations. This document addresses security, software updates, configurable parameters, and other related concerns associated with software within an approved device.

3.0 Authority

This specification is issued under the authority of section 12 of the Electricity and Gas Inspection Regulations (EGIR).

4.0 References

4.1 Electricity and Gas Inspection Act (R.S. 1985, c. E-4), s. 28.

4.2 Electricity and Gas Regulations (SOR/86-131), s. 12

4.3 Specifications Relating to Event Loggers for Electricity and Gas Metering Devices

4.4 Security Requirements for Cryptographic Modules, Federal Information Processing Standards, Publication 140-2.

5.0 Terminology

Attestation

A binding document which solemnly declares in writing that a particular requirement of this document has been complied with and that this conclusion is an accurate representation of the facts as attested to by the signatory.

Authentication

Checking of the declared or alleged identity of a user, process, or device (e.g. checking that downloaded software is legitimately linked to the applicant or device manufacturer identified in the notice of approval).

Authenticity

Result of the process of authentication (passed or failed).

Calibration parameter

Any adjustable parameter that can affect the measurement accuracy of a device.

Certificate authority

A trusted organization that issues digital certificates used to create digital public-private key pairs.

Configurable device

A device which is designed such that the information received from its measurement inputs can be selected and/or processed in different ways to suit different measurement applications. A configurable device includes any device that has been approved to permit legally relevant parameters to be deleted, appended to, modified, or substituted in whole or in part directly by the authorized operator or by any type of communications link from another device, such as a geographically local or remote console or computer, whether or not the secondary apparatus is part of the network connecting the devices.

Configurable parameter

Any adjustable or selectable parameter within a configurable device that can have an affect on the accuracy of a device or can significantly increase the potential for fraudulent use of the device and, based on its nature, may need to be updated on an ongoing basis or only during device installation or upon replacement of a component.

Configuration

To make adjustments to legally relevant parameters.

Cryptographic

Encryption of data by the sender (storing or transmitting program) and decryption by the receiver (reading program) with the purpose of concealing information from unauthorized access. Electronic signing of data with the purpose of enabling the receiver or user of the data to verify the origin of the data (i.e. to prove their authenticity).

Note: For electronic signing a public key system is used in general, i.e. the algorithm needs a pair of keys where only one has to be kept secret; the other may be public. The sender (the sending or storing program) generates a hash code of the data and encrypts it with their secret key. The result is the signature. The receiver (the receiving or reading program) decrypts the signature with the public key of the sender and compares the result with the actual hash code of the data. In case of equality, the data are authenticated. The receiver may require a cryptographic certificate of the sender to be sure of the authenticity of the public key.

Cryptographic certificate

Data set containing the public key belonging to a measuring instrument plus a unique identification of the subject. The data set is signed by a trustworthy institution with a digital signature. The assignment of a public key to a subject can be verified by using the public key of the trustworthy institution and decrypting the signature of the certificate.

Device

Includes a Measurement Canada approved meter, or a measurement system incorporating an approved meter(s).

Device specific parameter

Legally relevant parameter with a value that depends on the individual instrument. Device specific parameters comprise calibration parameters, metrological parameters and configuration parameters.

Event logger

A secure form of audit trail containing a series of records where each record contains the event number corresponding to an event or change to a legally relevant parameter.

Fixed legally relevant software part

Part of the legally relevant software that is and remains identical in the executable code to that of the

approved type.

Hardware security module

A secure device that provides cryptographic capabilities, typically by providing private keys used in public-key cryptography.

Hash code

A code calculated based on the contents of a subject. Hash codes can be used to demonstrate that the contents of a subject have not been modified.

Hash function

Mathematical function which maps values from a large domain into a smaller range through the generation of a hash code. A good hash function is such that the results of applying the function to a large set of values in the domain, will be evenly distributed (and apparently at random) over the range.

Integrity check (programs, data, or parameters)

Assurance that the programs, data, or parameters have not been subjected to any unauthorized or unintended changes while in use, transfer, storage, repair or maintenance.

Interface

Shared boundary between two functional units defined by various characteristics pertaining to functions, physical connections, signal interchanges, and other characteristics of the units (as applicable).

Legally relevant

Software, hardware, data or a part thereof which interferes with properties regulated by legal metrology.

Legally relevant parameter

Parameter of a measuring instrument, electronic device or a sub-assembly subject to legal control. Legally relevant parameters typically form part of the legally relevant functions performed by a device. The following types of legally relevant parameters can be distinguished: type-specific parameters and device-specific parameters. For the purposes of this specification, legally relevant parameters are those parameters which are, either individually or as part of a function, subject to verification under the Electricity and Gas Inspection Act.

Legally relevant software part

Part of a software module of a measuring instrument electronic device or sub-assembly that is legally relevant.

Metrological parameter

Any constant, factor or algorithm used by a device to produce results for trade measurement purposes.

Private key

A secret key used in asymmetric encryption. It is mathematically equivalent to a public key but is kept secret. A private key is one half of a key pair.

Public key

A publically distributed key used in asymmetric encryption. It is mathematically equivalent to a private key, but is widely distributed. Public keys are frequently certified by a Certificate authority so that users of the key can verify its authenticity.

Signature (digital)

The result of encryption (by private key) of a hash code generated by the sender hash function. The receiver may require a cryptographic certificate of the sender to be confident of the authenticity of the public key.

Software

Generic term comprising of program code, data and parameters. Software also includes what is often referred to as firmware.

Software interface

Consists of program code and a dedicated domain. It receives, filters or transmits data between software modules, (not necessarily legally relevant).

Software module

Logic entities such as programs, subroutines, libraries and objects including data domains that may be in a relationship with other entities. The software of measuring instruments, electronic devices or sub-assemblies consists of one or more software modules.

Software separation

Physical or logical separation of software into software modules or parts which communicate via a software interface. Software that has been separated has unique identifiers allowing them to be administered and controlled individually.

Sub-assembly

Part of an electronic device employing electronic components and having a recognizable function of its own.

Traced update

Traced Update is the procedure of changing legally relevant or legally non-relevant software in a verified device after which the subsequent verification by a responsible party is not necessary.

Type specific parameter

Legally relevant parameter with a value that depends on the type of device. Type-specific parameters have identical values for all specimens of an approved type and are fixed at type approval of the device.

User interface

Interface that enables information to be interchanged between a human and the measuring instrument or its hardware or software components. All inputs from the user interface are redirected to a program that filters incoming commands. It only allows and lets past the documented ones and discards all others. This program or software module is part of the legally relevant software.

Verification triggering event

Any event deemed by Measurement Canada to require a verification of the device before it is permitted to be used or continued for use in trade. The recording of a verification triggering event is analogous to breaking a physical seal and shall have the same ramifications and consequences as the breaking of a physical seal.

6.0 Policy

6.1 General

6.1.1 Updating or reloading the software on a verified device is considered to be a verification triggering event. This action is equivalent to the breaking of the device's seal, unless the device has been designed and constructed in accordance with the requirements of this specification.

6.1.2 A device which meets the device approval design, construction, and performance requirements associated with a traced update (sec. 7.0) may be approved as being capable of having its legally relevant or legally non-relevant software updated without necessitating device removal and/or device reverification.

6.1.3 A device which does not meet the device approval design, construction, and performance requirements of section 7.0, but meets the design, construction, and performance requirements of section 8.1, may be approved as being capable of having its legally non-relevant software updated without necessitating device removal and/or device reverification.

6.1.4 Where software updates are permitted in accordance with the requirements of this specification they can be performed locally (directly on the device) or remotely via a network. In either case, the update process shall be automatic such that human intervention is not required beyond initiation of the process.

6.1.5 Upon completion of a software update, the software protection environment shall be at the same level as required by type approval or this document.

6.2 Legally relevant software

6.2.1 All software modules (programs, subroutines, objects, etc.) that perform legally relevant functions or that contain legally relevant data domains form the legally relevant software part of a device. More specifically, this includes all software modules that:

contribute to or have an impact on the calculation of a legal unit of measure;
contribute to functions such as: displaying, securing, and storing legally relevant data;
identify the software, or
perform the software download.

6.2.2 All fixed variables or parameters that have an impact on the establishment of a legal unit of measurement form part of the legally relevant software.

6.3 Software separation

6.3.1 Legally relevant software or software parts may be separated from legally non-relevant software or software parts. Software separation requires separated parts to have a unique identifier allowing them to be administered and controlled. If separation of software or software parts is not possible or needed, the software is legally relevant as a whole.

6.3.2 All interactions, communications and data flow through a legally relevant software interface shall be fully documented as per section 11.2 (a) (ii).

6.4 Modification of legally relevant parameters

6.4.1 Access to a legally relevant parameter shall be protected by a physical seal or secured by an event logger.

6.4.2 All modifications to legally relevant device specific parameters (which form part of an approved function) are verification triggering events, unless the modification is a reconfiguration which results in the switching of one previously verified legally relevant parameter for another previously verified legally relevant parameter.

6.4.3 Where a configurable device includes a legally relevant function that has been specifically approved as a function intended to be utilized with configurable parameters falling within an approved range, all discrete parameters which lie within the approved range are legally relevant and shall be considered as having been verified as part of a device's verification process.

6.4.4 The Notice of Approval for a configurable device shall specify:

the provisions authorized for the effective sealing and securing of the device; and
the device specific legally relevant parameters that are capable of being reconfigured without requiring device reverification.

6.4.5 The programmed legally relevant parameters of a device shall reside in the device.

6.4.6 Modifications to legally relevant parameters that are type specific are not permissible.

6.4.7 Modifications to calibration parameters, parameters with a hardware dependancy, meter form factors (service configurations) and any parameter protected by a physical seal are verification triggering events.

6.4.8 Where parameter modifications or reconfigurations are permitted in accordance with the requirements of this specification, they can be performed locally (directly on the device) or remotely via a network.

7.0 Modification of legally relevant and legally non-relevant software or parameters using a traced software update

7.1 General

7.1.1 A software update shall not affect device performance and the measurement accuracy of the device shall be equivalent to that exhibited by the device prior to the occurrence of the software update.

7.1.2 Where a device has been approved with the capability of performing modifications to its legally relevant software through the use of a traced software update (in accordance with the requirements of this section), the software update shall not be classified as a verification triggering event.

7.1.3 A device that is approved as being capable of performing traced updates, shall be constructed with fixed legally relevant software that cannot be updated during a traced update (i.e. the fixed legally relevant software shall not form part of the downloaded software). The fixed legally relevant software shall contain an authenticity check function and integrity check function that is applicable to the software attempting to be loaded on the device (as specified in sections 7.2 and 7.3).

7.1.4 The notice of approval issued by Measurement Canada for a device approved with traced update capability shall include the software version number(s) and the hash code(s) of the legally relevant software part(s) as well as the fixed legally relevant software part.

7.1.5 Where a device is approved with trace software update capability, traced software updates may be utilized to reinstall or update approved legally relevant software or to modify configurable legally relevant parameters (in accordance with the requirements of section 6.4).

7.1.6 Traced software updates may be utilized to update both legally relevant and legally non-relevant software, however, traced software updates must be utilized to update legally non-relevant software where the requirements of section 8.1 have not been met.

7.2 Authenticity check

7.2.1 A device shall be designed and constructed with technical means to guarantee the authenticity of the software that is attempting to be loaded on the device. Before a software update occurs, the device shall perform an authenticity check to ensure that the software is legitimately linked to the applicant or device manufacturer identified in the notice of approval.

7.2.2 An authenticity check shall be performed by cryptographic means utilizing a public key and signature system (ref. Annex A or B). The public key shall form part of the legally relevant software or fixed legally relevant software.

7.2.3 The Hardware Security Module (HSM) used to protect the private keys and issue signatures or certificates shall meet or exceed the applicable security requirements of FIPS 140-2 (ref. sec. 4.4) or an appropriately recognized security standard of equivalence.

7.2.4 Where the software attempting to be loaded on a device fails to meet the authenticity check, the device shall be designed to abort the software loading process and ensure that the previous approved version of the software is maintained on the device. Alternatively, the device may switch to an inoperable mode where measuring functions are inhibited. However, the download process, in accordance with the traced update requirements, may be re-initiated.

7.3 Integrity check

7.3.1 A device shall be designed and constructed with technical means to guarantee the integrity of the loaded software.

7.3.2 An integrity check shall be performed by the device through the use of a cryptographic hash function whose purpose is to verify the generated hash value for the software to be installed against the hash value contained in the certificate or signature received (ref. Annex D or F).

7.3.3 Where the software attempting to be loaded on a device fails to meet the integrity check, the device shall be designed to abort the software loading process and ensure that the previous approved version of the software is maintained on the device. Alternatively, the device may switch to an inoperable mode where measuring functions are inhibited. However, the download process, in accordance with the traced update requirements, may be re-initiated.

7.3.4 A device approved for performing software updates shall be capable of detecting if the software download fails or is not completed successfully.

7.3.5 In the case of an unsuccessful software update or install or if the software update or loading is interrupted, the original status of the device shall be unaffected or the device shall display an error code and measurement functions shall cease.

8.0 Modification of legally non-relevant software or parameters without a traced software update

8.1 Non-legally relevant software updates

8.1.1 A device may be approved with the capability of updating its legally non-relevant software without a traced update, where:

the device has been designed and constructed such that the legally non-relevant software is distinctly separated from the legally relevant software;
the entire legally relevant part of the device cannot be modified without breaking a seal or utilizing a traced update; and,
the device's notice of approval states that the legally non-relevant software may be modified.

8.2 Non-legally relevant parameter modifications

8.2.1 Modifications to legally non-relevant parameters or unapproved parameters are not verification triggering events.

9.0 Design requirements

9.1 General

9.1.1 Devices shall be designed such that legally relevant software is capable of being secured against undetectable unauthorized modifications, whether by updating, or by swapping the memory device. Software protection comprises appropriate sealing by mechanical, electronic and/or cryptographic means making unauthorized intervention impossible or evident.

9.1.2 A device shall be designed such that the software update process shall not be capable of affecting any legally relevant measurement data that may be stored on the device.

9.2 Software interface

9.2.1 If a legally relevant software part of a device communicates with other software parts, a software interface shall be implemented. The software interface shall not be capable of being circumvented and all communication shall be performed exclusively via this interface.

9.2.2 Where legally relevant software has been separated from legally non-relevant software, the legally relevant software measurement operation (performed by the legally relevant software part) shall not be affected by other tasks. Technical means for preventing a legally non-relevant program from affecting the operation of legally relevant functions shall be provided.

9.2.3 Devices shall be designed such that all interactions and communications through a software interface do not inadmissibly influence the legally relevant software.

9.2.4 Devices shall be designed such that each command sent via the software interface to the initiated function or data change shall be unambiguously assigned.

9.2.5 The software interface shall prohibit all undocumented interactions, communications and data flow.

9.3 Software identification

9.3.1 Legally relevant software or legally relevant software parts of a device, shall be clearly identified with a software version. This identification shall be inextricably linked to the software itself via a hash code.

9.3.2 The legally relevant software version(s) shall be capable of being displayed and the hash code(s) shall be capable of being generated and displayed during operation or at start-up (where the device is capable of being turned on and off) or printed (where a printer forms part of the measuring system). Alternatively, the generated hash code(s) may be exported on site as an electronic file that can be viewed and printed using a laptop computer that is equipped with a relevant Microsoft Windows based operating system.

9.3.3 Where a device has been approved as being capable of performing traced updates, the fixed legally relevant software shall also have its own hash code.

9.3.4 Where legally relevant software is separated from legally non-relevant software, the legally non-relevant software shall be clearly identified with a software version capable of being displayed during operation or start up (where a device is capable of being turned on and off) or printed (where a printer forms part of the measuring system). Alternatively, the software version may be exported on site as an electronic file that can be viewed and printed using a laptop computer that is equipped with a relevant Microsoft Windows based operating system.

9.4 Software updating / loading and installation

During the software download and/or installation process, the device shall be capable of continuing to function and measure as intended or the device's measurement functions shall be inhibited.

9.5 Event logger

9.5.1 Devices that are approved as configurable devices or devices approved to perform traced updates shall be equipped with an event logger which complies with the requirements of Measurement Canada's Specifications Relating to Event Loggers for Electricity and Gas Metering Devices.

9.5.2 The event logger and event logger records (event log) are part of the legally relevant software and shall be protected as such.

10.0 Technical requirements

10.1 Measuring systems

10.1.1 Where a device has interfaces for communicating with other electronic devices, with the user or with other software parts, the legally relevant parts of a device (whether software or hardware) shall not be inadmissibly influenced by other parts of the measuring system.

10.1.2 Sub-assemblies or electronic devices of a measuring system that perform legally relevant functions shall be identified, clearly defined, and documented.

10.1.3 The manufacturer shall ensure that the relevant functions and data of sub-assemblies and electronic devices cannot be inadmissibly influenced by commands received via the interface.

11.0 Administrative requirements

11.1 General

11.1.1 Manufacturers shall produce devices and legally relevant software that conforms to the approved type and the documentation that was submitted in support of approval obtainment.

11.1.2 Manufacturers/approval applicants shall declare and document all software program functions, commands (including commands that can be entered via a user interface) relevant data structures, and software interfaces of the legally relevant software part(s). No hidden (undocumented) functions shall exist.

11.1.3 Compliance with the requirements of this specification shall be established on the basis of a combination of both functionality testing and written attestations of compliance.

11.1.4 Attestations of compliance shall originate from an authorised signing authority who has been appropriately designated by the device manufacturing corporation to represent it for these purposes as part of the pattern approval process.

11.1.5 All device manufacturer attestations shall serve as records of compliance and shall be maintained as permanent records in a device's pattern approval file.

11.2 Type approval documentation

Where an approval applicant wishes to have their device approved as being capable of receiving approved updates to their software without triggering the need for device reverification, the following documentation shall be submitted in support of the approval request:

A description of the legally relevant software and how the requirements are met:
1. a list of software modules that belong to the legally relevant part, including a declaration that all legally relevant functions are included in the description;
2. a description of the software interfaces of the legally relevant software part and of the commands and data flows via this interface including a statement of completeness;
3. description of the software identification (version numbers), and
4. a list of parameters to be protected and a description of protection means;
A description of suitable configuration and minimal required resources, where applicable.
A description of security means of the operating system, if applicable.
A description of the (software) sealing method(s).
A description of how authenticity of the software identification is guaranteed.
A description of how the integrity of the software is guaranteed.
A description of how its is assured that the downloaded software is approved for the type of device to which is has been downloaded.
An overview of the system hardware (e.g. topology block diagram). Where a hardware component is deemed legally relevant or where it performs legally relevant functions, this should also be identified.
A description of the validity of the algorithms (e.g. filtering of A/D conversion results, rounding algorithms, etc.).
A description of the user interface, menus and dialogues.
Where a device has interfaces for communicating with other electronic devices, identification of the interface(s).
A description of how the device ensures that the relevant functions and data of subassemblies or electronic devices in a measuring system cannot be inadmissibly influenced by commands received via the interface(s).
The software identification and instructions for obtaining it from an instrument in use.
A list of commands of each hardware interface of the measuring instrument / electronic device / sub- assembly including a statement of completeness.
A description of data sets stored or transmitted.
Assembly drawings and schematics for all Printed Wiring Boards (PWB) under the device cover.
Component silk screen or graphic file equivalent for all PWBs with the microprocessors and memory devices identified (highlighted or circled). Identify each microprocessor communication interface by drawing a line between the microprocessors involved.
List each software part in the system, and match each to a microprocessor in the system. Identify the physical memory where the configuration data, generated data, and other data sets are stored for each software.
Provide functional description for microprocessors and interfaces used by these devices and show where data is stored.
Describe the system using a block diagram. The diagram should show where the functional blocks of metrology are located with respect to the microprocessors or integrated circuits which include microprocessors within the system. Also, show the location of the data sets for each of the functional blocks. If physical separation is claimed, identify the line of separation, and describe the data flow and commands of the interface(s) across the separator.
If physical separation is claimed and it can be demonstrated by dismantling of the device and testing individual subsystems, provide the procedure that would allow the examiner to conduct this test.