Public key что это

Инфраструктура открытых ключей

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

Концепция инфраструктуры открытого ключа изменилась для помощи в устранении этой проблемы и других. Инфраструктура открытых ключей (PKI) состоит из программных и аппаратных элементов, которые доверенная третья сторона может использовать для установления целостности и принадлежности открытого ключа. Доверенная сторона, называемая центром сертификации (CA), обычно выполняет эту задачу, выдавая подписанные (зашифрованные) двоичные сертификаты, подтверждающие подлинность субъекта сертификата, и привязывает удостоверение к открытому ключу, содержащемуся в сертификате. ЦС подписывает сертификат с помощью его закрытого ключа. Он выдает соответствующий открытый ключ всем заинтересованным сторонам в самозаверяющего сертификата ЦС. При использовании ЦС предыдущий пример можно изменить следующим образом:

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

Типичная PKI состоит из следующих элементов.

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

В следующих разделах инфраструктура открытых ключей Майкрософт обсуждается более подробно:

Источник

Про PKI «на пальцах» за 10 минут

Предложил коллегам провести внутреннюю мини-лекцию по сабжу — идея зашла. Сел писать план лекции и… чот психанул — в итоге очнулся, дописывая небольшой гайд. Подумал, что будет полезно добавить сюда что-то для быстрого понимания, что такое PKI, зачем она нужна и как работает, так как пока готовился, чтобы освежить память, искал информацию в том числе на полюбившемся «Хабрахабре», но статей в таком формате не нашел.

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

Без теории не обойтись

PKI (Public Key Infrastructure, инфраструктура открытых ключей) — это про безопасность. Подразумевается, что у каждой сущности в инфраструктуре есть свой ключ, которым она однозначно идентифицируется. То есть, если ключ украден, пострадавшей сущностью может представиться укравший. PKI нужна для того, чтобы оперативно минимизировать последствия такой кражи. Ключ представлен двумя частями: публичной и приватной.

Аналог — это RSA ключи для SSH, но инфраструктурой их назвать сложно, так как отсутствует централизованный механизм управления ими. Также разница в том, что публичная часть ключа в паре ключей для SSH неизменна, а сертификат (публичную часть ключа участника PKI) можно перевыпустить в любой момент.

В PKI существует один (на самом деле, должно быть минимум два) или несколько Certification Authority — центров сертификации (удостоверяющих центров), отдающих публичные части своих ключей клиентам, которым выдают подписанные ими сертификаты. Таким образом, участники инфраструктуры «понимают», кто ими управляет, и действителен ли сертификат, выданный им или их «товарищам», в настоящий момент времени (одним из важнейших атрибутов сертификатов является срок их действия). Либо же сервер, у которого есть публичная часть ключа CA инфраструктуры, в которой он и его клиенты работают, понимает, что к нему пришел клиент с действительным сертификатом, и разрешает ему что-то, или запрещает в противном случае.

OpenVPN: как это бывает

На самом деле во многих компаниях на этот случай уже есть «PKI» и у него есть имя, потому что это кто-то из сотрудников. Назовем такого человека, к примеру, Полуэкт (с) и расскажем, как обычно это работает, а потом я расскажу, как это должно быть в идеале.

При появлении в компании нового сотрудника Полуэкт создает и присылает ему архив, в котором, помимо конфигурации собственно OpenVPN клиента, находятся файлы (на примере сотрудника Иванова А.А.):

В компании Acme все эти файлы генерирует Полуэкт…

А теперь как должно быть

На моем примере, упрощенно:

Please enter the following ‘extra’ attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:

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

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

И про срок действия клиентского сертификата: если предположить, что я устроился в Pixonic по временному контракту на 3 месяца, и мы его не продлили, то в описанной ситуации мой доступ к VPN автоматически отключится через 90 дней с момента выпуска сертификата. Чего не случится с SSH-доступом, если коллеги забудут отключить аккаунт во FreeIPA или удалить строчку из authorized_keys руками. C — сесуриту.

