success d3.9 v1.0 next generation smart meter, v 3 (final) · success d3.9 v1.0 page 1 (80) success...

SUCCESS D3.9 v1.0

(80)

SUCCESS D3.9 v1.0 Next Generation Smart Meter, V 3 (final) The research leading to these results has received funding from the European Union’s Horizon 2020 Research and Innovation Programme, under Grant Agreement no 700416. Project Name SUCCESS Contractual Delivery Date: 31.10.2018 Actual Delivery Date: 31.10.2018 Contributors: REC, TW, ENG, SYN, P3E, RWTH, EDD, ISMB Work package: WP3 – Securing Smart Devices Security: PU Nature: R Version: 1.0 Total number of pages: 80 Abstract: This deliverable presents the description of NORM concept, architecture, components and their software details as a third and final version. The report outlines also the necessary processes and the associated methodology towards integrating and testing, at functional level, components between WP3 and WP4 within the SUCCESS Security Solution. Keyword list: NORM, Smart meter, PMU, Physically Unclonable function, USM, Integration, Validation, Testing Disclaimer: All information provided reflects the status of the SUCCESS project at the time of writing and may be subject to change.

SUCCESS D3.9 v1.0

(80)

Executive Summary The purpose of this deliverable is to present the concepts of Next Generation Open Real Time Smart Meter (NORM) and the updated stage of its developments, including the communication possibilities with the Critical Infrastructure Security Operations Centre (CI-SOC). The deliverable presents hardware and software details of the NORM Real-time Meter. The hardware platform chosen has all the necessary computational resources and can be used directly as a next generation smart meter incorporating tamper detection functionality and near real time measurement intervals. The NORM experiments PUFs (Physically Unclonable Function) based cryptographic approach and will be further tested in laboratory and in the trials of WP 5. Privacy by design principle is also implemented in the NORM design and implementation, giving a solution for the meter which preserves privacy of end customer but also is able through the Security Agent to send non-private data to an upper level where such data can be tested for inconsistencies and patterns which may raise cyber-security flags. The NORM has important advantages compared with market existing smart meters and is a recommended solution for next generation of smart meters. Advantages of NORM are that: a) It has a multi-user interface, to communicate with all actors in parallel, thus allowing multi-actor interaction directly with the data source, without needing any intermediary system; b) It implements a special communication link with an important additional actor which is the Critical Infrastructure Security Operations Centre (CI-SOC), mediated by a Security Agent (SecA) running in Smart Meter Gateway (SMG) and extracting the relevant data for further cyber-security assessment, allowing the implementation of new cyber-attack counter-measures, in a way which preserves privacy (only non-private data is collected) and allows detection of data inconsistency at local and CI-SOC level; c) The multi-user communication is implemented by using secure VPN technologies and by going beyond today level of security by implementing the physically unclonable function (PUF) technology, which is a much higher level of security compared with any other security technology implemented in current Smart meters. d) NORM is aggregating through its Smart Meter Gateway (SMG) the data from two different local measuring equipment: a metrology meter and a low-cost Phasor Measurement Unit (PMU). With this data integration, NORM enables both smart metering and hard real-time smart grid functionalities. This is an important advancement from existing smart meters, as PMU data is now available in any metering point, enabling higher functionality in active distribution networks, specific to high renewables penetration. e) NORM is implementing in its SMG section a new PTP synchronisation of local clock, allowing PMU functionality in wired networks without the need of costly and difficult to place GPS receiver. f) NORM-SMG is converting classic PMU protocol (based on C37 standard) to protocols specific to smart grid SCADA (IEC61850) and to MQTT based publish-subscribe data-streams, for simple new services implementation, thus allowing a democratisation of the PMU data g) The new low-cost PMU integrated in any NORM allows wide-spread rollout of PMU technology, allowing that such information can be obtained from any point of the network. NORM implements a Smart Meter Gateway (SMG) functionality which can be adapted and configured to be compatible with German Smart Meter Gateway (G-SMG), while providing also a superset of its functionality.

SUCCESS D3.9 v1.0

(80)

Authors Partner Name e-mail REC Mihai Sanduleac [email protected] Mihai Paun [email protected] Mihai Mladin [email protected] ERICSSON Zain Mehdi [email protected] ENGINEERING (ENG) Antonello Corsi [email protected] Giampaolo Fiorentino [email protected] SYNELIXIS (SYN) Artemis Voulkidis [email protected] Kostas Pramataris [email protected] Theodore Zahariadis [email protected] Rheinisch-Westfaelische Technische Hochschule Aachen ( RWTH) Antonello Monti [email protected] Padraic McKeever [email protected] Gianluca Lipari [email protected] Teamware (TW) Gianluca Zanetto [email protected] ISMB Mikhail Simonov [email protected]

SUCCESS D3.9 v1.0

(80)

Table of Contents 1. Introduction ................................................................................................. 7 Scope of this Deliverable ............................................................................................... 7 Relationship to the work of the project ........................................................................... 7 How to Read This Document ......................................................................................... 7 2. NORM architecture, concepts and specifications .................................... 8 The concept of unbundling the metering functions ........................................................ 8 NORM unbundling concept ............................................................................................ 9 Smart Meter Gateway .......................................................................................... 10 2.2.1.1 Main functionalities .................................................................................... 10 2.2.1.2 Database centric architecture .................................................................... 10 2.2.1.3 Data privacy profiles .................................................................................. 11 Smart metrology Meter ......................................................................................... 13 Low cost Phasor Measurement Unit (PMU) ......................................................... 13 NORM new functionalities compared with today Smart Meters .................................. 15 NORM new functionalities and novelties.............................................................. 15 NORM’s SMG compared with the German Smart Meter Gateway ...................... 16 Cyber-security supervision with data delivered by NORM .......................................... 23 Concept ................................................................................................................ 23 Rationale for selected data for CI-SOC transmission .......................................... 24 NORM drop of components strategy for development ................................................ 25 3. NORM main modules ................................................................................ 26 Smart Meter Gateway (SMG) ...................................................................................... 26 The core Computer platform ................................................................................ 26 The PUF board description .................................................................................. 26 3.1.2.1 PicoPUF-ID ................................................................................................ 27 3.1.2.2 Butterfly PUF .............................................................................................. 27 3.1.2.3 Arbiter PUF ................................................................................................ 27 3.1.2.4 XOR-Arbiter PUF ....................................................................................... 28 3.1.2.5 SUM Ring Oscillator PUF .......................................................................... 28 Smart Metrology Meter (SMM) ..................................................................................... 28 Introduction ........................................................................................................... 28 Wally A meter ....................................................................................................... 28 A1800 meter ......................................................................................................... 29 Low cost PMU .............................................................................................................. 32

SUCCESS D3.9 v1.0

(80)

4. NORM Smart Meter Gateway software .................................................... 34 Open source SMXcore ................................................................................................. 34 4.1.1.1 Real-time Database organisation ............................................................... 34 4.1.1.2 RBAC concept............................................................................................ 34 4.1.1.3 MQTT communication ................................................................................ 34 4.1.1.4 Meter communication ................................................................................. 35 PMU protocol converter ............................................................................................... 36 PTP functionality .......................................................................................................... 37 PUF security modules .................................................................................................. 39 Bootstrapping services ......................................................................................... 39 Authentication services ........................................................................................ 40 Encryption services .............................................................................................. 40 Requirements and API documentation ................................................................ 41 4.4.4.1 Overview of the API documentation .......................................................... 44 4.4.4.2 Get the ID of the PUF ................................................................................ 45 4.4.4.3 Get the Utilities supported by the LPA ....................................................... 45 4.4.4.4 Update the active challenge for a given Utility ........................................... 46 4.4.4.5 Bootstrap the PUF LPA against a Utility .................................................... 47 4.4.4.6 Encode a piece of data using the PUF ...................................................... 47 4.4.4.7 Verify the PUF ............................................................................................ 48 4.4.4.8 Firewall ....................................................................................................... 49 4.4.4.9 Logs ........................................................................................................... 50 4.4.4.10 Reboot the NORM ..................................................................................... 51 NORM Security Agent .................................................................................................. 51 Introduction ........................................................................................................... 51 Security Agent Architecture .................................................................................. 52 NORM Security Administration Agent .......................................................................... 54 5. Test plan for individual components ....................................................... 55 BASIC SMG software .................................................................................................. 55 Security Agent .............................................................................................................. 56 PUF functionality .......................................................................................................... 56 PTP synchronisation .................................................................................................... 56 Low cost PMU .............................................................................................................. 58 EMC immunity test for PUF ......................................................................................... 60 6. Potential future work ................................................................................ 64

SUCCESS D3.9 v1.0

(80)

7. References ................................................................................................. 65 8. List of Abbreviations ................................................................................ 69 9. List of Figures ........................................................................................... 70 10. List of Tables ............................................................................................. 72 Annex A. List of data subject of being reported by NORM-SecA to CI-SOC73 A.1 Real-time data validation (cases named RTxx) ........................................................... 73 A.2 Communication on Public IP Networks (PIPN) such as Internet (cases CPIPxx) ....... 75 A.3 3. SMG Internal Database access ............................................................................... 76 A.4 SMG System health (SyHxx) ....................................................................................... 77 A.5 SMG Commands validation (CMDxx) .......................................................................... 77 A.6 Anti-tampering events (ATEVxx).................................................................................. 78 A.7 Power System Metada (PMdxx) .................................................................................. 79 A.8 Other category (YYYxx) ............................................................................................... 79

SUCCESS D3.9 v1.0

(80)

1. Introduction Scope of this Deliverable This deliverable describes the main architecture of NORM, principles of design and the description of each module, with final functionalities developed during the project. In this deliverable, the following main objectives are pursued: To provide the architecture, concepts and specifications of the Next Generation Open Real Time Smart Meter (NORM) To describe the main blocks (modules) and to detail the software components of NORM To provide the tests carried for the individual components, including the integration of NORM in the CI-SOC To highlight potential future work. Relationship to the work of the project NORM is developed in SUCCESS project as the Next Generation Open Real Time Smart Meter based on the unbundled meter concept already developed in Nobel Grid, by adding to the SMM and SMX parts of the Nobel Grid project additional hardware and software modules. NORM is an open platform where new functionalities can be added to standard meters within the Smart Meter Gateway (SMG), an enhanced version of SMX. NORM could be used as a new stand-alone meter (when equipped with the proper metrology and hard-real time features) or it could be used to expand legacy meters with more functionalities and securities and with added hard real time features such as PMU functionality. In this sense, SUCCESS offers an open solution compatible with the past but open to future developments. For the prototype implementation, a low-cost embedded computer has been used, having as specific target the Raspberry PI 3 (RPI3) platform, which will be used to run Linux operating system with application software to integrate a market existing meter and a low-cost PMU, thus the RPI3 platform acting as a Smart Meter Gateway (SMG). With these characteristics, NORM is an essential part of the project, bringing a comprehensive solution for the smart meter mounted at the point of common coupling (PCC) of the prosumer, able to cope with smart grid functionalities in an active distribution network, while raising the cyber-security protection and keeping privacy by design. How to Read This Document The document is structured as follows: Section 2 introduces architecture, concepts and general specification. Section 3 focuses on describing each module of NORM: SMG, low cost PMU, smart meter. Section 4 describes the current situation for the software functionalities inside the module. Section 5 provides the testing plan of individual components of NORM and the connection to CI-SOC, providing also meaningful results of the tests. Section 6 is considering potential future work to advance towards a mainstream next-generation meter. The last sections deal with references and abbreviations.

SUCCESS D3.9 v1.0

(80)

2. NORM architecture, concepts and specifications In this section are presented the main concepts and basic specifications of NORM. The concept of unbundling the metering functions Traditional smart meters have usually an embedded architecture for the metrology and for the additional functionalities. For this reason, it is difficult and sometime impossible to have flexibility in terms of local functionalities of the meter, because any new function requires a recompiled version of the firmware inside the meter, which implies automatically a new metrology certification. The current firmware of the meter has to be displayed on the screen of the meter and it is needed to have a metrology approval for each new version. Because it can be unreasonable expensive to change the version of firmware locally, some of the existing meters have the possibility of remote upgrade of the approved new version of the firmware. This implies possible malfunction after the upgrade, but also can bring cyber-security threats. It is already recognized that the metrology part should be separate from other functional blocks, in order to avoid recalibration and loss of trust. However, modern smart meters need also that some processing’s are stored in this trustful zone (e.g. making load-profiles of energies and implementing tariff functionality), and this part is usually implemented in a part which deal with the meter chip as well as with the external communication, plus additional functions available at the moment of certification. This makes difficult in current implementations of smart meters to make an effective separation of metrology and further processing power, thus keep the whole meter functionality rigid. In the new smart grid paradigm, the needed functions can evolve however much quicker than the time for new generation of smart meters can replace the old one. A complete cycle of smart meters replacement is now estimated at 10 years. It means that during the 10 years no functionality or only minimal functions can be transferred in the existing smart meters. It appears a situation the smart meter investment is a blockage factor for the smart grid developments. The unbundling of meter functionalities in two different parts is a systematisation which has been first presented in [1]. Nobel Grid project [19] took this systematisation and is now in process to implement it and to make the first unbundled Smart meter on the market, as a third generation of Smart meters, to be able to be part of new smart meter deployments in the next two years. The systematisation is presented in fig. 1: Figure 1 – Unbundled meter systematisation

SUCCESS D3.9 v1.0

(80)

It can be seen that the metrology measurements as well as the basic functions which have to do with handling important data for billing are placed in the Smart Metrology Meter (SMM), which is a black-box like acting part where billing and other data are secured in such a way that intervention from outside cannot delete the essential information, which is however self-recycled after a period of time when the commercial activity related to this data (especially billing) is not any more relevant for claims and this data is now also stored in the databases of the implied actors. The high-level processing which creates additional content is in the Smart Meter eXtension (SMX) and this part is highly flexible. SMX is also supporting all connections to remote actors, thus need to implement various communication protocols and measure of data security. A Virtual Private Network (VPN) approach for communication with each actor is considered, but additional features and details can be implemented as well. We rely on an open platform so that changes during the lifetime of SMX can easily be implemented. It is a standard Linux distribution running on small platforms such as Raspberry PI 2/3. The Fig. 2 gives details on the connectivity of the unbundled smart meter. Figure 2 - Unbundled meter connected to different networks NORM unbundling concept Based on the smart meter unbundling architecture, NORM goes further and adds an additional module, a low-cost PMU, which will be the second source of data to the SMX, besides the existing Smart Metrology meter data. The extension is more complex and ask for additional functions, such as enhanced cyber-security, thus in this project the enhanced extension becomes a “Smart Meter Gateway”. The project architecture uses this enriched unbundling, and the more complex device has now its own identification given by the name NORM (Next Generation Open Real Time Smart Meter). The unbundled parts are presented in figure 3:

SUCCESS D3.9 v1.0

(80)

Figure 3 – NORM unbundled concept In the figure it can be seen that NORM has now three components, and that the smart metrology meter part is now supplemented by the low-cost PMU (LCPMU). Smart Meter Gateway 2.2.1.1 Main functionalities Smart Meter Gateway (SMG) is the most important subsystem of NORM, as it orchestrates in the same time the local measurement equipment and the communication with all external actors. The most important aspects related to SMG are: It is the equipment concentrating the data from the metrology meter and the low-cost PMU (LCPMU), It uses meter and PMU specific protocols to access this data and to store it in a real-time database accompanied by a persistent storage of values based on daily logs of profiles, A database centric architecture allows that all external actors can interact with data only through a Role Based Access Control (RBAC) mechanism, which always that only data specific to each actor is provided with that actor, It implements the multi-user / multi-protocol simultaneous communication with all external actors, using a high cyber-security concept based on PUF technology, and It implements a local security agent, which is able to collect and transmit to higher level relevant and non-private data which can be used to assess at CI-SOC level inconsistencies which trigger corresponding counter-measures. 2.2.1.2 Database centric architecture Short general description (development in chapter 4). In NORM architecture the Smart Meter Gateway (SMG) acts as meter + PMU data acquisition device and as the only interface with public IP networks such as internet or local network based e.g. on WiFi connection to internet. The architecture of the SMG is derived from SMX developed in Nobel Grid and has a database centric approach, as in figure 4.

