Blockchain-Based Secure Authentication and Authorization Framework for Robust 5G Network Slicing

The rapid evolution of heterogeneous applications signifies the requirement for network slicing to cater to diverse network requirements. Network Functions (NFs), which are the essential elements of network slices, are required to communicate with each other securely to facilitate network services. Certificates are the established method to authenticate each other. However, dynamic certificate management while allowing NFs to communicate in a multi-operator environment is arduous. Also, sharing NFs between network slices originates authorization-related security challenges such as unauthorized service utilization, deceptive Denial of Service attacks, and data leakages from network slices. In this paper, we develop a novel framework to address the security challenges related to authentication and authorization in 5G network slicing systems. A blockchain-based multi-party distributed certificate management framework with secure communication protocols is developed using elliptic curve cryptography to facilitate certificate services for multi-operator environments. Also, we propose a blockchain-based NF authorization framework to mitigate the security vulnerabilities in NF sharing between network slices. We implement the proposed framework using Hyperledger Fabric blockchain with Java chain codes and perform comprehensive experiments to show the significance of our framework.The Ability to mitigate the single point of failure with respect to state-of-the-art, including traditional certificate authorities and blockchain-based certificate authorities, time analysis for certificate generation, and the potential to eliminate the mentioned authorization attacks are some of the experiments conducted.Also, we have shown that our framework is secure using informal and formal (using Real-Or-Random (ROR) logic and Scyther Validation tool) security verification mechanisms.


I. INTRODUCTION
T HE RAPID evolution of the Internet and related technolo- gies causes significant advancements in heterogeneous applications such as smart healthcare, autonomous vehicles, Internet of Things (IoT), and industrial automation [1].For instance, Lian highlighted that the number of IoT devices will exceed 25 billion by 2025 [2].Connectivity is one of the fundamental requirements for the realization of these diverse applications.Also, the connectivity requirements are diverse in these applications.Therefore, future telecommunication networks, including Fifth Generation (5G), are being designed to facilitate the network requirements of these diverse applications.
Network slicing, one of the predominant technologies in future telecommunication networks, can divide the physical network into multiple logical networks specific to different applications [3].In [4], Wijethilaka et al. showed the significance of network slicing for the realization of different applications.Allocating different network slices for different applications allows us to facilitate the diverse communication requirements of respective applications.According to ResearchDive, there is exponential growth in the networkslicing market in different applications.For instance, they expect the healthcare market in network slicing will be $182.5 million by 2027, which is $36.1 million in 2019 [5].Security is a critical aspect of a network-slicing ecosystem.In addition to the conventional security vulnerabilities in telecommunication systems, network slicing itself introduces a novel threat space.In [6], Olimit et al. identify the potential threat space of network slicing in 5G networks.These security vulnerabilities affect all the users in the network.
The functionality of a particular network slice depends on the deployed Network Functions (NFs).Network Function Virtualization (NFV) allows us to transform NFs from hardware-based entities to software components that can be deployed in commodity servers [7].Virtual NFs (VNFs) are specific instances of a network function that have been virtualized and deployed as software applications.VNFs provide the building blocks of NFV deployments.According to the Third Generation Partnership Project (3GPP), these VNFs use certificates to authenticate with each other and to enable secure communication [8].However, certificate management in an operator environment is an unsolved issue yet [9].
As concepts such as virtual network operators, Local 5G Operators (L5GOs) or private 5G Operators are evolving in future telecommunication networks, network slices need to be spanned over multiple administrative domains.Therefore, inter-operator visibility for the certificates is required to ensure secure communication.Standalone deployment of a Certificate Authority (CA) in an operator environment can not provide the required visibility for the certificates over multiple administrative domains.Also, acquiring certificates from commercial CAs is not feasible due to the dynamic nature of NF deployment and the cost of commercial CAs.Therefore, a novel authentication framework is required to manoeuvre the certificate management process related to NFs in network slices of operators.
NFs can be shared between multiple slices or deployed within a single slice.Sharing of NFs between network slices originates a set of authorization security challenges.The company Adaptive Mobile Security (AMS) identified potential security vulnerabilities in NF sharing between network slices [10].Data leakage between network slices, Denial of Service (DoS) attacks against a particular slice, and unauthorized resource usage are some identified security challenges in NF sharing.Since sensitive data, such as health data, are transmitted over network slices, information leakage creates a serious issue.Also, continuous communication without disruption is crucial for applications such as autonomous vehicles.Moreover, network slice owners might need to pay for unutilized services if some other parties utilize services impersonating them.The network-slicing ecosystem should be strengthened to mitigate these discussed authentication and authorization challenges to ensure the optimal utilization of network slicing.
Blockchain is a novel technology that builds trust between multiple parties using distributed and immutable ledger technologies [11].The properties, such as accountability, immutability, and increased transparency, motivate us to utilize blockchain in other applications in addition to crypto.Thus, several blockchain-based Public Key Infrastructures (PKIs) have been proposed in the literature.However, almost all of them are based on a central CA, and they use the blockchain as an intermediate technology to store and revoke certificates.
The central CA can be a single point of failure and can also affect the whole ecosystem if the CA is malicious [12].Therefore, a distributed certificate generation mechanism is required to reduce the impact of malicious individual CAs.Moreover, blockchain, along with its processing power achieved through smart contracts, can be utilized as a supporting technology in our framework as it allows us to make the certificate generation process more trusted, accountable, and transparent.In addition, blockchain technology permits simplifying certificate validation and revocation procedures.Hence, our framework can perform all the certificate operations, including certificate generation, validation, and revocation.Moreover, the same blockchain can be used to eliminate unresolved authorization issues in the slicing ecosystem.
Therefore, we present a blockchain-based framework to handle certificates in a slicing ecosystem and to mitigate authorization vulnerabilities highlighted in this paper.Our framework eliminates the single point of failure in the certificate issuance process.Also, trust is distributed as we utilize multiple parties to issue a single certificate.Therefore, we address the CA trust issues.Lightweight certificate utilization in our framework increases storage and bandwidth efficiency.Since we utilize the blockchain to handle certificates, certificate revocation can be announced to all parties effectively.The secure protocols to receive certificates presented in this paper allow us to deploy our framework with any blockchain network, either public or private.Moreover, our framework mitigates the challenge of NF authorization in network slices.

