Mobile payment identity authentication method based on digital signature

Through the mobile payment identity authentication method based on digital signature, combined with the device's tracking information and user's behavior information, the transaction digital signature is determined and verified, which solves the problem of low security of existing mobile payment identity authentication and achieves a higher level of Payment security.

CN118780791BActive Publication Date: 2025-02-18BEIJING RUIDA JINXIN TECHNOLOGY CO LTD
View PDF 2 Cites 0 Cited by

Patent Information

Application Number
CN202410814687.6
Authority / Receiving Office
CN · China
Patent Type
Patents(China)
Current Assignee / Owner
Filing Date
2024-06-24
Publication Date
2025-02-18
Estimated Expiration
2044-06-24

AI Technical Summary

Technical Problem

The existing mobile payment identity authentication methods are not very secure and are vulnerable to attacks and theft.

Method used

Using a mobile payment identity authentication method based on digital signature, a transaction digital signature is determined by obtaining the device's tracking information and user's behavior information, and the mobile payment is verified based on the signature.

Benefits of technology

It improves the security of mobile payments and can effectively prevent illegal mobile payments after the account is stolen or the device is lost.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN118780791B_ABST
    Figure CN118780791B_ABST
Patent Text Reader

Abstract

The present invention relates to the field of payment security technology, and in particular to a mobile payment identity authentication method based on digital signature. The method comprises: obtaining device tracking information and user behavior information; wherein the tracking information is used to characterize the identity information of the device, and the behavior information is used to characterize the payment habits of the user; based on the tracking information and the behavior information, determining a transaction digital signature; and verifying the mobile payment based on the transaction digital signature. The method disclosed in the present invention can further improve the security of mobile payment.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] The present application relates to the field of payment security technology, and in particular to a mobile payment identity authentication method based on digital signature. Background Art

[0002] With the rapid development of mobile Internet technology, mobile payment has become an indispensable part of modern life. Users are increasingly using mobile devices such as smartphones to conduct online shopping, transfers, payments and other financial transactions. However, the convenience of mobile payment also brings security risks, especially the security of identity authentication.

[0003] The mobile payment identity authentication methods provided by the existing technology mainly include password-based authentication, biometric-based authentication, and hardware token-based authentication. These methods have improved payment security to a certain extent, but there are still some limitations. For example, password authentication is vulnerable to brute force cracking and social engineering attacks; biometric technology may be affected by environmental factors and forged biometrics; hardware tokens are inconvenient to carry and easy to lose.

[0004] Therefore, the mobile payment identity authentication method provided by the prior art still has the problem of low security. Summary of the invention

[0005] In order to solve the problem that the mobile payment identity authentication method provided by the prior art is not highly secure, the purpose of the present invention is to provide a mobile payment identity authentication method based on digital signature, and the technical solution adopted is as follows:

[0006] In a first aspect, an embodiment of the present application provides a mobile payment identity authentication method based on digital signature, the method comprising:

[0007] Obtaining device tracking information and user behavior information; wherein the tracking information is used to characterize the identity information of the device, and the behavior information is used to characterize the payment habits of the user;

[0008] determining a transaction digital signature based on the tracking information and the behavioral information;

[0009] The mobile payment is verified based on the transaction digital signature.

[0010] In a second aspect, an embodiment of the present application provides a control device for mobile payment identity authentication based on digital signature, the control device comprising:

[0011] A first acquisition module is used to acquire tracking information of a device and behavior information of a user; wherein the tracking information is used to represent the identity information of the device, and the behavior information is used to represent the payment habits of the user;

[0012] A first determination module, configured to determine a transaction digital signature based on the tracking information and the behavior information;

[0013] The first verification module is used to verify the mobile payment based on the transaction digital signature.

[0014] In a third aspect, an embodiment of the present application provides an electronic device, which includes a memory and a processor, wherein the memory stores a computer program that can be run on the processor, and when the processor executes the computer program, the steps in the method provided in the first aspect can be implemented.

[0015] In a fourth aspect, an embodiment of the present application provides a computer-readable storage medium, which stores a computer program. When the computer program is executed by a processor, it can implement the steps in the method provided in the first aspect.

[0016] Through the above settings, in the mobile payment identity authentication method based on digital signature provided in the embodiment of the present application, the tracking information that can characterize the device identity information and the behavior information used to characterize the user's payment behavior are combined to determine the corresponding transaction digital signature. On this basis, the transaction digital signature is used to verify the mobile payment. In this way, if the account login device of the mobile payment changes or the user's mobile payment behavior (the time, place, frequency or amount of the mobile payment, etc.) does not conform to the user's mobile payment habits, the transaction digital signature does not meet the verification requirements and the mobile payment can be rejected. Therefore, in the case where the mobile payment account is stolen and logged into other devices, or the device that logs in the mobile payment account is lost to other areas, the security of mobile payment can be further ensured. Therefore, the mobile payment identity authentication method based on digital signature provided in the embodiment of the present application can further improve the security of mobile payment. BRIEF DESCRIPTION OF THE DRAWINGS

