Card management method and equipment based on virtual SE

Abstract

The invention relates to the technical field of communication, in particular to a card management method and equipment based on a virtual SE, and the method comprises the steps: responding to an equipment certificate application of a VSE client in user equipment, generating and returning an equipment certificate to the VSE client based on an SE end private key; in response to a card service application of the VSE client, performing security encryption verification and operation based on the VSE client key pair, the bidirectional certificate verification and the challenge encryption verification to complete corresponding services; the bidirectional certificate verification comprises that the VSE client verifies an SE end certificate or an SP end certificate of the server, and the server verifies an equipment certificate or a card certificate of the VSE client; and the challenge encryption verification is to generate data encryption information and message encryption information based on the randomly generated challenge information so as to perform service data transmission. Therefore, the function of the device without the SE chip can be realized with low cost and high safety.

Description

Technical Field

[0001] This invention relates to the field of communication technology, and more specifically to a card management method and device based on a virtual SE. Background Technology

[0002] With the widespread adoption of mobile payment and near-field communication (NFC) technologies, integrating virtual transportation cards, access control cards, and other applications into smartphones and other mobile terminals has become an important way to enhance user experience. These applications typically rely on a built-in Secure Element (SE) to store keys, perform secure operations, and protect transaction data.

[0003] Currently, there are two main technical approaches to implementing mobile terminal card emulation: one is based on hardware secure elements, and the other is based on host card emulation. The hardware secure element approach offers high security, meeting the requirements of high-security applications such as finance and transportation. However, this approach requires a dedicated security chip in the terminal, increasing hardware costs and limiting its adoption in some low-to-mid-range models. The host card emulation approach, on the other hand, simulates the card by running software within the terminal's main operating system, eliminating the need for dedicated security hardware and resulting in lower costs. However, the security of this approach relies entirely on the terminal's operating system software environment, making its security level far lower than that of hardware secure elements. It struggles to guarantee the security of sensitive data and transaction processes, and typically fails to meet the security standards for business scenarios involving funds and critical authorizations.

[0004] Therefore, there is a clear contradiction in the existing technology: low-cost solutions lack security, while secure solutions are expensive. There is an urgent need for a card emulation and management solution that can achieve a security level close to that of hardware security elements on mobile terminals without dedicated security hardware, so as to achieve an effective balance between cost and security. Summary of the Invention

[0005] In view of this, the purpose of the present invention is to provide a card management method and device based on virtual SE, so as to overcome the problem of not being able to effectively balance security and cost when integrating virtual cards on mobile terminals such as smartphones.

[0006] To achieve the above objectives, the present invention adopts the following technical solution: Firstly, this application provides a card management method based on a virtual SE, comprising: In response to a device certificate request from a VSE client in a user device, a device certificate is generated based on the SE's private key and returned to the VSE client. In response to the card service application from the VSE client, secure encryption verification and operation of business data are performed based on the VSE client key pair, two-way certificate verification, and challenge encryption verification to complete the business corresponding to the card service application; The services mentioned include at least one of card opening, card transfer, card deletion, card transfer out, and top-up; The two-way certificate verification includes the VSE client verifying the SE certificate or SP certificate of the server, and the server verifying the device certificate or card certificate of the VSE client. The card certificate is a certificate generated by the server and returned to the VSE client after the VSE client initiates a card activation application to the server. Both the SE certificate and the SP certificate are certified by a certificate authority. The challenge encryption verification involves generating data encryption information and message encryption information based on randomly generated challenge information, encrypting business data based on the data encryption information, and generating message verification information based on the message encryption information for business data transmission.

[0007] Furthermore, in some embodiments of this application, the step of generating and returning a device certificate to the VSE client in response to a device certificate request from a VSE client in a user equipment includes: Receive the device certificate application from the VSE client; Extract the device certificate application file from the device certificate application, the device certificate application file including device ID information; A device certificate is generated using the SE's private key based on the device certificate application file. Send the device certificate to the VSE client.

[0008] Furthermore, in some embodiments of this application, for card activation, deletion, transfer out, and renewal services, the response to the card service application from the VSE client, based on the VSE client key pair, two-way certificate verification, and challenge encryption verification, performs secure encryption verification and operates the service data, including: Receive card service applications, including device certificates or card certificates, from VSE clients, and verify the device certificates or card certificates; Randomly generate server challenge information and encrypt it using the VSE client public key or card public key to generate server encrypted challenge information. Then send the server encrypted challenge information and the SE certificate or SP certificate to the VSE client. For VSE clients: The SE or SP certificate is verified based on the Certificate Authority's public key. The server challenge information is obtained by decrypting the server's encrypted challenge information using the VSE client's private key or the card's public key. Randomly generate client challenge information; Perform hash calculations on time information, device ID information, server challenge information, and client challenge information; Data encryption information and message encryption information are generated based on the hash calculation results; The client's challenge information and time information are encrypted using the SE's public key to obtain the encrypted result of the client's first message; The card application data or card data is encrypted using data encryption information to obtain the client-side encrypted result; the client-side encrypted result is then digested using a hash algorithm and encrypted using message encryption information to obtain the client-side second message encrypted result; The client encrypted message result, the client first message encrypted result, and the client second message encrypted result are then sent to the server.

