Libreoffice e verifica validità della firma elettronica: una jungla?
Buongiorno nexiane, approfitto del fatto che in lista ci sono esperti di firma elettronica per condividere la mia piccola esperienza di utente che vorrebbe firmare e verificare i documenti con LibreOffice (in PAdES o XAdES ma tanto quest'ultimo non se lo fila nessuno... mi pare). Scrivo qui perché mi auguro possa essere di interesse generale, scusate se approfitto: so bene che non è una lista di supporto utenti! Comunque, dopo un po' di ricerche e tribolazioni per far funzionare lo sblocco della smartcard via PIN, sono riuscito a configurare due browser (Firefox e Ungoogled-Chromium) e per usarla come mezzo di autenticazione per firmare con Libreoffice. La prima cosa che ho notato è che la mia firma *non* era considerata valida e dopo pochissimo mi sono reso conto che Infocert, ovvero chi ha fornito le mie chiavi private, è *assente* dall'elenco delle Authorities ufficialmente riconosciute da Firefox (Libreoffice usa il database di Firefox): è un mio problema o davvero ciascun utente deve importare "a mano" le CA per poter verificare la firma. Comunque sia una volta importati "a mano" un paio di certificati di Infocert [1] ho potuto verificare come valide le firma fatte da me :-D La cosa veramente buffa è che anche il mio collega ha un token per la firma con chiave emessa da Infocert nel 2018, anche lui può usarlo per firmare con Libreoffice... tranne che la sua firma non risulta verificata nemmeno dopo aver importato "a mano" i certificati [1]. Evidentemente nel frattempo Infocert ha sostituito i suoi certificati e io non so dove andare a prenderli :-O. 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 Esiste anche un servizio web (software libero [3]) per consultare degli elenchi TSL pubblicati da ciascuno stato membro: https://webgate.ec.europa.eu/tl-browser/#/ C'è anche questo che permette di vedere via web le informazioni dettagliate di ciascun certificato: http://tlbrowser.tsl.website/tools/ 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)? Grazie! Giovanni [1] https://www.firma.infocert.it/installazione/#certificati [2] https://www.agid.gov.it/it/piattaforme/firma-elettronica-qualificata/certifi... [3] https://ec.europa.eu/cefdigital/code/projects/ESIG/repos/tlb/browse/digit-ts..., licenza LGPL 2.1 -- Giovanni Biscuolo
La prima cosa che ho notato è che la mia firma *non* era considerata valida e dopo pochissimo mi sono reso conto che Infocert, ovvero chi ha fornito le mie chiavi private, è *assente* dall'elenco delle Authorities ufficialmente riconosciute da Firefox (Libreoffice usa il database di Firefox): è un mio problema o davvero ciascun utente deve importare "a mano" le CA per poter verificare la firma.
Infocert (e le altre CA italiane) sanno dell'esistenza di Firefox? Suppongo di sì e allora la verità è che non gliene frega nulla di quell'1% di utenti che potrebbero beneficiarne dall'avere la propria CA dentro il root certificate store di Firefox. In fondo, dalle parti di Mozilla si chiede alle CA solo partecipazione e collaborazione, mica soldi (almeno da quanto si legge qui [1]) ...
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)?
Una volta l'avevo fatto io, non so più dove è andato a finire, se lo trovo lo metto a disposizione. Antonio [1] https://blog.mozilla.org/security/2019/02/14/why-does-mozilla-maintain-our-o...
...
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)?
prova questo https://github.com/eniocarboni/getTrustCAP7m Antonio
Antonio Iacono <antiac@gmail.com> writes:
...
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)?
prova questo https://github.com/eniocarboni/getTrustCAP7m
Grazie mille per la segnalazione, appena ho un po' di tempo provo uno di quegli script Ciao, Giovanni -- Giovanni Biscuolo
Il 16/10/20 18:48, Giovanni Biscuolo ha scritto:
Buongiorno nexiane,
approfitto del fatto che in lista ci sono esperti di firma elettronica per condividere la mia piccola esperienza di utente che vorrebbe firmare e verificare i documenti con LibreOffice (in PAdES o XAdES ma tanto quest'ultimo non se lo fila nessuno... mi pare).
Scrivo qui perché mi auguro possa essere di interesse generale, scusate se approfitto: so bene che non è una lista di supporto utenti!
Mi sento un pochino chiamato in causa ;-) . In realtà mi sembra che le cose che chiedi non siano di "supporto" (di cosa poi? LibO, Firefox, altro ...) ma ragionevoli domande di qualcuno che intenda usare sw libero per firmare digitalmente usando un token.
Comunque, dopo un po' di ricerche e tribolazioni per far funzionare lo sblocco della smartcard via PIN, sono riuscito a configurare due browser (Firefox e Ungoogled-Chromium) e per usarla come mezzo di autenticazione per firmare con Libreoffice.
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. A sua volta Mozilla si appoggia all'api PKCS11 per riconoscere il token. Occorre caricare la relativa libreria nella sezione "Certificati" la libreria pkcs11 che gestisce il proprio token. 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, 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). 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.
La prima cosa che ho notato è che la mia firma *non* era considerata valida e dopo pochissimo mi sono reso conto che Infocert, ovvero chi ha fornito le mie chiavi private, è *assente* dall'elenco delle Authorities ufficialmente riconosciute da Firefox (Libreoffice usa il database di Firefox): è un mio problema o davvero ciascun utente deve importare "a mano" le CA per poter verificare la firma.
Comunque sia una volta importati "a mano" un paio di certificati di Infocert [1] ho potuto verificare come valide le firma fatte da me :-D
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.
La cosa veramente buffa è che anche il mio collega ha un token per la firma con chiave emessa da Infocert nel 2018, anche lui può usarlo per firmare con Libreoffice... tranne che la sua firma non risulta verificata nemmeno dopo aver importato "a mano" i certificati [1]. Evidentemente nel frattempo Infocert ha sostituito i suoi certificati e io non so dove andare a prenderli :-O.
Immagino che sia così, ma senza l'Issuer è difficile dire qualcosa.
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.
Esiste anche un servizio web (software libero [3]) per consultare degli elenchi TSL pubblicati da ciascuno stato membro: https://webgate.ec.europa.eu/tl-browser/#/
C'è anche questo che permette di vedere via web le informazioni dettagliate di ciascun certificato: http://tlbrowser.tsl.website/tools/
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. ciao, rob 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.
Ciao Roberto, grazie per la pazienza... 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. [...]
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. Quindi immagino che anche con la prossima versione 3 di openssl in grado di firmare CAdES non si potranno firmare documenti con firma qualificata. Ma questa cosa della libreria proprietaria è destinata a sparire o dobbiamo subirla e basta?
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? Ironia a parte: tu che ne pensi?
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? [...]
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?!? No comment. Grazie, Giovanni. -- Giovanni Biscuolo
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
Il 22/10/20 09:51, Roberto Resoli ha scritto:
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:
Per chi fosse interessato, qui si trova ancora la presentazione di Davide Dozza fatta al convegno OpenGood dell'ospedale Galliera di Genova nel 2011: https://www.galliera.it/opengood/presentazioni-pdf/05%20-%20Davide%20Dozza-O... rob
Il 22/10/20 09:51, Roberto Resoli ha scritto:
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.
Con una certa fatica ho recuperato i dettagli (a volte il "Permanent Record" serve a qualcosa ...): http://opensc.1086184.n5.nabble.com/Secure-Messaging-td4174.html#a4175 rob
Ciao Roberto, Roberto Resoli <roberto@resolutions.it> writes:
Il 21/10/20 19:13, Giovanni Biscuolo ha scritto:
[...]
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.
Non ho capito in cosa sia tecnologicamente inferiore il certificato X.509 della "firma semplice" rispetto a quello della "firma qualificata", ovviamente a parità di soggetto attestante (tutti i sggetti sono approvati dall'autorità pubblica). Però la cosa si sta facendo molto tecnica: mi fido del tuo giudizio se mi dici che differenziare "fa senso".
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.
Ecco appunto: distinzione *puramente* de jure, la distinzione tecnica tra un X.509 "qualificato" e uno "semplice" mi sfugge, CA certificate usato a parte. [...]
Ahimè, non avrei creduto di essere ancora qui a parlarne dopo ben più di 10 anni ...
É da 15 anni che il solo e UNICO problema che ho con l'utilizzo del software libero è quello che mi viene impedito di usare l'hardware (per mezzo dei "driver" proprietari). Ogni volta che voglio usare un dispositivo - dalla scheda video allo scanner - devo faticare come un forsennato per trovare quello che funziona con il kernel Linux mainline e il software user space per dialogare con il dispositivo. Sono esausto. E io faccio il sistemista da anni, per lavoro. [...]
Come in TLS, insomma.
Sì mi era chiaro grazie. [...]
Per quanto ne so, nessun fornitore italiano supporta IAS-ECC per i dispositivi di firma, anche perchè nessuno gli l'ha chiesto.
Mavà?!? Sono solo io che noto l'ormai insopportabile e insostenibile leggerezza del Codice dell'Amministrazione Digitale? La soluzione tecnica c'è, basterebbero tre righe in un DPCM :-O
Dovrebbe essere IAS-ECC la nostra CIE, che però non ha certificati di firma a bordo.
Quindi per poter apporre una "firma qualificata" come desidero io dovrei chiedere asilo politico alla Francia?
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.
Oh mamma. Se ho capito bene, siccome il solo e unico mezzo de facto per connettere il token al terminale (il mio computer) è l'USB, l'unico vettore di attacco per un MITM (escludendo me ovviamente) è il sistema operativo e per proteggere la comunicazione tra token e computer da possibile malware si usa un canale simil-TLS? Ho capito bene o mi sfugge qualcosa?
Ironia a parte: tu che ne pensi?
Che dopo 15 anni siamo ancora qui a parlarne.
E saremo qui ancora a parlarne tra 10 anni, magari non proprio dei token per la firma di altro hardware. [...]
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ì.
OK, non ne so abbastanza di X.509... uff [...]
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.
In bocca al lupo su questa cosa! Per quanto mi riguarda, installare un driver proprietario o l'intero DIKE proprietario non fa differenza: se sarò costretto farò così, subirò protestando (al vento, perché con chi protesto?!?) come in tante altre cose. Saluti, Giovanni.
[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 -- Giovanni Biscuolo
Il 22/10/20 11:53, Giovanni Biscuolo ha scritto:
Ciao Roberto,
Roberto Resoli <roberto@resolutions.it> writes:
Il 21/10/20 19:13, Giovanni Biscuolo ha scritto:
[...]
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.
Non ho capito in cosa sia tecnologicamente inferiore il certificato X.509 della "firma semplice" rispetto a quello della "firma qualificata", ovviamente a parità di soggetto attestante (tutti i sggetti sono approvati dall'autorità pubblica).
In nulla, dal punto di vista tecnologico. Dal punto di vista di chi emette il certificato, invece, si tratta di certificati emessi con scopi diversi, cito dal precedente messaggio:
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).
Come conseguenza, le due root CA in cima alla catena dei due certificati sono diverse. E la "Infocert Servizi di Certificazione ...", ad esempio, *non* è tra quelle di firma Qualificata (non è esposta come tale nella TSL italiana).
Però la cosa si sta facendo molto tecnica: mi fido del tuo giudizio se mi dici che differenziare "fa senso".
vedi sopra.
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.
Ecco appunto: distinzione *puramente* de jure, la distinzione tecnica tra un X.509 "qualificato" e uno "semplice" mi sfugge, CA certificate usato a parte.
La differnza è negli scopi di utilizzo delle chiavi, e si sostanzia nella CA utilizzata per l'emissione.
[...]
Ahimè, non avrei creduto di essere ancora qui a parlarne dopo ben più di 10 anni ...
É da 15 anni che il solo e UNICO problema che ho con l'utilizzo del software libero è quello che mi viene impedito di usare l'hardware (per mezzo dei "driver" proprietari). Ogni volta che voglio usare un dispositivo - dalla scheda video allo scanner - devo faticare come un forsennato per trovare quello che funziona con il kernel Linux mainline e il software user space per dialogare con il dispositivo.
Sono esausto. E io faccio il sistemista da anni, per lavoro.
... sfondi portoni spalancati ... :((
[...]
Come in TLS, insomma.
Sì mi era chiaro grazie.
[...]
Per quanto ne so, nessun fornitore italiano supporta IAS-ECC per i dispositivi di firma, anche perchè nessuno gli l'ha chiesto.
Mavà?!? Sono solo io che noto l'ormai insopportabile e insostenibile leggerezza del Codice dell'Amministrazione Digitale?
La soluzione tecnica c'è, basterebbero tre righe in un DPCM :-O
Eh sì ... ma non ci sono queste righe, e intanto girano milioni di dispositivi non interoperabili.
Dovrebbe essere IAS-ECC la nostra CIE, che però non ha certificati di firma a bordo.
Quindi per poter apporre una "firma qualificata" come desidero io dovrei chiedere asilo politico alla Francia?
:-) Non sono aggiornato. Ma ai miei tempi sarebbe stato meglio Finlandia o Estonia. Ah, tra l'altro attualmente è possibile chiedere la e-residenza in Estonia, ricevendo la relativa carta d'identità: https://e-resident.gov.ee/become-an-e-resident/ Naturalmente dovresti poi convincere chi riceve il tuo documento che la firma fatta con la carta estone è valida (lo è).
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.
Oh mamma. Se ho capito bene, siccome il solo e unico mezzo de facto per connettere il token al terminale (il mio computer) è l'USB, l'unico vettore di attacco per un MITM (escludendo me ovviamente) è il sistema operativo e per proteggere la comunicazione tra token e computer da possibile malware si usa un canale simil-TLS?
Ho capito bene o mi sfugge qualcosa?
Hai capito bene, ma la normativa astrae dal tipo di canale. Ad esempio ci sono soluzioni che remotizzano l'accesso al dispositivo.
Ironia a parte: tu che ne pensi?
Che dopo 15 anni siamo ancora qui a parlarne.
E saremo qui ancora a parlarne tra 10 anni, magari non proprio dei token per la firma di altro hardware.
Probabilmente sì, anche se credo che nel mondo attuale, invece di permetter l'accesso paritario all'hardware, semplicemente si elimini l'hardware (vedi firma remota), aumentando enormemente il lock-in.
[...]
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ì.
OK, non ne so abbastanza di X.509... uff
Basta che apri un qualsiasi certificato ssl, anche dal browser, e trovi 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.
In bocca al lupo su questa cosa!
Per quanto mi riguarda, installare un driver proprietario o l'intero DIKE proprietario non fa differenza: se sarò costretto farò così, subirò protestando (al vento, perché con chi protesto?!?) come in tante altre cose.
Ti ho scritto in privato su questo, per non appesantire troppo la lista. Di fatto ti basta solo la libreria PKCS11, per il resto puoi usare sw libero. Questo è il massimo che si possa fare, con il token che hai in mano, al momento. Ciao, rob
Saluti, Giovanni.
[1] https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=uriserv:OJ.L_.2014.257.0...
Ciao Roberto, Roberto Resoli <roberto@resolutions.it> writes: [...]
Sono esausto. E io faccio il sistemista da anni, per lavoro.
... sfondi portoni spalancati ... :((
Sì lo so, siamo in tanti in questa situazione: «Ciao, mi chiamo Giovanni e faccio uso di software libero da 15 anni; ho provato molte terapie ma non riesco a smettere...» :-D [...]
Ah, tra l'altro attualmente è possibile chiedere la e-residenza in Estonia, ricevendo la relativa carta d'identità:
Interessante: ne avevo sentito parlare ma non ho mai approfondito, da tenere in considerazione.
Naturalmente dovresti poi convincere chi riceve il tuo documento che la firma fatta con la carta estone è valida (lo è).
Ah andiamo bene... [...]
Hai capito bene, ma la normativa astrae dal tipo di canale. Ad esempio ci sono soluzioni che remotizzano l'accesso al dispositivo.
Sì sì, mi è tutto chiarissimo dal punto di vista tecnico e mi è anche chiarissima l'abberrazione di aver permesso che l'accesso al dispositivo fosse remotizzato (smaterizliazato). La cosa che mi fa letteralmente rotolare dal ridere è che io che possiedo fisicamente la smartcard _non_ sono in grado di leggere il certificato per la firma qualificata mentre nel caso di firma remota quel certificato lo possono leggere tutti quelli che hanno accesso alla macchina dove è "ospitato": _magari_ mi sbaglio e la faccio troppo facile ma... diciamo che non sono lontano dall'azzeccarci. [...]
Probabilmente sì, anche se credo che nel mondo attuale, invece di permetter l'accesso paritario all'hardware, semplicemente si elimini l'hardware (vedi firma remota), aumentando enormemente il lock-in.
Se fosse disponibile solo la firma remota io di certo NON la userei e sconsiglierei vivamente, in modo professionale e documentato, altri ad usarla. [...]
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ì.
OK, non ne so abbastanza di X.509... uff
Basta che apri un qualsiasi certificato ssl, anche dal browser, e trovi tutto.
Sì grazie, intendevo dire che non ho studiato abbastanza i flag a disposizione e la loro semantica. [...]
Per quanto mi riguarda, installare un driver proprietario o l'intero DIKE proprietario non fa differenza
Ho detto una sciocchezza sull'onda del nervoso che mi è venuto nell'aver constatato che mi ero illuso di poter fare a meno di driver proprietari: usare "solo" un piccolo driver proprietario o un'intera applicazione ovviamente fa differenza. [...]
Di fatto ti basta solo la libreria PKCS11, per il resto puoi usare sw libero. Questo è il massimo che si possa fare, con il token che hai in mano, al momento.
Quello che si può fare è già molto, soprattutto considerando che (da quello che capisco) questo risultato è stato ottenuto senza la benché minima collaborazione da parte della "mano pubblica". Nei limiti delle mie risorse vedrò come riesco a collaborare affinché firmare digitalmente sia sempre più facile e alla portata di tutti (nonostante le serie perplessità sull'intero sistema X.509). Grazie ancora! Giovanni [1] è già abbastanza facile anche usando una smartcard, se poi la _smaterializziamo_ e la rendiamo accessibile tramite internet allora... ciao! -- Giovanni Biscuolo
Nei limiti delle mie risorse vedrò come riesco a collaborare affinché firmare digitalmente sia sempre più facile e alla portata di tutti (nonostante le serie perplessità sull'intero sistema X.509).
Dell'intero sistema X.509 purtroppo se ne sa molto poco. Ad esempio, in questi giorni, nella lista si parla tanto di monopoli di aziende high-tech. Un altro monopolio è quello delle certification authority (CA), anzi, dei providers che forniscono i certificati, leggi un po' qua [1]. Un articolo fatto molto bene che può chiarirti le idee lo trovi qui [2]. Antonio [1] https://en.wikipedia.org/wiki/Certificate_authority#Providers [2] https://proprivacy.com/guides/root-certificates-explained
Buongiorno Antonio, grazie che entri un po' nel merito, spero che anche le nexiane non tecniche abbiano la pazienza di approfondire un minimo. Antonio Iacono <antiac@gmail.com> writes:
Nei limiti delle mie risorse vedrò come riesco a collaborare affinché firmare digitalmente sia sempre più facile e alla portata di tutti (nonostante le serie perplessità sull'intero sistema X.509).
Dell'intero sistema X.509 purtroppo se ne sa molto poco.
Scusa Antonio ma no, se ne parla poco fra i non addetti ai lavori ma si sa tutto: https://en.wikipedia.org/wiki/X.509#Security (purtroppo la pagina italiana non è altrettanto aggiornata e precisa). Ci sono quattro classi di problemi, alcuni dei quali *esclusivi* di X.509: 1. debolezze architetturali 2. problemi con le CA (questi sono _esclusivi_ di X.509) 3. problemi di implementazione (esclusivi di X.509) 4. debolezze della crittografia Lascio come compito ai lettori più attenti trovare notizie in merito alla compromissione di intere Certification Authorities da parte dei *Marziani*. Alcuni rompiscatole come me di recente hanno anche sollevato la questione in questa lista ("sulla falsificazione di identità digitale"), solo nel tentativo di evidenziare il problema.
Ad esempio, in questi giorni, nella lista si parla tanto di monopoli di aziende high-tech. Un altro monopolio è quello delle certification authority (CA), anzi, dei providers che forniscono i certificati, leggi un po' qua [1].
Come cittadino mi fa un po' impressione che nel digitale le attività di certificazione - storicamente attribuite alla pubblica amministrazione - siano sostanzialmente privatizzate. Per essere chiari: un modo tecnicamente migliore rispetto a X.509 di garantire la sicurezza delle comunicazioni *e* delle firme digitali ESISTE, ci hanno messo 20 anni per metterlo a punto e ora è un prototipo interessante sul quale ci si potrebbe costruire sopra un sistema pubblico di trust decente: https://reclaim.gnunet.org/
Un articolo fatto molto bene che può chiarirti le idee lo trovi qui [2].
Grazie del riferimento, conoscevo il sistema delle CA ma quell'articolo mi fornisce ulteriori puntatori a notizie e iniziative, tipo https://www.eff.org/observatory che non conoscevo. Anche questo può chiarirci le idee sullo stato dell'ONION: https://ma.ttias.be/the-broken-state-of-trust-in-root-certificates/ «The Broken State of Trust In Root Certificates» Quindi, quando parliamo di "firma elettronica qualificata", non prendetemi per matto quando dico che ci sono delle serie e fondate perplessità sull'intero sistema: se manca la fiducia nel sistema come può funzionare nel medio termine? Io per esempio sono tra quelli che firmano OpenPGP anche i messaggi inviati via PEC, così me ne accorgerei nel caso compromettessero il giro del fumo :-O Saluti, Giovanni.
[1] https://en.wikipedia.org/wiki/Certificate_authority#Providers [2] https://proprivacy.com/guides/root-certificates-explained
-- Giovanni Biscuolo
Grazie dei link, che guarderò con calma.
Come cittadino mi fa un po' impressione che nel digitale le attività di certificazione - storicamente attribuite alla pubblica amministrazione - siano sostanzialmente privatizzate.
Già, me lo chiedo da anni pure io. Perchè un sito della P.A. deve essere "certificato digitalmente" da un'azienda privata straniera? Perchè un cittadino deve essere "certificato digitalmente" da un'azienda privata? Perché lo Stato è azionista, spesso con quote di maggioranza, in una innumerevole quantità di società (una per tutte, parlando di imprese tecnologiche, STMicroelectronics [1]) e gli enti pubblici hanno creato, negli ultimi ventanni migliaia di società e consorzi [2], se poi i compiti ad essi spettanti per legge vengono delegati ad altri? Antonio [1] https://it.wikipedia.org/wiki/STMicroelectronics#Azionariato [2] https://www.blia.it/partecipazioni-pa/
Il 23/10/20 15:30, Giovanni Biscuolo ha scritto:
Ciao Roberto,
Roberto Resoli <roberto@resolutions.it> writes:
[...]
Sono esausto. E io faccio il sistemista da anni, per lavoro.
... sfondi portoni spalancati ... :((
Sì lo so, siamo in tanti in questa situazione: «Ciao, mi chiamo Giovanni e faccio uso di software libero da 15 anni; ho provato molte terapie ma non riesco a smettere...» :-D
eh, contro la libertà le terapie sono tante, e per lo più cercano di reprimere i sintomi ... ma una volta infetti c'è poco da fare.
[...]
Ah, tra l'altro attualmente è possibile chiedere la e-residenza in Estonia, ricevendo la relativa carta d'identità:
Interessante: ne avevo sentito parlare ma non ho mai approfondito, da tenere in considerazione.
Naturalmente dovresti poi convincere chi riceve il tuo documento che la firma fatta con la carta estone è valida (lo è).
Ah andiamo bene...
[...]
Hai capito bene, ma la normativa astrae dal tipo di canale. Ad esempio ci sono soluzioni che remotizzano l'accesso al dispositivo.
Sì sì, mi è tutto chiarissimo dal punto di vista tecnico e mi è anche chiarissima l'abberrazione di aver permesso che l'accesso al dispositivo fosse remotizzato (smaterizliazato).
Io mi riferivo più ad un'accesso indiretto ad un dispositivo che è comunque sotto il tuo controllo, come in PCSC Relay[a], che ha un interesse più che altro accademico, oppure per parlare di cose attuali, al recente uso della Carta d'Identità Elettronica come token di autenticazione gestito via NFC dal proprio telefono[b]
La cosa che mi fa letteralmente rotolare dal ridere è che io che possiedo fisicamente la smartcard _non_ sono in grado di leggere il certificato per la firma qualificata mentre nel caso di firma remota quel certificato lo possono leggere tutti quelli che hanno accesso alla macchina dove è "ospitato": _magari_ mi sbaglio e la faccio troppo facile ma... diciamo che non sono lontano dall'azzeccarci.
Attenzione, il certificato è pubblico per definizione, tu probabilmente pensi alla corrispondente chiave privata, che dovrebbe essere non estraibile dal dispositivo (anche da quello remoto). Si genera lì e rimane lì. Sempre secondo i sacri testi, ovviamente. Cosa succeda in realtà, già con dei dispositivi non inizializzati autonomamente (figuriamoci quelli remoti), non è dato sapere.
[...]
Probabilmente sì, anche se credo che nel mondo attuale, invece di permetter l'accesso paritario all'hardware, semplicemente si elimini l'hardware (vedi firma remota), aumentando enormemente il lock-in.
Se fosse disponibile solo la firma remota io di certo NON la userei e sconsiglierei vivamente, in modo professionale e documentato, altri ad usarla.
[...]
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ì.
OK, non ne so abbastanza di X.509... uff
Basta che apri un qualsiasi certificato ssl, anche dal browser, e trovi tutto.
Sì grazie, intendevo dire che non ho studiato abbastanza i flag a disposizione e la loro semantica.
Ma certo, si sta veramente entrando molto nel dettaglio, e volevo solo dare un esempio percorribile da tutti.
Per quanto mi riguarda, installare un driver proprietario o l'intero DIKE proprietario non fa differenza
Ho detto una sciocchezza sull'onda del nervoso che mi è venuto nell'aver constatato che mi ero illuso di poter fare a meno di driver proprietari: usare "solo" un piccolo driver proprietario o un'intera applicazione ovviamente fa differenza.
Si, la differenza vera la farebbe il potersi generare le chiavi autonomamente (su un dispositivo certificato, certo) e invocare i servizi del certificatore solo per la firma della chiave pubblica, come si fa da sempre per i server web. Ma viviamo qui e ora ...
Di fatto ti basta solo la libreria PKCS11, per il resto puoi usare sw libero. Questo è il massimo che si possa fare, con il token che hai in mano, al momento.
Quello che si può fare è già molto, soprattutto considerando che (da quello che capisco) questo risultato è stato ottenuto senza la benché minima collaborazione da parte della "mano pubblica".
Non direi, visto che, almeno per j4sign, è frutto del lavoro di un dipendente pubblico e il rilascio è stata una decisione politica.
Nei limiti delle mie risorse vedrò come riesco a collaborare affinché firmare digitalmente sia sempre più facile e alla portata di tutti (nonostante le serie perplessità sull'intero sistema X.509).
Perplessità sacrosante.
Grazie ancora! Giovanni
A te, rob
[1] è già abbastanza facile anche usando una smartcard, se poi la _smaterializziamo_ e la rendiamo accessibile tramite internet allora... ciao!
[a] http://frankmorgner.github.io/vsmartcard/pcsc-relay/README.html [b] https://www.cartaidentita.interno.gov.it/identificazione-digitale/cie-id/
Ciao, ci tengo a un'ultima precisazione. Roberto Resoli <roberto@resolutions.it> writes: [...]
Quello che si può fare è già molto, soprattutto considerando che (da quello che capisco) questo risultato è stato ottenuto senza la benché minima collaborazione da parte della "mano pubblica".
Non direi, visto che, almeno per j4sign, è frutto del lavoro di un dipendente pubblico e il rilascio è stata una decisione politica.
Hai ragione, ho parlato a vanvera e me ne scuso con tutti i decisori politici che sostengono convintamente il lavoro sul e per il software libero e per una sana digitalizzazione della PA. Coraggio! [...] Grazie, Giovanni. -- Giovanni Biscuolo
Il 24 ottobre 2020 09:46:48 CEST, Giovanni Biscuolo <giovanni@biscuolo.net> ha scritto:
Ciao,
ci tengo a un'ultima precisazione.
Roberto Resoli <roberto@resolutions.it> writes:
[...]
Quello che si può fare è già molto, soprattutto considerando che (da quello che capisco) questo risultato è stato ottenuto senza la benché minima collaborazione da parte della "mano pubblica".
Non direi, visto che, almeno per j4sign, è frutto del lavoro di un dipendente pubblico e il rilascio è stata una decisione politica.
Hai ragione, ho parlato a vanvera e me ne scuso con tutti i decisori politici che sostengono convintamente il lavoro sul e per il software libero e per una sana digitalizzazione della PA.
Ma figurati Giovanni, sono io che devo scusarmi, sapevo benissimo cosa intendevi (e hai ragione), ho maliziosamente travisato per sottolineare una cosa cui tengo molto.
Coraggio!
Grazie, serve a tutti noi. rob
participants (3)
-
Antonio Iacono -
Giovanni Biscuolo -
Roberto Resoli