Arhitectura de securitate: întregul strat tehnic

Vaultaire folosește AES-256-GCM pentru criptare autentificată în indexurile seifurilor, cheile împachetate, anteturile fișierelor, conținut, miniaturi și metadate. PBKDF2-HMAC-SHA512 derivă o cheie de seif locală din model și dintr-o sare Keychain comună dispozitivului. Acea cheie de seif împachetează o cheie principală aleatorie separată, de 256 de biți, care face criptarea fișierelor prin CryptoKit în procesul aplicației.

Stratul criptografic

Vaultaire folosește mai multe mecanisme criptografice care lucrează împreună, fiecare ales pentru un rol precis. PBKDF2 transformă un credențial uman într-o cheie de seif sau de recuperare. AES-256-GCM protejează indexurile, ambalajele cheilor, metadatele, miniaturile și conținutul fișierelor. O cheie principală aleatorie separă criptarea de lungă durată a fișierelor de un model care se poate schimba. Keychain și iOS Data Protection protejează sarea legată de dispozitiv și înregistrările de recuperare cât timp dispozitivul este blocat. Nicio cheie de decriptare deținută de furnizor nu îi dă dezvoltatorului acces obișnuit la conținutul necriptat al seifului.

Nu este complexitate de dragul complexității. Fiecare strat acoperă altă suprafață de atac. AES-256-GCM combină confidențialitatea cu autentificarea, așa că textul cifrat modificat nu trece verificarea. PBKDF2 crește costul testării fiecărui model sau al fiecărei fraze. Cheia principală aleatorie înseamnă că o schimbare de model poate reîmpacheta o singură cheie în loc să recripteze fiecare fișier. Protecția datelor din Keychain păzește sarea locală și înregistrările de recuperare, iar aplicația recunoaște în continuare că criptarea simetrică are loc în memoria procesului.

Împreună, aceste straturi formează o arhitectură de apărare în adâncime, dar nu sunt toate bariere independente. Un model ghicit poate fi verificat față de numele fișierului de index și autentificarea AES-GCM, iar un dispozitiv deblocat compromis poate observa chei sau conținut necriptat în procesul aplicației. De aceea arhitectura depinde de entropia credențialului, de costul PBKDF2, de protecția dispozitivului iOS și de gestionarea corectă a criptării autentificate, pe lângă puterea AES în sine.

AES-256-GCM: criptarea fișierelor

Fiecare poză, videoclip și document stocat în Vaultaire este criptat cu AES-256-GCM — Advanced Encryption Standard cu o cheie de 256 de biți în modul Galois/Counter. Vaultaire folosește AES-GCM și pentru indexurile seifurilor, anteturile fișierelor, miniaturi și plicurile de chei. Algoritmul și dimensiunea cheii sunt standardizate; securitatea Vaultaire depinde totuși de gestionarea nonce-urilor, gestionarea cheilor, puterea credențialelor și corectitudinea implementării.

„256” din AES-256 se referă la lungimea cheii în biți. O cheie de 256 de biți are 2²⁵⁶ valori posibile. Ca să pui numărul în perspectivă: în universul observabil există aproximativ 10⁸⁰ atomi. Dacă fiecare atom ar fi un supercomputer care testează un miliard de chei pe secundă, încă de la Big Bang, ar fi explorat mai puțin de o trilionime dintr-o trilionime dintr-un procent din spațiul cheilor. AES-256 nu va fi spart prin forță brută. Nici azi. Nici în acest secol. Nici înainte să se stingă stelele.

De ce contează modul GCM

AES este un cifru pe blocuri — criptează datele în bucăți de 128 de biți. „Modul” stabilește cum sunt combinate acele bucăți. GCM (Galois/Counter Mode) oferă două lucruri pe care modurile mai simple, precum CBC, nu le oferă: criptare paralelizată și autentificare integrată.

