Ознакомительная версия. Доступно 16 страниц из 76
центры сертификации, системы репутации, облачные вычисления, различные виды каналов данных и, вероятно, уже в ближайшем будущем – рынки прогнозирования.
Возможно, крайне взаимосвязанный и взаимозависимый характер этих сервисов через десять лет приведет к тому, что переключиться с одной системы на другую людям будет сложнее, чем сменить собственное правительство. Поэтому чрезвычайно важно выстроить эти сервисы правильно и проконтролировать, чтобы отдельные структуры не получили над ними слишком много власти. На сегодняшний день многие из таких систем выстроены очень централизованно, и отчасти это связано с тем, что создатели Всемирной паутины не сумели понять важность этих сервисов и включить их по умолчанию – поэтому даже сегодня большинство сайтов просят вас «войти в систему через Google» или «войти в систему через Facebook», а центры сертификации сталкиваются с такими проблемами[29].
░ Иранский хакер-одиночка взял на себя ответственность за кражу нескольких SSL-сертификатов крупнейших сайтов, в том числе Google, Microsoft, Skype и Yahoo.
░ Мнения экспертов по безопасности разделились: одни поверили заявлению хакера, у других возникли сомнения.
░ На прошлой неделе основная версия стала гласить, что это была атака, организованная государством, – предположительно при финансировании иранского правительства и под его руководством, – в результате которой был взломан реселлер сертификатов при американской компании 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.
Вы выбираете восемь объектов: это могут быть ваши друзья, ваш работодатель, какая-то корпорация, некоммерческая организация, а в будущем даже правительство, и, если что-то пойдет не так, пятеро из них коллективно смогут восстановить ваш ключ. Эта концепция социального бэкапа с мультиподписью – пожалуй, один из мощнейших механизмов для любого вида децентрализованной системы. Она обеспечивает очень высокий уровень безопасности без существенных расходов и необходимости доверяться централизованным институтам. Обратите внимание, что с идентификацией на основе блокчейна, особенно с контрактной моделью Ethereum, все это очень легко запрограммировать: в реестре имен зарегистрируйте свое имя, свяжите его с контрактом, и дальше контракт будет хранить текущий главный ключ и резервные ключи, связанные с идентификатором, а также логику для их обновления через какое-то время. Такая система идентификации безопасна, не требует чьего-либо вмешательства (кроме вашего!) и так проста, что с ней справится даже бабушка.
Блокчейны могут решить не только проблему идентификации, но и тесно связанную с ней проблему репутации. «Системы репутации», существующие в современном мире, либо небезопасны, потому что не могут гарантировать, что организация, оценивающая другую организацию, действительно с ней взаимодействовала; либо централизованы, и данные о репутации привязаны к определенной платформе и находятся под ее контролем. Если вы перейдете с Uber на Lyft, ваш рейтинг не перейдет туда вместе с вами.
Случай с репутацией интересен тем, что здесь сочетаются многочисленные преимущества
Ознакомительная версия. Доступно 16 страниц из 76
