Русский
Русский
English
Статистика
Реклама

Encryption

Zabbix под замком включаем опции безопасности компонентов Zabbix для доступа изнутри и снаружи

02.11.2020 10:17:21 | Автор: admin
А не пришло ли время разобраться и навести наконец-то порядок с безопасностью в мониторинге? Тем более, в одной из популярных систем мониторинга и встроенная возможность такая имеется.



На схеме видно, что зашифровать можно почти все потоки внутри Zabbix. В этой статье мы расскажем и покажем как это сделать, а еще расскажем о новой интеграции Zabbix с хранилищем секретов Hashicorp Vault. Там можно хранить любую чувствительную информацию от логина/пароля в БД до значений макросов. Это позволит централизованно управлять авторизационными данными, вести аудит и не хранить их на файловой системе или в БД Zabbix. Такой функционал появился в последней (на момент публикации статьи) версии Zabbix 5.2.

Интересный факт: включение шифрования на компонентах Zabbix не требует открытия дополнительных портов на фаерволлах, демоны Zabbiх поддерживают шифрованные и нешифрованные соединения одновременно.

Велкам ту подкат.

В Zabbix есть следующие основные информационные потоки:

  • Пользователь (web-браузер) <-> Zabbix web-сервер. Управление конфигурацией Zabbix, представление метрик. Шифрование настраивается средствами web-сервера.
  • Zabbix web-сервер <-> Zabbix-сервер. Web-сервер проверяет запущен ли Zabbix-сервер, запрашивает текущее состояние очереди, выполняет тест элементов данных и некоторые другие операции. Единственный поток, который в соответствии с архитектурой Zabbix нельзя зашифровать. Мы даже пытаться не будем.
  • Zabbix web-сервер <-> База данных Zabbix. Web-сервер обновляет конфигурацию в БД, извлекает данные для визуализации, удаляет исторические данные (по нажатию на Очистить историю) и запускает задания Выполнить сейчас (Execute now). Можно настроить при установке или позже в файле конфигурации zabbix.conf.php. Поддерживается TLS-шифрование при помощи ключей. Для хранения логина и пароля для БД можно использовать Vault. Важный факт: сертификаты, защищённые паролем не поддерживаются.
  • Zabbix-сервер <-> База данных Zabbix. Zabbix-сервер через configuration syncer загружает в свой кэш конфигурацию, через history syncer записывает собранные данные в БД, очищает историю (housekeeping) и выполняет некоторые другие операции. Настройки шифрования выполняются через присваивание значений специальным ключам в конфигурационном файле zabbix_server.conf.
  • Zabbix-сервер <-> Zabbix-агент. Поддерживаются общий ключ PSK и сертификаты. Взаимодействие этих компонентов делится на две части: к узлу сети (TLSAccept для пассивных проверок) и от узла сети (TLSConnect для активных проверок).
  • Zabbix-сервер <-> Zabbix-прокси. Поддерживаются общий ключ PSK и сертификаты. Настройки выполняются через присваивание значений специальным ключам в конфигурационном файле zabbix_proxy.conf.
  • Zabbix-прокси <-> Zabbix-агент. Поддерживаются общий ключ PSK и сертификаты. Взаимодействие этих компонентов делится на две части: к узлу сети (TLSAccept для пассивных проверок) и от узла сети (TLSConnect для активных проверок).
  • Zabbix-прокси <-> БД Zabbix-прокси. Настройки выполняются через присваивание значений специальным ключам в конфигурационном файле zabbix_proxy.conf.
  • Zabbix sender -> Zabbix-прокси. Поддерживаются общий ключ PSK и сертификаты в качестве параметров при вызове через командную строку.
  • Zabbix-агент -> Zabbix get. Поддерживаются общий ключ PSK и сертификаты в качестве параметров при вызове через командную строку.


Пользователь (web-браузер) <-> Zabbix web-сервер


Шифрование этой коммуникации не поддерживается со стороны Zabbix, нужно самостоятельно выполнить настройку на стороне Apache или Nginx. В этой статье мы рассмотрим настройку Nginx с самоподписанным SSL-сертификатом, т.к. преимущественно используем именно Nginx в своих проектах по мониторингу на базе Zabbix. Можно использовать сертификат доверенного центра сертификации, например, бесплатный от Let's Encrypt. Это позволит избежать страшных предупреждений в браузере. Обращаем внимание, что использование самоподписанного сертификата никак не умаляет надежности шифрованного соединения, оно будет таким же защищённым как и при использовании сертификата от доверенного CA.

Листинг настройки
# mkdir -p /etc/ssl/private/
# chmod 0750 /etc/ssl/private
# openssl req \
> -newkey rsa:2048 -nodes -keyout /etc/ssl/private/zabbix.key \
> -x509 -days 365 -out /etc/ssl/certs/zabbix.crt \
> -subj "/C=RU/ST=Russia/L=Moscow/O=Gals/OU=Gals_Dev/CN=gals.software/emailAddress=welcome@gals.software"
# chmod 0400 /etc/ssl/certs/zabbix.crt
# chmod 0400 /etc/ssl/private/zabbix.key
# mv /etc/nginx/conf.d/zabbix.conf /etc/nginx/conf.d/zabbix-ssl.conf
# vi /etc/nginx/conf.d/zbx-ssl.conf
listen 443 ssl default_server;
ssl on;
ssl_certificate /etc/ssl/certs/zabbix.crt;
ssl_certificate_key /etc/ssl/private/zabbix.key;
# vi /etc/nginx/conf.d/zabbix.conf
server {
listen 80;
return 301 https://$host$request_uri;
}
# systemctl restart nginx




В браузере появится замочек и можно посмотреть детали сертификата. Соединение зашифровано.


Zabbix web-сервер <-> База данных Zabbix


Перед началом настройки на стороне Zabbix, в БД должны быть созданы пользователи и роли с атрибутами, требующими шифрованное подключение.

Листинг создания пользователей для Zabbix web-сервера и Zabbix-сервера
mysql> CREATE USER    'zabbix_srv'@'%' IDENTIFIED WITH mysql_native_password BY '<strong_password>',    'zabbix_web'@'%' IDENTIFIED WITH mysql_native_password BY '<strong_password>' REQUIRE SSL    PASSWORD HISTORY 5; mysql> CREATE ROLE 'zabbix_srv_role', 'zabbix_web_role'; mysql> GRANT SELECT, UPDATE, DELETE, INSERT, CREATE, DROP, ALTER, INDEX, REFERENCES ON zabbix.* TO 'zabbix_srv_role'; mysql> GRANT SELECT, UPDATE, DELETE, INSERT ON zabbix.* TO 'zabbix_web_role'; mysql> GRANT 'zabbix_srv_role' TO 'zabbix_srv'@'%'; mysql> GRANT 'zabbix_web_role' TO 'zabbix_web'@'%'; mysql> SET DEFAULT ROLE 'zabbix_srv_role' TO 'zabbix_srv'@'%'; mysql> SET DEFAULT ROLE 'zabbix_web_role' TO 'zabbix_web'@'%';


