Мобильный АРМ для iPad от ЭОС работает с ЭЦП на любой версии iOS – CNews

Использование простой электронной подписи в документах

Цель написания статьи – популяризировать использование

Простой электронной подписи

(пЭП) в документах. Чем больше людей пользуется, тем более популярен механизм, тем меньше у всех страхов, подозрений и вопросов. Очень удобно, подписал счет и акты пЭП и передал по email в бухгалтерию контрагента.

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

Более того, при наличии своего сервиса проверки, пЭП гарантирует достоверность подписи, в отличии от собственноручной подписи. Например третьему лицу, взявшему в руки документ, неизвестно, закорючка напротив ФИО это реальная подпись того человека или нет. А здесь зашел на указанный сервис, вбил номер подписи и ты точно знаешь, что именно данный документ подписал именно данный человек.

Как сделать такой сервис проверки, и как организовать свою пЭП и будет описано в данной статье.

PS: Данный способ не подходит для подписи счет-фактур. По счету-фактуре установлены жесткие требования — подпись либо живая, либо ЭП у оператора. А счет, акт и т.п. можно.

Комментарий юриста по данному поводу: “По счету-фактуре установлены жесткие требования — подпись либо живая, либо ЭП у оператора.
Была даже в свое время практика, можно ли подписывать сф факсимиле, вроде как примерно то же, что и живая подпись.
Суды сказали нельзя.
С ЭП будет то же самое. Слишком много бюджет теряет из-за сф
.”

Сначала немного законодательной теории.

Наше законодательство однозначно определяет условия признания электронных документов, подписанных простой электронной подписью, равнозначными документам на бумажном носителе, подписанным собственноручной подписью. Это определяется ФЗ №63 от 06.04.2021 статья 9 “Использование простой электронной подписи”. Данный закон голосит:

1. Электронный документ считается подписанным простой электронной подписью при выполнении в том числе одного из следующих условий:

1) простая электронная подпись содержится в самом электронном документе;

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

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

Т.е. для законного использования пЭП нам необходимо:

  1. код подписи вписать в документ (что и так понятно)
  2. придумать правила определения подписавшего лица
  3. способ обеспечения конфиденциальности

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

Приведу пример как это сделано у меня в

договоре оферте

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

В разделе 1, Термины и определения вводится понятие пЭП.

1.6. «Простая электронная подпись» — подпись на электронной версии документов, передаваемых между Сторонами и определяемая правилами в Приложении 1 Данного договора, пунктами 4.2 и 4.3 данного Договора и статьей 9 Федерального закона от 06.04.2021 N 63-ФЗ «Об электронной подписи».

Далее раздел 4. Соглашение об использовании пЭП.

4. СОГЛАШЕНИЕ ОБ ИСПОЛЬЗОВАНИИ ПРОСТОЙ ЭЛЕКТРОННОЙ ПОДПИСИ.

4.1. Стороны, в соответствии с Федеральным законом от 06.04.2021 N 63-ФЗ «Об электронной подписи», дают согласие на использовании простой электронной подписи документах передаваемых между Сторонами, в том числе в закрывающих документах.

4.2. Правила и порядок формирования ключа простой электронной подписи и правила определения лица, подписывающего электронный документ, по его простой электронной подписью, определяются в Приложении 1 к данному Договору. Приложение 1 является неотъемлемой частью данного Договора.

4.3. Стороны обязуются соблюдать конфиденциальность ключа своей простой электронной подписи.

4.4. На основании п.4.2 и п.4.3. данного договора и положений п.2 статьи 9 Федерального закона от 06.04.2021 N 63-ФЗ «Об электронной подписи», электронные версии документов размещаемые в личном кабинете Лицензиата, либо предаваемые посредством электронной почты между Сторонами, признаются равнозначными документам на бумажных носителях, подписанным собственноручной подписью.

Далее раздел 6. Порядок взаиморасчетов. Тут сказано, что закрывающие документы могут удостоверяться пЭП.

6.7. Закрывающие документы между сторонами передаются в электронном виде посредством размещения в личном кабинете Лицензиата и (или) через электронную почту и удостоверяются Простой электронной подписью.

И наконец Приложение 1, где описываются правила и порядок формирования пЭП.

Правила и порядок формирования Простой электронной подписи.

1. Правила формирования подписи.

