Abnormity repairing method and device for virtual card, equipment and computer program product

Abstract

The invention discloses a virtual card abnormity repairing method and device, equipment and a computer program product, and the method comprises the steps: obtaining real-time monitoring data of a first virtual card, and determining a real-time monitoring result of the first virtual card based on the real-time monitoring data; creating a second security domain corresponding to the first virtual card under the condition that the real-time monitoring result is that the security domain is in false death and a first security domain corresponding to the first virtual card meets a migration condition; and migrating the access control list and the key index of the first security domain to the second security domain.

Description

Technical Field

[0001] This invention relates to the fields of information security and data processing technology, and in particular to a method, apparatus, device, and computer program product for repairing anomalies in virtual cards. Background Technology

[0002] Near Field Communication (NFC) virtual cards are susceptible to electromagnetic interference, abnormal operation, or malicious attacks during practical applications, which can cause the internal security domain or application of the NFC virtual card to enter an abnormal state (such as locking / freezing), resulting in problems such as card swiping failure, card opening interruption, and migration failure.

[0003] Current common anomaly repair methods have shortcomings such as poor timeliness and inability to resolve the "freezing" problem, which limit the performance of NFC virtual cards. Summary of the Invention

[0004] This application provides a method, apparatus, device, and computer program product for repairing anomalies in virtual cards, which improves the timeliness of repairing abnormal scenarios, effectively solves the problem of apparent freezing, and enhances the performance of NFC virtual cards.

[0005] The technical solution of this application embodiment is implemented as follows:

[0006] In a first aspect, embodiments of this application provide a method for repairing anomalies in a virtual card, the method comprising:

[0007] Obtain real-time monitoring data of the first virtual card, and determine the real-time monitoring result of the first virtual card based on the real-time monitoring data;

[0008] If the real-time monitoring result indicates that the security domain is in a state of suspension, and the first security domain corresponding to the first virtual card meets the migration conditions, then create the second security domain corresponding to the first virtual card.

[0009] Migrate the access control list and key index of the first security domain to the second security domain.

[0010] Secondly, embodiments of this application provide an anomaly repair device for a virtual card, the anomaly repair device for a virtual card comprising:

[0011] The acquisition unit is used to acquire real-time monitoring data of the first virtual card and determine the real-time monitoring result of the first virtual card based on the real-time monitoring data.

[0012] A creation unit is used to create a second security domain corresponding to the first virtual card when the real-time monitoring result indicates that the security domain is in a state of suspension and the first security domain corresponding to the first virtual card meets the migration conditions.

[0013] The migration unit is used to migrate the access control list and key index of the first security domain to the second security domain.

[0014] Thirdly, embodiments of this application provide an electronic device, which includes a processor and a memory storing processor-executable instructions, wherein when the instructions are executed by the processor, the method described in the first aspect is implemented.

[0015] Fourthly, embodiments of this application provide a computer-readable storage medium having a program stored thereon, which, when executed by a processor, implements the method described in the first aspect.

[0016] Fifthly, embodiments of this application provide a computer program product, including a computer program or instructions, which, when executed by a processor, implement the method described in the first aspect.

[0017] This application provides a method, apparatus, device, and computer program product for abnormal repair of virtual cards. It acquires real-time monitoring data of a first virtual card and determines the real-time monitoring result of the first virtual card based on the data. If the real-time monitoring result indicates a security domain freeze, and the first security domain corresponding to the first virtual card meets the migration conditions, a second security domain corresponding to the first virtual card is created. The access control list and key index of the first security domain are migrated to the second security domain. Therefore, in this application, on the one hand, the virtual card status can be automatically determined through real-time monitoring data, avoiding reliance on user feedback and improving the detection efficiency of abnormal scenarios. On the other hand, when a security domain is confirmed to be in a frozen state, a new security domain can be created and the original data and information migrated, rather than being deleted and rebuilt, thereby reducing the anomaly repair time and resource consumption. In other words, this application can realize an automated monitoring and repair closed-loop system for NFC chip security domains and application anomalies, breaking through the limitation of traditional methods that cannot handle frozen states, realizing an automated repair process, and improving the performance of NFC virtual cards. Attached Figure Description

[0018] Figure 1 This is a schematic diagram of the composition structure of the virtual card anomaly repair device proposed in this application embodiment. Figure 1 ;

[0019] Figure 2 This is a schematic diagram of the implementation process of the virtual card anomaly repair method proposed in this application embodiment. Figure 1 ;

[0020] Figure 3 This is a schematic diagram illustrating the implementation of the virtual card anomaly repair proposed in this application embodiment. Figure 1 ;

[0021] Figure 4This is a schematic diagram illustrating the implementation of the virtual card anomaly repair proposed in this application embodiment. Figure 2 ;

[0022] Figure 5 This is a schematic diagram of the implementation process of the virtual card anomaly repair method proposed in this application embodiment. Figure 2 ;

[0023] Figure 6 This is a schematic diagram of the implementation process of the virtual card anomaly repair method proposed in this application embodiment. Figure 3 ;

[0024] Figure 7 This is a schematic diagram illustrating the implementation of the virtual card anomaly repair proposed in this application embodiment. Figure 3 ;

[0025] Figure 8 This is a schematic diagram illustrating the implementation of the virtual card anomaly repair proposed in this application embodiment. Figure 4 ;

[0026] Figure 9 This is a schematic diagram illustrating the implementation of the virtual card anomaly repair proposed in this application embodiment. Figure 5 ;

[0027] Figure 10 This is a schematic diagram of the implementation process of the virtual card anomaly repair method proposed in this application embodiment. Figure 4 ;

[0028] Figure 11 This is a schematic diagram illustrating the implementation of the virtual card anomaly repair proposed in this application embodiment. Figure 6 ;

[0029] Figure 12 This is a schematic diagram illustrating the implementation of the virtual card anomaly repair proposed in this application embodiment. Figure 7 ;

[0030] Figure 13 This is a schematic diagram illustrating the implementation of the virtual card anomaly repair proposed in this application embodiment. Figure 8 ;

[0031] Figure 14 This is a schematic diagram illustrating the implementation of the virtual card anomaly repair proposed in this application embodiment. Figure 9 ;

[0032] Figure 15 This is a schematic diagram illustrating the implementation of the virtual card anomaly repair proposed in this application embodiment. Figure 10 ;

[0033] Figure 16 This is a schematic diagram of the composition structure of the virtual card anomaly repair device proposed in this application embodiment. Figure 2 ;

[0034] Figure 17This is a schematic diagram of the composition structure of the electronic device proposed in the embodiments of this application. Detailed Implementation

[0035] The technical solutions in the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. It is understood that the specific embodiments described herein are only for explaining the differences between the application and the original application, and are not intended to limit the application. Furthermore, it should be noted that, for ease of description, only the parts that differ from the relevant application are shown in the accompanying drawings.

[0036] Near Field Communication (NFC) evolved from contactless Radio Frequency Identification (RFID). It integrates inductive card readers, inductive cards, and peer-to-peer communication functions on a single chip, enabling various types of applications using mobile terminals.

[0037] NFC virtual cards are digital card solutions based on near-field communication technology. They simulate the functions of physical cards via mobile phones or other smart devices. Currently, the NFC industry supports the simulation of various card types, including public transport cards, access cards, car keys, campus cards, electronic identity (eID), UnionPay QuickPass, and digital RMB. Devices can simulate these cards and perform swiping operations.

[0038] In practical applications, NFC virtual cards are prone to electromagnetic interference, abnormal operation, or malicious attacks. Their internal security domain or application (hereinafter referred to as "application") may enter an abnormal state, such as being locked or frozen, resulting in card swiping failure, card opening interruption, migration failure, and other malfunctions.

[0039] Anomaly triggering mechanisms are a key protective measure in the NFC security system, primarily achieving real-time risk interception through hardware and software collaboration. The following are two types of anomaly triggering mechanisms:

[0040] 1. External attack protection mechanism

[0041] When the chip detects abnormal signal interference (such as voltage glitches, clock glitches, or electromagnetic injection), it will immediately trigger the following response:

[0042] Application Lock: Forcefully terminates the current NFC application process, enters an unselectable state, and blocks all normal operations;

[0043] Redundancy calculation verification: By repeatedly calculating and comparing the results, if an inconsistency is detected, it is determined to be a fault injection attack, and circuit breaker protection is activated;

[0044] Physical isolation: The security module (SE) is isolated from the main processor to ensure that attacks cannot spread to sensitive data areas.

[0045] 2. Key authentication circuit breaker mechanism

[0046] Protection against unauthorized access attempts includes:

[0047] Consecutive failures lock the security domain (such as SE or TEE): The security domain will be automatically locked after a preset number of authentication failures (usually 3-5 times). Administrator privileges or hardware reset are required to restore it.

[0048] Dynamic key update: The temporary key becomes invalid after each authentication failure to prevent replay attacks;

[0049] Timing balance design: The encryption operation time is fixed to avoid guessing the key through timing analysis.

