A data sharing permission verification method and device, a storage medium and a smart card

Abstract

The application provides a data sharing permission verification method and device, a storage medium and a smart card, which can be applied to a smart card installed with a first application instance and a second application instance. The first application instance is configured with a first key, and the second application instance is configured with a second key. When performing sharing permission verification, the first application instance can perform encryption calculation on a random number by using the first key to generate first encrypted data. The second application instance can perform encryption calculation on the same random number by using the second key to generate second encrypted data. The second application instance can verify whether the first application instance has sharing permission based on the first encrypted data and the second encrypted data. In this way, when a business is expanded, a new application instance only needs to be configured with a corresponding key to grant the application instance sharing permission, so that the application instance becomes a sharing application instance and can access the data of the second application instance, thereby the sharing application instance can be more flexibly expanded.

Description

Technical Field

[0001] The present application relates to the field of smart card technology, and in particular to a data sharing authority verification method, device, storage medium and smart card. Background Art

[0002] With the development and popularization of smart card technology, smart cards are carrying an increasing number of application instances, supporting multiple uses of a single card. For example, smart cards can carry public transportation payment applications corresponding to different cities and / or bank payment applications corresponding to different banks.

[0003] Considering the need for data sharing between different application instances of a smart card, the prior art proposes a data sharing solution using a shared interface object. During data sharing between a first application instance and a second application instance, the first application instance can obtain the shared interface object of the second application instance and access the data of the second application instance through this shared interface object. This approach has the advantages of simple execution and high data acquisition efficiency. However, in this implementation, in addition to the first application instance, the remaining application instances can also obtain the shared interface object of the second application instance and access the data of the second application instance accordingly. The second application instance has no permission restrictions for this, which poses certain security risks.

[0004] To address the above issues, existing technologies also provide data sharing solutions that verify permissions based on an AID (Application Identifier) ​​list. In a specific implementation, a list of AIDs supporting data sharing can be pre-configured in the second application instance. During data sharing between a first application instance and a second application instance, the second application instance can first check whether the AID corresponding to the first application instance is in the AID list. If so, the second application instance allows the first application instance to access the second application instance's data, thus enabling data sharing. Otherwise, the second application instance denies the first application instance access to the data.

[0005] While the above implementation can provide permission control, once the AID list is determined, the shared application instances that can share data with the second application instance are also determined. If the number of shared application instances needs to be expanded, the AID list of the second application instance needs to be modified, which has a low flexibility and is not conducive to business expansion. Summary of the Invention

[0006] The purpose of this application is to solve at least one of the above-mentioned technical deficiencies, especially the technical deficiencies in the prior art that are low in flexibility and unfavorable for business expansion.

[0007] In a first aspect, an embodiment of the present application provides a data sharing permission verification method, which is applied to a smart card installed with a first application instance and a second application instance, wherein the first application instance is configured with a first key and the second application instance is configured with a second key; the method includes:

[0008] The first application instance sends a data sharing request to the second application instance;

[0009] In response to the data sharing request, the second application instance determines whether sharing permission verification needs to be performed;

[0010] In the case where sharing permission verification needs to be performed, the second application instance returns a random number to the first application instance;

[0011] The first application instance performs encryption calculation on the random number according to the first key to obtain first encrypted data;

[0012] The first application instance sends the first encrypted data to the second application instance;

[0013] The second application instance encrypts and calculates the random number according to the second key to obtain second encrypted data, and verifies whether the first application instance has sharing permission based on the first encrypted data and the second encrypted data;

[0014] The second application instance returns corresponding response data to the first application instance according to the verification result.

[0015] In one embodiment, the second application instance returns corresponding response data to the first application instance according to the verification result, including:

[0016] If the verification result reflects that the first application instance has sharing permission, the second application instance generates and stores a session token;

[0017] The second application instance returns the session token to the first application instance, so that the first application instance accesses data of the second application instance based on the session token.

[0018] In one embodiment, after the second application instance generates and stores the session token, the second application instance further includes:

