Dynamic attendance checking method and system based on NFC security tag

Abstract

The invention relates to a dynamic attendance checking method and system based on an NFC security tag, and belongs to the field of attendance checking, and the method comprises the following steps: a user mobile terminal carries out near field communication interaction with a preset NFC security tag to obtain dynamic authentication data generated by the NFC security tag; the mobile terminal generates an attendance request based on the dynamic authentication data and sends the attendance request to the background server; the background server receives the attendance request and executes verification operation, and the verification operation comprises the steps of performing cryptographic verification on the dynamic authentication data based on a security key pre-shared with the NFC security tag to verify the authenticity of the NFC security tag; verifying whether the dynamic authentication data meets a preset uniqueness condition or not; and after the verification is passed, the background server executes an attendance recording operation and sends an attendance punching result to the mobile terminal, so that the mobile terminal feeds back the attendance punching result to the user. According to the invention, the clone-proof and replay-proof attendance checking card punching of the attendance checking voucher can be realized at low cost and high convenience.

Description

Technical Field

[0001] This application relates to the field of attendance technology, and in particular to a dynamic attendance method and system based on NFC security tags. Background Technology

[0002] With the widespread adoption of mobile internet and smart devices, mobile-based electronic attendance systems have become increasingly popular due to their convenience and flexibility. However, existing mainstream low-cost attendance solutions suffer from serious security flaws.

[0003] Currently, the most widely used mobile attendance solution is based on QR code or barcode technology. In this solution, the system generates a QR code containing attendance information and displays it on the terminal screen or at a fixed location. Users scan the QR code with their mobile devices to complete the attendance check-in. Although this solution is simple to deploy, its security relies entirely on the QR code data itself.

[0004] Because QR codes are essentially static or periodically changing visual encoded information, they are extremely easy to copy completely through screenshots, photos, and other means. Attackers can easily submit the copied QR code credentials repeatedly at different times and locations, thereby achieving "proxy check-in" or "remote check-in." This exposes two fundamental security vulnerabilities in QR code attendance solutions: First, the credentials themselves are extremely easy to clone and cannot be bound to a unique physical carrier; second, there is a lack of effective mechanisms to prevent intercepted credentials from being reused (i.e., replay attacks).

[0005] While there are solutions that attempt to improve security, such as dynamic QR codes, dedicated attendance hardware (e.g., fingerprint scanners), or environmental awareness-based solutions (e.g., GPS, Bluetooth), they are either costly, complex to deploy, or still fail to fundamentally solve the problems of credential cloning and trusted verification.

[0006] Therefore, there is an urgent need in the existing technology for a mobile electronic attendance solution that can achieve anti-cloning and anti-replay of attendance vouchers at low cost and with high convenience. Summary of the Invention

[0007] To achieve cost-effective and convenient attendance tracking with anti-cloning and anti-replay capabilities, this application provides a dynamic attendance method and system based on NFC security tags.

[0008] Firstly, this application provides a dynamic attendance method based on NFC security tags, including: The user's mobile terminal interacts with a preset NFC security tag via near-field communication to obtain dynamic authentication data generated by the NFC security tag; The mobile terminal generates an attendance request based on the dynamic authentication data and sends the attendance request to the backend server. The backend server receives attendance requests and performs verification operations, which include: performing cryptographic verification on the dynamic authentication data based on a security key pre-shared with the NFC security tag to verify the authenticity of the NFC security tag; and verifying whether the dynamic authentication data meets a preset uniqueness condition to prevent replay attacks. After successful verification, the backend server performs the attendance recording operation and sends the attendance check-in result to the mobile terminal, so that the mobile terminal can provide feedback on the attendance check-in result to the user.

[0009] By adopting the above technical solution, introducing NFC security tags with dynamic authentication capabilities, and utilizing a backend server for cryptographic verification and uniqueness checks, the two major security vulnerabilities of existing QR code attendance solutions—easily cloned and replayed—are fundamentally resolved. While maintaining the convenience of mobile attendance, this solution, for the first time, achieves reliable verification of the authenticity and uniqueness of attendance credentials at low cost, laying the technological foundation for highly secure mobile attendance.

[0010] Optionally, the user mobile terminal interacts with a preset NFC security tag via near-field communication to obtain dynamic authentication data generated by the NFC security tag, including: The mobile terminal sends a challenge request to the backend server, and the challenge request includes first location information and user identity identifier obtained based on the mobile terminal. The backend server responds to the challenge application, verifies the legitimacy of the user's identity, and determines the expected geofence based on the first location information; it generates a one-time random challenge code, associates and binds the challenge code with the user's identity identifier and the geofence, and then sends it to the mobile terminal. After receiving the challenge code, the mobile terminal sends a cryptographic calculation instruction containing the challenge code to the NFC security tag through the near field communication interface; The security chip of the NFC security tag responds to the cryptographic calculation instruction and uses a preset security key to perform cryptographic operations on the challenge code to generate dynamic authentication data. The mobile terminal reads the dynamic authentication data generated by the NFC security tag through the near-field communication interface; The attendance request includes the second location information obtained by the mobile terminal when or after reading the dynamic authentication data; The verification operation further includes: verifying whether the second location information is located within the geofence bound to the challenge code.

[0011] By adopting the above technical solution, this approach introduces a challenge-response protocol and a location-binding verification mechanism to strongly associate dynamic authentication with the user's claimed geographical location. This effectively prevents attackers from using legitimate tags to clock in at non-designated locations, achieving a "one-time password, one-location authentication" security effect. It is particularly suitable for fieldwork or distributed office scenarios requiring verification of actual attendance, adding a dimension against location spoofing in addition to preventing cloning and replay attacks.

[0012] Optionally, the method further includes a trajectory analysis step: During the time period between the mobile terminal sending the challenge application and the reading of the dynamic authentication data, the mobile terminal continuously collects location information at a frequency higher than a preset frequency, forming a location data stream and sending it to the backend server. The backend server analyzes the location data stream to detect whether there are any abnormal patterns in the movement trajectory of the mobile terminal within the time period; wherein, the abnormal pattern includes at least one of the following: the movement speed or acceleration violates the laws of physics, or the movement trajectory does not match the geographical environmental features indicated by the first location information or the second location information.

[0013] By adopting the above technical solution, this approach enhances the monitoring of the core check-in process. By analyzing the high-frequency continuous trajectories of users during authentication operations, it can effectively identify abnormal movement patterns (such as teleportation or movement that violates the laws of physics) caused by automated scripts or fixed-location spoofing of check-ins. This provides quantifiable technical evidence for detecting "remote cheating with a genuine tag at a fixed point," enhancing the system's ability to detect premeditated and continuous fraudulent behavior.

[0014] Optionally, after the backend server sends the attendance check-in results, the method further includes a delayed authentication step: After receiving the attendance check-in result, the mobile terminal waits for a preset delay period and then silently collects third location information in the background and sends it to the background server. The backend server verifies the logical consistency between the third location information and the geographical location information associated with this attendance request.

[0015] By adopting the above technical solution, this approach innovatively introduces silent, delayed location auditing after successful check-in feedback. This forces potential cheaters to remain at their claimed attendance location for an unpredictable period of time, significantly increasing the time cost and exposure risk of cheating. This mechanism, without affecting the normal experience of honest users, achieves post-event deterrence and detection of "check-in and leave" cheating behavior, thus perfecting the time-dimensional closed loop of attendance security.

