Sikkerhedsarkitektur: Det fulde tekniske grundlag

Vaultaire bruger AES-256-GCM til autentificeret kryptering af boksindekser, indpakkede nøgler, filheadere, indhold, miniaturer og metadata. PBKDF2-HMAC-SHA512 udleder en lokal boksnøgle fra mønstret og et salt i Keychain, der gælder for hele enheden. Boksnøglen indpakker en separat tilfældig 256-bit-hovednøgle, som udfører filkrypteringen via CryptoKit i app-processen.

Det kryptografiske grundlag

Vaultaire bruger flere kryptografiske mekanismer, der arbejder sammen, hver valgt til et specifikt job. PBKDF2 gør et mønster eller en sætning til en boks- eller gendannelsesnøgle. AES-256-GCM beskytter indekser, nøgleindpakninger, 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 hos udbyderen giver udvikleren rutinemæssig adgang til boksens indhold i klartekst.

Dette er ikke kompleksitet for sin egen skyld. Hvert lag dækker en anden angrebsflade. AES-256-GCM kombinerer fortrolighed med autentificering, så ændret chiffertekst ikke består 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 genindpakke én nøgle i stedet for at genkryptere hver fil. Keychain-databeskyttelse beskytter lokale salt- og gendannelsesposter, mens appen stadig anerkender, at symmetrisk kryptering sker i proceshukommelsen.

Tilsammen giver lagene et forsvar i dybden, men de er ikke alle uafhængige barrierer. Et gættet mønster kan kontrolleres mod indeksets filnavn og AES-GCM-autentificeringen, og en kompromitteret, oplåst enhed kan se nøgler eller klartekst i app-processen. Arkitekturen afhænger derfor af mønstrets entropi, prisen for PBKDF2, iOS-enhedsbeskyttelsen og korrekt håndtering af autentificeret kryptering, ikke kun af styrken i AES.

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 i Galois/Counter Mode. Vaultaire bruger også AES-GCM til boksindekser, filheadere, thumbnails og nøglekonvolutter. Algoritmen og nøglestørrelsen er standardiseret; Vaultaires sikkerhed afhænger stadig af nonce-håndtering, nøglestyring, styrken af mønster og sætning og korrekt implementering.

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 et enhedsdækkende Keychain-salt føres gennem PBKDF2-HMAC-SHA512 med 600.000 iterationer for at danne den lokale boksnøgle. PBKDF2-HMAC-SHA512 med 600.000 iterationer og et salt, der kun afhænger af mønsteret, danner den separate backupnøgle til skyen, så den samme boks kan gendannes på en ny enhed. Den normaliserede gendannelsessætning kører gennem 800.000 PBKDF2-iterationer for at producere nøglen til en gendannelseskonvolut. Ingen af disse afledninger giver et menneskevalgt mønster eller en sætning 256 bits entropi, blot fordi outputtet er 256 bit langt.

Hvordan PBKDF2 beskytter dit mønster

Kerneideen bag PBKDF2 er bevidst arbejde. Den tager det serialiserede mønster eller den 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 den for hver kandidat, selvom parallel 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 øger ikke entropien i et forudsigeligt mønster.

Lokal mønsterafledning bruger ét kryptografisk tilfældigt salt for enheden, gemt som et WhenUnlockedThisDeviceOnly-element i Keychain. Saltet er ikke hemmeligt og deles af boksene på den enhed. Det forhindrer, at en tabel bygget til én enhed kan bruges 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 boksstruktur 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 i krypterede filheadere. 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 danner et godkendelsestag for hver krypteret værdi, så Vaultaire kan afvise en ændret header, et indeks, en thumbnail eller en konvolut i stedet for at acceptere klartekst, som en angriber styrer. 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 chiffer betyder ikke, at den samme nøgle eller nonce genbruges blindt. Boksnøglen beskytter indekset og indpakker den tilfældige hovednøgle; hovednøglen beskytter filmateriale. CryptoKit opretter autentificerede sealed boxes med nye nonces, mens Vaultaires streamingformat udleder en særskilt nonce for hver del i rækkefølgen. 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 boksindhold. Kryptering og dekryptering sker i app-processen på din enhed. Når iCloud-sikkerhedskopi er slået til, sender appen autentificeret chiffertekst til din private CloudKit-database i stedet for til en Vaultaire-styret bokstjeneste.

