Sikkerhetsmodell

Beskyttelsen starter før opplasting

Innebygde hvelv fungerer lokalt uten Revault-konto. Filinnhold, filnavn, MIME-typer, miniatyrbilder, hvelvnavn, mapper, etiketter og favoritter krypteres på enheten. Lokal bruk laster ikke opp hvelvfiler til Revault. Innebygd skysynkronisering og deling er valgfrie, separate handlinger.

Modellen forutsetter et pålitelig operativsystem, en pålitelig installert app og en pålitelig kryptografisk tilfeldighetskilde når et hvelv opprettes eller låses opp. Noen som bare har krypterte filer og nøkkelinnpakninger, kan ikke dekryptere dem uten den nødvendige hemmeligheten. Skadevare eller en kompromittert app som kjører mens et hvelv er åpent, kan fange opp klartekst og nøkler.

Uavhengige nøkler for hvert hvelv

Hvert hvelv starter med en tilfeldig 256-bits AES-hovednøkkel, generert med operativsystemets kryptografiske tilfeldighetskilde. Bevegelsen bestemmer ikke denne nøkkelen direkte. Hvert hvelv har uavhengig hovednøkkelmateriale, så avsløring av én hvelvnøkkel utleder ikke en annen.

Et enhetsmønster kombinerer den ordnede punktsekvensen med en tilfeldig 256-bits enhetshemmelighet. Den resulterende inndataen normaliseres med NFKC og sendes til PBKDF2-HMAC-SHA-256 med et nytt 128-bits salt og 600 000 iterasjoner. Den utledede 256-bits nøkkelen pakker inn hovednøkkelen med AES-256-GCM. Appen lagrer ikke et mønster i klartekst eller noe eget fingeravtrykk av mønsteret.

Mønstre bruker et 5 × 5-rutenett med seks til 25 ulike punkter og må være unike for alle hvelv som er registrert på samme enhet. Et mønster som stemmer, åpner bare sitt eget hvelv, og andre hvelvs navn og innhold forblir skjult. Forutsigbare bevegelser er fortsatt lettere å gjette. En person som får tak i både en enhetshemmelighet og den krypterte innpakningen, kan prøve å gjette mønstre offline.

For å åpne et innebygd hvelv kreves det lokale mønsteret eller en uttrykkelig gjenopprettingsflyt, ikke en Revault-konto eller tilgangsnøkkel (passkey). Valgfri skysynkronisering bruker plattformens Apple- eller Google-godkjenning, og kjøp i butikken bruker plattformens faktureringskonto. Verken skygodkjenning eller et kjøp gir en dekrypteringsnøkkel til hvelvet.

Nøkkelbeskyttelse bare på enheten

På iOS lagres enhetslåsen som et ikke-synkroniserende Nøkkelringelement med beskyttelsen WhenUnlockedThisDeviceOnly. Det er bare tilgjengelig mens enheten er låst opp, og flyttes ikke via Nøkkelringsynkronisering. Den lagrede hemmeligheten er ikke en Secure Enclave-nøkkel.

På Android krypteres enhetslåsen med AES-256-GCM under en Android Keystore-nøkkel som ikke kan eksporteres, og som krever en opplåst enhet. Den krypterte låsfilen ligger i appens no-backup-mappe. Maskinvarestøtte i Keystore avhenger av enheten, og appen lover ikke at alle enheter bruker maskinvarestøttede nøkler.

Lokale opplåsingshemmeligheter er utelatt fra innebygd skysynkronisering og bærbare hvelvsikkerhetskopier. Å ha en Apple- eller Google-konto gjenskaper ikke disse hemmelighetene og låser ikke automatisk opp et gjenopprettet hvelv. En ny enhet må bekrefte den uavhengige gjenopprettingshemmeligheten og registrere sitt eget mønster.

Konfidensialitet og oppdagelse av manipulering

Hvelvmetadata, filmetadata, miniatyrbilder og innpakkede nøkler bruker AES-256-GCM med autentiseringsmerker på 128 bit. Hver uavhengige kryptering bruker en ny, tilfeldig nonce på 96 bit. Dekryptering verifiserer merket før klartekst returneres. Endret chiffertekst eller feil nøkkel gjør at autentiseringen mislykkes.