SUCCESS D3.9 v1.0

(80)

Figure 4 – Database centric architecture In figure 4 it can be seen that all metering and PMU data is sent in the realtime database, in different datasets and that any connection with different external actors can be done only by accessing the database through MQTT and REST interfaces. This data-centric architecture allows a strong control regarding the access of different actors to the data, by using a Role based Access Control (RBAC) strategy, which allows different data privacy policies to be applied to each actor. This aspect is developed in next chapter. 2.2.1.3 Data privacy profiles Description: Data privacy is an important legal issue, supported also by the new GDPR specifications. Depending on the type of metering point, we can have a different privacy policy:

For metering points serving citizen’s houses or apartments, it applies personal data protection, thus collected data is subject of privacy assessment. This applies also to prosumer’s metering data, where renewable production, storage and consumption are ” behind the meter”, For metering points in the grid, it might be necessary to consider them as being data from critical infrastructure, even if they do not belong now to personal data, and For metering points related to production of energy some data might be critical as well. For this reason, NORM implemented a so called “Privacy profile”, which is parameterized based on the type of metering point. For considering the most demanding private data, a table with the different data types which can be sent at CI-SOC is presented in Annex 1. By using the database centric architecture, any connection of each external actors can be done only by accessing the database through MQTT and REST interfaces, which are incorporating Role based access control (RBAC), The RBAC implementation considers specific privacy profiles (PP) for each actor. For instance, in the figure, the privacy profile PP1 is a specific one for the DSO operation, meaning that only data which are allowed for DSO can be exchanged with it. In addition, the communication with the DSO is made through its specific OpenVPN and the whole SCADA application is considered as being in an untrusted zone, thus being sandboxed in a Docker cluster containing an MQTT broker, the SCADA app with IEC61850 protocol and the OpenVPN client. In this way, external communication can be kept with the DSO actor only in a secure environment. Similar access to data and communication is considered also with any other actors (such as ESCO or supplier). A special session can be obtained when communicating for system administration, by using an OpenVPN client in the trusted zone, which establishes an OpenVPN connection with the remote

SUCCESS D3.9 v1.0

(80)

system administrator, which usually is also the DSO, but another entity which is entitled to make the NORM/SMG maintenance. Privacy profiles PP1, .. PP3 etc. are a combination of rights of data access which respect both: country specific rules (provided by national law, country regulator and by the DSO), named Country Privacy Profile (CPP), and user specific rules, described in User Privacy profile UPP. Country specific rules are describing priorities between DSO and user preferences. For instance, for voltages the DSO may have the right to read the data, without consent of user, but for the active powers of the user consumption the user has the only right to give or not this rich content and privacy sensitive data to any actor (including for DSO). The simplified scheme of PP construction is in the figure 5. Figure 5 – Privacy profiles To be noted that PP structure may vary from country to country, based on the specific laws and country regulator rules. In figure 6 below is presented the wider view of NORM interaction with different users and actors.

Figure 6 – NORM-SMG and actors’ interaction through RBAC system Smart metrology meter and LCPMU integration are developed in chapter 3 and 4. Physical unclonable functions (PUFs) are formally defined as physical functions (often parallelized to one-way functions) embodied on physical structures and are easy to evaluate / validate but hard to predict. As one-way functions, PUFs are generally required to produce a unique output string (called response) when provided with an input string (called challenge). PUFs base their operation on the uniqueness of their exact manufacturing process (exploiting the uniqueness of their physical microstructure), they are practically impossible to duplicate and are, hence, used as security/authentication mechanisms in applications with high security requirements [1]. In the context of SUCCESS, a PUF mechanism is implemented in the greater NORM context, a means to offer authentication and encryption services (see §3.1.2 and §4.4, page 35) whereas access to it through the various NORM components facilitated a “local PUF agent”, namely a simple web service enabling RESTful access to the rest of the NORM components. Physically, PUF has been implemented on an FPGA board, albeit it could be implemented as a dedicated integrated circuit granted that its design principles would be kept intact and a relevant drive to communicate with the NORM computer base was implemented. Details on the FPGA-based implementation of the SUCCESS PUF solutions are presented in §4.4, page 35.

SUCCESS D3.9 v1.0

(80)

More information about NORM specific data security based on PUF technology is described in chapters 3 and 4. Smart metrology Meter The Smart metrology meter (SMM) is the metrological part of NORM. In the SUCCESS project it has been considered a market existing meter, which is chosen as being a meter present in the sites of the demonstrators. SUCCESS project does not concentrate on a new SMM, but on the new architecture of NORM, based on unbundling the different critical components, as already has been presented. The metrology aspect of this part is essential for keeping the NORM as having the status of a Smart meter, because it keeps the legal power of metrology, which allows that the measurements can be used in billing, thus being usable in case of legal disputes. Acting as a legal black-box containing un-modifiable data, SMM can be certified by its own, without affecting the other components of NORM. In the practical demonstration of NORM architecture, the market existing meter is connected to SMG through a serial connection, and this is the only possible interaction path between SMM and SMG, based on standard protocols available for the meter, such as DLMS/COSEM (“Device Language Message specification” and “COmpanion Specification for Energy Metering”, details being available at www.dlms.com). Low cost Phasor Measurement Unit (PMU) Phasor measurement units (PMUs) are new equipment in the distribution network, being at the moment more used in the transmission system, operated by Transmission and System Operator (TSO). The principle of measuring of angles of voltages and currents on phases relies essentially on the fact that there is a very good synchronisation of time between different PMUs. Due to this requirement, toady PMUs are using GPS as main source of time synchronisation, which need in fact GPS receiver mounted in such a place that the sky and its satellites are visible. For the TSO the costs involved in deploying a GPS based PMU are acceptable, even if they are high (usually more than 1000 Euros, for some models 3000 to 5000 Euros). Our project is targeting the large deployment of basic PMU functionality in any smart meter of the low voltage distribution grid, which is proposed with the following approach: only voltages are subject of PMU measurements (voltages phases are the most important for assessing active grid or microgrid functionality) and synchronisation is made through a combination of high-speed IP-network and 5G connectivity. As the SMG is a Linux machine, the default way of making time synchronisation in NTP (Network Time Protocol) synchronisation. This solution allows good synchronisation between different SMG of down to 20 milliseconds between the devices. However, this is unacceptable for phasor measurements, considering that a resolution of one degree (from 360 degrees in a period of 20 milliseconds) means a time resolution of 55 microseconds. For this reason, the project considers a much better synchronisation by investigating the PTP (Precise Time Protocol) use while also being able to synchronize with a GPS module. The PTP module is able to synchronize the CPU time base at much higher accuracy than NTP does. It refers to IEEE 1588 – 2008 standard [8] and even though the accuracy expectations of PTP synchronized clocks is in the order of 100 ns, based on the quality of network connection, realistic synchronisation between 10 and 100 microseconds are expected in the SMG by using cabled Ethernet based networks. The basic principle is similar to NTP protocol, where computers and other devices that have a clock are connected in a network and form a hierarchy of time sources in which time is distributed from top to bottom. The devices on top are normally synchronized to a reference time source (e.g. a timing signal from a GPS receiver). Devices “below” periodically exchange timestamps with their time sources in order to measure the offset of their clocks. The clocks are continuously adjusted to correct for random variations in their rate (due to effects like thermal changes) and to minimize the observed offset.

SUCCESS D3.9 v1.0

(80)

The PTP module in NORM features a single PTP port in the domain of the master clock available in a cabled Ethernet network and maintains the timescale used in the application. Furthermore, a built-in feature provided by PTP module is a PPS generation on a GPIO, in order to provide a test point and a synchronization trigger source for the low-cost PMU analogue-to-digital converters. Other structures and algorithms are possible as well and are no excluded from the vision of NORM, which is enough flexible to allow different upgrades on both synchronisation and PMU algorithms. The phasor calculation algorithm uses both the PPS signal and the PTP time reference for synchronizing the data acquisition and timestamping the calculated phasors. The PPS is used to trigger the data acquisition board: when the pulse is received the acquisition starts and samples are recorded at the desired sampling rate. The maximum sampling rate may vary, depending on the configuration and the number of signals acquired, between 100 kS/s and 12.5 kS/s, respectively for a single channel (e.g. single voltage acquired) and eight channels (e.g. four voltages and four currents). he data acquisition and phasor calculation require one second to be performed. Data are collected for 880 ms from the data acquisition board, then they are transferred to a Raspberry PI, which performs the actual phasor, frequency and the Rate Of Change Of Frequency (ROCOF) calculation in the remaining 120 ms of the one second window. The obtained results are then published following the IEC 61850 Sampled Values protocol. Figure 7 – Low Cost PMU data flow The first step of the phasor calculation algorithm is the application a Flat Top window to the acquired data, in order to filter data and reduce errors induced by spectral leakage. Then a Discrete Fourier Transform (DFT) is performed on the filtered data, thus obtaining amplitude and phase values of the desired signal. For Frequency calculation, a zero-crossing algorithm is applied to the acquired data and frequency is calculated for each period. The mean value of all calculated frequencies is the value published as representative of the whole acquisition window, while the ROCOF is the difference between the frequency obtained for the first period and that obtained for the last period of the acquired data. The presented implementation of the Low-Cost PMU could be modified or further developed, both from a hardware and software point of view in order to improve performances or reduce total costs. For example, different acquisition hardware could be used, like DPS based acquisition boards, or the processing unit could be implemented on different low-cost boards, e.g. the BeagleBone Black or Raspberry PI2/3 boards. On the other hand, different algorithms could be used for windowing or phasor calculation and in general software implementation could be different.

SUCCESS D3.9 v1.0

(80)

However, this well fits in the NORM vision and unbundled design, since it is not closely tied to a specific implementation or hardware product. NORM new functionalities compared with today Smart Meters NORM is considered as future equipment to replace existing smart meters in the next wave of smart meters deployments, to be considered as a third generation. NORM new functionalities and novelties Today Smart meters are considered as being part of a second generation, with large deployments in the last years over Europe. The first generation, mainly based on very low PLC communication in most situations and GPRS for some segments, started the deployment around year 2005 in early adopting countries such as Italy or Sweden. The second generation is based on quicker PLC communication, and on GPRS/3G communication in some particular cases. Second generation has more complex functionalities, such as net-metering, to be prepared for prosumers, and on complex structures of tariffs, to enable more flexible participation to market opportunities. In first generation of Smart Meters the only communication path is usually only to the DSO. The second generation gives in some situations also an interface to the end customer, e.g. with Linky in France or through the mandatory local interface in Belgium. Cyber-security is implemented on the PLC communication to the concentrator, which is the path to DSO. There is no concept of multi-user communication directly to the meter, thus any information needs to pass through DSO. NORM has new features when compared with the existing smart meters that are currently available in the market. Main features are presented below: Compared to existing SM, the NORM-SMG has a multi-user interface, where all users/actors can communicate in parallel, thus allowing multi-actor interaction directly with the data source, without needing any intermediary system; in addition to energy actors implemented in [19], SMG is implementing also the communication with an important additional actor which is the Critical Infrastructure Security Operations Centre (CI-SOC), mediated by a Security Agent (SecA) running in SMG and extracting the relevant data for CI-SOC. With the CI-SOC communication, new cyber-attack counter-measures can be implemented, in such a way which preserves privacy (only non-private data is collected) and allows detection of data inconsistency from local level, due to redundancy of measured data (meter and PMU) to higher CI-SOC level, where wide area data is checked as a whole The multi-user connectivity is implemented in a secure way, based on Linux supported security features, using VPN technologies such as OpenVPN, first implemented in [19]; NORM’s SMG is going further and implements the new PUF technology, which is a much higher level of security compared with any other security technology implemented in current Smart meters. SMG is aggregating data from two different local measuring equipment: a metrology meter and a low-cost PMU. With this data integration, NORM enables both smart metering and hard real-time smart grid functionalities. This is an important advancement from existing smart meters, as PMU data is now available in any metering point, enabling higher functionality in active distribution networks, specific to high renewables penetration. SMG is implementing new PTP synchronisation of local clock, enabled by 5G communication and allowing PMU functionality without the need of costly and difficult to place GPS receiver. SMG is converting classic PMU protocol (based on C37 standard) to protocols specific to smart grid SCADA (IEC61850) and MQTT based publish-subscribe for simple new services implementation, thus allowing a democratisation of the PMU data

SUCCESS D3.9 v1.0

(80)

The new low-cost PMU integrated in NORM allows democratisation of PMU technology, allowing that such information can be obtained from any point of the network. A comparison between today state of the art smart meters and NORM functionalities is given in the table below. Table 1 - Today state of the art smart meters and NORM functionalities No. Existing smart meters functionality NORM functionality Observations 1 One user interface (usually towards DSO) Multi-user / multi-protocol interface The multi-user feature enables services 2 Metering data for billing Metering data and PMU-based grid data Allows both smart metering and smart grid 3 Time synchronisation of one second Precise synchronisation under one millisecond Allows synchronous PMU measurements 4 Medium up to high cyber-security Enhanced cyber-security with PUF technology Higher trust in smart metering 5 Low to medium grid data redundancy Redundancy for grid data such as voltage and frequency Allows local check of data consistency 6 No intrinsic concept for holistic cyber-security approach Special security agent is running to support higher CI-SOC functionality Non-privacy intrusive security monitoring by design NORM’s SMG compared with the German Smart Meter Gateway The gateway of NORM has the same name as has also the German Smart Meter Gateway. For reasons of clarity, an assessment regarding what is similar and what is different in NORM’s SMG (NORM-SMG) compared with German SMG (G-SMG) is given below. Germany is the only country which comes with a concept of Smart Meter Gateway, which acts as an access point for the data from all meters of the customer (electricity, gas, water etc.), as well as for the home area network data. For this Gateway functionality, it needs to be considered the Data Access Manager (DAM) approach for handling the data, which is defined in [41]. In the German concept, the data from any such source can be retrieved in the so-called Smart Meter Gateway – the responsible for getting the metering data is the Smart Meter Gateway, which belongs to the end-customer. Moreover, even if the access rights for the data may be the responsibility of the end-customer, a third party – which is neither DSO nor Supplier – is managing the access rights. The role of managing the data access rights is kept by a special body for data access rights management, a role different from the DSOs (although they are managing data rights in other data access models), because this is an independent party, similar to the Central Hub in some other European countries. The role of storing the data is however different also to the Central Hub model, as the data is always at the Smart Metering System Gateway level, thus at the end-customer level, bringing

SUCCESS D3.9 v1.0

(80)

empowerment to the citizen, protecting their privacy and reducing their privacy concerns, and giving the option to modulate the policy. From this point of view the German model with DAM is the most modern and advanced in EU/Europe. Some figures from the German gateway specification are below presented, with explanations regarding the relevant aspects of the approach. Figure 8 and 9 from [41] show the three possible networks: the Home Area Network (HAN) - for the home appliances and for local user, the Local Metrology Network (LMN) - for different types of local meters and the Wide Area Network (WAN) – to be assimilated with public IP networks such as internet. A security module is considered to be associated to the German Smart Meter Gateway. In 1.4.6.1 - Handling of Meter Data [41], is stated that: “The Gateway is responsible for handling Meter Data. It receives the Meter Data from the Meter(s), processes it, stores it and submits it to external entities. Moreover, the TOE (Target of Evaluation) utilises Processing Profiles to determine which data shall be sent to which component or external entity. A Processing Profile defines: How the Meter Data must be processed, Which processed Meter Data must be sent and in which time intervals, To which component or external entity has to be sent, Data is signed using which key material, Data is encrypted using which key material, Whether processed Meter Data shall be pseudonymised or not, and Which pseudonym shall be used to send the data.”

