Il 21/10/20 19:13, Giovanni Biscuolo ha scritto:
Ciao Roberto,
grazie per la pazienza...
grazie a te, sono molto interessato alla firma in LibO, anche perchè qualche anno fa ho dato una mano al mio amico Giuseppe Castagno per questo: https://joinup.ec.europa.eu/solution/oooxadessignit
Roberto Resoli <roberto@resolutions.it> writes:
[...]
Mi sento un pochino chiamato in causa ;-) .
He he :-D
[...]
Qui serve un chiarimento: storicamente LibO (e OOo ancora prima quando i due non erano ancora progetti distinti) si è sempre appoggiato al sistema di gestione di Mozilla per accedere a chiavi e certificati, sia su file che su token crittografici PKCS11 (come smartcard e token usb).
Quindi per gestire i token occorre avere installata anche una versione recente di Thunderbird o Firefox. Nelle opzioni di LibO (Sicurezza) è possibile anche scegliere il profilo utente specifico di Firefox o Thunderbird che ha configurati i certificati personali che servono.
Hai fatto molto bene a chiarirlo, io avevo saltato a piè pari tutta la spiegazione.
Questo, se non mi sfugge qualcosa, significa anche che con LibO non è possibile firmare senza avere installato Firefox o Thunderbird... uff.
Sì, a quanto pare è ancora così, OpenOffice/LibreOffice dipende da Mozilla per le funzioni crittografiche. Nel progetto di cui sopra avevamo scelto di prescinderne completamente e gestire tutto nell'estensione.
[...]
Se si vuole firmare con valore massimo (firma qualificata) con i token disponibil qui in Italia è *indispensabile* usare la libreria proprietaria fornita a corredo con il token,
Oh mamma, questa cosa la ignoravo completamente (dipende da una certa allergia al burocratese). Spero solo di non dover mai usare una firma qualficata e che per la mia vita burocratica mi basti una firma semplice.
Scusa se ne approfitto, ma qual'è la ratio che ha portato il legislatore a differenziare tra "firma semplice" e "firma qualificata"? Siccome dal punto di vista tecnico sempre di certificati X.509 si tratta, ho come l'impressione che la distinzione sia puramente burocratico-certificatoria: vorrei tanto essere smentito.
Non direi. E' il grado diverso di forza probatoria, a sua volta dipendente sia dalle tecnologie utilizzate che dal soggetto che attesta l'identità del firmatario. La normativa in merito è raccolta principalmente nel regolamento europeo eIDAS[1], entrato in vigore nel 2016. All'Art.25, comma 2 (scusa il burocratese) si legge: 2. A qualified electronic signature shall have the equivalent legal effect of a handwritten signature.
Quindi immagino che anche con la prossima versione 3 di openssl in grado di firmare CAdES non si potranno firmare documenti con firma qualificata.
Ovviamente il problema rimane, dove esista un vendor lock-in come quello italiano.
Ma questa cosa della libreria proprietaria è destinata a sparire o dobbiamo subirla e basta?
Ahimè, non avrei creduto di essere ancora qui a parlarne dopo ben più di 10 anni ... Se non ricordo male tutto nasce dalla normativa tecnica europea che prescriveva per gli SSCD (Secure Signature Creation Devices), termine per indicare i token di firma, un "secure path" e "secure channel" tra dispositivo e applicazione. Detto in soldoni, i due endpoint devono essere mutuamente identificati e il canale crittato. Come in TLS, insomma. Il modo più primitivo di fare questo è usare una chiave simmetrica e cifrare il traffico (Secure Messaging) con quella. Ovviamente la chiave deve essere presente da entrambi i lati. Dato che nessuno ha imposto che l'interoperabilità andasse garantita, il lock-in era lì pronto per essere usato. Notare che fin dall'inizio anche nelle specifiche tecniche europee esistevano tutti le indicazioni su come negoziare dinamicamente le chiavi, come si fa in TLS. Successivamente le specifiche (che prevedono Secure Messaging con negoziazione dinamica delle chiavi) si sono evolute in IAS-ECC (ECC sta per European Citizen Card), che ad esempio OpenSC supporta pienamente[2]. Per quanto ne so, nessun fornitore italiano supporta IAS-ECC per i dispositivi di firma, anche perchè nessuno gli l'ha chiesto. Dovrebbe essere IAS-ECC la nostra CIE, che però non ha certificati di firma a bordo.
dato che da noi è invalsa l'abitudine di annegare chiavi simmetriche 3DES nel binario dell'applicazione per crittare il colloquio tra token e terminale (Secure Messaging).
...e a che pro? Per evitare un attacco MITM tra il token e il terminale?
Esatto, nessuna ironia.
Ironia a parte: tu che ne pensi?
Che dopo 15 anni siamo ancora qui a parlarne.
Le implementazioni PKCS11 in sw libero (come la opensc-pkcs11 di OpenSC) funzionano solo parzialmente, permettendo di "vedere" le sole chiavi e certificati usabili per autenticazione (e non quelle per sottoscrizione). Queste chiavi non sono soggette in genere a Secure Messaging.
In realtà le chiavi sono usabili non solo per autenticazione ma anche per firma semplice, giusto?
Diciamo di di sì, nulla vieta di farlo tecnicamente. La differenza tra le due coppie di chiavi è dovuta al fatto che si ritiene inopportuno per evitare attacchi crittografici utilizzare la stessa coppia di chiavi per la firma di documenti (Non Repudiation), e per quantità generate automaticamente (all'interno di un protocollo di comunicazione come TLS, ad esempio) (Digital Signature). Tra parentesi ho messo esattamente i due flag dell'attributo KeyUsage che distinguono i due certificati. Nella normativa tecnica italiana si prescriveva che le chiavi per firma riportassero nel certificato corrispondente l'attributo KeyUsage marcato critico con il solo flag "nonRepudiation". Non so se sia ancora così.
[...]
Le CA reperibili a questa pagina: "Infocert Servizi di Certificazione ..." sono relative alle chiavi e certificati di Autenticazione, quindi non a quelle di Sottoscrizione "InfoCert Firma Qualificata ..."
Quindi le firme che hai verificato sono semplici firme digitali, ma non qualificate.
Non so che tipo di firma serve per il MALEDETTO documento che tra qualche tempo dovrò firmare e ho *tanta* paura che non verrà riconosciuto come validamente firmato.
Che poi io eviterei tutta sta procedura e firmerei anche di mio pugno che della firma qualificata m'importa meno di zero... però questo implicherebbe che mi dovrei rivolgere a un notaio coi relativi costi :-O
Messa in questi termini mi pare abbastanza evidente la situazione di "cittadino di serie B" nella quale un utente che come me vorrebbe usare solo software libero viene "condannato". C'è di peggio eh, però mi scoccia non poco.
[...]
Dopo qualche ricerca ho trovato che AGID distribuisce i certificati [2] in formato XLS con schema TSL (Trust Service status List): https://eidas.agid.gov.it/TL/TSL-IT.xml
Esatto, lì trovi anche i certificati di Firma Qualificata.
Sono quelli di livello 3?
[...]
Per favore sapete se esiste un tool per convertire gli XML il formato TSL nel formato PKCS#7 (quello importabile da NSS aka Mozilla Firefox)?
I certificati sono inclusi codificati base64 quindi basta un copia incolla aggiungendo header e footer per ottener il PEM. Puoi recuperare direttamente il PEM anche usando secondo tool che hai menzionato.
Antonio in questo thread ha segnalato uno script, proverò a usare quello che dovrebbe automatizzare il tutto.
PS: pur aggiungendo la libreria pkcs11 proprietaria corretta sono riuscito a firmare in libo solo con le chiavi di Autenticazione, mentre con quelle di sottoscrizione il programma si blocca.
La butto lì: incompatibilità ABI?!?
Non saprei, devo indagare. Forse Antonio ne sa di più. Proverò a chiedere anche a Giuseppe Castagno che è il guru di LibO.
No comment.
Grazie, Giovanni.
ciao, rob [1] https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=uriserv:OJ.L_.2014.257.0... [2] https://github.com/OpenSC/OpenSC/wiki/IAS-ECC