A kernel-driven secure chip access control method and related device thereof

Abstract

The application provides a kernel-driven secure chip access control method and a related device thereof, and relates to the technical field of secure chips. The method deploys a daemon process in the user state as the only trusted entrance of the secure chip, blocks direct access of the application to the underlying device node, and avoids concurrent conflicts. The specified path is bound through the UNIX domain socket, and the permission and owner are set in combination, so that only the pre-authorized application is allowed to connect. The daemon process maintains a finite state machine, dynamically determines the legality of the command according to the current state, interacts with the chip through the kernel driver only when allowed, and ensures that the operation timing is correct. When a security event such as protocol exception, hardware failure or high-frequency request is detected, the device is automatically migrated to the attack state, and responses such as locking the chip, erasing the key or recording the log are triggered, active defense is realized, and the reliability, controllability and attack resistance of the secure chip are significantly improved.

Description

Technical Field

[0001] This application relates to the field of security chip technology, and in particular to a kernel-driven security chip access control method and related devices. Background Technology

[0002] In embedded security devices such as POS terminals and encryption modules, traditional access methods for security chips typically expose underlying interfaces, such as serial port device nodes, allowing multiple application processes to call them concurrently. This design has significant drawbacks: concurrent access by multiple processes can easily lead to command interleaving and internal state chaos; the lack of unified control over operation timing may cause communication to initiate before initialization is complete, resulting in hardware anomalies; the system lacks centralized state management and anomaly recovery mechanisms, making reliability difficult to guarantee; furthermore, due to the exposed interface, any process with device node access permissions can directly operate the security chip, posing a security risk of unauthorized access by malicious programs. The root cause of these problems lies in the fact that existing solutions treat security chips as ordinary peripherals, failing to establish a trusted, orderly, and controlled access proxy mechanism, resulting in security, stability, and maintainability failing to meet the requirements of high-security scenarios. Summary of the Invention

[0003] This application provides a kernel-driven security chip access control method and related devices to solve one or more technical problems existing in the prior art, and at least provides a beneficial option or creates conditions to achieve unified, orderly and highly secure access control of the security chip through a user-mode daemon process combined with UNIX domain sockets and finite state machines, effectively preventing illegal calls, concurrent conflicts and state chaos.

[0004] On the one hand, this application provides a kernel-driven secure chip access control method, including the following steps: A daemon process is started and runs in the user space of the operating system. This daemon process serves as the only trusted access point for the security chip, prohibiting applications from directly accessing the underlying device nodes of the security chip. The daemon process creates a UNIX domain socket and binds the UNIX domain socket to a specified path in the file system; By using permission setting system calls and owner setting system calls, the file access permissions for the specified path are configured so that only pre-authorized applications can initiate connection requests through the UNIX domain socket. The daemon process maintains a finite state machine; When a client command is received, the daemon process determines whether the command is allowed to be executed based on the current state of the finite state machine: if allowed, it communicates with the security chip through the kernel driver and returns the result; otherwise, it rejects the command. During operation, if a security event is detected, the finite state machine is triggered to transition to the attacked state of the device and execute the preset security response strategy.

[0005] Furthermore, the finite state machine includes at least an idle state, a connected state, a working state, an upgrade state, and a device under attack state, and defines legal transition paths between each state; The state transition rules of the finite state machine include: The system is in an idle state after initialization is complete; The state can only transition from idle to connected. The device transitions from the connected state to the working state after completing the security chip handshake authentication, or to the upgrade state after receiving an upgrade command. The device transitions from an operational state to an upgraded state upon receiving a legitimate upgrade request, or to an attacked state upon detecting a security incident. When the device is under attack, all client commands will be rejected until the system is reset or an administrator intervenes.

[0006] Furthermore, the daemon process creates an independent processing thread for each client connection and calls the kernel driver interface through a message sending function. The kernel driver provides functions for resetting the security chip, serial data transmission and reception, and error status reading.

[0007] Furthermore, in the upgrade state, the daemon process loads the firmware upgrade package from the preset security directory, writes the firmware upgrade package into segments to the security chip through the kernel driver, and updates the version information after successful verification, and then migrates back to the working state; if the verification fails, it rolls back to the state before the upgrade and enters the device under attack state.

[0008] Furthermore, the UNIX domain socket is a stream socket, and the specified path is located in a protected directory, the access permissions of which are uniformly managed by the system security policy.

[0009] Furthermore, the security event includes any of the following: invalid client command protocol format, firmware integrity verification failure, security chip returning a hardware abnormality signal, or the client request frequency exceeding a preset threshold within a unit of time; The security response strategy includes at least one of the following: locking the security chip to prevent further operations, erasing the sensitive keys stored inside the security chip, recording the security event to the audit log, and sending an alarm signal to the operating system security module.

[0010] On the other hand, this application provides a security chip that integrates a processor, a secure storage unit and a serial communication interface. The security chip is configured to work in conjunction with a daemon running in the user mode of the operating system to execute the aforementioned kernel-driven security chip access control method. The security chip responds to commands forwarded by the daemon process via the kernel driver and actively triggers a hardware-level security response when an unauthorized access attempt is detected.

[0011] On the other hand, this application provides a kernel-driven security chip access control system, including: As mentioned above, security chips; The kernel driver module provides a low-level access interface to the security chip. The daemon module runs in user space and is configured to execute the aforementioned methods, serving as the sole access proxy for the security chip. The client application communicates with the daemon module via UNIX domain sockets and must not directly access the device node of the security chip.

[0012] Furthermore, the daemon module and the kernel driver module interact with each other through standard system calls or character device interfaces, and the kernel driver module performs a second validity check on the requests from the daemon module.

[0013] On the other hand, this application provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the aforementioned kernel-driven security chip access control method.

[0014] The beneficial effects of this application are as follows: This application provides a driver-based security chip access control method. This method effectively blocks direct access of applications to the underlying device nodes of the security chip by deploying a daemon process in user space as the only trusted access entry point for the security chip, fundamentally avoiding command conflicts and state chaos caused by concurrent multi-process operations. The daemon process uses UNIX domain sockets to bind to a specified path in the file system and combines permission setting system calls and owner setting system calls to precisely control access permissions, ensuring that only pre-authorized applications can establish communication connections, significantly improving access security. At the same time, by maintaining a finite state machine to model the system operation phase, the system dynamically judges the legitimacy of the received client command based on the current state, and only interacts with the security chip through the kernel driver when the state allows, thereby ensuring the timing correctness and atomicity of the operation. In addition, when security events such as protocol anomalies, hardware failures, or abnormally high-frequency requests are detected, the system can automatically transition to the device under attack state and trigger preset response strategies such as locking the chip, erasing keys, or logging, realizing proactive defense and rapid emergency response, and significantly enhancing the reliability, controllability, and anti-attack capability of the security chip during operation.

[0015] This application also provides related equipment for the above method. The beneficial effects of the related equipment are similar to those of the above method, and will not be described in detail here.

[0016] Other features and advantages of this application will be set forth in the description which follows, and will be apparent in part from the description, or may be learned by practicing the application. The objectives and other advantages of this application may be realized and obtained by means of the structures particularly pointed out in the description, claims and drawings. Attached Figure Description

[0017] The accompanying drawings are provided to further understand the technical solutions of the present invention and constitute a part of the specification. They are used together with the embodiments of the present invention to explain the technical solutions of the present invention, and do not constitute a limitation on the technical solutions of the present invention.

