Newsgroup: it.comp.java
Titolo: Sicurezza dei dati di un'applicazione java

Ciao,
sto lavorando su una webapp java che gestisce dati che (almeno in parte)
sono sensibili e quindi vanno ben protetti.
L'applicazione utilizza un sistema di persistenza dei dati: i dati sono
salvati su disco (una sorta di snapshot del sistema) e vengono caricati
interamente nella memoria (del server) ogni volta che l'applicazione viene
avviata.
Ovviamente ho gia' intenzione di utilizzare un sistema di autenticazione
dell'utente con login e password per controllare l'accesso all'applicazione,
ma vorrei aumentare la sicurezza dei dati sensibili, in modo che se anche
qualcuno riuscisse ad avere accesso allo snapshot su disco, non riuscisse a
cavarci nulla di intellegibile.
Sto attualmente indagando JCE, l'estensione di Java per la crittografia...
A prescindere dal sistema di persistenza usato (classico DBMS o OODBMS),
nessuno di voi ha mai avuto esigenze del genere, ovvero criptare i dati
sensibili di un'applicazione?
E anche, che tipo di soluzione avete adottato per cifrare i dati?
Grazie mille!
Piero

 E anche, che tipo di soluzione avete adottato per cifrare i dati?
Nel tuo caso consiglierei cifratura simmetrica (3DES per esempio),
visto che non devi trasmettere i dati: chi li deposita (il server)
li riprende pure.
Particolare cura devi tenere nel cercare il nascondiglio più
sicuro per la chiave crittografica utilizzata. Anzi è consigliabile
aggiornarla periodicamente in automatico. Usa CipherStream
per scrivere e leggere da file cifrati.
Usa getEncoded (della classe SecretKey) per serializzare la chiave
e usa un'istanza del KeyFactory per rivitalizzarla.
Su 
java.sun.com
 trovi tutorial sulla JCA (Java Criptography Architecture)
docs > guide > security

 docs > guide > security
Ho trovato:
http://developers.sun.com/events/techdays/presentations/prague/SecurityAndIdentity.pdf
Leggi slide 10 e 11!!
AES è un altro algoritmo di crittografia
simmetrico: Advanced Encryption Standard.
Spero di esserti stato utile.
GianpieroP
***************************************
messaggio inviato tramite HostSearch.it
---------------------------------------
---> 
http://www.hostsearch.it/newsgroup
***************************************

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
GianpieroP wrote:
| Particolare cura devi tenere nel cercare il nascondiglio più
| sicuro per la chiave crittografica utilizzata.
Viene da sé che la chiave non dovrebbe essere sullo setsso server che
contiene anche i dati crittati o "tutto sarà inutile": chi ha accesso ai
disco con i dati, avrebbe accesso anche alla chiave.
Ovviamente, però, il server ha bisogno della chiave stessa per crittare
i dati.
| Anzi è consigliabile
| aggiornarla periodicamente in automatico.
Non capisco questo consiglio.
Anzi, i dati meno volte sono "in chiaro" (e per 'aggiornare' la chiave
devi prima decrittare tutto e poi ri-crittare tutto) meglio è!
Ovviamente fino a certi limiti... (ad esempio oltre la decina d'anni è
probabilmente utile ri-crittare tutto per evitare attacchi a forza
bruta; anche meno se la chiave è generata in modo "sbagliato", ad
esempio se è una password alfabetica di meno di 40 caratteri)
Due consigli:
1. JCE è molto carino ma è disponibile per default solo a partire da
JDK1.4, se non erro; opzionalmente era installabile fin dalla JDK1.2,
invece (ma con download e licenza separato dal JDK)
2. se quello che ti interessa è la mera crittografia AES/CTR ("mera" per
modo di dire: è uno dei migliori algoritmi oggi conosciuti) puoi fare a
meno dell'ambaradan del JCE e usare direttamente una classe che
implementi solo quella in meno di 7Kb di .class
Altre ulteriori disquisizioni sulla crittografia in sé e su come è
melgio fare le cose (generare la chiave in modo casuale, etc. etc.) sono
più inerenti a it.comp.sicurezza.crittografia, dove non sarò il solo a
poterti consigliare, ma troverai numerosi altri "esperti" (in realtà di
esperti non ce ne sono, diciamo che ce la caviamo =P).
- --
L a p o   L u c h i n i
l a p o @ l a p o . i t
w w w . l a p o . i t /
http://www.megatokyo.it
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (Cygwin)
Comment: Using GnuPG with Mozilla - 
http://enigmail.mozdev.org
iEYEARECAAYFAkARH+4ACgkQaJiCLMjyUvth/wCg/bClR7+Jcp07KBj05ewOGbuZ
O/8An2LwNBEJxNETWXbTeqkjr7J0Twoz
=IqYT
-----END PGP SIGNATURE-----

 wrote in message