1.1. Ключ подписи – кодовое слово или любая последовательность символов от 6 до 64 знаков известная только владельцу.

Например: «Ключ Лицензиата»

1.2. Hash ключа подписи – ключ подписи обработанный hash функцией с длинной ключа от 64 до 256 бит.

Пример получения:

  1. hash(‘sha256′,’Ключ Лицензиата’) = cf7f0afbad1857c1da38477d79889cb378d33dee5430e9e7bf4cc04f0e3354f8
  2. hash(‘sha1′,’Ключ Лицензиата’) = 7e3ecf5ab5ad710573a028d1a383355293b75438
  3. md5(‘Ключ Лицензиата’) = 822f424c94ffbe1e9b0e53df6d851da4

1.3. Hash ключа подписи, для возможности автоматической проверки документов системой, пользователю необходимо внести в личном кабинете на сайте https://erp-platforma.com в разделе Настройки-ЭП.

1.4. В целях безопасности, 5-10 символы значения хеша ключа пользователя при выводе на экран заменяются звездочками (например: вместо 822f424c94ffbe1e9b0e53df6d851da4 на экран будет выведено 822f4*****ffbe1e9b0e53df6d851da4). Данная процедура исключает копирование ключа пользователя злоумышленником, даже в случае взлома логина-пароля аккаунта пользователя. Оригинал ключа должен храниться исключительно у пользователя.

1.5. Алгоритм получения простой электронной подписи документа:

«Простая электронная подпись» = hash_sha1(«Тип документа» «Номер документа» «Дата документа» «Ключ Лицензиата»)

PS: ключ лицензиата в данной системе является “солью”.

Например:

b554f464d3cf1b128b07e96b960b7bb4a19a3c95 = hash(‘sha1′,’1′.’№03452′.’09.11.2021’.’822f424c94ffbe1e9b0e53df6d851da4′)

Типы документов:

1 – Счет
2 – Акт
3 – Договор
4 – Приложение к договору

1.6. Для улучшения читабельности Электронная подпись может представляться в виде по 5 символов разделенных дефисами. Данная процедура необязательна. Дефисы при вводе подписи программой автоматически удалятся.

b554f464d3cf1b128b07e96b960b7bb4a19a3c95 = b554f-464d3-cf1b1-28b07-e96b9-60b7b-b4a19-a3c95

2. Правила проверки подписи

2.1. Удостоверение подлинности Простой электронной подписи Лицензиара.

Лицензиар на своем официальном сайте erp-platforma.com предоставляет возможность проверки подписи любого документа по адресу erp-platforma.com/ecp. Для проверки необходимо ввести Простую электронную подпись из документа в поле «Простая электронная подпись», ввести код капчи и нажать на кнопку «Проверить подпись документа». В ответ программа выдаст реквизиты документа, либо напишет «Документ не найден, подпись не подтверждена».

Данную процедуру проверки подлинности Простой электронной подписи Лицензиата может проводить как Лицензиат, так и третьи лица, которым Лицензиат передал документы.

2.2. Удостоверение подлинности Простой электронной подписи Лицензиата.
Удостоверить подпись Лицензиата Лицензиар может 4 способами:

1) В личном кабинете Лицензиата должен быть внесен Hash ключа подписи пользователя, подписавшего документ. В этом случае при получении документов по электронной почте у Лицензиара появляется возможность автоматической проверки подлинности подписи зная тип документа, номер документа, дату подписи и hash ключа подписи пользователя.

2) В случае если Лицензиат производит подпись документ в личном кабинете, и внесен hash ключа подписи пользователя, то необходимо внести сформированную Простую электронную подпись для данного Акта в соответствующую графу документ и нажать на кнопку «ЭП». Программа автоматически произведет проверку подписи и поставит ее в документ.

3) В случае если Лицензиат не вносит hash ключа подписи пользователя в личном кабинете, но хочет передавать подписанные Простой электронной подписью документы через электронную почту, Лицензиат должен доставить Лицензиару hash ключа подписи пользователя, подписывающего документы на любом носителе, в том числе на бумажном

Читайте также:  Электронная подпись для iPad #эп / эцп #СЭД #ECMJ