Вызов статуса вернет, в том числе, данные по настройкам шифрования. Убедимся, что в строке SSL указаны алгоритмы шифрования.



Настройку шифрования между Zabbix и базой данных можно выполнить сразу при первичной настройке Zabbix через web-интерфейс. Обратите внимание на подпись напротив Database TLS encryption. Из-за того, что для подключения к локальной БД используется socket file, нет возможности настроить шифрованное подключение. Поэтому в поле Хост базы данных должны быть указаны IP-адрес или имя сервера с БД.



Меняем localhost на IP-адрес сервера и появляется чекбокс.



На двух скриншотах выше можно увидеть нововведение в Zabbix версии 5.2 поддержку интеграции с хранилищем Vault. Перед началом настройки Zabbix мы создали пару ключей и учетными данными для подключения к БД.



Берем клиентские ключи MySQL, заполняем необходимые поля и нажимаем Далее.



Другой способ настроить то же самое соответствующие ключи в конфигурационном файле zabbix.conf.php.

$DB['ENCRYPTION'] = true;
$DB['KEY_FILE'] = '/etc/ssl/mysql/client-key.pem';
$DB['CERT_FILE'] = '/etc/ssl/mysql/client-cert.pem';
$DB['CA_FILE'] = '/etc/ssl/mysql/ca.pem';
$DB['VERIFY_HOST'] = true;
$DB['CIPHER_LIST'] = '';


Zabbix-сервер <-> База данных Zabbix


На предыдущем шаге мы уже создали пользователя для подключения, клиентские ключи для подключения тоже есть. Осталось прописать эти данные в конфигурационный файл Zabbix-сервера.

DBTLSConnect=required
DBTLSCAFile=/etc/ssl/mysql/ca.pem
DBTLSCertFile=/etc/ssl/mysql/client-key.pem
DBTLSKeyFile=/etc/ssl/mysql/client-cert.pem
DBTLSCipher=''


После выполненных настроек, необходима перезагрузка службы Zabbix-сервера. Логин и пароль для подключения Zabbix-сервера к БД мы также храним в Vault.



Использование Vault требует добавления значений к следующим переменным в конфигурации Zabbix-сервера:

VaultDBPath=kv/secret/zabbix
VaultToken=s.Ev50RnGXNM3FmmcVBMRrR4Nz
VaultURL=http://192.168.56.101:8200


Переменная VaultDBPath отвечает за хранение учетных данных для подключения к БД. Подробнее о шифровании подключений к БД можно узнать в документации Zabbix.

Zabbix-сервер <-> Zabbix-прокси


Как многие пользователи Zabbix знают, в системе существует два типа подключений для передачи метрик: пассивные и активные. Пассивные подразумевают запрос к источнику данных, а активные отправку данных от источника вне зависимости запроса приемника. Аналогичным образом, соединение между сервером и прокси могут быть пассивными или активными. На скриншоте ниже настроен активный прокси, соединение, с которым зашифровано по технологии PSK.



Обратите внимание, что исходящие соединения (пассивные) могут выполняться каким-то одним способом на выбор, а для входящих доступны комбинации вариантов: без шифрования, PSK или сертификат.

На стороне прокси все настройки выполняются в конфигурационном файле. Для активных проверок:

TLSConnect=psk
TLSPSKIdentity=test_zabbix
TLSPSKFile=/var/zabbix/agentd.psk


Для пассивных проверок:

TLSAccept=psk
TLSPSKIdentity=test_zabbix
TLSPSKFile=/var/zabbix/agentd.psk


Второй способ шифрования подключения использование сертификатов. Заметим, что для pre-shared key (PSK) и сертификатов, закрытый ключ хранится на файловой системе в открытом виде.
Подробная информация доступна в документации Zabbix.

Zabbix-сервер <-> Zabbix-агент и Zabbix-прокси <-> Zabbix-агент


Мы не будем повторяться, настройка этих соединений аналогична настройке соединения сервера с прокси: для исходящих соединений доступен один вариант, для входящих один или несколько.



Названия переменных для настройки шифрования на стороне агента полностью аналогичны переменным в конфигурации прокси.

Zabbix-прокси <-> БД Zabbix-прокси


Подход к настройке аналогичен настройке шифрованного соединения между Zabbix-сервером и БД. Названия переменных такие же, указываются в конфигурационном файле Zabbix-прокси.

Zabbix sender -> Zabbix-прокси и Zabbix-агент -> Zabbix get


Шифрование соединения с утилитами Zabbix sender и Zabbix get выполняется при помощи специальных параметров при вызове соответствующих утилит.

zabbix_sender -z 127.0.0.1 -s zabbix02 -k Encrypt -o 18 --tls-connect psk --tls-psk-identity test_zabbix --tls-psk-file /etc/zabbix/keys/agent.psk

zabbix_get -s 127.0.0.1 -k agent.version \
--tls-connect psk --tls-psk-identity test_zabbix --tls-psk-file /etc/zabbix/keys/agent.psk


Авторегистрация с шифрованием


Шифрование также поддерживается и для процесса авторегистрации.



После авторегистрации нового узла, настройки соединения с ним будут автоматически настроены на использование шифрования PSK.

Хранение чувствительной информации в Vault


Приятное нововведение, которое появилось в версии Zabbix 5.2 поддержка хранилища Vault. Его можно использовать как для хранения учетных данных для доступа к БД так и для значений макросов. Так значения макросов выглядят в Vault:



А так на них можно сослаться в интерфейсе Zabbix:



Хранение значений макросов очень сильно упрощает управление учетными данными для разных шаблонов, позволяет легко отзывать учетные данные и вести аудит. Разумеется, из Vault можно брать значения любых макросов и это добавляет ещё одну степень свободы при автоматизации мониторинга в Zabbix.

Заключение


В статье мы рассказали о возможностях шифрования в Zabbix. Перед решением об использовании шифрованных подключений, важно понимать, что это снижает производительность системы мониторинга и сильнее утилизирует аппаратное обеспечение. Без понятной причины шифрование использовать не стоит.

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

А ещё можно почитать:

Добавляем CMDB и географическую карту к Zabbix

Мониторинг принтеров дело благородное

Структурированная система мониторинга на бесплатных решениях

Elastic под замком: включаем опции безопасности кластера Elasticsearch для доступа изнутри и снаружи

Для обработки событий от Zabbix, Prometheus, Elastic и других систем рекомендуем использовать Amixr (презентация по запросу).
Подробнее..

Основные идеи методов шифрования MIMO-OFDM систем на физическом уровне

02.12.2020 18:09:40 | Автор: admin

Я попытался раскрыть тему простым языком. Мне кажется, чтобы понять этот материал особых знаний не требуется, кроме умения читать тексты на русском и небольшого знания математики. Возможно, где-то я упустил важные детали или рассказал слишком очевидные вещи, но это все ради общедоступности. Не судите строго. Удачного чтения.

Почему это так важно?

Кажется очевидным, что пользоваться беспроводной связью значительно удобнее, чем сидеть на проводе (если вы так не считаете, то просто поверьте мне). Следовательно, требуется быстрый и надежный канал беспроводной связи. Вот тут как раз приходит на помощь OFDM сигнал (позже объясню, что это такое), который использует одновременно несколько поднесущих. А теперь мы еще модернизируем нашу схему установив на приемнике и на передатчике не одну антенну, а несколько вот мы и получили MIMO систему.

