Beskyttelsen starter før upload
Indbyggede pengeskabe virker lokalt uden en Revault-konto. Filindhold, filnavne, MIME-typer, miniaturebilleder, pengeskabsnavne, mapper, tags og favoritter krypteres på enheden. Lokal brug uploader ikke pengeskabsfiler til Revault. Indbygget cloud-synkronisering og deling er valgfrie, separate handlinger.
Modellen forudsætter et pålideligt operativsystem, en pålidelig installeret app og en pålidelig kryptografisk tilfældighedskilde, når et pengeskab oprettes eller låses op. Den, der kun har krypterede filer og nøgleindpakninger, kan ikke dekryptere dem uden den nødvendige hemmelighed. Malware eller en kompromitteret app, der kører, mens et pengeskab er åbent, kan opsnappe klartekst og nøgler.
Uafhængige nøgler til hvert pengeskab
Hvert pengeskab starter med en tilfældig 256-bit AES-hovednøgle, genereret med operativsystemets kryptografiske tilfældighedskilde. Bevægelsen bestemmer ikke direkte denne nøgle. Hvert pengeskab har uafhængigt hovednøglemateriale, så afsløring af ét pengeskabs nøgle ikke udleder et andet.
Et enhedsmønster kombinerer sin ordnede punktrækkefølge med en tilfældig 256-bit enhedshemmelighed. Det resulterende input normaliseres med NFKC og sendes til PBKDF2-HMAC-SHA-256 med et nyt 128-bit salt og 600.000 iterationer. Den afledte 256-bit nøgle pakker hovednøglen ind med AES-256-GCM. Appen gemmer ikke et mønster i klartekst eller et separat mønsterfingeraftryk.
Mønstre bruger et 5 × 5-gitter med seks til 25 forskellige punkter og skal være unikke på tværs af pengeskabe, der er tilmeldt på den samme enhed. Et matchende mønster åbner kun sit pengeskab; andre pengeskabes navne og indhold forbliver skjult. Forudsigelige bevægelser er stadig lettere at gætte. En person, der får fat i både en enhedshemmelighed og dens krypterede indpakning, kan forsøge offline-gæt på mønstre.
At åbne et indbygget pengeskab kræver dets lokale mønster eller et eksplicit gendannelsesforløb, ikke en Revault-konto eller adgangsnøgle (passkey). Valgfri cloud-synkronisering bruger platformens Apple- eller Google-godkendelse, og køb i butikken bruger platformens betalingskonto. Hverken cloud-godkendelse eller et køb giver en dekrypteringsnøgle til pengeskabet.
| Formål | Konstruktion |
|---|---|
| Pengeskabets hovednøgle | Tilfældig 256-bit AES-nøgle |
| Nøgleindpakning | PBKDF2-HMAC-SHA-256 · 600.000 iterationer · 128-bit-salt → AES-256-GCM |
| Metadata og miniaturebilleder | AES-256-GCM · tilfældig 96-bit nonce · 128-bit autentificeringstag |
| Afledning af filnøgle | HKDF-SHA-256 · tilfældigt 256-bit-salt pr. fil · 256-bit AES-output |
| Gendannelseshemmelighed | Genereret: 18 tilfældige ord (198 bit); brugerdefineret: mindst 6 forskellige ord og 32–512 tegn |
Nøglebeskyttelse kun på enheden
På iOS gemmes enhedslåsen som et ikke-synkroniserende Keychain-element med beskyttelsen WhenUnlockedThisDeviceOnly. Den er kun tilgængelig, mens enheden er låst op, og migrerer ikke via Keychain-synkronisering. Den gemte hemmelighed er ikke en Secure Enclave-nøgle.
På Android krypteres enhedslåsen med AES-256-GCM under en ikke-eksporterbar Android Keystore-nøgle, der kræver en oplåst enhed. Den krypterede låsefil ligger i appens no-backup-mappe. Keystores hardwarestøtte afhænger af enheden; appen lover ikke, at alle enheder bruger hardwarestøttede nøgler.
Lokale oplåsningshemmeligheder er udelukket fra indbygget cloud-synkronisering og transportable pengeskabsbackups. At have en Apple- eller Google-konto genskaber ikke disse hemmeligheder og låser ikke automatisk et gendannet pengeskab op. En ny enhed skal verificere den uafhængige gendannelseshemmelighed og tilmelde sit eget mønster.
Fortrolighed og registrering af manipulation
Pengeskabsmetadata, filmetadata, miniaturebilleder og indpakkede nøgler bruger AES-256-GCM med 128-bit autentificeringstags. Hver uafhængig kryptering bruger en ny tilfældig 96-bit nonce. Dekryptering verificerer tagget, før klartekst returneres; ændret chiffertekst eller en forkert nøgle får autentificeringen til at fejle.
Yderligere autentificerede data (AAD) binder hvert krypteret objekt til dets formatversion, pengeskabsidentifikator, objektidentifikator og formål. Et miniaturebillede og en filmetadatapost bruger for eksempel forskellige kontekster. Hvis et krypteret objekt flyttes til et andet pengeskab eller bruges i stedet for et andet objekt, ændres den autentificerede kontekst, og verificeringen fejler.
Autentificeret kontekst skjuler ikke identifikatorer og beviser ikke friskhed. En gyldig ældre post kan stadig have et gyldigt tag. Applikationens revisionskontroller opdager almindelige samtidige opdateringer, men det er ikke et kryptografisk forsvar mod en ondsindet tjeneste, der afspiller en komplet ældre tilstand igen.
Store filer bruger autentificerede segmenter
Indbygget filkryptering bruger AES-256-GCM-HKDF-SHA-256-streamingkonstruktionen beskrevet af Tink. iOS bruger CryptoKit til AES-GCM og HKDF; Android bruger platformens kryptografiske primitiver. Hver ny stream har et 40-byte-hoved med en længdemarkør, et tilfældigt 32-byte-salt og et tilfældigt nonce-præfiks på syv byte.
HKDF udleder en separat filkrypteringsnøgle fra pengeskabets hovednøgle. Dens kontekst omfatter pengeskabs- og filidentifikatorer, klartekstens længde i byte og den konfigurerede segmentstørrelse. Hvert segments 12-byte-nonce kombinerer det tilfældige præfiks, en fire-byte segmenttæller og et flag for det sidste segment. Segmenter bærer 128-bit GCM-tags.
De indbyggede apps behandler filer i afgrænsede segmenter på cirka 5 MiB. Segmenttællere, flaget for sidste segment og forventede længder i bytes opdager ændrede, omordnede eller afkortede segmenter. Hvert segment autentificeres før brug, og en privat forhåndsvisning offentliggøres først, når dens fil er færdig med at blive dekrypteret. Ufuldstændigt output kasseres ved fejl; nye forsøg overfører de eksisterende krypterede bytes.
Konstruktionen følger Tinks AES-GCM-HKDF-streamingspecifikation. Revaults implementering og segmentkonfiguration er ikke uafhængigt revideret eller certificeret af Tink.
Privat lager, importer og forhåndsvisninger
Krypterede pengeskabsfiler ligger i privat applager. Filnavne, MIME-typer, mapper, tags, favoritter og miniaturebilleder er autentificerede krypterede poster. Søgning og tagfiltrering foregår på det aktive pengeskabs dekrypterede metadata efter oplåsning; der er intet søgeindeks i klartekst på serveren.
Import af fotos, videoer og filer kan bruge privat midlertidigt mellemlager før kryptering. Kameraoptagelse i pengeskabet gemmer ikke automatisk en kopi i galleriet. Import fra Fotos eller en anden udbyder efterlader udbyderens original intakt. Valgfri medieoptimering sker lokalt før kryptering og ændrer kun nyligt importerede medier.
Private forhåndsvisninger kræver midlertidig klartekst, mens de er åbne. Apperne fjerner deres midlertidige forhåndsvisninger ved lukning, låsning og næste opstart; iOS anvender fuld filbeskyttelse på dekrypterede forhåndsvisningsfiler. Filer, der eksplicit eksporteres til en anden app, forlader pengeskabets beskyttelse. Sletning af midlertidige filer er ikke en garanti for forensisk sletning.
Valgfri indbygget cloud-synkronisering
Synkronisering er som standard slået fra og aktiveres separat for hvert pengeskab på hver enhed. iOS gemmer krypterede poster og filsegmenter i brugerens private CloudKit-database i iCloud. Android bruger Google Drives private appDataFolder. Ingen af transportvejene kræver en Revault-konto eller uploader indbyggede synkroniseringsdata til Revaults webcloud.
Skyen modtager krypterede metadata, filsegmenter og nøgleindpakninger, ikke en hovednøgle til pengeskabet i klartekst, en lokal enhedshemmelighed eller en gendannelseshemmelighed. En anden enhed på samme platform har brug for den samme indbyggede cloud-konto og pengeskabets gendannelsesnøgle for at tilmelde sit eget lokale mønster. Apple- og Google-godkendelse styrer adgangen til de krypterede poster, ikke deres dekryptering.
Når synkronisering slås fra, stopper yderligere overførsler for det pengeskab fra den aktuelle enhed; eksisterende krypterede cloudkopier består. Ændringer og sletninger kan blive udbredt, og samtidige redigeringer kan kræve gennemgang af konflikter. iCloud og Google Drive er separate lagre uden en automatisk bro mellem platformene. Brug en krypteret telefonoverførsel for at skifte mellem iPhone og Android.
Gendannelse er en anden vej til den samme nøgle
Genererede gendannelsesfraser består af 18 uafhængigt valgte ord fra en indbygget liste på 2.048 ord og giver 198 bit tilfældighed. Du kan i stedet vælge en brugerdefineret frase med mindst seks forskellige ord og 32–512 tegn; dens styrke afhænger af dine valg. Begge udleder uafhængigt en indpakningsnøgle med PBKDF2-HMAC-SHA-256 og et nyt salt og pakker derefter pengeskabets samme hovednøgle ind med AES-256-GCM. Enhver, der har frasen og det krypterede pengeskab, kan dekryptere det.
Gendannelseshemmeligheden vises under opsætningen og gemmes ikke i indbygget applager eller uploades til indbygget cloud-lager. Opbevar den adskilt fra de krypterede filer. At tilmelde en anden enhed kræver det krypterede pengeskab fra den oprindelige indbyggede cloud-konto eller en krypteret backup samt gendannelsesnøglen. En hemmelighed kan ikke gendanne manglende fildata, og Revault har ingen nulstillingsnøgle hos udbyderen.
En transportabel .qvault-backup indeholder krypterede nøgleindpakninger, en autentificeret krypteret oversigt og krypterede filsegmenter. Den udelukker den lokale oplåsningshemmelighed for enheden. Import verificerer oversigten, metadata og hvert segment, før der gendannes til et pengeskab med nye identifikatorer, ny hovednøgle, nye filnøgler og et nyt enhedsmønster. Gem den nye gendannelsesnøgle efter gendannelsen.
Nye gendannelsesfraser bevarer store og små bogstaver, normaliserer Unicode med NFKC og slår ekstra blanktegn sammen. Ældre hexadecimale nøgler understøttes stadig. Du kan udskifte et pengeskabs gendannelsesfrase i dets indstillinger, efter at du har gemt den nye frase. Det erstatter den nuværende gendannelsesindpakning; gamle backups og enheder, der ikke har synkroniseret, kan stadig have den gamle indpakning. Hvis du skifter mønster eller gendannelsesfrase, roteres pengeskabets hovednøgle ikke, og kopier tilbagekaldes ikke. Hvis nøglemateriale er kompromitteret, skal du flytte filerne til et nyt pengeskab med nye nøgler.
Krypteret overførsel fra telefon til telefon
Telefonoverførsel opretter en transportabel krypteret kopi med nye identifikatorer for pengeskab, ny hovednøgle, nye filnøgler og nye streamhoveder. Dens uafhængige overførselshemmelighed kan ikke låse kildepengeskabet op, og kildens gendannelseshemmelighed og enhedens oplåsningshemmelighed er ikke med. Den krypterede pakke og overførselshemmeligheden skal leveres hver for sig.
Den modtagende app autentificerer pakken og dens filsegmenter og gendanner derefter til et nyt pengeskab med et nyt lokalt mønster og en ny gendannelsesnøgle. Det virker mellem iOS og Android uden at forbinde deres cloud-konti. Originalen forbliver på den gamle enhed; bekræft det gendannede indhold, og gem den nye gendannelsesnøgle, før du sletter den.
Låsning og sessionsoprydning
Mobilapps låser straks, når de sendes i baggrunden, og som standard efter 60 sekunders inaktivitet. Hvert pengeskab kan vælge 30 sekunder, 1 minut, 2 minutter, 5 minutter eller 10 minutter. Et delt pengeskab bruger standarden på 60 sekunder. Afslutning vender tilbage til mønsterskærmen og afslutter den dekrypterede session.
Låsning afbryder sessionens arbejde, rydder dekrypterede metadata og søgetilstand, lukker forhåndsvisninger, fjerner midlertidige filer og overskriver ejede nøglebuffere, før de frigives. Midlertidige afledningsnøgler ryddes også efter brug. Hukommelsesstyring i Swift og JVM, kryptografiske biblioteker og mediedekodere kan oprette kopier; øjeblikkelig sletning af alle kopier kan ikke garanteres.
iOS dækker øjebliksbilleder i appskifteren med et privatlivsskjold. Android bruger flaget for sikkert vindue til at begrænse skærmbilleder og forhåndsvisninger af seneste apps. Disse platformsbeskyttelser forhindrer ikke, at nogen fotograferer en oplåst skærm, og de kalder ikke filer tilbage, som tidligere er eksporteret til en anden app.
Revault Cloud
Revault Cloud er en valgfri Pro-lagringsudbyder til synkronisering på tværs af platforme. Krypterede segmenter og krypterede filmetadata knyttes til en pseudonym faktureringsinstallation. Tjenesten kan se lagringsidentifikatorer, størrelser, kontrolsummer, revisioner og overførselsaktivitet, men modtager aldrig en upakket pengeskabsnøgle eller gendannelsesfrase. En separat tilfældig forbindelseskode giver adgang til lageret; for at tilslutte en ekstra enhed kræves også gendannelsesfrasen. Eksisterende clouddata kan stadig læses til gendannelse, efter at Pro er udløbet.
Transportveje og adgangskontrol for indbygget deling
På iOS placerer en privat, skrivebeskyttet CloudKit-invitation det krypterede udsnit i et separat delingshierarki af poster uden for den personlige synkroniseringszone. Apple styrer adgangen til invitationen; modtageren har stadig brug for den separate dekrypteringshemmelighed. CloudKit-invitationer håndhæver ikke serverens antal adgangssessioner, faste udløb eller destruktionstimer. Ejeren kan stoppe fremtidig CloudKit-adgang.
Delinger på tværs af platforme uploader krypterede dele til Revaults delingstjeneste. Uafhængige tilfældige 256-bit læse- og administrationsrettigheder gemmes som SHA-256-hashes. Webstedets link bærer læserettigheden i sit fragment, ikke dekrypteringshemmeligheden. Når det åbnes, fører det direkte til et delt pengeskab og beder om afsenderens hemmelige kode; der kræves intet personligt mønster eller eksisterende pengeskab. Personlige pengeskabe forbliver låst.
Kontrollerede serverdelinger håndhæver afsenderens maksimale antal adgangssessioner, faste udløb inden for 30 dage, tilbagekaldelse og valgfri eksporttilladelse. En session gives atomisk og varer højst 15 minutter, afgrænset af delingens frister. En adgang tæller, når sessionen gives, selv hvis download eller dekryptering mislykkes. Viseren kontrollerer løbende adgang og lukker ved fristen.
SHA-256-kontrolsummer bekræfter de overførte dele, mens autentificeret kryptering bekræfter deres indhold. Når eksport er tilladt, kan modtageren gemme en krypteret .qvault-kopi, som åbnes med den hemmelige delingskode. Hvis du slår eksport fra, fjernes den handling i appen, men det kan ikke kryptografisk forhindre skærmbilleder eller en ændret klient i at beholde klartekst. Hvis du sletter en kildefil, tilbagekaldes en uafhængigt oprettet deling ikke.
Valgfri pengeskabsaktivitet
Native revisionslogge er slået fra som standard og konfigureres pr. pengeskab på hver enhed. De seneste 500 lokale hændelser krypteres med pengeskabets hovednøgle og en dedikeret autentificeret kontekst. De udelader nøgler, mønstre, filindhold og andre pengeskabes data, synkroniseres ikke og kan ryddes eller deaktiveres. De er ikke manipulationssikre beviser. Mislykkede oplåsninger tildeles ikke et pengeskab.
Nye kontrollerede delinger, der oprettes med logning aktiveret, opbevarer op til 100 tidsstempler for adgangssessioner på delingstjenesten. Kun administrationsrettigheden kan hente dem; loggen indeholder ingen modtageridentitet eller dekrypteringshemmelighed. Hvis du deaktiverer lokal logning, påvirker det fremtidige delinger. Eksisterende delingslogge beholder deres oprindelige indstilling, indtil de tilbagekaldes eller udløber og ryddes op.
Valgfrie krypterede indbrudsfotos
Ejere kan aktivere Indbrudsalarmer separat for hvert pengeskab på hver enhed. Efter tre mislykkede mønstre kan appen i forgrunden tage et frontkamerafoto, afhængigt af tilladelse, kameratilgængelighed og en pause på ét minut. Systemets kameraindikatorer forbliver synlige. De seneste ti alarmer gemmes lokalt og føjes aldrig til Fotos eller uploades. Et mislykket mønster identificerer ikke et målpengeskab, så hvert tilvalgt pengeskab modtager en separat krypteret enhedsforsøgspost.
En dedikeret offentlig RSA-3072-nøgle indpakker en ny 256-bit AES-GCM-nøgle for hver alarm med OAEP, SHA-256 og MGF1-SHA-256. Det gør kryptering mulig, mens pengeskabet er låst. Den tilsvarende private nøgle er selv krypteret under pengeskabets hovednøgle med en dedikeret autentificeret kontekst. Kun oplåsning af det pengeskab kan dekryptere dets fotos. Alarmer vises i dets revisionsvisning uafhængigt af almindelig aktivitetslogning og kan ryddes i indstillingerne for Indbrudsalarmer. De er ikke manipulationssikre beviser.
Sikker udgang fjerner lokal adgang
Ét pengeskab på en enhed kan udpeges til Sikker udgang. Når du tegner dets mønster, åbnes det som normalt, mens de øvrige lokale pengeskabsposter, krypterede bidder, enhedens oplåsningsmateriale og ventende ændringer fjernes. Appen gemmer en permanent lokal tilladelsesliste, så synkronisering ikke i det skjulte kan genskabe de udelukkede pengeskabe. Krypterede overførsler, der allerede er i gang, kan stadig blive færdige.
Kopier i den native cloud og kopier på andre enheder består. Eksplicit gendannelse kræver det udelukkede pengeskabs gendannelsesnøgle, før der oprettes et nyt lokalt mønster. Et pengeskab, der kun findes offline og ikke har en separat backup, kan gå tabt. Denne indstilling gælder for den aktuelle installation, ikke for alle enheder, der bruger den samme cloud-konto.
Sikker udgang er ikke garanteret kriminalteknisk sletning eller skjulning. Flashlager, operativsystemets cacher, backups og tidligere eksporter kan beholde spor. Hvis du fjerner appdata eller geninstallerer, kan den lokale isolation forsvinde, og cloud-poster kan så blive fundet igen via den native cloud-konto. Kun gendannelseshemmeligheden kan låse de poster op.
Hvad der forbliver synligt
Kryptering skjuler indhold, men ikke alle driftsoplysninger. Lokale poster og cloududbydere kan se identifikatorer, relationer mellem poster, antal objekter, størrelser, revisioner, tidsstempler, krypterede nøgleindpakninger og streamhoveder. Identifikatorer bruger UUIDv7 og indeholder oplysninger om oprettelsestidspunktet; de er ikke hemmeligheder. Apple eller Google kan knytte native synkroniseringsaktivitet til platformskontoen.
Revaults kontrollerede delingstjeneste kan se krypterede pakkestørrelser, kontrolsummer for de enkelte dele, udløbsindstillinger, antal adgangssessioner og eventuelt tidsstempler for sessioner, men ikke den separat leverede dekrypteringshemmelighed. CloudKit-deling giver Apple adgang til oplysninger om invitationer og deltagere. Netværks- og driftsposter kan afsløre forbindelsesoplysninger. Revault tilbyder ikke anonymitet eller beskyttelse mod trafikanalyse.
HTTPS beskytter netværksforespørgsler undervejs. Autentificeret kryptering på enheden beskytter særskilt pengeskabets indhold, som er gemt lokalt og i cloud. Hverken transportkryptering eller kryptogrammer skjuler alt om, hvornår, hvor eller hvor meget data der overføres.
Brugsanalyse
Aktiveret som standard. Mixpanel modtager hændelser om brug af funktioner med et tilfældigt analyse-id. Pengeskabets indhold, navne, mønstre, nøgler og delingshemmeligheder er udeladt. Slå analyse fra når som helst for denne browser eller enhed.
Hvor beskyttelsen slutter
Et oplåst pengeskab udsætter nødvendigvis dekrypterede oplysninger for appsessionen. Malware, et kompromitteret operativsystem eller en kompromitteret app, nogen der kigger på skærmen, eller en modtager, du ikke kan stole på, kan fange dem. Nøglelagring udelukkende på enheden er en ekstra barriere, ikke en garanti mod en fuldstændig kompromitteret enhed. Et let at gætte mønster er usikkert, når dets lokale hemmelighed er kompromitteret.
Kryptering forhindrer ikke sletning i cloud, ransomware, tab af en gendannelseshemmelighed, at en udbyder tilbageholder poster, eller at en hel tidligere gyldig krypteret tilstand rulles tilbage. Opbevar uafhængige krypterede backups, og kontrollér gendannelsen, før du fjerner en gammel enhed. Tilbagekaldelse kan ikke kalde skærmbilleder, eksporter eller kopier tilbage, som en anden person allerede har beholdt.
Revault har ikke gennemgået en uafhængig sikkerhedsrevision. Dette er beskrivelser af det implementerede kryptografiske design, ikke en certificering eller en garanti mod ethvert indbrud.
Kryptografiske referencer
NIST SP 800-38D — GCM-autentificeret krypteringRFC 8018 — PBKDF2RFC 5869 — HKDFEksisterende browserpengeskabe
Denne reference beskriver de native apps. Eksisterende browser-pengeskabe har en separat konto-, enhedslager- og webcloud-model. Browserspecifikke S3-uploads og browserdelingslinks er ikke native cloud-synkronisering. Browserkontoen logger dig ikke ind i mobilapps; brug en krypteret backup og dens gendannelsesnøgle til at flytte eksisterende browserdata til et nativt pengeskab.