Host card-based interaction method, device and storage medium

Abstract

This application discloses an interaction method, device, and storage medium based on a host card, relating to the field of data processing technology. The method includes: responding to an execution instruction sent by an external reader / writer device, obtaining an application identifier from the execution instruction; sending the execution instruction to a target card application corresponding to the application identifier, the target card application generating a business key acquisition request based on the execution instruction; a key storage module decrypting a pre-stored encrypted business key based on the business key acquisition request to obtain a business key; encrypting transaction data based on the business key in a white-box component to obtain secure transaction result data; encapsulating the secure transaction result data into a response instruction, and sending the response instruction to the external reader / writer device. This method can improve the security and efficiency of NFC transaction processing.

Description

Technical Field

[0001] This application relates to the field of data processing technology, and in particular to an interaction method, device and storage medium based on a host card. Background Technology

[0002] In related technologies, virtual transportation cards mostly rely on a physical eSE (embedded secure element) security chip equipped with a COS system and a dedicated applet to realize card swiping transactions. After an external reading / writing device issues an execution command, the terminal routes the command to the target card application within the eSE. The eSE internally completes the reading and decryption of the encrypted business key, encrypts the transaction data, and sends back the response command. However, this implementation method is highly dependent on a dedicated eSE hardware chip, resulting in poor versatility and portability. Once removed from the eSE hardware environment, the original applet (card application) is difficult to reuse directly, requiring redevelopment, adaptation, and extensive repeated testing. At the same time, the key is protected only by the chip hardware isolation. Once removed from the dedicated hardware environment, it is susceptible to security risks such as key leakage, reverse engineering, and illegal theft.

[0003] The above content is only used to help understand the technical solution of this application and does not represent an admission that the above content is prior art. Summary of the Invention

[0004] The main purpose of this application is to provide an interaction method based on a host card, which aims to solve the technical problem of how to improve the security and efficiency of NFC transaction processing.

[0005] To address the aforementioned issues, this application provides a host card-based interaction method applied to a mobile terminal. The mobile terminal includes an NFC module, a VSE container, and a key storage module. The VSE container includes at least one card application component and a white-box component. The host card-based interaction method includes: In response to an execution command sent by an external read / write device, the application identifier in the execution command is obtained; The execution instruction is sent to the target card application corresponding to the application identifier, and the target card application generates a service key acquisition request based on the execution instruction; The key storage module decrypts the pre-stored encrypted business key based on the business key acquisition request to obtain the business key, which is in white-box key form. In the white-box component, the transaction data is encrypted based on the business key to obtain secure transaction result data; The secure transaction result data is encapsulated into a response instruction, and the response instruction is sent to the external read / write device.

[0006] In one embodiment, before the step of sending the execution instruction to the target card application corresponding to the application identifier, and the target card application generating a service key acquisition request based on the execution instruction, the host card-based interaction method further includes: The execution instructions are parsed to obtain the instruction code and the application identifier; When the instruction code is an application selection instruction, the application identifier is matched with a preset card application mapping table; The card application that has a mapping relationship with the application identifier is identified as the target card application.

[0007] In one embodiment, the business key is a traffic business key, and the step of the key storage module decrypting the pre-stored encrypted business key based on the business key acquisition request to obtain the business key includes: When the key storage module receives the service key acquisition request sent by the target card application, it acquires the key identifier and service scenario tag in the service key acquisition request; The key identifier and business scenario tag are used as indexes to match with a preset key library to obtain the encrypted traffic business key; The encrypted traffic service key is decrypted using a symmetric encryption algorithm to obtain the traffic service key, which includes an authentication subkey and a toll deduction subkey.

[0008] In one embodiment, the step of encrypting transaction data based on the business key in the white-box component to obtain secure transaction result data includes: When the white-box component receives the deduction operation subkey, it encrypts the transaction data based on the symmetric encryption algorithm, and sends the encrypted transaction ciphertext and verification code to the transportation card application. The transportation card application assembles the encrypted transaction ciphertext, the verification code, and the current balance to obtain the secure transaction result data.

[0009] In one embodiment, before obtaining the service key, the host card-based interaction method further includes: Determine the terminal leaf certificate in the business key acquisition request, and the traffic domain signature, payment domain signature, and device domain signature in the terminal leaf certificate; Based on the preset public key, the traffic domain signature, the payment domain signature, and the device domain signature are verified respectively to obtain the total number of valid signatures; A trust threshold is determined based on the current business type. When the total number of valid signatures is greater than or equal to the trust threshold, the business key acquisition request is deemed to have passed verification.

[0010] In one embodiment, the step of determining the trust threshold based on the current service type includes: Obtain the traffic domain signature, the payment domain signature, and the domain type code, domain trust level, and signature issuance timestamp corresponding to the device domain, as well as the scenario business type code, minimum transaction access trust level, and legal transaction time range in the session data; The field type code is compared with the preset standard business type code. If there is a discrepancy, the field type verification is determined to be abnormal. The trust level is compared with the minimum access trust level for the transaction. If any business trust level is lower than the minimum access trust level for the transaction, it is determined to be an unauthorized access by a low-level domain. If the signature issuance timestamp is not within the valid time range of the transaction, the time window verification is deemed abnormal.

[0011] In one embodiment, prior to the step of obtaining the application identifier in the execution instruction sent by the external read / write device, the host card-based interaction method further includes: Obtain the business key sent by the server, encrypt the business key based on the encryption algorithm, and obtain the encrypted business key; The encrypted business key is stored in the key storage module of the mobile terminal.

[0012] Furthermore, to achieve the above objectives, this application also proposes a host card-based interaction method applied to an external read / write device, wherein the host card-based interaction method includes: In response to a response command sent by a mobile terminal, the encrypted transaction data in the response command is obtained; The encrypted transaction data is matched with preset access rules. If the access rules are met, the card swipe transaction is determined to be legal and valid.

[0013] In addition, to achieve the above objectives, this application also proposes a host card-based interactive device, the device comprising: a memory, a processor, and a computer program stored in the memory and executable on the processor, the computer program being configured to implement the steps of the host card-based interactive method described above.

[0014] In addition, to achieve the above objectives, this application also proposes a storage medium, which is a computer-readable storage medium, on which a computer program is stored, and when the computer program is executed by a processor, it implements the steps of the host card-based interaction method described above.

[0015] This application provides an interaction method based on a host card. By parsing the execution instructions issued by an external reading / writing device and extracting the application identifier, the execution instructions can be accurately routed and distributed to the corresponding target card application. The target card application generates a standardized business key acquisition request based on the business logic of the execution instructions, providing a compliant request carrier for secure key retrieval. Based on the business key acquisition request, the pre-stored encrypted business key is decrypted, enabling secure and reliable acquisition of the business key. Relying on a white-box component to carry out transaction data encryption operations, transaction data encryption can be completed based on the business key in a secure isolation environment, generating secure transaction result data with security protection capabilities. Finally, the secure transaction result data is encapsulated into a response instruction and sent back to the external reading / writing device. This achieves accurate distribution of transaction instructions, secure access to business keys, end-to-end encrypted protection of transaction data, and trusted end-to-end instruction interaction, improving the security and efficiency of NFC transaction processing. Attached Figure Description

