Crypto Systems

Для организации крайне важно защищать потоки информации, следующие из внутренней сети к своим удалённым подразделениям, удалённым сотрудникам или партнёрам.

4 элемента безопасной коммуникации:

1. Целостность данных (data integrity)
   Данные должны гарантированно дойти до получателя в неизменном (оригинальном) виде. Другими словами, данные после отправки и до получения не могут быть чем-то подложены (заменены). Целостность гарантируется применением алгоритмов хэширования MD5 или SHA. Любые изменения данных неизменно ведут к изменению хэша.

2. Аутентичность или подлинность (authenticity)
   Данные должны гарантированно исходить от отправителя, другими словами, реквизиты отправителя не могут быть подделаны. Подлинность проверяется сверкой HMAC (hash message authentication code) последовательностей.

3. Конфиденциальность (confidentiality)
   Отправляемые данные могут быть прочтены только получателями и никем другим. Если сообщение в ходе передачи перехватывается 3-й стороной, то прочитать сообщение невозможно. Конфиденциальность обеспечивается шифрованием (симметричным или асимметричным).

4. Безотказность авторства (non-repudiation)
   Любой отправитель после отправки сообщения не имеет права отказаться от факта отправки. Данный принцип предполагает наличие уникальных характеристик (подпись) каждого отправителя, содержащихся в отправляемом сообщении.

Криптография может быть использована везде, где присутствует передача данных. Сегодняшняя тенденция заключается в том, что абсолютно ВСЕ коммуникации шифруются.

Целостность данных

Hash-функции используются для гарантии целостности сообщения. 2 разных сообщения дают разные хэши (контрольные суммы).

Hash - это дистиллят сообщения, он же digest, он же message digest (MD), он же fingerprint или отпечаток.

Hash function — простая в одну сторону (расчет хэша), и сложная в обратную (по хэшу найти оригинал). Пример с набором красок, которые являются сообщением, краски смешали в определённых пропорциях — получили хэш.

Хэширование применяется в:

• ipsec tunnels
• цифровая подпись кода
• версионировании файлов при разработке
• торрент-файлы
• RAID массивы данных

Hash function должна быть без коллизий, то есть 2 разных сообщения никогда не должны давать одинаковый hash.

Hashing спасает от непреднамеренных изменений или ошибок во время передачи, однако, не спасает от преднамеренного или умышленного изменения сообщения. Ведь из сообщения, которое перехвачено, при известной хэш-функции может быть получен новый хэш, добавленный в конец сообщения. И уже измененное сообщение, полученное конечным получателем, будет абсолютно валидным. Защита от умышленного изменения сообщения, или MITM атак, — задача аутентификации (сообщение должно быть действительно получено от отправителя, а не злоумышленника, который им представился).

Алгоритмы хэширования:

• MD5 (128bit) — уязвим, используется в случае невозможности использования SHA-1/SHA-2
• SHA-1 (160bit),
• SHA-2 (SHA-224, SHA-256, SHA-384, SHA-512)

На сайте https://cisco.com в разделе загрузок для каждого файла есть рассчитанный хэш.

Аутентичность или подлинность (authenticity)

Итак, хэш в чистом виде не спасает от подмены сообщения.

HMAC

Чтобы решить задачу подлинности сообщения, вводится понятие HMAC (keyed-hash message authentication code). HMAC использует дополнительный параметр при расчете хэша - отдельный секретный ключ. Данный секретный ключ известен ТОЛЬКО отправителю и получателю, и, следовательно, только отправитель и получатель могут рассчитать верный HMAC. Как это выглядит на картинке. Отправитель добавляет к оригинальному сообщению ключ и рассчитывает хэш. Полученный хэш добавляется в конец оригинального сообщения и отправляется получателю. Получатель, уже имея ключ, выделяет сообщение (еще неизвестно, оригинальное оно или нет) и рассчитывает из него и ключа новый хэш. Если принятый хэш соответствует хэшу, значит сообщение оригинальное.

Если сообщение перехвачено и изменено, то рассчитать правильный хэш без знания секретного ключа невозможно. Таким образом гарантируется и подлинность отправителя, и целостность сообщения. Однако, теперь стоит задача предварительного обмена ключами по закрытому каналу.

Применение HMAC – везде, где необходима аутентификация:

• PPP/PPPoE CHAP
• EIGRP/OSPF/BGP/RIP updates authentication
• RADIUS/TACACS session
• IPsec tunnels

