System and method for managing phased transition of PQC cryptosystem based on crypto agility management agent

Abstract

A system and method for managing the phased transition of a PQC cryptographic scheme based on a cryptographic agility management agent can automatically manage the phased transition of a PQC (Post-Quantum Cryptography) cryptographic scheme.

Description

Technology Field

[0001] This document relates to the fields of public key infrastructure (PKI), network security, and cryptographic algorithm management technology. More specifically, it relates to an automatic transition management system and method based on a crypto-agility management agent for automatically managing the transition to a Post-Quantum Cryptography (PQC) cryptographic scheme in stages in an existing TLS (Transport Layer Security) 1.3 or DTLS (Datagram Transport Layer Security) 1.3-based secure communication environment using RSA or ECC-based public key cryptographic schemes.

[0002] In particular, this document relates to a technology that automatically determines the transition step according to a cryptographic agility policy model by utilizing the results of a downgrade detection system and whether a PQC algorithm is applied in TLS 1.3 or DTLS 1.3-based communication, and automatically transitions, verifies, and recovers PQC certificates, cryptographic algorithms, and key management policies through a cryptographic agility management agent operating in dual mode. Background Technology

[0003] In secure communication environments based on TLS (Transport Layer Security) 1.3 or DTLS (Datagram Transport Layer Security) 1.3, public key infrastructure (PKI) using classical public key cryptographic algorithms such as RSA, ECDSA, and ECDH has been widely used for identity authentication and key exchange between servers and clients.

[0004] While these cryptographic systems have provided substantial security to date, the advancement of quantum computers raises the possibility that classical public-key cryptographic algorithms may not be able to guarantee cryptographic security in the long term.

[0005] Accordingly, there is a demand for a transition to next-generation cryptographic systems utilizing Post-Quantum Cryptography (PQC) algorithms such as lattice-based, hash-based, and multivariate-based algorithms; however, the transition to PQC in actual operating environments involves complex issues that cannot be resolved by simply replacing algorithms.

[0006] Specifically, the following problems exist in the actual operating environment.

[0007] - Operational requirements to gradually transition the encryption system without service interruption

[0008] - PQC algorithm support levels vary by server, client, and device

[0009] - Difficulty in applying full-scale PQC due to computational performance and memory constraints of low-spec devices

[0010] - Necessity of parallel operation of PQC certificates (Pure, Hybrid, or Composite) and existing certificates

[0011] - Risk of configuration errors, policy inconsistencies, and password strength degradation during the transition process

[0012] - Possibility of downgrade attacks occurring during the TLS / DTLS negotiation process

[0013] Accordingly, this document proposes a technology that automatically identifies and verifies whether the PQC algorithm is applied and downgrade attacks in TLS 1.3 and DTLS 1.3 environments.

[0014] However, such technology is limited to determining the communication status at a specific point in time and fails to provide a management system that links the determination results to password transition policies, automatically executes and gradually applies transitions, and verifies the transition results from an operational and audit perspective.

[0015] In other words, while technology exists to identify whether PQC is applied, cryptographic agility-based transition management technology has not been presented that utilizes the results to automatically switch cryptographic schemes, certificates, and key management policies, restores to the previous state in the event of a transition failure, and consistently manages the pre-, during, and post-transition states. The problem to be solved

[0016] According to one embodiment of the present document, a system and method for managing the phased transition of a Post-Quantum Cryptography (PQC) cryptographic system based on a cryptographic agility management agent that automatically manages the phased transition of a PQC cryptographic system may be provided.

[0017] More specifically, one embodiment of this document aims to solve the following problem.

[0018] (1) Provides technology that automatically determines the cryptographic system transition based on the detection results and policies.

[0019] Existing PQC transition technologies often amounted to merely verifying configurations in individual systems or replacing algorithms; consequently, even when transition decisions existed in actual operating environments, there was a lack of criteria for how to link them to transition policies.

[0020] The purpose of this document is to provide a technology that automatically determines which stage a system or service should immediately transition to—maintaining the existing cryptographic scheme, Hybrid, Composite, or Pure PQC—by interpreting the PQC application status and downgrade detection results derived from TLS / DTLS-based communications according to a cryptographic agility policy model.

[0021] (2) Provides technology to control password policy settings (cryptographic scheme, certificate, key length, validity period, etc.) in a forced execution or observation / verification mode.

[0022] In conventional technology, password policies were applied only during the configuration phase, and there was a problem in that it was difficult to verify whether the policy was continuously complied with during the actual communication phase.

[0023] The purpose of this document is to provide a technology that simultaneously ensures the execution (application) and verification of cryptographic policies by configuring a cryptographic agility management agent or proxy-based execution layer to operate in dual mode, thereby enabling the selective execution of a mode that enforces cryptographic schemes and certificate settings according to policy and a mode that continuously observes and verifies cryptographic algorithms used in actual communication.

[0024] (3) Provide technology to ensure service continuity through automatic rollback in the event of PQC transition failure

[0025] Since the PQC algorithm differs from existing cryptographic systems in terms of implementation maturity, performance characteristics, and compatibility, there is a possibility of communication errors or service failures occurring during the transition process.

[0026] This document aims to prevent service interruptions caused by PQC transition and realize a non-disruptive or high-availability transition environment by providing a rollback mechanism that automatically restores the previous cryptographic scheme and certificate state when a TLS / DTLS handshake failure, certificate verification error, or communication session creation failure is detected after the PQC transition.

[0027] (4) Provides policy consistency and audit response technology by consistently managing the pre-, mid-, and post-PQC transition status.

[0028] In large-scale system environments, if PQC transitions are carried out in stages, failure to systematically manage the transition timing, applied encryption schemes, and policy change history may lead to operational confusion, policy violations, or difficulties in responding to audits.

[0029] This document aims to provide technology that ensures traceability, policy consistency, and security audit response capabilities for the entire password transition process by recording and managing the status before, during, and after PQC transition, the applied policy version, the reason for transition, and whether a rollback occurred in a consistent format.

[0030] The problems to be solved in this disclosure are not limited to those mentioned above and can be extended in various ways without departing from the spirit and scope of this disclosure. means of solving the problem

[0031] A PQC cryptographic scheme transition management system according to one embodiment of the present document is a system that automatically manages the phased transition of a PQC (Post-Quantum Cryptography) cryptographic scheme and includes: a transition input interface unit that receives information on whether PQC is applied in TLS (Transport Layer Security) 1.3 or DTLS (Datagram Transport Layer Security) 1.3-based secure communication and a result of detecting whether a PQC downgrade attack has occurred; a policy model management unit that manages a cryptographic agility policy model including allowed cryptographic algorithms, recommended cryptographic algorithms, prohibited cryptographic algorithms, and transition conditions; a transition policy determination unit that automatically determines a transition policy based on the information on whether PQC is applied, the result of detecting whether a PQC downgrade attack has occurred, and the cryptographic agility policy model; a transition execution layer management unit that distributes the determined transition policy in the form of a cryptographic policy to an execution layer that enforces TLS / DTLS cryptographic settings according to the cryptographic policy or observes and verifies the cryptographic algorithm used in actual communication; and a transition failure detection and automatic rollback unit that automatically restores to the previous cryptographic setting state when a communication failure is detected after transitioning to the transition policy.

[0032] The above cryptographic agility policy model may include priority of cryptographic algorithms, application ranges, and transition rules based on risk levels.