[0017] In order to more clearly illustrate the technical solutions and advantages in the embodiments of the present invention or the prior art, the drawings required for use in the embodiments or the prior art descriptions are briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying creative work.

[0018] Figure 1 A flowchart of a mobile payment identity authentication method based on digital signature provided in an embodiment of the present application;

[0019] Figure 2 for Figure 1 A flow chart for implementing step S12;

[0020] Figure 3 for Figure 2 A flowchart for implementing step S121;

[0021] Figure 4 for Figure 2 A flowchart for implementing step S122;

[0022] Figure 5 A logical schematic diagram of a mobile payment identity authentication method based on digital signature provided in an embodiment of the present application;

[0023] Figure 6 A schematic diagram of the structure of a control device for a mobile payment identity authentication method based on digital signature provided in an embodiment of the present application;

[0024] Figure 7 A hardware entity schematic diagram of an electronic device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0025] In order to further explain the technical means and effects adopted by the present invention to achieve the predetermined invention purpose, the following is a detailed description of the specific implementation method, structure, features and effects of a mobile payment identity authentication method based on digital signature proposed by the present invention in combination with the accompanying drawings and preferred embodiments. In the following description, different "one embodiment" or "another embodiment" does not necessarily refer to the same embodiment. In addition, specific features, structures or characteristics in one or more embodiments may be combined in any suitable form.

[0026] Unless defined otherwise, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this invention belongs.

[0027] A specific scheme of a mobile payment identity authentication method based on digital signature provided by the present invention is described in detail below with reference to the accompanying drawings.

[0028] In the prior art, mobile payment identity authentication methods mainly include password-based identity authentication, biometric-based identity authentication, and hardware token-based identity authentication. These methods have improved payment security to a certain extent, but there are still some limitations. For example, password identity authentication is vulnerable to brute force cracking and social engineering attacks; biometric recognition technology may be affected by environmental factors and forged biometrics; and hardware tokens are inconvenient to carry and easy to lose. Therefore, the mobile payment identity authentication methods provided by the prior art still have the problem of low security.

[0029] In view of this, an embodiment of the present application provides a mobile payment identity authentication method based on digital signature, which can improve the security of mobile payment.

[0030] It should be noted that the mobile payment identity authentication method based on digital signature provided in the embodiment of the present application can be executed by an electronic device, wherein the electronic device can be various types of terminals such as mobile phones, laptops, tablet computers, desktop computers, mobile devices, etc., and can also be implemented as a server. The server can be an independent physical server, or a server cluster or distributed system composed of multiple physical servers, or a cloud server that provides basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communications, middleware services, domain name services, security services, content delivery networks (Content Delivery Network, CDN) and big data and artificial intelligence platforms.

[0031] Figure 1 A flowchart of a mobile payment identity authentication method based on digital signature provided in an embodiment of the present application is shown in FIG. Figure 1 As shown, the method includes steps S11 to S13, wherein:

[0032] Step S11, obtaining the tracking information of the device and the behavior information of the user; wherein the tracking information is used to characterize the identity information of the device, and the behavior information is used to characterize the payment habits of the user.

[0033] It is understandable that the device here refers to the device used by the user for mobile payment, for example, the device can be various types of devices such as a mobile phone, a smart watch or a laptop computer.

[0034] It should be noted that the device tracking information here is used to represent the device's identity information. Different devices have different identity information, and the device tracking information can be used to represent the uniqueness of the device. For example, for a device, generally there are multiple different types of unique identity information, such as the device's IMEI code, MAC address, or device identifier.

[0035] Specifically, the IMEI code is generally a 15-digit number; the MAC address is generally 12 hexadecimal digits; the device identifier varies depending on the device type. For Android devices, the device identifier is generally a 64-bit number.

[0036] On this basis, the above parameters that can characterize the unique identity information of the device can be used to directly or indirectly determine the device information. If the device used by the user for this mobile payment is different from the device used for the previous mobile payment, it means that there may be risks.

[0037] In addition, the user's behavior information can be used to characterize the user's mobile payment habits, such as the time or location when the user usually makes mobile payments. For example, for some users, they are used to using mobile payments in the afternoon or evening. If the time of this mobile payment is in the morning, it means that there may be risks. In addition, some users generally use mobile payments in the range of one city. If the location of this mobile payment is in another city, it means that there may be risks.

[0038] In addition, the user's behavior information may also include the user's mobile payment frequency or the number of mobile payments, the amount of mobile payments, etc.

[0039] It should be noted that in the embodiment of the present application, the tracking information of the device can be obtained by querying the hardware information of the device, and the behavior information of the user can be obtained by querying the history of the user's mobile payment. It should be noted that before querying the hardware information of the device or querying the history of the user's mobile payment, the user's consent or authorization is required.

