░ На прошлой неделе основная версия стала гласить, что это была атака, организованная государством, – предположительно при финансировании иранского правительства и под его руководством, – в результате которой был взломан реселлер сертификатов при американской компании Comodo.
░ 23 марта Comodo признала факт атаки, заявив, что восемью днями ранее хакеры заполучили девять поддельных сертификатов для входа на сайты Hotmail от Microsoft, Gmail от Google, службы интернет-звонков и переписки Skype и Yahoo Mail. Также к ним попал сертификат для сайта расширений Mozilla Firefox.
Почему бы центрам сертификации снова не стать децентрализованными, по крайней мере до уровня модели M-of-N?[30] (Заметьте, что случай гораздо более широкого использования M-of-N логически отделим от случая с блокчейнами, но блокчейны оказались хорошей платформой для запуска M-of-N.)
Рассмотрим конкретный сценарий использования – «идентификация в блокчейне». Что вам понадобится для идентификации? Простейший ответ: приватный и публичный ключи. Вы публикуете публичный ключ, который становится вашим идентификатором, и подписываете каждое сообщение приватным ключом посредством цифровой подписи, чтобы каждый мог быть уверен, что это сообщение написали именно вы (в этом контексте «вы» означает «объект, который владеет этим конкретным публичным ключом»). Однако здесь есть несколько проблем.
1. Что, если ваш ключ украдут и вам нужно будет перейти на новый?
2. Что, если вы потеряете свой ключ?
3. Что, если вы захотите сослаться на других пользователей по их именам, а не по случайным 20-байтовым строкам криптографических данных?
4. Что, если вы захотите использовать не только ключ, но и более продвинутый подход к обеспечению безопасности вроде мультиподписи?
Давайте разберем каждую проблему по отдельности. Начнем с четвертой. Для нее есть простое решение: вместо того чтобы требовать один конкретный тип криптографической подписи, ваш публичный ключ можно сделать программой, и тогда действительная подпись становится строкой, которая при вводе в программу вместе с сообщением возвращает 1. Теоретически в этой парадигме можно закодировать одноключевой, многоключевой или любой другой набор правил.
Но есть проблема: публичные ключи будут слишком длинными. Для ее решения можно внести изначальный «публичный ключ» в какое-то хранилище данных (например, в распределенную хеш-таблицу, если мы хотим децентрализации) и использовать хеш «публичного ключа» в качестве идентификатора пользователя. Для этого пока не требуются блокчейны – хотя в последних разработках по своей конструкции масштабируемые блокчейны не так уж сильно отличаются от распределенных хеш-таблиц. Вполне возможно, что лет через десять все виды децентрализованных систем, используемые в любых целях, случайно или намеренно сойдутся в какой-то масштабируемый блокчейн.
Перейдем к первой проблеме. Можно посмотреть на нее как на проблему отзыва сертификата: если вы хотите «отозвать» определенный ключ, как вы сможете убедиться, что об этом узнáют все, кому нужно? Ситуация может решиться сама собой с помощью распределенной хеш-таблицы, но тогда возникает другая проблема: если вы хотите отозвать ключ, то чем вы его замените? Если ваш ключ украден, он есть и у вас, и у злоумышленника, и никто из вас не сможет доказать, что именно он – настоящий владелец. Одно из решений – иметь три ключа, а затем, если один из них будет отозван, потребовать подписи от двух из них или от всех, чтобы утвердить следующий ключ. Но это приводит к проблеме «ничего на кону»: если злоумышленнику в конечном итоге удастся украсть все три ваших ключа в одной точке истории, он сможет имитировать историю назначения нового ключа, назначая оттуда дополнительные новые ключи, и ваша собственная история перестанет иметь силу. В этом случае помогут временны´е метки, и для этого понадобится блокчейн.
Для второй проблемы тоже хорошо подойдет хранение нескольких ключей и переназначение – и здесь блокчейн не нужен. На самом деле переназначение тоже не требуется; при грамотном использовании разделения секрета вы можете вернуть потерянный ключ, просто сохранив его в «осколках», – если вы потеряете один осколок, всегда можно использовать математику разделения секрета и восстановить его из других. Что касается третьей проблемы, здесь самое простое решение – реестры имен на основе блокчейна.
Однако на практике большинство людей недостаточно технически подкованы для безопасного хранения нескольких ключей. Всегда будут возникать сбои, и здесь централизованные сервисы играют важную роль, помогая людям вернуть свои учетные записи. В этом случае блокчейны могут предложить простое решение: социальный бэкап M-of-N.
30
Система M-of-N – это такая система, где для замка существует, например, N ключей, M из которых необходимо для его открытия.