Data sharing permission verification method and device, storage medium and smart card

Abstract

The invention provides a data sharing permission verification method and device, a storage medium and a smart card, which can be applied to the smart card installed with a first application instance and a second application instance. Wherein the first application instance is configured with a first secret key, and the second application instance is configured with a second secret key. When sharing permission verification is carried out, the first application instance can adopt the first secret key to carry out encryption calculation on the random number so as to generate first encryption data. The second application instance can adopt a second key to carry out encryption calculation on the same random number so as to generate second encrypted data. The second application instance may verify whether the first application instance has a sharing permission based on the first encrypted data and the second encrypted data. Thus, when service expansion is carried out, only the corresponding secret key needs to be configured for the new application instance, the application instance can be granted with the sharing permission, the application instance becomes the sharing application instance and can access the data of the second application instance, and therefore the sharing application instance can be expanded more flexibly.

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 carry more and more application instances to support one card for multiple uses. For example, smart cards can carry public transportation payment application instances corresponding to different cities and / or bank payment application instances corresponding to different banks.

[0003] Considering the need for data sharing between different application instances of smart cards, the prior art proposes a solution for data sharing through a shared interface object. In the process of data sharing between the first application instance and the 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 the shared interface object, which 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 authority restrictions for this, so it has certain security risks.

[0004] To solve the above problems, the prior art also provides a data sharing solution based on an AID (Application Identifier) ​​list for permission verification. In specific implementation, an AID list supporting data sharing can be set in advance in the second application instance. During the data sharing process between the first application instance and the 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 it is in the AID list, the second application instance allows the first application instance to access the data of the second application instance to achieve data sharing. Otherwise, the second application instance denies the first application instance access to the data.

[0005] Although the above implementation can perform permission control, once the AID list is determined, the shared application instance that can share data with the second application instance is 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 the problem of 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 defects, especially the technical defects of 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 comprises:

[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 authority 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 authority, 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 the 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 of the embodiments, the verification information is a transaction count value corresponding to the first application instance when generating the session token, and / or a transaction count value corresponding to the second application instance when generating the session token.

[0021] In one of the embodiments, 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 it is necessary to perform sharing permission verification, 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 a validity check on the available session token according to the verification information. If the validity check 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 of the embodiments, 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 present 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 reflects that the first application instance does not have sharing permissions, 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 the same as the second encrypted data, the second application instance determines that the first application instance has sharing authority;

[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, which stores 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 and calculate the random number to generate the first encrypted data. The second application instance may use the key corresponding to the second application instance to encrypt and calculate the same random number to generate the 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 the application instance sharing permissions, making the application instance a shared application instance and able to access the data of the second application instance. It can be seen that this application can effectively limit and verify the data sharing permissions on the smart card to ensure the security of shared data, and can more flexibly expand the number of shared application instances, which is helpful for 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 drawings required for use in the embodiments or the description of the prior art will be briefly introduced below. 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 creative labor.

[0041] Figure 1 A schematic diagram of a flow chart of a first key configuration step in an embodiment;

[0042] Figure 2 One of the flowcharts 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 an embodiment;

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

[0045] Figure 5 A schematic diagram of a process of sharing data access steps in one embodiment;

[0046] Figure 6 FIG. 4 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 the present application to clearly and completely describe the technical solutions in the embodiments of the present application. Obviously, the described embodiments are only part of the embodiments of the present application, not all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by ordinary technicians in this field without creative work 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. The application instance can be obtained by instantiating the application program into the smart card.

[0049] It can be understood that the first application instance and the second application instance can be any two application instances, and this document does not make specific restrictions on this. It only needs that the first application instance and the second application instance are not the same application instance. Further, for the convenience of distinction, the first application instance of the present 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 key and the second key can be configured according to actual conditions, and this document does not impose specific restrictions on this. In one example, the first key can be configured in the personalization stage of the first application instance, and the second key can be configured in the personalization stage of the second application instance. By performing personalization operations on each application instance in the smart card, each application instance can be consistent with the user information and user needs of the user using the smart card.

[0051] It can be 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 the first application instance is triggered to be personalized, determine whether the first application instance needs to share data with other application instances, if yes, proceed to step S104, otherwise, proceed to step S106;

[0053] S104: Acquire a first key, and add the first key to 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 restrictions on this. In addition, the configuration steps of the second key can refer to the configuration steps of the first key, and this document will not repeat them 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 authority 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] Further, 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 it is necessary to perform sharing permission verification based on 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 it is necessary to perform sharing permission verification, the second application instance returns a random number to the first application instance.

[0065] When it is determined that the shared permission verification needs to be performed, the second application instance can generate a random number and send the random number to the first application instance. It can be understood that the length of the random number can be determined according to the actual situation such as the group length of the key and the verification efficiency requirement of the shared permission, and this document does not make specific restrictions on this. In one example, the length of the random number can be 8 bytes or 16 bytes.

[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, when the first application instance receives the random number, it can use the key corresponding to the application instance (i.e., the first key) to perform encryption calculation on the random number to obtain the first encrypted data. It can be understood that the first application instance can use any encryption algorithm for encryption calculation, which can be 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 and calculates the random number according to the second key to obtain second encrypted data, and verifies whether the first application instance has sharing authority based on the first encrypted data and the second encrypted data.

[0070] In this step, the second application instance can use the key corresponding to the application instance (i.e., the second key) to perform encryption calculation on the same random number and obtain the second encrypted data. It can be understood that the second application instance can use any encryption algorithm for encryption calculation, which can be but not limited to the DES algorithm or the AES algorithm. This article does not make specific restrictions on this. It only needs that the first application instance and the second application instance use the same encryption algorithm for encryption calculation.

[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. Since the plaintext data corresponding to the first encrypted data and the plaintext data corresponding to the second encrypted data are the same, it is possible to determine whether the first key matches the second key based on the comparison result of the first encrypted data and the second encrypted data, and then verify whether the first application instance has the access right to the shared data of the second application instance, that is, verify whether the first application instance has the sharing right, thereby completing the data sharing right verification.

[0072] For ease of description, some embodiments herein refer to the first application instance with sharing permissions as an authorized application instance. In one example, if the first application instance is an authorized application instance, the first key and the second key may 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 the application instance sharing permission, so that the application instance has access rights to the shared data of the second application instance. It can be seen that this application can effectively limit and verify the data sharing permission on the smart card to ensure the security of shared data, and can more flexibly expand the number of shared application instances, which is helpful for 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 document does not make 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 thus 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 is the same as the second encrypted data, the second application instance determines that the first application instance has sharing authority;

[0078] Step A3: 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 authority.

[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 the same, and then verify whether the first application instance has sharing permissions. If the first encrypted data is the same as the second encrypted data, it indicates that the first key matches the second key, so the first application instance can be an authorized application instance. On the contrary, if the first encrypted data is not the same as the second encrypted data, the first key does not match the second key, so it can be determined that the first application instance is not an authorized application instance, 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 according to 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, so that the authorized application instance can use the session token mechanism to access shared data. In this way, it is possible to avoid the need to verify the permissions of the authorized application instance every time shared data is accessed, 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 according to 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] In order to further improve the data security of the shared data of the second application instance, the session token may be verified for validity, so as to reduce the risk of data leakage and malicious use of data caused by reasons such as session token leakage and malicious use of the session. Specifically, in one embodiment, after the second application instance generates and stores the session token, it may also record the verification information corresponding to the session token, so as to verify the validity of the session token based on the verification information in the subsequent process.

[0087] It can be understood that the present application can select corresponding data as the effective information of the session token according to the actual conditions such as data security requirements and data integrity requirements. For example, the effective information of the session token can 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 available time, the session token can be determined to be invalid. Otherwise, the session token can be determined to be valid. For another example, the effective information of the session token can be the 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 can be determined to be invalid. Otherwise, the session token can be determined to be valid.

[0088] In the smart card field, smart cards are usually installed with one or more payment application instances, and a transaction requires multiple shared data accesses. To further improve data security and take into account high data access efficiency, the second application instance can use the transaction count value corresponding to the first application instance when generating a session token and / or the transaction count value corresponding to the second application instance when generating a session token as verification information corresponding to 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 only valid in one transaction. On the one hand, in the same transaction, only one shared permission verification is required to achieve multiple shared data accesses, thereby improving execution efficiency. On the other hand, shared permission verification is required for each transaction in different transactions, thereby further improving 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 of the second application instance, and the data access request may carry an available session token corresponding to the first application instance.

[0092] The second application instance determines whether sharing permission verification needs to be performed, 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 a validity check on the available session token according to the verification information. If the validity check 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, it indicates that there is no available session token in the first application instance and the first application instance has not passed the sharing permission verification. In this case, the second application instance can directly determine that it is necessary to perform sharing 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 there is an available session token in the first application instance. In this case, the second application instance can perform a validity check on the available session token carried in the data access request based on the verification information, and determine whether it is necessary to re-perform the sharing permission verification on the second application instance based on the verification result of the validity check.

[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 embodiment, 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 present 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 according to 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 there is no available session token for the first application instance, 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 according to the verification result, further comprising:

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

[0109] Furthermore, in the case where 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 the present application, three specific examples are provided below for illustration. Example 1 shows 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 shows 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 shows 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: When 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 in 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: When the verification of the first encrypted data RandomEnc fails, the second application instance returns an error status code to the first application instance, and does not return the session token sessionToken. The verification failure of the first encrypted data RandomEnc refers to the situation 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 steps of accessing shared data in 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 in 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 this 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] Indicatively, Figure 6 This is a schematic diagram of the internal structure of a smart card provided in an embodiment of the present application. Figure 6, the smart card 900 includes a processing component 902, which further includes one or more processors, and a memory resource represented by a memory 901, for storing instructions that can be executed by the processing component 902, such as an application. The application stored in the memory 901 may include one or more modules, each corresponding to a set of instructions. In addition, the processing component 902 is configured to execute instructions to perform the steps of the data sharing authority verification method in any of the above embodiments.

[0147] Furthermore, the smart card 900 may also 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 based on the storage in the memory 901, such as COS (Chip Operating System) or the like.

[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 scheme of the present application, and does not constitute a limitation on the smart card to which the scheme of the present application is applied. A specific smart card may include more or fewer components than those shown in the figure, or combine certain components, or have a different arrangement of components.

[0149] Finally, it should be noted that, in this article, relational terms such as first and second, etc. are only used to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply that there is any such actual relationship or order between these entities or operations. Moreover, the term "include", "comprise" or any other variant thereof is intended to cover non-exclusive inclusion, so that the process, method, article or equipment including a series of elements not only includes those elements, but also includes other elements not clearly listed, or also includes elements inherent to such process, method, article or equipment. In the absence of more restrictions, the elements defined by the sentence "including one..." do not exclude the existence of other identical elements in the process, method, article or equipment including the elements. Herein, "one", "one", "said", "the" and "it" may also include plural forms, unless the context clearly indicates another way. A plurality refers to at least two cases, such as 2, 3, 5 or 8, etc. "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 refer to each other.

[0151] The above description of the disclosed embodiments enables those skilled in the art to implement or use the present application. Various modifications to these embodiments will be apparent to those 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 will not be limited to the embodiments shown herein, but will conform to the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. A data sharing authority verification method, It is 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 authority 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.

2. The method according to claim 1, It is characterized in that 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 authority, 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 the data of the second application instance based on the session token.

3. The method according to claim 2, It is 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.

4. The method according to claim 3, It is 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.

5. The method according to claim 3, It is 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 it is necessary to perform sharing permission verification, 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 a validity check on the available session token according to the verification information. If the validity check 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.

6. The method according to claim 2, It is characterized in that 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 present 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.

7. The method according to any one of claims 2 to 6, It is 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 reflects that the first application instance does not have sharing permissions, the second application instance returns an error status code to the first application instance.

8. The method according to any one of claims 1 to 6, It is 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 the same as the second encrypted data, the second application instance determines that the first application instance has sharing authority; 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.

9. A storage medium, It is characterized in that The storage medium stores computer-readable instructions, and 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 as described in any one of claims 1 to 8.

10. A smart card, It is characterized in that include: one or more processors, and memory; 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 as described in any one of claims 1 to 8 are performed.

Images