Card application access method, card application access device and electronic equipment

By obtaining the shared interface object and access control rules with the target card application, determining its security level and returning a response message, the problem of external applications bypassing the GP access control mechanism to access the card application is solved, and the security of the card application is improved.

CN119357943AInactive Publication Date: 2025-01-24CHINA MOBILE INTERNET CO LTD +2
View PDF 5 Cites 0 Cited by

Patent Information

Application Number
CN202411504117.3
Authority / Receiving Office
CN · China
Patent Type
Applications(China)
Current Assignee / Owner
Filing Date
2024-10-25
Publication Date
2025-01-24
Estimated Expiration
Not applicable · inactive patent

AI Technical Summary

Technical Problem

In the prior art, external applications or devices can directly access card applications bypass the GP access control mechanism, resulting in reduced security of card applications.

Method used

By receiving the terminal's request, obtain the shared interface object corresponding to the target card application, obtain the access control rules based on the shared interface object, determine the security level of the target card application, and finally return a response message, including the target execution result or authentication instruction, to Prevents the terminal from interacting directly with the target card application.

Benefits of technology

Effectively prevent the direct interaction between the terminal and the target card application, enhance the security of the target card application, and avoid the invasion of the access control program to the card application business program.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN119357943A_ABST
    Figure CN119357943A_ABST
Patent Text Reader

Abstract

The invention discloses a card application access method, a card application access device and electronic equipment, and the method comprises the steps: receiving a first request sent by a terminal, the first request being used for requesting a target card application to execute a target operation; when it is determined that the shared interface object corresponding to the target card application is not obtained, obtaining the shared interface object through a shared interface, and obtaining an access control rule corresponding to the target card application through the shared interface object; acquiring a security level of the target card application based on the access control rule; based on the security level of the target card application, a first response message is returned to the first request, the first response message comprises a target execution result or an authentication instruction, and the target execution result is obtained by executing the target operation based on the shared interface object. The authentication instruction is used for instructing the terminal to perform authentication.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] The present application belongs to the field of computer technology, and in particular, relates to a card application access method, a card application access device and an electronic device. Background Art

[0002] At present, smart card applications implement access control based on the ARF architecture under the GP specification. However, this method has security vulnerabilities, that is, it cannot prevent devices such as card readers from bypassing the GP access control mechanism and directly accessing the card application, thereby reducing the security of the card application. Summary of the invention

[0003] The embodiments of the present application provide a card application access method, a card application access device and an electronic device, which solve the problem that an external application or device bypasses the GP access control mechanism to access the card application, resulting in reduced security of the card application.

[0004] In a first aspect, an embodiment of the present application provides a card application access method, the method comprising: receiving a first request sent by a terminal, wherein the first request is used to request a target card application to perform a target operation; in a case where it is determined that a shared interface object corresponding to the target card application has not been obtained, obtaining the shared interface object through a shared interface, and obtaining an access control rule corresponding to the target card application through the shared interface object; based on the access control rule, obtaining a security level of the target card application; based on the security level of the target card application, returning a first response message to the first request, wherein the first response message includes a target execution result or an authentication indication, the target execution result being obtained by executing the target operation based on the shared interface object, and the authentication indication being used to instruct the terminal to perform authentication.

[0005] In a second aspect, an embodiment of the present application provides a card application access method, the method comprising: sending a first request to a smart card, wherein the first request is used to request a target card application to perform a target operation; receiving a first response message returned by the smart card; wherein the first response message includes a target execution result or an authentication indication, the target execution result is obtained by executing the target operation based on a shared interface object, the authentication indication is used to instruct the terminal to perform authentication, the first response message is determined based on an access control rule of the target card application, the access control rule is obtained through a shared interface object corresponding to the target card application, and the shared interface object is obtained by the smart card through a shared interface.

[0006] In a third aspect, an embodiment of the present application provides a card application access device, which includes: a receiving module, used to receive a first request sent by a terminal, wherein the first request is used to request a target card application to perform a target operation; a first acquisition module, used to obtain the shared interface object through a shared interface when it is determined that the shared interface object corresponding to the target card application has not been obtained, and to obtain the access control rules corresponding to the target card application through the shared interface object; a second acquisition module, used to obtain the security level of the target card application based on the access control rules; a processing module, used to return a first response message to the first request based on the security level of the target card application, wherein the first response message includes a target execution result or an authentication indication, the target execution result is obtained by executing the target operation based on the shared interface object, and the authentication indication is used to instruct the terminal to perform authentication. In a fourth aspect, an embodiment of the present application provides a card application access device, the device comprising: A sending module, used for sending a first request to a smart card, wherein the first request is used to request a target card application to perform a target operation; a receiving module, used to receive a first response message returned by the smart card; wherein the first response message includes a target execution result or an authentication indication, the target execution result is obtained by executing the target operation based on a shared interface object, the authentication indication is used to instruct the terminal to perform authentication, the first response message is determined based on an access control rule of the target card application, the access control rule is obtained through a shared interface object corresponding to the target card application, and the shared interface object is obtained by the smart card through a shared interface.

