Offline identity verification method based on CPU card, terminal, CPU card and system

Abstract

The invention provides an off-line identity verification method and system based on a CPU card, a terminal and the CPU card. The method comprises the steps of obtaining an encrypted data packet, current verification time and a verification scene type of a CPU card; reading an encrypted data packet, wherein the encrypted data packet comprises a ciphertext obtained by encrypting identity information and authority rule data of a cardholder according to a preset encryption algorithm and a key; decrypting the encrypted data packet to obtain plaintext identity information and plaintext permission rule data of the cardholder; performing off-line verification on the plaintext identity information and the plaintext permission rule data according to the current verification time and the verification scene type to obtain an off-line verification result; if the offline verification result represents that the plaintext identity information and the plaintext permission rule data meet the preset identity verification requirements, an offline verification log is generated, and the offline identity verification method for the cardholder is completed, so that offline rapid verification and dynamic permission management and storage of the cardholder identity are realized, and the offline verification efficiency and accuracy are improved.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of identity recognition, and in particular to an offline identity verification method based on a CPU card, a terminal, a CPU card and a system. BACKGROUND

[0002] As a key infrastructure of the power system, the safe operation of a substation is directly related to the stability of the power grid and social public safety. Construction personnel entering a substation need to go through strict qualification audits, including qualification certification and safety regulation examination of the work ticket issuer and the work supervisor, which can effectively improve the standardization, real-time performance and data management capability of the personnel access to substations, and is of great significance to the safety of the power industry.

[0003] Under the traditional management mode, the auditing of external construction personnel mainly relies on manual operation and paper file management. The construction personnel need to carry paper certificates and complete the access process by manually checking the white list and qualification certificates.

[0004] However, the paper list updating and checking efficiency is low, and the paper list is tampered with and has low security, which reduces the reliability and efficiency of the control of construction personnel. SUMMARY

[0005] The present application provides an offline identity verification method based on a CPU card, a terminal, a CPU card and a system to solve the technical problem that the paper list updating and checking efficiency is low in the existing verification technology, and the paper list is tampered with and has low security, which reduces the reliability and efficiency of the control of construction personnel.

[0006] In a first aspect, an offline identity verification method based on a CPU card is provided, comprising:

[0007] obtaining an encrypted data packet of a CPU card, a current verification time and a verification scene type;

[0008] reading the encrypted data packet, wherein the encrypted data packet includes ciphertext obtained by encrypting the identity information of a cardholder and the permission rule data according to a preset encryption algorithm and a key;

[0009] decrypting the encrypted data packet to obtain the plaintext identity information of the cardholder and the plaintext permission rule data;

[0010] performing offline verification on the plaintext identity information and the plaintext permission rule data according to the current verification time and the verification scene type to obtain an offline verification result;

[0011] if the offline verification result indicates that the plaintext identity information and the plaintext permission rule data meet a preset identity verification requirement, generating an offline verification log to complete the offline identity verification of the cardholder.

[0012] Further, before obtaining the encrypted data packet of the CPU card, the current verification time and the verification scene type, the method further comprises:

[0013] Obtaining a preset white list;

[0014] According to the preset white list, determining the identity information, the permission data and the time stamp of the current time of the target cardholder;

[0015] According to the identity information and the permission data of the target cardholder, and the time stamp, performing encryption processing to generate a dynamic key;

[0016] According to the dynamic key and a preset encryption algorithm, respectively encrypting the identity information and the permission data of the target cardholder to obtain an encrypted data packet.

[0017] Further, decrypting the encrypted data packet to obtain the plaintext identity information and the plaintext permission rule data of the cardholder, comprising:

[0018] According to the preset encryption algorithm, determining the identity decryption key and the permission decryption key of the encrypted data packet;

[0019] According to the identity decryption key, decrypting the identity information of the cardholder in the encrypted data packet to obtain the plaintext identity information of the cardholder;

[0020] According to the permission decryption key, decrypting the permission information of the cardholder in the encrypted data packet to obtain the plaintext permission rule data of the cardholder.

[0021] Further, according to the current verification time and the verification scene type, performing offline verification on the plaintext identity information and the plaintext permission rule data to obtain an offline verification result, comprising:

[0022] Obtaining preset white list information, wherein the preset white list information is deployed with list information of completed identity registration;

[0023] Performing offline identity verification on the preset white list information and the plaintext identity information to obtain an identity verification result;

[0024] According to the plaintext permission rule data, determining the effective time interval and the scene list defined by the plaintext permission rule data;

[0025] Verifying and comparing the current verification time with the effective time interval, and verifying and comparing the verification scene type with the scene list to obtain a permission verification result;

[0026] According to the identity verification result and the permission verification result, obtaining an offline verification result.

[0027] Further, if the offline verification result represents that the plaintext identity information and the plaintext permission rule data meet the preset identity verification requirement, an offline verification log is generated, and the offline identity verification of the cardholder is completed, including:

[0028] According to the offline verification result, an identity verification result and a permission verification result are determined;

[0029] If the identity verification result and the permission verification result both meet the preset identity verification requirement, card identification information of the CPU card is determined;

[0030] The card identification information, the current verification time, the verification scene type, and the offline verification result are associated to obtain a verification record of the CPU card;

[0031] According to the verification record of the CPU card, an offline verification log is generated, and the offline identity verification of the cardholder is completed.

