A method for dynamic data sharing using smart cards

Abstract

This invention provides a method for dynamic data sharing in smart cards. The method sets the data sharing range when a first instance is personalized, and presets the data sharing range when a second instance is personalized. It then determines whether the sharing range of the first instance is greater than that of the second instance. If so, the current sharing range of the second instance is determined. When data from the second instance is subsequently needed, if the data to be obtained is shared data, the corresponding data in the first instance is retrieved. This invention solves the problem in existing technologies where data sharing between instances is not flexible enough, and it cannot dynamically configure which data is not shared and which is shared.

Description

Technical Field

[0001] This invention relates to the field of smart card technology, specifically to a method for dynamic sharing of smart card data. Background Technology

[0002] Currently, smart card technology is relatively mature and can support various applications, especially in the financial sector, where it is widely used. Various domestic and international debit and credit financial applications utilize smart cards. Personalized data in these applications is often in BER-TLV format, or it may only contain the data value.

[0003] In a smart card, the application code implemented according to the application specification is called an application (Applet). Only after installing an instance of the application through the GP (Global Platform) installation command can it be used as an application instance. After successful installation, the application can be selected by selecting the instance AID. After successful selection, the personalization process and subsequent transaction operations can be executed.

[0004] In financial applications, there is often a need for data sharing among multiple instances, such as data sharing between multiple instances of a single application or data sharing between instances of different applications. Existing solutions for this multi-instance data sharing problem typically involve pre-defining the application dataset A to be shared, with multiple instances sharing all data content in application dataset A. This approach lacks the flexibility to configure which application data is used for sharing and which is not, limiting the flexibility of data sharing and preventing dynamic data sharing. Summary of the Invention

[0005] The first objective of this invention is to provide a method for dynamically sharing smart card data.

[0006] A second objective of this invention is to provide another method for dynamically sharing smart card data.

[0007] To achieve the aforementioned first objective, the present invention provides a method for dynamic sharing of smart card data, comprising: when a first instance performs personalization: the first instance receives a first sharing instruction, the first sharing instruction including a first tag; the first instance changes the state of the first sharing identifier bit of the first personalized data corresponding to the first tag to a first allowed sharing state; when a second instance performs personalization: the second instance receives a second sharing instruction, the second sharing instruction including a second tag; the second instance sends each second tag to the first instance through a first interface, and the first instance determines whether the following conditions are met: each second tag has a corresponding third tag in the first instance, and the third personalized data corresponding to the third tag is in a first allowed sharing state; if met, the first allowed result is returned to the second instance; after receiving the first allowed result, the second instance changes the state of the second sharing identifier bit of the second personalized data corresponding to the second tag to a second allowed sharing state; when the second instance needs to interact with the data content of the fourth personalized data of the second instance: the second instance determines whether the fourth sharing identifier bit of the fourth personalized data is in a second allowed sharing state; if so, it interacts with the data content of the fifth personalized data corresponding to the fifth tag of the fourth personalized data in the first instance.

[0008] As can be seen from the above scheme, the present invention can flexibly configure the first personalized data in the first instance that needs to be shared with other instances, and the second personalized data in the second instance that needs to share the first personalized data of the first instance. When subsequent instances interact with each other, the second instance can determine whether the fourth personalized data to be interacted with needs to be shared based on the first and second allowed sharing states. The present invention solves the problem of inflexible data sharing methods between instances in the prior art, namely, the inability to dynamically configure which data should not be shared and which should be shared.

[0009] A further approach is that, before interacting with the data content of the fifth personalized data, the first instance determines whether the fifth sharing flag of the fifth personalized data is in the first allowed sharing state. If so, the second instance interacts with the data content of the fourth personalized data.

[0010] This demonstrates that it can ensure the stability of data sharing and reduce errors.

[0011] A further solution is that when the second instance interacts with the data content of the fifth personalized data of the first instance, it reads the data content of the fifth personalized data through the second interface and / or updates the data content of the fifth personalized data of the first instance through the third interface.

[0012] Therefore, it can be seen that the fifth person's personalized data can be read and / or updated through different interfaces.

[0013] A further approach is that before the second instance interacts with the fifth personalized data content, the second instance and the first instance perform security authentication.