[0007] In a fifth aspect, an embodiment of the present application provides an electronic device, which includes a processor, a memory, and a program or instruction stored in the memory and executable on the processor, wherein the program or instruction, when executed by the processor, implements the steps of the method described in the first aspect or the second aspect.

[0008] In a sixth aspect, an embodiment of the present application provides a computer-readable storage medium, on which a program or instruction is stored. When the program or instruction is executed by a processor, the steps of the method described in the first aspect or the second aspect are implemented.

[0009] In the seventh aspect, an embodiment of the present application provides a chip, which includes a processor and a communication interface, wherein the communication interface is coupled to the processor, and the processor is used to run a program or instruction to implement the method described in the first aspect or the second aspect.

[0010] In an eighth aspect, a computer program product is provided, wherein the computer program product comprises at least one computer program, and when the computer program is loaded and executed by a processor, the method as described in the first aspect or the second aspect is implemented.

[0011] In an embodiment of the present application, a first request sent by a terminal is received, wherein the first request is used to request a target card application to perform a target operation; when it is determined that a shared interface object corresponding to the target card application has not been obtained, the shared interface object is obtained through the shared interface, and the access control rule corresponding to the target card application is obtained through the shared interface; based on the access control rule, the security level of the target card application is obtained; based on the security level of the target card application, a first response message is returned to the first request, wherein the first response message includes a target execution result or an authentication indication, the target execution result is obtained by executing the target operation based on the shared interface object, and the authentication indication is used to instruct the terminal to perform authentication, so that direct interaction between the terminal and the target card application can be effectively prevented, and the shared interface object corresponding to the target card application is obtained, and then the access control rule corresponding to the target card application is obtained, and then access control is performed on the terminal based on the access control rule, thereby solving the problem in the related art that an external application or device bypasses the GP access control mechanism to access the card application, resulting in reduced security of the card application, thereby enhancing the security of the target card application, and further, effectively preventing the access control program from intruding into the card application business program. BRIEF DESCRIPTION OF THE DRAWINGS

[0012] Figure 1 A schematic diagram of implementing card application access control in the related art is shown; Figure 2 A flowchart of a card application access method provided by an exemplary embodiment of the present application; Figure 3 A schematic diagram showing the format of an APDU instruction provided by an exemplary embodiment of the present application is shown; Figure 4 A schematic diagram of the structure of a smart card provided by an exemplary embodiment of the present application is shown; Figure 5 A schematic diagram of the structure of another smart card provided by an exemplary embodiment of the present application is shown; Figure 6 A schematic diagram of implementing card application access control in the related art is shown; Figure 7 A schematic diagram of a card application activation process provided by an exemplary embodiment of the present application is shown; Figure 8 Another flowchart of a card application access method provided by an exemplary embodiment of the present application is shown; Fig. 9An interactive schematic diagram of a card application access provided by an exemplary embodiment of the present application is shown; Fig.10 A schematic diagram of the structure of a card application access device provided by an exemplary embodiment of the present application is shown; Fig.11 A schematic diagram of the structure of a card application access device provided by an exemplary embodiment of the present application is shown; Fig.12 A schematic structural diagram of an electronic device provided by an exemplary embodiment of the present application is shown. DETAILED DESCRIPTION

[0013] 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 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.

[0014] In related technologies, according to the GP (Global Platform) specification, smart card applications are usually based on the ARF architecture to implement access control, such as Figure 1 As shown in the figure, the access controller of the terminal system (Android, Windows Phone, etc.) obtains AC (Access Control) rules by reading the Advanced Recording File (ARF). When the terminal application accesses the card application through the API, it sends the Application Protocol Data Unit (APDU) instruction to the access controller, which detects whether the application has access rights. If so, it forwards it to the card application for processing. This access control method based on ARF files is only applicable to terminal applications and cannot prevent direct access to card applications through card readers and other methods.

[0015] Based on this, the embodiments of the present application provide a card application access method, a card application access device and an electronic device to solve the problem in the related art that an external application or device bypasses the GP access control mechanism to access the card application, resulting in reduced security of the card application.

[0016] In conjunction with the accompanying drawings, a card application access method provided by an embodiment of the present application is described in detail through specific embodiments and application scenarios.

[0017] Figure 2A card application access method provided by an embodiment of the present application is shown, and the method can be executed by a smart card, and the smart card can include: NFC-UIM card, smart card, financial IC card, etc. In other words, the method can be executed by software or hardware installed on the smart card, and the method includes the following steps: S210: Receive a first request sent by a terminal.

[0018] The first request is used to request the target card application to perform a target operation, which may include but is not limited to data reading, data writing, password verification, mobile payment, business transaction, etc.

