Согласно п.1 ст.2 Федерального закона от 06.04.2011 № 63-ФЗ «Об электронной подписи», электронная подпись (ЭП) – это информация в электронной форме, которая присоединена к другой информации в электронной форме (подписываемой информации) или иным образом связана с такой информацией и которая используется для определения лица, подписывающего информацию.
Электронная подпись может быть простая (основана на использовании паролей и кодов для подтверждения подписания) или усиленная (формируется с использованием криптографического преобразования информации и позволяет обнаружить факт внесения изменений в данные после подписания). Усиленная ЭП, в свою очередь, делится:
-
по отношению к подписываемым данным: на присоединенную и отсоединенную;
-
по статусу удостоверяющего центра (УЦ), выдавшего сертификат: на квалифицированную (УКЭП) и неквалифицированную (УНЭП);
-
по виду используемого алгоритма: ГОСТ, RSA и пр.;
-
по составу включаемых в подпись данных существуют различные форматы: CMS, CAdES-BES, CAdES-T, CAdES-A и др.;
Рассмотрим, чем отличаются разные форматы усиленной ЭП.
Формат CMS (простая ЭП)
Формат CMS описан Международным стандартом 2009 года RFC 5652 (Cryptographic Message Syntax – CMS). Он используется для создания электронных подписей, шифрования и упаковки данных. В состав «простой» подписи CMS входят:
-
информация о подписываемых данных (хеш-значение);
-
алгоритм подписи;
-
значение подписи (результат криптографической операции над хеш-значением подписываемых данных, полученный с помощью указанного алгоритма с использованием закрытого ключа);
-
данные о подписывающем лице;
-
набор неподписываемых атрибутов, включая дату подписания.
Подписи такого формата формировались платформой «1С» до версии 8.3.20.
- ЭП формата CMS не содержит достоверных данных о дате подписания. Неподписанный атрибут с датой подписания может быть легко подделан. Поэтому после истечения срока сертификата на основании данных самой подписи нельзя доказать, что подпись была сформирована в период действия этого сертификата.
- В целом формат CMS можно считать устаревшим, в современных решениях он не используется.
- ЭП формата CMS стандартными средствами платформы «1С» нельзя преобразовать в другие форматы.
Формат CAdES-BES (базовая ЭП)
Стандарт CAdES (CMS Advanced Electronic Signatures) разработан на базе стандарта CMS (все описываемые далее форматы также созданы в соответствии с этим стандартом).
Различные форматы CAdES отличаются друг от друга наличием или отсутствием определенных атрибутов. Существует возможность усовершенствования ЭП, т.е. перевода из одного формата в другой путем добавления недостающих атрибутов.
Рис. 1. Форматы ЭП
В состав «базовой» подписи CAdES-BES (Basic Electronic Signature) входят все атрибуты, описанные в формате CMS, а также данные о сертификате подписывающего лица некоторые прочие служебные свойства.
-
«Базовая» подпись CAdES-BES не содержит достоверных данных о дате подписания, как и простая CMS. После истечения срока сертификата для доказательства того факта, что подпись сформирована в период действия сертификата, понадобятся дополнительные аргументы. По данным самой подписи доказать это невозможно.
-
Подпись CAdES-BES можно преобразовать в более сложные форматы, которые предполагают наличие меток времени для решения этой проблемы.
-
Подпись CAdES-BES используется по умолчанию во многих приложениях, в том числе в приложениях для работы с ЭДО.
-
Подпись CAdES-BES может использоваться по умолчанию при подписании в типовых решениях «1С» (наряду с CAdES-T и CAdES-A, регулируется настройкой).
Формат CAdES-T (ЭП с меткой доверенного времени)
Для того чтобы иметь в составе подписи достоверные данные о дате подписания, введено понятие «метка доверенного времени» («метка времени», «штамп времени», «TSP-ответ»). Согласно законодательству, метка доверенного времени – это достоверная информация в электронной форме о дате и времени подписания электронного документа (Федеральный закона от 06.04.2011 № 63-ФЗ, приказ Минцифры от 06.11.2020 №580).
Технически метка времени – это подпись, где в качестве подписанных данных выступают хеш базовой подписи и точное время формирования метки. Метку времени предоставляет специальная TSP-служба (Time Stamp Protocol). Для работы с квалифицированными подписями такая служба должна использовать сертифицированные программные средства формирования меток времени. Для работы с неквалифицированными подписями могут использоваться средства без такой сертификации, в том числе на базе open source решений.
Абстрактный смысл метки времени заключается в том, что сервис, которому мы доверяем, присылает подписанное подтверждение, что на строго определенный момент времени некие данные (в данном случае данные ЭП) находились в строго определенном состоянии.
Таким образом, сформировав хеш подписи, проверив, что он соответствует подписанному хешу в метке, и проверив подпись метки, можно убедиться, что с момента формирования метки подпись не менялась.
Если сертификат подписывающего лица уже истек, но подпись содержит действующую метку времени, по данным подписи можно достоверно выяснить, что она сформирована до истечения сертификата. Под действующей подразумевается метка, сертификат которой еще не истек. Срок действия сертификата метки тоже не бесконечный, но, как правило, TSP-службы используют специальные сертификаты с более длительными сроками действия, чем обычные (до 15 лет).
В состав подписи CAdES-T (Timestamp) входят все атрибуты CAdES-BES, а также атрибут signature-time-stamp с меткой времени.
-
Подпись CAdES-T содержит достоверные данные о дате подписания. Если сертификат истек, для доказательства, что подпись сформирована до его истечения, достаточно данных самой подписи.
-
Подпись CAdES-T не содержит информацию об отзывах сертификатов. По данным подписи нельзя доказать, что сертификат не был отозван на момент формирования подписи.
-
Подпись CAdES-T используется по умолчанию при работе с 1С-ЭДО.
- Подпись CAdES-T может использоваться по умолчанию при подписании в типовых решениях «1С» (наряду с CAdES-BES и CAdES-A, регулируется настройкой) если:
- Выполняется подписание ЭП любого формата с меткой времени, то TSP-службы, указанные в настройках программы, должны быть доступны с клиента и/или сервера «1С» (в зависимости от того, где выполняется подписание), иначе подписание завершится с ошибкой.
- По умолчанию в типовых решениях указываются следующие адреса: http://dss.1stdss.1c.ru/TSP/tsp.srf (поддерживается УЦ «1С») и http://uc.nalog.ru/tsp/tsp.srf (поддерживается УЦ ФНС).
Рис. 2. Выбор типа подписи при подписании файла в типовых решениях 1С
Формат CAdES-С
Подпись может содержать полную цепочку сертификатов – от сертификата подписывающего лица до сертификата его корневого УЦ, а также список отозванных сертификатов удостоверяющего центра на момент формирования ЭП. Эта информация может быть использована в будущем при проверке подписи.
Список отозванных сертификатов (список отзыва, Certificate Revocation List – CRL) доступен на открытых ресурсах удостоверяющего центра и содержит идентификаторы всех действующих отозванных сертификатов УЦ. Таким образом, если на момент подписания сертификат подписывающего лица не входит в актуальный список отзыва, это говорит о том, что он не был отозван.
Существует и другой способ определения факта отзыва сертификата – через протокол OCSP (Online Certificate Status Protocol). Клиент генерирует OCSP-запрос о статусе конкретного сертификата и отправляет его на сервер. OCSP-сервер получает этот запрос, проверяет статус сертификата на текущий момент, генерирует OCSP-ответ и отсылает его клиенту. Это более экономичный способ хранения информации об отзыве, т.к. вместо хранения полного списка отозванных сертификатов нужно сохранить только сообщение со статусом конкретного сертификата. Но на текущий момент этот способ еще не получил широкого распространения в нашей стране.
В состав подписи CAdES-C (Complete) входят все атрибуты CAdES-T, а также:
-
идентификаторы всех сертификатов цепочки до корневого УЦ;
-
идентификаторы списков отозванных сертификатов либо OCSP-ответ.
Эти данные в CAdES-C хранятся в неподписанном виде.
Формат CAdES-X Type 1, Type 2 (eXtended)
Добавляют к данным CAdES-C штамп времени, который заверяет информацию о сертификатах и списках отзыва. Отличие в том, что в Type 1 метка устанавливается на все данные CAdES-C, а в Type 2 – только на идентификаторы сертификатов и списков отзыва.
Формат CAdES-X Long
В отличие от CadES-C, хранит полные данные о сертификатах и списках отзыва, а не только идентификаторы. Это страхует в том числе от утери данной информации удостоверяющим центром.
Формат CAdES-X Long Type 1, Type 2
Хранят полные данные о сертификатах (как CAdES-X Long), заверенные меткой времени (как CAdES-X Type 1, Type 2).
Формат CAdES-A (архивная)
Формат CAdES-A предполагает хранение полных данных о сертификатах и отзывах, а также заверение данных дополнительными архивными метками времени. Существует несколько версий CAdES-A, наиболее полная из которых – CAdES-A v3. В состав подписи CAdES-A (Archive) v3 входят:
-
все атрибуты CAdES-BES;
-
опционально: атрибуты любых других версий, перечисленных выше (при усовершенствовании до формата CAdES-A все «старые» атрибуты сохраняются);
-
хеш-таблица сертификатов, списков отозванных сертификатов и неподписываемых атрибутов, содержащихся в подписи на момент архивации (перевода в формат CAdES-A);
-
архивные метки времени.
Формат CAdES-A предполагает добавление новых архивных меток в процессе хранения подписи. Это решает две проблемы:
-
проверяемость подписи после истечения срока действия сертификата предыдущей метки: если срок действия предыдущей метки подходит к концу, можно добавить новую метку, продлевая действие подписи до окончания действия сертификата новой метки;
-
защита от устаревания алгоритмов подписи: новые штампы могут использовать новые, более современные алгоритмы.
-
Подпись CAdES-A лучше всего подходит для долгосрочного хранения документов.
-
Подпись CAdES-A хранит подписанную информацию об отзывах, защищая от проблемы, актуальной, например, для формата CAdES-T. При его использовании, если данные об отзыве не хранятся в подписи, при автоматической проверке будет использован актуальный на момент проверки список отзыва. УЦ могут удалять сертификаты с истекшим сроком из актуального списка отзыва. Таким образом, истекший сертификат может быть признан действительным, хотя на момент подписания был отозван. При проведении более детальной экспертизы для проверки такой ЭП нужно искать список отзыва, актуальный на момент подписания.
-
Подпись CAdES-A защищает от устаревания алгоритмов подписи.
-
Подпись CAdES-A может занимать много места (зависит от размера списков отзыва, которые могут занимать десятки мегабайт, увеличивая размер файла подписи).
-
Подпись CAdES-A может использоваться по умолчанию при подписании в типовых решениях «1С» (наряду с CAdES-BES и CAdES-T, регулируется настройкой).
-
В «1С:Архиве» все подписи принятых документов преобразуются в формат CAdES-Av3. В процессе хранения «1С:Архив» добавляет новые архивные метки времени к подписям в тот момент, когда до истечения срока действия предыдущей архивной метки остается 1 год.
Рис. 3. Электронная подпись формата CAdES-A в «1С:Архиве»
Какой формат электронной подписи выбрать при подписании документов
Большинство типовых решений «1С» предлагают использовать один из трех форматов для подписания: CAdES-BES, CAdES-T, CAdES-A. Самый надежный вариант – это CAdES-A. Такая подпись содержит максимальное количество информации для обеспечения успешной проверки в любой момент. Однако стоит также учитывать:
- Доступность внешних сервисов. Если нет возможности обеспечить доступность TSP-служб и ресурсов УЦ сертификата подписывающего лица (CRL, OCSP), то формирование меток времени будет невозможно. Нужно использовать только CAdES-BES.
- Размер дискового пространства.CAdES-A может занимать на порядок больше места, чем другие варианты (зависит от размера актуального CRL конкретного удостоверяющего центра). Но могут быть ситуации, когда CAdES-BES занимает единицы килобайт, а при усовершенствовании до CAdES-A размер увеличивается до десятков мегабайт. Когда и если протокол OCSP получит более широкое распространение, эта проблема будет снята.
- Доказательства подлинности сертификата, не входящие в ЭП. При необходимости доказать подлинность подписи можно использовать не только сам файл ЭП, но и другую информацию. Например, ФНС присылает квитанции о принятии отчетности, которые могут служить доказательством, в том числе после истечения срока сертификата. В таких случаях может быть достаточно подписи CAdES-BES. Дополнительным доказательством могут также служить записи базы данных, технологические логи системы учета, переписка с контрагентом и т.д.
- Срок хранения документа. Если срок хранения документа не превышает срока действия сертификата подписывающего лица, можно рассмотреть использование CadES-BES. А если срок хранения документа менее 5 лет и риск утраты удостоверяющим центром информации о сертификатах и списках отзыва оценивается как несущественный, можно рассмотреть использование CAdES-T.
- Взаимодействие со сторонним ПО. Не все программы и сервисы поддерживают все перечисленные форматы ЭП. Более новые форматы поддерживает меньше программ. В частности, формат CAdES-A v3 не поддерживается в полной мере порталом «Госуслуги». При проверке такой подписи, сформированной в «1С», может быть выдан отрицательный результат, несмотря на то, что ЭП сформирована в полном соответствии со спецификацией. Эта проблема со временем будет становиться менее актуальной, но если планируются сценарии интеграции со сторонними системами, стоит заранее выяснить, какие форматы ЭП они поддерживают.
- Особенности УНЭП. В организации может быть прописан регламент хранения УНЭП, который подразумевает надежное хранение дополнительных данных об ЭП (дата подписания, сведения об отзывах сертификатов) особенным образом, без включения этой информации в файл ЭП. Этот регламент может быть прописан в соглашении между участниками документооборота. Тогда, в зависимости от конкретных деталей, подойдет CAdES-BES или CadES-T.
Для УНЭП используются алгоритмы, отличные от актуальных алгоритмов ГОСТ (например, алгоритм RSA). Важно убедиться, что TSP-службы, указанные в настройках, поддерживают выбранный алгоритм. Иначе при попытке формирования метки времени будут выдаваться ошибки. В таком случае придется использовать только CAdES-BES. TSP-службы, указанные в типовых конфигурациях по умолчанию, на текущий момент поддерживают только алгоритмы ГОСТ. Также стоит учитывать, что в законодательстве есть ограничения по видам документов, для которых допускается использование УНЭП, например, см. ст.22.3 ТК РФ.
- Идеал недостижим. Несмотря на то, что в большинстве случаев наиболее надежна CAdES-A, можно представить сценарии, где это не так. Например, контрагент обнаружил проблему и отозвал сертификат, УЦ пометил сертификат как отозванный. На следующий день мы проверяем подписанный документ. Если он был подписан CAdES-BES или CAdES-T, то для проверки отзыва сертификата будет запрошен актуальный CRL с сервера УЦ, проверка по нему покажет, что сертификат отозван, подпись неверна.
Если использовалась CAdES-A, для проверки будет использован CRL из самой подписи, который действовал на момент подписания. В нем еще не было нашего сертификата, т.к. он был отозван позже. Проверка покажет, что подпись верна. То есть в этой ситуации технически CAdES-A отработает правильно, но фактически поддельный документ будет признан верным из-за зазора по времени между компрометацией ключа и его отзывом.
В материале использованы фото: FAMILY STOCK / Shutterstock / Fotodom.
