Data management method and system for secure element

Abstract

The invention provides a data management method and system of a security element, the security element, electronic equipment and a computer program product, belongs to the technical field of intelligent cards, and aims to solve the problems of the existing security element in the aspects of data backup, recovery and the like. The method comprises the following steps: issuing an updating instruction of a current version application program to a security element through a trusted service management platform; in response to the update instruction, the secure execution environment randomly generates a temporary key, and obtains user specific configuration data of the application program of the current version from a secure storage area of the secure element; encrypting the user specific configuration data by using the temporary key to obtain encrypted data, and storing the encrypted data to the secure storage area; and obtaining the application program key from the secure storage area, encrypting the temporary key by using the application program key to obtain an encrypted key, and storing the encrypted key to the secure storage area.

Description

Technical Field

[0001] This application relates to the field of smart card technology, and in particular to a data management method, system, security element, electronic device, and computer program product for a security element. Background Technology

[0002] With the increasing prevalence of dynamic multi-application smart cards, applications installed on the card require personalized processing to inject user-specific configuration data (such as keys, account information, etc.) before activation. In scenarios such as application upgrades, securely handling this sensitive personal data becomes a key technological challenge.

[0003] Existing technologies primarily offer two data backup and recovery solutions: The first is a cloud server backup solution, where personalized data is uploaded to a cloud server for temporary storage before the upgrade and then downloaded and restored after the upgrade. This solution suffers from risks such as data leakage during card-to-card transmission, data loss and tampering during communication links, and low recovery efficiency due to network interactions. The second is a local backup solution, which avoids data leakage from the card, but generally uses a fixed key within the card to encrypt personalized data. The key itself has low security; once leaked, the data encrypted with this key faces permanent security threats, failing to meet the requirements of high-security applications. Summary of the Invention

[0004] This application provides a data management method, system, security element, electronic device, and computer program product for a security element, which can solve the problems of existing security elements in data backup and recovery.

[0005] In a first aspect, embodiments of this application provide a data management method for a secure element, wherein a secure execution environment for an application is deployed on the secure element. The method includes the following steps: The Trusted Service Management Platform issues an update command for the current version of the application to the secure element; In response to the update command, the secure execution environment randomly generates a temporary key and retrieves the user-specific configuration data of the current version of the application from the secure storage area of ​​the secure element; The secure execution environment uses the temporary key to encrypt the user-specific configuration data to obtain encrypted data, and stores the encrypted data in the secure storage area; The secure execution environment obtains the application key from the secure storage area, uses the application key to encrypt the temporary key to obtain an encryption key, and stores the encryption key in the secure storage area.

[0006] Secondly, embodiments of this application provide a data management system for a secure element, on which a secure execution environment for applications is deployed. The system includes the following: The instruction receiving module is used to send an update instruction for the current version of the application to the security element through the trusted service management platform; A key generation module is used by the secure execution environment to randomly generate a temporary key in response to the update command; The data acquisition module is used to acquire user-specific configuration data of the current version of the application from the secure storage area of ​​the secure element; The data backup module includes a secure execution environment that uses the temporary key to encrypt the user-specific configuration data to obtain encrypted data and stores the encrypted data in the secure storage area. It also includes a secure execution environment that obtains an application key from the secure storage area, uses the application key to encrypt the temporary key to obtain an encryption key, and stores the encryption key in the secure storage area.

[0007] Thirdly, embodiments of this application provide a security element, including: processor; Secure storage area; An operating system, running on the processor, wherein the operating system is configured to perform steps executed by the operating system in the data management method of the security element as described in the first aspect; A secure execution environment, created and isolated by the operating system, wherein the secure execution environment is configured to perform steps executed by the secure execution environment in the data management method of the secure element as described in the first aspect.

[0008] Fourthly, embodiments of this application provide an electronic device including a processor, a memory, and a program or instructions stored in the memory and executable on the processor, wherein the program or instructions, when executed by the processor, implement the steps of the data management method for a security element as described in the first aspect.

[0009] Fifthly, embodiments of this application provide a computer program product, the computer program product including a computer program stored on a non-transitory computer-readable storage medium, the computer program including program instructions, which, when executed by a computer, implement the steps of the data management method for a security element as described in the first aspect.

[0010] This application embodiment uses a randomly generated temporary key to encrypt user-specific configuration data, and then uses an independent application key to perform secondary encryption on the temporary key, which can avoid the risk of data being cracked in bulk. The entire key processing flow, including the generation, use, encryption, and storage of the temporary key, is completed in the secure execution environment deployed on the secure element. Sensitive key data never leaves the protection boundary of the secure element, which can reduce the risk of leakage due to key transmission. All encrypted user-specific configuration data is temporarily stored in a local secure storage area, and data recovery can be achieved without relying on the external network communication environment after the application upgrade, ensuring fast and reliable local recovery and helping to shorten business interruption time. The temporary key has randomness, temporariness, and single validity, overcoming the security defects of traditional local backup schemes that use fixed keys, significantly improving the security level, and the localized data backup and recovery method can avoid network latency, balancing security and efficiency. Attached Figure Description

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

[0012] Figure 1 This is a flowchart illustrating a data management method for a security element provided in an embodiment of this application; Figure 2 This is a flowchart illustrating the data backup method provided in an embodiment of this application; Figure 3 This is a flowchart illustrating another data management method for a security element provided in an embodiment of this application; Figure 4 This is a flowchart illustrating the data recovery method provided in an embodiment of this application; Figure 5 This is a schematic diagram of the structure of a data management system for a security element provided in an embodiment of this application; Figure 6 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0013] To enable those skilled in the art to better understand the technical solutions in this application, the technical solutions in the embodiments 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, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of this application.

[0014] The terms "first," "second," etc., used in the specification and claims of this application are used to distinguish similar objects and not to describe a specific order or sequence. It should be understood that such use of data can be interchanged where appropriate so that embodiments of this application can be implemented in orders other than those illustrated or described herein. Furthermore, in the specification and claims, "and / or" indicates at least one of the connected objects, and the character " / " generally indicates that the preceding and following objects are in an "or" relationship.

