Plausibel benægtbarhed i apps: Hvad det er, og hvorfor det er vigtigt

Plausibel benægtbarhed betyder, at eksistensen af skjulte data ikke kan bevises.

Plausibel benægtelse i kryptering er en lageregenskab, der lader en bruger afsløre et datasæt uden at efterlade en strukturel artefakt, der beviser, at der findes et andet datasæt. Påstanden skal navngive dens trusselsmodel: Et statisk billede af en korrekt polstret krypteret butik er forskellig fra en live, kompromitteret enhed, cloud-tjeneste-metadata eller kopier, der opbevares andre steder. Dette er mere end en skjulefunktion. Det afhænger af krypteringen, layoutet, polstringen og det operationelle design, der arbejder sammen.

Denne vejledning forklarer, hvordan plausibel benægtbarhed i apps fungerer, hvad forskellen er på ægte kryptografisk benægtbarhed og kosmetiske decoy-regimer, virkelige scenarier hvor det er vigtigt, og hvordan man vurderer benægtbarhedspåstande.

Hvad plausibel benægtbarhed i kryptering betyder

I dagligsproget betyder plausibel benægtelse, at du troværdigt kan benægte noget. I lagerkryptografi er det nyttige mål snævrere: En eksaminator af det krypterede lager bør ikke være i stand til at skelne skjult indhold fra ubrugt polstret plads inden for den angivne trusselmodel. Ingen app kan udvide det løfte til en allerede åben boks, optaget input, eksterne kopier eller enhver form for kompromittering af enheden.

Konceptet opstod inden for diskkryptering. TrueCrypt (og dets efterfølger VeraCrypt) introducerede det skjulte volumen: et krypteret volumen inden i et andet krypteret volumen. Ét kodeord afslører det ydre volumen med uskadeligt indhold. Et andet kodeord afslører det indre skjulte volumen med følsomme filer. En retsmedicinsk ekspert kan ikke fastslå, om det skjulte volumen eksisterer, fordi ubenyttet plads i det ydre volumen er fyldt med tilfældige data, uadskillelige fra krypterede data.

For apps betyder plausibel benægtbarhed, at forskellige legitimationsoplysninger (adgangskoder, PIN-koder, mønstre) åbner forskellige datasæt, og der er ingen metadata, intet register, intet konfigurationsflag og ingen strukturel artefakt der afslører eksistensen af yderligere datasæt.

Ægte benægtbarhed vs. kosmetisk decoy-regime

Dette er den afgørende forskel, som de fleste apps håndterer forkert.

Kosmetisk decoy-regime (ikke ægte benægtbarhed)

Mange hvælvingsapps tilbyder en "decoy"- eller "falsk PIN"-funktion. Du opsætter en sekundær PIN der åbner et separat rum med andre fotos. Problemet: disse apps gemmer typisk et boolsk flag, en databasepost eller en konfigurationsfil der angiver, at decoy-regimet eksisterer og er konfigureret.

En retsmedicinsk ekspert der kender appen finder dette flag. At finde et konfigureret decoy-regime beviser, at skjulte data eksisterer. Benægtbarheden er kosmetisk -- den virker mod en overfladisk nysgerrig person, men fejler ved retsmedicinsk undersøgelse.

Tegn på kosmetisk benægtbarhed:

• Appen har en "decoy-regime"-kontakt i indstillinger
• En konfigurationsfil gemmer, om decoy-regimet er slået til
• En databasetabel indeholder en liste over hvælving-ID'er med typeindikatorer (primær/decoy)
• Appens lagerstruktur ændres, når decoy-regimet er slået til
• Afinstallering og geninstallering af appen afslører forskellig adfærd, hvis decoy-regimet var konfigureret

Ægte kryptografisk benægtbarhed

Ægte benægtbarhed er en arkitektonisk egenskab, ikke en funktionskontakt. Det krypterede lager skal designes så:

1. Alternative legitimationsoplysninger afslører kun deres eget datasæt. Systemet har ikke et særskilt lokkeflag, der identificerer en legitimation som camouflage. Ugyldige legitimationsoplysninger kan mislykkes, men den fejl må ikke afsløre, om der eksisterer et ikke-offentliggjort datasæt.

2. Der er intet hvælvingsregister. Appen kan ikke beregne, hvor mange hvælvinger der eksisterer. Der er ingen tæller, intet indeks og ingen liste over hvælving-ID'er. En retsmedicinsk ekspert der undersøger appens lager finder en udifferentieret pulje af krypterede data.

3. Ingen konfigurationsflags afslører skjulte hvælvinger. Der er ingen boolsk, ingen databasepost og ingen præferencefil der angiver, om yderligere hvælvinger eksisterer.

