Real-time integrity verification system and method including third-party certification-based independent verification structure, and computer-readable recording medium therefor

Abstract

The present invention relates to a system and a method for verifying, in real time, whether a reference state pre-certified by a third-party certification institution is maintained even during actual operation, and a computer-readable recording medium therefor. The system may comprise: a reference identification value registry; an integrity monitoring agent that generates an execution identification value on a functional block basis; an independent verification server that compares the execution identification value with a reference identification value; and a policy-based response module according to a verification result. The verification result may be generated and stored as a digital integrity report, and an external user or institution may view and verify the digital integrity report via a public verification interface. Accordingly, the validity of pre-certification can be extended to the time of operation, and the operational reliability of the system can be improved.

Description

Real-time integrity verification system and method including a third-party authentication-based independent verification structure, and a computer-readable recording medium for the same

[0001] The present invention relates to a technology for ensuring reliability during the operation of a mission-critical digital system, and more specifically, to a system and method for continuously extending and guaranteeing the validity of prior certification until the point of operation by verifying in real time whether a standard state previously verified or certified by a third-party certification body is continuously maintained during actual operation, and by providing a structure capable of policy-based response and external verification based on the results.

[0002] The present invention is applicable to systems including execution logic combined with software, firmware, or hardware, and applies to structures including program code executed on a processor as well as dynamic execution elements such as execution states loaded in memory, setting parameters, control signals, or artificial intelligence-based decision flows.

[0003] In addition, the present invention includes a structure for comparing and determining the execution state in a verification area deployed in a network area, computing environment, or execution environment separated from the system to be verified, and the verification result may be provided so that it can be checked through an interface accessible to an external entity.

[0004] Here, the identification value is generated based on a cryptographic hash value in the basic embodiment, and a message authentication code, a digital signature value, or a hardware-based measurement value may be applied in the optional embodiment.

[0005] The present invention relates to a technology applicable to systems requiring integrity verification of functional logic during execution, configured such that a structure for generating and comparing identification values ​​at the function block level is applied identically in various execution environments including servers, clouds, virtualization environments, edge devices, and embedded systems.

[0006] The present invention has a common core structure comprising a third-party authentication-based reference state definition, generation of execution identification values ​​during operation, comparison and judgment in an independent verification domain, policy-based response, and an externally verifiable report structure. The core structure can be applied by varying the verification target function blocks, policy conditions, and disclosure scopes according to the characteristics of each industry, such as finance, medical, public systems, industrial control, gambling games, and artificial intelligence judgment systems.

[0007] Digital systems perform core decision-making, control, and service delivery functions in various fields, including finance, public services, healthcare, national defense, industrial control, transportation, gambling, and high-risk artificial intelligence judgment systems. A significant number of these are mission-critical systems where malfunction, unauthorized modification, or compromise of integrity can lead to significant social, economic, or safety risks. In such systems, merely ensuring that functions are provided is insufficient; the key element in ensuring reliability is whether the actual operational state consistently aligns with pre-approved or verified conditions.

[0008] Traditionally, testing, evaluation, certification, or conformity verification procedures have been widely used to ensure the reliability of such digital systems. For example, specific software or systems can be verified by third-party certification bodies or testing laboratories in terms of functional suitability, security, performance, safety, or compliance with standards, and certification or approval status may be granted based on the results. These procedures are effective for verifying whether system configurations or deliverables at a specific point in time meet predefined criteria during the pre-deployment phase.

[0009] However, conventional certification or verification systems are mostly limited to structures that verify conformity or test pass status at a specific point in time during the pre-deployment phase; consequently, they have limitations in that they cannot continuously guarantee whether the system maintains the reference state established at the time of certification even after it enters actual operation. In other words, while conventional pre-certification can verify conformity at the time of certification, it fails to provide a structure that verifies in real-time whether the run-time state continues to align with the certified reference state.

[0010] In particular, in cloud-based services, SaaS structures, container-based architectures, and DevOps-based continuous deployment environments, code changes, configuration changes, library updates, policy changes, environment reconfigurations, or runtime patches occur frequently, and even for the same system, different execution states may exist depending on the point in time or instance. In such environments, it is difficult to guarantee the identity, consistency, and persistence of the authentication status of the operational state solely through static verification based on the deployment time.

[0011] Furthermore, existing integrity verification often relies primarily on log analysis, post-hoc audits, or status checks through centralized management systems, resulting in a time lag between the execution state and the verification point. Consequently, it is difficult to immediately determine whether the operational state at a specific point in time directly corresponds to a baseline state; this approach has a structural limitation in that abnormal conditions can only be recognized after they are reflected in the results. In particular, while this method may partially verify the integrity of the code itself, it cannot directly guarantee whether the actual execution environment, configuration state, memory resident state, call flow, or policy application state is structurally consistent with the baseline state.

[0012] Meanwhile, existing integrity verification structures often remain limited to comparing data across the entire system or within limited units, making it difficult to precisely identify local deviations occurring in specific functional units, conditional branching, policy interpretation routines, or processing paths within the system. Verification at the simple file or system-wide level alone makes it difficult to structurally distinguish detailed variations within the logic during actual operation; consequently, the analysis of anomaly points, scope of impact, and causes may be restricted.

[0013] Furthermore, in industries requiring high reliability, although requirements for maintaining and monitoring the integrity of system states during operation are repeatedly presented in international standards, industry standards, or regulatory criteria, conventional technologies have often addressed these requirements at the level of "internal management procedures of the operating entity" or "post-event tracking systems." In other words, structural technical means have not been sufficiently presented to directly correlate the state during execution with a pre-certified reference state, independently determine consistency at the time of execution, and enable external entities to reproducibly verify the results.

[0014] Particularly for mission-critical systems, the reliability of certification is not sufficient if established only prior to deployment; it must be possible to continuously verify whether the actual operational state is identical to the pre-certified state. Nevertheless, conventional technologies have not sufficiently provided technical means to structurally bridge the gap between pre-certification and operational reliability. Therefore, a new technical structure is required that can independently and reproducibly verify in real-time whether the reference state, determined in advance by a third-party certification body, is continuously maintained during actual operation.

[0015] The core technical problem that this invention aims to solve is to overcome the limitations of existing structures that cannot verify in real time whether the standard state of a digital system, which has been verified or certified in advance by a third-party certification body, is continuously maintained during actual operation.

[0016] More specifically, since most conventional authentication or verification systems remain in a pre-authentication structure that confirms conformity at a specific point in time prior to deployment, it is structurally difficult to guarantee that the system remains in an authenticated state even if code, settings, execution environment, memory state, loaded modules, policy application state, or decision flow is changed or deviated during actual operation after authentication. Accordingly, the primary objective of the present invention is to provide a structure capable of correlating and comparing a third-party authentication-based reference state with a state during actual operation according to the same verification criteria, and determining whether they match in real time at the time of execution.

[0017] Furthermore, the present invention aims to enable the identification, at the level of a function block or a corresponding logical execution unit, of local logic deviations, unauthorized modifications to specific function blocks, deviations from specific execution paths, or partial configuration changes that are difficult to identify through conventional verification at the overall system or file level alone. Through this, the invention aims to structurally detect abnormal conditions occurring in specific function units even when the entire system appears to be operating normally, and to more precisely identify the scope of their impact and their causes.

[0018] In addition, the present invention aims to ensure that the integrity judgment regarding the state during execution is performed in an independent verification domain separated from the execution environment and the operating entity of the system under verification, thereby generating verification results without direct influence from the operating entity or the same execution environment. Accordingly, the purpose is to secure the objectivity, reproducibility, and external reliability of the verification results and to structure the operational reliability of a mission-critical system in a form that can be guaranteed by a third party.

[0019] Furthermore, the present invention aims to ensure that integrity verification results are not limited to simple detection or internal warnings, but are linked to policy-based judgment and response structures, thereby enabling them to be connected to actual control or protection measures—such as blocking, isolation, session termination, alternative processing, retries, or switching to safe mode—when an abnormal state occurs. Through this, the invention aims to provide a structure in which integrity verification is not limited to providing information for post-audit purposes but is directly linked to actual operational control.

[0020] Furthermore, the present invention aims to secure the tamper-proofness, traceability, and external independent verification of verification results by generating a verification result as a structured digital integrity report and providing time information, signature information, linkage information, or a chain structure to the report. Moreover, the invention aims to extend the reliability of the certification to the operational point and secure the possibility of third-party assurance regarding the operational state by enabling external users, auditing bodies, or regulatory bodies to view and verify the report and related verification data through a public verification interface.

[0021] In addition, the present invention aims to provide an operational integrity guarantee system that is commonly applicable to systems having different operational structures by enabling the same core verification structure to be applied in various execution environments, such as servers, clouds, virtualization environments, container environments, edge devices, embedded systems, and artificial intelligence-based decision systems.

[0022] Ultimately, the present invention aims to provide an integrated technical structure that includes a definition of a reference state based on third-party authentication, generation of execution identification values ​​during operation, comparison and judgment in an independent verification domain, policy-based response, and an externally verifiable report structure, so that the trust of prior authentication can be continuously established even during actual operation.

[0023] To solve the above problem, a system according to one embodiment of the present invention may include a reference identification value registry that stores a reference identification value generated or approved by a third-party certification authority, an integrity monitoring agent that collects an execution state from a system in operation and generates an execution identification value in the form of a function block, an independent verification server that compares the execution identification value and the reference identification value to determine whether the current operating state is consistent with an authenticated reference state, and a policy-based response module that performs a policy-based response according to the verification result.

[0024] The above reference identifier registry may be configured to store and manage reference states verified or certified by a third-party certification authority in units of functional blocks, and the reference identifiers may be managed together with metadata including functional block identifiers, version information, normalization profile information, creation time information, certification authority identification information, or policy-related information. Accordingly, the reference state is not limited to a simple set of hash values ​​but can be maintained as a structured reference standard that can be directly compared with the actual operational state.

[0025] The integrity monitoring agent described above can collect code, configuration, memory state, execution events, execution context, or equivalent operational state information from the operating system, and generate execution identifiers by normalizing and structuring this information in units of functional blocks. In the basic embodiment, the execution identifier may be generated based on a cryptographic hash, and, if necessary, may be combined with relevant metadata, environment information, or time-information and transmitted to an independent verification server. At this time, the collection of memory state is not limited to a method of comprehensively dumping the entire memory space, but may be selectively performed within a meaningful range for verification purposes, such as executable code areas, loading module areas, critical areas, or policy-designated monitoring areas.

[0026] The above-described independent verification server may be configured to operate in a verification domain that is organizationally, logically, or network-wise separated from the operating environment of the system under verification. It may compare the execution identifier with the reference identifier at the functional block level and determine the integrity status by including related metadata and execution environment information. This determination is intended to evaluate the direct consistency between the reference state and the operational state; it is not limited to a simple comparison of code identity but may be configured to evaluate whether the approved execution environment, policy identifier, normalization condition, and structural execution condition are simultaneously satisfied. Accordingly, the present invention can determine in real time whether a pre-certified reference state is continuously maintained during actual operation.

[0027] The independent verification server described above can determine whether divergence has occurred based on the comparison result, and if a divergence state is determined, it may be configured to perform a response according to a predefined policy in conjunction with the policy-based response module. The policy-based response may include at least one of warning, blocking, isolation, session termination, alternative processing, retry, function restriction, or safe mode transition, and may be applied differentially according to the importance of the function block, divergence type, scope of impact, policy priority, or risk level.

[0028] In addition, the system according to the present invention may be configured to generate the verification results and response results in the form of a digital integrity report. The digital integrity report may include one or more of verification target identification information, function block identification information, reference identification value, execution identification value, comparison or judgment result, time of verification execution, creation entity information, policy identifier, response action information, or previous report reference information, and may be combined with a digital signature, timestamp authentication information, and a hash chain structure as needed.

[0029] The digital integrity report described above may be recorded in an immutable repository, a WORM storage structure, an append-only storage structure, or an equivalent storage structure, thereby ensuring the tamper-proofness, historical continuity, and traceability of the verification results. Furthermore, the report or related verification data may be provided to external users, auditing bodies, or regulatory bodies through a public verification interface, allowing such external entities to view and independently verify it. Accordingly, the present invention extends the results of pre-certification beyond a simple pre-distribution conformity check into a continuous verification structure linked to the actual operational state.

[0030] Furthermore, the present invention may optionally define the verification scope to the entire system, service unit, function block unit, session unit, or request unit, and may be configured to adaptively adjust the verification intensity, collection scope, or response level according to operating conditions or policy conditions. The execution result source consistency verification, cross-channel verification, and external disclosure structure via a physical output device are extended embodiments that can be optionally combined depending on the specific application environment, and the common core structure of the present invention is established by the definition of a reference state based on third-party authentication, generation of execution identifiers during operation, comparison and judgment in an independent verification domain, policy-based response, and an externally verifiable digital integrity report structure. However, such structures may be understood as optional extended embodiments that complement the common core structure of the present invention.

[0031] Consequently, the present invention provides technical means to structurally extend and guarantee the validity of pre-certification until the actual operation point by organically combining third-party authentication-based reference state definition, generation of execution identification values ​​during operation, comparison and judgment in an independent verification domain, policy-based response, and an externally verifiable report structure.

[0032] The present invention is configured to directly compare a reference state, determined in advance by a third-party certification authority, with the actual run-time state within an allowed time range at or immediately after execution. By doing so, it eliminates the temporal discontinuity inherent in conventional pre-certification structures and provides the technical effect of continuously extending and guaranteeing the validity of certification until the point of operation. In particular, the present invention is configured to determine in real-time at the functional block level whether a mission-critical system still maintains an authenticated state during actual operation. This provides the effect of expanding the existing certification system, which was limited to verifying conformity prior to deployment, into a structure that guarantees reliability during operation.

[0033] Furthermore, the present invention is configured to generate and compare execution identification values ​​based on function blocks or corresponding logical execution units, thereby providing the effect of precisely detecting local logic deviations, deviations in specific execution paths, partial configuration changes, or unauthorized changes to specific judgment routines that are difficult to identify through verification at the entire file or system level. Accordingly, the location and scope of influence of an abnormal state can be identified more directly, and the precision of subsequent response and the possibility of root cause analysis can be improved.

[0034] Furthermore, the present invention provides a structure capable of reproducibly deriving identical verification results under identical conditions by configuring execution identifiers and reference identifiers to be generated and compared according to predefined generation rules, normalization rules, and comparison procedures. Accordingly, the reproducibility, traceability, and auditability of verification results can be enhanced, and a foundation is secured to independently review the operational status and verification results at a specific point in time thereafter.

[0035] Furthermore, the present invention is configured so that integrity judgment is performed in an independent verification domain that is organizationally, logically, or operationally separated from the system under verification, thereby ensuring that the verification results are independent from the direct influence of the operating entity or the same execution environment, which can enhance the objectivity and reliability of the verification results. This independence serves as a structural differentiator that distinguishes it from a simple internal state monitoring structure and provides a basis for external users, auditing bodies, or regulatory bodies to place greater trust in the verification results.

[0036] Furthermore, since the present invention can link verification results with actual control procedures through a policy-based response structure, it enables subsequent responses—such as blocking, restriction, alternative processing, warnings, retries, or switching to safe mode—to be performed in real-time or near-real-time, rather than merely detecting abnormal conditions. Accordingly, a technical effect is achieved where integrity verification results are directly linked to actual operational control, thereby simultaneously improving system safety, operational stability, and the ability to prevent the spread of accidents.

[0037] Furthermore, the present invention structures the verification results in the form of a digital integrity report and is configured to combine signatures, timestamp information, linkage information, or equivalent trust-granting elements into the report, thereby enhancing the tamper-proofness, historical continuity, and the possibility of independent external verification of the verification results. By configuring the report so that it can be provided to external entities through a public verification interface, the possibility of external verification of the verification results without relying on an operator can also be secured.

[0038] Furthermore, by resolving the gap between pre-certification and actual operating status in real time, the present invention can simultaneously secure continuous operational reliability, third-party assurance, reproducibility, independent verifiability, and policy-based control capabilities that existing static certification or post-audit-centric structures could not provide. Accordingly, the present invention provides the effect of being utilized as an operational reliability infrastructure in various mission-critical digital systems requiring high reliability, such as finance, public sector, healthcare, national defense, industrial control, transportation, gambling games, and high-risk artificial intelligence systems.

[0039] Consequently, the present invention provides the effect of fundamentally improving the operational reliability and verifiability of mission-critical systems by extending the results of pre-certification from being limited to simple pre-deployment conformity verification into a continuous assurance system structurally linked to the actual operational state.

[0040] FIG. 1 is a diagram illustrating the overall system configuration including a third-party authentication-based real-time integrity verification and public verification structure according to an embodiment of the present invention. The diagram illustrates the structural relationships and data flow between an authentication domain, an operation domain, an independent verification domain, a response and reporting domain, and a public interface domain. It also illustrates the overall flow of registering a reference identifier, verifying an execution identifier, policy-based response, generating an integrity report, and providing it externally.

[0041] FIG. 2 is a diagram illustrating a trust boundary separation architecture according to an embodiment of the present invention. The diagram illustrates a structure in which a certification authority, an operating system, an independent verification organization, and an external verification entity operate within trust boundaries separated from one another. It also illustrates a unidirectional or controlled data flow structure through signed data transmission and a limited feedback channel.

[0042] FIG. 3 is a diagram illustrating an end-to-end trust flow according to an embodiment of the present invention. The diagram sequentially illustrates the entire process from authentication, generation and registration of reference identifiers, collection of execution identifiers, integrity comparison, policy application, report generation, assignment of digital signatures and timestamps, immutable storage, and external verification.

[0043] FIG. 4 is a diagram illustrating an input element normalization structure for a deterministic build according to an embodiment of the present invention. The diagram illustrates a process in which a normalization module is applied to source code, environment variables, and build logs to generate standardized data from which non-deterministic elements are removed. Through this, a structure is shown that ensures a reproducible build input state.

[0044] FIG. 5 is a diagram illustrating a structure for generating reference identification values ​​based on multiple hashes and a Merkle Tree according to an embodiment of the present invention. The diagram illustrates a process of generating multiple hashes for normalized build outputs and environment metadata, and combining them into a Merkle Tree structure to generate a root hash. It also illustrates a structure in which an environment hash and a timestamp are combined.

[0045] FIG. 6 is a diagram illustrating the process of generating and registering a deterministic build-based reference identification value according to an embodiment of the present invention. The diagram illustrates the procedure in which a final reference identification value is registered in a registry through source input, normalization, build execution, identification value generation, metadata combination, verification, and digital signature.

[0046] FIG. 7 is a diagram illustrating the structure of a real-time integrity verification system in various industrial environments according to an embodiment of the present invention. The diagram illustrates the linkage structure between a plurality of verification target systems, a reference value management server, a central verification server, an immutability repository, and an external verification entity. It also illustrates the policy-based control flow during the transmission of identification values ​​and anomaly detection during operation.

[0047] FIG. 8 is a diagram showing the internal structure of a high-reliability verification server according to an embodiment of the present invention. The diagram illustrates a structure in which an external verification interface, an integrity verification engine, a policy-based response engine, a response execution engine, a report generation engine, and a storage and auditing engine are hierarchically configured.

[0048] FIG. 9 is a diagram illustrating a RIMA-based execution integrity identifier generation and pre-verification process according to an embodiment of the present invention. The diagram illustrates the main flow of execution monitoring, normalization, function block identification, identifier generation, metadata combination, and secure transmission, along with the flow of self-integrity verification and anomaly detection.

[0049] FIG. 10 is a diagram illustrating the process of generating an integrity identifier during operation according to an embodiment of the present invention. The diagram illustrates a pipeline structure leading to the collection of execution events, the generation of a hash in the form of a function block, the combination of execution contexts, and the generation of an execution identifier. It also illustrates a structure in which a static file integrity verification process is performed in parallel.

[0050] FIG. 11 is a diagram illustrating the flow of integrity verification and policy response at the functional block unit level according to an embodiment of the present invention. The diagram illustrates the flow of generating identification values ​​for multiple functional blocks, comparison with reference identification values, integrity verification, policy evaluation and response execution, and storage of verification results.

[0051] FIG. 12 is a diagram illustrating a self-check-based fault response and retry flow according to an embodiment of the present invention. The diagram illustrates a structure that branches into normal execution or execution blocking and recovery procedures based on the self-check result. It also illustrates the process of recording each processing result in an immutable log.

[0052] FIG. 13 is a diagram showing a time-test authentication structure according to an embodiment of the present invention. The diagram illustrates the process in which a request for a report hash is transmitted to a time-test authentication authority, and an authentication token is generated and combined with the report.

[0053] FIG. 14 is a diagram illustrating a hash chain-based integrity report management structure according to an embodiment of the present invention. The diagram illustrates a structure in which an integrity report is stored in a chain form by being linked with a previous report hash along with a digital signature and a timestamp.

[0054] FIG. 15 is a diagram showing the data structure of a verification report according to an embodiment of the present invention. The diagram illustrates a report structure including a timestamp, a reference hash value, an execution hash value, a comparison result, policy information, and a previous report hash.

[0055] FIG. 16 is a diagram showing the data model structure of an integrity verification record according to an embodiment of the present invention. The diagram illustrates the relationships between a reference record, an execution record, a verification record, a policy evaluation record, a corresponding execution record, a report, and a storage record as a data model.

[0056] FIG. 17 is a diagram illustrating a public verification architecture according to an embodiment of the present invention. The diagram illustrates a structure in which a user, an auditing body, and a regulatory body view and verify reports and verification data through a verification interface.

[0057] FIG. 18 is a diagram illustrating an authority-based access control structure according to an embodiment of the present invention. The diagram illustrates a structure in which the scope of access to verification data is controlled according to user roles, and results are provided through APIs and dashboards.

[0058] FIG. 19 is a diagram showing an application structure for each industrial sector according to an embodiment of the present invention. The diagram illustrates a structure in which standards applicable to multiple industrial sectors and key requirements correspond.

[0059]

[0060]

[0061] The best mode according to one embodiment of the present invention is implemented as an integrated integrity verification system that generates reference identification values ​​defined in units of functional blocks in a deterministic build environment through a third-party certification authority, collects the execution status of an operating system in real time and performs comparative verification on an independent verification server, performs policy-based control according to the results, and records the verification and control process in a digital report and chain of custody structure.

[0062] In this embodiment, the generation of a reference identifier is performed based on a deterministic build environment, and the deterministic build environment may be configured using a container-based execution environment. In one embodiment, the environment is implemented using container technology such as Docker, and to ensure that the same output is always generated for the same input, the base image used for the build is designated as an image having a fixed hash value, and the compiler version, build toolchain, and library dependencies are explicitly fixed. Additionally, environment variables, system time, timezone, file sorting order, and random seed used during the build process are controlled or removed in a deterministic manner, and the source code is input in a state normalized to canonical form. Accordingly, it is configured to generate the same output for the same build input.

[0063] The output generated in the deterministic build environment described above is divided into functional blocks, and a cryptographic hash-based identifier is generated for each functional block. This identifier is stored along with metadata including a hash algorithm identifier, a build environment identifier, and a time of creation. A third-party certification authority assigns digital signatures and authentication information to the identifier and registers it in a reference state registry. The reference state registry operates in an authentication domain separate from the system under verification, and the verification server performs verification by referencing the reference identifier registered in the registry.

[0064] The execution status of the system in operation is collected by a Runtime Integrity Monitoring Agent (RIMA), which is configured to collect data including running processes, code and libraries loaded in memory, configuration values, policy application status, and execution context. The collected data is used as input for generating functional block-unit identifiers or extracting metadata, and non-deterministic elements are separated into separate metadata during the collection process. Additionally, the collected data is protected from tampering through encryption or message authentication code-based protection during transmission, and a verification server performs a verification operation after verifying the integrity of the received data.

[0065] The independent verification server performs integrity verification by comparing the identifier generated from the execution state with the reference identifier stored in the reference state registry. This verification is performed by comprehensively considering not only the match of the function block identifiers but also metadata consistency and policy conditions, and the result is classified into one of the following states: PASS, WARNING, DEGRADED, or CRITICAL. This state classification is determined according to predefined thresholds and policy rules and is used as a criterion for determining the response level in the subsequent policy-based judgment step.

[0066] The policy-based decision module receives the verification result as input, determines the response level according to predefined policy rules, and generates the result as a structured control command object. The control command object includes a command identifier, a target function block identifier, an action type, an execution condition, an execution priority, a rollback flag, and a validity period; it also includes information such as a nonce and a sequence number to prevent replay attacks and can be protected by a digital signature.

[0067] The above control command is executed by a Runtime Control Agent (RCA), which performs control over the target function block after verifying the signature, validity, and execution conditions of the command. The control actions may include execution suspension, function restriction, network blocking, switching to an alternative module, or entering a safe state, and are configured to perform a rollback or fallback procedure if an error occurs during execution.

[0068] Verification results, policy judgment results, and control execution results are generated as digital report objects, which are stored along with digital signatures and timestamps. These report objects are linked to a separate chain of custody structure, and each report and related event is managed through a hash-based linkage structure that includes the hash value of the previous record and the hash value of the current record. Accordingly, the immutability and traceability of the entire verification process are ensured.

[0069] The aforementioned digital report may be provided to external users, auditing bodies, or regulatory bodies through a public verification interface, and external verification entities can independently verify its integrity using the hash value, digital signature, and timestamp information included in the report. Furthermore, the public verification structure is configured to control access rights based on user type, thereby ensuring both publicness and security simultaneously.

