Architettura di Sicurezza: lo stack tecnico completo

Vaultaire usa AES-256-GCM per la cifratura autenticata di indici delle casseforti, chiavi incapsulate, intestazioni dei file, contenuti, miniature e metadati. PBKDF2-HMAC-SHA512 deriva una chiave locale della cassaforte dalla sequenza e da un salt a livello di dispositivo conservato nel Keychain. La chiave della cassaforte incapsula una chiave master casuale separata a 256 bit, che cifra i file con CryptoKit nel processo dell'app.

Lo stack crittografico

Vaultaire usa diversi meccanismi crittografici che lavorano insieme, ciascuno scelto per un compito preciso. PBKDF2 trasforma una credenziale umana in una chiave della cassaforte o di ripristino. AES-256-GCM protegge indici, involucri delle chiavi, metadati, miniature e contenuto dei file. Una chiave master casuale separa la cifratura a lungo termine dei file da una sequenza che si può cambiare. Il Keychain e la protezione dei dati di iOS proteggono il salt e i record di ripristino legati al dispositivo mentre il dispositivo è bloccato. Nessuna chiave di decifratura in mano al fornitore dà allo sviluppatore un accesso di routine ai contenuti in chiaro della cassaforte.

Non è complessità fine a se stessa. Ogni livello affronta una superficie di attacco diversa. AES-256-GCM unisce riservatezza e autenticazione, quindi un testo cifrato modificato non supera la verifica. PBKDF2 aumenta il costo di ogni tentativo su sequenze o frasi. Grazie alla chiave master casuale, cambiare la sequenza richiede solo di incapsulare di nuovo una chiave invece di cifrare di nuovo ogni file. La protezione dei dati del Keychain protegge il salt e i record di ripristino locali, mentre l'app riconosce che la cifratura simmetrica avviene comunque nella memoria del processo.

Insieme, questi livelli formano un'architettura di difesa in profondità, ma non sono tutti barriere indipendenti. Una sequenza indovinata si può verificare con il nome del file di indice e con l'autenticazione AES-GCM, e un dispositivo sbloccato e compromesso può osservare chiavi o contenuti in chiaro nel processo dell'app. L'architettura dipende quindi dall'entropia delle credenziali, dal costo di PBKDF2, dalla protezione del dispositivo iOS e dalla corretta gestione della cifratura autenticata, oltre che dalla robustezza di AES.

AES-256-GCM: crittografia file

Ogni foto, video e documento salvato in Vaultaire è cifrato con AES-256-GCM, cioè l'Advanced Encryption Standard con chiave a 256 bit in modalità Galois/Counter. Vaultaire usa AES-GCM anche per gli indici delle casseforti, le intestazioni dei file, le miniature e le buste delle chiavi. L'algoritmo e la dimensione della chiave sono standard; la sicurezza di Vaultaire dipende comunque dalla gestione dei nonce, dalla gestione delle chiavi, dalla robustezza 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 deriva chiavi diverse per compiti diversi. La sequenza e un salt del Keychain a livello di dispositivo alimentano PBKDF2-HMAC-SHA512 per 600.000 iterazioni e producono la chiave locale della cassaforte. Una derivazione deterministica dalla sequenza produce la chiave di backup cloud separata. La frase di ripristino normalizzata passa per un massimo di 800.000 iterazioni di PBKDF2 e produce la chiave di una busta di ripristino. Nessuna di queste derivazioni trasforma una credenziale umana in 256 bit di entropia solo perché l'output è lungo 256 bit.

Come PBKDF2 protegge il tuo modello

L'idea centrale di PBKDF2 è un lavoro voluto. Prende la sequenza serializzata o la frase normalizzata e la sottopone a centinaia di migliaia di iterazioni HMAC-SHA512. Un utente legittimo paga questo costo una volta per ogni tentativo di sblocco o ripristino. Un attaccante lo paga per ogni candidato, anche se l'hardware parallelo e le scelte di implementazione determinano il ritmo reale dei tentativi.

