Upgrading method, system and equipment of smart card application applet and medium

Abstract

The invention provides a smart card application applet upgrading method, system and device and a medium, and relates to the technical field of computers, and the method comprises the steps: configuring an application version identifier of a smart card application applet based on an upgrading version; downloading the application program of the new version to a security chip in which the application program of the old version runs; selecting a new-version application program instance, sending a data migration command to the new-version application program, and triggering the new-version application program to read application data from the old-version application program; after the data migration succeeds, the application applet of the intelligent card is successfully upgraded, the new-version application program takes effect, and the old-version application program fails. According to the application, it can be ensured that service providing of the application applet is not affected when the upgrading service is interrupted at any moment, it is ensured that only one application program is effective at any moment, and therefore the use experience of a user is ensured.

Description

Technical Field

[0001] The present application relates to the field of computer technology, and in particular to a method, system, device and medium for upgrading a smart card application applet. Background Art

[0002] Smart card application applet refers to an application running on the JavaCard operating system. Smart cards are widely used in mobile phones, automobiles, and telecommunications. Smart card application applet is implemented in accordance with the Global Platform (GP) specification. Different from the firmware upgrade of traditional embedded chips (directly flashing the firmware area through the burning interface), smart cards that comply with the GP specification need to use other methods, such as APDU instruction encapsulation, to transmit the new version of the application to replace the old version of the application.

[0003] However, the GP specification upgrade solution has a disadvantage, that is, the interruption of the upgrade process may cause the application to be unavailable. This mechanism requires that once the user chooses to upgrade, the entire upgrade process must be successfully completed. If the upgrade process is interrupted, it must be retried until it succeeds. This method will cause the interruption of the use of smart card applications during the upgrade process, which greatly affects the user experience. Summary of the invention

[0004] The purpose of this application is to provide a method, system, device and medium for upgrading a smart card application applet to alleviate the above-mentioned technical problems existing in the prior art.

[0005] In a first aspect, the present invention provides a method for upgrading a smart card application applet, the method comprising:

[0006] An application version identifier of the smart card application applet is configured based on the upgraded version;

[0007] Download the new version of the application to the security chip running the old version of the application;

[0008] Select the new version application instance, send a data migration command to the new version application, and trigger the new version application to read application data from the old version application;

[0009] When the data is successfully migrated, the smart card application applet is successfully upgraded, the new version of the application takes effect, and the old version of the application becomes invalid.

[0010] In an optional embodiment, the method further comprises:

[0011] If the data migration fails and / or the smart card application applet upgrade fails, the old version of the application remains valid.

[0012] In an optional implementation, configuring the application version identifier of the smart card application applet based on the upgraded version includes:

[0013] Define a preset byte of the application version identifier of the smart card application applet as a version number byte;

[0014] Determine the version identifier of the version number byte according to the version number of the upgraded version;

[0015] An application version identifier of the smart card application applet is configured based on the identity byte information and the version identifier of the smart card application applet.

[0016] In an optional implementation, the preset bytes of the application version identifier of the smart card application applet are defined as version number bytes, including:

[0017] The last byte of the application version identifier of the smart card application applet is defined as the version number byte.

[0018] In an optional implementation, the first version identifier corresponding to the new version application is different from the second version identifier corresponding to the old version application.

[0019] In an optional implementation, selecting a new version application instance, sending a data migration command to the new version application, and triggering the new version application to read application data from the old version application includes:

[0020] In the new version application, traverse the application version identifiers of all supported old version applications to find the application version identifier corresponding to the correct old version application;

[0021] In response to the interface call of the new version application, the old version application reads the application data to be migrated from the storage, returns it to the new version application through the preset shared interface, and allows the new version application to switch the status of the old version application to migrated out through the preset shared interface;

[0022] The new version application obtains the preset shared object according to the application version identifier found, and exports the application data from the old version application according to the data reading method pre-agreed between the new and old versions of the application;

[0023] The new version of the application verifies the data format of the application data and performs data migration after confirming that the read application data is correct;

[0024] When all application data is successfully migrated, the new version of the application switches the status of the old version of the application to migrated out, and switches its own status to normal service status.

[0025] In an optional embodiment, the method further comprises:

