Negarea plauzibilă în aplicații: ce este și de ce contează

Negarea plauzibilă înseamnă că existența datelor ascunse nu poate fi dovedită.

În criptare, negarea plauzibilă este o proprietate a stocării care îi permite unui utilizator să dezvăluie un set de date fără să lase un artefact structural care dovedește existența altui set. Afirmația trebuie să își numească modelul de amenințare: o imagine statică a unui depozit criptat umplut corect este altceva decât un dispozitiv activ și compromis, metadatele unui serviciu cloud sau copiile păstrate în altă parte. Nu este doar o funcție de ascundere. Depinde de criptare, structură, umplere și designul operațional, care trebuie să funcționeze împreună.

Acest ghid explică cum funcționează negarea plauzibilă în aplicații, diferența dintre negarea criptografică reală și modurile-momeală cosmetice, situațiile reale în care contează și cum evaluezi afirmațiile despre negare.

Ce înseamnă negarea plauzibilă în criptare

În limbajul de zi cu zi, negarea plauzibilă înseamnă că poți nega ceva în mod credibil. În criptografia stocării, ținta utilă este mai îngustă: cine examinează depozitul criptat nu ar trebui să poată deosebi conținutul ascuns de spațiul neutilizat și umplut, în limitele modelului de amenințare declarat. Nicio aplicație nu poate extinde această promisiune la un seif deja deschis, la datele introduse și înregistrate, la copiile externe sau la orice formă de compromitere a dispozitivului.

Conceptul provine din criptarea discurilor. TrueCrypt (și succesorul său, VeraCrypt) a introdus volumul ascuns: un volum criptat în interiorul altui volum criptat. O parolă dezvăluie volumul exterior, cu fișiere inofensive. O altă parolă dezvăluie volumul interior ascuns, cu fișiere sensibile. Un examinator criminalistic nu poate stabili dacă există un volum ascuns, pentru că spațiul neutilizat din volumul exterior este umplut cu date aleatorii care nu pot fi deosebite de datele criptate.

În aplicații, negarea plauzibilă înseamnă că date de acces diferite (parole, PIN-uri, modele) deschid seturi de date diferite și că nu există metadate, registru, indicator de configurare sau artefact structural care să dezvăluie existența altor seturi de date.

Negare reală vs. moduri-momeală cosmetice

Aceasta este distincția critică pe care majoritatea aplicațiilor o greșesc.

Modul-momeală cosmetic (nu este negare reală)

Multe aplicații-seif oferă o funcție de „momeală” sau „PIN fals”. Setezi un PIN secundar care deschide un spațiu separat, cu alte poze. Problema: aceste aplicații stochează de obicei un indicator boolean, o intrare în baza de date sau un fișier de configurare care arată că un mod-momeală există și este configurat.

Un examinator criminalistic care înțelege aplicația poate găsi acest indicator. Găsirea unui mod-momeală configurat dovedește că există date ascunse. Negarea este cosmetică: funcționează împotriva unui curios ocazional, dar cedează la o examinare criminalistică.

Semne ale negării cosmetice:

• Aplicația are în setări un comutator pentru „modul-momeală”
• Un fișier de configurare stochează dacă modul-momeală este activat
• Un tabel din baza de date listează ID-urile seifurilor cu indicatori de tip (principal/momeală)
• Structura stocării aplicației se schimbă când modul-momeală este activat
• Dezinstalarea și reinstalarea aplicației dezvăluie un comportament diferit când modul-momeală a fost configurat

Negarea criptografică reală

Negarea reală este o proprietate a arhitecturii, nu un comutator. Stocarea criptată trebuie proiectată astfel încât:

1. Datele de acces alternative dezvăluie doar propriul set de date. Sistemul nu păstrează un indicator separat de momeală care să marcheze unele date de acces drept camuflaj. Datele de acces greșite pot eșua, dar eșecul nu trebuie să dezvăluie dacă există un set de date nedezvăluit.

2. Nu există niciun registru al seifurilor. Aplicația nu poate enumera câte seifuri există. Nu există un număr, un index sau o listă de ID-uri de seifuri. Un examinator criminalistic care analizează stocarea aplicației găsește un bazin nediferențiat de date criptate.

3. Niciun indicator de configurare nu dezvăluie seifurile ascunse. Nu există un boolean, o intrare în baza de date sau un fișier de preferințe care să arate dacă există seifuri suplimentare.

4. Stocarea este umplută. Spațiul total ocupat nu se schimbă în funcție de numărul de seifuri sau de fișiere. Fără umplere, un examinator ar putea estima numărul de seifuri comparând dimensiunea totală a datelor criptate cu conținutul vizibil.

5. Datele criptate nu pot fi deosebite de zgomotul aleatoriu. Nu există limite de fișiere, antete sau marcaje structurale care să arate unde se termină datele unui seif și unde încep ale altuia.