Теперь по Борщеву HTTPS

Предположим, вы хотите «включить SSL» для вашего сайта, чтобы у посетителей появился красивый замочек в браузере. Тут, собственно, все то же самое, но с некоторыми нюансами:

Источник

Что такое публичный ключ криптовалютного кошелька (биткоин-адрес)?

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

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

Навигация по материалу:

Что такое публичный ключ и как он выглядит?

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

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

Состоит публичный ключ 26-35 символов, которые могут быть буквами латинского алфавита (кроме O, l и I) в нижнем и верхнем регистре и цифрами (кроме 0). Выглядит биткоин-адрес примерно так:

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

Виды публичных ключей

Есть два типа публичных ключей.

Обычный — начинается с 1, и для получения средств на него пользователь должен подтвердить то, что знает приватный ключ. Он выглядит вот так:

Второй вариант — публичный ключ с мульти-подписью. Он начинается с 3, и для получения средств пользователь должен иметь больше одного закрытого ключа. Пример ключа с мульти-подписью:

Как узнать свой открытый ключ?

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

Место хранения адреса зависит от используемого кошелька, но обычно есть два варианта:

Роль адреса в отправке транзакций

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

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

Система использования биткоин-адресов

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

А теперь о том, как технически проходит транзакция.

После того как сгенерирован приватный ключ, на его основе создается публичный ключ, состоящий из ряда символов (максимум 35) и отображается на экране в виде QR-кода.

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

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

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

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

Дата публикации 05.06.2019
Поделитесь этим материалом в социальных сетях и оставьте свое мнение в комментариях ниже.

Источник

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

По умолчанию инженеры подключаются к сетевому оборудованию с помощью имени пользователя и пароля. По протоколу Telnet учетные данные пользователя передаются в открытом виде, а по протоколу SSH в зашифрованном. Чтобы не передавать секретную часть по сети, используется аутентификация по публичным ключам. При такой аутентификации публичный ключ пользователя заранее прописывается пользователю на оборудовании. Секретный ключ по сети не передается.

Это руководство поможет вам быстро начать использовать публичные ключи для аутентификации при подключении к сетевому оборудованию по протоколу SSH. Руководство применимо как для Windows, так и для Mac OS X. Я постарался сделать его максимально простым и информативным. Оно не перегружено, но отвечает на основные вопросы:

Содержание

Введение

Кроме стандартной аутентификации по паролю (password/keyboard) в протоколе SSH существует также аутентификация по публичному ключу (RSA).

Аутентификация с помощью RSA-ключей состоит из нескольких этапов:

Документ Secure Shell Configuration Guide, Cisco IOS Release 15E:

Secure Shell Configuration Guide, Cisco IOS Release 15E
Restrictions for Secure Shell Version 2 Support
Rivest, Shamir, and Adleman (RSA) key generation is an SSH server-side requirement. Devices that act as SSH clients need not generate RSA keys.

Попытка ввести данные DSA-ключа:

Создание публичного RSA-ключа

Пару RSA-ключей можно создать с помощью различных утилит: SecureCRT, PuTTYgen или любым другим ПО. При создании ключа можно задать Passphrase (защита ключа с помощью пароля).

Генерирование RSA-пары в SecureCRT

SecureCRT → Tools → Create Public Key…:

Чуть-чуть теории → кнопка “Next >”:

Тип сертификата RSA/DSA → Выбираем RSA → кнопка “Next >”:

Пароль шифрования для секретного ключа (необязательно, можно оставить пустым и не шифровать) + Комментарий → кнопка “Next >”:

Выбираем длину ключа (в версии SecureCRT 6.1.0 максимальная длина ключа равна 2048 бит, в версии 8.5.4 — 16 384 бит):

Генерирование ключа → кнопка “Next >”:

Для генерирования случайных чисел нужно просит поводить мышкой в рамках окна.

