Рассказывая про технологическую сторону блокчейна в статьях из цикла «Погружение в технологию блокчейн» мы столкнулись с вопросами: «Зачем это нужно? Какие проблемы решает? Как использовать?» Поэтому этот материал решили посвятить ответам на них на примере emcSSL – системы идентификации пользователей WWW на основе подсистемы NVS криптовалюты EmerCoin и децентрализованных клиентских SSL-сертификатов.

Цикл статей «Погружение в технологию блокчейн»

1. Серия материалов, посвященных технологии Emer:
1.1. Секреты EmerCoin.
1.2. Децентрализованная нецензурированная система доменных имён.
1.3. Инфраструктура публичных ключей всемирного масштаба.
1.4. Децентрализованная беспарольная система безопасности.
2. Быстрые и безопасные транзакции.
3. Экосистема цифровой стоматологии.
4. Loading…

Что происходит?

Как известно, наиболее распространённым способом аутентификации пользователя является пароль. Эта практика имеет исторические корни, и основана на парадигме получения доступа к доверенному устройству (компьютеру). Этот подход хорошо работал в прошлом, когда компьютер был изолирован от сети, и просто так никакой троян не мог перехватить пароль, а даже если мог бы – то никуда особо его не мог использовать, ибо зачем пароль трояну, который уже и так в компьютере вовсю орудует?

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

И эта парадигма совершенно не удовлетворяет условиям безопасности современных систем, где недоверенным может быть и устройство, и сетевое соединение, и даже сервер.

Недавний пример – захват домена blockchain.info с последующим выуживанием паролей пользователей фальшивым сайтом и хищением биткоинов со счетов пользователей. 8 миллионов учётных записей оказались потенциально скомпрометированы. При этом сам сайт не был взломан, но была взломана сетевая инфраструктура, что и сделало возможным «выуживание» паролей фальшивым сайтом.

Известны также инциденты, связанные со взломом популярных сайтов и «сливом» оттуда базы данных пользователей, включая хеши паролей.

Например, несколько громких инцидентов последнего времени:

1. Adultfriendfinder – украдено 412 миллионов учётных записей;
2. OPM (база государственных служащих США) – украдено 22 миллиона записей;
3. Отечественные хакеры тоже не отстают – Взлом «ВКонтакте» скомпрометировал 171 миллион учётных записей.

Здесь уже не удаётся списать такие инциденты на «исключительный частный случай», можно говорить о том, что прослеживается система. Конечно, не будем спорить – каждый взлом был уникален по-своему, но результат одинаков – массовая компрометация учётных записей пользователей, репутационные потери сайтов и организаций, и в каких-то случаях – значительные финансовые потери как пользователей, так и для сайтов и их владельцев.

Глядя на текущее бедственное положение дел, встают два извечных русских вопроса, сформулированные ещё Герценом и Чернышевским:

1. Кто виноват?
2. Что делать?

Попробуем ответить на них по порядку.

Кто виноват?

Очевидно, что основная вина лежит на устаревшей парольной системе аутентификации, которая была хороша для однопользовательского PC, но не годится для современного сетецентрического мира.

Ключевой недостаток парольной аутентификации заключается в том, что оператор, предъявляя устройству пароль, полностью раскрывает свой секрет. Для доверенного устройства — это не страшно. Но в случае недоверенного устройства, или вмешательства злоумышленника, последний, перехватив пароль, получает полный доступ к учётным записям пользователя. Другими словами, пользователь, единожды раскрыв пароль, становится беззащитным против злонамеренных действий «с той стороны монитора». А так как вряд ли какое-либо устройство в современном сетевом мире можно считать доверенным, то хищение паролей становится неизбежным и систематическим. Попытки улучшить эту систему принуждением пользователей к частой смене паролей – раздражает пользователей, создаёт им массу проблем, и по сути является паллиативным решением. Таким же паллиативным решением являются современные системы двухфакторной авторизации на основе СМС, в которых требуется подтвердить владение ещё одним недоверенным устройством, подключённым к ещё одной недоверенной сети.