[0018] Figure 1 This is a flowchart of the kernel driver security chip access control method provided in this application; Figure 2 This is a structural diagram of the kernel driver security chip access control system provided in this application. Detailed Implementation

[0019] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0020] The present application will be further described below with reference to the accompanying drawings and specific embodiments. The described embodiments should not be considered as limitations on the present application, and all other embodiments obtained by those skilled in the art without inventive effort are within the scope of protection of the present application.

[0021] In the following description, references are made to “some embodiments,” which describe a subset of all possible embodiments. However, it is understood that “some embodiments” may be the same subset or different subsets of all possible embodiments and may be combined with each other without conflict.

[0022] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application belongs. The terminology used herein is for the purpose of describing embodiments of this application only and is not intended to limit this application.

[0023] In today's high-security embedded systems, such as financial payment terminals, identity authentication devices, IoT security modules, and trusted execution environment platforms, security chips are widely used to perform critical security functions such as key storage, encryption / decryption operations, and secure boot verification. These security chips typically exist as coprocessors or independent secure elements, communicating with the main processor via a serial interface such as UART, and having their access interfaces exposed by character device nodes in the operating system, such as dev ttySx. In traditional implementations, applications can directly open this device node, sending commands to the security chip and receiving responses through standard file read / write operations or ioctl system calls. While this direct connection mode is simple to implement, it exposes a series of serious technical flaws in practical applications.

[0024] First, multiple applications or processes may simultaneously attempt to access the same security chip device node, leading to command interleaving, misaligned responses, and even internal state machine disorder. Since security chips typically lack multi-session management capabilities, their internal state relies on strict operational timing; for example, an initialization handshake must be completed before encryption operations can be performed. If two processes send initialization commands and business commands in different orders, it can easily cause the chip to hang or return incorrect results, rendering the system unavailable.

[0025] Secondly, existing technologies lack mechanisms for authenticating the identity and controlling access permissions of the user. As long as an application has read and write permissions to the device node, it can arbitrarily access all functions of the security chip, including sensitive operations such as key injection or firmware upgrades. In open operating systems like Android, once a malicious application gains the necessary file permissions, it can bypass upper-layer security policies and directly manipulate the security chip, creating a serious security vulnerability. Even with coarse-grained restrictions using Linux file permissions, fine-grained access control based on application identity or security context cannot be achieved.

[0026] Third, traditional solutions lack a unified framework for state management and exception handling. The lifecycle of a security chip involves multiple stages, including idle, connected, operational, and upgrade phases, each with different allowed operation sets. However, in direct connection mode, each application must maintain its own understanding of the chip's state, making it highly susceptible to initiating illegal operations at inappropriate times due to logical errors. Furthermore, when protocol parsing failures, firmware verification errors, or hardware anomalies occur, the system lacks a centralized detection and response mechanism, failing to isolate risks or trigger self-protection measures in a timely manner, allowing attacks to continue uninterrupted.

[0027] Fourth, in critical operation scenarios such as firmware upgrades, existing methods typically involve the application directly pushing the upgrade package to the security chip, lacking atomicity guarantees and rollback mechanisms. If a power outage or data corruption occurs during the upgrade process, the security chip may fall into an unrecoverable abnormal state or even permanently fail. Furthermore, if the upgrade process itself does not undergo rigorous state verification and permission review, it may be exploited as an attack entry point.

[0028] Finally, the existing architecture treats security chips as ordinary peripherals, failing to build a trusted proxy layer at the software level. This results in fragmented security policies, difficulties in auditing, and poor scalability. Each new security feature requires modifications to multiple application logics, making it difficult to maintain and verify overall security. In summary, existing technologies have significant shortcomings in concurrency control, access authorization, state management, anomaly response, and upgrade security, failing to meet the reliability, controllability, and proactive defense capabilities required by modern high-security systems.

[0029] To address the aforementioned issues, this application provides a kernel-driven security chip access control method and related devices. It constructs a daemon process running in the operating system's user space as the security chip's sole trusted access proxy, completely prohibiting applications from directly accessing the underlying device nodes of the security chip. This daemon process creates and binds UNIX domain sockets to specified paths in the file system and precisely controls socket access permissions using permission setting system calls and owner setting system calls, ensuring that only pre-authorized applications can establish connections. Simultaneously, the daemon process maintains a finite state machine covering idle, connected, working, upgrade, and attacked states. All client commands must undergo current state validity verification before being forwarded to the kernel driver for execution, thus strictly guaranteeing operation timing and process atomicity. During operation, the system continuously monitors security events such as protocol compliance, firmware integrity, hardware status, and request frequency. Upon detecting an anomaly, it automatically transitions to the attacked state and triggers preset security response strategies such as locking the chip, erasing keys, logging, or sending alarms. This achieves centralized, orderly, and highly secure management of the entire lifecycle of the security chip.

[0030] In addition, the following concepts need to be explained in this application.

[0031] A security chip is a dedicated integrated circuit with an independent processor, secure storage unit, and encryption computing capabilities. It is used to perform highly sensitive operations such as key management, encryption and decryption, authentication, and secure boot. Its internal data and logic are usually protected by physical and logical safeguards to prevent unauthorized external reading or tampering.

[0032] A kernel driver is a software module that runs in the operating system kernel space and is responsible for providing standardized access interfaces to hardware devices for upper-layer applications. The kernel driver in this application is specifically used to encapsulate the low-level communication details of the security chip, including reset control, serial data transmission and reception, and status reading, and serves as the only kernel-level channel between the user-mode daemon and the security chip.

[0033] A daemon is a special user-mode process that runs continuously in the background of the operating system, independent of terminal control, and does not interact directly with the user. It is usually automatically loaded when the system starts up to provide long-term services. In this application, the daemon acts as the sole trusted agent of the security chip, uniformly receiving, verifying and forwarding all access requests to achieve centralized management.

[0034] UNIX domain sockets are a local IPC mechanism that enables efficient inter-process communication within the same host. They create communication endpoints by binding to file system paths and support streaming or datagram transmission. This application utilizes the feature that file paths can be configured with fine-grained access permissions to limit read and write permissions of socket paths to pre-authorized applications, thereby building a highly secure local communication boundary.

[0035] A finite state machine is a mathematical model used to describe the transition behavior of a system between different discrete states. Each state defines the allowed inputs and the corresponding transition rules. This application applies it to the operation control of a daemon process, explicitly defining five states: idle, connected, working, upgrading, and device under attack, and their legal transition paths, to ensure that the operation of the security chip is always in a controlled and orderly process.

[0036] The permission setting system call and the owner setting system call refer to the underlying interfaces provided by the operating system for modifying file access permissions (such as read, write, execute) and changing the file owner and group, respectively. In this application, they are used to configure the access control attributes of the UNIX domain socket binding path to isolate unauthorized process connection attempts from the file system level.

[0037] Security incidents refer to abnormal behaviors or states that may threaten system security during operation, including client sending commands with invalid protocol formats, firmware integrity verification failures, security chips returning hardware abnormal signals, or request frequencies exceeding preset thresholds within a unit of time. The system triggers proactive defense mechanisms by monitoring these events in real time.

[0038] Security response strategies are a set of pre-defined emergency response measures that are automatically executed after a security incident is detected. Typical strategies include locking the security chip to prevent further operations, erasing sensitive keys stored internally, logging event details to the audit log, and sending alarm signals to the operating system security module to contain risks and support post-incident traceability.