[0033] The above cryptographic agility policy model may include time-based or threat-level-based cryptographic algorithm discarding conditions.

[0034] The above transition policy may represent any one of maintaining RSA or ECC-based passwords, transitioning to Hybrid PQC, transitioning to Composite PQC, or transitioning to Pure PQC.

[0035] The above-mentioned transition execution layer management unit can distribute the transition policy in the form of the password policy to the execution layer representing at least one of a proxy module, a gateway module, a service mesh sidecar module, or a password agility management agent.

[0036] The execution layer above can operate in Enforcement Mode, which enforces the password policy, or Observation Mode, which observes the encryption algorithm used in actual TLS / DTLS communication.

[0037] The above Observation Mode may be a mode for collecting and verifying negotiated KeyShare groups, signature algorithms, and certificate types.

[0038] The above-mentioned transition failure detection and automatic rollback unit can perform automatic recovery to the previous password setting state if any one of a TLS / DTLS handshake failure, a certificate verification error, or a session creation failure occurs.

[0039] It may further include a transition history management unit that records and manages the policy, password setting status, and actual application results before, during, and after transitioning to the above transition policy as evidence information, and stores a transition history including the policy version, application time, reason for transition, and whether a rollback occurred.

[0040] The above-mentioned switching input interface unit can further receive PQC-related passive information and PQC-related active information.

[0041] The above PQC downgrade attack detection result may include at least one of the KeyShare downgrade attack detection result, Keyshare Groups downgrade attack detection result, and SignatureAlgorithm downgrade attack detection result.

[0042] The above cryptographic agility policy model can be dynamically updated based on threat information or operational status.

[0043] The above execution layer may be installed on at least one of a server, a client, or an IoT device.

[0044] The above system can automatically manage the transition of the PQC encryption scheme in a virtual machine environment, a container environment, or a cloud environment.

[0045] The above system can be applied to power infrastructure environments, financial infrastructure environments, or public infrastructure environments.

[0047] A method for managing the transition of a PQC cryptographic system according to one embodiment of the present document is a method performed by a system that automatically manages the phased transition of a PQC (Post-Quantum Cryptography) cryptographic system, comprising: receiving information on whether PQC is applied in security communication based on TLS (Transport Layer Security) 1.3 or DTLS (Datagram Transport Layer Security) 1.3 and a result of detecting whether a PQC downgrade attack has occurred; automatically determining a transition policy based on a cryptographic agility policy model including allowed cryptographic algorithms, recommended cryptographic algorithms, prohibited cryptographic algorithms, and transition conditions, and the information on whether PQC is applied and the result of detecting whether a PQC downgrade attack has occurred; distributing the determined transition policy in the form of a cryptographic policy to an execution layer that enforces TLS / DTLS cryptographic settings according to the cryptographic policy or observes and verifies the cryptographic algorithm used in actual communication; and automatically restoring to the previous cryptographic setting state when a communication failure is detected after transitioning to the transition policy.

[0048] The above cryptographic agility policy model may include priority of cryptographic algorithms, application ranges, and transition rules based on risk levels.

[0049] The above cryptographic agility policy model may include time-based or threat-level-based cryptographic algorithm discarding conditions.

[0050] The above transition policy may represent any one of maintaining RSA or ECC-based passwords, transitioning to Hybrid PQC, transitioning to Composite PQC, or transitioning to Pure PQC.

[0051] The above execution layer may represent at least one of a proxy module, a gateway module, a service mesh sidecar module, or a crypto agility management agent.

[0052] It may further include a step of recording and managing the policy, password setting status, and actual application results before, during, and after the transition to the above transition policy as evidence information.

[0054] A computer program according to one embodiment of the present document is stored on a computer-readable storage medium and executes any one of the above-described PQC encryption scheme conversion management methods on a computer. Effects of the invention

[0055] According to one embodiment of the present document, by automatically managing the phased transition of a Post-Quantum Cryptography (PQC) cryptographic system, the following effects can be obtained.

[0056] (1) Ensuring consistency in PQC transitions through policy-based cryptographic agility implementation

[0057] This document systematically defines allowed, recommended, and non-recommended password algorithms, transition conditions, priorities, and time-based revocation policies through a cryptographic agility policy model. By applying these to the transition policy decision-making process, password transitions—which previously varied by system, server, or device—can be performed consistently based on a centralized policy. Consequently, transition errors caused by operator intervention or differences in individual settings can be prevented, and policy consistency and reproducibility can be ensured during the PQC transition process.

[0058] (2) Simultaneous execution of enforcement and verification through dual-mode agents

[0059] This document describes how to configure the cryptographic agility management agent to operate in a dual mode of Enforcement Mode and Observation Mode, thereby enabling the enforcement of PQC certificates and cryptographic policies while simultaneously observing and verifying the cryptographic algorithms used during actual TLS / DTLS communication. This allows for verification that policies are not merely applied during the configuration phase but are continuously complied with during actual communication, and enables the real-time detection of policy bypasses, partial application, or configuration inconsistencies.

[0060] (3) Service continuity guaranteed through automatic rollback

[0061] This document includes an automatic rollback mechanism that automatically restores the previous cryptographic scheme and certificate state in the event of a TLS / DTLS handshake failure, certificate verification error, or communication session creation failure after the PQC transition. Accordingly, service interruptions or failures caused by the PQC transition can be minimized, and the requirements for high availability and non-disruptive transition in the production environment can be met.

[0062] (4) Prevention of downgrade attacks and policy bypass

[0063] This document utilizes the application status of TLS / DTLS-based PQC and downgrade detection results as input for determining the transition policy, and can be configured to enforce PQC transition or increase the transition level if a policy violation or the possibility of a downgrade attack is detected. Through this, KeyShare or SignatureAlgorithm downgrade attacks that may occur due to man-in-the-middle attacks or configuration errors can be effectively prevented, and situations where cryptographic strength is unintentionally degraded can be blocked in advance.

[0064] (5) The entire PQC transition process can be traced and audited

[0065] This document allows for the systematic recording of the cryptographic system status before and after the PQC transition, the applied policy version, the reason for the transition, and whether a rollback occurred. Accordingly, all decisions and execution processes related to the PQC transition can be traced in chronological order and utilized as objective evidence for security audits, regulatory compliance, or incident analysis. Furthermore, the transition history can be integrated with external audit systems or SIEM, enabling the continuous management and monitoring of the organization's cryptographic transition status.

[0066] The effects according to the various embodiments of this document are not limited to those described above, and it is obvious to those skilled in the art that various effects are inherent in this disclosure. Brief explanation of the drawing

