Beveiligingsarchitectuur: de volledige technische stapel

Vaultaire gebruikt AES-256-GCM voor geauthenticeerde versleuteling van kluisindexen, omhulde sleutels, bestandsheaders, inhoud, miniaturen en metadata. PBKDF2-HMAC-SHA512 leidt een lokale kluissleutel af van het patroon en een salt per apparaat uit de sleutelhanger. Die kluissleutel omhult een aparte willekeurige 256-bits hoofdsleutel, waarmee CryptoKit de bestanden in het app-proces versleutelt.

De cryptografische stapel

Vaultaire gebruikt verschillende cryptografische mechanismen die samenwerken, elk gekozen voor een specifieke taak. PBKDF2 maakt van een patroon of zin een kluis- of herstelsleutel. AES-256-GCM beschermt indexen, sleutelomhulsels, metadata, miniaturen en bestandsinhoud. Een willekeurige hoofdsleutel houdt de langdurige bestandsversleuteling los van een patroon dat kan veranderen. De sleutelhanger en iOS-gegevensbescherming beschermen de apparaatgebonden salt en herstelrecords terwijl het apparaat vergrendeld is. Er is geen ontsleutelingssleutel bij de aanbieder die de ontwikkelaar standaard toegang geeft tot de leesbare kluisinhoud.

Dit is geen complexiteit om de complexiteit. Elke laag richt zich op een ander aanvalsoppervlak. AES-256-GCM combineert vertrouwelijkheid met authenticatie, zodat gewijzigde versleutelde tekst de verificatie niet doorstaat. PBKDF2 maakt het testen van elk patroon of elke zin duurder. Dankzij de willekeurige hoofdsleutel hoeft bij een nieuw patroon maar één sleutel opnieuw te worden omhuld in plaats van elk bestand opnieuw te versleutelen. Gegevensbescherming van de sleutelhanger bewaakt de lokale salt en herstelrecords, terwijl de app erkent dat symmetrische versleuteling in het procesgeheugen plaatsvindt.

Samen vormen deze lagen een gelaagde verdediging, maar het zijn niet allemaal onafhankelijke drempels. Een geraden patroon kan worden gecontroleerd aan de hand van de naam van het indexbestand en de AES-GCM-authenticatie, en een gecompromitteerd ontgrendeld apparaat kan sleutels of leesbare inhoud in het app-proces zien. De architectuur hangt daarom af van de entropie van het patroon of de zin, de PBKDF2-kosten, de apparaatbescherming van iOS en een correcte omgang met geauthenticeerde versleuteling, en niet alleen van de sterkte van AES.

AES-256-GCM: Bestandsversleuteling

Elke foto, video en document dat in Vaultaire is opgeslagen, wordt versleuteld met AES-256-GCM: de Advanced Encryption Standard met een 256-bits sleutel in Galois/Counter Mode. Vaultaire gebruikt AES-GCM ook voor kluisindexen, bestandsheaders, miniaturen en sleutelenveloppen. Het algoritme en de sleutelgrootte zijn gestandaardiseerd; de beveiliging van Vaultaire hangt nog steeds af van de omgang met nonces, sleutelbeheer, de sterkte van het patroon of de zin en een correcte implementatie.

De “256” in AES-256 verwijst naar de sleutellengte in bits. Een 256-bits sleutel heeft er 2²⁵⁶ mogelijke waarden. Om dat aantal in perspectief te plaatsen: het zijn er grofweg 10⁸⁰ atomen in het waarneembare heelal. Als elk atoom een supercomputer was die sinds de oerknal een miljard sleutels per seconde testte, zouden ze minder dan een biljoenste van een biljoenste van één procent van de sleutelruimte hebben verkend. AES-256 zal niet bruut geforceerd zijn. Niet vandaag. Deze eeuw niet. Niet voordat de sterren opbranden.

Waarom de GCM-modus belangrijk is

AES is een blokcijfer, en versleutelt gegevens in brokken van 128 bits. De “mode” bepaalt hoe die chunks worden gecombineerd. GCM (Galois/Counter Mode) biedt twee dingen die eenvoudigere modi zoals CBC niet bieden: parallelle versleuteling en ingebouwde authenticatie.