4) В случае если Лицензиат не желает сообщать лицензиару hash ключа подписи пользователя, он вправе сделать на своих технических средствах сервис проверки подписи аналогичный erp-platforma.com/ecp и вместе с документами присылать ссылку на данный сервис, чтобы у Лицензиара была возможность проверки подлинности Простой электронной подписи документа.


Код сервиса проверки

//Сначала отбрасываем всех кто неправильно ввел капчу
if ($_POST['capcha']==$_SESSION['captcha'])
{
	//Потом отбрасываем если неверный формат ЭП, на остольное даже не будем таратить ресурсы.
	if ((strlen($_POST['ep'])==47)or(strlen($_POST['ep'])==40))
	{
	
		//Если есть девисы то удаляем опять проверяем 
		$ep=str_replace('-','',$_POST['ep']);
		
		if (strlen($ep)==40)
		{
			//Здесь дожен быть запрос в БД и проверка ЭП, вывод результата проверки
		}
		else
			echo '<br><font color=red>Неверный формат ЭП.'.strlen($ep).'</font>';
	
	}
	else
		echo '<br><font color=red>Неверный формат ЭП. Должно быть 40 либо 47 символов.</font>';
}
else
{
	if (isset($_POST['capcha']))
		echo '<br><font color=red>Текст на рисунке не совпадает с введенным.</font>';
}

PS: не забываем про исключение SQL-иньекций при постановке в запрос ЭП!

Живой пример как можно организовать работу пользователей с ЭП и работу сервиса проверки, можно почитать здесь:

Надеюсь статья будет полезна, и я хоть немного популяризирую механизм пЭП и наша жизнь станет проще.

Положениео проведении эксперимента по использованию усиленной электронной подписи при предоставлении услуг и осуществлении иных действий с использованием федеральной государственной информационной системы “единая система идентификации и аутентификации в инфраструктуре, обеспечивающей информационно-технологическое взаимодействие информационных систем, используемых для предоставления государственных и муниципальных услуг в электронной форме”

1. Настоящее Положение устанавливает порядок проведения эксперимента по использованию усиленной электронной подписи (усиленной квалифицированной электронной подписи и усиленной неквалифицированной электронной подписи), сертификат ключа проверки которой создан и используется в инфраструктуре, обеспечивающей информационно-технологическое взаимодействие информационных систем, используемых для предоставления государственных и муниципальных услуг и исполнения государственных и муниципальных функций в электронной форме, при предоставлении услуг и осуществлении иных действий в электронном виде с использованием федеральной государственной информационной системы “Единая система идентификации и аутентификации в инфраструктуре, обеспечивающей информационно-технологическое взаимодействие информационных систем, используемых для предоставления государственных и муниципальных услуг в электронной форме” (далее соответственно – единая система идентификации и аутентификации, эксперимент).

2. Эксперимент проводится в 2 этапа:

первый этап – с 20 июля 2021 г. по 31 марта 2022 г.;

второй этап – с 1 апреля 2022 г. по 31 июля 2022 г.

3. На первом этапе осуществляется эксплуатация специализированной защищенной автоматизированной информационной системы, предусмотренной постановлением Правительства Российской Федерации от 29 октября 2021 г. № 1104 “О проведении в 2021 – 2021 годах эксперимента в целях обеспечения направления электронных документов для государственной регистрации юридических лиц и индивидуальных предпринимателей и открытия им счетов в кредитных организациях с использованием специализированной защищенной автоматизированной системы, предназначенной для централизованного создания и хранения ключей усиленной квалифицированной электронной подписи, а также их дистанционного применения владельцами квалифицированных сертификатов ключа проверки электронной подписи” (далее – автоматизированная система).

При проведении первого этапа эксперимента следует руководствоваться требованиями к автоматизированной системе, разработанными и утвержденными в рамках реализации указанного постановления Правительства Российской Федерации.

Для реализации задачи, предусмотренной подпунктом “а” пункта 7 настоящего Положения, на первом этапе до 31 декабря 2021 г. допускается использование несертифицированных средств электронной подписи и криптографической защиты информации.

4. На втором этапе автоматизированная система должна соответствовать требованиям, разработанным Федеральной службой безопасности Российской Федерации на основании модели угроз безопасности информации, обрабатываемой в автоматизированной системе (далее – модель угроз), и согласованным с Министерством цифрового развития, связи и массовых коммуникаций Российской Федерации.

5. Участниками эксперимента являются:

а) Министерство цифрового развития, связи и массовых коммуникаций Российской Федерации, Министерство труда и социальной защиты Российской Федерации, Федеральная служба безопасности Российской Федерации;

б) исполнительные органы государственной власти субъектов Российской Федерации, иные, помимо указанных в подпункте “а” настоящего пункта, федеральные органы исполнительной власти – на добровольной основе по согласованию с Министерством цифрового развития, связи и массовых коммуникаций Российской Федерации;

в) публичное акционерное общество “Ростелеком”, Банк ВТБ (публичное акционерное общество) – на добровольной основе;

г) государственные учреждения, иные юридические лица, индивидуальные предприниматели, участвующие в предоставлении услуг в рамках тестирования использования усиленной электронной подписи, предусмотренного подпунктами “а” и “б” пункта 7 настоящего Положения, – на добровольной основе по согласованию с Министерством цифрового развития, связи и массовых коммуникаций Российской Федерации;

д) физические лица, участвующие в предоставлении им услуг в рамках тестирования использования усиленной электронной подписи, предусмотренного подпунктами “а” и “б” пункта 7 настоящего Положения, – на добровольной основе и при наличии у физического лица ключа простой электронной подписи, выданного ему при личном приеме в соответствии с Правилами использования простой электронной подписи при оказании государственных и муниципальных услуг, утвержденными постановлением Правительства Российской Федерации от 25 января 2021 г.

е) аккредитованный удостоверяющий центр, владеющий автоматизированной системой, – на добровольной основе.

6. Целями эксперимента являются:

а) повышение эффективности дистанционного взаимодействия государственных органов, государственных учреждений, иных юридических лиц, индивидуальных предпринимателей и физических лиц посредством применения автоматизированной системы;

б) обеспечение возможности использования физическими лицами усиленной неквалифицированной электронной подписи при получении услуг и осуществлении иных действий в электронном виде с использованием федеральной государственной информационной системы “Единый портал государственных и муниципальных услуг (функций)” (далее – единый портал) и автоматизированной системы;

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

7. Задачами эксперимента являются:

а) тестирование использования физическими лицами усиленной неквалифицированной электронной подписи в соответствии с законодательством Российской Федерации и настоящим Положением, в том числе:

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

при подписании электронных документов, предусмотренных частью первой статьи 3123 Трудового кодекса Российской Федерации;

при заключении договоров об оказании услуг связи посредством информационно-телекоммуникационной сети “Интернет”;

при совершении сделок и осуществлении иных юридически значимых действий с использованием единого портала и иных информационных систем по соглашению между операторами или владельцами таких информационных систем и Министерством цифрового развития, связи и массовых коммуникаций Российской Федерации, заключаемому по утверждаемой им форме, при наличии информированного согласия физического лица на такой вид подписи при совершении сделки или осуществлении иного юридически значимого действия, предоставленного аккредитованному удостоверяющему центру, владеющему автоматизированной системой;

б) тестирование использования физическими лицами усиленной квалифицированной электронной подписи в соответствии с законодательством Российской Федерации и настоящим Положением;

в) доработка автоматизированной системы в целях реализации эксперимента.

8. Автоматизированная система обеспечивает:

а) взаимодействие:

с единой системой идентификации и аутентификации;

с единым порталом;

с единой информационной системой персональных данных, обеспечивающей обработку, включая сбор и хранение биометрических персональных данных, их проверку и передачу информации о степени их соответствия предоставленным биометрическим персональным данным физического лица;

с государственной системой изготовления, оформления и контроля паспортно-визовых документов нового поколения;

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

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

9. Создание ключа электронной подписи физическим лицом осуществляется самостоятельно c использованием средств электронной подписи, полученных в соответствии с подпунктом “в” пункта 8 настоящего Положения.

10. Создание и получение физическим лицом неквалифицированного сертификата осуществляется с использованием автоматизированной системы после создания физическим лицом ключа электронной подписи и прохождения процедуры идентификации и аутентификации с использованием ключа простой электронной подписи, выданного ему при личном приеме в соответствии с Правилами использования простой электронной подписи при оказании государственных и муниципальных услуг, утвержденными постановлением Правительства Российской Федерации от 25 января 2021 г. № 33 “Об использовании простой электронной подписи при оказании государственных и муниципальных услуг”.