[0067] FIG. 1 is a block diagram illustrating a system for managing the phased transition of a PQC cryptographic scheme based on a cryptographic agility management agent according to one embodiment of the present document. FIG. 2 is a block diagram illustrating the configuration of the PQC application status check and PQC downgrade attack detection system illustrated in FIG. 1. FIG. 3 is a diagram illustrating the operation of a passive TLS traffic monitoring module according to one embodiment of the present document. FIG. 4 is a diagram illustrating the operation of an active TLS connection module according to one embodiment of the present document. FIG. 5 is a diagram illustrating the operation of a PQC algorithm discrimination engine according to one embodiment of the present document. FIG. 6 is a diagram illustrating the operation of an automatic detection module for PQC downgrade attacks according to one embodiment of the present document. FIG. 7 is a diagram illustrating the operation of a policy management module according to one embodiment of the present document. FIG. 8 is a flowchart illustrating a method for automatically checking whether PQC is applied and detecting PQC downgrade attacks according to one embodiment of the present document. Figure 9 is a block diagram illustrating the configuration of the PQC cryptographic scheme switching management system illustrated in Figure 1. FIG. 10 is a diagram illustrating an example of the configuration of a PQC cryptographic scheme switching management system according to one embodiment of the present document. FIG. 11 is a diagram illustrating a transition policy decision process based on a cryptographic agility policy model according to one embodiment of the present document. FIG. 12 is a diagram illustrating a dual-mode operation structure for forcing execution and verification of a transition policy of an execution layer according to one embodiment of the present document. FIG. 13 is a diagram illustrating an automatic rollback process in case of a transition failure according to one embodiment of the present document. FIG. 14 is a flowchart illustrating a method for managing the phased transition of a PQC cryptographic scheme based on a cryptographic agility management agent according to one embodiment of the present document. Specific details for implementing the invention

[0068] Hereinafter, embodiments of this document will be described in detail with reference to the attached drawings. The advantages and features of the embodiments of this document, and the methods for achieving them, will become clear by referring to the details described below in conjunction with the attached drawings. However, the embodiments of this document are not limited to those disclosed below but can be implemented in various different forms, and the embodiments of this document are defined only by the scope of the claims.

[0069] Throughout the specification, the same reference numerals refer to the same components. Unless otherwise defined, all terms used in this specification (including technical and scientific terms) may be used in a meaning commonly understood by those skilled in the art to which the embodiments of this document pertain. Additionally, terms defined in commonly used dictionaries are not to be interpreted ideally or excessively unless explicitly and specifically defined otherwise.

[0070] In this specification, terms such as "first," "second," etc. are used to distinguish one component from another, and the scope of rights shall not be limited by these terms. For example, the first component may be named the second component, and similarly, the second component may be named the first component.

[0071] In this specification, identification symbols (e.g., a, b, c, etc.) for each step are used for convenience of explanation and do not indicate the order of the steps; the steps may occur differently from the specified order unless the context clearly indicates a specific order. That is, the steps may occur in the same order as specified, may be performed substantially simultaneously, or may be performed in the reverse order.

[0072] In this specification, expressions such as “have,” “may have,” “include,” or “may include” refer to the existence of the relevant feature (e.g., a numerical value, function, operation, or component, etc.) and do not exclude the existence of additional features.

[0073] Additionally, the term “part” as used in this specification refers to software or hardware components such as field-programmable gate arrays (FPGAs) or ASICs, and the “part” performs certain roles. However, the “part” is not limited to software or hardware. The “part” may be configured to reside in an addressable storage medium or configured to run one or more processors. Thus, by example, the “part” includes components such as software components, object-oriented software components, class components, and task components, as well as processes, functions, attributes, procedures, subroutines, segments of program code, drivers, firmware, microcode, circuits, data structures, and variables. The functions provided within the components and “parts” may be combined into a smaller number of components and “parts” or further separated into additional components and “parts.”

[0075] A system and method for managing the phased transition of a PQC cryptographic scheme based on a cryptographic agility management agent according to one embodiment of the present document will be described in detail below with reference to the attached drawings.

[0077] First, with reference to FIG. 1, a system for managing the phased transition of a PQC cryptographic scheme based on a cryptographic agility management agent according to one embodiment of the present document will be described.

[0078] FIG. 1 is a block diagram illustrating a system for managing the phased transition of a PQC cryptographic scheme based on a cryptographic agility management agent according to one embodiment of the present document.

[0079] Referring to FIG. 1, a system for automatically checking whether Post-Quantum Cryptography (PQC) is applied and for detecting PQC downgrade attacks (hereinafter referred to as the "PQC application check and PQC downgrade attack detection system") (100) according to one embodiment of the present document, and a system for managing the phased transition of a PQC cryptographic system based on a cryptographic agility management agent according to one embodiment of the present document (hereinafter referred to as the "PQC cryptographic system transition management system") (200) can be connected to a plurality of servers (10) and a plurality of clients (20) through a secure communication network based on TLS (Transport Layer Security) 1.3 or DTLS (Datagram Transport Layer Security) 1.3.

[0080] The server (10) can provide various services to a client (20) or an IoT device (not shown) through a secure communication network based on TLS 1.3 or DTLS 1.3.

[0081] The PQC application status check and PQC downgrade attack detection system (100) can automatically identify and verify whether the PQC algorithm of the server (10) is applied in TLS 1.3 or DTLS 1.3-based secure communication and detect PQC downgrade attacks against the server (10).

[0082] Here, the PQC application status check and PQC downgrade attack detection system (100) can be implemented in the form of software, hardware, or a combination thereof, and can be executed in various computing environments such as network traffic collection devices, servers, virtual machine environments, container environments, and cloud environments.

[0083] The PQC encryption system transition management system (200) can automatically manage the step-by-step transition of the PQC encryption system for a server (10), a client (20), an IoT device, etc.

[0084] Here, the PQC cryptographic scheme transition management system (200) can be implemented in the form of software, hardware, or a combination thereof, and can automatically manage the transition of the PQC cryptographic scheme in various computing environments, such as virtual machine environments, container environments, and cloud environments. Additionally, the PQC cryptographic scheme transition management system (200) can be applied to power infrastructure environments, financial infrastructure environments, or public infrastructure environments.

[0086] Then, with reference to FIGS. 2 to 7, a system for checking whether PQC is applied and detecting PQC downgrade attacks according to one embodiment of the present document will be described in more detail.

[0087] FIG. 2 is a block diagram for explaining the configuration of a system for checking whether PQC is applied and detecting PQC downgrade attacks as illustrated in FIG. 1, FIG. 3 is a diagram for explaining the operation of a passive TLS traffic monitoring module according to one embodiment of the present document, FIG. 4 is a diagram for explaining the operation of an active TLS connection module according to one embodiment of the present document, FIG. 5 is a diagram for explaining the operation of a PQC algorithm determination engine according to one embodiment of the present document, FIG. 6 is a diagram for explaining the operation of a PQC downgrade attack automatic detection module according to one embodiment of the present document, and FIG. 7 is a diagram for explaining the operation of a policy management module according to one embodiment of the present document.

[0088] Referring to FIG. 2, the PQC application status check and PQC downgrade attack detection system (100) may include a passive TLS traffic monitoring module (110), an active TLS connection module (120), a PQC algorithm determination engine (130), a PQC downgrade attack automatic detection module (140), a policy management module (150), and a PQC application status database (160).

[0089] The passive TLS traffic monitoring module (110) can collect handshake packets of TLS 1.3 or DTLS 1.3, including ClientHello and ServerHello, on the network and analyze the collected handshake packets to obtain passive information related to PQC for each server (10).

[0090] That is, the passive TLS traffic monitoring module (110) analyzes ClientHello and ServerHello messages to extract the TLS version, SNI (Server Name Indication), SupportedGroups, and KeyShare, and determines whether the handshake was completed normally based on the Finished message, thereby obtaining PQC-related passive information (TLS version, SNI, SupportedGroups, KeyShare, whether the handshake was completed normally, etc.) for each server (10).

[0091] At this time, the passive TLS traffic monitoring module (110) can extract KeyShares from the SupportedGroups and KeyShare extension fields.

