Attribute identification based IoT fog data security control and forwarding

Attack model

Assuming that an SDN architecture has been established in the IoT, Fig. 2 illustrates the security threats encountered during the data forwarding process in the IoT. The data in the figure originates from IoT devices, and the receiver is a fog node or a fog server. The solid part of the figure depicts the data forwarding process, and the dashed line indicates the control process of the controller to the IoT switch. Lines of different colors denote different types of data streams. The following describes the data streams shown in the figure:

Security dataflow: A legal IoT device sends a data packet to switch A (1). After receiving the packet, switch A checks whether it has the flow table information required for controlling and forwarding the packet. If switch A has the information, it forwards the packet according to the flow table information (4). If switch A does not have the flow table information that matches the packet, it sends a request for flow table information to the controller (2). Upon receiving the request, the controller sends the corresponding flow table information to switch A and switch B (3), and switch A forwards the packet according to the flow table information (4). After receiving the packet from switch A, switch B performs the same process as switch A and forwards the packet to Fog Device A.

Unauthorized access: Unauthorized IoT devices or users transmit data within the IoT. Unauthorized devices and users refer to those that have not obtained IoT authorization. When an unauthorized device (user) sends a data packet to switch A (1-2), switch A cannot differentiate between authorized and unauthorized devices, and will forward the data packet from the malicious device to Fog Device A according to the same process as for secure data packets (4-2,5-2), thus exposing Fog Device A to attack.

Matches forgery: Malicious nodes in the network forge match items such as IP address, device information, etc., and deceive switching devices to forward data streams abnormally. For example, Switch A is a malicious node (the attacker pollutes the switching device by exploiting vulnerabilities, implanting malicious software, ARP spoofing, etc.), and it forges the match item of the data stream and sends it to switch B (4-3). Switch B forwards the data stream to the wrong Fog Device B (5-3) according to the tampered match item.

Data tampering: The malicious nodes in the network tamper with or inject malicious content into the payload of the transmitted packets. For example, suppose that switching device A in the figure is a malicious switching device, which tampers with the received security data packets and forwards them to switch B (4-1). Because the matching items of the data packets tampered with have not changed, switch B forwards the data packets to Fog Device A (5-1) according to the processing flow of the security data packets. At this time, Fog Device A may be subject to network attacks.

Objectives

To address the security threats encountered during the end-to-end data forwarding process in the IoT fog architecture, we aim to propose a scheme for secure control and forwarding of data streams. The objectives we hope to achieve with this scheme are as follows:

1. To authenticate the origin of data initiators, it is essential to permit only devices that adhere to the access control rules to transmit data within the network. Simultaneously, by integrating the characteristics of data initiators with SDN matching criteria, we can achieve precise access control for data initiators and fine-grained control and forwarding of data flows.

2. To detect and block abnormal packets that have data tampering and matching item forgery, and provide the function of tracing malicious data that enter the network, ensuring the security of data transmission.

3. To choose an appropriate sampling method for sampling and verifying data flows, it is crucial to avoid creating excessive verification overhead. Such overhead could significantly affect both data transmission efficiency and network performance.

Attribute identification based security control and forwarding

To ensure secure data transmission within the IoT fog architecture, we have developed the AISCF model architecture. This section provides an overview of AISCF, covering four key aspects: the overall architecture, the attribute identity structure, the attribute signature scheme, and the AISCF implementation.

Overall architecture

In AISCF, first, the data initiator needs to obtain the key from the key generation center (KGC) according to its own attribute characteristics, and the attribute identification adding module adds the attribute identification header to the data packet and sends it to the network. The ingress switch judges whether the data packet has attribute identification, and matches and forwards the qualified data packet based on the attribute identification. The intermediate forwarding device only performs matching forwarding based on attribute identification for data packets. The egress switch samples the data packets while forwarding them, and sends the sampled data packets to the controller. The controller performs security verification on the sampled packets based on the attribute signature parameters obtained from the KGC. Figure 3 depicts the AISCF architecture.

The AISCF architecture consists of several components, each serving specific functions:

KGC: The KGC is responsible for generating and distributing keys used in the packet attribute signature phase. Users provide their own attribute set and attribute policy set for the signature. The KGC verifies the attribute policy set, generates the key, and provides users with the attribute private key required for signature. Additionally, the KGC maintains communication with the controller, supplying the attribute policy set and system public parameters needed for verifying attribute signatures.

Attribute identification adding module: The attribute identification header is added to the packet to realize control forwarding and security verification of data packets entering the IoT based on attribute identity.

Forwarding device: The forwarding device selects the programmable P4 switch that can effectively identify the attribute identification field and processes its contents. We classify the switches into ingress switches, intermediate forwarding devices, and egress switches based on the packet forwarding order. These switches realize their respective functions according to the multilevel flow table. The ingress switch identifies the attribute identification field of the incoming packets and only forwards the packets with attribute identification according to the flow table information. The intermediate forwarding device only forwards the packets that match based on attribute identification. The egress switch dynamically samples the incoming packets and uploads the sampled packets to the controller, while forwarding the unsampled packets based on attribute identification.

Controller: The controller adopts a dynamic sampling mechanism based on data packet security verification, which dynamically updates the sampling factor according to the verification results of the sampled data packets, and controls the egress switching devices to perform dynamic sampling on the data flows. The controller verifies the signatures on the attribute identifiers of the sampled data packets. In the event of an abnormal data packet failing verification, the controller promptly updates the flow rules based on the attribute identifiers of the abnormal data packets, ensuring the security of the data flow forwarding paths. Through communication with the KGC, the controller can track and confirm the identity of the packet initiator, effectively tracing the source of abnormal packets in the network.

Attribute identification structure

The packet header defines the attribute identification field, which is added between the Ethernet header and the IP header in the traditional packet. The attribute identification structure is shown in Fig. 4. The attribute identification field comprises four parts: Next_Type, Att_Features, Att_Signature, and Att_Tree. AISCF can realize secure and fine-grained control and forwarding of dataflow based on attribute identification.

Each part of the attribute identification field is discussed here:

Next_Type (16 bits): It acts as a logical connection between multiple headers. After parsing the attribute identification field, the switch determines the header field that needs to be parsed next through Next_ Type to realize the orderly parsing of various headers.

Att_Features (64 bits): Used to represent the set of packet attribute features. The attribute class features, such as user, device, and service categories, are used to replace deterministic features to describe the dataflow. And Att_Features is generated by calculating the hash function of attribute characteristics. AISCF implements fine-grained control and forwarding of dataflow according to Att_Features.

Att_Signature (256 bits): It is the packet attribute signature field. By using the attribute signature scheme, the Att_Features section and the IP_Payload section of the packet is signed and stored in Att_Signature. AISCF verifies the security of the data packages according to Att_Signature.

