Network Infrastructure Security System Based on Artificial Intelligence Dynamic Encryption Key Exchange and Distributed Authentication

Abstract

The present invention relates to a network infrastructure security system for maximizing the security of communication data in an internal corporate network or a cloud-linked network. The present invention has the effect of providing a hybrid encryption infrastructure that generates and discards dynamic encryption keys based on artificial intelligence, eliminates the centralized single point of failure problem through a distributed authentication server cluster, and performs data packet-level encryption, automatic assignment of security grades per communication channel, and state-based encryption load balancing.

Description

Technology Field

[0001] The present invention relates to a network infrastructure security system for maximizing the security of communication data in an internal corporate network or a cloud-linked network. Background Technology

[0002] Traditional network security infrastructure has primarily relied on static encryption key methods, such as Hardware Security Modules (HSMs) or VPN devices. This static key structure contains a single point of failure, where a single key leak can catastrophically compromise the security of the entire network. Furthermore, in modern environments where internal corporate networks and cloud-linked networks operate in a complex manner, key management and replacement are performed manually, posing a risk of simultaneously degrading operational efficiency and security levels.

[0003] As the number of network users increases rapidly, the computational load for authentication processing and encryption is rising exponentially. Particularly in environments with high real-time traffic, such as IoT devices, mobile applications, and cloud API calls, decryption and encryption are performed based on fixed keys, leading to intensified consumption of CPU and memory resources. Consequently, this results in reduced service latency and availability. This demonstrates a structural limitation that makes it difficult to simultaneously achieve both security and performance in large-scale environments.

[0004] Furthermore, in virtualization and container orchestration environments where network configurations change frequently, centralized authentication servers often face overload, which increases the risk of authentication delays and system-wide failures. The structural limitation of concentrating authentication requests occurring simultaneously from distributed geographical locations onto a single server hinders network scalability and, consequently, causes serious bottlenecks in global service operations.

[0005] To overcome these problems, an innovative approach is required to automate the processes of encryption key generation, exchange, and revocation, decentralize authentication servers to eliminate single points of failure, and apply granular encryption policies at the data packet level. Prior art literature

[0006] U.S. Patent Application Publication US2021 / 0243028 (Aug. 05, 2021) U.S. Patent Application Publication US2024 / 0396719 (Nov. 28, 2024) The problem to be solved

[0007] The objective of the present invention is to propose a hybrid encryption infrastructure that generates and discards dynamic encryption keys based on artificial intelligence, eliminates the centralized single point of failure problem through a distributed authentication server cluster, performs data packet-level encryption, automatically assigns security grades per communication channel, and performs state-based encryption load balancing. means of solving the problem

[0008] To solve the above-mentioned problem, the present invention provides a network infrastructure security system based on artificial intelligence-based dynamic encryption key exchange and distributed authentication, characterized by comprising: a dynamic key generation module (100) that generates a one-time encryption key in real time by processing the session state, location, time, and hardware unique value using an AI algorithm when a communication session between nodes starts, and automatically discards the key when a set time or traffic volume is reached to prevent key reuse; a distributed authentication server cluster (200) that processes authentication and key exchange of various nodes in a distributed manner based on a blockchain and consensus algorithm and records the authentication results; an encryption processing unit (300) that performs data encryption and decryption by selecting an optimal encryption algorithm and key for each traffic packet; a security grade automatic assignment unit (400) that automatically assigns a security grade to a communication channel in real time according to AI-based traffic analysis and policies; and an encryption load distribution engine unit (500) that optimally distributes encryption processing by analyzing the load, computation status, and security policy of the network and nodes in real time. Effects of the invention

[0009] The present invention has the effect of providing a hybrid encryption infrastructure that generates and discards dynamic encryption keys based on artificial intelligence, eliminates the centralized single point of failure problem through a distributed authentication server cluster, and performs data packet-level encryption, automatic assignment of security grades per communication channel, and state-based encryption load balancing. Brief explanation of the drawing

[0010] FIG. 1 is a configuration diagram illustrating the overall configuration of the present invention. FIG. 2 is a detailed configuration diagram of the dynamic key generation module (100) of the present invention. Figure 3 is an example of the operation of the system of the present invention. Specific details for implementing the invention

[0011] Throughout the entire specification below, the same reference numerals refer to the same components unless there are special circumstances. Terms with the addition of "part" used below may be implemented in software or hardware, and depending on the embodiment, it is possible for a single "part" to be implemented as a single physical or logical component, for multiple "parts" to be implemented as a single physical or logical component, or for a single "part" to be implemented as multiple physical or logical components. Throughout the specification, when it is stated that a part is connected to another part, this may mean a physical connection between the part and the other part, or an electrical connection. Furthermore, when it is stated that a part includes another part, this does not mean that another part other than the other part is excluded unless specifically stated otherwise, but means that additional parts may be included at the designer's choice. Terms such as "first," "second," etc., are used to distinguish one part from another part, and unless specifically stated otherwise, they do not imply sequential expressions. Also, singular expressions may include plural expressions unless there is an obvious exception in the context.

[0013] The present invention relates to a network infrastructure security system for maximizing the security of communication data in an internal corporate network or a cloud-linked network.

[0015] In this invention, "Node" refers to an independent computing device or endpoint capable of transmitting and receiving data and processing encryption within a network infrastructure. In terms of hardware, a node is a physical device, and in terms of software, it is a logical unit comprising a program module in which the security system of this invention is implemented.

[0017] Referring to FIG. 1, the system of the present invention is configured to include a dynamic key generation module (100), a distributed certificate server cluster (200), an encryption processing unit (300), an automatic security grade assignment unit (400), and an encryption load balancing engine unit (500).

[0019] The specific details of each component are as follows.

[0021] The dynamic key generation module (100) is a dynamic security module that generates a one-time encryption key in real time by processing the session state, location, time, and hardware unique value with an AI algorithm when a communication session between nodes starts, and automatically discards the key when a set time or traffic volume is reached, thereby preventing key reuse at the source.

[0023] The dynamic key generation module (100) comprises an input information collection unit (110), a data preprocessing and integration unit (120), a key generation engine unit (130), a key storage and transmission unit (140), and a key disposal management unit (150).

[0025] The input information collection unit (110) is intended to collect various context information required for key generation in real time when the communication section between nodes starts.

[0026] The above input information collection unit (110) is responsible for systematically collecting various context information that serves as the basis for dynamic key generation. This module is activated when a communication session between network nodes begins and collects four key information categories representing the unique characteristics of the current session in real time.

[0028] Specifically, in the first step of the session state information collection process, the unique identifier of the current communication session, the session start time, and the type of communication protocol in use are identified. This information is linked with the traffic classification result received from the security level automatic assignment unit (400) and used as basic data to determine the security level required by the session. For example, in the case of a financial transaction session, a high security level is assigned and more complex key generation parameters are required, whereas a general web browsing session uses relatively simple parameters.

[0029] Secondly, in the location information collection, the IP addresses, geographical location coordinates, and current locations on the network topology of the communicating nodes are accurately identified. This location information is closely related to the node authentication process performed by the distributed authentication server cluster (200). In particular, it is used to minimize authentication latency by selecting the closest node among the geographically distributed authentication nodes, and to determine the optimal key transmission path through the network topology information.

[0030] Thirdly, during the time information collection process, precise timestamps based on UTC and high-precision time information in nanosecond units are obtained. This time information is directly connected to the key revocation management unit (150) that manages the validity of the key, accurately records the time of key generation, and serves as a standard for determining the automatic revocation schedule according to a preset validity period. It is also used as important input information for establishing a load balancing strategy by analyzing traffic patterns by time period in the cryptographic load balancing engine unit (500).

