СИСТЕМА ОРГАНИЗАЦИИ ДЕЦЕНТРАЛИЗОВАННОЙ ДОВЕРИТЕЛЬНОЙ СВЯЗИ Российский патент 2025 года по МПК H04L9/06 

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

Решение относится к области компьютерной техники, а именно к децентрализованным компьютерным сетям.

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

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

• Сложность организации защищенной оперативной связи между сетями разграниченного доступа различного уровня и использующих различные технологии организации связи.

• Вывод из строя центрального узла связи в данных системах приводит к невозможности взаимодействия между остальными узлами.

• При построении структур централизованной доверенной связи свойства функциональности ущемляются в пользу осуществления максимального контроля за передаваемой информацией.

Известно изобретение РФ №2446606 «Способ доступа с аутентификацией и система доступа с аутентификацией в беспроводной многоскачковой сети» (дата приоритета 26.12.2008, МПК H04L 29/06), в данном патенте описан способ доступа с аутентификацией и система доступа с аутентификацией для беспроводных самоорганизующихся сетей, где в качестве примера приводятся технологии IEEE802.15.4/ZigBee. Данный способ позволяет провести аутентификацию устройств в децентрализованных ячеистых сетях, но не гетерогенный и многоуровневый характер сети.

Известно изобретение РФ №2704268 «Способ, система и устройство криптографической защиты каналов связи беспилотных авиационных комплексов» (дата приоритета 18.05.2018, МПК H04W 12/06), описывает систему аутентификации для беспилотных авиационных комплексов без применения центров сертификации и аутентификации, что не позволяется встроить ее в гетерогенную систему связи.

СУЩНОСТЬ

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

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

Система организации децентрализованной доверительной связи (СОДДС), включает:

по крайней мере два домена, где домены подчинены иерархически, причем

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

по крайней мере один сетевой узел (СЕУ), который выступает в роли головного узла (ГУ) и может дополнительно выступать в роли управляющего центра (УЦ) и/или граничного шлюза (ГШ);

а подчиненный домен включает по крайней мере один СЕУ, где

СЕУ выступает в роли ГУ, а также может выступать в роли ГШ и/или узла включения (УВ) и/или УЦ,

причем ГУ:

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

• выполняет роль сервера доменных имен (СДИ);

• содержит таблицу адресации, содержащую уникальные идентификаторы СЕУ;

• содержит таблицу соответствия сокращенного адреса домена и уникального идентификатора контроллера нижестоящего уровня, который был добавлен данным ГУ;

причем подчиненный домен:

• включает в себя как минимум два типа СЕУ - оконечный узел (ОУ) и ГУ;

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

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

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

причем СЕУ:

• может принадлежать к двум и более доменам, кроме СЕУ с ролью ГУ в корневом домене;

• имеет сертификат, который подписан корневым сертификатом и контроллером домена, в котором расположен СЕУ, в случае если СЕУ является узлом в двух или более доменах, то сертификат подписан каждым из контроллеров домена;

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

• имеет уникальный идентификатор узла (ИДУ);

• имеет уникальный доменный адрес узла (ДАУ), включающий в себя идентификатор устройства и все нижестоящие идентификаторы доменов;

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

• содержит список скомпрометированных СЕУ для каждого домена, где он расположен;

• выполнен с возможностью определения является ли устанавливающий соединение иной СЕУ доверенным без участия УЦ, с помощью системы иерархической проверки сертификатов и списков доверия, в случае нарушения связности сети;

причем в системе:

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

• новый домен добавляется в систему путем создания нового сертификата домена для СЕУ, который временно принимает роль ГУ и выбирается на основании заданных критериев, а его сертификат подписывается сертификатом вышестоящего домена в ручном или автоматизированном режиме, затем данный СЕУ запрашивает новый Доменный адрес узла (ДАУ) у вышестоящего домена, который генерирует адрес и вносит в собственную таблицу адресации;

• при добавлении нового СЕУ, в случае если сертификат и идентификатор данного узла не находится в списке скомпрометированных узлов контроллера домена, СЕУ отправляет собственный сертификат на канальном уровне уже функционирующему в сети ОУ, которое в свою очередь отправляет запрос о добавлении нового узла на подпись контроллеру домена и в случае доступности, контроллер домена удостоверяется в валидности данных сертификата нового СЕУ и подписывает его через сторонний доверенный канал, а в случае недоступности контроллера домена добавление нового узла прерывается и для избежания сетевой атаки выставляется задержка для повторного подключения;

• при блокировке СЕУ ГУ рассылает всем доверенным СЕУ домена обновленный список компрометированных узлов;

• обмен данными между СЕУ происходит по защищенному каналу с использованием протоколов TLS/DTLS;

• в основании Сервера доменных имен и системы адресации для поиска адреса СЕУ лежат сетевые запросы, использующие формат Доменной системы имен (DNS) и Динамической доменной системы имен (DDNS);

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

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

Система организации децентрализованной доверительной связи (СОДДС), включает:

по крайней мере два домена, где домены подчинены иерархически, причем

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

по крайней мере один сетевой узел (СЕУ), который выступает в роли головного узла (ГУ) и может дополнительно выступать в роли управляющего центра (УЦ) и/или граничного шлюза (ГШ);

