Management method of card application and management system of card application

Abstract

The invention provides a card application management method and a card application management system. The card application management method comprises the steps that an SD-DP + platform issues a configuration file to a card chip; the configuration file comprises a target card application and a filing voucher corresponding to the target card application; the record voucher is used for verifying security information of the target card application; the card chip receives the configuration file and verifies the target card application based on the record voucher; if the verification result is that the verification is passed, the card chip sets the target card application to be in a to-be-enabled state; the card chip responds to the received enabling instruction, and the target card application in the to-be-enabled state is switched to the enabled state. In the mode, through the management method for realizing card application security verification and controllable starting in the configuration file issuing stage, the security risk caused by malicious card application can be reduced, and the autonomous control right of a user to the card application is improved.

Description

Technical Field

[0001] This application relates to the field of communication technology, and in particular to a card application management method and a card application management system. Background Technology

[0002] With the increasing popularity of eSIM (Embedded SIM) technology, users can flexibly and dynamically download configuration files containing different SIM card applications to access diverse services offered by operators. However, this open download mechanism also provides an opportunity for the implantation of malicious SIM card applications. Attackers may use fake download platforms to distribute SIM card applications carrying malicious code, posing a serious threat to users' communication security and personal privacy.

[0003] While static whitelisting mechanisms can block unknown card applications in existing technologies, they also significantly limit the flexibility and functional scalability of eSIMs. Relying on post-event auditing fails to effectively prevent malicious activity before it occurs, making it difficult to avoid user data leaks or financial losses. Furthermore, existing solutions generally lack a user authorization process, leaving users unable to choose whether to enable card applications bundled in their configuration files, thus lacking necessary control. Summary of the Invention

[0004] In view of this, the purpose of this application is to provide a card application management method and a card application management system. By implementing a management method for card application security verification and controllable activation during the configuration file distribution stage, the security risks caused by malicious card applications can be reduced and the user's autonomy over card applications can be enhanced.

[0005] In a first aspect, the present invention provides a card application management method, applied to a card application management system, the card application management system including an SM-DP+ platform and a card chip connected in communication; the method includes: The SM-DP+ platform distributes the configuration file to the card chip; the configuration file contains the target card application and the corresponding filing certificate; the filing certificate is used to verify the security information of the target card application.

[0006] The card chip receives the configuration file and verifies the target card application based on the registration certificate.

[0007] If the verification result is successful, the card chip will set the target card application to a pending state.

[0008] In response to the received enable command, the card chip switches the target card application from the pending enable state to the enabled state.

[0009] In an optional implementation, the card application management system further includes a registration platform that communicates with both the card chip and the SM-DP+ platform; the registration certificate is generated in the following manner: The filing platform receives the application code corresponding to the target card application.

[0010] The filing platform performs a preset security audit on the application code of the target card application.

[0011] If the preset security audit result is passed, the filing platform generates a filing certificate for the target card application and sends the filing certificate to the SM-DP+ platform.

[0012] In an optional implementation, the card chip pre-stores the platform public key corresponding to the filing platform; the filing certificate includes the filing version number, the filing code hash value, and the digital signature.

[0013] The steps for the card chip to receive the configuration file and verify the target card application based on the filing certificate include: The card chip receives the configuration file and retrieves the current version number and application code of the target card application from the filing certificate contained in the configuration file.

[0014] The card chip verifies the digital signature based on the platform's public key to obtain the digital signature verification result.

[0015] The card chip parses the application code and calculates the current code hash value corresponding to the target card application according to the preset hash algorithm.

[0016] The card chip determines whether the current code hash value matches the filing code hash value, and at the same time, whether the current version number matches the filing version number.

[0017] If the current code hash value matches the filing code hash value, the current version number matches the filing version number, and the digital signature verification result is passed, then the verification result is determined to be passed.

[0018] In an optional implementation, the card application management system further includes a filing platform that is communicatively connected to both the card chip and the SM-DP+ platform; the filing credential includes a filing identifier; the method further includes: In response to the received disable command, the card chip uploads the verification information of the target card application to the filing platform; the verification information includes the filing identifier of the target card application, the current version number, and the current code hash value.

[0019] The filing platform verifies the legitimacy of the target card application based on the verification information.

[0020] If the legality verification result is successful, the filing platform sends an activation command to the card chip.

[0021] The card chip responds to the activation command and switches the target card application from the pending state to the enabled state.

[0022] In an optional implementation, after the step of the filing platform verifying the legitimacy of the target card application based on the verification information, the method further includes: If the legality verification fails, the filing platform sends a disabling command to the card chip.

[0023] The card chip responds to the disable command and switches the target card application from the pending enable state to the disabled state.

[0024] In an optional implementation, the step of the filing platform verifying the legitimacy of the target card application based on verification information includes: The filing platform determines whether the filing identifier exists in the filing record.

[0025] If the filing identifier exists in the filing record, determine whether the current version number is consistent with the filing version number.

[0026] If the current version number matches the version number registered, determine whether there is a security update for the current version number.

[0027] If there is no security update for the current version number, check if the current code hash value is consistent with the filing code hash value.

[0028] If the current code hash value matches the filing code hash value, the legality verification result is determined to be successful, and the legality verification result is sent to the card chip.

[0029] In an optional implementation, the card application management system also includes a filing platform that communicates with both the card chip and the SM-DP+ platform.

[0030] When the target card application is a high-risk application that meets preset conditions, the steps to switch the target card application from the pending activation state to the activated state include: The card chip sends authentication requests to both the user terminal and the filing platform.

[0031] If the card chip receives a terminal confirmation instruction from the user terminal and a platform confirmation instruction from the filing platform, it will switch the target card application from the pending activation state to the activated state.

[0032] In an optional implementation, the card application management system also includes a filing platform that communicates with both the card chip and the SM-DP+ platform.