Att_Tree (128 bits): It stores the attribute signature policy in a tree structure. Att_Tree contains attribute features and the logical relationship between attribute features. Only the attribute set that conforms to the signature policy can sign the packet. Att_Tree is also used as an input parameter in the packet attribute signature verification phase.

Attribute based signature scheme

ABS scheme poses problems such as high time consumption and linear correlation between signature verification time and the number of attributes (Su et al., 2020). Packets experience large transmission delays when using ABS verification. To address these problems, AISCF extends and employs the ABS scheme proposed by Tang, Ling & Shan (2022) in the packet forwarding process through SDN. The scheme incurs low time overhead in the signature verification process and is independent of the number of attributes, enabling lightweight and fine-grained secure forwarding verification of data packets. Figure 5 shows the implementation process of the attribute signature scheme in AISCF.

AISCF adopts the concept of attribute tree proposed by Bethencourt, Sahai & Waters (2007) and uses the tree structure to restrict the access policy of the signer’s attribute features. The signer qualifies to sign only when they match the access structure of the attribute policy tree. Threshold and attribute nodes compose the nodes in the attribute policy tree. Each attribute node corresponds to an attribute of the signer, whereas the threshold node represents the structure of n inputs corresponding to one output. For example, $\left(m,n\right)$ means that effective output is possible only when at least m inputs out of a total of n inputs satisfy the conditions. In particular, when m =n, $\left(m,n\right)$ represents the “and” relationship; when m =1, $\left(m,n\right)$ represents the “or” relationship.

Figure 6 illustrates an example of the attribute policy tree structure. As shown in the figure, the signer with administrator characteristics or the authority to use the authentication host conforms to the signature rules of the attribute policy tree. If the signer has the attribute features of user and Service C, they can effectively sign. However, if the signer has the attribute features of user and Service D, they cannot execute the signature because it does not conform to the access structure of the attribute policy tree.

Figure 6 illustrates an example of an IoT access control structure based on an attribute policy tree. In this structure, users with administrative privileges can access the IoT. Regular users can send data to the IoT via authenticated devices, with service types A, B, or C. If a user does not have administrative status, uses a non-authenticated IoT device, or sends other types of services, they will not be able to access the IoT due to non-compliance with the attribute policy tree structure. This structure provides secure and controlled access to the IoT system.

To clearly describe the attribute signature scheme, the following definitions are given.

Definition 1. Define the basic parameters in the ABS scheme. p and N are two large prime numbers, E is defined as an elliptic curve over a finite field F_p,G ₁ and G₂are N-th order additive cyclic groups on the elliptic curve, G_T is an N-th order multiplicative cyclic group, and P ₁ and P ₂ are, respectively the generators of G ₁ and G₂.[x]P_i is defined as x times of generator P_i, where $x\in Z_N^{\ast }.\phi$ is defined as a mapping of G₂ → G₁ such that $\phi \left(P_2\right)=P_1$. H ₁ and H₂are hash functions, and hid is the identification used for generating the key for the user. e is defined as a bilinear mapping of G₁ × G₂ → G_T and must meet the following conditions:

1. Bilinearity: $e\left(\left[a\right]P_1,\left[b\right]P_2\right)=e\left(\left[b\right]P_1,\left[a\right]P_2\right)=e{\left(P_1,P_2\right)}^{ab}$, where $a,b\in Z_N^{\ast }$.

2. Non-degeneracy: $e\left(P_1,P_2\right)\ne 1$, where 1 is an identity element of G_T.

3. Computability: For P₁ ∈ G₁, P₂ ∈ G₂, the value of $e\left(P_1,P_2\right)$ can be solved within polynomial time.

Definition 2. ID represents the identity information of the signer, and Att_ID represents the attribute set of the signer.

Definition 3. Υ represents the access control policy based on attributes, and T represents the attribute policy tree generated based on Υ.

Definition 4. PP represents the parameters disclosed in the attribute signature process, $\left(\mathrm{msk},\mathrm{mpk}\right)$ represents the master key pair of the system, in which msk and mpk represent the master public key and the master private key of the system respectively.

Definition 5. m represents the signed message, and the hash function H is defined. In AISCF, m is the hash value generated by the Att_Features field in the attribute identification and the data package payload, $m=\mathrm{H}\left(\mathrm{Att}\text{\_}\text{Features}∥\mathrm{IP}\text{\_}\text{Payload}\right)$.

Definition 6. sk represents the private key used for signature, and sign represents the attribute signature.

Definition 7. The Lagrangian coefficient is defined as ${\Delta }_i\left(x\right)={\prod }_{i\in S,j\ne i}\frac{x-x_j}{x_i-x_j}$, where $i\in Z_N^{\ast },S\in Z_N^{\ast }$. For the t − 1-th order polynomial p(⋅), any value can be calculated through t given points (x_i, y_i = p(x_i)), that is, $p\left(x\right)={\sum }_{i=1}^{t}p\left(i\right){\Delta }_i\left(x\right)\mathrm{mod}N$.

The proposed ABS scheme is discussed in terms of five aspects: system initialization, key generation, signature, signature verification, and tracing.

System initialization $\left(1^l\right)\to \left(\mathrm{PP},\mathrm{mpk},\mathrm{msk}\right)$: The KGC generates the system master private key msk according to the security parameter l, and calculates the system master public key mpk = [msk]P₂. KGC saves msk and makes mpk public. $g=e\left(P_1,\mathrm{mpk}\right)$, KGC obtains the public parameters $\mathrm{PP}=\left(N,P_1,P_2,e,\phi ,G_1,G_2,G_T,hid,g,H_1,H_2\right)$ according to the basic parameters in Definition 1.

Key generation $\left(\mathrm{msk},{\rm Y},At{t}_{\mathrm{ID}}\right)\to \left(\mathrm{sk}\right)$: The user provides the KGC with attribute policy Υ and user attribute feature set Att_ID. The KGC then generates the user private key according to the following steps:

1. It is determined whether the attribute set provided by the user meets the access control policy. ${\rm Y}\left(At{t}_{\mathrm{ID}}\right)=1$indicates that the user meets the access control policy, and perform step (2); otherwise, $\perp$ is returned, and the user cannot obtain the key.

2. A random number t is selected. Let $h_{ID}=H_1\left(\mathrm{ID}\parallel hid,N\right).\mathrm{s}{\mathrm{k}}^{\prime }=\left[\frac{\mathrm{msk}}{h_{\mathrm{ID}}+\mathrm{msk}}\right]P_1$ and ${\mathrm{sk}}_2=\left[\frac{h_{\mathrm{ID}}+\mathrm{msk}}{t}\right]P_2$ are calculated.

