Security control method, device and medium

Abstract

The application relates to the terminal field, in particular to a security control method, device and medium. The method establishes a security verification relationship between a first application needing security control and a security application installed on a terminal when the first application is installed or first run on the terminal. The security application can provide security verification services. The security verification relationship enables the first application to determine whether the user identity corresponding to the detected user operation is legal according to the received verification information, and further determines whether to execute the user operation, so as to ensure the security of the user operation process.

Description

Technical Field

[0001] This invention relates to the field of terminals, and more specifically to a security control method, device, and medium. Background Technology

[0002] Telecommunications fraud (or simply telecom fraud) refers to deceptive acts committed using telephones, the internet, and other communication methods with the intent to illegally possess another person's property. Telecom fraud typically begins with a phone call or chat on social media. After the user falls for the scam, the fraudster may gradually guide them to provide SMS verification codes, or direct them to visit a pre-prepared fraudulent website (also known as a phishing website) or install a specific application (also known as a phishing app) before requiring them to log in and provide SMS verification codes. Current security control measures include reminders to users to be wary of scams in SMS messages containing verification codes.

[0003] However, in some telecom fraud scenarios, users may ignore the warnings in the text message because they cannot see through the scammer's language traps, and still provide the SMS verification code to the scammer. As a result, the security of users' property and personal information cannot be effectively guaranteed. Summary of the Invention

[0004] This application provides a security control method, device, and medium that can ensure that the electronic device requesting the SMS verification code and the electronic device receiving the SMS verification code are the same device. This can effectively prevent the target user from providing the SMS verification code to the fraudster in the case of telecommunications fraud, and effectively protect the user's property and personal information.

[0005] In a first aspect, this application provides a security control method applied to a first electronic device. The method includes: receiving first verification information, wherein the first verification information is verification information corresponding to a first user operation request acting on a first interface of a first application, the first verification information being used to determine whether the user's identity is legitimate based on a first matching result, the first matching result being a matching result between the first verification information and signature information stored in a second electronic device; or, the first verification information is SMS information encrypted by the second electronic device using a public key, the first verification information being used to determine whether the user's identity is legitimate based on a second matching result, the second matching result being a result of decrypting the first verification information, the decryption result being related to the existence of a private key corresponding to the public key; determining the legitimacy of the user identity corresponding to the first user operation based on the first verification information, and displaying a second interface, wherein the second interface includes an interface after the first application successfully responds to the first user operation.

[0006] For example, the aforementioned first verification information may include SMS verification codes or signature information. The aforementioned first electronic device may be a mobile phone or other terminal electronic device, hereinafter also referred to as the first terminal. The user of this first electronic device may be a target user in some telecommunications fraud scenarios. The aforementioned second electronic device may be, for example, a server deployed on the server side of the first application. The first application may be an application that requires users to enter personal information such as mobile phone number, ID card number, login password, and payment password when registering or logging into a personal account. The user's login operations on the relevant interface of the first application may involve the security of the user's personal information and property. The aforementioned first user operation may include login operations and other operations that require verification, such as payment operations or transfer operations, etc., without limitation.

[0007] Corresponding to the signature information, the aforementioned first verification information can be signature information generated based on card information, etc., and the aforementioned first matching result can be a matching result of whether there is a pre-uploaded signature information generated based on the corresponding card information on the relevant server. Corresponding to the SMS verification code, the aforementioned first verification information can be SMS information encrypted by the server using a public key, and the aforementioned second matching result can be the result of whether the key used by the first electronic device to decrypt the first verification information can match the public key used by the server. Based on this, the first electronic device, based on the security control method provided in the first aspect, can determine whether the user identity corresponding to the first user operation received by the first application is legitimate by using the matching result of the first verification information on the server, and respond to the first user operation by displaying the corresponding interface, such as the aforementioned second interface, if the user identity is confirmed to be legitimate, thereby ensuring the security of the execution of the first user operation process.

[0008] In one possible implementation of the first aspect above, the first verification information includes an SMS verification code, wherein the SMS verification code is a verification code generated by the second electronic device in response to a first verification request from the first application.

[0009] In one possible implementation of the first aspect above, the first verification information is SMS information encrypted with a public key by the second electronic device, including: the first verification information is a first SMS verification code encrypted with a first public key by the second electronic device, wherein the first public key corresponds to the first private key in the first key pair in the first electronic device.

[0010] In one possible implementation of the first aspect above, determining the legitimacy of the user identity corresponding to the first user operation based on the first verification information includes: decrypting the first SMS verification code using a first private key; and determining the legitimacy of the user identity corresponding to the first user operation based on the successful decryption of the first SMS verification code.

[0011] That is, the public key (e.g., the first public key) used by the server (e.g., the second electronic device mentioned above) to encrypt the generated SMS verification code in response to the first verification request of the first application can belong to the same key pair (e.g., the first key pair mentioned above) as the private key (e.g., the first private key) on the first electronic device on which the first application runs, that is, the first public key corresponds to the first private key.

[0012] Thus, based on the successful decryption of the received encrypted first SMS verification code using the first private key, the first electronic device can determine that the user identity corresponding to the detected first user operation is legitimate. At this point, the first electronic device can securely execute the first user operation and display the aforementioned second interface.

[0013] In one possible implementation of the first aspect above, the first verification information is SMS information encrypted with a public key by the second electronic device, including: the first verification information is a second SMS verification code encrypted with a second public key by the second electronic device, wherein the second public key corresponds to the second private key in the second key pair in the third electronic device.

[0014] In one possible implementation of the first aspect above, the method further includes: decrypting the second SMS verification code using a first private key, wherein the first private key corresponds to the first public key in the first key pair in the first electronic device; and determining that the user identity corresponding to the first user operation is illegitimate based on the result of the second SMS verification code decryption failure.

[0015] In other words, the public key (e.g., the second public key) used by the server (e.g., the second electronic device mentioned above) to encrypt the generated SMS verification code in response to the first verification request from the first application can belong to the same key pair (e.g., the first key pair mentioned above) as the private key (e.g., the second private key mentioned above) on the third electronic device running the first application. In some telecom fraud scenarios, such as when the third electronic device is the terminal electronic device used by the fraudster, the first electronic device used by the target user can determine that the user identity corresponding to the first user operation is illegitimate based on the failure to decrypt the received encrypted second SMS verification code using the first private key. In this case, the first electronic device may choose not to execute the first user operation.

[0016] In one possible implementation of the first aspect above, the first electronic device includes a second application, wherein the second application is used to receive and process the first SMS verification code, and the method further includes: sending the first public key to the first application based on the second application's response to the first application's request to obtain a key.

[0017] In one possible implementation of the first aspect above, the method further includes: sending the first public key to the second electronic device based on the first application, wherein the first public key is used to encrypt the SMS verification code generated by the second electronic device to obtain the first SMS verification code.

[0018] For example, the second application mentioned above could be an SMS application. The first application installed on the first electronic device can establish a secure authentication relationship with the second application. The first application can obtain the public key from the corresponding generated key pair (e.g., the first key pair mentioned above) from the second application and provide it to the server deployed on the server side of the first application (e.g., the second electronic device mentioned above). In this way, when the first application on the first electronic device responds to a received first user operation or other user operations that require authentication, it can use verification information such as an SMS verification code encrypted with the corresponding public key sent by the server to ensure the legitimacy of the user identity corresponding to the first user operation.

[0019] In one possible implementation of the first aspect above, the method further includes: displaying a third interface of the second application, the third interface including the first verification information; or sending the first verification information to the first application to confirm the response to the first user operation; or providing the first verification information to an input method application so that the input method application displays the first verification information.

[0020] For example, the aforementioned third interface could be an SMS interface that includes the decrypted SMS verification code. Users can view the decrypted SMS verification code on this interface and then input it into the designated verification code input box. This input method can include copying and pasting or manual input, and is not limited here. Sending the first verification information to the first application could, for example, automatically fill the decrypted SMS verification code into the verification code input box on the login interface or other related interfaces. Providing the first verification information to the input method application could, for example, provide the decrypted SMS verification code to the input method application for display on the relevant input method interface. This input method interface could, for example, include a pop-up input method soft keyboard triggered by the user clicking the verification code input box on the login interface or other related interfaces. The decrypted SMS verification code could be displayed in the input area of ​​this soft keyboard, and the user could tap the SMS verification code displayed on the soft keyboard to confirm inputting it into the corresponding verification code input box.

[0021] In one possible implementation of the first aspect above, the method further includes: if it is determined that the user identity corresponding to the first user operation is illegitimate, displaying a fifth interface, wherein the fifth interface includes a first risk warning message related to the first verification information.

[0022] For example, the fifth interface mentioned above could be an interface containing a risk warning information box, which can display corresponding risk warning content, such as "This verification information has a high security risk, please pay attention!", etc., without any restrictions.

[0023] In one possible implementation of the first aspect above, the first verification information includes unencrypted SMS information, and the method further includes: determining, based on the first verification information, that the user identity corresponding to the first user operation is illegitimate, and displaying a sixth interface, wherein the sixth interface includes second risk warning information related to the first verification information.

[0024] For example, the risk warning information box displayed on the sixth interface above can also display corresponding risk warning content, such as "This verification information has a high security risk, please pay attention!", etc., without any restrictions.

[0025] It should be understood that when a fraudster requests verification from a server (e.g., the aforementioned second electronic device) through another terminal (e.g., the third electronic device mentioned above) and guides the target user to provide verification information such as SMS verification codes, this verification information may be encrypted using the public key provided by a second application installed on the other terminal to the first application. The second application on the target user's terminal (e.g., the aforementioned first electronic device) cannot decrypt this verification information based on the mismatched private key, and therefore cannot display the content of the verification information, such as the received SMS verification code or the SMS content containing the SMS verification code. Based on this, the target user cannot provide the SMS verification code to the fraudster.

[0026] Thus, the security control method provided in this application can ensure that the electronic device requesting the SMS verification code and the electronic device receiving the SMS verification code are the same device, which can effectively prevent the target user who is being defrauded from providing the SMS verification code to the fraudster in the case of telecommunications fraud, and effectively protect the user's property, personal information and other security.

[0027] In one possible implementation of the first aspect above, the first verification information includes first signature information obtained from a third application, wherein the third application is used to manage card information related to user identity, the card information is used to generate the first signature information, and the first signature information is related to signature information stored in the second electronic device.

[0028] In one possible implementation of the first aspect above, the method further includes: in response to an operation by a second user instructing the binding of the card information, obtaining the card information from a security authority that manages the card information; generating the first signature information based on the card information; and sending the first signature information to the second electronic device.

[0029] In one possible implementation of the first aspect above, determining the legitimacy of the user identity corresponding to the first user operation based on the first verification information includes: sending a second verification request to the second electronic device based on the second signature information, wherein the second verification request is used to request the second electronic device to verify whether the second signature information has matching signature information; receiving a result from the second electronic device confirming that the second signature information matches the stored first signature information, and determining the legitimacy of the user identity corresponding to the first user operation.

[0030] For example, the third application used to manage card information related to user identity could be a wallet app, and the card information could be bank card information or ID card information. Correspondingly, the security agency managing the card information could be a banking institution or a security agency capable of managing user ID card information. The first signature information could be signature information generated based on bank card information or ID card information. Based on this, when a user logs into their personal account for the first time, the first application can request signature information (i.e., the first signature information) generated based on the card information related to the user's identity from the third application (another example of a security application) and provide it to the server (i.e., the second electronic device). The server-side of the first application deployed on the server can store the first signature information. When the first application detects the user's login operation again, it can request signature information (i.e., the second signature information) from the third application again. The first application can use the second signature information to request verification from the server, and when the server returns the matching result of the first signature information and the second signature information, it determines whether the user's identity is legitimate. If the user's identity is legitimate, the user's login operation is executed (an example of the first user operation).

[0031] Thus, in some telecom fraud scenarios, when fraudsters attempt to log into a target user's account using other terminals, they cannot successfully complete the login operation because they cannot pass the verification of the target user's identity. This helps protect the target user's property and personal information security, thereby preventing the target user from being defrauded.

[0032] Secondly, this application provides a security control method applied to a second electronic device, the second electronic device including a server of a first application, the method comprising: receiving a first verification request from the first application of the first electronic device; determining first verification information, wherein the first verification information is used to determine whether a user's identity is legitimate based on a first matching result, the first matching result being a matching result between the first verification information and stored signature information; or, the first verification information is a text message encrypted with a public key, the first verification information being used to determine whether a user's identity is legitimate based on a second matching result, the second matching result being a result of decrypting the first verification information, the decryption result being related to whether a private key corresponding to the public key exists; and sending the first verification information to the first electronic device.

