вы должны аутентифицировать вектор инициализации в ipsec? - PullRequest
Новая
       99

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

1 голос
/ 10 октября 2011

Я пытаюсь реализовать IPSEC в форме ESP в транспортном режиме с использованием aes в режиме галуа / счетчика, согласно RFC4106.

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

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

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

Ответы [ 4 ]

2 голосов
/ 11 октября 2011

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

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

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

  • получить ключ
  • генерирует IV
  • вычисление связанных данных (из SPI и порядкового номера)
  • получить открытый текст
  • проход IV, связанные данные, ключ, открытый текст для алгоритма GCM
  • получить зашифрованный текст и ICV из алгоритма GCM
  • отправить IV, шифротекст и ICV
1 голос
/ 25 января 2017

Нет, не стоит.

Должно ли это быть очевидно? Обычно да. Многие другие 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 «nonce», 4956ed... в первом примере) включены cleartext в данные пакета. Они не включены ни в «открытый текст», ни в «aad», что представляет собой сумму данных, аутентифицированных шифром GCM.

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

1 голос
/ 10 января 2013

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

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

0 голосов
/ 11 октября 2011

Очевидно, что оба очевидных ответа верны.

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

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

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

...