Kerberos

Общая схема работы

Для протокола Kerberos, также как и для RADIUS существует несколько RFC, отражающие различные аспекты использования протокола (RFC-1964, RFC-2623, RFC-2712, RFC-2942). Однако существует немало весьма подробных разъяснений функционирования протокола, в том числе и на русском языке.

Протокол предназначен для аутентификации субъекта объектом (и наоборот), например сервера клиентом, в случае когда среда передачи данных открыта, а объект изначально ничего не знает о субъекте и не имеет с ним общего секрета, но оба (и субъект, и объект) предварительно идентифицированы третьей стороной — доверенным сервером и имеют с ним общие секреты (никогда не передаваемые по сети). Требование наличия такого секрета и определяет схему защиты протокола — симметричными криптографическими алгоритмами (DES). Согласно принятой терминологии субъект и объект называются принципалами (англ. principals), а доверенный сервер называют центром распределения ключей -ЦРК (англ. Key Distribution Center — KDС).

Поскольку ЦРК обеспечивает серьезную работу по аутентификации в распределенной сети, в том числе хранит ключи аутентифицируемых субъектов и объектов, к нему выдвигаются повышенные требования по безопасности (по аналогии с межсетевым экраном):

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

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

Протокол не защищает от атак класса "Отказ в обслуживании".
Принципалы должны сохранять в тайне свои секреты - протокол не обеспечивает защиты в случае утери секрета.
Протокол не защищает от атак типа "Разгадывание пароля": выбор надежного пароля, который служит секретом или на котором строится секрет, оставляется на усмотрение принципалов.
Системные часы всех участников аутентификационного процесса должны быть синхронизированы, обеспечение безопасности синхронизации отнесено к функциям дополнительного протокола синхронизации.
Новые принципалы не должны наследовать идентификаторы старых, удаленных из системы (сети), иначе они могут унаследовать и их права доступа.

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

доверенный сервер генерирует некий сессионный ключ;
шифрует сессионный ключ ключом клиента и отправляет клиенту;
шифрует сессионный ключ ключом сервера и отправляет серверу.

Теперь клиент и сервер обладают единым сессионным ключом, который, с одной стороны, позволяет им доверять друг другу (так как оба они доверяют серверу, предоставившему сессионный ключ), с другой стороны, позволяет построить защищенное соединение для обмена данными (рис. 22.18).

Рис. 22.18. Возможная схема работы

В принятой в протоколе Kerberos терминологии сессионный ключ с сопутствующими данными (наименование принципала, временной штамп и т. п.), зашифрованный ключом принципала, называется билетом (англ. ticket), или мандатом.

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

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

Рис. 22.19. Принципиальная схема Kerberos

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

В принятой в протоколе Kerberos терминологии билет для работы с доверенным сервером называется билетом на получение билетов (англ. ticket-granting-tickets — TGT), а билет для сервера ресурсов — билетом на получение сервиса (англ. ticket-granting-service — TGS). Все указанные билеты и связанные с ними ключи действительны только до срока истечения билета или до выхода клиента из сети. Они сохраняются только в оперативной памяти, в т. н. кэш-памяти билетов (англ. credentials cache) и удаляются по истечении срока или окончании работы клиента в сети. Таким образом, работа клиента складывается из следующих шагов, каждый из которых составляет отдельный подпротокол протокола Kerberos.

Регистрация в сети:

подпротокол "Обмен данными со службой аутентификация"

1. При первой регистрации клиента (пользователя) требуется ввод пароля, который преобразуется в ключ шифрования (стандартный метод преобразования - DES-CBC-MD5, но могут быть использованы и другие алгоритмы). Этот ключ, который считается постоянным или долговременным (до следующей смены пароля пользователем), сохраняется в кэш памяти.

2. Клиент формирует запрос на аутентификацию (KRB_AS_REQ-Kerberos uthentication Service Request), в который включаются идентификатор пользователя (для поиска его ключа), имя службы выдачи билетов, а также предварительные аутентификационные данные, которые могут предотвратить обращение злоумышленника за билетом от имени клиента (например, зашифрованная ключом клиента временная метка).

3. Клиент отсылает ЦРК запрос KRB_AS_REQ.

4. Доверенный сервер, получив запрос, ищет в своей базе соответствующий клиенту ключ и проверяет предварительные аутентификационные данные.

5. После успешной проверки ЦРК формирует сессионный ключ и готовит ответ на запрос клиента (KRB_AS_REP — Kerberos Authentication Service Reply), куда включает копию сессионного ключа, зашифрованного ключом клиента, и билет TGT, зашифрованный своим постоянным ключом, содержащий еще одну копию сессионного ключа для себя и авторизационные данные клиента.