[0019] Card Application refers to an application running on a smart card to perform specific functions or provide specific services. The smart card includes but is not limited to: SIM card, UICC card, eSIM card, USIM card, vSIM card, IoT card, financial card, transportation card, etc. Card application is usually stored in the security chip of the smart card and communicates with the terminal through APDU instructions. The terminal may include card reader, mobile terminal, smart card receiving device (Card Acceptance Device, CAD) and other devices or software that can directly interact with the user.

[0020] Optionally, the first request may be an APDU instruction. Figure 3 As shown, it is a schematic diagram of the format of the APDU instruction, wherein the target card application AID in LV format, i.e., the application identifier of the target card application, needs to be carried at the beginning of the data field, L represents the AID length, and V represents the AID value.

[0021] S220: If it is determined that the shared interface object corresponding to the target card application has not been obtained, obtain the shared interface object through the shared interface, and obtain the access control rule corresponding to the target card application through the shared interface object.

[0022] It is understandable that, in a smart card, in order to prevent a terminal from directly accessing a target card application, access control to the terminal can be implemented by obtaining a shared interface object corresponding to the target card application, so that the target card application is only responsible for processing calls or requests corresponding to the shared interface object. The shared interface object may be a SIO object.

[0023] Among them, in another implementation method, the determination that the shared interface object corresponding to the target card application has not been obtained includes: when the application identifier of the target card application is inconsistent with the preset card application identifier, determining that the shared interface object has not been obtained, wherein the preset card application identifier is the application identifier of the preset card application requested to be accessed by the second request, and the second request is the previous request received by the smart card that is adjacent to the first request.

[0024] It is understandable that after receiving the request, the smart card will parse out the corresponding card application identifier and save it in the instance variable targetAID. After receiving a new request, after parsing out the new card application identifier, the targetAID value will be set to the new card application identifier, that is, the value corresponding to the targetAID will be overwritten by the new card application identifier when updated. Therefore, in the embodiment of the present application, the value of targetAID is the preset card application identifier. If the application identifier of the target card application is inconsistent with the preset card application identifier, it means that the value of the instance variable targetAID in the current smart card is not the application identifier of the target card application, that is, the currently acquired shared interface object corresponds to the preset card application identifier, so it is necessary to re-acquire the shared interface object corresponding to the target card application through the shared interface. In addition, if the first request does not carry the application identifier (AID) of the target card application, the preset card application identifier stored in the instance variable targetAID is used as the AID of the target card application.

[0025] In an embodiment of the present application, the smart card may include an agent module and a service module, wherein the agent module is used to act as an agent for the service module to process the terminal request, the service module may include at least one card application, the at least one card application includes a target card application, and the agent module interacts with the service module through a shared interface. For example, Figure 4 As shown in FIG. 1 , a schematic diagram of the structure of a smart card provided in an embodiment of the present application is shown in FIG. Figure 5 As shown, it is an interactive schematic diagram of a smart card provided by an embodiment of the present application. It can be understood that, when it is determined that the shared interface object of the target card application has not been obtained, the proxy module obtains the shared interface object corresponding to the target card application through the shared interface, and then saves it in the instance variable sio, and then obtains the access control rules corresponding to the target card application through the shared interface object, that is, the access control rules of the target card application are obtained by calling the acquisition method of the shared interface object, and the access control rules are saved in the instance variable ac. In this way, the proxy module obtains the shared interface object and access control rules corresponding to the target card application. Among them, the acquisition method returns a byte array in TLV format.

[0026] In addition, in the embodiment of the present application, the access control to the terminal is implemented by the proxy module, so that there is no need to add an access control program in each card application, avoiding the intrusion into the business program corresponding to the card application, thereby avoiding the introduction of unnecessary complexity and potential errors. Figure 6 As shown, if the access control program is inserted into the business program of the card application, it will be intrusive to the original business program of the card application. At the same time, the proxy module can be responsible for the access control corresponding to multiple card applications at the same time, that is, the proxy module can realize two modes: single card application proxy and multi-card application proxy.

[0027] Optionally, the access control rule may be an AC rule, and the access control rule is used to perform access authority authentication for card-level applications on the terminal.

[0028] Optionally, the shared interface may be a Java card runtime environment (Java card runtime environment, JCRE).

[0029] Optionally, the acquisition method may be defined as getACR().

[0030] S230: Based on the access control rule, obtain the security level of the target card application.

[0031] It can be understood that the access control rules are used to authenticate the access rights of the terminal to the card-level application. That is, when an external application or device needs to access resources on the card application, the proxy module obtains the access control rules through the shared interface object and decides whether to allow access based on these rules. It should be noted that the access does not mean that the terminal directly interacts with the target card application, but that the target card application processes the request of the terminal through the proxy module.

[0032] S240: Return a first response message to the first request based on the security level of the target card application.

