Newsgroup: it.comp.os.linux.sys
Titolo: HSM senza hardware?

Stavo vedendo come realizzare un server per firmare digitalmente dei 
documenti e ho notato questa definizione di HSM
"A cryptographic module shall be a set of hardware, software, firmware, 
or some combination thereof that
implements cryptographic functions or processes, including cryptographic 
algorithms and, optionally, key
generation, and is contained within a defined cryptographic boundary."
prelevata direttamente dal punto 4.1
http://csrc.nist.gov/publications/fips/fips140-2/fips1402.pdf
Ora, l'idea ï¿œ di utilizzare una VM che funga da "modulo crittografico" 
il chï¿œ apparentemente puï¿œ sembrare folle..
Ma.. se guardiamo 
http://www.actalis.it/
 (Actalis ONE Server) dovrebbe 
fare esattamente questo salvo per il fatto che probabilmente utilizza un 
altro S.O...
Cmq, pare che inserendo le chiavi ed i certificati in un filesystem 
criptato all'interno di una VM anch'essa su FS cifrato si trasformi per 
magia in un HSM consentendo l'importazione delle firme.
Il chï¿œ ridurrebbe i costi all'osso se si riuscisse ad ottenere la 
certificazione FIPS 140-2
Torno a rileggere..


e chi ti dice che quel prodotto non abbia un modulo hardware di
crittografia fips compliant installato? e che poi non ci abbiano messo
una ca che lo sfrutta - tipo ejbca per intenderci - ?
oppure potrebbe essere una porchettata di ca windows server e una
chiavetta usb on board per le chiavi...

Francesco Paolini ha scritto:

Nessuno dubita della qualitï¿œ del prodotto, anche se non mi pare sia 
ancora in vendita, nï¿œ della professionalitï¿œ dell'azienda citata visto 
che sono sia rivenditori THALES che certificatori accreditati CNIPA.
L'idea ï¿œ un altra, partendo dal presupposto che un HSM sostanzialmente 
serve per archiviare le chiavi crittografiche, trasformando la sicurezza 
logica (proteggere un file) in sicurezza fisica (proteggere un oggetto 
non duplicabile).
Ora, se inseriamo l'HSM PCI/PCIe nel server Web e lo utilizzaiamo per la 
firma di file (tralasciando l'autenticazione SSL/TLS che a me non 
interessa per ora) abbiamo comunque il problema che nel caso di un 
attacco esterno che vada a buon fine, l'attaccante puï¿œ de facto 
utilizzare l'HSM per firmare illegalmente, idem nel caso di un 
dispositivo esterno.
Nel primo caso basterï¿œ fare una chiamata openssl passandogli il tipo di 
engine ed il nome della chiave.
Nel secondo caso basterï¿œ formattare una chiamata HTTP/SOAP ed ottenere 
la firma del file in questione.
Quindi sorge il dubbio, visto che il rischio ï¿œ analogo, a che mi server 
un costosissimo HSM quando mi basta configurare un server che riceve una 
chiama via http/https e firma il file (su storage condiviso ovviamente).
Quindi posso avere Apache da un lato con l'applicazione, gestendo gli 
accessi dei client via smart card (CNS) e db per la verifica del codice 
fiscale e delle CRL, e un server che firma in rete privata, ora, mi 
basta prendere il nome-utente di chi deve firmare, il nome del file, 
l'hash SHA1, il path completo, crittare la stringa e passarla al 
sign-server.
Quindi, decrittata la stringa, il sign-server verifica che il file 
esista, verifica l'hash, se il file c'ï¿œ lo firma creando un estensione 
.p7m e restituisce una stringa crittata di risposta (che poi su utilizzi 
SOAP piuttosto che REST o una semplice stringa crittata via curl poco 
cambia)
Al chï¿œ se prendo il mio bel sign-server e lo infilo in una cassa-forte 
(ovvaimente con FS cifrato, firewall & C.o) ho ottenuto lo stesso grado 
di sicurezza spendendo un millesimo.
Ma soprattutto sono sicuro che tra N anni potrï¿œ eventualmente sostituire 
il server ma non dovrï¿œ riacquistare un nuovo HSM perchï¿œ sai com'ï¿œ quello 
vecchio non ï¿œ piï¿œ supportato, mancano i driver e menate varie...

 Torno a rileggere..
anni fa' qualcuno iniziï¿œ qualcosa del genere ...
http://freshmeat.net/projects/lsmpkca11