CRIPTOGRAFIE ȘI ÎNCREDERE

Model de securitate

O referință tehnică pentru Revault pe iOS și Android: cum îți protejează datele seifurile locale, cheile dispozitivului, sincronizarea nativă în cloud și partajările independente și unde se opresc aceste protecții.

Referință tehnică · Actualizat în octombrie 2026

Protecția începe înainte de încărcare

Seifurile native funcționează local, fără cont Revault. Conținutul fișierelor, numele fișierelor, tipurile MIME, miniaturile, numele seifurilor, folderele, etichetele și favoritele sunt criptate pe dispozitiv. Utilizarea locală nu încarcă fișierele seifului în Revault. Sincronizarea nativă în cloud și partajarea sunt operațiuni opționale și separate.

Modelul presupune un sistem de operare, o aplicație instalată și o sursă aleatorie criptografică de încredere la crearea sau deblocarea unui seif. Cineva care are doar fișiere criptate și învelitori de chei nu le poate decripta fără secretul necesar. Malware-ul sau o aplicație compromisă care rulează cât timp un seif este deschis poate captura text simplu și chei.

Dispozitivul tăuText clar și cheia seifului
Criptare localăText cifrat autentificat
Stocare criptatăNicio cheie de seif în text clar

Chei independente pentru fiecare seif

Fiecare seif începe cu o cheie principală AES aleatorie de 256 de biți, generată folosind sursa aleatorie criptografică a sistemului de operare. Gestul nu determină direct această cheie. Fiecare seif are material independent pentru cheia principală, deci dezvăluirea cheii unui seif nu o derivă pe a altuia.

Un model de deblocare al dispozitivului combină secvența ordonată de puncte cu un secret aleatoriu al dispozitivului de 256 de biți. Intrarea rezultată este normalizată cu NFKC și trecută prin PBKDF2-HMAC-SHA-256 cu o sare nouă de 128 de biți și 600.000 de iterații. Cheia derivată de 256 de biți învelește cheia principală folosind AES-256-GCM. Aplicația nu salvează un model în text simplu și nici o amprentă separată a modelului.

Modelele de deblocare folosesc o grilă 5 × 5 cu șase până la 25 de puncte distincte și trebuie să fie unice între seifurile înrolate pe același dispozitiv. Un model corespunzător deschide doar seiful său; numele și conținutul celorlalte seifuri rămân ascunse. Gesturile previzibile sunt totuși mai ușor de ghicit. O persoană care obține atât un secret al dispozitivului, cât și învelitoarea lui criptată poate încerca ghicirea offline a modelului.

Deschiderea unui seif nativ necesită modelul lui local de deblocare sau un flux explicit de recuperare, nu un cont Revault sau un passkey. Sincronizarea opțională în cloud folosește autorizarea Apple sau Google a platformei, iar achizițiile din magazin folosesc contul de facturare al platformei. Nici autorizarea cloud, nici o achiziție nu furnizează o cheie de decriptare a seifului.

Parametri criptografici
ScopConstrucție
Cheia principală a seifuluiCheie AES aleatorie de 256 de biți
Învelirea cheilorPBKDF2-HMAC-SHA-256 · 600.000 de iterații · salt de 128 de biți → AES-256-GCM
Metadate și miniaturiAES-256-GCM · nonce aleatoriu de 96 de biți · etichetă de autentificare de 128 de biți
Derivarea cheii fișieruluiHKDF-SHA-256 · salt aleatoriu de 256 de biți pentru fiecare fișier · ieșire AES de 256 de biți
Secretul de recuperareGenerată: 18 cuvinte aleatorii (198 de biți); personalizată: cel puțin 6 cuvinte distincte și 32–512 de caractere

Protecția cheilor doar pe dispozitiv

Pe iOS, blocarea dispozitivului este stocată ca element Keychain nesincronizat, cu protecția WhenUnlockedThisDeviceOnly. Este accesibilă doar cât timp dispozitivul este deblocat și nu migrează prin sincronizarea Keychain. Secretul stocat nu este o cheie Secure Enclave.

Pe Android, blocarea dispozitivului este criptată cu AES-256-GCM sub o cheie Android Keystore neexportabilă, care necesită un dispozitiv deblocat. Fișierul de blocare criptat se află în directorul no-backup al aplicației. Suportul hardware Keystore depinde de dispozitiv; aplicația nu promite că fiecare dispozitiv folosește chei susținute hardware.

