openPGP в России / Библиотека / Статьи / Управление идентификацией посредством PGP

==Управление идентификацией посредством PGP:---Безопасная аутентификация и авторизация через Интернет==

====Введение====

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

====После паролей====

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

* Реализация концепции единоразовой аутентификации, при которой пользователям достаточно помнить всего один пароль, который, в то же время, менее подвержен попыткам взлома.
  * Применение стойкой аутентификации пользователя, расширяемой до многофакторных методов при помощи токенов и смарт-карт. Единственная копия аутентифицирующего (тайного) материала хранится у пользователя.
  * Разработка такой системы, которая не зависит от каких бы то ни было доверенных серверов, так что компрометация любого из них не затронет защиту других пользователей и серверов.
  * Построение на основе существующей широко распространенной инфраструктуры, которая может масштабироваться до очень большого числа пользователей и серверов.
  * Использование методов, которые позволят пользователям безопасно подключаться к сетям нескольких предприятий и осуществлять сделки.

====Аутентификация с криптографическими подписями====

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

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

Поскольку владелец секретного ключа – единственное лицо, которое может создать цифровую подпись, сверяемую соотвествующим открытым ключом, возникает прочная связь между личностью пользователя и способностью создавать подписи конкретным личным ключом. Таким образом, цифровая подпись становится надежным доказательством аутентичности отправителя.

====Криптографический запрос-ответ====

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

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

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

====PGPuam – подтверждение идеи====