[0031] Finally, in the collection of hardware unique values, hardware-level unique identification information such as the MAC address, CPU unique identification number, memory serial number, and TPM (Trusted Platform Module) value of each node is collected. These hardware unique values ​​are utilized as a key element to verify the authenticity of the nodes in the distributed certificate server cluster (200), and at the same time function as an entropy source that increases unpredictability during the key generation process.

[0033] The data preprocessing and integration unit (120) plays a key role in converting and integrating heterogeneous raw data collected from the input information collection unit (110) into a form suitable for an AI-based key generation algorithm. This process consists of four stages: normalization of data, hash conversion, entropy enhancement, and final fusion.

[0035] The description of each step of the above data preprocessing and integration unit (120) is as follows.

[0036] In the data normalization step, input data with different ranges and scales is scaled into a uniform range between 0 and 1. For example, time information is a very large number in nanosecond units, location information is expressed in latitude and longitude, and hardware unique values ​​exist in the form of hexadecimal strings; all of these are converted into the same numerical range so that the AI ​​model used by the key generation engine unit (130) can process them in a balanced manner. During this normalization process, the normalization weight is adjusted according to the security grade information received from the security grade automatic assignment unit (400), so that more precise normalization is performed when high security is required.

[0037] In the hash preprocessing step, the SHA-3-256 algorithm is used to convert variable-length normalized data into a fixed-length 256-bit hash value. This process guarantees an output of a constant size regardless of the size or form of the input data, while simultaneously preserving the characteristics of the original data and providing unidirectionality that makes reverse calculation impossible. The generated hash value is used as a seed value when generating a key per packet in the encryption processing unit (300), serving as the basis for generating a unique encryption key for each packet.

[0038] In the entropy enhancement step, a 256-bit true random value obtained from a hardware random number generator is combined with the hash result using an XOR operation. This process maximizes the unpredictability of the final key generation material, even if a certain pattern exists in the input data. The hardware random number generator is operated under the monitoring of the cryptographic load balancing engine unit (500), and when the system load is high, it automatically switches to a software-based pseudo-random number generator to prioritize processing speed, and in situations where security is important, it uses a hardware-based true random number to maximize security.

[0039] In the final data fusion stage, entropy-enhanced data is combined multidimensionally using a weighted average algorithm. During this process, network status information and past authentication history received from the distributed authentication server cluster (200) influence the determination of weights. For example, if a specific node has had a security breach in the past, higher weights are assigned to the data related to that node to generate a stronger key.

[0041] The key generation engine unit (130) generates a high-entropy dynamic encryption key using an AI-based algorithm.

[0042] The key generation engine unit (130) is a core component that receives data preprocessed through the data preprocessing and integration unit (120) as input and generates an actual encryption key through an AI-based algorithm. This module generates a high-quality dynamic encryption key through a four-step process of neural network-based key generation, chaos map application, key strength verification, and final key length determination.

[0044] The process for each step of the key generation engine unit (130) is as follows.

[0045] In the neural network-based key generation stage, a pre-trained Generative Adversarial Network (GAN) model (AI-based algorithm) is utilized. This GAN model consists of a generator network and a discriminator network; the generator generates initial key candidates based on the input preprocessed data, and the discriminator evaluates the randomness and unpredictability of the generated keys. During this process, the complexity of the model is dynamically adjusted according to the current system load information received from the cryptographic load balancing engine (500). When the system load is high, a lightweight model is used to prioritize fast key generation, and when the load is low, a more complex model is used to maximize security.

[0046] In the chaos map application step, a non-linear dynamic system such as a Zaslavskii map is used to impart chaotic characteristics to the initial keys generated by the GAN. The chaos map has the characteristic of being extremely sensitive to initial conditions, so even very small changes in input generate completely different outputs. In this process, nanosecond-level precise time information collected by the input information collection unit (110) is used as the initial condition of the chaos map, ensuring that completely different keys are generated over time even within the same node. Additionally, network topology change information received from the distributed certificate server cluster (200) is also utilized as a parameter of the chaos map, so that the key generation pattern changes fundamentally whenever the network configuration changes.

[0047] In the key strength verification step, it is checked whether the generated key passes all 11 randomness tests defined in NIST SP 800-22. These tests include the frequency test, the in-block frequency test, the run test, the longest run test, the binary matrix rank test, the discrete Fourier transform test, the non-overlapping template matching test, the overlapping template matching test, the universal statistical test of the maber, the linear complexity test, and the serial test. If the generated key does not pass these tests, the parameters of the chaos map are automatically adjusted to perform a regeneration process. The results of this verification process are fed back to the security class automatic assignment unit (400) and are used to establish a more appropriate key generation strategy for traffic of the same security class in the future.

[0048] In the final key length determination step, a key length of 128 bits, 256 bits, or 384 bits is determined according to the security grade assigned by the security grade automatic assignment unit (400). For financial or defense-related traffic requiring a high security grade, a 384-bit long-term key is generated, while for general corporate internal communication, a 256-bit key is generated, and for low-power environments such as IoT devices, a 128-bit key is generated. Based on the determined key length, the final key is derived using the PBKDF2 (Password-Based Key Derivation Function 2) algorithm, and in this process, a hardware unique value is used as a salt, and the number of iterations is dynamically adjusted considering system performance and security requirements.

[0050] The key storage and transmission unit (140) is for storing the key generated through the key generation engine unit (130) and transmitting it to the counterpart node.

[0051] The key storage and transmission unit (140) plays an important role in securely storing the generated dynamic encryption key and transmitting it to the communication partner. The operation of this module consists of four steps: key encryption storage, execution of the key exchange protocol, secure transmission, and key synchronization verification.

[0053] The description of each step of the above key storage and transmission unit (140) is as follows.

[0054] In the key encryption storage step, the generated dynamic key is not stored as is but is encrypted using the AES-256-GCM algorithm and then stored in a Hardware Security Module (HSM) or a secure memory area. The master key used in this process is managed by the distributed authentication server cluster (200) and is securely distributed through an authentication process when a node first joins the network. The stored key is automatically managed according to the lifecycle policy set by the key revocation management unit (150), and access rights are dynamically adjusted according to the system security status monitored by the encryption load balancing engine unit (500).

[0055] In the key exchange protocol execution phase, a key exchange protocol using the ECDH (Elliptic Curve Diffie-Hellman) P-384 curve is performed. During this process, each node generates a temporary key pair and exchanges its public key with the counterpart to derive a shared secret. This shared secret is used as an encryption key to securely transmit the actual dynamic key. During the key exchange process, the distributed certificate server cluster (200) performs the role of verifying the identity of each node and ensuring the integrity of the key exchange. Additionally, the encryption strength used for key exchange is adjusted according to the security grade determined by the security grade automatic assignment unit (400), so that stronger encryption parameters are applied when high security is required.

[0056] In the secure transmission phase, a dynamic key is transmitted through an encrypted tunnel based on the TLS 1.3 protocol. The transmitted key is further encrypted with the shared secret derived from the ECDH above to provide multi-layer security. During the transmission process, the encryption load balancing engine (500) monitors the network status in real time to select the optimal transmission path, and automatically sets an alternative path if network congestion or signs of attack are detected. If transmission failure or interruption occurs, an automatic retry mechanism is activated, and if consecutive failures occur, they are reported as a security event to the distributed certificate server cluster (200).

