Прежде чем перейти к статье, хочу вам представить, экономическую онлайн игру Brave Knights, в которой вы можете играть и зарабатывать. Регистируйтесь, играйте и зарабатывайте!
Проблема безопасной отправки данных между доменами с разным уровнем доступа возникает в различных сценариях передачи информации по сети. Большинство методов решения данной задачи использует политики безопасности и доверенные стороны, при этом создание системы, работающей в произвольной сети, является сложной задачей.
В данной статье рассматривается новый алгоритм на основе функционального шифрования, который позволяет решить данную проблему.
Введение
Cross Domain Problem (CDP) — проблема безопасного распространения секретной информации между доменами с разными уровнями доступа. Большинство существующих решений (Cross Domain Solution, CDS) основаны на системах управления рисками, которые обычно полагаются на доверенных лиц. Однако лучшим решением является полностью автоматизированная система, которая позволит источнику информации передавать данные между доменами с различными уровнями доступа, не раскрывая при этом информацию об участниках общения.
Функциональное шифрование (FE) — это обобщение шифрования с открытым ключом. Схемы функционального шифрования позволяют вычислять некоторую функцию открытого текста при знании секретного ключа и зашифрованного текста. Некоторые из этих схем основаны на использовании информации о пользователях или дополнительных атрибутов, добавляемых к передаваемому сообщению.
Далее будет рассмотрен алгоритм, предложенный учеными Рочестерского технологического института и сотрудниками компании L3Harris Technologies: Solving the Cross Domain Problem with Functional Encryption [1].
Описание системы
Во время передачи информации по сети необходимо осуществлять маршрутизацию данных между участниками общения с различными уровнями доступа.
В работе [1] исследуется сеть, в которой несколько источников сообщений генерируют данные разного уровня секретности.
Зашифрованные данные передаются в широковещательный домен, где обрабатываются сетевыми шлюзами. Каждый из шлюзов может пропустить данные в подключенную к нему подсеть, или отбросить их, предполагая, что данные предназначены другой подсети. При этом ни один из шлюзов не может расшифровать сообщение или получить информацию об отправителе и получателе сообщения.
![Модель рассматриваемой сети [2]](https://habrastorage.org/getpro/habr/upload_files/ada/fce/13b/adafce13bc985d0ca5bdacb32a3bd0f6.png "Модель рассматриваемой сети [2]")
Обеспечение безопасности отправки данных происходит следующим образом: каждый отправитель шифрует сообщение своим симметричным ключом, который используется только отправителем и получателем. Затем отправитель добавляет к зашифрованному сообщению атрибут, кодирующий подсеть получателя.
Так как шлюзы принимают решения о передаче сообщений из широковещательного домена в подсети получателей, после добавления атрибута к сообщению весь пакет данных подписывается секретным "скрывающим" ключом (concealing key), связанным с конкретным шлюзом в сети. Тот шлюз, который должен направить пакет получателю данного сообщения, имеет свой публичный "раскрывающий" ключ (revealing key). Используя его, шлюз проверяет, подключена ли к нему подсеть, соответствующая атрибуту пакета, после чего принимает решение о передаче данных.
Алгоритм FE-CDS
Рассмотрим работу предложенного алгоритма более подробно.
Подготовка
![Процесс шифрования [1]](https://habrastorage.org/getpro/habr/upload_files/6ae/bd0/397/6aebd039739db450c1f36f9149e779e7.png "Процесс шифрования [1]")
Отправитель генерирует сообщение (plaintext PT) и шифрует его своим секретным симметричным ключом K, в результате чего создается шифротекст CT.
Затем отправитель добавляет к зашифрованному сообщению булевы атрибуты 
и скрывает их при помощи алгоритма, описанного далее. Для генерации ключей K может использоваться один из блочных шифров, например AES.
Для распределения ключей применяется доверенный центр распределения ключей (Key Distribution Center, KDC).
Протокол
Генерация ключей. Доверенный KDC генерирует пару ключей цифровой подписи для каждого из атрибутов 
закрытый ключ 
и открытый ключ 
В отличие от других алгоритмов, открытый ключ не распространяется публично. KDC безопасно отправляет закрытый ключ отправителю сообщения, а открытый — тому получателю, который должен расшифровать значение атрибута 
Для генерации ключей используется один из алгоритмов цифровой подписи, например ECDSA.
Отправитель. Отправитель создает зашифрованное сообщение 
и определяет значение каждого из атрибутов 
в зависимости от того, в какой подсети находится получатель. Создание сокрытых атрибутов 
происходит следующим образом: если значение 
ложно, то 
иначе
Затем отправитель присоединяет значения сокрытых атрибутов 
к зашифрованному сообщению 
и отправляет пакет.
![Сокрытие атрибутов отправителем [1]](https://habrastorage.org/getpro/habr/upload_files/454/e25/2ef/454e252ef5f8211037650a590141d50c.png "Сокрытие атрибутов отправителем [1]")
Получатель. Получатель пакета (шлюз) может раскрыть значение того атрибута 
для которого он имеет закрытый ключ 
Если срабатывает проверка 
то значение атрибута 
ложно. Если выполняется 
то значение 
истинно. Если обе попытки проверки подписи не были успешны, то исходное значение 
определить невозможно. Такая ситуация может возникнуть в том случае, если зашифрованное сообщение или значение атрибута были изменены или подделаны.
![Раскрытие атрибутов получателем [1]](https://habrastorage.org/getpro/habr/upload_files/0de/026/036/0de02603682b7f3984ee2c0a8eb9634f.png "Раскрытие атрибутов получателем [1]")
Безопасность. В предложенной схеме шлюзы или злоумышленники не могут:
определить исходное сообщение (нет симметричного ключа шифрования),
определить значения чужих атрибутов (нет "раскрывающих" ключей). В данном алгоритме получатель пакета может определить значение только того атрибута
для которого у него есть ключ 
подделать или изменить зашифрованное сообщение или атрибуты (нет симметричного ключа шифрования и "скрывающих" ключей). При попытке изменения пакета обе проверки цифровой подписи у получателя сообщения не будут успешны.
Так как алгоритм ECDSA при вычислении цифровой подписи использует некоторое случайное число, скрытые значения атрибутов 
будут отличаться в каждом пакете даже при одинаковых зашифрованных сообщениях 
и атрибутах 
Таким образом, ни одна из сторон общения не сможет сопоставить скрытые значения атрибутов с их фактическими значениями.
Сценарий применения алгоритма
Одним из возможных сценариев применения алгоритма может быть распространение секретных документов пользователям с разным уровнем доступа. Допустим, существуют 3 пользовательских сети с уровнями доступа Несекретно, Секретно, Совершенно секретно, и им соответствуют булевы атрибуты 
При передаче пакета отправитель устанавливает значения этих атрибутов следующим образом:
для несекретного документа:
для секретного документа:
для совершенно секретного документа:
Сообщение и атрибуты зашифровываются и отправляются в сеть, после чего принимается шлюзами. На каждом шлюзе происходит определение значения того атрибута, который соответствует уровню доступа пользователей в подключенной к нему подсети. Если значение атрибута истинно, то пакет пересылается в подсеть.
Предложенная схема может быть дополнительно расширена и использовать атрибуты с 
дискретными значениями. В этом случае для сокрытия атрибутов 
в зависимости от их значения необходимо вычислить цифровую подпись для одного из выражений 
Для демонстрации работы алгоритма исследователями была реализована следующая система:
![Схема тестовой системы [1]](https://habrastorage.org/getpro/habr/upload_files/acb/3fb/3b5/acb3fb3b5efb4a58d120683545335865.png "Схема тестовой системы [1]")
Перед началом передачи данных необходимо произвести распределение ключей. Для этого доверенный центр генерирует и раздает ключи 
отправителю и получателям сообщения, которые находятся за шлюзами 0, 1 и 2 соответственно. После этого центр передает ключи 
отправителю для сокрытия атрибутов, а ключи 
— шлюзам.
Рассмотрим еще раз процесс отправки сообщения:
отправитель шифрует сообщение ключом
соответствующим ключу получателя,отправитель устанавливает значения атрибутов и добавляет их к шифротексту, подписывая ключом
отправитель пересылает широковещательный пакет всем шлюзам в сети,
каждый шлюз определяет исходное значение одного атрибута
при помощи ключа 
после чего пересылает пакет в случае, если значение 
было истинно,получатель пакета расшифровывает сообщение ключом
Авторами работы была проведена симуляция отправки сообщений в предложенной системе. Результаты показали, что данный алгоритм может иметь применение, так как его вычислительная сложность довольно мала. Время, затраченное алгоритмом на каждом этапе работы при использовании шифрования с ключом длиной 128 бит приведено в таблице.
Время, мкс | |||
Вычисление | Отправитель | Шлюз | Получатель |
Шифрование (AES-GCM) | 222 | ||
Подпись атрибутов | 1929 | ||
Проверка атрибутов | 5568 | ||
Расшифровка (AES-GCM) | 521 | ||
Для сравнения, в работе [3] при использовании гомоморфного шифрования в аналогичной схеме подготовка данных к отправке заняла 35 минут, а расшифровка - 20 часов.
Заключение
Итак, предложенный алгоритм позволяет решить проблему отправки данных пользователям с различным уровнем доступа к информации, показывая при этом приемлемое время работы и устойчивость к атакам. Для реализации безопасного доступа к информации используется схема функционального шифрования и дополнительные атрибуты, добавляемые к сообщению.
Однако вопрос распределения ключей не рассматривается в данной системе, и авторами предлагается использовать сторонние способы решения этой проблемы. Фактически, применение доверенных центров или других методов вносит вероятность перехвата ключей и взлома системы.
Литература
[1] Kaminsky A, Kurdziel M, Farris S, Łukowiak M, Radziszowski S. Solving the Cross Domain Problem with Functional Encryption.
[2] Committee on National Security Systems. Committee on National Security Systems (CNSS) Glossary. (4009):160, 2015.
[3] C. Tinker, K. Millar, A. Kaminsky, M. Kurdziel, M. Lukowiak, and S. Radziszowski. Exploring the application of homomorphic encryption to a cross domain solution. In MILCOM 2019 - 2019 IEEE Military Communications Conference (MILCOM), pages 1–6, 2019.