A. Motivation
This subsection describes the scenarios that motivated us to conduct this research.
1) Authentication Challenges for Network Functions in Network Slices: A network slice consists of multiple network functions, and they need to communicate with each other to realize the functionality of the network slice.Moreover, network functions need to communicate to realize the multidomain network slicing, as shown in Figure 1.Even though 3GPP specifies the use of digital certificates for the mutual authentication of network functions, the specific way to manage these certificates is not investigated.If a commercial CA is used, the cost would be very high for the MNO.If a private CA is used, the certificates only will be visible to the internal environment.Therefore, authentication among different MNOs will not be possible.Considering these limitations, a novel certificate management framework is required to enable certificate visibility among different MNOs and reduce the cost of certificates.
2) Security Vulnerabilities in Network Slicing Due to Network Function Sharing Between Slices: Even though network slicing supports diverse application realization, it introduces a new threat space to its users.In [13], Cunha et al. discuss the leading security challenges, such as impersonation attacks, end device vulnerabilities, and compromised NFs, in the packet core due to the network slicing utilization.The authors in [6] highlight potential security challenges and suggest possible solutions.AMS discovers a set of security concerns in 5G network slicing Service Based Architecture (SBA) [10].In all these research works vulnerabilities in NFs have been highlighted.NF sharing between multiple network slices introduces a set of authorization security challenges.As an industry leader in telecom security, AMS accentuates three security issues in NF sharing between network slices that are Authorized licensed use limited to the terms of the applicable license agreement with IEEE.Restrictions apply.not covered in existing standardization [10].Therefore, this paper aims to provide a solution to the following identified issues, as these issues greatly impact different applications.
a) Unauthorized service utilization: Figure 2 shows the attack flow related to this attack.Here, the Network Repository Function (NRF) acts as a centralized repository for all the 5G NFs in the operator's network.When a particular network function is shared between two network slices, a malicious network function can send requests with slice identities that do not belong to that particular network function but belong to the shared NF.However, the shared NF can not differentiate whether the received request is legitimate or not.Therefore, the actual slice owners may have to pay for the service that they have not used.This is a significant challenge for network slice owners.Due to the massive number of different applications, a massive number of network slices are available for different applications.Therefore, the impact of this attack on network slice owners is not negligible.
b) Deceptive denial of service attack on network slices: In 5G, an overload control header is used to indicate that a particular slice is overloaded.Figure 3 shows the flow diagram related to attack 2. As mentioned in the earlier attack, the malicious NF can send the overload control headers with some other slice's identity to the shared NF.Then, the shared NF assumes that the slice with the received ID is overloaded, and it stops providing services to the particular slice.That means the malicious NF can indirectly perform a DoS attack on some other slice due to the lack of solid authorization mechanisms.This is a severe issue for network slices.Critical application domains, such as autonomous vehicles and military applications, would be endangered due to this vulnerability.c) Data leakage between slices: As shown in Figure 4, the malicious NF can receive authorizations of slices that actually do not belong to them.Then, the malicious NF can request the information of data that flows across the unauthorized slice from the shared NF using the malicious authorization.This vulnerability can cause data leakage between network slices.Sensitive application domains such as smart healthcare and smart grids are subjected to data privacy and security challenges due to this vulnerability.

B. Our Contribution
The discussed limitations in the network-slicing ecosystem motivate us to propose a blockchain-based framework to address authentication and authorization-related security challenges.The contribution of this paper can be enumerated as follows.
• Propose a novel multi-party fully distributed PKI framework to handle certificates in an operator environment to mitigate authentication challenges.To the best of our knowledge, this is the very first fully distributed blockchain-based PKI framework that does not require the service via root CA.The distributed nature can eliminate centralized CA owners' unfair controlling/influence issues and the single point of failure issues of traditional root CA systems.• Formulate the protocols required for the certificate generation process so that it can be implemented in any blockchain network.

C. Paper Outline
The paper consists of nine sections.Section II presents the related background of this paper, including network slicing, Elliptic Curve Qu-Vanstone (ECQV) certificates, security vulnerabilities in NF sharing, and related works, along with a comprehensive comparison.Section III presents the proposed framework for certificate management and NF authorization with the threat model and security features.Section IV provides comprehensive experiments performed in a real blockchain-based implementation using Hyperledger Fabric.An extensive formal and informal security analysis of the protocols of our framework is presented in Sections V and VI, respectively.Section VII highlights the limitations of our framework and potential solutions for them.Finally, Section VIII concludes the paper with potential future research directions.

II. BACKGROUND
In this section, we will provide the required background related to this paper.The significance of network slicing, ECQV certificates, security vulnerabilities in NF sharing, and existing research related to our paper are described here.

A. Network Slicing
The expansion of diverse applications such as autonomous vehicles, the military, and healthcare intensifies heterogeneous communication requirements.For instance, real-time, ultrareliable connectivity is required for autonomous vehicles, but for environmental monitoring applications, those are not critical.Traditional telecommunication networks can not facilitate these diverse requirements using a single physical network.Deploying a physical network for each application is also not feasible due to the cost.Network slicing has the potential to address this problem in different application domains.Figure 5 shows how traditional telecommunication networks are evolving to a network-slicing-enabled environment to realize diverse applications.

B. Elliptic Curve Qu-Vanstone (ECQV) Implicit Certificates
Generally, public-private key schemes such as Rivest-Shamir-Adleman (RSA) are computationally expensive.However, Elliptic Curves (ECs) allow us to develop publicprivate key schemes which can achieve higher security levels with smaller key lengths [14].An elliptic curve in a finite field F p can be denoted as y 2 = x 3 + ax + b, where a, and b are constants in F p such that Δ = 4a 3 + 27b 2 = 0. We denote the generator of the curve by G.
Digital certificates are the best-known method for establishing digital identities in network communications.However, traditional certificates, also known as explicit certificates, have several limitations in terms of infrastructure, memory, and bandwidth.Also, acquiring a publicly trustworthy certificate is a very costly operation (around $60 per year on average) [15].Implicit certificates enable a low-resource trust model where the public key and the digital signature of a particular certificate are superimposed together so that the required bandwidth is minimal, as the certificate and the verification key are not required to transmit together.Implicit certificates are faster and smaller than conventional explicit certificates.
ECQV certificates are a kind of implicit certificate that is designed to perform the functionality of the general certificates in an environment where resources, such as bandwidth, computing power, and storage, are limited [16].Figure 6 shows the process of generating an ECQV certificate.Initially, the user (U) selects a random scalar number r u and calculates the EC point (R U = r u G) corresponding to the selected number.Then, the U sends the information that needs to be in the certificate, Cert info , and R U to the CA.Then, CA also selects a random number c and calculates the public parameter of the certificate, P U = cG.After that, the CA generates the certificate Cert U using Cert info and P U and calculates the hash of the Cert U , e. Finally, CA calculates the private key contribution of the CA, a, and sends back a and Cert U to the U. U can calculate its private key, d U = er u + a, and public key Q U = eP U + Q CA as shown, where (d CA , Q CA ) is the private and public key of the CA.

C. Blockchain
Blockchain is a decentralized and distributed ledger technology that acts as the underlying technology of several digital cryptocurrencies [17].Decentralization, transparency, Authorized licensed use limited to the terms of the applicable license agreement with IEEE.Restrictions apply.immutability, and auditability are some of the key features of blockchain technology.Due to these different advanced features, blockchain is utilized in several applications, such as healthcare facilities, risk management, and social services [18].Moreover, blockchain has gained significant attention in the research community to develop security applications due to its features.
Typically, a blockchain network consists of a sequence of cryptographically bound blocks.Figure 7 illustrates an example blockchain network.Each block points to the immediate previous block, called the parent block,by storing the hash of the corresponding block.Therefore, if anybody changes a previous block in the network, he has to alter every block after that block and all the nodes which maintain a copy of the ledger in the network.The first blockchain block, the genesis block, has no parent.A smart contract is a computer program stored in the blockchain that can be used to implement custom logic to implement some operations.In this paper, the Hyperledger Fabric blockchain network, which is an opensource blockchain platform, is used in the implementations.

