# Leveraging Blockchain Technology for Secure 5G Offloading Processes +
## 3 Blockchain-Based Secure 5G Offloading Mechanism
### Blockchain for Secure Authentication Among Operators
#### 3.2.1 Architecture and Components  
The SSI-based authentication system for 5G offloading processes follows the traditional set-up of an SSI-based solution, including three main actors: issuer (the primary operator), holder (the user equipment), and verifier (the secondary operator). As already stated in Section 2.2.1, the combination of Hyperledger Aries and Hyperledger Indy is the most widespread and evolved SSI solution. For this combination, the three users require the SSI agent (ACA-Py) with the credentials logic and the SSI controller with the authentication control logic. For the operators, which usually have servers with no computational constrains, both the SSI agent and the SSI controller can be deployed on their premises. However, in contrast, 5G user equipment can refer to all kinds of IoT devices, including devices with very limited features. For this reason, the SSI agent is deployed in the cloud, being always accessible from the user equipment, where the associated SSI controller needs to be deployed. Taking this into consideration, Figure 5 shows in green the high-level architecture of all the elements involved in the SSI operation for 5G user authentication among different operators involved in an offloading process. As mentioned, the deployment of the operators with both the SSI agent and controllers in servers on their premises is the usual one [102; 103]. However, the implementation in limited devices such as IoT can present challenges as they present limited capabilities in terms of resources and performance, which often complicates applying security measures on them, including identity management procedures [104]. Some authors [105] have acknowledged the limitations of IoT devices and consequently propose a proxy-based solution for those extremely constrained. The proxy approach is shared by other authors [106]; for example, by presenting another proxy-based design, termed as IoT Exchange, to connect IoT devices with users. Despite all these works, there is still a need for a performance evaluation focused on IoT devices running SSI solutions. Note that although some works delve deeper into the performance evaluation of SSI [107; 108], none of them considers IoT devices. Other works specifically provide measures for devices such as a Raspberry Pi [75], but not for more constrained devices such as Arduino broads, which are commonly used for different IoT devices [109]. Implementing an ACA-Py SSI controller in an Arduino device has a drawback. ACA-Py uses webhooks to connect the agent (installed in the cloud) with the controller (installed in the 5G user equipment, in this case, an Arduino board). Therefore, end devices need to deploy a webserver that listens to incoming communications to receive the information from the ACA-Py agent and take decisions according to the authentication control logic from the SSI controller. Regretfully, Arduino is not capable of de  
Figure 5: SSI-based authentication system architecture. which limits the implementation capability for ACA-Py. To address this challenge, two alternatives could be considered:  
* Automatic mode. ACA-Py agents might be configured in an automatic mode that implies that there is no need to ask the controller what to do. In this case, the Arduino SSI agent would always automatically accept all the received credentials and would always automatically respond with a proof from the credential to every verification request. This would release the SSI controller of the 5G user equipment (Arduino) of any control action. However, this approach is very limited, as the user equipment could not take any decision. * Polling. In this case, the controller would periodically poll the ACA-Py agent to check if any action needs to be performed. This would allow the SSI controller (Arduino) to make decisions according to any specified authentication logic. This includes that it could decide whether to accept or not a credential and if sending or not proof as a response to a verification request.