Arquitectura de seguretat: La base tècnica completa

Vaultaire fa servir AES-256-GCM per al xifratge autenticat dels índexs de les caixes fortes, les claus embolcallades, les capçaleres dels fitxers, el contingut, les miniatures i les metadades. PBKDF2-HMAC-SHA512 deriva una clau local de la caixa forta a partir del patró i d’una sal del Clauer comuna a tot el dispositiu. Aquesta clau de la caixa forta embolcalla una clau mestra aleatòria de 256 bits independent, que fa el xifratge dels fitxers amb CryptoKit dins del procés de l’app.

La base criptogràfica

Vaultaire fa servir diversos mecanismes criptogràfics que treballen junts, cadascun triat per a una feina concreta. PBKDF2 converteix una credencial humana en una clau de caixa forta o de recuperació. AES-256-GCM protegeix els índexs, els embolcalls, les metadades, les miniatures i el contingut dels fitxers. Una clau mestra aleatòria separa el xifratge dels fitxers, que dura molt, d’un patró que es pot canviar. El Clauer i la Protecció de dades d’iOS protegeixen la sal lligada al dispositiu i els registres de recuperació mentre el dispositiu és bloquejat. Cap clau de desxifratge en mans del proveïdor dona al desenvolupador accés habitual al text pla de la caixa forta.

No és complexitat per la complexitat. Cada capa cobreix una superfície d’atac diferent. AES-256-GCM combina confidencialitat i autenticació, així que el text xifrat modificat no supera la verificació. PBKDF2 encareix la prova de cada patró o frase. La clau mestra aleatòria fa que un canvi de patró pugui tornar a embolcallar una sola clau en lloc de tornar a xifrar tots els fitxers. La protecció de dades del Clauer protegeix la sal local i els registres de recuperació, tot i que l’app reconeix que el xifratge simètric passa a la memòria del procés.

Juntes, aquestes capes formen una arquitectura de defensa en profunditat, però no totes són barreres independents. Un patró endevinat es pot comprovar amb el nom del fitxer d’índex i l’autenticació AES-GCM, i un dispositiu desbloquejat i compromès pot observar claus o text pla al procés de l’app. Per tant, l’arquitectura depèn de l’entropia de la credencial, del cost de PBKDF2, de la protecció del dispositiu iOS i d’una gestió correcta del xifratge autenticat, a més de la robustesa del mateix AES.

AES-256-GCM: Xifratge de fitxers

Cada foto, vídeo i document que guardes a Vaultaire es xifra amb AES-256-GCM: l’Advanced Encryption Standard amb una clau de 256 bits en mode Galois/Counter. Vaultaire també fa servir AES-GCM per als índexs de les caixes fortes, les capçaleres dels fitxers, les miniatures i els sobres de claus. L’algorisme i la mida de la clau estan estandarditzats; la seguretat de Vaultaire continua depenent de la gestió dels nonces, la gestió de les claus, la robustesa de la credencial i la correcció de la implementació.

El “256” d’AES-256 és la longitud de la clau en bits. Una clau de 256 bits té 2²⁵⁶ valors possibles. Per posar aquest nombre en context: hi ha aproximadament 10⁸⁰ àtoms a l’univers observable. Si cada àtom fos un superordinador que provés mil milions de claus per segon des del Big Bang, haurien explorat menys d’una bilionèsima d’una bilionèsima de l’u per cent de l’espai de claus. AES-256 no caurà per força bruta. Ni avui. Ni aquest segle. Ni abans que s’apaguin les estrelles.

Per què importa el mode GCM

AES és un xifratge de blocs: xifra les dades en fragments de 128 bits. El “mode” determina com es combinen aquests fragments. GCM (Galois/Counter Mode) ofereix dues coses que modes més simples com CBC no ofereixen: xifratge en paral·lel i autenticació integrada.