Secretele locale de deblocare sunt excluse din sincronizarea nativă în cloud și din backup-urile portabile ale seifului. Deținerea unui cont Apple sau Google nu recreează acele secrete și nu deblochează automat un seif restaurat. Un dispozitiv nou trebuie să verifice secretul de recuperare independent și să-și înroleze propriul model de deblocare.

Confidențialitate și detectarea alterării

Metadatele seifului, metadatele fișierelor, miniaturile și cheile învelite folosesc AES-256-GCM cu etichete de autentificare de 128 de biți. Fiecare criptare independentă folosește un nonce aleatoriu nou de 96 de biți. Decriptarea verifică eticheta înainte de a returna textul clar; textul cifrat modificat sau o cheie greșită face ca autentificarea să eșueze.

Datele suplimentare autentificate leagă fiecare obiect criptat de versiunea formatului, identificatorul seifului, identificatorul obiectului și scopul lui. De exemplu, o miniatură și o înregistrare de metadate ale fișierului folosesc contexte diferite. Mutarea unui obiect criptat într-un alt seif sau înlocuirea lui cu alt obiect schimbă contextul autentificat și verificarea eșuează.

Contextul autentificat nu ascunde identificatorii și nu dovedește prospețimea. O înregistrare mai veche, dar validă, poate avea în continuare o etichetă validă. Verificările de revizie ale aplicației detectează actualizările concurente obișnuite, dar aceasta nu este o apărare criptografică împotriva unui serviciu rău intenționat care reia o stare completă mai veche.

Fișierele mari folosesc segmente autentificate

Criptarea nativă a fișierelor folosește construcția de streaming AES-256-GCM-HKDF-SHA-256 descrisă de Tink. iOS folosește CryptoKit pentru AES-GCM și HKDF; Android folosește primitive criptografice ale platformei. Fiecare flux nou are un antet de 40 de octeți care conține un marcaj de lungime, o sare aleatorie de 32 de octeți și un prefix nonce aleatoriu de șapte octeți.

HKDF derivă o cheie separată de criptare a fișierului din cheia principală a seifului. Contextul ei include identificatorii seifului și ai fișierului, lungimea în octeți a textului clar și dimensiunea configurată a segmentului. Nonce-ul de 12 octeți al fiecărui segment combină prefixul aleatoriu, un contor de segment de patru octeți și un indicator de ultim segment. Segmentele poartă etichete GCM de 128 de biți.

Aplicațiile native procesează fișierele în segmente limitate de aproximativ 5 MiB. Contoarele de segmente, indicatorul ultimului segment și lungimile așteptate în octeți detectează segmentele modificate, reordonate sau trunchiate. Fiecare segment este autentificat înainte de utilizare, iar o previzualizare privată este publicată doar după ce fișierul ei termină de decriptat. Ieșirea incompletă este eliminată în caz de eroare; reîncercările transferă octeții criptați existenți.

Construcția urmează specificația de streaming Tink AES-GCM-HKDF. Implementarea și configurația segmentelor Revault nu au fost auditate sau certificate independent de Tink.

Stocare privată, importuri și previzualizări

Fișierele criptate ale seifului se află în spațiul privat de stocare al aplicației. Numele fișierelor, tipurile MIME, folderele, etichetele, favoritele și miniaturile sunt înregistrări criptate autentificate. Căutarea și filtrarea după etichete funcționează pe metadatele decriptate ale seifului activ după deblocare; nu există un index de căutare în text simplu pe server.

Importurile de fotografii, videoclipuri și fișiere pot folosi un spațiu privat temporar înainte de criptare. Captura cu camera în interiorul seifului nu salvează automat o copie în galerie. Importul din Fotografii sau de la alt furnizor lasă intact originalul acelui furnizor. Optimizarea opțională a conținutului media are loc local înainte de criptare și modifică doar conținutul media nou importat.

Previzualizările private necesită text simplu temporar cât timp sunt deschise. Aplicațiile elimină previzualizările temporare la închidere, la blocare și la pornirea ulterioară; iOS aplică protecție completă a fișierelor pentru fișierele de previzualizare decriptate. Fișierele exportate explicit într-o altă aplicație părăsesc protecția seifului. Ștergerea fișierelor temporare nu este o garanție de ștergere criminalistică.

