Безопасность на сетевом уровне: IP SEC

Фаза I: основной режим

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

В третьих и четвертых сообщениях инициатор и респондент обычно обмениваются своими полуключами ( gⁱ и g^r метода Диффи-Хеллмана) и их nonce (для защиты ответа). В некоторых методах обмениваются другой информацией, о которой мы поговорим позже. Обратите внимание, что полуключи и nonce не передаются с первыми двумя сообщениями, потому что две стороны должны сначала получить гарантию, что засоряющая атака невозможна.

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

SKYID = prf (предварительный совместный ключ, N-I | N-R)              (метод предварительного совместного ключа)
SKYID = prf(N-I | N-R, gir)                                              (метод открытого ключа)
SKYID = prf( (hash (N-I | N-R), Cookie -I | Cookie -R)                          (цифровая подпись)

Другая общая секретность вычисляется следующим образом:

SKYID_d = prf( (SKEYID, gi r| Cookie -I | Cookie -R| 0)
SKYID_a = prf( (SKEYID, SKEYID_d | gi r| Cookie -I | Cookie -R| 1)
SKYID_e = prf( (SKEYID, SKEYID_a | gi r| Cookie -I | Cookie -R| 2)

SKEYID_d (derived - производный ключ) - ключ для создания других ключей. SKEYID_a - ключ аутентификации, и SKEYID_e применяется для ключа шифрования; обе эти секретности используются в течение фазы переговоров. Первый параметр ( SKEYID ) вычисляется для каждого метода обмена ключами отдельно. Второй параметр - конкатенация различных данных. Обратите внимание, ключ для prf - всегда SKEYID.

Эти две стороны также вычисляют два дайджеста хэширования, HASH-I и HASH-R, которые используются в главном режиме трех из этих четырех методов. Вычисления показаны ниже:

HASH-I = prf( (SKEYID, KE-I | KE-R | Cookie -I | Cookie -R |SA-I | ID-I)
HASH-R = prf( (SKEYID, KE-I | KE-R | Cookie -I | Cookie -R |SA-I | ID-R)

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

После вычисления ключей и хэширования каждая сторона передает хэш другой стороне, чтобы подтвердить свою подлинность. Инициатор передает HASH-I респонденту как доказательство, что она - Алиса. Только Алиса знает секретность аутентификации, и только она может вычислить HASH-I. Если HASH-I, вычисленный Бобом, соответствует HASH-I, посланному Алисой, она аутентифицирована. Тем же самым способом Боб может подтвердить свою подлинность Алисе, посылая HASH-R.

Обратите внимание, что здесь есть одна тонкость. Когда Боб вычисляет HASH I, он нуждается в ID Алисы, и наоборот. В некоторых методах ID передают с помощью предыдущих сообщений; в других - с хэшем либо с хэшем и с ID, зашифрованным SKEYID_e.

Метод предварительного совместного ключа

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

Рис. 8.20. Главный режим метода с предварительным совместным ключом.

В первых двух сообщениях инициатор и респондент обмениваются cookies (в общем заголовке и параметрах SA ). В следующих двух сообщениях они обмениваются полуключами и nonces (см. "Управление ключами" ). Теперь эти две стороны могут создать SKEYID и два ключевых хэша ( HASH-I и HASH-R ). В пятом и шестом сообщениях две стороны обмениваются созданными хэшами и их ID. Чтобы защищать ID и хэши, последние два сообщения зашифрованы с SKEYID_e.

Обратите внимание, что предварительный совместный ключ обеспечивает секретность между Алисой (инициатором) и Бобом (респондентом). Ева (злоумышленник) не имеет доступа к этому ключу. Ева не может создать SKEYID и поэтому не может создать ни HASH-I, ни HASH -R. Обратите внимание также, что обмен ID должен быть сделан в сообщениях 5 и 6, чтобы обеспечить вычисление хэша.

С этим методом есть одна проблема. Боб не может расшифровать сообщение, если он не знает предварительный совместный ключ, - то есть он должен знать, кто Алиса (знать ее ID ). Но ID Алисы зашифрован в сообщении 5. Разработчик этого метода утверждает, что ID в этом случае должен быть в адресе каждой стороны.

Это - не проблема, если Алиса находится в постоянном хосте (адрес IP установлен). Однако если Алиса двигается от одной сети к другой, это уже проблема.

Первоначальный метод открытого ключа

В первоначальном методе открытого ключа инициатор и респондент доказывают их подлинность, показывая, что они обладают секретным ключом, связанным с их объявленным открытым ключом. рис. 8.21 показывает обмен сообщениями при использовании метода первоначального открытого ключа.

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

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

Рис. 8.21. Главный режим метода с первоначальным открытым ключом.

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

Пересмотренный метод открытого ключа

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

Рис. 8.22. Главный режим метода с пересмотренным открытым ключом.

Обратите внимание, что два временных секретных ключа созданы из хэша nonce и cookies. Инициатор использует открытый ключ респондента, чтобы передать его nonce. Респондент дешифрирует nonce и вычисляет временный ключ инициатора, после чего могут быть расшифрованы полуключ, ID и дополнительный сертификат. Два временных ключа засекречивания, K-I и K-R, вычисляются следующим образом:

K-I = prf(N - I, Cookie-I)
K-R = prf(N - R, Cookie-R)

Метод цифровой подписи

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

Обратите внимание, что в этом методе передача сертификата является необязательной операцией. Сертификат можно передать, потому что он может быть зашифрован SKEYID_e, который не зависит от ключа подписи. В сообщении 5 инициатор подписывает всю информацию обмена в сообщениях 1-4 своим ключом подписи. Респондент верифицирует подпись, используя открытый ключ инициатора, который подтверждает подлинность инициатора. Аналогично, в сообщении 6 респондент подписывает всю информацию обмена своим ключом подписи. Инициатор верифицирует подпись.

Рис. 8.23. Главный режим метода цифровой подписи