WO2015188728A1

WO2015188728A1 - Mobile payment security protection method, apparatus and cloud server

Info

Publication number: WO2015188728A1
Application number: PCT/CN2015/080901
Authority: WO
Inventors: 孟齐源; 路轶; 李常坤; 高祎玮
Original assignee: 北京奇虎科技有限公司; 奇智软件（北京）有限公司
Priority date: 2014-06-10
Filing date: 2015-06-05
Publication date: 2015-12-17

Abstract

A mobile payment security protection method, apparatus and cloud server, and a mobile terminal secure payment method and apparatus. The mobile payment security protection method comprises: when a triggering event of a mobile terminal payment client is detected, acquiring the feature information of the payment client, wherein said feature information refers to unique ID information of the payment client (S102); implementing matching of the acquired feature information and feature information in a preset white list to obtain matching results, wherein said white list comprises feature information of mobile terminal payment clients which can securely complete payment operations (S104); on the basis of the matching results, determining whether the payment client is a malicious client (S106); and, on the basis of the determining results, processing the payment client (S108). The security of payment clients on a mobile terminal can be improved, enhancing protection against malicious attacks such as viruses and Trojans, and thereby providing a secure, clean mobile payment environment for the user.

Description

Mobile payment security protection method, device and cloud server

Technical field

The present invention relates to the field of mobile terminal technologies, and in particular, to a mobile payment security protection method, device and cloud server, and a secure payment method and device for a mobile terminal.

Background technique

Mobile payment refers to a service method that allows users to use their mobile terminals (such as mobile phones) to pay for goods or services they consume. The user sends a payment instruction directly or indirectly to the banking financial institution through the mobile terminal, the Internet or proximity sensing to generate a money payment and a fund transfer behavior, thereby realizing the mobile payment function. With the rapid development of mobile e-commerce, third-party payment, banking and other companies are rushing to launch mobile payment clients. Shopping clients such as shopping, wealth management and life services are also emerging, which greatly enriches the market application environment of mobile payment.

The security of mobile payments is a key factor affecting the development of payment services. The security of mobile payment involves the confidentiality of user information, the security of user funds and payment information, and the security risks it faces mainly come from two aspects: network and system security, and the security of mobile terminals.

In terms of mobile terminals, some fake clients masquerade as genuine payment-type clients, or some Trojans and virus programs are packaged twice into payment-type clients, resulting in lower security of payment-type clients on mobile terminals. Viruses, Trojans and other malicious attacks are poorly protected, which in turn makes users' privacy, traffic, and phone bills stolen and misappropriated, causing serious losses to users.

Summary of the invention

In view of the above problems, the present invention has been made in order to provide a mobile payment security protection method, apparatus, and cloud server that overcome the above problems or at least partially solve the above problems, and a secure payment method and apparatus for the mobile terminal.

According to an aspect of the present invention, a method for protecting mobile payment security is provided, including: acquiring feature information of a payment type client when monitoring a trigger event of a mobile terminal payment type client, wherein the feature information refers to The unique identification information of the payment type client is matched with the feature information in the preset white list to obtain a matching result, wherein the white list includes a mobile that can safely complete the payment type operation The feature information of the terminal payment type client; determining, according to the matching result, whether the payment type client is a malicious client; and processing the payment client according to the determination result.

According to another aspect of the present invention, a method for protecting mobile payment security is provided, comprising: receiving, from a mobile terminal, a query request for querying whether a payment terminal client of a mobile terminal is a malicious client, wherein the query request carries An icon of the payment-type client; calculating a similarity between the icon of the payment-type client and the icon in the preset icon library, and determining an icon in the icon library that the similarity is greater than or equal to a preset threshold; Presetting the mapping relationship between the icon in the icon library and the known payment client, querying the known payment client corresponding to the determined icon; determining whether the known payment client is a malicious client The terminal obtains the result of the judgment; and the result of the judgment is used as a result of the query of the payment client as a malicious client, and is sent to the mobile terminal.

According to another aspect of the present invention, there is also provided a mobile payment security protection device, comprising:

The acquiring module is configured to acquire the feature information of the payment class client when the trigger event of the payment terminal of the mobile terminal is monitored, where the feature information refers to the unique identity information of the payment class client;

The matching module is configured to match the acquired feature information with the feature information in the preset whitelist to obtain a matching result, where the whitelist includes a mobile terminal payment client capable of performing a payment type operation securely. Characteristic information

The first determining module is configured to determine, according to the matching result, whether the payment client is a malicious client;

The processing module is configured to process the payment client according to the determination result.

According to another aspect of the present invention, a cloud server is further provided, including:

The request receiving module is configured to receive a query request from the mobile terminal to query whether the payment terminal client of the mobile terminal is a malicious client, where the query request carries an icon of the payment client;

a calculation module, configured to calculate an similarity between an icon of the payment client and an icon in the preset icon library, and determine an icon in the icon library that the similarity is greater than or equal to a preset threshold;

The query module is configured to query, according to a preset mapping relationship between the icon in the icon library and a known payment client, a known payment client corresponding to the determined icon;

The third determining module is configured to determine whether the known payment client is a malicious client, and obtain a determination result;

The sending module is configured to use the judgment result as a query result of whether the payment client is a malicious client, and send the result to the mobile terminal.

The beneficial effects of the invention are:

In the embodiment of the present invention, when the trigger event of the payment client of the mobile terminal is detected, the feature information of the payment client is obtained, and the acquired feature information is matched with the feature information in the preset whitelist to obtain a matching result. Then, according to the matching result, it is determined whether the payment client is a malicious client, and then the payment client is processed according to the judgment result. Since the feature information is the unique identity information of the payment client, the fake client masquerading as the payment client is only similar in interface, but the identity cannot be copied, and the payment client of the second packaged Trojan and virus program is due to the client. The information itself changes, and the identity identifier must change accordingly. It is different from the unique identity information of the original payment client. Therefore, the feature information can be used to flexibly and effectively identify the fake client that is disguised as a genuine payment client or twice. A payment class client packaged with Trojans and virus programs. After the feature information is authenticated, it can be confirmed whether the currently used payment client is a malicious client and timely processed according to the judgment result. If you identify a malicious client, you can stop the payment class operation, and you can also report the complaint and minimize the user's loss. Therefore, the technical solution provided by the embodiment of the present invention can improve the security of the payment client on the mobile terminal, enhance the protection against malicious attacks such as viruses and Trojans, and provide a safe and clean mobile payment environment for the user.

According to still another aspect of the present invention, a secure payment method for a mobile terminal is provided, which includes: monitoring, when a payment-type client installed in a mobile terminal starts, acquiring identity identification information of the payment-type client, wherein The identity information includes at least one of the following: a package name information of the payment type client, version information of the payment type client, signature information of the payment type client, and determining the identifier according to the identity information of the payment type client. Whether the security of the payment type client is verified; if so, the payment operation is performed by the payment type client.

According to still another aspect of the present invention, a secure payment device for a mobile terminal is provided, which is applied to a mobile terminal, and includes: a monitoring module configured to monitor a payment type client installed on the mobile terminal to be activated; and an acquisition module configured to acquire The identification information of the payment-type client is detected, wherein the identity identification information includes at least one of the following: a package name information of the payment-type client, version information of the payment-type client, and the payment-type client And the determining module is configured to determine whether the security of the payment client is verified according to the identity information of the payment client, and the processing module is configured to: if it is determined that the security of the payment client is verified, use the The payment type client performs a payment operation.

The beneficial effects of the invention are:

According to the embodiment of the present invention, when the payment client is started, the identity information of the payment type client that is detected is obtained, and the security of the payment client is verified according to the obtained identity information. In the prior art, the user cannot judge whether the security of the payment type client used is verified. Therefore, the privacy information cannot be leaked and the property is not lost when the payment client is used. The embodiment of the present invention can obtain the identity identification information of the payment client when the payment client is started, and perform security verification on the payment client according to the obtained identity information of the payment client, when determining the payment. After the class client passes the security verification, the payment client is used to perform the payment operation. Therefore, according to the embodiment of the present invention, the problem of not being able to perform security verification on the payment client in the prior art can be solved, and the beneficial effect of avoiding the use of the fake payment client that steals the user's private information is achieved, thereby being reasonable and effective. Avoid the disclosure of user privacy information and protect the security of user property.

According to still another aspect of the present invention, a computer program is provided, comprising computer readable code, when the computer readable code is run on a computing device, causing the computing device to perform any of the above Mobile payment security protection method and/or secure payment method of mobile terminal.

According to still another aspect of the present invention, a computer readable medium storing the above computer program is provided.

The above description is only an overview of the technical solutions of the present invention, and the above-described and other objects, features and advantages of the present invention can be more clearly understood. Specific embodiments of the invention are set forth below.

DRAWINGS

Various other advantages and benefits will become apparent to those skilled in the art from a The drawings are only for the purpose of illustrating the preferred embodiments and are not to be construed as limiting. Throughout the drawings, the same reference numerals are used to refer to the same parts. In the drawing:

1 is a flow chart showing a method for protecting mobile payment security on a mobile terminal side according to an embodiment of the present invention;

2 is a flow chart showing a method for protecting mobile payment security on the cloud server side according to an embodiment of the present invention;