Tilleggsdata som autentiseres, binder hvert krypterte objekt til formatversjonen, hvelvidentifikatoren, objektidentifikatoren og formålet. For eksempel bruker et miniatyrbilde og en filmetadatapost ulike kontekster. Hvis et kryptert objekt flyttes til et annet hvelv eller erstatter et annet objekt, endres den autentiserte konteksten og verifiseringen mislykkes.

Autentisert kontekst skjuler ikke identifikatorer og beviser ikke ferskhet. En gyldig eldre post kan fortsatt ha et gyldig merke. Revisjonskontroller i applikasjonen oppdager vanlige samtidige oppdateringer, men dette er ikke et kryptografisk forsvar mot en ondsinnet tjeneste som spiller av en hel eldre tilstand på nytt.

Store filer bruker autentiserte segmenter

Innebygd filkryptering bruker AES-256-GCM-HKDF-SHA-256-strømkonstruksjonen som Tink beskriver. iOS bruker CryptoKit for AES-GCM og HKDF, mens Android bruker plattformens kryptografiske primitiver. Hver ny strøm har et 40-byte-hode som inneholder en lengdemarkør, et tilfeldig 32-byte-salt og et tilfeldig sju-byte nonce-prefiks.

HKDF utleder en egen filkrypteringsnøkkel fra hvelvets hovednøkkel. Konteksten omfatter hvelv- og filidentifikatorene, klartekstens bytelengde og den konfigurerte segmentstørrelsen. Hvert segments nonce på 12 byte kombinerer det tilfeldige prefikset, en segmentteller på fire byte og et flagg for siste segment. Segmentene har GCM-merker på 128 bit.

De innebygde appene behandler filer i avgrensede segmenter på omtrent 5 MiB. Segmenttellere, flagget for siste segment og forventede bytelengder avdekker endrede, omrokkerte eller avkortede segmenter. Hvert segment autentiseres før bruk, og en privat forhåndsvisning publiseres først når filen er ferdig dekryptert. Ufullstendig utdata forkastes ved feil, og nye forsøk overfører de eksisterende krypterte bytene.

Konstruksjonen følger Tink AES-GCM-HKDF-strømspesifikasjonen. Revaults implementering og segmentkonfigurasjon er ikke uavhengig revidert eller sertifisert av Tink.

Privat lagring, importer og forhåndsvisninger

Krypterte hvelvfiler ligger i privat applagring. Filnavn, MIME-typer, mapper, etiketter, favoritter og miniatyrbilder er autentiserte krypterte poster. Søk og etikettfiltrering virker på det aktive hvelvets dekrypterte metadata etter opplåsing, og det finnes ingen søkeindeks i klartekst på serveren.

Import av bilder, videoer og filer kan bruke privat midlertidig mellomlagring før kryptering. Opptak med kameraet i hvelvet lagrer ikke automatisk en kopi i galleriet. Import fra Bilder eller en annen leverandør lar leverandørens original være intakt. Valgfri medieoptimalisering skjer lokalt før kryptering og endrer bare nyimportert medieinnhold.

Private forhåndsvisninger krever midlertidig klartekst mens de er åpne. Appene fjerner de midlertidige forhåndsvisningene ved lukking, låsing og neste oppstart. iOS bruker full filbeskyttelse på dekrypterte forhåndsvisningsfiler. Filer som uttrykkelig eksporteres til en annen app, forlater hvelvets beskyttelse. Sletting av midlertidige filer er ikke en garanti for rettsteknisk sletting.

Valgfri innebygd skysynkronisering

Synkronisering er av som standard og slås på separat for hvert hvelv på hver enhet. iOS lagrer krypterte poster og filsegmenter i brukerens private CloudKit-database i iCloud. Android bruker Google Drives private appDataFolder. Ingen av transportene krever en Revault-konto eller laster opp innebygde synkroniseringsdata til Revaults nettsky.

Skyen mottar krypterte metadata, filsegmenter og nøkkelinnpakninger, ikke en hovednøkkel til hvelvet i klartekst, en lokal enhetshemmelighet eller en gjenopprettingshemmelighet. En annen enhet på samme plattform trenger samme innebygde skykonto og hvelvets gjenopprettingsnøkkel for å registrere sitt eget lokale mønster. Apple- og Google-godkjenning styrer tilgangen til de krypterte postene, ikke dekrypteringen av dem.

