Zero-Trust Security Authentication Based on SPA and Endogenous Security Architecture

Abstract

Zero-trust security architecture reconstructs the trust foundation of access control based on authentication and authorization by continuously authenticating the terminal during the authentication process and not relying solely on geographic location/user attributes as the sole basis for the trust assessment. However, due to the fine-grained verification of identity under the zero-trust security architecture, there is a need for multiple authentication and authorization processes. If a single policy engine has unknown vulnerabilities and unknown backdoors to be maliciously attacked, or DDOS attacks initiated by known vulnerabilities cannot be prevented, the policy engine based on this control center architecture cannot meet the requirements of system security and reliability. Therefore, it is proposed to apply the SPA single-package authorization and endogenous security architecture to the zero-trust authentication system, which can realize the reliability, dynamism and diversity of system defense. Through the experimental antiattack analysis and antiattack test, the test from the proposed scheme found that when the system introduces the endogenous security architecture, the security of the system can be improved due to the complexity of the attack process and the increase in the cost of the attack. The test through both the security and system overhead found that the scheme can effectively improve the security of the system while ensuring the quality of network services, compared to the traditional scheme. It was found that the scheme can effectively improve the security of the system while ensuring the quality of network services and has better adaptability than the traditional zero-trust authentication scheme.

1. Introduction

As a new type of network security architecture, zero-trust architecture (ZTA) was proposed by Forrester analyst John Kindervag in 2010 [1], driving the idea of ZTA in the context of “cybersecurity isolation across location and hosting models”. In 2019, the United States Department of Defense (DoD) released the “DoD Information Resource Management Strategic Plan FY19-23” [2], which prioritizes Artificial Intelligence and zero-trust security. In February 2020, the National Institute of Standards and Technology (NIST) released the “NIST.SP.800-207-draft2 zero-trust Architecture” [3], proposing three technical solutions “SIM” for the zero-trust security concept: SDP (Software Defined Perimeter), IAM (Identity and Access Management), MSG (Microsegmentation).

With the increasingly obvious weaknesses of the traditional boundary-based network security protection architecture, domestic research on ZTA tends to increase. At the Zero-Trust Development Trend Forum held on 14 May 2021, the Tencent Research Institute, Tencent Security and Gartner jointly released the white paper “Building Trust with Zero Trust—Reinventing the New Boundary of Security” [4] to help enterprises understand and accept the zero-trust framework. The idea of zero-trust states that user roles/devices should not be used as fixed criteria for identity authentication and trust should not be granted implicitly. A dynamic real-time assessment of identity authentication should be conducted based on the system state, following the principle of “Never Trust, Always Verify”. For each authorization request of a user, identity authority and responsibility authentication should be performed, and the user information, device information and policy information in the database should be dynamically evaluated to grant the minimum authority required to perform the task. In view of the characteristics of the zero-trust system, the correct and secure authentication of identity is the key to the ZTA.

In this paper, we investigate this recent trend in the common vulnerabilities in zero-trust authentication-based architectures. We propose an effective defense called the Mimic Authentication Strategy System (MAS) to resolve security issues during multiple authentications. In particular, we use dynamic heterogeneous redundancy (DHR) architecture [5,6] to refactor the zero-trust authentication architecture and use heterogeneous components for system components to avoid the hazards of common vulnerabilities. Additionally, we use Single Packet Authorization (SPA) to address the risk of DDOS attacks on our system. With the MAS authentication system built, we can perform secure and effective identity authentication and further enhance the active defense capability of the system.

Contributions. In summary, this paper proposes the following contributions:

(1)

For the policy engine construction method under zero-trust authentication architecture, we used heterogeneous components to realize the policy engine construction through operating systems, web servers, databases, etc., which can avoid the hazard of common vulnerabilities of system components.

(2)

We proposed a novel authentication system, the MAS, which is based on SPA and endogenous security architecture, to achieve a secure construction of the authentication system. The evaluation results showed that the MAS can effectively avoid DDOS attacks and malicious attacks based on unknown vulnerabilities.

(3)

We experimentally verified the feasibility of the MAS, mathematically reasoned about the system security and provable security through attack resistance analysis and demonstrated, through attack resistance testing, that the system can achieve the goal of a security authentication system without taking up too many resources and bandwidth.

The remainder of this paper is organized as follows: In Section 2, we provide the background of the development of ZTA and the related work. In Section 3, we compare the difference between MTD and the MAS. In Section 4, we analyze the problems and threat models in the zero-trust authentication system. In Section 5, we detail the MAS architecture and its implementation and evaluation. In Section 6, we express a safety analysis on the proposed model improvement program, and we also test the security of the MAS in the attack resistance test. Finally, we conclude and propose future work in Section 7.

2. Related Work

