Oxide описала иерархию ключей для защиты серверных стоек
Компания Oxide Computer, которая делает серверные стойки для локальных дата-центров с открытой прошивкой, опубликовала внутренний технический документ RFD 301, предложение по иерархии ключей шифрования для защиты данных внутри стойки.
В основе схемы, Trust Quorum («кворум доверия»): общий «секрет стойки» разбивается по схеме разделения секрета Шамира на N долей и распределяется между агентами на каждом узле (sled) стойки. Чтобы восстановить секрет, нужно собрать K долей из N; если долей меньше K, из них нельзя извлечь вообще никакой информации о секрете. Сейчас доли хранятся в незашифрованном виде на M.2-накопителях каждого узла, поэтому, чтобы восстановить секрет, атакующему нужно физически украсть минимум K таких дисков, авторы называют это невыполнимым без значительного времени и заметного вмешательства при физическом доступе к оборудованию. В будущем планируется «запечатать» доли с помощью корня доверия (Root of Trust) так, чтобы они расшифровывались только при загрузке узла, тогда атакующему придётся красть уже K целых узлов и суметь их загрузить, а вес такого количества оборудования делает кражу непосильной для случайного злоумышленника.
Из секрета стойки выводятся или оборачиваются остальные ключи: отдельный ключ ZFS-шифрования на каждый накопитель U.2 (чтобы компрометация одного диска не затрагивала остальные) и корневые сертификаты для внутренних сервисов стойки. Разработчики сознательно отказались от аппаратного полнодискового шифрования, из-за недоверия к реализациям, сложности управления ключами и зависимости от нескольких производителей, и вместо этого шифруют почти весь ZFS-пул, кроме отдельного набора данных Crucible (их собственной подсистемы хранения), у которого уже есть своё шифрование. Ротацию ключей ZFS выполняет сам модуль ядра, без необходимости заново шифровать весь набор данных при смене ключа.
Чтобы ограничить ущерб от возможной утечки во времени, при каждой реконфигурации кворума доверия, добавлении или удалении узла, либо иной ротации долей ключа, всегда генерируется новый секрет стойки. Это значит, что даже если старый секрет был скомпрометирован, после удаления скомпрометированного узла новые данные всё равно останутся защищены.
Документ отдельно формулирует цели проектирования (по возможности выводить ключи, а не оборачивать их, чтобы не хранить лишние обёрнутые ключи; допускать ротацию секрета стойки для смягчения компрометации; использовать уникальный ключ на каждый диск; не давать новым «пустым» узлам доступ к старым данным, которыми с ними не поделились) и жёсткие ограничения (при ротации секрета нужно одновременно знать старый и новый ключ-обёртку ZFS; узлы могут узнавать о реконфигурации не одновременно; фиксация новой конфигурации может произойти уже после нескольких «ложных стартов», когда новая конфигурация разослана части узлов, но не подтверждена). Из-за этого, при используемом в другом документе (RFD 238) протоколе двухфазной фиксации, новые доли ключа рассылаются ещё на этапе подготовительного сообщения («prepare»), до подтверждения. Извлечённый текст документа обрывается на середине предложения, поэтому дальнейшее обсуждение распределения долей при реконфигурации в пересказ не попало.
Ключевые факты
- Oxide Computer опубликовала RFD 301, документ с иерархией ключей шифрования для защиты данных внутри серверной стойки
- Секрет стойки разбит по схеме Шамира на N долей между узлами (sled); для восстановления нужно собрать K долей, меньше, ничего не раскрывает
- Сейчас доли хранятся незашифрованными на M.2-дисках узлов, нужно украсть минимум K дисков; в планах, «запечатать» их через Root of Trust, тогда придётся красть уже K целых узлов
- Из секрета стойки выводятся отдельные ключи ZFS-шифрования на каждый диск U.2 и внутренние корневые сертификаты, компрометация одного диска не задевает остальные
- При каждой реконфигурации состава узлов генерируется новый секрет стойки, чтобы прошлые утечки не угрожали новым данным
Почему это важно
Это редкий случай, когда компания, производящая реальное серверное оборудование, публично показывает не маркетинговый анонс, а инженерный процесс принятия решений: как именно защищаются секреты внутри физической стойки от атакующего с доступом к железу, а не только к сети. Документ разбирает конкретную модель угрозы, кражу дисков или целых узлов, и показывает, как криптографическая схема (разделение секрета, вывод и обёртывание ключей) переводится в требования к железу и прошивке.
Кому это важно
Инженерам инфраструктуры и безопасности, которые проектируют локальное (on-prem) или граничное (edge) оборудование и ищут альтернативу аппаратным HSM и полнодисковому шифрованию; архитекторам распределённых систем, которым интересна практика разделения секрета по схеме Шамира и построения иерархии ключей поверх ZFS-шифрования.
Как это применить
Из документа можно позаимствовать сам паттерн: не хранить единый ключ шифрования диска, а генерировать по одному ключу на устройство хранения из общего секрета, который сам недоступен ни на одном отдельном узле; выбирать между выводом ключа (не нужно хранить производные ключи, но их смена каскадно меняет все нижестоящие) и обёртыванием ключа (ротация родительского ключа не требует пересчёта нижестоящих, но обёрнутый ключ нужно где-то хранить). Также показан приём распределения новых долей ключа на этапе подготовительного сообщения протокола двухфазной фиксации, до того, как новая конфигурация подтверждена.
Можно ли доверять
Источник, сам первичный технический документ (RFD) компании Oxide Computer, реально существующего производителя серверных стоек, а не пересказ третьей стороны. Обсуждение на Hacker News на момент публикации минимальное (1 комментарий), поэтому пересказ опирается на текст документа напрямую. Документ сам честно помечает нерешённые вопросы (например, нужны ли промежуточные сертификаты, пока не определено) и то, что описанное «запечатывание» долей ключа, это план на будущее, а не уже работающий механизм; извлечённый текст обрывается на середине фразы, и часть обсуждения распределения долей при реконфигурации в исходнике недоступна.
Риски и подводные камни
Пока функция «запечатывания» долей через Root of Trust не реализована, доли секрета стойки лежат на дисках узлов незашифрованными, защита держится на том, что физическую кражу K дисков трудно провести быстро и незаметно, а не на криптографии диска как таковой. Сама иерархия ключей, с деривацией, обёртыванием, ротацией секрета при каждой реконфигурации и двухфазной фиксацией, достаточно сложна, а сложность в криптографических системах, частый источник ошибок реализации. Часть вопросов (нужны ли промежуточные сертификаты) документ прямо оставляет открытыми.
«Доли ключа сейчас хранятся в незашифрованном виде на M.2-дисках каждого узла. Атакующему пришлось бы украсть минимум K таких дисков, чтобы восстановить секрет стойки, а это невыполнимо без значительного времени и заметного вмешательства при физическом доступе к оборудованию.»
— RFD 301, Oxide Computer