Newsgroup: it.comp.lang.delphi
Titolo: Firma Digitale

Salve a tutti,
leggendo post del Newsgroup di Delphi ho visto che per tematiche di
firma digitale č stato consigliato il software IP*Works S/MIME di n/
Software: dovendolo valutare
avrei qlc quesito (magari stupido):
io devo firmare dei file che contengono immagini medicali (nello
standard DICOM): il componente da quel poco che so di S/MIME e da quel
che ho capito č fatto normalmente per firmare una property Message di
tipo AnsiString (normalmente il messaggio di posta) e quindi suppongo
documenti "testuali": č un problema nel mio caso?
Non essendo molto pratico come potrei fare (se fattibile) per avere il
mio file "come stringa".
Ma soprattutto fare in questo modo produce una vera "firma digitale"
del file?
Grazie per il consiglio
Saluti
Matteo

 del file?
no, produce una *copia* del file originale che *include* la firma, un 
file di tipo pkcs#7 secondo gli standard rsa.
Tieni conto che da nsoftware puoi scaricare una trial *completamente 
funzionante*. L'unica rottura č il msg visualizzato ad ogni applicazione 
di firma....
Ovviamente ti serve un certificato, ma quello lo chiedi ad una CA. In 
italia Infocamere.
-- 
Alberto Salvati
A *Neapolitan* delphi developer who is studing c# & .Net
"Dicette 'o pappece 'nfaccia 'a noce dammi 'o tiempo che pure te spertoso!"

 
Già che ci sono, e vista la tua gentilissima disponibilità, mi daresti
magari un buon link dove trovare una chiara (e magari breve)
spiegazione di questi "simpatici" standard pkcs#*?
Nel mio progetto entrano in gioco anche le SmartCard (GemPlus) :
esiste qualche componente in Delphi per gestirle secondo lo standard
pkcs#11? Oppure l'unica è usare le dll di Gemplus?
Grazie mille
Matteo

 pkcs#11? Oppure l'unica è usare le dll di Gemplus?
non ti serve gestire le smartcard.
Tra te e le smartcard esiste uno strato software (x la piattaforma m$ è 
il CSP contro resto del mondo che usa pkcs#11) che fa da interfaccia.
In pratica tu scegli *il certificato* e non il device
E' il certificato stesso che sa cosa deve usare anche in termini di device.
Ad esempio, se usi un certificato su smartcard dovresti avere un tool 
che ne installa una parte nello storage di sistema.
Quando tenti di usarlo, lui sa che deve cercare la smartcard, leggere 
qualcosa e chiedere ad esempio un pin.
Attenzione che puoi tozzare su 2 cose...
1) ipworks non prevede il caching del pin
Quindi, se devi applicare n firme, ti becchi n richieste di pin.
Ad una mia specifica richiesta mi hanno detto "non esiste! creerebbe 
falle nella sicurezza.. Che succede se tu inserisci il pin usi il 
certificato, te ne vai, arriva qualcuno e lo usa tranquillamente???"
Questa cosa, x operazioni batch puo essere risolta in modo 
sporco&bastardo usando un hook che intercetta la dialog di richiesta del 
pin lo scrive nella casella di testo e manda un sequenza di tasto 
invio.... :)
2) il funzionamento di alcuni csp (in fondo sono dll che espongono un 
set di funzioni predefinito...) è legato al nome del file exe che lo usa.
Se cerchi "cryptoapi" su msdn trovi info su come sono implementati i csp.
In pratica...
Tutti gli altri hanno n standard, uno x scopo (pkcs#7, pkcs#11, pkcs#12..)
Il csp invece è uno, sta a chi lo scrive scegliere quali funzioni 
implementare di quelle indicate dalle specifiche  microsoft; infatti chi 
li produce fornisce in genere un documento con l'elenco delle funzioni 
implementate.


 un AnsiString, anzi nell'ansi string del componente TipmSMIME!
puoi fare un typecast di un array di caratteri ad ansistring
leggi con un tmemorystream, copu in un buffer, poi fai il typcast del 
buffer ad ansistring e lo sommi ad una ansistring
Questa string la metti nella prop message e poi SIGN! ;)


...
