Method and system for confirming transactions in a mobile application

Abstract

The invention relates to methods for confirming transactions in a user mobile application. The present method comprises the steps of: a) receiving a transaction request; b) generating a request from a mobile device to a server for receipt of a list of server parameters and a parameter sequencing algorithm for generating one-time session identifiers (OSI) on the mobile device; c) receiving the requested data; d) generating, on the server, an OSI for the mobile device on the basis of the transmitted data, and saving said OSI in a database; e) generating, on the mobile device, an OSI for the mobile application on the basis of the received data, which entails encryption of the resulting sequence of parameters and the use of the sequencing algorithm; f) sending the OSI generated in step e) to the server and decrypting same; g) comparing the decrypted OSI of the application with the OSI stored in the database; h) approving or denying the transaction on the basis of the comparison. The result is an increase in transaction security.

Description

METHOD AND SYSTEM FOR CONFIRMING TRANSACTIONS IN A MOBILE APPLICATION AREA OF TECHNOLOGY

[0001] The claimed solution relates to the field of computer technology, in particular to data protection methods, namely to methods of confirming transactions in a user’s mobile application. LEVEL OF TECHNOLOGY

[0002] Currently, the use of mobile applications for receiving financial services is a widely used method of interaction between users and banks. However, with the widespread use of digital services, the number of fraudulent activities aimed at stealing users' funds has also increased, which necessitates the development of new means of protecting users from fraudsters.

[0003] Banking mobile applications (hereinafter referred to as MB) are used by bank clients to perform various operations (transactions), as well as to receive a variety of services. When performing these manipulations in MB, the bank may request additional confirmation of the transactions being performed from the client for their validation, and sometimes to give legal force to the events that follow after the transaction is performed or the service is rendered. Confirmation of transactions may be carried out at the initiative of the bank in order to combat financial fraud, as well as on the basis of the requirements of regulatory authorities. In this regard, validation of events in the banking mobile application is of great importance, and its incorrect operation may lead to failures in the operation of the MB and have significant negative consequences for both the client and the bank.

[0004] Traditional and widely used validation methods by banks include: - SMS or PUSH messages containing a one-time confirmation code (OTC); - an outgoing or incoming call from the bank’s contact center with confirmation from the bank operator, or via IVR (Interactive Voice Response); - a personal visit by the client to a bank branch.

[0005] Banking applications and bank clients are subjected to various attacks by intruders to obtain information from OTP from SMS and PUSH messages, or to mislead call center operators and other bank employees. The ultimate goal of these attacks by intruders is financial fraud and / or theft of funds.

[0006] The use of any of the above methods of transaction validation has its own characteristics and imposes certain restrictions on their use. For example, validation via SMS messages and voice calls to the contact center incurs significant maintenance costs and for SMS has high risks from mobile operators and the possibility of an illegitimate replacement of the subscriber's SIM card - the bank's client, committed by an intruder. Confirmation of transactions during a personal visit by the client to the bank branch has a negative impact on customer loyalty and entails a decrease in the bank's revenue and an increase in the workload of the branch's operational employees. Thus, the exclusive use of any of the existing transaction validation methods is not possible.

[0007] The most common approach to confirming transactions made using mobile devices is the use of two-factor verification (2FA) using 3D-Secure technology (https: / / ru.wikipedia.org / wiki / 3-D Secure).

[0008] A significant problem with existing 2FA solutions is that they generate a random code that can be intercepted by attackers to commit illegal actions. The proposed solution implements a new, more effective approach to transaction protection, implemented by generating one-time session identifiers (OSI), formed on the basis of data about the hardware elements of the mobile device. ESSENCE OF THE INVENTION

[0009] The claimed invention allows solving a technical problem in terms of creating a new stable one-time session identifier (OSI) of the MU for confirming transactions in mobile applications.

[0010] The technical result is to increase the security of transactions. [OOP] The claimed solution is implemented using a method for confirming transactions in a mobile application (MA) by generating one-time session identifiers (OSI) on the user's mobile device (MD) running the Android OS, which contains the following stages: a) receive a request to perform a transaction in the MP on the user's MU; b) generate a request from the MU to the server to receive a list of parameters and an algorithm for constructing a sequence of parameters for forming the OSI on the MU, wherein the list of parameters includes the following MU parameters: processor parameters, camera parameters, memory module parameters, radio module parameters, system parameters; c) receive a list of parameters and an algorithm for constructing a sequence of parameters on the MU; d) form the OSI for the MU on the server based on the data transmitted to the MU in step c), and record it in the database (DB) for the corresponding MU; e) form the OSI for the MP on the MU based on the data received in step c), using encryption of the received sequence of parameters and the algorithm for constructing it; f) send the OSI formed in step e) to the server and decrypt it; g) compare the MP OSI obtained during decryption with the OSI stored in the DB;h) based on the comparison of the OSI performed in step g), approve or prohibit the execution of the transaction.

