СофтХабрахабр

[Перевод] Проблема PGP

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

Если не вдаваться в подробности, основная причина в том, что программа разработана в 90-е годы, до появления серьёзной современной криптографии. Как вы скоро увидите, у PGP много проблем. Серьёзные криптографы в основном отказались от PGP и больше не тратят на неё времени (за некоторыми заметными исключениями). Ни один компетентный криптоинженер сегодня не станет разрабатывать систему в таком виде и не потерпит большинства её дефектов ни в какой другой системе. Во-первых, статья написана для инженеров, а не для юристов и активистов. Поэтому хорошо известные проблемы в PGP остаются нерешёнными более десяти лет.
Два небольших примечания. Мы используем термин “PGP” для всего этого. Во-вторых, “PGP” может означать множество вещей, от стандарта OpenPGP до эталонной реализации в GnuPG.

Абсурдная сложность

По причинам, которые сейчас уже никто не понимает, PGP основан на пакетах. Сообщение PGP (в файле .asc) — архив типизированных пакетов. Существует по крайней мере восемь различных способов кодирования длины пакета, в зависимости от того, используете вы пакеты «нового» или «старого» формата. У пакетов «нового формата» вроде BER переменная длина (попробуйте написать реализацию PGP, и стандарт кодирования ASN.1 покажется вам конфеткой). У пакетов могут быть подпакеты. Некоторые варианты пакетов перекрываются друг с другом. Последняя атака на сервер ключей связана с тем, что из-за этого невменяемого формата парсинг ключей GnuPG случайно уходит в квадратичное время.

Реальная система гораздо сложнее. И это только кодировка. Идентификаторы ключей, серверы ключей и подписи ключей. Есть ключи и подключи. Многочисленные «связки ключей». Ключи только для подписи и только для шифрования. Три различных формата сжатия. Аннулирование сертификатов. Это мы ещё не добрались до поддержки смарт-карт.

Дизайн швейцарского армейского ножа

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

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

Современная криптография так не работает, нам нужны специализированные инструменты. Еще в эпоху MC Hammer, когда появился PGP, «шифрование» было особой вещью в себе; был один инструмент для отправки файлов, резервного копирования, для шифрования и подписи файлов. Криптография для безопасного обмена сообщениями отличается от криптографии для резервного копирования или подписи пакетов.

Болото обратной совместимости

PGP предшествует современной криптографии и сильно устарел за это время. Если вам повезёт, у вашего GnuPG по умолчанию будет установлен 2048-битный ключ RSA, 64-битный шифр CAST5 в CFB и контрольная сумма OpenPGP MDC (о которой позже). Если шифрование производится паролем, а не открытым ключом, протокол OpenPGP установит для PGP алгоритм формирования ключа S2K. Мягко говоря, это не те примитивы, которые криптоинженер выберет для современной системы.

Мы узнали, что зашифрованные тексты следует аутентифицировать (и избегать режима CFB), что 64-битные блочные шифры плохи, что RSA не идеален, что сочетание сжатия и шифрования опасно и что KDF'ы должны строго генерироваться и по времени, и по памяти. Мы многому научились с тех пор, как ботан Стив Уркель украсил прайм-тайм в эфире ABC.

Возьмите шифры AEAD: Sequoia PGP на языке Rust по умолчанию перешла в режим AES-EAX AEAD. Что бы ни говорил OpenPGP RFC, вероятно, вы не делаете ничего из этого списка, если используете PGP, и невозможно сказать, когда рекомендации начнут выполняться. Но теперь никто не может прочитать их сообщения, потому что большинство версий PGP не знает, что такое режим EAX, и это не очень здорово. Это здорово. RFC не имеет значения: только реальные установки. В каждой плохой криптосистеме в конечном итоге вырастает расширение RFC, которое поддерживает эллиптические кривые или AEAD, так что его сторонники могут кричать на форумах, что они поддерживают современную криптографию. Мы изобрели аутентифицированное шифрование 20 лет назад, а PGP скоро на пенсию; хватит оправданий.

