следует ли аутентифицировать вектор инициализации в ipsec?

Я пытаюсь внедрить IPSEC в форме ESP в транспортном режиме с использованием aes в режиме galois/counter согласно RFC4106.

Я должен поместить вектор инициализации непосредственно перед зашифрованным текстом в преобразованном пакете.

Должен ли он быть частью аутентифицированных (но незашифрованных) данных? (Я предполагаю, что вы его не шифруете...)

Я не вижу, где это указано в RFC. Должно ли это быть очевидным, и если да, то почему?


ipsec cryptography aes-gcm
person John Lawrence Aspden    schedule 10.10.2011    source источник

Ответы (4)


arrow_upward
2
arrow_downward

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

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

Итак, чтобы закодировать пакет для ESP с помощью GCM, вы делаете следующее:

  • получить ключ
  • генерировать IV
  • рассчитать связанные данные (из SPI и порядкового номера)
  • получить открытый текст
  • передать IV, связанные данные, ключ, открытый текст в алгоритм GCM
  • получить зашифрованный текст и ICV из алгоритма GCM
  • отправить IV, зашифрованный текст и ICV
person Paŭlo Ebermann    schedule 10.10.2011
comment
Спасибо, это звучит очень правдоподобно. На самом деле это противоположно тому, что я считал очевидным ответом (да). Интересно, это вообще где-то указано? - person John Lawrence Aspden; 11.10.2011
comment
Для ESP AES-GCM ESP IV не совсем совпадает с IV GCM (или одноразовым номером). Таким образом, то, что вы передаете как IV в алгоритм GCM, на самом деле должно быть солью SA, связанной с ESP IV. Для каждого пакета регенерируется только ESP IV, соль постоянна для SA. - person salicideblock; 25.01.2017

arrow_upward
1
arrow_downward

Для AES-GCM-ESP IV (esp iv из 8 байтов) не является частью AAD. AAD — это просто заголовок ESP. Обратите внимание, что IV, который передается в AES_GCM, представляет собой конкатенацию соли (четыре байта) + iv (esp iv из 8 байт). Некоторые аппаратные криптографические механизмы принимают IV как 16 байтов, и в этом случае вам нужно дополнить последние четыре байта, чтобы они были 0x0.

Посмотрите этот документ, он довольно аккуратный http://csrc.nist.gov/groups/ST/toolkit/BCM/documents/proposedmodes/gcm/gcm-revised-spec.pdf

person user1967795    schedule 10.01.2013

arrow_upward
1
arrow_downward

Нет, вы не должны.

Это должно быть очевидно? Обычно да. Многие другие RFC для механизмов ESP включают тестовые векторы, чтобы развеять подобные вопросы. RFC4106 этого не делает. Это было замечено во время обсуждения, но не вошло в текст: https://www.ietf.org/mail-archive/text/ipsec/2005-08.mail

Однако есть черновик документа с тестовыми векторами: https://tools.ietf.org/html/draft-mcgrew-gcm-test-01 . Вы заметите, что IV (байты 4-11 "одноразового номера", 4956ed... в первом примере) включены открытым текстом в данные пакета. Они не включены ни в «открытый текст», ни в «aad», который представляет собой совокупность данных, аутентифицированных шифром GCM.

Учтите также, что IV для самого шифра GCM представляет собой конкатенацию соли и ESP IV, называемую «одноразовым номером», чтобы избежать двусмысленности. Соль получается из ключевого материала, согласованного во время IKE, поэтому она согласована между обеими конечными точками и постоянна для времени жизни SA.

person salicideblock    schedule 25.01.2017

arrow_upward
0
arrow_downward

По-видимому, оба очевидных ответа верны.

В соответствии с RFC 4543, в котором указывается ENCR_NULL_AUTH_AES_GMAC (аутентификация без шифрования), вы включаете IV.

Однако в том же RFC говорится, что для AES-GCM-ESP (шифрование и аутентификация) это не так.

Вооружившись этой информацией, теперь становится ясно, что это то, о чем RFC 4106 (в котором фактически указывается AES-GCM- ESP) тоже говорит, хотя сначала я интерпретировал это не так.

person John Lawrence Aspden    schedule 11.10.2011
comment
На самом деле нет: вектор инициализации — это отдельный ввод в режим GMAC (или GCM), а не часть дополнительных аутентифицированных данных. Таким образом, он каким-то образом аутентифицируется (поскольку изменение вектора инициализации даст другие результаты), но не является частью ввода AAD. - person Paŭlo Ebermann; 11.10.2011
comment
Пауло, спасибо за беспокойство, я немного новичок в этом и ценю помощь. Рисунок 4 в rfc 4543 выглядит так, как будто он говорит мне поместить iv в AAD. Я полагаю, что AES-GCM по-прежнему нуждается в IV, даже если он не шифрует, поэтому кажется, что в случае с GMAC он используется дважды. Что мне кажется ужасом в плане безопасности, но потом IANAC. Я неправильно читаю? - person John Lawrence Aspden; 11.10.2011
comment
Хм. Я думаю, что рисунок 4 вводит в заблуждение в этом отношении. Рисунок 3, с другой стороны, ясно показывает, что IV не включен в AAD. - person Paŭlo Ebermann; 11.10.2011
comment
Один из них, безусловно, вводит в заблуждение. Рисунок 3, похоже, вообще не включает IV. Но раздел 7, кажется, голосует за цифру 4. - person John Lawrence Aspden; 11.10.2011
comment
Ладно, теперь я должен сказать, что больше не уверен. Существует опечатка в разделе 7, которая также указывает на то, что цифра 4 правильная. Попробуйте и посмотрите, какая версия совместима с другими реализациями? - person Paŭlo Ebermann; 11.10.2011