FIG. 3 is another flow chart showing a method for protecting mobile payment security on the mobile terminal side according to an embodiment of the present invention; FIG.

4 is a third flowchart of a method for protecting mobile payment security on a mobile terminal side according to an embodiment of the present invention;

FIG. 5 is a flow chart showing a method for protecting mobile payment security in combination with a mobile terminal and a cloud server according to an embodiment of the present invention; FIG.

6 shows another flow chart of a method for protecting mobile payment security combining a mobile terminal and a cloud server according to an embodiment of the present invention;

FIG. 7 is a schematic structural diagram of a mobile payment security protection apparatus on a mobile terminal side according to an embodiment of the present invention; FIG.

FIG. 8 is a schematic structural diagram of a cloud server according to an embodiment of the present invention; FIG.

FIG. 9 is a flowchart showing a process of a secure payment method of a mobile terminal according to an embodiment of the present invention; FIG.

FIG. 10 is a flowchart showing a process of a secure payment method of a mobile terminal according to a preferred embodiment of the present invention; FIG.

FIG. 11 is a schematic structural diagram of a secure payment apparatus of a mobile terminal according to an embodiment of the present invention; FIG.

FIG. 12 is a block diagram showing the structure of a secure payment device of a mobile terminal according to a preferred embodiment of the present invention; FIG.

Figure 13 is a block diagram schematically showing a computing device for performing a mobile payment security protection method and/or a secure payment method of a mobile terminal according to the present invention;

Fig. 14 schematically shows a storage unit for holding or carrying a program code for implementing a mobile payment security protection method and/or a secure payment method of a mobile terminal according to the present invention.

detailed description

The invention is further described below in conjunction with the drawings and specific embodiments.

First, a method, a device, and a cloud server for protecting a mobile payment security provided by an embodiment of the present invention are introduced.

FIG. 1 is a flow chart showing a method of protecting mobile payment security on a mobile terminal side according to an embodiment of the present invention. As shown in FIG. 1, the method includes at least the following steps S102 to S108.

In step S102, when the trigger event of the payment client of the mobile terminal is detected, the feature information of the payment client is obtained, where the feature information refers to the unique identity information of the payment client.

Step S104: Matching the acquired feature information with the feature information in the preset whitelist to obtain a matching result, where the whitelist includes feature information of the mobile terminal payment client that can securely perform the payment class operation.

Step S106: Determine, according to the matching result, whether the payment type client is a malicious client.

Step S108: Processing the payment client according to the determination result.

In step S102 above, the trigger event of the payment class client may include multiple events. For example, install a payment class client, such as downloading the installation package of the payment class client, and install it. For another example, a payment type client is started, such as a payment type client, for browsing and payment. Also for example, scanning a payment-type client, such as scanning a payment-type client through a security guard. For another example, the payment type client is updated, such as downloading the update package of the payment type client, updating, and the like. When these events occur, the technical solution provided by the present invention can be used to determine whether the payment client is a malicious client, and then the payment client is processed according to the judgment result.

When the trigger event of the mobile terminal payment type client is detected, step S102 further acquires the feature information of the payment type client. The feature information here is the unique identity information of the payment client, and may include a name, an icon, a package name, a signature, a version information, a message digest algorithm (MD5), and a SHA1 (Secure Hash Algorithm). , file size, file modification time, file creation time, and more. In addition, the implementation manners of the step S104 to the step S106 are not completely the same for different feature information. The implementation manners corresponding to different feature information are described in detail below.

First, the acquired feature information is a name (or package name) and an icon. In the white list, the name and icon of the payment terminal client of the mobile terminal capable of safely completing the payment operation are preset, and the mobile terminal payment client capable of safely completing the payment operation can be regarded as a genuine payment client or an official payment class. Client. The name index may be pre-established, and the icon corresponding to the obtained name in the white list is searched by the name index, and then the similarity between the obtained icon and the icon found in the white list is calculated. Then, according to the size of the similarity, it is determined whether the payment client is a malicious client. That is, if the similarity is greater than or equal to a preset threshold (eg, 99.5%), it may be determined that the payment client is a non-malicious client; if the similarity is less than a preset threshold, the payment client may be determined to be a malicious client or Unknown client. Further, if the number of icons in the preset white list includes at least one, the similarity between the acquired icon and the at least one icon found in the white list may be calculated. If the similarity between the icon and the acquired icon in the at least one icon of the preset whitelist is greater than or equal to the preset threshold, the payment client may be determined to be a non-malicious client; if at least one of the preset whitelists The similarity between each icon in the icon and the obtained icon is less than the preset threshold, and Determine the payment class client as a malicious client or an unknown client. For example, the preset white list includes 10 icons, and the similarity between the obtained icon and one of the icons is calculated. If the similarity is greater than or equal to a preset threshold (such as 99.5%), it can be determined that the payment client is non-malicious. The client; otherwise, it continues to calculate the similarity between the acquired icon and the next icon. If the similarity between the obtained icon and the 10 icons in the preset whitelist is less than a preset threshold, it may be determined that the payment client is a malicious client or an unknown client. In addition, the calculation of the similarity can adopt various methods such as a calculation pixel method or a gray scale matching method. For example, regarding the method of calculating pixels, first, the acquired icons are scaled to the same size as the icons in the preset white list, and then the pixels corresponding to the positions of the two icons are compared, and the similarities are calculated according to the number of the same pixels. degree. Under normal circumstances, a fake client pretending to be a genuine payment client fakes the name of the genuine payment client and highly simulates the icon of the genuine payment client, making it difficult for the user to distinguish, resulting in the user using the payment client. Leaking private information, causing serious economic losses. The technical means can effectively identify the fake client masquerading as a genuine payment client, and then process it, improve the security of the payment client on the mobile terminal, and provide a safe and clean mobile payment environment for the user.

Second, the acquired feature information is the name (or package name) and signature. The name and signature of the payment terminal client of the mobile terminal that can securely complete the payment operation are preset in the whitelist. The name index may be pre-established, and the signature corresponding to the obtained name in the whitelist is found by the name index, and the obtained signature is obtained. The same as the signature found in the whitelist, it can be determined that the payment client is a non-malicious client; if the obtained signature is different from the signature found in the whitelist, it can be determined that the payment client is a malicious client or Unknown client. Since the name of the payment client that has been packaged by the Trojan and the virus program is generally unchanged, but the signature has changed, the technical means can effectively identify the payment client that has been packaged with the Trojan and the virus program twice. Then, it is processed to improve the security of the payment client on the mobile terminal, and to enhance the protection against malicious attacks such as viruses and Trojans, thereby avoiding theft, misappropriation, such as user privacy, traffic, and call charges.

Furthermore, the acquired feature information may also be a package name, MD5, and SHA1. In the whitelist, the package name, MD5, and SHA1 of the payment terminal of the mobile terminal that can securely complete the payment operation are preset, and the package name index can be pre-established, and the obtained package name is found in the white list through the package name index. MD5 and SHA1. Then, it is determined whether the obtained MD5 and SHA1 are the same as the MD5 and SHA1 found in the whitelist to determine whether the payment client is a malicious client. That is, if the obtained MD5 is the same as the MD5 found in the whitelist, and the obtained SHA1 is the same as the SHA1 found in the whitelist, it is determined that the payment client is a non-malicious client. If the obtained MD5 is the same as the MD5 found in the whitelist, and the obtained SHA1 is different from the SHA1 found in the whitelist, it is determined that the payment client is a malicious client or an unknown client. If the obtained MD5 is different from the MD5 found in the whitelist, and the obtained SHA1 is the same as the SHA1 found in the whitelist, it is determined that the payment client is a malicious client or an unknown client. If the obtained MD5 is different from the MD5 found in the whitelist, and the obtained SHA1 is different from the SHA1 found in the whitelist, it is determined that the payment client is a malicious client or an unknown client. The technical means can effectively identify a counterfeit client masquerading as a genuine payment client or a payment client that has been packaged with a Trojan horse and a virus program twice, and process it to improve the payment client on the mobile terminal. The security of the end enhances the protection against malicious attacks such as viruses and Trojans. It should be noted that the acquired feature information may also be any combination of one or two or more pieces of information of the foregoing feature information, and is used to identify a fake client that is pretending to be a genuine payment client or to be packaged a Trojan or a virus twice. Program The payment class client is not listed here.

In addition, the white list mentioned in step S104 may be located at the local end (ie, the mobile terminal), or may be located at the cloud server. If the whitelist is located in the cloud server, the following technical means may be adopted: sending a query requesting the client to be a malicious client to the cloud server, wherein the query request carries the feature information of the payment client, and then the cloud server The feature information of the payment client is matched with the feature information in the whitelist to obtain a matching result, and then the matching result returned by the cloud server is received. Here, setting the whitelist to the cloud server can alleviate the processing pressure of the mobile terminal, save resources of the mobile terminal, and can also update the whitelist of the cloud server in time, without updating at the mobile terminal, and avoiding lag of the feature information. Improve the ability to handle malicious clients.

Further, if the foregoing step S106 determines that the payment client is a malicious client or an unknown client, the payment client may be determined to be malicious according to the similarity between the icon of the payment client and the icon in the preset icon library. The client is also a non-malicious client, enabling more accurate judgment. It can be performed on mobile terminals and cloud servers, and is now described in detail.