[0092] Referring again to FIG. 3, the passive TLS traffic monitoring module (110) can collect TLS 1.3 or DTLS 1.3 handshake packets through a traffic collection device (not shown) installed in a network segment. The passive TLS traffic monitoring module (110) can analyze ClientHello and ServerHello messages to extract TLS version, SNI, SupportedGroups, and KeyShare information, and determine whether a normal handshake has been completed based on the Finished message, and store client and server information.

[0093] More specifically, the passive TLS traffic monitoring module (110) can collect packets through TAP / SPAN (mirroring port) and parse ClientHello and ServerHello for a connection identified as a TLS 1.3 handshake to extract KeyShare / SupportedGroups / SNI information. The passive TLS traffic monitoring module (110) can check whether a normal handshake has been completed through a Finished message and can register the server address and port of the completed session as a server candidate, and can assign priority based on whether a PQC KeyShare appears during registration.

[0095] The active TLS connection module (120) can obtain active information related to PQC for each server (10) by performing an active TLS connection with the identified server (10) based on passive information related to PQC (TLS version, SNI, SupportedGroups, KeyShare, whether a normal handshake has been completed, etc.).

[0096] That is, the active TLS connection module (120) analyzes the signature algorithm OID (Object Identifier), certificate size, certificate extension field, and certificate structure of the server certificate based on the ServerHello and encrypted Certificate messages received from the server (10), and when it receives a CertificateRequest message from the server (10), it obtains the SignatureAlgorithm list requested by the server (10) and can obtain active information related to PQC for the server (10) (signature algorithm OID, certificate size, certificate extension field, certificate structure, SignatureAlgorithm list, etc.).

[0097] At this time, the active TLS connection module (120) can automatically perform an active TLS connection to the identified server (10) based on PQC-related passive information (TLS version, SNI, SupportedGroups, KeyShare, whether a normal handshake has been completed, etc.) for each server (10).

[0098] Referring again to FIG. 4, the active TLS connection module (120) can actively perform a TLS 1.3 or DTLS 1.3 connection to a server (10) identified by the passive TLS traffic monitoring module (110). The active TLS connection module (120) receives ServerHello and encrypted Certificate messages and analyzes the signature algorithm OID, certificate size, and certificate extension fields of the server certificate, and if it receives a CertificateRequest message, it can further analyze the SignatureAlgorithm list requested by the server (10).

[0099] More specifically, the active TLS connection module (120) performs a TLS 1.3 connection to the candidate server (10) and can record the selected KeyShare of ServerHello. Subsequently, the active TLS connection module (120) receives the server certificate (including the encryption section) and can analyze the certificate signing algorithm OID, certificate size, extension field, and chain structure. When the server (10) sends a CertificateRequest, the active TLS connection module (120) can analyze the SignatureAlgorithm list in the message to determine whether PQC-based client authentication is supported.

[0101] The PQC algorithm determination engine (130) can obtain information on whether the server (10) has applied PQC based on PQC-related passive information (TLS version, SNI, SupportedGroups, KeyShare, whether a normal handshake has been completed, etc.) and PQC-related active information (signature algorithm OID, certificate size, certificate extension field, certificate structure, SignatureAlgorithm list, etc.).

[0102] That is, the PQC algorithm determination engine (130) can obtain information on whether PQC is applied to the server (10) (whether PQC signature is applied, whether PQC KEM is applied, certificate type, etc.) by analyzing whether PQC signature is applied to the server (10), whether PQC KEM is applied to the server (10), and one of Pure certificate, Hybrid certificate, and Composite certificate based on the signature algorithm OID, KeyshareGroup ID, certificate extension field, and certificate structure.

[0103] Here, the signature algorithm OID can be configured to identify the PQC algorithm, legacy algorithms, or a combination thereof. Additionally, the KeyShareGroup ID can be analyzed to determine whether the PQC KEM algorithm is applied. Furthermore, the certificate structure can be analyzed to determine the certificate type, which represents one of a Pure certificate, a Hybrid certificate (which includes both the PQC signature algorithm and the legacy signature algorithm), or a Composite certificate (which includes multiple signature algorithms within the same certificate structure).

[0104] At this time, the PQC algorithm determination engine (130) may additionally determine whether a PQC signature is applied based on the certificate size to obtain information on whether PQC is applied (whether a PQC signature is applied, whether a PQC KEM is applied, certificate type, etc.). For example, by utilizing the fact that the certificate size varies depending on the certificate type (Pure certificate, Hybrid certificate, or Composite certificate), the PQC algorithm determination engine (130) may additionally determine whether a PQC signature is applied to the server (10) using the certificate size based on a predefined certificate size threshold.

[0105] Additionally, if a PQC algorithm determination engine (130) includes a PQC-based algorithm in the SignatureAlgorithm list, it may determine that the server (10) supports PQC-based client authentication and obtain information on whether PQC is applied (whether PQC signature is applied, whether PQC KEM is applied, certificate type, whether PQC-based client authentication is supported, etc.).

[0106] Referring again to FIG. 5, the PQC algorithm determination engine (130) can determine whether to apply PQC by using the following information as input.

[0107] - SignatureAlgorithm OID

[0108] - KeyShareGroup ID

[0109] - Certificate Extension Fields and Chain Structure

[0110] Through this, the PQC algorithm discrimination engine (130) distinguishes between the PQC signature algorithm, the PQC KEM algorithm, the Pure certificate, the Hybrid certificate, and the Composite certificate, and may include auxiliary discrimination logic using the certificate size.

[0111] More specifically, the PQC algorithm determination engine (130) can determine (i) whether a PQC signature is applied, (ii) whether a PQC KEM is applied, and (iii) the certificate type (Pure / Hybrid / Composite) by using a signature algorithm OID and KeyShareGroup ID mapping table and a PQC certificate (Pure / Hybrid / Composite) determination rule. If necessary, the PQC algorithm determination engine (130) can use certificate size thresholds, etc., for auxiliary determination.

[0113] The PQC downgrade attack automatic detection module (140) can detect whether a PQC downgrade attack has occurred by analyzing PQC-related passive information (TLS version, SNI, SupportedGroups, KeyShare, whether a normal handshake has been completed, etc.) and PQC-related active information (signature algorithm OID, certificate size, certificate extension field, certificate structure, SignatureAlgorithm list, etc.) according to predefined comparison rules based on the same server (10).

[0114] That is, the PQC downgrade attack automatic detection module (140) can determine whether there is a PQC downgrade attack on the server (10) by comparing PQC-related passive information and PQC-related active information according to a comparison rule based on the same SNI standard.

[0115] Here, the comparison rule may include at least one of the following: a first rule determining that there is a possibility of a PQC downgrade attack on the server (10) when a PQC KeyShare is observed in PQC-related passive information but only a legacy KeyShare is negotiated in PQC-related active information; a second rule determining that there is a possibility of a PQC downgrade attack on the server (10) when only a legacy certificate is provided despite expectations of providing a PQC or Hybrid certificate; and a third rule determining that there is a possibility of a PQC downgrade attack on the server (10) when a PQC-based SignatureAlgorithm request is observed but not requested in PQC-related active information.

[0116] Referring again to FIG. 6, the PQC downgrade attack automatic detection module (140) verifies the consistency of passive TLS monitoring results and active TLS connection results based on the same server identifier and can detect the following discrepancies according to predefined comparison rules.

[0117] - Case where PQC KeyShares were observed in passive analysis but only legacy KeyShares were negotiated in active connection

[0118] - Cases where only a legacy certificate is provided even though a PQC or Hybrid certificate is expected to be provided