[0032] Further, after the offline verification of the plaintext identity information and the plaintext permission rule data is performed according to the current verification time and the verification scene type, and an offline verification result is obtained, the method further includes:

[0033] If the identity verification result represents that the preset whitelist information does not match the plaintext identity information, and / or the permission verification result represents that the current verification time does not match the valid time interval, and the verification scene type does not match the scene list, an offline verification failure result is generated;

[0034] According to the offline verification failure result, an abnormal event mark and an abnormal prompt are generated;

[0035] According to the abnormal event mark and the abnormal prompt, an early warning process of the identity information and the permission data of the cardholder is completed.

[0036] Further, after the encrypted data packet is decrypted to obtain the plaintext identity information and the plaintext permission rule data of the cardholder, the method further includes:

[0037] Obtaining preset list information, the preset list information being deployed with cardholder identity information that has been subjected to invalidation processing;

[0038] The plaintext identity information of the cardholder is compared with the preset list information to obtain a comparison result;

[0039] If the comparison result represents that the plaintext identity information matches the preset list information, an abnormal event mark and an abnormal prompt are generated;

[0040] According to the abnormal event mark and the abnormal prompt, the pre-warning processing on the identity information and the permission data of the cardholder is completed.

[0041] In a second aspect, the application provides an offline identity verification terminal based on a CPU card, comprising:

[0042] An information acquisition module is configured to acquire an encrypted data packet of the CPU card, a current verification time, and a verification scene type;

[0043] An encrypted information reading module is configured to read the encrypted data packet, wherein the encrypted data packet comprises ciphertext obtained by encrypting identity information and permission rule data of the cardholder according to a preset encryption algorithm and a key;

[0044] A decryption module is configured to decrypt the encrypted data packet to obtain plaintext identity information and plaintext permission rule data of the cardholder;

[0045] An offline verification module is configured to perform offline verification on the plaintext identity information and the plaintext permission rule data according to the current verification time and the verification scene type to obtain an offline verification result;

[0046] A verification completion module is configured to generate an offline verification log if the offline verification result indicates that the plaintext identity information and the plaintext permission rule data meet preset identity verification requirements, thereby completing offline identity verification on the cardholder.

[0047] In a third aspect, the application provides a CPU card for offline identity verification, comprising a memory and a processor.

[0048] The memory stores an encrypted data packet.

[0049] The processor executes computer execution instructions stored in the memory, so that the processor executes the method of any one of the first aspect.

[0050] In a fourth aspect, the application provides an offline identity verification system based on a CPU card, comprising an offline identity verification terminal based on a CPU card, a CPU card for offline identity verification, and a computer program.

[0051] The computer program is executed by the processor to implement the method of any one of the first aspect.

[0052] The CPU card-based offline identity verification method, terminal, CPU card and system provided by the embodiments of the present application obtain the encrypted data packet, the current verification time and the verification scene type of the CPU card, read the encrypted data packet, the encrypted data packet includes the ciphertext obtained by encrypting the identity information and the permission rule data of the cardholder according to a preset encryption algorithm and a key, decrypt the encrypted data packet to obtain the plaintext identity information and the plaintext permission rule data of the cardholder, perform offline verification on the plaintext identity information and the plaintext permission rule data according to the current verification time and the verification scene type to obtain an offline verification result, and if the offline verification result indicates that the plaintext identity information and the plaintext permission rule data meet preset identity verification requirements, generate an offline verification log to complete the method of offline identity verification of the cardholder, realize offline fast verification, dynamic permission management and storage of the identity of the cardholder, and improve the efficiency and accuracy of offline verification. BRIEF DESCRIPTION OF DRAWINGS

[0053] The accompanying drawings, which are incorporated herein and form a part of the specification, illustrate the embodiments of the present application and, together with the description, serve to explain the principles of the present application.

[0054] Figure 1 A flowchart of the first embodiment of the CPU card-based offline identity verification method provided by the present application is shown in the figure.

[0055] Figure 2 A flowchart of the second embodiment of the CPU card-based offline identity verification method provided by the present application is shown in the figure.

[0056] Figure 3 A flowchart of the third embodiment of the CPU card-based offline identity verification method provided by the present application is shown in the figure.

[0057] Figure 4 A structural diagram of the CPU card-based offline identity verification device provided by the present application is shown in the figure.

[0058] Figure 5 A structural diagram of the CPU card for offline identity verification provided by the present application is shown in the figure.

[0059] The specific embodiments of the present application have been shown in the above figures, and will be described in more detail hereinafter. These figures and textual descriptions are not intended to limit the scope of the concept of the present application by any means, but to illustrate the concept of the present application to those skilled in the art by referring to specific embodiments. DETAILED DESCRIPTION

[0060] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application as detailed in the appended claims.

[0061] The technical solution of this application is mainly applied to personnel access management scenarios in power system substations, specifically including: Construction personnel access verification: At the substation entrance, encrypted information in the CPU card of construction personnel is read via a mobile card reader and compared with a locally stored whitelist and qualification validity period to quickly complete identity verification; Work permit processing: Operation personnel verify the safety compliance assessment records and "two types of personnel" qualifications of construction personnel via mobile terminals to ensure operational compliance; Data recording and analysis: The system automatically generates time-stamped card-swipe logs, supporting subsequent access control audits, abnormal behavior tracing, and multi-dimensional data analysis (such as time-period traffic analysis and personnel classification management). The network architecture of this solution is a standalone offline mode, with all data processing completed locally without relying on external network communication, thus avoiding network attack issues and meeting the high security requirements of physical isolation in substations.

