Электронная подпись (ЭП) — это «информация в электронной форме, которая присоединена к другой информации в электронной форме (подписываемой информации) или иным образом связана с такой информацией и которая используется для определения лица, подписывающего информацию».
Существует деление на простую и усиленную электронную подпись:
- Простая основана на использовании паролей и кодов для подтверждения подписания.
- Усиленная формируется с использованием криптографического преобразования информации и позволяет обнаружить факт внесения изменений в данные после подписания.
Усиленная ЭП, в свою очередь, делится:
- По отношению к подписываемым данным: на присоединенную и отсоединенную.
- По статусу удостоверяющего центра (УЦ), выдавшего сертификат: на квалифицированную и неквалифицированную. УКЭП — усиленная квалифицированная подпись, УНЭП — усиленная неквалифицированная подпись. Описанная ниже информация в основном актуальна для обеих, но о некоторых особенностях УНЭП расскажем отдельно.
- По виду используемого алгоритма: ГОСТ, RSA и пр.
- По составу включаемых в подпись данных. Существуют различные форматы: CMS, CAdES-BES, CAdES-T, CAdES-A и др.
В рамках этой статьи рассмотрим отличия различных форматов усиленной ЭП.
CMS (простая)
Международный стандарт 2009 года RFC 5652 (Cryptographic Message Syntax — CMS) описывает формат CMS, который используется для создания электронных подписей, шифрования и упаковки данных.
В состав «простой» подписи CMS входят:
- Информация о подписываемых данных (хеш-значение).
- Алгоритм подписи.
- Значение подписи — результат криптографической операции над хеш-значением подписываемых данных, полученный с помощью указанного алгоритма с использованием закрытого ключа.
- Данные о подписывающем лице.
- Набор неподписываемых атрибутов, включая дату подписания.
Подписи такого формата формировались платформой «1С» до версии8.3.20.
- Такая подпись не содержит достоверных данных о дате подписания. Неподписанный атрибут с датой подписания может быть легко подделан. Поэтому после истечения срока сертификата на основании данных самой подписи нельзя будет доказать, что подпись была сформирована в период действия этого сертификата.
- В целом, формат CMS можно считать устаревшим, в современных решениях он не используется.
- Такую подпись нельзя стандартными средствами платформы «1С» преобразовать в другие форматы.
CAdES-BES (базовая)
На базе стандарта CMS был разработан стандарт CAdES (CMS Advanced Electronic Signatures). Все описываемые далее форматы созданы в соответствии с этим стандартом.
Различные форматы CAdES отличаются друг от друга наличием или отсутствием определенных атрибутов. Существует возможность усовершенствования ЭП,
В состав «базовой» подписи CAdES-BES (Basic Electronic Signature) входят все атрибуты, описанные в формате CMS, а также:
- Данные о сертификате подписывающего лица.
- Некоторые прочие служебные свойства.
- Такая подпись не содержит достоверных данных о дате подписания, как и простая CMS. После истечения срока сертификата для доказательства того факта, что подпись сформирована в период действия сертификата, по-прежнему понадобятся дополнительные аргументы. По данным самой подписи доказать это будет невозможно.
- Но такую подпись можно преобразовать в более сложные форматы, которые предполагают наличие меток времени для решения этой проблемы.
- Используется по умолчанию во многих приложениях, в том числе в приложениях для работы с ЭДО.
- Может использоваться по умолчанию при подписании в типовых решениях «1С» (наряду с CAdES-T и CAdES-A, регулируется настройкой).
CAdES-T (с меткой доверенного времени)
Для того чтобы иметь в составе подписи достоверные данные о дате подписания, было введено понятие «метка доверенного времени» («метка времени», «штамп времени», «TSP-ответ»).
Согласно законодательству, метка доверенного времени — это достоверная информация в электронной форме о дате и времени подписания электронного документа.
Технически метка времени — это подпись, где в качестве подписанных данных выступают хеш базовой подписи и точное время формирования метки. Метку времени предоставляет специальная TSP-служба (Time Stamp Protocol). Для работы с квалифицированными подписями такая служба должна использовать сертифицированные программные средства формирования меток времени. Для работы с неквалифицированными подписями могут использоваться средства без такой сертификации, в том числе на базе open source решений.
Абстрактный смысл метки времени заключается в том, что сервис, которому мы доверяем, присылает подписанное подтверждение того, что на строго определенный момент времени некие данные (в данном случае данные ЭП) находились в строго определенном состоянии.
Таким образом, сформировав хеш подписи, проверив, что он соответствует подписанному хешу в метке, и проверив подпись метки, можно убедиться, что с момента формирования метки подпись не менялась.
Если сертификат подписывающего лица уже истек, но подпись содержит действующую метку времени, по данным подписи можно достоверно выяснить, что она была сформирована до истечения сертификата. Под действующей подразумевается метка, сертификат которой еще не истек. Срок действия сертификата метки тоже не бесконечный, но, как правило, TSP-службы используют специальные сертификаты с более длительными сроками действия, чем обычные (до 15 лет).
В состав подписи CAdES-T (Timestamp) входят все атрибуты CAdES-BES, а также:
- Атрибут signature-time-stamp с меткой времени.
- Подпись содержит достоверные данные о дате подписания. Если сертификат истек, для доказательства того, что подпись сформирована до его истечения, достаточно данных самой подписи.
- Но подпись не содержит информацию об отзывах сертификатов. По данным подписи не получится доказать, что сертификат не был отозван на момент формирования подписи.
- Используется по умолчанию при работе с 1С-ЭДО.
- Может использоваться по умолчанию при подписании в типовых решениях «1С» (наряду с CAdES-BES и CAdES-A, регулируется настройкой).
- Если выполняется подписание ЭП любого формата с меткой времени, то TSP-службы, указанные в настройках программы, должны быть доступны с клиента и/или сервера «1С» (в зависимости от того, где выполняется подписание). В противном случае подписание завершится с ошибкой.
- По умолчанию в типовых решениях указываются следующие адреса:
- http://dss.1stdss.1c.ru/TSP/tsp.srf (поддерживается УЦ «1С»);
- http://uc.nalog.ru/tsp/tsp.srf (поддерживается УЦ ФНС).
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 v3. В состав подписи CAdES-A (Archive) v3 входят:
- Все атрибуты CAdES-BES.
- Опционально: атрибуты любых других версий, перечисленных выше. При усовершенствовании до формата CAdES-A все «старые» атрибуты сохраняются.
- Хеш-таблица сертификатов, списков отозванных сертификатов и неподписываемых атрибутов, содержащихся в подписи на момент архивации (перевода в формат CAdES-A).
- Архивные метки времени.
Главная особенность заключается в том, что этот формат предполагает добавление новых архивных меток в процессе хранения подписи. Это решает две проблемы:
- Проверяемость подписи после истечения срока действия сертификата предыдущей метки: если срок действия предыдущей метки подходит к концу, можно добавить новую метку, продлевая действие подписи до окончания действия сертификата новой метки.
- Защита от устаревания алгоритмов подписи: новые штампы могут использовать новые, более современные алгоритмы.
- Такая подпись лучше всего подходит для долгосрочного хранения документов.
- Хранит подписанную информацию об отзывах, защищая от проблемы, актуальной, например, для CAdES-T:
- Если данные об отзыве не хранятся в подписи, при автоматической проверке будет использован актуальный на момент проверки список отзыва. УЦ могут удалять сертификаты с истекшим сроком из актуального списка отзыва. Таким образом, истекший сертификат может быть признан действительным, хотя на момент подписания он был отозван.
При проведении более детальной экспертизы для проверки такой ЭП нужно будет искать список отзыва, актуальный на момент подписания.
- Если данные об отзыве не хранятся в подписи, при автоматической проверке будет использован актуальный на момент проверки список отзыва. УЦ могут удалять сертификаты с истекшим сроком из актуального списка отзыва. Таким образом, истекший сертификат может быть признан действительным, хотя на момент подписания он был отозван.
- Защищает от устаревания алгоритмов подписи.
- Может занимать много места. Это зависит в первую очередь от размера списков отзыва, которые могут занимать десятки мегабайт, увеличивая размер файла подписи на порядки.
- Может использоваться по умолчанию при подписании в типовых решениях «1С» (наряду с CAdES-BES и CAdES-T, регулируется настройкой).
- В «1С:Архиве» все подписи принятых документов преобразуются в формат CAdES-Av3. В процессе хранения «1С:Архив» добавляет новые архивные метки времени к подписям в тот момент, когда до истечения срока действия предыдущей архивной метки остается 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 отработает правильно, но фактически поддельный документ будет признан верным из-за зазора по времени между компрометацией ключа и его отзывом.
Комментарии