[0050] Currently, the handling process for abnormal application status within virtual cards typically follows a three-tiered model: "user feedback, manual diagnosis, and retry handling."

[0051] 1. User feedback: Submit logs (including NFC transaction timestamps, error codes, etc.) through the "Abnormal Reporting" entry in the APP.

[0052] 2. Intelligent Diagnosis: The system automatically compares four-dimensional risk control data (transaction frequency, equipment environment, fund flow, and behavioral changes).

[0053] 3. Handling and execution, for example, using the following two repair methods: remote deletion and reinstallation, and unlocking command. Among them, remote deletion and reinstallation requires the user to reactivate the card, which takes a long time; the unlocking command is only effective for lockouts caused by key authentication failure.

[0054] However, the above-mentioned solutions for handling abnormal situations have the following problems:

[0055] 1. Anomaly detection lacks flexibility and convenience. Problems rely on passive user reporting, resulting in long manual intervention cycles and poor fault recovery timeliness;

[0056] 2. Unable to effectively resolve application freezing issues. If the chip application state changes to a frozen state, the unlock command is ineffective for the frozen state, forcibly requiring deletion and reinstallation;

[0057] 3. Reinstalling applications incurs high costs. On one hand, clearing and reinstalling the security domain and applications requires users to re-activate the card. For some virtual cards, this means paying the activation fee again, which is costly and wasteful from an economic perspective. On the other hand, the application reinstallation process is time-consuming, with some virtual card activation processes taking tens of seconds, thus wasting the user's time.

[0058] It is evident that common virtual card anomaly repair solutions suffer from problems such as high response latency and limited repair methods, making it difficult to meet the needs for rapid identification and repair of virtual card anomalies in complex environments, thus restricting the stability and performance of virtual card systems.

[0059] To address the aforementioned issues, this application provides a method, apparatus, device, and computer program product for abnormal repair of virtual cards. The method involves acquiring real-time monitoring data of a first virtual card and determining the real-time monitoring result based on this data. If the real-time monitoring result indicates a security domain freeze, and the first security domain corresponding to the first virtual card meets the migration conditions, a second security domain corresponding to the first virtual card is created. The access control list and key index of the first security domain are then migrated to the second security domain. Therefore, in this application, on the one hand, the virtual card status can be automatically determined using real-time monitoring data, avoiding reliance on user feedback and improving the detection efficiency of abnormal scenarios. On the other hand, when a security domain is confirmed to be in a frozen state, a new security domain can be created and the existing data and information migrated, rather than being deleted and rebuilt, thereby reducing the repair time and resource consumption. In other words, this application can realize an automated monitoring and repair closed-loop system for NFC chip security domains and application abnormal states, overcoming the limitation of traditional methods in handling frozen states, achieving an automated repair process, and improving the performance of NFC virtual cards.

[0060] The technical solutions in the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings.

[0061] One embodiment of this application provides a method for repairing virtual cards. This method can be applied to virtual card repair devices and / or electronic devices, and can also be applied to any terminal equipped with a virtual card repair device and / or electronic device.

[0062] The following example, using a virtual card anomaly repair device, illustrates the virtual card anomaly repair method proposed in this application.

[0063] Exemplarily, in some embodiments, such as Figure 1 As shown, the virtual card anomaly repair device 10 can be configured with an NFC chip 101. The NFC chip can include one or more virtual cards (smart cards), for example, three virtual cards: a campus card 1011, an access card 1012, and a transportation card 1013. Each virtual card can correspond to a security domain (SD). All related applications of the virtual card, such as installation packages, log files, and permission information files, need to be installed within the corresponding security domain.

[0064] In NFC chips, a security domain is an independently defined, protected area used to store application-specific sensitive data (such as keys and certificates) and perform encryption operations. Each security domain operates independently through hardware isolation (such as an SE chip) or software isolation (such as a TEE), ensuring that data from different virtual cards does not interfere with each other.

[0065] Virtual cards and security domains have a one-to-one mapping mechanism, meaning that each virtual card (such as a transportation card or access card) typically corresponds to an independent security domain used to store the card's unique key and transaction data. For example, campus cards and transportation cards simulated by a mobile phone's NFC occupy different security domains, with funds and permissions completely isolated.

[0066] In the embodiments of this application, Figure 2 This is a schematic diagram of the implementation process of the virtual card anomaly repair method proposed in this application embodiment. Figure 1 ,like Figure 2 As shown, the method for repairing virtual card anomalies may include the following steps:

[0067] Step 201: Obtain the real-time monitoring data of the first virtual card, and determine the real-time monitoring result of the first virtual card based on the real-time monitoring data.

[0068] In the embodiments of this application, the virtual card anomaly repair device can first obtain the real-time monitoring data of the first virtual card, and determine the real-time monitoring result of the first virtual card based on the real-time monitoring data.

[0069] In the embodiments of this application, the virtual card anomaly repair method can be executed by the virtual card anomaly repair device.

[0070] For example, in some embodiments, the virtual card anomaly repair device can be any electronic device capable of configuring virtual cards, including but not limited to NFC terminals, management platform servers, etc. That is, the virtual card-based anomaly repair methods of various embodiments of this application can be executed by an NFC terminal, by a management platform server, or by interaction between an NFC terminal and a management platform server.

[0071] In the embodiments of this application, the virtual card anomaly repair device can continuously monitor the operating status of the first virtual card, thereby enabling rapid identification of possible abnormal scenarios.

[0072] In some embodiments, the first virtual card can be any one or more virtual cards included in the NFC chip configured in the virtual card anomaly repair device. For example, the first virtual card can be such as... Figure 1 One or more of the following: campus card, access card, and transportation card.

[0073] In embodiments of this application, the real-time monitoring data of the first virtual card may include Response Application Protocol Data Unit (APDU) and / or access mode data.

[0074] In the embodiments of this application, when the virtual card anomaly repair device acquires the real-time monitoring data of the first virtual card, it can acquire the response APDU sent by the first virtual card; wherein, the response APDU is used to respond to the command APDU sent to the first virtual card.

[0075] In some embodiments, APDU is a standard data structure in smart card communication, used to exchange command and response information between a host device and an NFC chip. APDU can be divided into two types: Command Application Protocol Data Unit (Response APDU) and Response Application Protocol Data Unit (Command APDU).

[0076] For example, in some embodiments, the response APDU is a data packet returned by the first virtual card to the virtual card's fault repair device, used to provide feedback on the result or status of the command APDU execution. For instance, when the virtual card's fault repair device sends a command to select a security domain, the first virtual card returns a response APDU containing a status code. Status code 6A82 indicates that the specified application was not found, status code 6985 indicates authentication failure, and status code 66A5 may indicate a frozen state.

[0077] In some embodiments, after obtaining the response APDU sent by the first virtual card, the virtual card anomaly repair device can parse the content of the response APDU to obtain the real-time monitoring results of the first virtual card.

[0078] In the embodiments of this application, when the virtual card anomaly repair device obtains the real-time monitoring data of the first virtual card, it can obtain the access mode data corresponding to the first virtual card.

[0079] In some embodiments, access pattern data refers to a set of records formed by access behavior of the first virtual card within a certain time range. Access pattern data may include, but is not limited to, access frequency, access time period, operation type, etc.

[0080] For example, in some embodiments, access pattern data can be collected through methods such as log recording and behavior analysis. After obtaining the access pattern data, it can be used as an important basis for determining whether the first virtual card has encountered abnormal access. For instance, if the access pattern data shows multiple consecutive authentication attempts within a unit of time, it can be identified as an attack characteristic, thereby triggering a risk circuit breaker mechanism.

[0081] Therefore, in the embodiments of this application, real-time status monitoring of the first virtual card can be achieved by acquiring response APDU and / or access mode data, thereby quickly identifying abnormal operations and potential attacks, avoiding the delayed response problem caused by relying on user feedback, so as to take timely repair or defense measures. This can significantly improve the stability and security of the NFC virtual card system, and also improve the timeliness and accuracy of anomaly detection.

[0082] In some embodiments, if potential anomaly risks are identified based on the acquired access pattern data, risk recording may be performed.

[0083] Exemplarily, in some embodiments, such as Figure 3 As shown, the virtual card anomaly repair device can obtain real-time monitoring data, including response APDU and / or access mode data, through chip dynamic behavior monitoring (step 301). If an abnormal scenario is determined based on the response APDU, anomaly repair can be further performed (step 302). If a potential anomaly risk is determined based on the access mode data, risk recording can be further performed (step 303).

[0084] In the embodiments of this application, when determining the real-time monitoring result of the first virtual card based on real-time monitoring data, the virtual card anomaly repair device may first determine the first response status word of the security domain and / or the second response status word of the application based on the response APDU; and then determine the real-time monitoring result of the first virtual card based on the first response status word and / or the second response status word.

[0085] In some embodiments, the final real-time monitoring result refers to the result of a comprehensive evaluation and judgment of the current operating status of the security domain and / or application of the first virtual card based on the status words (first response status word and / or second response status word) obtained by parsing the response APDU.