а подчиненный домен включает по крайней мере один СЕУ, где

СЕУ выступает в роли ГУ, а также может выступать в роли ГШ и/или узла включения (УВ) и/или УЦ,

причем ГУ:

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

• выполняет роль сервера доменных имен (СДИ);

• содержит таблицу адресации, содержащую уникальные идентификаторы СЕУ;

• содержит таблицу соответствия сокращенного адреса домена и уникального идентификатора контроллера нижестоящего уровня, который был добавлен данным ГУ;

причем домен:

• включает в себя как минимум два типа СЕУ - оконечный узел (ОУ) и ГУ;

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

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

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

причем СЕУ:

• может принадлежать к двум и более доменам, кроме СЕУ с ролью ГУ в корневом домене;

• имеет сертификат, который подписан корневым сертификатом и контроллером домена, в котором расположен СЕУ, в случае если СЕУ является узлом в двух или более доменах, то сертификат подписан каждым из контроллеров домена;

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

• имеет уникальный идентификатор узла (ИДУ);

• имеет уникальный доменный адрес узла (ДАУ), включающий в себя идентификатор устройства и все нижестоящие идентификаторы доменов;

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

• содержит список скомпрометированных СЕУ для каждого домена, где он расположен;

• выполнен с возможностью определения является ли устанавливающий соединение иной СЕУ доверенным без участия УЦ, с помощью системы иерархической проверки сертификатов и списков доверия, в случае нарушения связности сети;

причем в системе:

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

• новый домен добавляется в систему путем создания нового сертификата домена для СЕУ, который временно принимает роль ГУ и выбирается на основании заданных критериев, а его сертификат подписывается сертификатом вышестоящего домена в ручном или автоматизированном режиме, затем данный СЕУ запрашивает новый Доменный адрес узла (ДАУ) у вышестоящего домена, который генерирует адрес и вносит в собственную таблицу адресации;

• при добавлении нового СЕУ, в случае если сертификат и идентификатор данного узла не находится в списке скомпрометированных узлов контроллера домена, СЕУ отправляет собственный сертификат на канальном уровне уже функционирующему в сети ОУ, которое в свою очередь отправляет запрос о добавлении нового узла на подпись контроллеру домена и в случае доступности, контроллер домена удостоверяется в валидности данных сертификата нового СЕУ и подписывает его через сторонний доверенный канал, а в случае недоступности контроллера домена добавление нового узла прерывается и для избежания сетевой атаки выставляется задержка для повторного подключения;

• при блокировке СЕУ ГУ рассылает всем доверенным СЕУ домена обновленный список компрометированных узлов;

• обмен данными между СЕУ происходит по защищенному каналу с использованием протоколов TLS/DTLS;

• в основании Сервера доменных имен и системы адресации для поиска адреса СЕУ лежат сетевые запросы, использующие формат Доменной системы имен (DNS) и Динамической доменной системы имен (DDNS);

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

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

В некоторых вариантах реализации ИДУ представляет собой строку, идентифицирующую узел в рамках системы и основанную на стандарте RFC 4122, имеющую формат «хххххххх-хххх-хххх-хххх-хххххххххххх» и состоящую из чисел в шестнадцатеричной системе счисления.

В некоторых вариантах реализации список скомпрометированных СЕУ содержит идентификаторы и сертификаты заблокированных СЕУ

В некоторых вариантах реализации список скомпрометированных СЕУ формируется в случае компрометации СЕУ и поступает от контроллера домена.

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

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

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

В некоторых вариантах реализации домен включает в себя как минимум два типа СЕУ - ОУ и ГУ, причем ГУ дополнительно включает роль маршрутизатора, в зависимости от используемых протоколов маршрутизации на сетевом уровне.

В некоторых вариантах реализации ГШ:

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

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

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

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

В некоторых вариантах реализации СЕУ, который временно принимает роль ГУ, выбирается на основании по крайней мере одного из следующих критериев:

• текущего уровня заряда устройства;

• значения сетевых задержек;

• джиттера;

• количества скачков при маршрутизации до любого из узлов в сети.

Система организации децентрализованной доверительной связи (СОДДС), включает:

по крайней мере два домена, где домены подчинены иерархически, причем

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

по крайней мере один сетевой узел (СЕУ), который выступает в роли ГУ и может также выступать в роли УЦ и/или ГШ

а подчиненные домены включают по крайней мере один СЕУ, где

СЕУ выступает в роли ГУ, а также может выступать в роли ГШ и/или УВ и/или УЦ

причем ГУ:

• включает роль контроллера домена, который обеспечивает процедуру аутентификации в сети с использованием списков доверия и выполняет подпись сертификатов всех узлов в рамках домена (под подписью сертификатов имеется ввиду известная процедура, например описанная в ITU-T Х.509), где расположен ГУ и который в свою очередь связан с вышестоящими контроллерами домена до корневого контроллера доменов, имеющего самоподписанный сертификат, а также выполняет конвертацию уникальных адресов устройства в формат адреса, используемый доменом на сетевом уровне (сеть гетерогенная и на сетевом/канальном уровне может лежать любая технология организации сети: проводная, например, IEEE 802.3ab, IEEE 802.3ah, RS-232 и др. и беспроводные, например, IEEE 802.11, IEEE 802.15.1, IEEE 802.15.4 и др.);

