Что: 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 сессии с относительно небольшим количеством переданных пакетов/трафика. ------------------------------------------------------------------------ оставить комментарий: mailto:comment@blog.stargrave.org?subject=Re:%20%D0%A1%D0%B5%D1%80%D1%8C%D1%91%D0%B7%D0%BD%D1%8B%D0%B5%20%D0%B7%D0%B0%D0%BC%D0%B5%D1%87%D0%B0%D0%BD%D0%B8%D1%8F%20%D0%B8%20%D0%BE%D0%BF%D0%B0%D1%81%D0%B5%D0%BD%D0%B8%D1%8F%20%D0%BF%D0%BE%20%D0%BF%D0%BE%D0%B2%D0%BE%D0%B4%D1%83%20%D1%81%D1%82%D0%B0%D1%82%D1%8C%D0%B8%20%D0%BE%D0%B1%20if_ipsec%20%286981890b40135155d3c9eff9d09ace2181c1f28c%29 ------------------------------------------------------------------------ Сгенерирован: SGBlog 0.34.0