Основы криптографии

Симметричное шифрование

Между вашим смартфоном и мобильным оператором, или провайдером интернета, или банком используется симметричное шифрование. Ваш браузер отправляет и получает данные, используя симметричное шифрование. Не потому что оно самое надежное, но зато быстрое. Ключи симметричного шифрования занимают сущие крохи памяти (256 бит — 16 байт). Можете попробовать зашифровать что-нибудь с помощью BCTextEncoder.

Симметричное шифрование подразумевает использование одного ключа для шифрования и расшифровки данных. И отправитель, и получатель используют один и тот же ключ для общения через зашифрованные электронные сообщения. Если вы шифруете файлы или диск, в этом случае тоже работает симметричное шифрование. iMessage, Signal, WhatsApp — все они используют симметричное шифрование для безопасности вашей переписки.

В симметричном шифровании текст может обрабатываться как блоками, так и побитно. Алгоритмы DEA и AES содержат блоки 64 и 128 соответственно. Хоть AES и имеет фиксированный размер блока 128, лучше выбирать 14 раундов для 256-битных ключей. По настоящему случайные генерации требуют сложных вычислений, поэтому используют псевдо-случайные генерации для ускорения процесса. AES не дает Perfect Forward Secrecy, так что, как только злоумышленник получит общий ключ, то сможет расшифровать всё.

Бинарные цифры. Если алгоритмы из докомпьютерного мира могли полагаться на буквы, то в компьютере мы полагаемся только на цифры. Нули и единицы это биты, 8 бит это байт. Например, XOR . 2⁴= 2 * 2 * 2 * 2 = 16. Так, ключ может быть длиной 128 бит в современном мире, или 64 бита. Казалось бы, разница незначительная, но первый в 18 квинтиллионов раз более безопасный. Удвоение длины ключа очень усиливает безопасность. В алгоритме AES можно выбрать один из трех вариантов размера ключа. Ключ в AES128 достаточно маленький, чтобы быть зашифрован открытым ключом, и так получается гибридное шифрование. Если в вашем ключе всего 10 бит, то его можно отгадать за 1 000 попыток. Ключ содержит n бит, то есть 2ⁿ. Так, если n = 64, тогда получает 2⁶⁴ возможных вариантов ключа. Или 1.8 * 10 ¹⁹. Но специальные устройства могут взломать и такие комбинации. 128 бит сложно взломать брутфорсом. хэш-функция в 2 бита это всего 4 вариант: 00, 01, 11, 10. При длине в 512 злоумышленнику нужно 2²⁵⁶.

Симметричные ключи также различаются по размеру, но наиболее распространенная длина — 128 или 256 бит. Использование безопасного 256-битного симметричного шифрования делает коммуникации организации практически неуязвимыми для атак методом перебора, если ключ шифрования надежен.

Первый вид симметричного шифрования это блочные шифры, который мы упоминали ранее. Если размер блока слишком маленький, то его можно взломать. Слишком большой — неэффективен в работе. Был DES = 64 (нормально для 1970 года), 56-битный ключ, что означает, он имеет более 72 миллионов миллиардов возможных ключей. Звучит впечатляюще, но 128 лучше. При размере блока 128, и размере текста 348, получается 348 / 128 = 2.71. 348 — 256 = 92 пустых бит надо чем-то заполнить. Заполнение пустого пространства называется padding. Если заглянуть слегка наперед, то заполнение пустого пространства хорошо реализовано в RSA OAEP, весьма известный способ с двумя хэш-функциями. Также, шифрование не может скрыть длину сообщения. Если вы шифруете блочным шифром без хитрых режимов шифрования (в режиме EBC), то одинаковые блоки открытого текста будут переходить в одинаковые блоки шифротекста. Так как блоки достаточно маленькие, одинаковых будет много, и они будут раскрывать много информации атакующему. Злоумышленник может анализировать трафик, вычленить некий паттерн и использовать это для спекуляций. Для борьбы с таким поведением принято отправлять фальшивые сообщения, и добавлять padding.

Если в блочном шифре мы берём блок 128-bit и его преобразовываем, то в поточном мы преобразовываем сам bit. Потоковый шифр является вторым из двух наиболее популярных симметричных шифров. Использует XOR, ключ скорее всего будет 128 бит, очень быстр в использовании. Один из примеров реализации это RC4, который весьма слаб с точки зрения ИБ, поэтому принято использовать новый ключ для каждого нового пакета. Точно не годится для обмена платежными данными, но для военной рации — ок. RC4 можно встретить в WEP.

Теперь поговорим про MAC. MAC довольно короткий по длине, легко считается. Но не тот, который назначается сетевым устройствам на производстве, а про криптографичесий MAC. Это самая популярная симметричная техника. Представим, что злоумышленник перехватил сообщение, которое зашифровано потоковым шифром, и изменил в нем один бит. Если тип данных был дата, то она будет изменена и этого никто не заметит, так как она остается валидной, просто другой. Была 12/12/2022, стала 11/12/2022. Другими словами, криптография сама по себе не предоставляет гарантию, что сообщение до получается дойдет без изменений. Для проверки целостности на стороне получателя сверяется MAC, причем он разный на стороне получателя и отправителя. И это не хэш-функция, которая не способа подтвердить происхождение данных, пусть даже MAC может быть основан на хэш-функции и будет называться MAC. MAC увеличивает длину сообщения для отправки, что сказывается на скорости. Поэтому длина MAC обычно в пределах 32-64 бита, это добавление времени, но и дополнительной информации для увеличения безопасности. У MAC много стандартов, один из них ISO/IEC 9797.

Также, шифрование само по себе не дает никаких наметок на происхождение данных, и если нам это важно (а нам важно), то для симметричного шифрования применяется MAC + CTR. Я придерживаюсь подхода сначала шифровать, затем MAC. Если MAC не прошел проверку, то получатель попросту откажется от получения сообщения. В моем подходе будет два разных ключа. Два ключа = две операции, а это уже накладно, хоть и более безопасно. У описанного подхода есть название — Galous Counter Mode (GCM) == CTR + MAC. На выходе у нас зашифрованный текст + MAC. Так активные атаки предотвращаются по MAC.

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

Целостность требует не просто шифрования, но и подлинность (пример с датами выше). Целостность это про отсутствие изменений во время передачи данных. Подлинность про гарантию, что сообщение от ожидаемого отправителя. MAC получает на вход контекст и выдает строку в 64 или 128 бит. Популярные атаки: forgery attack и key recovery attack. Forgery attack позволяет третьему лицу без секретного ключа сгенерировать MAC.

