Корисне запитання про безпеку — не наскільки переконливо звучить шифрування, а що воно захищає, у кого ключі та які свідчення підтверджують заяву.
«Шифрування військового рівня» — недостатня інформація для оцінки застосунку для обміну повідомленнями. Ця фраза не повідомляє, у кого ключі, які розмови захищено, чи розкривають резервні копії відкритий текст і що відбувається, коли пристрій скомпрометовано.
Корисна відповідь — не відкидати шифрування, а замінити ефектний ярлик конкретними твердженнями, які можна перевірити.
AES-256 — вибір алгоритму, а не повна модель безпеки
AES — відкритий стандарт, а не секретна військова технологія. FIPS 197 від NIST визначає AES-128, AES-192 і AES-256; суфікс позначає довжину ключа. У 2023 році стандарт редакційно оновили, не змінюючи алгоритм.
Стійкий шифр усе одно може використовуватися в системі, яка надає сервісу доступ до відкритого тексту. Запитуйте, хто може розшифровувати, а не лише яка довжина ключа. Також запитуйте, як генеруються та зберігаються ключі, як підтверджуються особи й за яких збоїв застосунок зупиняється замість небезпечного продовження роботи.
Коли постачальник називає AES-GCM, це конкретніше, ніж просто AES: GCM поєднує шифрування з автентифікацією. Правильне поводження з nonce, перевірка тегів та інші вимоги до реалізації залишаються важливими. Технічним орієнтиром є специфікація GCM від NIST; логотип не доводить, що застосунок реалізує її правильно.
Чотири різні твердження, які маркетинг часто поєднує
| Твердження | Що воно охоплює | Чого воно не встановлює |
|---|---|---|
| Шифрування під час передавання | Захист з’єднання, наприклад між застосунком і сервером | Що сервер не може читати вміст |
| Шифрування даних у сховищі | Захист збережених даних у межах певної моделі ключів і доступу | Що оператор не має ключа розшифрування |
| Наскрізне шифрування | Захист вмісту між визначеними кінцевими точками | Безпеку скомпрометованої кінцевої точки або чесність одержувача |
| Постквантове встановлення ключів | Стійкість до визначених квантових загроз під час встановлення ключів | Повний аудит застосунку, анонімність або гарантовану майбутню безпеку |
Шифрування під час передавання не означає, що кожна база даних провайдера зберігає необроблений відкритий текст. Сервіс також може шифрувати збережені дані. Важлива відмінність полягає в тому, чи контролює провайдер ключі або чи має інший доступ до читабельного вмісту. Будьте точними, а не замінюйте одне гасло іншим.
Для ширшого вступу зверніться до матеріалу про те, що захищає наскрізне шифрування.
«Використовує стандарт NIST» не означає «пройшов валідацію FIPS»
FIPS 203 визначає ML-KEM, механізм інкапсуляції ключів. Месенджер може описувати використання цього алгоритму, не маючи сертифікації чи незалежної перевірки всього застосунку. Стандарти, тестування алгоритмів, валідація криптографічних модулів та аудити безпеки продукту — різні види свідчень.
Програма валідації криптографічних модулів NIST чітко пояснює: реалізації схвалених функцій недостатньо для підтвердження валідації модуля за FIPS 140. Якщо продукт рекламує валідацію, запросіть сертифікат, точний модуль і версію, робоче середовище та схвалену конфігурацію. Потім з’ясуйте, яку частину продукту цей сертифікат насправді охоплює.
Саме тому «256-бітну безпеку» не слід використовувати як загальну оцінку всього месенджера. Поєднання протоколів, керування ключами та реалізація можуть накладати різні обмеження.
Автентифікація паролем — не шифрування повідомлень
Механізм входу відповідає на запитання, чи може користувач отримати доступ до облікового запису. E2EE відповідає на запитання, хто може читати захищений вміст повідомлень. Жоден із механізмів автоматично не забезпечує властивостей іншого.
Наприклад, SRP призначений для автентифікації без передавання самого пароля. Це не означає, що викрадення бази даних автентифікації нешкідливе. Обговорення безпеки SRP у RFC 5054 пояснює, що викрадений верифікатор дає змогу здійснювати атаки з підбором пароля та створює інші ризики. Уникайте висновку: «Немає паролів, які можна вкрасти, отже, злам сервера не має значення».
Практичний наступний крок для читачів — запитати про відновлення облікового запису, активні сеанси та зв’язок між доступом до облікового запису й ключами шифрування. Відповідь, яка лише повторює «нульове знання», залишає важливі запитання без розв’язання.
П’ять запитань до сторінки безпеки месенджера
- Які області охоплено? Особисті чати, групи, файли, дзвінки, публічні дописи та резервні копії можуть мати різні межі захисту.
- У кого є придатні до використання ключі? Враховуйте ключі відновлення, пов’язані пристрої та режими обробки на сервері.
- Як автентифікується інша кінцева точка? Шукайте перевірку ключів, змістовні попередження про зміни та документовану модель довіри.
- Які свідчення існують? Специфікації, відтворювані збірки, тестові вектори та незалежні аудити відповідають на різні запитання. Уточнюйте версію та область охоплення кожного.
- Що залишається видимим або вразливим? Метадані, скомпрометовані пристрої, скопійовані повідомлення та публічний вміст не повинні зникати з пояснення.
Застосовуйте таку саму перевірку до Livara. Її документація з безпеки називає LVR1 і LGS1 та публікує експлуатаційні межі. Сприймайте це як заяви про продукт, які слід оцінити, а не як незалежну сертифікацію. Proof Lab пропонує обмежені демонстрації та перевірки артефактів, а не доказ того, що кожна функція чи версія є безпечною.
Як читати незалежний аудит
Перевіряйте дату, аудитора, ревізію коду, включені платформи й виключені компоненти. Читайте результати та стан усунення проблем, а не лише підсумковий значок. Аудит криптографічної бібліотеки автоматично не охоплює відновлення облікового запису, вебзастосунок, сповіщення чи експлуатаційну безпеку.
Відсутність аудиту — прогалина в підтвердженні безпеки, а не доказ конкретної вразливості. І навпаки, аудит — не довічна гарантія. Корисне порівняння фіксує свідчення та їхні обмеження замість оголошення універсального «найбезпечнішого» переможця.
Поширені запитання
«Військового рівня» — це завжди інша назва AES-256?
Ні. Не робіть із цієї фрази висновку про конкретний алгоритм чи сертифікацію. Попросіть постачальника точно пояснити, що він має на увазі.
Чи запобігає стійкіше шифрування знімкам екрана або шкідливому ПЗ?
Воно не заважає одержувачу копіювати вміст, а скомпрометованому пристрою — розкривати доступні йому дані. Це інші загрози.
Що є кращою ознакою, ніж гасло про безпеку?
Чітка область охоплення, названий протокол, явні обмеження та доступні для перевірки свідчення щодо реалізації, яка постачається. Пояснення має допомогти вирішити, чому довіряти — і що ще потрібно перевірити.
