La protezione inizia prima del caricamento
Il contenuto dei file, i nomi dei file, i tipi MIME, le miniature, i nomi dei depositi, i nomi e la struttura delle cartelle vengono crittografati sul dispositivo prima di essere caricati. Il servizio archivia testo cifrato e chiavi incapsulate. Un intruso che ottiene solo i record archiviati non ottiene la chiave del vault in testo normale, il segreto del dispositivo o la chiave di ripristino.
Ciò presuppone che il browser, il sistema operativo, il codice dell'applicazione fornito e il generatore di numeri casuali siano affidabili quando crei o sblocchi un vault. La crittografia dei dati inattivi non può proteggere un deposito sbloccato da codice dannoso in esecuzione sul tuo dispositivo.
Chiavi indipendenti per ogni caveau
Ogni deposito inizia con una chiave master AES a 256 bit generata casualmente. La chiave viene generata dal generatore di numeri casuali crittografici del browser, anziché derivare direttamente dal tuo gesto. Chiavi dell'insieme di credenziali separate limitano l'effetto della divulgazione di una singola chiave dell'insieme di credenziali.
Un modello di dispositivo combina la sequenza di punti ordinata con un segreto del dispositivo casuale a 256 bit. PBKDF2 con HMAC-SHA-256, un nuovo salt da 128 bit e 600.000 iterazioni derivano una chiave di wrapping da 256 bit. AES-256-GCM quindi crittografa la chiave principale sotto tale chiave di wrapper. Il servizio riceve il wrapper crittografato, il relativo sale e i parametri di derivazione pubblica. Il segreto del dispositivo rimane nel database IndexedDB locale di questo browser.
I modelli utilizzano solo una griglia 5 × 5 e almeno sei punti distinti. I formati di pattern precedenti non sono supportati. Gli archivi esistenti necessitano delle chiavi di ripristino per registrare un nuovo modello. La dimensione della griglia non è una promessa di sicurezza della password: i gesti prevedibili sono ancora più facili da indovinare. Il segreto del dispositivo aggiunge protezione contro qualcuno che dispone solo dei record del server, ma non è una chiave supportata dall'hardware. Qualcuno che copia sia il segreto locale che il wrapper può tentare ipotesi di pattern offline.
Le passkey autenticano il tuo account utilizzando le risposte alle sfide con chiave pubblica. L'autenticazione dell'account non deriva una chiave dell'archivio né decrittografa i file. Una sessione dell'account valida e lo sblocco del vault effettuato con successo sono requisiti separati nel normale flusso della richiesta.
| Scopo | Costruzione |
|---|---|
| Chiave principale del caveau | Chiave AES casuale a 256 bit |
| Avvolgimento delle chiavi | PBKDF2-HMAC-SHA-256 · 600.000 iterazioni · Sale a 128 bit → AES-256-GCM |
| Metadati e miniature | AES-256-GCM · nonce casuale a 96 bit · tag di autenticazione a 128 bit |
| Derivazione della chiave del file | HKDF-SHA-256 · salt casuale a 256 bit per file · output AES a 256 bit |
| Segreto di recupero | 192 bit casuali, visualizzati come sei gruppi di caratteri esadecimali |
Riservatezza e rilevamento delle manomissioni
I metadati del vault, i metadati dei file, le miniature e le chiavi incapsulate utilizzano AES-256-GCM con tag di autenticazione a 128 bit. Ogni crittografia indipendente utilizza un nuovo nonce casuale a 96 bit. La decrittografia verifica il tag prima di restituire testo in chiaro; il testo cifrato modificato o una chiave errata causano il fallimento dell'autenticazione.
Ulteriori dati autenticati associano ciascun oggetto crittografato alla versione del formato, all'identificatore del deposito, all'identificatore dell'oggetto e allo scopo. Ad esempio, una miniatura e un record di metadati di file utilizzano contesti diversi. Lo spostamento di un oggetto crittografato in un deposito diverso o la sua sostituzione con un altro oggetto modifica il contesto autenticato e non supera la verifica.
Il contesto autenticato non nasconde gli identificatori e non dimostra la freschezza. Un record precedente valido può ancora avere un tag valido. I controlli di revisione dell'applicazione rilevano gli aggiornamenti simultanei ordinari, ma questa non è una difesa crittografica contro un servizio dannoso che riproduce uno stato completamente precedente.
I file di grandi dimensioni utilizzano segmenti autenticati
Il contenuto del file utilizza la costruzione dello streaming AES-256-GCM-HKDF-SHA-256 descritta da Tink, implementata utilizzando le primitive crittografiche del browser. Ogni nuovo flusso di file ha un'intestazione di 40 byte contenente il relativo indicatore di lunghezza, un salt casuale di 32 byte e un prefisso nonce casuale di 7 byte.
HKDF deriva una chiave di crittografia file separata dalla chiave master del vault. Il suo contesto include il vault e gli identificatori di file, la lunghezza in byte del testo normale e la dimensione del segmento configurata. Il nonce di 12 byte di ogni segmento combina il prefisso casuale, un contatore di segmento di quattro byte e un flag di segmento finale. I segmenti portano tag GCM a 128 bit.
L'applicazione elabora i file in segmenti delimitati di circa 5 MiB. Le posizioni dei segmenti, il flag del segmento finale e le lunghezze dei byte previste fanno sì che i segmenti scambiati, alterati o troncati non superino la verifica. I download autenticano ogni segmento prima di rilasciarlo; un errore in ritardo in uno stream può lasciare un download incompleto, quindi il completamento con successo è importante. I tentativi di caricamento riutilizzano i byte già crittografati anziché crittografare il nuovo contenuto con lo stesso segmento nonce.
La costruzione segue il Prova le specifiche di streaming AES-GCM-HKDF.. L'implementazione e la configurazione del segmento di Revault non sono state controllate o certificate in modo indipendente da Tink.
Il ripristino è un secondo percorso per la stessa chiave
Un segreto di ripristino viene generato da 24 byte casuali, fornendo 192 bit di input casuale. Deriva in modo indipendente una chiave di wrapper utilizzando PBKDF2-HMAC-SHA-256 e il proprio salt e crittografa la stessa chiave master del vault con AES-256-GCM. Chiunque ottenga il segreto di ripristino e una copia del deposito crittografato può decrittografare tale deposito.
Il segreto di ripristino viene visualizzato durante la configurazione e non viene archiviato dal servizio in testo non crittografato. Conservalo separatamente dai file crittografati. La cancellazione dei dati del browser rimuove il segreto del dispositivo; il ripristino dell'accesso richiede la copia cloud crittografata del tuo account e la chiave di ripristino oppure un backup crittografato esportato e la relativa chiave di ripristino. Non esiste una chiave di decrittazione principale detenuta dal provider.
Un kit di ripristino contiene un segreto e wrapper della chiave, ma nessun contenuto del file. Un backup crittografato contiene un inventario autenticato e segmenti di file crittografati, senza il segreto del dispositivo del browser. L'importazione verifica i dati crittografati e crea un nuovo deposito con nuovi identificatori e chiavi.
La modifica di un modello sostituisce il wrapper di questo dispositivo. Non ruota la chiave master dell'insieme di credenziali, non revoca un altro dispositivo, non invalida i vecchi backup né modifica un segreto di ripristino esistente. Se una chiave dell'insieme di credenziali o un segreto di ripristino viene compromesso, spostare i dati in un nuovo insieme di credenziali con chiavi nuove.
Le condivisioni native utilizzano la crittografia indipendente
Le condivisioni mobili proteggono per impostazione predefinita le chiavi delle versioni selezionate con una nuova chiave di condivisione, riutilizzando i file cifrati. L’isolamento aggiuntivo opzionale li cifra di nuovo. Le chiavi del vault originale restano private. Dati cifrati identici possono collegare le condivisioni; nessuna modalità può richiamare una copia salvata dal destinatario.
iOS può inserire questo testo cifrato in una gerarchia di record CloudKit separata con un invito privato e di sola lettura. Non condivide la zona di sincronizzazione del vault. Le condivisioni native multipiattaforma utilizzano parti server limitate con SHA-256 checksum. Le funzionalità indipendenti di lettura e gestione casuali a 256 bit vengono archiviate come hash sul server. Il segreto di decrittazione viene passato separatamente e mai caricato. Le azioni controllate scadono alla data scelta dal mittente, entro 30 giorni. Il servizio conta atomicamente le sessioni di accesso e ne impone il massimo, la scadenza e la revoca prescelti. Una sessione di download dura al massimo 15 minuti e mai oltre la scadenza della condivisione.
I ricevitori autenticano ogni segmento crittografato e aprono un deposito condiviso isolato con il segreto separato del mittente. Non è richiesto alcun account, deposito personale o modello. I depositi personali rimangono chiusi. Quando l'esportazione è consentita, i destinatari possono salvare una copia .qvault crittografata che si apre con quel segreto di condivisione. Altrimenti, i controlli sulle esportazioni sono assenti. La sessione temporanea convalida l'accesso in corso. Si tratta di controlli dell'applicazione: screenshot, client modificati e copie conservate non possono essere bloccati crittograficamente. Le condivisioni sono snapshot senza aggiornamenti dell'origine continui. Gli inviti CloudKit illimitati non impongono il conteggio degli accessi o la scadenza automatica; l'accesso dura finché il proprietario non interrompe la condivisione. La rimozione di un originale non ne revoca la quota separata, e nessuna revoca può richiamare una copia già conservata.
Attività facoltativa del caveau
I log di controllo nativi sono disattivati per impostazione predefinita e configurati per insieme di credenziali su ogni dispositivo. Gli ultimi 500 eventi locali vengono crittografati con la chiave master dell'archivio protetto e un contesto autenticato dedicato. Escludono chiavi, modelli, contenuti di file e altri dati dei depositi, non si sincronizzano e possono essere cancellati o disabilitati. Non sono prove a prova di manomissione. Gli sblocchi non riusciti non vengono assegnati a un deposito.
Le nuove condivisioni controllate create con la registrazione abilitata conservano fino a 100 timestamp della sessione di accesso sul servizio di condivisione. Solo la capacità gestionale può recuperarli; il registro non contiene l'identità del destinatario o il segreto di decrittografia. La disabilitazione della registrazione locale influisce sulle condivisioni future. I registri di condivisione esistenti mantengono le impostazioni originali fino alla revoca o alla scadenza e alla pulizia.
Foto di effrazione crittografate opzionali
I proprietari possono abilitare gli avvisi di intrusione separatamente per ciascuna cassaforte su ciascun dispositivo. Dopo tre modelli senza eguali, l'app in primo piano può acquisire una foto con la fotocamera anteriore, previa autorizzazione, disponibilità della fotocamera e un minuto di ricarica. Gli indicatori della fotocamera del sistema rimangono visibili. Gli ultimi dieci avvisi vengono archiviati localmente e non vengono mai aggiunti a Foto o caricati. Un modello senza corrispondenza non identifica un deposito di destinazione, pertanto ciascun deposito attivato riceve un record di tentativi del dispositivo crittografato separatamente.
Una chiave pubblica RSA-3072 dedicata racchiude una nuova chiave AES-GCM a 256 bit per ciascun avviso utilizzando OAEP con SHA-256 e MGF1-SHA-256. Ciò consente la crittografia mentre il deposito è bloccato. La chiave privata corrispondente è essa stessa crittografata con la chiave master di quel vault con un contesto autenticato dedicato. Solo sbloccando quel caveau è possibile decrittografare le sue foto. Gli avvisi vengono visualizzati nella vista di controllo indipendentemente dalla registrazione delle attività ordinarie e possono essere cancellati nelle impostazioni degli avvisi di intrusione. Non sono prove a prova di manomissione.
Caricamenti crittografati nel tuo bucket
Le impostazioni di archiviazione di un deposito possono connettere questo browser direttamente a un endpoint HTTPS compatibile con S3 specificato dall'utente. I file del dispositivo selezionati vengono crittografati localmente utilizzando la stessa struttura del file. Ciascuno diventa un oggetto .qvault separato e portatile contenente un inventario crittografato autenticato e chiavi del vault incapsulate. I nomi degli oggetti casuali evitano di esporre i nomi dei file originali. Il ripristino richiede l'oggetto scaricato e la chiave di ripristino dell'insieme di credenziali.
La configurazione e le credenziali dell'endpoint vengono crittografate con la chiave master del vault con un contesto autenticato dedicato e conservate nel IndexedDB di questo dispositivo. Non vengono sincronizzati o inviati all'API di Revault. La firma della richiesta utilizza AWS Signature Version 4, HMAC-SHA-256 e un hash di ciascun corpo della richiesta delimitato. Le parti multipart da otto MiB trasportano byte già crittografati direttamente al provider di archiviazione. L'accesso al bucket rimane regolato dalle autorizzazioni del provider e dalla policy CORS.
Il provider può visualizzare gli identificatori delle chiavi di accesso, i percorsi degli oggetti, le dimensioni dei byte, i tempi di caricamento e le informazioni sulla connessione. Mantieni il bucket privato e le sue credenziali limitate alle operazioni richieste. Gli oggetti caricati sono indipendenti dalla sincronizzazione e dalla condivisione del cloud Revault. Tentativi di blocco o annullamento per interrompere i caricamenti non completati; la chiusura delle schede o la perdita di connettività possono lasciare parti orfane, quindi configura una regola del ciclo di vita del caricamento incompleto. Safe Exit rimuove le credenziali di archiviazione locale di altri depositi ma non elimina gli oggetti dai relativi bucket.
Safe Exit rimuove l'accesso locale
Puoi designare un deposito in questo browser come Safe Exit deposito. L'accesso al modello di quel deposito lo apre normalmente, senza conferma dell'attivazione o avviso di completamento. Gli snapshot locali, i blocchi crittografati, i segreti del dispositivo e le modifiche in coda di altri depositi vengono rimossi. I dati non sincronizzati potrebbero andare persi.
Un confine locale persistente impedisce che tali depositi vengano elencati o ripristinati automaticamente tramite la sincronizzazione su questo browser. Le loro copie cloud crittografate e le copie su altri dispositivi rimangono invariate. Il ripristino è esplicito, un insieme di credenziali alla volta e richiede la chiave di ripristino dell'insieme di credenziali prima di poter registrare un nuovo modello di dispositivo.
Si tratta della rimozione dell'accesso locale, non della cancellazione fisica garantita o dell'occultamento forense. Profili del browser, istantanee del file system, download precedenti, screenshot, record di servizio e un altro dispositivo possono conservare prove. La cancellazione dei dati locali di questo browser cancella anche il limite di isolamento locale; una nuova installazione può elencare nuovamente i depositi cloud dell'account dopo l'autenticazione.
Ciò che rimane visibile
La crittografia protegge i contenuti, non tutti gli aspetti relativi all'archiviazione. Il servizio può osservare associazioni di account, identificatori di oggetti casuali, conteggi di oggetti, dimensioni di byte, revisioni, timestamp, wrapper crittografati, intestazioni di flusso e attività di richiesta. I record operativi e di rete possono rivelare informazioni sulla connessione. Questo non è un sistema di anonimato e non fornisce resistenza all'analisi del traffico.
La crittografia del trasporto protegge le richieste in transito quando l'applicazione viene servita tramite HTTPS. Questo è separato dalla crittografia lato client che mantiene crittografati i contenuti dei file archiviati nel servizio.
Dove finisce la protezione
La navigazione privata di solito elimina la memoria locale al termine della sessione privata. Una richiesta di archiviazione persistente non rende permanente una sessione in incognito. Le copie cloud sincronizzate rimangono, ma i modelli locali, le modifiche non sincronizzate, i file memorizzati nella cache e le impostazioni Safe Exit possono andare perduti. Una nuova sessione privata richiede l'accesso all'account e la chiave di ripristino per registrare un nuovo pattern.
L'applicazione elimina il riferimento alla chiave dell'insieme di credenziali in memoria e revoca gli URL di anteprima privati quando bloccati. Si blocca automaticamente quando nascosto o dopo cinque minuti di inattività. Le app native si bloccano anche quando sono in background, rimuovono le anteprime temporanee e cancellano i buffer delle chiavi di proprietà al termine delle operazioni. La gestione della memoria del browser, di Swift e della JVM non può garantire la cancellazione immediata di ogni copia chiave o buffer multimediale decodificato.
Malware, estensioni non sicure, codici applicativi compromessi o qualcuno che visualizza uno schermo sbloccato possono acquisire testo in chiaro e segreti. La crittografia non può impedire la negazione del servizio dell'account, l'eliminazione di oggetti cloud, il ransomware, la perdita di un segreto di ripristino o la trattenuta di dati da parte di un servizio. Mantieni un backup crittografato separato e proteggi il dispositivo stesso.
Revault non è stato sottoposto a un controllo di sicurezza indipendente. Queste sono descrizioni del progetto crittografico implementato, non una certificazione o una garanzia contro ogni intrusione.