[0014] This demonstrates that data sharing between different instances can be guaranteed to occur in a secure environment.

[0015] A further approach is that before the second instance interacts with the fifth personalized data, read / write permission authentication is performed between the second instance and the first instance.

[0016] This demonstrates that data sharing between different instances can be guaranteed to occur in a secure environment.

[0017] To achieve the second objective mentioned above, the present invention provides a method for dynamic sharing of smart card data, wherein: when the first instance is personalized: the first instance determines whether it has received a first sharing instruction; if not, the first instance changes the first sharing identifier bit of the first personalized data of the first instance to a first allowed sharing state; when the second instance is personalized: the second instance receives a second sharing instruction, the second sharing instruction including a second tag; the second instance sends each second tag to the first instance through a first interface, and the first instance determines whether the following conditions are met: each second tag has a corresponding third tag in the instance, and the third personalized data corresponding to the third tag is in a first allowed sharing state; if met, the first allowed result is returned to the second instance; after receiving the first allowed result, the second instance changes the state of the second sharing identifier bit of the second personalized data corresponding to the second tag to a second allowed sharing state; when the second instance needs to interact with the data content of the fourth personalized data of the second instance: the second instance determines whether the fourth sharing identifier bit of the fourth personalized data is in a second allowed sharing state; if so, it interacts with the data content of the fifth personalized data corresponding to the fifth tag of the fourth personalized data in the first instance.

[0018] As can be seen from the above solution, the present invention solves the problem of inflexible data sharing methods between instances in the prior art, namely, the inability to dynamically configure which data should not be shared and which data should be shared. Attached Figure Description

[0019] Figure 1 This is a data block diagram of multiple instances of the first embodiment of the smart card data dynamic sharing method of the present invention.

[0020] Figure 2 This is a flowchart of the first embodiment of the smart card data dynamic sharing method of the present invention.

[0021] Figure 3 This is a flowchart illustrating the personalization process in the first instance of the smart card data dynamic sharing method of the present invention.

[0022] Figure 4 This is a flowchart illustrating the personalization process in the second instance of the first embodiment of the smart card data dynamic sharing method of the present invention.

[0023] Figure 5 This is a flowchart illustrating the process of reading personalized data from a second instance in the first embodiment of the smart card data dynamic sharing method of the present invention.

[0024] Figure 6 This is a flowchart illustrating the process of updating the personalized data of a second instance in the first embodiment of the smart card data dynamic sharing method of the present invention.

[0025] Figure 7 This is a flowchart illustrating the personalization process in the first instance of the second embodiment of the smart card data dynamic sharing method of the present invention.

[0026] The present invention will be further described below with reference to the accompanying drawings and embodiments. Detailed Implementation

[0027] This invention determines the personalized data that needs to be shared in the first instance and the second instance by setting a first allowed sharing state for the first instance and a second shared state for the second instance, thereby configuring dynamic data sharing between different instances.

[0028] First embodiment of the method for dynamic sharing of smart card data:

[0029] See Figure 1 In this embodiment, all application instances participating in data sharing store application data in a fixed format: Indicator, Tag, Length, and Value. Here, Indicator is the data sharing identifier, indicating whether data sharing is allowed; Tag is the data identifier (label); Length is the data length; and Value is the data content. For existing BER-TLV formats in smart cards and data containing only Value, both can be stored in a fixed format. Figure 1 The data is stored in a fixed format. For data that is only a value, the application can define a private tag for the data to store it in accordance with the above fixed format.

[0030] See Figure 2 To implement the smart card data dynamic sharing method of this embodiment, step S1 is first executed, whereby the first instance defines the scope of shared data during personalization. The first instance is the instance used to share its personalized data with other instances. Among all application instances participating in data sharing, the first instance needs to be personalized first, personalizing the complete data and defining the scope of data that can be shared during the personalization stage.

[0031] The first instance provides the following interfaces for the second instance to call:

[0032] 1) The first interface isTagListShareable(tagList) is used to check whether the tag list is allowed to be shared. The second instance calls this interface to determine whether the tags that the second instance needs to share are allowed by the first instance.

[0033] 2) The second interface, getTagListValue(tagList), is used to return the data content corresponding to the tag. The second instance obtains the data content corresponding to the tag of the first instance by calling this interface.