Альтернативой HMAC являются цифровые подписи (digital signatures).

Цифровая подпись или электронная цифровая подпись (ЭЦП).

Когда мы что-то подписываем, это означает, что документ является действительным, поскольку наша подпись уникальна и не может быть кем-то повторена, а, следовательно, документу и подписи можно безусловно доверять.

В криптографии цифровая подпись обеспечивает те же требования, что и подпись каллиграфическая:

• подлинность
• целостность
• невозможность отказаться от подписанного (безотзывность)

ЭЦП — это неотъемлемая часть электронного документа (реквизит), которая связана с автором документа и самим документом с помощью криптографических алгоритмов.

ЭЦП обеспечивает:

• аутентичность (подлинность) отправителя или автора
• неотрицаемость факта подписи сообщения
• целостность сообщения с момента его цифровой подписи

Свойства цифровой подписи:

• невозможно подделать, поэтому сообщения, подписанные цифровой подписью могут быть подписаны только её владельцем
• неизменность сообщения, так как после подписи сообщения, невозможно изменить сообщение без нарушения цифровой подписи (отпечатка) документа.
• подпись — уникальная часть сообщения, и точно такая же подпись не может быть использована для другого документа
• юридически подпись нельзя опровергнуть

Применение:

• подпись программы — подтверждение аутентичности издателя программы
• цифровые сертификаты — аутентичность интернет-сайта, или некой сущности в Интернет

Конфиденциальность (confidentiality)

Хэширование или HMAC могут обеспечить подлинность и целостность сообщения. Однако, при перехвате сообщения его всё ещё можно прочитать, если оно передаётся в открытом виде. На помощь приходит шифрование (encryption). Операция шифрования согласно неким правилам (алгоритмам) преобразует оригинальное сообщение, представленное в виде 0 и 1, в новое уже нечитаемое сообщение. Нечитаемость достигается преобразованием каждого блока оригинального сообщения с помощью ключа шифрования, также представленного в виде 0 и 1.

Какой алгоритм шифрования выбрать?

Критерии выбора:

• Степень доверия. Как долго алгоритм на рынке? Насколько он проверен?
• Способность сопротивляться brute-force
• Возможность использовать ключи с переменной длиной
• Экспортно-импортные ограничения

Существует 2 больших класса алгоритмов шифрования:

• симметричные
• асимметричные

Симметричные алгоритмы

Используются при небольшом количестве участников обмена информацией, которые заранее друг другу известны. В таких алгоритмах ключ для шифрования и дешифрования используется один и тот же. Секретный ключ называется pre-shared key (PSK) и раздаётся всем участникам до начала обмена сообщениями по отдельному закрытому каналу. Поэтому можно использовать более короткие ключи, что ускоряет их генерацию и дальнейшее управление. Так как ключи короткие, то такие алгоритмы шифруют и дешифруют очень быстро. Подобные алгоритмы весьма дешево реализуются на ASIC-микросхемах, что обусловило появление аппаратного шифрования (hardware accelerated encryption).

Симметричные Алгоритмы Шифрования:

• DES
• 3DES
• AES
• SEAL
• RC

Длина ключей у современных симметричных алгоритмов шифрования составляет 40-256 бит.

Применяются для шифрования каналов связи, где нужно много и быстро шифровать/дешифровать – в туннелях, которые объединяют сети (VPN).

Ещё одна классификация симметричных алгоритмов шифрования:

• Блочные — исходное сообщение "режется" на блоки по несколько байт и каждый блок шифруется отдельно.
• Потоковые — это блочный алгоритм шифрования, в котором размер блока равен 1 бит.

Асимметричные алгоритмы

Асимметричные алгоритмы (aka PKI, алгоритмы открытого ключа). Используются при большом количестве участников, которые заранее друг другу неизвестны. Для шифрования и дешифрования используются разные ключи (открытый и закрытый), которые составляют комплементарную математическую пару. По одному известному ключу, входящему в такую пару, невозможно за разумное время рассчитать второй ключ. Генерация и обмен ключами происходит по недоверенным (открытым) каналам до начала обмена информацией. Ввиду данного факта длина ключей сотни-тысячи бит. Поэтому шифрование/дешифрование происходит долго.

Длина ключей алгоритмов симметричного шифрования составляет 512-4096 бит.

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

• Интернет-магазины
• кассовая онлайн-система
• интернет-банкинг
• страховые сервисы
• SSL (TLS)
• SSH
• PGP