[0062] Based on the above scenarios, it can be seen that in the existing technology, the traditional manual verification mode is adopted, and the specific process is as follows: (1) Whitelist reporting and review: The construction unit submits the list of external construction personnel (including ID card, professional qualification certificate, etc.) to the operation management department. After the operation department reviews it, a paper whitelist is formed and distributed to the station manager and security personnel of each substation; (2) On-site verification: After the construction personnel arrive at the station, they need to show their ID card. The security guard manually verifies the identity through the paper whitelist. After the station manager confirms that there is no error, the passage is approved; (3) Work permit processing: The operation personnel need to verify the safety regulations assessment records of the external construction personnel and the validity period of the "two types of personnel" qualifications. After confirming that the requirements are met, the work permit is processed.

[0063] To address the aforementioned technical challenges, this application constructs a network-independent personnel security management system through a collaborative design based on an encrypted CPU card and an offline mobile terminal. This system enables rapid verification of personnel identities, dynamic access control, and electronic data storage. The solution, centered on a physical encryption chip and combined with standardized communication protocols and localized data processing capabilities, solves the problems of low efficiency and difficulty in data traceability associated with traditional manual verification. Its key technical advantage lies in combining hardware encryption with offline processing to ensure system authentication and access control even in network-free environments. Simultaneously, electronic recording ensures data traceability and analyzability, providing a cost-effective and secure alternative for high-security scenarios in power systems.

[0064] The technical solution of this application and how the technical solution of this application solves the above-mentioned technical problems are described in detail below with specific embodiments. These specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments. The embodiments of this application will now be described with reference to the accompanying drawings.

[0065] Figure 1 This is a flowchart illustrating an embodiment of the CPU card-based offline identity verification method provided in this application. Figure 1 As shown, the method includes:

[0066] S101. Obtain the encrypted data packet, current verification time, and verification scenario type of the CPU card.

[0067] This step triggers and initiates the offline identity verification process. The encrypted data packet refers to the encrypted data block read from the card's security chip storage area by the verification terminal's card reader module, which establishes communication with the contactless CPU card via radio frequency (e.g., 13.56MHz). It's important to note that obtaining the encrypted data packet is not simply reading the card number, but rather reading a ciphertext data packet containing identity and authorization information.

[0068] The current verification time refers to the time provided by the local real-time clock module of the verification terminal. This ensures the independence and accuracy of time determination and does not rely on network authorization, thus enabling time determination in offline mode.

[0069] Verification scenario type refers to a preset parameter. For example, for fixed terminals (such as substation gates), the verification scenario type is the access control that was set when the gate was installed; for portable terminals, it can be a scenario selected by the operator when starting a task, such as "work ticket processing - transformer maintenance".

[0070] Prior to this application step, the cardholder generates and initializes the encrypted CPU card, which is usually performed on the back-end management terminal and is a prerequisite and foundation for the verification process.

[0071] Specifically, this includes: obtaining a preset whitelist, determining the target cardholder's identity information, permission data, and current timestamp. For example, the administrator selects the target cardholder from the personnel database in the software interface of the backend management terminal; then, they retrieve the person's identity information (e.g., employee ID, name, department) and their configured permission data (e.g., list of allowed substations, validity period, job type permissions, etc.). This information collectively constitutes the cardholder's "authorization information" and is associated with the system's preset whitelist. This step achieves centralized and digital management of permissions, ensuring the authority and uniformity of the permission source, laying the foundation for subsequent encryption and distribution.

[0072] Furthermore, to enhance security and avoid potential issues arising from the use of fixed keys, this application employs a dynamic key generation mechanism. Specifically, a dynamic key is generated by encrypting the target cardholder's identity information, authorization data, and timestamp.

[0073] For example, the current time's timestamp (accurate to milliseconds) is obtained; the target cardholder's identity information, authorization data, and the timestamp are combined to form a unique data string; this data string is processed using a key derivation function (e.g., KDF based on SM3 or SHA-256) or a specific encryption algorithm to generate a dynamic key. This dynamic key will be specifically used to encrypt the cardholder's card issuance data for this instance. Through this step, even if multiple cards are issued to the same person, the generated encryption key will be different each time due to the different timestamps, greatly improving security; in addition, the dynamic key is bound to the card issuance time, increasing the difficulty for attackers to perform replay attacks using old data packets; more importantly, the key is generated from the cardholder's specific information, achieving a strong binding between the key and the data.

[0074] Furthermore, based on the dynamic key and a preset encryption algorithm, the target cardholder's identity information and authorization data are encrypted separately to obtain an encrypted data packet. For example, a preset encryption algorithm (such as the national standard SM4 or AES) is used, along with the dynamic key generated in the previous step, to encrypt the identity information and authorization data separately. In this step, the data can be encrypted separately and then packaged, or the two can be combined into a single encrypted data packet. Finally, the encrypted ciphertext, along with necessary auxiliary information (such as algorithm identifier and version number), is assembled into the final encrypted data packet. This step utilizes a dynamic key and a standard encryption algorithm to ensure that the information stored on the card cannot be cracked even if physically extracted. Furthermore, the encryption process ensures that the data is not tampered with after being written to the card, thus improving the security of the encrypted data packet.