[0057] In the key synchronization verification step, a procedure is performed to verify whether the sending side and the receiving side possess the same key. To this end, the hash values ​​of the generated keys are exchanged to verify consistency, and at the same time, the validity and integrity of the keys are verified. Once synchronization is complete, the information is recorded in the distributed certificate server cluster (200) so that it can be referenced for future audits or troubleshooting. If synchronization fails, the key regeneration process is automatically initiated, and during this process, the key generation engine (130) analyzes the cause of the previous failure and generates a new key using different parameters.

[0059] The key disposal management unit (150) is a final stage component that manages the entire lifecycle of the generated dynamic key and performs secure disposal according to security policies. This module performs four core functions: key life monitoring, secure deletion, sending a key invalidation signal, and recording an audit log.

[0061] The detailed description of the four core functions included in the above key disposal management unit (150) is as follows:

[0062] The key lifespan monitoring function continuously monitors dual expiration conditions based on time and usage. Time-based monitoring checks whether a preset validity period (default 300 seconds) has elapsed since the key was generated, while usage-based monitoring tracks whether the accumulated amount of data encrypted with the key has reached a set threshold (default 1GB). These expiration conditions are dynamically adjusted according to the security level determined by the security level automatic assignment unit (400), so that a shorter validity period and a smaller data threshold are applied for traffic requiring high security. Additionally, if there are abnormal signs or attack attempts detected by the encryption load balancing engine unit (500), an emergency expiration signal is received, and the key disposal process is initiated immediately. The secure deletion function completely removes key data using a multi-overwrite method in accordance with the NIST SP 800-88 guidelines. In this process, the key is not simply deleted, but the corresponding memory area is overwritten multiple times with a random pattern to make recovery impossible. The number of overwrites and the pattern are adjusted according to the characteristics of the medium where the key is stored, and in the case of an SSD, a special deletion procedure is applied considering wear leveling. During the deletion process, the distributed certificate server cluster (200) monitors the progress of the deletion operation and accurately records the time of deletion completion to confirm that the lifecycle of the key has been completely terminated.

[0063] In the key invalidation signal transmission function, when a key is revoked, an invalidation signal is transmitted to all relevant network components. This signal is propagated throughout the network via the distributed certificate server cluster (200) to notify all nodes that the corresponding key is no longer valid. At the same time, the encryption processing unit (300) is instructed to stop processing packets encrypted with the corresponding key and to request a new key. This invalidation process is performed via multiple paths to ensure reliable transmission even in the event of network partitioning or communication failure, and each node sends an acknowledgment upon receiving the invalidation signal to guarantee the integrity of the signal transmission.

[0064] The audit log recording function records in detail all events throughout the entire lifecycle of a key, from its creation to its disposal. The log includes the key creation time, usage start time, amount of encrypted data, key exchange history, disposal time, and related security events. These logs are stored on the blockchain of the distributed certificate server cluster (200) to prevent tampering, and the security grade automatic assignment unit (400) analyzes this log data to use for future security policy improvement. Additionally, the cryptographic load balancing engine unit (500) analyzes key usage patterns through the log data to optimize system performance and automatically generates a security alert when an abnormal pattern is detected.

[0066] In this way, each component of the dynamic key generation module (100) does not operate independently but is organically linked with other key components to implement an integrated network security infrastructure that maximizes the security and efficiency of the entire system.

[0068] The distributed authentication server cluster (200) is a core component that provides the trust basis for the entire network security system and fundamentally solves the single point of failure problem of the centralized authentication system by utilizing blockchain-based consensus algorithms and smart contract technology.

[0069] The core operation mechanism of the above distributed authentication server cluster (200) is based on the DL-DPoS (Deep Link-Delegated Proof of Stake) consensus algorithm. This algorithm introduces a LINK incentive mechanism to address the limitations of existing DPoS, such as low node participation rates and security risks caused by malicious nodes. First, during the node registration process, each network node registers the hardware unique value and public key information provided by the dynamic key generation module (100) on the blockchain. At this time, the credibility of the node is calculated through a multidimensional credit score system that comprehensively evaluates assets, performance, and stability, and this score plays a key role in the selection of authentication nodes in the future.

[0070] In the process of selecting validators through the distributed authentication server cluster (200), a composite algorithm combining stake weights and credit scores is used. The number of validators required is dynamically adjusted according to the security grade determined by the security grade automatic assignment unit (400), and for transactions requiring high security, consensus of more validators is required. The selected validators create a block containing the authentication transaction, and the remaining nodes verify the validity of the block through agreement of more than 2 / 3. In this process, the block creation cycle is adjusted according to network load information received from the cryptographic load balancing engine unit (500), and when the system load is high, the authentication processing speed is improved by creating a faster block.

[0071] The smart contract-based authentication technology of the distributed authentication server cluster (200) provides an automated authentication procedure by implementing the authentication policy in code. Validation of the key generated by the dynamic key generation module (100), verification of the integrity of the key exchange protocol, and automatic processing of the key revocation point are all executed through the smart contract. In particular, through the multi-signature authentication function, it is configured to require signatures from multiple authentication nodes for high-security-grade transactions. These authentication results are transmitted in real-time to the encryption processing unit (300) and reflected in the determination of the encryption policy for each packet.

[0072] The load balancing mechanism of the distributed authentication server cluster (200) is based on a round-robin method, but dynamic weights are adjusted by monitoring the real-time load status of each authentication node. The weight of each node is calculated in real time based on CPU, memory, and network usage information received from the cryptographic load balancing engine (500), and fewer authentication requests are allocated to nodes with high loads to optimize overall system performance. In addition, service continuity is ensured by automatically distributing tasks among the remaining nodes even in the event of network partitioning or failure of a specific node.

[0074] The encryption processing unit (300) is a core module that effectively implements the security of the entire system and fundamentally blocks comprehensive decryption attacks by applying differentiated encryption to each data packet. Unlike the existing method of encrypting the entire data stream as a single unit, this module's innovative approach applies different encryption algorithms and keys to each packet, so that even if an attacker decrypts some packets, they cannot understand the entire communication content.

[0075] The encryption processing unit (300) derives a one-time packet key by hashing the session ID, location information, time information, and hardware fingerprint received from the dynamic key generation module (100), and performs individual encryption processing for each data packet using the derived one-time packet key.

[0077] In the packet analysis step of the encryption processing unit (300), the size, protocol type, QoS priority, and destination information of each received data packet are comprehensively analyzed. The results of this analysis are combined with a security policy pre-set by the security grade automatic assignment unit (400) to determine the encryption strength to be applied to the packet. For example, a lightweight encryption algorithm with fast processing speed is selected when real-time performance is important, such as with VoIP packets, and a strong encryption algorithm is applied when security is important, such as with financial transaction data.

[0078] The encryption algorithm selection process for this purpose utilizes a pseudo-random selection mechanism based on the packet's hash value. The header information and sequence number of each packet are hashed using SHA-3-256, and the algorithm is selected based on the remainder obtained by dividing this value by the number of available encryption algorithms. Through this method, an unpredictable encryption method is applied to each packet within the same session, thereby defending against pattern analysis attacks. Selectable algorithms include AES-256-GCM for general data packets, ChaCha20-Poly1305 for low-power IoT devices, and AES-256-CCM for real-time streaming data.