Figure 8 - The G-SMG architecture general overview Figure 9 shows the type of actors which can be found in each of the G-SMG networks. For instance, the “consumer” (or end-user) and the “Service technician” can interact only from the HAN, thus are not able to make any remote connection and inspect / modify something from WAN. The “Authorized external Entity” and the “Gateway Administrator” can access the SMGW only from the Wide Area Network (WAN). While these rules give clarity about the access to various resources, the NORM approach is more flexible and gives the possibility for each actor to access its data in a different VPN, thus preserving adequate cyber-security between the different users.

SUCCESS D3.9 v1.0

(80)

Figure 9 - Energy Gateway environment in [41] The German concept is based also on defining a so-called Protection Profile (PP) for the Smart Meter Gateway (SMGW or as we call it also G-SMG in this document), an essential aspect of the German approach for Smart metering. According to the German metering profile specification [42], SMGW is a device or unit responsible for collecting Meter Data, processing Meter Data, providing communication capabilities for devices in the LMN, protecting devices in LAN (such as Controllable Local Systems, CLS) against attacks from the WAN and providing cryptographic primitives (in cooperation with a Security Module). The SMGW combines aspects of the following devices, according to [CEN]: Meter Data Collector, Meter Data Management System, and Meter Data Aggregator. The Gateway does not aim to be a complete implementation of these devices but focuses on the required security functionality. There is a Gateway Administrator which is considered the Authority that installs, configures, monitors, and controls the SMGW. Meters used in the SMGW architecture have to be able to encrypt and sign the data, and will therefore typically deploy a Security Module which is able to perform these operations. With these measures’ confidentiality, authenticity and integrity of the transferred data can be ensured. The Security Module is typically realised in form of a Smart Card. As presented in figure 9, there are 4 actors specified to access the SMGW: Consumer (Prosumer) and Service technician, which can access it through the LAN, respectively Gateway administrator and Authorised External Entity, which can access the SMGW from WAN. It should be noted that there is only one possible Gateway administrator in the German approach, however this one can authorize data access to many Authorised External Entities.

SUCCESS D3.9 v1.0

(80)

Typically, the Gateway will be placed in the household or premises of the consumer. In the chapter 1.4.5 of [42] different implementation possibilities are presented, one of them, “1.4.5.3 - Possible TOE Design: One Box Solution” is shown in Figure 10. Figure 10 - Possible TOE Design: One Box Solution from the German SMGW PP concept with mappings to the SUCCESS NORM This solution is close to the NORM concept. The picture shows a possible mapping of NORM-SMG and of SMM + low cost PMU on this One-box-solution of the German Smart Metering solution. NORM-SMG is targeting however more functionality, a subset and an adaptation of some NORM-SMG functionalities might bring a full compliance with the German SMGW (D-SMG) model. Additional meters to be read by NORM-SMG is a feature already considered, the only difference is that SMG is not using a separate / specific network for it, but it treats it within the LAN or in the set of various LANs (e.g. WiFi and Zigbee). The communication is encrypted and signed in G-SMG. NORM-SMG can do it as well, as it is designed as a Linux machine which can implement various security means, including encryption and digital signatures, thus being flexible to fully implement the G-SMG functionality. Figure 11 shows another possible implementation of the SMGW, again with the SMG and SMM+PMU functionalities mapped on it.

SUCCESS D3.9 v1.0

(80)

Figure 11 - SMGW design, minimal implementation and its mappings to the SUCCESS NORM The logical boundaries of the G-SMG can be defined by its security features: Handling of Meter Data, collection and processing of Meter Data, submission to authorised external entities (e.g. one of the service providers involved) – where necessary protected by a digital signature, Protection of authenticity, integrity and confidentiality of data temporarily or persistently stored in the Gateway, transferred locally within the LAN and transferred in the WAN (between Gateway and authorised external entities), Firewalling of information flows to the WAN and information flow control among meters, Controllable Local Systems and the WAN, A Wake-Up-Service that allows contacts to the TOE from the WAN side, Privacy preservation, Management of Security Functionality, and Identification and Authentication of TOE use. An important aspect is the statement that “it is possible that a Gateway provides more functionality than required by this PP. In those cases, however, it is essential that the additional functionality is separated from the evaluated functionality in a way that it cannot impact the security functionality”. The G-SMG is able to restrict access to (processed) Meter Data in the following ways: consumers shall be identified and authenticated before access to any data may be granted, the G-SMG shall accept Meter Data from authorised Meters only, and the G-SMG shall send processed Meter Data to correspondingly authorised external entities only. The G-SMG shall accept data (e.g. configuration data, firmware updates) from correspondingly authorised Gateway Administrators or correspondingly authorised external entities only. This restriction is a prerequisite for secure operation i.e. for secure handling of Meter Data. Further, the Gateway shall maintain a calibration log with all relevant events that could affect the calibration of the Gateway. The SMGW offers a local interface to the consumer (see also IF_GW_CON in Figure 10) and allows the consumer to obtain information via this interface. This information comprises the billing-relevant data (to allow the consumer to verify an invoice) and information about which Meter Data has been recorded and will be sent to which external entity. The TOE ensures that

SUCCESS D3.9 v1.0

(80)

the communication to the consumer is protected (e.g. by using SSL/TLS) and ensures that each consumer only get access to their own data. Accessing to this interface by the consumer may happen via different technologies as long as the security requirements are fulfilled. The interface IF_GW_CON may be used by a remote display dedicated to this purpose or may be accessed by standard technologies (e.g. via a PC-based web browser). The information flow control and firewall between devices of the three networks is presented in synthetically the Table 2. Table 2 - Communication flows between devices in different networks Rules for WAN: Communication within the WAN is not restricted. However, the Gateway is not involved in this communication. Rules for LMN: No communications between devices in the LMN are assumed. Devices in the LMN may only communicate to the Gateway and shall not be connected to any other network. Rules for HAN: Devices in the HAN may communicate with each other. However, the Gateway is not involved in this communication. If devices in the HAN have a separate connection to parties in the WAN (beside the Gateway) this connection is assumed to be appropriately protected. It should be noted that if a SMGW (TOE) connects to more than one HAN, communications between devices that belong to different HANs, via the SMGW (TOE) are only allowed if explicitly configured by a Gateway Administrator. It shall be noted that this concept deliberately accepts that devices in the LMN or HAN of the consumer cannot directly be contacted from the WAN side. However, the SMGW may implement additional functionality (as long as it does not contradict an SFP from this PP) that sets the Gateway as a broker into the communication between an external authorised entity in the WAN and the CLS. As long as a Gateway has a TLS connection to an external entity it may be technically possible to negotiate a connection between an external entity and a CLS upon the request of the external entity without violating the information flow policies from this Protection Profile (PP). Privacy preservation is implemented in G-SMG in two aspects: a) the Processing Profiles that the TOE obeys facilitate an approach in which only a minimum amount of data has to be submitted to external entities and therewith leave the scope of control of the consumer, and b) SMGW shall provide the consumer with transparent information about the information flows that happen with their data. For the second aspect, logs are needed with the following data: Monitoring of Data Transfers: The TOE shall be able to keep track of each data transmission in the consumer log and allow the consumer to see details on which information have been and will be sent (based on the previous and current settings) to which external entity;

SUCCESS D3.9 v1.0

(80)

Configuration Reporting: The TOE shall provide detailed and complete reporting in the consumer log of each security and privacy-relevant configuration setting. Additional to device specific configuration settings the consumer log shall contain the parameters of each Processing Profile. The consumer log shall contain the configured addresses for internal and external entities including the CLS Audit Log and Monitoring: The TOE shall provide all audit data from the consumer log at the user interface IF_GW_CON. Access to the consumer log shall only be possible after successful authentication and only to information that the consumer has permission to (i.e. that has been recorded based on events belonging to the consumer) The Gateway provides authorised Gateway Administrators with functionality to manage the behaviour of the security functions and to update the TOE. This Protection Profile defines a minimum set of management functions that must be implemented by each Gateway seeking conformance to this PP. Only authorised Gateway Administrators may be able to use the management functionality of the Gateway (while the Security Module is used for the authentication of the Gateway Administrator) and that the management of the Gateway shall only be possible from the WAN side interface. It should also be noted that in the proposed metering infrastructure it should be possible to change the Smart Meter Gateway Administrator (SMGW Admin) rights and assignments also during the operation the of Smart Meter Gateways. There are rules to do it without causing disruption of supply, or gaps in the collection and analysis of measured values. The Smart Metering Gateway Administrator is important actor. According to German rules, market participants entrusted with this task are: Transmission network operator (Übertragungsnetzbetreiber (ÜNB)), Distribution system operator (Verteilnetzbetreiber (VNB)), Measuring point operator (Messstellenbetreiber (MSB)), Communication provider, and Other/state institutions. Parts of the cryptographic functionality used in the SMGW shall be provided by a Security Module. The Security Module of G-SMG (or SMGW) provides strong cryptographic functionality, random number generation, secure storage of secrets and supports the authentication of the Gateway Administrator. Even if the Security Module is a different IT product and not part of the SMGW, it is physically embedded into SMGW and is protected by the same level of physical protection. The German model has been studied and considered in the Smart Meter Architecture because it gives important details of the German metering architecture, which are useful for our metering concept. For the time being we consider the German metering architecture based on SMGW as being a specific and more restricted implementation, which can be implemented with our proposed NORM consisting of more flexible SMG, SMM and low-cost PMU parts. We will not implement SMGW, as none of our demonstrators is located in Germany. We will use, however, these principles of SMGW that have shown to be useful for the more general concept of an USM and feasible in our five demonstrators. In the SUCCESS Metering Architecture there are two Administrators, similar with what is implemented in the Nobel Grid USM: one which has to do with the mandatory country regulations, such that it can secure data which is requested by the law – practically the regulated data management, and one which is the Local user, which can administrate un-regulated data, including more private data which may be needed for advanced energy services, for which the data access and management should be fully decided by the local user. With this approach, we aim to enhance the flexibility of data management and empower the citizen more than it is possible by the restricted solutions of today. The German case of data management is a very good example to follow, adapt and improve for the goals of SUCCESS project.

SUCCESS D3.9 v1.0

(80)

Cyber-security supervision with data delivered by NORM Concept In order to be able to implement the SUCCESS Security Monitoring Solution (CSMS), at the level of the Smart Meter Gateway it is needed to run a Security Agent (NORM-SecA), able to pre-process messages to be sent to the upper level, meaning the Critical infrastructure Security Operation Centre (CI-SOC). SecA manages encryption and cryptographic operations and formats messages in order to include all the relevant information for CI-SOC to: verify data integrity decrypt messages further analyse received value to detect potential threats Figure 12 gives a first view of the concept regarding data monitoring and control by using NORM-SecA in the SMG communication with the higher level CI-SOC.

Figure 12 – The Security Agent in the SMG architecture and its interconnections It can be seen that the Security Agent module interacts with all important modules, namely with the real-time data base and with all interacting interfaces, as well as with components responsible for encrypting and hashing messages, that are respectively the local PUF agent (LPA) and the local Data Centric Security (DCS) agent. The CI-SOC is a new actor comparing with the ones presented in previous figure, which interacts with the SMG-SecA in order to retrieve important data to be processed at its level. A separate VPN is considered for security management, distinct from the one for system administration and the ones for classic actors. The NORM-SecA should be able to retrieve data which is legally allowed, thus it does not request it through an RBAC system, but it needs to be considered as belonging to the trusted party which the CI-SOC. In case that, according to country rules, even the CI-SOC is not trustable, a connection like for all other actors - but with a more relaxed PP, can be implemented as well for the CI-SOC. From architecture point of view, “System Administrator” and “CI-SOC” are both connecting to the “Trusted zone”, as being the only part of SMG which has enough rights to get access to configuring external applications. Due to this particularity, these connections may need even more secure communication means than for standards connections to various actors, thus being eligible for the PUF security which is also subject of SUCCESS project. Figure 13 gives a simple view of security levels for each type of actor connection.

SUCCESS D3.9 v1.0

(80)

Figure 13 – Communication security level for various types of actors It can be observed that for all communications which allow interaction with trusted zone (CI-SOC and SMG System Administrator) it is proposed a PUF based security level, to be developed during the SUCCESS project, and for all other connections it is considered standard high level security based on OpenVPN and its certificates. The credentials needed for the standard connections (e.g. the OpenVPN certificates) may be distributed through the more secure connections based on PUF, as also depicted in figure 3. This document makes a first attempt of classifying the meaningful data and the simple processing, as basic information to be sent by NORM-SecA at the level of trusted CI-SOC. To be noted that one important issue is the need to preserve, where it applies, the privacy of user data, according to European laws and to the energy agencies in different countries. For this reason, most of the data listed below are not private data or do not show end-user private life. The privacy issues are essential at the consumer level, however energy related data in the grid, which does not point on specific customers or are aggregated data, are in most cases data which can be used as it is for the CI Security Operation Centre. The table below does not address the privacy sensitivity of the acquired data, however this subject need to be developed also in specific SUCCESS deliverables. Data has been organized in different categories, as per Annex A. Rationale for selected data for CI-SOC transmission The two measuring devices EM and PMU are not delivering (reporting) instantaneous values (sampled values) towards the SMG, but only calculated values. The voltage and current values obtained from both EM and PMUs are effective (rms) values (not mean values) of the u(t) and i(t) waves. The period of time for calculations is usually different from the period of time for reporting. Both calculating and reporting periods vary from meter to meter, for this reason it is proposed in the document that "reporting rate is 1 to 10 seconds" for voltages, to accommodate different meter types. For the phasor measurement there are the following sources of data: in 3-phased EM, we can have only two angles (fi1-2, fi2-3), the third is redundant if it is calculated (the sum need to be 360 degrees), or is used for validation if it is measured as well. Different meters are doing it in different ways. Moreover, the angle of U1 is

SUCCESS D3.9 v1.0

(80)

considered zero, so again we might have only fi(U2), fi(U3). There is no voltage angle information for mono-phase meters (as you expected), because the angle is always considered zero (as a reference). For mono-phase meters there is only angle between voltage and current. I initially wanted to put it in the list and I still consider it, but I am still thinking on privacy issues, as it gives some indirect hints on consumed power (which is highly sensitive regarding privacy) for PMUs it is different, they have for all phases angles which can be different from zero, . Moreover, there is angle also for mono-phase meters (because the reference is given by the precise time) NORM drop of components strategy for development The project aims to develop NORM in two steps: initial drop of components, is finalised in M12 (milestone MS5) and final drop of NORM components, finalized in M24 (milestone MS6). NORM is a complex equipment based on several components: SMM, low cost PMU (LCPMU), PUF technology and NORM-SMG. The final drop of NORM components is a system which uses a market existing smart meter acting as an SMM and 3 x RPI2/3 subsystems, each with the following role: RPI2/3#1 is the system which implements LCPMU RPI2/3#2 is the system which implements the PUF cyber-security technology RPI2/3#3 is the system which implements the NORM-SMG The advantage of this approach relies in the fact that each important component can be tested separately, in order to achieve a level of functionality needed for system operation and for further refinements, if needed. The final drop of NORM components is a system which integrates the 3 x RPI2/3 subsystems. The NORM functionality as a whole and the functionality of each component is described in this deliverable.

SUCCESS D3.9 v1.0

(80)