[0016] Optionally, the method further includes a collaborative verification step, which is as follows: After the mobile terminal sends the challenge application, the backend server or the mobile terminal designates at least one collaborative verification terminal and sends a verification request to the designated collaborative verification terminal. In response to the verification request, the collaborative verification terminal generates a verification token containing a trusted timestamp and sends it to the backend server. The backend server receives the verification token, generates time constraint information based on the trusted timestamp in the verification token, and sends the time constraint information to the mobile terminal. The interaction process between the mobile terminal and the NFC security tag, and / or the generation of the attendance request, must meet the time constraint information. The verification operation also includes verifying the validity of the verification token.

[0017] By adopting the above technical solution, this solution creatively introduces a collaborative verification terminal as a trusted third party, providing a reliable time benchmark from a trusted environment (such as within the company) for field attendance tracking. By constructing a distributed "time witness" network, this solution solves the core challenges of unreliable terminal time and difficulty in verifying location in beacon-free field scenarios. It upgrades simple location claims to time-constrained verifiable events, significantly improving the credibility and auditability of the remote attendance tracking process.

[0018] Optionally, the method further includes a delayed authentication step: After receiving the attendance check-in result, the mobile terminal waits for a preset delay period and then silently collects third location information in the background and sends it to the background server. The backend server verifies the logical consistency between the third location information and the geographic location information associated with this attendance request; wherein, the delay duration is calculated based on the feasible timestamp.

[0019] By adopting the above technical solution and utilizing the trusted time anchors provided by collaborative verification, the timing of delayed auditing can be pseudo-randomly determined. This requires the entire cheating chain to simultaneously meet two strong constraints: "authentication must be completed at a trusted time point" and "it must still be in a reasonable position at a random future time." This upgrades the protection of a single mechanism to a spatiotemporally linked composite defense, greatly increasing the complexity and infeasibility of systemic and premeditated cheating.

[0020] Optionally, the method further includes: The backend server maintains a user behavior risk profile; when receiving an attendance request or performing a verification operation, it dynamically decides whether and how to enable one or more enhanced security verifications based on the user behavior risk profile, the feature information of the current attendance request, and the user's historical records. The feature information includes at least: check-in time anomaly, check-in geographical location unfamiliarity, and the generation frequency of dynamic authentication data; The enhanced security verification includes at least: trajectory analysis of the mobile terminal's movement trajectory during the attendance process; delayed collection of location information after successful attendance for post-event consistency verification; and the introduction of a collaborative verification terminal to impose time constraints on the attendance process.

[0021] By adopting the above technical solutions, this approach provides an intelligent, adaptive security policy engine. It dynamically determines the appropriate security verification combinations by quantitatively analyzing users' historical behavior patterns and real-time risk characteristics. This enables the system to achieve precise protection against events of different risk levels with minimal runtime overhead and user experience disruption. It changes the traditional "one-size-fits-all" static model of security solutions, achieving optimized allocation of security resources and a balance between overall system security performance and operational efficiency.

[0022] Secondly, this application provides a dynamic attendance system based on an NFC security tag, characterized in that it includes an NFC security tag, a mobile terminal, and a back-end server; The user's mobile terminal interacts with a preset NFC security tag via near-field communication to obtain dynamic authentication data generated by the NFC security tag; The mobile terminal generates an attendance request based on the dynamic authentication data and sends the attendance request to the backend server. The backend server receives attendance requests and performs verification operations, which include: performing cryptographic verification on the dynamic authentication data based on a security key pre-shared with the NFC security tag to verify the authenticity of the NFC security tag; and verifying whether the dynamic authentication data meets a preset uniqueness condition to prevent replay attacks. After successful verification, the backend server performs the attendance recording operation and sends the attendance check-in result to the mobile terminal, so that the mobile terminal can provide feedback on the attendance check-in result to the user.

[0023] Thirdly, this application provides a dynamic attendance device based on an NFC security tag, including a memory and a processor, wherein the memory stores a computer program that can be loaded by the processor and executed as described in any of the first aspects.

[0024] Fourthly, this application provides a computer-readable storage medium storing a computer program that can be loaded by a processor and executed as described in any of the first aspects.

[0025] In summary, this application includes at least one of the following beneficial technical effects: This application fundamentally solves the two major security vulnerabilities of existing QR code attendance solutions—the ease with which credentials can be cloned and replayed—by introducing an NFC security tag with dynamic authentication capabilities and utilizing a backend server for cryptographic verification and uniqueness checks. While maintaining the convenience of mobile attendance, this solution achieves reliable verification of the authenticity and uniqueness of attendance credentials for the first time at low cost, laying the technological foundation for highly secure mobile attendance.

[0026] Furthermore, by introducing a challenge-response protocol and a location-binding verification mechanism, dynamic authentication is strongly correlated with the user's claimed geographical location. This effectively prevents attackers from using legitimate tags to clock in at non-designated locations, achieving a "one-time password, one-location authentication" security effect. It is particularly suitable for fieldwork or distributed office scenarios that require verification of actual attendance location, adding a dimension against location spoofing on top of anti-cloning and anti-replay measures. Attached Figure Description

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

[0028] Figure 1 This is a flowchart illustrating the dynamic attendance method based on NFC security tags disclosed in an embodiment of this application.

[0029] Figure 2 This is a structural block diagram of the dynamic attendance system based on NFC security tags disclosed in the embodiments of this application.

[0030] Explanation of reference numerals in the attached diagram: 201, NFC security tag; 202, mobile terminal; 203, backend server. Detailed Implementation

[0031] The following is in conjunction with the appendix Figure 1-2 This application will be described in further detail.

[0032] This application discloses a dynamic attendance method based on an NFC security tag (hereinafter referred to as the dynamic attendance method). The executing entity is an NFC security tag-based dynamic attendance system (hereinafter referred to as the dynamic attendance system). The dynamic attendance system includes an NFC security tag, a mobile terminal (such as a mobile phone / computer) with an attendance application (i.e., an APP) installed, and a backend server. The mobile terminal has the capability to perform near-field communication (NFC) with the NFC security tag and communicates with the backend server via a network. The following will be described in conjunction with the attached... Figure 1 This section details the specific steps and procedures for implementing dynamic attendance methods in a dynamic attendance system.

[0033] S101, the user's mobile terminal interacts with the preset NFC security tag via near-field communication to obtain dynamic authentication data generated by the NFC security tag.

[0034] S102, the mobile terminal generates an attendance request based on dynamic authentication data and sends the attendance request to the backend server.

[0035] S103, the backend server receives the attendance request and performs a verification operation. The verification operation includes: performing cryptographic verification on the dynamic authentication data based on the security key pre-shared with the NFC security tag to verify the authenticity of the NFC security tag; and verifying whether the dynamic authentication data meets the preset uniqueness condition to prevent replay attacks.

[0036] S104 After successful verification, the backend server performs the attendance recording operation and sends the attendance check-in result to the mobile terminal so that the mobile terminal can provide feedback on the attendance check-in result to the user.

