Criptare end-to-end pentru fotografii: cum funcționează și ce aplicații o oferă
Criptarea end-to-end ține conținutul lizibil al pozelor și cheile de conținut în text simplu departe de furnizorul de stocare.
Criptarea end-to-end (E2EE) este un model de securitate în care textul simplu este criptat pe un dispozitiv final autorizat și decriptat pe altul. Furnizorul de stocare sau de transport nu deține cheia de conținut în text simplu. Această limită protejează conținutul de citirea directă pe server, dar nu ascunde toate metadatele și nu protejează un dispozitiv final compromis, datele de recuperare, un destinatar al partajării sau o actualizare rău intenționată a clientului.
Pentru stocarea pozelor, criptarea end-to-end înseamnă că telefonul tău criptează conținutul pozelor înainte de încărcare, iar cloudul stochează text cifrat, nu imagini lizibile. Decriptarea cere o cheie disponibilă printr-un dispozitiv autorizat sau printr-o cale de recuperare. Dimensiunea fișierelor, momentul încărcării, datele contului, relațiile de partajare și alte metadate pot rămâne vizibile. Acest ghid explică limita și compară modelele folosite de servicii obișnuite.
Cum funcționează criptarea end-to-end
Mecanismul de bază are trei etape: generarea cheii, criptarea și decriptarea.
Generarea cheii
Dispozitivul utilizatorului generează o cheie criptografică. La criptarea simetrică (de exemplu AES-256), aceeași cheie criptează și decriptează. La criptarea asimetrică (de exemplu RSA), o cheie publică criptează și o cheie privată decriptează. Multe sisteme E2EE le combină: criptarea asimetrică schimbă o cheie de sesiune simetrică, care apoi criptează volumul mare de date.
Aplicațiile seif pentru poze folosesc mai multe modele de gestionare a cheilor. Unele derivă o cheie de fișier direct dintr-o parolă; modelele stratificate, mai puternice, pot folosi o cheie de deblocare derivată din datele de acces pentru a încapsula o cheie de fișier aleatorie. Vaultaire folosește PBKDF2-HMAC-SHA512 pentru a deriva o cheie de seif de 256 de biți dintr-un model 5x5 și o sare la nivelul dispozitivului. Această cheie de seif autentifică indexul criptat și decapsulează o cheie principală aleatorie separată, folosită pentru criptarea fișierelor.
Criptarea
Textul simplu (poza ta) este transformat în text cifrat cu ajutorul cheii de criptare și al unui algoritm de criptare. AES-256-GCM este cel mai folosit cifru simetric în acest scop. GCM (Galois/Counter Mode) oferă criptare autentificată: criptează datele și produce o etichetă de autentificare care detectează orice modificare. Fiecare fișier primește un vector de inițializare (IV) unic, astfel încât fișierele identice produc text cifrat diferit.
Decriptarea
Dispozitivul destinatarului folosește aceeași cheie (simetric) sau cheia privată corespunzătoare (asimetric) pentru a inversa transformarea. Fără cheia corectă, textul cifrat nu se poate deosebi de date aleatorii. Nu există o scurtătură matematică. AES-256 are 2^256 chei posibile, mai multe decât numărul estimat de atomi din universul observabil.
E2EE față de alte modele de criptare
Nu orice criptare este end-to-end. Diferențele stabilesc cine îți poate accesa datele.
Criptarea în tranzit (TLS/SSL)
Datele sunt criptate între dispozitivul tău și server. Serverul le decriptează la primire. Asta protejează împotriva interceptării în timpul transmisiei, dar datele rămân lizibile pe server. Toate serviciile cloud mari folosesc criptarea în tranzit. Este minimul de bază, nu un standard de protecție.
Criptarea în repaus (pe server)
Serverul criptează datele stocate cu chei pe care le gestionează el. Asta protejează împotriva furtului fizic al hardware-ului, dar nu împotriva furnizorului, a angajaților lui sau a cererilor legale adresate furnizorului. iCloud, Google Drive și Dropbox folosesc toate criptarea în repaus pe server. Furnizorul deține cheile.
Criptarea end-to-end
Datele sunt criptate pe un dispozitiv final autorizat înainte ca furnizorul de stocare să le primească. Un design solid ține cheia de conținut în text simplu în afara custodiei obișnuite a furnizorului, așa că o compromitere doar a stocării sau o cerere legală pentru conținutul stocat produce text cifrat, nu poze lizibile. Furnizorul poate totuși livra text cifrat și metadate, poate distribui software-ul client sau poate opera sisteme de recuperare și partajare, care trebuie incluse în modelul de amenințare.
| Model de criptare | Cine deține cheile | Furnizorul poate citi datele? | Protejează față de furnizor? |
|---|---|---|---|
| Numai la transmitere (TLS) | Server | Da | Nu |
| În repaus (server) | Server | Da | Nu |
| End-to-end | Dispozitive finale autorizate sau deținători ai recuperării | Nu doar din textul cifrat stocat | Protejează conținutul de cheile de stocare deținute de furnizor |
| Criptare pe partea clientului nevăzută de furnizor | Client și căi de recuperare documentate | Fără acces la conținut în text simplu prin proiectare | Protejează conținutul; metadatele și încrederea clientului rămân |
Cum tratează serviciile de stocare foto criptarea
Modelul de criptare variază semnificativ între serviciile de stocare foto. Unele promovează "criptare" fără a specifica modelul, ceea ce poate duce utilizatorii să creadă că fotografiile sunt E2EE când nu sunt.
Poze iCloud
Apple folosește criptare la transmitere și în repaus. Apple deține implicit cheile de criptare. Cu o solicitare legală valabilă, Apple poate furniza date Poze iCloud. Excepție: Protecția avansată a datelor, disponibilă din decembrie 2022, adaugă criptare end-to-end la Poze iCloud. Trebuie activată explicit în Configurări. Când este activată, Apple nu poate accesa datele din Poze iCloud. Majoritatea utilizatorilor nu au activat-o.
Google Photos
Google folosește criptare la transmitere și în repaus cu chei server. Google deține cheile de criptare pentru toate datele Google Photos, inclusiv conținutul folderelor blocate. Google poate îndeplini solicitări legale de date. Google nu oferă nicio opțiune E2EE pentru Google Photos.
Dropbox
Criptare în tranzit (TLS 1.2+) și în repaus (AES-256 cu chei gestionate de Dropbox). Dropbox deține cheile și îți poate accesa fișierele. Dropbox a suferit breșe de date (2012, 68 de milioane de conturi). Dropbox Vault (o funcție plătită) adaugă protecție prin PIN, dar nu și criptare end-to-end.
OneDrive
Microsoft folosește criptare în tranzit și în repaus cu chei gestionate de Microsoft. Microsoft deține cheile. OneDrive Personal Vault adaugă verificarea identității (2FA), dar nu și criptare end-to-end: Microsoft poate accesa în continuare datele. Clienții enterprise pot folosi chei gestionate de ei.
Vaultaire
Criptare pe partea clientului cu cheile deținute de furnizor excluse. Vaultaire criptează fotografiile și metadatele de pe dispozitiv cu AES-256-GCM înainte de orice încărcare în cloud. O cheie principală aleatorie criptează datele seifului. O cheie locală de seif derivată din modelul utilizatorului și o sare a dispozitivului încapsulează cheia principală, în timp ce o cheie de rezervă separată derivată din model protejează înregistrările de backup CloudKit private. Vaultaire nu operează un server de conținut și nu primește acele chei, așa că nu poate transforma o înregistrare CloudKit în text simplu. Aplicația, iOS și un dispozitiv deblocat rămân în limita de încredere, iar o solicitare legală poate obține în continuare metadatele contului sau serviciului deținute de furnizorul relevant.
| Serviciu | Criptare la transmitere | Criptare în repaus | Criptare end-to-end | Furnizorul poate accesa |
|---|---|---|---|---|
| Poze iCloud (standard) | Da | Da (cheile Apple) | Nu | Da |
| Poze iCloud (Protecția avansată a datelor activată) | Da | Da | Da | Nu |
| Google Photos | Da | Da (cheile Google) | Nu | Da |
| Dropbox | Da | Da (cheile Dropbox) | Nu | Da |
| OneDrive | Da | Da (cheile Microsoft) | Nu | Da |
| Vaultaire | Da | Da | Backup criptat pe partea clientului, activat implicit | Fără cheie de conținut în text simplu; metadatele CloudKit rămân |
De ce E2EE este importantă pentru fotografii
Fotografiile sunt date deosebit de sensibile. Conțin fețe, locații (metadate GPS), marcaje de timp și înregistrări vizuale ale momentelor private. O breșă în biblioteca ta foto dezvăluie mai multe informații personale decât aproape orice alt tip de date.
Breșele de date
Când un furnizor de servicii stochează fotografii cu chei de pe server, un compromis atât al stocării, cât și al căii sale de gestionare a cheilor poate expune conținut care poate fi citit. Cu un E2EE solid, o breșă doar a stocării produce text cifrat și orice metadate păstrează serviciul. Compromiterea dispozitivului final, acreditările de recuperare furate, software-ul client rău intenționat și defectele serviciilor de chei rămân rute separate către text simplu.
Accesul legal și guvernamental
Furnizorilor de servicii li se poate solicita să furnizeze înregistrările pe care le dețin. Cu E2EE, acestea pot include text cifrat, informații despre cont, jurnalele de acces, dimensiunile înregistrărilor, metadate de sincronizare și partajare, mai degrabă decât conținut foto lizibil. Dacă o cerere poate ajunge la un dispozitiv, o metodă de recuperare, un destinatar sau comportamentul viitor al clientului este o altă întrebare juridică și tehnică.
Accesul din interior
Angajații sau atacatorii cu acces la cheile de stocare gestionate de furnizor ar putea să ajungă la conținut criptat pe server. E2EE elimină acea cale directă a cheii de stocare atunci când furnizorului îi lipsesc cheile de conținut în text simplu. Nu face ca abuzul din interior să fie categoric imposibil, deoarece furnizorii pot controla distribuția clientului, starea contului, metadatele, partajarea sau componentele de recuperare.
Protecția metadatelor
Unele implementări E2EE criptează doar conținutul fișierelor și lasă neprotejate metadate precum numele și datele fișierelor. Vaultaire protejează antetele fișierelor, tipurile MIME, indexurile, miniaturile și alte metadate ale seifului cu criptare autentificată AES-256-GCM. Lungimea textului cifrat stocat și numărul fișierelor de stocare criptate pot totuși dezvălui informații structurale cuiva care are acces la containerul aplicației, de exemplu o estimare a numărului de seifuri care conțin fișiere.
Concepții greșite frecvente despre E2EE
„Stocarea mea cloud este criptată deci fotografiile sunt în siguranță.” Criptarea server protejează față de breșele externe ale hardware-ului serverului. Nu protejează față de furnizorul însuși, solicitări legale sau amenințări interne. Furnizorul deține cheile.
„HTTPS înseamnă că fotografiile mele sunt criptate end-to-end.” HTTPS (TLS) criptează datele la transmitere între dispozitivul tău și server. Odată ce datele ajung pe server, sunt decriptate. HTTPS este criptarea canalului, nu criptarea datelor.
„E2EE înseamnă că nimeni nu poate vedea vreodată fotografiile mele.” E2EE înseamnă că nimeni fără cheia nu poate vedea fotografiile. Dacă cineva are parola sau cheia ta, poate decripta datele. Gestionarea cheilor și parolele puternice rămân esențiale.
„Apple/Google nu îmi pot vedea pozele.” Implicit, ambele companii dețin cheile de criptare pentru pozele stocate în cloud. Apple oferă Protecția avansată a datelor ca opțiune pe care trebuie să o activezi. Google nu oferă nicio opțiune E2EE pentru Google Photos.
Cum implementează Vaultaire E2EE
Vaultaire folosește o abordare E2EE multistrat:
- AES-256-GCM criptează toate conținuturile fișierelor. Fiecare fișier primește un vector de inițializare unic. Criptarea autentificată detectează manipulările.
- PBKDF2 cu HMAC-SHA512 derivă o cheie locală de seif din modelul desenat de utilizator și din sarea dispozitivului. Factorul de lucru crește costul fiecărei presupuneri offline fără a adăuga entropie modelului. Acea cheie de seif autentifică indexul criptat și despachetează cheia principală aleatorie utilizată în datele fișierului.
- AES-256-GCM pentru metadate protejează numele fișierelor, datele, dimensiunile, indecșii și miniaturile sub criptare autentificată.
- Keychain-ul iOS și Protecția datelor protejează sarea dispozitivului și baza de date de recuperare criptată. Operațiile AES-GCM și cheile simetrice active rămân în procesul aplicației în timp ce un seif este deschis.
- Separarea cheii furnizorului înseamnă că Wraxle nu primește nicio cheie de seif, principală, de backup sau de recuperare în text simplu. Backup-ul CloudKit (activat implicit), sincronizarea și partajarea stochează înregistrări de text cifrat și plicuri de chei criptate, în timp ce Apple poate observa în continuare metadatele serviciului. Vaultaire nu necesită un cont de identitate Vaultaire.
Vaultaire păstrează informațiile de recuperare, inclusiv modelul, într-o bază de date criptată cu AES-GCM, stocată în Keychain-ul iOS. Nu sunt scrise în fișiere text simplu sau trimise către un serviciu de cont Vaultaire. Dacă nu există un model utilizabil, fraza de recuperare, sau un dispozitiv deja deblocat, Vaultaire nu deține o cheie de recuperare a furnizorului care să poată restabili accesul.
Întrebări frecvente
Este criptarea end-to-end legală?
Tratamentul legal al criptării, accesului forțat și serviciilor criptate variază în funcție de jurisdicție și se poate modifica. Acest ghid descrie modelul tehnic, nu oferă sfaturi juridice. Verificați legislația locală actuală dacă utilizarea dvs. implică percheziții la frontieră, hotărâri judecătorești, înregistrări reglementate sau alte situații cu risc ridicat.
Pot autoritățile sparge criptarea end-to-end?
Atacurile rareori trebuie să parcurgă întregul spațiu de chei AES-256. Un examinator poate viza o parolă sau un model slab, un dispozitiv deblocat, o memorie, o frază de recuperare, un destinatar, o copie de rezervă sau un defect de implementare. AES-256-GCM implementat corect, cu o cheie aleatorie cu entropie mare, este proiectat să reziste căutării directe a cheilor, dar aceasta este doar o parte a sistemului.
Care este diferența între E2EE și criptarea zero-knowledge?
E2EE descrie unde au loc criptarea și decriptarea textului simplu și cine deține cheile de conținut utilizabile. „Zero-knowledge” este adesea folosit în marketingul de produse pentru criptarea nevăzută de furnizor, dar nu trebuie citit literal: un serviciu poate să nu aibă chei în text simplu și totuși să vadă text cifrat, date de cont, dimensiuni, sincronizare, relații de partajare și alte metadate. Evaluați căile documentate ale cheilor și ale recuperării, nu doar eticheta.
E2EE încetinește telefonul meu?
Dispozitivele moderne procesează AES-256 eficient, cu accelerare hardware expusă prin bibliotecile criptografice ale sistemului. Pe iPhone, Vaultaire execută AES-GCM în procesul aplicației prin CryptoKit. API-urile publice Secure Enclave de la Apple nu sunt un motor AES-GCM arbitrar pentru criptarea fișierelor. Costul suplimentar al criptării și decriptării depinde de dimensiunea fișierului și de dispozitiv, dar este conceput pentru a rămâne departe de drum în timpul utilizării normale.
Ce se întâmplă dacă îmi pierd cheia de criptare?
Pierderea fiecărei căi de decriptare și recuperare utilizabilă face datele criptate imposibil de recuperat. Prin urmare, multe sisteme E2EE utilizează fraze de recuperare, dispozitive de încredere, contacte de recuperare, truse de urgență sau plicuri de chei criptate. Aceste mecanisme păstrează accesul, dar fiecare devine și parte a modelului de securitate.
Concluzie
Criptarea de la capăt la capăt poate elimina calea furnizorului de stocare către cheile în text simplu atunci când criptarea are loc pe un dispozitiv final autorizat înainte de încărcare. Aceasta este o protecție semnificativă, nu o garanție pentru întregul sistem. Verificați custodia cheii de conținut, recuperarea, metadatele, actualizările clientului, securitatea dispozitivelor finale și partajarea înainte de a acorda încredere unui serviciu cu fotografii private.
Vaultaire implementează criptarea pe partea client pentru iOS. Fotografiile și metadatele din seif sunt criptate pe dispozitiv cu AES-256-GCM înainte de backup sau sincronizare. Vaultaire nu primește cheile de decriptare și nu operează un server care poate transforma acele înregistrări criptate în fotografiile tale. Această limită a furnizorului nu face demn de încredere un iPhone compromis sau deblocat.