Sincronizare nativă opțională în cloud

Sincronizarea este dezactivată implicit și se activează separat pentru fiecare seif de pe fiecare dispozitiv. iOS stochează înregistrări criptate și segmente de fișiere în baza de date CloudKit privată a utilizatorului din iCloud. Android folosește appDataFolder privat din Google Drive. Niciunul dintre transporturi nu necesită un cont Revault și nici nu încarcă datele de sincronizare nativă în cloudul web Revault.

Cloudul primește metadate criptate, segmente de fișiere și învelitori de chei, nu o cheie principală de seif în text simplu, un secret local al dispozitivului sau un secret de recuperare. Un alt dispozitiv de pe aceeași platformă are nevoie de același cont cloud nativ și de cheia de recuperare a seifului pentru a-și înrola propriul model local de deblocare. Autorizarea Apple și Google controlează accesul la înregistrările criptate, nu decriptarea lor.

Dezactivarea sincronizării oprește transferurile ulterioare pentru acel seif de pe dispozitivul curent; copiile criptate existente din cloud rămân. Modificările și ștergerile din sincronizare se pot propaga, iar editările simultane pot necesita revizuirea conflictelor. iCloud și Google Drive sunt stocări separate, fără o punte automată între platforme. Folosește un transfer criptat între telefoane pentru a trece între iPhone și Android.

Recuperarea este o a doua cale către aceeași cheie

Frazele de recuperare generate conțin 18 cuvinte alese independent dintr-o listă încorporată de 2.048 de cuvinte, oferind 198 de biți de aleatoriu. Poți alege în schimb o frază personalizată cu cel puțin șase cuvinte distincte și 32–512 de caractere; puterea ei depinde de alegerile tale. Ambele derivă independent o cheie de învelire folosind PBKDF2-HMAC-SHA-256 și un salt nou, apoi învelesc aceeași cheie principală a seifului cu AES-256-GCM. Oricine are fraza și seiful criptat îl poate decripta.

Secretul de recuperare este afișat în timpul configurării și nu este păstrat în stocarea aplicației native și nici încărcat în stocarea cloud nativă. Păstrează-l separat de fișierele criptate. Înrolarea unui alt dispozitiv necesită seiful criptat din contul cloud nativ original sau un backup criptat, plus cheia de recuperare. Un secret nu poate restaura datele lipsă ale fișierelor, iar Revault nu are o cheie de resetare deținută de furnizor.

Un backup portabil .qvault conține învelitori de chei criptate, un inventar criptat autentificat și segmente de fișiere criptate. Exclude secretul local de deblocare al dispozitivului. Importul verifică inventarul, metadatele și fiecare segment înainte de restaurarea într-un seif cu identificatori noi, cheie principală, chei de fișiere și un nou model de deblocare al dispozitivului. Salvează noua cheie de recuperare după restaurare.

Frazele de recuperare noi păstrează majusculele și minusculele, normalizează Unicode cu NFKC și reduc spațiile suplimentare. Cheile hexazecimale vechi rămân acceptate. Poți înlocui fraza de recuperare a unui seif din setările acestuia, după ce salvezi noua frază. Aceasta înlocuiește învelișul de recuperare actual; backupurile vechi și dispozitivele care nu s-au sincronizat pot păstra totuși vechiul înveliș. Schimbarea unui model de deblocare sau a unei fraze de recuperare nu rotește cheia principală a seifului și nu revocă copiile. Dacă materialul cheii este compromis, mută fișierele într-un seif nou, cu chei noi.

Migrare criptată de la telefon la telefon

Transferul între telefoane creează o copie criptată portabilă, cu identificatori de seif noi, cheie principală nouă, chei de fișiere noi și antete de flux noi. Secretul lui de transfer independent nu poate debloca seiful sursă, iar secretul de recuperare sursă și secretul local de deblocare al dispozitivului nu sunt incluse. Pachetul criptat și secretul de transfer trebuie livrate separat.

