KRYPTOGRAFI OCH FÖRTROENDE

Säkerhetsmodell

En teknisk referens för Revault på iOS och Android: hur lokala valv, enhetsnycklar, inbyggd molnsynkronisering och oberoende delningar skyddar dina data, och var det skyddet tar slut.

Teknisk referens · Uppdaterad oktober 2026

Skyddet börjar före uppladdningen

Inbyggda valv fungerar lokalt utan Revault-konto. Filinnehåll, filnamn, MIME-typer, miniatyrer, valvnamn, mappar, taggar och favoriter krypteras på enheten. Lokal användning laddar inte upp valvfiler till Revault. Inbyggd molnsynkronisering och delning är valfria, separata åtgärder.

Modellen förutsätter ett pålitligt operativsystem, en pålitlig installerad app och en pålitlig kryptografisk slumpkälla när ett valv skapas eller låses upp. Den som bara har krypterade filer och nyckelpaket kan inte dekryptera dem utan den nödvändiga hemligheten. Skadlig kod eller en komprometterad app som körs medan ett valv är öppet kan fånga klartext och nycklar.

Din enhetKlartext och valvnyckel
Kryptera lokaltAutentiserad chiffertext
Krypterad lagringIngen valvnyckel i klartext

Oberoende nycklar för varje valv

Varje valv börjar med en slumpmässig 256-bitars AES-huvudnyckel, som genereras med operativsystemets kryptografiska slumpkälla. Gesten bestämmer inte den här nyckeln direkt. Varje valv har oberoende huvudnyckelmaterial, så om en valvnyckel röjs går det inte att härleda en annan.

Ett enhetsmönster kombinerar sin ordnade punktsekvens med en slumpmässig 256-bitars enhetshemlighet. Den resulterande indatan normaliseras med NFKC och skickas till PBKDF2-HMAC-SHA-256 med ett nytt 128-bitars salt och 600 000 iterationer. Den härledda 256-bitarsnyckeln paketerar huvudnyckeln med AES-256-GCM. Appen sparar inget mönster i klartext och inget separat mönsteravtryck.

Mönster använder ett 5 × 5-rutnät med sex till 25 olika punkter och måste vara unika bland valv som är registrerade på samma enhet. Ett matchande mönster öppnar bara sitt eget valv; andra valvs namn och innehåll förblir dolda. Förutsägbara gester är fortfarande lättare att gissa. Den som kommer över både en enhetshemlighet och dess krypterade inslagning kan försöka gissa mönster offline.

För att öppna ett inbyggt valv krävs dess lokala mönster eller ett uttryckligt återställningsflöde, inte ett Revault-konto eller en passkey. Valfri molnsynkronisering använder plattformens auktorisering från Apple eller Google, och köp i butiken använder plattformens faktureringskonto. Varken molnauktorisering eller ett köp ger någon dekrypteringsnyckel för valvet.

Kryptografiska parametrar
ÄndamålKonstruktion
Valvets huvudnyckelSlumpmässig 256-bitars AES-nyckel
NyckelomslutningPBKDF2-HMAC-SHA-256 · 600 000 iterationer · 128-bitars salt → AES-256-GCM
Metadata och miniatyrerAES-256-GCM · slumpmässig 96-bitars nonce · 128-bitars autentiseringstagg
Härledning av filnyckelHKDF-SHA-256 · slumpmässigt 256-bitars salt per fil · 256-bitars AES-utdata
ÅterställningshemlighetGenererad: 18 slumpmässiga ord (198 bitar); egen: minst 6 olika ord och 32–512 tecken

Nyckelskydd som bara finns på enheten

På iOS lagras enhetslåset som ett Keychain-objekt som inte synkroniseras, med skyddet WhenUnlockedThisDeviceOnly. Det är bara åtkomligt medan enheten är upplåst och migreras inte via Keychain-synkronisering. Den lagrade hemligheten är ingen Secure Enclave-nyckel.

På Android krypteras enhetslåset med AES-256-GCM under en icke-exporterbar Android Keystore-nyckel som kräver en upplåst enhet. Den krypterade låsfilen ligger i appens katalog utan säkerhetskopiering. Hårdvarustödet i Keystore beror på enheten; appen lovar inte att varje enhet använder hårdvarustödda nycklar.

