A permission verification system

Abstract

This application discloses an access control system, including multiple clockless terminals, a time synchronization terminal, and a user terminal. The user terminal, when a user logs into the system, identifies the clockless terminal corresponding to the user, obtains a first current time to generate a machine-readable code, and sends it to the corresponding clockless terminal. The time synchronization terminal periodically obtains a standard timestamp, establishes a time synchronization packet with a preset protocol version, and sends it to the clockless terminals. The clockless terminals receive the time synchronization packet and the machine-readable code, and perform a first verification of the time synchronization packet. If the first verification passes, they update their local time buffer, extract a second current time, and perform a second verification of the machine-readable code based on the second current time. If the second verification passes, they authorize the user based on the verification intent. This application implements independent verification functionality on clockless terminals without independent RTC chips, balancing cost control, reduced power consumption, and efficient security verification.

Description

Technical Field

[0001] This application relates to the field of permission verification technology, specifically to a permission verification system. Background Technology

[0002] Currently, in some areas of access control and verification, such as access control, campus management, and unmanned retail, in order to improve security and flexibility, mobile apps are commonly used to generate dynamic machine-readable codes or one-time passwords as identity or transaction credentials. For example, employees or students can pass through turnstiles with dynamic machine-readable codes, and users can scan codes to complete payments in unmanned stores.

[0003] However, in actual deployments, in order to control costs and reduce power consumption, many front-end terminals are often not equipped with independent RTC chips. The front-end terminals lack a reliable source of time and cannot complete the verification of machine-readable codes or one-time passwords locally. They can only report to the server for online verification each time. Once the network is abnormal or delayed, it will affect the entire permission verification process and cause inconvenience to users' work and life. Summary of the Invention

[0004] In view of this, this application provides an access control system to solve the problem that many front-end terminals are not equipped with independent RTC chips, lack a reliable source of time, and cannot complete the verification of machine-readable codes or one-time passwords locally. They can only report to the server for online verification each time. Once the network is abnormal or delayed, it will affect the entire access control process and cause inconvenience to users' work and life.

[0005] To achieve the above objectives, the following solution is proposed:

[0006] An access verification system includes multiple clockless terminals, a time synchronization terminal, and a user terminal;

[0007] The user terminal is used to determine the clockless terminal corresponding to the user when the user logs into the verification system, obtain a first current time, generate a machine-readable code based on the first current time, and send the machine-readable code to the clockless terminal corresponding to the user.

[0008] The time synchronization terminal is used to periodically acquire a standard timestamp, establish a time synchronization packet based on the standard timestamp and a preset protocol version, and send it to the clockless terminal.

[0009] The clockless terminal is used to receive the time synchronization packet and the machine-readable code, and to perform a verification on the time synchronization packet. If the first verification passes, the local time buffer is updated, a second current time is extracted from the local time buffer, and the machine-readable code is verified a second time based on the second current time. If the second verification passes, the user is authorized based on the verification intent.

[0010] Preferably, the user terminal generates machine-readable code based on the first current time, including:

[0011] Generate a one-time password based on the first current time;

[0012] Obtain the user's identity identifier, the verification scenario selected by the user on the user terminal interface, and the terminal ID of the clockless terminal corresponding to the user;

[0013] A machine-readable code is generated from the identity identifier, verification scenario, terminal ID, and one-time password.

[0014] Preferably, generating a one-time password based on the first current time includes:

[0015] Configure the start time and time step;

[0016] The first time step is calculated using the start time, the first current time, and the time step.

[0017] Convert the first time step into binary form;

[0018] The first sequence value is calculated based on the first time step converted to binary form and the pre-acquired shared key;

[0019] The first sequence value is truncated and moduloed to obtain a one-time password.

[0020] Preferably, the step of generating a machine-readable code from the identity identifier, verification scenario, terminal ID, and one-time password includes:

[0021] According to a preset structural form, the identity identifier, verification scenario, terminal ID, and one-time password are combined to obtain the first combination data;

[0022] Configure an expiration period for the first combination of data to obtain the second combination of data;

[0023] The second combination of data is encoded according to a preset encoding format to obtain a structured payload byte sequence;

[0024] Machine-readable code is generated from the structured payload byte sequence.

[0025] Preferably, the step of generating machine-readable code from the structured payload byte sequence includes:

[0026] The structured payload byte sequence is compressed to obtain a first payload sequence;

[0027] The compressed payload sequence is encrypted, and a first authentication token is generated to obtain a second payload sequence;

[0028] Machine-readable code is generated from the second payload sequence.

[0029] Preferably, the process by which the time synchronization end establishes a time synchronization packet based on the standard timestamp and the preset protocol version includes:

[0030] Determine your current time zone;

[0031] Calculate the time zone offset based on the time zone rules of the current time zone;

[0032] The protocol version, standard timestamp, and time zone offset are serialized respectively to obtain serialized version, serialized timestamp, and serialized offset information;

[0033] The serialization version, serialization timestamp, and serialization offset information are encrypted using a pre-acquired shared key, and a second authentication token is generated to obtain the first encrypted data;

[0034] The first encrypted data is written into a preset verification field and then filled in using a preset reserved field to obtain a time synchronization packet.

[0035] Preferably, the process by which the clockless terminal performs secondary verification of the machine-readable code based on the second current time includes:

[0036] Convert the machine-readable code into a third payload sequence;

[0037] Determine whether the third payload sequence is encrypted and contains a first authentication token. If so, verify the first authentication token in the third payload sequence. If the verification passes, decrypt to obtain the fourth payload sequence.

[0038] The fourth payload sequence is decoded to determine a one-time password;

[0039] Get the start time and time step;

[0040] The second time step is calculated using the second current time, the start time, and the time step size;

[0041] Multiple candidate time steps are configured based on the second time step and the preset fault tolerance window;

