Criptare dati sensibili

[Leonardo Valenti]

Buongiorno,
avrei la necessit? di criptare dati sensibili su un database ma sono nuovo
nel campo e vorrei avere maggiori informazioni.
Premetto che l'applicazione sar? sviluppata in Java e preveder? nella sua
fase iniziale, solamente una form (JSP e struts2) per l'inserimento dei dati
sensibili e l'immagazzinamento su database (dopo un'opportuna validazione).
Poi i dati dovranno essere riletti in seguito.

1) quale algoritmo utilizzare? ho sentito parlare dell'AES a 128bit; ?
abbastanza sicuro?

2) come gestire la chiave? come generarla? dove salvarla? dovr? essere
unica?

3) quali sono gli accorgimenti da tenere e le possibili tipologie di attacco
che si possono subire (es. SQL injection, etc.)?

4) dove posso trovare eventualmente documentazione sull'argomento?


Grazie per l'attenzione

[Claudio "BlackFire" Criscione]

Post by Leonardo Valenti
avrei la necessit? di criptare dati sensibili su un database ma sono nuovo
nel campo e vorrei avere maggiori informazioni.

[---]

Post by Leonardo Valenti
1) quale algoritmo utilizzare? ho sentito parlare dell'AES a 128bit; ?
abbastanza sicuro?
2) come gestire la chiave? come generarla? dove salvarla? dovr? essere
unica?

Questo dipende in buona sostanza dalle condizioni a contorno. In che modo
leggerai i dati in un secondo momento, che volumi ti aspetti di vedere, che
tipo di minacce hai modellizzato sull'infrastruttura?

Post by Leonardo Valenti
3) quali sono gli accorgimenti da tenere e le possibili tipologie di
attacco che si possono subire (es. SQL injection, etc.)?

I "possibili tipi di attacco qui" sono tutto il parco attacchi per le webapp (
owasp.org e buona lettura ;-) ) nonchè quelli all'infrastruttura: se il
sistema che ospita l'applicazione viene compromesso e si recupera la chiave si
ha buon gioco a decifrare i dati. Ah, mettiamoci anche gli attacchi di livello
network, se per caso non stai usando a modo SSL o chi per lui per trasmettere
i dati in chiaro.

Claudio

[Andrea Adami]

Post by Leonardo Valenti
Buongiorno,
avrei la necessit? di criptare dati sensibili su un database ma sono
nuovo nel campo e vorrei avere maggiori informazioni.

Il mio consiglio è lavorare lato DB.
Il DB che conosco maggiormente è SQL SERVER che dalla versione 2005 ha
funzioni specifiche per criptare i dati.
Se non c'è il supporto nativo di solito è possibile estendere le funzioni
del linguaggio SQL con librerie apposite per la criptazione dei dati.

Post by Leonardo Valenti
1) quale algoritmo utilizzare? ho sentito parlare dell'AES a 128bit; ?
abbastanza sicuro?
2) come gestire la chiave? come generarla? dove salvarla? dovr? essere
unica?
3) quali sono gli accorgimenti da tenere e le possibili tipologie di
attacco che si possono subire (es. SQL injection, etc.)?
4) dove posso trovare eventualmente documentazione sull'argomento?

Tutto dipende come il singolo database implementa la funzionalità di
criptazione.

Ciao
Andrea Adami

________________________________________________________
http://www.sikurezza.org - Italian Security Mailing List

[Marco Ermini]

2009/6/26 Andrea Adami:
[...]

Post by Andrea Adami
Il mio consiglio è lavorare lato DB.

[...]

Secondo me dipende moltissimo da quello che si deve fare e dal perché,
ma in linea di massima, ci andrei piano con la criptazione lato DB.
L'esperienza pratica insegna che pone più problemi di quanti ne
risolve.

Non so come funzioni in SQL Server, ma in Oracle dalla versione 10g in
avanti, la criptazione è trasparente, non è segnalata in alcun modo a
meno che non si richieda lo status del DB esplicitamente, e cripta
tutti i backup. Questo significa che un "disgruntled DBA" può iniziare
la criptazione di un intero DB senza che nessuno se ne accorga (a meno
che il DB non venga restartato, ma capita normalmente in Oracle che
non venga restartato per mesi e mesi... in Windows immagino un po'
meno, dato che devi installare quanto minimo le patch settimanali
dell'OS ;-)), e dopo dei mesi - dopo che tutti i backup, completi ed
incrementali, di mesi e mesi sono criptati e recuperabili soltanto da
questo DBA... - lasciare l'azienda non dopo aver fatto lo shutdown del
DB... e chiedere un bel riscatto :-)