Hvad nul-kendskab-arkitektur betyder i praksis

Hvis en myndighed sender Vaultaire en retskendelse, der kræver boksindhold i klartekst, er virksomheden ikke i besiddelse af mønsteret, gendannelsessætningen, boksnøglen, backup-nøglen eller hovednøglen, der er nødvendig for at dekryptere den. Krypterede iCloud-poster ligger i brugerens private CloudKit-database. Apple kan stadig se metadata som antal poster, størrelser og tidspunkter, og den, der kan læse databasen, kan teste gættede mønstre offline mod sikkerhedskopien. 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 ingen dekrypteringsnøgle på serversiden, som den kan udlevere til rutinemæssig gendannelse af bokse. Den udgivne app, iOS, den ulåste enhed og den kryptografiske implementering kan stadig behandle læsbare data, og tilliden til dem skal vurderes derefter.

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ører ikke Vaultaires AES-GCM-filoperationer i coprocessoren. Vaultaire beskriver derfor ikke sin bokschiffer som Secure Enclave-AES.

Vaultaire bruger almindelige generiske adgangskodeelementer i iOS Keychain til det tilfældige enhedssalt, den krypterede 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-eksporterbar Secure Enclave-nøgle.

Når du tegner mønsteret, udleder CommonCrypto boksnø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 andre muligheder end en undersøger, der kun har chiffertekst fra en låst enhed.

Et jailbroken eller på anden måde kompromitteret styresystem kan ramme 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, Keychain og databeskyttelse. Vaultaire hævder ikke, at kompromittering på root-niveau efterlader en åben boks' 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 boks 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-forsegling. Filoverskrifter og filindhold forsegles separat, og store filer bruger et autentificeret streamingformat med en tilfældig basisnonce og en særskilt nonce for hver del i rækkefølgen. 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 henter 96-bit nonces fra Apples kryptografiske tilfældighedsgenerator til kryptering i ét trin og gemmer basisnoncen i streaming-headeren. Kollisionsrisikoen afhænger af antallet af krypteringer under én nøgle, så implementeringen genererer en ny værdi i stedet for at fremstille 96-bit størrelsen som en fast garanti på én ud af 2⁹⁶ for hele levetiden.

Hukommelsesstyring: Rydning af aktiv nøgletilstand

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 begrænser, hvor længe aktiv nøgletilstand og dekrypterede UI-data er tilgængelige. Når appen låser, eller sessionen lukkes ned, følger koden flere oprydningsveje:

• Aktiv bokstilstand kasseres. Appen fjerner sin aktuelle session med boksnøglen og kræver en ny oplåsning, før den viser boksindhold.
• Nøgleindpakninger rydder egne buffere. Vaultaires sikre byte-beholdere overskriver de buffere, de ejer, når disse beholdere deallokeres.
• Cachelagret hovednøgletilstand ugyldiggøres. 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 thumbnails og forhåndsvisninger mindsker resterende apptilstand uden at påstå kontrol over hver kopi lavet af Swift, iOS eller en anden proces.

Næste gang Vaultaire åbner i en låst tilstand, tegner du mønsteret, og appen udleder boksnøglen igen, før den kan autentificere indekset og pakke hovednøglen ud. Dette er sessionsoprydning, ikke en påstand om, at hver midlertidig hukommelseskopi blev beviseligt overskrevet flere gange, eller at en Secure Enclave-nøglereference blev destrueret. Et nedbrud får iOS til at frigøre processen, men oprydningskoden kan ikke køre efter hver brat afslutning.