[0033] As mentioned above, the second electronic device is, for example, a server deployed by the server side of the first application.

[0034] In one possible implementation of the second aspect above, the first verification information includes an SMS verification code, which is a verification code generated in response to the first verification request.

[0035] In one possible implementation of the second aspect above, the first verification information is SMS information encrypted with a public key, including: a first SMS verification code encrypted with the first public key, wherein the first public key corresponds to the first private key in the first key pair in the first electronic device.

[0036] In one possible implementation of the second aspect above, the first verification information is SMS information encrypted with a public key, including: a second SMS verification code encrypted with a second public key, wherein the second public key corresponds to the second private key in the second key pair in the third electronic device.

[0037] In one possible implementation of the second aspect above, the first verification information includes unencrypted SMS information, which is used to determine that the user's identity is illegitimate based on the unencrypted state.

[0038] In one possible implementation of the second aspect above, the method further includes: receiving the first public key from the first electronic device, wherein the first public key is used to encrypt the generated SMS verification code to obtain the first SMS verification code.

[0039] In one possible implementation of the second aspect above, the method further includes: receiving first signature information from the first electronic device, the first signature information being generated based on card information, the card information being obtained from a security authority managing the card information in response to an instruction to a second user to bind the card information; and storing the first signature information.

[0040] In one possible implementation of the second aspect above, the method further includes: receiving a second verification request carrying second signature information; determining a third matching result that matches the second signature information with the stored first signature information; and sending the third matching result to the first electronic device.

[0041] Thirdly, this application provides an electronic device, including: one or more processors; one or more memories; wherein the one or more memories store one or more programs, and when the one or more programs are executed by the one or more processors, the electronic device performs the security control method provided in the first aspect and various possible implementations of the first aspect; or, the electronic device performs the security control method provided in the second aspect and various possible implementations of the second aspect.

[0042] Fourthly, this application provides a computer-readable storage medium storing instructions that, when executed on a computer, cause the computer to perform the security control methods provided in the first aspect and various possible implementations thereof, or cause the computer to perform the security control methods provided in the second aspect and various possible implementations thereof.

[0043] Fifthly, this application provides a security control system, including a first electronic device and a second electronic device, wherein the first electronic device is used to execute the security control method provided in the first aspect and various possible implementations thereof; and the second electronic device is used to execute the security control method provided in the second aspect and various possible implementations thereof.

[0044] In a sixth aspect, this application provides a computer program product, including a computer program / instructions that, when executed by a processor, implement the security control method provided in the first aspect and various possible implementations thereof; and a second electronic device for executing the security control method provided in the second aspect and various possible implementations thereof.

[0045] In a seventh aspect, this application provides a communication device, comprising: a module for executing the security control method provided in the first aspect and various possible implementations thereof; or, a module for executing the security control method provided in the second aspect and various possible implementations thereof.

[0046] Eighthly, this application provides a chip including a processor and a memory, for executing a computer program or instructions stored in the memory, causing the chip to perform the security control methods provided in the first aspect and various possible implementations of the first aspect, or causing the computer to perform the security control methods provided in the second aspect and various possible implementations of the second aspect.

[0047] The beneficial effects of the second to the third aspects mentioned above can be referred to the relevant descriptions in the first aspect and its various possible implementations, which will not be repeated here. Attached Figure Description

[0048] Figure 1 The diagram shows a scenario where a security control method is applied to a telecommunications fraud case.

[0049] Figure 2a The diagram shown is a schematic representation of the implementation principle of a security control method for displaying a successfully decrypted SMS verification code, as provided in an embodiment of this application.

[0050] Figure 2b The diagram shown illustrates the implementation principle of another security control method based on SMS verification codes provided in this application embodiment.

[0051] Figure 2c The diagram shown illustrates the implementation principle of a security control method that does not display a successfully decrypted SMS verification code, as provided in an embodiment of this application.

[0052] Figure 2d The diagram shown is a schematic representation of the implementation principle of a security control method based on bank card information provided in an embodiment of this application.

[0053] Figure 2e The diagram shown is a schematic representation of the implementation principle of a security control method based on ID card information provided in an embodiment of this application.

[0054] Figure 3 The diagram shown is an interactive implementation flow diagram of a security control method provided in an embodiment of this application.

[0055] Figure 4a The image shown is a schematic diagram of a login interface provided in an embodiment of this application.

[0056] Figure 4b The image shown is a schematic diagram of a login interface after automatically filling in an SMS verification code, provided in an embodiment of this application.

[0057] Figure 4c The image shown is a schematic diagram of another login interface after automatically filling in the SMS verification code, provided in an embodiment of this application.

[0058] Figure 4d The image shown is a schematic diagram of an SMS verification code display interface provided in an embodiment of this application.

[0059] Figure 5 The diagram shown is an interactive implementation flow diagram of another security control method provided in this application embodiment.

[0060] Figure 6a The diagram shown is a schematic representation of the software structure of an electronic device according to an embodiment of this application.

[0061] Figure 6b The diagram shown is a software structure diagram of another electronic device provided in an embodiment of this application.

[0062] Figure 7 The diagram shown is a schematic diagram of the system structure of a safety control system provided in an embodiment of this application.

[0063] Figure 8 The figure shown is a schematic diagram of the hardware structure of an electronic device provided in an embodiment of this application.

[0064] Figure 9 The diagram shown is a structural schematic of a communication device provided in an embodiment of this application. Detailed Implementation

[0065] The method provided in this application can be applied to any terminal electronic device, including but not limited to mobile stations (MS), mobile terminals (MT), etc., also known as electronic devices. For example, electronic devices can be mobile phones, smart TVs, wearable devices, tablets, desktop computers, laptops, virtual reality (VR) devices, augmented reality (AR) devices, terminals in industrial control, terminals in self-driving cars, terminals in smart grids, terminals in transportation safety, terminals in smart cities, terminals in smart homes, etc. This application does not limit the specific form of the terminal.

[0066] For example, the wearable device in the embodiments of this application may include smartwatches, smart bracelets, augmented reality (AR) devices, virtual reality (VR) devices, etc., and this application does not impose any special restrictions on the specific form of the wearable device.

[0067] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions in the embodiments of this application will be described in detail below with reference to the accompanying drawings and specific implementation methods.

[0068] Figure 1 A schematic diagram illustrating a security control method applied in a telecommunications fraud scenario is shown.

[0069] like Figure 1 As shown, the scenario includes a first terminal 00, a second terminal 10, and a server 20. The first terminal 00 can be a terminal electronic device used by the target user in a telecommunications fraud scheme; in this embodiment, it can also be referred to as a first electronic device, such as a mobile phone or a smartwatch. The second terminal 10 can be a terminal electronic device used by the fraudsters committing the fraud, such as a computer, mobile phone, or landline with a client installed that can make virtual VoIP calls.

[0070] In this embodiment, the server 20 can be used to deploy a server-side application for the first application, providing services and support for the corresponding functions of the first application installed on the first terminal 00 or the second terminal 10. The server 20 can be referred to as a second electronic device in this embodiment. The first application can be an application that requires users to enter personal information such as mobile phone number, ID number, login password, and payment password when registering or logging into a personal account, including but not limited to instant messaging applications, browser applications, smart assistants, game applications, shopping applications, or financial management applications, etc., without limitation. The server 20 can send verification information such as SMS verification codes to the first terminal 00 through the server of a telecommunications operator; that is, the server-side application for the first application can send verification information such as SMS verification codes to the first terminal 00 through a telecommunications operator.

[0071] In some scenarios, such as when a second terminal 10 responds to a fraudster making a phone call, it initiates a call request to the first terminal 00. After answering the call, the user of the first terminal 00 may fall victim to a scam during the conversation. During this process, the fraudster may impersonate customer service (e.g., bank customer service) and use their acquired personal information to perform malicious actions that could lead to financial loss for the user. For example, the second terminal 10 might detect a fraudster attempting to log into a target user's account on a bank's client login page, or detect a fraudster attempting to transfer funds. These actions typically require security verification, such as verifying identity via SMS verification codes. In this case, the second terminal 10 can respond to the detected actions by requesting verification from the server 20.

[0072] Correspondingly, server 20 can send verification information such as SMS verification codes to the first terminal 00 held by the target user. After receiving the SMS verification code, the first terminal 00 can display the SMS content containing the SMS verification code in response to the user's operation of viewing the SMS, as shown in the reference. Figure 1 As shown, the SMS message content could be something like, "[Application or Bank] Your SMS verification code is 123456. You are logging into an application or bank account. If this was not your operation, please ignore it." In some scenarios, the SMS message displayed on the first terminal 00 may also include prompts such as "If this was not your operation, please do not provide it to others," reminding users to be wary of scams.

[0073] However, users of the first terminal (00) may ignore the warnings in the SMS message because they cannot see through the scammer's linguistic traps, and still provide the SMS verification code to the scammer. After obtaining the SMS verification code, the scammer can verify the user's identity, successfully log into the target user's account, and perform operations such as binding bank cards, transferring money, and confirming payments to transfer the user's assets, causing financial losses to the user.

[0074] In other scenarios, telecom fraud targets users who may click on phishing websites or download phishing apps within the text message content displayed on the first terminal. This could lead to users entering more private information and providing SMS verification codes under the fraudsters' guidance, resulting in the leakage of even more personal information.

[0075] Thus, as mentioned earlier, some current security control solutions cannot effectively prevent users from providing SMS verification codes to fraudsters, thereby failing to effectively protect users' property, personal information, and other security.

[0076] To address the aforementioned issues, this application provides a security control method. When a first application requiring security control is installed or runs for the first time on a terminal, a security authentication relationship is established between the first application and the security application installed on the terminal. The security application provides security authentication services. This security authentication relationship enables the first application to determine the legitimacy of the user identity corresponding to a detected user operation based on received authentication information, and thus determine whether to execute the user operation, ensuring the security of the execution process. For example, the first application can obtain the public key from a key pair from a second application (an example of a security application) and provide it to the server. The server uses the received public key to encrypt the authentication information and sends the encrypted authentication information to the terminal. The second application uses the private key from the key pair to decrypt the received authentication information. Specifically, when responding to user login or transaction requests, the first application can include the aforementioned public key in the corresponding request to the server. Then, when the terminal receives authentication information encrypted with the aforementioned public key from the server via the second application, it can use the corresponding private key to decrypt the authentication information and display it or provide it to the first application for authentication purposes such as login or transaction requests. At this time, the verification information mentioned above can be, for example, an SMS verification code, and correspondingly, the second application mentioned above can be, for example, an SMS application.

[0077] It should be understood that when a fraudster requests verification from a server through another terminal and guides the target user to provide verification information such as an SMS verification code, this verification information may be encrypted using the public key provided by a second application installed on the other terminal to the first application. The second application on the target user's terminal cannot decrypt this verification information based on the mismatched private key, and therefore cannot display the content of the verification information, such as the received SMS verification code or the SMS content containing the verification code. Based on this, the target user cannot provide the SMS verification code to the fraudster. Thus, the security control method provided in this application ensures that the electronic device requesting and receiving the SMS verification code is the same device, effectively preventing the defrauded target user from providing the SMS verification code to the fraudster in a telecommunications fraud scenario, and effectively protecting the user's property and personal information security.

[0078] For example, verification information could be signature information generated based on card / certificate information. When a user logs into their personal account for the first time, the first application can request a digital signature (referred to as the first signature) from a third application (another example of a security application) based on the user's identity-related card / certificate information. This signature is then provided to the server of the first application, which stores the signature. Based on this, when the first application detects the user logging into their personal account again, it can request the signature again from the third application (referred to as the second signature). The first application can use this second signature to request verification from the server. When the server returns the matching result between the first and second signatures, it determines whether the user's identity is legitimate. If the user's identity is legitimate, the login operation is executed. In this case, the card / certificate information can include the user's bank card or ID card, etc. The third application could be, for example, a wallet app or other payment app. Thus, in some telecom fraud scenarios, when fraudsters attempt to log into a target user's account using other terminals, they cannot successfully complete the login operation because they cannot pass the target user's identity verification. This helps protect the target user's property and personal information security, preventing the target user from being defrauded.

[0079] In this embodiment, the aforementioned server can be the server for the first application. This server can be deployed on the aforementioned... Figure 1 In the scenario shown, server 20 provides services and call support for the functions required by the first application installed on terminal electronic devices such as first terminal 00 or second terminal 10. For example, if the first application is a client APP of a bank, server 20 can be deployed to provide corresponding payment, transfer and other transaction functions; no restrictions are placed here.

