Всем привет!
Эта заметка посвящена деталям проверок цифровых подписей: причинам, нормативным документам и реализации в SIGEX.
Тем, кого интересуют юридические подробности подтверждения легитимности электронных документов, рекомендуем обратить внимание на статью “Как предоставлять документы, подписанные электронной цифровой подписью, в суд”.
В первую очередь стоит разобраться с тем, что такое цифровая подпись. Закон “Об электронном документе и электронной цифровой подписи” вводит следующее определение:
16) электронная цифровая подпись – набор электронных цифровых символов, созданный средствами электронной цифровой подписи и подтверждающий достоверность электронного документа, его принадлежность и неизменность содержания;
На википедии в статье Электронная подпись приведено более развернутое определение:
ЭЦП — это реквизит электронного документа, полученный в результате криптографического преобразования информации с использованием закрытого ключа подписи и позволяющий проверить отсутствие искажения информации в электронном документе с момента формирования подписи (целостность), принадлежность подписи владельцу сертификата ключа подписи (авторство), а в случае успешной проверки подтвердить факт подписания электронного документа (неотказуемость).
Важно уточнить что фразу реквизит электронного документа не следует воспринимать в том смысле, что цифровая подпись становится частью электронного документа. В продолжении вышеупомянутой статьи описаны принципы формирования цифровых подписей из которых становится понятно что термин реквизит тут используется для того, чтобы явно ассоциировать цифровую подпись с документом, так как цифровую подпись вычисляют на основании содержимого документа.
Итак, электронная цифровая подпись может быть полезна для таких вещей, как подтверждение целостности электронного документа, подтверждение авторства и обеспечение неотказуемости.
Но сам по себе факт существования цифровой подписи некоего электронного документа мало о чем может сказать - ведь это бинарные данные и для их интерпретации необходимо программное обеспечение. Примерно так же как для интерпретации цифровых изображений необходимо программное обеспечение, которое сможет преобразовать цифровое представление изображения в картинку на экране. Но с цифровой подписью ситуация обстоит сложнее чем с цифровыми изображениями, так как содержащаяся в подписи информация не текстовая и не графическая. Цифровую подпись можно представить как значение переменной математической формулы. Другие переменные это преобразованное в числовой формат содержимое электронного документа и открытый криптографический ключ. Зная значения всех переменных возможно математически проверить выполняется ли формула. Это одна из проверок цифровой подписи. За деталями рекомендуем обратиться к вышеупомянутой статье на википедии.
До тех пор пока не будет выполнена проверка цифровой подписи нельзя быть уверенными ни в том, к какому электронному документу относится эта подпись, ни в том, кто подписывал документ. Таким образом можно заключить что в разрезе обеспечения значимости цифровой подписи ее проверка является не менее важной задачей, чем ее формирование.
Классический сценарий взаимодействия предполагает двух участников первый из которых готовит цифровой документ, подписывает его и передает его второму участнику. Второй участник хочет убедиться в том, что документ не был изменен в процессе передачи, а так же в том, что именно первый участник его составил и подписал. Для этого он выполняет проверку переданной вместе с электронным документом цифровой подписи. Так как проверка цифровой подписи, как было описано выше, не может быть выполнена человеком вручную, то обоим участникам необходимо иметь идентичное, либо совместимое программное обеспечение установленное на своих рабочих местах.
При этом нужно понимать что участники доверяют проверку цифровой подписи программному обеспечению, в значительной степени на него полагаются. В том случае, если программное обеспечение разработано не добросовестно, либо работает некорректно, либо было модифицировано компьютерным вирусом или вредоносным программным обеспечением, то оно может выдавать положительный результат проверки даже тогда, когда он на самом деле отрицательный. Это, в купе с тем, что участники могут не быть квалифицированными специалистами в области информационных технологий и с тем, что обслуживанием их рабочих мест может вообще никто не заниматься, то есть на них может присутствовать сомнительное нелицензионное программное обеспечение, может внушать сомнения в возможности установления доверия между участниками взаимодействия.
Стоит уточнить что обмен цифровыми подписями в таком сценарии достаточно сложен: помимо того что каждый участник должен передать свою подпись всем остальным участникам, каждый участник должен убедиться в том, что он получил подписи всех остальных участников и проверил их. Если участников, к примеру, пятеро, то каждый из этих пяти участников должен проверить четыре подписи остальных участников.
Современные сценарии, зачастую, отличаются от классических тем, что они не одноранговые, а клиент-серверные. То есть вместо того, чтобы взаимодействовать напрямую друг с другом, участники взаимодействуют с выделенным сервером. Их можно разделить на два случая:
SIGEX устроен вторым способом - при попытке добавления электронной подписи к зарегистрированному документу сервис выполняет необходимые проверки и добавляет подпись только в том случае, если проверки прошли успешно.
После того, как один из участников зарегистрировал цифровую подпись документа в SIGEX, остальным участникам уже не обязательно выполнять проверки самостоятельно, им достаточно убедиться в том что сервис принял эту подпись.
Участники взаимодействия в любом случае доверяют выполнение проверок цифровых подписей программному обеспечению. Разница заключается в том что либо это программное обеспечение размещено на локальных рабочих станциях, либо на централизованном сервере, обслуживанием которого занимаются квалифицированные специалисты.
В Приказе Министра по инвестициям и развитию Республики Казахстан “Об утверждении Правил проверки подлинности электронной цифровой подписи” указаны следующие проверки, которые необходимо выполнить для того, чтобы электронный документ был признан равнозначным документу, подписанному собственноручной подписью:
Так же в Приказе упоминаются две дополнительные проверки необязательные для признания юридической значимости документа:
Далее мы разберем каждую из перечисленных проверок по отдельности.
Речь идет о криптографической проверке цифровой подписи, той, о которой мы упоминали в начале данной заметки.
Механизм выполнения этой проверки для разных криптографических алгоритмов может отличаться. Тот механизм, который описан в Приказе, подходит для RSA. Для ГОСТ 34.310 он немного отличается, общее представление можно получить из статьи про российский ГОСТ 34.10.
Важный нюанс заключается в том, что в Приказе рассмотрен механизм проверки не упакованной в CMS подписи. Текущая реализация NCALayer - предоставляемого НУЦ инструмента для интеграции ЭЦП в веб приложения, не предоставляет функционала для формирования не упакованных в CMS подписей для произвольных данных, судя по документации рекомендуется применять упакованную в CMS подпись. Этот подход позволяет применять готовые международные наработки для упаковки и хранения цифровых подписей, а не изобретать что-то свое.
Отличие в обработке CMS подписей заключается в том, что в этом случае цифровая подпись вычисляется не от хеш-значения документа, а от хеш-значения специального блока данных CMS, которое, в свою очередь, включает в себя хеш-значение документа.
В случае не упакованной в CMS подписи вычисление подписи осуществляется следующим образом:
В случае упакованной в CMS подписи вычисление подписи осуществляется следующим образом:
Процедуры проверки подписи отличаются подобным образом, нужно просто заменить последний шаг с вычисления цифровой подписи из хеш-значения и закрытого ключа на проверку цифровой подписи на основании хеш-значения, открытого ключа и цифровой подписи.
Стоит упомянуть то, что в CMS подпись так же может быть упакован и сам электронный документ, но этот случай мы рассматривать не будем в связи с тем, что такие CMS подписи получаются достаточно большими и извлекать из них электронные документы проблематично так как для этого необходимо специализированное программное обеспечение.
Сертификат открытого ключа (регистрационное свидетельство), помимо данных о субъекте сертификата и открытого ключа, обычно включает в себя данные о сроке действия этого сертификата. Срок действия сертификата устанавливает удостоверяющий центр во время выпуска сертификата. Обычно началом срока действия сертификата является момент его выпуска, окончание устанавливается через регламентированный промежуток времени, к примеру, через год с момента выпуска.
В процессе проверки цифровой подписи информационная система должна убедиться в том, что срок действия сертификата еще не истек, а так же в том, что он уже наступил, так как такое тоже может случиться.
Для тех случаев, когда действие сертификата (регистрационного свидетельства) необходимо досрочно прекратить, в инфраструктуре открытых ключей предусмотрена возможность отзыва сертификатов по требованию субъекта сертификата (либо в другом порядке предусмотренном регламентом удостоверяющего центра). Для этого субъект (либо кто-то, кто имеет подобные полномочия) должен обратиться в удостоверяющий центр с просьбой отозвать сертификат.
Так как сертификат (регистрационное свидетельство) - это просто набор данных (файл) то может существовать неограниченное количество его копий на разных серверах, рабочих станциях, мобильных устройствах, в облаках и тому подобном. Очевидно что удостоверяющий центр не может заставить этот сертификат удалиться везде. Поэтому вместо того, чтобы пробовать уничтожить все существующие копии сертификата, удостоверяющий центр хранит реестр отозванных, но не истекших сертификатов.
В процессе проверки цифровой подписи информационная система должна убедиться в том, что сертификат отсутствует в списке отозванных сертификатов. На самом деле процедура несколько сложнее, за деталями можно обратиться к соответствующему разделу RFC 5280.
Существует два общепринятых способа проверки наличия сертификата в списке отозванных:
У CRL есть существенное ограничение - так как это файл и он может быть достаточно большим, то он формируется с определенной периодичностью: раз в день или раз в несколько часов. Информационные системы обычно не перекачивают весь этот файл каждый раз когда выполняют проверки, они хранят его в течении срока действия этого текущего CRL. Получается что при использовании CRL новость о том, что определенный сертификат был отозван, может поступить в информационную систему с большой задержкой.
В некоторой степени решить эту проблему позволяет Delta CRL - это разностные CRL файлы, которые хранят в себе только изменения произошедшие с момента публикации последнего полного CRL. Но их формируют так же с интервалом и так же кешируют на стороне информационных систем, так что задержка остается.
Еще одним минусом является то, что информационной системе приходится перекачивать CRL в любом случае - независимо от того, нужно ли ей будет проверять состояние сертификатов и сколько проверок будет нужно выполнить. То есть даже в том случае, если информационная система обычно в день проверяет статус 100 сертификатов, ей все равно нужно будет постоянно перекачивать весь CRL который может содержать информацию о миллионах сертификатов.
В качестве преимущества можно упомянуть некоторую степень автономности, которую предоставляет CRL - в том случае, если CRL скачан и срок его действия еще не вышел, то связь с сервером удостоверяющего центра не обязательна. Но чаще всего информационным системам нужны и другие онлайн сервисы удостоверяющего центра, так что этим преимуществом не всегда получается пользоваться.
Как уже упоминалось выше, OCSP позволяет запросить у удостоверяющего центра информацию о текущем состоянии определенного сертификата. Очевидные преимущества:
Казалось бы на этом тему проверки состояния сертификата субъекта можно закрывать, но есть один нюанс который, зачастую, остается без внимания. Дело в том, что и файл CRL и пакеты OCSP - это электронные документы подписанные цифровыми подписями. Подписывают их либо сертификатом самого удостоверяющего центра, либо специальными сертификатами выпущенными удостоверяющим центром для служб CRL и OCSP. А это значит что и для них необходимо выполнять полный набор проверок:
В данном случае принято пропускать проверку отозванности сертификатов служб CRL и OCSP, так как ответы были бы подписаны теми же службами, что привело бы к зацикливанию.
До того как эти проверки будут выполнены, доверять информации в CRL и OCSP нельзя, так как их передают, зачастую, по незащищенным каналам связи и злоумышленники могут организовать атаку человек посередине.
В Приказе приведено следующее пояснение к данной проверке:
Проверка заключается в проверке значения поля регистрационного свидетельства "использование ключа" (KeyUsage). Значения "Цифровая подпись" и "Неотрекаемость", содержащиеся в поле "использование ключа", означают что, это регистрационное свидетельство используется для ЭЦП. Значения "Цифровая подпись" и "Шифрование ключей", содержащиеся в поле "использование ключа", означают что, это регистрационное свидетельство используется для аутентификации;
Фактически информационная система должна удостовериться в том, что в расширении сертификата KeyUsage установлены флаги digitalSignature и nonRepudiation. В том случае, если один из этих флагов не установлен, то данный сертификат не предназначен для цифровой подписи и информационная система не должна принимать подписанные данные.
Расширение сертификата Certificate Policies содержит информацию о том, на основании какой политики удостоверяющий центр выпустил данный сертификат. Перечень политик и правила выпуска сертификатов по каждой из них описаны в регламентирующих документах удостоверяющего центра. В случае Национального удостоверяющего центра эта информация доступна в документе Правила применения регистрационных свидетельств подписчиков Национального удостоверяющего центра Республики Казахстан который можно найти на портале НУЦ в разделе Документация. В частности в подразделе 7.1.СТРУКТУРА РЕГИСТРАЦИОННОГО СВИДЕТЕЛЬСТВА ПОДПИСЧИКА НУЦ РК приведены структуры всех выпускаемых сертификатов, информацию о политике можно найти в поле Ceritifcate Policy структуры каждого сертификата. Сама политика тут указана в виде OID (объектного идентификатора), за текстовым представлением можно обратиться в реест OID РК.
Политика выпуска сертификата позволяет информационной системе лучше разобраться с тем, подходит ли использованный сертификат для подписания данного документа. К примеру в том случае, если информационная система ожидает что документ должен быть подписан представителем юридического лица, то ей следует принимать только подписи, которые были сформированы с использованием сертификатов выпущенных по политике 1.2.398.3.3.2.1 Политика применения регистрационных свидетельств электронной цифровой подписи юридических лиц Республики Казахстан.
В Приказе отдельно упоминается о том, что сертификаты информационной системы “Казначейство-клиент” разрешено применять только в информационной системе “Казначейство-клиент”, в реестре OID РК эти политики выглядят следующим образом:
Сертификат (регистрационное свидетельство) - это электронный документ включающий в себя цифровую подпись, подписание выполняет удостоверяющий центр используя для этого свой собственный сертификат. Детальнее об этом можно почитать в статье про инфраструктуру открытых ключей.
Обычно информационная система настроена на доверие ограниченному количеству удостоверяющих центров. Их называют доверенными корневыми удостоверяющими центрами. В Республике Казахстан существует Корневой удостоверяющий центр Республики Казахстан. Зачастую корневые удостоверяющие центры не выпускают сертификатов конечным пользователям, они выпускают сертификаты промежуточных удостоверяющих центров, примером такого удостоверяющего центра может служить Национальный удостоверяющий центр РК.
Таким образом для того, чтобы удостовериться в том, что сертификату конечного пользователя можно доверять, информационной системе необходимо построить цепочку доверия, к примеру:
Корневой доверенный сертификат КУЦ -> промежуточный сертификат НУЦ -> сертификат конечного пользователя
Процедура построения цепочки сертификатов описана в соответствующем разделе RFC 5280. Процедура достаточно сложная, с многими нюансами, помимо других моментов она включается в себя:
issuer текущего сертификата с полем subject сертификата выпустившего текущий сертификата;Протокол TSP позволяет получить метку времени от доверенного источника подтверждающую существование определенного блока данных на текущий момент времени. Такая метка может использоваться в дальнейшем для доказательства того, что определенный документ уже был подписан в определенный момент времени. Проще говоря метка времени позволяет фиксировать момент подписания электронного документа.
Для использования меток времени информационной системе следует в момент получения цифровой подписи связаться с сервером меток времени и получить от него метку времени для данной подписи. Либо можно требовать от клиента чтобы он присылал метку времени вместе с подписью. Так как метка времени, опять же, является электронным документом с цифровой подписью сервера меток времени, то эту цифровую подпись необходимо проверить - построить цепочку сертификатов, проверить сроки действия, списки отзыва и т.д.
Важным нюансом является то, что одной метки времени не достаточно для того, чтобы в будущем проверить цифровую подпись, так как сертификат может быть отозван на следующий день после подписания. В этом случае все те подписи, которые были сформированы до момента отзыва должны остаться валидными а все те, которые были сформированы после момента отзыва не должны проходить проверки. Для того, чтобы соблюсти это условие, информационная система должна так же собрать доказательства того, что сертификат не был отозван на момент указанный в метке времени. В качестве доказательства может использоваться CRL или OCSP ответ. Этот нюанс и рекомендации по реализации описаны в разделе APPENDIX B - Placing a Signature At a Particular Point in Time документа RFC 3161.
Полномочия в терминологии НУЦ - это специальные OIDы (объектные идентификаторы) которые могут присутствовать в расширении Extended Key Usage некоторых сертификатов. С тем какие OIDы полномочий могут присутствовать в сертификатах, выпущенных в соответствии с какими политиками, можно ознакомиться в документе Правила применения регистрационных свидетельств подписчиков Национального удостоверяющего центра Республики Казахстан который можно найти на портале НУЦ в разделе Документация. В частности в подразделе 7.1.СТРУКТУРА РЕГИСТРАЦИОННОГО СВИДЕТЕЛЬСТВА ПОДПИСЧИКА НУЦ РК приведены структуры всех выпускаемых сертификатов, полномочия описаны в поле Extended Key Usage.
К примеру в подразделе 7.1.5.Структура регистрационного свидетельства пользователя (юридическое лицо) Национального удостоверяющего центра Республики Казахстан (для подписи) указаны следующие возможные полномочия:
1.2.398.3.3.4.1.2.1 - Первый руководитель юридического лица, имеющий право подписи
1.2.398.3.3.4.1.2.2 - Лицо, наделенное правом подписи
1.2.398.3.3.4.1.2.3 - Лицо, наделенное правом подписи финансовых документов
1.2.398.3.3.4.1.2.4 - Сотрудник отдела кадров, наделенный правом подтверждать заявки на выпуск регистрационных свидетельств поданные от сотрудников юридического лица
1.2.398.3.3.4.1.2.5 - Сотрудник организации
OIDы полномочий присутствуют в реесте OID РК.
Информационная система может использовать перечисленные в сертификате полномочия для того, чтобы определить обладает ли субъект необходимыми полномочиями для подписания электронного документа.
Обсуждать последствия некорректной криптографической проверки подписи (проверки ЭЦП в электронном документе) особого смысла нет, очевидно что это приведет к полностью неработоспособной системе. Вероятно по этой причине в статье 10 3-ей главы Закона “Об электронном документе и электронной цифровой подписи” приведено требование к аккредитации удостоверяющих центров, в рамках которой требуется сертификация средств криптографической защиты информации к которым относятся криптографические библиотеки.
На первый взгляд ошибки при проверке срока действия регистрационного свидетельства не очень страшны - ведь закрытый ключ все равно находится у субъекта сертификата. Но, так как сертификаты нужно постоянно обновлять в связи с окончанием срока их действия, то за время своей жизни современный гражданин Республики Казахстан может получить десятки сертификатов. К сожалению не все относятся с надлежащей ответственностью к сохранности своих конфиденциальных данных. Некоторые в связи с недостаточной осведомленностью, другие просто небрежны. Все это приводит к тому, что вероятность получения злоумышленником доступа к какому-либо закрытому ключу растет. Это дополнительная причина по которой критически важно определять актуален ли сертификат открытого ключа или уже нет. Основная причина - это то, что не выполнение этой проверки лишает электронный документ юридической значимости.
Отзыв сертификатов (регистрационных свидетельств) может быть связан как с административной необходимостью (к примеру сотрудник уволился из организации), так и с проблемами с безопасностью (к примеру утерей защищенного носителя ключевой информации с наклеенным на него ПИН кодом) и с другими неожиданными ситуациями. Чаще всего неспособность информационной системы вовремя среагировать на отзыв сертификата (проверка регистрационного свидетельства на отозванность (аннулирование)) повлечет за собой то, что информационная система воспримет подписанный электронный документ как легитимный юридически значимый, в то время как он мог быть подписан либо человеком уже не занимающим свою должность, либо злоумышленником получившим доступ к закрытому ключу жертвы. Последствия могут быть более чем печальными, так как этим документом может быть, к примеру, договор купли-продажи имущества, либо доверенность на управление юридическим лицом.
Неспособность удостовериться в том, что в сертификате установлены корректные флаги расширения использования ключа, то есть выполнить проверку области использования ЭЦП регистрационного свидетельства, опять же приведет к тому, что фактически не легитимный документ будет воспринят системой как легитимный. Вероятность злого умысла в данном случае не очень высока, скорее всего произошла ошибка, но в том случае, если документ необходимо будет предоставить для разбирательства, к примеру, в суд, то могут возникнуть вопросы о том по какой причине информационная система некорректно уведомила пользователей о значимости документа.
Подобное случится и в случае проблем с проверкой номера политики регистрационного свидетельства и разрешенных способах его использования.
Некорректное построение цепочки сертификатов может предоставить злоумышленникам широкий простор для деятельности, так как в этом случае злоумышленнику не нужно будет похищать закрытый ключ. Все, что ему нужно сделать, это выпустить поддельный сертификат пользователя самостоятельно так, чтобы информационная система восприняла его как выпущенный доверенным удостоверяющим центром. К примеру в том случае, если информационная система сверяет поля subject и issuer, но не проверяет подпись под проверяемым сертификатом, то злоумышленник может создать сертификат пользователя в котором в поле issue укажет содержимое поля subject доверенного удостоверяющего центра а подпись добавит произвольную. Такая информационная система воспримет подготовленный злоумышленником сертификат как легитимный сертификат выпущенный удостоверяющим центром и, соответственно, будет принимать подписанные злоумышленником электронные документы.
В разрезе проверки метки времени информационная система может допускать следующие ошибки:
Некорректное выполнение проверки полномочий лица подписавшего документ, хоть и не относится к проверкам, необходимым к признанию юридической значимости документа, все-таки может негативно сказаться на бизнес процессах, так как информационная система не сможет определить того, что вместо первого руководителя организации документ был подписан обычным сотрудником.
Для выполнения криптографической проверки подписи сервис SIGEX использует сертифицированные библиотеки из состава SDK Национального удостоверяющего центра Республики Казахстан. Благодаря этому мы можем быть уверенными в том что используем точно те же реализации криптографических алгоритмов, которые использует удостоверяющий центр.
В процессе регистрации новой цифровой подписи сервис выполняет следующие действия:
Последующие проверки цифровой подписи инициированные пользователями информационной системы включают в себя следующие действия:
Таким образом мы можем утверждать что сервис SIGEX выполняет все необходимые проверки для того, чтобы выполнялось следующее положение Приказа Министра по инвестициям и развитию Республики Казахстан “Об утверждении Правил проверки подлинности электронной цифровой подписи”:
8. При удостоверении (установлении) подлинности ЭЦП с использованием СКЗИ удостоверяющего центра после проведения процедуры проверки ЭЦП (определен положительный результат проверки ЭЦП и регистрационного свидетельства), а также при соответствии условиям согласно подпунктам 2), 3) и 4) пункта 1 статьи 10 Закона, электронный документ, полученный посредством информационной системы, признается равнозначным документу, подписанному собственноручной подписи с одинаковыми юридическими последствиями.
Благодарим вас за внимание!
Портал SIGEX использует файлы cookie и другие технологии хранения данных в браузере только для персонализации пользовательского опыта: отображения уведомлений, напоминаний и подсказок, а так же хранения некоторых настроек. Мы не используем этих технологий для слежения за своими пользователями, сбора о них информации или отображения рекламы и не предоставляем подобных возможностей третим сторонам. Детали изложены в Политике конфиденциальности.
Мы проводим вебинары про электронные документы, ЭЦП и юридическую значимость.