[0019] The second application instance records verification information corresponding to the session token; the verification information is used to verify the validity of the session token.

[0020] In one embodiment, the verification information is a transaction count value corresponding to when the first application instance generates the session token, and / or a transaction count value corresponding to when the second application instance generates the session token.

[0021] In one embodiment, the data sharing request is a token acquisition request or a data access request, and the data access request carries an available session token corresponding to the first application instance;

[0022] The second application instance determines whether sharing permission verification needs to be performed, including:

[0023] If the data sharing request is the token acquisition request, the second application instance determines that sharing permission verification needs to be performed;

[0024] If the data sharing request is a data access request, the second application instance performs validity verification on the available session token according to the verification information. If the validity verification passes, it is determined that sharing permission verification does not need to be performed; otherwise, it is determined that sharing permission verification needs to be performed.

[0025] In one embodiment, the data sharing request is a token acquisition request or a data access request;

[0026] The first application instance sending a data sharing request to the second application instance includes:

[0027] The first application instance queries whether there is an available session token corresponding to the second application instance in the current application instance;

[0028] If the available session token exists, the first application instance generates the data access request according to the available session token, and sends the data access request to the second application instance;

[0029] If the available session token does not exist, the first application instance generates the token acquisition request and sends the token acquisition request to the second application instance.

[0030] In one embodiment, the second application instance returns corresponding response data to the first application instance according to the verification result, further comprising:

[0031] If the verification result shows that the first application instance does not have sharing permission, the second application instance returns an error status code to the first application instance.

[0032] In one embodiment, the second application instance verifies whether the first application instance has sharing permission based on the first encrypted data and the second encrypted data, including:

[0033] If the first encrypted data is identical to the second encrypted data, the second application instance determines that the first application instance has sharing permission;

[0034] If the first encrypted data is different from the second encrypted data, the second application instance determines that the first application instance does not have sharing permission.

[0035] In a second aspect, an embodiment of the present application provides a storage medium storing computer-readable instructions. When the computer-readable instructions are executed by one or more processors, the one or more processors execute the steps of the data sharing permission verification method described in any of the above embodiments.

[0036] In a third aspect, an embodiment of the present application provides a smart card, the smart card comprising: one or more processors, and a memory;

[0037] The memory stores computer-readable instructions, and when the computer-readable instructions are executed by the one or more processors, the steps of the data sharing authority verification method described in any of the above embodiments are executed.

[0038] In the data sharing permission verification method, device, storage medium, and smart card provided in some embodiments of the present application, the first application instance is configured with a first key, and the second application instance is configured with a second key. When performing sharing permission verification, the first application instance may use the key corresponding to the first application instance to encrypt a random number to generate first encrypted data. The second application instance may use the key corresponding to the second application instance to encrypt the same random number to generate second encrypted data. The second application instance may verify whether the first application instance has sharing permission based on the first encrypted data and the second encrypted data.

[0039] In this way, when expanding business, you only need to configure the corresponding key for the new application instance to grant sharing permissions to the application instance, making it a shared application instance and able to access the data of the second application instance. This shows that this application can not only effectively limit and verify the data sharing permissions on the smart card to ensure the security of shared data, but also more flexibly expand the number of shared application instances, which is conducive to subsequent business expansion. BRIEF DESCRIPTION OF THE DRAWINGS

[0040] In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the following briefly introduces the drawings required for use in the embodiments or the description of the prior art. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative labor.

[0041] Figure 1 1 is a flow chart of a first key configuration step in one embodiment;

[0042] Figure 2 This is a flowchart of a data sharing authority verification method in one embodiment;

[0043] Figure 3 This is a second flow chart of a method for verifying data sharing authority in one embodiment;

[0044] Figure 4 This is a third flow chart of a method for verifying data sharing authority in one embodiment;

[0045] Figure 5 A flowchart of a shared data access step in one embodiment;

[0046] Figure 6 FIG. 1 is a diagram showing the internal structure of a smart card in one embodiment. DETAILED DESCRIPTION

