Sikkerhedsarkitektur: Det fulde tekniske grundlag

Det kryptografiske grundlag

Vaultaire bruger flere kryptografiske mekanismer, der arbejder sammen, hver valgt til et specifikt job. PBKDF2 forvandler en menneskelig legitimation til en boks eller en gendannelsesnøgle. AES-256-GCM beskytter indekser, wrappers, metadata, thumbnails og filindhold. En tilfældig hovednøgle adskiller langvarig filkryptering fra et foranderligt mønster. Keychain og iOS Databeskyttelse beskytter enhedsbundne salt- og gendannelsesposter, mens enheden er låst. Ingen dekrypteringsnøgle, der holdes af udbyderen, giver udvikleren rutinemæssig adgang til almindelig tekstboks.

Dette er ikke kompleksitet for sin egen skyld. Hvert lag adresserer en anden angrebsoverflade. AES-256-GCM kombinerer fortrolighed med autentificering, så ændret chiffertekst mislykkes verifikationen. PBKDF2 øger omkostningerne ved at teste hvert mønster eller hver sætning. Den tilfældige hovednøgle betyder, at en mønsterændring kan ompakke én nøgle i stedet for at genkryptere hver fil. Keychain databeskyttelse bevogter lokale salt- og gendannelsesregistreringer, mens appen stadig anerkender, at symmetrisk kryptering sker i proceshukommelsen.

AES-256-GCM: Filkryptering

Hvert foto, video og dokument, der er gemt i Vaultaire, er krypteret med AES-256-GCM — Advanced Encryption Standard med en 256-bit nøgle ind Galois/tællertilstand. Vaultaire bruger også AES-GCM for vault-indekser, filoverskrifter, miniaturebilleder og nøglekonvolutter. Algoritmen og nøglestørrelsen er standardiseret; Vaultaires sikkerhed afhænger stadig af manglende håndtering, nøglestyring, legitimationsstyrke og implementeringskorrekthed.

Tallet "256" i AES-256 angiver nøglelængden i bit. En 256-bit nøgle har 2²⁵⁶ mulige værdier. Som perspektiv: der er ca. 10⁸⁰ atomer i det observerbare univers. Var hvert atom en supercomputer der testede en milliard nøgler i sekundet og kørte siden Big Bang, ville de have undersøgt mindre end en billiontedel af nøglerummet. AES-256 brydes ikke med brute force. Ikke i dag. Ikke i dette århundrede. Ikke før stjernerne slukner.

Hvorfor GCM-tilstanden betyder noget

AES er en blokcipher: den krypterer data i 128-bit blokke. "Tilstanden" bestemmer hvordan disse blokke kombineres. GCM (Galois/Counter Mode) giver to ting simplere tilstande som CBC ikke giver: paralleliseret kryptering og indbygget autentifikation.

Autentifikationsdelen er kritisk. GCM genererer et kryptografisk mærke for hver krypteret fil. Det mærke fungerer som manipulationssikring. Ændres en enkelt bit i chifferteksten, af en ondsindet aktør eller en beskadiget disksektor, stemmer autentifikationsmærket ikke, og dekrypteringen fejler. Du får ikke beskadigede data. Du får et klart signal om at noget er galt. Denne egenskab kaldes autentificeret kryptering og forhindrer en hel klasse af angreb.

PBKDF2: Nøgleafledning

Vaultaire udleder forskellige nøgler til forskellige job. Mønsteret og en enhedsdækkende Keychain salt foder PBKDF2-HMAC-SHA512 i 600.000 iterationer for at producere den lokale hvælvnøgle. En deterministisk mønsterafledning producerer den separate cloud backup nøgle. Den normaliserede gendannelsessætning løber gennem 800.000 PBKDF2 gentagelser for at producere nøglen til en gendannelseskonvolut. Ingen af ​​disse afledninger forvandler en menneskelig legitimation til 256 bits entropi, blot fordi outputtet er 256 bit langt.

Hvordan PBKDF2 beskytter dit mønster

Kerneideen bag PBKDF2 er bevidst arbejde. Det tager det serialiserede mønster eller normaliserede sætning og kører hundredtusindvis af HMAC-SHA512 iterationer. En legitim bruger betaler denne pris én gang under et oplåsnings- eller gendannelsesforsøg. En angriber betaler det for hver kandidat, selvom parallelle hardware- og implementeringsvalg bestemmer den reelle gættehastighed.

Vaultaire konfigurerer PBKDF2 med 600.000 iterationer for mønsterafledte nøgler. Det gør hvert gæt dyrere, men et ansvarligt angrebsestimat skal angive en målt tid pr. kandidat og hardwareantagelser. Ved præcis 1 ms pr. kandidat tager 1.000.000.000 serielle gæt omkring 11,6 dage, ikke år. 256-bit-resultatet udvider ikke entropien af ​​et forudsigeligt mønster.