D. Related Works
Authentication and authorization are a couple of key security aspects in telecommunication networks.As per the 3GPP, future telecommunication networks use certificates for mutual authentication, and they use RE presentational State Transfer (REST) for the internal communications between NFs [19].However, the certificate management processes, such as certificate issuance, cross-domain trust, certificate validation, and certificate revocation, are not clearly described in the specifications.Traditional PKI architecture has several limitations when applied to telecommunication networks.Using a commercial CA to handle certificates would be a very costly operation as deploying NFs and network slices is a frequent activity in telecom networks.If we use an internal CA to handle certificates, communication between NFs that are deployed in multi-domain network slices is not possible, as certificates are only visible to the internal network.
The various iterations of ECC in multi-party computation schemes and multi-party signing protocols have been explored in existing literature.In [20], a highly efficient non-interactive key-exchange (NIKE) mechanism is introduced.This mechanism enables the generation of a shared key within a group by leveraging contributions from its members.Additionally, in [21], Payeras et al. present a multi-party contract signing framework that eliminates the need for a trusted third party by utilizing ECC and blockchain technologies.Furthermore, Dai et al. propose a robust three-factor authentication scheme tailored for wireless sensor networks, employing ECC [22].This scheme is specifically designed for a multi-gateway environment, aiming to minimize the number of authentication messages while maintaining the desired security standards.Although there are existing implementations of multi-party signing protocols and key-sharing schemes utilizing ECC, none seem to incorporate a single key generation mechanism leveraging contributions from multiple parties.To the best of our knowledge, as of the time of conducting this research, the key generation mechanism proposed in this paper, utilizing ECC and an extended version of ECQV with multi-party contributions, represents the first such implementation documented in the literature.
A blockchain is an emerging approach to implementing PKI frameworks in existing research.In [23], Kubilay et al. proposed a blockchain-based PKI framework known as CertLedger to eliminate the split-world attack and to provide certificate/ revocation transparency.Trusted CA certificate management, validation, revocation, and storage are managed through the blockchain in their platform.In [24], Hewa et al. proposed a framework to manage ECQV certificates for IoT devices through a blockchain platform.Blockchain is used to simplify the certificate issuance and revocation processes in this research.ProofChain is a blockchain-based PKI framework that was proposed to select a CA randomly from a certificate pool to handle certificates [25].In [26], Yakubov et al. proposed a PKI framework that can issue an extended version of X.509 certificates.Khieu and Moh introduced an architecture for Public Key PKI hosted in the cloud, leveraging blockchain technology to establish secure access to certificate data and revocation lists [27].In [28], Adja et al. presented a system for managing certificate revocation and verifying certificate statuses using blockchain technology, with a specific focus on X.509 certificates and their extension while utilizing the blockchain ledger for revocation information storage.Luo et al. proposed a blockchain-based PKI framework with a focus on scalability, employing redactable blockchains to address certificate revocation challenges [29].Building upon Luo's architecture, ChainPKI, as discussed in [30], was designed to address privacy concerns within PKI frameworks.However, all these existing works rely on a single-parent CA, and if it is vulnerable, it impacts all the users in the network.Also, this CA is a single point of failure.
A framework for managing certificates using a blockchainbased PKI is proposed in [31].Also, they have proposed an optimization method to improve certificate storage efficiency and revocation simplicity.In [32], Yan et al. extended the framework in [31] to perform a decentralized certificate management framework in an NFV environment.However, these systems are also subject to the mentioned drawbacks in existing PKI frameworks.
3GPP specifies that the authorization between NFs is handled by the NRF using Oauth2 access tokens [8].However, as highlighted in [10], this system is vulnerable to the abovementioned security attacks when the NFs are shared between network slices.At the time this research is being conducted, to the best of our knowledge, no existing research can be found to mitigate these vulnerabilities in the authorization process.

E. Comparison Table With Existing Works
Table I shows the feature-wise comparison of the proposed certificate issuance framework with existing proposed frameworks.The key-related works were selected considering the relevance to our approach, implementation details, and experimental results.The feature list is extracted from the proven results of the experiment.From the comparison of the Table I, we can deliberate that our certificate issuance framework outperforms, considering other related works.

III. PROPOSED FRAMEWORK
In this section, we present our proposed frameworks, along with the considered threat model and security features, for the certificate issuance process in telecommunication networks and for authorization between NFs for managing access tokens.While the certificate issuance framework targets certificate management in telecom networks, we mainly considered the mitigation of mentioned security attacks in the authorization framework.Table II denotes the used notations throughout the paper.

A. Threat Model
During the certificate creation, we take the assumptions of the Dolev and Yao [33] threat model in order to depict the robustness of the designed decentralized certificate management framework for mutual authentication.This model suggests that an attacker (α) is capable of carrying out a variety of tasks.
• During the production of certificates at the MNO and NF levels, α has the potential to intercept the messages being exchanged.
• α has the potential to replay the intercepted exchanged message.

TABLE II NOTATIONS
• α has the potential to acquire the long-term secrets used in the production of certificates at the MNO and NF levels.
• α has the potential to interlink the exchanged messages of various successful certificate creations in order to trace the location of MNOR.• α has the potential to impersonate the entity involved in the production of certificates at the MNO and NF levels.

B. Security Features
The following security features [34], [35] are verified during the production of certificates at the MNO and NF levels.
• Resilient against replay attack: Previous session messages that have been captured prevent the attacker from sending the same message again to obtain a response.• Resilient against traceability attack: In order to track down the location of the entity engaged in the generation of certificates at the MNO and NF levels, the attacker will not be able to interlink messages from prior successful sessions that have been captured.

