Nfc tag data processing method based on multi-factor version routing decision and related device thereof

Abstract

This application provides an NFC tag data processing method and related equipment based on multi-factor version routing decision, belonging to the field of data processing and applied to servers. The method includes: acquiring a service access request initiated by a mobile terminal by touching an NFC tag; wherein the service access request contains a target resource locator; performing structured parsing on the target resource locator to obtain routing decision parameters; wherein the routing decision parameters include a version identifier, an algorithm identifier, and a service data segment; determining the current service processing mode based on the version identifier; calling the corresponding target encryption / decryption algorithm component from a heterogeneous chip algorithm library based on the algorithm identifier; and using the target encryption / decryption algorithm component to process the service data segment according to the service processing mode to generate a service response result. This application can realize dynamic adjustment of NFC service logic and unified adaptation of multiple chips based on structured parameters, thereby reducing operation and maintenance costs and improving service scalability.

Description

Technical Field

[0001] This invention relates to the field of data processing, and in particular to an NFC tag data processing method and related equipment based on multi-factor version routing decision. Background Technology

[0002] Currently, NFC technology has become a widely used short-range communication method in the Internet of Things and mobile Internet fields. Users can quickly establish a connection by touching a pre-installed NFC tag with an NFC-enabled mobile terminal to obtain information, complete payments, or verify identity.

[0003] In related technologies, existing NFC tag applications typically use static data fixation, meaning that fixed business redirection addresses and security parameters are written into the tag when it is issued. This makes business changes extremely difficult. When it is necessary to adjust business logic or adapt to different encryption chips, it is often necessary to recycle and reissue physical tags. This not only increases the cost of operation and maintenance but also limits the rapid expansion of the business. Summary of the Invention

[0004] The main objective of this application is to propose an NFC tag data processing method and related equipment based on multi-factor version routing decision, which can realize dynamic adjustment of NFC business logic and unified adaptation of multiple chips based on URL structured parameters, thereby reducing operation and maintenance costs and improving business expansion capabilities.

[0005] To achieve the above objectives, a first aspect of this application proposes an NFC tag data processing method based on multi-factor version routing decision, applied to subway turnstiles, the method comprising:

[0006] Applied to a server, the method includes:

[0007] Obtain a service access request initiated by a mobile terminal by touching an NFC tag; wherein the service access request includes a target resource locator;

[0008] The target resource locator is structured and parsed to obtain routing decision parameters; wherein, the routing decision parameters include version identifier, algorithm identifier, and business data segment;

[0009] The current business processing mode is determined based on the version identifier;

[0010] Based on the algorithm identifier, the corresponding target encryption / decryption algorithm component is called from the preset heterogeneous chip algorithm library;

[0011] Using the target encryption / decryption algorithm component, the business data segment is processed according to the business processing mode to generate a business response result and return it to the mobile terminal.

[0012] In some embodiments, determining the current business processing mode based on the version identifier includes:

[0013] When the version identifier indicates the first version, the business processing mode is determined to be the lightweight jump mode, and the business data segment is parsed in plaintext.

[0014] When the version identifier indicates the second version, the business processing mode is determined to be a secure encryption mode, and the business data segment is subjected to integrity verification and decryption.

[0015] In some embodiments, the heterogeneous chip algorithm library stores multiple encryption algorithms adapted to different chips; the step of calling the corresponding target encryption / decryption algorithm component from the preset heterogeneous chip algorithm library based on the algorithm identifier includes:

[0016] In the preset algorithm mapping table, find the encryption algorithm type that has a mapping relationship with the algorithm identifier;

[0017] Based on the encryption algorithm type, the corresponding encryption / decryption algorithm component is called from the heterogeneous chip algorithm library as the target encryption / decryption algorithm component.

[0018] In some embodiments, the routing decision parameters further include a key index, and the step of processing the service data segment according to the service processing mode using the target encryption / decryption algorithm component includes:

[0019] Based on the key index, a matching dynamic session key is retrieved from a preset key management library;

[0020] Extract the message authentication code and encrypted data from the business data segment;

[0021] Using the target encryption / decryption algorithm component and the dynamic session key, the ciphertext data is signed to obtain signature data;

[0022] The signature data is compared with the message authentication code. If they match, the ciphertext data is decrypted to obtain the plaintext service parameters.

[0023] In some embodiments, the method further includes:

[0024] The plaintext service parameters are parsed using key-value pairs to extract the service type identifier;

[0025] Based on the service type identifier, query the corresponding target redirection address in the preset service redirection rule table;

[0026] The process of generating a service response result and returning it to the mobile terminal specifically includes:

[0027] Generate a redirection instruction containing the target redirection address, and send the redirection instruction to the mobile terminal to control the mobile terminal to jump to the specified business page.

[0028] In some embodiments, the path portion of the target resource locator sequentially encodes the version identifier, the algorithm identifier, and the key index in a hierarchical structure, and the query string portion of the target resource locator contains the business data segment; the structured parsing of the target resource locator includes:

[0029] The path portion is segmented according to the delimiter, and the version identifier and the algorithm identifier are extracted sequentially.

[0030] Identify the parameter key names in the query string and extract the corresponding parameter key values ​​as the business data segment.

