WO2023149816A1

WO2023149816A1 - Method for generating a static identifier for mobile devices

Info

Publication number: WO2023149816A1
Application number: PCT/RU2022/000367
Authority: WO
Inventors: Дмитрий Николаевич ГУБАНОВ; Артём Александрович ШИРОКОВ; Иван Александрович ОБОЛЕНСКИЙ; Максим Геннадьевич ДЕНИСЕНКО; Владимир Владимирович ЯКУШЕВ
Original assignee: Публичное Акционерное Общество "Сбербанк России"
Priority date: 2022-02-04
Filing date: 2022-12-13
Publication date: 2023-08-10

Abstract

The claimed invention relates to the field of computer technology, and more particularly to methods for generating device identifiers for use in the field of data protection. A method (100) for generating a static identifier for mobile devices comprises the following steps performed with the aid of a processor: installing a payment application in the operating system of a mobile device (101); launching the payment application and registering a user therein, which includes collecting parameters of the mobile device (102), including: processor parameters, camera module parameters, memory module parameters, radio module parameters and at least the brand details of the mobile device; hashing the obtained set of parameters (103) using a context triggered piecewise hashing algorithm and a block recovery algorithm, wherein parameter hashing is performed by each of the algorithms in parallel; generating a static identifier for the mobile device on the basis of the performed hashing (104); linking the obtained identifier with the payment application of the specific user (105); transmitting the obtained identifier to a server of an automated fraud monitoring system (AFMS) (106). The invention is directed toward improving the accuracy of identification of mobile devices by generating a static identifier.

Description

METHOD FOR FORMING STATIC IDENTIFIER OF MOBILE DEVICES

FIELD OF TECHNOLOGY

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

BACKGROUND OF THE INVENTION

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

[0003] This problem is especially critical for mobile devices running OCAndroid. The banking mobile application provides the ability to receive a mobile device ID 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 performs additional verification of the client when making transactions, and if there are discrepancies in the client's identifiers, it can suspend or reject the transaction as suspicious.

[0004] The Android operating system (hereinafter referred to as OS) 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 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] Attackers, using various methods of influencing bank customers, including social engineering, can gain access to critical data customers, then this data can be used to install banking applications on the attacker's device with further registration with the bank. An attacker, after registering such an application on his device on behalf of the client, gains access to the client's funds and then attempts to steal these funds.

[0006] There are approaches regarding 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 the user's registration data of various accounts, thereby allowing the formation of a more unique ID for use for authentication .

[0007] 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, and the like. This data is quite vulnerable and does not allow generating a static identifier based on it, which will not change significantly during a factory reset of devices, also, starting from version 1 of the Android OS, this kind of data is not available to mobile applications.

SUMMARY OF THE INVENTION

[0008] The claimed invention solves the technical problem in terms of creating a new robust and stable mobile device identifier for its subsequent use to track fraudulent activity.

[0009] The technical result is to increase the accuracy of identifying mobile devices by generating a static identifier.

[0010] The claimed solution is implemented using a method for generating a static identifier for mobile devices running the Android OS, comprising the steps of: installing a payment application in the OS of the mobile device using the processor of the mobile device; launching the payment application and registering the user in it, while collecting mobile device parameters, including: processor parameters, camera module parameters, memory module parameters, radio module parameters, and at least mobile device brand data; carry out hashing of the obtained set of parameters using the piecewise hashing algorithm initiated by the context and the block hashing algorithm recovery, while the hashing of the parameters by each of the algorithms is performed in parallel; generating a static identifier of the mobile device based on the performed hashing; linking the received identifier with the payment application of a particular user; transfer the received identifier to the server of the automated fraud monitoring system (AFMS).

[OOP] In one particular embodiment 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.

[0012] In another particular embodiment of the method, the parameters of the camera module include at least one of: camera sensor size, camera focal length, horizontal camera offset angle, vertical camera offset angle, maximum frame duration.

[0013] In another particular embodiment 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.