[0033] The first response message includes a target execution result or an authentication indication, wherein the target execution result is obtained by executing the target operation based on the shared interface object, and the authentication indication is used to instruct the terminal to perform authentication.

[0034] It is understandable that when the target card application is initialized, the security level is determined, that is, the security level is fixed. For example, as shown in Table 1, there are different security levels and their corresponding requirements.

[0035] Table 1

[0036] It can be understood that b1-b8 represents an 8-bit binary number, binary "00000000" represents decimal "00", binary "00000001" represents decimal "01", binary "00000011" represents decimal "03", and binary "00000111" represents decimal "07", among which the security level "00" means that device authentication is not required; "01" means that device authentication is required; "03" means that device authentication and message authentication code are required; "07" means that both device authentication and message authentication code authentication are required, and the data domain must be encrypted.

[0037] In one implementation, returning a first response message to the first request based on the target card application security level includes: when the security level of the target card application is a target level, determining that the first response message includes the target execution result.

[0038] Taking the above Table 1 as an example, the target level is "00", then, when the security level of the target card application is the target level, it means that the terminal does not need to be verified, therefore, based on the shared interface object, the target operation is executed to obtain the target execution result. Wherein, based on the shared interface object, executing the target operation may include: executing the target operation by calling the business method of the shared interface object.

[0039] In another implementation, returning a first response message to the first request based on the target card application security level includes: when the target card application security level is not the target level, determining that the first response message includes the authentication indication.

[0040] Taking the above Table 1 as an example, if the target level is not "00", it means that the terminal needs to be authenticated, so the first response message returned to the terminal includes an authentication indication.

[0041] In an embodiment of the present application, a first request sent by a terminal is received, wherein the first request is used to request a target card application to perform a target operation; when it is determined that a shared interface object corresponding to the target card application has not been obtained, the shared interface object is obtained through the shared interface, and the access control rule corresponding to the target card application is obtained through the shared interface; based on the access control rule, the security level of the target card application is obtained; based on the security level of the target card application, a first response message is returned to the first request, wherein the first response message includes a target execution result or an authentication indication, the target execution result is obtained by executing the target operation based on the shared interface object, and the authentication indication is used to instruct the terminal to perform authentication, so that direct interaction between the terminal and the target card application can be effectively prevented, and the shared interface object corresponding to the target card application is obtained, and then the access control rule corresponding to the target card application is obtained, and then access control is performed on the terminal based on the access control rule, thereby solving the problem in the related art that an external application or device bypasses the GP access control mechanism to access the card application, resulting in reduced security of the card application, thereby enhancing the security of the target card application, and further, effectively preventing the access control program from intruding into the card application business program.

[0042] In the embodiment of the present application, the target card application in the business module specifies the proxy mode after initialization setting, and the proxy mode is used to verify the proxy module to prevent the proxy module from being invaded by malicious programs. The embodiment of the present application provides the following two verification methods: (1) In one implementation, obtaining the shared interface object through the shared interface includes: obtaining an initial proxy identifier corresponding to the target card application, wherein the initial proxy identifier is determined by initializing the target card application; and in response to a determination that the initial proxy identifier is consistent with a current proxy identifier, obtaining the shared interface object through the shared interface, wherein the current proxy identifier is a proxy identifier corresponding to the first request.

[0043] (2) In one implementation, obtaining the shared interface object through the shared interface includes: obtaining an initial proxy token corresponding to the target card application, wherein the initial proxy token is determined by initializing the target card application; in response to a determination that the initial proxy token is consistent with a current proxy token, obtaining the shared interface object through the shared interface, wherein the current proxy token is a proxy token corresponding to the first request.

[0044] It can be understood that after receiving the first request, the proxy module parses the AID of the target card application and saves it in the instance variable targetAID, and then forwards the first request to the shared interface by calling the JCSystem.JCSystem.getAppletShareableInterfaceObject(AID serverAID,byte param) method of the shared interface, wherein the serverAID parameter is the AID of the proxy module, and the param parameter is the proxy token set by the target card application in the initialization (install) phase, or 0 if not set. After receiving the request, the shared interface calls the getShareableInterfaceObject(AID clientAID, byte param) method of the target card application. After the target card application receives the request of the shared interface, if the proxy mode set by the target card application in the initialization phase uses the AID method to specify the proxy, it determines whether the clientAID is equal to the AID set in the initialization phase. If they are equal, the shared interface object of the target card application is returned to the proxy module, and if they are not equal, null is returned. If the proxy mode set in the target card application initialization uses token to specify the proxy, then determine whether param is equal to the token set in the initialization phase. If they are equal, return the shared interface object of the target card application to the proxy module, otherwise return null.

[0045] In one implementation, before the first request sent by the receiving terminal, the method further includes: initializing configuration parameters of the target card application, wherein the configuration parameters include an agent identifier, an agent token, an agent instruction list, and a security level.