Сохранение пары ключей → Выбор места хранения → Выбор формата сохраняемого ключа (VanDuke Private format, OpenSSH legacy, OpenSSH new) → кнопка “Finish”:

SecureCRT спрашивает, делать ли данный ключ ключом по умолчанию для SecureCRT:

Генерирование RSA-пары в PuTTYgen

Выбираем параметры (тип пары: RSA; битная размерность ключа: 2048; по желанию задаём Passphrase (защита ключа с помощью пароля)) → Generate:

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

Сохраняем RSA-ключи → Кнопка «Save private key»:

Обратите внимание: RSA-ключи, сохраненные в частном формате в одном ПО, нельзя использовать в ПО другого производителя. То есть пара RSA-ключей, созданных в PuTTYgen и сохраненных в формате Putty Private Key, не подходит для использования в SecureCRT, и наоборот. PuTTY поддерживает только формат Putty Private Key. Универсальным решением для распространения ключей является конвертирование ключей в формат OpenSSH (Смотри ссылку 2: “Conversion from Putty to SecureCRT with auth. keys”). Т. к. SecureCRT свободно работает с форматом OpenSSH. А ПО PuTTYgen преобразует формат OpenSSH в формат Putty Private Key.

Конвертирование RSA-ключа из формата Putty Private Key (PuTTY) в формат OpenSSH (SecureCRT)

Чтобы использовать в SecureCRT RSA-ключи, которые сгенерированы в PuTTYgen и сохранены в формате Putty Private Key (*.ppk), экспортируем их с помощью PuTTYgen в формат OpenSSH:

Конвертирование RSA-ключа из формата VanDyke Private Key (SecureCRT) в формат Putty Private Key (PuTTY)

Чтобы использовать в PuTTY RSA-ключи, которые сгенерированы в SecureCRT и сохранены в формате VanDyke Private Key (файл публичного ключа — *.pub, файл секретного ключа *. (без расширения)), экспортируем их с помощью SecureCRT в формат OpenSSH, а затем с помощью PuTTYgen экспортируем в формат Putty Private Key (*.ppk):

Генерирование публичных ключей на MAC OS X средствами операционной системы

Будем использовать встроенную утилиту ssh-keygen (man ssh-keygen).
Генерируем RSA-ключ с длиной 2048 бит с указанием имени ключа, путем к папке с местом хранения ключа:

Во время выполнения программа спросит пароль для защиты RSA-ключа:

Генерируем RSA-ключ с длиной 4096 бит в с указанием имени ключа, путем к папке с местом хранения ключа, пароль задаем в явном виде в параметрах генерации ключа (-N «cisco»):

Не рекомендуемые параметры генерации ключей: ненадёжный ключ длиной 1024 бита, с указанием имени ключа, путем к папке с местом хранения ключа, пароль задаем в явном виде в параметрах генерации ключа (-N «» – без пароля):

Итак, мы создали три ключа в с указанием имен ключей и указанием места хранения ключей (по умолчанию все ключи сохраняются в /Users/[Username]/.ssh).

По умолчанию, при подключении по SSH с аутентификацией по публичному ключу, происходит последовательный перебор всех публичных ключей, которые хранятся в папке /Users/[Username]/.ssh.

Ключ R6: переименуем ключ в “id_rsa” (по умолчанию имя файла генерируемого ключа “id_rsa”) и перенесем в папку с SSH-ключами (

/.ssh/) (Т. е. выполним все действия, чтобы ключ R6 использовался как основной ключ для подключений по SSH по умолчанию):

Преобразуем публичный OpenSSH-ключ в формат RFC4716 (экспорт в Cisco IOS):

Применение публичного ключа на оборудовании

Как на различном оборудовании привязать открытый ключ к пользователю?

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

Cisco IOS XE, Catalyst (с версии 15.1 и выше), IOS

Cisco ASA

Весь ключ вставляем в одну строчку (OpenSSH формат).