[0009] Furthermore, in some embodiments of this application, for card activation, deletion, transfer out, and renewal services, the step of responding to the card service application from the VSE client by performing secure encryption verification and operation of service data based on device-side key pairs, two-way certificate verification, and challenge encryption verification further includes: The client's first message encryption result is verified using the device's public key or the SP's private key to obtain the client's challenge information and time information; Verify the time information; Perform hash calculations on time information, device ID information, server challenge information, and client challenge information; Data encryption information and message encryption information are generated based on the hash calculation results; The client's first message encryption result is verified using message encryption information, and the client's ciphertext encryption result is decrypted using data encryption information to obtain card application data or card data. Business operations are conducted based on card application data or card data; For card activation and recharge transactions, the operation results are encrypted using data encryption information to obtain a server-side encrypted result. A hash algorithm is used to calculate a digest of the server-side encrypted result, and a server-side encrypted message result is generated based on the message encryption information. The server-side encrypted result and the server-side encrypted message result are then sent to the VSE client for verification and decryption before synchronizing the information data. Alternatively, for card deletion and transfer transactions, the card deletion string is encrypted using message encryption information to obtain an encrypted card deletion identifier, which is then sent to the VSE client for verification and decryption before deleting the card data.

[0010] Furthermore, in some embodiments of this application, for card deletion, transfer-out, and update services, the step of responding to the card service application of the VSE client by performing secure encryption verification and operation of service data based on the VSE client key pair, two-way certificate verification, and challenge encryption verification further includes: Based on the feedback information after synchronizing the information data with the VSE client, the operation status is recorded and the operation status information is sent to the VSE client.

[0011] Furthermore, in some embodiments of this application, for migration-in services, the step of responding to the card service application of the VSE client by performing secure encryption verification and operating service data based on the VSE client key pair, two-way certificate verification, and challenge encryption verification includes: Receive card service applications, including device certificates or card certificates, from VSE clients, and verify the device certificates or card certificates; Randomly generate server challenge information, encrypt it using the card public key to generate encrypted server challenge information, and send the encrypted server challenge information and SE certificate or SP certificate to the VSE client; For VSE clients: The SE or SP certificate is verified based on the Certificate Authority's public key. The server challenge information is obtained by decrypting the encrypted challenge information using the card's public key. Randomly generate client challenge information; Perform hash calculations on time information, device ID information, server challenge information, and client challenge information; Data encryption information and message encryption information are generated based on the hash calculation results; The client's challenge information and time information are encrypted using the SE's public key to obtain the encrypted result of the client's first message, and then the encrypted result of the client's first message is sent to the server.

[0012] Furthermore, in some embodiments of this application, for migration-in services, the step of responding to the card service application of the VSE client, and performing secure encryption verification and operation of service data based on the VSE client key pair, two-way certificate verification, and challenge encryption verification, further includes: The client's first message encryption result is verified using the device's public key or the SP's private key to obtain the client's challenge information and time information; Verify the time information; Perform hash calculations on time information, device ID information, server challenge information, and client challenge information; Data encryption information and message encryption information are generated based on the hash calculation results; Generate card data; The card data is encrypted using data encryption information to obtain a server-side ciphertext encryption result. A digest is calculated from the server-side ciphertext encryption result using a hash algorithm, and a server-side message encryption result is generated based on the message encryption information and recorded as a first questionable state. The server-side ciphertext encryption result and the server-side message encryption result are then sent to the VSE client for verification and decryption before synchronizing the information data.

[0013] Furthermore, this application also provides a card management device based on a virtual SE, including a processor and a memory, wherein the processor is connected to the memory: The processor is used to call and execute the program stored in the memory; The memory is used to store the program, which is at least used to execute the card management method based on the virtual SE described above.

[0014] Compared with the prior art, the technical solution provided by the present invention can achieve the following significant beneficial effects: 1. Low cost and high security: On mobile terminals without dedicated security hardware, secure encryption verification and operation of business data are carried out through VSE client key pairs, two-way certificate verification and challenge encryption verification, thereby building a software virtual security environment. This achieves a security level close to that of hardware security elements and significantly reduces the equipment cost threshold.

[0015] 2. Trusted Identity Authentication: A multi-layered certificate system is used to establish verifiable digital identities for devices and each virtual card, building a complete software trust chain and ensuring the legitimacy and trustworthiness of the participants' identities.

[0016] 3. End-to-end secure communication: Based on two-way authentication and challenge encryption verification, it provides a secure channel with confidentiality, integrity and freshness for all card management operations, effectively defending against network attacks.

[0017] 4. Enhanced user experience: Supports secure and convenient full lifecycle management of virtual cards, including activation, use, migration (including migration in and out) and updates, across a wider range of devices, improving business flexibility and user convenience. Attached Figure Description

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

[0019] Figure 1This is a flowchart illustrating the card management method based on a virtual SE provided in an embodiment of the present invention; Figure 2 This is a schematic diagram of the card opening process in the card management method based on virtual SE provided in the embodiments of the present invention; Figure 3 This is a schematic diagram of the migration process in the card management method based on virtual SE provided in this embodiment of the invention; Figure 4 This is a schematic diagram of the card deletion and transfer process in the card management method based on virtual SE provided in this embodiment of the invention; Figure 5 This is a schematic diagram of the recharge process in the card management method based on virtual SE provided in an embodiment of the present invention; Figure 6 This is a schematic diagram of the structure of a card management device based on a virtual SE provided in an embodiment of the present invention. Detailed Implementation