[0080] Figure 2a This application provides a schematic diagram illustrating the implementation principle of a security control method based on SMS verification codes. The explanation uses an SMS verification code as an example.

[0081] a1. The first terminal 00 detects the user's instruction to open the first application and runs the first application.

[0082] a2.1 The first application requests the first public key from the second application on the first terminal 00.

[0083] For example, the process involves the first application sending a request to the second application to obtain the first public key, and the second application responding to the request by sending the first public key back to the first application. In this embodiment, the second application is an application capable of providing security verification services, such as a text messaging application. In other embodiments, the second application may also be other applications capable of providing security authentication services, and this is not limited here.

[0084] a2.2 The first application of the first terminal 00 sends a first verification request carrying the first public key to the server 20. Correspondingly, the server 20 receives the first public key.

[0085] For example, the first terminal 00, based on the first application, can respond to user operations that require verification, such as instructing a user to log in to their personal account on an interface including a login control, and send a first verification request carrying the first public key to the server 20. The server 20 may deploy the server-side of the first application.

[0086] a3. Server 20 can generate an SMS verification code encrypted with a first public key in response to the first verification request. Specifically, server 20 can use the received first public key to encrypt the SMS verification code generated in response to the first verification request, thus obtaining an encrypted SMS verification code.

[0087] a4. Server 20 requests the telecommunications operator's server to send an encrypted SMS verification code.

[0088] a5.1 The telecommunications operator's server sends an encrypted SMS verification code to the first terminal 00.

[0089] Among them, the SMS communication service provided by the telecommunications operator's server can respond to the request of server 20, generate an encrypted SMS verification code, and send the encrypted SMS verification code to the first terminal.

[0090] a5.2 The second application of the first terminal 00 can use the first private key to decrypt and display the SMS verification code.

[0091] It is understood that the first private key can correspond to the first public key. For example, the first public key and the first private key can be the corresponding public key and private key in the first key pair generated by the second application. In some embodiments, the first key pair can also be described as the first key pair on the first terminal 00, which is not limited here. In other embodiments, the first terminal 00 may not display the SMS verification code after decrypting it based on the second application. For details, please refer to the following text. Figure 2b The descriptions shown and related information will not be repeated here.

[0092] It is understandable that the second application on the first terminal 00 uses the first private key to decrypt the SMS verification code. If the SMS verification code is encrypted using a different public key, such as in the following text... Figure 2b If the SMS verification code is encrypted with the second public key, the decryption result of the first terminal 00 can be a failure. For details, please refer to the relevant description below, which will not be repeated here.

[0093] a6. After the first terminal 00 decrypts and displays the SMS verification code based on the second application, the user can read the SMS verification code from the relevant display interface of the first terminal 00.

[0094] a7. The first application of the first terminal 00 can respond to the user's input operation on the relevant interface and obtain the SMS verification code.

[0095] a8. The first application on the first terminal 00 can request the server 20 to verify the obtained SMS verification code. After successful verification, the first application can confirm the execution of the response to the detected first user operation and successfully log in to the user's personal account.

[0096] Thus, based on the above Figure 2a The implementation process shown allows the first application on the first terminal 00 to securely respond to the aforementioned first user operation, thereby enabling secure control over the user's login to their personal account or the process of transferring funds and conducting transactions, and thus effectively protecting the user's property and personal information.

[0097] It is understandable that when a fraudster attempts to perform the first user operation on another terminal (such as the first terminal 00 mentioned above), the verification process triggered by the first user operation may include situations such as the first terminal 00 used by the target user being unable to decrypt the received SMS verification code, and the first terminal 00 being unable to display the received SMS verification code.

[0098] In comparison, Figure 2b According to an embodiment of this application, a schematic diagram illustrating the implementation principle of another security control method based on SMS verification codes is shown.

[0099] Compared to Figure 2a The process of the first application security response to the first user operation on the first terminal 00 is shown. Figure 2b The implementation process shown includes:

[0100] b1. The second terminal 10 detects a user action instructing the user to open the first application. In response to the detected user action, the second terminal 10 runs the first application and continues to execute b2 below, sending an authentication request carrying the second public key to the server 20.

[0101] It is understood that the above user operation may be related to the above first user operation. For example, the user operation and the above first user operation may be an operation that instructs the user to log in to the same user's personal account, or an operation that instructs the user to use the same user's account to perform operations such as transfers and transactions.

[0102] b2. The first application of the second terminal 10 sends a verification request carrying the second public key to the server 20. Accordingly, the server 20 receives the second public key. Alternatively, the first application of the second terminal 10 sends a verification request without carrying the public key to the server 20. Accordingly, the server 20 does not receive the public key and does not encrypt the SMS verification code in response to the verification request.

[0103] It is understood that the aforementioned second public key can correspond to the second private key in the second key pair on the second terminal 10. However, this second public key cannot correspond to the aforementioned... Figure 2a The first private key corresponds to the first key pair on the first terminal 00. Based on this, SMS verification codes encrypted using the second public key cannot be successfully decrypted by the first terminal 00. The specific process can be found in the relevant description below, and will not be elaborated here.

[0104] b3. In response to the verification request, server 20 generates an SMS verification code encrypted with the second public key, or generates an unencrypted SMS verification code.

[0105] b4. Server 20 requests to send an SMS verification code to the telecommunications operator's server. This SMS verification code can be an SMS verification code encrypted by Server 20 using the second public key, or it can be an unencrypted SMS verification code generated by Server 20.

[0106] Following b4 above, you can continue with b5.1 and b6.1 below.

[0107] b5.1 The telecommunications operator's server sends an encrypted SMS verification code to the first terminal 00. The first terminal 00 can be a terminal electronic device used by the target user in the telecom fraud. Correspondingly, the target user can be the user whose personal account or mobile phone number, etc., is triggered by user operation detected by the second terminal 10 in b1 above.

[0108] b6.1 The second application of the first terminal 00 failed to decrypt the SMS verification code using the first private key, and the SMS verification code was not displayed / a risk warning was displayed.

[0109] It is understood that the first terminal 00, as the terminal electronic device used by the target user, does not possess a private key corresponding to the aforementioned second public key, such as the second private key in the second key pair of the second terminal 10. In this case, if the second application of the first terminal 00 uses the first private key in the first key pair to decrypt the received encrypted SMS verification code, the decryption will fail.

[0110] In some embodiments, if the second application of the first terminal 00 fails to decrypt the encrypted SMS verification code, it can also display a risk warning corresponding to the SMS verification code. The specific warning method will be described in detail below with reference to relevant interface diagrams, and will not be limited thereto.

[0111] Alternatively, after b4 above, you can continue to execute b5.2 and b6.2 below.

[0112] b5.2 The telecommunications operator's server sends an unencrypted SMS verification code to the first terminal 00.

[0113] b6.2 The second application of the first terminal 00 does not display unencrypted SMS verification codes / displays risk warnings.

[0114] It is understood that, in order to protect the security of users' property and personal information, the first terminal 00, as a terminal electronic device used by the target user, may, based on the security control method provided in this application, not display unencrypted SMS verification codes. In some embodiments, the second application of the first terminal 00 may also display risk warnings corresponding to the aforementioned unencrypted SMS verification codes. Specific warning methods will be described in detail below with reference to relevant interface diagrams, and are not limited here.

[0115] Thus, if a fraudster wants to log into the target user's personal account through another terminal (such as the second terminal 10 mentioned above) and try to trick the target user into giving them an SMS verification code over the phone, then based on the above... Figure 2b The implemented security control method ensures that even if the target user falls into the scammer's language trap, they will not be able to disclose the SMS verification code to the scammer, thus helping to protect the user's property, personal information and other security.

[0116] In other embodiments, after the second application of the first terminal 00 successfully decrypts the SMS verification code using the first private key, the SMS verification code may not be displayed. As an example, Figure 2c According to an embodiment of this application, a schematic diagram illustrating the implementation principle of another security control method based on SMS verification codes is shown.

[0117] With the above Figure 2a The difference is that, after the second application of the first terminal 00 successfully decrypts the received encrypted SMS verification code using the first private key, it may not display the decrypted SMS verification code. Figure 2c The steps in a5.3 are shown below. Based on this, the method by which the first application of the first terminal 00 obtains the SMS verification code from the second application can also be the same as described above. Figure 2a The implementation process shown is different, namely Figure 2c The steps a6.1 and a7.1 are shown.

[0118] Specifically, such as Figure 2c As shown, the implementation process of the security control method that does not display the decrypted SMS verification code may include:

[0119] a1. The first terminal 00 detects the user's instruction to open the first application and runs the first application.

[0120] a2.1 The first application requests the first public key from the second application on the first terminal 00.

[0121] a2.2 The first application of the first terminal 00 sends a first verification request carrying the first public key to the server 20. Correspondingly, the server 20 receives the first public key.

[0122] a3. Server 20 can respond to the first verification request by generating an SMS verification code encrypted with the first public key.

[0123] a4. Server 20 requests the telecommunications operator's server to send an encrypted SMS verification code.

[0124] a5.1 The telecommunications operator's server sends an encrypted SMS verification code to the first terminal 00.

[0125] exist Figure 2c In the implementation process shown, after step a5.1 above, step a5.3 below can be executed.

[0126] a5.3 The second application of the first terminal 00 uses the first private key to decrypt the SMS verification code, but does not display the SMS verification code.

[0127] If the second application does not display the decrypted SMS verification code in step a5.3 above, the other security control method provided in this application can continue to implement steps a6.1 and a7.1 below.

[0128] a6.1 The first application of the first terminal 00 detects a user operation of clicking the verification control for verification.

[0129] It is understood that the interface displayed by the first application on the first terminal 00 may include a verification control, which the user can click to instruct a request to the second application to obtain a decrypted SMS verification code. After the first application detects the user's action of clicking the verification control to verify, it can continue to execute the following steps a7.1.

[0130] a7.1 The first application of the first terminal 00 obtains the SMS verification code from the second application.

[0131] It is understood that this acquisition process includes, for example, the first application sending the aforementioned request to the second application and receiving the SMS verification code returned by the second application. After obtaining the SMS verification code, the first application can automatically fill in the SMS verification code in the verification code input box on the relevant verification interface.

[0132] a8. The first application of the first terminal 00 can request the server 20 to verify the obtained SMS verification code.

[0133] Thus, based on the above Figure 2c The implementation process shown allows the first terminal 00 to use the obtained SMS verification code for the first application to verify login without displaying it, which helps improve the security of users' personal information.

[0134] Figure 2d This application provides a schematic diagram illustrating the implementation principle of a security control method based on bank card information. The following example illustrates the verification information, which is a signature generated based on the information carried by the bank card (hereinafter referred to as bank card information):

[0135] d0, the third application of the first terminal 00 responds to the user's instruction to bind a bank card and applies to the security agency to bind the bank card.

[0136] It is understood that the first terminal 00 can be equipped with an application capable of managing card information, i.e., the aforementioned third application, such as a wallet app (an example of a third application) or other payment applications. Correspondingly, the aforementioned security institution can be a banking institution with bank card issuance and management functions.

[0137] d1. Security agencies verify information during the bank card binding process.

[0138] For example, a banking institution (an example of a security institution) may, in response to a request from the aforementioned wallet app (an example of a third application) to bind a bank card, perform information verification during the bank card binding process. This information verification process may include, but is not limited to, verifying information such as the user's registered phone number or ID number, as well as verifying the user's biometric information such as facial recognition or fingerprints; no restrictions are imposed here.

[0139] Once the bank verifies the information during the bank card binding process, the wallet app can successfully bind the corresponding bank card.

[0140] d2. The first application of the first terminal 00 can request signature information from the third application when logging into its personal account for the first time. Correspondingly, the third application, such as a wallet app, can respond to the request of the first application, generate signature information based on the bound bank card information, and send it to the first application.

[0141] The methods for generating signature information may include, but are not limited to: hashing the bank card information and encrypting it with a key to create a digital signature as the signature information. For ease of description, Figure 2d The d2 shown involves the signature information of the request, which can be referred to as the first signature information.

[0142] d3. The first application of the first terminal 00 records the signature information to the server 20.

[0143] For example, after the first application of the first terminal 00 obtains the first signature information, it can request the server 20 to record the signature information.

[0144] d4. The first application of the first terminal 00 detects a user operation that instructs the user to open the first application.

[0145] It is understandable that after the initial login to the personal account, when the first application on the first terminal 00 detects another user action instructing it to open the application, it can run the application again. At this time, the user action could be a secondary login action requiring verification, or a payment or transfer action involving user assets, etc., without restriction.

[0146] d5. The first application of the first terminal 00 requests signature information from the third application.