[0026] If the upgrade process is interrupted and there are two applications in the security chip, select one application first and determine the selection result;

[0027] If the application feedback is normal, continue with the subsequent business process;

[0028] If the application reports that the application data has been migrated out, the next application is selected using the command, and the application is the new version of the application that takes effect;

[0029] After the selection is successful, business processing will continue through the effective new version of the application.

[0030] In a second aspect, the present invention provides a smart card application applet upgrade system, the system comprising:

[0031] A configuration module, configured to configure an application version identifier of the smart card application applet based on the upgraded version;

[0032] A download module, used to download a new version of the application to a security chip running an old version of the application;

[0033] A migration module is used to select a new version application instance, send a data migration command to the new version application, and trigger the new version application to read application data from the old version application;

[0034] The upgrade module is used to upgrade the smart card application applet successfully after the data migration is successful, the new version of the application is effective, and the old version of the application is invalid.

[0035] In a third aspect, the present invention provides an electronic device including a processor and a memory, wherein the memory stores computer executable instructions that can be executed by the processor, and the processor executes the computer executable instructions to implement the method for upgrading the smart card application applet of any of the aforementioned implementation modes.

[0036] In a fourth aspect, the present invention provides a computer-readable storage medium storing computer-executable instructions. When the computer-executable instructions are called and executed by a processor, the computer-executable instructions prompt the processor to implement the method for upgrading the smart card application applet of any of the aforementioned implementation modes.

[0037] The beneficial effects of the smart card application applet upgrade method, system, device and medium provided by the present application are as follows:

[0038] First, configure the application version identifier of the smart card application applet based on the upgraded version, and then download the new version of the application to the security chip running the old version of the application. Select the new version of the application instance, send a data migration command to the new version of the application, trigger the new version of the application to read the application data from the old version of the application, and when the data migration is successful, the smart card application applet is successfully upgraded, the new version of the application takes effect, and the old version of the application becomes invalid. In this way, it can be ensured that any interruption of the upgrade business at any time will not affect the service provided by the application applet, ensuring that only one application is valid at any time, thereby ensuring the user experience. BRIEF DESCRIPTION OF THE DRAWINGS

[0039] In order to more clearly illustrate the specific implementation methods of the present application or the technical solutions in the prior art, the drawings required for use in the specific implementation methods or the description of the prior art will be briefly introduced below. Obviously, the drawings described below are some implementation methods of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative work.

[0040] Figure 1 A flowchart of a method for upgrading a smart card application applet provided in an embodiment of the present application;

[0041] Figure 2 A structural diagram of a smart card application applet upgrade system provided in an embodiment of the present application;

[0042] Figure 3 A structural diagram of an electronic device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0043] In order to make the purpose, technical solution and advantages of the embodiments of the present application clearer, the technical solution in the embodiments of the present application will be clearly and completely described below in conjunction with the drawings in the embodiments of the present application. Obviously, the described embodiments are part of the embodiments of the present application, rather than all the embodiments. The components of the embodiments of the present application described and shown in the drawings here can be arranged and designed in various different configurations.

[0044] Therefore, the following detailed description of the embodiments of the present application provided in the accompanying drawings is not intended to limit the scope of the present application for which protection is sought, but merely represents selected embodiments of the present application. Based on the embodiments in the present application, all other embodiments obtained by ordinary technicians in the field without creative work are within the scope of protection of the present application.

[0045] It should be noted that similar reference numerals and letters denote similar items in the following drawings, and therefore, once an item is defined in one drawing, further definition and explanation thereof is not required in subsequent drawings.

[0046] Smart cards have a unique security protection mechanism. From hardware design to software implementation, they have different security protection measures. They are extremely secure and are often used to protect sensitive data such as personal information and security keys. The JavaCard operating system supports running multiple application applets and supports dynamic management of application applets, such as deletion, downloading, and updating. However, the management of smart card application applets must be implemented in accordance with the Global Platform (GP) specification, through specific data interaction protocols (ISO7816 & ISO14443) and communication interfaces (SPI, ISO7816), etc., to enable external devices / host computers and smart cards to interact through APDU. According to the definition of the GP specification, security authentication commands are transmitted through APDU to obtain management permissions, and then management instruction APDUs are assembled for application management.

