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

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

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

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

Новизна предложения заключается в полной децентрализации системы, то есть отсутствия некой группы серверов авторизации под единым управлением, что имеет место в системах Kerberos, OpenID, TeddyID и им подобных. В результате, становится невозможным блокировка пользователя посредством административного ресурса, или же одномоментного отказа в обслуживании всей системы авторизации из-за технических сбоев или злонамеренных атак на серверы авторизации.

Текущее положение дел

В современном Интернете основным способом аутентификации клиента на сервере является система паролей. Её идея состоит в том, что пользователю известен некий секретный пароль, который он предъявляет сайту в процессе авторизации, чем и подтверждает свою идентичность. Данная система, при внешней простоте, обладает рядом существенных недостатков:

• Слабые пароли. Обычно право придумать пароль предоставляется пользователю, и он зачастую придумывает пароль, который может быть легко подобран по словарю или вариациям словаря. Подробности можно прочесть здесь: www.volex-old.vlx9.ru/internet-news/3062
• Сложные пароли. Чтобы избежать слабых паролей, многие сайты заставляют людей изобретать сложные пароли, которые в обязательном порядке должны содержать те или иные символы. В результате, сайты проявляют чрезмерную «разборчивость», и для них даже пароль «mWxbq7LECJ7m4Gtu95L» выглядит слабым. А так как требования к паролям не стандартизированы, то пароль может быть отвергнут и по другой причине – например, вышеприведённый пароль был отвергнут неким сайтом, так как его длина превысила 16 символов.
• Сложность управление паролями. Так как нет единого стандарта требований к паролям, то невозможно и создать универсальный генератор паролей, результат которого подходит ко всем сайтам. В результате, люди изобретают «хранители паролей» — типа запароленого на мастер-пароле хранилища, где лежат все другие пароли. Кроме того, многие сайты требуют регулярной смены пароля, что приводит к тому, что такой пароль просто не запоминают, и записывают куда-либо, чтобы не забыть. Надо ли говорить, что запись пароля в открытом виде – прямой путь к его компрометации?
• Необходимость уникального пароля для каждого сайта. Так как при логине на сайт требуется предъявить пароль (то есть раскрыть секрет), то даже в случае добросовестного поведения сайта пароль может быть перехвачен при пересылке по сети, или же украден в результате взлома сайта, что происходит сравнительно регулярно. В случае же использования одного и того же пароля для разных сайтов, утечка такого пароля приводит просто к катастрофическим последствиям – хозяин, в случае возникновения подозрения в компрометации пароля, вынужден судорожно вспоминать, где он этот пароль когда-то использовал, и срочно –срочно обходить все сайты и менять пароль (если успеет).
• Восстановление забытых и утерянных паролей. Наверняка с этим все сталкивались, и проходили процедуру доказывания, что «я не верблюд». А кое-когда процедуру до конца пройти так и не удаётся, и приходится бросать учётную запись (account).

Существующие альтернативы

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

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

Существует также вариант, когда для авторизации использует для некоего сайта сертификат, выданный этим же сайтом и только им и признаваемый. Это бесплатно для клиента, но приводит к постоянным работам по поддержанию актуальности базы сертификатов. Нетрудно заметить, что если Вы имеете учётные записи на 52 сайтах (вполне реальное число для пользователя интернета), и используете стандартные сертификаты сроком на 1 год, то в среднем раз в неделю Вам надо будет обновлять тот или иной сертификат.

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

Также стоит упомянуть о решении от криптовалюты NXT «authorization token» — nxtcoin.wikia.com/wiki/Nxt_Software. Суть его заключается в том, что для каждой пары (site, username) генерируется уникальный жетон авторизации, который клиент предъявляет при логине серверу, а тот проверяет полученный жетон через blockchain NXT. К сожалению, этот механизм не обеспечивает безопасности, так как при авторизации жетон передаётся целиком, что делает возможным перехват жетона атакой Main-In-the-Middle, либо фишинговым сайтом или чем-либо подобным, с последующим злонамеренным и неограниченным использованием жетона перехватчиком.

Как сейчас используется SSL

В настоящее время, наиболее популярным механизмом защиты сетевого соединения является SSL – Secure Socket Layer. Наибольшее распространение получила система серверных сертификатов, то есть механизм, когда сервер доказывает клиенту что он – это он и есть, а не мошеннический сервер-дубликат. Кроме доказательства аутентичности сервера, SSL устанавливает шифрованное соединение между клиентом и сервером. Вот как это работает:



Типичный пример установки безопасного SSL-соединения:

1. Сервер пересылает свой SSL-сертификат, содержащий публичный ключ шифрования, пользователю
2. Пользователь проверяет подпись на сертификате и убеждается, что сертификат сервера был выдан доверенным агентом, которому можно верить.
3. Пользователь пересылает случайное число, зашифрованное публичным ключом от сервера
4. В случае успешной расшифровки этого числа на сервере, устанавливается безопасная SSL сессия

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



Проблема SSL соединений. Если существует возможность внедрения фальшивого корневого сертификата X.509 на пользовательские устройства (с целью слежения, контроля за трафиком), например, в корпоративном секторе, возникает возможность атаки “man in middle”

1. Сервер пересылает публичный SSL ключ пользователю
2. Злоумышленник перехватывает сертификат и подменяет своим.
3. Пользователь проверяет подменённый сертификат, но проверка проходит успешно, так как атакующий уже внесён в список доверенных агентов, и ему верят.
4. Пользователь шифрует случайное число с поддельным сертификатом и отправляет мнимому серверу, на самом деле – человеку посередине, man-in-the-middle.
5. Злоумышленник успешно расшифровывает число пользователя, чем устанавливает безопасное соединение к пользователю. Одновременно, злоумышленник устанавливает другое безопасное соединение к серверу, используя настоящий серверный сертификат.
6. Запуск компрометированного соединения SSL под контролем злоумышленника

Клиентские же SSL-сертификаты, которыми клиент также доказывает серверу свою аутентичность, в настоящее время почти не используются, а для аутентификации клиентов используется парольный механизм.

Введение в emcssl

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

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

Указанные отличия позволяют заявлять о практической применимости нашей системы авторизации в широких массах.


Исключение возможности атаки «man in middle» с помощью блокчейна (приложение emсssl):

1. Пользователь передает серверу SSL-сертификат
2. Сервер проверяет подлинность полученного сертификата по подписи, хранящейся в распределенном хранилище NVS.
3. Безопасная SSL сессия установлена только в случае идентичности сертификатов (нет подмены).

Как это выглядит для пользователя?

1. Вы запускаете программу и локально генерируете (либо обновляете) личный SSL-сертификат.
2. Вы публикуете (либо обновляете) «цифровую подпись» сертификата в EmerCoin NVS.
3. Вы загружаете сертификат в браузер.
4. Пункты 1-3 надо выполнить один единственный раз. После этого, в течение срока жизни сертификата (в нашей системе это 5 лет по умолчанию, может быть изменено) Вы только делаете следующее:
5. Магия! Идёте на любой сайт, который поддерживает данную систему, и входите в свою учётную запись без логина и пароля. Все делается автоматически! Как будто у Вас «вечный логин».
6. А если учётной записи на этом сайте ранее не существовало – Вы просто нажимаете кнопку типа «создать новую учётную запись на основе сертификата», и запись создаётся автоматически! Причём профиль пользователя на сервере автоматически заполняется данными, которые Вы предоставили при генерации сертификата. Вы можете их и не предоставлять, это Ваше право. Но весьма приятно, когда по одному клику сразу заполняется полный профиль.

Как это работает на практике

Для генерации пользовательских сертификатов emcssl Вам надо скачать toolkit с сайта pool.emercoin.com/emcssl для своей ОС, и распаковать в какую-либо директорию. Никакой инсталляции не требуется. Toolkit состоит из трёх *.sh скриптов для unix-подобных ОС. В Windows-версии присутствуют также набор утилит win-bash и openssl, а также *.bat файлы, запускающие соответствующие *.sh-скрипты. Сайт также содержит ссылку на тест-страницу, которая печатает Вам содержимое сертификата emcssl и InfoCard, если таковая присутствует.

Рассмотрим процесс генерации и использования сертификата шаг за шагом.