• содержит таблицу адресации, содержащую уникальные идентификаторы СЕУ;

• содержит таблицу соответствия сокращенного адреса домена и уникального идентификатора контроллера нижестоящего уровня, который был добавлен данным ГУ

причем домен:

• обязательно включает в себя как минимум два типа СЕУ-ОУ и ГУ, причем ГУ дополнительно включает роль контроллера домена, сервера доменных имен (СДИ) и опционально роль маршрутизатора, в зависимости от используемых протоколов маршрутизации на сетевом уровне (в качестве иллюстративного примера для сетей IEEE 802.15.4 с динамическим определением ролей устройств, например ZigBee, маршрутизатор сети выбирается автоматически, на уровне сети, СОДДС может функционировать как на нем, так и на любом другом узле сети; для сетей IEEE 802.15.4 со статически заданным ролями устройств, например LoRaWAN, концентратор сети предустановлен и СОДДС функционирует на нем; для сетей IEEE 802.3 контроллером домена выбирается маршрутизатор сети, а также протоколов коммутации на канальном уровне модели OSI и т.п.)

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

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

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

причем СЕУ:

• может принадлежать к двум и более доменам, кроме СЕУ с ролью ГУ в корневом домене;

• имеет сертификат, который содержит: уникальный идентификатор СЕУ, идентификатор родительского домена, произвольное поле для передачи открытых данных узла, сертификат подписан контроллером домена, в котором расположен СЕУ, в случае если СЕУ является узлом в двух или более доменах, то сертификат подписан каждым из контроллеров домена;

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

• имеет уникальный идентификатор узла (ИДУ) - строка, идентифицирующая узел в рамках системы и основанная на стандарте RFC 4122 (далее UUID), имеющая формат «хххххххх-хххх-хххх-хххх-хххххххххххх» и состоящая из чисел в шестнадцатиричной системе счисления, например «5f737a69-b99a-77e3-f871-56117613ab5f»;

• имеет уникальный доменный адрес узла (ДАУ), включающий в себя идентификатор устройства и все нижестоящие идентификаторы доменов, разделенные между друг другом точкой.

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

• содержит список скомпрометированных СЕУ для каждого домена, где он расположен, список содержит идентификаторы и сертификаты заблокированных СЕУ, который формируется в случае компрометации СЕУ и поступает от контроллера домена

• СЕУ выполнен с возможностью определения является ли устанавливающий соединение иной СЕУ доверенным без участия УЦ, с помощью системы иерархической проверки сертификатов и списков доверия, в случае нарушения связности сети

причем в системе:

• для определения уровня доверия между узлами используется цепочка последовательно подписанных котроллером домена сертификатов

• новый домен добавляется в систему путем создания нового сертификата домена для СЕУ, который временно принимает роль ГУ и выбирается на основании заданных критериев, а его сертификат подписывается сертификатом вышестоящего домена в ручном или автоматизированном режиме, затем данный СЕУ запрашивает новый Доменный адрес узла (ДАУ) у вышестоящего домена, который генерирует адрес и вносит в собственную таблицу адресации

• при добавлении нового СЕУ, в случае если сертификат и идентификатор данного узла не находится в списке скомпрометированных узлов контроллера домена, СЕУ отправляет собственный сертификат на канальном уровне уже функционирующему в сети ОУ, которое в свою очередь отправляет запрос о добавлении нового узла на подпись контроллеру домена и в случае доступности, контроллер домена удостоверяется в валидности данных сертификата нового СЕУ и подписывает его через сторонний доверенный канал - сетевой пользовательский интерфейс для взаимодействия со сторонними устройствами и приложениями, а в случае недоступности контроллера домена - добавление нового узла прерывается и для избежания сетевой атаки выставляется задержка для повторного подключения

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

• обмен данными между СЕУ происходит по защищенному каналу с использованием протоколов TLS/DTLS.

• в основании Сервера доменных имен и системы адресации для поиска адреса СЕУ лежат сетевые запросы, использующие формат Доменной системы имен (DNS) и Динамической доменной системы имен (DDNS)

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

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

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

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

Фиг. 1 - общая структура децентрализованной доверительной системы связи.

Фиг. 2 - общая структура децентрализованной доверительной системы связи, разделенной на вложенные домены.

Фиг. 3 - пример системы адресации между сегментами системы на основе DNS.

Фиг. 4а и 4б - включение нового узла в доверительную сеть.

Фиг. 5 - процедура аутентификации узла при запросе передачи данных в рамках локального домена.

Фиг. 6 - рассматривается удаление скомпрометированного узла (далее СКУ).

Фиг. 7 - представлена сеть, состоящая из ряда доменов, связанных между собой через домен верхнего уровня А.

ПОДРОБНОЕ ОПИСАНИЕ

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

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

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

Граничный шлюз (ГШ) - устройство, обеспечивающие межсетевое взаимодействие с внешними подсетями доверительной системы связи и обеспечивающее общее адресное пространство между ними поверх сетей и устройств, степень доверительности которых невозможно достоверно оценить (например, оптоволоконные сети магистральных провайдеров, мобильные сети, спутниковые сети, локальные муниципальные сети связи общего пользования и т.д.). Данный тип устройств чаще всего является уникальным и другие устройства в домене не могут взять роль ГШ на себя, т.к. работа узла зависит от аппаратного обеспечения, в частности модулей связи (например, он может выступать шлюзом между mesh-сетями 6L0WPAN и сетью 4G/PON/Ethernet).

