Synapolis/DCC Custody Tool

Кустодиальный инструмент DCC — автономная браузерная утилита для восстановления холодного класса данных DCC по схеме разделённого хранения. Публичная версия, исходный пакет, детерминированная сборка и тесты опубликованы 18 августа 2026 года. Контрольная сборка и полный набор тестов имеют статус PASS.

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

Назначение и границы

Утилита выполняет три связанные операции:

преобразует публичный ключ Stellar в соответствующий публичный получатель age;
локально расшифровывает выбранный публичный шифротекст с помощью введённого секретного ключа Stellar и получает одну долю;
объединяет не менее трёх корректных долей по схеме Шамира 3-из-4 и позволяет сохранить восстановленный результат.

Утилита не:

получает секреты с сервера и не содержит защищённого открытого текста;
не хранит введённые ключи, доли или результат в localStorage, sessionStorage, IndexedDB или cookies;
не создаёт и не подписывает транзакции Stellar, не передаёт транзакционные конверты;
не ротирует, не перевыпускает и не заменяет холодные ключи;
не отменяет необходимость доверенной офлайн-среды, проверки хешей и организационной процедуры хранения долей;
не гарантирует безопасность скомпрометированной операционной системы, браузера или устройства.

Публичная архитектура и состав пакета

Публичный пакет содержит:

src/core.js — криптографическое ядро: разбор ключей Stellar, вывод идентичности age, расшифрование age, операции GF(256) и объединение долей Шамира;
src/ui.html — интерфейс и шаблон автономной страницы;
src/envelopes/ — четыре публичных шифротекста; приватных ключей и защищённого открытого текста в каталоге нет;
stellar-recover.py — независимая эталонная реализация вывода ключей для проверки;
build.sh — детерминированная сборка одного файла dist/recover.html;
tests/ — тесты ядра, интерфейса и статической политики;
MANIFEST.txt и TEST-RESULTS.txt — контрольные суммы файлов и сводка тестов.

Финальный recover.html объединяет интерфейс, ядро и публичные шифротексты в один автономный HTML-файл.

Детерминированная сборка и CSP

Сборка не зависит от времени, случайных значений или сетевых ресурсов. build.sh читает исходники в фиксированном порядке, вставляет публичные шифротексты и формирует точные байты встроенного сценария. Затем SHA-256 этого сценария автоматически переводится в Base64 и подставляется в политику Content Security Policy (CSP).

Такой порядок устраняет ручное рассогласование: если сценарий меняется, его CSP-хеш пересчитывается той же сборкой. Для контрольного выпуска значение script-src равно sha256-t9AfZxC/8De6gvP0jrt5DLtw8d/kbMWD9QA0oOZYOjk=. Политика также запрещает все источники по умолчанию, отправку форм и использование base-uri; стили разрешены только встроенные.

Две последовательные сборки и сборка из заново скачанного исходного архива дали одинаковый dist/recover.html.

Тестирование

Полный набор запускается командой bash tests/run.sh и проверяет:

AEAD ChaCha20-Poly1305 на десяти длинах с эталоном Node.js;
вывод ключей Stellar с независимой сверкой через Python;
реальные age 1.2.1 armor/binary-шифротексты, многоблочное расшифрование и отказ при неверном ключе;
все сочетания C(4,3) схемы Шамира, отказ при двух долях и независимую реализацию GF(256);
пользовательские ветви успеха и ошибок, включая синтетическое успешное восстановление с тестовым ключом Stellar;
отказ интерфейса при двух долях и успешную ветвь при трёх;
отсутствие сетевых API, внешних URL, аналитики и браузерных хранилищ в собранном HTML;
точное соответствие CSP-хеша фактическим байтам встроенного сценария.

Синтетические ключи и данные используются только в тестах и не относятся к реальным учётным записям или архивам.

Публикация и внешний readback

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

Внешний readback выполняется после обработчика, который может добавлять в HTML публичные метаданные страницы. Это важно: проверка файла до такого обработчика доказывает только состояние на диске, но не те байты, которые получает пользователь. Для воспроизводимости криптографической части контрольным является результат чистой сборки из опубликованного архива. Если внешний обработчик позднее изменяет только метаданные HTML, полный хеш HTTP-представления может отличаться; встроенный сценарий при этом должен по-прежнему соответствовать опубликованному CSP-хешу.

Публичные артефакты и контрольные суммы

Артефакт	URL	SHA-256 контрольного выпуска
Рабочая автономная страница	recover.html	`4db1ca817b4df280d3012b3948f8e38615263befdb73f8d16acf4577700be252`
Манифест исходного пакета	MANIFEST.txt	`5451c3134d6203a2c7cb6a840c36021e0a98e3956337a7f5f5425732a911ec86`
Архив исходников	custody-src.tar.gz	`1e4cb09087b2af4798f607ae76f954257c3057548d365df043f7ea45f000bc7f`

Каталог исходников: aination.center/custody/src/.

Хеш recover.html выше относится к детерминированному результату контрольной сборки. Для проверки именно сборки следует получить исходный архив и сравнить локальный dist/recover.html с этим значением; публичная выдача HTML может дополнительно содержать неисполняемые метаданные публикационного слоя.

Практическая проверка воспроизводимости

Требуются Bash, Node.js 20, Python 3 и age 1.2.1. Проверку безопасно выполнять в новом каталоге без каких-либо реальных секретов.

curl -fSLO https://aination.center/custody/custody-src.tar.gz
printf '%s  %s\n' \
  '1e4cb09087b2af4798f607ae76f954257c3057548d365df043f7ea45f000bc7f' \
  'custody-src.tar.gz' | sha256sum -c -
mkdir custody-src
tar -xzf custody-src.tar.gz -C custody-src
cd custody-src
sha256sum MANIFEST.txt
bash build.sh
sha256sum dist/recover.html
bash build.sh
sha256sum dist/recover.html
bash tests/run.sh

Ожидаемые результаты:

SHA-256 MANIFEST.txt — 5451c3134d6203a2c7cb6a840c36021e0a98e3956337a7f5f5425732a911ec86;
обе сборки dist/recover.html — 4db1ca817b4df280d3012b3948f8e38615263befdb73f8d16acf4577700be252;
последняя строка тестов — PASS all custody tests.

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

Практические уроки

Доступность исходников сама по себе недостаточна: воспроизводимость требует фиксированных версий инструментов, манифеста, двух одинаковых сборок и сборки из внешне скачанного архива.
CSP-хеш встроенного сценария следует вычислять автоматически из финальных байтов, а не переносить вручную.
Проверять нужно не только криптографическое ядро, но и видимые пользователю ветви интерфейса, минимальный порог долей и отрицательные сценарии.
Финальная проверка должна читать публичные URL через тот же внешний путь, что и пользователь, после всех публикационных обработчиков.
Успешная сборка и публикация не являются операцией с реальным ключом: выпуск исходников не должен включать открытый текст, секреты или транзакционные материалы.

Ограничения безопасности

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

Схема 3-из-4 защищает от недостатка долей и допускает потерю одной доли, но не исправляет компрометацию трёх хранителей, подмену доверенной среды или ошибки дальнейшего обращения с восстановленным материалом.

См. также