Forward secrecy что это
Заметки про SSL/TLS: forward, backward secrecy
Секретность будущих сообщений означает, что при утечке приватного ключа в асимметрическом шифровании (private key), все будущие сообщения можно будет расшифровать «на лету».
Секретность прошлых сообщений означает, что при утечке приватного ключа в асимметрическом шифровании (private key), все прошлые сообщения записанные хакером(network attacker threat model) можно будет расшифровать.
Необходимо отметить, что имеется ввиду приватный ключ сервера, а не клиента.
Также следует добавить, что для данного конкретного примера в контексте использования алгоритма Ephemeral Diffie-Hellman, сам алгоритм имеет оба свойства (секретность будущих и прошлых сообщений). Но в других алгоритмах и схемах доставки сообщений (commitment schemes) алгоритм может предоставлять секретность будущих сообщений, но не прошлых. Один из примеров — Timed effecient commitment scheme with bounded sender.
При утере приватного ключа RSA хакер получает возможность расшифровать все записанные прошлые сообщения и будущие сообщения. Реализация обмена ключей в RSA является односторонней (non-contributory): вся необходимая информация для образования симметричного ключа, который создается на этапе рукопожатия (SSL/TLS handshake), пересылается на сервер и зашифрована публичным ключом (public key) сервера. Раскрытие приватного ключа дает возможность узнать симметричный ключ данной сессии.
Механизм Fixed Diffie-Hellman использует постоянный публичный ключ (g^a mod p), который прописан в сертификате сервера. Это также означает, что при каждом новом соединении, клиент (браузер) предоставляет свою часть ключа (g^b mod p). После обмена ключами, образуется новый симметрический ключ (g^(ab) mod p) для обмена информацией для текущей сессии. При раскрытии приватного ключа Diffie-Hellman (a из g^a mod p) сервера, хакер сможет расшифровать ранее записанные сообщения, а также все будущие сообщения. Это становится возможным из-за самого механизма Diffie-Hellman: (g^a mod p) ^b mod p = g^(ab) mod p. Так как хакеру известен частный ключ сервера, он сможет узнать симметричный ключ каждой сессии и даже тот факт, что механизм образования ключа является двусторонним (contributory) не поможет.
Механизм Anonymous Diffie-Hellman не предоставляет гарантий секретности ибо данные передаются незашифрованными.
Единственный вариант, при котором гарантируется безопасность прошлых и будущих сообщений — Ephemenral Diffie-Hellman. Разница по сравнению с ранее рассмотренными методами заключается в том, что при каждом новом соединении сервером и клиентом создается одноразовый ключ (g^a mod p и g^b mod p). Таким образом, даже если хакеру достанется текущий частный ключ, он сможет расшифровать только текущую сессию, но не предыдущие или будущие сессии.
Надежная защита от прослушивания: как работает технология совершенная прямая секретность
Совершенная прямая секретность (Perfect Forward Secrecy, PFS) предотвращает возможность того, что АНБ сможет расшифровать веб-коммуникации. Однако пока этот метод, к сожалению, применяется редко.
Американская спецслужба АНБ последовательно подорвала механизмы обеспечения безопасности веб-коммуникаций. По большому счету, она прослушивает все данные, проходящие по крупным кабелям или через Интернет-узлы, и каждый пользователь, шифрующий свой обмен данными, вызывает подозрения.
Политическими методами едва ли можно остановить трансатлантического «Большого брата». Технически — уже возможно: с помощью Perfect Forward Secrecy (совершенная прямая секретность).
По словам Сноудена, данный метод является лучшим инструментом для защиты от глобального прослушивания, но так как браузер и сервер по умолчанию устанавливают HTTPS-соединения, стойкость шифрования не реализуется.
Принцип работы у HTTPS следующий: сначала сервер отправляет браузеру публичный ключ, адаптированный к его частному ключу, с помощью которого, в свою очередь, можно расшифровать сообщения браузера. После установления связи оба ключа изменяются на менее интенсивное симметричное шифрование для собственно обмена данными. Для этого им необходимо согласовать ключ сеанса и криптографический метод (например, AES). Согласование ключа сессии осуществляется на последнем этапе установления соединения.
Асимметричное шифрование обладает слабыми местами
Браузер и сервер с помощью двух ключей (частного и публичного — Private и Public key) создают безопасное соединение, которое затем защищается ключом сеанса (Session key). Если шпион, который фиксирует все коммуникационные данные, получит доступ к публичному ключу сервера, он сможет расшифровать и ключ сеанса, так как он передается по Интернету.
Perfect Forward Secrecy (PFS, «совершенная прямая секретность») — надежное решение
В случае PFS ключ сеанса не передается через Интернет. Вместо этого браузер и сервер согласовывают математический метод и секретное случайное число, известное только им. Таким образом, каждый из них по отдельности вычисляет один и тот же ключ сеанса, который впоследствии уничтожается. Шпион не может вычислить ключ сеанса.
Применение PFS на практике
Применение PFS на практикеСистема PFS пока применяется достаточно редко.
От 66 до 99% (в зависимости от браузера) соединений
с SSL-сайтами не используют PFS.
Фактор длины ключа
Фактор длины ключаБолее длинные ключи надежнее, однако нагружают процессор. Если сравнивать издержки для различных методов при равной надежности, то лидером в области веб-шифрования является ECDHE.
Слабое звено — частный ключ
В настоящий момент шпион записывает только зашифрованную «абракадабру». Однако если позже он получит доступ к частному ключу сервера, то сможет извлечь ключ сеанса и с его помощью — данные из существующей «абракадабры». Так, АНБ хотело бы заполучить частный ключ Ладара Левисона, основателя почтовой службы Lavabit, так как Сноуден регулярно пользовался его услугами.
Вместо того, чтобы передать ключ АНБ, Левисон предпочел закрыть сервис электронной почты. Этого не произошло бы с ним при применении Perfect Forward Secrecy (PFS), поскольку в PFS частный ключ не используется. Кроме того, в случае PFS ключ не отправляется через Интернет, а рассчитывается обеими сторонами самостоятельно: за этим стоит чистая математика. PFS использует для этого обмен ключами по алгоритму Диффи-Хеллмана (DHE).
В классическом DHE (см. схему выше) сервер определяет параметры (простое число и первообразный корень) для математической формулы, в которую обе стороны подставляют собственное случайное число. Стороны отправляют результат, затем повторяют расчет с результатом другой стороны, и в заключение оценивают итог: должно получиться одно и то же число.
В Firefox щелчок по HTTPS в адресной строке показывает, активен ли PFS. В описании в этом случае присутствует DHE или ECDHE
Далее стороны принимают его в качестве ключа сеанса для симметричного шифрования, а после завершения обмена данными уничтожают ключ. Расшифровать переданную информацию после уничтожения ключа не сможет никто, в том числе и сами стороны.
Математика блокирует шпиона
Хотя всемогущая служба прослушивания, такая как АНБ, и знает параметры и соответствующий результат случайных чисел, все же для взлома ключа она должна узнать как минимум одно из случайных чисел. Они применяются в расчетах в качестве показателя степени. Для их определения шпион должен решить логарифмическое уравнение с двумя неизвестными случайными числами, что крайне накладно, однако вовсе не является невозможным. Поэтому серверы и браузеры для защиты от взлома методом подбора используют очень большие простые числа — например, длиной 2048 бит.
Наряду с классическим алгоритмом Диффи-Хеллмана также существует процедура обмена ключами на базе эллиптических кривых (ECDHE). Этот математический метод является более сложным; так, ECDHE должен проводить расчеты с меньшим количеством больших простых чисел, что облегчает работу процессору и ускоряет расчет ключа сессии.
Практически во всех известных браузерах реализован принцип Perfect Forward Secrecy для DHE и ECDHE, однако в сочетании не со всеми методами симметричного шифрования. Для серверов действует аналогичное утверждение: они по-прежнему очень редко выбирают PFS для обмена ключами.
Математический глоссарий
Простое число — число, которое делится только на себя и на единицу, например, 23.
Остаток от деления (mod) — остаток, который остается при делении целых чисел.
Пример: 17 mod 3 = 2, так как 17:3 = 5, остаток равен 2. Второй пример, поясняющий еще раз: 17 mod 4 = 1, так как 16:4 = 4,
остаток равен 1.
Первообразный корень — число n, показатель степени которого составляют все остатки до n–1. Пример: число 3 является первообразным корнем по модулю 7, так как расче-
ты от 31 mod 7 до 36 mod 7 дают все числа от 1 до 6 (36 mod 7 = 1; 32 mod 7 = 2; 31 mod 7 = 3, 34 mod 7 = 4; 35 mod 7 = 5 и 33 mod 7 = 6).
Perfect forward secrecy
Совершенная прямая секретность (англ. Perfect forward secrecy, PFS [1] ) — свойство некоторых протоколов согласования ключа (Key-agreement), которое гарантирует, что сессионные ключи, полученные при помощи набора открытых и закрытых ключей долговременного пользования, не будут скомпрометированы, при компрометации одного из закрытых ключей.
Совершенная прямая секретность (PFS) означает, что если третья сторона узнает какой-либо сеансовый ключ, то она сможет получить лишь доступ к данным, защищенных лишь этим ключом. Для сохранения совершенной прямой секретности ключ, используемый для шифрования передаваемых данных, не должен использоваться для получения каких-либо дополнительных ключей. Также, если ключ, используемый для шифрования передаваемых данных, был получен ( derived ) на базе какого-то еще ключевого материала, этот материал не должен использоваться для получения каких-либо других ключей. [4]
Содержание
История
Свойство PFS было предложено [5] Диффи, van Oorschot и Wiener и относилось к протоколу Station-to-Station (STS), в котором ключами долговременного пользования являются закрытые ключи. PFS требует использования асимметричной криптографии и не может быть реализован исключительно при помощи симметричных криптоалгоритмов.
Термин PFS также применялся [6] при описании аналогичного свойства в протоколах согласования ключей с аутентификацией по паролю (password-authenticated key agreement), в которых ключом долговременного пользования является пароль, известный обоим сторонам.
Приложение Annex D.5.1 стандарта IEEE 1363—2000 описывает связанные свойства one-party forward secrecy и two-party forward secrecy различных стандартных схем согласования ключа.
Протоколы
См. также
Примечания
Ссылки
Полезное
Смотреть что такое «Perfect forward secrecy» в других словарях:
Perfect forward secrecy — In an authenticated key agreement protocol that uses public key cryptography, perfect forward secrecy (or PFS) is the property that ensures that a session key derived from a set of long term public and private keys will not be compromised if one… … Wikipedia
Perfect Forward Secrecy — Folgenlosigkeit (engl. perfect forward secrecy, PFS; auf deutsch etwa „perfekt fortgesetzte Geheimhaltung“) bedeutet in der Kryptographie die Eigenschaft von Verschlüsselungsverfahren, dass aus einem aufgedeckten Schlüssel nicht auf vorhergehende … Deutsch Wikipedia
Off-the-Record Messaging — Off the Record Messaging, appelé communément OTR, est un protocole cryptographique. Sommaire 1 Description 2 Disponibilité 2.1 D origine dans 2.2 Sous forme de plugin … Wikipédia en Français
Off-the-record messaging — Off the Record Messaging, appelé communément OTR, est un protocole cryptographique. Sommaire 1 Description 2 Disponibilité 2.1 D origine dans 2.2 Sous forme de plugin … Wikipédia en Français
Diffie-Hellman key exchange — (D H) is a cryptographic protocol that allows two parties that have no prior knowledge of each other to jointly establish a shared secret key over an insecure communications channel. This key can then be used to encrypt subsequent communications… … Wikipedia
Diffie–Hellman key exchange — (D–H)[nb 1] is a specific method of exchanging keys. It is one of the earliest practical examples of key exchange implemented within the field of cryptography. The Diffie–Hellman key exchange method allows two parties that have no prior knowledge … Wikipedia
Off-the-Record Messaging — Off the Record Messaging, commonly referred to as OTR, is a cryptographic protocol that provides strong encryption for instant messaging conversations. OTR uses a combination of the AES symmetric key algorithm, the Diffie–Hellman key exchange,… … Wikipedia
Tor (anonymity network) — Tor Developer(s) The Tor Project[1] Initial release 20 September 2002 (2002 09 20) … Wikipedia
Authentication Header — IPsec im TCP/IP‑Protokollstapel: Anwendung HTTP IMAP SMTP DNS … Transport TCP UDP … Deutsch Wikipedia
Encapsulated Security Payload Protocol — IPsec im TCP/IP‑Protokollstapel: Anwendung HTTP IMAP SMTP DNS … Transport TCP UDP … Deutsch Wikipedia
Криптографические протоколы: определения, запись, свойства, классификация, атаки
Данный текст будет являться одной из переписанных глав для учебного пособия по защите информации кафедры радиотехники и систем управления, а также, с этого учебного кода, кафедры защиты информации МФТИ (ГУ). Полностью учебник доступен на github (см. также draft releases). На хабре планирую выкладывать новые «большие» куски, во-первых, чтобы собрать полезные комментарии и замечания, во-вторых, дать сообществу больше обзорного материала по полезным и интересным темам.
Основные понятия
Для успешного выполнения любых целей по защите информации необходимо участие в процессе защиты нескольких субъектов, которые по определённым правилам будут выполнять технические или организационные действия, криптографические операции, взаимодействовать друг с другом, например, передавая сообщения или проверяя личности друг друга.
Формализация подобных действий делается через описание протокола. Протокол — описание распределённого алгоритма, в процессе выполнения которого два или более участников последовательно выполняют определённые действия и обмениваются сообщениями (Здесь и далее в этом разделе определения даны на основе [Cheremushkin:2009]).
Под участником (субъектом, стороной) протокола понимают не только людей, но и приложения, группы людей или целые организации. Формально участниками считают только тех, кто выполняет активную роль в рамках протокола. Хотя при создании и описании протоколов забывать про пассивные стороны тоже не стоит. Например, пассивный криптоаналитик формально не является участником протоколов, но многие протоколы разрабатываются с учётом защиты от таких «неучастников».
Протокол состоит из циклов (англ. round) или проходов (англ. pass). Цикл — временной интервал активности только одного участника. За исключением самого первого цикла протокола, обычно начинается приёмом сообщения, а заканчивается — отправкой.
Цикл (или проход) состоит из шагов (действий, англ. step, action) — конкретных законченных действий, выполняемых участником протокола. Например:
Можно сказать, что протокол прескрептивно описывает правила поведения каждой роли в протоколе. А сеанс это дескриптивное описание (возможно теоретически) состоявшейся в прошлом реализации протокола.
Пример описания протокола.
Запись протоколов
Для записи протоколов, связанных с реализацией функций защиты информации, не используют выражения вроде «участник с ролью «Отправитель»», а заменяют их на краткие обозначения вроде «отправитель» или используют общепринятые экземплификанты: Алиса, Боб, Клара, Ева и т., д. При этом используют следующие соглашения.
В данном пособии мы будем придерживаться промежуточного формата записи.
Либо, отводя отдельный столбец для каждого участника.
Для сокращения описания и упрощения сравнения разных протоколов используют следующие соглашения об обозначениях передаваемых данных.
Свойства безопасности протоколов
Защищённая система и, соответственно, защищённый протокол могут выполнять разные функции безопасности. Многие из этих функций или целей (англ. goals) можно сформулировать как устойчивость к определённому классу атак. Наиболее полным и актуальным считается перечисление и толкование этих целей в документе проекта AVISPA (англ. Automated Validation of Internet Security Protocols and Applications) [AVISPA], суммирующим описания из различных документов IETF (англ. Internet Engineering Task Force). Данные цели принято считать формализируемыми — то есть такими, что для отдельных протоколов есть возможность формально доказать или опровергнуть достижение этих целей.
Гарантия возможности доказать, что факт нахождения системы в одном из состояний означает, что некогда в прошлом система хотя бы раз находилась в некотором другом состоянии. Например, что получение субъектом доступа к ресурсу означает, что некогда в прошлом субъект успешно оплатил данный доступ.
Примеры свойств безопасности, реализуемыми различными протоколами приведены в таблице.
Классификация протоколов
Общепризнанная классификация защитных протоколов отсутствует. Однако можно выделить набор объективных и однозначных признаков, классифицирующих протоколы.
Классификация по «полноте» выполняемых функций проблематична из-за того, что ни один протокол нельзя назвать в полной мере «прикладным». Любой протокол сам по себе это лишь часть некоторой информационной (или организационной) системы, которая как раз и выполняет требуемую пользователями функцию. Однако можно говорить о том, что отдельные протоколы (например, TLS) являются протоколами более высокого уровня, чем протоколы, например, Диффи—Хеллмана, так как последний часто выступает составной частью того же протокола TLS.
Атаки на протоколы
Защищённые свойства протоколов могут быть заявленными, когда о них заявляют сами авторы протокола (и, обычно, приводят различные аргументы в пользу выполнения данных функций), и подразумеваемыми, когда авторы некоторой системы рассчитывают на реализацию защищённых свойств некоторым протоколом.
Под атакой на защищённый протокол понимается попытка проведения анализа сообщений протокола и/или выполнения непредусмотренных протоколом действий для нарушения заявленных или подразумеваемых свойств протокола. (Используется модифицированное определение из [Cheremushkin:2009]. Отличие в том, что Черёмушкин в своём определении не описывает, что такое «нарушение работы протокола» и оставляет двусмысленными случаи нарушения, например, свойств G9/PFS и G20/STP.)
Атака считается успешной, если нарушено хотя бы одно из заявленных или подразумеваемых свойств протокола.
В случае успешной атаки на подразумеваемые свойства будем уточнять, что успешна атака на использование протокола в некоторой системе. Это будет говорить, разумеется, не о недостатках самого протокола, но о неверном выборе протокола (или его настроек) авторами системы.
Существует большое количество типов атак на протоколы. У многих атак есть некоторые общие принципы, что позволяет выделить классы атак для упрощения анализа и разработки протоколов, устойчивых к целым классам атак.
Класс атак на протоколы с аутентификацией ключа, в которых злоумышленник получает возможность доказать одной из сторон владение ключом (с помощью, например, повтора сообщения из легального сеанса), хотя сам ключ злоумышленник не знает. К такому классу атак уязвим, например, симметричный протокол Нидхема-Шрёдера.
Важно отметить, что если не сказано иное, то в рамках анализа криптографических протоколов (не конкретных систем) используется предположение о стойкости всех используемых криптографических примитивов. Например, предполагается, что пока идёт защищённый обмен информацией, использующий сеансовый ключ, выработанный в сеансе некоторого криптографического протокола, то злоумышленнику не хватит ресурсов и времени на то, чтобы получить данный сеансовый ключ через атаку на используемые шифры или криптографически-стойкие хеш-функции.
С другой стороны, следует предполагать, что сеансовые ключи, получаемые в рамках сеансов протоколов, через некоторое время (однако, много большее времени самого сеанса связи) будут получены злоумышленником (классы атак STS и KN). А через значительно более время злоумышленник сможет получить и доступ к «мастер»-ключам — ключам длительного использования, так что протоколы с генерацией сеансовых ключей должны разрабатываться в том числе со свойством G9/PFS.
(Дальше идут разделы с описанием конкретных протоколов.)
Объяснение протокола SRTP
Протокол SRTP (Secure Real-time Transport Protocol) это система безопасности, которая расширяет протокол RTP (Real-time Transport Protocol) набором защитных механизмов.
WebRTC использует DTLS-SRTP для шифрования, аутентификации и целостности сообщений, а также для защиты от атак повторного воспроизведения. Это дает конфиденциальность за счет шифрования RTP-нагрузки и проверки подлинности. SRTP это один из компонентов для безопасности, он очень удобен для разработчиков, которые ищут надежное и безопасное API. Но что такое SRTP и как оно работает?
Что такое SRTP?
SRTP повышает безопасность RTP. Протокол был опубликован организацией IETF (Internet Engineering Task Force) в стандарте RFC 3711, в марте 2004.
SRTP обеспечивает конфиденциальность за счет шифрования RTP-нагрузки, не включая заголовки RTP. Также поддерживается проверка подлинности, которая широко используется как защитный механизм в RTP. В то время как SRTP можно использовать во всей его полноте, также возможно отключать/включать определенные функции. Главный затык в SRTP – это управление ключами, так как вариантов много: DTLS-SRTP, MIKEY в SIP, SDES (Security Description) в SDP, ZRTP и пр.
Шифрование
SRTP использует AES (Advanced Encryption Standard) как шифр по умолчанию. В AES два режима шифрования: режим счетчика (Segmented Integer Counter Mode) и режим f8. Обычно используется режим счетчика – он критично важен при передаче трафика по ненадежной сети с потенциальной потерей пакетов. Режим f8 используется в мобильных 3G-сетях и является вариантом режима обратной связи (Output Feedback), в котором расшифровка происходит так же, как и шифрование.
Еще SRTP позволяет разработчикам отключать шифрование с помощью нулевого шифра. Нулевой шифр не делает шифрование, он копирует входящий поток напрямую в исходящий, без изменений.
В WebRTC не рекомендуется использовать нулевой шифр, так как сохранность данных довольно важна для конечных пользователей. В действительности, валидные реализации WebRTC ДОЛЖНЫ поддерживать шифрование, на данный момент с DTLS-SRTP.
Целостность
Чтобы сохранить целостность сообщений в SRTP, на основание содержимого и части пакетных заголовков с помощью алгоритма создается аутентификационная метка, которая затем добавляется в RTP-пакет. Эта метка используется для валидации содержимого полезной нагрузки, что, в свою очередь, предотвращает фальсификацию данных.
Аутентификация – это также основа для отражения атак повторного доступа. Для их блокировки каждому пакету назначается последовательный индекс. Новое сообщение будет принято только в том случае, если его индекс – следующий по порядку и еще не был получен. Индексы эффективны благодаря целостности, описанной чуть выше; без нее есть вероятность подмены индексов.
Хотя в WebRTC в основном используется алгоритм HMAC-SHA1 для целостности в SRTP, строго рекомендуется выбирать наборы алгоритмов с PFS (Perfect Forward Secrecy) поверх non-PFS и AEAD (Authenticated Encryption with Associated Data) поверх non-AEAD. Последние реализации WebRTC используют DTLS v1.2 c набором алгоритмов TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256.
Ключи
SRTP использует функцию формирования ключа (KDF) для создания ключей на основе мастер-ключа. Протокол управления ключами создает все ключи в сессии с помощью мастер-ключа. За счет того, что у каждой сессии свой уникальный ключ, все сессии защищены. Поэтому, если одна сессия была скомпрометирована, то остальные по-прежнему под защитой. Протокол управления ключами используется для мастер-ключа – обычно это ZRTP или MIKEY, но есть и другие разновидности.
Потоки в WebRTC защищены одним из двух протоколов: SRTP или DTLS (Datagram Transport Layer Security). DTLS – для шифрования потоков данных, SRTP – для медиапотоков. Тем не менее, для обмена ключами в SRTP используют DTLS-SRTP, чтобы определять атаки посредника. Это детально раскрыто в документах IETF: WebRTC security и security arch.
SRTCP (Secure Real-time Transport Control Protocol)
У SRTP есть родственный протокол – SRTCP (Secure Real-time Transport Control Protocol). SRTCP расширяет RTCP (Real-time Transport Control Protocol) теми же функциями, что SRTP расширяет RTP, включая шифрование и аутентификацию. Подобно SRTP, почти все функции безопасности SRTCP можно отключить, кроме аутентификации сообщений – оно необходима для SRTCP.
Подводные камни SRTP
SRTP шифрует полезную нагрузку RTP-пакетов, но не расширение заголовков. Так появляется уязвимость, так как расширение заголовка в RTP-пакете может содержать важную информацию, например, уровни звука каждого пакета в медиапотоке. Потенциально это может быть знаком для злоумышленника, что в сети происходит общение двух людей – приватность беседы может быть нарушена. Данное обстоятельство рассматривалось в документе IETF Request for Comments: 6904, который требует от всех последующих реализаций SRTP шифровать расширения заголовков.
В некоторых случаях – например, конференция со множеством участников – может быть необходим посредник в виде SFM (Selective Forwarding Mixer), чтобы оптимизировать RTP-параметры во время проброса потоков. Такой посредник нарушает принцип сквозного шифрования, которое используется в peer-to-peer системах; иными словами, конечные устройства должны “доверять” еще одному участнику. Для обхода этого ограничения, Privacy Enhanced RTP Conferencing (PERC, одна из рабочих групп IETF – прим.переводчика) работает над решениями вроде процедур двойного шифрования в SRTP. PERC дают гарантии, подкрепленные hop-by-hop и сквозным шифрованиями в двух раздельных, но родственных контекстах. Мы обязательно расскажем об этом в следующих постах!