<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE article PUBLIC "-//NLM//DTD JATS (Z39.96) Journal Publishing DTD v1.1 20151215//EN" "http://jats.nlm.nih.gov/publishing/1.1/JATS-journalpublishing1.dtd">
<article xmlns:xlink="http://www.w3.org/1999/xlink" xmlns:mml="http://www.w3.org/1998/Math/MathML" xml:lang="en" article-type="research-article" dtd-version="1.1">
<front>
<journal-meta>
<journal-id journal-id-type="pmc">CSSE</journal-id>
<journal-id journal-id-type="nlm-ta">CSSE</journal-id>
<journal-id journal-id-type="publisher-id">CSSE</journal-id>
<journal-title-group>
<journal-title>Computer Systems Science &#x0026; Engineering</journal-title>
</journal-title-group>
<issn pub-type="ppub">0267-6192</issn>
<publisher>
<publisher-name>Tech Science Press</publisher-name>
<publisher-loc>USA</publisher-loc>
</publisher>
</journal-meta>
<article-meta>
<article-id pub-id-type="publisher-id">68151</article-id>
<article-id pub-id-type="doi">10.32604/csse.2025.068151</article-id>
<article-categories>
<subj-group subj-group-type="heading">
<subject>Article</subject>
</subj-group>
</article-categories>
<title-group>
<article-title>DPZTN: Data-Plane-Based Access Control Zero-Trust Network</article-title>
<alt-title alt-title-type="left-running-head">DPZTN: Data-Plane-Based Access Control Zero-Trust Network</alt-title>
<alt-title alt-title-type="right-running-head">DPZTN: Data-Plane-Based Access Control Zero-Trust Network</alt-title>
</title-group>
<contrib-group>
<contrib id="author-1" contrib-type="author">
<name name-style="western"><surname>Yan</surname><given-names>Jingfu</given-names></name></contrib>
<contrib id="author-2" contrib-type="author" corresp="yes">
<name name-style="western"><surname>Zhou</surname><given-names>Huachun</given-names></name><email>hchzhou@bjtu.edu.cn</email></contrib>
<contrib id="author-3" contrib-type="author">
<name name-style="western"><surname>Wang</surname><given-names>Weilin</given-names></name></contrib>
<aff id="aff-1">
<institution>The School of Electronic and Information Engineering, Beijing Jiaotong University</institution>, <addr-line>Beijing, 100044</addr-line>, <country>China</country></aff>
</contrib-group>
<author-notes>
<corresp id="cor1"><label>&#x002A;</label>Corresponding Author: Huachun Zhou. Email: <email>hchzhou@bjtu.edu.cn</email></corresp>
</author-notes>
<pub-date date-type="collection" publication-format="electronic">
<year>2025</year>
</pub-date>
<pub-date date-type="pub" publication-format="electronic">
<day>10</day><month>10</month><year>2025</year>
</pub-date>
<volume>49</volume>
<issue>1</issue>
<fpage>499</fpage>
<lpage>531</lpage>
<history>
<date date-type="received">
<day>22</day>
<month>5</month>
<year>2025</year>
</date>
<date date-type="accepted">
<day>03</day>
<month>9</month>
<year>2025</year>
</date>
</history>
<permissions>
<copyright-statement>&#x00A9; 2025 The Authors.</copyright-statement>
<copyright-year>2025</copyright-year>
<copyright-holder>Published by Tech Science Press.</copyright-holder>
<license xlink:href="https://creativecommons.org/licenses/by/4.0/">
<license-p>This work is licensed under a <ext-link ext-link-type="uri" xlink:type="simple" xlink:href="https://creativecommons.org/licenses/by/4.0/">Creative Commons Attribution 4.0 International License</ext-link>, which permits unrestricted use, distribution, and reproduction in any medium, provided the original work is properly cited.</license-p>
</license>
</permissions>
<self-uri content-type="pdf" xlink:href="TSP_CSSE_68151.pdf"></self-uri>
<abstract>
<p>The 6G network architecture introduces the paradigm of <italic>Trust &#x002B; Security</italic>, representing a shift in network protection strategies from external defense mechanisms to endogenous security enforcement. While ZTNs (zero-trust networks) have demonstrated significant advancements in constructing trust-centric frameworks, most existing ZTN implementations lack comprehensive integration of security deployment and traffic monitoring capabilities. Furthermore, current ZTN designs generally do not facilitate dynamic assessment of user reputation. To address these limitations, this study proposes a DPZTN (Data-plane-based Zero Trust Network). DPZTN framework extends traditional ZTN models by incorporating security mechanisms directly into the data plane. Additionally, blockchain infrastructure is used to enable decentralized identity authentication and distributed access control. A pivotal element within the proposed framework is ZTNE (Zero-Trust Network Element), which executes access control policies and performs real-time user traffic inspection. To enable dynamic and fine-grained evaluation of user trustworthiness, this study introduces BBEA (Bayesian-based Behavior Evaluation Algorithm). BBEA provides a framework for continuous user behavior analysis, supporting adaptive privilege management and behavior-informed access control. Experimental results demonstrate that ZTNE combined with BBEA, can effectively respond to both individual and mixed attack types by promptly adjusting user behavior scores and dynamically modifying access privileges based on initial privilege levels. Under conditions supporting up to 10,000 concurrent users, the control system maintains approximately 65% CPU usage and less than 60% memory usage, with average user authentication latency around 1 s and access control latency close to 1 s.</p>
</abstract>
<kwd-group kwd-group-type="author">
<kwd>Zero trust network</kwd>
<kwd>data plane</kwd>
<kwd>bayesian-based behavior evaluation</kwd>
<kwd>blockchain-based access control</kwd>
<kwd>security functions</kwd>
</kwd-group>
<funding-group>
<award-group id="awg1">
<funding-source>Basic Research Operating Expenses Postgraduate Innovation Programme</funding-source>
<award-id>W24YJS00010</award-id>
</award-group>
<award-group id="awg2">
<funding-source>National Key R&#x0026;D Program of China</funding-source>
<award-id>2018YFA0701604</award-id>
</award-group>
<award-group id="awg3">
<funding-source>National Natural Science Foundation of China</funding-source>
<award-id>62341102</award-id>
</award-group>
</funding-group>
</article-meta>
</front>
<body>
<sec id="s1">
<label>1</label>
<title>Introduction</title>
<p>The evolution of 6G networks brings urgent demands for the new generation of endogenous security architectures. This transformation reflects three fundamental shifts in network protection strategies: from external defense to internal security mechanisms, from passive response to proactive defense, and from static protection to adaptive security frameworks [<xref ref-type="bibr" rid="ref-1">1</xref>].</p>
<p>However, traditional authentication methods in centralized architectures are increasingly inadequate in large-scale and dynamic network environments [<xref ref-type="bibr" rid="ref-2">2</xref>]. Password-based authentication is vulnerable to brute-force and dictionary attacks. The certificate-based schemes are susceptible to compromise by malicious intermediaries. The use of unencrypted biometric identifiers such as fingerprints poses serious privacy risks. To address these limitations, blockchain technology has been progressively adopted in ZTN environments to support decentralized and tamper-resistant identity authentication [<xref ref-type="bibr" rid="ref-3">3</xref>].</p>
<p>Meanwhile, in highly dynamic and heterogeneous network scenarios, static access control methods can no longer meet the dual requirements of security and efficiency. Adaptive access strategies are urgently needed to reflect users&#x2019; real-time behavior changes and associated risk levels. Although traditional trust and reputation models provide a basis for access control, they often rely on static behavior profiles and lack adaptability to evolving threats. The integration of smart contracts within blockchain offers a promising alternative by enabling decentralized, automated reputation scoring, dynamic access policy updates, and global synchronization of behavior data.</p>
<p>Despite these advances, many existing ZTN frameworks remain incomplete. They do not integrate traffic monitoring with fine-grained security enforcement. This integration is collectively referred to as MaS (Monitoring and Security). As a result, PEPs (Policy Enforcement Points) are exposed to frequent and targeted attacks [<xref ref-type="bibr" rid="ref-4">4</xref>]. In this context, programmable switches have emerged as a viable solution, allowing direct in-network analysis of user behavior and traffic characteristics at the data plane [<xref ref-type="bibr" rid="ref-5">5</xref>]. In coordination with the control plane, programmable switches support dynamic adaptation of access control policies to meet the diverse security demands [<xref ref-type="bibr" rid="ref-6">6</xref>].</p>
<p>To address the above challenges, this paper proposes and implements ZTNE that embeds security functions directly within network infrastructure. As a core security component, ZTNE enhances trust enforcement by supporting in-network behavior analysis, making it capable of responding to challenges posed by user changes [<xref ref-type="bibr" rid="ref-7">7</xref>] and increasing traffic heterogeneity [<xref ref-type="bibr" rid="ref-8">8</xref>]. Building on ZTNE, a dynamic access control framework based on user behavior profiling is developed. This framework uses real-time monitoring, programmable data planes, and blockchain infrastructure to strengthen zero-trust enforcement in 6G networks. The contributions of this study are summarized as follows:
<list list-type="bullet">
<list-item>
<p><bold>A zero-trust network architecture</bold> is proposed that implements data-plane-based access control. DPZTN uses blockchain-based registration, authentication, and policy enforcement to support continuous monitoring and adaptive access management through ZTNE components.</p></list-item>
<list-item>
<p><bold>A dynamic behavior evaluation algorithm</bold>, BBEA, is introduced and implemented via smart contracts. It monitors user behaviors in real time and applies Bayesian inference to calculate reputation scores, considering both historical behavior and potential risks.</p></list-item>
<list-item>
<p><bold>A programmable-switch-based ZTNE</bold> is developed to monitor authenticated traffic flows. ZTNE detects malicious behaviors and supplies behavior-related data to support reputation evaluation and policy refinement.</p></list-item>
</list></p>
<p>The remainder of this paper is organized as follows: <xref ref-type="sec" rid="s2">Section 2</xref> reviews the DPZTN framework and related studies. <xref ref-type="sec" rid="s3">Section 3</xref> presents the system design and implementation details. <xref ref-type="sec" rid="s4">Section 4</xref> provides experimental results. <xref ref-type="sec" rid="s5">Section 5</xref> offers a security analysis. <xref ref-type="sec" rid="s6">Section 6</xref> concludes the paper and discusses directions for future research.</p>
</sec>
<sec id="s2">
<label>2</label>
<title>Related Work</title>
<p>This section reviews recent research advancements in ZTNs and summarizes related studies on the integration of security functions within programmable switches.</p>
<sec id="s2_1">
<label>2.1</label>
<title>ZTN Authentication and Access Control Methods</title>
<p>Most of the existing studies proposing ZTNs refer to the ZTN model proposed by NIST [<xref ref-type="bibr" rid="ref-9">9</xref>]. This section provides a comparative summary of authentication and access control used in representative ZTN implementations.</p>
<p>Bradatsch et al. proposed ZTSFC, a zero-trust architecture that integrates monitoring and security functions into the authentication decision-making process. This framework utilizes sensing components to collect contextual data and shares threat intelligence with the control plane through a dedicated database [<xref ref-type="bibr" rid="ref-7">7</xref>]. PEPs generate personalized PDP (Policy Decision Point) rules based on historical user behavior, enabling access to service functions aligned with individual policies.</p>
<p>Sengupta and Lakshminarayanan introduced DistriTrust, a distributed trust management mechanism employing threshold signature schemes across multiple PDPs [<xref ref-type="bibr" rid="ref-10">10</xref>]. This design enhances authentication robustness under adversarial conditions by preventing reliance on a single PDP, thereby mitigating centralization risks.</p>
<p>Federici et al. developed a two-step access control method to enforce zero-trust principles [<xref ref-type="bibr" rid="ref-11">11</xref>]. The framework supports fine-grained access policies through trusted automation, end-to-end policy enforcement, and protection of both network and edge domains.</p>
<p>Azad et al. designed a decentralized trust management system for social IoT environments [<xref ref-type="bibr" rid="ref-12">12</xref>]. The system uses homomorphic encryption to protect participant privacy and employs zero-knowledge proofs to ensure protocol compliance without relying on trusted intermediaries.</p>
<p>The DPZTN architecture proposed in this study utilizes blockchain technology to achieve decentralized access control and uses smart contracts to support dynamic policy adjustments. <xref ref-type="table" rid="table-1">Table 1</xref> presents a comparative analysis of representative ZTN frameworks, focusing on four key dimensions: distributed architecture, dynamic adaptability, support for SFs (Security Functions), and phase within the zero-trust process. The DPZTN model exhibits comprehensive capability across all evaluated aspects, highlighting its effectiveness as a fully integrated zero-trust solution.</p>
<table-wrap id="table-1">
<label>Table 1</label>
<caption>
<title>Comparison of zero trust network</title>
</caption>
<table>
<colgroup>
<col/>
<col/>
<col/>
<col/>
<col/>
</colgroup>
<thead>
<tr>
<th>No.</th>
<th>Distributed</th>
<th>Dynamic</th>
<th>SFs</th>
<th>Stage</th>
</tr>
</thead>
<tbody>
<tr>
<td>[<xref ref-type="bibr" rid="ref-7">7</xref>]</td>
<td>N</td>
<td>Y</td>
<td>Y</td>
<td>Auth&#x0026;Acc</td>
</tr>
<tr>
<td>[<xref ref-type="bibr" rid="ref-10">10</xref>]</td>
<td>N</td>
<td>N</td>
<td>N</td>
<td>Acc</td>
</tr>
<tr>
<td>[<xref ref-type="bibr" rid="ref-11">11</xref>]</td>
<td>N</td>
<td>Y</td>
<td>N</td>
<td>Auth&#x0026;Acc</td>
</tr>
<tr>
<td>[<xref ref-type="bibr" rid="ref-12">12</xref>]</td>
<td>Y</td>
<td>Y</td>
<td>N</td>
<td>Auth&#x0026;Acc</td>
</tr>
<tr>
<td>DPZTN</td>
<td>Y</td>
<td>Y</td>
<td>Y</td>
<td>Auth&#x0026;Acc</td>
</tr>
</tbody>
</table>
<table-wrap-foot>
<fn id="table-1fn1" fn-type="other">
<p>Note: N represents no, Y represents yes, Auth represents Authentication and Acc represents Access Control.</p>
</fn>
</table-wrap-foot>
</table-wrap>
</sec>
<sec id="s2_2">
<label>2.2</label>
<title>ZTN Reputation Assessment Methods</title>
<p>This section analyzes representative reputation assessment techniques used in zero-trust environments, with a focus on algorithmic models and their deployment environments.</p>
<p>Tu and Kaur proposed BTRM, a multi-dimensional trust model designed to reduce assessment frequency without compromising IoT security [<xref ref-type="bibr" rid="ref-13">13</xref>]. The model evaluates behavior dimensions and integrates dynamic methods to establish trust relationships with connected users.</p>
<p>Taneja and Kanu introduced HA2CTMF, a trust management framework that enhances trust in cloud environments [<xref ref-type="bibr" rid="ref-14">14</xref>]. The framework evaluates cloud service provider reputation and availability using deep learning models to mitigate the effects of malicious behaviors.</p>
<p>Tian et al. presented MSLShard, a blockchain-enabled access control method for IoT [<xref ref-type="bibr" rid="ref-15">15</xref>]. The system comprises a Trust Management Model and a Smart Contract-based Network Segmentation Scheme. The segmentation strategy improves scalability, while intra-slice trust evaluation enhances security.</p>
<p>Baracaldo and Joshi designed a role-based access control model that dynamically adjusts privileges based on behavior patterns [<xref ref-type="bibr" rid="ref-16">16</xref>]. The model uses Colored Petri Nets to calculate risk levels and enforces least-privilege policies.</p>
<p>Dia et al. proposed the AALMOND framework, which implements distributed, risk-aware access control via smart contracts [<xref ref-type="bibr" rid="ref-17">17</xref>]. Risk values are computed based on security parameters and operational environment. If the risk exceeds a defined threshold, requests are sandboxed to contain potential threats.</p>
<p>BBEA proposed in this paper integrates historical user behavior with predictive risk modeling to generate behavior scores that comprehensively reflect the credibility of user behaviors. <xref ref-type="table" rid="table-2">Table 2</xref> provides a comparative analysis of various trust and risk assessment methods, focusing on their treatment of reputation, risk factors, dynamic evaluation, and feedback mechanisms.</p>
<table-wrap id="table-2">
<label>Table 2</label>
<caption>
<title>Comparison of trust and risk assessment</title>
</caption>
<table>
<colgroup>
<col/>
<col/>
<col/>
<col/>
<col/>
</colgroup>
<thead>
<tr>
<th>No.</th>
<th>Reputation</th>
<th>Risk</th>
<th>Dynamic evaluation</th>
<th>Feedback</th>
</tr>
</thead>
<tbody>
<tr>
<td>[<xref ref-type="bibr" rid="ref-13">13</xref>]</td>
<td>Y</td>
<td>N</td>
<td>Y</td>
<td>N</td>
</tr>
<tr>
<td>[<xref ref-type="bibr" rid="ref-14">14</xref>]</td>
<td>Y</td>
<td>N</td>
<td>N</td>
<td>Y</td>
</tr>
<tr>
<td>[<xref ref-type="bibr" rid="ref-15">15</xref>]</td>
<td>Y</td>
<td>N</td>
<td>Y</td>
<td>Y</td>
</tr>
<tr>
<td>[<xref ref-type="bibr" rid="ref-16">16</xref>]</td>
<td>Y</td>
<td>N</td>
<td>Y</td>
<td>Y</td>
</tr>
<tr>
<td>[<xref ref-type="bibr" rid="ref-17">17</xref>]</td>
<td>N</td>
<td>Y</td>
<td>Y</td>
<td>N</td>
</tr>
<tr>
<td>DPZTN</td>
<td>Y</td>
<td>Y</td>
<td>Y</td>
<td>Y</td>
</tr>
</tbody>
</table>
<table-wrap-foot>
<fn id="table-2fn1" fn-type="other">
<p>Note: N represents no and Y represents yes.</p>
</fn>
</table-wrap-foot>
</table-wrap>
</sec>
<sec id="s2_3">
<label>2.3</label>
<title>Programmable Switch Based Threat Detection</title>
<p>Traditional security functions based on AI models rely on batch training and processing, making it difficult to achieve real-time detection mechanisms [<xref ref-type="bibr" rid="ref-18">18</xref>]. Thus, this section reviews the application of programmable switches in implementing in-network threat detection mechanisms, validating their role in enhancing ZTN security functions.</p>
<p>Alevizos et al. introduced NetBeacon, an intelligent data plane framework that supports on-switch traffic analysis using embedded machine learning models [<xref ref-type="bibr" rid="ref-19">19</xref>]. The framework incorporates a multi-phase modeling structure, compact model representation, and indexed state management to handle concurrent data streams.</p>
<p>Saquetti et al. developed a neural-distributed defense architecture by deploying ANN (Artificial Neural Network) components across multiple switches [<xref ref-type="bibr" rid="ref-20">20</xref>]. This distributed ANN architecture enhances resilience against DDoS (Denial of Service Attack).</p>
<p>Mai et al. proposed an intelligent control architecture that allows network devices to autonomously adapt to dynamic conditions using learning-driven policies [<xref ref-type="bibr" rid="ref-21">21</xref>]. The architecture integrates centralized training with distributed inference and supports hybrid control strategies.</p>
<p>DPZTN uses blockchain for decentralized access control and smart contracts for dynamic policy adjustments. <xref ref-type="table" rid="table-3">Table 3</xref> illustrates that DPZTN excels across four key dimensions: active defense, dynamic strategy, and trust. Unlike traditional methods, DPZTN ensures real-time monitoring and adaptive security enforcement, making it a more scalable solution for dynamic network environments.</p>
<table-wrap id="table-3">
<label>Table 3</label>
<caption>
<title>Comparison of programmable switches threat detection</title>
</caption>
<table>
<colgroup>
<col/>
<col/>
<col/>
<col/>
</colgroup>
<thead>
<tr>
<th>No.</th>
<th>Active defense</th>
<th>Dynamic strategy</th>
<th>Trust</th>
</tr>
</thead>
<tbody>
<tr>
<td>[<xref ref-type="bibr" rid="ref-19">19</xref>]</td>
<td>N</td>
<td>N</td>
<td>N</td>
</tr>
<tr>
<td>[<xref ref-type="bibr" rid="ref-20">20</xref>]</td>
<td>Y</td>
<td>N</td>
<td>N</td>
</tr>
<tr>
<td>[<xref ref-type="bibr" rid="ref-21">21</xref>]</td>
<td>Y</td>
<td>Y</td>
<td>N</td>
</tr>
<tr>
<td>DPZTN</td>
<td>Y</td>
<td>Y</td>
<td>Y</td>
</tr>
</tbody>
</table>
<table-wrap-foot>
<fn id="table-3fn1" fn-type="other">
<p>Note: N represents no and Y represents yes.</p>
</fn>
</table-wrap-foot>
</table-wrap>
</sec>
</sec>
<sec id="s3">
<label>3</label>
<title>Design and Implementation of DPZTN</title>
<p>This section presents an overview of DPZTN, outlining the threat model it is designed to address. It concludes with a description of DPZTN&#x2019;s overall workflow and a detailed implementation method for each functional component.</p>
<sec id="s3_1">
<label>3.1</label>
<title>Overview</title>
<p>As illustrated in <xref ref-type="fig" rid="fig-1">Fig. 1</xref>, the DPZTN architecture is divided into the data plane and the control plane. The programmable switch and its controller together form ZTNE. The data plane extracts essential packet features from user requests, performs real-time monitoring and traffic analysis for authorized users, and executes rules defined by the control plane. The control plane consists of the switch controller, blockchain, and the deployed smart contracts, which manage and issue access control policies while supporting data plane operations. The BBEA dynamically adjusts policies based on data plane feedback. The BBEA is implemented through a combination of several smart contracts. Additionally, a hybrid encryption algorithm ensures the integrity, authenticity, and confidentiality of communication. Blockchain technology stores user behavior records, providing the foundation for dynamic reputation evaluation. The logical components shown in <xref ref-type="fig" rid="fig-1">Fig. 1</xref> will be described in detail in <xref ref-type="sec" rid="s3_1_1">Section 3.1.1</xref>.</p>
<fig id="fig-1">
<label>Figure 1</label>
<caption>
<title>DPZTN architecture and workflows</title>
</caption>
<graphic mimetype="image" mime-subtype="tif" xlink:href="CSSE_68151-fig-1.tif"/>
</fig>
<sec id="s3_1_1">
<label>3.1.1</label>
<title>Logical Components of DPZTN</title>
<p>This section provides a detailed overview of the logical components involved in DPZTN, including their full names and specific functionalities.
<list list-type="bullet">
<list-item>
<p><bold>ZIRSC</bold> (ZTNE Identity Registration Smart Contract): Registers the identity information of gateways on the blockchain to ensure that each gateway is uniquely and reliably recognized by the access control system. Once registered, gateways can use their identity for subsequent authentication and access control requests.</p></list-item>
<list-item>
<p><bold>ZIASC</bold> (ZTNE Identity Authentication Smart Contract): Verifies the identity of gateways by matching authentication requests with registered identity data on the blockchain. Only successfully authenticated gateways are permitted to participate in data transmission and access control operations.</p></list-item>
<list-item>
<p><bold>UIRSC</bold> (User Identity Registration Smart Contract): Handles the registration of user identity information on the blockchain, ensuring that each user has a unique and verifiable identity within the system. Registered users can then utilize this identity for subsequent authentication and access control requests.</p></list-item>
<list-item>
<p><bold>UIASC</bold> (User Identity Authentication Smart Contract): Performs authentication of user identities by validating the provided credentials against registered identity data on the blockchain. Only authenticated users are authorized to access system resources.</p></list-item>
<list-item>
<p><bold>ACSC</bold> (Access Control Smart Contract): Enforces access control policies for both users and gateways. It verifies the access level and permissions of each requester, ensuring that all access requests comply with predefined system rules and preventing unauthorized behaviors.</p></list-item>
<list-item>
<p><bold>BSESC</bold> (Behavior Score Evaluation Smart Contract): Calculates a user&#x2019;s behavior score based on both historical and current behavior data, providing a dynamic assessment of reliability. These scores serve as a reference for adjusting user permissions.</p></list-item>
<list-item>
<p><bold>RESC</bold> (Reputation Evaluation Smart Contract): Computes user reputation scores by analyzing their behavior across the system. Users with high scores may receive increased privileges, while those with low scores may face restrictions.</p></list-item>
<list-item>
<p><bold>RASC</bold> (Risk Assessment Smart Contract): Assesses user risk levels by evaluating behavior patterns, helping to estimate potential security threats. High-risk users may be subject to access limitations or stricter controls.</p></list-item>
<list-item>
<p><bold>ZRESC</bold> (ZTNE Reputation Evaluation Smart Contract): Evaluates the reputation of ZTNE gateways by analyzing their behavior and reliability in the system. Gateways with higher reputation scores are granted greater trust and access priority.</p></list-item>
<list-item>
<p><bold>ZRASC</bold> (ZTNE Risk Assessment Smart Contract): Monitors and evaluates the risk level of each gateway to assess its security status. Gateways with elevated risk levels may be subject to operational restrictions or alerts.</p></list-item>
<list-item>
<p><bold>RQCT</bold> (Request Classification): Receives and classifies incoming requests from users and gateways to determine the appropriate smart contract to invoke. This component streamlines system operations and optimizes resource utilization.</p></list-item>
<list-item>
<p><bold>UIE</bold> (User Information Extraction): Extracts relevant identity attributes of users to support authentication and authorization procedures. It ensures precise identity recognition and access environment determination.</p></list-item>
<list-item>
<p><bold>MTPP</bold> (Malicious Traffic Probability Prediction): Analyzes network traffic features to calculate the probability of malicious behavior. The resulting risk scores are used for dynamic permission adjustments and are stored on the blockchain.</p></list-item>
<list-item>
<p><bold>Traffic Monitoring:</bold> Continuously monitors real-time network traffic, extracts user packet features, and forwards them to MTPP for analysis and threat prediction.</p></list-item>
</list></p>
</sec>
<sec id="s3_1_2">
<label>3.1.2</label>
<title>Threat Model</title>
<p>In this paper, the STRIDE (Spoofing-Tampering-Repudiation-Information disclosure-Denial of service-Elevation of privilege) model [<xref ref-type="bibr" rid="ref-22">22</xref>] is used to analyze the security threats in a zero-trust environment, as summarized in <xref ref-type="table" rid="table-4">Table 4</xref>. To mitigate the risks associated with these threats, the following security requirements for the DPZTN are proposed.</p>
<table-wrap id="table-4">
<label>Table 4</label>
<caption>
<title>STRIDE-based threat modeling report</title>
</caption>
<table>
<colgroup>
<col align="center"/>
<col align="center"/>
<col align="center"/>
</colgroup>
<thead>
<tr>
<th align="center">Threat type</th>
<th align="center">Effect</th>
<th align="center">Description</th>
</tr>
</thead>
<tbody>
<tr>
<td>Spoofing</td>
<td>Authentication</td>
<td>Blockchain, ZTNE, Users can all be spoofed</td>
</tr>
<tr>
<td>Tampering</td>
<td>Integrity</td>
<td>Man-in-the-middle attack on transmission data</td>
</tr>
<tr>
<td>Repudiation</td>
<td>Non-repudiation</td>
<td>Users may deny their behavior</td>
</tr>
<tr>
<td>Information disclosure</td>
<td>Confidentiality</td>
<td>Users&#x2019; and ZTNE&#x2019;s information may be accessed by unauthorized third parties on the blockchain</td>
</tr>
<tr>
<td>Denial-of-service</td>
<td>Availability</td>
<td>ZTNE may be overwhelmed by a large number of access requests or DDoS attacks</td>
</tr>
<tr>
<td>Elevation of privilege</td>
<td>Authorization, authentication, confidentiality</td>
<td>Malicious users may be able to overstep their boundaries to access resources</td>
</tr>
</tbody>
</table>
</table-wrap>
<p><list list-type="bullet">
<list-item>
<p><bold>Requirement 1: Continuous verification.</bold> All devices and users within the DPZTN must undergo continuous identity verification. Any device or network that is not explicitly trusted should be distrusted, and all transmitted information must be protected against tampering. This requirement minimizes the risk of impersonation attacks and ensures the confidentiality and integrity of identities.</p></list-item>
<list-item>
<p><bold>Requirement 2: Behavior logging and query.</bold> The behaviors of all users and the status of ZTNEs must be logged to ensure the traceability and non-repudiation of each operation. Blockchain technology is utilized to guarantee the immutability of behavior data.</p></list-item>
<list-item>
<p><bold>Requirement 3: User behavior monitoring and malicious behavior detection.</bold> Network elements within the DPZTN must be capable of monitoring user behavior to prevent system DoS (denial-of-service) attacks, including those originating from DDoS.</p></list-item>
<list-item>
<p><bold>Requirement 4: Principle of least privilege and dynamic evaluation.</bold> DPZTN enforces stringent access control policies, adhering to the principle of least privilege, which restricts user and ZTNE access to only the necessary system resources.</p></list-item>
</list></p>
</sec>
<sec id="s3_1_3">
<label>3.1.3</label>
<title>DPZTN Workflow</title>
<p>The flow of the zero-trust architecture proposed in this paper is described according to the steps outlined in <xref ref-type="fig" rid="fig-1">Fig. 1</xref>:
<list list-type="bullet">
<list-item>
<p><bold>Steps 1&#x2013;4:</bold> When the ZTNE accesses the DPZTN for the first time, it submits an identity registration request to the blockchain. The request is verified through ZIRSC to ensure the uniqueness and legitimacy of the ZTNE. This process is detailed in <xref ref-type="sec" rid="s3_3_1">Section 3.3.1</xref>.</p>
</list-item>
<list-item>
<p><bold>Steps 5&#x2013;8:</bold> Following registration, the ZTNE undergoes authentication. The DPZTN verifies the ZTNE identity using ZIASC, enabling the ZTNE to perform subsequent access control operations. The authentication procedure is outlined in <xref ref-type="sec" rid="s3_3_1">Section 3.3.1</xref>.</p></list-item>
<list-item>
<p><bold>Steps 9&#x2013;16:</bold> When a user accesses the DPZTN for the first time, their identity information is stored on the blockchain through UIRSC. This ensures the user has an independent identity identifier and lays the groundwork for access control. The registration process is described in <xref ref-type="sec" rid="s3_3_2">Section 3.3.2</xref>.</p></list-item>
<list-item>
<p><bold>Steps 17&#x2013;25:</bold> The user then undergoes authentication. The legitimacy of the user&#x2019;s identity is verified through UIASC, allowing the user to request access to DPZTN resources. This step is discussed in <xref ref-type="sec" rid="s3_3_2">Section 3.3.2</xref>.</p></list-item>
<list-item>
<p><bold>Steps 26&#x2013;39:</bold> When a user requests access, ACSC verifies the legitimacy and permissions of the request. It ensures the request complies with the user&#x2019;s assigned access privileges and rejects unauthorized requests. The access control process is explained in <xref ref-type="sec" rid="s3_4">Section 3.4</xref>.</p></list-item>
<list-item>
<p><bold>Steps 40&#x2013;42:</bold> For authorized user traffic, MTP (the Malicious Traffic Probability) component calculates the malicious probability of the traffic in real time and records the result on the blockchain. This workflow is detailed in <xref ref-type="sec" rid="s3_5">Section 3.5</xref>.</p></list-item>
<list-item>
<p><bold>Step 43:</bold> The system dynamically adjusts ZRV (the ZTNE Reputation Value) and ZRR (the ZTNE Risk Value) based on the outcomes from the ZRESC and ZRASC, ensuring the security of DPZTN resources. This is discussed in <xref ref-type="sec" rid="s3_6_1">Sections 3.6.1</xref> and <xref ref-type="sec" rid="s3_6_2">3.6.2</xref>.</p></list-item>
<list-item>
<p><bold>Step 44:</bold> Finally, based on evaluations from the BSESC and RESC, the DPZTN adjusts the user&#x2019;s access privileges, restricting access for high-risk or low-reputation users. This process is described in <xref ref-type="sec" rid="s3_6_3">Sections 3.6.3</xref> and <xref ref-type="sec" rid="s3_6_4">3.6.4</xref>.</p></list-item>
</list></p>
<p>The DPZTN workflow ensures comprehensive coverage from user and ZTNE registration and authentication to dynamic access control. It enhances system security and flexibility through a dynamic adjustment mechanism based on user behavior assessment.</p>
</sec>
</sec>
<sec id="s3_2">
<label>3.2</label>
<title>Encryption and Secure Communications</title>
<p>To ensure the integrity and confidentiality of the above access control workflow, secure communication must be established between users and network components. Therefore, we next elaborate on the encryption and secure communication strategies adopted in DPZTN.</p>
<p>To enable secure communication between users and ZTNE in the DPZTN, a hybrid encryption algorithm combining ECC (Elliptic Curve Cryptography) and AES (Advanced Encryption Standard) is used. These algorithms are used in different phases of the DPZTN: the ECC algorithm is applied during the identity information exchange in the registration phase, the AES algorithm is used for identity authentication during the authentication phase, and both algorithms contribute to the credibility assessment in the access control phase. To protect against unauthorized users accessing the identity information of other users and ZTNEs, all identity data stored in the blockchain is hashed and encrypted, further enhancing security. For users with granted access, the DPZTN continuously monitors, processes, and feeds back their traffic behavior via programmable ZTNEs. If malicious traffic is detected, the DPZTN immediately intercepts the traffic at the Network Layer and removes the user&#x2019;s registration information from the blockchain.</p>
</sec>
<sec id="s3_3">
<label>3.3</label>
<title>Registration and Authentication</title>
<p>With secure channels in place, the next step is to establish trusted identities for users and network entities. This section outlines the registration and authentication mechanisms in DPZTN. Each ZTNE and user must register their identity information, and IoT users employ zero-knowledge proofs to enable anonymous authentication. The relevant symbols are listed in <xref ref-type="table" rid="table-5">Table 5</xref>.</p>
<table-wrap id="table-5">
<label>Table 5</label>
<caption>
<title>Symbols and descriptions</title>
</caption>
<table>
<colgroup>
<col/>
<col/>
<col/>
<col/>
</colgroup>
<thead>
<tr>
<th>Symbol</th>
<th>Description</th>
<th>Symbol</th>
<th>Description</th>
</tr>
</thead>
<tbody>
<tr>
<td><inline-formula id="ieqn-1"><mml:math id="mml-ieqn-1"><mml:mi>Z</mml:mi><mml:mi>T</mml:mi><mml:mi>N</mml:mi><mml:msub><mml:mi>E</mml:mi><mml:mi>i</mml:mi></mml:msub></mml:math></inline-formula></td>
<td>ZTNE</td>
<td><inline-formula id="ieqn-2"><mml:math id="mml-ieqn-2"><mml:mi>P</mml:mi><mml:msub><mml:mi>K</mml:mi><mml:mrow><mml:mi>Z</mml:mi><mml:mi>T</mml:mi><mml:mi>N</mml:mi><mml:msub><mml:mi>E</mml:mi><mml:mi>i</mml:mi></mml:msub></mml:mrow></mml:msub></mml:math></inline-formula></td>
<td>ZTNE public key</td>
</tr>
<tr>
<td><inline-formula id="ieqn-3"><mml:math id="mml-ieqn-3"><mml:mi>S</mml:mi><mml:msub><mml:mi>K</mml:mi><mml:mrow><mml:mi>Z</mml:mi><mml:mi>T</mml:mi><mml:mi>N</mml:mi><mml:msub><mml:mi>E</mml:mi><mml:mi>i</mml:mi></mml:msub></mml:mrow></mml:msub></mml:math></inline-formula></td>
<td>ZTNE private key</td>
<td><inline-formula id="ieqn-4"><mml:math id="mml-ieqn-4"><mml:mi>Z</mml:mi><mml:mi>I</mml:mi><mml:msub><mml:mi>D</mml:mi><mml:mi>i</mml:mi></mml:msub></mml:math></inline-formula></td>
<td>ZTNE identifier</td>
</tr>
<tr>
<td><inline-formula id="ieqn-5"><mml:math id="mml-ieqn-5"><mml:mi>Z</mml:mi><mml:mi>T</mml:mi><mml:mi>N</mml:mi><mml:msub><mml:mi>E</mml:mi><mml:mrow><mml:mi>I</mml:mi><mml:mi>n</mml:mi><mml:mi>f</mml:mi><mml:msub><mml:mi>o</mml:mi><mml:mi>i</mml:mi></mml:msub></mml:mrow></mml:msub></mml:math></inline-formula></td>
<td>ZTNE identity information</td>
<td><inline-formula id="ieqn-6"><mml:math id="mml-ieqn-6"><mml:mi>H</mml:mi><mml:mi>a</mml:mi><mml:mi>s</mml:mi><mml:msub><mml:mi>h</mml:mi><mml:mrow><mml:mi>I</mml:mi><mml:mi>n</mml:mi><mml:mi>f</mml:mi><mml:msub><mml:mi>o</mml:mi><mml:mi>i</mml:mi></mml:msub></mml:mrow></mml:msub></mml:math></inline-formula></td>
<td>ZTNE encrypted identity information</td>
</tr>
<tr>
<td><inline-formula id="ieqn-7"><mml:math id="mml-ieqn-7"><mml:mi>K</mml:mi><mml:mi>e</mml:mi><mml:msub><mml:mi>y</mml:mi><mml:mrow><mml:mi>Z</mml:mi><mml:mi>T</mml:mi><mml:mi>N</mml:mi><mml:msub><mml:mi>E</mml:mi><mml:mi>i</mml:mi></mml:msub></mml:mrow></mml:msub></mml:math></inline-formula></td>
<td>ZTNE symmetric key</td>
<td><inline-formula id="ieqn-8"><mml:math id="mml-ieqn-8"><mml:mi>B</mml:mi><mml:msub><mml:mi>C</mml:mi><mml:mi>i</mml:mi></mml:msub></mml:math></inline-formula></td>
<td>Blockchain nodes for ZTNE</td>
</tr>
<tr>
<td><inline-formula id="ieqn-9"><mml:math id="mml-ieqn-9"><mml:mi>P</mml:mi><mml:msub><mml:mi>K</mml:mi><mml:mrow><mml:mi>B</mml:mi><mml:msub><mml:mi>C</mml:mi><mml:mi>i</mml:mi></mml:msub></mml:mrow></mml:msub></mml:math></inline-formula></td>
<td>Blockchain public key</td>
<td><inline-formula id="ieqn-10"><mml:math id="mml-ieqn-10"><mml:mi>S</mml:mi><mml:msub><mml:mi>K</mml:mi><mml:mrow><mml:mi>B</mml:mi><mml:msub><mml:mi>C</mml:mi><mml:mi>i</mml:mi></mml:msub></mml:mrow></mml:msub></mml:math></inline-formula></td>
<td>Blockchain private key</td>
</tr>
<tr>
<td><inline-formula id="ieqn-11"><mml:math id="mml-ieqn-11"><mml:msub><mml:mi>U</mml:mi><mml:mi>j</mml:mi></mml:msub></mml:math></inline-formula></td>
<td>IoT users</td>
<td><inline-formula id="ieqn-12"><mml:math id="mml-ieqn-12"><mml:mi>P</mml:mi><mml:msub><mml:mi>K</mml:mi><mml:mrow><mml:msub><mml:mi>U</mml:mi><mml:mi>j</mml:mi></mml:msub></mml:mrow></mml:msub></mml:math></inline-formula></td>
<td>User public key</td>
</tr>
<tr>
<td><inline-formula id="ieqn-13"><mml:math id="mml-ieqn-13"><mml:mi>S</mml:mi><mml:msub><mml:mi>K</mml:mi><mml:mrow><mml:msub><mml:mi>U</mml:mi><mml:mi>j</mml:mi></mml:msub></mml:mrow></mml:msub></mml:math></inline-formula></td>
<td>User private key</td>
<td><inline-formula id="ieqn-14"><mml:math id="mml-ieqn-14"><mml:mi>U</mml:mi><mml:mi>I</mml:mi><mml:msub><mml:mi>D</mml:mi><mml:mrow><mml:mi>I</mml:mi><mml:mi>n</mml:mi><mml:mi>f</mml:mi><mml:msub><mml:mi>o</mml:mi><mml:mi>j</mml:mi></mml:msub></mml:mrow></mml:msub></mml:math></inline-formula></td>
<td>User identity information</td>
</tr>
<tr>
<td><inline-formula id="ieqn-15"><mml:math id="mml-ieqn-15"><mml:mi>U</mml:mi><mml:mi>I</mml:mi><mml:msub><mml:mi>D</mml:mi><mml:mi>j</mml:mi></mml:msub></mml:math></inline-formula></td>
<td>User identifier</td>
<td><inline-formula id="ieqn-16"><mml:math id="mml-ieqn-16"><mml:mi>K</mml:mi><mml:mi>e</mml:mi><mml:msub><mml:mi>y</mml:mi><mml:mrow><mml:msub><mml:mi>U</mml:mi><mml:mi>j</mml:mi></mml:msub></mml:mrow></mml:msub></mml:math></inline-formula></td>
<td>User symmetric key</td>
</tr>
<tr>
<td><italic>TS</italic></td>
<td>Timestamp</td>
<td></td>
<td></td>
</tr>
</tbody>
</table>
</table-wrap>
<sec id="s3_3_1">
<label>3.3.1</label>
<title>ZTNE Registration and Authentication</title>
<p>As 5G-AKA implements mutual authentication between the user and the service network, the ZTNE must also register its identity information and undergo bidirectional authentication with the blockchain. The registration and authentication process for the ZTNE is illustrated in <xref ref-type="fig" rid="fig-2">Fig. 2</xref>.</p>
<fig id="fig-2">
<label>Figure 2</label>
<caption>
<title>DPZTN architecture and workflows</title>
</caption>
<graphic mimetype="image" mime-subtype="tif" xlink:href="CSSE_68151-fig-2.tif"/>
</fig>
<p><bold>ZTNE registration:</bold> Before the ZTNE registration, <inline-formula id="ieqn-17"><mml:math id="mml-ieqn-17"><mml:mi>Z</mml:mi><mml:mi>T</mml:mi><mml:mi>N</mml:mi><mml:msub><mml:mi>E</mml:mi><mml:mi>i</mml:mi></mml:msub></mml:math></inline-formula> and <inline-formula id="ieqn-18"><mml:math id="mml-ieqn-18"><mml:mi>B</mml:mi><mml:msub><mml:mi>C</mml:mi><mml:mi>i</mml:mi></mml:msub></mml:math></inline-formula> use the <inline-formula id="ieqn-19"><mml:math id="mml-ieqn-19"><mml:mi>E</mml:mi><mml:mi>C</mml:mi><mml:msub><mml:mi>C</mml:mi><mml:mrow><mml:mi>K</mml:mi><mml:mi>e</mml:mi><mml:mi>y</mml:mi><mml:mi>G</mml:mi><mml:mi>e</mml:mi><mml:mi>n</mml:mi></mml:mrow></mml:msub></mml:math></inline-formula> function to generate their respective key pairs. ZTNE generates <inline-formula id="ieqn-20"><mml:math id="mml-ieqn-20"><mml:mrow><mml:mo>(</mml:mo><mml:mi>P</mml:mi><mml:msub><mml:mi>K</mml:mi><mml:mrow><mml:mi>Z</mml:mi><mml:mi>T</mml:mi><mml:mi>N</mml:mi><mml:msub><mml:mi>E</mml:mi><mml:mi>i</mml:mi></mml:msub></mml:mrow></mml:msub><mml:mo>,</mml:mo><mml:mi>S</mml:mi><mml:msub><mml:mi>K</mml:mi><mml:mrow><mml:mi>Z</mml:mi><mml:mi>T</mml:mi><mml:mi>N</mml:mi><mml:msub><mml:mi>E</mml:mi><mml:mi>i</mml:mi></mml:msub></mml:mrow></mml:msub><mml:mo>)</mml:mo></mml:mrow></mml:math></inline-formula>, and Blockchain generates <inline-formula id="ieqn-21"><mml:math id="mml-ieqn-21"><mml:mrow><mml:mo>(</mml:mo><mml:mi>P</mml:mi><mml:msub><mml:mi>K</mml:mi><mml:mrow><mml:mi>B</mml:mi><mml:msub><mml:mi>C</mml:mi><mml:mi>i</mml:mi></mml:msub></mml:mrow></mml:msub><mml:mo>,</mml:mo><mml:mi>S</mml:mi><mml:msub><mml:mi>K</mml:mi><mml:mrow><mml:mi>B</mml:mi><mml:msub><mml:mi>C</mml:mi><mml:mi>i</mml:mi></mml:msub></mml:mrow></mml:msub><mml:mo>)</mml:mo></mml:mrow></mml:math></inline-formula>, and they exchange their <inline-formula id="ieqn-22"><mml:math id="mml-ieqn-22"><mml:mi>P</mml:mi><mml:msub><mml:mi>K</mml:mi><mml:mrow><mml:mi>Z</mml:mi><mml:mi>T</mml:mi><mml:mi>N</mml:mi><mml:msub><mml:mi>E</mml:mi><mml:mi>i</mml:mi></mml:msub></mml:mrow></mml:msub></mml:math></inline-formula> and <inline-formula id="ieqn-23"><mml:math id="mml-ieqn-23"><mml:mi>P</mml:mi><mml:msub><mml:mi>K</mml:mi><mml:mrow><mml:mi>B</mml:mi><mml:msub><mml:mi>C</mml:mi><mml:mi>i</mml:mi></mml:msub></mml:mrow></mml:msub></mml:math></inline-formula>. ZTNE hashes and encrypts its own identity information <inline-formula id="ieqn-24"><mml:math id="mml-ieqn-24"><mml:mi>Z</mml:mi><mml:mi>T</mml:mi><mml:mi>N</mml:mi><mml:msub><mml:mi>E</mml:mi><mml:mrow><mml:mi>I</mml:mi><mml:mi>n</mml:mi><mml:mi>f</mml:mi><mml:msub><mml:mi>o</mml:mi><mml:mi>i</mml:mi></mml:msub></mml:mrow></mml:msub></mml:math></inline-formula> to get <inline-formula id="ieqn-25"><mml:math id="mml-ieqn-25"><mml:mi>H</mml:mi><mml:mi>a</mml:mi><mml:mi>s</mml:mi><mml:msub><mml:mi>h</mml:mi><mml:mrow><mml:mi>I</mml:mi><mml:mi>n</mml:mi><mml:mi>f</mml:mi><mml:msub><mml:mi>o</mml:mi><mml:mi>i</mml:mi></mml:msub></mml:mrow></mml:msub></mml:math></inline-formula>. Then, ZTNE encrypts <inline-formula id="ieqn-26"><mml:math id="mml-ieqn-26"><mml:mi>H</mml:mi><mml:mi>a</mml:mi><mml:mi>s</mml:mi><mml:msub><mml:mi>h</mml:mi><mml:mrow><mml:mi>I</mml:mi><mml:mi>n</mml:mi><mml:mi>f</mml:mi><mml:msub><mml:mi>o</mml:mi><mml:mi>i</mml:mi></mml:msub></mml:mrow></mml:msub></mml:math></inline-formula> and the session key <inline-formula id="ieqn-27"><mml:math id="mml-ieqn-27"><mml:mi>k</mml:mi><mml:mi>e</mml:mi><mml:msub><mml:mi>y</mml:mi><mml:mrow><mml:mi>A</mml:mi><mml:mi>E</mml:mi><mml:mi>S</mml:mi></mml:mrow></mml:msub></mml:math></inline-formula> using <inline-formula id="ieqn-28"><mml:math id="mml-ieqn-28"><mml:mi>P</mml:mi><mml:msub><mml:mi>K</mml:mi><mml:mrow><mml:mi>B</mml:mi><mml:msub><mml:mi>C</mml:mi><mml:mi>i</mml:mi></mml:msub></mml:mrow></mml:msub></mml:math></inline-formula> and adds the timestamp <inline-formula id="ieqn-29"><mml:math id="mml-ieqn-29"><mml:mi>T</mml:mi><mml:msub><mml:mi>S</mml:mi><mml:mn>1</mml:mn></mml:msub></mml:math></inline-formula> to form <inline-formula id="ieqn-30"><mml:math id="mml-ieqn-30"><mml:msub><mml:mi>M</mml:mi><mml:mn>1</mml:mn></mml:msub></mml:math></inline-formula>, which is sent to the blockchain. The blockchain decrypts the message using <inline-formula id="ieqn-31"><mml:math id="mml-ieqn-31"><mml:mi>S</mml:mi><mml:msub><mml:mi>K</mml:mi><mml:mrow><mml:mi>B</mml:mi><mml:msub><mml:mi>C</mml:mi><mml:mi>i</mml:mi></mml:msub></mml:mrow></mml:msub></mml:math></inline-formula> to get the ZTNE encrypted <inline-formula id="ieqn-32"><mml:math id="mml-ieqn-32"><mml:mi>H</mml:mi><mml:mi>a</mml:mi><mml:mi>s</mml:mi><mml:msub><mml:mi>h</mml:mi><mml:mrow><mml:mi>I</mml:mi><mml:mi>n</mml:mi><mml:mi>f</mml:mi><mml:msub><mml:mi>o</mml:mi><mml:mi>i</mml:mi></mml:msub></mml:mrow></mml:msub></mml:math></inline-formula>. The smart contract ZRISC generates the ZTNE global unique identifier <inline-formula id="ieqn-33"><mml:math id="mml-ieqn-33"><mml:mi>Z</mml:mi><mml:mi>I</mml:mi><mml:msub><mml:mi>D</mml:mi><mml:mi>i</mml:mi></mml:msub></mml:math></inline-formula> using the uuid function. The blockchain sends <inline-formula id="ieqn-34"><mml:math id="mml-ieqn-34"><mml:mi>Z</mml:mi><mml:mi>I</mml:mi><mml:msub><mml:mi>D</mml:mi><mml:mi>i</mml:mi></mml:msub></mml:math></inline-formula> and its signature to ZTNE. ZTNE decrypts the message <inline-formula id="ieqn-35"><mml:math id="mml-ieqn-35"><mml:msub><mml:mi>M</mml:mi><mml:mn>2</mml:mn></mml:msub></mml:math></inline-formula> and verifies the message with <inline-formula id="ieqn-36"><mml:math id="mml-ieqn-36"><mml:mi>Z</mml:mi><mml:mi>I</mml:mi><mml:msub><mml:mi>D</mml:mi><mml:mi>i</mml:mi></mml:msub></mml:math></inline-formula>, which completes the registration process.</p>
<p><bold>ZTNE authentication:</bold> ZTNE recalculates its own identity information <inline-formula id="ieqn-37"><mml:math id="mml-ieqn-37"><mml:mi>Z</mml:mi><mml:mi>T</mml:mi><mml:mi>N</mml:mi><mml:msub><mml:mi>E</mml:mi><mml:mrow><mml:mi>I</mml:mi><mml:mi>n</mml:mi><mml:mi>f</mml:mi><mml:msub><mml:mi>o</mml:mi><mml:mi>i</mml:mi></mml:msub></mml:mrow></mml:msub></mml:math></inline-formula> at the time of registration using a hash algorithm to get <inline-formula id="ieqn-38"><mml:math id="mml-ieqn-38"><mml:mi>H</mml:mi><mml:mi>a</mml:mi><mml:mi>s</mml:mi><mml:msub><mml:mi>h</mml:mi><mml:mrow><mml:mi>I</mml:mi><mml:mi>n</mml:mi><mml:mi>f</mml:mi><mml:msub><mml:mi>o</mml:mi><mml:mi>i</mml:mi></mml:msub></mml:mrow></mml:msub></mml:math></inline-formula> and inputs it into the <inline-formula id="ieqn-39"><mml:math id="mml-ieqn-39"><mml:mi>Z</mml:mi><mml:msub><mml:mi>K</mml:mi><mml:mrow><mml:mi>P</mml:mi><mml:mi>r</mml:mi><mml:mi>o</mml:mi><mml:mi>o</mml:mi><mml:mi>f</mml:mi></mml:mrow></mml:msub></mml:math></inline-formula> function to generate the <inline-formula id="ieqn-40"><mml:math id="mml-ieqn-40"><mml:mi>P</mml:mi><mml:mi>r</mml:mi><mml:mi>o</mml:mi><mml:mi>o</mml:mi><mml:mi>f</mml:mi></mml:math></inline-formula>. ZTNE sends <inline-formula id="ieqn-41"><mml:math id="mml-ieqn-41"><mml:mi>P</mml:mi><mml:mi>r</mml:mi><mml:mi>o</mml:mi><mml:mi>o</mml:mi><mml:mi>f</mml:mi></mml:math></inline-formula> to the blockchain. After receiving the message, the blockchain verifies the proof using the <inline-formula id="ieqn-42"><mml:math id="mml-ieqn-42"><mml:mi>Z</mml:mi><mml:msub><mml:mi>K</mml:mi><mml:mrow><mml:mi>V</mml:mi><mml:mi>e</mml:mi><mml:mi>r</mml:mi><mml:mi>i</mml:mi><mml:mi>f</mml:mi><mml:mi>y</mml:mi></mml:mrow></mml:msub></mml:math></inline-formula> function, which relies on ZIASC. The blockchain receives and verifies the message, then returns the verification result to ZTNE, which uses the verification result to complete the authentication process.</p>
</sec>
<sec id="s3_3_2">
<label>3.3.2</label>
<title>User Registration and Authentication</title>
<p>When a user connects to the DPZTN for the first time, the user must register the user identity information with the ZTNE. The ZTNE deposits the user information into the blockchain, the user identity registration and authentication process is shown in <xref ref-type="fig" rid="fig-3">Fig. 3</xref>.</p>
<fig id="fig-3">
<label>Figure 3</label>
<caption>
<title>User registration and authentication flows</title>
</caption>
<graphic mimetype="image" mime-subtype="tif" xlink:href="CSSE_68151-fig-3.tif"/>
</fig>
<p><bold>User registration:</bold> Before registration, the public key exchange between <inline-formula id="ieqn-43"><mml:math id="mml-ieqn-43"><mml:msub><mml:mi>U</mml:mi><mml:mi>j</mml:mi></mml:msub></mml:math></inline-formula>, <inline-formula id="ieqn-44"><mml:math id="mml-ieqn-44"><mml:mi>Z</mml:mi><mml:mi>T</mml:mi><mml:mi>N</mml:mi><mml:msub><mml:mi>E</mml:mi><mml:mi>i</mml:mi></mml:msub></mml:math></inline-formula>, and <inline-formula id="ieqn-45"><mml:math id="mml-ieqn-45"><mml:mi>B</mml:mi><mml:msub><mml:mi>C</mml:mi><mml:mi>i</mml:mi></mml:msub></mml:math></inline-formula> is completed, and ZTNE has completed the registration and authentication process. The user enters the registration information and hashes the password contained in the registration data. The <inline-formula id="ieqn-46"><mml:math id="mml-ieqn-46"><mml:mi>Z</mml:mi><mml:mi>K</mml:mi><mml:mi>P</mml:mi><mml:mi>r</mml:mi><mml:mi>o</mml:mi><mml:mi>o</mml:mi><mml:mi>f</mml:mi></mml:math></inline-formula> function is used to generate a zero-knowledge Proof for subsequent authentication. The user sends the identity information <inline-formula id="ieqn-47"><mml:math id="mml-ieqn-47"><mml:msub><mml:mrow><mml:mi>U</mml:mi><mml:mi>I</mml:mi><mml:mi>D</mml:mi></mml:mrow><mml:mrow><mml:mi>I</mml:mi><mml:mi>n</mml:mi><mml:mi>f</mml:mi><mml:msub><mml:mi>o</mml:mi><mml:mi>j</mml:mi></mml:msub></mml:mrow></mml:msub></mml:math></inline-formula>, <inline-formula id="ieqn-48"><mml:math id="mml-ieqn-48"><mml:mi>P</mml:mi><mml:mi>r</mml:mi><mml:mi>o</mml:mi><mml:mi>o</mml:mi><mml:mi>f</mml:mi></mml:math></inline-formula>, <inline-formula id="ieqn-49"><mml:math id="mml-ieqn-49"><mml:mi>P</mml:mi><mml:msub><mml:mi>K</mml:mi><mml:mrow><mml:msub><mml:mi>U</mml:mi><mml:mi>j</mml:mi></mml:msub></mml:mrow></mml:msub></mml:math></inline-formula>, and <inline-formula id="ieqn-50"><mml:math id="mml-ieqn-50"><mml:mi>T</mml:mi><mml:msub><mml:mi>S</mml:mi><mml:mn>1</mml:mn></mml:msub></mml:math></inline-formula> to <inline-formula id="ieqn-51"><mml:math id="mml-ieqn-51"><mml:mi>B</mml:mi><mml:msub><mml:mi>C</mml:mi><mml:mi>i</mml:mi></mml:msub></mml:math></inline-formula>. The blockchain decrypts the user information to obtain the information required for user registration <inline-formula id="ieqn-52"><mml:math id="mml-ieqn-52"><mml:msub><mml:mrow><mml:mi>U</mml:mi><mml:mi>I</mml:mi><mml:mi>D</mml:mi></mml:mrow><mml:mrow><mml:mi>I</mml:mi><mml:mi>n</mml:mi><mml:mi>f</mml:mi><mml:msub><mml:mi>o</mml:mi><mml:mi>j</mml:mi></mml:msub></mml:mrow></mml:msub></mml:math></inline-formula>. It then calls the UIRSC to generate <inline-formula id="ieqn-53"><mml:math id="mml-ieqn-53"><mml:mi>U</mml:mi><mml:mi>I</mml:mi><mml:msub><mml:mi>D</mml:mi><mml:mi>j</mml:mi></mml:msub></mml:math></inline-formula> for the user, completing the registration process.</p>
<p><bold>User authentication:</bold> The user is authenticated immediately after completing the registration process. The blockchain uses the <inline-formula id="ieqn-54"><mml:math id="mml-ieqn-54"><mml:mi>U</mml:mi><mml:mi>I</mml:mi><mml:msub><mml:mi>D</mml:mi><mml:mi>j</mml:mi></mml:msub></mml:math></inline-formula> to generate <inline-formula id="ieqn-55"><mml:math id="mml-ieqn-55"><mml:mi>S</mml:mi><mml:mi>i</mml:mi><mml:msub><mml:mi>g</mml:mi><mml:mrow><mml:mi>B</mml:mi><mml:msub><mml:mi>C</mml:mi><mml:mi>i</mml:mi></mml:msub></mml:mrow></mml:msub></mml:math></inline-formula> and sends it to ZTNE with <inline-formula id="ieqn-56"><mml:math id="mml-ieqn-56"><mml:mi>K</mml:mi><mml:mi>e</mml:mi><mml:msub><mml:mi>y</mml:mi><mml:mrow><mml:mi>Z</mml:mi><mml:mi>T</mml:mi><mml:mi>N</mml:mi><mml:msub><mml:mi>E</mml:mi><mml:mi>i</mml:mi></mml:msub></mml:mrow></mml:msub></mml:math></inline-formula>. After receiving the user identifier, the ZTNE generates <inline-formula id="ieqn-57"><mml:math id="mml-ieqn-57"><mml:mi>S</mml:mi><mml:mi>i</mml:mi><mml:msub><mml:mi>g</mml:mi><mml:mrow><mml:mi>Z</mml:mi><mml:mi>T</mml:mi><mml:mi>N</mml:mi><mml:msub><mml:mi>E</mml:mi><mml:mi>i</mml:mi></mml:msub></mml:mrow></mml:msub></mml:math></inline-formula> and sends <inline-formula id="ieqn-58"><mml:math id="mml-ieqn-58"><mml:mi>U</mml:mi><mml:mi>I</mml:mi><mml:msub><mml:mi>D</mml:mi><mml:mi>j</mml:mi></mml:msub></mml:math></inline-formula>, <inline-formula id="ieqn-59"><mml:math id="mml-ieqn-59"><mml:mi>S</mml:mi><mml:mi>i</mml:mi><mml:msub><mml:mi>g</mml:mi><mml:mrow><mml:mi>B</mml:mi><mml:msub><mml:mi>C</mml:mi><mml:mi>i</mml:mi></mml:msub></mml:mrow></mml:msub></mml:math></inline-formula>, <inline-formula id="ieqn-60"><mml:math id="mml-ieqn-60"><mml:mi>S</mml:mi><mml:mi>i</mml:mi><mml:msub><mml:mi>g</mml:mi><mml:mrow><mml:mi>Z</mml:mi><mml:mi>T</mml:mi><mml:mi>N</mml:mi><mml:msub><mml:mi>E</mml:mi><mml:mi>i</mml:mi></mml:msub></mml:mrow></mml:msub></mml:math></inline-formula>, and <inline-formula id="ieqn-61"><mml:math id="mml-ieqn-61"><mml:mi>T</mml:mi><mml:msub><mml:mi>S</mml:mi><mml:mn>3</mml:mn></mml:msub></mml:math></inline-formula> to the user. On decrypting the message, the user verifies <inline-formula id="ieqn-62"><mml:math id="mml-ieqn-62"><mml:mi>S</mml:mi><mml:mi>i</mml:mi><mml:msub><mml:mi>g</mml:mi><mml:mrow><mml:mi>B</mml:mi><mml:msub><mml:mi>C</mml:mi><mml:mi>i</mml:mi></mml:msub></mml:mrow></mml:msub></mml:math></inline-formula> and <inline-formula id="ieqn-63"><mml:math id="mml-ieqn-63"><mml:mi>S</mml:mi><mml:mi>i</mml:mi><mml:msub><mml:mi>g</mml:mi><mml:mrow><mml:mi>Z</mml:mi><mml:mi>T</mml:mi><mml:mi>N</mml:mi><mml:msub><mml:mi>E</mml:mi><mml:mi>i</mml:mi></mml:msub></mml:mrow></mml:msub></mml:math></inline-formula> using <inline-formula id="ieqn-64"><mml:math id="mml-ieqn-64"><mml:mi>E</mml:mi><mml:mi>C</mml:mi><mml:msub><mml:mi>C</mml:mi><mml:mrow><mml:mi>V</mml:mi><mml:mi>e</mml:mi><mml:mi>r</mml:mi><mml:mi>i</mml:mi><mml:mi>f</mml:mi><mml:mi>y</mml:mi></mml:mrow></mml:msub></mml:math></inline-formula>. If both <inline-formula id="ieqn-65"><mml:math id="mml-ieqn-65"><mml:mi>S</mml:mi><mml:mi>i</mml:mi><mml:msub><mml:mi>g</mml:mi><mml:mrow><mml:mi>B</mml:mi><mml:msub><mml:mi>C</mml:mi><mml:mi>i</mml:mi></mml:msub></mml:mrow></mml:msub></mml:math></inline-formula> and <inline-formula id="ieqn-66"><mml:math id="mml-ieqn-66"><mml:mi>S</mml:mi><mml:mi>i</mml:mi><mml:msub><mml:mi>g</mml:mi><mml:mrow><mml:mi>Z</mml:mi><mml:mi>T</mml:mi><mml:mi>N</mml:mi><mml:msub><mml:mi>E</mml:mi><mml:mi>i</mml:mi></mml:msub></mml:mrow></mml:msub></mml:math></inline-formula> are verified, the user and blockchain are authenticated bidirectionally. The user then generates a new proof, <inline-formula id="ieqn-67"><mml:math id="mml-ieqn-67"><mml:mi>P</mml:mi><mml:mi>r</mml:mi><mml:mi>o</mml:mi><mml:mi>o</mml:mi><mml:msup><mml:mi>f</mml:mi><mml:mrow><mml:mi mathvariant="normal">&#x2032;</mml:mi></mml:mrow></mml:msup></mml:math></inline-formula>, based on the input user information and sends the <inline-formula id="ieqn-68"><mml:math id="mml-ieqn-68"><mml:mi>U</mml:mi><mml:mi>I</mml:mi><mml:msub><mml:mi>D</mml:mi><mml:mi>j</mml:mi></mml:msub></mml:math></inline-formula> and <inline-formula id="ieqn-69"><mml:math id="mml-ieqn-69"><mml:mi>T</mml:mi><mml:msub><mml:mi>S</mml:mi><mml:mn>4</mml:mn></mml:msub></mml:math></inline-formula> to ZTNE. The blockchain calls the Proof, and ZTNE calls the zero-knowledge verification function <inline-formula id="ieqn-70"><mml:math id="mml-ieqn-70"><mml:mi>Z</mml:mi><mml:mi>K</mml:mi><mml:msub><mml:mi>P</mml:mi><mml:mrow><mml:mi>V</mml:mi><mml:mi>e</mml:mi><mml:mi>r</mml:mi><mml:mi>i</mml:mi><mml:mi>f</mml:mi><mml:mi>y</mml:mi></mml:mrow></mml:msub></mml:math></inline-formula> to authenticate <inline-formula id="ieqn-71"><mml:math id="mml-ieqn-71"><mml:mi>P</mml:mi><mml:mi>r</mml:mi><mml:mi>o</mml:mi><mml:mi>o</mml:mi><mml:mi>f</mml:mi></mml:math></inline-formula> and <inline-formula id="ieqn-72"><mml:math id="mml-ieqn-72"><mml:mi>P</mml:mi><mml:mi>r</mml:mi><mml:mi>o</mml:mi><mml:mi>o</mml:mi><mml:msup><mml:mi>f</mml:mi><mml:mrow><mml:mi mathvariant="normal">&#x2032;</mml:mi></mml:mrow></mml:msup></mml:math></inline-formula>. If the user passes the authentication, the user provides the session key to ZTNE for subsequent secure communication. If the authentication fails, the user authentication process is terminated.</p>
</sec>
</sec>
<sec id="s3_4">
<label>3.4</label>
<title>Access Control Based on User Behavior</title>
<p>Once the identities of users and ZTNEs have been securely verified, it becomes essential to determine whether access requests should be granted. The following section introduces a behavior-based access control scheme that adapts dynamically to user behavior.</p>
<sec id="s3_4_1">
<label>3.4.1</label>
<title>User Behavior-Based Access Control</title>
<p>As shown in <xref ref-type="fig" rid="fig-3">Fig. 3</xref>, users are assigned access privileges based on their roles after registration. The access privilege defines the maximum privilege boundaries for the user. Even if the user&#x2019;s behavior is good, the user&#x2019;s access privilege level cannot exceed the role&#x2019;s permission boundary.</p>
<p>In the smart contract ACSC, this paper assign the user&#x2019;s role as <inline-formula id="ieqn-73"><mml:math id="mml-ieqn-73"><mml:mi>R</mml:mi><mml:mi>o</mml:mi><mml:mi>l</mml:mi><mml:msub><mml:mi>e</mml:mi><mml:mrow><mml:msub><mml:mi>U</mml:mi><mml:mi>j</mml:mi></mml:msub></mml:mrow></mml:msub><mml:mo>&#x2208;</mml:mo></mml:math></inline-formula> {<italic>RU(Regular User), PU(Premium User), Admin(Administrator)</italic>} corresponding to the access privilege <inline-formula id="ieqn-74"><mml:math id="mml-ieqn-74"><mml:msub><mml:mi>P</mml:mi><mml:mrow><mml:msub><mml:mi>U</mml:mi><mml:mi>j</mml:mi></mml:msub></mml:mrow></mml:msub><mml:mo>&#x2208;</mml:mo><mml:mo fence="false" stretchy="false">{</mml:mo><mml:mi>L</mml:mi><mml:mn>1</mml:mn><mml:mo>,</mml:mo><mml:mi>L</mml:mi><mml:mn>2</mml:mn><mml:mo>,</mml:mo><mml:mi>L</mml:mi><mml:mn>3</mml:mn><mml:mo fence="false" stretchy="false">}</mml:mo></mml:math></inline-formula>. The access range corresponding to each access privilege is divided into 10 access privilege levels, and the initial access privilege level is set to 5 in the corresponding access range. Users are allowed to access beyond the initial access privilege level within the privilege range, but such operations will be marked as sensitive behavior, which ensures the DPZTN can monitor the overstepping access. By binding roles to permissions, the DPZTN ensures a clear and defined assignment of access privileges at the time of user registration.</p>
<p>In this paper, a UABAC (user attribute-based access control) algorithm is implemented within the ACSC of the blockchain, as shown in Algorithm 1. Initially, the user&#x2019;s behavior score is computed by evaluating the user&#x2019;s reputation value <inline-formula id="ieqn-75"><mml:math id="mml-ieqn-75"><mml:msubsup><mml:mi>R</mml:mi><mml:mrow><mml:msub><mml:mi>U</mml:mi><mml:mi>j</mml:mi></mml:msub></mml:mrow><mml:mo>+</mml:mo></mml:msubsup></mml:math></inline-formula> and risk value <inline-formula id="ieqn-76"><mml:math id="mml-ieqn-76"><mml:msubsup><mml:mi>R</mml:mi><mml:mrow><mml:msub><mml:mi>U</mml:mi><mml:mi>j</mml:mi></mml:msub></mml:mrow><mml:mo>&#x2212;</mml:mo></mml:msubsup></mml:math></inline-formula>, using the formula:
<disp-formula id="eqn-1"><label>(1)</label><mml:math id="mml-eqn-1" display="block"><mml:mi>A</mml:mi><mml:mi>S</mml:mi><mml:mo stretchy="false">(</mml:mo><mml:msub><mml:mi>U</mml:mi><mml:mi>j</mml:mi></mml:msub><mml:mo stretchy="false">)</mml:mo><mml:mo>=</mml:mo><mml:mi>&#x03B1;</mml:mi><mml:mo>&#x22C5;</mml:mo><mml:msubsup><mml:mi>R</mml:mi><mml:mrow><mml:msub><mml:mi>U</mml:mi><mml:mi>j</mml:mi></mml:msub></mml:mrow><mml:mrow><mml:mo>+</mml:mo></mml:mrow></mml:msubsup><mml:mo>+</mml:mo><mml:mi>&#x03B2;</mml:mi><mml:mo>&#x22C5;</mml:mo><mml:msubsup><mml:mi>R</mml:mi><mml:mrow><mml:msub><mml:mi>U</mml:mi><mml:mi>j</mml:mi></mml:msub></mml:mrow><mml:mrow><mml:mo>&#x2212;</mml:mo></mml:mrow></mml:msubsup></mml:math></disp-formula></p>
<p>If the behavior score <inline-formula id="ieqn-77"><mml:math id="mml-ieqn-77"><mml:mi>A</mml:mi><mml:mi>S</mml:mi><mml:mo stretchy="false">(</mml:mo><mml:msub><mml:mi>U</mml:mi><mml:mi>j</mml:mi></mml:msub><mml:mo stretchy="false">)</mml:mo></mml:math></inline-formula> is below the threshold <inline-formula id="ieqn-78"><mml:math id="mml-ieqn-78"><mml:mi>A</mml:mi><mml:mi>S</mml:mi><mml:mo stretchy="false">(</mml:mo><mml:msub><mml:mi>U</mml:mi><mml:mi>j</mml:mi></mml:msub><mml:msub><mml:mo stretchy="false">)</mml:mo><mml:mrow><mml:mi>t</mml:mi><mml:mi>h</mml:mi></mml:mrow></mml:msub></mml:math></inline-formula>, the ZTNE promptly rejects the access request. This step effectively filters out unqualified requests, minimizing the need for further processing. The detailed calculation of the behavior score is performed in the BSESC, as described in <xref ref-type="sec" rid="s3_6_4">Section 3.6.4</xref>.</p>
<fig id="fig-11">
<graphic mimetype="image" mime-subtype="tif" xlink:href="CSSE_68151-fig-11.tif"/>
</fig>
<p>Once the behavior score is validated, the ACSC further assesses whether the user&#x2019;s risk value <inline-formula id="ieqn-88"><mml:math id="mml-ieqn-88"><mml:msubsup><mml:mi>R</mml:mi><mml:mrow><mml:msub><mml:mi>U</mml:mi><mml:mi>j</mml:mi></mml:msub></mml:mrow><mml:mo>&#x2212;</mml:mo></mml:msubsup></mml:math></inline-formula> surpasses the risk threshold <inline-formula id="ieqn-89"><mml:math id="mml-ieqn-89"><mml:msub><mml:mrow><mml:msubsup><mml:mi>R</mml:mi><mml:mrow><mml:msub><mml:mi>U</mml:mi><mml:mi>j</mml:mi></mml:msub></mml:mrow><mml:mo>&#x2212;</mml:mo></mml:msubsup></mml:mrow><mml:mrow><mml:mi>t</mml:mi><mml:mi>h</mml:mi></mml:mrow></mml:msub></mml:math></inline-formula>. If the risk value exceeds this threshold, the ZTNE rejects the request and triggers a risk alert, thereby enhancing the security of the DPZTN. For requests that pass the risk assessment, the ACSC checks whether the requested resource level <inline-formula id="ieqn-90"><mml:math id="mml-ieqn-90"><mml:msub><mml:mrow><mml:mi>R</mml:mi><mml:mi>L</mml:mi></mml:mrow><mml:mi>k</mml:mi></mml:msub></mml:math></inline-formula> exceeds the user&#x2019;s allocated authority <inline-formula id="ieqn-91"><mml:math id="mml-ieqn-91"><mml:msub><mml:mi>P</mml:mi><mml:mrow><mml:msub><mml:mi>U</mml:mi><mml:mi>j</mml:mi></mml:msub></mml:mrow></mml:msub></mml:math></inline-formula>. If the requested resource level exceeds the user&#x2019;s authority, the ZTNE immediately rejects the request. In cases where the resource level is below the authority but exceeds the user&#x2019;s access privilege level <inline-formula id="ieqn-92"><mml:math id="mml-ieqn-92"><mml:mi>A</mml:mi><mml:mi>L</mml:mi><mml:mo stretchy="false">(</mml:mo><mml:msub><mml:mi>U</mml:mi><mml:mi>j</mml:mi></mml:msub><mml:mo stretchy="false">)</mml:mo></mml:math></inline-formula>, the blockchain generates an access privilege level alert, permitting access while notifying the DPZTN of a potential anomaly.</p>
</sec>
<sec id="s3_4_2">
<label>3.4.2</label>
<title>User Dynamic Access Privilege Level Adjustment</title>
<p>With the changing behavior of users, the access control system needs to dynamically adjust the access privilege level of users to ensure the safe access of resources. Dynamic adjustment is achieved through a comprehensive evaluation of the user&#x2019;s current and historical behaviors. In this paper, the proposed dynamic adjustment of user&#x2019;s access privilege level and behavior score is achieved by the following formula:
<disp-formula id="eqn-2"><label>(2)</label><mml:math id="mml-eqn-2" display="block"><mml:mrow><mml:mo>{</mml:mo><mml:mtable columnalign="left left" rowspacing=".2em" columnspacing="1em" displaystyle="false"><mml:mtr><mml:mtd><mml:mi>A</mml:mi><mml:msub><mml:mi>L</mml:mi><mml:mrow><mml:mrow><mml:mtext>min</mml:mtext></mml:mrow></mml:mrow></mml:msub><mml:mo>=</mml:mo><mml:mn>10</mml:mn><mml:mo>&#x2217;</mml:mo><mml:msub><mml:mi>P</mml:mi><mml:mrow><mml:msub><mml:mi>U</mml:mi><mml:mi>j</mml:mi></mml:msub></mml:mrow></mml:msub></mml:mtd></mml:mtr><mml:mtr><mml:mtd><mml:mi>A</mml:mi><mml:msub><mml:mi>L</mml:mi><mml:mrow><mml:mrow><mml:mtext>max</mml:mtext></mml:mrow></mml:mrow></mml:msub><mml:mo>=</mml:mo><mml:mn>10</mml:mn><mml:mo>&#x2217;</mml:mo><mml:mo stretchy="false">(</mml:mo><mml:msub><mml:mi>P</mml:mi><mml:mrow><mml:msub><mml:mi>U</mml:mi><mml:mi>j</mml:mi></mml:msub></mml:mrow></mml:msub><mml:mo>+</mml:mo><mml:mn>1</mml:mn><mml:mo stretchy="false">)</mml:mo></mml:mtd></mml:mtr><mml:mtr><mml:mtd><mml:msub><mml:mi mathvariant="normal">&#x0394;</mml:mi><mml:mrow><mml:msub><mml:mi>U</mml:mi><mml:mi>j</mml:mi></mml:msub></mml:mrow></mml:msub><mml:mo>=</mml:mo><mml:mi>A</mml:mi><mml:msubsup><mml:mi>L</mml:mi><mml:mrow><mml:msub><mml:mi>U</mml:mi><mml:mi>j</mml:mi></mml:msub></mml:mrow><mml:mrow><mml:mrow><mml:mtext>hist</mml:mtext></mml:mrow></mml:mrow></mml:msubsup><mml:mo>+</mml:mo><mml:mi>&#x03BB;</mml:mi><mml:mo>&#x2217;</mml:mo><mml:mo stretchy="false">(</mml:mo><mml:mi>A</mml:mi><mml:msub><mml:mi>S</mml:mi><mml:mrow><mml:msub><mml:mi>U</mml:mi><mml:mi>j</mml:mi></mml:msub></mml:mrow></mml:msub><mml:mo>&#x2212;</mml:mo><mml:mi>A</mml:mi><mml:msubsup><mml:mi>S</mml:mi><mml:mrow><mml:msub><mml:mi>U</mml:mi><mml:mi>j</mml:mi></mml:msub></mml:mrow><mml:mrow><mml:mrow><mml:mtext>hist</mml:mtext></mml:mrow></mml:mrow></mml:msubsup><mml:mo stretchy="false">)</mml:mo></mml:mtd></mml:mtr><mml:mtr><mml:mtd><mml:mi>A</mml:mi><mml:msub><mml:mi>L</mml:mi><mml:mrow><mml:msub><mml:mi>U</mml:mi><mml:mi>j</mml:mi></mml:msub></mml:mrow></mml:msub><mml:mo>=</mml:mo><mml:mo movablelimits="true" form="prefix">min</mml:mo><mml:mrow><mml:mo>(</mml:mo><mml:mi>A</mml:mi><mml:msub><mml:mi>L</mml:mi><mml:mrow><mml:mrow><mml:mtext>max</mml:mtext></mml:mrow></mml:mrow></mml:msub><mml:mo>,</mml:mo><mml:mo movablelimits="true" form="prefix">max</mml:mo><mml:mrow><mml:mo>(</mml:mo><mml:mi>A</mml:mi><mml:msub><mml:mi>L</mml:mi><mml:mrow><mml:mrow><mml:mtext>min</mml:mtext></mml:mrow></mml:mrow></mml:msub><mml:mo>,</mml:mo><mml:msub><mml:mi mathvariant="normal">&#x0394;</mml:mi><mml:mrow><mml:msub><mml:mi>U</mml:mi><mml:mi>j</mml:mi></mml:msub></mml:mrow></mml:msub><mml:mo>)</mml:mo></mml:mrow><mml:mo>)</mml:mo></mml:mrow></mml:mtd></mml:mtr></mml:mtable><mml:mo fence="true" stretchy="true" symmetric="true"></mml:mo></mml:mrow></mml:math></disp-formula></p>
<p>For the next time access privilege level assessment of the user, <inline-formula id="ieqn-93"><mml:math id="mml-ieqn-93"><mml:mi>A</mml:mi><mml:mi>L</mml:mi><mml:msub><mml:mrow><mml:mo>(</mml:mo><mml:msub><mml:mi>U</mml:mi><mml:mi>j</mml:mi></mml:msub><mml:mo>)</mml:mo></mml:mrow><mml:mrow><mml:mtext>hist</mml:mtext></mml:mrow></mml:msub><mml:mo>=</mml:mo><mml:mi>A</mml:mi><mml:mi>L</mml:mi><mml:msub><mml:mrow><mml:mo>(</mml:mo><mml:msub><mml:mi>U</mml:mi><mml:mi>j</mml:mi></mml:msub><mml:mo>)</mml:mo></mml:mrow><mml:mrow><mml:mtext>init</mml:mtext></mml:mrow></mml:msub></mml:math></inline-formula>, and <inline-formula id="ieqn-94"><mml:math id="mml-ieqn-94"><mml:mi>A</mml:mi><mml:mi>S</mml:mi><mml:msub><mml:mrow><mml:mo>(</mml:mo><mml:msub><mml:mi>U</mml:mi><mml:mi>j</mml:mi></mml:msub><mml:mo>)</mml:mo></mml:mrow><mml:mrow><mml:mtext>hist</mml:mtext></mml:mrow></mml:msub><mml:mo>=</mml:mo><mml:mi>A</mml:mi><mml:mi>S</mml:mi><mml:msub><mml:mrow><mml:mo>(</mml:mo><mml:msub><mml:mi>U</mml:mi><mml:mi>j</mml:mi></mml:msub><mml:mo>)</mml:mo></mml:mrow><mml:mrow><mml:mtext>init</mml:mtext></mml:mrow></mml:msub></mml:math></inline-formula>. In this formula, the user&#x2019;s access privilege level is always limited by the maximum privileges of the role <inline-formula id="ieqn-95"><mml:math id="mml-ieqn-95"><mml:mi>A</mml:mi><mml:msub><mml:mi>L</mml:mi><mml:mrow><mml:mtext>max</mml:mtext></mml:mrow></mml:msub></mml:math></inline-formula> and the minimum access privilege level set by the system <inline-formula id="ieqn-96"><mml:math id="mml-ieqn-96"><mml:mi>A</mml:mi><mml:msub><mml:mi>L</mml:mi><mml:mrow><mml:mtext>min</mml:mtext></mml:mrow></mml:msub></mml:math></inline-formula>. Additionally, the intermediate variable <inline-formula id="ieqn-97"><mml:math id="mml-ieqn-97"><mml:msub><mml:mi mathvariant="normal">&#x0394;</mml:mi><mml:mrow><mml:msub><mml:mi>U</mml:mi><mml:mi>j</mml:mi></mml:msub></mml:mrow></mml:msub></mml:math></inline-formula> is introduced to represent the adjusted behavior score, which is based on the difference between the current access score and its historical value, weighted by a parameter <inline-formula id="ieqn-98"><mml:math id="mml-ieqn-98"><mml:mi>&#x03BB;</mml:mi></mml:math></inline-formula>.</p>
<p>On this basis, the system introduces a time window for access privilege level changes and a buffer for behavior scores. The system limits the frequency of access privilege level adjustments through a time window mechanism for access privilege level changes. Specifically, the system specifies that a user&#x2019;s access privilege level is allowed to be adjusted only once within a fixed time window at <inline-formula id="ieqn-99"><mml:math id="mml-ieqn-99"><mml:msub><mml:mi>T</mml:mi><mml:mi>w</mml:mi></mml:msub></mml:math></inline-formula>. Regardless of fluctuations in user behavior scores during this time period, changes to the access privilege level are deferred until the end of the window for re-evaluation and adjustment.</p>
<p>The system introduces a buffer interval <inline-formula id="ieqn-100"><mml:math id="mml-ieqn-100"><mml:mi mathvariant="normal">&#x0394;</mml:mi><mml:mi>A</mml:mi><mml:mi>S</mml:mi><mml:mrow><mml:mo>(</mml:mo><mml:msub><mml:mi>U</mml:mi><mml:mi>j</mml:mi></mml:msub><mml:mo>)</mml:mo></mml:mrow></mml:math></inline-formula> for behavior scores <inline-formula id="ieqn-101"><mml:math id="mml-ieqn-101"><mml:mi>A</mml:mi><mml:mi>S</mml:mi><mml:mrow><mml:mo>(</mml:mo><mml:msub><mml:mi>U</mml:mi><mml:mi>j</mml:mi></mml:msub><mml:mo>)</mml:mo></mml:mrow></mml:math></inline-formula>, where changes in scores within a certain range will not directly trigger a grade adjustment. When the behavior score lies near the set upper and lower thresholds, e.g., between <inline-formula id="ieqn-102"><mml:math id="mml-ieqn-102"><mml:mo stretchy="false">[</mml:mo><mml:mi>A</mml:mi><mml:msub><mml:mi>S</mml:mi><mml:mrow><mml:mtext>up</mml:mtext></mml:mrow></mml:msub><mml:mo>&#x2212;</mml:mo><mml:mi mathvariant="normal">&#x0394;</mml:mi><mml:mi>A</mml:mi><mml:mi>S</mml:mi><mml:mrow><mml:mo>(</mml:mo><mml:msub><mml:mi>U</mml:mi><mml:mi>j</mml:mi></mml:msub><mml:mo>)</mml:mo></mml:mrow><mml:mo>,</mml:mo><mml:mi>A</mml:mi><mml:msub><mml:mi>S</mml:mi><mml:mrow><mml:mtext>up</mml:mtext></mml:mrow></mml:msub><mml:mo>+</mml:mo><mml:mi mathvariant="normal">&#x0394;</mml:mi><mml:mi>A</mml:mi><mml:mi>S</mml:mi><mml:mrow><mml:mo>(</mml:mo><mml:msub><mml:mi>U</mml:mi><mml:mi>j</mml:mi></mml:msub><mml:mo>)</mml:mo></mml:mrow><mml:mo stretchy="false">]</mml:mo></mml:math></inline-formula>, the system will not perform an adjustment of the access privilege level.</p>
<p>Algorithm 2 describes the dynamic access privilege level adjustment algorithm, which is realized in BSESC. The smart contract obtains the user&#x2019;s current behavior score <inline-formula id="ieqn-103"><mml:math id="mml-ieqn-103"><mml:mi>A</mml:mi><mml:mi>S</mml:mi><mml:mrow><mml:mo>(</mml:mo><mml:msub><mml:mi>U</mml:mi><mml:mi>j</mml:mi></mml:msub><mml:mo>)</mml:mo></mml:mrow></mml:math></inline-formula> and the number of accesses <inline-formula id="ieqn-104"><mml:math id="mml-ieqn-104"><mml:msub><mml:mi>N</mml:mi><mml:mrow><mml:mtext>Access</mml:mtext></mml:mrow></mml:msub></mml:math></inline-formula> from the blockchain, and if <inline-formula id="ieqn-105"><mml:math id="mml-ieqn-105"><mml:mi>A</mml:mi><mml:mi>S</mml:mi><mml:mrow><mml:mo>(</mml:mo><mml:msub><mml:mi>U</mml:mi><mml:mi>j</mml:mi></mml:msub><mml:mo>)</mml:mo></mml:mrow></mml:math></inline-formula> is lower than the behavior score threshold <inline-formula id="ieqn-106"><mml:math id="mml-ieqn-106"><mml:mi>A</mml:mi><mml:msub><mml:mi>S</mml:mi><mml:mrow><mml:mtext>th</mml:mtext></mml:mrow></mml:msub></mml:math></inline-formula>, the blockchain automatically logs out the user to ensure the timely removal of high-risk users. If the behavior score is higher than the threshold, it is compared with <inline-formula id="ieqn-107"><mml:math id="mml-ieqn-107"><mml:mi>A</mml:mi><mml:mi>L</mml:mi><mml:msub><mml:mrow><mml:mo>(</mml:mo><mml:msub><mml:mi>U</mml:mi><mml:mi>j</mml:mi></mml:msub><mml:mo>)</mml:mo></mml:mrow><mml:mrow><mml:mtext>hist</mml:mtext></mml:mrow></mml:msub></mml:math></inline-formula>. If the score changes beyond the set buffer <inline-formula id="ieqn-108"><mml:math id="mml-ieqn-108"><mml:mi mathvariant="normal">&#x0394;</mml:mi><mml:mi>A</mml:mi><mml:mi>S</mml:mi><mml:mrow><mml:mo>(</mml:mo><mml:msub><mml:mi>U</mml:mi><mml:mi>j</mml:mi></mml:msub><mml:mo>)</mml:mo></mml:mrow></mml:math></inline-formula>, the system adjusts the <inline-formula id="ieqn-109"><mml:math id="mml-ieqn-109"><mml:mi>A</mml:mi><mml:mi>L</mml:mi><mml:mrow><mml:mo>(</mml:mo><mml:msub><mml:mi>U</mml:mi><mml:mi>j</mml:mi></mml:msub><mml:mo>)</mml:mo></mml:mrow></mml:math></inline-formula> based on the difference in behavior scores, so that it floats between <inline-formula id="ieqn-110"><mml:math id="mml-ieqn-110"><mml:mi>A</mml:mi><mml:msub><mml:mi>L</mml:mi><mml:mrow><mml:mtext>max</mml:mtext></mml:mrow></mml:msub></mml:math></inline-formula> and <inline-formula id="ieqn-111"><mml:math id="mml-ieqn-111"><mml:mi>A</mml:mi><mml:msub><mml:mi>L</mml:mi><mml:mrow><mml:mtext>min</mml:mtext></mml:mrow></mml:msub></mml:math></inline-formula>. The adjusted access privilege level <inline-formula id="ieqn-112"><mml:math id="mml-ieqn-112"><mml:mi>A</mml:mi><mml:mi>S</mml:mi><mml:mrow><mml:mo>(</mml:mo><mml:msub><mml:mi>U</mml:mi><mml:mi>j</mml:mi></mml:msub><mml:mo>)</mml:mo></mml:mrow></mml:math></inline-formula> is bounded by the user&#x2019;s role permission boundaries. To prevent frequent adjustments, the system introduces a time window <inline-formula id="ieqn-113"><mml:math id="mml-ieqn-113"><mml:msub><mml:mi>T</mml:mi><mml:mi>w</mml:mi></mml:msub></mml:math></inline-formula> within which only one access privilege level adjustment is allowed. If the number of accesses <inline-formula id="ieqn-114"><mml:math id="mml-ieqn-114"><mml:msub><mml:mi>N</mml:mi><mml:mrow><mml:mtext>Access</mml:mtext></mml:mrow></mml:msub></mml:math></inline-formula> exceeds the preset threshold <inline-formula id="ieqn-115"><mml:math id="mml-ieqn-115"><mml:msub><mml:mi>N</mml:mi><mml:mrow><mml:mtext>Max</mml:mtext></mml:mrow></mml:msub></mml:math></inline-formula>, an alert is generated to remind the system Admin to handle the situation accordingly.</p>
<fig id="fig-12">
<graphic mimetype="image" mime-subtype="tif" xlink:href="CSSE_68151-fig-12.tif"/>
</fig>
<p>The dynamic access privilege level algorithm adjusts the access privilege level based on user behavior scores, combining time windows and buffers. This approach not only ensures that the access privilege level is reasonably adjusted according to user behavior but also avoids frequent changes due to short-term behavior fluctuations or minor score variations.</p>
</sec>
<sec id="s3_4_3">
<label>3.4.3</label>
<title>ZTNE Dynamic Privilege Adjustment</title>
<p>As shown in Algorithm 3, the dynamic privilege adjustment of ZTNE introduces the penalty-recovery mechanism, through which the dynamic management of ZTNE access control is realized.</p>
<p>First, the algorithm initializes the penalty counter <inline-formula id="ieqn-135"><mml:math id="mml-ieqn-135"><mml:msub><mml:mi>C</mml:mi><mml:mi>p</mml:mi></mml:msub></mml:math></inline-formula> and recovery counter <inline-formula id="ieqn-136"><mml:math id="mml-ieqn-136"><mml:msub><mml:mi>C</mml:mi><mml:mi>r</mml:mi></mml:msub></mml:math></inline-formula>, and the warning window <inline-formula id="ieqn-137"><mml:math id="mml-ieqn-137"><mml:mi>Z</mml:mi><mml:msub><mml:mi>T</mml:mi><mml:mi>w</mml:mi></mml:msub></mml:math></inline-formula>. In each cycle, the algorithm checks the ZTNE&#x2019;s reputation value <inline-formula id="ieqn-138"><mml:math id="mml-ieqn-138"><mml:mi>Z</mml:mi><mml:msup><mml:mi>R</mml:mi><mml:mo>+</mml:mo></mml:msup></mml:math></inline-formula> and risk value <inline-formula id="ieqn-139"><mml:math id="mml-ieqn-139"><mml:mi>Z</mml:mi><mml:msup><mml:mi>R</mml:mi><mml:mo>&#x2212;</mml:mo></mml:msup></mml:math></inline-formula> according to the ZTNE&#x2019;s reputation value (the specific reputation <inline-formula id="ieqn-140"><mml:math id="mml-ieqn-140"><mml:mi>Z</mml:mi><mml:msup><mml:mi>R</mml:mi><mml:mo>+</mml:mo></mml:msup></mml:math></inline-formula> and risk <inline-formula id="ieqn-141"><mml:math id="mml-ieqn-141"><mml:mi>Z</mml:mi><mml:msup><mml:mi>R</mml:mi><mml:mo>&#x2212;</mml:mo></mml:msup></mml:math></inline-formula> are introduced in <xref ref-type="sec" rid="s3_6_4">Sections 3.6.4</xref> and <xref ref-type="sec" rid="s3_6_2">3.6.2</xref>), and the penalty counter <inline-formula id="ieqn-142"><mml:math id="mml-ieqn-142"><mml:msub><mml:mi>C</mml:mi><mml:mi>p</mml:mi></mml:msub></mml:math></inline-formula> is increased if <inline-formula id="ieqn-143"><mml:math id="mml-ieqn-143"><mml:mi>Z</mml:mi><mml:msup><mml:mi>R</mml:mi><mml:mo>+</mml:mo></mml:msup></mml:math></inline-formula> is lower than the threshold <inline-formula id="ieqn-144"><mml:math id="mml-ieqn-144"><mml:mi>Z</mml:mi><mml:msubsup><mml:mi>R</mml:mi><mml:mrow><mml:mi>t</mml:mi><mml:mi>h</mml:mi></mml:mrow><mml:mo>+</mml:mo></mml:msubsup></mml:math></inline-formula> or <inline-formula id="ieqn-145"><mml:math id="mml-ieqn-145"><mml:mi>Z</mml:mi><mml:msup><mml:mi>R</mml:mi><mml:mo>&#x2212;</mml:mo></mml:msup></mml:math></inline-formula> is higher than the threshold <inline-formula id="ieqn-146"><mml:math id="mml-ieqn-146"><mml:mi>Z</mml:mi><mml:msubsup><mml:mi>R</mml:mi><mml:mrow><mml:mi>t</mml:mi><mml:mi>h</mml:mi></mml:mrow><mml:mo>&#x2212;</mml:mo></mml:msubsup></mml:math></inline-formula>; otherwise, the recovery counter <inline-formula id="ieqn-147"><mml:math id="mml-ieqn-147"><mml:msub><mml:mi>C</mml:mi><mml:mi>r</mml:mi></mml:msub></mml:math></inline-formula> is increased.</p>
<p>Subsequently, the algorithm checks the penalty and recovery conditions: if <inline-formula id="ieqn-148"><mml:math id="mml-ieqn-148"><mml:msub><mml:mi>C</mml:mi><mml:mi>p</mml:mi></mml:msub></mml:math></inline-formula> exceeds the set maximum value <inline-formula id="ieqn-149"><mml:math id="mml-ieqn-149"><mml:msub><mml:mi>C</mml:mi><mml:mrow><mml:msub><mml:mi>p</mml:mi><mml:mrow><mml:mtext>max</mml:mtext></mml:mrow></mml:msub></mml:mrow></mml:msub></mml:math></inline-formula> and the recovery counter <inline-formula id="ieqn-150"><mml:math id="mml-ieqn-150"><mml:msub><mml:mi>C</mml:mi><mml:mi>r</mml:mi></mml:msub></mml:math></inline-formula> is smaller than the recovery threshold <inline-formula id="ieqn-151"><mml:math id="mml-ieqn-151"><mml:msub><mml:mi>C</mml:mi><mml:mrow><mml:msub><mml:mi>r</mml:mi><mml:mrow><mml:mtext>th</mml:mtext></mml:mrow></mml:msub></mml:mrow></mml:msub></mml:math></inline-formula>, the ZTNE information is removed from the blockchain to ensure the security of the DPZTN. If <inline-formula id="ieqn-152"><mml:math id="mml-ieqn-152"><mml:msub><mml:mi>C</mml:mi><mml:mi>r</mml:mi></mml:msub></mml:math></inline-formula> reaches the <inline-formula id="ieqn-153"><mml:math id="mml-ieqn-153"><mml:msub><mml:mi>C</mml:mi><mml:mrow><mml:msub><mml:mi>r</mml:mi><mml:mrow><mml:mtext>th</mml:mtext></mml:mrow></mml:msub></mml:mrow></mml:msub></mml:math></inline-formula>, the counter is reset and ZTNE is restored to minimize accidental deletion and enhance the flexibility and robustness of the DPZTN. If none of the above conditions are satisfied, the blockchain continues to log the ZTNE behavior.</p>
<fig id="fig-13">
<graphic mimetype="image" mime-subtype="tif" xlink:href="CSSE_68151-fig-13.tif"/>
</fig>
<p>By monitoring ZTNE&#x2019;s reputation value <inline-formula id="ieqn-167"><mml:math id="mml-ieqn-167"><mml:mi>Z</mml:mi><mml:msup><mml:mi>R</mml:mi><mml:mo>+</mml:mo></mml:msup></mml:math></inline-formula> and risk value <inline-formula id="ieqn-168"><mml:math id="mml-ieqn-168"><mml:mi>Z</mml:mi><mml:msup><mml:mi>R</mml:mi><mml:mo>&#x2212;</mml:mo></mml:msup></mml:math></inline-formula>, which are dynamically adjusted according to the ZTNE&#x2019;s behavior, excessive punishment due to one-time fluctuation or short-term abnormality is avoided. Meanwhile, the dual mechanism of penalty counting and recovery counting ensures timely deletion operations to safeguard system security when ZTNE&#x2019;s performance continues to deteriorate. The introduction of the recovery window period and counters provides ZTNE with an opportunity to resume normal operation when its performance improves.</p>
</sec>
</sec>
<sec id="s3_5">
<label>3.5</label>
<title>ZTNE Data Plane</title>
<p>The successful enforcement of behavior-based access control policies depends on the real-time processing capabilities of the data plane. In this context, programmable switches play a pivotal role. This section outlines how ZTNEs utilize the data plane for policy enforcement and threat detection.</p>
<sec id="s3_5_1">
<label>3.5.1</label>
<title>ZTNE Handles User Requests</title>
<p>When the user authentication or access control fails, the blockchain generates the corresponding message and sends it to the programmable switch controller. Algorithm 4 shows the pseudo-code for ZTNE user request processing.</p>
<fig id="fig-14">
<graphic mimetype="image" mime-subtype="tif" xlink:href="CSSE_68151-fig-14.tif"/>
</fig>
<p>The P4Runtime initializes an empty <inline-formula id="ieqn-172"><mml:math id="mml-ieqn-172"><mml:mi>d</mml:mi><mml:mi>r</mml:mi><mml:mi>o</mml:mi><mml:mi>p</mml:mi><mml:mi mathvariant="normal">&#x005F;</mml:mi><mml:mi>t</mml:mi><mml:mi>a</mml:mi><mml:mi>b</mml:mi><mml:mi>l</mml:mi><mml:mi>e</mml:mi></mml:math></inline-formula> to store user data to be dropped. It iterates through each user&#x2019;s blockchain information and adds <inline-formula id="ieqn-173"><mml:math id="mml-ieqn-173"><mml:mi>U</mml:mi><mml:mi>I</mml:mi><mml:msub><mml:mi>D</mml:mi><mml:mi>j</mml:mi></mml:msub></mml:math></inline-formula> and <inline-formula id="ieqn-174"><mml:math id="mml-ieqn-174"><mml:mi>p</mml:mi><mml:mi>o</mml:mi><mml:mi>r</mml:mi><mml:msub><mml:mi>t</mml:mi><mml:mi>j</mml:mi></mml:msub></mml:math></inline-formula> to the <inline-formula id="ieqn-175"><mml:math id="mml-ieqn-175"><mml:mi>d</mml:mi><mml:mi>r</mml:mi><mml:mi>o</mml:mi><mml:mi>p</mml:mi><mml:mi mathvariant="normal">&#x005F;</mml:mi><mml:mi>t</mml:mi><mml:mi>a</mml:mi><mml:mi>b</mml:mi><mml:mi>l</mml:mi><mml:mi>e</mml:mi></mml:math></inline-formula> if it shows &#x201C;Wrong password&#x201D;, &#x201C;Authentication failed&#x201D;, or &#x201C;Behavior score too low&#x201D;. In the data plane, the <inline-formula id="ieqn-176"><mml:math id="mml-ieqn-176"><mml:mi>d</mml:mi><mml:mi>r</mml:mi><mml:mi>o</mml:mi><mml:mi>p</mml:mi><mml:mi mathvariant="normal">&#x005F;</mml:mi><mml:mi>t</mml:mi><mml:mi>a</mml:mi><mml:mi>b</mml:mi><mml:mi>l</mml:mi><mml:mi>e</mml:mi></mml:math></inline-formula> is used to determine whether to drop a packet based on the source port. If a match is found, the drop action is triggered. After each authentication or access control termination, ZTNE will report the user&#x2019;s behavior and behavior scores to the blockchain to ensure data transparency and non-tampering, and provide a basis for subsequent analysis and permission adjustment.</p>
</sec>
<sec id="s3_5_2">
<label>3.5.2</label>
<title>ZTNE Monitors User Traffic</title>
<p>The pseudo-code for the decision tree algorithm is presented in Algorithm 5. In the data plane, the ZTNE performs high-speed packet processing to extract <inline-formula id="ieqn-177"><mml:math id="mml-ieqn-177"><mml:msub><mml:mrow><mml:mi>f</mml:mi><mml:mi>e</mml:mi><mml:mi>a</mml:mi><mml:mi>t</mml:mi><mml:mi>u</mml:mi><mml:mi>r</mml:mi><mml:mi>e</mml:mi></mml:mrow><mml:mi>i</mml:mi></mml:msub></mml:math></inline-formula> from packets in real time. The control plane is responsible for managing the decision tree&#x2019;s thresholds and classification rules, dynamically adjusting them based on network changes and emerging attack patterns. Once updated, these rules are sent to the data plane. The data plane then classifies traffic in real time according to the updated rules and marks the processing status accordingly. A detailed description of this process can be found in my previous work [<xref ref-type="bibr" rid="ref-23">23</xref>].</p>
<fig id="fig-15">
<graphic mimetype="image" mime-subtype="tif" xlink:href="CSSE_68151-fig-15.tif"/>
</fig>
<p>ZTNE utilizes the decision tree algorithm to predict attacks on each packet, enabling precise traffic classification through detailed feature extraction and hierarchical filtering. The decision tree rapidly generates hard labels, allowing malicious traffic to be redirected to alternative ports. Upon detecting malicious traffic, the system sets the <italic>MTP</italic> to 1 and reports this information to the blockchain for subsequent user behavior score adjustment. After completing the prediction process, the switch transmits the <italic>MTP</italic> of each packet to the blockchain via the control plane, providing essential data for future privilege adjustments and behavior analysis. This collaborative mechanism ensures that ZTNE can effectively mitigate network attacks, thereby enhancing the overall security of the network.</p>
</sec>
<sec id="s3_5_3">
<label>3.5.3</label>
<title>An Example of DPZTN Traffic Processing</title>
<p>In the proposed DPZTN (Data Plane Zero Trust Network) framework, the data plane processes incoming packets through a series of match-action tables, which are dynamically coordinated by a centralized control plane. The detailed mechanism is illustrated through the following packet processing example as <xref ref-type="fig" rid="fig-4">Fig. 4</xref> shown.</p>
<fig id="fig-4">
<label>Figure 4</label>
<caption>
<title>An example of DPZTN traffic processing</title>
</caption>
<graphic mimetype="image" mime-subtype="tif" xlink:href="CSSE_68151-fig-4.tif"/>
</fig>
<p>When a data packet arrives at the switch, its header fields are first extracted by the parser. Suppose the packet has the following characteristics: the source IPv4 address is <monospace>192.168.1.100</monospace>, the source TCP port is <monospace>2000</monospace>, the destination IP address is <monospace>10.0.0.20</monospace>, the destination port is <monospace>8080</monospace>, the protocol is TCP, and the total packet length is <monospace>600 bytes</monospace>.</p>
<p>The packet first enters the <monospace>drop_table</monospace>, which checks whether the user is blacklisted by performing an exact match on the source IP address and source port. If a match is found, the <monospace>drop</monospace> action is executed and the packet is immediately discarded. Otherwise, the packet proceeds to the next phase.</p>
<p>Next, the packet is processed by the <monospace>user_privilege</monospace> table, which verifies whether the user has permission to access the specified destination IP and port. If the match indicates that the user&#x2019;s access is authorized, the packet is forwarded normally. If not, the switch triggers a <monospace>send_digest</monospace> operation to report the access attempt to the control plane. The controller then evaluates whether the access request violates the user&#x2019;s assigned privilege level and dynamically adjusts the user&#x2019;s permission if necessary.</p>
<p>After that, the packet enters the <monospace>malicious_detection</monospace> table, which performs multi-field matching based on protocol type, destination port, packet length range, and other features. If the combination of these features matches a known malicious behavior pattern, the switch again triggers a <monospace>send_digest</monospace> operation, sending a digest message to the control plane that includes the source address and behavior-related metadata. Upon receiving the digest, the control plane queries the blockchain to assess the user&#x2019;s trust status and may blacklist the user by updating the corresponding tables.</p>
<p>The control plane handles these digest messages by querying or updating the blockchain records and uses the P4Runtime interface to dynamically issue control commands to the data plane. For example, the controller can add the user and its port to the <monospace>drop_table</monospace> to enforce blocking, or update the <monospace>user_privilege</monospace> table to adjust the access level accordingly.</p>
</sec>
</sec>
<sec id="s3_6">
<label>3.6</label>
<title>Bayesian-Based Behavior Evaluation Algorithm Assessment</title>
<p>To support fine-grained and adaptive access control, a robust behavior evaluation mechanism is essential. We thus propose a BBEA, which quantifies user credibility and risk based on real-time observations. BBEA for user behavior evaluation through the joint use of ZRESC, ZRASC, RESC, RASC, and BSESC. The parameters used in BBEA are listed in <xref ref-type="table" rid="table-6">Table 6</xref>.</p>
<table-wrap id="table-6">
<label>Table 6</label>
<caption>
<title>User behavior assessment parameters and their descriptions</title>
</caption>
<table>
<colgroup>
<col/>
<col/>
<col/>
<col/>
</colgroup>
<thead>
<tr>
<th>Parameter</th>
<th>Description</th>
<th>Parameter</th>
<th>Description</th>
</tr>
</thead>
<tbody>
<tr>
<td>ASF</td>
<td>Authentication success frequency</td>
<td>AC</td>
<td>Authentication count</td>
</tr>
<tr>
<td>ACSF</td>
<td>Access control success frequency</td>
<td>ACC</td>
<td>Access control count</td>
</tr>
<tr>
<td>CAPL</td>
<td>Current allowed privilege level</td>
<td>CARL</td>
<td>Current access resource level</td>
</tr>
<tr>
<td>LAC</td>
<td>Legal access count</td>
<td>SACF</td>
<td>Sensitive access frequency</td>
</tr>
<tr>
<td>ACF</td>
<td>Access control frequency</td>
<td>MTP</td>
<td>Malicious traffic probability</td>
</tr>
<tr>
<td>ZASF</td>
<td>ZTNE authentication success frequency</td>
<td>ZAC</td>
<td>ZTNE authentication count</td>
</tr>
<tr>
<td>ZACSF</td>
<td>ZTNE access control success frequency</td>
<td>ZACC</td>
<td>ZTNE access control count</td>
</tr>
<tr>
<td>HRV</td>
<td>Historical reputation value</td>
<td>HRR</td>
<td>Historical risk rate</td>
</tr>
</tbody>
</table>
</table-wrap>
<sec id="s3_6_1">
<label>3.6.1</label>
<title>ZTNE Reputation Value</title>
<p>We implement the computation of the ZTNE reputation value using the ZRESC deployed on the blockchain. The reputation value <inline-formula id="ieqn-192"><mml:math id="mml-ieqn-192"><mml:mi>Z</mml:mi><mml:msup><mml:mi>R</mml:mi><mml:mo>+</mml:mo></mml:msup></mml:math></inline-formula> is calculated as a weighted average of the individual user reputation scores <inline-formula id="ieqn-193"><mml:math id="mml-ieqn-193"><mml:msubsup><mml:mi>R</mml:mi><mml:mrow><mml:msub><mml:mi>U</mml:mi><mml:mi>j</mml:mi></mml:msub></mml:mrow><mml:mo>+</mml:mo></mml:msubsup></mml:math></inline-formula> according to the following equation:
<disp-formula id="eqn-3"><label>(3)</label><mml:math id="mml-eqn-3" display="block"><mml:mi>Z</mml:mi><mml:msup><mml:mi>R</mml:mi><mml:mo>+</mml:mo></mml:msup><mml:mo>=</mml:mo><mml:munderover><mml:mo movablelimits="false">&#x2211;</mml:mo><mml:mrow><mml:mi>j</mml:mi><mml:mo>=</mml:mo><mml:mn>1</mml:mn></mml:mrow><mml:mrow><mml:mi>n</mml:mi></mml:mrow></mml:munderover><mml:msub><mml:mi>&#x03BE;</mml:mi><mml:mi>j</mml:mi></mml:msub><mml:mo>&#x2217;</mml:mo><mml:msubsup><mml:mi>R</mml:mi><mml:mrow><mml:msub><mml:mi>U</mml:mi><mml:mi>j</mml:mi></mml:msub></mml:mrow><mml:mo>+</mml:mo></mml:msubsup><mml:mspace width="1em" /></mml:math></disp-formula>where <inline-formula id="ieqn-194"><mml:math id="mml-ieqn-194"><mml:msubsup><mml:mi>R</mml:mi><mml:mrow><mml:msub><mml:mi>U</mml:mi><mml:mi>j</mml:mi></mml:msub></mml:mrow><mml:mo>+</mml:mo></mml:msubsup></mml:math></inline-formula> is the reputation value of <inline-formula id="ieqn-195"><mml:math id="mml-ieqn-195"><mml:msub><mml:mi>U</mml:mi><mml:mi>j</mml:mi></mml:msub></mml:math></inline-formula>, <inline-formula id="ieqn-196"><mml:math id="mml-ieqn-196"><mml:mi>n</mml:mi></mml:math></inline-formula> is the number of users connected to the ZTNE, and <inline-formula id="ieqn-197"><mml:math id="mml-ieqn-197"><mml:msub><mml:mi>&#x03BE;</mml:mi><mml:mi>j</mml:mi></mml:msub></mml:math></inline-formula> is the weight of the impact of <inline-formula id="ieqn-198"><mml:math id="mml-ieqn-198"><mml:msub><mml:mi>U</mml:mi><mml:mi>j</mml:mi></mml:msub></mml:math></inline-formula> on the reputation of the ZTNE. The formula for calculating the weight <inline-formula id="ieqn-199"><mml:math id="mml-ieqn-199"><mml:msub><mml:mi>&#x03BE;</mml:mi><mml:mi>j</mml:mi></mml:msub></mml:math></inline-formula> is as follows:
<disp-formula id="eqn-4"><label>(4)</label><mml:math id="mml-eqn-4" display="block"><mml:msub><mml:mi>&#x03BE;</mml:mi><mml:mi>j</mml:mi></mml:msub><mml:mo>=</mml:mo><mml:mfrac><mml:mrow><mml:mi>A</mml:mi><mml:mi>C</mml:mi><mml:msub><mml:mi>F</mml:mi><mml:mi>j</mml:mi></mml:msub><mml:mo>&#x2217;</mml:mo><mml:msubsup><mml:mi>R</mml:mi><mml:mrow><mml:msub><mml:mi>U</mml:mi><mml:mi>j</mml:mi></mml:msub></mml:mrow><mml:mo>+</mml:mo></mml:msubsup></mml:mrow><mml:mrow><mml:munderover><mml:mo>&#x2211;</mml:mo><mml:mrow><mml:mi>j</mml:mi><mml:mo>=</mml:mo><mml:mn>1</mml:mn></mml:mrow><mml:mrow><mml:mi>n</mml:mi></mml:mrow></mml:munderover><mml:mi>A</mml:mi><mml:mi>C</mml:mi><mml:msub><mml:mi>F</mml:mi><mml:mi>j</mml:mi></mml:msub><mml:mo>&#x2217;</mml:mo><mml:msubsup><mml:mi>R</mml:mi><mml:mrow><mml:msub><mml:mi>U</mml:mi><mml:mi>j</mml:mi></mml:msub></mml:mrow><mml:mo>+</mml:mo></mml:msubsup></mml:mrow></mml:mfrac><mml:mspace width="1em" /></mml:math></disp-formula></p>
<p><inline-formula id="ieqn-200"><mml:math id="mml-ieqn-200"><mml:mi>A</mml:mi><mml:mi>C</mml:mi><mml:msub><mml:mi>F</mml:mi><mml:mi>j</mml:mi></mml:msub></mml:math></inline-formula> denotes the access control frequency of <inline-formula id="ieqn-201"><mml:math id="mml-ieqn-201"><mml:msub><mml:mi>U</mml:mi><mml:mi>j</mml:mi></mml:msub></mml:math></inline-formula>, which reflects the frequency of the user&#x2019;s access behavior in ZTNE. <xref ref-type="disp-formula" rid="eqn-4">Eq. (4)</xref> dynamically adjusts the weights through the user&#x2019;s access frequency <inline-formula id="ieqn-202"><mml:math id="mml-ieqn-202"><mml:mi>A</mml:mi><mml:mi>C</mml:mi><mml:msub><mml:mi>F</mml:mi><mml:mi>j</mml:mi></mml:msub></mml:math></inline-formula> and <inline-formula id="ieqn-203"><mml:math id="mml-ieqn-203"><mml:msubsup><mml:mi>R</mml:mi><mml:mrow><mml:msub><mml:mi>U</mml:mi><mml:mi>j</mml:mi></mml:msub></mml:mrow><mml:mo>+</mml:mo></mml:msubsup></mml:math></inline-formula> to ensure that users with high access frequency and better reputation contribute more to the ZTNE reputation, thus dynamically reflecting the user&#x2019;s positive contribution to ZTNE. Since <inline-formula id="ieqn-204"><mml:math id="mml-ieqn-204"><mml:msub><mml:mi>&#x03BE;</mml:mi><mml:mi>j</mml:mi></mml:msub></mml:math></inline-formula> changes with users&#x2019; visit frequency and reputation, <inline-formula id="ieqn-205"><mml:math id="mml-ieqn-205"><mml:mi>Z</mml:mi><mml:msup><mml:mi>R</mml:mi><mml:mo>+</mml:mo></mml:msup></mml:math></inline-formula> can flexibly adapt to changes in user behavior, improving the robustness of the assessment.</p>
</sec>
<sec id="s3_6_2">
<label>3.6.2</label>
<title>ZTNE Risk Value</title>
<p>We have implemented the calculation of ZTNE risk value by applying ZRASC in the blockchain, and the ZTNE risk value <inline-formula id="ieqn-206"><mml:math id="mml-ieqn-206"><mml:mi>Z</mml:mi><mml:msubsup><mml:mi>R</mml:mi><mml:mrow><mml:msub><mml:mi>U</mml:mi><mml:mi>j</mml:mi></mml:msub></mml:mrow><mml:mo>&#x2212;</mml:mo></mml:msubsup></mml:math></inline-formula> is calculated according to the weighted average of the user&#x2019;s risk value <inline-formula id="ieqn-207"><mml:math id="mml-ieqn-207"><mml:msubsup><mml:mi>R</mml:mi><mml:mrow><mml:msub><mml:mi>U</mml:mi><mml:mi>j</mml:mi></mml:msub></mml:mrow><mml:mo>&#x2212;</mml:mo></mml:msubsup></mml:math></inline-formula> with the following formula:
<disp-formula id="eqn-5"><label>(5)</label><mml:math id="mml-eqn-5" display="block"><mml:mi>Z</mml:mi><mml:msubsup><mml:mi>R</mml:mi><mml:mrow><mml:msub><mml:mi>U</mml:mi><mml:mi>j</mml:mi></mml:msub></mml:mrow><mml:mo>&#x2212;</mml:mo></mml:msubsup><mml:mo>=</mml:mo><mml:mfrac><mml:mrow><mml:munderover><mml:mo>&#x2211;</mml:mo><mml:mrow><mml:mi>j</mml:mi><mml:mo>=</mml:mo><mml:mn>1</mml:mn></mml:mrow><mml:mrow><mml:mi>n</mml:mi></mml:mrow></mml:munderover><mml:msub><mml:mi>&#x03B7;</mml:mi><mml:mi>j</mml:mi></mml:msub><mml:mo>&#x2217;</mml:mo><mml:msubsup><mml:mi>R</mml:mi><mml:mrow><mml:msub><mml:mi>U</mml:mi><mml:mi>j</mml:mi></mml:msub></mml:mrow><mml:mo>&#x2212;</mml:mo></mml:msubsup></mml:mrow><mml:mrow><mml:munderover><mml:mo>&#x2211;</mml:mo><mml:mrow><mml:mi>j</mml:mi><mml:mo>=</mml:mo><mml:mn>1</mml:mn></mml:mrow><mml:mrow><mml:mi>n</mml:mi></mml:mrow></mml:munderover><mml:msub><mml:mi>&#x03B7;</mml:mi><mml:mi>j</mml:mi></mml:msub></mml:mrow></mml:mfrac></mml:math></disp-formula>where <inline-formula id="ieqn-208"><mml:math id="mml-ieqn-208"><mml:msubsup><mml:mi>R</mml:mi><mml:mrow><mml:msub><mml:mi>U</mml:mi><mml:mi>j</mml:mi></mml:msub></mml:mrow><mml:mo>&#x2212;</mml:mo></mml:msubsup></mml:math></inline-formula> is the risk value of <inline-formula id="ieqn-209"><mml:math id="mml-ieqn-209"><mml:msub><mml:mi>U</mml:mi><mml:mi>j</mml:mi></mml:msub></mml:math></inline-formula> and <inline-formula id="ieqn-210"><mml:math id="mml-ieqn-210"><mml:msub><mml:mi>&#x03B7;</mml:mi><mml:mi>j</mml:mi></mml:msub></mml:math></inline-formula> is the impact weight of the user <inline-formula id="ieqn-211"><mml:math id="mml-ieqn-211"><mml:msub><mml:mi>U</mml:mi><mml:mi>j</mml:mi></mml:msub></mml:math></inline-formula> on the risk of the ZTNE. The formula for calculating the weight <inline-formula id="ieqn-212"><mml:math id="mml-ieqn-212"><mml:msub><mml:mi>&#x03B7;</mml:mi><mml:mi>j</mml:mi></mml:msub></mml:math></inline-formula> is as follows:
<disp-formula id="eqn-6"><label>(6)</label><mml:math id="mml-eqn-6" display="block"><mml:msub><mml:mi>&#x03B7;</mml:mi><mml:mi>j</mml:mi></mml:msub><mml:mo>=</mml:mo><mml:mfrac><mml:mrow><mml:mi>A</mml:mi><mml:mi>C</mml:mi><mml:msub><mml:mi>F</mml:mi><mml:mi>j</mml:mi></mml:msub><mml:mo>&#x2217;</mml:mo><mml:msubsup><mml:mi>R</mml:mi><mml:mrow><mml:msub><mml:mi>U</mml:mi><mml:mi>j</mml:mi></mml:msub></mml:mrow><mml:mo>&#x2212;</mml:mo></mml:msubsup></mml:mrow><mml:mrow><mml:munderover><mml:mo>&#x2211;</mml:mo><mml:mrow><mml:mi>j</mml:mi><mml:mo>=</mml:mo><mml:mn>1</mml:mn></mml:mrow><mml:mrow><mml:mi>n</mml:mi></mml:mrow></mml:munderover><mml:mi>A</mml:mi><mml:mi>C</mml:mi><mml:msub><mml:mi>F</mml:mi><mml:mi>j</mml:mi></mml:msub><mml:mo>&#x2217;</mml:mo><mml:msubsup><mml:mi>R</mml:mi><mml:mrow><mml:msub><mml:mi>U</mml:mi><mml:mi>j</mml:mi></mml:msub></mml:mrow><mml:mo>&#x2212;</mml:mo></mml:msubsup></mml:mrow></mml:mfrac><mml:mspace width="1em" /></mml:math></disp-formula></p>
<p><inline-formula id="ieqn-213"><mml:math id="mml-ieqn-213"><mml:mi>A</mml:mi><mml:mi>C</mml:mi><mml:msub><mml:mi>F</mml:mi><mml:mi>j</mml:mi></mml:msub></mml:math></inline-formula> denotes the access control frequency of <inline-formula id="ieqn-214"><mml:math id="mml-ieqn-214"><mml:msub><mml:mi>U</mml:mi><mml:mi>j</mml:mi></mml:msub></mml:math></inline-formula>, which reflects the frequency of the user&#x2019;s access behavior in ZTNE. Through <xref ref-type="disp-formula" rid="eqn-6">Eq. (6)</xref>, the system is able to highlight those users with frequent access and higher risk values. The weight <inline-formula id="ieqn-215"><mml:math id="mml-ieqn-215"><mml:msub><mml:mi>&#x03B7;</mml:mi><mml:mi>j</mml:mi></mml:msub></mml:math></inline-formula> dynamically reflects the changes in users&#x2019; behavior and risk values. Users with high access frequency and high risk occupy greater weight in the overall risk assessment, and the system is able to prioritize these users, improving the identification and prevention of potential security threats.</p>
</sec>
<sec id="s3_6_3">
<label>3.6.3</label>
<title>Users Reputation Value and Risk Value</title>
<p>In this paper, we adopt a Bayesian algorithm to dynamically update the user&#x2019;s reputation and risk values. Specifically, the reputation value is derived from both prior and posterior probability distributions. The prior probabilities for reputation and risk are defined in <xref ref-type="disp-formula" rid="eqn-7">Eqs. (7)</xref> and <xref ref-type="disp-formula" rid="eqn-8">(8)</xref>, respectively.
<disp-formula id="eqn-7"><label>(7)</label><mml:math id="mml-eqn-7" display="block"><mml:mi>P</mml:mi><mml:mo stretchy="false">(</mml:mo><mml:msubsup><mml:mi>&#x03B8;</mml:mi><mml:mi>i</mml:mi><mml:mo>+</mml:mo></mml:msubsup><mml:mo stretchy="false">)</mml:mo><mml:mo>=</mml:mo><mml:mrow><mml:mo>{</mml:mo><mml:mtable columnalign="left left" rowspacing=".2em" columnspacing="1em" displaystyle="false"><mml:mtr><mml:mtd><mml:mi>Z</mml:mi><mml:mi>R</mml:mi><mml:mi>V</mml:mi><mml:mo>,</mml:mo></mml:mtd><mml:mtd><mml:mi>i</mml:mi><mml:mo>=</mml:mo><mml:mn>0</mml:mn></mml:mtd></mml:mtr><mml:mtr><mml:mtd><mml:mi>H</mml:mi><mml:mi>R</mml:mi><mml:mi>V</mml:mi><mml:mo>,</mml:mo></mml:mtd><mml:mtd><mml:mi>i</mml:mi><mml:mo>&#x2208;</mml:mo><mml:mo stretchy="false">[</mml:mo><mml:mn>1</mml:mn><mml:mo>,</mml:mo><mml:mo>+</mml:mo><mml:mi mathvariant="normal">&#x221E;</mml:mi><mml:mo stretchy="false">]</mml:mo></mml:mtd></mml:mtr></mml:mtable><mml:mo fence="true" stretchy="true" symmetric="true"></mml:mo></mml:mrow></mml:math></disp-formula>
<disp-formula id="eqn-8"><label>(8)</label><mml:math id="mml-eqn-8" display="block"><mml:mi>P</mml:mi><mml:mo stretchy="false">(</mml:mo><mml:msubsup><mml:mi>&#x03B8;</mml:mi><mml:mi>i</mml:mi><mml:mo>&#x2212;</mml:mo></mml:msubsup><mml:mo stretchy="false">)</mml:mo><mml:mo>=</mml:mo><mml:mrow><mml:mo>{</mml:mo><mml:mtable columnalign="left left" rowspacing=".2em" columnspacing="1em" displaystyle="false"><mml:mtr><mml:mtd><mml:mi>Z</mml:mi><mml:mi>R</mml:mi><mml:mi>R</mml:mi><mml:mo>,</mml:mo></mml:mtd><mml:mtd><mml:mi>i</mml:mi><mml:mo>=</mml:mo><mml:mn>0</mml:mn></mml:mtd></mml:mtr><mml:mtr><mml:mtd><mml:mi>H</mml:mi><mml:mi>R</mml:mi><mml:mi>R</mml:mi><mml:mo>,</mml:mo></mml:mtd><mml:mtd><mml:mi>i</mml:mi><mml:mo>&#x2208;</mml:mo><mml:mo stretchy="false">[</mml:mo><mml:mn>1</mml:mn><mml:mo>,</mml:mo><mml:mo>+</mml:mo><mml:mi mathvariant="normal">&#x221E;</mml:mi><mml:mo stretchy="false">]</mml:mo></mml:mtd></mml:mtr></mml:mtable><mml:mo fence="true" stretchy="true" symmetric="true"></mml:mo></mml:mrow></mml:math></disp-formula></p>
<p><inline-formula id="ieqn-216"><mml:math id="mml-ieqn-216"><mml:msubsup><mml:mi>&#x03B8;</mml:mi><mml:mi>i</mml:mi><mml:mo>+</mml:mo></mml:msubsup></mml:math></inline-formula> indicates the user&#x2019;s current reputation status, which is used to indicate positive performance in the system. <inline-formula id="ieqn-217"><mml:math id="mml-ieqn-217"><mml:msubsup><mml:mi>&#x03B8;</mml:mi><mml:mi>i</mml:mi><mml:mo>&#x2212;</mml:mo></mml:msubsup></mml:math></inline-formula> indicates the current risk status of the user. It is used to describe potential security threats of the user.</p>
<p>The <inline-formula id="ieqn-218"><mml:math id="mml-ieqn-218"><mml:msubsup><mml:mi>R</mml:mi><mml:mrow><mml:msub><mml:mi>U</mml:mi><mml:mi>j</mml:mi></mml:msub></mml:mrow><mml:mo>+</mml:mo></mml:msubsup></mml:math></inline-formula> of the user&#x2019;s current behavior is calculated by considering the following factors in RESC:
<list list-type="bullet">
<list-item>
<p><bold>User relative authentication success rate <inline-formula id="ieqn-219"><mml:math id="mml-ieqn-219"><mml:msub><mml:mi>P</mml:mi><mml:mrow><mml:mi>A</mml:mi><mml:mi>S</mml:mi></mml:mrow></mml:msub></mml:math></inline-formula>:</bold> This is the product of the user authentication success rate and the authentication success rate of users authenticated through the ZTNE:
<disp-formula id="eqn-9"><label>(9)</label><mml:math id="mml-eqn-9" display="block"><mml:msub><mml:mi>P</mml:mi><mml:mrow><mml:mi>A</mml:mi><mml:mi>S</mml:mi></mml:mrow></mml:msub><mml:mo>=</mml:mo><mml:mrow><mml:mo>(</mml:mo><mml:mfrac><mml:mrow><mml:mi>A</mml:mi><mml:mi>S</mml:mi><mml:mi>F</mml:mi></mml:mrow><mml:mrow><mml:mi>A</mml:mi><mml:mi>C</mml:mi></mml:mrow></mml:mfrac><mml:mo>)</mml:mo></mml:mrow><mml:mo>&#x2217;</mml:mo><mml:mrow><mml:mo>(</mml:mo><mml:mfrac><mml:mrow><mml:mi>Z</mml:mi><mml:mi>A</mml:mi><mml:mi>S</mml:mi><mml:mi>F</mml:mi></mml:mrow><mml:mrow><mml:mi>Z</mml:mi><mml:mi>A</mml:mi><mml:mi>C</mml:mi></mml:mrow></mml:mfrac><mml:mo>)</mml:mo></mml:mrow></mml:math></disp-formula></p>
</list-item>
<list-item>
<p><bold>User relative access control success rate <inline-formula id="ieqn-220"><mml:math id="mml-ieqn-220"><mml:msub><mml:mi>P</mml:mi><mml:mrow><mml:mi>A</mml:mi><mml:mi>C</mml:mi><mml:mi>S</mml:mi></mml:mrow></mml:msub></mml:math></inline-formula>:</bold> This is the product of the user access control success rate and the access control success rate of the users access controlled through the user&#x2019;s ZTNE:
<disp-formula id="eqn-10"><label>(10)</label><mml:math id="mml-eqn-10" display="block"><mml:msub><mml:mi>P</mml:mi><mml:mrow><mml:mi>A</mml:mi><mml:mi>C</mml:mi><mml:mi>S</mml:mi></mml:mrow></mml:msub><mml:mo>=</mml:mo><mml:mrow><mml:mo>(</mml:mo><mml:mfrac><mml:mrow><mml:mi>A</mml:mi><mml:mi>C</mml:mi><mml:mi>S</mml:mi><mml:mi>F</mml:mi></mml:mrow><mml:mrow><mml:mi>A</mml:mi><mml:mi>C</mml:mi><mml:mi>C</mml:mi></mml:mrow></mml:mfrac><mml:mo>)</mml:mo></mml:mrow><mml:mo>&#x2217;</mml:mo><mml:mrow><mml:mo>(</mml:mo><mml:mfrac><mml:mrow><mml:mi>Z</mml:mi><mml:mi>A</mml:mi><mml:mi>C</mml:mi><mml:mi>S</mml:mi><mml:mi>F</mml:mi></mml:mrow><mml:mrow><mml:mi>Z</mml:mi><mml:mi>A</mml:mi><mml:mi>C</mml:mi><mml:mi>C</mml:mi></mml:mrow></mml:mfrac><mml:mo>)</mml:mo></mml:mrow></mml:math></disp-formula></p>
</list-item>
<list-item>
<p><bold>User legal access rate <inline-formula id="ieqn-221"><mml:math id="mml-ieqn-221"><mml:msub><mml:mi>P</mml:mi><mml:mrow><mml:mi>L</mml:mi><mml:mi>A</mml:mi><mml:mi>F</mml:mi></mml:mrow></mml:msub></mml:math></inline-formula>:</bold> This indicates the user access control request, requesting resources that match their privilege levels:
<disp-formula id="eqn-11"><label>(11)</label><mml:math id="mml-eqn-11" display="block"><mml:msub><mml:mi>P</mml:mi><mml:mrow><mml:mi>L</mml:mi><mml:mi>A</mml:mi><mml:mi>F</mml:mi></mml:mrow></mml:msub><mml:mo>=</mml:mo><mml:mfrac><mml:mrow><mml:mi>L</mml:mi><mml:mi>A</mml:mi><mml:mi>C</mml:mi></mml:mrow><mml:mrow><mml:mi>A</mml:mi><mml:mi>C</mml:mi><mml:mi>C</mml:mi></mml:mrow></mml:mfrac></mml:math></disp-formula></p>
</list-item>
<list-item>
<p><bold>User&#x2019;s resource level match privilege level:</bold> This is a segmented function with a match privilege level:</p></list-item>
</list>
<disp-formula id="eqn-12"><label>(12)</label><mml:math id="mml-eqn-12" display="block"><mml:mtable columnalign="right left right left right left right left right left right left" rowspacing="3pt" columnspacing="0em 2em 0em 2em 0em 2em 0em 2em 0em 2em 0em" displaystyle="true"><mml:mtr><mml:mtd><mml:msub><mml:mi>f</mml:mi><mml:mrow><mml:mi>R</mml:mi><mml:mi>L</mml:mi></mml:mrow></mml:msub><mml:mo>=</mml:mo><mml:mrow><mml:mo>{</mml:mo><mml:mtable columnalign="left left" rowspacing=".2em" columnspacing="1em" displaystyle="false"><mml:mtr><mml:mtd><mml:mn>1</mml:mn><mml:mo>,</mml:mo></mml:mtd><mml:mtd><mml:mrow><mml:mtext>if&#xA0;</mml:mtext></mml:mrow><mml:mrow><mml:mtext>CARL</mml:mtext></mml:mrow><mml:mo>&#x2264;</mml:mo><mml:mrow><mml:mtext>CAPL</mml:mtext></mml:mrow></mml:mtd></mml:mtr><mml:mtr><mml:mtd><mml:mn>1</mml:mn><mml:mo>&#x2212;</mml:mo><mml:mstyle displaystyle="true" scriptlevel="0"><mml:mfrac><mml:mrow><mml:mrow><mml:mtext>CARL</mml:mtext></mml:mrow><mml:mo>&#x2212;</mml:mo><mml:mrow><mml:mtext>CAPL</mml:mtext></mml:mrow></mml:mrow><mml:mrow><mml:mtext>CAPL</mml:mtext></mml:mrow></mml:mfrac></mml:mstyle><mml:mo>,</mml:mo></mml:mtd><mml:mtd><mml:mrow><mml:mtext>if&#xA0;</mml:mtext></mml:mrow><mml:mrow><mml:mtext>CARL</mml:mtext></mml:mrow><mml:mo>&gt;</mml:mo><mml:mrow><mml:mtext>CAPL</mml:mtext></mml:mrow></mml:mtd></mml:mtr></mml:mtable><mml:mo fence="true" stretchy="true" symmetric="true"></mml:mo></mml:mrow></mml:mtd></mml:mtr></mml:mtable></mml:math></disp-formula></p>
<p>Combining <xref ref-type="disp-formula" rid="eqn-9">Eqs. (9)</xref>&#x2013;<xref ref-type="disp-formula" rid="eqn-11">(11)</xref> to obtain combining evidence:
<disp-formula id="eqn-13"><label>(13)</label><mml:math id="mml-eqn-13" display="block"><mml:mi>P</mml:mi><mml:mrow><mml:mo>(</mml:mo><mml:mi>X</mml:mi><mml:mrow></mml:mrow><mml:mo>|</mml:mo><mml:mrow></mml:mrow><mml:msubsup><mml:mi>&#x03B8;</mml:mi><mml:mi>i</mml:mi><mml:mo>+</mml:mo></mml:msubsup><mml:mo>)</mml:mo></mml:mrow><mml:mo>=</mml:mo><mml:msub><mml:mi>&#x03B4;</mml:mi><mml:mn>1</mml:mn></mml:msub><mml:mo>&#x2217;</mml:mo><mml:msub><mml:mi>P</mml:mi><mml:mrow><mml:mi>A</mml:mi><mml:mi>S</mml:mi></mml:mrow></mml:msub><mml:mo>+</mml:mo><mml:msub><mml:mi>&#x03B4;</mml:mi><mml:mn>2</mml:mn></mml:msub><mml:mo>&#x2217;</mml:mo><mml:msub><mml:mi>P</mml:mi><mml:mrow><mml:mi>A</mml:mi><mml:mi>C</mml:mi><mml:mi>S</mml:mi></mml:mrow></mml:msub><mml:mo>+</mml:mo><mml:msub><mml:mi>&#x03B4;</mml:mi><mml:mn>3</mml:mn></mml:msub><mml:mo>&#x2217;</mml:mo><mml:msub><mml:mi>P</mml:mi><mml:mrow><mml:mi>L</mml:mi><mml:mi>A</mml:mi><mml:mi>F</mml:mi></mml:mrow></mml:msub><mml:mo>+</mml:mo><mml:msub><mml:mi>&#x03B4;</mml:mi><mml:mn>4</mml:mn></mml:msub><mml:mo>&#x2217;</mml:mo><mml:msub><mml:mi>f</mml:mi><mml:mrow><mml:mi>R</mml:mi><mml:mi>L</mml:mi></mml:mrow></mml:msub></mml:math></disp-formula>where <inline-formula id="ieqn-222"><mml:math id="mml-ieqn-222"><mml:msub><mml:mi>&#x03B4;</mml:mi><mml:mi>i</mml:mi></mml:msub></mml:math></inline-formula> is the probability weight used to adjust the importance of each component in the credibility assessment.</p>
<p><inline-formula id="ieqn-223"><mml:math id="mml-ieqn-223"><mml:mi>P</mml:mi><mml:mo stretchy="false">(</mml:mo><mml:mi>X</mml:mi><mml:mo stretchy="false">)</mml:mo></mml:math></inline-formula> is the average behavior performance of all users in the system, which serves as a standardization:
<disp-formula id="eqn-14"><label>(14)</label><mml:math id="mml-eqn-14" display="block"><mml:mi>P</mml:mi><mml:mo stretchy="false">(</mml:mo><mml:mi>X</mml:mi><mml:mo stretchy="false">)</mml:mo><mml:mo>=</mml:mo><mml:mfrac><mml:mrow><mml:mi>Z</mml:mi><mml:mi>A</mml:mi><mml:mi>S</mml:mi><mml:mi>F</mml:mi><mml:mo>&#x2217;</mml:mo><mml:mi>Z</mml:mi><mml:mi>A</mml:mi><mml:mi>C</mml:mi></mml:mrow><mml:mrow><mml:mi>Z</mml:mi><mml:mi>A</mml:mi><mml:mi>C</mml:mi><mml:mi>S</mml:mi><mml:mo>&#x2217;</mml:mo><mml:mi>Z</mml:mi><mml:mi>A</mml:mi><mml:mi>C</mml:mi><mml:mi>C</mml:mi></mml:mrow></mml:mfrac><mml:mo>&#x2217;</mml:mo><mml:mfrac><mml:mn>1</mml:mn><mml:mi>n</mml:mi></mml:mfrac><mml:munderover><mml:mo>&#x2211;</mml:mo><mml:mn>1</mml:mn><mml:mi>n</mml:mi></mml:munderover><mml:msub><mml:mi>f</mml:mi><mml:mrow><mml:mi>R</mml:mi><mml:mi>L</mml:mi></mml:mrow></mml:msub></mml:math></disp-formula></p>
<p>The formula for the user&#x2019;s reputation value is:
<disp-formula id="eqn-15"><label>(15)</label><mml:math id="mml-eqn-15" display="block"><mml:msubsup><mml:mi>R</mml:mi><mml:mrow><mml:msub><mml:mi>U</mml:mi><mml:mi>j</mml:mi></mml:msub></mml:mrow><mml:mo>+</mml:mo></mml:msubsup><mml:mo>=</mml:mo><mml:mi>P</mml:mi><mml:mrow><mml:mo>(</mml:mo><mml:msubsup><mml:mi>&#x03B8;</mml:mi><mml:mi>i</mml:mi><mml:mo>+</mml:mo></mml:msubsup><mml:mrow></mml:mrow><mml:mo>|</mml:mo><mml:mrow></mml:mrow><mml:mi>X</mml:mi><mml:mo>)</mml:mo></mml:mrow><mml:mo>=</mml:mo><mml:mfrac><mml:mrow><mml:mi>P</mml:mi><mml:mo stretchy="false">(</mml:mo><mml:mi>X</mml:mi><mml:mrow><mml:mo stretchy="false">|</mml:mo></mml:mrow><mml:msubsup><mml:mi>&#x03B8;</mml:mi><mml:mi>i</mml:mi><mml:mo>+</mml:mo></mml:msubsup><mml:mo stretchy="false">)</mml:mo><mml:mo>&#x2217;</mml:mo><mml:msubsup><mml:mrow><mml:mi>P</mml:mi><mml:mo stretchy="false">(</mml:mo><mml:mi>&#x03B8;</mml:mi></mml:mrow><mml:mi>i</mml:mi><mml:mo>+</mml:mo></mml:msubsup><mml:mo stretchy="false">)</mml:mo></mml:mrow><mml:mrow><mml:mi>P</mml:mi><mml:mrow><mml:mo>(</mml:mo><mml:mi>X</mml:mi><mml:mo>)</mml:mo></mml:mrow></mml:mrow></mml:mfrac></mml:math></disp-formula></p>
<p>The <inline-formula id="ieqn-224"><mml:math id="mml-ieqn-224"><mml:msubsup><mml:mi>R</mml:mi><mml:mrow><mml:msub><mml:mi>U</mml:mi><mml:mi>j</mml:mi></mml:msub></mml:mrow><mml:mo>&#x2212;</mml:mo></mml:msubsup></mml:math></inline-formula> is the value of the user&#x2019;s future risk value, which is calculated by considering the following factors in RASC:
<list list-type="bullet">
<list-item>
<p><bold>User authentication failure rate <inline-formula id="ieqn-225"><mml:math id="mml-ieqn-225"><mml:msub><mml:mi>P</mml:mi><mml:mrow><mml:mi>A</mml:mi><mml:mi>F</mml:mi></mml:mrow></mml:msub></mml:math></inline-formula>:</bold> This is the ratio of the number of user authentication failures to the number of user authentications:
<disp-formula id="eqn-16"><label>(16)</label><mml:math id="mml-eqn-16" display="block"><mml:msub><mml:mi>P</mml:mi><mml:mrow><mml:mi>A</mml:mi><mml:mi>F</mml:mi></mml:mrow></mml:msub><mml:mo>=</mml:mo><mml:mfrac><mml:mrow><mml:mi>F</mml:mi><mml:mi>S</mml:mi><mml:mi>F</mml:mi></mml:mrow><mml:mrow><mml:mi>A</mml:mi><mml:mi>C</mml:mi></mml:mrow></mml:mfrac></mml:math></disp-formula></p>
</list-item>
<list-item>
<p><bold>User access control success rate <inline-formula id="ieqn-226"><mml:math id="mml-ieqn-226"><mml:msub><mml:mi>P</mml:mi><mml:mrow><mml:mi>A</mml:mi><mml:mi>C</mml:mi><mml:mi>F</mml:mi></mml:mrow></mml:msub></mml:math></inline-formula>:</bold> This is the ratio of the number of successful user access controls to the number of user access controls:
<disp-formula id="eqn-17"><label>(17)</label><mml:math id="mml-eqn-17" display="block"><mml:msub><mml:mi>P</mml:mi><mml:mrow><mml:mi>A</mml:mi><mml:mi>C</mml:mi><mml:mi>F</mml:mi></mml:mrow></mml:msub><mml:mo>=</mml:mo><mml:mfrac><mml:mrow><mml:mi>F</mml:mi><mml:mi>C</mml:mi><mml:mi>S</mml:mi><mml:mi>F</mml:mi></mml:mrow><mml:mrow><mml:mi>A</mml:mi><mml:mi>C</mml:mi><mml:mi>C</mml:mi></mml:mrow></mml:mfrac></mml:math></disp-formula></p>
</list-item>
<list-item>
<p><bold>Access sensitive information frequency <inline-formula id="ieqn-227"><mml:math id="mml-ieqn-227"><mml:msub><mml:mi>P</mml:mi><mml:mrow><mml:mi>S</mml:mi><mml:mi>A</mml:mi><mml:mi>C</mml:mi></mml:mrow></mml:msub></mml:math></inline-formula>:</bold> This is the ratio of the frequency of user access to sensitive information to the frequency of user access control:
<disp-formula id="eqn-18"><label>(18)</label><mml:math id="mml-eqn-18" display="block"><mml:msub><mml:mi>P</mml:mi><mml:mrow><mml:mi>S</mml:mi><mml:mi>A</mml:mi><mml:mi>C</mml:mi></mml:mrow></mml:msub><mml:mo>=</mml:mo><mml:mfrac><mml:mrow><mml:mi>S</mml:mi><mml:mi>A</mml:mi><mml:mi>C</mml:mi><mml:mi>F</mml:mi></mml:mrow><mml:mrow><mml:mi>A</mml:mi><mml:mi>C</mml:mi><mml:mi>F</mml:mi></mml:mrow></mml:mfrac></mml:math></disp-formula></p>
</list-item>
</list></p>
<p>Combining <xref ref-type="disp-formula" rid="eqn-12">Eqs. (12)</xref>, <xref ref-type="disp-formula" rid="eqn-16">(16)</xref>&#x2013;<xref ref-type="disp-formula" rid="eqn-18">(18)</xref> and <italic>MTP</italic>, the combining evidence is obtained:
<disp-formula id="eqn-19"><label>(19)</label><mml:math id="mml-eqn-19" display="block"><mml:mi>P</mml:mi><mml:mrow><mml:mo>(</mml:mo><mml:mi>X</mml:mi><mml:mo>&#x2223;</mml:mo><mml:msubsup><mml:mi>&#x03B8;</mml:mi><mml:mi>i</mml:mi><mml:mo>&#x2212;</mml:mo></mml:msubsup><mml:mo>)</mml:mo></mml:mrow><mml:mo>=</mml:mo><mml:msub><mml:mi>&#x03C3;</mml:mi><mml:mn>1</mml:mn></mml:msub><mml:mo>&#x22C5;</mml:mo><mml:msub><mml:mi>P</mml:mi><mml:mrow><mml:mi>A</mml:mi><mml:mi>F</mml:mi></mml:mrow></mml:msub><mml:mo>+</mml:mo><mml:msub><mml:mi>&#x03C3;</mml:mi><mml:mn>2</mml:mn></mml:msub><mml:mo>&#x22C5;</mml:mo><mml:msub><mml:mi>P</mml:mi><mml:mrow><mml:mi>A</mml:mi><mml:mi>C</mml:mi><mml:mi>F</mml:mi></mml:mrow></mml:msub><mml:mo>+</mml:mo><mml:msub><mml:mi>&#x03C3;</mml:mi><mml:mn>3</mml:mn></mml:msub><mml:mo>&#x22C5;</mml:mo><mml:msub><mml:mi>f</mml:mi><mml:mrow><mml:mi>R</mml:mi><mml:mi>L</mml:mi></mml:mrow></mml:msub><mml:mo>+</mml:mo><mml:msub><mml:mi>&#x03C3;</mml:mi><mml:mn>4</mml:mn></mml:msub><mml:mo>&#x22C5;</mml:mo><mml:msub><mml:mi>P</mml:mi><mml:mrow><mml:mi>S</mml:mi><mml:mi>A</mml:mi><mml:mi>C</mml:mi></mml:mrow></mml:msub><mml:mo>+</mml:mo><mml:msub><mml:mi>&#x03C3;</mml:mi><mml:mn>5</mml:mn></mml:msub><mml:mo>&#x22C5;</mml:mo><mml:mi>M</mml:mi><mml:mi>T</mml:mi><mml:mi>P</mml:mi></mml:math></disp-formula>where <inline-formula id="ieqn-228"><mml:math id="mml-ieqn-228"><mml:msub><mml:mi>&#x03C3;</mml:mi><mml:mi>i</mml:mi></mml:msub></mml:math></inline-formula> is the weight parameter, which is used to adjust the value at risk.</p>
<p>The formula for the user&#x2019;s value-at-risk is:
<disp-formula id="eqn-20"><label>(20)</label><mml:math id="mml-eqn-20" display="block"><mml:msubsup><mml:mi>R</mml:mi><mml:mrow><mml:msub><mml:mi>U</mml:mi><mml:mi>j</mml:mi></mml:msub></mml:mrow><mml:mo>&#x2212;</mml:mo></mml:msubsup><mml:mo>=</mml:mo><mml:mi>P</mml:mi><mml:mrow><mml:mo>(</mml:mo><mml:msubsup><mml:mi>&#x03B8;</mml:mi><mml:mi>i</mml:mi><mml:mo>&#x2212;</mml:mo></mml:msubsup><mml:mrow></mml:mrow><mml:mo>|</mml:mo><mml:mrow></mml:mrow><mml:mi>X</mml:mi><mml:mo>)</mml:mo></mml:mrow><mml:mo>=</mml:mo><mml:mfrac><mml:mrow><mml:mi>P</mml:mi><mml:mo stretchy="false">(</mml:mo><mml:mi>X</mml:mi><mml:mrow><mml:mo stretchy="false">|</mml:mo></mml:mrow><mml:msubsup><mml:mi>&#x03B8;</mml:mi><mml:mi>i</mml:mi><mml:mo>&#x2212;</mml:mo></mml:msubsup><mml:mo stretchy="false">)</mml:mo><mml:mo>&#x2217;</mml:mo><mml:msubsup><mml:mrow><mml:mi>P</mml:mi><mml:mo stretchy="false">(</mml:mo><mml:mi>&#x03B8;</mml:mi></mml:mrow><mml:mi>i</mml:mi><mml:mo>&#x2212;</mml:mo></mml:msubsup><mml:mo stretchy="false">)</mml:mo></mml:mrow><mml:mrow><mml:mi>P</mml:mi><mml:mrow><mml:mo>(</mml:mo><mml:mi>X</mml:mi><mml:mo>)</mml:mo></mml:mrow></mml:mrow></mml:mfrac></mml:math></disp-formula></p>
</sec>
<sec id="s3_6_4">
<label>3.6.4</label>
<title>User Behavior Score</title>
<p>The calculation of user behavior scores is implemented within the BSESC on the blockchain. These scores are computed by integrating both the user&#x2019;s reputation value and risk value, providing a comprehensive assessment of the user&#x2019;s overall behavior performance. The behavior score is formally defined by the following equation:
<disp-formula id="eqn-21"><label>(21)</label><mml:math id="mml-eqn-21" display="block"><mml:mi>A</mml:mi><mml:mi>S</mml:mi><mml:mrow><mml:mo>(</mml:mo><mml:msub><mml:mi>U</mml:mi><mml:mi>j</mml:mi></mml:msub><mml:mo>)</mml:mo></mml:mrow><mml:mo>=</mml:mo><mml:mi>&#x03B1;</mml:mi><mml:mo>&#x2217;</mml:mo><mml:msubsup><mml:mi>R</mml:mi><mml:mrow><mml:msub><mml:mi>U</mml:mi><mml:mi>j</mml:mi></mml:msub></mml:mrow><mml:mo>+</mml:mo></mml:msubsup><mml:mo>&#x2212;</mml:mo><mml:mi>&#x03B2;</mml:mi><mml:mo>&#x2217;</mml:mo><mml:msubsup><mml:mi>R</mml:mi><mml:mrow><mml:msub><mml:mi>U</mml:mi><mml:mi>j</mml:mi></mml:msub></mml:mrow><mml:mo>&#x2212;</mml:mo></mml:msubsup></mml:math></disp-formula>where:
<list list-type="bullet">
<list-item>
<p><inline-formula id="ieqn-229"><mml:math id="mml-ieqn-229"><mml:mi>&#x03B1;</mml:mi></mml:math></inline-formula>: The weight of the reputation value, <inline-formula id="ieqn-230"><mml:math id="mml-ieqn-230"><mml:mi>&#x03B1;</mml:mi><mml:mo>&gt;</mml:mo><mml:mn>0</mml:mn></mml:math></inline-formula>, is used to control for the positive impact of the reputation value on the behavior score.</p></list-item>
<list-item>
<p><inline-formula id="ieqn-231"><mml:math id="mml-ieqn-231"><mml:mi>&#x03B2;</mml:mi></mml:math></inline-formula>: The weight of the risk value, <inline-formula id="ieqn-232"><mml:math id="mml-ieqn-232"><mml:mi>&#x03B2;</mml:mi><mml:mo>&gt;</mml:mo><mml:mn>0</mml:mn></mml:math></inline-formula>, is used to control for the negative impact of the risk value on the behavior score.</p></list-item>
</list></p>
<p>When <inline-formula id="ieqn-233"><mml:math id="mml-ieqn-233"><mml:mi>&#x03B1;</mml:mi><mml:mo>&gt;</mml:mo><mml:mi>&#x03B2;</mml:mi></mml:math></inline-formula> is in place, the system focuses on the user&#x2019;s reputation to formulate an access control policy; conversely, the system focuses on the risk that the user may pose to the system.</p>
<p>To determine the optimal parameter configuration that results in the most rapid decline of behavior scores, we formulate an objective function and employ a global search strategy followed by local optimization.
<disp-formula id="eqn-22"><label>(22)</label><mml:math id="mml-eqn-22" display="block"><mml:mi>f</mml:mi><mml:mrow><mml:mo>(</mml:mo><mml:mi>x</mml:mi><mml:mo>)</mml:mo></mml:mrow><mml:mo>=</mml:mo><mml:mfrac><mml:mrow><mml:mi mathvariant="normal">&#x0394;</mml:mi><mml:mi>A</mml:mi><mml:mi>S</mml:mi></mml:mrow><mml:mi>n</mml:mi></mml:mfrac></mml:math></disp-formula>where <inline-formula id="ieqn-234"><mml:math id="mml-ieqn-234"><mml:mi mathvariant="normal">&#x0394;</mml:mi><mml:mi>A</mml:mi><mml:mi>S</mml:mi></mml:math></inline-formula> denotes the magnitude of the user behavior score decrease, <inline-formula id="ieqn-235"><mml:math id="mml-ieqn-235"><mml:mi>n</mml:mi></mml:math></inline-formula> denotes the number of access control attack rounds, and <inline-formula id="ieqn-236"><mml:math id="mml-ieqn-236"><mml:mi>f</mml:mi><mml:mrow><mml:mo>(</mml:mo><mml:mi>x</mml:mi><mml:mo>)</mml:mo></mml:mrow></mml:math></inline-formula> denotes the rate of user behavior score decrease with constraints on the parameters in the user reputation value and user risk value. The constraints are:
<disp-formula id="eqn-23"><label>(23)</label><mml:math id="mml-eqn-23" display="block"><mml:munderover><mml:mo movablelimits="false">&#x2211;</mml:mo><mml:mrow><mml:mi>i</mml:mi><mml:mo>=</mml:mo><mml:mn>1</mml:mn></mml:mrow><mml:mrow><mml:mi>n</mml:mi></mml:mrow></mml:munderover><mml:msub><mml:mi>&#x03B4;</mml:mi><mml:mi>i</mml:mi></mml:msub><mml:mo>=</mml:mo><mml:mn>1</mml:mn><mml:mo>,</mml:mo><mml:mspace width="1em" /><mml:munderover><mml:mo movablelimits="false">&#x2211;</mml:mo><mml:mrow><mml:mi>i</mml:mi><mml:mo>=</mml:mo><mml:mn>1</mml:mn></mml:mrow><mml:mrow><mml:mi>n</mml:mi></mml:mrow></mml:munderover><mml:msub><mml:mi>&#x03C3;</mml:mi><mml:mi>i</mml:mi></mml:msub><mml:mo>=</mml:mo><mml:mn>1</mml:mn><mml:mo>,</mml:mo><mml:msub><mml:mi>&#x03B4;</mml:mi><mml:mi>i</mml:mi></mml:msub><mml:mo>&gt;</mml:mo><mml:mn>0</mml:mn><mml:mo>,</mml:mo><mml:mspace width="1em" /><mml:msub><mml:mi>&#x03C3;</mml:mi><mml:mi>i</mml:mi></mml:msub><mml:mo>&gt;</mml:mo><mml:mn>0.</mml:mn></mml:math></disp-formula></p>
<p>To obtain a globally optimal solution within the parameter space, a grid search strategy is first applied to exhaustively scan discretized parameter combinations. The corresponding objective function values are evaluated to identify the configuration that leads to the most rapid decline in behavior scores.</p>
<p>To further enhance search accuracy and computational efficiency, simulated annealing is used for local refinement. The algorithm is initialized with the best result obtained from the grid search and iteratively adjusts the parameter set. During the annealing process, suboptimal solutions are accepted with a certain probability to avoid premature convergence to local optima.</p>
</sec>
</sec>
</sec>
<sec id="s4">
<label>4</label>
<title>Experiment and Result</title>
<p>This chapter first introduces the experimental environment, followed by an analysis of the security and dynamics of DPZTN, and concludes with a performance analysis of DPZTN.</p>
<sec id="s4_1">
<label>4.1</label>
<title>Experiment Preparation</title>
<p><bold>Environment configuration:</bold> In this study, the experimental environment is established using a Dell PowerEdge R720 server equipped with the VMware ESXi 6.0 virtualization platform. The platform is accessed and administrated from a personal computer via the VMware vSphere Client, enabling centralized management of the virtualized infrastructure. The virtual machine runs Ubuntu 18.04. Peer nodes play the role of ZTNEs and deploy a blockchain and programmable switch environment. Six virtual machines simulate users and attackers. The five Order nodes are used for sorting the nine blockchain peer nodes. The experimental topology is illustrated in <xref ref-type="fig" rid="fig-5">Fig. 5</xref>.</p>
<fig id="fig-5">
<label>Figure 5</label>
<caption>
<title>Experimental topology</title>
</caption>
<graphic mimetype="image" mime-subtype="tif" xlink:href="CSSE_68151-fig-5.tif"/>
</fig>
<p>In the virtual machine, Python 3.11 is used to code the protocol part, while Go 1.10.3 is used to write and deploy smart contracts on Fabric 1.4. The ZTNE registration, ZTNE authentication, user registration, user authentication, and user access control processes are implemented by calling the Fabric smart contract interfaces from the Python code. Meanwhile, the smart contract records each user behavior. For users who obtain access privileges, their request behavior is continuously monitored using BMv2, and the probability of malicious behavior is returned in real time via its control plane interface. We have made the DPZTN code publicly available on GitHub: <ext-link ext-link-type="uri" xlink:href="https://github.com/ILScience/DPZTN">https://github.com/ILScience/DPZTN</ext-link> (accessed on 02 September 2025)</p>
<p><bold>Dataset:</bold> The dataset used in this paper is the dataset liliMpro [<xref ref-type="bibr" rid="ref-24">24</xref>] generated and collected by our lab. This dataset was collected by the National Engineering Research Center for Mobile Private Networks of Beijing Jiaotong University, and this paper uses 14 DDoS attack types from it to simulate the attack behavior of malicious users after gaining access.</p>
<p><bold>Malicious behavior:</bold> In this paper, three types of user malicious behaviors are used to test the proposed ZTN:
<list list-type="bullet">
<list-item>
<p><bold>Unauthorized access:</bold> A user elevates his or her privileges beyond their access privilege level. A user access request where they elevate their access privilege level (without being authorized) to achieve an access request that exceeds their privileges.</p></list-item>
<list-item>
<p><bold>Sensitive resource access:</bold> Users access sensitive data or resources that are within their normal privileges but should not be accessed frequently.</p></list-item>
<list-item>
<p><bold>DDoS attack:</bold> The attacker sends a large number of requests to the target system through multiple controlled computers at the same time, causing the target system to be unable to serve normally, thus interrupting the service.</p></list-item>
</list></p>
<p><bold>Behavior patterns:</bold> Two malicious behavior patterns are defined to evaluate the system&#x2019;s sensitivity and adaptability: continuous and intermittent malicious behavior.
<list list-type="bullet">
<list-item>
<p><bold>Continuous malicious behavior:</bold> This pattern is used to verify the effectiveness of the system in identifying malicious behaviors.</p></list-item>
<list-item>
<p><bold>Intermittent malicious behavior:</bold> This pattern is used to verify that the DPZTN maintains a certain degree of sensitivity to episodic malicious behaviors and that the DPZTN has coherent performance in terms of the reputation of cross-malicious behaviors.</p></list-item>
</list></p>
</sec>
<sec id="s4_2">
<label>4.2</label>
<title>Parameter Setting</title>
<p>With the experimental environment established, we next describe the configuration of key parameters used to evaluate system performance and behavior response.The parameters for user behavior scores are derived using the methods described in <xref ref-type="sec" rid="s3_4_1">Sections 3.4.1</xref> and <xref ref-type="sec" rid="s3_6_4">3.6.4</xref>.</p>
<p>The mapping relationship between the initial access privilege level and the role is as follows:
<disp-formula id="eqn-24"><label>(24)</label><mml:math id="mml-eqn-24" display="block"><mml:mi>A</mml:mi><mml:mi>L</mml:mi><mml:msub><mml:mrow><mml:mo>(</mml:mo><mml:msub><mml:mi>U</mml:mi><mml:mi>j</mml:mi></mml:msub><mml:mo>)</mml:mo></mml:mrow><mml:mrow><mml:mrow><mml:mtext>init</mml:mtext></mml:mrow></mml:mrow></mml:msub><mml:mo>=</mml:mo><mml:mrow><mml:mo>{</mml:mo><mml:mtable columnalign="left left" rowspacing=".2em" columnspacing="1em" displaystyle="false"><mml:mtr><mml:mtd><mml:mn>5</mml:mn><mml:mo>,</mml:mo></mml:mtd><mml:mtd><mml:mrow><mml:mtext>RU</mml:mtext></mml:mrow></mml:mtd></mml:mtr><mml:mtr><mml:mtd><mml:mn>15</mml:mn><mml:mo>,</mml:mo></mml:mtd><mml:mtd><mml:mrow><mml:mtext>PU</mml:mtext></mml:mrow></mml:mtd></mml:mtr><mml:mtr><mml:mtd><mml:mn>25</mml:mn><mml:mo>,</mml:mo></mml:mtd><mml:mtd><mml:mrow><mml:mtext>Admin</mml:mtext></mml:mrow></mml:mtd></mml:mtr></mml:mtable><mml:mo fence="true" stretchy="true" symmetric="true"></mml:mo></mml:mrow></mml:math></disp-formula></p>
<p>The value ranges of <inline-formula id="ieqn-237"><mml:math id="mml-ieqn-237"><mml:msub><mml:mi>&#x03B4;</mml:mi><mml:mi>i</mml:mi></mml:msub></mml:math></inline-formula> and <inline-formula id="ieqn-238"><mml:math id="mml-ieqn-238"><mml:msub><mml:mi>&#x03C3;</mml:mi><mml:mi>i</mml:mi></mml:msub></mml:math></inline-formula> are set to <inline-formula id="ieqn-239"><mml:math id="mml-ieqn-239"><mml:mo stretchy="false">[</mml:mo><mml:mn>0</mml:mn><mml:mo>,</mml:mo><mml:mn>1</mml:mn><mml:mo stretchy="false">]</mml:mo></mml:math></inline-formula> with a step size of 0.05. The initial temperature for the simulated annealing algorithm is set to 10, the cooling rate to 0.95, and the maximum number of iterations to 100, which limits the total number of algorithmic steps. The optimal parameters for ZRV are (<inline-formula id="ieqn-240"><mml:math id="mml-ieqn-240"><mml:msub><mml:mi>&#x03B4;</mml:mi><mml:mn>1</mml:mn></mml:msub><mml:mo>,</mml:mo><mml:msub><mml:mi>&#x03B4;</mml:mi><mml:mn>2</mml:mn></mml:msub><mml:mo>,</mml:mo><mml:msub><mml:mi>&#x03B4;</mml:mi><mml:mn>3</mml:mn></mml:msub><mml:mo>,</mml:mo><mml:msub><mml:mi>&#x03B4;</mml:mi><mml:mn>4</mml:mn></mml:msub></mml:math></inline-formula>) &#x003D; (0.012, 0.945, 0.031, 0.012). The optimal parameters for ZRR are (<inline-formula id="ieqn-241"><mml:math id="mml-ieqn-241"><mml:msub><mml:mi>&#x03C3;</mml:mi><mml:mn>1</mml:mn></mml:msub><mml:mo>,</mml:mo><mml:msub><mml:mi>&#x03C3;</mml:mi><mml:mn>2</mml:mn></mml:msub><mml:mo>,</mml:mo><mml:msub><mml:mi>&#x03C3;</mml:mi><mml:mn>3</mml:mn></mml:msub><mml:mo>,</mml:mo><mml:msub><mml:mi>&#x03C3;</mml:mi><mml:mn>4</mml:mn></mml:msub><mml:mo>,</mml:mo><mml:msub><mml:mi>&#x03C3;</mml:mi><mml:mn>5</mml:mn></mml:msub></mml:math></inline-formula>) &#x003D; (0.036, 0.017, 0.039, 0.004, 0.903).</p>
<p>Key variables&#x2014;including initial user privilege levels, attack types, attack intensities, and behavior evaluation strategies&#x2014;are carefully controlled to ensure that the observed outcomes can be attributed solely to the proposed methods, without interference from external confounding factors. The simulation framework adheres to deterministic rules, and the algorithmic processes are reproducible. Multiple independent trials are conducted to verify the stability and consistency of the results.</p>
</sec>
<sec id="s4_3">
<label>4.3</label>
<title>Security and Dynamics Analysis</title>
<p>After configuring the system, we conduct experiments to assess its dynamic security response capabilities under various malicious behavior patterns. In this section, the impact of different user behaviors on the reputation value and risk value of a ZTNE will be analyzed through the dynamic changes of user behavior scores and access privilege levels.</p>
<sec id="s4_3_1">
<label>4.3.1</label>
<title>User Behavior Score Analysis</title>
<p><xref ref-type="fig" rid="fig-6">Fig. 6</xref> offers an exposition of the trend of behavior scores of different levels of users (i.e., RU, PU and Admins) when they perform continuous or intermittent malicious behaviors. It is evident that by observing the dynamic changes in behavior scores, a rational foundation is established for the establishment of reasonable behavior score thresholds in the environment of user access control. These malicious behaviors include PE (Privilege Exceeded), RS (Resources Sensitive accessed), and ATK (DDoS Attacks). The figure also provides an analysis of various combinations of attacks (e.g., RS&#x002B;ATK, RS&#x002B;PE, ATK&#x002B;PE, RS&#x002B;ATK&#x002B;PE), which serves to further validate the sensitivity of the behavior scores to different types of attacks.</p>
<fig id="fig-6">
<label>Figure 6</label>
<caption>
<title>Changes in user behavior score (<bold>a</bold>) Admin persistent malicious behavior; (<bold>b</bold>) PU persistent malicious behavior; (<bold>c</bold>) RU persistent malicious behavior; (<bold>d</bold>) Admin intermittent malicious behavior; (<bold>e</bold>) PU intermittent malicious behavior; (<bold>f</bold>) RU intermittent malicious behavior)</title>
</caption>
<graphic mimetype="image" mime-subtype="tif" xlink:href="CSSE_68151-fig-6.tif"/>
</fig>
<p>When calculating the behavior score, several constraints are imposed: if the number of illegal access control attempts exceeds 3, SACF is greater than 0.05, or a DDoS attack is detected, the user&#x2019;s reputation value is penalized and the risk value is significantly increased. This design ensures that the behavior score remains highly sensitive to malicious behaviors.</p>
<p>In the change of behavior scores of Admin users as <xref ref-type="fig" rid="fig-6">Fig. 6a</xref> shown, the behavior scores remain at a high level, close to 0.8, during normal access; the behavior scores drop rapidly after executing malicious behaviors. In particular, the combination of malicious behaviors leads to a sharp drop in behavior scores to 0.001, indicating that the combination of malicious behaviors has a more significant effect on Admins.</p>
<p><xref ref-type="fig" rid="fig-6">Fig. 6d</xref> shows the behavior score variation of the admin with intermittent malicious behavior. The Admin executes malicious behaviors in rounds 20, 23, 26, and 29, respectively, showing a stepwise decreasing trend. Each time the malicious behavior is triggered, the behavior score decreases rapidly, while it remains stable temporarily when it is stopped. As the number of rounds of malicious behavior accumulates, the score eventually converges to 0.197. Even intermittent malicious behavior continues to affect the score and eventually approaches the effect of continuous malicious behavior.</p>
<p>Behavior scores for PUs (<xref ref-type="fig" rid="fig-6">Fig. 6b</xref>,<xref ref-type="fig" rid="fig-6">e</xref>) and RUs (<xref ref-type="fig" rid="fig-6">Fig. 6c</xref>,<xref ref-type="fig" rid="fig-6">f</xref>) vary similarly to Admins. The behavior score stays around 0.8 for normal access. A single malicious act has a small effect on the behavior score, while a combination of malicious acts causes the behavior score to drop rapidly to near minimum values. Intermittent malicious behaviors also show a stepwise decrease, with the final score approaching 0.197.</p>
<p>Additionally, alternating different malicious behaviors&#x2014;such as INT RS&#x002B;ATK&#x002B;PE <xref ref-type="disp-formula" rid="eqn-2">(2)</xref> was also examined. The results indicate that such alternating behavior patterns do not prevent malicious users from experiencing a decline in behavior scores, thereby confirming the consistency and sensitivity of the scoring mechanism to diverse malicious activity patterns.</p>
<p>In s ummary, the DPZTN is highly sensitive to a wide range of malicious behaviors. Although the intermittent malicious behavior decreases in a stepwise manner, the final impact on the behavior score is comparable to that of the continuous malicious behavior. These results provide a basis for the setting of behavior score thresholds in dynamic access control, and in this paper, 0.7 is chosen as the threshold to effectively restrict the access of malicious users.</p>
</sec>
<sec id="s4_3_2">
<label>4.3.2</label>
<title>User Privilege Level Dynamics Analysis</title>
<p><xref ref-type="fig" rid="fig-7">Fig. 7</xref> illustrates the dynamic pattern change of CAPL for different levels of users when they perform continuous or intermittent malicious behavior. Different levels of users behave similarly when receiving malicious behaviors.</p>
<fig id="fig-7">
<label>Figure 7</label>
<caption>
<title>Dynamic change of user privilege levels (<bold>a</bold>) Admin persistent malicious behavior; (<bold>b</bold>) PU persistent malicious behavior; (<bold>c</bold>) RU persistent malicious behavior; (<bold>d</bold>) Admin intermittent malicious behavior; (<bold>e</bold>) PU intermittent malicious behavior; (<bold>f</bold>) RU intermittent malicious behavior</title>
</caption>
<graphic mimetype="image" mime-subtype="tif" xlink:href="CSSE_68151-fig-7.tif"/>
</fig>
<p>Taking the Admin as an example, in the scenario where the Admin sustains malicious behaviors (<xref ref-type="fig" rid="fig-7">Fig. 7a</xref>), the CAPL stays at the initial value of 25 during normal access, and the CAPL decreases rapidly after the malicious behavior is triggered. The decline rate of combined malicious behavior is consistent with that of single malicious behavior, indicating that alternate malicious behavior fails to slow down the decline of CAPL.</p>
<p><xref ref-type="fig" rid="fig-7">Fig. 7d</xref> illustrates the change in CAPL for Admins under intermittent malicious behavior. Each time a malicious behavior is triggered, CAPL decreases significantly in a stepwise trend. When the malicious behavior stops, the CAPL briefly stabilizes but does not return to the previous privilege level, eventually converging to the lowest value of 20.</p>
<p>In summary, user CAPL is stable during normal access, while malicious behavior significantly reduces CAPL, suggesting that the privilege moderation mechanism effectively restricts access. The comparison of continuous and intermittent malicious behaviors shows that the cumulative effect of intermittent malicious behaviors is comparable to that of continuous malicious behaviors. Combined with the behavior score changes in, real-time adjustment of CAPL can effectively restrict malicious user access and improve system security. Moreover, the similarity in the variation trends of user behavior scores and user privilege level across different user levels under the same attack scenarios indicates the stability of the proposed algorithm.</p>
</sec>
<sec id="s4_3_3">
<label>4.3.3</label>
<title>ZTNE Reputation Value and Risk Value Analysis</title>
<p>To assess the impact of malicious behavior on the reputation value of ZTNEs, changes in ZRV and ZRR were analyzed under both persistent and intermittent attack scenarios. The corresponding results are presented in <xref ref-type="fig" rid="fig-8">Fig. 8</xref>.</p>
<fig id="fig-8">
<label>Figure 8</label>
<caption>
<title>Dynamic change of ZRV and ZRR. (<bold>a</bold>) Changes in ZRV when a user experiences RS; (<bold>b</bold>) Changes in ZRV when a user experiences ATK; (<bold>c</bold>) Changes in ZRV when a user experiences PE; (<bold>d</bold>) Changes in ZRV when a user experiences RS&#x002B;ATK&#x002B;PE; (<bold>e</bold>) Changes in ZRV when 5 users experiences RS; (<bold>f</bold>) Changes in ZRV when 5 users experiences ATK; (<bold>g</bold>) Changes in ZRV when 5 users experiences PE; (<bold>h</bold>) Changes in ZRV when 5 users experiences RS&#x002B;ATK&#x002B;PE; (<bold>i</bold>) Changes in ZRR when a user experiences RS; (<bold>j</bold>) Changes in ZRR when a user experiences ATK; (<bold>k</bold>) Changes in ZRR when a user experiences PE; (<bold>l</bold>) Changes in ZRR when a user experiences RS&#x002B;ATK&#x002B;PE; (<bold>m</bold>) Changes in ZRR when 5 users experiences RS; (<bold>n</bold>) Changes in ZRR when 5 users experiences ATK; (<bold>o</bold>) Changes in ZRR when 5 users experiences PE; (<bold>p</bold>) Changes in ZRR when 5 users experiences RS&#x002B;ATK&#x002B;PE</title>
</caption>
<graphic mimetype="image" mime-subtype="tif" xlink:href="CSSE_68151-fig-8.tif"/>
</fig>
<p><bold>Intermittent single malicious behavior:</bold> Intermittent malicious behavior significantly fluctuates the ZTNE reputation value in both single- and multi-user scenarios. ZRVs were affected despite normal behavior in between malicious behaviors. Due to the low frequency of malicious behaviors, the reputation value did not drop dramatically and remained stable overall, ensuring the continuity of normal user behaviors. The drop in the ZRV due to malicious behavior is difficult to recover quickly, and subsequent visits trigger fluctuations in ZRV due to the user&#x2019;s lower behavior scores, increasing the risk of subsequent visits. DDoS attacks are detected significantly earlier than sensitive resource accesses and transgressing accesses, and the system has the lowest tolerance for DDoS, immediately reducing the user&#x2019;s behavior scores in response to them once detected. In terms of the ZTNE ZRR, in the single-user scenario, the fluctuation of the ZRR is mainly centered on the periodic occurrence of DDoS attacks, and the ZRR rises and then gradually recovers. However, in multi-user scenarios, the synergistic effect of malicious behaviors leads to increased the ZRR fluctuations, which increases the difficulty of risk management in the system.</p>
<p><bold>Intermittent alternating malicious behavior:</bold> The experiment analyzes the impact of alternating malicious behavior on the ZRV of ZTNE. The system first reacts to DDoS attacks, and as the malicious behaviors alternate, the ZRV fluctuation gradually increases, especially in the multi-user scenario, where multiple malicious users collaborate to attack, making the ZRV fluctuate more frequently. Although malicious behaviors occur intermittently, their cumulative effect makes it difficult for ZRV to recover quickly, further aggravating the interference with the system. The range of ZRR fluctuation is greater in alternating malicious behaviors. Multi-user combined malicious behaviors lead to faster ZRR growth and more significant fluctuations in ZRR, indicating that the existing protection mechanism is difficult to cope with complex combined malicious behaviors. It has a weaker inhibition effect on ZRR growth, and the combined malicious behaviors are more disruptive and challenging to the system.</p>
<p>It is worth noting that for the experiments presented in <xref ref-type="sec" rid="s4_3">Section 4.3</xref>, each was repeated at least three times. However, due to limitations in result clarity, the repeated experimental results are not displayed in <xref ref-type="sec" rid="s4_3">Section 4.3</xref>.</p>
</sec>
</sec>
<sec id="s4_4">
<label>4.4</label>
<title>Performance Analysis</title>
<p>This section provides a statistical analysis of the CPU usage, memory usage, and the latency variations in the DPZTN workflow. Each system performance-related experiment was conducted at least three times to ensure the reliability and consistency of the results.</p>
<sec id="s4_4_1">
<label>4.4.1</label>
<title>CPU and Memory Usage</title>
<p>The experiment tested the CPU and memory resource utilization of the DPZTN for different number of users. From <xref ref-type="fig" rid="fig-9">Fig. 9</xref>, it can be seen that the average CPU usage for 10, 100 and 1000 user scenarios is 50%, and the memory usage is about 60%. When the number of users is 10,000, the average CPU usage rises to about 70% and the memory usage remains the same.</p>
<fig id="fig-9">
<label>Figure 9</label>
<caption>
<title>Average CPU and memory usage of the DPZTN in scenarios with different numbers of users</title>
</caption>
<graphic mimetype="image" mime-subtype="tif" xlink:href="CSSE_68151-fig-9.tif"/>
</fig>
</sec>
<sec id="s4_4_2">
<label>4.4.2</label>
<title>DPZTN Latency</title>
<p><xref ref-type="fig" rid="fig-10">Fig. 10</xref> shows the latency of each phase of the DPZTN. The registration phase has a long latency of about 3.8 s, which is mainly due to the blockchain writing initial information and multi-party verification. The user registration latency is about 2 s, which further validates the impact of blockchain writing on latency. The communication delay in the authentication phase is higher (about 0.06 s), but the total delay is only 0.5 s, indicating that the system optimizes the computational efficiency in the authentication phase. The total delay in the user authentication phase is 0.8 s, and the communication delay is about 0.02 s, with the main delay coming from the computation process. The access control phase has the lowest latency of 0.3 s, showing the efficiency of the session.</p>
<fig id="fig-10">
<label>Figure 10</label>
<caption>
<title>Average latency of each phase for the DPZTN</title>
</caption>
<graphic mimetype="image" mime-subtype="tif" xlink:href="CSSE_68151-fig-10.tif"/>
</fig>
<p>Although the study is based on simulations, the user behavior model, attack scenarios, and permission evolution mechanisms are designed to reflect common patterns observed in real network security incidents, thereby enhancing the realism and represent ativeness of the experiments. The algorithm was also tested under diverse initial conditions and various attack combinations to improve the generalizability of the findings. Nevertheless, it is acknowledged that simulation environments cannot fully capture the complexity and unpredictability of real systems. Future work will focus on extending the evaluation to real deployments or hybrid testbeds to further validate the applicability of the proposed model.</p>
</sec>
</sec>
</sec>
<sec id="s5">
<label>5</label>
<title>Security Analysis</title>
<p>To demonstrate the security advantages of DPZTN in IoT environments, this paper presents the defense effectiveness of DPZTN against various threats faced by the network.
<list list-type="bullet">
<list-item>
<p><bold>Confidentiality:</bold> DPZTN protects against information leakage by encrypting the identity data of users and ZTNE using a hash algorithm before storing it on the blockchain. This prevents unauthorized access and ensures sensitive data remains confidential. Additionally, a mutual authentication mechanism minimizes the risk of impersonation among the blockchain, ZTNE, and users. The integration of ZTNE with blockchain further strengthens identity protection. Details are provided in <xref ref-type="sec" rid="s3_2">Sections 3.2</xref> and <xref ref-type="sec" rid="s3_3">3.3</xref>.</p></list-item>
<list-item>
<p><bold>Completeness:</bold> To defend against tampering, DPZTN stores all authentication and access control data on the immutable blockchain. Communication between IoT devices and ZTNE is encrypted, ensuring data integrity both at rest and in transit. This effectively prevents unauthorized modifications or forgery, as explained in <xref ref-type="sec" rid="s3_2">Section 3.2</xref>.</p></list-item>
<list-item>
<p><bold>Undeniability:</bold> DPZTN immutably records all user identity registrations, access requests, and behavior logs on the blockchain. This ensures traceability and prevents users from denying their behaviors, enabling full auditability. The design prohibits any deletion or alteration of stored data, thereby guaranteeing accountability and transparency. Further details are provided in <xref ref-type="sec" rid="s3_3">Sections 3.3</xref> to <xref ref-type="sec" rid="s3_6">3.6</xref>.</p></list-item>
<list-item>
<p><bold>Usability:</bold> Through a dynamic reputation evaluation algorithm&#x2014;BBEA, DPZTN limits access for high-risk users, mitigating the threat of DDoS-based resource abuse. ZTNE continuously monitors traffic and can promptly block abnormal behavior, maintaining system availability. See <xref ref-type="sec" rid="s3_5">Section 3.5</xref> for more information.</p></list-item>
<list-item>
<p><bold>Least privilege:</bold> To counter privilege escalation, DPZTN applies a Bayesian-based behavior scoring mechanism that evaluates user reputation and risk in real time. By continuously monitoring user behavior, the system adjusts privileges dynamically, ensuring access stays within authorized bounds. This ensures that only legitimate users access resources, enhancing overall system security. The mechanism is detailed in <xref ref-type="sec" rid="s3_4">Sections 3.4</xref> and <xref ref-type="sec" rid="s3_6">3.6</xref>.</p></list-item>
</list></p>
</sec>
<sec id="s6">
<label>6</label>
<title>Conclusion</title>
<p>This paper presents DPZTN and introduces a BBEA for user behavior-based access control. By integrating BBEA into smart contracts, DPZTN dynamically adjusts user access privileges. The deployed ZTNE accurately detects malicious user behavior using specialized algorithms and monitors changes in user behavior scores to identify and block abnormal behaviors in real time. Experimental results show that DPZTN&#x2019;s ZTNE supports up to 10,000 users with multiple concurrent access requests. Significant delays only occur during network element and user registration, while access control and authentication introduce minimal latency, demonstrating strong performance and security. The ZTNE also enables zero-trust enforcement at the network element level, enhancing system security and providing dynamic access control.</p>
<p>To further enhance the effectiveness and applicability of the proposed DPZTN architecture, future research will focus on the following three key directions. Enhancing the capability of DPZTN to accurately assess and manage access requests from unknown or previously unseen users through online learning and behavior inference, thereby improving system resilience against zero-day threats. Designing and implementing optimized, resource-efficient smart contracts to enable real-time decision-making in large-scale or resource-constrained environments, such as edge and IoT networks. Extending the DPZTN framework to support secure identity federation and policy coordination across multiple administrative domains, enabling unified zero-trust enforcement in distributed network.</p>
</sec>
</body>
<back>
<ack>
<p>Not applicable.</p>
</ack>
<sec>
<title>Funding Statement</title>
<p>This research was funded by the Basic Research Operating Expenses Postgraduate Innovation Programme (Grant No. W24YJS00010, received by J. Yan), the National Key R&#x0026;D Program of China (Grant No. 2018YFA0701604, received by H. Zhou), and the National Natural Science Foundation of China (NSFC) (Grant No. 62341102, received by H. Zhou).</p>
</sec>
<sec>
<title>Author Contributions</title>
<p>Conceptualization, Jingfu Yan; methodology, Jingfu Yan; validation, Jingfu Yan, Weilin Wang and Huachun Zhou; formal analysis, Jingfu Yan; resources, Jingfu Yan; data curation, Jingfu Yan; writing&#x2014;original draft preparation, Jingfu Yan; writing&#x2014;review and editing, Jingfu Yan, Weilin Wang and Huachun Zhou; visualization, Jingfu Yan; supervision, Weilin Wang and Huachun Zhou; funding acquisition, Jingfu Yan. All authors reviewed the results and approved the final version of the manuscript.</p>
</sec>
<sec sec-type="data-availability">
<title>Availability of Data and Materials</title>
<p>The datasets generated and analyzed during the current study are openly available in <italic>liliMpro</italic> at <ext-link ext-link-type="uri" xlink:href="https://github.com/liliMpro/source_dataset">https://github.com/liliMpro/source_dataset</ext-link> (accessed on 02 September 2025).</p>
</sec>
<sec>
<title>Ethics Approval</title>
<p>Not applicable.</p>
</sec>
<sec sec-type="COI-statement">
<title>Conflicts of Interest</title>
<p>The authors declare no conflicts of interest to report regarding the present study.</p>
</sec>
<ref-list content-type="authoryear">
<title>References</title>
<ref id="ref-1"><label>[1]</label><mixed-citation publication-type="other"><person-group person-group-type="author"><collab>Group IGP</collab></person-group>. <article-title>6G Trusted Endogenous Security Architecture Study</article-title>. <comment>IMT-2030(6G) Promotion Group; 2023. (In Chinese)</comment>.</mixed-citation></ref>
<ref id="ref-2"><label>[2]</label><mixed-citation publication-type="journal"><person-group person-group-type="author"><string-name><surname>Nandy</surname> <given-names>T</given-names></string-name>, <string-name><surname>Idris</surname> <given-names>MYIB</given-names></string-name>, <string-name><surname>Md Noor</surname> <given-names>R</given-names></string-name>, <string-name><surname>Mat Kiah</surname> <given-names>L</given-names></string-name>, <string-name><surname>Lun</surname> <given-names>LS</given-names></string-name>, <string-name><surname>Annuar Juma&#x2019;at</surname> <given-names>NB</given-names></string-name>, <etal>et al</etal></person-group>. <article-title>Review on security of internet of things authentication mechanism</article-title>. <source>IEEE Access</source>. <year>2019</year>;<volume>7</volume>:<fpage>151054</fpage>&#x2013;<lpage>89</lpage>. doi:<pub-id pub-id-type="doi">10.1109/access.2019.2947723</pub-id>.</mixed-citation></ref>
<ref id="ref-3"><label>[3]</label><mixed-citation publication-type="journal"><person-group person-group-type="author"><string-name><surname>Zhaofeng</surname> <given-names>M</given-names></string-name>, <string-name><surname>Jialin</surname> <given-names>M</given-names></string-name>, <string-name><surname>Jihui</surname> <given-names>W</given-names></string-name>, <string-name><surname>Zhiguang</surname> <given-names>S</given-names></string-name></person-group>. <article-title>Blockchain-based decentralized authentication modeling scheme in edge and IoT environment</article-title>. <source>IEEE Internet Things J</source>. <year>2021</year>;<volume>8</volume>(<issue>4</issue>):<fpage>2116</fpage>&#x2013;<lpage>23</lpage>. doi:<pub-id pub-id-type="doi">10.1109/jiot.2020.3037733</pub-id>.</mixed-citation></ref>
<ref id="ref-4"><label>[4]</label><mixed-citation publication-type="journal"><person-group person-group-type="author"><string-name><surname>Bradatsch</surname> <given-names>L</given-names></string-name>, <string-name><surname>Miroshkin</surname> <given-names>O</given-names></string-name>, <string-name><surname>Kargl</surname> <given-names>F</given-names></string-name></person-group>. <article-title>ZTSFC: a service function chaining-enabled zero trust architecture</article-title>. <source>IEEE Access</source>. <year>2023</year>;<volume>11</volume>(<issue>6</issue>):<fpage>125307</fpage>&#x2013;<lpage>27</lpage>. doi:<pub-id pub-id-type="doi">10.1109/access.2023.3330706</pub-id>.</mixed-citation></ref>
<ref id="ref-5"><label>[5]</label><mixed-citation publication-type="journal"><person-group person-group-type="author"><string-name><surname>Hauser</surname> <given-names>F</given-names></string-name>, <string-name><surname>H&#x00E4;berle</surname> <given-names>M</given-names></string-name>, <string-name><surname>Merling</surname> <given-names>D</given-names></string-name>, <string-name><surname>Lindner</surname> <given-names>S</given-names></string-name>, <string-name><surname>Gurevich</surname> <given-names>V</given-names></string-name>, <string-name><surname>Zeiger</surname> <given-names>F</given-names></string-name>, <etal>et al</etal></person-group>. <article-title>A survey on data plane programming with P4: fundamentals, advances, and applied research</article-title>. <source>J Netw Comput Appl</source>. <year>2023</year>;<volume>212</volume>(<issue>3</issue>):<fpage>103561</fpage>. doi:<pub-id pub-id-type="doi">10.1016/j.jnca.2022.103561</pub-id>.</mixed-citation></ref>
<ref id="ref-6"><label>[6]</label><mixed-citation publication-type="journal"><person-group person-group-type="author"><string-name><surname>Jose</surname> <given-names>M</given-names></string-name>, <string-name><surname>Lazri</surname> <given-names>K</given-names></string-name>, <string-name><surname>Fran&#x00E7;ois</surname> <given-names>J</given-names></string-name>, <string-name><surname>Festor</surname> <given-names>O</given-names></string-name></person-group>. <article-title>Stateful InREC: stateful in-network real number computation with recursive functions</article-title>. <source>IEEE Trans Netw Serv Manag</source>. <year>2023</year>;<volume>20</volume>(<issue>1</issue>):<fpage>830</fpage>&#x2013;<lpage>45</lpage>. doi:<pub-id pub-id-type="doi">10.1109/tnsm.2022.3198008</pub-id>.</mixed-citation></ref>
<ref id="ref-7"><label>[7]</label><mixed-citation publication-type="journal"><person-group person-group-type="author"><string-name><surname>Itodo</surname> <given-names>C</given-names></string-name>, <string-name><surname>Ozer</surname> <given-names>M</given-names></string-name></person-group>. <article-title>Multivocal literature review on zero-trust security implementation</article-title>. <source>Comput Secur</source>. <year>2024</year>;<volume>141</volume>:<fpage>103827</fpage>.</mixed-citation></ref>
<ref id="ref-8"><label>[8]</label><mixed-citation publication-type="journal"><person-group person-group-type="author"><string-name><surname>Bala</surname> <given-names>B</given-names></string-name>, <string-name><surname>Behal</surname> <given-names>S</given-names></string-name></person-group>. <article-title>AI techniques for IoT-based DDoS attack detection: taxonomies, comprehensive review and research challenges</article-title>. <source>Comput Sci Rev</source>. <year>2024</year>;<volume>52</volume>(<issue>10</issue>):<fpage>100631</fpage>. doi:<pub-id pub-id-type="doi">10.1016/j.cosrev.2024.100631</pub-id>.</mixed-citation></ref>
<ref id="ref-9"><label>[9]</label><mixed-citation publication-type="other"><person-group person-group-type="author"><string-name><surname>Rose</surname> <given-names>S</given-names></string-name>, <string-name><surname>Borchert</surname> <given-names>O</given-names></string-name>, <string-name><surname>Mitchell</surname> <given-names>S</given-names></string-name>, <string-name><surname>Connelly</surname> <given-names>S</given-names></string-name></person-group>. <article-title>Zero trust architecture. National institute of standards and technology [Internet]; 2020 [cited 2025 Sep 2]</article-title>. Available from: <ext-link ext-link-type="uri" xlink:href="https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-207.pdf">https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800- 207.pdf</ext-link>.</mixed-citation></ref>
<ref id="ref-10"><label>[10]</label><mixed-citation publication-type="journal"><person-group person-group-type="author"><string-name><surname>Sengupta</surname> <given-names>B</given-names></string-name>, <string-name><surname>Lakshminarayanan</surname> <given-names>A</given-names></string-name></person-group>. <article-title>DistriTrust: distributed and low-latency access validation in zero-trust architecture</article-title>. <source>J Inf Secur Appl</source>. <year>2021</year>;<volume>63</volume>(<issue>6</issue>):<fpage>103023</fpage>. doi:<pub-id pub-id-type="doi">10.1016/j.jisa.2021.103023</pub-id>.</mixed-citation></ref>
<ref id="ref-11"><label>[11]</label><mixed-citation publication-type="journal"><person-group person-group-type="author"><string-name><surname>Federici</surname> <given-names>F</given-names></string-name>, <string-name><surname>Martintoni</surname> <given-names>D</given-names></string-name>, <string-name><surname>Senni</surname> <given-names>V</given-names></string-name></person-group>. <article-title>A zero-trust architecture for remote access in industrial IoT infrastructures</article-title>. <source>Electronics</source>. <year>2023</year>;<volume>12</volume>(<issue>3</issue>):<fpage>566</fpage>. doi:<pub-id pub-id-type="doi">10.3390/electronics12030566</pub-id>.</mixed-citation></ref>
<ref id="ref-12"><label>[12]</label><mixed-citation publication-type="journal"><person-group person-group-type="author"><string-name><surname>Azad</surname> <given-names>MA</given-names></string-name>, <string-name><surname>Bag</surname> <given-names>S</given-names></string-name>, <string-name><surname>Hao</surname> <given-names>F</given-names></string-name>, <string-name><surname>Shalaginov</surname> <given-names>A</given-names></string-name></person-group>. <article-title>Decentralized self-enforcing trust management system for social internet of things</article-title>. <source>IEEE I Things J</source>. <year>2020</year>;<volume>7</volume>(<issue>4</issue>):<fpage>2690</fpage>&#x2013;<lpage>703</lpage>. doi:<pub-id pub-id-type="doi">10.1109/jiot.2019.2962282</pub-id>.</mixed-citation></ref>
<ref id="ref-13"><label>[13]</label><mixed-citation publication-type="journal"><person-group person-group-type="author"><string-name><surname>Tu</surname> <given-names>Z</given-names></string-name>, <string-name><surname>Zhou</surname> <given-names>H</given-names></string-name>, <string-name><surname>Li</surname> <given-names>K</given-names></string-name>, <string-name><surname>Song</surname> <given-names>H</given-names></string-name>, <string-name><surname>Yang</surname> <given-names>Y</given-names></string-name></person-group>. <article-title>A blockchain-based trust and reputation model with dynamic evaluation mechanism for IoT</article-title>. <source>Comput Netw</source>. <year>2022</year>;<volume>218</volume>(<issue>15</issue>):<fpage>109404</fpage>. doi:<pub-id pub-id-type="doi">10.1016/j.comnet.2022.109404</pub-id>.</mixed-citation></ref>
<ref id="ref-14"><label>[14]</label><mixed-citation publication-type="journal"><person-group person-group-type="author"><string-name><surname>Taneja</surname> <given-names>H</given-names></string-name>, <string-name><surname>Kaur</surname> <given-names>S</given-names></string-name></person-group>. <article-title>Reputation based novel trust management framework with enhanced availability for cloud</article-title>. <source>J Parallel Distr Comput</source>. <year>2023</year>;<volume>178</volume>(<issue>5</issue>):<fpage>43</fpage>&#x2013;<lpage>55</lpage>. doi:<pub-id pub-id-type="doi">10.1016/j.jpdc.2023.03.010</pub-id>.</mixed-citation></ref>
<ref id="ref-15"><label>[15]</label><mixed-citation publication-type="journal"><person-group person-group-type="author"><string-name><surname>Tian</surname> <given-names>J</given-names></string-name>, <string-name><surname>Tian</surname> <given-names>J</given-names></string-name>, <string-name><surname>Du</surname> <given-names>R</given-names></string-name></person-group>. <article-title>MSLShard: an efficient sharding-based trust management framework for blockchain-empowered IoT access control</article-title>. <source>J Parallel Distr Comput</source>. <year>2024</year>;<volume>185</volume>(<issue>12</issue>):<fpage>104795</fpage>. doi:<pub-id pub-id-type="doi">10.1016/j.jpdc.2023.104795</pub-id>.</mixed-citation></ref>
<ref id="ref-16"><label>[16]</label><mixed-citation publication-type="journal"><person-group person-group-type="author"><string-name><surname>Baracaldo</surname> <given-names>N</given-names></string-name>, <string-name><surname>Joshi</surname> <given-names>J</given-names></string-name></person-group>. <article-title>An adaptive risk management and access control framework to mitigate insider threats</article-title>. <source>Comput Secur</source>. <year>2013</year>;<volume>39</volume>:<fpage>237</fpage>&#x2013;<lpage>54</lpage>.</mixed-citation></ref>
<ref id="ref-17"><label>[17]</label><mixed-citation publication-type="journal"><person-group person-group-type="author"><string-name><surname>Dia</surname> <given-names>OA</given-names></string-name>, <string-name><surname>Farkas</surname> <given-names>C</given-names></string-name></person-group>. <article-title>Risk aware query replacement approach for secure databases performance management</article-title>. <source>IEEE Trans Dependable Secure Comput</source>. <year>2015</year>;<volume>12</volume>(<issue>2</issue>):<fpage>217</fpage>&#x2013;<lpage>29</lpage>. doi:<pub-id pub-id-type="doi">10.1109/tdsc.2014.2306675</pub-id>.</mixed-citation></ref>
<ref id="ref-18"><label>[18]</label><mixed-citation publication-type="journal"><person-group person-group-type="author"><string-name><surname>Iftikhar</surname> <given-names>N</given-names></string-name>, <string-name><surname>Rehman</surname> <given-names>MU</given-names></string-name>, <string-name><surname>Shah</surname> <given-names>MA</given-names></string-name>, <string-name><surname>Alenazi</surname> <given-names>MJF</given-names></string-name>, <string-name><surname>Ali</surname> <given-names>J</given-names></string-name></person-group>. <article-title>Intrusion detection in NSL-KDD dataset using hybrid self-organizing map model</article-title>. <source>Comput Model Eng Sci</source>. <year>2025</year>;<volume>143</volume>(<issue>1</issue>):<fpage>639</fpage>&#x2013;<lpage>71</lpage>. doi:<pub-id pub-id-type="doi">10.32604/cmes.2025.062788</pub-id>.</mixed-citation></ref>
<ref id="ref-19"><label>[19]</label><mixed-citation publication-type="journal"><person-group person-group-type="author"><string-name><surname>Alevizos</surname> <given-names>L</given-names></string-name>, <string-name><surname>Eiza</surname> <given-names>MH</given-names></string-name>, <string-name><surname>Ta</surname> <given-names>VT</given-names></string-name>, <string-name><surname>Shi</surname> <given-names>Q</given-names></string-name>, <string-name><surname>Read</surname> <given-names>J</given-names></string-name></person-group>. <article-title>Blockchain-enabled intrusion detection and prevention system of APTs within zero trust architecture</article-title>. <source>IEEE Access</source>. <year>2022</year>;<volume>10</volume>(<issue>2</issue>):<fpage>89270</fpage>&#x2013;<lpage>88</lpage>. doi:<pub-id pub-id-type="doi">10.1109/access.2022.3200165</pub-id>.</mixed-citation></ref>
<ref id="ref-20"><label>[20]</label><mixed-citation publication-type="journal"><person-group person-group-type="author"><string-name><surname>Saquetti</surname> <given-names>M</given-names></string-name>, <string-name><surname>Canofre</surname> <given-names>R</given-names></string-name>, <string-name><surname>Lorenzon</surname> <given-names>AF</given-names></string-name>, <string-name><surname>Rossi</surname> <given-names>FD</given-names></string-name>, <string-name><surname>Azambuja</surname> <given-names>JR</given-names></string-name>, <string-name><surname>Cordeiro</surname> <given-names>W</given-names></string-name>, <etal>et al</etal></person-group>. <article-title>Toward in-network intelligence: running distributed artificial neural networks in the data plane</article-title>. <source>IEEE Commun Lett</source>. <year>2021</year>;<volume>25</volume>(<issue>11</issue>):<fpage>3551</fpage>&#x2013;<lpage>5</lpage>. doi:<pub-id pub-id-type="doi">10.1109/lcomm.2021.3108940</pub-id>.</mixed-citation></ref>
<ref id="ref-21"><label>[21]</label><mixed-citation publication-type="journal"><person-group person-group-type="author"><string-name><surname>Mai</surname> <given-names>T</given-names></string-name>, <string-name><surname>Garg</surname> <given-names>S</given-names></string-name>, <string-name><surname>Yao</surname> <given-names>H</given-names></string-name>, <string-name><surname>Nie</surname> <given-names>J</given-names></string-name>, <string-name><surname>Kaddoum</surname> <given-names>G</given-names></string-name>, <string-name><surname>Xiong</surname> <given-names>Z</given-names></string-name></person-group>. <article-title>In-network intelligence control: toward a self-driving networking architecture</article-title>. <source>IEEE Netw</source>. <year>2021</year>;<volume>35</volume>(<issue>2</issue>):<fpage>53</fpage>&#x2013;<lpage>9</lpage>. doi:<pub-id pub-id-type="doi">10.1109/mnet.011.2000412</pub-id>.</mixed-citation></ref>
<ref id="ref-22"><label>[22]</label><mixed-citation publication-type="book"><person-group person-group-type="author"><string-name><surname>Shostack</surname> <given-names>A</given-names></string-name></person-group>. <source>Threat modeling: designing for security</source>. 1st ed. <publisher-name>Hoboken, NJ, USA: John Wiley &#x0026; Sons, Inc.</publisher-name>; <year>2014</year>. ISBN-13: 978-1-118-80999-0.</mixed-citation></ref>
<ref id="ref-23"><label>[23]</label><mixed-citation publication-type="journal"><person-group person-group-type="author"><string-name><surname>Yan</surname> <given-names>J</given-names></string-name>, <string-name><surname>Zhou</surname> <given-names>H</given-names></string-name>, <string-name><surname>Wang</surname> <given-names>W</given-names></string-name></person-group>. <article-title>Intelligent network element: a programmable switch based on machine learning to defend against DDoS attacks</article-title>. <source>Inf Syst Front</source>. <year>2025:1&#x2013;20</year>. doi:<pub-id pub-id-type="doi">10.1007/s10796-024-10577-9</pub-id>.</mixed-citation></ref>
<ref id="ref-24"><label>[24]</label><mixed-citation publication-type="other"><person-group person-group-type="author"><string-name><surname>Man</surname> <given-names>L</given-names></string-name>. <collab>LiliMpro/source_dataset [Internet]; 2022</collab></person-group> <article-title>[cited 2025 Aug 26]</article-title>. Available from: <ext-link ext-link-type="uri" xlink:href="https://github.com/liliMpro/source">https://github.com/liliMpro/source</ext-link>.</mixed-citation></ref>
</ref-list>
</back></article>