СПОСОБ И СИСТЕМА ОПРЕДЕЛЕНИЯ ИСПОЛЬЗОВАНИЯ ДОВЕРЕННОГО МОБИЛЬНОГО ПРИЛОЖЕНИЯ НА МОБИЛЬНОМ УСТРОЙСТВЕ ПОЛЬЗОВАТЕЛЯ ПОД УПРАВЛЕНИЕМ OC ANDROID Российский патент 2024 года по МПК G06F21/44 G06F21/16 

ОБЛАСТЬ ТЕХНИКИ

[0001] Заявленное решение относится к области компьютерной техники, в частности к методам защиты данных, а именно к методам формирования сессионных идентификаторов для определения применения доверенных мобильных приложений.

УРОВЕНЬ ТЕХНИКИ

[0002] В настоящее время применение мобильный приложений для получения финансовых услуг является широко используемым способом взаимодействия пользователей с банками. Однако с массовым распространением получения услуг в цифровом формате возросло также и количество мошеннической активности, направленной на хищение средств пользователей, что обуславливает необходимость разработки новых средств защиты пользователей от действий мошенников.

[0003] Особенно критичной данная проблема является для мобильных устройств под управлением ОС Android. Банковское мобильное приложение предоставляет возможность получать идентификатор мобильного устройства и передавать его в информационные системы банка. Данная возможность по умолчанию предоставляется всем приложениям, установленным на мобильном устройстве. На основе этого идентификатора банк осуществляет дополнительную верификацию клиента при совершении транзакций и при наличии расхождений в идентификаторах клиента, может приостановить, либо отклонить транзакцию, как подозрительную.

[0004] Операционная система (далее - ОС) Android начиная с 10 версии и выше, в целях повышения конфиденциальности пользователей мобильных устройств ограничила доступ к не сбрасываемым (статичным) идентификаторам устройств, в том числе для приложений, установленных и работающих на устройстве. При сбросе устройства до заводских настроек, идентификатор, доступный установленным на устройстве приложениям, изменяется. Таким образом, однозначная идентификация клиентского мобильного устройства на стороне банка не представляется возможной.

[0005] Как правило, взаимодействие клиента с банком осуществляется посредством банковского мобильного приложения (далее - МП), устанавливаемого на своем мобильном устройстве (далее - МУ), которое работает под управлением ОС Android. Клиенты не всегда могут получить достоверную информацию и использовать доверенные ресурсы по установке МП, что приводит к случаям, когда на МУ может быть установлено модифицированное банковское мобильное приложение (далее - МБМП), использующее общедоступные банковские протоколы клиент-серверного взаимодействия (mobile API). Данные мобильные приложения не являются официальными банковскими приложениями и представляют собой либо самостоятельные приложения - агрегаторы банковских услуг, либо несанкционированно модифицированное программное обеспечение банка, полученное путем реверс-инжиниринга исходного банковского приложения. МБМП являются угрозой кибербезопасности как клиентов, устанавливающих данное ПО, так и для всего банка в целом, так как могут нести в себе уязвимости и недекларированные возможности, которыми могут воспользоваться злоумышленники.

[0006] Программный интерфейс банковского мобильного приложения (далее - mAPI) представляет собой сложную структуру и набор правил, по которым осуществляется клиент-серверное взаимодействие всех клиентов, использующих МУ. Таким образом, для обеспечения максимальной совместимости и бесперебойной работы всех сервисов и услуг на всех устройствах под управлением ОС Android mAPI является открытым и общедоступным как для крупных разработчиков мобильных приложений и устройств, так и для частных исследователей и программистов.

[0007] Злоумышленники, а также компании-разработчики мобильных приложений, используя доступ к описанию, структуре и самому mAPI, создают МБПМ. При работе данных мобильных приложений осуществляется клиент-серверное взаимодействие с процессинговыми банковскими системами, которое на стороне банка идентично взаимодействию нативных (официальных) банковских приложений. Таким образом, банк не имеет технической возможности идентифицировать (отличить) операции и транзакции, совершенные в МБМП от операций, совершенных в нативных приложениях.