[0079] In the packet-specific key derivation process of the encryption processing unit (300), a key dedicated to each packet is generated by combining the master key provided by the dynamic key generation module (100) with the packet's unique information. A unique packet key is derived from the master key and the packet hash value using the HKDF (HMAC-based Key Derivation Function), and in this process, session authentication information received from the distributed authentication server cluster (200) is also utilized as additional entropy. The packet key generated in this way is used only for the encryption / decryption of the corresponding packet and is managed completely independently from other packets.

[0080] In addition, performance optimization of the encryption processing unit (300) is achieved by actively utilizing hardware acceleration functions. By utilizing hardware encryption instruction sets such as Intel AES-NI or ARM Crypto Extensions, the encryption processing speed is significantly improved, and in a multi-core CPU environment, multiple packets are encrypted in parallel to maximize throughput. Furthermore, adaptive encryption strength adjustment is performed according to network latency information received from the encryption load balancing engine unit (500). In situations where network latency is high, lightweight encryption is applied to prioritize processing speed, and when latency is low, high-strength encryption with enhanced security is used.

[0082] The security grade automatic assignment unit (400) is an intelligent security policy engine that assigns an appropriate security grade in real time to each network communication channel through AI-based traffic analysis. This module achieves both security and efficiency by dynamically determining a security strategy optimized for each communication session, taking into account the complexity and diversity of network traffic.

[0083] The core of the traffic classification AI model of the security grade automatic assignment unit (400) is an advanced feature extraction algorithm based on deep packet inspection (DPI). This system comprehensively analyzes not only the header information of network packets but also payload patterns, communication frequency, characteristics by time period, and geographical location information. In addition, the machine learning model based on the Random Forest classifier identifies traffic types with a high accuracy of over 98.7%, which is a level capable of accurately distinguishing between financial, medical, gaming, IoT, and general web traffic.

[0084] Here, the security grade mapping system of the automatic security grade assignment unit (400) consists of four security levels (CRITICAL, HIGH, MEDIUM, LOW), and a differentiated security policy is applied to each level. The CRITICAL grade is assigned to financial, medical, and defense-related traffic and requires AES-256 encryption and multi-factor authentication, while the HIGH grade is applied to corporate internal and VPN traffic and uses AES-192 and dual authentication. The MEDIUM grade is applied to general web traffic and IoT device communication and uses AES-128 and single authentication, and the LOW grade applies ChaCha20 and simplified authentication for access to public content. This grade information directly influences the key generation policy of the dynamic key generation module (100) and the selection of the encryption algorithm of the encryption processing unit (300).

[0085] In addition, the dynamic policy update mechanism continuously reflects real-time threat intelligence and machine learning-based anomaly detection results. It analyzes authentication history and security event logs collected from the distributed authentication server cluster (200) to learn new threat patterns and automatically updates security policies based on this. For example, if a DDoS attack or a new type of malware is detected in a specific region, the security level for that region or traffic with similar patterns is automatically raised.

[0086] The compliance automatic reflection system of the security grade automatic assignment unit (400) monitors various international standards and regulatory requirements, such as GDPR, HIPAA, and SOX, in real time and automatically reflects them in the security policy. Whenever a new regulation comes into effect or an existing regulation is changed, the corresponding update is automatically applied to the system, and the security grade of the relevant traffic is adjusted. In this process, it cooperates with the cryptographic load balancing engine unit (500) to find and apply the optimal balance point between compliance requirements and system performance.

[0088] The cryptographic load balancing engine (500) is a core component that ensures the performance and availability of the entire system and optimally distributes cryptographic tasks through real-time resource monitoring and an intelligent load balancing algorithm. This engine performs comprehensive optimization that considers both security and performance simultaneously, going beyond simple load balancing.

[0089] The real-time resource monitoring system of the above-mentioned cryptographic load balancing engine unit (500) continuously monitors the CPU usage, memory usage, network bandwidth, and cryptographic throughput of all nodes in the network. This information is collected at 100ms intervals and used for real-time decision-making, accurately identifying the cryptographic processing capability and current load status of each node. This monitoring information is securely shared through the blockchain network of the distributed authentication server cluster (200) to ensure the transparency and reliability of the entire network.

[0090] In addition, the load balancing algorithm adaptively uses three main methods depending on the situation. In the weighted round-robin method, work is distributed by assigning weights based on the processing capacity of each node, and in the minimum connection method, the node with the most spare capacity is selected based on the number of encryption tasks currently being processed. In the response time-based method, the node capable of providing the fastest response is selected first through statistical analysis of past encryption processing times. In this selection process, the security grade determined by the security grade automatic assignment unit (400) is an important consideration, and for tasks requiring high security, a security-specialized node is selected first rather than a performance-based node.

[0091] The dynamic algorithm switching mechanism of the encryption load balancing engine unit (500) adjusts the encryption algorithm to be used in real time according to the system status and security requirements. When the CPU usage exceeds 80%, it automatically switches to ChaCha20, which is 30% faster than AES, and when security requirements are high, it selects AES-256-GCM, prioritizing security over performance. In general situations, it uses AES-192-CTR, which considers the balance between security and performance. This algorithm switching information is transmitted in real time to the encryption processing unit (300) and is immediately reflected in the encryption processing for each packet.

[0092] The predictive scaling system of the cryptographic load balancing engine (500) analyzes past traffic patterns and load history to predict future resource requirements and preemptively allocates resources. It predicts an increase in load by comprehensively analyzing the key generation cycle information of the dynamic key generation module (100) and the security level change trends of the security level automatic allocation unit (400), and performs resource reallocation in advance to prepare for this. It optimizes the queue by applying the M / M / c model of queuing theory and continuously manages it so that the average waiting time does not exceed 100ms.

[0094] The components of the present invention are organically interconnected to comprehensively optimize the security, performance, and availability of the entire system. A distributed authentication server cluster (200) provides a trust basis, an encryption processing unit (300) implements actual security, an automatic security grade assignment unit determines intelligent policies, and an encryption load balancing engine unit (500) is responsible for overall performance optimization, thereby implementing a complete integrated security system.

[0096] The system of the present invention further includes a risk-based key management engine (600), and the risk-based key management engine (600) is an adaptive key management module that calculates the real-time security risk of a network environment through multi-indicator analysis and, based on this, dynamically adjusts the length, rotation period, and usage limit of encryption keys to achieve an optimal balance between security and system performance. Unlike conventional fixed key management methods, this component actively responds to the network threat environment that changes in real time and automatically optimizes key security policies.

[0098] The above-mentioned risk-based key management engine (600) first collects authentication failure rate data from the distributed authentication server cluster (200) at 5-second intervals. Then, it obtains packet drop rate and encryption latency information in real time from the encryption processing unit (300), and receives information on CPU usage deviation and memory usage change of each node from the encryption load balancing engine unit (500). Finally, it periodically updates geographical risk scores and new threat pattern information from an external threat intelligence system.

[0100] The above-mentioned risk-based key management engine (600) collects authentication failure rates (x1) from a distributed authentication server cluster (200) at 5-second intervals, obtains packet drop rates (x2) and encryption delay times in real time from an encryption processing unit (300), receives CPU usage deviation (x3) and memory usage change information from an encryption load balancing engine unit (500), and receives updates on geographical risk scores (x5) and new threat pattern information from an external threat intelligence system, fuses the above multiple indicators using Z-score normalization, entropy-based weighting, and time smoothing techniques to calculate a real-time risk index, and dynamically adjusts the length of the encryption key, rotation period, and traffic-based usage limit according to the above risk index to achieve an optimal balance of security and system performance.

[0102] The five collected indicators are as follows.