Lokala upplåsningshemligheter undantas från inbyggd molnsynkronisering och portabla valvsäkerhetskopior. Att ha ett Apple- eller Google-konto återskapar inte de hemligheterna och låser inte automatiskt upp ett återställt valv. En ny enhet måste verifiera den oberoende återställningshemligheten och registrera sitt eget mönster.

Konfidentialitet och manipuleringsdetektering

Valvmetadata, filmetadata, miniatyrer och omslutna nycklar använder AES-256-GCM med 128-bitars autentiseringstaggar. Varje oberoende kryptering använder en ny slumpmässig 96-bitars nonce. Dekrypteringen verifierar taggen innan klartext returneras; ändrad chiffertext eller fel nyckel gör att autentiseringen misslyckas.

Ytterligare autentiserad data binder varje krypterat objekt till dess formatversion, valvidentifierare, objektidentifierare och ändamål. Till exempel använder en miniatyr och en filmetadatapost olika sammanhang. Om ett krypterat objekt flyttas till ett annat valv eller byts ut mot ett annat objekt ändras det autentiserade sammanhanget och verifieringen misslyckas.

Autentiserat sammanhang döljer inte identifierare och bevisar inte färskhet. En giltig äldre post kan fortfarande ha en giltig tagg. Applikationens revisionskontroller upptäcker vanliga samtidiga uppdateringar, men det är inget kryptografiskt skydd mot en illasinnad tjänst som spelar upp ett helt äldre tillstånd igen.

Stora filer använder autentiserade segment

Inbyggd filkryptering använder den strömmande konstruktionen AES-256-GCM-HKDF-SHA-256 som beskrivs av Tink. iOS använder CryptoKit för AES-GCM och HKDF; Android använder plattformens kryptografiska primitiver. Varje ny ström har ett 40-byte-huvud som innehåller en längdmarkör, ett slumpmässigt 32-byte-salt och ett slumpmässigt nonce-prefix på sju byte.

HKDF härleder en separat filkrypteringsnyckel från valvets huvudnyckel. Dess sammanhang omfattar valv- och filidentifierare, klartextens längd i byte och den konfigurerade segmentstorleken. Varje segments 12-byte-nonce kombinerar det slumpmässiga prefixet, en fyra byte lång segmenträknare och en flagga för sista segmentet. Segmenten har 128-bitars GCM-taggar.

De inbyggda apparna bearbetar filer i begränsade segment på ungefär 5 MiB. Segmenträknare, flaggan för sista segmentet och förväntade längder i byte upptäcker ändrade, omordnade eller avkortade segment. Varje segment autentiseras före användning, och en privat förhandsvisning publiceras först när filen har dekrypterats färdigt. Ofullständig utdata kasseras vid fel; nya försök överför de befintliga krypterade byten.

Konstruktionen följer Tinks specifikation för AES-GCM-HKDF-strömning. Revaults implementation och segmentkonfiguration har inte granskats oberoende eller certifierats av Tink.

Privat lagring, importer och förhandsvisningar

Krypterade valvfiler finns i privat applagring. Filnamn, MIME-typer, mappar, taggar, favoriter och miniatyrer är autentiserade krypterade poster. Sökning och taggfiltrering sker på det aktiva valvets avkrypterade metadata efter upplåsning; det finns inget serverindex för sökning i klartext.

Import av foton, videor och filer kan använda privat tillfällig mellanlagring före kryptering. Fångst med kameran i valvet sparar inte automatiskt en kopia i galleriet. Import från Foton eller en annan leverantör lämnar den leverantörens original orört. Valfri medieoptimering sker lokalt före kryptering och påverkar bara nyligen importerade medier.

Privata förhandsvisningar kräver tillfällig klartext medan de är öppna. Apparna tar bort sina tillfälliga förhandsvisningar vid stängning, låsning och nästa start; iOS tillämpar fullständigt filskydd på avkrypterade förhandsvisningsfiler. Filer som uttryckligen exporteras till en annan app lämnar valvets skydd. Att tillfälliga filer raderas är ingen garanti för forensisk radering.

