Ce este criptarea zero-knowledge? Un ghid simplu
Criptarea zero-knowledge înseamnă că furnizorul nu îți poate accesa datele.
Criptarea zero-knowledge este o arhitectură limitată la furnizor, în care serviciul nu deține cheia necesară pentru a decripta conținutul stocat al utilizatorului. Spre deosebire de criptarea cloud standard, în care furnizorul controlează cheia de conținut, criptarea pe dispozitiv poate păstra această capacitate pe dispozitivele utilizatorului. O cerere legală, o breșă sau o persoană din interior pot expune totuși text cifrat, înregistrări de cont, date de trafic sau alte metadate păstrate de furnizor. Ghidul NIST pentru gestionarea cheilor pune custodia cheilor în centrul accesului, dar aplicația client, sistemul de operare și dispozitivul deblocat rămân parte din perimetrul de încredere.
Cum funcționează criptarea zero-knowledge
Cea mai simplă analogie: un seif de hotel la care doar tu setezi combinația, iar hotelul nu o află niciodată. Dacă uiți combinația, hotelul nu poate deschide seiful pentru tine. Nu este un defect de proiectare. Asta este proiectarea.
În termeni tehnici, criptarea zero-knowledge funcționează în trei pași:
Derivarea cheii pe dispozitiv. Utilizatorul furnizează date de acces, precum o parolă, o frază de acces sau un model. O funcție de derivare a cheii din parolă le combină cu o sare pentru a produce o cheie pe dispozitivul utilizatorului. Un design bine separat poate folosi acea cheie pentru a debloca o cheie aleatorie de criptare a conținutului, în loc să cripteze fiecare fișier direct cu datele de acces umane.
Criptarea înainte de transmitere. Toate datele sunt criptate pe dispozitiv cu cheia derivată înainte să plece spre stocarea cloud sau backup. Se încarcă rezultatul criptat (textul cifrat).
Furnizorul nu primește nicio cheie de conținut în clar. Cheile de conținut există inevitabil în memoria clientului în timpul utilizării și pot fi stocate și local sau la distanță, în plicuri criptate autentificate. Furnizorul poate stoca text cifrat și chei împachetate fără să dețină secretul utilizatorului necesar pentru a le deschide. Metadatele de cont, trafic, dimensiune a înregistrărilor și sincronizare pot rămâne totuși vizibile.
Constrângerea critică: dacă utilizatorul pierde toate datele de acces valide și toate căile de recuperare, conținutul criptat devine inaccesibil. Recuperarea poate exista în continuare, dar custodia cheilor ei trebuie explicată. Dacă doar o resetare prin e-mail redă conținutul lizibil fără aprobarea unui dispozitiv vechi, o frază de recuperare, o cheie de recuperare sau un secret echivalent deținut de utilizator, furnizorul și-a păstrat o cale efectivă înapoi la textul în clar.
Criptarea zero-knowledge comparată cu alte tipuri de criptare
Termenul „criptare” apare în materialele de marketing ale aproape oricărui serviciu cloud. Diferențele dintre tipuri sunt substanțiale.
| Tip | Cine deține cheia | Furnizorul poate citi datele | Rezistă unei breșe la furnizor | Exemplu |
|---|---|---|---|---|
| Fără criptare | N/A | Da | Nu | Dropbox (nivelul standard) |
| Criptare în tranzit (TLS) | Furnizorul | Da (în repaus, pe serverele lor) | Nu | Google Photos |
| Criptare în repaus pe server | Furnizorul | Da (dețin cheia de decriptare) | Parțial (depinde de amploarea breșei) | iCloud (standard) |
| Criptare end-to-end a platformei | Dispozitivele client și sistemul de recuperare al contului | Nu prin calea normală a serviciului | Depinde de client, de recuperare și de expunerea metadatelor | iCloud cu Protecția avansată a datelor |
| Criptare pe dispozitiv, oarbă pentru furnizor | Clientul și o cale de recuperare controlată de utilizator | Nicio cheie de conținut în clar deținută de furnizor | Conținutul poate rămâne criptat; metadatele și textul cifrat pot totuși să scape | Sisteme de seif și backup criptate |
Cea mai frecventă confuzie este între „criptarea în repaus” și „criptarea zero-knowledge”. La criptarea în repaus, furnizorul îți criptează datele pe serverele lui cu chei pe care le controlează. Asta protejează împotriva furtului fizic al serverelor. Nu protejează împotriva furnizorului care îți citește datele, a unei citații guvernamentale pentru date și chei sau a unei amenințări din interior. Furnizorul are capacitatea de decriptare.
La criptarea pe dispozitiv oarbă pentru furnizor, serviciul nu primește cheia de conținut în clar prin protocolul documentat. Textul cifrat stocat poate rămâne opac pentru acel furnizor, în timp ce software-ul client, calea de recuperare, metadatele contului și canalul de livrare a software-ului cer în continuare încredere și verificare.
De ce contează criptarea zero-knowledge
Breșele de date expun miliarde de înregistrări în fiecare an
Identity Theft Resource Center a raportat 3.205 compromiteri de date în Statele Unite în 2023, care au afectat aproximativ 353 de milioane de persoane. Când un furnizor deține cheile de conținut, o singură breșă poate expune atât datele stocate, cât și o cale de a le decripta. Criptarea oarbă pentru furnizor separă aceste active: o breșă a serverului poate expune totuși text cifrat și metadate, dar nu o cheie de conținut în clar deținută de furnizor. Ghicirea datelor de acces și compromiterea clientului rămân riscuri separate.
Obligația legală este o amenințare reală
Furnizorii pot fi obligați să dezvăluie datele pe care le păstrează. Un design orb pentru furnizor poate limita acest răspuns la text cifrat și la metadatele disponibile de cont, trafic, facturare sau serviciu, pentru că furnizorul nu deține cheia de conținut în clar. Dacă altcineva poate obține datele de acces ale utilizatorului, poate exploata un client sau poate impune dezvăluirea este o întrebare separată. Apple a introdus Protecția avansată a datelor în iOS 16.2 ca extindere opțională a criptării end-to-end pentru datele iCloud.
„Ai încredere în noi” nu este o arhitectură de securitate
Criptarea pe server se bazează pe chei și politici controlate de furnizor. Criptarea oarbă pentru furnizor schimbă custodia cheilor, astfel încât calea documentată a serviciului nu are o cheie de conținut în clar. Este o limită arhitecturală mai puternică, dar forța ei depinde în continuare de un cod client corect, de livrarea autentificată a software-ului, de o recuperare solidă, de dispozitive sigure și de o implementare care respectă specificația.
Standardul NIST din spatele criptografiei
AES-GCM a fost standardizat de National Institute of Standards and Technology în SP 800-38D (2007). AES a fost selectat de NIST printr-o competiție publică în 2001. „256” din AES-256 se referă la o cheie de 256 de biți. Căutarea exhaustivă a unei chei uniform aleatorii este imposibilă computațional, dar o parolă sau un model ales de un om poate oferi mult mai puțină entropie, chiar dacă o funcție de derivare a cheii produce 256 de biți.
GCM (Galois/Counter Mode) adaugă criptarea autentificată, adică procesul de decriptare detectează orice modificare a textului cifrat. Dacă un singur bit din datele criptate este modificat, decriptarea eșuează în loc să producă un rezultat corupt. Asta îi împiedică pe atacatori să manipuleze datele criptate fără să fie detectați.
PBKDF2 (Password-Based Key Derivation Function 2), specificat în RFC 8018, transformă datele de acces furnizate de om în material de cheie de lungime fixă prin apeluri repetate ale unei funcții pseudoaleatorii. Mai multe iterații cresc costul fiecărei încercări. Nu adaugă entropie unui model sau unei parole previzibile, așa că alegerea datelor de acces și verificarea offline contează în continuare.
Cum implementează Vaultaire separarea cheilor față de furnizor
Vaultaire este un seif criptat pe dispozitiv pentru iPhone. În sensul de produs promovat des ca „zero knowledge”, afirmația sa documentată, mai restrânsă, este că Wraxle nu primește conținutul seifului în clar și nici cheile necesare pentru a-l decripta. Iată cum funcționează implementarea și limitele de încredere rămase la fiecare nivel.
Derivarea cheii. Utilizatorul desenează un model pe o grilă de 5x5 cu 25 de puncte. PBKDF2-HMAC-SHA512 combină acea secvență cu o sare Keychain comună dispozitivului, în 600.000 de iterații, pentru a deriva o cheie de seif de 256 de biți. Cheia de seif autentifică indexul criptat și împachetează o cheie principală separată, aleatorie, de 256 de biți. Informațiile de recuperare, inclusiv modelul, sunt stocate într-o bază de date Keychain criptată cu AES-GCM, nu în fișiere text simplu sau într-un cont Vaultaire.
Criptarea fișierelor. Fiecare fișier importat este criptat cu AES-256-GCM sub cheia principală aleatorie. CryptoKit creează cutii sigilate autentificate cu nonce-uri noi, iar formatul de streaming derivă un nonce distinct pentru fiecare fragment ordonat.
Criptarea metadatelor. Numele fișierelor, tipurile MIME, datele, înregistrările indexului și miniaturile sunt protejate tot cu AES-256-GCM. Vaultaire nu folosește ChaCha20 pentru metadatele seifului.
Gestionarea cheilor. Vaultaire stochează sarea dispozitivului și baza de date de recuperare criptată ca elemente obișnuite de parolă generică în Keychain din iOS, protejate cu clasa de accesibilitate WhenUnlockedThisDeviceOnly. Cheile de seif derivate din model și cheile principale aleatorii sunt procesate în memoria aplicației prin CryptoKit. Blocarea renunță la starea activă a cheilor, dar Swift și iOS nu oferă garanția că fiecare copie temporară este suprascrisă.
Descoperirea seifurilor. Interfața normală nu afișează o listă de seifuri. Paginile tuturor seifurilor stau într-un singur dosar comun, cu nume aleatorii, așa că numele fișierelor nu arată cărui seif îi aparține un fișier și nu dezvăluie modele, nume sau conținut în clar. Cineva cu acces la containerul aplicației poate totuși estima câte seifuri ai, pentru că numărul zonelor de stocare îl limitează. Vezi întreaga arhitectură de securitate și explicația criptării prin model.
Cum afli dacă o aplicație folosește criptare zero-knowledge reală
Începe cu trei teste rapide, apoi verifică arhitectura publicată:
Testul „am uitat parola”. Dacă doar resetarea prin e-mail redă datele lizibile, întreabă ce mecanism deținut de furnizor a recuperat cheia de conținut efectivă. Frazele de recuperare deținute de utilizator, aprobarea de pe dispozitivul vechi și resetările controlate de furnizor sunt designuri diferite.
Testul dispozitivului nou. Dacă un dispozitiv nou restaurează conținut lizibil, identifică secretul sau dispozitivul de încredere care a autorizat restaurarea. Autentificarea doar în cont sugerează o cale de recuperare controlată de furnizor; o frază de recuperare plus înregistrări de backup criptate poate păstra separarea cheilor față de furnizor.
Testul contului. O adresă de e-mail sau un număr de telefon leagă identitatea de metadatele serviciului, dar asta nu dovedește singur că furnizorul poate decripta conținutul. Examinează ierarhia cheilor, designul recuperării, codul client sau auditul, politica privind metadatele și dacă textul cifrat autentificat permite verificarea offline a datelor de acces.
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 pentru nonce-uri, plicurile de recuperare, stocarea locală a secretelor, metadatele din cloud și punctul în care există chei în clar. O verificare independentă este o dovadă mai puternică decât o etichetă de produs.
Întrebări frecvente
Este criptarea zero-knowledge același lucru cu criptarea end-to-end?
Se suprapun, dar nu sunt identice. Criptarea end-to-end (E2EE) înseamnă că datele sunt criptate pe dispozitivul expeditorului și decriptate doar pe dispozitivul destinatarului. Criptarea zero-knowledge înseamnă că furnizorul nu poate accesa datele. Un serviciu poate fi criptat end-to-end fără să fie zero-knowledge, dacă furnizorul a generat cheile sau a avut acces la ele la un moment dat. Criptarea zero-knowledge este standardul mai strict.
Ce se întâmplă dacă îmi pierd parola la criptarea zero-knowledge?
Datele tale devin inaccesibile definitiv dacă pierzi toate datele de acces valide și toate plicurile de recuperare. O resetare sau o cheie principală controlată de furnizor ar slăbi limita față de furnizor, așa că recuperarea trebuie proiectată separat. Vaultaire generează o frază personalizată de nouă cuvinte, din care se derivă o cheie de recuperare ce deschide un plic criptat cu cheia de seif. Fraza nu regenerează și nu codifică cheia, iar restaurarea pe un dispozitiv nou cere și înregistrările CloudKit criptate corespunzătoare.
Pot forțele de ordine să acceseze datele criptate zero-knowledge?
Un furnizor poate fi obligat să dezvăluie textul cifrat stocat și metadatele de cont, trafic, facturare sau serviciu pe care le păstrează. Fără o cheie de conținut în clar deținută de furnizor, acesta nu poate folosi calea normală a serviciului pentru a decripta conținutul. Exploatarea dispozitivului, descoperirea datelor de acces, copiile de recuperare și dezvăluirea impusă sunt căi separate, a căror legalitate și eficiență variază în funcție de jurisdicție și de fapte.
Este criptarea zero-knowledge mai lentă decât criptarea obișnuită?
Performanța AES-256-GCM nu depinde de cine deține cheia. Derivarea din parolă adaugă muncă la deblocare, iar durata ei depinde de algoritm, numărul de iterații, dispozitiv și implementare. Aplicațiile ar trebui să măsoare acest cost pe hardware-ul acceptat și să echilibreze viteza de răspuns cu costul impus fiecărei încercări offline.
Înseamnă zero-knowledge că aplicația nu colectează deloc date?
Nu neapărat. Termenul se referă la limita cheii de conținut față de furnizor, nu la fiecare flux de date. O aplicație poate procesa în continuare date de cont, analize, rapoarte de erori, adrese IP, dimensiuni ale înregistrărilor, momente sau alte metadate de serviciu. Vaultaire nu cere un cont de identitate. Analiza de utilizare și diagnosticarea erorilor sunt activate implicit și pot fi dezactivate din „Partajați erorile anonim” în Setări. Politica documentată pentru evenimente exclude conținutul seifurilor, modelele, frazele și cheile de decriptare; politica de confidențialitate descrie regulile actuale de colectare și păstrare.
Cum se compară criptarea zero-knowledge cu Protecția avansată a datelor de la Apple?
Protecția avansată a datelor (ADP) de la Apple, introdusă în iOS 16.2, extinde criptarea end-to-end la categorii suplimentare de date iCloud și folosește modelul de recuperare al contului Apple. Vaultaire criptează conținutul seifurilor pe dispozitiv și nu cere un cont de identitate Vaultaire; backupul său iCloud, activat implicit, plus sincronizarea și partajarea folosesc înregistrări CloudKit criptate pe dispozitiv în contul Apple al utilizatorului. Vaultaire oferă și acces la seifuri separat prin modele și modul de constrângere, cu limitele de stocare și recuperare descrise în documentația despre negarea plauzibilă.
Rezumat
Criptarea zero-knowledge se tratează cel mai bine ca o afirmație despre separarea cheilor față de furnizor: serviciul nu deține cheia în clar necesară pentru a decripta conținutul stocat. Este mai puternică decât criptarea pe server cu chei controlate de furnizor, dar nu afirmă că cheile există doar în memorie, că metadatele dispar sau că orice compromitere a clientului și a dispozitivului este dejucată. Judecă produsul după ierarhia cheilor, designul recuperării, implementare și verificarea independentă.