Beveiligingsarchitectuur: de volledige technische stapel

Vaultaire-gebruik AES-256-GCM voor geverifieerde encryptie voor kluisindexen, ingepakte sleutels, bestandskoppen, inhoud, miniaturen en metagegevens. PBKDF2-HMAC-SHA512 leidt een lokale kluissleutel af van het patroon en een apparaatbreed Keychain zout. Die kluissleutel omvat een afzonderlijke willekeurige 256-bits hoofdsleutel, die de bestandsversleuteling uitvoert CryptoKit in het app-proces.

De cryptografische stapel

Vaultaire gebruikt verschillende cryptografische mechanismen die samenwerken, elk gekozen voor een specifieke taak. PBKDF2 verandert een menselijke inloggegevens in een kluis of herstelsleutel. AES-256-GCM beschermt indexen, wrappers, metagegevens, miniaturen en bestandsinhoud. Een willekeurige hoofdsleutel scheidt langdurige bestandsversleuteling van een veranderlijk patroon. Keychain en iOS Gegevensbescherming beschermt apparaatgebonden salt- en herstelrecords terwijl het apparaat is vergrendeld. Geen enkele door de provider beheerde decoderingssleutel geeft de ontwikkelaar routinematige toegang tot de platte tekst van de kluis.

Dit is geen complexiteit op zichzelf. Elke laag richt zich op een ander aanvalsoppervlak. AES-256-GCM combineert vertrouwelijkheid met authenticatie, zodat gewijzigde cijfertekst de verificatie mislukt. PBKDF2 verhoogt de kosten voor het testen van elk patroon of zin. De willekeurige hoofdsleutel betekent dat een patroonverandering één sleutel kan herverpakken in plaats van elk bestand opnieuw te versleutelen. Keychain gegevensbescherming bewaakt lokale salt- en herstelrecords, terwijl de app nog steeds erkent dat symmetrische codering plaatsvindt in het procesgeheugen.

Samen vormen deze lagen een diepgaande verdedigingsarchitectuur, maar het zijn niet allemaal onafhankelijke barrières. Een geraden patroon kan worden gecontroleerd aan de hand van de indexbestandsnaam en AES-GCM authenticatie, en een gecompromitteerd ontgrendeld apparaat kan sleutels of platte tekst in het app-proces waarnemen. De architectuur is daarom afhankelijk van referentie-entropie, PBKDF2 kosten, iOS apparaatbescherming en correcte afhandeling van geauthenticeerde codering, evenals de kracht van AES zelf.

AES-256-GCM: Bestandscodering

Elke foto, video en document dat in Vaultaire is opgeslagen, is gecodeerd met AES-256-GCM — de Advanced Encryption Standard met een 256-bits sleutel erin Galois/teller-modus. Vaultaire gebruikt ook AES-GCM voor kluisindexen, bestandskoppen, miniaturen en sleutelenveloppen. Het algoritme en de sleutelgrootte zijn gestandaardiseerd; De beveiliging van Vaultaire is nog steeds afhankelijk van nonce-afhandeling, sleutelbeheer, de sterkte van de inloggegevens en de correctheid van de 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 codeert 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 codering en ingebouwde authenticatie.

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

PBKDF2: Sleutelafleiding

Vaultaire leidt verschillende sleutels af voor verschillende taken. Het patroon en een apparaatbreed Keychain zout voer PBKDF2-HMAC-SHA512 voor 600.000 iteraties om de lokale kluissleutel te produceren. Een deterministische patroonafleiding produceert de afzonderlijke cloudback-upsleutel. De genormaliseerde herstelzin loopt tot en met 800.000 PBKDF2 iteraties om de sleutel voor een herstelenvelop te produceren. Geen van deze afleidingen verandert een menselijke referentie in 256 bits entropie alleen maar omdat de uitvoer 256 bits lang is.

Hoe PBKDF2 uw patroon beschermt

Het kernidee erachter PBKDF2 is doelbewust werk. Het neemt het geserialiseerde patroon of de genormaliseerde zin en voert honderdduizenden uit HMAC-SHA512 iteraties. 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 schatting van een verantwoorde aanval moet een gemeten tijd en hardware-aannames per kandidaat vermelden. 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 WhenUnlockedThisDeviceOnly Keychain artikel. Het zout 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: Metagegevensbescherming

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 gecodeerd 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 worden gecodeerd in gecodeerde bestandsheaders. De gecodeerde kluisindex bevat bestandsrecords, datums, grootte-informatie, opslagindeling en de ingepakte hoofdsleutel. Miniatuurgegevens worden ook gecodeerd onder de willekeurige hoofdsleutel.

Waarom geauthenticeerde encryptie voor metadata?

Metadata hebben zowel integriteit als vertrouwelijkheid nodig. AES-GCM produceert een authenticatietag voor elke gecodeerde waarde, zodat Vaultaire een gewijzigde koptekst, index, miniatuur of envelop kan weigeren in plaats van door de aanvaller gecontroleerde platte tekst te accepteren. Het ontwerp maakt bewust gebruik van één geauthenticeerde encryptieconstructie voor deze opslagformaten in plaats van cryptografische diversiteit te claimen die de implementatie niet biedt.

