#cryptography #ipsec #aes-gcm
#криптография #ipsec #aes-gcm
Вопрос:
Я пытаюсь реализовать IPSEC в форме ESP в транспортном режиме с использованием aes в режиме галуа / счетчика, согласно RFC4106.
Я должен поместить вектор инициализации непосредственно перед зашифрованным текстом в преобразованном пакете.
Должен ли он быть частью аутентифицированных (но не зашифрованных) данных? (Я предполагаю, что вы не шифруете его …)
Я не вижу, где RFC указывает это. Должно ли это быть очевидным, и если да, то почему?
Ответ №1:
Насколько я понимаю определение GCM, нет необходимости включать вектор инициализации в связанные данные — использование разных векторов инициализации в любом случае даст как разные результаты шифрования, так и разные значения проверки целостности.
Это преимущество использования комбинированного режима шифрования с аутентификацией, вам не нужно заботиться о включении векторов инициализации в MAC.
Итак, чтобы закодировать пакет для ESP с помощью GCM, вы делаете это:
- извлечение ключа
- сгенерируйте IV
- вычислите связанные данные (из SPI и порядкового номера)
- получить открытый текст
- передайте IV, связанные данные, ключ, открытый текст алгоритму GCM
- получить зашифрованный текст и ICV из алгоритма GCM
- отправка IV, зашифрованного текста и ICV
Комментарии:
1. Спасибо, это звучит очень правдоподобно. На самом деле это противоположно тому, что я считал очевидным ответом («да»). Интересно, действительно ли это где-нибудь указано?
2. Для AES-GCM ESP ESP IV не совсем совпадает с IV GCM (или «одноразовым номером»). Итак, то, что вы передаете как «IV» в алгоритм GCM, на самом деле должно быть «соль SA, связанная с ESP IV». Для каждого пакета восстанавливается только ESP IV, соль постоянна для SA.
Ответ №2:
Для AES-GCM-ESP IV (esp iv объемом 8 байт) не является частью AAD. AAD — это просто заголовок ESP. Обратите внимание, что IV, который передается в AES_GCM, представляет собой конкатенацию соли (четыре байта) iv (особенно iv из 8 байт). Некоторые криптосистемы hw принимают IV за 16 байт, и в этом случае вам нужно дополнить последние четыре байта, чтобы они были равны 0x0.
Проверьте этот документ, он довольно аккуратный http://csrc.nist.gov/groups/ST/toolkit/BCM/documents/proposedmodes/gcm/gcm-revised-spec.pdf
Ответ №3:
Нет, вы не должны.
Должно ли это быть очевидным? Обычно да. Многие другие RFC для механизмов ESP включают тестовые векторы, чтобы рассеять такого рода вопросы. RFC4106 этого не делает. Это было замечено во время обсуждения, но они не попали в текст: https://www.ietf.org/mail-archive/text/ipsec/2005-08.mail
Однако существует черновик документа с тестовыми векторами: https://datatracker.ietf.org/doc/html/draft-mcgrew-gcm-test-01 . Вы заметите, что IV (байты 4-11 «одноразового номера», 4956ed... в первом примере) включены открытым текстом в данные пакета. Они не включены ни в «открытый текст», ни в «aad», который представляет собой общее количество данных, аутентифицированных с помощью шифра GCM.
Учтите также, что IV для самого шифра GCM представляет собой конкатенацию соли и ESP IV — так называемый «одноразовый номер», чтобы избежать двусмысленности. Соль получается из ключевого материала, согласованного во время IKE, поэтому она согласована между обеими конечными точками и постоянна для срока службы SA.
Ответ №4:
По-видимому, оба очевидных ответа верны.
В соответствии с RFC 4543, в котором указывается ENCR_NULL_AUTH_AES_GMAC (аутентификация без шифрования), вы включаете IV.
Однако в том же RFC говорится, что для AES-GCM-ESP (шифрование и аутентификация) вы этого не делаете.
Вооружившись этой информацией, теперь ясно, что это то, что говорится в RFC 4106 (который фактически определяет AES-GCM-ESP), хотя сначала я интерпретировал это не так.
Комментарии:
1. На самом деле, нет: вектор инициализации является отдельным входом в режим GMAC (или GCM), а не частью дополнительных аутентифицированных данных . Таким образом, он каким-то образом аутентифицируется (поскольку изменение вектора инициализации даст разные результаты), но он не является частью ввода AAD.
2. Пауло, спасибо за беспокойство, я немного новичок в этом и ценю помощь. Рисунок 4 в rfc 4543 выглядит так, как будто он говорит мне поместить iv в AAD. Я полагаю, что AES-GCM все еще нуждается в IV, даже если он не шифрует, поэтому кажется, что в случае GMAC это происходит дважды. Для меня это выглядит как ужас безопасности, но затем IANAC. Я неправильно читаю?
3. Ага. Я думаю, что рисунок 4 вводит в заблуждение в этом отношении. С другой стороны, на рисунке 3 ясно показано, что IV не включен в AAD.
4. Один из них, безусловно, вводит в заблуждение. На рисунке 3, похоже, вообще нет IV. Но раздел 7, похоже, соответствует рисунку 4.
5. Хорошо, теперь я должен сказать, что я больше не уверен. В разделе 7 есть ошибка , которая также, по-видимому, указывает на правильность рисунка 4. Попробуйте и посмотрите, какая версия взаимодействует с другими реализациями?