[0014] In another particular embodiment of the method, the radio module parameters include at least one of: DRM scheme identifier, radio module firmware version, baseboard data.

[0015] In another particular embodiment of the method, 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 ID string.

[0016] The claimed solution is also carried out using a method for detecting fraudulent transactions carried out using mobile devices, the method comprising the steps of: using ASFM: fixing the registration of a payment application on a mobile device; generating a static identifier of the mobile device in the above manner; associating the received identifier with the registration data of the user of the payment application; fixing the execution of the transaction through the payment application; receive data on the completion of a fraudulent transaction through said payment application; blacklisting at least the obtained static identifier of the mobile device; block the operation of the payment application on a mobile device containing a blacklisted identifier.

[0017] In one of the particular examples of the implementation of the method, the details of the accounts to which the fraudulent transaction was made are recorded.

[0018] In another particular example of the implementation of the method, account details are blacklisted for subsequent blocking of transactions.

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

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

BRIEF DESCRIPTION OF THE DRAWINGS

[0021] FIG. 1 illustrates a flowchart of a method for generating a static identifier.

[0022] FIG. 2 illustrates a flow diagram of a method for tracking fraudulent transactions using a static identifier.

[0023] FIG. 3 illustrates a diagram of a computing device. IMPLEMENTATION OF THE INVENTION

[0024] In FIG. 1 is a flowchart of the steps of the method (100) for generating a static identifier. The claimed solution is executed when installing the payment application at step (101) in the OS of the mobile device. The term "mobile device" in the framework of the claimed solution can be understood as a smartphone, phablet or tablet running the Android OS.

[0025] After installing a payment application, for example, Sberbank Online, the application program logic requests data for subsequent user registration. Such data may be, full name, passport data, payment card number, phone number, login / password for entering the application, etc. Additionally, biometric information can 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.

[0026] After registering with the application, at step (102), mobile device data is collected. The collection is carried out through the program logic of the payment application that has access to the OS of the mobile device. 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.

[0027] Mobile device data is collected on the main hardware modules (processor, memory, camera, radio module), as well as system data that identifies the device itself.

[0028] Processor parameters may be selected from the following data presented in Table 1.

Table 1. Processor parameters

[0029] An example of the parameters of the camera module used are shown in Table 2.

Table 2. Camera parameters

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

Table 3. Memory module options

[0031] An example of the radio parameters used is shown in Table 4.

Table 4. Radio module parameters

[0032] Also, additionally, the system parameters shown in Table 5 are used to generate the identifier. Table 5. System parameters

[0033] Upon collection of the required set of the above parameters, at step (103) their subsequent hashing is carried out. The Android OS allows you to receive these parameters without additional permissions from the owner of the mobile device. [0034] This list of parameters allows you to achieve:

- uniqueness of received identifiers, even on the same devices of the same manufacturer;

- invariability of the identifier on any device, even with minor and major updates of the Android OS;

- reproducibility (repeatability of results) of the identifier for various types of resets of the mobile device to factory and subsequent device restores.

[0035] Depending on the type of tasks being solved, the identifier obtained on the above parameters can be static and / or probabilistic, this is achieved through the use of various data conversion algorithms. The present 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 by the Android OS, as well as any other changes that may arise with the system parameters of the mobile device during operation (for example, hardware replacement of the camera or processor in the device).

[0036] In step (103), two modified similarity-preserving hash functions are applied: ssdeep [1] and SimHash [2]. Initially, these algorithms were developed for the tasks of computer forensics, namely: the acceleration and automation of the analytics of the content of a particular electronic document, as well as the formalization and presentation of the obtained evidence in court. Ssdeep refers to context-initiated piecewise hashing algorithms, i.e. during hashing, a hash is generated 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 additional comparison of the obtained numerical characteristics of the distances, you can choose both the minimum value, which will mean that the received identifiers can refer to one device, and the maximum values, which will indicate that these are identifiers of different devices.