Hetzelfde cijfer betekent niet dat dezelfde sleutel of nonce blindelings wordt hergebruikt. De kluissleutel beschermt de index en omhult de willekeurige hoofdsleutel; de hoofdsleutel beschermt dossiermateriaal. CryptoKit creëert geauthenticeerde verzegelde dozen met nieuwe nonces, terwijl het streamingformaat van Vaultaire voor elk besteld deel een aparte nonce afleidt. De relevante garanties komen voort uit sleutelscheiding, nonce-discipline en authenticatie, en niet uit een tweede metadatacijfer.

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 opslagservice die uw patroon, geheime zin, decoderingssleutels of leesbare kluisinhoud ontvangt. Versleuteling en ontsleuteling gebeuren tijdens het app-proces op uw apparaat. Wanneer iCloud back-up is ingeschakeld, stuurt de app geverifieerde cijfertekst naar uw privégegevens CloudKit database in plaats van naar een door Vaultaire beheerde kluisservice.

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. Gecodeerd iCloud records leven in die van de gebruiker CloudKit privé database. Op het apparaat wordt het herstelmateriaal echter versleuteld bewaard Keychain database, en er bestaan symmetrische sleutels in het app-geheugen while CryptoKit codeert of decodeert een open kluis.

Deze providergrens is een architectonisch kenmerk en geen belofte dat elk onderdeel van de klantomgeving buiten het vertrouwensmodel valt. Vaultaire beschikt niet over een decoderingssleutel aan de serverzijde die het kan inleveren voor routinematig herstel van de kluis. De verzonden app, iOS, het ontgrendelde apparaat en de cryptografische implementatie kunnen nog steeds leesbare gegevens verwerken en moeten dienovereenkomstig worden vertrouwd.

Keychain en de app-procesgrens

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 gewoon iOS Keychain generieke wachtwoorditems voor het willekeurige apparaatzout, de gecodeerde hersteldatabase en de willekeurige sleutel die die database beschermt. Deze items gebruiken de toegankelijkheidsklasse WhenUnlockedThisDeviceOnly. Keychain en gegevensbescherming creëren een betekenisvolle apparaatgrens, vooral als de telefoon is vergrendeld, maar deze architectuur is anders dan een niet-exporteerbare architectuur Secure Enclave sleutel.

Wanneer u het patroon tekent, CommonCrypto leidt de kluissleutel af in het app-proces. CryptoKit en Vaultaire's CryptoEngine gebruikt vervolgens symmetrische sleutelbytes in dat proces om de index te authenticeren en te decoderen, de hoofdsleutel uit te pakken en bestanden te verwerken. De app wist de actieve status wanneer deze wordt vergrendeld, maar een voldoende bevoorrechte aanvaller die een ontgrendelde sessie observeert, heeft een andere kans dan een onderzoeker die alleen de cijfertekst van een vergrendeld apparaat vasthoudt.

Een gejailbreakt of anderszins gecompromitteerd besturingssysteem kan zich richten op patrooninvoer, app-geheugen, gedecodeerde voorbeelden, exports of het scherm. Vaultaire raadt een actueel, niet-gejailbreakt bestand aan iPhone omdat het ontwerp erop vertrouwt iOS procesisolatie, Keychainen 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 codeert, zou een naïeve implementatie identieke cijfertekst produceren. Dit is een probleem. Een aanvaller die twee identieke gecodeerde 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 cijfertekst door voor elk een nieuwe cryptografische nonce te genereren AES-256-GCM afdichtingsoperatie. Bestandskoppen en bestandsinhoud worden afzonderlijk verzegeld, en grote bestanden gebruiken een geverifieerd streamingformaat met een willekeurige basis-nonce en een afzonderlijke nonce voor elk geordend deel. Twee kopieën van dezelfde foto leveren dus niet dezelfde gecodeerde weergave op.

De nonces worden samen met de cijfertekst opgeslagen en zijn niet geheim; hun veiligheidsvereiste is uniekheid onder een bepaalde sleutel. Vaultaire vraagt ​​96-bits nonces aan bij de cryptografische willekeurige generator van Apple voor single-shot-encryptie en legt de basis-nonce vast in de streaming-header. Het risico op botsingen wordt bepaald door het aantal versleutelingen onder één sleutel, dus de implementatie genereert een nieuwe waarde in plaats van de 96-bitsgrootte te presenteren als een vaste één-op-2⁹⁶ levenslange garantie.

Geheugenbeheer: Actieve sleutelstatus 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 gedecodeerde 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 de actieve sleutelstatus en gedecodeerde UI-gegevens beschikbaar blijven. Wanneer de app wordt vergrendeld of de sessie wordt afgebroken, volgt de code verschillende opschoonpaden:

• De actieve kluisstatus wordt verwijderd. De app verwijdert de huidige kluissleutelsessie en vereist een nieuwe ontgrendeling voordat de kluisinhoud wordt gepresenteerd.
• Sleutelverpakkingen wissen eigen buffers. De beveiligde bytecontainers van Vaultaire overschrijven de buffers waarvan ze eigenaar zijn wanneer de toewijzing van die containers ongedaan wordt gemaakt.
• De status van de hoofdsleutel in de cache is ongeldig. De gedecodeerde hoofdsleutel die voor de open index wordt bewaard, wordt weggegooid op de relevante vergrendelings- en cacheresetpaden.
• Gedecodeerde UI-caches worden gewist waar deze door Vaultaire worden beheerd. Het opschonen van miniaturen en voorbeelden vermindert de resterende applicatiestatus, zonder controle te claimen over elke kopie die door Swift wordt gemaakt, iOSof een ander proces.

De volgende keer dat Vaultaire in vergrendelde toestand wordt geopend, tekent u het patroon en leidt de app de kluissleutel opnieuw af voordat deze de index kan verifiëren en de hoofdsleutel kan uitpakken. Dit is het opschonen van een sessie, en niet de bewering dat elke tijdelijke geheugenkopie een aantoonbare multi-pass wipe heeft ondergaan of dat a Secure Enclave sleutelreferentie is vernietigd. Een crash veroorzaakt iOS om het proces terug te eisen, maar de opschooncode kan niet worden uitgevoerd na elke abrupte beëindiging.