6. Доверенный сервер отсылает клиенту ответ KRB_AS_REP.

7. Клиент, получив ответ, дешифрует сессионный ключ, сохраняет его и TGT-билет в кэш- памяти, откуда удаляет свой постоянный ключ. Теперь общаться с ЦРК он будет, используя сессионный ключ.

Получение права на доступ к серверу ресурсов:

подпротокол "Обмен билетами на получение сервиса"

1. Клиент решает поработать с сервером ресурсов. Для этого клиент формирует запрос KRBTGSREQ — Kerberos Ticket-Granting-Service Request, куда включаются имя пользователя и аутентификационные данные, зашифрованные сессионным ключом для ЦРК, билет TGT, на именование сервера ресурсов.

2. Клиент отсылает запрос KRB_TGS_REQ доверенному серверу.

3. ЦРК, получив запрос, извлекает с помощью своего постоянного ключа сессионный ключ из TGT, а с помощью этого сессионного ключа проверяет аутентификационные данные клиента.

4. ЦРК генерирует второй сессионный ключ для работы клиента и сервера ресурсов.

5. ЦРК формирует ответ KRB_TGS_REP — Kerberos Ticket-Granting-Service Reply, куда помещает новый сессионный ключ, зашифрованный сессионным ключом клиента, и TGS, который состоит из того же нового сессионного ключа, а также данные о клиенте, необходимые для авторизации его на сервере ресурсов, — все это зашифровано постоянным ключом сервера ресурсов.

6. Доверенный сервер отсылает ответ KRB_TGS_REP клиенту.

7. Клиент, получив ответ, с помощью своего сессионного ключа извлекает новый сессионный ключ для работы с сервером ресурсов и сохраняет его в кэш-памяти вместе с TGS для сервера ресурсов. Теперь у клиента есть сессионный ключ и TGT для доверенного сервера и сессионный ключ и TGS для сервера ресурсов.

Использование сервера ресурсов:

подпротокол "Обмен данными между клиентом и сервером"

1. Клиент формирует запрос KRB_AP_REQ — Kerberos Application Request, в который он включает свои аутентификационные данные, зашифрованные сессионным ключом для работы с сервером ресурсов, TGS для данного сервера, а также (опционально) требование произвести взаимную аутентификацию.

2. Клиент отправляет запрос KRBAPREQ серверу ресурсов.

3. Сервер ресурсов с помощью своего постоянного ключа извлекает авторизацонные данные для определения прав клиента и сессионный ключ для клиента из TGS, с помощью этого сеансового ключа дешифрует ау-тентификационные данные клиента и проверяет требование взаимной аутентификации. Если такое требование присутствует, он включает в ответ KRB_AP_REP (Kerberos Application Reply) временную метку, зашифрованную сессионным ключом для клиента.

4. Сервер отсылает ответ KRB_AP_REP клиенту.

5. Клиент, получив ответ (и проверив метку времени), убеждается в готовности сервера к работе (и его подлинности) и может начать работу с сервером. При этом данные могут шифроваться сессионным ключом, либо клиент и сервер могут договориться о другом ключе.

Характеристики протокола Kerberos

Одно из преимуществ протокола заключается в том, что клиент может быть аутентифицирован и получить доступ к серверу ресурсов вне своей области аутентификации — домена (англ. realm) — ЦРК2, при условии, что оба доверенных сервера ЦРК1 и ЦРК2, обслуживающих свои области, установили между собой доверительные отношения (определили общий ключ шифрования при пересылке данных между областями). В этом случае ЦРК2 выступает для клиента в качестве такого же сервера ресурсов, только удаленного и предоставляющего сервис трансляции запросов клиента подведомственным ему серверам ресурсов.

Более того, возможна ситуация, когда клиенту необходим ресурс из области, с которой у его ЦРК1 нет доверительных отношений, но ЦРК обеих областей имеют доверенные отношения с третьим ЦРКЗ. В этом случае клиент также может быть аутентифицирован на сервере вне своей области аутентификации (рис. 22.20).

Рис. 22.20. Схема работы с промежуточным доверенным сервером

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