[0039] First, the kernel driver security chip access control method provided in this application embodiment will be described in detail below with reference to the accompanying drawings.

[0040] Reference Figure 1 The implementation process of the kernel driver security chip access control method provided in this application embodiment includes, but is not limited to, the following steps.

[0041] Step S110: Start the daemon process running in the user space of the operating system.

[0042] Among them, the daemon process serves as the only trusted access point for the security chip, prohibiting applications from directly accessing the underlying device nodes of the security chip.

[0043] In step S110, access permissions to the security chip are centrally managed by starting a daemon process running in the operating system's user space, making it the sole trusted entry point for communication between all applications and the security chip. This design fundamentally eliminates the risks of concurrent conflicts, state chaos, and unauthorized calls caused by multiple applications directly accessing the underlying device nodes of the security chip. Since the daemon process is the only entity allowed to interact with the security chip, it can uniformly schedule, verify, and process all requests, thereby significantly improving the system's reliability, security, and maintainability.

[0044] In step S120, the daemon creates a UNIX domain socket and binds the UNIX domain socket to a specified path in the file system.

[0045] In step S120, by creating a UNIX domain socket and binding it to a specified path in the file system, an efficient and secure channel is provided for local inter-process communication. UNIX domain sockets are limited to internal local communication and are not exposed to the network, naturally avoiding the remote attack surface. Furthermore, their file path-based addressing method facilitates access control in conjunction with the operating system's file permission mechanisms. This communication mechanism ensures high-performance interaction with low latency and zero network overhead, while also laying the foundation for subsequent fine-grained permission management, making it a key infrastructure for achieving secure isolation and efficient collaboration.

[0046] Step S130: Configure file access permissions for the specified path through permission setting system calls and owner setting system calls, so that only pre-authorized applications can initiate connection requests through UNIX domain sockets.

[0047] In step S130, operating system permission setting system calls (such as chmod) and owner setting system calls (such as chown) are used to apply strict access control policies to file paths bound to UNIX domain sockets, ensuring that only pre-authorized applications can initiate connection requests. This measure builds the first security boundary, effectively preventing unauthorized or malicious processes from impersonating legitimate clients and communicating with daemons, thereby avoiding the unauthorized triggering of sensitive operations. Through the operating system's native permission model, this step achieves strong authentication and access isolation with minimal performance cost, enhancing the overall security depth of the architecture.

[0048] In step S140, the daemon maintains a finite state machine. When a client command is received, the daemon determines whether the command is allowed to execute based on the current state of the finite state machine. If allowed, it communicates with the security chip through the kernel driver and returns the result. Otherwise, it rejects the command.

[0049] In step S140, a finite state machine mechanism is introduced, enabling the daemon process to dynamically determine the legitimacy of client commands based on its current state. The finite state machine explicitly defines the set of operations allowed in different system phases (such as idle, connected, working, and upgrading). Any command must pass the state-operation permission mapping table verification before execution. This mechanism ensures the orderliness and atomicity of critical processes, such as prohibiting business communication before initialization is complete and rejecting ordinary business requests during firmware upgrades, thereby avoiding hardware anomalies or data corruption caused by timing errors and greatly improving the system's robustness and logical rigor.

[0050] It is important to note that when the system appears alone, it does not refer to just the operating system kernel or just the security chip, but rather to a complete trusted execution environment that includes the kernel, daemons, drivers, security chips, and system services.

[0051] In step S150, if a security event is detected during operation, the finite state machine is triggered to transition to the attacked state of the device, and a preset security response strategy is executed.

[0052] In step S150, a proactive security defense capability is established. When the system detects security events such as illegal command formats, firmware integrity verification failures, abnormal hardware signals, or abnormal request frequencies during operation, it immediately triggers a finite state machine transition to an attacked device state. In this state, the daemon process will reject all subsequent operation requests and execute preset security response strategies, such as locking the security chip, erasing internal sensitive keys, recording audit logs, or sending alarms to the operating system security module. This rapid response mechanism can effectively curb the spread of risks in the early stages of an attack, protect the security of core assets, and provide a basis for post-attack analysis and recovery, reflecting a security design concept that combines defense-in-depth with proactive protection.

[0053] In some embodiments of this application, the finite state machine includes at least an idle state, a connected state, a working state, an upgrade state, and a device under attack state, and defines legal transition paths between each state, thereby constructing a logically rigorous and securely controllable operational process system. This structured state management mechanism ensures that the daemon process remains in a predictable and verifiable behavior mode throughout its entire lifecycle of interaction with the security chip, effectively preventing security vulnerabilities or system crashes caused by illegal or abnormal operations.

[0054] In some embodiments of this application, the state transition rules of the finite state machine include the following.

[0055] (1) After the system is initialized, it is in an idle state. This setting provides a clear starting point for the entire access control process. The idle state means that the system has successfully loaded and completed the necessary self-checks and resource configurations, but has not yet accepted any external connection requests. In this state, the daemon process remains on standby, neither communicating with the security chip nor responding to client commands, thereby avoiding processing invalid or malicious requests when it is not ready, and ensuring the stability and security of the system during the startup phase.

[0056] (2) The system can only transition from an idle state to a connected state. This restriction ensures that all subsequent operations must be based on a valid connection establishment. This rule eliminates the possibility of skipping authentication or connection negotiation and directly entering business processing, forcing all interactions to go through the complete access process. By strictly limiting the migration path, the system can effectively isolate unauthenticated access attempts, laying the foundation for subsequent secure handshakes and permission verification, reflecting the security design concepts of the principle of least privilege and sequential execution.

[0057] (3) From the connected state, it transitions to the working state after completing the security chip handshake authentication, or to the upgrade state after receiving the upgrade instruction.

[0058] Specifically, starting from the connection state, the system determines the next step based on the actual interaction results: if the handshake authentication with the security chip is successfully completed, it transitions to the working state and begins normal business processing; if a clear upgrade instruction is received and the instruction passes the validity verification, it transitions to the upgrade state, preparing to perform high-privilege operations such as firmware updates. This condition-based branching and migration mechanism allows the system to automatically switch to the most suitable working mode in different task scenarios, while ensuring that only processes that pass security verification can continue, preventing state chaos caused by man-in-the-middle attacks or forged instructions.

[0059] (4) From the working state, it can be migrated to the upgrade state when a legitimate upgrade request is received, or to the attacked state when a security event is detected.

[0060] Specifically, from an operational perspective, the system maintains strict control over high-risk operations: migration to the upgrade state is only permitted after a legitimate upgrade request is received and passes integrity and permission verification; and if any security event is detected, such as abnormal access patterns, signs of data tampering, or hardware alarm signals, the system immediately switches to a device under attack state. This two-way exit design supports a smooth transition from normal business to maintenance mode, while also quickly cutting off the operation channel when a threat occurs, enabling dynamic risk response and demonstrating the system's real-time awareness and adaptive defense capabilities regarding the security situation during operation.

[0061] (5) When the device is under attack, reject all client commands until the system is reset or the administrator intervenes.

[0062] Specifically, when a device is under attack, the system adopts the highest level of protection, rejecting all command requests from clients, regardless of their authorization. This state has a lock-in effect and will not automatically revert to other states unless the system is reset or manually intervened by a privileged administrator. This mechanism effectively prevents attackers from using established sessions or cached credentials to continue their infiltration, buying critical time windows for security auditing, log analysis, and emergency response. It also prevents sensitive operations from being performed in compromised environments, thereby maximizing the protection of the security chip and the core keys and data assets it carries.