Для обмена ключами и получатель, и отправитель нуждаются в часах. И если компьютер имеет часы, то более простые устройства могут не обладать такой функцией, такие как смарт-карты. Время должно быть одинаковым, но рано или поздно будет рассинхрон, на это может влиять даже температура воздуха. Значит, время нужно синхронизировать в соответствии с неким стандартом. С этой задачей может справиться MAC. Оптимально использовать Nonce-механизм (Number Used Only Once). Сравнение методов синхронизации времени приведено в таблице ниже:

ЧасыПоследовательностьNonce
Требуется синхронизацияДаДаНет
Задержка в коммуникацииДаДаДа
Требует целостностьДаДаНет
Минимальное кол-во проходов112
Специальные требованияЧасыБДГенератор случайных чисел

HASH-функции. Защита целостности данных от случайных ошибок работает на проверках CRC. Хэш-функции можно использовать для шифрования паролей, так как их не надо расшифровывать. У хэш-функции нету ключа, и она обычно намного меньше оригинального сообщения. Поэтому одинаковый хэш может быть у разных файлов. Например, у пин-кода банковской карты всего 4 цифры, то есть 10 000 комбинаций. Если у банка 1 000 000 клиентов, то каждые 100 клиентов имеют одинаковый пин. Но даже если злоумышленник купит базу данных хэшированных паролей в солью, ему это ничего не даст. Вычислительно очень сложно восстановить символы пароля из имеющегося хеш-значения. Такие хэш-функции устойчивы к обратному преобразованию и трудно понять, какие одинаковые значения спрятаны за одинаковой хэш-функцией. Если банк будет требовать придумывать пятизначные коды, то это 100 000 возможных PIN-кодов. Квадратный корень из 100 000 составляет чуть больше 316.

Хэш-функция позволяет удостовериться в целостности данных, но это не надежный инструмент для проверки целостности. Это позволяет убедиться, что файл не был изменен из-за технической ошибки, не более того. Технически, это простое сравнение двух хэшей, полученного хэша с ожидаемым. Но злоумышленник может это обойти, попросту использовав нелегитимный файл для генерации хеш-функции. Хэш-функции не могут обнаружить злонамеренное изменение данных активным злоумышленником, который также изменяет хэш в соответствии с измененными данными.

Хэш-функция умеет это предотвращать, полагаясь на preimage, second preimage и collision resistance. Хэш-функцию можно быстро и легко посчитать, и это односторонняя функция. Также хеш-функции не предоставляют non-repudiation.

У AES существуют разные режимы шифрования. А вот уже режим работы CBC или CFB, CTR могут накладывать свои особенности.

CTR требует синхронизации счетчика. CTR делает любой блочный шифр потоковым. Формально, когда вы используете AES в режиме CTR — формируются блоки случайных данных, которые перемешиваются с оригинальными шифруемыми данными. Поэтому без ключа расшифровать не получится. На практике, каждый из 16 байт генерируется одинаковый, то есть это очень условная псевдо-случайность. По факту, это XOR, который ломается автокорреляцией.

ECB — годится только для коротких сообщений, и если у вас одинаковый текст и одинаковый ключ, вы получите одинаковый зашифрованный текст. Если нужно шифрование с открытым ключом, на практике используется в основном режим ECB (хотя и только с одним «блоком» открытого текста). Если длина сообщения для шифрования больше, чем 128 бит, то используется ECB мод, ну и соответственно, если одинаковый текст дважды появился в тексте, то он будет одинаковым и в зашифрованном виде. Что позволяет злоумышленнику понять структуру, поэтому ECB весьма уязвим.

CBC слегка медленнее ECB, но куда лучше. И иногда цена от вендора на использование этого режима может отличаться, скажем, за AES128 ECB компания платит 100$, а за AES256 CBC — 1000$. CBC mode используется редко, так как SSH CBC шифры считаются слабыми. Мы зашифровали сообщение с помощью AES, а с помощью CBC получили хеш для валидации сообщения.

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

CBC может содержать аутентификацию (CBC-MAC), все на блочном шифре. У отправителя и получается есть секретный ключ k, и если он длиной в 1 бит, то у злоумышленника есть 50% шанс угадать. Но если ключ состоит из n бит, то шанс угадать 1/2ⁿ.

ПроблемаECBCBCCFBCTR
Легко распараллелить ДаНетНетДа
Требует синхронизацииНетНетНетДа
Битовые ошибки1 блок1 блок + 1 бит1 блок + 1 бит1 бит
Требует реализовать расшифровку и дешифровкуДаДаНетНет
Требует дополнение (padding) ДаДаНетНет
Зависимость от позицииНетДаДаНет

DES

Конечно, DES как алгоритм симметричного шифрования всегда вызывал много споров. Тем не менее, он привел к появлению многих хороших вещей. Он почти наверняка был достаточно хорош для множества задач в 1970-х и 1980-х годах, а также вызвал лавину исследований в области разработки блочных шифров. Сегодня консенсус заключается в том, что это был надежный алгоритм, которую подпортила короткая длина ключа — которая была введена по политическим причинам. Современные стандарты криптографии включают в себя сотрудничество людей из многих стран для создания методов, соответствующих современному уровню техники, и поэтому я считаю, что им можно доверять. Тем не менее, мы не можем позволить себе быть самодовольными, о чем свидетельствует шумиха вокруг стандартизации генератора случайных битов Dual_EC_DRBG.

Шифр Вернама

Шифр Вернама это алгоритм шифрования с множеством проблем. Но концептуально он идеален, дает идеальную секретность, то есть невозможно получить какую либо информацию до дешифрования (в теории). У такого подхода есть три особенности: количество ключей равно количеству потенциального текста. Требуется настоящая случайность для генерация ключа, и ключ может использоваться лишь один раз. Блочные шифры не увеличивают размер, Vernam Cipher работает побитово на XOR.

Ассиметричное шифрование

Принцип генерации ключей в симметричной и ассиметричной криптографии очень отличается. Симметричный ключ это простое случайное число, так, железку лучше использовать для генерации мастер-ключа, а псевдо-случайные числа для локальных ключей. Зачастую генерируют один ключ т и его используют для доставки остальных ключей. Эмпирическое правило гласит: удвойте длину симметричного ключа, чтобы получить эквивалентную длину хэш-выхода. Это позволит противостоять атаке по первообразу. Разные алгоритмы генерируют ключ по разному, и зачастую в алгоритме встречаются узявимости.

