Что интересно: В прошлый четверг, 29 октября, представители Emercoin Group передали Чобаняну техническое описание протокола децентрализованого аукциона на базе блокчейна. Протокол позволяет провести честный аукцион, в котором продавец не может «не заметить» той или иной заявки, дважды продать объект разным покупателям, украсть деньги, не передав обьект покупателю и пр. В общем — технология для борьбы с коррупцией и прочими злоупотреблениями при продаже собственности (втч государственной).
Не прошло и недели — и вот вам и пожалуйста…
1. Что такое 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А можно на этот СА надавить, чтоб выписал какой надо сертификат от любого имени.
Вы неверно поняли. В блокчейне, помимо Serial, хранится ещё и хеш самого сертификата. Поэтому если Вы сгенерируете сертификат с моим Serial=f1551313530859ce, загрузите в свой браузер, и пойдёте на pool.emercoin.com, то сервер Ваш сертификат отвергнет, так как его хеш не будет совпадать с хранящимся в блокчейне.
Фиктивный CА сделан исключительно для совместимости со стандарным механизмом проверки сертификатов, и его приватный ключ секретом не является. Основная проверка пользователя происходит при сравнении хешей.
> утверждаю, что в ваших сертификатах полезной нагрузкой является только публичный ключ.
Утверждение неверно. Ещё совершенно необходим Serial, который идентифицирует пользователя.
И ещё опционально используются другие поля — CN, UID, EMAIL. Но не суть важно.
Даже если Ваше высказывание было бы правдой — ну и что из того следует?
X.509 сертификат взят за основу именно из-за стандартности и распространённости. Его все понимают — как браузеры,
так и веб-сервера. Что не надо городить своих стандартов и костылей в виде плагинов для всего мира.
А что какие-то поля не используются… Ну наверняка в Ваших сертификатах тоже не используются поля OU1..OU4. И будем из того трагедию создавать, и утверждать о неприменимости X.509 в https?
Корневой CA-каталог, включающий секретный ключ, входит в дистрибутив системы. То есть то, что в обычном СА является секретом — здесь секретом не является. И на этом открытом СА любой участник может подписать свой сертификат. По сути, это сделано только для совместимости с текущей системой сертфиикатов, типа заглушки. Реальная валидация проводится через блокчейн.
Ещё раз: Довереность создаётся не стандартным способом, посредством подписывания у СА, а посредством загрузки хеша сертификата в децентрализованый и довереный блокчейн. В этом и состоит новизна технологического решения.
Насчёт «очень большой комплекс процедур» — это на сервере держать кошелёк, который и поддерживает актуальную базу довереных сертификатов. Больше это по затратам, чем покупать сертификаты у СА — это вопрос финансовый, а не технологический. И каждый его решает по своему, в ту или иную пользу. HashCoin, например решил, что EMCSSL для него лучше чем использование внешнего CA.
> В общем ещё раз — в данной системе используется простейший режим создания подписей на основе уникальности пары «публичный-закрытый ключ»
А безопасное https через TLS-соединение с Вашей точки зрения не создаётся, да.
> Сертификаты тут использованы только для того, чтобы упростить их использование в браузере.
Потому что они стандартные, безопасные и используются всеми. И именно посредством них устанавливается https.
Ага… Написать самостоятельное расширение для каждого браузера… Потом для всех веб-серверов… Потом проверить безопасность BAN-логикой… Потом сделать это стандартом…
По-моему, Вы предлагаете снова пройти путь стандарта X.509. Зачем?
Чем Вам сертификаты не угодили — стандартные, провереные, поддерживаемые всеми браузерами и WEB-серверами?
> но в рамках одного ресурса — к примеру доступ к части корпоративного сайта, там где эти сертификаты будут
> генерироваться и выдаваться лицом которое может проверить личность будущего владельца сертификата.
Вы говорите о простом использовании клиентских сертификатов, с верификацией через CA.
Здесь же в качестве верификатора выступает распрёделённый глобальный блокчейн.
И сертификаты самоподписаные, то есть создаются без участия СА.
> В глобальных системах это реализовать сложно по причинам вышеуказанным,
EMCSSL — глобальная система. В ней реализовано. Сгенерите сертификат — и идите на любой сайт, который EMCSSL поддерживает, наример pool.emercoin.com. Хотя конечно в рамках какой-либо организации это тоже можно использовать.
> хотя в маштабах страны это реализовать возможно но врятли гос. структура согласиться делиться такими данными
> с тем-же ВК, не говоря уже о мелких ресурсах.
А EMCSSL не требует участия третьего лица. Вы захотели обзавестись сертификатом — скачиваете скрипты, и генерите локально. От воли гос. структур тут ничего не зависит.
> зачем в данной системе использовать именно сертификат, когда из всех полей сертификата реально можно использовать только одно — публичный ключ?
Ещё используются Serial, СN и UID.
> Поясню почему нельзя использовать другие поля сертификата: закрытый и публичный ключ генерирует сам пользователь, хэш сумма вычисляется только от общего массива получившегося сертификата.
Утверждение неверно. Сертификат не содержит закрытого ключа. Смотрите пример сертификатата — где тут приватный ключ?
> Таким образом в данной системе могут быть миллионы сертификатов выданных, например, Владимиру Владимировичу Путину.
Да. Но только первый из них, кто загрузил в NVS — захватывает соответствующий Serial ID. Другие сертификаты с тем же Serial отвергаются. Этим обеспечивается уникальность Serial как userID.
> Так что пока считаю, что в данной чудесной системе можно обойтись и без PKI — просто использовать массив публичного ключа.
Я не понимаю, что это такое «массив публичного ключа». Но если Вы его сможете загрузить в браузер безо всяких дополнительный plugins, и чтоб браузер его предьявлял когда и кому надо, и чтоб его все WEB-сервера при установлении TLS-сессии понимали — тогда наверное можно сделать что-то эдакое по Вашему, да.
> С одной стороны, я бы предпочел хранить в блокчаине любые значения, а не только ключи
EMC NVS сделан так, что там и можно хранить любые значения — до 20KB каждое. И emcSSH — только один из сервисов. Есть ещё и многое другое — DNS, SSL, LNX, DPO — подробности на сайте emercoin.com
> но тогда будет очень легко забить его всяким мусором
Легко, но дорого. Когда система разрабатывалась, мы сделали такую цену записи, чтобы с одной стороны — не мешала честным пользователям, а с другой — ограничила инфяцию блокчейна от злонамереного раздувания. В результате, применённая система ценообразования такова, что для раздутия блокчейна до 60G нужно сжечь всю денежную массу EMC, что практически недостижимо.
Про IPFS — надо будет внимательнее почитать, и возможно — проверить BAN-логикой, если технология заинтересует.
Про табличку — передам пожелания авторам статьи. Я то не автор, я изобреталель emcSSH (Ну и emcSSL заодно).
1. Эмеркоин хранит не просто слово, а пару ключ-значение. SSH-ключ выступает здесь в роли хранимого значения.
Для одного и того же поискового ключа(имени) хозяин всегда может менять значение — например, заменить устаревший или потенциально скомпрометированый ssh-ключ на новый, тем самым автоматически отозвав старый ключ. Или добавить в группу нового пользователя.
2. В DHT можно искать ключ по его хешу, да. Но как быть с комрометироваными ключами, которые надо отозвать? При замене ключа на другой — неизбежно поменяется и его хеш. Если ключ определяется его хешем — значит, нужен безопасный механизм смены хеша старого ключа на хеш нового у всех пользователей сети. То есть задача возвращается к изначальной, просто вместо самого ключа фигурирует его хеш, а проблемы управления (добавление, отзыв, группирование) остаются.
> В чем преимущество цепочки блокчаинов перед распределенной dht или централизованными хранилищами?
Cнова повторю. В достоверности. В том, что MIM (например, провайдер Вашего сервера) может
подменить ответ из DHT на то, что ему хочется, и тем обеспечить себе несанкционированый доступ.
То есть, в DHT будет лежать одно, а Ваш сервер, когда запросит публичный ключ приходимца, получит у MIMa
нечто совершенно другое, выданное MIMом и прохешированое как положено.
Более того, при желании MIM сможет даже сделать локальный филиал DHT, с нужными ему values и значениями хешей.
С блокчейном такой фокус не пройдёт — MIM должен постоянно майнить сильнее всей остальной сети, для
поддержки фальшивого блокчейна. Причёи начиная с блока(момента), публикации ключа, который он решил подменить.
Касаемо мобильных приложений: Блокчейн нужен только на сервере. Клиент единственный раз публикует публичный
ключ — можно даже с другого компа, не мобильного. Поэтому проблема не стоит.
> В чем преимущество цепочки блокчаинов перед распределенной dht или централизованными хранилищами?
В достоверности, которую поддерживает множество независимых майнеров. Блокчейн один, и подмена записей или создание фальшивой альтернативы ему практически невозможны.
> Зачем мне как пользователю выгружать себе цепочку со всеми ключами всех гиков всей планеты?
Так уж блокчейн устроен, что хранится всё. Ну если у Вас дефицит дискового пространства, и нет лишнего десятка гигов — остаётся посочуствовать…
> мне больше подойдет DHT или IPFS или еще что-то такое
Прекрасно! Сделайте продукт, опубликуйте! Вы измените мир к лучшему.
Отвечу на оба вышерасположенных коммента сразу. Для начала процитирую Пруткова:
Многие вещи нам непонятны не потому, что наши понятия слабы; но потому, что сии вещи не входят в круг наших понятий.
Здесь мы наблюдаем нечто подобное. Вопросы оппонентов происходят из того, что они мыслят в парадигме «PKI масштаба предприятия».
Если мыслить в этих рамках, то действительно, можно использовать «puppet, etc» и про блокчейн не вспоминать. Однако рассмотренная в статье система emcSSH — это PKI всемирного масштаба. Которая будет функционировать и после того, как то или иное предприятие выйдет из бизнеса, вместе с серверами, на которых работали «puppet, etc».
Ещё раз обращу внимание: emcSSH не принадлежит кому-либо, ни частному лицу, ни организации. Независимые участники могут размещать свои ключи, другие — создавать из них группы и администирть их, третьи — импортировать уже существующие группы в те или иные проекты, в том числе — и в вновь созданные предприятия. Согласитесь, что ситуация, когда человек или группа людей переживает крах одного предприятия и создание нового — довольно типична.
> Сейчас выбираются программные движки для создания следующих сервисов:
> 1) Децентрализованный DNS (скорее всего namecoin / P2P DNS)
Я хочу предложить к рассмотрению распределённый децентрализованый DNS, базирующийся на EmerCoin: DNS and Name-Value Storage
Чем EmerCoin DNS лучше аналогичного сервиса от Namecoin?
1. Каждый кошелёк является нативным DNS-сервером стандарта RFC1034
2. Поддерживается не одна фиксированая TLD-зона *.bit, a четыре (*.lib *.emc *.coin *.bazar), c возможностью добавления новых.
3. Хранилище NVS может быть использовано для ряда других сервисов, предложенных в документе выше.
4. Некоторые уникальные сервисы уже написаны и успешно эксплуатируются (emcssl, emcssh)
5. Бесплатная и дружественная поддержка от EmerCoin team. Просто напишите на team(symbol)emercoin.com, и Вам с радостью помогут.
Подход с клиентскими сертификатами — правильный. Мы расширили этот подход, чтобы одним сертификатом клиент мог логиниться на много сайтов, и сделали децентрализованный механизм генерации и отзыва такого сертификата. Получилось это — habrahabr.ru/post/257605
Не прошло и недели — и вот вам и пожалуйста…
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А можно на этот СА надавить, чтоб выписал какой надо сертификат от любого имени.
Фиктивный CА сделан исключительно для совместимости со стандарным механизмом проверки сертификатов, и его приватный ключ секретом не является. Основная проверка пользователя происходит при сравнении хешей.
> утверждаю, что в ваших сертификатах полезной нагрузкой является только публичный ключ.
Утверждение неверно. Ещё совершенно необходим Serial, который идентифицирует пользователя.
И ещё опционально используются другие поля — CN, UID, EMAIL. Но не суть важно.
Даже если Ваше высказывание было бы правдой — ну и что из того следует?
X.509 сертификат взят за основу именно из-за стандартности и распространённости. Его все понимают — как браузеры,
так и веб-сервера. Что не надо городить своих стандартов и костылей в виде плагинов для всего мира.
А что какие-то поля не используются… Ну наверняка в Ваших сертификатах тоже не используются поля OU1..OU4. И будем из того трагедию создавать, и утверждать о неприменимости X.509 в https?
Серийный номер и является однозначным идентификатором, принадлежащим какому-то одному уникальному юзеру.
Поэтому, формально говоря, сертификат самоподписаный.
Но CA-ключ не абы какой, а из дистибутива EMCSSL.
Вот техническое описание технологнии EMCSSL: habrahabr.ru/post/257605
Насчёт «очень большой комплекс процедур» — это на сервере держать кошелёк, который и поддерживает актуальную базу довереных сертификатов. Больше это по затратам, чем покупать сертификаты у СА — это вопрос финансовый, а не технологический. И каждый его решает по своему, в ту или иную пользу. HashCoin, например решил, что EMCSSL для него лучше чем использование внешнего CA.
А безопасное https через TLS-соединение с Вашей точки зрения не создаётся, да.
> Сертификаты тут использованы только для того, чтобы упростить их использование в браузере.
Потому что они стандартные, безопасные и используются всеми. И именно посредством них устанавливается https.
По-моему, Вы предлагаете снова пройти путь стандарта X.509. Зачем?
Чем Вам сертификаты не угодили — стандартные, провереные, поддерживаемые всеми браузерами и WEB-серверами?
Вообще-то — уже работает.
> но в рамках одного ресурса — к примеру доступ к части корпоративного сайта, там где эти сертификаты будут
> генерироваться и выдаваться лицом которое может проверить личность будущего владельца сертификата.
Вы говорите о простом использовании клиентских сертификатов, с верификацией через CA.
Здесь же в качестве верификатора выступает распрёделённый глобальный блокчейн.
И сертификаты самоподписаные, то есть создаются без участия СА.
> В глобальных системах это реализовать сложно по причинам вышеуказанным,
EMCSSL — глобальная система. В ней реализовано. Сгенерите сертификат — и идите на любой сайт, который EMCSSL поддерживает, наример pool.emercoin.com. Хотя конечно в рамках какой-либо организации это тоже можно использовать.
> хотя в маштабах страны это реализовать возможно но врятли гос. структура согласиться делиться такими данными
> с тем-же ВК, не говоря уже о мелких ресурсах.
А EMCSSL не требует участия третьего лица. Вы захотели обзавестись сертификатом — скачиваете скрипты, и генерите локально. От воли гос. структур тут ничего не зависит.
Ещё используются Serial, СN и UID.
> Поясню почему нельзя использовать другие поля сертификата: закрытый и публичный ключ генерирует сам пользователь, хэш сумма вычисляется только от общего массива получившегося сертификата.
Утверждение неверно. Сертификат не содержит закрытого ключа. Смотрите пример сертификатата — где тут приватный ключ?
> Таким образом в данной системе могут быть миллионы сертификатов выданных, например, Владимиру Владимировичу Путину.
Да. Но только первый из них, кто загрузил в NVS — захватывает соответствующий Serial ID. Другие сертификаты с тем же Serial отвергаются. Этим обеспечивается уникальность Serial как userID.
> Так что пока считаю, что в данной чудесной системе можно обойтись и без PKI — просто использовать массив публичного ключа.
Я не понимаю, что это такое «массив публичного ключа». Но если Вы его сможете загрузить в браузер безо всяких дополнительный plugins, и чтоб браузер его предьявлял когда и кому надо, и чтоб его все WEB-сервера при установлении TLS-сессии понимали — тогда наверное можно сделать что-то эдакое по Вашему, да.
EMC NVS сделан так, что там и можно хранить любые значения — до 20KB каждое. И emcSSH — только один из сервисов. Есть ещё и многое другое — DNS, SSL, LNX, DPO — подробности на сайте emercoin.com
> но тогда будет очень легко забить его всяким мусором
Легко, но дорого. Когда система разрабатывалась, мы сделали такую цену записи, чтобы с одной стороны — не мешала честным пользователям, а с другой — ограничила инфяцию блокчейна от злонамереного раздувания. В результате, применённая система ценообразования такова, что для раздутия блокчейна до 60G нужно сжечь всю денежную массу EMC, что практически недостижимо.
Про IPFS — надо будет внимательнее почитать, и возможно — проверить BAN-логикой, если технология заинтересует.
Про табличку — передам пожелания авторам статьи. Я то не автор, я изобреталель emcSSH (Ну и emcSSL заодно).
Для одного и того же поискового ключа(имени) хозяин всегда может менять значение — например, заменить устаревший или потенциально скомпрометированый ssh-ключ на новый, тем самым автоматически отозвав старый ключ. Или добавить в группу нового пользователя.
2. В DHT можно искать ключ по его хешу, да. Но как быть с комрометироваными ключами, которые надо отозвать? При замене ключа на другой — неизбежно поменяется и его хеш. Если ключ определяется его хешем — значит, нужен безопасный механизм смены хеша старого ключа на хеш нового у всех пользователей сети. То есть задача возвращается к изначальной, просто вместо самого ключа фигурирует его хеш, а проблемы управления (добавление, отзыв, группирование) остаются.
3. Да.
Cнова повторю. В достоверности. В том, что MIM (например, провайдер Вашего сервера) может
подменить ответ из DHT на то, что ему хочется, и тем обеспечить себе несанкционированый доступ.
То есть, в DHT будет лежать одно, а Ваш сервер, когда запросит публичный ключ приходимца, получит у MIMa
нечто совершенно другое, выданное MIMом и прохешированое как положено.
Более того, при желании MIM сможет даже сделать локальный филиал DHT, с нужными ему values и значениями хешей.
С блокчейном такой фокус не пройдёт — MIM должен постоянно майнить сильнее всей остальной сети, для
поддержки фальшивого блокчейна. Причёи начиная с блока(момента), публикации ключа, который он решил подменить.
Касаемо мобильных приложений: Блокчейн нужен только на сервере. Клиент единственный раз публикует публичный
ключ — можно даже с другого компа, не мобильного. Поэтому проблема не стоит.
В достоверности, которую поддерживает множество независимых майнеров. Блокчейн один, и подмена записей или создание фальшивой альтернативы ему практически невозможны.
> Зачем мне как пользователю выгружать себе цепочку со всеми ключами всех гиков всей планеты?
Так уж блокчейн устроен, что хранится всё. Ну если у Вас дефицит дискового пространства, и нет лишнего десятка гигов — остаётся посочуствовать…
> мне больше подойдет DHT или IPFS или еще что-то такое
Прекрасно! Сделайте продукт, опубликуйте! Вы измените мир к лучшему.
Многие вещи нам непонятны не потому, что наши понятия слабы; но потому, что сии вещи не входят в круг наших понятий.
Здесь мы наблюдаем нечто подобное. Вопросы оппонентов происходят из того, что они мыслят в парадигме «PKI масштаба предприятия».
Если мыслить в этих рамках, то действительно, можно использовать «puppet, etc» и про блокчейн не вспоминать. Однако рассмотренная в статье система emcSSH — это PKI всемирного масштаба. Которая будет функционировать и после того, как то или иное предприятие выйдет из бизнеса, вместе с серверами, на которых работали «puppet, etc».
Ещё раз обращу внимание: emcSSH не принадлежит кому-либо, ни частному лицу, ни организации. Независимые участники могут размещать свои ключи, другие — создавать из них группы и администирть их, третьи — импортировать уже существующие группы в те или иные проекты, в том числе — и в вновь созданные предприятия. Согласитесь, что ситуация, когда человек или группа людей переживает крах одного предприятия и создание нового — довольно типична.
Читайте и делайте. Ничего сложного:
cryptor.net/tutorial/sozdaem-ssl-sertifikat-emcssl-dlya-avtorizacii-na-saytah
> 1) Децентрализованный DNS (скорее всего namecoin / P2P DNS)
Я хочу предложить к рассмотрению распределённый децентрализованый DNS, базирующийся на EmerCoin: DNS and Name-Value Storage
Чем EmerCoin DNS лучше аналогичного сервиса от Namecoin?
1. Каждый кошелёк является нативным DNS-сервером стандарта RFC1034
2. Поддерживается не одна фиксированая TLD-зона *.bit, a четыре (*.lib *.emc *.coin *.bazar), c возможностью добавления новых.
3. Хранилище NVS может быть использовано для ряда других сервисов, предложенных в документе выше.
4. Некоторые уникальные сервисы уже написаны и успешно эксплуатируются (emcssl, emcssh)
5. Бесплатная и дружественная поддержка от EmerCoin team. Просто напишите на team(symbol)emercoin.com, и Вам с радостью помогут.