[0047] Appendix H of the GP specification, "Executable Load File Upgrade Card Specification v2.3–Amendment H", describes an upgrade solution for smart card applications (Executable Load File, ELF). The general logic of this solution is:

[0048] 1. Transfer the data of the old version of the application to the system storage area.

[0049] 2. Delete the old version of the application.

[0050] 3. Download the new version of the application and instantiate it.

[0051] 4. Import the application data in the system storage area into the new version application to complete the upgrade process.

[0052] However, the current GP specification upgrade solution has a disadvantage, that is, the interruption of the upgrade process may cause the application to be unavailable. When step 1 is completed, the old version of the application enters the upgraded state, and the application function is unavailable. Until step 4 is completed, the new version of the application cannot be used. This mechanism requires that once the user chooses to upgrade, the entire upgrade process must be successfully completed. If the upgrade process is interrupted, it must be retried until it succeeds. For automotive digital key scenarios, OTA upgrades are common, but because the upgrade environment on the vehicle side is complex and there are many upgrade components, upgrade interruptions are very likely to occur. If the user's digital key is unusable due to abnormal circumstances, it will seriously affect the user experience.

[0053] Based on this, the embodiment of the present application provides a smart card application applet upgrade method, system, device and medium, which can turn the switching action between the old and new versions of the application into an atomic operation, that is, if the switch is successful, the new application takes effect; if the switch fails, the old application remains valid. This ensures that only one application is valid at any time, and ensures that any interruption of the upgrade service at any time will not affect the service provided by the application applet, thereby ensuring the user experience.

[0054] The present application embodiment provides a method for upgrading a smart card application applet, see Figure 1 As shown, the method mainly includes the following steps:

[0055] Step S110: configuring an application version identifier of the smart card application applet based on the upgraded version.

[0056] The application version identifier is a unique identifier for identifying the application version. In one embodiment, when applied to a JavaCard operating system and following the GP specification, the application version identifier may be a package aid / instance aid of the application in the security chip.

[0057] When the upgrade is implemented, there is an old version of the application in the current security chip, and the new version of the application is downloaded to the security chip. According to the definition of the GP specification, the package aid / instance aid of the application in the security chip must be unique. It is not feasible to use the same package aid / instance aid as the old version of the application. Therefore, the embodiment of the present application configures the application version identifier of the smart card application applet based on the upgraded version.

[0058] In one example, for example, the application version identifier corresponding to the first application version may be 01, 0A, 0a, etc., and the application version identifier corresponding to the second application version may be 02, 0B, 0b, etc. In actual applications, adaptive adjustments may be made according to actual conditions, which is only an example and not specifically limited here.

[0059] Step S120, downloading the new version of the application to the security chip running the old version of the application.

[0060] Since the package aid and instance aid of the new and old versions are different, in one implementation, the new version of the application can be downloaded to the security chip where the old version of the application exists, and the download process complies with the GP standard definition.

[0061] Step S130 , selecting a new version application instance, sending a data migration command to the new version application, and triggering the new version application to read application data from the old version application.

[0062] The application scenarios of the present application may include digital key scenarios, virtual bus card scenarios, and application scenarios used by smart card application applets in the fields of mobile phones, automobiles, and telecommunications. In order to ensure the user experience, the correct migration of application data is crucial.

[0063] Step S140, when the data migration is successful, the smart card application applet is successfully upgraded, the new version of the application is effective, and the old version of the application is invalid.

[0064] Furthermore, in order to ensure that there is a valid application running at all times, in an optional implementation, if data migration fails and / or the smart card application applet upgrade fails, the old version of the application remains valid.

[0065] The upgrade method for the smart card application applet provided in the embodiment of the present application configures the application version identifier of the smart card application applet based on the upgraded version, sends a data migration command to the new version application, triggers the new version application to read application data from the old version application, and when the data migration is successful, the smart card application applet is successfully upgraded, the new version application takes effect, and the old version application becomes invalid, thereby ensuring that any interruption of the upgrade business at any time will not affect the service provided by the application applet, ensuring that only one application is valid at any time, thereby ensuring the user experience.

[0066] For ease of understanding, the specific implementation details of the upgrade method of the smart card application applet are described in detail.