[0034] 3) The third interface setTagListValue(TLVList) is used to update the data content of the first instance. The second instance provides the ability to call this interface to update the data content of the first instance.

[0035] Then, step S2 is executed, where the second instance defines the shared data scope during personalization. The second instance is the instance that needs to obtain personalized data from the shared data scope of the first instance, and there can be one or more instances. During personalization, the second instance can flexibly determine the shared data scope, that is, decide which personalized data on the second instance needs to be obtained from the first instance.

[0036] Finally, step S3 is executed, where the second instance interacts with the first instance. That is, during the use of the smart card, when it is necessary to interact with the fourth personalized data on the second instance of the smart card, the data content of the fourth personalized data is the personalized data that the second instance needs to obtain. If the data sharing flag on the fourth personalized data is in the "can be shared" state, then the corresponding personalized data can be obtained from the first instance at this time, and interaction with the personalized data can be performed.

[0037] The smart card data dynamic sharing method of this embodiment is further described below:

[0038] When the first instance defines the scope of shared data during personalization, i.e., when executing step S1, see [link to relevant documentation]. Figure 3 First, step S11 is executed, whereby the first instance receives the first sharing instruction. The first sharing instruction is an APDU instruction that sets the data sharing scope of the first instance. This instruction includes a first tag set, which represents the set of tags of personalized data that need to be shared in the first instance. The data field of this instruction is a collection of tags, such as Tag1, Tag3, ... Tagi, and the first tag is any one of these tags.

[0039] Continuing with step S12, the first instance changes the state of the first shared identifier bit of the first personalized data corresponding to the first tag to the first allowed-to-share state. Specifically, the first instance marks the first shared identifier bit (Indicator) of the first personalized data corresponding to all first tags in the first tag set as "shareable". Only personalized data marked as "shareable" can be shared with other instances.

[0040] Optionally, the first sharing identifier can also be configured with different sharing ranges for different instances. In this case, the first sharing instruction also includes the instance identifier, and the first tag set corresponds to the instance identifier. For example, if the personalized data corresponding to Tag1 can be accessed by the second, third, and fourth instances, then the indicator for the personalized data corresponding to Tag1 is marked as "can be shared by the second / third / fourth instances". If the personalized data corresponding to Tag2 can be shared by the second and fourth instances, then the indicator for the personalized data corresponding to Tag2 is marked as "can be shared by the second / fourth instances".

[0041] In the second instance, when defining the scope of shared data during personalization, i.e., when executing step S2, see [link to relevant documentation]. Figure 4 First, step S21 is executed, whereby the second instance receives the second sharing instruction. The second sharing instruction is also an APDU instruction that sets the scope of shared data. This instruction includes a second tag set, which is a collection of tags corresponding to the personalized data to be shared in the second instance. The second tag represents any tag in the second tag set.

[0042] Then, step S22 is executed, whereby the second instance sends each second tag to the first instance through the first interface.

[0043] Continuing with step S23, the first instance determines whether each second tag has a corresponding third tag in the first instance, and whether the third personalized data corresponding to the third tag is in the first allowed-sharing state. Specifically, the third tag is the same tag as the second tag in the first tag set, such as the second tag being Tag1 and the third tag being Tag1. If the third tag exists, and the third sharing flag of the third personalized data corresponding to the third tag is in the first allowed-sharing state, i.e., "can be shared," then proceeding to step S24, the allowed result is returned to the second instance. The allowed result means that the second personalized data corresponding to each second tag is allowed to share the first personalized data in the first instance. If not, it indicates that personalization has failed, the current personalization ends, and the instance waits for another personalization attempt.

[0044] Continuing with step S25, after the second instance receives the permission result, it changes the second sharing identifier bit of the second humanized data corresponding to the second tag to the second allowed sharing state. Specifically, it marks the second sharing identifier bit of the second humanized data as "can be shared".

