Packet Key-Based End-to-End Security Management on a Blockchain Control Plane

The existing LTE mobile system uses the vertical model to handle the session-based security management. However, the goal of this paper is to propose a packet key-based security management scheme on the blockchain control plane to enhance the existing session key-based security scheme and overcome the limitation that the existing vertical model, as well as the Software-Defined Networking (SDN) based horizontal model, confronts within solving end-to-end security management. The proposed blockchain-based security management (BSM) scheme enables each peer to easily obtain the necessary parameters required to manage the packet key-based security system. The important features of the BSM scheme include the renewal process, which enables the different packet data streams to use completely different security parameters for the security management. In addition, because even blind values cannot be exposed to the possible attackers, our BSM scheme guarantees very secure end-to-end data transfer against active attacks such as falsification of data and transactions. Finally, this paper compares the BSM scheme with the existing vertical model to prove the advantageous effects on latency.


Introduction
The main feature of the Long Term Evolution (LTE) system is to use two independent planes where the signaling information process is done by control plane and the user data process is done by a user data plane [1][2][3][4][5]. As depicted in Figure 1, security management functions are based on the vertical model which uses distributed servers such as Mobility Management Entities (MMEs) and Home Subscriber Servers (HSSs) in LTE networks. Thus, the integrated operation of network control on the control plane enables security management functions to be efficiently implemented within the range of local LTE networks. However, for the end-to-end security management throughout the Internet, different solutions have been explored to use the horizontal network function model [6][7][8][9].
The existing Session Initiation Protocol (SIP) based Voice over Internet Protocol (VoIP) call system uses the vertical model to handle the security management where multiple servers distributed over networks collaborate to control a secure session between the end-to-end peers. The Internet Engineering Task Force (IETF)'s direction is to use the horizontal model. One of the horizontal models introduced for the future 5G mobile networks is Software-Defined Networking (SDN) [10][11][12][13]. SDN is an emerging networking paradigm that changes the limitations of the existing vertical model including LTE network control model, which separates the network's control plane from the data plane [14]. In SDN, the control plane is implemented in a logically centralized controller, simplifying the policy The goal of this paper is to develop a blockchain-based security management (BSM) scheme which utilizes a packet key-based system to perform better and extends the scope in security management from the local area to the end-to-end security service range. As depicted in Figure 2, our BSM structure is close to the administrative control that the SDN-based horizontal model operates with. However, while the software-defined controller on the control plane functions as the control center, the BSM scheme utilizes one of the most innovative features of the blockchain where there is no central server running. BSM operates between two end-to-end peers without environments of the distributed servers and the centralized controller [21,22]. Thus, this idea gives significantly advantageous effects on the end-to-end security management by reducing the complexity of the system deployment and latency taken for the end-to-end secure session set up. From the latency viewpoints, our BSM scheme is more advantageous in security management because security parameter agreements between end-to-end peers can be easily obtained via blockchain. Furthermore, considering low latency of 1 ms in 5G networks (10 to 20 ms for 4G), our BSM scheme is more useful in 5G environments because it requires less computational load during secure session setup and the latency to the setup secure session is mainly affected by the network delay components [23][24][25].  The rest of this paper is organized as follows. In Section 2, this paper proposes and explains the BSM scheme. Then, Section 3 describes the improvement effects of the proposed BSM scheme. This paper will be concluded in Section 4.

Security Management on the Blockchain Control Plane
As shown in Figure 3, the blockchain-based security management (BSM) network architecture explains the feature of the control plane. The steps to run the network are as follows: 1.
New transactions, which include ToALL Tx and Peer-fitted Tx, are sent to the nearest super node (SN). After the SN receives the transaction message, it broadcasts the message to all SNs. Each transaction message contains several pieces of field data for security management, which will be described later.

