Trovärdig förnekelse i appar: Vad det är och varför det spelar roll
Trovärdig förnekelse innebär att dolda datas existens inte kan bevisas.
Plausibel förnekelse i kryptering är en lagringsegenskap som låter en användare avslöja en datamängd utan att lämna en strukturell artefakt som bevisar att en annan datamängd finns. Anspråket måste namnge sin hotmodell: en statisk bild av ett korrekt utfyllt krypterat lager skiljer sig från en körande, komprometterad enhet, molntjänstmetadata eller kopior som finns på andra ställen. Detta är mer än en funktion för att gömma. Det kräver att kryptering, layout, utfyllnad och operativ design samverkar.
Den här guiden förklarar hur trovärdig förnekelse fungerar i appar, skillnaden mellan äkta kryptografisk förnekbarhet och kosmetiska locklägen, verkliga scenarier där det spelar roll och hur man utvärderar förnekbarhetspåståenden.
Vad trovärdig förnekelse betyder i kryptering
I vardagligt språk betyder plausibel förnekelse att du på ett trovärdigt sätt kan förneka något. I lagringskryptografi är det användbara målet smalare: en granskare av det krypterade lagret ska inte kunna skilja dolt innehåll från oanvänt utfyllt utrymme inom den angivna hotmodellen. Ingen app kan utöka det löftet till ett redan öppet valv, inspelad inmatning, externa kopior eller varje form av intrång i enheten.
Konceptet uppstod i diskkryptering. TrueCrypt (och dess efterträdare VeraCrypt) pionjärade den dolda volymen: en krypterad volym inom en annan krypterad volym. Ett lösenord avslöjar den yttre volymen med oskyldiga filer. Ett annat lösenord avslöjar den inre dolda volymen med känsliga filer. En kriminalteknisk undersökare kan inte avgöra om en dold volym finns eftersom det oanvända utrymmet i den yttre volymen är fyllt med slumpmässig data som är oskiljbar från krypterad data.
För appar innebär trovärdig förnekelse att olika inloggningsuppgifter (lösenord, PIN-koder, mönster) öppnar olika datauppsättningar, och det finns inga metadata, inget register, ingen konfigurationsflagga eller strukturell artefakt som avslöjar existensen av ytterligare datauppsättningar.
Äkta förnekbarhet vs. kosmetiska locklägen
Detta är den kritiska distinktionen som de flesta appar missar.
Kosmetiskt lockläge (Inte äkta förnekbarhet)
Många valvappar erbjuder ett "lock"- eller "falsk PIN"-läge. Du ställer in en sekundär PIN som öppnar ett separat utrymme med olika foton. Problemet: dessa appar lagrar vanligtvis en booleansk flagga, en databaspost eller en konfigurationsfil som indikerar att ett lockläge finns och är konfigurerat.
En kriminalteknisk undersökare som förstår appen kan hitta den flaggan. Att hitta ett konfigurerat lockläge bevisar att dolda data finns. Förnekbarheten är kosmetisk: den fungerar mot en tillfällig snokare men misslyckas under kriminalteknisk undersökning.
Tecken på kosmetisk förnekbarhet:
- Appen har en "lockläge"-reglage i inställningarna
- En konfigurationsfil lagrar om lockläge är aktiverat
- En databastabell listar valv-ID:n med typindikatorer (primär/lock)
- Appens lagringsstruktur förändras när lockläge aktiveras
- Avinstallering och ominstallering av appen avslöjar annat beteende när lockläge var konfigurerat
Äkta kryptografisk förnekbarhet
Äkta förnekbarhet är en arkitektonisk egenskap, inte en funktionsreglage. Den krypterade lagringen måste designas så att:
Alternativa inloggningsuppgifter avslöjar endast sin egen datamängd. Systemet har ingen separat lockbetesflagga som identifierar en inloggningsuppgift som kamouflage. Ogiltiga inloggningsuppgifter kan misslyckas, men det felet får inte avslöja om det finns en hemlig datamängd.
Inget valvregister finns. Appen kan inte räkna upp hur många valv som finns. Det finns inget antal, inget index, ingen lista med valv-ID:n. En kriminalteknisk undersökare som undersöker appens lagring hittar en odifferentierad pool av krypterad data.
Inga konfigurationsflaggor avslöjar dolda valv. Det finns ingen booleansk variabel, ingen databaspost, ingen preferencefil som indikerar om ytterligare valv finns.
Lagringen är utfylld. Det totala lagringsförbruket förändras inte baserat på antalet valv eller filer. Utan utfyllnad kan en undersökare uppskatta antalet valv från den totala krypterade datastorleken jämfört med det synliga innehållet.
Krypterad data är oskiljbar från slumpmässigt brus. Det finns inga filgränser, inga rubriker, inga strukturella markörer som avslöjar var ett valvs data slutar och ett annat börjar.
| Egenskap | Kosmetiskt lock | Äkta förnekbarhet |
|---|---|---|
| Separat data per inloggningsuppgift | Ja | Ja |
| Inget valvregister | Nej (databas spårar valv) | Ja |
| Inga konfigurationsflaggor | Nej (lockreglage lagras) | Ja |
| Lagringsutfyllnad | Sällan | Ja |
| Döljer alternativ lagring i en statisk bild | Nej | Ja, inom den angivna lagringshotmodellen |
| Arkitektonisk vs. funktion | Funktionsreglage | Arkitektonisk egenskap |
Verkliga scenarier där detta spelar roll
Trovärdig förnekelse är inte ett teoretiskt bekymmer. Det adresserar dokumenterade, återkommande verkliga situationer.
Gränsövergångar
Vid en gränsövergång kan en granskare inspektera en enhet och be om inloggningsuppgifter. Om en design faktiskt ger förnekbarhet på lagringsnivå kan en inloggningsuppgift avslöja en ofarlig datamängd medan en statisk bild saknar en strukturell markör som skiljer dolt innehåll från utfyllnad. Vaultaires nuvarande layout med en lagringskatalog per valv ger inte den garantin till en granskare med åtkomst till appcontainern.
Husligt våld och tvångsmässiga förhållanden
Någon i ett våldsamt förhållande kan behöva lagra bevis (foton av skador, hotfulla meddelanden, juridiska dokument) på en enhet som våldsutövaren övervakar. Om våldsutövaren kräver att se valvet kan användaren öppna ett valv med okänsligt innehåll. Utan äkta förnekbarhet skulle en "lockläge"-flagga i appens konfiguration avslöja existensen av dolt innehåll.
Enhetsstöld
En tjuv med teknisk kompetens kan försöka extrahera data från en stulen telefon. Ett korrekt utfyllt förnekbart lager syftar till att dölja hur många datamängder som upptar poolen, även om total tilldelning, enhetstillstånd, säkerhetskopior och driftspår fortfarande hör hemma i hotmodellen. Vaultaire krypterar för närvarande innehåll men visar ett räknebart lokalt index per konfigurerat valv.
Juridiskt och journalistiskt skydd
Journalister som skyddar källor, jurister som skyddar klientfiler och aktivister i auktoritära regimer möter scenarier där enhetsinnehåll kan tvingas fram. Äkta förnekbarhet ger ett trovärdigt försvar mot databeslag.
Vad Vaultaire implementerar idag
Vaultaire implementerar mönsterseparerad åtkomst och ett normalt gränssnitt utan någon synlig valvlista. Dessa egenskaper hjälper till vid vanlig appanvändning, men de uppfyller inte alla krav i checklistan för äkta förnekbarhet ovan.
Konfigurerade mönster öppnar separata krypterade valv. PBKDF2 härleder en valvnyckel från mönstret och ett salt för hela enheten. En konfigurerad nyckel autentiserar sitt krypterade index och packar upp en slumpmässig huvudnyckel. Ett okonfigurerat mönster visar ett tomt tillstånd snarare än ett "felaktigt mönster"-meddelande.
Det lokala formatet går att räkna upp. Rotfilerna vault_index_<fingerprint>.bin ligger i en pool om 64 med täckfiler, men varje valv har en egen lagringskatalog. Fingeravtrycket avslöjar inte mönstret eller valvets namn, men någon med åtkomst till appcontainern kan räkna lagringskatalogerna. AES-GCM-autentisering och det deterministiska filnamnet ger också ett offlinetest för kandidatvalvnycklar.
Lokal lagring är inte av konstant storlek. Filinnehåll och metadata är krypterade, och molnsäkerhetskopior använder storleksutfyllnad och lockbetesposter. Den lokala appcontainern reserverar inte en fast pool av verkliga och dummy-valvplatser, så totalt lagringsutrymme och indexantal kan avslöja strukturen.
Återställnings- och tvångstillstånd finns. Vaultaire håller återställningsinformation i en AES-GCM-krypterad Keychain-databas. Tvångsläge tar bort lokala index och återställningsmappningar för valv som inte är tvångsvalv och isolerar den enheten från synkronisering. Det raderar inte molnsäkerhetskopior, kopior på andra enheter eller varje delad krypterad blob, och slutförandetiden beror på det lokala arbetet som utförs.
Vaultaire tillhandahåller därför gränssnittsuppdelning och krypterad lagring, inte informationsteoretiskt bevis på att inget ytterligare valv existerar. En framtida katalog med fast kapacitet och oskiljbara verkliga platser och dummyplatser skulle krävas för att dölja antalet lokala valv i en offlineögonblicksbild av appcontainern.
Hur man utvärderar förnekbarhetspåståenden
När en app hävdar trovärdig förnekelse, fråga:
- Finns det en "lockläge"-reglage? Om ja, är det kosmetiskt. En kriminalteknisk undersökare kan hitta reglaget.
- Har appen en valvlista eller databas? Om ja är valvexistens bevisbar.
- Kan gissningar verifieras offline? Autentiserad chiffertext kan validera en kandidatnyckel utan en separat lösenordshash. Fråga vad som begränsar gissningskostnaden och om lagringslayouten erbjuder något billigare nyckelfingeravtryck.
- Förändras lagringsförbrukning med valvantal? Om ja kan diskanalys uppskatta valvantal.
- Kan appen räkna upp valv? Om appen kan visa en lista över dina valv finns den listan på enheten och är möjlig att hitta.
Vanliga frågor
Är trovärdig förnekelse lagligt?
Att använda kryptering med trovärdig förnekelse är lagligt i de flesta demokratier. Det finns ingen lag mot att ha krypterad data på din enhet vars existens inte kan bevisas. I vissa jurisdiktioner (UK under RIPA, Australien under Assistance and Access Act) kan myndigheter tvinga fram upplysning av krypteringsnycklar. Den juridiska frågan är om tvingande upplysning av en nyckel till data vars existens inte kan bevisas är verkställbar. Detta är fortfarande ett juridiskt område under utveckling.
Kan kriminaltekniska verktyg detektera trovärdig förnekelse?
En granskare som skaffar Vaultaires appcontainer kan upptäcka krypterad lagring och räkna lagringskatalogerna per valv. Rotfilerna vault_index_*.bin ligger i en pool om 64 med täckfiler, men katalogerna visar vilka som är äkta. De avslöjar inte valvnamn eller klartextinnehåll, men deras antal avslöjar antalet lokala valv. Den nuvarande designen döljer därför valv från normal navigering, inte från varje kriminalteknisk inspektion.
Fungerar trovärdig förnekelse mot en beslutad nationalstat?
AES-256-GCM ger en stark innehållskrypteringsgräns när nycklar, nonces och implementering är sunda. Det gör inte Vaultaires nuvarande lagringslayout förnekbar för en nationalstatsgranskare: det lokala indexantalet förblir synligt, och ett intrång i en körande enhet kan rikta in sig på mönster, nycklar, förhandsvisningar eller export medan ett valv är öppet. Den nuvarande funktionen skiljer åt vad olika mönster öppnar i gränssnittet; den lovar inte att en målmedveten granskare inte kan bevisa att ytterligare lokala index finns.
Vad är skillnaden mellan trovärdig förnekelse och dolda valv?
Dolda valv är valv som inte är synliga i appens normala gränssnitt. Stark kryptografisk förnekbarhet är den separata egenskapen att dolda data inte kan särskiljas från oanvänd utfylld lagring. Vaultaire tillhandahåller för närvarande den första egenskapen. Dess format med en lagringskatalog per valv ger inte det andra mot en granskare med åtkomst till appcontainern.
Kan jag använda trovärdig förnekelse med molnsäkerhetskopior?
Vaultaire skriver krypterade säkerhetskopieringsmanifest och utfyllda krypterade filbitar till användarens privata CloudKit-databas. Slumpmässiga postnamn, enhetliga posttyper, 10 MB utfyllnad per segment och lockbetesposter minskar direkt avslöjande av innehåll. Antal poster, total volym, tidpunkter och uppdateringsmönster förblir synliga tjänstemetadata, så molnsäkerhetskopieringen skapar inte ett informationsteoretiskt förnekbart lager av konstant storlek.
Slutsatsen
Stark förnekbarhet i lagringen syftar till att hindra en granskare från att skilja dolda data från utfyllt ledigt utrymme i ett statiskt krypterat lager. De flesta appar som hävdar den här funktionen erbjuder kosmetiska lockbetslägen med upptäckbara konfigurationsflaggor. Att uppfylla den starkare definitionen kräver en exakt hotmodell, inget räknebart valvregister, inga avslöjande konfigurationsflaggor, stabil utfyllnad och krypterade poster som inte avslöjar vilka platser som är verkliga.
Vaultaire använder konfigurerade mönster för att separera krypterade valv och håller valvnamn och innehåll borta från det låsta gränssnittet. Dess nuvarande lagringslayout exponerar fortfarande ett krypterat indexantal vid inspektion av appcontainern. Behandla det som döljande på gränssnittsnivå med stöd av autentiserad kryptering, inte som ett bevis på att det inte finns något extra valv.