C. Decentralized Certificate Management Framework for Mutual Authentication
According to the 3GPP specifications, Transport Layer Security (TLS) certificates are employed to mutually authenticate different network functions.In this paper, we designed a blockchain-based decentralized certificate management framework to issue, validate, and revoke certificates in an environment that consists of network slices created by multiple network operators.Figure 8 shows the considered environment with relevant entities.In our solution, we eliminate the requirement of a central trusted entity as the root of the certificate chain for the certificate management process.A decentralized trust-building mechanism is proposed to perform the functionality of the root certificate authority.
As we build trust using multiple parties in the network, communication with multiple parties is required when issuing a certificate.This is a costly operation to follow all the time when issuing certificates.Therefore, only MNO-wise certificates are issued using the distributed trust mechanism, and as NFs are internal entities in an MNO environment, the MNO can manage certificates of NFs.Thus in our solution, we maintain certificates in two levels, i.e., MNO level and NF level (Figure 9).Implicit certificates with elliptic curve cryptography are utilized to provide authenticity, confidentiality, integrity and non-repudiation in the communication in the considered environment.
1) System Initialization: The functionality of our framework depends on a blockchain network.A private, public, or consortium blockchain can be utilized to create our framework.The users are required to be able to communicate with the blockchain network.We assume that all the entities in the blockchain network possess a public-private key pair with them, as almost all the available blockchain networks employ such a mechanism for communication between the blockchain and the user.For simplicity, we assumed that there are only telecommunication-related entities such as network operators, service providers, Local 5G Operators (L5GOs), and infrastructure providers are available in the network.However, we can use any type of user who is willing to participate in the certificate generation process in the blockchain with our framework.
2) MNO Certificate Generation: The considered environment consists of multiple MNOs, and we consider them at the highest level of the certificate trust hierarchy.Initially, the domain parameters of the elliptic curve {F P , a, b, G} are distributed in the blockchain ledger.When a particular MNO requires a certificate, it sends a certificate-issuing request to the smart contract in the blockchain.Then, the smart contract executes the group trust-building mechanism to generate the certificate.The procedure for MNO certificate generation is shown in Figure 10.
• T 2 is the current timestamp, and T is an agreed parameter in the system to check the freshness of a request.
• Step 4: Upon decryption of the received request using d B , O R checks the freshness of the message using Equation (4).T 3 is the current timestamp.Then O R solves the received DoS puzzle.O R calculates a nonce so that the preceding d dos number of bits of the hash of the X O ||X B ||nonce is equal to zeros.
• Step 5: O R generates M3 using Equation ( 5).The message contains X O , nonce, T 3 , and the signed hash MAC of the message.X B is used as the key in the hash MAC calculation.
• Step 6 C O checks the freshness of the received message with current timestamp T4 using Equation ( 6), validates the hash MAC and confirms whether the received nonce resolves the sent dos puzzle.
• Step 7: C O selects n number of MNOs in the blockchain network based on the reputation score.The reputation score for a particular MNO, O rep , can be calculated using Equation (7).It is based on the number of NF certificates of the MNO (N owned ), the number of contributions for certificate issuance (N contributed ), and the number of revoked certificates in the MNO network (N revoked ).
After arranging the reputation scores in descending order, a number of n MNOs with the highest reputation scores are selected for the certificate generation procedure.The n depends on the number of available MNOs in the blockchain network.
• Step 8: Cert R is generated using the received Cert info and the public parameter, P for a particular certificate is calculated using the public keys of the selected MNOs and received parameter from O R (Equation ( 8)).Then the hash of the Cert R and P, e is calculated (Equation ( 9)).
• Step 9: A random number X k is selected and M4:k is calculated and sent to each selected MNO.Each message is encrypted using the public key, Q k , of the selected MNOs.T 4 is the current timestamp.
• Step 10: Each MNO decrypts the received message using its private key, validates the freshness of the received message, and confirms that the X O is stored in the blockchain ledger.This ensures that the request is sent by the blockchain network.12)).Each hash mac of M5:k, which is calculated using the received X k as the key, is signed using the d O:k .T k is the current timestamp.
• Step 15: Finally, O R validates the freshness of the received message and calculates e and the private key, d R using the parameters in the received message.X O is used to identify that the messages belong to the same certificate generation process.
If any of the intermediate steps fail, O R receives M Error (Equation ( 16)).
The proof of the distributed multi-party private key and public key generation procedure is as follows.
Authorized licensed use limited to the terms of the applicable license agreement with IEEE.Restrictions apply.
3) NF Certificate Generation: When a new NF is deployed, a certificate needs to be generated and stored inside it for the NF's communication purposes.The Network Slice Manager (NSM) generates the required certificates with the support of the blockchain and the security orchestrator (SecOC) in the MNO. Figure 11 shows the procedure for generating certificates for NFs.
• Step 1: The NSM selects an initial scalar r R and calculates a point,R R = r R G on the EC.Then, Cert info is generated, including all the required information of the new NF.The initial message M 1 is produced concatenating the identity of the MNO (ID MNO ), R R , a random number (X O ), and the current timestamp (T 1 ).The M 1 is signed using the wallet private key (d B ).
The NSM keeps the r R within itself securely to calculate the private key of the new NF, d N .• Step 2: Smart contract-related issuing certificates for NFs, C N receives the M 1 , and it confirms that the signature is valid and the message is fresh (Equation ( 24)).Then C N generates the NF certificate, Cert N , including the details in Cert info .The public parameter of the Cert N , P N , and the hash of the Cert N , e N , are calculated using and 26, respectively.
• Step 3: C N originates the M 2 including the e, X O , and current timestamp T 2 and sends the M 2 to the security orchestrator, SecOC, of the MNO.The content of the message is encrypted using the public key of the MNO, • Step 4: The SecOC decrypts M2 using the private key of MNO, d MNO , and validates the freshness of the message (Equation ( 28)).T 3 is the current timestamp.
Then it selects an EC point, {r S , R S }, considering the curve parameters in the blockchain.The private key contribution parameter, a S , is calculated as shown in Equation (29).
• Step 5: After calculating the MNO contribution for the NF key pair generation, the SecOC originates M3.M3 contains {a S , R S }, ID MNO , X O , and T 3 .The content of the message is signed using the d MNO .
• Step 6: Upon receiving the M3, C N validates the freshness of the message and verifies the signature.Then, it calculates the public key of the network function, Q N , using equation (32) and stores it in the ledger.
• Step 7: C N generates the M4, which contains the parameters required to calculate the private key, d NF , of the new NF.Additionally, M4 consists of X O , and the current timestamp T 4 , and it is encrypted using the Q MNO .
• Step 8: Finally, the NSM decrypts M4 and validates the freshness of the message as shown in Equation (34) (T 5 is the current timestamp).Then, it calculates the hash of the Cert N , e N , and the private key of the new NF, d N as follows.
If any error occurs in the procedure, the NSM receives M ERROR (Equation ( 36)).X O is used to identify the messages in a single NF certificate generation procedure.
Authorized licensed use limited to the terms of the applicable license agreement with IEEE.Restrictions apply.