Несимметричный ключ относительно труднее генерировать, чем симметричный. Асимметричное шифрование используется в электронной почте. Ассиметрия идет от ключей: один ключ для шифрования, другой для расшифровки. Публичный ключ может быть известен всему миру, и шифрование публичного ключа это долгая операция по сравнению с симметричным шифрованием. Открытый/публичный ключ это ключ, который вы используете для обращения со своей машины на сервер. В ассиметричной криптографии также используются случайные числа, но есть нюанс. Так, если мы выбрали RSA, нужно задать ключ d, и при 4608 битах значение равно d = 2⁴⁶⁰⁸, но некоторые потенциальные значения будут отброшены по определенным правилам.

Следует ещё раз отметить, что шифрование с открытым ключом используется только в процедуре TLS Handshake во время первоначальной настройки соединения (SHA-384). После настройки туннеля в дело вступает более быстрая симметричная криптография, и общение в пределах текущей сессии шифруется именно установленными симметричными ключами. Это необходимо для увеличения быстродействия, так как криптография с открытым ключом требует значительно большей вычислительной мощности. Основной смысл асимметричных схем не в уменьшение количества ключей, а в решении проблемы распределения ключа. Вам не нужен доверенный канал. Но ассиметричное шифрование медленное, потому что используется протокол Диффи-Хеллмана для выработки общего секретного ключа и последующего шифрования симметричным алгоритмом. 

Для генерации самого низкоуровневого и простого ключа ассиметричного шифрования вам нужен только e-mail. Это те самые сертификаты, что «бесплатно» раздаются под простенькие сайты от хостингов. Для крупного интернет-магазина уже потребуется подтвердить регистрацию бизнеса. Ключи могут генерироваться на различных устройствах, как внешний, так и встроенных. В реальной жизни, HSM в основном используется в сервисах для интернет-платежей и доставки PIN-кодов через интернет. HSM-модули удовольствие недешевое. Погуглите цены на Luna Network Hardware Security Modules (HSMs), это весьма дорого. А если мы хотим уметь подписывать платежи без раскрытия суммы, то применяется еще и гомоморфное шифрование. Так мы сможем работать с данными без расшифровки. Зачастую хочется, чтобы после хэша сохранялась схожесть над парами объектов, тогда используют то самое гомоморфное шифрование. 

Когда вы покупаете что-то в подозрительном интернет-магазине, то всегда должна использоваться public-key криптография, то есть ассиметричное шифрование. Протокол для покупки чего-то онлайн это SSL/TLS, с комбинацией двух вариантов криптографии. В случае с симметричным шифрованием TLS — AES или ChaCha20 (ChaCha20Poly1305) или RC5/RC6. RC5 c 2040 битами и RC6 с 4096 битами. Но мы уделим особое внимание алгоритму RSA.

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

RSA

Криптография с открытым ключом (public-key) привлекательна для многих приложений, но у нее есть и недостатки. Злоумышленник может иметь доступ к зашифрованному тексту, также, он может знать ключ шифрования. Алгоритм шифрования может быть как проприетарным, то есть его детали известны лишь вендору, либо алгоритм шифрования может быть публичным. В последнем случае злоумышленник знает, как работает алгоритм шифрования. Знает алгоритм, но не процесс шифрования и дешифрования. Если же вы корпорация и создали свой проприетарный алгоритм, все равно далеко не факт, что деталей проприетарного алгоритма нету в интернете, злоумышленник мог купить устройство с алгоритмом, и риверс-синженерить. Поэтому важное требование к любому алгоритму — его надежность не должна полагаться на секретность. Есть смысл выбрать популярный алгоритм, если его надежность подтверждена годами опыта, его успешной имплементацией между вашей сетью и сетью клиента, и доверием экспертов. Попросту, принято выбирать RSA. Это однонаправленная функция, в которой легко получить результат шифрования, но сложно его преобразовать в изначальные значения.

На совсем примитивном уровне, все, что делает RSA — это берет два больших простых числа, перемножает их и формирует так называемый модуль. Все остальные числа, с которыми будут производиться операции, должны находится между нулем и значением модуля. Алгоритм работы RSA прост: сначала генерируем два больших числа, каждое по 512 бит минимум. Перемножаем, и выбираем специальное свойство e (тоже число): пример формирования пары для публичного ключа = 3780 и 25.

p = 45 и q = 84
n = pq = 45 * 84 = 3780
e = 25 (44 * 83 = 3652 / 25 = 146.08)
Длина модуля RSAДлина симметричного ключа
51256
124880
2432112
3248128
15424256
RSA

Для увеличения скорости шифрования, значение e часто выбирают равным 17, 257 или 65537 — простые числа. Наиболее популярным является 0x10001 = 2^16 + 1 = 65537, но также могут быть 3,5,17,257, которые все имеют вид 2^(2^n). Именно такое значение e предпочтительнее других. Если мощность равна 2, что позволяет быстро вычислить M^e mod n. Большее значение e заметно замедлит работу RSA.

У разных пользователей будет одинаковая экспонента e как часть открытого ключа, и это не проблема. Самое главное — выбрать n, которое вряд ли будет одинаковым у многих пользователей. Потому что модули разные, и невозможно получить закрытый ключ по параметру e.

Если две функции в RSA окажутся не однонаправленными, то считайте, что RSA сломана. Идеологически, отправляется не ключ, а незашифрованное сообщение, а ключик остается на стороне отправителя. Получается, что ключ шифрования и дешифрования разный: берем сообщение «3», которое в побитовом виде 00000011, возводим в степень 00000011⁴² и делим на 7 830 987 678. Это легко посчитать, но трудно расшифровать.

Получаем огромные число, и вроде бы все надежно. Немного подсчитаем. Если компьютер умеет выполнять миллион операций в секунду, тогда для 30-и битного ключа потребуется 2³⁰ / 10⁶. Так как 2³⁰ это ≈10^30 / 3.3 = 10⁹, поиск ответа займет 10³ = 1000 секунд = 17 минут. Чем больше возведение в степень, тем надежнее, но и дольше процесс шифрования. Существует другой алгоритм — ELGamal. RSA лучше чем ELGamal, так как требует всего лишь одно возведение в степень. Но при расшифровке ELGamal выигрывает в скорости.

Если по каким-то причинам не понравилась RSA, на выручку придет ElGamal. Это алгоритм публичных ключей, работает на кривых. Состоит из трех сущностей: специальное огромное число, в районе 3072 бита, назовем его p. Другое число в роли примитива, в диапазоне 1 и p — 1, и приватный ключ, пусть будет 45. Так, p = 23, g = 11, pk = 3. Результат, y = 11³. Представленный пример выглядит весьма просто, но шифрование и дешифрование сложнее, чем RSA. Сломать алгоритм без знания приватного ключа… нет ничего невозможного, но эту задачу я бы назвал очень сложной. Чтобы сломать ElGamal без знания ключа шифрования, нужно узнать временный ключ. ElGamal достаточно надежный алгоритм, в то время как 3248-bit RSA просто отличный. Проблема дискретного логарифма сложнее, когда она определена на эллиптических кривых.