Regarding the scheme on the mobile terminal side. First, the icon of the payment client is obtained. The payment client is an unknown client, and then the similarity between the obtained icon and the icon in the preset icon library is calculated, and the similarity in the icon library is greater than or equal to a preset threshold. Icon. Then, according to the mapping relationship between the icon in the preset icon library and the known payment client, the known payment client corresponding to the determined icon is queried. If the known payment type client is a non-malicious client, the payment client is determined to be a non-malicious client; if the known payment client is a malicious client, the payment client is determined to be a malicious client. end. Therefore, a more accurate judgment can be achieved based on the icon similarity. In addition, the calculated similarity and the queried known payment class client may be sent to the cloud server for further judgment.

About the cloud server side solution. Considering the limitations of the mobile terminal processing capability, resource storage, etc., it can be further judged or verified on the cloud server side. First, an icon of the payment client is obtained. The payment client is an unknown client, and then sends a query requesting whether the payment client is a malicious client to the cloud server, where the query request carries an icon of the payment client, and then Receive the query results returned by the cloud server. If the payment type client is determined to be a malicious client according to the feature information in the white list, and the cloud server determines that the payment client is a non-malicious client (the possible reason is that the payment client is upgraded, and the mobile terminal is The whitelist library is not updated in time), that is, there is a false positive situation, and the cloud server can send the false alarm information to the mobile terminal, correct it in time, and improve the accuracy of the judgment. In addition, if the cloud server queries the payment client as a malicious client, the cloud server may also send an installation package or a download address of the payment client that can securely complete the payment operation to the mobile terminal. Further, the cloud server updates the preset icon library in real time, thereby further improving the accuracy of the judgment.

It should be noted that the icon of the payment type client mentioned above may be a shortcut icon of the payment type client, or may be an icon of the payment type client obtained from the application list. If the two icon feature values are the same, one of the icons may be selected to calculate the similarity with the icon in the preset icon library; if the two icon feature values are different, the two icons and the pre-calculation may be separately calculated. The similarity of the icons in the icon gallery.

After determining, according to the matching result, whether the payment client is a malicious client, the step S108 further processes the payment client according to the determination result. For example, if the judgment result is a non-malicious client of the payment client, the user may be reminded that the payment client is a genuine payment client, or the current payment is made. Environmental safety, and more. If the judgment result is a malicious client or an unknown client of the payment client, the user may be reminded that the payment client is a fake payment client, and it is recommended to install a genuine payment client, or the current payment environment is dangerous, and the like. Further, the processing command from the user may also be received, wherein the processing command is determined by the user according to the determination result, and then the payment type client is processed according to the processing command.

Correspondingly, FIG. 2 shows a flow chart of a method for protecting mobile payment security on the cloud server side according to an embodiment of the present invention. As shown in FIG. 2, the method includes at least the following steps S202 to S210.

Step S202: Receive a query request from the mobile terminal to query whether the payment terminal client of the mobile terminal is a malicious client, where the query request carries an icon of the payment client.

Step S204: Calculate the similarity between the icon of the payment client and the icon in the preset icon library, and determine an icon in the icon library that has a similarity greater than or equal to a preset threshold.

Step S206: Query the known payment type client corresponding to the determined icon according to the mapping relationship between the icon in the preset icon library and the known payment type client.

Step S208: Determine whether the known payment client is a malicious client, and obtain a judgment result.

Step S210: The judgment result is used as a result of the inquiry of whether the payment client is a malicious client, and is sent to the mobile terminal.

In the above step S210, if the payment client is a non-malicious client, the result of the query is that the payment client is a non-malicious client; if the payment client is known as a malicious client, the query result is a payment class. The client is a malicious client.

Further, if the payment client is determined to be a malicious client according to the feature information in the whitelist, and the cloud server determines that the payment client is a non-malicious client (the possible reason is that the payment client is upgraded and moved) The whitelist library on the terminal is not updated in time), that is, there is a false positive situation, and the cloud server can send the false alarm information to the mobile terminal, correct it in time, and improve the accuracy of the judgment. In addition, if the cloud server queries the payment client as a malicious client, the query result may also carry information such as an installation package or a download address of the payment client that can securely perform the payment operation. Further, the cloud server updates the preset icon library in real time, thereby further improving the accuracy of the judgment.

The various implementations of the various steps in the embodiments shown in FIG. 1 and FIG. 2 are described above. The mobile payment security protection method provided by the embodiment of the present invention is further described below through a specific preferred embodiment.

Embodiment 1

FIG. 3 illustrates another flow chart of a method for protecting mobile payment security on the mobile terminal side according to an embodiment of the present invention. In this embodiment, the similarity of the icon is used to effectively identify the counterfeit client that fakes the name of the genuine payment client and highly simulates the icon of the genuine payment client, and processes it in time. As shown in FIG. 3, the method includes the following steps S302 to S316.

Step S302: When the event of starting the payment client of the mobile terminal is detected, the name and icon of the payment client are obtained.

Step S304: Find, by using a pre-established name index, an icon corresponding to the obtained name in the white list.

Step S306: Calculate the similarity between the obtained icon and the icon found in the white list.

Step S308, determining whether the similarity calculated in step S306 is greater than or equal to a preset threshold, and if yes, proceeding to step S310; otherwise, proceeding to step S312.

Step S310: Determine that the payment client is a non-malicious client, and continue to step S314.

Step S312: Determine that the payment client is a malicious client or an unknown client, and continue to step S316.

In step S306 to step S312, if there are 10 icons found in the white list, first calculate the similarity between the obtained icon and one of the icons, and if the similarity is greater than or equal to a preset threshold (such as 99.5%), it may be determined. The payment client is a non-malicious client; otherwise, it continues to calculate the similarity between the acquired icon and the next icon. If the similarity between the obtained icon and the 10 icons in the preset whitelist is less than a preset threshold, it may be determined that the payment client is a malicious client or an unknown client.

Step S314: No processing is performed, and the user is reminded that the payment client is a genuine payment client, and the payment operation can be performed.

Step S316, deleting the payment type client, and reminding the user to install the genuine payment type client.

In the first embodiment, the fake client pretending to be a genuine payment client counterfeits the name of the genuine payment client, and highly simulates the icon of the genuine payment client, so that the user is difficult to distinguish, and the user uses the payment client. When leaking private information, it causes serious economic losses. The technical means can effectively identify the fake client masquerading as a genuine payment client, and then process it, improve the security of the payment client on the mobile terminal, and provide a safe and clean mobile payment environment for the user.

Embodiment 2

FIG. 4 shows a third flow chart of a method for protecting mobile payment security on the mobile terminal side according to an embodiment of the present invention. In this embodiment, the payment information client whose name is unchanged, the signature is changed, and the Trojan horse and the virus program are packaged twice is effectively identified by using the signature information, and is processed in time. As shown in FIG. 4, the method includes the following steps S402 to S414.

Step S402: When the event of installing the mobile terminal payment class client is monitored, the name and signature of the payment class client are obtained.

Step S404: Search for a signature corresponding to the obtained name in the whitelist by using a pre-established name index.

Step S406, determining whether the acquired signature is the same as the signature found in the whitelist, and if yes, proceeding to step S408; otherwise, proceeding to step S410.

Step S408: Determine that the payment client is a non-malicious client, and continue to step S412.

Step S410: Determine that the payment client is a malicious client or an unknown client, and continue to step S414.

Step S412: No processing is performed, and the user is reminded that the payment client is a genuine payment client, and the payment operation can be performed.

Step S414, deleting the payment type client, and reminding the user to install the genuine payment type client.

In the second embodiment, since the name of the payment client that has been packaged by the Trojan and the virus program is generally unchanged, but the signature has changed, the technical means can be used to effectively identify the Trojan horse and the virus program. The payment client is processed to improve the security of the payment client on the mobile terminal, and the protection against malicious attacks such as viruses and Trojans is enhanced, thereby preventing theft, misappropriation and the like of user privacy, traffic, and call charges.

Embodiment 3

FIG. 5 illustrates a flow chart of a method of securing mobile payment security in conjunction with a mobile terminal and a cloud server, in accordance with one embodiment of the present invention. As shown in FIG. 5, the method includes the following steps S502 to S518.

Step S502: When the event of starting the payment client of the mobile terminal is detected, the package name, MD5, and SHA1 of the payment client are obtained.

Step S504: Send a query requesting whether the payment type client is a malicious client to the cloud server, where the query request carries the package name, MD5, and SHA1 of the payment client.

Step S506: The cloud server receives, from the mobile terminal, a query request for querying whether the payment terminal client of the mobile terminal is a malicious client, and the query request carries the package name, MD5, and SHA1 of the payment client.

Step S508: The cloud server searches for the MD5 and SHA1 corresponding to the obtained package name in the whitelist by using the pre-established package name index.