[0063] In some embodiments of this application, the daemon process creates an independent processing thread for each client connection, effectively achieving secure isolation and efficient scheduling for concurrent access by multiple clients; the daemon process also calls the kernel driver interface through message sending function, and the kernel driver provides functions for resetting the security chip, serial data transmission and reception, and error status reading.

[0064] Specifically, by allocating a dedicated thread to each connection, the system can process multiple requests in parallel without interference, avoiding state pollution or resource contention issues caused by shared context. At the same time, the independent thread model facilitates fine-grained monitoring, timeout control, and abnormal termination of each client's behavior, enhancing system stability and traceability, and providing a foundation for subsequent session-based security auditing.

[0065] The daemon process establishes a standardized communication channel between user space and kernel space by calling the kernel driver interface through message sending function calls. This mechanism decouples high-level application logic from low-level hardware operations, allowing the daemon process to pass structured instructions through a well-encapsulated interface instead of directly manipulating device registers or memory-mapped regions. This not only simplifies the complexity of user-space code but also improves system portability and maintainability, while ensuring that all operations on the security chip are uniformly verified and scheduled by the kernel driver, preventing unauthorized or unauthorized access.

[0066] The kernel driver provides reset control for the security chip, enabling the system to proactively restore its hardware state in scenarios such as initialization failure, communication anomalies, or security events. As a critical underlying capability, reset control allows the daemon to forcibly revert the security chip to a known secure initial state when necessary, clearing potential intermediate data remnants or misconfigurations, thereby interrupting the attack chain and ensuring the reliability of subsequent operations. This function is a crucial technical means for achieving fault self-healing and proactive defense.

[0067] The kernel driver is also responsible for the serial data transmission and reception of the security chip, undertaking the task of reliable transmission of commands and responses between the host and the security chip. Since the security chip typically communicates with the host processor via serial buses such as SPI and I2C, the kernel driver needs to precisely manage timing, protocol formats, and data integrity verification to ensure that sensitive instructions such as key generation, signature operations, or encryption operations are accurately delivered and executed. This low-level communication capability is the physical foundation for the normal operation of the entire access control system, and its stability and security directly affect the trustworthiness of upper-layer services.

[0068] Furthermore, the kernel driver supports error status reading, enabling the daemon process to acquire various anomalies generated by the security chip during execution in real time, including communication timeouts, verification failures, internal faults, or security violations. By promptly capturing and parsing these states, the system can quickly determine whether the current operation was successful and trigger corresponding handling strategies based on the error type, such as retrying, issuing alarms, logging, or switching to an attacked device state. This closed-loop feedback mechanism significantly improves the system's fault tolerance and security response speed, providing crucial support for building a highly available and reliable security chip access control system.

[0069] In some embodiments of this application, during the upgrade process, the daemon loads the firmware upgrade package from a preset security directory, writes the firmware upgrade package into segments to the security chip via the kernel driver, updates the version information upon successful verification, and then migrates back to the working state. If verification fails, it rolls back to the pre-upgrade state and enters a vulnerable state.

[0070] Specifically, the default security directory is typically subject to strict file system permission controls and integrity protection mechanisms, allowing only authorized entities to write or modify its contents, thereby effectively preventing malicious tampering or injection of unauthorized firmware. By limiting the firmware source path and combining it with operating system access control policies, this step constructs the first line of defense in the firmware update process, eliminating the risk of backdoors being implanted or functionality being compromised in the security chip due to the use of untrusted images.

[0071] Subsequently, the daemon process writes the firmware upgrade package to the security chip in segments via the kernel driver. This segmented transmission method not only adapts to the limited internal buffering capacity of the security chip but also improves the reliability and controllability of data transmission. During the segmented writing process, the kernel driver is responsible for managing the underlying communication protocol, processing hardware handshake signals, and ensuring that each segment of data is delivered accurately to the target storage area. This fine-grained data push mechanism facilitates precise location of errors in the event of transmission anomalies and provides a structured foundation for subsequent verification, avoiding resource exhaustion or state inconsistency issues that may be caused by writing large blocks at once.

[0072] After all firmware data has been written, the system performs integrity and validity checks. Only if the checks are successful is the version information inside the security chip updated, marking the official activation of the new firmware. This version information update not only identifies the function switch but also serves as a crucial basis for subsequent compatibility assessments and rollback decisions. This step ensures that only verified, complete, and tamper-free firmware can be activated, preventing security chip malfunctions or security mechanism failures due to partial writes, data corruption, or invalid signatures, thus guaranteeing the atomicity and eventual consistency of the upgrade process.

[0073] After successful verification, the finite state machine transitions back to the working state, restoring the system's normal business processing capabilities. This state transition indicates that the firmware upgrade has been successfully completed, and the security chip is in a stable and usable new version environment, capable of continuing to respond to core security service requests such as encryption and authentication. Through explicit state transition rules, the system avoids unexpectedly processing business commands in the intermediate upgrade state, ensuring clear logic and predictable behavior throughout the entire lifecycle, further enhancing the robustness and security of the overall architecture.

[0074] If verification fails, the system immediately performs a rollback, restoring the security chip to its original state before the upgrade and forcibly migrating to a vulnerable device state. The rollback mechanism ensures that even if the upgrade process is interrupted, data is corrupted, or malicious firmware is injected, it can be quickly restored to a known secure configuration, preventing the system from being unavailable or vulnerable for extended periods. Entering the vulnerable device state triggers a higher level of security response, such as rejecting all external commands, logging security events, and notifying the administrator, to curb the spread of potential threats. This dual-protection strategy demonstrates deep protection against the high-risk operation of firmware updates, balancing reliability and proactive defense capabilities.

[0075] In some embodiments of this application, the UNIX domain socket is a stream socket, and the specified path is located in a protected directory, the access permissions of which are uniformly managed by the system security policy.

[0076] Specifically, UNIX domain sockets are configured as stream sockets. This type supports connection-oriented, ordered, and reliable bidirectional byte stream communication, ensuring the integrity and sequential consistency of data transmitted between the client and the daemon. Compared to datagram sockets, stream sockets are better suited for handling secure chip access requests requiring continuous interaction and state preservation, such as multi-round authentication, segmented firmware transmission, or complex command responses. By adopting a stream communication model, the system effectively avoids issues such as message loss, out-of-order delivery, or truncation, providing a robust transmission guarantee for the stable operation of upper-layer security protocols.

[0077] The design of specifying a path within a protected directory places the file nodes of UNIX domain sockets within a strictly controlled area of ​​the operating system, fundamentally limiting unauthorized processes' discovery and access to communication endpoints. Protected directories typically do not grant write or even read permissions to ordinary users or non-privileged applications; their very existence constitutes a physical isolation barrier, making it difficult for attackers to interfere with or impersonate legitimate communications through path enumeration, symbolic link hijacking, or file replacement. This measure significantly raises the attack threshold and effectively prevents common security threats such as local privilege escalation, man-in-the-middle eavesdropping, or forged client connections.

[0078] Access permissions for protected directories are managed uniformly by system security policies. This means that permission configurations are not statically fixed or determined by a single application, but are integrated into the overall security governance system of the operating system. They can be dynamically adjusted according to security policies and are subject to centralized auditing. This mechanism ensures that even if the daemon process itself has logical flaws, it cannot bypass system-level permission control and arbitrarily relax access conditions. At the same time, unified management facilitates the implementation of the principle of least privilege, such as allowing only specific user groups or signed applications to access the directory. This builds a defense-in-depth system at the system level, making UNIX domain sockets not only a communication channel but also an important component of the trusted execution environment.