Vaultaire configura PBKDF2 con 600.000 iterazioni per le chiavi derivate dalla sequenza. Questo rende ogni tentativo più costoso, ma una stima seria di un attacco deve indicare un tempo misurato per candidato e le ipotesi sull'hardware. Con esattamente 1 ms per candidato, 1.000.000.000 di tentativi in serie richiedono circa 11,6 giorni, non anni. L'output a 256 bit non aumenta l'entropia di una sequenza prevedibile.

La derivazione locale dalla sequenza usa un salt casuale crittograficamente sicuro per ogni dispositivo, conservato come elemento del Keychain WhenUnlockedThisDeviceOnly. Il salt non è segreto ed è condiviso da tutte le casseforti di quel dispositivo. Impedisce che una tabella costruita per un dispositivo si applichi direttamente a un altro dispositivo con un salt diverso, ma non obbliga un attaccante a ricominciare da capo per ogni cassaforte 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 della cassaforte 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 la cassaforte. La dimensione di una miniatura rivela se qualcosa è una foto o un video.

Vaultaire protegge questi metadati con AES-256-GCM, non con ChaCha20. Nomi dei file e tipi MIME sono codificati in intestazioni di file cifrate. L'indice cifrato della cassaforte contiene i record dei file, le date, le dimensioni, la disposizione dello storage e la chiave master incapsulata. Anche i dati delle miniature sono cifrati con la chiave master casuale.

Perché la cifratura autenticata per i metadati?

I metadati richiedono sia integrità sia riservatezza. AES-GCM produce un tag di autenticazione per ogni valore cifrato, così Vaultaire può rifiutare un'intestazione, un indice, una miniatura o una busta modificati invece di accettare dati in chiaro controllati da un attaccante. Il progetto usa di proposito un'unica costruzione di cifratura autenticata in questi formati di storage, invece di vantare una diversità crittografica che l'implementazione non offre.

Lo stesso cifrario non significa riusare alla cieca la stessa chiave o lo stesso nonce. La chiave della cassaforte protegge l'indice e incapsula la chiave master casuale; la chiave master protegge i file. CryptoKit crea sealed box autenticate con nonce nuovi, mentre il formato di streaming di Vaultaire deriva un nonce distinto per ogni blocco ordinato. Le garanzie che contano vengono dalla separazione delle chiavi, dalla disciplina sui 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 né un servizio di storage che riceva la sequenza, la frase segreta, le chiavi di decifratura o i contenuti leggibili della cassaforte. Cifratura e decifratura avvengono nel processo dell'app sul tuo dispositivo. Quando il backup iCloud è attivo, l'app invia testo cifrato autenticato al tuo database CloudKit privato invece che a un servizio di deposito controllato da Vaultaire.

Cosa significa conoscenza zero nella pratica

Se un'autorità notifica a Vaultaire un ordine che chiede i dati in chiaro, l'azienda non possiede la sequenza, la frase di ripristino, la chiave della cassaforte, la chiave di backup né la chiave master necessarie per decifrarli. I record iCloud cifrati risiedono nel database CloudKit privato dell'utente. Sul dispositivo, però, il materiale di ripristino è conservato in un database cifrato nel Keychain, e le chiavi simmetriche esistono nella memoria dell'app mentre CryptoKit cifra o decifra una cassaforte aperta.

Questo limite del fornitore è una proprietà dell'architettura, non la promessa che ogni parte dell'ambiente client sia fuori dal modello di fiducia. Vaultaire non possiede una chiave di decifratura lato server da consegnare per il ripristino ordinario di una cassaforte. L'app distribuita, iOS, il dispositivo sbloccato e l'implementazione crittografica possono comunque elaborare dati leggibili e vanno considerati parte della fiducia.

Il Keychain e il confine del processo dell'app

Il Secure Enclave di Apple può proteggere le chiavi private supportate e partecipa ad alcune parti dell'architettura di sicurezza della piattaforma, ma le sue API pubbliche non accettano una chiave simmetrica arbitraria derivata con PBKDF2 per eseguire le operazioni AES-GCM di Vaultaire sui file all'interno del coprocessore. Per questo Vaultaire non descrive il codice della cassaforte come AES nel Secure Enclave.

