Как проверять достоверность данных, поступающих в цифровой паспорт

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

Что именно проверяется в цифровом паспорте

При загрузке данных в цифровой паспорт обычно проверяются три уровня:

• Целостность сообщения – убедиться, что содержимое не изменено после подписи.
• Подпись отправителя – подтвердить, что данные подписаны закрытым ключом, соответствующим доверенному субъекту (государственный орган, аккредитованный удостоверяющий центр и т.п.).
• Действительность сертификата открытого ключа – проверить, что сертификат не отозван, не истёк и выдан доверенным центром сертификации.

Если любой из этих пунктов не выполнен, данные считаются ненадёжными и их использование в цифровом паспорте следует приостановить.

Основные принципы проверки

Криптографическая подпись и хеш-функция

Подпись создаётся путем вычисления хеша данных и последующего его шифрования закрытым ключом отправителя. При проверке вычисляется хеш полученных данных, расшифровывается подпись открытым ключом и сравниваются два хеша. Совпадение подтверждает, что данные не были изменены после подписи.

Цепочка доверия (PKI)

Открытый ключ, использованный для проверки подписи, содержится в сертификате X.509. Сам сертификат должен быть подписан доверенным центром сертификации (ЦС). Для установления доверия необходимо построить цепочку от сертификата отправителя к одному из корневых сертификатов, уже внесённых в список доверенных ( trust store ) системы или приложения.

Проверка статуса сертификата

Даже если цепочка построена корректно, сертификат может быть отозван или просрочен. Поэтому после построения цепочки следует:

• Сравнить текущую дату с полями NotBefore и NotAfter сертификата.
• Проверить наличие отзыва через список отзыва сертификатов (CRL) или протокол OCSP.

Временные метки и nonce

Для защиты от атак «повторного воспроизведения» в данных часто включают временную метку (timestamp) или случайное число (nonce). При проверке убеждаются, что метка находится в допустимом окне времени и nonce не использовался ранее.

Пошаговая процедура проверки данных при поступлении

1. Приём сообщения в защищённом канале (TLS, VPN, защищённое API).
2. Извлечение из сообщения самого payload (данных) и цифровой подписи.
3. Вычисление хеша payload с использованием того же алгоритма, что указан в подписи (обычно SHA‑256 или SHA‑384).
4. Получение открытого ключа отправителя из его сертификата, встроенного в сообщение или взятого из доверенного хранилища.
5. Расшифровка подписи открытым ключом и сравнение полученного хеша с вычисленным на шаге 3.
6. Построение цепочки сертификатов от сертификата отправителя к доверенному корневому ЦС.
7. Проверка сроков действия каждого сертификата в цепочке.
8. Проверка статуса отзыва (CRL/OCSP) для каждого сертификата.
9. Если присутствует временная метка или nonce – проверка их актуальности и уникальности.
10. Если все проверки прошли успешно – данные считаются достоверными и могут быть записаны в цифровой паспорт.

Инструменты и технологии для реализации проверки

На практике проверка выполняется с помощью готовых криптографических библиотек, которые уже реализуют все перечисленные шаги. Наиболее часто используются:

• Библиотеки с открытым исходным кодом: OpenSSL, BoringSSL, wolfSSL, mbedTLS.
• Языковые SDK: Java PKI, .NET System.Security.Cryptography.X509Certificates, Python cryptography, Go crypto/x509.
• Аппаратные модули защиты (HSM, TPM, secure element) – используются для хранения закрытых ключей и выполнения криптографических операций в изолированной среде.
• Сервисы проверки статуса: локальные CRL‑файлы, OCSP‑ responders, сервисы времени (timestamping authority).

При интеграции в систему цифрового паспорта рекомендуется:

• Использовать проверенные версии библиотек, регулярно обновляя их для устранения известных уязвимостей.
• Хранить список доверенных корневых сертификатов в отдельном, защищённом хранилище и обновлять его только из официальных источников.
• Журналировать результаты каждой проверки (успех/неуспех, код ошибки) для последующего аудита.

Ограничения и типичные ошибки

Даже при соблюдении процедуры существуют факторы, которые могут снизить эффективность проверки:

• Использование устаревших хеш‑функций (MD5, SHA‑1) – они больше не считаются криптостойкими.
• Приём данных по незащищённому каналу без последующей проверки подписи – открывает путь к атаке «man‑in‑the‑middle».
• Отсутствие актуального списка отзыва или недоступность OCSP‑сервера – может привести к ложноположительному результату (принятие отозванного сертификата).
• Непроверка временных меток – позволяет злоумышленнику переиграть старый, но ранее корректно подписанный набор данных.
• Хранение закрытых ключей отправителя в ненадёжном месте – если ключ скомпрометирован, подпись больше не гарантирует подлинность.

Важно помнить, что проверка подписи гарантирует только целостность и подлинность источника, но не оценивает саму семантику данных (например, корректность даты рождения или адреса). Для этого нужны отдельные бизнес‑правила валидации.

Что делать, если проверка не прошла

При возникновении любой ошибки на этапе проверки следует:

1. Отклонить запись данных в цифровой паспорт и вернуть пользователю или системе‑отправителю код ошибки с пояснением (например, «подпись неверна», «сертификат отозван», «цепочка доверия разорвана»).
2. Журналировать событие с указанием временной метки, идентификатора сообщения и типа ошибки для последующего расследования.
3. Если ошибка связана с временными проблемами (просроченный сертификат, недоступный OCSP), предложить отправителю обновить свои учётные данные или предоставить альтернативный способ передачи данных (например, повторную отправку с новым подписанным пакетом).
4. В случае повторяющихся ошибок от одного и того же источника инициировать процедуру проверки его аккредитации или временно приостановить приём данных от этого субъекта до выяснения обстоятельств.

Практические рекомендации по организации процесса проверки

• Определить чёткий набор доверенных корневых сертификатов и регулярно (не реже раза в квартал) обновлять его из официальных источников (министерства, аккредитованные ЦС).
• Внедрить автоматическую проверку цепочки и статуса отзыва на уровне шлюза или middleware, чтобы все входящие данные проходили одинаковую валидацию.
• Использовать изолированные среды (sandbox) для выполнения криптографических операций, особенно если данные поступают от непроверенных партнёров.
• Документировать все этапы проверки и хранить доказательства (журналы, временные метки) в соответствии с требованиями аудита и нормативными актами (например, GDPR, локальные законы о защите персональных данных).
• Проводить периодические тесты на проникновение и проверку устойчивости к известным атакам (повторное воспроизведение, подмена сертификата, downgrade‑атаки на хеш‑функцию).
• Обучать сотрудников, отвечающих за приём и обработку данных, основам работы с PKI и распознавания типичных признаков подозрительных сообщений.

Заключительный принцип

Главное условие достоверности данных в цифровом паспорте – успешная проверка криптографической подписи при наличии доверенной цепочки сертификатов и актуального статуса отзыва. Если хотя бы один из этих элементов отсутствует или нарушен, данные следует рассматривать как потенциально ненадёжные и не допускать их записи без дополнительного уточнения у источника.

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