[0040] Step S12: determining a transaction digital signature based on the tracking information and the behavior information.

[0041] Based on the device tracking information and user behavior information obtained in the above steps, the tracking information and behavior information can be encoded. Furthermore, the above encoding can be used to obtain a transaction digital signature using a digital signature algorithm.

[0042] It should be noted that in the embodiment of the present application, one or some parameters representing the tracking information can be used to determine the transaction digital signature. For example, one, two or more combinations or all combinations of IMEI code, MAC address or device identification code can be used to determine the transaction digital signature. In addition, one or some parameters representing the behavior information can also be used to determine the transaction digital signature. For example, one, two or more combinations or all combinations of the user's mobile payment time range, location range, payment amount, payment frequency or number of payments can be used to determine the transaction digital signature.

[0043] Step S13: verifying the mobile payment based on the transaction digital signature.

[0044] In this way, based on the transaction digital signature determined in the aforementioned steps, the transaction digital signature can be used to verify the mobile payment.

[0045] Specifically, when a user uses mobile payment, the transaction digital signature can be sent together with the payment data to be transmitted. After the recipient receives the transaction digital signature and payment data, the transaction digital signature can be used to authenticate the data. If the verification is successful, it means that the payment data is authentic and valid, and is operated by the user corresponding to the mobile payment account, and mobile payment can be made; if the verification fails, it means that there is a risk and it may not be operated by the user corresponding to the mobile payment account. On this basis, re-verification or additional verification in other ways can be required, such as real-name verification.

[0046] Through the above settings, in the mobile payment identity authentication method based on digital signature provided in the embodiment of the present application, the tracking information that can characterize the device identity information and the behavior information used to characterize the user's payment behavior are combined to determine the corresponding transaction digital signature. On this basis, the transaction digital signature is used to verify the mobile payment. In this way, if the mobile payment account login device changes or the user's mobile payment behavior (the time, place, frequency or amount of mobile payment, etc.) does not conform to the user's mobile payment habits, the transaction digital signature does not meet the verification requirements and the mobile payment can be rejected. Therefore, in the case where the mobile payment account is stolen and logged into other devices, or the device that logs into the mobile payment account is lost to other areas, the security of mobile payment can be further ensured.

[0047] On this basis, the present application embodiment also provides a mobile payment identity authentication method based on digital signature, referring to Figure 2 In this method, the above step S12 can be implemented through steps S121 to S123, wherein:

[0048] Step S121, determining the tracking code of the device based on the tracking information.

[0049] It should be noted that the tracking code of the device can be obtained by encoding according to the tracking information of the device.

[0050] Exemplarily, in an embodiment of the present application, the tracking code of the device can be determined based on one, two, a combination of more than two, or all of the IMEI code, MAC address, or device identification code of the device.

[0051] It is understood that in the embodiment of the present application, the tracking code of the device refers to a string of characters used to represent the identity information of the device. For example, the IMEI code, MAC address or device identification code of the device can be encoded using ASCII encoding rules, ANSI encoding rules, Unicode encoding rules, etc. to obtain the tracking code of the device.

[0052] Step S122: determining the behavior code of the user based on the behavior information.

[0053] In the embodiment of the present application, the user's behavior information may be quantified, and on this basis, the user's behavior information may be encoded to obtain the user's behavior code.

[0054] Specifically, the user's location information when using mobile payment can be quantified according to the center position of the longitude and latitude or the range of the longitude and latitude of the location information when using mobile payment; the number of mobile payments of the user can be quantified according to the time period or frequency of the user's use of mobile payment; the amount of the user's mobile payment can also be quantified according to the maximum, minimum or average amount of the user's mobile payment.

[0055] On this basis, the user's behavior code can be obtained by encoding according to one or more of the above parameters. Specifically, the encoding can be performed with reference to the encoding rules of the tracking code of the aforementioned determination device, or other encoding rules can be used for encoding.

[0056] Step S123, determining the transaction digital signature based on the tracking code and the behavior code.

[0057] Based on the device tracking code and the user's behavior code determined in the previous step, the tracking code and the behavior code can be combined to obtain a new code. For the convenience of description, the new code can be called a signature code. On this basis, by signing the signature code, a transaction digital signature can be obtained.

[0058] On this basis, the present application embodiment also provides a mobile payment identity authentication method based on digital signature, referring to Figure 3 In this method, the above step S121 can be implemented by steps S1211 to S1213, wherein:

[0059] Step S1211: generating a standard matrix of the IMEI code of the device based on the IMEI code of the device.

[0060] The IMEI code is generally a 15-digit number. In order to ensure the standard matrix rule of the IMEI code, a certain digit or certain digits of the IMEI code may be copied and continued to the end of the IMEI code or after a certain digit of the IMEI code.

[0061] On this basis, the IMEI code can be divided to obtain multiple IMEI subcodes, and the multiple IMEI subcodes can be arranged to obtain a matrix, which can be used as a standard matrix of the IMEI code.