[0086] In some embodiments, real-time monitoring results may include, but are not limited to, security domain lockout, security domain freeze, application lockout, application freeze, etc.

[0087] In some embodiments, the response APDU acquired by the virtual card's fault repair device includes a status word, which indicates the result status of the current operation. The response APDU may include a first response status word and / or a second response status word. The first response status word can be used to determine the result status of the current operation in the security domain, and the second response status word can be used to determine the result status of the current operation in the application.

[0088] In some embodiments, the response status word (first response status word and / or second response status word) is a key field in the response APDU, used to indicate the status of the application or security domain after processing the request (the result status of the current operation). By parsing these status words, it can be determined whether the security domain or application is in an abnormal state, thereby triggering the corresponding repair mechanism.

[0089] For example, in some embodiments, the virtual card's anomaly repair device can monitor and record the response APDU during each interaction with the NFC chip, and extract the status word (first response status word and / or second response status word) from it. For instance, after the instruction to select a security domain is executed, the response APDU may contain the first response status word of the security domain, which can serve as a basis for determining subsequent anomaly scenarios.

[0090] In the embodiments of this application, when determining the real-time monitoring result of the first virtual card based on the first response status word and / or the second response status word, if the first response status word is either the first status word or the second status word, the real-time monitoring result is determined to be that the security domain is locked; if the first response status word is the third status word, the real-time monitoring result is determined to be that the security domain is frozen; if the second response status word is the first status word, the real-time monitoring result is determined to be that the application is locked; if the second response status word is the third status word, the real-time monitoring result is determined to be that the application is frozen.

[0091] In some embodiments, the first status word can be 6A82, used to indicate that the file was not found. This first status word is returned when attempting to access a non-existent file or application.

[0092] In some embodiments, the second status word can be 6985, used to indicate that the usage conditions are not met. This second status word is returned when security domain authentication fails, for example, due to key verification failure or security conditions (such as PIN code, permissions) not being met.

[0093] In some embodiments, the third status word can be 66A5, used to indicate that the security status is not met. This third status word is returned when the security level of the operation request is lower than the requirements of the file or application, for example, when attempting a sensitive operation without completing authentication.

[0094] For example, in some embodiments, for the first response status word and / or the second response status word contained in the obtained response APDU, the virtual card's anomaly repair device can compare the first response status word and / or the second response status word with the first status word, the second status word, and the third status word, respectively. If the first response status word is the first status word (6A82) or the second status word (6985), then the real-time monitoring result can be determined to be that the security domain is locked; if the first response status word is the third status word (66A5), then the real-time monitoring result can be determined to be that the security domain is frozen; if the second response status word is the first status word (6A82), then the real-time monitoring result can be determined to be that the application is locked; if the second response status word is the third status word (66A5), then the real-time monitoring result can be determined to be that the application is frozen.

[0095] For example, in some embodiments, after the instruction to select a security domain is executed, if the first response status word returned is a first status word, i.e., the returned status word is 6A82, it may indicate that the security domain has not been correctly initialized or has been locked; if the first response status word returned is a second status word, i.e., the returned status word is 6985, it may indicate that the authentication key does not match or the access permission is restricted.

[0096] In the embodiments of this application, the virtual card anomaly repair device extracts the status word based on the response APDU and determines the operating status of the first virtual card according to the result of the operation. This enables the rapid and accurate identification of the abnormal status of the NFC virtual card. Not only can it achieve rapid and accurate identification of the abnormal status of the NFC virtual card, but it also improves the automation level of the system, effectively reduces the need for manual intervention, and improves the efficiency and accuracy of fault handling.

[0097] In the embodiments of this application, when determining the real-time monitoring result of the first virtual card based on the first response status word and / or the second response status word, if the first response status word is the first preset status word and the lifecycle of the security domain is in a locked state, the real-time monitoring result is determined to be that the security domain is locked; wherein, the first preset status word includes a first status word, a second status word, and a third status word; if the first response status word is the first preset status word and the lifecycle of the security domain is in a dead state, the real-time monitoring result is determined to be that the security domain is dead.

[0098] In some embodiments, the first preset status word refers to a specific set of status codes used to represent an abnormal instruction response. For example, the first preset status word may include, but is not limited to, a first status word, a second status word, and a third status word. These three types of status words represent different types of abnormal behaviors, such as access denial, authentication failure, and operation restriction.

[0099] In other words, in the embodiments of this application, the first preset status word usually corresponds to the abnormal response code returned by the NFC chip during the execution of the APDU instruction, such as 6A82 returned by the application selection instruction and 6985 returned by the authentication instruction. The above-mentioned specific status code set is defined as the first preset status word, so that the system can quickly identify potential security domain abnormal events.

[0100] In some embodiments, the lifecycle state of a security domain is used to describe the current functional state of the security domain, including a locked state, a suspended state, etc. For example, when a security domain is in a locked state, the lifecycle state indicates that the security domain has entered an unavailable state due to continuous authentication failures or other protection mechanisms, but can be restored by remote unlocking.

[0101] In some embodiments, a locked state refers to an inoperable state entered due to multiple failed key authentication attempts or other security policy triggers. In a locked state, no further operations can be performed, and recovery cannot be achieved through normal means unless a legitimate unlock command is received. Detecting locked states is crucial for ensuring system security and can effectively prevent unauthorized access and malicious attacks.

[0102] In some embodiments, a "frozen state" refers to a stagnant state entered due to hardware failure or serious software error, characterized by the inability to interact or recover using standard commands. In a frozen state, some data structures may still be retained, but management functionality has been lost.

[0103] In some embodiments, when a security domain is in a locked state, if the first response status word is simultaneously detected to belong to the first preset status word, then it can be determined that the security domain is locked, i.e., the real-time monitoring result is determined to be that the security domain is locked. When a security domain is in a suspended state, if the first response status word is simultaneously detected to belong to the first preset status word, then it can be determined that the security domain is suspended, i.e., the real-time monitoring result is determined to be that the security domain is suspended.

[0104] In other words, in the embodiments of this application, one method for determining real-time monitoring results is to perform anomaly judgment by combining a first preset status word with the lifecycle state. For example, the corresponding anomaly judgment conclusion will only be triggered when both the conditions of the first preset status word and the conditions of the lifecycle state are met simultaneously, which can effectively improve the accuracy of anomaly identification and avoid misjudgments that may be caused by judging a single status word.

[0105] For example, in some embodiments, the virtual card's anomaly repair device can first acquire the first response status word and the security domain lifecycle status, and then determine whether an anomaly exists based on the logical relationship between these two statuses, ultimately outputting the corresponding real-time monitoring results. This ensures that the system can efficiently identify and respond to anomalies with minimal intervention. The order in which the first response status word and the security domain lifecycle status are acquired is not specifically limited in this application.

[0106] In the embodiments of this application, when determining the real-time monitoring result of the first virtual card based on the first response status word and / or the second response status word, if the second response status word is the second preset status word and the application's lifecycle is in a locked state, the real-time monitoring result is determined to be that the application is locked; wherein, the second preset status word includes the first status word and the second status word; if the second response status word is the second preset status word and the application's lifecycle is in a frozen state, the real-time monitoring result is determined to be that the application is frozen.

[0107] In some embodiments, the second preset status word refers to a set of instruction response codes used to represent a specific abnormal state. For example, the second preset status word may include, but is not limited to, the first status word and the second status word. These two types of status words represent different types of abnormal behaviors, such as authentication failure, access restriction, and other scenarios.

[0108] In other words, in the embodiments of this application, the second preset state word set includes multiple specific state words (such as 6A82, 6985, etc.), and the second preset state word is usually associated with the security mechanism inside the chip. For example, the second preset state word includes a first state word (such as 6A82) and a second state word (such as 6985), wherein the first state word and the second state word in the second preset state word set are used to characterize different abnormal situations.

[0109] In some embodiments, if the second response status word is detected to belong to the second preset status word when the application is in a locked state, then the application can be determined to be locked, i.e., the real-time monitoring result is determined to be that the application is locked. If the second response status word is detected to belong to the second preset status word when the application is in a frozen state, then the application can be determined to be frozen, i.e., the real-time monitoring result is determined to be that the security domain is frozen.

[0110] In other words, in the embodiments of this application, one method for determining real-time monitoring results is to perform anomaly judgment by combining a second preset status word with the lifecycle state. For example, the corresponding anomaly judgment conclusion will only be triggered when both the conditions of the second preset status word and the conditions of the lifecycle state are met simultaneously, which can effectively improve the accuracy of anomaly identification and avoid misjudgments that may be caused by judging a single status word.

[0111] For example, in some embodiments, the virtual card's anomaly repair device can first acquire the second response status word and the application lifecycle status, and then determine whether an anomaly exists based on the logical relationship between these two statuses, ultimately outputting the corresponding real-time monitoring result. This ensures that the system can efficiently identify and respond to anomalies with minimal intervention. The order in which the second response status word and the application lifecycle status are acquired is not specifically limited in this application.