Общий формат билета следующий.
1. Поле Tkt-VNo указывает номер версии протокола (текущая версия - 5).
2. Поле Realm указывает имя области, где создан билет, т. е.
Доверенного ЦРК.
3. Поле SName указывает имя сервера, для которого предназначен билет.
4. Первые три поля не шифрованы, остальные данные зашифрованы.
5. Поле Flags — флаги билета (рассматриваются далее в данном разделе).
6. Поле Key — сессионный ключ шифрования.
7. Поле CRealm — наименование области, где зарегистрирован клиент и
где происходит первичная аутентификация.
8. Поле CName — идентификатор самого клиента.
9. Поле Transited — наименование областей, которые принимали участие
в аутентификации клиента (не в порядке последовательности аутентификации).
10. Поле AuthTime — указывается время первоначальной аутентификации клиента из самого
первого билета текущей сессии работы клиента (пользователя).
11. Поле StartTime— время вступления билета в силу; если не указано, берется равным
предыдущему полю.
12. Поле EndTime — время окончания срока действия билета вместе с предыдущим полем
составляют срок жизни билета. Некоторые службы устанавливают свои ограничения по
времени и могут отвергнуть билет, который фактически не достиг срока истечения.
13. Поле ReNew-Till — используется совместно с флагом RENEWABLE из поля Flags,
определяет максимальное время, до которого билет может быть обновлен.
14. Поле CAddr — указываются адреса, с которых клиент может использовать данный билет.
Если поле пустое — билет можно использовать с любого адреса.
15. Поле Authorization-Data — данные о клиенте, которые могут быть использованы
системой, получившей билет для применения к клиенту авторизационных правил.

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

Ограничение срока действия билета используется протоколом как одно из средств защиты от компрометации сессионного ключа. В течение срока действия билета клиент может применять (предъявлять) его неограниченное число раз. По истечении срока действия клиенту необходимо получить новый билет, основная задача которого — использовать новый сгенерированный ЦРК сессионный ключ. При этом клиенту придется снова задействовать свой долговременный ключ, т. е. пользователю снова придется набирать свой пароль.

Однако возможен другой способ — регенерация ключей без переформирования всего билета целиком. В этом случае в билете указываются два срока действия— первый, это срок до регенерации текущего ключа, второй -срок действия всего билета с учетом производимых регенераций ключей. Теперь клиенту необходимо позаботиться о том, чтобы билет был представ- лен ЦРК до срока истечения возможного обновления, и в этом случае билет будет обновлен (будет сгенерирован новый сессионный ключ и указано новое время истечения обновления). Делегирование полномочий предусмотрено для случаев, когда клиент обращается к серверу ресурсов, который в свою очередь должен будет обратиться к другому серверу без непосредственного участия клиента. Для этого клиент должен передать свои права на аутентификацию первому серверу. Для этого существуют два способа: если клиент знает наименование второго сервера, он может запросить у ЦРК билет на доступ к этому серверу и пере- дать данный билет первому серверу — т. н. билет посредника (англ. proxy ticket); если клиент не знает наименования второго сервера, то он передает первому серверу свой TGT, который тот использует для запроса нового билета для доступа ко второму серверу — т. н. переадресованный билет (англ. forwarded ticket).

Рассмотрим подробнее поле Flags, учитывая новые возможности обновления и делегирования. Это 32-битовое поле, в котором присутствие флага указывается включением соответствующего бита поля из 0 в 1. Биты имеют следующие значения.

0	RESERVED — зарезервировано для будущего использования.
1	FORWARDABLE — флаг указывает службе формирования билетов, что на основании данного 
билета TGT можно выпустить новый с другим сетевым адресом, для передачи его серверу.
2	FORWARDED — флаг указывает, что данный билет переадресован или выпущен на основе 
переадресованного билета.
3	PROXIABLE — флаг указывает, что ЦРК может на основе данного билета генерировать 
билеты с другим сетевым адресом. 
4 PROXY — указывает, что сетевой адрес данного билета отличается от TGT, на основе 
которого он был выпущен.

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

5	 MAY-POSTDATE — удостоверяет, что на основе данного билета можно
       выпустить билет, который активизируется позже.
6	 POSTDATED — указывает,  что билет помечен как активизируемый позже.
7	 INVALID — подтверждает, что сервер ресурсов не должен рассматривать
       данный билет, он должен быть проверен ЦРК перед использованием.
8	 RENEWABLE — указывает, что билет может быть обновлен.
9	 INITIAL — показывает, что это билет TGT.
10	 PRE-AUTHENT — указывает, что клиент был предварительно
       аутентифицирован службой ЦРК перед выпуском билета.
11	 HW-AUTHENT — подтверждает, что для предварительной аутентификации
       клиенту потребовалось специальное аппаратное обеспечение.
12-31 - оставлены для будущего использования.