[0037] In practice, when a user needs to clock in, they open the attendance application (i.e., the APP) on their mobile device. This APP is logged into the user's account and bound to the mobile device's device identifier (such as the IMEI number) on the backend server. The employee brings their mobile device (with NFC enabled) close to an NFC security tag (e.g., in the form of a card or sticker). The mobile device reads the tag via the NFC interface.

[0038] When an NFC security tag is read, its internal security chip performs encryption based on a preset key and dynamic parameters (such as an internally maintained counter that increments after each read, or a random number) to generate currently valid dynamic authentication data, which is then returned to the mobile terminal. This dynamic authentication data is different each time it is read.

[0039] The mobile app will package the dynamic authentication data it reads, the device identifier of the device itself, and the identity identifier of the currently logged-in user (such as the user's login account) into an attendance request and send it to the backend server via the mobile network.

[0040] After receiving the attendance request, the backend server executes multiple validation logic: a. The backend server locates the security key K corresponding to the user's bound NFC security tag based on the user's identity information. It then uses this security key K to verify the received dynamic authentication data (e.g., decrypting and verifying the validity of a counter, or verifying a signature). This step confirms that the request originates from a legitimate, uncloned NFC security tag.

[0041] b. Next, the backend server checks whether the dynamic parameters (such as counter values) associated with the dynamic authentication data in this attendance request are within a valid window and have not been used before, to prevent the same authentication data from being reused (i.e., the preset uniqueness condition: based on the validity and first-time use of the counter). Specifically, in one embodiment, the dynamic authentication data generated by the NFC security tag includes an encrypted, unidirectionally increasing counter value maintained by its security chip. The backend server stores the valid counter value corresponding to the last successful verification of the tag. When a new attendance request is received, the server decrypts the dynamic authentication data, extracts the counter value, and verifies whether it meets the following conditions: 1) it is greater than the last valid counter value stored by the backend server; and 2) the deviation from the current time of the backend server is within a preset reasonable time window (for example, the theoretical time corresponding to the counter value differs from the current time of the server by no more than 5 minutes). If both conditions are met, the dynamic authentication data is determined to be used for the first time, and the stored valid counter value is updated.

[0042] c. The backend server verifies whether the terminal device identifier in the request matches the device identifier pre-bound to the user account that initiated the attendance request, in order to prevent the use of someone else's mobile terminal to clock in on behalf of another person.

[0043] If all the above checks (a, b, c) pass, the backend server determines that the attendance request is valid, executes the core attendance recording operations (such as recording employee ID and check-in time), and returns the successful check-in result (i.e., attendance check-in result) to the mobile terminal APP. If any of the above checks (a, b, c) fail, the backend server determines that the attendance request has failed, and sends the failed check-in result (i.e., attendance check-in result) back to the mobile terminal APP so that the mobile terminal APP can display the corresponding attendance check-in result.

[0044] In summary, mobile terminal apps solve the problems of credential cloning and replay through dynamic authentication of NFC security tags, and solve the problem of device-based attendance tracking through terminal-user binding.

[0045] Optionally, S101 specifically includes the following sub-steps: S1011, The mobile terminal sends a challenge request to the backend server. The challenge request includes the first location information and user identity identifier obtained based on the mobile terminal. S1012, the backend server responds to the challenge application, verifies the user's identity and legitimacy, and determines the expected geofence based on the first location information; generates a one-time random challenge code, associates and binds the challenge code with the user's identity identifier and geofence, and sends it to the mobile terminal; S1013 After receiving the challenge code, the mobile terminal sends a cryptographic calculation command containing the challenge code to the NFC security tag through the near field communication interface; S1014, the security chip of the NFC security tag responds to cryptographic calculation instructions, uses a preset security key to perform cryptographic operations on the challenge code, and generates dynamic authentication data; S1015, the mobile terminal reads the dynamic authentication data generated by the NFC security tag through the near field communication interface; The attendance request includes the second location information obtained by the mobile terminal when or after reading the dynamic authentication data; The verification process also includes verifying whether the second location information is within the geofence bound to the challenge code.

[0046] In implementation, in a typical application scenario of this embodiment, the NFC security tag (e.g., in the form of a card or sticker) is held by the user. To overcome the potential problem of remote location spoofing in this scenario, this optional solution embodiment achieves reliable verification of the user's true physical location through the following challenge-response protocol and location binding verification mechanism. The specific process is as follows: Step 1: Initialize Check-in and Apply for Challenge 1-1: Employees open the attendance mobile terminal application (APP) at the field location where they need to clock in.

[0047] 1-2: The APP automatically or manually triggers the check-in process, first obtaining the current location information L1 of the mobile terminal (i.e., the first location information, such as the latitude and longitude coordinates obtained through GPS, Wi-Fi or base station positioning).

[0048] 1-3: The APP will send a challenge application request containing the user's identity identifier and first location information L1 to the backend server.

[0049] Step 2: The server generates and distributes the location binding challenge. 2-1: After receiving the challenge application request, the backend server first verifies the legitimacy of the user's identity.

[0050] 2-2: The backend server determines an expected precise geofence G based on the first location information L1 (e.g., a circular area with a radius of 500 meters centered on the first location information L1, or an electronic fence generated based on pre-stored customer address information).

[0051] 2-3: The backend server generates a one-time, random challenge code C. It should be noted that, to ensure the unpredictability, uniqueness, and collision resistance of the challenge code C, the backend server will use the following steps to generate the challenge code C: The backend server invokes a cryptographically secure pseudo-random number generator (CSPRNG) provided by its operating system or secure hardware module to generate a random byte sequence of a specified length. The entropy source of this generator comes from high-quality random events in the system, such as hardware noise and interrupt timing. The length is determined based on the strength of the selected cryptographic algorithm; for example, for a 128-bit security strength, a 16-byte (128-bit) random byte sequence Rand is generated. To facilitate transmission, recording, and tamper-proofing, the server combines the random byte sequence with other information to generate a structured challenge code C. A typical construction method is as follows: Timestamp: The current high-precision timestamp (e.g., a Unix timestamp, accurate to milliseconds) added to the server.

[0052] Identifier: A unique identifier for the user joining this session, either SessionID or UserID.

[0053] Calculation and Encoding: Concatenate the above data (Rand, Timestamp, SessionID) and calculate its cryptographic hash value (e.g., using the SHA-256 algorithm) as the final challenge code C. That is: C = SHA256(Rand||Timestamp||SessionID) Optional encoding: Convert the binary hash result C into a text format that is easy to transmit, such as Base64 or a hexadecimal string.

[0054] Upon generating challenge code C, the backend server internally associates and binds challenge code C, the user identifier, and the geofence G, storing them in a pre-defined list of valid challenges. For example, a temporary record is created, including the following fields: Challenge: C; UserID: [corresponding user identifier]; GeoFence: G (bound geofence information); Timestamp: [generation time]; Status: ACTIVE (status, indicating active). Furthermore, the backend server sets an expiration time for each challenge record (e.g., TTL = 120 seconds). Any challenge code exceeding the TTL will be automatically deleted, and its status will be set to EXPIRED. Once a challenge code is successfully used (to verify a check-in request), its status is immediately set to USED and it becomes invalid.

[0055] 2-4: The backend server sends the generated challenge code C (in text or binary format) to the mobile terminal APP via an encrypted communication link (such as HTTPS).