[0147] For example, the first application can request signature information from the wallet app again. In this case, the signature information requested by the first application from the third application can be the first signature information sent by the third application to the first application in step d2 above, or it can be the signature information generated again based on the bank card information successfully bound in step d1 above.

[0148] d6. The first application of the first terminal 00 requests the server 20 to verify the signature information.

[0149] For example, the signature information involved in the verification in step d6 above can be recorded as the second signature information, which is also the signature information requested by the first application from the third application in step d5 above. Server 20 can perform a verification process on the second signature information based on the first signature information recorded in step d3 above. This verification process may include, for example, determining whether the first signature information and the second signature information are the same or confirming whether they correspond, etc., without limitation.

[0150] It is understood that the aforementioned bank card information may include, but is not limited to, sensitive data such as card number, expiration date, and cardholder's name, and no restrictions are imposed here.

[0151] Figure 2eAccording to an embodiment of this application, a schematic diagram illustrating the implementation principle of another security control method based on ID card information is shown.

[0152] With the above Figure 2c The difference is that the signature information sent by the third application of the first terminal 00 in response to the request of the first application is signature information generated based on the information carried on the ID card (hereinafter referred to as ID card information), which involves... Figure 2e The steps e2 and e5 are shown. Based on this, the process by which the third application installed on the first terminal 00 obtains ID card information is the same as described above. Figure 2d The process by which third-party applications obtain bank card information differs from that of traditional applications, involving... Figure 2e The steps e0 and e1 are shown.

[0153] Specifically, such as Figure 2e As shown, the implementation process of a security control method based on ID card information may include:

[0154] e0, the third application of the first terminal 00 responds to the user's instruction to perform real-name verification and applies to the security agency for real-name verification.

[0155] For example, the aforementioned third application can continue to be a wallet app. The aforementioned security agency can be an organization capable of managing users' identity information.

[0156] e1. Security agencies verify identity information during the real-name registration process.

[0157] e2. The first application of the first terminal 00 can request signature information from the third application when logging into the personal account for the first time. Correspondingly, the third application, such as a wallet app, can respond to the request of the first application, generate signature information based on the bound ID card information, and send it to the first application.

[0158] The methods for generating signature information may include, but are not limited to: hashing the aforementioned ID card information and encrypting it with a key to create a digital signature as the signature information. For ease of description, Figure 2d The d2 shown involves the signature information of the request, which can be referred to as the first signature information.

[0159] e3. The first application of the first terminal 00 records the signature information to the server 20. The execution process of this step can be referred to the relevant description of step d3 above, and will not be repeated here.

[0160] e4. The first application of the first terminal 00 detects a user operation instructing the user to open the first application. The execution process of this step can be referred to the relevant description of step d4 above, and will not be repeated here.

[0161] e5. The first application of the first terminal 00 requests signature information from the third application.

[0162] For example, the first application can request signature information from the wallet app again. In this case, the signature information requested by the first application from the third application can be the first signature information sent by the third application to the first application in step d2 above, or it can be the signature information regenerated based on the ID card information successfully verified after the real-name process in step d1 above.

[0163] e6. The first application of the first terminal 00 requests the server 20 to verify the signature information. The execution process of this step can be referred to the relevant description of step d6 above, and will not be repeated here.

[0164] Thus, based on the above Figure 2d or Figure 2e The illustrated implementation process prevents fraudsters from obtaining signature information from wallet apps or other applications on the target user's terminal (e.g., the first terminal) through other terminals (e.g., the second terminal mentioned above). Consequently, fraudsters are also unable to log into the target user's account or use it to engage in risky activities such as transferring user assets or disclosing user personal information. Therefore, the security control method provided in this application can effectively protect the security of users' assets and personal information.

[0165] Based on the above Figures 2a to 2e The implementation principle is illustrated below. The specific implementation method of the security control method provided in this application will be described in detail below with reference to the implementation process diagram.

[0166] It should also be stated that the steps in the methods and processes in this application are numbered for ease of reference, not to limit the order of steps. If there is an order between the steps, the textual description shall prevail.

[0167] Let's combine the following... Figure 3 The diagram shown illustrates the interactive implementation process for the above-mentioned... Figure 2a The implementation principle shown will be described in detail along with the specific implementation process of the corresponding security control method.

[0168] Figure 3 An interactive implementation flowchart of a security control method is shown in an embodiment of this application.

[0169] Understandable. Figure 3The illustrated process may involve interaction between a first terminal 00 and a server 20. The first terminal 00 may have the aforementioned first application and second application installed. The first application is used by users or fraudsters to log in or to process or operate on matters involving property and personal information. In this embodiment, the second application may be an SMS application; in other embodiments, it may be other applications with corresponding functions, and no limitation is made here. The server 20 may deploy the server-side component of the first application.

[0170] As mentioned above, the first terminal 00 can be an electronic device such as a mobile phone.

[0171] Specifically, such as Figure 3 As shown, the process may include:

[0172] S301: The first application of the first terminal 00 detected the first user operation.

[0173] For example, the first user operation described above may include the above Figure 2a The example instructions to open the first application may also include user instructions to log in to a personal account or to perform actions involving property security, such as payments or transfers, without limitation.

[0174] As an example, refer to Figure 4a The login interface diagram shown above illustrates that the first user operation can be the user clicking the "Get Verification Code" control 411 on the login interface 410. This login interface 410 can be the interface of the first application. The first application of the first terminal 00 detects the first user operation and can continue to execute S302 and so on.

[0175] It is understood that in some embodiments, the first application detects the first user's operation, as described above. Figure 2a The execution process of step a1 shown, the corresponding "instruction to open the first application" can also include instructing the logged-in user's personal account on the first interface of the opened first application, etc., without limitation.

[0176] S302: The first application of the first terminal 00 sends a key acquisition request to the second application.

[0177] For example, when the first application installed on the first terminal 00 detects the first user operation, it can send a key acquisition request to the second application that can provide security authentication services. The key acquisition request can be used to request the second application to generate a corresponding key pair for the first application, and execute the following S303 to send the public key in the key pair to the first application.

[0178] S303: The second application of the first terminal 00 sends the first public key from the corresponding key pair to the first application.

[0179] For example, the second application of the first terminal 00 can respond to the key acquisition request sent by the first application, generate a corresponding key pair for the first application, and send the first public key in the corresponding key pair to the first application. For ease of distinction, the key pair generated for the first application can be referred to as the first key pair.

[0180] In other embodiments, the second application of the first terminal 00 may also respond to a key acquisition request from another application and generate a key pair for the corresponding application to protect the verification information, without limitation.

[0181] It is understood that, in some embodiments, the execution process of S302 to S303 described above may correspond to the above... Figure 2a The step a2.1 shown is one specific implementation method. In other embodiments, the process may also adopt other specific implementation methods, which are not limited here.

[0182] S304: The first application of the first terminal 00 sends a first authentication request carrying the first public key to the server 20. Accordingly, the server 20 receives the first authentication request.

[0183] For example, after obtaining the first public key sent by the second application, the first application of the first terminal 00 can respond to the aforementioned first user operation by generating a first verification request carrying the first public key and sending it to the server 20. That is, the first application can send a first verification request carrying the first public key to the server 20.

[0184] S305: Server 20 stores the first public key.

[0185] For example, after receiving the first verification request carrying the first public key, the server 20 can save the identification information of the first application corresponding to the first public key, or save it in the storage space corresponding to the first application, for use in encrypting verification information such as SMS verification codes sent to the first application. The identification information of the first application may include, for example, a user identifier (UID).

[0186] It is understood that, in some embodiments, the execution process of S304 to S305 described above may correspond to the above... Figure 2a The step a2.2 shown is one specific implementation method. In other embodiments, the process may also adopt other specific implementation methods, which are not limited here.

[0187] S306: Server 20 responds to the first verification request and generates an SMS verification code.

[0188] For example, in response to a first verification request sent by a first application, server 20 can generate a corresponding SMS verification code. This SMS verification code may include letters, numbers, special symbols, etc., and is not limited thereto.

[0189] S307: Server 20 uses the first public key to encrypt the SMS verification code and obtains the first verification information.

[0190] For example, the server 20 can use the first public key stored above to encrypt the generated SMS verification code. The encrypted SMS verification code is the first verification information, which is returned to the first application as a response to the first verification request.

[0191] It is understood that, in some embodiments, the execution process of S306 to S307 described above may correspond to the above... Figure 2a The above is one specific implementation of step a3. In other embodiments, the process may also be implemented in other specific ways, which are not limited here.

[0192] S308: Server 20 sends first verification information to the second application of the first terminal 00. Correspondingly, the second application of the first terminal 00 receives the first verification information.

[0193] For example, server 20 can send the encrypted SMS verification code, i.e., the first verification information, to the second application of the first terminal 00 through the server of the telecommunications operator. As mentioned above, the second application may be, for example, an SMS application.

[0194] It is understood that, in some embodiments, the execution process of S308 described above may correspond to the above... Figure 2a The steps a4 to a5.1 shown are one specific implementation method. In other embodiments, the process may also be implemented in other specific ways, which are not limited here.

[0195] S309: The second application of the first terminal 00 uses the corresponding first private key to decrypt the first verification information.

[0196] For example, after receiving the first verification information, the second application of the first terminal 00 can decrypt it using the first private key corresponding to the first public key. Since the first verification information is an SMS verification code encrypted with the first public key, the second application obtains the SMS verification code generated in response to the first verification request by decrypting it using the first private key.

[0197] S310: The second application on the first terminal 00 has successfully decrypted, confirming the user's identity and displaying the SMS verification code.

[0198] For example, when the second application of the first terminal 00 decrypts and obtains the SMS verification code, it indicates that the decryption was successful. At this time, the first terminal 00 can determine that the user identity corresponding to the detected first user operation is legitimate, and the second application of the first terminal 00 can display the SMS verification code obtained through decryption.

[0199] It is understood that, in some embodiments, the execution process of S309 to S310 described above may correspond to the above... Figure 2a This is one specific implementation of a6 shown. In other embodiments, the process may also be implemented in other ways, which are not limited here.

[0200] In other embodiments, the second application may not display the SMS verification code after successfully decrypting it; that is, the implementation flow of the security control method provided in this application embodiment may not include the above-described S310. In this case, the second application may respond to the first application's request to obtain the SMS verification code by executing the following S311 to send the decrypted SMS verification code to the first application. This execution process can correspond to the above-described... Figure 2c The diagram illustrates one specific implementation of steps a6.1 and a7.1. In other embodiments, this process may also employ other specific implementations, which are not limited here.

[0201] S311: The second application of the first terminal 00 sends the decrypted SMS verification code to the first application.

[0202] For example, after the second application of the first terminal 00 decrypts and obtains the SMS verification code, it can send the SMS verification code to the first application in response to the first application's request to obtain the SMS verification code.

[0203] In other embodiments, the first application's request to obtain the SMS verification code may be in response to the above... Figure 2c The operation generated by clicking the verification control detected by the first terminal 00 corresponding to a6.1 is not limited here.

[0204] S312: The first application of the first terminal 00 obtains the SMS verification code.

[0205] For example, the first application of the first terminal 00 can obtain the SMS verification code sent by the second application, and then can continue to execute S313 based on the obtained SMS verification code.

[0206] As an example, after successfully decrypting the SMS verification code, the second application on the first terminal 00 does not display the SMS verification code but instead sends it to the corresponding interface displayed by the first application. This can be referenced. Figure 4bThe login interface 420 is shown. In this login interface 420, the verification code input box 421 can automatically fill in the SMS verification code obtained by the first application, and display it using special symbols such as "*" to replace the various symbols in the SMS verification code. (See reference...) Figure 4b The symbol “******” is shown. In some embodiments, Figure 4b The login interface 420 shown can also display operation prompts below the verification code input box 421, such as "For security, a verification code has been automatically entered for you. Please click to log in." In some other embodiments, the login interface of the first application may not display the above operation prompts; the corresponding login interface can also refer to [the relevant documentation]. Figure 4c The login interface 430 shown or other forms of interface are not limited here.

[0207] In other embodiments, after the second application of the first terminal 00 successfully decrypts the first verification information in S309 to S310, it can provide the decrypted SMS verification code to the input method application for display on the relevant input method interface. This input method interface may include the input method soft keyboard that pops up when the verification code input box in the login interface 410 or 420 is triggered. At this time, the user can click on the displayed SMS verification code on the relevant input method interface to confirm that the SMS verification code has been entered into the corresponding verification code input box.

[0208] In some embodiments, the implementation process of the security control method provided in this application may not include the above-described S312, and no restrictions are imposed here.