4. Lageret er fyldt med polstringsdata. Den samlede lagerkapacitet ændres ikke med antallet af hvælvinger eller filer. Uden polstring kunne en ekspert anslå antallet af hvælvinger fra den samlede mængde krypterede data sammenlignet med synligt indhold.

5. Krypterede data er uadskillelige fra tilfældig støj. Der er ingen filgrænser, overskrifter eller strukturelle markører der afslører, hvor én hvælvings data slutter og en anden begynder.

Virkelige scenarier hvor det er vigtigt

Plausibel benægtbarhed er ikke en teoretisk sag. Det løser dokumenterede, tilbagevendende virkelige situationer.

Grænseovergange

Ved en grænseovergang kan en eksaminator inspicere en enhed og bede om legitimationsoplysninger. Hvis et design rent faktisk giver fornægtelse på lagerniveau, kan en legitimation afsløre et uskadeligt datasæt, mens et statisk billede mangler en strukturel markør, der adskiller skjult indhold fra polstring. Vaultaires nuværende layout med én indeks-fil pr. boks giver ikke denne garanti til en eksaminator med app-container-adgang.

Partnervold og tvangssituationer

En person i et voldeligt forhold kan have brug for at gemme beviser (fotos af skader, truende beskeder, juridiske dokumenter) på en enhed, som voldsudøveren overvåger. Kræver voldsudøveren adgang til hvælvingen, kan brugeren åbne en hvælving med ikke-følsomt indhold. Uden ægte benægtbarhed ville et "decoy-regime"-flag i appens konfiguration afsløre eksistensen af skjult indhold.

Enhedstyveri

En tyv med tekniske færdigheder kan forsøge at udtrække data fra en stjålet telefon. Et korrekt polstret benægtbart lager har til formål at skjule, hvor mange datasæt der optager puljen, selvom total allokering, enhedstilstand, sikkerhedskopier og operationelle spor stadig hører hjemme i trusselsmodellen. Vaultaire krypterer i øjeblikket indholdet, men afslører ét tælleligt lokalt indeks pr. konfigureret boks.

Juridisk og journalistisk beskyttelse

Journalister der beskytter kilder, advokater der beskytter klientfiler og aktivister i autoritære regimer står over for situationer, hvor enhedsindhold kan tvinges frem. Ægte benægtbarhed giver et troværdigt forsvar mod datakonfiskation.

Hvad Vaultaire implementerer i dag

Vaultaire implementerer mønstersepareret adgang og en normal grænseflade uden nogen synlig vault-liste. Disse egenskaber hjælper under almindelig appbrug, men de opfylder ikke alle krav i tjeklisten for ægte benægtelse ovenfor.

Konfigurerede mønstre åbner separate krypterede hvælvinger. PBKDF2 udleder en hvælvnøgle fra mønsteret og et salt for hele enheden. En konfigureret nøgle autentificerer sit krypterede indeks og udpakker en tilfældig hovednøgle. Et ukonfigureret mønster viser en tom tilstand i stedet for en "forkert mønster"-meddelelse.

Det lokale format er talværdigt. Vaultaire gemmer en vault_index_<fingerprint>.bin fil pr. boks. Fingeraftrykket afslører ikke mønsteret eller vault-navnet, men en person med app-container-adgang kan tælle indeksfilerne. AES-GCM autentificering og det deterministiske filnavn giver også en offline test for kandidat hvælvingsnøgler.

Lokal lagring er ikke konstant størrelse. Filindhold og metadata er krypteret, og skybackup-stykker bruger størrelsesudfyldning og lokkeposter. Den lokale app-beholder reserverer ikke en fast pulje af reelle og dummy vault-slots, så samlet lagerplads og indeksantal kan afsløre struktur.

Genopretning og tvangstilstand eksisterer. Vaultaire opbevarer gendannelsesoplysninger i en AES-GCM krypteret Keychain database. Tvangstilstand fjerner lokale indekser og gendannelsestilknytninger for ikke-tvangshvælvinger og isolerer denne enhed fra synkronisering. Den sletter ikke cloud-sikkerhedskopier, kopier på peer-enheder eller hver delt krypteret blob, og færdiggørelsestiden afhænger af det lokale arbejde, der udføres.

Vaultaire giver derfor grænsefladeopdeling og krypteret lagring, ikke informationsteoretisk bevis på, at der ikke eksisterer yderligere hvælving. Et fremtidigt katalog med fast kapacitet med ikke-adskillelige reelle og dummy-slots ville være påkrævet for at skjule det lokale vault-antal fra et offline app-container-øjebliksbillede.

Sådan vurderer du benægtbarhedspåstande