Длина ключа RSA и ElGamal по модулю n будет равна 3248 (и для ElGamal значение умножаем на 2), в то время как RSA и ElGamal на эллиптическая кривая дадут ключ длиной 256.

Во время мозгового штурма о том, как взломать систему, мы всегда думает про атаки из будущего. Так, экспонента в алгоритме шифрования RSA должна быть 1536, такое значение считается надежным против индивидуальных злоумышленников, 3072 против state-sponsored на будущее.

На картинке выше видно, что в какой то момент применилась RSA. Но RSA никогда не должен применяться для обмена ключами. В данном случае RSA применяется для поиска проблем в TLS-соединении. Также можно видеть ECDSA.

Один из отличных примеров гибридной схемы я считаю ECIES. Это схема шифрования с аутентификацией с открытым ключом, которая использует KDF (функцию деривации ключа) для генерации отдельного ключа управления доступом к среде и симметричного ключа шифрования из общего секрета ECDH. Это более практичная версия ElGamal, так как гибридная. Не является полностью ассиметричной. ECDH работает на эллиптических кривых. Поскольку алгоритм ECIES включает в себя симметричный шифр, он может шифровать любой объем данных. На практике, ECIES используется для хранения ключей в безопасности на iOS.

Шаги алгоритма ECIES:

  • входными данными являются открытый текст сообщения и открытый ключ ECC получателя
  • генерируется вектор инициализации / IV (случайные байты)
  • генерируется эфемерный ключ ECC (случайные байты). Открытый ключ получается из закрытого ключа
  • эфемерный закрытый ключ объединяется с открытым ключом получателя — это и есть общий секрет ECDH
  • общий секрет растягивается с помощью KDF (функция деривации ключа) для создания 2 секретных ключей
  • один секретный ключ используется для шифрования открытого текста
  • другой секретный ключ используется для генерации MAC.
  • на выходе получается шифротекст + IV + эфемерный открытый ключ + MAC

TLS

Самое популярное применение современной криптографии — шифрование сетевого трафика. Вы отправили сообщение на сервер, и его перехватил злоумышленник. Но он не сможет прочитать содержимое сообщения, в общем то это и есть основная задача TLS. Для сетевого трафика публичные сертификаты строятся на SSL/TLS. Если вы хотите создать свой SSL-сертификат, есть сайт letsencrypt. В сложном случае, сертификаты могут подписываться по цепочке RapidSSL -> GeoTrust -> Symantec -> Broadcom -> HP.

Transport Layer (TLS) позволяет браузеру установить httpS для установки безопасного соединения между браузером и сервером. Вы зашли в браузер, и перед началом диалога клиента/сервера браузер и сервер обмениваются TLS. TLS дает секретный ключ, у браузера есть список root public keys, и сайт имеет сертификат, подписанный одним из этих ключей.

TLS часто называют Secure Socket Layer (SSL), потому что основа TLS это SSL, который является одним из наиболее широко используемых протоколов безопасности. Secure Sockets Layer (SSL) — это криптографический протокол, обеспечивающий безопасное общение пользователя и сервера по небезопасной сети. TLS = SSL.

Шифровать ассиметрично абсолютно все — сложно. Чтобы решить проблему производительности, в Transport Layer Security (TLS) применяют гибридное шифрование: общий ключ для симметричного шифрования данных передается от клиента серверу зашифрованным открытым ключом сервера. После, сервер может его расшифровать своим закрытым ключом и использовать для обмена данными с клиентом.

Очевидная первая проблема это TLS v1.0 и TLS v1.1 — это устаревшие протоколы, которые не следует использовать, но на практике они бывают необходимы. TLS v1.2 или TLS v1.3 должны быть основными протоколами, потому что эти версии предлагают современное аутентифицированное шифрование (также известное как AEAD). Если не поддерживать TLS v1.2 или TLS v1.3 сегодня, ваша безопасность недостаточна. Можно использовать потоковый шифр, но обычно выбирают блочный. TLS 1.3 поддерживает режим GCM и ChaCha20/Poly1305.

TLS 1.3 появился на свет не просто так: все предыдущие версии были с уязвимостями. Проблемы предыдущих версий: сообщения об ошибках могут навести на догадки о первом положении битов, так можно узнать MAC. Другой вид атаки это protocol downgrade attack, когда выбирается устаревший протокол для обмена данными через старые браузеры. Особенно эффективно работает с мобильными телефонами, когда вас вынуждают использовать только 2G, где есть уязвимости. Либо был использован нестандартный алгоритм: MD5 никогда не был стандартизирован, но популярны в прошлом. С ним можно поиграться с помощью утилитки HashMyFiles. Альтернативные протоколы: QUIC/SCTP + DTLS.

Хотя ключ шифрования находится в открытом доступе в Интернете, только получатель с ключом расшифровки может прочитать зашифрованные с его помощью электронные письма. Частные компании размещают ключ в сценарии работы асимметричного шифрования, что дает возможность читать сообщения только уполномоченным сотрудникам.

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

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

  • Клиент обращается к серверу через защищенный URL-адрес (HTTPS…).
  • Сервер отправляет клиенту свой сертификат и открытый ключ.
  • Клиент проверяет его в доверенном корневом центре сертификации, чтобы убедиться, что сертификат легитимный.
  • Клиент и сервер договариваются о самом надежном типе шифрования, который каждый из них может поддерживать.
  • Клиент шифрует сеансовый (секретный) ключ с помощью открытого ключа сервера и отправляет его обратно на сервер.
  • Сервер расшифровывает сообщение клиента своим закрытым ключом, и сессия устанавливается.
  • Ключ сессии (симметричное шифрование) теперь используется для шифрования и дешифрования данных, передаваемых между клиентом и сервером.

Если нет возможности заранее договориться об симметричном ключе шифрования, то использует гибридное шифрование или протокол Диффи — Хеллмана. Он только для работы с ключами.

Диффи — Хеллман

Для TLS чаще всего используется эфемерный Диффи-Хеллман (DHE), который нужен для SSL-рукопожатия. Или CHAP, EAP. Суть Диффи-Хеллмана в том, что клиент и сервер обладают секретными K, которые сгенерированы случайным образом. Эти K никогда не передаются по сети. Поверх накладывается RSA для шифрования. Получаем заветный perfect forward secrecy — если скомпрометированы секретные ключи, прошлая переписка не будет скомпрометирована. В протоколе не учтена аутентификация, что позволяет провести атаку man-in-the-middle. Это решается с помощью STS. Если сверху накинуть STS-протокол, чья полная версия предоставляет взаимный ключ подтверждения, то это уже почти AKE. Диффи-Хеллман предпочтительнее RSA в TLS 1.3, так как он обеспечивает идеальную прямую секретность. Но реальность, как всегда, разочаровывает. PFs часто отключают, чтобы… что-то другое заработало. Такой совет есть во многих официальных мануалах. Я знаю о такой ситуации, когда на на одном роутере был включен PFs , а на втором нет. И туннель был поднят, каким-то образом оно работало.