[0031] In some embodiments, the method further includes:

[0032] Upon receiving the service access request, if the parsed version identifier is a reserved extended version, then a firmware upgrade detection is triggered or a preset compatibility downgrade process is executed.

[0033] To achieve the above objectives, a second aspect of this application provides an NFC tag data processing device based on multi-factor version routing decision, applied to a server, the device comprising:

[0034] The acquisition module is used to acquire a service access request initiated by the mobile terminal by touching the NFC tag; wherein the service access request includes a target resource locator.

[0035] The parsing module is used to perform structured parsing on the target resource locator to obtain routing decision parameters; wherein, the routing decision parameters include version identifier, algorithm identifier, and business data segment;

[0036] The determination module is used to determine the current business processing mode based on the version identifier;

[0037] The calling module is used to call the corresponding target encryption / decryption algorithm component from a preset heterogeneous chip algorithm library based on the algorithm identifier;

[0038] The processing module is used to process the business data segment according to the business processing mode using the target encryption / decryption algorithm component, generate a business response result, and return it to the mobile terminal.

[0039] To achieve the above objectives, a third aspect of this application provides an electronic device, which includes a memory and a processor. The memory stores a computer program, and the processor executes the computer program to implement the method described in the first aspect of the embodiment.

[0040] To achieve the above objectives, a fourth aspect of the present application provides a storage medium, which is a computer-readable storage medium storing a computer program that, when executed by a processor, implements the method described in the first aspect of the present application.

[0041] The NFC tag data processing method and related equipment based on multi-factor version routing decision proposed in this application have the following beneficial effects: First, by acquiring and structurally parsing the target resource locator, this method obtains routing decision parameters including version identifier, algorithm identifier, and business data segment. This allows the server to directly obtain key factors controlling business flow without pre-querying the database, providing standardized data support for subsequent hierarchical decision-making. Second, the version identifier is used to determine the current business processing mode. This step can switch between different business logics in real time according to the parameters passed from the front end, breaking the limitations of traditional fixed tag business. At the same time, the target encryption and decryption algorithm component is dynamically called from the preset heterogeneous chip algorithm library based on the algorithm identifier. This step achieves decoupling between the underlying hardware algorithm and the upper-layer business logic. It can automatically adapt to the chip algorithms of different manufacturers only based on the identifier, without the need to reconstruct the system for new chips. Finally, the selected component is used to process the business data segment according to the mode and generate response results, ensuring that the business processing flow can respond to the hardware and business change requirements of the front end in real time. In summary, by placing the control logic in the URL parameters and driving the server-side routing execution, this invention enables dynamic adjustment of NFC business logic and unified adaptation of multiple chips based on URL structured parameters, thereby reducing operation and maintenance costs and improving business expansion capabilities. Attached Figure Description

[0042] Figure 1 This is a flowchart of the NFC tag data processing method based on multi-factor version routing decision provided in the embodiments of this application;

[0043] Figure 2 This is another flowchart of the NFC tag data processing method based on multi-factor version routing decision provided in the embodiments of this application;

[0044] Figure 3 This is another flowchart of the NFC tag data processing method based on multi-factor version routing decision provided in the embodiments of this application;

[0045] Figure 4This is a flowchart of dynamic service processing based on multi-factor version routing decision provided in the embodiments of this application;

[0046] Figure 5 This is another flowchart of the NFC tag data processing method based on multi-factor version routing decision provided in the embodiments of this application;

[0047] Figure 6 This is another flowchart of the NFC tag data processing method based on multi-factor version routing decision provided in the embodiments of this application;

[0048] Figure 7 This is another flowchart of the NFC tag data processing method based on multi-factor version routing decision provided in the embodiments of this application;

[0049] Figure 8 This is a schematic diagram of an NFC tag data processing device based on multi-factor version routing decision provided in an embodiment of this application;

[0050] Figure 9 This is a schematic diagram of the hardware structure of the electronic device provided in the embodiments of this application. Detailed Implementation

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

[0052] It should be noted that although functional modules are divided in the device schematic diagram and the logical order is shown in the flowchart, in some cases, the steps shown or described may be performed in a different order than the module division in the device or the order in the flowchart.

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

[0054] Currently, NFC technology has become a widely used short-range communication method in the Internet of Things and mobile Internet fields. Users can quickly establish a connection by touching a pre-installed NFC tag with an NFC-enabled mobile terminal to obtain information, complete payments, or verify identity.

[0055] In related technologies, existing NFC tag applications typically use static data fixation, meaning that fixed business redirection addresses and security parameters are written into the tag when it is issued. This makes business changes extremely difficult. When it is necessary to adjust business logic or adapt to different encryption chips, it is often necessary to recycle and reissue physical tags. This not only increases the cost of operation and maintenance but also limits the rapid expansion of the business.

[0056] Based on this, embodiments of this application provide an NFC tag data processing method and related equipment based on multi-factor version routing decision, which can realize dynamic adjustment of NFC business logic and unified adaptation of multiple chips based on URL structured parameters, thereby reducing operation and maintenance costs and improving business expansion capabilities.