In step S510, the cloud server determines whether the acquired MD5 and SHA1 are the same as the MD5 and SHA1 found in the whitelist. If the obtained MD5 is the same as the MD5 found in the whitelist, and the obtained SHA1 and the SHA1 found in the whitelist are obtained, If yes, proceed to step S512; if the acquired MD5 is the same as the MD5 found in the whitelist, and the obtained SHA1 is different from the SHA1 found in the whitelist, proceed to step S514; if the acquired MD5 and white The MD5s found in the list are different, and the obtained SHA1 is the same as the SHA1 found in the whitelist. Then, the process proceeds to step S514; if the obtained MD5 is different from the MD5 found in the whitelist, and the acquired SHA1 and white are obtained. If the SHA1 found in the list is also different, step S514 is continued.

In step S512, the payment client is determined to be a non-malicious client, and sent to the mobile terminal, and the process proceeds to step S516.

Step S514: Determine that the payment client is a malicious client or an unknown client, and send the message to the mobile terminal, and continue to step S518.

Step S516: No processing is performed, and the user is reminded that the payment client is a genuine payment client, and the payment operation can be performed.

Step S518, deleting the payment type client, and reminding the user to install the genuine payment type client.

In the third embodiment, the mobile terminal and the cloud server are combined, and the feature information is used to flexibly and effectively identify a fake client that is pretending to be a genuine payment client or a payment client that is packaged with a Trojan or a virus program twice, and It is processed in a timely manner.

Embodiment 4

FIG. 6 illustrates another flow chart of a method of securing mobile payment security in conjunction with a mobile terminal and a cloud server, in accordance with one embodiment of the present invention. In this embodiment, if the payment client is a malicious client or an unknown client, the similarity between the icon of the payment client and the icon in the preset icon library may be used. Further judgment. As shown in 6, the method includes the following steps S602 to S614.

Step S602: The mobile terminal acquires an icon of the payment type client.

Step S604: Send a query requesting whether the payment type client is a malicious client's query request to the cloud server, where the query request carries an icon of the payment type client.

Step S606: Receive a query request from the mobile terminal to query whether the payment terminal client of the mobile terminal is a malicious client, where the query request carries an icon of the payment client.

Step S608: The cloud server calculates the similarity between the icon of the payment class client and the icon in the preset icon library, and determines an icon in the icon library that has a similarity greater than or equal to a preset threshold.

Step S610: The cloud server queries the known payment client corresponding to the determined icon according to the mapping relationship between the icon in the preset icon library and the known payment client.

Step S612: Determine whether the known payment client is a malicious client, and obtain a judgment result.

Step S614: The judgment result is used as a result of the inquiry of whether the payment client is a malicious client, and is sent to the mobile terminal.

In this step, if the payment client is known as a non-malicious client, the result of the query is that the payment client is a non-malicious client; if the payment client is known as a malicious client, the query result is a payment class. The client is a malicious client. Further, if the payment client is a non-malicious client, the process is not processed, and the user is reminded that the payment client is a genuine payment client, and the payment operation can be performed. If the payment client is a malicious client, the payment client is deleted, and the user is prompted to install a genuine payment client.

If the payment type client is determined to be a malicious client according to the feature information in the white list, and the cloud server determines that the payment client is a non-malicious client (the possible reason is that the payment client is upgraded, and the mobile terminal is The whitelist library is not updated in time), that is, there is a false positive situation, and the cloud server can send the false alarm information to the mobile terminal, correct it in time, and improve the accuracy of the judgment. In addition, if the cloud server queries the payment client as a malicious client, the cloud server may also send an installation package or a download address of the payment client that can securely complete the payment operation to the mobile terminal. Further, the cloud server updates the preset icon library in real time, thereby further improving the accuracy of the judgment.

It should be noted that, in an actual application, all the foregoing optional embodiments may be combined in any combination to form an optional embodiment of the present invention, and details are not described herein again.

Based on the same inventive concept, the embodiment of the present invention further provides a mobile payment security protection device to implement the above mobile payment security protection method.

FIG. 7 is a schematic structural diagram of a mobile payment security protection apparatus on a mobile terminal side according to an embodiment of the present invention. Referring to FIG. 7, the apparatus at least includes: an obtaining module 710, a matching module 720, a first determining module 730, and a processing module 740.

The functions of the components or devices of the mobile payment security protection device and the connection relationship between the components of the mobile payment security protection device of the embodiment of the present invention are now introduced:

The obtaining module 710 is configured to: when the triggering event of the payment terminal of the mobile terminal is monitored, obtain the feature information of the payment class client, where the feature information refers to the unique identity information of the payment class client;

The matching module 720 is coupled to the acquiring module 710, and configured to match the acquired feature information with the feature information in the preset whitelist to obtain a matching result, where the whitelist includes a mobile terminal capable of performing payment operation securely. Characteristic information of the payment class client;

The first determining module 730 is coupled to the matching module 720, and configured to determine, according to the matching result, whether the payment client is a malicious client;

The processing module 740 is coupled to the first determining module 730 and configured to process the payment client according to the determination result.

In an embodiment of the present invention, the feature information may include at least one of the following: name, icon, package name, signature, version information, message digest algorithm MD5, secure hash algorithm SHA1, file size, file Modify time, file creation time.

In an embodiment of the present invention, the first determining module 730 may be further configured to: if the acquired feature information exists in the whitelist, determine that the payment client is a non-malicious client; if the acquired feature information does not exist in the white In the list, determine that the payment class client is a malicious client or an unknown client.

In an embodiment of the present invention, the device shown in FIG. 7 may further include a second determining module 750, coupled to the first determining module 730, configured to: obtain an icon of a payment client, where the payment client is An unknown client; calculating the similarity between the acquired icon and the icon in the preset icon library; determining an icon in the icon library with a similarity greater than or equal to a preset threshold; according to the icon in the preset icon library and the known payment The mapping relationship between the class clients, the known payment type client corresponding to the icon determined by the query; if the known payment type client is a non-malicious client, the payment client is determined to be a non-malicious client; The known payment client is a malicious client, and the payment client is determined to be a malicious client.

In an embodiment of the present invention, the second determining module 750 may be further configured to: obtain an icon of the payment type client, where the payment type client is an unknown client; and send a query requesting whether the payment type client is a malicious client. To the cloud server, wherein the query request carries an icon of the payment type client; and receives the query result returned by the cloud server.

In one embodiment of the invention, the acquired icon includes a shortcut icon of the payment class client and/or an icon of the payment class client obtained from the application list.

In an embodiment of the present invention, the second determining module 750 is further configured to: zoom the acquired icon and the icon in the preset icon library to the same size; by comparing the zoomed acquired icon with the preset The icon in the icon library corresponds to the pixel of the position, and the similarity is obtained.

In an embodiment of the invention, the triggering event of the payment class client includes at least one of the following:

Install a payment class client;

Start the payment class client;

Scan the payment class client;

Update the payment class client.

Correspondingly, FIG. 8 shows a schematic structural diagram of a cloud server according to an embodiment of the present invention. Referring to FIG. 8 , the cloud server includes at least a request receiving module 810, a computing module 820, a query module 830, a third determining module 840, and a sending module 850.

The functions of the components or devices of the cloud server and the connection relationship between the components of the cloud server according to the embodiment of the present invention are introduced:

The request receiving module 810 is configured to receive, from the mobile terminal, a query request for querying whether the payment terminal client of the mobile terminal is a malicious client, where the query request carries an icon of the payment client;

The computing module 820 is coupled to the request receiving module 810, configured to calculate a similarity between the icon of the payment client and the icon in the preset icon library, and determine an icon in the icon library that has a similarity greater than or equal to a preset threshold;

The query module 830 is coupled to the computing module 820, and configured to query the known payment client corresponding to the determined icon according to the mapping relationship between the icon in the preset icon library and the known payment client;

The third determining module 840 is coupled to the query module 830, and configured to determine whether the known payment client is a malicious client, and obtain a determination result;

The sending module 850 is coupled to the third determining module 840, and configured to use the result of the determination as a result of the query of the payment client as a malicious client, and send the result to the mobile terminal.

In an embodiment of the present invention, the sending module 850 may be further configured to: if the payment client is known as a non-malicious client, the query result is that the payment client is a non-malicious client; if the payment client is known For a malicious client, the result of the query is that the payment client is a malicious client.

In one embodiment of the invention, the icon of the payment class client includes a shortcut icon of the payment class client and/or an icon of the payment class client obtained from the application list.

In an embodiment of the present invention, the information carried in the query result includes at least one of the following:

An installation package for a payment client that can securely perform payment class operations;

The download address of the payment client that can securely complete the payment class operation.

According to any one of the preferred embodiments or the combination of the preferred embodiments, the embodiment of the present invention can achieve the following beneficial effects:

Further, the mobile terminal and the cloud server may determine whether the payment client is a malicious client or a non-malicious client according to the similarity between the icon of the payment client and the icon in the preset icon library, so as to achieve more accurate implementation. Judge. If the payment type client is determined to be a malicious client according to the feature information in the white list, and the cloud server determines that the payment client is a non-malicious client (the possible reason is that the payment client is upgraded, and the mobile terminal is The whitelist library is not updated in time), that is, there is a false positive situation, and the cloud server can send the false alarm information to the mobile terminal, correct it in time, and improve the accuracy of the judgment. In addition, if the cloud server queries the payment client as a malicious client, the cloud server may also send an installation package or a download address of the payment client that can securely complete the payment operation to the mobile terminal. Further, the cloud server updates the preset icon library in real time, thereby further improving the accuracy of the judgment.