3. The attribute policy tree T is constructed from Υ, and the k_x − 1-th order polynomial p_x(⋅) for each node x in T is generated using the top-down method, where k_x is the threshold of the node. The constant term of the root node is defined as t, that is, p_xr(0) = t. For a non-leaf node $x^{\prime },p_{x^{\prime }}\left(0\right)=p_{par\left(x^{\prime }\right)}\left(ind\left(x^{\prime }\right)\right)$, where ind(x) and par(x) represent the numbers of node x and its parent node, respectively. For a leaf node x″, the attribute key ${\mathrm{sk}}_1=\left\{{\mathrm{sk}}_{1,\mathrm{i}}=p_{x^{″}}\left(0\right)\cdot \mathrm{s}{\mathrm{k}}^{\prime }\right\}$, i = att(x″) is calculated; att(x) represents the number of node x.

4. The KGC saves (ID, sk₂) and returns $\mathrm{sk}=\left({\mathrm{sk}}_1:\left\{{\mathrm{sk}}_{1,\mathrm{i}}\right\},{\mathrm{sk}}_2\right)$ to the user.

Signature $\left(m,\mathrm{sk},{\rm Y}\right)\to \left(\text{sign}\right)$: The user signs message m by using sk, selects a random number r, and calculates w = g^r, h = H₂(m||w, N), k = sk₂, l = (r − h)modN, and s_i = [l]sk_1,i, obtaining the signature as sign = (h, s_i, k). In AISCF, sign is stored in Att_Signature in the attribute identification.

Signature verification $\left(m,\text{sign},\mathrm{T}\right)\to \left(1/\perp \right)$: The controller in AISCF will verifie the Att_Signature field in the attribute identification of packets. The signature verification process is as follows:

1. The Lagrangian interpolation formula is used to calculate s_xr of the root node from bottom to top, that is, [l]p_xr(0)⋅sk′. When k_par(x) = 1 for node x, s_par(x) = s_x; otherwise s_par(x) = ∑_xi∈bro(x)s_xiΔ_xi(x)modN. Finally, $s_{x_r}=\left[\frac{l\cdot t\cdot \mathrm{msk}}{\mathrm{msk}+h_{ID}}\right]p_1$ is obtained. The parameter x is omitted and let $s_r=s_{x_r}=\left[\frac{l\cdot t\cdot \mathrm{msk}}{\mathrm{msk}+h_{ID}}\right]p_1$.

2. $w^{\prime }=e\left(s_r,k\right)\cdot g^h$ and $h^{\prime }=H_2\left(m\left|\right|w^{\prime },N\right)$ are calculated. If h′ = hthe signature verification is successful and 1 is returned. Otherwise, the signature verification fails and $\perp$ is returned. Because w = g^r, the condition for the success of signature verification is w′ = g^r. The correctness of the signature verification process can be determined using Eq. (1):

Tracing $\left(\text{sign}\right)\to \left(\mathrm{ID}\right)$: It is known that k = sk₂ in sign(h, s_i, k) and the KGC saves (ID, sk₂) when distributing the key to the user, then the KGC can trace the signer ID by checking the table of sk₂.

Implementation of AISCF

This section introduces the implementation of AISCF by explaining the workflows of both the switch and the controller.

Switch workflow

P4 programmable switch can add, read and delete headers in data packets. In addition to Ethernet header, IP header and other traditional packet headers, AISCF defines two header types in P4 switches in the network, namely InPort_Header and AttributeID_Header. The format of the header is shown in Table 2. The unit of the header field length in the table is bit.

Table 2:

Headers defined by AISCF in P4.

Structure of headers in P4 Switch

$\begin{array}{c}\text{header}\text{InPort}\text{\_}\text{Header}\left\{\right.\hfill \\ \text{fields}\left\{\right.\hfill \\ \text{Next}\text{\_}\text{Type}:16;\hfill \\ \mathrm{In}\text{\_}\text{Port}:2;\hfill \\ \left.\right\}\hfill \\ \left.\right\}\hfill \\ \text{header}\text{AttributeID}\text{\_}\text{Header}\left\{\right.\hfill \\ \text{fields}\left\{\right.\hfill \\ \text{Next}\text{\_}\text{Type}:16;\hfill \\ \mathrm{Att}\text{\_}\text{Features}:64;\hfill \\ \mathrm{Att}\text{\_}\text{Signature}:256;\hfill \\ \mathrm{Att}\text{\_}\text{Tree}:128;\hfill \\ \left.\right\}\hfill \\ \left.\right\}\hfill \end{array}$

DOI: 10.7717/peerjcs.1747/table-2

InPort_Header is used to identify the source of data packets. When In_Port=01 in InPort_Header, it indicates that the data packet is from the IoT device; when In_Port=00, it indicates that the data packet is from the switch. AttributeID_Header represents the attribute identification header defined in the ‘Attribute identification structure’ section. The switch controls and forwards the data packets according to the content of AttributeID_Header.

The P4 switch will mark the header type for different types of headers. The Next_Type field in the header records the next header type that needs to be parsed. The P4 switch implements the orderly analysis of multiple headers according to Next_Type. The default IP header and Ethernet header type numbers in P4 switch are 0x0800 and 0x1212, and the InPort_Header and AttributeID_Header type numbers are 0x2828 and 0x1818 defined in AISCF. The source host adds the AttributeID_Header, while the ingress switch adds the InPort_Header. The logical position of InPort_Header is in front of the Ethernet header, Next_Type =0x1212 in InPort_Header. AttributeID_Header is in front of the IP header, and Next_Type =0x0800 in AttributeID_Header.

The switch works by executing a “match–action” process on the packet, based on the flow table information it stores and receives from the controller. The switch matches the information parsed from the packet header with the corresponding flow table entry, and then executes the corresponding action on the packet. AISCF architecture establishes port distinguishing table, header validation table, matching forwarding table and sampling table in P4 switch, and carries out multilevel flow table matching process based on attribute identification for data packets. Figure 7 illustrates the multilevel flow matching process.

As can be seen from Figure, the switch first performs the “match–action” process based on the port matching table for the received packets and executes the corresponding actions for the various input port types. When the input port is an access port, the switch performs the “match–action” process of the identification table for the packets. Next, according to the content of the matching forwarding table, the packet is controlled and forwarded based on attribute identification, and the next hop address of the packet is set. Before the packet flows out of the switch, it is determined whether the exit port of the packet is an access port. If so, the contents of the sampling table are executed. The flow tables shown in Fig. 7 are discussed as follows:

Port matching table: Perform the corresponding action on the packet by matching the switch port type. AISCF divides switch ports into access ports and routing ports based on connection types. The access port indicates that the port is connected to the IoT device, and the routing port indicates that the port is connected to the switch. The port matching table is divided into inbound and outbound port matching tables. In the inbound port matching table, the matching item is In_Port in InPort_Header, when In_Port=01, submit the data packet to the identification table for processing, and when In_Port=00, the switch submits the data packet to the basic forwarding table for processing. In the outbound port matching table, the matching item is standard_metadata.egress_spec, when standard_metadata.egress_spec =01, submit the data packet to the sampling table for processing, and when standard_metadata.egress_spec =00, perform the forwarding action on the packet.