[0070] According to the best mode of the present invention configured as described above, it is possible to provide an integrated trust infrastructure that can guarantee the integrity of a digital system in operation in real time in a reproducible and verifiable manner, perform policy-based automatic response in the event of an anomaly, and reliably verify the results externally.

[0071] The above system can be implemented in various deployment structures, and in one embodiment, the integrity verification system may be configured in a centralized or distributed architecture. In the centralized structure, a reference state registry and an independent verification server are deployed in a cloud-based environment, and execution state data from multiple verification target systems can be collected via a network to perform integrated verification.

[0072] In addition, in one embodiment, the system is implemented as a Software as a Service (SaaS) to provide a central verification service for verification target systems located in multiple different operating environments, and a user or operator can view verification results or set policies through a network interface.

[0073] In another embodiment, the system may be implemented in an on-premise environment, and an independent verification server may be deployed within the same network area or physical environment as the system to be verified, so that integrity verification can be performed without an external network connection. In this case, it operates in a closed network environment in accordance with security requirements, and external verification entities may access it restrictively through a separate approval procedure.

[0074] Additionally, the system may include a verification module deployed in an Edge environment and can perform integrity verification based on a local reference state even in environments where network connectivity is limited or latency occurs. In this case, a portion of the reference state registry is stored in a cache form and can be synchronized with a central system according to a set period or event.

[0075] Each of the above components may be executed in physical hardware, a virtual machine, or a container-based environment, and operates on a computing device including a processor, memory, storage device, and network interface. Additionally, communication between the components is performed through an authenticated communication channel and is configured to maintain data integrity and confidentiality.

[0076]

[0077] The present invention relates to a structure for verifying the integrity of core logic executed during operation in real time in various digital information systems, including finance, medical, public administration, gambling games, and artificial intelligence judgment systems. In particular, it is configured to independently determine the integrity status in an execution environment by comparing an execution identification value generated in the operating environment with a reference identification value pre-registered in a third-party domain, based on an identification value defined at the functional block level.

[0078] The above system is configured to determine the integrity status based on data collected during execution and to perform automatic responses according to predefined policies when an abnormal state is detected. In addition, verification results and response history are generated as a structured digital integrity report, and said report can be provided for verification by external users, auditing bodies, or regulatory bodies.

[0079] The above structure is implemented through a series of processing steps including the generation of identifiers at the functional block level, the generation of reference values ​​based on a deterministic build environment, the generation of identifiers reflecting the execution state, comparison and judgment in an independent verification domain, policy-based response, and the recording of immutability of verification results and public verification. This structure is configured to detect various types of integrity deviations that may occur in the execution environment, including code changes, configuration tampering, execution flow anomalies, and data modification.

[0080] The structure of the present invention complements the limitations of existing pre-certification-centric verification structures and provides an extended verification system for ensuring integrity during operation by combining a third-party authentication-based reference value generation procedure with an in-execution verification procedure. Furthermore, the structure can be designed to align with international standard-based testing and verification procedures and can be utilized as a foundational structure for securing the reliability and safety required in various industrial fields.

[0081] Embodiments of the present invention are described below with reference to the attached drawings. The described embodiments are merely examples to aid in understanding the present invention and do not limit the technical scope of the invention. A person skilled in the art may make various modifications and changes within the scope of the technical scope of the present invention, and all such modifications and equivalent structures should be interpreted as being included within the scope of the rights of the present invention.

[0082] 1. Definitions and Hash Policy

[0083] 1.1 Definitions

[0084] The key terms used in the present invention and claims are defined as follows and may be interpreted according to such definitions throughout this specification. Each term is described clearly to reduce technical ambiguity and to ensure a consistent understanding by a person skilled in the art.

[0085] Terms not defined in this specification may be interpreted according to the meaning generally understood by those skilled in the art of the present invention.

[0086] 1.1.1 System and Basic Concepts

[0087] 1.1.1.1 Digital System

[0088] A digital system is composed of one or more computing devices, software, or a combination thereof to perform the processing, storage, transmission, or control of data, and

[0089] It refers to a system that generates specific results or performs physical or logical operations based on input data.

[0090] The above digital system may be composed of a single device, or

[0091] It may include a distributed structure composed of multiple computing nodes, services, or components interconnected through a network, and

[0092] It can be implemented in the form of cloud, on-premises, edge computing, or a combination thereof.

[0093] In addition, the digital system includes components including executable code, configuration information, data processing logic, judgment algorithms, or control flow, and

[0094] These components include an execution environment that has the potential to be changed, replaced, or removed during operation.

[0095] The aforementioned digital system is not only a software-based system, but also,

[0096] It may include a hardware control system, an embedded system, an artificial intelligence-based decision system, or a system that controls a physical device, and

[0097] It is not limited to specific industries or fields of application.

[0098] 1.1.1.2 Function Block

[0099] A Function Block refers to a logical configuration unit corresponding to a function, processing logic, or configuration performed in a digital system, and signifies a verification unit subject to identification value generation and integrity verification.

[0100] The above-mentioned function block is defined based on factors affecting the operation results or state of the system and may include one or more components related to execution code, configuration information, data processing logic, or execution events.

[0101] The above-mentioned function blocks are defined according to deterministic rules so that the same partitioning results are derived under the same input conditions and system configurations, and consistent partitioning criteria are maintained within the same system.

[0102] The above-mentioned function blocks can be organized into a hierarchical structure and defined as a multi-level structure having inclusion relationships between upper and lower function blocks. Through such a structure, function blocks can be defined at various levels, ranging from the overall system unit to detailed execution units.

[0103] The above-mentioned function block refers to a logical verification unit, and a physical or distribution unit, such as an executable file, library, or configuration file, can be interpreted as the function block itself or as a higher-level component containing the function block.

[0104] By performing identification value generation and comparison at the above function block level, it is possible to verify integrity during execution as well as identify and track the location of anomalies at the function block level.

[0105] In the present invention, the functional block is not a simple file splitting unit, but functions as a core verification unit that determines the precision of integrity verification during execution.

[0106] Simple file-level or whole-service-level verification may be valid for confirming whether entire files or images are identical, but it has limitations in identifying local deviations occurring in specific functions, specific condition branches, specific policy interpretation routines, or specific execution paths.

[0107] Accordingly, the present invention provides a precise runtime integrity verification structure that is distinguished from simple file identity verification by generating and comparing identification values ​​based on a function block or a corresponding logical execution unit.

[0108] 1.1.1.3 Running or operating (run-time state)

[0109] The term "run-time state" refers to the state in which a digital system or functional block is operating in an actual operating environment after being deployed or activated, and includes the time interval during which code is loaded into memory and executed, or functions are performed with configuration or setting information applied.

[0110] The above run-time state refers to an operational period after the initial boot of the digital system under verification during which a functional block is actually executed according to a user request or internal logic, and may include the system's initialization, loading, execution, waiting, or event processing phases. The above run-time state includes not only a simple static file existence state but also a state in which memory loading, function calls, data processing, or policy application is in progress.

[0111] The above run-time state may be formed under execution conditions that change according to external input, internal events, or system operations, and information regarding the execution conditions may be recorded or interpreted as part of the execution context.

[0112] The above run-time state is a standard concept that defines the point in time to which integrity verification is applied, and is defined as a concept that includes a time interval in which the integrity of code, configuration, or execution environment is evaluated while the system is actually operating.

[0113] 1.1.1.4 Real-time

[0114] Real-time refers to a state in which the generation, transmission, comparison, determination, and response of identification values ​​are performed within a limited time range during or immediately after the execution of a function block, based on predefined policy-based time limits or event triggers.

[0115] The above real-time processing can be performed by periodic execution, event-based execution, or policy-based triggers.

[0116] The above real-time does not necessarily require a fixed absolute time limit and may include processing performed within an allowed response delay range defined by the system's risk level, functional importance, or policy conditions.

[0117] 1.1.1.5 Execution Context

[0118] An execution context refers to environmental, logical, or procedural conditions at the time when a runtime identifier or related metadata is generated.

[0119] The above execution context may include one or more of a session identifier, a request identifier, the type or state of input data, the time of execution, user or caller information, the policy application status, execution environment information, and external dependency components.

[0120] The above execution context can be used as reference information to ensure consistency in the comparison and interpretation of execution identification values ​​for the same function block.

[0121] 1.1.1.6 Integrity State

[0122] Integrity State refers to the state of a verification target determined by the result of comparing the execution identifier, the reference identifier, and related metadata.

[0123] The above integrity status may be expressed as a normal state, a warning state, an out-of-bounds state, or one or more equivalent state classifications, and may be determined according to predefined policy criteria or consistency judgment criteria.

[0124] The above integrity status can be used as input for subsequent policy-based judgments, control executions, or the generation of digital integrity reports.

[0125] 1.1.2. Identification and Reference Structures

[0126] 1.1.2.1 Identifier

[0127] An identifier refers to a value generated in correspondence with a specific object within a digital system, used as a comparison standard to determine the integrity, identity, or state consistency of that object.

[0128] The above target may include a function block, run-time state, configuration information, execution context, metadata, or a structure combining two or more of these.

[0129] Identifier values ​​are generated according to predefined production rules, input structures, and processing conditions, and are configured to have deterministic characteristics so that the same result is reproduced under the same input conditions and the same production environment.

[0130] The identification value is the result of converting input data into a comparable form and is used as a verification means to detect whether an object has changed or to determine consistency with a reference state.

[0131] The identification value is not limited to a specific implementation method and is defined as a higher-level concept that includes cryptographic hash values, Message Authentication Codes, digital signature-based summary values, or values ​​generated by other integrity verification functions.

[0132] In addition, the identifier can be generated by reflecting not only static data but also the run-time state, and is configured to verify integrity while the system is actually operating.

[0133] Identifiers are classified into reference identifiers and runtime identifiers according to their generation time and purpose, and the reference identifiers and runtime identifiers are generated according to matching generation rules and processing conditions to enable mutual comparison.

[0134] Meanwhile, in the basic embodiment and central technical configuration of the present invention, the identification value is configured to be generated based on a cryptographic hash value. That is, a structure in which a hash-based identification value is generated for input data, execution state information, or corresponding normalized data at the functional block level, and which is utilized as a comparison standard between a reference state and an execution state, constitutes the core embodiment of the present invention.

[0135] Message Authentication Codes, digital signature-based summary values, hardware measurements, or other equivalent forms of identification values ​​should be understood not as replacing the hash-based embodiments, but as variant or auxiliary embodiments that may be optionally applied depending on specific security requirements, execution environments, or extended application structures.

[0136] 1.1.2.1.1 Reference identifier

[0137] A reference identifier refers to an identifier generated for an object verified or certified by a third-party certification authority or an equivalent verification entity, and signifies a reference value representing the reference state of the object.

[0138] The above-mentioned reference identifier may be generated corresponding to a function block, component, or specific part of the system, and reflects authenticated code, build results, configuration information, or execution conditions.

[0139] Standard identifiers can be registered and managed along with environment information, version information, policy information, or verification-related metadata at the time of creation, and can be maintained in an environment separated from the system being verified.

[0140] 1.1.2.1.2 Runtime identifier

[0141] A runtime identifier refers to an identifier generated to identify the execution status of the system under verification.

[0142] Execution identifiers can be generated as static identifiers, dynamic identifiers, or a combination thereof.

[0143] The execution identifier is generated while the system is actually running and can reflect the code state, memory state, configuration values, execution events, and execution context at the time of execution.

[0144] Execution identifiers can be generated at a single or multiple points in time and can reflect changes in state over time.

[0145] The execution identifier is generated according to production rules aligned to be comparable to the reference identifier, and is used as a comparison value to determine whether the execution state matches the reference state.

[0146] Execution identifiers can be generated by reflecting the memory state; in this case, the target of memory verification is not limited to a comprehensive collection of the entire memory space but can be defined as a range meaningful for verification purposes. The said range may include one or more of the following: an executable region where executable code is loaded, a loaded module region where dynamically loaded libraries or modules are located, a critical region directly related to policy-critical function blocks, or a designated monitored region. Therefore, execution identifiers do not necessarily require a full memory dump and can be generated targeting a memory range defined according to policy or a region meaningful for verification.

[0147] 1.1.2.1.3 Static Identifier

[0148] A static identifier refers to an identifier generated for a static component that is determined prior to the execution of a digital system.

[0149] The above static identification value has a deterministic characteristic that generates the same result under the same input conditions and forms a structure that can be directly compared with a reference identification value.

[0150] 1.1.2.1.4 Dynamic Identifier

[0151] A dynamic identifier refers to an identifier generated by reflecting the state during the execution of a digital system.

[0152] The above dynamic identification value is based on static components, but includes an identification value in which information corresponding to the execution state is additionally reflected.

[0153] Dynamic identifiers can be used as an extended integrity verification unit to identify state changes or deviations occurring in the execution environment, and can be generated in combination with static identifiers.

[0154] 1.1.2.2 Cryptographic Hash

[0155] A cryptographic hash refers to a mathematical function or a group of such functions that converts input data of arbitrary length into a fixed-length output value, and is used as a means of data transformation to detect whether input data has been altered or to determine its identity.

[0156] The aforementioned cryptographic hash possesses determinism, meaning that the same output is generated for the same input, and has the characteristic that the output value changes substantially even with minute changes in the input data.

[0157] Additionally, a cryptographic hash may include a group of functions comprising at least one security property among collision resistance, pre-image resistance, and second pre-image resistance, and is not limited to a specific algorithm.

[0158] In the present invention, the cryptographic hash is not merely one of several implementation methods for the identification value, but is used as a central implementation means for generating a reference identification value and an execution identification value in the basic embodiment. Therefore, unless otherwise stated throughout this specification, it is preferable to understand the generation of the reference identification value and the execution identification value primarily in terms of the hash-based structure.

[0159] However, MAC, digital signature-based summary values, or hardware-based measurements may be optionally used in parallel with the hash-based structure or used as alternatives in specific application environments, and such variations may be adopted within the scope that does not deviate from the basic technical concept of the present invention.

[0160] 1.1.2.3 Normalization Profile

[0161] A Normalization Profile refers to information used to identify the normalization procedure applied to input data prior to the generation of an identifier, and signifies an identification unit that defines the version, rule set, or scope of the said normalization procedure.

[0162] The above normalization profile may include alignment of the input data structure, unification of representation formats, definition of fields to be excluded, or transformation rules, and is configured so that data having the same meaning is transformed into a consistent representation.

[0163] The normalization profile is used as reference information to enable the identification of normalization conditions applied during the identifier generation process, and contributes to ensuring that the same normalization conditions are applied so that the reference identifier and the runtime identifier can be compared with each other.

[0164] The normalization profile can be recorded in association with the identifier or managed as separate metadata, and can subsequently be used as a criterion for determining consistency during the verification process.

[0165] 1.1.2.4 Domain Identification Information (Domain Tag)

[0166] Domain Tag refers to identification information defined to distinguish the type, execution context, verification purpose, or scope of application of the target for which an identifier is generated.

[0167] The above domain identification information enables distinction between identification values ​​generated in different contexts or purposes, and can be used as a distinction criterion to treat identification values ​​generated from the same input data as separate identification values ​​if the applicable domain is different.

[0168] Domain identification information can be defined according to the function block type, execution environment, verification purpose, policy conditions, or the role of system components, and can be combined with input data or recorded as separate metadata when generating the identification value.

[0169] In addition, domain identification information can be used as a consistency control criterion to ensure that comparison is performed only when the same domain condition is applied during identification value comparison.

[0170] 1.1.2.5 Third-Party Certification Authority

[0171] A Third-Party Certification Authority refers to an independent entity that performs testing, evaluation, verification, or certification procedures for components or functional blocks of a digital system subject to verification, and generates, approves, or registers reference identifiers based on the results.

[0172] The aforementioned third-party certification body is configured to maintain organizational, functional, and procedural independence from the developer and operator of the system under verification, and such independence is defined as an essential condition to ensure the reliability of the verification results.

[0173] The above-mentioned third-party certification authority is configured to ensure the objectivity, reproducibility, and traceability of the verification procedure and includes a structure capable of proving the legitimacy of the results generated during the verification process through electronic signatures, certification records, or equivalent methods.

[0174] In addition, the aforementioned third-party certification authority may be configured to generate and manage reference identification values ​​in a certification domain or an independent operating environment separated from the system under verification, and the generated results may be provided through a public key-based verification structure or a verification mechanism equivalent thereto so that they can be verified by an external entity.

[0175] A third-party certification body is not limited to a specific organizational form or certification system, and is defined as a concept that includes all institutions or organizations that satisfy the independence and verification functions mentioned above.

[0176] 1.1.2.6 Reference identifier generation based on third-party certification

[0177] "Generation of reference identifiers based on third-party certification" refers to the act of a third-party certification body or an equivalent independent verification entity performing a conformity assessment on the components of a digital system under verification, generating a reference identifier corresponding to the object confirmed to be in a reference state through said assessment, and registering it.

[0178] The above conformity assessment may be performed through activities including testing, inspection, verification, or certification, and may be performed in accordance with international standards, industry standards, or regulatory requirements, but is not limited thereto.

[0179] The above reference state may be defined based on a functional operation unit or execution unit, and may be defined corresponding to one or more components including code, executable files, libraries, configuration information, policy tables, or model parameters.

[0180] The above-mentioned reference identification value is a value generated to represent the above-mentioned reference state, is generated according to predefined generation rules, and is managed as a reference value approved by a third-party certification authority.

[0181] The above-mentioned standard identification value is distinguished from values ​​arbitrarily generated by the operating entity of the system under verification, and is defined as a reference value generated based on a standard state evaluated and confirmed by an independent verification entity.

[0182] 1.1.2.7 Deterministic Build Environment

[0183] A deterministic build environment refers to an environment configured such that when the same input conditions are applied to the same functional block, identical or substantially identical build outputs and corresponding reference identifiers can be reproduced.

[0184] The above input conditions may include source code, configuration information, build tools, dependency configurations, execution environments, and build parameters, and are defined as conditions for determining identity.

[0185] The above-mentioned deterministic build environment is a structure designed to ensure the reproducibility and verifiability of reference identifiers, and is managed so that the input data, processing conditions, and environment configurations used to generate identifiers are identifiable and consistently applied.

[0186] Identity in the above environment is defined to be verifiable according to predefined normalization rules, inclusion and exclusion items, and identification value generation rules.

[0187] 1.1.2.8 Certified Reference Identifier Registry (CRIR)

[0188] The Certified Reference Identifier Registry (hereinafter "CRIR") refers to a system that stores, manages, and provides reference identifiers and corresponding metadata generated or approved by a third-party certification authority or an equivalent independent verification entity, and signifies a component that provides a reference baseline during the integrity verification process.

[0189] The above CRIR is configured to register and manage reference identification values ​​corresponding to a function block or reference state, and the reference identification values ​​may be stored in a combined form with the digital signature, authentication token, or equivalent trust granting information of the authentication subject.

[0190] The above CRIR is configured to manage metadata related to the generation and application of a reference identification value, along with the reference identification value, and the metadata is used as reference information to determine the consistency, traceability, and reproducibility of the identification value.

[0191] The reference identifier stored in the above CRIR serves as a reference standard for comparison with the runtime identifier generated from the execution state, and is used as a reference value to be queried and applied during the integrity verification process.

[0192] CRIR is defined as a concept that is not limited to a specific implementation form and includes all forms of registration and management systems capable of maintaining the reliability, integrity, and verifiability of reference identifiers.

[0193] 1.1.2.9 Trust Boundary

[0194] A trust boundary refers to a logical, functional, or organizational separation criterion defined to limit direct mutual control, modification, or influence between multiple components or domains involved in authentication, execution, verification, control, or public verification.

[0195] The above trust boundary is defined as a structure that includes control constraints preventing specific components or entities from performing direct changes, interventions, or control over the state, data, or verification results of another domain.

[0196] The above trust boundary may include separation between a certification domain, a runtime domain, and a verification domain, and each domain may be configured to have independent authority, data flow, and control paths.

[0197] The aforementioned trust boundary is used as a structural standard to prevent the possibility of control or manipulation of the entire verification structure by a single entity, and is defined as a fundamental prerequisite for ensuring the reliability, independence, and fairness of the verification results.

[0198] 1.1.2.10 Verification Domain

[0199] A Verification Domain refers to an independent functional environment where verification logic is executed to compare runtime identifiers with reference identifiers, determine metadata consistency, and assess integrity status.

[0200] The above verification domain is configured to be separated from the operational domain by a trust boundary and is configured to perform verification processing independently on data collected from the system under verification.

[0201] The above verification domain may be configured to maintain a functionally, organizationally, authoritatively, or network-separated state and includes independence conditions that allow verification results to be generated without the influence of a specific operating entity.

[0202] In addition, the above verification domain is used as an environment to ensure the reproducibility of verification results and the consistency of verification procedures, and may be linked with a third-party certification authority or an equivalent external verification entity as needed.

[0203] The above verification domain functions as the entity generating integrity verification results, and these results can be used as reference information for subsequent policy-based response or external verification processes.

[0204] 1.1.3. Subjects of Verification and Judgment Criteria

[0205] 1.1.3.1 Scope of Verification

[0206] Scope of Verification is a concept that defines the scope and boundaries of the subject to which integrity verification is applied; it refers to verification criteria that specify which components, functional blocks, execution states, or related information within a digital system are included in the verification target.

[0207] The above verification scope is not limited to a single target and can be defined at various layer levels, such as function blocks, services, sessions, processes, or the entire system.

[0208] The verification scope can be configured in a combined form including multiple target elements and can function as a policy parameter that defines the selection criteria, scope of inclusion, and application conditions of the verification target.

[0209] In addition, the verification scope may be statically defined or dynamically adjusted according to the system's security requirement level, functional importance, policy conditions, or operational status, and may be configured to be set to a limited scope under specific conditions and then expanded to include relevant components or, conversely, reduced as necessary when a state change or divergence occurs.

[0210] The above verification scope can be defined in conjunction with the hierarchical structure of functional blocks, and verification of higher-level functional units and lower-level detailed execution units can be performed simultaneously or selectively.

[0211] Accordingly, the scope of verification in this specification refers not to a mere listing of verification targets, but to a structural verification target definition system that includes selection criteria, application conditions, the possibility of adjusting the scope, and a hierarchical structure.

[0212] 1.1.3.2 Integrity Evaluation Criteria

[0213] Integrity Evaluation Criteria refers to a set of rules, conditions, and evaluation logic applied to determine whether an identifier, metadata, or execution environment information generated from an execution state is consistent with a reference identifier, reference state, or predefined policy conditions.

[0214] The above consistency judgment criteria are not limited to whether simple values ​​match, and include criteria for determining whether the result generated under the same generation rules, input structure, and processing conditions maintains structural consistency with the reference state.

[0215] Consistency judgment criteria may include not only whether there is a perfect match, but also judgment criteria based on predefined allowable ranges, policy-approved variations, version compatibility conditions, execution environment conditions, or a combination of multiple factors.

[0216] The above consistency judgment criteria may consist of a single rule or a combination of multiple rules, and may be commonly applied to identification value comparison, metadata verification, execution environment evaluation, or policy-based judgment.

[0217] Accordingly, the consistency determination criteria in this specification are defined not as a simple identity comparison rule, but as an evaluation system for determining whether the state during execution is functionally and structurally consistent with the reference state.

[0218] 1.1.3.3 Policy

[0219] A policy refers to a control structure that defines the judgment and response methods to be performed based on the comparison results between the execution state and the reference state, as a set of rules, conditions, and judgment criteria applied during the integrity verification process.

[0220] The above policy may include criteria for consistency judgment, allowable range, risk level classification, event occurrence conditions, and response methods, and may be composed of a single rule or a combination of multiple rules.

[0221] Policies are used as criteria to link verification results to actual controls or responses, and function as decision factors that influence the interpretation and application of verification results.

[0222] In addition, policies may be defined, modified, or extended depending on the system's security requirements, operating conditions, or regulatory requirements.

[0223] When multiple policies are simultaneously applicable to the same verification result or the same policy event, a policy conflict resolution rule may be applied. The policy conflict resolution rule may include one or more of the following: a severity-priority rule that prioritizes the policy with a higher risk level; a deny-overrides rule that prioritizes policies requiring prohibition or blocking over allow or warning policies; a more-specific-rule priority rule that prioritizes policies corresponding to more specific function blocks or conditions over general policies; and a fail-safe basic principle that prioritizes conservative responses when the final judgment is unclear.

[0224] Accordingly, the policy in this specification is defined not as mere configuration information, but as a rule-based control system that enables the interpretation of integrity verification results, resolution of policy conflicts, and response execution.

[0225] 1.1.3.4 Execution Authenticity

[0226] Execution Authenticity Verification refers to a verification concept used to determine whether a specific execution result was generated according to a predefined execution procedure.

[0227] The above verification is a concept distinct from integrity verification at the functional block level, and includes criteria for determining not only the integrity of the executable code but also the execution flow through which the code generated a result.

[0228] Verification of the execution result source can be performed based on execution identification information, execution flow information, and linkage information between the result and the execution process, and is used to evaluate consistency with approved execution procedures.

[0229] The source verification of the execution result mentioned above is an extended verification concept that can be applied separately from basic integrity verification, and can be applied selectively depending on specific systems or requirements.

[0230] 1.1.3.5 Public Verification Interface

[0231] A Public Verification Interface refers to an interface provided to allow external users, auditing bodies, regulatory bodies, or other stakeholders to view and verify verification results or related verification data.

