Транспортное кодирование

Сжатие данных

Прочие компоненты криптосистем

К вспомогательным компонентам криптосистем относятся алгоритмы компрессии данных, отметки времени, порядкового номера, транспортного и помехоустойчивого кодирования. Из этого списка к дополнительным мерам безопасности переписки можно отнести предварительное сжатие данных и вставку отметки времени (англ. timestamp) или порядкового номера сообщения.

Сжатие данных увеличивает информационную плотность входного потока данных и, как следствие, улучшает его статистические характеристики. В отношении атак по шифротексту и по известному открытому тексту это, несомненно, играет против злоумышленника.

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

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

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

Алгоритм, выполняющий прямое преобразование, называется кодером, выполняющий обратное преобразование — декодером. Сами схемы кодирования традиционно носят второе название — кодек (сокращение по нескольким первым буквам: кодер/декодер).

Рис. 6. Схема установки транспортного кодека

Среди множества алгоритмов транспортного кодирования в криптографии наиболее прижился кодек Base64, стандартизованный в [RFC—1341]. Входной поток символов последовательно разбивается на блоки по три байта (24 бита), каждый из которых затем интерпретируется как четыре 6-битных числа. Эти числа используются как индексы в таблице из 64 разрешенных символов, включающей заглавные и строчные буквы латиницы, числа и несколько знаков.

Идентификация, аутентификация и авторизация

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

· на предъявлении пользователем пароля (рис. 7);

· на предъявлении пользователем доказательств, что он обладает секретной ключевой информацией;

· на ответах на некоторые тестовые вопросы;

· на предъявлении пользователем некоторых неизменных признаков, неразрывно связанных с ним;

· на предоставлении доказательств того, что он находится в определенном месте в определенное время;

· на установлении подлинности пользователя некоторой третьей доверенной стороной.

Процедуры аутентификации должны быть устойчивы к подлогу, подбору и подделке.

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

Рис. 7. Процессы идентификации и аутентификации

Схема Kerberos

Решение задачи аутентификации в современных информационных системах, представляющих собой совокупность реализованных на различных аппаратно-программных платформах территориально разнесенных компонентов, в соответствии с технологией клиент/сервер заключается в использовании специального сервера аутентификации. В настоящее время роль фактического стандарта сервера аутентификации выполняет Kerberos - продукт, разработанный в Массачусетсом технологическом институте (MIT) в середине 1980 годов и претерпевший с тех пор ряд принципиальных изменений. Широкому распространению Kerberos способствовало то, что его версия, реализованная в MIT, является свободно распространяемым продуктом. Программные средства, выполняющие аутентификацию по схеме Kerberos, разработаны для всех популярных ОС. Поддержка службы Kerberos предусмотрена в некоторых современных сетевых ОС. Схема Kerberos является типичным примером реализации симметричных методов аутентификации.

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

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

· он должен быть размещен в помещении с контролируемым физическим доступом;

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

· он не должен использоваться для хранения посторонних данных и т. п.

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

· Протокол не защищает от атак класса "Отказ в обслуживании".

· Принципалы должны сохранять в тайне свои секреты — протокол не обеспечивает защиты в случае утери секрета.

· Протокол не защищает от атак типа "Разгадывание пароля": выбор надежного пароля, который служит секретом или на котором строится секрет, оставляется на усмотрение принципалов.

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

· Новые принципалы не должны наследовать идентификаторы старых, удаленных из системы (сети), иначе они могут унаследовать и их права доступа.

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

· доверенный сервер генерирует некий сессионный ключ;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1. Клиент решает поработать с сервером ресурсов. Для этого клиент формирует запрос KRB_TGS_REQ — 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. Клиент отправляет запрос KRB_AP_REQ серверу ресурсов.

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

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

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

Дата добавления: 2014-01-07