Identification table: Perform the corresponding action on the packet by matching the Next_Type field in the Ethernet_Header. P4 switch extracts the header information from the data packet. When Next_Type =0x0800, it indicates that Ethernet_Header is adjacent to IP_Header, the data packet does not contain attribute identification, and the switch discards the data packet; When Next_Type =0x1818, it indicates that the data contains attribute identification, and the data packet is sent to the matching forwarding table for subsequent processing.

Matching forwarding table: The forwarding policy is formulated based on Att_Features in attribute identification to realize fine-grained packet control and forwarding. The matching and forwarding table matches Att_Features precisely with the type of exact. When Att_Features matches successfully, the switch assigns the parameter standard_metadata.egress_spec based on the matching and forwarding table, where standard_metadata.egress_spec represents the outbound port value of the packet, and forwards the packet, that is, forwards the packet according to the requirements of the matching and forwarding table. When the matching fails, the switch drops the data package and upload the package to the controller through packet-in.

Sampling table: AISCF defines the packet sampling parameter pkt_sample_val in the P4 switch, and the sampling table takes pkt_sample_val as the matching item to sample the packet. When pkt_sample_val =1, the switch executes action clone_ingress_pkt_to_egress on the data packet and sends the mirror of the data packet to the controller; When pkt_sample_val =0, the switch does not process the data packet.

The switch in AISCF processes the data packets according to the Multilevel flow table matching process shown in Fig. 7. Algorithm 1 shows the control and forwarding process of the switch for data packets.

Algorithm 1. Control and forwarding process of the switch for packets

$\begin{array}{c}\text{Input}:\text{packet}A,\text{sampling}\text{factor}\theta \hfill \\ \text{Output}:\text{action}\text{executed}\mathrm{on}A\hfill \\ 1.\text{Function}\text{Control}\mathrm{and}\text{forwarding}\mathrm{of}\text{packets}\mathrm{in}\text{switches}:\hfill \\ 2.\mathrm{If}A\mathrm{has}\mathrm{no}\text{InPort}\text{\_}\text{Header}:\hfill \\ 3.\mathrm{add}\text{\_}\text{header}\left(A,\text{InPort}\text{\_}\text{Header},\mathrm{In}\text{\_}\text{Port}=1\right)\hfill \\ 4.in\text{\_}port=A.\text{InPort}\text{\_}\text{Header}.\mathrm{In}\text{\_}\text{Port}\hfill \\ 5.\mathrm{If}in\text{\_}port=1:\hfill \\ 6.next\text{\_}type=A.\text{InPort}\text{\_}\text{Header}.\text{Next}\text{\_}\text{Type}\hfill \\ 7.\mathrm{If}\text{match}\left(next\text{\_}type,\text{Identification}\text{\_}\text{table}\right)=\text{NULL}:\hfill \\ 8.\text{drop}\left(A\right)\hfill \\ 9.A.\text{InPort}\text{\_}\text{Header}.\mathrm{In}\text{\_}\text{Port}=0\hfill \\ 10.att\text{\_}features=A.\text{AttributeID}\text{\_}\text{Header}.\mathrm{Att}\text{\_}\text{Features}\hfill \\ 11.\mathrm{If}\text{match}\left(att\text{\_}features,\text{Matching}\text{\_}\text{forward}\text{\_}\text{table}\right):\hfill \\ 12.\text{action}\left(att\text{\_}features,\text{Matching}\text{\_}\text{forward}\text{\_}\text{table}\right)\hfill \\ 13.\mathrm{If}\text{standard}\text{\_}\text{metadata}.\text{egress}\text{\_}\text{spec}\mathrm{is}\text{Access}\text{port}:\hfill \\ 14.sample\text{\_}val=\text{modify}\text{\_}\text{field}\text{\_}\mathrm{rng}\text{\_}\text{uniform}\left(0,1+\theta \right)\hfill \\ 15.\mathrm{If}\theta <sample\text{\_}val<\theta +1:\hfill \\ 16.\mathrm{pkt}\text{\_}\text{smaple}\text{\_}\mathrm{val}=1\hfill \\ 17.\text{Else}:\hfill \\ 18.\mathrm{pkt}\text{\_}\text{smaple}\text{\_}\mathrm{val}=0\hfill \\ 19.\mathrm{If}\text{match}\left(\mathrm{pkt}\text{\_}\text{smaple}\text{\_}\mathrm{val},\text{Sampling}\text{\_}\text{table}\right):\hfill \\ 20.\text{action}\left(\mathrm{pkt}\text{\_}\text{smaple}\text{\_}\mathrm{val},\text{Sampling}\text{\_}\text{table}\right)\hfill \\ 21.\text{delete}\text{\_}\text{header}\left(A,\text{InPort}\text{\_}\text{Header},\text{AttributeID}\text{\_}\text{Header}\right)\hfill \\ 22.\text{Else}:\hfill \\ 23.\text{drop}\left(A\right)\hfill \\ 24.\mathrm{END}\text{Function}\hfill \end{array}$

In the Algorithm 1 , θ represents the sampling factor, add_header() and delete_header() are defined as functions to add and delete headers to packets, match(table, matching field) and action(table, matching field) represent the matching result and execution action between matching field in packets and the corresponding flow table table respectively, and drop() represents that the switch discards packets.

For data packets entering SDN, the incoming switch adds InPort_Header() to them and performs matching and action execution based on identification table. The switch then sets In_Port in InPort_Header to 0 to inform downstream switches that the routing port sends the data packet (lines 2-9 of Algorithm 1 ).Then the switch performs the matching and action execution on the packet based on the matching forwarding table. When the switch is an egress switch, the egress switch selects the data packet according to the probability of 1:θ + 1 through the random function modify_field_rng_uniform() in P4 system, and stores the sampling result in pkt_smaple_val (lines 13-18 of Algorithm 1 ), then performs matching and action execution on the data packet based on the sampling table. Finally, the egress switch deletes InPort_Header and AttributeID_Header from the packet before forwarding it.

Security proof

The security of the cryptographic algorithm is based on difficult mathematical problems. The security of AISCF is based on the complexity assumption of q-SDH (q-Strong Diffie-Hellman Problem) (Boneh & Boyen, 2004), For a given q +2 tuple $\left(P_1,P_2,\left[a\right]P_2,\left[a^2\right]P_2,\dots ,\left[a^q\right]P_2\right)$ that is known, it is difficult to solve $\left(x,\left[\frac{a}{a+x}\right]P_1\right)$where $a,x\in Z_N^{\ast },P_1\in G_1,P_2\in G_2$. Next, we will prove the unforgeability of attribute signature scheme in AISCF.

