Architettura di Sicurezza: lo stack tecnico completo

Vaultaire utilizza AES-256-GCM per la crittografia autenticata su indici del vault, chiavi incapsulate, intestazioni di file, contenuti, miniature e metadati. PBKDF2-HMAC-SHA512 deriva una chiave dell'insieme di credenziali locale dal modello e una chiave a livello di dispositivo Keychain sale. La chiave del vault racchiude una chiave master casuale separata a 256 bit, che esegue la crittografia del file CryptoKit nel processo dell'app.

Lo stack crittografico

Vaultaire utilizza diversi meccanismi crittografici che lavorano di concerto, ciascuno scelto per un lavoro specifico. PBKDF2 trasforma una credenziale umana in un caveau o in una chiave di ripristino. AES-256-GCM protegge indici, wrapper, metadati, miniature e contenuto dei file. Una chiave master casuale separa la crittografia dei file di lunga durata da uno schema modificabile. Keychain e iOS La protezione dei dati protegge i record di sale e ripristino associati al dispositivo mentre il dispositivo è bloccato. Nessuna chiave di decrittazione posseduta dal provider fornisce allo sviluppatore l'accesso di routine al testo in chiaro del vault.

Questa non è complessità fine a se stessa. Ogni livello affronta una superficie di attacco diversa. AES-256-GCM combina la riservatezza con l'autenticazione, quindi il testo cifrato modificato non supera la verifica. PBKDF2 aumenta il costo del test di ogni modello o frase. La chiave master casuale significa che una modifica del pattern può riavvolgere una chiave invece di crittografare nuovamente ogni file. Keychain protezione dei dati protegge i record locali di salt e ripristino, mentre l'app riconosce comunque che la crittografia simmetrica avviene nella memoria del processo.

Insieme, questi livelli formano un’architettura di difesa approfondita, ma non sono tutte barriere indipendenti. Un modello indovinato può essere confrontato con il nome del file indice e AES-GCM l'autenticazione e un dispositivo sbloccato compromesso può osservare chiavi o testo non crittografato nel processo dell'app. L’architettura dipende quindi dall’entropia delle credenziali, PBKDF2 costo, iOS protezione del dispositivo e corretta gestione della crittografia autenticata, nonché la forza di AES stesso.

AES-256-GCM: crittografia file

Ogni foto, video e documento archiviato in Vaultaire è crittografato con AES-256-GCM — lo standard di crittografia avanzato con chiave a 256 bit Modalità Galois/Contatore. Anche Vaultaire utilizza AES-GCM per indici di vault, intestazioni di file, miniature e buste chiave. L'algoritmo e la dimensione della chiave sono standardizzati; La sicurezza di Vaultaire dipende ancora dalla gestione del nonce, dalla gestione delle chiavi, dalla forza delle credenziali e dalla correttezza dell’implementazione.

“256” in AES-256 si riferisce alla lunghezza della chiave in bit. Una chiave a 256 bit ne ha 2²⁵⁶ valori possibili. Per mettere quel numero in prospettiva: ce ne sono circa 10⁸⁰ atomi nell’universo osservabile. Se ogni atomo fosse un supercomputer che testa un miliardo di chiavi al secondo, in funzione dal Big Bang, avrebbero esplorato meno di un trilionesimo di trilionesimo dell’uno per cento dello spazio delle chiavi. AES-256 non verrà sottoposto a forza bruta. Non oggi. Non in questo secolo. Non prima che le stelle si spengano.

Perché la modalità GCM è importante

AES è un codice a blocchi, che crittografa i dati in blocchi da 128 bit. “mode” determina il modo in cui questi blocchi vengono combinati. GCM (Galois/Counter Mode) fornisce due cose che le modalità più semplici come CBC non forniscono: crittografia parallelizzata e autenticazione integrata.

