В этой статье обзорно поговорим про грядущую фичу Internet Computer'a под названием VETKeys. Она полностью решает проблему менеджмента ключей в privacy-focused приложениях (и в Web3.0, и в Web2.0), позволяя вообще не хранить ключи шифрования пользователей, а запрашивать их on-demand из блокчейна по протоколу гарантирующему, что никто кроме самого пользователя его ключ не увидит.


Вступление

Разработка privacy-focused сервисов на блокчейне - это одновременно и очень заманчивое, и очень трудное дело. Не важно, что именно разрабатывается: чат, цифровые документы, инвестиционные инструменты или софт для DAO - хочется, чтобы весь код работал полностью на публичной инфраструктуре, но при этом чтобы данные, которыми этот код оперирует, были от публичной инфраструктуры (и всех остальных) скрыты.

До недавнего момента, было всего два варианта достичь этого:

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

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

В скором времени, буквально в ближайшие месяцы, в Internet Computer будет добавлена фича, которая называется VETKeys (Verifiable Encrypted Threshold Keys). Она расширит наш арсенал третим - гораздо более простым и безопасным вариантом решения этой проблемы. Если коротко и без деталей, VETKeys позволяют пользователям вообще не хранить ключи шифрования, а генерировать их с помощью канистера каждый раз, когда они необходимы. Причем, генерировать так, что один и тот же пользователь детерминированно получает один и тот же набор ключей, но при этом, никто, кроме этого пользователя - даже сами узлы подсети - этот набор ключей никогда не узнает.

Кстати, если вам хочется больше информации про Internet Computer, заходите в наш телеграм канал, где мы пишем о теоретической составляющей этой блокчейн-сети простым языком. Сейчас, например, пересказываем whitepaper IC без формул и математики, но с кучей примеров.

Как это работает

Давайте теперь сделаем небольшой шаг назад и вкратце опишем, что такое Internet Computer и как он вообще работает. Internet Computer (IC) - это блокчейн-сеть нового поколения. Одна из главных отличительных особенностей этой сети - это возможность бесконечного масштабирования - пропускная способность (транзакции в секунду) растёт с ростом числа узлов в сети.

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

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

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

Именно на основе пороговых BLS подписей и работают VETKeys. Протокол функционирует примерно следующим образом (сильно упрощено):

  1. Пользователь хочет запросить некую энтропию (случайное число), чтобы затем как-то использовать её.

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

  3. Канистер видит запрос пользователя и решает, позволить ли пользователю это сделать или нет (подробнее о процессе принятия этого решения - далее).

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

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

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

  7. Ассиметричное шифрование используется не абы-какое, а экспоненциальный ElGamal, который обладает гомоморфными свойствами.

  8. Затем, все узлы подсети отправляют свои кусочки подписей блок-мейкеру - узлу, который в данном раунде консенсуса считается лидером подсети.

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

  10. Обратите внимание, что в предыдущем шаге, блок-мейкер выполняет проверку и объединение кусочков в зашифрованном виде - он не имеет возможности расшифровать кусочки и, таким образом, узнать энтропию, которую получит пользователь. Это возможно как раз благодаря использованию гомоморфного ElGamal.

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

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

  13. Затем, пользователь проверяет, что полученный блоб данных - это действительно подпись сделанная подсетью IC. Пользователь знает публичный ключ подсети.

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

Как это использовать

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

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

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

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

Представьте еще одно приложение - платформа цифровых завещаний. Есть у Бориса какие-то цифровые активы (токены, ключевые пары, аккаунты от соц. сетей) и Борису уже много лет. Поэтому Борис, чтобы убедиться, что его активы попадут только тому, кто их заслужил, а не кому-то еще, шифрует эти активы с помощью VETKeys, а затем говорит канистеру: "Я буду раз в полгода слать тебе ping. Если время подошло, а ping я не прислал, значит я умер. Если я умер, значит дай мою энтропию моей дочери.". В английском языке это называется dead man's watch - часы смертника. Пока они тикают - все работает в штатном режиме, когда они тикать перестали - что-то должно случиться.

Примеров можно придумать массу. По сути, VETKeys дают нам возможность генерировать безопасные случайные числа для пользователей и полностью управлять алгоритмом "какому пользователю какое число сгенерировать". А самое крутое - это то, что эту технологию можно внедрить даже в обычный Web2.0 сервис. У вас может быть самый классический веб-сервис на клиент-сервере, но пользователи могут свои ключи шифрования запрашивать с Internet Computer, а использовать у вас.

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

Заключение

Всем ребятам из сообщества Internet Computer - привет! Всем остальным советую приглядеться. Этот блокчейн совершенно не про обычные блокчейн штуки, типа токенов или NFT (хотя это там тоже есть) - он про то, как можно делать софт, решая старые проблемы новыми методами.

Заглядывайте в наш телеграм канал. Задавайте вопросы в комментариях. Вот более подробное видео о том, как VETKeys работают и как выглядят на практике. Спасибо!

Комментарии (0)