Головне
- Відкритий текст шифрується на клієнтському пристрої до завантаження.
- Місце шифрування ще не визначає, хто контролює ключі.
- Клієнтське шифрування стає zero-knowledge лише за належної моделі зберігання ключів.
- Безпека залежить від клієнта, доставлення коду та стану пристрою.
Визначення та область
За клієнтського шифрування застосунок перетворює відкритий текст на шифротекст до відправлення у хмарне сховище. Сервер отримує вже зашифрований об’єкт, тому компрометація лише сховища не розкриває вміст. Ключі можуть створюватися локально або керуватися окремою системою — цей вибір змінює межу довіри. [1][2]
Межа безпеки
Шифрування на клієнті не гарантує наскрізного захисту, якщо сервер може отримати ключ, нав’язати інший ключ або надіслати код, що вилучає відкритий текст. Для оцінювання потрібно простежити створення, обгортання, відновлення й передавання ключів, а також підтвердження пристроїв та одержувачів. [1][3]
Обмеження й оцінка
Після розшифрування дані доступні застосунку й операційній системі, тож шкідливе розширення, заражений пристрій або підмінена збірка залишаються загрозами. Назви об’єктів, розміри, час змін та інші метадані також можуть бути видимими, якщо їх не захищено окремо. [3]
Поширені питання.
Що означає Клієнтське шифрування?
Клієнтське шифрування перетворює відкритий текст на шифротекст на пристрої до надсилання сервісу. Контроль ключів визначає, чи виникає також наскрізна або zero-knowledge межа. [1][3]
Чого не гарантує Клієнтське шифрування?
Після розшифрування дані доступні застосунку й операційній системі, тож шкідливе розширення, заражений пристрій або підмінена збірка залишаються загрозами. Назви об’єктів, розміри, час змін та інші метадані також можуть бути видимими, якщо їх не захищено окремо. [3]
Як SealTask розглядає Клієнтське шифрування?
У SealTask браузерний клієнт і застосунок iOS шифрують захищені поля до відправлення API. Криптографічні операції виконує клієнтська реалізація на базі WebCrypto або WASM, а опублікована модель безпеки описує доставлення ключів і видимі метадані. [3]
Первинні джерела
Визначення надають перевагу органам стандартизації, державним рекомендаціям і архітектурі SealTask із перших рук. Посилання відкривають повне джерело.
- 01 Google Cloud Storage: Client-side encryption keys Первинне джерело або джерело першої сторони для визначення, вимог протоколу, межі безпеки чи нормативного контексту.
- 02 RFC 8439: ChaCha20 and Poly1305 for IETF Protocols Первинне джерело або джерело першої сторони для визначення, вимог протоколу, межі безпеки чи нормативного контексту.
- 03 SealTask security architecture Первинне джерело або джерело першої сторони для визначення, вимог протоколу, межі безпеки чи нормативного контексту.