Управляющий центр (УЦ) - устройство, представляющее собой ОУ/ГУ, который включает в себя базу данных содержащую информацию о доменах, пользователях и узлах в системе. УЦ является уникальным устройством в системе и не может быть заменен ОУ/ГУ/ГШ, т.к. он имеет как более высокие вычислительные возможности, так и больший объем устройств постоянного хранения данных. Данный узел используется как для автоматизированного принятия решений, так и помощи принятия решений в вопросах безопасности, связанных с добавлением нового устройства или исключением из сети скомпрометированного. Данный узел не обязателен для решения вопросов аутентификации при работе централизованного сегмента сети - домены могут самостоятельно принимать решения при нарушении связи с УЦ.

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

Сторонний узел (СУ) - программное или программно-аппаратное обеспечение, представляющее собой стороннее сетевое устройство, подключаемое к УВ, при необходимости передачи данных поверх доверительной сети. За вопросы доверенности и/или скомпрометированности данных узлов отвечает УВ. В случае если система доверительности в лице ГУ или УЦ обнаруживает атаку со стороны СУ, то УВ и все подключенные к нему узлы считаются скомпрометированными.

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

Идентификатор узла (ИДУ) - строка, представляющая собой идентификатор в виде UUID версии 5, согласно RFC 4122. Идентификатор узла указывается в сертификате узла.

Сертификат узла (СФУ) - сертификат в формате ITU-T Х.509, подписанный контроллером домена сети или контроллером вышестоящего домена. Сертификат содержит в себе также информацию о полномочиях узла.

Полномочия узла (ПРУ) - список правил и разрешений, которые определяют роль и функции узла. Например, согласно ПРУ, узел может выполнять роль контроллера домена или выполнять роль ГУ или ГШ.

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

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

Контроллер домена (КТД) - роль узла, при которой он имеет полномочия осуществлять добавление в домен, а также хранящий реплику данных, описывающих доменные правила и полномочия узлов. В случае компрометации или потери соединения КТД с остальными узлами в домене, из узлов, находящихся в списке доверия будет выбран новый КТД.

Доменный адрес узла (ДАУ) - строка, содержащая полный последовательный перечень идентификаторов верхнеуровневых доменов в текстовом UUID формате с разделителем в виде точки.

Сервер доменных имен (СДИ) - роль узла, при которой узел может выполнять сопоставление доменных имен. В случае компрометации или потери соединения СДИ с остальными узлами в домене, из узлов, находящихся в списке доверия будет выбран новый СДИ.

Сокращенный адрес домена (САД) - идентификатор домена, который привязывается ко вновь создаваемому домену на родительском СДИ, для сокращения размера строки домена в ДАУ за счет конвертации на СДИ идентификатора узла домена в короткий адрес, содержащий четыре числа в шестнадцатиразрядной системе счисления формата «хххх». Данный адрес также позволяет при смене контроллера домена сохранить ДАУ, путем простой замены ИДУ предыдущего контроллера домена текущим идентификатором КТД.

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

Изолированный сегмент (ИЗС) - совокупность узлов зоны, у которой в текущий момент времени отсутствует смежность с остальными узлами этой зоны.

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

Представленная система организации доверительной связи имеет следующие свойства:

• Децентрализованный характер сети, с ячеистой сетевой топологией.

• Сеть состоит из ряда защищенных подсетей и имеет гетерогенный характер, позволяющий взаимодействовать различным видам сетей связи между собой. Например, такие сети как сети связи дальнего радиуса действия, сети спутниковой связи, сети локальной проводной связи, сети мобильной связи, сети магистральной связи, сети беспроводной связи (ZigBee, Bluetooth, Wi-Fi и др.) и т.д. Подсети в данной системе могут динамически менять сетевую конфигурацию, в случае если маршрут или устройство были потеряны.

• Данная сеть организована на принципах самоорганизующихся сетей (далее СОС), в частности предполагается что на уровне боевых подразделений будут использоваться технологии ячеистых частично одноранговых беспроводных СОС (в качестве примера можно привести такие технологии как ZigBee, 6LoWPAN, WirelessHART, Bluetooth LE 4.2/5.0 и т.д.).

• Узлы в данной сети могут динамически менять свою роль, если имеется техническая возможность для этого, в соответствии с концепцией частично одноранговых СОС.

Система организации децентрализованной доверительной связи имеет следующие свойства:

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

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

В рамках данной системы существует четыре основных типа сетевых устройств: оконечный узел (далее ОУ), головной узел (далее ГУ), узел включения (далее УВ), а также опционально для обеспечения взаимодействия с другими типами сетей - граничный шлюз (далее ГШ). Также в качестве подвида ГУ можно выделить управляющий центр (далее УЦ). Предполагается, что узлы в данной системе могут менять свои роли динамически, в зависимости от их доступности и текущего состояния по доверенности/компрометации. Предполагается, что всегда любой ОУ может выступить как ГУ, а также при наличии технической возможности как ГШ/УЦ/УВ. Для функционирования сети в локальном режиме, в случае нарушения связности общей сети достаточно только двух взаимозаменяемых типов устройств - ОУ и ГУ.

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

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

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

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