[0232] The above-mentioned public verification interface is a component for ensuring transparency, accessibility, and external verifiability of verification results, and may include a function that allows an external entity to independently verify the integrity, signature validity, timestamp information, or related reference information of the verification results.

[0233] The above-mentioned public verification interface is not limited to a specific implementation method and is defined as a concept that includes all forms of interfaces capable of providing the above function.

[0234] Therefore, the public verification interface in this specification is not merely a means of providing information, but refers to a verification linkage structure that enables the integrity verification results to be independently verified externally.

[0235] 1.1.3.6 Cross-Channel Verification

[0236] Cross-Channel Verification refers to a procedure for verifying the consistency and alignment of results between multiple independent external channels when the same verification result or digital integrity report is provided through said channels.

[0237] The above plurality of channels may include a web-based interface, a public API, a blockchain explorer, a physical output device, or equivalent means, thereby reducing the possibility of single-channel errors or manipulation.

[0238] 1.1.4. Data Collection and Identifier Generation

[0239] 1.1.4.1 Collector

[0240] A collector refers to a component that performs the function of acquiring status information or data necessary for integrity verification during the operation of a digital system and transmitting it to an external verification entity or verification system.

[0241] The above collector is configured primarily around data acquisition and transmission functions, and is functionally distinct from components that perform integrity judgment or verification result generation functions.

[0242] The above collector can be placed inside or outside the target system and can acquire status information through a predefined interface.

[0243] In addition, the collected data can be used as input for generating execution identifiers or verifying integrity.

[0244] 1.1.4.1.1 Agentless

[0245] Agentless refers to a data collection method in which external components acquire operational status information through predefined interfaces, without installing resident monitoring software within the target system.

[0246] The above agentless method is structured not to insert continuous monitoring logic into the target system, and is configured to be applicable in environments with minimized impact on system performance or installation constraints.

[0247] 1.1.4.2 Runtime Integrity Monitoring Agent (RIMA)

[0248] A Runtime Integrity Monitoring Agent (RIMA) refers to a component that collects data from the run-time state of a digital system, generates an identifier based on the data, and transmits it to an external verification entity or an independent verification structure.

[0249] The above RIMA is a component that performs a combination of data collection and identification value generation functions, and is distinguished from a simple collector. In addition, the above RIMA can collect data targeting execution code, configuration information, memory state, execution environment, or execution event information at the functional block level, and the data can subsequently be used as input linked to an external verification structure.

[0250] The above RIMA can be deployed inside the system to be verified or in an environment adjacent thereto, and can function as a preprocessing and forwarding layer that generates a runtime identifier for the operating state.

[0251] Accordingly, RIMA in this specification refers to a runtime integrity collection and identification value generation component that generates verifiable identification data from an operating state and links it with an external verification structure.

[0252] 1.1.4.3 Self-Integrity Check (or Self-Check)

[0253] Self-Integrity Check refers to a function in which a system component or monitoring component checks its own code, configuration, execution environment, or communication status to verify whether the component is operating normally or is trusted.

[0254] The aforementioned self-integrity check is an internal verification function designed to confirm whether the integrity of the components is maintained, and it plays a role in supporting the reliability of the integrity verification process.

[0255] 1.1.5. Verification and Judgment Structure

[0256] 1.1.5.1 Independent Verification Server (IVS)

[0257] An Independent Verification Server (IVS) refers to a verification system deployed in a verification domain isolated from the execution environment of the system under verification, which receives execution identifiers and related metadata and performs the function of determining the integrity status by comparing them with reference identifiers and reference information.

[0258] The above IVS is configured to operate in a state of organizational, authority, and network separation from the development and operation entities of the system under verification, and includes a structure that enables verification results to be generated independently without external influence.

[0259] The above IVS determines whether there is divergence relative to the reference state based on the comparison result between the execution identification value and the reference identification value, and provides the determination result as reference information for subsequent control or response.

[0260] In addition, the above IVS can generate and store verification results in the form of recorded data or digital reports, and the results can be utilized for external verification or audit purposes.

[0261] 1.1.5.2 Integrity Verification Engine (IVE)

[0262] An Integrity Verification Engine (IVE) refers to a component that performs comparison and verification functions to determine whether the integrity of a target system or functional block is maintained by comparing an execution identifier and a reference identifier.

[0263] The above IVE performs a comparison between identification values ​​generated according to the same generation rules and processing conditions, and determines consistency with the reference state based on the comparison result.

[0264] IVE is not limited to a specific implementation method and is defined as a concept that includes all forms of verification logic capable of performing identification value comparison.

[0265] 1.1.5.3 Metadata Integrity Verification Engine (MIVE)

[0266] A Metadata Integrity Verification Engine (MIVE) refers to a metadata-centric verification component that determines whether metadata, execution environment information, or policy-related state information collected at runtime is consistent with a reference state or policy conditions.

[0267] The above MIVE evaluates whether the values, structures, conditions, or execution environment information of the metadata match predefined criteria or exist within an acceptable range, and determines the integrity status based on the result.

[0268] MIVE can operate independently or in combination with identifier-based verification, and can determine an integrity violation state if the metadata does not meet the criteria conditions even if the identifiers match.

[0269] 1.1.5.4 Divergence

[0270] Divergence refers to a state in which an identifier, metadata, or execution environment information generated from an execution state is determined not to be consistent with a reference identifier, reference state, or policy standard.

[0271] The above deviation may occur due to a discrepancy in identification values, failure to meet metadata conditions, changes in the execution environment, or violations of policy criteria.

[0272] Deviation is a result state determined during the integrity verification process and can be used as a trigger for subsequent policy-based responses, alert generation, report recording, or additional verification.

[0273] Deviation may be interpreted as a signal indicating potential tampering, error, or unauthorized change, but is not limited to specific causes.

[0274] 1.1.6. Policies and Controls

[0275] 1.1.6.1 Policy Event

[0276] A policy event refers to an event, condition, or judgment result that initiates the application of a predefined policy rule based on the result of an integrity verification or a change in the system state.

[0277] The above policy event may occur based on judgment results or state changes generated during the integrity verification process, and functions as a trigger that initiates a subsequent policy-based response.

[0278] Policy events may be triggered by a single condition, or by a combination of multiple conditions or judgment criteria.

[0279] Accordingly, policy events in this specification are defined not as simple status notifications, but as initiation conditions for linking integrity verification results to policy-based control procedures.

[0280] 1.1.6.2 Policy-Based Response Module (PB-RM)

[0281] A Policy-Based Response Module (PB-RM) refers to a component that determines a response method by applying predefined policy rules based on integrity verification results or policy events, and generates control commands or response instructions accordingly.

[0282] The above PB-RM acts as a decision-making entity performing policy interpretation and response decision functions, and plays the role of connecting verification results to actual control or subsequent response procedures.

[0283] PB-RM can operate based on a single rule or a combination of multiple rules and can generate different response decisions depending on system status, risk level, functional importance, or operating conditions.

[0284] The above PB-RM refers to a component that produces a final response decision according to a predefined conflict resolution rule when multiple policy rules are simultaneously satisfied. The conflict resolution rule may include one or more of the following: risk level, policy priority, the presence of prohibition or blocking characteristics, the specificity of function blocks or conditions, and fail-safe criteria for system protection.

[0285] Accordingly, the PB-RM in this specification is defined not as a simple configuration application module, but as a rule-based control component that calculates a response decision based on policy rules.

[0286] 1.1.6.3 Real-time Control Agent (RCA)

[0287] A Real-Time Control Agent (RCA) refers to an execution entity that receives control commands generated by a policy-based response module and reflects them in actual operations through the control interface of a target system.

[0288] The above RCA is a component that converts response decisions into actual execution actions, and functions as an execution entity distinct from the policy-based decision entity.

[0289] RCA can be deployed inside the target system or in an adjacent execution environment, and can transmit the results of applying control commands to external components in the form of status information or events.

[0290] Accordingly, the RCA in this specification is defined not as a simple command transmission means, but as a component of the execution layer that reflects policy-based response in actual system operation.

[0291] 1.1.7. Verification Results and Evidence Structure

[0292] 1.1.7.1 Digital Integrity Report

[0293] A Digital Integrity Report refers to a set of evidentiary data that presents the results and related information generated during the integrity verification process in a structured form, and is configured to enable the generation, transmission, storage, and tracking of the verification history of the results.

[0294] The above digital integrity report may include identification information of the verification target, an identifier, a verification result, verification time information, verification subject information, or related metadata equivalent thereto, and may be configured in an interconnected structure to enable the reproduction of the status and processing history of the verification process.

[0295] In addition, the digital integrity report may include a digital signature, a timestamp, or equivalent trust granting information, and may include a linkage structure with a previous report or related verification data.

[0296] Accordingly, the digital integrity report in this specification refers to an evidentiary data structure that goes beyond a simple record of results and provides traceability, tamper-proofness, and external verifiability for integrity verification.

[0297] 1.1.7.2 Chain of Custody

[0298] Chain of Custody refers to a structure in which the history of each stage is continuously linked throughout the entire process of data, identifiers, verification results, digital integrity reports, or equivalent related information generated during the integrity verification process—including their creation, storage, transmission, retrieval, and access—and is managed to enable verification of the integrity, order, and alteration status of such history.

[0299] The above chain of custody is configured so that historical information generated at each processing step is interconnected, and is used as a standard structure to ensure traceability and evidentiary continuity of the entire processing flow.

[0300] The above history information may include the time of creation, the creator, the processing content, the transmission path, the storage location, or the access record, and each history may be configured to be verifiable independently or in a linked form.

[0301] Data or reports managed under a chain of custody can be configured to be independently verifiable by a third party or user, thereby ensuring the reliability and traceability of integrity verification results.

[0302] Therefore, the chain of custody in this specification refers not to a simple set of logs, but to an evidence management structure that reliably connects the entire process from the generation of verification results and related information to preservation and external verification.

[0303] 1.1.7.3 Timestamp Agency (TSA)

[0304] A Time Stamping Authority (TSA) refers to a third-party organization or system that generates reliable time information for electronic data or its corresponding identifier and issues time tokens to enable verification that the data existed at a specific point in time.

[0305] The above TSA generates time information based on a trusted time source and can generate and provide a Time-Stamp Token (TST) for the input data or its identification value.

[0306] The above time point token can be used as trust-granting information to fix the creation or existence time of the data and to enable external verification of its integrity and temporal legitimacy.

[0307] In addition, the above-mentioned time point token can be combined with integrity verification results, digital integrity reports, or equivalent data to enhance the temporal continuity and evidentiary value of the said data.

[0308] Accordingly, the TSA in this specification does not refer merely to an organization that displays time, but to an independent point-in-time certification entity that grants temporal reliability to verification results or evidence data.

[0309] 1.1.8. Access Control and Storage Structure

[0310] 1.1.8.1 RBAC (Role-Based Access Control)

[0311] RBAC (Role-Based Access Control) refers to an access control model that defines access rights to system resources based on the roles assigned to users and controls access according to the mapping relationship between the roles and rights.

[0312] The above RBAC is configured to determine the scope of access and actions that can be performed based on the relationships between users, roles, and permissions, and includes a role-based permission management structure rather than direct authorization to specific users.

[0313] The above RBAC can be used as a standard to control access to verification results, digital integrity reports, policy information, log data, or equivalent system resources.

[0314] In addition, access control based on RBAC can generate historical information related to access attempts, approvals, and denials, and said history can be used for auditing or tracking purposes.

[0315] RBAC is not limited to a specific implementation method and can be applied in conjunction with various authentication and authorization management systems.

[0316] 1.1.8.2 WORM storage (Write Once Read Many)

[0317] WORM (Write Once Read Many) storage refers to an immutability-based storage structure configured so that changes or deletions are restricted or prohibited after data is written, while allowing for repeated retrieval.

[0318] The above WORM repository is configured to maintain the integrity and preservation of stored data by including a control mechanism that restricts the modification, deletion, or rewriting of data.

[0319] The above WORM repository may include a structure that enables verification that the stored data has not been altered afterward, and may be used as a storage layer to ensure the reliability of integrity verification results or related evidence data.

[0320] Accordingly, a WORM repository in this specification is defined not as a simple storage medium, but as an immutable storage structure to ensure the immutability and verifiability of data.

[0321] 1.2 Hash-based Identifier Generation and Operation Policy

[0322] In the present invention, the identifier can be conceptually implemented in various ways; however, the basic embodiment of the present invention focuses on a structure generated according to a cryptographic hash function or a hash-based integrity verification function equivalent thereto. The hash-based identifier generation method is applied as a basic means for detecting whether input data has been altered and for determining identity or consistency, and includes a deterministic characteristic of generating the same output for the same input.

[0323] Message authentication codes, digital signature-based summary values, or hardware measurements may be used as optional supplementary means or modified embodiments; however, the comparison structure between the reference state and the execution state of the present invention is preferably implemented primarily based on a hash-based identification value generation and comparison system. The hash function is not limited to a specific algorithm and may be configured to satisfy one or more security characteristics such as original resistance, second original resistance, and collision resistance. These characteristics serve as criteria for ensuring the reliability of the identification value during the integrity verification process.

[0324] The hash algorithm used to generate identification values ​​may be selected, replaced, or applied in parallel depending on security requirements, regulatory environments, or technological advancements. In one embodiment, a multi-hash structure that generates multiple identification values ​​by simultaneously applying multiple hash algorithms may be applied, thereby maintaining verification reliability even if a vulnerability occurs in a specific algorithm. Additionally, if an algorithm transition is required, a gradual transition may be performed by applying the existing algorithm and the new algorithm in parallel, and the identification values ​​generated during this process may be managed to enable mutual comparison.

[0325] When generating identifiers, the input data may include domain identification information (domain tags), execution context information, or validation purpose information, which can reduce the possibility of conflicts or misuse between identifiers generated in different contexts. Additionally, the input data can be processed according to a predefined normalization profile, thereby ensuring that data with the same meaning is reflected in the identifiers in a consistent manner.

[0326] For large volumes of data or continuous data streams, a method of splitting input data to generate partial identification values ​​and combining them into a hierarchical structure may be applied. In one embodiment, the structure may include a tree-based combination structure, thereby enabling efficient integrity verification regardless of data size.

[0327] Furthermore, the process of generating identifiers can be configured to reduce the possibility of collisions or attacks by combining the configuration method of input data, context information, or additional information. This structure aims to strengthen the semantic distinction of input data and reduce the possibility of false positives or malicious collisions for the same input.

[0328] Information related to the generation of identification values ​​may be recorded in the form of metadata, and said metadata may be used as reference information to ensure the reproducibility of the identification value generation process. In one embodiment, said metadata may include an algorithm identifier, a normalization profile identifier, domain identification information, or policy version information.

[0329] 1.3 Adaptive Integrity Verification Policy

[0330] This system may include an adaptive verification structure that, rather than uniformly applying the same verification method to all verification targets, can selectively adjust the verification method, verification intensity, or verification scope according to the characteristics, importance, and policy conditions of the verification targets. The above-mentioned adaptive verification refers to a structure that dynamically adjusts the verification targets, verification methods, verification intensity, or verification scope according to policies or system states.

[0331] The above-described adaptive verification structure may be configured to apply different verification criteria depending on the importance of the functional block, the level of security requirements of the system, the characteristics of the operating environment, regulatory requirements, or policy conditions. For example, stricter verification conditions may be applied to high-importance areas such as random number generators, payment processing logic, authorization control logic, or security configuration information, while relatively relaxed verification conditions may be applied to areas where changes within a limited scope are permitted, such as user interfaces, supplementary log information, or certain configuration settings.

[0332] However, the fundamental integrity judgment of the present invention is configured to be performed primarily through a strict consistency comparison between a reference identifier and a runtime identifier, and adaptive verification should be understood as an auxiliary verification structure applied restrictively within the scope permitted by policy. In other words, adaptive verification is not an independent verification structure that replaces strict verification, but rather functions as an exceptional or extended judgment structure that can be applied only under specific conditions following the result of the fundamental comparison.

[0333] Through such an adaptive verification policy, the system can be configured to maintain strict verification with a high level of confidence for core function blocks, while simultaneously reducing unnecessary false positives in non-core areas or within policy-acceptable limits and ensuring operational efficiency.

[0334] 2. System

[0335] 2.1 Overall System Overview

[0336] The present invention relates to a system and method for verifying the integrity and execution reliability of a digital system's run-time state in real time, performing policy-based automatic response based on the verification results, and recording and providing the results in a form that can be externally verified.

[0337] In particular, the present invention aims to technically guarantee runtime trustworthiness, which could not be secured by existing static authentication methods, by continuously comparing and analyzing the system state running in an actual operating environment based on a reference state verified in advance by a third-party certification authority.

[0338] Existing methods for ensuring trust in digital systems primarily rely on static analysis, functional testing, security certification, and configuration verification procedures performed during the pre-deployment phase. While these approaches can prove that a defined baseline state is satisfied at a specific point in time, they fail to provide a structure capable of continuously verifying whether that state is maintained during actual operation.

[0339] In particular, in cloud-based services, DevOps environments, and continuous deployment structures, code changes, configuration changes, library updates, or runtime patches occur frequently. These changes carry the potential for internal divergence, where the system deviates from the intended state even if it outwardly maintains normal operation. Consequently, an imbalance of trust may arise between operators and users, or between service providers and regulatory bodies, which acts as a significant risk factor in high-trust environments such as finance, healthcare, e-government, and artificial intelligence decision systems.

[0340] To address these limitations, the present invention provides a verification framework for structurally confirming whether the validity of prior certification is maintained until the point of operation by correlating and comparing a reference state determined in advance by a third-party certification authority with an actual execution state during operation according to the same verification criteria. The common core structure of the present invention includes a definition of a reference state based on third-party certification, generation of execution identifiers at the functional block level, comparison and judgment in an independent verification domain, policy-based response linked to deviation judgment, and an externally verifiable digital integrity report structure.

[0341] Specifically, the invention includes a structure that generates a reference state at the level of a function block verified by a third-party certification authority and registers it in a trusted repository; during operation, collects the execution state of the corresponding function block to generate an execution identifier according to the same generation rules, and then determines whether integrity is maintained by comparing the execution identifier with the reference identifier. In this case, the reference identifier and the execution identifier are generated as cryptographic hash-based identifiers in the basic embodiment, and other forms of identifiers may be applied as optional or extended embodiments. Here, a function block does not refer to a simple physical file unit, but may include a function, class, module, configuration object, state transition unit, request processing routine, or a corresponding logical execution unit. By adopting such a structure, the present invention can identify local execution deviations that are difficult to capture through comparisons at the level of the entire file or service image.

[0342] In this case, the verification is not limited to a simple comparison of code identity, but can be performed multidimensionally by including metadata such as the execution environment, configuration status, and policy conditions.

[0343] The system of the present invention may be composed of a plurality of functionally separated domains, and each domain is configured to be logically separated yet interconnected to form a single continuous trust flow.

[0344] The certification domain performs the function of generating and registering a reference state by a third-party certification authority. The runtime domain is the area where the system under verification actually runs, and includes the environment in which the runtime state is generated. The verification domain performs the function of determining integrity by comparing the runtime state with the reference state. The policy and control domain includes the function of determining whether to respond and the method of response based on the verification results, and executing them. The evidence and transparency domain performs the function of recording the verification results and providing them externally.

[0345] Each of the aforementioned domains is not merely functionally connected but possesses an organizationally and logically separated structure to ensure trust independence and verifiability. For example, the verification domain may be configured to operate in an environment separate from the operations domain, thereby minimizing the possibility of external influence or manipulation on verification results. Furthermore, the reference state is generated and signed by a certification authority, and this information is maintained so that it can be referenced during subsequent verification processes.

[0346] Furthermore, the present invention includes a flexible structure to enable application in various operating environments. The execution state collection method may be configured as an event-based, periodic, or request-based collection method, and the verification method may also selectively apply exact match-based verification and similarity-based verification according to policy. However, integrity verification is, in principle, based on confirming that the identification values ​​between the reference state and the execution state are substantially identical, and similarity-based verification may be applied secondarily within the scope permitted by policy.

[0347] Overall, the operation flow of the present invention is configured as follows. A third-party certification authority generates and registers a reference state at the level of a functional block. Subsequently, execution states are collected while the system is operating, and corresponding execution identifiers are generated. The generated execution identifiers are transmitted to an independent verification domain, where they are compared with the reference identifiers to determine whether integrity is maintained. If divergence is detected, the policy and control domain determines a response according to a predefined policy and, if necessary, can perform controls that directly affect system operation. Simultaneously, the verification results and response details are transmitted to the evidence and public domains, recorded in a form including digital signatures and timestamping, and provided so that users or external auditing bodies can view or verify them.

[0348] A system configuration according to one embodiment of the present invention can be more clearly understood with reference to FIG. 1. As illustrated in FIG. 1, the system may have a multi-layered structure divided into an authentication domain, an operation domain, an independent verification domain, a response and reporting domain, and a public interface domain.

[0349] In the authentication domain, a third-party certification authority generates standard identifiers at the functional block level and registers them in the standard registry. In the operation domain, the actual system under verification runs, and identifiers for the running logic are generated in real time. In the independent verification domain, a comparison is performed between the aforementioned execution identifiers and standard identifiers to determine integrity.

[0350] In the response and reporting domain, policy-based responses are performed based on verification results, and integrity reports are generated. The generated reports can be recorded in an immutable repository after being digitally signed and timestamped, and are provided through the public interface domain so that users, auditing bodies, or regulatory bodies can view and verify the results.

[0351] In addition, FIG. 7 is a diagram illustrating the structure of a real-time integrity verification system in various industrial environments according to an embodiment of the present invention, showing a linkage structure between a plurality of verification target systems, a reference value management server, a central verification server, an immutability repository, and an external verification entity. Accordingly, it can be understood that the common core structure of the present invention is not limited to a single system but can be commonly applied to multiple industrial environments or multiple operating environments.

[0352] The structure of the present invention can be understood hierarchically.

[0353] Layer 1 is a core integrity verification structure that includes the generation of a reference state based on third-party authentication, the generation of an execution identifier during operation, and comparison and judgment in an independent verification domain.

[0354] Layer 2 is an automatic response structure that performs policy-based response using the result of the core integrity verification structure above as input.

[0355] Layer 3 is a public verification structure that generates verification and response results as digital integrity reports and provides them for verification by external users, auditing bodies, or regulatory bodies.

[0356] Therefore, the policy-based automated response structure and the public verification structure can be understood as a hierarchical structure that can be optionally combined or extended based on the core integrity verification structure.

[0357] Through this structure, the present invention forms a trust chain capable of verifying the consistency between the authenticated state and the actual execution state in real time, and implements an independent verification structure that does not depend on an operator.

[0358] FIG. 3 is a diagram illustrating an end-to-end trust flow according to an embodiment of the present invention, sequentially showing the entire processing flow leading to authentication, generation and registration of reference identifiers, collection of execution identifiers, integrity comparison, policy application, report generation, combination of electronic signatures and timestamp information, immutable storage, and external verification. Accordingly, the entire verification system of the present invention can be understood not as a collection of individual components, but as an interconnected trust flow structure.

[0359] In addition, FIG. 19 is a diagram illustrating an application structure by industrial sector according to an embodiment of the present invention, showing a corresponding relationship between a representative standard or requirement applicable to multiple industrial sectors and the core verification structure of the present invention. Accordingly, the common core architecture of the present invention can be applied based on functional block unit verification, independent verification domains, policy-based response, and an externally verifiable report structure, even under regulatory environments or trust requirements that differ by industry.

[0360] 2.2 Trust Boundary Separation Architecture

[0361]

[0362] To ensure the reliability of integrity verification during execution, the present invention adopts a Trust Boundary Separation Architecture designed to configure the entire system into multiple functionally separated trust regions and to perform interactions between each region through limited interfaces.

[0363] Specifically, the system according to the present invention

[0364] It is divided into a certification domain, a runtime domain, a verification domain, and a public verification domain, and each of these domains is configured to form independent trust boundaries.

[0365] The certification area is operated by a third-party certification authority or an equivalent verification entity and performs the role of defining reference states at the functional block level and generating and registering reference identifiers that represent them. The said reference identifiers are generated based on a certified execution configuration, and said configuration can be determined in a deterministic build environment or an equivalent reproducible environment.

[0366] The operational area is the execution environment where the actual service is performed, and it is the area where user request processing, data processing, and decision logic execution take place. In the operational area, a runtime identifier is generated from the execution state, and this can reflect the code state, configuration information, memory state, or policy application results at the time of execution.

[0367] The verification domain performs the function of determining integrity based on information transmitted from the authentication domain and the operation domain, and the determination process is configured to be performed in a logically independent environment so as not to be affected by the processing of the operation and authentication domains. This independence can be secured through the separation of execution environments, the separation of authorization systems, or the restriction of control flow, thereby structurally limiting the modification or influence of verification results by specific entities.

[0368] The public verification area is an area that provides an interface enabling users, auditing bodies, or regulatory bodies to access and verify verification results, and performs the function of ensuring the possibility of external verification of the verification results.

[0369] Data flow between the aforementioned areas is performed through restricted interfaces, and reference information generated in the authentication area and execution information generated in the operations area are transmitted to the verification area. Control from the verification area over the operations area is performed restrictively through a policy-based response structure, and the system is configured so that the verification logic is not directly affected by the operations logic.

