Прямая секретность
В криптографии не будут скомпрометированы , прямая секретность ( FS ), также известная как совершенная прямая секретность ( PFS ), представляет собой функцию определенных протоколов согласования ключей , которая дает гарантии того, что ключи сеанса даже если при обмене ключами сеанса используются долгосрочные секреты. скомпрометированы, что ограничивает ущерб. Для HTTPS долгосрочным секретом обычно является закрытый ключ сервера. Прямая секретность защищает прошлые сеансы от будущего взлома ключей или паролей. Генерируя уникальный сеансовый ключ для каждого сеанса, инициируемого пользователем, компрометация одного сеансового ключа не повлияет ни на какие данные, кроме тех, которыми обмениваются в конкретном сеансе, защищенном этим конкретным ключом. Этого самого по себе недостаточно для прямой секретности, которая дополнительно требует, чтобы долгосрочная компрометация секрета не влияла на безопасность прошлых сеансовых ключей.
Прямая секретность защищает данные на транспортном уровне сети, которая использует общие протоколы безопасности транспортного уровня, включая OpenSSL . [ 1 ] когда его долгосрочные секретные ключи скомпрометированы, как в случае с ошибкой безопасности Heartbleed . Если используется прямая секретность, зашифрованные сообщения и сеансы, записанные в прошлом, не могут быть извлечены и расшифрованы, если долгосрочные секретные ключи или пароли будут скомпрометированы в будущем, даже если злоумышленник активно вмешался, например, через «человека в кадре». средняя (MITM) атака .
Ценность прямой секретности заключается в том, что она защищает прошлые сообщения. Это снижает мотивацию злоумышленников компрометировать ключи. Например, если злоумышленник узнает долгосрочный ключ, но компрометация обнаружена, а долгосрочный ключ отозван и обновлен, в системе прямой защиты произойдет утечка относительно небольшой информации.
Ценность прямой секретности зависит от предполагаемых возможностей противника. Прямая секретность имеет значение, если предполагается, что злоумышленник может получить секретные ключи от устройства (доступ для чтения), но либо обнаружен, либо не может изменить способ генерации сеансовых ключей на устройстве (полная компрометация). В некоторых случаях злоумышленник, который может читать долгосрочные ключи с устройства, может также иметь возможность изменить работу генератора сеансовых ключей, как в детерминированном генераторе случайных битов с двойной эллиптической кривой с бэкдором . Если злоумышленник сможет сделать генератор случайных чисел предсказуемым, то прошлый трафик будет защищен, но весь будущий трафик будет скомпрометирован.
Ценность прямой секретности ограничена не только предположением, что злоумышленник будет атаковать сервер, только украв ключи и не изменяя генератор случайных чисел, используемый сервером, но также ограничено предположением, что злоумышленник будет только пассивно собирать трафик. на канале связи и не проявлять активности, используя атаку «человек посередине». Прямая секретность обычно использует эфемерный обмен ключами Диффи-Хеллмана для предотвращения чтения прошлого трафика. Обмен эфемерными ключами Диффи-Хеллмана часто подписывается сервером с использованием статического ключа подписи. Если злоумышленник может украсть (или получить по решению суда) этот статический (долгосрочный) ключ подписи, он может замаскироваться под сервер для клиента и под клиента для сервера и реализовать классический «человек посередине». атака. [ 2 ]
История
[ редактировать ]Термин «совершенная прямая секретность» был введен К.Г. Гюнтером в 1990 году. [ 3 ] и далее обсуждалось Уитфилдом Диффи , Полом ван Оршотом и Майклом Джеймсом Винером в 1992 году. [ 4 ] где он использовался для описания свойства протокола между станциями. [ 5 ]
Прямая секретность также использовалась для описания аналогичного свойства протоколов соглашения о ключах, аутентифицированных паролем , где долгосрочным секретом является (общий) пароль . [ 6 ]
В 2000 году IEEE впервые ратифицировал стандарт IEEE 1363 , который устанавливает соответствующие свойства односторонней и двусторонней секретности для различных стандартных схем соглашения о ключах. [ 7 ]
Определение
[ редактировать ]Система шифрования обладает свойством прямой секретности, если проверка обмена данными в открытом (расшифрованном) виде, происходящая на этапе согласования ключей при инициировании сеанса, не выявляет ключ, который использовался для шифрования оставшейся части сеанса.
Пример
[ редактировать ] |
Ниже приведен гипотетический пример простого протокола обмена мгновенными сообщениями, использующего прямую секретность:
- Алиса и Боб генерируют по паре долгосрочных асимметричных открытого и закрытого ключей , а затем проверяют отпечатки открытых ключей лично или по уже аутентифицированному каналу. Проверка с уверенностью устанавливает, что заявленный владелец открытого ключа является фактическим владельцем.
- Алиса и Боб используют алгоритм обмена ключами, такой как Диффи-Хеллман , для безопасного согласования эфемерного сеансового ключа . Они используют ключи из шага 1 только для аутентификации друг друга во время этого процесса.
- Алиса отправляет Бобу сообщение, шифруя его симметричным шифром с использованием сеансового ключа, согласованного на шаге 2.
- Боб расшифровывает сообщение Алисы, используя ключ, согласованный на шаге 2.
- Процесс повторяется для каждого нового отправленного сообщения, начиная с шага 2 (и переключения ролей Алисы и Боба в качестве отправителя/получателя в зависимости от ситуации). Шаг 1 никогда не повторяется.
Прямая секретность (достигаемая путем создания новых сеансовых ключей для каждого сообщения) гарантирует, что прошлые сообщения не могут быть расшифрованы, если один из ключей, сгенерированных на итерации шага 2, скомпрометирован, поскольку такой ключ используется только для шифрования одного сообщения. Прямая секретность также гарантирует, что прошлые сообщения не могут быть расшифрованы, если долгосрочные секретные ключи, полученные на этапе 1, будут скомпрометированы. Однако, если это произойдет, маскировка под Алису или Боба будет возможной, что может поставить под угрозу все будущие сообщения.
Атаки
[ редактировать ]Прямая секретность предназначена для предотвращения воздействия компрометации долговременного секретного ключа на конфиденциальность прошлых разговоров. Однако прямая секретность не может защитить от успешного криптоанализа используемых базовых шифров , поскольку криптоанализ заключается в поиске способа расшифровки зашифрованного сообщения без ключа, а прямая секретность защищает только ключи, а не сами шифры. [ 8 ] Терпеливый злоумышленник может перехватить разговор, конфиденциальность которого защищена за счет использования криптографии с открытым ключом , и дождаться, пока основной шифр будет взломан (например, большие квантовые компьютеры могут быть созданы задачу дискретного логарифма , которые позволят быстро вычислить ). Это позволит восстановить старые открытые тексты даже в системе, использующей прямую секретность.
Неинтерактивные протоколы обмена ключами с прямой защитой сталкиваются с дополнительными угрозами, которые не имеют отношения к интерактивным протоколам. При атаке с подавлением сообщений злоумышленник, контролирующий сеть, может сам хранить сообщения, не позволяя им достичь предполагаемого получателя; поскольку сообщения никогда не принимаются, соответствующие закрытые ключи не могут быть уничтожены или проколоты, поэтому компрометация закрытого ключа может привести к успешной расшифровке. Заблаговременное удаление закрытых ключей по расписанию смягчает, но не устраняет эту атаку. При атаке с исчерпанием злонамеренного ключа злоумышленник отправляет получателю множество сообщений и исчерпывает материал закрытого ключа, заставляя протокол выбирать между сбоем закрытия (и включением атак типа «отказ в обслуживании ») или сбоем открытия (и отказом от некоторой степени прямой секретности). ). [ 9 ]
Неинтерактивная прямая секретность
[ редактировать ]Большинство протоколов обмена ключами являются интерактивными и требуют двусторонней связи между сторонами. Протокол, который позволяет отправителю передавать данные без необходимости предварительного получения каких-либо ответов от получателя, может называться неинтерактивным , асинхронным или нулевым двусторонним обходом (0-RTT). [ 10 ] [ 11 ]
Интерактивность является обременительной для некоторых приложений — например, в системе безопасного обмена сообщениями может быть желательно иметь реализацию с промежуточным хранением , а не требовать, чтобы отправитель и получатель были в сети одновременно; Ослабление требования к двунаправленности также может повысить производительность, даже если это не является строгим требованием, например при установлении или возобновлении соединения. Эти варианты использования стимулировали интерес к неинтерактивному обмену ключами, а поскольку прямая безопасность является желательным свойством протокола обмена ключами, к неинтерактивной прямой секретности. [ 12 ] [ 13 ] Эта комбинация считалась желательной по крайней мере с 1996 года. [ 14 ] Однако сочетание прямой секретности и неинтерактивности оказалось сложной задачей; [ 15 ] подозревалось, что прямая секретность с защитой от атак повторного воспроизведения невозможна в неинтерактивном режиме, но было показано, что можно достичь всех трех целей. [ 11 ]
В целом были исследованы два подхода к неинтерактивной прямой секретности: предварительно вычисленные ключи и прокалываемое шифрование . [ 13 ]
При использовании предварительно вычисленных ключей создается множество пар ключей и используются общие ключи, а закрытые ключи уничтожаются после получения сообщения с использованием соответствующего открытого ключа. Этот подход был развернут как часть протокола Signal . [ 16 ]
При прокалываемом шифровании получатель изменяет свой закрытый ключ после получения сообщения таким образом, что новый закрытый ключ не может прочитать сообщение, а открытый ключ остается неизменным. Росс Дж. Андерсон неофициально описал прокалываемую схему шифрования для прямого безопасного обмена ключами в 1997 году: [ 17 ] и Грин и Майерс (2015) формально описали такую систему: [ 18 ] Основываясь на соответствующей схеме Канетти, Халеви и Каца (2003) , которая изменяет закрытый ключ в соответствии с расписанием, так что сообщения, отправленные в предыдущие периоды, не могут быть прочитаны с помощью закрытого ключа из более позднего периода. [ 15 ] Green & Miers (2015) используют иерархическое шифрование на основе идентификации и шифрование на основе атрибутов , а Günther et al. (2017) используют другую конструкцию, которая может быть основана на любой иерархической схеме, основанной на идентичности. [ 19 ] Даллмайер и др. (2020) экспериментально обнаружили, что модификация QUIC для использования прямого безопасного и устойчивого к повторному обмену ключей 0-RTT, реализованного с помощью прокалываемого шифрования, привела к значительному увеличению использования ресурсов, но не настолько, чтобы сделать практическое использование невозможным. [ 20 ]
Слабая совершенная прямая секретность
[ редактировать ]Слабая совершенная прямая секретность (Wpfs) — это более слабое свойство, согласно которому при компрометации долгосрочных ключей агентов секретность ранее установленных сеансовых ключей гарантируется, но только для сеансов, в которые злоумышленник не вмешивался активно. Это новое понятие и различие между ним и прямой секретностью были введены Хьюго Кравчиком в 2005 году. [ 21 ] [ 22 ] Это более слабое определение неявно требует, чтобы полная (совершенная) прямая секретность сохраняла секретность ранее установленных сеансовых ключей даже в сеансах, в которых злоумышленник активно вмешивался или пытался действовать как посредник.
Протоколы
[ редактировать ]Прямая секретность присутствует в нескольких основных реализациях протокола, таких как SSH , а также в качестве дополнительной функции в IPsec (RFC 2412). Сообщения без записи , криптографический протокол и библиотека для многих клиентов обмена мгновенными сообщениями, а также OMEMO , который предоставляет дополнительные функции, такие как многопользовательская функциональность в таких клиентах, обеспечивают как прямую секретность, так и шифрование с возможностью отказа .
В Transport Layer Security наборы шифров, основанные на обмене ключами Диффи-Хеллмана (DHE- RSA , DHE- DSA ) и обмене ключами Диффи-Хеллмана на основе эллиптической кривой (ECDHE- RSA , ECDHE- ECDSA (TLS) доступны ). Теоретически TLS мог выбирать подходящие шифры, начиная с SSLv3, но в повседневной практике многие реализации отказывались обеспечивать прямую секретность или предоставляли ей только очень низкую степень шифрования. [ 23 ] Это уже не относится к TLS 1.3, который обеспечивает прямую секретность, оставляя эфемерный механизм Диффи-Хеллмана (варианты с конечным полем и эллиптической кривой) в качестве единственного оставшегося механизма обмена ключами. [ 24 ]
OpenSSL поддерживает прямую секретность с использованием эллиптической кривой Диффи-Хеллмана, начиная с версии 1.0. [ 25 ] с вычислительными затратами примерно 15% для первоначального установления связи. [ 26 ]
Протокол сигналов использует алгоритм двойного храпового механизма для обеспечения прямой секретности. [ 27 ]
С другой стороны, среди популярных протоколов, используемых в настоящее время, WPA Personal не поддерживал прямую секретность до WPA3. [ 28 ]
Использовать
[ редактировать ]Прямая секретность рассматривается несколькими крупными поставщиками информации в Интернете как важная функция безопасности. С конца 2011 года Google по умолчанию обеспечивает прямую секретность с помощью TLS для пользователей своей службы Gmail , службы Google Docs и служб зашифрованного поиска. [ 25 ] С ноября 2013 года Twitter обеспечил своим пользователям прямую секретность с помощью TLS. [ 29 ] Все вики , размещенные Фондом Викимедиа, с июля 2014 года обеспечивают пользователям конфиденциальность. [ 30 ] и требуют использования прямой секретности с августа 2018 года.
Facebook сообщил в рамках расследования шифрования электронной почты, что по состоянию на май 2014 года 74% хостов, поддерживающих STARTTLS, также обеспечивают прямую секретность. [ 31 ] В TLS 1.3, опубликованном в августе 2018 года, прекращена поддержка шифров без прямой секретности. По состоянию на февраль 2019 г. [update]96,6% опрошенных веб-серверов поддерживают ту или иную форму прямой секретности, а 52,1% будут использовать прямую секретность в большинстве браузеров. [ 32 ]
На WWDC 2016 Apple объявила, что все приложения iOS должны будут использовать App Transport Security (ATS) — функцию, которая обеспечивает использование передачи HTTPS. В частности, ATS требует использования шифра шифрования, обеспечивающего прямую секретность. [ 33 ] ATS стал обязательным для приложений с 1 января 2017 года. [ 34 ]
Приложение обмена сообщениями Signal использует в своем протоколе прямую секретность, что заметно отличает его от протоколов обмена сообщениями, основанных на PGP . [ 35 ]
По состоянию на май 2024 года прямая секретность поддерживается на 92,6% веб-сайтов в современных браузерах, а 0,3% веб-сайтов вообще не поддерживают прямую секретность. [ 36 ]
См. также
[ редактировать ]- Переадресация анонимности
- Обмен ключами Диффи-Хеллмана
- Эллиптическая кривая Диффи – Хеллмана
- Соберите сейчас, расшифруйте позже
Ссылки
[ редактировать ]- ^ "/docs/man1.1.1/man3/SSL_set_tmp_dh.html" . www.openssl.org . Проверено 25 мая 2024 г.
- ^ «tls — делает ли идеальная прямая секретность (PFS) атаки типа «человек посередине» (MitM) более трудными?» . Обмен стеками информационной безопасности . Проверено 11 октября 2020 г.
- ^ Гюнтер, CG (1990). Протокол обмена ключами на основе идентификации . Достижения в криптологии EUROCRYPT '89 (LNCS 434). стр. 29–37.
- ^ Мензис, Альфред; ван Орскот, Пол С; Ванстон, СКОТТ (1997). Справочник по прикладной криптографии . Председатель КПР. ISBN 978-0-8493-8523-0 .
- ^ Диффи, Уитфилд; ван Оршот, Пол К.; Винер, Майкл Дж. (июнь 1992 г.). «Аутентификация и обмен ключами с проверкой подлинности» (PDF) . Проекты, коды и криптография . 2 (2): 107–125. CiteSeerX 10.1.1.59.6682 . дои : 10.1007/BF00124891 . S2CID 7356608 . Проверено 7 сентября 2013 г.
- ^ Яблон, Дэвид П. (октябрь 1996 г.). «Обмен ключами с аутентификацией только по надежному паролю». Обзор компьютерных коммуникаций ACM . 26 (5): 5–26. CiteSeerX 10.1.1.81.2594 . дои : 10.1145/242896.242897 . S2CID 2870433 .
- ^ «IEEE 1363-2000 — Стандартные спецификации IEEE для криптографии с открытым ключом» . ИИЭЭ . Проверено 14 июня 2018 г.
- ^ Нильссон, Деннис К.; Рооста, Таня; Линдквист, Ульф; Вальдес, Альфонсо (31 марта 2008 г.). «Управление ключами и безопасные обновления программного обеспечения в беспроводных средах управления процессами» . Материалы первой конференции ACM по безопасности беспроводных сетей . WiSec '08. Александрия, Вирджиния, США: Ассоциация вычислительной техники. стр. 100–108. дои : 10.1145/1352533.1352550 . ISBN 978-1-59593-814-5 . S2CID 15382932 .
- ^ Бойд и Геллерт 2020 , с. 645.
- ^ Бойд и Геллерт 2020 , с. 639-640.
- ^ Jump up to: а б Гюнтер и др. 2017 , с. 1.
- ^ Бойд и Геллерт 2020 , с. 640.
- ^ Jump up to: а б Бойд и Геллерт 2020 , с. 643.
- ^ Еще в 1996 году .
- ^ Jump up to: а б Грин и Майерс, 2015 , с. 1.
- ^ Бойд и Геллерт 2020 , с. 644-645.
- ^ Андерсон 2002 .
- ^ Бойд и Геллерт 2020 , с. 643-644.
- ^ Гюнтер и др. 2017 , с. 5.
- ^ Даллмайер и др. 2020 , стр. 18-19.
- ^ Кравчик, Хьюго (2005). HMQV: высокопроизводительный безопасный протокол Диффи-Хеллмана . Достижения в криптологии – CRYPTO 2005. Конспекты лекций по информатике. Том. 3621. стр. 546–566. дои : 10.1007/11535218_33 . ISBN 978-3-540-28114-6 .
- ^ Кремерс, Кас; Фельц, Мишель (2015). «За пределами eCK: идеальная прямая секретность при компрометации действующих лиц и раскрытии эфемерного ключа» (PDF) . Проекты, коды и криптография . 74 (1): 183–218. CiteSeerX 10.1.1.692.1406 . дои : 10.1007/s10623-013-9852-1 . hdl : 20.500.11850/73097 . S2CID 53306672 . Проверено 8 декабря 2015 г.
- ^ Обсуждение в списке рассылки TLS в октябре 2007 г.
- ^ «Подробный обзор RFC 8446 (он же TLS 1.3)» . Блог Cloudflare . 10 августа 2018 г. Проверено 26 февраля 2019 г.
- ^ Jump up to: а б «Защита данных в долгосрочной перспективе с помощью прямой секретности» . Проверено 5 ноября 2012 г.
- ^ Винсент Бернат (28 ноября 2011 г.). «SSL/TLS и идеальная секретность пересылки» . Проверено 5 ноября 2012 г.
- ^ Унгер, Ник; Дечанд, Сергей; Бонно, Джозеф; Фаль, Саша; Перл, Хеннинг; Голдберг, Ян; Смит, Мэтью (17–21 мая 2015 г.). «SoK: Безопасный обмен сообщениями». Симпозиум IEEE по безопасности и конфиденциальности 2015 г. (PDF) . Сан-Хосе, Калифорния: Институт инженеров по электротехнике и электронике. п. 241. дои : 10.1109/СП.2015.22 . ISBN 978-1-4673-6949-7 . S2CID 2471650 . Проверено 4 декабря 2015 г.
- ^ «Wi-Fi становится более безопасным: все, что вам нужно знать о WPA3 — спектр IEEE» . ИИЭЭ . Проверено 4 мая 2024 г.
- ^ Хоффман-Эндрюс, Джейкоб. «Прямая секретность в Твиттере» . Твиттер . Проверено 25 ноября 2013 г.
- ^ «Tech/News/2014/27 – Мета» . Фонд Викимедиа . 30 июня 2014 г. Проверено 30 июня 2014 г.
- ^ «Текущее состояние развертывания SMTP STARTTLS» . Фейсбук . Проверено 7 июня 2014 г.
- ^ Лаборатория Qualys SSL . «SSL-Пульс» . Архивировано из оригинала (3 февраля 2019 г.) 15 февраля 2019 г. . Проверено 25 февраля 2019 г.
- ^ «iOS 9.0» .
- ^ «ТРЕБУЕТСЯ безопасность транспортировки приложений, январь 2017 г. | Форумы разработчиков Apple» . forums.developer.apple.com . Проверено 20 октября 2016 г.
- ^ Эванс, Джон (22 января 2017 г.). «WhatsApp, Signal и опасно невежественная журналистика» . ТехКранч . Проверено 18 апреля 2018 г.
- ^ «Qualys SSL Labs — SSL Pulse» . www.ssllabs.com . Проверено 25 мая 2024 г.
Библиография
[ редактировать ]- Андерсон, Росс (2002). «Два замечания о криптологии с открытым ключом» (PDF) .
- Канетти, Ран ; Халеви, Шай ; Кац, Джонатан (2003). «Схема прямого шифрования с открытым ключом». Достижения в криптологии — EUROCRYPT 2003 . Конспекты лекций по информатике. Том. 2656. стр. 255–271. дои : 10.1007/3-540-39200-9_16 . ISBN 978-3-540-14039-9 .
- Грин, Мэтью Д .; Майерс, Ян (2015). «Пересылка безопасных асинхронных сообщений с помощью прокалываемого шифрования». Симпозиум IEEE 2015 по безопасности и конфиденциальности . стр. 305–320. дои : 10.1109/СП.2015.26 . ISBN 978-1-4673-6949-7 . S2CID 9171925 .
- Гюнтер, Феликс; Хейл, Бритта; Ягер, Тибор; Лауэр, Себастьян (2017). «Обмен ключами 0-RTT с полной прямой секретностью» (PDF) .
- Назад, Адам (6 сентября 1996 г.). «неинтерактивная прямая секретность» . Шифропанки (список рассылки).
- Бойд, Колин; Геллерт, Кай (24 августа 2020 г.). «Современный взгляд на передовую безопасность» . Компьютерный журнал . 64 (4) (опубликовано в апреле 2021 г.): 639–652. дои : 10.1093/comjnl/bxaa104 . HDL : 11250/2730309 . Архивировано из оригинала 7 июня 2021 года . Проверено 8 июня 2021 г.
- Даллмайер, Финн; Дрес, Ян П.; Геллерт, Кай; Хэндрик, Тобиас; Ягер, Тибор; Клауке, Йонас; Нахтигаль, Саймон; Ренцельманн, Тимоти; Вольф, Руди (2020). «Внедрение технологии Forward-Secure 0-RTT: внедрение и анализ производительности в QUIC» (PDF) .
Внешние ссылки
[ редактировать ]- RFC 2412 IETF, Х. Орман. Протокол определения ключей OAKLEY
- Perfect Forward Secrecy может блокировать доступ АНБ к защищенным веб-страницам, но никто ею не пользуется Computerworld 21 июня 2013 г.
- SSL: сегодня перехвачено, завтра расшифровано Netcraft, 25 июня 2013 г.
- Развертывание лаборатории прямой секретности SSL 25 июня 2013 г.
- Тест SSL Labs для веб-браузеров
- Тест SSL Labs для веб-серверов