Маршрутизаторы и коммутаторы Huawei

Типы форматов ключей, импортируемых на Huawei:

“The SecureCRT and PuTTY generate RSA keys in PEM format.”

“The OpenSSH generates RSA keys in OpenSSH format.”

“The OpenSSL generates RSA keys in DER format.”

По умолчанию — в шестнадцатеричном виде:

Примечание: оборудование Huawei поддерживает не только ключи в формате RSA, но и другие форматы:

Можно жестко задать тип аутентификации для пользователя по SSH:

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

Huawei USG (6000)

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

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

Cisco Nexus 9.3

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

Вариант 2: копируем публичный ключ пользователю:

Использование секретного ключа для подключения по SSH

Этот раздел посвящен настройке SSH-клиентов для аутентификации по RSA-ключам на сетевом оборудовании (или другом оборудовании, при условии, что оборудование и ПО поддерживает аутентификацию по публичным ключам).

Мы рассмотрим настройку использования публичного ключа в самых популярных программах: SecureCRT и PuTTY.

SecureCRT

В окне настроек SSH есть список Authentication. В нём необходимо увеличить приоритет PublicKey до самого высокого — сделать верхним в списке.

Затем перейдите в параметры PublicKey и выберите файл приватного ключа. Самый верхний переключатель позволяет использовать глобальные настройки секретного ключа или сеансовые настройки — другой секретный ключ (ключ не по умолчанию) — только для этого подключения.

Настраиваем глобальный публичный ключ: в меню Options → Global options → Категория SSH2.

PuTTY

В настройках SSH (Connection → SSH → Auth) в поле “Private key file for authentication” укажите файл Putty Private Key (*.ppk):

MAC OS X

Настройка стандартного клиента для использования публичных ключей:

Как упростить работу с SSH на MAC OS X:

Заполняется таким образом:

Примечание: у меня некорректно настроено подключение по умолчанию (как правильно, я не знаю), потому что подключение к хосту R6 (10.31.73.31) выполняется очень долго. Рекомендуется указать сразу указать путь к ключу по умолчанию.

Пример подключения по ssh используя публичные ключи и файл config:

Заключение

RSA-ключи могут использоваться для замены аутентификации по паролю, но не во всех случаях:

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

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

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

Рекомендуется использовать публичные ключи для замены паролей, если пароли вводятся с помощью скриптов (пример: autologon в SecureCRT).

Рекомендуется использовать публичные ключи для защиты от передачи пароля по сети.

Некоторое ПО по умолчанию использует публичные ключи для аутентификации по SSH вместо пароля (пример: Ansible).

Источник

Public Key Cryptography: осваиваем открытые ключи на практике

Содержание статьи

Картина мира

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

Информация, необходимая для работы PKI, содержится в сертификате X.509. В PKI участвуют как минимум три стороны: Алиса, Боб и удостоверяющий центр (УЦ). У Алисы и Боба есть сертификаты с закрытым ключом, подписанные так называемым корневым сертификатом УЦ. У Алисы есть сертификат Боба с открытым ключом, а у Боба — сертификат Алисы с открытым ключом. Алиса и Боб доверяют УЦ и благодаря этому могут доверять друг другу.

Упрощенная структура PKI

Xakep #206. Ключ от всех дверей

Сертификаты X.509

Так повелось, что основным «активом» в PKI является сертификат X.509. Сертификат — это что-то вроде паспорта, он содержит информацию, позволяющую идентифицировать субъект, которому выдан сертификат (поле Subject), указывает, кем он был выпущен (поле Issuer), серийный номер сертификата и многое другое. В Windows управлять сертификатами можно с помощью оснастки «Сертификаты» ( run->certmgr.msc ).

Менеджер сертификатов

Сертификаты хранятся в хранилищах («Личное», «Доверенные центры сертификации», «Доверенные лица». ).

