Come archiviare nel database informazioni riservate crittografate, che dovranno essere decifrate in fase di runtime? [duplicare]

Question

Come archiviare nel database informazioni riservate crittografate, che dovranno essere decifrate in fase di runtime? [duplicare]

#1 da (1 voti)

1

Questa domanda è stata ripubblicata da StackOverflow in base al suggerimento indicato nei commenti

Sto creando un'applicazione in cui ho bisogno di memorizzare le informazioni del cliente (come le API Keys e API Secret per accedere al mio servizio, insieme ad altre informazioni riservate).

Ora, nel database, voglio memorizzarli nel formato crittografato. A questo proposito, ho deciso di utilizzare crittografia a chiave simmetrica , AES in specifico per crittografare i dettagli.

Tuttavia, per motivi di sicurezza, desidero utilizzare una diversa chiave di crittografia AES per ogni client, in modo che anche se il DB è compromesso, tutti i dati non possono essere decifrati utilizzando una sola chiave.

Tuttavia, a causa di ovvi motivi, non voglio memorizzare le mie chiavi private nel DB con le informazioni crittografate.

Quindi, non riesco a decidere come memorizzare le mie chiavi, soprattutto perché ho bisogno di avere un legame che la chiave appartiene a quale client.

Come posso raggiungere questo obiettivo e quale è l'approccio migliore in scenari come questo?

encryption

posta Ayush Gupta 30.12.2017 - 05:04

fonte

1 risposta

Leggi altre domande sui tag encryption

GPG - limita chi può aggiungere e rimuovere da pubring Crittografia utilizzando le migliori pratiche [duplicato]

score 1 · Accepted Answer

Questa è una situazione in cui l'uso di un KEK (Key Encrypting Key) e di più DEK (Data Encrypting Keys) è utile. (Domanda di fondo qui ).

Quello che dovresti fare è crittografare la chiave di ciascun cliente (questi saranno i DEK) usando il KEK. I DEK sono memorizzati (crittografati) nel database. All'avvio dell'applicazione, utilizza il KEK (che è non memorizzato nel database) per decrittografare i DEK, quindi i DEK (decrittografati) (che sono decodificati nel App, non nel database) per eseguire operazioni di crittografia. Quando l'App si spegne, i DEK vengono tutti crittografati in modo sicuro nel database, in attesa che il KEK li sblocchi nuovamente.

Questo modello può consentire di separare le chiavi (DEK nel database, KEK su un file del server delle applicazioni), richiedere l'intervento manuale (KEK fornito all'App all'avvio), o affidarsi a un HSM per il KEK. Tutto ciò fornisce maggiore sicurezza rispetto al semplice riempimento dei client DEK nel database senza protezione.