Масштаб витоку залежить від типу ключа й тривалості доступу нападника; храповий механізм не гарантує, що під загрозою лише одне повідомлення.
Надійне шифрування потребує й правильного виконання на пристрої. Вразливість операційної системи, реалізації криптографії або обладнання може відкрити доступ до конфіденційних даних. Проте з наявності досліджень атак на процесори не можна робити висновок, що кожен телефон чи месенджер можна зламати тим самим способом.
Корисно запитати: який доступ має нападник, який ключ або текст він може бачити та чи є його доступ тимчасовим або постійним? Відповіді важливіші за назву алгоритму.
Чим побічний канал відрізняється від зчитування пам’яті?
За прямого зчитування пам’яті нападник може мати змогу читати частини пам’яті процесу або пристрою. В атаці побічним каналом інформацію виводять з ознак, як-от час виконання операцій чи поведінка кешу. Ці два підходи не обов’язково мають однакові передумови або результати.
Оригінальне дослідження FLUSH+RELOAD вивчало поведінку кешу та спільні сторінки пам’яті в конкретному експериментальному середовищі й продемонструвало вилучення ключа з однієї версії GnuPG. Цей результат не є перевіркою безпеки Livara чи доказом вразливості всіх процесорів телефонів.
| Тип доступу | Необхідне запитання для оцінки |
|---|---|
| Запуск звичайного застосунку на тому самому пристрої | Чи дозволяють ізоляція процесів і передумови атаки вести спостереження? |
| Привілейований доступ до операційної системи | Які дані або операції з ключами доступні нападнику? |
| Фізичний або лабораторний доступ | Які стан блокування, модель обладнання та захист ключів? |
| Постійний доступ до застосунку | Чи може нападник знову збирати новий текст або ключі? |
Загальний вислів «злам RAM» без цих подробиць не є достатнім технічним поясненням.
Як допомагають Keystore і захищене обладнання?
Android Keystore може обмежувати використання ключів і на відповідних пристроях виконувати операції з апаратною підтримкою. У такій архітектурі неможливість вилучити ключ не тотожна неможливості використати його нападником: заражений застосунок за певних умов може зловживати дозволеними операціями з ключем, навіть не вилучаючи його байти. Посібник Android Keystore.
Також не всі ключі й алгоритми автоматично розміщуються в захищеному обладнанні. Потрібно визначати тип ключа, підтримку пристрою та спосіб використання застосунком. Фраза «ключ на пристрої» сама по собі не доводить його розташування чи рівня захисту.
Чи розкриває витік одного ключа лише одне повідомлення?
Іноді витік незалежного ключа повідомлення має обмежений масштаб. Але якщо нападник отримає ключ ланцюжка, стан сеансу, ключ ідентифікації, читабельну історію або кілька буферів, результат буде іншим. Тому без визначення розкритих даних не можна стверджувати, що під загрозою «щонайбільше одне повідомлення».
Зміна ключа для кожного повідомлення також не обов’язково припиняє доступ нападника. Якщо наступні ключі виводяться зі стану, який він має, або він і далі присутній на пристрої, він може отримати доступ і до наступних повідомлень. Захист минулого та відновлення безпеки майбутнього — дві різні властивості з конкретними припущеннями.
Які обмеження храпового механізму й очищення пам’яті?
Храповий механізм може змінювати ключі протягом розмови. Відновлення після витоку потребує надходження нової інформації, недоступної нападнику; саме надсилання повідомлення не доводить виконання цієї умови. Специфікація Double Ratchet пояснює не лише відновлення, а й ризики тривалого доступу та відновлення видалених даних.
Скорочення часу існування конфіденційних даних і очищення буферів корисні, але з цього не випливає загальне твердження про видалення всіх копій у RAM. Потрібно перевіряти бібліотеки, мову програмування та шляхи відображення.
Що можна сказати про Livara?
Сторінка безпеки Livara описує гібридну структуру й еволюцію ключів у LVR1. Ця стаття не є випробуванням побічних каналів, аудитом пам’яті чи підтвердженням використання Keystore для всіх ключів. Зокрема, публічна документація моделі загроз не гарантує захисту зараженого пристрою.
Тому обіцянки «нейтралізувати апаратний злам наступним повідомленням» або «розкрити щонайбільше одне повідомлення» не слід приписувати продукту без конкретних доказів для тієї самої версії та сценарію.
Практичне рішення для користувача
Оновлюйте операційну систему й застосунок, обирайте пристрій з чинною підтримкою безпеки, уникайте ненадійних встановлень і зайвих дозволів та використовуйте належне блокування. Якщо є підозра на серйозний злам, зміна месенджера або надсилання нового повідомлення не замінить перевірки й очищення пристрою.
Читаючи твердження про безпеку, вимагайте чотири речі: перевірену версію, доступ нападника, розкриті дані та обмеження результату. Назва процесора чи криптографічного стандарту сама по собі не відповідає на ці чотири запитання.