[0057] The NFC tag data processing method and related equipment based on multi-factor version routing decision provided in this application are specifically described through the following embodiments. First, the NFC tag data processing method based on multi-factor version routing decision in this application embodiment is described.

[0058] The NFC tag data processing method based on multi-factor version routing decision in this application can be illustrated by the following embodiments.

[0059] It should be noted that in all specific embodiments of this application, when processing data related to user identity or characteristics, such as user information, user behavior data, user historical data, and user location information, user permission or consent is obtained first. For example, when obtaining user-stored data and user cached data access requests, user permission or consent is obtained first. Furthermore, the collection, use, and processing of this data comply with relevant laws, regulations, and standards of the relevant countries and regions. In addition, when embodiments of this application need to obtain sensitive personal information of users, separate permission or consent from the user is obtained through pop-ups or redirection to a confirmation page. Only after obtaining the user's separate permission or consent is the necessary user-related data for the normal operation of the embodiments of this application obtained.

[0060] Figure 1 This is an optional flowchart of the NFC tag data processing method based on multi-factor version routing decision provided in the embodiments of this application. Figure 1 The method may include, but is not limited to, steps 101 to 105. It is also understood that this embodiment... Figure 1 The order of steps 101 to 105 is not specifically limited. The order of steps can be adjusted or some steps can be reduced or added according to actual needs.

[0061] Step 101: Obtain the service access request initiated by the mobile terminal by touching the NFC tag.

[0062] Step 102: Perform structured parsing on the target resource locator to obtain routing decision parameters.

[0063] Step 103: Determine the current business processing mode based on the version identifier.

[0064] Step 104: Based on the algorithm identifier, call the corresponding target encryption / decryption algorithm component from the preset heterogeneous chip algorithm library.

[0065] Step 105: Using the target encryption / decryption algorithm component, process the business data segment according to the business processing mode, generate a business response result, and return it to the mobile terminal.

[0066] In step 101 of some embodiments, the mobile terminal (e.g., a smartphone, handheld PDA, or smart wearable device with an integrated NFC controller) performs physical near-field sensing with an NFC tag (i.e., a passive data carrier containing an RF antenna and a storage chip, such as an NTAG series chip) pre-installed on the subway gate, reads the NDEF (NFC Data Exchange Format) message stored in the tag, and extracts the target resource locator, i.e., the URL, from it. The target resource locator is not only a link pointing to the server's network address, but also a structured data pre-encoded according to specific rules. After obtaining the URL, the mobile terminal will automatically call the system browser or a specified application to initiate an HTTPS service access request carrying the URL to the server through a 4G / 5G or Wi-Fi network, thereby establishing a communication link between the physical tag and the server.

[0067] In step 102 of some embodiments, after receiving a business access request, the server can use regular expression matching or a URL parser to perform structured parsing on the path part and query string part of the target resource locator, thereby separating and extracting routing decision parameters. Among them, the version identifier (such as " / v02 / " in the path) is a control character used to define the server-side processing logic version, the algorithm identifier (such as " / 01 / " in the path) is an index character used to map the underlying chip encryption type, and the business data segment is the payload entity carrying the tag UID, PICC ciphertext or CMAC checksum. Through this step, the unstructured URL string is transformed into standardized input that drives subsequent logic processing.

[0068] Please see Figure 2 In some embodiments, the path portion of the target resource locator is encoded with version identifier, algorithm identifier and key index in a hierarchical structure, and the query string portion of the target resource locator contains business data segments. Step 102 may include, but is not limited to, steps 201 to 202.

[0069] Step 201: Divide the path into segments according to the delimiter and extract the version identifier and algorithm identifier in sequence.

[0070] Step 202: Identify the parameter key names in the query string and extract the corresponding parameter key values ​​as business data segments.

[0071] In step 201 of some embodiments, after receiving an HTTPS request, the server first locates the path portion of the target resource locator (URL). This portion is designed as the basic data area, used to carry the core routing factors of the control logic. The path string can be hierarchically segmented using the forward slash separator " / ", and key parameters at each position can be extracted sequentially: First, the first-level data format version number (e.g., "V01" or "V02") after the domain name is extracted. This identifier directly determines the parsing format and business processing framework of subsequent data (e.g., whether decryption is required); next, the second-level algorithm scheme number (e.g., "00" or "01") is extracted. This identifier clarifies the type of algorithm required for subsequent decryption (e.g., "00" corresponds to the AES-128 algorithm for NXP chips, and "01" corresponds to the SM4-CBC national cryptographic algorithm for Tsinghua Unigroup chips); then, the third-level key index number is extracted, used to quickly locate a specific decryption key in the security management system; finally, the fourth-level user identifier (e.g., a 19-digit card number) is extracted, used to lock the transaction entity. This path-level encoding method fully utilizes the data characteristics of NTAG tags, enabling the encapsulation and rapid reading of multi-dimensional control parameters without consuming additional query parameter bytes.