We use the method of disproof to demonstrate that if attacker can forge the attribute signature in AISCF with a non negligible advantage ɛ, then challenger can be constructed to solve q-SDH with a non negligible advantage. Build a q-SDH instance, $\left(P_1,P_2,\left[a\right]P_2,\left[a^2\right]P_2,\dots ,\left[a^q\right]P_2\right)$, in which a =msk, for challenger based on the attribute signature scheme in Section 4.3. Define a binary group L₂, and the format of each element in L₂ is (ID_i, β_i). Assume that the number of times attacker can obtain $H_1\left(\mathrm{ID}\parallel hid,N\right)$ by asking is t_h. When attacker asks once for the hash of ID_i, challenger randomly selects β_j from L₂ and returns it to attacker, ${\beta }_j\in Z_N^{\ast },j\in \left[1,t_h\right]$. Challenger randomly selects β_i by q − 1 times, i ∈ [1, q − 1], and put the ID_i corresponding to β_i into L₂. Challenger generates polynomial $f\left(a\right)={\prod }_{i=1}^{q-1}\left(a+{\beta }_i\right)={\sum }_{i=0}^{q-1}{c}_i{a}^i$, where $c_0,c_1,\dots ,c_{q-1}\in Z_N^{\ast }$. Let $P_2^{\prime }=\left[f\left(r\right)\right]P_2,P_1^{\prime }=\phi \left(P_2^{\prime }\right),P_1^{\prime }$ and $P_2^{\prime }$ are respectively the generators of G₁andG₂, $\mathrm{mpk}=\left[a\right]P_2^{\prime }={\sum }_{i=0}^{q-1}{c}_i{a}^i$, and make mpk public. The public parameters of challenger, $\mathrm{PP}=\left(N,P_1^{\prime },P_2^{\prime },e,\phi ,G_1,G_2,hid,g,H_1,H_2\right)$.

Key inquiry process. Define a triplet group L₃ of challenger, and the format of each element in L₃ is (ID_i, skⁱ′, skⁱ). Assume that attacker can ask skⁱ, the key of ID_i, by q times, where ID_i meets ${\rm Y}\left(At{t}_{{\mathrm{ID}}_i}\right)=1$. If ID_i is not in L₂, the query fails. If ID_i is in L₂, challenger constructs a polynomial $f_i\left(a\right)=\frac{f\left(a\right)}{a+{\beta }_i}={\sum }_{i=0}^{q-2}{d}_i{a}^i$, where $d_0,d_1,\dots ,d_{q-2}\in Z_N^{\ast }.{{\mathrm{sk}}^i}^{\prime }$can be obtained by Eq. (2): (2)${\displaystyle \begin{array}{c}{{\mathrm{sk}}^i}^{\prime }=\left[\frac{\mathrm{msk}}{h_{{\mathrm{ID}}_i}+\mathrm{msk}}\right]P_1^{\prime }=\left[\frac{a\cdot f\left(a\right)}{h_{{\mathrm{ID}}_i}+\mathrm{msk}}\right]P_1\hfill \\ =\left[a\cdot f_i\left(a\right)\right]P_1\hfill \\ =\left[a\cdot \sum _{i=0}^{q-2}{d}_i{a}^i\right]P_1\hfill \\ =\sum _{i=0}^{q-2}\left[d_i{a}^{i+1}\right]P_1\hfill \\ =\sum _{i=0}^{q-2}{d}_i\phi \left(\left[a^{i+1}\right]P_2\right)\hfill \end{array}}$

For leaf node x″ in the attribute policy tree, j = att(x″), then get ${\mathrm{sk}}_1^i={\mathrm{sk}}_{1,j}^i=p_j\left(0\right)\cdot {{\mathrm{sk}}^i}^{\prime }$, ${\mathrm{sk}}_2^i={\left[t\cdot {\left(\left[{\beta }_i\right]P_2^{\prime }+\mathrm{mpk}\right)}^{-1}\right]}^{-1}$. Challenger returns ${\mathrm{sk}}^i=\left({\mathrm{sk}}_1^i:\left\{{\mathrm{sk}}_{1,j}^i\right\},{\mathrm{sk}}_2^i\right)$ which is the key of ID_ito attacker, and saves $\left({\mathrm{ID}}_i,{{\mathrm{sk}}^i}^{\prime },{\mathrm{sk}}^i\right)$ in L₃.

Signature inquiry process. Assume that attacker can ask for signature by t_s times, and attacker provide (ID_i, m_i) at each inquiry. If ID_i is not in L₃, challenger returns randomly generated skⁱ to attacker. If ID_i is in L₃, challenger returns sign = (h, s_j, k) , the signature generated by skⁱ for m_i, to attacker.

Challenge process. Challenger executes signature verification algorithm on $\left({\mathrm{m}}^{\ast },{\mathrm{ID}}^{\ast },{\text{sign}}^{\ast }=\left(h^{\ast },s_j^{\ast },k^{\ast }\right),\mathrm{T}\right)$ input by attacker. If ID_i is not in L₂ and L₃, the challenge fails. Otherwise, we can get ${{\mathrm{sk}}^{\ast }}^{\prime }=\left[\frac{a}{h_{{\mathrm{ID}}^{\ast }}+a}\right]P_1^{\prime }=\left[\frac{a\cdot f\left(a\right)}{h_{{\mathrm{ID}}^{\ast }}+\mathrm{a}}\right]P_1$, and because $a\cdot f\left(a\right)={\sum }_{i=0}^{q-1}{c}_i{a}^{i+1}$, through the transformation by long division, we can get a⋅f(a) = γ(a)(a + h_ID^∗) + γ₋₁, where $\gamma \left(a\right)={\sum }_{i=0}^{q-2}{\gamma }^i\cdot a^{i+1}$, ${\gamma }_{-1}\in Z_N^{\ast }$. Then Eq. (3) can be obtained: (3)${\displaystyle \begin{array}{c}\left[\frac{1}{h_{{\mathrm{ID}}^{\ast }}+a}\right]P_1=\frac{1}{{\gamma }_{-1}}\left({{\mathrm{sk}}^{\ast }}^{\prime }-\gamma \left(a\right)P_1\right)\hfill \\ =\frac{1}{{\gamma }_{-1}}\left({{\mathrm{sk}}^{\ast }}^{\prime }-\sum _{i=0}^{q-2}\left[{\gamma }^i\cdot a^{i+1}\right]P_1\right)\hfill \\ =\frac{1}{{\gamma }_{-1}}\left({{\mathrm{sk}}^{\ast }}^{\prime }-\sum _{i=0}^{q-2}{\gamma }^i\cdot \phi \left(a^{i+1}{P}_2\right)\right)\hfill \end{array}}$

