Quanto può essere affidabile la crittografia dei dati senza reinserire la password all'avvio?

1

Ho postato un commento un po 'indietro , e ho pensato di trasformarlo in una domanda.

Esempio: c'è una funzione in Microsoft SQL Server per la crittografia completa del database , che sembra avere un'opzione che non richiede una password al riavvio. Capisco che tu possa usare DPAPI o EKM, ma non sono ancora sicuro delle reali limitazioni di un tale sistema.

In realtà non sono interessato alla funzionalità di Microsoft SQL Server in particolare, solo nei limiti di uno schema di crittografia teorico.

Domanda: Dato un server che richiede la chiave di crittografia per essere ricreabile senza richiedere all'utente di inserire un segreto, Quanta barriera può essere posizionata contro l'attaccante?

Sono a conoscenza dei seguenti

  • Complessità (l'utente malintenzionato potrebbe non sapere come decodificare senza guardare il codice del mio programma)
  • Barriere all'accesso utente (il sistema operativo potrebbe essere in grado di memorizzare le informazioni in modo tale che gli account utente non possano accedere senza root)

Oltre a questo, mi mancano idee concrete:

Se l'autore dell'attacco può leggere il disco, sembra che non avresti alcuna protezione. (a meno che tu non abbia usato un hardware di crittografia speciale)

Infine, poiché la chiave deve essere memorizzata su un altro computer, di nuovo, non vedo come (supponendo che Complessità e sicurezza attraverso l'oscurità siano superate) si potrebbe impedire a quel diverso computer di fornire la chiave necessaria all'attaccante che ha accesso al server che normalmente è consentito.

Pertanto, qualsiasi indicazione su un tipico schema di crittografia sarebbe apprezzata e quali sarebbero normalmente le limitazioni.

    
posta George Bailey 24.07.2012 - 18:46
fonte

1 risposta

2

Le domande reali qui sono: Quanta parte di una barriera può essere posta contro l'aggressore WHAT ? Se il sistema non ha bisogno di una password all'avvio, se un utente malintenzionato ha accesso fisico allora è banale da bypassare. Non è letteralmente una misura di sicurezza e un attacco come attacco di avvio a freddo probabilmente non è richiesto.

Che mi dici di MS-SQL? Bene, questo sistema di crittografia sta impedendo un REMOTE ATTACKER possibilmente con un difetto di iniezione di SQL in grado di accedere ai dati sensibili. Tieni presente che se l'autore dell'attacco ha un difetto come SQL Injeciton, allora l'attaccante NON DEVE avere pieno accesso al disco, a meno che, naturalmente, non ci sia un'app Web che utilizza un account senza restrizioni come sa , che sarebbe un problema molto più grande .

Spostare solo la chiave su un'altra macchina in realtà non aiuta, se la macchina compromessa può accedere alla chiave, allora l'aggressore può accedere alla chiave. Ciò che può aiutare è la creazione di un archivio di informazioni sensibili. Quindi in questo modello un'applicazione web ha due database. Un database per la memorizzazione di informazioni non molto sensibili e un altro database solo per la memorizzazione di dati crittografati. Il database crittografato è reso il più restrittivo, è accessibile solo da una lista bianca di macchine e il numero di query su questa macchina è ridotto al minimo. Le probabilità di un difetto di iniezione sql contro questo database sono molto più basse.

    
risposta data 24.07.2012 - 19:42
fonte

Leggi altre domande sui tag