Secure Token и Bootstrap Token в macOS

Всем привет! Меня зовут Эрик, я инженер технической поддержки в Ринго. 

Если вы администрируете Mac в корпоративной среде, то рано или поздно сталкиваетесь с загадочными сущностями: Secure Token, Bootstrap Token, volume owner, OIK, KEK, VEK.

Проблема в том, что официальная документация Apple описывает их корректно, но сухо и редко объясняет, как всё это связано между собой на практике. В итоге админ узнаёт о Secure Token не из документации, а когда:

• пользователь не появляется на экране FileVault,

• MDM не может включить FileVault,

• обновление macOS требует «volume owner»,

• а Recovery внезапно никого не пускает менять настройки загрузки.

Постараемся разобраться поэтапно, что такое Secure Token, что лежит внутри, как он связан с Bootstrap Token и при чем тут MDM.

Статья подготовлена на основе документации Apple, включая Apple Platform Security, доклада Арека Дрейера на конференции MacSysAdmin и ряда дополнительных источников.

Часть 1. Secure Token

Что представляет собой Secure Token?

Если очень упрощенно, Secure Token – это как сейф-бокс (рис.1), внутри которого лежит нечто ценное, а пароль пользователя – это комбинация к замку. Только открыв сейф-бокс правильным паролем, можно достать содержимое.

Рис.1 - Сейф-бокс для ключей

В нашем случае внутри лежит ключ шифрования. Формально Apple определяет Secure Token так: «это упакованная версия ключа шифрования (Key Encryption Key, KEK), защищенная паролем пользователя» (рис.2).

Рис.2 - Определение Apple для Secure token

Другими словами, Secure Token – это объект, представляющий собой KEK, зашифрованный паролем пользователя. Хранится он в специальном зашифрованном хранилище (keybag) в метаданных APFS-тома (подробнее в документе Apple File System Reference). Это хранилище доступно для чтения, даже когда диск заблокирован (иначе система не смогла бы проверить пароль при загрузке), но извлечь из него ключи можно, только зная пароль пользователя. Благодаря Secure Token система знает, что этот пользователь имеет право расшифровать диск FileVault при загрузке, изменять некоторые критические настройки безопасности и вообще считается «доверенным».

Кстати, если хотите глубже разобраться, как устроен FileVault и что такое KEK и VEK, у нас есть отдельная статья на эту тему: «FileVault: как Apple превратила шифрование диска в незаметную магию».

Как создаётся первый Secure Token

Когда вы настраиваете новый Mac, мастер настройки (Setup Assistant) просит создать первого пользователя и задать пароль. Именно в момент, когда задается первый пароль, происходит создание первого Secure Token. Система генерирует ключи для шифрования диска APFS и упаковывает ключ шифрования (KEK) в сейф-бокс, защитив его только что придуманным паролем. Для этого процесса нужен именно пароль, а не хэш.

В обычных условиях первый вошедший пользователь становится обладателем Secure Token по умолчанию. Однако бывают сценарии, например, создание служебной учетки для MDM, когда нужно создать первого пользователя без Secure Token. Это возможно, но команду надо применить до первого входа пользователя (как вариант на этапе развертывания):

sudo dscl . -append /Users/<имя_пользователя> AuthenticationAuthority ";DisabledTags;SecureToken"

Цепочка ключей в macOS

Разберём аббревиатуры, без которых дальше никуда.

• KEK (Key Encryption Key) — промежуточный ключ шифрования ключа. Это и есть содержимое сейф-бокса. Сам по себе он не шифрует данные, но шифрует другие ключи. Это мастер-ключ к остальным секретам системы.

• VEK (Volume Encryption Key) — ключ шифрования тома. Именно он в реальном времени шифрует всё содержимое вашего диска. Доступ к нему защищён KEK. Чтобы получить VEK, нужно сначала расшифровать KEK, то есть открыть сейф-бокс правильным паролем.

• OIK (Owner Identity Key) — ключ идентичности владельца, существует только на Mac с Apple Silicon. Это криптографическая пара ключей, приватная часть которой хранится в Secure Enclave (защищенная подсистема, встроенная в процессоры, систему на чипе, интегральную микросхему, устройства, SoC Apple). OIK нужен для подписи Local Policy — набора параметров загрузки и безопасности для каждой конкретной установки macOS. И он тоже защищён KEK.

Цепочка выглядит так:

Пароль пользователя

    └─► открывает Secure Token (сейф-бокс)

            └─► даёт KEK

                    ├─► расшифровывает VEK  → доступ к данным на диске

                    └─► расшифровывает OIK  → право подписывать Local Policy

Важная деталь про Apple Silicon, если Local Policy не подписана действующим OIK, то Mac не загрузится. Именно поэтому изменение настроек Secure Boot, разрешение загрузки с внешних дисков, установка обновлений прошивки — всё это требует прохождения через Secure Token. Без него вы физически не можете изменить эти параметры.