[0103] - Authentication Failure Rate (x1): Failure rate relative to total authentication attempts (%, normal range 0~5%)

[0104] The normal range of the authentication failure rate of 0 to 5% above reflects the natural failure rate that occurs in a typical corporate network environment due to password entry errors, temporary network delays, etc., and was set by adding an operational margin of 2% to the standard value of 3% recommended by the ITU-T X.800 security standard.

[0106] - Packet Drop Rate (x2): Ratio of packet loss to total packets (%, normal range 0~0.5%)

[0107] The normal range of packet drop rates, 0 to 0.5%, is the IEEE 802.11 good standard of 0.1% plus a congestion margin of 0.4%.

[0109] -CPU Usage Deviation (x3): Deviation from the average during normal operation (%, normal range -10~+15%)

[0110] The normal range of CPU utilization deviation from -10% to +15% reflects the natural fluctuations caused by batch jobs and garbage collection in typical server operating environments, applying the standards recommended by ITIL v4, the standard in the field of system administration.

[0112] - Network Latency Change Rate (x4): Increase rate relative to reference latency (%, normal range 0~20%)

[0113] The normal range for network latency variation of 0–20% was set by adding a 5% operational margin to the 15% allowable latency variation limit of the ITU-T Y.1541 QoS standard.

[0115] - Geographic Risk Score (x5): 1-5 point scale (1=Very Safe, 5=Very Dangerous)

[0116] The geographical risk score is aligned with this indicator by mapping countries to five levels in the OECD and ITU’s National Cyber ​​Security Index, where the top 20% of countries in the NCSI assessment are mapped to 1–2 points, the middle 50% to 3 points, and the bottom 30% to 4–5 points.

[0118] Z-score transformation is performed to normalize each metric. For example, if the certification failure rate is measured as 12%, the normal mean is 2%, and the standard deviation is 1.5%, the normalized value is (12-2) / 1.5 = 6.67.

[0120] Next, information entropy is calculated to measure the uncertainty of each indicator. Each indicator value is classified into five risk ranges (very low, low, medium, high, very high), and the probability of belonging to a corresponding range is calculated. For example, if the probability that an authentication failure rate of 12% belongs to the 'very high' range is 0.9 and the probability that it belongs to the 'high' range is 0.1, the entropy becomes -(0.9×log₂(0.9) + 0.1×log₂(0.1)) = 0.47 bits.

[0122] Here, the criteria for classifying the certification failure rate into five risk zones are as follows.

[0123] Very Low (0~1%), Low (1~3%), Medium (3~5%), High (5~10%), Very High (over 10%)

[0124] Probability calculation applies Bayesian inference to calculate the prior probability that the current measurement of 12% belongs to each interval using a Gaussian distribution model. For example, since 12% is close to the center value of 15% of the 'very high' interval, it is assigned a probability of 0.9, and since it is far from the 'high' interval, it is assigned a probability of 0.1.

[0125] Here, the prior probability used in Bayesian inference is based on statistical data from the past 30 days, and the probability density is calculated through the beta function by modeling the frequency of occurrence for each interval as a Dirichlet distribution.

[0127] The weight of each indicator is determined in proportion to its entropy. Since higher entropy (greater uncertainty) provides more important information, a higher weight is assigned. If the total sum of entropies is 2.5 bits and the entropy of the authentication failure rate is 0.47 bits, the weight becomes 0.47 / 2.5 = 0.188.

[0129] The final risk index is calculated by applying a time smoothing technique. To this end, the current risk index is reflected by 70% and the previous risk index is reflected by 30% to mitigate sudden fluctuations. If the currently calculated risk index exceeds the alarm threshold (5.0) by 2.0 or more, an additional weight of 2.0 is multiplied to emphasize the situation of a sudden surge in risk.

[0130] The above alarm threshold of 5.0 is automatically adjusted based on cumulative statistics after 30 days of system operation; it is raised by 0.2 if the false positive rate exceeds 5% and lowered by 0.1 if the false negative rate exceeds 2%.

[0132] Here, the ratio of 70% current value and 30% previous value in time smoothing is based on the first-order delay filter design principles of control theory and is a weight derived when the time constant τ is set to 3 seconds to balance system responsiveness and stability. This satisfies the fast response requirements of 5 seconds or less commonly used in the field of network security.

[0134] The risk index calculation process is performed in the following order.

[0135] Step 1 (0–1 second): Collect 5 indicator values ​​from each component

[0136] Step 2 (1–2 seconds): Perform Z-score normalization on each metric to the normal mean / standard deviation.

[0137] Step 3 (2–3 seconds): Calculate 5-interval classification probabilities for each indicator and derive entropy.

[0138] Step 4 (3–4 seconds): Calculate weights using entropy ratio and calculate weighted average risk index

[0139] Step 5 (4–5 seconds): Final risk index determined by applying time smoothing and surge correction to the previous risk index.

[0141] Here, the entire process must be completed within 5 seconds to enable real-time response.

[0142] If the collection of authentication failure rate data from the distributed authentication server cluster (200) is delayed by more than 5 seconds, the last successful received value is maintained, but the weight of the corresponding indicator is reduced by 50% to adjust the reliability. If data collection fails three consecutive times, the corresponding indicator is excluded from the risk index calculation and the calculation is continued by re-normalizing with the remaining four indicators.

[0144] Specific calculation examples are as follows.

[0145] -Previous Risk Index: 3.2

[0146] - Current weighted average risk index: 7.1

[0147] -Alarm threshold: 5.0

[0148] - Surge weight: 2.0

[0149] In the case of,

[0150] The final risk index = 0.3×3.2 + 0.7×7.1 + 2.0×max(0, 7.1-5.0) = 0.96 + 4.97 + 4.2 = 10.13.

[0151] At this time, since the risk index is limited to the range of 0 to 10, the final value becomes 10.0.

[0153] Once the risk index is calculated as described above, the three key parameters are dynamically adjusted based on it.

[0154] As a procedure for determining the key length, the risk index is converted to a binary logarithm and then incremented in 64-bit increments to determine the key length. If the risk index is less than 1.0, the default value of 128 bits is used. If the risk index is 1.0 or higher and less than 3.0, 192 bits are applied; if it is 3.0 or higher and less than 7.0, 256 bits are applied; and if it is 7.0 or higher, the maximum value of 384 bits is applied.

[0156] In the above example, for a risk index of 10.0, log₂(1+10.0) = log₂(11.0) = 3.46, so when the floor function is applied, it becomes 3, and the key length becomes 128 + 64×3 = 320 bits, but it is limited to a maximum value of 384 bits.

[0158] As a procedure for determining the key rotation cycle, the basic maximum rotation cycle of 600 seconds is shortened exponentially according to the risk index. A risk sensitivity factor of 0.3 and a load correction factor of 0.2 are applied.

[0159] Here, the risk sensitivity factor of 0.3 and the load correction factor of 0.2 are values ​​identified as the optimal balance point between security and processing performance based on simulation results of 1,000 nodes and 30 days.

[0161] If the current system load is a normalized value of 0.6 (60% load) and the risk index is 10.0, then 'Rotation period = 600 × exp(-0.3×10.0) × (1 + 0.2×0.6)= 600 × exp(-3.0) × 1.12= 600 × 0.0498 × 1.12 = 33.5 seconds'.

[0162] This is a reduction of approximately 95% compared to 600 seconds in normal situations, minimizing the exposure time of the key in dangerous situations.

[0164] As a traffic limit determination procedure, the basic maximum traffic limit of 2GB is reduced exponentially according to the risk index.

