public key что это

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

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

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

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

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

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

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

Источник

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

В основе PKI лежит использование криптографической системы с открытым ключом и несколько основных принципов:

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

Содержание

История

Объекты PKI

PKI реализуется в модели клиент-сервер, то есть проверка какой-либо информации, предоставляемой инфраструктурой может происходить только по инициативе клиента.

Основные задачи

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

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

Основная идея

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

Деятельность инфраструктуры управления открытыми ключами осуществляется на основе регламента системы. Инфраструктура открытых ключей основывается на использовании принципов криптографической системы с открытым ключом. Инфраструктура управления открытыми ключами состоит из центра сертификации (удостоверяющего центра — УЦ), конечных пользователей, и опциональных компонентов: центра регистрации и сетевого справочника.

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

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

Удостоверяющий центр также публикует и списки отозванных сертификатов (Certificate Revocation List/CRL), которые могут использовать клиенты инфраструктуры открытого ключа, когда решают вопрос о доверии сертификату пользователя и/или компьютера.

Ключевая пара — это набор, состоящий из двух ключей: закрытого ключа (private key) и открытого ключа (public key). Эти ключи создаются вместе, являются комплементарными по отношению друг к другу (то, что зашифровано с помощью открытого ключа можно расшифровать, только имея закрытый ключ, а подпись сделанную с помощью закрытого ключа можно проверить используя открытый ключ).

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

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

Некоторые основные моменты

Разберём подробнее следующие моменты:

УЦ и его работа

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

Процесс работы с сертификатами

Какие же бывают PKI по архитектуре, кроме как одиночные УЦ?

Архитектуры PKI

В основном выделяют 5 видов архитектур PKI, это:

В основном PKI делятся на разные архитектуры по следующим признакам:

Рассмотрим более подробно каждую из архитектур PKI в отдельности.

1. Простая PKI

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

2. Иерархическая PKI

Иерархическая структура — это наиболее часто встречающаяся архитектура PKI. В данном случае во главе всей структуры стоит один Головной УЦ, которому все доверяют и ему подчиняются нижестоящие УЦ. Кроме этого головного УЦ в структуре присутствуют ещё не один УЦ, который подчиняется вышестоящему, которому в свою очередь приписаны какие-либо пользователи или нижестоящие УЦ. Частный пример иерархической PKI — корпоративная PKI. Например если у нас есть одна большая фирма, у которой в подчинении множество филиалов по всей стране. В главном здании фирмы есть головной УЦ и в каждом филиале есть УЦ, который подчиняется головному. В иерархической PKI, даже если злоумышленник выдал себя за какой — либо УЦ, сеть продолжает работать без него, а когда он восстанавливает нормальную работоспособность — он просто снова включается в структуру.

3. Сетевая PKI

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

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

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

4. Архитектура кросс-сертифицированной корпоративной PKI

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

5. Архитектура мостового УЦ

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

Внедрение PKI

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

Примеры использования PKI

Электронно-цифровая подпись (ЭЦП)

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

Шифрование сообщений

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

Авторизация

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

Терминология PKI

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

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

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

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

электронный отпечаток (fingerprint)

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

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

данные, зашифрованные при помощи открытого ключа пользователя

Термины, которые необходимы для общего понимания:

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

сертификаты которые хранятся у пользователя в личном хранилище сертификатов.

корневые центры сертификации

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

доверенные центры сертификации

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

Источник

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Источник

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.

Источник