[0112] Therefore, in the embodiments of this application, a two-factor authentication mechanism for anomaly diagnosis can be introduced. Detecting an abnormal command response code (such as application selection returning 6A82) is only a necessary but not sufficient condition for an abnormal state. Taking application locking as an example: selecting an application command response of 6A82 does not necessarily mean the application is locked. To eliminate the risk of false positives, a secondary lifecycle state verification can be introduced. By combining the status word with the lifecycle state, intelligent judgment and classification of abnormal states in the security domain are achieved, thereby improving system stability and user experience.

[0113] Exemplarily, in some embodiments, such as Figure 4 As shown, the virtual card anomaly repair device can obtain real-time monitoring data, including response APDU and / or access mode data, through chip dynamic behavior monitoring (step 401). Taking application locking as an example: first, determine whether the application selection instruction responds to 6A82 (step 402). If yes, then further read the security domain lifecycle (step 403). If not, then further determine whether the application selection instruction responds to 66A5 (step 404). If yes, then further read the security domain lifecycle (step 405). If not, then continue chip dynamic behavior monitoring (step 401). Continue to determine whether the security domain lifecycle is locked (step 406), or whether the security domain lifecycle is in a state of suspension (step 407). If the security domain lifecycle is determined to be locked, then the security domain is locked (step 408). If the security domain lifecycle is determined to be in a state of suspension, then the security domain is in a state of suspension (step 409). Otherwise, risk recording can be further performed (step 410).

[0114] Step 202: If the real-time monitoring result indicates that the security domain is in a state of suspension, and the first security domain corresponding to the first virtual card meets the migration conditions, create the second security domain corresponding to the first virtual card.

[0115] Step 203: Migrate the access control list and key index of the first security domain to the second security domain.

[0116] In the embodiments of this application, after obtaining the real-time monitoring data of the first virtual card and determining the real-time monitoring result of the first virtual card based on the real-time monitoring data, if the real-time monitoring result is that the security domain is dead and the first security domain corresponding to the first virtual card meets the migration conditions, then the virtual card anomaly repair device can further create a second security domain corresponding to the first virtual card and migrate the access control list and key index of the first security domain to the second security domain.

[0117] In some embodiments, the first security domain can be understood as the old, currently unresponsive security domain corresponding to the first virtual card; the second security domain can be understood as the newly created security domain corresponding to the first virtual card. The first and second security domains have the same structure.

[0118] In some embodiments, if it is determined that the first security domain of the first virtual card is in a suspended state and the first security domain corresponding to the first virtual card meets the migration conditions, the virtual card's anomaly repair device can create a second security domain with the same structure in the chip space.

[0119] In some embodiments, the newly created second security domain should have access control rules and permission configurations consistent with the original security domain to ensure that the migrated application can continue to operate normally.

[0120] In the embodiments of this application, the virtual card anomaly repair device can first determine the status information of the application in the first security domain; then, if the status information of the application in the first security domain is a preset state, it can determine that the first security domain meets the migration conditions.

[0121] In some embodiments, an application refers to a software module running within a security domain to implement specific functions, such as payment or authentication. Each application has a lifecycle state, such as selectable, locked, or dead.

[0122] In some embodiments, the application's status information describes the current lifecycle state of the application, which is usually identified by the instruction response code returned by the chip, such as 6A82 indicating selection failure, 6985 indicating authentication failure, and 66A5 indicating entering a stalemate state.

[0123] In some embodiments, migration conditions can be used to determine whether the lifecycle state of an application in a first security domain supports migration. For example, migration conditions may include the application in the security domain being in a SELECTABLE state.

[0124] In some embodiments, by acquiring the application's state information in the first security domain, the virtual card's anomaly repair device can determine whether the application's state information is in a migrateable state, thereby determining whether the migration conditions are met. For example, when the application's state information in the first security domain is not locked and is in the SELECTABLE state, it indicates that the application's state information is in a preset state and meets the migration conditions, i.e., the migration conditions are met. If the application's state information in the first security domain is in the LOCKED or DEAD state, it is determined that the migration conditions are not met, and other repair methods may need to be taken, such as unlocking or deleting and rebuilding.

[0125] In the embodiments of this application, by reading and parsing the application's status information, the health status of the application's status information within the first security domain is automatically detected, thereby providing a reliable basis for subsequent migration operations and improving the accuracy and efficiency of anomaly handling.

[0126] In the embodiments of this application, when determining the status information of an application in the first security domain, a status acquisition instruction can be sent to the first virtual card; status response information sent by the first virtual card can be received; and the status information of the application in the first security domain can be determined based on the status response information.

[0127] In some embodiments, a status acquisition command is a command issued by the anomaly repair device of the virtual card to request the security domain or a specific application within the first virtual card to return the current running status information of the security domain or the specific application within the first virtual card. Status acquisition commands typically follow the standard APDU command format defined in the Global Platform (GP) specification. For example, status acquisition commands may include, but are not limited to, the SELECT command and the READ LIFECYCLE STATUS command.

[0128] In some embodiments, the virtual card's anomaly repair device actively probes the status of the security domain or application by sending a status acquisition command to determine whether it is in a locked, frozen, or other abnormal state, so as to provide a basis for judgment for subsequent repair mechanisms.

[0129] In some embodiments, the status response information is data returned by the first virtual card based on the received status acquisition instruction, and can be presented in the form of a standard APDU response code.

[0130] In some embodiments, by parsing the status response information, the virtual card's anomaly repair device can accurately determine whether an anomaly exists and decide on the next operation strategy, such as performing operations like unlocking, migration, or deletion and reconstruction. Parsing the status response information not only improves the accuracy of diagnosis but also reduces the possibility of misjudgment.

[0131] In some embodiments, the virtual card anomaly repair device can determine the status information of the application in the first security domain based on the status response information, that is, determine the actual status of the application in the first security domain, so as to further determine whether the migration conditions are met based on the status information of the application in the first security domain.

[0132] In the embodiments of this application, if the status information of the application in the first security domain is a preset state, then the screenshot determines that the first security domain meets the migration conditions.

[0133] In some embodiments, the preset state refers to a pre-defined combination of security domain states that allow migration. This typically includes the application's state information being in the SELECTABLE state, without any locked or dead flags. Only when the application's state information matches the preset state does the virtual card's anomaly repair device consider the first security domain to meet the migration conditions and allow the migration operation to proceed. This process of determining whether the application's state information matches the preset state ensures the security and feasibility of the migration operation, preventing migration failure or data corruption due to state incompatibility.

[0134] In some embodiments, by setting reasonable preset states and migration condition judgment mechanisms, migration operations are ensured to be performed only under safe and controllable conditions, avoiding resource waste and data risks, and improving stability and security. The migration condition is a logical judgment result indicating whether an application in the original security domain can be migrated to a new security domain under certain premises. The judgment of the migration condition is based on multiple factors, such as application status information, access control policies, and key status. The migration operation is only triggered when all conditions are met.

[0135] For example, in some embodiments, if the internal application in the first security domain is still in the SELECTABLE state, then it can be determined that the migration conditions are met, and then a new security domain can be established.

[0136] In some embodiments, the entire process of creating a second security domain can be completed automatically in the background. For example, the operation of creating a new second security domain with the same structure within the chip space is typically based on the Extradite instruction (Cmd = 0xE60x40) in the GP specification.

[0137] In some embodiments, after the establishment of the second security domain is completed, the virtual card's fault repair device can migrate the access control list and key index of the first security domain to the second security domain. This avoids the time and resource costs required to delete and rebuild security domains in traditional solutions, while achieving seamless fault repair.

[0138] In some embodiments, during the data migration process, the virtual card's anomaly repair device can copy the access control lists (ACLs) and key indexes of the first security domain to the second security domain, but will not export the keys in plaintext form; the virtual card's anomaly repair device can use the Extradite instruction to transfer the application from the first security domain to the second security domain and reset the internal state machine of the second security domain, clearing the dead flags therein.

[0139] In some embodiments, an Access Control List (ACL) defines which entities are allowed to perform what operations on a given security domain or application. ACLs are an important mechanism for ensuring access permissions within a security domain.

[0140] In some embodiments, a key index is used to identify the storage location of the key within a security domain. The key index ensures that the migrated security domain can correctly reference the original key.

[0141] Therefore, in the embodiments of this application, by migrating the Access Control List (ACL) and key index of the first security domain to the second security domain, application functionality can be restored while retaining the original security policy, and data loss or service interruption caused by reinstallation can be avoided. Compared with the traditional deletion and reconstruction method, migrating the Access Control List (ACL) and key index of the first security domain to the second security domain not only saves time, but also shortens the repair processing time and reduces operational complexity.