[0008] Современные нативные банковские мобильные приложения (далее - НБМП) помимо бизнес-функционала содержат в себе функции (средства) по анализу, защите и предотвращению хакерских и\или финансовых атак как на клиентов банка, так и на весь банк в целом. К таким средствам относятся встроенные антивирусные средства, защита от несанкционированной и назойливой рекламы, выявление устройств с root-правами и многое другое. Клиенты, используя МБМП без вышеописанных средств защиты, значительно увеличивают риски кибербезопасности, как свои, так и банка в целом.

[0009] Существующие решения в части реализации подходов в части безопасного проведения транзакций, как правило, направлены на контролирование доверенности самого факта транзакции, совершаемого с надлежащего устройства, используя при этом, например, обмен ключами доступа, имеющими краткосрочный срок службы. Пример такого решения раскрыт в патенте US 10915902 В2 (Bell Identification BV, 09.02.2021).

[0010] Существенной проблемой существующих подходов является ключевое использование цифровой информации и базовых аппаратных номеров мобильных устройств, например, IMEI, серийный номер и т.п.Эти данные достаточно уязвимы, для чего предлагается на основании аппаратных параметров МУ формировать сессионный идентификатор при выполнении транзакций, который будет являться более надежным подтверждением того, что взаимодействие с банком пользователем осуществляется через НБМП.

СУЩНОСТЬ ИЗОБРЕТЕНИЯ

[0011] Заявленное изобретение позволяет решить техническую проблему в части создания нового робастного и устойчивого сессионного идентификатора (СИД) мобильного устройства для последующего его применения для отслеживания использования доверенных мобильных приложений.

[0012] Техническим результатом является повышение эффективности определения использования доверенных мобильных приложений.

[0013] Заявленное решение осуществляется с помощью способа определения использования доверенного мобильного приложения (МП) на мобильном устройстве (МУ) пользователя под управление ОС Android, содержащего этапы, на которых: получают данные о входе пользователя в МП;

a) получают данные о входе пользователя в МП;

b) формируют запрос от МУ на сервер для получения списка параметров и алгоритма построения последовательности параметров для формирования сессионного идентификатора МП на МУ, при этом список параметров включает в себя следующие параметры МУ: параметры процессора, параметры камеры, параметры модуля памяти, параметры радиомодуля, системные параметры;

c) формируют на сервере сессионный идентификатор для МУ на сновании данных, переданных на МУ на этапе b), и выполняют его запись в базу данных (БД) для соответствующего МУ;

d) формируют на МУ сессионный идентификатор для МП на основании данных, полученных на этапе b), с помощью шифрования полученной последовательности параметров и принципа ее построения;

e) отправляют сформированный на этапе d) сессионный идентификатор на сервер и осуществляют его дешифрование;

f) выполняют сравнение полученного в ходе дешифрации сессионного идентификатора МП с сессионным идентификатором, хранящимся в БД;

g) определяют степень доверенности МП на основании сравнения сессионных идентификаторов.

[0014] В одном из частных примеров реализации способа алгоритм построения последовательности параметров представляет собой алгоритм рандомизации.

[0015] В другом частном примере реализации способа на этапе d) применяется алгоритм асимметричного шифрования (RSA).

[0016] В другом частном примере реализации способа, в случае если МП является недоверенным, то сервер осуществляет мониторинг операций, совершаемых в МП на МУ.

[0017] В другом частном примере реализации способа сервер осуществляет формирование уведомления для МУ, что МП является недоверенным.

[0018] В другом частном примере реализации способа уведомление содержит ссылку на скачивание доверенного МП.

[0019] В другом частном примере реализации способа в ходе мониторинга выполняется блокирование транзакционных операций.

