Säkerhetsarkitektur: Den fullständiga tekniska stacken

Vaultaire använder AES-256-GCM för autentiserad kryptering över valvindex, inslagna nycklar, filrubriker, innehåll, miniatyrer och metadata. PBKDF2-HMAC-SHA512 härleder en lokal valvnyckel från mönstret och en enhetsomfattande Keychain salt. Den valvnyckeln omsluter en separat slumpmässig 256-bitars huvudnyckel, som utför filkrypteringen genom CryptoKit i appprocessen.

Den kryptografiska stapeln

Vaultaire använder flera kryptografiska mekanismer som arbetar tillsammans, var och en vald för ett specifikt jobb. PBKDF2 förvandlar en mänsklig legitimation till ett valv eller återställningsnyckel. AES-256-GCM skyddar index, omslag, metadata, miniatyrer och filinnehåll. En slumpmässig huvudnyckel skiljer långlivad filkryptering från ett föränderligt mönster. Keychain och iOS Dataskydd skyddar enhetsbundna salt- och återställningsposter medan enheten är låst. Ingen leverantörshållen dekrypteringsnyckel ger utvecklaren rutin åtkomst till valv klartext.

Detta är inte komplexitet för sin egen skull. Varje lager adresserar en annan attackyta. AES-256-GCM kombinerar konfidentialitet med autentisering, så modifierad chiffertext misslyckas med verifiering. PBKDF2 ökar kostnaden för att testa varje mönster eller fras. Den slumpmässiga huvudnyckeln innebär att en mönsterändring kan slå om en nyckel istället för att omkryptera varje fil. Keychain dataskydd bevakar lokala salt- och återvinningsposter, medan appen fortfarande bekräftar att symmetrisk kryptering sker i processminnet.

Tillsammans bildar dessa lager en djupförsvarsarkitektur, men de är inte alla oberoende barriärer. Ett gissat mönster kan kontrolleras mot indexfilnamnet och AES-GCM autentisering och en komprometterad olåst enhet kan observera nycklar eller klartext i appprocessen. Arkitekturen beror därför på referensentropi, PBKDF2 kostnad, iOS enhetsskydd och korrekt hantering av autentiserad kryptering samt styrkan hos själva AES.

AES-256-GCM: Filkryptering

Varje foto, video och dokument som lagras i Vaultaire är krypterade med AES-256-GCM — Advanced Encryption Standard med en 256-bitars nyckel in Galois/Counter Mode. Vaultaire använder också AES-GCM för valvindex, filrubriker, miniatyrer och nyckelkuvert. Algoritmen och nyckelstorleken är standardiserade; Vaultaires säkerhet beror fortfarande på nonce-hantering, nyckelhantering, autentiseringsstyrka och korrekt implementering.

“256” i AES-256 hänvisar till nyckellängden i bitar. En 256-bitars nyckel har 2²⁵⁶ möjliga värden. För att sätta den siffran i perspektiv: det finns ungefär 10⁸⁰ atomer i det observerbara universum. Om varje atom vore en superdator som testade en miljard nycklar per sekund, igång sedan Big Bang, skulle de ha utforskat mindre än en biljondel av en biljondel av en procent av nyckelutrymmet. AES-256 kommer inte att vara brute-forced. Inte idag. Inte detta århundrade. Inte förrän stjärnorna brinner ut.

Varför GCM-läge är viktigt

AES är ett blockchiffer, det krypterar data i 128-bitars bitar. “mode” bestämmer hur dessa bitar kombineras. GCM (Galois/Counter Mode) tillhandahåller två saker som enklare lägen som CBC inte gör: parallell kryptering och inbyggd autentisering.

Autentiseringsdelen är kritisk. GCM genererar en kryptografisk tagg för varje krypterad fil. Denna etikett fungerar som en manipuleringsförsegling. Om ens en enda bit av chiffertexten modifieras, oavsett om det är en illvillig aktör eller en skadad skivsektor, kommer autentiseringstaggen inte att matcha, och dekrypteringen kommer att misslyckas. Du får inte skadad data. Du får en tydlig signal om att något är fel. Den här egenskapen kallas autentiserad kryptering, och den förhindrar en hel klass av attacker där en motståndare modifierar krypterad data för att manipulera den dekrypterade utdata.

PBKDF2: Nyckelhärledning

Vaultaire härleder olika nycklar för olika jobb. Mönstret och en enhetsomfattande Keychain salt foder PBKDF2-HMAC-SHA512 för 600 000 iterationer för att producera den lokala valvnyckeln. En deterministisk mönsterhärledning producerar den separata säkerhetskopieringsnyckeln för molnet. Den normaliserade återställningsfrasen går genom 800 000 PBKDF2 upprepningar för att skapa nyckeln för ett återställningskuvert. Ingen av dessa härledningar förvandlar en mänsklig referens till 256 bitar av entropi bara för att utmatningen är 256 bitar lång.

Hur PBKDF2 skyddar ditt mönster

