EA044663B1 - METHOD AND DEVICE FOR FORMING A STATIC IDENTIFIER FOR MOBILE DEVICES CONTROLLED BY ANDROID OS, METHOD AND SYSTEM FOR DETECTING FRAUDULENT TRANSACTIONS USING A STATIC IDENTIFIER - Google Patents

Description

Field of technology

The claimed solution relates to the field of computer technology, in particular to methods for generating device identifiers for their use in the field of information security.

State of the art

Currently, the use of mobile applications for obtaining financial services is a widely used way for users to interact with banks. However, with the massive spread of receiving services in digital format, the amount of fraudulent activity aimed at stealing user funds has also increased, which necessitates the development of new means of protecting users from the actions of fraudsters. This problem is especially critical for mobile devices running OCAndroid. The banking mobile application provides the ability to receive a mobile device identifier and transfer it to the bank’s information systems. This feature 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.

The Android operating system (hereinafter referred to as OS) starting from version 10 and higher, in order to increase the privacy of mobile device users, has limited access to non-resettable (static) device identifiers, including for applications installed and running on the device. When you reset your device to factory settings, the ID available to apps installed on the device changes. Thus, unambiguous identification of the client mobile device on the bank’s side is not possible.

Attackers, using various methods of influencing bank customers, including social engineering, can gain access to critical customer data, then this data can be used to install banking applications on the attacker’s device with further registration with the bank. After registering such an application on his device on behalf of the client, the attacker gains access to the client’s funds and then attempts to steal these funds.

There are approaches to the formation of complex device IDs (patent application US 20140164178 A1, 06/12/2014), in which the ID is generated based on existing information about user registration data of various accounts, thereby allowing the generation of a more unique ID for use for authentication purposes.

A significant problem with existing approaches is the key use of digital information and basic hardware numbers of mobile devices, for example, IMEI, serial number, etc. This data is quite vulnerable and does not allow the formation of a static identifier based on it, which will not change significantly when the devices are factory reset; also, starting from version 10 of the Android OS, this kind of data is not available to mobile applications.

The essence of the invention

The claimed invention allows us to solve a technical problem in terms of creating a new robust and stable mobile device identifier for its subsequent use to track fraudulent activity. The technical result is to increase the accuracy of identification of mobile devices due to the formation of a static identifier. The claimed solution is implemented using a method for generating a static identifier for mobile devices running the Android OS, containing the stages in which, using the mobile device processor:

install the payment application in the mobile device OS;

launching the payment application and registering the user in it, while collecting parameters of the mobile device, including: processor parameters, camera module parameters, memory module parameters, radio module parameters, and at least data on the brand of the mobile device;

carry out hashing of the resulting set of parameters using a piecewise hashing algorithm initiated by the context and a block recovery algorithm, while hashing the parameters by each of the algorithms is performed in parallel;

generating a static mobile device identifier based on the performed hashing;

associate the received identifier with the payment application of a specific user;

transmit the received identifier to the server of the automated fraud monitoring system (ASFM).

In one of the particular examples of the method, the processor parameters include at least one of: number of processor cores, processor frequency, processor model, core name, core architecture, supported architecture.

In another particular example of the method, the parameters of the camera module include at least one of: camera sensor size, camera focal length, horizontal alignment angle

- 1 044663 camera ki, vertical camera angle, maximum frame duration.

In another particular example of the implementation of the method, the parameters of the memory module include at least one of: the total amount of physical RAM, the total amount of available swap, the total amount of memory from the total allocated virtual address space.

In another particular example of the method, the radio module parameters include at least one of: DRM scheme identifier, radio module firmware version, base board data.

In another particular example of the method, the parameters additionally include at least one of: processor range check parameter, changelog number, manufacturer data, mobile device name, industrial design name, screen resolution, assembly identifier string.

The claimed solution is also carried out using a method for identifying fraudulent transactions carried out using mobile devices, and the method contains stages in which, using ASFM:

record the registration of the payment application on the mobile device;

generating a static mobile device identifier in the above manner;

linking the received identifier with the registration data of the user of the payment application;

record the execution of the transaction through the payment application;

receive data about a fraudulent transaction through the said payment application;

blacklisting at least the received static identifier of the mobile device;

block the operation of a payment application on a mobile device containing a blacklisted identifier.

In one of the particular examples of the implementation of the method, the details of the accounts to which the fraudulent transaction was carried out are recorded.

In another particular example of the implementation of the method, account details are added to the black list for subsequent blocking of transactions.