[0042] For each candidate time step, calculate the one-time dynamic password for that candidate time step;

[0043] Determine whether there exists at least one one-time dynamic password that matches the one-time password;

[0044] If so, the second verification passes.

[0045] Preferably, after confirming that the secondary verification has passed, the method further includes:

[0046] Determine whether the machine-readable code has already been used;

[0047] If not, then authorize the user based on the verification intent;

[0048] If so, then obtain the number of times the machine-readable code has been used, and also obtain the time when the machine-readable code was first used;

[0049] Calculate the first time difference between the time when it was first used and the second current time;

[0050] If the number of times used is less than a preset threshold and the first time difference is less than a preset first threshold, then the user is authorized based on the verification intent.

[0051] Preferably, the system further includes a server;

[0052] The server is used to record the reception time as the first reception time when it receives the timing packet reception event reported by the clockless terminal, and to record the reception time as the second reception time when it receives the machine-readable code reception event reported by the clockless terminal.

[0053] Calculate the second time difference between the first reception time and the second reception time;

[0054] The time when the time synchronization terminal sends the timing packet to the clockless terminal is obtained as the first sending time, and the third time difference between the first sending time and the first receiving time is calculated.

[0055] The time when the user terminal sends the machine-readable code to the clockless terminal is obtained as the second transmission time, and a fourth time difference between the second transmission time and the second reception time is calculated.

[0056] The larger of the third time difference and the fourth time difference is taken as the comprehensive latency index, and it is determined whether the comprehensive latency index is less than a preset second threshold.

[0057] If so, a verification signal is sent to the clockless terminal so that the clockless terminal can perform a first verification and / or a second verification based on the verification signal;

[0058] If not, a pause signal is sent to the clockless terminal to restrict the verification process of the clockless terminal.

[0059] Preferably, the formula for calculating the second time step is:

[0060] ;

[0061] in, Indicates the second time step. This indicates the timestamp corresponding to the second current time. This represents the timestamp corresponding to the start time. Indicates the time step.

[0062] As can be seen from the above technical solution, this application provides an access control system, including multiple clockless terminals, a time synchronization terminal, and a user terminal. The user terminal, when a user logs into the verification system, determines the clockless terminal corresponding to the user, obtains a first current time, generates a machine-readable code based on the first current time, and sends the machine-readable code to the clockless terminal corresponding to the user. The time synchronization terminal periodically obtains a standard timestamp, establishes a time synchronization packet based on the standard time and a preset protocol version, and sends it to the clockless terminal. The clockless terminal receives the time synchronization packet and the machine-readable code, performs a first verification on the time synchronization packet, and if the first verification passes, updates its local time buffer, extracts a second current time from the local time buffer, performs a second verification on the machine-readable code based on the second current time, and if the second verification passes, authorizes the user based on the verification intent. This application achieves independent verification functionality on clockless terminals without independent RTC chips through time synchronization packets and a local time buffer, balancing cost control, reduced power consumption, and efficient security verification. First, the user-specific clockless terminal is identified from multiple clockless terminals to determine where the final verification will take place and to obtain the first current time to generate a machine-readable code. Simultaneously, a time synchronization terminal establishes a time synchronization packet based on a standard timestamp and protocol version, providing the clockless terminal with an external, reliable time reference source. A preset protocol version is used to accommodate the low power consumption of the clockless terminal and reduce its dependence on the network environment. The clockless terminal can then first verify the time synchronization packet. Upon successful verification, it updates its local time buffer as a prerequisite for secondary verification, extracting the second current time to verify the machine-readable code, thus achieving a logical closed loop and efficiently completing the entire authorization verification process, bringing convenience to the user's work and life. Furthermore, this solution improves the system's availability in weak or offline network environments. The verification process no longer relies on a real-time network connection between the clockless terminal and the verification server; the clockless terminal only needs to periodically synchronize with the time synchronization terminal to provide completely offline verification services in subsequent time periods, reducing the risk of service interruptions due to network fluctuations. Attached Figure Description

[0063] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on the provided drawings without creative effort.

[0064] Figure 1 This application provides a schematic diagram of the structure of an access control system.

[0065] Figure 2 This is a schematic diagram of a verification mode switching process provided in an embodiment of this application;

[0066] Figure 3 This is a schematic diagram of another permission verification system structure provided in an embodiment of this application;

[0067] Figure 4 This application provides a schematic diagram of the entire verification process of an authorization verification system. Detailed Implementation

[0068] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0069]

Terminology Conventions

[0070] Currently, in some access control and verification fields, such as access control, campus management, and unmanned retail, to improve security and flexibility, mobile apps commonly generate dynamic machine-readable codes or one-time passwords as identity or transaction credentials. For example, employees or students use dynamic machine-readable codes to pass through turnstiles, users scan codes to complete payments in unmanned stores, and residents or citizens use machine-readable codes to use club facilities or dispose of garbage for statistical purposes. There are two implementation methods: First, the terminal has a built-in RTC, which synchronizes time with the server via protocols such as NTP and then verifies the machine-readable code or one-time password locally. However, this method significantly increases hardware and maintenance costs, making it uneconomical for large-scale deployment. Second, to control costs and reduce power consumption, the terminal does not have an independent RTC chip. The front-end terminal lacks a reliable time source and cannot complete machine-readable code or one-time password verification locally, requiring online verification via the server each time. Network anomalies or delays will affect the entire access verification process, causing inconvenience to users' work and lives. Furthermore, inconsistent time sources across different terminals cause timeline confusion, hindering access verification in various scenarios.

[0071] Therefore, in order to solve the problems of the prior art, embodiments of the present invention provide an access verification system, the structure of which is as follows: Figure 1 As shown, it includes multiple clockless terminals, time synchronization terminals, and user terminals;