[0067] In one implementation, the above-mentioned configuration of the application version identifier of the smart card application applet based on the upgraded version may include the following steps 1.1 to 1.3 when implemented:

[0068] Step 1.1, defining a preset byte of the application version identifier of the smart card application applet as a version number byte.

[0069] Optionally, defining a preset byte of the application version identifier of the smart card application applet as a version number byte may be defining the last byte of the application version identifier of the smart card application applet as the version number byte.

[0070] According to the Javacard specification, the AID length range is 5-16 bytes. In one embodiment, 13 bytes can be selected to represent the package aid identity of the application, and 14 bytes can be selected to represent the instance aid identity. For example, the first 13 bytes of the package aid are A000005342434343444B413456, and the first 14 bytes of the instance aid are A000005342434343444B413456FF. Then the 14th byte of the package aid and the 15th byte of the instance aid can be defined as the version number bytes.

[0071] Step 1.2, determining the version identifier of the version number byte according to the version number of the upgraded version.

[0072] In order to ensure normal use of the new and old versions of the application and avoid confusion that would render both applications unusable, the first version identifier corresponding to the new version of the application is different from the second version identifier corresponding to the old version of the application.

[0073] Step 1.3, configuring the application version identifier of the smart card application applet based on the identity byte information and version identifier of the smart card application applet.

[0074] In one example, assuming the current version is 01, the complete package aid is A000005342434343444B41345601, and the instance aid is A000005342434343444B413456FF01. If you need to upgrade to version 02, the package aid of the new version application should be A000005342434343444B41345602, and the instance aid should be A000005342434343444B413456FF02. The aid length can be freely defined by the application developer as long as it does not conflict with the existing aid definition value.

[0075] Furthermore, the above-mentioned selecting of the new version application instance, sending a data migration command to the new version application, and triggering the new version application to read application data from the old version application may include the following steps 2.1 to 2.5 during specific implementation:

[0076] Step 2.1, in the new version application, traverse the application version identifiers of all supported old version applications to find the application version identifier corresponding to the correct old version application;

[0077] Step 2.2, in response to the interface call of the new version application, the old version application reads the application data to be migrated from the storage, returns it to the new version application through the preset shared interface, and allows the new version application to switch the status of the old version application to migrated out through the preset shared interface;

[0078] Step 2.3, the new version application obtains the preset shared object according to the application version identifier found, and exports the application data from the old version application according to the data reading method pre-agreed between the new and old versions of the application;

[0079] Step 2.4: The new version of the application verifies the data format of the application data, and performs data migration after confirming that the read application data is correct;

[0080] Step 2.5: When all application data is successfully migrated, the new version application switches the status of the old version application to migrated out, and switches its own status to normal service status.

[0081] In a specific embodiment, during the application data migration process, the migration instruction is defined by the new version application. For example, we use the command 80F5000000 to trigger the migration action. In the digital key scenario, the application data contains the vehicle's key, certificate, and the activated digital key. The correct migration of application data ensures the user's normal experience of using the vehicle, which is very important. In the virtual bus card scenario, the application data contains important information such as the bus card's authentication key and balance. The correct migration of application data ensures that the user's assets are not lost. However, to achieve data migration, the new version application must know the instance aid of the old version application. According to the above content, the last byte in instance aid is the version number, which means that instance aid is not fixed. According to the actual usage scenario, there is only one old version application and one new version application in the upgrade situation. Therefore, we need to traverse the instance aid of all supported old version applications in the new version application in order to find the correct old version instance aid and prepare for data migration.

[0082] In order to achieve data migration, the old version application needs to implement the Shareable Interface provided by the Javacard operating system. The old version application receives the interface call from the new version application, reads the data to be migrated from the storage, and returns it to the new version application through the Shareable Interface interface. At the same time, the new version application is allowed to switch the status of the old version application to migrated out through the Shareable Interface to prevent the old version application from being used. The type of data and the reading method are determined by the old version application. The new version application obtains the Shareable Interface object based on the instance aid found, and exports the data from the old version application according to the agreed data reading method (the agreement lies between the old and new versions of the application). The new version application should verify the data format, including length, value, etc., confirm that the read data is correct, and then process the data. When all the data is successfully migrated, the new version application switches the status of the old version application to migrated out, and switches its own status to the normal service status. The state switching of the old and new versions of the application is an operation protected by an atomic transaction, that is, the switching is successful at the same time or not at the same time, so as to ensure that only one application is in the normal service state at the same time.