[0072] In step 202 of some embodiments, the query string portion of the target resource locator is parsed. This portion is designed as an extended data area to carry specific business payloads and security credentials. Specific parameter key names and their corresponding key values ​​are identified and extracted as business data segments. This mainly includes: identifying the parameter with key name "e" and extracting its value as PICC ciphertext (i.e., data encrypted with the tag UID and counter) for anti-counterfeiting verification; identifying the parameter with key name "c" and extracting its value as CMAC (Cipher-based Message Authentication Code) for verifying the integrity of the entire data segment from the version number to the end of the business data; and identifying the parameter with key name "d" and extracting its value as custom business data. Specifically, the internal structure of the business data "d" differs depending on the version number extracted in step 201: in version V01, it directly transmits the business number through plaintext key-value pairs for fast redirection; while in version V02, it is stored as an encrypted string that needs to be decrypted to be restored.

[0073] Through steps 201 to 202 above, this embodiment of the application constructs a standardized URL encoding and parsing system. By using path separators to place decision factors such as version, algorithm, and key in the basic data area, the server can quickly determine which algorithm to use for decryption and which business process to follow through string segmentation before processing complex PICC ciphertext or business data. At the same time, by utilizing the key-value pair characteristics of the query string, the business payload is placed in the extended data area, supporting flexible nesting and expansion of plaintext and ciphertext. This ensures data transmission security while improving compatibility and parsing efficiency for different chip solutions and business scenarios.

[0074] In step 103 of some embodiments, the parsed version identifier is matched against a preset business configuration strategy table to determine the business processing mode that should be executed. For example, when the version identifier points to "marketing promotion mode", it is determined that no time-consuming decryption operation needs to be performed, and only plaintext parameters need to be passed through or statistically analyzed. When the version identifier points to "secure payment mode", it is determined that a strict security process including anti-replay detection, integrity verification, and data decryption is initiated. This enables real-time switching between business forms with different security levels and computational complexity by simply changing the version number in the tag URL without modifying the server-side code.

[0075] Please see Figure 3 In some embodiments, step 103 may include, but is not limited to, steps 301 to 302.

[0076] Step 301: When the version identifier indicates the first version, determine that the business processing mode is the lightweight jump mode, and perform plaintext parsing on the business data segment.

[0077] Step 302: When the version identifier indicates version 2, determine that the business processing mode is the secure encryption mode, and perform integrity verification and decryption on the business data segment.

[0078] In step 301 of some embodiments, after parsing the version identifier in the routing decision parameters, the server compares it with the preset configuration rules. When the version identifier is identified as the first version (e.g., "V01"), it determines that the current business scenario is a low-sensitivity scenario that is not related to financial transactions (such as internet advertising, activity page redirection, or public information query), and then locks the business processing mode to the lightweight redirection mode. In this mode, the time-consuming cryptographic operation module is skipped, and the business data segment in the query string is directly regarded as an unencrypted plaintext key-value pair. The parameter values ​​are directly extracted using a standard URL decoder, and these plaintext parameters are used as a search index to look up the corresponding redirection address in the business mapping table, thereby completing the response to the front-end request with extremely low latency.

[0079] In step 302 of some embodiments, when the server identifies the version identifier as the second version, it determines that the current business involves high-value asset interaction or strong identity authentication requirements (such as transportation card deduction, access control permission verification), and immediately switches to the secure encryption mode. In this mode, the business data segment is locked as the encrypted payload to be verified. First, the message authentication code carried in the URL is extracted, and the integrity of the entire path data from the version identifier to the end of the business data segment is compared using a preset verification algorithm to intercept tampered malicious requests. After the verification is passed, the decryption engine is called to perform a decryption operation on the encrypted business data segment (usually a combination of PICC ciphertext and custom business ciphertext), restoring it to a readable plaintext structure containing card number, counter and transaction instructions, ensuring the confidentiality and authenticity of core business instructions during transmission.

[0080] In some embodiments, after the server completes the structured parsing of the target resource locator, if it identifies that the version identifier belongs to a preset reserved extended version range, it determines that the current NFC tag carries a new protocol or test function that exceeds the current standard business logic. At this time, the firmware upgrade detection process is first started, the terminal device information carried in the business access request header is parsed, and the device version is compared with the minimum firmware environment required by the reserved extended version. If it is found that the terminal device does not support the extended protocol, a specific status code or upgrade guidance instruction is returned to the terminal, triggering the terminal to start firmware OTA update or prompting the user to upgrade the software. If the system determines that a firmware upgrade is not necessary or cannot be performed immediately, it will automatically execute the preset compatibility downgrade processing logic, attempt to ignore non-critical data fields added in the reserved extended version, and force the remaining data structures to be mapped to the backward compatible lower version standard (such as V02 secure payment mode or V01 plaintext jump mode) for parsing; for example, when the tag version is V03 but the system is only fully compatible with V02, the system will only extract the core business fields (such as card number and balance) that overlap with the V02 definition in the V03 data packet, and verify and respond according to the V02 security policy, thereby ensuring the availability of basic business functions.

[0081] Please see Figure 4 , Figure 4This is a flowchart of a dynamic service processing method based on multi-factor version routing decision provided in this application embodiment. As shown in the figure, the process begins by reading the NFC tag URL. First, the data format version number and algorithm scheme number are extracted from the URL as decision factors. Then, a first-level routing branch is executed based on the data format version number: if it is identified as a reserved V0N version, it enters the reservation process; if it is identified as a V01 version, it enters the plaintext data format parsing process; if it is identified as a V02 version, it enters the security encryption process. In the V02 process, a second-level routing is further executed based on the algorithm scheme number, and a matching algorithm component (such as AES or SM4) is selected to decrypt the encrypted service data and PICC security data in sequence. Subsequently, CMAC security data verification is performed on the parsed or decrypted data, and a third-level service routing is executed based on the verification result and service parameters. Finally, the mobile terminal is controlled to jump to a specific service page (such as service page A, service page B) or to jump to an error page if the verification fails.