[0033] The method also includes: The card chip synchronizes blacklist data from the filing platform at preset time intervals; the blacklist data includes the blacklist code hash value corresponding to illegal or high-risk card applications.

[0034] When the card chip receives the configuration file, if it detects that the current code hash value of the target card application is consistent with the blacklist code hash value, it will set the target card application to a disabled state.

[0035] In an optional implementation, the card application management system also includes a filing platform that communicates with both the card chip and the SM-DP+ platform.

[0036] The method also includes: The filing platform performs a preset security audit on the application code of the target card application based on a preset detection cycle.

[0037] If the default security audit results indicate the existence of a vulnerability, the filing platform generates a patched version of the target card application based on the vulnerability and updates the filing certificate corresponding to the target card application.

[0038] The filing platform generates update instructions based on the patch version and sends the update instructions to the card chip.

[0039] The card chip receives the update command and replaces the current version of the target card application with the patched version of the target card application.

[0040] Secondly, the present invention provides a card application management system for executing the card application management method of any of the above embodiments. The card application management system includes an SM-DP+ platform and a filing platform that are respectively connected to the card chip in communication.

[0041] This application provides a card application management method and a card application management system. By using a third-party filing platform to perform pre-processing code auditing of card applications, isolating the card applications in a pending-activation state after downloading, and combining this with a user-confirmed eSIM card security management method, it is possible to identify and block configuration files carrying malicious code. This prevents the automatic execution of malicious card applications on the card chip, thereby preventing the theft of sensitive information such as the user's IMSI (International Mobile Subscriber Identity) and keys. This avoids security issues such as eSIM card cloning and call fraud, ensuring the security of the eSIM ecosystem and the user's right to self-control.

[0042] Other features and advantages of this application will be set forth in the following description and will be apparent in part from the description or may be learned by practicing the application.

[0043] To make the above-mentioned objectives, features and advantages of this application more apparent and understandable, preferred embodiments are described below in detail with reference to the accompanying drawings. Attached Figure Description

[0044] To more clearly illustrate the technical solutions in the specific embodiments of this application or the prior art, the drawings used in the description of the specific embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of this application. For those skilled in the art, other drawings can be obtained from these drawings without creative effort.

[0045] Figure 1 A schematic diagram of a card application management system provided in an embodiment of this application; Figure 2 A flowchart illustrating a card application management method provided in an embodiment of this application; Figure 3 A flowchart illustrating the method for generating a filing certificate provided in this application embodiment; Figure 4 This is a flowchart illustrating the verification process of a card chip for a target card application, as provided in an embodiment of this application. Figure 5 Flowchart for switching the target card application to the enabled state provided in the embodiments of this application; Figure 6 The flowchart shows the process of the filing platform used in this application to verify the legality of the target card application.

[0046] Icons: 1-Card chip; 2-SM-DP+ platform; 3-Registration platform. Detailed Implementation

[0047] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0048] To facilitate understanding of this embodiment, the embodiments of this application will be described in detail below.

[0049] This application provides a card application management system for executing a card application management method, referring to... Figure 1 The card application management system provided in this application embodiment includes: an SM-DP+ platform 2 and a filing platform 3, which are respectively connected to the card chip 1 in communication.

[0050] Here, the card application management system includes SM-DP+ platform 2 (contract management data preparation platform), filing platform 3, and card chip 1. Both SM-DP+ platform 2 and filing platform 3 establish communication connections with card chip 1. Furthermore, SM-DP+ platform 2 and filing platform 3 can also establish communication connections.

[0051] SM-DP+ Platform 2 is used to prepare and distribute configuration files (also known as Profiles in the GSMA specification).

[0052] Specifically, the SM-DP+ platform 2 obtains the filing certificate (such as digital signature, hash value and version information) corresponding to the target card application from the filing platform 3, and packages the filing certificate together with the target card application (such as Applet) into the configuration file.

[0053] Subsequently, in response to the download request, the SM-DP+ platform 2 sends the configuration file containing the target card application and filing certificate to the card chip 1.

[0054] The filing platform 3 is acted by, for example, a GSMA certification body or other trusted third-party organization, to provide code security auditing, whitelist maintenance and security status verification services for card applications.

[0055] In one specific implementation, the filing platform 3 is configured to receive the application code corresponding to the target card application submitted by the operator or developer.

[0056] The filing platform 3 is configured to perform preset security audits on application code.

[0057] In one preferred embodiment, the default security audit includes static analysis. Static analysis is used to detect dangerous API calls and dangerous bytecode processing. In another preferred embodiment, the default security audit also includes dynamic sandbox testing. Dynamic sandbox testing simulates the JavaCard runtime environment and interacts with the card application through full instruction execution to capture potential malicious behavior.

[0058] The filing platform 3 is further configured such that if the preset security audit result is passed, a filing certificate is generated for the target card application and the filing certificate is sent to the SM-DP+ platform 2.

[0059] In a preferred embodiment, the filing credential may include: a unique filing identifier (such as a filing ID), a filing version number, a filing code hash value, and a digital signature generated by the filing platform's private key.

[0060] The filing platform 3 is also configured to communicate with the card chip 1 to perform subsequent security verification, activation, disabling or updating operations.

[0061] Card chip 1 can be an eUICC chip (embedded UICC) that is configured to support multiple profiles.

[0062] The operating system of card chip 1 includes a state management mechanism for card applications. Specifically, the states of card applications include at least: pending activation, activated, and disabled (or unavailable) states.

[0063] The "pending activation" status means that the card application has been successfully downloaded and the filing certificate has been verified, but it has not yet been activated and is in isolation, and cannot be selected or called by external parties.

[0064] The "enabled" status means that the card application has gone through the activation process and is in a normal and usable state.

[0065] A disabled status means that the card application has failed verification or has been marked as high-risk by the filing platform and is permanently or temporarily prohibited from use.