Further, according to an embodiment of the present invention, a secure payment method and apparatus for a mobile terminal are also provided.

The embodiment of the invention provides a secure payment method for a mobile terminal, which is applied to a mobile terminal. FIG. 9 is a flowchart showing the processing of a secure payment method of a mobile terminal according to an embodiment of the present invention. Referring to FIG. 9, the flow includes at least steps S902 to S906.

In step S902, when it is detected that the payment type client installed in the mobile terminal is started, the identity identification information of the payment type client is acquired. In the embodiment of the present invention, the identity information of the payment client may be any information that can identify the identity of the payment client, for example, the package name information of the payment client, the version information of the payment client, and/or the payment client. The signature information of the end. The payment type client is a payment type software installed on the mobile terminal.

After obtaining the identity information of the payment client, step S904 is performed to determine whether the security of the payment client is verified according to the identity information of the payment client, and after the security of the payment client is verified, the payment class is used. The client performs a payment operation (ie, step S906).

As mentioned above, in the embodiment of the present invention, it is determined whether the security of the payment client is verified by obtaining the identity information of the payment client. In addition, the embodiment of the present invention may also preferably detect the running environment of the payment client and/or the payment client according to a preset rule when the payment client is downloaded and/or the payment client is started.

Specifically, when detecting the running or downloading environment of the payment client, when the user downloads the payment client or starts the payment client, the network used (such as wireless network wifi) may be a public place network, security. Lower. Moreover, when downloading or running a payment client using a less secure network such as a public place network, the criminals can easily tamper with the local domain name system (DNS), resulting in the downloaded payment client. The end is a phishing payment client (such as a payment client masquerading as a common payment client to illegally obtain user information), or when the payment client is started, since the local DNS has been illegally tampered with, the user actually inputs the information. The interface may be an interface that steals user information after the local DNS has been tampered with.

Therefore, in detecting the operation or download environment of the payment client, the embodiment of the present invention preferably detects the security of the network used. If the network is detected as a network with security risks, the user is prompted to use the current network to download or run the payment client. If the user chooses to continue using the current network or determines the security of the network after detecting, it is detected whether the local DNS has been changed. If it is determined that the local DNS has been changed, the user is prompted, the local DNS is changed, and the user is asked whether to change the local DNS to a secure DNS. The secure DNS may be a server that has been authenticated by security, and may be a plurality of domain name resolution servers having the qualification of a telecom operator. For example, the domain name of the online shopping website, the domain name of the game website, and the domain name of the social network website are selected from the domain names with a large number of user visits (such as a user access volume exceeding 400 million). Ask the user whether to change the local DNS to a secure DNS, according to the user's input selection command or according to any reception When the triggered operation of the user determines to modify the DNS, the changed DNS is changed to a secure DNS. If the user chooses not to change the DNS or determines that the local DNS has not been changed, the next operation is performed.

The foregoing describes the process of detecting the running or downloading environment of the payment client in the embodiment of the present invention. When detecting the payment client, the embodiment of the present invention preferably performs a virus scanning operation on the payment client. For example, call the setPreInstallListener( ) interface of the QihooAppManager class to register the listener. When receiving the user's instruction through the registered listener and downloading or installing or running the payment client, the embodiment of the present invention does not directly perform the corresponding operation, but first performs a virus scan on the payment client. Then call the resumeOrAbortInstall() interface to decide whether to continue downloading or installing or continuing to run the payment class client.

In addition, when scanning the payment client, the embodiment of the present invention may perform a virus scanning operation on the payment client according to the virus database local to the mobile terminal, and may perform virus scanning on the payment client according to the virus database of the cloud server. The operation may also be based on a local virus database combined with a virus database of the cloud server to perform a more comprehensive virus scanning operation on the payment client.

After detecting the running environment of the payment client and/or the payment client, if the payment client fails the detection, the payment client is determined to be a payment-type client whose security is not verified. For the payment type client that is detected, such as the payment type client whose local DNS is not changed and the virus is not present in the payment type client, obtain the identity information of the payment type client, and determine the payment according to the identity information of the payment type client. Whether the class client security is verified.

Preferably, in the embodiment of the present invention, a predefined security identification library may be set in the mobile terminal local and/or cloud server. The pre-defined security identification library stores identity information of the payment client. That is, the predefined security identification library is a database in which the identity identification information of the payment type client is stored. Therefore, the security identification library is simply referred to as a database below. In addition, in the embodiment of the present invention, the identity identification information of the payment type client stored in the database is classified according to the determination of the security of the known payment type client. For example, the database stores a whitelist of payment-type clients (ie, a list of security-certified payment-type clients), and a blacklist of payment-type clients (ie, a list of payment-type clients whose security is not verified). Further, the identity information of each payment class client is stored in the whitelist and the blacklist of the database. For example, in the database, the payment client A exists in the white list, and the identification information of the payment client A is also stored in the white list.

In the embodiment of the present invention, the identity information of the payment client may include one or a combination of the following: a package name of the payment client, a version number, and a developer signature. In addition, the identity information of the payment client may further include the feature data of the payment client. According to the feature data, the embodiment of the present invention can perform security verification on the payment client with unknown security. The feature data of the payment client includes the identity information of the payment client described above, and may also include a feature of a component broadcast receiver of the payment client, a feature of the service of the payment client, and payment. The characteristics of the component activity of the class client, the instruction or string in the executable file, and the message digest algorithm (MD5 value) of each file in the installation package directory of the payment client. It should be noted that, in the embodiment of the present invention, the executable file includes a Dex type file (including a classes.dex file, a file with a .jar extension, and a file in a Dex format), and/or an ELF type file.

In the embodiment of the present invention, when the security verification of the payment client is performed by using the database, due to the mobile terminal The local space resources are limited. Therefore, the identity information and/or feature data of the payment client stored in the database in the cloud server is more comprehensive. Therefore, preferably, the embodiment of the present invention sends the identity information of the payment client to the cloud server for security verification. The cloud server matches the identity information of the received payment type client in the database storing the identity information of the payment type client through the security verification, and returns a matching result. According to the matching result, the embodiment of the present invention can determine whether the payment type client is a payment type client whose security is verified. Specifically, if the matching result is that the identity information in the database can match the identity information of the payment client, it is determined that the security of the payment client is verified, and if the matching result is the identity information of the received payment client If it is not able to match any of the identity information stored in the database, it is determined that the payment class client security has not passed the verification.

In addition, since the database may also store the identity information of the payment type client whose security is not verified, and the data characteristics of the known malicious payment type client, when verifying the security of the payment type client, The identity information of the payment type client may be matched with the identity information of the payment type client in the database that is not verified by the security. If it is matched, it is determined that the payment type client fails the security verification, and if it does not match Then, according to the data characteristics of the known malicious payment client, whether the fullness of the payment client can be further verified can be verified.

Due to the actual operation, the Trojan horse program, the secondary packaging of the software, and the like are more and more advanced, and only the identity information of the payment client that is not verified according to the known security and the data of the known malicious payment client are known. The feature cannot guarantee that the fake payment client or phishing payment software can be fully detected, and the security client that can pass the verification can determine its security through manual inquiry and other ways. It is added to the database for the user to verify the security of the payment client when downloading or installing or using the payment client. Therefore, in the embodiment of the present invention, the identity information of the payment client is matched with the identity information of the payment client authenticated in the database, and the security of the payment client is verified according to the matching result.

When it is determined that the security of the payment type client is verified, the running state of the payment type client is maintained. If it is determined that the security of the payment client fails to pass the verification, the present prompt message and corresponding processing operation options are displayed. Preferably, the processing operation option in the embodiment of the present invention is displayed in the form of a button, that is, each processing operation option displayed is a corresponding processing button, and when the user triggers the processing operation option, the user can be received at the corresponding processing button. Input instructions. If the trigger instruction input by the user according to the prompt message is received at the processing button, the corresponding processing is performed on the payment client according to the trigger instruction.

In the embodiment of the present invention, the processing button that is displayed when the security of the payment client is not verified may be any button that can trigger the processing of the payment client, which is not limited by the embodiment of the present invention. For example, the processing button may be a termination button, may be an uninstall button, may be a genuine button installed, or may continue to use a button. Correspondingly, if the trigger command of the user is received at the termination button, the running process of the payment client is terminated, and if the trigger command of the user is received at the uninstall button, the payment client is uninstalled, and if the user is received at the genuine button The triggering instruction, uninstalling the payment type client, and installing the genuine payment type client corresponding to the payment type client, if the user receives the trigger instruction at the button, the operation state of the payment type client is maintained.

In the embodiment of the present invention, when it is determined that the security of the payment client fails to pass the verification, the prompt message can be displayed, and various buttons for different processing of the payment client are performed, and the user is received at each button. The triggering instruction performs corresponding processing on the payment client, and the payment client is processed according to the user's selection to ensure that the payment client is performing the wrong uninstallation when the user is prompted to pay the security of the client. Such operations cause user inconvenience. For example, if it is detected according to the preset rule that the installation package of the payment client includes a malicious virus, it is determined that the payment client belongs to an uninstallable application, and the identifier is uninstallable; if the payment client is detected to include an advertisement, The pop-up window, the charge, and the like, classify the payment client according to different contents included in the payment client, and identify that it is uninstallable; if the payment client is detected, the payment client can be determined as the mobile terminal In its own application, the unloading payment client may affect the normal use of the mobile terminal, and then classify and identify the payment client as non-uninstallable; if the payment client is detected, it can determine that the payment client is The mobile terminal's own application, and the offloading payment client does not have a serious impact on the normal use of the mobile terminal, but may cause loss of functionality in the mobile terminal, and the payment class client is classified and identified as a cautious uninstall.