[0047] The following will be combined with the drawings in the embodiments of this application to clearly and completely describe the technical solutions in the embodiments of this application. Obviously, the embodiments described are only part of the embodiments of this application, not all of the embodiments. Based on the embodiments in this application, all other embodiments obtained by ordinary technicians in this field without making creative efforts are within the scope of protection of this application.

[0048] In some embodiments, the present application provides a data sharing permission verification method, which is applied to a smart card installed with a first application instance and a second application instance, wherein the application instance can be obtained by instantiating the application into the smart card.

[0049] It is understood that the first application instance and the second application instance can be any two application instances, and this document does not impose any specific restrictions on this. It only requires that the first application instance and the second application instance are different application instances. Furthermore, for ease of distinction, the first application instance of this application can be an instance that needs to access the data of other application instances, that is, a client instance. The second application instance can be an instance accessed by other application instances, that is, a server instance. For example, application instance A needs to access the data of application instance B. In this case, application instance A is the first application instance, and application instance B is the second application instance.

[0050] The first application instance is configured with a first key, and the second application instance is configured with a second key. Both the first and second keys can be configured based on actual circumstances, and this document does not impose specific limitations. In one example, the first key can be configured during the personalization phase of the first application instance, and the second key can be configured during the personalization phase of the second application instance. By performing personalization operations on each application instance in the smart card, each application instance can be tailored to the user information and needs of the smart card user.

[0051] It is understood that the first key and the second key can be configured using similar configuration steps. Figure 1 As shown, taking the configuration step of the first key as an example, it may specifically include the following sub-steps:

[0052] S102: When personalization of the first application instance is triggered, determine whether the first application instance needs to share data with other application instances. If so, proceed to step S104; otherwise, proceed to step S106.

[0053] S104: Obtain a first key, and add the first key to the personalized data corresponding to the first application instance, so that the personalized data of the first application instance includes the first key;

[0054] S106: Perform a personalization operation on the first application instance according to the personalization data.

[0055] It is understood that in addition to the first key, the personalized data may include other data, which may be determined based on actual factors such as the application type and application function corresponding to the application instance, and this document does not impose specific limitations on this. Furthermore, the steps for configuring the second key can refer to the steps for configuring the first key and will not be repeated here.

[0056] The data sharing permission verification method provided by this application is described below.

[0057] In one embodiment, Figure 2 As shown, a data sharing permission verification method provided by this application may include the following steps:

[0058] S202: The first application instance sends a data sharing request to the second application instance.

[0059] The data sharing request is used to request data sharing with the second application instance, and may be, but is not limited to, a token acquisition request or a data access request.

[0060] In this step, when the first application instance needs to access the shared data of the second application instance, the first application instance may send a data sharing request to the second application instance to request data sharing with the second application instance.

[0061] Furthermore, in one example, before executing S202, the first application instance may send a shared interface object acquisition request to the second application instance. In response to the shared interface object acquisition request, the second application instance may return a shared interface object corresponding to the second application instance to the first application instance, so that the first application instance can perform data transmission with the second application instance based on the shared interface object.

[0062] S204: In response to the data sharing request, the second application instance determines whether sharing permission verification needs to be performed.

[0063] In this step, when the second application instance receives the data sharing request sent by the first application instance, it can determine whether sharing permission verification needs to be performed according to the preset permission verification judgment rules to verify whether the first application instance has the permission to access the shared data of the second application instance.

[0064] S206: When sharing permission verification is required, the second application instance returns a random number to the first application instance.

[0065] If shared permission verification is determined to be necessary, the second application instance can generate a random number and send it to the first application instance. It is understood that the length of the random number can be determined based on practical considerations such as the key block length and the efficiency requirements for shared permission verification, and this document does not impose specific limitations on this. In one example, the random number can be 8 bytes or 16 bytes long.

[0066] S208: The first application instance performs encryption calculation on the random number according to the first key to obtain first encrypted data.

