Що таке наскрізне шифрування? Як воно захищає ваші фото
Наскрізне шифрування не дає постачальникові сховища отримати читабельний вміст фото й ключі вмісту у відкритому вигляді.
Наскрізне шифрування (E2EE) — модель безпеки, у якій відкриті дані шифруються на одному довіреному кінцевому пристрої й розшифровуються на іншому. Постачальник сховища чи каналу передавання не зберігає ключа вмісту у відкритому вигляді. Ця межа захищає вміст від прямого читання на сервері, але не приховує всіх метаданих і не захищає скомпрометований кінцевий пристрій, облікові дані відновлення, одержувача спільного доступу чи шкідливе оновлення клієнта.
Для зберігання фото наскрізне шифрування означає, що телефон шифрує вміст фото до завантаження, а хмара зберігає шифротекст, а не читабельні зображення. Для розшифрування потрібен ключ, доступний через довірений пристрій або шлях відновлення. Розмір файлів, час, дані облікового запису, зв'язки спільного доступу та інші метадані можуть залишатися видимими. У цьому посібнику пояснено цю межу й порівняно поширені моделі сервісів.
Як працює наскрізне шифрування
Основний механізм складається з трьох етапів: створення ключа, шифрування й розшифрування.
Створення ключа
Пристрій користувача створює криптографічний ключ. У симетричному шифруванні (наприклад, AES-256) один і той самий ключ шифрує й розшифровує. В асиметричному шифруванні (наприклад, RSA) відкритий ключ шифрує, а закритий розшифровує. Багато систем E2EE поєднують обидва підходи: асиметричне шифрування передає симетричний сеансовий ключ, який потім шифрує основний обсяг даних.
Фотосховища використовують різні схеми керування ключами. Деякі формують ключ файлу просто з пароля; сильніші багаторівневі схеми можуть використовувати ключ розблокування, сформований з облікових даних, щоб обгорнути випадковий ключ файлу. Vaultaire використовує PBKDF2-HMAC-SHA512, щоб сформувати 256-бітний ключ сховища з візерунка на сітці 5x5 і спільної для пристрою солі. Цей ключ сховища перевіряє автентичність зашифрованого індексу й розгортає окремий випадковий майстер-ключ, яким шифруються файли.
Шифрування
Відкриті дані (ваше фото) перетворюються на шифротекст за допомогою ключа й алгоритму шифрування. AES-256-GCM — найпоширеніший симетричний шифр для цього завдання. GCM (режим Галуа/лічильника) забезпечує автентифіковане шифрування: він шифрує дані й створює тег автентифікації, який виявляє будь-яке втручання. Кожен файл отримує унікальний вектор ініціалізації (IV), тому однакові файли дають різний шифротекст.
Розшифрування
Пристрій одержувача використовує той самий ключ (симетричне шифрування) або відповідний закритий ключ (асиметричне) і виконує зворотне перетворення. Без правильного ключа шифротекст неможливо відрізнити від випадкових даних. Математичного обхідного шляху немає. AES-256 має 2^256 можливих ключів — більше, ніж оціночна кількість атомів у спостережуваному Всесвіті.
Наскрізне шифрування та інші моделі шифрування
Не кожне шифрування наскрізне. Від відмінностей залежить, хто може отримати доступ до ваших даних.
Шифрування під час передавання (TLS/SSL)
Дані шифруються між вашим пристроєм і сервером. Сервер розшифровує їх під час отримання. Це захищає від перехоплення під час передавання, але залишає дані читабельними на сервері. Шифрування під час передавання використовують усі великі хмарні сервіси. Це базовий мінімум, а не еталон.
Шифрування під час зберігання (на боці сервера)
Сервер шифрує збережені дані ключами, якими сам керує. Це захищає від фізичної крадіжки серверного обладнання, але не від постачальника сервісу, його працівників і юридичних запитів до постачальника. iCloud, Google Drive і Dropbox використовують шифрування під час зберігання на боці сервера. Ключі в постачальника.
Наскрізне шифрування
Дані шифруються на довіреному кінцевому пристрої до того, як їх отримає постачальник сховища. Грамотна схема не залишає ключа вмісту у відкритому вигляді у звичайному розпорядженні сервера постачальника, тому злам лише сховища чи юридична вимога щодо збереженого вмісту дають шифротекст, а не читабельні фото. Постачальник однаково може передати шифротекст і метадані, поширювати клієнтське ПЗ або керувати системами відновлення й спільного доступу, які треба враховувати в моделі загроз.
| Модель шифрування | У кого ключі | Постачальник може читати дані? | Захищає від постачальника? |
|---|---|---|---|
| Лише під час передавання (TLS) | Сервер | Так | Ні |
| Під час зберігання (на боці сервера) | Сервер | Так | Ні |
| Наскрізне | Довірені кінцеві пристрої або власники відновлення | Не з одного лише збереженого шифротексту | Захищає вміст від ключів сховища в постачальника |
| Шифрування на боці клієнта, невидиме для постачальника | Клієнт і задокументовані шляхи відновлення | Доступу до відкритого вмісту немає за задумом | Захищає вміст; метадані й довіра до клієнта залишаються |
Як фотосховища поводяться із шифруванням
Моделі шифрування у фотосховищ дуже різняться. Деякі рекламують «шифрування», не уточнюючи моделі, і користувачі можуть помилково вирішити, що їхні фото захищені E2EE.
Фото iCloud
Apple використовує шифрування під час передавання й зберігання. За замовчуванням ключі шифрування в Apple. На чинний юридичний запит Apple може передати дані «Фото iCloud». Виняток: Посилений захист даних (ADP) від Apple, доступний із грудня 2022 року, додає наскрізне шифрування для «Фото iCloud». ADP треба явно ввімкнути в «Параметрах». Після ввімкнення Apple не має доступу до даних «Фото iCloud». Більшість користувачів ADP не ввімкнули.
Google Photos
Google використовує шифрування під час передавання й зберігання з ключами на боці сервера. Ключі шифрування всіх даних Google Photos, включно з вмістом «Заблокованої теки», зберігає Google. Google може виконувати юридичні запити даних. Наскрізного шифрування для Google Photos Google не пропонує.
Dropbox
Шифрування під час передавання (TLS 1.2+) і зберігання (AES-256 із ключами, якими керує Dropbox). Ключі в Dropbox, і він може отримати доступ до ваших файлів. У Dropbox були витоки даних (2012, 68 мільйонів облікових записів). Dropbox Vault (платна функція) додає захист PIN-кодом, але не наскрізне шифрування.
OneDrive
Microsoft використовує шифрування під час передавання й зберігання з ключами, якими керує Microsoft. Ключі в Microsoft. Особисте сховище OneDrive додає перевірку особи (2FA), але не наскрізне шифрування — Microsoft і далі може отримати доступ до даних. Корпоративним клієнтам доступні ключі, якими керує клієнт.
Vaultaire
Шифрування на боці клієнта без ключів у постачальника. Vaultaire шифрує фото й метадані на пристрої за допомогою AES-256-GCM до будь-якого завантаження в хмару. Випадковий майстер-ключ шифрує дані сховища. Локальний ключ сховища, сформований з візерунка користувача й солі пристрою, обгортає цей майстер-ключ, а окремий ключ резервної копії, сформований з візерунка, захищає приватні записи резервної копії в CloudKit. Vaultaire не керує сервером вмісту й не отримує цих ключів, тому не може перетворити запис CloudKit на відкриті дані. Застосунок, iOS і розблокований пристрій залишаються всередині межі довіри, а юридичний запит однаково може отримати метадані облікового запису чи сервісу від відповідного постачальника.
| Сервіс | Шифрування під час передавання | Шифрування під час зберігання | Наскрізне шифрування | Постачальник має доступ |
|---|---|---|---|---|
| «Фото iCloud» (за замовчуванням) | Так | Так (ключі Apple) | Ні | Так |
| «Фото iCloud» (ADP увімкнено) | Так | Так | Так | Ні |
| Google Photos | Так | Так (ключі Google) | Ні | Так |
| Dropbox | Так | Так (ключі Dropbox) | Ні | Так |
| OneDrive | Так | Так (ключі Microsoft) | Ні | Так |
| Vaultaire | Так | Так | Резервна копія із шифруванням на боці клієнта, увімкнена за замовчуванням | Немає ключа вмісту у відкритому вигляді; метадані CloudKit залишаються |
Чому наскрізне шифрування важливе для фото
Фото — особливо чутливі дані. На них є обличчя, місця (метадані GPS), час зйомки й візуальні записи особистих моментів. Витік медіатеки розкриває більше особистої інформації, ніж майже будь-який інший тип даних.
Витоки даних
Коли постачальник зберігає фото з ключами на боці сервера, злам і сховища, і системи керування ключами може розкрити читабельний вміст. За грамотного E2EE злам лише сховища дає шифротекст і ті метадані, які зберігає сервіс. Компрометація кінцевого пристрою, крадіжка облікових даних відновлення, шкідливе клієнтське ПЗ і помилки служби ключів залишаються окремими шляхами до відкритих даних.
Доступ за законом і з боку держави
Від постачальників сервісів можуть вимагати передати записи, які в них є. За E2EE це можуть бути шифротекст, дані облікового запису, журнали доступу, розміри записів, час і метадані спільного доступу, а не читабельний вміст фото. Чи може вимога дістати до пристрою, способу відновлення, одержувача чи майбутньої поведінки клієнта — окреме юридичне й технічне питання.
Внутрішній доступ
Працівники чи зловмисники з доступом до ключів сховища, якими керує постачальник, можуть дістатися до вмісту, зашифрованого на боці сервера. E2EE прибирає цей прямий шлях через ключі сховища, якщо в постачальника немає ключів вмісту у відкритому вигляді. Зловживань зсередини це не виключає повністю, бо постачальник може керувати поширенням клієнта, станом облікового запису, метаданими, спільним доступом чи компонентами відновлення.
Захист метаданих
Деякі реалізації E2EE шифрують лише вміст файлів, залишаючи метадані на кшталт імен файлів і дат незахищеними. Vaultaire захищає заголовки файлів, типи MIME, індекси, мініатюри та інші метадані сховища автентифікованим шифруванням AES-256-GCM. Довжина збереженого шифротексту й кількість зашифрованих файлів зберігання однаково можуть розкрити структурну інформацію тому, хто має доступ до контейнера застосунку, наприклад оцінку того, скільки сховищ містять файли.
Поширені хибні уявлення про E2EE
«Моє хмарне сховище зашифроване, тож мої фото в безпеці». Шифрування на боці сервера захищає від зовнішніх зламів серверного обладнання. Воно не захищає від самого постачальника, юридичних запитів і внутрішніх загроз. Ключі в постачальника.
«HTTPS означає, що мої фото захищені наскрізним шифруванням». HTTPS (TLS) шифрує дані під час передавання між вашим пристроєм і сервером. Коли дані надходять на сервер, вони розшифровуються. HTTPS шифрує канал, а не дані.
«Наскрізне шифрування означає, що ніхто ніколи не побачить моїх фото». E2EE означає, що ваших фото не побачить ніхто без ключа. Якщо хтось має ваш пароль чи ключ, він зможе розшифрувати дані. Керування ключами й надійні паролі й далі потрібні.
«Apple/Google не бачать моїх фото». За замовчуванням обидві компанії зберігають ключі шифрування ваших фото в хмарі. Apple пропонує Посилений захист даних як опцію, яку можна ввімкнути. Google узагалі не пропонує E2EE для Google Photos.
Як Vaultaire реалізує наскрізне шифрування
Vaultaire використовує багаторівневий підхід до E2EE:
- AES-256-GCM шифрує весь вміст файлів. Кожен файл отримує унікальний вектор ініціалізації. Автентифіковане шифрування виявляє втручання.
- PBKDF2 з HMAC-SHA512 формує локальний ключ сховища з намальованого користувачем візерунка й солі пристрою. Фактор складності підвищує вартість кожної офлайн-спроби підбору, але не додає візерунку ентропії. Цей ключ сховища перевіряє автентичність зашифрованого індексу й розгортає випадковий майстер-ключ, яким шифруються дані файлів.
- AES-256-GCM для метаданих захищає імена файлів, дати, розміри, індекси й мініатюри автентифікованим шифруванням.
- Keychain і Data Protection в iOS захищають сіль пристрою й зашифровану базу даних відновлення. Операції AES-GCM і активні симетричні ключі залишаються в процесі застосунку, поки сховище відкрите.
- Розділення ключів із постачальником означає, що Wraxle не отримує ключа сховища, майстер-ключа, ключа резервної копії чи ключа відновлення у відкритому вигляді. Резервна копія CloudKit (увімкнена за замовчуванням), синхронізація й спільний доступ зберігають записи шифротексту й зашифровані конверти ключів, а Apple однаково бачить метадані сервісу. Для Vaultaire не потрібен обліковий запис Vaultaire.
Vaultaire зберігає дані для відновлення, включно з візерунком, у базі даних, зашифрованій AES-GCM і збереженій у Keychain iOS. Вони не записуються у відкриті файли й не надсилаються в службу облікових записів Vaultaire. Якщо не залишилося ні робочого візерунка, ні фрази відновлення, ні вже розблокованого пристрою, Vaultaire не має ключа відновлення постачальника, який міг би повернути доступ.
Часті запитання
Чи законне наскрізне шифрування?
Правовий режим шифрування, примусового доступу й зашифрованих сервісів залежить від юрисдикції і може змінюватися. У цьому посібнику описано технічну модель, а не юридичну консультацію. Перевірте чинне місцеве законодавство, якщо ваша ситуація пов'язана з оглядом на кордоні, судовими рішеннями, регульованими записами чи іншим високим ризиком.
Чи можуть правоохоронні органи зламати наскрізне шифрування?
Атакам рідко потрібно перебирати весь простір ключів AES-256. Дослідник може атакувати слабкий пароль чи візерунок, розблокований кінцевий пристрій, пам'ять, фразу відновлення, одержувача, резервну копію або помилку реалізації. Правильно реалізований AES-256-GCM із випадковим ключем високої ентропії розрахований на те, щоб витримувати прямий перебір ключа, але це лише одна частина системи.
Чим E2EE відрізняється від шифрування з нульовим розголошенням?
E2EE описує, де відбуваються шифрування й розшифрування відкритих даних і в кого є придатні ключі вмісту. «Нульове розголошення» часто використовують у маркетингу продуктів для шифрування, невидимого для постачальника, але його не варто розуміти буквально: сервіс може не мати ключів у відкритому вигляді й при цьому бачити шифротекст, дані облікового запису, розміри, час, зв'язки спільного доступу та інші метадані. Оцінюйте задокументовані шляхи ключів і відновлення, а не лише ярлик.
Чи сповільнює наскрізне шифрування мій телефон?
Сучасні пристрої ефективно виконують AES-256 завдяки апаратному прискоренню, доступному через системні криптографічні бібліотеки. На iPhone Vaultaire виконує AES-GCM у процесі застосунку через CryptoKit. Публічні API Secure Enclave від Apple не є довільним рушієм AES-GCM для шифрування файлів. Витрати на шифрування й розшифрування залежать від розміру файлу й пристрою, але розраховані на те, щоб не заважати у звичайному використанні.
Що буде, якщо я втрачу ключ шифрування?
Якщо втратити всі робочі шляхи розшифрування й відновлення, зашифровані дані відновити не можна. Тому багато систем E2EE використовують фрази відновлення, довірені пристрої, контакти для відновлення, аварійні набори чи зашифровані конверти ключів. Ці механізми зберігають доступ, але кожен із них теж стає частиною моделі безпеки.
Підсумок
Наскрізне шифрування може прибрати шлях постачальника сховища до ключа у відкритому вигляді, якщо шифрування відбувається на довіреному кінцевому пристрої до завантаження. Це вагомий захист, а не гарантія для всієї системи. Перш ніж довірити сервісу особисті фото, перевірте, у кого ключі вмісту, як улаштовані відновлення, метадані, оновлення клієнта, безпека кінцевих пристроїв і спільний доступ.
Vaultaire реалізує шифрування на боці клієнта для iOS. Ваші фото й метадані сховища шифруються на пристрої за допомогою AES-256-GCM до резервного копіювання чи синхронізації. Vaultaire не отримує ключів розшифрування й не керує сервером, який міг би перетворити ці зашифровані записи на ваші фото. Ця межа з постачальником не робить скомпрометований чи розблокований iPhone надійним.