Шифрование на физическом уровне крайне выгодно, так как оно позволяет нам установить безопасное и надежное соединение без предположений о вычислительной мощности подслушивающих устройств. Такие схемы шифрования используют свойство случайности беспроводного канала, что усиливает безопасность.

Стартуем

А теперь начнем. Для начала расскажу чуть более подробно про OFDM-сигналы и MIMO и massive-MIMO системы, так как в дальнейшем понимание этих деталей не будет лишним.

Что такое MIMO и massive-MIMO и с чем их едят?

MIMO (Multiple Input Multiple Output) это способ кодирования сигнала, при котором и прием и передача сигнала происходят посредством нескольких антенн. Различают и другие системы:

  • SISO - Single Input Single Output

  • SIMO - Single Input Multiple Output

  • MISO - Multiple Input Single Output

  • MIMO - Multiple Input Multiple Output

Очевидно, что SIMO самая странная схема реализации общения, так как в этом случае базовая станция состоит из одной антенны, но зато на приемниках стоят много антенн. Представьте, что сотовый оператор ставит себе одну станцию за 1000 руб, а в каждый смартфон ставят по 5000 руб. Очевидно, что такая схема не прижилась в трех измерениях из-за экономической нецелесообразности. Реализации же других схем активно применяются, а MIMO системы в тот момент, когда вы читаете эту статью, совершенно точно собирают на каком-нибудь заводе в Китае и совершенствуют в какой-нибудь лаборатории.

MIMO использует физическое явление, называемое многолучевым распространением. Его эффект заключается в том, что сигналы поступают на приемное устройство с разными задержками и под разными углами. Это позволяет снизить требования к каналу передачи данных (среде распространения). Например, вы можете поставить у себя дома больше устройств, создающих помехи, и при этом вы не ухудшите качество сигнала. Также MIMO увеличивает радиус действия, улучшает пропускную способность беспроводной сети и скорость передачи данных без увеличения диапазона частот.

Более формально можно описать это добавлением нового ресурса:

  • Время (time diversity) сигнал может передаваться на протяжении фиксированного отрезка времени.

  • Частота (frequency diversity) невозможно использовать частоты, вне выданного вам диапазона.

  • Пространство (spatial diversity) одинаковые сигналы могут быть переданы по разным путям (различными антеннами) и, следовательно, на приемнике возможна более точная оценка сигнала с использованием наиболее правдоподобных копий.

Пусть Y принятый сигнал, H матрица канала, X отправленный сигнал, N шумы в канале(AWGN-аддитивный белый гауссовский шум).Тогда принятый сигнал представим в виде:

Y = HX + N

Один из возможных методов решения минимизация среднеквадратичной ошибки дает аналитическое решение:

X^* =(H^TH-\sigma^2I)^{-1}H^TY

Кстати, на практике иногда не так уж и просто найти обратную матрицу.

Massive-MIMO это схема, при которой количество антенн на базовой станции много больше их числа на мобильной. На базовой станции ставят 128, 256 антенн, а на приемнике 2-3 штуки. MIMO активно применяется в WiFi, LTE. Massive-MIMO будет основой для построения сетей 5G и, судя по темпам развития, и 6G.

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

Заправим наше MIMO-system блюдо OFDM модуляцией.

OFDM (orthogonal frequency-division multiplexing мультиплексирование с ортогональным частотным разделением каналов) схема модуляции, в которой предоставленный частотный диапазон разбивается на несколько субканалов, в каждом из которых используется своя поднесущая. При этом исходный плотный поток данных разбивается на несколько разреженных субпотоков и каждый передается независимо на своей частоте.

Из-за особенностей OFDM-модуляции возникают два типа помех: межсимвольные (ISI inter-symbol interference) и межнесущие (ICI inter-carrier interference).

ISI

В результате многолучевого распространения мы можем получить ситуацию, когда задержанная версия первого символа накладывается на второй символ, приводя к искажениям. Для того, чтобы избежать такой проблемы в каждый символ добавляется защитный временной интервал (guard interval).

ICI

Доплеровский сдвиг приводит к тому, что каждая частота сдвигается на некоторое значение, при этом расстояние между поднесущими также меняется. Это вызывает нарушение требования ортогональности точное равенство расстояния между поднесущими обратному периоду символа. Эта проблема решается добавлением циклического префикса(CP insertion) формально это циклическое повторение сигнала, длина которого, как и в случае ISI, рассчитывается из наибольших возможных помех в канале.

Преимущества OFDM:

  • Высокая спектральная эффективность

  • Возможность работы в зашумленных каналах (если одна поднесущая не передает сигнал (помехи в канале в узком диапазоне), то можно переложить эту работу на оставшиеся)

  • Высокая адаптивность (благодаря независимости поднесущих возможно использование различных методов модуляции и их автоматическая перенастройка в зависимости от стабильности канала)

Недостатки OFDM:

  • Схема модуляции чувствительна к эффекту Доплера, из-за чего невозможно использование при быстром передвижении

  • Необходимость точной синхронизации

  • Высокое энергопотребление

Все, теперь переходим к защите информации. Дальше будет чуть сложнее, но не отчаивайтесь.

Три кита защиты информации

Информационная безопасность в классической модели основывается на трех принципах: конфиденциальность, целостность и доступность (CIA triangle - Confidentiality, Integrity, Availability). Рассмотрим каждый из них.

Конфиденциальность.

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

  • Разделение пользователей и данных по категориям в соответствии с потенциальными угрозами при потере информации.

  • Двухфакторная аутентификация для получения доступа к конфиденциальным данных наиболее популярная практика. Также применяются другие методы, например, проверка биометрии.

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

Целостность.

Этот принцип гарантирует тот факт, что данные не были изменены во время передачи. На этом этапе возможны: применение разрешения на доступ к конфиденциальной информации, ведение системы контроля версий, использования контрольным сумм для обнаружения изменений, не вызванных вмешательством человека.

Доступность.

Этот принцип лежит в основе надежного и непрерывного доступа правильных лиц к конфиденциальной информации. Для обеспечения необходимого уровня защиты на данном уровне система должна быть избыточна и отказоустойчива, должна быть приспособлена к действиям в сложных условиях, в том числе при отказах целых блоков систем. Необходимо проведение стресс тестов на предмет возможности работы в условиях DOS (Denial of Service) или DDOS (Distributed Denial of Service) атак. Принцип доступности нередко называют основным в модели информационной безопасности.

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

В дальнейшем я предлагаю рассмотреть методы шифрования, касающиеся принципов конфиденциальности и целостности. Доступность в данной статье мы не будем рассматривать.

Аутентификация пользователя

На данном уровне существуют два типа атак: Fake client attack (FCA) и Fake access point (AP) attack.

Fake client attack. После получения пробного кадра третье лицо отправляет на сервер поддельную информацию о канале (CSI Channel State Information). Ниже представлено решение проблемы.

