Электронная цифровая подпись | Контроль Разума | Fandom

Введение.

Стандарты и закон, на которые ссылается эта лекция.

ГОСТ Р 34.10-2022 (полное название: «ГОСТ Р 34.10-2022. Информационная технология. Криптографическая защита информации. Процессы формирования и проверки электронной цифровой подписи»)

ГОСТ Р 34.11-2022 «Информационная технология. Криптографическая защита информации. Функция хэширования»

Федеральный закон от 06.04.2022 N 63-ФЗ (ред. от 23.06.2022) «Об электронной подписи» (с изм. и доп., вступ. в силу с 31.12.2022)

Что такое электронная подпись

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

Электронная цифровая подпись (ЭЦП) — это совокупность средств, позволяющих однозначно удостовериться в том, что автором документа (или исполнителем какого-то действия) является именно то лицо, которое называет себя автором. В этом смысле ЭЦП полностью аналогична традиционной подписи: если в обычном «бумажном» документе указано, что его автор Иванов, а внизу стоит подпись Петрова, вы справедливо можете усомниться в авторстве Иванова.

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).

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

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

Генерирование открытого и секретного ключей

Итак, вы решили самостоятельно изготовить усиленную неквалифицированную электронную подпись и научиться подписывать ею свои документы. Начать необходимо, конечно, с генерирования пары ключей, открытого (public key) и секретного (private key).

Существует множество стандартов и алгоритмов асимметричного шифрования. Одной из библиотек, реализующих эти алгоритмы, является PGP (Pretty Good Privacy). Она была выпущена в 1991 году под проприетарной лицензией, поэтому имеются полностью совместимые с ней свободные библиотеки (например, OpenPGP).

Одной из таких свободных библиотек является выпущенная в 1999 году GNU Privacy Guard (GnuPG, или GPG). Утилита GPG традиционно входит в состав почти всех дистрибутивов Линукса; для работы из-под Windows необходимо установить, например, gpg4win. Ниже будет описана работа из-под Линукса.

Сначала сгенерируем собственно ключи, подав (из-под обычного юзера, не из-под root’а) команду

gpg --full-generate-key

В процессе генерирования вам будет предложено ответить на ряд вопросов:

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

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

gpg --export -a "Иван Иванович Иванов" > public.key
gpg --export-secret-key -a "Иван Иванович Иванов" > private.key

Понятно, что private.key вы должны хранить в секрете, а вот public.key вы можете открыто публиковать и рассылать всем желающим.

Защищённость[]

Цифровая подпись обеспечивает:

• Удостоверение источника документа. В зависимости от деталей определения документа могут быть подписаны такие поля, как «автор», «внесённые изменения», «метка времени» и т. д.
• Защиту от изменений документа. При любом случайном или преднамеренном изменении документа (или подписи) изменится хэш, следовательно, подпись станет недействительной.
• Невозможность отказа от авторства. Так как создать корректную подпись можно лишь, зная закрытый ключ, а он известен только владельцу, то владелец не может отказаться от своей подписи под документом.
• Предприятиям и коммерческим организациям сдачу финансовой отчетности в государственные учреждения в электронном виде;
• Организацию юридически значимого электронного документооборота;

Возможны следующие угрозы цифровой подписи:

• Злоумышленник может попытаться подделать подпись для выбранного им документа.
• Злоумышленник может попытаться подобрать документ к данной подписи, чтобы подпись к нему подходила. Однако в подавляющем большинстве случаев такой документ может быть только один. Причина в следующем:

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

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

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

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

Тем не менее, возможны ещё такие угрозы системам цифровой подписи:

Интерфейсы для доступа к скзи

На сегодняшний день широкое распространение получили один промышленный стандарт работы с СКЗИ и один (фактически два) проприетарный интерфейс всеми известной компании Microsoft.

Использование эцп в других странах[]

Система электронных подписей широко используется в Эстонской Республике, где введена программа ID-карт, которыми снабжены 3/4 населения страны.

При помощи электронной подписи в марте 2007 года были проведены выборы в местный парламент — Рийгикогу.

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

Использование эцп в россии[]

После становления ЭЦП при использовании в электронном документообороте между кредитными организациями и кредитными бюро в 2005 году активно стала развиваться инфраструктура электронного ДОУ между налоговыми органами и налогоплательщиками.

Начал работать приказ Министерства по налогам и сборам Российской Федерации от 2 апреля 2002 г. N БГ-3-32/169 «Порядок представления налоговой декларации в электронном виде по телекоммуникационным каналам связи». Порядок представления налоговой декларации в электронном виде по телекоммуникационным каналам связи определяет общие принципы организации информационного обмена при представлении налогоплательщиками налоговой декларации в электронном виде по телекоммуникационным каналам связи.

В Законе РФ от 10.01.2002 № 1-ФЗ «ОБ ЭЛЕКТРОННОЙ ЦИФРОВОЙ ПОДПИСИ» прописаны условия использования электронной цифровой подписи, особенности ее использования в сферах государственоого управления и в корпоративной информационной системе.
Благодаря электронной цифровой подписи теперь, в частности, многие российские компании осуществляют свою торгово-закупочную деятельность в Интернете, через «Системы электронной торговли», обмениваясь с контрагентами необходимыми документами в электронном виде, подписанными ЭЦП. Это значительно упрощает и ускоряет проведение конкурсных торговых процедур.