[0016] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0017] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0018] Figure 1 This is a first flowchart illustrating the host card-based interaction method of this application; Figure 2 A schematic diagram of the architecture of the mobile terminal provided by the host card-based interaction method of this application; Figure 3 This is a second flowchart illustrating the host card-based interaction method of this application. Figure 4 A third flowchart illustrating the host card-based interaction method of this application; Figure 5 This is a schematic diagram of the hardware operating environment involved in the host card-based interaction method in the embodiments of this application.

[0019] The purpose, features, and advantages of this application will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0020] It should be understood that the specific embodiments described herein are merely illustrative of the technical solutions of this application and are not intended to limit this application.

[0021] To better understand the technical solution of this application, a detailed description will be provided below in conjunction with the accompanying drawings and specific implementation methods.

[0022] To achieve the above objectives, this application proposes an interaction method based on a host card, the method comprising: in response to an execution instruction sent by an external read / write device, obtaining an application identifier in the execution instruction; The execution instruction is sent to the target card application corresponding to the application identifier. The target card application generates a business key acquisition request based on the execution instruction. The key storage module decrypts the pre-stored encrypted business key based on the business key acquisition request to obtain the business key. The transaction data is encrypted based on the business key in the white-box component to obtain secure transaction result data. The secure transaction result data is encapsulated into a response instruction and sent to the external read / write device.

[0023] In existing technologies, virtual transit cards mostly rely on a physical eSE (embedded secure element) security chip equipped with a COS system and a dedicated applet to realize card swiping transactions. After an external reading / writing device issues an execution command, the terminal routes the command to the target card application within the eSE. The eSE internally completes the reading and decryption of the encrypted business key, encrypts the transaction data, and sends back the response command. However, this implementation method is highly dependent on a dedicated eSE hardware chip, resulting in poor versatility and portability. Once removed from the eSE hardware environment, the original applet (card application) is difficult to reuse directly, requiring redevelopment, adaptation, and extensive repeated testing. At the same time, the key is protected only by the chip hardware isolation. When removed from the dedicated hardware environment, it is susceptible to security risks such as key leakage, reverse engineering, and illegal theft.

[0024] This application provides an interaction method based on a host card. By parsing the execution instructions issued by an external reading / writing device and extracting the application identifier, the execution instructions can be accurately routed and distributed to the corresponding target card application. The target card application generates a standardized business key acquisition request based on the business logic of the execution instructions, providing a compliant request carrier for secure key retrieval. Based on the business key acquisition request, the pre-stored encrypted business key is decrypted, enabling secure and reliable acquisition of the business key. Relying on a white-box component to carry out transaction data encryption operations, transaction data encryption can be completed based on the business key in a secure isolation environment, generating secure transaction result data with security protection capabilities. Finally, the secure transaction result data is encapsulated into a response instruction and sent back to the external reading / writing device. This achieves accurate distribution of transaction instructions, secure access to business keys, end-to-end encrypted protection of transaction data, and trusted end-to-end instruction interaction, improving the security and efficiency of NFC transaction processing.

[0025] It should be noted that the executing entity in this embodiment can be a computing service device with network communication and program execution functions, such as a tablet computer, personal computer, or mobile phone, or an electronic device or apparatus capable of performing the above functions. The following description uses a host card-based interaction method device as an example to illustrate this embodiment and the subsequent embodiments.

[0026] Based on this, embodiments of this application provide an interaction method based on a host card, referring to... Figure 1 , Figure 1 This is a flowchart illustrating the first embodiment of the host card-based interaction method of this application.

[0027] In this embodiment, the host card-based interaction method includes steps S10 to S50: Please refer to Figure 2 The mobile device includes an NFC module, a VSE container, and a key storage module. The NFC module (NFC CLF, NFC controller front end) is responsible for transmitting and receiving radio frequency signals, receiving APDU commands from the gate / card reader, and sending response commands back to external devices. It is the physical communication interface between the mobile phone and the card reader. The VSE container (VSE SDK, Virtual Secure Element Container) is a software container that replaces the hardware eSE. It provides a standard API interface and is compatible with the original embedded secure element (eSE) card application components (applets), thereby enabling one-time development and multi-environment operation. The VSE container includes at least one card application component and a white-box component, and multiple card application components such as Applet, Applet2, and Appletn. The VSE container provides a secure execution sandbox for card application components, preventing malicious processes from directly accessing the card application's memory. Applets are business logic units running within the VSE container, corresponding to card applications in different business scenarios such as transportation cards and payment cards, used to handle business logic (such as transaction verification and balance calculation). White-box components are secure computing units integrated within the VSE container, used to perform transaction encryption operations such as 3DES and MAC generation. Keys are obfuscated and protected within the module. The key storage module (KeyStore) is connected to the VSE container via API, used to securely store and decrypt business keys. Plaintext keys only circulate within the KeyStore and white-box, and are not exposed to user process memory. It also provides device binding and data integrity verification capabilities.

[0028] By designing the VSE SDK container, compatibility with the API interfaces of the COS (Chip Operating System) in the existing eSE security chip is achieved. Specifically, the VSE SDK container pre-defines the same API interface set, calling protocol, and data interaction format as the original COS, fully supporting all COS APIs called by the original Applet during runtime. Whether the Applet is used for authentication, key exchange, data encryption / decryption, or transaction instruction transmission, the VSE SDK container can respond, correctly parse, and execute the corresponding operations. This ensures that the original Applet can run normally directly within the VSE SDK container without any code modification or adaptation to new interface specifications, achieving seamless reuse. Since the original Applet has already undergone comprehensive functional, security, and compatibility testing, reuse significantly reduces the workload of repetitive testing in new scenarios, avoiding the manpower and time costs associated with repeated testing, while also mitigating potential risks during testing and ensuring the stability and security of business functions. Step S10: In response to the execution instruction sent by the external read / write device, obtain the application identifier in the execution instruction.

[0029] It should be noted that external reading and writing devices are contactless reading and writing devices that communicate with mobile terminals through radio frequency signals, send transaction instructions and receive responses. These devices can be turnstiles, POS machines, traffic card readers, etc.

[0030] In this embodiment, the external read / write device transmits an analog modulated signal carrying data via a radio frequency field. The NFC module of the mobile terminal senses the spatial radio frequency electromagnetic field in real time and acquires the original continuous analog voltage signal. The field strength amplitude and carrier characteristics of the original analog signal are compared to detect the radio frequency field activation status. By comparing with a preset threshold, it is determined whether the radio frequency field is effectively activated, and valid analog signals are selected. The valid analog signals are demodulated and decoded, converting the analog radio frequency signal into a binary data sequence. The integrity of the data frame is verified, and invalid data with transmission errors is removed to obtain a standard business instruction that can be identified, parsed, and executed, i.e., an execution instruction. The execution instruction is parsed, and the application identifier (AID) is extracted from the parsing result.