[0015] With the continuous increase in computing and storage resources, smart cards have begun to support dynamic multi-application support. Smart cards supporting dynamic multi-application support can install various applications via post-download, greatly enriching the diversity of smart card business scenarios and enhancing their commercial value. Generally, after an application is installed on a smart card, it needs to undergo personalization before it can be activated and used. Smart card application personalization needs to be conducted under a secure and reliable mechanism. The purpose of personalization is to combine the smart card application with the cardholder's specific information, enabling it to store the cardholder's personal information, account details, and other necessary data to ensure that the smart card can be identified and used in specific applications. The personalized data involved includes sensitive information such as the user's personal account balance and keys. After the smart card application personalization is completed, sensitive user-personalized data is generated, which needs to be securely stored and managed. When upgrading applications already installed on the smart card, the issue of how to handle personalized data arises. The overall process of smart card application download, installation, activation, upgrade (including uninstallation), and personalized data processing in existing solutions generally includes the following: 1. Before smart card issuance, the issuer's security domain (ISD) is pre-installed on the card. After issuance, the supplementary security domain (SSD) of the application provider is downloaded from the Trusted Service Management (TSM) platform as needed for business operations. Generally, the ISD is responsible for installing the SSD on the card. The role of the SSD is to isolate and protect the application provider's applications and data. It is a security domain controlled by the application provider. The SSD is used to store and manage applications and data related to specific services, such as public transportation ticketing and e-government. The SSD allows application providers to deploy and execute their applications on the smart card while ensuring that these applications are isolated from other applications on the card to maintain data security and integrity.

[0016] 2. The smart card downloads the application installation package (e.g., an older version of the application) from the TSM platform and completes the application installation under the application provider's secondary security domain (SSD) within the card.

[0017] 3. Complete the application personalization process. The purpose of personalization is to generate personalized data related to the user, such as account information, encryption keys, account balance, etc.

[0018] 4. The smart card selects an application to activate it and begin relevant business operations. For example, it executes the Select instruction of the GP specification, where GP (Global Platform) is a technical specification in the smart card field.

[0019] 5. If the card application needs to be upgraded, the upgrade process will begin. After the user agrees and confirms the upgrade request, the smart card will download the new version of the application installation package from the TSM platform.

[0020] 6. Back up the smart card application's personalized data on a local or cloud server.

[0021] 7. Smart card: Clears personal data from older versions of applications on the card.

[0022] 8. Uninstall old versions of applications from the smart card.

[0023] 9. The smart card installs the new version of the application on the original SSD.

[0024] 10. Restore personal data locally or download it to the smart card from the cloud server to restore personal data.

[0025] 11. The smart card selects an application to activate it and begin the relevant business processes, thus ending the application upgrade process.

[0026] In the above process, the technical solutions for upgrading existing smart card applications involving the backup of smart card personal data generally include two main methods: cloud server backup and local backup.

[0027] The technical solution for cloud server backup generally includes: when upgrading an application, before uninstalling the old version, the application's personalized data is uploaded to the cloud server. After the upgrade is complete, the data is downloaded from the cloud server to the smart card for personalized data recovery. While existing cloud backup and recovery solutions have certain applicable scenarios, they still have the following drawbacks: Personalized data being taken out of the card poses a certain risk of leakage, as cloud server backup requires the smart card to upload personalized data to the cloud, introducing a risk of data leakage; there is a risk of personalized data loss and error, as communication between the smart card and the cloud, as well as the two data transmission interactions, may result in data loss or error due to certain special scenarios and unforeseen circumstances. Data transmitted over the air interface is also susceptible to illegal attacks and tampering, posing potential risks to data integrity, accuracy, and security; under cloud backup, personalized data recovery requires re-downloading from the cloud, which takes time, resulting in slow personalized data recovery speeds and reduced business recovery speeds after upgrades. This negatively impacts the user experience during upgrades. Clearly, cloud backup is not suitable for application scenarios requiring efficient upgrades and rapid recovery of personalized data.

[0028] The technical solutions for local backup generally include: when upgrading an application, before uninstalling the old version, backing up the application's personalized data to local storage; and then restoring the personalized data from local storage after the upgrade is complete. Most local backup solutions use a fixed key on the card to encrypt personalized data, failing to implement a "one card, one key" security mechanism. The key itself has insufficient security, thus introducing security risks to the storage of personalized data. Using a fixed backup key on the card to encrypt some or all of the application's personalized data has low security; once the key is leaked, the personalized data will permanently lose its security. The leakage of sensitive user data, in particular, will cause significant privacy and security problems. The low security level cannot meet the requirements of high-security design.

[0029] Therefore, there is an urgent need for a data management method for smart cards that can securely store and restore data locally, while fundamentally improving the security level of key management and data encryption.

[0030] The following is in conjunction with the appendix Figures 1 to 6 This application provides a detailed description of a data management method, system, security element, electronic device, and computer program product for a security element through specific embodiments and application scenarios.

[0031] Figure 1 This application illustrates a data management method for a secure element, wherein the secure element has a secure execution environment for an application deployed on it. The method can be executed by an electronic device, which may include a server and / or a terminal device. In other words, the method can be executed by software or hardware installed on the server and / or terminal device, and includes the following steps: Step 110: Issue an update command for the current version of the application to the security element through the trusted service management platform.

[0032] The secure element can be a hardware carrier with computing power, storage capacity, and security protection capabilities. For example, a smart card typically has a built-in processor or microprocessor, storage unit, and card operating system (COS), and can usually handle complex data independently. The secure execution environment deployed on the secure element can be the application provider's secondary security domain (SSD).

[0033] The Trusted Service Management (TSM) platform, acting as a remote and trusted management entity, is responsible for managing the lifecycle of applications on the secure element. When an upgrade is required for a specific application on the secure element, the TSM platform generates and issues an update command. The triggering conditions for this update command can be based on various sources, such as the application provider releasing a new version of the application, the TSM platform detecting an upgrade policy that meets preset conditions, or receiving an upgrade request from a user.

[0034] The update command can be sent to the secure element via a secure communication channel (e.g., a secure channel protocol conforming to the GP specification). The update command includes at least the application's identifier and information pointing to the updated version of the application. Upon receiving the update command, the operating system (COS) of the secure element parses and verifies it to confirm the legitimacy and integrity of its source, and then forwards the update command to the secure execution environment hosting the current version of the application.