[0062] In addition, the above-mentioned multiple IMEI subcodes can also be converted to obtain a standard matrix of IMEI codes. Exemplarily, in some embodiments of the present application, the above-mentioned multiple IMEI subcodes can be binary converted and inversely operated and then arranged to obtain a matrix, which can also be used as the standard matrix of IMEI codes.

[0063] Step S1212: Generate an identification convolution kernel of the device based on the device identifier and MAC address of the device.

[0064] For a device, due to the particularity of the MAC address, a device can only have one unique MAC address. Therefore, the MAC address can also be used to uniquely represent the device.

[0065] On this basis, the MAC address can be used to generate the core of a convolution kernel, and the device identifier can be filled in the remaining parts of the convolution kernel to obtain a convolution kernel, which can be used as the device identification convolution kernel.

[0066] Step S1213, using the identification convolution kernel to perform a convolution operation on the standard matrix and expand it to obtain the tracking code.

[0067] Based on the standard matrix of the IMEI code and the identification convolution kernel of the device determined in the aforementioned steps, the identification convolution kernel can be used to perform convolution operation on the standard matrix and expand it, and the result of the convolution operation and expansion can be used as the tracking code.

[0068] On this basis, in some embodiments of the present application, the above step S1211 can be implemented by the following steps:

[0069] Segmenting the IMEI code to obtain a model approval code, a final assembly code, and a product serial code of the device; wherein the model approval code, the final assembly code, and the product serial code correspond to the first to sixth digits, the seventh to eighth digits, and the ninth to fourteenth digits of the IMEI code, respectively;

[0070] Performing a reverse code operation on the model approval code, the final assembly code, and the product serial code;

[0071] Copy the last digit of the IMEI code and append it to the end of the IMEI code to obtain an updated IMEI code;

[0072] The inverse code of the product serial code, the inverse code of the final assembly code and the inverse code of the model approval code are sequentially connected to the updated IMEI code to obtain an extended serial code;

[0073] Convert each bit of the extended sequence code into a binary format and arrange them to generate a binary matrix;

[0074] The binary matrix is ​​used as the standard matrix.

[0075] Specifically, for the IMEI code, the IMEI code includes the device's model approval code, final assembly code and product serial code. The model approval code corresponds to the 1st to 6th digits of the IMEI code, the final assembly code corresponds to the 7th to 8th digits of the IMEI code, and the product serial code corresponds to the 9th to 14th digits of the IMEI code. It can be understood that the 15th digit of the IMEI code is a check code, which is used to verify the validity of the IMEI code.

[0076] On this basis, the model approval code, final assembly code and product serial code can be inverted. Specifically, the model approval code, final assembly code and product serial code can be converted into binary and then inverted.

[0077] It should be noted that in order to ensure that the number of digits remains unchanged, the model approval code, final assembly code and product serial code can be individually inverted by each digit, so as to obtain the inverse of the corresponding product serial code, the inverse of the final assembly code and the inverse of the model approval code.

[0078] In addition, in the embodiment of the present application, the last digit of the IMEI code may be copied and appended to the IMEI code to obtain an updated IMEI code.

[0079] On this basis, the inverse code of the product serial code, the inverse code of the final assembly code and the inverse code of the model approval code can be sequentially connected to the updated IMEI code to obtain an extended serial code. It can be understood that the length of the extended serial code is 30 bits.

[0080] Furthermore, by performing binary conversion and arranging each bit of the extended sequence code, a 15×16 binary matrix can be generated. In this way, the binary matrix can be used as a standard matrix.

[0081] On this basis, in some embodiments of the present application, the above step S1212 can be implemented by the following steps:

[0082] Grouping the MAC addresses into groups of two bits each, and performing a binary AND operation on the binary form of each group of MAC addresses;

[0083] Performing a binary exclusive OR operation on the results of the binary AND operation of each group of MAC addresses and converting the results into decimal form to obtain a characteristic value of the MAC address;

[0084] The characteristic value of the MAC address is used as the core of the convolution kernel, and the remaining part of the convolution kernel is filled with the device identifier to obtain the identification convolution kernel.

[0085] Specifically, a MAC address can usually be represented as 12 hexadecimal digits or a 48-bit binary number. Due to the particularity of the MAC address, it may contain 0. If the XOR operation is used for direct calculation, the final calculation result may be 0, making it impossible to ensure the particularity of the obtained MAC characteristic value.

[0086] Here, the MAC addresses are divided into groups of two bits, and the values ​​of each group of MAC addresses are subjected to a binary AND operation, so that 0 will not appear.

[0087] On this basis, the binary XOR operation is performed on the result of the binary AND operation of each group of MAC addresses to enhance the specificity of the data. Further, the result of the XOR operation is converted into a decimal form to obtain the characteristic value of the MAC address.

[0088] Specifically, the above description can be understood by referring to the following formula:

[0089]

