Last Will Letter: A Secure Federated P2P Scheme for Blockchain-Oriented Virtual Redundancy and Backup

Received 3 September 2025, accepted 20 September 2025, date of publication 13 October 2025, date of current version 21 October 2025. Digital Object Identifier 10.1109/ACCESS.2025.3621074 Last Will Letter: A Secure Federated P2P Scheme for Blockchain-Oriented Virtual Redundancy and Backup CESAR A. CAZAL 1, (Graduate Student Member, IEEE), SU MON TUN 1, (Graduate Student Member, IEEE), LEONARDO LEONZI D’ALESSANDRO2, STEFAN LANKES 1, FERDINANDA PONCI 1, (Senior Member, IEEE), AND ANTONELLO MONTI 1,3, (Senior Member, IEEE) 1Institute for Automation of Complex Power Systems, E.ON Energy Research Center, RWTH Aachen University, 52074 Aachen, Germany 2TTControl, 39042 Bolzano, Italy 3Fraunhofer Institute for Applied Information Technology (FIT), 52062 Aachen, Germany Corresponding author: Cesar A. Cazal (cesar[email protected]) This work was supported by the Project Interoperable, Scalable and seCure Ac-Dc modular Automation system (InterSCADA), funded by European Union’s Horizon Europe Research and Innovation Program under Grant 101173007. ABSTRACT This work extends previous research on blockchain-based Virtual Redundancy, proposing a new approach to improve the reliability of distributed systems, with a focus on power grid applications. The original solution used blockchain’s fault-tolerant properties to provide redundancy through virtualization. However, the existing application layer and API proved unsuitable for future projects. Moreover, building on the original architecture and optimal machine allocation algorithm, this work introduces a peer-to-peer (P2P) alternative to replace the application layer and API. The design addresses three major security concerns in algorithm allocation: information leaks, malware propagation, and man-in-the-middle attacks. To mitigate these risks, a scheme called the Last Will Letter is proposed, which involves three types of nodes,the Testator, the Inheritor, and the Executor, modeled after a fictional succession ritual. The scheme presented in the current study has been deployed and tested on a five-node network under stress conditions, such as singlenode failures. Results show the system maintains performance while enabling secure migration. Finally, execution times and computational requirements for achieving Virtual Redundancy with this scheme are also reported. INDEX TERMS Last Will Letter, virtual redundancy, blockchain, secure migration, federated peer-to-peer, power grid, automation, fault tolerance. I. INTRODUCTION The adoption of new Information and Communication Technologies (ICT) for the automation of power systems also inherits the rising threats of cyber-attacks on the electric network to disrupt the normal operation of any society. This is the case observed in 2014, during the coordinated cyber-attacks carried over on the Ukrainian distribution network [1], exposing the vulnerabilities present The associate editor coordinating the review of this manuscript and approving it for publication was Mouloud Denai . in centralized automation techniques as Single Points Of Failure (SPOF) in the system, in consequence, constituting the main targets for cyber warfare and criminal attacks. To this point, several countermeasures have been proposed to tackle cyber-physical attacks on power grids. Nevertheless, we will give special emphasis on the distributed architecture proposed in [2], as this work represents a continuation of the research initiated. Given the virtual character of the solution, where idle resources of collaborative machines are assigned to perform the task in the control of physical components in computational nodes, the solution was internally renamed as VOLUME 13, 2025 2025 The Authors. This work is licensed under a Creative Commons Attribution 4.0 License. For more information, see https://creativecommons.org/licenses/by/4.0/ 178845 C. A. Cazal et al.: Last Will Letter: A Secure Federated P2P Scheme FIGURE 1. Conventional redundancy vs. virtual redundancy concept representation. The algorithms (A1,A2,... ,An) are executed inside every machine. ‘‘Virtual Redundancy’’, considering that the resources do not come to action until a failure is detected in the system, as it can be appreciated in 1. In that approach, a blockchain-based architecture is proposed, centered in the Hyperledger Fabric framework to exploit the fail-proof characteristic of distributed solutions. Next, it runs a series of smart contracts for the creation, reading, and updating of the different actors and parameters that feed an algorithm for the selection of the optimal host machine of the local program. Once the optimal machine is selected, the information is transmitted to node-red, which acts as an interface between the smart contract and Calvin IoT. This last is a platform in charge of managing the local actor, communicating with the future host, and migrating the program in case the original machine can no longer respond in the system. Unfortunately, the main component of the application layer, Calvin IoT, has fallen deprecated [3], bringing up the need for revision of the whole solution proposed by [2]. So, in this case, we took the opportunity to analyze in detail the solution proposed and identify possible improvement points by studying potential threats that might come together: •Malware propagation: It is the spread of malicious programs along the network. The current solution does not provide isolation for the received files in case of the presence of malware nor prevent its propagation. This point can disrupt the operation of the new host machine or trigger a chain reaction within the network in case the malware gets ‘‘automatically migrated’’. •Data Leak: Defined as the exposure of confidential, sensitive, protected, or critical information to unauthorized parties. The solution presented in [2] does not protect the received program’s information from being accessed before the migration. In case the new host takes possession of the program migrated, he can disrupt the operation of the network by e.g. sending contradictory instructions to the physical devices, making use of the information within the program to disrupt other services with similar functions within the network, etc. •Man-in-the-middle attack: Defined as an attack where a malicious actor secretly intercepts and (potentially) modifies the data exchanged between two other parties [4]. The solution proposed by [2] does not protect the network in case the new host machine represents an infiltrated threat, putting itself between the processing software recently migrated, and the computer receiving the processed information. Here, in case the new host behaves maliciously, it can either report similar but dangerous values to create malfunctions in the system, or even take malign possession of the controlled physical end (for the case of power systems). These types of attacks can be hard to detect due to the use of privileged information. •To overcome the limitations, and given the need to replace Calvin IoT, we proposed a new architecture for the application end to deal with these specific problems while preserving the rest of the solution intact, considering the contribution of transparency and fail-proof properties of the blockchain framework, including a first defensive wall: the need for certificates to participate in the system. The main contributions of this document are the following: •The study proposes a new framework to protect the new host machine in case of malware file propagation. •A novel Federated Peer-to-Peer (P2P) Algorithm, where no actor involved gathers enough information about the migrated file until the original machine loses connection to the network. •A consensus-mode operation for critical processes to verify the correct action of the new host machine(s). •A Proof-of-Concept (PoC) of the proposed application developed in Node.js is presented and integrated into the Smart Contract and Blockchain Framework of the solution presented in [2]. •The working functionality of the overall system (i.e. migration process) of the implemented prototype is tested and the performance evaluation as well as the system response to normal and unfavorable conditions are presented. II. THEORETICAL BACKGROUND In this chapter, we revise the fundamentals necessary to understand and implement the proposed algorithm. It is important to add that the different elements presented within the chapter start with the current state of the art, and then we proceed to describe the different concepts necessary to understand the present solution. In the process, we expect to describe the characteristics and clarify the limitations of every technology presented, to properly comprehend the characteristics of the current solution. A. REDUNDANCY FUNDAMENTALS Before proceeding further, we need to speak about how redundant systems are commonly classified: as N+1, for a single redundant element, N+2, for two redundant elements, 2N for double of every element, and so on. For practical reasons, we will adopt ‘‘N+r’’, for ‘‘r’’ as the redundant number of elements within the system, which we will call 178846 VOLUME 13, 2025 C. A. Cazal et al.: Last Will Letter: A Secure Federated P2P Scheme redundant value ‘‘r’’, which we will use in several sections of this paper. To this point, we have presented a redundant operation, where there is only one copy of the original program to be migrated, giving us a redundant factor of two (original node plus the redundant node). In case the redundant host fails before the original node, we would lose all redundancy in the system, leaving us with the need to revise the strategies to increase the chances of service availability upon failures within the system. Here we would like to show the different possible strategies to be followed to preserve enough data for migration. If we consider the mean chances for one machine to fail in a defined period are λ, the reciprocal λ−1 would be the Mean Time Between Failures (or MTBF, if we consider the failures are repairable). Nonetheless, the overall system failure for different components has a different behavior compared to the probabilities for two failure events to converge at the same time, as we can see in equation (1) [5]. If we assume the components are in their useful life period, and have a constant failure rate (i.e. only due to random failures), we can make some practical assumptions. In other words, even when two independent components of a bigger system might have the same failure rate, the chances that both machines fail simultaneously within the same period (defined by the Mean Time to Repair or ‘‘MTTR’’) are a quadratic function, while three machines respond to a cubic function, and so on. MTBFsys =MTBF1·MTBF2·. . . ·MTBFn MTTR1+MTTR2+ · · · + MTTRn(1) In consequence, in the case of redundant information, the more copies of the data, the less the chances of losing it (exponentially better, so to say). To implement it there are different methods, but we should take a special look into two very relevant for us: •Data Replication: This procedure consists of creating an entire number of copies of the data (independent of full or split) and distributing them to different storage units. This is the simplest way of creating redundancy, but it presents risks of lost data in the transport or storage process, as well as inefficiencies. For split files, what counts is the number of copies created of every piece.+ •Rabin’s Information Dispersal Algorithm (IDA) [6]: With this algorithm, we can split the file on ‘‘n’’ arbitrary pieces of length ‘‘L’’, so just ‘‘m’’ (also arbitrary) pieces are enough to reconstruct the whole file. For this, the. Each of the ‘‘n’’ pieces has a length of l=L/m, where, when having ‘‘m’’ pieces we have enough information to reconstruct the whole file, making it more storage efficient than simple data replication and highly faulttolerant. In a simple analysis, if we take a file split into four pieces, with a redundant value of three, for the data replication scenario we would need a total of 12 equal-sized pieces totalizing 3 times the storage need, while for the IDA case, for 12 pieces we only need ‘‘m’’ to be ‘‘n-3’’, leaving us with FIGURE 2. Symmetric key encryption scheme. a total space needed of 1.33 times more than the original file, reducing in this way possible errors and the overall space required for having equal redundancy (we can have up to 3 failed components in the system). It is important to add that, as we assume that the data is going to be passed from the local machine to the redundant ones, we are vulnerable to errors in the transport process. However, the application of error detection and correction techniques present within the data link layer (layer 2 of the OSI model) of TCP-IPbased protocols would significantly mitigate possible errors in the transmission process. At the same time, an integrity check is crucial to reconstruct the files and, more importantly, to ensure security within the network, as malicious data can be traced to its origin in case of malicious or faulty file propagation. To this point, even when we have split the files into several amounts of pieces, we are still revealing information about it (partially but still revealing it). No security measures have been applied. B. CRYPTOGRAPHIC FUNDAMENTALS To this extent, I think we were just expecting to be exchanging sensitive (and critical) information haphazardly along the network, but we need to think about the possibility of malicious actors paying special attention to our information traffic. Our final objective is to deploy a cyber defense tool that can correct successful attacks on our system, so preventing them should also be in our greatest interest. In this case, there exist different cryptographic strategies that we should be taking a more practical look at. 1) SYMMETRIC ENCRYPTION ALGORITHMS As presented in Figure 2, we can see that symmetric encryption requires the possession of the secret key by the Sender as well as the Receiver. For this, previous knowledge of the secret key (commonly associated with a ‘‘password’’) is necessary, making it impractical for cases where the key should be remotely distributed. Please note that if you implement password-based authentication, you should at least hash it to avoid revealing the information to anyone, VOLUME 13, 2025 178847 C. A. Cazal et al.: Last Will Letter: A Secure Federated P2P Scheme FIGURE 3. Asymmetric key-encryption scheme, where scenario 2 is only valid for the RSA algorithm. or even better: a hash of a password plus some Salt [7] and Pepper (also called ‘‘secret salt’’) [7],[8]. In our case, we have adopted the Advanced Encryption Standard (AES) Algorithm [9], also known as ‘‘Rijndael’’, first proposed by Daemen and Rijmen [10]. This scheme represents a NIST (National Institute of Standards and Technology) norm for symmetrical encryptions. However, this is probably the most used cryptographic encryption for files and information, even when the key cannot be remotely distributed, due to its relatively good computational performance (about 11MiB/s for a 200 MHz processor from 2001 [11]) compared to any Asymmetric Encryption Scheme (RSA for a key length of 2048bits demonstrated an encryption rate of 306.4KiB/s for a 3.2GHz processor in 2007 [12]), while still preserving equal or even better security levels. 2) ASYMMETRIC ENCRYPTION ALGORITHMS In comparison to Symmetric Encryption Algorithms, Asymmetric ones require two different keys for encryption and decryption. Due to the existence of two different keys, one for encryption and another for decryption, this algorithm requires the exchange of a key, making one disclosed or ‘‘public’’, rebaptizing these algorithms as ‘‘public key cryptography’’, where in all cases only the private key can generate a public key, hence the ‘‘uniqueness’’ that binds the private key to its owner’s identity (and now you might have come into realization about the fundamentals of cryptographic signatures). Moreover, anyone in possession of the private key can make a message public to the owners of the public one, while on the other hand (and more often used), anyone in possession of the public key can send an encrypted message that can only be decrypted by the owner of the private key [13], as shown in Figure 3. In our case, due to its practicality, simplicity, and libraries compatibility, we decided to use the Rivest-Shamir-Adleman (RSA) algorithm [14], which bases its complexity on the computation of high-value prime numbers. FIGURE 4. Shamir’s secret share algorithm principles. Here we can see three key points necessary to reveal a secret. At this point, the reader should know that there exist different types of asymmetric encryption algorithms, where the most common ones are the RSA, and the Eliptic-Curve Cryptographic (ECC) algorithms [15],[16], the later one recently more popular due to its improved performance compared against RSA, as the key length necessary for secure encryption and decryption increases over time. The ‘‘minimum secure key length’’ computational performance is now similar (i.e., 3072 bits for RSA and 128 bits for ECC), but soon ECC performance will significantly surpass RSA [17]. Nonetheless, due to the overall poor performance of all asymmetrical algorithms compared to symmetrical ones, we need to appeal to hybrid schemes, where we combine public key schemes to exchange the common key, making the communication channel secure for all the participants. The one used by us is the TLS (Transport Layer Security), very commonly used on HTTPS (where the last ‘‘s’’ is for secure), where we can exchange first the public keys within crypto-signed certificates and then the AES-based key for fast and secure communication. It is important to remark that we can make use of more elaborated TLS security schemes but considering the low amount of expected connections and compromise of the server’s secret key represents no threat to the client (for our study case). To this point, the use of HTTPS in the exchange of packages would have been enough for creating secure channels for data exchange, but we will be using the different cryptographic algorithms presented in different orders to create a scheme for secure information storage and retrieval. To this extent none of the methods mentioned allow the federated exchange of keys to divide the power of the receiver machine. 3) SECRET SHARING ALGORITHM A name we have mentioned before as one of the most prominent cryptographic mathematicians in the 20th century has been Adi Shamir, who, besides his contribution to the RSA encryption algorithm, also proposed a scheme to distribute several keys (points in a curve) so, their combination can lead 178848 VOLUME 13, 2025 C. A. Cazal et al.: Last Will Letter: A Secure Federated P2P Scheme FIGURE 5. SHA-1 hash function applied to the input, with its respective hash. to a common shared secret, as represented in Figure 4 [18]. This scheme is recommended for Threshold cryptography by the NIST 8214 standard [19], in combination with other standard schemes to ensure the secure distribution of keys. More in detail, this scheme uses polynomial interpolation to distribute the secret among the participants. For secret shared schemes, ‘‘n’’ points are distributed along ‘‘n’’ participants, where ‘‘m’’ threshold keys are necessary to reveal the secret. Secret Shared schemes commonly make use of polynomial interpolation [18], a set of linear equations (Blakley’s secret sharing) [20], the Chinese Reminder theorem (Mignotte’s [21] and Asmouth-Bloom’s Secret Sharing [22]), or even homomorphic Encryption for Post-Quantum applications (Benaloh’s Secret Sharing [23]). Any of the aforementioned methods suffice and would be enough for our Proof of concept. Nonetheless, due to its simplicity and library availability, we have opted for a variation of the Protocol proposed by Krawczyk, known as ‘‘secret sharing made short’’ [24]. Plane Shamir’s secret share would require an important amount of storage space to apply it to a file directly. Instead, Krawczyk proposes very simple steps: 1) We Encrypt the file with a randomly generated key using a Symmetric Encryption algorithm. 2) Next, by the application of the IDA method, we Split the file into ‘‘n’’ different pieces with a threshold of ‘‘m’’ necessary pieces for reconstruction. 3) We implement Shamir’s secret to split the secret key into ‘‘n’’ different keys with a threshold of ‘‘m’’ minimum necessary keys. 4) We distribute the keys by making use of a secure channel. As to the knowledge of the authors of this paper, we could not find a suitable and well-supported library for the implementation of step 2, so we modified step 2 by applying just ‘‘data replication’’ with a redundant factor equivalent to ‘‘n - m’’, but the application of IDA is strongly recommended due to its Fault-Tolerant and Storage-Efficiency advantages. 4) DATA INTEGRITY VERIFICATION: HASHING ALGORITHM To this extent, anyone with a basic knowledge of blockchain would know already what a hash function is. As shown in Figure 5, a hash is the fixed data length output of a one-way cryptographic function (known as a hashing function) [7]. Considering the hash length ‘‘h’’ (e.g. 128 bits, 256 bits, 512 bits, etc.), every input value of any length will be associated with a unique fixed-length output value, which can be any one of the 2h possible ones (e.g. 2128, 2256, or 2512, FIGURE 6. Virtual machine technology (left) compared to container technology (right). or if we just place these as base-10 numbers, we would be speaking about 1038.5, 1077 and 10154 respectively, i.e. 54 orders of magnitude bigger than a googol [25]). In other words, these associations can be used to individually and uniquely identify the given input data to an output data identifier (i.e. hash) with an absurdly low probability of crashes (virtually zero), which is how the event of having two equal hashes with different inputs are denominated. On the other hand, given it is a one-way function, the only possible way of maintaining the same output while modifying the input is to try by brute force every possible combination until we get the same output, a task that would make Sisyphus himself feel lucky. At this point, we can see that this method can be used to prove some knowledge without revealing the data (known as ‘‘zero-knowledge proof’’, by comparing two hashes from different machines), or to prove that certain data remained unmodified after receiving it from any other actor, known as ‘‘proof of integrity’’ or ‘‘checksum’’ for the case of a file, as defined in the equation (2). Finally, if the hash is also encrypted with a private key, with the possession of the public key we can prove that certain data was unmodified and is associated with a specific private-key owner, basically a ‘‘crypto-signature’’ of the data. Hash(X)=Hash(X′)→X=X′(2) C. SANDBOX ENVIRONMENT A Sandbox is an isolated environment to confine software for security reasons, for it to run without affecting the rest of the applications, platforms, or overall system (i.e. hardware or other software) [26]. As our main focus is to improve the overall security of the whole network, the fact of receiving files and running them without hesitation represents a naïve approach, when we might be dealing with malicious software from the first moment, we get in contact with it. This solution we propose is by making use of containers (which represent already isolated environments) with enhanced isolation for security [27]. The particular choice of docker allows the virtualization of the migrated application to be run within the host machine in a more general way without depending on hardware-specific or softwarespecific solutions while paying attention to the security of the receiving end. On the other hand, we require not VOLUME 13, 2025 178849 C. A. Cazal et al.: Last Will Letter: A Secure Federated P2P Scheme FIGURE 7. Verifiable computing by process replication. one, but two layers of solutions, as the receiving end might be receiving a generic file looking to exploit security breaches. As shown in Figure 6, we might apply a Virtual Machine for hosting the Virtual Redundancy service (which also isolates the host machine’s OS at the cost of small overhead, compared to containers) or another container to run the migrated application (in our case, Sysbox, for ‘‘nested’’ container solutions [28], now acquired by Docker for Business solutions [27]), in between other less popular isolation and virtualization solutions. This architecture for hosting the applications is intended to ensure security from the host’s perspective, as the received file will have to be deployed as ‘‘Docker-In-Docker’’ within Sysbox, so, in case the deployed file contains or ‘‘is’’ by itself a malware, it will remain isolated from the rest of the machine. D. VERIFIABLE COMPUTATION: VERIFICATION BY REPLICATION While the last solution was presented to avoid malicious software affecting the host machine, we have no methods to be sure that the new host machine is running the algorithm provided by the original machine, or is just providing us with unuseful, malicious, or even dangerous data. To check the computation, we can apply a simple method to probabilistically check for truth in the process: we can provide ‘‘N’’ independent machines with the same input and expect the same output from all of them. If the majority of values, more than a threshold ‘‘M’’ coincide, then we can say we ‘‘probably’’ have the true output in our hands [29]. As shown in Figure 7, this method does not necessarily require consensus, as the machines do not need to interact with each other, but it requires an external verifier (as the original machine is expected to fail). This means that the application would require a minimum of three machines for ‘‘value certainty’’ (i.e., two hosts, and one verifier running a ‘‘lightweight’’ program for comparing the results) or four machines (i.e., with three hosts and one verifier) to resolve in case of values mismatch. This method should be reserved only for very critical operations necessary within the system, as we are unnecessarily adding more processing burden to implement it. E. PREVIOUS WORK As shown in Figure 1, the main idea behind the Virtual Redundancy, as opposed to the conventional redundancy concept where dedicated hardware is applied for redundant operation, is to make use of the idle hardware resources of FIGURE 8. Algorithm representation for optimal machine selection with multiple requirements vs. multiple capabilities criteria. machines dedicated to other tasks within the network in order to enhance the resiliency, especially (but not limited to) the critical infrastructure as for the case of automation services in power distribution networks. In [2] (and summarized in [30]), the main idea is to make use of the distributed nature of Blockchain networks to register the resources present within the network and coordinate the migration of the service previous to failure. For this, the virtualization of resources is essential, as the idea is to be able to reproduce the same behavior and responses as the system previous to migration as is the case for sensors and actuators, which should be ‘‘virtually rewired’’ to the new processing location by redirecting the communication flow, not to mention that the new host should also be capable of running the migrated algorithms, so the more generic the software and hardware resources and standard resources, the better. Leaving now behind the necessary assumptions for its implementation, we need to quickly describe how the selection process of the new host is carried over without including the mathematical details for brevity reasons (nonetheless inviting the reader to check them within the associated publications provided as part of the cited literature in [2] and summarized in [30]). So, prior to machine (and resources) registration, the smart contract gathers the application computational requirements to filter all machines with fewer resources than required and then proceeds with the application of the Analytical Hierarchical Process (see [31]). Finally, the TOPSIS algorithm [32] points out a list of possible machines able to receive the algorithm, from the optimal one to the one that would suit the worst applicable case (but still suitable to receive the migration), as shown in Figure 8. Once the optimal host has been identified in between all the machines registered within the blockchain network, the local machine and the new receiver are bound by a Smart Contract that starts the preparations for the eventual failure (by the use of CALVIN IoT [33]). To exemplify the solution, in [30] a power distribution network divided into three different automation areas has been proposed, as shown in Figure 9. 178850 VOLUME 13, 2025 C. A. Cazal et al.: Last Will Letter: A Secure Federated P2P Scheme FIGURE 9. Example of power distribution grid divided into three different control and automation areas (controlled by Substation automation Units A, B, and C), as presented in [30]. In the eventual case of failure of one of the Substation Automation Units (SAU), due to the lack of redundant devices, we might not only lose the ability to control or protect the different elements present within Area C but rather the whole operation of infrastructure, leading to blackouts (see [1]) that might lead to possible human as well as material loses as shown in Figure 10. These scenarios are more than common due to the lack of redundant devices to support the operation in the event of faults, proper of the power distribution network architecture. Nonetheless, in the case of resources virtualization and migration performed previous to the failure, the service restoration can be performed by migrating the critical services present within SAU ‘‘C’’ into any other SAU (to SAU ‘‘A’’ in the case presented in Figure 11). Now, both areas are under the control of one SAU by the use of idle resources. Finally, even when the migration is performed on virtual elements, the automation operation to control area C is expected to be resumed as soon as the heartbeat of ‘‘C’’ is no longer perceived within the network. In summary, the solution proposed in [2] contemplates the following operations within the blockchain: •Node registration •Register Node Computational Resources FIGURE 10. Failure of one of the SAU ‘‘C’’, leaving Area ‘‘C’’ without automation services, as presented in [30]. •Upload Application Computational Requirements •Perform the request for Optimal Node migration •Perform the Application Allocation •Computational Resources Update •Node Deletion Out of the blockchain the whole migration, as already mentioned, is orchestrated by CALVIN IoT, which serves as the application runtime manager, and Node-Red [34], an event-driven API for wiring applications, online services, and other APIs. Leaving aside the fact one is deprecated, and the other presents a processing load that leads us to rethink its need, the current solutions are not prepared to tackle possible security problems that might come along with the solution, information leaks, malware propagation, and manin-the-middle threats. III. METHODOLOGY A federation in computing is a group of systems that maintain their autonomy but agree to share resources to achieve a shared objective. In this section, we will see how the different technologies recently described can help us in the coordinated effort to provide virtual redundancy without losing sight of the decision-making power that each member has to maintain a reliable and secure system. VOLUME 13, 2025 178851 C. A. Cazal et al.: Last Will Letter: A Secure Federated P2P Scheme FIGURE 11. Restoration of ‘‘SAU C’’ critical services by migration into ‘‘SAU A’’, as presented in [30]. As discussed in the previous sections, we applied the permissioned Blockchain architecture with Hyperledger Fabric and Smart Contracts for Virtual Redundancy as presented in [2], while our main contribution lies especially in replacing the application and API components, with a PoC application designed with the security fundamentals in mind, which we baptized as ‘‘Last Will Letter’’ (LWL), as the whole scheme was inspired on the fictional ritual for power transition within a secret society to name a new successor upon the decease of its grandmaster. As a consequence, using a permissioned blockchain allows us to enforce access control and ensures that only authorized nodes participate in the network, enhancing security pursuant to our threat model. A. ACTORS AND COMPONENT DESCRIPTION From here, we need to present the different roles necessary for our solution and its relevant components, while a detailed description of each one of these is presented in the following subsections. 1) TESTATOR A Testator is a node responsible for requesting the service to the smart contract, as well as preparing and distributing a specific asset between its different Executors. Figure 12 depicts the Testator’s functions within the closed box. In case the Testator fails, the asset once executed by FIGURE 12. Testator role for the LWL algorithm implementation. FIGURE 13. Inheritor role and operation modes for the LWL algorithm implementation. it will be migrated to an Inheritor node, which will become this asset’s new owner. The decision power is centered on the Testator. 2) ASSET The asset is the program or data to be migrated to its new successor. 3) INHERITOR The Inheritor is represented as the blue box in Figure 13. An Inheritor is a node chosen by the TOPSIS algorithm to be the next host of a migrated asset. After receiving and deploying an asset, the Inheritor becomes the Testator for that asset. As shown in Figure 13, there can be more than one possible inheritor, in case of redundant inheritors or for verifiable computation purposes for very critical applications. 4) TESTAMENT A Testament is a file containing instructions on getting access to the asset content. The data stored in the Testament is composed by: •Instructions on how to reassemble the divided encrypted asset (hashes and order of the files) •Instructions on the migration period of the asset (in case the migration is going to be periodical) •Instructions on how many ‘‘generations’’ should receive the asset in a period (to avoid passing a cursed asset that provokes the failure on the host) •The encryption key of the asset The Testament is created and encrypted by the Testator and stored by the Inheritor. 5) EXECUTOR Executors are nodes are the red nodes depicted in Figure 14 responsible for receiving and storing a piece of the encrypted asset, as well as one of the secret keys necessary for 178852 VOLUME 13, 2025 C. A. Cazal et al.: Last Will Letter: A Secure Federated P2P Scheme FIGURE 14. Executor role and operation modes for the LWL algorithm implementation. FIGURE 15. Actor role definition stage. the Testament execution. Also, and most importantly, the Executors are also responsible for deciding whether the Testator has failed or not, to initiate the Testament’s execution, where the Testator is considered down in case more than half of the Executors agree on the absence of its heartbeat. B. NETWORK DESCRIPTION The manager application is the software responsible for executing the system workflow according to the nodes’ roles, as received from the Smart Contract. In Figure 15, we can see the main possible routines of the manager application: once it receives the node’s role for input, it proceeds to call a specific routine according to it. C. TESTATOR’S FUNCTION DESCRIPTION As introduced in Figure 15, the testator function has to prepare the asset for secure migration, as well as the testament. For this, as shown in Figure 16, the Testator should process the asset first by: 1) Symmetrically encrypting the asset (with the AES-256 algorithm). 2) Splitting the asset in ‘‘m’’ pieces. 3) Creating the Reassembly Instructions (i.e. pieces names and orders, checksum of pieces, etc.). 4) Creating the Testament (Merging the Symmetric Key from step 1 and Reassembly instructions in a file). 5) Encrypting the Testament (with Shamir’s Secret Share algorithm). FIGURE 16. Testament creation for inheritors and encrypted pieces for the executors. 6) Generating m*r secret keys, with a threshold greater than half of the generated keys. After the whole process is finished, the Testator transmits the asset pieces and keys to every executor by making use of the TLS protocol, as presented in the previous section. It is important to add that, even when no copies are created, ‘‘r’’ copies of every piece are provided, being ‘‘r’’ the redundant value for our system (e.g., r=2 for two copies of every piece, or r=3 for three copies of each piece sent). Finally, the Testamentor distributes copies of the Testament, depending on the redundant value ‘‘r’’. As demonstrated in Figure 17, no actor has enough information to deploy the asset alone without a federated decision of the executors. Additionally, AES-256 is currently considered computationally secure because the best known attacks require computational resources beyond what is feasible with current technology [10]. Shamir’s Secret Sharing is information-theoretically secure, meaning that an adversary with fewer than kshares gains no information about the secret. This property is proven based on the randomness of the coefficients in the polynomial used to generate the shares [18]. VOLUME 13, 2025 178853 C. A. Cazal et al.: Last Will Letter: A Secure Federated P2P Scheme Finally, the execution times (for a 25MiB asset) demonstrated that the system can be operational in approximately 10s upon migration, showing in this way that the main purpose of Virtual Redundancy is achievable with a secure migration scheme. REFERENCES [1] R. M. Lee, M. J. Assante, and T. Conway, ‘‘Analysis of the cyber attack on the Ukrainian power grid: Defense use case,’’ SANS Institute E-ISAC, Tech. Rep. DUC-5, 2016. [2] A. Sadu, A. Jindal, G. Lipari, F. Ponci, and A. Monti, ‘‘Resilient design of distribution grid automation system against cyber-physical attacks using blockchain and smart contract,’’ Blockchain, Res. Appl., vol. 2, no. 1, Mar. 2021, Art. no. 100010. [3] EricssonResearch. Calvin-Base. Accessed: Sep. 1, 2025. [Online]. Available: https://github.com/EricssonResearch/calvin-base [4] M. A. Elakrat and J. C. Jung, ‘‘Development of field programmable gate array–based encryption module to mitigate man-in-the-middle attack for nuclear power plant data communication network,’’ Nucl. Eng. Technol., vol. 50, no. 5, pp. 780–787, Jun. 2018. [5] D. J. Smith, Reliability, Maintainability, and Risk: Practical Methods for Engineers, 8th ed., London, U.K.: Butterworth-Heinemann, 2011. [6] M. O. Rabin, ‘‘Efficient dispersal of information for security, load balancing, and fault tolerance,’’ J. ACM, vol. 36, no. 2, pp. 335–348, Apr. 1989. [7] M. Rosulek. The Joy of Cryptography. Accessed: Nov. 14, 2024. [Online]. Available: https://joyofcryptography.com [8] D.Temoshok, J.L. Fenton,Y.-Y. Choong,N. Lefkovitz, A.Regenscheid,R. Galluzzo, and J. P. Richer, ‘‘Digital identity guidelines: Authentication and authenticator management,’’ Nat. Inst. Standards Technol., Gaithersburg, MD, USA, Tech. Rep. SP 800-63B-4, 2025. [9] Advanced Encryption Standard (AES), Nat. Inst. Standards Technol. (US), Gaithersburg, MD, USA, Sep. 2023, doi: 10.6028/NIST.FIPS.197upd1. [Online]. Available: https://nvlpubs.nist.gov/nistpubs/FIPS/NIST. FIPS.197-upd1.pdf [10] J. Daemen and V. Rijmen, The Design of Rijndael, vol. 2. Cham, Switzerland: Springer, 2002. [11] B. Schneier, J. Kelsey, D. Whiting, D. Wagner, C. Hall, and N. Ferguson, ‘‘Performance comparison of the AES submissions,’’ presented at the 2nd AES Candidate Conf., NIST, 1999. [12] V. Yakovyna, D. Fedasyuk, M. Seniv, and O. Bilas, ‘‘The performance testing of RSA algorithm software realization,’’ in Proc. 9th Int. Conf.- Exper. Designing Appl. CAD Syst. Microelectron., Feb. 2007, pp. 390–392. [13] IBM Integration Bus. Accessed: Sep. 1, 2025. [Online]. Available: https:// www.ibm.com/docs/en/integration-bus/10.1.0?topic=overview-publickey-cryptography [14] R. L. Rivest, A. Shamir, and L. Adleman, ‘‘A method for obtaining digital signatures and public-key cryptosystems,’’ Commun. ACM, vol. 21, no. 2, pp. 120–126, 1978. [15] V. S. Miller, ‘‘Use of elliptic curves in cryptography,’’ in Advances in Cryptology–CRYPTO Proceedings (Lecture Notes in Computer Science), H. C. Williams, Ed., Cham, Switzerland: Springer, 1985, pp. 417–426. [16] N. Koblitz, ‘‘Elliptic curve cryptosystems,’’ Math. Comput., vol. 48, no. 177, pp. 203–209, 1987. [17] D. Mahto and D. K. Yadav, ‘‘RSA and ECC: A comparative analysis,’’ Int. J. Appl. Eng. Res., vol. 12, no. 19, pp. 9053–9061, 2019. [18] A. Shamir, ‘‘How to share a secret,’’ Commun. ACM, vol. 22, no. 11, pp. 612–613, Nov. 1979. [19] L. T. Brando, N. Mouha, and A. Vassilev, ‘‘Threshold schemes for cryptographic primitives: Challenges and opportunities in standardization and validation of threshold cryptography,’’ Nat. Inst. Standards Technol., Gaithersburg, MD, USA, Tech. Rep. IR 8214, 2019. [20] G. R. Blakley, ‘‘Safeguarding cryptographic keys,’’ in Proc. Int. Workshop Manag. Requirements Knowl. (MARK), Jun. 1979, pp. 313–318. [21] M. Mignotte, ‘‘How to share a secret,’’ in Proc. Workshop Cryptogr., Burg Feuerstein (Lecture Notes in Computer Science), vol. 149, T. Beth, Ed., Berlin, Germany: Springer, 1983, pp. 371–375. [22] C.Asmuth andJ. Bloom,‘‘Amodular approachto key safeguarding,’’IEEE Trans. Inf. Theory, vol. IT-29, no. 2, pp. 208–210, Mar. 1983. [23] J. C. Benaloh, ‘‘Secret sharing homomorphisms: Keeping shares of a secret secret (extended abstract),’’ in Advances in Cryptology—CRYPTO’86 (Lecture Notes in Computer Science), A. M. Odlyzko, Ed., Cham, Switzerland: Springer, 1986, pp. 251–260. [24] H. Krawczyk, ‘‘Secret sharing made short,’’ in Advances in Cryptology— CRYPTO’93, vol. 773, D. R. Stinson, Ed., Cham, Switzerland: Springer, 1994, pp. 136–146. [25] E. Kasner and J. R. Newman, Mathematics and the Imagination. North Chelmsford, MA, USA: Courier Corporation, 2001. [26] I. Goldberg, D. Wagner, R. Thomas, and E. Brewer, ‘‘A secure environment for untrusted helper applications (confining the wily hacker),’’ Tech. Rep. [27] What is Enhanced Container Isolation?. Accessed: Sep. 18, 2019. [Online]. Available: https://docs.docker.com/desktop/hardened-desktop/ enhanced-container-isolation/ [28] Nestybox/Sysbox. Accessed: Jun. 20, 2025. [Online]. Available: https:// github.com/nestybox/sysbox [29] S. Šimunic, D. Bernaca, and K. Lenac, ‘‘Verifiable computing applications in blockchain,’’ IEEE Access, vol. 9, pp. 156729–156745, 2021. [30] C. Cazal and F. Ponci, ‘‘Blockchain in monitoring and automation of distribution systems,’’ in Blockchain-Based Systems for the Modern Energy Grid, 2023, pp. 251–283. [31] R. W. Saaty, ‘‘The analytic hierarchy process—What it is and how it is used,’’ Math. Model., vol. 9, nos. 3–5, pp. 161–176, 1987. [32] Z. Yue, ‘‘A method for group decision-making based on determining weights of decision makers using TOPSIS,’’ Appl. Math. Model., vol. 35, no. 4, pp. 1926–1936, Apr. 2011. [33] Open Source Release of IoT App Environment Calvin. Accessed: Oct. 23, 2022. [Online]. Available: https://www.ericsson.com/en/blog/ 2015/6/open-source-release-of-iot-app-environment-calvin [34] OpenJS Foundation. Node-RED. Accessed: Sep. 13, 2023. [Online]. Available: https://nodered.org [35] W. Reese, ‘‘Nginx: The high-performance web server and reverse proxy,’’ Linux J., vol. 2008, no. 173, p. 2, Sep. 2008. [36] BRILLIANT Last Will Letter. GitLab. Accessed: Sep. 3, 2025. [Online]. Available: https://git-ce.rwth-aachen.de/cesarcazal/brilliant-last-resourceletter [37] Change Docker Desktop Settings on Linux. Accessed: Nov. 14, 2023. [Online]. Available: https://docs.docker.com/desktop/settings/linux/ [38] Snyk. Severity Levels. Snyk User Docs. Accessed: Sep. 1, 2025. [Online]. Available: https://docs.snyk.io/manage-risk/prioritize-issuesfor-fixing/severity-levels [39] C. Cazal, R. Hamila, M. Pitz, F. Ponci, and A. Monti, ‘‘Fault-tolerant implementation of the SMU with bad-data detection applied to PMU values,’’ Tech. Rep. [40] S. Gilbert and N. Lynch, ‘‘Brewer’s conjecture and the feasibility of consistent, available, partition-tolerant web services,’’ ACM SIGACT News, vol. 33, no. 2, pp. 51–59, Jun. 2002. CESAR A. CAZAL (Graduate Student Member, IEEE) received the Engineering degree in electronics with a major in industry control from the Universidad Nacional de Asuncion, Paraguay, in 2016, and the M.Sc. degree in electrical engineering, information technology, and computer engineering with a major in power systems from RWTH Aachen University, Germany, in 2019, where he is currently pursuing the Ph.D. degree with the E.ON Energy Research Center, Institute for Automation of Complex Power Systems. His research interests include distributed automation, control, and monitoring of power distribution grids, with a special emphasis on distributed computing technologies. Also, synchronized measurement techniques play a major interest in between his research topics. SU MON TUN (Graduate Student Member, IEEE) received the M.Eng. degree in electrical and computer engineering from the King Mongkut’s University of Technology North Bangkok, Thailand, in 2024. She is currently pursuing the Ph.D. degree with the Institute for Automation of Complex Power Systems, RWTH Aachen University, Germany. Her research interests include semantic interoperability and cybersecurity in the energy domain. 178860 VOLUME 13, 2025 C. A. Cazal et al.: Last Will Letter: A Secure Federated P2P Scheme LEONARDO LEONZI D’ALESSANDRO received the Engineering degree in informatics from RWTH Aachen University, and the double master’s degree from RWTH Aachen University and the University of Sao Paulo, Brazil, in 2022. During his time with the University of Sao Paulo, he was a Research Assistant in the field of data science, focusing on researching the effects of pollutants on the biodiversity of the Amazon Rainforest. Currently, he resides in Bolzano, Italy, where he is a Functional Safety Application Engineer with TTControl, developing applications for off-road vehicles. STEFAN LANKES received the Ph.D. degree from RWTH Aachen University, Germany. From 2007 to 2017, he was an Academic Counselor with the Chair for Operation Systems, RWTH Aachen University. Since 2017, he has been the Academic Director with the Institute for Automation of Complex Power Systems, RWTH Aachen University. His research interests include operating systems, cloud computing, and highperformance computing. FERDINANDA PONCI (Senior Member, IEEE) received the Ph.D. degree in electrical engineering from the Politecnico di Milano, Milan, Italy, in 2002. In 2003, she joined the Department of Electrical Engineering, University of South Carolina, Columbia, SC, USA, as an Assistant Professor, where she became an Associate Professor, in 2008. In 2009, she joined the E.ON Research Center, Institute for Automation of Complex Power Systems, RWTH Aachen University, Aachen, Germany, where she is currently a Professor of monitoring and distributed control for power systems. Her current research interests include automation and advanced monitoring of active distribution systems. ANTONELLO MONTI (Senior Member, IEEE) received the M.Sc. (summa cum laude) and Ph.D. degrees in electrical engineering from the Politecnico di Milano, Milan, Italy, in 1989 and 1994, respectively. He started his career with Ansaldo Industria, Genoa, Italy, and then moved to the Politecnico di Milano, in 1995, as an Assistant Professor. In 2000, he joined the Department of Electrical Engineering, University of South Carolina, Columbia, SC, USA, as an Associate Professor and then a Full Professor. Since 2008, he has been the Director of the E.ON Energy Research Center, Institute for Automation of Complex Power Systems, RWTH Aachen University, Aachen, Germany. He is the author or co-author of more than 300 peer-reviewed articles published in international journals and the proceedings of international conferences. He was a recipient of the 2017 IEEE Innovation in Societal Infrastructure Award. He is an Associate Editor of IEEE SYSTEMS JOURNAL and IEEE Electrification Magazine. He is an Editorial Board Member of Sustainable Energy, Grids and Networks (SEGAN) (Elsevier). He is the Founding Board Member of Energy Informatics (Springer). VOLUME 13, 2025 178861