2.
Like Bitcoin, our BSM scheme uses the consensus algorithm of PoW (Proof of Work When an SN finds a proof-of-work, it broadcasts the block to all SNs.

4.
SNs accept the block only if all transactions in it are valid.

5.
Nodes imply their acceptance of the block by working on creating the next necessary block in the chain, using the hash of the accepted block as the previous hash. SNs and ENs will always keep working on extending full blockchains and block-header chains respectively. 6.
The EN is responsible for updating its valid information for security management by pushing them into the blockchain. The valid information is contained in either ToALL Tx or Peer-fitted Tx.
Here, we define the latency from the moment a new transaction is announced to the network until the event that the transaction successfully gets in the blockchain as Time-to-Get-in-Blockchain (T GinB ). It is easy to adjust the average of TGinB value by controlling the block creation difficulty because our BSM scheme is based on the private blockchain among the SNs differently from the public blockchain where at least 51% miners have to agree for changing the difficulty [26]. Our BSM scheme adjusts this difficulty to target 1 second between blocks. The period of 1 second for T GinB means that it only takes 1 second on average for a certain EN's new information for security management to become available to other ENs since the transaction information becomes valid on the blockchain after 1 second from the moment when the transaction was sent to the network.

BSM Wallet
The following information, which is maintained in the wallet, is used for the security management.
• Prime number (q) and primitive root (α): global parameters in the Diffie-Hellman key exchange.

•
An array of secret values (X EN s), that is, Secret Value Vector (SVV), for packet key agreements.
The tasks performed by the wallet software also include: • generates the corresponding public key (pubKey) and the hash address (My_Hash_Addr), • generates an array of blind keys (Y EN s), that is, Blind Value Vector (BVV), using the equation of generates an array of index values (H EN s), that is, Blind Value Hash Table (BVHT), using the equation of H EN = Hash(Y EN ). 'Hash' is a one-way hash function which accepts the blind value as input (Y EN ) and produces a fixed-size message digest as output (H EN ).

Security Parameter Agreement between Peers by Using Blockchain
Transactions, which grow without ceasing, are stored into a distributed database called the blockchain. There are two types of transactions: ToALL Tx and Peer-fitted Tx. Each EN sends its ToALL Tx to the network in advance. This process belongs to the registration step. Then, the ToALL Tx allows a certain session initiator to reach the ToALL transaction information of the session responder. The Peer-fitted Tx is sent to the network in order that the session responder obtains the session initiator's Tx information during the session initiation stage. As illustrated in Figure 4, the BSM transaction consists of Transaction Input (TxIn) and Transaction Output (TxOut). The TxIn contains the signature and the public key computed from the EN's private key which creates the transaction. The first field of TxOut contains the hash address that identifies the owner of this transaction.   Figure 5 illustrates how the SNs handles ToALL Txs and Peer-fitted Txs to establish the packet key-based secure session. Each EN, which needs the blockchain-based security management services, should store its ToALL Tx information into the blockchain in the pre-session stage. This process belongs to ToALL Tx initialization stage. Now, let's assume the case that EN A wants to set up a packet key-based secure session with EN B . EN A first uses the Query/Reply procedure to obtain the EN B 's ToALL Tx information. After EN A succeeds to obtain EN B 's ToALL Tx information, it sends the secure session request message destined to EN B along with sending the Peer-fitted Tx to the network. When EN B receives the secure session request message from EN A , it extracts the Peer-fitted Tx from the blockchain. Then, all parameters for security management are agreed between the peers. Then, both peers renew their ToALL Txs. As a result of this renewal process, every session uses a different set of security parameters which contribute to guarantee a much more secure session.

Creation of ToALL Tx Blocks
The blockchain is a distributed database holding all the BSM transactions, that is, ToALL and Peer-fitted Txs, and keeps them secure. Figure 6 explains how the ToALL Tx information is stored in the blockchain. When a BSM application of EN A begins to work, EN A creates and maintains m-sized Secret . .

Obtaining the Peer's Information for Security Management
The procedure of a secure session establishment begins with the Query/Reply mechanism to obtain the peer's information for security management. Figure 7

Creation of Peer-Fitted Block
Because of the Query/Reply mechanism, EN A obtains (α B , q B ) and BVV B . Here, for the scalability of our BSM scheme, it is assumed that the session initiator and the session responder use different global parameters. This means that our BSM scheme can be used to secure end-to-end peers which belong to different groups. If the BSM scheme operates between end-to-end peers in the same group, the use of the Peer-fitted Tx is not necessary. Because the BSM scheme is scalable, it requires the additional steps to handle the Peer-fitted Tx. The additional steps are as follows.

•
The session initiator creates the Peer-fitted Tx.

•
The session initiator sends the Peer-fitted Tx to the network. • Some SN create a new block, which includes the Peer-fitted Tx and uses it to extend the blockchain.

•
The session responder finally extracts the Peer-fitted Tx from the blockchain.
Those steps contribute to increase latency to complete the procedure of the secure session setup. This increased latency issue results in limitation of the BSM scheme.

Security Parameter Agreements between Peers
As shown in Figure 9, EN B can maintain security-related parameters: SVV B , BVV A , and the index  Figure 9. Security parameter agreements between peers.

Renewal Process for the Security Parameters
The secure aspect of our BSM system is due to the fact that each secure session establishment procedure uses the different set of security parameters: SVV, BVV, and BV HT. Each EN uses a different SVV of [(1, X 1 ), (2, X 2 ), (3, X 3 ), · · · , (m, X m )] every session. This means that once SVV is used, the previous SVV is replaced with new SVV * . Thus, the BVV * , which calculated from the new SVV * , needs to be made public. This is the ToALL Tx renewal process shown in Figure 10.
A,i mod q A . Then, the ToALL Tx, which includes the value field of (α A , q A ) and BVV * A , is sent to the network.

Effects on Security
The most attractive feature of the packet key scheme is that there is little chance to reuse the same packet key for a continuous packet data stream. Additional advantageous effects are as follows. As shown in Figure 10, the renewal process of the BSM scheme enables the different packet data session to use completely different security parameters for security management. Therefore, our BSM scheme is secure against the powerful eavesdroppers who use brute-force approaches even to try after-transmission attacks. Our BSM scheme also uses BVHT to indicate the index value associated with the packet key used. The one-way hash function accepts the blind value selected from the BVV as input and produces a fixed-size hash value as output, which is used as the index value. As shown in Figure 11, each datagram in a secure datagram flow contains the corresponding index value for a certain blind value. This means that our BSM scheme protects the blind values while the existing Diffie-Hellman key exchange method exposes the blind values. Instead of the blind values, exposing the hash values to the possible attackers contributes to our BSM scheme to lead to very secure end-to-end data transfer systems against active attacks such as falsification of data and transactions.

Effects on Latency
In SIP-based VoIP call operation, an end user sends SIP requests to initiate a session. Figure 12 shows a series of steps required to complete a packet key-based secure VoIP session set up between two ENs. This paper calls the existing SIP plus packet key model shown in Figure 12 a "vertical model". Some assumptions are necessary to perform the comparative analysis with respect to total latency to complete security management between EN A and EN B , where they are located in different domains. This paper assumes three types of delays, that is (1) T Intra : intra-domain delay caused in intra-domain links, (2) T E2E : end-to-end delay caused in end-to-end path, (3) T BVV : processing delay caused to compute BVV, and (4) T GinB : latency for creating a block. Table 1 shows comparisons on latency needed to set up a packet key-based secure session between the proposed BSM model, the non-scalable BSM model, and the vertical model. Figure 13 shows the secure session setup procedure for the non-scalable BSM scheme. Compared to the proposed BSM scheme in Figure 5, it is shown that the secure session setup procedure for the non-scalable BSM scheme is much simpler.  Figure 13. Secure session setup procedure in the non-scalable BSM model. Table 1. Comparisons on latency needed to set up packet key-based session.

Models Latency to Setup a Secure Session
Proposed BSM model 2T Intra ((1), (2) in Figure 7) 1T BVV ((3) in Figure 8) 1T GinB ((4)+(5)+(6)+(7) in Figure 8) Non-scalable BSM model 2T Intra ((1), (2) in Figure 13) 1T E2E ((3) in Figure 13) 2T Intra ((4), (5) in Figure 13) Figure 12) 2T BVV ((a), (c) in Figure 12) The latency of T BVV changes depending on the size of BVV as well as the size of the secret value. Here, the size of the secret value, as well as the blind value, is the same as that of the packet key. Recall that calculating each component of the BVV needs the corresponding latency for the computation of α A X A,i mod q A . Table 2 shows experimental data on computational latency needed to compute each blind value for a given secret value. The results were obtained from the testbed with 2.2GHz i7-8750H CPU. Then, the m-sized BVV requires m times the above latency.  Figure 14 plots the total latency to set up the packet key-based secure session in the BSM model, which corresponds to the latency of 2T Intra + 1T BVV + 1T GinB . Here, we assume that 2 × T Intra is 0.4 s and T GinB is one second.  Figure 15 plots the total latency to set up the packet key-based secure session in the non-scalable BSM model, which corresponds the latency of 4T Intra + 1T E2E . Here, we assume that 4 × T Intra is 0.8 s and T E2E is 0.5 s. For the non-scalable BSM model, the total latency is independent of the parameter of T BVV . It is shown that the total latency to setup the packet key-based secure session can be dramatically reduced if the proposed BSM scheme operates in the limited scale. Packet key size (bits) Packet Key Session Setup Latency (Sec) Size of BVV, m=400 Size of BVV, m=800 Size of BVV, m=1200 Size of BVV, m=1600 Size of BVV, m=2000 Figure 15. Total latency to set up a packet key-based secure session in the non-scalable BSM model. Figure 16 plots the total latency to set up the packet key-based secure session in the vertical model, which corresponds to the latency of 2T E2E + 2T BVV . Here, we assume that 2 × T E2E is one second. The use of packet key guarantees very secure data flow [27]. However, the latency to set up the secure session needs to be limited to below several seconds. In Figure 14, it is shown that the BVV size of 1600 and the key size of 2048 bits are enough to satisfy the session set up latency below 10 s. On the other hand, according to Figure 16, the condition of 1600-sized BVV and 2048-sized key causes the latency to rise beyond 20 s. If the vertical model uses the BVV size of 2000 and the key size of 2048 bits, its packet key session setup latency tends to increase up to 30 s. As a result, it is proved that, compared with the vertical model, our BSM scheme effects are better by almost 200% on latency to set up a secure session while it provides the same security level as the vertical model.  Table 3 shows comparisons on two kinds of network delay components for the 3G, 4G and 5G networks. According to [24], T Intra can be reduced to 2 ms in 5G networks while T Intra of 20 ms is required in 4G networks. Then, it is reasonable to consider that T E2E values in 4G networks and 5G networks are 50 ms and 5 ms, respectively. Figure 17 plots the latency comparisons for different models. Those latency results are based on the conditions that 3G networks work and the size of BVV is 400, that is, m = 400. Considering that in the packet key scheme different keys are supplied for different packets, packet key size of around 512 bits is enough to satisfy the secure session. It is shown that either the proposed BSM model or the non-scalable BSM model guarantees latency level of 2500 ms even in 3G networks.