[0209] It is understood that, in some embodiments, the execution process of S311 to S312 described above may correspond to the above... Figure 2a This is one specific implementation of step a7 shown. In other embodiments, this process may also be implemented in other ways, which are not limited here.

[0210] In other embodiments, the execution process of S311 to S312 described above may correspond to the above. Figure 2c This is a specific implementation of a7.1 shown.

[0211] S313: The first application of the first terminal 00 sends a verification request to the server 20 for the obtained SMS verification code.

[0212] For example, the first application of the first terminal 00 can generate a verification request to be sent to the server 20 based on the obtained SMS verification code, requesting the server 20 to verify the SMS verification code. This verification process can determine the validity of the SMS verification code issued by the server 20 to the first terminal 00, which helps to ensure the security of the verification process based on the SMS verification code.

[0213] It is understood that the above verification request can also be described as a verification request in some embodiments. The verification request can be a request initiated after the first verification request, and the content to be verified by the request can include, but is not limited to: verifying whether the first verification information obtained by the first verification request matches the SMS verification code generated on the server 20, etc., without limitation.

[0214] S314: Server 20 returns a verification result to the first application of the first terminal 00.

[0215] For example, if the server 20 determines that the SMS verification code requested by the first application has passed verification, it returns the verification result to the first application of the first terminal 00. This verification result is the result of matching between the SMS verification code requested by the first application and the SMS verification code generated on the server 20 corresponding to the first verification request, serving as an example of a matching result. The verification result can be sent to the first terminal 00 in the form of a notification, etc., without limitation.

[0216] It is understood that, in some embodiments, the execution process of S313 to S314 described above may correspond to the above... Figure 2a The above is one specific implementation of a8. In other embodiments, the process may also be implemented in other specific ways, which are not limited here.

[0217] S315: The first application of the first terminal 00 determines that the user identity corresponding to the first user operation is legitimate, executes the first user operation, and displays the second interface.

[0218] For example, if the first user operation is a login operation, the second interface displayed by the first terminal 00 can be the interface after the user successfully logs into the user's personal account in the first application. In other embodiments, if the first user operation is a payment or transfer operation, the second interface displayed by the first terminal 00 can be the interface after successful payment or transfer, which is not limited or elaborated here. The first application of the first terminal 00 can determine that the first user operation corresponding to the first verification information is a legitimate operation based on the verification result returned by the server 20 in S314, and that the user identity corresponding to the first user operation is legitimate. At this time, the first user operation can be executed safely and the second interface can be displayed.

[0219] Based on the execution process of S301 to S315 described above, the security control method provided by this application can ensure that the electronic device requesting the SMS verification code and the electronic device receiving the SMS verification code are the same device, such as the first terminal 00 mentioned above. This can improve the security of users using terminal electronic devices, protect users' property from loss, and prevent the leakage of personal information.

[0220] It is understandable that, corresponding to another decryption result of S309 above, if the second application of the first terminal 00 fails to decrypt the first verification information—for example, the first verification information decrypted by the second application might be the verification information requested by a fraudster through a verification request triggered by related operations performed by another terminal (e.g., the second terminal 10 mentioned above); or, if the first verification information received by the second application of the first terminal 00 is unencrypted information—then the second application of the first terminal 00 can display a risk warning message corresponding to the first verification information. At this time, the first terminal 00, the second terminal 10, and the server 20 can execute the above... Figure 2b The implementation process shown controls the second application of the first terminal 00 to prevent it from displaying SMS verification codes that failed to decrypt or unencrypted. Furthermore, the second application of the first terminal 00 can also display risk warnings related to the aforementioned failed or unencrypted SMS verification codes, i.e., the aforementioned risk warning information. For a detailed implementation process, please refer to the above. Figure 2b The relevant descriptions will not be elaborated here.

[0221] As an example, refer to Figure 4d The SMS verification code display interface 440 displayed on the first terminal 00 may include an SMS verification code information box 441 and a risk warning information box 442. The SMS verification code information box 441 may display special symbols such as "*" for SMS verification codes that failed to decrypt or were not encrypted. Figure 4d The message displayed is: "[First Application] Your SMS verification code is ******. You are logging into the target application account. If this was not your operation, please ignore it!" The risk warning information box 442 can display corresponding risk warning content, such as "This verification information has a high security risk, please be careful!" This prevents users from providing unencrypted SMS verification codes in plaintext to fraudsters, thereby avoiding financial losses and the leakage of personal information.

[0222] In other embodiments, corresponding to another successful decryption step in S310 described above, the second application of the first terminal 00 may also not display the successfully decrypted SMS verification code. In this case, the second application can respond to a user operation that clicks the verification control on the relevant interface of the first application to input the successfully decrypted SMS verification code into the first application, such as as described above. Figure 4b or Figure 4c The interface shown automatically fills in the SMS verification code. Correspondingly, the first application can obtain the successfully decrypted SMS verification code from the second application. At this time, the first terminal 00 and the server 20 can perform the above... Figure 2c The implementation process shown involves controlling the second application on the first terminal 00 to not display the successfully decrypted SMS verification code, and controlling the second application to respond to user operations such as clicking the verification control to perform verification, inputting the successfully decrypted SMS verification code into the first application. For a detailed implementation process, please refer to the above. Figure 2c The relevant descriptions will not be elaborated here.

[0223] Next, let's combine... Figure 5 The diagram shown illustrates the interactive implementation process for the above-mentioned... Figure 2d or Figure 2e The implementation principle shown will be described in detail along with the specific implementation process of the corresponding security control method.

[0224] Figure 5 An embodiment of this application illustrates an interactive implementation flow diagram of another security control method.

[0225] Understandable. Figure 5 The process shown may involve interaction between a first terminal 00 and a server 20. The first terminal 00 may have the aforementioned first application and third application installed. In this embodiment, the third application may be an application such as a wallet app, and there are no restrictions on its use. As mentioned above, the first terminal 00 may be an electronic device such as a mobile phone.

[0226] Specifically, such as Figure 5 As shown, the process may include:

[0227] S501: The first application of the first terminal 00 detects the first login operation and generates a signature information acquisition request.

[0228] For example, after the first application on the first terminal 00 is installed and running, when it detects a login operation instructing the user to log in to a personal account for the first time, it can request signature information from the third application. In this case, the first login operation detected by the first application can include the aforementioned first detected login operation. In other embodiments, the first application running on the first terminal 00 can also log out of the user's personal account after logging in, in response to the user's logout operation. Subsequently, when the first application detects a second or third login operation instructing the user to log in to a personal account, it can also request signature information from the third application. In this case, the first login operation detected by the first application can include the second or third login operation detected after logging out of the user's personal account. The process of the first application requesting signature information from the third application can include the first application generating the aforementioned signature information acquisition request in response to the detected first login operation, and executing the process described in S502, which involves sending the signature information acquisition request to the third application.

[0229] In some embodiments, before executing the above-described S501 based on the first application, the first terminal 00 may, based on the third application, respond to the user's instruction to bind a bank card or respond to the user's instruction to real-name registration, request verification from the relevant security authority and obtain card information authorized by the security authority to bind, such as bank card information or ID card information.

[0230] The aforementioned user-instructed bank card binding operation or user-instructed real-name authentication operation can be uniformly described as a second user operation involving binding card / certificate information. Based on this, the aforementioned second user operation may include related operations involved in the bank card binding process. This operation can trigger secure verification of user identity and bank card information, etc. This verification process is typically highly secure and allows a third application to bind bank card information capable of verifying user identity. In some embodiments, the aforementioned second user operation may also include related operations involved in the real-name authentication process. This operation can trigger secure verification of user identity information, such as an ID card, etc. This verification process is typically highly secure and allows a third application to bind ID card information capable of verifying user identity. The aforementioned bank card information and ID card information, etc., can be uniformly described as card / certificate information in this application embodiment. In other embodiments, the aforementioned second user operation may also include other operations that enable a third application to obtain information capable of verifying user identity, which are not limited here.

[0231] When the third application of the first terminal 00 detects the aforementioned second user operation, it can request a security agency to bind card information and obtain the card information authorized by the security agency for binding. For example, in response to the detected second user operation, the third application of the first terminal 00 can request a security verification from the security agency managing the corresponding card information. For example, when the card information is bank card information, the aforementioned security agency can be a banking institution. In this case, the first terminal 00 can request the banking institution to verify the bank card information to be bound. This verification process may include, but is not limited to, verifying the user's pre-registered phone number, ID card number, and other information, as well as verifying the user's facial or fingerprint biometric information, etc., without limitation.

[0232] After verifying the third application's request to bind card information and confirming the user's legitimate identity, the security agency may authorize the third application on the first terminal 00 to obtain the corresponding card information, such as the aforementioned bank card information or ID card information. Correspondingly, the third application on the first terminal 00 can save the obtained card information. The saved card information can be used to generate corresponding signature information to respond to the first application's verification requests.

[0233] S502: The first application of the first terminal 00 sends a signature information acquisition request to the third application.

[0234] For example, after generating the above-mentioned signature information acquisition request, the first application of the first terminal 00 can execute this step S502 to send the signature information acquisition request to the third application.

[0235] S503: The third application of the first terminal 00 generates the first signature information based on the corresponding card information.

[0236] For example, the third application of the first terminal 00 can respond to the signature information acquisition request sent by the first application and generate corresponding signature information based on the aforementioned stored card information (such as bank card information or ID card information). For ease of description, the signature information generated by the third application at this time can be referred to as the first signature information.

[0237] Taking the generation of first signature information based on bank card information as an example, the third application can use a hash function to perform hash calculation on the bound bank card information, and encrypt the calculated hash value into a digital signature using a key, which serves as the first signature information. In other embodiments, the third application can generate the first signature information based on the bound card information in other ways, which are not limited here.

[0238] S504: The third application of the first terminal 00 returns the first signature information to the first application.

[0239] For example, after generating the first signature information, the third application of the first terminal 00 can return the first signature information to the first application in response to the signature information acquisition request sent by the first application.

[0240] It is understood that, in some embodiments, the execution process of S502 to S504 described above may correspond to the above... Figure 2d Step d2 shown or Figure 2e The above is one specific implementation of step e2. In other embodiments, the process may also be implemented in other specific ways, which are not limited here.

[0241] S505: The first application of the first terminal 00 sends the first signature information to the server 20.

[0242] For example, after obtaining the first signature information returned by the third application, the first application of the first terminal 00 can send the first signature information to the server 20 for storage.

[0243] It is understood that the server 20, which hosts the server-side of the aforementioned first application, can also deploy a database with data management functions to store relevant data of the first application installed on different terminals, user personal account data logged in on the first application on different terminals, and the aforementioned first signature information, etc. The functions and deployment methods of the corresponding database can refer to existing related technologies, and will not be elaborated here.

[0244] S506: Server 20 stores the first signature information.

[0245] For example, after receiving the first signature information sent by the first application, the server 20 can save the first signature information. This first signature information can be saved to the storage space corresponding to the first application on the first terminal 00. Referring to the foregoing example, this storage space can be provided by a database deployed on the server 20, and there are no restrictions on its use.

[0246] It is understood that, in some embodiments, the execution process of S505 to S506 described above may correspond to the above... Figure 2d As shown in d3 or Figure 2e The above is one specific implementation of e3. In other embodiments, the process may also be implemented in other specific ways, which are not limited here.

[0247] S507: The first application of the first terminal 00 generates a first verification request in response to the detected first user operation.

[0248] For example, the first user operation described above may include the above Figure 2dThe example of instructing the user to open the first application may further include user instructions to log in to a personal account or perform actions involving property security, such as payments or transfers; this is not limited to these specific actions. The aforementioned first user action can trigger a verification process. In response to the detected first user action, the first application of the first terminal 00 can generate a corresponding verification request, uniformly described in this embodiment as a first verification request. This first verification request can be used to request signature information from the aforementioned third application again.

[0249] It is understood that, in some embodiments, the execution process of S507 described above may correspond to the above... Figure 2d As shown in d4 or Figure 2e The above is one specific implementation of e4. In other embodiments, the process may also be implemented in other specific ways, which are not limited here.

[0250] S508: The first application of the first terminal 00 sends a first verification request to the third application.

[0251] For example, after generating the first verification request, the first application of the first terminal 00 can send the first verification request to the third application.

[0252] S509: The third application of the first terminal 00 returns the second signature information to the first application.

[0253] For example, the third application of the first terminal 00 can respond to the received first verification request by returning corresponding signature information to the first application. The signature information returned by the third application to the first application in step S504 can be referred to as the second signature information.