Или у вас обратная совместимость с программой 90-х годов, или у вас хорошая криптография; нельзя получить и то, и другое.

Неприятный UX

Трудно сформулировать это лучше, чем Тед Унангст:

Через два часа никто из них ещё не отозвался. Несколько лет назад было проведено исследование юзабилити PGP, в котором группу технических специалистов поместили в комнату с компьютером и попросили настроить PGP.

Если вам нужны собственные эмпирические данные, чтобы подтвердить это, вот эксперимент, который вы можете провести: найдите какого-нибудь далёкого от компьютеров юриста и по телефону помогите ему установить Signal. Наверное, он справится без истерики. А теперь попробуйте сделать это с PGP.

Долговременные секреты

PGP просит пользователей практически навсегда сохранять корневой ключ, привязанный к их личности. Генерации и обмен ключами обременительны с этими «вечеринками подписи ключей» и «сетью доверия», где ключи зависят от других ключей.

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

Но по беглой приблизительной оценке, почти никто в мире не использует дорогие Yubikey, и вряд ли это изменится в будущем (мы едва можем развернуть U2F, а те ключи одноразовые). Фанаты PGP сразу ответят: «Вот почему нужно держать ключи на Yubikey». Мы не можем принимать плохие криптосистемы только для того, чтобы ботанам Unix было приятнее играться со своими игрушками.

Сломанная аутентификация

Подробнее об архаичных примитивах PGP: ещё в 2000 году рабочая группа OpenPGP поняла, что нужно аутентифицировать зашифрованный текст и что подписи PGP этого не делают. Поэтому OpenPGP изобрела систему MDC: сообщения PGP с MDC присоединяют SHA-1 открытого текста к самому открытому тексту, который затем шифруется (как обычно) в режиме CFB.

Как бы вам описать эту карикатуру? Если вам интересно, как PGP справляется с этим, когда современные системы используют относительно сложные схемы AEAD (поскольку не могут просто прикрепить SHA-1 к открытому тексту), то это хороший вопрос. Чтобы сохранить обратную совместимость с небезопасными старыми сообщениями, PGP ввёл новый тип пакета, который сигнализирует о необходимости проверки MDC. PGP MDC можно очистить от сообщений — он закодирован таким образом, что достаточно просто отрезать последние 22 байта зашифрованного текста. Даже если вы это сделаете, новый формат пакета SEIP достаточно близок к небезопасному формату SE, который потенциально обмануть получателя с понижением шифра; Тревор Перрин свёл SEIP всего к 16 битам безопасности. Если вы используете неправильный тип, то MDC не проверяется.

Наконец, даже если всё пойдёт правильно, эталонная реализация PGP выдаст по запросу неаутентифицированный открытый текст, даже если MDC не совпадает.

Непоследовательные идентити

PGP — это и приложение, и набор интеграций с другими приложениями, и формат файла, и социальная сеть, и субкультура.

Вы создаёте ключ, сохраняете его в связке ключей, печатаете его фингерпринт на визитке и публикуете на сервере ключей. PGP выдвигает понятие криптографической идентичности (identity). Они, в свою очередь, могут полагаться или не полагаться на ваши подписи для проверки других ключей. Вы подписываете чужие ключи. Другие организуют «вечеринки подписи ключей». Некоторые люди стараются встретиться с другими пользователями PGP лично, чтобы обменяться ключами и более надёжно прописаться в этой «сети доверия». Если представить всю эту активность, то становится понятно, как трудно преданным фанатам PGP переключиться на новые технологии.

Ни сеть доверия с подписями ключей, ни серверы ключей, ни вечеринки. Но вся эта система не работает на практике. Эксперты не доверяют ключам, которые не получили лично. Обычные люди будут доверять всему, что выглядит как ключ PGP, независимо от того, откуда он взялся — как они могут не доверять, если даже эксперту трудно сформулировать, как оценить ключ? Механизмы распространения ключей PGP — это цирк. Все остальные полагаются на централизованные сервисы для распространения ключей.