Fake access point attack. В этом случае злоумышленник предоставляет клиенту поддельный пробный кадр, из-за которого тот отправляет на сервер неверный ответ. Решение опять же ниже.

Существуют и другие схемы шифрования на физическом уровне. Грубо я выделю следующую классификацию всех существующих алгоритмов.

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

Для двух следующих алгоритмов выдвину предположения:

  • Алиса общается с Бобом и проверяет гипотезу H0 = "сообщение пришло от Боба" против H1 = "сообщение пришло не от Боба"

  • Канал меняется во времени, матрица канала меняется непрерывно

  • Матрицу канала можно разбить на вектора, из которых можно составить авторегрессионную схему.

Алгоритм AKBA(asymmetric-key based authentication):

  • На первом шаге Алиса передает пилоты,а Боб оценивает канал.

h_n(t) = h_n(t1) + \sqrt{1-^2}z_n(t)

- коэффициент корреляции, z(t) - независимые одинаково распределённые c.в. из комплексного нормального распределения.

  • Боб квантует мнимую и действительную части оценки канала при помощи определенного квантователя и уровня квантования, извлекает из них битовую последовательность b.

  • Боб применяет известную всем пользователям функцию хэширования и сжатия для получения более короткого ключа из битовой последовательности b, создает пару открытый-закрытый ключ (K1, K2)

  • На втором шаге Боб передает всем пользователям открытый ключ K1, и кодирует данные при помощи созданного закрытого ключа K2, благодаря чему Алиса может его идентифицировать.

Алгоритм SKBA(symmetric-key based authentication):

  • На первом шаге Алиса передает список пилотных символов Бобу, Боб оценивает канал.

h_n(t) = h_n(t1) + \sqrt{1-^2}z_n(t)
  • На втором шаге происходит обратное общение. Боб передает Алисе список пилотных символов, а Алиса оценивает канал.

  • В словаре кодовых слов Алиса находит ближайшее к каждой из 2N оценок канала

c^* = argmin_{cC}||h_A(2) - c||^2
  • и отправляет Бобу вектор ошибок.

e = h_A(2) - c^*
  • Боб вычисляет ошибку между принятым вектором и своей оценкой канала

h_B = h_B(1) - e
  • и находит ближайшее кодовое слово из словаря ко всему вектору.

c^* = argmin_{cC}||h_B c||^2
  • Боб и Алиса применяют хэш-функцию к индексу последовательностей для извлечения битов, которые будут использованы как ключ аутентификации.

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

Схема шифрования на основе сравнения пилотных символов принимает решение о корректности идентификации клиента на основе сходства пилотных символов в различных сообщениях.

Алгоритм PLA(Physical Layer Authentication)

  • На первом шаге Боб передает список пилотных символов Алисе, которая оценивает канал(так же как в прежних схемах).

  • Во всех последующих передачах Алиса сравнивает оценки каналов на шагах t > 1 с первой оценкой, расстояние вычисляется по формуле:

(t) = \frac{1}{N {\gamma_{A}}^2(t)} \sum_{n=1}^{N} {|h_n(t)-^{t-1}h_n(1)|^2}
  • Алиса принимает решение о том является ли Боб на самом деле Бобом на основе сревнения расстояния с пороговой функцией:

(t) < (t)

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

Можно видеть, что каждая их схем опирается на свойство случайности канала связи, однако теоретически злоумышленник может оценить ваш канал связи и тогда ваша схема аутентификации не будет работать.

Вывод: данные алгоритмы шифрования являются отличным дополнением к высокоуровневым, они просто реализуемы и вычислительно просты, их можно использовать для повышения уровня защиты.

Конфиденциальность данных

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

Скремблер

Ниже приведена классическая схема реализации этого типа шифрования. Этот прием довольно часто применяется в области защиты информации и прежде всего для повышения защищенности от перехватов и вредоносных атак в системах связи, где передача данных происходит по открытым каналам.

Сначала поток данных преобразуется в несколько параллельных потоков. После этого эти потоки поступают на вход скремблера, матрица которого может быть построена различными способами (один из возможных - на основе местоположения мобильной станции). Затем данные передаются через канал посредством нескольких антенн на стороне приемника и на стороне передатчика. Сигнал на приемнике представим в виде:

Y=HSX+N

N - AWGN(аддитивный белый гауссовский шум), H - матрица канала, X - входные данные

Приемное устройство проводит обратные операции:

X^* = S^{-1}H^{-1}Y = X+S^{-1}H^{-1}N

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

Оценка канала

Я предлагаю к рассмотрению схему шифрования, рассчитанную на ограниченное число M одновременных пользователей.

На базовой станции случайным образом генерируются M ортогональных векторов w размерности число антенн на базовой станции. Затем они нормализуются и каждому из M пользователей рассылаются прекодированные известные символы по формуле

x = \sum_{i=1}^{M}{w_ms_i}

Пользователи вычисляют отношение уровня сигнала к уровню шума(SINR - signal-to-interference-plus-noise ratio) по формуле

\gamma_{k,m} = \frac{P|h_kw_m|^2}{\sum_{i=1, i \neq m}^{M}{P|h_kw_i|^2}+\sigma^2}

P - мощность передачи каждого луча

Среди всех лучей каждый из пользователей выбирает луч:

w_{m_k} = arg max_{1mM} {_{k,m}}

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

Одним из основных минусов данного метода является необходимость дополнительного шифрования во избежание синхронизации злоумышленника с реальными пользователями.

Искусственные помехи и затухание

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

Схема с искусственными помехами(AN - Artificial Noise)

Алиса искажает передаваемые символы посредством добавления искусственных шумов. Шумы генерируются так, чтобы Боб смог их отбросить, а потому они не ухудшают демодулирование сигнала.

Передаваемый символ на l-й поднесущей:

x^l_{AN} = ^l_{ZF}u^l + Z^lv^l^l_{ZF} = (H^l)^{+}

а Z получается из SVD разложения матрицы канала:

H^l = U^l ^l [V^l Z^l ]^H

На законном приемнике имеем:

y^l = H^l x^l + n^l = u^l + H^l n^l

На незаконном приемнике:

y^l_{AN} = G^l x^l_{AN} + n^l = G^l ^l_{ZF}u^l + G^l Z^l v^l + n^l

Схема с затуханием(AFF - Artificial Fast Fading)

Алиса искусственно домножает исходный сигнал на коэффициенты затухания в соответствии с матрицей канала. При прохождении через канал к Бобу сигнал приходит в исходной форме. До злоумышленника сигнал идет по другому каналу, значит искажется при передаче.

Передаваемый символ на l-й поднесущей:

x^l_{AFF} = ^l_{AFF}u^l^l_{AFF} = [^l_{rand} ^l_{cancel}]^T

Как видите, матрица состоит из двух частей: случайной и отменяющей, которая отвечает за удаления эффекта затухания при прохождении через легитимный канал.

^l_{cancel}=({H^l}_{cancel})^{-1}(I {H^l}_{rand}{^l}_{rand})

На законном приемнике имеем:

y^l_{AFF} = H^lx^l_{AFF} + n^l = u^l + n^l

На незаконном приемнике:

