Method and system for identifying use of a trusted mobile application

Abstract

A method for identifying the use of a trusted mobile application on a user mobile device running OS Android includes receiving data about a user login to a mobile application, and generating a request from the mobile device to a server for receipt of a list of parameters and an algorithm for sequencing said parameters on the mobile device. A session identifier for the mobile device is generated on the server on the basis of the data transmitted to the mobile device and is recorded in a database for the mobile device in question. A session identifier for the mobile application is generated on the mobile device on the basis of the data received from the server by encrypting the obtained sequence of parameters and the sequencing principle, and said session identifier is sent to the server, where it is decrypted. The mobile application session identifier obtained during decryption is compared with the session identifier stored in the database, and the level of trustworthiness of the mobile application is determined from the comparison of the session identifiers. The technical result consists in more effective identification of the use of trusted mobile applications.

Description

METHOD AND SYSTEM FOR DETERMINING THE USE OF A TRUSTED 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 for generating session identifiers to determine the use of trusted mobile applications. 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] This problem is especially critical for mobile devices running Android OS. The banking mobile application provides the ability to receive the identifier of the mobile device and transmit it to the bank's information systems. This option is provided by default to all applications installed on the mobile device. Based on this identifier, the bank carries out additional verification of the client when making transactions and, if there are discrepancies in the client identifiers, can suspend or reject the transaction as suspicious.

[0004] The Android operating system (hereinafter referred to as OS) starting from version 10 and above, in order to increase the privacy of mobile device users, has restricted access to non-resettable (static) device identifiers, including for applications installed and running on the device. When resetting the device to factory settings, the identifier available to applications installed on the device changes. Thus, unambiguous identification of the client's mobile device on the bank's side is not possible.

[0005] As a rule, the client interacts with the bank via a mobile banking application (hereinafter referred to as MP), installed on their mobile device (hereinafter referred to as MD), which runs on the Android OS. Clients do not always can obtain reliable information and use trusted resources for installing the MP, which leads to cases when a modified mobile banking application (hereinafter referred to as MBMA) can be installed on the MU, using publicly available banking protocols of client-server interaction (mobile API). These mobile applications are not official banking applications and are either independent applications - aggregators of banking services, or unauthorized modified software of the bank, obtained by reverse engineering the original banking application. MBMA are a threat to the cybersecurity of both clients installing this software and the entire bank as a whole, since they can carry vulnerabilities and undeclared capabilities that can be used by intruders.

[0006] The software interface of the banking mobile application (hereinafter referred to as mAPI) is a complex structure and set of rules by which the client-server interaction of all clients using the MU is carried out. Thus, to ensure maximum compatibility and uninterrupted operation of all services and services on all devices running the Android OS, mAPI is open and publicly available both for large developers of mobile applications and devices, and for private researchers and programmers.

[0007] Attackers, as well as mobile application developers, using access to the description, structure and mAPI itself, create MBPM. When these mobile applications operate, client-server interaction with processing banking systems is carried out, which on the bank's side is identical to the interaction of native (official) banking applications. Thus, the bank does not have the technical ability to identify (distinguish) operations and transactions made in MBPM from operations made in native applications.

[0008] Modern native banking mobile applications (hereinafter referred to as NBMA), in addition to business functionality, contain functions (tools) for analyzing, protecting and preventing hacker and / or financial attacks both on bank clients and on the entire bank as a whole. Such tools include built-in antivirus tools, protection from unauthorized and intrusive advertising, detection of devices with root rights, and much more. Clients using NBMA without the above-described means of protection significantly increase the cybersecurity risks, both their own and the bank's as a whole.

[0009] Existing solutions in terms of implementing approaches to secure transactions are usually aimed at controlling the trust of the very fact of a transaction carried out from an appropriate device, using, for example, exchange of access keys with a short service life. An example of such a solution is disclosed in patent US 10915902 B2 (Bell Identification BV, 09.02.2021).

[0010] A significant problem with existing approaches is the key use of digital information and basic hardware numbers of mobile devices, such as IMEI, serial number, etc. This data is quite vulnerable, which is why it is proposed to form a session identifier based on the hardware parameters of the mobile device when performing transactions, which will be a more reliable confirmation that the user interacts with the bank through the NBMP. ESSENCE OF THE INVENTION

[0011] The claimed invention allows solving a technical problem in terms of creating a new robust and stable session identifier (SID) of a mobile device for its subsequent use to track the use of trusted mobile applications.

[0012] The technical result is to increase the efficiency of determining the use of trusted mobile applications.