Система логина с открытыми ключами первоначально была представлена автором статьи в виде прототипа PGPuam и позднее распространена в виде демонстрационного кода на Apple Computer в 1998 г. (//V. Moscaritolo, [[http://www.vmeng.com/mc/cfp1998.html "PGPuam – Public Key Authentication for AppleShare-IP"]]//). Состоящая из клиента AppleShare-IP и плагина к серверу, эта система позволяла пользователю осуществлять надежно защищенную двусторонне-аутентифицируемую процедуру подключения к серверу AppleShare-IP через клиента MacOS. Криптографическое ядро было представлено библиотекой PGP Software Development Kit (PGP SDK), распространявшейся в комплекте PGP 6.0. Пользовательский интерфейс являлся дополнением готового интерфейса логина AppleShare.

Хотя концепт-версия PGPuam была полностью функциональной, она не задумывалась в качестве рабочей программы. Скорее она должна была послужить практической демонстрацией того, почему криптография с открытым ключом должна рассматриваться как один из центральных компонентов операционной системы. К сожалению, в конце девяностых криптография увязла в коммерческих и политических ограничениях, и широкое распространение инфраструктур открытых ключей (PKI) закреплялось слишком медленно. Тем не менее, PGPuam успешно показал, что криптография может применяться не только для шифрования электронной почты. (Обратите внимание, что AppleShare-IP оказался всего лишь удобной тестовой платформой. Эта концепция может быть легко перенесена на любые файл-серверы, которые поддерживают подключаемые модули аутентификации, такие как модули Apache или Windows GINA Authentication DLL.)

====Аутентификация против авторизации====

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

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

Хотя было множество попыток создать автоматизированные системы с синхронизирующимися или централизованными базами авторизации, типа Kerberos, все они по-видимому имеют следующие недостатки:

* Сам сервер авторизации должен быть физически защищен, ибо являет собой критическое звено в цепи безопасности.
  * Каждый сервер должен поддерживать связь с сервером авторизации, дабы устанавливать личность и авторизацию каждого пользователя. Это может оказаться непрактичным требованием для удаленных объектов или устройств, вроде кард-ридеров дверных замков.
  * Сервер авторизации становится идеальной мишенью для атак на "отказ в обслуживании" (DoS), поскольку это скажется на всех остальных серверах системы, связанных с ним.

====PGPticket – объединенная безопасная авторизация пользователей====

В ряде работ были рассмотрены весьма удачные схемы распределенных систем сетевой авторизации (//M. Blaze, J. Feigenbaum, J. Lacy, [[http://www.crypto.com/papers/policymaker.pdf "Decentralized Trust Management"]]. C. Ellison, [[http://www.ietf.org/rfc/rfc2692.txt "SPKI Requirements"]]//). В частности, модель Простой инфраструктуры открытых ключей (SPKI) вносит изменения в представление о том, как может проходить авторизация в сетевых службах. Вместо того, чтобы вести на каждом сервере базы данных с именами пользователей, паролями и соответствующими правами допуска, можно применить технологию цифровых подписей для создания сертификата авторизации. Можете представить этот сертификат как цифровой пропуск, действительный только для конкретного ключа пользователя и в течении определенного срока. Сертификат авторизации подписывается организацией или полномочным лицом, владеющим сервером, а пользователь предоставляет его при необходимости доступа в зону с ограниченным допуском.

Один из способов формирования такого сертификата – это отдельный пакет подписи формата OpenPGP (//J. Callas, L. Donnerhacke, H. Finney, R. Thayer, [[http://www.ietf.org/rfc/rfc2440.txt "OpenPGP Message Format]]//). Эти пакеты, называемые PGP-билетами (PGPticket), создают основу простого, но очень надежного протокола объединенной авторизации (//V. Moscaritolo, [[http://www.vmeng.com/mc/cfp1998.html "PGPticket – A Secure Authorization Protocol"]]. V. Moscaritolo, A. Mione, [[http://www.pgp.com/resources/ctocorner/draft-ietf-pgpticket-moscaritolo-mione-02.txt draft-ietf-pgpticket-moscaritolo-mione-02.txt]]//). Каждый PGPticket содержит следующие поля:

* ##ПОСТАВЩИК##, представленный ID-номером ключа PGP, – он генерирует и заверяет сертификат.
  * ##СУБЪЕКТ## – лицо или группа лиц, получающие авторизацию по данному сертификату. Для представления субъекта используется комбинация из ID ключа, алгоритма и отпечатка ключа.
  * ##СРОК ДЕЙСТВИЯ## – некоторая комбинация дат или онлайновых проверок, определяющих период / условия действительности сертификата – обычно это дата создания и дата окончания действия. Например, это поле может быть полезно для школы, которая хочет дать доступ к средствам, но с условием ограниченного периода.
  * ##АВТОРИЗАЦИЯ## – структурированное поле, описывающее ту авторизацию, которую данный сертификат предоставляет субъекту. Эти данные могут представлены как SAML или некоторая форма XML.
  * ##ДЕЛЕГИРОВАНИЕ## – отметка, которая указывает, имеет ли право данный субъект передавать свою авторизацию дальше.

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

Процесс доступа к службе по PGPticket проходит следующим образом:

1. Пользователь запрашивает доступ к серверу от системного администратора (поставщика). Пользователь предоставляет копию своего открытого ключа или публикует его в общественном депозитарии ключей. Поставщик проверяет подлинность этого ключа.
  2. Администратор генерирует PGPticket с соотвествующими данными авторизации и срока службы и подписывает билет ключом админа сервера. Билет либо публикуется на сервере, либо отправляется пользователю по электронной почте.
  3. Пользователь получает PGPticket и сохраняет его в локальной базе билетов.
  4. Когда пользователь пытается получить доступ к сетевому сервису, программа-клиент находит в базе необходимый билет и посылает серверу его копию вместе с запросом доступа.
  5. Сервер проверяет действительность билета, сверяя подпись администратора и срок действия билета. Затем сервер генерирует случайную строку запроса и посылает этот запрос клиенту, требуя подписать ее ключом, указанным в поле ##СУБЪЕКТ## данного билета.
  6. Подписанный клиентом запрос возвращается обратно, проверяется сервером, который, в случае успеха, предоставляет пользователю доступ в соответствии с авторизацией, указанной в билете.

Серверу требуется только копия открытого ключа корневого поставщика. Отпадает потребность в хранении копий публичных ключей субъектов, поскольку отпечаток нужного ключа вписан в само тело билета. Публичный ключ субъекта можно получить путем запроса от клиента и кэшировать для дальнейшего использования. То же касается и делегированных билетов. Отсутствует необходимость в особом удостоверяющем центре, хотя его наличие никак не ограничено; наоборот, УЦ сделает PGPticket'ы пригодными как для маленьких сайтов, так и для больших предприятий.

Одна из наиболее интересных особенностей такой архитектуры состоит в том, что серверы служб могут функционировать без доступа к серверам ключей, не зависеть от внешних воздействий и быть устойчивыми к DoS-атакам. Этот подход позволяет использовать PGPticket'ы в автономных устройствах, использование сетевых соединений в которых неприемлемо, что открывает широкий простор для интересных возможностей. Например, можно перенести PGPticket в аппаратный брелок или устройство Bluetooth и использовать его не только для таких обычных вещей, как доступ к веб-сервисам или к VPN, но также и для доступа в помещения с ограниченным допуском. По сути, PGPticket сможет расширить применимость инфраструктуры ключей PGP и в физический мир.

====PGPcoupon – построение на XML веб-сервисах====

Другие интересные варианты возникают, когда вы нестандартно совмещаете PGPticket с гибкостью инфраструктуры ключей PGP. Представьте себе систему, которая автоматически "печатает" билеты посредством некоего платного сервиса, и объедините это с анонимными ключами. А как насчет использования для создания билетов разделенных ключей, которые должны быть соединены из некоторого количества долей для доступа к сервису?

Другая возможность – это смешение технологий PGPticket и XML объектов веб-сервисов. Клиент мог бы опубликовать веб-запрос на конкретное предложение, после чего продавцы могли бы отвечать ему PGP-подписанным купоном, который будет приниматься к оплате различными дистрибьютерами в течении указанного срока.

Представьте, например, что школа хочет закупить ряд книг; различные конкурирующие продавцы посылают ответы на заказ, стараясь предложить клиенту более выгодные условия. В каких-то ответах содержится PGP-купон на 20-процентную скидку, принимаемый к оплате в Amazon или BN.com. Клиент тогда мог бы в процессе покупки предоставить этот купон, который система обработает в автоматическом режиме.

====Заключение====

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

>>>++Винни Москаритоло, инженер-криптограф PGP Corporation---Перевод (c) 2004 ((username:unknown unknown)), ((username:sattva SATtva))++>>>
===Комментарий===

Вообще-то ничего принципиально нового в этой статье нет. Схемы беспарольной аутентификации проектируются очень давно, и здесь просто предлагается наиболее выгодный вариант для компании PGP Corporation. Если бы им удалось распространить именно свой вариант в качестве стандарта, то они бы получили большой рынок заказов (и возможно еще патентные отчисления) – выпускали бы новые стандарты для аутентификации дверных замков, для поддержания серверов ключей и т.д. Возможно, другие компании такая перспектива не устраивает и они предлагают иные решения, а аргументы в пользу широкой распространенности PGP-подобных систем их не останавливают в попытках изобрести и внедрить что-то свое.

Если посмотреть на алгоритмы, используемые в платежных смарт-картах, то там используются чаще специальные протоколы аутентификации (наподобие Фейге-Фиата-Шамира) или вообще симметричная криптография (обмен хэшированными запросами), а никак не электронные подписи PGP, даже если эти схемы заведомо менее стойкие.

Вот здесь и проясняются те экономические и политические причины, которые якобы мешают доминированию PGP-стандарта. Еще в восьмидесятые годы возникла идея об использовании //((ЧтоТакоеЛичностнаяКриптография Identity Based Cryptosystems))// (IBC). И сравнительно недавно (с 2001 г.) стали появляться практические схемы. Если Алиса хочет послать письмо Бобу (участнику IBC), то ей не надо получать открытый ключ Боба и проверять его подлинность – она сама может его рассчитать по его почтовому адресу или другой принятой информации. Если все участники системы будут менять ключи раз в год, то открытый ключ Боба будет например ##bob@bobserver.com||2004##.

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

Перед этим, конечно, Боб должен раз в год явиться в Центр Распределения Ключей. Там работает человек по имени Трент, который проверит личность Боба, сгенерирует ему закрытый ключ, не оставляя при этом копии для себя. Конечно, Трент может тайно депонировать ключи, подделывать и читать сообщения Алисы и Боба, но скорее всего это мало кого будет волновать. Эта система и не предназначена для хранения личной тайны – те, кто хотят, могут создать собственные системы или подсистемы, выпускать собственные сертификаты для своих организаций и т.д. Никого ведь не волнует, что правительство может подделать те же паспорта, которые оно выдает своим гражданам, или подделывать собственные деньги, которые оно же и выпускает, – это было бы слишком абсурдно. Да и будет ли ему интересно расшифровывать чужие налоговые декларации, если оно само и является их получателем (оплата налогов по Интернету). Так же мало кого интересует всерьез утечка личной информации при пользовании кредитными карточками и мобильными телефонами.

Что-то никто почти не отказывается от их использования и не выражает бурных протестов.

Так что вполне возможно, что крупным корпорациям, производителям операционных систем, правительственным организациям больше понравится централизованно управляемая криптосистема, из которой можно легко "выкинуть" неугодного пользователя или проследить за ним лишний раз. А слишком независимая система, основанная на PGP, так и не будет широко распространена в физическом мире, чтобы управлять всем сразу – от доступа к дверным замкам до финансовых счетов. Косвенным подтверждением этому может служить и тот факт, что разработки систем IBC, ведущиеся в крупных научных институтах, финансируются в Америке организацией оборонных исследований DARPA.

Ваше имя:
	Запомнить псевдоним (сохранить в cookie)
	OpenPGP-подписанный текст в кодировке Помощь
	Сохранить параметры OpenPGP в cookie

Для корректной работы разрешите в своем браузере показ изображений.

Пожалуйста, напишите, кого/что вы видите
на изображенной слева картинке. Если
там несколько персонажей/предметов,
перечислите их в именительном падеже
через пробел (одинаковых приводите во
множественном числе).

(осталось попыток на решение теста: 3)

Поддержка BBCode включена