Partea de autentificare este esențială. GCM generează o etichetă criptografică pentru fiecare fișier criptat. Eticheta funcționează ca un sigiliu împotriva modificărilor. Dacă se modifică fie și un singur bit din textul cifrat — de către un atacator sau de un sector de disc corupt — eticheta de autentificare nu se mai potrivește, iar decriptarea eșuează. Nu primești date corupte. Primești un semnal clar că ceva nu este în regulă. Această proprietate se numește criptare autentificată și previne o întreagă clasă de atacuri în care un adversar modifică datele criptate ca să manipuleze rezultatul decriptat.

PBKDF2: derivarea cheilor

Vaultaire derivă chei diferite pentru roluri diferite. Modelul și o sare Keychain comună dispozitivului intră în PBKDF2-HMAC-SHA512 cu 600.000 de iterații pentru a produce cheia de seif locală. O derivare deterministă din model produce cheia separată de backup în cloud. Fraza de recuperare normalizată trece prin 800.000 de iterații PBKDF2 pentru a produce cheia unui plic de recuperare. Niciuna dintre aceste derivări nu transformă un credențial uman în 256 de biți de entropie doar pentru că rezultatul are 256 de biți.

Cum îți protejează PBKDF2 modelul

Ideea de bază din PBKDF2 este efortul deliberat. Ia modelul serializat sau fraza normalizată și rulează sute de mii de iterații HMAC-SHA512. Un utilizator legitim plătește acest cost o singură dată, la o încercare de deblocare sau de recuperare. Un atacator îl plătește pentru fiecare candidat, deși hardware-ul paralel și alegerile de implementare stabilesc rata reală de ghicire.

Vaultaire configurează PBKDF2 cu 600.000 de iterații pentru cheile derivate din model. Asta face fiecare încercare mai scumpă, dar o estimare responsabilă a unui atac trebuie să precizeze un timp măsurat per candidat și ipotezele despre hardware. La exact o milisecundă per candidat, un miliard de încercări în serie durează aproximativ 11,6 zile, nu ani. Rezultatul de 256 de biți nu mărește entropia unui model previzibil.

Derivarea locală din model folosește o singură sare aleatorie criptografic pentru dispozitiv, stocată ca element Keychain WhenUnlockedThisDeviceOnly. Sarea nu este secretă și este comună seifurilor de pe acel dispozitiv. Ea împiedică aplicarea directă a unui tabel construit pentru un dispozitiv pe alt dispozitiv cu altă sare, dar nu obligă un atacator să o ia de la capăt pentru fiecare seif de pe același dispozitiv.

AES-256-GCM: protecția metadatelor

Criptarea conținutului fișierelor nu este suficientă. Numele fișierelor, datele de creare, dimensiunile miniaturilor și structura seifului sunt toate metadate — iar metadatele pot dezvălui la fel de mult ca datele. Un fișier numit „declaratie-fiscala-2025.pdf” îi spune unui atacator exact ce conține, chiar dacă fișierul este criptat. O marcă temporală arată când ai folosit seiful. Dimensiunea unei miniaturi arată dacă ceva este poză sau videoclip.

Vaultaire protejează aceste metadate cu AES-256-GCM, nu cu ChaCha20. Numele fișierelor și tipurile MIME sunt codificate în anteturi de fișier criptate. Indexul criptat al seifului conține înregistrările fișierelor, date, informații despre dimensiuni, organizarea stocării și cheia principală împachetată. Datele miniaturilor sunt și ele criptate cu cheia principală aleatorie.

De ce criptare autentificată pentru metadate?

Metadatele au nevoie de integritate, nu doar de confidențialitate. AES-GCM produce o etichetă de autentificare pentru fiecare valoare criptată, așa că Vaultaire poate respinge un antet, un index, o miniatură sau un plic modificat în loc să accepte conținut controlat de atacator. Designul folosește intenționat o singură construcție de criptare autentificată în toate aceste formate de stocare, în loc să pretindă o diversitate criptografică pe care implementarea nu o oferă.