[0079] In some embodiments of this application, security events include any of the following: invalid client command protocol format, firmware integrity verification failure, security chip returning a hardware abnormality signal, or the frequency of client requests exceeding a preset threshold within a unit of time.

[0080] Specifically, security events are clearly defined as several categories of detectable abnormal behaviors or system states. The first category is illegal client command protocol formats. When a daemon receives a command that does not conform to the preset communication protocol structure, has an incorrect field length, an unknown opcode, or out-of-bounds parameters, it is determined to be an illegal protocol format. Such anomalies often indicate implementation defects or version incompatibility in the client, or more seriously, it may be a malicious program attempting to trigger buffer overflows, logic bypasses, or other vulnerabilities through malformed input. Including protocol format verification in the scope of security events enables the system to identify and block potential attacks at an early stage, preventing illegal instructions from penetrating kernel drivers or security chips.

[0081] The second type of security incident is firmware integrity verification failure. During firmware loading, upgrading, or operation, if hash verification, digital signature verification, or other integrity mechanisms detect that the firmware content does not match expectations, it is considered a verification failure. This usually means that the firmware may have been tampered with, corrupted, or injected with malicious code during storage, transmission, or update. Since the core functionality of a security chip highly depends on the trustworthiness of the firmware, any integrity breach can lead to key leakage, authentication bypass, or hardware backdoor activation. Therefore, classifying integrity verification failure as a critical security incident can trigger emergency protective measures, such as terminating the upgrade process, rolling back to a secure version, and entering a vulnerable state, thereby ensuring the reliability of the underlying root of trust.

[0082] The third type of security event is a hardware anomaly signal returned by the security chip. This type of signal is actively emitted by the security chip itself when it detects internal faults, voltage anomalies, clock interference, physical tampering attempts, or encryption engine errors. Hardware anomaly signals are an important output of chip-level security mechanisms, reflecting that its operating environment or internal state has deviated from security boundaries. Once the daemon process captures such a signal, it indicates that the security chip may be in an untrusted or unstable state, and continuing to perform sensitive operations would pose an extremely high risk. Defining this as a security event enables the system to respond promptly to hardware-level threats, such as freezing all access, logging physical attack attacks, and switching to an attacked device state to prevent further damage.

[0083] The fourth type of security incident occurs when the frequency of client requests exceeds a preset threshold within a given time period. This mechanism is used to prevent denial-of-service attacks, brute-force attempts, or abuse of automated scripts. By monitoring the number of requests made by each client connection within a fixed time window, the system can identify high-frequency accesses that significantly deviate from normal interaction patterns. Even if these requests appear syntactically and permissively legitimate, their abnormal frequency itself constitutes a potential threat, potentially intended to exhaust daemon resources, trigger chip overload, or test security boundaries. Including request frequency in the security incident detection scope demonstrates a proactive ability to detect abnormal behavior, enabling the system to defend not only against content-level attacks but also against abuse based on traffic characteristics, thereby building a more comprehensive runtime protection system.

[0084] In some embodiments of this application, the security response strategy includes at least one of the following: locking the security chip to prevent further operation, erasing the sensitive keys stored inside the security chip, recording the security event to the audit log, and sending an alarm signal to the operating system security module.

[0085] Specifically, the security response strategy includes locking the security chip to prevent further operations. This measure aims to immediately cut off all access channels to the security chip upon detecting a security incident. By sending a lock command to the security chip or having the daemon actively block communication, the system can prevent attackers from exploiting the current vulnerability to perform sensitive operations, such as key extraction, identity impersonation, or firmware tampering. The locked state typically requires a physical reset or administrator authorization to be lifted, thus buying time for emergency response, effectively curbing the spread of risk, and ensuring that the security chip resumes service in a controlled environment.

[0086] Security response strategies also include erasing sensitive keys stored internally on the security chip, which is the last line of defense for protecting core confidential information. Once it is determined that the system may have been compromised or is in an untrusted state, immediately erasing the keys can fundamentally eliminate the risk of key leakage. Even if an attacker has gained partial control, they cannot recover or utilize the destroyed cryptographic credentials. This operation is typically supported by hardware-level security mechanisms on the security chip, possessing rollback-proof and irreversible characteristics, ensuring that the erasure itself cannot be bypassed or forged, thereby maintaining the fundamental security of the entire trust system.

[0087] Logging security incidents to audit logs is a key traceability tool in security response strategies. All information triggering a security incident, including timestamps, event types, source client identifiers, operational contexts, and system states, is structured and written to protected log files. These logs not only provide reliable evidence for post-incident analysis of attack paths and assessment of impact, but can also be used for compliance reviews and security posture awareness. By storing logs in read-only or restricted access areas and employing integrity protection mechanisms, the system ensures the authenticity and non-repudiation of audit data, enabling closed-loop management of security incidents that are traceable and verifiable.

[0088] Sending alarm signals to the operating system's security module enables cross-layered security coordination and response. When the daemon identifies a high-risk event, it proactively notifies the operating system's security subsystems, such as SELinux, IMA, or trusted computing modules, through standard interfaces. This collaborative mechanism allows the entire system to take further action based on a unified security policy, such as isolating abnormal processes, restricting user privileges, triggering a full disk integrity check, or notifying a remote security management center. By bringing threat information at the security chip level to the global view of the operating system, this strategy breaks down the security silos between hardware and software, building a defense-in-depth system from the underlying chip to the upper-level application.

[0089] In some embodiments of this application, the implementation steps of a kernel-driven security chip access control method are described as follows.

[0090] During system startup, the systemd service manager (a Linux system and service management tool) loads and runs the SecCPU Guardian Daemon. This daemon serves as the sole trusted entry point in the operating system's user space, responsible for unified control over all access to the security chip. To prevent applications from bypassing the daemon and directly manipulating the underlying device nodes (such as / dev / seccpu, the character device file corresponding to the security chip in the Linux system), the kernel driver sets the permissions of this device node to 0600 (read and write only for the file owner) during the initialization phase. The owner is limited to the dedicated user seccpu, and only authorized channels are allowed for communication.

[0091] After the daemon completes initialization, it immediately creates a Unix domain socket (a local socket mechanism for efficient and secure communication between processes on the same host), binds it to a controlled path (such as / run / seccpu.sock), and sets the socket file permissions to 0660 (readable and writable by the owner and group) using the fchmod and fchown system calls (used to modify file permissions and file owner / group, respectively). The group is set to the predefined seccpugroup, ensuring that only client applications authorized to join this group (such as financial trading systems or key management systems) can establish connections.

[0092] Subsequently, the daemon process enters a listening state, waiting for client connection requests. When clients such as client A and client B initiate a connection, the daemon process receives the request through the `accept` function (used to accept incoming socket connections) and creates an independent thread for each connection. This thread calls the `client_request_deal` function to handle subsequent interactions. The thread first parses the command sent by the client (such as `CMD_CONNECT` or `CMD_WORK`), and then triggers the state transition mechanism: the daemon process queries the current state of its finite state machine (FSM, a control model that determines the next state based on the current state and input), and determines whether the command is valid according to a predefined state-operation permission mapping table.

