company_banner

Погружение в технологию блокчейн: Децентрализованная беспарольная система безопасности

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



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


    1. Серия материалов, посвященных технологии Emer:
    1.1. Секреты EmerCoin.
    1.2. Децентрализованная нецензурированная система доменных имён.
    1.3. Инфраструктура публичных ключей всемирного масштаба.
    1.4. Децентрализованная беспарольная система безопасности.
    2. Быстрые и безопасные транзакции.
    3. Экосистема цифровой стоматологии.
    4. Борьба с контрафактными товарами.
    5. Взаимное страхование животных.
    6. Что такое ICO и как его провести.
    7. 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 была открыта для публичного использования примерно год назад. В течение этого года система была принята в промышленную эксплуатацию рядом организаций и веб-сайтов. Некоторые из известных нам применений перечислены ниже:



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


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

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

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

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

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

    Об авторе


    Олег Ховайко – ведущий разработчик криптовалюты «EmerCoin», эксперт в области криптографии и компьютерной безопасности. С 1994 года работает в IT-сфере. В настоящий момент также является вице-президентом американского инвестиционного банка, производящего операции с ценными бумагами – Jefferies & Company. Который считается одним из крупнейших независимых банков США.
    Microsoft 260,96
    Microsoft — мировой лидер в области ПО и ИТ-услуг
    Поделиться публикацией
    Комментарии 13
    • +1
      Пардон, а где здесь блокчейн используется и как?
      • 0
        Блокчейн EmerCoin выступает только как публичное доверенное хранилище хешей SSL-сертификатов и
        обеспечивает уникальность Serial, который и является уникальным UserID.

      • 0
        (вздыхает) Для использования клиентских сертификатов блокчейн необязателен. Я вот много лет пользуюсь — удобно, практично, эффективно.

        При этом я прекрасно сам себе генерю клиентский сертификат, а также его отзываю в случае необходимости. Делов-то — на том же self-signed сертификате сгенерить что и серверу генерили. И отзывается так же легко — занесением в CRL.

        Собственно вот наглядно.

        А если надо со всей мутью от УЦ — то какой-нибудь StartSSL (жаль конкретно этот испортился после покупки китайцами) прекрасно выдает бесплатные клиентские сертификаты. И с отзывом проблем нет (правда тут-то денег и просят, хех).

        А теперь то же самое но с блокчейном!!! Ну ок. А что поменялось?

        Кстати, емеркойн — где-то я это уже слышал. Это не те самые которые потом по блокчейну транзакции откатывали после известного фрода? ;-)
        • 0
          Кстати, емеркойн — где-то я это уже слышал. Это не те самые которые потом по блокчейну транзакции откатывали после известного фрода? ;-)

          Нет, то был Ethereum. А Emercoin просто пиарятся часто как улучшенная альтернатива Namecoin. С Ethereum тоже любят себя сравнивать, хотя ничего похожего в них нет.

          • 0
            Точно!

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

          В системе emcSSL отсутствует центр сертификации, а выпуском сертификатов занимаются сами пользователи...


          И после этого полностью рассказано о всех достоинствам, к примеру, давным давно существующей авторизации на SSH через сертификаты.

          Чего такого принципиального нет в SSL,
          что такое принципиальное есть в emcSSL?

          • 0
            Чего такого принципиального нет в SSL, что такое принципиальное есть в emcSSL?


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

            Также, в материале написано:

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


            Там детально освещена работа.
            • 0
              В наше время CA хотят государства стать.
              ;)
              Например, в Казахстане требуют установки ключа, подписанного кем-то там на уровне магистрального провайдера, без него дают отлуп от https

              То есть проблема больше политическая.

              Трудно представить, где была бы столь серьезно востребована технология.
              Не, я понял, что это полезно.

              Но в условиях, когда бабло миллионами гребут CA…
              • 0
                > В emcSSL главный секрет – приватный ключ CA, который является открытой информацией

                приватный ключ… является открытой информацией.

                Простите, что?

                • 0
                  Именно так, ничего не напутано!
                  Приватный ключ является открытой информацией.

                  В системе emcSSL – CA фиктивен, оставлен только для совместимости системы с остальной инфраструктурой SSL. То есть от имени этого фиктивного CA кто угодно может сгенерировать сертификат с любыми атрибутами.
                  Только вот блокчейн не позволит злоумышленнику успешно пользоваться сертификатом-дубликатом с тем же Serial.

                  В этом и есть ключевое отличие децентрализованной одноранговой системы emcSSL от классической древовидной структуры классических SSL-сертификатов с «подписями сверху».
                  • 0
                    Представьте себе что под домен третьего уровня нужен сертификат — сроком «нуу на пару недель наверное, но может и дольше, это потестить».

                    Wildcards уже в пролете — ведь все сертификаты доступны, достал из блокчейна сертификат микрософта *.live.com, сунул своему апачу — профит. Нет, не сунул? Не взлетит? А почему? Классический же SSL никуда не делся?

                    Окей, у меня на проекте допустим кластеры prod, stage, qa, dev, testing, и в каждом гора хостов с автоскейлингом. Чтобы https у всех был мне сколько надо сертификатов нагенерить в блокчейне? Нагрузка возросла, амазон еще пять инстансов стартанул, что там с сертификатами? А сервера у меня в DMZ и без коннектов куда попало, дальше что делаем?

                    И это я про https, а сертификаты применяются и в подписях драйверов для винды, хех…
                    • 0
                      Обратите внимание на то, что в статье речь идёт о клиентских сертификатах, а ваш комментарий касается серверных (которые выкладываются на сервер):

                      Поэтому этот материал решили посвятить ответам на них на примере emcSSL – системы идентификации пользователей WWW на основе подсистемы NVS криптовалюты EmerCoin и децентрализованных клиентских SSL-сертификатов.
              • 0
                1.
                После совершения покупки, сервер «забывает» содержимое инфокарты – до следующего логина пользователя.
                ничто не мешает и думаю так и будет что магазины будут забывать «забывать».
                2. И фронт борьбы за приватность переносится на плечи самого пользователя (защита его конечного устройства) что вызывает большее уныние нежели защита более менее крупных ресурсов
                а в целом все красиво )

                Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                Самое читаемое