Блокчейн сеть в Hyperledger включает в себя различных участников: пиры (peers), заказчики (orderers), клиентские приложения, администраторы и т.д. Каждый из этих элементов сети имеет свой собственный цифровой идентификатор - X.509 сертификат. Этот идентификатор очень важен так как благодаря ему понятно какие права есть в сети у того или иного участника сети и действительно ли он тот, за кого себя выдаёт.

Так как это работает?

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

Правило 1: Не важно сколько у вас карт и сколько в общем денег, не все карты одобрены.

Если перевести это правило в Hyperledger:

• Центр сертификации PKI выступает в роли поставщика карт (выдает сертификаты множеству узлов, пользователей и т.д.)
• MSP - список карт, которыми вы можете оплатить (список организаций)

Что такое PKI?

Инфраструктура открытых ключей (PKI) это набор технологий, который обеспечивает безопасную связь в сети. В частности, благодаря этой PKI появился HTTPS. Благодаря PKI вы можете быть уверены в валидности источника.

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

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

Правило 2: Не всем ЦС можно доверять.

4 основных элемента PKI:

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

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

Сертификаты (Цифровые сертификаты)

Цифровой сертификат - это цифровой документ, который содержит множество атрибутов, связанных с владельцем. В Hyperledger каждый сертификат соответствует стандарту X.509. Если есть желание поковыряться в стандарте.

Для примера представим ситуацию что Гогиев Гога имеет свой собственный электронный сертификат. При этом он работает в org1, в отделе разработки и живёт в великолепной стране - Казахстан. Так вот при запросе сертификата он обозначил следующие данные: C=KZ, ST=Astana, O=org1, OU=Developers, CN=Гогиев Гога. Конечно он мог написать какую-то чушь, но тогда центр сертификации просто отклонил бы его заявку, и он остался без сертификата.

Всё что он заполнил хранится в сертификате, собственно подтверждая своего владельца. Для просмотра содержимого сертификата можно выполнить openssl x509 -in personal.crt -text -noout

openssl x509 -in personal.crt -text -noout | grep Subject

Subject: C = KZ, ST = Astana, L = Astana, O = org1, OU = Developers, CN = Goga Gogiyev, emailAddress = goga@org1.com

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

Правило 3: Никогда не отдавайте свой сертификат третьим лицам.

Аутентификация, открытые ключи и закрытые ключи

Для того, чтобы обменятся сообщениями узлы в сети должны пройти аутентификацию. Это необходимо чтобы все узлы в сети были уверенны в том, что они коммуницируют с действительно тем узлом. Т.е. узел, который, например, выдаёт себя за peer1.org3 является им. Если же мы продолжаем примера с Гогой, то допустим он отправил вам файл с секретной информацией. И вот чтобы вы не сомневались, что это его сообщение он подписал его своим приватным ключом. Тем самым подтверждая свою личность.

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

Мы уже говорили, что один из основных элементов PKI это закрытый (private) и открытый (public) ключ. Так вот если возвращаться к примеру, то Гога подписал свой файл приватным ключом и отправил файл другому человеку. Человек получив файл должен ещё проверить что файл действительно от Гоги. Для этого ему понадобится публичный сертификат (ключ) Гоги, который Гога ему любезно предоставил ещё ранее.

1. Гога подписывает файл приватным ключом

echo "Очень секрктая информация" > message.txt
openssl dgst -sha256 -sign goga_private.key -out signature.sha256 message.txt

1. Вторая сторона, получив файл проверяет что подписано именно Гогой

openssl dgst -sha256 -verify public.pem -signature signature.sha256 message.txt

Verified OK

Хорошо мы проверили что файл действительно от Гоги, но что если его изменили? Для того, чтобы такого не было Гога при подписи создал файл signature.sha256, который был сгенерирован тоже при помощи приватного ключа. Конечно же Гога передал этот файл вместе с секретным файлом. Давайте попробуем внести изменения в файл и снова проверить его.

echo "Кто-то что-то поменял" >> message.txt
openssl dgst -sha256 -verify public.pem -signature signature.sha256 message.txt

Verification Failure

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

Важный момент если кто-то раньше генерировал Hash файла может подумать что это именно он содержится в файле signature.sha256, но это не совсем так. Да там хэш файла, но также подписанный (зашифрованный) приватным ключом.

Правило 4: Никогда не отдавайте свой приватный ключ третьим лицам.

Центр сертификации

Не раз уже упоминал о нём в своих статьях про Hyperledger, так как является основным компонентом. Как вы уже поняли узел или пользователь может коммуницировать с остальными узлами в сети используя цифровой сертификат. Так вот выдают эти сертификаты в Hyperledger именно центры сертификации. Рекомендуется использовать свой центр сертификации для каждой организации, даже по два. Сертификаты, выдаваемые ЦС соответствуют стандарту X.509.

В интернете очень много доверенных ЦС: GeoTrust, DigiCert, GoDaddy, Comodo, Sectigo и т.д. Мы сейчас не будем затрагивать тему кто решил, что они доверенные, об этом писать долго.

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

Корневые центры сертификации, промежуточные центры сертификации и цепочки доверия

Сами ЦС можно разделить на два вида:

• Корневой (Root)
• Промежуточный (Intermediate)

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

Второй вариант для чего использовать корневой ЦС и промежуточный это безопасность. Идея в том, что вы выпускаете сертификат для промежуточного ЦС используя корневой ЦС. Далее корневой ЦС выключается и включается только по необходимости. Тут вы оберегаете свой корневой ЦС от кибератак, а если вдруг ваш промежуточный взломали вы просто включаете корневой ЦС и отзываете сертификаты промежуточного ЦС, в таком случае все сертификаты выданные промежуточным ЦС станут не валидными. Ну и опять-таки если у вас десятки промежуточных ЦС взломав один злоумышленник получит к 100-1000 сертификатам вместо миллионов.

Fabric CA

Теперь, когда мы понимаем насколько важны цифровые сертификаты и центры сертификации, которые их выдают понятное дело, что не использовать их не получится. Так вот чтобы было проще с выпуском сертификатов конечному пользователю Hyperledger добавил компонент Fabric CA. С помощью него вы легко можете поднять для своей организации ЦС и выдавать сертификаты узлам или пользователем в сети. Но если вы хотите использовать его и для выдачи SSL сертификатов для своего сайта, то не получится.

Списки отзыва сертификатов

Я уже упоминал что сертификаты можно отозвать и отозванный сертификат перестанет быть валидным. Но как конечный пользователь должен понять, что сертификат не валидный? Для этого используется список отзыва сертификатов - по сути просто список с сертификатами, которые отозвал ЦС по разным причинам. Да, причины обычно указываются. Если возвращаться к примеру, с кредитными картами, то можно представить список отзыва сертификатов как список с утерянными или украденными картами.

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

Правило 4: CRL должен быть доступен для всех пользователей.

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

Автор черпал знания с сайта https://hyperledger-fabric.readthedocs.io/.