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

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 — стандартом Advanced Encryption Standard з 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-бітний результат не розширює ентропію передбачуваного візерунка.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Keychain і межа процесу застосунку

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

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

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

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

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

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

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