В рамках данной системы каждый из поддоменов выделяется из домена более высокого уровня и в случае обрушения соединения - может работать локально в рамках собственного домена и поддоменов, используя собственную защищенную сессию и сертификаты сессии. В случае если поддомен не имеет возможности сетевого обмена сигнальными сообщениями с вышестоящим доменом, например не имеет шлюза или не имеет возможности установить устойчивое соединение с ГУ или ГШ вышестоящего домена - он может взаимодействовать через соседний поддомен, если один из узлов, функционирующий в его сети, также зарегистрирован в смежном поддомене (как например ОУ в доменах Г и Д или ГУ домена Д, который также зарегистрирован в домене Е, как ОУ на фиг. 2). Такие узлы, являясь доверенными узлами для двух и более доменов имеют возможность взаимодействовать со всеми узлам в данных доменах и являются в некотором роде шлюзами для взаимодействия узлов данных доменов между друг другом.

Для обеспечения взаимодействия между узлами используется иерархическая доменно-атрибутная модель доверия.

В корне дерева находится корневой домен (домен А на рис. 2), сертификаты контроллеров которого подписаны самоподписанным корневым сертификатом. Узлами дерева являются домены. Членами домена являются сетевые узлы, каждый из которых может выполнять одну или несколько ролей.

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

В некоторых вариантах реализации новый домен добавляется в систему путем создания нового сертификата домена для любого узла в сети, который временно считается ГУ и подписывается сертификатом вышестоящего домена в ручном или автоматизированном режиме. Затем данный узел запрашивает новый URL-адрес у вышестоящего домена, который генерирует адрес и вносит в собственную таблицу адресации. В дальнейшем роль ГУ может быть назначена для любого другого узла в домене на основе анализа следующих параметров для каждого из узлов: текущий уровень заряда устройства, значение сетевых задержек, джиттера (фазового дрожания цифрового сигнала данных) и количество скачков при маршрутизации до любого из узлов в сети. Затем ГУ путем запроса у остальных узлов в рамках сети, по вышеприведенным параметрам выбирает устройство, которое наиболее подходит для роли ГУ и затем отправляет широковещательное оповещение об этом всем устройствам в сети.

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

Для определения уровня доверия между узлами используется цепочка последовательно подписанных КТД сертификатов.

В некоторых вариантах реализации любой обмен данными между любыми узлами в рамках сети должен происходить по защищенному каналу TLS/DTLS.

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

Система может иметь удаленные сегменты соединенные друг с другом с помощью транспортных сетей, не являющимися частью доверительной сети. Для включения сегментов доверительной сети в данные сети используется специальный тип устройств - Граничные шлюзы. Для обеспечения единого адресного пространства в рамках системы используется технологии Доменной системы имен (далее DNS) и Динамической доменной системы имен (далее DDNS) в рамках Системы доменных имен.

На фиг. 3 изображен пример доверительной сети на основе доменов, с применением методов используемых для протоколов DNS и DDNS. В данном примере узел 1 из домена Г, с УИД «5f737a69-b99a-77e3-f871-56117613ab5f» пытается обратиться к узлу 2, с УИД «16ab4eb7a-ff5c-38c1-f913-7a5f7669acel». Узлу 1 тем или иным способом заранее известен ДАУ узла 2: «16ab4eb7a-ff5c-38c1-f913-7a5f7669ace1.ab96.6a7f.int.spb.ru». Данный адрес состоит из УИД узла 2 в домене («16ab4eb7a-fF5c-38cl-f913-7a5f7669acel») и адресов вышестоящих доменов - домена Ж «ab96», домена В «6a7f» и верхнего домена А «int.spb.ru» Узел 1 делает DNS-запрос на локальный СДИ домена Г «а571». Если в кэше СДИ домена нет записи о адресе узла 2, то СДИ пересылает запрос на сервер, вышестоящего домена «f7c1», а затем и до СДИ домена А «int.spb.ru». Сервер домена А не знает адрес узла 2, но он знает путь до сервера домена В «6a7f», тот в свою очередь знает адрес домена Ж - «ab96». Сам СДИ домена Ж имеет список всех узлов в домене с прописанными УИД и может напрямую вернуть адрес узла 2. В случае необходимости отделения адресного пространства от адресации и СДИ в глобальных сетях связи общего пользования, между ГШ возможна организация виртуальной частной сети (далее ВЧС), которая позволяет организовать общее закрытое адресное пространство для всех сегментов доверительной сети.

Для решения проблем, возникающих из-за динамического характера сети, например когда ГУ/СДИ (например, «ab96») одного из доменов отключается от сети и другой узел берет его роль на себя и вследствие этого ДАУ домена («ab96.6a7f.int.spb.ru») ведет на несуществующий в сети адрес - используется протокол DDNS. При смене ГУ новый ГУ зная адрес локального СДИ домена и вышестоящего домена, может при помощи запроса DDNS сообщить новый адрес узла, выдав свой адрес и обновив сертификаты для нижестоящего СДИ на вышестоящем. Таким образом решается вопрос обеспечения возможности динамической смены адресов узлов, при сохранении ДАУ-адресации доменов в доверительной сети.

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