[0066] The card application is configured to receive and rigorously verify the card application registration certificate (including digital signature, code hash value and version number) issued by the SM-DP+ platform 2 using the pre-stored public key of the registration platform. After successful verification, the card application is placed in a secure pending state for isolation. Based on the subsequent received activation instructions, it will ultimately decide whether to switch it to the enabled state or the disabled state. It is also responsible for performing security enhancement functions such as blacklist synchronization interception and forced version update.

[0067] This application provides a card application management system that utilizes a filing platform to perform pre-application security audits on card applications, the SM-DP+ platform to issue configuration files containing filing credentials, and the card chip to place the card application in a pending-activation state for security isolation after the credential verification is passed, and only switches it to the activated state in response to subsequent activation commands. This can effectively intercept malicious or unverified code during the card application installation stage and prevent it from running automatically, thereby significantly enhancing the security of the card chip and preventing the leakage and malicious use of sensitive data.

[0068] Based on the above embodiments, this application provides a card application management method, applied to a card application management system, with reference to... Figure 2 A method for managing card applications, which includes: Step S101: The SM-DP+ platform sends the configuration file to the card chip; the configuration file contains the target card application and the corresponding filing certificate; the filing certificate is used to verify the security information of the target card application.

[0069] Here, the SM-DP+ platform prepares a configuration file for distribution to the card chip, which contains the user's subscription code number data and one or more target card applications.

[0070] The configuration file also includes a registration certificate. This certificate serves as proof that the target card application has passed a security audit or is security information from a trusted source.

[0071] In one embodiment, the registration credential may be generated by a trusted third-party registration platform after performing a rigorous security audit (e.g., static analysis, dynamic sandbox testing, etc.) on the target card application's code. The registration credential may be a complex data structure, such as containing the target card application's code hash, a unique registration ID, an application version number, and a digital signature generated by the registration platform using its private key.

[0072] In another embodiment, the registration credential can also be a simplified form of security information. For example, it could simply be a trusted code hash value calculated and published by the registration platform.

[0073] In another embodiment, the registration credential can be a security token issued or attached by the SM-DP+ platform itself. In this case, the SM-DP+ platform may maintain an internal whitelist of trusted applications or have already verified them with the registration platform. The SM-DP+ platform uses the attached security token to prove to the card chip that the target card application is trustworthy.

[0074] In other feasible embodiments, the filing credential can also be a digital certificate that conforms to specific standards, which binds the code signature of the target card application to a registered developer or operator identity.

[0075] In step S102, the card chip receives the configuration file and verifies the target card application based on the registration certificate.

[0076] In one embodiment, where the registration certificate includes a digital signature, hash value, and version number, the card chip first uses the platform public key of the registration platform, pre-stored within the chip, to decrypt and verify the digital signature in the registration certificate to confirm its authenticity and integrity. Next, the card chip uses the same preset hash algorithm as the registration platform to calculate the current code hash value of the received target card application's application code. Then, the card chip compares this current code hash value with the registration code hash value carried in the registration certificate, and simultaneously compares the current version number with the registration version number. Only when the digital signature verification passes, the code hash value matches, and the version number matches, is the verification result considered successful.

[0077] In another embodiment, when the registration certificate is a trusted hash value, the card chip calculates the code hash value of the received target card application and compares it with the hash value in the registration certificate. If they match, the verification is successful.

[0078] In another embodiment, when the filing credential is a digital certificate, the card chip verifies whether the certificate was issued by a trusted root CA (Certificate Authority, here the filing platform) and whether the certificate is valid and has not been revoked.

[0079] In other embodiments, if the card chip has network connectivity or can communicate with the filing platform via a terminal device, the verification step may further include: the card chip extracting the filing identifier ID from the filing certificate and initiating an online query request to the filing platform, which then returns in real time whether the ID is legal and valid.

[0080] Step S103: If the verification result is successful, the card chip sets the target card application to the ready-to-use state.

[0081] Here, the "pending activation" state means that the target card application's code has been securely stored on the card chip, but it is in an inactive and isolated mode. In this state, the target card application cannot be selected by external APDU (Application Protocol Data Unit Command), cannot run actively, and cannot interact with other card applications or the chip's operating system.

[0082] If the verification result fails (e.g., invalid digital signature, code hash value mismatch, or missing filing certificate), the card chip can choose to directly discard the target card application and refuse to install it, or mark it as disabled to achieve local interception.

[0083] In step S104, the card chip responds to the received enable command and switches the target card application from the pending enable state to the enabled state.

[0084] Here, the target card application, which is in a pending state, needs an activation command to be activated.

[0085] In a preferred embodiment, the activation command originates from the user's choice. For example, after the card chip sets the target card application to a pending state, the card chip can interact with the terminal device (e.g., through the LPA local configuration file assistant) to display a prompt on the device's UI (user interface) asking the user whether to activate the newly downloaded card application. Once the user confirms by clicking the enable button, the terminal device sends the activation command to the card chip. This grants the user ultimate control over the applications on the eSIM card.

[0086] In another embodiment, the activation command can originate from the registration platform. For example, the card chip or terminal device can upload the application's verification information (such as registration ID, hash value, etc.) to the registration platform for secondary verification. After confirming that the application has no security updates or high-risk vulnerabilities, the registration platform then issues an encrypted and signed activation command to the card chip.

[0087] In another embodiment, when the target card application involves high-risk operations (such as accessing sensitive data, modifying keys, etc.), the activation command can be a composite command. For example, the card chip needs to simultaneously receive a confirmation command from the user terminal (such as the user entering a PIN code or SMS verification code) and a platform confirmation command from the filing platform before it can be switched to the enabled state.