[0020] To make the objectives, technical solutions, and advantages of this invention clearer, the technical solutions of this invention will be described in detail below. Obviously, the described embodiments are merely some embodiments of this invention, and not all embodiments. Based on the embodiments of this invention, all other implementation methods obtained by those skilled in the art without creative effort are within the scope of protection of this invention.

[0021] Figure 1 This is a flowchart illustrating the card management method based on a virtual SE provided in an embodiment of the present invention. Please refer to [link / reference]. Figure 1 This embodiment may include the following steps: S101. In response to the device certificate request from the VSE client in the user equipment, generate and return the device certificate to the VSE client based on the SE's private key.

[0022] It should be noted that the method provided in this application is applied to devices such as mobile phones that do not have an SE chip installed but have NFC or other near-field communication chips installed, in order to enable normal activation and use of smart cards for public transportation. It is understandable that in the initial VSE client (i.e., virtual SE client) service, data transmission is not secure, therefore initialization is required; this step constitutes the VSE initialization part.

[0023] Specifically, the server-side certificates are completed offline before the business begins. The participating servers include SE (SE certificate issuer) certificates and SP (SP service provider) certificates, both of which are issued separately by CA (Certificate Authority) private keys.

[0024] Based on this, the VSE client generates a VSE client key pair, such as an RSA2048 key pair, including a VSE client public key (VSE Public Key) and a VSE client private key (VSE Private Key); the VSE client also generates device ID information (DeviceID) and a device certificate request file (CM_CSR), and populates the DeviceID into its Subject field; then the VSE client sends the VSE_CSR file to the server to request the server to sign it.

[0025] Correspondingly, the server receives the device certificate request from the VSE client, extracts the device certificate request file from the request, generates a VSE Certificate based on the device certificate request file using the SE's private key, and sends it to the VSE client for storage. It's understandable that the VSE Certificate corresponds to either the user settings or the VSE client, and is only issued by the SE when the virtual card is first activated on the VSE client. The card certificate, or Applet Certificate, mentioned later, is issued each time a virtual card is activated.

[0026] It should be noted that the aforementioned VSE client is set on the user's device, such as a mobile phone, and is responsible for the management of the entire SE, including the creation of internal SE applications, certificate issuance, and SE device management. It is provided by the server vendor (in some embodiments, there may be specific hardware) and is installed on the user's mobile device when using services such as wallet and public transportation.

[0027] S102. In response to the card service application from the VSE client, perform secure encryption verification and operation of business data based on the VSE client key pair, two-way certificate verification, and challenge encryption verification to complete the business corresponding to the card service application.

[0028] The services include at least one of the following: card issuance, card transfer, card deletion, card transfer out, and top-up.

[0029] Two-way certificate verification includes the VSE client verifying the SE certificate or SP certificate on the server side, and the server verifying the device certificate or card certificate on the VSE client side. The card certificate is generated by the server and returned to the VSE client after the VSE client initiates a card activation request to the server. Both the SE certificate and the SP certificate are certified by a certificate authority.

[0030] The challenge encryption verification generates data encryption information and message encryption information based on randomly generated challenge information, encrypts business data based on the data encryption information, and generates message verification information based on the message encryption information for business data transmission.

[0031] In practical applications, the mobile terminal and the server ensure the security of data transmission during communication by issuing root certificates. During each business interaction, the mobile phone manufacturer and the server carry certificate authentication information and data encryption verification to complete the functions of card opening, recharge, migration out, migration in and card deletion.

[0032] The card management method based on Virtual SE provided in this application uses VSE client key pairs, two-way certificate verification, and challenge encryption verification to perform secure encryption verification and operation of business data, so as to realize data interaction between VSE client and server, thereby completing card business, achieving low cost, high security, trusted identity authentication, end-to-end secure communication, and improved user experience.

[0033] Furthermore, in some embodiments of this application, for card issuance, deletion, transfer out, and renewal services, the aforementioned response to the card service application in response to the virtual SE client involves secure encryption verification and operation of service data based on the virtual SE client key pair, two-way certificate verification, and challenge encryption verification, including: First, the server side: receives the card service application, including the device certificate or card certificate, sent by the virtual SE client, and verifies the device certificate or card certificate; randomly generates server challenge information, encrypts it using the virtual SE client's public key to generate server encryption challenge information, and sends the server encryption challenge information and the SE certificate or SP certificate to the virtual SE client; Then, the virtual SE client: verifies the SE certificate or SP certificate based on the certificate authority's public key; decrypts the server's encrypted challenge information using the virtual SE client's private key to obtain the server challenge information; randomly generates client challenge information; performs hash calculations on the time information, device ID information, server challenge information, and client challenge information; generates data encryption information and message encryption information based on the hash calculation results; encrypts the client challenge information and time information using the SE's public key to obtain the client's first message encryption result; encrypts the card application data or card data using the data encryption information to obtain the client's ciphertext encryption result; calculates a digest of the client's ciphertext encryption result using a hash algorithm, and encrypts it using the message encryption information to obtain the client's second message encryption result; and sends the client's ciphertext encryption result, the client's first message encryption result, and the client's second message encryption result to the server.