Kärnan bakom PBKDF2 är ett medvetet arbete. Den tar det serialiserade mönstret eller normaliserade frasen och kör hundratusentals HMAC-SHA512 iterationer. En legitim användare betalar den kostnaden en gång under ett upplåsnings- eller återställningsförsök. En angripare betalar det för varje kandidat, även om parallella val av hårdvara och implementering avgör den verkliga gissningshastigheten.

Vaultaire konfigurerar PBKDF2 med 600 000 iterationer för mönsterhärledda nycklar. Det gör varje gissning dyrare, men en ansvarsfull attackuppskattning måste ange en uppmätt tid per kandidat och hårdvaruantaganden. Vid exakt 1 ms per kandidat tar 1 000 000 000 seriegissningar ungefär 11,6 dagar, inte år. 256-bitarsresultatet utökar inte entropin för ett förutsägbart mönster.

Lokal mönsterhärledning använder ett kryptografiskt slumpmässigt salt för enheten, lagrat som en WhenUnlockedThisDeviceOnly Keychain objekt. Saltet är inte hemligt och delas av valven på den enheten. Det förhindrar att en tabell byggd för en enhet appliceras direkt på en annan enhet med ett annat salt, men det tvingar inte en angripare att börja om för varje valv på samma enhet.

AES-256-GCM: Metadataskydd

Det räcker inte att kryptera filinnehållet. Filnamn, skapandedatum, miniatyrdimensioner och valvstruktur är alla metadata, och metadata kan vara lika avslöjande som själva data. En fil med namnet “tax-return-2025.pdf” berättar för en angripare exakt vad som finns inuti även om innehållet är krypterat. En tidsstämpel visar när du använde valvet. En miniatyrstorlek avslöjar om något är ett foto eller en video.

Vaultaire skyddar denna metadata med AES-256-GCM, inte ChaCha20. Filnamn och MIME typer kodas till krypterade filrubriker. Det krypterade valvindexet innehåller filposter, datum, storleksinformation, lagringslayout och den inslagna huvudnyckeln. Miniatyrbildsdata krypteras också under den slumpmässiga huvudnyckeln.

Varför autentiserad kryptering för metadata?

Metadata behöver integritet såväl som konfidentialitet. AES-GCM producerar en autentiseringstagg för varje krypterat värde, så att Vaultaire kan avvisa en modifierad rubrik, index, miniatyrbild eller kuvert istället för att acceptera angriparkontrollerad klartext. Designen använder medvetet en autentiserad krypteringskonstruktion över dessa lagringsformat snarare än att hävda kryptografisk mångfald som implementeringen inte ger.

Samma chiffer betyder inte att samma nyckel eller nonce återanvänds blint. Valvnyckeln skyddar indexet och lindar den slumpmässiga huvudnyckeln; huvudnyckeln skyddar filmaterial. CryptoKit skapar autentiserade förseglade lådor med färska nonces, medan Vaultaires streamingformat härleder en distinkt nonce för varje beställd bit. De relevanta garantierna kommer från nyckelseparation, nonce-disciplin och autentisering, inte från ett andra metadatachiffer.

Zero-Knowledge Architecture

Här är en fråga som är värd att ställa om vilken säkerhetsapp som helst: vad händer om företaget bakom den blir hackat, stämt eller helt enkelt blir skadligt?

Med de flesta appar är svaret obekvämt. De håller dina data, dina nycklar eller båda. Ett domstolsbeslut tvingar dem att överlämna det. Ett dataintrång avslöjar det. En oseriös anställd kommer åt det. App’s säkerhet är bara lika stark som företagets ’s operativa säkerhet, och historien visar att företag blir intrångade regelbundet.

Vaultaire driver inte ett konto eller en lagringstjänst som tar emot ditt mönster, hemliga fras, dekrypteringsnycklar eller läsbart valvinnehåll. Kryptering och dekryptering sker i appprocessen på din enhet. När iCloud säkerhetskopiering är aktiverad, skickar appen autentiserad chiffertext till din privata CloudKit databas snarare än till en Vaultaire-kontrollerad valvtjänst.

Vad noll-kunskap betyder i praktiken

Om en brottsbekämpande myndighet servar Vaultaire med en stämning som kräver valv klartext, har företaget inte mönstret, återställningsfrasen, valvnyckeln, reservnyckeln eller huvudnyckeln som behövs för att dekryptera det. Krypterad iCloud poster live i användarens CloudKit privat databas. På enheten hålls dock återställningsmaterial i en krypterad Keychain databas och symmetriska nycklar finns i appminnet medan CryptoKit krypterar eller dekrypterar ett öppet valv.

Denna leverantörsgräns är en arkitektonisk egenskap, inte ett löfte om att varje del av klientmiljön ligger utanför förtroendemodellen. Vaultaire har inte en dekrypteringsnyckel på serversidan som den kan överlämna för rutinvalsåterställning. Den levererade appen, iOS, den olåsta enheten och den kryptografiska implementeringen kan fortfarande bearbeta läsbar data och måste litas på i enlighet därmed.

Keychain och App-processgränsen