[0119] - Case where a PQC-based Signature Algorithm request is observed but not requested during active verification

[0120] If a discrepancy occurs, the PQC downgrade attack automatic detection module (140) can automatically determine that there is a possibility of a PQC downgrade attack or a server configuration error.

[0121] More specifically, the PQC downgrade attack automatic detection module (140) can compare passive results with active results. For example, if the appearance / selection of a PQC KeyShare is observed in passive monitoring but only a legacy KeyShare is negotiated in the active monitoring results, it can be determined that there is a possibility of a downgrade attack or a misconfiguration. Additionally, if the expected provision of a PQC / Hybrid certificate is not confirmed and only a legacy certificate is provided, it can be determined that PQC is disabled or that there is a policy violation. The determination result can be recorded as a warning event and transmitted to the policy management module (150).

[0123] The policy management module (150) can generate a warning event based on the attack detection results of the PQC downgrade attack automatic detection module (140).

[0124] That is, the policy management module (150) can generate a warning event if it determines that there is a possibility of a PQC downgrade attack on the server (10) based on the attack detection results.

[0125] Additionally, the policy management module (150) can update the PQC application status database (160) based on various information transmitted, received, or generated during the operation of the PQC application status check and PQC downgrade attack detection system (100). At this time, the policy management module (150) can update the various information in the PQC application status database (160) by classifying it by server (10).

[0126] Referring again to FIG. 7, the policy management module (150) stores whether PQC is applied per server (10), the algorithm used, the certificate type, and whether client authentication is supported, and can generate a warning when a policy violation or abnormal state occurs.

[0128] The PQC application status database (160) stores various information transmitted, received, or generated during the operation of the PQC application status check and PQC downgrade attack detection system (100), classified by server (10). For example, the PQC application status database (160) may store PQC-related passive information (TLS version, SNI, SupportedGroups, KeyShare, whether a normal handshake has been completed, etc.), PQC-related active information (signature algorithm OID, certificate size, certificate extension field, certificate structure, SignatureAlgorithm list, etc.), PQC application status information (whether PQC signature is applied, whether PQC KEM is applied, certificate type, whether PQC-based client authentication is supported, etc.), PQC downgrade attack status, warning event-related information, etc., classified by server (10).

[0130] Then, with reference to FIG. 8, a method for automatically checking whether PQC is applied and detecting PQC downgrade attacks according to one embodiment of the present document will be described.

[0131] FIG. 8 is a flowchart illustrating a method for automatically checking whether PQC is applied and detecting PQC downgrade attacks according to one embodiment of the present document.

[0132] Referring to FIG. 8, a system (100) for checking whether PQC is applied and detecting PQC downgrade attacks according to one embodiment of the present document collects handshake packets of TLS 1.3 or DTLS 1.3 including ClientHello and ServerHello on a network, and analyzes the collected handshake packets to obtain passive information related to PQC for each server (10) (S110).

[0133] That is, the PQC application status check and PQC downgrade attack detection system (100) analyzes ClientHello and ServerHello messages to extract the TLS version, SNI, SupportedGroups and KeyShare, and determines whether a normal handshake has been completed based on the Finished message, thereby obtaining PQC-related passive information (TLS version, SNI, SupportedGroups, KeyShare, whether a normal handshake has been completed, etc.) for each server (10).

[0134] At this time, the PQC application status check and PQC downgrade attack detection system (100) can extract KeyShare from SupportedGroups and KeyShare extension fields.

[0136] In addition, the PQC application status check and PQC downgrade attack detection system (100) can obtain PQC-related active information for each server (10) by performing an active TLS connection to the identified server (10) based on PQC-related passive information (TLS version, SNI, SupportedGroups, KeyShare, whether a normal handshake has been completed, etc.) (S120).

[0137] That is, the PQC application status check and PQC downgrade attack detection system (100) analyzes the signature algorithm OID (Object Identifier), certificate size, certificate extension field, and certificate structure of the server certificate based on ServerHello and encrypted Certificate messages received from the server (10), and when a CertificateRequest message is received from the server (10), obtains the SignatureAlgorithm list requested by the server (10), thereby obtaining active information related to PQC for the server (10), such as the signature algorithm OID, certificate size, certificate extension field, certificate structure, SignatureAlgorithm list, etc.).

[0138] At this time, the PQC application status check and PQC downgrade attack detection system (100) can automatically perform an active TLS connection to the identified server (10) based on PQC-related passive information (TLS version, SNI, SupportedGroups, KeyShare, whether a normal handshake has been completed, etc.) for each server (10).

[0140] Then, the PQC application status check and PQC downgrade attack detection system (100) can obtain information on whether the server (10) has applied PQC based on PQC-related passive information (TLS version, SNI, SupportedGroups, KeyShare, whether a normal handshake is completed, etc.) and PQC-related active information (signature algorithm OID, certificate size, certificate extension field, certificate structure, SignatureAlgorithm list, etc.) (S130).

[0141] That is, the PQC application status check and PQC downgrade attack detection system (100) can obtain information on whether PQC is applied to the server (10) (PQC signature application status, PQC KEM application status, certificate type, etc.) by analyzing whether the server (10) has a PQC signature applied, whether the server (10) has a PQC KEM applied, and a certificate type indicating one of a Pure certificate, a Hybrid certificate, and a Composite certificate based on a signature algorithm OID, a KeyshareGroup ID, a certificate extension field, and a certificate structure.

[0142] Here, the signature algorithm OID can be configured to identify the PQC algorithm, legacy algorithms, or a combination thereof. Additionally, the KeyShareGroup ID can be analyzed to determine whether the PQC KEM algorithm is applied. Furthermore, the certificate structure can be analyzed to determine the certificate type, which represents one of a Pure certificate, a Hybrid certificate (which includes both the PQC signature algorithm and the legacy signature algorithm), or a Composite certificate (which includes multiple signature algorithms within the same certificate structure).

[0143] At this time, the PQC application status check and PQC downgrade attack detection system (100) may additionally determine whether the PQC signature is applied based on the certificate size and obtain information on whether the PQC is applied (whether the PQC signature is applied, whether the PQC KEM is applied, certificate type, etc.).

[0144] Additionally, the PQC application status check and PQC downgrade attack detection system (100) may determine that the server (10) supports PQC-based client authentication when a PQC-based algorithm is included in the SignatureAlgorithm list, and obtain information on whether PQC is applied (whether PQC signature is applied, whether PQC KEM is applied, certificate type, whether PQC-based client authentication is supported, etc.).

[0146] Then, the PQC application status check and PQC downgrade attack detection system (100) can detect whether a PQC downgrade attack has occurred by analyzing PQC-related passive information (TLS version, SNI, SupportedGroups, KeyShare, whether a normal handshake has been completed, etc.) and PQC-related active information (signature algorithm OID, certificate size, certificate extension field, certificate structure, SignatureAlgorithm list, etc.) according to a predefined comparison rule based on the same server (10) (S140).

[0147] That is, the PQC application status check and PQC downgrade attack detection system (100) can determine whether there is a PQC downgrade attack on the server (10) by comparing PQC-related passive information and PQC-related active information according to comparison rules based on the same SNI standard.