[0088] In other feasible embodiments, the activation command may also be a subsequent management command from the operator, or it may be automatically issued by the terminal device according to a preset security policy (e.g., automatically enabling all applications from the "operator").

[0089] Once the card chip receives a valid activation command, it switches the target card application from the pending activation state to the activated state. In the activated state, the card application becomes fully operable and can be selected and executed normally.

[0090] In an optional implementation, the filing certificate in step S101 refers to... Figure 3 It is generated in the following way.

[0091] Step S201: The filing platform receives the application code corresponding to the target card application.

[0092] Here, the provider of the target card application, such as an operator or a third-party developer, needs to submit the application code of its target card application to the filing platform.

[0093] In step S202, the filing platform performs a preset security audit on the application code of the target card application.

[0094] Here, upon receiving the application code, the filing platform executes a pre-defined and rigorous security audit process to ensure that the target card application does not contain malicious behavior or high-risk vulnerabilities. The pre-defined security audit preferably includes two phases: static analysis and dynamic sandbox testing, forming a dual security audit mechanism.

[0095] 1. Static Analysis Static analysis refers to scanning application code (such as the CAP package or bytecode of JavaCard) using techniques such as lexical analysis, syntax analysis, and data flow analysis without actually running the code, in order to detect dangerous API (interface) calls, dangerous bytecode processing, etc.

[0096] Static analysis primarily targets the following security risks: bypassing authentication, authorization, or access control; leaking keys, PIN codes (personal identification codes), or other sensitive data; illegally calling platform APIs, such as abusing cross-card application calls; exploiting design vulnerabilities in the APDU (Application Protocol Data Unit Protocol) protocol; leaving backdoor commands or debugging interfaces in the code; and using language features such as Java (e.g., reflection, serialization) to achieve secure sandbox escape or denial-of-service (DoS) attacks.

[0097] In a preferred embodiment, the static analysis security detection process may specifically include: (1) Authentication and permission isolation detection: Audit whether authentication checks are required before all sensitive operations (such as writing keys, PIN resets) (e.g., check for authentication code branches). At the same time, detect whether the card application exposes the shareable InterfaceObject to other unauthorized card applications, and perform backtracking analysis on the hot method call paths of cross-card applications.

[0098] (2) Sensitive data security detection: Perform full lifecycle tracking on sensitive data variables such as keys and PINs, check whether they are stored in transient memory, and whether they are cleared in time when not in use (e.g., through methods such as Util.arrayFillNonAtomic) to prevent data residue. At the same time, perform boundary checks on all accesses to APDU buffers or input parameters to avoid out-of-bounds access and information leakage.

[0099] (3) API usage and blacklist mechanism detection: Static detection and prohibition of applications from directly or indirectly using insecure APIs in the platform blacklist, such as System.arraycopy (which requires special attention when using cross-card applications), Class.forName, reflection, serialization, threads, etc. At the same time, unauthorized service registration and external interface exposure are prohibited.

[0100] (4) Backdoor detection and coding standard inspection: Formulate static rules to find backdoor branches such as "hidden commands", "special constants" (such as if 0xDEADBEEF), and "super PIN" in the code. Analyze whether there are any public methods exposed to the outside without protection. At the same time, check the encapsulation of sensitive member variables (such as whether private / protected is used correctly).

[0101] (5) Logic Anomaly and Anomaly Handling Detection: Analyze the anomaly capture and handling of sensitive methods. Security checks must capture all unexpected anomalies and handle them with generic error codes to avoid returning sensitive internal information (such as stack traces) to the outside during anomalies. Simultaneously, analyze paths such as loops, recursion, and object creation to avoid DoS paths that could cause the card chip to crash or exhaust resources.

[0102] 2. Dynamic Sandbox Testing Dynamic sandbox testing refers to the full-process, full-command interaction with the target card application in a controlled, simulated JavaCard runtime environment through automated or semi-automated methods. By monitoring the card application's resource consumption, abnormal triggers, authorization failures, and other security-sensitive points during operation in real time, it can capture potential malicious behaviors and check whether the card application has unauthorized access, information leakage, backdoors, or DoS attacks.

[0103] In a preferred embodiment, the dynamic sandbox testing process may specifically include: (1) Load the application of the card to be tested: Use tools such as JCardSim (Java card simulator) or smart card tester to load the CAP package to be risk assessed into the sandbox environment.

[0104] (2) Batch / scripted APDU instruction generation and automatic interaction: Use tools such as Python and Java to write automated scripts to repeatedly send APDU instruction packets to the functional boundaries and error flows (such as sending short packets, wrong packets, and illegal data input) of the target card application, and analyze the returned data in real time.

[0105] (3) Monitoring resources and events: During the interaction process, the running logs, memory usage, exception stack information, and returned status codes of the card application are collected.

[0106] (4) Analyze behavioral patterns: Check whether sensitive paths are triggered. For example, whether sensitive data is returned without authorization, whether internal state is exposed when an internal exception occurs, and whether resources are not released. Focus on identifying behaviors such as "universal PINs" (e.g., trying common passwords like 123456, 000000), "special commands," and leakage of stack information when exceptions are thrown. At the same time, simulate DoS attacks (e.g., infinite loop calls, sending extremely large data packets) to test its resource limitations and controlled exception handling capabilities. In addition, it is also necessary to check the consistency of shared interface calls and bytecode and data types.

[0107] Common test cases are shown in Table 1 below.

[0108] Table 1 Common Test Cases

[0109] Step S203: If the preset security audit result is passed, the filing platform generates a filing certificate for the target card application and sends the filing certificate to the SM-DP+ platform.

[0110] Here, the filing platform will only recognize the audit result as passed if the target card application passes both static analysis and dynamic sandbox testing.

[0111] At this point, the filing platform will generate a unique filing certificate for the target card application. In a preferred embodiment, the filing certificate may contain rich information, such as a unique filing ID, the filing version number of the current card application, the hash value of the filing code calculated by a hash algorithm, a digital signature generated by the filing platform's private key, and a summary of an evaluation report, etc.