[0020] В другом частном примере реализации способа дополнительно формируют статичный идентификатор МУ с помощью сбора параметров МУ, включающих в себя: параметры процессора, параметры модуля камеры, параметры модуля памяти, параметры радиомодуля, и по меньшей мере данные марки мобильного устройства, и последующего хэширования полученного набора параметров.

[0021] В другом частном примере реализации способа статичный идентификатор записывается в БД сервера.

[0022] Заявленный технический результата также достигается за счет системы определения использования доверенного мобильного приложения (МП) на мобильном устройстве (МУ) пользователя под управление ОС Android, в которой:

МУ выполнено с возможностью

получать данные о входе пользователя в МП;

формировать запрос от МУ на сервер для получения списка параметров и алгоритма построения последовательности параметров для формирования сессионного идентификатора МП на МУ, при этом список параметров включает в себя следующие параметры МУ: параметры процессора, параметры камеры, параметры модуля памяти, параметры радиомодуля, системные параметры;

формировать сессионный идентификатор для МП на основании данных, полученных в ответ на отправленный запрос от МУ, с помощью шифрования полученной последовательности параметров и принципа ее построения;

отправлять сформированный сессионный идентификатор МП на сервер; сервер выполнен с возможностью

формирования на сервере сессионного идентификатора для МУ на сновании данных, переданных на МУ в ответ на поступивший запрос, и выполняют его запись в базу данных (БД) для соответствующего МУ;

дешифровки сформированного сессионного идентификатора МП, получаемого от МУ;

сравнения полученного в ходе дешифрации сессионного идентификатора МП с сессионным идентификатором, хранящимся в БД;

определения степени доверенности МП на основании сравнения сессионных идентификаторов.

[0023] В одном из частных примеров реализации системы, в случае если МП является недоверенным, то сервер осуществляет мониторинг операций, совершаемых в МП на МУ.

[0024] В другом частном примере реализации системы сервер осуществляет формирование уведомления для МУ, что МП является недоверенным.

[0025] В другом частном примере реализации системы уведомление содержит ссылку на скачивание доверенного МП.

[0026] В другом частном примере реализации системы в ходе мониторинга выполняется блокирование транзакционных операций.

[0027] В другом частном примере реализации системы дополнительно формируют статичный идентификатор МУ с помощью сбора параметров МУ, включающих в себя: параметры процессора, параметры модуля камеры, параметры модуля памяти, параметры радиомодуля, и по меньшей мере данные марки мобильного устройства, и последующего хэширования полученного набора параметров.

[0028] В другом частном примере реализации системы статичный идентификатор записывается в БД сервера.

КРАТКОЕ ОПИСАНИЕ ЧЕРТЕЖЕЙ

[0029] Фиг. 1 иллюстрирует общую схему работы решения.

[0030] Фиг. 2 иллюстрирует блок-схему реализации способа определения степени доверенности мобильного приложения.

[0031] Фиг. 3 иллюстрирует блок-схему способа отслеживания транзакций.

[0032] Фиг. 4 иллюстрирует схему вычислительного устройства.

ОСУЩЕСТВЛЕНИЕ ИЗОБРЕТЕНИЯ

[0033] На Фиг. 1 представлен общий вид схемы реализации заявленного решения, которое включает в себя МУ пользователя (110), соединенный каналом передачи данных (130) с сервером (120), выполняющим обработку данных через API. В качестве МУ (110) может применяться смартфон, фаблет или планшет под управление ОС Android, на котором установлено МП (например, Сбербанк Онлайн). В части канала передачи данных (130) применяется сеть «Интернет», обеспечивая обмен данными между МУ (110) и сервером (120).

[0034] На Фиг. 2 представлена блок-схема выполнения этапов способа (200) определения степени доверенности мобильного приложения. После установки платежного МП (201), например, Сбербанк Онлайн, программная логика приложения запрашивает данные для последующей регистрации пользователя. Такими данными могут являться, ФИО, паспортные данные, номер платежной карты, номер телефона, логин/пароль для входа в приложение и т.п. Дополнительно может применяться биометрическая информация. После успешной регистрации для каждого пользователя создается уникальная запись под соответствующим идентификатором, которая сохраняется на сервере в единой базе данных (БД).