Включение нового узла в доверительную сеть отображено на фиг. 4а и 4б и содержит следующие этапы:

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

2. Узлы, на которые поступил запрос, проводят проверяют корректность формата сертификата, его кодировки и корректность формата УИД, ДАУ узла и УИД контроллера домена и в случае ее прохождения - формируют запрос на регистрацию нового узла на ГУ домена, включая в сетевое сообщение сертификат с информацией об узле.

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

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

5. В случае положительного заключения о сертификате узла - ГУ формирует ответ о подтверждении добавления нового узла и затем отправляет его на узлы-источники запроса (из шага 1), к которым изначально подключался новый узел поверх канального уровня.

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

7. После процедуры подключения новый узел устанавливает защищенное ассиметричным шифрованием соединение с ГУ и передает поверх данного соединения (через данное соединение) симметричный ключ шифрования, с помощью которого ГУ расшифровывает закрытую часть информации об узле из ранее полученного сертификата. ГУ проверяет ЦС (цепочку сертификатов) нового узла и производит окончательное решении о доверенности данному узлу. В зависимости алгоритма работы вышестоящего приложения, использующего данную систему для организации доверительной связи, в ходе проверки доверенности ГУ может делать запросы на УЦ, если есть такая возможность. Если такой возможности нет, то ГУ принимает решение в соответствии с имеющейся информации и заключения корректности сертификата узла по правилам задаваемым приложением, использующим данную систему.

Аутентификация узла при запросе передачи данных в рамках локального домена.

На фиг. 5 рассматривается процедура аутентификации узлов при запросе передачи пользовательских данных на время сессии.

1. Узел-отправитель (далее УО) устанавливает соединение с узлом-получателем (далее УП) в рамках локального домена и передает ему запрос на отправку данных.

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

3. УО принимает сообщение с сертификатом, а затем формирует и отправляет запрос на аутентификацию УП головному узлу домена.

4. УП отправляет запрос на аутентификацию УО головному узлу домена.

5. ГУ анализирует сертификаты и открытую информацию об узлах и в случае необходимости делает запросы узлам из списка доверия аутентифицируемых узлов и на вышестоящий в иерархии домен.

6. Если ГУ отправил запросы на вышестоящий домен, то данный домен может рекурсивно делать запросы об аутентификации узла, принимая решение на основе ответов. В случае, если новый узел был признан вызывающим доверие, то домен посылает на ГУ подтверждение о корректности сертификата узла.

7. ГУ отправляет УП подтверждение о корректности сертификата вместе со специальным токеном сессии по ассиметричному каналу шифрования.

8. ГУ отправляет УО подтверждение о корректности сертификата вместе со специальным токеном сессии по ассиметричному каналу шифрования.

9. УО устанавливает сессию с УП с помощью полученного токена. Узлы обмениваются симметричными ключами шифрования для расшифровки закрытой части информации из сертификатов.

На фиг. 6 рассматривается удаление скомпрометированного узла (далее СКУ), который был обнаружен при аутентификации, содержащая следующие шаги:

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

2. После получения сообщения ОУ разрывают соединение с СКУ и отправляют подтверждение разрыва соединения ГУ

3. В случае если ГУ имеет доступ к вышестоящим доменам, то узел отправляет сообщение в УЦ, о блокировке СКУ. В случае если доступа к УЦ нет, то ГУ отправляет сообщение о блокировке СКУ всем контроллерам домена, сертификатами которых были подписаны сообщения от узла (если домен имеет доступ к ним). Само решение о блокировке происходит в автоматическом или ручном режиме на каждом из доверительных серверов доменов.

4. УЦ в автоматическом, используя сторонние системы помощи принятия решения, или ручном режиме, используя специальные интерфейсы взаимодействия с уже доверенными пользователями системы в зависимости от логики работы приложения, которое использует СОДДС, добавляет СКУ в список скомпрометированных узлов в рамках сети и оповещает домены, сертификатами которых был подписан СКУ о его компрометации. Далее УЦ (или вышестоящие домены) отправляют подтверждение о блокировке узла и ГУ утверждает блокировку СКУ

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

Каждый из доменов имеет собственный сертификат, который используется для подписи сертификатов узлов, функционирующих в рамках данного домена. Корневой домен А имеет собственный самоподписанный сертификат, который используется для подписи сертификатов нижестоящих доменов в соответствии с концепцией иерархических рекурсивных доменов, описанной в RFC 4387 и RFC 5280. Таким образом домен А подписывает сертификаты доменов Б и В, домен Б подписывает сертификаты доменов Г и Д, а домен В подписывает сертификат домена Е. Те же в свою очередь подписывают сертификаты всех узлов входящих в их домен, например сертификат оконечного узел домена Г (ОУГ) подписан сертификатом домена Г, ОУД подписан сертификатом Д, а ОУЕ - сертификатом Е. Для использования в дальнейшем при проверке сертификатов других узлов в сети - каждый узел, сразу после аутентификации и добавления в сеть, путем поочередного запроса сертификатов у вышестоящих доменов составляет списки проверенных узлов (далее СПУ), которые содержат все вышестоящие сертификаты вплоть до сертификата головного домена. Таким образом, каждый из узлов ОУГ, ОУД, ОУЕ имеет СПУ, отображенные на фиг. 8.