Het authenticatieonderdeel is van cruciaal belang. GCM genereert een cryptografische tag voor elk versleuteld bestand. Deze tag fungeert als een sabotagezegel. Als zelfs maar een enkel bit van de ciphertext wordt gewijzigd, hetzij door een kwaadwillende actor of door een beschadigde schijfsector, zal de authenticatietag niet overeenkomen en zal de ontsleuteling mislukken. U krijgt geen beschadigde gegevens. Je krijgt een duidelijk signaal dat er iets mis is. Deze eigenschap wordt geauthenticeerde versleuteling genoemd en voorkomt een hele klasse aanvallen waarbij een tegenstander versleutelde gegevens wijzigt om de ontsleutelde uitvoer te manipuleren.

PBKDF2: Sleutelafleiding

Vaultaire leidt verschillende sleutels af voor verschillende taken. Het patroon en een salt per apparaat uit de sleutelhanger gaan 600.000 iteraties door PBKDF2-HMAC-SHA512 en leveren zo de lokale kluissleutel op. Een deterministische afleiding van het patroon levert de aparte sleutel voor de cloudback-up op. De genormaliseerde herstelzin gaat door 800.000 PBKDF2-iteraties en levert de sleutel voor een herstelenvelop op. Geen van deze afleidingen geeft een patroon of zin 256 bits entropie, alleen omdat de uitvoer 256 bits lang is.

Hoe PBKDF2 uw patroon beschermt

Het kernidee achter PBKDF2 is bewust veel rekenwerk. Het neemt het geserialiseerde patroon of de genormaliseerde zin en voert honderdduizenden HMAC-SHA512-iteraties uit. Een legitieme gebruiker betaalt deze kosten één keer tijdens een ontgrendelings- of herstelpoging. Een aanvaller betaalt het voor elke kandidaat, hoewel parallelle hardware- en implementatiekeuzes de werkelijke goksnelheid bepalen.

Vaultaire configureert PBKDF2 met 600.000 iteraties voor van patronen afgeleide sleutels. Dat maakt elke gok duurder, maar een eerlijke schatting van een aanval moet een gemeten tijd per kandidaat en de aannames over de hardware noemen. Bij precies 1 ms per kandidaat duren 1.000.000.000 seriële gissingen ongeveer 11,6 dagen, niet jaren. Het 256-bits resultaat vergroot de entropie van een voorspelbaar patroon niet.

Lokale patroonafleiding gebruikt één cryptografisch willekeurige salt voor het apparaat, opgeslagen als sleutelhangeritem met WhenUnlockedThisDeviceOnly. De salt is niet geheim en wordt gedeeld door de kluizen op dat apparaat. Het voorkomt dat een tabel die voor het ene apparaat is gebouwd, rechtstreeks op een ander apparaat met een andere salt wordt toegepast, maar het dwingt een aanvaller niet om voor elke kluis op hetzelfde apparaat opnieuw te beginnen.

AES-256-GCM: bescherming van metadata

Het coderen van de bestandsinhoud is niet voldoende. Bestandsnamen, aanmaakdatums, miniatuurafmetingen en kluisstructuur zijn allemaal metadata, en metadata kunnen net zo onthullend zijn als de gegevens zelf. Een bestand met de naam “tax-return-2025.pdf” vertelt een aanvaller precies wat er in zit, zelfs als de inhoud versleuteld is. Een tijdstempel geeft aan wanneer u de kluis heeft gebruikt. De miniatuurgrootte laat zien of iets een foto of een video is.

Vaultaire beschermt deze metadata met AES-256-GCM, niet ChaCha20. Bestandsnamen en MIME-typen staan in versleutelde bestandsheaders. De versleutelde kluisindex bevat bestandsrecords, datums, informatie over grootte, de opslagindeling en de omhulde hoofdsleutel. Ook miniatuurgegevens worden versleuteld onder de willekeurige hoofdsleutel.

Waarom geauthenticeerde versleuteling voor metadata?

Metadata hebben zowel integriteit als vertrouwelijkheid nodig. AES-GCM maakt voor elke versleutelde waarde een authenticatietag, zodat Vaultaire een gewijzigde header, index, miniatuur of envelop kan weigeren in plaats van inhoud te accepteren die een aanvaller heeft bepaald. Het ontwerp gebruikt bewust één geauthenticeerde versleutelingsconstructie voor deze opslagformaten in plaats van cryptografische diversiteit te claimen die de implementatie niet biedt.