[0035] После регистрации в приложении на этапе (202), клиентская часть МП фиксирует вход в МП. После этого МП на МУ (110) отправляет запрос на сервер (120) для получения списка параметров и алгоритма формирования последовательности параметров, с помощью которых будет формироваться сессионный идентификатор (SID) для МП. Список параметров включает в себя следующие параметры МУ: параметры процессора, параметры камеры, параметры модуля памяти, параметры радиомодуля, системные параметры. Сервер (120) осуществляет запрос параметров и алгоритма формирования их последовательности в БД и передает их на МУ (110).

[0036] Сбор параметров осуществляется посредством программной логики платежного приложения, имеющего доступ к ОС мобильного устройства. В рамках осуществления настоящего этапа осуществляется сбор следующих параметров: параметры процессора, параметры модуля камеры, параметры модуля памяти, параметры радиомодуля, и по меньшей мере данные марки мобильного устройства.

[0037] Данные мобильного устройства собираются по основным аппаратным модулям (процессор, память, камера, радиомодуль), а также системные данные, идентифицирующие само устройство.

[0038] Параметры процессора могут выбираться из следующих данных, представленных в Таблице 1.

[0039] Пример используемых параметров модуля камеры приведены в Таблице 2.

[0040] Параметры модуля памяти могут включать в себя параметры, указанные в Таблице 3.

[0041] Пример используемых параметров радиомодуля приведен в Таблице 4.

Таблица 4. Параметры радиомодуля

[0042] Также дополнительно для формирования идентификатора используются системные параметры, приведенные в Таблице 5.

[0043] Далее на этапе (203) после того как сервер (120) передал параметры на МУ (110), на сервере (120) происходит формирование SID для МУ (110). Алгоритм формирования последовательности из 28 вышеуказанных параметров представляет собой рандомизатор последовательности полученных сервером (120) параметров, за счет чего количество возможных комбинаций для набора одного МУ (110) превышает 38 млн значений.

[0044] По факту сбора требуемого набора вышеуказанных параметров, на этапе (204) осуществляется их последующее хэширование с учетом выбранного алгоритма рандомизации, переданного сервером (120). В качестве алгоритма рандомизации может применяться алгоритм Randomized Quick Sort или иной. ОС Android позволяет получать данные параметры без дополнительных разрешений со стороны владельца мобильного устройства.

[0045] Данный список параметров позволяет добиться:

- уникальности получаемых идентификаторов, даже на одинаковых устройствах одного производителя;

- неизменности идентификатора на любом устройстве, даже при минорных и мажорных обновлениях ОС Android;

- воспроизводимости (повторяемость результатов) идентификатора при различных типах сбросов мобильного устройства до заводских и последующих восстановлений устройства.

[0046] В зависимости от типа решаемых задач идентификатор, получаемый на вышеописанных параметрах, может быть статическим и\или вероятностным, это достигается за счет использования различных алгоритмов преобразования данных. При формировании SID на МУ (110) применяется алгоритмов асимметричного шифрования (RSA) для повышения защищенности и повышения устойчивости соединения к различным векторам атак на банковскую инфраструктуру.

[0047] На этапе (204) по итогу применения функций хэширования формируется SID, который может иметь следующий вид:

Wj6tqLi34kZsbPZCi+gGTyrTaHmoAnljOlwMwAxSx0Wn:C3+zD3sl0XsjJOc:C3FzD3sl0Xsj JOcWj6tqLi34kZsbPZCi+gGTyrTaHmoAnljOlwlCY0Sx0Wn:ClfpwOcWj68LioBPZCiqyrGGJn1fVxv.

