Лента прозрачности: реестр протоколов

Каждый готовый протокол попадает в реестр: хеш записи включает хеш предыдущей записи, пачка записей сворачивается в корень дерева Меркла, корень пишется в файл и заверяется меткой времени государственной службы НУЦ РК (RFC 3161) и OpenTimestamps. Изменить или убрать запись задним числом, не разорвав цепочку до заверенного корня, нельзя. Файл корня не содержит ни номеров протоколов, ни их содержимого. В ту же цепочку пишутся служебные записи: журнал входа администратора eFix под пользователем (причина, срок, завершение) и шаги споров по протоколам — тоже только хешами.

Архивные метки (ETSI TS 119 511)

Подпись протокола и квитанция времени в ней проверяются, пока действуют сертификаты подписанта и службы времени. Архивная метка — новая квитанция НУЦ РК и OpenTimestamps над файлом, в котором записаны хеш последнего корня реестра и хеш предыдущей метки вместе с её квитанцией. Пока цепочка продолжается (первая метка — как только есть заверённый корень, далее раз в квартал, досрочно — при смене ключа подписанта и за год до истечения сертификата подписанта или службы времени), факт существования каждого протокола доказуем и после истечения сертификатов. Evidence record протокола с цепочкой меток — на его странице проверки; экспортный пакет всех файлов ленты со скриптами проверки: efix-transparency.zip. Внешний монитор (любая третья сторона, стандартная библиотека Python): python tools/monitor_transparency.py https://efix.kz ./папка — по расписанию докачивает корни и метки через latest.json, проверяет непрерывность цепочек и квитанции и поднимает тревогу, если история переписана или откатилась.

Ключи постквантовой подписи (ML-DSA-65, FIPS 204)

Протоколы с 11.10.2026 несут, кроме ЭЦП НУЦ РК, второй подписной контейнер protocol.pdf.mldsa.p7s на те же итоговые байты — техническую страховку на случай ослабления классических алгоритмов. Ниже — все сертификаты eFix, которыми он когда-либо ставился; сертификат не удаляется и после смены ключа, иначе старые протоколы нечем проверить. Каждый сертификат входит в код выпуска, поэтому его отпечаток заверен в журнале выпусков (подпись, метка НУЦ РК, OpenTimestamps), а внешний монитор сигналит, если опубликованный сертификат исчез или изменился. Проверка контейнера — «Как проверить», раздел 2а.

Политика для архивных меток. Сегодня ни НУЦ РК, ни другие службы меток времени не выпускают постквантовых квитанций RFC 3161, поэтому архивные метки выше ставятся классическим алгоритмом службы. Когда появится служба меток с подписью ML-DSA (или другим алгоритмом FIPS 204/205), очередная архивная метка будет выпущена ею досрочно и накроет всю прежнюю цепочку — так же, как метка выпускается при смене ключа и до истечения сертификатов; прежние квитанции сохраняются. До тех пор постквантовую страховку каждого протокола даёт его собственный контейнер ML-DSA.

Как проверить без eFix

1. На странице проверки протокола возьмите «доказательство включения» (JSON) и скачайте файл корня, в который включена запись.
2. Запустите python tools/verify_ledger.py доказательство.json ledger-root-NNNNNN.json — скрипт из репозитория, только стандартная библиотека Python: он пересчитает хеш записи из её полей, проведёт путь Меркла до корня и сверит корень с файлом.
3. Цепочку корней: python tools/verify_ledger.py --chain ledger-root-000001.json ledger-root-000002.json … — каждый корень несёт хеш предыдущего.
4. Квитанции на файл корня: .tsr — любой программой RFC 3161 (например, openssl ts -verify), .ots — на opentimestamps.org или ots verify. Они подтверждают SHA-256 самого файла корня. Когда календарь включил квитанцию в блок, eFix дополняет её (ots upgrade) и сверяет блок по заголовку у двух обозревателей — в таблице появляется номер блока; ots verify покажет тот же блок и корень Меркла.