[0075] S102. Read the encrypted data packet and decrypt it to obtain the cardholder's plaintext identity information and plaintext permission rule data.

[0076] This step is the core data processing stage in the verification process. Its core lies in using an independent and isolated decryption key mechanism to process identity information and permission information separately, so as to achieve fine-grained security control and operational flexibility.

[0077] Specifically, after verifying the CPU card's legitimacy, the verification terminal's security processing module reads the complete encrypted data packet from the designated storage area of ​​the CPU card's security chip. This data packet was encapsulated during the card manufacturing stage (as described in S101) using a preset encryption algorithm (such as SM4 or AES) and an independent key to encrypt the identity and authorization information separately.

[0078] Then, based on the preset encryption algorithm, the identity decryption key and the authorization decryption key of the encrypted data packet are determined. For example, the verification terminal obtains two independent keys from the protected storage area of ​​its security chip, namely the identity decryption key and the authorization decryption key, according to the type of preset encryption algorithm; wherein, the identity decryption key is specifically used to decrypt the cardholder's identity information part, and the authorization decryption key is specifically used to decrypt the cardholder's authorization rule data part.

[0079] Next, an independent decryption operation for identity and permissions is performed. That is, based on the identity decryption key, the cardholder's identity information in the encrypted data packet is decrypted to obtain the cardholder's plaintext identity information. For example, the security processing module uses the identity decryption key to decrypt the ciphertext segment corresponding to the identity information in the encrypted data packet to restore the plaintext identity information (e.g., {Employee ID: "1001", Name: "Zhang San", Department: "Operations Department"}).

[0080] Simultaneously, based on the authorization decryption key, the cardholder's authorization information in the encrypted data packet is decrypted to obtain the cardholder's plaintext authorization rule data. For example, the security processing module uses the authorization decryption key to decrypt the ciphertext segment of the corresponding authorization rule in the encrypted data packet to restore the plaintext authorization rule data (e.g., {Validity period: "2024-01-01 to 2024-12-31", Authorization scenario: ["Substation A, Substation B"], Operation level: "Inspection"}).

[0081] This step employs independent identity decryption keys and permission decryption keys. Through key isolation, permission separation, and flexible management, the entire system is endowed with stronger adaptability, maintainability, and defense-in-depth capabilities while ensuring the security of core processes. This is one of the key technical features of this invention in achieving the goals of "high security" and "refined permission management".

[0082] S103. Based on the current verification time and verification scenario type, perform offline verification of plaintext identity information and plaintext permission rule data to obtain offline verification results.

[0083] In this step, offline verification means that the entire verification process does not require querying any remote server and is completed entirely on the terminal. The offline verification process is based on the matching relationship between the decrypted plaintext information and the current verification time and verification scenario type.

[0084] After obtaining the offline verification result in this step, a result indicating that the offline verification failed will also be generated. When the offline verification result fails, an anomaly handling and early warning mechanism needs to be executed. The purpose is to immediately block illegal or unauthorized behavior, leave clear audit clues and on-site alarms, and control potential security threats in their infancy.

[0085] For example, if the decrypted plaintext identity information (such as employee number) does not appear in the preset whitelist information stored locally on the verification terminal, this indicates that the cardholder may not be a registered user of the system, or their card may have been cancelled / reported lost. Alternatively, the current verification time may not be within the valid time range defined by the permission rules (e.g., non-working hours, expired permissions), or the current verification scenario type (e.g., "Substation #3 Main Control Room") may not be within the range allowed by the permission rule scenario list. In this case, offline verification fails, and a structured "Offline Verification Failure Result" object can be generated. This object not only contains a simple "failure" status but also encapsulates specific failure reason codes (e.g., identity mismatch, invalid time, unauthorized scenario).

[0086] Then, based on the offline verification failure results, an anomaly event marker and anomaly message are generated. For example, an anomaly event marker is created, which is a record containing detailed contextual information, typically including: the trigger time, the CPU card identifier used (the card number can be recorded even if the identity does not match), the verification scenario, the specific failure reason code, and the device ID of the verification terminal. This marker is the "data source" and "audit core" for all subsequent processing actions, providing irrefutable electronic evidence for this anomaly event. Additionally, based on the failure reason, anomaly message information is generated for on-site personnel and / or on-site management personnel. For example, immediately triggering a flashing red alarm light and a rapid, continuous beeping sound on the verification terminal to directly attract the attention of surrounding personnel; or displaying the specific failure reason on the verification terminal's screen in a prominent color (such as red), such as: no access permission or card expired.

[0087] Finally, based on the abnormal event markers and abnormal prompts, the system completes the early warning processing for the cardholder's identity information and access control data. For example, in access control systems, the electronic lock remains closed; in work ticket systems, the process is interrupted, and further operations are not permitted.

[0088] This step embodies the "proactive management" concept of this application, solving the problem of "what to do if it fails". Furthermore, it uses technical means to transform a failed verification attempt into an effective security incident record and on-site proactive defense action, significantly improving the operation and maintenance management capabilities of the entire offline verification process.

[0089] S104. If the offline verification result indicates that the plaintext identity information and plaintext permission rule data meet the preset identity verification requirements, then an offline verification log is generated to complete the offline identity verification of the cardholder.