Алгоритм работает так: у нас есть p = 14, g = 173, это составные публичного ключа. Далее клиентский компьютер берет приватный ключ, a = 25, аналогичное делает сервер b = 78. Следующим шагом клиент применяет формулу gᵃ = 173²⁵ * модуль p.  Аналогичное делает сервер 173⁷⁸ * модуль p. По итогу, на сервере и клиенте получаются одинаковые ключи.

По итогу, протокол Диффи-Хеллмана позволяет обменяться ключами. Если вы банк и вам нужно для каждого клиента хранить по ключу, то это накладно. Диффи-Хеллман был разработан еще в те времена, когда не было возможности устанавливать защищенное соединение. У протокола Диффи-Хеллман есть несколько реализаций, такие как статичный, ECDH, эфемерный. Так, лучше всего описывает протокол «станция-станция» аутентифицированная версия протокола Диффи-Хеллмана.

Аутентификация

Аутентификация собеседников это уверенность в том, кто является собеседником. Аутентификация особенно важна при контроле доступа, что является частью комплексных криптографических процессов. Если наша задача аутентифицировать сотрудника с доступом в помещение, то можно дать ему магнитную ленту, которая вместе с пин-кодом будет давать доступ к помещение. Умные карты и токены — тоже способы аутентификации. Не нужно путать аутентификацию (в простом примере это проверка пароля) и авторизацию (доступ к определенным данным). Можно аутентифицироваться как простой пользователь и не иметь авторизированного доступа к панели администрации. Да и сам факт предоставления данных — ничего не значит, еще важна их актуальность.

В популярном случае, для аутентификации требуется пароль, и очевидно, он должен быть защищен криптографией. Многие знакомы с Salt в Unix: это 12-и битовое число, сгенерированное на основе системных часов. Называется DES+. 8 ASCII символов, каждый по 7 бит, конвертируется в 56-битный DES ключ. Но многие системы модифицируют подход к хранению и защите паролей и заставляют пользователя придумывать надежный пароль.

Аутентификация нужна, когда нужен доступ к аккаунту. Браузер спрашивает вас логин и пароль, обмен происходит после установки TLS-сессии, так пароль не может быть перехвачен. Аналогично с оплатой картой через терминал, генерируется MAC. Существуют разные виды аутентификации. Локальная аутентификация — ввели пароль на своей локальной машине. Прямая аутентификация — вводим пароль к серверу, и БД с паролем хранится непосредственно на этом сервере. Непрямая аутентификация — используется отдельный сервер для аутентификации, с протоколами типа RADIUS или Kerberos. Аутентификация на основе тикетов-блоков зашифрованных данных, у MS так работает Kerberos в Active Directory. Оффлайновая аутентификация, когда при попытке логина нужно предоставить сертификат ассиметричного ключа, который ассоциирован с именем владельца.

Для предотвращения атаки повтора на аутентификацию применяются генераторы случайных чисел. И вообще, в мире IT очень многое работает на случайных числах. Когда мы говорим случайные числа, мы подразумеваем по настоящему случайную вероятность, но в компьютерном мире нет ничего случайного. У всего есть структура, и она предсказуема, а значит уязвима. Например, появляется ли 0 также часто, как и 1? Чередуются ли 1 и 0 друг за другом с одинаковой частотой? Появляется ли строка 1111 также часто, как 0000? Если вы подумали о равномерном распределении чисел, то это никак не связано со случайностью. Существует всего два вида генераторов — недерерминированный и детерминированный. Первый полагается на физический мир, например на шум, отскоки электронов, и требует специального оборудования. Детерминированный выдает псевдо-случайности. Другими словами, если знать изначальные вводные, то можно предугадать результат. А если подать на вход одинаковые данные, то и результат будет одинаковым. Возможно провести Side channel attack — взлом по косвенным признакам.

Стандартное требование это аутентификация источника данных — конфиденциальность, а это MAC и ключ с помощью которого данные шифровались. Для вывода ключей можно использовать NIST или HKDF, которая основана на HMAC, pbkdf2 это функция, PBKDF2 это алгоритм, позволяющий увеличить стойкость к брут форсу. KDF может базироваться как на потоковом или блочном шифре, так и на хэш-функции. SK -> KDF -> k1, k2, k3…

Иерархия ключей

Иерархия ключей — ключи на низком уровне защищаются ключами на уровне выше. Трехуровневая иерархия ключей состоит из мастер-ключа в вершине, и он шифрует ключи второго уровня. Ключи второго уровня шифруют ключи третьего уровня. Ключи второго уровня живут меньше чем ключи первого уровня, и их легче поменять, и третий ключ это ключ на сессию. Самое важное это генерация мастер-ключа, и это компонентная форма. Нужно обменяться мастер-ключем между двумя HSMs? Тогда либо генерация одинакового ключа на обеих сторонах, либо обмен по специальному протоколу.

Электронная подпись. Отправитель должен получить подтверждение о доставке сообщения, и получатель получает гарантии, что отправитель это конкретное лицо. Значит, все было легитимно и действие неотменимо. Это важно при подписании документов на сдачу квартиры, например. Понятие электронная подпись можно интерпретировать и как просто написать ваше имя в контактной форме к этой статье, но очевидно, это очень слабая подпись. Хотелось бы иметь возможность идентифицировать отправителя. Электронная подпись напрямую генерируется с данных, которые она подтверждает, + дополнительный секретный параметр. Подпись идет через арбитра, на чьей стороне добавляется дополнительный MAC, но дополнительный участник в процессе обмена данными — всегда плохо. Обмен может происходить напрямую между банком и клиентом, это называется ассиметрия. HSMs это специальное устройство, в котором один MAC может быть использован только клиентом для создания MAC, который будет проверен банком. В таком случае, судья сможет понять, были ли данные с определенным MAC сгенерированы отправителем. Все должны использовать определенную хэш-функцию, где RSA оперирует блоками битов, что делает RSA неэффективным для подписи больших блоков информации. Каждый блок подписывается отдельно, и эти блоки никак не связаны.

Протоколы

