До того как мы приступим непосредственно к внедрению IPsec VPN, поговорим о технологиях, на которые он будет опираться, предоставляя защиту трафику: ключи, шифрование, аутентификация пакетов, обмен ключами, методы аутентификации пользователей и устройств.
Ключи
Ключи используются в таких критически важных функциях VPN как: шифрование, проверка целостности пакета, аутентификация.
Ключи бывают двух видов – симметричные и асимметричные.
Симметричный ключ, это единый ключ, который используется для защиты информации. Алгоритм шифрования использует его и для шифрования, и для дешифрования, что делает подобные алгоритмы быстрыми, но менее криптостойкими. К таким алгоритмам относятся DES, 3DES, AES, RC4 и другие.
Устройства на двух концах VPN сессии должны знать о симметричном ключе, который будет использоваться в процессе перед тем, как защищать какую-либо информацию, что может быть достигнуто следующими путями:
- pre-shared ключи – обмен ключами, что называется, out-of-band
- с использованием защищенного соединения (catch-22 ситуация) – чтобы установить безопасное подключение вам нужны ключи, а чтобы получить ключи вам нужно безопасное соединение :)
Асимметричные ключи – это уже пара ключей, состоящая из открытых (public) и закрытых (private) ключей. Закрытый ключ, в отличии от открытого, держится в секрете и не сообщается никому другому. За формирование пары ключей отвечает специальный алгоритм.
В процессе шифрования между маршрутизаторами R1 и R2 устройства создают пару ключей, обмениваются открытыми ключами. R1 отправляет открытый ключ на R2, R2, используя его, шифрует информацию, которую следует отправить на R1, затем R1, используя закрытый ключ, расшифровывает полученную информацию. Даже если злодей получил открытый ключ расшифровать полезную нагрузку он все равно будет не в состоянии.
Примерами могут служить такие алгоритмы как RSA, DSA, DH.
Шифрование
Есть процесс трансформации информации в такую форму, из которой ее невозможно было бы обратно извлечь без знания ключа или ключей, которые использовались в процессе трансформации.
Процесс шифрования описывает какие ключи (симметричные или ассиметричные) будут использоваться. Не смотря на то, что устройства используют отдельные модули для разгрузки CPU, процесс шифрования ассиметричными ключами намного более требователен к ресурсам.
Алгоритмы шифрования DES/3DES и AES
DES/3DES изначально разработанный IBM алгоритм Lucifer, который в процессе модификаций превратился в стандарт. DES – блочный алгоритм шифрования с эффективной длинной ключа в 56 бит.
Из-за низкой криптостойкости на смену ему в 1999 был создан 3DES, суть которого состоит в том, что информация трижды прогоняется через алгоритм DES тремя разными 56ю битовыми ключами (результирующая эффективная длина ключа – 168 бит).
Преимуществами DES/3DES являются быстрая скорость шифрования и дешифрования, простота реализации алгоритмов с ПО и железе, однако на данный момент существую алгоритмы новее, которые и быстрее и безопаснее чем 3DES. AES, как пример.
AES (Advanced Encryption Standard) – так же является симметричным блочным шифром, поддерживающим длину ключа в 128, 192 и 256 бит. Является более щадящим к ресурсам чем тот же 3DES.
Аутентификация пакетов
Используется с целью проверки подлинности пакетов, а так же отвечает за аутентификацию источника информации.
Осуществляется это с помощью HMAC (Hashing Message Authentication Codes) функций, которые являются подмножеством хэш-функций. HMAC функции используют симметричный общий ключ, для создания определённого значения – fingerprint, чтобы исключить ситуацию когда злодей перехватывает пакет и с помощью одного лишь MD5 пытается подписать изменённую информацию.
Происходит это следующим образом:
- Источник берет информацию, ключ, известный получателю, и прогоняет все это дело через HMAC функцию.
- Выхлоп HMAC и есть цифровая подпись пакета – fingerprint (в IPsec VPN это называется Integrity Checksum Value – ICV).
- Источник отправляет информацию и fingerprint получателю.
- Получатель производит те же действия с информацией, что и отправитель в пункте 1.
- Если fingerprint полученный в процессе выполнения пункта 3 и fingerprint полученный в процессе выполнения пункта 4 совпадают, то все хорошо.
Примерами HMAC функций являются MD5 и SHA.
Применяется это повсеместно в протоколах динамической маршрутизации, ведь мало кому хочется, чтобы злодей нарушил связность, обновив таблицу маршрутизации неверной информацией, или того хуже объявил себя маршрутом по умолчанию.
Меня всегда интересовал другой вопрос – зачем проверять уже зашифрованное сообщение?
Как оказалось HMAC алгоритмы используют во много раз меньше ресурсов, из-за чего вызвать отказ в обслуживании с помощью «левых» пакетов, заставляя оборудование их расшифровывать будет значительно труднее. Поясню на примере:
Если в процессе сверки на стадии 4 выяснится что fingerprint не соответствует зашифрованному пакету, то и расшифровывать его не надо.
Обмен общим HMAC ключом
Понятное дело, нельзя отправить этот ключ открытым текстом, так как теряется весь смысл HMAC. Опять же, можно использовать out-of-band обмен или обмен ключами по уже зашифрованному каналу.
HMAC fingerprint и NAT/PAT
Помните, в предыдущей статье, мы говорили о проблемах преодоления NAT/PAT IPsec протоколами AH и ESP? Информация, которая может изменится в процессе трансляции (IP, TTL, TOS поля, номера портов) просто не включается в алгоритм формирования HMAC fingerprint.
Обмен ключами
Помните дилемму? Чтобы начать обмен информацией по зашифрованному каналу, надо сначала обменяться ключами для создания зашифрованного канала и ключи, желательно, передать в сохранности. Читай – не обычным текстом. Сделать это можно с помощью:
- Pre-shared key
- Один из вариантов решения проблемы – использовать заранее оговоренные ключи и передать их администраторам другого узла по телефону или почте, или же вбить руками самому тем или иным образом.
- Уже существующих безопасных соединений
- Сходить на железку по SSH.
- Зашифровать ключ с помощью ассиметричных алгоритмов шифрования.
Но тут встает другая проблема – жадные до ресурсов ассиметричные алгоритмы шифрования при передаче большого объема траффика позволят устройству обрабатывать потом в разы меньший поток, чем при использовании симметричных, по этому… мы будем использовать ассиметричные алгоритмы шифрования для того, чтобы обмениваться симметричными ключами :)
Алгоритм Diffie-Hellman (DH)
DH обычно не используется для шифрования данных, однако, как указано выше, используется различными реализациями VPN для обмена общими ключами через сети с низким уровнем доверия (интернет).
Как он работает:
- Каждое из двух устройств рассказывает информацию, которая поможет им создать собственные пары открытых и закрытых ключей. Этот шаг важен потому, что DH поддерживает разные длины ключей, который называются DH groups. Как только устройства на обоих концах согласовали длину ключа создаются пары открытых и закрытых ключей.
- Каждое из устройств обменивается открытыми ключами с соседом.
- Каждое из устройств берет свой закрытый ключ и открытый ключ соседа и запускает алгоритм DH.
- Фишка алгоритма в том, что не смотря на то, что информация различается на обоих концах результат будет одинаков.
- Теперь можно зашифровать симметричных ключ с помощью ключа, полученного в процессе работы алгоритма DH и отправить его соседу не беспокоясь о том, что он может быть расшифрован 3ей стороной.
- Когда принимающая сторона получила симметричный ключ в целостности и сохранности и расшифровала его с помощью алгоритма DH можно начинать обмен данными, с использованием быстрых симметричных алгоритмов шифрования.
Некоторые DH группы и длина ключа:
- DH 1 – 768 бит
- DH 2 – 1024 бит
- DH 5 – 1536 бит
- DH 14 – 2048 бит
- DH 15 – 3072 бит
Одно из преимуществ ассиметричных алгоритмов состоит в том, что закрытый ключ никогда не передается по сети, по этому злодей, даже получив доступ к открытому ключу будет не в состоянии расшифровать передаваемую информацию. Однако такая передача уязвима к атакам типа «человек посередине» («man in the middle»).
К примеру, R1 хочет передать зашифрованный симметричный ключ R2, однако вместо R2 на предложение инициировать обмен ключами по алгоритму DH отвечает злоумышленник. Другими словами помимо обеспечения безопасности передачи по алгоритму DH необходимо еще каким-то образом ответит на вопрос – «является ли R2 тем, за кого он себя выдает»?
Аутентификация устройств встречается и в l2l и в remote access VPN. Осуществляется либо с помощью pre-shared ключей, либо с помощью цифровых сертификатов.
Аутентификация пользователей свойственна именно remote access VPN-ам, обычно используется совместно с аутентификацией устройств. Осуществляется с помощью pre-shared (обычный пароль) ключей и сервисам подобным OTP (one time password).
Аутентификация устройств: pre-shared симметричные ключи
Наиболее простой и часто встречающийся случай когда устройства проводят аутентификацию друг друга с помощью pre-shared ключей, обмен которыми был произведен заранее, out-of-band. Процесс аутентификации использует либо алгоритм шифрования, либо HMAC функцию.
И в том и в другом случае берется какой-то набор сведений об устройствах (IP, hostname, serial no. + pre-shared key), прогоняется через алгоритм шифрования или HMAC функцию и отправляется соседу. Сосед расшифровывает или прогоняется через HMAC и сравнивается с fingerprint. Если все совпадает, то факт соседства можно считать установленным.
Аутентификация устройств: pre-shared асимметричные ключи
С ассиметричными ключами так же имеет место обмен out-of-band, только вместо pre-shared ключей соседи будут меняться открытыми ключами. В конечном итоге маршрутизаторы-соседи R1 и R2 будут иметь следующий набор:
R1: R1 public key, R1 private key, R2 public key
R2: R2 public key, R2 private key, R1 public key
Далее, к примеру, R1 берет информацию о себе, R1 private key и шифруя это, передает в последствии in-band на R2, где R2 расшифровывает информацию с использованием R1 public key.
Еще одним методом аутентификации является аутентификация с использованием цифровых сертификатов. Я на нем подробно останавливаться не буду.