L'elemento di autenticazione è fondamentale. GCM genera un tag crittografico per ogni file crittografato. Questo tag funge da sigillo anti-manomissione. Se anche un solo bit del testo cifrato viene modificato, da un attore malintenzionato o da un settore del disco danneggiato, il tag di autenticazione non corrisponderà e la decrittografia fallirà. Non ottieni dati danneggiati. Ricevi un chiaro segnale che qualcosa non va. Questa proprietà è chiamata crittografia autenticata e impedisce un'intera classe di attacchi in cui un avversario modifica i dati crittografati per manipolare l'output decrittografato.

PBKDF2: derivazione chiave

Vaultaire ricava chiavi diverse per lavori diversi. Il modello e un dispositivo a livello Keychain mangime salato PBKDF2-HMAC-SHA512 per 600.000 iterazioni per produrre la chiave dell'insieme di credenziali locale. Una derivazione di modello deterministico produce la chiave di backup cloud separata. La frase di recupero normalizzata arriva fino a 800.000 PBKDF2 iterazioni per produrre la chiave per una busta di ripristino. Nessuna di queste derivazioni trasforma una credenziale umana in 256 bit di entropia semplicemente perché l'output è lungo 256 bit.

Come PBKDF2 protegge il tuo modello

L'idea centrale dietro PBKDF2 è un lavoro intenzionale. Prende il modello serializzato o la frase normalizzata e ne esegue centinaia di migliaia HMAC-SHA512 iterazioni. Un utente legittimo paga tale costo una volta durante un tentativo di sblocco o ripristino. Un utente malintenzionato paga per ogni candidato, sebbene le scelte parallele di hardware e implementazione determinino il reale tasso di ipotesi.

Vaultaire configura PBKDF2 con 600.000 iterazioni per chiavi derivate da pattern. Ciò rende ogni ipotesi più costosa, ma una stima di attacco responsabile deve indicare un tempo misurato per candidato e ipotesi hardware. Con esattamente 1 ms per candidato, 1.000.000.000 di tentativi seriali richiedono circa 11,6 giorni, non anni. Il risultato a 256 bit non espande l'entropia di un modello prevedibile.

La derivazione del modello locale utilizza un sale crittograficamente casuale per il dispositivo, archiviato come WhenUnlockedThisDeviceOnly Keychain elemento. Il sale non è segreto ed è condiviso dalle casseforti su quel dispositivo. Impedisce che una tabella creata per un dispositivo venga applicata direttamente a un altro dispositivo con un sale diverso, ma non obbliga un utente malintenzionato a ricominciare da capo per ogni insieme di credenziali sullo stesso dispositivo.

AES-256-GCM: Protezione dei metadati

La crittografia del contenuto del file non è sufficiente. I nomi dei file, le date di creazione, le dimensioni delle miniature e la struttura del vault sono tutti metadati, e i metadati possono essere altrettanto rivelatori quanto i dati stessi. Un file denominato “tax-return-2025.pdf” dice a un utente malintenzionato esattamente cosa c'è dentro, anche se i contenuti sono crittografati. Un timestamp mostra quando hai utilizzato il vault. La dimensione di una miniatura rivela se qualcosa è una foto o un video.

Vaultaire protegge questi metadati con AES-256-GCM, non ChaCha20. Nomi dei file e MIME i tipi sono codificati in intestazioni di file crittografate. L'indice del deposito crittografato contiene record di file, date, informazioni sulle dimensioni, layout di archiviazione e la chiave principale incapsulata. Anche i dati delle miniature vengono crittografati con la chiave principale casuale.

Perché la crittografia autenticata per i metadati?

I metadati necessitano di integrità e riservatezza. AES-GCM produce un tag di autenticazione per ciascun valore crittografato, in modo che Vaultaire possa rifiutare un'intestazione, un indice, una miniatura o una busta modificati invece di accettare testo in chiaro controllato dall'aggressore. Il progetto utilizza deliberatamente una costruzione di crittografia autenticata in questi formati di archiviazione piuttosto che rivendicare la diversità crittografica che l'implementazione non fornisce.