[0048] Зашифрованный SID передается на сервер (120) где впоследствии на этапе (205) дешифруется для целей проверки его совпадения с SID, который был сформирован на этапе (203), хранящегося в БД. На этапе (206) в случае если SID совпадают, то делается вывод о том, что МП на МУ (110) является доверенным (нативным). В противном случае делается вывод, что МП на МУ (110) является недоверенным (измененным).

[0049] Дополнительно для МУ (110) может формироваться статичный идентификатор способом, который был описан в патенте №2779521 (ПАО Сбербанк, 08.09.2022), который сохраняется в БД сервера (120) и может применяться для дополнительной аутентификации МУ (110).

[0050] На Фиг. 3 представлен способ (300) мониторинга транзакций с помощью формирования SID на стороне МУ (110) и сервера (120). При проверке на этапе (301) сформированных SID в рамках взаимодействия пользователя МП при осуществлении операций со стороны сервера (120) выполняется проверка срока действия SID, которая как правило составляет несколько минут. Если по итогу проверки на шаге (302) устанавливается, что транзакция совершается из недоверенного МП, то информация о таком МП передается во внешнюю систему мониторинга, которая выполняет последующий контроль в рамках взаимодействия пользователя МП (этап 303).

[0051] Такой системой может являться автоматизированная система фрод-мониторинга (АСФМ). Автоматизированная система фрод-мониторинга банка анализирует и выявляет аномалии в транзакционном потоке клиентов, помещая идентификаторы мобильных устройств злоумышленников в «черные» списки, тем самым предотвращая дальнейшие установки и регистрации платежных приложений на устройствах злоумышленников.

[0052] При выявлении аномалий (изменений) в идентификаторах клиента, сервер (120) на этапе (304) может генерировать сигнал о приостановке, либо отклонении транзакций, на том основании, что она является подозрительной и выполняется из модифицированного МП. Такой подход обеспечивает предотвращение возможного мошенничества (хищение денежных средств, либо имущества) в отношении клиента банка.

[0053] Также, сервер (120) может продолжать осуществлять сбор и накопление данных для формирования более точного понимания о характере конкретной активности и при наступлении высоко рискованного события осуществлять меры противодействия, указанные выше.

[0054] Уникальность подхода заключается в формировании сессионного идентификатора именно на клиентской части приложения по той логике, которую ему передает серверная часть, на данных, которые известны только клиентской и серверной части. Данный подход значительно повышает уровень доверия (при тождественности идентификаторов) клиент-серверному взаимодействию и при этом сохраняется высокий уровень быстродействия взаимодействия в целом. При достаточной защите исходного кода от злоумышленников, самостоятельно (несанкционированно) сгенерировать сессионный идентификатор в модифицированном мобильном приложении не представляется возможным.

[0055] Применимость подхода имеет разные прикладные стороны, это как уже описанный выше метод использования идентификатора в системах, осуществляющих мониторинг и блокировку подозрительных транзакций, так и системы, осуществляющие авторизацию клиентов и устройств.

[0056] На Фиг. 4 представлен общий вид вычислительного устройства (400), с помощью которого может быть реализовано заявленное решение. В общем случае, вычислительное устройство (400) содержит объединенные общей шиной информационного обмена один или несколько процессоров (401), средства памяти, такие как ОЗУ (402) и ПЗУ (403), интерфейсы ввода/вывода (404), устройства ввода/вывода (405), и устройство для сетевого взаимодействия (406).

[0057] Процессор (401) (или несколько процессоров, многоядерный процессор) могут выбираться из ассортимента устройств, широко применяемых в текущее время, например, компаний Intel™, AMD™, Apple™, Samsung Exynos™, MediaTEK™, Qualcomm Snapdragon™ и т.п. Под процессором также необходимо учитывать графический процессор, например, GPU NVIDIA или ATI, который также является пригодным для полного или частичного выполнения способа (200,300). При этом, средством памяти может выступать доступный объем памяти графической карты или графического процессора.