[0072] The user terminal is used to determine the clockless terminal corresponding to the user when the user logs into the verification system, obtain a first current time, generate a machine-readable code based on the first current time, and send the machine-readable code to the clockless terminal corresponding to the user.

[0073] The time synchronization terminal is used to periodically acquire a standard timestamp, establish a time synchronization packet based on the standard timestamp and a preset protocol version, and send it to the clockless terminal.

[0074] The clockless terminal in this application refers to a front-end device that does not integrate an independent real-time clock (RTC) chip and cannot maintain accurate time for an extended period after power failure. The clockless terminal receives the timing packet and machine-readable code, and performs an initial verification on the timing packet. If the initial verification passes, it updates the local time buffer, extracts a second current time from the local time buffer, and performs a second verification on the machine-readable code based on the second current time. If the second verification passes, it authorizes the user based on the verification intent. The initial verification includes at least: a consistency check on the protocol version, total length, and field length of the timing packet, and an integrity check on the authentication mark; the local time buffer is only updated or the internal timer is reset after the initial verification passes.

[0075] Specifically, the user terminal can refer to user terminals such as mobile phones and tablets, and the verification system is an APP or application used to implement permission verification, such as verification APP, verification mini-program, etc. It can generate dynamic machine-readable codes to support scenarios such as access, class attendance, appointment services, goods collection, garbage disposal, medical and nursing work; the machine-readable code can be in various forms, such as QR code, barcode, NFC, dynamic screen flashing code, sound wave signal, etc., and this embodiment does not limit it.

[0076] The system includes multiple clockless terminals. When a user logs into the authentication system, they may be associated with one of the clockless terminals. It is necessary to determine which one it is in order to accurately send the generated machine-readable code to the corresponding clockless terminal. Time is very important for this authentication mechanism. Therefore, it is necessary to obtain the first current time, which refers to the user's time, and generate a machine-readable code based on the first current time, and then send it to the corresponding clockless terminal.

[0077] A time synchronization terminal refers to an access control host, site master control device, or edge gateway with network time synchronization capabilities. It is typically installed in a computer room or low-voltage room and has network connectivity and serial communication interfaces. It obtains standard timestamps from standard time sources (such as NTP, GPS, etc.), generates time synchronization packets, and periodically broadcasts them to multiple clockless terminals. A preset protocol version is used to accommodate the low power consumption of clockless terminals and reduce dependence on the network environment. In large-scale deployments, multiple time synchronization master devices can be configured within the time synchronization terminal to serve different physical segments. Each master device then synchronizes with an upper-layer time synchronization service or a central server to avoid single points of failure and ensure time consistency across segments.

[0078] A clockless terminal can refer to any terminal device configured without a clock (such as an RTC chip), including but not limited to access control readers, campus access control / roll call terminals (middle school / university entrances, classrooms, laboratories, computer rooms, etc.), unmanned store turnstiles, vending machines, self-service pickup machines, garbage sorting and disposal terminals, public facility reservation turnstiles (clubs, sports venues, etc.), or hospital special zone entrances and exits, pharmacy / laboratory / hazardous materials warehouse terminals, equipped with a microcontroller, memory, and serial communication interface. After receiving the time synchronization packet and machine-readable code, the clockless terminal first performs time-level verification, checking whether the total length, protocol version, etc. of the time synchronization packet meet expectations, and then verifies the key, fields, etc. If the verification passes, the time synchronization packet is considered trustworthy, the local time buffer is updated, and the internal timer is reset, thus completing the time synchronization process and assigning accurate time to the clockless terminal; if the verification fails, the time synchronization packet needs to be discarded to avoid affecting the accuracy of subsequent verifications, and this event is recorded as a dangerous event for subsequent traceability analysis. This application is specifically designed for terminals without a clock configuration. It does not assume that the terminal has a calibrable clock. Instead, it uses a time synchronization terminal to periodically send timing packets, allowing the clockless terminal to maintain a time reference through a time buffer and internal counting method.

[0079] The timing packets can be encapsulated in OSDP File Transfer and transmitted directly over existing RS-485 cabling without modifying the existing RS-485 cabling or terminal hardware. Only firmware and server software upgrades are required, resulting in lower costs. Modbus, CAN, RS-232, or other serial / fieldbus protocols can also be selected, as long as the clockless terminal can reliably receive and verify the timing packets.

[0080] As can be seen from the above technical solution, this application achieves independent verification functionality on clockless terminals without independent RTC chips through time synchronization packets and local time buffers, balancing cost control, reduced power consumption, and efficient security verification. Firstly, the user-specific clockless terminal is identified from multiple clockless terminals to determine where the final verification will take place and to obtain the first current time to generate a machine-readable code. Simultaneously, a time synchronization terminal establishes a time synchronization packet based on a standard timestamp and protocol version, providing the clockless terminal with an external, reliable time reference source. The use of a preset protocol version is to accommodate the low power consumption of the clockless terminal and reduce dependence on the network environment. The clockless terminal can then first verify the time synchronization packet. Upon successful verification, it updates its local time buffer as a prerequisite for secondary verification, thereby extracting the second current time to verify the machine-readable code, achieving a logical closed loop and ultimately efficiently completing the entire authorization verification process, bringing convenience to the user's work and life. In addition, this solution improves the availability of the system in weak network or network outage environments. Its verification process no longer relies on the real-time network connection between the clockless terminal and the verification server. The clockless terminal only needs to periodically synchronize with the time synchronization terminal to provide a completely offline verification service in subsequent time periods, reducing the risk of service interruption due to network fluctuations.

[0081] Optionally, for the user end, the process of generating machine-readable code based on the first current time may specifically include:

[0082] Generate a one-time password based on the first current time;

[0083] Obtain the user's identity identifier, the verification scenario selected by the user on the user terminal interface, and the terminal ID of the clockless terminal corresponding to the user;