[0254] In this embodiment, the second signature information may include the first signature information mentioned above; that is, the second signature information and the first signature information may be the same signature information. The third application may use the generated first signature information to respond to the verification request initiated by the first application. In other embodiments, the second signature information may also be signature information regenerated by the third application based on the bound card information, wherein the card information carried by the signature information may be the same as the card information carried by the first signature information, and no limitation is imposed here.

[0255] It is understood that, in some embodiments, the execution process of S508 to S509 described above may correspond to the above... Figure 2d As shown in d5 or Figure 2e The above is one specific implementation of e5. In other embodiments, the process may also be implemented in other specific ways, which are not limited here.

[0256] S510: The first application of the first terminal 00 sends a second verification request related to the second signature information to the server 20.

[0257] For example, after the first application of the first terminal 00 obtains the returned second signature information from the third application, it can send a verification request to the server 20, namely the aforementioned second verification request, to request the server 20 to verify the second signature information.

[0258] S511: Server 20 determines whether it has signature information that matches the second signature information.

[0259] For example, the server 20 may verify the second signature information by determining whether information matching the second signature information exists in the corresponding storage space. For instance, the server 20 may determine whether signature information identical to the second signature information exists in the corresponding storage space, or whether signature information identical to the card information carried by the second signature information exists in the corresponding storage space, etc., without limitation.

[0260] S512: Server 20 returns the result of matching the second signature information with the saved first signature information to the first application of the first terminal 00.

[0261] For example, if server 20 determines that there is information in the corresponding storage space that matches the second signature information, such as the first signature information saved in S506, it can return the matching result to the first terminal 00, that is, the result of matching between the second signature information and the saved first signature information, as another example of the matching result. It is understood that the matching result includes the first signature information and the second signature information being the same, or the two correspondingly carrying the same card information, etc., without limitation.

[0262] It is understood that, in some embodiments, the execution process of S510 to S512 described above may correspond to the above... Figure 2d As shown in d6 or Figure 2e The above is one specific implementation of e6. In other embodiments, the process may also be implemented in other specific ways, which are not limited here.

[0263] S513: The first terminal 00 determines that the user identity corresponding to the first user operation is legitimate, executes the first user operation, and displays the second interface.

[0264] For example, if the first user operation is a login operation, the second interface displayed by the first terminal 00 can be the interface after the user's personal account has been successfully logged into the first application. In other embodiments, if the first user operation is a payment or transfer operation, the second interface displayed by the first terminal 00 can be the interface after successful payment or transfer, which is not limited or elaborated here. The first application of the first terminal 00 can determine that the first user operation corresponding to the first verification information is a legitimate operation based on the matching result between the second signature information returned by the server 20 in S512 and the saved first signature information. The user identity corresponding to the first user operation is legitimate, and at this time, the first user operation can be executed securely and the second interface can be displayed.

[0265] Based on the execution process described in S501 to S513, the security control method provided in this application can utilize digital assets certified by security agencies, such as bank card information and ID card information, to provide digital signatures. This enables the verification of the legitimacy of user identity for user behaviors on certain apps that require the protection of user personal information security. These user behaviors include, but are not limited to, logging into personal accounts or making payments and transfers involving user property security. Therefore, this method is inherently beneficial in protecting the property and personal information security of target users.

[0266] The structure of the equipment and system for implementing the safety control method provided in this application will be described in detail below with reference to the relevant accompanying drawings.

[0267] Figure 6a A schematic diagram of the software structure of an electronic device is shown according to an embodiment of this application. In this embodiment, the electronic device can be described using the aforementioned first terminal 00 as an example.

[0268] like Figure 6aAs shown, the first terminal 00 can have the aforementioned first application and second application installed, or the aforementioned first application and third application installed. The second application can provide the first application with SMS verification code-based verification services and a key pair (including a public key and a private key) to protect the security of verification information such as the SMS verification code. Based on this key pair, the first application can first verify the legitimacy of the user's identity through the second application and the server of the first application, and then execute the user-instructed operations related to the security of the user's property and personal information. The third application can provide the first application with digital signatures, such as the aforementioned first signature information and second signature information. As mentioned earlier, the signature information provided by the third application can be generated based on bound or acquired card information, and the corresponding card information is card information bound after being certified and authorized by a corresponding security institution, such as bank card information, ID card information, etc., which can be used to verify the legitimacy of the user's identity. Based on the aforementioned signature information, the first application can first verify the legitimacy of the user's identity through the third application and the server of the first application, and then execute the user-instructed operations related to the security of the user's property and personal information.

[0269] Continue to refer to Figure 6a The first application can be used to receive and respond to user operations, while the second or third application can be used to receive and respond to verification requests from the user. Furthermore, on the first terminal 00, the second or third application can be used to receive and respond to verification requests from the first application and send the corresponding verification result, i.e., the aforementioned matching result, to the first application. The verification result generated by the second or third application in response to the aforementioned verification request from the user can also be sent to the first application. In this case, the verification result may include the aforementioned SMS verification code or signature information, etc., without limitation.

[0270] Figure 6b An embodiment of this application illustrates a schematic diagram of the software structure of another electronic device.

[0271] like Figure 6b As shown, the first terminal 00 can have the aforementioned first application, second application, and third application installed. The process by which the second application provides SMS verification code-based verification services to the first application, and the process by which the third application provides signature information (or digital signature)-based verification services to the first application, can be independent of each other. For example, while the second application is providing SMS verification code-based verification services to the first application, the third application can also respond to a request from the first application and provide signature information-based verification services. Alternatively, while the third application is providing signature information-based verification services to the first application, the second application can also respond to a request from the first application and provide SMS verification code-based verification services.

[0272] It is understood that the triggering time for the second application to provide the verification service based on SMS verification code to the first application may be the same as or different from the triggering time for the third application to provide the verification service based on signature information to the first application; no restrictions are imposed here.

[0273] Continue to refer to Figure 6b The first application can be used to receive and respond to user operations, and the second and / or third application can be used to receive and respond to verification requests from the user. Furthermore, on the first terminal 00, the second application can be used to receive and respond to verification requests from the first application and send the corresponding verification result, i.e., the matching result, back to the first application. The third application can also be used to receive and respond to verification requests from the first application and send the corresponding verification result, i.e., the matching result, back to the first application. No restrictions are imposed here.

[0274] Figure 7 A schematic diagram of the system structure of a safety control system is shown according to an embodiment of this application.

[0275] like Figure 7 As shown, the security control system provided in this application may include a first terminal 00 and a server 20. The first terminal 00 may have the aforementioned first application and second application installed, or the aforementioned first application and third application installed, or the aforementioned first application, second application, and third application installed, etc. The server 20 may have a server-side application for the first application deployed on it.

[0276] In some embodiments of this application, the server 20 may request the SMS service of a telecommunications operator to send an SMS verification code to the first terminal 00. A second application installed on the first terminal 00 may have the ability to read and decrypt the SMS verification code; this ability may be provided by the SMS module of the second application in some embodiments.

[0277] In some embodiments of this application, the third application may include a card management module for requesting card information verification services from a security authority. As mentioned above, the third application may, in response to a user's instruction to bind bank cards or other card information, request verification of the relevant user identity from a security authority such as a bank. The third application may also, in response to a user's real-name registration, request verification of the relevant user identity from a security authority capable of managing the user's ID card information. The specific verification process can be referred to the above. Figures 2a to 2e ,as well as Figure 3 , Figure 5 The descriptions shown and related information will not be repeated here.

[0278] Figure 8 A schematic diagram of the hardware structure of an electronic device is shown according to an embodiment of this application.

[0279] In this embodiment of the application, the electronic device may be the first terminal 00 or the second terminal 10, such as a mobile phone or other terminal electronic device.

[0280] like Figure 8 As shown, the electronic device 100 may include a processor 110, an external memory interface 120, an internal memory 121, a universal serial bus (USB) interface 130, a charging management module 140, a power management module 141, a battery 142, an antenna 1, an antenna 2, a mobile communication module 150, a wireless communication module 160, an audio module 170, a speaker 170A, a receiver 170B, a microphone 170C, a headphone jack 170D, a sensor module 180, buttons 190, a motor 191, an indicator 192, a camera 193, a display screen 194, and a subscriber identity module (SIM) card interface 195, etc. The sensor module 180 may include a pressure sensor 180A, a gyroscope sensor 180B, a barometric pressure sensor 180C, a magnetic sensor 180D, an accelerometer sensor 180E, a distance sensor 180F, a proximity sensor 180G, a fingerprint sensor 180H, a temperature sensor 180J, a touch sensor 180K, an ambient light sensor 180L, a bone conduction sensor 180M, etc.

[0281] It is understood that the structures illustrated in the embodiments of this application do not constitute a specific limitation on the electronic device 100. In other embodiments of this application, the electronic device 100 may include more or fewer components than illustrated, or combine some components, or split some components, or have different component arrangements. The illustrated components may be implemented in hardware, software, or a combination of software and hardware.

[0282] Processor 110 may include one or more processing units, such as application processors (APs), modem processors, graphics processing units (GPUs), image signal processors (ISPs), controllers, video codecs, digital signal processors (DSPs), baseband processors, and / or neural network processing units (NPUs). These different processing units may be independent devices or integrated into one or more processors.

[0283] The controller can generate operation control signals based on the instruction opcode and timing signals to complete the control of instruction fetching and execution.

[0284] In this embodiment, the processor 110 can generate operation control signals through the controller to complete the above-mentioned... Figures 2a to 2e , Figure 3 , Figure 5 The first terminal 00 is involved in reading and executing the instructions corresponding to each step of the execution, so as to realize the security control method provided in this application.

[0285] The processor 110 may also include a memory for storing instructions and data. In some embodiments, the memory in the processor 110 is a cache memory. This memory can store instructions or data that the processor 110 has just used or that are used repeatedly. If the processor 110 needs to use the instruction or data again, it can retrieve it directly from the aforementioned memory. This avoids repeated accesses, reduces the waiting time of the processor 110, and thus improves the efficiency of the system.

[0286] In some embodiments, the processor 110 may include one or more interfaces. Interfaces may include an inter-integrated circuit (I2C) interface, an inter-integrated circuit sound (I2S) interface, a pulse code modulation (PCM) interface, a universal asynchronous receiver / transmitter (UART) interface, a mobile industry processor interface (MIPI), a general-purpose input / output (GPIO) interface, a SIM card interface, and / or a universal serial bus (USB) interface, etc.

[0287] USB port 130 is a USB standard compliant interface, specifically a Mini USB port, Micro USB port, USB Type-C port, etc. USB port 130 can be used to connect a charger to charge electronic device 100, and can also be used for data transfer between electronic device 100 and peripheral devices. It can also be used to connect headphones for audio playback. This interface can also be used to connect other electronic devices, such as AR devices.

[0288] It is understood that the interface connection relationships between the modules illustrated in the embodiments of this application are merely illustrative and do not constitute a structural limitation on the electronic device 100. In other embodiments of this application, the electronic device 100 may also employ different interface connection methods or combinations of multiple interface connection methods as described in the above embodiments.

[0289] The charging management module 140 receives charging input from a charger. The charger can be a wireless charger or a wired charger. In some wired charging embodiments, the charging management module 140 receives charging input from the wired charger via the USB interface 130. In some wireless charging embodiments, the charging management module 140 receives wireless charging input via the wireless charging coil of the electronic device 100. While charging the battery 142, the charging management module 140 can also supply power to the electronic device via the power management module 141.

[0290] The wireless communication function of electronic device 100 can be realized through antenna 1, antenna 2, mobile communication module 150, wireless communication module 160, modem processor and baseband processor, etc.

[0291] Antenna 1 and antenna 2 are used to transmit and receive electromagnetic wave signals. Each antenna in electronic device 100 can be used to cover one or more communication frequency bands. Different antennas can also be multiplexed to improve antenna utilization. For example, antenna 1 can be multiplexed as a diversity antenna for a wireless local area network. In some other embodiments, the antennas can be used in conjunction with tuning switches.

[0292] The mobile communication module 150 can provide solutions for wireless communication, including 2G / 3G / 4G / 5G / 5.5G / 6G, applied to the electronic device 100. The mobile communication module 150 may include at least one filter, switch, power amplifier, low noise amplifier (LNA), etc. The mobile communication module 150 can receive electromagnetic waves via antenna 1, and perform filtering, amplification, and other processing on the received electromagnetic waves before transmitting them to a modem processor for demodulation. The mobile communication module 150 can also amplify the signal modulated by the modem processor and convert it into electromagnetic waves for radiation via antenna 1. In some embodiments, at least some functional modules of the mobile communication module 150 may be housed in the processor 110. In some embodiments, at least some functional modules of the mobile communication module 150 and at least some modules of the processor 110 may be housed in the same device.

