Arhitectura de securitate: Fundația tehnică completă

Arhitectura de securitate a Vaultaire este construită pe criptarea fișierelor AES-256-GCM, derivarea cheilor PBKDF2 cu 600.000 de iterații, protecția metadatelor ChaCha20, chei protejate hardware în Apple Secure Enclave și un design zero-knowledge care face imposibil chiar și pentru compania Vaultaire accesul la datele dvs.

Stratul 1: Criptarea fișierelor AES-256-GCM

Fiecare fișier din seiful Vaultaire este criptat separat cu AES-256-GCM. AES (Advanced Encryption Standard) este standardul mondial pentru criptarea simetrică, aprobat de NIST și standardizat FIPS 197 pentru aplicații guvernamentale și militare. Varianta cu cheie de 256 de biți folosește 14 runde de transformare față de 10 pentru AES-128, oferind marje de securitate semnificativ mai mari.

GCM (Galois/Counter Mode) adaugă criptare autentificată, ceea ce înseamnă că fiecare fișier conține o verificare criptografică a integrității. Dacă cineva ar modifica datele criptate, chiar și cu un singur bit, verificarea de autentificare ar eșua imediat la decriptare. Aceasta previne nu doar citirea fișierelor fără cheie, ci și modificarea lor silențioasă.

Stratul 2: Derivarea cheilor PBKDF2

Modelul dvs. nu este direct cheia de criptare. Trece prin PBKDF2 (Password-Based Key Derivation Function 2) cu hash HMAC-SHA512. Vaultaire folosește 600.000 de iterații, limita superioară a recomandărilor NIST pentru 2026 și mult peste minimul de 210.000 de iterații pe care OWASP îl recomandă pentru SHA512.

Numărul mare de iterații are un singur scop: a încetini un atacator care încearcă să testeze modele posibile. Pe hardware modern, 600.000 de iterații PBKDF2 durează aproximativ o zecime de secundă. Pentru dvs., care vă cunoașteți modelul, acea mică pauză este irelevantă. Pentru un atacator care testează milioane de modele, aceasta este diferența dintre un atac care durează ore și unul care durează milenii.

Sare per seif

Fiecare seif are propria sare criptografic aleatorie generată la creare. Sarea este amestecată cu modelul înainte de derivarea PBKDF2. Aceasta previne ca un atacator să precalculeze un tabel de hash-uri pentru modele populare (atac de tip rainbow table). Chiar dacă doi utilizatori folosesc un model identic, cheile derivate vor fi complet diferite din cauza sărurilor diferite.

Stratul 3: Protecția metadatelor ChaCha20

AES-256-GCM protejează conținutul fișierelor. Dar ce se întâmplă cu metadatele despre acele fișiere: nume, dimensiuni, date de modificare, structura dosarelor? Aceste date pot dezvălui mult chiar și fără acces la conținut.

Vaultaire protejează metadatele separat cu cifrul flux ChaCha20. ChaCha20 a fost ales pentru metadate datorită performanței excelente pe platformele fără accelerare hardware AES și deoarece caracteristicile sale de securitate sunt bine studiate independent de AES. Folosirea unui algoritm diferit pentru metadate înseamnă că o vulnerabilitate ipotetică ce afectează un algoritm nu compromite automat celălalt strat.

Stratul 4: Integrarea Apple Secure Enclave

Apple Secure Enclave este un coprocesor separat integrat în fiecare iPhone modern. Are propria memorie izolată și spațiu de execuție fizic separat de procesorul principal. Nici iOS, nici aplicațiile, nici Vaultaire în sine nu pot accesa direct conținutul Secure Enclave.

Vaultaire delegă operațiunile criptografice critice Secure Enclave ori de câte ori este posibil. Aceasta înseamnă că materialul criptografic sensibil există în hardware rezistent la manipulare neautorizată, nu în software pe care un atacator l-ar putea examina sau modifica. Chiar și cu acces complet la stiva software a telefonului, conținutul Secure Enclave rămâne inaccesibil.

Stratul 5: IV per fișier și izolarea criptografică

Fiecare operațiune de criptare din Vaultaire folosește un IV (vector de inițializare) aleatoriu proaspăt generat. Nu se repetă niciodată. Aceasta este importantă deoarece una dintre rarele slăbiciuni ale AES-GCM este reutilizarea IV cu aceeași cheie, care poate scurge informații despre textul clar.

IV-urile sunt stocate alături de datele criptate, dar sunt criptografic lipsite de semnificație fără cheie. Efectul general este că fiecare text cifrat arată criptografic independent de toate celelalte, chiar și pentru fișiere de intrare identice criptate cu aceeași cheie. Un atacator care observă multiple ieșiri criptate nu poate deduce dacă fișierele originale au fost identice.

Stratul 6: Design zero-knowledge

Design-ul zero-knowledge nu este o funcție: este o restricție arhitecturală. Vaultaire este construit astfel încât compania să nu poată deține niciodată cheile de decriptare ale datelor utilizatorilor, chiar și dacă ar dori.

Cheile sunt derivate local pe dispozitiv. Nu sunt niciodată transmise serverelor Vaultaire. Serverele pot stoca date criptate în scopuri de backup și sincronizare, dar acele date sunt fără sens pentru ele fără cheie. Vaultaire nu poate satisface o solicitare de date ale utilizatorilor deoarece tehnic, nu numai politic, nu deține acele date.

Stratul 7: Protecție criminalistică și de memorie

Cheile de criptare există în memorie doar când seiful este deblocat. Când utilizatorul închide aplicația, o trimite în fundal sau când sistemul detectează o perioadă de inactivitate, cheile sunt șterse din RAM. Nu este suficient să ieșiți din aplicație: memoria este nulificată activ pentru a preveni date reziduale care ar putea fi recuperate prin instrumente criminalistice de memorie.

Această abordare de ștergere a cheilor din memorie înseamnă că nu există nicio stare de securitate parțială în aplicație. Fie cheile sunt în memorie și seiful este accesibil, fie nu sunt și seiful este ermetic sigilat.