Паттерн Information Obscurity

Описание

Цель паттерна Information Obscurity – шифрование конфиденциальных данных в небезопасных средах с целью защиты данных от кражи.

Контекст

Этот паттерн следует использовать, когда данные часто передаются между частями системы и/или между системой и другими (внешними) системами.

Проблема

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

Решение

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

Примеры реализации

Пример реализации паттерна Information Obscurity: Пример Secure Login.

Источники

Паттерн Information Obscurity подробно рассмотрен в следующих работах:

• Dangler, Jeremiah Y., "Categorization of Security Design Patterns" (2013). Electronic Theses and Dissertations. Paper 1119. https://dc.etsu.edu/etd/1119
• Schumacher, Markus, Fernandez-Buglioni, Eduardo, Hybertson, Duane, Buschmann, Frank, and Sommerlad, Peter. "Security Patterns: Integrating Security and Systems Engineering" (2006).

Пример Secure Login (Civetweb, TLS-terminator)

Пример Secure Login демонстрирует использование паттерна Information Obscurity. Пример демонстрирует возможность передачи критической для системы информации через недоверенную среду.

Архитектура примера

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

С точки зрения архитектуры в таких системах можно выделить следующие субъекты:

• Источник данных: браузер пользователя.
• Точка коммуникации с устройством: веб-сервер.
• Подсистема обработки информации от пользователя: подсистема аутентификации.

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

1. Обеспечить взаимодействие источника данных и устройства по протоколу HTTPS. Это позволит избежать "прослушивания" HTTP-трафика и атак типа MITM (man in the middle).
2. Выработать между источником данных и подсистемой обработки информации общий секрет.
3. Использовать этот секрет для шифрования информации на стороне источника данных и расшифровки на стороне подсистемы обработки информации. Это позволит избежать компрометации данных внутри устройства (в точке коммуникации).

Пример Secure Login включает следующие компоненты:

• Веб-сервер Civetweb (недоверенный компонент, программа WebServer).
• Подсистему аутентификацию пользователей (доверенный компонент, программа AuthService).
• TLS-терминатор (доверенный компонент, программа TlsEntity). Этот компонент поддерживает транспортный механизм TLS (transport layer security). TLS-терминатор совместно с веб-сервером поддерживают протокол HTTPS на стороне устройства (веб-сервер взаимодействует с браузером через TLS-терминатор).

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

1. Пользователь открывает в браузере страницу по адресу https://localhost:1106 (при запуске примера на QEMU) или по адресу https://<IP-адрес Raspberry Pi>:1106 (при запуске примера на Raspberry Pi 4 B). HTTP-трафик между браузером и TLS-терминатором будет передаваться в зашифрованном виде, а веб-сервер будет работать с открытым HTTP-трафиком.

   В примере используется самоподписанный сертификат, поэтому большинство современных браузеров сообщит о незащищенности соединения. Нужно согласиться использовать незащищенное соединение, которое тем не менее будет зашифрованным. В некоторых браузерах возможно возникновение сообщения "TLS: Error performing handshake: -30592: errno = Success".

2. Веб-сервер Civetweb, запущенный в программе WebServer, отображает страницу index.html, содержащую приглашение к аутентификации.
3. Пользователь нажимает на кнопку Log in.
4. Программа WebServer обращается к программе AuthService по IPC для получения страницы, содержащей форму ввода имени пользователя и пароля.
5. Программа AuthService выполняет следующие действия:
   • генерирует закрытый ключ, открытые параметры, а также вычисляет открытый ключ по алгоритму Диффи-Хеллмана;
   • создает страницу auth.html с формой ввода имени пользователя и пароля (код страницы содержит открытые параметры и открытый ключ);
   • передает полученную страницу программе WebServer по IPC.
6. Веб-сервер Civetweb, запущенный в программе WebServer, отображает страницу auth.html с формой ввода имени пользователя и пароля.
7. Пользователь заполняет форму и нажимает на кнопку Submit (корректные данные для аутентификации содержатся в файле secure_login/auth_service/src/authservice.cpp).
8. Код страницы auth.html, который исполняется на стороне браузера, осуществляет следующие действия:
   • генерирует закрытый ключ, вычисляет открытый ключ и общий секретный ключ по алгоритму Диффи-Хеллмана;
   • выполняет шифрование пароля операцией XOR с использование общего секретного ключа;
   • передает веб-северу имя пользователя, зашифрованный пароль и открытый ключ.
9. Программа WebServer обращается к программе AuthService по IPC для получения страницы, содержащей результат аутентификации, передавая имя пользователя, зашифрованный пароль и открытый ключ.
10. Программа AuthService выполняет следующие действия:
    • вычисляет общий секретный ключ по алгоритму Диффи-Хеллмана;
    • расшифровывает пароль с использованием общего секретного ключа;
    • возвращает страницу result_err.html или страницу result_ok.html в зависимости от результата аутентификации.
11. Веб-сервер Civetweb, запущенный в программе WebServer, отображает страницу result_err.html или страницу result_ok.html.

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

Unit-тестирование с использованием фреймворка GoogleTest

Помимо паттерна Information Obscurity пример Secure Login демонстрирует использование фреймворка GoogleTest для выполнения unit-тестирования программ, разработанных под KasperskyOS (KasperskyOS Community Edition содержит в своем составе этот фреймворк).

Исходный код тестов находится по следующему пути:

/opt/KasperskyOS-Community-Edition-<version>/examples/secure_login/tests

Эти unit-тесты предназначены для верификации некоторых cpp-модулей подсистемы аутентификации и веб-сервера.

Чтобы запустить тестирование, выполните следующие действия:

1. Перейдите в директорию с примером Secure Login.
2. Удалите директорию build с результатами предыдущей сборки, выполнив команду:
   sudo rm -rf build/
3. Выполните команду для запуска тестирования:
   $ RUN_TESTS=YES ./cross-build.sh

Тесты выполняются в программе TestEntity. Программы AuthService и WebServer не запускаются, поэтому при выполнении тестирования пример нельзя использовать для демонстрации паттерна Information Obscurity.

После завершения тестирования выводятся результаты выполнения тестов.

Файлы примера

Код примера и скрипты для сборки находятся по следующему пути:

Сборка и запуск примера

Чтобы запустить пример на QEMU, перейдите в директорию с примером, соберите пример и выполните следующие команды:

Также см. "Сборка и запуск примеров".

Для корректной работы примера secure_login на Raspberry Pi после сборки примера и подготовки загрузочной SD-карты требуется выполнить следующие действия:

• скопировать директории certs и www, расположенные по пути /opt/KasperskyOS-Community-Edition-<version>/examples/secure_login/resources/hdd, в корневую директорию загрузочной SD-карты;
• создать директорию /lib на загрузочной SD-карте, если этой директории не существует;
• скопировать в директорию /lib на загрузочной SD-карте содержимое директории build/hdd/lib, которая генерируется во время сборки примера.