[0056] Step 3: NFC Security Tag Generation Challenge Response 3-1: After receiving challenge code C, the mobile terminal APP prompts the user to "Please place your phone close to your NFC tag".

[0057] 3-2: The user first brings the mobile device close to the NFC security tag they personally possess.

[0058] 3-3: The mobile terminal APP sends a cryptographic calculation command to the NFC security tag through the near field communication (NFC) interface. The cryptographic calculation command contains the challenge code C.

[0059] 3-4: After receiving the cryptographic calculation instruction, the security chip of the NFC security tag calls its internal threshold security key K to perform cryptographic operations on the received challenge code C (e.g., using the HMAC-SHA256 algorithm to calculate the message authentication code, or using the elliptic curve digital signature algorithm to generate a digital signature), generating a dynamic response data R. This dynamic response data R is mathematically strongly correlated with the challenge code C and the security key K.

[0060] 3-5: After generating dynamic response data R, the NFC security tag stores it in a preset readable area. The mobile app prompts the user, "Please bring the tag close again to complete the check-in."

[0061] 3-6: When the user brings the mobile terminal close to the NFC security tag for the second time, the mobile terminal APP reads the dynamic response data R stored in the NFC security tag through the NFC interface.

[0062] Step 4: Submit the check-in request and undergo multiple verifications on the server side. 4-1: The mobile terminal APP obtains the latest high-precision location information L2 (i.e., second location information).

[0063] 4-2: The mobile terminal APP packages the dynamic response data R, the second location information L2, and the user identity identifier into a final attendance check-in request and sends it to the backend server.

[0064] Step 5: The server performs dual security and location verification. After receiving the attendance check-in request, the backend server executes the following verification logic sequentially; if any step fails, the check-in fails: 5-1: Check if the challenge code C associated with the user identity in the attendance check-in request exists in the current valid challenge list and has not expired (i.e., has not exceeded the set validity period).

[0065] 5-2: The backend server uses the same security key K, which is pre-shared with the NFC security tag in its database, to verify whether the dynamic response data R is a valid cryptographic response to the challenge code C. That is, it verifies whether the equation or signature holds true: Verify(K, C, R) == True. This step verifies the "authenticity and uniqueness of the credential".

[0066] 5-3: The backend server verifies whether the submitted second location information L2 falls within the corresponding geofence G and is inconsistent with the location information L1.

[0067] If steps 5-1, 5-2, and 5-3 are met simultaneously, the verification passes, and the backend server determines that the attendance request is legal, valid, and successful. Upon successful verification, the backend server immediately invalidates the challenge code C used (removes it from the valid list) to ensure that the same challenge cannot be reused; simultaneously, it executes the core business logic of attendance tracking (such as recording the check-in time, location, and user) and updates the database. Regardless of whether the verification passes or not, the backend server sends feedback on the success or failure of the attendance tracking to the mobile app, allowing the mobile app to display the feedback result to the user.

[0068] Optionally, dynamic attendance methods may also include a trajectory analysis step: S301: During the time period between when the mobile terminal sends the challenge application and when it reads the dynamic authentication data, the mobile terminal continuously collects location information at a frequency higher than a preset frequency, forming a location data stream that is sent to the backend server.

[0069] S302, the background server analyzes the location data stream to detect whether there are abnormal patterns in the mobile terminal's movement trajectory within a time period; wherein, the abnormal pattern includes at least one of the following: the movement speed or acceleration violates the laws of physics, or the movement trajectory does not match the geographical environmental features indicated by the first location information or the second location information.

[0070] In implementation, to address the vulnerability that attackers might fake attendance at fixed locations but cannot simulate real movement trajectories, this application further provides a trajectory analysis step as an enhanced monitoring of the core attendance process. This step is executed in parallel with the aforementioned optional steps (challenge-response protocol and location binding verification mechanism), and the specific process is as follows: S3.1 (High-Frequency Positioning Data Acquisition): After the mobile terminal completes step S1011 (sends challenge application), its attendance application (APP) immediately activates the high-frequency positioning service, continuously collecting GPS, Wi-Fi, or base station positioning information at a frequency higher than the normal required frequency (i.e., the preset frequency) (e.g., once per second), forming a dense stream of positioning data. This acquisition process continues until step S1015 (reads dynamic authentication data) is completed.

[0071] S3.2 (Real-time Data Stream Reporting): The collected location data stream is encapsulated into data packets in real-time or near real-time and sent to the backend server via the mobile network. To ensure timeliness, short-connection or long-connection channels can be used for streaming transmission.

[0072] S3.3 (Server-side Trajectory Modeling and Anomaly Detection): The backend server has a trajectory analysis engine. After receiving the location data stream, the trajectory analysis engine executes the following core analysis logic: S3.3.1: Calculate the distance, velocity and acceleration between adjacent positioning points (i.e., the position information of adjacent moments in the positioning data stream), and determine whether there are any abnormal situations that violate the laws of natural human movement, such as "instantaneous movement" (velocity exceeding the limit) or uniform linear motion (acceleration is always zero and continuous).