Общая схема[]

Схема электронной подписи обычно включает в себя:

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

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

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

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

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

Алгоритмы ЭЦП делятся на два больших класса: обычные цифровые подписи и цифровые подписи с восстановлением документа. Обычные цифровые подписи необходимо пристыковывать к подписываемому документу. К этому классу относятся, например, алгоритмы, основанные на эллиптических кривых (ECDSA, ГОСТ Р 34.

10-2001, ДСТУ 4145-2002). Цифровые подписи с восстановлением документа содержат в себе подписываемый документ: в процессе проверки подписи автоматически вычисляется и тело документа. К этому классу относится один из самых популярных алгоритмов — RSA.

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

Подписание документа

Нет ничего проще, чем создать отсоединенную ЭЦП в текстовом (ASCII) формате:

gpg -ba имя_подписываемого_файла

Файл с подписью будет создан в той же папке, где находится подписываемый файл и будет иметь расширение asc. Если, например, вы подписали файл privet.doc, то файл подписи будет иметь имя privet.doc.asc. Можно, следуя традиции, переименовать его в privet.sig, хотя это непринципиально.

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

#!/usr/bin/python
# -*- coding: utf-8 -*-
from Tkinter import *
from tkFileDialog import *
import os, sys, tkMessageBox

def die(event):
    sys.exit(0)

root = Tk()
w = root.winfo_screenwidth()//2 - 400
h = root.winfo_screenheight()//2 - 300
root.geometry("800x600 {} {}".format(w, h))
root.title("Подписать документ")

flName = askopenfilename(title="Что подписываем?")

if flName:
    os.system("gpg -ba "   flName)
    button = Button(text="ЭЦП создана")
    button.bind("<Button-1>", die)
    button.pack(expand=YES, anchor=CENTER)
else:
    die()

root.mainloop()

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

Вряд ли, конечно, вам самому придется проверять достоверность собственной электронной подписи, но если вдруг (на всякий случай) вам захочется это сделать, то нет ничего проще:

gpg --verify имя_файла_подписи имя_файла_документа

В реальности гораздо полезнее опубликовать где-нибудь в открытом доступе (например, на вашем персональном сайте или на сайте вашей организации):

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

К счастью для нас, имеется свободная библиотека OpenPGP.js; скачиваем самый маленький по размеру (на момент написания данного туториала — 506 КБ) файл dist/lightweight/openpgp.min.js и пишем несложную html-страничку (для упрощения восприятия я удалил все описания стилей и очевидные meta-тэги):

Проприетарные интерфейсы

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

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

Процедура формирования цифровой подписи

На подготовительном этапе этой процедуры абонент А — отправитель сообщения — генерирует пару ключей: секретный ключ kA и открытый ключ КА. Открытый ключ КА вычисляется из парного ему секретного ключа kA.

Открытый ключ КА рассылается остальным абонентам сети (или делается доступным, например, на разделяемом ресурсе) для использования при проверке подписи. Для формирования цифровой подписи отправитель А прежде всего вычисляет значение хэш- функции h(M) подписываемого текста M (рис. 1).

Рис. 1. Схема формирования электронной цифровой подписи.

Хэш-функция служит для сжатия исходного подписываемого текста М в дайджест — относительно короткое число, состоящее из фиксированного небольшого числа битов и характеризующее весь текст M в целом (Рис. 2).

Рис. 2. Схема формирования хэша H = h(M) (дайджеста сообщения М).

Далее отправитель А шифрует дайджест m своим секретным ключом kA. В результате получается цифровая подпись для данного текста M. Сообщение М вместе с цифровой подписью отправляется в адрес получателя.

См. также[]

cs:Elektronický podpisda:

Digital signaturde:Elektronische Signaturen:Digital signaturees:

Firma digitalet:Digitaalallkirifi:

Digitaalinen allekirjoitusfr:Signature numériquehe:חתימה אלקטרוניתit:Firma digitalekk:

Сандық қолтаңбаnl:Digitale handtekeningpl:Podpis cyfrowypt:

Assinatura digitalsl:Digitalni podpistr:

Sayısal imzauk:

Електронно-цифровий підписvi:Chữ ký sốzh:數位簽章

Сырая подпись

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

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

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

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

Управление ключами[]

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

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

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

Форматы электронной подписи

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

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

Электронная цифровая подпись для чайников: с чем ее есть и как не подавиться. часть 3

Юридические аспекты[]

В России юридически значимый сертификат электронной подписи выдаёт удостоверяющий центр.
Правовые условия использования электронной цифровой подписи в электронных документах регламентирует ФЕДЕРАЛЬНЫЙ ЗАКОН ОТ 10.01.2002 N 1-ФЗ «ОБ ЭЛЕКТРОННОЙ ЦИФРОВОЙ ПОДПИСИ»

Заключение

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