3. NORM main modules The NORM modules are based on the unbundled concept, as described before. This chapter presents the modules seen as black-box components, and describe hardware and basic functionality of the modules. Software components involved in NORM are however described in next chapter 4. Smart Meter Gateway (SMG) In this section are presented the basic description of NORM’s SMG. The core Computer platform The core computer has the following sub-modules: The Single Board Computer (SBC), which is a RPI3 solution in the SUCCESS project, A power supply for the SBC, connected to the dedicated micro-USB connector. The following description of the components apply: The PUF board description The PUF functionality is implemented in SUCCESS on a dedicated RPI3 platform on top of an FPGA board. The specification requirements related to the selection of the FPGA board indicate that the FPGA board is able to: seamlessly integrate with the NORM core computer platform (namely the RPI3 board) through a Serial Peripheral Interface (SPI) bus interface to enable read and write access to the internal FPGA registers; be of low cost, matching the low-cost objective of the NORM; process a large number of PUF requests, i.e. generation of a response based on a challenge, as well as encryption requests. Based on the above requirements, a Xilinx Spartan-6 LX9 (XC6SLX9) FPGA was chosen, featuring 1430 slices, 11,440 CLB Flip-Flops (used for the PUF configuration) and 576kB of RAM [2], accompanied by 2 SPI ports allowing for a maximum bandwidth rate of approximately 4MB/s, which is deemed enough for the SUCCESS purposes. For reasons of independent developments, the implementation is made with a separate RPI3 used for the PUF demonstration. The register access will be performed by exchanging respective SPI packet, the format of which is shown in Fehler! Verweisquelle konnte nicht gefunden werden.. The interface enables FIFO-register access, meaning that a user can read/write FIFO data by simply sending an SPI message with more than one data bytes. Table 3 - Table 2: SPI Message format 1st byte 2nd byte … N+1th byte HEADER 1st R/W data … Nth R/W data Table 4 - SPI Header format 7 .. 4 bit 3 .. 1 bit 0 bit register address Reserved R/W (1 = write)

SUCCESS D3.9 v1.0

(80)

Figure 14: PUF FPGA architecture As depicted in [37], the FPGA incorporates a register that is holding the active challenge. The output of the challenge register file is fed to the PUF module. The output of the PUF module is sent back to the SPI interface and to an AES encryption module. In this manner, one can choose to retrieve directly the PUF response for key-pair validation purposes, or pass data to be encrypted by the AES module using as encryption key the PUF response. Note that to facilitate interaction with the core services of NORM outside the PUF FPGA (particularly the core PUF software service, i.e. the local PUF agent documented at §4.4), the standard SPI driver bundled with the default Raspberry PI 3 operating system, Raspbian [3], is utilized for enabling software access to the PUF FPGA. The exact PUF architecture that will be incorporated is still under evaluation. There are several candidates that are currently evaluated in terms of performance, reliability and long-term stability. The architectures that are up to this time of writing under consideration are presented in the following paragraphs. 3.1.2.1 PicoPUF-ID The architecture of a single-bit PicoPUF cell uses two matched delay paths implemented by two toggle flip-flops which are first reset by a synchronous CLEAR. They are then excited simultaneously on the next clock edge with the use of a common CE. Fixed routing is used to pass each signal into a LUT based cross-coupled NAND gate which acts as an arbiter to determine which signal arrived first. To implement the cell on an FPGA requires just two LUTs and two flip-flops, which compactly fits into an FPGA slice. This has the benefit of ensuring all routing stays local in the SLICE and its corresponding switch matrix, rather than passing through the general interconnect. The small and independent nature of the cells also means they can be placed disparately throughout the FPGA fabric in the spare logic of a design. 3.1.2.2 Butterfly PUF The butterfly PUF was introduced as a more general equivalent of the SRAM PUF for FPGAs, as not all devices support the uninitialized SRAM start-up values required. The butterfly PUF consists of two cross coupled latches with manually routed paths to create as symmetrically routed paths as possible. The clock for both latches is always set high to create a combinatorial loop. To read back a response the excite signal is set high which puts the circuit in an unstable state, when the signal is subsequently set low the output will randomly (but consistently) set to 1 or 0 based on manufacturing process variations. 3.1.2.3 Arbiter PUF The arbiter PUF is based on comparing how long it takes a signal to travel two identical paths, determined by an arbiter at the end. The paths delays slightly mismatch due to random process

EncrypteddataPUF FPGASPIPUF AESChallenge Response Response Raw dataLocal PUF agentChallenge Register

SUCCESS D3.9 v1.0

(80)

variations. The multiplexor select lines are fed by the input challenge and, ideally, the number of independent paths a signal can take through the circuit is exponential in nature. However, it is somewhat less than this as not all multiplexors will have the same effect on the output. The restricted routing options available in FPGAs also means that a straightforward implementation will result in heavily biased designs as the difference between the delay paths will be determined by the interconnect delay rather than any random process variations. 3.1.2.4 XOR-Arbiter PUF The XOR-arbiter increases the complexity of the circuit to thwart modelling-based attacks. The basic premise of this approach is to combine the output of many arbiter circuits using an XOR gate. Several different architectures are possible, each with varying trade-offs. Examples include simply XORing the output of many parallel arbiter circuits, or using the same arbiter circuit and deriving subsequent challenges from the base challenge. 3.1.2.5 SUM Ring Oscillator PUF The SUM Ring Oscillator PUF provides a much larger challenge space than the original RO PUF. Pre-determined pairs of RO are summed together, with the challenge determining the sign of the frequency difference. A thresholding step is then used to return a single bit. This also has the effect of de-biasing the bit outputs. Smart Metrology Meter (SMM) Introduction The Smart Metrology Meter is the NORM component which is supporting the traditional legally recognized metering. For this, a market existing meter has been used in the project, to integrate the metering data in the SMG, together with the PMU data, and to send it at that level to various actors, including the Security Agent, which is delivering data to higher levels for assessing anomalous situations which may raise flags for possible cyber-attacks situations. In our project we have integrated energy meters which are found in the demonstrators’ premises, as follows: In the Italian trial site (Terni) it has been integrated the Wally A meter, which is a combined power quality and energy meter. In the Romanian trial site the DSO uses extensively Itron meters of type SL7000 and Elster meters of type A1800. As in the Electrica region with renewables there are more Elster meters and as these meters have a good resolution for the frequency measurement (better than 10 mHz, comparing with 100 MHz for SL7000), the A1800 meter is used as SMM part of the NORM. In the Irish trial site it is used also the Wally A meter, which has a very good resolution for frequency measurement, which is important in this demonstrator. In the final level of integration (final drop of NORM) all these meters are integrated. Below can be found some data acquired by SMG by using these types of SMM. Wally A meter Wally A meter [43] has been connected to SMG part of NORM through its Ethernet interface. This interface can send XML data to the SMG driver which has been specially designed to be compatible with Wally A. Below is presented the list of relevant data which is read from Wally A meter: Voltage U1, U2, U3 (on each phase) Currents I1, I2, I3 (on each phase) Three phase active power with plus (Ap) Three phase active power with minus (Am) Three phase active energy register with plus (Ep) Three phase active energy register with minus (Em) Frequency of the grid

SUCCESS D3.9 v1.0

(80)

Examples of voltage and frequency variation are presented in the figures 15 and 16 below Figure 15 – Voltage variation records with Wally A meter

Figure 16 – Frequency variation records with Wally A meter To be noted that during the second phase of integration the Wally A meter reporting for frequency has been improved, being possible to read the frequency as requested by IEC61000-4-30, which is an average per 10 seconds, for measurements stability reasons as well as the real-time frequency needed for dynamic applications. A1800 meter A1800 meter [44] has one or two RS232 communication ports and the meter data can be read through a DLMS protocol. In the project, the already existing DLMS driver of SMXCore is adapted for readout of the needed data coming from A1800 meter. Below is presented the list of relevant data which is read from A1800 meter:

SUCCESS D3.9 v1.0

(80)

Voltage U1, U2, U3 (on each phase) Currents I1, I2, I3 (on each phase) Three phase active power with plus (Ap) Three phase active power with minus (Am) Three phase active energy register with plus (Ep) Three phase active energy register with minus (Em) Frequency of the grid Examples of voltage and frequency variation are presented in figures 17 and 18.

Figure 17 – Voltage variation records on phase 1, with A1800 meter Figure 18 – Frequency variation records with A1800 meter Figures 19 to 23 show voltage and frequency records from a PV plant and from a hydro-plant from the Romanian trial site.

SUCCESS D3.9 v1.0

(80)

Figure 19 – Voltage variation records over an entire day at a PV plant in Romania Figure 20 – Frequency variation records over an entire day at a PV plant in Romania

SUCCESS D3.9 v1.0

(80)

Figure 21 – Voltage variation records over an entire day at a hydroplant in Romania Figure 22 – Frequency variation records over an entire day at a hydro plant in Romania To be noted that the records have been made in daily files, at one second based time intervals. Moreover, all presented data are non-private data which can be sent to the CI-SOC for further processing regarding data consistency. Low cost PMU The low-cost PMU (LCPMU) is based on a distinct Raspberry Pi 3 (RPI3) platform, which has in addition an interface for acquiring voltages samples from the three voltage phases and a GPS interface for synchronisation. The LCPMU is synchronized in the project by using a PTP protocol, already described in 2.2. The LCPMU is running each one second an algorithm for providing voltages magnitudes, voltage angles, network frequency and rate of change of frequency (ROCOF), which are then provided towards SMG through an IEC61850 Sampled Values protocol. The LCPMU functionality is independent of other NORM functionalities, in order to keep the Unbundled Smart Meter architecture. A software library has been developed with a set of algorithms to calculate synchrophasors, frequency and ROCOF based on the samples provided by the data acquisition board. The measurements are then encapsulated in the Sampled Value (SV) messages and later into UDP-IP packets, as recommended by the IEC 61850-90-5 [4] standard for PMUs. Figure 23 shows the operation of the PMU in real time. The Pulse Per Second (PPS) signal of the GPS triggers the acquisition of samples every second. The samples are digitally filtered and then passed to a zero crossing algorithm to calculate the frequency. The samples are then passed to a block to calculate the Discrete Fourier Transform (DFT) and published via SV and UDP.

SUCCESS D3.9 v1.0

(80)

Figure 23 - Flowchart of LCPMU real time operation

SUCCESS D3.9 v1.0

(80)

4. NORM Smart Meter Gateway software Considering what is written in chapter 2, the consortium took specific steps to achieve the goal of testing and integrating the SUCCESS Security Monitoring Solution. In this course, first, individual component testing on all SUCCESS Security Monitoring Solution have been performed. The testing refers to components developed in the context of WP3, followed by WP4 components tested and documented in the context of D4.9. Open source SMXcore 4.1.1.1 Real-time Database organisation From dynamics and persistency point of view, SMXcore considers two types of data: A) Real-time data, which is non-persistent and which is expected to be frequently modified (e.g. each 1 second). Examples of such data are the instrumentation data coming from the meter, such as active and reactive power (P and Q), voltages U and currents I. This data is kept as variables in the SMXcore program (RAM allocated variables) and can be quickly accessed internally or outside SMXcore. This data is obtained by applications (Apps) through frequent read or write by using an MQTT mechanism which is supported by SMXcore, which can incorporate instances of MQTT clients (to be described later, in the SMXcore modules). Real-time data are not saved on disk, thus after a shut-down / power-up it is needed new data to be written in the SMXcore variables, in order to have again real data in the allocated variables. B) Archive data. This is persistent data, with storage not based on a database, but on daily logs of files, which have records every 1 to 60 seconds (programmable). 4.1.1.2 RBAC concept The RBAC system is already described in 2.2.1. Figure 18 gives a zoom image to the core RBAC architecture, which is implementing the control differently for each client connected to the database, as seen also in figure 24. Figure 24 – RBAC system, controlling data exchange with different actors. As having a database centric approach, all actors can access only the database and cannot have direct connection between them, in order not to transfer data which is nor controlled by the user. 4.1.1.3 MQTT communication SMXCore allows to access the real-time database through MQTT clients. In figure 25 below

SUCCESS D3.9 v1.0

(80)

Figure 25 – Clients connection to SMXCore real-time database through MQTT clients and broker In the figure it can be seen that all external actors (1 to 3) can receive and send the same type of data, depending on the subscription made to the MQTT broker (Mosquitto). If the database need to be connected to two different types of actors, it is advisable to have also two different MQTT brokers, one for privacy profile 1, specific to actor 1 and one for privacy profile 2, specific e.g. to a pool of actors with the same rights to access data. Figure 26 shows such an example, with two types of actors, needing two MQTT brokers. Figure 26 – Example of SMXCore with two types of actors, having different privacy profile (PP). In this example, the second MQTT broker is used to connect different external MQTT clients through internet, thus allowing through the MQTTClient2 configuration file to define the specific privacy profile through a RBAC described in a configuration file. It can be seen that there are different privacy profiles (PP1, PP2) for each MQTT client, which allows that only specified data can be exchanged with each pool of actors (for PP1 we have only Actor 1, and for PP2 we have a pool of two actors: Actor 2 and Actor 3, which share the same type of data). 4.1.1.4 Meter communication The project integrates meters available in the trial sites.

SUCCESS D3.9 v1.0

(80)

According to the site analysis and based on availability of meters in each demonstrator, the following types of meters are chosen for integration in SUCCESS project: Irish site: Wally A meter [43] Communication: http interface, XML messages Romanian site: Elster A1800 meter [44] Communication: serial interface, DLMS/COSEM Italian site: Wally A meter [43] Communication: http interface, XML messages For each type of meter, the communication reporting rate in SMG will be maximum ten seconds, based on meters communication periods. PMU protocol converter The low-cost PMU can be interfaced with an IEC61850 protocol. As the basic SMXCore does not support at this time such a protocol connector, a conversion to MQTT messages need to be done. Such conversion is managed by the SMXcore, using an IEC 61850 Sampled Values (SV) subscriber and a PMU driver, able to interpret the data coming from the PMU and write them into the Database Centric Architecture of the SMXcore. In the initial drop of NORM components, the PMU has been tested for IEC61850 capability, while in the final drop the Sampled Value subscriber and the PMU diver have been implemented in the SMXcore. The LCPMU uses the open source libraries libiec6850, in order to send the measurements in the Sampled Value (SV) format, as recommended by the IEC 61850-90-5 standard for PMUs. The SV publisher is configured by means of the Substation Configuration Language (SCL) file, where the measurement data are mapped onto 61850 data models, which account of physical device, logical device, logical nodes, data object and data attributes. In order to be able to send PMU into Wide Area Networks (WANs), SV messages are also encapsulated into UDP-IP packets. In the final drop the PMU data is converted from IEC61850 in appropriate messages order to be stored in the real-time database and to be converted in MQTT messages for communication with SecA and with the actors related to critical infrastructure (DSO-SCADA and CI-SOC). The structure of such data protocol conversion is depicted in Figure 27.

SUCCESS D3.9 v1.0

(80)

Figure 27 – Interface between LCPMU and Smart Meter Gateway The Sampled Values are published every second by the PMU and the subscriber in the SMXcore receives the updated measurements each second. Once the data are received they are interpreted, in compliance with the data model specified in the SCL file. Then the measurement data are stored written into a local file in the SMXcore memory, where the PMU driver can read them and write them into the Real-time database. Finally, MQTT messages are created, reporting voltage magnitude and phase, frequency and ROCOF. PTP functionality This module is able to synchronize the Linux machine clock at much higher accuracy than NTP does. It refers to IEEE 1588 – 2008 standard and even though the accuracy expectations of PTP synchronized clocks is in the order of 100 ns, based on the quality of network connection, realistic synchronisations between 10 to 100 microseconds are expected in the SMG. The basic principle is similar to NTP protocol, where computers and other devices that have a clock are connected in a network and form a hierarchy of time sources in which time is distributed from top to bottom. The devices on top are normally synchronized to a reference time source (e.g. a timing signal from a GPS receiver). Devices “below” periodically exchange timestamps with their time sources in order to measure the offset of their clocks. The clocks are continuously adjusted to correct for random variations in their rate (due to effects like thermal changes) and to minimize the observed offset. The master on top is called grandmaster (GM). A device that has ports in two or more communication paths (i.e. it can be a slave and also master of other slaves at the same time) is a boundary clock (BC). Clocks with one port are ordinary clocks (OC). The group of all clocks that are directly or indirectly synchronized to each other using the protocol is called a PTP domain.