Aplicația destinatară autentifică pachetul și segmentele lui de fișiere, apoi restaurează într-un seif nou, cu un nou model local de deblocare și o nouă cheie de recuperare. Funcționează între iOS și Android fără a face punte între conturile lor cloud. Originalul rămâne pe dispozitivul vechi; confirmă conținutul restaurat și salvează noua cheie de recuperare înainte de a-l șterge.

Blocare și curățarea sesiunii

Aplicațiile mobile se blochează imediat când trec în fundal și implicit după 60 de secunde de inactivitate. Fiecare seif poate alege 30 de secunde, 1 minut, 2 minute, 5 minute sau 10 minute. Un seif partajat folosește valoarea implicită de 60 de secunde. Ieșirea revine la ecranul modelului de deblocare și încheie sesiunea decriptată.

Blocarea anulează activitatea sesiunii, șterge metadatele decriptate și starea căutării, închide previzualizările, elimină fișierele temporare și suprascrie bufferele de chei deținute înainte de a le elibera. Cheile temporare de derivare sunt de asemenea șterse după utilizare. Gestionarea memoriei în Swift și JVM, bibliotecile criptografice și decodoarele media pot crea copii; ștergerea imediată a fiecărei copii nu poate fi garantată.

iOS acoperă capturile comutatorului de aplicații cu un ecran de confidențialitate. Android folosește indicatorul de fereastră securizată pentru a restricționa capturile de ecran și previzualizările aplicațiilor recente. Aceste protecții ale platformei nu împiedică pe cineva să fotografieze un ecran deblocat și nu retrag fișierele exportate anterior într-o altă aplicație.

Revault Cloud

Revault Cloud este un furnizor opțional de stocare Pro pentru sincronizare între platforme. Segmentele criptate și metadatele criptate ale fișierelor sunt asociate cu o instalare de facturare pseudonimă. Serviciul poate observa identificatorii de stocare, dimensiunile, sumele de control, reviziile și activitatea de transfer, dar nu primește nicio cheie de seif decriptată și nicio frază de recuperare. Un cod de conectare aleatoriu separat autorizează accesul la stocare; conectarea unui alt dispozitiv necesită și fraza de recuperare. Datele existente din cloud rămân lizibile pentru recuperare după expirarea Pro.

Chei independente pentru fiecare partajare

O partajare nativă este un instantaneu al fișierelor selectate, nu acces la seiful personal al proprietarului. Implicit, aplicația derivă cheile versiunilor de fișiere selectate și le învelește cu AES-256-GCM sub o cheie principală nouă a partajării. Reutilizează octeții criptați ai fișierelor, în timp ce re-criptează metadatele și miniaturile pentru partajare. Cheile seifului sursă, secretul lui de recuperare, structura folderelor, etichetele și favoritele sunt excluse.

Partajarea are propria frază de decriptare de 18 cuvinte, generată independent, și propriul înveliș de recuperare. Expeditorul transmite acest secret în privat, separat de link-ul de invitație. Serverul primește date criptate, niciodată cheia de partajare în text clar sau secretul de decriptare. Destinatarul nu poate deriva cheile fișierelor nepartajate sau cheia principală a seifului sursă din cheile fișierelor selectate.

Setarea opțională de izolare suplimentară re-criptează conținutul fișierelor cu chei și antete de flux noi. Valoarea implicită este mai rapidă, deoarece evită rescrierea fiecărui fișier; textul cifrat repetat poate corela copiile aceleiași versiuni de fișier. Ambele moduri creează un instantaneu separat și niciunul nu poate retrage textul cifrat și cheile păstrate deja de un destinatar.

Transporturi native de partajare și controale de acces

Pe iOS, o invitație CloudKit privată, doar pentru citire, plasează instantaneul criptat într-o ierarhie separată de înregistrări de partajare, în afara zonei personale de sincronizare. Apple controlează accesul la invitație; destinatarul are în continuare nevoie de secretul de decriptare separat. Invitațiile CloudKit nu impun numărul de sesiuni de acces, expirarea fixă sau cronometrul de distrugere ale serverului. Proprietarul poate opri accesul CloudKit viitor.

Partajările între platforme încarcă părți criptate în serviciul de partajare Revault. Capabilitățile independente aleatorii de citire și de gestionare, de 256 de biți, sunt stocate ca hash-uri SHA-256. Linkul site-ului poartă capabilitatea de citire în fragmentul său, nu secretul de decriptare. Deschiderea lui face deep-link către un seif partajat și solicită secretul expeditorului; nu este necesar niciun model personal de deblocare sau seif existent. Seifurile personale rămân blocate.