[0067] In this step, upon receiving the random number, the first application instance may use the key corresponding to the application instance (i.e., the first key) to perform encryption calculations on the random number to obtain first encrypted data. It is understood that the first application instance may use any encryption algorithm for encryption calculations, including but not limited to the DES (Data Encryption Standard) algorithm or the AES (Advanced Encryption Standard) algorithm.

[0068] S210: The first application instance sends first encrypted data to the second application instance.

[0069] S212: The second application instance encrypts the random number according to the second key to obtain second encrypted data, and verifies whether the first application instance has sharing permission based on the first encrypted data and the second encrypted data.

[0070] In this step, the second application instance may use the key corresponding to the first application instance (i.e., the second key) to encrypt the same random number and obtain second encrypted data. It is understood that the second application instance may use any encryption algorithm for encryption, including but not limited to the DES algorithm or the AES algorithm. This document does not impose any specific restrictions on this. It is sufficient that the first and second application instances use the same encryption algorithm for encryption.

[0071] The second application instance can obtain the first encrypted data encrypted by the first application instance using the first key, and the second encrypted data encrypted by the second application instance using the second key. Because the plaintext data corresponding to the first encrypted data and the plaintext data corresponding to the second encrypted data are identical, the comparison result between the first and second encrypted data can be used to determine whether the first and second keys match, thereby verifying whether the first application instance has access to the shared data of the second application instance, that is, verifying whether the first application instance has sharing permissions, thereby completing data sharing permission verification.

[0072] For ease of description, some embodiments herein refer to the first application instance with sharing permissions as the authorized application instance. In one example, if the first application instance is the authorized application instance, the first key and the second key can be symmetric keys to improve the efficiency of permission verification and shared data access.

[0073] S214: The second application instance returns corresponding response data to the first application instance according to the verification result.

[0074] Through the data sharing permission verification method provided by this application, when expanding business, you only need to configure a key that matches the second key for the new application instance to grant sharing permissions to the application instance, so that the application instance has access to the shared data of the second application instance. This shows that this application can not only effectively limit and verify the data sharing permissions on the smart card to ensure the security of shared data, but also more flexibly expand the number of shared application instances, which is conducive to subsequent business expansion.

[0075] It should be noted that in step S214, the second application instance can use any method to verify whether the first application instance is an authorized application instance. This article does not impose any specific restrictions on this. It only requires that the second application instance completes the sharing permission verification based on the first encrypted data and the second encrypted data.

[0076] To improve the efficiency of sharing permission verification and thereby improve the efficiency of accessing shared data, in one embodiment, the second application instance verifies whether the first application instance has sharing permission based on the first encrypted data and the second encrypted data, including:

[0077] Step A1: If the first encrypted data and the second encrypted data are the same, the second application instance determines that the first application instance has sharing permission;

[0078] Step A3: If the first encrypted data and the second encrypted data are different, the second application instance determines that the first application instance does not have sharing permission.

[0079] In this embodiment, the second application instance can compare the first encrypted data with the second encrypted data to determine whether the two encrypted data are identical, thereby verifying whether the first application instance has sharing permissions. If the first encrypted data and the second encrypted data are identical, then the first key and the second key match, and the first application instance can be determined to be an authorized application instance. Conversely, if the first encrypted data and the second encrypted data are different, then the first key and the second key do not match, and the first application instance can be determined to be non-authorized, that is, the first application instance does not have access to the shared data of the second application instance.

[0080] In one embodiment, the second application instance returns corresponding response data to the first application instance based on the verification result, including:

[0081] If the verification result reflects that the first application instance has sharing permission, the second application instance generates and stores a session token;

[0082] The second application instance returns the session token to the first application instance, so that the first application instance accesses the data of the second application instance based on the session token.

[0083] In this embodiment, the second application instance can issue a session token to the first application instance with sharing permissions, allowing the authorized application instance to access shared data using the session token mechanism. This avoids requiring permission verification for the authorized application instance each time it accesses shared data, thereby improving data access efficiency.