[0142] The virtual card anomaly repair method provided in this application embodiment achieves automated identification and efficient repair of high-risk anomalies such as security domain freezes by real-time monitoring of the operating status of the first virtual card and combining a two-factor authentication mechanism with GP specification application migration technology. Specifically, after detecting an anomaly, the system can automatically create a second security domain and migrate the access control policies and key configurations of the first security domain to the second security domain, thereby restoring the normal use of the first virtual card. The virtual card anomaly repair method provided in this application embodiment not only improves the stability and security of the system but also significantly reduces the need for manual intervention, lowers operation and maintenance costs, and improves user experience.

[0143] In summary, this embodiment of the application obtains the application's status information and determines whether the migration conditions are met based on a preset status. This method effectively identifies migrateable applications, initiates the migration process, restores the normal function of the security domain, and improves user experience and system reliability.

[0144] In the embodiments of this application, such as Figure 5 As shown, the method for repairing virtual card anomalies may include the following steps:

[0145] Step 204: If the real-time monitoring result indicates that the security domain is locked and / or the application is locked, send an unlock command to the first virtual card.

[0146] In the embodiments of this application, after obtaining the real-time monitoring data of the first virtual card and determining the real-time monitoring result of the first virtual card based on the real-time monitoring data, if the real-time monitoring result of the first virtual card includes a locked security domain and / or a locked application, then the virtual card anomaly repair device can choose to perform anomaly repair processing by remote unlocking.

[0147] In some embodiments, when a security domain or application in the first virtual card is detected to be locked, the virtual card's anomaly repair device can automatically trigger a remote unlocking process.

[0148] For example, in some embodiments, if an error code 6A82 is returned when trying to select an application, it indicates that the application may be locked. If the application is detected to be locked, the virtual card's fault repair device can send an unlock command to the first virtual card inside the chip to restore the first virtual card to its operable state.

[0149] In some embodiments, the unlock command is typically based on the GP specification and is sent to the target application or security domain via standard APDU commands to remotely unlock the device. The recipient of the unlock command is the first virtual card, i.e., the virtual card entity to which the currently locked application belongs, and / or the currently locked virtual card entity.

[0150] In the embodiments of this application, for abnormal scenarios where a security domain is locked and / or an application is locked, an anomaly repair process can be performed through a remote unlocking procedure. This remote unlocking mechanism avoids the waiting time required for manual intervention, significantly shortens the fault repair time, and improves fault recovery efficiency.

[0151] Step 205: If the real-time monitoring result indicates that the security domain is frozen and / or the application is frozen, perform identity authentication based on the acquired biometric information, and if the identity authentication is successful, perform anomaly repair processing on the first virtual card.

[0152] In the embodiments of this application, after acquiring the real-time monitoring data of the first virtual card and determining the real-time monitoring result of the first virtual card based on the real-time monitoring data, if the real-time monitoring result of the first virtual card includes security domain freeze and / or application freeze, then the virtual card anomaly repair device can choose to perform identity authentication based on the acquired biometric information, and perform anomaly repair processing on the first virtual card if the identity authentication is successful.

[0153] In some embodiments, when the virtual card's fault repair device detects that a security domain or application is in a frozen state (e.g., returning error code 66A5), it indicates that the security domain or application cannot be recovered by regular unlocking commands and has entered a stagnant state. At this point, the virtual card's fault repair device can initiate a higher-level repair process.

[0154] In some embodiments, the virtual card anomaly repair device can first obtain the user's biometric information. This biometric information may include, but is not limited to, fingerprint data, facial images, and iris scan data. Here, biometric information possesses a high degree of individual uniqueness and anti-counterfeiting capabilities. Introducing a biometric authentication mechanism also enhances the credibility of the entire repair process and effectively defends against external threats such as relay attacks. The identity authentication process ensures that only legitimate users can initiate high-risk repair operations, preventing unauthorized operations from potentially causing security vulnerabilities.

[0155] For example, in some embodiments, the virtual card anomaly repair device can collect the user's biometric information through a biometric module (such as a fingerprint sensor or a facial recognition camera) and authenticate the user's identity. If the authentication is successful, the virtual card anomaly repair device will perform the corresponding anomaly repair operation, such as migrating the application or deleting and rebuilding a specific application to restore the functionality of the specific application.

[0156] For example, in some embodiments, for abnormal scenarios such as security domain freeze and / or application freeze, the abnormal repair process specifically includes means such as application hot migration or targeted deletion and reconstruction. These means can bypass the freeze state and restore the first virtual card to normal operation.

[0157] In the embodiments of this application, abnormal scenarios where a security domain is locked and / or an application is locked can be classified as low-risk scenarios. The corresponding anomaly repair processing can be the processing method for low-risk scenarios, such as remote unlocking. For example, an unlock command can be automatically sent when a security domain or application is detected to be locked. Abnormal scenarios where a security domain appears to be frozen and / or an application appears to be frozen can be classified as low-risk or high-risk scenarios. The corresponding anomaly repair processing can be the processing method for high-risk scenarios, such as hot migration of the application or targeted deletion and reconstruction. For example, biometric authentication can be introduced and anomaly repair processing can be performed when a frozen state is detected. In this way, by using different types of anomaly repair methods for different types of abnormal scenarios, the fault response speed and repair success rate can be significantly improved, thereby enhancing the overall reliability and security of the virtual card.

[0158] For example, in some embodiments, the real-time monitoring results can be determined based on the acquired real-time monitoring data, and the abnormal scenarios can be further classified based on the real-time monitoring results, as shown in Table 1:

[0159] Table 1

[0160]

[0161] Of course, the abnormal scenarios can be divided into high-risk and low-risk scenarios, and this application does not impose specific limitations.

[0162] In the embodiments of this application, such as Figure 6 As shown, the method for repairing virtual card anomalies may include the following steps:

[0163] Step 206: If the real-time monitoring result indicates that the application is frozen, send an application uninstallation command to the first virtual card; wherein the application uninstallation command carries a first application identifier, which is used to identify the application that is abnormal.

[0164] Step 207: After receiving the application uninstallation response sent by the first virtual card, send an application installation command to the first virtual card; wherein the application uninstallation command carries the first application identifier.

[0165] In the embodiments of this application, after obtaining the real-time monitoring data of the first virtual card and determining the real-time monitoring result of the first virtual card based on the real-time monitoring data, if the real-time monitoring result is that the security domain is dead and the first security domain corresponding to the first virtual card meets the migration conditions, then the virtual card anomaly repair device can further create a second security domain corresponding to the first virtual card and migrate the access control list and key index of the first security domain to the second security domain.

[0166] After acquiring the real-time monitoring data of the first virtual card and determining the real-time monitoring result of the first virtual card based on the real-time monitoring data, if the real-time monitoring result is that the application is frozen, the virtual card's abnormal repair device can send an application uninstallation command to the first virtual card; and after receiving the application uninstallation response sent by the first virtual card, it sends an application installation command to the first virtual card.

[0167] In some embodiments, an application freeze refers to a security domain or application entering a frozen state due to an unrecoverable error (such as hardware failure). This is manifested by a return code of 66A5, indicating that the application or security domain cannot be recovered using standard unlock commands. Application freezes are typically caused by external attacks, signal interference, or key verification failures, thus preventing normal access to the abnormal application or security domain.

[0168] In some embodiments, the application uninstallation instruction carries a first application identifier, which is used to determine the existence of an abnormal application.

[0169] In some embodiments, an application uninstallation command is a command used to delete a specified application. The application uninstallation command locates and uninstalls the target application using a specific identifier. Specifically, the application uninstallation command carries a first application identifier, which uniquely identifies the application currently in an abnormal state. The first application identifier can be the application ID (AID) of the abnormal application, i.e., an application identifier that conforms to a standard definition and is globally unique.

[0170] In some embodiments, upon detecting that an application is in a frozen state, the virtual card's anomaly repair device can quickly locate and uninstall the malfunctioning application, preventing it from affecting the operation of the entire security domain and preventing malicious operations from further escalating the risk. Furthermore, by accurately identifying the faulty application and uninstalling only the malfunctioning portion, rather than the entire security domain, repair costs and time are reduced.

[0171] In the embodiments of this application, after receiving the application uninstallation response sent by the first virtual card, if it is determined through the application uninstallation response that the first virtual card has completed the uninstallation of the abnormal application, then the virtual card's abnormal repair device can further send an application installation instruction to the first virtual card; wherein, the application uninstallation instruction carries the first application identifier.

[0172] In some embodiments, the application uninstallation response is feedback information from the first virtual card to the application uninstallation command, indicating whether the abnormal application was successfully uninstalled. If the abnormal application was successfully uninstalled, the next step is executed, namely, sending an application installation command.

[0173] In some embodiments, the application installation instruction is used to reinstall the malfunctioning application in its original location, and also carries the first application identifier. The purpose of the application installation instruction is to ensure that the malfunctioning application is installed.

[0174] In some embodiments, the reinstallation of the malfunctioning application is triggered immediately after uninstallation, enabling the first virtual card to quickly return to normal operation. Since both the application uninstallation and installation commands use the same first application identifier, the virtual card's fault repair device can accurately identify and rebuild the state of the malfunctioning application, thereby achieving targeted recovery without affecting other normally functioning applications.