[0073] S3.3.2: Match the location trajectory with the electronic map database. The backend server matches the location trajectory with the electronic map database (which contains vector data of geographic features and their attribute information. For example, when using the well-known geographic database OpenStreetMap (OSM), features such as roads and buildings are defined by "key-value" pairs (Tags)). The following quantifiable judgments are performed: The latitude and longitude coordinates of each location point are obtained. Through the spatial query interface of a Geographic Information System (GIS), it is determined whether the location is within the buffer zone of a passable geometric polygon or linear feature that conforms to the above tag definitions (e.g., highway=*, building=entrance, etc.; where highway=* is a tag matching pattern indicating that all geographic features for which the highway key is defined with any value (* represents a wildcard). In OSM, the highway key... Used to identify all traversable paths, such as highway=motorway, highway=residential, highway=footway, etc. Therefore, the traversable area layer referred to by "highway=*" is the geometric set of all traversable routes marked as roads, paths, etc. in the OSM database. "building=entrance" indicates a geographic feature with the key "building" set to "entrance," i.e., a building entrance. It is included in the traversable area because, in an attendance scenario, it is reasonable for employees to clock in at the building entrance.

[0074] If multiple consecutive location points fall into clearly impassable areas (such as lakes, enclosed private property, or other areas not marked as passable), it is considered an anomaly.

[0075] If most points of the trajectory are located on roads, calculate the average movement speed of the trajectory; if the average movement speed is lower than the minimum walking speed limit (e.g., 1 km / h) or higher than the urban road speed limit (e.g., 80 km / h) for a continuous specified period of time, it is determined that it does not conform to the "road driving" characteristic.

[0076] If the trajectory points are located within the building polygon, calculate the dispersion of the trajectory points (such as the average distance from all points to their centroid). If the dispersion is too large (e.g., exceeding the typical size of the building), or the movement speed is consistently high, it is determined that it does not conform to the "indoor activity" characteristic.

[0077] Calculate the planar distance D1 between the starting point of the trajectory and the first position information L1, and the planar distance D2 between the ending point of the trajectory and the second position information L2; set a reasonable error threshold ε (e.g., 50 meters, depending on the positioning accuracy); if D1 > ε or D2 > ε, it is determined that the trajectory endpoint deviates significantly from the claimed check-in location, which is abnormal.

[0078] S3.3.3: The backend server obtains the precise time of the NFC interaction (e.g., T_touch1 is the start time of the first touch, T_touch2 is the completion time of the second touch) and performs the following analysis: A time window [T_touch – ΔT, T_touch + ΔT] is defined centered on each interaction time T_touch. ΔT is a preset short time interval based on user habits, e.g., ΔT = 2 seconds. All location points within the above time window are extracted. If the standard deviation of latitude and longitude of all location points within the time window is less than a very small threshold (e.g., 0.00001 degrees, approximately 1 meter), they are considered stationary. The maximum distance D_max between all adjacent location points within the time window is calculated. If D_max is less than a preset "micro-motion distance threshold" (e.g., 5 meters), it is considered micro-motion. This threshold is set based on "the range of natural body movement that may occur when a user holds the phone close to the device." If, for any NFC interaction moment, the location point data within the corresponding time window does not meet the criteria for "stationary" or "micro-movement" (i.e., a large range of movement has occurred), then it is determined that the posture at the interaction moment is abnormal.

[0079] S3.4 (Risk Assessment and Handling): If the trajectory analysis engine detects any of the above anomalies, it generates a preset risk level identifier corresponding to the detected anomaly, and generates an anomaly record to be fed back to the user terminal with administrator status for manual review by the administrator.

[0080] Optionally, after the backend server sends the attendance check-in results, the dynamic attendance method also includes a delayed authentication step: S401: After receiving the attendance check-in result, the mobile terminal waits for a preset delay period, then silently collects third-party location information in the background and sends it to the background server.

[0081] S402, the backend server verifies the logical consistency between the third-party location information and the geographic location information associated with this attendance request.

[0082] In implementation, to further prevent employees from leaving the attendance point immediately after successfully clocking in, this invention adds a hidden delayed authentication step after the core process is completed. The specific execution process is as follows: S4.1 (Delayed Triggering and Silent Data Acquisition): After step S104 (background server executes attendance recording) and sends the attendance check-in result to the mobile terminal, the mobile terminal APP does not immediately terminate the process. Instead, it starts a background timer, waiting for a preset delay duration (e.g., randomly between 5 and 30 minutes). During this period, the mobile terminal APP remains completely silent to the user. After the delay duration is reached, the mobile terminal APP automatically wakes up in the background and calls the positioning module again to silently acquire the current precise third location information L3.

[0083] S4.2 (Delayed Location Reporting): After collecting the third location information L3, the mobile terminal APP sends the third location information L3 and the unique identifier for this attendance to the backend server through the backend network connection.

[0084] S4.3 (Server-side logical consistency verification): After receiving the third-party location information L3, the backend server executes delayed verification logic: S4.3.1 Location Persistence Verification: Determine the spatial relationship between the third location information L3 and the geofence G (or the second location information L2) associated with this attendance. If the third location information L3 is still within the geofence G or within its reasonable perimeter (e.g., within 500 meters), it passes. If L3 shows that it is tens of kilometers away, it is considered abnormal.

[0085] S4.3.2 Mobility Possibility Verification: Calculate the time difference ΔT by combining the attendance success timestamp with the collection timestamp of the third location information L3. Based on ΔT and the distance D from the second location information L2 to the third location information L3, calculate the average movement speed V = D / ΔT. If V exceeds a reasonable vehicle speed (such as the upper limit of commuting speed in an urban area), it is considered abnormal.

[0086] S4.4 Audit and Follow-up Processing: The result of delayed verification does not affect the successful check-in status already reported to the user, but it will be sent to the user terminal with administrator privileges as an audit log record.

[0087] Optionally, the dynamic attendance method also includes a collaborative verification step, which is as follows: S501, after the mobile terminal sends the challenge application, the backend server or the mobile terminal designates at least one collaborative verification terminal and sends a verification request to the designated collaborative verification terminal. S502, the collaborative verification terminal responds to the verification request, generates a verification token containing a trusted timestamp, and sends it to the backend server; S503: The backend server receives the verification token and generates time constraint information based on the trusted timestamp in the verification token, and sends the time constraint information to the mobile terminal. The interaction process between the mobile terminal and the NFC security tag, and / or the generation of attendance requests, must meet time constraint information; The verification process also includes verifying the validity of the verification token.

[0088] In implementation, to address the lack of trusted location references in field scenarios, this application creatively introduces a collaborative verification terminal, constructing distributed trust through social networks and time cryptography. This process is interwoven with a challenge-response protocol and a location binding verification mechanism, with the specific steps as follows: S5.1 (Collaborative Verifier Selection and Request): Simultaneously with or after step S1011 (Mobile Terminal Sends Challenge Request), the backend server's collaborative scheduling module executes the following selection logic: It's important to note beforehand that to enable intelligent selection of collaborative verifiers, the backend server maintains a user status database. This database is a real-time or near real-time in-memory database (such as Redis) or a high-speed cache table within a relational database. Its core fields and update mechanism are as follows: Data Structure (Content): This database maintains a status record for each registered mobile terminal (i.e., a potential collaborative verification terminal). The record must contain at least the following fields: user_id: Unique user identifier. device_id: Unique mobile terminal device identifier (bound to the device certificate). online_status: Online status indicator (true / false), indicating whether the long-term connection between the mobile terminal and the server is active. last_reported_location: The mobile terminal's most recent actively or passively reported geographical location information (latitude and longitude coordinates and source, such as GPS / Wi-Fi). last_ip_address: The IP address of the mobile terminal's most recent communication with the server. last_activity_time: The timestamp of the mobile terminal's last activity (such as heartbeat, check-in, or response to a request). trust_level: Device trust level, calculated based on device certificate status, security audit history, etc. verification_count: The number of times you have acted as a co-verifier recently (e.g., within 24 hours).

[0089] Online status is updated in real time via a heartbeat connection or push channel maintained between the mobile terminal and the backend server. When the connection is lost, online_status is automatically set to false.

[0090] The geographic location and IP address are updated in any of the following events: the location information (L1 / L2) reported by the mobile terminal is updated each time the mobile terminal checks in; the source IP address of the connection is recorded and updated when the mobile terminal interacts with the server in any network; the mobile terminal APP can silently report a rough location (city level) in the background at a set period.

[0091] The last active time is updated when any valid data interaction occurs between the terminal and the server.

[0092] Trust level updates are triggered by the following events: Upon initial registration, after the device completes a secure boot and installs a valid certificate, the initial trust level is set. If abnormal logins or expired certificates are detected, the system automatically downgrades the level. The level is periodically reviewed and manually / automatically adjusted by the administrator or security system.

[0093] Each time a terminal is successfully selected as a co-verifier and completes a verification task, its verification_count is incremented. This count is atomically updated by the backend server when the task is assigned and after the task is completed, and can be reset or decayed by a scheduled task (such as at midnight every day).

[0094] When the collaborative verification process is formally executed, the backend server obtains the following status factors of candidate collaborative verification terminals from the user status database in real time: Online status: The terminal maintains an active network connection with the server, and its attendance application process runs in the foreground or background.

[0095] Geographic location: Whether the terminal's most recently reported GPS / Wi-Fi location information, or the IP address it is connected to, falls within a preset trusted area (such as the IP range of a company's office network).

