RU2796211C1 - METHOD AND DEVICE FOR FORMING STATIC IDENTIFIER FOR MOBILE DEVICES RUNNING ON iOS, METHOD AND SYSTEM FOR DETECTING FRAUD TRANSACTIONS USING STATIC IDENTIFIER - Google Patents

Abstract

FIELD: information security.

SUBSTANCE: invention is related to methods for generating device identifiers. A method for generating a static identifier for mobile devices running iOS is claimed, comprising the following steps: installing a payment application in the operating system (OS) of the mobile device; launching the payment application and registering the user in it, while collecting parameters of the mobile device, including processor parameters, OS parameters, memory module parameters and battery parameters; translating each received parameter into an array of bits; concatenating the received array of bits of the received parameters; performing hashing of the concatenated array of bits; generating a static mobile device identifier; writing the obtained static identifier into a private memory area of the mobile device; linking the received identifier with the payment application of the specific user; transferring the received identifier to the server of the automated fraud monitoring system.

EFFECT: increasing the accuracy of identifying mobile devices by generating a static identifier.

11 cl, 3 dwg, 4 tbl

Description

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] Mobile Device Identification (MU) is a process of generating persistent features, which make it possible to establish the identity of an unknown device with a known one based on the coincidence of features. Thus, during the initial formation of MU identifiers, unique device values are generated, the uniqueness of which is guaranteed by the identifier generation algorithm (the space of options is 2 ¹²⁸ ).

[0004] Modern mobile devices (smartphones) are high-performance multifunctional devices with a full user interface and many different radio interfaces. MU manufacturers generate various internal device identifiers (OS level, interfaces, hardware components), which cannot be accessed at the level of application software installed on MU, or they do not provide a sufficient level of uniqueness or stability.

[0005] The Apple® privacy policy has a number of serious restrictions for applications installed on MU (https://support.apple.com/rii-ru/HT211970), namely:

- closed API and the inability to obtain meaningful data about the MU hardware (current CPU load, partly GPU, partly Memory, clock frequency, etc.);

- opt in - a principle that restricts the receipt of IDFA (ID of applications MU) without the explicit consent of the user to provide data to a specific application;

- application markers - a principle that determines the type of personal data collected and processed by a mobile application. Blocking the operation of the application when identifying data that goes beyond the declared marking.

[0006] A study of existing solutions for identifying MUs under the control of iOS led to the conclusion that there are two main methods:

1) Identification based on the Unique Device Identifier (UDID), assigned to the MU directly by the manufacturer and required for registration in the Apple Developer Portal. Solutions using this method include: IFunBox and SuperUDID. However, the main disadvantage is that UDID needs to install special software on an external device, such as a computer, to which the mobile device needs to be connected;

2) hardware-based identification (IDFV and IDFA) received at the application software level. Solutions using this method include RSA, BiZone and others. This method is also inappropriate to use to identify the MU, since when the device is reset to factory settings, the identifier also changes.

[0007] Since the existing methods for generating identifiers do not have a sufficient degree of stability, or are not applicable as PROM solutions, it was decided to search for and test our own method for identifying the MU.

предназначенный для хранения пользовательской информации в закрытой области памяти.[0008] As a result of the research, no solution has been identified that would allow the formation of a strong device identifier running iOS, which would be resistant to changes in the hardware configuration of the MU, for example, a restored MU. In the iOS system, the Keychain Services API service is used to store and use MU identifiers

designed to store user information in a closed area of memory.

[0009] This functionality allows applications to store a few bits of user data in an encrypted database called the Keychain. This database is not limited to password information, it can also store any other information that is important to the user, as well as items that the user needs, but the existence of which he may not know. For example, cryptographic keys and certificates that are managed and used by certificate and key services and that allow a user to participate in secure communications and establish trust relationships with other users and devices.

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

[0011] 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 a more unique ID to be used for authentication purposes .

[0012] 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. These data are quite vulnerable and do not allow generating a static identifier based on them, which will not change significantly during a factory reset of devices, its hardware modification, etc.

SUMMARY OF THE INVENTION

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

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

[0015] The claimed solution is carried out using a method for generating a static identifier for mobile devices running iOS, while the method contains the steps at which, using the processor of the mobile device:

install the payment application in the operating system (OS) of the mobile device;

launching the payment application and registering the user in it, while collecting the parameters of the mobile device, including: processor parameters, OS parameters, memory module parameters and battery parameters;

translate each received parameter into an array of bits;

carry out concatenation of the received array of bits of the obtained parameters; performing hashing of the concatenated array of bits;

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

writing the obtained static identifier into a private memory area of the mobile device;

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).

[0016] In one particular implementation, the processor parameters include at least one of: processor name, processor nominal frequency, number of physical cores, number of logical cores, system processor utilization percentage, user processor utilization percentage, idle processor utilization percentage.

[0017] In another particular implementation example, the OS parameters include at least one of: launch flag, language code on the device, region code on the device, time zone code on the device, device family, device full name, device version in the family, operating system code name systems, release version, system kernel version, processor architecture, number of processes, number of threads.

[0018] In another particular implementation, the memory module parameter includes at least the physical size of the device's RAM.

[0019] In another particular implementation, the battery parameters include at least one of: battery capacity, maximum battery capacity, design battery capacity.

[0020] In another particular implementation, the hashing algorithm is the SHA256 algorithm.

[0021] The claimed solution is also carried out using a method for detecting fraudulent transactions carried out using mobile devices, while the method includes the steps of:

using ASFM:

registering the payment application on the mobile device; generating a static mobile device identifier;

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.

[0022] In another particular implementation example, the details of the accounts to which the fraudulent transaction was made are recorded.

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

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

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

BRIEF DESCRIPTION OF THE DRAWINGS

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

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

[0028] FIG. 3 illustrates a diagram of a computing device.

IMPLEMENTATION OF THE INVENTION

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

[0030] After installing a payment application, for example, Sberbank Online, the program logic of the application 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.

[0031] 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, OS parameters, memory module parameters, and battery parameters.

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

[0033] The processor parameters may be selected from the following data presented in Table 1.

[0034] An example of OS parameters used is shown in Table 2.

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

[0036] An example of battery parameters used is shown in Table 4.

After collecting the required set of the above parameters, at step (103) their subsequent hashing is carried out using, for example, the SHA256 algorithm.

[0037] 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 iOS updates;

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

[0038] 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. This solution uses the SHA256.3 cryptographic hashing algorithm to minimize possible further restrictions on the collection of system parameters by iOS, as well as any other changes that may occur with the system parameters of a mobile device during operation (for example, hardware replacement of a camera or processor in device).

[0039] In step (103), the received parameters necessary to generate the identifier form an array of bits by concatenating their bit values. An array of bits might look like this:

65 110 100 114 111 105 100 58 116 101 115 116 47 88 105 97 111 109 105 58 77 73 49 48 84 32 80 114 111 47 67 80 85 58 83 111 109 101 32 67 80 85

The resulting array is processed by the UUID generator by hashing it with the SHA256 algorithm.

[0040] As a result of hashing at step (104), a static identifier is generated, which is written to the keychain library for this device, as well as to the closed memory area of the MU. The identifier may look like this: 123e4567-e89b-12d3-a456-426655440000.

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

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

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

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

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

[0046] Upon completion of a transaction, 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).

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

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

[0049] Consider an example of generating static identifiers. The static ID of the first device was obtained using the following parameters:

PROCESSOR NAME: A11

PROCESSOR FREQ: 2.39 GHz

PHYSICAL CORES: 6

LOGICAL CORES: 6

SYSTEM: 23

USER: 42

IDLE: 35

IS PROCESS TRANSLATED: native

ISO LANGUAGE CODE: 597

ISO REGION CODE: 256

KNOWN TIMEZONE ID: 441

DEVICE: iPhone

FULL NAME: iPhone 8 Plus

VERSION: 10.2

RELEASE: 3.95 MACHINE: ARM

UPTIME: 56078

PROCESSES: 15

THREADS: 21

LOAD AVERAGE: 34

HARDWARE ID: 9E621041-7F2E-43C3-B1A7-BCD8B5632F18

PHYSICAL SIZE: 17179869184

FREE: 1979920384

WIRED: 4351307776

ACTIVE: 4953337856

INACTIVE -.4873920512