Partajările controlate prin server impun numărul maxim de sesiuni de acces al expeditorului, expirarea fixă în maximum 30 de zile, revocarea și permisiunea opțională de export. O sesiune este acordată atomic și durează cel mult 15 minute, limitată de termenele partajării. O accesare se numără când sesiunea este acordată, chiar dacă descărcarea sau decriptarea eșuează. Vizualizatorul verifică accesul în curs și se închide la termen.

Sumele de control SHA-256 verifică părțile transferate, iar criptarea autentificată le verifică conținutul. Când exportul este permis, vizualizatorul poate salva o copie .qvault criptată, care se deschide cu secretul partajării. Dezactivarea exportului elimină această acțiune din aplicație; nu poate împiedica criptografic capturile de ecran sau un client modificat care păstrează textul necriptat. Ștergerea unui fișier sursă nu revocă o partajare creată independent.

Un termen după prima accesare

Un expeditor poate activa un temporizator de distrugere separat. Acesta pornește atomic când este acordată prima sesiune de acces pe server, chiar dacă transferul sau decriptarea eșuează ulterior. Fiecare sesiune ulterioară are același termen; redeschiderea nu îl resetează niciodată. Se aplică cea mai apropiată dintre expirarea fixă, momentul distrugerii și expirarea sesiunii. La termen, serviciul refuză citirile ulterioare și pune textul cifrat în coadă pentru ștergere, în timp ce vizualizatorul nativ se închide și eliberează cheile partajării și fișierele temporare. Curățarea este asincronă și nu poate șterge capturile de ecran, datele păstrate de un client modificat sau copiile exportate mai devreme.

Activitatea opțională a seifului

Jurnalele de audit native sunt dezactivate implicit și se configurează pentru fiecare seif, pe fiecare dispozitiv. Ultimele 500 de evenimente locale sunt criptate cu cheia principală a seifului și un context autentificat dedicat. Ele exclud chei, modele, conținutul fișierelor și datele altor seifuri, nu se sincronizează și pot fi șterse sau dezactivate. Nu sunt dovezi rezistente la alterare. Deblocările eșuate nu sunt atribuite unui seif.

Partajările controlate noi create cu jurnalizarea activată păstrează până la 100 de marcaje de timp ale sesiunilor de acces pe serviciul de partajare. Doar capabilitatea de gestionare le poate prelua; jurnalul nu conține identitatea destinatarului sau secretul de decriptare. Dezactivarea jurnalizării locale afectează partajările viitoare. Jurnalele partajărilor existente își păstrează setarea inițială până la revocare sau expirare și curățare.

Fotografii criptate opționale la tentative de intruziune

Proprietarii pot activa Alertele de intruziune separat pentru fiecare seif, pe fiecare dispozitiv. După trei modele nepotrivite, aplicația aflată în prim-plan poate captura o fotografie cu camera frontală, în funcție de permisiune, disponibilitatea camerei și o pauză de un minut. Indicatoarele camerei de sistem rămân vizibile. Ultimele zece alerte sunt stocate local și nu sunt adăugate niciodată în Fotografii sau încărcate. Un model nepotrivit nu identifică un seif țintă, așa că fiecare seif înscris primește o înregistrare de încercare a dispozitivului criptată separat.

O cheie publică RSA-3072 dedicată învelește o cheie AES-GCM nouă de 256 de biți pentru fiecare alertă, folosind OAEP cu SHA-256 și MGF1-SHA-256. Acest lucru permite criptarea cât timp seiful este blocat. Cheia privată corespunzătoare este ea însăși criptată cu cheia principală a seifului, într-un context autentificat dedicat. Doar deblocarea acelui seif poate decripta fotografiile sale. Alertele apar în vizualizarea sa de audit independent de jurnalizarea obișnuită a activității și pot fi șterse din setările Alertelor de intruziune. Nu sunt dovezi rezistente la alterare.

Ieșirea sigură elimină accesul local