Secure European System for Aplications
in a Multivendor Environment

Европейскую Систему Безопасности Приложений в Смешанных Программных Средах (SESAME) в общем-то трудно назвать протоколом — это скорее модель или архитектура безопасности. Однако это название иногда упоминается рядом с Kerberos, мы решили рассмотреть его и будем называть схемой. Так как SESAME получил широкое распространение в основном только в Западной Европе, коснемся его только в общем виде.

Схема SESAME была предназначена для обеспечения безопасности при работе в незащищенной сети, например, таких известных своими уязвимостя-ми приложений, как Telnet, RLogin, RSh, RCP и RPC, и ставила своими целями обеспечение следующих задач.

1.	Аутентификация  (односторонняя или  взаимная)  с помощью  Kerberos
      или механизмов шифрования с открытым ключом.
2.	Обеспечение защиты данных при передаче.
3.	Создание ролевой модели  доступа (англ. Role-based access control — RBAC).
4.	Делегирование прав.
5.	Служба аудита.
6.	Мультидоменная поддержка.

Рассмотрим основные составляющие схемы (рис. 22.21).

Рис. 22.21. Компоненты SESAME

ПП — посредник (покровитель) пользователя (анг. User Sponsor) — предоставляет пользователю интерфейс к системе SESAME, предлагая пользователю функциональность для входа в систему (logon).

АПА — атрибут привилегий аутентификации (англ. Authentication Privilege Attribute) — используется ПП при связи с сервером безопасности домена.

СА — сервер аутентификации (англ. Authentication Server) -аналогичен схеме протокола Kerberos, обеспечивает единый вход в сеть (single sign-on).

САП — сервер атрибутов привилегий (англ. Privilege Attribute Server) — механизм управления доступом.

СРК — сервер распределения ключей (англ. Key Distribution Server) — аналогичен ЦРК протокола Kerberos, обеспечивает управление криптографическими ключами, но в отличие от Kerberos поддерживает аутентификацию на публичных ключах с помощью протокола Х.509. МКБО — менеджер контекста безопасного объединения (англ. Secure Association Context Manager) — обеспечивает защиту данных при обмене (аутентификацию и целостность данных, неотрекаемость или апеллируемость)

УПСАП — устройство проверки САП (сертификата атрибутов привелегий) (англ. Privilege Attribute Certificate Validation Facility) — производит проверку прав клиента на доступ к приложению на основе САП.

УПК — устройство поддержки криптографии (англ. Cryptographic Support Facility) — обеспечивает реализацию конкретных криптографических алгоритмов/протоколов.

УУПК — устройство управления публичными ключами (англ. Public Key Management Facility) — обеспечивает работу СРК при работе с публичными ключами.

УА — устройство аудита (англ. Audit Facility) — обеспечивает ведение детальных регистрационных журналов.

Дополнительные используемые термины схемы: инициатор (англ. initiator) — пользователь или приложение от имени пользователя или само по себе, обращающееся за ресурсом к приложению назначения (англ. target).

Рассмотрим основные характеристики схемы SESAME.

Обеспечение безопасности в открытой сети. Схема всегда обеспечивает целостность передаваемых данных и опционально — конфиденциальность (кроме тех случаев, когда конфиденциальность критически необходима — например, при пересылке ключей).
Аутентификация и единый вход в сеть. Схема позволяет аутентифицировать инициатора и назначение, а также обеспечивает возможность пользователю регистрироваться в сети только один раз, даже если ему нужен доступ к различным назначениям.
В схеме используется активная (англ. push), а не пассивная (англ. pull) аутентификационная технология. Две эти технологии отличаются характером передачи данных: в активной схеме инициатор сам отсылает свои аутентификационные данные по назначению, в пассивной - объект назчения запрашивает данные у инициатора.
Используется он-лайн, а не офф-лайн сервера безопасности. Наиболее яркий пример оффлайн сервера - это Уполномоченный по Сертификатам (УС) (англ. Certification Authority - СА). Подобный сервер выпускает сертификаты, которые далее могут быть сохранены, копированы и использованы без участия самого УС. Это накладывает определенные неудобства, когда в централизованной системе вся работа с аутентифи-кационными данными должна быть учтена. Поэтому в схеме SESAME используется интерактивный (он-лайн) запрос/получение аутентифика-ционных данных.
Могут быть использованы различные атрибуты привилегий. Поскольку схема использования аутентификационных данных жестко не закреплена, а лишь придерживается соответствующих стандартов и разработана специально для оборудования от различных поставщиков (англ. multivendor structure), для доступа к разнообразным назначениям могут быть использованы различные атрибуты привилегий.
В схеме различаются несколько видов идентифицируемости (англ. identity): для аутентификации, для доступа и для аудита.
Может использоваться политика ролей при управлении доступом (англ. role-based access control), т. е. администратор определяет атрибуты привилегий не отдельно для каждого пользователя, а для предопределенной группы пользователей, объединенных общей функциональностью для выполнения конкретных задач. В этом случае задачи по администрированию существенно упрощаются при перемещении пользователя в рамках организации, увольнении и т. п.
Использует пути доступа и делегирование. Пользователь (инициатор), обращаясь за конкретным ресурсом, может не знать, какое конкретно назначение им обладает. В этом случае аутентификационные данные инициатора передаются требующемуся назначению.