[0031] In one feasible implementation, before step S20, the following steps may be included: parsing the execution instruction to obtain the instruction code and the application identifier; when the instruction code is an application selection instruction, matching the application identifier with a preset card application mapping table; and determining the card application that has a mapping relationship with the application identifier as the target card application.

[0032] In this embodiment, the external device transmits the data via the NFC link and obtains a valid executable instruction after processing by the terminal's NFC CLF. Using the complete execution instruction as input, the instruction is split and semantically parsed according to the communication protocol and application interaction specifications. Two independent data fields, the instruction code and the application identifier, are extracted and separated from the fixed field positions of the instruction. The parsed instruction code is used as the basis for determining the instruction's service type. When the instruction code is determined to be an application selection instruction, a pre-stored preset card application mapping table is retrieved. This mapping table pre-establishes a one-to-one binding mapping relationship between each application identifier and its corresponding card application. Using the currently parsed application identifier as the search keyword, all entries in the preset card application mapping table are traversed and matched, and the application identifier data is compared one by one to ensure complete consistency. When a mapping entry that completely matches the current application identifier data is found, the corresponding card application entity bound to that entry is read, and the successfully matched card application is officially identified as the target card application required for this service interaction.

[0033] In one feasible implementation, before step S10, the method further includes: obtaining the service key sent by the server, encrypting the service key based on the encryption algorithm to obtain the encrypted service key; and storing the encrypted service key in the key storage module of the mobile terminal.

[0034] In this embodiment, during the card activation stage, the mobile terminal actively establishes a dedicated secure transmission channel with the card issuance service platform, receives the card activation initialization raw data packet uniformly issued by the platform, parses and verifies the obtained raw data packet, and after completing the compliance verification of the card activation data packet, the mobile terminal extracts the standard application identifier from the legal data packet. At the same time, it completes the creation and registration of the target card application instance in the security domain corresponding to the local eSE security chip of the terminal, establishes a unique binding mapping relationship between the application identifier and the target card application, and persistently stores the mapping binding table locally, thereby forming a fixed routing matching rule. This provides the core matching basis for the subsequent external reading and writing devices to accurately route to the corresponding target card application based on the application identifier when sending execution instructions.

[0035] After binding the application identifier to the card application, the business key uniformly issued by the card issuing platform is extracted from the compliant card opening data packet. After obtaining the business key, it is encrypted using a national cryptographic algorithm or a compliant encryption algorithm such as 3DES to generate encrypted business key ciphertext, which is then stored in the key storage module. After secure key storage, the mobile terminal initializes the newly registered target card application, uniformly configuring the business interaction logic, instruction parsing standard template, and transaction data format rules corresponding to the card application. Simultaneously, card application permission allocation is completed, limiting access permissions for external read / write devices, internal key access permissions, and transaction data encryption / decryption operation permissions. The mobile terminal parses the configuration information in the card opening data packet, pre-setting various basic transaction parameters, including key content such as transaction type identifier, standard message encapsulation format, fixed response instruction template, and transaction encryption / decryption algorithm identifier. It also solidifies the data encapsulation specifications and format rules required for subsequent full-process transaction business, ensuring that after transaction data encryption based on the business key is completed, it can be automatically encapsulated into compliant response instructions according to a unified standard format, enabling standard message interaction with external read / write devices.

[0036] Please refer to Figure 3 In the card opening and migration initialization process, the mobile terminal is the main body for initiating the process and processing local data. It contains four components: NFC framework, SDK container, KeyStore, and wallet. The NFC framework is responsible for initiating the card opening initialization request, calling the initialization interface and passing in the terminal's unique identifier, while receiving the final card opening result and triggering data saving. The SDK container receives the initialization request, uses the backend server's public key to encrypt the data to confirm the scheme, and then receives the encrypted personalized data returned by the server, completes the decryption using a secure channel, and then re-encrypts the decrypted card data before handing it over to KeyStore for processing. KeyStore signs the data and obtains the terminal certificate chain, transmits the data to the server, and completes the subsequent encrypted storage of card data to ensure local data security. The server acts as a relay gateway between the terminal and the business server. It is responsible for receiving data, signatures, and certificate chains transmitted from the terminal and passing them through to the server. At the same time, it sends the encrypted data returned by the server back to the KeyStore on the terminal side. The backend server is responsible for verifying the certificate chain uploaded by the terminal to verify the legitimacy of the terminal's identity and obtaining the secure session key. It calculates and generates a secure channel key and uses this key to encrypt the personalized data on the card. Finally, it sends the encrypted personalized data back to the server, which then forwards it to the mobile terminal, completing the secure data interaction and card personalization process of the entire card opening process.

[0037] Step S20: The execution instruction is sent to the target card application corresponding to the application identifier, and the target card application generates a service key acquisition request based on the execution instruction.

[0038] In this embodiment, the NFC module takes a valid execution command as input, completes data encapsulation and routing according to the communication interface specification, and forwards the execution command completely to the VSE container within the terminal. After receiving the execution command from the NFC module, the VSE container parses and identifies the command, matches the pre-configured application distribution relationship according to the type identifier and application identifier fields agreed upon in the command, and distributes the current execution command to the corresponding target card application according to the internal routing distribution rules.

[0039] After receiving the business execution instruction distributed by the VSE container, the target card application performs business semantic parsing to identify the current transaction scenario, business type, and key business parameters such as the required key identifier number and key permission level. The target card application then calls the API interface definition provided by the VSE container and, according to the interface's specified message format, field order, and data length specifications, sequentially fills in the fixed protocol version field, the caller application identity field, and the session sequence number field. The parsed key identifier, business scenario code, permission request identifier, and random challenge factor are then sequentially filled into the designated positions in the message as business-private fields. Following the preset secure call protocol rules, the complete original message is subjected to integrity verification value calculation, message signature encapsulation, and the addition of protocol encapsulation fields such as message start character, end character, and length verification field, completing the structured assembly of the compliant key request message. Through the API call entry point provided by the VSE container, and in accordance with the cross-module secure communication protocol, carrying the identity access token and call permission credentials, the assembled and encrypted key request message is sent to the key storage module (KeyStore) to initiate a standardized business key retrieval call request.

[0040] In step S30, the key storage module decrypts the pre-stored encrypted business key based on the business key acquisition request to obtain the business key, which is in white-box key form.

[0041] Step S40: The transaction data is encrypted in the white-box component based on the business key to obtain secure transaction result data.

[0042] In this embodiment, the execution entity of this step is a white-box security component deployed in the VSE container. The input parameters include the transaction data to be processed and the white-box BLOB data of the corresponding business key. The core execution action is to perform encryption and MAC operations on the transaction data based on the equivalent key structure corresponding to the business key, and finally output secure transaction result data.

