Leveraging DLTs for Secure and Persistent Communications in the PHOENIX Platform
In the PHOENIX platform architecture, Secure and Persistent Communications (SPC) layer, as also reflected in its name, offers security over legacy protocols, as well as data persistency. More precisely, the SPC layer adopts a data-centric approach based on federated Distributed Ledger Technologies (DLTs) to achieve a higher degree of persistency, traceability, availability, integrity and interoperability in the context of data communications. Since different ledger technologies meet different needs, for instance, the ledgers aimed for asset and access control management are preferably chosen from permissioned ledgers with the purpose of achieving cost reduction, whereas public ledgers are widely used for trade and making payments due to their high level of trustworthiness. Therefore, beyond usage of DLTs within SPC layer, different components of the PHOENIX platform can also leverage the use of DLT as a persistent and immutable data storage.
Concerning the utilization of multiple ledgers simultaneously within the PHOENIX platform, it is imperative to develop a distributed and resilient solution for interconnecting varying ledger networks, which are also suitable for critical Electrical Power and Energy System (EPES) assets and data. For enabling interaction among differing DLTs, several mechanisms such as Atomic cross-chain transactions, Bridging and Ledger-of-ledger approaches were proposed in the literature [1]. As part of the SPC layer, it will also contain the so-called inter-ledger component, which is developed on basis of the atomic cross-chain transactions approach. The inter-ledger component facilitates the integration of multiple ledgers, which results in a cohesive storage platform, where different types of the ledgers can be used simultaneously to benefit from the strengths of various ledger types and to combat their possible shortcomings.
For better understanding, let’s consider the Information Incidents Sharing Platform (I2SP) component in the PHOENIX platform, which is aiming to bridge the gap between national and global Computer Emergency Response Teams (CERTs), Transmission System Operators (TSOs), Distribution System Operators (DSOs) and grid operators. I2SP would be instantiated as a distributed platform comprising one or more ledgers, where each stakeholder can establish agreements and share Cyber Threat Information (CTI), such as cyber-attacks, with others reliably and transparently through the inter-ledger component.
In the PHOENIX platform, DLTs are mainly used for storing CTI, but not operational data such as metering information due to the immutable nature of data records on ledgers. More accurately, operational data may not be stored on DLTs since this operation can lead to violating GDPR compliance (e.g., the right to be forgotten for personal data). Furthermore, CTI which is generated within the PHOENIX platform, cannot be freely shared with everyone, especially with users outside of EPES infrastructures. Thereby, private permissioned DLTs are considered as an appropriate data storage for the PHOENIX platform, because in such ledgers a designated organization controls the access rights to data records and only certain nodes are authorized to publish data on the ledger networks. On contrary, public permissionless DLTs do not fulfill the privacy requirements of the PHOENIX platform because they allow any user to join ledger networks and carry out varying transactions, such as read and write on data records. For this reason, Quorum and Hyperledger fabric, which both fall into the category of the private ledgers, will be utilized in the PHOENIX platform.
The main specification work for the SPC layer was carried out in the spring and summer of 2020 as a joint effort between the partners of WP2, with valuable contributions also from members outside WP2. The work was finalized by end of summer – without being much affected by the global covid-19 pandemic – and the results were documented in D2.2 [2]. Since then work has evolved towards implementation and planning for the first actual prototyping activities.
[1] V. Siris, P. Nikander, S. Voulgaris, N. Fotiou, D. Lagutin and G. Polyzos, “Interledger Approaches,” in IEEE Access, vol. 7, pp. 89948-89966, doi: 10.1109/ACCESS.2019.2926880., 2019.
[2] PHOENIX, “D2.2 Secure and Persistent Communication Layer,” H2020 – 832989 – PHOENIX Deliverable Report, 2020.