Säkerhetsarkitektur: Den fullständiga tekniska stacken

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

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 inloggningsuppgift till en 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 dekrypteringsnyckel hos leverantören ger utvecklaren rutinmässig åtkomst till valvets 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 omsluta en nyckel på nytt istället för att omkryptera varje fil. Keychain-dataskydd skyddar lokala salt- och återställningsposter, 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 upplåst enhet kan observera nycklar eller klartext i appens process. Arkitekturen beror därför på inloggningsuppgiftens entropi, 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 krypteras med AES-256-GCM, Advanced Encryption Standard med en 256-bitars nyckel i 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 knäckas med råstyrka. 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. “Läget” 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 tagg 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 ett enhetsomfattande Keychain-salt matas in i 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-iterationer för att skapa nyckeln för ett återställningskuvert. Ingen av dessa härledningar förvandlar en mänsklig inloggningsuppgift till 256 bitar av entropi bara för att utmatningen är 256 bitar lång.

Hur PBKDF2 skyddar ditt mönster

Grundidén bakom PBKDF2 är medvetet arbete. Funktionen tar det serialiserade mönstret eller den 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 den för varje kandidat, även om parallell hårdvara och implementeringsval 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 ett WhenUnlockedThisDeviceOnly-objekt i Keychain. 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 in i krypterade filrubriker. Det krypterade valvindexet innehåller filposter, datum, storleksinformation, lagringslayout och den omslutna 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 enda konstruktion för autentiserad kryptering i 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 omsluter den slumpmässiga huvudnyckeln; huvudnyckeln skyddar filmaterialet. CryptoKit skapar autentiserade förseglade block med nya nonces, medan Vaultaires streamingformat härleder en egen nonce för varje ordnat segment. De relevanta garantierna kommer från nyckelseparation, nonce-disciplin och autentisering, inte från ett andra metadatachiffer.

Zero-knowledge-arkitektur

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. En apps säkerhet är bara lika stark som företagets 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 appens process 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 delger Vaultaire ett föreläggande som kräver valvets klartext har företaget inte mönstret, återställningsfrasen, valvnyckeln, säkerhetskopieringsnyckeln eller huvudnyckeln som behövs för att dekryptera det. Krypterade iCloud-poster finns i användarens privata CloudKit-databas. På enheten hålls dock återställningsmaterial i en krypterad Keychain-databas, och symmetriska nycklar finns i appens minne 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 lämna ut för rutinmässig valvåterställning. Den levererade appen, iOS, den upplåsta enheten och den kryptografiska implementeringen kan fortfarande bearbeta läsbara data och måste därför vara betrodda.

Nyckelringen och gränsen för appens process

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

Vaultaire använder vanliga generiska lösenordsobjekt i iOS Keychain för det slumpmässiga enhetssaltet, den krypterade å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-exporterbar Secure Enclave-nyckel.

När du ritar mönstret härleder CommonCrypto valvnyckeln i appens process. 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 angripare med tillräcklig behörighet som observerar en upplåst session har andra möjligheter än en granskare som bara har chiffertext från en låst enhet.

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å processisolering i iOS, Keychain och dataskydd. Den hävdar inte att ett intrång på rotnivå 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 filer 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-förseglingsoperation. Filrubriker och filinnehåll förseglas separat, och stora filer använder ett autentiserat streamingformat med en slumpmässig basnonce och en egen nonce för varje ordnat segment. Två kopior av samma foto ger därför inte samma krypterade representation.

Nonces 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 kryptering i ett steg och registrerar basnoncen i streaminghuvudet. 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: rensning av aktivt nyckeltillstånd

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åses eller sessionen avslutas följer dess kod flera rensningsvägar:

• Aktivt valvtillstånd släpps. 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 bytecontainrar skriver över buffertarna de äger när containrarna avallokeras.
• Cachat huvudnyckeltillstånd ogiltigförklaras. 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. Rensning av miniatyrer och förhandsvisningar minskar kvarvarande apptillstå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ärleder 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. Vid en krasch tar iOS tillbaka processen, men rensningskoden kan inte köras efter varje abrupt avslutning.