- Что такое электронная подпись
- Что делать, если потеряли электронную подпись
- «облачная» кэп в россии
- «подводные камни» простой электронной подписи
- Microsoft crypto api 2.0
- Pkcs#11
- Pkcs#7
- Xml-dsig
- Встраивание электронной подписи в прикладные системы
- Где можно использовать электронную подпись
- Европейский опыт использования облачных эп
- Зачем нужна электронная подпись
- Интерфейсы для доступа к скзи
- Как начать работать с квалифицированной электронной подписью
- Как перевыпустить сертификат
- Как подписать документ электронной подписью
- Как приобрести подпись физическому лицу
- Как приобрести подпись юридическому лицу и ип
- Как проверить подлинность подписи
- Как устроена эп
- Личная собственноручная подпись
- Манипуляции с эцп
- Новая облачная эцп
- Проприетарные интерфейсы
- Сырая подпись
- Фнс разъяснила, кто и как может получить бесплатную кэп с 1 июля | фнс россии | 77 город москва
- Форматы электронной подписи
- Электронная подпись
- Электронная цифровая подпись для чайников: с чем ее есть и как не подавиться. часть 3
- Эпилог
- Заключение
Что такое электронная подпись
Электронная подпись гарантирует, что документ подписал владелец электронной подписи. А неквалифицированная и квалифицированная подписи покажут, изменился ли документ после подписания.
Что делать, если потеряли электронную подпись
Если вы потеряли ключ от подписи или его украли, сразу обратитесь в удостоверяющий центр или МФЦ, который выдавал вам сертификат. Центр отзовет ваш сертификат, чтобы его не могли использовать мошенники. Еще обязательно сообщите об этом контрагентам, чтобы они знали, что вашей утерянной подписью могут воспользоваться злоумышленники.
Восстановить утерянный сертификат или ключ ЭП невозможно. Нужно получать новый: собирать документы и идти в удостоверяющий центр.
«облачная» кэп в россии
Безопасность облачных решений, а в особенности ЭЦП – это одна из основных болей безопасников. Что именно мне не нравится, спросит меня читатель, ведь уже все давно используют облачные сервисы, а с СМС-кой еще надежнее сделать банковский перевод.
На самом деле, опять-таки, вернемся к деталям. Облачная ЭЦП – это будущее, с которым сложно спорить. Но не сейчас. Для этого должны произойти нормативно-правовые изменения, которые позволят защищать обладателя облачных ЭЦП.
Что мы имеем сегодня? Существует ряд документов, определяющие понятие ЭП, электронного документооборота (ЭДО), а также законы о защите информации и обороте данными. В том числе нужно учитывать и Гражданский кодекс (ГК РФ), который регламентирует использование ЭП в документах.
Федеральный закон №63-ФЗ «Об электронной подписи» от 06.04.2021. Основной и рамочный закон описывающий общий смысл использования ЭП при совершении сделок различного характера и оказания услуг.
Федеральный закон №149-ФЗ «Об информации, информационных технологиях и о защите информации от 27.07.2006. В настоящем документе конкретизируется понятие электронного документа и всех связанных с ним сегментов.
Есть дополнительные законодательные акты, которые сопричастны регулированию ЭДОФедеральный закон 402-ФЗ «О бухгалтерском учете» от 06.12.2021. Законодательный акт предусматривает систематизацию требований к бухгалтерии и бухгалтерским документам в электронном виде.
В т.ч. можно учесть Арбитражный процессуальный кодекс РФ, которые допускают документы, подписанные ЭП в качестве доказательств в суде.
И именно тут и пришло мне в голову поковыряться в вопросе обеспечения безопасности, ведь у нас стандарты для средств крипто-защиты обеспечивает ФСБ и обеспечивает выдачу сертификатов соответствия. С 18 февраля ввелись-таки новые ГОСТы. Таким образом, ключи, хранящиеся в облаке напрямую не защищены сертификатами ФСТЭК.
«подводные камни» простой электронной подписи
Все информационные системы (ИС) можно разделить на публичные и закрытые, рассматривая круг пользователей, имеющих возможность создания или отправки электронных документов. Если, для доступа к ИС, человек обязан пройти процедуру проверки оригинала УЛ, то такая ИС будет закрытой, доступ к которой имеет строго определенный круг лиц.
ИС, доступ к которой имеет неопределенный круг лиц, не прошедших процедуру проверки УЛ, будет публичной. К закрытым ИС относятся все корпоративные ИС, так как человек, получивший к ней доступ, прошел процедуру оформления на рабочем месте с предъявлением документов и заключением трудового договора.
Рассмотрим основные способы подписания документов ПЭП, сложившиеся в российских реалиях.
Первым способом является заключение соглашения о том, что стороны признают документы, отправленные с электронного почтового ящика, подписанными ПЭП. В этом случае открытым ключом является адрес электронной почты, конфиденциальным ключом — пароль к электронному почтовому ящику. Юридически значимой такая ПЭП будет при соблюдении следующего условий:
- Почтовый сервис является закрытым, т.е. доступ к нему имеет строго определенный круг лиц, прошедших процедуру проверки оригинала удостоверения личности;
- Открытый ключ ПЭП содержится в передаваемом документе (ФЗ-63, статья 9 п.1);
- Пароль к почтовому ящику строго конфиденциален, известен только единственному, определенному лицу, прошедшему процедуру проверки оригинала УЛ перед получением пароля (ключа ПЭП) и это зафиксировано в соглашении (ФЗ-63, статья 9, п.2);
При использовании корпоративной электронной почты обычно соблюдаются все эти условия, т.к. корпоративная почта относится к закрытым ИС, адрес почтового ящика отправителя содержится в передаваемом сообщении, пароль к корпоративному личному почтовому ящику известен только строго определенному лицу.
Microsoft crypto api 2.0
Операционная система Microsoft Windows, независимо от версии, довольно сложная система, которая помимо всего прочего занимается вопросами обеспечения безопасности пользовательских и корпоративных данных. В этих задачах традиционно широко используется криптография.
С целью унификации доступа к криптографическим функциям компания Microsoft разработала проприетарный API: Microsoft Crypto API. Широкое распространение приобрела версия Crypto API 2.0. Парадигма Microsoft Crypto API базируется на использовании так называемых криптопровайдеров, или, по-русски, поставщиков криптографии.
Спецификация Crypto API описывает набор функций, которые должна предоставлять библиотека криптопровайдера операционной системе, способы интеграции с ней и спецификации вызовов. Таким образом, производитель СКЗИ, выполняющий правила Crypto API, имеет возможность интеграции своего решения в операционную систему Microsoft Windows, а прикладное программное обеспечение получает доступ криптографическим функциям посредством унифицированного интерфейса.
Дополнительным плюсом является то, что компания Microsoft реализовала над Crypto API довольно большое количество функций, отвечающих за выполнение прикладных задач: работа с сертификатами, формирование различных видов подписи, работа с ключевой информацией и пр. Также Crypto API, как нетрудно догадаться, тесно интегрирован с операционной системой и ее внутренними механизмами.
Но расплатой за удобство становится платформозависимость и необходимость тесной интеграции решения в операционную систему.
В Windows Vista Microsoft представила новую версию криптографического программного интерфейса – Microsoft CNG (Cryptography API: Next Generation). Данный интерфейс базируется уже не на поставщиках криптографии, а на поставщиках алгоритмов и поставщиках хранилищ ключевой информации.
Pkcs#11
PKCS#11 (Public-Key Cryptography Standard #11) – платформонезависимый программный интерфейс для работы с аппаратно реализованными СКЗИ: смарт-карты, HSM’ы, криптографические токены. Иногда PKCS#11 используется для доступа к программно реализованным криптографическим библиотекам.
PKCS#11 представляет собой довольно обширный документ, опубликованный RSA Laboratories, который описывает набор функций, механизмов, алгоритмов и их параметров для работы с криптографическими устройствами или библиотеками. В данном документе четко прописаны правила, в соответствии с которым будет работать прикладное программное обеспечение при вызове криптографических функций.
Данный стандарт поддерживается во многих open source-проектах, использующих криптографию. Для примера, Mozilla Firefox позволяет хранить сертификаты и закрытые ключи для аутентификации через SSL/TLS на токенах, работая с ними по PKCS#11.
Если прикладное программное обеспечение «умеет» работать с PKCS#11, то производителю СКЗИ необходимо реализовать программную библиотеку, которая наружу будет выставлять интерфейсы, описанные в стандарте, а внутри реализовывать необходимую СКЗИ логику: работа непосредственно с криптографическим устройством или реализация необходимых криптоалгоритмов программно.
В этом случае прикладное программное обеспечение должно «подцепить» необходимую библиотеку и выполнять необходимые действия в соответствии с рекомендациями стандарта. Это обеспечивает заменяемость различных устройств и их библиотек для прикладного программного обеспечения и прозрачное использование СКЗИ в различных системах.
Единственным существенным минусом PKCS#11 является отсутствие рекомендаций по работе с сертификатами открытого ключа, что предполагает либо использование проприетарных расширений стандарта, либо использование других средств для работы с сертификатами.
Pkcs#7
PKCS#7 (Public-Key Cryptography Standard #7), или CMS (Cryptographic Message Syntax) – стандарт, публикуемый и поддерживаемый все той же RSA Laboratories, описываемый синтаксис криптографических сообщений.
PKCS#7 также публикуется в качестве RFC с номером 2315.
Синтаксис CMS описывает способы формирования криптографических сообщений, в результате чего сообщение становится полностью самодостаточным для его открытия и выполнения всех необходимых операций.
С этой целью в PKCS#7 размещается информация об исходном сообщении (опционально), алгоритмах хеширования и подписи, параметрах криптоалгоритмов, времени подписи, сертификат ключа электронной подписи, цепочка сертификации и т. д.
Большинство атрибутов PKCS#7 являются опциональными, но их обязательность может определяться прикладной системой.
Отдельно следует отметить, что PKCS#7 позволяет ставить несколько подписей под одним документом, сохраняя всю необходимую информацию в сообщении.
Формирование и проверка PKCS#7 реализованы в криптографических «надстройках» в Microsoft Crypto API, речь о которых шла выше. Но сам формат довольно хорошо специализирован и его поддержка может быть реализована нативно.
Xml-dsig
W3C разработала и опубликовала рекомендации по составлению подписанных сообщений в формате XML.
Фактически XML-DSig решает те же вопросы, что и PKCS#7. Основное отличие в том, что в PKCS#7 данные хранятся в структурах, сформированных в соответствии с разметкой ANS.1 (фактически, бинарные данные), а в XML-DSig данные хранятся в текстовом формате в соответствии с правилами документа «XML Signature Syntax and Processing».
Область применения XML-DSig – веб-приложения и веб-сервисы.
Встраивание электронной подписи в прикладные системы
Криптостойкие алгоритмы, принятые в качестве национальных или мировых стандартов, являются общедоступными. Их криптостойкость базируется на неразрешимых за приемлемое время математических задачах.
Но реализация криптоалгоритмов с учетом высокого быстродействия, отсутствия ошибок и гарантированного выполнения требований математических преобразований – непростая задача, которой занимаются квалифицированные разработчики.
В случае, если электронная подпись используется в критичных приложениях (например, для выполнения юридически значимых действий), реализация криптоалгоритмов в обязательном порядке проходит процесс сертификации на соответствие требованиям безопасности.
В «западном» мире широко используется сертификация решений на соответствие Common Criteria, в России процесс сертификации средств криптографической защиты проводит ФСБ России.
Дополнительно, средства криптографической защиты информации (СКЗИ, этот термин широко используется в РФ) могут иметь самое разное представление: от программных библиотек до высокопроизводительных специализированных железок (Hardware Security Module, HSM).
Именно из-за сложности реализации и регуляции данного вида продукции существует рынок решений по криптографической защите информации, на котором играют различные игроки.
С целью совместимости различных реализаций, а также упрощения их встраивания в прикладное программное обеспечение, были разработаны несколько стандартов, относящиеся к различным аспектам работы с СКЗИ и непосредственно электронной подписью.
Где можно использовать электронную подпись
| Простая | Неквалифицированная | Квалифицированная | |
|---|---|---|---|
| Внешние и внутренние электронные документы | |||
| Документооборот с физическими лицами | |||
| Госуслуги | — | ||
| Документы для ИФНС в личном кабинете налогоплательщика | — | ||
| ПФР и ФСС | — | — | |
| Арбитражный суд | — | — |
Европейский опыт использования облачных эп
Начнем с главного – облачные технологии, не только ЭП имеют четкий стандарт. Основой Группа координации облачных стандартов (Cloud Standard Coordination, CSC) Европейского института телекоммуникационных стандартов (European Telecommunications Standards Institute, ETSI). Однако на территории разных государств все еще имеются различия в стандартах защиты данных.
Базой для комплексной защиты данных является обязательная для провайдеров сертификация по ISO 27001:2021 на системы менеджмента информационной безопасности (соответствующий российский ГОСТ Р ИСО/МЭК 27001-2006 базируется на версии этого стандарта от 2006 года).
В ISO 27017 предусматриваются дополнительные элементы безопасности для облака, отсутствующие в ISO 27002. Полное официальное название этого стандарта: «Свод правил для средств управления информационной безопасностью на базе ISO/IEC 27002 для облачных сервисов» («Code of practice for information security controls based on ISO/IEC 27002 for cloud services»).
Летом 2021 года ISO опубликовала стандарт ISO 27018:2021 о защите персональных данных в облаке, а в конце 2021 года — ISO 27017:2021 о средствах контроля информационной безопасности для облачных решений.
Осенью 2021-го года в силу вступило новое Постановление Европарламента №910/2021, получившее название eIDAS. Новые правила разрешают пользователям хранение и использование ключа КЭП на сервере аккредитованного поставщика доверенных услуг, так называемого TSP (Trust Service Provider).
Европейский комитет по стандартизации (CEN) в октябре 2021-го года принял техническую спецификацию CEN/TS 419241 «Security Requirements for Trustworthy Systems Supporting Server Signing», посвященную регулированию облачный ЭЦП. В документе описано несколько уровней соответствия безопасности.
К примеру, для соответствия «уровня 2», предъявляемого для формирования квалифицированной электронной подписи, является поддержка строгих вариантов аутентификации пользователей. По требованиям данного уровня аутентификация пользователя происходит напрямую на сервере подписи, в отличии, к примеру, от допустимой для «уровня 1»аутентификации в приложении, которое от своего имени обращается к серверу подписи.
Аутентификация пользователя в облачном сервисе обязана быть как минимум двухфакторной. Как правило наиболее доступный и простой в использовании вариант — это подтверждение входа через код полученный в СМС-сообщении. Так к примеру, реализовано большинство личных кабинетов ДБО российских банков.
Могу подвести пока промежуточный итог, относительно того, что облачные КЭП пока у нас еще только формируются и отходить от железа рано. В принципе, это естественный процесс, который то и в Европе (о, великая!) длился около 13-14 лет, пока были выработаны более менее точные стандарты.
Пока мы не разработаем хороших ГОСТов, регулирующих наши облачные сервисы, рано говорить о полном отказе от аппаратных решений. Скорее, они сейчас, наоборот, станут двигаться в сторону «гибридов», то есть работать с облачными подписями в том числе. Некоторые примеры, соответствующие евростандартам работы с Cloud уже реализованы. Но об этом чуть подробнее и в новом материале.
Зачем нужна электронная подпись
Электронная подпись понадобится тем, кто собирается использовать в работе электронные документы, сдавать отчетность и получать услуги в интернете.
Все эти операции призваны облегчить жизнь представителям бизнеса — экономить на документообороте, меньше бегать по инстанциям, получать государственные услуги удаленно и т. п.
О том, как еще обычный человек может использовать электронную подпись на практике, мы рассказывали в другой статье.
Интерфейсы для доступа к скзи
На сегодняшний день широкое распространение получили один промышленный стандарт работы с СКЗИ и один (фактически два) проприетарный интерфейс всеми известной компании Microsoft.
Как начать работать с квалифицированной электронной подписью
Чтобы начать работать с электронной подписью, необходимо подготовить свое рабочее место и приобрести сертификат подписи. Сертификат выдают быстро — в течение часа.
Еще для работы с квалифицированной подписью надо будет установить программу для криптозащиты информации (СКЗИ). Самые распространенные средства криптозащиты в России — это «Криптопро CSP», Signal-com CSP, «Лисси CSP», Vipnet CSP. Все они примерно одинаковые.
Какое конкретно СКЗИ потребуется и какие настройки будут нужны, вам скажут в удостоверяющем центре или МФЦ.
Как перевыпустить сертификат
Срок действия сертификата электронной подписи — год. Когда он подойдет к концу, выпустите новый сертификат. Для этого обратитесь с заявлением в удостоверяющий центр или МФЦ. Если в документах ничего не изменилось, нести их снова не нужно. Если какие-то документы поменялись, нужно принести оригиналы только этих документов.
Как подписать документ электронной подписью
Ваше СКЗИ добавляет в контекстное меню вашей операционной системы — Виндоус или Мак-ос — свой специальный раздел. Таким образом, можно подписать любой документ просто нажатием правой кнопки мыши. На сайте каждого СКЗИ можно найти подробную инструкцию, как подписывать документ.
Например, так работает процесс подписания с помощью программы «Крипто-АРМ»:
- Кликните правой кнопкой мыши по документу.
- Найдите пункт меню «Крипто-АРМ» и нажмите «Подписать».
- После этого запускается мастер создания электронной подписи, который подробно объяснит все дальнейшие шаги.
- В итоге рядом с документом появится новый файл документ.doc.sig — это и есть файл электронной подписи.
В результате документ становится недоступным для изменения, а рядом с ним в папке появится файл подписи в формате документ.doc.sig.
В «Гугл-докс» плагины для электронной подписи можно найти во вкладке «Дополнения».
Как приобрести подпись физическому лицу
Физическим лицам проще всего получить подпись в ближайшем МФЦ: рядом может не быть удостоверяющих центров, а МФЦ найдется всегда. Для этого надо записаться на прием и подготовить следующие документы:
- Заявление на изготовление квалифицированного сертификата — шаблон дадут в МФЦ.
- Паспорт.
- СНИЛС.
- Свидетельство о присвоении ИНН.
В Москве электронная подпись для граждан стоит 900—950 рублей. Вместе с носителем цена составит 1500—1600 Р. Отдельно носитель будет стоить от 1500 рублей. Эта цена отличается в зависимости от тарифа удостоверяющего центра и того, насколько защищенную подпись вы хотите использовать.
Как приобрести подпись юридическому лицу и ип
Юридические лица получают квалифицированные сертификаты подписи в удостоверяющем центре или МФЦ.
Как проверить подлинность подписи
Чтобы проверить подлинность подписи и неизменность документа, воспользуйтесь любым из бесплатных сервисов:
- Портал «Криптопро».
- Сайт госуслуг.
- Сервис «Контур-крипто».
Как устроена эп
Файл электронной подписи генерирует специальная программа — средство криптографической защиты информации (СКЗИ). Когда вы подпишете документ электронной подписью, эта программа просканирует документ. В итоге она создаст уникальное сочетание данных документа — хэш-сумму.
Сертификат закрытого ключа хранится у владельца на любом удобном носителе: на компьютере, внешнем диске или токене — специальной защищенной флешке, которую можно носить с собой. Еще подпись может быть на диске, смарт-карте, симке, в облачном хранилище и т. д.
Просмотреть подпись можно с помощью сертификата открытого ключа — электронного документа, в котором есть следующая информация:
- Кто владеет подписью.
- Какие у него полномочия.
- Какая организация выдала подпись и какие у нее полномочия.
Программа СКЗИ проверяет хэш-сумму и сравнивает ее с содержанием документа. Если все совпало, документ не меняли и подпись цела. Несовпадения означают, что документ изменили после того, как подписали. Тогда подпись автоматически считается недействительной и документ теряет юридическую силу.
Личная собственноручная подпись
Исторически сложилось так, что в российском законодательстве нет определения личной собственноручной подписи. Этот вопрос разбирается в большом количестве юридической литературы, и общепринятым толкованием термина «личная собственноручная подпись» является следующее:
Подпись — уникальная совокупность символов, написанных от руки с помощью специальных оформительских приемов (монограмма, росчерки, штрихи), служащая для определения правоспособности физического лица.
Манипуляции с эцп
Новая инициатива правительства вышла на фоне многочисленных случаев мошенничества, когда коммерческие центры сертификации выдавали усиленные квалифицированные ЭЦП через интернет после поверхностной проверки документов. Этим пользовались мошенники, которые
, отправляли
и т. д.
За те годы, что в России действует законодательство по электронной цифровой подписи, зарегистрировано несколько способов мошенничества:
- Незаконные действия через центры сертификации РФ, в том числе оформление документов без участия гражданина. Выявлены случаи массовой фальсификации ЭЦП путём повторного использования удостоверяющим центром электронной подписи клиента.
- Дистанционный выпуск квалифицированного сертификата без личного контакта заявителя и сотрудника регистрационного отдела удостоверяющего центра. В этом случае оформление электронной подписи производится на основании документов заявителя, представленных центру сертификации через интернет. По мнению специалистов правовой системы «Гарант», в этом случае «IT-функции в деятельности УЦ преобладают над его юридической сущностью», а электронная подпись может быть использована недобросовестными третьими лицами.
Новая облачная эцп
«Преимущество облачной цифровой подписи заключается в том, что пользователю не надо устанавливать на свой компьютер никакого специального ПО и не надо беспокоиться о том, как электронную подпись, хранящуюся на флэшке, воткнуть, например, в iPhone. Она просто хранится на защищенном сервере в облаке, и именно туда отправляются на подписание нужные пользователю документы», — объяснил консультант по информационной безопасности Cisco Systems Алексей Лукацкий.
Автоматизированную систему для выдачи и использования облачной электронной подписи должны создать «Ростелеком» и подведомственный Минкомсвязи НИИ «Восход». Кроме того, «Ростелеком» должен проработать «модель угроз информационной безопасности», которая будет учитываться при создании системы.
По словам информированного источника, по итогам эксперимента «Ростелеком» может быть назначен оператором единой системы по выдаче и использованию облачных электронных цифровых подписей в России: «Такой вариант развития событий обсуждался, и он вполне вероятен.
По оценке игроков рынка, в России используется более 5 млн квалифицированных ЭЦП. Объём рынка составляет 15−20 млрд руб. в год.
Если эксперимент окажется удачным, то облачная ЭЦП может заменить привычные USB-токены. Но специалисты отмечают естественное ослабление безопасности в таком случае: «Представьте, готовы ли вы отдать третьим лицам гипотетическую возможность переписать все ваше имущество, закрыть или переписать ваш бизнес и любые другие активы?
В настоящий момент обычная электронная подпись ещё не стала массовой, не говоря об облачной. Поэтому для частных лиц проблема не является сильно актуальной. Однако она куда более близка организациям, где сделки совершаются ежедневно и электронная подпись является критически важным элементом бизнеса», — говорит руководитель Центра мониторинга и реагирования на инциденты информационной безопасности Jet CSIRT компании «Инфосистемы Джет» Алексей Мальнев.
Проприетарные интерфейсы
Наличие стандартизованных интерфейсов никогда не было препятствием для существования проприетарных библиотек со своими интерфейсами. Примером этому может служить библиотека OpenSSL, работа с которой осуществляется по собственным правилам.
Стандарт PKCS#11 предполагает возможность использования проприетарных расширений. Фактически, это добавленные производителем функции, не описанные в стандарте. Обычно они служат для выполнения специфических операций с устройствами или реализуют необходимые, по мнению производителя, функции.
Сырая подпись
Описанные выше форматы электронной подписи необходимы при взаимодействии разнородных систем, когда информация об отправителе подписанного сообщения минимальна.
При взаимодействии в рамках одной информационной системы, когда информация об отправителе, используемых криптоалгоритмах и их параметрах известна получателю, более рационально использование «сырой» электронной подписи.
В этом случае фактически передается только само значение электронной подписи вместе с документом. Информация для проверки берется получателем из централизованной базы данных.
Это позволяет значительно упростить процедуры выработки и проверки подписи, так как отсутствуют шаги формирования и разбора сообщений в соответствии с каким-либо форматом.
Фнс разъяснила, кто и как может получить бесплатную кэп с 1 июля | фнс россии | 77 город москва
Дата публикации: 12.05.2021 09:30
C 1 января 2022 года на ФНС России возлагаются функции по выпуску квалифицированной электронной подписи для юридических лиц (лиц, имеющих право действовать от имени юридического лица без доверенности), индивидуальных предпринимателей и нотариусов.
Срок действия КЭП, выпущенных коммерческими удостоверяющими центрами, заканчивается 1 января 2022 года. До 1 июля 2021 года им необходимо переаккредитоваться. Чтобы обеспечить «бесшовный» переход от платной к соответствующей безвозмездной государственной услуге по выпуску электронной подписи с 1 июля получить квалифицированную электронную подпись можно будет в Удостоверяющем центре ФНС России.
Сделать это смогут все юридические лица и индивидуальные предприниматели с учетом следующих ограничений:
- Удостоверяющий центр ФНС России бесплатно выдает квалифицированные сертификаты только для юридических лиц (как правило, генеральному директору, который действует от лица компании без доверенности), индивидуальных предпринимателей и нотариусов;
- Квалифицированный сертификат физического лица, а также лица, планирующего действовать от имени юридического лица по доверенности, можно получить в коммерческих аккредитованных удостоверяющих центрах;
- Квалифицированные сертификаты для заявителей, указанных в п.1, выпускаются территориальными налоговыми органами по предварительной записи. Заявитель должен лично предоставить заявление на выпуск КЭП, паспорт и СНИЛС в налоговый орган и пройти процедуру идентификации.
- Квалифицированный сертификат записывается на предоставляемый заявителем носитель ключевой информации, сертифицированный ФСТЭК России или ФСБ России. УЦ ФНС России поддерживает ключевые носители формата USB Тип-А, в частности: Рутокен ЭЦП 2.0, Рутокен S, Рутокен Lite, JaCarta ГОСТ, JaCarta-2 ГОСТ, JaCarta LT, ESMART Token, ESMART Token ГОСТ и другие, соответствующие установленным требованиям.
Приобрести такие носители можно у дистрибьюторов производителей и в специализированных интернет-магазинах. Кроме того, можно использовать уже имеющиеся носители при условии их соответствия требованиям. Один ключевой носитель может использоваться для хранения нескольких (до 32 экз.) КЭП и сертификатов к ним, выданных как коммерческими, так и государственными УЦ.
Для подготовки заявления на выдачу квалифицированного сертификата, а также приобретения ключевых носителей можно обратиться к оператору электронного документооборота. Полученные в рамках «пилотного» выпуска квалифицированные сертификаты являются легитимными, имеют срок действия 15 месяцев и могут использоваться для сдачи отчетности и ведения хозяйственной деятельности в рамках Федерального закона от 06.04.2021 № 63-ФЗ «Об электронной подписи».
Пользователи, получившие КЭП в УЦ ФНС России, могут обращаться в Службу технической поддержки или по телефону Единого контакт-центра ФНС России: 8-800-222-2222.
С 1 июля 2021 года лица, имеющие право действовать без доверенности от имени организации, и индивидуальные предприниматели смогут подать заявление на выпуск КЭП через «Личный кабинет налогоплательщика – физического лица».
ФНС напоминает, что с 1 января 2022 года вступают в силу следующие ограничения:
- Квалифицированную электронную подпись кредитных организаций, операторов платежных систем, некредитных финансовых организаций и индивидуальных предпринимателей можно будет получить в Удостоверяющем центре Центрального банка Российской Федерации;
- Квалифицированную электронную подпись должностных лиц государственных органов, органов местного самоуправления либо подведомственных государственному органу или органу местного самоуправления организации можно будет получить в Удостоверяющем центре Федерального Казначейства;
- Квалифицированную электронную подпись физических лиц, а также лиц, действующих от имени юридического лица по доверенности, можно будет получить
в коммерческих удостоверяющих центрах после их переаккредитации.
Форматы электронной подписи
Описанные выше интерфейсы для доступа к криптографическим функциям позволяют обращаться за выполнением математических преобразований к различным, как хорошо было замечено Microsoft, «поставщикам криптографии».
Но алгоритмов выработки и проверки электронной подписи существует множество. У каждого из этих алгоритмов есть набор параметров, которые должны быть согласованы при выработке и проверке. Плюс для проверки подписи по-хорошему нужен сертификат. Все эти параметры необходимо либо согласовать в прикладной системе, либо передавать вместе с подписью.Для решения этой задачи также предлагается ряд стандартов.
Электронная подпись
Нормативным документом, в котором приводится определение электронной подписи(ЭП), является Федеральный Закон “№ 63 от 06.04.2021 «Об электронной подписи” (далее ФЗ-63). В статье 2 ФЗ-63 рассматриваемое понятие определяется так:
Электронная подпись — информация в электронной форме, которая присоединена к другой информации в электронной форме (подписываемой информации) или иным образом связана с такой информацией и которая используется для определения лица, подписывающего информацию.
Из данного определения вытекает, и в статье 6 ФЗ-63 нормативно зафиксировано, что ЭП является аналогом личной собственноручной подписи, так как главная цель у обеих типов подписей одна — определение лица, подписывающего информацию. Идентификация личности — очень важный момент для юридической значимости ЭП.
Полную гарантию достоверного определения лица не дает ни один из видов ЭП, но, в случае неквалифицированной и квалифицированной ЭП, человек лично посещает специальное учреждение — Удостоверяющий Центр (УЦ), аккредитованное государством и уполномоченное для выдачи(замены) ЭП.
В случае ПЭП, об обязательности достоверной идентификации личности при выдаче(замене) ЭП часто забывают или способ определения лица вызывает много споров в технической реализации. ФЗ-63, в статье 5 пункт 2, подчеркивая важность идентификации личности, дает следующее определение простой электронной подписи:
Простой электронной подписью является электронная подпись, которая посредством использования кодов, паролей или иных средств подтверждает факт формирования электронной подписи определенным лицом.
Кода, пароли или иные средства, являющиеся элементами ПЭП, имеют обобщающее название — ключи ПЭП. Ключи ПЭП могут иметь публичную и конфиденциальную части.
Например, при использовании в техническом решении идентификации личности личного электронного почтового ящика, адрес почтового ящика будет открытой частью ключа, а пароль к нему — закрытой, конфиденциальной частью. ФЗ-63 обязывает строго соблюдать конфиденциальность непубличных ключей ПЭП, так как компрометация приводит к потере юридической значимости.
Возвращаясь к определению подписи, которое было дано в предыдущих абзацах, мы можем расширить определение ПЭП, раскрыв значение термина «определенное лицо»:
Простой электронной подписью является электронная подпись, которая посредством использования кодов, паролей или иных средств устанавливает связь человека, подписывающего информацию, с набором признаков, присущих только этому человеку, в целях контроля соблюдения прав или выполнения обязанностей, определенных подписанным документом.
Основным и практически единственным способом юридического сопоставления человека с набором признаков, присущих данному человеку, является предъявление оригинала удостоверяющего документа, в качестве которого применяется выданное государственными органами удостоверение личности (УЛ).
Удостоверение личности содержит фотографию, фамилию и имя, а также указание на место жительства, т.е. весь необходимый набор признаков, установленный законодательством для идентификации. Правила выдачи такого удостоверения всегда предписывают его получение лично владельцем и никем иным и этот факт является юридически значимым: во время выдачи удостоверения установлена связь между человеком, его фотографией, его именем и фамилией, и его местом жительства.
Следовательно, задача придания ПЭП юридической значимости сводится к задаче определения связи между государственным УЛ и ключами ПЭП.
Электронная цифровая подпись для чайников: с чем ее есть и как не подавиться. часть 3
Часть 2
В этой части сделаем небольшое отступление от цифровых подписей в сторону того, без чего непосредственно цифровых подписей, да и защиты информации в привычном понимании, не было бы: шифрования. Ведь первое, что приходит на ум, когда идет речь о защите наших данных — это не дать эти данные нехорошему человеку прочитать. Поэтому, перед тем, как продолжить рассмотрение стандартов PGP и S/MIME, стоит закрасить некоторые остающиеся в знаниях белые пятна, и рассмотреть процесс шифрования немного поподробнее.
Шифры и коды существуют, наверное, с того момента, как человечество научилось записывать свои впечатления об окружающем мире на носителях. Если немного вдуматься, даже обыкновенный алфавит — уже шифр. Ведь когда мы читаем какой-либо текст, в нашей голове каждому нарисованному символу сопоставляется некий звук, сочетание звуков, или даже целое понятие, а в голове соседа, который читать не умеет, этого уже не происходит.
Не зная, какому символу и что сопоставлено, мы никогда не сможем понять, что же именно писавший имел ввиду. К примеру, попробуйте взять и прочитать что-то, написанное на иврите, или на китайском языке. Сами алфавиты этих языков будут являться для вас непреодолимым препятствием, даже если с помощью этих символов написаны понятия вашего родного языка.
Но, тем не менее, простое использование чужого алфавита все же недостаточная мера для защиты ваших данных. Ведь любой алфавит, так или иначе, создавался для удобства пользования им и является неразрывно связанным с языком, которому данный алфавит характерен. А значит, выучив этот язык и некоторый набор базовых понятий на нем (а то и просто воспользовавшись услугами человека, знающего данный язык), нехороший человек может прочитать вашу информацию.
Значит, надо придумать алфавит, который знает только ограниченный круг лиц, и с его помощью записать информацию. Наверняка все читали (или, по крайней мере, слышали) цикл историй про Шерлока Холмса. В этом цикле фигурировал алфавит, составленный из пляшущих человечков (а многие, я думаю, в детстве на его основе составляли свой). Однако, как показывает данная история, наблюдательный человек может разгадать, какой символ и к чему относится. А значит наша информация опять попадет не в те руки.
Что же делать? Придумывать все более и более сложные алфавиты? Но чем более сложный и громоздкий алфавит, тем более неудобно с ним работать, хранить его в тайне. К тому же, насчет тайны есть замечательная поговорка: знают двое – знают все. Ведь самое слабое звено в любом шифре – это человек, который знает, как этот шифр расшифровать.
А почему бы не сделать так, чтобы способ шифрования был сразу известен всем, но расшифровать наши данные было бы нельзя без какого-то ключа? Ведь ключ (в отличие от всего алфавита) маленький, его достаточно легко сделать новый, если что (опять же, в отличие от переработки всего алфавита), легко спрятать. Наиболее наглядно плюсы ключевых систем показывает следующий пример: получателю надо прочитать сосланное вами сообщение. Обычное, на бумаге. Допустим, вы используете секретный алфавит. Тогда, чтобы прочитать сообщение, получатель должен знать алфавит, иметь большой пыльный талмуд, в котором описаны способы расшифровки (ведь алфавит должен быть сложным, чтобы быть надежным) и понимать, как же с этим талмудом работать. С ключами же все проще: вы кладете сообщение в коробку с замком, а получателю достаточно просто вставить подходящий ключик, а знать, как же устроен замок ему совершенно но нужно.
Итак, общеизвестные «алфавиты» и ключи — механизм, существенно более удобный, чем просто алфавиты. Но как же так зашифровать, чтобы все расшифровывалось простым ключом? И вот тут нам на помощь приходит математика, а конкретнее – математические функции, которые можно использовать для замены наших исходных символов на новые.
Вспомним же, что такое функция. Это некоторое соотношение, по которому из одного числа можно получить другое. Зная x и подставляя его в известное нам соотношение y=A*x, мы всегда получим значение y. Но ведь, как правило, верно и обратное: зная y, мы можем получить и x.
Как правило, но далеко не всегда. Для многих зависимостей получить y легко, тогда как x – уже очень трудно, и его получение займет продолжительное время. Вот именно на таких зависимостях и базируется используемое сейчас шифрование.
Но, вернемся к самому шифрованию. Шифрование подразделяют на симметричное, асимметричное и комбинированное. Рассмотрим, в чем суть каждого из них.
Симметричное шифрование, по большому счету, достаточно слабо отличается от старого доброго секретного алфавита. Собственно говоря, отличается оно как раз наличием ключа – некоторой сравнительно маленькой последовательности чисел, которая используется для шифрования и расшифровывания. При этом, каждая из обменивающихся информацией сторон должна этот ключ знать и хранить в секрете. Огромным плюсом такого подхода является скорость шифрования: ключ, по сути, является достаточно простой и короткой инструкцией, какой символ, когда, и на какой надо заменять. И работает данный ключ в обе стороны (то есть с его помощью можно как заменить все символы на новые, так и вернуть все как было), за что такой способ шифрования и получил название симметричного. Столь же огромным минусом является именно то, что обе стороны, между которыми информация пересылается, должны ключ знать. При этом, стоит нехорошему человеку заполучить ключ, как он тут же прочитает наши столь бережно защищаемые данные, а значит проблема передачи ключа принимающей стороне становится в полный рост.
Асимметричное шифрование поступает несколько хитрее. Здесь и у нас, и у нашего получателя есть уже два ключа, которые называют открытый и закрытый. Закрытый ключ мы и получатель храним у себя (заметьте, каждый хранит только свой ключ, а значит, мы уже выходим за пределы той самой поговорки про двоих знающих), а открытый мы и получатель можем спокойно передавать кому угодно – наш закрытый, секретный, по нему восстановить нельзя. Итого, мы используем открытый ключ получателя для шифрования, а получатель, в свою очередь, использует свой закрытый ключ для расшифровывания. Плюс данного подхода очевиден: мы легко можем начать обмениваться секретной информацией с разными получателями, практически ничем (принимая условие, что наш получатель свой закрытый ключ не потерял/отдал и т.п., то есть не передал его в руки нехорошего человека) не рискуем при передаче информации. Но, без огромного минуса не обойтись. И здесь он в следующем: шифрование и расшифровывание в данном случае идут очень, очень, очень медленно, на два-три порядка медленнее, чем аналогичные операции при симметричном шифровании. Кроме того, ресурсов на это шифрование тратится также значительно больше. Да и сами ключи для данных операций существенно длиннее аналогичных для операций симметричного шифрования, так как требуется максимально обезопасить закрытый ключ от подбора по открытому. А значит, большие объемы информации данным способом шифровать просто невыгодно.
Пример использования асимметричного шифрования [Wikipedia]
e — открытый ключ получателя B
d — закрытый ключ получателя B
m — исходная информация отправителя A
c — зашифрованная исходная информация
И снова возникает вопрос: что же делать? А делать нужно следующее: взять, и скомбинировать оба способа. Собственно, так мы и получаем комбинированное шифрование. Наш большой объем данных мы зашифруем по первому способу, а чтобы донести ключ, с помощью которого мы их зашифровали, до получателя, мы сам ключ зашифруем по второму способу. Тогда и получим, что хоть асимметричное шифрование и медленное, но объем зашифрованных данных (то есть ключа, на котором зашифрованы большие данные) будет маленьким, а значит расшифровывание пройдет достаточно быстро, и дальше уже в дело вступит более быстрое симметричное шифрование.
Пример применения комбинированной системы [Wikipedia]
Все эти механизмы нашли свое применение на практике, и оба наших больших лагеря PGP и S/MIME их используют. Как говорилось в первой статье, асимметричное шифрование используется для цифровой подписи (а именно, для шифрования нашего хэша). Отличие данного применения от обычного асимметричного шифрования в том, что для шифрования используется наш закрытый ключ, а для расшифровывания достаточно наличие связанного с ним (то есть, тоже нашего) открытого ключа. Поскольку открытый ключ мы не прячем, наш хэш можем прочитать кто угодно, а не только отдельный получатель, что и требуется для цифровой подписи.
Комбинированное же шифрование применяется в обоих стандартах непосредственно для шифрования отправляемых данных.
Таким образом, начиная пользоваться цифровыми подписями для защиты наших данных от подмены, мы автоматически (для этих двух стандартов) получаем и замечательную возможность защитить наши данные еще и от прочтения, что, согласитесь, весьма удобно.
Теперь, когда мы познакомились с общими принципами работы механизмов, используемых для защиты наших данных, можно наконец перейти к практике и рассмотрению, что же использовать. Но об этом в следующих статьях.
Эпилог
Инфраструктура открытых ключей, которую необходимо разворачивать при использовании неквалифицированной и квалифицированной электронной подписи, сложна в практическом использовании для большинства людей, чьи интересы лежат вне сферы IT. Простая электронная подпись – это довольно удобная альтернатива инфраструктуре открытых ключей, главным образом, для физических лиц, а также во внутреннем электронном документообороте между сотрудниками организации.
Но, как и в любом процессе, в процедуре подписания ПЭП существуют некоторые нюансы. Надеюсь, эта статья поможет всем заинтересованным лицам увидеть эти подводные камни, и учесть их в проектировании инфраструктуры электронной подписи.
Заключение
В качестве заключения хочу отметить, что использование в рамках прикладного программного обеспечения тех или иных программных интерфейсов и форматов электронной подписи должно соответствовать функциям и задачам данного ПО, не накладывая ограничений и дополнительных требований на пользователя.