[0058] ОЗУ (402) представляет собой оперативную память и предназначено для хранения исполняемых процессором (401) машиночитаемых инструкций для выполнение необходимых операций по логической обработке данных. ОЗУ (402), как правило, содержит исполняемые инструкции операционной системы и соответствующих программных компонент (приложения, программные модули и т.п.).

[0059] ПЗУ (403) представляет собой одно или более устройств постоянного хранения данных, например, жесткий диск (HDD), твердотельный накопитель данных (SSD), флэш-память (EEPROM, NAND и т.п.), оптические носители информации (CD-R/RW, DVD-R/RW, Blue Ray Disc, MD) и др.

[0060] Для организации работы компонентов устройства (400) и организации работы внешних подключаемых устройств применяются различные виды интерфейсов В/В (404). Выбор соответствующих интерфейсов зависит от конкретного исполнения вычислительного устройства, которые могут представлять собой, не ограничиваясь: 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 и т.п.

[0061] Для обеспечения взаимодействия пользователя с вычислительным устройством (400) применяются различные средства (405) В/В информации, например, клавиатура, дисплей (монитор), сенсорный дисплей, тач-пад, джойстик, манипулятор мышь, световое перо, стилус, сенсорная панель, трекбол, динамики, микрофон, средства дополненной реальности, оптические сенсоры, планшет, световые индикаторы, проектор, камера, средства биометрической идентификации (сканер сетчатки глаза, сканер отпечатков пальцев, модуль распознавания голоса) и т.п.

[0062] Средство сетевого взаимодействия (406) обеспечивает передачу данных устройством (400) посредством внутренней или внешней вычислительной сети, например, Интранет, Интернет, ЛВС и т.п. В качестве одного или более средств (406) может использоваться, но не ограничиваться: Ethernet карта, GSM модем, GPRS модем, LTE модем, 5G модем, модуль спутниковой связи, NFC модуль, Bluetooth и/или BLE модуль, Wi-Fi модуль и др.

[0063] Дополнительно могут применяться также средства спутниковой навигации в составе устройства (300), например, GPS, ГЛОНАСС, BeiDou, Galileo.

[0064] Представленные материалы заявки раскрывают предпочтительные примеры реализации технического решения и не должны трактоваться как ограничивающие иные, частные примеры его воплощения, не выходящие за пределы испрашиваемой правовой охраны, которые являются очевидными для специалистов соответствующей области техники.

Изобретение относится к области защиты данных. Техническим результатом является повышение эффективности определения использования доверенных мобильных приложений. Способ определения использования доверенного мобильного приложения (МП) на мобильном устройстве (МУ) пользователя под управлением ОС Android включает этапы: получают данные о входе пользователя в МП; формируют запрос от МУ на сервер для получения списка параметров и алгоритма построения последовательности параметров для формирования сессионного идентификатора МП на МУ; формируют на сервере сессионный идентификатор для МУ на сновании переданных на МУ данных и выполняют его запись в базу данных (БД) для соответствующего МУ; формируют на МУ сессионный идентификатор для МП на основании полученных от сервера данных с помощью шифрования полученной последовательности параметров и принципа ее построения и отправляют его на сервер и осуществляют его дешифрование; выполняют сравнение полученного в ходе дешифрации сессионного идентификатора МП с сессионным идентификатором, хранящимся в БД; определяют степень доверенности МП на основании сравнения сессионных идентификаторов. 2 н. и 14 з.п. ф-лы, 4 ил., 5 табл.

1. Способ определения использования доверенного мобильного приложения (МП) на мобильном устройстве (МУ) пользователя под управлением ОС Android, содержащий этапы, на которых:

a) получают данные о входе пользователя в МП;

b) формируют запрос от МУ на сервер для получения списка параметров и алгоритма построения последовательности параметров для формирования сессионного идентификатора МП на МУ, при этом список параметров включает в себя следующие параметры МУ: параметры процессора, параметры камеры, параметры модуля памяти, параметры радиомодуля, системные параметры;