[0084] A machine-readable code is generated from the identity identifier, verification scenario, terminal ID, and one-time password.

[0085] Specifically, to generate a machine-readable code, a one-time password is first generated using the current time. This one-time password is one type of data used to generate the machine-readable code. Other data includes the user's identity identifier, the verification scenario selected by the user on the user interface, and the terminal ID of the user's clockless terminal. These data are combined to generate the machine-readable code, making it more secure, less prone to being cracked, and more stable, which is beneficial for subsequent permission verification processes.

[0086] The identity identifier is determined based on the specific permission verification scenario. For example, different identity identifiers are obtained for different verification scenarios. For student access control on campus, the identity identifier refers to student ID, name, class, etc. For company access control, the identity identifier refers to employee ID, name, department, etc. For hospital access control, the identity identifier refers to patient ID, etc. This embodiment does not impose any restrictions on this.

[0087] The verification scenario selected by the user on the user interface is the scenario corresponding to the verification intent. For example, if the user's intent is to enter the campus, then the corresponding verification scenario is to pass through the school gate access control, and the terminal ID of the clockless terminal corresponding to the user is the school gate ID.

[0088] In addition, the user terminal includes a time synchronization module, a one-time password calculation module, an encoding module, and a machine-readable code generation and display module. The one-time password calculation module is used to generate a one-time password based on the first current time. The encoding module and the machine-readable code generation and display module are used together to obtain the user's identity identifier, the verification scenario selected by the user on the user terminal interface, and the terminal ID of the clockless terminal corresponding to the user; and generate a machine-readable code from the identity identifier, verification scenario, terminal ID, and one-time password.

[0089] The process of generating a one-time password based on the first current time in the above process includes:

[0090] Configure the start time and time step;

[0091] The first time step is calculated using the start time, the first current time, and the time step.

[0092] Convert the first time step into binary form;

[0093] The first sequence value is calculated based on the first time step converted to binary form and the pre-acquired shared key;

[0094] The first sequence value is truncated and moduloed to obtain a one-time password.

[0095] Specifically, the start time can be a pre-agreed start time of the authorization verification system provided in this application, such as 1970-01-01 00:00:00 UTC, or it can be uniformly configured by the server to a fixed time, and the start time of the user terminal and each clockless terminal should be the same; the time step is used to control the effective time window of each one-time password, usually 30 s or 60 s, preferably 30 s, and the time synchronization period is controlled within the range of 30 to 300 s, so as to limit the cumulative time error of the clockless terminal.

[0096]

Symbol Explanation

[0097] Optionally, the formula for calculating the first time step is:

[0098] ;

[0099] in, Indicates the first step. This represents the timestamp corresponding to the first current time. This represents the timestamp corresponding to the start time. Indicates the time step.

[0100] The shared key K can be uniformly generated by the server and distributed to user terminals and various clockless terminals through a secure channel. The server can store the master key through a hardware security module (HSM) or a security chip, and only distribute derived or partitioned working keys to user terminals and various clockless terminals to reduce the risk of key leakage. After calculating the first time step, the first time step is converted into binary form for calculation. Then, it is combined with the shared key to calculate the first sequence value, for example, the first sequence value or authentication token can be generated based on HMAC. The hash function used by HMAC can be selected from hash functions that meet security requirements, such as SHA-1, SHA-256, SHA-512, SHA-3, SM3, etc. In some embodiments, HMAC-SHA256 is preferred, but this application does not limit this. HMAC is a key-based message authentication code algorithm that outputs a fixed-length message authentication code after inputting the shared key and a message (e.g., the first time step in binary form), used for integrity verification and preventing tampering.

[0101] For example, the HMAC-SHA sequence value is a sequence number or counter calculated based on a time window and used to generate a one-time password. It is also a cryptographic function; that is, given a shared key and a message, it outputs a fixed-length digest, ensuring the integrity and authenticity of the message. The first time step in binary form is the message itself. After calculating the first sequence value, the number of bits in the one-time password can be set, and the first sequence value can be dynamically truncated and moduloed according to the number of bits.

[0102] Optionally, the step of generating a machine-readable code from the identity identifier, verification scenario, terminal ID, and one-time password in the above process is as follows:

[0103] According to a preset structural form, the identity identifier, verification scenario, terminal ID, and one-time password are combined to obtain the first combination data;

[0104] Configure an expiration period for the first combination of data to obtain the second combination of data;

[0105] The second combination of data is encoded according to a preset encoding format to obtain a structured payload byte sequence;

[0106] Machine-readable code is generated from the structured payload byte sequence.

[0107] Specifically, the preset structure can be in JSON or URL Query format and is extensible, adaptable to verification scenarios across various industries. The purpose of combining identity identifiers, verification scenarios, terminal IDs, and one-time passwords according to the preset structure is to integrate scattered verification elements into a complete data packet. This unified structure maintains the stability of the first set of data. The terminal ID ensures that the machine-readable code is only valid for specific clockless terminals, forming a one-to-one verification method and preventing the intercepted machine-readable code from being misused on other clockless terminals. The verification scenario allows clockless terminals to perform differentiated processing based on different business scenario logics.

[0108] To prevent machine-readable codes from expiring and for security reasons, an expiration period can be configured after obtaining the first set of data. For example, the expiration time can be calculated based on the current time and a preset validity period. When the expiration time is reached, the machine-readable code becomes invalid. A limit on the number of uses can also be set, both of which reduce the risk of the machine-readable code being misused after being screenshotted or photographed. Then, the second set of data is encoded. The preset encoding format can be TLV (Tag-Length-Value), JSON, CBOR (Concise Binary Object Representation), Protocol Buffers, etc., etc. This embodiment does not impose any restrictions on this. Binary encoding saves more space than text format, making the process of generating machine-readable codes more efficient and faster to recognize.