The Traditional Network Access Control (NAC) system [7] is mainly based on the idea of border security [8,9]; zero-trust security, on the other hand, focuses on real-time authentication [10,11,12,13]. Zero-trust security architectures are combined and used in the Internet of Things [14,15,16,17], medicine [18] and cloud computing [19] due to the ability to meet the current security needs in networks, and there are related studies that use zero-trust security architectures in 6 G network architectures as well [20,21]. Some recent studies [22,23,24,25,26,27] on cybersecurity have also discussed issues regarding network architecture and DDOS attacks.

The Software-Defined Boundary (SDP) [28,29] as an implementation of zero-trust security architecture is more capable of enhancing the security of the access control process compared to the traditional NAC system [30], while the SDP is able to defend against DDOS attacks [31,32] for the infrastructure. Among the issues considered in zero-trust security architectures, a dynamic evaluation of trust [33] and the proper authentication of identity [34] are the most important, but with existing architectures, due to the fine-grained authentication of identity, the system can be subject to DDOS attacks based on known vulnerabilities or malicious attacks based on unknown vulnerabilities. The RTPM protocol is used to extend session security beyond the authentication phase, combining techniques such as Artificial Intelligence (AI) [35] to optimize the authentication scheme.

Ferretti et al. [36] studied the application of Byzantine Fault Tolerance (BFT) techniques to the construction process of zero-trust system components. The idea is innovative but does not take into account the common vulnerabilities between system components. Our previous paper [37] proposed to use the DHR architecture in a zero-trust architecture, but since the system did not make a defense scheme against DDOS attacks and also did not modify the authentication specific process, it could be subject to malicious attacks, which is the starting point of the work proposed in this paper.

3. MTD Defense Method Compared with MAS

Moving target defense (MTD) is a theory and method proposed by the National Science and Technology Council based on the ideas of dynamization, randomization and diversification to transform the existing information system defense defects. Its core idea is dedicated to building a dynamic, heterogeneous and uncertain cyberspace target environment to increase the attacker’s attack difficulty and to counter cyber attacks with the randomness and unpredictability of the system.

Network hopping as a defense method to effectively resist active scanning is one of the key technologies to achieve moving target defense. The use of protocol codes, configurations and states such as IP addresses and ports, operating system fingerprints and other information, to achieve the continuous and dynamic transfer of the network attack surface of the protected system to lure, confuse and obfuscate the detection of attackers, increases the difficulty of exploiting vulnerabilities and backdoors, increases the difficulty and cost of attacks and achieves the purpose of securing the target system. However, there are some problems with the existing network hopping technology:

• A lack of awareness of malicious scanning strategies by the hopping mechanism leads to blindness in the selection of hopping defense strategies;
• The poor effectiveness of hopping defense due to limited hopping space and a fixed hopping period;
• The poor availability and scalability of network hopping defense due to a lack of constraints on hopping implementation and high deployment complexity.

Mobile Target Defense implements security policies at the system and software levels and achieves multilevel active changes to the network system in a defender-controllable manner through network hopping to achieve security defense.

The MAS is based on the mimetic network system and dynamic heterogeneous redundancy building in many aspects of the network architecture, key devices and protocol system to achieve multistructural redundancy not only at the software level but also at the hardware architecture level, thus greatly increasing the difficulty for attackers to reach the attack surface and penetrate the execution components and thus nonlinearly and greatly improving the defense capability in the cyberspace.

4. Threat Models and Attack Scenarios

In an authentication system, an attacker wants to gain unauthorized access to some resources of the target system, such as information stored by users in a database or in a signature key. In the current real-world attack scenario and environment considered by the zero-trust model, the attacker may be an external threat that does not own a device registered in the device inventory (identity database) or registered in the user/group database. The attacker could also be an internal threat [36], such as a disgruntled employee or a malicious infiltrator social worker who exploits their own identity peculiarities to directly bypass the border protection device and attack the policy engine and who owns a managed device that is registered in the device inventory and is registered in the user/group database. At the same time, there are unknown loopholes in the system itself, and the system designer may have reserved system backdoors for some reason. These situations can no longer be defended against based on traditional authentication security defenses, and they need to be analyzed for the security of authentication and authorization components.

When an attacker gains access to trusted devices inside the system, there can be a variety of threats, such as frequent authorization requests to the policy engine for a short period of time through these machines as a springboard, producing an effect equivalent to a DDOS (Distributed Denial of Service) attack and resulting in a system policy formulation failure. As a single sign-on authentication system, an attacker may bypass any authentication and authorization logic by compromising the confidentiality of the single sign-on signature key, which allows the attacker to sign any authentication token and thus simulate an already registered user while simulating access to the proxy server’s device. When an attacker successfully attacked or mimicked the access proxy or policy engine, they can then control the verification process of the single sign-on signature key, resulting in errors in the system authentication service.

5. Mimic Authentication Strategy System

5.1. System Architecture Design

