🟨 Электронная подпись (ЭП) является краеугольным камнем современного юридически значимого электронного документооборота, обеспечивая подлинность, целостность и неотрекаемость отправителя документа. В сфере государственных закупок, банковского обслуживания, страховых услуг и корпоративного управления электронные заявки с подписью заменяют бумажные документы с «живой» подписью. Однако корректность проверки такой подписи — это не просто техническая операция, а сложный криптографический и процедурный процесс, который может быть скомпрометирован как программными ошибками, так и человеческим фактором. Сбои, ошибки или преднамеренные манипуляции на этапе верификации могут привести к принятию недействительных заявок, отказам в исполнении обязательств, финансовым потерям и длительным судебным разбирательствам. Именно поэтому компьютерно-техническая экспертиза корректности проверки подписи электронной заявки становится критически важным инструментом для установления истины в спорах между контрагентами, операторами электронных площадок и удостоверяющими центрами. Данная статья представляет собой глубокое методологическое руководство по проведению такой экспертизы, охватывающее все этапы — от криптографического анализа до правовой интерпретации, и включает детализированные реальные кейсы.

🔐 Раздел 1: Криптографические основы электронной подписи и её роль в заявках

• 🔑 Электронная подпись реализуется на основе асимметричной криптографии, где каждый участник обладает парой ключей: закрытым (секретным) для создания подписи и открытым (публичным) для её проверки. В России ключевым документом является Федеральный закон № 63-ФЗ «Об электронной подписи», который устанавливает требования к сертифицированным ключам и средствам подписи. Для заявок, как правило, используется усиленная квалифицированная электронная подпись (КЭП), выданная аккредитованным удостоверяющим центром. Процесс проверки включает восстановление хеш-образа документа, расшифровку подписи открытым ключом и сравнение хешей. Любое отклонение — будь то изменение даже одного байта документа, невалидный сертификат или сбой в алгоритме — приводит к статусу «подпись недействительна». Эксперт обязан досконально знать алгоритмы ГОСТ Р 34.10-2012 (для формирования и проверки ЭП) и ГОСТ Р 34.11-2012 (функция хеширования), чтобы идентифицировать, на каком этапе произошла ошибка.

📂 Раздел 2: Структура электронной заявки и формат данных

• 📄 Электронная заявка представляет собой структурированный набор данных, обычно в формате XML, JSON или в виде PDF-документа, подписанного с применением откреплённой или прикреплённой подписи. В случае XML-заявок, подпись содержится в отдельном конверте или является частью документа (XMLDSig). Важно проверять не только основной текст заявки, но и все вложения, приложения, а также метаданные (дата, время, идентификаторы участников). Эксперт должен знать спецификации форматов XSD для каждой конкретной электронной площадки (например, для торгов по 44-ФЗ, для банковских систем), так как некорректный парсинг этих форматов является частой причиной ложного «несовпадения подписи».

🛠️ Раздел 3: Аппаратно-программное окружение для проверки подписи

• 💻 Проверка ЭП всегда выполняется в некоторой среде: это может быть серверное ПО оператора электронной площадки, десктопное приложение клиента, веб-интерфейс или мобильное приложение. Критически важен состав этого окружения: используемые библиотеки (CryptoPro CSP, VipNet CSP, OpenSSL), версии драйверов криптопровайдеров, сертификаты цепочки доверия (головной сертификат Минцифры, сертификат УЦ), списки отозванных сертификатов (CRL) и параметры времени (так как сертификат действителен в определённый период). Эксперт должен получить образ системного и программного окружения в момент проверки, чтобы воспроизвести условия и определить, не было ли сбоя из-за неправильного времени, устаревшего CRL или битой библиотеки.

🔍 Раздел 4: Методы восстановления последовательности проверки (Trace-логирование)