Phasor Node• Wihtdraw digitalsamples• CalculateSynchrophasor, frequency, ROCOF• Save dataInternal data structureSV PublisherIEC 61850PMU algorithms

LCPMU SMXcoreSV SubscriberIEC 61850PMU driverDatabase CentricArchitecture

Trusted ZoneDataSet kDataSet 1SMX/LD01/U1 235.21SMX/LD01/U2 235.21SMX/LD01/U3 235.21SMX/LD01/I1 2.34SMX/LD01/I2 2.34SMX/LD01/I3 2.34Internal DataSetsReal-time data, JSON formatReal-time Data BaseIEC 61850 SV

SMXCore Basic InterfacesMQTTClientRBACPrivacy ProfilePP 1MQTTClientRBACPrivacy ProfilePP 2MQTTClientRBACPrivacy ProfilePP 3OpenVPNclientSystem administration

SUCCESS D3.9 v1.0

(80)

Figure 28 – PTP domain The PTP module in NORM features a single PTP port in the domain of the master clock (represented by the 5G eNodeB) and maintains the timescale used in the application. Furthermore, a built-in feature provided by PTP module is a PPS generation on a GPIO, in order to provide a test point and a synchronization trigger source for the low-cost PMU analog-to-digital converters. Between the two possible Linux implementations of PTP considered for SMG (PTPd and PTP4L), the final choice was for PTP4L, due to its best performance given that it natively relies on the core kernel module and supports both software and hardware timestamping. Moreover, PTP4L offers higher degree of customization allowing tuning either of the filter and the feedback control to compensate jitter on the communication link, which may be useful with 5G mobile networks. Figure 29 – PTP4L architecture The ethernet physical layer of the adopted SMG CPU (RPI3) does not support hardware timestamping: hence software emulation must be enabling in ptp4l configuration. Despite this, when PTP4L starts automatically at boot, it fails because the current Raspbian kernel misses a patch to the ethernet driver and some required configuration not enabled by default. For that reason, it has been necessary to rebuild the kernel with required patches and proper configuration options. A detailed explanation of the required steps as well the necessary files/scripts for building the PTP on the NORM SMG has been posted to the public repository github at the link https://github.com/twteamware/raspberrypi-ptp). After the linux kernel has been patched, configured, built and deployed to the target, PTP4L automatically starts as a systemd service at boot, making precise system time available for all other system and application processes. In addition to the PTP implementation, another feature has been added to the NORM SMG in order to offer the capability of locally generating a PPS signal on a GPIO pin of CPU, for synchronization purposes of other SMG modules (e.g. low-cost PMU). The PPS generator is synchronized with the PTP module. The setup involves tasks similar to those described in PTP implementation, namely patching configuring and compiling a new kernel for the Raspberrypi. At the same above mentioned github link are described the steps for adding the PPS generator feature and if necessary how to change default GPIO pin for PPS signal.

SUCCESS D3.9 v1.0

(80)

PUF security modules As mentioned in the previous subsections, the role of PUF in the overall NORM architecture is twofold: 1. Provide a way for authenticating NORM against the CI-SOC, i.e. offering uniqueness features and allowing for PUF-based authentication, and; 2. Deliver on-demand encryption services to the various data services hosted under the overarching SMG concept (e.g. the low-cost PMU or the metering services). As the interface between the core computer and the FPGA implementing the PUF is performed on the basis of a serial bus (SPI), a local PUF agent has been implemented in software in the form of a simple web service that exposes the PUF functionality (and the bus one) to the rest of the NORM components by means of a RESTful API implemented as a lightweight1 Flask Python application [4] communicating with the SPI through the SPI driver mentioned in §3.1.2. The overall PUF (hardware and software) architecture is depicted on Figure 30. Figure 30: Overall PUF architecture. The local PUF agent will be providing service endpoint URLs over Secure HTTP (https) exposing services related to: 1. Bootstrapping the PUF functionality against CI-SOC Key Management module; 2. Authentication against the CI-SOC Key Management module; 3. Encryption of transmitted data. In the following paragraphs, the relevant functionality is briefly discussed. For details on the PUF DSOSMC counterpart i.e. the Key Management module, the interested reader should refer to [2]. Bootstrapping services As, based on the discussion held on §3.1.2, SUCCESS is willing to trade larger persistent storage for the security offered by a non-model-based PUF implementation combined with a strong PUF approach. In this framework, the availability of a large number of challenge-response pairs at authentication server level (Key Management component of the CI-SOC) prior to a PUF deployment on a NORM is extremely important. To this end, the PUF local agent features a service able to communicate with a designated DSOSMC Key Management module to perform the bootstrapping as follows: 1 The lightweight operation of the local PUF agent is imposed as a stringent requirement, based on the limited resources of the core NORM computer and the abundancy of services required to operate on it.

NORMFPGA RPI 2/3 DSOSMCVPNLocal PUF agentSPI APISPI Key ManagementOther DSOMC modulesIntegration APISPI Driver Other NORM servicesOther NORM servicesOther NORM servicesPUF AES

SUCCESS D3.9 v1.0

(80)

The bootstrapping service of the CI-SOC Key Management module is invoked by the local PUF agent, designating a number of awaited challenges (say Nc), The local PUF agent processes the response of the CI-SOC Key Management module (consisting of a dictionary of Nc challenges) and responds with a dictionary of Nc responses. Note that the above procedure should take place in a controlled environment or, in any case, non-field setting, to avoid the exposure of the challenge-response pairs to the public. In the case of bootstrapping at field settings, the above steps should be performed only if the communication link is protected by an encrypted (e.g. VPN) connection. After this bootstrapping procedure has been performed, the PUF is ready for field use. Authentication services After the bootstrapping procedure has been performed and the PUF-enabled NORM has been put on operation, the NORM should be able to perform authentication requests against the CI-SOC. In the context of SUCCESS’ strong PUF implementation, depending on the bootstrapping configuration of the node as to the number of challenge strings requested by the local PUF agent, each PUF should be able to authenticate itself against a unique active challenge. Ideally, this challenge should only be used once, then be deleted so that it is not possible for a malicious third party to overhear it and use it again. However, as in the context of SUCCESS the PUF-supported operations will be take place over encrypted (VPN) channels, a re-use of a challenge-response pair for a limited amount of time will be attempted, namely all requests that take place in the timeframe of a minute will be based on the same challenge. Considering the above discussion, the PUF should be able to validate itself against the CI-SOC Key Management module by providing its ID and a response that matches the active PUF challenge. To this end, the local PUF agent holds in RAM the active challenge that governs the PUF authentication at any given moment and will send authentication requests periodically. If an active challenge is not found in RAM (e.g. in the case of a NORM reboot), a request for a new challenge is issued against the CI-SOC Key Management module. Note that the CI-SOC Key Management module already features a mechanism for communicating to registered PUF-enabled NORMs new challenges at pre-defined time intervals (e.g. every 1 hour or less, based on constraints found during the developments). Encryption services Granted that the bootstrapping and authentication processes operate as expected, the local PUF agent is able to offer AES-based encryption services to the various NORM modules hosted under the SMG scope. In this respect, the local PUF agent exposes a RESTful API that can be used by the rest NORM modules to encrypt data POSTed to the service. The steps followed upon receipt of such a request are as follows: 1. Make sure that an active challenge is held in RAM; a. In the case this is not true, request a new challenge from the DSOSMC Key Management module; 2. Request a new encryption request from the PUF, providing as input the active challenge and the data to be encrypted; and 3. Receive from PUF the encrypted data and enfold them in the response to the original encryption request. Note that, as mentioned in §3.1.2, the PUF encryption mechanism is using the active challenge to produce a proper response which is, in turn, used as the encryption key for the data encryption process. As the CI-SOC Key Management module is aware of the expected responses to the set of known challenges of all the PUFs, it is readily possible to decrypt the data (at the server side). It is worth highlighting that this encryption may work in conjunction with the encrypted channels approach (VPN) employed by SUCCESS for the critical, security-related information transmitted by the NORM to the CI-SOC, adding another security layer on top of the existing one. In this manner, even if a third party gains physical access to the storage contents of NORM, hence

SUCCESS D3.9 v1.0

(80)

also the VPN configuration/keys), they won’t be able to overhear the information transmitted from NORM to the CI-SOC. Requirements and API documentation The local PUF agent (LPA) exposes a HTTP RESTful API for allowing other components make use of its functionality. The rest of the paragraph overviews how a third party can interact with the LPA. It is worth noting that the present implementation of the LPA offers full support for multi-Utility operation, by means of in-memory management of the active challenges for each Utility supported at NORM level. The hardware and software requirements for running the LPA are minimal, as shown in the following table. Note that resource requirements may be upscaled as the number of supported Utilities increases. Table 5 - Minimum hardware and software requirements for running the local PUF agent. Requirement Minimum Recommended Comments CPU cores 1 2 2 cores are needed in the case of integrating encrypting PMU values where the requests rate is expected to be high. RAM 64MB 100MB Can be tuned depending on the load we would need to address (currently parallelization x4 is assumed). Disk 30MB 100MB Including the various system libraries, services etc. Miscellaneous A port for listening to incoming requests is definitely needed to expose the RESTful API. Port 8080 has been initially chosen to support this cause, through it is completely configurable. The LPA may be operated within a sandboxed Docker environment granted that access to the SPI port has been provided at runtime. From a software requirements standpoint, standard Python support is explicitly needed, which is standard in all RPi versions and flavours. In the next paragraphs, the API exposed by the LPA is discussed, followed by the relevant data models that are used for the component communication processes. Note that granted the limited hardware resources available at NORM level and the fact that the NORM might be connected to the internet through metered networking interfaces (e.g. GRPS/4G/5G SIM cards), the API and the data models have been kept as minimal as possible. Table 6 - API service model Property Type Description endpoint String The relative URL of the service endpoint method String The HTTP method it exposes accepts String The content type of the required

SUCCESS D3.9 v1.0

(80)

response (only application/json) content-type String The supported content-type of the request (only application/json) description String The short API description Table 7 - Doc model Property Type Description data List<API> A list of supported APIs Table 8 - Challenge model Property Type Description challenge String The challenge to sync Table 9 - Message model Property Type Description msg String The message text Table 10 - Data model Property Type Description data String A certain piece of data Table 11 - Encoded data model Property Type Description data String A certain piece of data encoded timestamp String The time of the encryption on time zone-aware ISO8601 format

SUCCESS D3.9 v1.0

(80)

Table 12 - PUF ID model Property Type Description puf String The ID of the PUF (can be extracted by calling on the encode endpoint trying to encode a certain fixed string) Table 13 - Log data model Log Property Type Description log List<String> A list of strings, each one of which holds a line of the log. Table 14 - Firewall rule data model Property Type Description rule String The firewall rule to apply. This should be iptables-compliant Table 15 - Firewall configuration model Property Type Description puf String The PUF id rules List<Firewall rule> The list of Firewall rules to apply. Given the above data models, several API service endpoints have been defined as presented in the following paragraphs. Note that the service API endpoint status codes are following the standard web notations, a status code of 200 and 201 meaning that everything went well with the request processing, 400 implying that the request was malformed, 401 stating that unauthenticated API access was attempted, 403 stating that unauthorized API access was attempted, 404 meaning that there was no relevant output to provide, 405 if the HTTP method invoked was wrong and 500 declaring that the LPA was not able to serve the request due to an internal error.

SUCCESS D3.9 v1.0

(80)

4.4.4.1 Overview of the API documentation Endpoint URL / HTTP Method GET Request body N/A Response body Doc object (see Fehler! Verweisquelle konnte nicht gefunden werden.) Although self-documentation systems like Swagger2 or Apiary3 are gaining increased visibility and guarantee dynamic API usage documentation, the LPA exposes its own, minimalistic documentation as a means of complying to the requirement of minimal resources utilization. The following listing presents how a relevant API service invocation may be implemented using the standard cURL command line tool. $ curl http://<NORM_IP>:<LPA_PORT>/ [ { "endpoint": "/logs/<lineno>", "method": "GET", "accepts": "application/json", "content-type": [ "application/json", "application/xml" ], "description": "Gets the last <lineno> lines of the logs of the PUF local agent." }, { "endpoint": "/reset/", "method": "POST", "accepts": "application/json", "content-type": [ "application/json", "application/xml" ], 2 https://swagger.io 3 https://apiary.io/

SUCCESS D3.9 v1.0

(80)

"description": "Reset the Puf. The body of the request should be in json format of type {\"puf\":\"<id>\"} where the <id> should be the id of puf." }, . . . ] Figure 31: Getting the API documentation of the LPA. 4.4.4.2 Get the ID of the PUF Endpoint URL /id HTTP Method GET Request body N/A Response body PUF ID object (see Table 12 ) This service allows getting the ID of the PUF. The PUF ID is generated as the result of the encoding of a standard string using a standard challenge. Since by design all PUFs should provide a different response for this standard challenge, the encryption of the same string using this response as a challenge is guaranteed to be different, hence it can be used as an ID of the PUF. The following figure presents an indicative service invocation: $ curl http://<NORM_IP>:<LPA_PORT>/id { "puf": " 3468356a6572666866353435" } Figure 32: Getting the ID of the PUF. 4.4.4.3 Get the Utilities supported by the LPA Endpoint URL /utilities HTTP Method GET Request body N/A Response body Message object (see Fehler! Verweisquelle konnte nicht gefunden werden.) This service allows for the discovery of the Utilities that this NORM (hence LPA) serves. The context of the Message object is a simple JSON list of strings, each string corresponding to a supported Utility. For security reasons, further information on the Utilities are not provided.

SUCCESS D3.9 v1.0

(80)

$ curl http://<NORM_IP>:<LPA_PORT>/utilities { "msg": [ "utility_a", "utility_b" ] } Figure 33: Retrieving the LPA-supporting utilities. 4.4.4.4 Update the active challenge for a given Utility Endpoint URL /utilities/{id}/challenge HTTP Method POST Request body Challenge object (see Fehler! Verweisquelle konnte nicht gefunden werden.) Response body Message object (see Fehler! Verweisquelle konnte nicht gefunden werden.) Table 16: Service path parameters for updating the active PUF challenge for a Utility. Name Type Example Description id String utility The id of the utility to change the challenge for By using this interface, the CI-SOC Key Management Module (KMM, see deliverable D3.6 for discussion and details) of each supported Utility can update their corresponding active PUF challenge. The active challenge of each Utility is kept in an in-memory cache and is only applied to the PUF once really needed (e.g. in the case of a verification request or data encryption request). Upon successful operation, the PUF challenge gets updated with a generic, standard challenge (that would fail all utility verification tests). The following listing presents a sample service invocation. $ curl -X POST -H "Content-Type: application/json" -d '{"challenge" "a_challenge_string"}' http://<NORM_IP>:<LPA_PORT>/utilities/utility/challenge { "msg": "Challenge updated successfully"

SUCCESS D3.9 v1.0

(80)

} Figure 34: Updating the challenge for utility with id "utility". 4.4.4.5 Bootstrap the PUF LPA against a Utility Endpoint URL /utilities/{id}/bootstrap HTTP Method PUT Request body N/A Response body Message object (see Fehler! Verweisquelle konnte nicht gefunden werden.) Table 17: Service path parameters for bootstrapping the PUF against a Utility. Name Type Example Description id String utility The id of the utility to change the challenge for If during its normal operation the CI-SOC KMM of a Utility depletes the available number of CPRs, it can instruct the LPA to bootstrap the PUF. In this case, the following steps get implemented: 1. The LPA issues a request for verification and gets verified; 2. The LPA requests from the CI-SOC KMM to generate a number of challenges to provid responses for; 3. The LPA delivers the CPRs to the CI-SOC KMM. The following listing offers a depiction of how this service may be invoked. $ curl -X PUT -H "Content-Type: application/json" http://<NORM_IP>:<LPA_PORT>/utilities/utility/bootstrap { "msg": "Bootstrap executed" } Figure 35: Instructing the LPA to bootstrap the PUF to a utility. 4.4.4.6 Encode a piece of data using the PUF Endpoint URL /utilities/{id}/encode HTTP Method POST Request body Data object (see Table 10 )