[0096] Device trustworthiness: Has the terminal completed the company's internal security registration and certification? Is its device certificate valid and not blacklisted?

[0097] The collaborative scheduling module selects from eligible candidate terminals according to a preset strategy. The strategy includes at least one of the following: Randomization strategy: Select one terminal completely randomly from all currently online terminals located in the trusted zone.

[0098] Load balancing strategy: Select the terminal that has acted as a co-verifier the fewest times recently.

[0099] Social connection strategy: Prioritize terminals that are in the same department, project team, or have a history of collaboration with the initiator (main check-in user).

[0100] After a collaborative verification terminal is selected, the backend server pushes a verification request containing the ID of the current attendance session to it.

[0101] S5.2 (Generation of Trusted Timestamp Token): After receiving the verification request, the attendance service (or independent APP) on the collaborative verification terminal obtains a high-precision, tamper-proof Network Time Protocol (NTP) time from the company's trusted internal network (the company's trusted internal network is equipped with a local NTP server that is synchronized with an authoritative time source and configured with security policies to prevent external time spoofing attacks), denoted as T_witness. Subsequently, the collaborative verification terminal uses its internally securely stored device private key K_private_device to perform a digital signature operation on T_witness, generating a verification token Token, and returns it to the backend server. The process of generating the verification token Token is as follows: The timestamp T_witness and the unique identifier of this verification session, session_id, are concatenated, and their hash value H = Hash(T_witness || session_id) is calculated, where Hash is a cryptographic hash function (such as SHA-256). The hash value H is digitally signed using the device private key K_private_device, resulting in the signature value Sig = Sign(K_private_device, H). Here, Sign represents a digital signature algorithm (such as ECDSA with P-256). The original timestamp T_witness, session_id, and the aforementioned signature value Sig are serialized (e.g., using JSON format) and encoded (e.g., Base64) to form the final verification token.

[0102] S5.3 (Time Constraint Information Generation and Distribution): After the backend server checks the signature validity of the verification token (e.g., verifying whether the corresponding digital signature exists in a pre-stored signature database containing the digital signatures of all current employees of the company), it extracts the trusted timestamp T_witness. Based on the trusted timestamp T_witness, the backend server generates time constraint information. For example, the time constraint information could be: "The main check-in process must be completed within 60 seconds after T_witness." The backend server then distributes this time constraint information to the main check-in mobile terminal.

[0103] S5.4 (Main Process Constrained Execution): After receiving the time constraint information, the main mobile terminal must ensure that the entire process defined in S1011, S1012, S1013, S1014, and S1015—"the user's mobile terminal interacts with the preset NFC security tag via near-field communication to obtain dynamic authentication data"—(i.e., the series of steps from sending the challenge application to reading the dynamic authentication data) meets the time constraint. The specific execution plan is dynamically adjusted by the mobile terminal APP based on the content of the time constraint information, and systematically includes at least one of the following: Start time constraint: If the time constraint information is "the process must start after T_witness", then the mobile terminal APP will suspend sending any instructions to the NFC security tag before the local time reaches T_witness.

[0104] Completion Time Constraint: If the time constraint information is "the process must be completed within Δt seconds after T_witness", then the mobile terminal APP starts timing from the time T_witness and monitors the entire interaction process. If the total process time is close to Δt, the user is prompted to speed up the operation; if the timeout occurs, the current check-in is automatically terminated and a failure is reported.

[0105] Key Node Timestamp Binding: When generating the final attendance request, the mobile terminal must include the trusted timestamp T_witness as a mandatory field in the request data packet, or use T_witness as a parameter to generate a secondary signature for this request, so that the backend server can verify the logic of the entire event timeline in S5.5.

[0106] S5.5: When the background server performs the verification operation described in S103, in addition to the original verification operation, the background server performs the following additional verifications in parallel: Token validity verification: The received verification token (Token) is digitally signed using a pre-stored public key of the device certificate bound to the collaborative verification terminal. If the signature is invalid, or the timestamp T_witness in the token has expired (e.g., the time difference with the server's current time exceeds a preset threshold such as 120 seconds), the token is deemed invalid.

[0107] Time constraint compliance verification: If the attendance request includes T_witness, the backend server calculates the time difference between T_witness and the time the backend server receives the attendance request, and determines whether it is within a reasonable allowable range (e.g., 0 to 65 seconds). The backend server verifies whether the timestamps of key events in this attendance process (e.g., challenge code generation time, mobile terminal reading dynamic authentication data time) are all later than T_witness. If the time constraint information is "complete within Δt seconds after T_witness", the server verifies whether the actual time from T_witness to process completion is less than Δt.

[0108] If any of the above-mentioned new checks fails, the entire attendance verification result will be "failed". If all checks pass, the time constraint compliance verification is considered successful.

[0109] Optionally, dynamic attendance methods may also include a delayed authentication step: S601: After receiving the attendance check-in result, the mobile terminal waits for a preset delay period of time, then silently collects third-party location information in the background and sends it to the background server. S602, the backend server verifies the logical consistency between the third location information and the geographical location information associated with this attendance request; the delay duration is calculated based on the feasible timestamp.

[0110] The specific steps involved in implementation are as follows: S6.1: In step S5.3, when the backend server generates time constraint information, it calls its cryptographically secure pseudo-random number generator (CSPRNG) to generate a random delay offset Δ within a preset interval [Δ_min, Δ_max] (e.g., [300, 1800] seconds) based on a trusted timestamp T_witness. The backend server calculates the delay trigger time T_delay = T_witness + Δ, and sends T_delay as part of the time constraint information to the main card-playing mobile terminal.

[0111] S6.2: The main check-in process (the entire process defined in S1011, S1012, S1013, S1014, and S1015, which involves "the user's mobile terminal interacting with a preset NFC security tag to obtain dynamic authentication data" (i.e., the series of steps from sending a challenge application to reading dynamic authentication data)) is completed after meeting the time constraint information. The mobile terminal APP stores the delayed trigger time T_delay in the local secure storage area (such as Android's KeyStore or iOS's Keychain), and then normally ends the front-end interaction of the mobile terminal APP, showing the user that the check-in was successful.

[0112] S6.3: When the mobile terminal system time reaches the delay trigger time T_delay, the mobile terminal APP is woken up in the background and automatically executes the delayed location collection and reporting process in steps S4.1 to S4.3. At this time, the APP collects the third location information L3 and simultaneously records the current system time as the collection timestamp T_collect for this location information. Subsequently, the APP sends L3 and T_collect together to the backend server. The expected collection time T_delay of L3 collected at this time is strongly correlated with the collaborative verification time T_witness.

[0113] S6.4: After the backend server contains the data from L3 and T_collect, it executes the delayed verification logic: Calculate the absolute time difference |T_collect-T_delay| between the collected timestamp T_collect and the planned delay time T_delay. If this difference is greater than a preset allowable time deviation threshold δ_t (e.g., δ_t = 30 seconds), the time consistency check is deemed to have failed.

[0114] Calculate the planar distance D between the third location information L3 and the center of the geofence G associated with this attendance (or the second location information L2). Simultaneously, calculate the time interval ΔT_total from the successful attendance time (i.e., the time of verification in step S103) to T_collect.

[0115] Based on the time interval ΔT_total and the planar distance D, the required average moving speed V_avg = D / ΔT_total is calculated. If V_avg exceeds a preset reasonable moving speed threshold V_max (for example, V_max = 120 km / h, which is a relatively high speed achievable in the city), it is determined that the movement from the check-in point to the point at time T_delay is physically impossible, and the verification fails.

[0116] This scheme pseudo-randomly binds the triggering time of "delayed authentication" to a trusted time anchor point provided by "collaborative verification," requiring the entire fraud chain to simultaneously meet the following conditions: 1) the NFC interaction is completed near a trusted time point; 2) the location remains at a reasonable geographical location at an unpredictable future time. This significantly increases the complexity and infeasibility of systematic and premeditated fraud.