D. Blockchain-Based Authorization Framework
The authorization between NFs is handled by the Network Repository Function (NRF) in traditional 5G networks.There are two methods for communication between NFs in 5G networks: direct communication, which is communication directly while receiving an access token from NRF, and indirect communication, where communication is through a Service Communication Proxy (SCP), which gets the access token from the NRF [9].However, this system is vulnerable to mentioned security attacks when NFs are shared between network slices.Therefore, we designed a novel authorization framework for 5G and beyond networks with the support of blockchain.
When a particular NF is shared between network slices or deployed in a network slice, NSM generates a transaction request which includes the NF id and the corresponding slice id and sends it to the blockchain network.We can use the same blockchain network that we used to generate certificates earlier here.This information can then be used when providing authorization between NFs, which are shared between multiple network slices across multiple administrative domains.
Figure 12 shows the proposed authorization framework for the direct communication between NFs.Here, N 1 denotes the consumer NF and N 2 denotes the producer NF.Initially, the N 1 mutually authenticates with the NRF using the certificates generated through our certificate framework.After verifying the certificates through the blockchain, N 1 and N NRF share the session key securely using the private-public key pairs.Then, acquiring the access token process is encrypted using the shared session key.N 1 sends the access token request, which includes a slice id.Upon receiving the request to NRF, it performs regular authorization checks to check whether the N 1 can access services in N 2 .In addition, it queries the blockchain to check whether the N 1 is actually deployed in the received slice.If NRF can find such a transaction and if other authorization checks are passed, NRF generates an access token, which is a JSON Web Token (JWT) including N 1 id, N 2 id, and slice id as claims in the token in addition to other required claims.
After receiving the access token from NRF, N 1 mutually authenticates with the N 2 following the same procedure for the authentication between N 1 and N NRF .Then, N 1 sends the service request to the N 2 with the received access token.N 2 validates the access token with the support of NRF, and if the validation is successful, it offers the service to N 1 .
This procedure covers the authorization for direct communication.However, with slight modifications, we can use the same procedure for indirect communication.

E. Deployment of the Framework in Blockchain
This framework can be deployed in a blockchain network to ensure trust and immutability.Figure 13 illustrates deploying the proposed framework in a blockchain network.A public, private, or consortium blockchain that supports smart contracts can be used with our framework, as we are not storing any sensitive information, such as private keys, in the blockchain.However, we have to follow the blockchain network-specific configurations when selecting an appropriate network, such as policies in the network.The consensus mechanisms, such as Proof of Work (PoW), Proof of Stake (PoS), and Practical Byzantine Fault Tolerance (PBFT), can be used with our framework according to the selected blockchain network.Mining is an essential functionality in blockchain networks.If we use a public blockchain, the existing miners in the network can also be used as miners in our framework.If we use a private blockchain deployed among MNOs, MNOs can be the miners in this network, as the functionality benefits all the MNOs in the network.
Primitively, we need to implement three smart contracts to implement the functionality of our framework.The functions related to these smart contracts are described earlier.Users communicate with the smart contracts using blockchainspecific Software Development Kits (SDKs), and smart contracts may need to communicate with external parties already members of the blockchain.The smart contract responsible for MNO certificate management must select and communicate with n MNOs to collect the contributions for MNO certificate generation.NF certificate management contract communicates with SecOC to generate a certificate for an NF.NF sharing management contract does not require communication with external parties for its functionality.Also, we must add all the requests and responses from external parties into the blockchain to ensure accountability and transparency.Therefore, the blocks that are created in the blockchain with our framework should contain transactions related to inbound and outbound requests and responses, issued certificates and their status (revoked or not), and NF sharing details among slices.

IV. EXPERIMENTAL ANALYSIS
In this section, we provide details about the implementation of our testbed.Also, an analysis of the performed set of comprehensive experiments can be found at the end of this section.

A. Implementation Setup
We used Hyperledger Fabric (Version 2.1.0)to build a Proof of Concept (PoC) of our proposed decentralized certificate management framework.We have considered a blockchain network that consists of two organizations in the experiments.One organization has one peer node and two ordered nodes, and the other organization has one peer node and one orderer node.Peer nodes and orderer nodes are running as docker containers, and CouchDB is used as the state DB.The applications related to certificate requests, smart contracts, and responses for certificate requests are developed using Java and Web sockets.For comparison, a CA is developed using Java, and it is used with the same Hyperledger network, considering proposed architectures in existing certificate management frameworks.The size of the DoS puzzle used in the experiments is five zeros at the front of the generated hash.We implemented this framework in a machine with 16GB RAM and 8 CPU cores.
In our implementation, we developed the three smart contracts as we described in section III-E.One is for handling  the certificates for the MNOs, one is for handling the process of NF certificates, and the other is for handling NF sharing between network slices.Users (MNOs, NSM, and NRF) communicate with smart contracts deployed in peers.Orderers handle the process of ordering the transactions and distributing them across the network.All the experiments were performed several times, and averages were taken to eliminate inconsistencies in the results.

B. Performance Analysis Experiments of the Proposed Certificate Management Framework
Here, we experimented with the functionality and the performance of the proposed certificate framework.The impact of the multi-party contribution and performance analysis when processing batches of certificates are analyzed here.
1) Performing a DoS Attack on the Certificate Issuing Party: In this experiment, we investigated the impact of a DoS attack on the certificate issuance process.We have considered four scenarios in this experiment, i.e., a traditional CA-based system without blockchain [36], a single CA entity with blockchain as proposed in [32], a blockchain between the CA and certificate requested party [24], and our framework (Figure 15).We performed a DoS attack on the certificate issuer during the 20th and 80th iterations and measured the time to receive a certificate from the system.As we performed the DoS attack on a single entity in all the systems in our framework, we randomly selected an MNO and performed the attack on it.Four MNOs were deployed in the network, and one MNO was subjected to the DoS attack.We considered three MNOs randomly for certificate generation.
Figure 16 shows the received results in this experiment.Architecture (a) shows the minimum time to issue a certificate, as blockchain interaction is not required to issue certificates.Architecture (b) and architecture (c) show nearly equal values to issuing certificates due to the interaction with the blockchain.Our framework takes the highest time to issue certificates due to the involvement of multiple parties to issue a certificate.During the DoS attack, architectures (a), (b), Authorized licensed use limited to the terms of the applicable license agreement with IEEE.Restrictions apply.and (c) are subject to a nearly equal impact as they all depend on a single CA entity.However, proportionally (table in Figure 16), architecture (a) has the highest performance degradation when compared with normal time as in normal time, it consumes a very short time to generate a certificate.Even though architecture (b) and (c) faced approximately equal impact, when comparing the proportion, it is a lower value.Our architecture performed well during the DoS attack, as it does not depend on a single CA or entity to issue a certificate.The time consumed during the attack in our architecture can be further reduced by increasing the participating parties when there is a higher number of parties in the network.
2) Time to Issue an MNO Certificate: Here, we analyzed the time taken to issue an MNO certificate (root certificate for an operator) using our framework.We have increased the number of participating other operators and measured the time elapsed to generate a certificate.We also performed the experiment with the different settings of the blockchain network to assess the impact of these configurations on performance.
As shown in Figure 17, when the number of participating MNOs increases, the time taken to issue a certificate increases.An increment in the communication time needed to collect certificate contributions is the cause of this observation.The alterations of parameters in the blockchain network are not affected significantly by the results as shown in the graph Fig. 10.Fluctuations can be observed due to the time elapsed to resolve the dos puzzle, as the receiving dos puzzle is completely random in each request.
3) Time to Issue an NF Certificate: Issuing certificates for NFs is a frequent operation in an operator network.In this experiment, we investigated the time complexity of issuing our system certificates for batches of NFs.We submitted certificate requests as batches to our system, and we increased the batch size and measured the time elapsed to generate certificates for a particular batch during the experiment.The configuration parameters, such as block time and size, are altered, and experiments are performed with different settings in the blockchain network.
The time consumed with each blockchain setting and the average time for all the different blockchain settings is shown in Figure 18.As we increase the number of certificate requests in a batch, the time consumed to complete the total process increases with all the different blockchain settings.However, each higher block size (512 kB) corresponding to the same block time shows a higher completion time.A block is not  created until it receives the configured size of transactions or until the block time elapses.When the block size is large, the fabric should receive a higher number of transactions or transactions with increased size.Even if it receives some transactions, a new block is not created until the block time expires.However, when the block size is small, it creates blocks rapidly, and the created blocks are available in the blockchain before the block time elapses.This causes the observation of higher time consumption for larger block sizes.The exponentially increasing nature of the graphs is observed due to the increased amount of parallel processing required in the certificate-issuing application.
4) Ledger Storage Utilization for Storing Generated Certificates: Here, we have investigated the ledger storage utilization for storing the generated certificates with our framework, an extended version of the ECQV certificates against state of the art.Traditional ECQV certificates and RSA certificates are considered state-of-the-art in this evaluation.The certificate size in our framework is a bit larger than traditional ECQV certificates due to the number of contributions, and they are considerably smaller than RSA certificates.Blockchainbased implementations are evaluated in this analysis.For instance RSA - [23], [26], ECQV - [24].The simulation parameters are extracted from the [37].Also, we considered different security levels for these different certificate types in this simulation for more elaborate results.
Figure 19 illustrates the received results of this investigation.As there is no impact from the number of contributors for ECQV and RSA certificate generation, the storage utilization in the ledger is constant with these certificate types.Initially, when the number of contributors is low, the storage utilization for a particular certificate in our framework is considerably lower than RSA certificates and slightly higher than traditional ECQV certificates.However, when the number of contributions rises, storage utilization continuously increases, and when it is very high, storage utilization exceeds the storage required for RSA certificates.This observation can be seen due to the requirement to store the contributions from different MNOs for certificate generation with our framework.Also, we can see that when the security level increases, storage utilization increases in all three certificate types.

