Archiviazione della chiave di crittografia

Question

Archiviazione della chiave di crittografia

#1 da (3 voti)
#2 da (1 voti)

5

Recentemente ho ereditato un sistema di archiviazione chiavi integrato. La società memorizza i dati della carta di credito in due server di database crittografati con AES. I tasti risiedono in un sistema separato che si trova nella propria DMZ. Quando un server Web deve crittografare alcuni dati, il server delle chiavi viene chiamato tramite https e richiede una chiave. Restituisce una chiave e un numero di serie codificato. Il server delle app memorizza le informazioni crittografate e il numero di serie, quindi scarta la chiave. Quando i dati devono essere decrittografati, il numero di serie viene inviato al server delle chiavi che restituisce la chiave utilizzata per quel record.

L'utente che lo ha sviluppato non ha utilizzato i pool principali. Ogni chiave è un valore casuale unico. Il database delle chiavi viene crittografato utilizzando una chiave generata da 2 password fornite da 2 custodi. Da quello che sto vedendo, anche se avessi ottenuto i tasti, dovresti essere in grado di decodificare i numeri seriali per poterli usare, e quindi ogni chiave andrebbe bene solo per un record. Ha anche scritto un'estensione php in c che ha le funzioni di codifica / decodifica.

Questo sembra essere un buon progetto. Chiunque abbia esperienza con questo tipo di cose che possono dare un'opinione su questo metodo e su eventuali buchi o miglioramenti.

architecture encryption

posta Pete Robbins 17.11.2012 - 06:21

fonte

2 risposte

Leggi altre domande sui tag architecture encryption

Sicurezza dei database NoSQL È bcrypt sicuro con l'attacco di compleanno a 64 bit della cifratura a blocchi?

score 3 · Answer 1

A prima vista, sembra essere geniale e un doppio livello di sicurezza. Su ulteriore pensiero, è abbastanza simile alla tokenizzazione delle carte di credito, con 1 pro e 1 contro invece di tokenizzazione:

pro - ci sono due livelli di crittografia in due sistemi separati
con - i numeri di carta di credito completi, anche se crittografati, sono ancora memorizzati nel sistema aziendale e la crittografia è reversibile.

Sebbene la configurazione dei due custodi sia un buon meccanismo, le chiavi del regno sono ancora la chiave di crittografia del "database delle chiavi". Se sono compromessi, il resto è solo la ricerca e gli algoritmi e tutti i numeri di carte di credito possono sfuggire.

Sulla base di un'analisi preliminare, mi permetto di dire che, nel complesso, è forse meno sicuro per un sistema di tokenizzazione. Un token non può essere invertito, può essere solo controllato e quindi limitato, controllato da IP ecc. Un buon sistema di tokenizzazione ha altri vantaggi come può essere esternalizzato, oppure il numero CC può essere rilasciato a terzi come un pagamento processore, ecc. e i numeri CC, crittografati o chiari, non vengono mai archiviati in un sistema aziendale e non possono nemmeno entrare nel settore aziendale dopo essere stati scambiati per un token la prima volta.

score 1 · Answer 2

Suoni complicati e fragili - mantenere questo sarà un dolore. Che ne dici di questo per un potenziale buco:

"the key server is called via https and requests a key"

Se la richiesta https al server delle chiavi è protetta utilizzando un certificato debole (ad esempio autofirmato), la connessione di scambio delle chiavi potrebbe essere falsificata (ad es. da un attacco MITM che restituisce una chiave conosciuta - facile decifrare le cose più tardi quando si conosce il È abbastanza probabile poiché il server delle chiavi non è pubblico e forse il creatore non pensava di utilizzare una CA commerciale, mi chiedo se il certificato del server SSL sia stato verificato correttamente .... o se il richiedente della chiave verifica di vedere se una chiave diversa viene ricevuta ogni volta, potrebbe essere facile ripetere il messaggio iniziale più e più volte ... ora ho solo bisogno di rompere un tasto! Oh bene.