• 📜 Для анализа корректности эксперту необходим доступ к логам всех операций, связанных с подписанием и проверкой. В системах на базе Windows это могут быть журналы приложений, в Linux — системные логи, а также специализированные логи криптопровайдера. В сложных случаях проводится трассировка вызовов API криптографических функций (например, с помощью Process Monitor или API Monitor), чтобы увидеть каждое обращение к сертификатам, каждое вычисление хеша и каждое сравнение. Если система не ведёт детализированного логирования, это само по себе может быть признаком несоответствия регуляторным требованиям (приказ ФСБ № 796 и другие).

🕵️ Раздел 5: Проверка целостности подписанного документа (хеш-функция)

• 🧪 Первым шагом эксперта является независимое вычисление хеш-кода документа, полученного из системы (заявки), с использованием той же хеш-функции (ГОСТ 34.11-2012) и сравнение с хеш-значением, расшифрованным из подписи. Если хеши не совпадают, документ был изменён после подписания (либо намеренно, либо из-за ошибок кодирования, например, перекодировки в UTF-8 и ANSI). Эксперт проверяет, не было ли автоматического преобразования формата (добавление BOM, перевод строк) на сервере, которое нарушило целостность. Это одна из самых частых причин сбоев.

🔑 Раздел 6: Анализ валидности сертификата и цепочки доверия

• 📋 Сертификат ключа проверки подписи должен быть действителен на момент подписания (или на момент проверки, в зависимости от настроек). Эксперт проверяет: не истек ли срок действия сертификата, не отозван ли он (по CRL или OCSP), соответствует ли он субъекту (владельцу), выпущен ли он аккредитованным УЦ, прослеживается ли цепочка до корневого сертификата. Особое внимание уделяется «моменту времени» проверки — если системные часы были выставлены неверно (например, на несколько дней назад или вперёд), сертификат может быть признан недействительным даже при формальной корректности. Эксперт сверяет время подписи (из метки времени, если она есть) и время проверки.

🗣️ Раздел 7: Исследование квалифицированного сертификата и его расширений

📜 Квалифицированный сертификат имеет набор обязательных полей: уникальный номер, ИНН/СНИЛС владельца, ОГРН организации, область применения ключа (для подписи заявок это должен быть код 1.2.643.100.4.1 — усиленная квалифицированная подпись). Эксперт анализирует наличие и корректность этих расширений, проверяет, не были ли они модифицированы (это возможно только при перевыпуске). Если в сертификате отсутствует нужное расширение, система может выдать ошибку «подпись не предназначена для данного типа документа».

⏱️ Раздел 8: Оценка метки времени (timestamp) и её корректность

⏳ Многие системы требуют прикреплённой метки времени, чтобы зафиксировать момент подписания и гарантировать, что подпись была создана в момент действия сертификата. Эксперт проверяет, соответствует ли метка времени реальному времени подписания, а также проверяет сертификат службы времени (TSA). Если метка отсутствует или недействительна, это может стать основанием для отказа в признании подписи (особенно по 44-ФЗ, где время подачи заявки критично). Сравнивается время метки со временем в системных журналах — расхождение более 5 минут считается аномалией.

📡 Раздел 9: Анализ программных алгоритмов, используемых при проверке

⚙️ Реализация криптографических алгоритмов может быть некорректной из-за использования устаревших версий CryptoPro (например, версий, не поддерживающих новый ГОСТ Р 34.10-2021 для некоторых типов ключей). Эксперт идентифицирует версию криптопровайдера, проверяет наличие всех необходимых обновлений, а также проверяет, не использовались ли сторонние «обёртки» (типа Java Security Provider), которые могли внести ошибку при преобразовании типов данных. Воспроизведение проверки на эталонном стенде с теми же версиями ПО часто является ключевым методом.

🧩 Раздел 10: Проверка на соответствие регламентам электронной площадки