Hetzelfde algoritme betekent niet dat dezelfde sleutel of nonce blindelings wordt hergebruikt. De kluissleutel beschermt de index en omhult de willekeurige hoofdsleutel; de hoofdsleutel beschermt de bestanden. CryptoKit maakt geauthenticeerde sealed boxes met nieuwe nonces, en het streamingformaat van Vaultaire leidt voor elk geordend blok een eigen nonce af. De garanties komen uit gescheiden sleutels, zorgvuldig nonce-gebruik en authenticatie, niet uit een tweede algoritme voor metadata.

Zero-Knowledge-architectuur

Hier is een vraag die de moeite waard is om te stellen over elke beveiligingsapp: wat gebeurt er als het bedrijf erachter wordt gehackt, gedagvaard of eenvoudigweg kwaadaardig wordt?

Bij de meeste apps is het antwoord ongemakkelijk. Ze bevatten uw gegevens, uw sleutels of beide. Een gerechtelijk bevel dwingt hen om het over te dragen. Een datalek legt het bloot. Een malafide medewerker heeft er toegang toe. De beveiliging van de app is slechts zo sterk als de operationele beveiliging van het bedrijf, en de geschiedenis leert dat bedrijven regelmatig worden gehackt.

Vaultaire beheert geen account- of opslagdienst die uw patroon, herstelzin, ontsleutelingssleutels of leesbare kluisinhoud ontvangt. Versleuteling en ontsleuteling gebeuren in het app-proces op uw apparaat. Staat iCloud-back-up aan, dan stuurt de app geauthenticeerde versleutelde tekst naar uw privé-CloudKit-database en niet naar een kluisdienst van Vaultaire.

Wat nulkennis in de praktijk betekent

Als een wetshandhavingsinstantie Vaultaire een dagvaarding stuurt waarin wordt geëist dat de kluis in platte tekst wordt weergegeven, beschikt het bedrijf niet over het patroon, de herstelzin, de kluissleutel, de back-upsleutel of de hoofdsleutel die nodig zijn om de kluis te ontsleutelen. Versleutelde iCloud-records staan in de privé-CloudKit-database van de gebruiker. Op het apparaat staat het herstelmateriaal wel in een versleutelde database die door de sleutelhanger wordt beschermd, en symmetrische sleutels staan in het app-geheugen zolang CryptoKit een open kluis versleutelt of ontsleutelt.

Deze grens bij de aanbieder is een eigenschap van de architectuur, geen belofte dat elk onderdeel aan de kant van de gebruiker buiten het vertrouwensmodel valt. Vaultaire heeft geen ontsleutelingssleutel op een server die het kan afgeven voor een gewoon herstel van de kluis. De uitgebrachte app, iOS, het ontgrendelde apparaat en de cryptografische implementatie kunnen nog steeds leesbare gegevens verwerken en moeten dienovereenkomstig worden vertrouwd.

De sleutelhanger en de grens van het app-proces

De Secure Enclave van Apple kan ondersteunde privésleutels beschermen en maakt deel uit van de platformbeveiliging, maar de openbare API's nemen geen willekeurige, met PBKDF2 afgeleide symmetrische sleutel aan en voeren de AES-GCM-bestandsbewerkingen van Vaultaire niet uit in de coprocessor. Vaultaire beschrijft zijn kluisversleuteling daarom niet als Secure Enclave AES.

Vaultaire gebruikt gewone generieke wachtwoorditems in de iOS-sleutelhanger voor de willekeurige salt van het apparaat, de versleutelde hersteldatabase en de willekeurige sleutel die die database beschermt. Deze items gebruiken de toegankelijkheidsklasse WhenUnlockedThisDeviceOnly. De sleutelhanger en gegevensbescherming vormen een echte grens op het apparaat, vooral als de telefoon vergrendeld is, maar dat is iets anders dan een niet-exporteerbare sleutel in de Secure Enclave.

Wanneer u het patroon tekent, leidt CommonCrypto de kluissleutel af in het app-proces. CryptoKit en de CryptoEngine van Vaultaire gebruiken daarna symmetrische sleutelbytes in dat proces om de index te verifiëren en te ontsleutelen, de hoofdsleutel uit te pakken en bestanden te verwerken. De app wist de actieve toestand bij het vergrendelen, maar een aanvaller met voldoende rechten die een ontgrendelde sessie kan bekijken, heeft andere mogelijkheden dan een onderzoeker die alleen de versleutelde tekst van een vergrendeld apparaat heeft.