[0084] Specifically, if the first application instance is an authorized application instance, the second application instance can generate and store a session token and return the session token to the first application instance. After receiving the session token, the first application instance can access the shared data of the second application instance based on the session token.

[0085] It is understandable that the specific method of generating the session token can be determined based on actual conditions, for example, it can be an 8-byte or 16-byte random number.

[0086] To further enhance the security of data shared by the second application instance, the session token may be validated to reduce the risk of data leakage and malicious exploitation caused by reasons such as session token leakage and session malicious exploitation. Specifically, in one embodiment, after generating and storing the session token, the second application instance may also record verification information corresponding to the session token, so that the validity of the session token can be verified based on this verification information in subsequent processes.

[0087] It is understood that this application may select corresponding data as the valid information of the session token based on actual conditions such as data security requirements and data integrity requirements. For example, the valid information of the session token may be the token generation time of the session token. If the current time is later than the sum of the token generation time and the preset usable time, the session token may be determined to be invalid; otherwise, the session token may be determined to be valid. For another example, the valid information of the session token may be a usage count threshold. If the current total usage count of the session token is less than or equal to the usage count threshold, the session token may be determined to be invalid; otherwise, the session token may be determined to be valid.

[0088] In the smart card field, smart cards typically have one or more payment application instances installed, and a single transaction involves multiple shared data accesses. To further enhance data security while maintaining high data access efficiency, the second application instance can use the transaction count value generated by the first application instance when generating a session token, and / or the transaction count value generated by the second application instance when generating a session token, as verification information for the session token.

[0089] For example, when generating session token A, the transaction count value corresponding to the first application instance is N1, and the transaction count value corresponding to the second application instance is N2, then the verification information corresponding to session token A may be N1 and / or N2.

[0090] In this way, a session token is valid only for a single transaction. This improves efficiency by requiring only a single shared permission verification for multiple shared data accesses within the same transaction. Furthermore, separate shared permission verification is required for each transaction, further enhancing data security.

[0091] In one embodiment, the data sharing request is a token acquisition request or a data access request. The token acquisition request is used to request a session token from the second application instance. The data access request is used to request shared data from the second application instance and may carry an available session token corresponding to the first application instance.

[0092] The second application instance determines whether sharing permission verification is required, including:

[0093] Step B1: If the data sharing request is a token acquisition request, the second application instance determines that sharing permission verification needs to be performed;

[0094] Step B3: If the data sharing request is a data access request, the second application instance performs validity verification on the available session token based on the verification information. If the validity verification passes, it is determined that sharing permission verification does not need to be performed; otherwise, it is determined that sharing permission verification needs to be performed.

[0095] In this embodiment, if the first application instance sends a token acquisition request to the second application instance, this indicates that the first application instance does not have an available session token and has not passed the shared permission verification. In this case, the second application instance can directly determine that it needs to perform shared permission verification on the first application instance to determine whether the first application instance is an authorized application instance.

[0096] If the first application instance sends a data access request to the second application instance, it indicates that the first application instance has a valid session token. In this case, the second application instance can verify the validity of the valid session token carried in the data access request based on the verification information and determine whether to re-perform sharing permission verification for the second application instance based on the verification result.

[0097] In one example, if the verification information corresponding to the session token is the transaction count value corresponding to the first application instance when generating the session token, and / or the transaction count value corresponding to the second application instance when generating the session token, then the second application instance can perform validity verification based on the transaction count value corresponding to the first application instance when sending the data access request, and / or the current transaction count value of the second application instance.

[0098] For example, if the verification information corresponding to the session token is the transaction count value N1 corresponding to the first application instance when generating the session token, and the data access request carries the transaction count value N1' corresponding to the first application instance when sending the data access request, then when N1'≠N1, it is determined that the validity check fails, and when N1'=N1, it is determined that the validity check passes.

[0099] In one embodiment, the data sharing request is a token acquisition request or a data access request. For the relevant description of the token acquisition request and the data access request, please refer to the above embodiments, which will not be repeated here.

[0100] In this embodiment, the first application instance sends a data sharing request to the second application instance, including:

[0101] Step C1: The first application instance queries whether there is an available session token corresponding to the second application instance in the current application instance;

[0102] Step C3: If there is an available session token, the first application instance generates a data access request according to the available session token, and sends the data access request to the second application instance;

[0103] Step C5: If there is no available session token, the first application instance generates a token acquisition request and sends the token acquisition request to the second application instance.

[0104] Specifically, before accessing the shared data of the second application instance, the first application instance may first query whether there is an available session token in the first application instance, wherein the available session token may be a session token allocated by the second application instance to the first application instance.

[0105] If the first application instance has an available session token, the first application instance can generate a data access request based on the available session token, so that the data access request carries the available session token. The first application instance can send the data access request to the second application instance to request access to the shared data of the second application instance.

[0106] If the first application instance does not have an available session token, the first application instance may generate a token acquisition request and send the token acquisition request to the second application instance to request the second application instance to allocate a session token to the first application instance.

[0107] In one embodiment, the second application instance returns corresponding response data to the first application instance based on the verification result, further comprising:

[0108] If the verification result shows that the first application instance does not have the sharing permission, the second application instance returns an error status code to the first application instance.

[0109] Furthermore, in the case that the first application instance does not have sharing permissions, the second application instance should deny the first application instance access to shared data to further improve data security.

[0110] To facilitate understanding of the solution of this application, three specific examples are provided below. Example 1 illustrates the process of the second application instance verifying the sharing permissions of the first application instance when there is no available session token for the first application instance. Example 2 illustrates the process of the second application instance verifying the sharing permissions of the first application instance when there is an available session token for the first application instance and the available session token is invalid. Example 3 illustrates the process of the first application instance accessing the shared data of the second application instance through a valid available session token.

[0111] Example 1:

[0112] like Figure 3 As shown, the data sharing permission verification method of this example may include the following steps:

[0113] S302: The first application instance sends a request to obtain a shared interface object to the second application instance;

[0114] S304: In response to the shared interface object acquisition request, the second application instance returns the shared interface object to the first application instance;

[0115] S306: The first application instance sends a token acquisition request to the second application instance through the shared interface object;

[0116] S308: In response to the token acquisition request, the second application instance generates a random number Random;

[0117] S310: The second application instance returns a random number Random to the first application instance;

[0118] S312: The first application instance uses the first key to perform encryption calculation on the random number Random to obtain first encrypted data RandomEnc;

[0119] S314: The first application instance sends the first encrypted data RandomEnc to the second application instance through the shared interface object;

[0120] S316: The second application instance uses the second key to perform encryption calculation on the random number Random to obtain second encrypted data RandomEnc1;

[0121] S318: If the first encrypted data RandomEnc is equal to the second encrypted data RandomEnc1, the second application instance generates a session token sessionToken, and uses the current transaction count value of the second application instance as verification information corresponding to the session token sessionToken;

[0122] S320: When the first encrypted data RandomEnc is successfully verified, the second application instance returns a session token sessionToken to the first application instance;

[0123] S322: If the first encrypted data RandomEnc fails to be verified, the second application instance returns an error status code to the first application instance and does not return the session token sessionToken. The first encrypted data RandomEnc fails to be verified when the first encrypted data RandomEnc is not equal to the second encrypted data RandomEnc1.

[0124] Example 2:

[0125] like Figure 4As shown, the data sharing permission verification method of this example may include the following steps:

[0126] S402: The first application instance sends a request to obtain a shared interface object to the second application instance;

[0127] S404: In response to the shared interface object acquisition request, the second application instance returns the shared interface object to the first application instance;

[0128] S406: The first application instance sends a data access request to the second application instance through the shared interface object, where the data access request carries an available session token determined by the first application instance;

[0129] S408: In response to the data access request, if the available session token carried in the data access request is the same as the session token stored by the second application instance, the second application instance compares the current transaction count value of the second application instance with the transaction count value corresponding to the available session token;

[0130] S410: If the current transaction count value of the second application instance is not equal to the transaction count value corresponding to the available session token, the second application instance generates a random number Random;