[0165] To this end, a traffic sensitivity factor of 0.4 is applied, resulting in 'Traffic limit = 2048MB × exp(-0.4×10.0)= 2048MB × exp(-4.0)= 2048MB × 0.0183= 37.4MB'.

[0166] This represents a reduction of approximately 98% compared to normal conditions, significantly limiting the amount of data processed by the key in dangerous situations.

[0168] For event-based emergency key rotation, the rate of change of the risk index is monitored every 1 second, and if either of the two conditions is satisfied, emergency key rotation is executed.

[0170] Condition 1: Detecting sudden changes in risk index

[0171] A case where the value obtained by subtracting the previous risk index from the current risk index is greater than or equal to the threshold of 2.0 is determined to be a sudden change. For example, if the previous risk index is 4.2 and the current risk index is 7.8, the change amount is 3.6, which exceeds the threshold of 2.0, thus satisfying the emergency turnover condition.

[0173] Condition 2: Exceeding the absolute risk index

[0174] If the current risk index exceeds the emergency response threshold of 8.0, an emergency rotation is executed unconditionally.

[0176] If an emergency rotation is decided, it proceeds in the following order.

[0178] Transmit an emergency key generation signal to the key generation engine unit (130) of the dynamic key generation module (100) → Transmit an immediate invalidation signal for the existing key to the key revocation management unit (150) → Broadcast key invalidation to the entire network via the distributed certificate server cluster (200) → Instruct to use a temporary key until new key generation is complete → Return to normal operation mode after new key distribution is complete

[0180] For example, under normal operating conditions, the risk index is set to 2.1, the key length to 192 bits, the rotation cycle to 420 seconds, and the traffic limit to 1.2 GB. If a DDoS attack starts and the risk index spikes to 8.7 within 5 minutes, the key length is increased to 384 bits, the rotation cycle is shortened to 45 seconds, and the traffic limit is restricted to 85 MB. At the same time, since both the conditions of a spike in the risk index (8.7-2.1=6.6 > 2.0) and an absolute value exceeding (8.7 > 8.0) are satisfied, an emergency key rotation is executed immediately.

[0182] The above-mentioned risk-based key management engine (600) receives a basic security policy per channel from the security grade automatic assignment unit (400), and automatically raises the policy if the real-time risk index requires a higher security level than the basic policy. For example, if general web traffic is classified as MEDIUM grade and is set to use a 256-bit key, but the current risk index reaches 9.2, it is forcibly raised to a 384-bit key.

[0184] It performs bidirectional information exchange with the cryptographic load balancing engine unit (500). It monitors in real time the impact of the high security level required by the risk-based key management engine (600) on system performance, and performs performance balancing adjustments such as extending the key rotation cycle by 10% or temporarily shortening the key length of some low-importance channels when the CPU usage exceeds 90%.

[0186] From the distributed authentication server cluster (200), not only authentication statistics but also information on network topology changes such as new node participation, node exit, and consensus failure is received and reflected in the risk index calculation. For example, if more than 20% of all nodes exit the network within 5 minutes, this is judged as a sign of a potential attack, and an additional weight of 1.5 is applied to the risk index.

[0188] This risk-based key management engine (600) reduces the possibility of security breaches caused by key leakage compared to the existing fixed-key method, and reduces the overall system load by preventing unnecessary high-strength encryption and frequent key rotation during normal operation. This is achieved through an automatic threshold determination based on a risk index and an immediate execution mechanism, and has the effect of significantly improving the ability to respond to zero-day attacks or new threats.

[0190] The present invention further includes a differential privacy traffic analyzer (700), and the differential privacy traffic analyzer (700) is a privacy-enhancing analysis module that applies a differential privacy technique to protect sensitive information of individual users or sessions during the network traffic pattern analysis process. This component receives traffic data classified by the security grade automatic assignment unit (400) and adaptively adds different levels of noise according to the importance and sensitivity of each traffic type, thereby providing meaningful traffic analysis results required by the risk-based key management engine (600) while protecting personal information.

[0192] The functions of the differential information protection traffic analyzer (700) are as follows.

[0193] First, the privacy budget is allocated differentially based on the importance of each traffic type. A high privacy budget is allocated to high-sensitivity traffic, such as financial transactions or medical information, to provide robust protection, while a relatively lower budget is allocated to general web browsing or access to public content to enhance analysis accuracy.

[0194] Second, the amount of noise to be added is dynamically adjusted based on real-time traffic patterns and risk situations. Standard noise is applied under normal conditions, but the noise level is lowered to prioritize accurate analysis when signs of an attack are detected or abnormal traffic increases.

[0195] Third, statistical noise is added so that unique traffic patterns of individual users or sessions cannot be identified, and analysis results are provided only in an aggregated form.

[0197] The above differential information protection traffic analyzer (700) dynamically calculates a Gaussian noise variance (σ²) by reflecting the sensitivity of each traffic type and real-time network risk situation, and applies noise to the data aggregation result using the variance. This “adaptive noise allocation” function is implemented with the following factors and procedures.

[0199] Traffic Sensitivity Score (S i ) is an integer value between 1 and 5. The above traffic sensitivity score is calculated by the AI-based traffic classification model of the security grade automatic assignment unit (400), which analyzes deep packet inspection (DPI), payload patterns, communication frequency, and service types (finance, medical, IoT, etc.), and calculates a 'threat context' score for each traffic session between 1 and 5 points. As for the mapping rules, financial transactions are set to 5, medical information to 4, IoT control to 3, general web to 2, and public content to 1, and are assigned as traffic classification results in real time immediately after traffic classification.

[0201] Privacy budget (ε i ) is a value between 0.1 and 2.0, with score S i It is set inversely proportional to, and S i Linear mapping function ε with values ​​as input i = 0.2 + (5-S i The value is calculated by applying ) × 0.3.

[0202] Here, the privacy budget ε iIt is designed to decrease linearly according to the sensitivity score, guaranteeing the GDPR requirement of 0.2 at the highest sensitivity (5 points) and allowing up to 1.4 for analytical utility at the lowest sensitivity (1 point) by dividing the interval into four equal parts (increasing by 0.3) to ε i = 0.2 + (5-S i The formula ) × 0.3 was derived.

[0203] For example, financial transactions (5 points) can be ε=0.2, and public content (1 point) can be ε=1.4.

[0205] The sample number (n) is the number of packets within the analysis target traffic window (5 minutes), and is a value counted (100 to 100,000) by the statistical processing module. The sample number is determined by counting the packets processed in real-time during the network traffic analysis window (default 5 minutes) through the data packet unit encryption processing unit (300). For example, if 12,000 packets are encrypted and processed during a 5-minute session, n=12,000, and as the amount of traffic increases, n increases, thereby reducing the basic noise dispersion and improving the accuracy of the analysis.

[0207] The risk index (R) is a value in the range of 0 to 10, which is calculated and updated every 5 seconds by the risk-based key management engine (600). The risk index is a value calculated by fusing multiple indicators (authentication failure rate, packet drop rate, CPU load, etc.) of the distributed authentication server cluster (200), encryption processing unit (300), and encryption load balancing engine unit (500) through the risk-based key management engine (600) using entropy-weighted average and time series smoothing techniques. The calculation cycle is calculated at 5-second intervals, within the range of 0 to 10 (0: safe, 10: highest risk), and the latest value can be received in the following 1st step (0-1 second).

[0209] The sensitivity amplification factor (α) is based on 1.5, and S i The application intensity can be adjusted when α increases by 1.