В качестве примера проверки сертификатов можно рассмотреть два основных случая - проверка между узлами расположенными в доменах связанных только лишь через головной узел (например взаимодействие узлов Г и Е в случае когда все взаимодействующие узлы доступны друг другу через домен А), а также проверка между узлами связанными одним из вышестоящих поддоменов доверительной сети (например взаимодействие узлов Г и Д в случае нарушения связности сети с корневым доменом).

В первом случае доверенные узлы посылают сертификаты друг другу через доверительную сеть, по получению каждый из узлов инициирует процедуру проверки сертификатов доменов. Например, ниже описана процедура проверки сертификата узла ОУГ узлом ОУЕ:

1. ОУЕ проверяет сертификат ОУГ, после его проверки он выделяет адрес домена Г, подписавшего сертификат ОУГ.

2. ОУЕ делает запрос сертификата Г. После получения он проводит проверку наличия сертификата Г в собственном СПУ В списке проверенных узлов ОУЕ находятся сертификаты ОУЕ, Е, В, А и таким образом узел не считает домен Г доверенным.

3. После проверки сертификата ОУЕ выделяет адрес домена Б, подписавшего сертификат Г и отправляет запрос на домен Б. Далее проводится проверка наличия сертификата в СД.

4. Далее ОУЕ выделяет адрес домена А и делает запрос сертификата на домен А. По результатам проверки узел обнаруживает сертификат в собственном списке проверенных узлов и таким образом цепочка сертификатов, подписавших ОУГ, считается доверенной. Сертификат ОУГ также может считаться доверенным.

В случае если ОУЕ не имеет доступ к одному из доменов, который присутствует в цепочке сертификатов или же корневой сертификат А отличается от сертификата, указанного в СПУ, то процедура аутентификации прерывается с оповещением пользователя и УЦ о недоверии смежному узлу.

Во втором случае доверенные узлы также посылают сертификаты друг другу через доверительную сеть и по получению каждый из узлов инициирует процедуру проверки сертификатов доменов. Например, ниже описана процедура аутентификации узла ОУГ узлом ОУД:

1. ОУД проверят сертификат ОУГ, после его проверки он имеет адрес домена Г, подписавшего сертификат данного узла.

2. ОУД делает запрос сертификата Г. После этого он проводит проверку наличия сертификата Г в собственном СПУ В списке проверенных узлов ОУД находятся сертификаты ОУД, Д, Б, А и таким образом узел не считает домен Г доверенным.

3. После проверки сертификата ОУД выделяет адрес домена Б, подписавшего сертификат Г и отправляет запрос на домен Б. По результатам проверки узел обнаруживает сертификат в собственном списке проверенных узлов и таким образом цепочка сертификатов, подписавших ОУГ, считается доверенной. Сертификат ОУГ также может считаться доверенным.

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

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

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

1. ОУД проверят сертификат ОУГ, после его проверки он имеет адрес домена Г, подписавшего сертификат данного узла.

2. ОУД делает запрос сертификата Г. После этого он проводит проверку наличия сертификата Г в собственном СПУ В списке проверенных узлов ОУД находятся сертификаты ОУД, Д, Б, А и таким образом узел не считает домен Г доверенным.

3. После проверки сертификата ОУД выделяет адрес домена Б, подписавшего сертификат Г и отправляет запрос на домен Б. Т.к. связи с доменом нет, то процедура завершается ошибкой.

4. Далее ОУД проводит повторную проверку связности с узлом ОУГ, отправляя ему запрос. В случае если ОУГ отвечает на запрос, то считается, что домены Г и Д связаны локально, через узлы являющимися частями и домена Г и домена Д.

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

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

7. В случае если на запрос ОУД приходит положительный ответ от узла, который считает доверенными домены Д и Г, то ОУД выводит предупреждение пользователю о частично (косвенной) доверенной связи и в зависимости от реакции пользователя подтверждает корректность сертификата ОУГ или нет.

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

Изобретение относится к системе организации децентрализованной доверительной связи. Технический результат - повышение эффективности идентификации и аутентификации сетевых устройств в децентрализованных сетях с возможным нарушением связности. Для определения уровня доверия между узлами используется цепочка последовательно подписанных контроллером домена сертификатов. Новый домен добавляется в систему путём создания нового сертификата домена для сетевого узла (СЕУ), который временно принимает роль головного узла (ГУ) и выбирается на основании заданных критериев, а его сертификат подписывается сертификатом вышестоящего домена в ручном или автоматизированном режиме, затем данный СЕУ запрашивает новый доменный адрес узла (ДАУ) у вышестоящего домена, который генерирует адрес и вносит в собственную таблицу адресации. При добавлении нового СЕУ, в случае если сертификат и идентификатор данного узла не находится в списке скомпрометированных узлов контроллера домена, СЕУ отправляет собственный сертификат на канальном уровне уже функционирующему в сети оконечному узлу (ОУ), который в свою очередь отправляет запрос о добавлении нового узла на подпись контроллеру домена, и в случае доступности контроллер домена удостоверяется в валидности данных сертификата нового СЕУ и подписывает его через сторонний доверенный канал, а в случае недоступности контроллера домена добавление нового узла прерывается и для избежания сетевой атаки выставляется задержка для повторного подключения. При блокировке СЕУ ГУ рассылает всем доверенным СЕУ домена обновленный список компрометированных узлов. В случае нарушения связности системы с корневым контроллером домена процедура аутентификации осуществляется в рамках изолированного сегмента системы, если аутентифицируемое СЕУ было предварительно зарегистрировано в любом из доменов системы, и любой из сертификатов контроллера доменов из списка доверия может быть проверен контроллером домена. 9 з.п. ф-лы, 10 ил.