y^l_{AFF} = G^l x^l_{AFF} + n^l = G^l ^l_{AFF}u^l + n^l

Общая диаграмма направленности в сочетании с помехами

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

Рассмотрим процесс общения между кластерами. Сначала передающее устройство передает данные пользователям своего кластера, а в принимающем кластере пользователи передают принимающему устройству помехи. Затем передатчик и его соседи передают данные на приемное устройство, а в принимающем кластере соседи принимающего устройства передают те же самые помехи. В итоге, на приемнике имеется и шум, и зашумленный сигнал и остается лишь восстановить исходные данные.

Минусом такой схемы являются требования к синхронизации между большим количеством устройств, а также необходимость проверки легитимности пользователя при его подключении к кластеру.

Выводы

Мы рассмотрели некоторые из методов шифрования на физическом уровне. Снова обращаю ваше внимание на то, что не все из них могут гарантировать безопасную передачу данных. Однако за счет простоты реализации и малой вычислительной сложности могут быть внедрены в современные ЭВМ.

Список литературы:

[] - What is Information Security? The Basics of Information Security

[] - Comparison Between Asymmetric and Symmetric Channel-Based Authentication for MIMO Systems

[] - A Physical Layer Security Scheme Employing Imaginary Receiver for Multiuser MIMO-OFDM Systems

[] - High security orthogonal factorized channel scrambling scheme with location information embedded for MIMO-based VLC system

[] - Mode Selection in MU-MIMO Downlink Networks: A Physical-Layer Security Perspective

[] - Virtual MIMO-based cooperative beamforming and jamming scheme for the clustered wireless sensor network security

[] - Physical Layer Authentication over MIMO Fading Wiretap Channels

[] - Virtual MIMO-based cooperative beamforming and jamming scheme for the clustered wireless sensor network security

Подробнее..

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

14.01.2021 16:09:15 | Автор: admin
Как развеять предубеждения потенциальных пользователей относительно безопасности публичных облаков? На помощь приходит технология Intel Software Guard Extensions (Intel SGX). Рассказываем, как мы внедрили её в своём облаке и какие преимущества от нашего решения получила компания Aggregion.





Кратко об Intel SGX и его роли в облаке


Intel Software Guard Extensions (Intel SGX) набор инструкций ЦП, с помощью которых в адресном пространстве приложения создаются частные защищённые области (анклавы), где размещается код уровня пользователя. Технология обеспечивает конфиденциальность и целостность чувствительных данных. Путём изоляции в анклаве они получают дополнительную защиту как от несанкционированного внешнего доступа, в том числе со стороны провайдера облачных услуг, так и от внутренних угроз, включая атаки со стороны программного обеспечения привилегированного уровня.

Принципы работы. Для хранения кода и данных анклавов технология Intel SGX выделяет область памяти Processor Reserved Memory (PRM). ЦП защищает её от всех внешних обращений, в том числе от доступа со стороны ядра и гипервизора. В PRM содержится Enclave Page Cache (EPC), состоящий из блоков страниц объёмом 4 КиБ, при этом каждая страница должна принадлежать только одному анклаву, а их состояние фиксируется в Enclave Page Cache Metadata (EPCM) и контролируется ЦП.

Безопасность EPC обеспечивается за счёт Memory Encryption Engine (MEE), который генерирует ключи шифрования, хранящиеся в ЦП. Предполагается, что страницы могут быть расшифрованы только внутри физического ядра процессора.

Преимущества. Intel SGX позволяет повысить уровень доверия к публичному облаку со стороны организаций, использующих в своей работе чувствительные данные (пароли, ключи шифрования, идентификационные, биометрические, медицинские данные, а также информацию, относящуюся к интеллектуальной собственности). Речь идёт о представителях самых разных отраслей финансового сектора, медицины и здравоохранения, ритейла, геймдева, телекома, медиасферы.

Наш подход к внедрению Intel SGX


Чтобы в публичном облаке G-Core Labs появилась возможность выделять виртуальные машины с анклавами Intel SGX, нам пришлось пройти путь от компиляции патченного ядра KVM и QEMU до написания Python-скриптов в сервисах OpenStack Nova. Вычислительные узлы, которые планировалось использовать для выделения виртуальных машин повышенной безопасности, мы решили определить в отдельный агрегатор тип вычислительных ресурсов, требующий дополнительной настройки. На таких узлах было необходимо:

  • Включить поддержку Intel SGX на уровне BIOS.
  • Поставить патченные QEMU/KVM.

Изначально у нас не было понимания, как это должно работать и что в итоге мы должны прикрутить, чтобы получить ВМ нужной конфигурации. Разобраться с этим вопросом нам частично помогло руководство Intel для разработчиков. С его помощью мы узнали, как подготовить вычислительный узел для работы с SGX и какими дополнительными параметрами должен обладать конфигурационный XML-файл виртуальной машины. Здесь же мы нашли исчерпывающую информацию, как с помощью виртуализации KVM сделать гостевую машину с использованием Intel SGX. Чтобы убедиться, что мы смогли обеспечить поддержку данной технологии, мы использовали два способа:

  • Проверили секцию /dev/sgx/virt_epc в файле /proc/$PID/smaps:

    [root@compute-sgx ~]# grep -A22 epc /proc/$PID/smaps7f797affe000-7f797b7fe000 rw-s 00000000 00:97 57466526/dev/sgx/virt_epcSize:               8192 kBKernelPageSize:        4 kBMMUPageSize:           4 kBRss:                   0 kBPss:                   0 kBShared_Clean:          0 kBShared_Dirty:          0 kBPrivate_Clean:         0 kBPrivate_Dirty:         0 kBReferenced:            0 kBAnonymous:             0 kBLazyFree:              0 kBAnonHugePages:         0 kBShmemPmdMapped:        0 kBFilePmdMapped:         0 kBShared_Hugetlb:        0 kBPrivate_Hugetlb:       0 kBSwap:                  0 kBSwapPss:               0 kBLocked:                0 kBTHPeligible:0VmFlags: rd wr sh mr mw me ms pf io dc dd hg
    
  • И воспользовались данным shell-скриптом, предварительно поставив SGX-драйвер (все действия осуществлялись внутри ВМ):

    [root@sgx-vm ~]# cat check_sgx.sh#!/bin/bashMETRICS="sgx_nr_total_epc_pages \    sgx_nr_free_pages \    sgx_nr_low_pages \    sgx_nr_high_pages \    sgx_nr_marked_old \    sgx_nr_evicted \    sgx_nr_alloc_pages \    "MODPATH="/sys/module/isgx/parameters/"for metric in $METRICS ; do    echo "$metric= `cat $MODPATH/$metric`"done[root@sgx-vm ~]# curl -fsSL https://raw.githubusercontent.com/scontain/SH/master/install_sgx_driver.sh | bash -s - install -p metrics -p page0[root@sgx-vm ~]# ./check_sgx.shsgx_nr_total_epc_pages= 2048sgx_nr_free_pages= 2048sgx_nr_low_pages= 32sgx_nr_high_pages= 64sgx_nr_marked_old= 0sgx_nr_evicted= 0sgx_nr_alloc_pages= 0
    

    Стоит учитывать, что, если одна страница занимает 4 КиБ, то для 2048 страниц требуется 8 МиБ (2048 x 4 = 8192).