Un singur seif de pe un dispozitiv poate fi desemnat pentru Ieșire sigură. Introducerea modelului său de deblocare îl deschide normal, în timp ce celelalte înregistrări locale de seif, fragmentele criptate, materialul de deblocare al dispozitivului și modificările aflate în coadă sunt eliminate. Aplicația păstrează o listă locală permanentă de excepții, astfel încât sincronizarea să nu repopuleze pe tăcute seifurile excluse. Transferurile criptate deja în curs se pot totuși finaliza.

Copiile din cloud-ul nativ și copiile de pe alte dispozitive rămân. Recuperarea explicită necesită cheia de recuperare a seifului exclus înainte de a configura un nou model de deblocare local. Un seif doar offline, fără backup separat, poate fi pierdut. Această setare se aplică instalării curente, nu fiecărui dispozitiv care folosește același cont cloud.

Ieșirea sigură nu garantează ștergerea criminalistică sau ascunderea completă. Memoria flash, cache-urile sistemului de operare, backupurile și exporturile anterioare pot păstra urme. Eliminarea datelor aplicației sau reinstalarea pot elimina bariera de izolare locală; înregistrările din cloud pot fi apoi descoperite din nou prin contul cloud nativ. Doar secretul de recuperare poate debloca aceste înregistrări.

Ce rămâne vizibil

Criptarea ascunde conținutul, nu toate informațiile operaționale. Înregistrările locale și furnizorii de cloud pot observa identificatori, relațiile dintre înregistrări, numărul de obiecte, dimensiuni, revizii, marcaje temporale, învelișuri de chei criptate și anteturi de flux. Identificatorii folosesc UUIDv7 și includ informații despre momentul creării; nu sunt secrete. Apple sau Google pot asocia activitatea de sincronizare nativă cu contul platformei.

Serviciul controlat de partajare al Revault poate observa dimensiunile pachetelor criptate, sumele de control ale părților, setările de expirare, numărul de sesiuni de acces și, opțional, marcajele temporale ale sesiunilor, dar nu secretul de decriptare livrat separat. Partajarea prin CloudKit expune Apple informațiile despre invitații și participanți. Înregistrările de rețea și cele operaționale pot expune informații despre conexiune. Revault nu oferă anonimat și nici rezistență la analiza traficului.

HTTPS protejează cererile de rețea în timpul transmiterii. Criptarea autentificată de pe dispozitiv protejează separat conținutul seifului stocat local și în cloud. Nici criptarea transportului, nici textul cifrat nu ascund orice detaliu despre când, unde sau cât de multe date sunt transferate.

Statistici de utilizare

Activate implicit. Mixpanel primește evenimente de utilizare a funcțiilor cu un ID de analiză aleatoriu. Conținutul seifurilor, numele, modelele de deblocare, cheile și codurile secrete de partajare sunt excluse. Poți dezactiva statisticile oricând pentru acest browser sau dispozitiv.

Unde se oprește protecția

Un seif deblocat expune în mod necesar informații decriptate sesiunii aplicației. Programele malware, un sistem de operare sau o aplicație compromisă, cineva care se uită pe ecran sau un destinatar de încredere îndoielnică le pot captura. Stocarea cheilor doar pe dispozitiv este o barieră suplimentară, nu o garanție împotriva unui dispozitiv complet compromis. Un model de deblocare previzibil nu este sigur dacă secretul său local este compromis.

Criptarea nu împiedică ștergerea din cloud, ransomware-ul, pierderea unui secret de recuperare, reținerea înregistrărilor de către un furnizor sau revenirea la o stare criptată anterioară, dar încă validă. Păstrează backupuri criptate independente și verifică recuperarea înainte de a elimina un dispozitiv vechi. Revocarea nu poate retrage capturi de ecran, exporturi sau copii deja păstrate de altă persoană.

Revault nu a trecut printr-un audit de securitate independent. Acestea sunt descrieri ale designului criptografic implementat, nu o certificare sau o garanție împotriva oricărei intruziuni.

Seifuri de browser existente

Această referință descrie aplicațiile native. Seifurile existente din browser au un cont separat, o stocare separată pe dispozitiv și un model de cloud web separat. Încărcările S3 specifice browserului și link-urile de partajare din browser nu reprezintă sincronizare cloud nativă. Contul din browser nu te autentifică în aplicațiile mobile; folosește un backup criptat și cheia sa de recuperare pentru a muta datele existente din browser într-un seif nativ.

Securitate și arhitectură