Lokal mønsterafledning bruger ét kryptografisk tilfældigt salt til enheden, gemt som en WhenUnlockedThisDeviceOnly Keychain vare. Saltet er ikke hemmeligt og deles af hvælvingerne på den enhed. Det forhindrer et bord, der er bygget til én enhed, i at anvende direkte på en anden enhed med et andet salt, men det tvinger ikke en angriber til at starte forfra for hver boks på den samme enhed.

AES-256-GCM: Metadatabeskyttelse

At kryptere filindhold er ikke nok. Filnavne, oprettelsesdatoer, miniaturedimensioner og hvælvingsstruktur er metadata, og metadata kan være lige så afslørende som selve data. En fil med navnet "selvangivelse-2025.pdf" fortæller en angriber præcis hvad der er inden i, selv om indholdet er krypteret.

Vaultaire beskytter disse metadata med AES-256-GCM, ikke ChaCha20. Filnavne og MIME typer er kodet til krypterede filoverskrifter. Det krypterede boksindeks indeholder filposter, datoer, størrelsesoplysninger, lagerlayout og den indpakkede hovednøgle. Thumbnail-data er også krypteret under den tilfældige hovednøgle.

Hvorfor Autentificeret Kryptering til Metadata?

Metadata kræver integritet såvel som fortrolighed. AES-GCM producerer et godkendelsesmærke for hver krypteret værdi, så Vaultaire kan afvise en ændret header, et indeks, et miniaturebillede eller en konvolut i stedet for at acceptere angriberstyret almindelig tekst. Designet bruger bevidst én autentificeret krypteringskonstruktion på tværs af disse lagringsformater i stedet for at hævde kryptografisk mangfoldighed, som implementeringen ikke giver.

Den samme ciffer betyder ikke, at den samme nøgle eller nonce genbruges blindt. Vault-nøglen beskytter indekset og omslutter den tilfældige hovednøgle; hovednøglen beskytter filmateriale. CryptoKit skaber autentificerede forseglede kasser med friske nonces, mens Vaultaires streamingformat udleder en særskilt nonce for hver bestilte del. De relevante garantier kommer fra nøgleadskillelse, nonce-disciplin og autentificering, ikke fra en anden metadatakryptering.

Nul-kendskab-arkitektur

Her er det værd at stille spørgsmålet om enhver sikkerhedsapp: hvad sker der hvis virksomheden bag den hackes, får en stævning, eller simpelthen vender sig?

For de fleste apps er svaret ubehageligt. De holder dine data, dine nøgler, eller begge dele. En retskendelse tvinger dem til at udlevere det. Et datalæk afslører det. En uærlig medarbejder tilgår det. Appens sikkerhed er kun så stærk som virksomhedens operationelle sikkerhed.

Vaultaire driver ikke en konto eller lagertjeneste, der modtager dit mønster, hemmelige sætning, dekrypteringsnøgler eller læsbart hvælvingsindhold. Kryptering og dekryptering sker i app-processen på din enhed. Hvornår iCloud backup er aktiveret, sender appen autentificeret chiffertekst til din private CloudKit database i stedet for til en Vaultaire-styret vault-tjeneste.

Hvad nul-kendskab-arkitektur betyder i praksis

Hvis et retshåndhævende agentur betjener Vaultaire med en stævning, der kræver hvælving i klartekst, er virksomheden ikke i besiddelse af mønsteret, gendannelsessætningen, vault-nøglen, backup-nøglen eller hovednøglen, der er nødvendig for at dekryptere den. Krypteret iCloud poster live i brugerens CloudKit privat database. På enheden opbevares gendannelsesmateriale imidlertid i en krypteret Keychain database, og symmetriske nøgler findes i apphukommelsen, mens CryptoKit krypterer eller dekrypterer en åben boks.

Denne udbydergrænse er en arkitektonisk egenskab, ikke et løfte om, at alle dele af klientmiljøet er uden for tillidsmodellen. Vaultaire har ikke en dekrypteringsnøgle på serversiden, den kan aflevere til rutinemæssig genoprettelse af vault. Den afsendte app, iOS, den ulåste enhed og den kryptografiske implementering kan stadig behandle læsbare data og skal have tillid i overensstemmelse hermed.

Keychain og app-procesgrænsen

Apples Secure Enclave kan beskytte understøttede private nøgler og deltager i dele af platformens sikkerhedsarkitektur, men dens offentlige API'er accepterer ikke en vilkårlig PBKDF2-afledt symmetrisk nøgle og udføre Vaultaires AES-GCM filhandlinger inde i coprocessoren. Vaultaire beskriver derfor ikke sin hvælvingciffer som Secure Enclave AES.