[0082] Through steps 301 to 302 above, this application embodiment establishes a security hierarchical response directly driven by version parameters, breaking the traditional NFC system's mode of having to execute a unified security policy for all requests. It can flexibly schedule computing resources between payment verification in low-sensitivity scenarios and high-security scenarios based on different business version identifiers, ensuring both high-concurrency response speed for low-value businesses and financial-grade security for high-value businesses, thus achieving a balance between performance and security costs.

[0083] In step 104 of some embodiments, the corresponding target encryption and decryption algorithm component is dynamically loaded and instantiated from a preset heterogeneous chip algorithm library according to the parsed algorithm identifier. The heterogeneous chip algorithm library is an abstract service layer that encapsulates the dedicated algorithm interfaces of different chip manufacturers. The algorithm identifier serves as the unique index key of the library and is directly mapped to the specific algorithm implementation class or dynamic link library (for example, the identifier "00" automatically maps to and calls the internationally common AES algorithm component, and the identifier "01" automatically maps to and calls the national cryptographic SM4 algorithm component). This mechanism enables the server to plug and play the correct decryption logic according to the chip type of the front-end physical tag, thereby decoupling the upper-layer business logic from the lower-layer hardware algorithm.

[0084] Please see Figure 5 In some embodiments, the heterogeneous chip algorithm library stores a variety of encryption algorithms adapted to different chips. Step 104 may include, but is not limited to, steps 501 to 502.

[0085] Step 501: In the preset algorithm mapping table, find the encryption algorithm type that has a mapping relationship with the algorithm identifier.

[0086] Step 502: Based on the encryption algorithm type, call the corresponding encryption / decryption algorithm component from the heterogeneous chip algorithm library as the target encryption / decryption algorithm component.

[0087] In step 501 of some embodiments, after obtaining the algorithm identifier parsed from the target resource locator, a preset algorithm mapping table is accessed. This mapping table stores the correspondence logic between the algorithm identifier and the specific encryption algorithm type in the form of key-value pairs (for example, configuring the algorithm identifier "00" to map to the internationally used AES-128 standard algorithm, and the algorithm identifier "01" to map to the domestic commercial cryptographic SM4-CBC algorithm). By searching and matching in the mapping table with the algorithm identifier as the index key, the specific encryption algorithm type used by the current NFC tag chip can be locked, thereby converting the short characters used for routing distribution in the URL protocol into the algorithm standard definition that can be recognized and executed by subsequent programs.

[0088] In step 502 of some embodiments, based on the encryption algorithm type determined in step 501, the corresponding encryption and decryption algorithm component is called from a preset heterogeneous chip algorithm library. The heterogeneous chip algorithm library pre-integrates and encapsulates a variety of algorithm implementation modules adapted to the hardware characteristics of different chip manufacturers. Based on the determined algorithm type, the matching algorithm component is directly loaded or instantiated as the target encryption and decryption algorithm component, so that the component immediately has the specific encryption and decryption capabilities required to process the current request, thereby providing computational support for the subsequent decryption, restoration and integrity verification of the business data segment.

[0089] In step 105 of some embodiments, the target encryption / decryption algorithm component instantiated in step 104 is used to perform specific cryptographic operations on the business data segment according to the business processing mode determined in step 103 (such as decrypting PICC ciphertext to restore the card number, or verifying CMAC signature to confirm data integrity). The corresponding redirect address is then queried in the business rule table based on the processed plaintext data, and finally a business response result containing redirection instructions is generated and returned to the mobile terminal. After receiving the response, the mobile terminal automatically redirects to the final business landing page (such as a payment success page or an activity details page), thereby completing the end-to-end business from "touch the tag" to "obtain the service".

[0090] Please see Figure 6 In some embodiments, the routing decision parameters also include a key index, and step 105 may include, but is not limited to, steps 601 to 604.

[0091] Step 601: Retrieve a matching dynamic session key from a preset key management library based on the key index.

[0092] Step 602: Extract the message authentication code and encrypted data from the business data segment.

[0093] Step 603: Using the target encryption / decryption algorithm component and the dynamic session key, perform signature calculation on the ciphertext data to obtain the signature data.

[0094] Step 604: Compare the signature data with the message authentication code. If they match, decrypt the ciphertext data to obtain the plaintext business parameters.

[0095] In step 601 of some embodiments, the key index parsed from the target resource locator path is read. This index is a digital identifier that does not contain sensitive information but points to a specific encrypted credential. The index is used as a query key to initiate a retrieval request to a preset key management library, thereby obtaining a dynamic session key that matches the current NFC tag batch. The dynamic session key is the credential for all subsequent cryptographic operations. Through the indexing mechanism, the logical isolation and on-demand loading of keys are realized, and the key rotation and upgrade can be implemented through background configuration without updating the code.