При получении сертификата важно установить его в правильное хранилище. Так, сертификаты, которые ты хочешь использовать для электронной подписи, должны быть установлены в хранилище «Личное», а сертификаты получателей, которым нужно будет отправлять зашифрованные сообщения, — в хранилище «Доверенные лица». Сертификаты удостоверяющих центров (УЦ) должны быть установлены в хранилище «Доверенные корневые центры сертификации». При установке сертификата система предлагает два варианта: выбрать хранилище автоматически либо указать вручную. Рекомендую использовать второй вариант, так как автоматика иногда устанавливает сертификат не в то хранилище. Сертификат, которым мы хотим подписывать сообщения, должен иметь закрытый ключ. О наличии закрытого ключа можно узнать, посмотрев на свойства сертификата, где русским по белому будет написано: «есть закрытый ключ для этого сертификата».

Закрытый ключ для сертификата

Самое интересное о сертификате мы можем узнать на вкладке «Состав».

Состав сертификата

Обрати внимание на поля «Алгоритм подписи», «Алгоритм хеширования подписи» и «Открытый ключ». Если хочешь использовать сертификат для осуществления транзакций в России, во всех этих полях ты должен видеть слово «ГОСТ». Также следует обратить внимание на значение поля «Использование ключа» и поля «Действителен с» и «Действителен по»: первое позволит понять, возможно ли использование сертификата для выполнения нужной нам операции (шифрование, подпись), а второе и третье — возможно ли использовать данный сертификат в указанный момент времени. В дополнение к этому следует убедиться, что сертификат действителен. В этом нам поможет вкладка «Путь сертификации». Если с сертификатом все хорошо, мы увидим надпись: «Этот сертификат действителен».

Состояние сертификата

WARNING

Цифровая подпись

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

Электронная подпись применяется не только в спецслужбах и органах, но и в бизнесе. Например, для перевода пенсионных накоплений в НПФ: мы генерируем запрос на сертификат, отправляем его в удостоверяющий центр (УЦ). УЦ выпускает сертификат, мы подписываем сертификатом заявление на перевод пенсионных накоплений, отправляем — и вуаля. Подпись также позволяет осуществлять контроль целостности подписываемых данных. Если данные будут изменены, подпись не пройдет проверку.

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

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

Прикрепленная и открепленная подписи

Результатом прикрепленной подписи будет CMS (Cryptography Message Syntax) — сообщение, содержащее как подписываемые данные, так и саму подпись. Открепленная подпись содержит только саму подпись. Рекомендую использовать именно открепленную подпись, потому что с ней намного меньше мороки. В нее проще поставить метку времени, она меньше весит, так как не содержит подписываемые данные. Подписываемые данные легко открыть, посмотреть. В случае прикрепленной подписи для того, чтобы просмотреть подписанные данные, CMS-сообщение необходимо сначала декодировать. В общем, прикрепленной подписи я рекомендую избегать всеми силами. Если потребуется передавать подпись и контент вместе, рассмотри вариант архивирования (вместо использования прикрепленной подписи используй открепленную, просто заархивируй подписываемый файл и открепленную подпись). Посмотрим на код подписи (С#):

На C++ будет что-то вроде:

Вызов кода на C++ из C# будет выглядеть примерно так:

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

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

Если пользователь прислал тебе отчет в виде прикрепленной подписи, тебе для чтения придется его декодировать:

А так будет выглядеть код проверки подписи при вызове из C#:

Шифрование

Зачем нужно шифрование, все уже знают. PKI нам дает полезную плюшку: мы можем зашифровать один документ так, что расшифровать его смогут несколько получателей. Это очень удобно. Для этого нам нужно иметь сертификаты получателей.

Расшифрование

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

Заключение

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

За кадром остались поточное шифрование и расшифрование, подпись несколькими сертификатами, генерация запросов на сертификат и многое другое, но основу я тебе показал. Код примеров с тестами можно скачать на GitHub.

Источник