[0090] Specifically, based on the offline verification results, the identity verification result and the permission verification result are determined. The identity verification result confirms the authenticity of the card and the legality of the cardholder's identity (e.g., successful decryption and correct identity information format). The permission verification result is used to perform logical judgments based on the decrypted plaintext permission rule data (e.g., "Allowed entry to the 220kV distribution area, valid: weekdays 8:00-18:00"), the current verification time (e.g., "2023-10-27 14:30"), and the verification scenario type (e.g., "Access Control Point - 220kV Distribution Area Gate"). In this embodiment, when the current time is determined to be within the validity period and the scenario matches the permission, the permission verification result is "Passed".

[0091] Secondly, in this embodiment of the application, identity verification is considered successful only when both of the above results are passed. That is, when both the identity verification result and the authorization verification result meet the preset identity verification requirements, the card identification information of the CPU card is determined. For example, unique card identification information such as the card serial number is read from the CPU card or extracted from the decrypted information.

[0092] Based on the above verification results, a structured data record is created, which associates the card identification information, the current verification time, the verification scenario type, and the offline verification result, and adds a timestamp to complete a full digital snapshot of a verification event.

[0093] Finally, the verification records are appended to a specific log file in the secure storage module of the offline verification terminal, thus generating an offline verification log. This step signifies that the offline identity verification has been completed at both the logical and logging levels, meaning the offline identity verification of the cardholder is complete.

[0094] In addition, in this embodiment of the application, after the offline identity verification of the cardholder is completed, an offline identity verification success prompt can be generated on the verification terminal, and control operations corresponding to the verification scenario type can be executed, such as controlling the access control device to open, and displaying the offline identity verification success prompt and the cardholder's plaintext identity information through a visual interface.

[0095] This application's embodiment generates structured logs by associating identifiers, time, scenarios, and verification results, achieving a complete closed loop for offline verification. This design not only ensures that each authorized access is recorded electronically without alteration, strengthening security auditing and accountability capabilities, but also improves verification accuracy through a dual "identity + permission" verification mechanism, providing crucial support for refined and reliable management in offline environments.

[0096] Figure 2 This is a flowchart illustrating Embodiment 2 of the CPU card-based offline identity verification method provided in this application. Figure 2 As shown, based on Example 1, according to the current verification time and verification scenario type, plaintext identity information and plaintext permission rule data are verified offline to obtain offline verification results, including:

[0097] S201. Obtain preset whitelist information.

[0098] The preset whitelist information contains a list of individuals or cards that have completed identity registration. For example, the offline verification terminal reads the pre-deployed "pre-deployed whitelist information" from its internal secure storage module. This whitelist is updated offline during system initialization or periodically via secure means (such as an administrator using an authorization card), and contains basic identification information (such as employee ID, card number hash value, etc.) of all personnel or cards that have completed formal identity registration and are authorized for verification within the terminal's jurisdiction.

[0099] This step is used to establish a localized, trusted "access personnel database," which serves as the benchmark for identity verification in offline environments.

[0100] S202. Perform offline identity verification between the preset whitelist information and the plaintext identity information to obtain the identity verification result.

[0101] In this step, the key identifier fields in the plaintext identity information (e.g., employee name, employee number) obtained from the CPU card will be compared with the local preset whitelist information to check whether the cardholder is on the system's recognized legitimate list.

[0102] This step of identity verification ensures that even if the card itself is a genuine CPU card and can be successfully decrypted, it will be directly rejected if the cardholder is not on the whitelist (e.g., a former employee or an unrelated external person), effectively preventing the problem of "legitimate cards being held by unauthorized persons".

[0103] S203. Based on the plaintext permission rule data, determine the effective time interval and scenario list limited by the plaintext permission rule data.

[0104] This step can parse the plaintext permission rule data decrypted from the CPU card, which clearly defines the details of the permissions granted to the card, including the effective time range, such as "2024-01-01 to 2024-12-31, 08:00-18:00 daily"; and the scenario list, such as the "area list" that is allowed to enter (e.g., "main control room", "10kV switchyard") or the "business type list" that is allowed to be handled (e.g., "first type of work ticket", "inspection permission").

[0105] This step transforms abstract permission data into specific parameters that can be used for logical judgment, preparing for refined verification.

[0106] S204. Verify and compare the current verification time with the valid time interval, and verify and compare the verification scenario type with the scenario list to obtain the permission verification result.

[0107] This step compares the current verification time (card reading time) with the valid time interval in the permission rules to determine whether the current time is within the allowed time range; and compares the current verification scenario type (for example, the card reader is installed at the entrance of "10kV switchyard") with the scenario list in the permission rules to determine whether the card is authorized to enter this specific area or perform this service.

[0108] This step allows for the verification of the validity and scope of permissions. It enables precise control over "who, when, and where (or what) they can do."

[0109] S205. Based on the identity verification result and the permission verification result, obtain the offline verification result.

[0110] In this step, the identity verification result (S202) and the permission verification result (S204) can be combined to generate the final offline verification result. Typically, only if both results are "passed" is the final verification considered successful; if either result is "failed," the final verification fails.

[0111] This step ensures the rigor and security of the verification strategy by performing an AND operation on the results of the two independent processes of identity verification and permission verification through the execution of the final authorization decision logic.