[0043] Optionally, the overall interaction is scheduled by the NFC framework. The target card application is not an independent process and does not have the ability to initiate key requests. Only the NFC framework has the right to access the key materials protected by the KeyStore. When processing card transaction instructions, the NFC framework needs to perform encryption or MAC operations on the transaction data. For this purpose, it initiates a key call to the system KeyStore. The request includes a key alias used to identify the target business key and the transaction data to be processed. The KeyStore adopts a system-level access control mechanism and does not perform business-level access token verification, message parsing, or other operations. Its access verification is only completed based on the application UID binding rules.

[0044] Optionally, after the caller satisfies KeyStore's access restrictions, KeyStore locates the corresponding encrypted white-box key material from its internal secure key store based on the key alias, and recovers the BLOB data required by the white-box algorithm through a protected hardware decryption process. This BLOB data is obfuscated material required by the white-box component to build an equivalent key structure; it does not contain directly usable plaintext keys and is irreversible and non-derivative.

[0045] KeyStore returns the decrypted white-box BLOB data to the NFC framework. The NFC framework, through its embedded VSESDK, transmits this BLOB data to the white-box security component within the VSE container. Upon receiving the BLOB data, the white-box security component reconstructs an equivalent key structure valid only within the white-box environment within its isolated operating environment. Based on this equivalent key, it performs security operations such as 3DES encryption / decryption and MAC generation on the transaction data to obtain secure transaction result data.

[0046] In transaction processing scenarios, the white-box component performs calculations using an equivalent key structure only in memory and does not persist this structure. After completing the calculations, the white-box component only returns the encrypted result, which serves as the secure transaction result data, and the MAC verification value to the NFC framework, which then continues the subsequent card transaction processing flow.

[0047] In scenarios such as card personalization that require writing card keys, the white-box component can convert the internal equivalent key structure back into new white-box BLOB data and hand it over to the NFC framework for persistent storage. Before persistence, the BLOB data will be protected by KeyStore's hardware encryption capabilities, thereby ensuring that the white-box key material retains its irreversible, non-exportable, and non-parsable security attributes in the storage state.

[0048] Step S50: Encapsulate the secure transaction result data into a response instruction and send the response instruction to the external read / write device.

[0049] In this embodiment, after the white-box module completes security operations such as 3DES encryption / decryption and MAC value generation, it generates the final authentication result data and sends the result back to the target card application within the VSE container. Upon receiving the result from the white-box module, the target card application uses the result data as its payload and, according to the NFC protocol and APDU instruction format specifications, sequentially assembles the frame start identifier, instruction response code, status code, payload data, verification field, and frame end identifier. The assembled response APDU instruction is submitted by the target card application to the VSE container through a standard interface. The VSE container performs internal routing and format encapsulation of the instruction and forwards it transparently to the upper-layer NFC framework. After receiving the response instruction, the NFC framework completes data framing and timing control according to the underlying communication protocol and sends it to the NFC CLF radio frequency front-end module. The NFC CLF encodes and modulates the received digital instruction data, converting it into a radio frequency analog signal, which is then transmitted outwards via an antenna in a radio frequency field manner. The external card reader receives the analog signal through radio frequency field sensing, demodulates, decodes, and verifies the frame to parse the response instruction content, completing a complete authentication transaction interaction.

[0050] In this embodiment, by parsing the execution instructions issued by the external reading and writing device and extracting the application identifier, the execution instructions can be accurately routed and distributed to the corresponding target card application. The target card application generates a standardized business key acquisition request based on the business logic of the execution instructions, providing a compliant request carrier for secure key retrieval. Based on the business key acquisition request, the pre-stored encrypted business key is decrypted, enabling secure and reliable acquisition of the business key. Relying on the white-box component to carry out transaction data encryption operations, transaction data encryption can be completed based on the business key in a secure isolation environment, generating secure transaction result data with security protection capabilities. Finally, the secure transaction result data is encapsulated into a response instruction and sent back to the external reading and writing device, realizing accurate distribution of transaction instructions, secure access to business keys, end-to-end encrypted protection of transaction data, and trusted end-to-end instruction interaction, thereby improving the security and business processing efficiency of NFC transaction processing.

[0051] In this embodiment, based on the first embodiment of this application, the content that is the same as or similar to that in the first embodiment described above can be referred to the above description and will not be repeated hereafter. Based on this, step S30 further includes steps S31 to S33: Step S31: When the key storage module receives the service key acquisition request sent by the target card application, it acquires the key identifier and service scenario tag in the service key acquisition request.

[0052] Step S32: Use the key identifier and business scenario tag as an index to match with a preset key library to obtain the encrypted traffic business key.

[0053] Step S33: Decrypt the traffic service key based on a symmetric encryption algorithm to obtain the traffic service key, which includes an authentication subkey and a toll deduction subkey.

[0054] In this embodiment, the user carries a virtual transportation card on their mobile phone and approaches a bus or subway gate (external reading and writing device). The gate initiates radio frequency communication and sends a card swiping execution instruction in APDU format. The VSE container of the mobile terminal parses the application identifier in the instruction and routes the instruction to the target card application. The target card application identifies the current scenario as a composite business of card swiping and fare deduction, generates a business key acquisition request adapted to the dual business, and sends it to the key storage module KeyStore to start the key decryption process.

[0055] During the mobile terminal card activation phase, the transportation card composite business key, which includes authentication and deduction sub-keys, is encrypted using the device root key bound to the terminal hardware and stored in encrypted form in the KeyStore secure isolated storage area. The decrypted business key contains a card swipe authentication sub-key and a fare deduction calculation sub-key. The card swipe authentication sub-key is used for two-way identity authentication with external reading and writing devices and instruction signature verification; the fare deduction calculation sub-key is used for encrypting transaction data related to fare deduction, MAC verification, and balance deduction calculation.

[0056] When the KeyStore key storage module receives a business key retrieval request from a transit card application, it performs an integrity check on the request, verifying the message length and checksum to ensure there are no missing or tampered parts. Upon successful verification, the key request message is disassembled according to a preset security protocol format, extracting the transit card applet identifier, business scenario marker, and key identifier. The transit card applet identifier (AID) identifies which virtual transit card initiated the request, distinguishing different transit card applications, such as bus cards, subway cards, and intercity cards. The business scenario informs the KeyStore of the key supporting the business that needs to be retrieved. The business key identifier is used to search and match pre-stored encrypted business keys. The parsed results may also include the transaction session ID, caller identity, and transaction scenario parameters (such as travel type: bus / subway, expected fare range, etc.). The caller identity is verified, checking whether the transit card application identifier is within a preset whitelist of legitimate transit card applications, confirming that the target card application initiating the request is an authorized legitimate application, and excluding unauthorized applications from accessing the key. Verify the validity of the session, check whether the transaction session identifier is within the session validity period, and confirm that the session has not expired or been reused.