[0035] Step 120: In response to the update instruction, the secure execution environment randomly generates a temporary key and retrieves the user-specific configuration data of the current version of the application from the secure storage area of ​​the secure element.

[0036] The secure execution environment (SEA) responds to update commands by initiating a data caching process before application upgrades. Internally, the SEA randomly generates a temporary key, preferably using an industry-standard cryptographically secure random number generator to ensure its unpredictability. This temporary key is specifically created for this application update operation, has a short lifespan, is used only to encrypt current user-specific configuration data, and is destroyed at a designated point in the subsequent process. This "one-time key" security mechanism significantly reduces the security risks associated with long-term key exposure or reuse.

[0037] The secure execution environment (SEU) retrieves user-specific configuration data for the current version of an application from the secure storage area of ​​the secure element. The secure storage area is a storage space within the secure element protected by access control policies, ensuring that only authorized entities (e.g., the corresponding SEU) can access its internal data.

[0038] User-specific configuration data is key information that binds an application to a specific user. This includes, but is not limited to, personalized data such as user identification, personal account information, transaction keys, account balance, and personalized settings parameters.

[0039] Step 130: The secure execution environment uses the temporary key to encrypt the user-specific configuration data to obtain encrypted data, and stores the encrypted data in the secure storage area.

[0040] The secure execution environment can invoke its internal encryption / decryption engine to perform encryption operations on the acquired user-specific configuration data using the temporary key generated in step S120, generating corresponding encrypted data. The encryption operation can employ a symmetric encryption algorithm commonly used in the field, such as the Advanced Encryption Standard (AES) algorithm, to ensure both encryption strength and processing efficiency. Through this step, the plaintext user-specific configuration data is converted into encrypted data in ciphertext form, which is unreadable without decryption, thus achieving data confidentiality protection.

[0041] The secure execution environment persistently writes the generated encrypted data to the secure storage area of ​​the secure element. This secure storage area provides access-controlled storage space, ensuring that only authorized entities (e.g., the current secure execution environment or a subsequently certified new version of the application) can access the encrypted data. This step achieves static security of user data within the secure element. Even if part of the secure element's storage medium is read non-physically, attackers can only obtain encrypted data that they cannot directly understand, and cannot acquire meaningful user information.

[0042] Step 140: The secure execution environment obtains the application key from the secure storage area, uses the application key to encrypt the temporary key to obtain an encryption key, and stores the encryption key in the secure storage area.

[0043] The secure execution environment retrieves the application key pre-configured for the application from the secure storage area. The application key is a long-term key uniquely bound to a specific application and a specific security element. Its generation can be achieved through a key distribution algorithm based on the security element's unique identifier and a specific key, thus ensuring the high security characteristic of "one key per card." This key is typically securely pre-installed in the secure storage area when performing personalized operations on the application, and its access permissions are strictly controlled, limited to calls by the corresponding secure execution environment.

[0044] The secure execution environment uses the acquired application key to perform encryption operations on the temporary key randomly generated in step S120, generating a corresponding encryption key. This re-encrypts the core key (i.e., the temporary key), effectively adding a second, independent, hardware-based lock to the sensitive data. The secure execution environment then writes the generated encryption key into a secure storage area for secure storage.

[0045] This embodiment uses a randomly generated temporary key to encrypt user-specific configuration data, and then uses a separate application key to further encrypt the temporary key, thus avoiding the risk of mass data breaches. The entire key processing flow, including the generation, use, encryption, and storage of the temporary key, is completed within the secure execution environment deployed on the secure element. Sensitive key data never leaves the protection boundary of the secure element, reducing the risk of leakage due to key transmission. All encrypted user-specific configuration data is temporarily stored in a local secure storage area, allowing for data recovery without relying on external network communication after application upgrades, ensuring fast and reliable local recovery and helping to shorten business interruption time. The temporary key's randomness, temporariness, and single-use validity overcome the security flaws of traditional local backup schemes using fixed keys, significantly improving the security level. Furthermore, the localized data backup and recovery method avoids network latency, balancing security and efficiency.

[0046] In yet another exemplary embodiment, the data management method for a security element may further include the following specific steps: The application key is configured for the current version of the application through the trusted service management platform, and the application key is stored in the secure storage area by the operating system of the secure element.

[0047] During the preparation phase before the current version of the application enters normal use, a unique application key is configured for it through the Trusted Service Management Platform, and the operating system of the secure element securely stores the application key in a secure storage area. This configuration process can also be performed during the application personalization phase. Based on its key management system, the Trusted Service Management Platform generates or derives an application key that uniquely corresponds to a specific secure element and a specific application. The generation of the application key can employ a key distribution algorithm, using the smart card's unique identifier and root key as distribution factors to ensure a "one card, one key" security mechanism. Subsequently, the Trusted Service Management Platform issues a personalization instruction containing the application key to the secure element through a secure communication channel (e.g., a secure channel conforming to the GP specification).

[0048] Upon receiving the instruction, the operating system of the secure element performs security verification and parsing to extract the application key. Next, the operating system writes this application key into the secure storage space allocated to the application within the secure storage area. The writing process follows strict security access rules, ensuring that the key is bound to a specific secure execution environment (i.e., the SSD to which the application resides), so that only that secure execution environment has the right to access and use this key in subsequent operations, while the operating system itself and other applications cannot directly read its plaintext.

[0049] In this embodiment, the application key is managed as an independent, pre-configured security asset, providing a reliable foundation for subsequent encryption protection of temporary keys. The trusted service management platform, as a central authoritative body, is responsible for key generation and distribution, achieving "one card, one key" from the source. This enhances overall system security and avoids the risk of key tampering or reuse. The application key is securely anchored in a secure storage area through the operating system of the secure element, and strict access control is implemented to ensure the confidentiality and integrity of the key during storage, effectively preventing unauthorized access and leakage.

[0050] In yet another exemplary embodiment, see Figure 2 Using a smart card as an example, this paper provides a detailed explanation of the data temporary storage process.