[0034] Correspondingly, on the server side: the device public key or SP private key is used to verify the client's first message encryption result to obtain client challenge information and time information; the time information is verified; a hash calculation is performed on the time information, device ID information, server challenge information, and client challenge information; data encryption information and message encryption information are generated based on the hash calculation result; the message encryption information is used to verify the client's first message encryption result, and the data encryption information is used to decrypt the client's ciphertext encryption result to obtain card application data or card data; business operations are performed based on the card application data or card data; for card opening and recharge businesses, the data encryption information is used to encrypt the operation result to obtain the server-side ciphertext encryption result, a digest is calculated using a hash algorithm on the server-side ciphertext encryption result, and a server-side message encryption result is generated based on the message encryption information; the server-side ciphertext encryption result and the server-side message encryption result are sent to the virtual SE client for verification, decryption, and data synchronization; or for deletion and migration businesses, the message encryption information is used to encrypt the deleted card string to obtain an encrypted deletion identifier, and the encrypted deletion identifier is sent to the virtual SE client for verification, decryption, and card data deletion.

[0035] The following sections provide detailed explanations of specific implementation examples for various business scenarios. Firstly, regarding SIM card activation and migration, for mobile phones, the VSE client can request SIM card data from the server (in this application, "server" and "server-side" refer directly to the VSE client's server and server-side server, respectively). The server generates JSON-formatted SIM card data, encrypts it, and sends it to the mobile phone manufacturer. The mobile phone manufacturer then transmits the SIM card data to the VSE client, which embeds it into the virtual SE's applet, i.e., the SIM card. During migration, the server needs to read the SIM card data from the VSE client, convert it to the server's JSON format, and then transmit the final migration data to the mobile phone manufacturer. The SIM card data undergoes a series of encryption processes during transmission.

[0036] Figure 2 This is a schematic diagram of the card opening process in the card management method based on virtual SE provided in this embodiment of the invention, as shown below. Figure 2 As shown, regarding the card activation service: Before the business is carried out, the client already has: CA public key, SE public key, SE private key, and SE certificate; and the server already has: VSE client private key, VSE private key, VSEC certificate, SP public key, SP private key, and SP certificate.

[0037] Based on this, the specific interactions and operation processes for each terminal are as follows: Interactive part: 1. The VSE client sends a VSE Certification to the server to apply for the activation of the virtual card, which means the card is activated.

[0038] At this time, the server-side operation is as follows: 1. Verify the VSEC Certificate and read the DeviceelD and VSE Public Key; 2. Generate a 16-byte random number Challenge_Server (i.e., server challenge information), and encrypt Challenge_Server using VSE PublicKey to obtain Challenge_Server_Encrypted (i.e., server encrypted challenge information).

[0039] Interaction section: 2. The server returns Challenge_Server_Encrypted and SElCertificate to the VSE client.

[0040] At this point, the VSE client will perform the following actions: 1. Verify the SEI Certificate using the CA Public Key and extract the SEI Public Key; 2. Use the VSE Private Key to decrypt Challenge_Server_Encrypted to obtain Challenge_Server; 3. Generate a 16-byte random number Challenge_Media (i.e., client challenge information); 4. Take the current time date_time, and calculate the SHA256 of (date_time + DeviceelD + Challenge_Server + Challenge_Media); 5. Take the first 16 bytes as the AES key SessionKeyEnc (i.e., data encryption information), and take the last 16 bytes as the AES key SessionKeyMac (i.e., message encryption information). 6. Use the SEl Public Key to encrypt Challenge_Media+date_time to obtain EncryptedMediaData (i.e., the encrypted result of the first message from the client); 7. Generate Applet CSR (i.e., card application data), encrypt the Applet CSR using SessionKeyEnc to obtain EncryptedAppletCSR (i.e., client-side encrypted result), then use SHA256 to calculate the digest of EncryptedAppletCSR, and use SessionKeyMac to calculate CMac_EncryptedAppletCSR (i.e., client-side second message encrypted result) on the digest. Interaction section: 3. The VSE client sends EncryptedMediaData, EncryptedAppletCSR, and CMac_EncryptedAppletCSR to the server.

[0041] At this time, the server is operating as follows: 1. Use the SE1 Private Key to decrypt EncryptedMediaData to obtain Challenge_Media and date_time; 2. Ensure that the difference between date_time and the current system time does not exceed 5 minutes; 3. Calculate the SHA256 hash of (date_time + DeviceID + Challenge_Server + Challenge_Media); 4. Take the first 16 bytes as the AES key SessionKeyEnc, and take the last 16 bytes as the AES key SessionKeyMac. 5. Use SessionKeyMac to verify CMac_EncryptedAppletCSR, and use SessionKeyEnc to decrypt EncryptedAppletCSR to obtain the Applet CSR; 6. Use the SP Private Key to issue an Applet CSR and obtain an Applet Certificate (i.e., the result of the operation, which is also the card certificate). 7. Encrypt the Applet Certificate using SessionKeyEnc to obtain EncryptedAppletCert (i.e., the server-side encrypted result), then use SHA256 to calculate the digest of EncryptedAppletCert, and use SessionKeyMac to calculate CMac_EncryptedAppletCert (i.e., the server-side message encrypted result) from the digest.

[0042] Interaction section: 4. The server returns EncryptedAppletCert and CMac_EncryptedAppletCer to VSE.

[0043] At this point, the ASE client will perform the following actions: 1. Use SessionKeyMac to verify EncryptedAppletCert and CMac_EncryptedAppletCert, and use SessionKeyEnc to decrypt and obtain the Applet Certificate; 2. Store the Applet Certificate.

[0044] Figure 3 This is a schematic diagram of the migration process in the card management method based on virtual SE provided in this embodiment of the invention, as shown below. Figure 3 As shown, the migration service operates on the same principle as other services in this article, but the specific operational process differs. It involves initially sending only the encrypted result of the first message to the client, and then proceeding with subsequent operations after receiving feedback from the server. Specifically, for the migration service, the specific interactions and operational processes for each terminal are as follows: Interaction section: 1. The VSE client sends the Applet Certificate request download card data to the server.

[0045] At this time, the server operates as follows: 1. Verify the Applet Certificate and read the Device ID and Applet Public Key (generated by the VSE client). 2. Generate a 16-byte random number Challenge_Server, and encrypt Challenge_Server using the Applet Public Key to obtain Challenge_Server_Encrypted.

[0046] Interaction section: 2. The server returns Challenge Encrypted and SPCertificate to the VSE client; At this point, the VSE client will perform the following actions: 1. Verify the SP Certificate using the CA Public Key and extract the SP Public Key; 2. Use the Applet Private Key (generated by the VSE client) to decrypt Challenge_Server_Encrypted to obtain Challenge_Server; 3. Generate a 16-byte random number, Challenge_Media; 4. Take the current time date_time, and calculate SHA256 for (date_time + DeviceelD + Challenge_Server + Challenge_Media); 5. Take the first 16 bytes as the AES key SessionKeyEnc, and take the last 16 bytes as the AES key SessionKeyMac; 6. Use the SP Public Key to encrypt Challenge_Media and date_time to obtain EncryptedMediaData.

[0047] Interaction section: 3. The VSE client sends EncryptedMediaData to the server.

[0048] At this point, the server performs the following operations: 1. Decrypts EncryptedMediaData using the SP Private Key to obtain Challenge_Media and date_time; 2. Ensure that the difference between date_time and the current system time does not exceed 5 minutes; 3. Calculate the SHA256 hash of (date_time + DeviceID + Challenge_Server + Challenge_Media); 4. Take the first 16 bytes as the AES key SessionKeyEnc, and take the last 16 bytes as the AES key SessionKeyMac; 5. Generate card data; 6. Use SessionKeyEnc to encrypt the card data to obtain EncryptedCardData. Then, use SHA256 to calculate the digest of EncryptedCardData. Use SessionKeyMac to calculate CMac_EncryptedCardData from the digest. At the same time, change the server-side settings to "card opening questionable".

[0049] Interaction section: 4. The server returns EncryptedCardData and CMac_EncryptedCardData to the VSE client.

[0050] At this point, the VSE client will perform the following actions: 1. Use SessionKeyMac to verify EncryptedCardData and CMac_EncryptedCardDat, and use SessionKeyEnc to decrypt and obtain the card data; 2. Perform SHA256 calculation on the card data to obtain CardDataDigest; 3. Calculate CMac_PlainData using SessionKeyMac on CardDataDigest; 4. Memory card data Interaction section: 5. The VSE client sends Cmac_PlainData to the server.

[0051] At this time, the server is operating as follows: 1. Verify Cmac_PlainData; 2. Issue an enable command (the server-side enable is questionable); Interactive section: 6. The server returns a card status update to enable instruction to the VSE.

[0052] Interactive section: 7. VSE uploads the latest card status to the server.

[0053] At this time, the server is operating as follows: 1. The obtained card status is Normal; 2. The server-side configuration was successfully enabled.

[0054] Interactive section: 8. The server returns EOF to VSE.

[0055] Furthermore, when a user performs a card deletion / transfer transaction in their mobile wallet, the interaction with the server also requires the certificate generated by the VSE client to complete the transaction. Both card deletion and transfer require backing up the card data read from the VSE client by the server, and the server updates the card status to indicate successful deletion / transfer. Figure 4 This is a schematic diagram of the card deletion and transfer process in the card management method based on virtual SE provided in this embodiment of the invention, as shown below. Figure 4 As shown, this applies to card deletion and transfer services: Before the business is conducted, the client already has: CA Public Key, VSE Public Key, VSE Private Key, and VSE Certificate; the server already has: SP Public Key, SP Private Key, and SPC Certificate.

[0056] Based on this, the specific interactions and operation processes for each terminal are as follows: Interactive part: 1. The VSE client sends an AppletCertificate to the server to request the deletion or backup (i.e., migration) of the virtual card.

[0057] At this time, the server is operating as follows: 1. Verify the Applet Certificate and read the Device ID and Applet Public Key; 2. Generate a 16-byte random number Challenge_Server, and use the Applet Public Key to... Challenge_Server encryption results in Challenge_Server_Encrypted.

[0058] Interaction section: 2. The server returns Challenge_Server_Encrypted and SPCertificate to the VSE client.

[0059] At this point, the VSE client will perform the following actions: 1. Verify the SP Certificate using the CA Public Key and extract the SP Public Key. 2. Use the Applet Private Key to decrypt Challenge_Server_Encrypted to obtain Challenge_Server; 3. Generate a 16-byte random number, Challenge_Media; 4. Take the current time date_time, and calculate SHA256 for (date_time + DeviceelD + Challenge_Server + Challenge_Media); 5. Take the first 16 bytes as the AES key SessionKeyEnc, and take the last 16 bytes as the AES key SessionKeyMac; 6. Use the SP Public Key to encrypt Challenge_Media+date_time to obtain EncryptedMediaData; 7. Use SessionKeyEnc to encrypt the card data to obtain EncryptedCardData, then use SHA256 to calculate the digest of EncryptedCardData, and use SessionKeyMac to calculate CMac_EncryptedCardData from the digest.

[0060] Interaction section: 3. The VSE client sends EncryptedMediaData and CMac_EncryptedCardDat to the server.

[0061] At this time, the server is operating as follows: 1. Use the SP Private Key to decrypt EncryptedMediaData to obtain Challenge_Media and date_time; 2. Ensure that the difference between date_time and the current system time does not exceed 5 minutes; 3. Calculate the SHA256 hash of (date_timetDeviceID + Challenge_Server + Challenge_Media); 4. Take the first 16 bytes of the above calculation result as the AES key SessionKeyEnc, and take the last 16 bytes as the AES key SessionKeyMac; 5. Use SessionKeyMac to verify the card data and use SessionKeyEnc to decrypt the card data to obtain the plaintext card data; 6. Calculate the Mac for the string "DELETE-CARD" using SessionKeyMac to obtain Delete_Authorization.

[0062] Interaction section: 4. The server returns Delete_Authorization to the VSE client.

[0063] At this point, the VSE client will perform the following actions: 1. Use SessionKeyMac to verify Delete_Authorization; 2. After successful verification, clear the card data.

[0064] Interactive section: 5. The VSE client notifies the server that the card data has been deleted.

[0065] At this time, the server is operating as follows: 1. The record indicates that the card has been deleted.

[0066] Interactive section: 6. The server returns a message to the VSE client indicating that the card deletion was successful.

[0067] Furthermore, when users make top-up transactions in their mobile wallets, they also need to use the certificate generated by the VSE client to complete the transaction when interacting with the server. Figure 5 This is a flowchart illustrating the recharge process in the card management method based on a virtual SE provided in this embodiment of the invention, specifically for the update process: Before the business is conducted, the client already has: CA Public Key, SP Public Key, SP Private Key and SP Certificate; the server already has: VSE Public Key, VSE Private Key and VSECertificate.

[0068] Based on this, the specific interactions and operation processes for each terminal are as follows: Interaction section: 1. The VSE client sends an AppletCertificate to the server to request updated card data.

[0069] At this time, the server is operating as follows: 1. Verify the Applet Certificate and read the Device ID and Applet Public Key; 2. Generate a 16-byte random number Challenge_Server, and encrypt Challenge_Server using the Applet Public Key to obtain Challenge_Server_Encrypted.

[0070] Interaction section: 2. The server returns Challenge_Server_Encrypted and SPCertificate to the VSE client.

[0071] At this point, the VSE client will perform the following actions: 1. Verify the SP Certificate using the CA Public Key and extract the SP Public Key; 2. Use the Applet Private Key to decrypt Challenge_Server_Encrypted to obtain Challenge_Server; 3. Generate a 16-byte random number, Challenge_Media; 4. Take the current time date_time, and calculate SHA256 for (date_time + DeviceelD + Challenge_Server + Challenge_Media); 5. Take the first 16 bytes as the AES key SessionKeyEnc, and take the last 16 bytes as the AES key SessionKeyMac; 6. Use the Applet Public Key to encrypt Challenge_Media+date_time to obtain EncryptedMediaData; 7. Use SessionKeyEnc to encrypt the card data to obtain EncryptedCardData, then use SHA256 to calculate the digest of EncryptedCardData, and use SessionKeyMac to calculate CMac_EncryptedCardData from the digest.

[0072] Interaction section: 3. The VSE client sends EncryptedMediaData and CMac_EncryptedCardData to the server.

[0073] At this time, the server is operating as follows: 1. Use the SP Private Key to decrypt EncryptedMediaData to obtain Challenge_Media and date_time; 2. Ensure that the difference between date_time and the current system time does not exceed 5 minutes; 3. Calculate the SHA256 hash of (date_time + DeviceelD + Challenge_Server + Challenge_Media); 4. Take the first 16 bytes as the AES key SessionKeyEnc, and take the last 16 bytes as the AES key SessionKeyMac; 5. Use SessionKeyMac to verify the card data and use SessionKeyEnc to decrypt the card data to obtain the plaintext card data; 6. Organize the data to be updated based on the plaintext card data.

[0074] 7. Use SessionKeyEnc to encrypt the data to be updated to obtain EncryptedData, then use SHA256 to calculate the digest of EncryptedData, and use SessionKeyMac to calculate CMac_EncryptedData from the digest.

[0075] Interaction section: 4. The server returns EncryptedData and CMac_EncryptedData to the VSE client.

[0076] At this point, the VSE client will perform the following actions: 1. Use SessionKeyMac to verify EncryptedData and CMac_EncryptedData, and use SessionKeyEnc to decrypt to obtain the data to be updated; 2. Replace the old data with the data from the card to be updated; 3. Perform SHA256 calculation on the new complete card data to obtain CardDataDigest; 4. Use SessionKeyMac to calculate CMac_PlainData on CardDataDigest.

[0077] Interaction section: 5. VSE sends Cmac_PlainData to the server.

[0078] At this time, the server is operating as follows: 1. Verify Cmac_PlainData; Interactive section: 6. The server returns a message to the VSE client indicating that the card data update was successful.

[0079] Understandably, as described in the above process, for the initial card activation, the virtual SE client's public and private keys and the SE certificate can be used for verification. For other services after card activation, the card's public and private keys and the SP certificate can be used for verification.

[0080] Based on the same inventive concept, the present invention also provides a card management device based on a virtual SE for implementing the above method embodiments. Figure 6 This is a schematic diagram of the structure of a card management device based on a virtual SE provided in an embodiment of the present invention, as shown below. Figure 6 As shown, the card management device based on virtual SE in this embodiment includes a processor 11 and a memory 12, with the processor 11 connected to the memory 22. The processor 11 is used to call and execute a program stored in the memory 12; the memory 12 is used to store the program, which is at least used to execute the card management method based on virtual SE in the above embodiments.

[0081] The specific implementation scheme of the card management device based on virtual SE provided in this application can refer to the implementation scheme of the card management method based on virtual SE in any of the above embodiments, and will not be repeated here.

[0082] It is understood that the same or similar parts in the above embodiments can be referred to each other, and the contents not described in detail in some embodiments can be referred to the same or similar contents in other embodiments.

[0083] It should be noted that in the description of this invention, the terms "first," "second," etc., are used for descriptive purposes only and should not be construed as indicating or implying relative importance. Furthermore, in the description of this invention, unless otherwise stated, "a plurality of" means at least two.

[0084] Any process or method description in the flowchart or otherwise herein can be understood as representing a module, segment, or portion of code comprising one or more executable instructions for implementing a particular logical function or process, and the scope of the preferred embodiments of the invention includes additional implementations in which functions may be performed not in the order shown or discussed, including substantially simultaneously or in reverse order depending on the functions involved, as will be understood by those skilled in the art to which embodiments of the invention pertain.

[0085] It should be understood that various parts of the present invention can be implemented in hardware, software, firmware, or a combination thereof. In the above embodiments, multiple steps or methods can be implemented in software or firmware stored in memory and executed by a suitable instruction execution system. For example, if implemented in hardware, as in another embodiment, it can be implemented using any one or a combination of the following techniques known in the art: discrete logic circuits having logic gates for implementing logical functions on data signals, application-specific integrated circuits (ASICs) having suitable combinational logic gates, programmable gate arrays (PGAs), field-programmable gate arrays (FPGAs), etc.

[0086] Those skilled in the art will understand that all or part of the steps of the methods described in the above embodiments can be implemented by a program instructing related hardware. The program can be stored in a computer-readable storage medium, and when executed, it includes one or a combination of the steps of the method embodiments.

[0087] Furthermore, the functional units in the various embodiments of the present invention can be integrated into a processing module, or each unit can exist physically separately, or two or more units can be integrated into a module. The integrated module can be implemented in hardware or as a software functional module. If the integrated module is implemented as a software functional module and sold or used as an independent product, it can also be stored in a computer-readable storage medium.

[0088] The storage media mentioned above can be read-only memory, disk, or optical disk, etc.

[0089] In the description of this specification, references to terms such as "one embodiment," "some embodiments," "example," "specific example," or "some examples," etc., indicate that a specific feature, structure, material, or characteristic described in connection with that embodiment or example is included in at least one embodiment or example of the invention. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples.

[0090] Although embodiments of the present invention have been shown and described above, it is understood that the above embodiments are exemplary and should not be construed as limiting the present invention. Those skilled in the art can make changes, modifications, substitutions and variations to the above embodiments within the scope of the present invention.

Claims

1. A card management method based on a virtual SE, characterized in that, include: In response to a device certificate request from a VSE client in a user device, a device certificate is generated based on the SE's private key and returned to the VSE client. In response to the card service application from the VSE client, secure encryption verification and operation of business data are performed based on the VSE client key pair, two-way certificate verification, and challenge encryption verification to complete the business corresponding to the card service application; The services mentioned include at least one of card opening, card transfer, card deletion, card transfer out, and top-up; The two-way certificate verification includes the VSE client verifying the SE certificate or SP certificate of the server, and the server verifying the device certificate or card certificate of the VSE client. The card certificate is a certificate generated by the server and returned to the VSE client after the VSE client initiates a card activation application to the server. Both the SE certificate and the SP certificate are certified by a certificate authority. The challenge encryption verification involves generating data encryption information and message encryption information based on randomly generated challenge information, encrypting business data based on the data encryption information, and generating message verification information based on the message encryption information for business data transmission.

2. The card management method based on virtual SE according to claim 1, characterized in that, The process of responding to a device certificate request from a VSE client in a user device, generating and returning a device certificate to the VSE client based on the SE's private key, includes: Receive the device certificate application from the VSE client; Extract the device certificate application file from the device certificate application, the device certificate application file including device ID information; A device certificate is generated using the SE's private key based on the device certificate application file. Send the device certificate to the VSE client.

3. The card management method based on virtual SE according to claim 1, characterized in that, For card activation, deletion, transfer, and renewal services, the response to the card service application from the VSE client involves secure encryption verification and operation of service data based on the VSE client key pair, two-way certificate verification, and challenge encryption verification, including: Receive card service applications, including device certificates or card certificates, from VSE clients, and verify the device certificates or card certificates; Randomly generate server challenge information and encrypt it using the VSE client public key or card public key to generate server encrypted challenge information. Then send the server encrypted challenge information and the SE certificate or SP certificate to the VSE client. For VSE clients: The SE or SP certificate is verified based on the Certificate Authority's public key. The server challenge information is obtained by decrypting the server's encrypted challenge information using the VSE client's private key or the card's public key. Randomly generate client challenge information; Perform hash calculations on time information, device ID information, server challenge information, and client challenge information; Data encryption information and message encryption information are generated based on the hash calculation results; The client's challenge information and time information are encrypted using the SE's public key to obtain the encrypted result of the client's first message; The card application data or card data is encrypted using data encryption information to obtain the client-side encrypted result; the client-side encrypted result is then digested using a hash algorithm and encrypted using message encryption information to obtain the client-side second message encrypted result; The client encrypted message result, the client first message encrypted result, and the client second message encrypted result are then sent to the server.

4. The card management method based on virtual SE according to claim 3, characterized in that, For card activation, deletion, transfer, and renewal services, the response to the card service application from the VSE client, based on device-side key pair, two-way certificate verification, and challenge encryption verification, includes secure encryption verification and operation of service data, and further includes: The client's first message encryption result is verified using the device's public key or the SP's private key to obtain the client's challenge information and time information; Verify the time information; Perform hash calculations on time information, device ID information, server challenge information, and client challenge information; Data encryption information and message encryption information are generated based on the hash calculation results; The client's first message encryption result is verified using message encryption information, and the client's ciphertext encryption result is decrypted using data encryption information to obtain card application data or card data. Business operations are conducted based on card application data or card data; For card activation and recharge transactions, the operation results are encrypted using data encryption information to obtain a server-side encrypted result. A hash algorithm is used to calculate a digest of the server-side encrypted result, and a server-side encrypted message result is generated based on the message encryption information. The server-side encrypted result and the server-side encrypted message result are then sent to the VSE client for verification and decryption before synchronizing the information data. Alternatively, for card deletion and transfer transactions, the card deletion string is encrypted using message encryption information to obtain an encrypted card deletion identifier, which is then sent to the VSE client for verification and decryption before deleting the card data.

5. The card management method based on virtual SE according to claim 4, characterized in that, For card deletion, transfer-out, and renewal services, the response to the card service application from the VSE client, which involves secure encryption verification and operation of service data based on the VSE client key pair, two-way certificate verification, and challenge encryption verification, further includes: Based on the feedback information after synchronizing the information data with the VSE client, the operation status is recorded and the operation status information is sent to the VSE client.

6. The card management method based on virtual SE according to claim 2, characterized in that, For inbound services, the response to the card service application from the VSE client, based on the VSE client key pair, two-way certificate verification, and challenge encryption verification, performs secure encryption verification and operates the service data, including: Receive card service applications, including device certificates or card certificates, from VSE clients, and verify the device certificates or card certificates; Randomly generate server challenge information, encrypt it using the card public key to generate encrypted server challenge information, and send the encrypted server challenge information and SE certificate or SP certificate to the VSE client; For VSE clients: The SE or SP certificate is verified based on the Certificate Authority's public key. The server challenge information is obtained by decrypting the encrypted challenge information using the card's private key. Randomly generate client challenge information; Perform hash calculations on time information, device ID information, server challenge information, and client challenge information; Data encryption information and message encryption information are generated based on the hash calculation results; The client's challenge information and time information are encrypted using the SE's public key to obtain the encrypted result of the client's first message, and then the encrypted result of the client's first message is sent to the server.

7. The card management method based on virtual SE according to claim 6, characterized in that, For migration-in services, the process of responding to the card service application from the VSE client, and performing secure encryption verification and operation of service data based on the VSE client key pair, two-way certificate verification, and challenge encryption verification, further includes: The client's first message encryption result is verified using the device's public key or the SP's private key to obtain the client's challenge information and time information; Verify the time information; Perform hash calculations on time information, device ID information, server challenge information, and client challenge information; Data encryption information and message encryption information are generated based on the hash calculation results; Generate card data; The card data is encrypted using data encryption information to obtain a server-side ciphertext encryption result. A digest is calculated from the server-side ciphertext encryption result using a hash algorithm, and a server-side message encryption result is generated based on the message encryption information and recorded as a first questionable state. The server-side ciphertext encryption result and the server-side message encryption result are then sent to the VSE client for verification and decryption before synchronizing the information data.

8. A card management device based on a virtual SE, characterized in that, It includes a processor and a memory, wherein the processor is connected to the memory: The processor is used to call and execute the program stored in the memory; The memory is used to store the program, which is at least used to execute the card management method based on virtual SE as described in any one of claims 1-7.

Images