[0131] S412: The second application instance returns a random number Random to the first application instance;

[0132] S414: The first application instance uses the first key to perform encryption calculation on the random number Random to obtain first encrypted data RandomEnc;

[0133] S416: The first application instance sends the first encrypted data RandomEnc to the second application instance through the shared interface object;

[0134] S418: The second application instance uses the second key to perform encryption calculation on the random number Random to obtain second encrypted data RandomEnc1;

[0135] S420: If the first encrypted data RandomEnc is equal to the second encrypted data RandomEnc1, the second application instance generates a session token sessionToken, and uses the current transaction count value of the second application instance as verification information corresponding to the session token sessionToken;

[0136] S422: When the first encrypted data RandomEnc is successfully verified, the second application instance returns a session token sessionToken to the first application instance;

[0137] S424: If the first encrypted data RandomEnc fails to be verified, the second application instance returns an error status code to the first application instance and does not return the session token sessionToken. Wherein, the first encrypted data RandomEnc fails to be verified means that the first encrypted data RandomEnc is not equal to the second encrypted data RandomEnc1.

[0138] Example 3:

[0139] like Figure 5 As shown, the shared data access step of this example may include the following sub-steps:

[0140] S502: The first application instance sends a data access request to the second application instance through a shared interface object, where the data access request carries an available session token determined by the first application instance;

[0141] S504: In response to the data access request, if the available session token carried in the data access request is the same as the session token stored by the second application instance, the second application instance compares the current transaction count value of the second application instance with the transaction count value corresponding to the available session token;

[0142] S506: If the current transaction count value of the second application instance is equal to the transaction count value corresponding to the available session token, the second application instance returns a correct status code to the first application instance;

[0143] S508: If the current transaction count value of the second application instance is not equal to the transaction count value corresponding to the available session token, the second application instance returns an error status code to the first application instance and ends the shared data access request.

[0144] In one embodiment, the present application also provides a storage medium storing computer-readable instructions. When the computer-readable instructions are executed by one or more processors, the one or more processors execute the steps of the data sharing permission verification method in any embodiment.

[0145] In one embodiment, the present application also provides a smart card having computer-readable instructions stored therein. When the computer-readable instructions are executed by one or more processors, the one or more processors execute the steps of the data sharing authority verification method in any embodiment.

[0146] Schematically, Figure 6 This is a schematic diagram of the internal structure of a smart card provided in an embodiment of the present application. Figure 6Smart card 900 includes a processing component 902, which further includes one or more processors, and a memory resource represented by memory 901 for storing instructions executable by processing component 902, such as an application. The application stored in memory 901 may include one or more modules, each corresponding to a set of instructions. In addition, processing component 902 is configured to execute instructions to perform the steps of the data sharing permission verification method in any of the above embodiments.

[0147] Furthermore, the smart card 900 may further include an input / output interface 903 for data exchange with external devices. Meanwhile, the smart card 900 may also be configured with an operating system stored in the memory 901, such as a COS (Chip Operating System) or similar.

[0148] Those skilled in the art will understand that the internal structure of the smart card shown in the present application is merely a block diagram of a partial structure related to the solution of the present application, and does not constitute a limitation on the smart card to which the solution of the present application is applied. A specific smart card may include more or fewer components than shown in the figure, or combine certain components, or have a different component arrangement.

[0149] Finally, it should be noted that, in this article, relational terms such as first and second are merely used to distinguish one entity or operation from another, and do not necessarily require or imply any actual relationship or order between these entities or operations. Moreover, the terms "comprise," "include," or any other variations thereof are intended to encompass non-exclusive inclusion, such that a process, method, article, or device comprising a series of elements includes not only those elements, but also other elements not explicitly listed, or elements inherent to such process, method, article, or device. Without further restriction, an element defined by the phrase "comprising a..." does not exclude the presence of other identical elements in the process, method, article, or device comprising the element. Herein, "one," "said," "the," and "its" may also include plural forms unless the context clearly indicates otherwise. A plurality refers to at least two, such as 2, 3, 5, or 8. "And / or" includes any and all combinations of the relevant listed items.