[0109] In the process of generating machine-readable code from a structured payload byte sequence, an appropriate machine-readable code version can be selected based on the length of the structured payload byte sequence. Standard machine-readable code generation libraries (such as ZXing, QRCode Generator) can be used to encode the structured payload byte sequence into a machine-readable code matrix, and then render it as an image.

[0110] To further reduce data size, simplify the generated machine-readable code graphics, and improve the transmission efficiency of the machine-readable code, thereby enabling faster and more reliable identification in subsequent verification processes, the process of generating machine-readable code from the structured payload byte sequence can first undergo certain processing before generating machine-readable code. This includes the following steps:

[0111] The structured payload byte sequence is compressed to obtain a first payload sequence;

[0112] The compressed payload sequence is encrypted, and a first authentication token is generated to obtain a second payload sequence;

[0113] Machine-readable code is generated from the second payload sequence.

[0114] Specifically, after obtaining the structured payload byte sequence, the structured payload byte sequence can be compressed, for example, by using common compression algorithms such as DEFLATE, gzip, or Brotli to reduce the data size of the structured payload byte sequence.

[0115] After obtaining the first payload sequence, the payload can be protected for confidentiality and integrity according to security level requirements: the payload can be encrypted using a symmetric encryption algorithm, and an authentication tag can be generated for integrity verification. Symmetric encryption algorithms include, for example, AES-GCM, ChaCha20-Poly1305, etc., but this application does not limit this. When using a symmetric encryption mode with authentication capabilities, the authentication tag may include an authentication label (Tag) output by the encryption algorithm. At higher security levels, message authentication codes or digital signatures can also be superimposed for enhancement, but this application does not limit this. The authentication tag can be a message authentication code (e.g., HMAC, and its hash function can be selected from SHA-1, SHA-256, SHA-512, SHA-3, SM3, etc.) or a digital signature (e.g., RSA, ECDSA, SM2, etc.); message authentication codes and digital signatures can also be used simultaneously to meet higher security level requirements.

[0116] The process of establishing a time synchronization packet based on the standard timestamp and the preset protocol version at the time synchronization end is as follows:

[0117] Determine your current time zone;

[0118] Calculate the time zone offset based on the time zone rules of the current time zone;

[0119] The protocol version, standard timestamp, and time zone offset are serialized respectively to obtain serialized version, serialized timestamp, and serialized offset information;

[0120] The serialization version, serialization timestamp, and serialization offset information are encrypted using a pre-acquired shared key, and a second authentication token is generated to obtain the first encrypted data;

[0121] The first encrypted data is written into a preset verification field and then filled in using a preset reserved field to obtain a time synchronization packet.

[0122] Specifically, this application can flexibly configure the time zone according to the current verification scenario without changing the time synchronization mechanism of the standard timestamp. It can also calculate the time zone offset of the current time zone relative to the standard timestamp according to the time zone rules, and then convert the three different types of data, namely the protocol version header field, the standard timestamp (UTC Timestamp), and the time zone offset (TimeZone Offset), into a standard byte sequence to achieve consistency of different data types and match and correspond with clockless terminals. This ensures that clockless terminals can correctly parse the time synchronization packet according to the unified parsing rules. Furthermore, since the second authentication mark acts on the binary byte stream, serialization is also to ensure that the second authentication mark can be successfully generated and verified.

[0123] The generation and verification of one-time passwords are calculated based solely on the standard timestamp, start timestamp, and time step; the time zone offset is used for display, log presentation, or localized business rule processing and does not participate in the calculation of one-time passwords.

[0124] This application establishes that a shared key is used in the process of generating machine-readable code on the user end. When constructing the timing packet at the time synchronization end, specifically in the process of determining the first encrypted data, the same shared key can be used. This creates an intersection point in the entire verification process, implying some correlation between the user end, the time synchronization end, and the clockless terminal beyond just data transmission and reception. This further ensures the stability and correspondence of the entire interaction process and effectively prevents the risk of forging timing packets or machine-readable code in the middle. Then, a second authentication token is generated, which binds the serialization version, serialization timestamp, and serialization offset information together. This prevents splicing attacks, meaning that external attacks cannot combine an expired timestamp and a new offset information to pass subsequent verification, thereby further ensuring security.

[0125] Finally, the first encrypted data is written into the verification field. This involves placing the encryption result and the second authentication mark in a fixed position within the packet. To ensure the stability of the timing packet, reserved fields are used to complete the final timing packet. Both the verification field and the reserved fields are pre-defined and set according to the desired timing packet. This embodiment does not impose any restrictions on this. The fixed length of the timing packet facilitates subsequent reading and verification parsing, improving verification efficiency and accuracy. The reserved fields can reserve space for subsequent protocol upgrades (such as newly added algorithm identifiers, longer authentication mark rules, etc.) without changing the overall length or framework of the timing packet, ensuring forward compatibility.

[0126] In one example, the total length of the timing packet is set to 20 bytes. In addition to the three types of data mentioned above, the timing packet may also include a metadata field at the beginning (e.g., 2 bytes). For example: the serialization version field occupies 1 byte, the serialization timestamp field occupies 8 bytes, the serialization offset information field occupies 2 bytes, the verification field occupies Y bytes, and the reserved field occupies R bytes. Here, Y is the byte length of the verification field, and R is the byte length of the reserved field. Optionally, the byte lengths of the verification and reserved fields can be adjusted according to the protocol version, standard timestamp (UTC Timestamp), timezone offset, and authentication algorithm requirements (e.g., authentication tag length, algorithm identifier field length, etc.).

[0127] The time synchronization terminal can set the broadcast frequency, such as 30~300 seconds, and broadcast time synchronization packets to all clockless terminals via RS-485 / OSDP bus or other buses. The time synchronization period is set according to the maximum allowable time offset and the accuracy of the clockless terminal. For example, when the time step is 30 seconds, the time synchronization period can be selected from 30 to 300 seconds to limit the accumulated time error of the clockless terminal.