[0112] After generating the filing certificate, the filing platform sends the filing certificate to the SM-DP+ platform. When the SM-DP+ platform subsequently issues the configuration file, it will package this filing certificate together with the corresponding target card application and send them to the card chip for verification.

[0113] In an optional implementation, the card chip pre-stores the platform public key corresponding to the filing platform; the filing certificate includes the filing version number, the filing code hash value, and the digital signature.

[0114] Here, the card chip is programmed with the public key of the filing platform during the chip manufacturing or initialization stage. The platform public key is public and corresponds to the private key held by the filing platform; it is specifically used to verify the authenticity of the filing certificate.

[0115] A filing certificate is a data structure generated and signed by the filing platform after auditing. In this embodiment, the filing certificate specifically includes: a filing version number, a filing code hash value, and a digital signature.

[0116] The filing version number refers to the trusted version of the target card application registered on the filing platform.

[0117] The hash value of the filing code refers to the hash digest calculated by the filing platform from the original text of the audited application code during the audit process.

[0118] Digital signature refers to the process by which a filing platform uses its private key to sign important information in a filing certificate (such as the filing code hash and filing version number) to prevent the certificate from being forged or tampered with.

[0119] Reference Figure 4 Step S102 includes the following steps S301-S305.

[0120] Step S301: The card chip receives the configuration file and obtains the current version number and application code of the target card application from the filing certificate contained in the configuration file.

[0121] Here, the card chip receives the configuration file from the SM-DP+ platform. The card chip then parses the configuration file, extracting the application code of the target card application (e.g., the CAP package of an Applet) and the registration credentials associated with the target card application.

[0122] In step S302, the card chip verifies the digital signature based on the platform's public key to obtain the digital signature verification result.

[0123] Here, the card chip decrypts and verifies the digital signature extracted from the filing certificate based on the pre-stored platform public key, confirming that the filing certificate was indeed issued by a trusted filing platform and that the certificate content has not been tampered with during transmission.

[0124] If digital signature verification fails, the registration certificate is considered invalid, subsequent verification steps will be terminated, and the verification result will be "failed." If verification is successful, a successful digital signature verification result will be obtained.

[0125] Step S303: The card chip parses the application code and calculates the current code hash value corresponding to the target card application according to the preset hash algorithm.

[0126] Here, after confirming the credibility of the filing certificate itself, the card chip needs to confirm whether the application code in the configuration file is the credible code guaranteed by the filing certificate.

[0127] The card chip parser extracts the original application code of the target card application from the configuration file.

[0128] The card chip uses a preset hash algorithm (the same algorithm used by the filing platform to generate the filing code hash value) to calculate the complete content of the application code and obtain a current code hash value.

[0129] The current code hash value represents the digital fingerprint of the application code actually received by the card chip.

[0130] In step S304, the card chip determines whether the current code hash value is consistent with the filing code hash value, and at the same time, determines whether the current version number is consistent with the filing version number.

[0131] Here, the card chip reads the registration code hash value from the registration certificate and compares it with the calculated current code hash value. The two must be completely identical to prove that the application code received by the card chip is consistent with the original code that was audited and approved by the registration platform at the time.

[0132] Simultaneously, the card chip also retrieves the current version number from the application code's metadata or registration certificate and compares it with the registration version number recorded in the registration certificate. This ensures that the downloaded application is not only correct in its code content but also in its version.

[0133] Step S305: If the current code hash value is consistent with the filing code hash value, the current version number is consistent with the filing version number, and the digital signature verification result is passed, then the verification result is determined to be passed.

[0134] Here, if the digital signature verification result is successful, and the current code hash value is consistent with the filing code hash value, and the current version number is consistent with the filing version number, then the card chip determines that the verification result is successful.

[0135] If any one of these conditions is not met, the verification result will be a failure.

[0136] In an optional implementation, the filing credential includes a filing identifier. Here, the filing credential includes at least one unique filing identifier (e.g., a filing ID).

[0137] Reference Figure 5 The method further includes the following steps S401-S404.

[0138] In step S401, in response to the received disable instruction, the card chip uploads the verification information of the target card application to the filing platform; the verification information includes the filing identifier of the target card application, the current version number, and the current code hash value.

[0139] In a preferred embodiment, the disable command can be initiated by the user through the device's user interface. For example, after the card chip sets the target card application to a pending state, the terminal device interface may prompt the user "Enable new Applet?". At this time, the user can choose options such as "Do not enable for now" or "Submit for platform verification," which will send a disable command to the card chip.

[0140] In other embodiments, disabling the instruction can also be a system-preset strategy, for example, automatically triggered for all newly installed applications before the user explicitly enables it.

[0141] In response to the instruction not being enabled, the card chip will upload the verification information it acquired or generated during the local verification phase to the filing platform via a secure channel.

[0142] The verification information should include at least: the filing identifier (used for quick indexing by the platform), the current version number, and the current code hash value.

[0143] Step S402: The filing platform verifies the legality of the target card application based on the verification information.

[0144] Here, after receiving the verification information from the card chip, the filing platform will perform a server-side legality verification.

[0145] In a preferred embodiment, the registration platform and the card chip preferably perform a two-way authentication first to ensure the credibility of the identities of both parties and prevent man-in-the-middle attacks.

[0146] In an optional implementation, refer to Figure 6 Step S402 includes the following steps S501-S505.

[0147] Step S501: The filing platform determines whether the filing identifier exists in the filing record.

[0148] Here, the filing platform uses the filing identifier uploaded by the card chip to query its internally maintained card application whitelist database or filing records to verify the legitimacy of the target card application. If the filing identifier cannot be found in the filing records, it proves that the target card application has never undergone a security audit by the filing platform and is an unknown or illegal application. The filing platform will directly determine that the legitimacy verification has failed.