1. Генерация шаблона.
   Вначале, Вы генерируете шаблон сертификата с помощью 1-ой программы, gen_tpl.sh. Программа последовательно запрашивает у Вас атрибуты будущего сертификата:
   
   • CommonName – имя пользователя. Это обязательный параметр. В качестве такового можно использовать loign name, username, или просто имя и фамилию, разделённые пробелом.
   • Email – Ваш e-mail address. Это необязательный параметр, может быть пропущен. Но если указан – может быть использован сервером для заполнения соответствующего поля учётной записи.
   • UID – Необязательный параметр. Это ссылка на дополнительную информацию о владельце сертификата, которую он желает о себе предоставить. В качестве таковой предполагается использовать ссылку на EmerCoin infocard (префикc NVS-сервиса info). EmerCoin infocard хранится в блокчейне в зашифрованом виде, а info-ссылка содержит ключ расшифровки. Таким образом, доступ к информации имеет не кто угодно, а только те сайты, для которых Вы используете соответствующий сертификат, содержащий ссылку.
   
   В результате работы этой программы создаётся шаблон сертификата – файл, содержащий введённые Вами атрибуты, и имеющий случайное имя, представляющее собою серийный номер будущего сертификата и суффикс *.tpl, например, 84aa5f2c6527eb33.tpl.
   Далее, на основании этого шаблона, будет возможность генерировать различные сертификаты с одними и теми же параметрами. Это позволит Вам легко и удобно обновлять сертификаты по истечению срока их действия, или же при подозрении в том, что сертификат был скомпрометирован.
   При желании Вы можете сгенерировать несколько шаблонов, из которых потом произвести несколько сертификатов, а потом обновлять последние по необходимости.
   
2. Генерация сертификата.
   Далее происходит собственно генерация (или обновление) сертификата. Для этого запускаем программу gen_crt.sh, передавая ей в качестве параметра файл шаблона. Пример вызова:
   ./gen_crt.sh 84aa5f2c6527eb33.tpl
   Программа генерирует собственно сертификат (файл *.crt), и пакет загрузки в браузер (*.p12), содержащий как сертификат, так и ассоциированный с ним секретный ключ. В процессе генерации пакета программа просит Вас ввести пароль. Этот пароль будет впоследствии запрошен браузером в процессе загрузки пакета (см. п. 4). Пароль защищает содержимое файла *.p12 от последующего неавторизованного использования этого файла. В результате, если даже сам файл был похищен, то злоумышленник не сможет его использовать, не зная пароля.
   
   Секретный ключ, который был использован для генерации пакета, тут же удаляется, так как использованию отдельно от пакета более не подлежит. По завершению работы, кроме создания двух файлов (*.crt, *.p12), программа печатает важное сообщение, наподобие:
   
   Your new certificate in the file 84aa5f2c6527eb33.p12
   Please, deposit into EmerCoin NVS pair:
   Key: ssl:84aa5f2c6527eb33
   Value: sha256=52cfd176a00756646fc73b6eecdf53c4d51cd077cc9b4ea49dd9bf660337fb52
   
   Первая строка сообщает имя свежесгенерированного *.p12 файла. Вы его будете загружать в браузер в п 4. Далее – напечатана пара “key->value” (выделено жирным) для загрузки в NVS-подсистему EmerCoin. Важно: Пара “key->value” печатается только один раз, никуда не сохраняется. Нужно использовать её «с экрана». Если же она всё-таки оказалась утеряна – ничего страшного, просто сгенерируйте новый сертификат из того же самого шаблона, и будет у Вас новая пара.
   
   В дальнейшем, из свежесгенерированых файлов будет использоваться только файл *.p12. Файл собственно сертификата, *.crt – оставлен только «для справки». Его можно просмотреть в текстовом редакторе и взглянуть на структуру и атрибуты сертификата. При желании, файл *.crt можно удалить.
   
3. Загрузка пары в EmerCoin NVS.
   Используя графический интерфейс кошелька EmerCoin или команду name_new (в случае замены сертификата – name_update) командной строки emercoind, загрузите в NVS указанную выше пару. Подождите нескольких подтверждений блока (хотя одного подтверждения обычно достаточно) – это примерно 5-15минут. Как только подтверждение появилось – поздравляем! Вы успешно зарегистрировали свой сертификат в распределённой системе emcssl, и можете переходить к завершающему этапу. В крайне маловероятном случае возникновения коллизии (её вероятность ниже выигрыша миллиона в лотерею), когда NVS не принимает Вашу пару из-за того, что такой ключ уже зарегистрирован – повторите пункты 1-3 снова, тем самым сгенерировав сертификат с другим серийным номером.
   