Situații reale în care contează

Negarea plauzibilă nu este o grijă teoretică. Răspunde unor situații reale, documentate și recurente.

Trecerea frontierei

La trecerea frontierei, un examinator poate inspecta un dispozitiv și poate cere datele de acces. Dacă un design oferă cu adevărat negare la nivelul stocării, un set de date de acces poate dezvălui un set de date inofensiv, iar o imagine statică nu are niciun marcaj structural care să deosebească conținutul ascuns de umplutură. Structura actuală a stocării Vaultaire îi permite unui examinator cu acces la containerul aplicației să estimeze numărul de seifuri, deci nu oferă această garanție.

Abuz domestic și relații coercitive

O persoană dintr-o relație abuzivă poate avea nevoie să stocheze dovezi (poze cu răni, mesaje amenințătoare, documente juridice) pe un dispozitiv pe care agresorul îl monitorizează. Dacă agresorul cere să vadă seiful, utilizatorul poate deschide un seif cu conținut nesensibil. Fără negare reală, un indicator de „mod-momeală” din configurația aplicației ar dezvălui existența conținutului ascuns.

Furtul dispozitivului

Un hoț cu abilități tehnice poate încerca să extragă date de pe un telefon furat. Un depozit cu negare, umplut corect, urmărește să ascundă câte seturi de date ocupă bazinul, deși alocarea totală, starea dispozitivului, backupurile și urmele operaționale rămân parte din modelul de amenințare. În prezent, Vaultaire criptează conținutul, dar numărul zonelor de stocare limitează totuși câte seifuri conțin fișiere.

Protecție juridică și jurnalistică

Jurnaliștii care își protejează sursele, avocații care protejează dosarele clienților și activiștii din regimuri autoritare se confruntă cu situații în care pot fi obligați să dezvăluie conținutul dispozitivelor. Negarea reală oferă o apărare credibilă împotriva confiscării datelor.

Ce implementează Vaultaire astăzi

Vaultaire implementează acces separat prin modele și o interfață normală fără listă vizibilă de seifuri. Aceste proprietăți ajută în folosirea obișnuită a aplicației, dar nu îndeplinesc toate cerințele din lista de verificare a negării reale de mai sus.

Modelele configurate deschid seifuri criptate separate. PBKDF2 derivă o cheie de seif din model și dintr-o sare comună dispozitivului. O cheie configurată își autentifică indexul criptat și despachetează o cheie principală aleatorie. Un model neconfigurat afișează o stare goală, nu un mesaj de „model incorect”.

Formatul local permite totuși o estimare a numărului de seifuri. Vaultaire stochează câte un fișier rădăcină vault_index_<locator>.bin pentru fiecare seif, într-un bazin de 64 sau mai multe, alături de fișiere de acoperire. Paginile și zonele de stocare ale tuturor seifurilor stau într-un singur dosar comun, cu nume aleatorii. Numele nu dezvăluie modelul, numele seifului sau cărui seif îi aparține un fișier, dar cineva cu acces la containerul aplicației poate totuși estima câte seifuri conțin fișiere, pentru că numărul zonelor de stocare îl limitează. Autentificarea AES-GCM oferă și un test offline pentru cheile de seif candidate.

Stocarea locală nu are dimensiune constantă. Conținutul fișierelor și metadatele sunt criptate, iar fragmentele de backup din cloud folosesc umplere a dimensiunii și înregistrări-momeală. Fișierele rădăcină stau într-un bazin, alături de fișiere de acoperire, iar zonele de stocare de acoperire țin numărul de zone într-un interval, dar numărul zonelor de stocare, numărul paginilor de catalog, momentele fișierelor și spațiul total pot expune totuși structura.

Există stare de recuperare și de constrângere. Vaultaire păstrează informațiile de recuperare într-o bază de date Keychain criptată cu AES-GCM. Modul de constrângere șterge indexurile, paginile și zonele de stocare ale celorlalte seifuri de pe acest dispozitiv (ștergere simplă a fișierelor, fără suprascriere), șterge datele de recuperare și izolează acel dispozitiv de sincronizare. Nu șterge backupurile din cloud sau copiile de pe dispozitivele pereche, iar durata depinde de volumul de lucru local.

Prin urmare, Vaultaire oferă compartimentare la nivel de interfață și stocare criptată, nu o dovadă teoretic-informațională că nu există niciun seif suplimentar. Formatul de stocare livrat în versiunea 1.0.17 ascunde ce fișiere aparțin cărui seif, dar numărul zonelor de stocare îi dă totuși unui instantaneu offline al containerului aplicației o limită pentru numărul de seifuri.

Cum evaluezi afirmațiile despre negare

Când o aplicație afirmă că oferă negare plauzibilă, întreabă:

1. Există un comutator pentru „modul-momeală”? Dacă da, negarea este cosmetică. Un examinator criminalistic poate găsi comutatorul.
2. Are aplicația o listă sau o bază de date a seifurilor? Dacă da, existența seifurilor poate fi dovedită.
3. Pot fi verificate încercările offline? Textul cifrat autentificat poate valida o cheie candidată fără un hash separat al parolei. Întreabă ce limitează costul încercărilor și dacă structura stocării oferă o amprentă a cheii mai ieftin de verificat.
4. Se schimbă spațiul ocupat în funcție de numărul de seifuri? Dacă da, analiza discului poate estima numărul de seifuri.
5. Poate aplicația enumera seifurile? Dacă aplicația îți poate afișa o listă a seifurilor, acea listă există pe dispozitiv și poate fi descoperită.

Întrebări frecvente

Este negarea plauzibilă legală?

Folosirea criptării cu negare plauzibilă este legală în majoritatea democrațiilor. Nicio lege nu interzice să ai pe dispozitiv date criptate a căror existență nu poate fi dovedită. În unele jurisdicții (Regatul Unit prin RIPA, Australia prin Assistance and Access Act), autoritățile pot obliga la dezvăluirea cheilor de criptare. Întrebarea juridică este dacă obligația de a dezvălui cheia unor date a căror existență nu poate fi dovedită poate fi aplicată. Acesta rămâne un domeniu de drept în dezvoltare.

Pot instrumentele criminalistice să detecteze negarea plauzibilă?

Un examinator care obține containerul aplicației Vaultaire poate detecta stocarea criptată. Fișierele rădăcină vault_index_*.bin stau într-un bazin de 64 sau mai multe, alături de fișiere de acoperire, iar paginile și zonele de stocare ale tuturor seifurilor stau într-un singur dosar comun, cu nume aleatorii. Numele fișierelor nu arată cărui seif îi aparține un fișier, dar numărul zonelor de stocare limitează câte seifuri conțin fișiere, așa că un examinator poate totuși estima câte seifuri ai. Fișierele nu dezvăluie numele seifurilor sau conținutul în clar. Prin urmare, designul actual ascunde seifurile de navigarea normală, nu de orice inspecție criminalistică a stocării.

Funcționează negarea plauzibilă împotriva unui stat hotărât?

AES-256-GCM oferă o limită solidă de criptare a conținutului când cheile, nonce-urile și implementarea sunt corecte. Asta nu face ca structura actuală a stocării Vaultaire să ofere negare în fața unui examinator al unui stat: un examinator poate totuși estima numărul local de seifuri, iar o compromitere activă poate viza modele, chei, previzualizări sau exporturi cât timp un seif este deschis. Funcția actuală separă ce deschid modelele diferite în interfață; nu promite că un examinator hotărât nu poate dovedi existența unor indexuri locale suplimentare.

Care este diferența dintre negarea plauzibilă și seifurile ascunse?

Seifurile ascunse sunt seifuri care nu sunt vizibile în interfața normală a aplicației. Negarea criptografică puternică este o proprietate separată: datele ascunse nu pot fi deosebite de stocarea neutilizată și umplută. În prezent, Vaultaire oferă prima proprietate. Formatul său actual de stocare îi permite totuși unui examinator cu acces la containerul aplicației să estimeze numărul de seifuri, deci nu o oferă pe a doua.

Pot folosi negarea plauzibilă cu backupurile în cloud?

Vaultaire scrie manifeste de backup criptate și fragmente de fișiere criptate și umplute în baza de date CloudKit privată a utilizatorului. Numele aleatorii ale înregistrărilor de date, umplerea fragmentelor la 10 MB și înregistrările-momeală reduc dezvăluirea directă a conținutului. Numărul de înregistrări, volumul total, momentele și tiparele de actualizare rămân metadate vizibile ale serviciului, deci backupul în cloud nu creează un depozit cu dimensiune constantă și cu negare teoretic-informațională.

Concluzie

Negarea puternică la nivelul stocării urmărește să împiedice un examinator să deosebească datele ascunse de spațiul liber umplut dintr-un depozit criptat static. Majoritatea aplicațiilor care afirmă că oferă această funcție au moduri-momeală cosmetice, cu indicatori de configurare care pot fi descoperiți. Definiția mai strictă cere un model de amenințare precis, niciun registru de seifuri care poate fi numărat, niciun indicator de configurare revelator, umplere stabilă și înregistrări criptate care nu arată ce sloturi sunt reale.

Vaultaire folosește modelele configurate ca să separe seifurile criptate și ține numele și conținutul seifurilor în afara interfeței blocate. Structura sa actuală a stocării permite totuși inspectării containerului aplicației să estimeze numărul de seifuri. Tratează asta ca pe o ascundere la nivel de interfață, susținută de criptare autentificată, nu ca pe o dovadă că nu există niciun seif suplimentar.