Результат форензики залежить від фактичного стану пристрою й ключів, а не лише від назви бази даних чи алгоритму.
Наскрізне шифрування та захист локальних даних — пов’язані, але різні завдання. Повідомлення, захищене під час передавання мережею, має стати читабельним для показу на пристрої. Результат криміналістичного дослідження залежить від стану пристрою, типу доступу, версії системи й застосунку та розташування ключів; сама назва алгоритму не визначає результат.
Тому обережності потребують як твердження «за фізичного доступу все одразу можна прочитати», так і обіцянка «вилучення ніколи не можливе».
Розглядайте чотири рівні захисту окремо
| Рівень | Основна функція | Важливе обмеження |
|---|---|---|
| E2EE повідомлень | Захист вмісту між пристроями учасників | Не гарантує безпеку пристрою й локальних копій |
| Ізоляція застосунків | Обмеження доступу звичайних застосунків до даних один одного | Високопривілейований доступ або вразливість можуть змінити модель |
| Шифрування файлів чи диска | Захист збережених даних за певних умов | Важливі стан блокування й доступність ключа |
| Шифрування бази даних у застосунку | Додаткова межа захисту файлу бази даних | Вирішальне значення мають зберігання й використання ключа |
Документація Android FBE розрізняє сховище, залежне від облікових даних користувача, та сховище, доступне в Direct Boot. З фрази «телефон заблоковано» не можна визначити повний стан ключів; може мати значення й те, чи відбулося перше розблокування після запуску.
Що доводить файл SQLite?
SQLite — формат і рушій зберігання, а не позначка, яка сама собою показує наявність або відсутність усіх захистів. Файл може перебувати в зашифрованому просторі операційної системи або захищатися окремим рішенням.
Також видалення рядка не обов’язково усуває всі його сліди в усіх файлах. Документація SQLite пояснює налаштування безпечного видалення й обмеження віртуальних таблиць. Під час розгляду життєвого циклу даних потрібно враховувати також допоміжні файли й резервні копії. Це не означає гарантованого відновлення будь-якого видаленого повідомлення на будь-якому телефоні.
Не виконуйте команд обслуговування бази на реальних даних без знання застосунку; пряме змінення його файлів може пошкодити дані або змінити докази.
SQLCipher і Keystore — рішення, а не сертифікати невразливості
SQLCipher призначений для прозорого шифрування бази даних, але характеристики потрібно читати з урахуванням версії. Сторінка архітектури SQLCipher описує AES-CBC з автентифікацією; анонс бета-версії 5 у вересні 2026 року повідомляє про перехід на AES-GCM. Тому приписувати один режим шифрування всім версіям неточно.
Android Keystore також може забезпечувати захист ключа й контроль його використання, але слід установити, які можливості та який апаратний рівень насправді використовує застосунок. Згадка StrongBox у статті не доводить його використання продуктом. Посібник Keystore.
Навіть ключ, який неможливо вилучити, за певних умов можна використати через дозволені операції. «Ключ неможливо скопіювати» та «зловмисник не може відкрити жодних даних» — не одне твердження.
Яку роль відіграють RAM і ратчет?
Обмеження часу життя ключа й чутливого тексту зменшує кількість можливостей витоку. Але очищення одного буфера не доводить, що інші копії не залишилися в бібліотеці, попередньому перегляді або процесі відображення.
Дія ратчета також різниться залежно від типу розкритого ключа й збереження доступу зловмисника. З «окремого ключа для кожного повідомлення» не можна зробити висновок, що один знімок пам’яті розкриває щонайбільше одне повідомлення. Зберігання читабельної історії на пристрої — окреме питання від ключів передавання.
Що не підтверджено щодо Livara?
Модель загроз Livara не гарантує захисту зараженого або розблокованого пристрою. Ця стаття не підтверджує незалежно використання SQLCipher чи StrongBox певною версією Livara, повне очищення RAM або відсутність локальних даних викликів. Без звіту про випробування та доказів реалізації ці властивості не можна приписувати продукту.
Крім того, пакет відновлення ідентичності в документації безпеки — не те саме, що резервна копія історії. Перевірка хешу APK у Proof Lab може показати відповідність файлу довіреному хешу; її результат не є аудитом зберігання чи тестом захисту від форензики.
Які відомості має містити обґрунтована заява про форензику?
Запитуйте модель пристрою, версії системи й застосунку, стан блокування, метод і рівень доступу, тип отриманих даних та обмеження тесту. Невдача одного інструмента в одному експерименті не доводить неможливості всіх методів; обмежений успіх також не дає підстав поширювати результат на всіх користувачів.
Для звичайного користувача пріоритетні оновлення, надійне блокування, зменшення зайвих копій медіа й захист способів відновлення. У разі серйозного інциденту зверніться до уповноваженого фахівця до дій, що змінюють дані або докази.
