Criptare zero-knowledge: ce înseamnă și de ce contează pentru fotografii
Criptarea cu cunoștințe zero este o arhitectură limitată de furnizor în care serviciul nu deține cheia necesară pentru a decripta conținutul stocat al utilizatorului. Spre deosebire de criptarea standard în cloud, în care furnizorul controlează cheia de conținut, criptarea la nivelul clientului poate păstra această capacitate pe dispozitivele utilizatorului. O solicitare legală, o încălcare sau o încălcare din interior poate expune în continuare text cifrat, înregistrări de cont, date de trafic sau alte metadate pe care furnizorul le păstrează. Îndrumarea NIST privind gestionarea cheilor face ca custodia cheii să fie centrală pentru acces, dar aplicația client, sistemul de operare și dispozitivul deblocat rămân parte din limita de încredere.
Furnizorul nu primește nicio cheie de conținut text simplu. Cheile de conținut există în mod necesar în memoria clientului în timpul utilizării și pot fi, de asemenea, stocate local sau de la distanță în plicuri criptate autentificate. Furnizorul poate stoca text cifrat și chei împachetate fără a deține secretul utilizatorului necesar pentru a le deschide. Metadatele privind contul, traficul, dimensiunea înregistrării și sincronizarea pot rămâne în continuare vizibile.
Zero-knowledge vs. criptare standard
Diferența fundamentală este cine deține cheile:
| Aspect | Criptare standard | Zero-knowledge |
|---|---|---|
| Cine deține cheile | Furnizorul | Numai utilizatorul |
| Furnizorul poate accesa datele | Da | Nu (arhitectural imposibil) |
| Vulnerabil la cereri legale | Da (furnizorul poate preda date) | Nu (furnizorul nu are chei) |
| Recuperare cont de furnizor | Da | Nu (furnizorul nu poate) |
| Verificabilitate | Trebuie să ai încredere | Verificabilă arhitectural |
Cum verifici că o aplicație este zero-knowledge
Câteva indicatori că o implementare este cu adevărat zero-knowledge:
- Cheia este generată local: Aplicația nu trimite niciodată parola sau modelul la un server.
- Fără resetare parolă prin email: Dacă furnizorul poate reseta parola prin email, deține cheile sau are acces la date.
- Fără cont obligatoriu: Un cont cu email implică că furnizorul poate lega identitatea de date.
- Open source sau audit public: Codul poate fi verificat independent.
Cum implementează Vaultaire separarea furnizor-cheie
- Vaultaire: ZK complet, cheile locale, fără cont, fără server Vaultaire.
- iCloud cu APD: Fotografiile sunt E2E criptate față de Apple, dar există un sistem de conturi.
- 1Password: Parole zero-knowledge cu arhitectura Secret Key.
- Bitwarden: Open source, ZK pentru conținut (nu metadate).
Aceste teste sunt filtre, nu o dovadă de securitate. O specificație coerentă ar trebui să numească cheia de conținut, cheia de deblocare, sărurile, parametrii de derivare, formatul de criptare autentificat, regulile nonce, plicurile de recuperare, stocarea secretă locală, metadatele în cloud și punctul în care există cheile de text simplu. Evaluarea independentă este o dovadă mai puternică decât o etichetă a produsului.
Compromisuri zero-knowledge
Datele dvs. devin permanent inaccesibile dacă fiecare acreditări valide și fiecare plic de recuperare sunt pierdute. O resetare sau o cheie principală controlată de furnizor ar slăbi limita furnizorului, așa că recuperarea trebuie proiectată separat. Vaultaire generează o expresie personalizată care conține 9 cuvinte separate, a cărei cheie de recuperare derivată deschide un plic criptat cu cheie seif. Expresia nu regenerează sau codifică cheia, iar restaurarea dispozitivului nou necesită, de asemenea, corespondența criptată. CloudKit înregistrări.
Vaultaire reduce parțial acest risc printr-o frază de recuperare personalizată cu 9 cuvinte distincte, generată la configurare. Nu este BIP-39 și nu codifică cheia seifului: derivă o cheie separată care deschide un plic de recuperare criptat. Dacă păstrezi fraza în siguranță, recuperarea se poate face fără ajutorul Vaultaire, dar necesită și datele locale sau înregistrările CloudKit criptate corespunzătoare.