Når du slår av synkronisering, stopper videre overføringer for det hvelvet fra den aktuelle enheten, mens eksisterende krypterte skykopier blir værende. Synkronisering kan spre endringer og slettinger, og samtidige redigeringer kan kreve konfliktgjennomgang. iCloud og Google Drive er separate lagre, uten automatisk bro mellom plattformene. Bruk en kryptert telefonoverføring for å flytte mellom iPhone og Android.

Gjenoppretting er en andre vei til samme nøkkel

Genererte gjenopprettingsfraser består av 18 uavhengig valgte ord fra en medfølgende liste på 2048 ord, og gir 198 biter tilfeldighet. Du kan i stedet velge en egendefinert frase med minst seks forskjellige ord og 32–512 tegn. Styrken avhenger da av valgene dine. Begge avleder hver for seg en innpakningsnøkkel med PBKDF2-HMAC-SHA-256 og et nytt salt, og pakker deretter inn den samme hovednøkkelen til hvelvet med AES-256-GCM. Alle som har frasen og det krypterte hvelvet, kan dekryptere det.

Gjenopprettingshemmeligheten vises under oppsettet og lagres ikke i appens innebygde lagring og lastes ikke opp til innebygd skylagring. Oppbevar den adskilt fra de krypterte filene. For å registrere en annen enhet kreves det krypterte hvelvet fra den opprinnelige innebygde skykontoen, eller en kryptert sikkerhetskopi, pluss gjenopprettingsnøkkelen. En hemmelighet kan ikke gjenopprette manglende fildata, og Revault har ingen tilbakestillingsnøkkel som leverandøren har.

En bærbar .qvault-sikkerhetskopi inneholder krypterte nøkkelinnpakninger, en autentisert kryptert filoversikt og krypterte filsegmenter. Den utelater den lokale opplåsingshemmeligheten på enheten. Importen verifiserer filoversikten, metadataene og hvert segment før den gjenoppretter til et hvelv med nye identifikatorer, ny hovednøkkel, nye filnøkler og et nytt enhetsmønster. Lagre den nye gjenopprettingsnøkkelen etter gjenopprettingen.

Nye gjenopprettingsfraser beholder store og små bokstaver, normaliserer Unicode med NFKC og slår sammen ekstra mellomrom. Eldre heksadesimale nøkler støttes fortsatt. Du kan bytte gjenopprettingsfrasen til et hvelv i innstillingene etter at du har lagret den nye frasen. Dette erstatter den gjeldende gjenopprettingsinnpakningen. Gamle sikkerhetskopier og enheter som ikke har synkronisert, kan fortsatt ha den gamle innpakningen. Hvis du bytter mønster eller gjenopprettingsfrase, roteres ikke hovednøkkelen til hvelvet, og kopier tilbakekalles ikke. Hvis nøkkelmateriale er kompromittert, flytter du filene til et nytt hvelv med nye nøkler.

Kryptert overføring fra telefon til telefon

Telefonoverføring lager en bærbar kryptert kopi med nye hvelvidentifikatorer, ny hovednøkkel, nye filnøkler og nye strømhoder. Den uavhengige overføringshemmeligheten kan ikke låse opp kildehvelvet, og kildens gjenopprettingshemmelighet og enhetens opplåsingshemmelighet er ikke med. Den krypterte pakken og overføringshemmeligheten må leveres separat.

Den mottakende appen autentiserer pakken og filsegmentene og gjenoppretter til et nytt hvelv med nytt lokalt mønster og ny gjenopprettingsnøkkel. Dette fungerer mellom iOS og Android uten å bygge bro mellom skykontoene deres. Originalen blir på den gamle enheten. Bekreft det gjenopprettede innholdet og lagre den nye gjenopprettingsnøkkelen før du sletter den.

Låsing og opprydding av økten

Mobilappene låses umiddelbart når de legges i bakgrunnen, og som standard etter 60 sekunders inaktivitet. Hvert hvelv kan velge 30 sekunder, 1 minutt, 2 minutter, 5 minutter eller 10 minutter. Et delt hvelv bruker standarden på 60 sekunder. Når du avslutter, kommer du tilbake til mønsterskjermen, og den dekrypterte økten avsluttes.

