Що таке шифрування з нульовими знаннями? Простий посібник

Шифрування з нульовими знаннями означає, що провайдер не може отримати доступ до ваших даних.

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

Як працює шифрування з нульовими знаннями

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

Технічно шифрування з нульовими знаннями працює в три кроки:

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

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

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

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

Шифрування з нульовими знаннями порівняно з іншими типами

Термін "шифрування" з'являється в маркетингових матеріалах майже кожного хмарного сервісу. Відмінності між типами є суттєвими.

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

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

Чому шифрування з нульовими знаннями важливе

Витоки даних щорічно відкривають мільярди записів

Ресурсний центр крадіжки особистих даних повідомив про 3205 витоків даних у Сполучених Штатах у 2023 році, що вплинуло на приблизно 353 мільйони осіб. Коли постачальник володіє ключами вмісту, один злам може відкрити як збережені дані, так і шлях до їх розшифрування. Сліпе шифрування постачальника розділяє ці активи: злом сервера все одно може розкрити зашифрований текст і метадані, але не ключ до вмісту, бо постачальник його не має. Вгадування облікових даних і компрометація клієнта залишаються окремими ризиками.

Юридичний примус є реальною загрозою

Від постачальників можуть вимагати розкривати дані, які вони зберігають. Сліпий дизайн постачальника може обмежити цю відповідь зашифрованим текстом і доступними метаданими облікового запису, трафіку, платежів або послуг, оскільки постачальник не має ключа до вмісту. Окреме питання, чи може інша сторона отримати облікові дані користувача, використати клієнта чи змусити розкрити інформацію. Apple представила «Посилений захист даних» в iOS 16.2 як необов’язкове розширення наскрізного шифрування для даних iCloud.

"Довіртеся нам" не є архітектурою безпеки

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

Стандарт NIST, що лежить в основі криптографії

AES-GCM був стандартизований Національним інститутом стандартів і технологій у SP 800-38D (2007). Сама AES була обрана NIST через публічний конкурс у 2001 році. «256» в AES-256 відноситься до 256-бітного ключа. Повний перебір рівномірно випадкового ключа обчислювально неможливий, але людський пароль або візерунок може забезпечити набагато меншу ентропію, навіть якщо функція виведення ключа виводить 256 біт.

GCM (Galois/Counter Mode) додає шифрування з автентифікацією: процес розшифрування виявляє будь-яке втручання в шифротекст. Якщо змінити хоча б один біт зашифрованих даних, розшифрування завершиться помилкою, а не видасть пошкоджений результат. Це не дає зловмисникам непомітно змінювати зашифровані дані.

PBKDF2 (Функція виведення ключа на основі пароля 2), указана в RFC 8018, перетворює облікові дані, надані людиною, у матеріал ключа фіксованої довжини за допомогою повторюваних викликів псевдовипадкових функцій. Більша кількість ітерацій підвищує вартість кожної спроби. Вони не додають ентропії до передбачуваного візерунка чи пароля, тому вибір облікових даних і офлайн-перевірка все ще мають значення.

Як Vaultaire реалізує розділення ключів постачальника

Vaultaire це застосунок-сховище для iPhone, побудований на архітектурі нульових знань.

Виведення ключів. Користувач малює візерунок на сітці 5x5 із 25 точок. PBKDF2-HMAC-SHA512 поєднує цю послідовність з однією сіллю Keychain рівня пристрою для 600 000 ітерацій, щоб отримати 256-бітний ключ сховища. Ключ сховища автентифікує зашифрований індекс і обгортає окремий випадковий 256-бітний головний ключ. Інформація для відновлення, включаючи візерунок, зберігається у зашифрованій AES-GCM базі даних Keychain, а не в текстових файлах чи обліковий запис Vaultaire.

Шифрування файлів. Кожен імпортований файл зашифровано за допомогою AES-256-GCM під випадковим головним ключем. CryptoKit створює автентифіковані sealed box зі свіжими nonce, а потоковий формат виводить окремий nonce для кожного впорядкованого блоку.

Шифрування метаданих. Імена файлів, типи MIME, дати, індексні записи та мініатюрні дані також захищені AES-256-GCM. Vaultaire не використовує ChaCha20 для метаданих сховища.

Управління ключами. Vaultaire зберігає сіль пристрою та зашифровану базу даних відновлення як звичайні елементи generic password в iOS Keychain із класом доступності WhenUnlockedThisDeviceOnly. Ключі сховища, виведені з візерунка, і випадкові головні ключі обробляються у пам’яті застосунку через CryptoKit. Блокування скидає активний стан ключа, але Swift і iOS не гарантують перезапису кожної тимчасової копії.

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

Як визначити, чи використовує застосунок справжнє шифрування з нульовими знаннями

Три тести, що займають менше хвилини:

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

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

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

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

Часті запитання

Чи є шифрування з нульовими знаннями тим самим, що наскрізне шифрування?

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

Що відбувається, якщо я втрачу пароль при шифруванні з нульовими знаннями?

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

Чи може поліція отримати доступ до даних, зашифрованих нульовими знаннями?

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

Чи є шифрування з нульовими знаннями повільнішим?

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

Чи означає нульові знання, що застосунок взагалі не збирає дані?

Не обов'язково. Цей термін стосується межі ключа вмісту постачальника, а не кожного потоку даних. Застосунок все ще може обробляти дані облікового запису, аналітику, звіти про збої, IP-адреси, розміри записів, час або інші метадані служби. Для Vaultaire не потрібен обліковий запис. Його аналітика застосунку і діагностика збоїв увімкнені за замовчуванням, і їх можна вимкнути за допомогою «Анонімно ділитися помилками» у налаштуваннях. Задокументована політика подій виключає вміст сховища, візерунки, фрази та ключі розшифрування; політика конфіденційності описує поточні правила збирання та зберігання.

Як шифрування з нульовими знаннями порівнюється з посиленим захистом даних Apple?

Посилений захист даних (ADP) від Apple, представлений у iOS 16.2, розширює наскрізне шифрування до додаткових категорій iCloud та використовує модель відновлення облікового запису Apple. Vaultaire не потребує облікового запису Vaultaire; зашифроване резервне копіювання (увімкнене за замовчуванням, його можна вимкнути), а також синхронізація та спільний доступ, якщо ви їх налаштуєте, використовують зашифровані на стороні клієнта записи CloudKit в обліковому записі Apple користувача. Vaultaire також пропонує розділений візерунками доступ до сховища та правдоподібну заперечність, з обмеженнями зберігання та відновлення, описаними в його документації про режим примусу.

Підсумок

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

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