В начале каждого семестра студенты магистерской программы кафедры МиИТ Академического университета (СПб) и представители компаний-партнеров собираются вместе. Представители рассказывают о проектах, над которыми можно будет работать, а студенты выбирают их.В одном из проектов, сделанных в Parallels Labs, наш студент исследовал возможность реализации виртуального Hardware Security Module (HSM). В результате он добавил свою реализацию VHSM в open-source проект OpenVZ. Подробнее о его решении читайте под катом.
Что такое HSM
Представим себе приложение, которое подписывает отправляемые на сервер данные с помощью приватного ключа. Пусть утеря данного ключа неприемлема для его собственника. Как защитить такой ценный ключ от утечки в результате удаленного взлома системы? Подход с использованием HSM предлагает нам вообще не давать уязвимой части системы доступ к содержимому ключа. HSM – это физическое устройство, которое само хранит цифровые ключи или другие секретные данные, управляет ими, генерирует их, а также производит с их помощью криптографические операции. Все операции над данными производятся внутри HSM, а пользователь имеет доступ только к результатам этих операций. Внутренняя память устройства защищена от физического доступа и взлома. При попытке проникновения все секретные данные уничтожаются.
Чтобы начать использовать HSM, пользователь должен себя аутентифицировать. Если аутентификация выполняется через приложение-клиент HSM, работающее в уязвимой части системы, то возможен перехват пароля HSM злоумышленником. Перехваченный пароль даст возможность злоумышленнику использовать HSM без получения секретных данных, хранящихся в нем. Таким образом, аутентификацию желательно выполнять в обход уязвимой части системы, например, при помощи физического ввода PIN.
Основным барьером в использовании HSM является их высокая стоимость. В зависимости от класса устройства цена может варьироваться от 10$ (USB токены, smart карты) до 30000+$ (устройства с аппаратным ускорением криптографии, защитой от взлома, high availability функциями). Провайдеры cloud решений не оставили без внимания рынок HSM. Например, Amazon продает свой облачный HSM по средней цене 1373$ в месяц.
Одной из основных особенностей HSM является изоляция уязвимой части системы, использующей криптографические сервисы, от HSM, исполняющей эти сервисы. Заметим, что отдельные инстансы (виртуальные машины, контейнеры и т.д.), в облаке изолированы друг от друга, поэтому если вынести функции HSM за пределы уязвимого инстанса в другой изолированный от внешнего мира инстанс, то мы достаточно точно воспроизведем функциональность физического HSM. Такой подход мы назвали Virtual HSM (VHSM). Рассмотрим как он был реализован нашим студентом для проекта OpenVZ.
Что такое OpenVZ
OpenVZ – это одна из технологий для запуска множества изолированных ОС Linux на одном ядре Linux. При этом говорят, что каждая ОС Linux работает в отдельном контейнере. Если сильно упрощать, то фактически в ядро Linux встроена функциональность, которая позволяет изолировать приложения, приписанные разным контейнерам так, чтобы они не подозревали о существовании друг друга. Приложения не могут сменить свой контейнер. Для лучшей изоляции и безопасности коммуникация между приложениями из разных контейнеров при помощи средств IPC запрещена. Обычно она осуществляется с помощью сетевых соединений. В итоге мы видим сходство контейнеров с “обычными” виртуальными машинами. OpenVZ и технологии на ее основе популярны у хостинг провайдеров для создания VPS. В Академическом университете уже делались проекты, связанные с контейнерной виртуализацией. Например habrahabr.ru/company/parallels/blog/174211. Parallels – главный разработчик OpenVZ. Вполне закономерной стала реализация VHSM именно для OpenVZ.
Архитектура Virtual HSM
- Client VE – контейнер OpenVZ, в котором выполняются пользовательские приложения, требующие для своей работы криптографические сервисы, такие как шифрование, подпись и т.д. Контейнер доступен для удаленных атак с целью кражи цифровых ключей.
- VHSM virtual environment (VHSM VE) — контейнер OpenVZ, в котором запущен VHSM server – демон, принимающий команды от приложений в Client VE и исполняющий их. Никаких других приложений в VHSM VE не запущено. VHSM VE изолирован от обычных пользовательских контейнеров при помощи OpenVZ. У контейнера нет сетевых интерфейсов и он не доступен по сети.
- Transport – модуль ядра Linux, предназначенный для передачи сообщений из Client VE в VHSM VE и обратно.
- VHSM API – библиотека, реализующая часть стандартного для HSM интерфейса PKCS #11, передающая команды приложений из ClientVE в VHSM server при помощи transport, и возвращающая результат выполнения команды приложению в ClientVE.
Рассмотри каждый компонент подробнее.
VHSM virtual environment
Сервер VHSM отвечает за аутентификацию пользователей, взаимодействие с хранилищем секретных данных и выполнение криптографических операций. Кроме сервера VHSM, VHSM VE содержит Secure Storage – базу данных, хранящую важную информацию в зашифрованном виде. Каждый пользователь VHSM имеет свой мастер ключ, которым шифруются его данные. Мастер ключ генерируется из пароля пользователя при помощи функции PBKDF2. Передаваемая ей на вход соль хранится в незашифрованном виде в базе данных. Таким образом, VHSM не хранит мастер ключ пользователя в БД, а использование PBKDF2 существенно снижает скорость перебора исходного пароля пользователя при краже БД.
Пользователь регистрируется в VHSM администратором, в роли которого может выступать как человек, так и программа. При регистрации пользователя VHSM генерирует 256-битный ключ аутентификации и шифрует его мастер ключом с помощью AES-GCM. Далее, перед использованием VHSM, пользователь аутентифицирует себя парой логин-пароль. Во время аутентификации, мастер-ключ, сформированный из пароля и соли, используется для расшифровывания ключа аутентификации пользователя. Использование GCM позволяет проверить правильность мастер-ключа при расшифровке. Мастер-ключ получается из пароля пользователя, и потому проверка его правильности позволяет проверить и сам пароль пользователя, переданный при аутентификации. После успешной аутентификации пользователю становятся доступны криптографические сервисы, использующие хранящиеся в VHSM цифровые ключи пользователя.
VHSM требует явного выбора контейнеров, из которых конкретный пользователь может работать с VHSM. Информация о контейнере, из которого получена команда пользователя, предоставляется OpenVZ.
VHSM API
Это C-библиотека, находящаяся в пользовательских контейнерах и реализующая часть стандартного для HSM интерфейса PKCS#11, позволяющего управлять ключами, данными, сессиями, цифровой подписью, шифрованием и т.д. Рассмотрим конкретный пример использования VHSM API:
- Приложению в пользовательском контейнере необходимо подписать отправляемое сообщение.
- При помощи VHSM API приложение генерирует пару открытый-закрытый ключ, получает ID закрытого ключа и открытый ключ.
- Приложение передает сообщение в VHSM API для подписывания закрытым ключом с нужным ID. VHSM API возвращает подписанное сообщение.
- Подписанное сообщение и открытый ключ передаются получателю сообщения. При этом закрытый ключ не доступен клиентскому контейнеру.
В клиентской части проекта также были реализованы OpenSSL engine и PAM-модуль, позволяющие работать с VHSM в существующих приложениях, использующих OpenSSL и PAM. Однако, эта часть проекта слабо проработана и представляет собой скорее proof of concept.
VHSM Transport
Как было сказано выше, приложения, исполняющиеся в разных контейнерах, не могут взаимодействовать друг с другом при помощи механизмов IPC Linux. Поэтому для транспортировки сообщений от клиентов к серверу и обратно был реализован свой загружаемый модуль ядра Linux. Модуль запускает Netlink-сервер в ядре, а VHSM-клиенты и VHSM-сервер соединяются с ним. Netlink-сервер отвечает за передачу сообщений от источника (клиента VHSM) к приемнику (серверу VHSM) и обратно. Попутно к сообщениям добавляется ID контейнера источника сообщения, чтобы, например, сервер мог отклонить запросы от контейнеров, из которых конкретному пользователю запрещено использовать VHSM.
Заключение
Основной целью создания VHSM было исключение возможности кражи секретных ключей из памяти пользовательских приложений, работающих в пользовательском контейнере. Эта цель была достигнута, т.к. секретные данные доступны только в изолированном контейнере (VHSM VE). Изоляция реализуется OpenVZ.
Утечка БД из VHSM VE не приведет к немедленной утрате секретных данных, т.к. они хранятся в зашифрованном виде. Ключ шифрования не хранится в БД, а генерируется из пароля пользователя, передающегося при его аутентификации.
Как и любая технология защиты иформации, приведенное решение является еще одним барьером на пути злоумышленника и не обеспечивает полной защиты информации.