Sigurnosna arhitektura: Cjelovita tehnička osnova

Sigurnosna arhitektura Vaultairea izgrađena je na AES-256-GCM enkripciji datoteka, PBKDF2 izvođenju ključa s 600 000 iteracija, ChaCha20 zaštiti metapodataka, hardverski zaštićenim ključevima u Apple Secure Enclaveu i dizajnu nultog znanja koji onemogućuje čak i Vaultaire tvrtki pristup vašim podacima.

Sloj 1: AES-256-GCM enkripcija datoteka

Svaka datoteka u Vaultaire trezoru zasebno se šifrira pomoću AES-256-GCM. AES (Advanced Encryption Standard) je svjetski standard za simetričnu enkripciju, odobren od strane NIST-a i FIPS 197 standardiziran za vladine i vojne aplikacije. Varijanta s 256-bitnim ključem koristi 14 rundi transformacije u usporedbi s 10 rundi za AES-128, što pruža znatno veće margine sigurnosti.

GCM (Galois/Counter Mode) dodaje autentificirano šifriranje, što znači da svaka datoteka sadrži kriptografsku provjeru integriteta. Ako bi netko modificirao šifrirane podatke, čak i za jedan bit, autentifikacijska provjera bi odmah zatajila pri dekripciji. To sprečava ne samo čitanje vaših datoteka bez ključa, nego i njihovo tiho mijenjanje.

Sloj 2: PBKDF2 izvođenje ključa

Vaš uzorak nije direktno vaš ključ za enkripciju. Prolazi kroz PBKDF2 (Password-Based Key Derivation Function 2) s HMAC-SHA512 hashom. Vaultaire koristi 600 000 iteracija, što je gornja granica preporuka NIST-a za 2026. godinu i daleko iznad minimuma od 210 000 iteracija koji OWASP preporučuje za SHA512.

Visok broj iteracija ima jednu svrhu: usporiti napadača koji pokušava testirati moguće uzorke. Na modernom hardveru 600 000 iteracija PBKDF2 traje otprilike desetinu sekunde. Za vas, koji znate svoj uzorak, ta mala pauza je nevažna. Za napadača koji testira milijune uzoraka ona je razlika između napada koji traje sate i napada koji traje tisućljeća.

Sol po trezoru

Svaki trezor ima vlastitu kriptografski nasumičnu sol generiranu pri stvaranju. Sol se miješa s uzorkom prije PBKDF2 derivacije. To sprečava napadača od unaprijed izračunavanja tablice hashova za popularne uzorke (tzv. rainbow table napad). Čak i da dva korisnika koriste identičan uzorak, derivirani ključevi bit će potpuno različiti zbog različitih soli.

Sloj 3: ChaCha20 zaštita metapodataka

AES-256-GCM štiti sadržaj datoteka. No što je s metapodacima o tim datotekama: nazivi, veličine, datumi izmjene, struktura mapa? Ti podaci mogu otkriti puno čak i bez pristupa sadržaju.

Vaultaire štiti metapodatke zasebno pomoću ChaCha20 toka šifre. ChaCha20 odabran je za metapodatke zbog izvrsnih performansi na platformama bez hardverskog ubrzanja AES-a i zbog toga što su sigurnosne karakteristike dobro proučene neovisno o AES-u. Korištenje drugačijeg algoritma za metapodatke znači da bi hipotetska ranjivost koja utječe na jedan algoritam automatski ne kompromitirala drugi sloj.

Sloj 4: Apple Secure Enclave integracija

Apple Secure Enclave je zasebni koprocesor ugrađen u svaki moderni iPhone. Ima vlastitu izoliranu memoriju i izvršni prostor koji je fizički odvojen od glavnog procesora. Niti iOS, niti aplikacije, pa niti sam Vaultaire ne mogu izravno pristupiti sadržaju Secure Enclavea.

Vaultaire delegira kritične kriptografske operacije Secure Enclaveu gdje god je moguće. To znači da osjetljivi kriptografski materijal postoji u hardveru otpornom na neovlašteni pristup, a ne u softveru koji bi napadač mogao ispitati ili modificirati. Čak i uz potpuni pristup softverskom stogu telefona, sadržaj Secure Enclavea ostaje nedostupan.

Sloj 5: IV po datoteci i kriptografska izolacija

Svaka operacija šifriranja u Vaultaireu koristi svježe generirani nasumični IV (inicijalizacijski vektor). Nikad se ne ponavlja. To je bitno jer jedna od rijetkih slabosti AES-GCM jest ponovna upotreba IV-a s istim ključem, koja može procuriti informacije o otvorenom tekstu.

IV-ovi se pohranjuju uz šifrirane podatke, ali su sami po sebi kriptografski beznačajni bez ključa. Ukupni učinak jest da svaki šifrirni tekst izgleda kriptografski neovisno od svih ostalih, čak i za identične ulazne datoteke šifrirane istim ključem. Napadač koji promatra višestruke šifrirane izlaze ne može zaključiti jesu li izvorne datoteke bile identične.

Sloj 6: Dizajn nultog znanja

Dizajn nultog znanja nije značajka: to je ograničenje arhitekture. Vaultaire je izgrađen tako da tvrtka nikad ne može posjedovati ključeve za dešifriranje korisničkih podataka, čak i kad bi htjela.

Ključevi se izvode lokalno na uređaju. Nikad se ne prenose na Vaultaire poslužitelje. Poslužitelji mogu pohranjivati šifrirane podatke za svrhe backupa i sinkronizacije, ali ti podaci su im bez ključa besmisleni. Vaultaire ne može udovoljiti zahtjevu za korisničkim podacima jer tehničkom, a ne samo politički, nije u posjedu tih podataka.

Sloj 7: Zaštita od forenzike i memorije

Ključevi za enkripciju postoje u memoriji samo dok je trezor otključan. Kad korisnik zatvori aplikaciju, prebaci je u pozadinu ili kada sustav detektira period neaktivnosti, ključevi se brišu iz RAM-a. Nije dovoljno samo napustiti aplikaciju: memorija se aktivno nulira kako bi se spriječilo rezidualnih podatke koji bi se mogli dohvatiti forenzičkim alatima memorije.

Ovaj pristup brisanja ključeva iz memorije znači da nema sigurnog stanja u aplikaciji. Ili su ključevi u memoriji i trezor je dostupan, ili ih nema i trezor je hermetički zatvoren.