У команды MyBox из Мастерской обновление по гипотезе из предыдущего краудсорсинга: можно ли сделать воспроизводимый продукт (наш MyBox) на Apple‑железе так, чтобы удалённый узел мог криптографически проверить, что перед ним «правильный» бокс, а не подмена с применением админского доступа.

Спойлер: клонирование через ABM/MDM работает, но не элегантно. Вышло скорее размножение через центр, чем красивое p2p‑клонирование.

В конце — ограничения (в том числе про Россию) и почему мы продолжаем считать этот маршрут практичным для PoC/MVP. В комментариях оставили ссылку на разбор других (менее удачных) решений.

Контекст: чего мы хотели добиться и почему «в лоб» нельзя

Задача в терминах продукта стоит такая: MyBox должен уметь «переехать» на новый Mac mini так, чтобы можно было доказуемо отличить официальный бокс от «злого клона».

Ключевой жёсткий пункт из задачи был такой: нужен сигнал доверия, который нельзя подделать через «доступ разработчика/админа к нашему процессу».

В предыдущем раунде обсуждений стало ясно, что публичного Apple API, который выдаёт Apple‑signed attestation именно конкретного пользовательского процесса/хеша бинарника на macOS, нет. Тогда в обсуждении родилась гипотеза: если нельзя аттестовать приложение, можно попытаться опереться на то, что Apple точно умеет и делает массово — корпоративное управление устройствами.

Гипотеза: Apple ABM + MDM как «корень доверия» для размножения продукта

Идея простая:

• Apple умеет привязывать устройство к корпоративному управлению (Apple Business Manager, ABM).

• При первичной активации macOS может получить от Apple команду: «за настройками иди к конкретному MDM‑серверу».

• Дальше MDM‑сервер (в нашем прототипе это «Адам», первичное устройство, выведенное на кибериспытания и полностью проверяемое) может выдать конфигурацию и поставить нужные компоненты.

Нас интересовало не удобство MDM как таковое, а можно ли сделать так, чтобы:

• мы (как разработчики) не могли подменить установку так, чтобы получился «злой MyBox»;

• участники процесса не могли незаметно вклиниться и подсунуть другое устройство/другой сервер;

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

Что проверяли и что получилось подтвердить

Админ ABM не может навредить

Ключевая проверка: если у кого‑то есть доступ к Apple Business Account (ABM), может ли он тайно повлиять на установку так, чтобы получился «злой» MyBox.

Результат теста/разбора:

• ABM‑доступ сам по себе не даёт «волшебного рычага» подсунуть пользователю другой MyBox.

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

Не упустили ли мы критическую уязвимость в узких местах

Отдельно прогнали остальные места, где обычно случается магия:

• подмена акторов (Apple / «Адам» / новое устройство);

• попытка атаковать процесс установки через сеть;

• попытка вмешаться в конфиг/подписи.

В прототипе критичный момент про канал связи сформулирован так: новый Mac и «Адам» общаются через интернет, с проверкой подлинности (в терминах TLS — пиннинг/жёсткая привязка), чтобы подменить ни «Адама», ни устройство было нельзя.

Как выглядит процесс (упрощённо)

Три актора:

• Apple

• «Адам» — исходный MyBox, который хранит приватные ключи и «знает конфигурацию» (на кибериспытаниях, поэтому доверенный)

• новый Mac mini (который станет MyBox)

Поток:

1. Мы добавляем новый Mac в корпоративный аккаунт (ABM). Это вручную.

2. При активации новый Mac общается с Apple и получает инструкцию: «настройка — через MDM‑сервер (Адам)».

3. Новый Mac идёт к «Адаму», «Адам» конфигурирует устройство, устанавливает нужное и подписывает то, что должно быть подписано.

4. Дальше устройство можно удалить из корпоративного аккаунта или оставить — на работоспособность MyBox это уже не влияет.

Важно: приватные ключи живут в «Адаме» и никогда его не покидают, а установка идёт по каноническому пути Apple‑экосистемы.

Если интересны детали «где в процесс может/не может влезть злоумышленник» — у нас есть 3 иллюстрации из внутренней разборки.

Важные оговорки

Клонировать можно только «Адама»

Это сильное ограничение.

В этой схеме не любой MyBox размножает следующий, что было идеальным образом результата для клонирования.

Размножает только «Адам» — тот, кто:

• хранит конфигурацию;

• связан с Apple Business Account;

• подписывает нужные артефакты для клона.

«Адамов» может быть несколько, но пользователь, чтобы получить бокс, всё равно должен принести устройство к «Адаму»/в контур, который добавит его в ABM (условно — есть связующий «человек‑установщик»).

То есть UX получается не «дай другу с боксом на вечер», а «отнеси в точку, где есть доступ к ABM + Адам».

На чём держится защита и что будет означать взлом

Эта схема сознательно опирается на механизмы Apple. Поэтому «взлом клонирования» в нашей формулировке разваливается на два сценария:

1. сломать Apple (или конкретный механизм корпоративного управления/привязки на активации);

2. сломать наши проверки нетронутости нового Mac на пути к конфигурации.

Атака становится другого класса и выходит за рамки «кто‑то подменил нам установку, имея доступ к аккаунту/админу».

ABM официально не работает в России

Это, конечно, большой фактор применимости для региона.

Почему это не элегантно, но всё равно полезно

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

• ручное администрирование (добавление в ABM);

• зависимость от наличия интернета у всех участников в момент установки;

• ограничения на масштаб (и потенциальные вопросы от Apple при странных паттернах активности).

Но у него есть причина жить: в текущих ограничениях macOS/Apple это, похоже, лучший способ получить криптографически подкреплённую воспроизводимость на Apple‑железе, не превращая нас (разработчиков) в точку коррупции. По крайней мере до этапа MVP и/или новых разработок самих Apple для MDM.

Как это ложится на этапы продукта (PoC → MVP)

С практической точки зрения мы смотрим на это как на этапы производства MyBox:

PoC (до 100 устройств)

• Что делаем: предоставляем устройства штучным пользователям‑тестерам для проверки гипотез и сбора обратной связи.

• Как производим: централизованная сборка — собираем/инициируем «Адама», от него делаем новые MyBox.

MVP (условно несколько сотен)

• Что делаем: уже продаём готовые устройства.

• Как закупаем: централизованно у реселлера (вне РФ), который может сразу добавлять устройства в корпоративный аккаунт.

• Как производим: активация устройства подтягивает «Адама» и ставит MyBox автоматически.

На больших количествах придётся отдельно думать про:

• доступность Mac mini как платформы;

• устойчивость цепочки поставок;

• операционную модель «человек‑установщик/точки».

Что дальше

Мы пошли делать демо. А если у вас есть:

• вопросы к модели угроз (где мы могли ошибиться),

• опыт с ABM/MDM в нетипичных сценариях,

• идеи, как упростить UX без потери невмешательства разработчика,

• приходите в комментарии.

Апдейты по MyBox и следующим проверкам продолжим выкладывать здесь и в телеграм‑канале Мастерской.