Читайте также:  Как работать с электронной подписью без флешки? - Изготовим ЭЦП за 30 минут

11. Создание и получение физическим лицом квалифицированного сертификата осуществляется с применением информационных технологий без личного присутствия физического лица путем предоставления в автоматизированную систему информации, указанной в документе, удостоверяющем личность гражданина Российской Федерации за пределами территории Российской Федерации, содержащем электронный носитель информации с записанными на нем персональными данными владельца паспорта, включая биометрические персональные данные, или путем предоставления сведений из единой системы идентификации и аутентификации и информации из единой биометрической системы персональных данных, обеспечивающей обработку, включая сбор и хранение биометрических персональных данных, их проверку и передачу информации о степени их соответствия предоставленным биометрическим персональным данным физического лица в порядке, установленном Федеральным законом “Об информации, информационных технологиях и о защите информации”.

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

Указанная проверка осуществляется с использованием реестра неквалифицированных сертификатов, ведение которого обеспечивается Министерством цифрового развития, связи и массовых коммуникаций Российской Федерации. Реестр неквалифицированных сертификатов доступен на едином портале ежедневно и круглосуточно на безвозмездной основе.

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

14. При проведении эксперимента:

а) Министерство цифрового развития, связи и массовых коммуникаций Российской Федерации:

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

в течение 30 календарных дней после вступления в силу постановления Правительства Российской Федерации от 15 июля 2021 г. № 1207 “О проведении эксперимента по использованию усиленной электронной подписи при предоставлении услуг и осуществлении иных действий с использованием федеральной государственной информационной системы “Единая система идентификации и аутентификации в инфраструктуре, обеспечивающей информационно-технологическое взаимодействие информационных систем, используемых для предоставления государственных и муниципальных услуг в электронной форме” разрабатывает и направляет на согласование в Федеральную службу безопасности Российской Федерации модель угроз;

в течение 30 календарных дней после получения согласования Федеральной службой безопасности Российской Федерации утверждает модель угроз;

в течение 60 календарных дней с даты вступления в силу постановления Правительства Российской Федерации от 15 июля 2021 г. № 1207 “О проведении эксперимента по использованию усиленной электронной подписи при предоставлении услуг и осуществлении иных действий с использованием федеральной государственной информационной системы “Единая система идентификации и аутентификации в инфраструктуре, обеспечивающей информационно-технологическое взаимодействие информационных систем, используемых для предоставления государственных и муниципальных услуг в электронной форме” разрабатывает и согласовывает с Федеральной службой безопасности Российской Федерации “дорожную карту” по переходу на массовое использование технологии применения усиленной квалифицированной электронной подписи с применением физическими лицами средств электронной подписи класса не ниже КС3 при оказании государственных услуг в срок до 1 января 2023 г.;

в течение 90 календарных дней после определения Федеральной службой безопасности Российской Федерации требований к автоматизированной системе обеспечивает ее доработку;

не позднее чем через 30 календарных дней после завершения эксперимента проводит оценку результатов эксперимента, включая количественную оценку выданных сертификатов электронной подписи, подписанных электронной подписью документов, видов предоставленных услуг, и представляет соответствующий доклад в Правительство Российской Федерации;

б) Федеральная служба безопасности Российской Федерации:

в течение 30 календарных дней после получения модели угроз от Министерства цифрового развития, связи и массовых коммуникаций Российской Федерации обеспечивает ее рассмотрение;

в течение 120 календарных дней после утверждения модели угроз определяет требования к дорабатываемой автоматизированной системе.

Статья 16. аккредитация удостоверяющего центра

1. Аккредитация удостоверяющих центров осуществляется уполномоченным федеральным органом в отношении удостоверяющих центров, являющихся российскими или иностранными юридическими лицами.

2. Аккредитация удостоверяющего центра осуществляется на добровольной основе. Аккредитация удостоверяющего центра осуществляется на срок пять лет, если более короткий срок не указан в заявлении удостоверяющего центра.

3. Аккредитация удостоверяющего центра осуществляется при условии выполнения им следующих требований:

1) стоимость чистых активов удостоверяющего центра составляет не менее чем один миллион рублей;

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

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

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

4. Аккредитация удостоверяющего центра осуществляется на основании его заявления, подаваемого в уполномоченный федеральный орган. К заявлению прилагаются документы, подтверждающие соответствие удостоверяющего центра требованиям, установленным частью 3 настоящей статьи.

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

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

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