Låsing avbryter øktarbeid, fjerner dekrypterte metadata og søketilstand, lukker forhåndsvisninger, fjerner midlertidige filer og overskriver nøkkelbuffere før de frigis. Midlertidige utledningsnøkler fjernes også etter bruk. Minnehåndteringen i Swift og JVM, kryptografibibliotek og mediedekodere kan lage kopier, og umiddelbar sletting av hver eneste kopi kan ikke garanteres.

iOS dekker øyeblikksbilder i appbytteren med et personvernskjold. Android bruker flagget for sikkert vindu for å begrense skjermbilder og forhåndsvisninger i nylige apper. Disse plattformbeskyttelsene hindrer ikke noen i å fotografere en opplåst skjerm, og de trekker ikke tilbake filer som tidligere er eksportert til en annen app.

Revault Cloud

Revault Cloud er en valgfri Pro-lagringsleverandør for synkronisering på tvers av plattformer. Krypterte segmenter og krypterte filmetadata knyttes til en pseudonym faktureringsinstallasjon. Tjenesten kan se lagringsidentifikatorer, størrelser, kontrollsummer, revisjoner og overføringsaktivitet, men mottar aldri en ubeskyttet hvelvnøkkel eller gjenopprettingsfrase. En separat tilfeldig tilkoblingskode gir tilgang til lagringen; for å koble til en ekstra enhet kreves også gjenopprettingsfrasen. Eksisterende skydata forblir lesbare for gjenoppretting etter at Pro har utløpt.

Uavhengige nøkler for hver deling

En innebygd deling er et øyeblikksbilde av utvalgte filer, ikke tilgang til eierens personlige hvelv. Som standard utleder appen nøklene til de valgte filversjonene og pakker dem inn med AES-256-GCM under en ny hovednøkkel for delingen. Den gjenbruker de krypterte filbytene, mens metadata og miniatyrbilder krypteres på nytt for delingen. Kildehvelvets nøkler, gjenopprettingshemmelighet, mappestruktur, etiketter og favoritter er utelatt.

Delingen har sin egen uavhengig genererte dekrypteringsfrase på 18 ord og sin egen gjenopprettingsinnpakning. Avsenderen gir den hemmelige koden videre privat, atskilt fra invitasjonslenken. Serveren mottar krypterte data, aldri den ukrypterte delingsnøkkelen eller dekrypteringshemmeligheten. Mottakeren kan ikke avlede nøkler til filer som ikke er delt, eller hovednøkkelen til kildehvelvet, fra nøklene til de valgte filene.

Den valgfrie innstillingen for ekstra isolering krypterer filinnholdet på nytt med nye nøkler og strømhoder. Standarden er raskere fordi den unngår å omskrive hver fil, men gjentatt chiffertekst kan korrelere kopier av den samme filversjonen. Begge modusene lager et separat øyeblikksbilde, og ingen av dem kan trekke tilbake chiffertekst og nøkler som en mottaker allerede har beholdt.

Innebygde delingstransporter og tilgangskontroller

På iOS plasserer en privat, skrivebeskyttet CloudKit-invitasjon det krypterte øyeblikksbildet i et separat delingsposthierarki utenfor den personlige synkroniseringssonen. Apple styrer tilgangen til invitasjonen, og mottakeren trenger fortsatt den separate dekrypteringshemmeligheten. CloudKit-invitasjoner håndhever ikke serverens antall tilgangsøkter, faste utløp eller destruksjonstimer. Eieren kan stoppe fremtidig CloudKit-tilgang.

Delinger på tvers av plattformer laster opp krypterte deler til Revaults delingstjeneste. Uavhengige, tilfeldige 256-bits lese- og administrasjonstilganger lagres som SHA-256-hasher. Nettstedlenken bærer lesetilgangen i fragmentet, ikke dekrypteringshemmeligheten. Når den åpnes, går den rett til et delt hvelv og ber om avsenderens hemmelige kode. Ingen personlig mønster eller eksisterende hvelv er nødvendig. Personlige hvelv forblir låst.

Kontrollerte serverdelinger håndhever avsenderens maksimale antall tilgangsøkter, faste utløp innen 30 dager, tilbakekalling og valgfri eksporttillatelse. En økt gis atomisk og varer høyst 15 minutter, avgrenset av delingens frister. En tilgang telles når økten gis, selv om nedlasting eller dekryptering mislykkes. Visningen kontrollerer pågående tilgang og lukkes ved fristen.

