Aannemelijke Ontkenning in Apps: Wat het Is en Waarom het Ertoe Doet
Aannemelijke ontkenning betekent dat het bestaan van verborgen data niet bewezen kan worden.
Plausibele ontkenning bij encryptie is een opslageigenschap waarmee een gebruiker één dataset kan vrijgeven zonder een structureel artefact achter te laten dat bewijst dat er een andere dataset bestaat. De claim moet het dreigingsmodel benoemen: een statisch beeld van een goed opgevulde gecodeerde winkel is anders dan een live, gecompromitteerd apparaat, metagegevens van clouddiensten of kopieën die elders worden bewaard. Dit is meer dan een verbergfunctie. Het hangt af van de samenwerking tussen de codering, lay-out, opvulling en operationeel ontwerp.
Deze handleiding legt uit hoe aannemelijke ontkenning werkt in apps, het verschil tussen echte cryptografische ontkenning en cosmetische lokmodussen, praktijkscenario's waarbij het ertoe doet, en hoe je ontkenbaarheidsbeweringen kunt evalueren.
Wat Aannemelijke Ontkenning Betekent in Versleuteling
In alledaagse taal betekent plausibele ontkenning dat je op geloofwaardige wijze iets kunt ontkennen. Bij opslagcryptografie is het bruikbare doel beperkter: een onderzoeker van de gecodeerde opslag zou binnen het genoemde dreigingsmodel geen onderscheid moeten kunnen maken tussen verborgen inhoud en ongebruikte opgevulde ruimte. Geen enkele app kan die belofte uitbreiden naar een reeds geopende kluis, opgenomen invoer, externe kopieën of elke vorm van apparaatcompromis.
Het concept is ontstaan in schijfversleuteling. TrueCrypt (en zijn opvolger VeraCrypt) pionierden het verborgen volume: een versleuteld volume binnen een ander versleuteld volume. Eén wachtwoord onthult het buitenste volume met onschuldige bestanden. Een ander wachtwoord onthult het binnenste verborgen volume met gevoelige bestanden. Een forensisch onderzoeker kan niet bepalen of een verborgen volume bestaat, omdat de ongebruikte ruimte in het buitenste volume gevuld is met willekeurige data die niet te onderscheiden is van versleutelde data.
Voor apps betekent aannemelijke ontkenning dat verschillende referenties (wachtwoorden, PIN-codes, patronen) verschillende datasets openen, en er is geen metadata, register, configuratieflag of structureel artefact dat het bestaan van extra datasets onthult.
Echte Ontkenning vs. Cosmetische Lokmodussen
Dit is het cruciale onderscheid dat de meeste apps fout maken.
Cosmetische Lokmodus (Geen Echte Ontkenning)
Veel kluis-apps bieden een "lokmodus" of "nep-PIN"-functie. Je stelt een secundaire PIN in die een aparte ruimte opent met andere foto's. Het probleem: deze apps slaan typisch een booleaanse vlag, een database-invoer, of een configuratiebestand op dat aangeeft dat een lokmodus bestaat en geconfigureerd is.
Een forensisch onderzoeker die de app begrijpt kan deze vlag vinden. Het vinden van een geconfigureerde lokmodus bewijst dat verborgen data bestaat. De ontkenning is cosmetisch -- het werkt tegen terloops besnuffelen maar faalt onder forensisch onderzoek.
Tekenen van cosmetische ontkenning:
- De app heeft een "lokmodus"-schakelaar in instellingen
- Een configuratiebestand slaat op of lokmodus is ingeschakeld
- Een databasetabel somt kluis-ID's op met type-indicatoren (primair/lokmodus)
- De opslagstructuur van de app verandert wanneer lokmodus is ingeschakeld
- De app verwijderen en opnieuw installeren onthult ander gedrag wanneer lokmodus was geconfigureerd
Echte Cryptografische Ontkenning
Echte ontkenning is een architecturale eigenschap, geen functieschakelaar. De versleutelde opslag moet zo ontworpen zijn dat:
Alternatieve inloggegevens onthullen alleen hun eigen dataset. Het systeem houdt geen aparte lokvlag bij die één identificatie als camouflage identificeert. Ongeldige inloggegevens kunnen mislukken, maar dat falen mag niet onthullen of er een niet-openbaar gemaakte dataset bestaat.
Er bestaat geen kluisregister. De app kan niet opsommen hoeveel kluizen er bestaan. Er is geen teller, geen index, geen lijst van kluis-ID's. Een forensisch onderzoeker die de opslag van de app onderzoekt vindt een ongedifferentieerde pool van versleutelde data.
Geen configuratieflags onthullen verborgen kluizen. Er is geen booleaan, geen database-invoer, geen voorkeurenbestand dat aangeeft of extra kluizen bestaan.
Opslag is geopvuld. De totale verbruikte opslag verandert niet op basis van het aantal kluizen of bestanden. Zonder opvulling kan een onderzoeker het aantal kluizen schatten uit de totale versleutelde dataomvang versus de zichtbare inhoud.
Versleutelde data is niet te onderscheiden van willekeurige ruis. Er zijn geen bestandsgrenzen, geen headers, geen structurele markers die onthullen waar de data van één kluis eindigt en die van een andere begint.
| Eigenschap | Cosmetische Lokmodus | Echte Ontkenning |
|---|---|---|
| Aparte data per referentie | Ja | Ja |
| Geen kluisregister | Nee (database bijhoudt kluizen) | Ja |
| Geen configuratieflags | Nee (lokmodus-schakelaar opgeslagen) | Ja |
| Opslagopvulling | Zelden | Ja |
| Verbergt alternatieve opslag in een statisch beeld | Nee | Ja, binnen het genoemde opslagbedreigingsmodel |
| Architecturaal vs. functie | Functieschakelaar | Architecturale eigenschap |
Praktijkscenario's Waarbij Dit Ertoe Doet
Aannemelijke ontkenning is geen theoretische zorg. Het adresseert gedocumenteerde, terugkerende praktijksituaties.
Grensovergangen
Bij een grensovergang kan een examinator een apparaat inspecteren en om legitimatie vragen. Als een ontwerp daadwerkelijk ontkenning op opslagniveau biedt, kan één referentie een onschadelijke dataset onthullen, terwijl een statische afbeelding een structurele markering mist die verborgen inhoud onderscheidt van opvulling. De huidige indeling van Vaultaire met één indexbestand per kluis biedt die garantie niet aan een examinator met toegang tot app-containers.
Huiselijk Geweld en Dwingende Relaties
Iemand in een mishandelende relatie moet misschien bewijs opslaan (foto's van verwondingen, bedreigende berichten, juridische documenten) op een apparaat dat de mishandelaar controleert. Als de mishandelaar eist de kluis te zien, kan de gebruiker een kluis openen met niet-gevoelige inhoud. Zonder echte ontkenning zou een "lokmodus"-vlag in de app-configuratie het bestaan van verborgen inhoud onthullen.
Apparaatdiefstal
Een dief met technische vaardigheden kan proberen gegevens uit een gestolen telefoon te halen. Een goed opgevulde ontkenningsopslag heeft tot doel te verbergen hoeveel datasets de pool in beslag nemen, hoewel de totale toewijzing, apparaatstatus, back-ups en operationele sporen nog steeds thuishoren in het dreigingsmodel. Vaultaire codeert momenteel de inhoud, maar stelt één telbare lokale index per geconfigureerde kluis beschikbaar.
Juridische en Journalistieke Bescherming
Journalisten die bronnen beschermen, advocaten die cliëntbestanden beschermen, en activisten in autoritaire regimes staan voor scenario's waarbij apparaatinhoud afgedwongen kan worden. Echte ontkenning biedt een geloofwaardige verdediging tegen gegevensbeslag.
Wat Vaultaire vandaag de dag implementeert
Vaultaire implementeert patroongescheiden toegang en een normale interface zonder zichtbare kluislijst. Deze eigenschappen helpen bij gewoon app-gebruik, maar voldoen niet aan alle vereisten in de bovenstaande checklist voor echte ontkenning.
Geconfigureerde patronen openen afzonderlijke gecodeerde kluizen. PBKDF2 leidt een kluissleutel af van het patroon en een zout voor het hele apparaat. Een geconfigureerde sleutel verifieert de gecodeerde index en pakt een willekeurige hoofdsleutel uit. Een niet-geconfigureerd patroon geeft een lege status weer in plaats van een bericht 'onjuist patroon'.
Het lokale formaat is opsombaar. Vaultaire bewaart er één vault_index_<fingerprint>.bin bestand per kluis. De vingerafdruk onthult het patroon of de kluisnaam niet, maar iemand met toegang tot de app-container kan de indexbestanden tellen. AES-GCM authenticatie en de deterministische bestandsnaam bieden ook een offline test voor kandidaat-kluissleutels.
Lokale opslag heeft geen constante grootte. Bestandsinhoud en metagegevens worden gecodeerd, en back-upfragmenten in de cloud maken gebruik van grootte-opvulling en lokrecords. De lokale app-container reserveert geen vaste pool van echte en dummy-kluisslots, dus de totale opslag en het indexaantal kunnen structuur blootleggen.
Er bestaat een herstel- en dwangtoestand. Vaultaire bewaart herstelinformatie in een AES-GCM gecodeerd Keychain database. Dwangmodus verwijdert lokale indexen en hersteltoewijzingen voor kluizen zonder dwang en isoleert dat apparaat van synchronisatie. Er worden geen cloudback-ups, kopieën op peer-apparaten of elke gedeelde gecodeerde blob gewist, en de voltooiingstijd is afhankelijk van het lokale werk dat wordt uitgevoerd.
Vaultaire biedt daarom interface-compartimentering en gecodeerde opslag, en geen informatietheoretisch bewijs dat er geen extra kluis bestaat. Er zou een toekomstige catalogus met vaste capaciteit nodig zijn, met niet van elkaar te onderscheiden echte en dummy-slots, om het aantal lokale kluizen te verbergen voor een momentopname van een offline app-container.
Hoe Ontkenbaarheidsbeweringen te Evalueren
Wanneer een app aannemelijke ontkenning beweert, vraag dan:
- Is er een "lokmodus"-schakelaar? Als ja, is het cosmetisch. Een forensisch onderzoeker kan de schakelaar vinden.
- Heeft de app een kluislijst of database? Als ja, is kluisbestaan bewijsbaar.
- Kunnen gissingen offline worden geverifieerd? Geauthenticeerde cijfertekst kan een kandidaatsleutel valideren zonder een afzonderlijke wachtwoordhash. Vraag wat de gokkosten beperkt en of de opslagindeling een goedkopere sleutelvingerafdruk biedt.
- Verandert opslagverbruik met het aantal kluizen? Als ja, kan schijfanalyse het aantal kluizen schatten.
- Kan de app kluizen opsommen? Als de app je een lijst van je kluizen kan tonen, bestaat die lijst op het apparaat en is deze vindbaar.
Veelgestelde Vragen
Is aannemelijke ontkenning legaal?
Het gebruik van versleuteling met aannemelijke ontkenning is legaal in de meeste democratieën. Er is geen wet tegen het hebben van versleutelde data op je apparaat waarvan het bestaan niet bewezen kan worden. In sommige jurisdicties (VK onder RIPA, Australië onder de Assistance and Access Act) kunnen autoriteiten onthulling van versleutelingssleutels afdwingen. De juridische vraag is of het afdwingen van onthulling van een sleutel voor data waarvan het bestaan niet bewezen kan worden afdwingbaar is. Dit blijft een zich ontwikkelend rechtsgebied.
Kunnen forensische tools aannemelijke ontkenning detecteren?
Een onderzoeker die de app-container van Vaultaire verkrijgt, kan gecodeerde opslag detecteren en tellen vault_index_*.bin bestanden. De bestanden onthullen geen kluisnamen of platte tekstinhoud, maar hun telling onthult het aantal lokaal gecodeerde indexen. Het huidige ontwerp verbergt daarom kluizen voor normale navigatie, en niet voor elke forensische opslaginspectie.
Werkt aannemelijke ontkenning tegen een vastberaden natiestaat?
AES-256-GCM biedt een sterke grens voor inhoudscodering wanneer sleutels, nonces en implementatie in orde zijn. Dat maakt de huidige opslagindeling van Vaultaire niet ontkenbaar voor een onderzoeker van een natiestaat: de lokale indextelling blijft zichtbaar en een live compromis kan zich richten op patronen, sleutels, previews of exports terwijl een kluis open is. De huidige functie scheidt welke verschillende patronen in de interface worden geopend; het belooft niet dat een vastberaden onderzoeker niet kan bewijzen dat er aanvullende lokale indexen bestaan.
Wat is het verschil tussen aannemelijke ontkenning en verborgen kluizen?
Verborgen kluizen zijn kluizen die niet zichtbaar zijn in de normale interface van de app. Sterke cryptografische ontkenning is de aparte eigenschap dat verborgen gegevens niet kunnen worden onderscheiden van ongebruikte opgevulde opslag. Vaultaire biedt momenteel het eerste pand aan. Het formaat van één indexbestand per kluis biedt niet de tweede tegen een examinator met toegang tot app-containers.
Kan ik aannemelijke ontkenning gebruiken met cloud-back-ups?
Vaultaire schrijft gecodeerde back-upmanifesten en opgevulde gecodeerde bestandsfragmenten naar de privégegevens van de gebruiker CloudKit database. Willekeurige recordnamen, uniforme recordtypen, opvulling van 10 MB chunks en lokrecords verminderen de directe openbaarmaking van inhoud. Het aantal records, het totale volume, de timing en updatepatronen blijven zichtbare metagegevens van de service, zodat back-up in de cloud geen opslag van constante grootte creëert die in theorie ontkenbaar is.
Conclusie
Sterke opslagontkenning heeft tot doel te voorkomen dat een onderzoeker verborgen gegevens onderscheidt van opgevulde vrije ruimte in een statisch gecodeerde opslag. De meeste apps die deze functie claimen, bieden cosmetische lokmodi met detecteerbare configuratievlaggen. Om aan de strengere definitie te voldoen, is een nauwkeurig dreigingsmodel vereist, geen telbaar kluisregister, geen onthullende configuratievlaggen, stabiele opvulling en gecodeerde records die niet onthullen welke slots echt zijn.
Vaultaire gebruikt geconfigureerde patronen om gecodeerde kluizen te scheiden en houdt kluisnamen en inhoud buiten de vergrendelde interface. De huidige opslagindeling stelt nog steeds een gecodeerde indextelling bloot aan inspectie van app-containers. Beschouw dit als een verhulling op interfaceniveau, ondersteund door geverifieerde encryptie, en niet als bewijs dat er geen extra kluis bestaat.