[0175] Therefore, compared to the traditional method of complete reinstallation, on the one hand, uninstalling and installing only faulty applications (one or more abnormal applications) can significantly reduce resource consumption and processing time, thus achieving an efficient and low-interference automatic repair mechanism. On the other hand, by sending an application uninstallation command when an application is detected to be frozen, and sending an application installation command after the application is successfully uninstalled, it is possible to quickly isolate and restore abnormal applications, thereby ensuring the stability and security of the first virtual card and significantly improving fault repair efficiency.

[0176] In other words, in the embodiments of this application, for abnormal scenarios where an application appears to freeze, the abnormal application is removed using an application uninstallation command, the uninstallation status is confirmed based on the application uninstallation response, and then a precise recovery is performed using an application installation command. This process ensures that the isolation and recovery of abnormal applications can be completed quickly without damaging the overall structure, effectively improving fault tolerance and availability.

[0177] In the embodiments of this application, the abnormal repair processing for the apparent dead state may include abnormal repair processing for the security domain state dead state and abnormal repair processing for the application state dead state.

[0178] Exemplarily, in some embodiments, such as Figure 7 As shown, for the first virtual card, there can be a corresponding first security domain. All related applications of the first virtual card, such as application 1, application 2, application 3, and related installation packages, log files, permission information files, etc., need to be installed in this corresponding first security domain.

[0179] In some embodiments, for cases where a security domain appears to be dead, a new identical security domain can be created within the chip space, and all applications in the original security domain can be migrated to the new security domain. This involves first reading the state of the applications in the fault-safe domain to ensure the system sets them to the SELECTABLE state; then, the ACL and key index of the original security domain can be copied, but the system resets the state machine of the original security domain; next, the Extradite instruction is used to transfer the applications while retaining references to the encryption keys; finally, a secure erasure operation is performed on the old security domain key, and the corresponding structure is deleted.

[0180] Exemplarily, in some embodiments, such as Figure 8 As shown, for handling the anomaly repair of a security domain freeze, a new identical security domain can be created within the chip space, and then all applications within the original locked security domain can be migrated to the new security domain. For example, applications in the first security domain experiencing the anomaly can be migrated to the newly created corresponding second security domain. Compared to the solution of deleting and rebuilding the security domain, the migration time of applications within the chip is only 18% of that of a reinstallation, resulting in a faster recovery time.

[0181] In some embodiments, for applications that appear to freeze, a targeted deletion and reconstruction method can be chosen, which involves uninstalling and reinstalling only the faulty application while preserving other data within the security domain. This avoids the tedious process of deleting and reinstalling the entire security domain and effectively resolves the application freezing issue.

[0182] Exemplarily, in some embodiments, such as Figure 9 As shown, for handling the abnormal repair of application freezing, the target application AID can be specified by the DELETE instruction to limit the scope of uninstallation, and the target application (such as application 1) can be reinstalled by the INSTALL instruction; the application parameters are backed up to the non-volatile storage of the security domain; if the uninstallation fails, an application-level rollback is triggered to restore the application to the state before freezing.

[0183] In the embodiments of this application, a layered retry and risk escalation mechanism is designed to address potential uncertainties in the repair operation. When a low-risk anomaly is detected (such as a locked security domain or application), an unlocking command can be automatically triggered. If the initial repair fails, a limited retry strategy is initiated, with the retry interval increasing exponentially using a backoff algorithm. If multiple retries still fail, the following closed-loop operations are performed: 1. Log marking and risk escalation: Record the anomaly event and escalate its risk level from low to high; 2. Perform dynamic permission contraction: Immediately freeze access permissions for the target security domain or application; 3. Trigger a high-level intervention mechanism upon detecting an anomaly: Push alarm information to the management platform in the form of a work order, requiring administrators to manually intervene or for the system to automatically execute a system-level recovery protocol.

[0184] In summary, the virtual card anomaly repair method proposed in this application firstly automatically judges the virtual card status through real-time monitoring data, avoiding reliance on user feedback and improving the detection efficiency of abnormal scenarios. Secondly, when it is confirmed that the security domain is in a suspended state, a new security domain is created and the original configuration information is migrated, rather than being deleted and rebuilt, thereby reducing the anomaly repair time and reducing resource consumption.

[0185] The virtual card anomaly repair method proposed in this application embodiment can significantly improve the fault recovery time, reducing the average anomaly repair time from 8 hours of traditional manual processing to less than 16 seconds; it can also significantly reduce operation and maintenance costs, avoid the secondary card opening fees caused by reinstallation operations, and reduce the overall manual processing requirements by more than 91%.

[0186] The virtual card anomaly repair method proposed in this application can enhance reliability by optimizing the system architecture and introducing redundancy mechanisms, reducing the false positive rate to below 0.1%, and the configured risk escalation strategy can effectively prevent the spread of single point of failure.

[0187] The virtual card anomaly repair method proposed in this application can effectively block relay attacks by using biometric authentication and dynamic access control; at the same time, it uses key circuit breaking technology to ensure that the password cannot be recovered.

[0188] Therefore, the virtual card anomaly repair method proposed in this application realizes an automated monitoring and repair closed-loop system for NFC chip security domain and application anomalies. Specifically, the two-factor authentication mechanism solves the industry's problem of misjudgment; the innovative application of the GP specification overcomes the limitation that a frozen state is unrecoverable; and the dynamic circuit breaker engine constructs a defense system that meets automotive-grade safety standards.

[0189] This application proposes a method for repairing anomalies in virtual cards. The method involves acquiring real-time monitoring data of a first virtual card and determining the real-time monitoring result based on this data. If the real-time monitoring result indicates a security domain freeze, and the first security domain corresponding to the first virtual card meets the migration conditions, a second security domain corresponding to the first virtual card is created. The access control list and key index of the first security domain are then migrated to the second security domain. Therefore, in this application, on the one hand, the virtual card status can be automatically determined using real-time monitoring data, avoiding reliance on user feedback and improving the detection efficiency of abnormal scenarios. On the other hand, when a security domain is confirmed to be in a freeze state, a new security domain can be created and the original data and information migrated, rather than being deleted and rebuilt, thereby reducing the anomaly repair time and resource consumption. In other words, this application can realize an automated monitoring and repair closed-loop system for NFC chip security domains and application anomalies, overcoming the limitation of traditional methods that cannot handle freeze states, achieving an automated repair process, and improving the performance of NFC virtual cards.

[0190] Based on the above embodiments, another embodiment of this application proposes a method for repairing virtual cards, including an automatic detection and repair strategy for abnormal states of NFC virtual card applications. Specifically, in this embodiment, an automated closed-loop system with multi-level monitoring, graded repair, and risk circuit breaker is constructed to solve the problem of NFC virtual card applications becoming unusable due to abnormal states.

[0191] The virtual card anomaly repair method proposed in this application embodiment may include several parts such as: chip dynamic behavior monitoring, anomaly classification and handling, anomaly diagnosis two-factor verification mechanism, breakthrough solution for apparent death state, and layered retry and risk escalation mechanism.

[0192] In some embodiments, chip dynamic behavior monitoring may include the following two aspects:

[0193] (1) Monitor the APDU command content and return code. If the command response is abnormal (such as the application selection command returning 6A82, the security domain authentication command returning 6985, etc.), then perform an automatic repair mechanism.

[0194] (2) Monitor for abnormal access patterns. If there are attack characteristics such as high-frequency authentication requests, then record the risks of the chip in advance.

[0195] In some embodiments, the anomaly classification and handling can be divided into high-risk and low-risk scenarios. Common low-risk scenarios include: security domain locking and application locking. When this scenario is triggered, a mild recovery process is used to trigger remote unlocking and repair. High-risk scenarios include: security domain or application freezing, which is determined to be due to external attack. This requires a multi-authorization mechanism, a pop-up reminder to the user, and biometric authentication (fingerprint or face) to confirm that the user is the one using the virtual card before the automatic repair mechanism can be initiated. The correspondence between command response content and anomaly behavior is shown in Table 2.

[0196] Table 2

[0197]

[0198] For example, such as Figure 10 As shown, the virtual card anomaly repair device can acquire real-time monitoring data, including response APDUs and / or access mode data, through chip dynamic behavior monitoring (step 1001). If an anomaly scenario is determined based on the response APDU, it can be further determined whether it is a high-risk scenario, i.e., whether the real-time monitoring result is a security domain freeze and / or application freeze (step 1002). If it is not a high-risk scenario, i.e., it is determined to be a low-risk scenario, then further anomaly repair for the low-risk scenario is performed (step 1003). If so, it is further determined whether the biometric authentication is successful (step 1004). If successful, further anomaly repair for the high-risk scenario is performed (step 1005). If unsuccessful, further risk recording is performed (step 1006). Based on the access mode data, it is determined whether there is a potential anomaly risk (step 1007). If so, further risk recording is performed (step 1006); otherwise, the acquisition of real-time monitoring data continues.