[0117] Optionally, dynamic attendance methods may also include the following steps: The backend server maintains a user behavior risk profile; when receiving an attendance request or performing a verification operation, it dynamically decides whether and how to enable one or more enhanced security verifications based on the user behavior risk profile, the feature information of the current attendance request, and the user's historical records. Among them, the feature information includes at least: the anomaly of check-in time, the unfamiliarity of check-in geographical location, and the generation frequency of dynamic authentication data; Enhanced security verification includes at least: trajectory analysis of the mobile terminal's movement trajectory during the attendance process; delayed collection of location information after successful attendance for post-event consistency verification; and the introduction of collaborative verification terminals to impose time constraints on the attendance process.

[0118] In implementation, to intelligently allocate the aforementioned security resources and achieve the optimal balance between security and efficiency, this application further provides an adaptive security policy engine. Its workflow is as follows: The S7.1 backend server maintains a dynamic risk profile for each user. This profile is represented by a set of quantifiable data structures and their update algorithms. 1. Time Regularity Model: The data structure is an integer array M_time[0……23] of length 24. Array index i corresponds to the i-th hour of the day (0 at 0:00, 23 at 23:00 is 23). The value of M_time[i] represents the number of times the user's check-in occurred within the i-th hour in all historical check-ins. The update algorithm is as follows: whenever a user's check-in verification is successful, let the hour of their check-in time be h (0≤h≤23), then execute M_time[h] = M_time[h]+1.

[0119] 2. Spatial Regularity Model: The data structure is a list M_loc, where each element is a quadruple (center_lat, center_lon, radius, count), representing a historical resident location cluster, containing the center point's latitude and longitude, cluster radius (meters), and the number of times a check-in was performed within that cluster. The update algorithm is as follows: for a new valid check-in location P(lat, lon), calculate its distance to the center of each cluster in M_loc. If the distance is less than or equal to the cluster's radius, increment the cluster's count by 1; otherwise, add (lat, lon, R_default, 1) as a new cluster to M_loc, where R_default is a preset initial radius (e.g., 100 meters).

[0120] 3. Operational Speed ​​Baseline: The data structure consists of a fixed-capacity (e.g., 20 times) queue M_speed.queue recording the most recently successfully completed process times, maintaining its mean M_speed.μ and standard deviation M_speed.σ. The update algorithm is as follows: when a new process time d is generated, it is added to the tail of M_speed.queue; if the queue is overloaded, the head element is removed, and then M_speed.μ and M_speed.σ are recalculated.

[0121] Whenever a new attendance request is received, the adaptive security policy engine takes the model defined in S7.1 as input, performs the following calculations, and outputs a standardized real-time risk feature score: 1. Calculation of Time Anomaly Score F_time: The hour h_current of the current check-in time (extracted from the timestamp of the check-in request). Input the time regularity model; calculate the total number of historical check-ins N_total = Σ_{i=0}^{23}M_time[i]. If N_total == 0 (new user), set N_total = 1 to avoid division by zero. Calculate the historical probability P = M_time[h_current] / N_total for check-ins in the h_current hour. Calculate F_time = -log(P + ε). Where ε is a very small positive number (e.g., 1e-10) to prevent taking the logarithm of zero. The larger this value, the more abnormal the check-in time.

[0122] 2. Calculation of Geographical Location Unfamiliarity Score F_loc: Input the initial location information P_current(lat_c, lon_c) into the spatial regularity model. If M_loc is empty, then F_loc = 0 (no historical location, not considered unfamiliar). Otherwise, calculate the minimum spherical distance D_min (in meters) from P_current to the center point of each cluster in M_loc, F_loc = D_min. This value is directly expressed in meters; the larger the value, the more unfamiliar the location.

[0123] 3. Calculation of the frequency anomaly score F_freq: Input the current time T_now and the last time the user successfully generated dynamic authentication data (T_last) recorded in the system into the operation speed baseline, and calculate the time interval Δt = T_now - T_last (seconds). Set a reasonable minimum interval threshold T_min (e.g., 10 seconds). Calculate F_freq = max(0, (T_min - Δt) / T_min); when Δt ≥ T_min, F_freq = 0; when Δt < T_min, F_freq increases linearly between 0 and 1.

[0124] The S7.3 adaptive security policy engine calculates a comprehensive risk score R = Σ(Wi * Si) by weighting and summing the scores of each real-time risk feature extracted in S7.2 [S1, S2, S3…] with a preset weight vector [W1, W2, W3…]. The weight Wi can be configured according to management strategies (e.g., geographical unfamiliarity has the highest weight). The engine then compares R with preset tiered thresholds (threshold 1, threshold 2) to determine the enhanced verification combination to be enabled. This decision can be directly mapped to a preset policy table, for example: If R < threshold 1, then the policy is identified as policy_basic: only perform basic verifications of S101 to S104 and S1011-S1015.

[0125] If threshold 1 ≤ R < threshold 2, then the strategy is identified as strategy_intermediate: on the basis of basic verification, selectively enable trajectory analysis steps (i.e., S301, S302) or delayed authentication steps (i.e., S401, S402).

[0126] If R ≥ threshold 2, the policy is identified as Policy_Advanced: Force the activation of trajectory analysis steps (i.e. S301, S302) and collaborative verification steps (i.e. S501, S502, S503), and may be accompanied by delayed authentication based on collaborative verification (i.e. S601, S602).

[0127] The S7.4 adaptive security policy engine distributes the decision results (i.e., the enhanced verification combinations to be enabled) to the corresponding processing units (such as the trajectory analysis engine, collaborative scheduling module, and delayed authentication scheduler). Each processing unit executes the instructions. Simultaneously, the execution results of each processing unit (such as whether the trajectory analysis is abnormal or whether delayed authentication passes) are returned to the engine as feedback signals. Based on the final result (success / failure) and feedback signals of this attendance check, the engine iteratively optimizes the risk profile according to the following rules: If the check-in is successful and no enhanced verification is reported as an anomaly: the check-in time, location and other data are regarded as positive samples and used to strengthen the corresponding baseline indicators in S7.1 (for example, the current location is included in the permanent set and the average response time is updated).

[0128] If check-in fails or any enhanced verification reports a high-risk anomaly, the real-time risk characteristics for that instance will be treated as a negative sample. The engine can automatically increase the weight Wi of the basic risk characteristics most relevant to that anomaly, or trigger a manual review alert for the user profile in the management interface.