[0112] This application's embodiment employs a two-layer verification mechanism combining "whitelist identity verification" and "spatiotemporal dynamic permission matching" to ensure the legitimacy of the cardholder's identity. Furthermore, by parsing and comparing time and scenario constraints in the permission rules, it achieves precise spatiotemporal control over personnel access and business transactions. This design upgrades the traditional "one card for all" access control system to "one card, one policy; one time, one policy; one location, one policy," significantly enhancing the initiative and intelligence of security management in scenarios without network support. Technically, it eliminates unauthorized access and time-out violations, representing the core technological manifestation of this invention's shift from "passive verification" to "proactive management."

[0113] Figure 3 This is a flowchart illustrating Embodiment 3 of the CPU card-based offline identity verification method provided in this application. Figure 3As shown, based on Example 1, after offline verification of plaintext identity information and plaintext permission rule data according to the current verification time and verification scenario type, and obtaining the offline verification result, the method further includes:

[0114] S301. Obtain preset list information.

[0115] The preset list includes the identity information of cardholders whose cards have been deactivated. Specifically, the offline verification terminal reads another set of key data—the "list"—from its secure storage module. This list is independent of the whitelist and specifically records information about individuals whose identities have been registered but whose current status has been marked as "deactivated" or "prohibited" (e.g., individuals added to the prohibited list by the administrator due to reasons such as resignation, job transfer, disciplinary violations, or card loss).

[0116] This step involves establishing a localized "real-time problem personnel database." This is crucial for addressing dynamic security management needs, enabling the identification and blocking of known problematic individuals even when the endpoint is offline.

[0117] S302. Compare the cardholder's plaintext identity information with the preset list information to obtain the comparison result.

[0118] In this step, the plaintext identity information of the cardholder (such as employee ID and name) that has been decrypted and verified from the CPU card is quickly compared with the local preset list information. It checks whether the "legitimate" cardholder also appears on the prohibited access list.

[0119] This step is an additional management policy review that is applied after identity and permissions have been technically verified. It resolves the contradictory scenario of "technical legality but management illegality".

[0120] S303. If the comparison result indicates that the plaintext identity information matches the preset list information, an abnormal event marker and an abnormal prompt will be generated.

[0121] In this step, if the comparison finds that the cardholder's information exists in the list (i.e., a "match"), the following actions will be performed immediately:

[0122] (1) Generate an exception event marker: Add a special “list alert” tag to this verification record. This marker will be associated with the verification log generated in S104.

[0123] (2) Generate abnormal prompts: trigger clear local alarms, such as: displaying a red "No Entry - List Personnel" warning on the terminal screen, issuing a rapid alarm sound, flashing indicator lights, etc.

[0124] This step enables real-time visualization of problems and event characterization, clearly identifying a common "verification failure" as a "security warning event" requiring high attention, providing a clear classification basis for subsequent handling and auditing.

[0125] S304. Based on the abnormal event markers and abnormal prompts, complete the early warning processing of the cardholder's identity information and authorization data.

[0126] This step executes a preset early warning process based on abnormal event markers and abnormal prompts. For example, regardless of the previous permission verification results, when an abnormal event marker and abnormal prompt appear, any door opening or authorization operation is immediately denied; then, a more detailed "list of alarm trigger records" is generated than a regular log, including on-site photos (if the terminal has a camera), records of multiple card reading attempts, etc.; finally, a wider-area on-site warning is issued through an audible and visual alarm connected to the verification terminal.

[0127] This step completes the closed-loop process from problem detection to problem handling, ensuring that the list policy is strictly enforced by the terminal and proactively exposes problems, alerting on-site personnel or security forces to intervene, thereby controlling potential security threats in their infancy.

[0128] The offline list mechanism introduced in this application adds a crucial "management backdoor" defense to the entire offline verification process, solving the core security management challenge of improper use of legitimate cards (such as cards not returned by former employees or lost cards being misused). By deploying and comparing the list in real time on local terminals, higher-priority administrative security instructions can be executed immediately after technical verification, achieving synergy and checks and balances between "technical authorization" and "management prohibition." It enhances the ability to address dynamic personnel issues and, by generating clear abnormal event markers and triggering immediate alarms, upgrades passive recording in the offline environment to proactive security warnings, significantly improving the overall security response level and management flexibility.

[0129] Figure 4 This is a schematic diagram of the structure of the CPU card-based offline identity verification terminal provided in this application. Figure 4 As shown, the CPU card-based offline identity verification terminal 40 provided in this embodiment includes:

[0130] The information acquisition module 401 is used to acquire the encrypted data packet, current verification time, and verification scenario type of the CPU card;

[0131] The encrypted information reading module 402 is used to read encrypted data packets, which include ciphertext obtained by encrypting the cardholder's identity information and authorization rules data according to a preset encryption algorithm and key;

[0132] The decryption module 403 is used to decrypt the encrypted data packet to obtain the cardholder's plaintext identity information and plaintext permission rule data;

[0133] The offline verification module 404 is used to perform offline verification of plaintext identity information and plaintext permission rule data according to the current verification time and verification scenario type, and obtain the offline verification result;

[0134] The verification completion module 405 is used to generate an offline verification log and complete the offline identity verification of the cardholder if the offline verification result represents plaintext identity information and plaintext permission rule data that meet the preset identity verification requirements.

[0135] In one possible implementation, the information acquisition module 401 is further used for:

[0136] Get the preset whitelist;

[0137] Based on a preset whitelist, determine the target cardholder's identity information, access data, and current timestamp;