[0149] Step S502: If the filing identifier exists in the filing record, determine whether the current version number is consistent with the filing version number.

[0150] Here, if the registration identifier is confirmed to be registered, the registration platform will extract all audited version information corresponding to the identifier in the registration record. The registration platform will compare the current version number uploaded by the card chip with the registered version number in the registration record to verify whether the version of the target card application is a registered and trusted version. If the version number does not match, for example, if it is an obsolete old version or a new version that has not yet been submitted for registration, the registration platform will determine that the legality verification has failed.

[0151] Step S503: If the current version number is consistent with the filed version number, determine whether there is a security update for the current version number.

[0152] Here, if the version number is also confirmed as a registered and trusted version, the registration platform queries its security vulnerability database or update records to determine whether the target application for that version number has been found to have new security vulnerabilities after its original registration was approved. In other words, it determines whether the version number currently corresponds to a state where a security update exists.

[0153] If the filing platform finds that the version has been marked as having a vulnerability or that a patched version already exists (i.e., a security update is available), the filing platform will determine that the legitimacy verification has failed, in order to prevent the card chip from activating a known dangerous application.

[0154] Step S504: If there is no security update for the current version number, determine whether the current code hash value is consistent with the filing code hash value.

[0155] Here, if the target card application not only has the correct version number but is also currently deemed secure by the platform (no security updates are available), the filing platform will compare the current code hash value uploaded by the card chip with the unique filing code hash value stored in the filing record that corresponds to the filing version number, bit by bit. This verifies whether the original application code actually installed on the card chip is completely consistent with the original code submitted to the filing platform and passed the audit. If the hash values ​​do not match, the filing platform will determine that the legality verification has failed.

[0156] Step S505: If the current code hash value is consistent with the filing code hash value, the legality verification result is determined to be successful, and the legality verification result is sent to the card chip.

[0157] Here, the filing platform will only determine the legality verification result as passed when all the checks are passed in sequence.

[0158] After confirming the result, the filing platform will send the legality verification result (i.e., verification passed or verification failed) to the card chip.

[0159] Step S403: If the legality verification result is successful, the filing platform sends an activation command to the card chip.

[0160] Here, the filing platform sends different instructions to the card chip based on the verification results.

[0161] If the legality verification result is successful, that is, the filing platform confirms that the card application has indeed been filed, and that the version is correct, the hash value is consistent, and there are currently no known security updates or vulnerabilities.

[0162] At this point, the registration platform generates and sends an activation command to the card chip. In a preferred embodiment, the activation command is an encrypted ciphertext command to ensure the security of the activation process.

[0163] In step S404, the card chip responds to the activation command and switches the target card application from the pending activation state to the activated state.

[0164] Here, the card application returns to a normal, usable state.

[0165] In an optional implementation, after step S402, the method further includes: If the legality verification fails, the filing platform sends a disabling command to the card chip.

[0166] The card chip responds to the disable command and switches the target card application from the pending enable state to the disabled state.

[0167] Here, if the legality verification fails, it means the filing platform has detected an anomaly in the application. For example, the filing identifier may not exist (unfiled), the hash value may not match (the code may have been tampered with), or the version may have been flagged by the filing platform as having a high-risk vulnerability.

[0168] At this point, the filing platform will generate and send a disable command to the card chip.

[0169] In response to a disable command, the card chip switches the target card application from a pending activation state to a disabled state. In one embodiment, the disabled state can be permanent, with the card chip marking it as a malicious application and prohibiting any subsequent activation attempts. In another embodiment, the disabled state can also be temporary, in which case the card chip can further prompt the user to delete the target card application to free up chip resources and eliminate security risks.

[0170] In an optional implementation, when the target card application is a high-risk application that meets preset conditions, the step of switching the target card application from the pending state to the enabled state includes the following steps S601-S602.

[0171] In step S601, the card chip sends authentication requests to the user terminal and the filing platform respectively.

[0172] Here, when the process of activating a high-risk application is triggered (for example, when a user clicks the "Enable" button on the UI), the card chip does not immediately switch it to the enabled state, but instead initiates the two-factor authentication process.

[0173] The card chip may send authentication requests simultaneously or sequentially to two different entities (the user terminal and the filing platform): 1. Send an authentication request to the user terminal to obtain explicit confirmation from the user. For example, the card chip may trigger a high-priority security prompt through the terminal device, or require the user to enter a one-time SMS confirmation code, to ensure that the user is fully aware of and agrees to activate this high-risk application.

[0174] 2. Send an authentication request to the filing platform to obtain real-time authorization. The filing platform will then re-verify the status of the high-risk application, such as confirming that the application's signature is still trustworthy, or confirming that calls to the sensitive API are permitted under the current security policy.

[0175] Step S602: If the card chip receives a terminal confirmation instruction returned by the user terminal and a platform confirmation instruction returned by the filing platform, the target card application in the pending activation state will be switched to the activated state.

[0176] Here, the card chip awaits responses from two entities (the user terminal and the filing platform).

[0177] The card chip receives a terminal confirmation command from the user terminal, indicating that the user has passed strong authentication (such as entering an SMS verification code or confirming a high-risk warning) and explicitly agrees to activation.

[0178] The card chip also receives a platform confirmation instruction from the filing platform, indicating that the filing platform has also authorized this activation from a management and security perspective.

[0179] Only when the card chip successfully receives both the terminal confirmation command and the platform confirmation command within the predetermined time will the card chip finally determine that the activation conditions are met, and then switch the high-risk target card application from the pending activation state to the activated state.

[0180] If either of the two instructions is not received (for example, the user cancels the confirmation, or the filing platform refuses the authorization), the target card application will remain in an enabled state or be switched to a disabled state, thereby preventing accidental or malicious activation of high-risk applications.