L’autenticació és la part clau. GCM genera una etiqueta criptogràfica per a cada fitxer xifrat. Aquesta etiqueta fa de precinte contra manipulacions. Si es modifica encara que sigui un sol bit del text xifrat, sigui per un actor maliciós o per un sector de disc corromput, l’etiqueta d’autenticació no coincidirà i el desxifratge fallarà. No obtens dades corrompudes. Obtens un senyal clar que alguna cosa va malament. Aquesta propietat s’anomena xifratge autenticat, i evita tota una classe d’atacs en què un adversari modifica dades xifrades per manipular la sortida desxifrada.

PBKDF2: Derivació de claus

Vaultaire deriva claus diferents per a feines diferents. El patró i una sal del Clauer comuna a tot el dispositiu alimenten PBKDF2-HMAC-SHA512 durant 600.000 iteracions per produir la clau local de la caixa forta. Una derivació determinista del patró produeix la clau independent de la còpia de seguretat al núvol. La frase de recuperació normalitzada passa per 800.000 iteracions de PBKDF2 per produir la clau d’un sobre de recuperació. Cap d’aquestes derivacions converteix una credencial humana en 256 bits d’entropia només perquè la sortida fa 256 bits.

Com protegeix PBKDF2 el teu patró

La idea central de PBKDF2 és la feina deliberada. Agafa el patró serialitzat o la frase normalitzada i executa centenars de milers d’iteracions d’HMAC-SHA512. Un usuari legítim paga aquest cost una vegada per cada intent de desbloqueig o de recuperació. Un atacant el paga per cada candidat, tot i que el maquinari en paral·lel i les decisions d’implementació determinen el ritme real d’intents.

Vaultaire configura PBKDF2 amb 600.000 iteracions per a les claus derivades del patró. Això encareix cada intent, però una estimació d’atac responsable ha d’indicar un temps mesurat per candidat i les hipòtesis de maquinari. A exactament un mil·lisegon per candidat, mil milions d’intents en sèrie triguen uns 11,6 dies, no anys. El resultat de 256 bits no amplia l’entropia d’un patró previsible.

La derivació local del patró fa servir una sal criptogràficament aleatòria per al dispositiu, guardada com a element del Clauer WhenUnlockedThisDeviceOnly. La sal no és secreta i la comparteixen les caixes fortes d’aquell dispositiu. Evita que una taula construïda per a un dispositiu s’apliqui directament a un altre dispositiu amb una sal diferent, però no obliga un atacant a començar de zero per a cada caixa forta del mateix dispositiu.

AES-256-GCM: Protecció de metadades

Xifrar el contingut dels fitxers no n’hi ha prou. Els noms de fitxer, les dates de creació, les dimensions de les miniatures i l’estructura de la caixa forta són metadades, i les metadades poden revelar tant com les mateixes dades. Un fitxer anomenat “tax-return-2025.pdf” diu a un atacant exactament què hi ha a dins encara que el contingut estigui xifrat. Una marca de temps mostra quan has fet servir la caixa forta. La mida d’una miniatura revela si una cosa és una foto o un vídeo.

Vaultaire protegeix aquestes metadades amb AES-256-GCM, no amb ChaCha20. Els noms de fitxer i els tipus MIME es codifiquen dins de capçaleres de fitxer xifrades. L’índex xifrat de la caixa forta conté els registres dels fitxers, les dates, la informació de mida, l’organització de l’emmagatzematge i la clau mestra embolcallada. Les dades de les miniatures també es xifren amb la clau mestra aleatòria.

Per què xifratge autenticat per a les metadades?

Les metadades necessiten integritat a més de confidencialitat. AES-GCM produeix una etiqueta d’autenticació per a cada valor xifrat, així que Vaultaire pot rebutjar una capçalera, un índex, una miniatura o un sobre modificats en lloc d’acceptar text pla controlat per un atacant. El disseny fa servir expressament una sola construcció de xifratge autenticat en tots aquests formats d’emmagatzematge, en lloc de presumir d’una diversitat criptogràfica que la implementació no ofereix.

