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

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

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

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

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

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

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

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

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

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

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

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

   В примере используется самоподписанный сертификат, поэтому большинство современных браузеров сообщит о незащищенности соединения. Нужно согласиться использовать незащищенное соединение, которое тем не менее будет зашифрованным. При использовании некоторых браузеров возможно возникновение сообщения "mbedtlsErrorCode=-0x7780, Error performing SSL handshake: SSL - A fatal alert message was received from our peer".

2. Веб-сервер Boost, запущенный в программе WebServer, отображает страницу index.html, содержащую приглашение к аутентификации.
3. Пользователь нажимает на кнопку Log in.
4. Программа WebServer обращается к программе AuthService по IPC для получения страницы, содержащей форму ввода имени пользователя и пароля.
5. Программа AuthService выполняет следующие действия:
   • генерирует закрытый ключ, открытые параметры, а также вычисляет открытый ключ по алгоритму Диффи-Хеллмана;
   • создает страницу auth.html с формой ввода имени пользователя и пароля (код страницы содержит открытые параметры и открытый ключ);
   • передает полученную страницу программе WebServer по IPC.
6. Веб-сервер Boost, запущенный в программе 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. Веб-сервер Boost, запущенный в программе WebServer, отображает страницу result_err.html или страницу result_ok.html.

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

Динамическое создание IPC-каналов

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

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

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

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

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

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

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

1. Перейдите в директорию с примером Secure Login.
2. Удалите директорию build с результатами предыдущей сборки, выполнив команду:

   sudo rm -rf build/

3. Выполните команды для запуска тестирования:

   $ KL_WITH_TEST=YES

   $ cmake -B build -D CMAKE_TOOLCHAIN_FILE="$KOSCEDIR/toolchain/share/toolchain-*-kos.cmake" && cmake --build build --target sim

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

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

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

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

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

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

Для сборки и запуска примера используется система CMake из состава KasperskyOS Community Edition SDK.

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