Valfri inbyggd molnsynkronisering

Synkronisering är avstängd som standard och aktiveras separat för varje valv på varje enhet. iOS lagrar krypterade poster och filsegment i användarens privata CloudKit-databas i iCloud. Android använder Google Drives privata appDataFolder. Ingen av transporterna kräver ett Revault-konto eller laddar upp inbyggda synkroniseringsdata till Revaults webbmoln.

Molnet tar emot krypterad metadata, filsegment och nyckelpaket, inte en huvudnyckel för valvet i klartext, en lokal enhetshemlighet eller en återställningshemlighet. En annan enhet på samma plattform behöver samma inbyggda molnkonto och valvets återställningsnyckel för att registrera sitt eget lokala mönster. Auktorisering från Apple och Google styr åtkomsten till de krypterade posterna, inte deras dekryptering.

Om du stänger av synkroniseringen upphör fler överföringar för det valvet från den aktuella enheten; befintliga krypterade molnkopior finns kvar. Synkroniseringen kan sprida ändringar och raderingar, och samtidiga redigeringar kan kräva granskning av konflikter. iCloud och Google Drive är separata lagringar, utan någon automatisk brygga mellan plattformarna. Använd en krypterad telefonöverföring för att flytta mellan iPhone och Android.

Återställning är en andra väg till samma nyckel

Genererade återställningsfraser innehåller 18 oberoende valda ord från en medföljande lista på 2 048 ord, vilket ger 198 bitar slumpmässighet. Du kan i stället välja en egen fras med minst sex olika ord och 32–512 tecken; dess styrka beror på dina val. Båda härleder oberoende en omslutande nyckel med PBKDF2-HMAC-SHA-256 och ett nytt salt, och omsluter sedan samma huvudnyckel för valvet med AES-256-GCM. Den som har frasen och det krypterade valvet kan dekryptera det.

Återställningshemligheten visas under installationen och sparas inte i den inbyggda appens lagring eller laddas upp till inbyggd molnlagring. Förvara den separat från de krypterade filerna. För att registrera en annan enhet krävs det krypterade valvet från det ursprungliga inbyggda molnkontot, eller en krypterad säkerhetskopia, plus återställningsnyckeln. En hemlighet kan inte återställa saknade fildata, och Revault har ingen återställningsnyckel som leverantören håller.

En portabel .qvault-säkerhetskopia innehåller krypterade nyckelpaket, en autentiserad krypterad förteckning och krypterade filsegment. Den utesluter den lokala upplåsningshemligheten för enheten. Importen verifierar förteckningen, metadata och varje segment innan den återställer till ett valv med nya identifierare, ny huvudnyckel, nya filnycklar och ett nytt enhetsmönster. Spara den nya återställningsnyckeln efter återställningen.

Nya återställningsfraser bevarar skiftläge, normaliserar Unicode med NFKC och slår ihop extra blanksteg. Äldre hexadecimala nycklar stöds fortfarande. Du kan byta ut ett valvs återställningsfras i dess inställningar efter att du har sparat den nya frasen. Det ersätter det nuvarande återställningshöljet; gamla säkerhetskopior och enheter som inte har synkroniserats kan fortfarande ha kvar det gamla höljet. Om du byter mönster eller återställningsfras roteras inte valvets huvudnyckel och kopior återkallas inte. Om nyckelmaterial har röjts bör du flytta filerna till ett nytt valv med nya nycklar.

Krypterad migrering från telefon till telefon

Telefonöverföring skapar en portabel krypterad kopia med nya valvidentifierare, ny huvudnyckel, nya filnycklar och nya strömhuvuden. Dess oberoende överföringshemlighet kan inte låsa upp källvalvet, och källans återställningshemlighet och enhetens upplåsningshemlighet ingår inte. Det krypterade paketet och överföringshemligheten måste levereras separat.

Den mottagande appen autentiserar paketet och dess filsegment och återställer sedan till ett nytt valv med ett nytt lokalt mönster och en ny återställningsnyckel. Det fungerar mellan iOS och Android utan att deras molnkonton behöver kopplas ihop. Originalet finns kvar på den gamla enheten; bekräfta det återställda innehållet och spara den nya återställningsnyckeln innan du raderar det.

