[Discussioni] Smart Cards, firma digitale, sw libero (era: Verifica firme digitali (era: esempio di formato dati inadatto))

[Roberto Resoli]

Salve a tutti,
Eccomi di ritorno per qualche giorno, e come promesso cerco di dare
qualche  informazione in più sul tema in oggetto. Purtroppo lo scopo
originale del mio messaggio, cioé contattare Gian Uberto Lauri, non
l'ho ancora raggiunto, probabilmente é in ferie anche lui.
Tempo fa c'é stato un dibattito su SC e firma anche sulla ml  rospa,
così ho pensato di riciclare il post fatto in quella sede, che delinea
situazione e problematiche principali, almeno per quanto ne so io;
spero mi perdoni chi segue anche quella lista.
In più aggiungo solo una nota riguardo j4sign, sostanzialmente si
tratta solo di un API per richiamare (via jni) le funzionalità
crittografiche di una libreria nativa pkcs11 (c'é anche l'ottima
libera opensc-pkcs11 del progetto opensc, per il quale Antonio Iacono
e Sirio Capizzi hanno scritto il supporto per molte carte italiane), e
quelle di "imbustamento" delle librerie pure java di bouncycastle.
Quindi é vero che il tutto dipende fortemente da codice nativo che
deve essere disponibile per la carta e la piattaforma specifica.
Per quanto riguarda la verifica, j4sign offre solo una verifica
crittografica della validità della firma, mentre il pacchetto
freesigner aggiunge il controllo della catena di certificazione, con
verifica on line di CRL e CSL, tutto in pure java. Mancherebbe il
supporto al protocollo OCSP, ma non so se qualche certificatore
italiano lo utilizzi.
Ecco il vecchio post:
===============
---------- Forwarded message ----------
From: Roberto Resoli <roberto.resoli a gmail.com>
Date: 28-mag-2007 19.39
Subject: Software di Firma Digitale e Smart Cards.
To: Rete dell'Open Source nella Pubblica Amministrazione <rospa a rospa.it>


Salve a tutti,
Vorrei esporre alcune cose per fare un po' di chiarezza, per quanto
posso, su questo argomento.
Intanto mi scuso per la stringatezza delle risposte precedenti, erano
dovute a mancanza di tempo.
Chiedo anche a quanti leggono la lista e hanno esperienza in materia
di correggere i miei errori.

Dividerei la quetione in due aree:
- Normativa
- Tecnico - Informatica

*** Area Normativa. ***

La parte meglio normata riguarda i formati file. Al momento attuale
hanno validità in Italia:

1) Pkcs7 (o CMS secondo le RFC)
2) PDF
3) XMLSig

pkcs7 è di gran lunga più diffuso. Si tratta di un formato aperto e
standardizzato, per cui da molti anni, dopo varie circolari di AIPA e
CNIPA, esiste completa interoperabilità.
Questo vuol dire che i file firmati .p7m, creati con uno strumento sw,
sono verificabili con un qualsiasi altro.
Attenzione perchè le RFC  definiscono il formato del file (busta
crittografica), ma ulteriori specificazioni sono contenute nelle
circolari AIPA -CNIPA

Per i sw di firma non vi sono molti vincoli normativi, una delle cose
più importanti da considerare è che un file firmato non può contenere,
ad esempio, macroistruzioni che ne modifichino l'apparenza. La
normativa dice in particolare che il contenuto da sottoscrivere deve
essere presentato completamente e in maniera non ambigua al
firmatario. Un attacco ovvio alla firma digitale è far vedere a chi
firma qualcosa di diverso da ciò che contiene in realtà il file; è il
problema del "Trusted Viewer".

*** Area Tecnico - Informatica ***

Bisogna distinguere innanzitutto tra sw di firma vero e proprio, e
librerie criptoki.
Criptoki sta per Cryptographic Token Interface; si tratta di
implementazioni dello standard PKCS11, che definisce un'insieme di
schemi di chiamate a funzionalità di un token crittografico.
In genere il sw di firma (Dike, ad esempio) è gestito  dalla CA
(Infocamere, in questo caso).
Le librerie cryptoki sono legate quasi sempre al produttore del chip.
La CA acquista i diritti di redistribuzione delle cryptoki dal chipmaker.