[0045] When the second instance interacts with the first instance, i.e., when step S3 is executed, if the second instance needs to read data from the first instance, refer to... Figure 5 First, step S31 is executed, where the second instance determines whether the fourth sharing flag of the fourth personalized data is in the second allowed sharing state. Specifically, when the second instance needs to read the data content of the fourth personalized data, it finds the fourth personalized data based on its tag and determines whether the fourth sharing flag of the fourth personalized data is in the second allowed sharing state, i.e., the "can be shared" state. If so, it means that the data content of the fourth personalized data to be obtained needs to share the data content of the fifth personalized data corresponding to the fourth tag in the first instance (e.g., both the fourth and fifth tags are Tag4), i.e., the data content of the fifth personalized data is read as the data content of the fourth personalized data to be read, and step S32 is executed. If not, it means that the data content of the fourth personalized data does not need to be shared, and step S39 is executed, where the second instance directly reads the data content of the fourth personalized data.

[0046] If the judgment result of S31 is yes, proceed to step S32, whereby the first instance and the second instance perform security authentication and / or read permission authentication. Specifically, the first instance requires the second instance to perform a security authentication agreed upon by both parties, such as authenticating the security of the working environment; and / or the first instance performs agreed-upon permission authentication for the second instance to read data, thereby further enhancing the security of data sharing. For example, the first instance may pre-set a list containing the correspondence between read permissions and the identifiers of other instances. This correspondence indicates that only specific instances can read the first instance's personalized data. Thus, during read / write permission authentication, the first instance can authenticate the second instance's read permission, and upon successful authentication, allow the second instance to read the first instance's personalized data.

[0047] Continue executing step S33, whereby the second instance requests the data content of the fifth personalized data corresponding to the fifth tag corresponding to the fourth tag through the second interface.

[0048] Then, step S34 is executed, where the first instance determines whether the fifth sharing flag of the fifth personalized data is in the first allowed sharing state. Specifically, it determines whether the fifth sharing flag is in the "can be shared" state. If yes, proceed to step S35. If no, proceed to step S37, where the first instance returns the read exception status code to the second instance, and then to step S38, where the second instance obtains the read exception status code, indicating that the read has failed.

[0049] Then, step S35 is executed, whereby the first instance returns the data content of the fifth personalized data to the second instance.

[0050] Then, step S36 is executed, where the second instance reads the data content of the fifth personalized data. This data reading operation is now complete.

[0051] If the second instance needs to update the data of the first instance, and the second instance needs to update the data content of the fourth personalized data in the second instance, refer to... Figure 6 First, step S41 is executed, where the second instance determines whether the fourth sharing identifier of the fourth personalized data is in the second allowed sharing state. Specifically, when the second instance needs to update the data content of the fourth personalized data, it finds the fourth personalized data based on its tag and determines whether the fourth sharing identifier of the fourth personalized data is in the second allowed sharing state, i.e., the "can be shared" state. If so, it means that the data content of the fourth personalized data to be updated needs to share the data content of the fifth personalized data corresponding to the fifth tag in the first instance, i.e., the data content of the fifth personalized data is updated as the data content of the fourth personalized data to be updated, and step S42 is executed. If not, it means that the data content of the fourth personalized data does not need to be shared, and step S49 is executed, where the second instance directly updates the data content of the fourth personalized data.

[0052] If the judgment result of step S41 is yes, proceed to step S42, whereby the first instance and the second instance perform security authentication and / or update permission authentication. Specifically, the first instance requires the second instance to perform the security authentication agreed upon by both parties, and / or the first instance performs the agreed permission authentication for the second instance regarding data updates, thereby further enhancing the security of data sharing.

[0053] Continue executing step S43, whereby the second instance requests an update to the data content of the fifth personalized data corresponding to the fifth tag corresponding to the fourth tag through the third interface.

[0054] Then, step S44 is executed, where the first instance determines whether the fifth sharing identifier of the fifth personalized data is in the first allowed sharing state. Specifically, it determines whether the fifth sharing identifier is in the "can be shared" state. If yes, proceed to step S45. If no, proceed to step S47, where the first instance returns an update exception status code to the second instance, and step S48, where the second instance obtains the update exception status code, indicating that the data update failed.

[0055] In step S45, the first instance updates the fifth personalized data and returns a success status code to the second instance.

[0056] In step S46, the second instance obtains the update success status code. At this point, the data update is successful, and the data update operation is complete.

[0057] Thus, this embodiment enables dynamic data sharing between the first instance and the second instance.

[0058] Second embodiment of the smart card data dynamic sharing method:

[0059] The difference between this embodiment and the first embodiment is that, when personalizing in the first embodiment, see [link to first embodiment]. Figure 7 Before executing step S11, step S51 is executed, in which the first instance determines whether it has received the first sharing instruction. Specifically, if the first instance does not receive the first sharing instruction within a preset time, it is assumed that all personalized data in the first instance can be shared. In this case, the first tag set includes the tags of all personalized data in the first instance, and the first tag represents the tag of any personalized data in the first instance. The first personalized data can be any personalized data in the first instance. In this case, step S52 is executed. Otherwise, step S11 is executed, which will not be described in detail.

[0060] In step S52, the first instance changes the first shared identifier bit of the first humanized data of the first instance to the first allowed state.

[0061] In summary, this invention sets the data sharing scope when the first instance is personalized, and presets the data sharing scope when the second instance is personalized, determining whether the sharing scope of the first instance is greater than that of the second instance. If so, the current sharing scope of the second instance can be determined. When data from the second instance is subsequently needed, if the data to be obtained is shared data, the corresponding data in the first instance is retrieved. This invention solves the problem in the prior art where the data sharing method between instances is not flexible enough, i.e., it cannot dynamically configure which data is not shared and which data is shared.

Claims

1. A method for dynamic data sharing using smart cards, characterized in that, include: When the first instance is personalized: The first instance receives a first sharing instruction, the first sharing instruction including a first tag; The first instance changes the state of the first shared identifier bit of the first humanized data corresponding to the first tag to the first allowed sharing state; When the second instance is personalized: The second instance receives a second sharing instruction, the second sharing instruction including a second tag; The second instance sends each second tag to the first instance through the first interface. The first instance determines whether the following conditions are met: each second tag has a corresponding third tag in the first instance, and the third humanized data corresponding to the third tag is the first allowed sharing state. If the conditions are met, the first allowed result is returned to the second instance. After receiving the permission result, the second instance changes the state of the second sharing identifier bit of the second humanized data corresponding to the second tag to the second allowed sharing state; When the second instance needs to interact with the data content of the fourth personalized data of the second instance: The second instance determines whether the fourth sharing identifier of the fourth personalized data is in the second allowed sharing state. If so, it interacts with the data content of the fifth personalized data corresponding to the fifth tag of the fourth personalized data in the first instance.

2. The smart card data dynamic sharing method as described in claim 1, characterized in that: Before interacting with the data content of the fifth personalized data, the first instance determines whether the fifth sharing identifier of the fifth personalized data is in the first allowed sharing state. If so, the second instance interacts with the data content of the fourth personalized data.

3. The smart card data dynamic sharing method as described in claim 1 or 2, characterized in that: When the second instance interacts with the data content of the fifth personalized data of the first instance, it reads the data content of the fifth personalized data through the second interface and / or updates the data content of the fifth personalized data of the first instance through the third interface.

4. The smart card data dynamic sharing method as described in claim 1 or 2, characterized in that: Before the second instance interacts with the data content of the fifth personalized data, the second instance and the first instance perform security authentication.

5. The smart card data dynamic sharing method as described in claim 1 or 2, characterized in that: Before the second instance interacts with the data content of the fifth personalized data, the second instance and the first instance perform read and write permission authentication.

6. A method for dynamic data sharing using smart cards, characterized in that: When the first instance is personalized: The first instance determines whether it has received the first sharing instruction. If not, the first instance changes the first sharing flag of the first humanized data of the first instance to the first allowed sharing state. When the second instance is personalized: The second instance receives a second sharing instruction, the second sharing instruction including a second tag; The second instance sends each second tag to the first instance through the first interface. The first instance determines whether the following conditions are met: each second tag has a corresponding third tag in the instance, and the third humanized data corresponding to the third tag is the first allowed sharing state. If the conditions are met, the first allowed result is returned to the second instance. After receiving the first permission result, the second instance changes the state of the second sharing identifier bit of the second humanized data corresponding to the second tag to the second permission sharing state; When the second instance needs to interact with the data content of the fourth personalized data of the second instance: The second instance determines whether the fourth sharing identifier of the fourth personalized data is in the second allowed sharing state. If so, it interacts with the data content of the fifth personalized data corresponding to the fifth tag corresponding to the fourth tag of the fourth personalized data in the first instance.

Images