[0057] Based on the extracted business key type identifier, the key type identifier and the transportation card AID are used as dual indexes to locate the pre-stored transportation card composite business key ciphertext. The transportation card composite business key ciphertext includes authentication subkey ciphertext and deduction operation subkey ciphertext. The key obtained after decryption can support two types of services at the same time, avoiding business failure caused by key mismatch. The ciphertext of the transportation card's composite business key is split into multiple equal-length ciphertext blocks using a fixed block length symmetric encryption algorithm. For example, if the key ciphertext length is 32 bytes, it is split into 4 blocks. Based on the device root key, round function subkeys are generated according to the rules of the symmetric encryption algorithm. The round function subkeys are in the reverse order of the round function subkeys used during encryption. For each ciphertext block, the inverse operations of initial inverse permutation, round function inverse iteration, and final inverse permutation are performed sequentially. The initial inverse permutation adjusts the initial position of the ciphertext block to restore the initial permutation state during encryption. The round function inverse iteration calls the subkeys sequentially to perform inverse substitution, inverse shift, and inverse mixing operations on the block data, restoring the plaintext data round by round. The final inverse permutation performs a final inverse permutation on the block data after inverse iteration to obtain the plaintext data of a single block. After each block is decrypted, the format and length of the plaintext data in that block are verified to confirm that there are no calculation errors. If an abnormality occurs, decryption is immediately terminated, all calculated data is overwritten and cleared, and a decryption failure response is returned. The plaintext blocks obtained from decryption are concatenated and reassembled one by one in the order of the original ciphertext blocks to form a complete business key with the same length as before encryption, including an authentication subkey and a billing operation subkey. The integrity of the reassembled business key set is verified to confirm that the key length and format meet the preset requirements and that there are no missing or disordered keys. According to preset rules, the business key set is logically split into two independent subkeys, which are marked as authentication subkey and billing operation subkey, respectively.

[0058] In this embodiment, step S40 includes steps S41 to S42: Step S41: When the white-box encryption module receives the deduction operation subkey, it encrypts the transaction data based on the 3DES symmetric encryption algorithm, and sends the encrypted transaction ciphertext and verification code to the transportation card application. In step S42, the transportation card application assembles the encrypted transaction ciphertext, the verification code, and the current balance to obtain the secure transaction result data.

[0059] In this embodiment, KeyStore sends the fare deduction sub-key from the transportation service key to the white-box encryption module via a secure channel. The target card application organizes the transaction data into data to be encrypted, including the ride type (bus / subway), fare amount, transaction serial number, current card balance, transaction timestamp, and card status (normal / lost), and transmits it to the white-box encryption module through the secure channel.

[0060] The white-box encryption module calls the deduction operation subkey and uses the 3DES symmetric encryption algorithm to encrypt the transaction data into blocks, generating encrypted transaction ciphertext. Using the deduction operation subkey, it calculates the MAC (Message Authentication Code) on the encrypted transaction ciphertext and transaction serial number to generate a MAC checksum, which is used by the gate to verify the integrity of the transaction data. The encrypted transaction ciphertext and MAC checksum are returned to the target card application through a secure channel. The target card application calls the deduction operation subkey to deduct the card balance, generating a new balance and recording the transaction in the log. The target card application verifies the validity of the deducted balance. If the balance is not lower than 0, the deduction operation is confirmed as complete; otherwise, the transaction is terminated, an insufficient balance response is returned, and the gate refuses passage.

[0061] The target card application assembles secure transaction result data based on the authentication result, encrypted transaction ciphertext, MAC checksum, new balance after deduction, and transaction serial number. Following the APDU response instruction format, it encapsulates this secure transaction result data into a response instruction and transmits it back to the external reader / writer via the VSE container and NFC radio frequency channel. Upon receiving the response instruction, the external reader / writer uses its own deduction key to decrypt the transaction ciphertext, verify the MAC checksum, confirm the transaction data's legitimacy and lack of tampering, record the transaction information, and open the gate for passage. After receiving confirmation from the gate, the mobile terminal target card application completes the transaction, the KeyStore overwrites and clears the business key, and the key's use is terminated.

[0062] In this embodiment, based on the first embodiment of this application, the content that is the same as or similar to that in the first embodiment described above can be referred to the above description and will not be repeated hereafter. Based on this, please refer to... Figure 4 Before step S30, steps A10 to A30 are also included: Step A10: Determine the terminal leaf certificate in the business key acquisition request, and the business domain signature, payment domain signature, and device domain signature in the terminal leaf certificate; In this embodiment, the terminal leaf certificate contains pre-built complete trust verification information, including independent digital signatures from three independent business domains: the business domain, the payment domain, and the device domain, corresponding to the business domain signature, payment domain signature, and device domain signature, respectively. Simultaneously, the security level and trust threshold corresponding to the business type are pre-set, and the terminal leaf certificate itself has been jointly signed by the intermediate certificates of the three business domains, ensuring its legitimacy and immutability.

[0063] The mobile terminal has a pre-configured public key of the root certificate authority (Root CA) as a globally unique trust anchor. It also has three types of intermediate certificates for business domains: business domain, payment domain, and device domain, which correspond to the terminal's leaf certificate. Each type of intermediate certificate is issued by the root certificate authority and corresponds to an independent business trust domain. Each business domain intermediate certificate manages its own public and private key pair independently. They are completely isolated physically and logically and do not communicate with each other, ensuring that the leakage of keys in one business domain will not affect the security of other business domains.

[0064] When KeyStore receives a business key acquisition request initiated by the target card application, it extracts the transportation card terminal leaf certificate from the request message, as well as the three business domain signatures and trust thresholds built into the terminal leaf certificate. At the same time, it extracts the intermediate certificates of the business domain, payment domain, and device domain carried in the request and starts the multi-business domain trust verification process.

[0065] Step A20: Based on the preset public key, verify the business domain signature, the payment domain signature, and the device domain signature respectively to obtain the total number of valid signatures; In this embodiment, KeyStore invokes the locally pre-configured root certificate authority public key to perform legitimacy verification on the intermediate certificates corresponding to the business domain, payment domain, and device domain one by one. During verification, the digital signature of the intermediate certificate is extracted and decrypted using the root certificate authority public key to verify the signature, confirming that the signature source of the intermediate certificate is legitimate and has not been tampered with. Based on the validity period of the intermediate certificate, it is confirmed that it has not expired or been revoked; the issuer information contained in the certificate fully matches the issuance information of the root certificate authority, and there are no issues such as mismatched issuing entities or abnormal signatures. The format integrity of the intermediate certificate can also be verified to confirm that the certificate has no missing fields or traces of tampering, ensuring that the intermediate certificate is a valid certificate legally issued by the root certificate authority, and not an invalid certificate that has been forged or tampered with. Once all intermediate certificates have passed the above comprehensive verification, confirming their legitimacy, validity, and validity period, and that the issuing entity is legitimate, the legitimacy verification of the intermediate certificates is completed. This fundamentally ensures that the public keys of each business domain used for subsequent signature verification have legitimate validity, avoiding signature verification failures due to invalid, tampered, or revoked intermediate certificates, and ensuring the accuracy of multi-source signature verification.