🏢 Каждая электронная торговая площадка (Сбербанк-АСТ, РТС-тендер, ЭТП ГПБ и др.) имеет свой регламент проверки подписи, который может включать дополнительные шаги: проверку полномочий представителя, аккредитацию участника, наличие права подписи на основании доверенности. Эксперт должен изучить этот регламент и сопоставить его с фактической последовательностью операций в системе. Часто сбой возникает именно на этапе проверки полномочий, а не криптографии.

🖥️ Раздел 11: Исследование клиентской стороны (рабочая станция заявителя)

🖱️ Подписание заявки происходит на компьютере заявителя, поэтому экспертиза включает анализ его рабочей станции: проверка наличия и корректности установленного сертификата в хранилище «Личные», проверка работы токена (Рутокен, eToken) или файлового ключа, наличие необходимых драйверов, отсутствие конфликтующего ПО (антивирусы, блокирующие криптографические операции). Также проверяется, не была ли скомпрометирована закрытая часть ключа (например, скопирована злоумышленником). Если на машине обнаружены признаки вредоносного ПО, это может ставить под сомнение действительность подписи (статья о «недобросовестной конкуренции»).

🧪 Раздел 12: Воспроизведение проверки в изолированной среде (эмуляция)

🔬 Эксперт создаёт изолированный стенд (виртуальная машина) с точным воспроизведением версий ОС, криптопровайдера, браузера и цепочки сертификатов, затем подаёт на вход ту же заявку и тот же сертификат. Если на эталонном стенде подпись проходит проверку, а в производственной системе — нет, значит проблема в конфигурации именно этой системы (например, неправильно настроен CRL). Если не проходит ни там, ни там — проблема в самой подписи или документе.

📊 Раздел 13: Анализ журналов событий удостоверяющего центра (УЦ)

🏛️ Удостоверяющий центр, выдавший сертификат, ведёт журналы выдачи и отзыва. Эксперт запрашивает у УЦ информацию о том, был ли сертификат на момент подписания действительным, не отозван ли он до или после, а также о параметрах генерации ключа (длина ключа, алгоритм). Это позволяет проверить, не был ли сертификат скомпрометирован. Если УЦ не предоставляет данные или они противоречивы, это может стать основанием для признания подписи недостоверной.

📄 Раздел 14: Юридическая квалификация статуса проверки

⚖️ Результат проверки подписи — это не просто технический бит («true» или «false»). Эксперт должен связать его с юридическими последствиями: если проверка не пройдена из-за ошибки системы оператора, то заявка не может считаться недействительной; если из-за несоответствия документа — то вина лежит на заявителе. Эксперт даёт квалификацию: ошибка программная, ошибка пользовательская, ошибка административная, либо злоумышленные действия.

📑 Раздел 15: Составление протокола разбора событий (хронология)

📅 Создается временная шкала всех действий: создание заявки, подписание, отправка, получение сервером, проверка, выдача статуса. Сопоставляются временные метки из системных журналов, журналов УЦ, меток времени. Любое расхождение более допустимого (обычно ±1 минута для синхронизации) фиксируется как потенциальная причина отказа.

🧩 Раздел 16: Оценка роли системных администраторов и операторов

🖥️ Иногда причина сбоя — человеческий фактор на стороне администратора: неправильное обновление CRL, отключение службы проверки, перезагрузка сервера в момент проверки. Эксперт анализирует действия администраторов по журналам аудита, и если обнаруживает, что отказ произошёл в момент технических работ, это может служить основанием для пересмотра результатов тендера.

💡 Раздел 17: Использование средств криптографической экспертизы (СКЗИ)

🔒 В рамках исследования применяются сертифицированные средства криптографической защиты информации (СКЗИ) — например, «КриптоПро CSP» или «ViPNet CSP». Эксперт проверяет, что использовались легальные версии с актуальными сертификатами ФСБ, и что они не были взломаны или модифицированы. Наличие нелицензионного ПО может дискредитировать результаты проверки.

📈 Раздел 18: Статистический анализ частоты ошибок проверки