[0012] In one particular example of implementation, the algorithm for constructing a sequence of parameters is a randomization algorithm.

[0013] In another particular example of implementation, the asymmetric encryption algorithm (RSA) is used at step e).

[0014] In another particular implementation example, steps b) - h) are executed within a specified time range of transaction execution.

[0015] In another particular example of implementation, a static identifier of the MU is additionally formed by collecting MU parameters, including: processor parameters, camera module parameters, memory module parameters, radio module parameters, and at least mobile device brand data, and subsequent hashing of the obtained set of parameters.

[0016] In another specific implementation example, a static identifier is created on the user's MU, sent and verified on the server for each MU transaction request.

[0017] In another preferred embodiment of the invention, a system for confirming transactions in a mobile application (MA) is claimed using generation of one-time session identifiers (OTI) on the user's mobile device (MD) running the Android OS, in which: The MU is configured to receive a request for performing a transaction in the MP on the user's MU; to generate a request from the MU to the server to receive a list of parameters and an algorithm for constructing a sequence of parameters for forming the OSI on the MU, wherein the list of parameters includes the following MU parameters: processor parameters, camera parameters, memory module parameters, radio module parameters, system parameters; to receive from the server a list of parameters and an algorithm for constructing a sequence of parameters; to form the OSI for the MP based on the data received from the server, using encryption of the received sequence of parameters and the algorithm for constructing it; to send the formed OSI to the server; the server is configured to form the OSI for the MU on the server based on the data transmitted to the MU in response to the received request, and to record it in the database (DB) for the corresponding MU; decrypt the formed OSI of the MP received from the MU;comparison of the MP OSI obtained during decoding with the OSI stored in the database; based on the comparison of the OSI, approve or prohibit the execution of the transaction;

[0018] In one particular implementation example, the construction of the parameter sequence is a randomization algorithm.

[0019] In another particular implementation example, encryption is performed using the RSA (Reference Sentinel Asymmetric Algorithm).

[0020] In another particular example of implementation, a static identifier of the MU is additionally formed by collecting MU parameters, including: processor parameters, camera module parameters, memory module parameters, radio module parameters, and at least mobile device brand data, and subsequent hashing of the obtained set of parameters.

[0021] In another specific implementation example, a static identifier is created on the user's MU, sent and verified on the server for each MU transaction request. BRIEF DESCRIPTION OF DRAWINGS

[0022] Fig. 1 illustrates the general scheme of the solution operation.

[0023] Fig. 2 illustrates a block diagram of the implementation of the claimed method.

[0024] Fig. 3 illustrates a diagram of a computing device. IMPLEMENTATION OF THE INVENTION

[0025] Fig. 1 shows a general view of the implementation diagram of the claimed solution, which includes a user's MU (MU) connected via a data transmission channel (130) to a server (120) that processes data via an API. A smartphone, phablet or tablet running Android OS, on which a MP (for example, Sberbank Online) is installed, can be used as a MU (PU). The Internet network is used in part of the data transmission channel (130), ensuring data exchange between the MU (PU) and the server (120).

[0026] Fig. 2 shows a flow chart of the execution of the stages of the method (200) for confirming transactions in the MP. After installing the payment MP (201), for example, Sberbank Online, the program logic of the application requests data for subsequent registration of the user. Such data may be full name, passport data, payment card number, phone number, login / password for entering the application, etc. Additionally, biometric information may be used. After successful registration, a unique record is created for each user under the corresponding identifier, which is saved on the server in a single database (DB).

[0027] After registration in the application at stage (202), the client part of the MP records the entry into the MP. When the MP user initiates the execution of a transaction on the MU (110), a request is generated to the server (120) to obtain a list of parameters and an algorithm for generating a sequence of parameters with the help of which the OSI for the MP will be generated. The list of parameters includes the following MU parameters: processor parameters, camera parameters, memory module parameters, radio module parameters, system parameters. The server (120) makes a request for parameters and an algorithm for generating their sequence in the DB and transmits them to the MU (110).

[0028] The parameters are collected by means of the software logic of the payment MP, which has access to the mobile device OS. As part of the implementation of this stage, the following parameters are collected: processor parameters, camera module parameters, memory module parameters, radio module parameters, and at least mobile device brand data.

[0029] Mobile device data is collected from the main hardware modules (processor, memory, camera, radio module), as well as system data identifying the device itself.

[0030] The processor parameters can be selected from the following data presented in Table 1. Table 1. Processor parameters

[0031] An example of the camera module parameters used is given in Table 2. Table 2. Camera parameters