Vaultaire usa normali elementi password generici del Keychain di iOS per il salt casuale del dispositivo, per il database di ripristino cifrato e per la chiave casuale che protegge quel database. Questi elementi usano la classe di accessibilità WhenUnlockedThisDeviceOnly. Il Keychain e la protezione dei dati creano un confine importante sul dispositivo, soprattutto quando il telefono è bloccato, ma questa architettura è diversa da una chiave non esportabile del Secure Enclave.

Quando disegni la sequenza, CommonCrypto deriva la chiave della cassaforte nel processo dell'app. CryptoKit e il CryptoEngine di Vaultaire usano poi i byte delle chiavi simmetriche in quel processo per autenticare e decifrare l'indice, sbloccare la chiave master ed elaborare i file. L'app cancella lo stato attivo quando si blocca, ma un attaccante con privilegi sufficienti che osserva una sessione sbloccata ha possibilità diverse rispetto a un esaminatore che ha solo il testo cifrato di un dispositivo bloccato.

Un sistema operativo con jailbreak o comunque compromesso può colpire l'inserimento della sequenza, la memoria dell'app, le anteprime decifrate, le esportazioni o lo schermo. Vaultaire consiglia un iPhone aggiornato e senza jailbreak, perché il progetto si basa sull'isolamento dei processi di iOS, sul Keychain e sulla protezione dei dati. Non afferma che una compromissione a livello root lasci inaccessibili le chiavi simmetriche di una cassaforte aperta.

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 evita il testo cifrato deterministico generando un nuovo nonce crittografico per ogni operazione di sigillatura AES-256-GCM. Intestazioni e contenuti dei file sono sigillati separatamente, e i file grandi usano un formato di streaming autenticato con un nonce di base casuale e un nonce distinto per ogni blocco ordinato. Due copie della stessa foto non producono quindi la stessa rappresentazione cifrata.

I nonce sono salvati insieme al testo cifrato e non sono segreti; il loro requisito di sicurezza è l'unicità per una data chiave. Vaultaire chiede nonce a 96 bit al generatore casuale crittografico di Apple per la cifratura in un solo passaggio e registra il nonce di base nell'intestazione dello streaming. Il rischio di collisione dipende dal numero di cifrature con la stessa chiave, quindi l'implementazione genera un valore nuovo invece di presentare la dimensione a 96 bit come una garanzia fissa di una probabilità su 2⁹⁶ per sempre.

Gestione della memoria: cancellazione dello stato delle chiavi attive

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 per quanto tempo restano disponibili lo stato delle chiavi attive e i dati decifrati dell'interfaccia. Quando l'app si blocca o la sessione si interrompe, il suo codice segue diversi percorsi di pulizia:

• Lo stato della cassaforte attiva viene abbandonato. L'app rimuove la sessione corrente della chiave della cassaforte e richiede un nuovo sblocco prima di mostrarne il contenuto.
• I contenitori delle chiavi azzerano i propri buffer. I contenitori di byte sicuri di Vaultaire sovrascrivono i buffer che possiedono quando vengono deallocati.
• Lo stato della chiave master in cache viene invalidato. La chiave master decifrata tenuta per l'indice aperto viene eliminata nei percorsi di blocco e di reset della cache.
• Le cache decifrate dell'interfaccia vengono svuotate dove Vaultaire le controlla. La pulizia di miniature e anteprime riduce lo stato residuo dell'app, senza pretendere di controllare ogni copia fatta da Swift, da iOS o da un altro processo.

Alla successiva apertura, Vaultaire parte bloccato: disegni la sequenza e l'app deriva di nuovo la chiave della cassaforte prima di autenticare l'indice e sbloccare la chiave master. Si tratta di una pulizia della sessione, non dell'affermazione che ogni copia temporanea in memoria abbia subito una cancellazione a più passaggi dimostrabile, né che un riferimento a una chiave del Secure Enclave sia stato distrutto. Un crash porta iOS a recuperare il processo, ma il codice di pulizia non può girare dopo ogni interruzione improvvisa.