Быстродействие асимметричных алгоритмов очень низкое, поскольку в процессе шифрования вовлечены сложные математические вычисления (факторинг - разложение на множители), над очень длинными числами.

Симметричные алгоритмы:

• DH (Diffie-Hellman)
• DSS
• DSA
• RSA
• ElGamal
• Elliptic curves techniques

Обмен ключами

Неоднократно выше возникал вопрос о том, что ключами для HMAC или для асимметричного шифрования заранее надо обменяться. Значит, для передачи нужно строить еще один закрытый канал с шифрованием для обмена ключами шифрования, чтобы использовать их в шифровании для обмена полезными данными! Ок? Звучит страшно. Разумеется, так никто делать не будет. В случае с симметричным шифрованием, когда количество участников обмена заранее известно и это 10-20 человек, то можно с каждым созвониться по телефону и сообщить каждому из них ваш общий секретный ключ, но и телефоны могут прослушиваться Но в случае с асимметричным шифрованием, миллиону пользователей сообщить каждому отдельный секретный ключ невозможно. Нужен иной механизм генерации и обмена ключевой информацией. Такой механизм есть, и это – алгоритм Diffie-Hellman!

Diffie-Hellman (DH, или эпонимно известный как алгоритм Диффи-Хеллмана) — это асимметричный алгоритм (это не алгоритм шифрования), для генерации общего секретного ключа между двумя компьютерами, которые друг другу заранее неизвестны, через незащищенный канал (который могут прослушивать). Полученный общий секретный ключ далее можно использовать для симметричного шифрования. При этом полученный общий секрет никогда не передаётся через открытый канал.

Алгоритмы DH применяются в:

• IPsec VPN
• SSL/TLS шифрование в Интернет
• SSH

Вообще шифрование используется на разных уровнях OSI:

• L7 — на уровне приложений (smtps, pop3s, Telegram, sql session encryption)
• L5 — session layer (SSL, TLS)
• L3 — IPsec VPN
• L2 — macsec

Мы делаем упор на L3, и на L5.

Управление ключами (ключевой информацией).

Как сделать систему защищенной?! Есть 2 подхода:

1. Создать секретный алгоритм
2. Придумать очень сложный секретный ключ

Создать секретный алгоритм

В этом подходе на первый взгляд всё хорошо. Создали суперсекретный алгоритм шифрования и можем свободно им пользоваться. Однако, никто не гарантирует, что авторы алгоритма не заложили на своих наработках и зашить в алгоритм пару уязвимостей, которые позже можно продать в darknet. И даже если автор алгоритма очень сильный криптограф, то может найтись ещё один криптограф, более прозорливый и находчивый, который сможет взломать алгоритм. Словом, нет доверия алгоритму, автор которого скрывает исходные данные (код алгоритма).

Поэтому лучше созданный алгоритм "подарить" сообществу, то есть сделать открытым для исследований в криптоанализе и ждать, пока в алгоритме не начнут открывать уязвимости. В итоге, лучший подход это придумать очень сложный секретный ключ.

Придумать очень сложный секретный ключ

Лучше придумать ключ подлиннее и посложнее. Однако, сегодня ваш ключ суперсложный, завтра — очень сложный, послезавтра — весьма сложный, через год — ... В общем, когда вычислительная мощность компьютера, достаточная для взлома вашего ключа методом подбора (brute force), станет сравнительно невысокой, т.е. цена такого компьютера станет существенно ниже цены защищенной информации, то "ждите гостей".

Короче, спасения нет. Остаётся найти баланс между производительностью и безопасностью. Чем длиннее ключ, тем медленнее работает алгоритм, но тем безопаснее зашифрованы ваши данные.

Длинна ключа и его алфавит (количество комбинаций символов) напрямую определяют его сложность. Каким бы большим ни был алфавит, всегда есть слабые ключи.

PKI (public key infrastructure)

Вернёмся к асимметричному шифрованию. Именно на основе асимметричных алгоритмов и строится PKI. В асимметричных алгоритмах используется пара комплементарных ключей:

• публичный (public) или открытый
• закрытый (private)

Такая пара ключей обладает важными математическими свойствами:

• зашифрованное публичным ключом может быть расшифровано только комплементарным приватным
• зашифрованное приватным ключом может быть расшифровано только комплементарным публичным