[0138] Encryption is performed based on the target cardholder's identity information, authorization data, and timestamp to generate a dynamic key;

[0139] Based on the dynamic key and the preset encryption algorithm, the identity information and authorization data of the target cardholder are encrypted to obtain encrypted data packets.

[0140] Furthermore, the decryption module 403 is also used for:

[0141] Based on the preset encryption algorithm, determine the identity decryption key and the authorization decryption key for the encrypted data packet;

[0142] Based on the identity decryption key, the cardholder's identity information in the encrypted data packet is decrypted to obtain the cardholder's plaintext identity information;

[0143] Based on the access decryption key, the cardholder's access information in the encrypted data packet is decrypted to obtain the cardholder's plaintext access rule data.

[0144] Furthermore, the offline verification module 404 is also used for:

[0145] Obtain the preset whitelist information, which contains a list of individuals who have completed identity registration;

[0146] The preset whitelist information and plaintext identity information are verified offline to obtain the identity verification result.

[0147] Based on the plaintext permission rule data, determine the valid time interval and scenario list defined by the plaintext permission rule data;

[0148] The current verification time is compared with the valid time interval, and the verification scenario type is compared with the scenario list to obtain the permission verification result;

[0149] The offline verification result is obtained based on the identity verification result and the permission verification result.

[0150] Furthermore, the verification completion module 405 is also used for:

[0151] Based on the offline verification results, determine the identity verification results and the permission verification results;

[0152] If both the identity verification result and the authorization verification result meet the preset identity verification requirements, then the card identification information of the CPU card is determined.

[0153] The card identification information, current verification time, verification scenario type, and offline verification results are correlated to obtain the CPU card's verification record;

[0154] Based on the CPU card's verification records, an offline verification log is generated to complete the offline identity verification of the cardholder.

[0155] Furthermore, the offline verification module 404 is also used for:

[0156] If the identity verification result indicates that the preset whitelist information does not match the plaintext identity information, and / or the permission verification result indicates that the current verification time does not match the valid time interval and the verification scenario type does not match the scenario list, then an offline verification failure result will be generated.

[0157] Based on the offline verification failure results, generate an exception event marker and exception message;

[0158] Based on abnormal event markers and abnormal prompts, complete the early warning processing of cardholder's identity information and authorization data.

[0159] Furthermore, the decryption module 403 is also used for:

[0160] Obtain a preset list of cardholders whose cards have been deactivated.

[0161] The cardholder's plaintext identity information is compared with the information in the preset list to obtain the comparison result;

[0162] If the comparison result indicates that the plaintext identity information matches the preset list information, an abnormal event marker and an abnormal prompt will be generated.

[0163] Based on abnormal event markers and abnormal prompts, complete the early warning processing of cardholder's identity information and authorization data.

[0164] The CPU card-based offline identity verification terminal 40 provided in this embodiment can execute the method provided in the above method embodiment. Its implementation principle and technical effect are similar, and will not be described in detail here.

[0165] Figure 5 This is a schematic diagram of the CPU card used for offline identity verification provided in this application. Figure 5 As shown, the CPU card 50 for offline identity verification provided in this embodiment includes at least one processor 501 and a memory 502. Optionally, the device 50 also includes a communication component 503. The processor 501, memory 502, and communication component 503 are connected via a bus 504.

[0166] In a specific implementation, at least one processor 501 executes computer execution instructions stored in memory 502, causing at least one processor 501 to perform the above-described method.

[0167] The specific implementation process of processor 501 can be found in the above method embodiments, and its implementation principle and technical effect are similar. It will not be repeated here.

[0168] In the above embodiments, it should be understood that the processor can be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), etc. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the method disclosed in this invention can be directly implemented by a hardware processor, or implemented by a combination of hardware and software modules within the processor.

[0169] The memory may include random access memory (RAM) and may also include non-volatile memory (NVM), such as at least one disk storage device.

[0170] The bus can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Architecture (EISA) bus, etc. Buses can be categorized as address buses, data buses, control buses, etc. For ease of illustration, the buses shown in the accompanying drawings are not limited to a single bus or a single type of bus.

[0171] This application also provides an offline identity verification system based on a CPU card, including an offline identity verification terminal based on a CPU card, a CPU card for offline identity verification, and a computer program;

[0172] The method described in the above embodiments is implemented when a computer program is executed by a processor.

[0173] In addition, the functional units in the various embodiments of the present invention can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0174] 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 instructions 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.

[0175] Those skilled in the art will understand that all or part of the steps of the above-described method embodiments can be implemented by hardware related to program instructions. The aforementioned program can be stored in a computer-readable storage medium. When executed, the program performs the steps of the above-described method embodiments; and the aforementioned storage medium includes various media capable of storing program code, such as ROM, RAM, magnetic disks, or optical disks.

[0176] Finally, it should be noted that other embodiments of the invention will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This invention is intended to cover any variations, uses, or adaptations of the invention that follow the general principles of the invention and include common knowledge or customary techniques in the art not disclosed herein, and is not limited to the precise structures described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of the invention is limited only by the appended claims.

Claims