[0129] This application also discloses a dynamic attendance system based on NFC security tags. (See also...) Figure 2 This includes an NFC security tag 201, a mobile terminal 202, and a backend server 203; The user mobile terminal 202 interacts with the preset NFC security tag 201 via near-field communication to obtain dynamic authentication data generated by the NFC security tag 201. Mobile terminal 202 generates an attendance request based on dynamic authentication data and sends the attendance request to backend server 203; The backend server 203 receives the attendance request and performs a verification operation, which includes: performing cryptographic verification on the dynamic authentication data based on the security key pre-shared with the NFC security tag 201 to verify the authenticity of the NFC security tag 201; and verifying whether the dynamic authentication data meets the preset uniqueness condition to prevent replay attacks. After successful verification, the backend server 203 performs the attendance recording operation and sends the attendance check-in result to the mobile terminal 202, so that the mobile terminal 202 can provide feedback on the attendance check-in result to the user.

[0130] This application also discloses a dynamic attendance device based on an NFC security tag. The dynamic attendance device based on an NFC security tag includes a memory and a processor. The memory stores a computer program that can be loaded by the processor and executed as described above for the dynamic attendance method based on an NFC security tag.

[0131] This application also discloses a computer-readable storage medium that stores a computer program that can be loaded by a processor and executed as described above for the dynamic attendance method based on an NFC security tag. The computer-readable storage medium includes, for example, various media capable of storing program code, such as a USB flash drive, a portable hard drive, a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk.

[0132] It should be noted that in this paper, relational terms such as first and second are used only to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any such actual relationship or order between these entities or operations.

[0133] The above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit the scope of protection of the application. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on these embodiments, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

Claims

1. A dynamic attendance method based on NFC security tags, characterized in that, include: The user's mobile terminal interacts with a preset NFC security tag via near-field communication to obtain dynamic authentication data generated by the NFC security tag; The mobile terminal generates an attendance request based on the dynamic authentication data and sends the attendance request to the backend server. The backend server receives the attendance request and performs a verification operation, which includes: performing cryptographic verification on the dynamic authentication data based on the security key pre-shared with the NFC security tag to verify the authenticity of the NFC security tag; It also verifies whether the dynamic authentication data meets the preset uniqueness condition to prevent replay attacks; After successful verification, the backend server performs the attendance recording operation and sends the attendance check-in result to the mobile terminal, so that the mobile terminal can provide feedback on the attendance check-in result to the user.

2. The dynamic attendance method based on NFC security tags according to claim 1, characterized in that, The user mobile terminal interacts with a preset NFC security tag via near-field communication to obtain dynamic authentication data generated by the NFC security tag, including: The mobile terminal sends a challenge request to the backend server, and the challenge request includes first location information and user identity identifier obtained based on the mobile terminal. The backend server responds to the challenge application, verifies the legitimacy of the user's identity, and determines the expected geofence based on the first location information; it generates a one-time random challenge code, associates and binds the challenge code with the user's identity identifier and the geofence, and then sends it to the mobile terminal. After receiving the challenge code, the mobile terminal sends a cryptographic calculation command containing the challenge code to the NFC security tag through the near field communication interface; The security chip of the NFC security tag responds to the cryptographic calculation instruction and uses a preset security key to perform cryptographic operations on the challenge code to generate dynamic authentication data. The mobile terminal reads the dynamic authentication data generated by the NFC security tag through the near-field communication interface; The attendance request includes the second location information obtained by the mobile terminal when or after reading the dynamic authentication data; The verification operation further includes: verifying whether the second location information is located within the geofence bound to the challenge code.

3. The dynamic attendance method based on NFC security tags according to claim 2, characterized in that, The method also includes a trajectory analysis step: During the time period between the mobile terminal sending the challenge application and the reading of the dynamic authentication data, the mobile terminal continuously collects location information at a frequency higher than a preset frequency, forming a location data stream and sending it to the backend server. The backend server analyzes the location data stream to detect whether there are any abnormal patterns in the movement trajectory of the mobile terminal within the time period; wherein, the abnormal pattern includes at least one of the following: the movement speed or acceleration violates the laws of physics, or the movement trajectory does not match the geographical environmental features indicated by the first location information or the second location information.

4. The dynamic attendance method based on NFC security tags according to claim 1 or 2, characterized in that, After the backend server sends the attendance check-in results, the method further includes a delayed authentication step: After receiving the attendance check-in result, the mobile terminal waits for a preset delay period and then silently collects third location information in the background and sends it to the background server. The backend server verifies the logical consistency between the third location information and the geographical location information associated with this attendance request.

5. The dynamic attendance method based on NFC security tags according to claim 2, characterized in that, The method further includes a collaborative verification step, which is as follows: After the mobile terminal sends the challenge application, the backend server or the mobile terminal designates at least one collaborative verification terminal and sends a verification request to the designated collaborative verification terminal. In response to the verification request, the collaborative verification terminal generates a verification token containing a trusted timestamp and sends it to the backend server. The backend server receives the verification token, generates time constraint information based on the trusted timestamp in the verification token, and sends the time constraint information to the mobile terminal. The interaction process between the mobile terminal and the NFC security tag, and / or the generation of the attendance request, must meet the time constraint information. The verification operation also includes verifying the validity of the verification token.

6. The dynamic attendance method based on NFC security tags according to claim 5, characterized in that, The method also includes a delayed authentication step: After receiving the attendance check-in result, the mobile terminal waits for a preset delay period and then silently collects third location information in the background and sends it to the background server. The backend server verifies the logical consistency between the third location information and the geographic location information associated with this attendance request; wherein, the delay duration is calculated based on the feasible timestamp.

7. The dynamic attendance method based on NFC security tags according to claim 1, characterized in that, The method further includes: The backend server maintains a user behavior risk profile; when receiving an attendance request or performing a verification operation, it dynamically decides whether and how to enable one or more enhanced security verifications based on the user behavior risk profile, the feature information of the current attendance request, and the user's historical records. The feature information includes at least: check-in time anomaly, check-in geographical location unfamiliarity, and the generation frequency of dynamic authentication data; The enhanced security verification includes at least: trajectory analysis of the mobile terminal's movement trajectory during the attendance process; delayed collection of location information after successful attendance for post-event consistency verification; and the introduction of a collaborative verification terminal to impose time constraints on the attendance process.

8. A dynamic attendance system based on NFC security tags, characterized in that, This includes NFC security tags, mobile terminals, and backend servers; The user's mobile terminal interacts with a preset NFC security tag via near-field communication to obtain dynamic authentication data generated by the NFC security tag; The mobile terminal generates an attendance request based on the dynamic authentication data and sends the attendance request to the backend server. The backend server receives the attendance request and performs a verification operation, which includes: performing cryptographic verification on the dynamic authentication data based on the security key pre-shared with the NFC security tag to verify the authenticity of the NFC security tag; It also verifies whether the dynamic authentication data meets the preset uniqueness condition to prevent replay attacks; After successful verification, the backend server performs the attendance recording operation and sends the attendance check-in result to the mobile terminal, so that the mobile terminal can provide feedback on the attendance check-in result to the user.

9. A dynamic attendance device based on an NFC security tag, characterized in that, It includes a memory and a processor, wherein the memory stores a computer program that can be loaded by the processor and executed as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, The computer program is stored that can be loaded by a processor and executed as described in any one of claims 1 to 7.

Images