Secure-HTTP

Secure-HTTP (используются сокращения S-HTTP и SHTTP) текущая версия 1.2 — протокол, разработанный для обеспечения безопасности сообщений при использовании протокола HTTP и облегченной интеграции с приложениями, ориентированными на HTTP. В качестве ссылки на документацию протокола указывают рабочий документ IETF — draft-ietf-wts-shttp-02. Сохраняя все характеристики HTTP, протокол позволяет производить аутентификацию, шифрование, электронно-цифровую подпись сообщений в любой комбинации. При этом протокол поддерживает как криптографическую схему с открытыми ключами, так и симметричную схему шифрования. Протокол поддерживает гибкое определение алгоритмов шифрования с помощью возможности, называемой переговоры о параметрах (англ. option negotiation). В ней определяются три составляющих протокола.

Транзакционный модуль — т. е. будет ли запрос и/или ответ зашифрован и/или подписан.
Криптографические алгоритмы — что будет использовано для шифрования (в документе указаны DES и RC2), электронно-цифровой подписи (указаны RSA и DSA).
Выбор сертификата — какой из цифровых сертификатов использовать.

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

Формирование сообщения требует наличия трех составляющих.
1. Собственно сообщение формата HTTP или другие данные.
2. Криптографические предпочтения получателя и ключевая информация.
3. Криптографические предпочтения отправителя и ключевая информация.
Для создания сообщения отправитель должен произвести интеграцию криптографических
предпочтений своих и получателя и, сформировав список криптографических опций, применить
его с использованием соответствующей ключевой информации.

Восстановление сообщения (в HTTP формат) требует наличия четырех составляющих.
1. Собственно S-HTTP сообщение.
2. Определенные получателем ранее криптографические предпочтения и ключевая
информация.
3. Текущие криптографические предпочтения получателя и ключевая информация.
4. Определенные отправителем ранее криптографические предпочтения и ключевая
информация.

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

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

Формат сообщения включает строку запроса, строку статуса, заголовок протокола, содержание и опции формата инкапсуляции. Интересен принцип формирования строки статуса, предложенный в документе. Строка статуса определяется ответом сервера и имеет вид "Secure-HTTP/1.2 200 OK" независимо от успешной или неудачной обработки запроса. Как указано, это сделано для предотвращения возможного анализа злоумышленником успешных и неуспешных запросов. Структуру остальных строк можно изучить в документе draft-ietf-wts-shttp-02.txt.

Secure Socket Layer

Общие сведения

Secure Socket Layer (SSL) в настоящее время является, пожалуй, одним из самых популярных протоколов безопасности транспортного уровня, используемых в Интернете. Работая на транспортном уровне стека TCP/IP, он решает следующие задачи.

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

Протокол включает в себя два подпротокола — протокол записи (SSL record protocol), определяющий формат передачи данных, и протокол установки связи (SSL handshake protocol), определяющий механизм установки соединения.

Подпротокол SSL-записи

Основная функция протокола записи — работа с данными, поступающими от уровня приложения. На первом этапе производится фрагментирование данных в блоки для дальнейшей обработки (блок 16 384 байта для версии SSL 3.0). Затем производится упаковка (при отправлении) или распаковка (при получении) данных, если эта опция была задана. Далее производится шифрование данных тем алгоритмом, который был определен для клиента и сервера, а также устанавливается аутентификационный код сообщения (англ. message authentication code — MAC) для обеспечения контроля целостности сообщения.

Кроме того, этот подпротокол берет на себя функции генерирования сообщений об ошибках и закрытии сессии. Рассмотрим возможные варианты служебных сообщений, которые представлены в табл. 22.1.

                Таблица 22.1. Системные сообщения подпротокола SSL-записи

Сообщение                  Значение сообщения