[0150] The various embodiments in this specification are described in a progressive manner, and each embodiment focuses on the differences from other embodiments. The various embodiments can be combined as needed, and the same or similar parts can be referenced to each other.

[0151] The above description of the disclosed embodiments is intended to enable one skilled in the art to implement or use the present application. Various modifications to these embodiments will be readily apparent to one skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of the present application. Therefore, the present application is not limited to the embodiments shown herein, but is intended to conform to the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. A data sharing authority verification method, characterized in that: The method is applied to a smart card installed with a first application instance and a second application instance, wherein the first application instance is configured with a first key and the second application instance is configured with a second key; the method comprises: The first application instance sends a data sharing request to the second application instance; In response to the data sharing request, the second application instance determines whether sharing permission verification needs to be performed; In the case where sharing permission verification needs to be performed, the second application instance returns a random number to the first application instance; The first application instance performs encryption calculation on the random number according to the first key to obtain first encrypted data; The first application instance sends the first encrypted data to the second application instance; The second application instance encrypts and calculates the random number according to the second key to obtain second encrypted data, and verifies whether the first application instance has sharing permission based on the first encrypted data and the second encrypted data; The second application instance returns corresponding response data to the first application instance according to the verification result; The second application instance returns corresponding response data to the first application instance according to the verification result, including: If the verification result reflects that the first application instance has sharing permission, the second application instance generates and stores a session token; The second application instance returns the session token to the first application instance, so that the first application instance accesses data of the second application instance based on the session token.

2. The method according to claim 1, characterized in that After the second application instance generates and stores the session token, the second application instance further includes: The second application instance records verification information corresponding to the session token; the verification information is used to verify the validity of the session token.

3. The method according to claim 2, characterized in that The verification information is a transaction count value corresponding to when the first application instance generates the session token, and / or a transaction count value corresponding to when the second application instance generates the session token.

4. The method according to claim 2, characterized in that The data sharing request is a token acquisition request or a data access request, and the data access request carries an available session token corresponding to the first application instance; The second application instance determines whether sharing permission verification needs to be performed, including: If the data sharing request is the token acquisition request, the second application instance determines that sharing permission verification needs to be performed; If the data sharing request is a data access request, the second application instance performs validity verification on the available session token according to the verification information. If the validity verification passes, it is determined that sharing permission verification does not need to be performed; otherwise, it is determined that sharing permission verification needs to be performed.

5. The method according to claim 1, wherein The data sharing request is a token acquisition request or a data access request; The first application instance sending a data sharing request to the second application instance includes: The first application instance queries whether there is an available session token corresponding to the second application instance in the current application instance; If the available session token exists, the first application instance generates the data access request according to the available session token, and sends the data access request to the second application instance; If the available session token does not exist, the first application instance generates the token acquisition request and sends the token acquisition request to the second application instance.

6. The method according to any one of claims 1 to 5, characterized in that The second application instance returns corresponding response data to the first application instance according to the verification result, further comprising: If the verification result shows that the first application instance does not have sharing permission, the second application instance returns an error status code to the first application instance.

7. The method according to any one of claims 1 to 5, characterized in that The second application instance verifies, based on the first encrypted data and the second encrypted data, whether the first application instance has the sharing permission, including: If the first encrypted data is identical to the second encrypted data, the second application instance determines that the first application instance has sharing permission; If the first encrypted data is different from the second encrypted data, the second application instance determines that the first application instance does not have sharing permission.

8. A storage medium, characterized in that: The storage medium stores computer-readable instructions, which, when executed by one or more processors, cause the one or more processors to execute the steps of the data sharing authority verification method according to any one of claims 1 to 7.

9. A smart card, characterized in that: include: one or more processors, and memory; The memory stores computer-readable instructions, which, when executed by the one or more processors, execute the steps of the data sharing authority verification method according to any one of claims 1 to 7.

Images