Вторым ключевым недостатком является централизация учётных записей, то есть хранение их в огромных базах. Если бы в учётной записи содержался бы только UserID, то «слив» такой базы не приводил бы к катастрофе – в конце концов, просто UserID не является секретной информацией. Но в базах, наряду с UserID, хранится и другая информация, разглашению не подлежащая – например хеши паролей. Да, хеш конечно же – не пароль. Но имея соответствующий словарь, по хешам удаётся восстановить значительную часть паролей слитой базы, порядка трети. К тому же, эвристические атаки на слабые пароли тоже кое-что добавляют. А далее – секрет известен, и ключи в руках злоумышленника.

Резюмируя вышесказанное – имеем:

1. Парольную систему с полным раскрытием секрета, не соответствующую современным требованиям.
2. Централизованное хранение данных пользователей, что приводит к катастрофическим последствиям в случае компрометации базы данных.

Следует заметить, что выполнение обоих вышеуказанных условий делает взлом полезным для злоумышленника с практической стороны.

Так, если бы из слитой базы невозможно было восстановить пароли, то её ценность была бы весьма сомнительной (хотя персональные данные тоже могут представлять интерес), так как получить доступ к учётной записи всё равно было бы невозможно.

Также централизованное хранение учётных записей делает идею взлома и слива базы привлекательной для злоумышленников. Действительно, если бы централизованного хранения не было бы – не было бы и массовых сливов, как в вышеприведённых примерах.

В общем – виноваты мы все, так как используем архитектуру, не соответствующую современным требованиям. И владельцы сайтов, и пользователи, которые соглашаются это использовать.

Что делать?

Как было замечено выше, систематическая компрометации базы пользователей имеет смысл в случае применения обоих механизмов устаревшей архитектуры – паролей с полным раскрытием секрета, и централизации, делающей привлекательным и экономически выгодным хищение базы пользователей с их паролями. Отказ от любого из этих механизмов (а лучше – от обоих сразу) сделает бессмысленными взломы, подобные тем, которые рассмотрены выше.

Иными словами, необходима новая архитектура аутентификации, которая:

a. Не раскрывает секрет пользователя в процессе аутентификации серверу.
b. Использует децентрализованное хранение учётных записей.

В идеале – сервер должен знать о пользователе только UserID, и ничего более.

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

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

Долгое время проблема централизации не имела хорошего решения. Однако появление феномена криптовалют и публичного блокчейна, обеспеченного независимым доверием, дало миру инструмент, на основе которого можно построить новую архитектуру аутентификации, удовлетворяющую обоим условиям – (a, b).

На основе этого инструмента такая архитектура была создана, и уже более года находится в эксплуатации. Встречайте героев нашего времени – emcSSL+InfoCard!

Описание архитектуры и механизмов работы обеих систем подробно рассмотрено здесь.

Теперь, стал понятен ответ на извечный вопрос №2.

Ниже кратко рассмотрим, как предложенная архитектура помогает в решении вопросов (a, b).

emcSSL

Как было указано выше, система клиентских SSL-сертификатов решает проблему полного раскрытия секрета (a). Однако по ряду причин, включая приведённые выше, она не слишком хорошо масштабируется, и широкого распространения не получила.

В системе emcSSL отсутствует центр сертификации, а выпуском сертификатов занимаются сами пользователи. Соответственно, выпуск сертификата – по определению бесплатен. Блокчейн EmerCoin выступает только как публичное доверенное хранилище хешей SSL-сертификатов и обеспечивает уникальность Serial, который и является уникальным UserID.

Таким образом, в системе emcSSL успешно решены обе проблемы – как неразглашения секрета (a), так и децентрализации (b), что позволяет масштабировать систему до общемирового уровня. Пользователь системы emcSSL получает эдакий «пропуск-вездеход», не зависящий ни от кого, кроме самого пользователя. Ни от «сайта в интернете», ни от сертификатора, ни от кого-либо ещё. Соответственно, в системе невозможны атаки типа рассмотренных выше, которые приводят к массовой компрометации учётных записей, ибо приватные ключи генерируются пользователями, и никогда не покидают их компьютеров, и просто не существует такого центрального места, которое можно скомпрометировать.

В особо важных случаях целесообразно использование emSSL совместно с паролем в рамках двухфакторной авторизации. При этом emcSSL авторизует устройство и обеспечивает безопасный канал связи с сервером, а пароль авторизует оператора.

Ещё стоит упомянуть, что блокчейн-архитектура emcSSL эффективно и безопасно решает проблему отзыва скомпрометированного сертификата и его быстрой замены, чем выгодно отличается от CRL и протокола OCSP, уязвимого к атаке MItM.

