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

Каждый протокол выдаётся архивом: protocol.pdf и файлы, которыми его можно проверить независимо от сервиса. Ниже — что именно и чем проверяется. Страница проверки на сайте делает то же самое автоматически, но она принадлежит eFix; для суда важнее проверка сторонними средствами.

Что именно система делает при фиксации — в декларации практик; номер её редакции печатается в разделе 1 протокола.

Судье и секретарю: проверка за несколько минут

  1. Наведите камеру телефона на QR-код протокола или откройте www.efix.kz/verify и введите номер протокола (EF-… или SC-…). Страница покажет: сходится ли подпись, кто подписал, когда, действовал ли сертификат и не отозван ли он.
  2. Чтобы убедиться, что у вас тот же файл, загрузите на этой странице сам protocol.pdf, полученный от стороны: страница сравнит его SHA-256 с выданным. Совпадение — файл не менялся.
  3. Чтобы не зависеть от сайта eFix, проверьте подпись protocol.cms на ezsigner.kz или в SIGEX (раздел 2 ниже), а SHA-256 — стандартной командой компьютера (раздел 1).
  4. Что зафиксировано (адрес, текст, снимок), читается в самом PDF; по одному номеру страница проверки этого не показывает — так защищены сведения сторон.

Что видно на странице проверки без входа

По одному номеру протокола страница проверки показывает только сведения о подлинности файла: номер, время фиксации, SHA-256 файла протокола и его сверку, электронную подпись и её сверку с файлом, квитанции меток времени, запись в реестре. Что именно зафиксировано — адрес и заголовок страницы, имя файла, домен отправителя письма, сведения о телефоне — по номеру не показывается: номер напечатан в QR-коде и может оказаться у постороннего.

Полные сведения видит владелец протокола в кабинете, тот, кто открыл ссылку из QR-кода протокола (в протоколах с версии 49.49 в ней есть ключ после знака «#», он не передаётся в журналы сервера), и тот, кто загрузил на странице проверки сам файл protocol.pdf. Знать номер или хеш протокола для этого недостаточно. Страницы проверки закрыты от поисковых систем (noindex).

1. Неизменность файла

Пересчитайте SHA-256 файла protocol.pdf (например, sha256sum protocol.pdf или certutil -hashfile protocol.pdf SHA256) и сравните с protocol.pdf.sha256 из архива и с числом в QR-коде протокола. Совпадение означает, что файл не менялся после выдачи.

2. Электронная подпись

2а. Второй подписной контейнер ML-DSA-65 (техническая страховка)

В протоколах с 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".

3. Метки времени на файл протокола

4. Реестр протоколов (лента прозрачности)

Хеш каждого готового протокола попадает в публичный реестр: записи связаны в цепочку, пачки записей сворачиваются в корень, корень заверяется меткой НУЦ РК и OpenTimestamps. На ленте прозрачности скачайте файл корня, на странице проверки протокола — «доказательство включения», и запустите python tools/verify_ledger.py доказательство.json ledger-root-NNNNNN.json (скрипт из репозитория eFix, только стандартная библиотека Python). Файл корня не раскрывает ни номеров, ни содержимого протоколов.

4а. Воспроизведение страницы (WACZ)

capture.wacz — веб-архив страницы со всеми ресурсами. Откройте его на replayweb.page (работает в браузере, файл никуда не отправляется) — страница воспроизводится как была зафиксирована. Внутри архива datapackage.json с хешами всех файлов и datapackage-digest.json с подписью ECDSA и квитанцией метки времени НУЦ РК над ней; целостность проверяется командой wacz validate -f capture.wacz (py-wacz). Заголовки ответов сервера для ресурсов в таком архиве синтезированы из снимка страницы — это указано в warcinfo.

4б. Архивные метки и evidence record (ETSI TS 119 511)

Подпись и квитанция времени проверяются, пока действуют сертификаты подписанта и службы времени. Чтобы протокол оставался проверяемым и после их истечения, над реестром выпускаются архивные метки: файл с хешем последнего корня и хешем предыдущей метки вместе с её квитанцией, заверенный НУЦ РК и OpenTimestamps (первая — после первого заверённого корня, далее раз в квартал, досрочно — при смене ключа и за год до истечения сертификатов). Evidence record протокола (ссылка на странице проверки, /api/ledger/evidence/<номер>; файл хранится в папке реестра, выданный протокол не меняется) содержит доказательство включения, корень, цепочку меток и данные валидации подписи, снятые при первой записи.

Проверка без eFix: скачайте evidence record и файлы корня и меток с их квитанциями (efix-transparency.zip содержит всё сразу), затем python tools/verify_evidence_record.py evidence_record.json ledger/ — скрипт пересчитывает включение, хеши файлов, ссылки между метками и отпечатки внутри квитанций RFC 3161, печатает момент каждой квитанции и срок сертификата службы, а при истёкшем сертификате подписанта показывает, что подпись удостоверена квитанцией до истечения и цепочка меток не прерывалась.

4в. Content Credentials (C2PA) медиафайлов

С 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. Какого именно устройства — протокол печатает серийный номер сертификата и отпечаток ключа; тем же ключом подписан хеш файла (раздел «Аттестация устройства»).

5. Какой программой сделан протокол

В разделе 1 протокола указаны выпуск, коммит и отпечаток реестра выпуска (SHA-256 списка файлов кода), а также итог самопроверки кода сервера в момент фиксации. Реестр выпуска с подписью, меткой НУЦ РК и квитанцией OpenTimestamps хранится в журнале выпусков eFix и выдаётся по запросу: эксперт пересчитывает SHA-256 файлов выпуска и сверяет отпечаток с напечатанным в протоколе.

5а. Машиночитаемый протокол

С версии 50.89 рядом с protocol.pdf лежит protocol.json — тот же протокол в полях для программ (в том числе для «Цифрового помощника судьи»): реквизиты, объект, время, хеши, пределы фиксации и реестр файлов архива с SHA-256 каждого. Подпись той же ЭЦП НУЦ РК — protocol.json.cms, проверяется как в п. 2 (файл и отсоединённая подпись). Схема: efix-protocol-v1.json. JSON ничего не добавляет к PDF; при расхождении решает подписанный PDF.

6. Что в архиве

Перечень файлов с их контрольными суммами напечатан в протоколе (реестр файлов) и продублирован в manifest.json. Снимок страницы (screenshot.png), исходный HTML, архив страницы (page.mhtml), журнал сетевых запросов и, для соцсетей, скачанные медиа — всё это сверяется по SHA-256 с реестром.

Вопросы по проверке: контакты. Протокол оформляется по п. 5 ст. 78 ГПК РК; оценку доказательства даёт суд.