SHA-256-sjekksummer verifiserer de overførte delene, mens autentisert kryptering verifiserer innholdet i dem. Når eksport er tillatt, kan visningen lagre en kryptert .qvault-kopi som åpnes med den hemmelige koden for delingen. Hvis du slår av eksport, fjernes den handlingen i appen, men det kan ikke kryptografisk hindre skjermbilder eller en modifisert klient i å beholde klartekst. Å slette en kildefil trekker ikke tilbake en deling som er opprettet uavhengig.

En frist etter første tilgang

En avsender kan slå på en separat tidtaker for ødeleggelse. Den starter atomisk når den første serverøkten innvilges, selv om overføring eller dekryptering senere mislykkes. Alle senere økter deler samme frist, og ny åpning nullstiller den aldri. Den tidligste av fast utløpstid, ødeleggelsestidspunkt og øktutløp gjelder. Ved fristen nekter tjenesten ytterligere lesing og setter chifferteksten i kø for sletting, mens den innebygde visningen lukkes og frigir delingsnøklene og de midlertidige filene sine. Oppryddingen er asynkron og kan ikke slette skjermbilder, data en modifisert klient har beholdt, eller kopier som er eksportert tidligere.

Valgfri hvelvaktivitet

Revisjonslogger i appen er slått av som standard og konfigureres per hvelv på hver enhet. De siste 500 lokale hendelsene krypteres med hvelvets hovednøkkel og en egen autentisert kontekst. De utelater nøkler, mønstre, filinnhold og data fra andre hvelv, synkroniseres ikke og kan tømmes eller slås av. De er ikke bevis som er sikret mot manipulering. Mislykkede opplåsinger knyttes ikke til noe hvelv.

Nye kontrollerte delinger opprettet med logging slått på beholder opptil 100 tidsstempler for tilgangsøkter på delingstjenesten. Bare administrasjonskapabiliteten kan hente dem. Loggen inneholder ingen mottakeridentitet eller dekrypteringshemmelighet. Hvis du slår av lokal logging, påvirker det fremtidige delinger. Eksisterende delingslogger beholder sin opprinnelige innstilling til tilbakekalling eller utløp og opprydding.

Valgfrie krypterte innbruddsbilder

Eiere kan slå på Innbruddsvarsler separat for hvert hvelv på hver enhet. Etter tre mønstre som ikke stemmer, kan appen i forgrunnen ta et bilde med frontkameraet, avhengig av tillatelse, kameratilgjengelighet og en nedkjøling på ett minutt. Systemets kameraindikatorer er fortsatt synlige. De ti siste varslene lagres lokalt og legges aldri til i Bilder eller lastes opp. Et mønster som ikke stemmer, avgjør ikke hvilket hvelv som er målet, så hvert hvelv som er valgt, får en separat kryptert enhetsforsøkspost.

En dedikert offentlig RSA-3072-nøkkel pakker inn en ny AES-GCM-nøkkel på 256 bit for hvert varsel med OAEP, SHA-256 og MGF1-SHA-256. Dette gjør kryptering mulig mens hvelvet er låst. Den tilhørende private nøkkelen er selv kryptert under hvelvets hovednøkkel med en egen autentisert kontekst. Bare opplåsing av det hvelvet kan dekryptere bildene. Varsler vises i revisjonsvisningen uavhengig av vanlig aktivitetslogging og kan tømmes i innstillingene for Innbruddsvarsler. De er ikke bevis som er sikret mot manipulering.

Trygg utgang fjerner lokal tilgang

Ett hvelv på en enhet kan utpekes til Trygg utgang. Når du tegner mønsteret til det hvelvet, åpnes det som vanlig, mens de andre lokale hvelvoppføringene, de krypterte databitene, opplåsingsmaterialet på enheten og køede endringer fjernes. Appen har en varig lokal tillatelsesliste, slik at synkronisering ikke i det stille kan fylle opp utelatte hvelv igjen. Krypterte overføringer som allerede pågår, kan fortsatt bli ferdige.