В случае принятия решения об аккредитации удостоверяющего центра уполномоченный федеральный орган в срок, не превышающий десяти дней со дня принятия решения об аккредитации, уведомляет удостоверяющий центр о принятом решении и выдает свидетельство об аккредитации по установленной форме.

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

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

6. Основанием для отказа в аккредитации удостоверяющего центра является его несоответствие требованиям, установленным частью 3 настоящей статьи, или наличие в представленных им документах недостоверной информации.

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

Читайте также:  Портал поставщиков стал удобнее для самозанятых граждан - Единый портал ЭП

Аккредитованный удостоверяющий центр при осуществлении своих функций и исполнении принятых обязательств должен соблюдать требования, установленные для удостоверяющих центров статьями 13 – 15, 17 и 18 настоящего Федерального закона. Уполномоченный федеральный орган вправе проводить проверки соблюдения аккредитованными удостоверяющими центрами требований настоящего Федерального закона в течение всего срока их аккредитации.

В случае выявления несоблюдения аккредитованным удостоверяющим центром указанных требований уполномоченный федеральный орган обязан выдать этому удостоверяющему центру предписание об устранении нарушений в установленный срок и приостановить действие аккредитации на данный срок с внесением информации об этом в перечень, указанный в пункте 4 части 3 статьи 8 настоящего Федерального закона.

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

8. На государственные органы, органы местного самоуправления, государственные и муниципальные учреждения, осуществляющие функции удостоверяющих центров, не распространяются требования, установленные пунктами 1 и 2 части 3 настоящей статьи.

9. Головной удостоверяющий центр, функции которого осуществляет уполномоченный федеральный орган, не подлежит аккредитации в соответствии с настоящим Федеральным законом.

Хранилище сертификатов в офисном пакете libreoffice

imageLibreOffice

— мощный офисный пакет. LibreOffice бесплатен и имеет открытый исходный код.

Офисный пакет содержит в себе текстовый и табличный процессор, программу для подготовки и просмотра презентаций, векторный графический редактор, систему управления базами данных и редактор формул:

image

Более того, проводимая политика импортозамещения, когда на столах чиновников вместо MS Windows все чаще появляются отечественные форки Linux, способствует широкому распространению пакета LibreOffice и в органах государственного управления.

LibreOffice интенсивно развивается и с момента своего появления вобрал в себя множество дополнительных возможностей. Одной из таких возможностей является электронная подпись (цифровая подпись в терминологии LibreOffice) документа. Для формирования электронной подписи (Файл → Цифровые подписи → Цифровые подписи … → Подписать документ) используются личные сертификаты:

image

Глядя на картинку, у неискушенного пользователя (а тем более у чиновника) возникает глубокое чувство непонимания: что за файл собирается открываться, что за пароль должен вводиться!

Следует отметить, что это не очень удачный перевод разработчиков LibreOffice. Речь идет не о файле, а о токене/смарткарте PKCS#11, и не о пароле, а о пользовательском PIN-коде для токена. Должно быть что-то следующего вида:

image

Тут мы подошли к главному вопросу: где и как хранятся сертификаты, которые LibreOffice использует для формирования электронной подписи документов?

В качестве хранилища сертификатов LibreOffice использует, как правило, хранилища сертификатов, создаваемых и поддерживаемых продуктами Mozilla (Firefox, Thunderbird, SeaMonkey). По умолчанию это хранилище сертификатов почтового клиента Thunderbird (Сервис → Параметры… → Безопасность → Сертификат…):

image

Хранилища сертификатов для продуктов Mozilla создаются средствами пакета NSS (Network Security Services). С помощью утилит командной строки можно создать и свое хранилище сертификатов, например:

bash-4.3$ cd /home/a513/tmp 
bash-4.3$ mkdir db_for_libre 
bash-4.3$ modutil -create -dbdir /home/a513/tmp/db_for_libre 
WARNING: Performing this operation while the browser is running could cause 
corruption of your security databases. If the browser is currently running, 
you should exit browser before continuing this operation. Type  
'q <enter>' to abort, or <enter> to continue:  
bash-4.3$ ls -l db_for_libre 
итого 60 
-rw------- 1 a513 a513 65536 авг 31 16:49 cert8.db 
-rw------- 1 a513 a513 16384 авг 31 16:49 key3.db 
-rw------- 1 a513 a513 16384 авг 31 16:49 secmod.db 
bash-4.3$