[0210] The aforementioned sensitivity amplification factor is set by experts based on simulation test results for financial, medical, IoT, and general web traffic. It measures the protection strength and system latency of traffic with a sensitivity score of 5 by varying α within the range of 1.0 to 2.0. An optimal balance was identified and adopted when α=1.5, where the risk of personal information exposure in financial transaction traffic is reduced by 95% while maintaining analysis latency within 2 seconds. Here, if α increases, noise becomes excessive, reducing the usability of analysis results, while if α decreases, the level of protection becomes insufficient.

[0212] The load correction factor (β) is set to 0.3 as the standard, so that the amount of noise change is controlled when R is greater than or equal to the standard value.

[0213] The above load correction factor β=0.3 adds 30% noise for every 1-point increase in the risk index, and was set to balance security priority and analysis performance. When β<0.2, analysis accuracy was insufficient in risk situations, and when β>0.5, useful analysis was impossible due to excessive noise. At β=0.3, it was possible to maintain an analysis accuracy of over 75% even in a situation with a risk index of 8.0. The above load correction factor is set by experts based on the results of experiments on adjusting noise intensity according to changes in the risk index.

[0215] Alarm threshold (R i ) is set to switch to security priority mode if the risk index is above this value, based on 5.0. The above alarm threshold is derived through the analysis of false positive and false negative rates of the risk index calculated by the risk-based key management engine (600). The value is calculated by comparing and analyzing the risk index with actual security events (authentication failure, attack detection, etc.) for 30 days of system operation through a risk management expert, and R when the false positive rate (misjudging a normal situation as a risk) and the false negative rate (missing a dangerous situation as normal) are each 5% or less. i It was derived that the optimal equilibrium is achieved when = 5.0. Here, R iIf is low, frequent false positives occur under normal conditions, and R i If it is high, the failure to detect dangerous situations increases.

[0217] The above “adaptive noise allocation” function is calculated through the following procedure,

[0218] Step 1 (0-1 second): For each category i, S i , ε i , n, obtain the latest risk index R.

[0219] Step 2 (1-2 seconds): Calculate the basic noise dispersion factor. ε i To ensure that the variance increases as ε decreases (high sensitivity), “Basic Variance = C / (ε i It is determined using the method ·√n), where C is a fixed constant (≈3.7) in differential information protection theory.

[0220] Here, the basic variance is “C / (ε i It is calculated by the formula ·√n)”, and the privacy budget ε in the differential information protection Gaussian mechanism. i It means the minimum noise variance corresponding to the number of samples n.

[0222] Step 3 (2-3 seconds): Apply sensitivity amplification correction value. Sensitivity score S i As α increases, additional noise is required, so “Amplification Variance = Fundamental Variance × [1 + α·(S i Calculate -1)]”.

[0223] Here, regarding amplification dispersion, since standard levels of noise alone are insufficient to provide adequate protection for sensitive traffic, the sensitivity score (S i Designed considering that noise must be further amplified in proportion to ), it amplifies the fundamental variance by α for every 1 increase in the sensitivity score, using “fundamental variance × [1 + α·(S i The formula -1)]” was designed to implement a technical concept that maintains only minimum protection for low-sensitivity traffic while providing linearly enhanced protection for high-sensitivity traffic.

[0224] Sensitivity score S for this i is an integer between 1 and 5 representing the relative importance of a traffic type, S i For public content with a value of 1, the basic variance alone is sufficient, but S i For financial transactions with a score of 5, protection is strengthened by amplifying the basic variance by 7 times (= 1 + α·4). Here, α is the sensitivity amplification factor, and “S i The method of linearly adjusting the amplification ratio by -1” was chosen to minimize complexity while obtaining an exponential noise amplification effect as sensitivity increases. As a result of experimenting with various α values ​​(1.0, 1.5, 2.0), α=1.5 was adopted as it was confirmed that there is an optimal balance between the financial transaction traffic protection level (95% identification blocking) and system latency (<2 seconds).

[0226] Step 4 (3-4 seconds): Calculate the danger situation correction value. R is the alarm threshold R i If it exceeds, noise is added in proportion to the excess amount.

[0227] - If R ≤ R i , risk variance adjustment = 1.0 and

[0228] - If R > R i , Risk Variance Adjustment = 1.0 + β·(R - R i It works.

[0229] And the value is calculated as Total Variance = Amplified Variance × Risk Variance Correction.

[0231] In other words, under normal circumstances (risk index R is the standard value R i Within this range), sufficient privacy protection is guaranteed by the base variance (value after sensitivity amplification), so only “1.0x” is applied without additional correction (R ≤ R i , risk variance adjustment = 1.0),

[0232] The risk index is the baseline (R iIf it exceeds ), a switch to “Security First Mode” is required; therefore, noise is linearly increased by the risk excess amount to strengthen protection over analysis accuracy (R > R i , Risk Variance Adjustment = 1.0 + β·(R - R i )).

[0234] Step 5 (4-5 seconds): Pass the final variance value to the statistical module to add the Gaussian noise of the corresponding variance to the aggregated data (mean, histogram, etc.) for analysis.

[0236] Here, the privacy budget (ε i The initial value (0.1 to 2.0) of ) was set by combining the GDPR recommendations and domestic financial industry personal information protection guidelines, with a minimum privacy budget (0.1) for highly sensitive traffic and a maximum (2.0) for low-sensitivity traffic.

[0237] The constant C (≈3.7) represents the failure probability 10 in the differential information protection Gaussian mechanism formula. -6 It is a standard constant reflecting this, derived from the formula C = √(2ln(1.25 / δ)). That is, C = √(2ln(1.25 / 10 -6 )) = √(2ln(1,250,000)) = √(2×14.04) = 3.72.

[0238] Alarm threshold R i =5.0 is a value derived by experimentally verifying the balance between false positive and false negative rates in the risk-based key management engine (600).

[0240] If the reception of traffic classification information from the rapid automatic allocation unit (400) is delayed by more than 5 seconds, the average sensitivity score from the previous 5 minutes is used, but a safety factor of 1.2 is multiplied to handle it conservatively. If the reception of the risk index from the risk-based key management engine (600) fails, a default value R=6.0 (alarm level) is applied to maintain a high level of security.

[0242] The aggregate result after adding noise, which is output by this analyzer, is transmitted to the risk-based key management engine (600) and is used as a basic statistical value when determining resource allocation, key length, and rotation cycle.

[0244] For example, financial transaction traffic (S i =5, ε i In the case where =0.2, n=1,000, R=7.0),

[0245] Basic variance = 3.7 / (0.2×31.6)=0.586, and

[0246] Amplification variance = 0.586×[1+1.5×4]=0.586×7=4.102, and

[0247] Risk variance adjustment = 1+0.3×(7.0-5.0)=1.6

[0248] The total variance is calculated to be 4.102 × 1.6 = 6.563.

[0250] Gaussian noise with a variance of 6.563 is added to the aggregate results of the category to prevent the possibility of personal information leakage, while the aggregate mean and distribution can be sufficiently utilized for analysis purposes.

[0252] In this way, the differential information protection traffic analyzer (700) dynamically adjusts noise by considering both sensitivity and risk situations, thereby reducing the risk of personal information identification by traffic type and achieving the effect of improving analysis accuracy even in attack situations.

[0254] An example of an operation algorithm for a network infrastructure security system based on artificial intelligence-based dynamic encryption key exchange and distributed authentication for the above proceeds through the following steps: request to start a communication session → key generation in a dynamic key generation module → request for authentication to a distributed authentication server cluster → automatic assignment of communication channel type and security level → encryption processing at the data packet level → operation of a state-based encryption load balancing engine → revocation of key and termination of session (see Fig. 3).

[0256] Each process is explained in detail as follows.

[0258] 1) Request to start a communication session step