The MAS is an improvement in the policy engine in the original zero-trust security architecture. The principle of the transformation is to introduce an authentication system based on DHR architecture [6] and then heterogenize the policy engine and trust evaluation database in the zero-trust authentication architecture to increase the dynamism, heterogeneity, diversity and randomness of the system. Through the heterogeneous processing of the policy engine, the problem of common vulnerability collaborative attacks that frequently occur in the homogeneous architecture is solved. Through the collective verification mechanism of multi-PE for the signature key in the single sign-on system, the confidentiality of the entire authentication process is guaranteed. The integrity of the specific system architecture is shown in Figure 1.

The MAS uses Single Packet Authorization to access the controlled devices under the zero-trust authentication system. According to the analysis of the attacker’s behavior in Section 3, when an attacker uses a trusted device inside the system as a jump server, frequently sending resource requests to the policy engine, it will affect the real-time bandwidth and connectivity of the system, which is often referred to as a DDOS attack. The problem of first packet trust is to consider how to allow only trusted connections and discard all other connections without responding to any unauthenticated data packet, which is usually solved by preauthentication. As shown in Figure 2, the port knockdown daemon is used for the real-time management of open ports, and port knockdown is required for service requests before each user makes a service request. SPA is a lightweight security protocol [38] that verifies the identity of a device or user before allowing access to the network on which the relevant system components such as controllers or gateways reside. Under the SPA protocol, various applications and network services are hidden behind the system firewall. The firewall defaults to discard all incoming unauthenticated TCP and UDP packets and does not respond to unconfirmed connection attempts. For potential attackers inside and outside the system, they can only access the requested service application after the first packet authorization verification because they cannot know which ports of the system service are open or listened to.

The zero-trust authentication architecture is mainly composed of a policy execution component, a policy engine, a trust engine and a data storage system. As shown in Figure 3, the MAS implementation completes permission grant determination by heterogenizing the policy engines by using different hardware and software to constitute the access control engines with the same authorization verification function; additionally, it also evaluates trust levels based on different database information. For resource applications submitted by users, the heterogeneous policy engines use:

• Different authentication methods;
• A heterogeneous operating environment;
• Different databases;
• Different scoring weights for policy development;
• The difference in the syntax of the establishment policy engine.

In the process of designing the heterogeneous authentication policy engine, by choosing different operating systems such as Windows, Centos, Ubuntu, etc., the system service software runs different web server software such as Apache(Apache version 2.4, Brian Behlendorf: Urbana Champagne, US)), Nginx(Nginx version 1.12.2, Igor Sysoev: Russia), IIS(IIS version 10.0, Microsoft: Redmond, US)), etc., and uses different compiled/interpreted languages such as C/C++, JAVA, Python and Golang to implement different writing methods to execute programs with the same function; then, it selects different compilers and diverse compilation methods to perform heterogeneous processing from the aspect of the operating environment, increasing the difficulty of performing a system analysis on the heterogeneous policy engine while disrupting the malicious attacker from detecting the system information which, in the attacker’s view, is in a state of dynamic change. Since different software and hardware are used to build the authentication policy engine, the possibility of attackers using common vulnerabilities to carry out coordinated attacks is greatly reduced, and the backdoor problem of unknown vulnerabilities that may exist in the system design process is solved.

When the user group database is compromised and leaked by a malicious attacker, personal information such as passwords stored by the user will be stolen. At the same time, the attacker can add the user/device controlled by himself to the legitimate database, which is convenient for bypassing the system authentication logic next time. The heterogeneous database is used in the MAS as the source of authentication information for the system, and database management systems such as MySQL(MySQL version 8.0, Michael Widenius: Sweden), Oracle(Oracle version 19c, Larry Ellison: State of California, US) and DB2(DB2 version DB2 Express Edition, IBM: US) are used as heterogeneous database service sets and provide APIs (Application Programming Interfaces) for multiple programming languages to facilitate the system management data.

In the MAS implementation, the heterogeneous policy engine establishes digital portraits for users by implementing different user role authentication methods to verify the user’s identity more accurately and quickly and provide resource application services. Multiple heterogeneous bodies use different authentication methods, which include a one-time password, dynamic password authentication and multifactor authentication to verify user identity from different perspectives and ensure avoiding the risk of online trawling attacks that exist with single password authentication.

The identity authentication evaluation system under the ZTA performs a single trust level evaluation for the information fed back from the database, which has the risk of implicit trust. The MAS implementation avoids policy bias by changing the scoring weight of different heterogeneous executors for the policy, as shown in the following

Table 1. Diversity policy engine.

Factor	Behavioral Elements	Score	Security Level
Policy	Login and query times	60	Medium
	Access to sensitive servers	85	High
	Number of guesses for username/password	80	Medium high
	Modify file permissions	85	High
	Number of port scans	80	Medium high
	Number of leapfrog operations	95	Very high
	Number of threads created	60	Medium
	Change system settings	90	Very high
	Continuous authentication failures	85	High