SUCCESS D3.9 v1.0

(80)

Response body Encoded data object (see Fehler! Verweisquelle konnte nicht gefunden werden.) Table 18: Service path parameters for encoding a certain piece of data. Name Type Example Description id String utility The id of the utility to use for using the right encryption key (response to the active challenge) By using this interface, the various components of NORM and particular the NORM Security Agent (documented in the next subsection) can encrypt a certain piece of data (e.g. measurements from the smart meter) prior to sending them to the CI-SOC to be decrypted and properly processed. The encryption process happens entirely on the PUF, where an AES encryption operation takes place, using the response to the active Utility challenge as encryption key. $ curl -X POST -H "Content-Type: application/json" -d '{ "data" "string_to_be_encrypted"}' http://<NORM_IP>:<LPA_PORT>/utilities/utility/encode { "data": "70738c3eb7f6cbf97acbb54878be46c6", "timestamp": "2018-04-12T11:47:18.687105Z" } Figure 36: Invoking the encryption services of the LPA. 4.4.4.7 Verify the PUF Endpoint URL /utilities/{id}/verify HTTP Method POST Request body PUF ID object (see Table 12 ) Response body Message object (see Fehler! Verweisquelle konnte nicht gefunden werden.) Table 19: Service path parameters for verifying a PUF. Name Type Example Description id String utility The id of the utility to verify against This service is used by the CI-SOC KMM in order to allow proper verification of the normal PUF operation. When invoked, the LPA operates as follows:

SUCCESS D3.9 v1.0

(80)

1. Requests a challenge update from the CI-SOC KMM of the utility of interest; 2. Provides the response back to the CI-SOC KMM to be verified. If it matches the expected one, then the PUF authenticity is verified, else, not. The following listing presents how the LPA verification service may be invoked, using the standard command line tool cURL. $ curl -X POST -H "Content-Type: application/json" -d '{"puf": " 3468356a6572666866353435"}' http://<NORM_IP>:<LPA_PORT>/utilities/utility/verify { "msg": "Verification successful" } Figure 37: Verifying the PUF authenticity. 4.4.4.8 Firewall Endpoint URL /firewall HTTP Method POST Request body Firewall configuration object (see Fehler! Verweisquelle konnte nicht gefunden werden.) Response body Message object (see Fehler! Verweisquelle konnte nicht gefunden werden.) By invoking this service, the NORM Security Agent is able to instruct the LPA to set the global NORM firewall rules, as perceived to be proper by the CI-SOC components. When instructed to do so, the LPA serially invokes the system firewall services (standard Linux IPtables) to execute each one of the requests. The following figure presents how the relevant service invocation may take place. $ curl -X POST \ http://<NORM_IP>:<LPA_PORT>/firewall \ -H 'Content-Type: application/json' \ -d '{ "puf": "208e57ba4afc479bc9c3507fb5e49449", "rules": [ {"rule": "-F"}, {"rule": "-P INPUT DROP"}, {"rule": "-A INPUT -i lo -j ACCEPT"},

SUCCESS D3.9 v1.0

(80)

{"rule": "-A INPUT -p tcp -m tcp --dport 8080 -j ACCEPT"}, {"rule": "-A INPUT -p tcp -m tcp --dport 22 -j ACCEPT"}, {"rule": "-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT"} ] }' { "msg": "Firewall has been configured" } Figure 38: Configuring the NORM firewall through LPA. 4.4.4.9 Logs Endpoint URL /logs/{number_of_lines} HTTP Method GET Request body N/A Response body Log data object (see Fehler! Verweisquelle konnte nicht gefunden werden.) Table 20: Service path parameters for getting the logs of LPA. Name Type Example Description number_of_lines Int 4 The number of log lines to fetch. When invoked, this service simply returns the last {number_of_lines} lines of log of the LPA component, information that can be useful when dealing with extensive log filtering, to automatically identify whether there are errors in the LPA (hence PUF) functionality or whether unforeseen usage of the LPA has been performed (e.g. from a third party claiming to be a valid CI-SOC KMM). $ curl http://<NORM_IP>:<LPA_PORT>/logs/4 { [ "2018-04-12 12:19:36,315 -- [ key_manager: bootstrap: 252] -- DEBUG -- Successfully updated all CR pairs for vendor.", "2018-04-12 12:19:36,319 -- [ lpa: bootstrap: 260] -- INFO -- Bootstrap executed to vendor", "2018-04-12 12:22:12,487 -- [ lpa: get_logs: 221] -- DEBUG

SUCCESS D3.9 v1.0

(80)

-- [src: 192.168.1.89] Successfully served request for logs.", "2018-04-12 12:22:19,283 -- [ lpa: get_logs: 221] -- DEBUG -- [src: 192.168.1.89] Successfully served request for logs." ] } Figure 39: Acquiring the LPA logs through proper service invocation. 4.4.4.10 Reboot the NORM Endpoint URL /reset HTTP Method POST Request body PUF ID object (see Table 12 ) Response body Message object (see Fehler! Verweisquelle konnte nicht gefunden werden.) Instructs the NORM to reboot. The reboot takes place after 60 seconds from issueing this command. $ curl -X POST -H 'Content-Type: application/json' -d '{"puf": "208e57ba4afc479bc9c3507fb5e49449"}' http://<NORM_IP>:<LPA_PORT>/reset { "msg": "Scheduled reboot in 1 minute" } Figure 40: Using LPA to remotely reboot the NORM. NORM Security Agent Introduction The Security Agent (SecA) is collecting through MQTT messages only the data which is meaningful for security tests in upper level. SecA send also MQTT messages to Critical Infrastructure Security Operations Centre (CI-SOC), for security-related analysis at the upper level. In order to have a simple implementation of SecA, the software module is implemented as an MQTT messaging module which is extracting from the SMG database only the data which has the following characteristics: It does not contain privacy / sensitive end-user information; It is a data which can be used at upper level for making assessments for data received form many places, such that inconsistencies can be detected and flags can be raised to show possible cyber-attacks, Even if SecA can be reparametrized in different ways, we considered for the project scope only the acquisition of voltage and frequency data, which is sent to a CI-SOC for data consistency verifications.

SUCCESS D3.9 v1.0

(80)

Based on our laboratory measurements and using also filed deployed NORM devices, we could analyse on-line data and recorded data of the voltage evolution in different low voltage and medium voltage grids, in University Politehnica of Bucharest (UPB), and in the seven metering points deployed at Electrica and EPG, where there are connected different renewable resources: PV renewable production in UPB, at Stalpu region (EPG operated PVs) and Electrica (Ploiesti and Sibiu region) and small hydro production at Electrica (Busteni in Ploiesti region and Balea Lac in Sibiu region). Figure 41 below shows the voltage acquisition made in NORM devices by SecA, which has been compared during the tests, by simulating DSO-SMC inconsistency assessment. Figure 41 - Voltage evolution recorded in 3 different metering points read by NORM’s SMG It can be seen that NORM2 has a certain deviation in the time window W1, which has been assessed as being normal, considering that this metering point is on the low voltage grid far from the other two NORMs, thus being detected a voltage drop due to a sudden additional load at the level of NORM2. This kind of assessment is not in the scope of this deliverable; however, the example shows the capability of analysing the network status through non-private data acquisition from different NORMs, which need to be assessed with special algorithms at higher level. To be noted that SecA is exchanging data with higher level (e.g. CI-SOC) by using a higher secure VPN, where data is sent with enhanced PUF security encryption, making the channel used for cyber-security highly impenetrable compared with normal communication paths. Security Agent Architecture The Security Agent receive and pre-process values measured by both smart meters and PMU, so that CI-SOC can have more information to analyse. After the reception of detected measures, the Security Agent verifies the consistency of received data, by comparing values obtained by smart meter and PMU and formats received information in messages in the form NORMId valueType timestamp value (PMU/SMM)consistency source Where NORMId is the identifier of the NORM, whose calculation is described below, valueType indicates the type of the measured value, e.g. frequency or voltage, value is the measured value without measurement unit, (PMU/SMM) consistency is a string specifying whether data sent by PMU and SMM are consistent, and source is the component that transmitted data, i.e. PMU or smart meter (SMM). The consistency is evaluated according two predefined thresholds tSIGNAL and tERROR. Let the difference between value detected by SMM and value detected by PMU be vSMM-vPMU; if |vSMM-vPMU|< tSIGNAL the consistency is OK, if tSIGNAL ≤ |vSMM-vPMU| ≤ tERROR the consistency is NOT OK, while if |vSMM-vPMU| > tERROR the consistency is set to ERROR. An example of SecA formatted message is: id frequency 1521205225000 49.986 OK SMM

SUCCESS D3.9 v1.0

(80)

With regard to NORM identifier, PUF can make authentic a NORM in the success solution. In general, a NORM is composed by PUF, SMG and SMM. The Security Agent (SecA), placed into the NORM, has to guarantee the uniqueness and the indivisibility of the ensemble. In other worlds, the SecA creates an identity (id) for each NORM composed by PUF, SMG and SMM. SecA creates a different id for each single NORM, based on three identifiers: PUF id, SMM id and SMG id - RPI serial number (see Figure 42). The SecA generates a hash-based identity (Id) using a function based on the SHA-256 algorithm. Even if just one PUF is enough to guarantee the identification of a NORM into the success solution, once the PUF is plugged in, the NORM is also associated to SMM and RPI, allowing it to be identified in the success solution through the CI-SOC. It is easily provable that just PUF usage can’t guarantee the unique identification of the NORM. In fact, if someone took and plugged the PUF onto another NORM, it will continue to be validated even if it is associated to another NORM having different SMM and RPI. def getserial(): # Extract serial from cpuinfo file cpuserial = "0000000000000000" try: f = open('/proc/cpuinfo','r') for line in f: if line[0:6]=='Serial': cpuserial = line[10:26] f.close() except: cpuserial = "ERROR000000000" return cpuserial Figure 42 – Sample of code As expected, the RPI is not directly connected to the Smart Meter. Hence, it would be easy for someone to unplug it and plug it into another Smart Meter and continue sending the data to CI-SOC; the CI-SOC would not know the difference (as the RPI would be valid). So, the Security Agent (SecA) plays a fundamental role against this kind of incoherence, it allows the association of the PUF, RPI, PMO and SMM all together, by generating a unique authentication towards CI-SOC, using a hash function based on the SHA-256 algorithm. Figure 43 - Hash Function Figure 43 shows the input of the hash function generating the NORM identity. It uses SHA-256 (Secure Hash Algorithm) for generating a random, fixed length 256-bit (32-byte) hash. It is a one-way function – it cannot be reversed (decrypted) back to the original input parameters. The basic idea is to have the hash function both in NORM and CI-SOC as shown in Figure 44. The hash function in placed both in SecA and SecA Driver in NORM and CI-SOC respectively. In the initiating phase, when the NORM is put on line, the SecA generates the NORM_id – function of SMMid, PMUid, RPIid and PUFid - , the NORM_id is stored in SecA and sent to the DSOSMC through SecA. When the SecA Drive catches the NORM_id for the first time, it stores the id in its internal repository. RPI Id #Hash Function NORM IdNORM IdSMM IdPMU IdPUF Id

SUCCESS D3.9 v1.0

(80)

Figure 44 - Security Agent architecture In this respect, if the PUF is removed from NORM and associated to another NORM it will be recognised as new element. In order to make the communication between NORM and CI-SOC more secure, the message will be encrypted. This encryption is performed by the local PUF agent on NORM. The SecA finally sends the encrypted message to CI-SOC via MQTT message. In order to obtain information relevant for its processing, i.e. voltages and frequencies, CI-SOC will then decrypt the received message by interacting with the Key Management Module (KMM), as detailly reported in section 3.1.1. of SUCCESS deliverable D3.6 − Information Security Management Components and Documentation. Additionally, each message contains a hash, generated by the Data Centric Security agent on NORM, from the following data: "norm_ip": IP address of the NORM "request_id": alpha-numeric id of the hash request, "request_ts": timestamp when the hash is requested "norm_data": encrypted NORM data The DCS generates a certificate and a hash that sends back to the Security Agent. The hash is then included as hashed data, together with the request id, in the message that will be sent to CI-SOC. The CI-SOC will then later use these values to verify data integrity by interacting with the Breakout Gateway. The mechanism allows to detect every type of intrusion between NORM and CI-SOC; if the data integrity verification fails, a threat will be issued and then mitigated with a suitable countermeasure. Figure 45 - hashed data generation On top of that, the Security Agent can check firewall rules set in the NORM, mainly after a request by CI-SOC. If this control fails, appropriate countermeasures can be applied by interacting with the local PUF agent on NORM (LPA). NORM Security Administration Agent The Security Administration Agent (SAA) is periodically checking some important aspects of the SMG, such as hash-codes of important parts of the software and of critical files such as essential configuration files (e.g. the Privacy Profile files). To be noted that SAA is exchanging data with higher level (e.g. the administrator in the BR-GW) by using, like SecA, a higher secure VPN, where data is sent with enhanced PUF security encryption, making the channel used for cyber-security highly impenetrable compared with normal communication paths.

SMMPMU RPI(SMX/SMG)Security Agent(SecA)# #(NORM_Id, PMU_msg, RPI_msg)OpenVPMID-MSG MQTT= (ID_MSG, MSG) MQTT #Security Agent(SecA)Private Key Provenance Manager Tool Key Managementother DSOSMC modules PMU_msg, RPI_msgNORM_Id DSOSMCNORM_IdPMU_msg, RPI_msg Integration APIPublic Key NORM_Id

SUCCESS D3.9 v1.0

(80)

5. Test plan for individual components The goal of this section is to describe the strategy and plan that has been followed in the realization of the individual single component testing the belong to WP3, namely NORM and the CI-SOC. To that end, we: introduce a common formalization list of terms for the well-defined definition of tests. Brief introduction about protocols that will be used between CI-SOC and NORM define the typology of features that will be tested during the individual test phase. define a preliminary plan describing test of NORM and CI-SOC. Individual module testing refers to the testing of the individual system components with respect to the requirements. After all modules are verified, then the integration will begin and when it is completed, a final set of tests will be performed. BASIC SMG software BASIC SMG software refers to the following main components: - The SMXCore, which is the basic software around which all applications are running. It contains: o the realtime database o software connectors to external actors, based on MQTT messages; the connectors have an internal RBAC system which allows that only selected data can be sent or received from a specific agent o drivers for energy meters, acting as Smart metrology meters; o other internal functions, such as SMX internal daily records for in-deep analysis - The Security Agent, which is one of the agents, acting as data extractor for the upper levels, such as CI-SOC - Driver for PMU integration - Software for classic OpenVPN connectivity - Software for the PUF security mechanism needed on NORM side Different tests have been made and the SMX internal daily records for in-deep analysis has been extensively used for different analysis, to show proper functionality of the acquisition. Figures 46 and 47 below provide a comparison made for the frequency evolution between three NORM measurements across continental Europe, namely in two metering point in Romania (one PV plant and one hydro-plant) and a metering point in Terni, Italy.

Figure 46 - Frequency records on a full day

SUCCESS D3.9 v1.0

(80)