4. Загрузка пакета *.p12 в браузер и использование.
   Теперь, после успешной регистрации сертификата в EmerCoin NVS, можно загрузить файл *.p12 в браузер и начать использовать все преимущества системы emcssl. Загрузка наших пакетов ничем не отличается от загрузки обычных клиентских SSL-сертификатов, и делается через соответствующие меню настройки того или иного браузера. Примеры руководств для конкретных браузеров:
   Firefox: www.onlinehowto.net/install-ssl-certificate-in-firefox/784
   Chrome: www.binarytides.com/client-side-ssl-certificates-firefox-chrome
   IE: ipswitchmsg.force.com/kb/articles/FAQ/Using-client-SSL-certificates-in-Internet-Explorer-1307739573570
   
   В общем случае, нужно пойти в настройки, и найти там пункты типа Advanced/Security/Certificates, после чего нажать кнопку Import, и загрузить Ваш *.p12 файл. В процессе импортирования нужно будет ввести пароль, которым Вы в п.2 защищали пакет. После загрузки сертификата некоторые браузеры (например Google Chrome) нуждаются в рестарте.
   

Итак, работа сделана, теперь остаётся получать награду за неё – то есть без паролей безопасно ходить на сайты, и при необходимости – автоматически создавать там учётные записи на основе сертификатов. Рассмотрим подробнее, как это работает.

1. Когда Вы из браузера с наличествующем в нём сертификатом идёте на сайт-участник системы, сайт требует браузер предъявить сертификат клиента. Если у клиента нет сертификата, или он отказывается его предъявлять, то сервер, в зависимости от его настроек, либо переходит на парольную схему аутентификации, либо отказывается работать далее. Мы же предполагаем, что сертификат есть, и браузер готов его предъявить по требованию сервера. При самом первом посещении сайта браузер спросит Вас «тут сертификат просят, подходят такие-то из хранилища, какой будем показывать?». Вы выбираете сертификат, и браузер у себя запоминает, что на этот сервер надо ходить с таким-то сертификатом, и более этого вопроса не задаёт. Также в браузере можно установить режим авто-выбора, но мы этого делать не рекомендуем.
2. Сервер, получив сертификат, вначале проверяет подпись сертификата. Успешная проверка подписи доказывает, что сертификат был сгенерирован для системы EMCSSL, и не более того. Здесь имеется расхождение с классическим применением сертификата, где подпись удостоверяет и значения других полей сертификата. В нашем случае, подпись удостоверяет только то, что сертификат сгенерирован для этой системы, и не более. Остальные проверки будут сделаны далее.
3. Сервер генерирует случайное число, шифрует его на публичном ключе, находящемся в предъявленном сертификате, и отправляет Вашему браузеру. Это будет одноразовый пароль этого (и только этого) соединения.
4. Браузер, имея в себе полный файл *.p12, извлекает из него секретный ключ, и расшифровывает пароль, посланный сервером. После этого браузер устанавливает безопасное https-соединение с сервером. Факт установления такого соединения доказывает серверу, что браузер владеет не только предъявленным сертификатом, но и соответствующим ему секретным ключом, то есть доказывает, что предъявитель сертификата владеет полным *.p12 файлом. Заметим, что в этой системе секретный ключ никогда не покидает Вашего компьютера. Вы его локально генерируете, и локально используете в браузере. Таким образом, даже если Ваш сертификат будет украден недобросовестным сервером, или перехвачен при передаче по сети, то использовать его никто кроме Вас всё равно не сможет, так как у злоумышленника не будет ответной части – секретного ключа.
5. Сервер, убедившись в том, что клиент владеет корректным секретным ключом, производит проверку информации сертификата через EmerCoin блокчейн. Для этого он извлекает из сертификата серийный номер, и выполняет в EMC NVS поиск по этому серийному номеру, получая то, что Вы загружали в поле Value – контрольную сумму сертификата. После этого сервер вычисляет контрольную сумму только что полученного сертификата и убеждается в том, что предъявленный сертификат с соответствующим серийным номером – то же самый, который участвовал в регистрации пары в NVS. Иными словами, сервер удостоверяется, что клиент, сертификат которого содержит номер N – этот тот же самый клиент, который и ранее приходил с этим же номером – с момента регистрации номера в NVS. Таким образом, верифицируется уникальный серийный номер сертификата, который и можно будет использовать для авторизации пользователя. Действительно, если злоумышленник сгенерирует другой сертификат с тем же серийным номером что и Ваш, то он не сможет загрузить контрольную сумму в NVS, так как она уже занята Вами. А если он сгенерирует сертификат с другим серийным номером – то это будет уже другой ID, и для него сервер создаст другую учётную запись.