Созданное хранилище сертификатов в каталоге /home/a513/tmp/db_for_libre содержит три базы данных, а именно cert8.db, key3.db и secmod.db. Для их создания используется старая версия базы данных Berkeley (обычно она описывается в документах NSS как« DBM ») в отличие от хранилища сертификатов, скажем, в google-chrome, для создания и поддержки которого также используется пакет NSS, но для поддержки баз данных (cert9.db, key4.db и pkcs11.txt) в хранилище используется механизм SQLite3. Для работы и с тем и другим хранилищем используются одни и те же утилиты NSS, просто в параметре –d (каталог хранилища) перед путем к хранилищу, если вы собираетесь работать с новым форматом (SQLite3) хранилища, достаточно указать префикс: -d sql:.

Более того, также просто из хранилища сертификатов старого формата (cert8.db, key3.db и secmod.db) создается и хранилище в новом формате (cert9.db, key4.db и pkcs11.txt). Для этого достаточно выполнить утилиту работы с сертификатами certutil в режиме просмотра ключей (-K) или сертификатов (-L) с параметром –X:

bash-4.3$ ls -l /home/a513/tmp/db_for_libre/ 
итого 60 
-rw------- 1 a513 a513 65536 авг 31 17:56 cert8.db 
-rw------- 1 a513 a513 16384 авг 31 17:56 key3.db 
-rw------- 1 a513 a513 16384 авг 31 16:49 secmod.db 
bash-4.3$ certutil -L -d sql:/home/a513/tmp/db_for_libre -X  
Certificate Nickname             Trust Attributes   SSL,S/MIME, JAR/XPI 
bash-4.3$ ls -l /home/a513/tmp/db_for_libre/                
итого 120 
-rw------- 1 a513 a513 65536 авг 31 17:56 cert8.db 
-rw------- 1 a513 a513 28672 авг 31 17:56 cert9.db 
-rw------- 1 a513 a513 16384 авг 31 17:56 key3.db 
-rw------- 1 a513 a513 28672 авг 31 17:56 key4.db 
-rw------- 1 a513 a513   440 авг 31 17:56 pkcs11.txt 
-rw------- 1 a513 a513 16384 авг 31 16:49 secmod.db 
bash-4.3$

Как видим, теперь в хранилище есть базы данных как в старом, так и новом форматах.

К сожалению, обратное преобразование мне неизвестно и поэтому новые хранилища сертификатов, например, google-chrome (~/.pki) в LibreOffice недоступны.

Пакет NSS поддерживает работу с токенами/смарткартами PKCS#11, на которых, как правило, и хранят свои личные сертификаты с закрытыми ключами пользователи. Отметим, что личные сертификаты сегодня получают в удостоверяющих центрах .

Итак, мы остановились на том, что у нас был запрошен PIN-код к токену. Подключить токены/смарткарты PKCS#11 можно как через Firefox, Thunderbir, Seamonkey, так и утилитой modutil. Например, для подключения облачного токена достаточно выполнить команду:

$modutil –add LS11CLOUD2021 –libfile libls11cloud.so –dbdir /home/a513/tmp/db_for_libre 
$

Именно к этому токену LibreOffice и запросил пароль:

image

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

image

Как только будет выбран сертификат, произойдет формирование электронной подписи:

image

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

В заключение еще несколько слов о работе с хранилищем сертификатов. Если пользователь решил создавать свое хранилище отличное от продуктов Mozilla и для этого использовать утилиты командной строки NSS, то удобно воспользоваться графической оболочкой GUINSS.

Данная утилита позволяет подключать токены/смарткарты, импортировать корневые сертификаты и сертификаты из защищенного контейнераPKCS#12. Позволяет также создавать запросы (CSR) на сертификаты в формате PKCS#10:

image

Сформированный запрос на сертификат может быть отправлен в УЦ для получения сертификата:

image

Созданное хранилище может найти применение и за рамками LibreOffice.
P.S. В офисном пакете сертификаты из хранилища теперь используются для формирования электронной подписи по ГОСТ Р 34.10-2001/2021 в PDF-документах.

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

Adblock
detector