1. A CPU card-based offline identity verification method, characterized in that, The method comprises the steps of: obtaining an encrypted data packet of a CPU card, a current verification time and a verification scene type; reading the encrypted data packet, wherein the encrypted data packet comprises ciphertext obtained by encrypting identity information and permission rule data of a cardholder according to a preset encryption algorithm and a key; decrypting the encrypted data packet to obtain plaintext identity information and plaintext permission rule data of the cardholder; performing offline verification on the plaintext identity information and the plaintext permission rule data according to the current verification time and the verification scene type to obtain an offline verification result; if the offline verification result indicates that the plaintext identity information and the plaintext permission rule data meet preset identity verification requirements, generating an offline verification log to complete offline identity verification of the cardholder.

2. The off-line identity verification method of claim 1, wherein, Before obtaining the encrypted data packet of the CPU card, the current verification time and the verification scene type, the method further comprises the steps of: obtaining a preset white list; determining identity information, permission data and a time stamp of a current time of a target cardholder according to the preset white list; generating a dynamic key through encryption processing according to the identity information and the permission data of the target cardholder and the time stamp; encrypting the identity information and the permission data of the target cardholder respectively according to the dynamic key and a preset encryption algorithm to obtain an encrypted data packet.

3. The off-line identity verification method of claim 1, wherein, Decrypting the encrypted data packet to obtain the plaintext identity information and the plaintext permission rule data of the cardholder comprises the steps of: determining an identity decryption key and a permission decryption key of the encrypted data packet according to the preset encryption algorithm; decrypting the identity information of the cardholder in the encrypted data packet according to the identity decryption key to obtain the plaintext identity information of the cardholder; decrypting the permission information of the cardholder in the encrypted data packet according to the permission decryption key to obtain the plaintext permission rule data of the cardholder.

4. The off-line identity verification method of claim 1, wherein, Performing offline verification on the plaintext identity information and the plaintext permission rule data according to the current verification time and the verification scene type to obtain an offline verification result comprises the steps of: obtaining preset white list information, wherein the preset white list information is deployed with list information of completed identity registration; performing offline identity verification on the preset white list information and the plaintext identity information to obtain an identity verification result; determining an effective time interval and a scene list defined by the plaintext permission rule data according to the plaintext permission rule data; performing verification comparison on the current verification time and the effective time interval and performing verification comparison on the verification scene type and the scene list to obtain a permission verification result; obtaining an offline verification result according to the identity verification result and the permission verification result.

5. The offline identity verification method according to any one of claims 1 to 4, characterized in that, If the offline verification result indicates that the plaintext identity information and the plaintext permission rule data meet preset identity verification requirements, generating an offline verification log to complete offline identity verification of the cardholder comprises the steps of: determining an identity verification result and a permission verification result according to the offline verification result; if the identity verification result and the permission verification result both meet preset identity verification requirements, determining card identification information of the CPU card; Correlate the card identification information, the current verification time, the verification scene type and the offline verification result to obtain a verification record of the CPU card; According to the verification record of the CPU card, an offline verification log is generated to complete the offline identity verification of the cardholder.

6. The offline identity verification method according to any one of claims 1 to 4, characterized in that, According to the current verification time and the verification scene type, the plaintext identity information and the plaintext permission rule data are subjected to offline verification to obtain an offline verification result, and the method further comprises: If the identity verification result indicates that the preset whitelist information does not match the plaintext identity information, and / or the permission verification result indicates that the current verification time does not match the valid time interval, and the verification scene type does not match the scene list, an offline verification failure result is generated; According to the offline verification failure result, an abnormal event marker and an abnormal prompt are generated; According to the abnormal event marker and the abnormal prompt, the warning processing of the identity information and the permission data of the cardholder is completed.

7. The offline identity verification method according to any one of claims 1 to 4, characterized in that, After the encrypted data packet is decrypted to obtain the plaintext identity information and the plaintext permission rule data of the cardholder, the method further comprises: Obtain preset list information, wherein the preset list information is deployed with the identity information of the cardholder that has been subjected to invalidation processing; Compare the plaintext identity information of the cardholder with the preset list information to obtain a comparison result; If the comparison result indicates that the plaintext identity information matches the preset list information, an abnormal event marker and an abnormal prompt are generated; According to the abnormal event marker and the abnormal prompt, the warning processing of the identity information and the permission data of the cardholder is completed.

8. A CPU card-based offline identity verification terminal, characterized by comprising: Comprise: An information acquisition module is configured to acquire an encrypted data packet of a CPU card, a current verification time and a verification scene type; An encrypted information reading module is configured to read the encrypted data packet, wherein the encrypted data packet comprises ciphertext obtained by encrypting the identity information and the permission rule data of a cardholder according to a preset encryption algorithm and a key; A decryption module is configured to decrypt the encrypted data packet to obtain the plaintext identity information and the plaintext permission rule data of the cardholder; An offline verification module is configured to perform offline verification on the plaintext identity information and the plaintext permission rule data according to the current verification time and the verification scene type to obtain an offline verification result; A verification completion module is configured to generate an offline verification log to complete the offline identity verification of the cardholder if the offline verification result indicates that the plaintext identity information and the plaintext permission rule data meet preset identity verification requirements.

9. A CPU card for offline identity verification, characterized by, Comprise: A memory and a processor; The memory stores an encrypted data packet; The processor executes computer execution instructions stored in the memory, so that the processor executes the method of any one of claims 1-7.

10. A CPU card-based offline identity verification system, characterized in that, Comprise a CPU card-based offline identity verification terminal, a CPU card for offline identity verification and a computer program; The computer program is executed by the processor to implement the method of any one of claims 1-7.

Images