Цілісність повідомлень: чи може сервер змінити зашифрований чат?

Месенджер може мати функції редагування й видалення, але в системі з автентифікованим шифруванням сервер не повинен мати змоги непомітно змінити шифротекст і все одно доставити дійсне повідомлення. Цілісність повідомлень у месенджері означає, що одержувач може виявити зміну даних після шифрування; це не те саме, що збереження повної історії або юридичне доведення переписки.

Основне

• Автентифіковане шифрування виявляє зміну шифротексту, але не обов’язково зберігає історію правок і видалень.
• Згідно з технічними документами Livara, AES-256-GCM захищає приватні повідомлення тегом автентифікації; змінений пакет не повинен розшифровуватися як дійсний.
• Дозволена правка має бути новою наскрізно зашифрованою подією, а не прихованим перезаписом попереднього пакета сервером.
• Номери безпеки допомагають перевірити ключ співрозмовника, а не його чесність чи юридичну силу знімка екрана.
• У чутливих спорах зберігайте оригінальний файл, часові позначки, стан редагування та незалежні свідчення також поза гілкою переписки.

Що саме означає цілісність повідомлень?

Цілісність повідомлення означає, що одержувач може виявити несанкціоновану зміну зашифрованих даних. Конфіденційність запитує: «Хто може прочитати текст?»; цілісність: «Чи надійшли ті самі дані, які зашифрував відправник?». Пояснення наскрізного шифрування та його меж докладніше розкриває цю різницю.

Це концептуальна ілюстрація з демонстраційними підписами, а не справжній інтерфейс Livara чи результат тесту відхилення зміненого повідомлення.

За технічними документами Livara прямі повідомлення шифруються наскрізно з LVR1, а сумісні приватні групи — з LGS1. Згідно зі сторінкою безпеки Livara, стара несумісна група явно залишається поза E2EE, а нова не створюється з позначкою шифрування до готовності всіх учасників. Перевіряйте стан конкретної розмови. Документи вказують, що LVR1 використовує ECDH P-256 і ML-KEM-768 для виведення ключа повідомлення. Стандартизація компонента не означає незалежного схвалення всієї комбінації чи продукту. Далі Livara використовує AES-256-GCM для захисту вмісту.

За документацією продукту цей захист охоплює текст, правки й вкладення приватних розмов. Але канали Livara не мають наскрізного шифрування: сервер навмисно може читати їхній вміст, зокрема для видалення матеріалів зі зловживаннями. Членство в групах також контролює сервер. Безпеку дзвінків і режим записування слід оцінювати окремо від текстових повідомлень.

Виявлення зміни зашифрованого повідомлення й AES-256-GCM у месенджері

Окрім шифрування вмісту AES-GCM створює тег автентифікації. Якщо зміняться шифротекст або автентифіковані дані, перевірка тега має завершитися невдачею. NIST SP 800-38D визначає режим GCM і попереджає, що повторне використання nonce з одним ключем може серйозно послабити безпеку.

Згідно з технічною специфікацією Livara приватні повідомлення використовують AES-256-GCM. Якщо сервер змінить частину захищеного пакета, без ключа повідомлення він не зможе створити новий тег; тому одержувач не повинен прийняти пакет як неушкоджений. Коротка відповідь на запитання «Чи може сервер змінити повідомлення?»: сервер може видалити, утримати, заблокувати або затримати дані, але не повинен мати змоги видати змінений вміст за дійсний.

Гарантія не безмежна. Криптографія не нейтралізує шкідливе ПЗ на пристрої, доступ нападника до відкритого екрана чи дозволену правку користувача. Цілісність вмісту також не обов’язково приховує метадані. Посібник із метаданих месенджерів і того, що вони розкривають, пояснює цю межу.

Чи може сервер змінити повідомлення, чи редагування — інше?

Сервер не повинен мати змоги таємно переписати попередній зашифрований пакет, але може доставити подію правки, створену відправником. Безпека редагування повідомлень залежить від того, чи автентифікується правка й чи шифрується наскрізно, як початкове повідомлення, а не від прямої зміни збереженого тексту сервером.

Згідно з документацією Livara правки прямого чату захищає LVR1, а сумісної приватної групи — LGS1. Оцінюючи інтерфейс, перевірте, чи показує застосунок стан «відредаговано»; однак криптографія сама собою не зберігає попередню версію вічно на всіх пристроях.

«Видалити для всіх» — також запит на вилучення вмісту, а не доказ знищення всіх копій. Одержувач міг побачити повідомлення, прочитати сповіщення, зберегти файл чи зробити знімок екрана. Зникні повідомлення скорочують збереження, але не гарантують видалення всіх копій.