Close_notify                    Это нормальное, не связанное с ошибкой, сообщение о закрытии
                                        сессии
Unexpected_message    Получено несоответствующее сообщение, которое приводит к
                                      закрытию сессии
Bad_record_mac            Получен   неверный   аутентификационный   код   сообщения, 
                                        приводящий к закрытию сессии
Decompression_failure  Функция распаковки получила неверное значение, приводит к
                                      закрытию сессии
Handshake_failure         Получатель не способен поддержать требуемый отправителем
                                    набор параметров безопасности, приводит к закрытию сессии
No_certificate                  Нет доступа к сертификату Bad_certificate                Сертификат
                                        поврежден
Unsup-                            Данный тип сертификата не поддерживается ported_ certificate
Certificate_revoked        Сертификат отозван выпустившим его субъектом 
Certificate_expired         Дата действия сертификата истекла или неверна
Certificate_unknown       При обработке данных сертификата возникли прочие
                                       неразрешимые проблемы
Illegal_parameter            Поле данных имеет неверное значение, которое приводит к
                                        закрытию сессии

Подпротокол установки связи

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

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

Клиент посылает сообщение Client_hello, в котором указывает версию протокола, случайное число, номер сессии, список поддерживаемых алгоритмов шифрования и список методов компрессии. Сервер отвечает сообщением Server_hello, в котором содержатся те же поля и в них указан выбор сервера из представленных клиентом возможностей. Если сервер должен аутенти- фицировать себя, он высылает клиенту свой сертификат. В случае если у него нет соответствующего сертификата, он высылает сообщение Server_key_exchange, в котором в зависимости от выбранного алгоритма асимметричного шифрования устанавливается способ передачи открытого ключа сервера.

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

Клиент высылает сообщение Client_certificate со своим сертификатом, либо сообщение No_certificate, если у него нет сертификата. Затем клиент высылает сообщение Client_key_exchange, в котором он формирует основу для генерации распределенного секрета для симметричного шифрования. Этот предварительный секрет он шифрует открытым ключом сервера из его сертификата.

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

Алгоритмы шифрования и аутентификации, используемые в реализации SSL, представлены в следующем списке:

DES — Data Encryption Standard и Triple-DES;
RC2 и RC4 — Rivest Cipher 2 и Rivest Cipher 4 соответственно;
DSA — Digital Signature Algoritm;
RSA и RSA key exchange — Rivest-Shamir-Addleman;
MD5 — Message Digest 5 и SHA-1 Secure Hash Algoritm 1;

Кроме того, при отдельных реализациях используются алгоритмы Skipjack и КЕА - Key Exchange Algorithm.

Рис. 22.22. Работа протокола установки связи, опциональные параметры

Различные варианты реализации протокола по убывающей от наиболее к наименее стойкой в криптографическом смысле конфигурации показаны в табл. 22.2. Данные представлены по состоянию до снятия ограничения на вывоз криптографии с длиной ключа более 40 бит из США.

Таблица 22.2. Параметры шифрования протокола SSL  

              Конфигурация                              Поддержка версий 
Шифрование                 Аутентификация
TripleDES (168 бит)        SHA-1 (160 бит)              SSL 2.0 и SSL 3.0
RC-4 (128 бит)             MD5 (128 бит)                SSL 2.0 и SSL 3.0
RC-2 (128 бит)             MD5 (128 бит)                SSL 2.0
DES (56 бит)               SHA-1 (160 бит)              SSL 2.0 и SSL 3.0
 (но версия 2 иногда 
 использует MD5 для аутентификации 
 сообщений)
RC-4 (40 бит)              MD5 (128 бит)                SSL 2.0 и SSL 3.0
RC-2 (40 бит)              MD5 (128 бит)                SSL 2.0 и SSL 3.0
Без шифрования             MD5 (128 6ит)                SSL 3.0

В заключение рассмотрим процессы проверки цифрового сертификата сервера клиентом и аутентификации клиента сервером.

Когда клиент получает цифровой сертификат сервера, он проверяет следующие параметры.

Срок действия сертификата: попадает ли текущая дата в этот период, если нет — процесс обработки прекращается, если да - переходит дальше.
Находится ли субъект, выпустивший сертификат (СА — Certification Authority), в списке доверенных СА клиента. Каждый клиент поддерживает список доверенных СА. Если субъект отсутствует в списке — сервер не аутентифицируется.
Используя открытый ключ СА из списка доверенных СА, клиент проверяет корректность электронно-цифровой подписи на сертификате сервера. Если подпись некорректна, то предполагается, что сертификат был изменен и не принимается.
Проверяется соответствие имени сервера (англ. domain name), указанного в сертификате, реальному имени сервера. Если они совпадают — сервер аутентифицирован.

