Прямая секретность - Forward secrecy

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

Прямая секретность защищает данные на транспортном уровне сети, использующей общие SSL / TLS протоколы, в том числе OpenSSL, когда его долгосрочные секретные ключи скомпрометированы, как в случае с ошибкой безопасности Heartbleed. Если используется прямая секретность, зашифрованные сообщения и сеансы, записанные в прошлом, не могут быть получены и расшифрованы, если долгосрочные секретные ключи или пароли будут скомпрометированы в будущем, даже если злоумышленник активно вмешался, например, через злоумышленника. средняя атака.

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

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

Значение прямой секретности ограничено не только предположением, что злоумышленник атакует сервер, только крадя ключи и не изменяя генератор случайных чисел, используемый сервером, но также ограничивается предположением, что злоумышленник будет только пассивно собирать трафик. на линии связи и не быть активным, используя Человек посередине (MITM) атака. Для прямой секретности обычно используются эфемерные Обмен ключами Диффи-Хеллмана чтобы предотвратить чтение прошедшего трафика. Обмен эфемерными ключами Диффи-Хеллмана часто подписывается сервером с использованием статического ключа подписи. Если злоумышленник может украсть (или получить по решению суда) этот статический (долгосрочный) ключ подписи, противник может замаскироваться как сервер для клиента и как клиент для сервера и реализовать классический Man-in-the-Middle атака.[1]

История

Термин «совершенная прямая секретность» был введен К. Г. Гюнтером в 1990 г.[2] и далее обсуждается Уитфилд Диффи, Пол ван Оршот, и Майкл Джеймс Винер в 1992 г.[3] где он использовался для описания свойства протокола Station-to-Station.[4]

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

В 2000 г. IEEE впервые ратифицирован IEEE 1363, который устанавливает соответствующие свойства односторонней и двухсторонней прямой секретности различных стандартных схем согласования ключей.[6]

Определение

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

Пример

Ниже приводится гипотетический пример простого протокола обмена мгновенными сообщениями, который использует прямую секретность:

  1. Алиса и Боб генерируют по паре долгосрочных, асимметричные открытые и закрытые ключи, затем проверьте отпечатки пальцев открытого ключа лично или по уже аутентифицированному каналу. Проверка с уверенностью устанавливает, что заявленный владелец открытого ключа является фактическим владельцем.
  2. Алиса и Боб используют алгоритм обмена ключами, например Диффи – Хеллмана, чтобы надежно согласовать эфемерный ключ сеанса. Они используют ключи из шага 1 только для аутентификации друг друга во время этого процесса.
  3. Алиса отправляет Бобу сообщение, зашифровав его симметричный шифр используя сеансовый ключ, согласованный на шаге 2.
  4. Боб расшифровывает сообщение Алисы, используя ключ, согласованный на шаге 2.
  5. Процесс повторяется для каждого нового отправленного сообщения, начиная с шага 2 (и при необходимости меняя роли Алисы и Боба как отправителя / получателя). Шаг 1 никогда не повторяется.

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

Атаки

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

Слабая идеальная прямая секретность

Слабая совершенная прямая секретность (wPFS) - это более слабое свойство, при котором, когда долгосрочные ключи агентов скомпрометированы, секретность ранее установленных сеансовых ключей гарантируется, но только для сеансов, в которые злоумышленник не вмешивался активно. Это новое понятие, а также различие между ним и прямой секретностью было введено Уго Кравчиком в 2005 году.[7][8]Это более слабое определение неявно требует, чтобы полная (совершенная) прямая секретность сохраняла секретность ранее установленных ключей сеанса даже в сеансах, в которых противник сделал активно вмешиваться или пытался действовать как мужчина посередине.

Протоколы

Прямая секретность присутствует в нескольких основных реализациях протокола, таких как SSH и как дополнительная функция в IPsec (RFC 2412 ). Сообщения без записи, криптографический протокол и библиотека для многих клиентов обмена мгновенными сообщениями, обеспечивает прямую секретность, а также отрицательное шифрование.

В Безопасность транспортного уровня (TLS), наборы шифров на основе Диффи – Хеллмана обмен ключами (DHE-ЮАР, DHE-DSA ) и эллиптическая кривая Диффи – Хеллмана обмен ключами (ECDHE-ЮАР, ECDHE-ECDSA ) доступны. Теоретически TLS может выбирать подходящие шифры, начиная с SSLv3, но в повседневной практике многие реализации отказываются предлагать прямую секретность или предоставляют только очень низкий уровень шифрования.[9] TLS 1.3 оставляет эфемерный метод Диффи-Хеллмана в качестве единственного механизма обмена ключами для обеспечения прямой секретности.[10]

OpenSSL поддерживает прямую секретность с использованием эллиптическая кривая Диффи – Хеллмана начиная с версии 1.0,[11] с вычислительными затратами примерно 15% для начального рукопожатия.[12]

В Сигнальный протокол использует Двойной трещоточный алгоритм для обеспечения прямой секретности.[13]

С другой стороны, среди популярных протоколов, используемых в настоящее время, WPA не поддерживает прямую секретность.

Использовать

Прямая секретность рассматривается как важная функция безопасности несколькими крупными поставщиками информации в Интернете. С конца 2011 года Google по умолчанию обеспечивал прямую секретность с помощью TLS для пользователей своих Gmail служба, Гугл документы сервис и сервисы зашифрованного поиска.[11] С ноября 2013 г. Twitter обеспечивает прямую секретность с помощью TLS для своих пользователей.[14] Вики организовано Фонд Викимедиа с июля 2014 года все обеспечивают секретность для пользователей[15] и требуют использования прямой секретности с августа 2018 года.