512 1024
Packet key size (bits)   Packet key size (bits)  Figure 19 plots the latency comparisons for different models in 5G environments where m = 400. In 5G environments, with the key size of 512 bits, latency level can be reduce to 2000 ms in the BSM model. In addition, the non-scalable BSM model guarantees much less latency level as the 5G networks serve very fast data rates.

Conclusions
Existing phone systems, such as SIP-based VoIP call systems, use the vertical model to solve issues relating to the security management. As of now, as IETF suggests, an alternative solution is to use the SDN horizontal model where a centralized software-defined network controller on the control plane is in charge of security management. The goal of this paper is to introduce blockchain technologies to manage a packet key-based security system, which can overcome the limitation that the vertical model is confronted with. While the packet key-based security system can provide very strong security strength, it needs a high computational power to agree on security parameters between peers at the packet key session setup phase. Our BSM scheme is advantageous from the perspective that, using blockchain, each peer can easily obtain the necessary parameters required to handle security management.
Advantageous effects in our BSM scheme result from the renewal process, which enables the different packet data sessions to use completely different security parameters for the security management. Therefore, our BSM scheme is secure against the powerful eavesdroppers who use brute-force approaches even to try after-transmission attacks. In addition, in our BSM scheme, corresponding hash values travel together with the secured datagrams so that even blind values cannot be exposed to the possible attackers. This contributes our BSM scheme to lead to very secure end-to-end data transfer systems against active attacks such as falsification of data and transactions. From the viewpoints of latency, the BSM scheme performs better by around 200% than the existing vertical model. Author Contributions: Y.J. initiated the idea, designed the security management scheme and wrote the paper; M.P. made contributions in the proposed security management scheme and edited the paper; R.A. conducted the experiment setup and helped to finalize the paper.

Conflicts of Interest:
The authors declare that there are no conflicts of interest regarding the publication of this paper.