[0046] It is understandable that the target card application is in an inactive state after being installed to the smart card through the install command in the initialization phase, and needs to be selected through the select command to enter the active state. The target card application in the active state can perform business processing. For example, Figure 6 As shown in the figure, it is the activation process of the target card application. Among them, in the initialization stage, the custom parameters can be passed to the target card application in TLV format through the c9 parameter, and the custom parameters can include four parameters: agent identification, agent token, agent instruction list, and security level. Exemplarily, as shown in Table 2 below, the agent identification specifies a unique card application agent, that is, a unique agent module, and the agent token specifies that all agent modules holding the agent token can act as agents. Label 63 represents the white list of instructions, and label 64 represents the black list of instructions, which are mutually exclusive.

[0047] Table 2

[0048] In one implementation, the method also includes: receiving a second request sent by the terminal based on the authentication indication; based on the second request, obtaining an authentication result by authenticating the terminal; if the authentication result is successful, returning a second response message to the terminal to indicate successful authentication, wherein the second response message carries an execution result corresponding to the target operation; if the authentication result is a failure, returning the third response message to the terminal to indicate failed authentication.

[0049] Among them, in another implementation method, the authentication result is obtained by authenticating the terminal based on the second request, including: returning a first random number to the terminal based on the third request; receiving first encrypted data sent by the terminal, wherein the first encrypted data is obtained by the terminal encrypting the first random number according to the authentication key; encrypting the first random number according to the authentication key to obtain second encrypted data; and determining the authentication result in response to a consistency judgment of the first encrypted data and the second encrypted data.

[0050] Optionally, the second request may be a GET CHALLENGE (INS: 84) instruction.

[0051] Optionally, the authentication key may be pre-agreed.

[0052] Figure 8 A card application access method provided by an embodiment of the present application is shown, and the method can be executed by a terminal. The method includes the following steps: S810: Send a first request to the smart card.

[0053] The first request is used to request the target card application to perform a target operation.

[0054] S820: Receive a first response message returned by the smart card.

[0055] Among them, the first response message includes a target execution result or an authentication indication, the target execution result is obtained by executing the target operation based on the shared interface object, the authentication indication is used to instruct the terminal to perform authentication, the first response message is determined based on the access control rules of the target card application, the access control rules are obtained through the shared interface object corresponding to the target card application, and the shared interface object is obtained by the smart card through the shared interface.

[0056] In an embodiment of the present application, a first request is sent to a smart card, wherein the first request is used to request a target card application to perform a target operation; and a first response message returned by the smart card is received; wherein the first response message includes a target execution result or an authentication indication, wherein the target execution result is obtained by executing the target operation based on a shared interface object, and the authentication indication is used to instruct the terminal to perform authentication, and the first response message is determined based on an access control rule of the target card application, wherein the access control rule is obtained through a shared interface object corresponding to the target card application, and the shared interface object is obtained by the smart card through a shared interface, which can effectively prevent direct interaction between the terminal and the target card application, and avoid the problem of the terminal bypassing the GP access control mechanism to directly access the target card application, thereby enhancing the security of the target card application.

[0057] In one implementation, when the first response message includes the authentication indication, the method further includes: sending a second request for authentication to the smart card; receiving a second response message or a third response message returned by the smart card based on the second request, wherein the second response message is used to indicate that the authentication is successful, the third response message is used to indicate that the authentication fails, and the second response message carries an execution result corresponding to the target operation.

[0058] For details about the implementation, please refer to Figure 3 The relevant description in the illustrated embodiment will not be repeated here.

[0059] Fig. 9 An interactive schematic diagram of a card application access method provided by an exemplary embodiment of the present application is shown as follows: Fig. 9 As shown, the following steps may be included: S910: CAD selects a proxy module.

[0060] S920: The CAD sends an APDU instruction to the proxy module.

[0061] The instruction data field contains the AID of the target card application.

[0062] S930: The proxy module receives the instruction and parses the target card application AID.

[0063] The AID is stored in the instance variable targetAID. If the targetAID in the instruction data received subsequently does not exist or is equal to the targetAID in the instance variable, it means that the target card application remains unchanged, and then go to S960.

[0064] S940: The proxy module obtains the SIO object of the target card application through JCRE and stores it in the instance variable sio.

[0065] S950: The proxy module obtains the AC rule applied by the target card through the SIO object and stores it in the instance variable ac.

[0066] S960: When the AC rule requires device authentication and data encryption, the CAD initiates the device authentication process to the proxy module. After the authentication is passed, the proxy module saves the authentication pass flag to the instance variable verified. The subsequent card application will check the flag after receiving the instruction.

[0067] S970: CAD sends a data domain encryption instruction to the proxy module.

[0068] S980: The proxy module decrypts the data field using the authentication key.

