В мессенджерах со сквозным шифрованием (E2E) пользователь отвечает за свои ключи. Когда он теряет их, то вынужден переустанавливать учётную запись.
Сброс учётной записи опасен. Вы стираете открытые ключи и во всех разговорах становитесь криптографическим незнакомцем. Вам нужно восстановить личность, и почти во всех случаях это означает личную встречу и сравнение «номеров безопасности» с каждым из контактов. Как часто вы реально проходите такую проверку, которая является единственной защитой от MiTM?
Даже если вы серьёзно относитесь к номерам безопасности, многих партнёров по чату вы видите только раз в год на конференции, так что вы застряли.
Но такое ведь нечасто происходит, верно?
Как часто происходит сброс? Ответ: в большинстве E2E-приложений для чата всё время.
В этих мессенджерах вы отбрасываете криптографию и просто начинаете доверять серверу: (1) всякий раз, когда переключаетесь на новый телефон; (2) всякий раз, когда какой-либо собеседник переключается на новый телефон; (3) когда производите сброс к заводским настройкам телефона; (4) когда любой собеседник производит сброс к заводским настройкам; (5) всякий раз, когда удаляете и переустанавливаете приложение, или (6) когда любой собеседник удаляет и переустанавливает его. Если у вас десятки контактов, сброс будет происходить каждые несколько дней.
Сброс происходит настолько регулярно, что эти приложения делают вид, что это не проблема:
Похоже, у нас апгрейд безопасности! (Но не совсем)
Это действительно TOFU?
В криптографии термин TOFU («доверие при первом использовании») описывает азартную игру, когда две стороны заговаривают первый раз. Вместо того, чтобы встретиться лично, посредник поручается за каждую сторону… и затем, после представления сторон, каждая сторона тщательно отслеживает ключи, чтобы убедиться, что ничего не изменилось. Если ключ изменился, каждая сторона подаёт сигнал тревоги.
Если в SSH в такой ситуации изменяется ключ удалённого хоста, он не будет «просто работать», а становится совершенно воинственным:
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that a host key has just been changed.
The fingerprint for the RSA key sent by the remote host is
00:11:22:33:44:55:66:77:88:99:aa:bb:cc:dd:ee:ff
Please contact your system administrator.
Add correct host key in /Users/rmueller/.ssh/known_hosts to get rid of this message.
Offending RSA key in /Users/rmueller/.ssh/known_hosts:12
RSA host key for 8.8.8.8 has changed and you have requested strict checking.
Host key verification failed.
Вот правильное поведение. И помните: это не TOFU, если он позволяет работать дальше с маленьким предупреждением. Вы должны увидеть гигантский череп со скрещёнными костями.
Конечно, эти мессенджеры будут утверждать, что всё нормально, потому что пользователь предупреждён. Если хочет, то он может проверить номера безопасности. Вот почему мы не согласны:
- Проверка не выполняется, так как происходит слишком часто.
- Проверка отстой.
- Даже беглый опрос наших друзей, которые озабочены безопасностью, показал, что никто не беспокоится об этой проверке.
- Так что это просто доверие к серверу и доверие SMS (ну-ну!) снова, снова и снова.
- Наконец, эти приложения не должны работать таким образом. Особенно при изменении устройств. Типичный нормальный случай можно обрабатывать гладко и безопасно, а чем более редкая ситуация, тем она должна выглядеть страшнее. Через минуту покажем решение Keybase.
Хватит называть это TOFU
Есть очень эффективная атака. Предположим, Ева хочет ворваться в существующий разговор Алисы и Боба и встать между ними. Алиса и Боб в контакте в течение многих лет, давным-давно пройдя TOFU.
Ева просто заставляет Алису думать, что Боб купил новый телефон:
Боб (Ева): Эй, Эй!
Алиса: Йо, Боб! Похоже, у тебя новые номера безопасности.
Боб (Ева): Да, купил iPhone XS, хороший телефон, очень доволен им. Давай обменяемся номерами безопасности на RWC 2020. Эй, у тебя есть текущий адрес Кэролайн? Хочу удивить её, пока я в Сан-Франциско.
Алиса: Тут не сравнюсь, Android 4 life! Да, Кози Стрит 555.
Поэтому большинство мессенджеров с шифрованием вряд ли заслужили соответствие TOFU. Это больше похоже на TADA — доверие после добавлений устройств. Это реальная, а не выдуманная проблема, поскольку создаёт возможность для злонамеренного внедрения в ранее существовавший разговор. В реальном TOFU ко времени, когда кто-то заинтересован в вашем разговоре, он не сможет внедриться в него. С TADA такое возможно.
В групповых чатах ситуация ещё хуже. Чем больше людей в чате, тем чаще будут происходить переустановки аккаунтов. В компании из всего 20 человек это будет происходить примерно каждые две недели, по нашей оценке. И каждый человек в компании должен встретиться с этим человеком. Лично. В противном случае весь чат скомпрометирован одним кротом или хакером.
Решение
Есть ли хорошее решение, которое не предполагает доверия серверам с закрытыми ключами? Мы думаем, что есть: реальная поддержка нескольких устройств. Это означает, что вы управляете цепочкой устройств, которые представляют вашу личность. Когда вы получаете новое устройство (телефон, ноутбук, настольный компьютер, iPad и т. д.), он генерирует собственную пару ключей, а ваше предыдущее устройство подписывает её. Если потеряете устройство, то «удаляете» его с одного из оставшихся. Технически такое удаление является отзывом, и в этом случае также есть некое обращение ключей, которое происходит автоматически.
В результате, вам не нужно доверять серверу или встречаться лично, когда собеседник или коллега получает новое устройство. Точно так же вам не нужно доверять серверу или встречаться лично, когда он удаляет устройство, если оно не было последним. Единственное, когда вам нужно увидеть предупреждение, — когда кто-то действительно теряет доступ ко всем своим установкам. И в таком случае вы увидите серьёзное предупреждение, как и должно:
Специально максимально уродливое
В результате сбрасывается и переустанавливается гораздо меньше аккаунтов. Исторически на Keybase общее количество добавлений и отзывов устройств в десять раз больше количества сбросов аккаунтов (вам не нужно верить нам на слово, это общедоступно в нашем дереве Меркла). В отличие от других мессенджеров, мы можем показать поистине ужасающее предупреждение, когда вы разговариваете с кем-то, кто недавно переустановил ключи.
Управление устройствами — сложная инженерная операция, которую мы дорабатывали несколько раз. Существующее устройство подписывает открытые ключи нового устройства и шифрует все важные секретные данные для открытого ключа нового устройства. Эта операция должна производится быстро (в течение секунды), так как речь идёт о диапазоне внимания пользователя. В результате Keybase использует иерархию ключей, так что при передаче 32 байт секретных данных со старого устройства новое устройство может видеть все долгоживущие криптографические данные (подробнее см. FAQ ниже). Это может показаться немного удивительным, но именно в этом смысл криптографии. Она не решает ваших проблем управления секретами, она просто делает систему более масштабируемой.
Полная картина безопасности
Теперь мы можем сформулировать четыре основных свойства безопасности для приложения Keybase:
- долговечные секретные ключи никогда не покидают устройств, на которых созданы
- полная поддержка нескольких устройств сводит сбросы аккаунтов к минимуму
- отзыв ключей не может быть злонамеренно задержан или откачен назад
- прямая секретность с помощью эфемерных сообщений по времени
Первые два кажутся понятными. Третий становится важным в конструкции, где отзыв устройств ожидается и считается нормальным. В системе должны быть проверки, что вредоносные серверы не могут задерживать отзывы устройств, о чём мы писали ранее.
Более подробную информацию о четвёртом свойстве безопасности см. в нашей статье об эфемерных сообщениях.
Много новой криптографии, всё правильно реализовано?
Основные функции безопасности Keybase никто никогда не реализовывал ранее и даже не описывал в научных статьях. Нам пришлось самим изобретать некоторые криптографические протоколы. К счастью, готовых, стандартизированных и широко используемых криптографических алгоритмов в избытке для любой ситуации. Весь наш клиентский код открыт. Теоретически, любой может найти ошибки проектирования или реализации. Но мы хотели продемонстрировать внутреннее устройство и наняли лучшую аудиторскую фирму по безопасности для полного анализа.
Сегодня мы представляем отчёт NCC Group и чрезвычайно воодушевлены результатами. Keybase потратила на аудит более $100 000, а NCC Group наняла экспертов по безопасности и криптографии высшего уровня. Они нашли в нашей реализации две важные ошибки, и мы быстро их исправили. Эти баги могли проявиться только если бы наши серверы действовали злонамеренно. Можем заверить, что они не будут так действовать, но у вас нет причин нам верить. В том-то и дело!
Мы считаем, что команда NCC проделала отличную работу. Респект за время, которое они потратили, чтобы полностью понять нашу архитектуру и реализацию. Они нашли тонкие ошибки, которые прошли мимо внимания наших разработчиков, хотя мы в последнее время многократно смотрели эту часть кодовой базы. Рекомендуем посмотреть отчёт здесь, или переходите к нашему FAQ.
FAQ
Как вы СМЕЕТЕ атаковать продукт XYZ?
Мы уже удалили из статьи упоминания конкретных продуктов.
Что ещё?
Мы гордимся тем, что Keybase не требует телефонных номеров и может криптографически проверять идентификаторы Twitter, HackerNews, Reddit и Github, если вы кого-то знаете.
И… очень скоро… появится поддержка Mastodon.
Что насчёт атак с переадресацией телефона?
Многие приложения восприимчивы к атакам с переадресацией. Ева заходит в киоск в торговом центре и убеждает оператора мобильной связи Боба переадресовать номер телефона Боба на её устройство. Или она убеждает представителя по телефону. Теперь Ева может аутентифицироваться на серверах мессенджеров, утверждая, что она Боб. Результат выглядит как наш пример Алисы, Боба и Евы выше, но Еве не нужно проникать на какие-то серверы. Некоторые приложения предлагают «блокировки регистрации» для защиты от этой атаки, но по умолчанию они раздражают.
Я слышал, Keybase отправляет некоторые приватные ключи на сервер?
В первые дни (2014 и начало 2015) Keybase работал как веб-приложение PGP, и пользователь мог выбрать функцию хранить свои закрытые ключи PGP на наших серверах, зашифрованные парольными фразами (которые Keybase не знал).
В сентябре 2015 года мы представили новую модель Keybase. Ключи PGP никогда не используются (и никогда не использовались) в чате или файловой системе Keybase.
Как старые чаты мгновенно появляются на новых телефонах?
В некоторых других приложениях новые устройства не видят старых сообщений, так как синхронизация старых сообщений через сервер противоречит прямой секретности. Приложение Keybase позволяет назначать некоторые сообщения — или целые разговоры — как «эфемерные». Они уничтожаются через определённое время и шифруются дважды: один раз с помощью долгоживущих ключей шифрования чата, а другой — часто меняющимися эфемерными ключами. Таким образом, эфемерные сообщения обеспечивают прямую секретность и не могут быть синхронизированы между телефонами.
Неэфемерные сообщения сохраняются до тех пор, пока пользователь явно не удалит их и синхронизируются E2E с новыми устройствами в стиле Slack, только с шифрованием! Поэтому, когда вы добавляете кого-то в команду или добавляете новое устройство для себя, сообщения разблокируются.
Подробнее о синхронизации в следующем пункте.
Расскажите о PUK'ах!
Два года назад мы представили ключи по пользователям (PUK). Публичная половина PUK рекламируется в публичном sigchain пользователей. Секретная половина зашифрована для открытого ключа каждого устройства. Когда Алиса готовит новое устройство, её старое устройство знает секретную половину её PUK и открытый ключ нового устройства. Она шифрует секретную половину PUK для открытого ключа нового устройства, и новое устройство скачивает этот шифротекст через сервер. Новое устройство расшифровывает PUK и может сразу получить доступ ко всем долгоживущим сообщениям чата.
Всякий раз, когда Алиса отзывает устройство, оно меняет её PUK, так что все её устройства, кроме самого последнего отозванного, получают новый PUK.
Эта схема синхронизация кардинально отличается от ранней системы Keybase PGP. Здесь у всех задействованных ключей 32 байта истинной энтропии, они не ломаются брутфорсом в случае взлома сервера. Правда, если сломан Curve25519 или ГПСЧ от Go, то всё ломается. Но PUK-синхронизация не делает никаких других значимых криптографических предположений.
Что насчёт больших групповых чатов?
tL;dr У групп собственные аудируемые цепочки подписей для изменения ролей, добавления и удаления членов.
Исследователи безопасности писали об атаках «фантомного пользователя» на групповые чаты. Если клиенты пользователей не в состоянии криптографически проверить членство в группе, то вредоносные серверы могут внедрить шпионов и кротов в групповые чаты. У Keybase здесь очень надёжная система в виде специальной функции групп, о которой мы дополнительно напишем в будущем.
Можете рассказать о NCC-KB2018-001?
Мы считаем, что этот баг — самая значительная находка аудита NCC. Keybase активно использует для защиты от неоднозначности сервера append-only неизменяемые структуры данных. В случае бага честный сервер, возможно, начнёт увиливать: «Я ранее говорил вам A, но произошёл баг, я имел в виду Б». Но у наших клиентов общая политика не позволять серверу такую гибкость: в них жёстко зашиты исключения на случай багов.
Недавно мы также представили Sigchain V2: эта система решает проблемы масштабируемости, которые мы не совсем корректно предусмотрели в первой версии. Теперь клиенты более экономны с криптографическими данными, которые они стягивают с сервера, получая только одну подпись с хвоста цепочки подписей, а не подпись каждого промежуточного звена. Таким образом, клиенты потеряли возможность зациклиться в поиске конкретного хеша подписи, но мы ранее использовали эти хеши для поиска плохих чейнлинков в этом списке жёстко закодированных исключений. Мы готовили к выпуску Sigchain V2, забыв об этой детали, похороненной под несколькими слоями абстракций, так что система просто доверяла полю из ответа сервера.
Как только NCC обнаружил эту ошибку, исправление было достаточно простым: поиск жёстко закодированных исключений хешем чейнлинка, а не хешем подписи чейнлинка. Клиент всегда может напрямую вычислить эти хэши.
Мы также можем приписать эту ошибку дополнительной сложности, необходимой для одновременной поддержки Sigchain V1 и Sigchain V2. Современные клиенты записывают ссылки Sigchain V2, но все клиенты должны поддерживать устаревшие ссылки v1 в течение неограниченного времени. Напомним, что клиенты подписывают ссылки своими закрытыми ключами для каждого устройства. Мы не можем в разумные сроки координировать всех клиентов, переписывающих исторические данные, так как эти клиенты могут быть просто в офлайне.
Можете рассказать о NCC-KB2018-004?
Как и в 001 (см. выше), нас подвело определённое сочетание одновременной поддержки устаревших решений и оптимизации, которые казались важными по мере того, как мы получали больше опыта реальной работы с системой.
В Sigchain V2 мы уменьшаем размер цепочек в байтах, чтобы уменьшить полосу пропускания, необходимую для поиска пользователей. Эта экономия особенно важна на мобильных телефонах. Таким образом, мы кодируем chainlinks с MessagePack, а не JSON, что даёт хорошую экономию. В свою очередь, клиенты подписывают и проверяют подписи по этим цепочкам. Исследователи из NCC нашли хитрые способы создавать «подписи», которые выглядят как JSON и MessagePack одновременно, что приводило к конфликту. Мы невольно ввели эту двусмысленность декодирования при оптимизации, когда переключили парсеры JSON со стандартного парсера Go на более производительный. Этот быстрый парсер спокойно пропускал кучу мусора, прежде чем найти фактический JSON, что включало эту возможность polyglot-атаки. Ошибка исправлена дополнительной проверкой ввода.
В Sigchain V2 мы также приняли предложение Адама Лэнгли о том, чтобы подписывающие предваряли свои пакеты с подписями префиксом контекстной строки и байтом , чтобы верификаторы не путались в намерениях подписывающего. На верифицирующей стороне этой контекстно-префиксной идеи были ошибки, которые могли привести к другим polyglot-атакам. Мы быстро исправили этот недостаток с помощью белого списка.
После исправления обоих багов сервер отклоняет вредоносные нагрузки polyglot-атаки, так что эксплуатация данных уязвимостей возможна только с помощью скомпрометированного сервера.
Где документация?
В ближайшие месяцы мы уделим больше времени работе на документацией.
Можете подробнее рассказать об этом заявлении NCC: «Однако злоумышленник способен отказаться от обновления sigchain или откатить sigchain пользователя в предыдущее состояние путём усечения последующих звеньев цепи»
Keybase активно использует неизменяемые append-only структуры общедоступных данных, которые заставляют серверную инфраструктуру фиксировать одно истинное представление идентификаторов пользователей. Мы можем гарантировать отзыв устройств и удаление членов группы таким образом, что скомпрометированный сервер не сможет выполнить откат. Если сервер решает показать несогласованное представление, это отклонение становится частью неизменяемой общедоступной записи. Клиенты Keybase или сторонний аудитор могут обнаружить несоответствие в любое время после атаки. Мы считаем, что эти гарантии намного превосходят гарантии конкурирующих продуктов и являются почти оптимальными с учётом практических ограничений мобильных телефонов и клиентов с ограниченной вычислительной мощностью.
Проще говоря, Keybase не может изобретать чьи-то подписи. Как и любой сервер, он может удерживать данные. Но наше прозрачное дерево Меркла сконструировано для хранения их в течение очень короткого периода времени, и это всегда обнаружимо.
Как Keybase обрабатывает сбросы учётной записи?
Когда пользователи Keybase фактически теряют все свои устройства (в отличие от добавления новых или потери нескольких), им нужно произвести сброс. После сброса аккаунта пользователь в основном новый, но у него то же имя пользователя. Он не может подписать «инструкцию reset», потому что потерял все свои ключи. Так что вместо этого сервер Keybase коммитит нестираемый оператор в дерево Меркла, который означает сброс. Клиенты принудительно обеспечивают невозможность отката этих инструкций. В будущей статье будут подробно описаны конкретные механизмы.
Данному пользователю придётся повторно добавить подтверждения личности (Twitter, Github, что угодно) с новыми ключами.
Может ли сервер просто поменять чей-то лист дерева Меркла, чтобы рекламировать совершенно другой набор ключей?
Авторы NCC рассматривают враждебный сервер Keybase, который полностью меняет лист дерева Меркла, заменяя истинный набор ключей Боба совершенно новым поддельным набором. У атакующего сервера есть два варианта. Во-первых, он может форкнуть состояние мира, поставив Боба в один форк, а тех, кого он хочет одурачить, — в другой. Во-вторых, он может «схитрить», опубликовав версию дерева Меркла с правильным набором ключей Боба и другие версии с поддельным набором. Пользователи, которые регулярно взаимодействуют с Бобом, обнаружат эту атаку, так как они проверят, что ранее загруженные версии истории Боба являются действительными префиксами новых версий, которые они загружают с сервера. Сторонние валидаторы, которые сканируют все обновления Keybase, также заметят эту атаку. Если вы напишете сторонний валидатор Keybase, который нам понравится, мы можем предложить значительное вознаграждение. Обратитесь к max на Keybase. В противном случае мы надеемся в ближайшее время запланировать создание автономного валидатора.
Можете поверить, что я дочитал до конца?
Дочитал или просто прокрутил вниз?
Автор: m1rko