[0181] In an optional implementation, the method further includes the following steps S701-S702.

[0182] Step S701: The card chip synchronizes blacklist data from the filing platform based on a preset time interval; the blacklist data includes the blacklist code hash value corresponding to illegal or high-risk card applications.

[0183] Here, the card chip is configured to actively or passively (e.g., pushed by the platform) synchronize the latest blacklist data from the filing platform based on a preset time interval (e.g., periodically, such as daily, weekly, or every time a network is connected).

[0184] The blacklist data includes a series of blacklist code hash values ​​corresponding to illegal or high-risk card applications. These hash values ​​are digital fingerprints of applications that have been identified as malicious card applications or applications with serious security vulnerabilities, accumulated by the filing platform through continuous auditing, vulnerability discovery, or security incident response.

[0185] The card chip stores the acquired blacklist data in a local secure storage area.

[0186] In step S702, when the card chip receives the configuration file, if it detects that the current code hash value of the target card application is consistent with the blacklist code hash value, it sets the target card application to a disabled state.

[0187] Here, after the card chip receives the configuration file from the SM-DP+ platform, it will first perform a local blacklist check.

[0188] The card chip parses the application code of the target card application contained in the configuration file and calculates the current code hash value of the target card application according to the preset hash algorithm.

[0189] The card chip compares the current code hash value calculated in the previous step with all the blacklist code hash values ​​in its locally stored blacklist data.

[0190] If the current code hash value is detected to match a blacklist code hash value, it proves that the target card application is a known malicious or illegal application.

[0191] At this point, the card chip will no longer perform subsequent verification of the registration certificate, but will directly perform a local interception and installation operation, that is, immediately set the target card application to a disabled state. The disabled state is preferably permanently unavailable.

[0192] If the hash value is not detected in the blacklist, the card chip continues to perform the normal verification process.

[0193] In an optional implementation, the method further includes the following steps S801-S804.

[0194] Step S801: The filing platform performs a preset security audit on the application code of the target card application based on a preset detection cycle.

[0195] Here, the filing platform not only performs a security audit when the card application is first submitted, but also re-examines or regresses the application code of the target card applications already in its filing database based on a preset detection cycle (e.g., periodically, or when new security threat intelligence is received).

[0196] Pre-defined security audits are similar to the aforementioned audit processes and may include methods such as static analysis and dynamic sandbox testing to continuously utilize the latest security knowledge bases and vulnerability models to identify previously undiscovered potential risks.

[0197] Step S802: If the preset security audit result indicates the existence of a vulnerability, the filing platform generates a patch version of the target card application based on the vulnerability and updates the filing certificate corresponding to the target card application.

[0198] Here, if during periodic audits, the filing platform discovers a vulnerability in a filed target card application.

[0199] At this point, the filing platform will (or notify its developers) generate a patched version of the target card application that fixes the vulnerability.

[0200] After the patch version is generated, it undergoes a full security audit by the filing platform. Once the audit is passed, the filing platform will generate a completely new filing certificate for this new patch version. The new filing certificate will contain a new filing version number and a new filing code hash value for the corresponding patch version code, and will be re-signed by the filing platform.

[0201] In step S803, the filing platform generates an update instruction based on the patch version and sends the update instruction to the card chip.

[0202] Here, after confirming that the patch version and its new filing certificate are ready, the filing platform will automatically generate an update command.

[0203] An update command is a remote management command that contains the target card application code for the patch version, as well as its corresponding new registration certificate (or a secure path containing the data to be downloaded).

[0204] The filing platform will remotely push and send the update instruction through a secure communication channel to all card chips that have installed the old version of the application with the vulnerability.

[0205] In step S804, the card chip receives the update instruction and replaces the current version of the target card application with the patched version of the target card application.

[0206] Here, after receiving the update instruction from the filing platform, the card chip will perform a forced update operation.

[0207] In a preferred embodiment, the card chip performs rigorous verification of the patch version and its registration credentials included in the update instruction (e.g., verifying the digital signature, checking the code hash value, etc.) as if performing an initial installation verification, to ensure that the patch itself is trustworthy and has not been tampered with.

[0208] After verification, the card chip performs a replacement operation, which means replacing the target card application with the patched version stored on the chip that currently has the vulnerability.

[0209] This application provides a card application management method that establishes a secure closed-loop management process that includes pre-audit, in-process isolation, and post-confirmation or two-factor activation for high-risk applications. This prevents unverified malicious card applications from automatically executing after download. Through security enhancements such as local blacklist synchronization and remote forced updates, the method ensures that the card chip can withstand various security threats from the installation stage to its entire lifecycle, preventing sensitive data leakage, eSIM card cloning, and enhancing user self-control.

[0210] The computer program product provided in this application includes a computer-readable storage medium storing program code. The instructions included in the program code can be used to execute the methods described in the preceding method embodiments. For specific implementation details, please refer to the method embodiments, which will not be repeated here.

[0211] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working process of the system and apparatus described above can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.

[0212] Furthermore, in the description of the embodiments of this application, unless otherwise expressly specified and limited, the terms "installation," "connection," and "linking" should be interpreted broadly. For example, they can refer to a fixed connection, a detachable connection, or an integral connection; they can refer to a mechanical connection or an electrical connection; they can refer to a direct connection or an indirect connection through an intermediate medium; and they can refer to the internal connection of two components. Those skilled in the art can understand the specific meaning of the above terms in this application based on the specific circumstances.

[0213] If the aforementioned functions are implemented as software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a portion 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.) to execute all or part of the steps of the methods described in the various embodiments of this application. 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.