c) формируют на сервере сессионный идентификатор для МУ на основании данных, переданных на МУ на этапе b), и выполняют его запись в базу данных (БД) для соответствующего МУ;

d) формируют на МУ сессионный идентификатор для МП на основании данных, полученных на этапе b), с помощью шифрования полученной последовательности параметров и принципа ее построения;

e) отправляют сформированный на этапе d) сессионный идентификатор на сервер и осуществляют его дешифрование;

f) выполняют сравнение полученного в ходе дешифрации сессионного идентификатора МП с сессионным идентификатором, хранящимся в БД;

g) определяют степень доверенности МП на основании сравнения сессионных идентификаторов.

2. Способ по п. 1, в котором алгоритм построения последовательности параметров представляет собой алгоритм рандомизации.

3. Способ по п. 1, в котором на этапе d) применяется алгоритм асимметричного шифрования (RSA).

4. Способ по п. 1, в котором в случае если МП является недоверенным, то сервер осуществляет мониторинг операций, совершаемых в МП на МУ.

5. Способ по п. 4, в котором сервер осуществляет формирование уведомления для МУ, что МП является недоверенным.

6. Способ по п. 5, в котором уведомление содержит ссылку на скачивание доверенного МП.

7. Способ по п. 4, в котором в ходе мониторинга выполняется блокирование транзакционных операций.

8. Способ по п. 1, в котором дополнительно формируют статичный идентификатор МУ с помощью сбора параметров МУ, включающих в себя: параметры процессора, параметры модуля камеры, параметры модуля памяти, параметры радиомодуля и по меньшей мере данные марки мобильного устройства, и последующего хэширования полученного набора параметров.

9. Способ по п. 8, в котором статичный идентификатор записывается в БД сервера.

10. Система определения использования доверенного мобильного приложения (МП) на мобильном устройстве (МУ) пользователя под управлением ОС Android, в которой:

МУ выполнено с возможностью

получать данные о входе пользователя в МП;

формировать запрос от МУ на сервер для получения списка параметров и алгоритма построения последовательности параметров для формирования сессионного идентификатора МП на МУ, при этом список параметров включает в себя следующие параметры МУ: параметры процессора, параметры камеры, параметры модуля памяти, параметры радиомодуля, системные параметры;

формировать сессионный идентификатор для МП на основании данных, полученных в ответ на отправленный запрос от МУ, с помощью шифрования полученной последовательности параметров и принципа ее построения;

отправлять сформированный сессионный идентификатор МП на сервер;

сервер выполнен с возможностью

формирования на сервере сессионного идентификатора для МУ на основании данных, переданных на МУ в ответ на поступивший запрос, и выполняют его запись в базу данных (БД) для соответствующего МУ; дешифровки сформированного сессионного идентификатора МП, получаемого от МУ;

сравнения полученного в ходе дешифрации сессионного идентификатора МП с сессионным идентификатором, хранящимся в БД;

определения степени доверенности МП на основании сравнения сессионных идентификаторов.

11. Система по п. 10, в которой в случае если МП является недоверенным, то сервер осуществляет мониторинг операций, совершаемых в МП на МУ.

12. Система по п. 11, в которой сервер осуществляет формирование уведомления для МУ, что МП является недоверенным.

13. Система по п. 12, в которой уведомление содержит ссылку на скачивание доверенного МП.

14. Система по п. 11, в которой в ходе мониторинга выполняется блокирование транзакционных операций.

15. Система по п. 11, в которой дополнительно формируют статичный идентификатор МУ с помощью сбора параметров МУ, включающих в себя: параметры процессора, параметры модуля камеры, параметры модуля памяти, параметры радиомодуля и по меньшей мере данные марки мобильного устройства, и последующего хэширования полученного набора параметров.

16. Система по п. 15, в которой статичный идентификатор записывается в БД сервера.