[0037] The essence of the modification of the algorithms used in the claimed solution lies in the fixed sampling positions (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 algorithms ssdeep and SimHash calculate regardless of the size and presence of strings for each of the system parameters. For example, when you change the camera on the device, the identifier of the mobile device will change, but thanks to hashing algorithms with similarity preservation, you can determine the most probable (closest) identifier that the device had earlier, 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 at once, 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 intruders on algorithms [3].

[0038] At step (104), a static mobile device identifier is generated as a result of applying the hash functions. The identifier may look like this: OcWj6tqLi34kZsbPZCi+gGTyrTaHmoAnlj01wlCYOSxOWn:ClfpwOcWj68LioBPZCiqyrG GJ nlfVxv.

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

[0040] If anomalies (changes) are detected in the client's identifiers, the bank can suspend or reject the transaction as suspicious, thereby preventing possible fraud (theft of funds or property) in relation to the bank's client.

[0041] The uniqueness of the claimed approach lies in the formation of an identifier that simultaneously combines several properties:

- Static - resistant to changes in the OS on mobile devices and does not require additional permissions for the mobile payment application.

- Probabilistic stability - in the event of a change in the approach of OS developers for mobile devices, the available characteristics necessary for generating an identifier remain.

[0042] The information generated at step (105) recorded on the bank server is transmitted at step (106) to the server of the automated fraud monitoring system (AFMS). The bank's automated fraud monitoring system analyzes and detects anomalies in the transaction flow of customers, placing the identifiers of the attackers' mobile devices on the "black" lists, thereby preventing further installation and registration of payment applications on the devices of the attackers.

[0043] In FIG. 2 shows an example of the operation of the method (200) for tracking fraudulent transactions using the above-described method for generating a static identifier. At the first stage (201), the ASFM fixes 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. [0044] Once a transaction has been made, 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), then the corresponding entry is made in the ASFM, and for the generated static identifier of the mobile device from which this transaction was performed, a record is formed about entering it into the black list (step 203).

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

[0046] Upon the fact of the subsequent transaction (step 205), ASPM checks the corresponding static identifier for its presence in the black list.

[0047] Consider an example of comparing static identifiers.

[0048] The static identifier of the first device is obtained from the following parameters:

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

HIGH SPEED SIZES : 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

WIDEVINE UUID SYSTEM ID : 7893

And looks like:

Wj6tqLi34kZsbPZCi+gGTyrTaHmoAnlj01wMwAxSxOWn:C3+zD3slOXsjJOc:C3FzD3slOXsjJ

OcWj6tqLi34kZsbPZCi+gGTyrTaHmoAnlj01wlCYOSxOWn:ClfpwOcWj68LioBPZCiqyrGGJ nlfVxv.

[0049] The static identifier of the second device is obtained from the following parameters:

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

HIGH SPEED SIZES : 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 : 3714673 kV

SWAPTOTAL : 2293757 kV

COMMITLIMIT : 4151092 kV

VMALLOCTOTAL : 263061440 kV

WIDEVINE UUID SYSTEM ID : 7893

And looks like:

Wj6tqLi34kZsbPZCi+gGTyrTaHmoAnlj01wMwAxSxOWn:C3+zD3slOXsjJOc:C3FzD3slOXsjJ OcWj6tqLi34kZsbPZCi+gGTyrTaHmoAnljO 1 wlCY0Sx0Wn:C 1 fpwOcWj68LioBPZ CiqyrGGJ nlUdAxv.

[0050] For both examples of devices, all parameters are the same, except for MEMTOTAL and SWAPTOTAL (they differ by 1 KB), respectively, they have different basic identifiers: 2be8b842-7c80-4480-8158-d62a3104bf53 and ee5ebc7f-5b65-41ec-87df-75b74301786f.

When comparing static identifiers using the ssdeep algorithm, it becomes clear that with a probability of 99% 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 the static identifier indicates that the new identifier is very similar to the previous one, then this allows you to additionally take into account such changes in the fraud monitoring system and more quickly respond to possible attempts at fraudulent activity.