[0093] This finite state machine comprises five states: Idle, Connecting, Working, Upgrading, and DeviceAttacked. Initially, the daemon is in the Idle state, only responding to the CMD_CONNECT command; upon receiving this command, it transitions to the Connecting state. In this state, if a CMD_WORK command is received, it enters the Working state to handle normal business (such as key generation and signature verification); if a new firmware package is detected in a specified directory and there are no active services, it automatically transitions to the Upgrading state to perform firmware verification, secure writing, and rollback preparation. The Working state allows the execution of various business commands and manual upgrade requests; the Upgrading state only processes firmware data streams; once it enters the DeviceAttacked state, all operations are rejected until the system is reset or manual intervention is required.

[0094] The security event detection mechanism is built into the daemon process and covers five dimensions: verification of the protocol format and semantic legality of client commands, compliance check of state transition paths, periodic reading of the security chip firmware hash via the kernel driver and comparison with a trusted benchmark to verify integrity, listening for abnormal signals at the SecCPU hardware layer (such as physical attack indicators like voltage or clock anomalies), and monitoring the request frequency of each client connection (using a sliding window algorithm to count the number of requests per unit time). When any detection item continuously exceeds a preset threshold (such as three consecutive protocol parsing failures or more than one hundred requests per second), it is determined to be a security event. The daemon process immediately transitions to the DeviceAttacked state and executes a preset security response strategy: calling the kernel driver's ioctl interface (input / output control, a system call used for device-specific control operations) to lock the device, erasing sensitive keys, and recording structured logs to the audit subsystem (the user-space logging service of the Linux kernel audit framework).

[0095] In each legal state, the daemon interacts with the kernel driver through standard system calls (such as ioctl, read, and write) according to business needs, performing low-level operations such as reset, serial communication, and encrypted data transmission. All operations are constrained by the state machine to ensure context safety. For command requests in illegal states, the daemon returns a standardized error code (such as ERR_ILLEGAL_STATE) and does not perform any hardware operations, thereby ensuring system stability. Throughout the entire operation, the daemon continuously records detailed logs, including state changes, command reception, security events, and driver call results, supporting fault diagnosis and compliance auditing.

[0096] Through the above mechanism, the system achieves refined, state-aware access control of the security chip, ensuring high security while also taking into account business flexibility and maintainability.

[0097] In some embodiments of this application, the daemon maintains a high-precision timestamp circular buffer for each established client connection. Whenever a client command is received, the system retrieves the current nanosecond-level timestamp and pushes it into the buffer, while simultaneously removing all historical records earlier than 1000 milliseconds (i.e., 1 second). The buffer capacity dynamically reflects the number of requests within the most recent second. If the buffer length exceeds 100 after pushing in a new timestamp, the client's triggering frequency is immediately determined to be abnormal. This sliding window mechanism avoids the counting distortion problem at the boundaries of a fixed time bucket, ensuring the real-time performance and accuracy of threshold judgment. Once the judgment is valid, the daemon records the event and triggers a state transition to the DeviceAttacked state.

[0098] In some embodiments of this application, the daemon maintains an integer error counter in each client connection context, initially set to 0. Whenever a protocol violation (including but not limited to invalid command codes, message length mismatches, and checksum failures) occurs while parsing a client command, the counter increments by 1; conversely, when any command is successfully parsed and enters a valid processing flow, the counter is immediately reset to 0. This design ensures that "continuous" refers only to a sequence of errors without a successful operation interval. If the counter value reaches 3, the daemon no longer attempts to parse subsequent commands but directly determines that a security event has occurred, executes response measures such as locking the device and erasing the key, and transitions the finite state machine to the DeviceAttacked state.

[0099] In some embodiments of this application, the SHA-256 hash algorithm is used to implement hash comparison in firmware integrity verification. Upon initial deployment, the system loads a base hash value and corresponding public key certificate, signed by the chip manufacturer using an RSA-2048 private key, from a read-only and tamper-proof secure storage area (such as the UEFI variable storage area or hardware OTP area). During operation, the daemon process calls the kernel driver interface `seccpu_get_firmware_hash()` every 24 hours to obtain the real-time SHA-256 hash of the current firmware of the security chip. Subsequently, the signature validity of the base hash is verified using a preset public key, and the real-time hash is compared byte-by-byte with the verified base value. Only when the two are inconsistent and the signature is valid is it determined that the firmware has been maliciously tampered with, thereby triggering the DeviceAttacked state transition to prevent false positives or false negatives caused by the replacement of the base data.

[0100] In some embodiments of this application, to make the upgrade prerequisite of "no active service" feasible, the daemon process introduces dual criteria: First, it maintains an atomic integer variable `active_work_count`, incrementing it by 1 each time a CMD_WORK command is started and decrementing it by 1 after the response is completed; second, it records the timestamp of the last CMD_WORK request received. When a new firmware package is detected in the Connecting state, the system first checks whether `active_work_count` is equal to 0, and then determines whether the difference between the current time and the last working time is greater than 5000 milliseconds (i.e., 5 seconds). Only when both conditions are met simultaneously is it considered "no active service," allowing the state to transition to the Upgrading state for upgrade execution. This mechanism avoids interrupting ongoing critical services and prevents frequent triggering of the upgrade process due to misjudgment caused by brief periods of idle time.

[0101] In some embodiments of this application, the dual authentication mechanism for UNIX domain socket access control includes: after accepting a client connection, the daemon immediately calls `getsockopt(client_fd, SOL_SOCKET, SO_PEERCRED,&ucred,&len)` to obtain the peer process's real user ID (UID), group ID (GID), and process ID (PID). It then verifies whether `ucred.gid` is equal to the system group ID of `seccpugroup`. Only connections that pass this credential verification are allowed to send subsequent commands. This mechanism ensures that even if an attacker gains file access permissions through privilege escalation or group membership forgery, they cannot bypass authentication based on kernel-trusted credentials.

[0102] In some embodiments of this application, the erasure of sensitive data is initiated proactively by the daemon process, rather than by the security chip itself. Specifically, upon entering the DeviceAttacked state, the daemon process sends an erase command to the kernel driver via the opened / dev / seccpu device file descriptor, calling ioctl(fd, SECCPU_IOC_ERASE_SENSITIVE_DATA, NULL). Upon receiving the ioctl, the kernel driver sends a dedicated erase command to the security chip hardware, forcibly erasing all sensitive runtime data such as temporary keys, session tokens, and random number seeds in its internal volatile storage unit, while retaining the device's unique root key and firmware code in the non-volatile storage area. After erasure, the driver returns a success status code, which the daemon process uses to confirm the operation's completion and record an audit log, ensuring the traceability and controllability of the security response.

[0103] Secondly, this application provides a security chip that integrates a processor, a secure storage unit, and a serial communication interface. The security chip is configured to work in conjunction with a daemon running in the user mode of the operating system to execute the aforementioned kernel-driven security chip access control method. Specifically, the security chip responds to commands forwarded by the daemon through the kernel driver and actively triggers a hardware-level security response when an unauthorized access attempt is detected.

[0104] The aforementioned security chip integrates a processor, secure storage unit, and serial communication interface, forming an independent and trusted execution environment with autonomous computing and security protection capabilities. The processor executes the chip's internal security logic, including command parsing, access control, encryption operations, and state management. The secure storage unit protects sensitive data, such as keys, certificates, and firmware images, through hardware isolation, preventing external reading or tampering. The serial communication interface serves as the sole physical channel for interaction with the main control system, supporting standardized protocol transmission. By integrating these core components into a single chip, the security chip achieves strong isolation from the main operating system at both the physical and logical levels, providing a solid hardware root of trust for the entire access control system.