InfoCard

Итак, система emcSSL решает все поставленные задачи. Компрометация какого-либо сервера не приводит к компрометации учётных записей, так как пароль ни в какой форме на сервере не хранится. Однако на сервере может храниться дополнительная информация о пользователе, представляющая интерес для злоумышленника, такая как номер телефона, домашний адрес и тому подобное. По-хорошему, весьма желательно, чтобы этой информации на сервере не хранилось тоже. Некоторые интернет-магазины в целях безопасности так и поступают – дают возможность пользователю делать покупку как «гость», и не сохраняют информации о пользователе после совершения покупки. Подход конечно варварский, но верный. По крайней мере, в плане обеспечения безопасности.

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

Система InfoCard именно так и поступает. Информация о пользователе (инфокарта) создаётся самим пользователем, шифруется и помещается в блокчейн EmerCoin. Когда пользователь логинится по сертификату emcSSL, сертификат содержит ссылку на инфокарту и ключ расшифровки. Сервер в этот момент может извлечь содержимое инфокарты, и использовать его – например, взять адрес доставки заказа и заполнить его содержимым поля формы заказа. После совершения покупки, сервер «забывает» содержимое инфокарты – до следующего логина пользователя. В результате, в учётной записи на сервере можно хранить только UserID, и ничего больше. Ни пароля, ни персональных данных пользователя. Не слишком богатый улов для взломщика, не так ли? Соответственно, если с сервера взять нечего – его скорее всего и не будут пытаться взломать.

В дополнение стоит заметить, что система InfoCard, кроме повышения безопасности, повышает удобство пользователя, так как:

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

Примеры применения

Система emcSSL была открыта для публичного использования примерно год назад. В течение этого года система была принята в промышленную эксплуатацию рядом организаций и веб-сайтов. Некоторые из известных нам применений перечислены ниже:

• Emercoin Blockchain Engine – BaaS приложение для MS Azure.
• Пул майнинга EmeCoin.
• Онлайн-кошелёк EmeCoin.
• Модуль авторизации для Drupal CMS.
• Система управления датацентрами и майнерами компании HashCoins.
• Массовая система беспарольной авторизации от компании Remme.

Как начать пользоваться

Сначала советуем ознакомиться с детальной статьёй, в которой вы найдете самые основы. Далее можно изучить видео, в котором пошагово показано, как оператор сгенерировал свой SSL-сертификат и разместил его в блокчейне EmerCoin.

Этот классический способ, когда пользователь сам генерирует сертификат и публикует его хеш в NVS, наиболее корректен в плане безопасности. Ибо в этом случае пользователь верит только себе, а его приватный ключ генерируется локально и никогда не покидает устройства пользователя.
Если же вы считаете приемлемым доверить вашу безопасность внешнему сайту, как это происходит в случае логина через соцсети, то вы можете бесплатно заказать сертификат online на сайте Криптор, и потом самостоятельно разместить его хеш в NVS. При желании, можно потом сгенерировать ещё один сертификат локально, и обновить его хеш в NVS, что поднимет вашу безопасность до «классического» уровня.

Если вы вообще не желаете связываться с EmerCoin, но тем не менее пользоваться системой emcSSL, то вы можете воспользоваться сервисом от компании Remme, которая предоставляет сервис беспарольной авторизации на базе технологии emcSSL. Понятно, что в этом случае компания становится вашим доверенным агентом.

Проверить работу свежесгенерированного сертификата и инфокарты можно на сайте emcSSL. Оттуда же можно скачать как скрипты для генерации сертификатов, так и два варианта серверного приложения на PHP, а также заархивированную копию всего этого сайта. Развернув эту копию у себя, можно посмотреть изнутри, как оно всё работает, и использовать её как основу для интеграции emcSSL в ваш сайт.

В завершении хотим поделиться хорошей статьёй о создании серверного приложения для использования авторизации через emcSSL.

Об авторе

Олег Ховайко – ведущий разработчик криптовалюты «EmerCoin», эксперт в области криптографии и компьютерной безопасности. С 1994 года работает в IT-сфере. В настоящий момент также является вице-президентом американского инвестиционного банка, производящего операции с ценными бумагами – Jefferies & Company. Который считается одним из крупнейших независимых банков США.