Утечки метаданных

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

Нет прямой секретности

Наглядный пример: криптография для безопасного обмена сообщениями требует прямой секретности (forward secrecy). Прямая секретность означает, что если злоумышленник получит ваш ключ, то всё равно не сможет прочитать предыдущие сообщения. В современной криптографии мы предполагаем, что противник записывает всё в бесконечное хранилище. Заявленные противники PGP включают мировые правительства. Безусловно, некоторые из них делают это. Против серьёзных противников взлом криптографии без прямой секретности — лишь вопрос времени.

Ключ сеанса эфемерен (обычно продукт обмена DH), и доверенный ключ подписывает его, так что человек посередине не может применить собственный ключ. Чтобы на практике обеспечить прямую секретность, вы обычно храните два секретных ключа: краткосрочный сеансовый ключ и долгосрочный доверенный ключ. Конечно, почти никто этого не делает. Теоретически, прямую секретность можно реализовать инструментами PGP.

Топорные ключи

Открытый ключ OpenBSD signify — это строка Base64, достаточно короткая, чтобы поместиться в середине предложения в электронном письме; закрытый ключ, который не является форматом обмена, — просто строка или около того. А открытый ключ PGP — это целый гигантский документ Base64; если вы часто их использовали, вы, вероятно, уже привыкли прикреплять их в аттаче, а не вставлять в сообщения, чтобы не повредить. Ключ signify сгенерирован передовым алгоритмом Ed25519, а PGP — более слабым RSA.

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

Согласование

PGP поддерживает ElGamal, RSA, p-кривые NIST, Brainpool, Curve25519, SHA-1, SHA-2, RIPEMD160, IDEA, 3DES, CAST5, AES. Это не полный список того, что поддерживает PGP.

Как правило, недостатки криптосистем появляются в реализациях, а не примитивах, и экспансивная криптосовместимость увеличивает количество реализаций. Если за последние 20 лет мы узнали три важные вещи о криптографии, по крайней мере, две из них, это то, что согласование и совместимость — зло. 3, стремятся избавиться от обратной совместимости с архаизмами вроде RSA, а не добавляют её. Современные протоколы, такие как TLS 1. Если один из этих примитивов проваливается, вы избавляетесь от этой версии и бросаете сразу весь старый протокол. Новые системы поддерживают только один набор примитивов и простой номер версии.

Мы не можем сказать это яснее, и это нужно многократно повторять: или у вас обратная совместимость с программой 90-х годов, или у вас хорошая криптография; нельзя получить и то, и другое. Если нам не повезёт и через 20 лет люди всё ещё будут использовать PGP, он останется единственной причиной, по которой хоть где-то применяется стандарт CAST5.

Мусорный код

Де-факто стандартной реализацией PGP является GnuPG. Эта программа не очень аккуратно написана. Там обширная кодовая база на C — языка с дублированием функциональности (например, в описании недавней атаки типа «отказ в обслеживании» на парсинг SKS сказано, что у него есть несколько парсеров ключей) с длинным послужным списком CVE, начиная от повреждения памяти до криптографической атаки по сторонним каналам. Иногда можно было удалить из сообщений аутентификацию, а GnuPG не замечал этого. Можно было скормить ему ключи без правильного отпечатка. В 2018 году уязвимость Efail была вызвана тем, что GnuPG по запросу отдавал неаутентифицированный открытый текст. GnuPG — не есть хорошо.

Он никуда не денется. GnuPG является и эталонной реализацией для PGP, и основой для большинства других инструментов, интегрирующих криптографию PGP. Полагаться на PGP — значит, полагаться на GPG.

Чтобы убедить человека отказаться от PGP, важно объяснить ему, что PGP нечем заменить, и это нормально. Альтернативный инструмент зависит от задачи.

Разговоры