Практическая польза Secure Token

В чём практическая польза Secure Token? На самом деле, без Secure Token многие вещи просто не будут работать на современных Mac.

FileVault (шифрование диска). Без Secure Token пользователь не сможет активировать FileVault, даже если он админ. Более того, если FileVault уже включён, учётная запись без токена не будет добавлена в список пользователей, имеющих право расшифровывать диск при загрузке.

Доступ к Recovery OS и изменение настроек безопасности загрузки. На Intel Mac'ах, чтобы выключить SIP (система защиты данных System Integrity Protection) или разрешить загрузку с внешнего диска через Recovery, достаточно было знать пароль администратора. Recovery проверял, что пользователь является админом и имеет Secure Token. Если у администратора не было токена, аутентификация могла не пройти.

На Mac с Apple Silicon подход ужесточился: одной учетной записи с правами администратора мало, нужен именно volume owner с Secure Token. Когда вы заходите в Recovery и хотите изменить Secure Boot или систему загрузки, Mac потребует выбрать учётку volume owner и ввести её пароль. Эта связка проверяется криптографически: только volume owner имеет OIK, а OIK нужен для подписи новой Local Policy. Без Secure Token вы не сможете изменить критические настройки — система попросту не примет ваши действия.

Управление учетными записями. Пользователь с Secure Token может создавать других пользователей с токенами. Если админ с токеном добавляет нового пользователя через Системные настройки, новый пользователь автоматически получит Secure Token. Если же админ без токена добавит кого-то,  то токен не будет выдан.

При управлении через командную строку передача токена контролируется опцией sysadminctl -secureTokenOn: её нельзя выполнить без ввода логина и пароля существующего администратора с токеном.

Сама система защитит вас от ошибок: macOS не даст удалить последнего пользователя с Secure Token ни через GUI, ни через sysadminctl. Это спасает от ситуации, когда вы случайно остаетесь без токенов вообще. Но, конечно, если очень захотеть, можно сломать всё. Интересный момент, если вы всё же удалите последнего пользователя и затем попробуете переустановить macOS через Recovery, то обнаружите, что из-за Secure Token и отсутствия пользователей система не позволит выполнить установку.

Рис.3 - Recovery установка macOS после удаления последнего пользователя.

Обновления ПО и установка macOS. На Mac с Apple Silicon авторизация на установку обновлений системы требует volume owner (рис.4). Причём есть интересный момент: обычный стандартный пользователь (не админ), но являющийся volume owner, может разрешить установку обновления macOS. Достаточно, чтобы этот пользователь владел томом. Это сделано для корпоративных сценариев, где пользователи не админы, но могут самостоятельно подтверждать MDM-запросы на обновление. Без Secure Token такой пользователь не будет считаться владельцем и не сможет авторизовать установку апдейта.

Рис.4 - Ошибка установки обновления, пользователь не volume owner.

Команды для работы с Secure Token

С теорией разобрались, теперь к практике.

Проверить наличие токена у пользователя:

sysadminctl -secureTokenStatus <имя_пользователя>

Рис.5 - проверка наличие токена у пользователя в терминале.

Также можно через GUI посмотреть, в утилите “служба каталогов” (рис.6):

Рис.6 - проверка наличие токена у пользователя в службе каталогов.

Показать всех пользователей с FileVault (и Secure Token) на Mac (Рис.7):

fdesetup list -extended

Рис.7 - выполнение команды fdesetup.

Первая команда вернёт статус (Enabled/Disabled) для указанного аккаунта. Вторая выведет список пользователей, допущенных к FileVault, с указанием их UUID и типа (как правило, у всех них Secure Token есть).

Также на Apple Silicon список volume owners можно вывести через (Рис.8):

diskutil apfs listUsers /

Рис.8 - Выполнение команды diskutil apfs listUsers /

Эта команда покажет GUID всех владельцев тома. Затем GUID можно сопоставить с пользователем (рис.9):

dscl . -search /Users GeneratedUID <GUID> 

Рис.9 - Сопоставление GUID с пользователем.

Так вы всегда можете выяснить, кто на машине обладает Secure Token и volume ownership.

Наследование Secure Token

Первый Secure Token создаётся, когда KEK «оборачивается» паролем первого пользователя, и это убирает KEK из «не защищённого» состояния.

Следующие Secure Token создаются так: один Secure Token разворачивают, чтобы получить KEK, затем KEK оборачивают новым паролем нового пользователя.

sysadminctl -adminUser <ваш_логин> -adminPassword <ваш_пароль> \
-secureTokenOn <новый_пользователь> -password <его_пароль>

Также Secure Token наследуется:

• автоматически, если существующий пользователь с токеном создает нового через GUI;

• через MDM в корпоративной среде в момент первой настройки устройства (с помощью Bootstrap Token).

Рис.10 - Workflow передачи токена.

Часть 2. Bootstrap Token

Если Secure Token — это про связь пароля пользователя с ключами шифрования, то Bootstrap Token — это про связь MDM с вашим Mac. В некотором смысле, Bootstrap Token — это токен для самого устройства, который позволяет MDM-серверу выступать доверенным посредником.

Apple добавила Bootstrap Token в macOS 10.15 Catalina, чтобы решить главную проблему корпоративных админов, как выдавать Secure Token автоматически, без участия человека, когда устройство управляется через MDM.

Представьте: у вас десятки Mac, вы зарегистрировали их в Apple Business Manager, привязали к MDM, и при первом включении они сами создают локального администратора (Automated Device Enrollment). Админ создан, но Secure Token он не получит, ведь никто не вводил пароль интерактивно! Как тогда включить FileVault политикой или создавать других пользователей? Раньше это было невозможно, теперь Bootstrap Token пришёл на помощь.

Как работает Bootstrap Token

Bootstrap Token (BT) — это специальный токен устройства, который создаётся автоматически при первом входе любого пользователя с Secure Token на Mac под управлением MDM. Токен отправляется (эскроится) на MDM-сервер.

Bootstrap Token не дает MDM доступа к KEK или OIK пользователей. Вместо этого он позволяет MDM запрашивать выполнение привилегированных действий, а система, проверив подпись запроса,  доверяет MDM и выполняет их от своего имени.

Что может сделать MDM с помощью Bootstrap Token (рис.11):

• Получать Secure Token

• Одобрять расширения ядра (kernel extensions)

• Одобрять обновления ПО без ввода пароля пользователем

• Подтверждать команду «Стереть контент и настройки» (Erase All Content and Settings), отправленную через MDM

• Использовать декларативное управление устройством (Declarative Device Management) для обновлений macOS

• Создавать новую учётную запись в окне входа при разблокированном FileVault с использованием PSSO

Рис.11 - Возможности MDM с Bootstrap token согласно документации aApple.

Platform SSO и Bootstrap Token

В macOS 13 Ventura (и улучшено в 14 Sonoma) появился механизм Platform SSO. Он позволяет организациям интегрировать провайдеров идентичности (Okta (рис.12), Azure AD и др.) напрямую в процесс логина macOS.

Сотрудник включает новый Mac, на экране входа видит опцию войти через корпоративный аккаунт, проходит аутентификацию в Okta, и на Mac создаётся локальный профиль, привязанный к этому облачному пользователю. Поскольку пользователь создаётся «на лету», ему надо сразу выдать Secure Token.

Рис. 12 - Логин в macOS через Okta.

Bootstrap Token решает эту задачу: система запрашивает у MDM Bootstrap Token в момент создания нового аккаунта через Platform SSO и с его помощью наделяет свежесозданную учётку Secure Token при первом же входе. Без этого Platform SSO не смог бы полноценно создать локального пользователя (учётка создалась бы, но без токена, что сломало бы FileVault и другие механизмы).

Поэтому в требованиях к Platform SSO на macOS 14 прямо указано, что устройство должно иметь эскроенный Bootstrap Token, быть управляемым MDM (Рис.13).

Рис.13 - Требования bootstap token для mdm к PSSO.

Управление Bootstrap Token

Если обобщить, Bootstrap Token — это такой «мастер-ключ» для MDM, который позволяет выполнять действия, требующие особые полномочия, без участия пользователя.

Сам Bootstrap Token (BT) хранится в зашифрованном виде на MDM-сервере. Для администратора он практически прозрачен, нужно лишь убедиться, что MDM получил BT.

Проверить статус Bootstrap Token:

sudo profiles status -type bootstraptoken

Рис.14 - Проверка статуса Bootstrap Token.

Эта команда (Рис.14) покажет, поддерживает ли MDM эту функцию и передан ли токен.

Если автоматический процесс не сработал, можно инициировать отправку вручную. Важно: команда требует данные пользователя, у которого уже есть Secure Token, чтобы авторизовать операцию:

sudo profiles install -type bootstraptoken -user <существующий_админ_с_токеном> -password '<его_пароль>'

Заключение

Secure Token и Bootstrap Token — фундаментальные механизмы безопасности современных Mac. Понимание их работы помогает избежать множества проблем:

• Пользователи не появляются на экране FileVault? Проверьте Secure Token.

• MDM не может включить FileVault? Убедитесь, что есть Bootstrap Token.

• Recovery не пускает менять настройки? Ищите volume owner.

Надеюсь, этот материал помог вам разобраться в теме. Если остались вопросы — пишите в комментариях!