А веб-браузеры и серверы используют инфраструктуру открытых ключей (PKI) для аутентификации и конфиденциальности сессий. Помимо системы паролей (пользователю известен секретный пароль, который он предъявляет сайту) в современном интернете для авторизации применяют клиентские SSL-сертификаты (Secure Sockets Layer – уровень защищенных сокетов). Пользователь покупает сертификат, подписанный доверенным центром авторизации, и с его помощью авторизуется на различных площадках в интернете.
Цифровой сертификат представляет собой цифровой документ, который связывает открытый ключ с определенным пользователем или приложением. В качестве подтверждения подлинности цифрового сертификата часто используется цифровая подпись доверенного центра — Центра сертификации (ЦС).
Так как в список функций ЦС входит формирование сертификатов и списков отозванных сертификатов, центр сертификации является основным компонентом в подобных системах. Однако значительная стоимость сертификатов и их обслуживания, постоянная зависимость от центра сертификации и сложность генерации сертификата с участием авторизующего центра, делает этот механизм аутентификации практически неприменимым для массового использования, вследствие чего он получил ограниченное распространение в корпоративных сетях, и в широких массах практически неизвестен.
Один из сооснователей криптовалютной сети «Эмеркоин», о которой мы уже писали в нашем блоге, разработчик Олег Ховайко предложил такое прочтение SSL-протокола, которое не требует участия центра сертификации: протокол emcssl предоставляет возможности для децентрализованной работы системы аутентификации. Emcssl смещает фокус процесса аутентификации на пользователя, тем самым, предоставляя возможность пользователям самостоятельно генерировать и распоряжаться идентифицирующими данными.
Emcssl
Emcssl – децентрализованный сервис беспарольной аутентификации, где каждый может сам генерировать свой сертификат, а в качестве авторизующей инстанции выступает блокчейн Эмеркоина.
Emcssl использует клиентские SSL-сертификаты, которые обеспечивают, во-первых, упрощенную авторизацию клиента, во-вторых, создание шифрованного защищённого канала связи с сервером – иными словами, безопасное соединение.
В отличие от других SSL-систем, с помощью emcssl, клиенты, без ограничений и взаимодействия с кем бы то ни было, могут быстро, самостоятельно генерировать сертификат и обновлять его, по собственному усмотрению. Один единственный клиентский SSL-сертификат может быть многократно использован для авторизации на множестве серверов, входящих в систему аутентификации, без ущерба для безопасности. Таким образом, пользователю для полноценного функционирования в интернет-пространстве достаточно одного сертификата, что радикально упрощает доступ к учетным записям, и избавляет от необходимости помнить десятки паролей. Сертификат состоит из публичной части и приватного ключа, который известен только пользователю.
Как работает emcssl?
Для того, чтобы начать использовать emcssl, необходимо запустить программу: 1) сгенерировать личный ssl-сертификат, 2) опубликовать «цифровую подпись» сертификата в EmerCoin NVS и 3) загрузить сертификат в браузер. Первые три шага выполняются лишь один раз.
Далее, вы можете зайти на любой сайт, который поддерживает данную систему авторизации, и впредь входить в свою учётную запись без логина и пароля (ваш браузер уже поставил подпись за вас) полностью автоматически. Если ранее учетной записи на этом сайте у вас не было, то можно создать новую учетную запись на основе сертификата, буквально, в одно нажатие клавиши. Профиль пользователя на сервере автоматически заполняется данными, которые вы сочли нужным предоставить при генерации сертификата.
Как сервер взаимодействует с сертификатом?
Когда пользователь браузера, обладающий сертификатом, захочет посетить какой-либо сайт, на котором уже существует его учетная запись, сайт потребует у браузера предъявить клиентский сертификат.
- При самом первом посещении сайта браузер спросит пользователя, каким сертификатом следует воспользоваться для авторизации. Пользователь выберет сертификат и браузер запомнит, что этому серверу следует предъявлять соответствующий сертификат.
- Сервер, получив сертификат, вначале проверяет подпись сертификата. Успешная проверка подписи доказывает, что сертификат был сгенерирован для системы emcssl. Остальные проверки последуют позже.
- Далее, сервер генерирует случайное число, шифрует его на публичном ключе, находящемся в предъявленном сертификате, и отправляет браузеру. Это — одноразовый пароль этого соединения.
- Браузер извлекает секретный ключ из сертификата и расшифровывает пароль, посланный сервером.
- После этого браузер устанавливает безопасное https-соединение с сервером. Установление такого соединения доказывает серверу, что браузер владеет не только серийным номером сертификата, но и соответствующим секретным ключом. В рамках этой системы секретный ключ никогда не покидает пользовательского компьютера.
- Убедившись в том, что клиент владеет корректным секретным ключом, сервер производит проверку информации сертификата через блокчейн Эмеркоина. Для этого он извлекает из сертификата серийный номер, и выполняет в блокчейне поиск по этому серийному номеру, получая в результате размер вашей хэш-суммы. После этого сервер вычисляет контрольную сумму только что полученного сертификата и убеждается в том, что предъявленный сертификат с соответствующим серийным номером – то же самый, который был зарегистрирован в блокчейне. Таким образом, подтверждается уникальный серийный номер сертификата, который можно использовать для авторизации пользователя.
Если злоумышленник сгенерирует другой сертификат, с таким же серийным номером что и у вас, то он не сможет загрузить такую же контрольную сумму, так как она уже занята. В результате всех проверок, которые, в совокупности, занимают доли секунды, сервер удостоверяется в том, что пришедший клиент: имеет сертификат emcssl, владеет секретным ключом, владеет соответствующим серийным номером сертификата и, в результате, открывает доступ к учетной записи.
Особенностью работы системы является тот факт, что тот, кто владеет доступом к браузеру с загруженным сертификатом, владеет всеми ключами ко всем аккаунтам. В том случае, если у вас украли ноутбук или планшет, вам следует как можно скорее сгенерировать новый сертификат и загрузить его цифровую подпись в блокчейн Эмеркойна. Этот шаг автоматически сделает похищенный сертификат недействительным. К счастью, в этом случае нужно заменить только один сертификат, а не десятки паролей.
Данная система авторизует только браузер и делает сетевое соединение безопасным, но не авторизует оператора. Для верификации на особо важных сервисах лучше применять многофакторную авторизацию.
Система emcssl удачно вписалась в рабочую среду сервиса HashFlare — мы внедрили её в свои панели управлении майнерами. С помощью технологии emcssl в интерфейсе управления майнерами HashFlare можно пройти безопасную аутентификацию, используя те же пользовательские сертификаты, сгенерированные в emcssh.
Так как, клиентский сертификат генерируется в личном кошельке пользователя, в блокчейне Эмеркоина, при условии, что вся система инкорпорирована в пользовательский интерфейс управления майнерами, возникает замкнутый цикл для соло-майнига эмеркоинов, где кошелек эмеркоина внедрен непосредственно в майнер.
Как начать использовать?
Всё программное обеспечение распространяется бесплатно. Пакет для генерации клиентских сертификатов находится здесь: pool.emercoin.com/emcssl Там же можно проверить работу вашего сертификата на тестовой странице.
Комментарии (24)
maxihatop
29.10.2015 07:21> В общем ещё раз — в данной системе используется простейший режим создания подписей на основе уникальности пары «публичный-закрытый ключ»
А безопасное https через TLS-соединение с Вашей точки зрения не создаётся, да.
> Сертификаты тут использованы только для того, чтобы упростить их использование в браузере.
Потому что они стандартные, безопасные и используются всеми. И именно посредством них устанавливается https.
ystr
29.10.2015 08:55Безопасное TLS соединение создаётся когда сертификат является доверенным. Ваши же сертификаты являются самоподписанными и доверенными их считать изначально невозможно. Для осуществления установления доверия к подобным сертификатам нужно будет провести очень большой комплекс процедур. И пока я считаю, что этот «комплекс процедур» будет существенно больше по затратам, чем стандартная модель PKI.
maxihatop
29.10.2015 18:17Ещё раз: Довереность создаётся не стандартным способом, посредством подписывания у СА, а посредством загрузки хеша сертификата в децентрализованый и довереный блокчейн. В этом и состоит новизна технологического решения.
Насчёт «очень большой комплекс процедур» — это на сервере держать кошелёк, который и поддерживает актуальную базу довереных сертификатов. Больше это по затратам, чем покупать сертификаты у СА — это вопрос финансовый, а не технологический. И каждый его решает по своему, в ту или иную пользу. HashCoin, например решил, что EMCSSL для него лучше чем использование внешнего CA.ystr
30.10.2015 06:57Доверенный сертификат или нет в PKI определяется доверием к корневому сертификату цепочки сертификатов для данного пользовательского сертификата. Понятие «доверенный блокчейн» мне понятно слабо. Как я понял из статьи этот блокчейн может однозначно подтвердить только то, что серийный номер сертификата уникален.
ystr
29.10.2015 09:02У вас в статье есть вот такое выражение:
Сервер, получив сертификат, вначале проверяет подпись сертификата. Успешная проверка подписи доказывает, что сертификат был сгенерирован для системы emcssl.
Как сервер проверяет, что именно этот сертификат был сгенерирован для системы emcssl, при условии, что клиентский сертификат самоподписанный?maxihatop
29.10.2015 18:22Корневой CA-каталог, включающий секретный ключ, входит в дистрибутив системы. То есть то, что в обычном СА является секретом — здесь секретом не является. И на этом открытом СА любой участник может подписать свой сертификат. По сути, это сделано только для совместимости с текущей системой сертфиикатов, типа заглушки. Реальная валидация проводится через блокчейн.
ystr
30.10.2015 06:52Так сертификат пользователя самоподписанный или нет?
maxihatop
30.10.2015 06:56Пользователь сам подписывает сертификат на CA-ключе, который есть у него локально.
Поэтому, формально говоря, сертификат самоподписаный.
Но CA-ключ не абы какой, а из дистибутива EMCSSL.
Вот техническое описание технологнии EMCSSL: habrahabr.ru/post/257605ystr
30.10.2015 07:00Мда. Самоподписанным называется сертификат, у которого поля «issuer» и «subject» являются одинаковыми и у которого подпись самого сертификата выполнена с использованием закрытого ключа, соответствующего публичному ключу из данного сертификата. А ваша схема уже формально использует «удостоверяющий центр».
maxihatop
30.10.2015 07:39Будем считать, что я ошибся, называя сертификат самоподписаным.
ystr
30.10.2015 08:05Ну тогда я вам расскажу, как работает ваша система. Всё работает по стандартной схеме PKI: есть один удостоверяющий центр и множество пользовательских сертификатов. Так как сертификат пользователя генерируется самим пользователем, то возникает проблема — отсутствие уникальности серийных номеров сертификатов. Данную проблему вы решаете использованием блокчейна. Так что блокчейн у вас тут крайне второстепенная вещь, которая просто обеспечивает формальные требования к пользовательским сертификатам. Доверенное TLS у вас действительно возникает, но вот только потому, что вы добавляете корневой сертификат вашего так сказать «удостоверяющего центра» в доверенные. То есть выполняете формальные требования.
Однако думаю, что возможны различные претензии к вашим пользовательским сертификатам, вызванные тем, что генерируются они самим пользователем. Так основная претензия будет к качеству генерируемых ключей — при генерации ключей с помощью УЦ возможно использование «правильных алгоритмов» генерации и правильных параметров к ним, а вот при генерации на стороне пользователя с этим уже могут возникнуть сложности. Ну и опять же я до сих пор утверждаю, что в ваших сертификатах полезной нагрузкой является только публичный ключ. На все остальные поля сертификата можно закрывать глаза.ystr
30.10.2015 09:31Также в вашей системе возможна ситуация, когда пользователь изготавливает себе сертификат удостоверяющего центра. И таким образом может начать сам устанавливать политики использования выпущенных сертификатов и другие ограничения. Или сделать очень длинную цепочку сертификатов (скажем в 1000 промежуточных удостоверяющий центров) и создавать тем самым возможные проблемы для «certificate verification engines».
Кстати, ответьте, пожалуйста, на мой вопрос в этой теме.
maxihatop
30.10.2015 20:01Вы неверно поняли. В блокчейне, помимо Serial, хранится ещё и хеш самого сертификата. Поэтому если Вы сгенерируете сертификат с моим Serial=f1551313530859ce, загрузите в свой браузер, и пойдёте на pool.emercoin.com, то сервер Ваш сертификат отвергнет, так как его хеш не будет совпадать с хранящимся в блокчейне.
Фиктивный CА сделан исключительно для совместимости со стандарным механизмом проверки сертификатов, и его приватный ключ секретом не является. Основная проверка пользователя происходит при сравнении хешей.
> утверждаю, что в ваших сертификатах полезной нагрузкой является только публичный ключ.
Утверждение неверно. Ещё совершенно необходим Serial, который идентифицирует пользователя.
И ещё опционально используются другие поля — CN, UID, EMAIL. Но не суть важно.
Даже если Ваше высказывание было бы правдой — ну и что из того следует?
X.509 сертификат взят за основу именно из-за стандартности и распространённости. Его все понимают — как браузеры,
так и веб-сервера. Что не надо городить своих стандартов и костылей в виде плагинов для всего мира.
А что какие-то поля не используются… Ну наверняка в Ваших сертификатах тоже не используются поля OU1..OU4. И будем из того трагедию создавать, и утверждать о неприменимости X.509 в https?ystr
31.10.2015 10:03Наш диалог мне всё больше напоминает вот эту цитату с bash.im.
Понимаете, давным-давно жили умные люди. И захотелось им чтобы было общее хранилище для всех цифровых идентификаторов пользователей. И придумали они стандарт X.500 — и возрадовались. Также были другие умные люди, которые решили, что стандарт X.500 уж больно сложен. И придумали они LDAP (Lightweight Directory Access Protocol), который был проще. Также умные люди придумали ещё один стандарт — X.509, дабы служил он для достоверной передачи сведений о пользователях и достоверной идентификации оных.
А потом, лет эдак через 20, появился чудесный продукт — EMCSSL. И придумали для этого продукта базу данных — «доверенный блокчейн». И хранила она пары «имя-значение» и были эти пары однозначно привязаны к пользователю. С сертификатами в этом продукте решили не заморачиваться, и использовали сильно обрезанные сертификаты из X.509.
А теперь по существу. Вашему «доверенный блокчейну» даже до упрощённых реализаций «X.500 directory» — как до Луны пешком. Все ваши «инновации» и «улучшение SSL» достигаются просто дополнительным уровнем проверки по вашей базе данных («доверенному блокчейну»). Всё это давным-давно возможно, и может быть реализовано гораздо более правильно путём использования стандартных «directories» с доступом по LDAP. Ваши «сертификаты» ущербны потому, что в них отсутствует корректное использование следующих полей:
1) subject;
2) notBefore + notAfter;
3) issuerUniqueID + subjectUniqueID;
4) ну и на сладкое — все поля из «extensions»;
Наверное кто-то решил, что эти поля в сертификатах вторичны. Конечно, зачем умные люди их придумали — мы же живём в «новой цифровой эпохе», тут у нас есть «доверенный блокчейн» :)
Кстати — полей «OU1...OU4» в сертификатах нет. Полагаю, что вы говорите про «organizationalUnitName», а это всего лишь один из элементов имени, используемый в полях сертификата «issuer», «subject» плюс в различных расширениях сертификата (поле «extensions»).
У меня есть куча других дел, кроме копания в вашей поделке. Если мои замечания для вас пустой звук, то мне на самом деле наплевать. Мои замечания здесь тогда будут оценивать другие читатели данной статьи.maxihatop
31.10.2015 14:081. Что такое X.500 DSA и протокол DAP — знаю, сам это конфигурил в 1995-1998м когда-то.
2. Блокчейн не EMCSSL придумал, а Сатоши Накамото вообще-то. И на его доверенности функционирует сеть Биткоин.
3. Да, для авторизации используются обрезанные сертификаты, в которых некоторые поля не используются. Ну и что?
Можно подумать, что Вы всегда используете поле Location, и без использования этого поля https будет уязвим.
4. LDAP — использовать можно. Но это — централизованое хранилище, со всеми присущими ему недостатками. Например таким, что хозяин сервера волюнтаристки заменит мой сертификат в своей базе и пойдёт по всем моим акаунтам шарить.
3. Про поля — subject, etc. В обычном username/password тоже нет ничего из перечисленых Вами полей, а поди ж всё работает, и хватает. Почему Вы считаете использование этих полей необходимым в нашей системе? Как отсутствие этих полей повысит уязвисмость? Особенно при использовании блокчейна в качестве идеального CRL?
4. OU1-4: Да, перепутал-с по памяти с полями X.400. В X.509 там всё попроще будет, и вместо 4х OU — только один, без номера. Никто это поле практически не использует, вот и подзабыл точно структуру полей. Но всё равно мой изначальный вопрос остаётся — как тот факт, что в сертификате есть практически неиспользуемое поле, снижает защищённость https?
5. Ну и наплюйте.
Резюмирую:
Да, в EMCSSL сертификаты используются в весьма сокращённом виде, и часть функционала (CA+CRL) обеспечивается блокчейном. Не вижу в том трагедии. Также, как не вижу трагедии в использовании LDAP вместо полноценного DAP.
Понятно, что без блокчейна, только при использовании сертификатов, EMCSSL не будет обеспечивать безопасности. Ну так это ж и не предлагается. Зато с блокчейном — безопасность выше, чем при использовании классической PKI. Хотя бы потому, что в случае централизованного CА можно на этот СА надавить, чтоб выписал какой надо сертификат от любого имени.
ystr
У меня остался один вопрос: зачем в данной системе использовать именно сертификат, когда из всех полей сертификата реально можно использовать только одно — публичный ключ? Поясню почему нельзя использовать другие поля сертификата: закрытый и публичный ключ генерирует сам пользователь, хэш сумма вычисляется только от общего массива получившегося сертификата. Таким образом в данной системе могут быть миллионы сертификатов выданных, например, Владимиру Владимировичу Путину. Или Биллу Гейтсу. Так что пока считаю, что в данной чудесной системе можно обойтись и без PKI — просто использовать массив публичного ключа.
POS_troi
Фактически эта система будет работать но в рамках одного ресурса — к примеру доступ к части корпоративного сайта, там где эти сертификаты будут генерироваться и выдаваться лицом которое может проверить личность будущего владельца сертификата. Что собственно не редкость в банковской сфере и гос.
В глобальных системах это реализовать сложно по причинам вышеуказанным, хотя в маштабах страны это реализовать возможно но врятли гос. структура согласиться делиться такими данными с тем-же ВК, не говоря уже о мелких ресурсах.
maxihatop
> Фактически эта система будет работать
Вообще-то — уже работает.
> но в рамках одного ресурса — к примеру доступ к части корпоративного сайта, там где эти сертификаты будут
> генерироваться и выдаваться лицом которое может проверить личность будущего владельца сертификата.
Вы говорите о простом использовании клиентских сертификатов, с верификацией через CA.
Здесь же в качестве верификатора выступает распрёделённый глобальный блокчейн.
И сертификаты самоподписаные, то есть создаются без участия СА.
> В глобальных системах это реализовать сложно по причинам вышеуказанным,
EMCSSL — глобальная система. В ней реализовано. Сгенерите сертификат — и идите на любой сайт, который EMCSSL поддерживает, наример pool.emercoin.com. Хотя конечно в рамках какой-либо организации это тоже можно использовать.
> хотя в маштабах страны это реализовать возможно но врятли гос. структура согласиться делиться такими данными
> с тем-же ВК, не говоря уже о мелких ресурсах.
А EMCSSL не требует участия третьего лица. Вы захотели обзавестись сертификатом — скачиваете скрипты, и генерите локально. От воли гос. структур тут ничего не зависит.
ystr
Ах вот оно что — сертификаты самоподписаные. Тогда тем более нет никакой (вообще) причины использовать именно сертификаты. Если у вас возникает проблема с использованием публичного/приватного ключа при создании коммуникаций в браузере, то вполне вероятно написать самостоятельное расширение.
maxihatop
Ага… Написать самостоятельное расширение для каждого браузера… Потом для всех веб-серверов… Потом проверить безопасность BAN-логикой… Потом сделать это стандартом…
По-моему, Вы предлагаете снова пройти путь стандарта X.509. Зачем?
Чем Вам сертификаты не угодили — стандартные, провереные, поддерживаемые всеми браузерами и WEB-серверами?
maxihatop
> зачем в данной системе использовать именно сертификат, когда из всех полей сертификата реально можно использовать только одно — публичный ключ?
Ещё используются Serial, СN и UID.
> Поясню почему нельзя использовать другие поля сертификата: закрытый и публичный ключ генерирует сам пользователь, хэш сумма вычисляется только от общего массива получившегося сертификата.
Утверждение неверно. Сертификат не содержит закрытого ключа. Смотрите пример сертификатата — где тут приватный ключ?
> Таким образом в данной системе могут быть миллионы сертификатов выданных, например, Владимиру Владимировичу Путину.
Да. Но только первый из них, кто загрузил в NVS — захватывает соответствующий Serial ID. Другие сертификаты с тем же Serial отвергаются. Этим обеспечивается уникальность Serial как userID.
> Так что пока считаю, что в данной чудесной системе можно обойтись и без PKI — просто использовать массив публичного ключа.
Я не понимаю, что это такое «массив публичного ключа». Но если Вы его сможете загрузить в браузер безо всяких дополнительный plugins, и чтоб браузер его предьявлял когда и кому надо, и чтоб его все WEB-сервера при установлении TLS-сессии понимали — тогда наверное можно сделать что-то эдакое по Вашему, да.
ystr
В общем ещё раз — в данной системе используется простейший режим создания подписей на основе уникальности пары «публичный-закрытый ключ». Сертификаты тут использованы только для того, чтобы упростить их использование в браузере. Из всего сертификата используется только массив публичного ключа. Какое-либо использование подобных «сертификатов» в PKI просто невозможно.