[0013] The claimed solution is implemented using a method for determining the use of a trusted mobile application (MA) on a user's mobile device (MD) running Android OS, comprising the following stages: receiving data on the user's login to the MA; a) receiving data on the user's login to the MA; b) generating a request from the MA to the server to receive a list of parameters and an algorithm for constructing a sequence of parameters for forming a session identifier of the MA on the MA, wherein the list of parameters includes the following MA parameters: processor parameters, camera parameters, memory module parameters, radio module parameters, system parameters; c) generating a session identifier for the MA on the server based on the data transmitted to the MA at stage b), and recording it in the database (DB) for the corresponding MA;d) generate a session identifier for the MP on the MU based on the data obtained in step b), using encryption of the received sequence of parameters and the principle of its construction; e) send the session identifier generated in step d) to the server and decrypt it; f) compare the MP session identifier obtained during decryption with the session identifier stored in the database; g) determine the MP trust level based on the comparison of session identifiers.

[0014] In one of the particular examples of the implementation of the method, the algorithm for constructing a sequence of parameters is a randomization algorithm.

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

[0016] In another particular example of the implementation of the method, if the MP is untrusted, the server monitors the operations performed in the MP on the MU.

[0017] In another particular example of the method implementation, the server generates a notification for the MU that the MP is untrusted.

[0018] In another specific example of the method implementation, the notification contains a link to download a trusted MP.

[0019] In another particular example of the implementation of the method, transaction operations are blocked during monitoring.

[0020] In another particular example of implementing the method, 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 particular example of the method implementation, the static identifier is written to the server database.

[0022] The stated technical result is also achieved through a system for determining the use of a trusted mobile application (MA) on a user's mobile device (MD) running the Android OS, in which: The MU is designed with the ability to receive data on the user's entry into the MP; 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 a session identifier of the MP 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; generate a session identifier for the MP based on the data received in response to a sent request from the MU, using encryption of the received sequence of parameters and the principle of its construction; send the generated session identifier of the MP to the server; the server is configured to generate a session identifier for the MU on the server based on the data transmitted to the MU in response to the received request, and record it in the database (DB) for the corresponding MU; decrypt the generated session identifier of the MP received from the MU; compare the session identifier of the MP obtained during decryption with the session identifier stored in the DB; determine the degree of trust of the MP based on the comparison of session identifiers.

[0023] In one of the specific examples of the system implementation, if the MP is untrusted, the server monitors the operations performed in the MP on the MU.

[0024] In another particular example of the system implementation, the server generates a notification for the MU that the MP is untrusted.

[0025] In another particular example of the system implementation, the notification contains a link to download a trusted MP.

[0026] In another particular example of the system implementation, transaction operations are blocked during monitoring.

[0027] In another particular example of the implementation of the system, 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.

[0028] In another particular example of the system implementation, a static identifier is written to the server database. BRIEF DESCRIPTION OF DRAWINGS

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

[0030] Fig. 2 illustrates a block diagram of the implementation of a method for determining the trust level of a mobile application.

[0031] Fig. 3 illustrates a flow chart of a method for tracking transactions.

[0032] Fig. 4 illustrates a diagram of a computing device. IMPLEMENTATION OF THE INVENTION

[0033] Fig. 1 shows a general view of the implementation diagram of the claimed solution, which includes a user's MU (PU) 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).

[0034] Fig. 2 shows a block diagram of the execution of the stages of the method (200) for determining the degree of trust of a mobile application. 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).

[0035] After registration in the application at stage (202), the client part of the MP records the entry into the MP. After this, the MP on the MU (110) sends a request to the server (120) to obtain a list of parameters and an algorithm for generating a sequence of parameters, with the help of which a session identifier (SID) 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).

[0036] The parameters are collected by means of the software logic of the payment application, 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.

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

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

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

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

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

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

[0043] Next, at step (203), after the server (120) has transmitted the parameters to the MU (110), the SID for the MU (NO) is generated on the server (120). 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.

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

[0045] This list of parameters allows you to achieve: - uniqueness of the received identifiers, even on identical devices from the same manufacturer; - the identifier remains unchanged on any device, even with minor and major Android OS updates; - reproducibility (repeatability of results) of the identifier during various types of resets of the mobile device to factory and subsequent device restores.

[0046] Depending on the type of tasks being solved, the identifier obtained on the above parameters can be static and / or probabilistic, this is achieved by using various data conversion algorithms. When forming SID 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.

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

[0048] The encrypted SID is transmitted to the server (120), where it is subsequently decrypted at step (205) for the purpose of checking its coincidence with the SID that was generated at step (203), stored in the DB. At step (206), if the SIDs match, then a conclusion is made that the MP on the MU (PO) is trusted (native). Otherwise, a conclusion is made that the MP on the MU (110) is untrusted (modified).

[0049] Additionally, a static identifier can be generated for the MU (PO) 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 (110).

[0050] Fig. 3 shows a method (300) for monitoring transactions using the formation of SIDs on the side of the MU (PO) and the server (120). When checking at step (301) the generated SIDs within the framework of the interaction of the MP user when performing operations on the side of the server (120), a check of the SID validity period is performed, which is usually several minutes. If, as a result of the check at step (302), it is established that the transaction is carried out from an untrusted MP, then information about such MP is transmitted to an external monitoring system, which performs subsequent control within the framework of the MP user interaction (step 303).

