Система распространения полномочий и сертификатов открытых ключей на базе корпоративного блокчейна

Шарапов Роман Андреевич, студент 4-ого курса ФРТК МФТИ, sharapov.roman@gmail.com.

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

Ключевые слова:

Удостоверяющий центр, сертификат открытого ключа, иерархическая система PKI, корпоративный блокчейн, PBFT

Классическая PKI система, несмотря на надёжность и проверенность временем, имеет ряд недостатков, которые так и не были исправлены. Необходимость сверки своих данных с CRL на центральном сервере до принятия сертификата приводит к следующим проблемам:

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

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

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

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

Выбор алгоритма консенсуса

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

Каким же должен быть консенсус в данной системе.

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

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

Алгоритм консенсуса, удовлетворяющий всем обозначенным выше требованиям является Practical Byzantine Fault Tolerance (PBFT), основанный на классической задаче византийских генералов.

Рассмотрим алгоритм PBFT подробнее:

1. В каждом раунде есть узел лидер (или арбитр), который предлагает заготовку следующего блока и распространяет ее по сети. Этот лидер выбирается раз в цикл случайным образом.
2. Узлы валидаторы голосуют за предложенный блок, распространяя «prevote» сообщение, которое обозначает то, что узел смог распознать сообщение и подтверждает, что информация в сообщении корректна.
3. После того как валидатор собрал достаточное количество prevote сообщений с большинства узлов, то он подтверждает транзакцию и распространяет «precommit» сообщение, которое содержит содержимое блока и его хэш. Это сообщение означает, что узел готов поместить соответствующий блок в блокчейн, но ожидает одобрения других узлов валидаторов.
4. В конце раунда, если валидатор собрал превалирующее большинство «precommit» сообщений с тем же хэшом состояния для того же предложения, тогда предложенная заготовка блока становится блоком и помещается в конец блокчейна [2, 3].

Лесли Лэмпортом доказал, что если злоумышленники не могут искажать информацию в узлах, то в системе с m скомпрометированными узлами можно достичь согласия при наличии 2*m+1 верно работающих узлов, то есть двух третей от общего количества [4]. При обмене информацией появляется возможность определить «предателя», который всем остальным участникам процесса сообщил разные данные, — этот вредоносный узел помещается в карантин и в дальнейшем не учитывается.

Набор, состоящий минимум из 2/3 prevote сообщений от узлов за предложенный блок в текущем раунде и текущей высоте блокчейна (количество блоков в цепи), называется Proof-of-Lock (PoL) состоянием. Узлы хранят PoL состояние как часть состояния узла, при этом один узел не может хранить больше чем одно PoL состояние.

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

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

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

Анкоринг

Анкоринг – это метод сохранения «слепка» последней рабочей нескомпрометированной версии блокчейна, то есть создания последнего необратимого блока (Last Irreversible Block – LIB). Это блок, который был подтверждён двумя третями (или больше) узлов валидаторов и затем выслан в публичный блокчейн. Ни один узел не переключится на форк, который не был построен на основании последнего необратимого блока.

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

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

Схема анкоринга изображена на рисунке ниже.

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

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

В случае автоматизации процесса анкоринга, необходимо учитывать то, что блоки на публичной цепи чаще всего создаются с нерегулярными интервалами, значительно превышающими интервалы между блоками на эксклюзивном блокчейне. По этой причине протокол привязки может указывать, что заголовок блока в эксклюзивной цепи может (но не обязан) включать SPV-доказательство транзакции-свидетельства одного из предыдущих блоков эксклюзивного блокчейна. Например, если блоки в эксклюзивной цепи создаются с интервалом в 10 секунд:

1. Транзакцию-свидетельство можно отсылать для одного из 180 блоков (т. е. каждые полчаса).
2. Транзакция-свидетельство должна приобрести необходимое количество подтверждений, чтобы реорганизация блокчейна, которая исключила бы свидетельство из вспомогательного блокчейна стала статистически маловероятным событием.
3. После этого SPV-доказательство, соответствующее свидетельству, можно включить в заголовок блока эксклюзивной цепи.

PKI составляющая системы

Рассмотрим имплементацию блокчейна в классическую иерархическую PKI систему:

1. Доставка сертификата до конечного пользователя: у злоумышленника не должно быть возможности вмешаться в процесс распространения публичных ключей и отзыва сертификата. В классической централизованной системе доставка сертификата до пользователя уязвимым моментом, в случае если генерация пары ключей идет на стороне УЦ и надо доставить закрытый ключ клиенту. При установке программного обеспечения на машину клиента, ему генерируется пара ключей для его узла в блокчейне, а факт создания нового узла фиксируется в транзакции и заносится в блокчейн с указанием публичного ключа кошелька. При запросе сертификата и генерации приватного ключа на стороне УЦ, УЦ шифрует приватный ключ сертификата на открытом ключе кошелька клиента, и посылает полученное сообщение клиенту, который расшифровывает сообщение свои закрытым ключом кошелька. В транзакции фиксируется факт выдачи закрытого ключа сертификата, но не сам ключ, а лишь его хэш.
2. Стандарт сертификата: в качестве сертификата должен использоваться стандарт X.509.
3. Доступность и отказоустойчивость: у любого клиента должна быть возможность в любой момент времени обратиться к списку отозванных сертификатов для проверки сертификата. CRL будет храниться полностью в УЦ, также его копии будут храниться на мастернодах, к которым лайтноды могут обратиться в любой момент для прочтения списка. Лайтнодам необходимо дать возможность скачать CRL целиком при запуске программного обеспечения. В небольших корпорациях этот список не должен быть слишком большим и тяжелым, так что объем информации, хранимый на лайтноде-клиенте будет по силам даже для слабых машин. Этот список полностью скачивается и синхронизируется при запуске, затем он просто обновляется, считывая транзакции из поступающих в блокчейн блоков. Если УЦ, один или несколько мастернодов выйдут из строя, то у клиента все равно будет возможность обратиться к CRL либо на других узлах, либо прочитать его у себя на узле.
4. Неотказуемость: все операции будут фиксироваться в блокчейне в виде транзакций (с указанием всех данных участников транзакций, включая публичный ключ блокчейн узла), в результате в случае необходимости можно будет отследить всю историю операций в сети, даже в случае компрометации УЦ и части мастернодов. Перечислим эти транзакции: запрос на выдачу сертификата/на становление узлом фиксатором/на отзыв сертификата, отказ/выдача сертификата клиенту, генерация и выдача приватного ключа, добавление сертификата в CRL, добавление/ удаление нового узла.

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

1. Генерация первого блока данных, который бы содержал информацию обо всех сертификатах аккредитованных УЦ, должна быть осуществлена единым центром, которому все участники сети доверяют. Под аккредитацией должна пониматься процедура проверки безопасности УЦ и соблюдение ими правил выпуска сертификатов пользователей. В этом случае, УЦ берут на себя роль организаций ответственных за постоянную актуализацию базы данных. Свой статус они должны будут поддерживать периодически, подписывая блоки с данными действующих сертификатов.
2. В свою очередь УЦ обязаны требовать от пользователей прохождения аутентификации по паспорту или другим официальным документам при получении сертификата. В случае если пользователь отправляет УЦ информацию об отзыве сертификата он обязан выпустить новый блок без данных отозванного сертификата.
3. Пользователи сертификатов обязаны хранить у себя всю цепочку блоков для каждого сертификата.
4. Отсутствие цепочки блоков у пользователя является доказательством недействительности сертификата.

Во всем остальном (алгоритмы генерации, хранения, проверки и само содержимое сертификатов и CRL листов) PKI система остается без изменений.

Описание работы системы

Теперь перейдем к полному описанию цикла работы системы.

1. Генерация транзакции: источниками транзакций являются клиенты и УЦ. Каждая операция запроса, выдачи, отказа, добавления в список и так далее – заносится в свою транзакцию.
2. Создание блока узлами-фиксаторами: консорциум узлов производит блок по алгоритму PBFT, затем арбитр раунда посылает этот блок в сеть.
3. Обновление сети: новый созданный блок попадает в сеть и рассылается по всем узлам.
4. Анкоринг: раз в период на усмотрение администратора (обычно зависит от нагрузки в сети и ценности данных) делается транзакция, которая отсылается в публичный блокчейн (либо общекорпоративный, либо в биткойн). Предпочтительным вариантом является тот, в котором у фирмы есть возможность запустить публичный блокчейн для всех своих филиалов, а в каждом филиале запустить приватный блокчейн.

Рис. 2. Схема работы проектируемой системы

Заключение

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

Список литературы.

1. Введение в криптографию и сертификаты [Электронный ресурс]. – Режим доступа : http://www.autopark.ru/ASBProgrammerGuide/CRYPTO.HTM, свободный. – Загл. с экрана.
2. Practical Byzantine Fault Tolerance [Электронный ресурс]. – Режим доступа : http://www.pmg.lcs.mit.edu/papers/osdi99.pdf, свободный. – Загл. с экрана.
3. Exonum [Электронный ресурс]. – Режим доступа : https://exonum.com/doc/, свободный. – Загл. с экрана.
4. Теорема о византийских генералах [Электронный ресурс]. – Режим доступа : http://archive.is/iFLX, свободный. – Загл. с экрана.
5. Открытые и закрытые блокчейны [Электронный ресурс]. – Режим доступа : https://forklog.com/wp-content/uploads/public-vs-private-pt1-1.0-ru.pdf, свободный. – Загл. с экрана.

Автор: Шарапов Р. А.

Дата публикации: 01.01.2018

Библиографическая ссылка: Шарапов Р. А. Система распространения полномочий и сертификатов открытых ключей на базе корпоративного блокчейна // Вопросы защиты информации. М., 2018. № 3. С. 3–6.

---