[0128] In addition, the time synchronization terminal includes an external time synchronization client module, a time synchronization packet generation and authentication mark generation module, a serial broadcast module, and a terminal online / offline monitoring and error alarm module. The external time synchronization client module is used to determine the current time zone. The time synchronization packet generation and authentication mark generation module is used to perform a series of calculations based on the current time zone and generate time synchronization packets and authentication marks. The serial broadcast module is used to send time synchronization packets to the corresponding clockless terminal. The terminal online / offline monitoring and error alarm module is used to monitor the online and offline status of the clockless terminal and to issue error alarms.

[0129] In the system provided by this invention, the specific operation process for a clockless terminal to perform secondary verification of the machine-readable code based on the second current time is as follows:

[0130] Convert the machine-readable code into a third payload sequence;

[0131] Determine whether the third payload sequence is encrypted and contains a first authentication token. If so, verify the first authentication token in the third payload sequence. If the verification passes, decrypt to obtain the fourth payload sequence.

[0132] The fourth payload sequence is decoded to determine a one-time password;

[0133] Get the start time and time step;

[0134] The second time step is calculated using the second current time, the start time, and the time step size;

[0135] Multiple candidate time steps are configured based on the second time step and the preset fault tolerance window;

[0136] For each candidate time step, calculate the one-time dynamic password for that candidate time step;

[0137] Determine whether there exists at least one one-time dynamic password that matches the one-time password;

[0138] If so, the second verification passes.

[0139] Specifically, the start time and time step in this step are the same as the start time and time step used when calculating the first time step, and the calculation formula for the second time step is the same as that for the first time step:

[0140] ;

[0141] in, Indicates the second time step. This indicates the timestamp corresponding to the second current time. This represents the timestamp corresponding to the start time. Indicates the time step.

[0142] This process corresponds to the reverse of the process of generating machine-readable code on the user end. It requires the timeless terminal to reverse-engineer the machine-readable code layer by layer to achieve verification. So first, the machine-readable code needs to be converted into a payload sequence, namely the third payload sequence (if there are no problems or thefts in the whole process, the third payload sequence is the same as the second payload sequence). Then, the first authentication tag contained in the third payload sequence is verified. After the verification is successful, it is decrypted to obtain the fourth payload sequence. The fourth payload sequence may be compressed (corresponding to the first payload sequence), so the fourth payload sequence can also be decompressed and then decoded (using TLV (Tag-Length-Value) / JSON / CBOR (Concise Binary Object Representation) / Protocol Buffers, etc.). Then, multiple verification data contained in the machine-readable code can be obtained, which will include a one-time password.

[0143] [Window Distinction] The “fault-tolerant window” described in this application is used for candidate time step expansion (e.g., C2-1, C2, C2+1) to improve the fault tolerance capability of one-time password verification; the “offline fault-tolerant time window” described in this article is used to maintain an acceptable time offset range based on the last time synchronization result when the time synchronization is interrupted. The two have different meanings.

[0144] The next crucial step is to verify the one-time password. To prevent false positives and reduce the verification error rate, a set of candidate time steps can be calculated. After calculating the second time step, it is expanded to increase the one-time password's fault tolerance. The expanded candidate time steps include... , , Then, for each candidate time step, a one-time dynamic password is calculated: the candidate time step is converted to binary form, a sequence value is calculated based on the converted binary candidate time step and the shared key, and this sequence value is truncated and moduloed to obtain the one-time dynamic password. Next, each one-time dynamic password is compared with the one-time password to determine whether the candidate time step matches. The condition for successful secondary verification is that at least one one-time dynamic password is the same as the one-time password; if each one-time dynamic password is different from the one-time password, the secondary verification fails. This means that if the secondary verification passes, then the one-time dynamic password is indeed the one-time password. The clockless terminal verifies layer by layer, ultimately determining the one-time password generated by the user. Furthermore, this method enables local autonomous verification by the clockless terminal, rather than relying entirely on the server.

[0145] The clockless terminal includes a time synchronization packet receiving and verification module, a time buffer management and internal timing module, a credential parsing and verification module, and an I / O control module. The time synchronization packet receiving and verification module receives time synchronization packets and performs initial verification on them. If the initial verification passes, the time buffer management and internal timing module updates the local time buffer and extracts a second current time from it. The credential parsing and verification module performs secondary verification on the machine-readable code based on the second current time. The I / O control module authorizes users.

[0146] To further ensure the accuracy and real-time nature of the verification, after confirming that the secondary verification has passed, this system may also include:

[0147] Determine whether the machine-readable code has already been used;

[0148] If not, then authorize the user based on the verification intent;

[0149] If so, then obtain the number of times the machine-readable code has been used, and also obtain the time when the machine-readable code was first used;

[0150] Calculate the first time difference between the time when it was first used and the second current time;

[0151] If the number of times used is less than a preset threshold and the first time difference is less than a preset first threshold, then the user is authorized based on the verification intent.

[0152] Specifically, the permission verification system provided in this application not only verifies whether the machine-readable code is correct and whether its source is legitimate, but also assesses whether the verification requirements are reasonable. That is, it introduces the dimensions of usage frequency and time to verify the validity of the machine-readable code. This includes verifying whether the machine-readable code has been used and verifying the time validity of the machine-readable code. If the machine-readable code has been used, the first line of defense is breached, and the second line of defense needs to be examined. This is determined based on the number of uses and the first time difference. Only when the number of uses does not exceed the requirement and the time since the first use does not exceed the requirement can the machine-readable code be considered valid, thereby authorizing the user based on the verification intent.

[0153] Therefore, the clockless terminal also includes a fault-tolerant time window control module, an event log caching and reporting module, and a backup mode management module. The fault-tolerant time window control module is used to determine the validity of machine-readable codes; the event log caching and reporting module is used to record event logs and transmit them to the server.