После всех этих проверок (которые в реальности происходят в доли секунды), сервер удостоверяется в том, что пришедший клиент:

• Имеет сертификат нашей системы, а не что попало.
• Владеет секретным ключом.
• Владеет соответствующим серийным номером сертификата.

И даёт вам доступ к вашей учётной записи.

Заметим, что в данной системе верифицируется только серийный номер сертификата, который и является Вашим UserID. При генерации последующих сертификатов, Вы можете отредактировать файл *.tpl, и внести туда другие значения полей CN/Email/UID, после чего сгенерировать новый сертификат, заменить его в браузере и соответственно изменить контрольную сумму в соответствующей записи в NVS. После этого старый сертификат станет бесполезным, так как перестанет проходить проверку п.5.

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

Сервер может извлечь из вашего сертификата поля CN (имя пользователя) и Email, и мгновенно заполнить минимальные значения полей вашего профиля при его создании. Кроме того, сертификат может содержать значение в поле UID (может отсутствовать). Это значение представляет собою ссылку на infocard — дополнительную информацию, которую Вы желаете о себе предоставить. Информация также хранится в NVS, но зашифрована и недоступна для всех желающих. Поле UID содержит в себе также и ключ дешифрования для infocard. Таким образом, доступ к содержащейся в infocard информации может получить только сервер, которому Вы предъявили соответствующий сертификат.

Объединённые возможности infocard и emcssl открывает возможность создания детальной и полной учётной записи просто по клику – без ввода нового пароля, заполнения информации о себе, верификации email, и прочего. Клик – и готово!
Также в связи с расширенными возможностями EmerCoin, в нём существует интересная возможность отправления платежа на имя из NVS. Таким образом, возникает возможность получения безопасного платежа. Сервер, используя этот механизм, гарантировано посылает платёж только владельцу сертификата, и никому иному. Таким образом, даже в случае взлома Вашей учётной записи, невозможно заменить в ней адрес и вывести средства куда-то помимо Вашего кошелька. Мы считаем, что использование этой возможности поднимет безопасность бирж и пулов.

F.A.Q. Частые вопросы и ответы на них.

— А можно ли один и тот же *.p12 файл загрузить в несколько браузеров? А на разных компьютерах?
— Да, можно!

— А если у меня украли ноутбук или планшет, на котором был браузер с установленным сертификатом?
— Тогда Вам нужно как можно более быстро сгенерировать новый сертификат, и загрузить его цифровую подпись в EmerCoin NVS. Этот шаг автоматически сделает похищенный сертификат недействительным. К счастью, в этом случае нужно заменить только один сертификат, а не десятки их.

— А каким ещё способом можно защитить сертификат от неавторизованного использования?
— Нужно на компьютер или планшет ставить пароль, чтоб злоумышленник даже после похищения компьютера не мог сразу добраться до Вашего браузера и начать делать всякое. Кроме того, некоторые браузеры (например Firefox) позволяют в настройках установить опцию, что нужно вводить пароль на сертификат (который Вы вводили при генерации пакета *.p12) каждый раз при использовании сертификата. Насколько это практично – решать Вам. Также существует возможность хранения сертификатов в аппаратных криптографических устройствах формата PKCS#11 (http://en.wikipedia.org/wiki/PKCS_11), но к сожалению, далеко не все браузеры поддерживают такие устройства. В любом случае, это больше проблема браузера и вашего контроля над компьютером, а не сетевого соединения.

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

— А почему именно EmerCoin? Можно ли использовать блокчейны других криптовалют?
— Можно. Если эти криптовалюты имеют распределённое хранилище общего назначения с открытым интерфейсом, подобное EmerCoin NVS. Подавляющее большинство криптовалют не имеют ничего подобного. А хранилища тех, что имеют (Namecoin, NXT) — имеют ряд ограничений, снижающих либо функциональность, либо безопасность системы.

— А где-либо эта система уже эксплуатируется? Посмотреть можно?
— Да, можно! Эта система, как один из механизмов авторизации, используется на основном пуле EmerCoin: pool.emercoin.com

— Как получить доступ к EmerCoin NVS сервису?
— Нужно скачать бесплатно кошелёк EmerCoin wallet c sourceforge.net/projects/emercoin/files, приобрести каким-то образом небольшое количество Эмеркоинов, и загружать Ваши подписи в распределённую базу.