[0051] Such a system could be an automated fraud monitoring system. (ASFM). The bank's automated fraud monitoring system analyzes and identifies anomalies in the customer transaction flow, placing the identifiers of the attackers' mobile devices on "black" lists, thereby preventing further installations and registrations of payment applications on the attackers' devices.

[0052] When anomalies (changes) in the client identifiers are detected, the server (120) at step (304) can generate a signal to suspend or reject the transaction, on the grounds that it is suspicious and is executed from a modified MP. This approach ensures the prevention of possible fraud (theft of funds or property) in relation to the bank client.

[0053] Also, the server (120) may continue to collect and accumulate data to form a more accurate understanding of the nature of a particular activity and, upon the occurrence of a high-risk event, implement the countermeasures specified above.

[0054] The uniqueness of the approach lies in the formation of a session identifier 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, while maintaining a high level of interaction performance as a whole. With sufficient protection of the source code from intruders, it is not possible to independently (unauthorizedly) generate a session identifier in a modified mobile application.

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

[0056] Fig. 4 shows a general view of the computing device (400) with the help of which the claimed solution can be implemented. In the general case, the computing device (400) contains one or more processors (401) united by a common information exchange bus, memory means such as RAM (402) and ROM (403), input / output interfaces (404), input / output devices (405), and a device for network interaction (406).

[0057] The processor (401) (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 also includes a graphic processor, for example, NVIDIA or ATI GPU, which is also suitable for the full or partial implementation of the method (200, 300). In this case, the available memory capacity of the graphic card or graphic processor can act as a memory means.

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

[0059] ROM (403) 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.

[0060] To organize the operation of the device components (400) and to organize the operation of external connected devices, various types of I / O interfaces (404) 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), TRS / Audio jack (2.5, 3.5, 6.35), HDMI, DVI, VGA, Display Port, RJ45, RS232, etc.

[0061] To ensure interaction between the user and the computing device (400), various means (405) of I / O information are used, for example, a keyboard, a display (monitor), a touch display, a touchpad, a joystick, a mouse, a light pen, a stylus, a touch panel, a trackball, speakers, a microphone, augmented reality means, optical sensors, a tablet, light indicators, a projector, a camera, biometric identification means (a retina scanner, a fingerprint scanner, a voice recognition module), etc.

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

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

[0064] 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 determining the use of a trusted mobile application (MA) on a user's mobile device (MD) running the Android OS, comprising the following steps: a) receiving data about the user's login to the MA; b) generating a request from the MA to the server to receive a list of parameters and an algorithm for constructing a sequence of parameters for forming a session identifier for the MA on the MA, wherein the list of parameters includes the following MA parameters: processor parameters, camera parameters, memory module parameters, radio module parameters, system parameters; c) generating a session identifier for the MA on the server based on the data transmitted to the MA in step b) and recording it in the database (DB) for the corresponding MA; d) generating a session identifier for the MA on the MA based on the data received in step b) by encrypting the received sequence of parameters and the principle of its construction;e) send the session identifier generated in step d) to the server and decrypt it; f) compare the MP session identifier obtained during decryption with the session identifier stored in the database; g) determine the level of trust of the MP based on the comparison of session identifiers.

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 in step d) an asymmetric encryption algorithm (RSA) is used.

4. The method according to paragraph 1, in which, if the MP is untrusted, the server monitors the operations performed in the MP on the MU.

5. The method according to paragraph 4, in which the server generates a notification for the MU that the MP is untrusted.

6. The method according to paragraph 5, wherein the notification contains a link to download the trusted MP.

7. The method according to paragraph 4, in which, during monitoring, transaction operations are blocked.

8. The method according to claim 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 mobile device brand data, and subsequent hashing of the obtained set of parameters.

9. The method according to paragraph 8, wherein the static identifier is recorded in the server database.

10. A system for determining the use of a trusted mobile application (MA) on a user's mobile device (MD) running the Android OS, in which: The MU is configured to receive data on user login to the MP; 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 a session identifier of the MP 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 form a session identifier for the MP based on the data received in response to a sent request from the MU, using encryption of the received sequence of parameters and the principle of its construction; to send the generated session identifier of the MP to the server; the server is configured to form a session identifier 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 generated session identifier of the MP received from the MU;comparison of the MP session identifier obtained during decryption with the session identifier stored in the database; determination of the MP trust level based on the comparison of session identifiers.

11. The system according to paragraph 10, in which, if the MP is untrusted, the server monitors the operations performed in the MP on the MU.

12. The system of claim 11, wherein the server generates a notification for the MU that the MP is untrusted.

13. The system of claim 12, wherein the notification contains a link to download a trusted MP.

14. The system according to paragraph 11, in which, during monitoring, blocking of transaction operations is performed.

15. The system according to claim 11, 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.

16. The system according to paragraph 15, in which the static identifier is recorded in the server database. 15

Images