Что: 6981890b40135155d3c9eff9d09ace2181c1f28c
Когда: 2020-02-28 12:54:08+03:00
Темы: ipsec
Серьёзные замечания и опасения по поводу статьи об if_ipsec
https://victor-sudakov.livejournal.com/456221.html
Автору я отправил пару писем, но... судя по логам почтового сервера,
одно точно не дошло (по неизвестной мне прчине), другое, скорее всего,
тоже. Решил вот опубликовать и тут свои опасения:
> Но, повторюсь, может быть вам достаточно будет (в зависимости от вашей
> модели угроз) сделать всё на статических ключах, как описано в мануале,
> тогда схема получается железобетонная по надежности и не требует
> стороннего софта.
Боюсь, что всё как-раз совершенно наоборот -- безопасность такой системы
практически нулевая. Через setkey задаётся статический симметричный ключ
*шифрования* для ESP, а также его SPI (просто идентификационный номер
сессии, грубо говоря). Если посмотреть на то, как ESP шифруется в
AES-GCM режиме (а стоит использовать именно его на современном amd64
железе из-за аппаратного ускорения AES-NI в процессорах, поддерживаемым
FreeBSD), то https://tools.ietf.org/html/rfc4106
у нас имеется AES-GCM функция, на вход которой подаётся ключ, nonce,
открытый текст, additional associated data (AAD). GCM устроен так (как и
почти все современные AEAD шифры), что nonce ОБЯЗАН ни в коем случае не
использоваться дважды -- иначе полностью его безопасность на нуле, так
как это будет равносильно двойному использованию одноразового
шифроблокнота. В принципе, nonce можно просто сделать счётчиком -- это
нечто, что никогда не должно повторятся. В ESP AES-GCM RFC показано что
nonce создаётся как salt + IV. IV на практике в FreeBSD является
действительно счётчиком, хранимым внутри SA. salt задаётся вместе с
ключом. Отрывок из man setkey:
The following is the list of encryption algorithms that can be used as
the ealgo in the -E ealgo of the protocol parameter:
algorithm keylen (bits) comment
[...]
aes-ctr 160/224/288 draft-ietf-ipsec-ciph-aes-ctr-03
aes-gcm-16 160/224/288 rfc4106
сам по себе AES принимает ключи в 128, 192 или 256 бит, но тут задаётся
160/224/288 -- это как-раз 32 бита salt.
Так вот если просто так задать этот SA через setkey, но каждый раз,
когда SA устанавливается в ядро, оно имеет абсолютно точно такие же
криптографические параметры: точно такой же ключ, соль, вектор
инициализации (счётчик установленный в ноль). В итоге на практике,
каждая переустановка в ядро статического SA равносильна двойному
использованию одноразового шифроблокнота, переиспользованию nonce
который ОБЯЗАН (это чуть ли не единственное требование к GCM режиму
жёсткое, полностью нивелирующее его безопасность в случае нарушения).
Фатальность переиспользования nonce такова, что не просто какие-то
только спецслужбы смогут дешифровать трафик, а просто сосед Вася,
перехватывая пакеты и делая XOR между ними, будет получать XOR между
открытыми текстами.
Если гарантировать, что всё же хотя бы соль будет меняться (например это
тоже будет счётчиком) при каждом вызове setkey, то проблем не будет. Но
какова вероятность, что делая это руками, случайно не будет
переиспользоваться один и тот же salt+key, что человек не ошибётся?
Использование strongSwan/racoon/whatever как-раз гарантирует что
параметры SA никогда не повторятся.
Это не специфика только для GCM режима -- аналогичные требования к nonce
и у ChaCha20-Poly1305 режиму, и к нашему MGM ГОСТовому режиму (который в
IPsec ESP, IKEv2, TLS 1.3 используется ГОСТовых).
Если в гипотетической системе нет возможности хранить состояние
счётчика, то в качестве вектора инициализации можно было бы передавать
каждый раз некий random. Но, если мы шифруем на скоростях в гигабиты,
десятки гигабит, то это надо быстро и очень много этого random
генерировать -- тоже не простая задача. А если рассматривать конкретно
ESP AES-GCM, то для IV там всего 64-бит отведено, что недостаточно для
того чтобы туда засовывать рандом -- вызова вероятность коллизии и
повторения значения. Например в шифрах Salsa20/ChaCha20 тоже
используется 64-бит nonce, но есть XSalsa20/XChaCha20 варианты этих
шифров с расширенным nonce-ом до 192-х бит, как-раз для того чтобы там
можно было использовать не счётчик, а достаточно большой рандом.
А ещё в AEAD режимах ESP есть другая забота: AAD (Additional
Authenticated Data), который в AES-GCM (в ГОСТовом MGM аналогично, как и
в ChaCha20-Poly1305) состоит из SPI+sequence number ESP пакета. Sequence
number передаётся с каждым ESP пакетом и имеет размер всего в 32-бит.
Это значит что через 2**32 пакетов, значение SPI+SEQ повторится и будет
повторён AAD. Это, в принципе, не настолько фатально как повторение
nonce, но всё-равно понижает уровень безопасности аутентичности
сообщений. Для ESP уже давно придумали такую технологию как ESN
(extended sequence number) -- sequence number при этом просто увеличен
до 64-х бит, но передаются в ESP пакете по сети всё-равно только
нижняя 32-х битная половина. Это решает проблему (2**64 на практике
сложно преодолеть в пределах одной SA-сессии), но FreeBSD не
поддерживает ESN, в отличии от GNU/Linux. Поэтому за количеством пакетов
переданных в пределах одной SA сессии надо постоянно следить и менять
SPI (фактически устанавливать новый SA). Опять же, если бы за этим
следил человек, то высока вероятность что не уследит/забудет. IKE-демоны
в том числе следят и за этим, регулярно обновляя SA.
Использование статического ключа *аутентификации* (PSK) (безусловно при
хорошем алгоритме/протоколе этой аутентификации (в IKEv1/v2 с этим
проблем нет)) -- железобетонно надёжно. Но ключа *шифрования* -- ни в
коем случае, только есл�� это не используется для одноразовой IPsec
сессии с относительно небольшим количеством переданных пакетов/трафика.
Сгенерирован: SGBlog 0.34.0