[0096] In step 602 of some embodiments, the service data segment is separated and parsed to extract the message authentication code used for integrity verification and the ciphertext data carrying core business information. The message authentication code is a digital fingerprint generated by the NFC tag using its internal key on the original data, while the ciphertext data is the encrypted tag UID, counter, or business instruction. The two are separate and independent parameters at the transmission level, but they are closely related in terms of security logic.

[0097] In step 603 of some embodiments, the target encryption / decryption algorithm component instantiated in step 104 is invoked, the dynamic session key obtained in step 601 is loaded, and the ciphertext data is hashed and encrypted according to the preset signature algorithm rules, thereby generating a new signature data locally on the server. This process is the reverse calculation of the signature behavior of the NFC tag, which aims to verify whether the data has been tampered with by a man-in-the-middle or replay attack during transmission.

[0098] In step 604 of some embodiments, the signature data calculated locally by the server is compared with the original message authentication code extracted in step 602 at the binary level. If the two are completely consistent, the data is determined to be complete and trustworthy. Then, the target encryption and decryption algorithm component and the dynamic session key are used to perform decryption operation on the ciphertext data to restore it to plaintext business parameters containing card number, transaction counter and specific business instructions. If the comparison is inconsistent, the processing flow is terminated immediately and a security exception is reported.

[0099] Through steps 601 to 604 above, this application embodiment constructs a communication security closed loop based on index addressing and dual verification; it achieves discretization and security of key management through key indexing, avoiding the risk of leakage caused by hard-coded keys; through the rigorous logic of verification before decryption, it effectively resists data tampering and malicious injection attacks, ensuring that in an open NFC communication environment, the server can accurately restore real and reliable plaintext business parameters, providing a solid data foundation for subsequent accurate business routing.

[0100] Please see Figure 7 In some embodiments, the method provided in this application may further include, but is not limited to, steps 701 to 702.

[0101] Step 701: Parse the plaintext business parameters using key-value pairs and extract the business type identifier.

[0102] Step 702: Based on the service type identifier, query the corresponding target redirection address in the preset service redirection rule table.

[0103] Accordingly, the steps of generating the business response result and returning it to the mobile terminal may further include:

[0104] Generate a redirection instruction containing the target redirection address and send the redirection instruction to the mobile terminal to control the mobile terminal to jump to the specified business page.

[0105] In step 701 of some embodiments, key-value pair parsing is performed on the decrypted and restored plaintext business parameters to extract the business type identifier used to define the business scenario attributes. The business type identifier is a short code that is pre-agreed to distinguish different business logics (e.g., 01 represents subway entry and gate passage, 02 represents anti-counterfeiting traceability query). Through string segmentation and regular expression matching technology, the core control factor is separated from the business parameter set to determine which business logic is triggered by the current NFC touch action.

[0106] In step 702 of some embodiments, the extracted service type identifier is used as the index key to perform a search in a preset service redirection rule table to obtain the corresponding target redirection address. The service redirection rule table is a dynamic mapping relationship configuration stored in the server memory or database. Through the table lookup operation, the digital identifier is mapped to a specific Internet resource address (URL). This address is the service landing page that the mobile terminal browser ultimately needs to access. This mechanism allows the operator to change the service landing page at any time without modifying the NFC tag data, simply by modifying the backend configuration table. For example, switching the holiday event page to the daily homepage.

[0107] In some embodiments, in the steps of generating a business response result and returning it to the mobile terminal, the server constructs a redirection instruction containing an HTTP 302 (Found) or HTTP 301 (Moved Permanently) status code based on the queried target redirection address, and fills the target address into the HTTP field and sends it back to the mobile terminal. After receiving the instruction, the mobile terminal's system browser can automatically parse and execute the page jump operation without user intervention, directly load and render the specified business page (such as displaying the passage status "gate is open"), thereby completing the implementation from backend logic to frontend interaction.

[0108] Through steps 101 to 105 above, this embodiment of the application explicitly defines structured routing parameters in the URL and uses these parameters as direct instructions to drive server-side logic branches. This not only allows for flexible definition of the security level and processing flow of the business based on version identifiers, breaking the limitations of traditional fixed tag services, but also achieves unified adaptation and dynamic invocation of algorithms for heterogeneous chips from multiple vendors through algorithm identifiers. This means that when accessing new chips or adjusting services, there is no need to refactor the core code. It enables dynamic adjustment of NFC business logic and unified adaptation of multiple chips based on URL structured parameters, thereby reducing operation and maintenance costs and improving business expansion capabilities.

[0109] Please see Figure 8 This application also provides an NFC tag data processing device based on multi-factor version routing decision, which can implement the above-mentioned NFC tag data processing method based on multi-factor version routing decision. The device includes:

[0110] The acquisition module is used to acquire service access requests initiated by the mobile terminal by touching the NFC tag; wherein, the service access request contains a target resource locator;

[0111] The parsing module is used to perform structured parsing of the target resource locator to obtain routing decision parameters; among which, the routing decision parameters include version identifier, algorithm identifier, and business data segment;

[0112] The determination module is used to determine the current business processing mode based on the version identifier;