Зашифровать данные и хранить их на своей машине это интересно, но куда интереснее данные пересылать. Что такое протокол? Когда вы встречаете человека в коридоре, вы говорите how are you? и улыбаетесь. Это протокол поведения. Но в компьютерном мире протокол это TCP/IP для обмена информацией между устройствами, а в мире криптографии существуют свои протоколы. Протоколы призваны решить проблему с безопасной передачей данный, но как всегда, мы чем-то жертвуем ради производительности. Поэтому шифрование стандартизируется и называется протоколом.

Базовая структура криптографического протокола:

  1. что происходит до протокола
  2. кто обменивается сообщениями
  3. какая информация на каком шаге присутствует
  4. что должно происхожить на каждом шаге

Протоколы AKE: очень часто адаптируются под нужды конкретного приложения. Двум сторонам обмена требуется точно понимать, что на другой стороне провода не злоумышленник. Обменяться общим симметричным ключом, ISO/IEC 9798-2:2019.

Другой транспортный протокол RPC (Remote Procedure Call) — для удаленного вызова функций на сервере. Очень старый.

Протокол RADIUS для аутентификации и авторизации. Вместо RADIUS можно использовать более новый протокол Diameter. Такие проткоолы упрощают администрование 802.11.

Примеры — PKCS для публичных ключей, ISO/IEC 11770 для аутентификации, SSL/TLS для безопасного канала обмена данными, очень часто это клиент и веб-сервер. И он не такой уж и безопасный. Безопасность SSL не имеет возможности контролировать или даже реагировать на содержимое веб-страницы, только на ее DNS-адрес

PKI и хранение ключей

Хранить ключи идея сама по себе плохая. В идеале, ключ генерируется налету, такая реализация существует и успешно работает. Но для генерации ключа нужен seed, и вот его уже надо где-то хранить. Хранится он в голове пользователя под видом пароля или кодовой фразы. А теперь мы можем вспомнить, что генерировать несимметричные ключи весьма накладно. Возникает желание сохранить сгенерированный ключ внутри кода приложения, но это небезопасно. Или на железке HSMs, или смарт-токене.

Плохая идея переиспользовать созданный ключ ради удобства. Например, хранить на устройстве или в памяти пин-код, зашифрованный симметричным ключом. Зашифрованный пин-код нужно этим ключом только шифровать, но никогда не дешифровать. Использовать одинаковый симметричный ключ и для генерации MAC, и для шифрования — всегда плохая идея. Но если мы решили так делать для оптимизации (что очень частый случай), то нужна деривация. Поверх накидываем SIV mode, уменьшаем строку зашифрованного ключа в другую информацию, накручиваем ANSI TR-31, DES с указанием цели ключа.

Так мы потихоньку подходим к вопросу хранения ключей, так как генерировать ключи налету оказалось сложно. У ключей есть свой жизненный цикл. Очевидно, что сломать криптографию саму по себе не легко, злоумышленнику куда перспективнее получить доступ к паролю из-за уязвимостей в самой системы хранения ключей. Поэтому для ключей создана определенная инфраструктура. Такая как PKI, система хранения ключей. PKI является технологией безопасности, которая основывается на стандарте X.509 и использует цифровые сертификаты. Может быть реализована в виде отдельного устройства, со специальным криптографическим протоколом, и обеспечивающее бекап ключей. PKI обычно работает с ассиметрией, потому что используется два ключа.

Чтобы быть полезным на практике, сертификат открытого ключа должен быть создан в соответствии с заранее определенным форматом. Один из очень широко используемых форматов известен как сертификат X.509, который был стандартизирован в ISO/IEC 9594-8. Сертификаты X.509 используются различными способами для поддержки безопасности в Интернете, в частности, в протоколе безопасности TLS.

Шифрование позволяет зашифровать данные на диски, так что даже если данные украдены — ничего страшного. Но где-то надо хранить ключи, которыми шифровался диск. Если ключ потерян — данные потеряны. Поэтому ключ мы храним в специальном TPM. Window 11 требует наличия TPM-чипа в компьютере. Ключ может автоматически дешифровать данные в момент запуска компьютера. Ключ можно хранить на флешке, некоторые флешки предлагают защиту, например diskAshur Pro 500GB, Kingston Ironkey D300S.

Также, существуют центры сертификации (CA), которые играют три роли — создание сертификатов, отзыв сертификатов и подтверждение сертификатов. Нам нужна сильная связь между владельцем ассиметричного ключа и самим ключом. Но как убедиться, что центр сертификации надежный? Ведь CA не может ничего, кроме как работать со своими приватными ключами. Увеличение длины ключей не компенсируют небезопасную систему, поскольку общая безопасность настолько слаба, насколько слаб самый слабый компонент в системе. То же самое относится и к проверяющему компьютеру — тому, который использует сертификат. Приватный ключ также может быть захвачен злоумышленником. Вывод: мы не можем слепо доверять центрам. Но вот несколько, которые можно рассмотреть: DigiCert, Entrust, thawte, Verisign, GoDaddy, или ваш собственный сервер. PKI состоит из CMS (Certificate Management System), VA (Validation Authority), CA (Certification Authority), RA (Registration Authority), DC (Digital Certificates) и конечный пользователь.

Всегда лучше убедиться в том, что ключ получен из достоверного источника, так как ключ уязвим и когда он передается, и когда хранится. Нужно знать имя владельца, сам ассиметричный ключ, время его валидности и цифровую подпись. Самый популярный формат сертификата X.509, как и для PKI. Формат сертификата X.509 задается на языке, называемом Abstract Syntax Notation One (ASN.1). Базовое правило кодирования включает три аббревиатуры: BER, DER, CER. DER и CER являются однозначными. Основной причиной, по которой были разработаны альтернативы, такие как сертификаты EMV — Europay-MasterCard-Visa (в отличие от принятия сертификатов X.509) это необходимость минимизировать длины сертификатов.

RFC 5280 описывает, как сертификаты X.509 должны использоваться в интернет-протоколах — говоря языком документа, это профиль X.509 (т.е. спецификация того, как должны использоваться определенные необязательные элементы). Он содержит описание формата X.509 и обсуждает ряд других тем, включая использование списков отзыва сертификатов (CRL). CRL решают давно известную проблему сертификатов открытых ключей, а именно то, что после выпуска они остаются действительными неограниченное время. Конечно, в сертификат можно включить дату истечения срока действия, и формат X.509 явно позволяет это сделать, но обычно сертификаты действуют в течение нескольких лет. Если закрытый ключ, соответствующий открытому ключу в сертификате, скомпрометирован, необходимо немедленно сделать сертификат недействительным.