[0090] Where Ma represents the characteristic value of the MAC address; B represents binary; D represents decimal; B2D represents the binary to decimal function; MAC1 represents the binary form of the first bit of the MAC address, MAC2 represents the binary form of the second bit of the MAC address, and MAC i Represents the binary form of the i-th bit of the MAC address, i∈[1,I]; Represents binary AND operation; Represents the binary exclusive-OR operation.

[0091] On this basis, the characteristic value of the MAC address can be used as the core of the convolution kernel, and the remaining part of the convolution kernel can be filled in sequence with the device identifier to obtain the identification convolution kernel.

[0092] For example, for an Android device, the device identifier is 64 bits, and the device identifier can be divided into 8 groups to fill the remaining part of the convolution kernel. Specifically, the convolution kernel can be generated by referring to the following formula:

[0093]

[0094] Among them, BJ represents the identification convolution kernel, AID i represents the i-th bit of the device identifier, ∑ represents the sum, and Ma represents the characteristic value of the MAC address.

[0095] On this basis, in some embodiments of the present application, the above step S1213 can be implemented by the following steps, specifically:

[0096] Using the identification convolution kernel to perform a convolution operation on the standard matrix to obtain a coding matrix;

[0097] The encoding matrix is ​​grouped, summed, and the ASCII table is queried to obtain the corresponding characters;

[0098] The characters are sorted to obtain the tracking code.

[0099] Here, based on the identification convolution kernel determined in the aforementioned step, a convolution operation is performed on the standard matrix of the device and it is unfolded, so that a coding matrix after the convolution operation can be obtained.

[0100] Specifically, the above description can be understood by referring to the following formula:

[0101] B = BJ*S;

[0102] Among them, B represents the encoding matrix; BJ represents the identification convolution kernel; S represents the standard matrix of the IMEI code of the device.

[0103] On this basis, the corresponding characters can be obtained by grouping the encoding matrix, summing it up and querying the ASCII table.

[0104] For example, for a standard binary matrix of 15×16, the tracking code of the device can be obtained by the following formula:

[0105] MB={ASCII -1 (B1+…+B 15 ), ..., ASCII -1 (B 226 +…+B 240 )};

[0106] MB represents the tracking code of the device; ASCII -1 () indicates a table lookup function, which uses the value in the brackets to query the ASCII table to get the corresponding character; B i Represents the i-th bit of the encoding matrix after the convolution operation. In this way, the tracking code of the device can be obtained.

[0107] In addition, refer to Figure 4 In some embodiments of the present application, the above step S122 can be implemented by steps S1221 to S1222, wherein:

[0108] Step S1221, obtaining the user's historical payment location information, dividing the user's payment range, and determining the user's payment range information;

[0109] Since mobile payment is carried out on a user-by-user basis, the user's mobile payment behavior can also be used to characterize the user's identity.

[0110] Specifically, the user's historical payment location information can be obtained and analyzed to determine the center position of the user's historical payment location, and the average distance or maximum distance between the historical payment location and the center position.

[0111] On this basis, the user's payment range information can be characterized by the average distance between the historical payment location and the central location.

[0112] Step S1222: determining the behavior code based on the payment scope information and the user's payment behavior data.

[0113] It should be noted that the user's payment behavior data can be characterized by the number of transactions and payment amounts of the user within a certain period of time.

[0114] In this way, encoding is performed on the basis of the user's payment behavior data in the user's payment range information set, and the behavior code can be determined.

[0115] On this basis, in some embodiments of the present application, the above step S1221 can be implemented by the following steps, specifically:

[0116] Obtain the latitude and longitude information of the location of the user's historical payment to determine the center of the user's payment range;

[0117] Based on the center of the payment range, an average distance between the user's payment position and the center of the payment range is determined, and the average distance is used as the user's payment range.

[0118] It should be noted that by analyzing the historical data of the user's location when using mobile payment, the center of the user's payment range can be determined.

[0119] Exemplarily, the center of the user's payment range may be determined by referring to the following formula:

[0120]

[0121] Where X represents the horizontal coordinate of the center of the user's payment range; Y represents the horizontal coordinate of the center of the user's payment range; n represents the number of times the user has paid; i represents the i-th payment by the user; x i The horizontal coordinate of the latitude and longitude of the user’s geographical location when making the i-th payment; y i The vertical coordinate representing the longitude and latitude information of the geographical location at the time of the i-th payment.

[0122] On this basis, the average distance between the location of the user's historical payments and the center of the payment range can be determined.

[0123] Exemplarily, the above average distance may be determined by referring to the following formula:

[0124]

[0125] Where d represents the user's activity range, that is, the average distance between the user's historical payment location and the center of the payment range; X represents the horizontal coordinate of the center of the user's payment range; Y represents the horizontal coordinate of the center of the user's payment range; n represents the number of payments made by the user; i represents the i-th payment made by the user; x represents the number of payments made by the user; and i represents the horizontal coordinate of the longitude and latitude information of the user’s geographical location at the time of the i-th payment; yi represents the vertical coordinate of the longitude and latitude information of the geographical location at the time of the i-th payment.

