Архітектура безпеки: повний технічний стек

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

Криптографічний стек

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

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

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

AES-256-GCM: шифрування файлів

Кожне фото, відео та документ, що зберігається в Vaultaire, зашифровано AES-256-GCM — розширений стандарт шифрування з 256-бітним ключем Режим Galois/Counter. Vaultaire також використовує AES-GCM для індексів сховищ, заголовків файлів, ескізів і конвертів ключів. Алгоритм і розмір ключа стандартизовані; Безпека Vaultaire все ще залежить від обробки nonce, керування ключами, надійності облікових даних і правильності впровадження.

«256» в AES-256 означає довжину ключа в бітах. 256-бітний ключ має 2²⁵⁶ можливих значень. Для розуміння цього числа: в спостережуваному Всесвіті є приблизно 10⁸⁰ атомів. Якщо б кожен атом був суперкомп'ютером, що перевіряє мільярд ключів за секунду і працює з моменту Великого вибуху, вони б дослідили менше трильйонної частки трильйонної частки одного відсотка простору ключів. AES-256 не буде зламано методом перебору. Ні сьогодні. Ні в цьому столітті. Ні до того, як згаснуть зірки.

Чому важливий режим GCM

AES є блоковим шифром: він шифрує дані блоками по 128 біт. «Режим» визначає, як ці блоки об'єднуються. GCM (режим Галуа/лічильника) забезпечує дві речі, яких не мають простіші режими на зразок CBC: паралельне шифрування і вбудовану автентифікацію.

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

PBKDF2: виведення ключів

Vaultaire отримує різні ключі для різних завдань. Візерунок і приладовий Keychain сольовий корм PBKDF2-HMAC-SHA512 для 600 000 ітерацій, щоб створити ключ локального сховища. Виведення детермінованого шаблону створює окремий ключ резервного копіювання хмари. Нормована фраза відновлення проходить через 800 000 PBKDF2 ітерації для створення ключа для конверта відновлення. Жодне з цих похідних не перетворює ідентифікаційні дані людини на 256 біт ентропії лише тому, що вихід має 256 біт.

Як PBKDF2 захищає ваш візерунок

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

Vaultaire налаштовує PBKDF2 з 600 000 ітерацій для ключів, отриманих за шаблоном. Це робить кожне припущення дорожчим, але відповідальна оцінка атаки повинна вказувати виміряний час для кожного кандидата та апаратні припущення. При рівно 1 мс на кандидата 1 000 000 000 серійних вгадувань займає близько 11,6 днів, а не років. 256-бітний результат не розширює ентропію передбачуваного шаблону.

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

AES-256-GCM: Захист метаданих

Шифрування вмісту файлів недостатньо. Імена файлів, дати створення, розміри мініатюр і структура сховища є метаданими, а метадані можуть бути так само показовими, як і самі дані. Файл з назвою «податкова-декларація-2025.pdf» повідомляє зловмиснику точно, що всередині, навіть якщо вміст зашифрований. Мітка часу показує, коли ви використовували сховище. Розмір мініатюри вказує, чи є щось фотографією чи відео.

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

Чому автентифіковане шифрування метаданих?

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

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

Архітектура нульових знань

Варто запитати про будь-який застосунок безпеки: що станеться, якщо компанія, що стоїть за ним, буде зламана, отримає судовий запит або просто стане недобросовісною?

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

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

Що означає нульова довіра на практиці

Якщо правоохоронний орган надсилає Vaultaire повістку з вимогою відкритого тексту сховища, компанія не має шаблону, фрази відновлення, ключа сховища, резервного ключа чи головного ключа, необхідного для його розшифровки. Зашифровано iCloud записи живуть у користувача CloudKit приватна база даних. Однак на пристрої матеріал для відновлення зберігається в зашифрованому вигляді Keychain база даних, а симетричні ключі існують у пам’яті програми CryptoKit шифрує або розшифровує відкрите сховище.

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

Keychain і межа App-Process

Apple Secure Enclave може захищати підтримувані закриті ключі та бере участь у частинах архітектури безпеки платформи, але його публічні API не приймають довільні PBKDF2-похідний симетричний ключ і виконання Vaultaire AES-GCM файлові операції всередині співпроцесора. Тому Vaultaire не описує свій шифр сховища як Secure Enclave AES.

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

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

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

Вектори ініціалізації для кожного файлу

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

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

Нонси зберігаються разом із зашифрованим текстом і не є секретними; їхня вимога безпеки полягає в унікальності за даним ключем. Vaultaire запитує 96-розрядні одноразові коди від криптографічного генератора випадкових значень Apple для одноразового шифрування та записує базовий одноразовий номер у заголовок потокового потоку. Ризик зіткнення залежить від кількості шифрувань під одним ключем, тому реалізація генерує нове значення, а не представляє 96-бітний розмір як фіксований один у двох⁹⁶ довічна гарантія.

Керування пам'яттю: очищення стану активного ключа

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

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

• Активний стан сховища видалено. Додаток видаляє свій поточний сеанс ключа сховища та вимагає повторного розблокування перед показом вмісту сховища.
• Обгортки ключів очищають належні буфери. Захищені байтові контейнери Vaultaire перезаписують буфери, якими вони володіють, коли ці контейнери звільняються.
• Кешований стан головного ключа недійсний. Розшифрований головний ключ, який зберігається для відкритого індексу, відкидається на відповідних шляхах блокування та скидання кешу.
• Розшифровані кеші інтерфейсу користувача очищаються там, де це контролює Vaultaire. Очищення ескізів і попереднього перегляду зменшує залишковий стан програми, не вимагаючи контролю над кожною копією, зробленою Swift, iOSабо інший процес.

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