|
|||||||
АвтоАвтоматизацияАрхитектураАстрономияАудитБиологияБухгалтерияВоенное делоГенетикаГеографияГеологияГосударствоДомДругоеЖурналистика и СМИИзобретательствоИностранные языкиИнформатикаИскусствоИсторияКомпьютерыКулинарияКультураЛексикологияЛитератураЛогикаМаркетингМатематикаМашиностроениеМедицинаМенеджментМеталлы и СваркаМеханикаМузыкаНаселениеОбразованиеОхрана безопасности жизниОхрана ТрудаПедагогикаПолитикаПравоПриборостроениеПрограммированиеПроизводствоПромышленностьПсихологияРадиоРегилияСвязьСоциологияСпортСтандартизацияСтроительствоТехнологииТорговляТуризмФизикаФизиологияФилософияФинансыХимияХозяйствоЦеннообразованиеЧерчениеЭкологияЭконометрикаЭкономикаЭлектроникаЮриспунденкция |
Взаимная аутентификацияДанные протоколы применяются для взаимной аутентификации участников и для обмена ключом сессии. Основной задачей таких протоколов является обеспечение конфиденциального распределения ключа сессии и гарантирование его своевременности, то есть протокол не должен допускать повторного использования старого ключа сессии. Для обеспечения конфиденциальности ключи сессии должны передаваться в зашифрованном виде. Вторая задача, обеспечение своевременности, важна, потому что существует угроза перехвата передаваемого сообщения и повторной его пересылки. Такие повторения в худшем случае могут позволять взломщику использовать скомпрометированный ключ сессии, при этом успешно подделываясь под другого участника. Успешное повторение может, как минимум, разорвать операцию аутентификации участников. Такие повторы называются replay-атаками. Рассмотрим возможные примеры подобных replay-атак:
Один из возможных подходов для предотвращения replay-атак мог бы состоять в присоединении последовательного номера (sequence number) к каждому сообщению, используемому в аутентификационном обмене. Новое сообщение принимается только тогда, когда его последовательный номер правильный. Трудность данного подхода состоит в том, что каждому участнику требуется поддерживать значения sequence number для каждого участника, с которым он взаимодействует в данный момент. Поэтому обычно sequence number не используются для аутентификации и обмена ключами. Вместо этого применяется один из следующих способов:
Считается, что подход с отметкой времени не следует использовать в приложениях, ориентированных на соединение, потому что это технически трудно, так как таким протоколам, кроме поддержки соединения, необходимо будет поддерживать синхронизацию часов различных процессоров. При этом возможный способ осуществления успешной атаки может возникнуть, если временно будет отсутствовать синхронизация часов одного из участников. В результате различной и непредсказуемой природы сетевых задержек распределенные часы не могут поддерживать точную синхронизацию. Следовательно, процедуры, основанные на любых отметках времени, должны допускать окно времени, достаточно большое для приспособления к сетевым задержкам, и достаточно маленькое для минимизации возможности атак. С другой стороны, подход запрос/ответ не годится для приложений, не устанавливающих соединения, так как он требует предварительного рукопожатия перед началом передач, тем самым отвергая основное свойство транзакции без установления соединения. Для таких приложений доверие к некоторому безопасному серверу часов и постоянные попытки каждой из частей синхронизировать свои часы с этим сервером может быть оптимальным подходом. Использование симметричного шифрования Для обеспечения аутентификации и распределения ключа сессии часто используется двухуровневая иерархия ключей симметричного шифрования. В общих чертах эта стратегия включает использование доверенного центра распределения ключей (KDC). Каждый участник разделяет секретный ключ, называемый также мастер-ключом, с KDC. KDC отвечает за создание ключей, называемых ключами сессии, и за распределение этих ключей с использованием мастер-ключей. Ключи сессии применяются в течение короткого времени для шифрования только данной сессии между двумя участниками. Большинство алгоритмов распределения секретного ключа с использованием KDC, включает также возможность аутентификации участников. Протокол Нидхэма и Шредера Предполагается, что секретные мастер-ключи KA и KB разделяют соответственно А и KDC и В и KDC. Целью протокола является безопасное распределение ключа сессии KS между А и В. Протокол представляет собой следующую последовательность шагов: 1. A KDC: IDA || IDB || N12. KDC A: EKa [KS || IDB || N1 || EKb [KS || IDA] ]3. A B: EKb [KS || IDA]4. B A: EKS [N2]5. A B: EKS [f (N2)]
А должен убедиться, что полученный nonce равен значению nonce из первого запроса. Это доказывает, что ответ от KDC не был модифицирован при пересылке и не является повтором некоторого предыдущего запроса. Кроме того, сообщение включает два элемента, предназначенные для В:
Эти два последних элемента шифруются мастер-ключом, который KDC разделяет с В. Они посылаются В при установлении соединения и доказывают идентификацию А.
В этой точке ключ сессии безопасно передан от А к В, и они могут начать безопасный обмен. Тем не менее, существует еще два дополнительных шага:
Эти шаги гарантируют B, что сообщение, которое он получил, не изменено и не является повтором предыдущего сообщения. Заметим, что реальное распределение ключа включает только шаги 1 - 3, а шаги 4 и 5, как и 3, выполняют функцию аутентификации. А безопасно получает ключ сессии на шаге 2. Сообщение на шаге 3 может быть дешифровано только B. Шаг 4 отражает знание В ключа KS, и шаг 5 гарантирует В знание участником А ключа KS и подтверждает, что это не устаревшее сообщение, так как используется nonce N2. Шаги 4 и 5 призваны предотвратить общий тип replay-атак. В частности, если противник имеет возможность захватить сообщение на шаге 3 и повторить его, то это должно привести к разрыву соединения. Разрывая рукопожатие на шагах 4 и 5, протокол все еще уязвим для некоторых форм атак повторения. Предположим, что противник Х имеет возможность скомпрометировать старый ключ сессии. Маловероятно, чтобы противник мог сделать больше, чем просто копировать сообщение шага 3. Потенциальный риск состоит в том, что Х может заставить взаимодействовать А и B, используя старый ключ сессии. Для этого Х просто повторяет сообщение шага 3, которое было перехвачено ранее и содержит скомпрометированный ключ сессии. Если В не запоминает идентификацию всех предыдущих ключей сессий с А, он не сможет определить, что это повтор. Далее Х должен перехватить сообщение рукопожатия на шаге 4 и представиться А в ответе на шаге 5. Протокол Деннинга Деннинг предложил преодолеть эту слабость модификацией протокола Нидхэма и Шредера, которая включает дополнительную отметку времени на шагах 2 и 3: 1. A -> KDC: IDA || IDB2. KDC -> A: EKa [KS || IDB || T || EKb [KS || IDA || T] ]3. A -> B: EKb [KS || IDA || T]4. B -> A: EKS [N1]5. A -> B: EKS [f (N1)]Т - это отметка времени, которая гарантирует А и B, что ключ сессии является только что созданным. Таким образом, и А, и В знают, что распределенный ключ не является старым. А и В могут верифицировать временную отметку проверкой, что |Clock - T| < Δt1 + Δt2где Δ t1 - оцениваемое нормальное расхождение между часами KDC и локальными часами (у А или B) и t2 - ожидаемая сетевая задержка времени. Каждый участник может установить свои часы, ориентируясь на определенный доверенный источник. Поскольку временная отметка Т шифруется с использованием секретных мастер-ключей, взломщик, даже зная старый ключ сессии, не сможет достигнуть цели повторением шага 3 так, чтобы В не заметил искажения времени. Шаги 4 и 5 не были включены в первоначальное представление, но были добавлены позднее. Эти шаги подтверждают А, что В получил ключ сессии. Протокол Деннинга обеспечивает большую степень безопасности по сравнению с протоколом Нидхэма и Шредера. Однако данная схема требует доверия к часам, которые должны быть синхронизированы в сети. В этом есть определенный риск, который состоит в том, что распределенные часы могут рассинхронизироваться в результате диверсии или повреждений. Проблема возникает, когда часы отправителя спешат по отношению к часам получателя. В этом случае противник может перехватить сообщение от отправителя и повторить его позднее, когда отметка времени в сообщении станет равной времени на узле получателя. Это повторение может иметь непредсказуемые последствия. Один способ вычисления атак повторения состоит в требовании, чтобы участники регулярно сверяли свои часы с часами KDC. Другая альтернатива, при которой нет необходимости всем синхронизировать часы, состоит в доверии протоколам рукопожатия, использующим nonce. Протокол аутентификации с использованием билета Данный протокол пытается преодолеть проблемы, возникшие в предыдущих двух протоколах. Он выглядит следующим образом: 1. A -> B: IDA || Na2. B -> KDC: IDB || Nb || EKb [IDA || Na || Tb]3. KDC -> A: EKa [IDB || Na || KS || Tb] || EKb [IDA || KS || Tb] || Nb4. A -> B: EKb [IDA || KS || Tb] || EKS [Nb]
Данный протокол аутентифицирует А и В и распределяет ключ сессии. Более того, протокол предоставляет в распоряжение А билет, который может использоваться для его последующей аутентификации, исключая необходимость повторных контактов с аутентификационным сервером. Предположим, что А и В установили сессию с использованием описанного выше протокола и затем завершили эту сессию. Впоследствии, но до истечения лимита времени, установленного протоколом, А может создать новую сессию с B. Используется следующий протокол: 1. A -> B: EKb [IDA || KS || Tb], Na'2. B -> A: Nb', ES [Na']3. A -> B: ES [Nb']Когда В получает сообщение на шаге 1, он проверяет, что билет не просрочен. Заново созданные nonces Na' и Nb' гарантируют каждому участнику, что не было атак повтора. Время Tb является временем относительно часов B. Таким образом, эта временная метка не требует синхронизации, потому что В проверяет только им самим созданные временные отметки. Использование шифрования с открытым ключом Протокол аутентификации с использованием аутентификационного сервера. Рассмотрим протокол, использующий отметки времени и аутентификационный сервер: 1. A -> AS: IDA || IDB2. AS -> A: EKRas [IDA || KUa || T] || EKRas [IDB || KUb || T]3. A -> B: EKRas [IDA || KUa || T] || EKRas [IDB || KUb || T] || EKUb [EKRa [KS || T]]В данном случае третья доверенная сторона является просто аутентификационным сервером AS, потому что третья сторона не создает и не распределяет секретный ключ. AS просто обеспечивает сертификацию открытых ключей участников. Ключ сессии выбирается и шифруется А, следовательно, не существует риска, что AS взломают и заставят распределять скомпрометированные ключи сессии. Отметки времени защищают от повтора скомпрометированных ключей сессии. Данный протокол компактный, но, как и прежде, требует синхронизации часов. Протокол аутентификации с использованием KDC Другой подход использует nonces. Этот протокол состоит из следующих шагов: 1. A -> KDC: IDA || IDB2. KDC -> A: EKRkdc [IDB || KUb]3. A -> B: EKUb [Na || IDA]4. B -> KDC: IDB || IDA || EKUkdc [Na]5. KDC -> B: EKRkdc [IDA || KUa] || EKUb [EKRkdc [Na || KS || IDB]]6. B -> A: EKUa [EKRkdc [Na || KS || IDB] || Nb]7. A -> B: EKS [Nb]На первом шаге А информирует KDC, что хочет установить безопасное соединение с B. KDC возвращает А сертификат открытого ключа В (шаг 2). Используя открытый ключ B, А информирует В о создании защищенного соединения и посылает nonce Na (шаг 3). На 4-м шаге В спрашивает KDC о сертификате открытого ключа А и запрашивает ключ сессии. В включает nonce A, чтобы KDC мог пометить ключ сессии этим nonce. Nonce защищен использованием открытого ключа KDC. На 5-м шаге KDC возвращает В сертификат открытого ключа А плюс информацию {Na, KS, IDB}. Эта информация означает, что KS является секретным ключом, созданным KDC в интересах В и связан с Na. Связывание KS и Na гарантирует А, что KS не устарел. Эта тройка шифруется с использованием закрытого ключа KDC, это гарантирует B, что тройка действительно получена от KDC. Она также шифруется с использованием открытого ключа B, чтобы никто другой не мог подсмотреть ключ сессии и использовать эту тройку для установления соединения с А. На шаге 6 тройка {Na, KS, IDB}, зашифрованная закрытым ключом KDC, передается А вместе с nonce Nb, созданным B. Все сообщение шифруется открытым ключом А. А восстанавливает ключ сессии KS, использует его для шифрования Nb, который возвращает B. Это последнеее сообщение гарантирует B, что А знает ключ сессии. Это достаточно безопасный протокол при различного рода атаках. Однако авторы предложили пересмотренную версию данного алгоритма: 1. A -> KDC: IDA || IDB2. KDC -> A: EKRauth [IDB || KUb]3. A -> B: EKUb [Na || IDA]4. B -> KDC: IDB || IDA || EKUauth [Na]5. KDC -> B: EKRauth [IDA || KUa] || EKUb [ EKRauth [Na || KS || IDA || IDB]]6. B -> A: EKUa [EKRauth [Na || KS || IDA || IDB] || Nb]7. A -> B: EKS [Nb]Добавляется идентификатор А IDA к данным, зашифрованных с использованием закрытого ключа KDC на шагах 5 и 6 для идентификации обоих участников сессии. Это включение IDA приводит к тому, что значение nonce Na должно быть уникальным только среди всех nonces, созданных А, но не среди nonces, созданных всеми участниками. Таким образом, пара {IDA, Na} уникально идентифицирует соединение, созданное А. Поиск по сайту: |
Все материалы представленные на сайте исключительно с целью ознакомления читателями и не преследуют коммерческих целей или нарушение авторских прав. Студалл.Орг (0.005 сек.) |