Lo stesso codice non significa che la stessa chiave o il nonce vengono riutilizzati alla cieca. La chiave dell'insieme di credenziali protegge l'indice e avvolge la chiave master casuale; la chiave principale protegge il materiale del file. CryptoKit crea scatole sigillate autenticate con nuovi nonce, mentre il formato di streaming di Vaultaire deriva un nonce distinto per ogni blocco ordinato. Le garanzie rilevanti provengono dalla separazione delle chiavi, dalla disciplina del nonce e dall'autenticazione, non da una seconda cifratura dei metadati.

Architettura a conoscenza zero

Ecco una domanda che vale la pena porsi riguardo a qualsiasi app di sicurezza: cosa succede se l'azienda dietro di essa viene hackerata, citata in giudizio o semplicemente diventa dannosa?

Con la maggior parte delle app, la risposta è scomoda. Contengono i tuoi dati, le tue chiavi o entrambi. Un ordine del tribunale li obbliga a consegnarlo. Una violazione dei dati lo espone. Un dipendente disonesto vi accede. La sicurezza dell'app’ è forte quanto la sicurezza operativa dell'azienda’, e la storia dimostra che le aziende vengono regolarmente violate.

Vaultaire non gestisce un account o un servizio di archiviazione che riceva la sequenza, la frase segreta, le chiavi di decrittazione o i contenuti leggibili del vault. La crittografia e la decrittografia avvengono durante il processo dell'app sul tuo dispositivo. Quando iCloud il backup è abilitato, l'app invia testo cifrato autenticato al tuo privato CloudKit database anziché a un servizio di deposito controllato da Vaultaire.

Cosa significa conoscenza zero nella pratica

Se un'agenzia delle forze dell'ordine notifica a Vaultaire un mandato di comparizione richiedendo testo in chiaro, la società non detiene il modello, la frase di recupero, la chiave del vault, la chiave di backup o la chiave principale necessari per decrittografarlo. Crittografato iCloud i record risiedono in quello dell'utente CloudKit banca dati privata. Sul dispositivo, tuttavia, il materiale di recupero è conservato in modo crittografato Keychain database e le chiavi simmetriche esistono nella memoria dell'app mentre CryptoKit crittografa o decrittografa un deposito aperto.

Questo limite del provider è una proprietà architetturale, non una promessa che ogni parte dell'ambiente client sia esterna al modello di attendibilità. Vaultaire non possiede una chiave di decrittazione lato server da poter cedere per il ripristino di routine del vault. L'app spedita, iOS, il dispositivo sbloccato e l'implementazione crittografica possono ancora elaborare dati leggibili e devono essere considerati attendibili di conseguenza.

Keychain e il confine del processo app

Quello di Apple Secure Enclave può proteggere le chiavi private supportate e partecipa a parti dell'architettura di sicurezza della piattaforma, ma le sue API pubbliche non accettano un arbitrario PBKDF2-chiave simmetrica derivata ed eseguire quella di Vaultaire AES-GCM operazioni sui file all'interno del coprocessore. Vaultaire quindi non descrive il suo codice vault come Secure Enclave AES.

Vaultaire usa l'ordinario iOS Keychain elementi password generica per il salt del dispositivo casuale, il database di ripristino crittografato e la chiave casuale che protegge tale database. Questi elementi utilizzano la classe di accessibilità WhenUnlockedThisDeviceOnly. Keychain e la protezione dei dati creano un confine significativo del dispositivo, soprattutto quando il telefono è bloccato, ma questa architettura è diversa da quella non esportabile Secure Enclave chiave.

Quando disegni il modello, CommonCrypto deriva la chiave dell'insieme di credenziali nel processo dell'app. CryptoKit e CryptoEngine di Vaultaire utilizzano quindi byte di chiave simmetrica in quel processo per autenticare e decrittografare l'indice, scartare la chiave principale ed elaborare i file. L'app cancella lo stato attivo quando si blocca, ma un utente malintenzionato con privilegi sufficienti che osserva una sessione sbloccata ha un'opportunità diversa rispetto a un esaminatore che detiene solo il testo cifrato del dispositivo bloccato.