Apples Secure Enclave kan skydda privata nycklar som stöds och deltar i delar av plattformens säkerhetsarkitektur, men dess offentliga API:er accepterar inte en godtycklig PBKDF2-härledd symmetrisk nyckel och utför Vaultaires AES-GCM filoperationer inuti samprocessorn. Vaultaire beskriver därför inte sitt valvchiffer som Secure Enclave AES.

Vaultaire använder vanliga iOS Keychain generiska lösenordsobjekt för den slumpmässiga enhetens salt, krypterad återställningsdatabasen och den slumpmässiga nyckeln som skyddar den databasen. Dessa objekt använder tillgänglighetsklassen WhenUnlockedThisDeviceOnly. Keychain och dataskydd skapar en meningsfull enhetsgräns, särskilt när telefonen är låst, men den här arkitekturen skiljer sig från en icke-exportabel Secure Enclave nyckel.

När du ritar mönstret, CommonCrypto härleder valvnyckeln i appprocessen. CryptoKit och Vaultaires CryptoEngine använder sedan symmetriska nyckelbytes i den processen för att autentisera och dekryptera indexet, packa upp huvudnyckeln och bearbeta filer. Appen rensar aktivt tillstånd när den låser sig, men en tillräckligt privilegierad angripare som observerar en olåst session har en annan möjlighet än en granskare som bara har låst enhets chiffertext.

Ett jailbroken eller på annat sätt äventyrat operativsystem kan rikta in sig på mönsterinmatning, appminne, dekrypterade förhandsvisningar, exporter eller skärmen. Vaultaire rekommenderar en aktuell, icke-jailbreakad iPhone eftersom designen förlitar sig på iOS processisolering, Keychainoch dataskydd. Den hävdar inte att rotkompromiss gör ett öppet valvs symmetriska nycklar otillgängliga.

Vektorer för initialisering per fil

När du krypterar två identiska filer med samma nyckel, skulle en naiv implementering producera identisk chiffertext. Detta är ett problem. En angripare som ser två identiska krypterade blobbar vet, utan att dekryptera något, att de två originalfilerna är desamma. I ett valv fullt av foton kan den här typen av mönsteranalys avslöja information även genom kryptering.

Vaultaire förhindrar deterministisk chiffertext genom att generera en ny kryptografisk nonce för varje AES-256-GCM tätningsoperation. Filrubriker och filinnehåll förseglas separat, och stora filer använder ett autentiserat streamingformat med en slumpmässig bas nonce och en distinkt nonce för varje beställd bit. Två kopior av samma foto ger därför inte samma krypterade representation.

Nonserna lagras med chiffertexten och är inte hemliga; deras säkerhetskrav är unikhet under en given nyckel. Vaultaire begär 96-bitars nonce från Apples kryptografiska slumpgenerator för single-shot-kryptering och registrerar basnonce i strömningshuvudet. Kollisionsrisk styrs av antalet krypteringar under en nyckel, så implementeringen genererar ett nytt värde snarare än att presentera 96-bitarsstorleken som en fast en-i-2⁹⁶ livstidsgaranti.

Minneshantering: Rensar Active Key State

Ett vanligt fel i säkerhetsprogramvaran är att känsliga data lämnas i minnet efter att de inte längre behövs. Krypteringsnycklar, härledda lösenord och dekrypterad data kan finnas kvar i RAM-minnet långt efter att appen har slutat använda dem. Kriminaltekniska verktyg kan dumpa enhetsminne och söka efter dessa rester, en teknik som kallas kallstartsattack eller minnesdumpningsanalys.

Vaultaire begränsar hur länge aktivt nyckeltillstånd och dekrypterad UI-data förblir tillgängliga. När appen låser sig eller sessionen rivs, följer dess kod flera rensningsvägar:

• Aktivt valvtillstånd avbryts. Appen tar bort sin nuvarande valvnyckelsession och kräver ytterligare en upplåsning innan valvets innehåll presenteras.
• Nyckelomslag rensar ägda buffertar. Vaultaires säkra byte-behållare skriver över buffertarna de äger när dessa behållare avallokeras.
• Cachad huvudnyckeltillstånd är ogiltigt. Den dekrypterade huvudnyckeln som hålls för det öppna indexet kasseras på de relevanta lås- och cache-återställningsvägarna.
• Dekrypterade UI-cacher rensas där de kontrolleras av Vaultaire. Rengöring med miniatyrbilder och förhandsgranskning minskar kvarvarande applikationstillstånd, utan att göra anspråk på kontroll över varje kopia gjord av Swift, iOS, eller en annan process.

Nästa gång Vaultaire öppnas i låst tillstånd ritar du mönstret och appen hämtar valvnyckeln igen innan den kan autentisera indexet och packa upp huvudnyckeln. Detta är en sessionsrensning, inte ett påstående om att varje övergående minneskopia fick en bevisbar multipass-torkning eller att en Secure Enclave nyckelreferens förstördes. En krasch orsakar iOS för att återta processen, men rensningskoden kan inte köras efter varje abrupt avslutning.