El mateix xifratge no vol dir que es reutilitzin a cegues la mateixa clau o el mateix nonce. La clau de la caixa forta protegeix l’índex i embolcalla la clau mestra aleatòria; la clau mestra protegeix el material dels fitxers. CryptoKit crea capses segellades autenticades amb nonces nous, mentre que el format de transmissió de Vaultaire deriva un nonce diferent per a cada fragment ordenat. Les garanties que compten venen de la separació de claus, la disciplina amb els nonces i l’autenticació, no d’un segon xifratge per a les metadades.

Arquitectura de coneixement zero

Aquesta és una pregunta que val la pena fer sobre qualsevol app de seguretat: què passa si l’empresa que hi ha darrere pateix un atac, rep una ordre judicial o simplement actua de mala fe?

Amb la majoria d’apps, la resposta és incòmoda. Tenen les teves dades, les teves claus o totes dues coses. Una ordre judicial les obliga a lliurar-les. Una filtració de dades les exposa. Un empleat deslleial hi accedeix. La seguretat de l’app només és tan forta com la seguretat operativa de l’empresa, i la història mostra que les empreses pateixen filtracions sovint.

Vaultaire no gestiona cap servei de comptes ni d’emmagatzematge que rebi el teu patró, la teva frase secreta, les claus de desxifratge o el contingut llegible de la caixa forta. El xifratge i el desxifratge passen al procés de l’app, al teu dispositiu. Quan la còpia de seguretat d’iCloud està activada, l’app envia text xifrat autenticat a la teva base de dades privada de CloudKit, no a un servei de caixes fortes controlat per Vaultaire.

Què vol dir coneixement zero a la pràctica

Si un cos policial lliura a Vaultaire una ordre judicial que exigeix el text pla d’una caixa forta, l’empresa no té el patró, la frase de recuperació, la clau de la caixa forta, la clau de la còpia de seguretat ni la clau mestra necessaris per desxifrar-lo. Els registres xifrats d’iCloud són a la base de dades privada de CloudKit de l’usuari. Al dispositiu, en canvi, el material de recuperació es guarda en una base de dades xifrada del Clauer, i les claus simètriques són a la memòria de l’app mentre CryptoKit xifra o desxifra una caixa forta oberta.

Aquest límit del proveïdor és una propietat de l’arquitectura, no una promesa que cada part de l’entorn del client quedi fora del model de confiança. Vaultaire no té cap clau de desxifratge al servidor que pugui lliurar per a una recuperació habitual de caixes fortes. L’app publicada, iOS, el dispositiu desbloquejat i la implementació criptogràfica encara poden processar dades llegibles, i cal confiar-hi en conseqüència.

El Clauer i el límit del procés de l’app

El Secure Enclave d’Apple pot protegir les claus privades compatibles i participa en parts de l’arquitectura de seguretat de la plataforma, però les seves API públiques no accepten una clau simètrica qualsevol derivada amb PBKDF2 per fer les operacions de fitxer AES-GCM de Vaultaire dins del coprocessador. Per això Vaultaire no descriu el xifratge de la seva caixa forta com a AES del Secure Enclave.

Vaultaire fa servir elements normals de contrasenya genèrica del Clauer d’iOS per a la sal aleatòria del dispositiu, la base de dades de recuperació xifrada i la clau aleatòria que protegeix aquesta base de dades. Aquests elements fan servir la classe d’accessibilitat WhenUnlockedThisDeviceOnly. El Clauer i la Protecció de dades creen un límit del dispositiu significatiu, sobretot mentre el telèfon és bloquejat, però aquesta arquitectura és diferent d’una clau del Secure Enclave no exportable.

Quan dibuixes el patró, CommonCrypto deriva la clau de la caixa forta dins del procés de l’app. Després, CryptoKit i el CryptoEngine de Vaultaire fan servir els bytes de la clau simètrica en aquest procés per autenticar i desxifrar l’índex, desembolcallar la clau mestra i processar els fitxers. L’app esborra l’estat actiu quan es bloqueja, però un atacant amb prou privilegis que observi una sessió desbloquejada té una oportunitat diferent de la d’un examinador que només té el text xifrat d’un dispositiu bloquejat.