[0051] At step (206), upon completion of the ASPM check, a decision is made to block or approve the transaction. If it is blocked and the actions are regarded as fraudulent, the bank server also determines the transaction details of fraudsters, based on information about the transaction, which allows you to effectively block subsequent installations of payment applications (when comparing a static identifier with a previously blacklisted one), and fraudulent details to prevent the receipt of funds for them.

[0052] In FIG. 3 shows a general view of the computing system implemented on the basis of the computing device (300). In general, the computing device (300) contains one or more processors (301) connected 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 networking (306).

[0053] The processor (301) (or multiple processors, multi-core processor) may be selected from a variety of devices currently widely used, such as Intel™, AMD™, Apple™, Samsung Exynos™, MediaTEK™, Qualcomm Snapdragon™, and etc. Under the processor, it is also necessary to take into account a graphics processor, for example, an NVIDIA or ATI GPU, which is also suitable for the full or partial execution of the method (100). In this case, the memory means can be the available memory capacity of the graphics card or graphics processor.

[0054] RAM (302) is a random access memory and is designed to store machine-readable instructions executable by the processor (301) to perform the necessary data logical processing operations. The RAM (302) typically contains the executable instructions of the operating system and associated software components (applications, program modules, etc.).

[0055] A ROM (303) is one or more persistent 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.

[0056] Various types of I/O interfaces (304) are used to organize the operation of device components (300) and organize the operation of external connected devices. The choice of appropriate interfaces depends on the particular design of the computing device, which can be, but 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.

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

[0058] The network communication means (306) enables data communication by the device (300) via an internal or external computer network, such as an Intranet, Internet, LAN, and the like. As one or more means (306) can 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 others

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

[0060] The submitted application materials disclose preferred examples of the implementation of the technical solution and should not be construed 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] Komblum, J “Identifying almost identical files using context trigger piecewise hashing,” Digital Investigation, vol. 3(S 1 ), pp. 91-97, 2006

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

Claims

FORMULA

1. A method for generating a static identifier for mobile devices running the Android OS, comprising the steps of: using the processor of the mobile device: installing a payment application in the OS of the mobile device; launching the payment application and registering the user in it, while collecting mobile device parameters, including: processor parameters, camera module parameters, memory module parameters, radio module parameters, and at least mobile device brand data; carrying out hashing of the obtained set of parameters using a piecewise hashing algorithm initiated by the context, and a block recovery algorithm, with the hashing of the parameters by each of the algorithms is performed in parallel; generating a static identifier of the mobile device based on the performed hashing; linking the received identifier with the payment application of a specific user; transmitting the received identifier to the server of the automated fraud monitoring system (AFMS).

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.

3. The method according to claim 1, characterized in that the camera module parameters include at least one of: camera sensor size, camera focal length, horizontal camera offset angle, vertical camera offset angle, maximum frame duration.

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 of claim 1, wherein 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 ID string.

7. A method for detecting fraudulent transactions carried out using mobile devices, the method comprising the steps of: using ASFM: fixing the registration of a payment application on a mobile device; form a static identifier of the mobile device according to any one of paragraphs. 1-6; associating the received identifier with the registration data of the user of the payment application; fixing the execution of the transaction through the payment application; receive data on the completion of a fraudulent transaction through said payment application; blacklisting at least the obtained static identifier of the mobile device; block the operation of the 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 made are recorded.

9. The method according to claim 8, characterized in that the account details are blacklisted for subsequent blocking of transactions.

10. A device for generating a static identifier for mobile devices running the Android OS, comprising at least one processor and at least one memory storing machine-readable instructions that, when executed by the processor, perform the method according to any one of paragraphs. 1-6.

11. A system for detecting fraudulent transactions, comprising at least one processor and at least one memory storing machine-readable instructions that, when executed by the processor, perform the method according to any one of paragraphs. 7-9.