Используйте Signal. Или Wire, или WhatsApp, или какой-то другой безопасный мессенджер на основе протокола Signal.

Они используют сохраняющие конфиденциальность аутентификационные рукопожатия, аннуляцию сообщений, криптографические храповики (ratchets), которые выдают ключ на каждый обмен сообщениями, и, конечно же, современные примитивы шифрования. Современные безопасные мессенджеры созданы специально для обмена сообщениями. Если вы используете Signal, вы получаете даже больше: вы получаете систему, настолько параноидальную насчёт сохранения приватных метаданных с серверов, что она даже туннелирует поисковые запросы Giphy, чтобы избежать атак с анализом трафика, и до недавнего времени даже не поддерживала профили пользователей. Мессенджеры тривиально просты в использовании, никакой суеты с ключами и подключами.

Шифрование электронной почты

Не делайте этого.

Даже с PGP это открытый текст по умолчанию, то есть даже если вы всё делаете правильно, какой-то совершенно разумный получатель письма, делая абсолютно разумные вещи, обязательно процитирует открытый текст вашего зашифрованного сообщения кому-то другому в CC (мы не знаем пользователя электронной почты PGP, который с этим не сталкивался). Электронная почта не безопасна. Метаданные электронной почты, включая тему (которая буквально является содержимым сообщения), всегда передаются открытым текстом. В электронной почте PGP отсутствует прямая секретность.

Сообщество GnuPG, которое провалилось с раскрытием информации о Efail, бурно критикует эту статью, но её приняли в Usenix Security (один из лучших академических центров по безопасности программного обеспечения), а также на конференцию Black Hat USA (ведущая конференция по безопасности программного обеспечения). Если вам нужна другая причина, прочитайте статью об уязвимости Efail. Как вы увидите из статьи, S/MIME не лучше. Это одна из лучших криптографических атак за последние пять лет — и довольно разрушительная бомба против экосистемы PGP.

Чтобы сделать реально безопасную электронную почту, вам придётся туннелировать по электронной почте другой протокол (вы всё равно будете уязвимы для атаки с анализом трафика). Это никогда не исправят. В том-то и дело, зачем прикидываться?

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

Отправка файлов

Используйте Magic Wormhole. Клиенты Wormhole используют одноразовый обмен ключами с парольной аутентификацией (PAKE) для шифрования файлов. Это легко (по крайней мере, для ботаников), безопасно и весело: всякий, кому мы показывали «кротовую нору», сразу начинал пропускать через неё все файлы подряд, как это делаем мы.

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

Для получения отчётов об ошибках публикуйте номер Signal, а не ключ PGP. Если вы общаетесь с юристами, а не с инженерами, Signal отлично справляется с передачей файлов.

Шифрование бэкапов

Используйте Tarsnap. Колин объяснит, как Tarsnap оптимизирован для защиты резервных копий. Или действительно, возьмите любой другой инструмент шифрования бэкапов; он не будет так хорош, как Tarsnap, но всё равно будет лучше PGP.

Используйте шифрование образов дисков; оно встроено в современные версии Windows, Linux и macOS. Нужны офлайновые бэкапы? Полное шифрование диска не очень хорошо, но отлично справляется с этой задачей, и оно проще и безопаснее, чем PGP.

Подпись пакетов

Используйте Signify/Minisign. Тед Унангст вам всё расскажет. Этот инструмент используется для подписи пакетов в OpenBSD. Он очень простой и применяет современные подписи. Minisign от Фрэнка Дениса (один из разработчиков libsodium) реализует тот же дизайн в Windows и macOS; у него есть привязки к Go, Rust, Python, Javascript и .NET; он даже совместим с Signify.

Шифрование данных приложений

Используйте libsodium: это универсальная библиотека с интерфейсом, в котором трудно допустить ошибку, а для работы не нужен бинарник.

Шифрование файлов

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

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

Теги
Показать больше

Похожие статьи

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»
Закрыть