Crittografia annidata per più utenti

1

Ho sviluppato un'applicazione web (sviluppata in .NET MVC 4) che ha più utenti con credenziali di accesso personali. L'applicazione web contiene molti contenuti caricati dagli utenti.

Il mio cliente vorrebbe anche avere una versione offline dell'applicazione, per Windows. Questa applicazione dovrebbe utilizzare le stesse informazioni disponibili sul Web, dovrebbe essere disponibile offline e dovrebbe essere protetta in modo che un utente non possa essere in grado di prendere il contenuto dell'applicazione e darlo / venderlo a un concorrente (in un modo semplice).

Quindi ho implementato nella mia applicazione web la funzionalità per creare un pacchetto di applicazioni, contenente tutte le informazioni rilevanti, che è scaricabile e crittografato con una chiave simmetrica. Tuttavia, ogni utente dovrebbe essere in grado di decifrare il pacchetto con le sue credenziali (ad esempio le password personali).

Quindi, quando viene creato un utente, creo una coppia di chiavi asimmetriche per quell'utente e la chiave privata viene archiviata nel database come una stringa crittografata in cui la chiave è la password privata (memorizzata come hash da bcrypt).

Questo elenco di eventi significa che c'è un bel po 'di crittografia annidata e mi fa sentire a disagio perché non so davvero se è abbastanza sicuro - quindi vorrei alcuni input sul mio metodo di scelta.

La catena di funzionalità;

Durante la creazione di un utente;

  1. Crea una coppia di chiavi asimmetriche
  2. Cripta la chiave privata con la password delle credenziali degli utenti
  3. Hash la password con bcrypt
  4. Store hash + chiave privata crittografata per l'utente

Durante la creazione di un pacchetto di applicazione;

  1. Crea una chiave simmetrica [Lato server]
  2. Crea un pacchetto di applicazioni (dati grezzi) e crittografalo con tasto simmetrico [lato server]
  3. Per ogni utente, crittografare la chiave simmetrica con la chiave pubblica dell'utente e memorizza il risultato in modo che possa essere scaricato [Lato server]
  4. Un utente accede per scaricare il pacchetto + simmetrico crittografato chiave + chiave privata crittografata [lato server]
  5. Decrittografa la chiave privata, crittografata, memorizzata con le credenziali dell'utente password [lato client]
  6. Decrittografa la chiave memorizzata, crittografata, simmetrica con l'ora decrittografata chiave privata per l'utente [lato client]
  7. Decifra il pacchetto dell'applicazione (in memoria sul computer client) e mostra il contenuto tramite un piccolo server integrato [lato client]

Questo è un modo abbastanza sicuro per risolvere il mio problema? Posso farlo in altro modo? C'è qualche evidente lacuna di sicurezza in questa soluzione?

    
posta Björn 15.01.2014 - 17:38
fonte

2 risposte

1

Se vuoi fare in modo che i dati rimangano crittografati tranne che per alcuni utenti, ognuno con una password, allora hai la sequenza corretta. Tuttavia, ti aiuterà molto non a reimplementarlo da zero. Con un punto di vista leggermente più alto:

  • Ogni utente ha un portachiavi contenente la sua chiave privata e protetto da una password.
  • I dati dell'applicazione sono crittografati asimmetricamente con la chiave pubblica dell'utente.
  • La crittografia asimmetrica è fatta in modo che sia efficiente: è adeguata per dozzine di megabyte di dati e quando gli stessi dati vengono crittografati per diversi utenti, la maggior parte dei dati viene memorizzata solo una volta.

A quel punto, riconosci il problema essere ciò che GnuPG risolve. GnuPG implementa il formato OpenPGP che è stato inizialmente progettato per email , ma in realtà può elaborare blocchi arbitrari di dati. Le librerie e gli strumenti includono già tutta la crittografia e la condivisione ibride per più destinatari e anche la protezione tramite password della chiave privata. Il formato è uno standard ragionevolmente ben studiato, ci sono più implementazioni open-source in varie lingue, questo è mantenuto e mainstream . E non devi dedicare tempo di riflessione alle chiavi simmetriche sottostanti e agli algoritmi annidati.

Tuttavia, l'obiettivo potrebbe essere irraggiungibile. Se i dati sono disponibili, ad un certo punto, nel computer dell'attaccante (qui, l'utente malintenzionato è l'utente stesso, che vuole estrarre i dati e venderli ai concorrenti), allora l'attaccante sarà in grado per ottenerlo direttamente Quello è il suo computer; può scansionare la RAM a volontà.

Naturalmente possiamo iniziare a discutere su quanto "facile" sia per l'utente "medio". Ma bisogna ricordare che se ci fosse un modo sicuro per proteggere i dati in queste condizioni, non ci sarebbe stata pirateria di musica, film o videogiochi; e anche se il valore individuale di una singola canzone è basso, le persone fanno estraggono i dati dai giocatori.

In larga misura, il valore aggiunto di uno schema di crittografia basato su GnuPG, nella tua situazione, è che rende molto ovvio e innegabile che il tuo intento è prevenire e impedire l'estrazione di massa dei dati. Questo può aiutare in situazioni legali; chiunque abbia estratto i dati non può più affermare di non sapere che era proibito.

    
risposta data 21.01.2014 - 19:13
fonte
2

it should be available offline, and it should be secured in a way that a user should not be able to take the application content and give it/sell it to a competitor

Questo non è in generale possibile. L'utente controlla il suo computer e può bypassare qualsiasi meccanismo di sicurezza se è motivato a farlo. Ad esempio, potrebbe utilizzare un debugger per interrompere il programma e leggere le chiavi dalla memoria.

La completa prevenzione con mezzi tecnici non è possibile, quindi è l'obiettivo sbagliato. Gli obiettivi adatti sono:

  • Mantieni onesta la gente onesta
  • Fornisci prove di manomissione / audit trail

Il primo può essere ottenuto relativamente facilmente nascondendo o crittografando file locali in qualche modo. Tuttavia il tuo schema è esagerato. Devi solo inviare a ciascun utente una chiave univoca (che l'app memorizza) ed emettere i documenti / le risorse crittografati su quella chiave. Ovviamente possono facilmente decodificarlo se ci mettono un piccolo sforzo.

Il secondo deve essere raggiunto utilizzando una sorta di schema di filigrana. Ce ne sono molti, ma se per esempio fornisci il contenuto come file PDF, puoi filigranarlo facilmente, ad esempio "Questa copia è stata inviata a [email protected] il 2014-01-21" su ogni pagina - questo sarà visibile per l'utente. (In grigio chiaro, risalire il bordo sinistro della pagina è una scelta popolare). Potresti anche voler includere una seconda filigrana "segreta", per tentare di catturare quelli che fanno di tutto per cancellare quella ovvia.

La filigrana richiede l'emissione di una singola copia per ciascun utente. Questo non è tecnicamente difficile, ma potrebbe essere scomodo.

    
risposta data 21.01.2014 - 18:50
fonte