[0293] The modem processor may include a modulator and a demodulator. The modulator modulates the low-frequency baseband signal to be transmitted into a mid-to-high frequency signal. The demodulator demodulates the received electromagnetic wave signal into a low-frequency baseband signal. The demodulator then transmits the demodulated low-frequency baseband signal to the baseband processor for processing. After processing by the baseband processor, the low-frequency baseband signal is transmitted to the application processor. The application processor outputs sound signals through an audio device (not limited to speaker 170A, receiver 170B, etc.) or displays images or videos through the display screen 194. In some embodiments, the modem processor may be a separate device. In other embodiments, the modem processor may be independent of the processor 110 and may be housed in the same device as the mobile communication module 150 or other functional modules.

[0294] The wireless communication module 160 can provide solutions for wireless communication applications on the electronic device 100, including wireless local area networks (WLANs) (such as wireless fidelity (Wi-Fi) networks), Bluetooth (BT), global navigation satellite system (GNSS), frequency modulation (FM), near field communication (NFC), and infrared (IR) technologies. The wireless communication module 160 can be one or more devices integrating at least one communication processing module. The wireless communication module 160 receives electromagnetic waves via antenna 2, performs frequency modulation and filtering of the electromagnetic wave signals, and sends the processed signal to processor 110. The wireless communication module 160 can also receive signals to be transmitted from processor 110, perform frequency modulation and amplification, and convert them into electromagnetic waves for radiation via antenna 2.

[0295] In some embodiments, antenna 1 of electronic device 100 is coupled to mobile communication module 150, and antenna 2 is coupled to wireless communication module 160, enabling electronic device 100 to communicate with networks and other devices via wireless communication technology. The aforementioned wireless communication technology may include Global System for Mobile Communications (GSM), General Packet Radio Service (GPRS), Code Division Multiple Access (CDMA), Wideband Code Division Multiple Access (WCDMA), Time-Division Code Division Multiple Access (TD-SCDMA), Long Term Evolution (LTE), BT, GNSS, WLAN, NFC, FM, and / or IR technologies, etc. The aforementioned GNSS may include the Global Positioning System (GPS), the Global Navigation Satellite System (GLONASS), the BeiDou Navigation Satellite System (BDS), the Quasi-Zenith Satellite System (QZSS), and / or satellite-based augmentation systems (SBAS).

[0296] Electronic device 100 implements display functions through a GPU, a display screen 194, and an application processor. The GPU is a microprocessor for image processing, connected to the display screen 194 and the application processor. The GPU is used to perform mathematical and geometric calculations and for graphics rendering. Processor 110 may include one or more GPUs, which execute program instructions to generate or modify display information.

[0297] Display screen 194 is used to display images, videos, etc. Display screen 194 includes a display panel. The display panel may be a liquid crystal display (LCD), an organic light-emitting diode (OLED), an active-matrix organic light-emitting diode (AMOLED), a flexible light-emitting diode (FLED), a Mini-LED, a Micro-LED, a Micro-OLED, a quantum dot light-emitting diode (QLED), etc. In some embodiments, electronic device 100 may include one or N displays 194, where N is a positive integer greater than 1.

[0298] Electronic device 100 can perform shooting functions through ISP, camera 193, video codec, GPU, display 194 and application processor.

[0299] An NPU (Neural Processing Unit) is a computational processor for neural networks (NNs). By borrowing the structure of biological neural networks, such as the transmission patterns between neurons in the human brain, it can rapidly process input information and continuously learn on its own. NPUs enable intelligent cognitive applications in electronic devices, such as image recognition, facial recognition, speech recognition, and text understanding.

[0300] The external storage interface 120 can be used to connect an external memory card, such as a Micro SD card, to expand the storage capacity of the electronic device 100. The external memory card communicates with the processor 110 through the external storage interface 120 to perform data storage functions. For example, music, video, and other files can be saved on the external memory card.

[0301] Internal memory 121 can be used to store computer executable program code, including instructions. Internal memory 121 may include a program storage area and a data storage area. The program storage area may store the operating system, application programs required for at least one function (such as sound playback, image playback, etc.), etc. The data storage area may store data created during the use of electronic device 100 (such as audio data, phonebook, etc.). In addition, internal memory 121 may include high-speed random access memory, and may also include non-volatile memory, such as at least one disk storage device, flash memory device, universal flash storage (UFS), etc. Processor 110 executes various functional applications and data processing of electronic device 100 by running instructions stored in internal memory 121 and / or instructions stored in memory disposed in the processor.

[0302] Electronic device 100 can implement audio functions, such as music playback and recording, through audio module 170, speaker 170A, receiver 170B, microphone 170C, headphone jack 170D, and application processor.

[0303] The audio module 170 is used to convert digital audio information into analog audio signals for output, and also to convert analog audio input into digital audio signals. The audio module 170 can also be used for encoding and decoding audio signals. In some embodiments, the audio module 170 may be located in the processor 110, or some functional modules of the audio module 170 may be located in the processor 110.

[0304] Buttons 190 include a power button, volume buttons, etc. Buttons 190 can be mechanical buttons or touch-sensitive buttons. Electronic device 100 can receive button input and generate key signal inputs related to user settings and function control of electronic device 100.

[0305] Motor 191 can generate vibration alerts. Motor 191 can be used for incoming call vibration alerts or for touch vibration feedback. For example, different vibration feedback effects can correspond to touch operations performed on different applications (such as taking photos, playing audio, etc.). Motor 191 can also correspond to different vibration feedback effects for touch operations performed on different areas of the display screen 194. Different application scenarios (such as time reminders, receiving messages, alarm clocks, games, etc.) can also correspond to different vibration feedback effects. The touch vibration feedback effect can also be customized.

[0306] Indicator 192 can be an indicator light, used to indicate charging status, power changes, or to indicate messages, missed calls, notifications, etc.

[0307] The SIM card interface 195 is used to connect a SIM card. The SIM card can be inserted into or removed from the SIM card interface 195 to make contact with and separate from the electronic device 100. The electronic device 100 can support one or N SIM card interfaces, where N is a positive integer greater than 1. The SIM card interface 195 can support Nano SIM cards, Micro SIM cards, SIM cards, etc. Multiple cards can be inserted into the same SIM card interface 195 simultaneously. The types of these multiple cards can be the same or different. The SIM card interface 195 is also compatible with different types of SIM cards. The SIM card interface 195 is also compatible with external memory cards. The electronic device 100 interacts with the network through the SIM card to realize functions such as calls and data communication. In some embodiments, the electronic device 100 uses an eSIM, i.e., an embedded SIM card. The eSIM card can be embedded in the electronic device 100 and cannot be separated from the electronic device 100.

[0308] In this embodiment, the second application installed on the first terminal 00 can receive verification information such as SMS verification codes sent by the communication operator based on the SIM card or eSIM card connected to the SIM card interface 195, which will not be elaborated here.

[0309] Figure 9 A schematic diagram of the structure of a communication device is shown according to an embodiment of this application.

[0310] like Figure 9 As shown, the communication device 900 may include a processing module 910 (sometimes also called a processing unit) and a transceiver module 920 (sometimes also called a transceiver unit). The transceiver module is capable of both sending and receiving functions. When the transceiver module performs the sending function, it may be called a sending module (sometimes also called a sending unit); when it performs the receiving function, it may be called a receiving module (sometimes also called a receiving unit). The sending module and the receiving module may be the same functional module, which is called the transceiver module and can perform both sending and receiving functions; alternatively, the sending module and the receiving module may be different functional modules, and the transceiver module is a collective term for these functional modules.

[0311] In some possible implementations, the communication device 900 provided in the embodiments of this application further includes: a storage module 930 (sometimes also called a storage unit) for storing any data, computer instructions and / or computer programs that may be involved in the embodiments of this application.

[0312] The processing module 910, transceiver module 920, and storage module 930 in this application embodiment are used to enable the communication device 900 to perform the functions of the first electronic device (e.g., the first terminal 00) in the above method embodiment, or to perform the functions of the second electronic device (e.g., the server 20), or to perform cloud functions.

[0313] The following describes each module in the first electronic device, using the communication device 900 to implement the functions of the first electronic device in the above method embodiment.

[0314] In some possible implementations, the communication device 900 provided in this application embodiment includes a transceiver module 920 for receiving first verification information. This first verification information is verification information corresponding to a first user operation request acting on a first interface of a first application. The first verification information is used to determine whether the user's identity is legitimate based on a first matching result, where the first matching result is the matching result between the first verification information and signature information stored in a second electronic device. Alternatively, the first verification information is SMS information encrypted with a public key by the second electronic device. This first verification information is used to determine whether the user's identity is legitimate based on a second matching result, where the second matching result is the result of decrypting the first verification information. The decryption result is related to whether a private key corresponding to the public key exists. A processing module 910 is used to determine the legitimacy of the user identity corresponding to the first user operation based on the first verification information and display a second interface, where the second interface includes the interface after the first application successfully responds to the first user operation.

[0315] In some embodiments, the first verification information includes an SMS verification code, wherein the SMS verification code is a verification code generated by the second electronic device in response to a first verification request from the first application. Furthermore, the first verification information is a first SMS verification code encrypted by the second electronic device using a first public key, wherein the first public key is the same as the first private key in a first key pair in the first electronic device. Correspondingly, the processing module 910 is further configured to decrypt the first SMS verification code using the first private key; and to determine the legitimacy of the user identity corresponding to the first user operation based on the successful decryption of the first SMS verification code.

[0316] In some embodiments, the first verification information is a second SMS verification code encrypted by the second electronic device using a second public key, wherein the second public key corresponds to the second private key in the second key pair in the third electronic device. Correspondingly, the processing module 910 is further configured to decrypt the second SMS verification code using a first private key, wherein the first private key corresponds to the first public key in the first key pair in the first electronic device; and to determine, based on the result of the second SMS verification code decryption failure, that the user identity corresponding to the first user operation is illegitimate. The third electronic device may, for example, be the second terminal 10, i.e., the electronic device used by the fraudster.

[0317] In some embodiments, the first electronic device includes a second application, wherein the second application is used to receive and process the first SMS verification code. Correspondingly, the processing module 910 is further configured to send the first public key to the first application based on the second application's response to the first application's request to obtain a key. The processing module 910 is further configured to instruct the transceiver module 920 to send the first public key to the second electronic device based on the first application, wherein the first public key is used to encrypt the SMS verification code generated by the second electronic device to obtain the first SMS verification code.

[0318] In some embodiments, the processing module 910 is further configured to control the display of a third interface of the second application, the third interface including the first verification information; or, to send the first verification information to the first application to confirm the response to the first user operation; or, to provide the first verification information to the input method application so that the input method application displays the first verification information.

[0319] In some embodiments, the processing module 910 is further configured to display a fifth interface when it is determined that the user identity corresponding to the first user operation is illegitimate, wherein the fifth interface includes a first risk warning information related to the first verification information.

[0320] In some embodiments, the first verification information includes unencrypted SMS messages. Correspondingly, the processing module 910 is further configured to determine, based on the first verification information, that the user identity corresponding to the first user operation is illegitimate, and display a sixth interface, wherein the sixth interface includes second risk warning information related to the first verification information.

[0321] In some embodiments, the first verification information includes first signature information obtained from a third application, wherein the third application manages card information related to user identity, the card information is used to generate the first signature information, and the first signature information is related to signature information stored in the second electronic device. Correspondingly, the processing module 910 is configured to, in response to a second user operation instructing the binding of the card information, obtain the card information from a security authority managing the card information; generate the first signature information based on the card information; and instruct the transceiver module 920 to send the first signature information to the second electronic device.

[0322] In some embodiments, the processing module 910 is configured to send a second verification request to the second electronic device based on the second signature information, wherein the second verification request is configured to request the second electronic device to verify whether the second signature information has matching signature information; and to receive the result from the second electronic device confirming that the second signature information matches the stored first signature information, and to determine that the user identity corresponding to the first user operation is legitimate.

[0323] The following describes each module in the second electronic device, using the communication device 900 to implement the functions of the second electronic device in the above method embodiment.

[0324] In some possible implementations, the communication device 900 provided in this application embodiment includes a transceiver module 920, which is used to receive a first verification request from a first application of a first electronic device, determine first verification information, wherein the first verification information is used to determine whether the user's identity is legitimate based on a first matching result, and the first matching result is the matching result between the first verification information and stored signature information; or, the first verification information is a text message encrypted with a public key, wherein the first verification information is used to determine whether the user's identity is legitimate based on a second matching result, and the second matching result is the result of decrypting the first verification information, wherein the decryption result is related to whether there is a private key corresponding to the public key; and is used to send the first verification information to the first electronic device.