Language	Writing Language	Compiler	Efficiency Score
	C/C++	GCC	85
	Java	Eclipse	80
	Python	PyCharm	75

according to the different behaviors of users:

• Different scoring weighting mechanisms for the same type of request authorization behavior;
• Different scoring weighting mechanisms for different types of request authorization behaviors;
• Different syntax for building policy engines.

Based on the MAS architecture proposed above, the system operation framework is shown in Figure 4. The system is controlled by the policy engine heterogeneous layer, the executive information adjudication and feedback layer and the trust evaluation layer.

5.2. Certification Process Analysis

The workflow of the MAS implementation is shown in Figure 5. When a user submits a resource request, the controlled device first uses single-package authorization to verify the user’s device identity and then sends the request to the access proxy after passing the verification. The access proxy serves as a reverse proxy server and forwards the user request to the service queue of the heterogeneous policy engine in the system. Each heterogeneous executor uses the identity authentication method formulated in advance to authenticate the user and returns the result to the consistency adjudicator for judgment and allocates the resources requested by the user after passing the verdict.

After the heterogeneous policy engine has processed the user authentication process, the results of each executor are sent to the response consistency adjudicator for adjudication, and a suitable adjudication scheme is selected according to the user’s historical personal behavior, such as large number adjudication, consistency comparison, weight judgment and iterative judgment methods. After the adjudicator adjudicates the results of each heterogeneous executor, if the user request verification is passed, the resource will be allocated to the controlled device, which forwards it to the requesting user, and if the user identity verification fails, the resource request will be rejected.

6. Experiment Analysis

6.1. Attacker–Defender Game Analysis

For user data, when attackers exploit database data from different sources, or incompletely deleted data are leaked, or the data backup file system is attacked, it may lead to the loss of critical system data. The security threat transfer is a stochastic process, which can be modeled as a Markov chain (MC) for attack state transfer analysis. The core idea of an MC is that the probability of state transition at the current moment depends only on the state at the previous moment. In security analysis, the probability of transitioning from the current executor state to other states depends on the type and number of vulnerabilities in the current state, as well as the number of common attack vulnerabilities on which the attacker relies.

Modeling from the attacker view, the probability of transitioning from one system state to another depends on the presence of vulnerabilities in the current state, and the attacker attempts to transition from the system protected state $P$ to the attacked state $A$ and finally to the system failure state $E$. Figure 6 depicts the modeling of security threats as Markov models with state transfer probabilities. The attacker attacks the authentication system to make it transition from the protected state $P$ to the attacked state $A$ with a probability $\alpha$, while the state $A$ may return to the state $P$ by the instantaneous probability $\delta$ of the protective measures or further transition to the failure state $E$ with instantaneous probability $\beta$. In order to facilitate the analysis, this process is described by the mimic defense Markov game model, which can define a quintuple $\left\{C,S,\psi ,P,W\right\}$ suitable for the game analysis of the MAS.

$i$ represents malicious attackers and system defenders in the authentication system.

$S=\left\{S_0,S_1\cdots S_i,S_{i+1}\right\}$ are possible states during the attack and defense of the system, $S_0$ is the initial state of the system and each state transition is only related to the previous state.

$\psi =\left\{\xi ,\phi \right\}$ is the probability set of actions taken by both the attacker and the defender, ${\xi }_i\left(a\right)$ denotes the probability that a malicious attacker in the system takes an action $a$ in state $i$ and ${\phi }_i\left(d\right)$ denotes the probability that the defense system in the system takes action $d$ in state $i$.

$P=\left\{P^1,P^2\cdots P^i,P^{i+1}\right\}$ is a complete transition process of a single executor from state $P$ to state $E$ and $P^i$ denotes the transition process probability of an attacker breaking the transition process of multiple executors at a time. $P_{i,j}^1$ denotes the complete transition process of a single executor system from path $i$ to $j$ state from $P$ to $E$.

$W=\left\{W_1,W_2\cdots W_i,W_{i+1}\right\}$ $\to$ is the combination of executor service sets available to the system.

Given the policy combination $\left\{\xi ,\phi \right\}$ and instantaneous probability ${\xi }_i\left(a\right)={\eta }_i$, ${\phi }_i\left(d\right)={\lambda }_i$, the state transition probability of the Markov chain can be expressed as the following formula:

$$P_{i,j}=P\left\{S_{q+1}=S_j|S_q=S_i\right\}=\sum P_{i,j}\left(a,d\right){\xi }_i\left(a\right){\phi }_i\left(d\right)=\sum P_{i,j}\left(a,d\right){\eta }_i{\lambda }_i$$

(1)

The best case of the game between attacker and defender under the MAS is defined as:

$$S{R}^d={\zeta }^{*d}:\underset{{\zeta }^h}{\min }\underset{{\zeta }^d}{\max }{U}^d\left({\zeta }^h,{\zeta }^d\right)=\underset{{\zeta }^d}{\mathrm{argmax}}{U}^d\left({\xi }_i\left(a\right),{\phi }_i\left(d\right)\right)$$