Hævder en app at have plausibel benægtbarhed, spørg:

1. Har appen en "decoy-regime"-kontakt? Hvis ja, er det kosmetisk. En retsmedicinsk ekspert finder kontakten.
2. Har appen en hvælvingliste eller database? Hvis ja, kan hvælvingernes eksistens bevises.
3. Kan gæt bekræftes offline? Autentificeret chiffertekst kan validere en kandidatnøgle uden en separat adgangskode-hash. Spørg, hvad der begrænser gætteomkostninger, og om lagerlayoutet tilbyder et billigere nøglefingeraftryk.
4. Ændres lagerforbruget med antallet af hvælvinger? Hvis ja, kan diskanalyse anslå antallet af hvælvinger.
5. Kan appen beregne hvælvinger? Kan appen vise en liste over dine hvælvinger, eksisterer denne liste på enheden og er opdagelig.

Ofte stillede spørgsmål

Er plausibel benægtbarhed lovlig?

Brug af kryptering med plausibel benægtbarhed er lovlig i de fleste demokratiske lande. Der er ingen lov der forbyder at have krypterede data på din enhed hvis eksistens ikke kan bevises. I visse jurisdiktioner kan myndigheder kræve udlevering af krypteringsnøgler (f.eks. UK under RIPA-loven eller Australien under Assistance and Access Act). Det juridiske spørgsmål om, hvorvidt nøgleudlevering kan håndhæves for data hvis eksistens ikke kan bevises, forbliver åbent og fortsætter med at udvikle sig.

Kan retsmedicinske værktøjer opdage plausibel benægtbarhed?

En eksaminator, der får Vaultaires app-beholder, kan registrere krypteret lagring og tælle vault_index_*.bin filer. Filerne afslører ikke hvælvingsnavne eller almindeligt tekstindhold, men deres optælling afslører antallet af lokale krypterede indekser. Det nuværende design skjuler derfor hvælvinger fra normal navigation, ikke fra enhver retsmedicinsk lagerinspektion.

Virker plausibel benægtbarhed mod en beslutsom statsaktør?

AES-256-GCM giver en stærk indholdskrypteringsgrænse, når nøgler, nonces og implementering er sunde. Det gør ikke, at Vaultaires nuværende lagerlayout kan nægtes for en nationalstatsgransker: det lokale indekstal forbliver synligt, og et live-kompromis kan målrette mod mønstre, nøgler, forhåndsvisninger eller eksport, mens en boks er åben. Den aktuelle funktion adskiller, hvilke forskellige mønstre, der åbner i grænsefladen; det lover ikke, at en beslutsom eksaminator ikke kan bevise, at der findes yderligere lokale indekser.

Hvad er forskellen på plausibel benægtbarhed og skjulte hvælvinger?

Skjulte hvælvinger er hvælvinger, der ikke er synlige i appens normale grænseflade. Stærk kryptografisk fornægtelse er den særskilte egenskab, at skjulte data ikke kan skelnes fra ubrugt polstret lager. Vaultaire leverer i øjeblikket den første ejendom. Dens one-index-file-per-vault-format giver ikke den anden mod en eksaminator med app-container-adgang.

Kan plausibel benægtbarhed bruges med cloud-backups?

Vaultaire skriver krypterede sikkerhedskopieringsmanifester og polstrede krypterede filbidder til brugerens private CloudKit database. Tilfældige postnavne, ensartede registreringstyper, 10 MB chunk-udfyldning og lokkeposter reducerer direkte indholdsoffentliggørelse. Registreringsantal, samlet volumen, timing og opdateringsmønstre forbliver synlige servicemetadata, så cloud-backup skaber ikke en konstant størrelse, informationsteoretisk benægtelig butik.

Konklusion

Stærk lagerfornægtelse sigter mod at forhindre en eksaminator i at skelne skjulte data fra polstret ledig plads i et statisk krypteret lager. De fleste apps, der hævder denne funktion, tilbyder kosmetiske lokketilstande med synlige konfigurationsflag. At opfylde den stærkere definition kræver en præcis trusselsmodel, intet tælleligt vault-register, ingen afslørende konfigurationsflag, stabil polstring og krypterede registreringer, der ikke afslører, hvilke slots der er rigtige.

Vaultaire bruger konfigurerede mønstre til at adskille krypterede hvælvinger og holder hvælvingsnavne og indhold ude af den låste grænseflade. Dets nuværende lagerlayout udsætter stadig et krypteret indekstal for app-containerinspektion. Behandl det som skjul på grænsefladeniveau understøttet af autentificeret kryptering, ikke som bevis på, at der ikke eksisterer nogen ekstra hvælving.