[0051] For ease of describing the upgrade scenario, the current version of the application will be referred to as the old version of the application, and the main steps for its download and installation are as follows: 1. Download the application, such as the two Application Protocol Data Unit (APDU) instructions "install for load" and "load" defined in the GP specification, and write the application installation package data to the secure storage area of ​​the smart card, such as the smart card file system. The storage and access of related files must follow secure access rules to ensure the security of file storage and the isolation between applications.

[0052] 2. Install the application in a secondary security domain (SSD) of its application provider, such as the install for install directive defined in the GP specification.

[0053] 3. Perform personalization operations on the application, such as the "install for personalization" directive defined in the GP specification, to configure an application key (KEY_APP) and write KEY_APP to the smart card file system. KEY_APP is used to encrypt a temporary key (KEY_PDATA) for encrypting personalized data in subsequent steps. The KEY_PDATA encrypted by KEY_APP is stored in the smart card file system and managed by the application provider's auxiliary security domain SSD, making the key inaccessible externally. This method of storing KEY_PDATA locally on the smart card ensures the security of both the key and the personalized data, complying with the high-security design principles of smart cards and relevant data security requirements. 4. Start the application to begin the business process, such as the select instruction defined in the GP specification.

[0054] The detailed steps for the personal data temporary storage process before upgrading the smart card application include the following: 1. The TSM platform sends an upgrade command to the smart card to start the application upgrade (the pre-upgrade steps, such as triggering the upgrade action and prompting the user for confirmation, are omitted here).

[0055] 2. Smart card reading card application personalization data.

[0056] 3. The smart card reads and returns the personalized data of the card application stored in the file system.

[0057] 4. The smart card application provider's auxiliary security domain (SSD) randomly generates a temporary key (KEY_PDATA). Random generation ensures that the key is unpredictable. The key is deleted immediately after a single upgrade and a new temporary key is randomly generated when the next upgrade process begins, ensuring that the key usage period is minimized, protecting the key itself, and minimizing the risk of continuous illegal use after the key is leaked. This solves the security risks of using fixed keys in other existing technical solutions.

[0058] 5. Use the KEY_PDATA generated in the above steps to encrypt the card application personalization data (PersonalizationData) to obtain the encrypted card application personalization data (PersonalizationData_Encrypted).

[0059] 6. The encrypted card application personalization data (PersonalizationData_Encrypted) obtained in the above steps is securely stored in the smart card file system, which realizes that the personalization data does not leave the card and reduces the risk of leakage during data transmission.

[0060] 7. The application provider's secondary security domain (SSD) obtains the application key (KEY_APP) written to the smart card through personalized operations.

[0061] 8. The smart card reads and returns KEY_APP from the file system. The read operation must follow the file security access rules to ensure that the key is read under the allowed access permissions. 9. KEY_APP is used to encrypt KEY_PDATA to generate encrypted KEY_PDATA_Encrypted, which realizes that the key does not leave the card and ensures the security of the key itself.

[0062] 10. Store the encrypted KEY_PDATA_Encrypted into the smart card file system to ensure that the key used to encrypt the smart card's personal data does not leave the card. 11. Uninstall the old version of the application.

[0063] In this embodiment, user personal data can be securely stored in the card before the application is upgraded, ensuring that the user personal data is not lost. The security mechanism can also ensure the security of the user personal data. Furthermore, the personal data and the temporary key itself are encrypted and stored through the above steps, thereby achieving "dual security" of the smart card's personal data and the key.

[0064] In yet another exemplary embodiment, the encrypted data is stored as a separate, application-specific secure data file or data object.

[0065] When encrypted data is written to a secure storage area by a secure execution environment, it is not simply appended to the end of existing data. Instead, a unique storage structure with an independent identifier is created for it. For a file system-based secure storage area, encrypted data is stored as a separate secure data file. The filename or file identifier of this secure data file contains a unique identifier for the specific application it is associated with (e.g., the application identifier), thus establishing a clear correspondence at the file system level. Alternatively, in an object storage-based secure storage area, encrypted data can also be encapsulated as a separate secure data object, which, in addition to containing the encrypted data itself, also contains metadata identifying the application it belongs to.

[0066] Regardless of the specific form used, the secure data file or data object is protected by a mandatory access control mechanism within the secure storage area. The access control policy is configured to allow only the source secure execution environment that generated the file or object, or a verified new secure execution environment associated with the application (such as after an application upgrade), to read and decrypt its contents. Other applications or security domains, and even the operating system kernel of the secure element, cannot access its contents without authorization.

[0067] In this embodiment, by establishing an independent, uniquely identified storage unit for the encrypted data of each application, strict logical isolation of temporary data between different applications is achieved. This effectively prevents accidental access or unauthorized reading that may result from mixed data storage, thus strengthening data confidentiality from the storage structure perspective. During the data recovery phase after an application upgrade, the corresponding secure data file or object can be accurately located and retrieved based on the application identifier, avoiding errors and delays in searching through large amounts of data and ensuring the accuracy and efficiency of the recovery process.

[0068] Figure 3 This illustration shows a flowchart of another data management method for a secure element provided by an embodiment of this application. The secure element has a secure execution environment for an application deployed on it. This method can be executed by an electronic device, which may include a server and / or a terminal device, etc. In other words, the method can be executed by software or hardware installed on the server and / or terminal device, and includes the following steps: Step 210: Send an update command for the current version of the application to the security element through the trusted service management platform.

[0069] Step 220: In response to the update instruction, the secure execution environment randomly generates a temporary key and retrieves the user-specific configuration data of the current version of the application from the secure storage area of ​​the secure element.

[0070] Step 230: The secure execution environment uses the temporary key to encrypt the user-specific configuration data to obtain encrypted data, and stores the encrypted data in the secure storage area.

[0071] Step 240: The secure execution environment obtains the application key from the secure storage area, uses the application key to encrypt the temporary key to obtain the encryption key, and stores the encryption key in the secure storage area.

[0072] Steps 210-240 can be found above. Figure 1 The specific descriptions of steps 110 to 140 in the illustrated embodiment are provided, and the same technical effects can be achieved. To avoid repetition, they will not be repeated here.

[0073] Step 250: After storing the encrypted data and encryption key, the operating system of the secure element uninstalls the current version of the application, then downloads an updated version of the application from the trusted service management platform and installs the updated version of the application through the secure execution environment.