[0370] Under this structure, since the definition of the reference state, the creation of the execution state, and integrity determination are performed at different trust boundaries, it is structurally restricted for any specific entity to unilaterally control or manipulate the entire verification structure. Accordingly, changes or tampering occurring in the operational environment can be detected within an independent verification domain.

[0371] In addition, the judgment result generated in the verification area can be linked with a policy-based response mechanism and converted into a control command for the operation area, and the control result can also be included in the verification and recording targets.

[0372] Furthermore, verification results and response history are recorded in a form including digital signatures and timestamps, and can be provided for verification by external auditing bodies or users. Through this, the structure of the present invention can be extended beyond internal verification to a publicly verifiable trust architecture that includes the possibility of external verification.

[0373] As illustrated in FIG. 2, the system according to the present invention may have a multi-layered structure divided into an authentication domain, an operation domain, an independent verification domain, and a public verification domain, and each domain operates in an environment that is organizationally, logically, and network-separated.

[0374] In the authentication domain, a third-party certification authority generates and registers a reference identifier. In the operation domain, the system under verification runs, and an identifier is generated from the execution status. In the independent verification domain, integrity is determined by comparing the aforementioned execution identifier with the reference identifier. In the public verification domain, the verification results are provided so that external users or auditing bodies can view and verify them.

[0375] In addition, data transfer between domains can be performed through a cryptographically protected communication structure and can be configured to maintain the independence of each domain through a unidirectional or limited feedback structure.

[0376]

[0377] 2.3 System Components

[0378] 2.3.1 Third-Party Certification Entity

[0379] In one embodiment, a third-party certification entity may be configured to function as a starting point for defining the reference state of a digital system under verification and generating a corresponding reference identifier. The third-party certification entity may not merely act as a formal approval body, but may operate as an entity that independently performs testing, evaluation, and verification procedures to ensure the conformity, reproducibility, and reliability of the reference state.

[0380] The aforementioned third-party certification authority is configured to operate in a state of organizational and functional separation from the developer and operator of the system under verification, and accordingly, the process of defining the reference state and generating the reference identifier is ensured to be performed independently from external influences.

[0381] The aforementioned independence is an essential component forming the trust structure of the present invention, and structurally restricts a specific entity from arbitrarily changing the reference state or influencing the verification results.

[0382] In one embodiment, the independence may be implemented by one or more of physical system separation, network separation, separation of authority, or separation of verification procedures, and even when implemented within the same organization, it may be secured through role-based separation of authority and separation of signature authority.

[0383] The third-party certification body mentioned above may include various types in its form of implementation and is not limited to a specific type of body. In one embodiment, the third-party certification body may be configured in the form of a testing, verification, or certification body accredited according to international standards, for example, an institution accredited according to international standards such as ISO / IEC 17025, ISO / IEC 17029, ISO / IEC 17065, etc. Additionally, it may be configured in the form of a testing, verification, or certification body accredited by a national or public institution, or it may be implemented in the form of a specialized verification body accredited in a specific industrial sector or recognized as a de facto standard. The important point is not the type of body itself, but the structure that allows for defining a standard state independently of the entity developing and operating the system under verification, and externally proving the reliability of the results.

[0384] The above-mentioned third-party certification authority is configured to receive various information related to the subject of verification from the development environment, build environment, deployment environment, or operation environment of the system subject to verification, and said information may include source code, build scripts, compilation environment information, external library and dependency package information, configuration files, policy tables, model parameters, execution environment definition files, or equivalent data.

[0385] Depending on the embodiment, the third-party certification authority may be configured to perform an evaluation that is not limited to simple source code but includes executable files, container images, package products, signed distribution artifacts, or operating environment snapshots that are the actual targets for distribution.

[0386]

[0387] The aforementioned third-party certification authority may determine criteria for dividing the system under verification into functional blocks during the processing process. For example, in a compiled language-based system, functional blocks may be defined based on units of functions, classes, modules, or linker symbols; in a script-based system, the criteria may be based on Abstract Syntax Tree (AST)-based functions, classes, or units that are independently executable on the call graph. Additionally, in a configuration-oriented system, units of normalized configuration objects may be defined as functional blocks; and in an event-based system, units of state transitions or input processing flows may be used as criteria.

[0388] The aforementioned third-party certification body may be configured to perform testing, verification, or certification procedures for each functional block or component, and said procedures may include conformity assessment in accordance with international standards, industry standards, or regulatory standards.

[0389] The above conformity evaluation is not limited to simple functional testing and may include reproducibility verification to determine whether the same result is reproduced under the same input conditions, interface consistency verification between components, impact analysis on setting values ​​and environment dependencies, and verification of the existence of unauthorized change elements.

[0390] In addition, during the above conformity assessment process, structural, functional, and operational conformity verification may be performed to determine whether a specific functional block or system component meets predefined standards or requirements.

[0391] Additionally, if necessary, the aforementioned third-party certification authority may be configured to perform a procedure to capture and preserve specific build environments and execution environments in order to determine a certified execution configuration.

[0392]

[0393] As a result of the above verification procedure, a third-party certification authority may determine a standard data set normalized in units of functional blocks and generate a corresponding standard identification value. The standard identification value may be generated using a cryptographic hash, multiple hash, message authentication code, or an equivalent method, and may be configured in the form of a set of identification values ​​corresponding to multiple functional blocks rather than a single value.

[0394] In addition, the aforementioned standard identification value may be combined with the digital signature, authentication token, or public key-based verification information of a certification authority, thereby enabling an external entity to independently verify the authenticity, generation time, and generation entity of the result. According to this structure, the verification result generated by the third-party certification authority may be provided in a form that can be re-verified by an external system or user.

[0395] The output of the aforementioned third-party certification authority is not limited to the reference identifier itself, but may be generated in the form of a structured certification result record that includes, along with the reference identifier, a function block identifier, version information, a normalization profile identifier, an applied algorithm identifier, generation time information, certification authority identification information, and policy-related information. The certification result record may subsequently be registered in the Certified Reference Identifier Registry (CRIR) and used as a reference standard for comparison with the execution state.

[0396] The reference state and reference identifier generated by such a third-party certification authority are used as reference points of trust during the subsequent verification process, and provide a basis for determining the integrity and execution reliability of the system through comparison with the operational state.

[0397] 2.3.2 Certified Reference Identifier Registry (CRIR)

[0398] In one embodiment, a Certified Reference Identifier Registry (CRIR) may be configured as a trust-based repository that stores and manages reference identifiers generated or approved by a third-party certification authority and corresponding metadata. The CRIR serves as a core component that provides reference standards during the integrity verification process and can perform the role of providing reference data that is compared with execution identifiers generated from the operational state.

[0399] The above CRIR is not limited to a simple data repository and may be configured to include structural functions to ensure the reliability, integrity, and traceability of reference identification values. To this end, the CRIR may manage metadata linking the reference identification values ​​with the basis for their creation and verification history, and this metadata may be used to maintain the consistency of the comparison criteria during subsequent verification processes.

[0400] The reference identification values ​​stored in the above CRIR may be defined based on functional block units or equivalent logical configuration units, and each identification value may be used as a reference value representing the authenticated state of the corresponding functional block. In this case, the reference identification value may not be a single value but may be configured in the form of a set of identification values ​​corresponding to multiple functional blocks, and the reference state of the entire system may be expressed as a combination of such a set of identification values.

[0401] The above CRIR may be configured to store various metadata along with a reference identifier, and said metadata may include a function block identifier, version information, creation time, identification information of the applicable system or service, a normalization profile identifier, a hash algorithm identifier, a policy identifier, and identification information of a certification authority. In addition, said metadata may include the certification authority's digital signature, authentication token, or public key-based verification information, thereby enabling external verification that the reference identifier was generated through a trusted procedure.

[0402] The above CRIR can be configured to support change history and version management of reference identification values, and can manage reference identification values ​​corresponding to each version separately when multiple versions exist for the same functional block. Through this structure, even when system updates, patches, or configuration changes occur, it is possible to distinguish and track past reference states and current reference states, and it can be configured to enable the reproduction or verification of the reference state at a specific point in time.

[0403] In addition, the CRIR may include various technical means to protect the integrity of the reference identification value. For example, digital signature verification of stored data, access control-based protection, immutable storage structures, or equivalent integrity protection mechanisms may be applied. In one embodiment, the CRIR may be implemented in a form including a centralized database, a distributed storage, or an immutable storage structure, and may be linked with a blockchain-based ledger structure, a WORM (Write Once Read Many) storage structure, or an append-only secure DB as needed.

[0404] The above CRIR may provide an interface to allow an external verification entity or verification server to query a reference identification value, and said interface may be configured to allow access only to authenticated requests. In this case, said interface may be implemented as a REST API, a data query interface, or an equivalent method, and signature verification or hash verification procedures may be performed together to verify data integrity at the time of query.

[0405] In addition, the CRIR can be configured to be shared by multiple verification domains or multiple verification entities, thereby enabling multiple independent verifications to be performed based on the same reference state. This structure can reduce dependence on a single verification entity and provide the effect of improving the objectivity and reliability of the verification results.

[0406] Such a reference identifier registry functions as a core infrastructure that enables comparisons between the operational state and the reference state to be performed based on reliable standards by reliably storing reference states generated by third-party certification authorities and providing them to the verification process.

[0407] 2.3.3 Collector

[0408] In one embodiment, a collector may be configured to operate as an input generating component for acquiring data necessary for integrity verification from the run-time state of a digital system under verification and transmitting it to a verification entity or an independent verification server. The collector performs an initial stage function of converting the run-time state into a verifiable form and subsequently has a direct impact on the reliability of the identification value generation and verification process.

[0409] The aforementioned collector can be implemented in an agent-based manner installed within the target system or in an agentless manner operating outside the target system. In the agent-based manner, the collector can directly acquire executable code, memory status, configuration information, and execution events through the operating system or application interface, whereas in the agentless manner, it can indirectly collect status information through an external interface. These implementation methods may be selectively applied depending on the system's security requirements, performance requirements, or operational policies.

[0410] The above collector can acquire various types of data as input, which may include executable files, libraries, configuration files, policy tables, code or data loaded into memory, execution environment information, version information, dependency component information, and execution event information. Additionally, the collector can collect not only a single data element but also a combination of multiple data elements, and such combined data can be used as input for generating an identifier value.

[0411] The aforementioned collector may utilize various technical means during the data acquisition process. For example, at the operating system level, data can be collected through process information interfaces, system call tracing interfaces, event logging mechanisms, or memory access interfaces, while at the application level, data can be acquired through API calls, log streams, message queues, or service interfaces. In the agentless approach, state information can be collected through network-based interfaces or external query interfaces.

[0412] The above collector is not limited to transmitting the collected data as is, but may perform a preprocessing process to align the data structure or remove unnecessary elements as needed. This preprocessing is intended to ensure that data having the same meaning is expressed in a consistent format and may include aligning the data structure, unifying the representation method, or removing non-deterministic elements.

[0413] In addition, the collector may be configured to ensure transmission security during the process of transmitting the collected data to an external verification component. For example, the data may be transmitted through an encrypted communication channel or transmitted in a form to which a message authentication code or digital signature is applied, thereby ensuring the integrity of the data and the reliability of the transmission process.

[0414] The above collector can be configured not to directly perform verification judgment functions and can maintain a structure functionally separated from the verification logic by focusing on data acquisition and transmission functions. This separation can be applied as a design principle to minimize the possibility of data manipulation during the collection phase and to ensure the independence of the verification phase.

[0415] Furthermore, the aforementioned collector is not limited to a single system but can be implemented as a centralized collection structure that collects data from multiple systems subject to verification, and can be expanded into a distributed collection structure as needed. Through such a structure, it can be configured to collect execution states in a consistent manner across various environments and transmit them to the subsequent verification process.

[0416] The collector configured in this way functions as a starting point for converting the execution state into verifiable data, and operates as a foundational element providing reliable input in the integrity verification structure of the entire system.

[0417] 2.3.4 Runtime Integrity Monitoring Agent (RIMA)

[0418] In one embodiment, a Runtime Integrity Monitoring Agent (RIMA) may be configured to operate as a runtime collection and preprocessing layer that collects execution evidence necessary for verification from the run-time state of a digital system, converts the evidence into a runtime identifier of a structure that can be directly compared with a reference state, and transmits it to an external verification structure. Referring to FIGS. 9 and 10, the RIMA may be implemented as a multi-stage processing structure including execution monitoring, normalization, functional block identification, identifier generation, metadata binding, and secure transmission.

[0419] The core processing layer of the above RIMA can first collect one or more of executable files, loaded libraries, configuration information, memory-resident code regions, environment variables, execution event logs, or call flow information from the system under verification. The collected data may undergo processing in the normalization layer, such as timestamp standardization, path normalization, alignment of order-independent data, and removal or separation of non-deterministic elements, and subsequently can be structured according to functions, classes, modules, AST-based execution units, logical object units, or state transition units in the function block identification layer. Accordingly, the above RIMA can convert heterogeneous execution data obtained from the operating state into a comparable input structure.

[0420] The above RIMA can generate runtime identifiers at the functional block level based on structured execution data. In this process, a hash-based identifier may be generated for each functional block, and the identifier may be combined with a module identifier, version information, session information, execution time, policy identifier, execution environment information, or equivalent metadata. The runtime identifier may be generated in the form of a structured package so that it can be directly compared with a reference identifier on an independent verification server.

[0421] The above RIMA may be configured to transmit the generated execution identifier or related execution evidence to an external verification structure through a signed channel or an authenticated communication path. Accordingly, it can be guaranteed that data acquired in the operational state has not been altered during transmission, and the external verification entity can use the data as a trusted input.

[0422] In addition, the RIMA may include extended verification and policy linkage functions in addition to core processing functions. For example, the RIMA may additionally include a self-integrity verification function that periodically checks the integrity of its own components, a local anomaly detection function that detects abnormal execution patterns or unauthorized state changes locally, and a policy trigger function that immediately transmits a signal to a policy-based response module (PB-RM) or an independent verification server when specific conditions are met.

[0423] FIG. 12 is a diagram illustrating a self-check-based failure response and retry flow according to an embodiment of the present invention, showing a structure that branches into maintaining normal execution, blocking execution, entering a recovery procedure, or performing a retry based on the results of a self-integrity check. In addition, it also illustrates a flow in which each processing result is linked to a verification record or an immutable log structure and managed in a traceable manner.

[0424] These functions can be understood as optional extension layers of RIMA and can be applied selectively depending on the security requirements of the system or the operating environment.

[0425] The above RIMA can be implemented not only by residing within the target system but also by operating in conjunction with an adjacent security zone or a separate collection node. Furthermore, the above RIMA is not limited to a method of comprehensively collecting the entire address space but can be configured to perform selective collection targeting executable code areas, loading module areas, critical areas related to policy-critical function blocks, or pre-designated monitoring areas. This allows for securing runtime evidence substantially necessary for integrity verification without imposing an excessive performance burden on the entire system.

[0426] The RIMA configured in this manner can function as a core preprocessing layer that reliably collects verifiable execution evidence from a digital system in operation, structures it into execution identifiers in the form of functional blocks, and links it with an external verification structure. Accordingly, the present invention can provide structural deviations or execution deviations occurring in the operational state to an external verification structure in a form that can be directly compared with a reference state.

[0427] 2.3.5 Identifier Generation Component

[0428] In one embodiment, the identifier generation component may be configured to operate as a core processing layer that generates a reproducible identifier according to predefined generation rules based on input data obtained from the operational state of the digital system or a pre-authenticated reference state. The component is not limited to a single hash generation module and may be implemented as a multi-stage pipeline structure including normalization of input data, functional block division, block identifier generation, metadata combination, and the generation of a final identifier package.

[0429] Referring to FIGS. 4 through 6, the identifier generation component can be implemented in conjunction with input data normalization, multiple hash and tree-based aggregation, metadata combination, digital signature assignment, and reference identifier registration structures. The identifier generation component can operate in conjunction with an integrity monitoring agent (RIMA) or a reference state generation structure, and is configured so that collected execution state data or authenticated reference data are processed according to the same generation rule, thereby enabling direct comparison between the runtime identifier and the reference identifier.

[0430] A runtime identifier can be generated by including the steps of: collecting one or more of an executable file, a loaded library, a memory-resident code area, configuration data, environment variables, and execution event logs from a system in operation; performing normalization to remove non-deterministic elements from the collected data; dividing the normalized data into functional blocks or corresponding logical execution units; generating a cryptographic hash-based identifier for each functional block; combining metadata including a module identifier, version information, execution time, session information, policy identifier, and execution environment information with the identifier; and transmitting the generated runtime identifier to an independent verification server through a signed channel or an authenticated communication path.

[0431] In the above normalization step, timestamp standardization, normalization of path information, alignment of order-independent data, and removal or separation of non-deterministic elements may be performed, thereby configuring execution states having the same meaning to be converted into a consistent input structure. Additionally, the above functional block partitioning may be performed based on one or more of functions, classes, modules, AST-based execution units, logical object units, or state transition units, and accordingly, the above identifier generation component may convert execution states into structured verification data that can be directly compared with reference states.

[0432] The identification value generation step described above may be performed based on a cryptographic hash-based structure in the basic embodiment. For example, a block-unit identification value may be generated by applying SHA-256, SHA-3, or an equivalent hash algorithm to each functional block, and the identification value may be used as a basic input for direct comparison with a reference identification value thereafter. In addition, the identification value generation result may be configured to combine a normalization profile identifier, an algorithm identifier, a policy identifier, and execution context information to ensure reproducibility of the subsequent comparison and verification process.

[0433] Additionally, depending on the embodiment, the identification value generation component may additionally include a multi-hash structure that applies multiple hash algorithms in parallel, a Merkle Tree structure that aggregates block-unit identification values ​​into a tree-based structure, an environment hash generation structure for an execution environment or build environment, and a timestamp combination structure to enhance the verifiability of the generation time. Such structures can be understood as optional extension embodiments of identification value generation and may be selectively applied according to specific security requirements, performance requirements, or audit requirements.

[0434] The finally generated identifier is not limited to a single hash value but may be configured in the form of a structured identifier package combining a block-unit identifier set, a top-level aggregate identifier, an environment hash, time information, and related metadata; said package can be utilized as a runtime identifier or reference identifier to serve as input for comparison, churn judgment, and policy-based response structures in an independent verification server thereafter.

[0435] The identifier generation component configured in this way can function as a core processing layer that enhances the accuracy, reproducibility, and reliability of integrity verification during execution by going beyond simple hash generation functions and generating a comparable identifier structure that reflects the structural characteristics of the input data, the execution environment, the time of generation, and policy conditions.

[0436] 2.3.6 Independent Verification Server (IVS)

[0437] The Independent Verification Server (IVS) operates in an environment that is organizationally, logically, or operationally separated from the system under verification, and can be configured as an independent verification infrastructure that performs comparison of reference identifiers and runtime identifiers, evaluation of the consistency of related metadata, and determination of deviation status. Functions for determining policy-based responses, structured recording of verification results, and external verification linkage can be linked to the aforementioned core verification functions and selectively combined or implemented together within the same verification domain.

[0438] Referring to FIG. 8, the IVS can be implemented in a structure including an integrity verification engine (410), a policy-based response engine (420), a response execution engine (430), an integrity report engine (440), a storage and audit engine (450), and a public and external verification interface engine (460). Additionally, FIG. 5 and FIG. 6 illustrate the linkage with the standard identification value generation and registration structure, and FIG. 11 illustrates the linkage with the function block unit integrity verification and policy response flow. Each of the engines can be arranged to be functionally separated yet interconnected, thereby enabling the entire process from receiving and verifying execution identification values, policy judgment, response execution, recording verification results, and linking with external verification to be performed within a single independent trust system.

[0439] The integrity verification engine (410) can generate a basis result for determining the integrity state by performing a comparison at the functional block level based on the correspondence between the execution identification value and the reference identification value transmitted from RIMA or a similar collection structure, and by evaluating the consistency of the relevant metadata and structural consistency. The integrity verification engine may be configured not to be limited to a single comparison result, but to synthesize the comparison results for multiple functional blocks to generate basis data for determining the integrity state of the entire system.

[0440] The policy-based response engine (420) can identify applicable policies based on comparison results or deviation judgment results received from the integrity verification engine, and determine the final applicable policy according to the risk level, policy priority, and conflict resolution rules. The policy-based response engine can be configured to select different responses depending on the security requirement level of the system, functional importance, regulatory requirements, or operating conditions, and can determine response types such as warning, blocking, isolation, execution restriction, switching to alternative mode, or requesting administrator approval as needed.

[0441] The above response execution engine (430) can function as an execution layer that connects the response result determined by the policy-based response engine to the actual control procedure. For example, the above response execution engine can perform the transmission of warning notifications, session termination, suspension of execution of a specific function block, activation of an alternative module, network isolation, switching to safe mode, or equivalent execution control. In this case, the response execution can be performed in conjunction with a real-time control agent (RCA) inside the system under verification, and the response result can be reflected in the verification record structure thereafter.

[0442] The integrity report engine (440) can generate verification results, policy judgment results, and response execution results in the form of a structured digital integrity report. The storage and audit engine (450) can record the generated report in an immutable storage, an append-only structure, a WORM storage structure, or an equivalent auditable storage structure, and, if necessary, can manage trace information or audit reference information for said records together. The public and external verification interface engine (460) can provide linkage functions so that external users, auditing bodies, or regulatory bodies can access and independently verify said reports or related verification results. However, the detailed field structure of the digital integrity report, the timestamp authentication structure, the chain structure, and the detailed implementation of the public verification channel will be described in more detail in 2.3.11 below.

[0443] The above IVS may be configured so as not to be under the same execution environment or direct control of the same operating entity as the system under verification, and may be operated in an independent environment where authentication domains, data processing rights, access rights, and policy execution rights are separated. Accordingly, the verification results and policy judgment results generated by the above IVS can secure independence from internal interests of the system under verification or the direct influence of the same execution environment. Such independence functions as a key structural element to ensure the objectivity and reliability of the comparison results between the reference state and the operating state in the present invention.

[0444] Furthermore, the above IVS is not limited to a single system subject to verification but can be extended to perform verification in parallel on multiple systems, multiple instances, or multiple functional block groups. Through this, it can be utilized as a common verification infrastructure for multiple systems or multiple industrial domains based on the same Reference Identifier Registry (CRIR) and verification policy framework. If necessary, the above IVS can be extended into a hierarchical or distributed structure, and some functions can be distributed across multiple verification servers.

[0445] The IVS configured in this manner can function as a core independent verification infrastructure that performs direct comparison between the baseline state and the operational state, evaluates the consistency of related metadata, and determines deviations. Policy-based response, structured evidence recording, and external public verification linkage functions can be linked to the aforementioned core verification function and selectively combined or implemented together within the same verification domain.

[0446] 2.3.7 Integrity Verification Engine (IVE)

[0447] The Integrity Verification Engine (IVE) can be configured to operate as a core comparison component for determining an identifier-based integrity state by directly matching and comparing a runtime identifier and a reference identifier generated at the function block level.

[0448] In one embodiment, the integrity verification engine may receive an execution identifier, a reference identifier, and identification information or metadata indicating the corresponding relationship between them as input, and the input data may be structured and processed in units of functional blocks. Accordingly, the integrity verification engine may perform a direct comparison by mapping the execution identifier and the reference identifier corresponding to each functional block.

[0449] The verification engine described above can evaluate the consistency between the execution identifier and the reference identifier according to the following procedure. First, a corresponding reference identifier can be selected based on the function block identifier, module identifier, or version information included in the execution identifier. Next, the identity can be determined by directly comparing the identifiers themselves between the execution identifier and the reference identifier. Subsequently, the consistency of the execution environment, version information, policy identifier, normalization profile identifier, or related metadata can be further reviewed along with the result of the identifier comparison. If an identifier discrepancy or a related condition discrepancy is identified through such stepwise comparison, the corresponding state can be used as basic data for determining the divergence state.

[0450] Based on the above comparison results, cases such as hash value discrepancies of core function blocks, failure to map unauthorized version identifiers or reference identifiers, discrepancies of normalization profile identifiers, omissions or modifications of policy-mandatory comparison items, or changes to unauthorized function block structures or block combinations may be classified as hard mismatches. Since such hard mismatches signify a direct violation of consistency with the reference state, they may, in principle, be determined to be in an out-of-state immediately without further mitigation considerations.

[0451] Conversely, differences in supplementary metadata regarding non-core function blocks, differences in environmental information within the scope permitted by policy, allowed time errors, or differences related to pre-approved alternative configurations may be classified as soft mismatches. Only when the above soft mismatch occurs, flexible verification may be performed within the scope permitted by policy; even in this case, the matching of identification values ​​of core function blocks and the essential metadata conditions must be satisfied first. Accordingly, in the present invention, flexible verification functions not as an independent comparison method replacing strict verification, but as an auxiliary judgment step applied exceptionally after strict verification.

[0452] The integrity verification engine described above is not limited to comparison results for a single functional block but can be utilized to determine the integrity status of the entire system by synthesizing comparison results for multiple functional blocks. For example, a hard mismatch in a specific core functional block can be interpreted as a serious deviation at the overall system level, while a soft mismatch in a non-core functional block can be classified as a warning state or a state requiring further verification depending on policy conditions.

[0453] In addition, the integrity verification engine may perform auxiliary verification considering multiple reference identification values, approved alternative configurations, or acceptable variation ranges as needed. However, such auxiliary verification should be understood as an extended judgment structure applied restrictively within a policy-permitted range, rather than altering the basic integrity judgment structure of the present invention.