[0069] S990: The proxy module sends the decrypted APDU instruction to the target card application for processing.

[0070] Fig.10 A schematic diagram showing the structure of a card application access device provided by an embodiment of the present application is shown as follows: Fig.10 As shown, the card application access device 1000 may include: a receiving module 1010 , a first obtaining module 1020 , a second obtaining module 1030 and a processing module 1040 .

[0071] In this embodiment, the receiving module 1010 is used to receive a first request sent by the terminal, wherein the first request is used to request the target card application to perform a target operation; the first acquisition module 1020 is used to obtain the shared interface object through a shared interface when it is determined that the shared interface object corresponding to the target card application has not been obtained, and obtain the access control rules corresponding to the target card application through the shared interface object; the second acquisition module 1030 is used to obtain the security level of the target card application based on the access control rules; the processing module 1040 is used to return a first response message to the first request based on the security level of the target card application, wherein the first response message includes a target execution result or an authentication indication, the target execution result is obtained by executing the target operation based on the shared interface object, and the authentication indication is used to instruct the terminal to perform authentication.

[0072] In one implementation, the first acquisition module 1020 is specifically used to: obtain an initial proxy identifier corresponding to the target card application, wherein the initial proxy identifier is determined by initializing the target card application; in response to a judgment that the initial proxy identifier is consistent with the current proxy identifier, obtain the shared interface object through the shared interface, wherein the current proxy identifier is the proxy identifier corresponding to the first request.

[0073] In one implementation, the first acquisition module 1020 is specifically used to: obtain an initial proxy token corresponding to the target card application, wherein the initial proxy token is determined by initializing the target card application; in response to a judgment that the initial proxy token is consistent with the current proxy token, obtain the shared interface object through the shared interface, wherein the current proxy token is the proxy token corresponding to the first request.

[0074] In one implementation, the processing module 1040 is specifically configured to: when the security level of the target card application is the target level, determine that the first response message includes the target execution result.

[0075] In one implementation, the processing module 1040 is specifically configured to: when the security level of the target card application is not the target level, determine that the first response message includes the authentication indication.

[0076] In one implementation, the determination that the shared interface object corresponding to the target card application has not been acquired includes: when an application identifier of the target card application is inconsistent with a preset card application identifier, determining that the shared interface object has not been acquired, wherein the preset card application identifier is an application identifier of the preset card application requested to be accessed by a second request, and the second request is a previous request received by the smart card that is adjacent to the first request.

[0077] In one implementation, before the first request sent by the receiving terminal, the card application access device 1000 may further include: a configuration module for initializing configuration parameters of the target card application, wherein the configuration parameters include an agent identifier, an agent token, an agent instruction list and a security level.

[0078] In one implementation, the card application access device 1000 may also include: a verification module, used to receive a second request sent by the terminal based on the authentication indication; based on the second request, obtain an authentication result by authenticating the terminal; if the authentication result is successful, return a second response message indicating successful authentication to the terminal, wherein the second response message carries an execution result corresponding to the target operation; if the authentication result is a failure, return the third response message indicating failed authentication to the terminal.

[0079] The card application access device provided in the embodiment of the present application can realize Figure 3 To avoid repetition, the various processes implemented in the illustrated method embodiment will not be described again here.

[0080] The card application access device in the embodiment of the present application may be a device, or a component, an integrated circuit, or a chip in an electronic device. The embodiment of the present application does not specifically limit this.

[0081] The card application access device in the embodiment of the present application may be a device having an operating system, which may be an Android operating system, an iOS operating system, or other possible operating systems, which are not specifically limited in the embodiment of the present application.

[0082] Fig.11 A schematic diagram showing the structure of a card application access device provided by an embodiment of the present application is shown as follows: Fig.11 As shown, the card application access device 1100 may include: a sending module 1110 and a receiving module 1120 .

[0083] In this embodiment, The sending module 1110 is used to send a first request to the smart card, wherein the first request is used to request a target card application to perform a target operation; The receiving module 1120 is used to receive a first response message returned by the smart card; Among them, the first response message includes a target execution result or an authentication indication, the target execution result is obtained by executing the target operation based on the shared interface object, the authentication indication is used to instruct the terminal to perform authentication, the first response message is determined based on the access control rules of the target card application, the access control rules are obtained through the shared interface object corresponding to the target card application, and the shared interface object is obtained by the smart card through the shared interface.

[0084] In one implementation, when the first response message includes the authentication indication, the card application access device 1100 may also include: an authentication module, used to send a second request for authentication to the smart card; receive a second response message or a third response message returned by the smart card based on the second request, wherein the second response message is used to indicate that the authentication is successful, the third response message is used to indicate that the authentication fails, and the second response message carries an execution result corresponding to the target operation.

[0085] The card application access device provided in the embodiment of the present application can realize Figure 8 To avoid repetition, the various processes implemented in the illustrated method embodiment will not be described again here.