[0066] After verification, the public keys corresponding to the intermediate certificates of the business domain, payment domain, and device domain are extracted respectively. The independent signatures of the corresponding business domains on the terminal leaf certificates are verified one by one. That is, the public key of the intermediate certificate of the business domain is used to verify the traffic domain signature on the terminal leaf certificate, the public key of the intermediate certificate of the payment domain is used to verify the payment domain signature on the terminal leaf certificate, and the public key of the intermediate certificate of the device domain is used to verify the device domain signature on the terminal leaf certificate. The verification process of the three signatures is independent of each other and forms a cross-verification logic. Since the private keys of each business domain are stored independently, if an attacker wants to forge the multi-source signature on the terminal leaf certificate, he must obtain the private keys of the three business domains at the same time, which increases the attack cost and effectively prevents the risk of illegal key calls after a single business domain is compromised.

[0067] Step A30: Determine the trust threshold based on the current business type. When the total number of valid signatures is greater than or equal to the trust threshold, determine that the business key acquisition request has passed verification.

[0068] In this embodiment, after the signature verification is completed, the verification results of the three domain signatures are counted to obtain the total number of valid signatures; and the preset trust threshold in the terminal leaf certificate is read, and the total number of valid signatures is compared with the threshold. If the total number of valid signatures is greater than or equal to the trust threshold, the trust verification of this key request is determined to be successful. If the total number of valid signatures is less than the trust threshold, the trust verification is determined to be unsuccessful, the key request is rejected, and the subsequent process is terminated.

[0069] Optionally, different business types correspond to different security scenario levels. The trust threshold for high security scenarios is 3, requiring all 3 signatures to pass; the trust threshold for high security scenarios is 2, requiring at least 2 signatures to pass; and for low security scenarios, the trust threshold for high security scenarios is 1, requiring any 1 signature to pass for verification.

[0070] In one feasible implementation, steps A40 to A70 are included before step A30: Step A40: Obtain the business domain signature, the payment domain signature, and the domain type code, domain trust level, and signature issuance timestamp corresponding to the device domain, as well as the scenario business type code, minimum transaction access trust level, and legal transaction time range in the session data; Step A50: Perform field matching and comparison between the domain type code and the preset standard business type code. If there is an inconsistency, determine that the domain type verification is abnormal. Step A60: Compare the trust level with the minimum access trust level for the transaction. If any business trust level is lower than the minimum access trust level for the transaction, it is determined to be an unauthorized access by a low-level domain. Step A70: If the signature issuance timestamp is not within the valid time interval of the transaction, the time window verification is determined to be abnormal.

[0071] In this embodiment, the structured attribute data of each domain is sequentially parsed and extracted from the multi-source signature data of the intermediate certificates and terminal leaf certificates of the transportation domain, payment domain, and device domain that have completed signature verification, to obtain the domain type code, domain trust level identifier, signature issuance timestamp, certificate effective start time, and certificate expiration end time; the preset scenario business type code, minimum access trust level for the transaction, and the legal time range of this transaction are extracted from the current transportation card swipe transaction session data.

[0072] A pre-defined mapping table between business domain type codes and standard business type codes is established, clearly defining the unique standard business codes and business attribute definitions for each of the transportation, payment, and device domains. The transportation, payment, and device domain type codes are extracted from the fixed data segments of the intermediate certificates in the three business domains. Simultaneously, the unified standard toll deduction code corresponding to the card-swiping travel scenario is extracted from the current card-swiping transaction session request data, and three pre-defined business attribute bases for this scenario are read: toll authentication-specific attribute, fare deduction-specific attribute, and terminal device trusted authentication-specific attribute. Based on the preset mapping relationship, a fixed binding comparison is performed. First, the read traffic domain type code is matched with the standard code belonging to the access authentication business in the mapping table to determine that the two codes are completely consistent and the business attribute tags are strictly corresponding. Then, the payment domain type code is matched with the standard code belonging to the ride fare deduction business in the mapping table to verify that the code fields are different and the business attribute belongs to the deduction transaction category. Finally, the device domain type code is precisely compared with the standard code corresponding to the trusted authentication of terminal devices in the mapping table to confirm that the codes match and the business attribute is only used to verify the legality of the terminal device. If a traffic domain code is matched with a toll deduction service, a payment domain code is matched with a pass authentication service, a device domain code is used to impersonate a pass or toll deduction service code, or any domain type code is not within the preset legal code whitelist or cannot form a unique and compliant mapping relationship with the standard business code of the current card swiping scenario, the code matching is determined to be unsuccessful, the business attribute is misattributed, the domain type verification is marked as abnormal, and it is determined that there is cross-domain business impersonation or domain type confusion substitution behavior. The key request is blocked. From the perspective of accurate matching of the coding field and rigid binding of business attributes, the risk of cross-scenario mixing and unauthorized use of signatures from different business domains is avoided.

[0073] Obtain the pre-stored trust level classification table, convert the trust level identifiers of the three domains into quantifiable level values, and then compare them with the minimum security level value preset for this card swipe transaction. Determine whether the quantifiable level value of each business domain is greater than or equal to the minimum threshold for transaction access. If any business domain level value is lower than the security access standard, it is determined that the low-level domain unauthorized verification fails.

[0074] The issuance timestamps of the three business domain signatures and the validity and expiration times of the intermediate certificates for each domain are uniformly converted into a standard time format and incorporated into the same time coordinate axis. The issuance time of each domain signature is calculated to ensure it falls within the legitimate time interval of the current transaction. The validity time intervals of the three business domain certificates are checked for any common overlapping periods, and the issuance times of each domain signature are concentrated within the same legitimate transaction window. Data combinations with excessively large timestamp offsets, signature issuance times scattered across different time periods, or certificate validity periods without overlap are identified as time window verification anomalies. This prevents attackers from forging signatures for each domain separately within different validity windows and then reassembling and reusing them, thus avoiding attack paths involving time tampering and asynchronous combination forgery. If all three data comparison logics—domain type matching, trust level compliance, and time window overlap—pass compliance, the cross-domain cross-verification is deemed overall effective. Any data verification anomalies in any dimension directly reject the current business key acquisition request, effectively preventing domain type confusion, low-level domain unauthorized access, and time forgery attacks from the data layer's closed loop.

[0075] Optionally, the signature issuance time of each business domain is checked sequentially to see if it falls within the interval formed by the start and end times of the legal transaction. By comparing the timestamp values, if the signature issuance timestamp of a domain is less than the start time of the legal transaction or greater than the end time, the signature in that domain is determined to be outside the legal window period of the transaction, indicating an abnormal timestamp offset. The common intersection of the three time intervals is calculated, using the certificate validity time of the transportation domain, payment domain, and device domain as the start time and the certificate expiration time as the end time. If the validity periods of the three certificates do not overlap, or if any two or all three certificate time intervals are completely different and do not intersect, the certificate validity compliance is directly determined to be invalid. Further checks are performed on the clustering consistency of the signature issuance times of the three domains. The issuance timestamps of the signatures in each of the three business domains are extracted, and the difference between each pair of timestamps is calculated and compared with a preset maximum allowed time offset threshold. If the difference between the timestamps of any two domain signatures exceeds the preset offset threshold, the signature issuance times of the domains are considered to be scattered in different time periods and do not belong to the same batch of trusted endorsements, indicating an abnormal time consistency check.