[0154] Optionally, the permission verification system provided in this embodiment of the invention further includes a server:

[0155] The server is used to record the reception time as the first reception time when it receives the timing packet reception event reported by the clockless terminal, and to record the reception time as the second reception time when it receives the machine-readable code reception event reported by the clockless terminal.

[0156] Calculate the second time difference between the first reception time and the second reception time;

[0157] The time when the time synchronization terminal sends the timing packet to the clockless terminal is obtained as the first sending time, and the third time difference between the first sending time and the first receiving time is calculated.

[0158] The time when the user terminal sends the machine-readable code to the clockless terminal is obtained as the second transmission time, and a fourth time difference between the second transmission time and the second reception time is calculated.

[0159] The larger of the third time difference and the fourth time difference is taken as the comprehensive latency index, and it is determined whether the comprehensive latency index is less than a preset second threshold.

[0160] If so, a verification signal is sent to the clockless terminal so that the clockless terminal can perform a first verification and / or a second verification based on the verification signal;

[0161] If not, a pause signal is sent to the clockless terminal to restrict the verification process of the clockless terminal.

[0162] Specifically, in addition to making various judgments and restrictions on the verification process, this application also verifies the clockless terminal itself. That is, it examines the time difference between the clockless terminal receiving the timing packet and the machine-readable code from the time dimension, and at the same time examines the time difference between the user end / time synchronization end sending the machine-readable code / timing packet and the clockless terminal receiving the machine-readable code / timing packet from the time dimension. These are analyzed together, and the larger of the third time difference and the fourth time difference is taken as the comprehensive latency index. Then it is judged whether the comprehensive latency index meets the requirements. This can ensure that the interaction process between the user end, the time synchronization end and the clockless terminal is more secure.

[0163] If the overall latency index is not less than the second threshold, or if a verification fails once, the verification process needs to be exited or offline fault-tolerant mode needs to be entered to ensure security. Specifically, this includes:

[0164] like Figure 2As shown, for the offline fault-tolerant mode, if the system recovers and the administrator re-enables it during this process, it will return to the normal verification mode provided in this application; if the preset offline fault-tolerant time window is exceeded (where the time of the last time synchronization terminal is used to set the offline fault-tolerant time window), it will enter the backup QR code mode (Quick Response Code, QR Code) or Legacy mode for verification, and only verify the authentication mark (which can be a message authentication code or digital signature) or static authorization information. In the backup QR code mode or Legacy mode, only low-risk operations / low-risk areas are allowed; high-risk operations require a second factor feature, and failure is rejected by default; optional policies can trigger blocking / disabling; the entire process is recorded for auditing and risk analysis.

[0165] The specific algorithms used for message authentication codes and digital signatures can be selected according to security levels and compliance requirements. This application does not impose any restrictions on this, and this information will be recorded for subsequent auditing and risk analysis. This allows the clockless terminal to maintain some functions during brief time synchronization or network anomalies, preventing shutdowns in certain verification scenarios, such as access control failures or unexpected problems in unmanned stores. If normal operation is restored and the administrator reactivates the terminal, it will return to the normal verification mode provided by this application. Regardless of the mode, if the administrator manually disables the terminal, all verification processes will be exited, and the permission granting channel of the clockless terminal will be blocked or disabled. Alternatively, only low-risk operations or low-risk area permissions may be granted to users, such as in the garbage disposal verification scenario, where access control to high-security areas is not authorized. If a user insists on requesting high-risk permissions, a second factor verification (biometrics / two-factor authentication 2FA) can be added. If the verification passes, high-risk operations / areas are allowed; if it fails, high-risk requests are rejected. However, regardless of whether the verification passes or fails, a backup mode is maintained.

[0166] In addition, the server can be deployed locally or in the cloud, and is responsible for key management, registration of clockless terminals and user terminals, centralized storage and auditing of event logs, time offset monitoring, risk scoring and alarms, etc. It has network communication and storage capabilities, including a key and configuration management module, a policy engine module (dynamically adjusting fault tolerance time and backup mode, etc.), a centralized log and audit module (including hash chain or signature protection), a time offset analysis module, a risk scoring and alarm module, and a reporting and interface module.

[0167] When the secondary verification is successful, the clockless terminal can select the corresponding I / O control logic according to the verification intent and execute the corresponding action, as shown in Table 1 below. At the same time, the clockless terminal will write the time, timing status, verification result, scenario type and other information of this permission verification event into the local log, and perform centralized auditing according to the policy to form an audit log and send it to the server.

[0168] Table 1

[0169]

[0170] In one example, such as Figure 3 As shown, a group of clockless terminals consists of various types of clockless terminals, including the various clockless terminals listed in Table 1. These clockless terminals are all without RTC. Each clockless terminal can upload verification results or audit logs to the server. The server can store audit log data in the audit / log database. The time synchronization terminal broadcasts a time synchronization packet containing a standard timestamp to each clockless terminal via the RS-485 / OSDP bus. Figure 4 A schematic diagram of the entire verification process of the permission verification system provided for this application.

[0171] It should also be noted that the user information (including but not limited to identity identifiers, biometrics, second factor characteristics, etc.) and data (including but not limited to data used for encoding and analysis, stored data, displayed data, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties, and the collection, use and processing of the relevant data comply with relevant regulations.

[0172] Furthermore, the functional modules in the various embodiments of this disclosure can be integrated together to form an independent part, or each module can exist independently, or two or more modules can be integrated to form an independent part. If the function is implemented as a software functional module 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 disclosure, in essence, 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, a live streaming device, or a network device, etc.) to execute all or part of the steps of the methods in the various embodiments of this disclosure.