[0199] In other words, regarding anomaly classification and handling, abnormal scenarios can be divided into high-risk and low-risk categories, and different response strategies can be adopted. For low-risk scenarios (such as a locked security domain or application), the system adopts a mild recovery process, such as remote unlocking; while for high-risk scenarios (such as a frozen security domain or application), the system needs to perform multi-authorization verification mechanisms, including pop-up reminders to users and requiring biometric authentication (such as fingerprint or facial recognition). Only after confirming that it is the user who is using the system will the system allow the automatic repair mechanism to be executed.

[0200] In some embodiments, for the two-factor authentication mechanism for anomaly diagnosis, detecting an abnormal instruction response code (such as the application selection return 6A82) is only a necessary but not sufficient condition for an abnormal state.

[0201] For example, such as Figure 11As shown, through steps 1101 to 1109, (1) when a preset abnormal command code is captured, an application lifecycle read request is immediately initiated; (2) if the returned status value is LOCKED, it is confirmed as a lockout exception; (3) otherwise, it is attributed to a transient error and a basic retry process is triggered. Taking the monitoring of the selected security domain command content as an example, after obtaining the real-time monitoring data (status word), it is determined whether the security domain command responds to 6A82 and 66A5. If a preset abnormal command code is detected, such as responding to 6A82 or 66A5, the status word is combined with the lifecycle status for judgment. For example, the security domain lifecycle is read, and the security domain lifecycle is further judged as whether it is locked or dead, thereby determining whether the security domain status is locked or dead. If neither is true, risk is recorded. This can more accurately identify the type of exception, avoid misjudgment, improve the accuracy of fault location, and at the same time, reduce the frequency of manual intervention, realize automated abnormal diagnosis and repair process, thereby significantly improving reliability.

[0202] In other words, to eliminate the risk of false positives and improve the accuracy of anomaly detection, a two-factor authentication mechanism can be introduced, namely, secondary verification based on the application lifecycle state. For example, when an abnormal command response code is detected (such as application selection returning 6A82), detecting such a response code is only a necessary but not sufficient condition for an anomaly. Furthermore, a secondary verification is needed by reading the application lifecycle state. If the reading result is LOCKED, a locking anomaly is confirmed; otherwise, it will be considered a transient error, and the basic retry process will be triggered.

[0203] In some embodiments, once all application state anomalies are automatically detected, different handling is required for different anomalies. For security domain or application lock issues, a method of remotely sending unlock commands can be tried. According to the GP specification, an application state of "LOCKED" (locked) can be restored to normal.

[0204] In some embodiments, the abnormal repair processing for a seemingly dead state may include abnormal repair processing for a security domain state dead state and abnormal repair processing for an application state dead state.

[0205] Exemplarily, in some embodiments, such as Figure 12 As shown, in the chip space, a virtual card needs to correspond to a security domain. All related applications of the virtual card, such as application 1, application 2, application 3, related installation packages, log files, permission information files, etc., need to be installed in this corresponding security domain.

[0206] In some embodiments, for the case of a security domain appearing to be dead, a new security domain of the same type can be created within the chip space, and all applications within the original security domain can be migrated to the new security domain. Installed virtual card applications can be migrated to different security domains unless the application is locked or has reached the end of its lifecycle. Further, depending on the actual situation: (1) when a security domain appears to be dead, the lifecycle of its internal applications remains SELECTABLE (optional); (2) the dead security domain only loses management functions (such as access authentication), but the applications are not marked as locked, thus meeting the migration conditions. Therefore, a new security domain of the same type can be created within the chip space, and all applications within the original locked security domain can be migrated to the new security domain.

[0207] In some embodiments, such as Figure 13 As shown, referring to steps 1301 to 1308, in the case of a security domain seemingly dead, a new identical security domain can be created within the chip space, and all applications in the original security domain can be migrated to the new security domain. Specifically, the status of applications in the fault-safe domain can be read first to ensure the system sets the applications in the fault-safe domain to the SELECTABLE state. For example, the management platform in the electronic device can send a GET STATUS command to the old security domain (fault-safe domain) to read the status of applications in the fault-safe domain. The fault-safe domain returns a list of application AIDs, i.e., the status, such as SELECTABLE. The management platform creates a new security domain and obtains the new security domain AIDs. Then, the ACL and key index of the original security domain can be copied, while resetting the state machine of the original security domain. For example, the EXTRADITE command can be used to transfer the applications, that is, to migrate the applications in the fault-safe domain to the new security domain, while retaining the reference to the encryption key. A secure erasure operation (destruction operation) is performed on the old security domain key, and the corresponding structure is deleted.

[0208] In this embodiment, compared to conventional repair methods, the migration time of the internal application of the chip is only 18% of that of reinstallation. Therefore, compared to the solution of deleting and rebuilding the security domain, the recovery time is faster, and the repair can be performed without the user's awareness.

[0209] In some embodiments, for the case of an application freezing, a targeted deletion and reconstruction method is adopted, which only uninstalls and reinstalls the faulty application, while retaining other data in the security domain. This can avoid the tedious process of deleting and reinstalling the entire security domain and effectively solve the application freezing problem.

[0210] In some embodiments, such as Figure 14As shown, referring to steps 1401 to 1406, in the case of an application freeze, (1) the management platform of the electronic device sends a DELETE command to the NFC chip, and restricts the uninstallation process to only operate on the target application by specifying the application AID; (2) freezes the application thread, and backs up the application parameters (such as transaction counters and access policies) to the secure domain non-volatile storage; (3) reinstalls the target application (application AID) by using the INSTALL command, loads the backup data, and returns a success message. If the uninstallation process fails, an application-level rollback is triggered to restore the application to its state before freezing.

[0211] In some embodiments, this application also introduces a tiered retry and risk escalation mechanism. This is because, in reality, not all repair operations have a 100% success rate. For example, the unlock command may fail to execute, and the application migration process may also fail. Therefore, the tiered retry and risk escalation mechanism can be used to address the problem of uncertain failures in repair operations.

[0212] In some embodiments, such as Figure 15 As shown, when a security domain / application lockout (low-risk anomaly) is detected, an unlock command will be automatically triggered. If the initial repair fails, a limited retry strategy (e.g., 3 times) will be initiated, with the retry interval increasing exponentially using a backoff algorithm (e.g., 200ms → 600ms → 1800ms) to avoid command storms. If the retry count reaches a preset threshold and still fails, a closed-loop operation will be performed, including but not limited to:

[0213] (1) Log marking and risk escalation: Record abnormal events (including error codes, environmental parameters, retry traces) and escalate the abnormality level from low risk to high risk;

[0214] (2) Dynamic permission contraction: Immediately freeze access permissions for the security domain / application to prevent residual vulnerabilities from being exploited;

[0215] (3) Triggering high-level intervention: Pushing an alarm work order to the management platform, requesting manual intervention or initiating system-level recovery protocols (such as key circuit breaking, security domain isolation).

[0216] The virtual card anomaly repair method proposed in this application can achieve the following effects:

[0217] 1. Improved fault recovery time

[0218] (1) Automated monitoring and repair reduces the average repair time for faults and anomalies from 8 hours (manual intervention) to 16 seconds (actual measurement data);

[0219] (2) The apparent dead state is restored by applying migration technology, which takes only 18% of the time of reinstallation (within 5 seconds), achieving a repair that is imperceptible to the user.

[0220] 2. Operation and maintenance costs are significantly reduced.

[0221] (1) Avoid the cost of reactivating the card due to reinstallation (save 3 to 50 yuan per card);

[0222] (2) The demand for manual processing decreased by 91%, and the annual operation and maintenance cost was reduced by hundreds of thousands of yuan (based on a user scale of tens of thousands).

[0223] 3. Breakthrough in system reliability

[0224] (1) The two-factor validation mechanism reduces the false positive rate to below 0.1% (compared to more than 15% for traditional methods);

[0225] (2) Risk escalation strategies prevent 90% of single-point failures from spreading (such as key leakage).

[0226] 4. Enhanced security defenses

[0227] (1) Biometric authentication + dynamic permission reduction mechanism, with a 99.3% success rate in blocking relay attacks;

[0228] (2) Key melting technology ensures that the cryptographic level of the permanently locked domain is unrecoverable.

[0229] In summary, the virtual card anomaly repair method proposed in this application realizes an automated monitoring and repair closed-loop system for NFC chip security domains and application anomalies. Specifically: (1) a two-factor authentication mechanism solves the industry's misjudgment problem; (2) innovative application of the GP specification overcomes the limitation of unrecoverable states in a frozen state; and (3) a dynamic circuit breaker engine constructs a defense closed loop that meets automotive-grade security standards. This solution has clear practical value and innovation in the field of NFC chip management and security.