(2)

where $S{R}^d$ denotes the best case of the attacker–defender in the current state of the system, ${\zeta }^h$ denotes the measures taken by the malicious attacker and ${\zeta }^d$ denotes the measures taken by the system defender.

In the process of system state transition from $i$ to $j$, the multistep probability formula is:

$$P_{i,j}\left(m+n\right)=P_{i,j}^{m+n}=\sum P_{i,k}^m{P}_{k,j}^n$$

(3)

For the existence of multiple vulnerability exploitation paths in a single executor, there are multiple attack paths from the protected state $P$ to the attacked state $A$, and the transition formula is:

$${\alpha }_i=\frac{{{\displaystyle \sum }}_j{v}_{ij}}{{{\displaystyle \sum }}_{t,l}{v}_{tl}}\ast {\xi }_i\left(a\right){\phi }_i\left(d\right)=\frac{{{\displaystyle \sum }}_j{v}_{ij}}{{{\displaystyle \sum }}_{t,l}{v}_{tl}}\ast \alpha$$

(4)

The transition formula from state $A$ to state $E$ is:

$${\beta }_{ik}=\frac{{{\displaystyle \sum }}_j{v}_{ij}}{{{\displaystyle \sum }}_{t,l}{v}_{tl}}\ast {\beta }_k$$

(5)

From this, it can be calculated that the state transition formula of the system under a single executor is:

$$P_{system}=P_{i,j}=\sum P_{i,j}\left(a,d\right){\eta }_i{\lambda }_i={\displaystyle \sum }_i{\alpha }_i{\beta }_{ik}$$

(6)

The failure rate of the system in the case of a single executor obeys the exponential distribution of the failure rate $\lambda$. With the progress of the attacker’s attack process and the in-depth understanding of the system information, the probability of a successful attack leading to system failure gradually converges to one. $\lambda$ indicates the attacker’s attack strength, and when the attacker launches a targeted attack with a strong attack capability, the value of $\lambda$ is larger and the system failure rate is higher. The system failure rate can be expressed as:

$$P_{Invalid}=1-e^{-\lambda t}$$

(7)

6.2. Safety Gain Analysis

In this paper, the number of public vulnerabilities of 10 mainstream operating systems in the past 12 years is counted from the CVE (Common Vulnerabilities and Exposures) of each system’s vulnerability records. From the comparison of the data in Figure 7, one can see that for the Linux system kernel release version, the Debian system and Redhat system were largely different from the Linux system version, whereby the number of common vulnerabilities was less. It can be seen that for homogeneous/homologous systems, the likelihood of common vulnerabilities was higher, and the risk of being attacked by malicious attackers was greater. For heterogeneous operating systems, the number of public vulnerabilities was relatively low due to different system CPU scheduling management, different memory-based space allocation management procedures and different device drivers, which can effectively avoid malicious attacks caused by common vulnerability attacks.

In a single-executor system, there is a high probability of a common vulnerability in the system’s executors. However, in the MAS, due to the introduction of multiple heterogeneous executor components, the attacker needs to conduct a coordinated attack against multiple executors. The executor attack chain in the MAS is shown in Figure 8. When the attacker successfully transfers from the protected state $P^1$ of the executor $1$ to the fault state $E_1$, it cannot directly pass the authentication system, but needs to go through the next step to destroy other associated executors to achieve the purpose of system intrusion. Considering the random scheduling strategy of heterogeneous executors and the random target selection of attackers to attack, we analyzed the state of the executors:

$$Security status group P=\left\{P_1,P_2\cdots P_{n-1},P_n\right\}$$

$$Attacked state group A=\left\{A_1,A_2\cdots A_{n-1},A_n\right\}$$

$$Failure state group E=\left\{E_1,E_2\cdots E_{n-1},E_n\right\}$$

The state of the system with the executor number $1$ in the case of an attacker’s attack is $S_1=P_1\left|A_1\right|E_1$, from which the overall state of the system can be obtained:

$$S^{*}=\left\{S_1,S_2\cdots S_{n-1},S_n\right\}=\left\{P_1\left|A_1\right|E_1,P_2\left|A_2\right|E_2\cdots P_{n-1}\left|A_{n-1}\right|E_{n-1},P_n\left|A_n\right|E_n\right\}$$

(8)

From the analysis in Section 6.1, the probability of a single executor $i$ from the protected state $P_i$ to the fault state $E_i$ is:

$$P_{S_i}={\displaystyle \sum }_i{\alpha }_i{\beta }_{ik}$$

(9)

The probability of the system being breached after introducing the MAS idea can be expressed as:

$$P_{Security}=\frac{P_{W_l}\left({{\displaystyle \prod }}_l{P}_{S_l}-\frac{{{\displaystyle \sum }}_{i=1}^{l}CVSS\left({\kappa }_i\right)}{SC{R}_l}\right)}{\raisebox{1ex}{$A_m^l$}\!\left/ \!\raisebox{-1ex}{$\sum t_i$}\right.}=\frac{P_{W_l}\left({{\displaystyle \prod }}_l{{\displaystyle \sum }}_l{\alpha }_l{\beta }_{lk}-\frac{{{\displaystyle \sum }}_{i=1}^{l}CVSS\left({\kappa }_i\right)}{SC{R}_l}\right)}{\raisebox{1ex}{$A_m^l$}\!\left/ \!\raisebox{-1ex}{$\sum t_i$}\right.}$$

(10)

$P_{Security}$ indicates that after the introduction of the idea of the MAS, since a heterogeneous policy engine is used to form the system authentication executor, the attacker needs to complete a series of single-step attacks on the executor $P_{S_l}$ and then complete the sequence attack effect. It needs to be consistent with the executor service set $P_{W_l}$ currently selected by the system. $CVSS\left({\kappa }_i\right)$ indicates that according to the Common Vulnerability Scoring System (CVSS) in the National Vulnerability Database (NVD), the calculated vulnerability score, $SC{R}_l$, indicates the normalized sum value of the system vulnerability score in the range of 0.0–10.0.

Therefore, it can be seen from the above analysis that after the introduction of the heterogeneous policy engine, the security gain of the system is

$${\sigma }_{security}=\frac{1-P_{Security}}{1-\underset{1\le i\le n}{\min }{P}_{S_i}}=\frac{1-P_{Security}}{1-P_{Invalid}}=\frac{1-P_{Security}}{e^{-\lambda t}}$$

(11)

6.3. Experiment Environment

The verification method of this experiment uses the physical machine deployment experiment, the SPA tool FWKNOP to perform port knocking (PK), the Nginx reverse proxy service to forward the authorization request service, the Docker container technology to build the heterogeneous policy engine service pool, and an algorithm to make output judgments to complete the entire request process.

The advantages of using these tools/techniques are as follows:

• FWKNOP, as an open-source and mature tool for single-packet authorization and port probe, is used to hide system services. By encrypting a single data packet, replay attacks are avoided and the authentication credentials are hash encoded (MD5, SHA-256, SHA-512, etc.), so to authenticate via HMAC, the workload needs to do less than a single-decrypt SPA packet. At the same time, the server side of FWKNOP acts as a front-end proxy under the whole system, blocking all service traffic that has not been authorized by a single package, preventing the system from being damaged by DDOS attacks;
• As a free, open-source, high-performance HTTP server and reverse proxy server, Nginx can realize the function of service request forwarding and the load balancing effect by setting the Nginx configuration file. Compared with the forward proxy, the deployment location of the reverse proxy server is closer to the source server, which makes it easier to control and centralize permissions;
• Docker, as an open-source application container engine, adopts the sandbox mechanism, and each container is independent of each other without any interface. The performance overhead of containers is extremely low and it is simple and easy to use compared to VMware or VirtualBox. The image shared by the Docker community is very easy to use to deploy containers, and it can be built locally, deployed to the cloud at any time and can be run anywhere. At the same time, it is very convenient to manage Docker containers using container cluster management tools such as Kubernetes, Docker Swarm and OpenShift.

6.4. Experiment Procedure

6.4.1. System Information

The topology of this experimental system is shown in the following Figure 9:

First, the client (192.168.73.135) uses SPA single-packet authorization and authentication, sends an access request to the controlled device (192.168.73.134), which forwards the message to the access proxy (192.168.73.7). The access proxy processes the access request, and the message backup refers to the $nginx.conf$ configuration file in the access agent Nginx server for message distribution and sends it to the heterogeneous policy engine (192.168.73.25-27) composed of the Docker container pool, and the Docker container pool host IP is 192.168.73.20. Among them, the heterogeneous policy engine realizes the purpose of the heterogeneous system executor through the difference in the software stack composition. After that, each heterogeneous policy engine performs a trust evaluation by accessing the system database according to its own developed scoring mechanism and sends the respective evaluation results to the adjudicator (192.168.73.202). Finally, the adjudicator makes a consensus decision based on the majority voting algorithm and feeds back the decision result to the controlled device, and then the controlled device responds to the client with a resource response.

