Шифры Вернама

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

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

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

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

Основанная на времени и основанная на событии аутентификация

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

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

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

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

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

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

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

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

Процесс аутентификации Kerberos

Существует несколько фаз к аутентификации Kerberos. В первой фазе клиент получает учетные данные (блоки данных, идентифицирующие и аутентифицирующие объект) использоваться, чтобы запросить доступ к kerberized службам. Во второй фазе клиент запрашивает аутентификацию на определенную службу. В заключительной фазе клиент представляет те учетные данные службе. Рисунок 1-2 и рисунок 1-3 иллюстрируют этот процесс.

Рисунок 1-2 показывает первую фазу, в которой клиент, маркировал Элис в числе, учетных данных запросов от Kerberos KDC.

Шаги следующие:

1. Элис ищет идентификатор пользователя для своего имени пользователя с помощью сервера каталогов.

   Элис тогда отправляет запрос к KDC, просящему учетные данные, если тот идентификатор пользователя (в открытом тексте).

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

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

   Это также создает идентификационные учетные данные, названные билетом выдачи билетов (TGT), содержащим копию сеансового ключа, зашифрованного с секретным симметричным ключом KDC’s (плюс другая информация).

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

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

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

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

В третьей фазе Элис отправляет учетные данные Бобу, и Боб отправляет информацию аутентификации Элис. Вторые и третьи фазы проиллюстрированы на рисунке 1-3.

Шаги следующие:

1. Элис отправляет два сообщения в KDC:

   • Аутентификатор — запрос для открытия сеанса с Бобом, включающим объявление идентификатора клиента метка времени — зашифрованное использование сеансового ключа

   • Сообщение, содержащее TGT, который KDC выпустил ранее

2. KDC дешифрует TGT и извлекает сеансовый ключ, который он выпустил ранее Элис. (Вспомните, что, когда KDC отправил сеансовый ключ Элис ранее, он был зашифрован с секретным ключом Элис, поэтому только KDC и Элис могут знать этот сеансовый ключ.), Поскольку TGT шифруется с секретным ключом KDC’s, он не мог быть изменен, и таким образом KDC доверяет тому сеансовому ключу.

   KDC получает идентификатор клиента Элис при помощи основного сеансового ключа для дешифрования аутентификатора.

   KDC тогда генерирует новый сеансовый ключ клиент-сервер для Элис для использования при передаче с Бобом, шифрует его с основным сеансовым ключом и отправляет его Элис.

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

3. Элис отправляет билет Бобу. Элис также отправляет новый аутентификатор (идентификатор клиента и метка времени) зашифрованное использование сеансового ключа клиент-сервер.

   Боб дешифрует его со своим секретным ключом. Поскольку только KDC и Боб знают его секретный ключ, Боб знает, что билет был выпущен KDC. Боб извлекает сеансовый ключ клиент-сервер.

   Боб использует сеанс клиент-сервер для дешифрования аутентификатора. Это тогда передает обратно сообщение, содержащее метку времени от аутентификатора плюс один, зашифрованное использование сеансового ключа.

4. Поскольку Элис знает, что только у нее и Боба есть этот сеансовый ключ, она знает, что учетные данные, должно быть, прибыли от Боба. Она проверяет значение и сравнивает его с тем, которое она получила ранее от KDC. Если они выключены одним (как ожидалось), она знает, что Боб аутентифицировался KDC.

Обратите внимание на то, что эта процедура не включает отправку или секретный ключ Элис или Боба по сети. Поскольку и Элис и Боб аутентифицируются друг другу, Боб знает, что Элис является действительным пользователем, и Элис знает, что Боб является сервером, с которым она намеревалась поддерживать деловые отношения. Все учетные данные далее защищены с метками времени и времена истечения срока. Kerberos имеет другие средства защиты также; для подробных данных посмотрите MIT веб-сайт Kerberos в MIT's kerberos страница.

Kerberos и авторизация

Kerberos является протоколом аутентификации, не протоколом авторизации. Т.е. это проверяет идентификационные данные и клиента и сервера, но это не включает информации о том, имеет ли клиент право использовать услуги, предоставленные сервером. С точки зрения предыдущего обсуждения, после того, как Боб удовлетворен, что запрос на службы действительно прибыл от Элис, это до Боба, чтобы определить, предоставить ли доступ Элис к тем службам. Билет, который Боб получает от Элис, содержит достаточно информации об Элис, чтобы позволить Бобу сделать то определение.

Начиная с версии 5 Kerberos билеты Kerberos обеспечивают механизм для устойчивой к внешним воздействиям передачи информации авторизации. Когда клиент запрашивает билет, он включает информацию о себе в запросе и может запросить, чтобы KDC включал дополнительную авторизацию в билет. KDC вставляет эту информацию в поле данных авторизации билета и вперед этого к серверу. Kerberos не определяет, как должна быть закодирована эта информация авторизации; это обеспечивает только безопасный механизм для своей передачи. Это до клиента и сервера для реализации протокола авторизации.

Единая точка входа

OS X использует Kerberos для аутентификации единой точки входа, освобождающей пользователей от ввода имени и пароля отдельно для каждой kerberized службы. С единой точкой входа, после того, как пользователь вводит имя и пароль в окно входа в систему, пользователь не должен вводить имя и пароль для файловой службы Apple, почтовой службы или других служб то использование аутентификация Kerberos. Другими словами, Kerberos аутентифицирует пользователя один раз, и после того использует билеты для идентификации пользователя.

Для использования в своих интересах функции единой точки входа службы должны быть сконфигурированы для аутентификации Kerberos и пользователей, и службы должны использовать тот же Kerberos KDC. В OS X Открывают учетные записи пользователей в каталоге LDAP, имеющие тип пароля, Directory используют встроенный KDC сервера. Эти учетные записи пользователей автоматически сконфигурированы для Kerberos и единой точки входа. kerberized службы сервера также используют встроенный KDC сервера и автоматически сконфигурированы для единой точки входа.

Большие сети

На высоком уровне можно обычно думать о Центре распределения ключей (KDC) Kerberos как о единственном объекте. Однако KDC состоит из двух отдельных программных процессов: сервер аутентификации и сервер выдачи билетов. Сервер аутентификации проверяет идентификационные данные пользователя путем запроса пользователя имя и пароль и выяснения у сервера каталогов пароль пользователя. Сервер аутентификации тогда ищет секретный ключ пользователя, генерирует сеансовый ключ и создает билет выдачи билетов (TGT), как показано на рисунке 1-4.

После того пользователь отправляет TGT в сервер выдачи билетов каждый раз, когда службы kerberized сервера требуются, и сервер выдачи билетов выпускает билет, как показано на рисунке 1-5.

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

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