[0083] In addition, in order to avoid abnormal situations during the upgrade process, in one embodiment, the method further includes the following steps 3.1 to 3.4:

[0084] Step 3.1, if the upgrade process is interrupted and there are two applications in the security chip, select one application first and determine the selection result;

[0085] Step 3.2: If the application feedback is normal, continue with the subsequent business process;

[0086] Step 3.3, if the application reports that the application data has been migrated out, use the command to select the next application, which is the new version of the application that takes effect;

[0087] Step 3.4: After the selection is successful, continue the business processing through the effective new version of the application.

[0088] Generally, under ideal circumstances, only one of the new version of the application and the old version of the application will exist before and after the upgrade. According to the application selection logic of the GP specification, the host computer program selects the instance aid representing the identity of the mini program to continue the subsequent business process. However, if the upgrade process is interrupted, both the old and new versions of the application may exist in the security chip at the same time, and only one of the two versions of the application is valid. Therefore, the host computer needs to apply the selection strategy, that is, select the first application first and judge the selection result. If the application feedback is normal, continue the subsequent business process. If the application feedback indicates that the application data has been migrated out, use the instruction to select the next application to continue the selection. At this time, the next application is the new version of the application that takes effect. Continue business processing after the selection is successful.

[0089] In summary, through the specific implementation method of the smart card application applet upgrade provided by the embodiment of the present application, during the upgrade process of the smart card application applet, the interruption of the application upgrade service does not affect the user's normal use of the application. There will be a valid application function at any time. By downloading the new version of the application first and then deleting the old version of the application, it can be guaranteed that there is a valid application at any time; when searching for the old version of the application, by traversing the supported old version instance aid, the search result is made more accurate; when actually using the application, according to the selection strategy, in order to be compatible with the scenario where the new and old versions exist at the same time, the user experience is guaranteed.

[0090] The above method embodiment, the present application embodiment also provides an upgrade system for smart card application applet, see Figure 2 As shown, the system mainly includes the following parts:

[0091] A configuration module 210, configured to configure an application version identifier of the smart card application applet based on the upgraded version;

[0092] A download module 220, for downloading a new version of the application to a security chip running an old version of the application;

[0093] Migration module 230, used to select a new version application instance, send a data migration command to the new version application, and trigger the new version application to read application data from the old version application;

[0094] The upgrade module 240 is used to upgrade the smart card application applet successfully after the data migration is successful, so that the new version of the application program takes effect and the old version of the application program becomes invalid.

[0095] In a feasible implementation manner, the system further includes: a maintaining module, configured to:

[0096] If the data migration fails and / or the smart card application applet upgrade fails, the old version of the application remains valid.

[0097] In a feasible implementation manner, the configuration module 210 is used to:

[0098] Define a preset byte of the application version identifier of the smart card application applet as a version number byte;

[0099] Determine the version identifier of the version number byte according to the version number of the upgraded version;

[0100] An application version identifier of the smart card application applet is configured based on the identity byte information and the version identifier of the smart card application applet.

[0101] In a feasible implementation manner, the configuration module 210 is used to:

[0102] The last byte of the application version identifier of the smart card application applet is defined as the version number byte.

[0103] In a feasible implementation manner, the first version identifier corresponding to the new version application is different from the second version identifier corresponding to the old version application.

[0104] In a feasible implementation, the migration module 230 is used to:

[0105] In the new version application, traverse the application version identifiers of all supported old version applications to find the application version identifier corresponding to the correct old version application;

[0106] In response to the interface call of the new version application, the old version application reads the application data to be migrated from the storage, returns it to the new version application through the preset shared interface, and allows the new version application to switch the status of the old version application to migrated out through the preset shared interface;

[0107] The new version application obtains the preset shared object according to the application version identifier found, and exports the application data from the old version application according to the data reading method pre-agreed between the new and old versions of the application;

[0108] The new version of the application verifies the data format of the application data and performs data migration after confirming that the read application data is correct;

