DPKI: устраняем недостатки централизованной PKI при помощи блокчейна
Ни для кого не секрет, что один из общераспространенных вспомогательных инструментов, без которого невозможна защита данных в открытых сетях, — это технология цифровых сертификатов. Впрочем, не является секретом и то, что главный недостаток это технологии — безусловное доверие к центрам, выпускающим цифровые сертификаты. Директор по технологиям и инновациям компании ENCRY Андрей Чмора предложил новый подход к организации инфраструктуры общедоступных ключей (Public Key Infrastructure, PKI), который поможет устранить существующие в настоящее время недостатки и который использует технологию распределенного реестра (блокчейна). Но обо всем по порядку.
Если вы знакомы с принципами работы существующей инфраструктуры общедоступных ключей и знаете ее ключевые недостатки, то можете сразу перейти ниже к описанию того, что мы предлагаем изменить.
Начнем с того, что для использования этих методов субъекты взаимодействия должны обладать двумя индивидуальными парными ключами — общедоступным и секретным. С их помощью и обеспечиваются услуги безопасности, о которых мы упомянули выше.
Как достигается конфиденциальность передачи информации? Перед отправкой данных абонент-отправитель зашифровывает (криптографически преобразовывает) открытые данные с использованием общедоступного ключа получателя, а тот расшифровывает полученный шифртекст при помощи парного секретного ключа.
Как достигается целостность и подлинность передаваемой информации? Для решения этой задачи был создан другой механизм. Открытые данные не шифруются, но вместе с ним передается результат применения криптографической хеш-функции — «сжатый» образ входной последовательности данных — в зашифрованном виде. Результат такого хеширования называется «дайджестом», а его зашифрование производится на секретном ключе абонента-отправителя («заверителя»). В результате зашифрования дайджеста получается цифровая подпись. Она вместе с открытым текстом передается абоненту-получателю («проверяющему»). Тот расшифровывает цифровую подпись на открытом ключе заверителя и сравнивает с результатом применения криптографической хеш-функции, который проверяющий вычисляет самостоятельно на основе принятых открытых данных. Если они совпадают, то это свидетельствует о том, что данные были переданы в подлинном и целостном виде именно абонентом-отправителем, а не видоизменены злоумышленником.
Большинство ресурсов, работающих с персональными данными и платежной информацией (банки, страховые компании, авиаперевозчики, платежные системы, а также государственные порталы, такие как налоговая служба) активно используют методы асимметричной криптографии.
При чем тут цифровой сертификат? Всё просто. И в первом, и во втором процессе задействованы общедоступные ключи, а поскольку они играют центральную роль, очень важно удостовериться, что ключи действительно принадлежат отправителю (заверителю, в случае проверки подписи) или получателю, а не подменены на ключи злоумышленников. Для этого и существуют цифровые сертификаты, которые позволяют обеспечить подлинность и целостность общедоступного ключа.
Примечание: подлинность и целостность общедоступного ключа подтверждается точно таким же образом, что и подлинность и целостность открытых данных, то есть с использованием электронной цифровой подписи (ЭЦП).
Если не подтверждать подлинность общедоступного ключа, то злоумышленник во время передачи/хранения этого ключа может заменить его на свой собственный. Если подмена состоялась, то злоумышленник сможет расшифровать все, что абонент-отправитель передает абоненту-получателю, либо изменить открытые данные по своему усмотрению.
Цифровые сертификаты используется везде, где есть асимметричная криптография. Один из самых распространенных цифровых сертификатов — это SSL-сертификаты для защищенного режима взаимодействия по протоколу HTTPS. Эмиссией SSL-сертификатов занимаются сотни компаний, зарегистрированных в различных юрисдикциях. Основная доля приходится на пять-десять крупных доверенных центров: IdenTrust, Comodo, GoDaddy, GlobalSign, DigiCert, CERTUM, Actalis, Secom, Trustwave.
УЦ и ЦР — это компоненты PKI, в которую также входят:
- Открытый справочник — общедоступная база данных, обеспечивающая надежное хранение цифровых сертификатов.
- Список отозванных сертификатов — общедоступная база данных, обеспечивающая надежное хранение цифровых сертификатов аннулированных общедоступных ключей (например, по причине компрометации парного секретного ключа). Субъекты инфраструктуры могут самостоятельно обращаться к этой базе данных, а могут воспользоваться специализированным протоколом Online Certificate Status Protocol (OCSP), который упрощает процесс проверки.
- Пользователи сертификатов — обслуживаемые субъекты PKI, заключившие с УЦ соглашение пользователя и осуществляющие проверку цифровой подписи и/или зашифрование данных на основе общедоступного ключа из сертификата.
- Подписчики — обслуживаемые субъекты PKI, владеющие секретным ключом, парным общедоступному ключу из сертификата, и заключившие с УЦ соглашение подписчика. Подписчик может быть одновременно пользователем сертификата.
Таким образом, доверенные субъекты инфраструктуры общедоступных ключей, к которым относятся УЦ, ЦР и открытые справочники, отвечают за:
1. Проверку подлинности личности заявителя.
2. Профилирование сертификата общедоступного ключа.
3. Выпуск сертификата общедоступного ключа для заявителя, подлинность личности которого достоверно подтверждена.
4. Изменение статуса сертификата общедоступного ключа.
5. Предоставление информации о текущем статусе сертификата общедоступного ключа.
Пользователи должны безусловно доверять УЦ и ЦР. Но, как показывает практика, безусловное доверие чревато серьезными последствиями.
За последние десять лет в этой области произошло несколько крупных скандалов, связанных с уязвимостью инфраструктуры.
— в 2010 году в сети стал распространяться вредонос Stuxnet, который был подписан с использованием украденных цифровых сертификатов от RealTek и JMicron.
— в 2017 году компания Google обвинила Symantec в выдаче большого числа фальсифицированных сертификатов. На тот момент Symantec был одним из самых крупных УЦ по объемам выпуска. В браузере Google Chrome 70 была прекращена поддержка сертификатов, эмитированных этой компаний и аффилированными с ней центрами GeoTrust и Thawte до 1 декабря 2017 года.
УЦ были скомпрометированы, в результате пострадали все — и сами УЦ, а также пользователи и подписчики. Доверие к инфраструктуре было подорвано. Помимо этого, цифровые сертификаты могут быть заблокированы в условиях политических конфликтов, что также скажется на работе множества ресурсов. Именно этого опасались несколько лет назад в администрации российского президента, где в 2016 году обсуждали возможность создания государственного удостоверяющего центра, который бы выдавал сайтам в рунете SSL-сертификаты. Текущее положение дел таково, что даже государственные порталы в России используют цифровые сертификаты, выданные американскими компаниями Comodo или Thawte («дочка» Symantec).
Существует еще одна проблема — вопрос первичной проверки подлинности (аутентификации) пользователей. Как без непосредственного личного контакта идентифицировать пользователя, обратившегося в УЦ с запросом на выдачу цифрового сертификата? Сейчас это решается ситуативно в зависимости от возможностей инфраструктуры. Что-то берется из открытых реестров (например, информация о юрлицах, запрашивающих сертификаты), в случаях, когда заявители — физлица, могут использоваться офисы банков или почтовые отделения, где их личность подтверждают по удостоверяющим документам, например, паспорту.
Проблема фальсификации учетных данных с целью имперсонификации относится к разряду фундаментальных. Заметим, что полноценного решения этой проблемы не существует в силу теоретико-информационных причин: не располагая достоверной информацией априори, невозможно подтвердить или опровергнуть подлинность того или иного субъекта. Как правило, для проверки необходимо предъявить набор документов, удостоверяющих личность заявителя. Существует множество различных методик проверки, но ни одна из них не предоставляет полноценной гарантии достоверности документов. Соответственно, подлинность личности заявителя тоже не может быть гарантированно подтверждена.
Децентрализация не предполагает наличия доверенных субъектов — если создать децентрализованную инфраструктуру общедоступных ключей (Decentralized Public Key Infrastructure, DPKI), то не нужны ни УЦ, ни ЦР. Откажемся от концепции цифрового сертификата и воспользуемся распределенным реестром для хранения информации об общедоступных ключах. Реестром в нашем случае мы называем линейную базу данных, состоящую из отдельных записей (блоков), связанных по технологии блокчейн. Вместо цифрового сертификата введем понятие «нотификата».
Как в предлагаемой DPKI будет выглядеть процесс получения, проверки и аннулирования нотификатов:
1. Каждый заявитель отправляет заявку на получение нотификата самостоятельно через заполнение формы в ходе регистрации, после чего формирует транзакцию, которая сохраняется в специализированном пуле.
2. Информация об общедоступном ключе вместе с реквизитами владельца и другими метаданными хранится в распределенном реестре, а не в цифровом сертификате, за эмиссию которого в централизованной PKI отвечает УЦ.
3. Проверка подлинности личности заявителя выполняется постфактум совместными усилиями сообщества пользователей DPKI, а не ЦР.
4. Изменить статус общедоступного ключа может только владелец такого нотификата.
5. Каждый может получить доступ к распределенному реестру и проверить текущий статус общедоступного ключа.
Примечание: на первый взгляд проверка подлинности личности заявителя сообществом может показаться слишком ненадежной. Но надо помнить, что в настоящее время все пользователи цифровых услуг непременно оставляют цифровой след, и этот процесс только продолжит набирать силу. Открытые электронные реестры юрлиц, карты, оцифровка изображений местности, соцсети — все это общедоступные инструменты. Они уже успешно применяются в ходе расследований как журналистами, так и правоохранительными органами. Например, достаточно вспомнить расследования Bellingcat или совместной следственной группы JIT, занимающейся изучением обстоятельств крушения малайзийского Boeing.
Итак, как на практике будет работать децентрализованная инфраструктура общедоступных ключей? Остановимся на описании самой технологии, которую мы запатентовали в 2018 году и по праву считаем своим ноу-хау.
Представьте, есть некоторый владелец, которому принадлежит множество общедоступных ключей, где каждый ключ — это некая транзакция, которая хранится в реестре. Как в отсутствии УЦ понять, что все ключи принадлежат именно этому владельцу? Чтобы решить эту задачу, создается нулевая транзакция, в которой содержится информация о владельце и его кошельке (с которого списывается комиссия за размещение транзакции в реестре). Нулевая транзакция — это своеобразный «якорь», к которому будут прикрепляться следующие транзакции с данными об общедоступных ключах. Каждая такая транзакция содержит специализированную структуру данных, или по-другому — нотификат.
Нотификат — структурированный набор данных, состоящий из функциональных полей и включающий информацию об общедоступном ключе владельца, персистентность которого гарантируется размещением в одной из связанных записей распределенного реестра.
Следующий логичный вопрос — как формируется нулевая транзакция? Нулевая транзакция — как и последующие — представляет собой агрегацию шести полей данных. В ходе формирования нулевой транзакции задействована ключевая пара кошелька (общедоступный и парный секретный ключи). Эта пара ключей появляется в тот момент, когда пользователь регистрирует свой кошелек, с которого будет списываться комиссия за размещение в реестре нулевой транзакции и — впоследствии — операции с нотификатами.
Как показано на рисунке, дайджест общедоступного ключа кошелька формируется путем последовательного применения хеш-функций SHA256 и RIPEMD160. Здесь RIPEMD160 отвечает за компактное представление данных, разрядность которых не превышает 160 бит. Это важно — ведь реестр не дешевая база данных. Сам общедоступный ключ заносится в пятое поле. В первом поле содержатся данные, которые устанавливают связь с предыдущей транзакцией. У нулевой транзакции это поле ничего не содержит, что отличает ее от последующих транзакций. Второе поле — это данные для проверки связности транзакций. Для краткости будем называть данные первого и второго полей «связкой» и «проверкой» соответственно. Содержимое этих полей формируется методом итеративного хеширования так, как это продемонстрировано на примере связывания второй и третьей транзакций на рисунке ниже.
Данные из первых пяти полей заверяются ЭЦП, которая формируется при помощи секретного ключа кошелька.
Всё, нулевая транзакция отправляется в пул и после успешной проверки заносится в реестр. Теперь к ней можно «подвязывать» следующие транзакции. Рассмотрим, как происходит формирование транзакций, отличных от нулевой.
Первое, что вам, наверное, бросилось в глаза — это обилие ключевых пар. Помимо уже знакомой ключевой пары кошелька используются ординарная и служебная ключевые пары.
Ординарный общедоступный ключ — это то, ради чего все, собственно, и затевалось. Этот ключ задействован в различных процедурах и процессах, разворачивающихся в окружающем мире (банковские и иные транзакции, документооборот, и пр.). Например, секретный ключ из ординарной пары может использоваться для формирования ЭЦП различных документов — платежных поручений и т.д., а общедоступный — для проверки этой ЭЦП с последующим исполнением этих поручения при условии ее валидности.
Служебная пара выдаётся зарегистрированному субъекту DPKI. Название этой пары соответствует ее назначению. Заметим, что при формировании/проверке нулевой транзакции служебные ключи не применяются.
Еще раз уточним назначение ключей:
- Ключи кошелька применяются для формирования/проверки как нулевой, так и любой другой, отличной от нулевой, транзакции. Секретный ключ кошелька известен только владельцу кошелька, который одновременно является владельцем множества ординарных общедоступных ключей.
- Ординарный общедоступный ключ по своему назначению аналогичен общедоступному ключу, для которого выпускается сертификат в централизованной PKI.
- Служебная пара ключей принадлежит DPKI. Секретный ключ выдается зарегистрированным субъектам и используется при формировании ЭЦП транзакций (за исключением нулевой). Общедоступный применяется для проверки ЭЦП транзакции перед ее размещением в реестре.
Таким образом, имеется две группы ключей. В первую входят служебные ключи и ключи кошелька — имеют смысл только в контексте DPKI. Во вторую группу входят ординарные ключи — их область применения может различаться и обусловлена теми прикладными задачами, в которых они используются. При этом DPKI обеспечивает целостность и подлинность ординарных общедоступных ключей.
Примечание: Служебная ключевая пара может быть известна различным субъектам DPKI. Например, может быть единой для всех. Именно по этой причине при формировании подписи каждой ненулевой транзакции применяется два секретных ключа, один из которых ключ кошелька — он известен только владельцу кошелька, который одновременно является владельцем множества ординарных общедоступных ключей. Все ключи имеют свой смысл. Например, всегда можно доказать, что транзакция была занесена в реестр зарегистрированным субъектом DPKI, так как подпись была сформирована в том числе и на секретном служебном ключе. И здесь не может быть злоупотреблений, например DOS-атаки, ведь владелец оплачивает каждую транзакцию.
Все транзакции, которые идут следом за нулевой, формируются похожим образом: общедоступный ключ (но не кошелька, как в случае с нулевой транзакцией, а из ординарной ключевой пары) прогоняется через две хеш-функции SHA256 и RIPEMD160. Так формируются данные третьего поля. В четвертое поле заносится сопровождающая информация (например, информация о текущем статусе, сроках действия, временная отметка, идентификаторы используемых криптоалгоритмов и пр.). В пятом поле — общедоступный ключ из служебной ключевой пары. С его помощью потом будет проверяться ЭЦП, поэтому он тиражируется. Обоснуем необходимость такого подхода.
Напомним, что транзакция заносится в пул и хранится там до тех пор, пока не будет обработана. Хранение в пуле связано с определенным риском — данные транзакции могут быть фальсифицированы. Владелец заверяет данные транзакции ЭЦП. Общедоступный ключ для проверки этой ЭЦП указывается в одном из полей транзакции в явном виде и впоследствии заносится в реестр. Особенности обработки транзакции таковы, что злоумышленник способен изменить данные по своему усмотрению и затем заверить их при помощи своего секретного ключа, а парный общедоступный ключ для проверки ЭЦП указать в транзакции. Если подлинность и целостность обеспечивается исключительно посредством ЭЦП, то такой подлог останется незамеченным. Однако, если помимо ЭЦП существует дополнительный механизм, обеспечивающий одновременно архивирование и персистентность сохраняемой информации, то подлог возможно обнаружить. Для этого достаточно занести в реестр подлинный общедоступный ключ владельца. Поясним, как это работает.
Пусть злоумышленник выполняет подлог данных транзакции. С точки зрения ключей и ЭЦП возможны следующие варианты:
1. Злоумышленник размещает в транзакции свой общедоступный ключ при неизменной ЭЦП владельца.
2. Злоумышленник формирует ЭЦП на своем секретном ключе, но оставляет общедоступный ключ владельца без изменений.
3. Злоумышленник формирует ЭЦП на своем секретном ключе и размещает в транзакции парный общедоступный ключ.
Очевидно, что варианты 1 и 2 бессмысленны, так как всегда будут обнаружены в ходе проверки ЭЦП. Смысл имеет только вариант 3, и если злоумышленник формирует ЭЦП на своём собственном секретном ключе, то он вынужден сохранять в транзакции парный общедоступный ключ, отличный от общедоступного ключа владельца. Для злоумышленника это единственный способ навязать сфальсифицированные данные.
Предположим, что владелец располагает фиксированной парой ключей — секретным и общедоступным. Пусть данные заверяются ЭЦП при помощи секретного ключа из этой пары, а общедоступный ключ указывается в транзакции. Предположим также, что этот общедоступный ключ уже был ранее занесен в реестр и его подлинность достоверно подтверждена. Тогда на подлог будет указывать то обстоятельство, что общедоступный ключ из транзакции не соответствует общедоступному ключу из реестра.
Подведем итог. При обработки данных самой первой транзакции владельца необходимо подтвердить подлинность занесенного в реестр общедоступного ключа. Для этого следует прочитать ключ из реестра и выполнить его сличение с истинным общедоступным ключом владельца в пределах периметра безопасности (область относительной неуязвимости). Если подлинность ключа подтверждена и его персистентность гарантируется по факту размещения, то подлинность ключа из последующей транзакции легко подтвердить/опровергнуть путем его сличения с ключом из реестра. Иными словами, ключ из реестра используется в качестве эталонного образца. Аналогично обрабатываются все остальные транзакции владельца.
Транзакция заверяется ЭЦП — тут-то и понадобятся секретные ключи, и не один, а сразу два — служебный и кошелька. Благодаря использованию двух секретных ключей обеспечивается необходимый уровень безопасности — ведь служебный секретный ключ может быть известен другим пользователям, тогда как секретный ключ кошелька известен только владельцу ординарной ключевой пары. Мы назвали такую двух ключевую подпись «консолидированной» ЭЦП.
Проверка транзакций, отличных от нулевой, выполняется с использованием двух общедоступных ключей: кошелька и служебного. Процесс проверки можно разделить на два основных этапа: первый — это проверка дайджеста общедоступного ключа кошелька, а второй — проверка ЭЦП транзакции, той самой, консолидированной, которая была сформирована при помощи двух секретных ключей (кошелька и служебного). Если валидность ЭЦП подтверждена, то после дополнительной проверки транзакция заносится в реестр.
Может возникнуть логичный вопрос: как проверить принадлежит ли транзакция конкретной цепочки с «корнем» в виде нулевой транзакции? Для этого процесс проверки дополнен еще одной стадией — проверкой связности. Тут-то нам и понадобятся данные из первых двух полей, которые пока что мы обходили своим вниманием.
Представим, что нам надо проверить, действительно ли транзакция №3 идет после транзакции №2. Для этого методом комбинированного хеширования вычисляется значение хеш-функция для данных из третьего, четвертого и пятого полей транзакции №2. Потом выполняется конкатенация данных из первого поля транзакции №3 и ранее полученное значение комбинированной хеш-функции для данных из третьего, четвертого и пятого полей транзакции №2. Все это тоже прогоняется через две хеш-функции SHA256 и RIPEMD160. Если полученное значение совпадает с данным второго поля транзакции №2, то проверка пройдена и связность подтверждена. Более наглядно это показано на рисунках ниже.
В общих чертах технология формирования и занесения нотификата в реестр выглядит именно таким образом. Наглядная иллюстрация процесса формирования цепочки нотификатов представлена на следующем рисунке:
В этом тексте мы не будем останавливаться на деталях, которые, несомненно, существуют, и вернемся к обсуждению самой идеи децентрализованной инфраструктуры общедоступных ключей.
Итак, поскольку заявитель сам отправляет заявку на регистрацию нотификатов, которые хранятся не в базе данных УЦ, а в реестре, то основными архитектурными компонентами DPKI следует считать:
1. Реестр действующих нотификатов (РДН).
2. Реестр отозванных нотификатов (РОН).
3. Реестр приостановленных нотификатов (РПН).
Информация об общедоступных ключах сохраняется в РДН/РОН/РПН в виде значений хеш-функции. Стоит также заметить, что это могут быть как разные реестры, так и разные цепочки или даже одна цепочка в составе единого реестра, когда информация о статусе ординарного общедоступного ключа (отзыв, приостановка действия и пр.) заносится в четвертое поле структуры данных в виде соответствующего кодового значения. Существует множество различных вариантов архитектурной реализации DPKI и выбор того, или иного, зависит от ряда факторов, например такого критерия оптимизации как затраты долговременной памяти для хранения общедоступных ключей и пр.
Таким образом, DPKI может оказаться если не проще, то по меньшей мере сравнимой с централизованным решением по сложности архитектуры.
Остается главный вопрос — какой реестр подойдет для реализации технологии?
Главное требование к реестру — возможность формирования транзакций произвольного типа. Самый известный пример применения реестра — это сеть Биткойн. Но в ней при реализации описанной выше технологии возникают определенные трудности: сказывается ограниченность существующего языка сценариев, отсутствие необходимых механизмов для обработки произвольных наборов данных, способов формирования транзакций произвольного типа, а также многое другое.
Мы в компании ENCRY попытались разрешить сформулированные выше проблемы и разработали реестр, который, на наш взгляд, обладает рядом преимуществ, а именно:
- поддерживает несколько типов транзакций: в нем можно как обмениваться активами (то есть выполнять финансовые транзакции), так и формировать транзакции с произвольной структурой,
- разработчикам доступен проприетарный языке программировании PrismLang, обеспечивающий необходимую гибкость при решении различных технологических задач,
- предусмотрен механизм обработки произвольных наборов данных.
Если подходить упрощенно, то имеет место следующая последовательность действий:
- Заявитель регистрируется в DPKI и получает цифровой кошелек. Адрес кошелька — значение хеш-функции от общедоступного ключа кошелька. Секретный ключ кошелька известен только заявителю.
- Зарегистрированному субъекту предоставляется доступ к служебному секретному ключу.
- Субъект формирует нулевую транзакцию и заверяет ее ЭЦП с использованием секретного ключа кошелька.
- Если формируется отличная от нулевой транзакция, то заверяет ее ЭЦП с использованием двух секретных ключей: кошелька и служебного.
- Субъект отправляет транзакцию в пул.
- Узел сети ENCRY считывает транзакцию из пула и проверяет ЭЦП, а также связность транзакции.
- Если ЭЦП валидна и связность подтверждена, то подготавливает транзакцию для занесения в реестр.
Здесь реестр выступает в роли распределенной базы данных, в которой хранится информация о действующих, аннулированных и приостановленных нотификатах.
Конечно, децентрализация не панацея. Фундаментальная проблема первичной аутентификации пользователей никуда не исчезает: если в настоящее время проверкой заявителя занимаются ЦР, то в DPKI проверку предлагается делегировать участникам сообщества, и использовать финансовую мотивацию для стимуляции активности. Технология проверки по открытым источникам хорошо известна. Эффективность такой проверки подтверждена на практике. Опять же вспомним ряд резонансных расследований интернет-издания Bellingcat.
Но в общем складывается следующая картина: DPKI — это возможность исправить, если не все, то многие недостатки централизованной PKI.
Подписывайтесь на наш Хабраблог, мы планируем и дальше активно освещать наши исследования и разработки, и следите за твиттером, если не хотите пропустить другие новости о проектах ENCRY.