Een gejailbreakt of op een andere manier gecompromitteerd besturingssysteem kan het invoeren van het patroon, het app-geheugen, ontsleutelde voorbeelden, exports of het scherm onderscheppen. Vaultaire raadt een bijgewerkte iPhone zonder jailbreak aan, omdat het ontwerp steunt op de procesisolatie van iOS, de sleutelhanger en gegevensbescherming. Er wordt niet beweerd dat een rootcompromis de symmetrische sleutels van een open kluis ontoegankelijk maakt.

Initialisatievectoren per bestand

Wanneer u twee identieke bestanden met dezelfde sleutel versleutelt, zou een naïeve implementatie identieke ciphertext produceren. Dit is een probleem. Een aanvaller die twee identieke versleutelde blobs ziet, weet, zonder iets te decoderen, dat de twee originele bestanden hetzelfde zijn. In een kluis vol foto's kan dit soort patroonanalyse zelfs via encryptie informatie onthullen.

Vaultaire voorkomt deterministische versleutelde tekst door voor elke AES-256-GCM-versleuteling een nieuwe cryptografische nonce te maken. Bestandsheaders en bestandsinhoud worden apart versleuteld, en grote bestanden gebruiken een geauthenticeerd streamingformaat met een willekeurige basis-nonce en een eigen nonce voor elk geordend blok. Twee kopieën van dezelfde foto leveren dus niet dezelfde versleutelde vorm op.

De nonces worden naast de versleutelde tekst opgeslagen en zijn niet geheim; ze moeten alleen uniek zijn onder een bepaalde sleutel. Vaultaire haalt 96-bits nonces uit de cryptografische randomgenerator van Apple voor versleuteling in één keer en legt de basis-nonce vast in de streamingheader. De kans op een botsing hangt af van het aantal versleutelingen onder één sleutel, dus de implementatie maakt steeds een nieuwe waarde en doet de 96-bitsgrootte niet voor als een vaste garantie van één op 2⁹⁶.

Geheugenbeheer: actieve sleutels wissen

Een veel voorkomende fout in beveiligingssoftware is dat gevoelige gegevens in het geheugen achterblijven nadat deze niet langer nodig zijn. Encryptiesleutels, afgeleide wachtwoorden en ontsleutelde gegevens kunnen in het RAM blijven bestaan, lang nadat de app ze niet meer gebruikt. Forensische tools kunnen apparaatgeheugen dumpen en naar deze overblijfselen zoeken, een techniek die bekend staat als een cold-boot-aanval of geheugendumpanalyse.

Vaultaire beperkt hoe lang actieve sleutels en ontsleutelde interfacegegevens beschikbaar blijven. Wanneer de app vergrendelt of de sessie wordt afgebroken, ruimt de code op verschillende manieren op:

• De actieve kluistoestand wordt gewist. De app wist de huidige kluissleutelsessie en vraagt een nieuwe ontgrendeling voordat de kluisinhoud weer wordt getoond.
• Sleutelcontainers wissen hun eigen buffers. De beveiligde bytecontainers van Vaultaire overschrijven hun eigen buffers wanneer die containers worden vrijgegeven.
• De gecachte hoofdsleutel wordt ongeldig gemaakt. De ontsleutelde hoofdsleutel die voor de open index wordt bewaard, wordt weggegooid bij het vergrendelen en bij het legen van de cache.
• Ontsleutelde interfacecaches die Vaultaire beheert, worden gewist. Het opruimen van miniaturen en voorbeelden beperkt wat er in de app achterblijft, zonder controle te claimen over elke kopie die Swift, iOS of een ander proces maakt.

Opent u Vaultaire daarna in vergrendelde toestand, dan tekent u het patroon en leidt de app de kluissleutel opnieuw af voordat de index kan worden geverifieerd en de hoofdsleutel kan worden uitgepakt. Dit is het opruimen van een sessie, geen bewering dat elke tijdelijke kopie in het geheugen aantoonbaar meerdere keren is overschreven of dat een sleutel in de Secure Enclave is vernietigd. Na een crash ruimt iOS het proces op, maar de opruimcode kan niet na elke abrupte beëindiging draaien.