[0259] In the communication session start request step, when session initialization messages are exchanged for data transmission and reception between network nodes, each node provides initial parameters such as the unique ID of the current session, protocol information, and node hardware identifier to the input information collection unit (110) to configure the session context.

[0261] 2) Key generation step in the dynamic key generation module

[0262] In the dynamic key generation module, the key generation step involves the data preprocessing and integration unit (120) normalizing and hashing the session state, location information, time information, and hardware unique value collected by the input information collection unit (110), and the AI-based key generation engine unit (130) generating a one-time encryption key using a GAN model and a chaos map. The generated key is encrypted with AES-GCM by the key storage and transmission unit (140), stored in an internal storage, and then transmitted to the counterpart node of the session via an ECDH P-384-based secure channel.

[0264] 3) Authentication request step to the distributed authentication server cluster

[0265] In the authentication request step for the distributed authentication server cluster, once the key exchange is completed, the node sends an authentication request to the distributed authentication server cluster (200) to verify the key validity and node identity. Through a PoS-based consensus algorithm and a smart contract, each authentication node verifies the request and obtains the consent of more than 2 / 3 of the nodes to record the authentication result in the blockchain ledger.

[0267] 4) Automatic assignment of communication channel type and security level

[0268] After authentication is completed, the communication channel type and security grade automatic assignment step classifies the type of communication traffic (IoT, API call, internal / external traffic, etc.) based on AI, and the security grade automatic assignment unit (400) assigns one grade among CRITICAL / HIGH / MEDIUM / LOW. This security grade is used as a criterion for determining the key length, encryption algorithm strength, and the number of authentication steps.

[0270] 5) Data packet-level encryption processing step

[0271] In the data packet unit encryption processing step, the encryption processing unit (300) processes the header and sequence number for each transmitted packet using SHA3-256 hash to select an encryption algorithm (AES-GCM, ChaCha20-Poly1305, AES-CCM, etc.) and performs individual encryption using a packet-specific key derived from HKDF. The receiving node performs packet-specific decryption using the same procedure.

[0273] 6) State-based cryptographic load balancing engine operation steps

[0274] In the state-based encryption load balancing engine operation step, the encryption load balancing engine unit (500) monitors the CPU / memory / network status and encryption throughput of each node in real time, and distributes encryption tasks by selecting nodes with load capacity instead of nodes with concentrated load. Additionally, it automatically switches to an appropriate algorithm, such as ChaCha20 or AES-256, depending on system load or latency conditions.

[0276] 7) Key Disposal and Session Termination Step

[0277] In the key revocation and session termination step, when the session ends, the key revocation management unit (150) securely deletes the key in the NIST SP 800-88 manner when the key validity period (e.g., 300 seconds) is reached or the transmission threshold (e.g., 1 GB) is exceeded, and a signal of invalidation is propagated to the distributed certificate server cluster. After confirming the invalidation, the session log is recorded on the blockchain, and the session is finally terminated.

[0279] Although various embodiments of an AI-based dynamic encryption key exchange and distributed authentication-based network infrastructure security system have been described above, the AI-based dynamic encryption key exchange and distributed authentication-based network infrastructure security system is not limited solely to the embodiments described above. Various devices or methods that can be implemented by a person skilled in the art by modifying and varying the embodiments described above may also serve as examples of the AI-based dynamic encryption key exchange and distributed authentication-based network infrastructure security system described above. For example, even if the described technologies are performed in a different order than described, and / or the components of the described system, structure, device, circuit, etc. are combined or assembled in a form different from described, or replaced or substituted by other components or equivalents, they may still serve as an embodiment of the advertising execution information providing device, system, and method described above. Explanation of the symbols

[0280] Dynamic key generation module (100) Input information collection unit (110) Data preprocessing and integration unit (120) Key generation engine unit (130) Key storage and transmission unit (140) Key disposal management department (150) Distributed certificate server cluster (200) Encryption processing unit (300) Security grade automatic assignment unit (400) Cryptographic load balancing engine unit (500)

Claims

Claim 1 The system includes a dynamic key generation module (100) that generates a one-time encryption key in real time by processing the session state, location, time, and hardware unique value using an AI algorithm when a communication session between nodes starts, and automatically discards the key when a set time or traffic volume is reached to prevent key reuse; a distributed authentication server cluster (200) that processes authentication and key exchange of various nodes in a distributed manner based on a blockchain and consensus algorithm and records the authentication results; an encryption processing unit (300) that performs data encryption and decryption by selecting an encryption algorithm and a key that select one of a plurality of predefined encryption algorithms using a pseudo-random number selection method based on packet hash values ​​according to the results analyzed based on packet size, protocol type, QoS priority, and destination information; a security grade automatic assignment unit (400) that automatically assigns a security grade to a communication channel in real time according to AI-based traffic analysis and policies; and an encryption load balancing engine unit (500) that monitors the CPU usage, memory usage, network bandwidth, and encryption throughput of each node in real time and distributes encryption work by selecting one of a weighted round-robin method, a minimum connection method, or a response time-based method. The encryption processing unit (300) hashes the session ID, location information, time information, and hardware fingerprint received from the dynamic key generation module (100) to derive a one-time packet key, and performs individual encryption processing for each data packet using the derived one-time packet key, and collects the authentication failure rate from the distributed authentication server cluster (200) at 5-second intervals, obtains the packet drop rate and encryption delay time in real time from the encryption processing unit (300), receives information on CPU usage deviation and memory usage change from the encryption load balancing engine unit (500), and receives updates on geographical risk scores and new threat pattern information from an external threat intelligence system, thereby obtaining the authentication failure rate, packet drop rate, CPU usage deviation,A network infrastructure security system based on artificial intelligence-based dynamic encryption key exchange and distributed authentication, characterized by including a risk-based key management engine (600) that collects multiple indicators including network latency change rate and geographical risk score, fuses them using Z-score normalization, entropy-based weighting, and time smoothing techniques to calculate a real-time risk index, and dynamically adjusts the length of the encryption key, rotation period, and traffic-based usage limit according to the risk index. Claim 2 In claim 1, the procedure for calculating the risk index of the risk-based key management engine (600) sequentially collects authentication failure rate, packet drop rate, encryption latency, CPU utilization deviation, and geographical risk score in step 1 (0 to 1 second); normalizes the above indicators by Z-scores using their respective normal mean and standard deviation in step 2 (1 to 2 seconds); classifies the normalized values ​​into ranges of 'very low (0 to 1%), low (1 to 3%), normal (3 to 5%), high (5 to 10%), very high (over 10%)' in step 3 (2 to 3 seconds), calculates probabilities using Bayesian inference-based prior probabilities and a Dirichlet distribution model, calculates entropy-based weights, fuses the indicators with the weights in step 4 (3 to 4 seconds) to calculate a weighted average risk index, and in step 5 (4 to 5 seconds), sums 70% of the weighted average risk index and 30% of the previous risk index and issues an alarm. An AI-based dynamic encryption key exchange and distributed authentication-based network infrastructure security system characterized by determining the final risk index by multiplying by a weight of 2.0 when the threshold (5.0) is exceeded. Claim 3 delete Claim 4 delete Claim 5 delete Claim 6 delete

Images