[0074] The operating system of the secure element executes an uninstallation process, removing the current version of the application from its secure execution environment. This uninstallation operation follows predefined application lifecycle management protocols, such as the GP specification, ensuring that the application is completely and securely uninstalled while releasing its runtime resources. It should be noted that this uninstallation process only targets the application's executable code and resources; it does not erase the encrypted data and encryption keys stored separately in steps 230 and 240, thus ensuring the secure retention of user-specific configuration data.

[0075] Subsequently, the secure element establishes a secure communication connection with the Trusted Service Management Platform and downloads the installation package of the updated application from the platform. The installation package is provided by the Trusted Service Management Platform and is typically digitally signed to ensure its integrity and trusted origin.

[0076] Next, the operating system of the secure element, in conjunction with the secure execution environment (SEA), executes the installation process for the updated application. Specifically, the operating system writes the application installation package data to the secure storage area and invokes the SEA to complete the installation and initialization of the new application within it. This installation process allows the new application to inherit the access permissions of the original application in the secure storage area, particularly gaining access to the encryption key (i.e., the temporary key encrypted with the application key), thereby enabling the new application to subsequently restore user-specific configuration data.

[0077] Step 260: The operating system configures the application key for the updated version application through the trusted service management platform and stores the application key in the secure storage area.

[0078] The operating system of the secure element configures the updated application with the same application key as the previous version through a trusted service management platform. Based on its key management system, the trusted service management platform regenerates or retrieves the same application key using the exact same key generation parameters and key distribution algorithm as when configuring the original application. This process ensures strict consistency of the application key before and after the version update, providing the necessary conditions for the subsequent secure recovery of encrypted temporary keys. The trusted service management platform issues a personalized instruction containing the application key to the secure element through a secure communication channel. Upon receiving the instruction, the operating system of the secure element performs security verification and parsing to extract the application key. Subsequently, the operating system securely writes the application key into the dedicated storage space allocated for the updated application in the secure storage area. During the writing process, the operating system establishes a strict binding relationship between the application key and the secure execution environment where the updated application resides, and sets corresponding access control policies to ensure that only this secure execution environment has the right to access and use this key in subsequent data processing.

[0079] Step 270: Obtain the encrypted data and encryption key from the secure storage area through the secure execution environment; decrypt the encryption key using the application key to obtain the temporary key; decrypt the encrypted data using the temporary key to obtain the user-specific configuration data; and store the user-specific configuration data in the secure storage area.

[0080] The secure execution environment retrieves the encrypted data stored in step 230 and the encryption key stored in step 240 from the secure storage area. Since the secure execution environment maintains its original security attributes and access permissions after installing the new version of the application, it can successfully pass the access control verification of the secure storage area and read these two encrypted pieces of information. Next, the secure execution environment performs a key decryption operation, using the application key configured for the updated application version in step S260 to decrypt the encryption key. Because the application key is exactly the same as the key used during encryption, the decryption operation successfully restores the plaintext of the original temporary key. Then, the secure execution environment uses the decrypted temporary key to perform a data decryption operation on the encrypted data. The decryption algorithm corresponds to the encryption algorithm used in step S230 (e.g., the AES decryption algorithm), thereby successfully restoring the encrypted data in ciphertext form to user-specific configuration data in plaintext form. Finally, the secure execution environment decrypts the obtained user-specific configuration data and rewrites it in a format and structure recognizable by the new version of the application into the designated location in the secure storage area allocated for the updated version of the application. This series of steps completes the formal migration of user data from the old version to the new version, enabling the new version of the application to immediately recognize and use this critical user configuration information.

[0081] Step 280: Delete the encrypted data, encryption key, and temporary key through the secure execution environment.

[0082] After confirming that the user-specific configuration data has been successfully restored and securely stored in the designated space of the updated application, the secure execution environment immediately initiates the cleanup process. First, the secure execution environment issues a deletion command to the secure storage area, permanently erasing the encrypted data files or data objects stored in step 230. Simultaneously, the encryption key stored in step 240 is also permanently deleted. The secure execution environment also securely erases the plaintext copy of the temporary key residing in its runtime memory. This operation is achieved through secure cleanup mechanisms such as overwriting storage areas, ensuring that the plaintext information of the temporary key is completely destroyed and unrecoverable. This cleanup process is immediate and mandatory, triggered as soon as data recovery is successful. All deletion operations are completed within the controlled environment of the secure execution environment, and the deleted data cannot be recovered by conventional means, thus eliminating the possibility of sensitive information residue at the physical level.

[0083] In this embodiment, a rigorous sequential logic—first securely storing data, then uninstalling the old application, and finally installing the new application and restoring the data—ensures that user business data is not lost during the transition from the old version to the new version of the application. When users use the new version of the application, their business status, personal settings, and key information (e.g., balance, keys) are fully preserved, facilitating seamless upgrades and greatly improving user experience and business continuity. Configuring the same application key for the updated application as the previous version ensures that the secure execution environment can decrypt the previously stored encryption key, thus forming a secure and reliable key inheritance chain. The data recovery process is entirely completed within the secure element. From reading ciphertext and decrypting keys to finally restoring user data, all sensitive operations are performed under the protection of the secure execution environment, ensuring that plaintext user data and keys remain "on the card" throughout the recovery process, forming a closed, highly secure internal data loop together with the temporary storage phase. After successful data recovery, all temporary keys and intermediate ciphertext are immediately and completely destroyed, ensuring that the lifespan of these sensitive information serving this upgrade is minimized, fundamentally preventing any possibility of these temporary data being maliciously extracted and decrypted in the future.

[0084] In yet another exemplary embodiment, see Figure 4 Using a smart card as an example, this paper provides a detailed explanation of the data recovery process.

[0085] Before proceeding with the data recovery process using a smart card, the following preparations are required: 1. Before uninstalling the application, personal data is temporarily stored. The specific process for this data storage is described above and will not be repeated here.

[0086] 2. Uninstall the old version of the application.

[0087] Detailed steps for upgrading the smart card application include the following: 1. Download the application, for example, the two APDU instructions "install for load" and "load" defined in the GP specification, and write the application installation package data to the smart card file system.

[0088] 2. Install applications, such as the install for install directive defined in the GP specification.