Трудности разработки и их преодоление


Отсутствие какой-либо технической документации по интеграции Intel SGX в OpenStack было нашей основной трудностью на момент внедрения. Поиск привел нас к статье проекта SecureCloud, где был представлен способ управления виртуальными машинами с анклавами SGX.

Найденная информация помогла понять, над чем именно нам предстоит работать. В результате мы сформировали следующие задачи:

  1. Добиться от сервиса OpenStack Nova генерации XML-файла с дополнительными параметрами для виртуальных машин с поддержкой Intel SGX.
  2. Написать фильтр планировщика OpenStack Nova с целью определения доступной памяти для анклавов на вычислительных узлах и осуществления некоторых других проверок.

Их выполнения было достаточно для интеграции Intel SGX в наше публичное облако.

Кроме того, мы дописали сбор статистики с учетом EPC:

# openstack usage showUsage from 2020-11-04 to 2020-12-03 on project a968da75bcab4943a7beb4009b8ccb4a:+---------------+--------------+| Field         | Value        |+---------------+--------------+| CPU Hours     | 47157.6      || Disk GB-Hours | 251328.19    || EPC MB-Hours  | 26880.02     || RAM MB-Hours  | 117222622.62 || Servers       | 23           |+---------------+--------------+


Безопасная среда для запуска контейнеризированных приложений



Научившись выделять виртуальные машины с поддержкой Intel SGX, мы использовали платформу SCONE компании Scontain, чтобы обеспечить возможность безопасного запуска контейнеризированных приложений в случае угроз со стороны привилегированного программного обеспечения. При использовании данного решения для прозрачной защиты файловых систем в средах Docker, Kubernetes и Rancher достаточно наличия процессора Intel с поддержкой SGX и драйвера Linux SGX.

Запуск каждого из контейнеров возможен лишь при наличии файла конфигурации, создаваемого клиентским расширением платформы SCONE. В нём содержатся ключи шифрования, аргументы приложения и переменные среды. Файлы, сетевой трафик и стандартные потоки ввода/вывода (stdin/stdout) прозрачно зашифрованы и недоступны даже для пользователей с правами root.
Платформа SCONE оснащена встроенной службой аттестации и конфигурации, проверяющей приложения на соответствие принятой политике безопасности. Она генерирует приватные ключи и сертификаты, которые должны быть доступны только в пределах анклава. Конфиденциальность и целостность данных в процессе их передачи обеспечиваются криптографическим протоколом TLS.

С помощью драйвера SGX для каждого анклава в виртуальном адресном пространстве резервируется до 64 ГБ памяти. Платформа SCONE поддерживает языки программирования C/C++/C#/Rust/Go/Python/Java. За счёт специального компилятора исходный код автоматически (без необходимости дополнительных модификаций) подготавливается к использованию совместно с Intel SGX.

Кейс Aggregion


Завершив все необходимые работы по интеграции Intel SGX, мы подключили к нашему публичному облаку платформу управления распределёнными данными компании Aggregion.

Она предназначена для реализации совместных маркетинговых проектов представителями различных отраслей финансовых и страховых услуг, государственного управления, телекоммуникаций, ритейла. Партнёры анализируют поведение потребителей, развивают таргетированное продвижение товаров и услуг, разрабатывают востребованные программы лояльности, обмениваясь и обрабатывая обезличенные массивы данных на платформе Aggregion. Поскольку утечка конфиденциальной информации крайне не желательна и грозит серьёзными репутационными рисками, компания уделяет особое внимание вопросам безопасности.

Софт Aggregion целиком ставится в контур поставщика данных, что подразумевает наличие в его распоряжении инфраструктуры с поддержкой Intel SGX. Теперь клиенты компании могут рассматривать подключение к нашему публичному облаку в качестве альтернативы аренде или покупке физических серверов.

Принципы безопасной работы на платформе Aggregion. В контуре каждого поставщика чувствительные данные изолируются в анклавы Intel SGX, которые фактически представляют собой чёрные ящики: что происходит внутри, недоступно никому, в том числе и провайдеру облачной инфраструктуры. Проверка первоначального состояния анклава и возможности его использования для хранения конфиденциальной информации осуществляется за счёт удалённой аттестации, когда MrEnclave определяет хеш-значение.

Потенциальная польза для клиентов. Комбинирование баз данных нескольких поставщиков позволяет повысить эффективность совместных рекламных кампаний. При выделении целевой аудитории по заданным параметрам мэтчинг (сопоставление) сегментов выполняется непосредственно внутри контейнеров с поддержкой анклавов Intel SGX. За пределы выводится только конечный результат: например, численность пользователей, соответствующих выбранным атрибутам. Аналогичным образом оценивается эффективность проведенных кампаний: в анклавы выгружаются данные о рекламных показах и совершённых продажах для вычисления прироста покупок целевой группы относительно контрольной, который и выдаётся наружу для дальнейшего использования.



Выводы


Мы понимаем, что Intel SGX не является панацеей по защите данных и можно найти ряд статей, порицающих эту технологию, в том числе и на Хабре. Периодически появляются сообщения об атаках, способных извлечь конфиденциальные данные из анклавов: так, в 2018 году бреши в SGX пробили Meltdown и Spectre, в 2020 году SGAxe и CrossTalk. В свою очередь компания Intel устраняет выявленные уязвимости с помощью обновлений микрокода процессоров.

Почему же мы всё-таки решили внедрить данную технологию? Мы видим в применении Intel SGX возможность сократить потенциальную область кибератак за счёт создания дополнительного контура защиты облачной инфраструктуры G-Core Labs наряду с уже задействованными технологиями информационной безопасности и тем самым повысить доверие наших пользователей к хранению и обработке конфиденциальных данных. Надеемся, что в будущем нам ещё предстоит поделиться с вами успешными клиентскими кейсами, хотя и не берёмся утверждать, что наши статьи не будут основаны на историях обнаружения и устранения новых уязвимостей. А пока предлагаем вам поделиться своими методами по защите чувствительных данных в комментариях.
Подробнее..

Как мы добавляли CPU флаги Intel SGX в libvirt

22.04.2021 14:23:53 | Автор: admin
С момента публикации статьи о внедрении Intel SGX в наше публичное облако прошло несколько месяцев. За это время решение было существенно доработано. В основном улучшения касаются устранения мелких багов и доработок для нашего же удобства.



Есть, однако, один момент, о котором хотелось бы рассказать подробнее.



В предыдущей статье мы писали, что в рамках реализации поддержки SGX нужно было научить сервис Nova генерировать XML-файл с необходимыми настройками гостевого домена. Проблема эта оказалась сложной и интересной: за время работы по её решению нам пришлось на примере libvirt подробно разбираться, как в целом программы взаимодействуют с наборами инструкций в процессорах x86. Подробных и самое главное понятно написанных материалов на эту тему очень и очень немного. Надеемся, что наш опыт будет полезен всем, кто занимается виртуализацией. Впрочем, обо всём по порядку.