1. Система организации децентрализованной доверительной связи (СОДДС), включает:

по крайней мере два домена, где домены подчинены иерархически, причем

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

по крайней мере один сетевой узел (СЕУ), который выступает в роли головного узла (ГУ) и может дополнительно выступать в роли управляющего центра (УЦ) и/или граничного шлюза (ГШ);

а подчинённый домен включает по крайней мере один СЕУ, где

СЕУ выступает в роли ГУ, а также может выступать в роли ГШ и/или узла включения (УВ) и/или УЦ,

причем ГУ:

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

• выполняет роль сервера доменных имен (СДИ);

• содержит таблицу адресации, содержащую уникальные идентификаторы СЕУ;

• содержит таблицу соответствия сокращённого адреса домена и уникального идентификатора контроллера нижестоящего уровня, который был добавлен данным ГУ;

причем подчиненный домен:

• включает в себя как минимум два типа СЕУ - оконечный узел (ОУ) и ГУ;

• имеет уникальный короткий адрес;

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

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

причем СЕУ:

• может принадлежать к двум и более доменам, кроме СЕУ с ролью ГУ в корневом домене;

• имеет сертификат, который подписан корневым сертификатом и контроллером домена, в котором расположен СЕУ, в случае если СЕУ является узлом в двух или более доменах, то сертификат подписан каждым из контроллеров домена;

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

• имеет уникальный идентификатор узла (ИДУ);

• имеет уникальный доменный адрес узла (ДАУ);

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

• содержит список скомпрометированных СЕУ для каждого домена, где он расположен;

• выполнен с возможностью определения, является ли устанавливающий соединение иной СЕУ доверенным без участия УЦ, с помощью системы иерархической проверки сертификатов и списков доверия, в случае нарушения связности сети;

причем в системе:

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

• новый домен добавляется в систему путём создания нового сертификата домена для СЕУ, который временно принимает роль ГУ и выбирается на основании заданных критериев, а его сертификат подписывается сертификатом вышестоящего домена в ручном или автоматизированном режиме, затем данный СЕУ запрашивает новый доменный адрес узла (ДАУ) у вышестоящего домена, который генерирует адрес и вносит в собственную таблицу адресации;

• при добавлении нового СЕУ, в случае если сертификат и идентификатор данного узла не находится в списке скомпрометированных узлов контроллера домена, СЕУ отправляет собственный сертификат на канальном уровне уже функционирующему в сети ОУ, который в свою очередь отправляет запрос о добавлении нового узла на подпись контроллеру домена, и в случае доступности контроллер домена удостоверяется в валидности данных сертификата нового СЕУ и подписывает его через сторонний доверенный канал, а в случае недоступности контроллера домена добавление нового узла прерывается и для избежания сетевой атаки выставляется задержка для повторного подключения;

• при блокировке СЕУ ГУ рассылает всем доверенным СЕУ домена обновленный список компрометированных узлов;

• обмен данными между СЕУ происходит по защищенному каналу с использованием протоколов TLS/DTLS;

• в основании Сервера доменных имён и системы адресации для поиска адреса СЕУ лежат сетевые запросы, использующие формат доменной системы имён (DNS) и динамической доменной системы имён (DDNS);

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

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

2. Система по п. 1, в которой ИДУ представляет собой строку, идентифицирующую узел в рамках системы и основанную на стандарте RFC 4122, имеющую формат «xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx» и состоящую из чисел в шестнадцатеричной системе счисления.

3. Система по п. 1, в которой список скомпрометированных СЕУ содержит идентификаторы и сертификаты заблокированных СЕУ.

4. Система по п. 3, в которой список скомпрометированных СЕУ формируется в случае компрометации СЕУ и поступает от контроллера домена.

5. Система по п. 1, в которой блокировка СЕУ может осуществляться пользователями системы через сетевой пользовательский интерфейс для взаимодействия со сторонними устройствами и приложениями.

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

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

8. Система по п. 1, в которой домен включает в себя как минимум два типа СЕУ - ОУ и ГУ, причем ГУ дополнительно включает роль маршрутизатора, в зависимости от используемых протоколов маршрутизации на сетевом уровне.

9. Система по п. 1, в которой ГШ:

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

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

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

10. Система по п. 1, в которой СЕУ, который временно принимает роль ГУ, выбирается на основании по крайней мере одного из следующих критериев:

• текущего уровня заряда устройства;

• значения сетевых задержек;

• джиттера;

• количества скачков при маршрутизации до любого из узлов в сети.