[0089] 3. Using personalization instructions, such as the install for personalization instruction defined in the GP specification, write the application key (KEY_APP) to the application and write KEY_APP to the smart card file system.

[0090] The detailed steps for data recovery after a smart card application upgrade include the following: 1. Smart card reading card application personal data.

[0091] 2. Returns the card application personalization data (PersonalizationData_Encrypted) stored in the smart card file system after being encrypted by KEY_PDATA.

[0092] 3. Obtain the encrypted KEY_PDATA_Encrypted.

[0093] 4. Return KEY_PDATA_Encrypted.

[0094] 5. Use KEY_APP to decrypt KEY_PDATA_Encrypted to obtain KEY_PDATA.

[0095] 6. Use KEY_PDATA to decrypt the encrypted data (PersonalizationData_Encrypted) to obtain the personalized data (PersonalizationData).

[0096] 7. Write personalized data to the smart card file system.

[0097] 8. Delete PersonalizationData_Encrypted.

[0098] 9. Delete KEY_PDATA_Encrypted and KEY_PDATA.

[0099] 10. Start the application and begin the business process (select command defined in GP specification).

[0100] In this embodiment, after the card application is upgraded, the user's personalized data can be quickly restored in a secure manner, without requiring the user to re-sign up for the service at the business operator's branch. The rapid restoration of personalized data after the card application upgrade saves upgrade time, and the service is immediately available, greatly improving the user experience, enhancing the competitiveness of smart card products, and promoting the better development of smart card-related businesses.

[0101] In yet another exemplary embodiment, the data management method for a security element may further include the following specific steps: Step 290: The trusted service management platform obtains an identifier uniquely corresponding to the security element and obtains a primary key associated with the security element; the trusted service management platform takes the identifier and primary key as input, executes a first key distribution algorithm, generates the application key based on the output of the first key distribution algorithm, and stores the application key in the secure storage area through the operating system of the security element.

[0102] This embodiment uses a smart card as an example. The application key (KEY_APP) needs to remain consistent throughout the smart card for the same application, for example, before and after an application upgrade. The KEY_APP key is obtained by distributing the smart card's primary key KEY_L1 and the smart card's unique identifier CID using a key distribution algorithm. This ensures that the same application has the same KEY_APP key within a smart card with the same smart card identifier. Since the KEY_APP key is obtained from the smart card's unique identifier and primary key using a key distribution algorithm, "one card, one key" can be achieved, thereby improving the security of the key itself.

[0103] The key distribution algorithm is a special key derivation function that takes a master key and a specific distribution factor as input and generates a new subkey that uniquely corresponds to the distribution factor through an irreversible cryptographic operation.

[0104] The process for generating application keys may include the following steps: 1. The TSM platform determines whether a unique smart card identifier (CID) already exists.

[0105] 2. If the TSM platform does not have a unique identifier for the smart card, the TSM platform initiates a process to remotely obtain the card's on-site data from the smart card.

[0106] 3. The TSM platform extracts a unique identifier (CID) from the on-site data fed back by the smart card.

[0107] 4. Use the smart card primary key (KEY_L1) and the smart card unique identifier (CID) as inputs to the key distribution algorithm for distribution.

[0108] 5. Generate the smart card application key (KEY_APP).

[0109] In this embodiment, by using the unique identifier of the security element and the primary key as common inputs to the key distribution algorithm, it is ensured that the final generated application key is strongly bound to the specific hardware security element. Even if the same application is installed on different security elements, its application key will be completely different, effectively avoiding the risk of a large-scale security incident caused by the leakage of a single key. The application key is obtained based on the unique identifier of the security element and the primary key, using the key distribution algorithm. This ensures that the application key remains unchanged for the same application on the same security element (e.g., before and after an application upgrade). This consistency is a key prerequisite for the smooth execution of subsequent security processes (e.g., recovery of encrypted temporary data), guaranteeing business continuity. The trusted service management platform centrally executes key generation and distributes it to the security element through a secure channel, ensuring both the trustworthiness of the key source and the flexibility of remote management. The application key itself does not statically exist in any external system but is dynamically generated by a trusted party as needed. Hardware uniqueness (CID), master key security (KEY_L1), and cryptographic algorithms (key distribution algorithm) are combined to ensure that the final generated application key has high strength and uniqueness.

[0110] In yet another exemplary embodiment, based on step 290, the method of this embodiment may further include the following specific steps: Obtain the master root key and multiple feature data that uniquely correspond to the security element; take the master root key and the multiple feature data as input, execute the second key distribution algorithm, generate the first-level key according to the output of the second key distribution algorithm, and pre-set the first-level key in the security element.

[0111] The master root key is a top-level, highest-secret cryptographic seed in the key hierarchy. It is not directly used to encrypt any business data, but is specifically used as the source for deriving (generating) other lower-level working keys. It is typically generated and stored in a highly secure environment by the smart card vendor or the main operator of the system (e.g., banks, government agencies), with the highest level of security protection.

[0112] The second key distribution algorithm can be implemented using a multi-level distribution algorithm model.

[0113] The process for generating the first-level key can specifically include the following steps: 1. Enter the smart card root key. The root key is usually held by the smart card vendor or the main operating unit, and its absolute security must be guaranteed.

[0114] 2. Enter smart card information, such as the Integrated Circuit Card Identifier (ICCID), card vendor code, card number, serial number, Security Chip Identifier (SEID), and other information unique to each smart card.

[0115] 3. Generate the smart card primary key (KEY_L1) through a series of key distribution algorithms. To ensure the security of the primary key, multi-level distribution can be implemented. One of the smart card information inputs at each level is used as input one of the key distribution algorithms at this level, and the distribution result of the previous level is used as input two of the key distribution algorithm at this level.

[0116] 4. Obtain the smart card primary key (KEY_L1). Following the above method, one key per card can be achieved, thereby ensuring the uniqueness and security of the primary key.

[0117] 5. The smart card primary key (KEY_L1) obtained through distribution needs to be pre-installed into the card by the card manufacturer during the card production stage along with other necessary pre-installed data. At the same time, it is necessary to ensure the confidentiality and security of key transmission, as well as the security of the key pre-installation process.