Skykopier fra den innebygde skytjenesten og kopier på andre enheter blir værende. Eksplisitt gjenoppretting krever gjenopprettingsnøkkelen til det utelatte hvelvet før et nytt lokalt mønster registreres. Et hvelv som bare finnes frakoblet og uten egen sikkerhetskopi, kan gå tapt. Denne innstillingen gjelder den aktuelle installasjonen, ikke alle enheter som bruker samme skykonto.

Trygg utgang er ingen garanti for rettsmedisinsk sletting eller skjuling. Flashlagring, hurtigbuffere i operativsystemet, sikkerhetskopier og tidligere eksporter kan beholde spor. Hvis du fjerner appdata eller installerer appen på nytt, kan den lokale isolasjonen forsvinne, og skyoppføringer kan da bli oppdaget på nytt via den innebygde skykontoen. Bare gjenopprettingshemmeligheten kan låse opp disse oppføringene.

Hva som fortsatt er synlig

Kryptering skjuler innhold, ikke all driftsinformasjon. Lokale oppføringer og skyleverandører kan se identifikatorer, forhold mellom oppføringer, antall objekter, størrelser, revisjoner, tidsstempler, krypterte nøkkelinnpakninger og strømhoder. Identifikatorene bruker UUIDv7 og inneholder opplysninger om opprettelsestidspunkt, så de er ikke hemmelige. Apple eller Google kan knytte innebygd synkroniseringsaktivitet til plattformkontoen.

Revaults kontrollerte delingstjeneste kan se størrelsen på krypterte pakker, sjekksummer for delene, utløpsinnstillinger, antall tilgangsøkter og eventuelle tidsstempler for økter, men ikke den dekrypteringshemmeligheten som leveres separat. CloudKit-deling gir Apple innsyn i invitasjons- og deltakerinformasjon. Nettverks- og driftslogger kan avsløre tilkoblingsinformasjon. Revault gir ikke anonymitet eller motstand mot trafikkanalyse.

HTTPS beskytter nettverksforespørsler underveis. Autentisert kryptering på enheten beskytter hvelvinnholdet som er lagret lokalt og i skyen, uavhengig av dette. Verken transportkryptering eller chiffertekst skjuler alt om når, hvor eller hvor mye data som overføres.

Bruksanalyse

Aktivert som standard. Mixpanel mottar hendelser om funksjonsbruk med en tilfeldig analyse-ID. Hvelvinnhold, navn, mønstre, nøkler og hemmelige koder for deling er utelatt. Du kan når som helst slå av analyse for denne nettleseren eller enheten.

Der beskyttelsen slutter

Et opplåst hvelv gjør nødvendigvis dekryptert informasjon tilgjengelig for appøkten. Skadevare, et kompromittert operativsystem eller en kompromittert app, noen som ser på skjermen, eller en mottaker du ikke stoler på, kan fange den opp. Nøkkellagring bare på enheten er en ekstra barriere, ikke en garanti mot en fullstendig kompromittert enhet. Et forutsigbart mønster er utrygt så snart den lokale hemmeligheten er kompromittert.

Kryptering hindrer ikke sletting i skyen, løsepengevirus, tap av en gjenopprettingshemmelighet, at en leverandør holder tilbake oppføringer, eller tilbakerulling av en hel tidligere gyldig kryptert tilstand. Ha uavhengige krypterte sikkerhetskopier, og kontroller at gjenoppretting fungerer før du fjerner en gammel enhet. Tilbakekalling kan ikke ta tilbake skjermbilder, eksporter eller kopier som en annen person allerede har beholdt.

Revault har ikke vært gjennom en uavhengig sikkerhetsrevisjon. Dette er beskrivelser av den implementerte kryptografiske utformingen, ikke en sertifisering eller en garanti mot alle inntrengninger.

Eksisterende nettleserhvelv

Denne oversikten beskriver de innebygde mobilappene. Eksisterende nettleserhvelv har en egen konto-, enhetslagrings- og nettskymodell. Nettleserspesifikke S3-opplastinger og delingslenker i nettleseren er ikke innebygd skysynkronisering. Nettleserkontoen logger deg ikke inn i mobilappene. Bruk en kryptert sikkerhetskopi og gjenopprettingsnøkkelen til den for å flytte eksisterende nettleserdata til et hvelv i mobilappen.