[0032] The memory module parameters may include the parameters listed in Table 3. Table 3. Memory module parameters

[0033] An example of the radio module parameters used is given in Table 4. Table 4. Radio module parameters

[0034] Additionally, the system parameters given in Table 5 are used to form the identifier. Table 5. System parameters

[0035] Next, at step (203), after the server (120) has transmitted the parameters to the MU (110), the server (120) generates the OSI for the MU (NO). The algorithm for generating a sequence of 28 of the above parameters is a randomizer of the sequence of parameters received by the server (120), due to which the number of possible combinations for a set of one MU (110) exceeds 38 million values.

[0036] After collecting the required set of the above parameters, at stage (204) their subsequent hashing is performed taking into account the selected randomization algorithm transmitted by the server (120). The Randomized Quick Sort algorithm or another one can be used as a randomization algorithm. The Android OS allows you to receive these parameters without additional permissions from the owner of the mobile device.

[0037] Depending on the type of tasks being solved, the identifier obtained on the above parameters is static, which is achieved by using various data conversion algorithms. When forming the OSI on the MU (PO), asymmetric encryption algorithms (RSA) are used to increase security and improve the stability of the connection to various attack vectors on the banking infrastructure.

[0038] At stage (204), as a result of applying the hashing functions, an OSI is formed, which may have the following form: Wj6tqLi34kZsbPZCi+gGTyrTaHmoAnlj01wM AxSxOWn:C3+zD3slOXsjJOc:C3FzD3slOXsjJ OcWj6tqLi34kZsbPZCi+gGTyrTaHmoAnlj01wlCYOSxOWn:ClfpwOcWj68LioBPZCiqyrGGJ nlfVxv.

[0039] The encrypted IOC is transmitted to the server (120), where it is subsequently decrypted at step (205) for the purpose of checking its coincidence with the IOC that was generated at step (203), stored in the DB. At step (206), if the IOCs match, the transaction performed in the MP is approved. Otherwise, the transaction is rejected. The verification of the IOC generated on the MU (PO) and the server (120) is performed automatically and does not require additional input or actions from the MU (PO) user, which further increases the security of this operation and reduces the risk of the IOC being intercepted. As a rule, the time for checking the fact of transaction approval has a set range, for example, 30 sec, 1 minute, etc. The range may vary. The verification of the IOC is performed within the above-mentioned set range.

[0040] Additionally, a static identifier can be generated for the MU (110) using the method described in patent No. 2772571 (Sberbank PJSC, 09 / 08 / 2022), which is saved in the server database (120) and can be used for additional authentication of the MU (PO).

[0041] The uniqueness of the approach lies in the formation of the OSI specifically on the client part of the application according to the logic that the server part transmits to it, on data that is known only to the client and server parts. This approach significantly increases the level of trust (with the identity of identifiers) in client-server interaction and at the same time maintains a high level of performance of the interaction as a whole. With sufficient protection of the source code from intruders, it is not possible to independently (unauthorizedly) generate the OSI in a modified mobile application.

[0042] The applicability of the approach has different application sides, such as the above-described method of using the identifier in systems that monitor and block suspicious transactions, as well as systems that authorize clients and devices.

[0043] Fig. 3 shows a general view of a computing device (300) with the help of which the claimed solution can be implemented. In the general case, the computing device (300) contains one or more processors (301) united by a common information exchange bus, memory means such as RAM (302) and ROM (303), input / output interfaces (304), input / output devices (305), and a device for network interaction (306).

[0044] The processor (301) (or several processors, multi-core processor) can be selected from a range of devices that are widely used at present, for example, from Intel™, AMD™, Apple™, Samsung Exynos™, MediaTEK™, Qualcomm Snapdragon™, etc. The processor must also include a graphic processor, for example, NVIDIA or ATI GPU, which is also suitable for the full or partial implementation of the method (200). In this case, the available memory capacity of the graphic card or graphic processor can act as a memory means.

[0045] RAM (302) is a random access memory and is intended for storing machine-readable instructions executed by the processor (301) to perform the necessary operations for logical data processing. RAM (302), as a rule, contains executable instructions of the operating system and the corresponding software components (applications, software modules, etc.).

[0046] ROM (303) is one or more permanent data storage devices, such as a hard disk drive (HDD), a solid-state drive (SSD), flash memory (EEPROM, NAND, etc.), optical storage media (CD-R / RW, DVD-R / RW, BlueRay Disc, MD), etc.

[0047] To organize the operation of the device components (300) and to organize the operation of external connected devices, various types of I / O interfaces (304) are used. The choice of the corresponding interfaces depends on the specific design of the computing device, which may include, but are not limited to: PCI, AGP, PS / 2, IrDa, FireWire, LPT, COM, SATA, IDE, Lightning, USB (2.0, 3.0, 3.1, micro, mini, type C), TRSZ Audio jack (2.5, 3.5, 6.35), HDMI, DVI, VGA, Display Port, RJ45, RS232, etc.