Quindi i sw di firma si appoggiano praticamente in toto, per la parte
strettamente crittografica, alle cryptoki del chipmaker. Questo è il
motivo per cui a volte il sw di firma non funziona con carte diverse
da quelle supportate dalla CA che lo ha creato.

A loro volta le cryptoki implementano le macrofunzionalità in termini
di comandi elementari che sono inviabili più o meno direttamente alla
carta, secondo le specifiche ISO 7816. Questi comandi sono trasmessi
in unità dette APDU.

E' possibile ad esempio capire il tipo di carta, ed entro certi limiti
anche la cryptoki necessaria, usando una APDU GetATR che richiede alla
carta il codice ATR, una stringa esadecimale univoca per quel tipo di
carta.

Da quando esistono CIE e CNS, anche il set di APDU è diventato più o
meno standard (almeno un set minimale) e pubblico. La specifica delle
posizioni degli oggetti elementari sulla carta (certificati, chiavi,
ecc) non è però ancora pubblica.

Esiste un progetto open source (LGPL) OpenSC, che, pur essendo nato
per supportare lo standard pkcs15, un'evoluzione di pkcs11, dispone di
un meccanismo che permette di supportare più carte pkcs11 astraendone
le differenze attraverso un layer di emulazione. La cryptoki di
opensc, che supporta moltissime carte europee, si chiama
opensc-pkcs11, e ne esistono versioni per diverse piattaforme. Allo
stato attuale non è possibile includere il supporto per CIE e CNS
italiane perchè la specifica del filesystem non è pubblica.

Ultima cosa: per proteggere meglio il colloquio Applicazione - carta,
la normativa europea prescrive che le APDU vengano crittate (secure
channel). Di solito lo si fa tramite un meccanismo detto Secure
Messaging, che fa sempre parte di ISO 7816. E' anche previsto che
applicazione e carta possano mutuamente identificarsi (secure path).
Per il SM sostanzialmente si usa una chiave segreta per crittare e
decrittare. Il risultato è che se una cryptoki non dispone della
chiave relativa ad una certa carta non può utilizzarla. Di fatto
questo rende impossibile implementare una cryptoki opensource per
queste carte.
Si noti che una recente regola tecnica (CWA 14890) descrive in
dettaglio come derivare una chiave segreta nuova ad ogni sessione di
colloquio applicazione - carta. Quindi il modo di evitare il vendor
locking esiste.
                                                        ***
In sintesi, sostanzialmente i sw di firma sono legati all'utilizzo di
librerie che sono dominio quasi esclusivo dei chipmaker. Da questo
punto di vista CA e programmatori indipendenti sono praticamente nella
stessa situazione.

Scusate la mail lunga, ma spero che serva a qualcuno, e di non aver
scritto troppe cretinate.

Ciao,
Rob
==================

Il 16/07/07, Roberto Resoli<roberto.resoli a gmail.com> ha scritto:
> Il 16/07/07, Gian Mario Tagliaretti<gianmt a gnome.org> ha scritto:
> > Il 16/07/07, Roberto Resoli<roberto.resoli a gmail.com> ha scritto:
> >
> > > Nicola ha ragione, la jvm é il problema minore,
> >
> > e fin qua immaginavo
> >
> > > in genere le carte
> > > dipendono fortemente da librerie (pkcs11, nella fattispecie) per il
> > > funzionamento.
> >
> > eh pero' anche cosi' vuol dir poco, almeno per me che non sono un
> > esperto della crittografia, il supporto pkcs11 esiste in java 5.0,
> > c'e' un problema di OS? implementazione sull'OS?
>
> beh, il supporto é "solo" un provider crittografico, una sorta di
> wrapper attorno alla libreria nativa pkcs11. E tra l'altro non
> esisteva quando j4sign  é nato.
>
>
> >
> > Mozilla implementa lo standard nella libreria nss se non sbaglio, è utile?
>
> é utile, ma si tratta sempre di un wrapper , se parliamo di smart card.
> e solo per autenticazione, non per firma digitale.
>
> ciao,
> Rob
>