AC POWERED: true

CHARGED: false

CHARGING: true

CHARGE: 0.83

CAPACITY: 7893

MAX CAPACITY: 7893

DESIGN CAPACITY: 1420

CYCLES: 524

TEMPERATURE: 32

SHA256 looks like this:

D4413EB8DC76D9208F4466F42660E37DA1F737E3CA7786FEF413B492A21CAF78

UUID looks like

4iffe8a2-f474-3418-80fl-lall13336479

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

PROCESSOR NAME: A14

PROCESSOR FREQ: 3.1

GHz PHYSICAL CORES: 6

LOGICAL CORES: 6

SYSTEM: 18

USER: 5

IDLE: 28

IS PROCESS TRANSLATED: native

ISO LANGUAGE CODE: 597

ISO REGION CODE: 256

KNOWN TIMEZONE ID: 441

DEVICE: iPhone

FULL NAME: iPhone 12 Pro Max

VERSION: 13.4

RELEASE: 3.95

MACHINE: ARM

UPTIME: 51231

PROCESSES: 12

THREADS: 15

LOAD AVERAGE: 30

HARDWARE ID: 70CD060B-B30A-46DD-A210-2771C8B80E57

PHYSICAL SIZE: 17179869184

FREE: 1979920384

WIRED -.4351307776

ACTIVE: 4953337856

INACTIVE: 4873920512

AC POWERED: true

CHARGED: false

CHARGING: true

CHARGE: 0.83

CAPACITY: 7893

MAX CAPACITY: 7893

DESIGN CAPACITY: 1420

CYCLES: 524

TEMPERATURE: 32

SHA256 is:

8899FE3A92BE1EF6446E415E025B9B7C40E2F76F0351A7C34044D810C5CED8A1

UUID looks like

48ec3487-dlbc-3444-abbl-c4c03e49bc31

[0051] The resulting static identifiers are written to the secure memory of each of the mobile devices.

[0052] At the same time, if the appearance of a new identifier for the same user is recorded, but the static UUID 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 of fraudulent activity.

[0053] At step (206), upon completion of the ASPM check, a decision is made to block or approve the transaction. If it is blocked and actions are regarded as fraudulent, the bank server also determines the transaction details of fraudsters based on information about the transaction, which allows both 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 on them.

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

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

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

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

[0058] 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 the appropriate interfaces depends on the particular design of the computing device, which can be, but not limited to: PCI, AGP, PS/2, IrDa, Fire Wire, 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.

[0059] To ensure user interaction with the computing device (300), various means (305) of I/O information 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 tools (retinal scanner, fingerprint scanner, voice recognition module), etc.

[0060] The networking means (306) enables data to be transmitted 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

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

[0062] 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 (27)

1. A method for generating a static identifier for mobile devices running iOS, comprising the steps at which, using the processor of the mobile device: install the payment application in the operating system (OS) of the mobile device; launching the payment application and registering the user in it, while collecting the parameters of the mobile device, including: processor parameters, OS parameters, memory module parameters and battery parameters; carry out the concatenation of the received parameters; forming an array of bits based on the concatenation of the parameters; perform hashing of the resulting array of bits; generating a static identifier of the mobile device based on the performed hashing; writing the obtained static identifier into a private memory area of the mobile device; 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: the name of the processor, the nominal frequency of the processor, the number of physical cores, the number of logical cores, the percentage of processor utilization by the system, the percentage of processor utilization by the user, the percentage of processor utilization in simple. 3. The method according to claim 1, characterized in that the OS parameters include at least one of: start flag, language code on the device, region code on the device, time zone code on the device, device family, full device name, device version in the family , operating system code name, release version, system kernel version, processor architecture, number of processes, number of threads. 4. The method according to claim 1, characterized in that the parameter of the memory module includes at least the physical size of the RAM of the device. 5. The method according to claim 1, characterized in that the battery parameters include at least one of: battery capacity, maximum battery capacity, design battery capacity. 6. The method according to claim 1, characterized in that the hashing algorithm is the SHA256 algorithm. 7. A method for detecting fraudulent transactions carried out using mobile devices, the method comprising the steps of: using ASFM: registering the payment application on the 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 iOS mobile devices, 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.

Images