Challenger can get h_ID^∗ By looking up L₂, and $\left(h_{{\mathrm{ID}}^{\ast }},\frac{1}{{\gamma }_{-1}}\left({{\mathrm{sk}}^{\ast }}^{\prime }-{\sum }_{i=0}^{q-2}{\gamma }^i\cdot \phi \left(a^{i+1}{P}_2\right)\right)\right)$ can be used as the solution of challenger to q-SDH.

To sum up, the condition for challenger to challenge successfully is that the three processes of key inquiry, signature inquiry and challenge need to be successful, the probability of success of the three processes are ${\left(\frac{q-2}{t_h}\right)}^{q-2},{\left(\frac{t_s}{t_h}\right)}^{t_s}$ and $\frac{1}{t_h}$, and the probability of successful challenge is the product of the three. Then it is concluded that if attacker can forge the attribute signature in AISCF with a non negligible advantage ɛ, challenger can solve q-SDH with a non negligible advantage ${\varepsilon }^{\prime }=\frac{{\left(q-2\right)}^{q-2}\cdot t_s^{t_s}}{{\left(t_h\right)}^{t_s+q-1}}\cdot \varepsilon$. It proves that the attribute signature scheme in AISCF can not be forged, that is, AISCF has security.

Implemented functions

This section analyzes the safety functions of AISCF based on the safety problems described in ‘Attack Model’ section.

Defend against unauthorized access. AISCF only allows users that meet attribute access control policy Υ to access the network. Invalid users cannot obtain the key from KGC due to their inconsistent attributes, and thus cannot generate attribute identifications. AISCF requires only the ingress switch to check the data packets and discard those that do not contain attribute identifications, effectively preventing the data streams sent by illegal visitors. The security proof in the ‘Security proof’ section shows that the attribute identification cannot be forged. When the illegal visitor wants to forge the attribute identification, because the illegal visitor does not have the key required for signature, he can only randomly generate the 256bit signature field, and the probability of the generated signature passing the verification is (2²⁵⁶)⁻¹, which would cause great difficulties for illegal visitors. Therefore, we believe that illegal visitors without keys will not randomly generate attribute identifications.

Prevent matches forgery and tampering with packet content. The signature field in the attribute identification is the signature of the hash value of the matching item field and the load field of the packet. The signature ensures the integrity of the information. If someone forges the matching item or tampers with the content of the data package, it will damage the integrity of the information. As a result, it cannot pass the security verification process in the controller based on the attribute signature field.

Source authentication. AISCF ensures that packets are sent from trusted sources that conform to attribute access policies by adding attribute identifiers to packets. AISCF has anonymity for the data source, that is, the attribute identification of the data package only contains attribute characteristics, signatures generated based on attribute characteristics, and attribute policy trees. In order to prevent attackers from using the anonymity of attribute signatures to perform illegal operations, AISCF provides the traceability function of data sources, which can trace signer ID through k in signature sign = (h, s_i, k).

Fine-grained access control. AISCF implements fine-grained access control on data flow based on attribute characteristics. The fine-grained access control of AISCF on data flow is determined by the number of attribute characteristics in attribute identification and the structure of attribute policy tree in Att_Tree. Suppose there are Nt attributes of different categories, and n_t represents the number of attribute features in the t- th attribute, where t ∈ [1, Nt]. In theory, AISCF can implement up to ${\prod }_{t=0}^{Nt}{n}_t$ different access controls on data flows. AISCF can achieve access control of IoT fog architecture under various requirements by flexibly setting the access control structure through attribute policy trees. This effectively solves illegal access behavior caused by low access control granularity.

Fine-grained forwarding of data flows. AISCF uses Att_Features field in attribute identifier as a matching term for data stream forwarding, and SDN is used to achieve attribute based forwarding of the data stream, effectively improving the fine-grained control of data forwarding in the IoT fog architecture.

Scheme overhead

This section analyzes the overhead of AISCF from two aspects: header overhead and computational complexity.

Additional header overhead. AISCF realizes its function by adding AttributeID_Header header to the data packet. The length of AttributeID_Header added to the data packet at the source host is 464 bit (58B).

Computational complexity. exp is defined as the exponential operation on G_T; sca₁ and sca₂ are the scalar multiplication operations on G₁ and G₂, respectively; E represents a bilinear mapping operation; and |S_Υ| is the number of attribute features in attribute policy Υ. The time cost of the scheme in the key generation phase, signature phase, and signature verification phase is |S_Υ + 1|sca₁ + sca₂, |S_Υ|sca₁ + exp, and E + exp, respectively. The computational complexity of the tracing process is O(n), where n is the number of users stored in AISCF. AISCF exhibits a linear correlation between the time complexity and the number of attributes during key generation and signature. The key generation stage only needs to occur once for the same user, while the attribute signature stage takes place at the source device side, not affecting the forwarding delay of packets in the network.

Table 3 compares AISCF with related schemes in terms of extra header overhead and the verification overhead of data packets during the forwarding process. In the table, l denotes the number of switches in the forwarding path, and M denotes the computation process of a message authentication code. It can be seen from Table 3 that the extra header overhead and the verification overhead of data packets for SDNsec (Sasaki et al., 2016) grow linearly with l, which will incur large overhead when the forwarding path is long; P4Label (Zuo et al., 2020) introduces large extra header overhead and requires three pairing bilinear operations at the egress switch; Attribute-Guard’s (Zhu et al., 2020) verification overhead of data packets increases linearly with the number of attribute features, when the value of |S_Υ| is large, it will cause huge cost to the controller. Compared to related schemes, AISCF incurs less extra header overhead and has smaller and more stable time overhead for data packet verification.

Additionally, AISCF employs dynamic sampling to sample the data flow, which reduces the verification overhead incurred by sampling and verifying the data flow by dynamically changing the sampling factor. Next, we compare the verification overhead incurred by using dynamic sampling and using a fixed sampling factor. Assume that the data stream contains N packets, and the initial fixed sampling factor is θ₀. In dynamic sampling, when K consecutive packets are verified successfully, use f () to update the sampling factor, which is represented by θ_i. For ease of computation, let N have the value as shown in Eq. (4), which means that the sampling factor is changed n times in the dynamic sampling process of N packets. (4)${\displaystyle \mathrm{N}=\sum _{i=0}^{i=n-1}\mathrm{K}\left(1+{\theta }_i\right).}$