Același cifru nu înseamnă că aceeași cheie sau același nonce sunt refolosite orbește. Cheia de seif protejează indexul și împachetează cheia principală aleatorie; cheia principală protejează materialul fișierelor. CryptoKit creează containere sigilate autentificate cu nonce-uri noi, iar formatul de streaming Vaultaire derivă un nonce distinct pentru fiecare bucată ordonată. Garanțiile relevante vin din separarea cheilor, disciplina nonce-urilor și autentificare, nu dintr-un al doilea cifru pentru metadate.

Arhitectură zero-knowledge

Iată o întrebare care merită pusă despre orice aplicație de securitate: ce se întâmplă dacă firma din spatele ei este spartă, primește o citație sau pur și simplu devine rău intenționată?

La majoritatea aplicațiilor, răspunsul este incomod. Ele îți dețin datele, cheile sau pe amândouă. O hotărâre judecătorească le obligă să le predea. O breșă de date le expune. Un angajat necinstit le accesează. Securitatea aplicației este doar atât de puternică cât securitatea operațională a firmei — iar istoria arată că firmele sunt sparte în mod regulat.

Vaultaire nu operează un serviciu de cont sau de stocare care să-ți primească modelul, fraza secretă, cheile de decriptare sau conținutul lizibil al seifului. Criptarea și decriptarea au loc în procesul aplicației, pe dispozitivul tău. Când backupul iCloud este activ, aplicația trimite text cifrat autentificat în baza ta de date CloudKit privată, nu unui serviciu de seifuri controlat de Vaultaire.

Ce înseamnă zero-knowledge în practică

Dacă o autoritate de aplicare a legii îi trimite Vaultaire o citație prin care cere conținutul necriptat al seifului, firma nu deține modelul, fraza de recuperare, cheia de seif, cheia de backup sau cheia principală necesare pentru decriptare. Înregistrările iCloud criptate stau în baza de date CloudKit privată a utilizatorului. Pe dispozitiv însă, materialul de recuperare este păstrat într-o bază de date Keychain criptată, iar cheile simetrice există în memoria aplicației cât timp CryptoKit criptează sau decriptează un seif deschis.

Această limită față de furnizor este o proprietate a arhitecturii, nu o promisiune că fiecare parte a mediului client este în afara modelului de încredere. Vaultaire nu deține o cheie de decriptare pe server pe care să o poată preda pentru recuperarea obișnuită a seifului. Aplicația livrată, iOS, dispozitivul deblocat și implementarea criptografică pot procesa în continuare date lizibile și trebuie tratate ca atare.

Keychain și limita procesului aplicației

Secure Enclave de la Apple poate proteja chei private compatibile și participă la unele părți ale arhitecturii de securitate a platformei, dar API-urile sale publice nu acceptă o cheie simetrică arbitrară derivată cu PBKDF2 ca să execute în coprocesor operațiile AES-GCM ale Vaultaire asupra fișierelor. De aceea Vaultaire nu își descrie cifrul seifului drept AES în Secure Enclave.

Vaultaire folosește elemente Keychain iOS obișnuite, de tip parolă generică, pentru sarea aleatorie a dispozitivului, baza de date de recuperare criptată și cheia aleatorie care protejează acea bază de date. Aceste elemente folosesc clasa de accesibilitate WhenUnlockedThisDeviceOnly. Keychain și Data Protection creează o limită reală a dispozitivului, mai ales cât timp telefonul este blocat, dar această arhitectură diferă de o cheie Secure Enclave care nu poate fi exportată.

Când desenezi modelul, CommonCrypto derivă cheia de seif în procesul aplicației. CryptoKit și CryptoEngine din Vaultaire folosesc apoi octeții cheii simetrice în acel proces pentru a autentifica și decripta indexul, a despacheta cheia principală și a procesa fișierele. Aplicația șterge starea activă când se blochează, dar un atacator cu privilegii suficiente care observă o sesiune deblocată are o oportunitate diferită de a unui examinator care deține doar textul cifrat al unui dispozitiv blocat.