Un sistema operatiu amb jailbreak o compromès d’una altra manera pot atacar l’entrada del patró, la memòria de l’app, les previsualitzacions desxifrades, les exportacions o la pantalla. Vaultaire recomana un iPhone actualitzat i sense jailbreak perquè el disseny es basa en l’aïllament de processos d’iOS, el Clauer i la Protecció de dades. No afirma que un compromís a nivell root deixi inaccessibles les claus simètriques d’una caixa forta oberta.

Vectors d’inicialització per fitxer

Quan xifres dos fitxers idèntics amb la mateixa clau, una implementació ingènua produiria text xifrat idèntic. Això és un problema. Un atacant que veu dos blocs xifrats idèntics sap, sense desxifrar res, que els dos fitxers originals són iguals. En una caixa forta plena de fotos, aquest tipus d’anàlisi de patrons pot revelar informació fins i tot a través del xifratge.

Vaultaire evita el text xifrat determinista generant un nonce criptogràfic nou per a cada operació de segellat AES-256-GCM. Les capçaleres i el contingut dels fitxers se segellen per separat, i els fitxers grans fan servir un format de transmissió autenticat amb un nonce base aleatori i un nonce diferent per a cada fragment ordenat. Per tant, dues còpies de la mateixa foto no produeixen la mateixa representació xifrada.

Els nonces es guarden amb el text xifrat i no són secrets; el seu requisit de seguretat és ser únics per a una clau donada. Vaultaire demana nonces de 96 bits al generador aleatori criptogràfic d’Apple per al xifratge d’una sola passada i registra el nonce base a la capçalera de transmissió. El risc de col·lisió depèn del nombre de xifratges amb una mateixa clau, així que la implementació genera un valor nou en lloc de presentar la mida de 96 bits com una garantia fixa d’una entre 2⁹⁶ per a tota la vida útil.

Gestió de la memòria: esborrar l’estat actiu de les claus

Un error habitual del programari de seguretat és deixar dades sensibles a la memòria quan ja no calen. Les claus de xifratge, les contrasenyes derivades i les dades desxifrades poden quedar a la RAM molt després que l’app hagi acabat de fer-les servir. Les eines forenses poden bolcar la memòria del dispositiu i buscar-hi aquestes restes, una tècnica coneguda com a atac d’arrencada en fred o anàlisi d’un bolcat de memòria.

Vaultaire limita quant de temps continuen disponibles l’estat actiu de les claus i les dades desxifrades de la interfície. Quan l’app es bloqueja o la sessió es tanca, el seu codi segueix diversos camins de neteja:

• Es descarta l’estat actiu de la caixa forta. L’app elimina la sessió actual de la clau de la caixa forta i demana un altre desbloqueig abans de mostrar-ne el contingut.
• Els contenidors de claus esborren els seus búfers. Els contenidors de bytes segurs de Vaultaire sobreescriuen els búfers que tenen quan aquests contenidors s’alliberen.
• S’invalida l’estat de la clau mestra a la memòria cau. La clau mestra desxifrada que es manté per a l’índex obert es descarta en els camins de bloqueig i de reinici de la memòria cau corresponents.
• S’esborren les memòries cau desxifrades de la interfície que controla Vaultaire. La neteja de miniatures i previsualitzacions redueix l’estat residual de l’app, sense pretendre controlar cada còpia que facin Swift, iOS o un altre procés.

La pròxima vegada que Vaultaire s’obri bloquejat, dibuixes el patró i l’app torna a derivar la clau de la caixa forta abans de poder autenticar l’índex i desembolcallar la clau mestra. Això és neteja de sessió, no una afirmació que cada còpia transitòria a la memòria hagi rebut un esborrat demostrable de diverses passades ni que s’hagi destruït una referència de clau del Secure Enclave. Una fallada fa que iOS recuperi el procés, però el codi de neteja no es pot executar després de cada finalització sobtada.