[0126] On this basis, in the embodiment of the present application, the above step S1222 can be implemented by the following steps, specifically:

[0127] Get the average payment distance of the user in the first time;

[0128] Get the average amount of the user's first payment;

[0129] Multiplying the average value of the payment distance by the abscissa corresponding to the center of the payment range to obtain a first coding coefficient;

[0130] Multiplying the average value of the payment amount by the ordinate corresponding to the center of the payment range to obtain a second coding coefficient;

[0131] The first coding coefficient and the second coding coefficient are summed and then hash-coded to obtain the behavior code.

[0132] Exemplarily, the first time mentioned above may be 24 hours. For this, the above description may be understood with reference to the following formula:

[0133]

[0134] Among them, U represents behavior coding; Hash() represents hash coding; d i represents the average payment distance of users in the i-th time period; n i Indicates the number of transactions of the user in the i-th time period; m i represents the average amount of payment of the user in the i-th time period; X represents the abscissa of the center of the user's payment range; Y represents the abscissa of the center of the user's payment range.

[0135] In this way, the hash algorithm can be used to perform data summary on the obtained data to obtain the user's behavior code.

[0136] In the method provided in the embodiment of the present application, the transaction characteristics of the user can be extracted using the transaction behavior data of the user. For the user, the transaction and transaction scope of the mobile payment under normal circumstances will not change much. Therefore, the transaction behavior data of the user can be used for feature analysis, and the transaction behavior of the user can be uniquely represented. The content summary can be used to further ensure its uniqueness while meeting the coding fusion requirements of the digital signature.

[0137] In addition, in some embodiments of the present application, the above step S123 can be implemented by the following steps, wherein:

[0138] The tracking code and the behavior code are data-fused to obtain a signature code;

[0139] The signature code is signed to determine the transaction digital signature.

[0140] Specifically, in an embodiment of the present application, after obtaining the tracking code of the device and the behavior code of the user, the tracking code of the device and the behavior code of the user can be merged to obtain the signature code.

[0141] On this basis, the digital signature algorithm can be used to sign the signature code to obtain the transaction digital signature, for example, the DSA digital signature algorithm can be used.

[0142] It should be noted that in the embodiment of the present application, in addition to determining the signature code based on the device's tracking code and the user's behavior code, the signature code can also be determined based on the above two combined with the user's key.

[0143] For example, refer to Figure 5 , is a flow chart of a mobile payment identity authentication method based on digital signature provided in an embodiment of the present application, such as Figure 5 As shown, in the embodiment of the present application, the code decomposition can be performed according to the tracking information of the device to obtain the standard matrix of the IMEI code and the identification convolution kernel of the device. On this basis, the identification convolution kernel can be used to perform convolution operation on the standard matrix to obtain the tracking code of the device. At the same time, the location information of the user's historical payment and the user's payment behavior data can be determined according to the user's behavior information, and on this basis, the user's behavior code can be determined.

[0144] Furthermore, the signature code can be obtained based on the device's tracking code and the user's behavior code. Finally, the signature code is signed to determine the transaction digital signature.

[0145] In addition, the present application also provides a control device for mobile payment identity authentication based on digital signature, referring to Figure 6 The control device 600 for mobile payment identity authentication based on digital signature includes:

[0146] The first acquisition module 601 is used to acquire the tracking information of the device and the behavior information of the user; wherein the tracking information is used to represent the identity information of the device, and the behavior information is used to represent the payment habits of the user.

[0147] A first determination module 602, configured to determine a transaction digital signature based on the tracking information and the behavior information;

[0148] The first verification module 603 is used to verify the mobile payment based on the transaction digital signature.

[0149] The description of the above device embodiment is similar to the description of the above method embodiment, and has similar beneficial effects as the method embodiment. In some embodiments, the functions or modules included in the device provided in the embodiment of the present application can be used to execute the method described in the above method embodiment. For technical details not disclosed in the device embodiment of the present application, please refer to the description of the method embodiment of the present application for understanding.

[0150] It should be noted that in the embodiment of the present application, if the above method is implemented in the form of a software function module and sold or used as an independent product, it can also be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the embodiment of the present application can be essentially or partly reflected in the form of a software product that contributes to the relevant technology. The software product is stored in a storage medium, including a number of instructions to enable an electronic device (which can be a personal computer, server, network equipment or vehicle-mounted computer, etc.) to execute all or part of the methods of each embodiment of the present application. The aforementioned storage medium includes: various media that can store program codes, such as a U disk, a mobile hard disk, a read-only memory (ROM), a disk or an optical disk. In this way, the embodiment of the present application is not limited to any specific hardware, software or firmware, or any combination of hardware, software and firmware.