The claimed solution is also implemented using a device for generating a static identifier for mobile devices running Android OS, which contains at least one processor and at least one memory storing machine-readable instructions, which, when executed by the processor, perform the above method of generating a static identifier.

The claimed solution is also implemented using a fraudulent transaction detection system, which contains at least one processor and at least one memory storing machine-readable instructions, which, when executed by the processor, perform the above-described method of detecting fraudulent transactions.

Brief description of drawings

Fig. 1 illustrates a flow diagram of a method for generating a static identifier.

Fig. 2 illustrates a flow diagram of a method for tracking fraudulent transactions using a static identifier.

Fig. 3 illustrates a diagram of a computing device.

Carrying out the invention

In fig. 1 shows a block diagram of the steps of the method (100) for generating a static identifier. The stated solution is performed when installing the payment application at stage (101) in the OS of the mobile device. The term mobile device within the framework of the claimed solution can be understood as a smartphone, phablet or tablet running Android OS.

After installing a payment application, for example Sberbank Online, the application’s software logic requests data for subsequent user registration. Such data may be full name, passport data, payment card number, phone number, login/password for logging into 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 stored on the server in a single database.

After registering with the application, step (102) collects mobile device data. The collection is carried out through the software logic of the payment application, which has access to the OS of the mobile device. As part 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.

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

Processor parameters can be selected from the following data presented in table. 1.

- 2 044663

Table 1

Processor parameters

CPUCORES Number of processor cores CPU MHZ CPU frequency MODEL NAME Processor model CPU FAMILY Processor family name KERNEL OS NAME Kernel name KERNEL OS ARCH Kernel architecture CPU ABI Supported Architecture CPU AB 12 Supported Architecture

An example of the camera module parameters used is given in table. 2.

table 2

Camera options

CAMERA SENSOR SIZE Camera sensor size CAMERA 0 FOCAL LENGTH Camera focal length CAMERA 0 HORIZONTAL ANGLE Horizontal camera angle CAMERA 0 VERTICAL ANGLE Vertical camera angle MAX FRAME DURATION Maximum frame duration

Memory module parameters may include the parameters listed in table. 3.

Table 3

Memory module parameters

MEMTOTAL Total amount of physical RAM SWAPTOTAL The total amount of available swap (“Swap” file\swap partition of the operating system designed to improve performance and optimize the use of applications on a mobile device). VMALLOCTOTAL Total memory from total allocated virtual address space

An example of the radio module parameters used is given in table. 4.

Table 4

Radio module parameters

WIDEVINEUUID SYSTEM ID DRM Scheme ID RADIO VERSION Radio module firmware version HARDWARE Hardware name (from kernel command line) BOARD Baseplate name

Additionally, the system parameters given in Table 1 are used to generate the identifier. 5.

Table 5

System parameters

BOGOMIPS Processor Range Check Option OUTPUTSIZES Screen resolution MANUFACTURER Manufacturer name

- 3 044663

MODEL Mobile device name visible to the device user DEVICE Name of the industrial design (factory name of the brand and model range of mobile devices) ID Changelog number, or a label like “M4-gs20” DISPLAY Assembly ID string BRAND Brand name of the device manufacturer

Upon collection of the required set of the above parameters, their subsequent hashing is carried out at step (103). Android OS allows you to receive these parameters without additional permissions from the owner of the mobile device. 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 for various types of mobile device resets before factory reset and subsequent device restores.

Depending on the type of problem being solved, the identifier obtained using the parameters described above can be static and/or probabilistic; this is achieved through the use of various data conversion algorithms. This solution uses a combination of cryptographic hashing algorithms and fuzzy hashing methods (similarity preserving hash functions). This is done to minimize possible further restrictions on the collection of system parameters from the Android OS, as well as any other changes that may occur to the system parameters of the mobile device during operation (for example, hardware replacement of the camera or processor in the device).

At step (103), two modified similarity-preserving hash functions are applied: ssdeep [1] and SimHash [2]. Initially, these algorithms were developed for computer forensics tasks, namely: accelerating and automating the analysis of the contents of a specific electronic document, as well as formalizing and presenting the obtained evidence in court. Ssdeep refers to context-initiated piecewise hashing algorithms, that is, during hashing, a hash is created for several discrete data segments, the size and number of which are determined algorithmically based on the context of the data being hashed. SimHash is a block recovery algorithm and allows you to determine the difference in distances between identifiers by calculating the Hamming distance, or the Damerau-Levenshtein distance, or the XOR vector. By additionally comparing the obtained numerical characteristics of the distances, you can select both the minimum value, which will mean that the received identifiers can relate to the same device, and the maximum value, which will indicate that these are identifiers of different devices.

