Для оцінки безпеки виклику запитуйте не лише «Чи є шифрування?», а й де воно закінчується та що змінює запис.
Шифрування чату саме собою не доводить, що звук, відео, демонстрація екрана чи запис виклику мають такий самий захист. Щоб оцінити виклик, потрібно запитати, до якого моменту медіадані залишаються зашифрованими, хто має ключ і що змінюється, коли вмикають такі функції, як запис.
Цей посібник поділяє твердження про безпеку на рівні, які можна перевірити. Назва протоколу чи значок замка не замінюють відповідей на ці запитання.
Три різні шляхи даних в одному застосунку
| Шлях даних | Приклади даних | Запитання про безпеку |
|---|---|---|
| Повідомлення, що зберігаються | Текст, фотографії, файли й голосові повідомлення | Хто може читати копії на пристрої, на сервері та в резервній копії? |
| Медіадані в реальному часі | Звук із мікрофона, відео й демонстрація екрана | Шифрування закінчується на пристрої співрозмовника чи на проміжному сервері? |
| Сигналізація | Запрошення до виклику, відповідь та інформація для узгодження з'єднання | Хто може змінити керувальні повідомлення або ідентичність адресата? |
Голосове повідомлення, надіслане в чат, — це файл; голосовий виклик — потік у реальному часі. Продукт може використовувати для них різні ключі та механізми. Хороша якість звуку чи недоставлене текстове повідомлення самі собою також нічого не говорять про безпеку іншого каналу.
Про що свідчить DTLS-SRTP?
У WebRTC протокол SRTP захищає медіапотік, а DTLS-SRTP є одним зі способів узгодження потрібного ключового матеріалу. RFC 5764 описує механізм DTLS-SRTP, а RFC 3711 — захист медіапакетів.
Проте фраза «ми використовуємо WebRTC» сама собою не відповідає на запитання, чи розшифровує сервер конференції медіадані. Мають бути чітко визначені кінцеві точки шифрування та спосіб перевірки їхньої автентичності. Між користувачем і сервером може бути зашифроване з'єднання, але сервер водночас може мати доступ до розшифрованого вмісту для обробки або запису. Це не те саме, що наскрізне шифрування (E2EE) між учасниками.
Архітектура безпеки WebRTC у RFC 8827 також показує, що поряд із захистом медіаданих важливі довіра до вебзастосунку, шлях сигналізації та справжність співрозмовника. Шифрування пакетів не означає, що всі компоненти продукту заслуговують на довіру.
Чому сигналізацію потрібно оцінювати окремо?
Сигналізація узгоджує, хто кому телефонує та як встановлюється з'єднання. Навіть якщо застосунок захищає керувальні повідомлення, все одно потрібно перевірити, як цей захист пов'язаний зі справжньою ідентичністю учасників і ключами медіаданих.
Під час читання документації достатньо трьох запитань:
- Чи захищені запрошення, відповідь та інформація про ключі від несанкціонованих змін?
- Як користувач дізнається, що ключ належить саме тому співрозмовнику, з яким він хоче зв'язатися?
- Яке попередження з'являється, коли змінюється ключ або пристрій?
Навіть під час виклику з E2EE сервіс може знати інформацію про маршрутизацію, час виклику та його учасників. Стаття «Що таке метадані месенджера» пояснює цю відмінність.
Запис виклику — нова межа безпеки
Фраза «зашифрований виклик» не дає повної відповіді щодо записаної копії. Учасник може записати звук або зображення на власному пристрої. Запис на стороні сервера також має бути задокументований окремо: чи отримує сервер для запису доступ до медіаданих у відкритому вигляді? Хто зберігає файл? Коли його видаляють?
Якщо ввімкнення запису змінює режим безпеки, учасники мають чітко бачити цю зміну. Перед конфіденційною розмовою перевірте стан запису та згоду учасників. Вимкнений вбудований індикатор запису не гарантує, що ніхто не записує розмову іншим засобом.
Як читати актуальну документацію Livara?
Сторінка безпеки Livara описує прямі та групові виклики як E2EE, але робить виняток для необов'язкового запису на стороні сервера: у режимі з видимим індикатором REC захист виклику змінюється на шифрування під час передавання. Це твердження документації продукту, а не результат тестування чи незалежного аудиту, проведеного в межах цієї статті.
Наведене в старому тексті обмеження всіх групових викликів «від 2 до 6 осіб на Android» не відповідає актуальній документації та не є основою цього посібника. Відомості про допустиму кількість учасників, потрібну платформу й версію слід звіряти з актуальним посібником і реальною поведінкою застосунку. Ця стаття не містить тестування допустимої кількості учасників.
Крім того, згадка алгоритмів чату, як-от ML-KEM, сама собою не доводить, що той самий алгоритм використовується для медіаданих виклику. Для твердження про постквантовий захист викликів потрібні докази, що стосуються саме шляху медіаданих та автентифікації. Читайте модель загроз Livara разом зі сторінкою можливостей, а не замість незалежного тестування.
Короткий контрольний список перед порівнянням двох сервісів
Для кожної відповіді «так» також запишіть версію та джерело:
- Чи описані окремо виклики між двома учасниками, групові виклики й демонстрація екрана?
- Чи чітко вказано, що саме робить сервер: лише пересилає пакети чи може розшифрувати медіадані?
- Чи можна перевірити ідентичність учасника та його ключ?
- Чи помітні зміна пристрою, додавання учасника та ввімкнення запису?
- Чи однаковий шлях виклику у вебверсії та в застосунку, чи є відмінності?
- Чи пояснено зберігання записів і метаданих?
- Чи стосуються результати тестування або аудиту тієї самої версії та функції?
Якщо документація не містить відповіді, напишіть «невідомо». Відсутність відповіді не є доказом ані безпеки, ані прослуховування.
Поширені запитання
Чи перешкоджає виклик з E2EE співрозмовнику записати розмову?
Ні. Авторизований одержувач має доступ до вмісту у відкритому вигляді та може записати його за допомогою програми або іншого пристрою.
Шифрування під час передавання — це погано?
Шифрування під час передавання забезпечує важливий захист від прослуховування на шляху передавання даних. Відмінність у тому, що сервіс, який є кінцевою точкою, може мати доступ до розшифрованого вмісту. Це не слід називати E2EE між користувачами.
Чи робить використання постквантового шифрування в чаті виклики також постквантовими?
Ні. Твердження має стосуватися того самого рівня, алгоритмів і версії реалізації. Оцінюйте чат і виклики окремо.