Låsning och rensning av sessionen

Mobilapparna låser direkt när de läggs i bakgrunden och som standard efter 60 sekunders inaktivitet. Varje valv kan välja 30 sekunder, 1 minut, 2 minuter, 5 minuter eller 10 minuter. Ett delat valv använder standardvärdet 60 sekunder. Om du avslutar återgår du till mönsterskärmen och den avkrypterade sessionen avslutas.

Låsningen avbryter sessionens arbete, rensar avkrypterad metadata och söktillstånd, stänger förhandsvisningar, tar bort tillfälliga filer och skriver över nyckelbuffertar som appen äger innan de släpps. Tillfälliga härledningsnycklar rensas också efter användning. Minneshanteringen i Swift och JVM, kryptografiska bibliotek och mediaavkodare kan skapa kopior; omedelbar radering av varje kopia kan inte garanteras.

iOS täcker appväxlarens ögonblicksbilder med en integritetssköld. Android använder flaggan för säkra fönster för att begränsa skärmdumpar och förhandsvisningar av senaste appar. Dessa plattformsskydd hindrar inte någon från att fotografera en upplåst skärm, och de drar inte tillbaka filer som tidigare exporterats till en annan app.

Revault Cloud

Revault Cloud är en valfri Pro-lagringsleverantör för synkronisering mellan plattformar. Krypterade segment och krypterad filmetadata kopplas till en pseudonym faktureringsinstallation. Tjänsten kan se lagringsidentifierare, storlekar, kontrollsummor, revisioner och överföringsaktivitet, men får aldrig någon olindad valvnyckel eller återställningsfras. En separat slumpmässig anslutningskod ger åtkomst till lagringen; för att ansluta ytterligare en enhet krävs även återställningsfrasen. Befintliga molndata förblir läsbara för återställning efter att Pro har löpt ut.

Oberoende nycklar för varje delning

En inbyggd delning är en ögonblicksbild av valda filer, inte åtkomst till ägarens personliga valv. Som standard härleder appen nycklarna till de valda filversionerna och paketerar dem med AES-256-GCM under en ny huvudnyckel för delningen. Den återanvänder de krypterade filbyten och krypterar samtidigt om metadata och miniatyrer för delningen. Källvalvets nycklar, dess återställningshemlighet, mappstruktur, taggar och favoriter utesluts.

Delningen har sin egen oberoende genererade dekrypteringsfras på 18 ord och ett eget återställningshölje. Avsändaren överlämnar den hemligheten privat, separat från inbjudningslänken. Servern tar emot krypterade data, aldrig den okrypterade delningsnyckeln eller dekrypteringskoden. Mottagaren kan inte härleda nycklar till ej delade filer eller valvets huvudnyckel från de valda filnycklarna.

Den valfria inställningen för extra isolering krypterar om filinnehållet med nya nycklar och strömhuvuden. Standardläget är snabbare eftersom det undviker att skriva om varje fil; upprepad chiffertext kan korrelera kopior av samma filversion. Båda lägena skapar en separat ögonblicksbild, och inget av dem kan dra tillbaka chiffertext och nycklar som en mottagare redan har.

Transporter och åtkomstkontroller för inbyggd delning

På iOS placerar en privat, skrivskyddad CloudKit-inbjudan den krypterade ögonblicksbilden i en separat hierarki av delningsposter, utanför den personliga synkroniseringszonen. Apple styr åtkomsten till inbjudan; mottagaren behöver fortfarande den separata dekrypteringshemligheten. CloudKit-inbjudningar upprätthåller inte serverns antal åtkomstsessioner, fasta utgångsdatum eller förstörelsetimer. Ägaren kan stoppa framtida åtkomst via CloudKit.

Delningar mellan plattformar laddar upp krypterade delar till Revaults delningstjänst. Oberoende slumpmässiga 256-bitars läs- och hanteringsbehörigheter lagras som SHA-256-hashar. Webblänken bär läsbehörigheten i sitt fragment, inte dekrypteringshemligheten. När den öppnas länkar den djupt till ett delat valv och frågar efter avsändarens hemliga kod; inget personligt mönster eller befintligt valv krävs. Personliga valv förblir låsta.