The essence of the modification of the algorithms used in the claimed solution lies in the fixed positions of sampling (segmentation) of the resulting sequence of parameters into five blocks that characterize the main system modules of the mobile device (processor, camera, memory, radio module, system data), which allows the ssdeep and SimHash algorithms perform calculations regardless of the size and availability of lines for each of the system parameters. For example, when replacing the camera on a device, the identifier of the mobile device will change, but thanks to similarity-preserving hashing algorithms, it is possible to determine the most likely (close) identifier that the device previously had, and also, due to fixed sampling positions, determine the module in which the changes occurred , similarly, with possible restrictions on the collection of system parameters from the Android OS. The use of two hashing algorithms independently of each other is also due to an increase in the accuracy of identifying probable identifiers and a decrease in false positives during targeted attacks by attackers on the algorithms [3].

At step (104), based on the results of applying the hashing functions, a static identifier of the mobile device is formed. The identifier may look like this:

- 4 044663

Wj6tqLi34kZsbPZCi+gGTyrTaHmoAnlj01wMwAxSxOWn:C3+zD3slOXsjJOc:C3FzD3slOXsjJ

OcWj 6tqLi34kZsbPZCi+gGTyrTaHmoAn Ij 01 wlC YOSxOWn: C1 fpwOcWj 68LioBPZCiqyrGGJ nlfVxv.

The generated static identifier is associated with the user registration data entered into the payment application, and at step (105) is transferred to the database on the server. The frequency of generation and transfer of mobile device identifiers to the server may vary depending on the goals and objectives of the organization (one-time, event-based, or scheduled). The resulting identifiers are accumulated in the organization's automated systems and allow the identification of client mobile devices when working with the application.

If anomalies (changes) in client identifiers are detected, the bank can suspend or reject the transaction as suspicious, thereby preventing possible fraud (theft of funds or property) against the bank client.

The uniqueness of the proposed approach lies in the formation of an identifier that simultaneously combines several properties:

static - resistant to changes in the OS on mobile devices and not requiring additional permissions for the mobile payment application;

probabilistic stability - if the approach of OS developers for mobile devices changes, the available characteristics necessary for generating an identifier remain.

The information generated at stage (105), recorded on the bank’s server, is transmitted at stage (106) to the server of the automated fraud monitoring system (ASFM). The bank's automated fraud monitoring system analyzes and identifies anomalies in the transaction flow of clients, placing the identifiers of mobile devices of attackers on blacklists, thereby preventing further installations and registrations of payment applications on the devices of attackers. In fig. 2 shows an example of the operation of the method (200) for tracking fraudulent transactions using the above-described method of generating a static identifier. At the first stage (201), the ASFM records the receipt of information about the implementation of the first transaction using a mobile device with an installed payment application, for which there is already a record on the bank server about the client’s registration data and the corresponding static identifier of the mobile device.

Once a transaction has been completed, its primary status is unknown, and it is usually processed by the bank. However, when information is received that the transaction was fraudulent in nature (step 202), a corresponding entry is made in the ASFM, and for the generated static identifier of the mobile device from which this transaction was performed, an entry is generated to blacklist it (step 203 ).

This situation can occur if client data is stolen and used by a fraudster to register a payment application on his mobile device.

Upon the fact of a subsequent transaction (step 205), the ASFM checks the corresponding static identifier for its presence in the black list.

Let's look at an example of comparing static identifiers.

The static identifier of the first device is obtained using the following parameters:

- 5 044663

BOARD: COL

BRAND: HONOR

DISPLAY : COL-L29 10.0.0.177(C1OE4R1P4)

CPU ABI: armeabi-v7a/armeabi

CPU ABI2: arm64-v8a

RADIO VERSION : 21C20B369S009C000,21C20B369S009C000

HARDWARE : Hisilicon Kirin970

ID : HUAWEICOL-L29

MANUFACTURER: HUAWEI

MODEL: COL-L29

DEVICE: HWCOL

OUTPUT SIZES: 176x144

HIGHSPEEDSIZES: 1920x1080

MAX FRAME DURATION: 9000000000

CAMERA SENSOR SIZE: 5.16/3.87

CAMERA O FOCAL LENGTH: 3.95

CAMERA O HORIZONTAL ANGLE: 66.302284

CAMERA O VERTICAL ANGLE: 52.19801

KERNEL OS NAME: Linux

