Що таке наскрізне шифрування і як воно захищає ваші фото
E2EE означає, що ваші фото зашифровані ключем, яким тільки ви володієте. Більшість хмарних сервісів не пропонує цього.
Дані шифруються на авторизованій кінцевій точці до того, як їх отримає постачальник сховища. Надійний дизайн утримує ключ відкритого текстового вмісту поза звичайним контролем постачальника на стороні сервера, тому компроміс лише для зберігання або юридична вимога щодо збереженого вмісту дає зашифрований текст, а не читабельні фотографії. Постачальник все ще може надавати зашифрований текст і метадані, поширювати клієнтське програмне забезпечення або керувати системами відновлення та спільного використання, які повинні бути включені в модель загроз.
E2EE проти шифрування на стороні сервера
| Критерій | Шифрування на стороні сервера | Наскрізне шифрування |
|---|---|---|
| Де генеруються ключі | На сервері провайдера | На пристрої користувача |
| Хто тримає ключі | Провайдер | Авторизовані кінцеві точки або власники відновлення |
| Чи може провайдер розшифрувати | Так | Ні |
| Відповідь на юридичний запит | Провайдер може надати ключі | Нічого надати немає |
| Захист при зломі провайдера | Ні (ключі скомпрометовано) | Так (ключі не на сервері) |
Які сервіси реалізують E2EE для фото
iCloud Photos з ADP (розширений захист даних): увімкніть ADP в Налаштуваннях iOS, щоб перевести iCloud Photos до E2EE. Apple не може розшифрувати ваші фото. Якщо ви втрачаєте всі довірені пристрої без ключа відновлення, ваші дані безповоротно втрачені.
Google Photos: не пропонує E2EE для зберігання фото. Google тримає ключі і може отримати доступ до вашого вмісту.
Виключено шифрування на стороні клієнта з ключами, які зберігаються постачальником. Vaultaire шифрує фотографії та метадані на пристрої за допомогою AES-256-GCM перед будь-яким завантаженням у хмару. Випадковий головний ключ шифрує дані сховища. Локальний ключ сховища, отриманий із шаблону користувача, і сольова оболонка пристрою для цього головного ключа, тоді як окремий резервний ключ, отриманий із шаблону, захищає приватні CloudKit резервні записи. Vaultaire не керує сервером вмісту та не отримує ці ключі, тому не може повернути a CloudKit запис у відкритий текст. додаток, iOS, і розблокований пристрій залишаються в межах довіри, і юридичний запит все одно може отримати метадані облікового запису чи служби, які зберігаються відповідним постачальником.
Як E2EE захищає від різних загроз
- Злом провайдера: якщо сервери хмарного провайдера скомпрометовані, зловмисники отримують лише зашифровані блоби. Без ключів нічого не можна прочитати.
- PBKDF2 з HMAC-SHA512 отримує локальний ключ сховища з намальованого користувачем шаблону та солі пристрою. Фактор роботи підвищує вартість кожного офлайн-припущення, не додаючи ентропії шаблону. Цей ключ сховища автентифікує зашифрований індекс і розгортає випадковий головний ключ, який використовується для даних файлу.
- Розділення ключів провайдера означає, що Wraxle не отримує відкритий текстовий сховище, головний ключ, ключ резервного копіювання чи відновлення. Додатково CloudKit зберігає записи зашифрованого тексту та зашифровані конверти ключів, тоді як Apple все ще може спостерігати метадані служби. Для Vaultaire не потрібен обліковий запис Vaultaire.
Відмінність E2EE від нульових знань
Від постачальників послуг можуть вимагати надати записи, якими вони володіють. З E2EE це може включати зашифрований текст, інформацію про обліковий запис, журнали доступу, розміри записів, хронометраж і метадані спільного використання, а не читабельний вміст фотографій. Чи може запит досягти пристрою, методу відновлення, одержувача чи майбутньої поведінки клієнта – це інше юридичне та технічне питання.
Співробітники або зловмисники, які мають доступ до ключів зберігання, керованих постачальником, можуть отримати доступ до зашифрованого на сервері вмісту. E2EE видаляє цей прямий шлях до ключа зберігання, якщо у постачальника відсутні ключі вмісту відкритого тексту. Це не робить внутрішнє зловживання категорично неможливим, оскільки постачальники можуть контролювати розповсюдження клієнтів, стан облікового запису, метадані, обмін або компоненти відновлення.
Часті запитання
Чи є наскрізне шифрування законним?
Юридичне трактування шифрування, примусового доступу та зашифрованих послуг залежить від юрисдикції та може змінюватися. Цей посібник описує технічну модель, а не юридичну консультацію. Ознайомтеся з чинним місцевим законодавством, якщо ваше використання передбачає обшук на кордоні, судові ухвали, регламентовані записи чи іншу обстановку з високим ризиком.
Чи може правоохоронець зламати наскрізне шифрування?
Атаки рідко потребують повного пошуку AES-256 ключовий простір. Експерт може націлитися на слабкий пароль або шаблон, розблоковану кінцеву точку, пам’ять, фразу відновлення, одержувача, резервну копію або недолік реалізації. Правильно реалізовано AES-256-GCM з випадковим ключем високої ентропії розроблений, щоб протистояти прямому пошуку ключів, але це лише одна частина системи.
Яка різниця між E2EE і шифруванням з нульовими знаннями?
E2EE описує, де відбувається шифрування та дешифрування відкритого тексту та хто має ключі придатного вмісту. «Нульове знання» часто використовується в маркетингу продуктів для сліпого шифрування провайдера, але його не слід розуміти буквально: служба може не мати відкритих текстових ключів, але все ще бачити зашифрований текст, дані облікового запису, розміри, час, зв’язки спільного використання та інші метадані. Оцініть задокументований ключ і шляхи відновлення замість однієї мітки.