[0148] Here, the comparison rule may include at least one of the following: a first rule determining that there is a possibility of a PQC downgrade attack on the server (10) when a PQC KeyShare is observed in PQC-related passive information but only a legacy KeyShare is negotiated in PQC-related active information; a second rule determining that there is a possibility of a PQC downgrade attack on the server (10) when only a legacy certificate is provided despite expectations of providing a PQC or Hybrid certificate; and a third rule determining that there is a possibility of a PQC downgrade attack on the server (10) when a PQC-based SignatureAlgorithm request is observed but not requested in PQC-related active information.

[0150] Then, the PQC application check and PQC downgrade attack detection system (100) can generate a warning event based on the attack detection result (S150).

[0151] That is, the PQC application check and PQC downgrade attack detection system (100) can generate a warning event if it is determined that there is a possibility of a PQC downgrade attack on the server (10) based on the attack detection result.

[0153] Afterwards, the PQC application status check and PQC downgrade attack detection system (100) can update the PQC application status database (160) based on various information (S160).

[0154] That is, the PQC application status check and PQC downgrade attack detection system (100) can update the PQC application status database (160) based on various information transmitted, received, or generated during operation. At this time, the PQC application status check and PQC downgrade attack detection system (100) can update various information in the PQC application status database (160) by classifying it by server (10).

[0157] Then, with reference to FIGS. 9 to 13, a PQC encryption scheme switching management system according to one embodiment of the present document will be described in more detail.

[0158] FIG. 9 is a block diagram illustrating the configuration of the PQC cryptographic scheme transition management system illustrated in FIG. 1, FIG. 10 is a diagram illustrating an example of the configuration of the PQC cryptographic scheme transition management system according to one embodiment of the present document, FIG. 11 is a diagram illustrating the transition policy decision process based on a cryptographic agility policy model according to one embodiment of the present document, FIG. 12 is a diagram illustrating a dual-mode operation structure for forced execution and verification of the transition policy of the execution layer according to one embodiment of the present document, and FIG. 13 is a diagram illustrating the automatic rollback process in case of transition failure according to one embodiment of the present document.

[0159] Referring to FIGS. 9 and 10, the PQC cryptographic scheme transition management system (200) may include a transition input interface unit (210), a policy model management unit (220), a transition policy decision unit (230), a transition execution layer management unit (240), a transition failure detection and automatic rollback unit (250), and a transition history management unit (260).

[0160] The switching input interface unit (210) can receive results of automatic checking of whether PQC is applied and detection of PQC downgrade attacks from the PQC application check and PQC downgrade attack detection system (100).

[0161] That is, the switching input interface unit (210) can receive information on whether PQC is applied in TLS 1.3 or DTLS 1.3-based secure communication (whether PQC signature is applied, whether PQC KEM is applied, certificate type, whether PQC-based client authentication is supported, etc.) and the detection result of whether PQC downgrade attacks are supported. Of course, the switching input interface unit (210) may also receive PQC-related passive information (TLS version, SNI, SupportedGroups, KeyShare, whether a normal handshake is completed, etc.) and PQC-related active information (signature algorithm OID, certificate size, certificate extension field, certificate structure, SignatureAlgorithm list, etc.).

[0162] Here, the detection result of whether a PQC downgrade attack is detected may include at least one of the detection result of whether a KeyShare downgrade attack is detected, the detection result of whether a KeyShare Groups downgrade attack is detected, and the detection result of whether a SignatureAlgorithm downgrade attack is detected.

[0163] To explain further, the switching input interface unit (210) can receive from an external or internal system the detection results of whether the PQC algorithm is applied in TLS 1.3 or DTLS 1.3-based communication and the downgrade (Keyshare, Signature Algorithms).

[0164] More specifically, the switching input interface unit (210) can receive a judgment result for each server (10), client (20), or IoT device from a PQC application check and PQC downgrade attack detection system (100) operating in a network segment using TLS 1.3 or DTLS 1.3-based communication.

[0165] The judgment result may include, for example, the following information.

[0166] - Negotiated KeyShare Group and PQC KEM Application Status

[0167] - Server certificate signature algorithm type (PQC / Hybrid / Legacy)

[0168] - Whether Signature Algorithm downgrade occurred

[0169] - Whether there is a policy violation or setting inconsistency

[0170] The switching input interface unit (210) can store the information by mapping it to the switching target system identifier (IP, FQDN, device ID, etc.).

[0172] The policy model management department (220) can manage the crypto agility policy model.

[0173] Here, the cryptographic agility policy model may include allowed cryptographic algorithms, recommended and prohibited cryptographic algorithms and transition conditions, priority of cryptographic algorithms, transition rules based on application ranges and risk levels, and time-based or threat-level-based cryptographic algorithm decommissioning conditions.

[0174] In addition, the cryptographic agility policy model can be dynamically updated based on threat information or operational status.

[0175] To explain further, the policy model management unit (220) can store and manage cryptographic agility policies including allowed, recommended, and non-recommended cryptographic algorithms, transition priority, validity period, performance and risk criteria, etc.

[0177] The transition policy decision unit (230) can automatically determine the transition policy based on the PQC application status information, the PQC downgrade attack detection result and the crypto agility policy model.

[0178] Here, the transition policy may represent any one of RSA or ECC-based password retention, transition to Hybrid PQC, transition to Composite PQC, or transition to Pure PQC.

[0179] Referring again to FIG. 11, the transition policy decision unit (230) can automatically determine the transition stage of RSA / ECC maintenance, Hybrid, Composite, or Pure PQC by combining input results and policy information. In addition, the transition policy decision unit (230) can control certificate issuance, replacement, parallel operation, or maintenance according to the transition stage in conjunction with the PQC PKI system.

[0180] More specifically, the policy model determination unit (230) can determine the transition step by comparing the determination result received from the transition input interface unit (210) with the policy stored in the policy model management unit (220).

[0181] The password agility policy model may include the following rules.

[0182] - When PQC downgrade is detected → Force switch to Pure PQC

[0183] - If only PQC KEM is applied and the signature is legacy → Apply Hybrid Certificate

[0184] - For low-end devices → Maintain PQC application only for KEM

[0185] The policy model decision unit (230) can automatically determine the transition step by applying the corresponding rule.

[0186] Additionally, the policy model decision unit (230) can control the issuance of certificates in conjunction with the PQC PKI system or the certification authority (CA) according to the determined transition stage.

[0187] - Pure PQC Transition Phase → Issuance of PQC Signature-Based Certificates

[0188] - Hybrid Phase → Issuance of certificate including PQC + legacy signature

[0189] - Parallel Operation Phase → Maintain existing certificates + Parallel new PQC certificates

[0190] At this time, the policy model decision unit (230) can set the certificate validity period, renewal time, and revocation conditions according to the policy.

[0192] The transition execution layer management unit (240) can distribute the determined transition policy to the execution layer in the form of a password policy.

[0193] Here, the execution layer can enforce TLS / DTLS password settings according to the password policy distributed from the switching execution layer management unit (240) or observe and verify the password algorithm used in actual communication.

[0194] And, the execution layer represents at least one of a proxy module including a proxy-based execution layer that performs the same function in an application-changeless state, a gateway module, a crypto agility management agent representing an execution principal that directly applies and verifies a crypto policy, a service mesh sidecar module representing an orchestration layer for managing and deploying the proxy module or the crypto agility management agent on a large scale, and may be installed on at least one of a server (10), a client (20), or an IoT device.

[0195] To explain further, the transition execution layer management unit (240) can deploy or control / manage crypto agility management agents, etc. to the system determined as the transition target.

[0196] More specifically, the transition execution layer management unit (240) can deploy crypto agility management agents, etc., to the system determined as the transition target or activate existing agents.

