СПОСОБ И СИСТЕМА ЕДИНОЙ ИДЕНТИФИКАЦИИ УСТРОЙСТВ В ИНФРАСТРУКТУРЕ ПРИЛОЖЕНИЙ Российский патент 2025 года по МПК G06F21/30 H04L41/806 

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

Данное техническое решение относится к области вычислительной техники, а именно к способам и системам идентификации устройств в инфраструктуре приложений.

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

Данное техническое решение относится к области вычислительной техники, а именно к способам и системам единой идентификации устройств в инфраструктуре приложений.

По данным аналитического издания KPMG, опубликованным в "Глобальном исследовании по вопросам мошенничества в банковской сфере" за период 2015-2018 гг. значительно увеличилось количество мошеннических схем в банковской сфере, включая кражу личных данных и учетных записей, кибератаки, CNP-атаки ("card not present fraud" https://en.wikipedia.org/wiki/Card_not_present_transaction). В исследовании также отмечен значительный рост авторизованных платежей мошенникам: мошенники манипулируют клиентами банков и обманным путем заставляют их переводить деньги в обход системы контроля банков. Несмотря на то, что многие клиенты самостоятельно переводят деньги на счет злоумышленников они считают, что именно банки должны заниматься предотвращением попыток мошеннических действий.

Банки всего мира вкладывают средства в развитие новых технологий, направленных на предотвращение мошенничеств: получение сигналов о мошеннических действиях в режиме реального времени, посредствам алгоритмов машинного обучения, использование биометрии, поведенческой биометрии и пр. Большинство решений, разработанных банками для противостояния киберугрозам реализованы за счет накопления и анализа данных об операциях клиентов. Основная сложность в разработке подобных решений заключается в том, что банки неохотно делятся персональными данными клиентов между собой из-за чего страдает эффективность разработанных решений.

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

Одним из таких решений является патент RU 2795371, опубликованный 03.05.2023, на "Способ и систему обезличенной оценки клиентов организаций для проведения операций между организациями" компании Group-IB, заявителя по данному решению. В патенте описана возможность коллаборации банков с целью накопления данных о мошенниках на стороннем сервере в обезличенном виде. Упомянутый способ позволяет обойти известный конфликт интересов в банковской сфере и избежать передачи персональных данных между банками, благодаря обезличиванию данных. Все персональные данные клиентов хранятся в обезличенном виде на стороне независимого сервера и при пересылке шифруются. Это обеспечивает безопасность и полную анонимность данных. Аналитика производится также в обезличенном виде. Таким образом, неограниченное количество банков может обогащать данные о мошенниках на сервере, не разглашая персональные данные своих клиентов. Взамен каждый банк получает доступ к расширенной базе данных, обогащенной другими банками. Данное решение является одним из немногих решений, предполагающих эффективное взаимодействие банков с целью противостояния киберугрозам.

Из уровня техники известна заявка на патент US 10785287 B2 "Secure binding of software application to a communication device" компании Visa International Service Association, опубликованная 22.09.2020, направленная на преодоление уязвимости программного обеспечения, а именно, на предотвращение похищения части программного обеспечения и его использовании на устройстве злоумышленника. Для этого предлагается идентифицировать оригинальное устройство пользователя и ассоциировать его с программным обеспечением и динамически подтверждать использование пары "устройство - пользователь" через сервер, при неподтверждении пары "устройство - пользователь" предлагается считать сессию мошеннической и прерывать ее.

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

Из уровня техники также известно использование временных меток, например временные метки часто используются для динамического обновления ключей аутентификации. Одним из таких решений является патент US 10153901 B2 "System and method for verifying user identity in a virtual environment" компании Concierge Holdings Inc, опубликованный 04.02.2016. В данном патенте описан технический способ по реализации сервиса аутентификации. Данный способ предполагает отправление временной метки при попытке прохождения аутентификации, а также выполнение проверки превышения лимита ожидания ответа на запрос. Время ожидания ответа на запрос отсчитывается от временной метки, переданной с запросом. В случае превышения времени ожидания сессия прерывается.

Другим решением из уровня техники является заявка на патент US 11259183 В2 "Determining a security state designation for a computing device based on source of software" от компании LookOut Inc, опубликованная 2022-02-22. В ней описан кооперационный способ определения вредоносности программного обеспечения. Способ содержит шаги, которые описывают обмен информацией между устройствами для определения статуса вредоносности программного обеспечения. Каждому приложению присваивается идентификатор и устройства передают друг другу значение, соответствующее вредоносности заданного приложения, где значение вредоносности, по крайней мере частично, основывается на источнике загрузки данного приложения. Это решение оценивает статус вредоносности приложений, а не идентифицирует клиента банка. Таким образом, описанное решение применимо к другому спектру задач и здесь приведено для описания уровня техники.

Как показал обзор уровня техники, на момент поиска отсутствуют публикации, где были бы описаны способы решения задачи единой идентификации устройств в инфраструктуре банковских приложений.

РАСКРЫТИЕ РЕШЕНИЯ

Решение относится к области компьютерной безопасности. Технической проблемой, на решение которой направлено заявленное техническое решение, является создание компьютерно-реализуемого способа и системы единой идентификации устройств в инфраструктуре приложений.

Технический результат заключается в реализации арсенала технических средств впервые.

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

• в ответ на получение от по меньшей мере одного устройства пользователя контейнера с пустым значением генерируют уникальный идентификатор;

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

• создают и отправляют на по меньшей мере одно устройство пользователя контейнер со значением N;

• в ответ на получение от по меньшей мере одного устройства пользователя контейнера со значением N создают и отправляют на по меньшей мере одно устройство пользователя контейнер со значением N+1.

Возможна такая реализация способа, где создание контейнера со значением N содержит следующие действия:

• находят сохраненный уникальный идентификатор устройства пользователя;

• выбирают по меньшей мере один параметр из набора параметров;

• создают контейнер со значением N на основе найденного уникального идентификатора и по меньшей мере одного параметра из набора параметров;

Возможен также вариант реализации способа, где созданный контейнер с любым значением зашифровывают;

Возможен также вариант реализации способа, где для шифрования контейнера с любым значением используют симметричное шифрование;

Возможен и такой вариант реализации способа, где для шифрования контейнера с любым значением используют симметричное шифрование с контролем целостности;

Возможен также вариант реализации способа, где для шифрования контейнера с любым значением используют асимметричные алгоритмы шифрования;

Возможен также вариант реализации способа, где для шифрования контейнера с любым значением используют асимметричные алгоритмы шифрования с контролем целостности;

Возможен также вариант реализации способа, где уникальный идентификатор ассоциируют с приложением, отправившим контейнер.

Возможен также вариант реализации способа, где ассоциирование уникального идентификатора с приложением, отправившим контейнер, выполняется с помощью идентификатора приложения;

Возможен также вариант реализации способа, где идентификатором приложения является package name.

Возможен также вариант реализации способа, где набор параметров содержит по меньшей мере одно из:

• параметр времени;

• параметр пользователя;

• параметры системного окружения устройства пользователя;

• параметр устройства пользователя, такой как уникальный идентификатор;

Возможен также вариант реализации способа, где создание контейнера со значением N+1 содержит следующие действия:

• контейнер со значением N+1 расшифровывают;

• извлекают уникальный идентификатор;

• заменяют по меньшей мере один параметр из набора параметров;

• создают контейнер со значением N+1;

Также описан способ идентификации устройства в инфраструктуре приложений, способ выполняемый по меньшей мере одним устройством пользователя, способ включающий шаги на которых:

• при первом запуске по меньшей мере одного приложения инфраструктуры выполняют поиск другого приложения инфраструктуры;

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

• получают соответствующий устройству сгенерированный контейнер с любым значением;

• полученный контейнер с любым значением сохраняют в служебные данные по меньшей мере одного приложения;

• при последующих запусках по меньшей мере одного приложения выполняются следующие действия:

i. контейнер с любым значением отправляют на сервер;

ii. в ответ от сервера получают контейнер с любым значением;

iii. полученный контейнер с любым значением сохраняют в служебных данных по меньшей мере одного приложения;

• в ответ на то, что другое приложение инфраструктуры установлено:

i. в служебных данных другого приложения инфраструктуры находят контейнер с любым значением;

ii. найденный контейнер с любым значением отправляют на сервер;

iii. в ответ от сервера получают контейнер с любым значением;

iv. полученный контейнер с любым значением сохраняют в служебных данных по меньшей мере одного приложения.

Возможен такой вариант реализации способа, в котором поиск другого приложения инфраструктуры выполняют по меньшей мере следующими действиями:

• получают список установленных на устройстве приложений;

• в служебных данных каждого из приложений, оставшихся в списке, выполняют поиск контейнера с любым значением.

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

Возможен такой вариант реализации способа, в котором поиск в служебных данных приложения инфраструктуры выполняется с помощью программы content provider.

Технический результат достигается за счет того, что система единой идентификации устройств в инфраструктуре приложений, состоящая по меньшей мере из одного сервера, выполненного с возможностью обмена информацией по беспроводной вычислительной сети с устройствами пользователя, содержащего по меньшей мере процессор и постоянное запоминающее устройство, хранящее машиночитаемые инструкции, исполнение которых процессором приводит к выполнению следующих шагов:

• в ответ на получение от по меньшей мере одного устройства пользователя контейнера с пустым значением генерируют уникальный идентификатор;

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

• создают и отправляют на по меньшей мере одно устройство пользователя контейнер со значением N;

• в ответ на получение от по меньшей мере одного устройства пользователя контейнера со значением N создают и отправляют на по меньшей мере одно устройство пользователя контейнер со значением N+1.

Технический результат также достигается за счет того, что система единой идентификации устройств в инфраструктуре приложений, состоящая из по меньшей мере из одного устройства пользователя, выполненного с возможностью обмена информацией по беспроводной вычислительной сети с сервером, устройства пользователя, содержащего по меньшей мере процессор и постоянное запоминающее устройство, хранящее машиночитаемые инструкции, исполнение которых процессором устройства пользователя приводит к выполнению следующих шагов:

• при первом запуске по меньшей мере одного приложения инфраструктуры выполняют поиск другого приложения инфраструктуры;

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

• получают соответствующий устройству сгенерированный контейнер с любым значением;

• полученный контейнер с любым значением сохраняют в служебные данные по меньшей мере одного приложения;

• при последующих запусках по меньшей мере одного приложения выполняются следующие действия:

i. контейнер с любым значением отправляют на сервер;

ii. в ответ от сервера получают контейнер с любым значением;

iii. полученный контейнер с любым значением сохраняют в служебных данных по меньшей мере одного приложения;

• в ответ на то, что другое приложение инфраструктуры установлено:

i. в служебных данных другого приложения инфраструктуры находят контейнер с любым значением;

ii. найденный контейнер с любым значением отправляют на сервер;

iii. в ответ от сервера получают контейнер с любым значением;

iv. полученный контейнер с любым значением сохраняют в служебных данных по меньшей мере одного приложения.

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

Реализация изобретения будет описана в дальнейшем в соответствии с прилагаемыми чертежами, которые представлены для пояснения сути изобретения и никоим образом не ограничивают область изобретения. К заявке прилагаются следующие чертежи:

Фиг. 1 иллюстрирует общую схему инфраструктуры приложений для идентификации клиентов;

Фиг. 2 иллюстрирует способ обнаружения и поддержания контейнера на устройстве пользователя;

Фиг. 3 схема пересылки контейнера внутри инфраструктуры;

Фиг 4 иллюстрирует способ, реализуемый на сервере;

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

ДЕТАЛЬНОЕ ОПИСАНИЕ

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

Кроме того, из приведенного изложения будет ясно, что изобретение не ограничивается приведенной реализацией. Многочисленные возможные модификации, изменения, вариации и замены, сохраняющие суть и форму настоящего изобретения, будут очевидными для квалифицированных в предметной области специалистов.

В рамках настоящего описания, если это не оговорено непосредственно по месту применения, нижеперечисленные специальные термины используются в следующих значениях:

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

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

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

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

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

уникальный идентификатор приложения - тот или иной идентификатор приложения, например, хорошо известный специалистам в предметной области package name;

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

параметры времени - параметры, передающие информацию о времени, например метка времени, то же timestamp. Данные о времени, используются для создания обновленного единого идентификатора;

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

параметр пользователя - например, логин;

обновленный контейнер - контейнер со значением N, N+1, высылается с сервера на устройства, содержит обновленные параметры;

пустое значение контейнера - контейнер не несущий информацию, содержит незначащие нули, которые передают на сервер при первом запуске приложения инфраструктуры. После этого на сервере генерируют уникальный идентификатор;

content provider - приложение, разработанное для операционной системы Android для передачи данных между приложениями;

SDK - (сокращение от англ. software development kit - «комплект для разработки программного обеспечения») https://ru.wikipedia.org/wiki/SDK

скрипт - набор команд, посредством исполнения которых реализуется некий шаг алгоритма

Одной из возможных реализаций описываемого способа является его реализация для инфраструктуры банковских приложений. На этом неограничивающем примере способ будет ниже описан в деталях. Важно отметить, что способ не специфичен именно для банковской сферы, она выбрана просто для определенности приводимого примера. Специалистам в предметной области должно быть очевидно, что аналогичным образом способ может быть реализован для инфраструктуры приложений из другой сферы, например, для инфраструктуры приложений для бэттинга, ритейла (торговли) и так далее.

Часто банки не разрабатывают приложения полностью, а используют комплекты для разработки - SDK решения. В SDK решениях, как правило, информация обрабатывается на едином бэкенд сервере. То есть любое решение, построенное на базе заданного SDK будет конструктивно устроено так, что ему необходимо отправлять информацию для обработки на бэкенд сервер. В общем случае вместо SDK может быть использовано любое другое программное обеспечение, выполненное с аналогичной функциональностью. Благодаря этой технической особенности была реализована значительная функциональная часть патентуемого решения. А именно, благодаря наличию бэкенд сервера решение позволяет идентифицировать клиентов разных приложений в одной инфраструктуре. В одной из реализаций инфраструктура содержит один бэкенд сервер. В другой реализации инфраструктура дополнительно содержит несколько подгрупп бэкенд серверов, где по меньшей мере одна из подгрупп объединена общим ключом шифрования.

Для идентификации клиентов используется уникальный идентификатор, запакованный в идентификационный контейнер или контейнер. Контейнер создается на стороне сервера и передается на устройство клиента в зашифрованном виде - это гарантирует анонимность всех клиентов инфраструктуры.

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

Настоящее решение реализовано для идентификации устройств, объединенных одной инфраструктурой приложений.

На Фиг. 1 изображена общая схема инфраструктуры приложений для идентификации устройств 100. Инфраструктура банковских приложений состоит из бэкенд сервера ПО, далее именуемого сервером, и из множества устройств пользователей, таких как устройства 120, 130, 140. В некоторых реализациях инфраструктура включает несколько серверов, подобных серверу ПО. На сервере ПО может храниться база данных 105, в которой могут храниться уникальные идентификаторы. В альтернативном способе реализации на сервере не хранится база данных. Сервер ПО имеет возможность коммуникативной связи с каждым устройством пользователя 120, 130, 140.

На каждом устройстве пользователя может быть установлено несколько приложений инфраструктуры, таких как приложения инфраструктуры 121, 122, установленные на устройстве 120. Также на каждом устройстве пользователя установлено приложение content provider 125.

Важно отметить, что на каждом устройстве пользователя могут быть установлены выпущенные разными, например, банками приложения инфраструктуры. Так, на устройстве 120 помимо приложений 121, 122, разработанных для взаимодействия с сервером ПО и выпущенных банком А, которому принадлежит сервер 110, может быть также установлено приложение 129, разработанное для взаимодействия с сервером 190, который принадлежит другому банку, банку Б. В данном случае важно, что все приложения 121, 122, 129 созданы на базе одного и того же SDK, благодаря чему и становится возможным взаимодействие, которое будет описано ниже.

Далее предлагаемые к патентованию способ и система будут описаны пошагово. Сначала для простоты понимания сути изобретения будет подробно описана часть способа, реализуемая на устройстве пользователя. Данный способ проиллюстрирован на Фиг. 2.

Как видно из Фиг. 2 способ имеет 3 сценария. Первый сценарий включает шаги 210-250. Этот сценарий реализуют, если запускаемое приложение инфраструктуры запускается впервые и другие приложения инфраструктуры не установлены на устройстве.

Способ 200 начинается с шага 210. На шаге 210 определяют впервые ли запущено приложение. Если приложение запущено впервые, то способ переходит к шагу 220. Если приложение ранее запускалось, то способ переходит к шагу 211.

Шаг 210 может быть реализован посредством запуска скрипта. В одной из реализаций скрипт является частью SDK, на котором разработано приложение. Скрипт может запускаться при каждом запуске приложения.

На шаге 220 проверяют установлено ли на данном устройстве пользователя другое приложение инфраструктуры. Для этого получают список установленных на устройстве приложений. Из полученного списка исключают системные приложения. Список системных приложений может быть составлен заранее и храниться в ресурсах банковского приложения. В дополнительной реализации приложением инфраструктуры может являться не только банковское приложение, но и приложение бэттинга, ритейла и другие приложения. Далее в служебных данных каждого из приложений, оставшихся в списке, выполняют поиск идентификационного контейнера. Для чтения и записи в служебных данных приложений может быть использована утилита content provider. Контейнер может представлять собой последовательность байт заранее заданной длины, например, 256 байт, и являться результатом шифрования, например, взятия хэш-функции от какой-либо строки. Если в служебных данных, хотя бы у одного из установленных приложений будет обнаружен контейнер, то это означает, что на устройстве установлено другое приложение инфраструктуры и способ переходит к шагу 221.

Следует заметить, что это другое приложение инфраструктуры необязательно рассчитано на работу с тем же сервером, что и впервые установленное приложение, выполнявшее поиск. Оно вполне может быть рассчитано на работу с другим сервером. Применительно к Фиг. 1, если впервые установлено приложение 121, то найденное приложение может быть как приложением 122, разработанное банком А и работающее с сервером 110, так и приложением 129, разработанное банком Б и работающее с сервером 190.

Если в служебных данных ни одного приложения не было найдено контейнера, то это первое приложение инфраструктуры и далее способ переходит к выполнению шага 230.

На шаге 230 с данного устройства пользователя на сервер отправляют контейнер с пустым значением. Таким образом гарантируется обезличивание данных клиентов. Уникальный идентификатор генерируют на сервере и он не содержит персональных данных пользователя.

Данный шаг выполняется посредством запуска скрипта. Ip-адрес сервера известен из ресурсов приложения. Далее способ 200 переходит к выполнению шага 240.

На шаге 240 от сервера получают контейнер. Полученный контейнер в одной из реализаций может быть зашифрован. В альтернативном варианте реализации полученный контейнер может быть не зашифрован. Далее способ 200 переходит к выполнению шага 250.

На шаге 250 полученный контейнер сохраняют в служебных данных приложения. Для сохранения единого идентификатора в служебных данных банковского приложения используют утилиту content provider.

Далее будет приведен второй сценарий работы способа 200, который выполняют при всех последующих запусках первого приложения. А именно, при каждом следующем запуске первого приложения выполняют отправку контейнера на сервер для обновления параметра времени. В альтернативном варианте реализации выполняется обновление других параметров, таких как, параметры устройства, пользователя, параметры системного окружения. Далее данный сценарий будет подробно описан применительно к каждому из его шагов: 211, 212, 213, 250.

Первый шаг сценария обновления единого идентификатора - это шаг 211. На шаге 211 в служебных данных первого банковского приложения 120 посредством утилиты content provider 125 находят контейнер. На этом шаг 211 завершается и сценарий переходит к следующему шагу 212.

На шаге 212 найденный контейнер отправляют на сервер для обновления параметров. Шаг выполняется посредством запуска скрипта. На этом шаг 212 завершается и сценарий переходит к следующему шагу 213.

На шаге 213 от сервера получают контейнер с обновленными параметрами. Шаг выполняется посредством запуска скрипта. На этом шаг 213 завершается и сценарий переходит к следующему шагу 240. Шаг 240 был описан выше. Шагом 250 завершается выполнение обновления параметров контейнера.

Далее будет рассмотрен третий сценарий работы способа 200, он запускается в том случае если приложение 120 запускается впервые, но на устройстве пользователя ранее было установлено и запускалось другое банковское приложение, например, такое, как приложение 122 или приложение 129. Этот сценарий включает в себя шаги 221, 222, 223, 250.

На шаге 221 в служебных данных второго приложения с помощью утилиты content provider 125 находят контейнер. Шаг выполняется посредством запуска скрипта. На этом шаг 221 завершается и сценарий переходит к следующему шагу 222.

На шаге 222 найденный контейнер отправляют на сервер ПО для обновления параметров. Шаг выполняется посредством запуска скрипта. На этом шаг 222 завершается и сценарий переходит к следующему шагу 223.

На шаге 223 от сервера получают контейнер с обновленными параметрами. Шаг выполняется посредством запуска скрипта. На этом шаг 223 завершается и сценарий переходит к следующему шагу 250. Шаг 250 был описан выше. Шагом 250 завершается выполнением обновления единого идентификатора.

На этом закончено описание способа 200.

Далее будет описан способ генерирования уникального идентификатора и обновления параметров контейнера на сервере. Но ранее, со ссылкой на Фиг. 3, для наглядности описания будет представлена схема пересылки контейнера внутри инфраструктуры Фиг. 3.

На Фиг. 3 инфраструктура приложений 300 утрировано упрощена и представлена устройством пользователя инфраструктуры 301 (аналогичным устройству 120 на Фиг. 1) и сервером 310, аналогичным серверам ПО и 190 на Фиг. 1. На сервере 310 имеются модуль шифрования 302, база данных 303, аналогичная базе данных 115, и процессор 304.

Идентификационный контейнер поступает от устройства 301. Как было описано выше, при первом запуске программы контейнер содержит пустое значение, при последующих запусках -непустое значение. Возможна реализация описываемого способа, при которой поступивший контейнер зашифрован. В этом случае посредством модуля шифрования 302 выполняют его расшифровку и передают для дальнейшей обработки процессору 304. Возможна также реализация описываемого способа, при которой контейнер не зашифрован. В этом случае расшифровку не выполняют и модуль шифрования 302 не задействуют.

Посредством процессора 304 отправляют запрос к базе данных 303, используя полученные из базы сведения и метку времени, генерируют уникальный идентификатор с некоторым значением N (для последующих итераций - с очередным значением N+1).

В одном из возможных вариантов реализации способа сгенерированный уникальный идентификатор отправляют на устройство 301. В другом возможном варианте реализации сгенерированный уникальный идентификатор предварительно зашифровывают, как будет описано ниже, посредством модуля шифрования 302.

В другом возможном варианте реализации уникальный идентификатор не сохраняют в базу данных. В этом случае уникальный идентификатор остается неизвестным для бэкенд сервера. Уникальный идентификатор хранится на устройстве клиента.

Далее будет описан способ генерирования уникального идентификатора и обновления параметров контейнера на сервере 400 со ссылкой на Фиг. 4. Способ 400 имеет два возможных сценария. Первый сценарий реализуют, если на сервере от устройства пользователя получают контейнер с пустым значением. В этом случае генерируют уникальный идентификатор. Первый сценарий включает шаги 410, 420 430, 440, 450. Второй сценарий реализуют, если получают непустое значение идентификационного контейнера. В этом случае выполняют шаги 411, 412.

Способ генерирования уникального идентификатора и обновления идентификационного контейнера на сервере 400 начинается с шага 410. На шаге 410 от устройства пользователя 301 получают контейнер. Помимо контейнера также на шаге 410 получают идентификатор устройства пользователя. Проверяют значение контейнера. В случае, если значение контейнера пустое, то далее способ реализует первый сценарий и способ переходит к шагу 420. В обратном случае, если значение единого идентификатора непустое, то далее способ реализует второй сценарий и способ переходит к шагу 411. Сначала будет описан первый сценарий, то есть, предполагаем, что было получено пустое значение единого идентификатора. Шаг 410 завершается и способ переходит к выполнению шага 420.

На шаге 420 посредством процессора 304 генерируют уникальный идентификатор. Контейнер по одному из способов реализации состоит из уникального идентификатора и метки времени.

Шаг 420 выполняется посредством запуска скрипта. На этом шаг 420 завершается и способ переходит к следующему шагу.

На шаге 430 сгенерированный уникальный идентификатор сохраняют в базе данных уникальных идентификаторов. Идентификатор в базе данных ассоциируют вместе с идентификатором устройства. Шаг 430 выполняется посредством запуска скрипта. На этом шаг 430 завершается и способ переходит к следующему шагу. В альтернативном способе уникальный идентификатор не сохраняют в базе данных, он хранится во временной памяти сервера. Шаг 430 может также являться опциональным, в этом случае идентификатор не сохраняют.

На шаге 440 создают контейнер со значением N. Контейнер со значением N включает набор параметров. Опционально на этом шаге выполняют шифрование контейнера. В качестве шифрования может быть использован любой известный способ шифрования. В одном из способов реализации может быть использовано симметричное шифрование. Также может быть использовано симметричное шифрование с контролем целостности. В альтернативном способе реализации может быть использовано ассиметричные алгоритмы шифрования. В другом способе реализации могут быть использованы ассиметричные алгоритмы шифрования с контролем целостности. На этом шаг 440 завершается. Данный шаг является опциональным. Способ переходит к шагу 450.

На шаге 450 контейнер, который, в зависимости от реализации способа, может быть как зашифрованным, так и не зашифрованным, передают на устройство пользователя. На этом шаг 450 и способ 400 завершаются.

Далее будет описан второй сценарий способа 400, то есть, предполагаем, что было получено непустое значение единого идентификатора. Шаг 410 завершился и способ переходит к выполнению шага 411

На шаге 411 полученном от устройства пользователя контейнер расшифровывают. Шифрование контейнеров выполняется на сервере. Ключи шифрования хранятся на сервере. Шифрование гарантирует безопасную передачу данных от сервера к приложениям инфраструктуры, а также безопасное хранение контейнеров на устройстве пользователя. На этом шаг 411 завершается и способ переходит к шагу 412.

На шаге 412 выполняют обновление контейнера посредством замены метки времени на актуальную. Для этого выполняется запрос к системными часам сервера. Обновленный контейнер состоит из прежнего уникального идентификатора, сгенерированного на шаге 420 и актуализированной метки времени. На этом шаг 412 завершается и способ переходит к шагу 430. Шаг 430 и последующие за ним шаги 440 и 450 были описаны ранее.

Как было упомянуто выше, описанный способ позволяет, в случае получения данных о компрометации в одном из банковских приложений, известить все банки, банковские приложения которых входят в инфраструктуру. Ниже со ссылкой на Фиг. 1 будет описан неограничивающий пример подобного оповещения.

В рассматриваемом примере на сервере первого банка, например, таком, как сервер ПО, получают из независимого, не относящегося к данному способу источника информацию о компрометации некоего конкретного устройства, например устройства 120. Такая информация может быть получена, например, из внутренней скоринговой базы клиентов этого банка, из посвященного скомпрометированным мобильным устройствам открытого веб-ресурса наподобие virustotal, из отдела антифрод-аналитики или из любого другого подобного источника. При этом в базе данных 115, хранящей идентификаторы устройств, работающих с сервером 110, для данного скомпрометированного устройства 120 сохранят метку или флаг "скомпрометировано".

Когда от приложения 121, запущенного на скомпрометированном устройстве, например, таком как устройство 120, на сервер 110 очередной раз поступит контейнер для обновления параметров, в число параметров, используемых для обновления, сервером будет включена метка или флаг "скомпрометировано", предварительно извлеченная из базы данных 115, где она будет найдена по запросу, содержащему идентификатор устройства 120. Таким образом, контейнер с обновленными параметрами, направленный на устройство 120 с сервера первого банка 110, будет содержать информацию о компрометации данного устройства.

Когда в следующий раз на устройстве 120 будет запущено приложение второго банка 129, оно, в соответствии с описанными выше шагами, найдет в данных первого приложения 121 этот контейнер и направит его на сервер второго банка 190 для обновления параметров. При этом информация о компрометации устройства 120, к тому моменту уже содержащаяся в контейнере, окажется передана на сервер 190. И на сервере 190, принадлежащем другому банку, после раскрытия контейнера для данного устройства 120 также сохранят в базе данных метку или флаг "скомпрометировано", и возможно, предпримут еще какие-либо общеизвестные действия, направленные на предупреждение мошенничества, например, запросят дополнительную идентификацию пользователя устройства 120.

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

На Фиг. 5 далее будет представлена общая схема вычислительного устройства 500, обеспечивающего обработку данных, необходимую для реализации заявленного решения.

В общем случае устройство 500 содержит такие компоненты, как: один или более процессоров 501, по меньшей мере одну память 502, средство хранения данных 503, интерфейсы ввода/вывода 504, средство В/В 505, средства сетевого взаимодействия 506.

Процессор 501 устройства выполняет основные вычислительные операции, необходимые для функционирования устройства 500 или функциональности одного или более его компонентов. Процессор 501 исполняет необходимые машиночитаемые команды, содержащиеся в оперативной памяти 502.

Память 502, как правило, выполнена в виде ОЗУ и содержит необходимую программную логику, обеспечивающую требуемый функционал.

Средство хранения данных 503 может выполняться в виде HDD, SSD дисков, рейд массива, сетевого хранилища, флэш-памяти, оптических накопителей информации (CD, DVD, MD, Blue-Ray дисков) и т.п. Средство 503 позволяет выполнять долгосрочное хранение различного вида информации, например, вышеупомянутых файлов, промежуточных данных, списков, баз данных и т.п.

Интерфейсы 504 представляют собой стандартные средства для подключения и работы, например, USB, RS232, RJ45, LPT, COM, HDMI, PS/2, Lightning, Fire Wire и т.п.

Выбор интерфейсов 504 зависит от конкретного исполнения устройства 500, которое может представлять собой персональный компьютер, мейнфрейм, сервер, серверный кластер, тонкий клиент, смартфон, ноутбук и т.п.

В качестве средств В/В данных 505 может использоваться клавиатура. Помимо клавиатуры, в составе средств В/В данных также может использоваться: джойстик, дисплей (сенсорный дисплей), проектор, тачпад, манипулятор мышь, трекбол, световое перо, динамики, микрофон и т.п.

Средства сетевого взаимодействия 506 выбираются из устройств, обеспечивающий сетевой прием и передачу данных, например, Ethernet карту, WLAN/Wi-Fi модуль, Bluetooth модуль, BLE модуль, NFC модуль, IrDa, RFID модуль, GSM модем и т.п. С помощью средств 506 обеспечивается организация обмена данными по проводному или беспроводному каналу передачи данных, например, WAN, PAN, ЛВС (LAN), Интранет, Интернет, WLAN, WMAN или GSM.

Компоненты устройства 500 сопряжены посредством общей шины передачи данных 510.

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

Изобретение относится к области вычислительной техники, а именно идентификации устройств в инфраструктуре приложений. Технический результат направлен на повышение безопасности при идентификации. Способ единой идентификации устройств в инфраструктуре приложений, выполняемый по меньшей мере одним сервером, и содержащий шаги, на которых в ответ на получение от по меньшей мере одного устройства пользователя контейнера с пустым значением генерируют уникальный идентификатор, сохраняют идентификатор устройства пользователя, приславшего контейнер с пустым значением, создают и отправляют на по меньшей мере одно устройство пользователя контейнер со значением N, и в ответ на получение от по меньшей мере одного устройства пользователя контейнера со значением N создают и отправляют на по меньшей мере одно устройство пользователя контейнер со значением N+1. 4 н. и 14 з.п. ф-лы, 5 ил.

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

• в ответ на получение от по меньшей мере одного устройства пользователя контейнера с пустым значением генерируют уникальный идентификатор;

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

• создают и отправляют на по меньшей мере одно устройство пользователя контейнер со значением N;

• в ответ на получение от по меньшей мере одного устройства пользователя контейнера со значением N создают и отправляют на по меньшей мере одно устройство пользователя контейнер со значением N+1.

2. Способ по п. 1, где создание контейнера со значением N содержит следующие действия:

• находят сохраненный уникальный идентификатор устройства пользователя;

• выбирают по меньшей мере один параметр из набора параметров;

• создают контейнер со значением N на основе найденного уникального идентификатора и по меньшей мере одного параметра из набора параметров.

3. Способ по п. 1, где созданный контейнер с любым значением зашифровывают.

4. Способ по п. 3, где для шифрования контейнера с любым значением используют симметричное шифрование.

5. Способ по п. 4, где для шифрования контейнера с любым значением используют симметричное шифрование с контролем целостности.

6. Способ по п. 3, где для шифрования контейнера с любым значением используют асимметричные алгоритмы шифрования.

7. Способ по п. 6, где для шифрования контейнера с любым значением используют асимметричные алгоритмы шифрования с контролем целостности.

8. Способ по п. 1, где уникальный идентификатор ассоциируют с приложением, отправившим контейнер.

9. Способ по п. 8, где ассоциирование уникального идентификатора с приложением, отправившим контейнер, выполняется с помощью идентификатора приложения.

10. Способ по п. 8, где идентификатором приложения является package name.

11. Способ по п. 2, где набор параметров содержит по меньшей мере одно из:

• параметр времени;

• параметр пользователя;

• параметры системного окружения устройства пользователя;

• параметр устройства пользователя, такой как уникальный идентификатор.

12. Способ по п. 2, где создание контейнера со значением N+1 содержит следующие действия:

• контейнер со значением N+1 расшифровывают;

• извлекают уникальный идентификатор;

• заменяют по меньшей мере один параметр из набора параметров;

• создают контейнер со значением N+1.

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

• при первом запуске по меньшей мере одного приложения инфраструктуры выполняют поиск другого приложения инфраструктуры;

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

• получают соответствующий устройству сгенерированный контейнер с любым значением;

• полученный контейнер с любым значением сохраняют в служебные данные по меньшей мере одного приложения;

• при последующих запусках по меньшей мере одного приложения выполняются следующие действия:

i. контейнер с любым значением отправляют на сервер;

ii. в ответ от сервера получают контейнер с любым значением;

iii. полученный контейнер с любым значением сохраняют в служебных данных по меньшей мере одного приложения;

• в ответ на то, что другое приложение инфраструктуры установлено:

i. в служебных данных другого приложения инфраструктуры находят контейнер с любым значением;

ii. найденный контейнер с любым значением отправляют на сервер;

iii. в ответ от сервера получают контейнер с любым значением;

iv. полученный контейнер с любым значением сохраняют в служебных данных по меньшей мере одного приложения.

14. Способ по п. 13, где поиск другого приложения инфраструктуры выполняют по меньшей мере следующими действиями:

• получают список установленных на устройстве приложений;

• в служебных данных каждого из приложений, оставшихся в списке, выполняют поиск контейнера с любым значением.

15. Способ по п. 14, где для поиска другого приложения инфраструктуры из списка установленных приложений исключают системные приложения.

16. Способ по п. 15, где поиск в служебных данных приложения инфраструктуры выполняется с помощью программы content provider.

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

• в ответ на получение от по меньшей мере одного устройства пользователя контейнера с пустым значением генерируют уникальный идентификатор;

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

• создают и отправляют на по меньшей мере одно устройство пользователя контейнер со значением N;

• в ответ на получение от по меньшей мере одного устройства пользователя контейнера со значением N создают и отправляют на по меньшей мере одно устройство пользователя контейнер со значением N+1.

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

• при первом запуске по меньшей мере одного приложения инфраструктуры выполняют поиск другого приложения инфраструктуры;

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

• получают соответствующий устройству сгенерированный контейнер с любым значением;

• полученный контейнер с любым значением сохраняют в служебные данные по меньшей мере одного приложения;

• при последующих запусках по меньшей мере одного приложения выполняются следующие действия:

i. контейнер с любым значением отправляют на сервер;

ii. в ответ от сервера получают контейнер с любым значением;

iii. полученный контейнер с любым значением сохраняют в служебных данных по меньшей мере одного приложения;

• в ответ на то, что другое приложение инфраструктуры установлено:

i. в служебных данных другого приложения инфраструктуры находят контейнер с любым значением;

ii. найденный контейнер с любым значением отправляют на сервер;

iii. в ответ от сервера получают контейнер с любым значением;

iv. полученный контейнер с любым значением сохраняют в служебных данных по меньшей мере одного приложения.