[0325] In some embodiments, the first verification information includes an SMS verification code, which is a verification code generated in response to the first verification request.

[0326] In some embodiments, the first verification information is SMS information encrypted with a public key, including: a first SMS verification code encrypted with the first public key, wherein the first public key corresponds to the first private key in the first key pair in the first electronic device. Correspondingly, the processing module 910 is used to encrypt the SMS verification code with the first public key to obtain the first SMS verification code.

[0327] In some embodiments, the first verification information is a text message encrypted with a public key, including a second text message verification code encrypted with a second public key, wherein the second public key corresponds to the second private key in the second key pair in the third electronic device. Correspondingly, the processing module 910 is used to encrypt the text message verification code with the second public key to obtain the second text message verification code. The third electronic device may, for example, be the second terminal 10, i.e., the electronic device used by the fraudster.

[0328] In some embodiments, the transceiver module 920 is used to receive the first public key from the first electronic device, wherein the first public key is used to encrypt the generated SMS verification code to obtain the first SMS verification code.

[0329] In some embodiments, the transceiver module 920 receives first signature information from the first electronic device, the first signature information being generated based on card information, the card information being obtained from a security authority managing the card information in response to an instruction to a second user to bind the card information; and the storage module 930 is used to store the first signature information.

[0330] In some embodiments, the transceiver module 920 is configured to receive a second verification request carrying second signature information; the processing module 910 is configured to determine a third matching result in which the second signature information matches the stored first signature information; the transceiver module 920 is further configured to send the third matching result to the first electronic device.

[0331] For more detailed information on the operation of the above-mentioned processing module 910 and transceiver module 920, please refer to the description in the above method embodiments, which will not be repeated here.

[0332] It should be noted that the physical device corresponding to the processing module 910 in this device can be a processor, and the physical device corresponding to the transceiver module 920 can be a transceiver. Furthermore, the physical device corresponding to the storage module 930 in this device can be a memory.

[0333] It should be noted that the information interaction and execution process between the modules of the above-mentioned device are based on the same concept as the method embodiment of this application, and the resulting technical effects are the same as those of the method embodiment of this application. For details, please refer to the description in the method embodiment shown above in this application, and it will not be repeated here.

[0334] This application also provides a computer-readable storage medium storing instructions that, when executed on a computer, cause the computer to perform the security control method provided by the invention and specific embodiments of this application.

[0335] This application also provides a computer program product, including a computer program / instruction, which, when executed by a processor, is used to implement the security control method provided by the above-described invention and specific embodiments.

[0336] This application also provides a chip including a processor, the processor being coupled to a memory, for executing computer programs or instructions stored in the memory, so that the chip implements the security control method provided by the above-described invention and specific embodiments of this application.

[0337] Various embodiments of the mechanisms disclosed in this application can be implemented in hardware, software, firmware, or combinations of these implementation methods. Embodiments of this application can be implemented as computer program modules or module code executable on a programmable system, the programmable system including at least one processor, a storage system (including volatile and non-volatile memory and / or storage elements), at least one input device, and at least one output device.

[0338] Computer program modules or module code can be applied to input instructions to perform the functions described in this application and generate output information. The output information can be applied to one or more output devices in a known manner. For the purposes of this application, the processing system includes any system having a processor such as, for example, a digital signal processor (DSP), a microcontroller, an application-specific integrated circuit (ASIC), or a microprocessor.

[0339] Module code can be implemented using a high-level modular language or an object-oriented programming language to communicate with the processing system. Assembly language or machine language can also be used to implement module code when needed. In fact, the mechanisms described in this application are not limited to any particular programming language. In either case, the language can be a compiled language or an interpreted language.

[0340] In some cases, the disclosed embodiments may be implemented in hardware, firmware, software, or any combination thereof. The disclosed embodiments may also be implemented as instructions carried or stored thereon on one or more temporary or non-temporary machine-readable (e.g., computer-readable) storage media, which may be read and executed by one or more processors. For example, the instructions may be distributed via a network or via other computer-readable storage media. Therefore, machine-readable storage media may include any mechanism for storing or transmitting information in a machine-readable (e.g., computer-readable) form, including but not limited to floppy disks, optical disks, optical discs, magneto-optical disks, read-only memory (ROM), random access memory (RAM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), magnetic cards or optical cards, flash memory, or tangible machine-readable storage for transmitting information (e.g., carrier waves, infrared signals, digital signals, etc.) using the Internet in the form of electrical, optical, acoustic, or other forms of propagated signals. Therefore, machine-readable storage media include any type of machine-readable storage media suitable for storing or transmitting electronic instructions or information in a machine-readable (e.g., computer-readable) form.

[0341] In this specification, the reference to "an embodiment" or "an embodiment" means that a specific feature, structure, or characteristic described in connection with the embodiment is included in at least one exemplary implementation or technology disclosed according to an embodiment of this application. The appearance of the phrase "in an embodiment" in various places in the specification does not necessarily refer to the same embodiment.

[0342] The disclosure of embodiments of this application also relates to means for performing operations in text. This means may be specifically constructed for the claimed purpose or may include a general-purpose computer selectively activated or reconfigured by a computer program stored in a computer. Such a computer program may be stored in a computer-readable storage medium, such as, but not limited to, any type of disk, including floppy disks, optical disks, CD-ROMs, magneto-optical disks, read-only memory (ROM), random access memory (RAM), EPROM, EEPROM, magnetic or optical cards, application-specific integrated circuits (ASICs), or any type of medium suitable for storing electronic instructions, and each may be coupled to a computer system bus. Furthermore, the computer mentioned in the specification may include a single processor or may be an architecture employing multiple processors for increased computing power.

[0343] Furthermore, the language used in this specification has been primarily chosen for readability and instructional purposes and may not have been chosen to depict or limit the disclosed subject matter. Therefore, the embodiments disclosed in this application are intended to illustrate, and not limit, the scope of the concepts discussed herein.

Claims

1. A safety control method, characterized in that, Applied to a first electronic device, the method includes: Receive the first verification information, in which, The first verification information is the verification information corresponding to the first user operation request applied to the first interface of the first application. The first verification information is used to determine whether the user's identity is legitimate based on the first matching result, whereby the first matching result is the matching result between the first verification information and the signature information stored in the second electronic device; or, The first verification information is a text message encrypted with a public key by the second electronic device. The first verification information is used to determine whether the user's identity is legitimate based on the second matching result. The second matching result is the result of decrypting the first verification information. The decryption result is related to whether there is a private key corresponding to the public key. Based on the first verification information, the user identity corresponding to the first user operation is determined to be legitimate, and a second interface is displayed, wherein the second interface includes the interface after the first application successfully responds to the first user operation.

2. The method according to claim 1, characterized in that, The first verification information includes an SMS verification code, wherein the SMS verification code is a verification code generated by the second electronic device in response to the first verification request of the first application.

3. The method according to claim 2, characterized in that, The first verification information is a text message encrypted with a public key by the second electronic device, including: The first verification information is a first SMS verification code encrypted by the second electronic device using a first public key, wherein the first public key corresponds to the first private key in the first key pair in the first electronic device.

4. The method according to claim 3, characterized in that, The step of determining the legitimacy of the user identity corresponding to the first user operation based on the first verification information includes: Use the first private key to decrypt the first SMS verification code; Based on the successful decryption of the first SMS verification code, it is determined that the user identity corresponding to the first user operation is legitimate.

5. The method according to claim 2, characterized in that, The first verification information is a text message encrypted with a public key by the second electronic device, including: The first verification information is a second SMS verification code encrypted by the second electronic device using the second public key, wherein the second public key corresponds to the second private key in the second key pair in the third electronic device.

6. The method according to claim 5, characterized in that, The method further includes: The second SMS verification code is decrypted using the first private key, wherein the first private key corresponds to the first public key in the first key pair in the first electronic device; Based on the failure to decrypt the second SMS verification code, it is determined that the user identity corresponding to the first user's operation is illegitimate.

7. The method according to claim 3 or 4, characterized in that, The first electronic device includes a second application, wherein the second application is used to receive and process the first SMS verification code, and the method further includes: Based on the second application's response to the first application's request to obtain the key, the second application sends the first public key to the first application.

8. The method according to claim 7, characterized in that, The method further includes: The first application sends the first public key to the second electronic device, wherein the first public key is used to encrypt the SMS verification code generated by the second electronic device to obtain the first SMS verification code.

9. The method according to claim 7, characterized in that, The method further includes: Display a third interface of the second application, the third interface including the first verification information; or, Send the first verification information to the first application to confirm the response to the first user operation; or, The first verification information is provided to the input method application so that the input method application displays the first verification information.

10. The method according to claim 6, characterized in that, The method further includes: If it is determined that the user identity corresponding to the first user operation is illegitimate, a fifth interface is displayed, wherein the fifth interface includes a first risk warning information related to the first verification information.

11. The method according to claim 1, characterized in that, The first verification information includes unencrypted SMS messages, and the method further includes: Based on the first verification information, it is determined that the user identity corresponding to the first user operation is illegitimate, and a sixth interface is displayed, wherein the sixth interface includes second risk warning information related to the first verification information.

12. The method according to claim 1, characterized in that, The first verification information includes first signature information obtained from a third application, wherein the third application is used to manage card information related to user identity, the card information is used to generate the first signature information, and the first signature information is related to the signature information stored in the second electronic device.

13. The method according to claim 12, characterized in that, The method further includes: In response to an instruction from a second user to bind the card information, the card information is retrieved from a security authority that manages the card information. The first signature information is generated based on the card information; and... The first signature information is sent to the second electronic device.

14. The method according to claim 13, characterized in that, The step of determining the legitimacy of the user identity corresponding to the first user operation based on the first verification information includes: A second verification request is sent to the second electronic device based on the second signature information, wherein the second verification request is used to request the second electronic device to verify whether the second signature information has matching signature information; The system receives confirmation from the second electronic device that the second signature information matches the stored first signature information, and determines that the user identity corresponding to the first user operation is legitimate.

15. A safety control method, characterized in that, Applied to a second electronic device, the second electronic device including a server for the first application, the method includes: A first verification request is received from a first application of a first electronic device, and first verification information is determined. The first verification information is used to determine whether a user's identity is legitimate based on a first matching result, where the first matching result is a match between the first verification information and stored signature information. Alternatively, the first verification information is a text message encrypted with a public key, and the first verification information is used to determine whether a user's identity is legitimate based on a second matching result, where the second matching result is the result of decrypting the first verification information, and the decryption result is related to the existence of a private key corresponding to the public key. Send the first verification information to the first electronic device.

16. The method according to claim 15, characterized in that, The first verification information includes an SMS verification code, which is a verification code generated in response to the first verification request.

17. The method according to claim 16, characterized in that, The first verification information is a text message encrypted with a public key, including: The first SMS verification code is encrypted using a first public key, wherein the first public key corresponds to the first private key in the first key pair in the first electronic device.

18. The method according to claim 16, characterized in that, The first verification information is a text message encrypted with a public key, including: The second SMS verification code is encrypted using the second public key, wherein the second public key corresponds to the second private key in the second key pair in the third electronic device.

19. The method according to claim 15, characterized in that, The first verification information includes unencrypted SMS messages, which are used to determine that the user's identity is illegitimate based on the unencrypted state.

20. The method according to claim 17, characterized in that, The method further includes: The system receives the first public key from the first electronic device, wherein the first public key is used to encrypt the generated SMS verification code to obtain the first SMS verification code.

21. The method according to claim 15, characterized in that, The method further includes: Receive first signature information from the first electronic device, the first signature information being generated based on card information, the card information being obtained from a security authority that manages the card information in response to an instruction from a second user to bind the card information; Store the first signature information.

22. The method according to claim 21, characterized in that, The method further includes: Receive a second verification request carrying a second signature information; A third matching result is determined to match the second signature information with the stored first signature information; The third matching result is sent to the first electronic device.

23. An electronic device, characterized in that, include: One or more processors; One or more memories; the one or more memories storing one or more programs, which, when executed by the one or more processors, cause the electronic device to perform the security control method of any one of claims 1 to 14; or cause the electronic device to perform the security control method of any one of claims 15 to 22.

24. A computer-readable storage medium, characterized in that, The readable storage medium stores instructions that, when executed on a computer, cause the computer to perform the security control method of any one of claims 1 to 14, or cause the computer to perform the security control method of any one of claims 15 to 22.

Images