For example, after detecting that the payment client A starts, after detecting the running environment of the payment client A and the payment client A according to the preset rule, determining that the payment client A is the detected payment client After the version information of the payment type client A is sent to the cloud server, and the version information matching the payment type client A does not exist in the database, the embodiment of the present invention determines that the security of the payment type client fails the verification. However, in actual operation, the payment client A may be a newly developed payment client, and the user who starts the payment client A is the first user of the payment client A, and the database does not store the payment. The version information of the client A, but the user can determine that the payment client A does not have a security risk, and the user can ensure that the payment operation is continued by the payment client A by triggering the continue use button described above.

It should be noted that, in the secure payment method of the mobile terminal provided by the embodiment of the present invention, the verification process of the security of the payment client can be applied to the verification process of any software security, and the embodiment of the present invention does not limited.

Embodiment 1

In order to clarify the security payment method of the mobile terminal provided by the foregoing embodiments, a preferred embodiment is provided to introduce a secure payment method of the mobile terminal provided by the embodiment of the present invention. It should be noted that, in order to simplify the present preferred embodiment, in this example, the payment client A is installed in the mobile phone.

FIG. 10 is a flow chart showing the processing of a secure payment method of a mobile terminal in accordance with a preferred embodiment of the present invention. Referring to FIG. 10, the flow includes at least steps S1002 to S1026. It should be noted that, in FIG. 10, the payment client A is simply referred to as a payment client.

Step S1002, detecting a local DNS.

Specifically, when it is detected that the payment type client A is started, it is preferable to detect the network used by the startup payment type client A. When it is detected that the network is a public network, it is determined that the security of the public network is low, and the local DNS is detected.

In step S1004, it is determined whether the local DNS is changed. If it is not changed, step S1012 is directly performed. If the determination is changed, step S1006 is performed.

Step S1006: When it is determined according to step S1004 that the local DNS is changed, the user is prompted to change the local DNS, and the use of the payment client A may have a security risk. For example, displaying a prompt on the phone’s screen Message. In addition, when the prompt message is displayed, it is also possible to display a processing button on the screen, such as displaying a "modify local DNS" button and/or a "keep local DNS unchanged" button.

Step S1008: Determine whether to modify the local DNS according to an instruction input by the user. If yes, go to step S1010, if no, go to step S1012.

Specifically, it is mentioned in step S1006 that when it is determined that the local DNS is changed, a prompt message may be displayed on the screen of the mobile phone, and preferably, a processing button may also be displayed. A trigger command input by the user according to the prompt message is received at the processed processing button. For example, when the user inputs a trigger instruction at the "modify local DNS" button, it is determined to modify the local DNS. When the user inputs a trigger instruction at the "keep local DNS unchanged" button, it is determined that the local DNS remains unchanged, and is not correct. It is modified.

Step S1010: Modify the local DNS as a secure DNS.

When the local DNS is modified according to an instruction input by the user, the local DNS is modified to a secure DNS. The secure DNS may be a server that has been authenticated by security, and may be a plurality of domain name resolution servers having the qualification of a telecom operator. For example, the domain name of the online shopping website, the domain name of the game website, and the domain name of the social website are selected from the domain names with a large number of user visits.

Step S1012, performing a virus scanning operation.

Specifically, after determining that the local DNS has not been changed, or determining that the local DNS is changed, keeping the local DNS unchanged according to an instruction input by the user, or determining that the local DNS is changed, modifying the local DNS to a secure DNS according to an instruction input by the user. After that, a virus scanning operation is performed on the payment client A.

Step S1014: Determine whether a virus exists in the payment client A. If yes, go to step S1024 directly, and if no, go to step S1016.

Step S1016: When it is determined according to step S1014 that there is no virus in the payment client A, the payment client A obtains the identity identification information of the payment client A by detecting. Preferably, the identity information of the payment client A may be the package name information of the payment client A, the version information of the payment client A, and the signature information of the payment client A.

Step S1018: Send the acquired identity information of the payment client A to the cloud server. The cloud server matches the identity information of the payment client A in the database and returns a matching result. In this example, the database stores the identity information of the payment-type client that is authenticated by security.

In step S1020, it is determined whether the security of the payment client A is verified according to the matching result. If yes, step S1022 is performed, and if no, step S1024 is performed.

Specifically, if the matching result is that the identity information in the database can match the identity information of the payment client A, it is determined that the security of the payment client A is verified, and step S1022 is performed; if the matching result is a payment client If the identity information of the terminal A is not matched with any of the identity information stored in the database, it is determined that the security of the payment client A does not pass the verification, and step S1024 is performed.

Step S1022: After the security of the payment client A is verified, the operation of the payment client A is maintained.

Step S1024: After determining that the security of the payment client A has not passed the verification, a prompt message and a processing button are displayed.

In this example, the processing button that is displayed when the security of the payment client A is not verified may be any button that can trigger the processing of the payment client A, which is not limited by the embodiment of the present invention. For example, the processing button may be a termination software button, an uninstall button, a genuine button, or a button.

Step S1026: Perform corresponding processing according to the trigger instruction of the user.

Corresponding to the processing button in step S1024, receiving a trigger instruction input by the user at a different processing button performs a corresponding processing on the payment class client A. For example, if the trigger command of the user is received at the termination button, the running process of the payment type client is terminated, and if the trigger instruction of the user is received at the uninstall button, the payment type client is uninstalled, and if the user is received at the installation genuine button Trigger the command, uninstall the payment client, and install the genuine payment client corresponding to the payment client. If the user receives the trigger command while continuing to use the button, the operation state of the payment client is maintained.

In this example, when it is determined that the payment client security has not passed the verification, the prompt message can be displayed, and various buttons for different processing of the payment client are received, and the payment class is received by receiving the trigger instruction of the user at each button. The client performs the corresponding processing, and the payment client is processed according to the user's choice to ensure that the user is in danger of paying the security of the client, thereby avoiding the user's inconvenience caused by performing the wrong uninstallation on the payment client. .

Based on the secure payment method of the mobile terminal provided by the foregoing preferred embodiments, the embodiment of the present invention provides a secure payment device for a mobile terminal to implement a secure payment method for the mobile terminal.

FIG. 11 is a block diagram showing the structure of a secure payment device of a mobile terminal according to an embodiment of the present invention. Referring to FIG. 11, the secure payment device of the mobile terminal according to the embodiment of the present invention includes at least a monitoring module 1110, an obtaining module 1120, a determining module 1130, and a processing module 1140.

The functions of each device or component of the secure payment device of the mobile terminal of the embodiment of the present invention and the connection relationship between the components are now introduced:

The monitoring module 1110 is configured to monitor a payment type client installed on the mobile terminal to start.

The obtaining module 1120 is coupled to the monitoring module 1110 and configured to obtain the identity information of the payment client. The identity information includes at least one of the following: a package name information of the payment client, a version information of the payment client, and a payment class. The signature information of the client.

The determining module 1130 is coupled to the obtaining module 1120 and configured to determine whether the security of the payment client is verified according to the identity information of the payment client.

The processing module 1140 is coupled to the determining module 1130, and configured to perform a payment operation by using the payment class client if it is determined that the payment type client security is verified.

FIG. 12 is a block diagram showing the structure of a secure payment device of a mobile terminal according to a preferred embodiment of the present invention. Referring to FIG. 12, the secure payment device of the mobile terminal in this example further includes:

The sending module 1150 is configured to send the identity information of the payment client to the cloud server, where the cloud server matches the identity information of the payment client in the database, where the database stores the security client that has passed the security verification. Identification information;

The determining module 1130 is further configured to determine whether the security of the payment class client passes the verification according to the matching result returned by the cloud server.

In a preferred embodiment, the determining module 1130 is further configured to:

If the matching result is that the identity information exists in the database and the identity information of the payment class client Matching, it is determined that the security of the payment client is verified;

If the matching result is that the identity information of the payment client is not able to match any of the identity information stored in the database, it is determined that the payment client security has not passed the verification.

As shown in FIG. 12, in a preferred embodiment, the secure payment device of the mobile terminal further includes:

The detecting module 1160 is configured to: when the payment client is started, detect the running environment of the payment client and/or the payment client according to a preset rule;

The obtaining module 1120 is further configured to filter out the payment type client that passes the detection;

Obtain the identity information of the payment type client that passes the detection.

After detecting the running environment of the payment type client and/or the payment type client according to the preset rule, it is determined that the payment type client that fails the detection is a payment type client whose security has not passed the verification.

In a preferred embodiment, the processing module 1140 is further configured to:

After the determining module 1130 determines that the payment type client security fails the verification, the prompt message and the processing operation option are displayed, so that the user processes the payment processing client according to the prompt message triggering the corresponding processing operation option, wherein the processing operation option includes at least the following One: terminate, uninstall, install genuine, continue to use;