[0076] In this embodiment, based on the first embodiment of this application, the content that is the same as or similar to that in the first embodiment described above can be referred to the above description and will not be repeated hereafter. Based on this, the interaction based on the host card includes steps B10~B20: Step B10: In response to a response command sent by the mobile terminal, obtain the encrypted transaction data in the response command; Step B20: Match the encrypted transaction data with the preset access rules. If the access rules are met, the card swipe transaction is determined to be legal and valid.

[0077] In this embodiment, the external reading and writing device initiates a transaction interaction process, generates and encapsulates the execution instruction data corresponding to the card swipe transaction, and carries the transaction trigger identifier, interaction protocol data and basic transaction parameters inside the instruction, completes the structured packetization and protocol format encapsulation of the execution instruction, and then sends the execution instruction outward through the near field communication link to complete the push of the transaction request instruction.

[0078] During the entire internal terminal processing phase, from the execution instruction being received by the terminal and routed to the target card application, to the target card application generating a business key acquisition request, to the business key being decrypted by the key storage module, to the local transaction data being encrypted based on the business key and generating secure transaction result data, the external read / write device continuously maintains the near-field communication link connection, keeps the session context and transaction session identifier valid, listens in real time and waits for the terminal to send back response instructions, and at the same time locally caches the basic configuration parameters, transaction time base, legal business code and security verification rules of this transaction, to prepare the preliminary data for subsequent reception and verification.

[0079] When the terminal returns a response instruction indicating that the encapsulation is complete, the external read / write device first performs frame integrity verification, protocol format parsing, and message legality checks on the received response instruction. It verifies whether the message length, frame structure, and verification fields are compliant, and removes incomplete, tampered, or abnormally formatted illegal messages. Subsequently, it parses and extracts the secure transaction result data from the response instruction, and splits and extracts the encrypted transaction business data, integrity verification code, and transaction authentication result information.

[0080] External reading and writing devices call locally preset security verification parameters and business matching rules to perform business scenario matching, time window verification, and data integrity verification on the parsed secure transaction result data. They verify that the transaction business type is consistent with the current card swipe scenario, the transaction data timestamp falls within the legal transaction range, and the integrity verification code passes the verification, thus determining that the terminal transaction data is trustworthy and has not been tampered with.

[0081] After successful verification, the encrypted transaction message, card identity identifier, transaction amount, transaction serial number, transaction timestamp, and message integrity check code are parsed from the secure transaction result data. Following the preset communication protocol and business data format specifications, the encrypted transaction data is structured and split, redundant data is removed, standard business data format is restored, and an independent transaction session instance corresponding to this card swipe transaction is established and bound to the card's unique identifier and the transaction session number. Locally preset transportation service fare rules, access permission blacklists / whitelists, and card status control rules are retrieved. First, the card identity identifier is used to verify whether the card is in a normal and usable state and whether it is reported lost, frozen, expired, or otherwise abnormal. Then, the preset access permission policy is matched with the route and travel scenario of this transaction to comprehensively determine whether the virtual transportation card has the access permission for this card swipe to enter or exit the station, thus completing the compliance judgment of the access permission. When all business elements corresponding to the encrypted transaction data meet the preset access rules, the external reader / writer determines that the card swipe transaction is legal and valid, confirms the trustworthiness of the mobile terminal's virtual card identity, the compliance of the transaction behavior, and the possession of normal travel access permissions. It then triggers the gate access control logic, simultaneously recording and archiving the transaction data, registering the transaction history, and generating a transaction confirmation status. If any business element does not meet the access rule matching conditions, the access verification is directly determined to have failed, the gate is refused to open, a transaction rejection status is generated, and the interaction process is terminated. After the access verification is successful, the external reader / writer performs ride transaction accounting processing based on the parsed transaction amount, transaction time, card identifier, transaction serial number, and other elements, generating standardized transaction accounting records according to transportation operation reconciliation specifications. Key information such as card information, transaction time, deduction amount, session number, access result, and verification status are organized in a unified format and written into the local transaction logbook, completing the local registration and persistent storage of transaction records to ensure traceability.

[0082] External read / write devices perform business parsing and transaction logic processing on encrypted transaction data, complete the determination of card-swipe access permission, record the ride transaction and register the transaction flow, and generate transaction confirmation result status information; and store the verification result, access release instruction and transaction archive information locally and synchronize them with the business.

[0083] This application provides a host card-based interactive device, including: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, the instructions being executed by the at least one processor to enable the at least one processor to execute the host card-based interactive method in Embodiment 1 above.

[0084] The following is for reference. Figure 5The diagram illustrates a structural schematic of a host card-based interactive method device suitable for implementing embodiments of this application. The host card-based interactive method device in the embodiments of this application may include, but is not limited to, mobile terminals such as mobile phones, laptops, personal digital assistants (PDAs), tablet computers (PADs), etc., and main positioning terminals such as digital TVs, desktop computers, etc. Figure 5 The host card-based interaction method device shown is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of this application.

[0085] like Figure 5 As shown, a host card-based interactive device may include a processing unit 1001 (e.g., a central processing unit, a graphics processing unit, etc.) that performs various appropriate actions and processes based on programs stored in read-only memory (ROM) 1002 or programs loaded from storage device 1003 into random access memory (RAM) 1004. The random access memory 1004 also stores various programs and data required for the operation of the host card-based interactive device. The processing unit 1001, ROM 1002, and RAM 1004 are interconnected via a bus 1005. An input / output (I / O) interface 1006 is also connected to the bus. Typically, the following systems can be connected to I / O interface 1006: input devices 1007 including, for example, touchscreens, touchpads, keyboards, mice, image sensors, microphones, accelerometers, gyroscopes, etc.; output devices 1008 including, for example, liquid crystal displays (LCDs), speakers, vibrators, etc.; storage devices 1003 including, for example, magnetic tapes, hard disks, etc.; and communication devices 1009. Communication device 1009 allows the host card-based interactive method device to exchange data wirelessly or via wired communication with other devices. Although host card-based interactive method devices with various systems are shown in the figures, it should be understood that it is not required to implement or possess all of the systems shown. More or fewer systems may be implemented alternatively.

[0086] Specifically, according to the embodiments disclosed in this application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments disclosed in this application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via a communication device, or installed from storage device 1003, or installed from read-only memory 1002. When the computer program is executed by processing device 1001, it performs the functions defined in the methods of the embodiments disclosed in this application.

[0087] The host card-based interaction method device provided in this application, employing the host card-based interaction method in the above embodiments, can solve the technical problem of how to improve the security and efficiency of NFC transaction processing. Compared with the prior art, the beneficial effects of the host card-based interaction method device provided in this application are the same as those of the host card-based interaction method provided in the above embodiments, and other technical features in this host card-based interaction method device are the same as those disclosed in the previous embodiment method, and will not be repeated here.

[0088] It should be understood that the various parts disclosed in this application can be implemented using hardware, software, firmware, or a combination thereof. In the description of the above embodiments, specific features, structures, materials, or characteristics can be combined in any suitable manner in one or more embodiments or examples.