When the user creates an authentication/authorization request, the request is sent to a controlled device with a trust certificate, and the controlled device uses the private key $s{k}_{MD}$ to sign and generate a signature ${\sigma }_{MD}$. Then, it sends the user request $re{q}_u$ and the signature ${\sigma }_{MD}$ together to the access proxy, and the access proxy is responsible for forwarding it to the heterogeneous policy engine (HPE) for authentication. The HPE verifies the received signature ${\sigma }_{MD}$ through the public key $p{k}_{MD}$ of the controlled device, the user’s request is signed using the private key $s{k}_{HPE}$ of the heterogeneous policy engine after the verification is passed and ${\sigma }_{HPE}$ is sent to the resource agent for resource application. After the resource agent uses $p{k}_{HPE}$ to verify the signature, if the signature is valid, the resource request $re{q}_r$ is forwarded to the resource, and after the resource response $resp$ is generated, the resource agent uses the controlled device public key $p{k}_{MD}$ to encrypt the response $resp$ and generate the ciphertext $c$. Finally, the resource agent signs the response and sends it to the access proxy. The access proxy forwards the response content to the controlled device to verify whether it is the resource request submitted by the user and finally decrypts the ciphertext $c$ using $s{k}_{MD}$ to obtain the resource response reply.

The detailed system information of each component in the system and the heterogeneous policy engine in the Docker container pool is shown in the following

Table 2. System component information.

No.	Server Name	IP	Software Stack Composition	Image/Container
1	Controlled Device	192.168.73.134	Centos 7 + Apache + Redis + PHP	CD_Centos
2	Access Proxy	192.168.73.7	Ubuntu + Nginx + MySQL + C++	AP_Ubuntu
3	Policy Engine 1	192.168.73.25	Debian + Apache + Oracle + JAVA	PE_Debian_Docker1
4	Policy Engine 2	192.168.73.26	Fedora + Lighttpd + MariaCB + Python	PE_Fedora_Docker2
5	Policy Engine 3	192.168.73.27	RedHat + Tomcat + Sqlite + C++	PE_RedHat_Docker3
6	Adjudicator	192.168.73.202	Windows + IIS + SQL server + NET	Adjudicator_Windows

:

The software stack consists of {operating system, web server, database, policy language} for heterogeneous implementation. The analysis in Section 6.2 above showed that Debian and Redhat contained different versions of Linux systems with fewer common vulnerabilities, and the policy engine is mainly built by these two Linux systems.

6.4.2. SPA (Single Package Authorization)

The above Table is an example of an SPA data packet. After combining the information, the authentication credentials are encrypted twice using the hash algorithm to generate a message digest. The SPA information has the timestamp of the creation of the message, so for requests of different time periods, the hash code value is different, thus ensuring that each access needs to be authorized. An example of SPA information as shown in

Table 3. SPA information example.

Message Name	Parameter Value
Local Username	chris
Local Timestamp	202204121724
Client IP	192.168.73.135
Verify Password	ZzuP@ss_Word
Hash-Encoded Value (MD5)	(“chris: 202204121724:192.168.73.135:ZzuP@ss_Word”) = e30316234dd806f64026fa52dc67d627

:

As shown in Figure 10, after the client executes the fwknop client access command, the generated authentication credentials and message digest can be checked through the .fwknop file in the/root directory and can be copied to to/etc/fwknop/access on the server side.

The following Figure 11 is the system-recording process of a complete SPA certification during the experiment:

By default, after the client performs the fwknop authentication, the port will be closed again after being opened for 30 s. When it needs to be accessed again, reauthenticating the system will be needed. As shown in the following Figure 12, the authentication rules of fwknop are shown:

6.4.3. Request Processing and Distribution

The access proxy server (192.168.73.7) contains the access information of each heterogeneous policy engine, configures the distribution address through the Nginx reverse proxy, configures the IP and port of the policy engine server in the upstream module and configure the main listening port and response behavior in the server module; the Nginx proxy server information in the experiment is listed in

Table 4. Policy engine information.

Upstream Server	IP	PORT
PE_Debian_Docker1	192.168.73.25	8080
PE_Fedora_Docker2	192.168.73.26	8080
PE_RedHat_Docker3	192.168.73.27	8080

.

The server then performs request processing through the prewritten Zzu_delivery program, obtains the Docker container pool information according to the configuration information in nginx.conf, verifies that the requester is the controlled device (192.167.73.7) and then makes a service request. As shown in Figure 13:

As shown in Figure 14 above, initializing the system environment is a process for the access proxy to clean up the access traces. By deleting the last access request information in the database, it avoids the problem of implicit trust in the system and ensures that each user request access is an independent process. After verifying the identity of the requester, the system processes the access request and sends it to the heterogeneous policy engines (PE1, PE2, PE3). After each policy engine processes the access request, it sends the processing result to the consistency adjudicator (192.168.73.202) and the distribution process ends.

6.4.4. Information Judgment

After receiving the authentication results from the heterogeneous policy engines PE1, PE2 and PE3, the adjudicator collates them uniformly and then makes an adjudication according to the pre-established adjudication policy, as shown in the following

Table 5. PE information processing.

No.	Server Name	IP	Port	Result
1	PE_Debian_Docker1	192.168.73.25	8080	Authorization verification passed
2	PE_Fedora_Docker2	192.168.73.26	8080	Authorization verification passed
3	PE_RedHat_Docker3	192.168.73.27	8080	Authorization verification passed

.