The payment class client performs corresponding processing according to the processing operation option triggered by the user.

In a preferred embodiment, the detecting module 1160 performs a detecting operation on the operating environment of the payment client and/or the payment client according to the preset rule, including at least one of the following:

Detecting whether the local domain name system DNS has been altered;

Perform a virus scan operation on the payment client.

In a preferred embodiment, the detection module 1160 is further configured to:

Perform a virus scan operation on the payment class client according to the virus database in the local virus database and/or the cloud server.

If the detection module 1160 detects that the local DNS is modified and/or there is a virus in the payment client, it is determined that the payment client has not passed the detection.

In the description provided herein, numerous specific details are set forth. However, it can be understood that the present invention The embodiments may be practiced without these specific details. In some instances, well-known methods, structures, and techniques are not shown in detail so as not to obscure the understanding of the description.

Similarly, the various features of the invention are sometimes grouped together into a single embodiment, in the above description of the exemplary embodiments of the invention, Figure, or a description of it. However, the method disclosed is not to be interpreted as reflecting the intention that the claimed invention requires more features than those recited in the claims. Rather, as the following claims reflect, inventive aspects reside in less than all features of the single embodiments disclosed herein. Therefore, the claims following the specific embodiments are hereby explicitly incorporated into the embodiments, and each of the claims as a separate embodiment of the invention.

Those skilled in the art will appreciate that the modules in the devices of the embodiments can be adaptively changed and placed in one or more devices different from the embodiment. The modules or units or components of the embodiments may be combined into one module or unit or component, and further they may be divided into a plurality of sub-modules or sub-units or sub-components. In addition to such features and/or at least some of the processes or units being mutually exclusive, any combination of the features disclosed in the specification, including the accompanying claims, the abstract and the drawings, and any methods so disclosed, or All processes or units of the device are combined. Each feature disclosed in this specification (including the accompanying claims, the abstract and the drawings) may be replaced by alternative features that provide the same, equivalent or similar purpose.

In addition, those skilled in the art will appreciate that, although some embodiments described herein include certain features that are included in other embodiments and not in other features, combinations of features of different embodiments are intended to be within the scope of the present invention. Different embodiments are formed and formed. For example, in the following claims, any one of the claimed embodiments can be used in any combination.

The various component embodiments of the present invention may be implemented in hardware, or in a software module running on one or more processors, or in a combination thereof. It should be understood by those skilled in the art that a microprocessor or a digital signal processor (DSP) can be used in practice to implement a mobile payment security protection device and a cloud server according to an embodiment of the present invention, and a security detection of a mobile terminal input window. Some or all of the functionality of some or all of the components. The invention can also be implemented as a device or device program (e.g., a computer program and a computer program product) for performing some or all of the methods described herein. Such a program implementing the invention may be stored on a computer readable medium or may be in the form of one or more signals. Such signals may be downloaded from an Internet website, provided on a carrier signal, or provided in any other form.

For example, Figure 13 illustrates a computing device that can implement a method of transferring data between intelligent terminals. The computing device conventionally includes a processor 1310 and a computer program product or computer readable medium in the form of a memory 1320. The memory 1320 may be an electronic memory such as a flash memory, an EEPROM (Electrically Erasable Programmable Read Only Memory), an EPROM, a hard disk, or a ROM. Memory 1320 has a storage space 1330 for program code 1331 for performing any of the method steps described above. For example, the storage space 1330 for program code may include respective program codes 1331 for implementing various steps in the above methods, respectively. The program code can be read from or written to one or more computer program products. These computer program products include program code carriers such as hard disks, compact disks (CDs), memory cards or floppy disks. Such computer program products are typically portable or as described with reference to FIG. The fixed storage unit. The storage unit may have a storage segment, a storage space, and the like that are similarly arranged to the storage 1320 in the computing device of FIG. The program code can be compressed, for example, in an appropriate form. Typically, the storage unit includes computer readable code 1331', ie, code that can be read by a processor, such as, for example, 1310, which when executed by a computing device causes the computing device to perform each of the methods described above step.

"an embodiment," or "an embodiment," or "an embodiment," In addition, it is noted that the phrase "in one embodiment" is not necessarily referring to the same embodiment.

It is to be noted that the above-described embodiments are illustrative of the invention and are not intended to be limiting, and that the invention may be devised without departing from the scope of the appended claims. In the claims, any reference signs placed between parentheses shall not be construed as a limitation. The word "comprising" does not exclude the presence of the elements or steps that are not recited in the claims. The word "a" or "an" The invention can be implemented by means of hardware comprising several distinct elements and by means of a suitably programmed computer. In the unit claims enumerating several means, several of these means can be embodied by the same hardware item. The use of the words first, second, and third does not indicate any order. These words can be interpreted as names.

In addition, it should be noted that the language used in the specification has been selected for the purpose of readability and teaching, and is not intended to be construed or limited. Therefore, many modifications and changes will be apparent to those skilled in the art without departing from the scope of the invention. The disclosure of the present invention is intended to be illustrative, and not restrictive, and the scope of the invention is defined by the appended claims.

Claims

A method of protecting mobile payment security, comprising:

Obtaining the feature information of the payment class client when the triggering event of the payment terminal of the mobile terminal is detected, where the feature information refers to the unique identity information of the payment class client;

Matching the obtained feature information with the feature information in the preset whitelist to obtain a matching result, where the whitelist includes feature information of the payment terminal client of the mobile terminal capable of performing the payment type operation securely;

Determining, according to the matching result, whether the payment client is a malicious client;

The payment type client is processed according to the judgment result.
The method according to claim 1, wherein the feature information comprises at least one of: a name, an icon, a package name, a signature, a version information, a message digest algorithm MD5, a secure hash algorithm SHA1, a file size, and a file modification time. , file creation time.
The method according to claim 1 or 2, wherein determining whether the payment client is a malicious client according to the matching result comprises:

If the acquired feature information exists in the whitelist, determining that the payment client is a non-malicious client;

If the acquired feature information does not exist in the whitelist, determine that the payment client is a malicious client or an unknown client.
The method of claim 3, wherein after determining that the payment client is a malicious client or an unknown client, the method further comprises:

Obtaining an icon of the payment class client, where the payment class client is an unknown client;

Calculating the similarity between the obtained icon and the icon in the preset icon library;

Determining, in the icon library, the icon whose similarity is greater than or equal to a preset threshold;

Querying a known payment type client corresponding to the determined icon according to a preset mapping relationship between the icon in the icon library and a known payment type client;

If the known payment type client is a non-malicious client, determining that the payment client is a non-malicious client;

If the known payment type client is a malicious client, the payment client is determined to be a malicious client.
The method of claim 3, wherein after determining that the payment client is a malicious client or an unknown client, the method further comprises:

Obtaining an icon of the payment class client, where the payment class client is an unknown client;

Sending a query requesting whether the payment-type client is a malicious client to the cloud server, where the query request carries an icon of the payment-type client;

Receiving the query result returned by the cloud server.
The method according to claim 4 or 5, wherein the acquired icon comprises a shortcut icon of the payment class client and/or an icon of the payment class client obtained from the application list.
The method according to any one of claims 4 to 6, wherein calculating the similarity between the acquired icon and the icon in the preset icon library comprises:

Scale the acquired icon to the same size as the icon in the preset icon library;

The similarity is obtained by comparing pixels of the position obtained by the scaled acquired icon with the icon in the preset icon library.
The method according to any one of claims 1 to 7, wherein the triggering event of the payment class client comprises at least one of the following:

Installing the payment class client;

Starting the payment class client;

Scanning the payment class client;

Update the payment class client.
A method of protecting mobile payment security, comprising:

Receiving, by the mobile terminal, a query request for querying whether the payment terminal client of the mobile terminal is a malicious client, wherein the query request carries an icon of the payment client;

Calculating an similarity between the icon of the payment client and the icon in the preset icon library, and determining an icon in the icon library that the similarity is greater than or equal to a preset threshold;

Querying a known payment type client corresponding to the determined icon according to a preset mapping relationship between the icon in the icon library and a known payment type client;

Determining whether the known payment client is a malicious client, and obtaining a judgment result;

The judgment result is used as a query result of whether the payment client is a malicious client, and is sent to the mobile terminal.
The method according to claim 9, wherein the result of the determining whether the payment client is a malicious client includes:

If the known payment client is a non-malicious client, the query result is that the payment client is a non-malicious client;

If the known payment client is a malicious client, the query result is that the payment client is a malicious client.
The method according to claim 9 or 10, wherein the icon of the payment class client comprises a shortcut icon of the payment class client and/or an icon of the payment class client obtained from the application list.
The method according to any one of claims 9 to 11, wherein the information carried in the query result comprises at least one of the following:

An installation package of the payment client capable of performing a payment type operation securely;

The payment type client can download the download address of the payment type operation securely.
A secure payment method for a mobile terminal, comprising:

Obtaining, when the payment type client installed on the mobile terminal is started, acquiring the identity identification information of the payment type client, where the identity identification information includes at least one of the following: the package name information of the payment type client, the a version information of the payment client, and signature information of the payment client;

Determining whether the security of the payment client is passed according to the identity information of the payment client verification;