Using the number of packets that are sampled and verified from the data flow as a measure of the verification overhead, when a fixed θ₀ is used to sample and verify the data flow, the number of packets that are sampled and verified from the data stream is n₀ = N/(1 + θ₀); when dynamic sampling is used, the number of packets that are sampled and verified from the data stream is n₁ = nK, then the ratio of n₁ to n₀ can be calculated as shown in Eq. (5). (5)${\displaystyle \begin{array}{c}\hfill \frac{n_1}{n_0}=\frac{n\mathrm{K}\left(1+{\theta }_0\right)}{N}\hfill \\ \hfill =\frac{n\mathrm{K}\left(1+{\theta }_0\right)}{\sum _{i=0}^{i=n-1}\mathrm{K}\left(1+{\theta }_i\right)}\hfill \\ \hfill =\frac{n+n{\theta }_0}{n+\sum _{i=0}^{i=n-1}{\theta }_i}.\hfill \end{array}}$ Where θ_i = f(θ_i−1), and f () is a monotonic increasing function, so for any θ₀<θ_i, and it can be concluded that for the same data flow, the dynamic sampling method produces less verification overhead than the fixed sampling method.

Experimental environment

The AISCF architecture is implemented by employing P4 programmable software switches. These switches utilize the P4 language and generate a JSON format description file via the P4 compiler (P4c). Subsequently, this description file is imported into P4 behavioral-model version 2(BMv2) for execution. Additionally, we enhance security by incorporating an attribute signature verification function in Python within the controller. The controller communicates with the data plane through the P4 Runtime interface.

We conducted the experiment on an Intel i7–11370H 4.266-GHz host with 32-GB memory. We used mininet to simulate the IoT fog architecture environment, and Fig. 8 shows the network topology, including two hosts Host1 and Host2 (simulating IoT devices and IoT fog layer servers respectively), four P4 software switches Switch1 to Switch4, and one controller. We generated the data message required for the experiment using scapy and sent it from the host. We also captured and analyzed the operation flow information using Wireshark.

Validity analysis

Experiment 1: We conducted Experiment 1 to verify whether AISCF can realize access control, security verification, and fine-grained control forwarding of data flow, targeting the attack model summarized and objectives proposed in the ‘Problem description’ section. We constructed five types of dataflow, Flow A∼Flow E, at Host1 in the network topology shown in Fig. 8. Flow A represents the data flow sent by the user whose attribute feature set is R, Flow B represents the data flow sent by the user whose attribute feature set is P, Flow C represents the data flow sent by the user whose attribute feature set is Q, Flow D represents the data flow obtained after tampering with the data content of Flow B, Flow E represents the data flow obtained by forging the matches of Flow C, assume that Flow E replaces Att_Features of Flow C with Att_Features of Flow B. AISCF establishes access control over data flows flowing into the network, and stipulates that the data flow whose attribute feature set is P and Q can be transmitted in the network. And packets with attribute characteristics P and Q are specified to be transmitted in different paths, assume that when packets are sent from Host1 to Host2, the forwarding path with attribute P and Q are Host1 → Switch1 → Switch2 → Switch4 → Host2 and Host1 → Switch1 → Switch3 → Switch4 → Host2 respectively. To verify the results, the sampling parameter was set as θ = 0 in the effectiveness verification stage; that is, all the packets were sampled, and signature verification based on attribute identification was performed for all of them. Host1 successively sent the five types of packets to Host2 at the rate of 50 packets per second; this step was repeated 10 times. The average was obtained, and the data traffic was measured at the switch port. Figs. 9 and 10 show the traffic at each port of Switch1 and Switch4, respectively, during the experiment.

Figures 9 and 10 show the results for every 10s, representing the forwarding of one type of dataflow on Switch1 and Switch4. The x-axis and y-axis represent the time and number of packets, respectively. The positive and negative directions of the y-axis respectively represent the number of packets received and sent by the port. Flow A received from port eth0 of Switch1 but did not send from any port of Switch1, because Flow A does not meet the access control specified by AISCF and cannot generate attribute identification, the ingress switch in AISCF will discard Flow A, indicating that AISCF can achieve effective access control over data flows. Unlike Flow A, Switch4 sent Flow B and Flow C. This indicates that AISCF can implement fine-grained access control on Flows A to C according to access control rules. Port eth1 of Switch1 sent Flow B, and port eth0 of Switch4 received it. In contrast, port eth2 of Switch1 sent Flow C, and port eth1 of Switch4 received it. These actions comply with the forwarding rules that AISCF formulated for data flows, demonstrating that AISCF can control and forward data flows based on attribute identification. Switch4 received Flows D and E but did not forward them. This indicates that AISCF can detect and block abnormal packets with content tampering and matches forgery through signature verification based on attribute identification.

Experiment 2: In Experiment 2, to verify the impact of θ on AISCF packet verification, we set θ as 0, 1, 3, 4, 7, and 9. These values correspond to a sampling probability of 100%, 50%, 25%, 20%, 12.5%, and 10%, respectively. Test the performance of AISCF using different θ in detecting abnormal packets. It is considered as a successful detection when AISCF blocks the data flow which has the same Att_Features item as the abnormal packet’s within the specified time, and the false negative of detection is defined as the percentage of undetected times in the total detection times. Host1 continuously sends the security data flow Flow B in Experiment 1 to Host2, and mixes 10% abnormal data flows into Flow B. The abnormal data flows include Flow A, Flow D and Flow E, which correspond to three types of abnormal data flows: the illegally accessed data flow, the data flow with data tampering, and the data flow with forged matching items. The false negative is used as the evaluation parameter for AISCF detection performance to analyze the impact of θ on AISCF. The results are shown in Fig. 11.

Figure 11 compares the false negatives of abnormal dataflow detected by the AISCF architecture for different sampling factors θ. It can be seen from the figure that AISCF can achieve accurate detection of the illegally accessed data flow, and the false negative rate is 0% which does not change with θ. When θ was fixed, the false negatives of data tampering and matches forging cases were similar because both malicious flows would change the attribute signature of the packet and could not pass the signature verification based on attribute identification. When the sampling factor is 5, AISCF detects data tampering and matches forging anomalies with false negative rates of 6.5% and 6.6% respectively; when the sampling factor is 3, AISCF obtains false negative rates of 4.5 and 4% for data tampering and matches forging respectively; and when the sampling factor is 0, AISCF can get a detection false negative rate of 0%. It can be concluded that the false negative rate is proportional to the sampling factor, that is, the smaller the sampling factor, the lower the false negative rate of malicious flow detection. Depending on the current network conditions, it is possible to lower θ to enhance the detection effect of AISCF.

Based on the findings from Experiment 1 and Experiment 2, it is evident that AISCF is capable of effectively detecting malicious activities in the network, such as unauthorized access, data tampering, and spoofing of match items, which ensures the secure transmission of data from end-to-end within an IoT fog architecture. Furthermore, AISCF provides flexible and fine-grained control over data flow, significantly enhancing the efficiency of data management within the IoT.

Performance evaluation

This section evaluates the network performance of AISCF in terms of packet forwarding delay, network throughput and controller CPU usage.

