Trovärdig förnekbarhet i appar: Vad det är och varför det spelar roll
Trovärdig förnekbarhet 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 en korrekt vadderad krypterad butik skiljer sig från en live, komprometterad enhet, molntjänstmetadata eller kopior som finns på andra ställen. Detta är mer än en döljande funktion. Det beror på att kryptering, layout, utfyllnad och operativ design fungerar tillsammans.
Den här guiden förklarar hur trovärdig förnekbarhet 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örnekbarhet 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 den krypterade butiken ska inte kunna skilja dolt innehåll från oanvänt vadderat utrymme inom den angivna hotmodellen. Ingen app kan utöka det löftet till ett redan öppet valv, inspelad ingång, externa kopior eller varje form av enhetskompromiss.
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 rättsmedicinsk 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örnekbarhet 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 rättsmedicinsk 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 rättsmedicinsk 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 referenser avslöjar endast sin egen datamängd. Systemet har inte en separat lockbetsflagga som identifierar en legitimation som kamouflage. Ogiltiga autentiseringsuppgifter 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 rättsmedicinsk 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örnekbarhet är inte ett teoretiskt bekymmer. Det adresserar dokumenterade, återkommande verkliga situationer.
Gränsövergångar
Vid en gränsövergång kan en examinator inspektera en enhet och be om legitimation. Om en design faktiskt ger förnekelse på lagringsnivå, kan en autentisering 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 en-index-fil-per-valv-layout ger inte den garantin till en granskare med app-container-åtkomst.
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. En korrekt vadderad förnekbar butik 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örnekelse 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 är uppräckligt. Vaultaire lagrar en vault_index_<fingerprint>.bin fil per valv. Fingeravtrycket avslöjar inte mönstret eller valvets namn, men någon med app-container-åtkomst kan räkna indexfilerna. 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 lockbete. Den lokala appbehållaren reserverar inte en fast pool av verkliga och dummy-valvplatser, så totalt lagringsutrymme och indexantal kan avslöja strukturen.
Återhämtning 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 utan tvång och isolerar den enheten från synkronisering. Det raderar inte molnsäkerhetskopior, kopior på peer-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 med oskiljbara verkliga och dummy-slots skulle krävas för att dölja det lokala valvet från en offline-app-container-ögonblicksbild.
Hur man utvärderar förnekbarhetspåståenden
När en app hävdar trovärdig förnekbarhet, fråga:
- Finns det en "lockläge"-reglage? Om ja, är det kosmetiskt. En rättsmedicinsk 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örnekbarhet lagligt?
Att använda kryptering med trovärdig förnekbarhet ä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 rättsmedicinska verktyg detektera trovärdig förnekbarhet?
En granskare som skaffar Vaultaires appbehållare kan upptäcka krypterad lagring och räkna vault_index_*.bin filer. Filerna avslöjar inte valvnamn eller klartextinnehåll, men deras antal avslöjar antalet lokala krypterade index. Den nuvarande designen döljer därför valv från normal navigering, inte från varje kriminalteknisk inspektion.
Fungerar trovärdig förnekbarhet 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 en livekompromiss kan rikta in sig på mönster, nycklar, förhandsvisningar eller export medan ett valv är öppet. Den aktuella funktionen separerar vilka olika mönster som öppnas i gränssnittet; det lovar inte att en bestämd examinator inte kan bevisa att ytterligare lokala index finns.
Vad är skillnaden mellan trovärdig förnekbarhet och dolda valv?
Dolda valv är valv som inte är synliga i appens normala gränssnitt. Stark kryptografisk förnekelse är den separata egenskapen att dolda data inte kan särskiljas från oanvänd vadderade lagring. Vaultaire tillhandahåller för närvarande den första fastigheten. Dess en-index-fil-per-valv-format ger inte det andra mot en granskare med app-behållare-åtkomst.
Kan jag använda trovärdig förnekbarhet med molnsäkerhetskopior?
Vaultaire skriver krypterade säkerhetskopieringsmanifest och vadderade krypterade filbitar till användarens privata CloudKit databas. Slumpmässiga postnamn, enhetliga posttyper, 10 MB chunk padding och lockoutposter minskar direkt innehållsavslöjande. Antal rekord, total volym, timing och uppdateringsmönster förblir synliga tjänstemetadata, så molnsäkerhetskopiering skapar inte en konstant storlek, informationsteoretiskt förnekade butik.
Slutsatsen
Stark lagringsförnekelse syftar till att hålla en granskare från att skilja dolda data från vadderat ledigt utrymme i en statisk krypterad butik. De flesta appar som hävdar den här funktionen erbjuder kosmetiska lockbetslägen med upptäckbara konfigurationsflaggor. För att möta den starkare definitionen krävs en exakt hotmodell, inget räknebart valvregister, inga avslöjande konfigurationsflaggor, stabil utfyllnad och krypterade poster som inte avslöjar vilka slots 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 för app-behållareinspektion. 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.