Facebook сообщил в рамках расследования шифрования электронной почты, что по состоянию на май 2014 г. 74% хостов, поддерживающих STARTTLS также обеспечивают прямую секретность.[16] TLS 1.3, опубликованный в августе 2018 года, отказался от поддержки шифров без прямой секретности. По состоянию на февраль 2019 г.96,6% опрошенных веб-серверов поддерживают ту или иную форму прямой секретности, а 52,1% будут использовать прямую секретность с большинством браузеров.[17]

На WWDC 2016 Apple объявила, что все приложения для iOS должны будут использовать App Transport Security (ATS), функцию, которая обеспечивает использование передачи HTTPS. В частности, ATS требует использования шифра, обеспечивающего прямую секретность.[18] ATS стала обязательной для приложений с 1 января 2017 года.[19]

В Сигнал приложение обмена сообщениями использует прямую секретность в своем протоколе, что заметно отличает его от протоколов обмена сообщениями, основанных на PGP.[20]

Немецкий провайдер электронной почты Mailbox.org, ориентированный на безопасность, использует PFS и HSTS для сообщений в пути.[21]

Смотрите также

Рекомендации

  1. ^ "tls - Делает ли Perfect Forward Secrecy (PFS) атакой Man-in-the-Middle (MitM) более сложными?". Обмен стеками информационной безопасности. Получено 2020-10-11.
  2. ^ Гюнтер, К. Г. (1990). Протокол обмена ключами на основе личности. Достижения в криптологии EUROCRYPT '89 (LNCS 434). С. 29–37.
  3. ^ Мензис, Альфред; van Oorscot, Paul C .; Ванстон, СКОТТ (1997). Справочник по прикладной криптографии. CRC Pres. ISBN  978-0-8493-8523-0.
  4. ^ Диффи, Уитфилд; van Oorschot, Paul C .; Винер, Майкл Дж. (Июнь 1992 г.). «Аутентификация и аутентифицированный обмен ключами» (PDF). Конструкции, коды и криптография. 2 (2): 107–125. CiteSeerX  10.1.1.59.6682. Дои:10.1007 / BF00124891. S2CID  7356608. Получено 2013-09-07.
  5. ^ Джаблон, Дэвид П. (октябрь 1996 г.). «Надежный обмен ключами с проверкой подлинности только с помощью пароля». Обзор компьютерных коммуникаций ACM. 26 (5): 5–26. CiteSeerX  10.1.1.81.2594. Дои:10.1145/242896.242897. S2CID  2870433.
  6. ^ «IEEE 1363-2000 - Стандартные спецификации IEEE для криптографии с открытым ключом». standard.ieee.org. Получено 2018-06-14.
  7. ^ Кравчик, Хьюго (2005). HMQV: высокопроизводительный безопасный протокол Диффи-Хеллмана. Достижения в криптологии - CRYPTO 2005. Конспект лекций по информатике. 3621. С. 546–566. Дои:10.1007/11535218_33. ISBN  978-3-540-28114-6.
  8. ^ Cremers, Cas; Feltz, Мишель (2015). «За пределами eCK: идеальная прямая секретность при компрометации актера и раскрытии эфемерного ключа» (PDF). Конструкции, коды и криптография. 74 (1): 183–218. CiteSeerX  10.1.1.692.1406. Дои:10.1007 / s10623-013-9852-1. S2CID  53306672. Получено 8 декабря 2015.
  9. ^ Обсуждение в списке рассылки TLS в октябре 2007 г.
  10. ^ «Подробный взгляд на RFC 8446 (он же TLS 1.3)». Блог Cloudflare. 2018-08-10. Получено 2019-02-26.
  11. ^ а б «Долгосрочная защита данных с прямой секретностью». Получено 2012-11-05.
  12. ^ Винсент Бернат. «SSL / TLS и совершенная пересылка секретов». Получено 2012-11-05.
  13. ^ Унгер, Ник; Дечан, Сергей; Бонно, Жозеф; Фахл, Саша; Перл, Хеннинг; Гольдберг, Ян; Смит, Мэтью (17–21 мая 2015 г.). SoK: безопасный обмен сообщениями (PDF). Симпозиум IEEE по безопасности и конфиденциальности 2015 г.. Сан-Хосе, Калифорния: Институт инженеров по электротехнике и радиоэлектронике. п. 241. Дои:10.1109 / SP.2015.22. ISBN  978-1-4673-6949-7. S2CID  2471650. Получено 4 декабря 2015.
  14. ^ Хоффман-Эндрюс, Джейкоб. «Прямая секретность в Twitter». Twitter. Twitter. Получено 25 ноября 2013.
  15. ^ "Техника / Новости / 2014/27 - Мета". Фонд Викимедиа. 2014-06-30. Получено 30 июн 2014.
  16. ^ «Текущее состояние развертывания SMTP STARTTLS». Получено 7 июн 2014.
  17. ^ Qualys SSL Labs. «Импульс SSL». Архивировано из оригинал (3 февраля 2019 г.) 15 февраля 2019 г.. Получено 25 февраля 2019.
  18. ^ https://developer.apple.com/library/ios/releasenotes/General/WhatsNewIniOS/Articles/iOS9.html#//apple_ref/doc/uid/TP40016198-SW14
  19. ^ «ТРЕБУЕТСЯ безопасность транспорта приложений. Январь 2017 г. | Форумы разработчиков Apple». forum.developer.apple.com. Получено 2016-10-20.
  20. ^ Эванс, Джон (22 января 2017 г.). «WhatsApp, Signal и опасно невежественная журналистика». TechCrunch. Получено 18 апреля 2018.
  21. ^ Свен Тейлор (7 ноября 2019 г.). "Обзор Mailbox.org". Восстановить конфиденциальность. Получено 8 ноября 2019.

внешняя ссылка