Первые попытки


Ещё раз повторим формулировку задачи: нам требовалось передать параметры поддержки SGX в конфигурационный XML-файл виртуальной машины. Когда мы только начинали эту задачу решать, в OpenStack и libvirt поддержки SGX не было, соответственно, передать их в XML виртуальной машины нативно было невозможно.

Сначала мы попытались решить эту проблему путем добавления блока Qemu command-line в скрипт подключение к гипервизору через libvirt, как это описано в руководстве Intel для разработчиков:

<qemu:commandline>     <qemu:arg value='-cpu'/>     <qemu:arg value='host,+sgx,+sgxlc'/>     <qemu:arg value='-object'/>     <qemu:arg value='memory-backend-epc,id=mem1,size=''' + epc + '''M,prealloc'/>     <qemu:arg value='-sgx-epc'/>     <qemu:arg value='id=epc1,memdev=mem1'/></qemu:commandline>

Но после этого у виртуальной машины добавилась вторая процессорная опция:

[root@compute-sgx ~] cat /proc/$PID/cmdline |xargs -0 printf "%s\n" |awk '/cpu/ { getline x; print $0 RS x; }'-cpuSkylake-Client-IBRS-cpuhost,+sgx,+sgxlc

Первая опция задавалась штатно, а вторая была непосредственно нами добавлена в блоке Qemu command-line. Это приводило к неудобству при выборе модели эмуляции процессора: какую бы из моделей процессоров мы ни подставляли в cpu_model в конфигурационном файле вычислительного узла Nova, в виртуальной машине мы видели отображение хостового процессора.

Как решить эту проблему?

В поисках ответа мы сначала пробовали экспериментировать со строкой <qemu:arg value='host,+sgx,+sgxlc'/> и пытаться передать в неё модель процессора, но это не отменяло дублирование этой опции после запуска ВМ. Тогда было решено задействовать libvirt для присвоения флагов CPU и управлять ими через конфигурационный файл Novы вычислительного узла с помощью параметра cpu_model_extra_flags.

Задача оказалась сложнее, чем мы предполагали: нам потребовалось изучить инструкцию Intel IA-32 CPUID, а также найти информацию о нужных регистрах и битах в документации Intel об SGX.

Дальнейший поиск: углубляемся в libvirt


В документации для разработчиков сервиса Nova указано, что маппинг CPU флагов должен поддерживаться самим libvirtом.

Мы нашли файл, в котором описываются все флаги CPU это x86_features.xml (актуален с версии libvirt 4.7.0). Ознакомившись с этим файлом, предположили (как выяснилось потом, ошибочно), что нам нужно лишь получить hex-адреса необходимых регистров в 7-м листе с помощью утилиты cpuid. Из документации Intel мы узнали, в каких регистрах вызываются нужные нам инструкции: sgx находится в EBX регистре, а sgxlc в ECX.

[root@compute-sgx ~] cpuid -l 7 -1 |grep SGX      SGX: Software Guard Extensions supported = true      SGX_LC: SGX launch config supported      = true[root@compute-sgx ~] cpuid -l 7 -1 -rCPU:   0x00000007 0x00: eax=0x00000000 ebx=0x029c6fbf ecx=0x40000000 edx=0xbc000600

После добавления флагов sgx и sgxlc со значениями, полученными с помощью утилиты cpuid, мы получили следующее сообщение об ошибке:

error : x86Compute:1952 : out of memory

Сообщение, прямо говоря, не очень информативное. Чтобы хоть как-то понять, в чём проблема, мы завели issue в gitlabe libvirta. Разработчики libvirta заметили, что выводится неверная ошибка и исправили ее, указав на то, что libvirt не может найти нужную инструкцию, которую мы вызываем и предположили, где мы можем ошибаться. Но понять, что именно нам нужно было указывать, чтобы ошибки не было, нам так и не удалось.

Пришлось зарыться в источники и изучать, это заняло много времени. Разобраться удалось лишь после изучения кода в модифицированном Qemu от Intel:

    [FEAT_7_0_EBX] = {        .type = CPUID_FEATURE_WORD,        .feat_names = {            "fsgsbase", "tsc-adjust", "sgx", "bmi1",            "hle", "avx2", NULL, "smep",            "bmi2", "erms", "invpcid", "rtm",            NULL, NULL, "mpx", NULL,            "avx512f", "avx512dq", "rdseed", "adx",            "smap", "avx512ifma", "pcommit", "clflushopt",            "clwb", "intel-pt", "avx512pf", "avx512er",            "avx512cd", "sha-ni", "avx512bw", "avx512vl",        },        .cpuid = {            .eax = 7,            .needs_ecx = true, .ecx = 0,            .reg = R_EBX,        },        .tcg_features = TCG_7_0_EBX_FEATURES,    },    [FEAT_7_0_ECX] = {        .type = CPUID_FEATURE_WORD,        .feat_names = {            NULL, "avx512vbmi", "umip", "pku",            NULL /* ospke */, "waitpkg", "avx512vbmi2", NULL,            "gfni", "vaes", "vpclmulqdq", "avx512vnni",            "avx512bitalg", NULL, "avx512-vpopcntdq", NULL,            "la57", NULL, NULL, NULL,            NULL, NULL, "rdpid", NULL,            NULL, "cldemote", NULL, "movdiri",            "movdir64b", NULL, "sgxlc", NULL,        },        .cpuid = {            .eax = 7,            .needs_ecx = true, .ecx = 0,            .reg = R_ECX,        },

Из приведенного листинга видно, что в блоках .feat_names побитово (от 0 до 31) перечисляются инструкции из EBX/ECX-регистров 7-го листа; если инструкция не поддерживается Qemu или этот бит зарезервирован, то он заполняется значением NULL. Благодаря этому примеру мы сделали такое предположение: возможно, нужно указывать не hex-адрес необходимого регистра в libvirt, а конкретно бит этой инструкции. Проще это понять, ознакомившись с таблицей из Википедии. Слева указан бит и три регистра. Находим в ней нашу инструкцию sgx. В таблице она указана под вторым битом в регистре EBX:



Далее сверяем расположение этой инструкции в коде Qemu. Как мы видим, она указана третьей в списке feat_names, но это потому, что нумерация битов начинается от 0:

    [FEAT_7_0_EBX] = {        .type = CPUID_FEATURE_WORD,        .feat_names = {            "fsgsbase", "tsc-adjust", "sgx", "bmi1",

Можно посмотреть другие инструкции в этой таблице и убедиться при подсчете от 0, что они находятся под своим битом в приведенном листинге. Например: fsgsbase идет под 0 битом регистра EBX, и он указан в этом списке первым.

В документации Intel мы нашли этому подтверждение и убедились, что необходимый набор инструкций можно вызвать с использованием cpuid, передавая правильный бит при обращении к регистру нужного листа, а в некоторых случаях подлиста.

Мы стали более подробно разбираться в архитектуре 32-битных процессоров и увидели, что в таких процессорах имеются листы, которые содержат основные 4 регистра: EAX, EBX, ECX, EDX. Каждый из этих регистров содержит по 32 бита, отведенных под определенный набор инструкций CPU. Бит является степенью двойки и чаще всего может передаваться программе в hex-формате, как это сделано в libvirt.

Для лучшего понимания, рассмотрим еще пример c флагом вложенной виртуализации VMX из файла x86_features.xml, используемый libvirtом:

<feature name= 'vmx'>
<cpuid eax_in='0x01' ecx='0x00000020'/> # 25 = 3210 = 2016
</feature>

Обращение к этой инструкции осуществляется в 1-м листе к регистру ECX под 5 битом и убедиться в этом можно посмотрев таблицу Feature Information в Википедии.

Разобравшись с этим и сформировав понимание, как в итоге добавляются флаги в libvirt, мы решили добавить и другие флаги SGX (помимо основных: sgx и sgxlc), которые имелись в модифицированном Qemu:

[root@compute-sgx ~] /usr/libexec/qemu-kvm -cpu help |xargs printf '%s\n' |grep sgxsgxsgx-debugsgx-exinfosgx-ksssgx-mode64sgx-provisionkeysgx-tokenkeysgx1sgx2sgxlc

Некоторые из этих флагов являются уже не инструкциями, а атрибутами структуры управления данными анклавов (SECS); подробнее об этом можно прочитать в документации Intel. В ней мы нашли, что необходимый нам набор атрибутов SGX находится в листе 0x12 в подлисте 1:

[root@compute-sgx ~] cpuid -l 0x12 -s 1 -1CPU:   SGX attributes (0x12/1):      ECREATE SECS.ATTRIBUTES valid bit mask = 0x000000000000001f0000000000000036



На скриншоте таблицы 38-3 можно найти необходимые нам биты атрибутов, которые мы укажем позже в качестве флагов в libvirt: sgx-debug, sgx-mode64, sgx-provisionkey, sgx-tokenkey. Они находятся под битами 1, 2, 4 и 5.

Так же мы поняли из ответа в нашем issue: libvirt имеет макрос проверки флагов на предмет их поддержки непосредственно процессором вычислительного узла. Это означает то, что недостаточно указать в документе x86_features.xml необходимые листы, биты и регистры, если сам libvirt не поддерживает лист набора инструкций. Но к нашему счастью выяснилось, что в коде libvirta имеется возможность работы с этим листом:

/* Leaf 0x12: SGX capability enumeration * * Sub leaves 0 and 1 is supported if ebx[2] from leaf 0x7 (SGX) is set. * Sub leaves n >= 2 are valid as long as eax[3:0] != 0. */static intcpuidSetLeaf12(virCPUDataPtr data,               virCPUx86DataItemPtr subLeaf0){    virCPUx86DataItem item = CPUID(.eax_in = 0x7);    virCPUx86CPUIDPtr cpuid = &item.data.cpuid;    virCPUx86DataItemPtr leaf7;    if (!(leaf7 = virCPUx86DataGet(&data->data.x86, &item)) ||        !(leaf7->data.cpuid.ebx & (1 << 2)))        return 0;    if (virCPUx86DataAdd(data, subLeaf0) < 0)        return -1;    cpuid->eax_in = 0x12;    cpuid->ecx_in = 1;    cpuidCall(cpuid);    if (virCPUx86DataAdd(data, &item) < 0)        return -1;    cpuid->ecx_in = 2;    cpuidCall(cpuid);    while (cpuid->eax & 0xf) {        if (virCPUx86DataAdd(data, &item) < 0)            return -1;        cpuid->ecx_in++;        cpuidCall(cpuid);    }    return 0;}

Из этого листинга видно, что при обращении к 2-му биту EBX регистра 7-го листа (т.е. к инструкции SGX), libvirt может задействовать лист 0x12 для проверки имеющихся атрибутов в подлистах 0, 1 и 2.

Заключение


После проделанного исследования мы поняли, как правильно дополнить файл x86_features.xml. Мы перевели необходимые биты в hex-формат и вот что у нас получилось:

  <!-- SGX features -->  <feature name='sgx'>    <cpuid eax_in='0x07' ecx_in='0x00' ebx='0x00000004'/>  </feature>  <feature name='sgxlc'>    <cpuid eax_in='0x07' ecx_in='0x00' ecx='0x40000000'/>  </feature>  <feature name='sgx1'>    <cpuid eax_in='0x12' ecx_in='0x00' eax='0x00000001'/>  </feature>  <feature name='sgx-debug'>    <cpuid eax_in='0x12' ecx_in='0x01' eax='0x00000002'/>  </feature>  <feature name='sgx-mode64'>    <cpuid eax_in='0x12' ecx_in='0x01' eax='0x00000004'/>  </feature>  <feature name='sgx-provisionkey'>    <cpuid eax_in='0x12' ecx_in='0x01' eax='0x00000010'/>  </feature>  <feature name='sgx-tokenkey'>    <cpuid eax_in='0x12' ecx_in='0x01' eax='0x00000020'/>  </feature>

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

[root@compute-sgx nova] grep cpu_mode nova.confcpu_mode = customcpu_model = Skylake-Client-IBRScpu_model_extra_flags = sgx,sgxlc,sgx1,sgx-provisionkey,sgx-tokenkey,sgx-debug,sgx-mode64[root@compute-sgx ~] cat /proc/$PID/cmdline |xargs -0 printf "%s\n" |awk '/cpu/ { getline x; print $0 RS x; }'-cpuSkylake-Client-IBRS,sgx=on,sgx-mode64=on,sgx-provisionkey=on,sgx-tokenkey=on,sgx1=on,sgxlc=on

Проделав сложный путь, мы научились добавлять в libvirt поддержку флагов SGX. Это нам помогло решить проблему дублирования процессорных опций в XML-файле виртуальной машины. Полученный опыт мы будем использовать и в дальнейшей работе: если в процессорах Intel или AMD появится новый набор инструкций, мы сможем их аналогичным образом добавить в libvirt. Знакомство с инструкцией CPUID так же будет нам полезно при написании своих собственных решений.

Если у вас есть вопросы добро пожаловать в комментарии, постараемся ответить. А если у вас есть, что дополнить тем более пишите, будем очень признательны.
Подробнее..

Категории

Последние комментарии

  • Имя: Макс
    24.08.2022 | 11:28
    Я разраб в IT компании, работаю на арбитражную команду. Мы работаем с приламы и сайтами, при работе замечаются постоянные баны и лаги. Пацаны посоветовали сервис по анализу исходного кода,https://app Подробнее..
  • Имя: 9055410337
    20.08.2022 | 17:41
    поможем пишите в телеграм Подробнее..
  • Имя: sabbat
    17.08.2022 | 20:42
    Охренеть.. это просто шикарная статья, феноменально круто. Большое спасибо за разбор! Надеюсь как-нибудь с тобой связаться для обсуждений чего-либо) Подробнее..
  • Имя: Мария
    09.08.2022 | 14:44
    Добрый день. Если обладаете такой информацией, то подскажите, пожалуйста, где можно найти много-много материала по Yggdrasil и его уязвимостях для написания диплома? Благодарю. Подробнее..
© 2006-2024, personeltest.ru