news:bur7de$kvsqt$2...@ID-187835.news.uni-berlin.de...


 devi prima decrittare tutto e poi ri-crittare tutto) meglio è!
No, mi riferisco ad una chiave di sessione, anzi ora che ci
ripenso è meglio rigenerarla per ogni sessione.
Se leggi bene la mail di partenza (quella di Pieroz)
lo use-case è:
"l'applicazione utilizza un sistema di persistenza dei dati: i dati sono
salvati su disco (una sorta di snapshot del sistema) e vengono caricati
interamente nella memoria (del server) ogni volta che l'applicazione viene
avviata."
Conviene utilizzare una nuova chiave per ogni nuova sessione
(Avvio fino a shutdown) dell'application server.
Infine, riferendomi alla news di Pieroz più avanti nel thread,
lo sconsiglio di creare nuove architetture non collaudate.
Se il tuo scopo è evitare l'accesso al file devi solo cifrare il file.
Per il nascondiglio della chiave esistono diverse tecniche che
consentono di nasconderela all'interno dello stesso sistema
(vedi la "Steganografia", per esempio).
L'algoritmo 3DES non mi sembra sia stato ancora violato con
crittoanalisi. A forza bruta è un po' improbabile (se usi chiavi
a 168 bits). La convenienza di AES è la semplicità e la velocità
di esecuzione, e forse anche il mistero che aleggia sulla progettazione
(resa mai nota) delle S-BOX del DES.
Un libro utile: "Crittografia e sicurezza delle reti", W. Stallings.
Che ne direste di spostare questa discussione sul newsgroup che
tu citavi?
Cordiali saluti,
GianpieroP

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
GianpieroP wrote:
| "l'applicazione utilizza un sistema di persistenza dei dati: i dati sono
| salvati su disco (una sorta di snapshot del sistema) e vengono caricati
| interamente nella memoria (del server) ogni volta che l'applicazione viene
| avviata."
|
| Conviene utilizzare una nuova chiave per ogni nuova sessione
| (Avvio fino a shutdown) dell'application server.
Mi pare che Pieroz, nel suo secondo messaggio, abia parlado diun
ambiente un po' diverso: non un programam che ha bisogno "in itineris"
di salvare roba su disco in modo sicuro e poi ricaricarla (in tal caso
la chiave di sessione *realmente* casuale è sicuramente la scelta
milgiore), ma di un programam che critta singoli campi di un database.
In tal caso la chiave ha necessità (ovviamente) di essere sempre la
stessa nel tempo (altrimenti all'esecuzione dopo nno puoi decrittare i
dati salvati precedentemente) o quantomeno ha bisogno di essere crittata
in un luogo fisso con una (seconda) chiave, in questo modo la chiave in
sé può anche cambiare spesso.
E' comunque "scomodo" dover ricrittare l'intero DB campo per campo e una
chiave AES, se usata bene, non "rilascia" abbastanza informazioni da
avere una vità così breve da giustificare una ri-crittaizone dell'nitero
DB a ogni esecuzione.
Al limite, come dicevo, come procedura di sicurezza "ogni tanto"...
(ovviamente il generatore casuale deve esseer *tale*, o quantomeno un
generatore pseudocasuale crittograficamente sicuro, come ad esempio
Fortuna o Yarrow; riguardo al java.security.SecureRandom non ricordo, in
questo momento, recensioni specifiche, ma mi pare di ricordare che
mancava di alcune procedure di sicurezza che sarebbe melgio che ci
fossero...)
| Infine, riferendomi alla news di Pieroz più avanti nel thread,
| lo sconsiglio di creare nuove architetture non collaudate.
Questo *sempre e comunque*.
Bisogna essere *bravi* e molto sicuri delle proprie capacità anche solo
per implelentare della sciruezza "ben conosciuta", figuriamoci quando ci
si addentra in campi inesplorati...
Un programma se ha un bug al limite ogni tanto darà qualche eccezioncina
o qualche risultato leggermente sbagliato; mentre nel campo della
sicuerzza ogni minimo bug tendenzialmente scardina l'intero sistema...
| Se il tuo scopo è evitare l'accesso al file devi solo cifrare il file.
| Per il nascondiglio della chiave esistono diverse tecniche che
| consentono di nasconderela all'interno dello stesso sistema
| (vedi la "Steganografia", per esempio).
Usare la crittografia diventa un simpatico (nonché inutile) esercizio di
stile se la chiave è nascosta nel sistema stesso.
A quel punto è totalmente inutile pensare a AES o Serpent, DES andrà più
che bene... (nonostante DES *non* vada bene ^_^)
| L'algoritmo 3DES non mi sembra sia stato ancora violato con
| crittoanalisi.
3DES è *schifosamente lento*.
AES è qualcosa come 20 volte più veloce... e di sicurezza non minore,
almeno a parere di tutti i maggiori crittografi del mondo, che hanno
partecipato all'elezione di "AES" stesso tra i vari finalisti.
| La convenienza di AES è la semplicità e la velocità
La semplicità è una convenienza maggiore di quanto si crea, in un mondo
dove -come dicevo prima- ogni bug è in genere fatale...
| Un libro utile: "Crittografia e sicurezza delle reti", W. Stallings.
Non lo conosco... ma giusto in questi giorni su
it.comp.sicurezza.crittografia si sta parlando di libri sulla
crittografia in italiano.
| Che ne direste di spostare questa discussione sul newsgroup che
| tu citavi?
Dato che stiamo parlando di crittografia e non più di "come farla in
Java", direi che è il caso, sì:
x/p e f/up su it.comp.sicurezza.crittografia
- --
L a p o   L u c h i n i
l a p o @ l a p o . i t
w w w . l a p o . i t /
http://www.megatokyo.it
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (Cygwin)
Comment: Using GnuPG with Mozilla - 
http://enigmail.mozdev.org
iEYEARECAAYFAkARuv0ACgkQaJiCLMjyUvtWvQCgito2vd0BJ9YRbM3oTHsgpvST
OiAAnjmiTeY1Ta/P8AlcoH/tJEQcWnm7
=rHGo
-----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
GianpieroP wrote:
|>Usare la crittografia diventa un simpatico (nonché inutile) esercizio di
|>stile se la chiave è nascosta nel sistema stesso.
|>A quel punto è totalmente inutile pensare a AES o Serpent, DES andrà più
|>che bene... (nonostante DES *non* vada bene ^_^)
| Ripeto: penso che non è insicuro memorizzare la chiave
| nello stesso sistema se usi qualche tecnica che la nasconda.
...e ti sbagli. ^_^
(no, non lo dico io, non solo io, almeno)
| Ad esempio la  "Steganografia" utilizzando risorse già presenti
| nel sistema (bitmap, file di testo, etc.).
La steganografia è, al pari di crittare una una chiave presente nello
stesso luogo di ciò che dovrebbe "difendere" un simpatico (nonchè
inutile) esercizio di stile.
Rispetto al tempo che ci vorrebbe per "rompere la crittografia", il
tempo che ci vuole a cercare una chiave su tutto l'hard disk è
assolutamente ininfluente.
|Il punto debole è sempre
| lo stesso: l'hacking dell'applicazione. Ma è un caso pericoloso
| anche se l'applicazione deve recuperare la chiave da un altro sistema.
| Non pensi?
Se l'applicazione può essere modificata a piacere nessuna difesa può
esistere...
|>x/p e f/up su it.comp.sicurezza.crittografia
| Cosa significa x/p e f/up ?
Cross-post e follow-up: quando un argomento non è inerente al newsgroup
in cui si staparlando si imposta il cross-post (ovvero si posta
l'articolo su due newsgroup) e il follo-up (quello che indica a chi
risponde su quale NG deve rispondere), in modo che le rispsote si
spostino automaticamente sul newsgroup "giusto".
BTW: questo messaggio è in cross-post, dato che la persona interessata
pare non sapere cosa è un f/up e quindi non noterebbe la rispsota
(suppongo), e non ha un e-mail valida...
- --
L a p o   L u c h i n i
l a p o @ l a p o . i t
w w w . l a p o . i t /
http://www.megatokyo.it
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (Cygwin)
Comment: Using GnuPG with Mozilla - 
http://enigmail.mozdev.org
iEYEARECAAYFAkAVIPQACgkQaJiCLMjyUvvmEwCgqc3ke7wKKPHUdBiNhsdyG0eK
U0AAnROQtWlZtt/CLWdIgkn4fwY/y2Oc
=uMBY
-----END PGP SIGNATURE-----