Kontrollerade serverdelningar upprätthåller avsändarens högsta antal åtkomstsessioner, fasta utgångsdatum inom 30 dagar, återkallande och valfritt exporttillstånd. En session beviljas atomärt och varar högst 15 minuter, begränsad av delningens slutpunkter. En åtkomst räknas när sessionen beviljas, även om nedladdningen eller dekrypteringen misslyckas. Visaren kontrollerar pågående åtkomst och stängs vid sin slutpunkt.

SHA-256-checksummor verifierar överförda delar, medan autentiserad kryptering verifierar deras innehåll. När export är tillåten kan mottagaren spara en krypterad .qvault-kopia som öppnas med den hemliga delningskoden. Om du stänger av export tas den åtgärden bort i appen, men det kan inte kryptografiskt hindra skärmdumpar eller en modifierad klient från att behålla klartext. Att ta bort en källfil återkallar inte en delning som skapats separat.

En tidsgräns efter första åtkomsten

En avsändare kan aktivera en separat förstörelsetimer. Den startar atomiskt när den första serveråtkomstsessionen beviljas, även om överföringen eller dekrypteringen senare misslyckas. Varje senare session delar samma tidsgräns; att öppna på nytt nollställer den aldrig. Den tidigaste av fast utgång, förstörelsetid och sessionsutgång gäller. Vid tidsgränsen nekar tjänsten ytterligare läsningar och köar chiffertexten för radering, medan den inbyggda visaren stängs och släpper sina delningsnycklar och tillfälliga filer. Rensningen sker asynkront och kan inte radera skärmdumpar, data som en modifierad klient har behållit eller kopior som exporterats tidigare.

Valfri valvaktivitet

Inbyggda granskningsloggar är avstängda som standard och konfigureras per valv på varje enhet. De senaste 500 lokala händelserna krypteras med valvets huvudnyckel och ett särskilt autentiserat sammanhang. De utesluter nycklar, mönster, filinnehåll och andra valvs data, synkroniseras inte och kan rensas eller inaktiveras. De är inte manipuleringssäkra bevis. Misslyckade upplåsningsförsök kopplas inte till något valv.

Nya kontrollerade delningar som skapas med loggning aktiverad behåller upp till 100 tidsstämplar för åtkomstsessioner hos delningstjänsten. Bara hanteringsbehörigheten kan hämta dem; loggen innehåller ingen mottagaridentitet eller dekrypteringshemlighet. Om du inaktiverar lokal loggning påverkar det framtida delningar. Befintliga delningsloggar behåller sin ursprungliga inställning tills återkallelse eller utgång och rensning.

Valfria krypterade intrångsfoton

Ägare kan aktivera Intrångslarm separat för varje valv på varje enhet. Efter tre felaktiga mönster kan appen i förgrunden ta ett foto med den främre kameran, med förbehåll för behörighet, kameratillgänglighet och en minuts väntetid. Systemets kameraindikatorer förblir synliga. De tio senaste larmen lagras lokalt och läggs aldrig till i Foton eller laddas upp. Ett felaktigt mönster identifierar inte något målvalv, så varje valv som valt funktionen får en separat krypterad post om enhetsförsöket.

En särskild offentlig RSA-3072-nyckel omsluter en ny 256-bitars AES-GCM-nyckel för varje larm med OAEP, SHA-256 och MGF1-SHA-256. Det gör kryptering möjlig medan valvet är låst. Den motsvarande privata nyckeln är i sin tur krypterad under det valvets huvudnyckel med ett särskilt autentiserat sammanhang. Bara upplåsning av det valvet kan dekryptera dess foton. Larmen visas i dess granskningsvy oberoende av vanlig aktivitetsloggning och kan rensas i inställningarna för Intrångslarm. De är inte manipuleringssäkra bevis.

Säker utgång tar bort lokal åtkomst

