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

-----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-----

 x/p e f/up su it.comp.sicurezza.crittografia
Cosa significa x/p e f/up ?
Saluti,
GianpieroP.

  [X.509 available]  ,''`.
Linux Reg. User #263663/NEW Machine: #216144 (Debian Sarge/SID) : :' :
On the Web: 
http://www.quagliata.eu.org
 - My GPG Key:0x5539D8E4 `. `'
On ICQ: 48618109 - On Jabber: 
qu...@jabber.org/@jabber.linux.it
   `-

 lo stesso: l'hacking dell'applicazione.
Security by obscurity? BLEAH.
Pensa a qualche cosa di intrinsecamente sicuro, e' meglio. Nascondere
una password (peggio, steganografarla) e' il modo migliore per renderla
facilmente recuperabile (gia' la presenza di tool steganografici rende
il meccanismo di mascheramento della password evidente).
-- 
*    HappyCactus - Linux User #209744 - BOFH Certified Engineer    *
*           27/11/2003 Rilaciata la prima relase di qixl!          *
*    
http://sourceforge.net/projects/qixl
 : una gui per iSiloXC    *
*  
www.google.com
 / 
groups.google.com
 : cercare prima di chiedere  *

-----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-----

 (suppongo), e non ha un e-mail valida...
Se non conosco le sigle, non significa che non ho intuito! Ti sei sbagliato
tu
a postare in cross +, visto che ti avevo già risposto nel newsgroup più
appropriato (e qui ci vuole tatto). Comunque leggilo con toni smussati,
perchè sto replicando scherzosamente: non mi importa la polemica.
Tornando al discorso della steganografia, se non si lasciano tracce
(tool steganografici, algoritmi leggibili, etc.) alla ricerca esaustiva in
decine di G. di ottetti di bit si somma la assoluta non conoscenza del
posizionamento dei singoli bit della chiave. Datemi una dimostrazione
formale che il posizionamento casuale di una semplice terna di bit in
uno spazio di 1MBit (tanto per fare un esempio con quantità assai
limitate) non implichi 10^(6*3) c.a. tentativi per smascherarla!
Oltretutto una possibile soluzione non è neppure validabile:
supponiamo che la mia applicazione legga da un file audio i bit di posizione
i,j,k (tutti compresi tra 0 e 2^20-1 per restare fedeli all'ipotesi di
1MBit)
l'acker per determinare i,j,k effettua varie prove. Tra tutte le terne che
soddisfano la prova (e ce ne sono moltissime), qual'è quella corretta?
Vi prego di convincermi del contrario, perchè mi rendo conto che così
sarebbe troppo facile nascondere informazioni: c'è qualcosa che non va!
Un'ultima cosa: uso smart card per memorizzare la chiave privata:
penso che sia la soluzione migliore che abbiano potuto mai inventare ;-)
Ciao,
GianpieroP
la mia email: "gianpiero.sicurezza.java" (al server di posta)
"
fastwebnet.it
"

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
GianpieroP wrote:
| visto che ti avevo già risposto nel newsgroup più
| appropriato (e qui ci vuole tatto).
Ma se non sapevi cosa è un f/up potevi benissimo non aver notato di
averlo fatto, dato che il normale reply lo fa in automatico =P
| Datemi una dimostrazione
| formale che il posizionamento casuale di una semplice terna di bit in
| uno spazio di 1MBit (tanto per fare un esempio con quantità assai
| limitate) non implichi 10^(6*3) c.a. tentativi per smascherarla!
Non lo so, può anche essere.
In ogni caso avvalora ciò che ho detto: totalmente ininfluente rispetto
a quello che la crittografia dovrebbe aggiungere, in quanto a sicurezza ^_^
| qual'è quella corretta?
I programi di steganografia non sono infiniti.
Anche ammesos di fare qualcosa di totalmente inventato "apposta" e MAI
usato altrove, le cose cambiano poco.
siamo sempre nel campo delle "simpatici trucchetti" e non della
"crittografia seria".
| Vi prego di convincermi del contrario, perchè mi rendo conto che così
| sarebbe troppo facile nascondere informazioni: c'è qualcosa che non va!
Non è che nasconderle non funzioni, però è come dire che un coltello
"funziona" quando si sta parlando di armi di massa...
E, peraltro, il tuo eseguibile (leggibile tendenzialmente da tutti) deve
ACCEDERE a qulle informazioni, quindi lui stesso deve averne
"l'indirizzo"... questo smonta in gran parte il tuo 10^18 (che, ripeto,
non ho verificato).
| Un'ultima cosa: uso smart card per memorizzare la chiave privata:
| penso che sia la soluzione migliore che abbiano potuto mai inventare ;-)
Sì, purtroppo sui server non è applicabile a meno che tu nno vada di
persona in sala machcine ogni volta che riavvii... ^_^
- --
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
iEYEARECAAYFAkAVnRMACgkQaJiCLMjyUvtx6QCgklsvXd78JVO1dmgEIS8noUrV
A7sAnjcb+xy4UCcXo9IOSPKudYdzzMsQ
=ytyk
-----END PGP SIGNATURE-----

 ;-)