Un sistema operativo sottoposto a jailbreak o altrimenti compromesso può prendere di mira l'input di pattern, la memoria dell'app, le anteprime decrittografate, le esportazioni o lo schermo. Vaultaire consiglia un sistema attuale, senza jailbreak iPhone perché il design si basa su iOS isolamento del processo, Keychaine protezione dei dati. Non afferma che la compromissione del root lasci inaccessibili le chiavi simmetriche di un vault aperto.

Vettori di inizializzazione per file

Quando si crittografano due file identici con la stessa chiave, un'implementazione ingenua produrrebbe un testo cifrato identico. Questo è un problema. Un utente malintenzionato che vede due BLOB crittografati identici sa, senza decrittografare nulla, che i due file originali sono uguali. In un archivio pieno di foto, questo tipo di analisi dei modelli può rivelare informazioni anche attraverso la crittografia.

Vaultaire impedisce il testo cifrato deterministico generando un nuovo nonce crittografico per ciascuno AES-256-GCM operazione di sigillatura. Le intestazioni e il contenuto dei file sono sigillati separatamente e i file di grandi dimensioni utilizzano un formato di streaming autenticato con un nonce di base casuale e un nonce distinto per ogni blocco ordinato. Due copie della stessa foto quindi non producono la stessa rappresentazione crittografata.

I nonce vengono memorizzati con il testo cifrato e non sono segreti; il loro requisito di sicurezza è l'unicità sotto una determinata chiave. Vaultaire richiede nonce a 96 bit dal generatore casuale crittografico di Apple per la crittografia single-shot e registra il nonce di base nell'intestazione dello streaming. Il rischio di collisione è governato dal numero di crittografie sotto una chiave, quindi l'implementazione genera un nuovo valore anziché presentare la dimensione a 96 bit come uno su 2 fisso⁹⁶ garanzia a vita.

Gestione della memoria: cancellazione dello stato della chiave attiva

Un errore comune nel software di sicurezza è il lasciare i dati sensibili in memoria dopo che non sono più necessari. Chiavi di crittografia, password derivate e dati decrittografati possono persistere nella RAM molto tempo dopo che l'app ha finito di utilizzarli. Gli strumenti forensi possono eseguire il dump della memoria del dispositivo e cercare questi residui, una tecnica nota come attacco di avvio a freddo o analisi del dump della memoria.

Vaultaire limita la durata della disponibilità dello stato della chiave attiva e dei dati dell'interfaccia utente decrittografati. Quando l'app si blocca o la sessione viene interrotta, il suo codice segue diversi percorsi di pulizia:

• Lo stato del vault attivo viene abbandonato. L'app rimuove la sessione corrente della chiave dell'archivio e richiede un altro sblocco prima di presentare il contenuto dell'archivio.
• I wrapper chiave cancellano i buffer di proprietà. I contenitori di byte sicuri di Vaultaire sovrascrivono i buffer di loro proprietà quando tali contenitori vengono deallocati.
• Lo stato della chiave master memorizzata nella cache è invalidato. La chiave master decrittografata conservata per l'indice aperto viene eliminata nei relativi percorsi di blocco e reimpostazione della cache.
• Le cache dell'interfaccia utente decrittografate vengono cancellate dove controllate da Vaultaire. La pulizia delle miniature e delle anteprime riduce lo stato residuo dell'applicazione, senza rivendicare il controllo su ogni copia effettuata da Swift, iOSo un altro processo.

La prossima volta che Vaultaire si apre in uno stato bloccato, disegni lo schema e l'app ricava nuovamente la chiave del vault prima di poter autenticare l'indice e scartare la chiave principale. Si tratta di una pulizia della sessione, non di un'affermazione secondo cui ogni copia transitoria della memoria ha ricevuto una cancellazione multi-passaggio dimostrabile o che a Secure Enclave il riferimento chiave è stato distrutto. Causa un incidente iOS per recuperare il processo, ma il codice di pulizia non può essere eseguito dopo ogni interruzione improvvisa.