[0048] To ensure user interaction with the computing device (400), various means (305) of I / O information are used, for example, a keyboard, a display (monitor), a touch screen, a touch pad, a joystick, a mouse, a light pen, stylus, touchpad, trackball, speakers, microphone, augmented reality tools, optical sensors, tablet, indicator lights, projector, camera, biometric identification tools (retina scanner, fingerprint scanner, voice recognition module), etc.

[0049] The network interaction means (306) ensures data transmission by the device (300) via an internal or external computer network, for example, Intranet, Internet, LAN, etc. One or more means (306) may be, but are not limited to: an Ethernet card, GSM modem, GPRS modem, LTE modem, 5G modem, satellite communication module, NFC module, Bluetooth and / or BLE module, Wi-Fi module, etc.

[0050] Additionally, satellite navigation tools included in the device (300) can also be used, for example, GPS, GLONASS, BeiDou, Galileo.

[0051] The submitted application materials disclose preferred examples of the implementation of the technical solution and should not be interpreted as limiting other, particular examples of its implementation that do not go beyond the scope of the requested legal protection, which are obvious to specialists in the relevant field of technology.

Claims

FORMULA 1. A method for confirming transactions in a mobile application (MA) by generating one-time session identifiers (OSI) on a user's mobile device (MD) running the Android OS, comprising the following stages: a) receiving a request to perform a transaction in the MA on the user's MD; b) generating a request from the MD to the server to receive a list of parameters and an algorithm for constructing a sequence of parameters for generating the OSI on the MD, wherein the list of parameters includes the following MD parameters: processor parameters, camera parameters, memory module parameters, radio module parameters, system parameters; c) receiving a list of parameters and an algorithm for constructing a sequence of parameters on the MD; d) generating the OSI on the server for the MD based on the data transmitted to the MD in stage c), and recording it in the database (DB) for the corresponding MD;e) generate the OSI for the MP on the MU based on the data obtained in step c) using encryption of the received sequence of parameters and the algorithm for its construction; f) send the OSI generated in step e) to the server and decrypt it; g) compare the MP OSI obtained during decryption with the OSI stored in the DB; h) approve or prohibit the execution of the transaction based on the comparison of the OSI performed in step g).

2. The method according to claim 1, wherein the algorithm for constructing a sequence of parameters is a randomization algorithm.

3. The method according to claim 1, wherein at step e) an asymmetric encryption algorithm (RSA) is used.

4. The method according to claim 1, wherein steps b) - h) are performed in a specified time range for executing the transaction.

5. The method according to item 1, in which a static identifier of the MU is additionally formed by collecting MU parameters, including: processor parameters, camera module parameters, memory module parameters, radio module parameters, and at least the mobile device brand data, and subsequent hashing of the resulting set of parameters.

6. The method according to paragraph 5, in which the static identifier is created on the user's MU, sent and verified on the server upon each request to perform a MU transaction.

7. A system for confirming transactions in a mobile application (MA) using the generation of one-time session identifiers (OSI) on the user’s mobile device (MD) running the Android OS, in which: The MU is configured to receive a request for performing a transaction in the MP on the user's MU; to generate a request from the MU to the server to receive a list of parameters and an algorithm for constructing a sequence of parameters for forming the OSI on the MU, wherein the list of parameters includes the following MU parameters: processor parameters, camera parameters, memory module parameters, radio module parameters, system parameters; to receive from the server a list of parameters and an algorithm for constructing a sequence of parameters; to form the OSI for the MP based on the data received from the server, using encryption of the received sequence of parameters and the algorithm for constructing it; to send the formed OSI to the server; the server is configured to form the OSI for the MU on the server based on the data transmitted to the MU in response to the received request, and to record it in the database (DB) for the corresponding MU; to decrypt the formed OSI of the MP received from the MU;comparison of the MP OSI obtained during decoding with the OSI stored in the database; based on the comparison of the OSI, approve or prohibit the execution of the transaction.

8. The system according to claim 7, wherein the construction of the sequence of parameters is a randomization algorithm.

9. The system according to claim 7, wherein encryption is performed using an asymmetric encryption algorithm (RSA).

10. The system according to item 7, in which a static identifier of the MU is additionally formed by collecting MU parameters, including: processor parameters, camera module parameters, memory module parameters, radio module parameters, and at least mobile device brand data, and subsequent hashing of the obtained set of parameters.

11. The system according to item 10, in which the static identifier is created on the user's MU, sent and verified on the server upon each request to perform a MU transaction.

Images