[0197] The agent can be installed in at least one of the following environments.

[0198] - Server operating system (User Space or System Service)

[0199] - Container or virtual machine

[0200] - Embedded device firmware

[0201] Then, the execution layer can operate in Enforcement Mode, which enforces the password policy, or Observation Mode, which observes the password algorithm used in actual TLS / DTLS communication, in order to enforce TLS / DTLS password settings according to the password policy or to observe and verify the password algorithm used in actual communication. Here, Observation Mode may be a mode that collects and verifies the negotiated KeyShare group, signature algorithm, and certificate type.

[0202] Referring again to FIG. 12, the execution layer can automatically switch TLS / DTLS cipher settings based on the PQC certificate and security policy transmitted through the PQC cipher scheme switching management system (200).

[0203] More specifically, the execution layer cryptographic agility management agent operates in at least one of the following modes.

[0204] (a) Enforcement Mode

[0205] - Apply PQC certificate according to central policy

[0206] - Force change the cipher settings of the TLS / DTLS library

[0207] - Blocking unauthorized changes by local administrators or applications

[0208] (b) Observation Mode

[0209] - Observation of the algorithm used in the actual TLS / DTLS handshake

[0210] - Report any discrepancies with the policy to the central system

[0211] Additionally, the execution layer applies the following information transmitted from the PQC cryptographic scheme conversion management system (200).

[0212] - PQC Certificate or Hybrid Certificate

[0213] - PQC KEM algorithm parameters

[0214] - TLS / DTLS cipher suite settings

[0215] In this case, the transition can be applied at the session level or at the time of reconnection to minimize service interruption.

[0217] The transition failure detection and automatic rollback unit (250) can automatically restore to the previous password setting state if a communication failure is detected after transitioning to the transition policy.

[0218] That is, the transition failure detection and automatic rollback unit (250) can perform automatic recovery to the previous password setting state if any one of the following occurs: TLS / DTLS handshake failure, certificate verification error, or session creation failure.

[0219] Referring again to FIG. 13, the transition failure detection and automatic rollback unit (250) can enable uninterrupted and high-availability transitions by providing a rollback mechanism that automatically restores to the previous password setting state when communication failure or performance degradation occurs after the PQC transition.

[0220] More specifically, the transition failure detection and automatic rollback unit (250) can determine that a transition failure has occurred when any of the following occurs.

[0221] - TLS / DTLS handshake failed

[0222] - Certificate verification error

[0223] - Failed to create communication session

[0224] If a transition failure is detected, the system can automatically recover (rollback) by referring to the previously saved password settings and certificate status.

[0226] The transition history management unit (260) can record and manage the policy, password setting status, and actual application results before, during, and after the transition to the transition policy as evidence information.

[0227] That is, the transition history management unit (260) can store transition history including policy version, time of application, reason for transition, and whether to roll back.

[0228] To explain further, the transition history management unit (260) can record and manage the state before and after the transition, the type of algorithm, the policy version, the reason for the transition, and whether to roll back in the form of evidence.

[0229] More specifically, the conversion history management unit (260) can record the following information.

[0230] - Encryption system status before and after transition

[0231] - Applied policy version

[0232] - Switching reasons and detection events

[0233] - Whether a rollback occurred

[0234] The above history can be transmitted to a security audit system, a regulatory response system, or an external SIEM.

[0236] Then, with reference to FIG. 14, a method for managing the phased transition of a PQC cryptographic scheme based on a cryptographic agility management agent according to one embodiment of the present document will be described in more detail.

[0237] FIG. 14 is a flowchart illustrating a method for managing the phased transition of a PQC cryptographic scheme based on a cryptographic agility management agent according to one embodiment of the present document.

[0238] Referring to FIG. 14, the PQC cryptographic scheme transition management system (200) can receive information on whether PQC is applied (whether PQC signature is applied, whether PQC KEM is applied, certificate type, whether PQC-based client authentication is supported, etc.) and the result of detecting whether PQC is downgraded attack from the PQC application check and PQC downgrade attack detection system (100) (S210).

[0239] At this time, the PQC cryptographic scheme transition management system (200) may also receive PQC-related passive information (TLS version, SNI, SupportedGroups, KeyShare, whether a normal handshake has been completed, etc.) and PQC-related active information (signature algorithm OID, certificate size, certificate extension field, certificate structure, SignatureAlgorithm list, etc.) from the PQC application status check and PQC downgrade attack detection system (100).

[0240] Here, the detection result of whether a PQC downgrade attack is detected may include at least one of the detection result of whether a KeyShare downgrade attack is detected, the detection result of whether a KeyShare Groups downgrade attack is detected, and the detection result of whether a SignatureAlgorithm downgrade attack is detected.

[0242] Then, the PQC cryptographic scheme transition management system (200) can automatically determine the transition policy based on the cryptographic agility policy model, information on whether PQC is applied, and the detection result of whether PQC is downgraded (S220).

[0243] Here, the cryptographic agility policy model may include allowed cryptographic algorithms, recommended and prohibited cryptographic algorithms, transition conditions, priority of cryptographic algorithms, transition rules based on application ranges and risk levels, and time-based or threat-level-based cryptographic algorithm decommissioning conditions. Additionally, the cryptographic agility policy model may be dynamically updated based on threat information or operational status.

[0244] And, the transition policy may represent any one of maintaining RSA or ECC-based passwords, transitioning to Hybrid PQC, transitioning to Composite PQC, or transitioning to Pure PQC.

[0246] Then, the PQC cryptographic scheme transition management system (200) can distribute the determined transition policy to the execution layer in the form of a cryptographic policy (S230).

[0247] Here, the execution layer can enforce TLS / DTLS cipher settings according to the cipher policy distributed from the PQC cipher scheme switching management system (200) or observe and verify the cipher algorithm used in actual communication.

[0248] And, the execution layer represents at least one of a proxy module, a gateway module, a service mesh sidecar module, or a crypto agility management agent, and can be installed on at least one of a server (10), a client (20), or an IoT device.

[0249] Then, the execution layer can operate in Enforcement Mode, which enforces the password policy, or Observation Mode, which observes the password algorithm used in actual TLS / DTLS communication, in order to enforce TLS / DTLS password settings according to the password policy or to observe and verify the password algorithm used in actual communication. Here, Observation Mode may be a mode that collects and verifies the negotiated KeyShare group, signature algorithm, and certificate type.

[0251] Then, the PQC password scheme transition management system (200) can automatically restore to the previous password setting state if a communication failure is detected after transitioning to the transition policy (S240).

[0252] That is, the PQC cryptographic scheme transition management system (200) can perform automatic recovery to the previous password setting state if any of the following occur: TLS / DTLS handshake failure, certificate verification error, or session creation failure.

[0254] Afterwards, the PQC encryption system transition management system (200) can record and manage the policy, encryption setting status, and actual application results before, during, and after the transition to the transition policy as evidence information (S250).

[0255] That is, the PQC cryptographic scheme transition management system (200) can store transition history including policy version, time of application, reason for transition, and whether to roll back.

[0257] The operation according to the embodiments of this document described above may be implemented in the form of program instructions that can be executed through various computer means and recorded on a computer-readable storage medium. A computer-readable storage medium refers to any medium that participates in providing instructions to a processor for execution. A computer-readable storage medium may include program instructions, data files, data structures, or a combination thereof. Examples include magnetic media, optical storage media, memory, etc. Computer programs may be distributed over networked computer systems, and computer-readable code may be stored and executed in a distributed manner. Functional programs, code, and code segments for implementing the embodiments of this document will be readily deducible by programmers in the art to which the embodiments of this document belong.

