Nagsisimula ang proteksyon bago ang upload
Gumagana nang lokal ang mga native vault nang walang Revault account. Naka-encrypt sa device ang laman ng file, filename, MIME type, thumbnail, pangalan ng vault, folder, tag at paborito. Hindi nag-a-upload ng mga vault file sa Revault ang lokal na paggamit. Hiwalay at opsyonal na operasyon ang native cloud sync at pagbabahagi.
Ipinapalagay ng modelo ang mapagkakatiwalaang operating system, naka-install na app at cryptographic random source kapag ginawa o in-unlock ang vault. Hindi made-decrypt ng may naka-encrypt na file at key wrapper lang ang mga ito nang walang kinakailangang secret. Ang malware o nakompromisong app na tumatakbo habang bukas ang vault ay maaaring makakuha ng plaintext at mga key.
Magkakahiwalay na key para sa bawat vault
Nagsisimula ang bawat vault sa random na 256-bit AES master key, na nabuo gamit ang cryptographic random source ng operating system. Hindi direktang tinutukoy ng galaw ang key na ito. May independiyenteng master key material ang bawat vault, kaya ang pagkalantad ng isang vault key ay hindi nagha-hango ng iba pa.
Pinagsasama ng device pattern ang nakaayos na sequence ng tuldok nito at random na 256-bit device secret. Ang nagresultang input ay ni-normalize gamit ang NFKC at ipinapasa sa PBKDF2-HMAC-SHA-256 na may bagong 128-bit salt at 600,000 iteration. Ang hinangong 256-bit key ang bumabalot sa master key gamit ang AES-256-GCM. Hindi nagse-save ang app ng plaintext na pattern o hiwalay na pattern fingerprint.
Gumagamit ang mga pattern ng 5 × 5 na grid na may anim hanggang 25 magkakaibang tuldok at dapat natatangi sa mga vault na naka-enroll sa iisang device. Ang katugmang pattern ay nagbubukas lang ng vault nito; nananatiling nakatago ang pangalan at laman ng ibang vault. Mas madaling hulaan pa rin ang mga predictable na galaw. Ang taong makakakuha ng device secret at ng naka-encrypt na wrapper nito ay maaaring magtangkang manghula ng pattern offline.
Ang pagbubukas ng native vault ay nangangailangan ng lokal nitong pattern o tahasang recovery flow, hindi ng Revault account o passkey. Ang opsyonal na cloud sync ay gumagamit ng awtorisasyon ng Apple o Google ng platform, at ang mga pagbili sa store ay gumagamit ng billing account ng platform. Walang cloud authorization o pagbili na nagbibigay ng decryption key ng vault.
| Layunin | Konstruksyon |
|---|---|
| Master key ng vault | Random na 256-bit AES key |
| Pagbabalot ng susi | PBKDF2-HMAC-SHA-256 · 600,000 iteration · 128-bit salt → AES-256-GCM |
| Metadata at thumbnail | AES-256-GCM · random na 96-bit nonce · 128-bit authentication tag |
| Key derivation ng file | HKDF-SHA-256 · random na 256-bit salt kada file · 256-bit AES output |
| Lihim sa pag-recover | Nabuo: 18 random na salita (198 bit); custom: hindi bababa sa 6 na magkakaibang salita at 32–512 character |
Proteksyon ng key na nasa device lang
Sa iOS, ang device lock ay nakaimbak bilang nonsynchronizing na Keychain item gamit ang proteksyong WhenUnlockedThisDeviceOnly. Naa-access lang ito habang naka-unlock ang device at hindi lumilipat sa pamamagitan ng Keychain sync. Hindi Secure Enclave key ang nakaimbak na secret.
Sa Android, ang device lock ay naka-encrypt gamit ang AES-256-GCM sa ilalim ng hindi ma-export na Android Keystore key na nangangailangan ng naka-unlock na device. Nasa no-backup na directory ng app ang naka-encrypt na lock file. Nakadepende sa device ang hardware backing ng Keystore; hindi nangangako ang app na gumagamit ng hardware-backed na key ang bawat device.
Hindi kasama ang mga lokal na unlock secret sa native cloud sync at portable na backup ng vault. Ang pagkakaroon ng Apple o Google account ay hindi muling bumubuo ng mga secret na iyon o awtomatikong nag-a-unlock ng na-restore na vault. Dapat i-verify ng bagong device ang independiyenteng recovery secret at i-enroll ang sarili nitong pattern.
Pagiging kumpidensyal at pag-detect ng pakikialam
Gumagamit ng AES-256-GCM na may 128-bit authentication tag ang metadata ng vault, metadata ng file, thumbnail, at wrapped na key. Gumagamit ng bagong random na 96-bit nonce ang bawat independiyenteng encryption. Bine-verify ng decryption ang tag bago magbalik ng plaintext; nabibigo ang authentication kapag binago ang ciphertext o mali ang key.
Itinatali ng additional authenticated data ang bawat naka-encrypt na object sa format version, vault identifier, object identifier, at layunin nito. Halimbawa, magkaibang konteksto ang gamit ng thumbnail at ng record ng metadata ng file. Kapag inilipat ang naka-encrypt na object sa ibang vault o ipinalit sa ibang object, nagbabago ang authenticated na konteksto at nabibigo ang verification.
Hindi itinatago ng authenticated na konteksto ang mga identifier at hindi nito pinapatunayan ang pagiging bago. Maaari pa ring may valid na tag ang valid na mas lumang record. Natutukoy ng mga application revision check ang karaniwang magkasabay na update, pero hindi ito cryptographic na depensa laban sa malisyosong serbisyong nag-replay ng buong mas lumang estado.
Gumagamit ng authenticated na segment ang malalaking file
Gumagamit ang native na pag-encrypt ng file ng AES-256-GCM-HKDF-SHA-256 streaming construction na inilalarawan ng Tink. Gumagamit ang iOS ng CryptoKit para sa AES-GCM at HKDF; gumagamit ang Android ng mga cryptographic primitive ng platform. Ang bawat bagong stream ay may 40-byte na header na naglalaman ng length marker nito, random na 32-byte salt at random na pitong-byte na nonce prefix.
Humuhubog ang HKDF ng hiwalay na file encryption key mula sa master key ng vault. Kasama sa konteksto nito ang mga identifier ng vault at file, haba ng plaintext sa byte, at naka-configure na laki ng segment. Pinagsasama ng 12-byte na nonce ng bawat segment ang random na prefix, apat-na-byte na segment counter, at final-segment flag. May 128-bit na GCM tag ang mga segment.
Pinoproseso ng mga native app ang mga file sa mga bounded na segment na humigit-kumulang 5 MiB. Natutukoy ng mga segment counter, final-segment flag at inaasahang haba sa byte ang mga binago, ni-reorder o pinutol na segment. Ina-authenticate ang bawat segment bago gamitin, at ilalathala lang ang pribadong preview pagkatapos matapos ma-decrypt ang file nito. Itinatapon ang hindi kumpletong output kapag nabigo; inililipat muli ng mga retry ang kasalukuyang naka-encrypt na byte.
Sumusunod ang konstruksyon sa Tink AES-GCM-HKDF streaming specification. Hindi pa independiyenteng na-audit o na-certify ng Tink ang implementasyon at configuration ng segment ng Revault.
Pribadong storage, mga import at preview
Nasa pribadong app storage ang mga naka-encrypt na vault file. Ang mga filename, MIME type, folder, tag, paborito at thumbnail ay mga naka-authenticate at naka-encrypt na record. Gumagana ang paghahanap at pag-filter ng tag sa na-decrypt na metadata ng aktibong vault pagkatapos mag-unlock; walang plaintext na search index sa server.
Maaaring gumamit ng pribadong pansamantalang staging bago ang encryption ang pag-import ng larawan, video at file. Hindi awtomatikong nagse-save ng kopya sa gallery ang camera capture sa loob ng vault. Ang pag-import mula sa Photos o ibang provider ay nag-iiwang buo sa orihinal ng provider na iyon. Nangyayari nang lokal bago ang encryption ang opsyonal na media optimization at binabago lang nito ang bagong na-import na media.
Nangangailangan ng pansamantalang plaintext ang mga pribadong preview habang bukas ang mga ito. Inaalis ng mga app ang pansamantalang preview nila sa pagsasara, pag-lock at sa susunod na pagsisimula; naglalapat ang iOS ng kumpletong file protection sa mga na-decrypt na preview file. Lumalabas sa proteksyon ng vault ang mga file na tahasang na-export sa ibang app. Hindi garantiya ng forensic na pagbura ang pagbura ng pansamantalang file.
Opsyonal na native cloud sync
Naka-off ang sync bilang default at na-e-enable nang hiwalay para sa bawat vault sa bawat device. Iniimbak ng iOS ang mga naka-encrypt na record at file segment sa pribadong CloudKit database ng user sa iCloud. Gumagamit ang Android ng pribadong appDataFolder ng Google Drive. Walang transport na nangangailangan ng Revault account o nag-a-upload ng native sync data sa web cloud ng Revault.
Natatanggap ng cloud ang naka-encrypt na metadata, file segment at key wrapper, hindi ang plaintext na vault master key, lokal na device secret o recovery secret. Ang isa pang device sa parehong platform ay nangangailangan ng parehong native cloud account at ng vault recovery key para i-enroll ang sarili nitong lokal na pattern. Kinokontrol ng awtorisasyon ng Apple at Google ang access sa mga naka-encrypt na record, hindi ang decryption ng mga ito.
Ang pag-off ng sync ay humihinto sa mga susunod na paglipat para sa vault na iyon mula sa kasalukuyang device; nananatili ang mga kasalukuyang naka-encrypt na kopya sa cloud. Maaaring maipalaganap ang mga pagbabago at pagbubura ng sync, at ang mga sabay na pag-edit ay maaaring mangailangan ng conflict review. Magkahiwalay na store ang iCloud at Google Drive, na walang awtomatikong cross-platform bridge. Gumamit ng naka-encrypt na phone transfer para lumipat sa pagitan ng iPhone at Android.
Ang recovery ay pangalawang daan sa iisang key
Ang mga nabuong recovery phrase ay may 18 salitang independiyenteng pinili mula sa kasamang listahang may 2,048 salita, na nagbibigay ng 198 bit ng randomness. Puwede ka ring pumili ng custom na phrase na may hindi bababa sa anim na magkakaibang salita at 32–512 character; nakadepende sa mga pinili mo ang lakas nito. Parehong independiyenteng nagbubuo ng wrapping key gamit ang PBKDF2-HMAC-SHA-256 at bagong salt, saka ni-wrap ang parehong vault master key gamit ang AES-256-GCM. Maaaring i-decrypt ng sinumang may phrase at naka-encrypt na vault ang vault.
Ipinapakita ang recovery secret habang nagse-setup at hindi ito pinananatili sa native app storage o ina-upload sa native cloud storage. Itabi ito nang hiwalay sa mga naka-encrypt na file. Ang pag-enroll ng isa pang device ay nangangailangan ng naka-encrypt na vault mula sa orihinal na native cloud account, o ng naka-encrypt na backup, kasama ang recovery key. Hindi maibabalik ng secret ang nawawalang file data, at walang provider-held na reset key ang Revault.
Ang portable na .qvault backup ay naglalaman ng mga naka-encrypt na key wrapper, naka-authenticate at naka-encrypt na inventory at mga naka-encrypt na file segment. Hindi nito kasama ang lokal na device unlock secret. Bine-verify ng import ang inventory, metadata at bawat segment bago mag-restore sa vault na may bagong identifier, master key, file key at bagong device pattern. I-save ang bagong recovery key pagkatapos ng restoration.
Pinapanatili ng mga bagong recovery phrase ang case, nino-normalize ang Unicode gamit ang NFKC at pinagsasama-sama ang sobrang whitespace. Suportado pa rin ang mga legacy na hexadecimal key. Puwede mong palitan ang recovery phrase ng isang vault sa mga setting nito matapos i-save ang bagong phrase. Pinapalitan nito ang kasalukuyang recovery wrapper; maaari pa ring hawak ng mga lumang backup at ng mga device na hindi pa nakaka-sync ang lumang wrapper. Hindi nire-rotate ng pagpapalit ng pattern o recovery phrase ang vault master key at hindi nito nire-revoke ang mga kopya. Kung nakompromiso ang key material, ilipat ang mga file sa bagong vault na may mga bagong key.
Naka-encrypt na paglipat mula telepono papunta sa telepono
Gumagawa ang phone transfer ng portable na naka-encrypt na kopya na may bagong identifier ng vault, master key, file key at stream header. Hindi mabubuksan ng independiyenteng transfer secret nito ang source vault, at hindi kasama ang recovery secret ng source at device unlock secret. Dapat ibigay nang hiwalay ang naka-encrypt na package at ang transfer secret.
Ina-authenticate ng tumatanggap na app ang package at ang mga file segment nito, pagkatapos ay nagre-restore sa bagong vault na may bagong lokal na pattern at recovery key. Gumagana ito sa pagitan ng iOS at Android nang hindi ikinokonekta ang kanilang mga cloud account. Nananatili ang orihinal sa lumang device; kumpirmahin ang na-restore na laman at i-save ang bagong recovery key bago ito burahin.
Pag-lock at paglilinis ng session
Agad nala-lock ang mga mobile app kapag napunta sa background at pagkatapos ng 60 segundong walang aktibidad bilang default. Maaaring piliin ng bawat vault ang 30 segundo, 1 minuto, 2 minuto, 5 minuto o 10 minuto. Gumagamit ang shared vault ng 60 segundong default. Ang paglabas ay bumabalik sa screen ng pattern at tinatapos ang na-decrypt na session.
Kinakansela ng pag-lock ang gawain ng session, nila-clear ang na-decrypt na metadata at search state, isinasara ang mga preview, inaalis ang mga pansamantalang file at ino-overwrite ang mga key buffer bago ilabas ang mga ito. Nila-clear din pagkatapos gamitin ang mga pansamantalang derivation key. Maaaring gumawa ng mga kopya ang memory management ng Swift at JVM, mga cryptographic library at media decoder; hindi magagarantiya ang agarang pagbura ng bawat kopya.
Tinatakpan ng iOS ang mga snapshot ng app switcher gamit ang privacy shield. Gumagamit ang Android ng secure-window flag para higpitan ang mga screenshot at preview ng mga kamakailang app. Hindi napipigilan ng mga proteksyong ito ng platform ang pagkuha ng litrato sa naka-unlock na screen, at hindi nila binabawi ang mga file na na-export na sa ibang app.
Revault Cloud
Ang Revault Cloud ay opsyonal na Pro storage provider para sa cross-platform na sync. Ang mga naka-encrypt na segment at naka-encrypt na metadata ng file ay naka-link sa isang pseudonymous na billing installation. Nakikita ng serbisyo ang mga storage identifier, laki, checksum, revision at aktibidad ng paglilipat, pero hindi ito tumatanggap ng unwrapped na vault key o recovery phrase. Isang hiwalay na random na connection code ang nagbibigay-pahintulot sa access sa storage; kailangan din ang recovery phrase para magkonekta ng isa pang device. Nananatiling nababasa para sa recovery ang kasalukuyang data sa cloud pagkatapos mag-expire ng Pro.
Mga transport at kontrol sa access ng native na pagbabahagi
Sa iOS, ang pribado at read-only na CloudKit invitation ay naglalagay ng naka-encrypt na snapshot sa hiwalay na sharing record hierarchy, sa labas ng personal sync zone. Kinokontrol ng Apple ang access sa invitation; kailangan pa rin ng tatanggap ang hiwalay na decryption secret. Hindi ipinapatupad ng mga CloudKit invitation ang bilang ng access session, fixed expiry o destruction timer ng server. Maaaring ihinto ng may-ari ang mga susunod na CloudKit access.
Nag-a-upload ang mga cross-platform na share ng mga naka-encrypt na bahagi sa sharing service ng Revault. Iniimbak bilang SHA-256 hash ang independiyenteng random na 256-bit na read at management capability. Dala ng link ng website ang read capability sa fragment nito, hindi ang decryption secret. Ang pagbubukas nito ay nagde-deep-link sa shared vault at humihingi ng secret ng nagpadala; walang kailangang personal na pattern o kasalukuyang vault. Nananatiling naka-lock ang mga personal na vault.
Ipinapatupad ng mga kontroladong server share ang maximum na access session ng nagpadala, fixed expiry sa loob ng 30 araw, pag-revoke at opsyonal na pahintulot sa export. Ang session ay ibinibigay nang atomic at tumatagal nang hanggang 15 minuto, na nakatali sa mga deadline ng share. Nabibilang ang access kapag naibigay ang session, kahit mabigo ang download o decryption. Sinusuri ng viewer ang tuloy-tuloy na access at nagsasara sa deadline nito.
Bine-verify ng mga SHA-256 checksum ang mga inilipat na bahagi, habang ang authenticated encryption naman ang nagbe-verify sa laman ng mga ito. Kapag pinapayagan ang export, puwedeng mag-save ang viewer ng naka-encrypt na kopyang .qvault na nabubuksan gamit ang sikretong code ng share. Inaalis ng pag-disable sa export ang application action na iyon; hindi nito cryptographically mapipigilan ang mga screenshot o ang isang binagong client na magtago ng plaintext. Hindi nire-revoke ng pagbura sa source file ang share na hiwalay na ginawa.
Opsyonal na aktibidad ng vault
Naka-off bilang default ang mga native na audit log at kino-configure kada vault sa bawat device. Ang pinakahuling 500 lokal na event ay naka-encrypt gamit ang master key ng vault at nakalaang authenticated na konteksto. Hindi kasama ang mga key, pattern, laman ng file, at data ng ibang vault, hindi sila nagsi-sync, at maaari silang i-clear o i-disable. Hindi sila ebidensyang hindi mapapakialaman. Hindi itinatalaga sa vault ang mga nabigong unlock.
Ang mga bagong kontroladong share na ginawa nang naka-enable ang logging ay nagpapanatili ng hanggang 100 timestamp ng access session sa sharing service. Management capability lang ang makakakuha ng mga ito; walang pagkakakilanlan ng tatanggap o decryption secret ang log. Naaapektuhan ng pag-disable ng lokal na logging ang mga susunod na share. Pinananatili ng mga umiiral na share log ang orihinal nilang setting hanggang sa pagbawi o expiry at cleanup.
Opsyonal na naka-encrypt na larawan ng panghihimasok
Maaaring i-enable ng mga may-ari ang Alerto sa Panghihimasok nang hiwalay para sa bawat vault sa bawat device. Pagkatapos ng tatlong hindi tugmang pattern, maaaring kumuha ng larawan gamit ang front camera ang foreground app, depende sa pahintulot, availability ng camera, at isang-minutong cooldown. Nananatiling nakikita ang mga indicator ng camera ng system. Lokal na iniimbak ang pinakahuling sampung alerto at hindi kailanman idinaragdag sa Photos o ina-upload. Hindi tinutukoy ng hindi tugmang pattern ang target na vault, kaya bawat vault na pumayag ay tumatanggap ng hiwalay na naka-encrypt na record ng pagtatangka sa device.
Binabalot ng nakalaang RSA-3072 public key ang bagong 256-bit AES-GCM key para sa bawat alerto gamit ang OAEP na may SHA-256 at MGF1-SHA-256. Pinapahintulutan nito ang encryption habang naka-lock ang vault. Naka-encrypt mismo ang kaukulang private key gamit ang master key ng vault na may nakalaang authenticated na konteksto. Ang pag-unlock lang ng vault na iyon ang makapagde-decrypt ng mga larawan nito. Lumalabas ang mga alerto sa audit view nito nang hiwalay sa karaniwang activity logging at maaaring i-clear sa mga setting ng Alerto sa Panghihimasok. Hindi sila ebidensyang hindi mapapakialaman.
Inaalis ng Ligtas na Paglabas (Safe Exit) ang lokal na access
Maaaring italaga ang isang vault sa device para sa Safe Exit. Kapag ipinasok ang pattern nito, normal itong bubukas habang inaalis ang iba pang lokal na vault record, naka-encrypt na chunk, device unlock material at mga naka-queue na pagbabago. Nagpapanatili ang app ng permanenteng lokal na allowlist para hindi tahimik na maibalik ng sync ang mga vault na hindi kasama. Maaari pa ring matapos ang mga naka-encrypt na transfer na kasalukuyang isinasagawa.
Mananatili ang mga native cloud copy at ang mga kopya sa ibang device. Para sa tahasang recovery, kailangan ang recovery key ng vault na hindi kasama bago mag-enroll ng bagong lokal na pattern. Maaaring mawala ang isang offline-only na vault na walang hiwalay na backup. Nalalapat ang setting na ito sa kasalukuyang installation, hindi sa bawat device na gumagamit ng parehong cloud account.
Ang Safe Exit ay hindi garantisadong forensic erasure o pagtatago. Maaaring mag-iwan ng bakas ang flash storage, mga cache ng operating system, mga backup at mga naunang export. Ang pag-alis ng app data o muling pag-install ay maaaring mag-alis ng lokal na hangganan ng paghihiwalay; maaaring muling matuklasan ang mga cloud record sa pamamagitan ng native cloud account. Ang recovery secret lang ang makakapag-unlock sa mga record na iyon.
Ang nananatiling nakikita
Itinatago ng encryption ang nilalaman, hindi ang lahat ng operational na impormasyon. Maaaring makita ng mga lokal na record at cloud provider ang mga identifier, ugnayan ng mga record, bilang ng object, laki, revision, timestamp, naka-encrypt na key wrapper at stream header. Gumagamit ang mga identifier ng UUIDv7 at may kasamang impormasyon sa oras ng paglikha; hindi sila sikreto. Maaaring iugnay ng Apple o Google ang native sync activity sa platform account.
Nakikita ng kontroladong sharing service ng Revault ang laki ng mga naka-encrypt na package, checksum ng mga bahagi, setting ng expiry, bilang ng access session at opsyonal na timestamp ng session, pero hindi ang hiwalay na ipinapadalang decryption secret. Ibinubunyag ng CloudKit sharing ang impormasyon ng imbitasyon at kalahok sa Apple. Maaaring maglantad ng impormasyon sa koneksyon ang mga network at operational record. Hindi nagbibigay ang Revault ng anonymity o panlaban sa traffic analysis.
Pinoprotektahan ng HTTPS ang mga network request habang bumibiyahe ang mga ito. Hiwalay namang pinoprotektahan ng on-device authenticated encryption ang laman ng vault na naka-store nang lokal at sa cloud. Hindi naitatago ng transport encryption o ng ciphertext ang lahat ng detalye tungkol sa kung kailan, saan o gaano karaming data ang inililipat.
Pagsusuri ng paggamit (usage analytics)
Naka-enable bilang default. Tumatanggap ang Mixpanel ng mga event ng paggamit ng feature na may random na analytics ID. Hindi kasama ang laman ng vault, mga pangalan, pattern, key at share secret. I-off ang analytics anumang oras para sa browser o device na ito.
Kung saan nagtatapos ang proteksyon
Ang naka-unlock na vault ay kinakailangang maglantad ng decrypted na impormasyon sa app session nito. Maaari itong makuha ng malware, ng nakompromisong operating system o app, ng taong nakatingin sa screen, o ng hindi pinagkakatiwalaang tatanggap. Ang pag-iimbak ng key sa device lang ay karagdagang hangganan, hindi garantiya laban sa ganap na nakompromisong device. Hindi ligtas ang madaling hulaang pattern kapag nakompromiso ang lokal na secret nito.
Hindi napipigilan ng encryption ang pagbura sa cloud, ransomware, pagkawala ng recovery secret, pagtatago ng provider ng mga record, o rollback ng buong naka-encrypt na estado na dating valid. Magtabi ng mga hiwalay na naka-encrypt na backup at tiyaking gumagana ang recovery bago mag-alis ng lumang device. Hindi mababawi ng revocation ang mga screenshot, export o kopyang hawak na ng ibang tao.
Hindi pa dumaan ang Revault sa independiyenteng security audit. Mga paglalarawan ito ng ipinatupad na cryptographic na disenyo, hindi sertipikasyon o garantiya laban sa bawat panghihimasok.
Mga cryptographic na sanggunian
NIST SP 800-38D — GCM authenticated encryptionRFC 8018 — PBKDF2RFC 5869 — HKDFMga kasalukuyang browser vault
Naglalarawan ang reference na ito sa mga native app. May hiwalay na account, device storage at web cloud model ang mga kasalukuyang browser vault. Ang mga S3 upload na para sa browser at mga browser share link ay hindi native cloud sync. Hindi ka isina-sign in ng browser account sa mga mobile app; gumamit ng naka-encrypt na backup at ng recovery key nito para ilipat ang kasalukuyang browser data sa isang native vault.