[0109] When all application data is successfully migrated, the new version of the application switches the status of the old version of the application to migrated out, and switches its own status to normal service status.

[0110] In a feasible implementation, the system further includes: an exception handling module, configured to:

[0111] If the upgrade process is interrupted and there are two applications in the security chip, select one application first and determine the selection result;

[0112] If the application feedback is normal, continue with the subsequent business process;

[0113] If the application reports that the application data has been migrated out, the next application is selected using the command, and the application is the new version of the application that takes effect;

[0114] After the selection is successful, business processing will continue through the effective new version of the application.

[0115] The upgrade system device for the smart card application applet provided in the embodiment of the present application has the same implementation principle and technical effects as those of the aforementioned method embodiment. For the sake of brief description, for parts not mentioned in the embodiment of the upgrade system for the smart card application applet, reference may be made to the corresponding contents in the aforementioned smart card application applet upgrade method embodiment.

[0116] The present application also provides an electronic device, such as Figure 3 As shown, it is a schematic diagram of the structure of the electronic device, wherein the electronic device 100 includes a processor 31 and a memory 30, the memory 30 stores computer executable instructions that can be executed by the processor 31, and the processor 31 executes the computer executable instructions to implement any of the above-mentioned smart card application applet upgrade methods.

[0117] exist Figure 3 In the illustrated embodiment, the electronic device further includes a bus 32 and a communication interface 33 , wherein the processor 31 , the communication interface 33 and the memory 30 are connected via the bus 32 .

[0118] Among them, the memory 30 may include a high-speed random access memory (RAM), and may also include a non-volatile memory (non-volatile memory), such as at least one disk storage. The communication connection between the system network element and at least one other network element is realized through at least one communication interface 33 (which can be wired or wireless), and the Internet, wide area network, local area network, metropolitan area network, etc. can be used. The bus 32 can be an ISA (Industry Standard Architecture) bus, a PCI (Peripheral Component Interconnect) bus or an EISA (Extended Industry Standard Architecture) bus, etc. The bus 32 can be divided into an address bus, a data bus, a control bus, etc. For ease of representation, Figure 3 Only one bidirectional arrow is used in the diagram, but this does not mean that there is only one bus or only one type of bus.

[0119] The processor 31 may be an integrated circuit chip with signal processing capabilities. In the implementation process, each step of the above method can be completed by the hardware integrated logic circuit or software instructions in the processor 31. The above processor 31 can be a general-purpose processor, including a central processing unit (CPU), a network processor (NP), etc.; it can also be a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, discrete gates or transistor logic devices, discrete hardware components. The general-purpose processor can be a microprocessor or the processor can also be any conventional processor. The steps of the method disclosed in the embodiment of the present application can be directly embodied as a hardware decoding processor to perform, or the hardware and software modules in the decoding processor can be combined and performed. The software module can be located in a mature storage medium in the field such as a random access memory, a flash memory, a read-only memory, a programmable read-only memory, or an electrically erasable programmable memory, a register, etc. The storage medium is located in the memory, and the processor 31 reads the information in the memory and completes the steps of the smart card application applet upgrade method of the above embodiment in combination with its hardware.

[0120] An embodiment of the present application also provides a computer-readable storage medium, which stores computer-executable instructions. When the computer-executable instructions are called and executed by a processor, the computer-executable instructions prompt the processor to implement the upgrade method of the above-mentioned smart card application applet. The specific implementation can be found in the aforementioned method embodiment, which will not be repeated here.

[0121] The computer program product of the smart card application applet upgrade method, system, device and medium provided in the embodiments of the present application includes a computer-readable storage medium storing program code. The instructions included in the program code can be used to execute the methods in the previous method embodiments. The specific implementation can be found in the method embodiments, which will not be repeated here.

[0122] Unless otherwise specifically stated, the relative steps, numerical expressions and values ​​of the components and steps set forth in these embodiments do not limit the scope of the present application.