[0118] The implementation details of the multi-level distributed algorithm model are as follows: 1. First-level distribution algorithm: The result of the first-level distribution algorithm is L1-S. L1-S is used as the input L2-I1 of the second-level distribution algorithm, where L2-I1=L1-S.

[0119] 2. The second-level distribution algorithm, in addition to L2-I1 generated in the first level as input one, adds a second-level input two L2-I2. After the distribution algorithm, the result of the second level is L2-S. L2-S is used as the input of the third level L3-I1, where L3-I1=L2-S.

[0120] 3. Repeat the above steps to implement the multi-level distribution algorithm.

[0121] 4. The final distribution result is obtained through the last-level distribution algorithm and used as the first-level key (KEY_L1).

[0122] In this embodiment, a key derivation hierarchy is constructed, consisting of a root key, a primary key, and application keys. This separates the core master key from frequently used application-level keys, thereby achieving fine-grained key management and effective isolation of security risks, in line with the design principles of high-security systems.

[0123] This application provides a method for secure temporary storage and recovery of personal data from smart cards. It is applicable to the temporary storage and recovery of personalized data in scenarios such as application upgrades. Employing a highly secure data temporary storage and recovery mechanism, it utilizes a unique key for each card and a key-free system to achieve a higher level of security, effectively ensuring the security of user's personalized data and addressing the problems of existing technical solutions. Unlike existing cloud backup solutions, this application focuses on local storage. Local storage offers two advantages: firstly, security, reducing the risk of data leakage due to the transfer of personal data from the smart card to the cloud server; and secondly, faster recovery speed for personal data stored locally on the smart card. Unlike existing local backup solutions, the data management method in this application primarily improves the security of personal data storage and the speed of personal data recovery through higher-security storage of smart card personal data, a unique key for each card, key-free key, secure key storage, and multi-level distribution of application keys. This enhances the security of personal data storage and the speed of personal data recovery, thereby improving the security and user experience of applications involving temporary storage of personal data, such as upgrades. This application embodiment achieves key non-disappearance by encrypting and storing the encryption key itself, and the key for encrypting personalized data is generated randomly. The randomly generated key has the characteristics of being temporary, short-lived, and invalid and destroyed after a single use, which improves the overall security of data encryption and storage, and has originality and great innovation.

[0124] Corresponding to the data management method for a secure element provided in the above embodiments, based on the same technical concept, this application also provides a data management system for a secure element, wherein a secure execution environment for an application is deployed on the secure element. See also Figure 5 The system 400 includes an instruction receiving module 410, a key generation module 420, a data acquisition module 430, and a data backup module 440.

[0125] The instruction receiving module 410 is used to issue an update instruction for the current version of the application to the secure element through the trusted service management platform; the key generation module 420 is used for the secure execution environment to respond to the update instruction and randomly generate a temporary key; the data acquisition module 430 is used to acquire user-specific configuration data of the current version of the application from the secure storage area of ​​the secure element; the data backup module 440 is used for the secure execution environment to encrypt the user-specific configuration data using the temporary key to obtain encrypted data and store the encrypted data in the secure storage area, and for the secure execution environment to acquire the application key from the secure storage area, encrypt the temporary key using the application key to obtain an encryption key, and store the encryption key in the secure storage area.

[0126] It should be noted that the data management system for the security element provided in this application embodiment and the data management method for the security element provided in this application embodiment are based on the same application concept. Therefore, the specific implementation of this embodiment can refer to the implementation of the data management method for the security element described above, and the repeated parts will not be described again.

[0127] In yet another exemplary embodiment, the system 400 further includes an application module and a data recovery module.

[0128] The application module is used to, after storing the encrypted data and encryption key, for the operating system of the secure element to uninstall the current version of the application, then download an updated version of the application from the trusted service management platform and install the updated version of the application through the secure execution environment, and for the operating system to configure the application key for the updated version of the application through the trusted service management platform and store the application key in the secure storage area.

[0129] The data recovery module is used by the secure execution environment to obtain the encrypted data and encryption key from the secure storage area, decrypt the encryption key using the application key to obtain the temporary key, decrypt the encrypted data using the temporary key to obtain the user-specific configuration data, store the user-specific configuration data in the secure storage area, and delete the encrypted data, encryption key, and temporary encryption key.

[0130] In this embodiment, a secure data storage and recovery mechanism is provided for user-specific configuration data within the secure element in scenarios such as application upgrades, through a data backup module and a data recovery module, which can ensure the security of users' personalized data.

[0131] Corresponding to the data management method for the security element provided in the above embodiments, based on the same technical concept, this application also provides a security element. The security element includes the following: processor; Secure storage area; An operating system, running on the processor, wherein the operating system is configured to perform the steps executed by the operating system in the methods described in the above embodiments; A secure execution environment, created and isolated by the operating system, is configured to perform the steps executed by the secure execution environment in the methods described in the above embodiments.

[0132] The processor, as the computing core of the security element, is responsible for executing instructions and processing data. The processor can be a microprocessor.

[0133] The secure storage area is coupled to the processor and is used to securely store data, including but not limited to application code, user-specific configuration data (e.g., personal data), encrypted data, encryption keys, and key materials at all levels.

[0134] The operating system runs on the processor and is used to manage the hardware resources of the secure element, execute instruction scheduling, and provide basic security services. The operating system is configured to perform steps as described in any of the above method embodiments, including but not limited to: establishing secure communication with the trusted remote service management platform, receiving and parsing management instructions, and managing the lifecycle of applications (e.g., application installation and uninstallation).

[0135] The secure execution environment is created and isolated by the operating system, providing a protected execution space for applications. The secure execution environment is configured to perform steps as described in any of the above method embodiments, including but not limited to: randomly generating a temporary key in response to an update instruction, performing encryption and decryption operations on data, performing encryption and decryption operations on the key, and controlling access to the secure storage area. The secure execution environment may be an auxiliary security domain conforming to the GP specification.

[0136] The security element in this embodiment, by decomposing and embedding the steps of the above method embodiments into specific hardware and software components, forms a physical entity capable of independently, securely, and efficiently managing application data. The security element can be independently packaged as a chip (e.g., a smart card chip, eSE chip, etc.), or it can be integrated as a security core into more complex computing devices (e.g., mobile phones, IoT devices, etc.).

