Каждый протокол выдаётся архивом: protocol.pdf и файлы, которыми его
можно проверить независимо от сервиса. Ниже — что именно и чем проверяется. Страница
проверки на сайте делает то же самое
автоматически, но она принадлежит eFix; для суда важнее проверка сторонними средствами.
Что именно система делает при фиксации — в декларации практик; номер её редакции печатается в разделе 1 протокола.
Пересчитайте SHA-256 файла protocol.pdf (например, sha256sum protocol.pdf
или certutil -hashfile protocol.pdf SHA256) и сравните с protocol.pdf.sha256
из архива и с числом в QR-коде протокола. Совпадение означает, что файл не менялся после выдачи.
protocol.cms — документ внутри подписи. Загрузите файл на
ezsigner.kz → «Проверить документ» или в SIGEX:
сервис покажет подписанта по сертификату НУЦ РК и момент квитанции метки времени, вложенной в
подпись. Из подписи извлекается тот же protocol.pdf — сверьте его SHA-256 с пунктом 1.protocol.pdf.cms проверяется вместе с protocol.pdf
программами проверки ЭЦП НУЦ РК (NCALayer и совместимые).protocol.cms
с такой квитанцией поставлен дополнительно (дозаверение).
В протоколах с 11.10.2026 те же итоговые байты protocol.pdf, что подписаны ЭЦП НУЦ РК, дополнительно
подписаны постквантовым алгоритмом ML-DSA-65 (FIPS 204): файл protocol.pdf.mldsa.p7s — отсоединённая
подпись CMS (RFC 9882, дайджест SHA-512) — и открытый сертификат eFix efix-mldsa65.pem. Контейнер не
заменяет ЭЦП и самостоятельного юридического значения не имеет: он сохраняет проверяемость неизменности файла,
если со временем классические алгоритмы подписи будут ослаблены. Проверка — свободной программой OpenSSL 3.5 или
новее (в Git для Windows, Debian 13, Alpine 3.22 она уже есть; в macOS — brew install openssl@3):
openssl x509 -in efix-mldsa65.pem -noout -fingerprint -sha256 openssl cms -verify -binary -inform DER -in protocol.pdf.mldsa.p7s -content protocol.pdf -CAfile efix-mldsa65.pem -out /dev/null
Первая команда печатает отпечаток сертификата — сверьте его с опубликованным на
ленте прозрачности (там же сертификат можно скачать
и использовать вместо файла из архива). Вторая должна ответить CMS Verification successful; любое
изменение хотя бы одного байта PDF даёт verification failure. В командной строке Windows вместо
/dev/null укажите NUL. Без своей OpenSSL — через Docker:
docker run --rm -v "$PWD:/d" -w /d alpine:3.22 sh -c "apk add -q openssl && openssl cms -verify -binary -inform DER -in protocol.pdf.mldsa.p7s -content protocol.pdf -CAfile efix-mldsa65.pem -out /dev/null".
protocol.tsr — квитанция RFC 3161 на SHA-256 файла protocol.pdf.
Проверка: openssl ts -verify -data protocol.pdf -in protocol.tsr -CAfile <корневой сертификат НУЦ РК>.protocol.pdf.ots — квитанция OpenTimestamps (блокчейн Bitcoin). Проверка:
opentimestamps.org или
ots verify protocol.pdf.ots. Квитанция подтверждает, что файл с таким хешем существовал
не позже момента записи в блокчейн.
Хеш каждого готового протокола попадает в публичный реестр: записи связаны в цепочку, пачки записей
сворачиваются в корень, корень заверяется меткой НУЦ РК и OpenTimestamps. На
ленте прозрачности скачайте файл корня, на странице
проверки протокола — «доказательство включения», и запустите
python tools/verify_ledger.py доказательство.json ledger-root-NNNNNN.json
(скрипт из репозитория eFix, только стандартная библиотека Python). Файл корня не раскрывает ни
номеров, ни содержимого протоколов.
capture.wacz — веб-архив страницы со всеми ресурсами. Откройте его на
replayweb.page (работает в браузере, файл никуда не
отправляется) — страница воспроизводится как была зафиксирована. Внутри архива datapackage.json
с хешами всех файлов и datapackage-digest.json с подписью ECDSA и квитанцией метки времени
НУЦ РК над ней; целостность проверяется командой wacz validate -f capture.wacz (py-wacz).
Заголовки ответов сервера для ресурсов в таком архиве синтезированы из снимка страницы — это указано в warcinfo.
Подпись и квитанция времени проверяются, пока действуют сертификаты подписанта и службы времени.
Чтобы протокол оставался проверяемым и после их истечения, над реестром выпускаются архивные метки:
файл с хешем последнего корня и хешем предыдущей метки вместе с её квитанцией, заверенный НУЦ РК
и OpenTimestamps (первая — после первого заверённого корня, далее раз в квартал, досрочно — при смене
ключа и за год до истечения сертификатов). Evidence record протокола (ссылка на странице проверки,
/api/ledger/evidence/<номер>; файл хранится в папке реестра, выданный протокол не меняется)
содержит доказательство включения, корень, цепочку меток и данные валидации подписи, снятые при первой записи.
Проверка без eFix: скачайте evidence record и файлы корня и меток с их квитанциями
(efix-transparency.zip содержит всё сразу), затем
python tools/verify_evidence_record.py evidence_record.json ledger/ — скрипт пересчитывает
включение, хеши файлов, ссылки между метками и отпечатки внутри квитанций RFC 3161, печатает момент
каждой квитанции и срок сертификата службы, а при истёкшем сертификате подписанта показывает, что подпись
удостоверена квитанцией до истечения и цепочка меток не прерывалась.
С 11.10.2026 протокол сообщает о каждом медиафайле (скачанные медиа публикации, фото и видео с телефона,
вложения письма, медиа из выгрузки переписки, скачанное видео), есть ли в нём манифест C2PA, действительна ли
его подпись и доверена ли цепочка сертификата, кто выдал сертификат, какой программой и какие действия
заявлены — в том числе генерация ИИ (digitalSourceType trainedAlgorithmicMedia).
Манифест — заявление создателя файла, а не установленный факт; его отсутствие ничего не доказывает.
Прочитанный манифест лежит в архиве рядом с файлом: <файл>.c2pa.json (для выгрузки
переписки — в папке c2pa/).
Самостоятельная проверка открытым инструментом C2PA c2patool (проверено с версией 0.27.22) по тому же списку доверия, что использует eFix (C2PA-TRUST-LIST.pem, копия официального списка C2PA от 05.08.2026; SHA-256 списка напечатан в протоколе):
c2patool media/image_0.jpg trust --trust_anchors C2PA-TRUST-LIST.pem
В ответе: validation_state — Trusted (подпись действительна, сертификат в списке
доверия), Valid (подпись действительна, цепочка не доверена) или Invalid; в
validation_results — коды нарушений, например assertion.dataHash.mismatch (файл
изменён после подписания). Для файла без манифеста c2patool отвечает No claim found.
Те же коды напечатаны в протоколе.
Снимок, сделанный в мобильном приложении eFix, несёт манифест, подписанный на телефоне ключом, происхождение
которого подтверждено аттестацией устройства; сертификат на этот ключ выдал удостоверяющий центр устройств eFix.
По списку C2PA такая цепочка «не доверена» (корень eFix в него не входит) — проверяйте по корню eFix
(efix-device-ca.pem,
SHA-256 сертификата 452bf312e1140cdda7aff55e3ae2a766e754f014e43177eea23cfdc551c732c5):
c2patool evidence.jpg trust --trust_anchors efix-device-ca.pem
Ответ Trusted и signingCredential.trusted означают: подпись действительна и выдана
на ключ устройства eFix. Какого именно устройства — протокол печатает серийный номер сертификата и отпечаток
ключа; тем же ключом подписан хеш файла (раздел «Аттестация устройства»).
В разделе 1 протокола указаны выпуск, коммит и отпечаток реестра выпуска (SHA-256 списка файлов кода), а также итог самопроверки кода сервера в момент фиксации. Реестр выпуска с подписью, меткой НУЦ РК и квитанцией OpenTimestamps хранится в журнале выпусков eFix и выдаётся по запросу: эксперт пересчитывает SHA-256 файлов выпуска и сверяет отпечаток с напечатанным в протоколе.
Перечень файлов с их контрольными суммами напечатан в протоколе (реестр файлов) и продублирован в
manifest.json. Снимок страницы (screenshot.png), исходный HTML, архив страницы
(page.mhtml), журнал сетевых запросов и, для соцсетей, скачанные медиа — всё это
сверяется по SHA-256 с реестром.
Вопросы по проверке: контакты. Протокол оформляется по п. 5 ст. 78 ГПК РК; оценку доказательства даёт суд.