[0086] The card application access device in the embodiment of the present application may be a device, or a component, an integrated circuit, or a chip in an electronic device. The embodiment of the present application does not specifically limit this.

[0087] The card application access device in the embodiment of the present application may be a device having an operating system, which may be an Android operating system, an iOS operating system, or other possible operating systems, which are not specifically limited in the embodiment of the present application.

[0088] Optional, such as Fig.12 As shown, an embodiment of the present application also provides an electronic device 1200, including a processor 1210, a memory 1220, and a program or instruction stored in the memory 1220 and executable on the processor 1210. When the program or instruction is executed by the processor 1210, each process of the above-mentioned card application access method embodiment is implemented, and the same technical effect can be achieved. To avoid repetition, it will not be repeated here.

[0089] The embodiment of the present application also provides a readable storage medium, on which a program or instruction is stored. When the program or instruction is executed by a processor, each process of the above-mentioned card application access method embodiment is implemented, and the same technical effect can be achieved. To avoid repetition, it will not be repeated here.

[0090] The processor is the processor in the electronic device described in the above embodiment. The readable storage medium includes a computer readable storage medium, such as a computer read-only memory (ROM), a random access memory (RAM), a magnetic disk or an optical disk.

[0091] An embodiment of the present application further provides a chip, which includes a processor and a communication interface, wherein the communication interface is coupled to the processor, and the processor is used to run programs or instructions to implement the various processes of the above-mentioned card application access method embodiment, and can achieve the same technical effect. To avoid repetition, it will not be repeated here.

[0092] It should be understood that the chip mentioned in the embodiments of the present application can also be called a system-level chip, a system chip, a chip system or a system-on-chip chip, etc.

[0093] The embodiment of the present application also provides a computer program product, which includes at least one computer program. When the computer program is loaded and executed by a processor, the various processes of the above-mentioned card application access method embodiment are implemented, and the same technical effect can be achieved. To avoid repetition, it will not be repeated here.

[0094] It should be noted that, in this article, the terms "comprise", "include" or any other variant thereof are intended to cover non-exclusive inclusion, so that the process, method, article or device including a series of elements includes not only those elements, but also includes other elements not explicitly listed, or also includes elements inherent to such process, method, article or device. In the absence of further restrictions, the elements defined by the sentence "comprise one..." do not exclude the presence of other identical elements in the process, method, article or device including the element. In addition, it should be pointed out that the scope of the methods and devices in the embodiments of the present application is not limited to performing functions in the order shown or discussed, and may also include performing functions in a substantially simultaneous manner or in reverse order according to the functions involved, for example, the described method may be performed in an order different from that described, and various steps may also be added, omitted, or combined. In addition, the features described with reference to certain examples may be combined in other examples.

[0095] Through the description of the above implementation methods, those skilled in the art can clearly understand that the above-mentioned embodiment methods can be implemented by means of software plus a necessary general hardware platform, and of course by hardware, but in many cases the former is a better implementation method. Based on such an understanding, the technical solution of the present application, or the part that contributes to the prior art, can be embodied in the form of a software product, which is stored in a storage medium (such as ROM / RAM, a magnetic disk, or an optical disk), and includes a number of instructions for a terminal (which can be a mobile phone, a computer, a server, an air conditioner, or a network device, etc.) to execute the methods described in each embodiment of the present application.

[0096] The embodiments of the present application are described above in conjunction with the accompanying drawings, but the present application is not limited to the above-mentioned specific implementation methods. The above-mentioned specific implementation methods are merely illustrative and not restrictive. Under the guidance of the present application, ordinary technicians in this field can also make many forms without departing from the purpose of the present application and the scope of protection of the claims, all of which are within the protection of the present application.

Claims

1. A card application access method, characterized in that: Applied to a smart card, the method comprises: Receiving a first request sent by a terminal, wherein the first request is used to request a target card application to perform a target operation; In the case where it is determined that the shared interface object corresponding to the target card application has not been obtained, obtaining the shared interface object through a shared interface, and obtaining the access control rule corresponding to the target card application through the shared interface object; Based on the access control rule, obtaining the security level of the target card application; Based on the security level of the target card application, a first response message is returned to the first request, wherein the first response message includes a target execution result or an authentication indication, the target execution result is obtained by executing the target operation based on the shared interface object, and the authentication indication is used to instruct the terminal to perform authentication.

2. The method according to claim 1, characterized in that Obtaining the shared interface object through the shared interface includes: Acquire an initial proxy identifier corresponding to the target card application, wherein the initial proxy identifier is determined by initializing the target card application; In response to a determination that the initial proxy identifier is consistent with the current proxy identifier, the shared interface object is acquired through the shared interface, wherein the current proxy identifier is the proxy identifier corresponding to the first request.