[0454] The above verification results can be recorded in units of functional blocks and can be generated as structured verification result data including whether a deviation occurred, identification information of related functional blocks, applied comparison conditions, and verification time information. These results can subsequently be utilized as input for a deviation judgment structure, a policy-based response structure, and a digital integrity report generation structure.

[0455] The integrity verification engine configured in this manner functions as a central component of identifier-based integrity judgment that directly corresponds and compares the execution state with a reference state, and forms a core comparison layer for technically determining whether the operational state of a digital system is substantially identical to the reference state.

[0456] 2.3.8 Metadata Integrity Verification Engine (MIVE)

[0457] The Metadata Integrity Verification Engine (MIVE) can be configured to operate as a meta-information-centric component that verifies whether metadata, execution environment information, and policy-related state information collected at runtime are consistent with a reference state or predefined policy conditions.

[0458] In one embodiment, the MIVE receives metadata and state information collected at the time of execution as input and can determine consistency by comparing this with reference information corresponding to a reference state or policy condition. The MIVE may operate in combination with an integrity verification engine (IVE) or be implemented as a separate independent verification module, and can play a role in performing extended verification that includes changes in the execution environment, policy state, and structural execution conditions that are not detected by identification value-based comparison alone.

[0459] The input information of the above MIVE may be optionally configured according to the scope of verification and may include, for example, configuration information, policy information, execution environment information, version information, session or request context information, loaded dependency component information, execution flow information, or a combination thereof. The input information may be structured and processed at the functional block level or the system level.

[0460] The above MIVE can map the input information to reference information corresponding to a reference state or policy condition and compare them, and in this process, a function block identifier, policy identifier, normalization profile identifier, execution context, or version information may be used as a comparison criterion. Accordingly, the above MIVE is not limited to simply checking for value matching, but can determine whether the execution environment and policy condition are structurally consistent with the reference state.

[0461] In one embodiment, MIVE can verify metadata items by classifying them into mandatory metadata and optional metadata. Mandatory metadata may include version information, policy identifiers, normalization profile identifiers, approved execution environment identification information, or equivalent items, and discrepancies in these items may, in principle, be interpreted as a hard mismatch or a significant mismatch equivalent thereto. On the other hand, optional metadata may include additional environment information, auxiliary logging information, descriptive context fields, or auxiliary information permitted by policy, and differences in these items may be interpreted as a soft mismatch depending on the policy.

[0462] The above MIVE can determine an integrity violation state or divergence if the metadata does not satisfy the reference state or policy conditions, even when the execution identifier matches the reference identifier. For example, even if the same code is executed, if it operates in an unauthorized execution environment, an unauthorized policy version is applied, or the execution flow conditions do not align with the reference state, the above MIVE can determine this as a structural divergence state. Through this, the present invention can provide a verification structure that evaluates the reliability of the entire execution environment, going beyond code identity verification.

[0463] In addition, the above MIVE can operate in conjunction with execution flow information or result source verification structures. For example, if a specific function block does not follow a pre-approved call sequence or state transition flow, the MIVE can use this as grounds for an abnormal state, and this result can be combined with the IVE result in an out-of-bounds judgment structure and used as input for a final integrity state judgment.

[0464] The verification results of the above MIVE can be generated as structured result data including verification results by metadata item, overall consistency judgment results, identification information of related function blocks, and applied verification criteria information. These results can be combined with the results of the integrity verification engine (IVE) and used as input for a comprehensive integrity judgment, and can subsequently be linked to a policy-based response structure and a digital integrity report generation structure.

[0465] The metadata verification engine configured in this manner complements identifier-based integrity verification and functions as a component that performs multidimensional verification including code, configuration, execution environment, policy conditions, and execution flow information, forming a core metadata verification layer that determines whether the operational state of the digital system is structurally consistent with the reference state.

[0466] Furthermore, execution flow information or result source consistency determination can be understood as an extended verification element that can be optionally combined with the metadata verification engine, and is not limited to being an essential prerequisite for establishing the identifier-based integrity verification itself.

[0467] 2.3.9 Divergence Determination Structure

[0468] The deviation judgment structure can be configured to operate as a higher judgment layer that synthesizes the comparison results generated by the integrity verification engine (IVE) and the metadata verification engine (MIVE) to ultimately determine whether the run-time state of the digital system aligns with the reference state or policy conditions.

[0469] In one embodiment, the deviation determination structure may be configured to calculate a final integrity state by synthesizing the identification value comparison result generated in the IVE, the metadata and execution environment consistency evaluation result generated in the MIVE, and policy condition or function importance information. Accordingly, the deviation determination structure may perform the function of structurally determining whether a deviation has occurred, the type of deviation, and the risk level by integrating multiple judgment elements, rather than drawing a conclusion based on a single comparison result.

[0470] The above deviation determination structure can first determine whether there is a hard mismatch based on the comparison results of the IVE. If a direct discrepancy between the execution identifier and the reference identifier occurs in the core function block, or if conditions such as an unauthorized version identifier, a normalization profile mismatch, the omission of policy-mandatory comparison items, or an unauthorized function block structure change are confirmed, the status can, in principle, be immediately determined to be a deviation state.

[0471] If no hard mismatch is identified, the above deviation determination structure may further evaluate, based on the results of MIVE, whether metadata, execution environment information, policy identifiers, version information, execution flow information, or other policy-significant state information aligns with the reference state or policy conditions. In this process, if conditions such as differences in additional metadata for non-core function blocks, differences in policy-allowed environment information, allowed time errors, or differences related to approved alternative configurations are identified, the discrepancy may be classified as a soft mismatch.

[0472] Flexible verification may be performed restrictively according to predefined policies and allowance conditions, only when the aforementioned soft mismatch is confirmed. This flexible verification does not replace strict verification but functions as an auxiliary judgment step applied exceptionally after the results of strict verification; even in this case, the matching of the identification values ​​of the core function blocks and the mandatory metadata conditions must be satisfied first. If the results of the flexible verification satisfy the allowance conditions, it may be classified as a normal state or a warning state, and if it fails to satisfy the allowance conditions, it may be confirmed as an exit state.

[0473] The above deviation judgment structure is not limited to a simple normal / abnormal dichotomy but can be configured to determine the type of deviation, scope of impact, and risk level together. For example, minor configuration differences may be classified as a low-risk warning state, while discrepancies in core function blocks, unauthorized changes to execution structures, or abnormalities in the source of execution results may be classified as a high-risk deviation state. This risk level classification can subsequently be used as a criterion for determining the response method applied by the Policy-Based Response Module (PB-RM).

[0474] In addition, the above deviation determination structure may operate in conjunction with the results of Execution Authenticity Verification or execution flow information as needed. For example, even if the execution identifier itself matches the reference state, if the result is generated through an unauthorized execution path or an abnormal call flow, the above deviation determination structure may determine this as a structural deviation state. Through this, the present invention can provide an extended determination structure that includes the generation path of the execution result, going beyond simple identification value comparison. The linkage with the above execution authenticity verification exemplifies an extended determination structure in a high-trust environment, and the basic deviation determination structure of the present invention should not be interpreted as necessarily including the above additional verification.

[0475] The output of the above deviation judgment structure may be generated in the form of a structured judgment result including whether a deviation occurred, the type of deviation, the identifier of the affected functional block, relevant metadata items, applied judgment criteria, and risk level information. This result may be transmitted to a policy-based response module (PB-RM) to be used as a trigger for response measures, and simultaneously recorded as a component of a digital integrity report to be utilized in subsequent audit, tracing, or external verification procedures.

[0476] In addition, the above-mentioned deviation judgment structure may record input data, applied judgment criteria, evaluation results, and policy conditions or store them in a log format to ensure the reproducibility of the verification process, and this can be linked with a chain of custody structure to ensure the traceability of the verification results.

[0477] The deviation judgment structure configured in this manner functions as a core judgment layer that comprehensively evaluates whether the operational state of a digital system is structurally consistent with a reference state by performing multidimensional judgments that go beyond simple identification value comparisons and include codes, settings, execution environments, execution flows, and policy conditions. Through this, the present invention completes a comprehensive judgment structure that enables the technical verification of reliability at the time of execution.

[0478]

[0479] 2.3.10 Policy-Based Response Module and Control Structure

[0480] In one embodiment, the Policy-Based Response Module (PB-RM) may be configured to operate as a component that determines a response method by applying a predefined policy based on the integrity verification result or a judgment result derived by an out-of-bounds judgment structure, and generates control commands accordingly. The PB-RM may be implemented by being included within an Independent Verification Server (IVS) or separated into a separate policy processing module, and may function as a decision layer that reflects the verification result in the actual system operation. This section is intended to explain the configuration and linkage structure of the Policy-Based Response Module and the Real-Time Control Agent; the logic for deriving the policy conclusion itself follows the policy-based judgment structure described in Section 2.8, and this section focuses on the structure in which that conclusion is connected to the actual response procedure.

[0481] The above policy-based response structure can be understood as an extension layer coupled to the core integrity verification structure. That is, the comparison between the reference state and the execution state, and the deviation determination itself, can be performed independently of the policy-based response, and the policy-based response functions as a subsequent structure that connects the results of the comparison and determination to system control or operational response.

[0482] The above PB-RM can receive, as input, verification results transmitted from the integrity verification engine (IVE) and the metadata verification engine (MIVE), escaping information generated from the escaping judgment structure, execution environment information, and policy identifiers, and can select a policy to apply and determine a response method based on this.

[0483] In one embodiment, the policy may be configured to include one or more of the following elements: identification value comparison criteria and allowable ranges, metadata verification conditions and exception conditions, importance grades of function blocks or services, response priorities and response methods based on risk levels, control rules (e.g., session termination, function restriction, administrator notification, performing additional verification, etc.), and conditional response rules based on environmental conditions or user status. These policy elements may be applied as a single condition or a combination of multiple conditions and may be selectively configured according to the security requirements of the system or operational purposes.

[0484] The above policy can be defined as a declarative, rule-based, or table-based structure and implemented in various representation formats. For example, the policy can be defined in a structured data format and interpreted by a policy engine, or configured in the form of a rule set to perform condition evaluation and response decisions. Additionally, the policy can be managed through version control, change history tracking, or approval procedures, thereby enabling the tracking of the scope of impact resulting from policy changes.

[0485] The above PB-RM can determine a response method based on input verification results and policy conditions, and the response method is not limited to a single measure but can be configured as a complex response structure including multiple control measures. For example, it can be configured to immediately terminate the session and notify the administrator while performing additional verification procedures when a specific churn is detected. Furthermore, the response method can be applied in stages depending on the type of churn, the scope of impact, and the risk level.

[0486] The corresponding result determined by the above PB-RM can be generated in the form of a control command, and the control command can be transmitted to a Runtime Control Agent (RCA) and reflected in the actual system operation.

[0487] In one embodiment, the Real-time Control Agent (RCA) may be configured to operate as an execution entity that receives control commands transmitted from the PB-RM, interprets them, and applies them to the operation of the target system. The RCA may be deployed within the target system or in an adjacent execution environment and may perform system control in various ways, such as API calls, command execution interfaces, configuration change interfaces, application of access control policies, or processing flow control.

[0488] The above RCA can be configured to perform granular control at the function block, session, or service level, and can operate by restricting the execution of specific function blocks, terminating specific user sessions, or disabling certain functions of a service. Additionally, the RCA can generate the results of applying control commands in the form of status information or events and transmit them to an external verification structure, thereby allowing the response results to also be included in the verification and auditing process.

[0489] The above PB-RM and RCA are structures that mediate the control flow between the verification area and the operation area, and can be configured to be linked through a unidirectional or limited interface so that the verification results can directly affect the operation system, but the verification logic is not inversely affected by the operation logic.

[0490] In summary, the policy-based response structure in this section concerns the execution layer that connects the policy conclusions derived in 2.8 to actual control procedures. Therefore, the identification of applicable policies, severity assessment, and the application of conflict resolution rules follow the judgment structure of 2.8, and this section focuses on the structure for the transmission, application, and recording of application results of the control commands generated as a result.

[0491] In addition, the above policy-based response structure may adjust the intensity or scope of application according to the system state, operating environment, or security requirement level, and may be implemented as an adaptive control structure that strengthens or weakens the response intensity under specific conditions.

[0492] The policy-based response module and control structure configured in this manner function as a core control layer that connects integrity verification results to actual system operations. By forming a closed-loop structure in which verification, judgment, and response are sequentially linked, it plays a role in maintaining and guaranteeing reliability in real time during the execution of the digital system.

[0493] 2.3.11 Digital Integrity Report and Public Verification Structure

[0494] In one embodiment, the Digital Integrity Report may be configured to be generated as an evidence data object for recording verification results, policy application results, and related execution information derived from the integrity verification process in a structured form that is externally verifiable. The Digital Integrity Report is not limited to simple internal logs or operator status records; rather, by consistently linking and expressing the execution status at a specific point in time, the verification results regarding that status, and the judgments and response details based thereon, it can function as a structure to ensure the traceability, integrity, and independent external verification of verification results. Furthermore, the Digital Integrity Report and the public verification structure can be understood as a separate extension layer for recording and providing the results of the core integrity verification structure or the policy-based response structure in a form that is externally verifiable. Accordingly, the public verification structure may be combined with an automated response structure, but it may also be implemented as a structure that allows external entities to independently verify the verification results themselves, regardless of the existence of the automated response.

[0495] Referring to FIG. 15, the digital integrity report may be configured to include identification information of the verification target, identification information of a function block or a corresponding logical execution unit, a reference identifier, a runtime identifier, a comparison or judgment result, the time of verification execution, and information of the entity that generated the report. These pieces of information may function as a minimum set of fields to consistently identify the target, reference, execution status, judgment time, and the entity that generated the verification result. Additionally, depending on the embodiment, the digital integrity report may additionally include one or more of a policy identifier, response action information, previous report hash value, environment metadata, session identifier, signature verification information, timestamp token, and reference information for external verification. These additional fields may be used as optional fields to enhance the interpretability of the verification result, the traceability of policy application and response history, the connectivity between reports, and the possibility of independent verification by an external entity.

[0496] The above digital integrity report may include a digital signature or an equivalent trust granting means so that its authenticity and integrity can be verified externally. For example, the report may be combined with an electronic signature from an independent verification server or a separate report signer, and said signature may be provided so that users, auditing bodies, or regulatory bodies can independently verify it through a public key-based verification structure.

[0497] Referring to FIG. 13, the digital integrity report may be combined with trusted time information, and in one embodiment, the time information may be included in the form of a time token issued by a trusted third-party Time Stamping Authority (TSA). This allows the report to be configured to be externally verifiable that it existed at a specific point in time and has not been altered since. The time authentication structure may be implemented by transmitting a report hash or equivalent identification information to a Time Stamping Authority, receiving a corresponding authentication token, and combining it with the report.

[0498] Referring to FIG. 14, the digital integrity report may include reference information linked to a previous report or related verification data, thereby forming a hash chain structure in which multiple reports are connected in chronological order. For example, each report may include one or more of the hash value of a previous report, a previous event identifier, a previous verification time, or a previous report reference token, thereby maintaining sequential connectivity between verification results, historical continuity, and a chain of custody. Through this structure, an attempt to tamper with a specific report can be detected through a discrepancy in the connection relationship between preceding and succeeding reports.

[0499] Referring to FIG. 16, the digital integrity report can be managed within a data model structure that is interconnected with a baseline record, execution record, verification record, policy evaluation record, response execution record, and storage record. Accordingly, a single report can function not merely as a set of simple result values, but as part of structured evidentiary data that includes verification inputs, comparison results, policy judgments, and response history. The data model structure can be used as an infrastructure to enhance the reproducibility, traceability, and auditability of the report.

[0500] Furthermore, the digital integrity report may be recorded in an immutable storage, a WORM (Write Once Read Many) storage structure, an append-only log structure, a distributed ledger, or an equivalent storage structure to prevent alteration or subsequent tampering. Accordingly, the report may be configured to restrict modification or deletion after storage, or to enable tracking of any attempted modifications; the report may also be utilized as evidence for post-audits, dispute resolution, or external verification purposes.

[0501] Referring to FIG. 17, the digital integrity report may be provided so that an external entity can view and verify it through a Public Verification Interface. The key to the public verification structure is that the external entity can view the verification result or the digital integrity report and independently verify the integrity, signature validity, timestamp information, or linkage structure of the result.

[0502] The aforementioned public verification structure can be implemented through various external channels. For example, general users or external entities with restricted privileges can view the system's current integrity status, verification results at a specific point in time, history of recent outflows, or summary reports through web-based dashboards, mobile interfaces, or equivalent user interfaces. Additionally, external systems, automated audit tools, supervisory systems, or third-party services can mechanically receive verification results, report data, hash values, signature information, and timestamp information via Application Programming Interfaces (APIs) and independently verify them.

[0503] The above-mentioned public verification structure may include a dedicated interface linked with an auditing firm or a regulatory body. In this case, the auditing firm or the regulatory body may query or receive more detailed reports, policy application information, response history, chain of custody information, and signature verification information, and may perform independent audits, conformity assessments, or supervision procedures based on this information. The above-mentioned linkage structure may be implemented via file transfer, API calls, a message broker, a dedicated audit channel, or an equivalent method.

[0504] Furthermore, the above-mentioned public verification structure is preferably implemented centered on a public verification interface, and linkage with a physical disclosure channel or a public notification channel may be optionally added depending on specific service environments or regulatory requirements. For example, verification results or status information may be provided auxiliaryly through an LED display, electronic display board, physical display panel, public display, kiosk terminal, or equivalent physical output means as needed. However, such physical output means should not be interpreted as essential elements constituting the common core structure of the present invention.

[0505] When identical or corresponding verification results are provided through multiple external channels, the public verification structure may be configured to optionally perform cross-channel verification. However, cross-channel verification may be understood as an auxiliary verification function additionally coupled to the basic public verification structure of the present invention centered on the public verification interface.

[0506] Referring to FIG. 18, the public verification interface may operate in combination with role-based access control (RBAC), user authentication, and data verification functions, and the scope and level of detail of the information provided may be differentiated according to user type or authority level. For example, general users may be provided with status summary information or basic verification results, while auditing bodies or regulatory bodies may be additionally provided with detailed reports, policy application information, response history, and information related to the chain of custody. Accordingly, the public verification structure may also include a control structure that prevents unauthorized access or excessive exposure of verification data while ensuring external verifiability.

[0507] The digital integrity report and public verification structure configured in this manner does not limit verification results to mere internal processing outcomes; instead, by connecting the generation, timestamping, chain linking, storage, access control, and external verifiability of verification results into a single continuous structure, it provides a technical foundation that enables external entities to independently review and verify the integrity status of a digital system during operation.

[0508] 2.4 Baseline Generation

[0509] In one embodiment, the reference state generation and registration step may be performed as a procedure to establish a reliable reference for the digital system under verification, and it is preferable that this be performed by a third-party certification authority in an independent environment. The step is not merely a process of generating a hash value, but includes a procedure to define a reference state including the executable form of the system under verification and its operating conditions, and to convert this into a reproducible and verifiable structure for registration.

[0510] The generation of the above reference state may begin with a step of receiving input data related to the system to be verified. At this time, the input data may be provided by the development entity or the deployment entity and may include source code, build scripts, compilation environment information, dependency libraries, configuration files, policy tables, container images, executable files, or equivalent execution products. Additionally, configuration information of the actual deployment environment or production environment may be provided as needed.

[0511] A third-party certification authority may define criteria for partitioning into functional block units based on the above input data. In this process, for systems based on compiled languages, functional blocks may be defined at the level of functions, classes, or modules, while for script-based systems, execution units based on ASTs or units that are independently executable on a call graph may serve as the criteria. Additionally, for configuration data or policy data, partitioning may be performed at the level of logical objects, and for event-based systems, functional blocks may be defined at the level of state transitions or processing flows.

[0512] Once the functional block partitioning is complete, testing and verification procedures can be performed for each functional block. The verification procedures performed at this stage are not limited to simple functional operation verification but may include standard conformity testing, reproducibility verification, interface consistency verification, and environmental dependency analysis. For example, the determinism of execution can be verified by confirming whether the same result is repeatedly generated under identical input conditions, and the acceptable range of variation can be defined by analyzing the impact of specific configuration values ​​or environmental conditions on the result.

[0513] In addition, a certified execution configuration may be determined during the verification process. The certified execution configuration refers to a reproducible execution state that includes a specific build environment, compiler version, library combination, and configuration status, and can be used as a reference environment to ensure that the same result is generated under the same conditions thereafter. To this end, a third-party certification authority may create and preserve snapshots of the build environment and the execution environment, and said snapshots may be managed in the form of environment metadata. In one embodiment, the build environment may be implemented as a container-based reproducible build environment or an equivalent isolated reproducible build environment. For example, by fixing or recording a Docker image or an equivalent container image, build scripts, dependency library version information, environment variable configuration, and compiler configuration together, the reproducibility of the reference identification value for the same functional block can be ensured.

[0514] For the function blocks and execution configurations determined as above, an identifier generation component may be applied to generate a reference identifier. It is preferable that this process follow the same procedure as the identifier generation pipeline defined in 2.3.5, and may include normalization, block splitting, block-unit hash generation, tree-based aggregation, and environment hash generation.

[0515] Specifically, after normalized input data is generated for each function block, block-unit identifiers can be generated using SHA-256, SHA-3, or an equivalent hash algorithm. Subsequently, the block identifiers can be combined into a Merkle Tree structure to generate a root identifier representing the entire set of function blocks. Simultaneously, environment snapshots of the build and execution environments can be hashed to generate an environment hash.

[0516] The above-mentioned reference identifier is not a single value but can be generated as a structure including a set of block identifiers, a root hash, and an environment hash, wherein a functional block identifier, version information, a normalization profile identifier, hash algorithm information, and generation time information can be combined as metadata.

[0517] In addition, the aforementioned reference identifier can be generated in combination with a digital signature and a timestamp. A third-party certification authority can generate a signature for the reference identifier and metadata using its private key, and, if necessary, can issue a timestamp token regarding the time of generation through a Timestamp Authority (TSA). This allows for external verification that the reference identifier was generated by a specific entity at a specific time.

[0518] The generated reference identifiers and related metadata may be registered in a Reference Identifier Registry (CRIR). The CRIR may not be a simple repository, but may be configured as a trusted storage structure that maintains version control, history tracking, and verifiability of the reference identifiers. For example, version-specific reference identifiers for the same functional block may be managed, and the change history and coverage between each version may be recorded.

[0519] In addition, CRIR may include an immutable storage structure, a hash chain structure, or a distributed ledger-based storage method to protect the integrity of registered reference identification values, thereby minimizing the possibility of alteration or falsification of reference information.

[0520] Consequently, the reference identifier generated and registered in this stage functions as the sole reference for comparison with subsequent execution states, and forms the starting point of trust for the entire integrity verification structure by ensuring that the reference was generated independently of external influences.

[0521] 2.5 Runtime Data Acquisition

[0522] In one embodiment, the execution state collection step may be performed as a procedure to acquire data and execution evidence corresponding to the run-time state of the digital system under verification while the system is operating in an actual operating environment, and to provide them in a form that enables subsequent integrity verification. In the present invention, this step functions as a starting point for generating execution-side inputs for comparison with a reference state, and should be understood not as simple log collection or state inquiry, but as a process of extracting actual executed code, referenced settings, invoked function blocks, applied execution environments, and generated events into a verifiable structure.

[0523] The above-mentioned execution state collection can be performed by an integrity monitoring agent (RIMA), a collector, or an auxiliary module associated with them, and can be implemented in an agent-based, agentless, or mixed manner depending on the structure of the system under verification, the level of security requirements, and the operating environment. In the agent-based method, a RIMA deployed inside the target system or in an adjacent execution environment can directly observe or track the execution state, while in the agentless method, state information can be collected through an external interface. However, regardless of which implementation method is selected, the collected data must be convertible into a form that can be directly compared with a reference state in the subsequent identifier generation component.

[0524] The targets of execution state collection are not limited to static files and may include various elements that reflect the actual operational state. For example, executable files, libraries, dynamically loaded modules, code areas loaded in memory, data areas, configuration files, policy tables, environment variables, session information, dependency component version information, container or virtualization environment information, function call events, return events, state transition information, API request flows, transaction processing paths, and information on the time of execution result generation may be included. These elements may be collected individually or as composite execution evidence in the form of multiple elements combined.

[0525] In one embodiment, the execution state collection step is not limited to dumping the entire memory space even when collecting memory states, but may be performed by selectively collecting memory ranges that are meaningful for verification purposes. The selective collection targets may include, for example, one or more of an executable region where executable code is loaded, a loaded module region where dynamically loaded libraries or plugins are loaded, a critical region associated with a core function block according to policy, or a designated monitored region that has been previously designated as a verification target. Through such a selective collection structure, the present invention can be configured to secure runtime evidence substantially necessary for integrity verification while mitigating the excessive performance burden caused by collecting the entire memory.

[0526] The collection of the above execution state can be performed using different technical means depending on the system layer. At the operating system level, process identification information, memory maps, lists of loaded modules, file access status, process creation and termination events, system call events, and thread activity information can be collected. For example, in Linux-based environments, / proc, ptrace, eBPF, audit subsystem, inotify, fanotify, kprobe, uprobes, or equivalent interfaces can be used, and in Windows-based environments, ETW (Event Tracing for Windows), WMI, system APIs, DLL load events, process and thread events, or equivalent interfaces can be used. At the application layer, evidence of execution flow can be collected through function call hooking, RPC interceptors, message queue event observation, database access logging, inter-service call chain tracing, or application log stream analysis.