📉 Если система выдаёт много отказов на подписи, которые внешне выглядят корректными, это может указывать на системную ошибку (баг). Эксперт собирает статистику за определённый период, сравнивает с другими площадками или аналогичными системами, и при выявлении аномалий (например, 30% отказов при среднем 2%) делает вывод о программном сбое.

🔐 Раздел 19: Проверка использования средств усиленной защиты (защищённый носитель)

🔑 В некоторых системах закрытый ключ хранится на защищённом носителе (токен), и проверка подписи требует PIN-кода или биометрии. Эксперт проверяет, была ли корректно аутентифицирована эта операция, не было ли подмены носителя. Если токен не был подключен или PIN не был введён, а подпись всё равно проверена — это явный признак ошибки.

📋 Раздел 20: Составление экспертного заключения и формулирование выводов

📝 Финальный документ должен содержать: вводную часть (на основании чего проведена экспертиза), описательную (методы, данные, стенды), синтезирующую (анализ всех источников) и выводы (однозначные ответы на поставленные судом вопросы). Выводы формулируются, например: «Подпись недействительна, поскольку документ был изменён после подписания» или «Подпись действительна, но проверка не прошла из-за устаревшего CRL на стороне оператора». Эксперт также даёт рекомендации по предотвращению подобных ошибок.

🟨 Раздел 21: Развернутые практические кейсы из деятельности Союза «Федерация судебных экспертов»

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

Кейс 1: Отказ в признании заявки на тендер из-за «некорректной подписи» (ошибка CRL)

🏢 Участник торгов по 44-ФЗ подал заявку на крупный контракт (более 50 млн рублей) через электронную площадку. Через несколько минут после окончания срока подачи система выдала отказ: «Проверка подписи не пройдена — сертификат отозван». Участник был уверен, что его сертификат действителен, и обратился в Союз «Федерация судебных экспертов».

Эксперты запросили у оператора площадки логи проверки, а также получили списки CRL из УЦ за тот день. Выяснилось, что в момент проверки система использовала CRL, который был загружен за 6 часов до события, и в этом списке действительно был указан серийный номер сертификата участника. Однако этот же сертификат был перевыпущен за день до подачи заявки, и старый серийный номер был занесён в CRL как отозванный, а новый — активный, но в том CRL его не было, так как обновление ещё не произошло. Эксперты также проверили время действия нового сертификата — оно перекрывало момент подписания. Они воспроизвели проверку на своём стенде с актуальным CRL, и подпись прошла успешно.

Вывод: отказ был вызван технической ошибкой оператора — несвоевременным обновлением CRL на сервере проверки. Суд обязал оператора признать заявку действительной и компенсировать участнику упущенную выгоду (разницу в цене контракта). Союз «Федерация судебных экспертов» указал, что оператор нарушил регламент обновления списков отзыва.

Кейс 2: Изменение кодировки документа при передаче — сбой в проверке хеша

📧 Страховая компания получила электронную заявку на страховую выплату с квалифицированной подписью от клиента. Система компании выдала ошибку: «Подпись не соответствует документу». Клиент настаивал, что подписывал именно этот файл. Эксперты Союза провели анализ исходного файла на компьютере клиента и файла, полученного системой.

Выяснилось, что в процессе отправки через веб-интерфейс страховой компании файл был перекодирован из UTF-8 в ANSI (Windows-1251) с добавлением символа «BOM» (Byte Order Mark) в начале. Это изменило хеш-образ документа на один байт, что привело к несовпадению с подписью, вычисленной исходно. Эксперты восстановили исходный файл, применили обратное преобразование, после чего подпись стала валидной. Дополнительно было обнаружено, что в регламенте страховой компании нет требования к кодировке, что является упущением.

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

Кейс 3: Использование недействительного сертификата с истекшим сроком действия

📅 Индивидуальный предприниматель подал заявку на участие в электронном аукционе, но получил отказ, так как система показала «Срок действия сертификата истёк». Предприниматель был уверен, что сертификат был перевыпущен и действует до следующего года. Он обратился в Союз «Федерация судебных экспертов».