[0113] The calling module is used to call the corresponding target encryption / decryption algorithm component from the preset heterogeneous chip algorithm library based on the algorithm identifier;

[0114] The processing module is used to process the business data segment according to the business processing mode using the target encryption and decryption algorithm component, generate the business response result and return it to the mobile terminal.

[0115] This application also provides an electronic device, which includes a memory and a processor. The memory stores a computer program, and the processor executes the computer program to implement the above-described NFC tag data processing method based on multi-factor version routing decision. This electronic device can be any smart terminal, including tablet computers, in-vehicle computers, etc.

[0116] Please refer to the figure. Figure 9 The hardware structure of an electronic device according to another embodiment is illustrated. The electronic device includes:

[0117] The processor 901 can be implemented using a general-purpose CPU (Central Processing Unit), microprocessor, application-specific integrated circuit (ASIC), or one or more integrated circuits, and is used to execute relevant programs to implement the technical solutions provided in the embodiments of this application.

[0118] The memory 902 can be implemented as a read-only memory (ROM), static storage device, dynamic storage device, or random access memory (RAM). The memory 902 can store the operating system and other applications. When the technical solutions provided in the embodiments of this specification are implemented through software or firmware, the relevant program code is stored in the memory 902 and is called and executed by the processor 901 to execute the NFC tag data processing method based on multi-factor version routing decision of the embodiments of this application.

[0119] The input / output interface 903 is used to implement information input and output;

[0120] The communication interface 904 is used to enable communication and interaction between this device and other devices. Communication can be achieved through wired means (such as USB, Ethernet cable, etc.) or wireless means (such as mobile network, WIFI, Bluetooth, etc.).

[0121] Bus 905 transmits information between various components of the device (e.g., processor 901, memory 902, input / output interface 903, and communication interface 904);

[0122] The processor 901, memory 902, input / output interface 903, and communication interface 904 are connected to each other within the device via bus 905.

[0123] This application also provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the above-described NFC tag data processing method based on multi-factor version routing decision.

[0124] Memory, as a non-transitory computer-readable storage medium, can be used to store non-transitory software programs and non-transitory computer-executable programs. Furthermore, memory may include high-speed random access memory, and may also include non-transitory memory, such as at least one disk storage device, flash memory device, or other non-transitory solid-state storage device. In some embodiments, memory may optionally include memory remotely located relative to the processor, and these remote memories can be connected to the processor via a network. Examples of such networks include, but are not limited to, the Internet, intranets, local area networks, mobile communication networks, and combinations thereof.

[0125] The embodiments described in this application are for the purpose of more clearly illustrating the technical solutions of the embodiments of this application, and do not constitute a limitation on the technical solutions provided by the embodiments of this application. As those skilled in the art will know, with the evolution of technology and the emergence of new application scenarios, the technical solutions provided by the embodiments of this application are also applicable to similar technical problems.

[0126] Those skilled in the art will understand that the technical solutions shown in the figures do not constitute a limitation on the embodiments of this application, and may include more or fewer steps than shown, or combine certain steps, or different steps.

[0127] The device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs.

[0128] Those skilled in the art will understand that all or some of the steps in the methods disclosed above, as well as the functional modules / units in the systems and devices, can be implemented as software, firmware, hardware, or suitable combinations thereof.

[0129] The terms “first,” “second,” “third,” “fourth,” etc. (if present) in the specification and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms “comprising” and “having,” and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0130] It should be understood that in this application, "at least one" and "several" refer to one or more, and "multiple" refers to two or more. "And / or" describes the relationship between related objects, indicating that three relationships can exist. For example, "A and / or B" can represent three cases: only A exists, only B exists, and both A and B exist simultaneously, where A and B can be singular or plural. The character " / " generally indicates that the preceding and following related objects are in an "or" relationship. "At least one of the following" or similar expressions refer to any combination of these items, including any combination of single or plural items. For example, at least one of a, b, or c can represent: a, b, c, "a and b", "a and c", "b and c", or "a and b and c", where a, b, and c can be single or multiple.

[0131] In the embodiments provided in this application, it should be understood that the disclosed systems and methods can be implemented in other ways. For example, the system embodiments described above are merely illustrative; for instance, the division of the units described above is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. The couplings or direct couplings or communication connections shown or discussed may be indirect couplings or communication connections through some interfaces, devices, or units, and may be electrical, mechanical, or other forms.

[0132] The units described above as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0133] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0134] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or 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 multiple instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this application. The aforementioned storage medium includes various media capable of storing programs, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0135] The preferred embodiments of the present application have been described above with reference to the accompanying drawings, but this does not limit the scope of the claims of the present application. Any modifications, equivalent substitutions, and improvements made by those skilled in the art without departing from the scope and substance of the embodiments of the present application shall be within the scope of the claims of the present application.

Claims

