Domanda:
Pattern per consentire a più persone di decrittografare un documento, senza condividere la chiave di crittografia?
Monika
2014-10-29 20:31:12 UTC
view on stackexchange narkive permalink

Configurazione corrente

Abbiamo un servizio che consente agli utenti di caricare documenti tramite un sito Web e memorizza i documenti caricati crittografati su disco.

I documenti su disco vengono crittografati con una chiave per utente, generata in modo casuale al momento della creazione dell'account. Questa chiave del documento è memorizzata in un campo del database che è crittografato con la password dell'utente come chiave.Quando l'utente (proprietario) desidera scaricare un documento, deve fornire la propria password, che viene utilizzata per decrittografare la chiave del documento che si trova in viene utilizzato per decrittografare il documento.

Abbiamo scelto questo modello per negare la necessità di crittografare nuovamente tutti i documenti crittografati quando l'utente sceglie di cambiare la propria password: abbiamo solo bisogno di crittografare nuovamente la chiave del documento.

Questa configurazione funziona bene (e pensiamo che sia un pattern sicuro 1 ).


Modifiche richieste

Sfortunatamente, abbiamo due nuovi requisiti da implementare.

  1. Per legge, siamo tenuti a poter decrittografare qualsiasi documento che abbiamo su disco, su richiesta del governo;
  2. Qualcuno ha deciso che il proprietario di un documento dovrebbe essere in grado di condividere il documento caricato con altri utenti.

Non so come implementare questi requisiti mantenendo i documenti archiviati con la crittografia per utente.

Quindi, la mia domanda è:

Esiste un modello noto che consente di crittografare i documenti in modo che possano essere decrittografati da una o più parti, dove le parti in questione devono essere determinati in base alla crittografia del documento?


Aggiorna :

Alcune informazioni di base sulla legge sopra menzionata:
In effetti, la legge non afferma che siamo tenuti a costruire una porta sul retro. La legge rende un reato penale non consegnare la chiave dei dati crittografati che hai 2 se la polizia richiede la chiave 3 . Il risultato di ciò è che noi che ospitiamo i dati dobbiamo avere una porta sul retro o essere perseguiti nel caso in cui non possiamo decrittografare i dati quando richiesto. Tuttavia, salvo che in altri paesi, siamo liberi di comunicare il fatto che abbiamo ricevuto un ordine per decrittografare i documenti. Queste leggi purtroppo non sono rare.

Informare i nostri clienti e il pubblico:
come ho indicato in un commento prima, ho intenzione di fare tutto il possibile per assicurarmi che questa politica sia chiaramente comunicata ai nostri clienti. Le dichiarazioni sulla privacy devono essere modificate e i Termini di servizio devono essere aggiornati.
La consapevolezza del pubblico da un lato e la certezza che le "cattive leggi costano denaro" dall'altro, sono il metodo migliore a disposizione per protestare contro tali leggi. Tuttavia, allo stesso tempo sono un po 'scettico sull'impatto di tale affermazione. Alla maggior parte delle persone semplicemente non importa. Allo stesso tempo, molte persone utilizzano la posta elettronica e la posta in arrivo per archiviare e condividere documenti. Quindi da quella prospettiva il nostro servizio è (ancora) un enorme miglioramento (ed è il motivo per cui alcuni dei nostri clienti richiedono ai propri dipendenti di utilizzarlo).


1. Se c'è un buco evidente in questo metodo, sentiti libero di commentarlo.
2. Gli avvocati hanno capito che i "dati che hai" dovrebbero includere tutti i dati memorizzati su dispositivi fisici che possiedi (non sono un avvocato, quindi questa è la mia traduzione da profani di ciò che hanno concluso). 3. Sì, non un ufficio di sicurezza di fantasia, ma la polizia. Ci sono alcune misure di sicurezza quando possono richiedere la password, ma ciò non cambia le implicazioni di questa legge. La grande domanda è cosa succede quando hai veramente dimenticato la password di alcuni dati. Il ministro ha indicato che è responsabilità del proprietario di tali dati crittografati eliminarli. Ma nessun caso del genere è stato ancora (per quanto ne so) in tribunale.