If so, the payment operation is performed by the payment type client.
The method of claim 13, wherein determining whether the security of the payment class client passes the verification according to the identity identification information of the payment class client comprises:

Sending the identity information of the payment client to the cloud server, where the cloud server matches the identity information of the payment client in the database, where the database stores the security verified payment class. The identity information of the client;

Determining whether the payment type client security passes the verification according to the matching result returned by the cloud server.
The method of claim 14, wherein determining whether the payment type client security passes the verification according to the matching result returned by the cloud server comprises:

If the matching result is that the identity information in the database can match the identity information of the payment client, determining that the security of the payment client is verified;

If the matching result is that the identity information of the payment client is not able to match any of the identity information stored in the database, it is determined that the security of the payment client fails verification.
The method according to any one of claims 13 to 15, wherein when the payment client is started, the identity information of the payment client is obtained, including:

When the payment type client is started, the running environment of the payment type client and/or the payment type client is detected according to a preset rule, and the payment type client that passes the detection is selected;

Obtaining identity identification information of the payment type client that is detected.
The method of claim 16, wherein after detecting the operating environment of the payment client and/or the payment client according to a preset rule, the method further includes:

The payment type client that fails the detection is determined to be a payment type client whose security has not passed the verification.
The method according to any one of claims 15 to 17, wherein after determining that the payment type client security fails the verification, the method further comprises:

Displaying a prompt message for the user to process the payment type client according to the prompt message triggering corresponding processing operation option, where the processing operation option includes at least one of the following: terminating, uninstalling, installing genuine, continuing to use;

Performing corresponding processing on the payment class client according to the processing operation option triggered by the user.
The method according to claim 18, wherein performing corresponding processing on the payment class client according to the triggering instruction comprises:

If the user triggers the termination operation, terminating the running process of the payment class client;

If the user triggers the uninstall operation, uninstalling the payment class client;

If the user triggers the installation of the genuine operation, uninstalling the payment client, and installing a genuine payment client corresponding to the payment client;

If the user triggers the continuing use operation, maintaining the running state of the payment class client.
The method according to any one of claims 16 to 19, wherein the detecting operation of the payment type client and/or the payment type client operating environment according to a preset rule comprises at least one of the following:

Detecting whether the local domain name system DNS has been altered;

Performing a virus scanning operation on the payment client.
The method of claim 20, wherein performing a virus scanning operation on the payment class client comprises:

Performing a virus scanning operation on the payment class client according to a local virus database and/or a virus database in the cloud server.
The method according to claim 20 or 21, wherein if it is detected that the local DNS is modified and/or a virus is present in the payment client, it is determined that the payment client has not passed the detection.
A mobile payment security protection device, comprising:

The acquiring module is configured to acquire the feature information of the payment class client when the trigger event of the payment terminal of the mobile terminal is monitored, where the feature information refers to the unique identity information of the payment class client;

The matching module is configured to match the acquired feature information with the feature information in the preset whitelist to obtain a matching result, where the whitelist includes a mobile terminal payment client capable of performing a payment type operation securely. Characteristic information

The first determining module is configured to determine, according to the matching result, whether the payment client is a malicious client;

The processing module is configured to process the payment client according to the determination result.
The apparatus according to claim 23, wherein the feature information comprises at least one of: a name, an icon, a package name, a signature, a version information, a message digest algorithm MD5, a secure hash algorithm SHA1, a file size, and a file modification time. , file creation time.
The apparatus according to claim 23 or 24, wherein the first determining module is further configured to:

If the acquired feature information exists in the whitelist, determining that the payment client is a non-malicious client;

If the acquired feature information does not exist in the whitelist, determine that the payment client is a malicious client or an unknown client.
The device of claim 25, further comprising a second determining module configured to:

Obtaining an icon of the payment class client, where the payment class client is an unknown client;

Calculating the similarity between the obtained icon and the icon in the preset icon library;

Determining, in the icon library, the icon whose similarity is greater than or equal to a preset threshold;

Querying a known payment type client corresponding to the determined icon according to a preset mapping relationship between the icon in the icon library and a known payment type client;

If the known payment type client is a non-malicious client, determining that the payment client is a non-malicious client;

If the known payment type client is a malicious client, the payment client is determined to be a malicious client.
The apparatus of claim 26, wherein the second determining module is further configured to:

Obtaining an icon of the payment class client, where the payment class client is an unknown client;

Sending a query requesting whether the payment-type client is a malicious client to the cloud server, where the query request carries an icon of the payment-type client;

Receiving the query result returned by the cloud server.
The apparatus according to claim 26 or 27, wherein the acquired icon comprises a shortcut icon of the payment class client and/or an icon of the payment class client obtained from the application list.
The apparatus according to any one of claims 26 to 28, wherein the second determining module is further configured to:

Scale the acquired icon to the same size as the icon in the preset icon library;

The similarity is obtained by comparing pixels of the position obtained by the scaled acquired icon with the icon in the preset icon library.
The apparatus according to any one of claims 23 to 29, wherein the triggering event of the payment class client comprises at least one of the following:

Installing the payment class client;

Starting the payment class client;

Scanning the payment class client;

Update the payment class client.
A cloud server that includes:

The request receiving module is configured to receive a query request from the mobile terminal to query whether the payment terminal client of the mobile terminal is a malicious client, where the query request carries an icon of the payment client;

a calculation module, configured to calculate an similarity between an icon of the payment client and an icon in the preset icon library, and determine an icon in the icon library that the similarity is greater than or equal to a preset threshold;

The query module is configured to query, according to a preset mapping relationship between the icon in the icon library and a known payment client, a known payment client corresponding to the determined icon;

The third determining module is configured to determine whether the known payment client is a malicious client, and obtain a determination result;

The sending module is configured to use the judgment result as a query result of whether the payment client is a malicious client, and send the result to the mobile terminal.
The cloud server according to claim 31, wherein the sending module is further configured to:

If the known payment client is a non-malicious client, the query result is that the payment client is a non-malicious client;

If the known payment client is a malicious client, the query result is that the payment client is a malicious client.
The cloud server according to claim 31 or 32, wherein the icon of the payment class client comprises a shortcut icon of the payment class client and/or an icon of the payment class client obtained from the application list.
The cloud server according to any one of claims 31 to 33, wherein the information carried in the query result comprises at least one of the following:

An installation package of the payment client capable of performing a payment type operation securely;

The payment type client can download the download address of the payment type operation securely.
A secure payment device for a mobile terminal, comprising:

a monitoring module configured to monitor a payment type client installed on the mobile terminal to start;

An obtaining module, configured to obtain the identity information of the payment client, where the identity information includes at least one of the following: a package name information of the payment client, version information of the payment client, The signature information of the payment client;

a determining module, configured to determine, according to the identity information of the payment client, whether the security of the payment client is verified;

The processing module is configured to perform a payment operation by using the payment type client if it is determined that the payment type client security is verified.
The apparatus of claim 35, further comprising:

a sending module, configured to send the identity information of the payment client to the cloud server, where the cloud server matches the identity information of the payment client in a database, where the database stores security The identity information of the verified payment client;

The determining module is further configured to determine, according to the matching result returned by the cloud server, whether the security of the payment client is verified.
The apparatus of claim 36, wherein the determining module is further configured to:

If the matching result is that the identity information in the database can match the identity information of the payment client, determining that the security of the payment client is verified;

If the matching result is that the identity information of the payment client is not able to match any of the identity information stored in the database, it is determined that the security of the payment client fails verification.
The apparatus according to any one of claims 35 to 37, further comprising:

The detecting module is configured to detect, when the payment client is started, the operating environment of the payment client and/or the payment client according to a preset rule;

The obtaining module is further configured to filter out the payment type client that passes the detection;

Obtaining identity identification information of the payment type client that is detected.
The apparatus of claim 38, wherein the determining module is further configured to:

After detecting the running environment of the payment type client and/or the payment type client according to a preset rule, the payment type client that fails the detection is determined to be a payment type client whose security has not passed the verification.
The apparatus of any one of claims 37 to 39, wherein the processing module is further configured to:

After the determining module determines that the security of the payment client fails to pass the verification, the prompt message and the processing operation option are displayed, so that the user can process the payment processing client according to the prompt message triggering the corresponding processing operation option, where The processing operation option includes at least one of the following: terminating, uninstalling, installing genuine, continuing to use;

Performing corresponding processing on the payment class client according to the processing operation option triggered by the user.
The apparatus according to any one of claims 38 to 40, wherein the detecting module performs a detecting operation on an operating environment of the payment type client and/or the payment type client according to a preset rule, including at least the following one:

Detecting whether the local domain name system DNS has been altered;

Performing a virus scanning operation on the payment client.
The apparatus of claim 41, wherein the detecting module is further configured to:

Performing on the payment class client according to a local virus database and/or a virus database in the cloud server Virus scanning operation.
The apparatus of claim 41 or 42, wherein the determining module is further configured to:

If the detecting module detects that the local DNS is modified and/or a virus exists in the payment client, it is determined that the payment client fails to pass the detection.
A computer program comprising computer readable code that, when executed on a computing device, causes the computing device to perform the method of any one of claims 1-22.
A computer readable medium storing the computer program of claim 44.