Un sistem de operare cu jailbreak sau compromis în alt fel poate viza introducerea modelului, memoria aplicației, previzualizările decriptate, exporturile sau ecranul. Vaultaire recomandă un iPhone actualizat, fără jailbreak, pentru că designul se bazează pe izolarea proceselor din iOS, pe Keychain și pe Data Protection. Nu pretinde că o compromitere la nivel root lasă inaccesibile cheile simetrice ale unui seif deschis.

Vectori de inițializare pentru fiecare fișier

Când criptezi două fișiere identice cu aceeași cheie, o implementare naivă ar produce text cifrat identic. Asta este o problemă. Un atacator care vede două blocuri criptate identice știe — fără să decripteze nimic — că cele două fișiere originale sunt la fel. Într-un seif plin de poze, acest tip de analiză a tiparelor poate dezvălui informații chiar prin criptare.

Vaultaire previne textul cifrat determinist generând un nonce criptografic nou pentru fiecare operație de sigilare AES-256-GCM. Anteturile și conținutul fișierelor sunt sigilate separat, iar fișierele mari folosesc un format de streaming autentificat, cu un nonce de bază aleatoriu și un nonce distinct pentru fiecare bucată ordonată. Două copii ale aceleiași poze nu produc deci aceeași reprezentare criptată.

Nonce-urile sunt stocate împreună cu textul cifrat și nu sunt secrete; cerința lor de securitate este unicitatea sub o anumită cheie. Vaultaire cere nonce-uri de 96 de biți de la generatorul criptografic aleatoriu al Apple pentru criptarea dintr-o singură trecere și înregistrează nonce-ul de bază în antetul de streaming. Riscul de coliziune depinde de numărul de criptări sub o cheie, așa că implementarea generează o valoare nouă în loc să prezinte dimensiunea de 96 de biți ca pe o garanție fixă de unu la 2⁹⁶ pe toată durata de viață.

Gestionarea memoriei: ștergerea stării active a cheilor

O greșeală frecventă în software-ul de securitate este lăsarea datelor sensibile în memorie după ce nu mai sunt necesare. Cheile de criptare, parolele derivate și datele decriptate pot rămâne în RAM mult după ce aplicația a terminat cu ele. Instrumentele criminalistice pot extrage memoria dispozitivului și pot căuta aceste resturi — o tehnică numită atac cold boot sau analiză a memoriei extrase.

Vaultaire limitează cât timp rămân disponibile starea activă a cheilor și datele decriptate din interfață. Când aplicația se blochează sau sesiunea se închide, codul său urmează mai multe căi de curățare:

• Starea activă a seifului este eliminată. Aplicația își elimină sesiunea curentă cu cheia de seif și cere o nouă deblocare înainte să afișeze conținutul seifului.
• Ambalajele cheilor își șterg bufferele proprii. Containerele securizate de octeți din Vaultaire suprascriu bufferele pe care le dețin când sunt dealocate.
• Starea cheii principale din cache este invalidată. Cheia principală decriptată păstrată pentru indexul deschis este eliminată pe căile relevante de blocare și de resetare a cache-ului.
• Cache-urile decriptate ale interfeței sunt șterse acolo unde Vaultaire le controlează. Curățarea miniaturilor și a previzualizărilor reduce starea reziduală a aplicației, fără să pretindă control asupra fiecărei copii făcute de Swift, iOS sau alt proces.

Data viitoare când Vaultaire se deschide blocată, desenezi modelul, iar aplicația derivă din nou cheia de seif înainte să poată autentifica indexul și despacheta cheia principală. Aceasta este o curățare a sesiunii, nu o afirmație că fiecare copie temporară din memorie a fost ștearsă demonstrabil prin mai multe treceri sau că a fost distrusă o referință la o cheie Secure Enclave. La o cădere a aplicației, iOS recuperează procesul, dar codul de curățare nu poate rula după fiecare oprire bruscă.