Эксперты извлекли сертификат из токена предпринимателя и проверили его поля: срок действия действительно был до 01.01.2025, а подача заявки была 02.01.2025. Однако предприниматель предоставил сертификат, срок действия которого начинался с 02.01.2025 — это был новый сертификат, но он был записан в то же место хранилища, что и старый, и система подтянула старый (с истекшим сроком) из-за ошибки в приоритете выбора сертификатов в ПО. Эксперты проверили версию криптопровайдера: она была устаревшей и неправильно обрабатывала несколько сертификатов с одинаковым владельцем. На эталонном стенде с новой версией проблема не воспроизводилась.

Суд признал, что причиной отказа стала программная ошибка на стороне заявителя (использование устаревшего криптопровайдера), но поскольку заявитель не знал об этом, а рекомендации по обновлению не были явно предоставлены, суд обязал оператора площадки провести переторжку с его участием.

Кейс 4: Подмена закрытого ключа — злоумышленные действия контрагента

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

Эксперты Союза провели детальный анализ: изучили журналы доступа к токену директора, обнаружили, что за 2 дня до подписания было произведено клонирование закрытого ключа на другой носитель (по IP-адресу неизвестного сотрудника). Затем был проведён сравнительный анализ подписи: метка времени в заявке совпадала с моментом, когда директор находился в командировке за границей, а его токен лежал в сейфе. Также криптоанализ показал, что подпись была создана с использованием более старой версии CryptoPro, чем та, что была установлена у директора. Это указывало на то, что подпись была сгенерирована на другом компьютере, с использованием скопированного ключа. Эксперты подготовили заключение о том, что подпись формально корректна, но создана неустановленным лицом без ведома владельца, с нарушением правил хранения ключа.

Суд признал заявку недействительной, так как не была обеспечена защита ключа, и компания-получатель была обязана вернуть активы. Также были инициированы уголовные процедуры.

Кейс 5: Сбой часов на сервере оператора и ошибочный отказ по сроку сертификата

🕰️ Организация подала заявку на получение лицензии через портал госуслуг. Система выдала отказ, указав, что «сертификат не действует на момент проверки». Однако дата в заявке была 15.03.2025, а сертификат был действителен до 20.03.2025. Эксперты Союза «Федерация судебных экспертов» изучили системные логи сервера госуслуг и обнаружили, что часы сервера были сдвинуты на 2 дня вперёд (системное время было 17.03.2025 из-за ошибки синхронизации NTP после обновления). Из-за этого система считала, что сертификат уже истёк (так как по её времени было 17.03, хотя реально 15.03, и до истечения срока, как она «видела», оставалось менее 3 дней — она отклонила как «запоздалую»). Эксперты восстановили фактическую хронологию по внешним журналам УЦ и времени отправки заявки (зафиксированному на стороне клиента).

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

🔮 Заключительное слово и практические советы

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

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

Для заявителей: всегда сохраняйте локальные копии подписанных файлов и скриншоты успешного подписания. Используйте только актуальные версии криптопровайдеров и проверяйте срок действия сертификатов непосредственно перед отправкой. При получении отказа немедленно фиксируйте состояние системы (логи, экран) и обращайтесь к независимым экспертам, не полагаясь на устные объяснения оператора.

Союз «Федерация судебных экспертов» предлагает полный цикл компьютерно-технических экспертиз электронных подписей и систем проверки, включая выездное исследование серверного и клиентского окружения, воспроизведение проверок на стенде, криптоанализ и подготовку юридически безупречных заключений, принимаемых в судах всех уровней. Наши эксперты имеют сертификаты в области информационной безопасности и криптографии, что гарантирует высокое качество и надёжность выводов.

Полную контактную информацию, телефон и адрес офиса, а также более подробную информацию по вашему вопросу вы можете найти на нашем официальном сайте ✅ https://fse.ms/