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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Виведення ключа. Користувач малює візерунок на сітці 5x5 з 25 точок. Послідовність точок по порядку надходить до PBKDF2 з HMAC-SHA512 та унікальною криптографічною сіллю для кожного сховища. На виході: 256-бітний ключ шифрування AES. Візерунок ніколи не зберігається на пристрої. Ні як хеш, ні як представлення, ні в жодному вигляді.

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

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

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

Управління ключами. Vaultaire зберігає сіль пристрою та зашифровану базу даних відновлення як звичайну 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 також пропонує розділений шаблонами доступ до сховища та режим примусу, з обмеженнями зберігання та відновлення, описаними в його правдоподібна документація.

Підсумок

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

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