[0173] Finally, it should be noted that terms such as "first" and "second" in this document are used only to distinguish the objects described and do not indicate or imply relative importance or order, nor do they limit the specific relationship or order between entities or operations. The terms "comprising," "including," and any variations thereof are intended to indicate non-exclusive inclusion, meaning that when a process, method, article, or apparatus includes a series of elements, it may include other elements not expressly listed, or other elements inherent to the process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element.

[0174] The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on the differences from other embodiments. The same or similar parts between the various embodiments can be referred to each other.

[0175] The above description of the disclosed embodiments enables those skilled in the art to make or use this application. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of this application. Therefore, this application is not to be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. A rights verification system, characterized by comprising: Includes multiple clockless terminals, time synchronization terminals, and user terminals; The user terminal is used to determine the clockless terminal corresponding to the user when the user logs into the verification system, obtain a first current time, generate a machine-readable code based on the first current time, and send the machine-readable code to the clockless terminal corresponding to the user. The time synchronization terminal is used to periodically acquire a standard timestamp, establish a time synchronization packet based on the standard timestamp and a preset protocol version, and send it to the clockless terminal. The clockless terminal is used to receive the time synchronization packet and the machine-readable code, and to perform a verification on the time synchronization packet. If the first verification passes, the local time buffer is updated, a second current time is extracted from the local time buffer, and the machine-readable code is verified a second time based on the second current time. If the second verification passes, the user is authorized based on the verification intent.

2. The system of claim 1, wherein, The process by which the user terminal generates machine-readable code based on the first current time includes: Generate a one-time password based on the first current time; Obtain the user's identity identifier, the verification scenario selected by the user on the user terminal interface, and the terminal ID of the clockless terminal corresponding to the user; A machine-readable code is generated from the identity identifier, verification scenario, terminal ID, and one-time password.

3. The system of claim 2, wherein, The step of generating a one-time password based on the first current time includes: Configure the start time and time step; The first time step is calculated using the start time, the first current time, and the time step. Convert the first time step into binary form; The first sequence value is calculated based on the first time step converted to binary form and the pre-acquired shared key; The first sequence value is truncated and moduloed to obtain a one-time password.

4. The system of claim 2, wherein, The generation of a machine-readable code from the identity identifier, verification scenario, terminal ID, and one-time password includes: According to a preset structural form, the identity identifier, verification scenario, terminal ID, and one-time password are combined to obtain the first combination data; Configure an expiration period for the first combination of data to obtain the second combination of data; The second combination of data is encoded according to a preset encoding format to obtain a structured payload byte sequence; Machine-readable code is generated from the structured payload byte sequence.

5. The system of claim 4, wherein, The generation of machine-readable code from the structured payload byte sequence includes: The structured payload byte sequence is compressed to obtain a first payload sequence; The compressed payload sequence is encrypted, and a first authentication token is generated to obtain a second payload sequence; Machine-readable code is generated from the second payload sequence.

6. The system of claim 1, wherein, The process by which the time synchronization terminal establishes a time synchronization packet based on the standard timestamp and the preset protocol version includes: Determine your current time zone; Calculate the time zone offset based on the time zone rules of the current time zone; The protocol version, standard timestamp, and time zone offset are serialized respectively to obtain serialized version, serialized timestamp, and serialized offset information; The serialization version, serialization timestamp, and serialization offset information are encrypted using a pre-acquired shared key, and a second authentication token is generated to obtain the first encrypted data; The first encrypted data is written into a preset verification field and then filled in using a preset reserved field to obtain a time synchronization packet.

7. The system of claim 1, wherein, The process by which the clockless terminal performs secondary verification of the machine-readable code based on the second current time includes: Convert the machine-readable code into a third payload sequence; Determine whether the third payload sequence is encrypted and contains a first authentication token. If so, verify the first authentication token in the third payload sequence. If the verification passes, decrypt to obtain the fourth payload sequence. The fourth payload sequence is decoded to determine a one-time password; Get the start time and time step; The second time step is calculated using the second current time, the start time, and the time step size; Multiple candidate time steps are configured based on the second time step and the preset fault tolerance window; For each candidate time step, calculate the one-time dynamic password for that candidate time step; Determine whether there exists at least one one-time dynamic password that matches the one-time password; If so, then the second verification passes.

8. The system of claim 7, wherein, After confirming that the secondary verification has passed, the following steps are also included: Determine whether the machine-readable code has already been used; If not, then authorize the user based on the verification intent; If so, then obtain the number of times the machine-readable code has been used, and also obtain the time when the machine-readable code was first used; Calculate the first time difference between the time when it was first used and the second current time; If the number of times used is less than a preset threshold and the first time difference is less than a preset first threshold, then the user is authorized based on the verification intent.

9. The system of claim 1, wherein, The system also includes a server; The server is used to record the reception time as the first reception time when it receives the timing packet reception event reported by the clockless terminal, and to record the reception time as the second reception time when it receives the machine-readable code reception event reported by the clockless terminal. Calculate the second time difference between the first reception time and the second reception time; The time when the time synchronization terminal sends the timing packet to the clockless terminal is obtained as the first sending time, and the third time difference between the first sending time and the first receiving time is calculated. The time when the user terminal sends the machine-readable code to the clockless terminal is obtained as the second transmission time, and a fourth time difference between the second transmission time and the second reception time is calculated. The larger of the third time difference and the fourth time difference is taken as the comprehensive latency index, and it is determined whether the comprehensive latency index is less than a preset second threshold. If so, a verification signal is sent to the clockless terminal so that the clockless terminal can perform a first verification and / or a second verification based on the verification signal; If not, a pause signal is sent to the clockless terminal to restrict the verification process of the clockless terminal.

10. The system of claim 7, wherein, The formula for calculating the second time step is: ； wherein, denotes a second time step, denotes a timestamp corresponding to a second current time, denotes a timestamp corresponding to a start time, denotes a time step.

Images