C. Experiments on NS-Related Attacks Mitigation
Here, we investigate how our framework mitigates the discussed three NS-related attacks in the background section (Section II).We show that the proposed improvements for the NF authorization in our framework can eliminate all three attacks.
1) Mitigation of Unauthorized Service Utilization: Here, we experimented with how our framework can mitigate unauthorized service utilization attacks.The direct communication scheme is used in this experiment, and authentication is performed using certificates.As shown in Figure 2, the cause for this attack is the NRF cannot check whether the malicious NF sends the correct slice id or not.However, with our system, when a particular NF is shared with a slice, that record is added to the blockchain.Then, before providing the access token, the NRF cross-checks the received slice id and the stored slice id in the blockchain against the NF id.If it matches, it provides authorization; otherwise, the request is denied.Therefore, our system can successfully mitigate this attack.In this experiment, we first configured the blockchain to store the VNF deploying details.Then, we sent service requests to the shared NF while misconfiguring the slice ids in the authorization request following the direct communication scheme.
Table III shows the received results in this experiment.The experiment is performed around 50 times, and the time for authorization is calculated with 95% confidence.The time consumed for authorization in our system has increased considerably compared with the traditional authorization system.We received an authorization token for legitimate requests, and requests are denied when we send malicious requests with an unauthorized slice id.Even though there is an apparent increase in the authorization time in our system, it could mitigate all the unauthorized service utilization attacks in the slicing ecosystem.Therefore, slice owners of the victim slice do not want to pay for unused services.
2) Elimination of DoS Attacks Due to Malicious Overload-Control Header: In this attack, even though malicious NF takes authentication, it can send the overload control header related to another slice for a shared NF, as shown in Figure 4.As we include the authorized slice into the authorization token in our framework, the shared NF can cross-check and validate the header.In this experiment, the malicious NF in slice two sends the overload control header related to slice one in the  30th iteration, and then it notifies the shared NF that slice one is back to normal in the 70th iteration.In this experiment, we measured the processed traffic percentages related to each slice through the shared NF.Here, we assume in normal conditions, slice one and slice two follow poison distribution when sending requests to the shared NF, and they send requests with λ = 30 and λ = 70 (λ is the arrival rate in the poison distribution) in respective slices.
As shown in Figure 20, in the reference system, during the 30th and 70th iterations, shared NF stops the interactions with slice one and only interacts with slice two.In our system, we generate a JWT token that contains the authorized slice id as claims.Therefore, the shared NF can cross-check the slice id in the overload control header with the slice id in the authorization token.Thus, the shared NF disregards the overload control header and continues the services as usual in our system.Therefore, slice one would not be subjected to a DoS attack with our system due to the malicious NF in some other slice, as in the reference system.Due to the blockchain access to validate the received slice ID in the authorization request, this experiment also takes a longer time than the normal authorization with the NRF.
3) Mitigation of Data Leakage Between Slices: In this experiment, we tried to access the data of a user in some other slice.As shown in Figure 4, this attack also happens due to the inability of the NRF to validate the correct slice before issuing the authorization.However, our system makes all slicesharing data against VNF ids available in the blockchain.The NRF validates the slice ids against VNF ids with the support of blockchain according to our framework.Even in a multidomain network slicing environment, our system can mitigate these unauthorized slice data accesses.
Table IV shows the received results of this experiment.Our framework could eliminate all the unauthorized data access in network slices.We received authorization tokens only when we sent a valid slice id in the authorization requests into the NRF.However, the time consumed for establishing a successful session between two network functions is significantly greater than the traditional method due to blockchain queries.

V. FORMAL ANALYSIS
The formal analysis section shows the security examination of the MNO certificate issuance and NF certificate issuance phases using the Oracle model known as Real-or-Random (ROR) logic [38], and widely adopted validation tool Scyther [39] used by many researchers to validate the security properties of the authentication protocol.

A. Formal Security Analysis Using ROR Logic
ROR is used in order to show that the attacker (α) will not get any secrets during the certificate generation at the MNO level and NF level.This logic was introduced by Abdalla et al. [38] to verify the protected communication protocols using cryptographic operations.Since both levels (MNO and NF level) use the same cryptographic parameters, we prove the security of the MNO level, which will also work for the NF level.During the certificate creation, the requesting MNO is called MNOR, Blockchain, and the n contributing MNOs, MNO1• • • MNOn, participate.These participants are represented by M i , B j , and O k n of the instances i, j and k.We use the same assumptions as taken by [38] and others papers [40], [41] during the proof that α can intercept exchanged messages and can perform the following acts such as editing and replaying in order to get the secrets used during the authentication.There are some queries defined thatα uses to get the secrets.The explanation of these queries is as follows.
• Execute (M i , B j and O k n ): This query is executed by α to intercept the exchange messages between M i , B j and O k n .• Reveal (E h ): α executes this query to get the private key betweenM i , B j and O k n .
• Send (E h , m): α uses the above query to intercept the messages betweenM i , B j and O k n and this query is used to send the forged message to theM i , B j and O k n to get the response in order to determine the secrets.
• Test (E h ): α uses this query to predict the actual secret key by tossing a coin C. It guesses on the basis of the outcome of the coin (i.e., C = 0, the communicating party returns the random number or C = 1, then the communicating party returns the private key.Otherwise, a null value is returned.)• Corrupt (E h ): α uses this query to obtain the secrets stored on the communicating entities involved in the certificate creation.