Ett valv på en enhet kan utses till Säker utgång. När du anger dess mönster öppnas det som vanligt, samtidigt som de övriga lokala valvposterna, krypterade datablock, enhetens upplåsningsmaterial och köade ändringar tas bort. Appen för en beständig lokal tillåtelselista så att synkroniseringen inte i tysthet kan fylla på uteslutna valv igen. Krypterade överföringar som redan pågår kan fortfarande slutföras.

Kopior i den inbyggda molntjänsten och kopior på andra enheter finns kvar. För uttrycklig återställning krävs det uteslutna valvets återställningsnyckel innan ett nytt lokalt mönster registreras. Ett valv som bara finns offline och saknar separat säkerhetskopia kan gå förlorat. Inställningen gäller den aktuella installationen, inte alla enheter som använder samma molnkonto.

Säker utgång är ingen garanterad forensisk radering eller döljning. Flashminne, operativsystemets cacheminnen, säkerhetskopior och tidigare exporter kan innehålla spår. Om du rensar appdata eller installerar om appen kan den lokala avgränsningen försvinna, och molnposter kan då upptäckas igen via det inbyggda molnkontot. Bara återställningshemligheten kan låsa upp dessa poster.

Vad som förblir synligt

Kryptering döljer innehåll, inte all driftinformation. Lokala poster och molnleverantörer kan se identifierare, relationer mellan poster, antal objekt, storlekar, revisioner, tidsstämplar, krypterade nyckelhölje och strömrubriker. Identifierarna använder UUIDv7 och innehåller information om skapandetidpunkt; de är inte hemliga. Apple eller Google kan koppla inbyggd synkroniseringsaktivitet till plattformskontot.

Revaults kontrollerade delningstjänst kan se krypterade paketstorlekar, delars checksummor, utgångsinställningar, antal åtkomstsessioner och valfria sessionstidsstämplar, men inte den separat levererade dekrypteringskoden. CloudKit-delning visar inbjudnings- och deltagarinformation för Apple. Nätverks- och driftsloggar kan avslöja anslutningsinformation. Revault erbjuder inte anonymitet eller skydd mot trafikanalys.

HTTPS skyddar nätverksförfrågningar under överföringen. Autentiserad kryptering på enheten skyddar separat valvets innehåll som lagras lokalt och i molnet. Varken transportkryptering eller chiffertext döljer allt om när, var eller hur mycket data som överförs.

Användningsstatistik

Aktiverat som standard. Mixpanel tar emot händelser om funktionsanvändning med ett slumpmässigt analys-ID. Valvets innehåll, namn, mönster, nycklar och hemliga delningskoder utesluts. Stäng av statistiken när som helst för den här webbläsaren eller enheten.

Var skyddet tar slut

Ett upplåst valv exponerar nödvändigtvis dekrypterad information för appsessionen. Skadlig kod, ett komprometterat operativsystem eller en komprometterad app, någon som tittar på skärmen eller en mottagare du inte litar på kan fånga upp den. Nyckellagring enbart på enheten är en extra barriär, inte en garanti mot en helt komprometterad enhet. Ett förutsägbart mönster är osäkert så fort dess lokala hemlighet har röjts.

Kryptering förhindrar inte molnradering, ransomware, förlorad återställningshemlighet, att en leverantör håller inne poster eller återställning av ett helt tidigare giltigt krypterat tillstånd. Behåll oberoende krypterade säkerhetskopior och kontrollera att återställningen fungerar innan du tar bort en gammal enhet. Återkallelse kan inte dra tillbaka skärmdumpar, exporter eller kopior som en annan person redan har sparat.

Revault har inte genomgått någon oberoende säkerhetsgranskning. Detta är beskrivningar av den implementerade kryptografiska designen, inte en certifiering eller en garanti mot alla intrång.

Befintliga webbläsarvalv

Den här referensen beskriver de inbyggda apparna. Befintliga webbläsarvalv har en separat modell för konto, enhetslagring och webbmoln. Webbläsarspecifika S3-uppladdningar och delningslänkar i webbläsaren är inte inbyggd molnsynkronisering. Webbläsarkontot loggar inte in dig i mobilapparna; använd en krypterad säkerhetskopia och dess återställningsnyckel för att flytta befintliga webbläsardata till ett inbyggt valv.

Säkerhet och arkitektur