— И сколько стоит загрузка подписи?
— Зависит от ряда факторов, но можно ориентироваться на сумму ? EMC на загрузку одной пары. При текущем курсе 1EMC = 0.02USD, мы считаем цену в половину цента за 5 лет (срок жизни сертификата) вполне доступной кому угодно, даже жителям беднейших стран.

— А почему бы это не сделать вообще бесплатным?
— Оплата услуг NVS введена как средство защиты блокчейна от злонамеренного заполнения «мусорной информацией». Эта сумма вполне приемлема для кого угодно, но не для желающего раздуть блокчейн на десятки гигабайт.

— И где можно приобрести EMCs?
— Вы можете купить или получить их иным способом у какого-либо владельца, на или намайнить на пуле pool.emercoin.com, или получить как оплату за помощь мировой науке в проекте folding@home: emerfor.org/folding_home/about_en.php
Если Вы решите купить, Вы можете это сделать на бирже www.livecoin.net
Или обратитесь на форумы, где Вам помогут:
Русскоязычный forum.bits.media/index.php?/topic/3408-emc-emercoin-pos
Англоязычный bitcointalk.org/index.php?topic=362513.0
Также Вы можете написать приватный запрос на team@emercoin.com

— И куда деваются EMCs, потраченные на загрузку пары? Небось в кошелёк к авторам?
— Сгорают. Иначе говоря, навсегда удаляются из оборота, то есть не достаются никому.

— Хорошо. На какой срок лучше всего регистрировать пару?
— Мы рекомендуем срок регистрации 6-10 лет, или более. При update value срок не «сгорает», и новый срок жизни добавляется к остатку старого. В этом случае, вначале истечёт сертификат, и сайты перестанут его принимать. И только через 1-5 лет истечёт срок действия записи в NVS. Мы считаем, что этого времени вполне достаточно для генерации нового сертификата и обновления записи. Такой подход позволит исключить ситуацию, когда злоумышленник после истечения NVS-записи зарегистрирует свой сертификат с тем же серийным номером, и получит доступ к учётным записям предыдущего владельца серийного номера. Здесь прямая аналогия с доменными именами – если имя вовремя не продлять, то оно истечёт и его сможет захватить кто-либо другой. К счастью, здесь предложен простой рецепт, как избежать подобной ситуации.

InfoCard

InfoCard – формат данных, посредством которых люди или организации могут добровольно сообщить о себе некоторые персональные или корпоративные данные. Её предназначение структура чем-то напоминает визитную карточку (бумажную, или электронную *.vcf), или же запись о пользователе в LDAP-справочнике.

InfoCard – отдельный продукт, использующий NVS-подсистему EmerCoin, и вообще говоря, может быть самодостаточным. Однако настоящую ценность он приобретает при совместном использовании c сертификатами emcssl, поле UID которых содержит ссылку на infocard (UID). При этом сервер по получению сертификата может извлечь infocard пользователя, и использовать информацию из infocard для заполнения профиля пользователя на сайте, или же контакта с ним на основании информации, содержащейся в infocard, включая платежи в криптовалюте на указанный в infocard адрес.

Здесь мы видим аналогию с системой OpenID, в которой пользователь может авторизовать сайт воспользоваться профилем на каком-либо другом известном сайте, например facebook. Однако, в отличие от OpenID, система infocard децентрализована, и не зависит от работоспособности того или иного сервера, а также его поведения. Например можно предположить гипотетическую ситуацию, когда facebook по своим соображениям удалил или заблокировал Вашу учётную запись, и Вы более не имеете возможности писать на десятках форумов, в которые ранее заходите через facebook OpenID.

Кроме того, в отличие от систем хранения дополнительной информации OpenID, LDAP, vCard, в которых запись (карточка) содержит всю информацию о человеке (или должности), запись infocard позволяет импортировать часть информации из других записей, уже содержащихся в системе. Это становится удобным для работников организаций или других иерархических структур.

Например, в infocard-системе может содержаться запись об организации (для определённости — компании), в которой включено название компании, адрес, телефон и прочие атрибуты. А infocard-записи работников содержат директиву импорта этой общей информации в визитную карточку работника. Тогда, если, например, в компании сменился номер телефона, или офис переехал на другой адрес, или компания слилась с другой и поменяла имя – все эти изменения будут внесены в единственную infocard-запись о компании, после чего карты других работников, импортирующих эту информацию, автоматически обновятся и будут содержать актуальную информацию. А теперь вспомните, сколько раз Вам вручали визитки, в которых от руки зачёркнут номер телефона и вписан другой. То-то же!