Если сервер сконфигурирован таким образом, что он требует аутентификации клиента, процесс происходит следующим образом.

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

Если аутентификация прошла успешно, сервер производит авторизацию - т.е. проверяет, имеет ли клиент доступ к запрашиваемым ресурсам и в зависимости от правил доступа разрешает или запрещает доступ клиента к ресурсам.

Говоря о SSL, необходимо упомянуть и протокол TLS (Transport Layer Security — Безопасность Транспортного Уровня), который является в отличие от SSL официально опубликованным интернет-стандартом [RFC-2246], и популярность которого, по-видимому, будет расти. В указанном RFC говорится, что между протоколами нет кардинальных различий, и при этом TSL обеспечивает обратную совместимость с SSL. Одним из основных преимуществ TSL следует назвать возможность его встраивания в работу приложений независимыми разработчиками и расширения криптографических возможностей.

Secure Shell

(Стандарты draft-ietf-secsh-architecture-05, draft-ietf-secsh-userauth-07, draft-ietf-secsh-transport-07, draft-ietf-secsh-connect-07.)

Secure Shell (SSH) это протокол, обеспечивающий безопасную работу различных сетевых сервисов (таких как login) на незащищенной сети. Он состоит из трех подпротоколов.

Протокол транспортного уровня (SSH-TRANS) обеспечивает аутентификацию сервера, конфиденциальность и целостность данных. Опционально может производить компрессию данных. Обычно работает поверх TCP/IP, но может быть использован и с любым надежным потоком данных (8-битовый двоичный транспорт с коррекцией ошибок).
Протокол аутентификации пользователя (SSH-USERAUTH) аутентифи-цирует клиента перед сервером. Функционирует поверх протокола транспортного уровня.
Протокол соединения (SSH-CONN) совмещает (мультиплексирует) различные логические каналы в единый шифрованный канал. Функционирует поверх протокола аутентификации пользователя.

Рассмотрим общую архитектуру протокола и коснемся трех его составляющих. Одним из наиболее важных элементов схемы является требование аутентификации, которая производится на основе алгоритмов шифрования с открытым ключом. Это означает, что каждый участник взаимодействия (хост) должен иметь соответствующий ключ. Модель протокола допускает как вариант, когда один хост имеет множество ключей, так и вариант, когда множество хостов пользуются одним ключом. Для каждого из используемых алгоритмов хост должен иметь отдельный ключ (в качестве стандартного указан алгоритм DSS — Digital Signature Standard). Ключ сервера используется для обеспечения уверенности клиента, что он работает с соответствующим сервером. Для этого клиент должен иметь некоторые предварительные знания о ключе сервера. Протокол допускает существование двух различных моделей обеспечения клиента такой информацией.

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

Централизованная. Присутствует доверенная сторона СА (certification authority), которая производит подтверждение ассоциации хост/открытый ключ для каждого ключа, полученного клиентом. Таким образом, клиенту достаточно хранить только ключ самого СА. С другой стороны, до начала взаимодействия, каждый сервер должен быть сертифицирован СА. Теоре- тически допускается в качестве опции протокола возможность использования первой сессии с хостом без подтвержденной ассоциации хост/ключ, однако указывается, что такая возможность уязвима с точки зрения безопасности для атаки класса злоумышленник-посередине (англ. man-in-the-middle).

Допускаются альтернативные методы подтверждения корректности соответствия ключа хосту, например, вычисление 16-ричного значения хэш-функции открытого ключа (указан алгоритм SHA-1 Secure Hash Algorithm) и далее передача его для верификации внешними каналами связи (например, по телефону).

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

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

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

байт (byte) представляет некое 8-битовое значение (октет). Набор данных фиксированной длины может быть представлен, как byte(n), где n — количество байтов в массиве;
булевское (boolean) представляет один байт, интерпретируемый как 0 — "ложь" и 1 или любое ненулевое значение — "истина";
uint32 — 32-битное беззнаковое целое, хранимое как четыре байта в по рядке убывания значимости; строка (string) двоичная строка произвольной длины. При хранении строки сначала записывается длина строки len в формате uint32, затем следуют 0 или более байт символов — byte (len);
Mpint представляет целое увеличенной точности в двойном формате, наиболее значимый бит слева. В наиболее значимом бите первого байта записан 0 для положительного числа, 1 — для отрицательного.