Эта проблема может быть решена с помощью списков отзыва сертификатов (CRL). CRL — это список всех сертификатов, выпущенных данным ЦС, которые более не действительны. ЦС должен выпускать новый CRL через фиксированные, частые интервалы времени, что позволяет пользователю CRL проверять актуальность полученного CRL. Но главная роль проверять данные для аутентификации. Ведь самое сложное это отзыв ключа. Самоподписываемый сертификат безопасен за счет того, что это доказывает, что тот, кто создал сертификат, знает закрытый ключ, соответствующий открытому ключу в сертификате. Это может быть полезно, например, при запросе на то, чтобы ЦС создал «обычный» сертификат для открытого ключа. Открытый ключ содержится внутри сертификата, если так можно выразиться. Лучше CRL только OCSP. Самосертификация это сертификация собственного открытого ключа.

Почти невозможно контролировать, у кого доступ к публичному ключу. К счастью, замена публичного ключа происходит довольно легко. Но раз мы не знаем, кто имел доступ к ключу, не факт что сможем гарантировать доставку нового ключа для всех владельцев старого ключа. Отозвать старый ключ можно тремя способами: 1) CRL, что по факту Blacklist 2) Whitelist 3) короткий срок годности у сертификата. Для шифровки ключа используется блочный шифр. Для обмена ключами можно использовать квантовые технологии, причем обе стороны должны уметь обмениваться кубитами через специальные устройства. Злоумышленник не сможет подслушать сигнал, не изменив его. Протокол для передачи кубитов называется BB84, и… у него ограничения по дистанции, максимум сотни километров. Так что уже сейчас передавать ключи через квантум — реально, технология называется QKD.

Криптографический материал может храниться на устройстве, на процессоре Secure Enclave в случае с iOS. Для Android как всегда, все усложнено, но Bouncy Castle в общем случае помогает. Ваш сервер имеет закрытый ключ Котик, и открытый ключ Носик. Во время регистрации, открктый ключ Носик отправляется на все устройства. Устройство создает на своей стороне приватный ключ Запах, и ассоциирует его с полученным публичным ключом. И происходит ECDH. Далее по SHA-256 с открытым ключом сервера Носик и закрытым ключом Запах формирует два 128-битных значения, ключ подписи.

Также, существует identity-based-encryption (IBE), в котором доверенные третьи лица (TKC) участвуют в генерации сертификата. Подтвеждение личности и есть публичный ключ. Так, сертификат публичного ключа не требуется. Шаги реализации:

  • Шифрование: Маша получает публичный ключ PubB Сомчана, и шифрует этим ключом сообщение. Отправляет шифротекст Сомчану.
  • Идентификация. Сомчан заходит в свой аккаунт, и запрашивает PrvtB.
  • Извлечение приватного ключа. TKC извлекает PrvtB из PubB, и предоставляет специальное секретное значение TKC.
  • Распределение приватного ключа. Сомчан получает PrvtB от TKC.
  • Дешифрование. Сомчан использует PrvtB и читает сообщение от Маши.

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

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

Активация ключа. Если ключ хранится на компьютере конечного пользователя, то его активация это использование ключа. В худшем случае, пользователю надо ввести код для активации ключа. В более сложном случае, ключ генерируется на лету, или хранится на внешнем устройстве. Но если захотелось незапланированно сменить ключ, то это весьма дорого: особенно если это мастер-ключ на HSMs. Надо будет перегенерировать все зависимые ключи.

Уничтожение ключа. Рано или поздно ключ потеряет свою актуальность. Как общий совет, шифрование должно разруливаться централизованно, в простейшем случае — на http-gate, где стоит Nginx и Certbot, обновляющий и удаляющий сертификаты своевременно.

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

Прикладные кейсы

IoT. Связка SHA256 с AES-128 (с учётом соответствующей крипто-специфики типа «соли», счётчика пакетов и т. п.) на 99,(9) решает проблему безопасности в IoT. Простой и уже знакомый TLS (dTLS). Можно также применить специализированные железные решения наподобие дешёвой, но функциональной ATSHA204A — тогда хакеру будет трудно взломать систему. В LoRaWAN пользовательские данные шифруются по алгоритму AES-128 с соответствующим по длине ключом 128 бит (16 байт). Описанное можно реализовать на специальных микросхемах, вроде ATSHA204A.

Семейство SHA-2 это на данный момент рекомендация минимального уровня безопасности для IoT. И whirlpool с его 512 битами и с AES в основе. Для SHA-256 есть визуализация. Хэш-функции, как и блочный шифр, отрабатывают раундами. Другими словами, берется фиксированного размера блок и кешируется в функцию заданной длины. Либо Меркле-Дамгоре, что лежит в основе многих хэш-функций. У MD5 по стандарту RFC 1321 есть 128-битная хэш-функция, которая, безусловно, не рекомендуема к использованию. Видим MD5, выбираем MD6, SHA-2, SHA-3.

Также, может использоваться SHA-3, это не замена SHA-2. И Keccak — хэш-функция, на которой основан SHA-3, преобразовывает входные данные в нечитаемые для злоумышленника.

Базовые станции используют AES — алгоритм надёжный, при этом на минимально современных микроконтроллерах, даже не имеющих блока аппаратного шифрования, его использование не влечёт существенных накладных расходов: на Cortex-M3 с частотой 48 МГц один 16-байтный блок шифруется примерно за 100 мкс «с нуля». А Диффи-Хеллмана не используется, слишком накладно по производительности для такого класса устройств. Формально, могут использоваться отечетсвенные «Кузнечик» и «Магма», но я в своей практике ни разу с ними не сталкивался.

Wi-Fi требует защищенного канала, поэтому использует WPA3, WPA2, полагается на 256-битный ключ шифрования, метод аутентификации Pre-Shared Key (PSK). Wi-Fi использует блочный шифр, ключ находится в роутере. Во всех перечисленных случаях клиенты и беспроводная точка доступа используют один и тот же секретный ключ. Обновлённый протокол беспроводной безопасности WPA3 дополнился встроенной защитой от brute-force атак (атак методом полного перебора), усовершенствованным стандартом криптографии -192-разрядным пакетом безопасности, более простой настройкой устройств, индивидуальным шифрованием информации, что усилило конфиденциальность в открытых сетях Wi-Fi.

Иногда можно встретить 3DES. Это обычный DES, который генерирует три разных ключа. Ключи могут быть разными, или одинаковыми. Но он долго шифрует, и его эффективность безопасности можно уронить до 112 бит. Другими словами, алгоритм дырявый. AES быстрее и лучше, хоть и был изначально сделан для железок. Если вас будет пытаться взломать школьник-сосед, то длины ключа 32 вам хватит. Для защиты от атак на малые организации в 2012 году длина ключа была 80, в 2022 длина ключа 112, и против квантовых компьютеров длина ключа 256.