[0258] The embodiments of this document are intended to illustrate technical concepts, and the scope of the technical concepts of the embodiments of this document is not limited by these embodiments. The scope of protection of the embodiments of this document shall be interpreted by the claims below, and all technical concepts within an equivalent scope shall be interpreted as being included within the scope of rights of the embodiments of this document. Explanation of the symbols

[0259] 10 : Server, 20 : Client, 100: PQC application status check and PQC downgrade attack detection system, 110: Passive TLS Traffic Monitoring Module, 120: Active TLS Connection Module, 130 : PQC Algorithm Discrimination Engine, 140 : PQC Downgrade Attack Auto-Detection Module, 150 : Policy Management Module, 160 : PQC Application Status Database, 200 : PQC Cryptographic Scheme Transition Management System, 210 : Switching input interface section, 220 : Policy Model Management Department, 230 : Transition Policy Decision Department, 240 : Transition Execution Layer Management Department, 250 : Switching failure detection and automatic rollback section, 260 : Conversion History Management Department

Claims

Claim 1 A system for automatically managing the phased transition of a Post-Quantum Cryptography (PQC) cryptographic scheme, comprising: a transition input interface unit that receives information on whether PQC is applied in secure communication based on Transport Layer Security (TLS) 1.3 or Datagram Transport Layer Security (DTLS) 1.3 and a result of detecting whether a PQC downgrade attack has occurred; a policy model management unit that manages a cryptographic agility policy model including allowed cryptographic algorithms, recommended cryptographic algorithms, prohibited cryptographic algorithms, and transition conditions; a transition policy determination unit that automatically determines a transition policy based on the information on whether PQC is applied, the result of detecting whether a PQC downgrade attack has occurred, and the cryptographic agility policy model; a transition execution layer management unit that distributes the determined transition policy in the form of a cryptographic policy to an execution layer that enforces TLS / DTLS cryptographic settings according to the transition policy or observes and verifies the cryptographic algorithm used in actual communication; and a transition failure detection and automatic rollback unit that automatically restores to the previous cryptographic setting state when a communication failure is detected after transitioning to the transition policy. Claim 2 In claim 1, the cryptographic agility policy model is a PQC cryptographic scheme transition management system that includes transition rules based on the priority, application range, and risk level of cryptographic algorithms. Claim 3 In paragraph 1, the cryptographic agility policy model is a PQC cryptographic scheme transition management system that includes time-based or threat-level-based cryptographic algorithm decommissioning conditions. Claim 4 In paragraph 1, the above transition policy represents any one of RSA or ECC-based password retention, transition to Hybrid PQC, transition to Composite PQC, or transition to Pure PQC, a PQC cryptographic scheme transition management system. Claim 5 In claim 1, the PQC cryptographic scheme transition management system, wherein the transition execution layer management unit distributes the transition policy in the form of the password policy to the execution layer representing at least one of a proxy module, a gateway module, a service mesh sidecar module, or a password agility management agent. Claim 6 In claim 1, the execution layer is a PQC cryptographic scheme switching management system that operates in an Enforcement Mode for forcibly applying the cryptographic policy, or in an Observation Mode for observing the cryptographic algorithm used in actual TLS / DTLS communication. Claim 7 In paragraph 6, the above-mentioned Observation Mode is a PQC cryptographic scheme transition management system that is a mode for collecting and verifying negotiated KeyShare groups, signature algorithms, and certificate types. Claim 8 In claim 1, the above-mentioned transition failure detection and automatic rollback unit performs automatic recovery to a previous password setting state when any one of a TLS / DTLS handshake failure, a certificate verification error, or a session creation failure occurs, in a PQC password scheme transition management system. Claim 9 A PQC encryption system transition management system further comprising, in claim 1, a transition history management unit that records and manages the policy, password setting status, and actual application results before, during, and after transition to the transition policy as evidence information, and stores a transition history including the policy version, application time, reason for transition, and rollback status. Claim 10 In claim 1, the above-mentioned switching input interface unit further receives PQC-related passive information and PQC-related active information, a PQC cryptographic scheme switching management system. Claim 11 A PQC cryptographic scheme transition management system according to claim 1, wherein the detection result of whether a PQC downgrade attack has occurred includes at least one of the detection result of whether a KeyShare downgrade attack has occurred, the detection result of whether a KeyShare Groups downgrade attack has occurred, and the detection result of whether a SignatureAlgorithm downgrade attack has occurred. Claim 12 In paragraph 1, the above-mentioned cryptographic agility policy model is a PQC cryptographic scheme transition management system that is dynamically updated based on threat information or operational status. Claim 13 In claim 1, the execution layer is a PQC cryptographic scheme switching management system installed on at least one of a server, a client, or an IoT device. Claim 14 In claim 1, the system is a PQC cryptographic scheme transition management system that automatically manages the transition of the PQC cryptographic scheme in a virtual machine environment, a container environment, or a cloud environment. Claim 15 In paragraph 1, the above system is a PQC cryptographic scheme transition management system applicable to a power infrastructure environment, a financial infrastructure environment, or a public infrastructure environment. Claim 16 A method for managing the transition of a Post-Quantum Cryptography (PQC) cryptographic scheme, performed by a system that automatically manages the transition of a PQC cryptographic scheme, comprising: receiving information on whether PQC is applied in secure communication based on TLS (Transport Layer Security) 1.3 or DTLS (Datagram Transport Layer Security) 1.3 and a result of detecting whether a PQC downgrade attack has occurred; automatically determining a transition policy based on a cryptographic agility policy model including allowed cryptographic algorithms, recommended cryptographic algorithms, prohibited cryptographic algorithms, and transition conditions, and the information on whether PQC is applied and the result of detecting whether a PQC downgrade attack has occurred; distributing the determined transition policy in the form of a cryptographic policy to an execution layer that enforces TLS / DTLS cryptographic settings according to the transition policy or observes and verifies the cryptographic algorithm used in actual communication; and automatically restoring to the previous cryptographic setting state if a communication failure is detected after the transition to the transition policy. Claim 17 In paragraph 16, the above cryptographic agility policy model is a PQC cryptographic scheme transition management method that includes transition rules based on the priority, application range, and risk level of cryptographic algorithms. Claim 18 In paragraph 16, the above cryptographic agility policy model is a PQC cryptographic scheme transition management method including time-based or threat-level-based cryptographic algorithm decommissioning conditions. Claim 19 In paragraph 16, the above transition policy represents a PQC cryptographic scheme transition management method, which indicates any one of maintaining RSA or ECC-based cryptography, transitioning to Hybrid PQC, transitioning to Composite PQC, or transitioning to Pure PQC. Claim 20 In claim 16, the execution layer represents at least one of a proxy module, a gateway module, a service mesh sidecar module, or a crypto agility management agent, a PQC crypto scheme switching management method. Claim 21 A PQC encryption system transition management method further comprising, in paragraph 16, a step of recording and managing the policy, password setting status, and actual application results before, during, and after transition to the above transition policy as evidence information. Claim 22 A computer program stored on a computer-readable storage medium for executing the PQC cryptographic scheme conversion management method described in any one of paragraphs 16 through 21 on a computer.

Images