[0527] The aforementioned collection of execution states aims not merely to verify "what exists," but to secure evidence that proves "what was actually executed." For example, the mere fact that a specific executable file exists on disk is insufficient; it is desirable to collect information on whether the file was actually loaded, which function blocks were invoked, which configuration objects were referenced, and through which specific sessions or requests were completed. This structure serves as a prerequisite for identifying operational exit states that cannot be captured by static integrity checks alone.

[0528] The aforementioned collection of execution state can be performed in a continuous or event-based manner. For example, a periodic method that collects the state in the form of snapshots at regular intervals may be applied, or an event-based method in which collection is triggered by specific function calls, component loading, configuration changes, session initiation, policy violation candidate events, or external requests may be applied. Additionally, a request-based method that collects additional data limited to specific function blocks or specific sessions based on requests from a validation server or policy engine may be applied. These methods are not mutually exclusive but can be applied in parallel or hierarchically combined depending on system requirements.

[0529] For example, it can perform only lightweight periodic collection during normal operations, but switch to event-based or request-based high-density collection when anomalies are detected. This structure minimizes the performance burden while securing more precise execution evidence during periods of high security. This adaptive collection method can be dynamically adjusted based on the importance of function blocks, service sensitivity, policy conditions, or external audit requirements.

[0530] Additionally, during the execution state collection phase, the scope of verification of the collection target can be determined. For example, only the executable code of a specific function block or module may be collected, or it may include configuration information and policy tables; in some cases, it may also include data state in memory, execution environment information, call flow information, and state transition information. This verification scope is not fixed but can be expanded or contracted according to the policy; it can be configured to collect only a limited scope during normal conditions and to collect a broader range of evidence when a candidate for deviation is detected.

[0531] The collected data can be structured at the function block, session, request, or time point level so that it can be processed directly during the subsequent identifier generation stage. In this process, it is desirable that the raw event stream is not maintained as a simple list of events, but is reorganized into a set of execution evidence attributed to specific execution flows and function blocks. For example, if function call events and configuration access events belong to the same request context, they can be combined into a single execution context package and used as input for subsequent identifier generation.

[0532] Data obtained during the execution state collection step described above may be used immediately for generating identifiers, but depending on the implementation, it may undergo temporary buffering, queuing, or structured storage after collection. For example, in environments where high-frequency events occur, real-time events can be temporarily stored in a buffer and then grouped into time windows for processing; when a specific session or request ends, the entire execution flow can be consolidated into a single collection unit. This structure serves to bridge the gap between granular collection at the event level and verifiable structuring at the functional block level.

[0533] In the aforementioned collection step, not only the execution status but also contextual information of the execution environment may be collected. For example, this may include the operating system version, runtime version, loaded library versions, container image tags, deployment unit identifiers, hardware or virtualization environment identification information, user or session identifiers, policy identifiers, and time information. This information is not merely auxiliary data but can function as a core input used later to determine the consistency of environment hashes or metadata. In particular, the collection of such environment information is essential in systems where the same code can produce different results in different environments.

[0534] In addition, the execution state collection step can be linked with the Execution Authenticity Verification structure. For example, it can collect information on which function blocks were called in what order at the time a specific result value is generated, which session or request context the result was generated from, and which policy was applied during the process. Accordingly, evidence can be secured regarding not only the fact that "a result was generated," but also "through which execution path it was generated."

[0535] In the aforementioned execution state collection step, protective measures to ensure the integrity and reliability of the collected data may be applied. For example, time-of-creation information may be combined with the collected raw data or structured execution evidence, and RIMA or the collector may apply a digital signature or message authentication code to the data. Additionally, the collected data may be temporarily stored in a protected memory area or trusted local storage until it is transmitted to a verification server, and access control and encryption may be applied as needed. This reduces the risk that the collection step itself may be bypassed or manipulated by an attacker.

[0536] Depending on the embodiment, the execution state collection step may be linked with a self-verification structure for the RIMA itself. For example, identification values ​​for the RIMA's executable file, configuration state, memory state, or communication module itself may be generated, collected together with general execution state data, and transmitted to an external verification server. Through such a structure, it is possible to detect even if the RIMA itself, which acts as a sensor for the verification system, is tampered with or bypassed.

[0537] Additionally, a local drift or anomaly detection function can be combined with the collection phase. For example, if abrupt changes in function call frequency, unexpected module loading, abnormal configuration access, or abnormal patterns in the execution flow are detected, the local detection function can transmit this to a policy trigger interface to induce additional collection, enhanced verification, or early response. In this case, the execution state collection phase can be expanded from simple manual collection into an active monitoring phase that adjusts the collection intensity and scope according to the risk level.

[0538] The output of the above-mentioned runtime state collection may not be a simple set of raw logs, but rather a structured runtime evidence package that can be directly utilized in the identifier generation stage. The runtime evidence package may include function block identifiers, execution code snapshots, memory state summaries, configuration object information, call event sequences, environment context, session or request identification information, policy context, and time-information. Such a structured package may subsequently be used as an input unit in the normalization and identifier generation stages.

[0539] An important point is that the execution state collection step of the present invention is a "step for collecting evidence for integrity verification during operation." That is, the data obtained in this step is distinguished from simple monitoring statistics or performance data, and must be verifiable input that has a correspondence with a reference state. Therefore, it is desirable that the execution state collection be designed to comprehensively secure evidence at the functional block, environment, and execution flow levels, so that consistency comparison with the reference state can be performed thereafter.

[0540] The execution state collection step configured in this manner secures execution evidence reflecting the actual executed state and flow from the digital system during operation, and structures this into a form that can be transmitted to the subsequent identification value generation and independent verification steps, thereby serving to form a substantial input basis in the runtime integrity verification system of the entire invention.

[0541]

[0542] 2.6 Identifier Generation and Normalization

[0543] In one embodiment, the identifier generation and normalization step may be performed as a procedure to convert runtime evidence obtained in the run state collection step into an identifier that can be directly compared with a reference state. The step is not limited to simple hash operations and may consist of a multi-stage processing pipeline including normalization of input data, functional block partitioning, block-unit identifier generation, tree-based aggregation, combination of environment information, and metadata structuring.

[0544] It is preferable that the above identification value generation procedure be performed according to rules identical to or compatible with the generation rules used in the reference state generation step, thereby enabling a direct consistency comparison between the runtime identifier and the reference identifier. In other words, the key is to maintain a deterministic characteristic where the same identification value is generated when the same input conditions and processing rules are applied.

[0545] The identification value generation procedure may first begin with a step of receiving an execution evidence package transmitted from the execution state collection step as input. The input data may include execution code, configuration information, memory state summary, execution event sequence, environment context information, and execution flow information at the session or request level, and these may be provided in a structured state at the functional block level or execution level.

[0546] The above input data is not hashed as is, but can be processed through a normalization step so that data with the same meaning is transformed into the same representation form. This normalization step is an essential procedure to ensure the reproducibility and comparability of identification values, and it serves to prevent the problem where the same state is calculated as a different identification value due to differences in data representation.

[0547] The normalization process can be performed in different ways depending on the data type. For example, binary data such as executable files or libraries can be normalized by removing or ignoring padding areas, alignment differences, or non-deterministic build elements. For configuration information or policy data, key order sorting, field structure unification, removal of unnecessary fields, and standardization of value representation formats can be performed. For memory state data, normalization can be performed by removing non-deterministic elements, such as address values ​​or time-dependent values, and extracting only meaningful data structures.

[0548] Normalization of memory-based input data may be performed only on selected memory ranges, in which case address relocation information, time-dependent values, temporary buffer values, or volatile fields excluded from comparison by policy may be removed, masked, or separated into separate metadata.

[0549] Accordingly, the memory-based execution identifier does not correspond to a complete copy of the entire memory, but can be generated as a result of extracting a comparable semantic state from the memory range designated as the verification target.

[0550] Additionally, for execution event sequences, event ordering, removal of duplicate events, filtering of meaningless events, or reorganization based on call flow can be performed. Such normalization can be performed according to a predefined normalization profile (norm_profile_id), and the corresponding profile information is included in the result of generating the identifier value to enable comparison under the same conditions during the subsequent verification phase.

[0551] Normalized input data can be divided into functional blocks or data blocks. The division can be performed based on the size of the data or based on logical execution units.

[0552] In the case of size-based partitioning, input data can be divided into blocks of a fixed size (e.g., 64KB units), and each block is defined as the minimum unit capable of independently generating an identification value. This method enables efficient verification of large-scale data processing and partial changes.

[0553] In the case of logical partitioning, data can be divided into units of functions, classes, modules, configuration objects, or execution flows, and each unit is defined as a function block. In this case, each function block has an independent identifier and can be compared individually during the subsequent verification phase.

[0554] In addition, input data can be processed not only as simple block data but also combined with domain identification information (domain tag), execution context information, session identifiers, and policy identifiers. This allows for configuration to prevent conflicts between identifiers generated in different execution contexts, even for identical data.

[0555] For each block divided as described above, the identification value generation component can generate a block-unit identification value by applying a cryptographic hash function. In this case, hash generation is not limited to a single algorithm but can be performed using a multi-hash structure that applies multiple hash algorithms in parallel.

[0556] For example, SHA-256-based hashes and SHA-3-based hashes can be generated simultaneously for the same block of data, and high-performance hash algorithms such as BLAKE2 or BLAKE3 can be additionally applied as needed. This multi-hash structure provides crypto-agility that enables the reliability of the entire identification system to be maintained even in the event of an attack or vulnerability to a specific algorithm.

[0557] Each hash result can be maintained as an individual field or managed as a combined structure, and applied algorithm information (alg_id), output length, and policy information can be recorded together as metadata.

[0558] When a block-unit identification value is generated, aggregation using a tree structure can be performed based on it. In one embodiment, the aggregation structure can be implemented as a Merkle Tree or a hash tree structure equivalent thereto.

[0559] Specifically, block hash values ​​are combined in pairs to generate a higher hash, and this process is repeated to finally generate a root hash (root identifier). The root hash can be used as a final identifier representing the entire input data set.

[0560] By applying a Merkle Tree structure, not only can the integrity of the entire data be efficiently verified, but performance can also be optimized by re-verifying only the path to a specific block when a change occurs. Furthermore, it can be configured to enable proof-based verification even in external verification environments.

[0561] In the above identification value generation process, information regarding the execution environment, in addition to the input data itself, may be processed separately to generate an environment hash. This environment information may include the operating system, runtime, library version, container image, hardware or virtualization environment, and deployment unit information, and can be normalized, hashed, and combined into the identification value structure.

[0562] In addition, time information regarding the time of identification value generation may be combined, and if necessary, a time token generated through a Timestamp Authority (TSA) may be included. The aforementioned time information functions as a factor proving that the identification value was generated at a specific point in time and serves as an important criterion in subsequent verification and auditing processes.

[0563] Finally, the above-mentioned identifier generation component can generate a structured identifier package by combining a block identifier, a root identifier, an environment hash, time information, and related metadata.

[0564] The above-mentioned identification value package is not a single hash value but consists of a data set containing multi-layered verification information, and may include a function block identifier, version information, normalization profile identifier, hash algorithm information, policy identifier, and execution context information. If necessary, the package may be protected by a digital signature or a message authentication code, and is subsequently transmitted to an independent verification server to be used as input for integrity verification.

[0565] The identification value generation and normalization steps configured in this manner are core procedures that transform the execution state into a form comparable to a reference state, and play a role in ensuring the reliability and comparative accuracy of input data in the integrity verification structure of the present invention.

[0566]

[0567] 2.7 Integrity Verification Mechanism

[0568] In one embodiment, the integrity verification mechanism may be performed as a core procedure to determine whether integrity is maintained at the functional block level by comparing a reference identifier generated from a reference state with a runtime identifier generated from an operating state. The integrity verification may not be limited to simple value comparison but may be composed of a multi-layered structure including reference version selection, determination of identifier consistency, determination of metadata consistency, analysis of partial inconsistency locations, determination of the combination of static and dynamic identifiers, state classification, and determination of policy linkage. It is preferable that such verification be designed to be performed in a verification area that is logically, functionally, and operationally independent from the authentication and operation areas.

[0569] Before the above integrity verification is performed, the independent verification server may first select a reference version of the reference identifier to be compared with the execution identifier. If multiple reference states exist, first, if a reference version explicitly specified at the time of execution or in the request context exists, that version may be applied first. Second, if there is no explicit specification, the reference version that is active at the time of execution may be applied. Third, if multiple reference versions satisfy the above conditions, the reference version with the most recent approval time may be applied. If no selectable reference state exists according to the above priorities, the corresponding function block may be classified as a state without a reference, and the verification engine may determine this as a divergence or unverifiable state rather than a normal state. This reference version selection logic functions not as a simple query procedure, but as a step that establishes the preconditions for verification.

[0570] In one embodiment, the integrity verification engine may process the comparison of a reference identifier and an execution identifier, the determination of metadata consistency, and the structuring of results in the form of verification input and result objects. For example, a verification object may include a function block identifier (function_block_id), an applicable reference version (reference_version), a reference identifier (reference_identifier), a execution identifier (runtime_identifier), a comparison strategy (matching_context), metadata verification conditions (metadata_verification), and a final verification result (verification_result). In particular, the matching_context may include fields such as matching_strategy, comparison_type, reference_version_selector, and fallback_policy, and the metadata_verification may include reference metadata (reference_metadata), execution metadata (runtime_metadata), strict comparison fields (strict_fields), and flexible comparison fields (flexible_fields). The verification_result may have the identifier_match_result, metadata_match_result, final_result, severity_level, and comparison_timestamp structured and recorded. This object structure is an important means of enhancing feasibility in that it represents verification logic in a software-reproducible state.

[0571] For example, the above verification object may be defined such that the reference version v3.2.1 is selected for a specific function block RNG_CORE_1, both the reference identifier and the execution identifier use SHA-256 and the same norm_profile_id, the comparison strategy is exact_match, the reference version selection method is latest_active, and the policy for the absence of a reference is mark_divergence_if_no_reference. Additionally, the reference metadata may include policy_id, build_config_id, and deterministic_flag, and the execution metadata may include policy_id, build_config_id, and execution_context. In this case, policy_id and build_config_id may be treated as strict fields, and execution_context as a flexible field. Finally, identifier_match_result may be recorded as exact_match, metadata_match_result as valid, final_result as PASS, and severity_level as LOW. Beyond being a simple example, this object serves as a technical disclosure that clearly demonstrates the data model by which the actual verification module operates internally.

[0572] In one embodiment, the integrity verification may be performed in the order of at least a first comparison step, a second comparison step, and a third comparison step. In the first comparison step, it is determined whether the reference identification value and the execution identification value match at the entire unit of the function block. The first comparison step is the most basic integrity verification step and is configured to check whether the reference identification value and the execution identification value generated for the same function block match completely. If a match is confirmed in the first comparison step, the function block may be determined to satisfy at least a basic level of identification value integrity. Here, "complete match" refers not only to a match of simple hash strings but also to a match under the premise that the same generation rule, the same normalization rule, and the same comparison standard have been applied.

[0573] In the second comparison step, if a discrepancy occurs in the first comparison step, the location of the difference is identified using sub-component unit identifiers, partial identifiers, or Merkle Tree-based partial identifiers within the function block. Accordingly, even if a discrepancy occurs at the level of the entire function block, it is possible to identify in detail where within the function block the discrepancy occurred—for example, in a specific submodule, a specific configuration object, or a specific execution unit. The second comparison step can be utilized as a technical basis for analyzing the scope of impact, determining the response level, or deciding whether to apply limited mitigation measures in the subsequent policy-based response step. In particular, when combined with the block hash and Merkle Tree structure defined in 2.3.5, the difference section can be locally identified through a proof path even if the entire hash is inconsistent.

[0574] In the third comparison step, the consistency of execution environment information, policy identifiers, version information, normalization profiles, algorithm identifiers, and other metadata is determined separately from the comparison of identification values. Accordingly, even if identification value matching is confirmed in the first or second comparison step, if the essential metadata fails to meet the criteria in the third comparison step, the final result may be determined as a divergence state rather than a normal state. For example, even if the code itself is identical, if it is executed under an unauthenticated execution environment, an unauthorized policy version, or inconsistent configuration conditions, the state may be determined as an integrity deviation because the execution context differs from the standard state. Through this structure, the present invention goes beyond the simple model of "code identity = normal state" and provides a high-reliability verification structure in which the code and the execution context must be consistent together to be determined as normal.

[0575] In one embodiment, when the execution identifier includes a static identifier and a dynamic identifier, the independent verification server may perform individual comparisons and combined judgments for each identifier. For example, if both the static identifier and the dynamic identifier match the reference identifier, the system may be determined to be in a normal state. Conversely, if the static identifier matches the reference identifier but the dynamic identifier does not, it may be determined that tampering, abnormal behavior, or unauthorized state changes have occurred in the execution state. In another case, if the static identifier itself does not match the reference identifier, it may be determined that there is a high probability that integrity was compromised prior to execution or during the deployment phase. Such a combined judgment structure enables the identification of tampering in the execution state that would not be detected by a verification method using only static identifiers.

[0576] Furthermore, the present invention may include a similarity-based comparison as an exceptional or supplementary judgment means. Basic integrity verification is performed based on a comparison of identity between a reference identifier and an execution identifier, and the similarity-based comparison may be applied auxiliaryly as an optional extension embodiment within a predefined allowable range. For example, if the value of a specific metadata field has changed but that field is not a critical element for integrity judgment, it may be classified as a flexible field, and a comparison of the remaining critical elements may be performed first. Such similarity judgment may be implemented through inclusion / exclusion items defined in normalization rules, tolerance ranges, policy-based exception rules, or weight-based evaluation models. However, the similarity-based comparison should be understood not as a replacement for the basic identity judgment, but as an auxiliary judgment means applied restrictively only to non-critical representation differences or policy-allowed variation elements.

[0577] Integrity determination is not limited to simple binary results but can be expressed as a result including multiple severity levels. For example, complete match can be classified as a normal state, differences in some non-critical elements can be classified as a low-level warning, and code inconsistencies in core function blocks, policy inconsistencies, or abnormal changes in dynamic execution states can be classified as a high-level threat. Accordingly, the final verification result can be structured into a status value of PASS, WARNING, DIVERGENCE, CRITICAL, or equivalent, and the status classification can be used as a criterion for determining the response level in subsequent policy judgment and control execution stages.

[0578] In one embodiment, the integrity verification result may not be limited to a simple comparison result but may be generated as a structured verification state object that can be used as input for a subsequent policy judgment step. The verification state object may include at least a function block identifier, an applied reference version, an identification value comparison result, a metadata consistency result, a severity level, an applied comparison rule, a comparison time, and judgment basis information. A policy-based judgment structure can determine the response level by using the verification state object as a direct input. This significantly enhances the feasibility of system implementation by clearly defining the interface between the verification engine and the policy engine.

[0579] In embodiments where high reliability is particularly required or where it is necessary to verify the origin legitimacy of the execution result, the integrity verification mechanism may be optionally extended and configured to perform execution authenticity verification. This additional verification is an optional higher-level verification step distinct from the basic integrity verification that determines the identity of function block unit identifiers and metadata consistency, and uses collected execution context information, execution token-related information, call flow information, result binding information, and approved module chain information as inputs.

[0580] In one embodiment, the additional verification may be performed in a fourth comparison step. In the fourth comparison step, for a specific function block or result unit, in addition to the comparison result between the execution identifier and metadata, it is determined whether the execution was performed in accordance with an approved procedure. To this end, the verification engine may comprehensively analyze at least the existence and validity of the execution token, the consistency of the call order between function blocks, the continuity of the approved module chain, and the binding relationship between the result value and the execution path.

[0581] For example, if an execution token is missing or used outside of an allowed valid range, if an execution path is identified that does not pass through a required preceding function block, if result binding information is not associated with an authorized session or request flow, or if a call flow discontinuous with an authorized module chain is detected, the validation engine may determine that the result was generated from an unauthorized execution procedure. Accordingly, even when the reference identifier and the execution identifier match, it is possible to distinguish cases where the actual result was generated by an unauthorized execution path, result attribution mismatch, or shadow execution.

[0582] That is, even if it can be judged as PASS in the first to third comparison steps, if execution token consistency, call flow consistency, approved module chain consistency, or result binding consistency is not satisfied in the fourth comparison step, the final result may be reclassified as an execution source mismatch state rather than a normal state. Accordingly, the present invention provides a structure capable of verifying not only code integrity but also the legitimacy of attribution of the execution result. The execution result source consistency verification result may be structured into items such as execution_authenticity_result, flow_verification_result, token_verification_result, binding_verification_result, approved_chain_verification_result, and authenticity_severity. For example, execution_authenticity_result may be expressed as one of VALID, SUSPICIOUS, or INVALID, and token_verification_result may indicate one of PRESENT, MISSING, REUSED, or EXPIRED states. Additionally, flow_verification_result can be expressed in forms such as APPROVED_PATH, UNKNOWN_PATH, BYPASSED_STEP, etc., and binding_verification_result can be expressed in forms such as BOUND, UNBOUND, MISMATCHED, etc. approved_chain_verification_result can be expressed in forms such as CHAIN_VALID, CHAIN_BROKEN, CHAIN_UNKNOWN, etc., and these result objects can be used as input along with existing integrity verification results in a subsequent policy-based decision step.

[0583] According to the embodiment, an independent judgment grade regarding execution authenticity may be assigned in parallel with existing integrity results, and a composite state may be allowed where code integrity is PASS but execution result source consistency is judged as SUSPICIOUS or INVALID. This is intended to separately identify high-risk states such as "the code is normal, but the execution path or result attribution is abnormal." Additionally, the execution authenticity verification rule set may be managed separately from the basic identifier comparison rule set and may include whether a token is required, a list of required prerequisite steps, a definition of an approved module chain, required fields for result binding, and shadow execution judgment conditions.

[0584] In this invention, to further ensure the reliability of the verification results, integrity verification of the verification process itself may be performed. For example, identification values ​​for the code or configuration values ​​of a verification module may be managed separately, and it may be verified whether the module is operating in a normal state. If necessary, a method of operating multiple independent verification modules in parallel and cross-verifying their results may also be applied. This structure contributes to maintaining the reliability of the entire system even when the verification area itself becomes a target of attack.

[0585] In addition, in the present invention, verification of multiple functional blocks can be performed in parallel to ensure verification performance, and each verification result can be managed based on an independent identifier. Results generated during the parallel verification process can be sorted according to chronological order and identifiers and transmitted to a policy judgment stage; if multiple results exist for the same functional block, the most recent result or a priority criterion defined by the policy can be selected. In an embodiment where execution authenticity verification is enabled, verification objects at the result level and verification objects at the functional block level can be managed in conjunction with each other, and a collective judgment on the entire functional block chain corresponding to a specific result can be additionally performed.

[0586] However, execution token verification, determination of call flow consistency, result binding verification, verification of authorized module chains, and shadow execution detection are not necessarily required in all embodiments and may be omitted in systems where comparison of identification values ​​at the functional block level and determination of metadata consistency are sufficient. That is, the above additional verification structure should be understood as an extended verification mode that is selectively applied in environments where legal evidentiary value is particularly required, such as public, financial, medical, defense, high-risk AI, security control, or other sectors, and should not be interpreted as an essential component that limits the basic integrity verification mechanism of the present invention.

[0587] However, the verification of source consistency of the above execution results should be understood as an extended verification mode that can be additionally combined with the basic integrity verification structure of the present invention, which centers on the comparison of identification values ​​at the functional block level and the determination of metadata consistency, and should not be interpreted as a configuration that is essential in all embodiments.

[0588] The integrity verification results performed in this manner can be generated as structured judgment results that include not only whether there is a match between the reference state and the execution state, but also the consistency of the execution environment, the integrity of the dynamic execution state, the origin legitimacy of the execution result, and the results of applying verification rules, and are subsequently transmitted to the policy-based judgment and response stage. Accordingly, the present invention enables substantive integrity judgment of the operating state and high-reliability execution result verification, going beyond simple code identity verification. FIG. 11 can be understood as an exemplary diagram illustrating the flow of generating execution identifiers in functional block units, comparing reference identifiers, policy-based response, and immutable repository recording.

[0589] However, the integrity verification mechanism in this section is intended to explain the verification procedure between the reference state and the execution state and the structuring of the results thereof; the step of converting the verification results into policy conclusions can be performed in the policy-based judgment structure described later, and the step of executing them as actual control commands can be performed in the control execution structure described later.

[0590] 2.8 Policy-Based Decision Mechanism

[0591] In one embodiment, the policy-based decision structure may be executed as a decision procedure that receives a verification state object generated by an integrity verification mechanism, an execution authenticity result object, and related execution context information as input, and determines whether a response is necessary, the priority of the response, and the method of the response according to predefined policy rules. The policy-based decision structure may be executed in a policy-based response engine within an independent verification server and may operate in conjunction with a separate policy engine or rule engine as needed. That is, the policy-based decision structure in this section relates to a decision layer that interprets verification results to derive policy conclusions, and the step of executing the policy conclusions as actual system control operations is distinguished from the control execution structure described later.

