Я бы хотел описать ENS в плане возможности доказательства владения публичным ключом при подписи данных и небольшого сравнения с CA(certificate authority).
1. Кратко об электронной подписи
Подробное описание, глава - Что такое электронная подпись. Для электронной подписи используются 2 связанных ключа - один шифрует, другой расшифровывает данные.При шифровании публичным ключом выступает тот, который шифрует, а приватным - тот который расшифровывает.
При подписи все наоборот, публичный - тот который расшифровывает, приватный - тот который шифрует. Обычно берут хеш от данных и шифруют его приватным ключом, получившуюся последовательность называют сигнатурой(в переводе подпись). Все могут сравнить хеш данных и хеш из сигнатуры с помощью публичного ключа(расшифровав подпись), но изменить хеш в сигнатуре невозможно, так как для шифрования нового хеша нужен приватный ключ. При использовании нового приватного ключа, не сможем расшифровать сигнатуру старым публичным ключом. Таким образом подпись - это зашифрованный хеш данных и в нашем случае мы привязали данные к паре ключей. Зная публичный ключ юзера мы можем проверить данные, которые сервис подписал приватным ключом.
Мы связали данные с парой ключей, пар ключей может быть много и проблема заключается в связке пары ключей с определенным сервисом или человеком. Т.е. необходимо точно знать, что публичный ключ для проверки и связанный с ним приватный ключ принадлежит именно этому пользователю, от которого мы ожидаем подписи.
2. CA(certificate authority)
На проблеме доказательства принадлежности данной пары ключей юзеру строится инфраструктура публичных(открытых) ключей или PKI(public key infrastructure). PKI является набором средств по решению задач в инфраструктуре с помощью публичного и закрытого ключей. В основном это система из удостоверяющих центров(Certificate Authority). Принципы из вики:
Центр сертификации или удостоверяющий центр(CA) - это 3 лицо, которому доверяют обе стороны - проверяющая подпись и предоставляющая подпись. Задача CA в подтверждении принадлежности пары ключей опрделенному юзеру. Доказательство - это выдача сертификата, т.е. набора данных о владельце и публичном ключе. Сертификат имеет стандарт - x509. Состав сертификата:
Основные данные - имя издателя, имя субъекта, открытый ключ субъекта. Дабы создать единую 3 сторону в глобальной сети и решить проблему масштабируемости вместо нескольких разрозненных серверов CA, создали иерархическую модель центров сертификации. Где сертификаты CA подписиваются вышестоящими CA. Серты верхних CA(корневых) хранятся на устройствах. Самый простой пример это HTTPS - зашифрованный трафик. Для достоверности ключей шифрования, сервера подписывают их, для достоверности подписи клиенты обращаются к CA.
3. ENS(Ethereum name system)
Консенсус компьютеры образуют распределенную систему с единым состоянием с помощью алгоритмов консенсуса. Т.е. нет центра принятия решений. ENS - проект основанный на блокчейне Ethereum. Очень похож на DNS, только вместо IP адресов - хеши публичных ключей аккаунтов(аккаунтом в эфире можно считать пару публичного и приватного ключей ECDSA, а хеш публичного ключа это адрес аккаунта).
Ethereum привнес такое понятие как смарт-контракты - децентрализованные приложения, программы которые выполняются в блокчейне. Почему мы можем быть уверены в том, что разработчики не изменят логику сервиса? Код смарт-контракта неизменяем и доступен для проверки.
Для обновления программ в блокчейне разработчики публикуют адрес обновленного смарт-контракта. Пример обновления смарт-контракта из доки ENS.
Т.е. можем узнать по имени ens.eth хеш публичного ключа ECDSA. Как можно это использовать? Для проверки подписи нужна сама подпись, и имя подписавшего. Стандартная проверка - расшифровка публичным ключом ens.eth сигнатуры, получая хеш данных и сравнивая его с посчитанным нами хешем данных. Но в данном случае есть только хеш публичного ключа ens.eth.
ECDSA позволяет получить публичный ключ из хеша данных и сигнатуры.
Пример функции проверки подписи на golang:
// check signature
func CheckSig(hash, sig []byte, pub *crypto_ecdsa.PublicKey) (bool, error) {
// получение публичного ключа из хеша и сигнатуры
sigPublicKey, err := crypto.Ecrecover(hash, sig)
if err != nil {
return false, err
}
// сравнение публичного ключа из сигнатры и переданного в функцию
return bytes.Equal(sigPublicKey, crypto.FromECDSAPub(pub)), nil
}Из сигнатуры и хеша данных мы получаем публичный ключ, считаем хеш публичного ключа и сравниваем его с тем хешем который получили из ENS для ens.eth. В ENS также возможно разделение резолвинга имени на хеш и владение именем. Т.е. одна пара ключей ECDSA может владеть несколькими именами ENS и управлять резолвингом на хеши других пар ECDSA. Это добавляет гибкости в управлении ключами и безопасности в инфраструктуру. Можно добавялять метадату.
Пример из ens(addresses - хеш публичного ключа, owner - владелец имени). Арендовать можно на официальном сайте смарт-контракта.
4. Заключение
Сравнивая PKI на ENS и иерархических CA, отмечу у ENS децентрализацию и гибкость в управлении ключами. Проблемы могут возникнуть в списках CRL (Certificate Revocation List- это черный список цифровых сертификатов X.509, которые центр сертификации (ЦС) отзывает до назначенной даты отзыва), которых нет, приходится каждый раз резолвить имя. И с HSTS(проще говоря, когда браузер запоминает сертификат сервера) тоже в данном случае требовал бы постоянных запросов на резолвинг имени.
Идея использования блокчейна вместо CA или DNS не нова. Emercoin имеет key-value(или name-value) хранилище, на основе него построены децентрализованный DNS, есть хранение SSL сертификатов. В Emercoin можно посмотреть историю изменения key-value ключей, используется скрипт Сатоши(неполный по Тьюрингу), полные по Тьюрингу языки в Ethereum для написания смарт-контрактов накладывают риски по безопасности по мнению проекта.
Но мое мнение, что смарт-контракты на базе Ethereum предоставляют больше гибкости(обратный резолвинг, добавления метаданных и т.д.) и возможность строить вокруг пары ключей экосистемы, блокчейн не заканчивается резолвингом имени на хеш публичного ключа. Можно, к примеру, посетить сайт в IPFS(файловая система на блокчейне, в метаданных ENS можно указать ссылку на данные). Адрес может быть связян участием и обязательствами в других смарт-контрактах и публиковать свои. Т.е. у аккаунта, подписавшего данные возможна активная жизнь в пределах блокчейна.
Учитывая некоторые проблемы с сертификатами у компаний в РФ и РБ с отказом работать ряда удостоверяющих центров и перспективой использования внутренних центров сертификации блокчейн является неплохой альтернативой для хранения согласованных данных и борьбой с мошенничеством, будь то Emercoin или Ethereum.