[0214] In the description of this application, it should be noted that the terms "center," "upper," "lower," "left," "right," "vertical," "horizontal," "inner," and "outer," etc., indicate the orientation or positional relationship based on the orientation or positional relationship shown in the accompanying drawings. They are used only for the convenience of describing this application and simplifying the description, and do not indicate or imply that the device or element referred to must have a specific orientation, or be constructed and operated in a specific orientation. Therefore, they should not be construed as limitations on this application. Furthermore, the terms "first," "second," and "third" are used for descriptive purposes only and should not be construed as indicating or implying relative importance.

[0215] Finally, it should be noted that the above-described embodiments are merely specific implementations of this application, used to illustrate the technical solutions of this application, and not to limit them. The protection scope of this application is not limited thereto. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that any person skilled in the art can still modify or easily conceive of changes to the technical solutions described in the foregoing embodiments within the scope of the technology disclosed in this application, or make equivalent substitutions for some of the technical features. Such modifications, changes, or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application, and should all be covered within the protection scope of this application.

Claims

1. A method for managing card applications, characterized in that, A management system for card applications, the management system comprising an SM-DP+ platform and a card chip connected in communication; the method comprising: The SM-DP+ platform sends a configuration file to the card chip; the configuration file contains the target card application and the filing certificate corresponding to the target card application; the filing certificate is used to verify the security information of the target card application. The card chip receives the configuration file and verifies the target card application based on the registration certificate; If the verification result is successful, the card chip will set the target card application to a pending state; In response to the received activation command, the card chip switches the target card application from the pending activation state to the activated state.

2. The card application management method according to claim 1, characterized in that, The card application management system also includes a filing platform that is communicatively connected to both the card chip and the SM-DP+ platform; the filing certificate is generated in the following manner: The filing platform receives the application code corresponding to the target card application; The filing platform performs a preset security audit on the application code of the target card application; If the preset security audit results are passed, the filing platform generates the filing certificate for the target card application and sends the filing certificate to the SM-DP+ platform.

3. The card application management method according to claim 2, characterized in that, The card chip pre-stores the platform public key corresponding to the filing platform; the filing certificate includes a filing version number, a filing code hash value, and a digital signature. The steps of the card chip receiving the configuration file and verifying the target card application based on the registration certificate include: The card chip receives the configuration file and obtains the current version number and application code of the target card application from the filing certificate contained in the configuration file; The card chip verifies the digital signature based on the platform's public key to obtain a digital signature verification result; The card chip parses the application code and calculates the current code hash value corresponding to the target card application according to a preset hash algorithm; The card chip determines whether the current code hash value is consistent with the filing code hash value, and at the same time, determines whether the current version number is consistent with the filing version number; If the current code hash value is consistent with the filing code hash value, the current version number is consistent with the filing version number, and the digital signature verification result is passed, then the verification result is determined to be passed.

4. The card application management method according to claim 1, characterized in that, The card application management system also includes a filing platform that is communicatively connected to both the card chip and the SM-DP+ platform; the filing credential includes a filing identifier; the method further includes: In response to the received disable instruction, the card chip uploads the verification information of the target card application to the filing platform; the verification information includes the filing identifier, current version number, and current code hash value of the target card application; The filing platform verifies the legality of the target card application based on the verification information; If the legality verification result is successful, the filing platform sends an activation command to the card chip; In response to the activation command, the card chip switches the target card application from the pending activation state to the activated state.

5. The card application management method according to claim 4, characterized in that, After the step of the filing platform performing legality verification on the target card application based on the verification information, the method further includes: If the legality verification result is a verification failure, the filing platform sends a disable command to the card chip; In response to the disable command, the card chip switches the target card application, which is in the pending enable state, to the disabled state.

6. The card application management method according to claim 4, characterized in that, The steps by which the filing platform verifies the legitimacy of the target card application based on the verification information include: The filing platform determines whether the filing identifier exists in the filing record; If the filing identifier exists in the filing record, determine whether the current version number is consistent with the filing version number; If the current version number is the same as the filed version number, determine whether there is a security update for the current version number; If the current version number does not have the security update, determine whether the current code hash value is consistent with the filing code hash value; If the current code hash value matches the filing code hash value, the legality verification result is determined to be successful, and the legality verification result is sent to the card chip.

7. The card application management method according to claim 1, characterized in that, The card application management system also includes a filing platform that is communicatively connected to both the card chip and the SM-DP+ platform. When the target card application is a high-risk application that meets preset conditions, the step of switching the target card application from the pending activation state to the activated state includes: The card chip sends authentication requests to the user terminal and the filing platform respectively; If the card chip receives a terminal confirmation instruction returned by the user terminal and a platform confirmation instruction returned by the filing platform, it will switch the target card application from the pending activation state to the activated state.

8. The card application management method according to claim 1, characterized in that, The card application management system also includes a filing platform that is communicatively connected to both the card chip and the SM-DP+ platform. The method further includes: The card chip synchronizes blacklist data from the filing platform at preset time intervals; the blacklist data includes blacklist code hash values ​​corresponding to illegal or high-risk card applications; When the card chip receives the configuration file, if it detects that the current code hash value of the target card application is consistent with the blacklist code hash value, it will set the target card application to a disabled state.

9. The card application management method according to claim 1, characterized in that, The card application management system also includes a filing platform that is communicatively connected to both the card chip and the SM-DP+ platform. The method further includes: The filing platform performs a preset security audit on the application code of the target card application based on a preset detection cycle; If the audit result of the preset security audit is that a vulnerability exists, the filing platform generates a patched version of the target card application based on the vulnerability and updates the filing certificate corresponding to the target card application. The filing platform generates an update instruction based on the patch version and sends the update instruction to the card chip; The card chip receives the update instruction and replaces the current version of the target card application with the patched version of the target card application.

10. A card application management system, characterized in that, The management system for executing the card application management method according to any one of claims 1-9 includes: an SM-DP+ platform and a filing platform that are respectively communicatively connected to the card chip.

Images