B. Semantic Security of the Session Key
This subsection shows that α can not get any secret information or random numbers used in the derivation of the private key of MNORduring the certificate generation from the captured exchange message between M i , B j and O k n .Theorem 1: If α violates the semantic security of keys derived during the certificate generation in the proposed scheme, then Adv α ≤ The terms utilized in the theorem are H Q , R Q , F Q , A, and B denotes the number of Hash, Send, Execute query,length of the hash function output value and range space of random number respectively.
Proof: We examine the security of the certificate generation similar to previous work of [34], [40], [41].We also took the same assumption as taken by [38] during the query and game execution.α utilizes three games to get the secrets of the certificate generation process.The three games G 1 , G 2 , G 3 are used, and an event Su αG 1 could be explained asα predicts the random bit during the execution of the game,and Pr [R αG 1 ] denotes the winning probability of G 1 .
Game(G 1 ): α simulates this game to obtain the value of C in order to get the secrets before the Oracle finishes the initialization of the process.
Game (G 2 ): Now α intercepts the exchanged message betweenM i , B j and O k n by running theExecute query.After getting the exchanged message, α runs theTest query to get any secrets through which he can derive the private key of MNO.However, it is not confirmed by executing the query that the value is real and random.This means that α fails to predict the value and loss of the game since all the secrets are transferred in encrypted form using the digital signature.Therefore, the winning probability of G 1 and G 2 will be similar.

Pr R αG
Game(G 3 ): In the game G 1 and G 2 , α tries to get any insights by running the Execute and Send query, but he fails, now he will execute the other query in order to get the random number through the exchanged messages.Since all the random numbers used in certificate derivations are sent in signed messages and generated using elliptic curve cryptography.However, some random numbers are sent in plain text, but they will not be useful in determining the rest used in the certificate creations due to the discrete logarithm problem.Apart from that, it is observed that running the Hashquery will not get any chance, and there will not be any collision.Thus, this shows that α also fails to win this game, and the winning probability of G 2 and G 3 are the same.Thus,we get the following outcome by adopting the birthday paradox.

Pr R αG
α has played the whole game and fails to win the game, so the winning probability to predict the bit C is from equations (37) (38), and (40), we can obtain We get the following result from Eq. ( 39) and Eq. ( 41).
Authorized licensed use limited to the terms of the applicable license agreement with IEEE.Restrictions apply.
This demonstrates that the attackers will not get any insights during the certificate creation to obtain the secrets used within polynomial time.

C. Perfect Forward Secrecy
This theorem is used to show that both levels preserve the perfect forward secrecy at the time of the certificate creation.
Theorem 2: Let us assume that α tries to get secrets stored on M i , B j and O k n and can derive the secrets that are different for different certificate creations then Adv α ≤ The G 1 , G 2 , and G 3 will be expected to be similar to Theorem 1.
(G 4 ): This game is similar toG 3 except the execution of the Corrupt query.The α executes the Corrupt query to get the random number used in the private key derivation since these numbers are not exchanged in the public channel.ECC is applied, and random numbers used in the derivation are generated that will not allow the attacker to get these random numbers; still, they have private and public keys of communicating entities through which they exchange the messages.Due to the hardness of ECQV (see Section III-A).Thus, due to the use of ECC, it is impossible to determine the secrets used in certificate generation even if α has secrets stored on the communication entities.So we have All four games have been played by the attacker to predict the value of C and then from equations (37) (38), and (44), we can obtain We obtain the following outcome from Eq. ( 43) and Eq.(45).
Thus, the proof of Theorem 1 and 2 demonstrates that α can not obtain the secrets by intercepting the message and by getting the long-term secrets within polynomial time.

D. Formal Analysis Using Scyther Tool
The security of the certificate creation at MNO and NF levels is verified using the Scyther tool.This is a well-known tool used to validate security protocols [34], [42].This tool utilizes the.spdl language to model the protocols.It uses  four types of claims to verify the security of the proposed protocol under well-known threat models such as Dolev and CK adversary models.The description of the query is as follows [43] • Alive-Successful execution of this claim indicates that all the events between the MNOR, Blockchain, MNOi and NSM, Blockchain, and Security Orchestrator have been executed.• Weakagree-Successful execution of this claim indicates that there is no DoS, impersonation, and replay attack.• Nisynch-Successful execution of this claim indicates that the traceability attack is not possible during certificate creation.• Niagree-Successful execution of this claim indicates that there is no non-repudiation attack and stolen verifier attack.We execute both protocols (certificate creation at the MNO level and NF level), which shows that all the specified claims have been passed by the mechanism designed for certificate issuance at MNO and NF levels.Therefore, we can infer from the outcome of the Scyther tool shown in Fig. 21 and Fig. 22 that there is no attack during the certificate creation.

VI. INFORMAL ANALYSIS
This section offers informally demonstrative evidence that no attack can occur at the MNO and NF levels during certificate creation.

A. Resilient Against Replay Attack
In order to prevent the replay attack, both levels (i.e., MNO level and NF level) use timestamps and nonces in every exchanged message.When any entity receives the message, it verifies the freshness using ΔT ≥ T i+1 − T i .We assume that the clock used by the communication entities during the certificate issuance is synchronized, similar to [41], [42].If this condition matches, then it is believed that the message is fresh, and the process continues further.Otherwise, they reject the message.

B. Resilient Against Traceability Attack
If the attacker intercepts <M 1, M 2, M 3, M 4> at NF level or <M 1, M 2, M 3, M 4:1, ..M 4:n, M 6> at MNO level and tries to interlink the intercepted message then he/she can not succeed due to the use of random numbers that are different for a different session.In both levels, during the message exchange, random numbers are used to restrict the attacker from interlinking with each other by capturing the exchanged messages.

C. Resilient Against Impersonation Attack
If an attacker tries to forge the message <M 1, M 2, M 3, M 4> at NF level or <M 1, M 2, M 3, M 4:1, ..M 4:n, M 6> at MNO level in order to get the secrets through which he can determine the certificate key, then this is not possible.All the messages use the digital signature mechanism that restricts the attacker from forging the message.If the attacker tries, then he will fail due to the random numbers used, which are unique in the process.

D. Resilient Against Non-Repudiation
The messages exchanged at both levels are signed, and only the legitimate entity can decrypt this.Therefore, if an entity denies it, then others can prove that the message is signed by your private key, and only you can decrypt it.