[0105] The security chip is configured to work closely with a daemon running in the operating system's user space to jointly execute the aforementioned kernel-driven security chip access control method. This collaborative architecture places the security policy decision-making layer within the user-space daemon, while entrusting the execution and protection of sensitive operations to the security chip. This leverages the scheduling and communication capabilities provided by the operating system while avoiding the exposure of critical assets to the general computing environment. The daemon, acting as the sole legitimate agent, forwards rigorously verified commands to the security chip through the kernel driver, ensuring that all operations remain within a controlled process. This hardware-software hybrid design not only enhances overall security but also strengthens the system's flexibility and maintainability, enabling the security mechanism to evolve with policy changes without frequent hardware replacements.

[0106] The security chip can respond to commands forwarded by the daemon process via the kernel driver. This means that all calls to security functions must undergo complete software stack verification and state machine authorization before reaching the chip for execution. This mechanism eliminates the possibility of bypassing the daemon process to directly access the hardware, ensuring that commands are from a trustworthy source, have a legitimate context, and are executed in accordance with timing. Furthermore, the security chip does not passively execute instructions but continuously monitors the legitimacy of access behavior internally. Once an unauthorized access attempt is detected, such as unauthorized opcodes, unauthorized parameters, abnormal communication timing, or physical probe signals, it proactively triggers a hardware-level security response. This response may include immediately terminating the current session, erasing sensitive data, locking functional interfaces, or entering an irreversible security circuit breaker state. This effectively blocks threats at the hardware level from the very first moment an attack occurs, preventing further exploitation of vulnerabilities and truly achieving proactive defense capabilities built from the ground up.

[0107] Furthermore, refer to Figure 2 This application provides a kernel-driven security chip access control system, including the aforementioned security chip, kernel driver module, daemon process module, and multiple client applications. Wherein: The kernel driver module provides a low-level access interface to the security chip, acting as a bridge between the operating system kernel and the security chip hardware. It handles critical tasks such as device initialization, register configuration, interrupt handling, data transmission and reception, and error status reporting. This module abstracts complex hardware operations into standardized system calls or character device interfaces, eliminating the need for upper-layer software to understand the chip's specific electrical characteristics or communication protocol details. More importantly, the kernel driver exposes only controlled and limited functional entry points to user space, not directly to applications. This prevents the security chip from becoming uncontrollable due to driver abuse or misuse, laying a solid foundation for the security boundary of the entire system.

[0108] The daemon module runs in user space and is configured to execute the aforementioned methods. As the sole access proxy for the security chip, it is responsible for receiving, parsing, verifying the status of, and forwarding all client requests. This design implements centralized permission management, ensuring that all operations on the security chip must undergo a unified authentication, protocol compliance check, and finite state machine authorization process. The daemon not only isolates the application from the underlying hardware but also introduces advanced mechanisms such as session management, anomaly detection, and security event response, making it the only trusted intermediary entity in the entire system. This fundamentally eliminates the risks of concurrency conflicts, permission bypassing, and state pollution caused by multiple direct connections.

[0109] Multiple client applications communicate with the daemon module via UNIX domain sockets and are prohibited from directly accessing the security chip's device nodes. This constraint forces all business logic to be relayed through the daemon. UNIX domain sockets, as an efficient and secure local inter-process communication mechanism, provide a low-overhead data transmission channel and can be combined with file system permissions to achieve fine-grained access control. Prohibiting clients from directly manipulating device nodes completely cuts off the path to bypassing security policies. Even if malicious programs gain high privileges, they cannot bypass the daemon's state machine and auditing mechanisms to interact directly with the security chip. This architecture not only improves the overall security of the system but also enhances maintainability and scalability, allowing new applications to simply interface with the standard socket interface without needing to concern themselves with the underlying security implementation details.

[0110] In some embodiments of this application, the daemon module and the kernel driver module interact with each other through standard system calls or character device interfaces, and the kernel driver module performs a second validity check on the requests from the daemon module.

[0111] Specifically, the daemon module and the kernel driver module interact with each other via standard system calls or character device interfaces. This design ensures that communication between user space and kernel space adheres to the operating system's established security specifications and interface contracts. Standard system calls and character device interfaces are mature, stable, and controlled cross-privilege communication mechanisms provided by the operating system, effectively isolating user space and kernel space and preventing illegal memory access or privilege escalation vulnerabilities. Furthermore, these interfaces inherently support permission checks, resource management, and error handling, providing a reliable and auditable channel for the daemon process to pass commands to the kernel driver and receive responses, avoiding compatibility issues or security blind spots that might be introduced by custom communication methods.

[0112] The kernel driver module performs a secondary verification of the legitimacy of requests from the daemon module, a mechanism that forms a crucial link in the defense-in-depth system. Although the daemon, as the sole trusted proxy, has already completed protocol parsing, state machine judgment, and permission filtering in user space, the kernel driver does not completely trust its input. Instead, it independently verifies the command type, parameter range, operation context, and data integrity based on its own pre-defined security rules. This dual-verification strategy effectively prevents the risk of unauthorized command transmission due to daemon tampering, exploitation of logical flaws, or internal state anomalies. Even if an attacker manages to bypass user-space protection, the kernel-level secondary verification can still intercept malicious operations, ensuring that only truly compliant requests reach the security chip hardware, greatly enhancing the robustness and attack resistance of the entire system.

[0113] Furthermore, embodiments of this application provide a computer-readable storage medium storing a computer program thereon, which, when executed by a processor, implements the aforementioned kernel-driven security chip access control method.

[0114] In summary, the kernel driver-based security chip access control method and related devices provided in this application have the following technical effects.

[0115] This solution effectively blocks direct access from applications to underlying device nodes by deploying a daemon process in user space as the sole trusted access point for the security chip, avoiding command conflicts and state chaos caused by multi-process concurrency. It utilizes UNIX domain sockets combined with file permissions and owner control to implement a fine-grained client access control mechanism. A finite state machine is introduced to model the system's operational phases, ensuring command execution conforms to preset timing and security policies, guaranteeing the legality and atomicity of operations. Upon detecting security events such as protocol anomalies, hardware anomalies, or high-frequency requests, the system automatically transitions to an attacked device state and triggers response measures such as locking the chip, erasing keys, and recording audit logs, achieving proactive defense and rapid emergency response. Overall, this significantly improves the reliability, controllability, attack resistance, and system security of the security chip during operation.

[0116] It should be noted that in all specific embodiments of this application, all data processing activities related to user identity or personal characteristics, such as user information, user behavior data, historical data, and location information, will be conducted in accordance with the principles of legality, legitimacy, and necessity. All data collection, use, storage, and processing will be subject to compliance with applicable national and regional laws, regulations, and industry standards, and informed consent from users will be obtained in a clear and explicit manner before processing. For the processing of sensitive personal information, separate consent from users will be obtained through prominent means such as pop-up prompts and independent confirmation pages. If any processing conflicts with laws and regulations, the laws and regulations will prevail, and necessary data processing will only be carried out within the scope permitted by laws and regulations, ensuring that all data-based applications, analyses, and technical implementations are conducted within the scope permitted by laws and regulations.