È molto piu facile e sicuro criptare il solo campo dell'unica tabella
in cui il dato serve effettivamente criptato, e lasciar stare il DB
come è :-) le funzioni di criptazione trasparente del DB dovrebbero
essere lasciate a installazioni specifiche con richieste particolari
ed essere trattate di conseguenza, con una procedura di change
management messa in pratica per la gestione della criptazione del DB.


Cordiali saluti

[Cesare]

Secondo me dipende moltissimo da quello che si deve fare e dal perché,
ma in linea di massima, ci andrei piano con la criptazione lato DB.
L'esperienza pratica insegna che pone più problemi di quanti ne
risolve.

Alle volte sì, alle volte no. Quello che interessa sapere, sopratutto,
quale Ú il requisito riguardo allla criptazione dei dati e da cosa
proteggerli. Se lo scopo Ú quello di non perdere il controllo dei dati
presenti nel DB (per esempio nella sostituzione di un disco guasto, al
furto dei dischi o nella copia dell'intero DB in altra copia) allora,
la criptazione lato DB Ú utile. Mentre, se Ú richiesta una separazione
di compiti tra i DBAs (che hanno full-access sul DB stesso) e i dati
in esso contenuto, allora la criptazione lato DB non Ú del tutto
sufficente (anche facendo una coerente profilatura degli account). Si
possono comunque abbinare le due soluzioni.

Un'altra possibilità Ú quella di criptare le informazioni a livello di
colonna utilizzando le primitive Oracle (non conoscendo SQL
Server)come DBMS_CRYPTO, questo pero sottointende di riscrivere le
applicazioni che accedono al DB e/o alle tabelle, rivedendo la
struttura della base dati (esempio gli indici).

Un ulteriore sicurezza Ú quella di sviluppare by-hand l'algoritmo di
criptazione, ma in questo caso porre attenzione anche alle questioni
di performance della base dati.

Da non dimenticare che anche il colloquio tra il DB e i relativi
client che accedono ai dati devono essere criptati, per ovviare al
network-sniffing.

Cesare
--

Clifford Stoll  - "The Internet is a telephone system that's gotten uppity."

[Roberto Scaccia]

Secondo me dipende moltissimo da quello che si deve fare e dal perch?,
ma in linea di massima, ci andrei piano con la criptazione lato DB.
L'esperienza pratica insegna che pone pi? problemi di quanti ne
risolve.

Alle volte s?, alle volte no. Quello che interessa sapere, sopratutto,
quale ? il requisito riguardo allla criptazione dei dati e da cosa
proteggerli. Se lo scopo ? quello di non perdere il controllo dei dati
presenti nel DB (per esempio nella sostituzione di un disco guasto, al
furto dei dischi o nella copia dell'intero DB in altra copia) allora,
la criptazione lato DB ? utile. Mentre, se ? richiesta una separazione
di compiti tra i DBAs (che hanno full-access sul DB stesso) e i dati
in esso contenuto, allora la criptazione lato DB non ? del tutto
sufficente (anche facendo una coerente profilatura degli account). Si
possono comunque abbinare le due soluzioni.
Un'altra possibilit? ? quella di criptare le informazioni a livello di
colonna utilizzando le primitive Oracle (non conoscendo SQL
Server)come DBMS_CRYPTO, questo pero sottointende di riscrivere le
applicazioni che accedono al DB e/o alle tabelle, rivedendo la
struttura della base dati (esempio gli indici).

Oracle dalla versione 11 permette di gestire le chiavi e la cifratura con un
HSM e PKCS#11. Senza utilizzare Package PL/SQL e/o modificare il codice per
aprire il password wallet e via dicendo. Ovviamente si deve comunque
accedere all'HSM con un'autenticazione e richiedere la decifratura del dato
da visualizzare lato client.

Un ulteriore sicurezza ? quella di sviluppare by-hand l'algoritmo di
criptazione, ma in questo caso porre attenzione anche alle questioni
di performance della base dati.
Da non dimenticare che anche il colloquio tra il DB e i relativi
client che accedono ai dati devono essere criptati, per ovviare al
network-sniffing.

Si ma oltre a questo andrebbe minimizzato il tempo in cui il dato ? visibile
in chiaro nella parte client. Sparare a video una tabella con tutti i dati
in chiaro annullerebbe tutta la sicurezza del sistema. Bisogna quindi
gestire in modo opportuno il dato e quindi la sua visualizzazione/modifica
sul client. Per esempio visualizzando di volta in volta solo il singolo dato
(con eventuale modifica), una sessione di tempo ridotta e "zeroing" delle
zone di memoria client.

Certo se poi si dota l'utente di funzionalit? di stampa :-)

Comunque la cifratura del dato attraverso un sistema nativo (ex: DBMS
connesso ad HSM) con protezione del canale e sviluppo dell'applicazione
client in modo opportuno pu? garantire (IMHO) un buon livello di sicurezza
del sistema.

Inoltre delegare a meccanismi nativi la cifratura permetterebbe di superare
pi? agilmente eventuali Audit e/o certificazioni (di almeno una parte
dell'infrastruttura). Diversamente con soluzioni home-made bisognerebbe far
analizzare agli auditor l'intero codice, anche di cifratura. E l? la vedo
pi? dura!

Ciao

Roberto

Cesare
--
Clifford Stoll - "The Internet is a telephone system that's gotten
uppity."
________________________________________________________
http://www.sikurezza.org - Italian Security Mailing List

[KJK::Hyperion]

Post by Leonardo Valenti
1) quale algoritmo utilizzare? ho sentito parlare dell'AES a 128bit; ?
abbastanza sicuro?

alt. Leggere e rileggere:

http://www.matasano.com/log/1749/typing-the-letters-a-e-s-into-your-code-youre-doing-it-wrong/

Le risposte sono nelle ultime 4 battute, il resto è il processo mentale
________________________________________________________
http://www.sikurezza.org - Italian Security Mailing List

[yersinia]

Post by Leonardo Valenti
4) dove posso trovare eventualmente documentazione sull'argomento?

Tutte le domande che tu poni sono abbastanza documentate sul web. Ma
se cerchi qualcosa di ottimo su tutte le problematiche descritte
allora, a mio avviso, è difficile trovare qualcosa di meglio del libro
"Pratical Cryptography" di Ferguson e Schneier
(http://www.schneier.com/book-practical.html).

Ciao

Elia

Post by Leonardo Valenti
________________________________________________________
http://www.sikurezza.org - Italian Security Mailing List

________________________________________________________
http://www.sikurezza.org - Italian Security Mailing List

[Stefano Zanero]

Post by Leonardo Valenti
avrei la necessit? di criptare dati sensibili su un database ma sono nuovo
nel campo e vorrei avere maggiori informazioni.

La prima domanda e' "perche'" ? Da cosa vuoi proteggere codeste
informazioni ?

Post by Leonardo Valenti
1) quale algoritmo utilizzare? ho sentito parlare dell'AES a 128bit; ?
abbastanza sicuro?

Qui vale oro cio' che ti e' stato consigliato di leggere di Tom Ptacek.

Aggiungo che, in genere, "quale algoritmo" non e' una scelta importante,
purche' sia mainstream e robusto.

Post by Leonardo Valenti
2) come gestire la chiave? come generarla? dove salvarla? dovr? essere
unica?

Vedi sopra.

Post by Leonardo Valenti
3) quali sono gli accorgimenti da tenere e le possibili tipologie di attacco
che si possono subire (es. SQL injection, etc.)?

Se ti aspetti attacchi a livello applicativo, con ogni probabilita'
cifrare i dati a livello di DB non sara' d'aiuto. Se ti aspetti attacchi
a livello piu' basso puo' essere utile. Tutto dipende dal tuo threat model.
--
Cordiali saluti,
Stefano Zanero

Politecnico di Milano - Dip. Elettronica e Informazione
Via Ponzio, 34/5 I-20133 Milano - ITALY
Tel. [phone]
Fax. [phone]
E-mail: ***@elet.polimi.it
Web: http://home.dei.polimi.it/zanero/
________________________________________________________
http://www.sikurezza.org - Italian Security Mailing List