[0089] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

[0090] This application provides a computer-readable storage medium having computer-readable program instructions (i.e., a computer program) stored thereon, the computer-readable program instructions being used to execute the host card-based interaction method in the above embodiments.

[0091] The computer-readable storage medium provided in this application may be, for example, a USB flash drive, but is not limited to, electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems or devices, or any combination thereof. More specific examples of computer-readable storage media may include, but are not limited to: electrical connections having one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fibers, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. In this embodiment, the computer-readable storage medium may be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system or device. The program code contained on the computer-readable storage medium may be transmitted using any suitable medium, including but not limited to: wires, optical cables, radio frequency (RF), etc., or any suitable combination thereof.

[0092] The aforementioned computer-readable storage medium may be included in a host card-based interactive method device; or it may exist independently and not assembled into a host card-based interactive method device. The aforementioned computer-readable storage medium carries one or more programs. When the aforementioned one or more programs are executed by the host card-based interactive method device, the host card-based interactive device: in response to an execution instruction sent by an external read / write device, obtains an application identifier from the execution instruction; sends the execution instruction to a target card application corresponding to the application identifier, the target card application generating a service key acquisition request based on the execution instruction; the key storage module decrypts a pre-stored encrypted service key based on the service key acquisition request to obtain a service key; encrypts transaction data based on the service key in the white-box component to obtain secure transaction result data; encapsulates the secure transaction result data into a response instruction, and sends the response instruction to the external read / write device.

[0093] Computer program code for performing the operations of this application can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, and C++, and conventional procedural programming languages ​​such as the "C" language or similar programming languages. The program code can be executed entirely on the client computer, partially on the client computer, as a standalone software package, partially on the client computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the client computer via any type of network—including a local area network (LAN) or a wide area network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0094] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation that may be implemented in systems, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing the specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, may be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0095] The modules described in the embodiments of this application can be implemented in software or hardware. The names of the modules do not necessarily limit the functionality of the unit itself.

[0096] The readable storage medium provided in this application is a computer-readable storage medium that stores computer-readable program instructions (i.e., a computer program) for executing the aforementioned host card-based interaction method, thereby solving the technical problem of how to improve the security and efficiency of NFC transaction processing. Compared with the prior art, the beneficial effects of the computer-readable storage medium provided in this application are the same as those of the host card-based interaction method provided in the above embodiments, and will not be repeated here.

[0097] The above description is only a part of the embodiments of this application and does not limit the patent scope of this application. All equivalent structural transformations made under the technical concept of this application and using the contents of the specification and drawings of this application, or direct / indirect applications in other related technical fields, are included in the patent protection scope of this application.

Claims

1. An interaction method based on a host card, characterized in that, Applied to a mobile terminal, the mobile terminal includes an NFC module, a VSE container, and a key storage module. The VSE container includes at least one card application component and a white-box component. The interaction method based on the host card includes: In response to an execution command sent by an external read / write device, the application identifier in the execution command is obtained; The execution instruction is sent to the target card application corresponding to the application identifier, and the target card application generates a service key acquisition request based on the execution instruction; Determine the terminal leaf certificate in the business key acquisition request, and the traffic domain signature, payment domain signature, and device domain signature in the terminal leaf certificate; Based on the preset public key, the traffic domain signature, the payment domain signature, and the device domain signature are verified respectively to obtain the total number of valid signatures; A trust threshold is determined based on the current business type. When the total number of valid signatures is greater than or equal to the trust threshold, the business key acquisition request is determined to have passed verification. The key storage module decrypts the pre-stored encrypted business key based on the business key acquisition request to obtain the business key, which is in white-box key form. In the white-box component, the transaction data is encrypted based on the business key to obtain secure transaction result data; The secure transaction result data is encapsulated into a response command, and the response command is sent to the external read / write device; The business key is a transportation business key. The steps by which the key storage module decrypts the pre-stored encrypted business key based on the business key acquisition request to obtain the business key include: When the key storage module receives the service key acquisition request sent by the target card application, it acquires the key identifier and service scenario tag in the service key acquisition request; The key identifier and business scenario tag are used as indexes to match with a preset key library to obtain the encrypted traffic business key; The encrypted traffic service key is decrypted using a symmetric encryption algorithm to obtain the traffic service key, which includes an authentication subkey and a toll deduction subkey.

2. The host card-based interaction method as described in claim 1, characterized in that, Before the step of sending the execution instruction to the target card application corresponding to the application identifier, and the target card application generating a service key acquisition request based on the execution instruction, the host card-based interaction method further includes: The execution instructions are parsed to obtain the instruction code and the application identifier; When the instruction code is an application selection instruction, the application identifier is matched with a preset card application mapping table; The card application that has a mapping relationship with the application identifier is identified as the target card application.

3. The host card-based interaction method as described in claim 1, characterized in that, The step of encrypting transaction data based on the business key in the white-box component to obtain secure transaction result data includes: When the white-box component receives the deduction operation subkey, it encrypts the transaction data based on the symmetric encryption algorithm, and sends the encrypted transaction ciphertext and verification code to the transportation card application. The transportation card application assembles the encrypted transaction ciphertext, the verification code, and the current balance to obtain the secure transaction result data.

4. The host card-based interaction method as described in claim 1, characterized in that, The step of determining the trust threshold based on the current business type includes: Obtain the traffic domain signature, the payment domain signature, and the domain type code, domain trust level, and signature issuance timestamp corresponding to the device domain, as well as the scenario business type code, minimum transaction access trust level, and legal transaction time range in the session data; The field type code is compared with the preset standard business type code. If there is a discrepancy, the field type verification is determined to be abnormal. The trust level is compared with the minimum access trust level for the transaction. If any business trust level is lower than the minimum access trust level for the transaction, it is determined to be an unauthorized access by a low-level domain. If the signature issuance timestamp is not within the valid time range of the transaction, the time window verification is deemed abnormal.

5. The host card-based interaction method as described in claim 1, characterized in that, Prior to the step of obtaining the application identifier in the execution instruction sent by the external read / write device, the host card-based interaction method further includes: Obtain the business key sent by the server, encrypt the business key based on a symmetric encryption algorithm, and obtain the encrypted business key; The encrypted business key is stored in the key storage module of the mobile terminal.

6. An interaction method based on a host card, characterized in that, The host card-based interaction method, applied to external read / write devices, includes: In response to a response command sent by a mobile terminal, the encrypted transaction data in the response command is obtained; The encrypted transaction data is matched with preset access rules. If the access rules are met, the card swipe transaction is determined to be legal and valid.

7. An interactive device based on a host card, characterized in that, The device includes: a memory, a processor, and a computer program stored in the memory and executable on the processor, the computer program being configured to implement the steps of the host card-based interaction method as described in any one of claims 1 to 6.

8. A storage medium, characterized in that, The storage medium is a computer-readable storage medium, on which a computer program is stored, and when the computer program is executed by a processor, it implements the steps of the host card-based interaction method as described in any one of claims 1 to 6.

Images