[0137] Corresponding to the data management method for security elements provided in the above embodiments, based on the same technical concept, this application also provides an electronic device for executing the above method. Figure 6 To illustrate the structure of an electronic device according to various embodiments of this application, as shown in the following diagrams... Figure 6 As shown. Electronic device 500 can vary considerably due to differences in configuration or performance, and may include one or more processors 510 and memory 520. Memory 520 may store one or more application programs or data. Memory 520 may be temporary or persistent storage. The application programs stored in memory 520 may include one or more modules (not shown), each module may include a series of computer-executable instructions for the electronic device. Furthermore, processor 510 may be configured to communicate with memory 520 and execute the series of computer-executable instructions stored in memory 520 on the electronic device.

[0138] This application also provides a computer program product, which includes a computer program stored on a non-transitory computer-readable storage medium. The computer program includes program instructions, which, when executed by a computer, implement the steps of the data management method for the security element as described above.

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

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

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

[0142] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0143] In a typical configuration, an electronic device includes one or more processors (CPU), input / output interfaces, network interfaces, and memory.

[0144] Memory may include non-persistent storage in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM. Memory is an example of computer-readable media.

[0145] Computer-readable media includes both permanent and non-permanent, removable and non-removable media that can store information using any method or technology. Information can be computer-readable instructions, data structures, modules of programs, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, magnetic magnetic disk storage or other magnetic storage devices, or any other non-transferable medium that can be used to store information accessible by a computing device. As defined herein, computer-readable media does not include transient computer-readable media, such as modulated data signals and carrier waves.

[0146] It should also be noted that the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

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

[0148] The above description is merely an embodiment of this application and is not intended to limit the scope of this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of the claims of this application.

Claims

1. A data management method for a secure element, wherein a secure execution environment for an application is deployed on the secure element, characterized in that, The method includes the following steps: The Trusted Service Management Platform issues an update command for the current version of the application to the secure element; In response to the update command, the secure execution environment randomly generates a temporary key and retrieves the user-specific configuration data of the current version of the application from the secure storage area of ​​the secure element; The secure execution environment uses the temporary key to encrypt the user-specific configuration data to obtain encrypted data, and stores the encrypted data in the secure storage area; The secure execution environment obtains the application key from the secure storage area, uses the application key to encrypt the temporary key to obtain an encryption key, and stores the encryption key in the secure storage area.

2. The method according to claim 1, characterized in that, The method further includes the following steps: The application key is configured for the current version of the application through the trusted service management platform, and the application key is stored in the secure storage area by the operating system of the secure element.

3. The method according to claim 1, characterized in that, The method further includes the following steps: After storing the encrypted data and encryption key, the operating system of the secure element uninstalls the current version of the application, then downloads an updated version of the application from the trusted service management platform and installs the updated version of the application through the secure execution environment; The operating system configures the application key for the updated version application through the trusted service management platform and stores the application key in the secure storage area; The encrypted data and encryption key are obtained from the secure storage area through the secure execution environment, the encryption key is decrypted using the application key to obtain the temporary key, the encrypted data is decrypted using the temporary key to obtain the user-specific configuration data, and the user-specific configuration data is stored in the secure storage area. The encrypted data, encryption key, and temporary key are deleted through the secure execution environment.

4. The method according to claim 1, characterized in that, The method further includes the following steps: The trusted service management platform obtains an identifier that uniquely corresponds to the security element, and obtains a primary key associated with the security element; The trusted service management platform takes the identifier and the primary key as input, executes the first key distribution algorithm, generates the application key based on the output of the first key distribution algorithm, and stores the application key in the secure storage area through the operating system of the secure element.

5. The method according to claim 4, characterized in that, The method further includes the following steps: Obtain the master root key and multiple feature data uniquely corresponding to the security element; The primary root key and the plurality of feature data are used as inputs to execute a second key distribution algorithm. The primary key is generated based on the output of the second key distribution algorithm and is then pre-installed in the secure element.

6. A data management system for a secure element, wherein a secure execution environment for an application is deployed on the secure element, characterized in that, The system includes the following: The instruction receiving module is used to send an update instruction for the current version of the application to the security element through the trusted service management platform; A key generation module is used by the secure execution environment to randomly generate a temporary key in response to the update command; The data acquisition module is used to acquire user-specific configuration data of the current version of the application from the secure storage area of ​​the secure element; The data backup module includes a secure execution environment that uses the temporary key to encrypt the user-specific configuration data to obtain encrypted data and stores the encrypted data in the secure storage area. It also includes a secure execution environment that obtains an application key from the secure storage area, uses the application key to encrypt the temporary key to obtain an encryption key, and stores the encryption key in the secure storage area.

7. The system according to claim 6, characterized in that, The system also includes the following: The application module is used to, after storing the encrypted data and encryption key, for the operating system of the secure element to uninstall the current version of the application, then download an updated version of the application from the trusted service management platform and install the updated version of the application through the secure execution environment, and for the operating system to configure the application key for the updated version of the application through the trusted service management platform and store the application key in the secure storage area; The data recovery module is used by the secure execution environment to obtain the encrypted data and encryption key from the secure storage area, decrypt the encryption key using the application key to obtain the temporary key, decrypt the encrypted data using the temporary key to obtain the user-specific configuration data, store the user-specific configuration data in the secure storage area, and delete the encrypted data, encryption key, and temporary encryption key.

8. A safety element, characterized in that, include: processor; Secure storage area; An operating system running on the processor, wherein the operating system is configured to perform the steps executed by the operating system in any one of claims 1 to 5; A secure execution environment, created and isolated by the operating system, wherein the secure execution environment is configured to perform the steps executed by the secure execution environment in the method as described in any one of claims 1 to 5.

9. An electronic device, characterized in that, It includes a processor, a memory, a program or instructions stored in the memory and executable on the processor, wherein the program or instructions, when executed by the processor, implement the steps of the method as described in any one of claims 1 to 5.

10. A computer program product, characterized in that, The computer program product includes a computer program stored on a non-transitory computer-readable storage medium, the computer program including program instructions that, when executed by a computer, implement the steps of the method as described in any one of claims 1 to 5.

Images