KERNEL OS ARCH : aarch64

BOGOMIPS: 3.84

CPU ARCHITECTURE: 8

CPU VARIANT: 0x0

CPU PART: 0xd09

CPU REVISION: 2

MEMTOTAL: 3714672 kV

SWAPTOTAL: 2293756 kV

COMMITLIMIT: 4151092 kV

VMALLOCTOTAL: 263061440 kV

WIDEVINEUUIDSYSTEMJD: 7893

And it looks like:

Wj6tqLi34kZsbPZCi+gGTyrTaHmoAnljGlwMwAxSxOWn:C3+zD3slOXsjJOc:C3FzD3slOXsjJ OcWj6tqLi34kZsbPZCi+gGTyrTaHmoAnljO!wlCYOSxOWn:ClfpwOcWj68LioBPZC iqyrGGJ nlfVxv.

The static identifier of the second device is obtained using the following parameters:

- 6 044663

BOARD: COL

BRAND: HONOR

DISPLAY : COL-L29 10.0.0.177(C1OE4R1P4)

CPU ABI: armeabi-v7a/armeabi

CPU ABI2: arm64-v8a

RADIO VERSION : 21C20B369S009C000,21C20B369S009C000

HARDWARE : Hisilicon Kirin970

ID : HUAWEICOL-L29

MANUFACTURER: HUAWEI

MODEL: COL-L29

DEVICE: HWCOL

OUTPUT SIZES: 176x144

HIGHSPEEDSIZES: 1920x1080

MAX FRAME DURATION: 9000000000

CAMERA SENSOR SIZE: 5.16/3.87

CAMERA O FOCAL LENGTH: 3.95

CAMERA 0 HORIZONTAL ANGLE : 66.302284

CAMERA O VERTICAL ANGLE: 52.19801

KERNEL OS NAME: Linux

KERNEL OS ARCH : aarch64

BOGOMIPS: 3.84

CPU ARCHITECTURE: 8

CPU VARIANT: 0x0

CPUPART: 0xd09

CPU REVISION: 2

MEMTOTAL: 3714673 kV

SWAPTOTAL: 2293757 kV

COMMITLIMIT: 4151092 kV

VMALLOCTOTAL: 263061440 kV

WIDEVINEUUIDSYSTEMJD: 7893

And it looks like:

Wj6tqLi34kZsbPZCi+gGTyrTaHmoAnlj01wMwAxSxOWn:C3+zD3slOXsjJOc:C3FzD3slOXsjJ

OcWj 6tqLi34kZsbPZCi+gGTyrTaHmoAnlj 01 wlCY0Sx0Wn:C 1 fpwOcWj 68LioBPZCiqyrGGJ nlUdAxv.

For both examples of devices, all parameters are the same, except for MEMTOTAL and SWAPTOTAL (differ by 1 KB), respectively, their base identifiers are different: 2be8b842-7c804480-8158-d62a3104bf53 and ee5ebc7f-5b65-41ec-87df-75b74301786f.

When comparing static identifiers using the ssdeep algorithm, it becomes clear that with a 99% probability this is the identifier of the same device.

At the same time, if the appearance of a new identifier for the same user is recorded, but a static identifier indicates that the new identifier is very similar to the previous one, then this makes it possible to additionally take into account such changes in the fraud monitoring system and more quickly respond to possible attempts at fraudulent activity.

At step (206), upon completion of the ASFM check, a decision is made to block or approve the transaction. If it is blocked and the actions are assessed as fraudulent, the bank server also determines the transaction details of the fraudsters, based on the information

-

Claims (11)