[0117] In some alternative embodiments, the functions / operations mentioned in the block diagrams may not occur in the order shown in the operation diagrams. For example, depending on the functions / operations involved, two consecutively shown blocks may actually be executed substantially simultaneously, or the blocks may sometimes be executed in reverse order. Furthermore, the embodiments presented and described in the flowcharts of this application are provided by way of example to provide a more comprehensive understanding of the technology. The disclosed methods are not limited to the operations and logic flows presented herein. Alternative embodiments are contemplated in which the order of various operations is changed and sub-operations described as part of a larger operation are executed independently.

[0118] Furthermore, although this application is described in the context of functional modules, it should be understood that, unless otherwise stated, one or more of the functions and / or features may be integrated into a single physical device and / or software module, or one or more functions and / or features may be implemented in a separate physical device or software module. It is also understood that a detailed discussion of the actual implementation of each module is unnecessary for understanding this application. Rather, given the properties, functions, and internal relationships of the various functional modules in the apparatus disclosed herein, the actual implementation of the module will be understood within the scope of ordinary skill of an engineer. Therefore, those skilled in the art can implement the application set forth in the claims using ordinary skill. It is also understood that the specific concepts disclosed are merely illustrative and are not intended to limit the scope of this application, which is determined by the full scope of the appended claims and their equivalents.

[0119] If a function is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this invention, or the part that contributes to the prior art, or a part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several programs to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0120] The logic and / or steps represented in the flowchart or otherwise described herein, for example, can be considered as a sequential list of executable programs for implementing logical functions, and can be embodied in any computer-readable medium for use by, or in conjunction with, a program execution system, apparatus, or device (such as a computer-based system, a processor-included system, or other system that can retrieve and execute a program from or in conjunction with such a program execution system, apparatus, or device). For the purposes of this specification, "computer-readable medium" can mean any means that can contain, store, communicate, propagate, or transmit a program for use by or in conjunction with a program execution system, apparatus, or device.

[0121] More specific examples (a non-exhaustive list) of computer-readable media include: electrical connections (electronic devices) having one or more wires, portable computer disk drives (magnetic devices), random access memory (RAM), read-only memory (ROM), erasable and editable read-only memory (EPROM or flash memory), fiber optic devices, and portable optical disc read-only memory (CDROM). Additionally, computer-readable media can even be paper or other suitable media on which programs can be printed, for example, by optically scanning the paper or other media, then editing, interpreting, or, if necessary, processing it in a suitable manner to obtain the program electronically, and then storing it in computer memory.

[0122] It should be understood that various parts of the present invention can be implemented in hardware, software, firmware, or a combination thereof. In the above embodiments, multiple steps or methods can be implemented in software or firmware stored in memory and executed by a suitable program execution system. For example, if implemented in hardware, as in another embodiment, it can be implemented using any one or a combination of the following techniques known in the art: discrete logic circuits having logic gates for implementing logical functions on data signals, application-specific integrated circuits (ASICs) having suitable combinational logic gates, programmable gate arrays (PGAs), field-programmable gate arrays (FPGAs), etc.

[0123] In the foregoing description of this specification, the reference to terms such as "one embodiment / implementation," "another embodiment / implementation," or "certain embodiments / implementations," etc., indicates that a specific feature, structure, material, or characteristic described in connection with an embodiment or example is included in an embodiment or example of the present invention. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples.

[0124] Although embodiments of the invention have been shown and described, those skilled in the art will understand that various changes, modifications, substitutions and alterations can be made to these embodiments without departing from the principles and spirit of the invention, the scope of which is defined by the claims and their equivalents.

[0125] The above is a detailed description of the preferred embodiments of the present invention. However, the present invention is not limited to the embodiments. Those skilled in the art can make various equivalent modifications or substitutions without departing from the spirit of the present invention. All such equivalent modifications or substitutions are included within the scope defined by the claims of the present invention.

Claims

1. A kernel-driven method for secure chip access control, characterized in that, Includes the following steps: A daemon process is started and runs in the user space of the operating system. This daemon process serves as the only trusted access point for the security chip, prohibiting applications from directly accessing the underlying device nodes of the security chip. The daemon process creates a UNIX domain socket and binds the UNIX domain socket to a specified path in the file system; By using permission setting system calls and owner setting system calls, the file access permissions for the specified path are configured so that only pre-authorized applications can initiate connection requests through the UNIX domain socket. The daemon process maintains a finite state machine; When a client command is received, the daemon process determines whether the command is allowed to be executed based on the current state of the finite state machine: if allowed, it communicates with the security chip through the kernel driver and returns the result; otherwise, it rejects the command. During operation, if a security event is detected, the finite state machine is triggered to transition to the attacked state of the device and execute the preset security response strategy.

2. The kernel-driven security chip access control method as described in claim 1, characterized in that, The finite state machine includes at least an idle state, a connected state, a working state, an upgrade state, and a device under attack state, and defines legal transition paths between each state; The state transition rules of the finite state machine include: The system is in an idle state after initialization is complete; The state can only transition from idle to connected. The device transitions from the connected state to the working state after completing the security chip handshake authentication, or to the upgrade state after receiving an upgrade command. The device transitions from an operational state to an upgraded state upon receiving a legitimate upgrade request, or to an attacked state upon detecting a security incident. When the device is under attack, all client commands will be rejected until the system is reset or an administrator intervenes.

3. The kernel-driven security chip access control method as described in claim 1, characterized in that, The daemon process creates an independent processing thread for each client connection and calls the kernel driver interface through a message sending function. The kernel driver provides functions for resetting the security chip, serial data transmission and reception, and error status reading.

4. The kernel-driven security chip access control method as described in claim 1, characterized in that, In the upgrade state, the daemon process loads the firmware upgrade package from the preset security directory, writes the firmware upgrade package into segments to the security chip through the kernel driver, updates the version information after successful verification, and then migrates back to the working state. If the verification fails, the device will roll back to its pre-upgrade state and enter a vulnerable state.

5. The kernel-driven security chip access control method as described in claim 1, characterized in that, The UNIX domain socket is a stream socket, and the specified path is located in a protected directory, the access permissions of which are uniformly managed by the system security policy.

6. The kernel-driven security chip access control method as described in claim 1, characterized in that, The security event includes any of the following: invalid client command protocol format, firmware integrity verification failure, security chip returning hardware abnormal signal, or client request frequency exceeding a preset threshold within a unit of time. The security response strategy includes at least one of the following: locking the security chip to prevent further operations, erasing the sensitive keys stored inside the security chip, recording the security event to the audit log, and sending an alarm signal to the operating system security module.

7. A security chip integrating a processor, a secure storage unit, and a serial communication interface, characterized in that, The security chip is configured to work in conjunction with a daemon running in the user mode of the operating system to execute the kernel-driven security chip access control method as described in any one of claims 1 to 6. The security chip responds to commands forwarded by the daemon process via the kernel driver and actively triggers a hardware-level security response when an unauthorized access attempt is detected.

8. A kernel-driven security chip access control system, characterized in that, include: The security chip as described in claim 7; The kernel driver module provides a low-level access interface to the security chip. The daemon module runs in user space and is configured to execute the kernel driver security chip access control method as described in any one of claims 1 to 6, serving as the sole access proxy for the security chip. The client application communicates with the daemon module via UNIX domain sockets and must not directly access the device node of the security chip.

9. The kernel-driven secure chip access control system as described in claim 8, characterized in that, The daemon module and the kernel driver module interact with each other through standard system calls or character device interfaces. The kernel driver module performs a second validity check on requests from the daemon module.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by the processor, it implements the kernel-driven secure chip access control method as described in any one of claims 1 to 6.

Images