[0123] If the function is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a non-volatile computer-readable storage medium that is executable by a processor. Based on this understanding, the technical solution of the present application, or the part that contributes to the prior art or the part of the technical solution, can be embodied in the form of a software product, which is stored in a storage medium and includes several instructions for a computer device (which can be a personal computer, server, or network device, etc.) to perform all or part of the steps of the various embodiments of the present application. The aforementioned storage medium includes: U disk, mobile hard disk, read-only memory (ROM, Read-Only Memory), random access memory (RAM, Random Access Memory), disk or optical disk, and other media that can store program codes.

[0124] In the description of the present application, it should be noted that the terms "first", "second", etc. are only used to distinguish the description and cannot be understood as indicating or implying relative importance.

[0125] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present application, rather than to limit it. Although the present application has been described in detail with reference to the aforementioned embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the aforementioned embodiments, or replace some or all of the technical features therein with equivalents. However, these modifications or replacements do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of the present application.

Claims

1. A method for upgrading a smart card application applet, characterized in that: The method comprises: An application version identifier of the smart card application applet is configured based on the upgraded version; Download the new version of the application to the security chip running the old version of the application; Select the new version application instance, send a data migration command to the new version application, and trigger the new version application to read application data from the old version application; When the data migration is successful, the smart card application applet is successfully upgraded, the new version of the application becomes effective, and the old version of the application becomes invalid.

2. The method for upgrading the smart card application applet according to claim 1, characterized in that: The method further comprises: If the data migration fails and / or the smart card application applet upgrade fails, the old version of the application is kept valid.

3. The method for upgrading the smart card application applet according to claim 1, characterized in that: Configure the application version identifier of the smart card application applet based on the upgraded version, including: Define a preset byte of the application version identifier of the smart card application applet as a version number byte; Determine the version identifier of the version number byte according to the version number of the upgraded version; An application version identifier of the smart card application applet is configured based on the identity byte information of the smart card application applet and the version identifier.

4. The method for upgrading the smart card application applet according to claim 3, characterized in that: The preset bytes of the application version identifier of the smart card application applet are defined as the version number bytes, including: The last byte of the application version identifier of the smart card application applet is defined as the version number byte.

5. The method for upgrading the smart card application applet according to claim 4, characterized in that: The first version identifier corresponding to the new version application is different from the second version identifier corresponding to the old version application.

6. The method for upgrading the smart card application applet according to claim 1, characterized in that: Select the new version application instance and send a data migration command to the new version application to trigger the new version application to read application data from the old version application, including: In the new version application, traverse the application version identifiers of all supported old version applications to find the application version identifier corresponding to the correct old version application; In response to the interface call of the new version application, the old version application reads the application data to be migrated from the storage, returns it to the new version application through the preset shared interface, and allows the new version application to switch the status of the old version application to migrated out through the preset shared interface; The new version application obtains the preset shared object according to the application version identifier found, and exports the application data from the old version application according to the data reading method pre-agreed between the new and old versions of the application; The new version application verifies the data format of the application data, and performs data migration after confirming that the read application data is correct; When all application data is successfully migrated, the new version of the application switches the status of the old version of the application to migrated out, and switches its own status to normal service status.

7. The method for upgrading a smart card application applet according to claim 1, characterized in that: The method further comprises: If the upgrade process is interrupted and there are two applications in the security chip, one application is selected first and the selection result is determined; If the application feedback is normal, continue with the subsequent business process; If the application reports that the application data has been migrated out, the next application is selected using the command, and the application is the new version of the application that takes effect; After the selection is successful, business processing continues through the effective new version of the application.

8. A smart card application applet upgrade system, characterized in that: The system comprises: A configuration module, configured to configure an application version identifier of the smart card application applet based on the upgraded version; A download module, used to download a new version of the application to the security chip running the old version of the application; A migration module is used to select a new version application instance, send a data migration command to the new version application, and trigger the new version application to read application data from the old version application; The upgrade module is used to upgrade the smart card application applet successfully after the data migration is successful, the new version of the application program takes effect, and the old version of the application program becomes invalid.

9. An electronic device, characterized in that: It comprises a processor and a memory, wherein the memory stores computer executable instructions that can be executed by the processor, and the processor executes the computer executable instructions to implement the smart card application applet upgrade method according to any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores computer-executable instructions. When the computer-executable instructions are called and executed by the processor, the computer-executable instructions prompt the processor to implement the smart card application applet upgrade method according to any one of claims 1 to 7.

Images