Сетевые адреса отображаются в виде строк, DNS-имена не используются, так как протокол DNS не обеспечивает необходимой безопасности, если в адресе встречается двоеточие (:), он интерпретируется, как IPv6.

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

Имена, не содержащие символы @ и запятую, — это зарезервированные обозначения института IANA (Internet Assigned Numbers Authority) , такие как (без учета кавычек): "3des- cbc", "sha-1", "hmac-shal". Сюда входят наименования для алгоритмов шифрования, алгоритмов контроля целостности (message authentication control — MAC), алгоритмов с открытым ключом, методов обмена ключами и имен сервисов/протоколов.
Возможно определение дополнительных алгоритмов, используя имена для них в формате name@domain, где domain — это полностью обозначенное доменное имя (Full Qualified Domain Name — FQDN).

SSH использует нумерацию сообщений от 1 до 255, распределенные следующим образом.

1-19   Характеристики протокола транспортного уровня
        (disconnect, ignore, debug и т. п.).
20-29   Согласование алгоритмов.
30-49   Специфики способов обмена ключами.
50-59   Характеристики протокола аутентификации пользователя.
60-79   Специфики методов аутентификации пользователя.
80—89   Характеристики протокола соединения.
90-127  Сообщения, связанные с работой канала.
128-191 Зарезервированные для клиентских протоколов.
192-255 Локальные расширения (для особенностей реализации).

Рассмотрим некоторые особенности подпротоколов.

Подпротокол транспортного уровня

Напомним, что протокол обеспечивает аутентификацию только сервера, но не клиента, использует зарегистрированный TCP порт 22. Протокол применяет следующие методы (табл. 22.3).

Таблица 22.3. Параметры протокола SSH
Вид 
метода
Наименование
Описание
Требование поддержки
Сжатие
none
Без сжатия
Обязательно

zlib
GNU ZLIB (LZ77)
Опционально
Шифро-
вание
3des-cbc
Трехключевой  TripleDES в ре-
жиме CBC (168 бит)
Обязательно

blowfish-cbc
Blowfish   в   режиме   СВС   (128 
бит)
Рекомендовано

twofish-cbc
Twofish в режиме СВС (256 бит)
Рекомендовано

arcfour
Arcfour потоковый шифр
Опционально

idea-cbc
IDEA в режиме СВС
Опционально

cast128-cbc
CAST-128 в режиме СВС
Опционально

none
Без шифрования
Не   рекомендовано
Контроль
hmac-sha1
HMAC-SHA1 длиной 160 битов
Обязательно
целостно-
сти
hmac-sha-96
Первые 96 бит от HMAC-SHA1
Рекомендовано

hmac-md5
HMAC-MD5 длиной 128 бит
Опционально

hmac-md5-96
Первые 96 бит от HMAC-MD5
Опционально

none
Без контроля
Не   рекомендовано
Обмен 
ключами
diffie-hellman-
group1-sha1
Метод Диффи-Хеллмана, ком-
бинированный с электронно-
цифровой подписью
Обязательно
Открытые 
ключи
ssh-dss
Обычный DSS (Digital Signature 
Standard)
Обязательно

x509v3
Сертификаты Х.509
Рекомендовано

spki
Сертификаты SPKI
Опционально

pgp
Сертификаты OpenPGP
Опционально

Подпротокол аутентификации

Цель протокола - произвести аутентификацию клиента. Предполагается, что он будет работать поверх протокола транспортного уровня, который уже произвел аутентификацию сервера, установил шифрованное соединение и определил идентификатор сессии. Для усложнения возможных атак перебора ключей аутентификации, сервер может временно блокировать свою работу после нескольких неудачных попыток аутентификации. Если при работе транспортного уровня была выбрана нерекомендованная опция работы без шифрования, тогда аутентификационные методы, основанные на передаче секретных данных, должны быть блокированы. Кроме того, если отсутствует контроль целостности, необходимо отключить возможность изменения аутентификационных данных, таких как пароль, так как это может привести к отказу в работе сервиса (атака класса deny-of-service), если атакующий изменит шифрованный поток данных.

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

Метод none (без аутентификации) зарезервирован, но не должен предлагаться сервером в качестве допустимых методов аутентификации. Клиент может предложить этот метод серверу, но сервер должен отказать в нем, если только он не предоставляет возможности работы без аутентификации. В основном цель такого запроса клиента — это получение списка методов ау- тентификации от сервера. Если после отправления списка методов сервером клиент не отвечает, сервер должен иметь возможность разрыва соединения потаймауту (рекомендуемый период - 10 минут).

Подпротокол соединения

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