В. Р. Гинзбург Перевод с английского
жүктеу/скачать 2,74 Mb. Pdf көрінісі
|
практическая криптография
Глава 18 Серверы ключей Пришло время вплотную заняться управлением ключами. Это, без со- мнения, самый трудный момент всех криптографических систем. Именно по- этому мы решили рассмотреть управление ключами в конце книги. Мы уже объясняли, как шифровать данные, проводить их аутентификацию и согласо- вывать секретный ключ между двумя участниками общения. Теперь нужно найти способ, с помощью которого пользователи А и Б могли бы идентифи- цировать друг друга по Internet. Вы вскоре убедитесь, что сложность данной проблемы разрастается с быстротой снежного кома. Управление ключами является таким трудным еще и потому, что вместо математических формул в нем задействованы люди, а понять и предсказать человеческую логику на- много сложнее. Прежде чем начинать, давайте проясним еще один момент. Мы будем го- ворить исключительно о криптографических аспектах управления ключами. Такие организационные аспекты, как политики, описывающие, кому следует выдавать ключи, какие ключи будут предоставлять доступ к каким ресурсам, как проверить личность человека, получившего ключ, политики безопасно- сти хранения ключей, механизмы верификации, проверяющие, действительно ли в системе придерживаются этих политик, и прочее, затронуты не будут. Каждая организация реализует эти аспекты по-своему, в зависимости от сво- их требований и существующей организационной инфраструктуры. Поэтому нас интересуют только те элементы управления ключами, которые непосред- ственно влияют на криптографическую систему. Один из способов управления ключами — создание доверенной сущности, которая будет раздавать пользователям все необходимые ключи. Назовем такую сущность сервером ключей (key server) . 331 332 Глава 18. Серверы ключей 18.1 Основная идея Идея, лежащая в основе применения сервера ключей, очень проста. Мы предполагаем, что каждый пользователь обменивается общим секретным ключом с сервером ключей. Например, пользователь А выбирает ключ K A , который будет известен только ему и серверу ключей. Пользователь Б выби- рает ключ K B , который будет известен только ему и серверу ключей. Ана- логичным образом свои секретные ключи выбирают и остальные участники общения. Теперь предположим, что пользователь А хочет начать общаться с поль- зователем Б. У него нет ключа, посредством которого он мог бы общаться с пользователем Б, зато он может безопасно общаться с сервером ключей. Сервер ключей, в свою очередь, может безопасно общаться с пользовате- лем Б. В подобной ситуации мы могли бы просто направлять весь трафик на сервер ключей, который выполнял бы роль гигантского почтового отделе- ния. К сожалению, обработка такого объема трафика оказалась бы слишком сложным заданием для одного сервера. Гораздо лучше, если сервер ключей сгенерирует ключ K AB , который будет совместно применяться пользовате- лями А и Б. 18.2 Kerberos Описанная идея легла в основу Kerberos — системы управления ключами, которая широко используется во всем мире [57]. Родоначальником Kerberos стал протокол Нидхэма–Шредера (Needham–Schroeder) [75]. Базовый принцип работы Kerberos можно объяснить следующим образом. Когда пользователь А хочет отправить сообщение пользователю Б, он внача- ле связывается с сервером ключей. Сервер ключей посылает пользователю А новый секретный ключ K AB , а также ключ K AB , зашифрованный с помощью ключа K B пользователя Б. Оба сообщения зашифрованы с помощью ключа K A , чтобы их мог прочитать только пользователь А. Он отсылает ключ K AB , зашифрованный с помощью ключа K B , пользователю Б, который расшиф- ровывает это сообщение и получает ключ K AB . После этого ключ K AB на- чинает выступать в роли ключа сеанса, известного только пользователям А и Б (ну и, разумеется, серверу ключей). Одно из свойств Kerberos состоит в том, что серверу ключей, который в терминологии Kerberos называется центром распространения ключей или ЦРК (Key Distribution Center — KDC) , не нужно обновлять свое состояние слишком часто. Разумеется, сервер ключей должен помнить все общие клю- чи, которыми он обменялся с каждым участником. Тем не менее, когда поль- зователь А просит ЦРК создать ключ для общения между ним и пользова- 18.3. Решения попроще 333 телем Б, ЦРК выполняет свою функцию и тут же об этом забывает. Он не следит за тем, какие ключи были сгенерированы им для общения пользо- вателей друг с другом. Это очень удобное свойство, так как оно позволяет без особых трудностей распределить сверх меры загруженный сервер клю- чей между несколькими компьютерами. Поскольку серверу ключей не нуж- но обновлять свое состояние, пользователь А может в один момент общаться с одной копией сервера, а в следующий момент — уже с другой его копией. Оказывается, что криптографические протоколы, которые требуются для работы систем на основе Kerberos, очень сложны. Вначале проектирование подобных протоколов выглядит довольно простым, но даже разработки опыт- ных криптографов в конце концов оказывались взломанными. Изъяны, кото- рым удается проникнуть в эти протоколы, крайне тонки и незаметны. Мы не будем рассматривать протоколы такого типа, поскольку считаем их слишком опасными. Даже мы избегаем разрабатывать их “с нуля”. Если вам действи- тельно нужен подобный протокол, воспользуйтесь последней версией Ker- beros. Он уже довольно давно применяется на практике и тщательно изучен многими компетентными критиками. 18.3 Решения попроще Иногда использовать Kerberos невозможно. Структуру этого протокола никак не назовешь простой. Кроме того, она накладывает на систему неко- торые ограничения. Серверы должны запоминать все принятые ими билеты, а каждому участнику общения нужны надежные часы 1 . В некоторых ситуа- циях удовлетворить подобные требования невозможно. Между тем мы можем создать более простое и надежное решение, если не будем слишком заострять внимание на эффективности. Оказывается, что со- хранение сервером ключей своего состояния может весьма пригодиться для распространения ключей. Современные компьютеры намного мощнее, чем вычислительные машины тех лет, когда создавался Kerberos. Поэтому они не должны испытывать затруднений, сохраняя состояние сервера для десят- ков тысяч участников. Даже наличие большой системы со 100 000 участников не представляет особых проблем: если на каждого участника потребуется по 1 Кбайт для сохранения состояния на сервере ключей, сохранение всех состо- яний потребует лишь 100 Мбайт памяти. Разумеется, сервер ключей все же должен быть достаточно быстрым, чтобы генерировать все запрашиваемые ключи, но это не составит проблем для современных быстрых компьютеров. Мы ограничимся тем, что рассмотрим использование только одного сер- вера ключей. Существуют методы, с помощью которых состояние сервера 1 Билет (ticket) — это сообщение, которое пользователь А отсылает пользователю Б. Это стандартная терминология Kerberos. |