Ссылка на infocard-запись имеет следующий вид:
info:infocard_key:infocard_password

• info – префикс сервиса в системе NVS
• infocard_key – ключ для поиска карты в NVS
• infocard_password – пароль расшифровки этой карты

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

Рассмотрим подробнее пример инфокарты (номера строк в реальной инфокарте отсутствуют):

1 Alias superabdul # Short name (username, login)
2 FirstName Abdul # First (short) name
3 LastName AbstulZadomBey # Remain part of full name
4 HomeAddress
5 Sinan Pasa Mah. Hayrettin Iskelesi # Free form address
6 Sok. No \#1 # Free form address
7 Besiktas, Besiktas # Free form address
8 Istanbul # City
9 34353 # ZIP code
10 Turkey # Country
11 HomePhone +90-555-123-4567
12 WorkPhone +90-555-123-4568
13 CellPhone +90-555-123-4569
14 Gender M
15 Birthdate 27.05.91 # May, 27, 1991
16 Email abdul@bubbleinflators.com
17 WEB bubbleinflators.com/superabdul
18 Facebook Abdul.AbstulZadomBey
19 Twitter AbdulAbstulZadomBey
20 EMC EdvJ7b7zPL6gj5f8VNfX6zmVcftb35sKX2 # EmerCoin payment address
21 BTC 1MkKuU78bikC2ACLspofQZnNb6Vz9AP1Np # BitCoin payment address

Каждая запись представляет собою множество (в математическом смысле) пар:
Key (один или более пробелов) value
Value – может содержать в себе пробелы.

Пример:
Alias superabdul # Short name (username, login)

После обработки карты key может иметь несколько values, внесённых в общий список для данного key. Чтобы добавить values к нужному key, их надо ввести в строках, начинающихся с пробела, то есть не имеющих своего key. Примером является HomeAddress в строках 4-10.
Символы “#” и то что правее являются комментарием, и удаляются при чтении карты. Если нужно ввести символ “#” внутрь строки-значения, надо перед ним поставить экранирующий символ “\”, как это сделано в строке 6 примера.
Импортировать содержимое другой infocard можно командой Import наподобие:

Import info:2f2c5a7c57d60668:74744c6e4443df490eab0807052bb9

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

HomePhone +90-555-123-4567
HomePhone +90-555-123-0000

Создаст единственное значение для HomePhone — +90-555-123-0000. Предыдущее значение будет перезаписано.

Чтобы иметь возможность корректно объединять значения из импортируемых карт и свои, введены квалификаторы для key. Это знаки “+” перед или после key. Плюс перед key означает «добавить данное value в хвост списка», после key — «добавить данное value в голову списка». Без квалификаторов – удалить список для данного значения, и ввести текущее, если имеется. Примеры ниже демонстрируют эти варианты:

HomePhone +90-555-123-4567
+HomePhone +90-555-123-0000
Результат: HomePhone ->[+90-555-123-4567] [+90-555-123-0000]

HomePhone +90-555-123-4567
HomePhone+ +90-555-123-0000
Результат: HomePhone -> [+90-555-123-0000] [+90-555-123-4567]

HomePhone +90-555-123-4567
HomePhone
Результат: HomePhone ->[] (пустой список)

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

Резюме

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

Также можно указать на механизм проверки безопасности, подобный применённому в Kerberos, где клиент получает у Kerberos сервера “жетон авторизации”, а собственно сервер услуг по жетону запрашивает у Kerberos решение, что делать с этим клиентом. В нашем случае, вместо централизованного сервера используется децентрализованный EmerCoin NVS, а в качестве уникального жетона выступает успешно зарегистрованный в NVS серийный номер сертификата. Серверы услуг также вместо запроса к центральному серверу Kerberos верифицируют клиента в локальной копии NVS, посредством запросов в локальный EmerCoin wallet.

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

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

Всё программное обеспечение распространяется бесплатно. Пакет генерации клиентских сертификатов находится тут: pool.emercoin.com/emcssl
Здесь же можно проверить работу вашего сертификата на тестовой страничке, а также скачать полное содержимое этого простого сервера с примером тестовой страницы на PHP, и на основе кода, содержащегося в примере, добавить авторизацию emcssl в ваш сервер.