Where the entire system processing is shown in the following procedure. The distribution of the adjudicator can be centralized or distributed. The position of the adjudicator in this experiment was located after each policy engine, and the unified centralized adjudication approach was adopted. Considering that the increase in the number of adjudications will affect the response latency of the system, the process of adjudication should be reduced as much as possible while improving the security. The selection of the adjudication method is based on the security requirements of the system. In the authentication system, the security requirement is very high. Therefore, the $Consensus-Voting$ method was adopted, as shown in Algorithm 1. It can be seen from Table 5 that the heterogeneous policy engines in the current service set all determined that the access request was passed, allowing the resource response reply to be sent to the client.

Algorithm 1. Consensus voting.

Consensus—Voting

Input: client request parameters ClientRequest and authentication key ClientSecret

begin

If get client requests

// First authenticate the user’s identity and perform security checks

Processed_Auth=Id_Authentication(ClientSecret)

// Determining user identity

If(Processed_Auth)

// Handling user request parameters

Processed_Request=Request_exec(ClientRequest)

// Send processed user requests to heterogeneous policy engines PE1, PE2, PE3

Response1=Send_to_PE1(Processed_Request)

Response2=Send_to_PE2(Processed_Request)

Response3=Send_to_PE3(Processed_Request)

// Voting on messages using a consistent voting machine

Response_to_Client=Consensus-Voting(Response1,Response2,Response3)

// Return the processing results to the controlled device

Send_to_CD(Response_to_Client)

end if

end if

end

6.5. Experiment Analysis

(1)

System failure rate

According to the antiattack analysis in the previous Section 6.1, the system failure rate is related to the attack strength of malicious attackers and whether the system undergoes mimic transformation. As shown in Figure 15, the attack strength was controlled, the number of executors was one and the number of system executors was three for the comparison experiments. The analysis of the experimental results showed that the attack strength had a great influence on the system failure rate, and when the system introduced the idea of mimic defense, the system failure rate was greatly reduced, which can have a better security defense effect.

(2)

Vulnerability Utilization

In the MAS, the time interval for the attacker to take attack measures and the time for the defender to schedule defense measures have a decisive impact in the system utilization. Based on this, experiments were conducted to change the interval period between the implementation of the attack/defense measures from. The results showed that (Figure 16) as the interval period of the measures taken by both the attacker and the defender increased, the defender took measures at a longer interval, resulting in system vulnerabilities not being discovered and patched in time, and the utilization rate of the system vulnerabilities increased; due to the increase in the interval period of the attackers, the utilization rate of the system vulnerabilities was reduced.

(3)

Attack–defense time cost

As the system scheduling cycle (i.e., the system defense policy update cycle) increases, the attacker overhead decreases, the cost of attacking the system decreases and the cost of defender measures to maintain the system decreases. The experimental results are shown in Figure 17.

(4)

Effect of the number of isomers

The experiments of the attack overhead and defense overhead were run in the proposed system in this paper with the number of heterogeneous bodies as one (nonheterogeneous system), three, five, seven and nine. It is obvious from Figure 18 that when the number of heterogeneous bodies running in the system increases, both the attack overhead and defense overhead tend to increase, but the challenge to the attacker is greater, so the significance of transforming the system into heterogeneous and mimic is obvious.

The MAS proposed in this paper, by the heterogeneous operation of the policy engine in a zero-trust authentication system, has the following advantages over traditional authentication systems:

• By introducing the SPA single-packet authorization mechanism, it ensures that the system can operate safely under DDOS attacks and the system resources are utilized stably.
• Compared with the single authentication center (policy engine) authentication system, the multipolicy engine construction method can ensure stable operation and a lower system failure rate after the attacker increases the intensity of the attack on the system.
• With the introduction of the multipolicy engine approach in the system, the defense capability of the system and the attacker’s attack overhead tend to grow nonlinearly as the number of heterogeneous bodies increases, which can improve the security defense capability of the system.

7. Conclusions

In response to the authentication request initiated by using unknown vulnerabilities and unknown backdoors, the authentication system cannot play a normal protective role, and the defective problem of single-policy engine authentication occurs. This paper proposes a zero-trust security authentication system based on SPA and endogenous security architecture, implements the MAS by designing the system architecture and applying the two techniques to the authentication process and evaluates the security problem of the system. The design experiments verified the security gain of the proposed system in the authentication and authorization process, while the system overhead was in an acceptable range. Our method also had some limitations; for example, designing heterogeneous executors in the MAS requires ensuring that they are sufficiently different, because otherwise, there may be common vulnerabilities. In a zero-trust authentication system, especially after introducing the MAS idea, multiple device authentication processes may lead to the need for frequent authentication and a poor user experience.

In the future, research can be further improved in the following aspects, including increasing the heterogeneous diversity of the system components, such as using more components with different hardware compositions or structural designs, as well as developing a more suitable authentication frequency and scheme according to the user level of trust assessment and increasing the user experience.