Figure 47 - Details with the records in the first hour of the same day It can be seen that the acquired data, which is locally stored in each NORM, shows by superposition a good coherence in frequency evolution, which is a prerequisite for CI-SOC and higher levels to analyse this grid information and to be able to detect suspicious data and then to start applying countermeasures. Moreover, the records prove a good synchronisation between the three NORMs through internet, even if they are geographically far located. Security Agent Security agent package have been tested by parametrising the MQTT client to send voltage and frequency data at a certain time interval. The following tests have been made: - The SecA data is arriving to a CI-SOC module This test shows the availability of SecA to provide necessary data to upper level of security monitoring center - Any attempt from CI-SOC for obtaining other data (by subscribing to the Mosquitto broker) is un-successful. This test showed that private data is well kept and cannot be obtained with un-authorised requests. This characteristic is supported by the RBAC system incorporated in SMXcore. PUF functionality The PUF-enabled hardware security features have been tested on both hardware and software (local PUF agent) in combination with the CI-SOC Key Management module as to its capabilities to: Test the bootstrapping and challenge-response pairs updating of PUF; Test the ability of PUF to implement NORM authentication/authorization against the CI-SOC Key Management module, effectively offering uniqueness characteristics on the NORM identification processes; Deliver encryption/decryption services to the rest of the NORM services. The tests have been carried out on non-production environments and will ensure that the hardware security features of the NORM are robust, fulfilling the strict security requirements of NORM. PTP synchronisation PTP synchronisation have been tested against a counter-machine which is able to provide a GPS time synchronisation. As the level of time accuracy is at microseconds level or less, the following simple test schema will be used:

SUCCESS D3.9 v1.0

(80)

Figure 48 – Test schema A NORM Raspberry Pi3 board with the PTP module installed was prepared, along with a local PTP grandmaster (GM) clock (sourced through a secondary RPI3 board synchronized by a NMEA-PPS GPS receiver model L80GPS), with Gigabit Ethernet path connected to NORM board and a digital oscilloscope for assessing the maximum jitter between the PPS from the two sources. An additional CPU board (Variscite I.MX7 SOM module), featuring the hardware timestamp, was used to compare the performance differences with NORM Raspberry Pi3, which instead supports only software timestamps. The overall performance of the SMG implementation of PTP, tested with a GPS based master clock were in line with expectations, as summarized by the following table, showing the jitter between the master clock and SMG and another reference board (Variscite SOM I.MX7, featuring hardware timestamping) have same rms values: Figure 49 – PTP implementation The NORM RPi3 results were the following (see Figure 50): Offset rms = 7.9us Offset min = -132us Offset max = 208us

SUCCESS D3.9 v1.0

(80)

Figure 50 – NORM RPI3 software time-stamped results The comparative hw-timestamped board results were the following (see Figure 51): Offset rms = 7.9us Offset min = -159us Offset max = 157us

Figure 51 – Hardware time-stamped solution results Low cost PMU Low cost PMU (LCPMU) has been tested for compliance with the IEEE Std C37.118.1-2011 [7] and IEEE Std C37.118.1a-2014 [8]. The testing aimed at certify compliance with the steady state conditions of the class M PMUs, as defined in the IEEE Std C37.118.1-2011 andC37.118.1a-2014 standards, evaluating the maximum of Total Vector Error (TVE), Frequency Error (FE) and ROCOF Error (RFE) values. The test procedures are based on the standard IEEE Std C37.242-2013 [9] for the procedures to assess steady-state compliance of a PMU. In this respect, it will be tested that LCPMU is providing at reporting rates of one second the voltage levels and the voltage angles as well as the value of the network frequency.

SUCCESS D3.9 v1.0

(80)

The tests on voltage magnitude required to check the output of the PMU versus the input when the voltage magnitude spans over a range of 80% to 120 % of the nominal voltage. The test results are shown in Figure 52. Figure 52 - TVE, ME and PE for test with magnitude variation In the test with the phase angle variation the values are kept constant for 6 seconds, during the test phase, and increased by 0.3 radians each time, until a complete turn of 2π occurs. The test results are shown in Figure 53. Figure 53 - TVE, ME and PE for test with phase angle variation During the frequency variation tests, the signal magnitude, phase and frequency are kept constant, while the frequency is increased by 0.1 Hz each time to cover the range between 48 and 52 Hz. The test results are presented in Figure 54.

SUCCESS D3.9 v1.0

(80)

Figure 54 - TVE, ME and PE for test with frequency variation Finally, for the harmonic’s tests, a signal generator creates multiple harmonics, from the 2nd till the 50th of the nominal frequency. The magnitude of the harmonics is 10 % of the magnitude of the nominal input magnitude. These signals are generated in conjunction with a signal at nominal magnitude and frequency. The test results are presented in Figure 55. Figure 55 - TVE, ME and PE for test with different harmonic contributions It is possible to verify that the specification of the IEEE standard for M class, that is Max TVE = 1%, is always respected. A more detailed description of the test setup and the obtained results is included in [10]. EMC immunity test for PUF EMC has been tested and evaluated according to the CISPR 1270_INF guidance for equipment connected to smart grids. Specifically, SMG can be treated as a data concentrator device, whose reference standards are the following:

EN61000-6-2 – Immunity for industrial environment EN61000-6-4– Emission for industrial environment EN60950-1 IT Equipment – Safety (Cat IV 300 V, reinforced insulation, pollution degree 2).

SUCCESS D3.9 v1.0

(80)

With specific reference to EMC test for PUF, the following three ports of SMG can be considered: 1. Enclosure port 2. Primary AC power supply input 3. Wired network port (cable length < 10m) Moreover, the proper acceptance criterion to consider is A, which means that the device shall continue to operate as required during and after the test and no performance degradation below the indicated level is allowed. Consequently, the following table resumes the EMC test to apply for EMC PUF immunity conformance: Table 21 – EMC tests Immunity test Reference Standard Test Limit Notes Port Acceptance Criterion Power frequency magnetic field IEC 61000-4-8 30A/m continuous Orientation on three axes x, y, z Port 1 A Radiated radio frequency electromagnetic field from 80MHz to 1GHz IEC 61000-4-3 10V/m Port 1 A Radiated radio frequency electromagnetic field from 1.4GHz to 2.0GHz IEC 61000-4-3 3V/m Port 1 A Radiated radio frequency electromagnetic field from 2.0GHz to 2.7GHz IEC 61000-4-3 1V/m Port 1 A Electrostatic discharge IEC 61000-4-2 4KV contact 8KV in air Port 1 A Conducted disturbances from 150KHz to 80MHz IEC 61000-4-6 10V Common mode Port 2, 3 A Fast transient IEC 61000-4-4 1KV Common mode Port 2 A 1KV Common mode Port 3

SUCCESS D3.9 v1.0

(80)

Surge IEC 61000-4-5 1KV Line to Line Port 2 A 2KV Line to Ground Power supply dips IEC 61000-4-11 70%Vn 25 cycles Port 2 A 40% Vn 10 cycles 0% Vn 1 cycle A NORM RPi3 board equipped with LOGI-Pi Fpga board was prepared and assembled into a suitable case, with an internal power supply and cable glands, for data line and other possible additional wires: Figure 56 – NORM RPi3 assembly for tests A pass/no pass test file was realized, that when run, should indicate whether everything is good or not. The test can be invoked by calling the test_PUF.sh file in the home directory: pi@raspberrypi-puf:~ $ ls Desktop Downloads Music Public Templates Videos Documents logi-tools Pictures python_games test_PUF.sh The normal output should be as follows: pi@raspberrypi-puf:~ $ ./test_PUF.sh sudo: unable to resolve host raspberrypi-puf LOGI_LOADER VERSION : 0.1.0 Compiled for LOGI-PI Board variant is LOGIPI_R1.5

SUCCESS D3.9 v1.0

(80)

bit file size : 341256 bitstream loaded, check done led ======================================== test session starts ======================================== platform linux2 -- Python 2.7.13, pytest-3.4.2, py-1.5.3, pluggy-0.6.0 rootdir: /home/pi/Documents/success/puf-client/rPI/API/test, inifile: collected 1 item test_NORMG2F2T1.py . [100%] ===================================== 1 passed in 30.50 seconds ===================================== /home/pi The immunity tests are executed at the laboratory “Tecnolab del Lago Maggiore” located at Verbania (VB) – Italy (Accreditation Certificate no. 0991 by Accredia). Tests are still in progress, according to the internal laboratory tasks program.

SUCCESS D3.9 v1.0

(80)

6. Potential future work NORM is an open platform where appropriate meters and new low-cost PMUs are integrated with the support of its Smart Meter Gateway, bringing new functionalities needed for smart energy grid support and for an enhanced cyber-security, as part of essential feature which are needed in real-time monitoring and control of critical infrastructures. NORM can be implemented as a new stand-alone meter (when equipped with the proper metrology and hard-real time features) or can be used to expand legacy meters with more functionalities and securities and with added hard real time features such as PMU functionality. In this sense, SUCCESS offers an open solution compatible with the past but open to future developments. As NORM needs further steps in promoting it at commercial scale, where the architecture need further integration activities in order to reach a cost-effective product, the plans for next period are to use the architecture in more types of business cases, and to enrich functionalities in order to accommodate new technologies, such as 5G and blockchain, as enablers for new entities such as microgrids, local energy communities and local energy and ancillary services markets, for a decentralized and low carbon energy ecosystem. One of the examples is the use of NORM in a new H2020 project, named NRG5, where both 5G technologies and blockchain are integrated and new use-cases are tested, using as enabling platform NORM. Additionally, compatibility with Internet of Things (IoT) standards will be also considered in the future, as supplementary pathways for future work. The SMXcore open-source GPL-based solution is a prerequisite for further developments to be made by project partners or by other interested developers, for direct real-life applications or for progressing towards functionalities needed in near future (blockchain or others) In this respect, NORM can be considered as a next generation smart meter, which covers complex functionality at end-points of the smart grids, giving appropriate platform solution to be exploited for the evolving energy grid needs.

SUCCESS D3.9 v1.0

(80)

7. References [1] C. Herder, M.-D. Yu, F. Koushanfar and S. Devadas, “Physical Unclonable Functions and Applications: A Tutorial,” in Proceedings of the IEEE, 2014. [2] Xilinx, “Spartan-6 FPGA Family,” Xilinx, [Online]. Available: https://www.xilinx.com/support/documentation/selection-guides/cost-optimized-product-selection-guide.pdf#S6. [Accessed Mar. 2017]. [3] Raspbian, “Welcome page,” [Online]. Available: https://www.raspbian.org. [Accessed Mar. 2017]. [4] Flask, “Welcome page,” [Online]. Available: http://flask.pocoo.org. [Accessed Mar. 2017]. [5] SUCCESS, “Deliverable D3.4: Information Security Management Components and Documentation V1.0,” 2017. [6] D. Spinellis, “15 Rules for Writing Quality Code,” 9 06 2014. [Online]. Available: http://www.informit.com/articles/article.aspx?p=2223710. [Accessed 17 09 2014]. [7] C. Alexander, S. Ishikawa, M. Silverstein, M. Jacobson, I. Fiksdahl-King and S. Angel, A Pattern Language, Towns, Buildings, Construction, New York: Oxford University Press, 1977. [8] “Cloud Patterns,” [Online]. Available: http://cloudpatterns.org/. [Accessed Jan. 2017]. [9] “Big Data Patterns,” [Online]. Available: http://www.bigdatapatterns.org/. [Accessed Jan. 2017]. [10] SUCCESS, “Deliverable D3.4: Information Security Management Components and Documentation v1,” 2017. [11] FIWARE, “Cygnus,” [Online]. Available: https://github.com/telefonicaid/fiware-cygnus. [Accessed Jan 2017]. [12] Wikipedia. [Online]. Available: https://en.wikipedia.org/wiki/Software_test_documentation. [Accessed 10 January 2017]. [13] “. 2. S. T. The International Software Testing Standard. [Online]. Available: http://www.softwaretestingstandard.org/. .

SUCCESS D3.9 v1.0

(80)

[Accessed 10 September 2014]. [14] NOBEL GRID, “D1.1-Distribution grid and retail market requirements definition,” 2015. [15] NOBEL GRID, “D1.2-Distribution grid and retial market scenarios and use cases definition,” 2015. [16] European Union, “RECTIVE 2014/32/EU OF THE EUROPEAN PARLIAMENT AND OF THE COUNCIL of 26 February 2014 on the harmonisation of the laws of the Member States relating to the making available on the market of measuring instruments (recast),” Offical Journal of the European Union, 2014. [17] E. Union, “RECTIVE 2014/32/EU OF THE EUROPEAN PARLIAMENT AND OF THE COUNCIL of 26 February 2014 on the harmonisation of the laws of the Member States relating to the making available on the market of measuring instruments (recast),”,” Official Journal of the European Union, 2014. [18] SUCCESS, “Deliverable D3.7 : Next Generation Smart Meter V1,” 2017. [19] SUCCESS, “Deliverable D3.11: Integration and Validation Plan. Test and certification specifications v2,” 2017. [20] SUCCESS, “Deliverable 3.12 : Integration and Validation Plan. Test and certification specifications v3,” 2018. [21] SUCCESS, “Deliverable D4.7 : Integration and Validation Plan. Test and certification specifications v1,” 2017. [22] SUCCESS, “Deliverable D4.8 : Integration and Validation Plan. Test and certification specifications v2,” 2017. [23] SUCCESS, “Deliverable 4.9 : Integration and Validation Plan. Test and certification specifications v3,” 2018. [24] M. J. a. M. L. S. Harrold, “An incremental approach to unit testing during maintenance.,” Software Maintenance,, 1988. [25] K. Beck, Test-driven development: by example, Addison-Wesley Professional, 2003. [26] T. Ostrand, White‐Box Testing, Encyclopedia of Software Engineering, 2002. [27] B. Beizer, Black-box testing: techniques for functional testing of software and systems., John Wiley & Sons, Inc., 1985.

SUCCESS D3.9 v1.0

(80)

[28] M. E. a. F. K. Khan, “A comparative study of white box, black box and grey box testing techniques.,” International Journal of Advanced Computer Science and Applications (IJACSA), 2012. [29] H. K. a. L. W. Leung, “A study of integration testing and software regression at the integration level.,” Software Maintenance, 1990, Proceedings., Conference on.IEEE, 1990. [30] “Protection of personal data,” [Online]. Available: http://ec.europa.eu/justice/data-protection/. [31] “REGULATION (EU) 2016/679 OF THE EUROPEAN PARLIAMENT AND OF THE COUNCIL,” [Online]. Available: http://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32016R0679. [32] IEC, “62056-6-2:2013,” 201. [Online]. Available: https://webstore.iec.ch/publication/6410. [Accessed 20 12 2016]. [33] N. a. B. J. C. Saxena, “State of the art authentication, access control, and secure integration in smart grid,” Energies, 2015. [34] S. Feuerhahn, M. Zillgith, C. Wittwer and C. Wietfeld, “Comparison of the communication protocols DLMS/COSEM SML IEC 61850 for smart metering applications,” in Smart Grid Communications (SmartGridComm), 2011 IEEE International Conference on. IEEE, Bruxelles. [35] “ OpenADR and Cyber Security,” [Online]. Available: http://www.openadr.org/cyber-security. [Accessed 20 12 2016]. [36] SUCCESS, “Deliverable D4.4: Description of available components for SW functions, infrastructure and related documentation v1,” 2017. [37] S. Tajik, E. Dietz, S. Frohmann, J.-P. Seifert, D. Nedospasov, C. Helfmeier, C. Boit and H. Dittrich, “Physical characterization of Arbiter PUFs,” in 16th International Workshop on Cryptographic Hardware and Embedded Systems, New York, 2014. [38] C. Gu, J. P. Murphy and M. O'Niell, “A unique and robust single slice FPGA identification generator,” in IEEE International Symposium on Circuits and Systems, Melbourne, Victoria, Australia, 2014. [39] S. S. Kumar, J. Guajardo, R. Maes, G. J. Schrijen and P. Tuyls, “The butterfly PUF: protecting IP on every FPGA,” in IEEE International Workshop on Hardware-Oriented Security