Wi-Fi умеет в аутентифицированное шифрование при использование режима CCM в WPA2 и режима GCM в WPA3.

Криптовалюты. Цифровая подпись биткоина — ECDSA. Цифровую подпись может верифицировать кто угодно с ключом верификации. Открытый ключ используется для отправки криптовалюты в кошелек. Bitcoin — это, по сути, односторонняя «автономная» коммуникация, как и электронная почта. В схеме цифровой подписи DSA многое позаимствовано от ElGamal, с эллиптической кривой secp256k1. Криптовалюты используют закрытый ключ для проверки транзакций и доказательства владения адресом в блокчейне. Если кто-то отправляет вам один биткоин (BTC), закрытый ключ необходим для «разблокировки» транзакции и доказательства того, что теперь вы владеете этим биткоином.

Мобильные звонки полагаются на предраспрделенные ключи и не нуждаются в аутентификации происхождения данных. Используют симметричное шифрование, требуют защищенного канала по потоковому шифру. Звонки GSM не шифруются полностью end-to-end, но шифруются на многих участках своего пути, поэтому случайные люди не могут просто прослушивать телефонные разговоры через эфир, как радиостанцию. Обмен ключами шифрования, который устанавливает безопасное соединение между вашим телефоном и ближайшей сотовой вышкой, происходит при каждой новой инициализации звонка. Этот обмен дает ключи для разблокировки данных и вашему устройству, и вышке. Так как индустрия мобильных звонков весьма старая по меркам Интернета, все еще можно встретить алгоритмы шифрования GEA-1 и GEA-2, которые применялись в сетях GSM первых трёх поколений, и они весьма уязвимы. С приходом LTE они должны были кануть в лету, но по факту, многие мобильные операторы продолжают использовать их и в наши дни ради совместимости со старым оборудованием.

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

Поэтому для мобильных звонков используется двухэтапный процесс шифрования, основанный на аутентификации и шифровании разговора. В процессе аутентификации генерируется сертификат, зашифрованный с помощью алгоритма RSA. Но держим в уме бекдор: он может быть вставлен либо в алгоритм шифрования, либо в детерминированный генератор. Пример Dual_EC_DBRG. Либо алгоритм ZUC, который используется китайскими мобильными операторами.

Карты идентификации. Они дают визуальную идентификацию, digital-данные, аутентификацию, и функцию подписи. Очевидно, нужно иметь возможность убедиться, что карта RFID не была модифицирована с момента выпуска. Для магнитных/банковских карт применяется стандарт ISO/IEC 7810, по которому нужно уместить в 250 байт имя, данные банковской карты и доп информацию. Для smart-карт применяется стандарт ISO/IEC 7816, и такие карты труднее скопировать, чем банковские. Используется криптография с открытым ключом (ассиметрия), шифрование RSA 1024, а более новые вплоть до 2048. Раньше длина асимметричных ключей составляла 1024 бита, но после нескольких крупных инцидентов в сфере кибербезопасности в прошлом, длина асимметричных ключей теперь составляет 2048 бит. Большинство карт содержат пару аутентификационных ключей, и non-repudiation пару ключей. Автомобильный въезд в его простейшей форме является в первую очередь механизмом контроля доступа и не требует создания защищенного канала для передачи данных, кроме того, который необходим для обеспечения аутентификации субъекта. В более сложном варианте учтена иерархия ключей.

Нам интереснее рассмотреть документ гражданина страны, а не карту для въезда на парковку. Для удостоверений личности, корневой сертификат будет RSA 2048 бит. Карта содержит 5 сертификатов: корневой, гражданина, eID аутентификация, non-repudiation и сертификат нормативных стандартов. Такая карта сертифицирована по x.509 третьей версии. Выглядит довольно сложной, и процесс выпуска eID включает работу сразу нескольких государственных организаций. Для обновления сертификата используется CRL.

E-mail. Для шифрования электронной почты используются асимметричные и симметричные ключи, и оба метода обеспечивают одинаковый уровень безопасности, но работают по-разному. Общая цель одна: никто иной не сможет прочитать сообщения. Возьмем в качестве примера Gmail. Открытый ключ встроен в сертификат TLS/SSL и используется для шифрования данных от отправителя. Закрытый ключ находится в отдельном файле, который должен надежно храниться на вашем сервере и может использоваться как для шифрования, так и для дешифрования. Открытый ключ встроен в SSL-сертификат, а закрытый ключ хранится на сервере и держится в секрете. Чтобы взломать сообщение электронной почты, зашифрованное с помощью асимметричного шифрования RSA, которое широко используется для защиты деловой переписки, злоумышленнику потребовались бы все вычислительные мощности, имеющиеся в настоящее время на Земле, и все равно это заняло бы более 10 миллиардов лет.

Защита Email часто ассоциируется с PGP (Pretty Good Privacy), да и десктопное шифрование зачастую это PGP, только называется GPG. Если нужна криптографическая защита, то добавляется S/MIME. PGP умеет не только шифровать/дешифровать, но способен уменьшать размер сообщения. PGP используется и по сей день, особенно под брендом Symantec Encryption Desktop. PGP полагается на WoT.

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

Существует множество атак, вот список основных:

  • Frequency Analysis
  • Brute Force
  • Trickery and Deceit
  • One-Time Pad
  • Plaintext
  • Chosen-ciphertext
  • Chosen-plaintext
  • Chosen-key
  • Rubber Hose
  • Rainbow Table
  • Ciphertext only
  • Man-in-the-middle
  • Related-key
  • Dictionary
  • Timing
  • Adaptive chosen-plaintext
  • DROWN
  • Side-channel
  • Birthday
  • Hash Collision
  • DUNK
  • Meet-in-the-middle
  • Padding Oracle

От каждой атаки защищаться бесполезно, главное — придерживаться подходов, что приведены в статье.

2 комментария

  1. Pavel Munrocket

    Как перехватываются сессионные ключи для браузера?

    • Цветков Максим (Author)

      Для Windows, запустить скрипт:
      @echo off
      killall chrome
      set SSLKEYLOGFILE=F:\keylogfile.txt
      start chrome

      На Mac в терминале: export SSLKEYLOGFILE=/user/Desktop/keylogfile.txt
      open -a "Google Chrome.app"

      Далее в Wireshark нужно указать файл keylogfile.

      Это расшифрует информацию. Находим нужный фрейм командой frame contains "avito" и изучаем.

«Взаимодействуя с данным сайтом, вы, как пользователь, автоматически даете согласие согласие на обработку персональных данных» Согласие

Этот сайт использует Akismet для борьбы со спамом. Узнайте, как обрабатываются ваши данные комментариев.