Experiment 3: We conducted Experiment 3 to analyze the time consumption of the ABS scheme in AISCF. We established multiple attribute policy tree structures with the number of attribute features as 5, 10, 15, 20, 25, and 30. The AISCF’s time consumption of the signature phase and signature verification phase under various quantities of attribute features was calculated repeatedly for averaging. The results are shown in Fig. 12.

Figure 12 shows that the time consumed by the signature phase is proportional to the number of attributes in the attribute policy tree. The time consumption of the signature phase increases by an average of 0.5 ms for every five attribute features added. A normal local area network (LAN) requires a signature policy composed of 20–30 attribute features. Therefore, when creating packets based on attribute identification, the increase in the time consumption caused by the signature phase at the IoT device side can be controlled within 4 ms, which is an acceptable transmission delay in the AISCF architecture. The average time consumption of the signature verification process is 1.96 ms and is independent of the scale of the signature policy. Therefore, the AISCF architecture can ensure a low and stable time delay of dataflow in the transmission process.

Experiment 4: We conducted Experiment 4 to test the dataflow forwarding delay in the AISCF architecture. A total of 1,000 conventional packets and 1,000 packets containing legal attribute identification were created at Host1 and sent to Host2. The conventional packets were transmitted in the basic network without the AISCF architecture, whereas the packets containing attribute identification were transmitted in the network with the AISCF architecture. The sampling factor in the AISCF architecture was set as 7. We captured the packets at Switch1-eth0 and Switch1-eth2, respectively, and calculated the forwarding delay. The experimental results were used to generate the cumulative distribution function (CDF) curves, as shown in Figures 13∼15.

Figures 13 and 14 show the forwarding delays of 1,000 packets in the conventional network and AISCF, respectively. The average forwarding delay for 1,000 packets in the basic network was 2.56 ms, whereas the average forwarding delay in the AISCF architecture was 2.95 ms. Using AISCF architecture will increase the forwarding delay by 15.2% during packet forwarding compared to conventional network and the increased forwarding delay originated from two aspects. First, the packets transmitted in the AISCF architecture include an attribute identification field compared with the conventional packets. Second, the AISCF architecture samples the packets and copies the sampled packets to the controller for signature verification process.

Figure 15 plots the cumulative distribution function (CDF) curve of the experimental results, and from the figure we can see that, when packets were transmitted in the basic network, 96% of the packets could be forwarded within 3 ms. When we use the AISCF architecture, 87% of the packets can be forwarded within 3 ms, and 99% of the packets can be forwarded within 5.5 ms. AISCF causes a small increase in the forwarding latency of packets.

Table 4 compares the forwarding delay of data packets between AISCF and related schemes. LPV (Wang, Li & Zhang, 2019) has a low verification overhead, but it requires sampling at the first and last switches where the data flow enters and exits, resulting in an increase in forwarding delay. AISCF architecture only samples and verifies data packets at the egress switch, effectively reducing the burden on the controller and the forwarding delay of data packets. P4Label (Zuo et al., 2020) performs signature verification in P4 switching devices, thus generating a high verification overhead. AISCF only performs sampling at the switching devices, and delegates the signature verification process to the controller. Attribute-Guard (Zhu et al., 2020) has a large time overhead in the verification process, because it involves multiple bilinear pairings and polynomial calculations in the signature verification process, and the number of calculations is linearly related to the number of attributes, which increases the forwarding delay of data packets. Compared with Attribute-Guard, AISCF only performs one bilinear pairing and one exponentiation in the signature verification process, which significantly improves the signature verification overhead. Scheme (Xie et al., 2019) applies blockchain to 5G Vehicle Ad-hoc Network (5G-VANET) and verifies data through a consensus mechanism between multiple nodes. However, data transmission between two points requires confirmation from other nodes. Therefore, when the data volume is large, it can cause an increase in node burden and result in high forwarding latency. Compared to Scheme (Xie et al., 2019), AISCF’s forwarding latency is only related to the forwarding path and is not affected by other nodes in the network.

Experiment 5: The egress switch mirrors and transmits the sampled packets to the controller for signature verification, which affects the throughput of the network. To test the relationship between sampling factor θ and throughput in AISCF, Experiment 5 is constructed. In Experiment 5, θ was varied from 0, 1, 3, 4, 7, to 9, and the packets sent in the network were security packets with a load length of 1,000B. Test the throughput of AISCF for many times, take the average value and compare it with the network throughput without AISCF. The result is shown in Fig. 16.

In Fig. 16, the bars show the throughput of the network for different θ, and the line shows the ratio of the throughput of the network with AISCF architecture to the throughput of the basic network. With the decrease in θ, the throughput decreased, when θ was 0, the throughput was the lowest, which decreased by 42.5% compared with the throughput of the basic network, and when θ was greater than 7, the network throughput decreased by less than 10% compared with the basic network, which had little impact on the network performance. Combined with the results of Experiment 2, the sampling factor will affect the detection effect and system performance, such as the network throughput, of AISCF at the same time. AISCF can dynamically select θ to meet the requirements between the detection effect of abnormal data flow and the system performance.

Experiment 6: To evaluate the verification overhead of the dynamic sampling method in AISCF, Experiment 6 is conducted, where Host1 continuously sent secure data flows to Host2. We measured the CPU utilization of the controller in AISCF using both dynamic sampling and fixed sampling factor methods, and compared them with a conventional SDN network. The results are shown in Fig. 17. We defined the function f(θ) = 2θ to dynamically select the sampling factor, the maximum sampling number threshold K = 1000, and the fixed sampling factor θ₀ = 1.

Figure 17 shows the statistics of the controller’s CPU utilization at different time points during data flow transmission. The figure suggests that the average CPU utilization of the controller is 9.21% when the data flow is transmitted in the SDN network. When AISCF uses a fixed sampling rate, the CPU utilization of the controller is stable, with an average value of 18.24%, which is significantly higher than that of the SDN network. When AISCF uses a dynamic sampling rate, the CPU utilization of the controller exhibits a gradual decline, with average values of 16.7%, 14.1%, and 10.3% when the number of packets sent ranges from 2,000 to 5,000, 5,000 to 10,000, and 10,000 to 18,000, respectively. When the number of packets sent ranges from 10,000 to 18,000, AISCF using a dynamic sampling rate reduces the controller’s CPU utilization by 44.3% compared to using a fixed sampling rate, indicating that AISCF using a dynamic sampling rate can effectively reduce the verification overhead of the controller for packets by adjusting the sampling factor. AISCF using a dynamic sampling rate increases the controller’s CPU utilization by 11.35% compared to SDN network, and the additional CPU resources are used for verifying signatures of sampled packets, tracking malicious users, and other operations. The impact of AISCF on the controller’s performance is minimal.

The results of Experiment 3 to Experiment 6 demonstrate that AISCF achieves its security functions with low network performance overhead, which is a feasible and lightweight data flow forwarding verification scheme.