Що доводить автентифікація повідомлення чату?

Автентифікація повідомлення чату показує, що воно створене з ключами сеансу й не змінене в дорозі. Вона не доводить, що власник облікового запису особисто тримав пристрій, що текст правдивий або що одержувач пізніше зможе остаточно довести його третій особі.

У технічних документах Livara номери безпеки представлені як спосіб виявити зміну ключа. Двоє людей можуть порівняти відбитки ключів через незалежний канал; посібник із перевірки чату за номерами безпеки описує практичні кроки. Це знижує ризик заміни ключа контакту ключем нападника, але не робить заражений пристрій безпечним.

Автентифікація облікового запису — окреме питання. Будь-який механізм входу, хоч би яким сильним він був, не замінює цілісності повідомлень, перевірки ключа контакту чи безпеки пристрою.

Цілісність вмісту — не порядок і свіжість повідомлень

Старий пакет може мати дійсний тег автентифікації. Щоб запобігти повторному прийняттю, потрібні дизайн протоколу, лічильники, ідентифікатор сеансу та збереження стану одержувачем; AES-GCM сам собою не є журналом порядку всієї розмови. Ця різниця важлива для оцінювання повторного відтворення, затриманих повідомлень і синхронізації кількох пристроїв.

Треба також визначити, які дані справді охоплює тег. Якщо ідентифікатор розмови чи тип події перебувають поза автентифікованим контекстом, одного захисту тіла недостатньо. Перевірка коду й тестування саме цієї версії мають прояснити зв’язок.

Якщо текст або стан повідомлення несподівані

Запишіть версію застосунку, час спостереження, залучені пристрої та наявність позначки редагування. Незалежним каналом уточніть у співрозмовника, чи робив він дозволену правку. Не приписуйте розбіжність синхронізації втручанню сервера без свідчень, але й не ігноруйте без причини помилку автентифікації чи зміну ключа.

Для технічного звіту використовуйте нечутливе тестове повідомлення й не включайте приватні дані співрозмовника в публічний звіт. Якщо переписку планують використовувати в юридичній справі, криптографія чи знімок екрана самі собою не визначають юридичної допустимості; до зміни доказів зверніться до кваліфікованого фахівця.

Як оцінювати заяву про цілісність месенджера?

Не обмежуйтеся словом «зашифровано». Запитайте:

• Які розмови та файли шифруються наскрізно?
• Який алгоритм AEAD використовує сервіс?
• Як реєструються та відображаються правки й видалення?
• Як користувач виявляє зміну ключа контакту?
• Які метадані, вміст чи членство контролює сервер?
• Чи дають дзвінки ті самі гарантії, що й повідомлення?
• Чи проходив протокол незалежний аудит?

Livara публікує специфікації й інструменти для перевірки деяких своїх заяв, а користувачі Android можуть порівняти контрольну суму APK із SHA-256 у Proof Lab для офлайн-перевірки застосунку. Однак ця стаття не надає доказу незалежного аудиту поточної версії. Публікація специфікацій і тестових векторів допомагає перевірці, але не замінює незалежного аудиту.

Для приватних розмов основна заява Livara обмежена й чітка: AES-256-GCM має виявляти зміну пакета, а правки також мають шифруватися. Це не означає незмінного журналу, гарантованого видалення всіх копій чи автоматичного юридичного доказу.

Поширені запитання

Чи може адміністратор сервера змінити текст зашифрованого повідомлення?

За правильного дизайну з AES-256-GCM адміністратор без ключа повідомлення не може змінити шифротекст і створити дійсний тег. Він усе ще може видалити, заблокувати чи затримати пакет. Ця гарантія не охоплює заражений пристрій або дозволену правку відправника.

Чи доводить позначка «відредаговано», якою була попередня версія?

Ні. Вона лише каже, що відображуваний вміст змінився після надсилання, якщо застосунок не зберігає також історію версій. Шифрування може перевірити автентичність події правки, але не зберігає автоматично попередній текст.

Чи гарантує номер безпеки автентичність усіх повідомлень?

Ні. Він допомагає перевірити належність ключа контакту й виявити його зміну. Перевірка не каже, хто тримав пристрій під час надсилання, чи правдиве повідомлення й чи немає на пристрої шкідливого ПЗ.

Чи видаляє «видалити для всіх» повідомлення звідусіль?

Ні. Функція може прибрати копію всередині застосунку, але не відкликає збережений файл, сповіщення, знімок екрана чи попередній запис. Вона скорочує збереження, але не гарантує видалення з пристрою одержувача чи інших систем.