3. The method according to claim 2, characterized in that The acquiring, through the shared interface, a shared interface object corresponding to the target card application comprises: Acquire an initial proxy token corresponding to the target card application, wherein the initial proxy token is determined by initializing the target card application; In response to a determination that the initial proxy token is consistent with a current proxy token, the shared interface object is acquired through the shared interface, wherein the current proxy token is a proxy token corresponding to the first request.

4. The method according to claim 1, characterized in that: The returning a first response message to the first request based on the target card application security level includes: In a case where the security level of the target card application is a target level, it is determined that the first response message includes the target execution result.

5. The method according to claim 1, characterized in that The returning a first response message to the first request based on the target card application security level includes: In a case where the security level of the target card application is not the target level, it is determined that the first response message includes the authentication indication.

6. The method according to claim 1, characterized in that The determining that the shared interface object corresponding to the target card application is not obtained includes: When the application identifier of the target card application is inconsistent with the preset card application identifier, it is determined that the shared interface object has not been obtained, wherein the preset card application identifier is the application identifier of the preset card application requested to be accessed by the second request, and the second request is the previous request received by the smart card adjacent to the first request.

7. The method according to claim 1, characterized in that Before the receiving terminal sends the first request, the method further includes: Initialize the configuration parameters of the target card application, wherein the configuration parameters include an agent identifier, an agent token, an agent instruction list, and a security level.

8. The method according to claim 5, characterized in that The method further comprises: receiving a second request sent by the terminal based on the authentication indication; Based on the second request, obtaining an authentication result by authenticating the terminal; If the authentication result is successful, returning a second response message indicating the authentication success to the terminal, wherein the second response message carries an execution result corresponding to the target operation; When the authentication result is failure, a third response message indicating the authentication failure is returned to the terminal.

9. A card application access method, characterized in that: Applied to a terminal, the method comprises: Sending a first request to the smart card, wherein the first request is used to request a target card application to perform a target operation; Receiving a first response message returned by the smart card; Among them, the first response message includes a target execution result or an authentication indication, the target execution result is obtained by executing the target operation based on the shared interface object, the authentication indication is used to instruct the terminal to perform authentication, the first response message is determined based on the access control rules of the target card application, the access control rules are obtained through the shared interface object corresponding to the target card application, and the shared interface object is obtained by the smart card through the shared interface.

10. The method according to claim 9, characterized in that In the case where the first response message includes the authentication indication, the method further includes: sending a second request for authentication to the smart card; Receive a second response message or a third response message returned by the smart card based on the second request, wherein the second response message is used to indicate that the authentication is successful, the third response message is used to indicate that the authentication fails, and the second response message carries an execution result corresponding to the target operation.

11. A card application access device, characterized in that: include: A receiving module, configured to receive a first request sent by a terminal, wherein the first request is used to request a target card application to perform a target operation; A first acquisition module is used to acquire the shared interface object through a shared interface if it is determined that the shared interface object corresponding to the target card application has not been acquired, and acquire the access control rule corresponding to the target card application through the shared interface object; A second acquisition module, configured to acquire the security level of the target card application based on the access control rule; A processing module is used to return a first response message to the first request based on the security level of the target card application, wherein the first response message includes a target execution result or an authentication indication, the target execution result is obtained by executing the target operation based on the shared interface object, and the authentication indication is used to instruct the terminal to perform authentication.

12. A card application access device, characterized in that: include: A sending module, used for sending a first request to a smart card, wherein the first request is used for requesting a target card application to perform a target operation; A receiving module, used to receive a first response message returned by the smart card; wherein the first response message includes a target execution result or an authentication indication, the target execution result is obtained by executing the target operation based on a shared interface object, the authentication indication is used to instruct the terminal to perform authentication, the first response message is determined based on an access control rule of the target card application, the access control rule is obtained through a shared interface object corresponding to the target card application, and the shared interface object is obtained by the smart card through a shared interface.

13. An electronic device, characterized in that: The method comprises a processor, a memory and a program or instruction stored in the memory and executable on the processor, wherein the program or instruction, when executed by the processor, implements the steps of the card application access method as claimed in any one of claims 1 to 10.

14. A readable storage medium, characterized in that: The readable storage medium stores a program or instruction, and when the program or instruction is executed by a processor, the steps of the card application access method according to any one of claims 1 to 10 are implemented.

15. A computer program product, characterized in that The computer program product comprises program instructions, and when the program instructions are executed by a computer, the computer is enabled to implement the steps of the card application access method according to any one of claims 1 to 10.

Citation Information

Patent Citations

  • Authentication method for improving JavaCard shared interface access security and authentication system

    CN107968784A

  • Identity authentication method and system based on converged media cloud platform

    CN111541656A

  • Security authentication method and device, computer equipment and storage medium

    CN117062073A

  • Method and terminal for data sharing between fast application and native application

    WO2021104259A1

  • Communication agent establishing method and apparatus, and terminal

    WO2021238939A1