[0230] The virtual card anomaly repair method proposed in this application has two advantages. First, it can automatically determine the virtual card status through real-time monitoring data, avoiding reliance on user feedback and improving the detection efficiency of abnormal scenarios. Second, when it is confirmed that the security domain is in a frozen state, a new security domain can be created and the original data and information migrated, rather than being deleted and rebuilt, thereby reducing anomaly repair time and resource consumption. In other words, this application can realize an automated monitoring and repair closed-loop system for NFC chip security domain and application anomaly states, breaking through the limitation of traditional methods that cannot handle frozen states, realizing an automated repair process, and improving the performance of NFC virtual cards.

[0231] Based on the above embodiments, in another embodiment of this application... Figure 16 This is a schematic diagram of the composition structure of the virtual card anomaly repair device proposed in this application embodiment. Figure 2 ,like Figure 16As shown, the virtual card anomaly repair device 160 proposed in this application embodiment may include:

[0232] The acquisition unit 1601 is used to acquire real-time monitoring data of the first virtual card and determine the real-time monitoring result of the first virtual card based on the real-time monitoring data.

[0233] The creation unit 1602 is used to create a second security domain corresponding to the first virtual card when the real-time monitoring result is that the security domain is in a state of suspension and the first security domain corresponding to the first virtual card meets the migration conditions.

[0234] Migration unit 1603 is used to migrate the access control list and key index of the first security domain to the second security domain.

[0235] In the embodiments of this application, further, Figure 17 This is a schematic diagram of the composition structure of the electronic device proposed in the embodiments of this application, such as... Figure 17 As shown, the electronic device 170 proposed in this application embodiment may include a processor 1701, a memory 1702, a communication interface 1703, and a bus 1704 for connecting the processor 1701, the memory 1702, and the communication interface 1703.

[0236] In the embodiments of this application, the processor 1701 can be at least one of the following: Application-Specific Integrated Circuit (ASIC), Digital Signal Processor (DSP), Digital Signal Processing Device (DSPD), Programmable Logic Device (PLD), Field-Programmable Gate Array (FPGA), Central Processing Unit (CPU), Controller, Microcontroller, and Microprocessor. It is understood that for different devices, the electronic device used to implement the above-mentioned processor function can also be other types, and this application embodiment does not specifically limit the specific types. The electronic device 170 may also include a memory 1702, which can be connected to the processor 1701. The memory 1702 is used to store executable program code, which includes computer operation instructions. The memory 1702 may include high-speed RAM memory and may also include non-volatile memory, such as at least two disk drives.

[0237] In embodiments of this application, bus 1704 is used to connect communication interface 1703, processor 1701, and memory 1702, as well as the mutual communication between these devices.

[0238] In practical applications, the aforementioned memory 1702 can be volatile memory, such as random-access memory (RAM); or non-volatile memory, such as read-only memory (ROM), flash memory, hard disk drive (HDD), or solid-state drive (SSD); or a combination of the above types of memory, and provide instructions and data to the processor 1701.

[0239] In an embodiment of this application, processor 1701 is configured to: acquire real-time monitoring data of a first virtual card, and determine the real-time monitoring result of the first virtual card based on the real-time monitoring data; create a second security domain corresponding to the first virtual card when the real-time monitoring result indicates that the security domain is in a state of limbo and the first security domain corresponding to the first virtual card meets the migration conditions; and migrate the access control list and key index of the first security domain to the second security domain.

[0240] Furthermore, in this embodiment, the functional modules can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional module.

[0241] If the integrated unit is implemented as a software functional module and is not sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this embodiment, in essence, or the part that contributes to related technologies, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) or processor to execute all or part of the steps of the method of this embodiment. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0242] This application provides a computer-readable storage medium storing a program thereon, which, when executed by a processor, implements the virtual card anomaly repair method as described above.

[0243] Specifically, the program instructions corresponding to the virtual card anomaly repair method in this embodiment can be stored on storage media such as optical discs, hard disks, and USB flash drives. When the program instructions corresponding to the virtual card anomaly repair method in the storage media are read or executed by the first device, the following steps are included:

[0244] Obtain real-time monitoring data of the first virtual card, and determine the real-time monitoring result of the first virtual card based on the real-time monitoring data;

[0245] If the real-time monitoring result indicates that the security domain is in a state of suspension, and the first security domain corresponding to the first virtual card meets the migration conditions, then create the second security domain corresponding to the first virtual card.

[0246] Migrate the access control list and key index of the first security domain to the second security domain.

[0247] This application also provides a computer program product.

[0248] In some embodiments, the computer program product may include a computer program or instructions.

[0249] In some embodiments, the computer program product can be applied to the computer device in the embodiments of this application, and the computer program instructions cause the computer to execute the corresponding processes implemented by the computer device in the various methods of the embodiments of this application. For the sake of brevity, they will not be described in detail here.

[0250] Those skilled in the art will understand that embodiments of this application can be provided as methods, systems, or computer program products. Therefore, this application can take the form of hardware embodiments, software embodiments, or embodiments combining software and hardware aspects. Furthermore, this application can take the form of a computer program product implemented on one or more computer-usable storage media (including, but not limited to, disk storage and optical storage) containing computer-usable program code.

[0251] This application is described with reference to schematic and / or block diagrams of implementations of methods, apparatus (systems), and computer program products according to embodiments of this application. It should be understood that each block of the schematic and / or block diagrams can be implemented by computer program instructions, and combinations of blocks in the schematic and / or block diagrams can be implemented. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable key management device to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable key management device, generate instructions for implementing the implementation of the schematic and / or block diagrams. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0252] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable key management device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in the implementation flow diagram. Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0253] These computer program instructions can also be loaded onto a computer or other programmable key management device, causing a series of operational steps to be performed on the computer or other programmable device to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable device for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0254] The above description is merely a preferred embodiment of this application and is not intended to limit the scope of protection of this application.

Claims

1. A method for repairing an exception of a virtual card, characterized by, The method comprises: obtaining real-time monitoring data of a first virtual card, and determining a real-time monitoring result of the first virtual card based on the real-time monitoring data; in the case that the real-time monitoring result is a safe domain dead, and a first security domain corresponding to the first virtual card meets migration conditions, creating a second security domain corresponding to the first virtual card; migrating an access control list and a key index of the first security domain to the second security domain.

2. The method of claim 1, wherein, The method further comprises: determining state information of an application program in the first security domain; in the case that the state information of the application program in the first security domain is a preset state, determining that the first security domain meets migration conditions.

3. The method of claim 2, wherein, The determination of the state information of the application program in the first security domain comprises: sending a state acquisition instruction to the first virtual card; receiving state response information sent by the first virtual card; determining the state information of the application program in the first security domain based on the state response information.

4. The method of claim 1, wherein, The real-time monitoring data comprises response application protocol data unit (APDU) and / or access mode data; the obtaining of the real-time monitoring data of the first virtual card comprises: obtaining the response APDU sent by the first virtual card; wherein the response APDU is used to respond to a command APDU sent to the first virtual card; and / or, obtaining the access mode data corresponding to the first virtual card.

5. The method of claim 4, wherein, The determination of the real-time monitoring result of the first virtual card based on the real-time monitoring data comprises: determining a first response state word of a security domain and / or a second response state word of an application program based on the response APDU; and determining the real-time monitoring result of the first virtual card based on the first response state word and / or the second response state word.

6. The method of claim 5, wherein, The determination of the real-time monitoring result of the first virtual card based on the first response state word and / or the second response word comprises: in the case that the first response state word is a first preset state word, and a life cycle of the security domain is a lock state, determining that the real-time monitoring result is that the security domain is locked; wherein the first preset state word comprises a first state word, a second state word and a third state word; in the case that the first response state word is a first preset state word, and the life cycle of the security domain is a dead state, determining that the real-time monitoring result is that the security domain is dead.

7. The method of claim 5, wherein, The determination of the real-time monitoring result of the first virtual card based on the first response state word and / or the second response word comprises: in the case that the second response state word is a second preset state word, and a life cycle of the application program is a lock state, determining that the real-time monitoring result is that the application program is locked; wherein the second preset state word comprises a first state word and a second state word; in the case that the second response state word is a second preset state word, and the life cycle of the application program is a dead state, determining that the real-time monitoring result is that the application program is dead.

8. An abnormality recovery apparatus of a virtual card, characterized by comprising: The abnormality repair device of the virtual card comprises: an obtaining unit, configured to obtain real-time monitoring data of a first virtual card, and determine a real-time monitoring result of the first virtual card based on the real-time monitoring data; The creating unit is configured to create a second security domain corresponding to the first virtual card in a case where the real-time monitoring result is a security domain dead lock, and a first security domain corresponding to the first virtual card meets a migration condition; The migration unit is configured to migrate an access control list and a key index of the first security domain to the second security domain.

9. An electronic device, comprising: The electronic device comprises a processor and a memory storing instructions executable by the processor, and when the instructions are executed by the processor, the method of any one of claims 1-7 is implemented.

10. A computer program product comprising computer programs or instructions, characterized in that, The computer program or the instructions are executed by the processor to implement the method of any one of claims 1-7.

Images