E. Resilient Against DoS Attack
Both at the MNO and NF levels,random numbers and timestamps are used to make sure that entities involved in the communication will easily and rapidly identify that the message is replayed.

F. Perfect Forward Secrecy
If the attacker obtains the public and private keys of the entity involved at the MNO level and NF level before the starting of the certificate process, then he can

G. Stolen Verifier Attack
An attacker can not get the secrets used in certificate creation at both levels even if they acquire the table of MNO and MNR.All the secrets are derived using Elliptic Curve Qu-Vanstone (ECQV), and random numbers used in the process are not transmitted in the channel, which shows that the attacker can not take the random number of the MNO and MNR.This shows that an attacker having access to such a table will not be able to obtain secrets.

VII. DISCUSSION
In this section, we discuss the limitations related to our solution and potential solutions for those limitations.
As we observed in the results, our framework takes a bit more time to generate certificates than the existing approaches.Currently, the smart contract communicates with the selected MNOs sequentially in our system.We can optimize it to communicate in a parallel way to reduce time consumption.In the current system, we add all the requests and responses related to the certificate generation into the ledger to increase accountability.This fills up the ledger rapidly.Optimized storage mechanisms can be developed for the ledger to address this challenge.Also, we can develop a system in which all the data is stored outside the ledger, but the hashes of the messages are stored in the ledger.Moreover, during the authorization process, our framework consumes more time than the existing mechanisms.A high-performance blockchain query mechanism can be implemented to reduce this time consumption.

VIII. CONCLUSION
This paper proposes a novel blockchain-based framework to eliminate the security challenges related to authentication and authorization in the 5G network-slicing ecosystem.A novel distributed multi-party certificate management framework using blockchain and ECQV certificates has been developed to facilitate the certificate management requirements to provide authentication services for network slicing in multi-operator environments.Also, we have designed the required secure communication protocols for certificate management.Moreover, the identified authorization security challenges in NF sharing between network slices are eliminated using the proposed framework.We implemented a prototype of the proposed framework using Hyperledger Fabric.The comprehensive experiments with the prototype showed that our framework could simplify the certificate management process in a multi-domain environment.For instance, it can eliminate interruptions in certificate generation and increase storage utilization efficiency.Also, the experiments showed that our authorization framework could mitigate the Authorized licensed use limited to the terms of the applicable license agreement with IEEE.Restrictions apply.
security challenges in NF sharing between network slices.Formal and informal verification of communication protocols illustrated that our framework is secure considering the mentioned threat model.
In the current implementation, we considered only MNOs and NFs in the certificate generation process.In future works, we intend to optimize the certificate management framework for all related entities in the telecommunication domain, such as VNF providers and Infrastructure providers.Also, in the experimental results, we observed that our framework takes a bit longer than traditional approaches due to the sequential communication with the set of MNOs in the certificate generation.We will optimize the system to reduce the time for certificate generation in future works.Furthermore, we will consider integrating our system with existing certificate frameworks such as commercial CAs.

Fig. 5 .
Fig. 5. Transformation of traditional telecom networks to network slicing system to support different applications.

Fig. 10 .
Fig. 10.Security flow diagram for the MNO certificate generation.

• Step 13 :
Upon receiving the M5:k from each MNO, C O validates the freshness of the responses.Also, C O confirms that the hash MAC is calculated using the sent X k and signed using the d O:k .• Step 14: C O calculates the public key, Q R of the O R as follows, generates M 6, and shares it with O R Q R = e * P +

Fig. 11 .
Fig. 11.Security flow diagram for the NF certificate generation.

Fig. 12 .
Fig. 12.The proposed framework for acquiring the authorization for inter-NF communication.

Fig. 16 .
Fig. 16.The impact of a DoS attack on the certificate issuer.

Fig. 17
Fig. 17.Consumed time for receiving an MNO certificate.
Fig. 17.Consumed time for receiving an MNO certificate.

Fig. 18 .
Fig. 18.Consumed time for a batch of NF certificates.

Fig. 20 .
Fig. 20.The impact of traffic flow through the shared NF due to the overload control header.
not derive the {(a K = rO:K + e * d OK ), (Q O:R = e * P + R O:1+ • • • + R O:n ), (d O:R = e * r R + a O:1 + • • • + a O:n )} due to the {e, r R , r O:K } at MNO level and {(a S = r S +e * d S ), (Q NF = e * P + R S ), (d NF = e * r R + a S )} due to {r R , r S }that is used in the certificate derivation due to the hardness of the discrete logarithm problem (see Section III-A).Although the attacker has long-term secrets, he can not determine the random numbers due to the hardness of the discrete logarithm problem.

TABLE I FEATURE
COMPARISON WITH KEY RELATED WORKS Resilient against non-repudiation: During the production of certificates at the MNO and NF levels, the entity involved can not deny that they have not applied for the certificate.
• Resilient against impersonation attack: It is impossible for the attacker to impersonate the entity involved during the production of certificates at the MNO and NF levels.•• Perfect forward secrecy: Acquiring long-term secrets will not allow the attacker to derive the private key during the certificate creation.• Stolen verifier attack: Acquiring the secrets stored on the blockchain and the security orchestrator will not allow the attacker to derive secret information of the certificate creation.
Cert info contains the details that need to be in the certificate, such as MNO id, MNO name, Mobile Network Code (MNC), and Mobile Country Code (MCC).After that, O R originates the certificate request which contains the identity of the O R , ID O:R , X O , R R , and the current timestamp T 1 .O R calculates the hash of the complete message and signs it using the wallet private key, d B .The first message from O R to the C O is as follows.M 1 = ID O:R ||R R ||X O ||T 1 ||Cert info || d B H (ID O:R ||R R ||X O ||T 1 ||Cert info ) (1) Step 1: In order to request a certificate by MNO, O R , selects an initial random scalar r R and computes the EC point, R R = r R G, associated with the established EC domain parameters in the blockchain.Then O R selects a random number X O and certificate information Cert info .O R keeps the r R within itself in a secure place to compute the private key (d R ) in future steps.•Step 2: After receiving the certificate request from O R , C O validates the signature of the message appended at the previous step using the public key, Q B of O R which is correspondent to the d B in O R 's wallet.Also, C O checks the freshness of the request using Equation (2).Authorized licensed use limited to the terms of the applicable license agreement with IEEE.Restrictions apply.
a random number X B and a DoS puzzle parameter, d dos , and sends M 2 back to the O R .M 2 can be calculated as follows.This DoS puzzle parameter supports mitigating the potential DoS attacks on other network operators in the blockchain network as the C O sends requests to a selected set of operators for each certificate request.
Then each MNO selects a random scalar r O:k and calculates the R O:k considering the established EC domain parameters.Then, each MNO calculates the certificate contribution parameter a O:K as shown in Equation (11).d O:k is the private key of each MNO.

TABLE III SYSTEM
BEHAVIOR FOR SERVICE UTILIZATION ATTACK

TABLE IV SYSTEM
BEHAVIOR FOR THE DATA LEAKAGE BETWEEN SLICES ATTACK