Qual è il vantaggio di fare la crittografia per utente? Sembra che potresti anche usare la crittografia dell'intero disco e chiedere all'applicazione di verificare le password per i download.
Il vantaggio della crittografia per utente è che tutte le sequenze di decrittografia richiedono una password. In altre parole, non ci sono chiavi di decrittografia memorizzate ovunque sul disco (in forma non crittografata).
Quindi, l'utente deve inserire la propria password per decrittografare? Ciò è incompatibile con l'obbligo legale di decrittografare su richiesta.
@paj28, esattamente. Ecco perché ho posto la domanda. Tieni presente che, sebbene la legge ci imponga di essere in grado di decrittografare qualsiasi documento, non richiede che questo sia un processo automatizzato. Quindi possiamo ancora mantenere segreta la nostra "password principale".
@Monika: se memorizzi la tua "password principale" in una macchina offline o in un pezzo di carta, c'è davvero una sicurezza aggiuntiva nella crittografia per utente.
La persona che ha espresso un voto negativo si preoccuperebbe di spiegare perché?
Considererei disonesto offrire questo servizio, poiché il tuo requisito legale per poter decriptare e documentare non è compatibile con ciò che i tuoi clienti possono ragionevolmente aspettarsi.
@IanRingrose, Il servizio offre agli utenti la possibilità di archiviare i documenti in modo che possano accedervi ogni volta che ne hanno bisogno. Criptiamo i documenti perché rispettiamo l'idea di privacy, non perché il contratto con il cliente lo richiede. Come seconda nota: il servizio è utilizzato esclusivamente dai clienti aziendali, che normalmente utilizzerebbero altrimenti (o simultaneamente) la propria casella di posta elettronica nello stesso effetto.
Sicuramente la legge richiede che tu decifri solo se sei fisicamente in grado di farlo. Se rendi impossibile decrittografare i dati utente, non ci sono problemi, giusto?
@JMK, Se non puoi fornire la password, la legge presume che tu stia lavorando contro la richiesta. La legge cerca di impedire alle persone di affermare di aver "dimenticato" la password ed è formulata come tale. L'effetto collaterale di questa formulazione della legge (il caso in questa domanda) non è qualcosa che gli interessa.
@Monika, Non credo che la legge sia noi che dichiari, poiché qualsiasi servizio di backup che esegua il backup di un file dalla mia macchina che ho già crittografato sarebbe necessario per poter consegnare la chiave. Allo stesso modo se uno dei tuoi clienti crittografa un file da solo prima di utilizzare il tuo sistema per condividerlo.
@IanRingrose, Non sono un avvocato e non credo che questo sia il luogo per discutere se questa legge debba o meno essere interpretata come hanno fatto loro. Nel frattempo, * devo * trovare una soluzione che soddisfi i due requisiti descritti nella mia domanda.
Una domanda strettamente pratica: sebbene sia possibile modificare l'archiviazione della chiave come suggerito di seguito per i nuovi documenti, come intendi gestire qualsiasi cosa caricata prima che la modifica venisse apportata dove solo l'utente ha una copia della chiave di decrittazione ...
@DanNeely, anche quello mi sta infastidendo. L'intera questione con questo problema è che la legge è stata progettata da persone che apparentemente non ci hanno pensato a fondo o, più probabilmente, non hanno il "know how" tecnico per vedere tutte le implicazioni e le impossibilità che crea. Per ora, penso che dovrei a) ignorarlo ob) trovarmi un altro lavoro o qualcosa del genere.
Aspetta, non sono i TUOI dati e chiavi crittografati: sono gli UTENTI. Perché hai richiesto di dare le chiavi a qualunque agenzia legale? Memorizzi solo dati casuali per gli utenti, quindi inviali per recuperare le chiavi dagli utenti.
@Monika Se la mancanza di capacità di decifrare può essere tenuta contro di te, questo ti rende soggetto a una sorta di ricatto: immagina che un utente carichi una sequenza di bit casuale e induca il governo a chiederti una "decrittazione"
In che paese è questo, se non ti dispiace che te lo chieda?
Possibilmente correlato: [SuperUser: crittografia di un documento con più chiavi e responsabilizzazione delle persone per tali chiavi] (http://superuser.com/q/638358/53590)
@Monika che paese è questo?
Sei risposte:
Tom Leek
2014-10-29 20:48:44 UTC
view on stackexchange narkive permalink

È necessaria una chiave per documento, non una chiave per utente. Bene, hai anche bisogno di chiavi per utente, ma questa è un'altra questione.

Vale a dire, ogni documento D è crittografato con una chiave K D sub> . Quella chiave viene generata in modo casuale la prima volta che il documento viene importato nel sistema. Ogni documento ha la sua chiave. La chiave di un documento non può essere dedotta dalla chiave di nessun altro documento.

Ogni utente U ha anche una chiave K U . Pertanto, se è necessario che il documento D sia accessibile agli utenti U , V e W , archiviare E K D (D) (crittografia di D con la chiave del documento), insieme a E K U (K D ) , E K V sub > (K D ) e EKW (K D ) (crittografia della chiave KD con le chiavi dell'utente U , V e W ). Queste "chiavi crittografate" hanno una dimensione ridotta (poche dozzine di byte, indipendentemente dalle dimensioni del documento), quindi aumenta.

Per rendere le cose più pratiche, potrebbe essere necessario utilizzare la crittografia asimmetrica per le chiavi utente: la crittografia di D utilizza un comodo sistema simmetrico (ad esempio, AES), ma le "chiavi utente" saranno di tipo RSA (o un altro algoritmo simile come ElGamal). In questo modo, se l'utente U desidera condividere il documento D con l'utente V , allora:

  1. recupera EKU (K D ) dal server;
  2. usa il suo chiave privata per decrittografarla e recuperare KD;
  3. crittografa K D sub > con la chiave pubblica di V , ottenendo EKV (K D ) .

La bellezza di questo schema è che V non ha bisogno di essere presente per questa procedura, poiché solo V .

A quel punto, quello che hai veramente è OpenPGP, un formato pensato principalmente per le email sicure. Le email hanno questa "proprietà di condivisione" (un'email può essere inviata a più destinatari) e sono asincrone (quando si invia l'email, il destinatario non è necessariamente disponibile immediatamente). Ti consigliamo di riutilizzare OpenPGP, un formato che è stato rivisto da molti crittografi e per il quale esistono già implementazioni.

Quando hai un meccanismo di condivisione, puoi semplicemente metterti come destinatario implicito per ogni documento e puoi leggere tutto. Indipendentemente dai requisiti di legge, assicurati di avvisare gli utenti attraverso le "condizioni di utilizzo" che puoi tecnicamente leggere tutto; altrimenti potrebbero farti causa per mancanza di avvertimento.

Speravo in un'elegante crittografia a chiave pubblica multipla con relativo schema di decrittazione della chiave privata, ma questo è probabilmente più semplice (quindi, migliore). [e non preoccuparti, farò in modo che l'informativa sulla privacy e i TOS vengano modificati; la consapevolezza dell'opinione pubblica da un lato e assicurarsi che le "cattive leggi costino denaro", dall'altro, sono il miglior metodo di protesta che ho a disposizione contro tali leggi.]
Esiste uno schema di "crittografia a chiave pubblica multipla, decrittografia con chiave privata correlata"? o qualcuno ha ancora capito questo?
Lo schema OpenPGP è un esempio; ma ottieni comunque un sovraccarico per destinatario. Esistono schemi di "crittografia delle trasmissioni" che cercano di ridurre questo sovraccarico; ma non puoi rimuoverlo completamente.
Dovrei iscrivermi di nuovo all'università :-)
E un'implementazione di PGP già fa l'elemento 1 (richiesta govt) o almeno lo ha fatto. La versione "commerciale" di PGP Inc, intorno al 2000 quando il governo degli Stati Uniti stava spingendo Clipper ecc., Ha aggiunto un'alternativa più gentile chiamata ADK Additional Decryption Key che consente al proprietario di decrittografare quando necessario, in questo caso la richiesta del governo. Non ho tenuto traccia, ma alcune ricerche su Google suggeriscono che il nuovo proprietario Symantec mantiene questa capacità. Dovresti sicuramente impostare i controlli in modo che venga utilizzato solo quando legalmente corretto, qualunque cosa sia nella tua giurisdizione.
@dave_thompson_085, Additional Decryption Key (ADK) è interessante. Potresti forse espandere il tuo commento in una risposta?
Si noti che la configurazione proposta non soddisfa il requisito della domanda secondo cui i documenti possono essere condivisi "senza condividere la chiave di crittografia". Lo stai condividendo in una forma crittografata, ma lo stai ancora condividendo. Ciò significa che se desideri revocare l'accesso a qualcuno dovrai comunque crittografare nuovamente il documento con un nuovo K_D e condividerlo (in forma crittografata o meno) con tutti gli utenti rimanenti che dovrebbero avere accesso.
Probabilmente, se la chiave K_D è specifica del documento, la condivisione della chiave e del documento è la stessa cosa. Si potrebbe dire che non puoi costringere qualcuno a dimenticare un documento più di quanto puoi costringerlo a dimenticare una chiave. In questo senso, "revocare" un accesso non è ben definito.
@Chris Penso che il miglior compromesso qui sarebbe se ci fosse una nuova chiave generata ogni volta che il documento è stato modificato .. Parte del processo di caricamento sarebbe quindi crittografare la nuova chiave per ogni persona che dovrebbe essere autorizzata a scrivere sul documento.
antispy
2014-10-30 05:44:43 UTC
view on stackexchange narkive permalink

MA, abbiamo due nuovi requisiti da implementare:

Per legge, siamo tenuti a essere in grado di decrittografare tutti i documenti che abbiamo su disco, su richiesta del governo;

Wow. Spero davvero che tu stia pianificando di informare i tuoi utenti che eseguirai il backdoor del tuo servizio per le forze dell'ordine in modo che abbiano tempo sufficiente per eliminare i loro dati dal tuo servizio prima che ciò accada. Questa sarebbe la cosa etica e onorevole da fare.

Se sei costretto a farlo, ad es. di National Security Letter e non ti è permesso di parlarne a causa di un ordine di bavaglio, quindi le tue opzioni sono limitate:

  1. Chiedi a qualcuno in azienda di divulgare in modo anonimo queste informazioni alla stampa libera (che in futuro il tuo servizio verrà sottoposto a backdoor).
  2. Chiudi il servizio per motivi non specificati. Concedi ai tuoi utenti alcune settimane per scaricare i propri dati prima che vengano eliminati per sempre.
  3. Trasferisci la tua azienda, il servizio online e il personale in un paese in cui non esistono leggi di sorveglianza draconiane.
    4. ol >

    Sembra che tu abbia già un servizio sicuro e abbia attirato alcuni utenti orientati alla privacy. Qualsiasi cosa sarebbe meglio che installare intenzionalmente una backdoor per le forze dell'ordine e rovinare i tuoi utenti. Per quanto ne sai, non appena il sistema proposto per le forze dell'ordine sarà operativo, ti invieranno un mandato per tutti i dati degli utenti.

    Faresti meglio a chiudere l'azienda si ferma, prende i tuoi soldi e avvia una nuova impresa, ma questa volta lo fa correttamente. Ecco i miei suggerimenti:

  • Avvia la tua azienda in un paese senza queste leggi. Ospita anche i tuoi server e i dati degli utenti.
  • Utilizza un client open source in modo che gli utenti abbiano fiducia nel software in esecuzione sul loro computer / dispositivo. Sarà molto difficile nascondere una backdoor in futuro se sei costretto dalle autorità perché qualcuno se ne accorgerà.
  • Tutte le chiavi di crittografia dei dati privati ​​vengono archiviate sul lato client , mai sul server. Solo i dati crittografati vengono archiviati sul server. Tutta la crittografia e la decrittografia vengono eseguite sul client. Il server contiene solo dati crittografati. Gli utenti hanno la responsabilità di eseguire il backup delle proprie chiavi private. Quindi la tua azienda non è letteralmente in grado di rispondere alle future richieste NSL perché non hai le chiavi.
  • Per l'autenticazione con il server e consentire all'utente di memorizzare e scaricare dati crittografati dal proprio account, configurare una sorta di per protocollo di autenticazione con chiave pubblica dell'utente. Forse il server detiene la chiave pubblica per ogni utente. L'utente detiene la chiave privata, quindi firma ogni caricamento e richiesta di dati al server. Ogni client può avere la chiave pubblica del server incorporata (bloccata) in esso per verificare le risposte e i dati crittografati scaricati dal server.
  • Per condividere file con altri utenti, l'utente può crittografare nuovamente il proprio file con un nuovo chiave simmetrica e condividere tale chiave utilizzando lo scambio di chiavi pubbliche con altri utenti del sistema. Il tuo servizio potrebbe gestire la condivisione della chiave pubblica per loro. Tuttavia, questo è pericoloso se gli utenti non possono fidarsi completamente del server e se il server si trova in un paese con leggi di sorveglianza ostili. Gli utenti non sanno se il server sta fornendo loro una chiave pubblica falsa o reale per l'altro utente, quindi sarebbero vulnerabili agli attacchi MITM. Questo sarebbe un modo in cui le forze dell'ordine potrebbero utilizzare per accedere ai dati non crittografati per i file condivisi tra altri utenti. In questo scenario sarebbe più sicuro se gli utenti conoscessero le proprie chiavi pubbliche e potessero condividerle privatamente con altri utenti quando desiderano condividere i dati con loro.
  • Utilizza algoritmi di chiave pubblica più recenti che non sono vulnerabili al quantum computer. Nessuna curva RSA, DSA o ellittica.
  • Usa chiave simmetrica più recente e algoritmi hash di autori che si preoccupano della privacy e non amano la sorveglianza di massa. Ad esempio, Bruce Schneier & Daniel J. Bernstein.
8. Installi un canarino di mandato prima di ottenere una citazione segreta del governo.
I nuovi algoritmi a chiave pubblica hanno un track record molto più breve rispetto a RSA, DSA ed EC. Dato che i progressi nell'informatica quantistica sono stati lenti e che i progressi nella violazione dei nuovi algoritmi sono stati spesso sorprendentemente rapidi, sembra ragionevolmente probabile che i servizi di sicurezza abbiano attacchi contro alcuni di questi algoritmi.
Non sono nemmeno contento della parte etica dell'intera questione, infatti, sto cercando di vedere come possiamo ridurre al minimo il danno. Si prega di vedere anche il paragrafo * aggiornamento * nella domanda.
Questa è stata una risposta abbastanza buona fino agli ultimi due punti elenco. Usare algoritmi non testati a favore di quelli ben noti e accuratamente esaminati che si sono rivelati abbastanza sicuri nella pratica è una cattiva idea, per ragioni che sono state discusse più e più volte. Edward Snowden era fiducioso nell'usare GnuPG per comunicare in modo sicuro e [ha dichiarato] (http://www.theguardian.com/world/2013/jun/17/edward-snowden-nsa-files-whistleblower) che "La crittografia funziona. ** I sistemi crittografici potenti implementati correttamente sono una delle poche cose su cui puoi fare affidamento. ** ", con un forte avvertimento sulla sicurezza degli endpoint.
Il miglior attacco semi-pratico pubblicamente noto contro AES-256 sembra essere un attacco a chiave correlata con una complessità di circa 2 ^ 99,5. L'attacco di ripristino della chiave completo più noto su AES-256 è la complessità 2 ^ 254.4. La prima può probabilmente essere evitata nella selezione delle chiavi, e la seconda è più una curiosità accademica che altro, dato che [non possiamo realisticamente * contare * su un banale 2 ^ 192] (http: // security. stackexchange.com/a/6149/2138) e hanno difficoltà a raggiungere il 2 ^ 128. Wikipedia: [attacchi AES pubblicamente noti] (https://en.wikipedia.org/wiki/Advanced_Encryption_Standard#Known_attacks).
"Usare algoritmi non testati a favore di quelli ben noti e accuratamente esaminati che si sono rivelati abbastanza sicuri nella pratica è una cattiva idea" - In generale sono d'accordo, ma nel caso dei computer quantistici, tutti gli algoritmi a chiave pubblica attualmente protetti (controcomputer classici) saranno resi obsoleti e insicuri.Inoltre ci sono algoritmi post-quantistici testati nel tempo e rivisti che sono ancora considerati sicuri oggi (se vengono utilizzate chiavi di grandi dimensioni), ad es.McEliece.Ora c'è una competizione post-quantistica sugli algoritmi per trovare alcune opzioni sicure per il futuro.Combinare due finalisti sarebbe solido.
"Edward Snowden era fiducioso nell'usare GnuPG per comunicare in modo sicuro e ha affermato che" la crittografia funziona.I sistemi crittografici potenti implementati correttamente sono una delle poche cose su cui puoi fare affidamento. "- I burattini del governo * adorano * ripetere questo. Snowden * non * è qualificato per dire * su quali * sistemi crittografici si può fare affidamento. Dopo tutto ildocumenti a cui aveva accesso * nulla * dettagliato sulle tecniche di crittoanalisi. In effetti l'unica informazione che abbiamo su BULLRUN era una diapositiva che diceva "non chiedere a riguardo". Sai perché? Sono informazioni ECI SCI top secret. Solo alcune dellei crittoanalisti della NSA lo sanno.
"Wikipedia: attacchi AES pubblicamente noti" - È proprio questo.* Attacchi noti * pubblicamente.Cosa sa la NSA come rompere?C'era un'altra diapositiva NSA trapelata che diceva di aver classificato * tecniche interne * contro cifrari a blocchi come AES.Affidati ad AES a tuo rischio e pericolo.La crittografia con due algoritmi è un'idea molto più sicura, ad es.AES-CTR con una chiave, quindi ChaCha20 con un'altra chiave.
simbo1905
2015-01-11 19:21:36 UTC
view on stackexchange narkive permalink

La soluzione delineata da Tom Leek sopra è stata implementata dall'archivio di documenti cloud opensource ownCloud. Il modello di crittografia è descritto qui.

Come sottolineato anche in altre risposte, puoi fare la stessa cosa con OpenPGP / GPG che ho delineato in una risposta a una domanda correlata. Per ripetere brevemente l'approccio standard:

  1. Ogni utente ha una coppia di chiavi pubblica / privata
  2. A ogni documento viene assegnata una chiave simmetrica univoca con la quale il documento viene crittografato e caricato in il contenitore di supporto. Questa è chiamata chiave del file
  3. Ogni volta che a un utente viene concesso l'accesso al file, la chiave del file viene crittografata con la chiave pubblica dell'utente

In particolare tu vuoi essere in grado di fornire la chiave del file quando richiesto dalla legge. Questa è una funzione di opt-in di ownCloud in cui ogni chiave di file è anche crittografata con la chiave pubblica dell'amministratore di sistema. Con ownCloud l'intenzione della funzionalità è che l'utente possa aver dimenticato la passphrase della propria chiave privata e possa chiedere all'amministrazione di concedere nuovamente l'accesso al file.

Una cosa da notare è che ownCloud utilizza un database regolare per i dati utente / gruppo e i metadati del file. I BLOB di file effettivi possono essere archiviati localmente o su un provider esterno come Amazon S3 o Google Drive. Puoi adottare lo stesso approccio; chiedere al client di crittografare e scrivere prima in un archivio BLOB esterno fuori giurisdizione crittografato con le proprie chiavi, quindi scrivere solo l'URL (in genere un GUID a 128 bit) nel sistema. Sebbene questo sia tutt'altro che ideale in termini di complessità del sistema, potrebbe liberarti dal dover rispettare una legge pericolosa e opprimente; poiché puoi solo trasferire i puntatori ai dati.

Penso che almeno un paese che sta implementando tali leggi totalitarie stia costringendo tutti i fornitori di cloud offshore a spostare i propri server nel paese per gli utenti domiciliati in quel paese. In tal caso, l'ultima risorsa è consentire agli utenti del sistema di crittografare e scrivere sulle proprie unità di rete locali e memorizzare un percorso di file nel sistema. Spetta quindi al cliente eseguire backup off-site di tali dati.

Sono molto infelice di apprendere che vivo in un paese con una simile legge http://goo.gl/NdC2T2
Questa risposta purtroppo non funziona per noi perché ci sono abbastanza informazioni memorizzate sul server per poter decrittografare i documenti memorizzati.Pertanto, è possibile per le autorità ottenere il documento normale.
Ho risposto al corpo della domanda in cui le autorità richiedono all'autore di essere in grado di decrittografare il documento.se la tua situazione non è come la loro, la risposta alla loro situazione non ti aiuterà.è possibile eseguire la crittografia e la decrittografia sul client in modo tale che il server non possa decrittografare alcun contenuto.utilizzare i verificatori di password SRP (non password salate) in modo da non poter nemmeno autenticarsi come cliente (ad esempio thinbus-npm).fare in modo che i clienti si scambino chiavi pubbliche e scambino chiavi di file crittografate con chiavi private.usa la condivisione segreta di shamir per il recupero della password peer-2-peer.
eseguire tutta la crittografia sul client (browser / telefono).crittografa le chiavi private con password e memorizzale sul server (srp significa che non conosci la password).se perdono il telefono, possono scaricare la chiave privata e utilizzarla.usa la condivisione segreta shamir sul telefono per eseguire il backup della password per gli amici.la password può essere recuperata solo sul telefono.tutto ciò che devi garantire è che utilizzino una password molto complessa.controlla l'hash contro il database di Pwned Passwords e utilizza un controllo password efficace tutto sul client.Q.E.D.
paj28
2014-10-30 13:50:24 UTC
view on stackexchange narkive permalink

Come risposta diretta alla tua domanda, la risposta di Tom Leek è perfetta.

Tuttavia, ti consiglio di adottare un approccio diverso: abbandonare la crittografia per utente.

Lo farai utilizzare ancora la crittografia di rete (HTTPS), l'hashing della password e, se lo si desidera, la crittografia dell'intero disco sul server. Tuttavia, non utilizzare alcuna crittografia oltre a quella. La tua applicazione decide comunque chi può visualizzare un determinato documento: l'utente che ha caricato per primo, il tuo amministratore per scopi legali e tutti gli utenti che hanno condiviso il documento con loro. In questa disposizione, è abbastanza facile soddisfare tutte le tue esigenze.

Allora perché suggerisco di abbandonare la crittografia per utente? Perché è complesso e difficile da implementare e in realtà non aggiunge molta sicurezza. Non hai davvero spiegato quale vantaggio volevi per la crittografia per utente, ma presumo che sia per mantenere i documenti al sicuro nel caso in cui il server sia compromesso elettronicamente o fisicamente. Entrambi dovrebbero essere eventi estremi: dovresti prendere precauzioni standard come il firewall per evitare che accadano. Ma se si verifica un evento così estremo, in realtà un utente malintenzionato avanzato può comunque ottenere i documenti dei tuoi utenti. Stanno aspettando in silenzio, aspettando che i tuoi utenti effettuino il login, quindi acquisiscano la password e decifrino i documenti.

Grazie. L'intento è infatti quello di proteggere i documenti caricati dall'utente dal furto da parte di terze parti dannose. La domanda è formulata dal punto di vista della nostra attuale implementazione e di come cambiarla. Tuttavia, la crittografia dell'intero disco potrebbe essere una soluzione migliore.
Sono d'accordo con la maggior parte di ciò che hai detto, tranne l'ultimo punto.Sicuramente il punto è che i documenti esistenti possono essere decodificati solo se la chiave privata è compromessa e non i dettagli di accesso.
CompanyDroneFromSector7G
2014-10-31 16:09:20 UTC
view on stackexchange narkive permalink

So che è già stata data una risposta, ma ...

Devo fare qualcosa di molto simile sul mio sito web.

I documenti sono crittografati ma possono essere condivisi con altri utenti .

Essendo nel Regno Unito, sono tenuto a condividere i dettagli di sicurezza con i servizi di sicurezza se richiesto, ma solo se li ho. Non ho accesso a loro quindi questo non è un problema. (Non sono inoltre autorizzato a notificare agli utenti che i dettagli sono stati richiesti - il prezzo della libertà!)

Ogni utente ha una coppia di chiavi asimmetriche che viene utilizzato per proteggere i loro documenti. Le chiavi pubbliche sono archiviate in testo normale ma le chiavi private vengono crittografate utilizzando blowfish, con una chiave a 128 bit derivata dalla password dell'utente.

Quando un utente desidera condividere un documento, viene decrittografato e una copia viene realizzato e crittografato utilizzando la chiave pubblica dell'utente di destinazione, che essendo in testo semplice è facile da fare. Quando l'utente di destinazione effettua il login, può decrittografare il documento utilizzando la sua chiave privata sicura.

Ovviamente se condivisa con più utenti deve esserci una copia per ciascuno.

"Il prezzo della libertà" ... in effetti, a me suona come l'opposto della libertà, ma ok
@iCodeSometime Sì, era ironia.
madscientist159
2014-10-30 07:25:55 UTC
view on stackexchange narkive permalink

Poiché i requisiti dichiarati impongono che la crittografia sia essenzialmente per "spettacolo" (teatro di sicurezza?) E protezione dai furti di base, non protezione a livello di documento sicuro, consiglierei la crittografia di base dell'intero disco utilizzando LUKS o simili. In questo modo si dispone della chiave principale dell'intero archivio e si possono utilizzare schemi non basati sulla crittografia per controllare l'accesso per utente ai vari documenti. La crittografia per documento in realtà non ti offre nulla tranne il fastidio alla luce del requisito n. 1.

Inoltre, vorrei seguire la risposta di antispy sopra. Come minimo, il servizio proposto è altamente immorale e in alcune giurisdizioni sarebbe persino considerato una frode a seconda dei termini di servizio / di ciò che hai divulgato ai tuoi utenti.

Non sono nemmeno soddisfatto della parte etica dell'intera questione, infatti, sto cercando di vedere come possiamo minimizzare il danno. Si prega di vedere anche il paragrafo * aggiornamento * nella domanda.
Inteso. Allontanandomi dalla questione tecnica e supponendo che tu e il governo abbiate diritti di accesso identici (per legge), come affermato non vedo alcun vantaggio nella crittografia per documento. In altre parole, tu e il governo condividete i privilegi di root su un sistema multiutente; per ottemperare a questa legge entrambi potete leggere qualsiasi documento in qualsiasi momento. Il solo fatto di avere un account di root non rende insicuro un sistema multiutente; si riduce a chi userà quel potere e per quale scopo. Vorrei sapere di che paese si tratta, così potrebbe andare in una lista di posti in cui non vivere ...


ⓘ
Questa domanda e risposta è stata tradotta automaticamente dalla lingua inglese. Il contenuto originale è disponibile su stackexchange, che ringraziamo per la licenza cc by-sa 3.0 con cui è distribuito.
Loading...