Пример 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.

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

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

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

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

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

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

$ cd build/einit

# Перед выполнением следующей команды убедитесь, что путь к

# директории с исполняемым файлом qemu-system-aarch64 сохранен в

# переменной окружения PATH. В случае отсутствия

# добавьте его в переменную PATH.

$ qemu-system-aarch64 -m 2048 -machine vexpress-a15 -nographic -monitor none -net nic,macaddr=52:54:00:12:34:56 -net user,hostfwd=tcp::1106-:1106 -sd sdcard0.img -kernel kos-qemu-image

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

Для корректной работы примера 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, которая генерируется во время сборки примера.