Итак, есть 2 пользователя (А, В), которые хотят обменяться данными друг с другом, они заранее друг с другом незнакомы, Пользователи хотят подтвердить друг другу подлинность отправляемых данных и их целостность. А и В имеет свою пару ключей: риб_а, рй_ аи риб_Ь, ри_Ь. Так же Аив установили безусловное доверие с Зй стороной, которой является центр сертификации СА (сей са!е ац\рогИу). Эта Зя сторона выдаёт пользователям А и В цифровой сертификат, в котором указана личность пользователя, срок действия сертификата и публичный ключ пользователя.

Когда А шлёт пакет (еж) В, он предварительно из пакета рассчитывает хэш (пазв_а), затем шифрует

полученный хэш своим закрытым ключом риИ_а. В результате получается цифровая подпись (отпечаток) 4_а. Теперь к пакету добавляется цифровая подпись 1еж + 95_а и отправляется В.

В получает Чехи + 9_а и выделяет отдельно пакет 4ех{ и цифровую подпись 95_а. Расшифровывает её открытым ключом риБ_а и получает ВазВ_а_гесе№мед. Далее рассчитывает хэш по тому же алгоритму из пакета _ \ехг и получает ВазН_а_вепегаед. Если Вазр_а_гесемед идентичен ра5№_а_вепегакед, значит сообщение подлинно и не было перехвачено и изменено. Таким образом осуществляется аутентификация с помощью цифровой подписи гза Ча! $дпашгез. ;

Ровно также поступает В, когда хочет послать свои данные А.

Вопрос, откуда А и В знают открытые ключи друг друга? Дело в том, что перед обменом полезными | данными А и В предварительнЪ обменялись своими цифровыми сертификатами, которые они ещё раньше получили от СА. Кроме того, каждый сертификат, выданный центром сертификации, подписан цифровой = подписью самого центра сертификации, что позволяет установить доферие к СА. А раз сертификат подписан. : цифровой подписью центра сертификации, его выдавшего, значит... это значит, что пользователь заранее до иметь открытый ключ центра сертификации! Как сложно, не правда ли? Этот публичный ключ центра _ сертификации распространяется вместе с браузером, обновлениями ОС или вручную. : Как видно из алгоритма выше, Аи В НИКОГДА не обмениваются закрытыми ключами рим_а

RSA Алгоритм, ключи, цифровые сертификаты

Итак, есть 2 пользователя (A, B), которые хотят обменяться данными друг с другом, они заранее друг с другом незнакомы. Пользователи хотят подтвердить друг другу подлинность отправляемых данных и их целостность. A и B имеет свою пару ключей: pub_a, priv_a, pub_b, priv_b. Так же A и B установили безусловное доверие с З-й стороной, которой является центр сертификации CA (certificate authority). Эта З-я сторона выдаёт пользователям A и B цифровой сертификат, в котором указана личность пользователя, срок действия сертификата и публичный ключ пользователя.

Когда A шлёт пакет (text) B, он предварительно из пакета рассчитывает хэш (hash_a), затем шифрует полученный хэш своим закрытым ключом priv_a. В результате получается цифровая подпись (отпечаток) ds_a. Теперь к пакету добавляется цифровая подпись text + ds_a и отправляется B.

B получает text + ds_a и выделяет отдельно пакет text и цифровую подпись ds_a. Расшифровывает её с помощью открытого ключа pub_a и получает hash_a_received. Далее рассчитывает хэш по тому же алгоритму из пакета text и получает hash_a_generated. Если hash_a_received идентичен hash_a_generated, значит сообщение подлинное и не было перехвачено и изменено. Таким образом осуществляется аутентификация с помощью цифровой подписи (rsa digital signatures).

Ровно также поступает B, когда хочет послать свои данные A.

Вопрос, откуда A и B знают открытые ключи друг друга? Дело в том, что перед обменом полезными данными A и B предварительно обмениваются цифровыми сертификатами, которые они ещё раньше получили от CA. Кроме того, каждый сертификат, выданный центром сертификации, подписан цифровой подписью самого центра сертификации, что позволяет установть доверие к CA. А раз сертификат подписан цифровой подписью центра сертификации, который его выдал, то это значит, что пользователь заранее должен иметь открытый ключ центра сертификации! Как сложное, не правда ли? Этот публичный ключ центра сертификации распространяется вместе с браузером, обновлениями ОС или вручную.

Как видно из алгоритма выше, A и B НИКОГДА не обмениваются закрытыми ключами priv_a и priv_b.

• Конфиденциальность — ваш оппонент зашифровал данные вашим публичным, а расшифровали вы своим приватным.
• Аутентичность — вы шифруете своим приватным, а все остальные расшифровывают вашим публичным.

Что же такое CA (ЦС, центр сертификации)?

Всякий раз при передаче сообщения с обеих сторон обмениваться данными об аутентичности крайне сложно. Требуется 3-я сторона — Центр Сертификации, этой стороне доверяют все без исключения.

CA — Это субъект (компьютер, сервер), выпускающий цифровые сертификаты. В сертификате перечислены следующие параметры пользователя:

• IP-адрес или FQDN (полное доменное имя пользователя)
• Открытый ключ пользователя
• СА добавляет серийный номер сертификату
• CA подписывает выпускаемый сертификат своей цифровой подписью
• Указаны URL, проследовав по которым другие пользователи могут узнать срок действия сертификата и отозван ли сертификат
• иные параметры для работы PKI

Сертификаты выдаются под разные задачи. Для этого сертификаты принято делить на классы:

• 0 — тест, без проверок
• 1 — для проверок одного юзера в обмене некритичной информацией (почта)
• 2 — для проверки идентичности личности или business personnel
• 3 — подпись кода (программ), как правило, требуется аудит
• 4 — интернет-магазины и платежные агрегаторы (PayPal, интернет-банкинг)
• 5 — private organizations or governmental security

Коммерческие центры сертификации берут оплату за выпуск сертификатов сертификаций, которым будут доверять все платформы (ОС) и браузеры. Однако в своей организации можно поднять свой CA совершенно бесплатно, но сертификаты, выпускаемые им, будут иметь значимость в пределах организации (домена).

Центр сертификации проводит аудит стороны, запросившей для себя выпуск сертификата. После успешного аудита сторона получает сертификат, однозначно идентифицирующий обладателя сертификата.

Обладатель сертификата хранит его в специальном хранилище (оснастка certmgr.msc).

В некоторых случаях закрытый ключ сертификата хранится отдельно от самого сертификата в специальном контейнере, (на USB-dongle), который имеет пароль для удобства пользователя.

Не всегда центр сертификации CA самостоятельно выдает сертификаты. На это дело он подписывает субардинаторов RA.

Часто сертификаты выпускаются для каждого пользователя в закрытой сети. Для этого требуется свой root CA.

CA выпускает для себя корневой сертификат (root certificate) и для пользователей удостоверяющие сертификаты (identity certificate).

Root certificate содержит открытый ключ CA и другие данные о CA:

• Серийный номер
• Автор (кем выпущен) сертификата
• Срок действия сертификата (крайне важно наличие NTP для проверки подлинности любых сертификатов)
• Субъект (чья-то организация, организация в целом, страна)
• Открытый ключ CA
• Алгоритм отпечатка (цифровой подписи) и сам отпечаток

Identity certificate похож на root certificate, но основное отличие в том, что он содержит открытый ключ пользователя, которому этот сертификат выдан.

x509 apps

Чтобы обмениваться информацией и выдачей сертификатов между CA используется протокол X.500.

Согласно этому протоколу сертификат содержит определённые поля определённого формата, определяет формат списка отозванных сертификатов (CRL) и прочие договорённости.

PKI — это иерархическая структура, распространить и поддерживать которую требуется постоянно вместе с ростом вовлеченность Интернета в бизнесе и в жизни вообще. Делать это "руками" бессмысленно. Для быстрого и масштабируемого выпуска сертификатов электронным образом RSA Lab выпустила ряд стандартов PKCS# для:

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

Правила аутентификации, генерирования ключевой пары, запроса на сертификат и проверки сертификата и его установки в ОС описаны в протоколе SCEP (Simple Certificate Enrollment Protocol). Протокол имеет патент.

PKI Topologies

В крупных сетях, где количество пользователей исчисляется тысячами и десятками тысяч, одного CA может быть недостаточно. Нужны резервные CA. Кроме того, часть операций CA может быть делегирована подчиненным ему CA. RA (registration authority) — собирают запросы на выдачу сертификата, генерируют ключевую информацию, передают эти данные в CA.

CA — выпускает сертификаты и список отозванных сертификатов (CRL). Отозванным сертификат считается, если есть основания полагать, что закрытый ключ данного сертификата скомпрометирован (взломан), или устройство, которое обладает этим сертификатом, "списывается", как это часто бывает в организации. Для этого потребуется связаться с CA и потребовать "отозвать" данный сертификат.