[0592] The purpose of the above policy-based judgment structure is not merely to link fixed measures to verification results, but to derive policy conclusions appropriate to the situation by comprehensively considering the type of verification result, severity, importance of the functional block, scope of impact on the service or system, nature of the user or session, sensitivity of the execution environment, and regulatory requirements. Accordingly, even for the same divergence state, different conclusions may be derived depending on which functional block it occurred in, which consistency conditions were violated, and whether violations of execution result source consistency were combined.

[0593] In one embodiment, the policy-based decision may be performed in the order of an input reception and object interpretation step, a policy search and application target determination step, a rule matching step, a severity and priority evaluation step, an exception condition and conditional mitigation judgment step, and a final policy conclusion generation step. The steps may be performed sequentially, and depending on system requirements, some steps may be performed in parallel or evaluated competitively against multiple sets of rules.

[0594] In the input reception and object resolution step described above, the policy engine may receive a verification status object including at least a function block identifier, an applied reference version, an identifier comparison result, a metadata consistency result, a severity level, an applied comparison rule, and a verification time. Depending on the embodiment, if execution authenticity verification is enabled, execution_authenticity_result, flow_verification_result, token_verification_result, binding_verification_result, or equivalent extended result objects may be transmitted together. The policy engine may resolve these objects to determine whether there is a basic integrity violation, an execution result source violation, or a composite state combining both.

[0595] In the above policy search and application target determination step, the policy engine can identify applicable policy sets based on function block identifiers, service identifiers, system domains, execution environment identifiers, user groups, session attributes, risk levels, policy identifiers, reference versions, or execution contexts. For example, even with the same identifier mismatch, different policy sets may be applied depending on whether it is a core function block, a non-core function block, a high-trust environment, or a general operating environment.

[0596] In the aforementioned rule matching and severity assessment phase, the policy engine compares the validation state object and the extension result object with a predefined set of rules to determine the risk level, policy priority, and applicability for the corresponding situation. During this process, if a specific result is absolutely not permitted under the policy, it may be immediately classified as a high risk level, while some results may be subject to mitigation judgment based on exception rules, allowance ranges, or conditional approval rules.

[0597] In the aforementioned exception conditions and conditional mitigation judgment stages, if conditions such as a soft mismatch regarding non-core function blocks, policy-allowed environmental differences, approved alternative configurations, or limited scope of execution flow differences exist, the status may be reclassified to a warning, additional verification required, or restricted allowance status according to predefined allowance rules. However, a hard mismatch regarding core function blocks, a material violation of execution result origin consistency, or a violation of policy mandatory conditions may, in principle, be excluded from mitigation.

[0598] Finally, the above policy-based decision structure can generate policy conclusions such as maintaining normality, issuing a warning, requiring additional verification, allowing with restrictions, requiring blocking, requiring isolation, or requiring administrator approval; these conclusions can subsequently be connected to actual response procedures by the Policy-Based Response Module (PB-RM) and the Real-Time Control Agent (RCA). In other words, the policy-based decision structure in this section is a step for deriving policy conclusions regarding "what to do," while the policy-based response module and control structure described later can be distinguished as steps for executing these policy conclusions into actual control and response procedures.

[0599] In addition, the above policy-based judgment result can be generated as a structured judgment object including functional block identification information, verification status summary, applied policy rules, risk level, whether exceptions are applied, and final policy conclusion information, and said object can subsequently be recorded as a component of a digital integrity report or utilized as input for audit and external verification procedures.

[0600] The policy-based judgment structure configured in this way functions as a core policy conclusion layer that enables subsequent policy-based response structures to operate in a reproducible and consistent manner by transforming integrity verification results from simple status indications into judgment conclusions that reflect function block importance, execution environment, regulatory requirements, and policy priorities.

[0601]

[0602] 2.9 Control Execution Model

[0603] In one embodiment, the control execution structure may be performed as a procedure to receive a policy decision object or a response directive generated from a policy-based decision structure as input, convert it into an actual system-level control action, and apply it. The control execution structure may be performed by a policy-based response module (PB-RM), a response execution engine, a runtime control agent (RCA), or an equivalent control entity, and may function as a closed-loop control layer that goes beyond merely recording verification results to actively modifying and stabilizing the system's execution state. That is, the control execution structure in this section relates to an execution layer that converts policy decision results into actual control actions, and the determination of the verification result itself or the derivation of policy conclusions may be performed by an integrity verification mechanism and a policy-based decision structure, respectively.

[0604] The above control execution structure may generally consist of a response instruction reception step, a control command generation step, a control target identification step, an execution path determination step, a control command transmission and application step, an execution result verification step, and a re-verification request or status feedback step. These steps may be performed sequentially, and in some cases, may be performed in combination with parallel control or multi-stage approval procedures.

[0605] First, in the response instruction reception stage, the response execution layer may receive a final policy decision object from the policy engine. The policy decision object may include at least a function block identifier, a service identifier, a final severity level, whether a response is required, a response priority, a recommended response type, whether immediate execution is required, whether manual approval is required, whether additional verification is required, and the basis for the decision. Additionally, in an embodiment where execution authenticity extended verification is enabled, result attribution discrepancies, execution token errors, broken authorized module chains, or suspicion of shadow execution may be included as separate authenticity decision fields.

[0606] The response execution layer described above can interpret the policy judgment object and convert it into a specific control command. In this case, the control command may be defined not as a simple text instruction, but as a structured command object that includes the control target, control scope, control method, execution time, duration, return condition, re-verification condition, and reporting method. For example, the control command may include the immediate deactivation of a specific function block, termination of a specific session, restriction of access for a specific user group, switching a specific module to an alternate mode, switching a specific service to read-only mode, activation of an additional verification mode, or entry into a state waiting for administrator approval.

[0607] During the aforementioned control command generation process, the identification of the control target can be performed simultaneously. That is, it is possible to first distinguish whether the policy judgment result requires control over the entire system, local control over a specific function block, or fine-grained control over a specific user session or transaction. For example, an integrity deviation in a core payment module may lead to control that immediately blocks the corresponding function block or related service chain, whereas a metadata inconsistency in a non-core log module may remain at the level of notifications and requests for additional verification. Furthermore, if a result source consistency violation is limited to a specific session, the scope of control can be restricted to isolation measures for that specific session or request unit, rather than a complete service interruption.

[0608] In the control path determination step, it is possible to select through which interface the control command will be transmitted to and applied to the target system. For example, an appropriate path may be selected from among API call methods, message queue or event bus-based methods, policy engine linkage methods, system command execution methods, network control methods, or configuration interface-based methods. This selection may vary depending on the structure of the target system, real-time requirements, the risk level of the control, and operational policies. For example, if real-time blocking is required, a direct control API with low latency may be applied first, while if operational stability is more critical, an indirect control method via a safety switching protocol may be selected.

[0609] Furthermore, the control execution structure can distinguish between automatic and approval-based execution paths depending on the nature of the control command. That is, low- or medium-level responses can be executed automatically by the policy engine, whereas high-impact measures—such as total system shutdown, complete service blocking, blocking accompanied by external disclosure, or notification to regulatory authorities—can be configured to be executed through an administrator or a dual approval structure. This approval-based execution structure is intended to ensure operational control over high-risk controls while maintaining the automation of policies.

[0610] In one embodiment, a Real-time Control Agent (RCA) may be configured as an execution entity that converts the control command into actual system behavior and applies it. The RCA may be deployed within the target system or in an adjacent execution environment and may perform control through API calls, command execution interfaces, configuration change interfaces, access control policy interfaces, routing control interfaces, or service mesh-based control interfaces. For example, it may apply a policy to block calls to disable a specific function block, call a session management interface to terminate a specific session, or change routing settings to bypass a specific service path.

[0611] The above RCA can be designed to perform control at the functional block level, module level, service level, session level, user level, or system-wide level. In particular, since the present invention is based on a functional block-level identification and verification structure, it is desirable that control can also be applied finely at the same level. For example, it can be configured to enable local control that isolates only the problematic functional block without interrupting the entire system, blocks only the path for generating specific results, or stops only specific unauthorized execution flows. This is advantageous for suppressing the spread of risk while maintaining service continuity as much as possible.

[0612] In addition, control commands can be applied hierarchically based on the response intensity. For example, it can be configured to generate only a warning as a Level 1 response, activate an additional verification mode or high-sensitivity monitoring mode as a Level 2 response, perform function restriction or session isolation as a Level 3 response, and perform a full block or switch to safe mode as a Level 4 response. This hierarchical response structure can operate in conjunction with the policy engine's severity classification, and the response level can be progressively raised if the same type of deviation is repeated or additional authenticity violations are detected.

[0613] When the above control command is actually applied, a step to verify the control execution result may be performed. In this step, it can be verified whether the target system has successfully received the command, whether the command has actually been applied, and whether the state after application reflects the expected changes. For example, if a command to disable a function block is issued, it can be verified whether the call to that function block has actually been blocked; if a command to terminate a session is issued, whether the session state has transitioned to terminated; and if a command to switch to safe mode is issued, whether the system settings have changed to that mode.

[0614] Such result verification is not limited to a simple acknowledgment but can be performed by collecting and verifying the state itself after execution. That is, RIMA or a collector can collect the system state after control, generate execution identifiers and metadata regarding it, and transmit them to a verification server. Through this, it is possible to determine whether the policy-based response actually produced the intended effect or whether the same deviation state persists even after control. This structure is important in that the control execution of the present invention does not remain a one-time measure but forms a closed-loop structure in which the response results are also included in the verification flow.

[0615] Depending on the embodiment, the control execution result may be structured into a status value such as success, partial success, failure, pending, or rejected. For example, if only a portion of the control commands for a multi-functional block are successfully applied, it may be classified as partial success, and if the target system receives the command but immediate application is delayed by an operational policy, it may be classified as pending. The result may subsequently be used as input for report generation, audit logs, and additional policy judgments.

[0616] Additionally, the control execution structure described above may include supplementary logic for failure or partial success situations. For example, if a primary control command fails, an alternative control path may be attempted, or for high-risk events, a stronger blocking policy may be applied. Conversely, if excessive blocking has a significant impact on service continuity, a fallback policy may be applied to switch to a restricted operation mode that maintains only specific functions. Such supplementary logic may be executed in conjunction with a policy engine according to a predefined escalation rule or fallback rule.

[0617] The above control execution structure can support both manual approval-based responses requiring human intervention and fully automated responses. For example, in high-impact environments such as critical national infrastructure, financial payment systems, or medical AI decision systems, certain response commands may be configured to execute only after obtaining approval from an administrator, auditor, or through a dual approval process. In this case, the policy engine can generate a "manual approval required" status instead of immediate execution and provide the decision-maker with the rationale and recommended actions through an approval interface. Conversely, pre-defined low-risk or medium-risk responses can be executed immediately by an automated mitigation module.

[0618] In addition, the control execution structure of the present invention does not refer only to external control but may also include internal verification enhancement measures. For example, if a minor deviation is detected in a specific function block, "verification enhancement control" may be performed by shortening the collection cycle for the function block, applying a normalization profile more strictly, or enabling execution authenticity verification, instead of immediate blocking. Such control can function as a means to dynamically increase the level of trust while maintaining system availability.

[0619] Simultaneously with the execution of a control, the control command and execution results can be recorded in digital integrity reports and audit structures. For example, a single response execution record can be generated detailing which policy rules were applied, which response was selected at what severity level, what the control target was, what the actual control result was, and what the re-verification result was after the control. This record can be stored along with a digital signature, timestamp, policy version identifier, executor or approver identifier, and a reference to a related verification state object. This allows the response process itself to be the subject of post-audit and legal evidence.

[0620] Depending on the embodiment, the control execution result may also be linked to a public verification structure. For example, if a deviation or response exceeding a certain level occurs, the system status change may be provided to external users or regulatory agencies through a public interface. Additionally, the system status may be displayed as "Normal," "Warning," "Isolation," "Safe Mode," etc., via LEDs, electronic display boards, public announcement systems, or multi-channel public interfaces. Such a structure has the effect of enabling direct external verification of not only the verification results but also the response results.

[0621] An important feature of the above-described control execution structure is that the verification result does not end as a simple report but changes the actual system state, and that changed state becomes the subject of verification again. In other words, by forming a self-feedback structure that follows the sequence of "Verification -> Judgment -> Control -> Re-verification -> Record," the present invention enables the reliability of a digital system during execution to be maintained not through one-off judgments, but from the perspective of continuous control and evidence.

[0622] Consequently, the control execution structure described above functions as a core execution layer that converts policy-based judgment results into actual system-level behavioral changes and connects those results back to a verification and logging structure. Through this, the present invention goes beyond a simple detection-based integrity verification system and can provide an active operational trust infrastructure that substantially controls deviations during execution and maintains a state of trust.

[0623] 2.10 Execution Authenticity Verification Structure

[0624] In one embodiment, the execution result source verification structure may be performed as a higher-level verification structure to additionally verify whether the actual operation result was generated from the normal execution process of an authenticated function block, even if the integrity of the function block itself is determined to be normal. The purpose of the structure is not merely to verify the identity of an executable file or memory state, but to determine through which execution path specific result data was generated, whether an authenticated function block was actually involved at the time of result generation, and whether the result data is structurally coupled with the authenticated execution flow and verification procedure. Accordingly, the present invention includes a basic structure that verifies the integrity of code, settings, or execution states through the comparison of identification values ​​at the function block level, and, if necessary, may further include an additional layer to verify the source legitimacy of the execution result itself, either separately from or in addition to the basic integrity verification.

[0625] Generally, if the reference identifier and the execution identifier match, the corresponding function block can be determined to maintain an authenticated state. However, in actual operating environments, there may be cases where, even though an authenticated function block A is successfully loaded and passes integrity verification, the actual business processing or result generation is configured to be performed by a separate unauthorized function block A' or a bypass execution path. For example, while an authenticated random number generation module is successfully loaded and reports a normal status to the verification server, the actual lottery result or game result may be generated by a separate unauthorized random number generation module or a tampered result generation module. In such cases, it is difficult to determine the source of the actual result solely through simple code integrity comparison or static identifier comparison. Therefore, it is desirable for the present invention to go beyond a structure that verifies the existence or loading status of a function block and to provide an additional source verification layer that directly combines the execution result with the authenticated execution path for verification.

[0626] In one embodiment, the execution result source verification structure may include at least one of an execution token-based verification structure, an execution flow identification structure, a result binding structure, a recurrence verification structure, and an approved execution enforcement structure, and these may operate alone or in combination. From a more generalized perspective, the structure may be understood as an independent technical structure comprising at least (a) an execution token-based verification structure, (b) an execution flow identification structure (call flow verification), (c) a result binding structure, and (d) an approved module chain verification structure. Each of the above components performs a complementary role to verify from various angles whether a specific result was generated from the normal execution process of an authenticated function block.

[0627] First, the execution token issuance structure can function as a means to strongly couple the execution of a specific function block and its execution results to an external verification structure. In one embodiment, a verification server or an independent verification entity may generate an execution token corresponding to a specific execution point, a specific session, or a specific request unit of the function block. The execution token may include at least a function block identifier, a session identifier, a request identifier, a creation time, a valid time range, and a random number value or nonce, and may include the verification server's digital signature or message authentication value as needed. The execution token is delivered to the corresponding function block, and the function block may be configured to combine the execution token or a verification value derived from the token with the result data and output it when generating result data. Accordingly, the execution result is structured not as a simple output value, but as result data combined with a specific verification session and a specific execution context.

[0628] It is desirable that the aforementioned execution token be configured to be dependent on a specific function block, a specific point in time, and a specific execution context. Accordingly, this prevents the reuse of the same result value in different function blocks or different sessions, and allows results generated based on tokens that have already been used or have expired to be classified as invalid. Furthermore, if the token itself is protected by a digital signature or MAC, it can be structurally made difficult for unauthorized programs to generate results by reusing past tokens or inserting forged tokens. Accordingly, this structure provides a technical basis for determining whether a specific result is associated with a specific authentication execution instance, rather than merely the fact that "a legitimate module existed."

[0629] Next, the execution flow identification structure can function as a structure for verifying the call flow, processing order, and path consistency until a specific result is generated. In one embodiment, the execution process of a function block is not limited to a simple single function call, but can be expressed as a series of call flows or process flows extending to input reception, preprocessing, core operations, postprocessing, and result output. In the execution flow identification structure, execution flow metadata may be generated that includes the call order of each step, the identifier of the called function or module, reference information of the input data, reference information of the intermediate output, whether a policy is applied, and whether an external call is made; said metadata may be converted into a hash value or an equivalent identifier and managed as an execution flow identifier.

[0630] The above execution flow identifier can be compared with a reference execution flow identifier corresponding to a pre-authenticated normal execution path. For example, if the normal execution path of a specific random number generation function block is defined in the order of "input reception -> seed verification -> call authenticated RNG module -> result generation -> result signing -> external output," the execution flow identifier will not match the reference execution flow identifier if the actual execution path calls an unauthorized module in an intermediate step or includes an unapproved post-processing step. By using the above execution flow identifier structure, it is possible to verify whether the entire actual result generation path follows the authenticated structure, rather than simply whether the authenticated function block is loaded.

[0631] The result binding structure is a structure designed to combine the execution result itself with an authenticated execution process. In one embodiment, when generating result data, a function block may generate result binding data by combining one or more of an execution token, a function block identifier, an execution flow identifier, a session identifier, a request identifier, an execution time, and optionally an input data identifier or an intermediate state identifier with the result data. The result binding data may be transmitted together with the result value, included in the input for the hash calculation of the result value, or included as separate data to be signed. Accordingly, a verification server or an external auditing entity can determine whether a specific result value was actually generated by combining it with an authenticated function block, a specific execution time, a specific execution flow, and a specific request. This should be understood as a structure that inseparably binds the result value and the generation procedure, going beyond a simple structure where "only the result value needs to be correct."

[0632] In one embodiment, the result binding data may be combined with the result data in a manner inseparable. For example, a method may be used in which a result value is concatenated with an execution token, a function block identifier, an execution flow identifier, and a session identifier, a hash is generated, and a digital signature is performed on the hash value. Alternatively, a message authentication code may be generated for the result value itself, but the reproduction of the result without the token may be prevented by reflecting the execution token in the key or input value of the message authentication code. Through such a structure, even if the result value is forged independently or reproduced in the same format by another module, the result may be determined to be invalid if it fails to simultaneously satisfy the verification value combined with the authenticated execution process. In other words, the structure provides a technical criterion that does not recognize a result as valid if the source binding relationship is broken, even if the external appearance of the result is similar.

[0633] Additionally, the reproducibility verification structure may include an auxiliary verification structure to determine whether a specific result is reproducible in light of input and execution conditions. For certain functional blocks, such as rule-based processing modules, deterministic computation modules, or judgment modules that produce the same result when inputs and states are fixed, results may be regenerated or recalculations for verification may be performed if the same input data, the same initial state, the same policy version, and the same environmental conditions are provided. In such cases, a verification server or an external verification entity may recalculate or partially reproduce the result using the input reference value, policy identifier, environment identifier, and execution flow identifier at the time of result generation, and compare it with the actual reported result. If the comparison results do not match, the result may not be recognized as a result generated from an authenticated functional block.

[0634] In particular, even in the case of functional blocks that include outwardly non-deterministic elements, such as random number generation, a reproduction verification structure is not completely excluded. In this case, the present invention is not limited to absolutely reproducing the random number result itself, but is configured to verify whether the result was produced during a legitimate calling process of an authenticated module through at least the authorized module identifier used for random number generation, the verification token at the time of the call, the source information of the authorized seed source, the number of calls or state transition counters, result binding data, and signature information. That is, even in cases where it is difficult to completely reproduce the result value itself, it is possible to detect whether the result was generated by an unauthorized module by verifying the procedural legitimacy and source consistency of the result generation.

[0635] An authorized execution enforcement structure may include a structure for blocking or restricting the execution of unauthorized function blocks or unauthorized libraries. In one embodiment, the operating system is configured so that only pre-authorized execution modules can be executed, and unauthorized executable files, libraries, scripts, or runtime loading modules may be blocked from execution or loading. Such execution enforcement may be performed through a signature-based allowlist, a process whitelist, loader-level verification, container image integrity verification, a read-only file system, execution control based on an authorized image digest, or a trusted execution environment. Accordingly, structures that execute an unauthorized function block A' in parallel with an authorized function block A, or use the results of an unauthorized module for actual business processing by bypassing the results of a legitimate module, can be suppressed at the operating environment level. This structure can function as a proactive enforcement layer that complements the detection layer of execution result source verification.

[0636] In this embodiment, the execution result source verification structure can be closely linked with a policy-based judgment structure. For example, if the identifier of the function block itself is verified as normal, but the execution flow identifier does not match the reference path, result binding verification fails, an execution token is missing, or an approved module chain is not verified, the policy-based judgment structure may classify this as an execution authenticity divergence, which is a type distinct from a simple code integrity deviation. In this case, the response level may be determined as one or more of a general warning, function restriction, result discarding, session termination, alternative module switching, or entry into a safe state, and the judgment criteria may be applied differentially based on the importance of the function block, the legal or financial impact of the result data, the frequency of occurrence, and the operating environment.

[0637] In particular, even if the execution identifier matches the reference identifier, if the execution result source verification structure determines that the result does not follow an approved execution procedure or an authenticated functional blockchain, the result may be determined to be in an execution source mismatch state rather than a normal state. Accordingly, the present invention can determine the integrity of the code itself and the legitimacy of the result's source at distinct verification levels, and can allow for a composite state where code integrity is PASS but result source consistency is determined as SUSPICIOUS or INVALID. This composite state structure is very important in high-trust systems. This is because, even if seemingly normal code exists, a situation where the actual business result is generated through an unauthorized path can be substantially more dangerous.

[0638] Furthermore, token verification results, execution flow identifiers, result binding verification results, approved module chain verification results, and related exception information generated during the aforementioned execution result source verification process may be included and recorded in the digital report. Accordingly, external auditing bodies or regulatory authorities can retrospectively review not only whether the functional block was in an integrity state, but also whether the actual result was generated from an authenticated execution structure. Combined with the chain of custody structure, this information enables the long-term traceability of the source, procedure, timing, and reliability of result generation. Consequently, the structure described in this section serves to enhance legal evidentiary value and regulatory compliance capabilities, going beyond simple technical verification functions.

[0639] However, the above-mentioned execution result source verification structure is not mandatory in all embodiments and may be omitted in systems where comparison of identification values ​​at the functional block level and determination of metadata consistency are sufficient. That is, it is preferable to understand the above structure as an optional extension embodiment that complements the functional block-level integrity verification structure, and it may be optionally activated in environments where legal evidentiary value is particularly required, such as public, financial, medical, defense, high-risk AI, security control, or other sectors. In this case, the legitimacy of the result source can be additionally determined using the execution token, execution flow information, result binding information, and approved module chain verification information.

[0640] Consequently, the execution result source verification structure according to the present invention is configured as an optional extension embodiment that complements the basic functional block unit integrity verification structure, enabling additional verification of the legitimacy of the generation path of actual business results or service results beyond the simple existence or loading state of an authenticated functional block. Through this, it is possible to effectively detect and block evasion attacks in the form of shadow execution, bypass execution, or dual-path execution, which cause the actual result to be generated by an unauthorized program A' while maintaining the appearance of an authenticated program A.

[0641] This extension structure is not an essential component of the present invention and corresponds to an embodiment that is optionally applied in a specific high-trust environment. In this case, the legitimacy of the result source can be additionally determined using the execution token, execution flow information, result binding information, and approved module chain verification information.

[0642] 2.11 Digital Report Structure (Digital Integrity Report)

[0643] In one embodiment, the Digital Integrity Report according to the present invention may be configured to function as an information representation layer that integrates integrity verification results, policy-based judgment results, and control execution results into a structured form, and provides for subsequent auditing, tracing, and external verification. The Digital Integrity Report is not limited to a simple set of logs or operational records, but may be composed of an evidentiary data object that combines the system state at a specific point in time, verification judgments regarding that state, policy decisions, control history, and related evidence in a consistent format. Accordingly, the Digital Integrity Report can serve as a key element in securing the visibility, traceability, and verifiability of the entire trust system.

[0644] The aforementioned digital integrity report can be generated by receiving as input integrity verification results from the verification domain, response decisions derived from the policy-based judgment structure, and execution results generated from the control execution structure. In this case, the results of each stage can be interconnected based on the same trace identifier; accordingly, it is desirable that the report be configured to reconstruct the entire state transition process from "verification -> judgment -> execution" within a single object. The trace identifier can be assigned at the functional block level, session level, request level, transaction level, or result level, allowing multiple objects belonging to the same event to reference it within a single system.

[0645] In one embodiment, the digital integrity report may be generated as a structured object comprising at least a report identifier, a system identifier, a function block identifier, a reference identifier, a runtime identifier, a verification result, a severity level, an applied policy identifier, an executed control command, an execution result status, a generation timestamp, and a digital signature. Additionally, depending on the embodiment, it may additionally include a session identifier, a request identifier, a policy version, a normalization profile identifier, an algorithm identifier, an environment hash, a result identifier, a time point token identifier, a previous report reference value, and a related verification state object identifier or policy decision object identifier. If the required fields are missing, the report may not be recognized as a complete evidence report or may be classified as a report with a limited trust level.

[0646] The above report may be presented in JSON, XML, CBOR, PDF-A, or a structured data format that meets regulatory requirements. JSON or XML structures facilitate machine readability and integration with external systems, while long-term retention formats such as PDF-A enhance the potential for use as evidentiary documents for legal submissions or long-term audits. The important point is not the presentation format itself, but that the meaning and relationships of each field are consistently defined so that the same report can be independently interpreted and verified by different systems or agencies.

