Масштаб утечки зависит от типа ключа и длительности доступа атакующего; храповой механизм не гарантирует, что под угрозой лишь одно сообщение.
Надёжное шифрование требует и корректного выполнения на устройстве. Уязвимость операционной системы, реализации криптографии или оборудования может открыть доступ к конфиденциальным данным. Однако из существования исследований атак на процессоры нельзя заключать, что любой телефон или мессенджер можно взломать тем же способом.
Полезно спросить: какой доступ есть у атакующего, какой ключ или текст он может видеть и является ли его доступ временным или постоянным? Ответы важнее названия алгоритма.
Чем побочный канал отличается от извлечения памяти?
При прямом извлечении памяти атакующий может иметь возможность читать части адресного пространства процесса или памяти устройства. При атаке по побочному каналу информацию выводят из признаков, таких как время выполнения операций или поведение кеша. Предпосылки и результаты этих двух подходов не обязательно совпадают.
Оригинальное исследование FLUSH+RELOAD изучало поведение кеша и общие страницы памяти в определённой экспериментальной среде и продемонстрировало извлечение ключа из одной из версий GnuPG. Этот результат не является проверкой безопасности Livara или доказательством уязвимости всех процессоров телефонов.
| Тип доступа | Необходимый вопрос для оценки |
|---|---|
| Запуск обычного приложения на том же устройстве | Позволяют ли изоляция процессов и предпосылки атаки вести наблюдение? |
| Привилегированный доступ к операционной системе | Какие данные или операции с ключами доступны атакующему? |
| Физический или лабораторный доступ | Каковы состояние блокировки, модель оборудования и защита ключей? |
| Постоянный доступ к приложению | Может ли атакующий повторно собирать новый текст или ключи? |
Общее выражение «взлом RAM» без этих подробностей не является достаточным техническим объяснением.
Чем помогают Keystore и защищённое оборудование?
Android Keystore может ограничивать использование ключей и на подходящих устройствах выполнять операции с аппаратной поддержкой. В такой архитектуре неизвлекаемость ключа не равна невозможности его использования атакующим: заражённое приложение при определённых условиях может злоупотребить разрешёнными операциями с ключом, даже не извлекая его байты. Руководство Android Keystore.
Кроме того, не все ключи и алгоритмы автоматически размещаются в защищённом оборудовании. Необходимо уточнять тип ключа, поддержку со стороны устройства и способ его использования приложением. Фраза «ключ находится на устройстве» сама по себе не доказывает ни место его хранения, ни уровень защиты.
Раскрывает ли утечка одного ключа лишь одно сообщение?
Иногда утечка независимого ключа сообщения имеет ограниченный масштаб. Но если атакующий получает ключ цепочки, состояние сеанса, ключ идентификации, читаемую историю или несколько буферов, результат иной. Поэтому без указания утёкших данных нельзя утверждать, что под угрозой «не более одного сообщения».
Смена ключа для каждого сообщения также не обязательно прекращает доступ атакующего. Если следующие ключи выводятся из состояния, которым он располагает, или он по-прежнему присутствует на устройстве, ему могут стать доступны и следующие сообщения. Защита прошлого и восстановление безопасности будущего — разные свойства с определёнными предпосылками.
Каковы ограничения храпового механизма и очистки памяти?
Храповой механизм может изменять ключи по мере общения. Восстановление после утечки требует поступления новой информации, недоступной атакующему; сама отправка сообщения не доказывает выполнения этого условия. Спецификация Double Ratchet объясняет не только восстановление, но и риски постоянного доступа и восстановления удалённых данных.
Сокращение времени жизни конфиденциальных данных и очистка буферов полезны, но из этого не следует общее утверждение об удалении всех копий в RAM. Следует изучать библиотеки, язык программирования и пути отображения данных.
Что можно сказать о Livara?
Страница безопасности Livara описывает гибридную структуру и эволюцию ключей в LVR1. Эта статья не является испытанием на атаки по побочным каналам, аудитом памяти или подтверждением использования Keystore для всех ключей. В частности, публичная документация модели угроз не гарантирует защиту заражённого устройства.
Поэтому обещания «нейтрализовать аппаратный взлом следующим сообщением» или «раскрыть максимум одно сообщение» нельзя приписывать продукту без конкретных доказательств для той же версии и сценария.
Практическое решение для пользователя
Обновляйте операционную систему и приложение, выбирайте устройство с действующей поддержкой безопасности, избегайте ненадёжных установок и избыточных разрешений, используйте подходящую блокировку. При подозрении на серьёзный взлом смена мессенджера или отправка нового сообщения не заменяет проверку и очистку устройства.
Читая утверждение о безопасности, требуйте четыре вещи: проверенную версию, доступ атакующего, раскрытые данные и ограничения результата. Название процессора или криптографического стандарта само по себе не отвечает на эти четыре вопроса.