1. An NFC tag data processing method based on multi-factor version routing decision, characterized in that, Applied to a server, the method includes: Obtain a service access request initiated by a mobile terminal by touching an NFC tag; wherein the service access request includes a target resource locator; The target resource locator is structured and parsed to obtain routing decision parameters; wherein, the routing decision parameters include version identifier, algorithm identifier, and business data segment; The current business processing mode is determined based on the version identifier, including: when the version identifier indicates a first version, the business processing mode is determined to be a lightweight jump mode, and the business data segment is parsed in plaintext; when the version identifier indicates a second version, the business processing mode is determined to be a secure encryption mode, and the business data segment is checked for integrity and decrypted; if the version identifier is found to belong to a preset reserved extended version range, it is determined that the current NFC tag carries a new protocol or test function that exceeds the current standard business logic; at this time, the firmware upgrade detection process is first started; if it is determined that the firmware upgrade is not needed or cannot be performed, the preset compatibility downgrade processing logic is automatically executed, attempting to ignore the non-critical data fields added in the reserved extended version, and forcibly mapping the remaining data structure to the backward compatible lower version standard for parsing; Based on the algorithm identifier, the corresponding target encryption / decryption algorithm component is called from a preset heterogeneous chip algorithm library; wherein, the heterogeneous chip algorithm library stores a variety of encryption algorithms adapted to different chips; specifically, it includes: searching for an encryption algorithm type that has a mapping relationship with the algorithm identifier in a preset algorithm mapping table; based on the encryption algorithm type, calling the corresponding encryption / decryption algorithm component from the heterogeneous chip algorithm library as the target encryption / decryption algorithm component; Using the target encryption / decryption algorithm component, the business data segment is processed according to the business processing mode to generate a business response result and return it to the mobile terminal.

2. The NFC tag data processing method based on multi-factor version routing decision according to claim 1, characterized in that, The routing decision parameters also include a key index. The step of processing the service data segment using the target encryption / decryption algorithm component according to the service processing mode includes: Based on the key index, a matching dynamic session key is retrieved from a preset key management library; Extract the message authentication code and encrypted data from the business data segment; Using the target encryption / decryption algorithm component and the dynamic session key, the ciphertext data is signed to obtain signature data; The signature data is compared with the message authentication code. If they match, the ciphertext data is decrypted to obtain the plaintext service parameters.

3. The NFC tag data processing method based on multi-factor version routing decision according to claim 2, characterized in that, The method further includes: The plaintext service parameters are parsed using key-value pairs to extract the service type identifier; Based on the service type identifier, query the corresponding target redirection address in the preset service redirection rule table; The process of generating a service response result and returning it to the mobile terminal specifically includes: Generate a redirection instruction containing the target redirection address, and send the redirection instruction to the mobile terminal to control the mobile terminal to jump to the specified business page.

4. The NFC tag data processing method based on multi-factor version routing decision according to claim 1, characterized in that, The path portion of the target resource locator is hierarchically encoded with the version identifier, the algorithm identifier, and the key index; the query string portion of the target resource locator contains the business data segment; the structured parsing of the target resource locator includes: The path portion is segmented according to the delimiter, and the version identifier and the algorithm identifier are extracted sequentially; Identify the parameter key names in the query string and extract the corresponding parameter key values ​​as the business data segment.

5. An NFC tag data processing device based on multi-factor version routing decision, characterized in that, Applied to a server, the device includes: The acquisition module is used to acquire a service access request initiated by the mobile terminal by touching the NFC tag; wherein the service access request includes a target resource locator. The parsing module is used to perform structured parsing on the target resource locator to obtain routing decision parameters; wherein, the routing decision parameters include version identifier, algorithm identifier, and business data segment; The determination module is used to determine the current business processing mode based on the version identifier, including: when the version identifier indicates a first version, determining that the business processing mode is a lightweight jump mode and parsing the business data segment in plaintext; when the version identifier indicates a second version, determining that the business processing mode is a secure encryption mode and performing integrity verification and decryption on the business data segment; if the version identifier is identified as belonging to a preset reserved extended version range, determining that the current NFC tag carries a new protocol or test function that exceeds the current standard business logic; at this time, the firmware upgrade detection process is first started; if it is determined that the firmware upgrade is not needed or cannot be performed, the preset compatibility downgrade processing logic is automatically executed, attempting to ignore the non-critical data fields added in the reserved extended version, and forcibly mapping the remaining data structure to the backward compatible lower version standard for parsing; The calling module is used to call the corresponding target encryption / decryption algorithm component from a preset heterogeneous chip algorithm library based on the algorithm identifier; wherein, the heterogeneous chip algorithm library stores a variety of encryption algorithms adapted to different chips; specifically, it includes: searching for an encryption algorithm type that has a mapping relationship with the algorithm identifier in a preset algorithm mapping table; and calling the corresponding encryption / decryption algorithm component from the heterogeneous chip algorithm library as the target encryption / decryption algorithm component based on the encryption algorithm type. The processing module is used to process the business data segment according to the business processing mode using the target encryption / decryption algorithm component, generate a business response result, and return it to the mobile terminal.

6. An electronic device, characterized in that, The electronic device includes a memory and a processor. The memory stores a computer program, and when the processor executes the computer program, it implements the NFC tag data processing method based on multi-factor version routing decision as described in any one of claims 1 to 4.

7. A computer-readable storage medium storing a computer program, characterized in that, When the computer program is executed by the processor, it implements the NFC tag data processing method based on multi-factor version routing decision as described in any one of claims 1 to 4.

Images