SUCCESS D3.9 v1.0

(80)

and Trust, Anaheim, CA, USA, 2008. [40] G. E. Suh and S. Devadas, “Physical unclonable functions for device authentication and secret key generation,” in Proceedings of the 44th annual Design Automation Conference, 2007. [41] Dr. Helge Kreutzmann, M.Sc. Stefan Vollmer. Protection Profile for the Gateway of a Smart Metering System (Smart Meter Gateway PP), v 1.3. s.l. : Federal Office for Information Security, 2014. BSI-CC-PP-0073

SUCCESS D3.9 v1.0

(80)

8. List of Abbreviations BR-GW Breakout Gateway BSF Bootstrapping Server Function CA Certificate Authority CI-SAN Critical Infrastructure Security Analytics Network CI-SOC Critical Infrastructure Security Operations Centre G-SMG German Smart Meter Gateway (named also SMGW in the German SMG) DCS Data Centric Security DEMS Decentralised Energy Management System DoS Denial of Service DDoS Distributed Denial of Service DE-SMIS Distributed instance of European Security Monitoring and Information System DSO Distribution System Operator E-SMIS Security Monitoring and Information System NAN Neighbourhood Area Network NORM New-generation Open Real-time Smart Meter NORM-SMG NORM Smart Meter Gateway PMU Phasor Measurement Unit PUF Physically Unclonable Function SCADA Supervisory Control and Data Acquisition SecA Security Agent running in NORM’s SMG SMG Smart Meter Gateway SMGW Smart Meter Gateway (abbreviation of German Smart Meter Gateway/G-SMG) SMM Smart Meter Gateway SMX Smart Meter eXtension TOE Target of Evaluation (used for the German Smart Meter Gateway) USM Unbundled Smart Meter

SUCCESS D3.9 v1.0

(80)

9. List of Figures Figure 1 – Unbundled meter systematisation ................................................................................ 8 Figure 2 - Unbundled meter connected to different networks ....................................................... 9 Figure 3 – NORM unbundled concept ......................................................................................... 10 Figure 4 – Database centric architecture .................................................................................... 11 Figure 5 – Privacy profiles ........................................................................................................... 12 Figure 6 – NORM-SMG and actors’ interaction through RBAC system ...................................... 12 Figure 7 – Low Cost PMU data flow ............................................................................................ 14 Figure 8 - The G-SMG architecture general overview ................................................................ 17 Figure 9 - Energy Gateway environment in [41] .......................................................................... 18 Figure 10 - Possible TOE Design: One Box Solution from the German SMGW PP concept with mappings to the SUCCESS NORM ............................................................................................ 19 Figure 11 - SMGW design, minimal implementation and its mappings to the SUCCESS NORM ..................................................................................................................................................... 20 Figure 12 – The Security Agent in the SMG architecture and its interconnections .................... 23 Figure 13 – Communication security level for various types of actors ........................................ 24 Figure 14: PUF FPGA architecture ............................................................................................. 27 Figure 15 – Voltage variation records with Wally A meter .......................................................... 29 Figure 16 – Frequency variation records with Wally A meter ..................................................... 29 Figure 17 – Voltage variation records on phase 1, with A1800 meter ........................................ 30 Figure 18 – Frequency variation records with A1800 meter ....................................................... 30 Figure 19 – Voltage variation records over an entire day at a PV plant in Romania .................. 31 Figure 20 – Frequency variation records over an entire day at a PV plant in Romania ............. 31 Figure 21 – Voltage variation records over an entire day at a hydroplant in Romania ............... 32 Figure 22 – Frequency variation records over an entire day at a hydro plant in Romania ......... 32 Figure 23 - Flowchart of LCPMU real time operation .................................................................. 33 Figure 24 – RBAC system, controlling data exchange with different actors. .............................. 34 Figure 25 – Clients connection to SMXCore real-time database through MQTT clients and broker .......................................................................................................................................... 35 Figure 26 – Example of SMXCore with two types of actors, having different privacy profile (PP). ..................................................................................................................................................... 35 Figure 27 – Interface between LCPMU and Smart Meter Gateway ............................................ 37 Figure 28 – PTP domain ............................................................................................................. 38 Figure 29 – PTP4L architecture .................................................................................................. 38 Figure 30: Overall PUF architecture. ........................................................................................... 39 Figure 31: Getting the API documentation of the LPA. ............................................................... 45 Figure 32: Getting the ID of the PUF. .......................................................................................... 45

SUCCESS D3.9 v1.0

(80)

Figure 33: Retrieving the LPA-supporting utilities. ...................................................................... 46 Figure 34: Updating the challenge for utility with id "utility". ........................................................ 47 Figure 35: Instructing the LPA to bootstrap the PUF to a utility. ................................................. 47 Figure 36: Invoking the encryption services of the LPA. ............................................................. 48 Figure 37: Verifying the PUF authenticity. ................................................................................... 49 Figure 38: Configuring the NORM firewall through LPA. ............................................................ 50 Figure 39: Acquiring the LPA logs through proper service invocation. ....................................... 51 Figure 40: Using LPA to remotely reboot the NORM. ................................................................. 51 Figure 41 - Voltage evolution recorded in 3 different metering points read by NORM’s SMG ... 52 Figure 42 – Sample of code ........................................................................................................ 53 Figure 43 - Hash Function ........................................................................................................... 53 Figure 44 - Security Agent architecture ....................................................................................... 54 Figure 45 - hashed data generation ............................................................................................ 54 Figure 46 - Frequency records on a full day ............................................................................... 55 Figure 47 - Details with the records in the first hour of the same day ......................................... 56 Figure 48 – Test schema ............................................................................................................. 57 Figure 49 – PTP implementation ................................................................................................. 57 Figure 50 – NORM RPI3 software time-stamped results ............................................................ 58 Figure 51 – Hardware time-stamped solution results.................................................................. 58 Figure 52 - TVE, ME and PE for test with magnitude variation ................................................... 59 Figure 53 - TVE, ME and PE for test with phase angle variation ................................................ 59 Figure 54 - TVE, ME and PE for test with frequency variation .................................................... 60 Figure 55 - TVE, ME and PE for test with different harmonic contributions ................................ 60 Figure 56 – NORM RPi3 assembly for tests ............................................................................... 62

SUCCESS D3.9 v1.0

(80)

10. List of Tables Table 1 - Today state of the art smart meters and NORM functionalities ................................... 16 Table 2 - Communication flows between devices in different networks ..................................... 21 Table 3 - Table 2: SPI Message format ...................................................................................... 26 Table 4 - SPI Header format ....................................................................................................... 26 Table 5 - Minimum hardware and software requirements for running the local PUF agent. ...... 41 Table 6 - API service model ........................................................................................................ 41 Table 7 - Doc model .................................................................................................................... 42 Table 8 - Challenge model .......................................................................................................... 42 Table 9 - Message model ............................................................................................................ 42 Table 10 - Data model ................................................................................................................. 42 Table 11 - Encoded data model .................................................................................................. 42 Table 12 - PUF ID model ............................................................................................................. 43 Table 13 - Log data model .......................................................................................................... 43 Table 14 - Firewall rule data model ............................................................................................. 43 Table 15 - Firewall configuration model ...................................................................................... 43 Table 16: Service path parameters for updating the active PUF challenge for a Utility. ............. 46 Table 17: Service path parameters for bootstrapping the PUF against a Utility. ........................ 47 Table 18: Service path parameters for encoding a certain piece of data.................................... 48 Table 19: Service path parameters for verifying a PUF. ............................................................. 48 Table 20: Service path parameters for getting the logs of LPA. ................................................. 50 Table 21 – EMC tests .................................................................................................................. 61

SUCCESS D3.9 v1.0

(80)

Annex A. List of data subject of being reported by NORM-SecA to CI-SOC A.1 Real-time data validation (cases named RTxx) Code Description Source Observations Reporting rate Privacy aspects (incl. critical data) RT01 Voltages1 of the energy meter (EM) Inputs from EM T0068ey need to be in certain range Each 1, 10 up to 60 seconds Voltage is a network data, so it is not subject of end-customer privacy RT02 Voltages1 of the PMU Inputs from PMU They need to be in certain range Each 1, 10 up to 60 seconds RT03 ΔUEM-PMU = UEM(t1) – UPMU(t1) (Comparison between UEM and UPMU measured at the same time) Simple processing based on RT01 and RT02 They need to be similar Each 10 up to 60 seconds No privacy concern RT04 ΔUEM = UEM(t2) - UEM(t1) (Change of voltage level over a certain time window ΔUEM = UEM(t2) - UEM(t1)) Simple processing based on RT01 High ΔU may indicate network disturbance Event based On request No privacy concern RT05 Angles between voltages in energy meters Inputs from EM They need to be near to 120 grd Event based, on request No privacy concern RT06 Angles between voltages in PMU Inputs from PMU, simple processing from “angles of voltages” Angles between voltages need to be near to 120 grd Event based, on request No privacy concern

SUCCESS D3.9 v1.0

(80)

RT07 ΔφEM-PMU = φEM(t1) – φPMU(t1) Comparison between angles φEM and φPMU measured at the same time) Simple processing based on RT05 and RT06 They need to be similar Each 10 up to 60 seconds No privacy concern RT08 Frequency of the system (EM) Inputs from EM, e.g. each 1 second Needs to be in certain range and thresholds apply for alarm Each 1, 10 up to 60 seconds No privacy concern RT09 Frequency of the system (PMU) Inputs from PMU, e.g. each averages for each 1 second Needs to be in certain range and thresholds apply for alarm Each 1 second No privacy concern RT10 ΔfEM-PMU = fEM(t1) – fPMU(t1) (Comparison between fEM and fPMU measured at the same time) Simple processing based on RT09 and RT10 They need to be similar Each 10 seconds No privacy concern Etc. 1 The total number of voltage measurements in a 3-phased system is: U1, U2, U3 (voltages on each phase), U12, U23, U31 (voltages between phases) and U0 (voltage to earth). Depending on power network scheme, on the meter connection scheme and on the meter ability to calculate some measurements from measured values, the availability of these measurements is different from case to case (network, connection scheme, meter functionality). The minimal number of voltages to be monitored is 3 for the 3-phase meters (U1, U2 and U3) and one for the mono-phased meter. On medium voltage (MV) it might be necessary to decide the voltages to be analysed between voltage on each phase (U1, U2, U3) and voltages between phases (U12, U23, U31). Moreover, V0 can be also selected as being a monitored information. 2 (S+A) means signalization or alarm. The monitored measurements need to have defined levels of signalization (for the reason of drawing the attention on some deviation which is not yet an abnormal situation) and levels of alarm (which mean clear abnormal situation). To be noted that the events need to be generated

SUCCESS D3.9 v1.0

(80)

after using filtering and hysteresis, in order to avoid bursts of events during the stay of the system around the defined levels. This processing may be part of specific NORM-SecA A.2 Communication on Public IP Networks (PIPN) such as Internet (cases CPIPxx) Code Description Source Observations Reporting rate to DSO Privacy aspects CPIP01 List of established communications with remote actors, by type of actor IP Connection manager for sandboxed connections with PIPN Type of actors: DSO, supplier, ESCO, End-user Private CPIP02 Average traffic each 1 minute / 15 minutes / 1 hour / one day for each actor connected to SMG IP Connection manager for sandboxed connections with PIPN Similar Private CPIP03 Peak traffic for a specific actor connection (time window to be defined) IP Connection manager for sandboxed connections with PIPN Similar Private CPIP04 Last time when credentials have been changed Credential manager for a specific VPN connection Similar Private CPIP05 Last time when the active challenge/response part was Key Manager at the DSO Security Depends on whether strong/weak PUF will Private

SUCCESS D3.9 v1.0

(80)

changed Monitoring Centre be employed. Etc. A.3 3. SMG Internal Database access Code Description Source Observations Reporting rate to DSO Privacy aspects DB01 List of communication links established by actors’ local agents with the internal DB, by type of actor Role Base Access Control (RBAC) manager Type of actors: DSO, supplier, ESCO, End-user Private DB02 Average traffic each 1 minute / 15 minutes / 1 hour / one day for each actor connected to DB or aggregated Role Base Access Control (RBAC) manager Similar Private DB03 Peak traffic for a specific actor connection (time window to be defined) or for the aggregation Role Base Access Control (RBAC) manager Similar Private DB04 Number and type of errors in syntax/parsing the DB requests (JSON, XML etc.) Trusted zone application (as system data of the App) Similar Private Etc.

SUCCESS D3.9 v1.0

(80)

A.4 SMG System health (SyHxx) Code Description Source Observations Reporting rate to DSO Privacy aspects SyH01 Average system load on a certain period (e.g. 15 minutes) Linux standard information A certain agent is “consuming” the computation resource of SMG Each time it is overpassed a threshold Private SyH02 Reduction in the Linux system storage capacity under a certain limit Linux standard information A certain agent is “consuming” the storage resource e.g. each day Private SyH03 Rate of reduction in Linux system storage capacity over a certain value in a defined time window Simple processing on Linux standard information A certain agent is “consuming” too quick the storage resource e.g. each day Private Etc. A.5 SMG Commands validation (CMDxx) Code Description Source Observations Reporting rate to DSO Privacy aspects CMD01 Request for connection of the meter’s breaker Application in trusted zone of SMG, which communicate with the It should show a pattern of simultaneous Event based No, it is a DSO order based on DSO rules approved

SUCCESS D3.9 v1.0

(80)

EM connection commands by National Regulatory Agencies CMD02 Request for disconnection of the meter’s breaker Application in trusted zone of SMG, which communicate with the EM It should show a pattern of simultaneous connection commands Event based No, it is a DSO order based on DSO rules approved by National Regulatory Agencies CMD03 Etc. Etc. A.6 Anti-tampering events (ATEVxx) Code Description Source Observations Reporting rate to DSO Privacy aspects ATEV01 Attempt to uncover the terminals (wirings) cover of the meter Energy Meter (EM) mechanical sensor It can show unusual physical intrusion Event based ATEV02 Attempt to change the measuring accuracy by using magnets (disturbing magnetic field) Energy Meter (EM) magnetic field sensor It can show unusual distortion of physical measurements Event based ATEV03 Attempt to open the NORM case Mechanical switch It can show unusual physical intrusion Event based

SUCCESS D3.9 v1.0

(80)

ATEV04 Etc. A.7 Power System Metada (PMdxx) Code Description Source Observations Reporting rate to DSO Privacy aspects PMdD01 Network configuration Parameterization Voltage level UN Treatment of neutral (earthed, treated earth with coli or resistor etc) At start-up, on demand, on event (to be defined the event) PMd02 Meter / PMU wiring connections Parameterization 3 wires, 4 wires At start-up, on demand, on event (to be defined the event) PMd03 Mono-phased connection to phase K Automatic or param. For mono-phased meters it is important to know on which phase it is connected At start-up, on demand, on event (to be defined the event) A.8 Other category (YYYxx) Code Description Source Observations Reporting rate to DSO Privacy aspects YYY01 To be defined (tbd), based on

SUCCESS D3.9 v1.0

(80)

necessary functionality in the future YYY02 (tbd) YYY03 (tbd) Obs: Only codes (YYY) of this category have been defined at this stage List of data subject of NOT being reported by NORM-SecA to CI-SOC The following list addresses data which can be subject of European laws related to data protection and privacy 1. Real-time data validation (cases named NOT-RTxx) Code Description Source Observations Reporting rate Privacy aspects (incl. critical data) NOT-RT01 Active power (P) of the energy meter Inputs from EM This can be used only by end-user or by his delegated ESCO Each 1 to 10 seconds Private data for residential metering Possible mitigation through aggregation