Tutta questa tua sicurezza nei tuoi mezzi e nelle tue scelte mi
spaventa. Il termine "sicuro" va sempre accompagnato ad un contesto, in
quanto la tua soluzione potrebbe essere del tutto inefficace in altri
ambiti di applicazione.
HappyCactus meditate, gente, meditate...


 persona in sala machcine ogni volta che riavvii... ^_^
Perchè? Se la lascio inserita nel server?
GianpieroP

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
GianpieroP wrote:
|>Sì, purtroppo sui server non è applicabile a meno che tu nno vada di
|>persona in sala machcine ogni volta che riavvii... ^_^
| Perchè? Se la lascio inserita nel server?
0_o!!!!!!!
Una serratura chiusa con chiave sempre inserita cosa ha di dissimile da
una serratura già aperta?
- --
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
iEYEARECAAYFAkAdHOoACgkQaJiCLMjyUvteRwCgtI03UFZ/32gwiTixUUDYTI5Y
MLUAnRkg5upAaU8plxvtBcovDnZRlDjk
=uXdl
-----END PGP SIGNATURE-----

 una serratura già aperta?
Che la chiave non potrà mai uscire dalla s.c. E ovviamente mi riferivo
a contesti tipo SSL. E' chiaro che se avessi dati cifrati su disco, potrei
mandare pacchetti APDU alla s.c. per farmeli decifrare.
Uso la s.c. per decrittare la chiave di sessione generata di volta in volta dai browser: SSL.
Il che diventa un po' tutto più complicato.
Potrei rubare la s.c.? E a che serve? Il server non funziona più!
Potrei sostituire la s.c.? E il certificato corrispondente?
Insomma mi sa che le cose si complicano un po' con l'introduzione della s.c.
E' chiaro che la sicurezza assoluta non si può mai ottenere. Ma ci si spinge
verso livelli sempre maggiori. E la s.c. mi sa che incomincia a scoraggiare un po'
chiunque.
GianpieroP.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
GianpieroP wrote:
| Potrei rubare la s.c.? E a che serve? Il server non funziona più!
Al tuo attaccante non interessa rubare la chiave: se entra sul server la
chiave è già inserita e a malapena si accorgerà che ci sia, dato che
autenticherà automaticamente ogni transazione "proprio come se non
fossero protette da alcuna chiave".
Certo, c'è il comodo fattore che non può "rubarsela", ma può fare un
sacco di altre cosine... (compreso cancellarla, suppongo =P)
Comunque riguardo alle SC ne so (ancora per poco) troppo poco per dire
altro...
- --
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
iEYEARECAAYFAkAeF0gACgkQaJiCLMjyUvvinACgi/wF2DILdLeaAScrUpOWX75Q
4n8AoP5EuUUs+JHdRz4BpspsNUYNYKUi
=aqif
-----END PGP SIGNATURE-----