information about a completed transaction, which allows you to effectively block subsequent installations of payment applications (when comparing a static identifier with a previously blacklisted one), as well as fraudulent details to prevent the receipt of funds. In fig. 3 shows a general view of a computing system implemented on the basis of a computing device (300). In general, a computing device (300) contains one or more processors (301), memory devices such as RAM (302) and ROM (303), input/output interfaces (304), and input/output devices connected by a common data exchange bus. (305), and a networking device (306). The processor (301) (or multiple processors, multi-core processor) may be selected from a variety of devices commonly used today, such as Intel™, AMD™, Apple™, Samsung Exynos™, MediaTEK™, Qualcomm Snapdragon™, etc. . By processor it is also necessary to take into account a graphics processor, for example an NVIDIA or ATI GPU, which is also suitable for carrying out the method (100) in whole or in part. In this case, the memory means can be the available memory capacity of the graphics card or graphics processor. RAM (302) is a random access memory and is designed to store machine-readable instructions executed by the processor (301) to perform the necessary operations for logical data processing. RAM (302) typically contains executable operating system instructions and associated software components (applications, program modules, etc.). ROM (303) is one or more permanent 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. To organize the operation of device components (300) and organize the operation of external connected devices, various types of I/O interfaces (304) are used. The choice of appropriate interfaces depends on the specific design of the computing device, which can be, but is 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. To ensure user interaction with the computing device (300), various I/O information tools (305) are used, for example, a keyboard, a display (monitor), a touch display, a touch pad, a joystick, a mouse, a light pen, a stylus, a touchpad, trackball, speakers, microphone, augmented reality tools, optical sensors, tablet, light indicators, projector, camera, biometric identification tools (retina scanner, fingerprint scanner, voice recognition module), etc. The network communication means (306) ensures that the device (300) transmits data via an internal or external computer network, for example, an Intranet, the Internet, a LAN, etc. One or more means (306) may be used, but not limited to: Ethernet card, GSM modem, GPRS modem, LTE modem, 5G modem, satellite communication module, NFC module, Bluetooth and/or BLE module, Wi-Fi module and etc. Additionally, satellite navigation tools can also be used as part of the device (300), for example, GPS, GLONASS, BeiDou, Galileo. The submitted application materials disclose preferred examples of implementation of a 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. Information sources. 1. A method for generating a static identifier for mobile devices running Android OS, containing stages in which, using the mobile device processor: install the payment application in the mobile device OS; launch the payment application and register the user in it, while collecting parameters of the mobile device, including: processor parameters, parameter [1] Komblum, J “Identifying almost identical files using context trigger piecewise hashing,” Digital Investigation, vol. 3(S 1), pp. 91-97, 2006 2. The method according to claim 1, characterized in that the processor parameters include at least one of: number of processor cores, processor frequency, processor model, core name, core architecture, supported architecture. [2] C. Sadowsky and G. Levin, “Simhash: Hash-based similarity detection,” Tech. Rep., 2007. [Online], Available: http://simhash. googlecode.com/svn/trunk/paper/SimHashWithBib.pdf 3. The method according to claim 1, characterized in that the parameters of the camera module include at least one of: camera sensor size, camera focal length, horizontal camera alignment angle, vertical camera alignment angle, maximum frame duration. [3] H. Baier and F. Breitinger, “Security aspects of piecewise hashing in computer forensics,” in Sixth International Conference on IT Security Incident Management and IT Forensics (IMF 2001), 2011, pp. 21-36. CLAIM 4. The method according to claim 1, characterized in that the parameters of the memory module include at least one of: the total amount of physical RAM, the total amount of available swap, the total amount of memory from the total allocated virtual address space. 5. The method according to claim 1, characterized in that the radio module parameters include at least one of: DRM scheme identifier, radio module firmware version, base board data. 6. The method according to claim 1, characterized in that the parameters further include at least one of: processor range check parameter, changelog number, manufacturer data, mobile device name, industrial design name, screen resolution, assembly identifier string. 7. A method for identifying fraudulent transactions carried out using mobile devices, wherein the method contains stages in which, using ASFM: record the registration of the payment application on the mobile device; generate a static mobile device identifier according to any of claims 1-6; linking the received identifier with the registration data of the user of the payment application; record the execution of the transaction through the payment application; receive data about a fraudulent transaction through the said payment application; blacklisting at least the received static identifier of the mobile device; block the operation of a payment application on a mobile device containing a blacklisted identifier. 8. The method according to claim 7, characterized in that the details of the accounts to which the fraudulent transaction was carried out are recorded. - 8 044663 camera module parameters, memory module parameters, radio module parameters and at least data on the brand of the mobile device; carry out hashing of the resulting set of parameters using a piecewise hashing algorithm initiated by the context and a block recovery algorithm, while hashing the parameters by each of the algorithms is performed in parallel; generating a static mobile device identifier based on the performed hashing; associate the received identifier with the payment application of a specific user; transmit the received identifier to the server of the automated fraud monitoring system (ASFM). 9. The method according to claim 8, characterized in that account details are added to a black list for subsequent blocking of transactions. 10. A device for generating a static identifier for mobile devices running Android OS, containing at least one processor and at least one memory storing machine-readable instructions, which, when executed by the processor, perform the method according to any of claims 1-6. 11. A system for detecting fraudulent transactions, comprising at least one processor and at least one memory storing machine-readable instructions, which, when executed by the processor, perform the method according to any one of claims 7-9. -