Oakley
- 1 year ago
- 0
- 0
Протокол Oakley — протокол согласования ключей, который позволяет двум аутентифицированным сторонам безопасно согласовать ключевой материал. Протокол был предложен Хилари К. Орман в 1998 году и лег в основу более широко используемого протокола Internet Key Exchange .
Целью обработки обмена ключами является безопасное установление общего состояния ключевой информации на двух сторонах. Эта информация о состоянии представляет собой имя ключа, секретный ключевой материал, идентификацию двух сторон и три алгоритма для использования во время аутентификации: шифрование (для конфиденциальности личности двух сторон), хеширование ( псевдослучайная функция для защиты целостности сообщения и для аутентификации полей сообщений) и аутентификация (алгоритм, на котором основана взаимная аутентификация двух сторон).
Обмен в основном режиме имеет пять дополнительных функций: обмен файлами cookie без сохранения состояния, совершенная прямая секретность для ключевого материала, секретность для удостоверений, абсолютная прямая секретность для тайны личности, использование подписей (для неотказуемости). Обе стороны могут использовать любую комбинацию этих функций.
Общая схема обработки заключается в том, что Инициатор обмена начинает с указания в своем первом сообщении как можно большего количества информации. Ответчик отвечает, предоставляя столько информации, сколько пожелает. Обе стороны обмениваются сообщениями, каждый раз предоставляя больше информации, пока их требования не будут удовлетворены.
Выбор того, сколько информации включать в каждое сообщение, зависит от того, какие параметры желательны. Например, если куки-файлы без сохранения состояния не являются обязательными, а секретность личности и совершенная прямая секретность для ключевого материала не являются обязательными, и если неотказуемые подписи допустимы, то обмен может быть завершен в трех сообщениях. Дополнительные функции могут увеличить количество циклов, необходимых для определения ключевого материала.
ISAKMP предоставляет поля для указания параметров ассоциации безопасности для использования с протоколами AH и ESP . Эти типы полезной нагрузки сопоставления безопасности указаны в спецификации ISAKMP; типы полезной нагрузки могут быть защищены с помощью ключевого материала и алгоритмов Oakley.
Обмен ключами может быть завершен за три или более сообщений, но точное число сообщений определяется при выборе параметров сторонами.
Основные составляющие протокола:
При начале обмена инициатор может отправить ответчику как минимальный набор данных для запроса на обмен ключей без дополнительной информации, так и предоставить больше информации вплоть до всей необходимой информации для аутентификации и быстрого завершения определения ключа. В ответ инициатор получит, в зависимости от изначально переданной информации, как минимум файл cookie.
Методом аутентификации могут быть как цифровые подписи , так и асимметричное шифрование , внеполосный симметричный ключ. Каждый метод вносит небольшие различия в сообщениях между сторонами.
Инициатор несет ответственность за повторную передачу сообщений ответчику в случае ошибок, поэтому ответчик должен сохранять информацию полученную при обмене, пока эта информация не будет подтверждена.
Все поля в сообщении именованы и разделяются запятой.
Агрессивный режим обмена ключами позволяет установить ключевую информацию за три сообщения. При таком режиме идентификаторы сторон не являются секретными, но полученный ключевой материал удовлетворяет условиям полной прямой секретности.
Использование цифровых подписей для аутентификации дает доказательство связи сторонам, а также эти данные могут быть записаны и представлены третьим сторонам.
При этом ключевой материал, подразумеваемый групповыми экспонентами, не требуется для завершения обмена. Если желательно отложить вычисление, возможно сохранение этих значений «x» и «g^y» с пометкой этого ключевого материала как «нерассчитанного».
Инициатор | Ответчик | |
-> |
CKY-I, 0, OK_KEYX, GRP, g^x, EHAO, NIDP, ID(I), ID(R), Ni, 0,
S{ID(I)|ID(R)|Ni|0|GRP|g^x|0|EHAO}Ki |
-> |
<- |
CKY-R, CKY-I, OK_KEYX, GRP, g^y, EHAS, NIDP, ID(R), ID(I), Nr, Ni,
S{ID(R)|ID(I)|Nr|Ni|GRP|g^y|g^x|EHAS}Kr |
<- |
-> |
CKY-I, CKY-R, OK_KEYX, GRP, g^x, EHAS, NIDP, ID(I), ID(R), Ni, Nr,
S{ID(I)|ID(R)|Ni|Nr|GRP|g^x|g^y|EHAS}Ki |
-> |
Результатом обмена является ключ с идентификатором KEYID и значением sKEYID:
KEYID = CKY-I|CKY-R;
sKEYID = prf(Ni | Nr, g^xy | CKY-I | CKY-R).
Схема обмена в агрессивном режиме:
Во всех обменах каждая сторона следит за тем, чтобы она не предлагала и не принимала 1 или g^(p-1) в качестве экспоненты. При этом, несмотря на отсутствие PFS для защиты идентификаторов, PFS для полученного ключевого материала присутствует, так как обмениваются частичные ключи Диффи-Хеллмана.
Если ответчик принимает только часть информации инициатора, то инициатор будет считать, что протокол выполняется. Инициатор должен исходить из того, что поля, которые не были приняты ответчиком, не были записаны ответчиком. Если же ответчик не принимает агрессивный обмен и выбирает другой алгоритм для функции аутентификации, то протокол переходит к стандартному режиму и стороны перестают использовать алгоритм подписи из первого сообщения.
Когда ответчик не принимает поля, предложенные инициатором, то он включает пустые значения для этих полей в свой ответ, причем все последующие поля должны быть нулевыми. Если идентификаторы и одноразовые номера имеют нулевые значения, то не будет подписи над этими нулевыми значениями.
Криптография с открытым ключом скрывает личность во время аутентификации. Групповые экспоненты обмениваются и аутентифицируются, но подразумеваемый ключевой материал (g^xy) не требуется во время обмена.
Этот обмен имеет важное отличие от предыдущей схемы подписи — в первом сообщении идентификатор ответчика указывается в виде открытого текста: ID(R'). Однако личность, скрытая с помощью криптографии с открытым ключом, отличается: ID(R). Это происходит потому, что инициатор должен сообщить ответчику, какую пару открытого/закрытого ключей использовать для расшифровки, но в то же время личность скрыта за счет шифрования с помощью этого открытого ключа.
Инициатор может принять решение отказаться от секретности личности ответчика, но это нежелательно. Вместо этого, если имеется общеизвестный идентификатор узла ответчика, открытый ключ для этого идентификатора можно использовать для шифрования фактического идентификатора ответчика.
Инициатор | Ответчик | |
-> |
CKY-I, 0, OK_KEYX, GRP, g^x, EHAO, NIDP,
ID(R'), E{ID(I), ID(R), E{Ni}Kr}Kr' |
-> |
<- |
CKY-R, CKY-I, OK_KEYX, GRP, g^y, EHAS, NIDP,
E{ID(R), ID(I), Nr}Ki, prf(Kir, ID(R)|ID(I)|GRP|g^y|g^x|EHAS) |
<- |
-> |
CKY-I, CKY-R, OK_KEYX, GRP, 0, 0, NIDP,
prf(Kir, ID(I)|ID(R)|GRP|g^x|g^y|EHAS) |
-> |
Kir = prf(0, Ni | Nr)
KEYID = CKY-I|CKY-R
sKEYID = prf(Ni | Nr, g^xy | CKY-I | CKY-R)
Схема обмена в агрессивном режиме со скрытыми идентификаторами:
sKEYID = prf(Ni | Nr, g^xy | CKY-I | CKY-R)
При этом, несмотря на отсутствие PFS для защиты идентификаторов, PFS для полученного ключевого материала присутствует, так как обмениваются частичные ключи g^x и g^y Диффи-Хеллмана.
Значительных вычислительных затрат можно избежать, если полная секретность пересылки не является требованием для получения сеансового ключа. Обе стороны могут обмениваться одноразовыми номерами и частями секретного ключа для аутентификации и получения ключевого материала. Долгосрочная конфиденциальность данных, защищенных с помощью производного ключевого материала, зависит от закрытых ключей каждой из сторон.
В приведенном ниже обмене GRP имеет значение 0, а поле групповой экспоненты вместо этого используется для хранения одноразового значения. Первый предлагаемый алгоритм должен быть системой шифрования с открытым ключом; отвечая с помощью файла cookie и ненулевого экспоненциального поля, Ответчик неявно принимает первое предложение и отсутствие полной прямой секретности для идентификаторов и производного ключевого материала.
Инициатор | Ответчик | |
-> |
CKY-I, 0, OK_KEYX, 0, 0, EHAO, NIDP,
ID(R'), E{ID(I), ID(R), sKi}Kr’, Ni |
-> |
<- |
CKY-R, CKY-I, OK_KEYX, 0, 0, EHAS, NIDP,
E{ID(R), ID(I), sKr}Ki, Nr, prf(Kir, ID(R)|ID(I)|Nr|Ni|EHAS) |
<- |
-> |
CKY-I, CKY-R, OK_KEYX, EHAS, NIDP,
prf(Kir, ID(I)|ID(R)|Ni|Nr|EHAS) |
-> |
Kir = prf(0, sKi | sKr)
KEYID = CKY-I|CKY-R
sKEYID = prf(Kir, CKY-I | CKY-R)
Стандартный режим отличается меньшим количеством информации передаваемым в каждом сообщении.
Приведем пример, в котором стороны используют обмен файлами куки, чтобы отложить создание состояния, используют полную секретность пересылки для защиты личности, а также шифрование с открытым ключом для аутентификации. Но в качестве метода аутентификации могут использоваться также цифровые подписи и предварительные общие ключи.
Ответчик рассматривает способность инициатора повторить CKY-R как слабое доказательство того, что сообщение исходит от «живого» ответчика в сети и ответчик связан с сетевым адресом инициатора. Инициатор делает аналогичные предположения, когда CKY-I повторяется инициатору.
Все сообщения должны иметь либо действительные файлы cookie, либо хотя бы один нулевой файл cookie. Если оба файла cookie равны нулю, это указывает на запрос файла cookie; если только куки-файл инициатора равен нулю, это ответ на запрос куки-файла.
Все неуказанные поля имеют нулевые значения:
Инициатор | Ответчик | |
-> | 0, 0, OK_KEYX | -> |
<- | 0, CKY-R, OK_KEYX | <- |
-> | CKY-I, CKY-R, OK_KEYX, GRP, g^x, EHAO | -> |
<- | CKY-R, CKY-I, OK_KEYX, GRP, g^y, EHAS | <- |
-> |
CKY-I, CKY-R, OK_KEYX, GRP, g^x, IDP,
ID(I), ID(R), E{Ni}Kr |
-> |
<- |
CKY-R, CKY-I, OK_KEYX, GRP, 0, 0, IDP,
E{Nr, Ni}Ki, ID(R), ID(I), prf(Kir, ID(R)|ID(I)|GRP|g^y|g^x|EHAS) |
<- |
-> |
CKY-I, CKY-R, OK_KEYX, GRP, 0, 0, IDP,
prf(Kir, ID(I)|ID(R)|GRP|g^x|g^y|EHAS) |
-> |
Kir = prf(0, Ni | Nr)
sKEYID = prf(Ni | Nr, g^xy | CKY-I | CKY-R)
Схема обмена в стандартном режиме:
Как и в случае с файлами cookie, каждая сторона рассматривает возможность удаленной стороны повторить значение Ni или Nr как доказательство того, что Ka, открытый ключ стороны а, говорит от имени удаленной стороны и устанавливает ее личность.
Отметим, что, хотя флаг IDP гарантирует, что удостоверения защищены общим ключом g^xy, сама аутентификация не зависит от g^xy. Важно, чтобы этапы аутентификации проверяли значения g^x и g^y, и поэтому крайне важно, чтобы аутентификация не включала в себя круговую зависимость от них. Третья сторона может вмешаться по схеме «человек посередине», чтобы убедить инициатора и ответчика использовать разные значения g^xy; хотя такая атака может привести к раскрытию личности перехватчику, аутентификация не удастся.
Одноразовые номера Ni и Nr используются для обеспечения дополнительного измерения секретности при получении сеансовых ключей. Это делает секретность ключа зависимой от двух разных проблем: проблемы дискретного логарифмирования в группе G и проблемы взлома схемы шифрования nonce. Если используется шифрование RSA, то эта вторая проблема примерно эквивалентна факторизации открытых ключей RSA как инициатора, так и ответчика.
Когда уже существует аутентифицированный KEYID и связанный с ним ключевой материал sKEYID, легко получить дополнительные KEYID и ключи с аналогичными атрибутами (GRP, EHAS и т. д.), используя только функции хеширования.
С другой стороны, аутентифицированный ключ может быть распределенным вручную ключом, который совместно используется инициатором и ответчиком через некоторые внешние по отношению к Oakley средства. Если метод распределения сформировал KEYID с использованием соответствующих уникальных значений для двух половин (CKY-I и CKY-R), то этот метод применим.
Далее в качестве идентификатора обмена ключами используется Oakley Quick Mode. Nonces передаются в полезной нагрузке аутентификации, а значение prf передается в полезной нагрузке аутентификации; Центр аутентификации - «None», а тип - «Pre-Shared».
Протокол:
Инициатор | Ответчик | |
-> | KEYID, INEWKRQ, Ni, prf(sKEYID, Ni) | -> |
<- | KEYID, INEWKRS, Nr, prf(sKEYID, 1|Nr|Ni) | <- |
-> | KEYID, INEWKRP, 0, prf(sKEYID, 0|Ni|Nr) | -> |
NKEYID = Ni | Nr
sNKEYID = prf(sKEYID, Ni | Nr)
Удостоверения и значения EHA, связанные с NKEYID, такие же, как и у KEYID. Каждая сторона должна проверить хеш-значения, прежде чем использовать новый ключ для любых целей.
Все поля сообщения OAKLEY соответствуют полезной нагрузке сообщения ISAKMP или компонентам полезной нагрузки.
CKY-I - ISAKMP заголовок
CKY-R - ISAKMP заголовок
MSGTYPE - Тип сообщения в ISAKMP заголовке
GRP - SA нагрузка, Раздел предложений
g^x - полезная нагрузка обмена ключами, закодированная как целое число переменной точности
g^y - полезная нагрузка обмена ключами, закодированная как целое число переменной точности
EHAO - полезная нагрузка SA, раздел предложений
EHAS - SA
IDP - бит в зарезервированом поле заголовка AUTH
ID(I) - AUTH нагрузка, поле идентификации
ID(R) - AUTH нагрузка, поле идентификации
Ni - AUTH нагрузка, поле одноразового номера
Nr - AUTH нагрузка, поле одноразового номера
S{...}Kx - AUTH нагрузка, поле данных
prf{K,...} - AUTH нагрузка, поле данных