[0647] As illustrated in FIG. 15, the report may be composed of a structured data model including a timestamp, a reference identifier, an execution identifier, a comparison result, a policy identifier, a module identifier, and a previous report hash value. Through this structure, consistent representation of verification results and data reuse for subsequent verification are made possible. Additionally, as illustrated in FIG. 16, a data model may be constructed in which the reference identifier record, the execution identifier record, the integrity verification result, the policy evaluation result, the response execution history, and the digital report are linked by cross-reference relationships, thereby ensuring traceability and auditability of the entire verification process.

[0648] The digital integrity report may be stored as a single simple flat object, but depending on the embodiment, it may be configured as a hierarchical structure containing multiple sub-sections internally. For example, the report may include an identity section, a verification section, a policy decision section, a response execution section, an evidence section, a timestamp section, a signature section, and a chain reference section. This hierarchical structure clarifies that the report is an object that describes not only a verification decision at a single point in time, but also how that decision was generated and what response it led to as a whole.

[0649] In particular, the verification section may contain or reference the verification state object created in 2.7 and may include a function block identifier, the applied reference version, the result of comparing the identifier value, the result of metadata consistency, the comparison rule, the final integrity status, and the basis for the decision. The policy decision section may contain or reference the policy decision object created in 2.8 and may include the applied policy rule identifier, whether a response is required, the response priority, whether immediate execution is required, whether manual approval is required, and the basis for the decision. The response execution section may contain or reference the response execution record created in 2.9 and may include the executed control command, the control target, the time of execution, the execution result, and whether a re-verification request was made. Through this structure, the report can function not merely as a storage of results, but as an evidence package explaining the relationship between judgment and execution.

[0650] In one embodiment, the digital integrity report is generated as an independent report object containing verification results, policy judgments, and control execution results, and the report object may be configured to be linked by a separate chain of custody object or a chain reference structure. In this case, the report object constitutes the body of the evidence data, and the chain of custody object may function as a separate layer that ensures evidence continuity by managing the report and related event objects in a hash link structure. Accordingly, it is desirable to design the report so that the content of the report itself and the sequential relationship between reports are clearly separated yet can be mutually referenced.

[0651] As illustrated in FIG. 14, each report can form a continuous hash chain by including the hash value of the previous report along with digital signature and timestamp authentication information. For example, the nth report may include its own body hash value, the hash value of the n-1st report, the time of creation, the creator identifier, and the related trace identifier. Through this structure, the prevention of tampering and the maintenance of integrity of the entire report history can be guaranteed, and even if only a specific report is manipulated individually, the integrity of the entire chain is broken, allowing an external validator to detect it.

[0652] To ensure the reliability of the digital integrity report, a digital signature may be applied during the report generation process. The signature may be performed by one or more of a verification server, a policy judgment module, a control execution module, or an equivalent trusted entity. Depending on the embodiment, a single signature structure may be applied, while in other embodiments, a multi-signature structure in which a verification server signature, a policy engine signature, and a control execution result confirmation signature are combined sequentially or in parallel may be applied. When a multi-signature structure is applied, an external verifier can determine not only the fact that "the report exists," but also whether each entity in the verification, judgment, and execution phases has independently verified the contents of the report.

[0653] In addition, the digital integrity report may be assigned credible time information regarding the time of creation through a Time Stamping Authority (TSA). As illustrated in FIG. 13, the generated digital integrity report or its hash value is transmitted to a Time Stamping Authority, and a timestamp token may be issued by the authority. Subsequently, the timestamp token may be combined with the report and stored. This ensures the reliability of the report's time of creation and allows for the detection of attempts to retroactively change the time of creation by manipulating the report after the fact. Depending on the embodiment, RFC 3161 (Time-Stamp Protocol) or a protocol equivalent thereto may be applied, and multiple time sources or multiple timestamp structures may be used as needed.

[0654] It is desirable that the aforementioned report be structured to enable independent verification by external entities. For example, an external verifier can recalculate identification values ​​using the reference identifier and runtime identifier included in the report, verify digital signatures and timestamp tokens, or check for changes to the report through a chain of custody structure. Additionally, the chronological order, response process, and follow-up actions of a specific event can be reconstructed by referring to the previous report hash value and trace identifier. As such, the report must have a structure that allows a third party to independently verify its reliability even after its creation, and this is a key feature that distinguishes it from simple operational logs.

[0655] In one embodiment, the digital integrity report may provide verification results externally not only through a network-based interface but also through a physical output interface. The physical output interface may include a display, an LED indicator, a warning light, an audible device, or an equivalent output device, and the output device may be configured so that a general user, auditor, or operator can directly perceive the integrity status of the current system or the status of the source consistency of the execution result without separate system access. For example, the statuses of PASS, WARNING, and CRITICAL may be displayed via green, yellow, or red LEDs, or the status of an execution authenticity violation may be immediately announced via separate warning lights and sound patterns. This structure can function as an extension of a public verification interface and ensures visibility of verification results even in environments where network access is restricted.

[0656] The report structure may include metadata for searching, aggregation, and regulatory compliance. For example, it may include report identifiers, creation timestamps, creators, policy versions, system environment information, normalization profile identifiers, algorithm identifiers, service areas, feature block importance, severity levels, regulatory tags, or reporting obligation tags. This metadata can be utilized for searching, filtering, statistical aggregation, long-term trend analysis, submission to regulatory agencies, and visualization on external dashboards.

[0657] Furthermore, the aforementioned digital integrity report is not limited to representing the state at a single point in time but can be extended into a time-series-based structure. That is, by sequentially linking or aggregating multiple reports generated over a certain period for a specific functional block or system, it is possible to analyze trends in state changes, recurring deviation patterns, policy application effectiveness, and long-term stability indicators. For example, by aggregating reports from the past 30 days for the same functional block, it is possible to analyze warning frequency, divergence frequency, automated response success rates, and the number of authenticity violations. This time-series extended structure goes beyond simple event recording to provide a basis for statistical and regulatory analysis of operational reliability.

[0658] Meanwhile, in high-trust environments, digital reports may be configured to optionally include an execution_authenticity_section. This section includes an independent judgment structure for verifying the origin legitimacy of execution results separately from code integrity, and may include token verification, flow verification, binding verification, approved module chain verification, and authenticity determination items. Accordingly, it can represent a complex state where execution authenticity is judged as SUSPICIOUS or INVALID even when code integrity is judged as PASS. This can be utilized to identify high-risk situations such as unauthorized execution, shadow execution, bypass execution, or discrepancies in result attribution. The execution_authenticity_section is not a mandatory component in all embodiments and may be omitted if integrity verification at the functional block level is sufficient. However, in financial, public, medical, defense, high-risk AI, and regulated systems, this structure may be enabled to provide a higher level of trust verification.

[0659] Digital reports can be recorded in immutable storage after creation, and such storage may be configured as an append-only or WORM (write once read many) structure. Reports recorded in said storage may be maintained in a state where they are immutable or strictly restricted, and external entities may view and verify the reports according to access permission policies. If necessary, the report hash value or the chain root hash value may be anchored to a blockchain or distributed ledger, thereby enabling verification of the existence and modification status of the report even outside the report storage.

[0660] As such, the digital integrity report structure serves to integrate all key information generated by the integrity verification system into a consistent format, guarantee its reliability, and secure the possibility of external verification. Through this, the present invention can provide a publicly verifiable trust structure that extends beyond the guarantee of integrity at the internal system level to include external auditing bodies, regulatory authorities, and general users.

[0661] In the following section, based on the digital integrity report mentioned above, a chain of custody and trust storage structure that more strictly guarantees data immutability and evidence continuity will be described in detail.

[0662] 2.12 Chain of Custody

[0663] In one embodiment, a chain of custody structure may be configured to function as an evidence management structure to ensure data continuity, integrity, and immutability throughout the entire process of creation, storage, transmission, retrieval, and verification of a digital integrity report after the report is generated. The chain of custody structure aims not only to ensure the reliability of a single report but also to ensure the reliability of the entire history, including the temporal order, causal relationships, and reference relationships among multiple reports.

[0664] Generally, even if a digital signature and timestamp are assigned to a single report, the reliability of the entire history may be compromised if only the report at a specific point in time is selectively deleted or intermediate reports are tampered with. Therefore, it is desirable for the present invention to combine the connection relationships between reports based on hashing, so that the modification or deletion of a specific report affects the consistency of the entire chain.

[0665] In one embodiment, each digital integrity report may include a hash value for its body data (report hash) and may be configured to simultaneously include a hash value for a previous report (previous report hash). Accordingly, the nth report may be generated with a structure including (i) a hash value for its content, (ii) a hash value for the (n-1)th report, (iii) a time of creation, (iv) an identifier of the creator, and (v) a trace identifier. This structure allows a series of reports to form a hash chain in which they are sequentially connected.

[0666] The aforementioned hash chain goes beyond a simple connection structure to provide a mathematical basis for verifying data integrity. For example, if the content of the k-th report is changed, its hash value changes, resulting in a discrepancy with the previous hash field of the k+1-th report. Since such a discrepancy can be immediately detected during the verification of the entire chain, the tampering or deletion of intermediate reports can be structurally prevented.

[0667] As illustrated in FIG. 14, the chain of custody structure can be implemented as a linear chain structure in which each report refers to a previous report, and depending on the embodiment, it may be extended to a branch structure based on the state at a specific point in time or a structure in which multiple chains exist in parallel. For example, for the same system, a functional block unit chain, a service unit chain, a session unit chain, or an event unit chain may be maintained separately, and if necessary, these chains may be connected through a cross-reference relationship.

[0668] In one embodiment, the chain of custody structure may operate in combination with a digital signature for each report in addition to a simple hash link. That is, each report is signed including its own hash value and the previous hash, thereby ensuring that a specific report was generated by a specific entity at a specific time. Additionally, the signature may be composed of a single signature or a multi-signature structure, and a verification server, a policy judgment module, a control execution module, or an external certification authority may participate.

[0669] Additionally, the chain of custody structure can be combined with timestamp authentication. Each report or a batch of reports within a specific interval may be timestamped by a Time-Stamped Authority (TSA), thereby proving that the reports have not been altered since a specific point in time. Depending on the implementation, a structure that assigns individual timestamps to all reports and a batch method that assigns a single timestamp to reports within a specific interval may be optionally applied.

[0670] The above chain of custody structure is also closely linked to the storage method of the report. In one embodiment, the report may be written to an immutable storage having an append-only structure or a WORM (write once read many) structure. The storage may be implemented as a file system, object storage, a distributed storage system, or a dedicated evidence storage system, and it is preferable that it have a structure in which the modification or deletion of existing data is impossible or strictly limited.

[0671] In one embodiment, the chain of custody structure can be extended by combining it with an external trust infrastructure. For example, at regular intervals or upon the occurrence of a specific event, the root hash of the report chain or the Merkle tree-based aggregate hash value can be recorded on an external blockchain or a credible distributed ledger system. Through such an anchoring structure, an external third party can independently verify the existence and state of the report chain stored in the internal repository.

[0672] For example, if a Merkle tree is constructed for a set of reports generated at a specific point in time T and its root hash is recorded on an external blockchain, an external validator can detect if a specific report is subsequently modified or deleted, as the proof path containing that report changes. Accordingly, the present invention can provide additional means of guaranteeing integrity using external public infrastructure, going beyond the reliability level of an internal storage.

[0673] Furthermore, the chain of custody structure can play a crucial role in the process of accessing and querying reports. For example, an external auditor querying a specific report can verify not only the single report object itself but also the set of consecutive reports preceding and following it. This allows for the reconstruction of the entire flow, including not only the state at a specific point in time but also the process leading up to that state and subsequent changes.

[0674] In one embodiment, the chain verification procedure may be performed in the following steps. First, the validator can verify the digital signature of a specific report to confirm whether the report was generated by a trusted entity. Next, the connection with the previous report can be confirmed using the previous hash of the report. Subsequently, the entire chain can be traversed to verify whether hash connections between each report are maintained. Finally, the legitimacy of the time of report generation can be confirmed by verifying a timestamp token or external anchoring information. Through this procedure, reliability at the report level, chain level, and time level can all be verified.

[0675] Furthermore, the present invention can construct an event-centric evidentiary model based on a chain of custody structure. That is, related reports can be grouped around events—such as integrity deviations, policy judgments, and control executions occurring in specific functional blocks—and the entire history chain related to those events can be managed as a single logical unit. This can play a crucial role in regulatory reporting, incident analysis, forensic investigations, and legal dispute response.

[0676] The above chain structure may be maintained only within a single system, but depending on the embodiment, it may be extended to a linked chain structure between multiple systems. For example, a structure may be configured in which a certification authority, a verification server, and an operating system each maintain separate chains while exchanging cross-referenced hashes. In this case, the reliability of a specific result does not rely on a single chain but can be enhanced through a structure in which multiple independent chains perform cross-verification.

[0677] Furthermore, the aforementioned chain of custody structure can be designed with long-term preservation in mind. For example, a report chain may be moved to an archive repository after a certain period, and chain linkage information and signature information must be maintained during this process. Additionally, to prepare for cases where the security of the hash or signature algorithm is weakened, long-term reliability can be maintained by periodically re-signing with a new algorithm or by incorporating the existing chain into a new chain.

[0678] The chain of custody and trust storage structure configured in this manner is characterized by structurally securing the continuity and immutability of the entire report history, going beyond guaranteeing the integrity of a single report. Through this, the present invention can provide a trust record system capable of being utilized as legal evidence, going beyond a simple operational record system, and can be expanded into a public trust infrastructure that enables independent verification by external auditing bodies, regulatory authorities, and general users.

[0679] 2.13 Public Verifiability Interface

[0680] In one embodiment, a public verification interface may be configured as an interface layer to provide an external entity with the ability to independently query and verify digital integrity reports and chain of custody information generated by the integrity verification system according to the present invention. The purpose of the public verification interface is to enable external verification of the authenticity and reliability of the verification results without direct access to the operating system or the verification system.

[0681] The aforementioned public verification interface is not limited to simple information retrieval functions and can provide multi-layered verification capabilities that include the integrity, signature, timestamp, chain linkage relationships, and source consistency of the report. Accordingly, external users, auditing bodies, or regulatory bodies can independently reconstruct not only the system state at a specific point in time but also the entire verification and response process leading to that state.

[0682] In one embodiment, the public verification interface may be provided in the following forms, but is not limited thereto. First, it may be provided in the form of a web-based dashboard. The dashboard may visually represent the system's current integrity status, status by functional block, recent verification results, severity distribution, response history, and execution authenticity status. Additionally, it may be configured to allow detailed verification of the internal structure, signature information, timestamps, chain connection status, and policy application results by selecting a specific report.

[0683] Second, it may be provided in the form of an Application Programming Interface (API). The API may be implemented using RESTful, gRPC, or equivalent communication methods, and supports external systems in mechanically querying and verifying digital integrity reports, chain data, verification status objects, and policy judgment results. For example, an API may be provided that takes a specific report identifier or trace identifier as input and returns the entire verification history, policy judgments, and control execution records associated with the report.

[0684] Third, it can be provided in the form of a mobile interface. This can be implemented through a mobile application or a lightweight web interface, enabling operators, auditors, or general users to check the system status even while on the move. In particular, it may include a structure that provides real-time push notifications when a warning or high-risk state occurs.

[0685] Fourth, it may be provided in the form of an external audit linkage interface. This can be implemented in a structure that is directly linked to regulatory bodies, certification bodies, or external audit systems to automatically transmit report data or provide a specific range of data in response to an audit request. For example, it may include functions to convert reports into a standard format required by regulatory bodies for submission or to automatically deliver a chain of reports for a specific period.

[0686] The above-mentioned public verification interface may be combined with access control, authentication, and data protection mechanisms. For example, a hierarchical access structure may be applied in which only summary information is provided to general users, detailed reports and chain information are provided to authenticated auditors, and full data access is granted to regulatory bodies. Additionally, sensitive information may be provided after being masked or anonymized.

[0687] In one embodiment, an external verifier may perform the following independent verification procedures using information provided through a public verification interface. First, a specific digital integrity report may be queried, and the digital signature included in the report may be verified to determine whether the report was generated by a trusted entity. Next, a tim...

Claims

1. In a third-party authentication-based execution integrity verification system for verifying the execution integrity of a digital system in operation, (a) A Certified Reference Identifier Registry (CRIR) that stores reference identification values ​​generated from a configuration pre-verified by a third-party certification authority acting as a trust anchor independent of the operator of the digital system for a verification target performed in the digital system; (b) a Runtime Integrity Monitoring Agent (RIMA) that generates execution identification values ​​in units of function blocks configured to generate the same value in the same execution state by reflecting the execution state within the operating environment of the digital system; and (c) An independent verification server (IVS) configured to operate in a verification domain that is organizationally or functionally separated from the operating entity of the digital system and to determine the integrity status by comparing the execution identification value in units of functional blocks with reference to the reference identification value; Includes, An execution integrity verification system characterized in that the above-mentioned third-party certification authority, the operating domain of the above-mentioned digital system, and the above-mentioned verification domain form independent trust boundaries that are functionally and organizationally separated.

2. In Claim 1, An execution integrity verification system characterized by the above-mentioned function blocks being deterministically divided according to function units, method units, class units, module units, configuration object units, state transition units, or a combination thereof.

3. In Claim 1, An execution integrity verification system characterized in that the above-mentioned standard identification value is generated for an executable file, library, script, configuration file, policy table, model parameter, or a combination of two or more of these.

4. In Claim 1, An execution integrity verification system characterized by the above-mentioned standard identification value being generated in a deterministic build environment configured to enable the reproduction of identical build outputs under identical source code, identical configuration information, and identical build conditions.

5. In Claim 4, An execution integrity verification system characterized in that the above deterministic build environment is configured to fix or record at least one of a compiler version, library version, link order, environment variable, build option, normalization profile, domain identification information, and build script version.

6. In Claim 1, An execution integrity verification system characterized by generating the above execution identification value by combining at least one of execution code, code or data loaded into memory, configuration parameters, execution context, input event information, and policy application status.

7. In Claim 1, An execution integrity verification system characterized in that the integrity monitoring agent is configured to generate the execution identification value based on a cycle-based, event-based, request-based, or a combination thereof.

8. In Claim 1, An execution integrity verification system characterized in that the integrity monitoring agent includes a self-integrity check function for its own executable file, configuration status, code signing status, or communication status, and is configured to transmit the results to the independent verification server or a separate independent verification server.

9. In Claim 1, An execution integrity verification system characterized by the above-mentioned independent verification server including an integrity verification function that determines the consistency between an execution identifier and a reference identifier, and a metadata integrity verification function that determines the consistency of execution environment information, version information, policy identifier, or configuration information.

10. In Claim 9, An execution integrity verification system characterized by the above-described independent verification server being configured to determine whether a reference identification value and an execution identification value match at the unit level of a function block in a first comparison step, to identify the location of the difference using a sub-component unit or a partial identification value based on a hierarchical structure in a second comparison step, and to determine the consistency of metadata in a third comparison step.

11. In Claim 1, An execution integrity verification system characterized by the above-mentioned independent verification server being configured to determine an out-of-bounds state if the comparison result does not match the reference state or deviates from a predefined policy or acceptance standard.

12. In Claim 11, An execution integrity verification system characterized by further including a policy-based response module that determines a response level based on at least one of the importance of a function block, a type of deviation, the number of repeated occurrences, an execution context, a time condition, or a risk classification when the above-mentioned deviation state is determined.

13. In Claim 12, An execution integrity verification system characterized by the above policy-based response module generating control commands to perform at least one of the following responses: session termination, execution suspension, function restriction, administrator warning, additional verification, switching to an alternative execution path, entry into a safe state, or notification to a supervisory authority.

14. In Claim 13, An execution integrity verification system characterized by further including a real-time control agent that receives the control command and reflects it in a target system, wherein the real-time control agent is configured to perform a control operation after verifying at least one of a command identifier, a valid time, a nonce value, or a signature value.

15. In Claim 1, An execution integrity verification system characterized by being configured to generate a digital integrity report including the reference identification value, execution identification value, comparison result, judgment status, application policy, control execution result, and verification time.

16. In Claim 15, An execution integrity verification system characterized in that the above digital integrity report is generated by combining at least one of a digital signature, a timestamp, a report identifier, a session identifier, or a chain of custody records.

17. In Claim 15, An execution integrity verification system characterized in that the above digital integrity report is stored in an immutable storage means having a structure in which modification or deletion of data is restricted or history tracking is possible, and the immutable storage means includes a blockchain-based ledger, a WORM repository, an append-only secure database, or a combination thereof.

18. In Claim 1, An execution integrity verification system characterized by further including a public verification interface that allows external users, auditing bodies, regulatory bodies, or stakeholders to view and independently verify verification results or digital integrity reports containing such results.

19. In Claim 18, An execution integrity verification system characterized by the above-mentioned public verification interface including at least one external verification channel that enables an external entity to view verification results or a digital integrity report containing the same and to verify them independently.

20. In Claim 19, An execution integrity verification system characterized in that the above-mentioned external verification channel includes one or more of a web-based dashboard, an application programming interface (API), a mobile application, an external audit integration interface, or a blockchain explorer.

21. In claim 20, An execution integrity verification system characterized in that the above-mentioned public verification interface is configured to transmit the same verification result or related verification data through a plurality of different external verification channels, and is configured to enable cross-verification between the plurality of channels.

22. In Claim 1, An execution integrity verification system characterized by further including an execution result source verification structure configured to determine the source consistency of an execution result using at least one of an execution token, call flow information, result binding information, or approved module chain information, in order to additionally determine whether a specific result was generated following an approved execution procedure.

23. A third-party authentication-based execution integrity verification method for verifying the execution integrity of a digital system in operation, (a) For a functional block of the digital system, a third-party certification authority independent of the operating entity and the development entity of the digital system generates a standard identification value from a pre-verified shape and registers it in a certified standard identification value registry; (b) a step of generating an execution identification value in the form of a function block unit so that the same value is generated in the same execution state by reflecting the execution state within the operating environment of the digital system; and (c) A step of determining the execution integrity status by comparing the execution identification value with the function block unit by referring to the above-mentioned standard identification value. A method for verifying execution integrity characterized by including 24. In Claim 23, The execution integrity verification method is characterized by further including the step of providing the judgment result or a digital integrity report containing it through a public verification interface so that external users, auditing bodies, regulatory bodies, or stakeholders can directly view and verify it.

25. In order to verify the execution integrity of a digital system in operation, (a) Refer to a standard identifier generated by a third-party certification authority, and (b) Generate an execution identifier that reflects the state during execution, and (c) Determine the execution integrity status by comparing the above-mentioned standard identification value and the above-mentioned execution identification value in units of function blocks A non-transient computer-readable recording medium storing instructions for controlling a computer.

26. In Claim 1, An execution integrity verification system characterized in that the above execution identification value includes at least one of a static identification value generated from a static component determined prior to the execution of a digital system and a dynamic identification value generated by reflecting the state during operation, or is generated by a combination thereof.

27. In Claim 26, An execution integrity verification system characterized by the above static identification value being generated from at least one of an executable file, a library, configuration information, a policy table, or a distribution product.

28. In Claim 26, An execution integrity verification system characterized in that the above dynamic identification value is generated by additionally reflecting at least one of an execution memory state, dynamic loading code, input data, execution flow information, or runtime event information to an identification value generated based on an executable file, library, configuration information, or other static components.

29. In Claim 26, An execution integrity verification system characterized by the above-mentioned independent verification server being configured to identify tampering with the execution state, dynamic library substitution, runtime setting changes, or unauthorized changes in memory that are difficult to identify through verification based on static identification values.

30. In Claim 26, An execution integrity verification system characterized in that the above-described independent verification server is configured to determine the execution integrity status by combining static identification values ​​and dynamic identification values, or by using dynamic identification values ​​that include static identification values.

31. In Claim 1, An execution integrity verification system characterized in that the execution identification value is repeatedly generated over multiple points in time rather than a single point in time, and the independent verification server is configured to determine the persistence or pattern of change of the execution integrity state over time.

32. In Claim 23, A method for verifying execution integrity, characterized in that the execution identification value includes at least one of a static identification value determined prior to the execution of a digital system and a dynamic identification value reflecting the state during operation, or is generated by a combination thereof.

33. In Claim 32, An execution integrity verification method characterized by the above-mentioned judgment step further including a step for identifying changes in the execution state that are difficult to identify by verification based solely on static identification values.

34. In Claim 25, A non-transient computer-readable recording medium characterized by the above-mentioned instruction generating at least one of a static identification value and a dynamic identification value, and controlling a computer to determine the execution integrity state using the same.

35. In any one of claims 1 to 16, An execution integrity verification system characterized by the above digital system including an online game system, a gambling system, a financial system, an e-government system, an artificial intelligence-based judgment system, an industrial control system, or a high-reliability digital system equivalent thereto.

36. In any one of claims 1 to 16, An execution integrity verification system characterized by being configured to be applicable to multiple industrial domains where reliability of execution results is required, wherein the industrial domains include financial transaction processing, probability-based result generation, artificial intelligence judgment, public decision-making, or industrial control.

37. In Claim 1, An execution integrity verification system characterized in that the digital system includes an inference process or judgment flow of an artificial intelligence model, and the execution integrity verification is configured to verify the integrity of the inference process.

Images