[0151] An embodiment of the present application also provides an electronic device, which includes a processor, a memory, a communication interface and a communication bus, wherein the memory stores a computer program that can be run on the processor, and when the processor executes the program, some or all of the steps in the above method are implemented.

[0152] The embodiment of the present application also provides a computer-readable storage medium on which a computer program is stored, and when the computer program is executed by a processor, some or all of the steps in the above method are implemented. The computer-readable storage medium can be transient or non-transient.

[0153] An embodiment of the present application also provides a computer program, including a computer-readable code. When the computer-readable code runs in an electronic device, a processor in the electronic device executes some or all of the steps in the above method.

[0154] The present application also provides a computer program product, which includes a non-transitory computer-readable storage medium storing a computer program, and when the computer program is read and executed by a computer, some or all of the steps in the above method are implemented. The computer program product can be implemented specifically by hardware, software, or a combination thereof. In some embodiments, the computer program product is specifically embodied as a computer storage medium, and in other embodiments, the computer program product is specifically embodied as a software product, such as a software development kit (SDK), etc.

[0155] It should be noted here that the description of the various embodiments above tends to emphasize the differences between the various embodiments, and the same or similar aspects can be referenced to each other. The description of the above device, storage medium, computer program and computer program product embodiments is similar to the description of the above method embodiment, and has similar beneficial effects as the method embodiment. For technical details not disclosed in the embodiments of the device, storage medium, computer program and computer program product of this application, please refer to the description of the method embodiment of this application for understanding.

[0156] It should be noted that, refer to Figure 7 , is a schematic diagram of the hardware entity of the electronic device in the embodiment of the present application, such as Figure 7 As shown, the hardware entity of the electronic device 700 includes: a processor 701, a communication interface 702, a memory 703 and a communication bus 704, wherein:

[0157] The processor 701 generally controls the overall operation of the electronic device 700;

[0158] The communication interface 702 and the communication bus 704 may enable the electronic device 700 to communicate with other terminals or servers via a network;

[0159] The memory 703 is configured to store instructions and applications executable by the processor 701, and can also cache data to be processed or processed by the processor 701 and each module in the electronic device 700 (for example, image data, audio data, voice communication data, and video communication data), which can be implemented by flash memory (FLASH) or random access memory (Random Access Memory, RAM). Data transmission can be performed between the processor 701, the communication interface 702, and the memory 703 through the bus 704.

[0160] It should be understood that "one embodiment" or "an embodiment" mentioned throughout the specification means that specific features, structures or characteristics related to the embodiment are included in at least one embodiment of the present application. Therefore, "in one embodiment" or "in an embodiment" appearing throughout the specification does not necessarily refer to the same embodiment. In addition, these specific features, structures or characteristics can be combined in one or more embodiments in any suitable manner. It should be understood that in various embodiments of the present application, the size of the serial number of each step / process mentioned above does not mean the order of execution, and the execution order of each step / process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiment of the present application. The serial numbers of the embodiments of the present application mentioned above are for description only and do not represent the advantages and disadvantages of the embodiments.

[0161] It should be noted that, in this article, the terms "include", "comprises" or any other variations thereof are intended to cover non-exclusive inclusion, so that a process, method, article or device including a series of elements includes not only those elements, but also other elements not explicitly listed, or also includes elements inherent to such process, method, article or device. In the absence of further restrictions, an element defined by the sentence "comprises a ..." does not exclude the existence of other identical elements in the process, method, article or device including the element.

[0162] In the several embodiments provided in the present application, it should be understood that the disclosed devices and methods can be implemented in other ways. The device embodiments described above are only schematic. For example, the division of units is only a logical function division. There may be other division methods in actual implementation, such as: multiple units or components can be combined, or can be integrated into another system, or some features can be ignored or not executed. In addition, the coupling, direct coupling, or communication connection between the components shown or discussed can be through some interfaces, and the indirect coupling or communication connection of devices or units can be electrical, mechanical or other forms.

[0163] The units described above as separate components may or may not be physically separated, and the components displayed as units may or may not be physical units; they may be located in one place or distributed on multiple network units; some or all of the units may be selected according to actual needs to achieve the purpose of the present embodiment.

[0164] In addition, all functional units in the embodiments of the present application may be integrated into one processing unit, or each unit may be a separate unit, or two or more units may be integrated into one unit; the above-mentioned integrated units may be implemented in the form of hardware or in the form of hardware plus software functional units.

[0165] A person skilled in the art can understand that all or part of the steps of implementing the above method embodiment can be completed by hardware related to program instructions, and the aforementioned program can be stored in a computer-readable storage medium. When the program is executed, it executes the steps of the above method embodiment; and the aforementioned storage medium includes: mobile storage devices, read-only memories (ROM), magnetic disks or optical disks, etc., various media that can store program codes.