Vaultaire bruger alm iOS Keychain generiske adgangskodeelementer til den tilfældige enheds salt, krypteret gendannelsesdatabase og den tilfældige nøgle, der beskytter denne database. Disse elementer bruger tilgængelighedsklassen WhenUnlockedThisDeviceOnly. Keychain og databeskyttelse skaber en meningsfuld enhedsgrænse, især mens telefonen er låst, men denne arkitektur er forskellig fra en ikke-eksportabel Secure Enclave nøgle.

Når du tegner mønsteret, CommonCrypto udleder vault-nøglen i app-processen. CryptoKit og Vaultaires CryptoEngine bruger derefter symmetriske nøglebytes i den proces til at autentificere og dekryptere indekset, pakke hovednøglen ud og behandle filer. Appen rydder aktiv tilstand, når den låser, men en tilstrækkeligt privilegeret angriber, der observerer en ulåst session, har en anden mulighed end en eksaminator, der kun har låst enheds chiffertekst.

Et jailbroken eller på anden måde kompromitteret operativsystem kan målrette mod mønsterinput, apphukommelse, dekrypterede forhåndsvisninger, eksporter eller skærmen. Vaultaire anbefaler en aktuel, ikke-jailbroken iPhone fordi designet er afhængig af iOS proces isolation, Keychainog databeskyttelse. Den hævder ikke, at rodkompromis efterlader en åben hvælvings symmetriske nøgler utilgængelige.

Initialiseringsvektorer pr. fil

Krypterer du to identiske filer med samme nøgle, ville en naiv implementering producere identisk chiffertekst. Det er et problem. En angriber der ser to identiske krypterede blokke ved, uden at dekryptere noget, at to originale filer er ens. I en hvælving fuld af fotos kan den slags mønsteranalyse afsløre information på trods af kryptering.

Vaultaire forhindrer deterministisk chiffertekst ved at generere en ny kryptografisk nonce for hver AES-256-GCM tætningsoperation. Filoverskrifter og filindhold forsegles separat, og store filer bruger et autentificeret streamingformat med en tilfældig basisnonce og en distinkt nonce for hver bestilte del. To kopier af det samme billede producerer derfor ikke den samme krypterede repræsentation.

Noncerne er gemt med chifferteksten og er ikke hemmelige; deres sikkerhedskrav er unikhed under en given nøgle. Vaultaire anmoder om 96-bit nonce fra Apples kryptografiske tilfældige generator til single-shot-kryptering og registrerer basisnonce i streaming-headeren. Kollisionsrisiko er styret af antallet af krypteringer under én nøgle, så implementeringen genererer en ny værdi i stedet for at præsentere 96-bit størrelsen som en fast en-i-2⁹⁶ livstidsgaranti.

Hukommelsesstyring: Nøgler der sletter sig selv

En hyppig fejl i sikkerhedssoftware er at lade følsomme data blive i hukommelsen længere end nødvendigt. Krypteringsnøgler, afledte adgangskoder og dekrypterede data kan forblive i RAM længe efter at appen er holdt op med at bruge dem. Retsmedicinske værktøjer kan dumpe enhedens hukommelse og søge efter disse rester, en teknik kendt som cold-boot-angreb eller hukommelsesdump-analyse.

Vaultaire håndterer hukommelse aggressivt. Lukker du appen eller låser en hvælving, sker dette straks i rækkefølge:

• Aktiv vault-tilstand er droppet. Appen fjerner dens aktuelle vault-key-session og kræver endnu en oplåsning, før den præsenterer vault-indhold.
• Nøgleindpakning rydder ejede buffere. Vaultaires sikre byte-beholdere overskriver de buffere, de ejer, når disse beholdere deallokeres.
• Cachelagret hovednøgletilstand er ugyldig. Den dekrypterede hovednøgle, der holdes for det åbne indeks, kasseres på de relevante låse- og cache-nulstillingsstier.
• Dekrypterede UI-caches ryddes, hvor de kontrolleres af Vaultaire. Oprydning af miniaturebilleder og forhåndsvisninger reducerer resterende applikationstilstand uden at kræve kontrol over hver kopi lavet af Swift, iOSeller en anden proces.

Næste gang Vaultaire åbner i en låst tilstand, tegner du mønsteret, og appen udleder vault-nøglen igen, før den kan autentificere indekset og pakke hovednøglen ud. Dette er sessionsoprydning, ikke en påstand om, at hver transient hukommelseskopi modtog en beviselig flergangssletning, eller at en Secure Enclave nøglereference blev ødelagt. Et styrt forårsager iOS for at genvinde processen, men oprydningskoden kan ikke køre efter hver brat afslutning.