[0166] Alternatively, if the above-mentioned integrated unit of the present application is implemented in the form of a software function module and sold or used as an independent product, it can also be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present application can essentially or in other words, the part that contributes to the relevant technology can be embodied in the form of a software product, which is stored in a storage medium and includes a number of instructions for an electronic device (which can be a personal computer, a server, or a network device, etc.) to execute all or part of the methods of each embodiment of the present application. The aforementioned storage medium includes: various media that can store program codes, such as mobile storage devices, ROMs, magnetic disks, or optical disks.

[0167] The above are only implementation methods of the present application, but the protection scope of the present application is not limited thereto. Any technician familiar with the technical field can easily think of changes or substitutions within the technical scope disclosed in the present application, which should be included in the protection scope of the present application.

Claims

1. A mobile payment identity authentication method based on digital signature, characterized in that: include: Obtaining device tracking information and user behavior information; wherein the tracking information is used to characterize the identity information of the device, and the behavior information is used to characterize the payment habits of the user; determining a transaction digital signature based on the tracking information and the behavioral information; Verifying the mobile payment based on the transaction digital signature; The determining the tracking code of the device based on the tracking information includes: Based on the IMEI code of the device, generating a standard matrix of the IMEI code of the device; Generate an identification convolution kernel of the device based on a device identifier and a MAC address of the device; Using the identification convolution kernel to perform a convolution operation on the standard matrix and expand it to obtain the tracking code; The step of generating a standard matrix of the IMEI code of the device based on the IMEI code of the device comprises: Segmenting the IMEI code to obtain a model approval code, a final assembly code, and a product serial code of the device; wherein the model approval code, the final assembly code, and the product serial code correspond to the first to sixth digits, the seventh to eighth digits, and the ninth to fourteenth digits of the IMEI code, respectively; Performing a reverse code operation on the model approval code, the final assembly code, and the product serial code; Copy the last digit of the IMEI code and append it to the end of the IMEI code to obtain an updated IMEI code; The inverse code of the product serial code, the inverse code of the final assembly code and the inverse code of the model approval code are sequentially connected to the updated IMEI code to obtain an extended serial code; Convert each bit of the extended sequence code into a binary format and arrange them to generate a binary matrix; Taking the binary matrix as the standard matrix; The step of generating an identification convolution kernel of the device based on a device identifier and a MAC address of the device includes: Grouping the MAC addresses into groups of two bits each, and performing a binary AND operation on the binary form of each group of MAC addresses; Performing a binary exclusive OR operation on the results of the binary AND operation of each group of MAC addresses and converting the results into decimal form to obtain a characteristic value of the MAC address; Using the characteristic value of the MAC address as the core of the convolution kernel and filling the remaining part of the convolution kernel with the device identifier to obtain the identification convolution kernel; The determining of the transaction digital signature based on the tracking information and the behavior information includes: Determining a tracking code for the device based on the tracking information; Based on the behavior information, determining a behavior code of the user; Determining the transaction digital signature based on the tracking code and the behavior code; The determining the behavior code of the user based on the behavior information includes: Obtain the user's historical payment location information, divide the user's payment range, and determine the user's payment range information; Determining the behavior code based on the payment scope information and the user's payment behavior data; The obtaining of the location information of the user's historical payments, dividing the user's payment range, and determining the user's payment range information includes: Determine the center of the user's payment range based on the latitude and longitude information of the user's historical payment locations; Based on the center of the payment range, determine the average distance between the location of the user's historical payments and the center of the payment range, and take the average distance as the payment range of the user; The determining the behavior code based on the payment scope information and the payment behavior data of the user includes: Get the average payment distance of the user in the first time; Get the average total amount of the user's first payment; Multiplying the average value of the payment distance by the abscissa corresponding to the center of the payment range to obtain a first coding coefficient; Multiplying the average of the total payment amount by the ordinate corresponding to the center of the payment range to obtain a second coding coefficient; The first coding coefficient and the second coding coefficient are summed and then Encoding, obtaining the behavior encoding; The process of acquiring the behavior code is expressed by the formula: ; in, Indicates behavioral coding; Represents hash code; Indicates The average payment distance of users in a time period; Indicates The number of transactions of the user in a time period; Indicates The average amount of payment by users in a time period; The horizontal axis represents the center of the user's payment range; The horizontal axis represents the center of the user's payment range.

2. The method according to claim 1, characterized in that The method of performing a convolution operation on the standard matrix using the identification convolution kernel and expanding the matrix to obtain the tracking code includes: Using the identification convolution kernel to perform a convolution operation on the standard matrix to obtain a coding matrix; Group the encoding matrix, sum it up and query it Table, get the corresponding character; The characters are sorted to obtain the tracking code.

3. The method according to claim 1, characterized in that The determining the transaction digital signature based on the tracking code and the behavior code includes: The tracking code and the behavior code are data-fused to obtain a signature code; The signature code is signed to determine the transaction digital signature.

Citation Information

Patent Citations

  • Mobile transaction method and device based on address grid coding, equipment and medium

    CN116452202A

  • Scan and pay method and device utilized in mobile apparatus

    US20190259021A1