Re: [OT] fascicolo sanitario e CIE
Il 2022-02-15 14:57 Diego Zuccato ha scritto: Il 11/02/2022 22:00, Davide Prina ha scritto: Poiché il testo cifrato può essere decifrato, a cifrati identici corrispondono necessariamente testi in chiaro identici. questa frase è così generica che secondo me è falsa. Sicuramente falsa. Controprova: basta scegliere un algoritmo di cifratura e provare a decodificare con chiavi diverse lo stesso Davvero qualcuno può pensare che quella frase intenda dire che per decifrare non serve conoscere né l'algoritmo né la chiave? Perché è tutto lo stesso? Se c'è UN MODO per decifrare testi cifrati, a cifrati identici con QUEL MODO, corrispondono testi in chiaro identici. La frase era stata scritta in risposta al paventato rischio che cifrare documenti lunghi (implicitamente inteso che lo si fa avendo scelto UN MODO per farlo, ovverosia un determinato algoritmo, una determinata chiave, più gli eventuali annessi e connessi) aumentasse la probabilità di collisione dei testi cifrati. E sottolineo pure che si parlava di probabilità. Oserei dire che ogni affermazione, spostata in contesti diversi diventa vera e falsa :-P Prendendo ad esempio il grande classico delle affermazioni ovvie, 2+2=4, vale ricordare che: in Z/3Z, 2+2=1 :-) ho letto qualche anno fa un articolo che parlava di cifratura e si indicava che la principale attività era quella di verificare che l'algoritmo fosse stato implementato correttamente e il suo uso fosse congruo. In modo che non vi siano bug o usi inappropriati. Verificare che l'implementazione sia priva di bug di solito è il primo passo. Discorso diverso per l'uso inappropriato: questo non te lo può garantire nessun algoritmo. Anche il più sicuro, se usato male, Ci possono essere procedure che vanno seguite... almeno all'interno del singolo software. Poi sull'uso dall'esterno, certo il controllo è impossibile. Però nessuno valuta se il bug è a livello matematico, cioè se vi è un "problema", magari intenzionale, che permetta di avere un passpartout, backdoor Anche in questa affermazione penso ci siano differenze possibili di contesto. Immagino che, in una ditta che produce semplicemente software, effettivamente nessuno controlli l'algoritmo "dal punto di vista matematico" e ci si concentri sulla correttezza della implementazione. Perché ci si affida ad algoritmi, analisi, indicazioni procedurali elaborate altrove. Chi invece studia non l'implementazione, ma lo sviluppo e la selezione degli algoritmi... li guarda eccome "a livello matematico"! Ĝis, m -- http://bodrato.it/papers/
Re: [OT] fascicolo sanitario e CIE
Il 11/02/2022 22:00, Davide Prina ha scritto:
Poiché il testo cifrato può essere decifrato, a cifrati identici
corrispondono necessariamente testi in chiaro identici.
questa frase è così generica che secondo me è falsa.
Sicuramente falsa. Controprova: basta scegliere un algoritmo di
cifratura e provare a decodificare con chiavi diverse lo stesso blocco.
Ovviamente si otterranno due "plaintext" diversi.
Due, secondo me, lo stesso algoritmo con lunghezza di chiave diversa o
algoritmi diversi o... potrebbero ottenere lo stesso cifrato a partire
da testo in chiaro diverso.
*Di solito* (ma non necessariamente) l'operazione di cifratura è
deterministica: dato [algoritmo,chiave,plaintext] viene sempre generato
lo stesso cyphertext. Questo è necessario, p.e., per testare che
l'algoritmo sia implementato correttamente (i test vector forniti con le
specifiche si basano su questo), oltre che per non consumare inutilmente
entropia. Nel caso sia richiesto un "blinding" del plaintext (fissata la
tripletta [A,K,T] devo ottenere testi cifrati ogni volta diversi) ci
sono diversi modi (banalmente -e in modo poco sicuro!- si potrebbe
mettere nel primo blocco il valore di un contatore, che verrà poi
incrementato), anche se generalmente aumentano la lunghezza del
cyphertext (che potrebbe anche essere un effetto voluto).
Un esempio banale è prendere un file a piacere e applicare diversi
algoritmi o stesso algoritmo con chiavi diverse o con lunghezze di
chiavi diverse o... per "decifrarlo". Penso che, bene o male, tutti
ritornino un file di output valido.
Generalmente si, soprattutto se usano la stessa dimensione del blocco.
Il fatto che poi il testo decifrato abbia o meno "senso" all'algoritmo
di cifratura non interessa. Potrebbe p.e. essere il cyphertext da
decodificare con un algoritmo diverso. 3DES funzionava proprio in questo
modo: in modalità EDE cifrava con K1, decifrava con K2 e tornava a
cifrare con K1. Non è ancora stato dimostrato che DES non sia un gruppo,
quindi *potrebbe* essere possibile che il risultato di 3DES equivalga
alla sola operazione di cifratura sotto una sola chiave ma è improbabile:
https://link.springer.com/article/10.1007/BF00206323
" Experiments show, with overwhelming confidence, that DES is not a group."
* visto che chi deve cifrare o decifrare è di solito un utente qualsiasi
con i suoi mezzi computazionali (normalmente tramite l'uso di una CPU)
deve essere permesso di eseguire l'operazione in tempi accettabili. Se
tutti avessero hardware "appropriato" non sarebbe un problema cifrare
messaggi lunghi
No, questo no. Oramai anche un telefonino può eseguire decine (se non
centinaia) di cifrature a chiave pubblica al secondo. Il problema è che
non necessariamente aumenti la sicurezza!
Esempio classico: cifri ("firmi") con RSA2048 un messaggio, *un
carattere alla volta*. Ti aspetti che sia sicuro? Ovviamente no: anche
se l'attaccante non può generare la firma di un carattere che non ha mai
visto, dato un numero sufficiente di firme potrebbe falsificare un
messaggio creato partendo da quelle. P.e. se hai firmato "CIAO"
ottenendo !"£$ l'attaccante può generare un messaggio "firmato" !£"$ che
viene verificato come CAIO :)
* l'uso di una funzione hash permette di minimizzare le collisioni,
soprattutto per messaggi "vicini" (o simili). Questo rende (o dovrebbe
rendere) più complesso riuscire a manipolare una parte del messaggio
facendo corrispondere la firma, anche se vengono scoperte falle nel
sistema di cifratura
All'utente non interessano le collisioni :)
Il problema delle collisioni è che tutti i messaggi che entrano in
collisione possono essere spacciati come autentici!
Esempio banale: se la funzione di hash ignora il carattere '0', il
messaggio "mi impegno a pagare 1€" e ha lo stesso hash di "mi impegno a
pagare 1000€"... Entrambi validi, ma di significato molto diverso :)
* l'uso di una funzione hash permette di usare un messaggio breve su cui
applicare la cifratura. Più il messaggio è lungo e più volte viene usata
la stessa chiave di cifratura e maggiori sono le probabilità di un
attaccante di individuare la "chiave" usata
Con algoritmi recenti questo non è un problema.
(è stato grazie a questa
tecnica che sono riusciti a decifrare messaggi tedeschi nella seconda
guerra mondiale, dove l'uso, inappropriato, della stessa "chiave" su
messaggi anche lunghi ha permesso di identificare la "chiave" usata. Per
messaggi corti, se non erro la maggior parte, invece anche ora stanno
tentando di decifrarli con la tecnologia attuale, ma non ci riescono)
* ...
Beh, non proprio:
http://practicalcryptography.com/cryptanalysis/breaking-machine-ciphers/cryptanalysis-enigma/
Con poco più di 18 miliardi di chiavi, un PC anche datato può fare brute
forcing in poco tempo ("In general it will take less than 30 seconds to
break short messages (50 characters), slightly longer for longer
messages.").
ho letto qualche anno fa un articolo che parlava di
Re: [OT] fascicolo sanitario e CIE
On 10/02/22 19:59, Marco Bodrato wrote: Poiché il testo cifrato può essere decifrato, a cifrati identici corrispondono necessariamente testi in chiaro identici. questa frase è così generica che secondo me è falsa. Uno non sono sicuro se tutti gli algoritmi di cifratura assicurino questa univocità. Secondo me l'assicurazione è solo di poter ottenere il messaggio di partenza. Due, secondo me, lo stesso algoritmo con lunghezza di chiave diversa o algoritmi diversi o... potrebbero ottenere lo stesso cifrato a partire da testo in chiaro diverso. Un esempio banale è prendere un file a piacere e applicare diversi algoritmi o stesso algoritmo con chiavi diverse o con lunghezze di chiavi diverse o... per "decifrarlo". Penso che, bene o male, tutti ritornino un file di output valido. Come diceva il mio prof di metodi: non esiste un programma che dia sempre la risposta sbagliata. Dipende da chi valuta tale risposta. Quindi i file di output potrebbero essere per molti un insieme di stringhe casuali, ma per alcuni potrebbero aver significato. Poiché però il documento da firmare può tranquillamente "pesare" centinaia di megabyte, OT: io non ho mai capito come si possa indicare come "peso" qualcosa che indica un numero di elementi consecutivi. Dunque si firma sempre un'impronta del documento. Impronta ottenuta con una funzione "hash" che ha lo scopo non tanto di diminuire la probabilità (statistica) di una collisione, quanto la realizzabilità (computazionale) di un falso da parte di un avversario. secondo me i motivi sono molteplici: * visto che chi deve cifrare o decifrare è di solito un utente qualsiasi con i suoi mezzi computazionali (normalmente tramite l'uso di una CPU) deve essere permesso di eseguire l'operazione in tempi accettabili. Se tutti avessero hardware "appropriato" non sarebbe un problema cifrare messaggi lunghi * l'uso di una funzione hash permette di minimizzare le collisioni, soprattutto per messaggi "vicini" (o simili). Questo rende (o dovrebbe rendere) più complesso riuscire a manipolare una parte del messaggio facendo corrispondere la firma, anche se vengono scoperte falle nel sistema di cifratura * l'uso di una funzione hash permette di usare un messaggio breve su cui applicare la cifratura. Più il messaggio è lungo e più volte viene usata la stessa chiave di cifratura e maggiori sono le probabilità di un attaccante di individuare la "chiave" usata (è stato grazie a questa tecnica che sono riusciti a decifrare messaggi tedeschi nella seconda guerra mondiale, dove l'uso, inappropriato, della stessa "chiave" su messaggi anche lunghi ha permesso di identificare la "chiave" usata. Per messaggi corti, se non erro la maggior parte, invece anche ora stanno tentando di decifrarli con la tecnologia attuale, ma non ci riescono) * ... ho letto qualche anno fa un articolo che parlava di cifratura e si indicava che la principale attività era quella di verificare che l'algoritmo fosse stato implementato correttamente e il suo uso fosse congruo. In modo che non vi siano bug o usi inappropriati. Però nessuno valuta se il bug è a livello matematico, cioè se vi è un "problema", magari intenzionale, che permetta di avere un passpartout, backdoor o come la si voglia chiamare o magari soltanto un metodo per diminuire la complessità dell'attacco di alcuni fattori. Ciao Davide -- What happened in 2013 couldn't have happened without free software (He credited free software for his ability to help disclose the U.S. government's far-reaching surveillance projects). Edward Snowden
Re: [OT] fascicolo sanitario e CIE
Ciao, Il 2022-02-09 11:40 Roberto Resoli ha scritto: Il 08/02/22 16:14, Diego Zuccato ha scritto: intero documento era stato processato dalla card, non solo un hash è una cosa altamente sconsigliabile, perché esporrebbe la firma ad attacchi. La cifratura con chiave privata non protegge di per sé da possibili collisioni (testo cifrato identico a partire da testi in chiaro diversi). L'hashing diminuisce enormemente la probabilità di collisioni. Questa non l'ho capita :-) Poiché il testo cifrato può essere decifrato, a cifrati identici corrispondono necessariamente testi in chiaro identici. Se il testo da firmare stesse tutto in un blocco "cifrabile" dal sistema di firma, in alcuni scenari potrebbe essere anche una buona idea non usare "hash". Poiché però il documento da firmare può tranquillamente "pesare" centinaia di megabyte, emergerebbero problemi gravi di efficienza e anche di protocollo (come legare i diversi blocchi firmati per evitare che vengano usati, tipo puzzle, per generare messaggi diversi?). Dunque si firma sempre un'impronta del documento. Impronta ottenuta con una funzione "hash" che ha lo scopo non tanto di diminuire la probabilità (statistica) di una collisione, quanto la realizzabilità (computazionale) di un falso da parte di un avversario. Non sarebbe stato tutto più chiaro? :) Tipici standard da comitato... Beh, basta intendersi sul significato dei termini. Su questo, invece, concordo in pieno! È necessario imparare, prima o dopo, che i termini tecnici non corrispondono quasi mai al linguaggio corrente. Altrimenti si finisce per pensare che la "buona scuola" sia proprio una cosa buona, un "giusto processo" sia sempre una cosa giusta o addirittura che "l'equa remunerazione del capitale" sia davvero una cosa equa! Certo per noi matematici è più semplice, visto che per noi un "toro" è quello che i comuni mortali chiamano con la parola "anello"; con la quale noi matematici indichiamo strutture, alle quali i comuni mortali normalmente non pensano e che quindi non chiamano :-) Ĝis, m
Re: [OT] fascicolo sanitario e CIE
Il 08/02/22 16:14, Diego Zuccato ha scritto: Il 07/02/2022 12:03, Roberto Resoli ha scritto: Tecnicamente, i certificati per firma qualificata si distinguono per l'attributo keyUsage con unico flag attivo "nonRepudiation" e marcato critico. I certificati per identificazione (quelli ospitati in ogni caso su CIE e CNS) hanno keyUsage con flag "digitalSignature", e nessun flag "nonRepudiation". Certo che se avessero chiamato i flag col nome giusto si sarebbero evitati tanti problemi: "signature" invece di "nonRepudiation" (con "nonRepudiation" che poteva significare altro, p.e. che l'intero documento era stato processato dalla card, non solo un hash) e "authentication" invece di "digitalSignature". In realtà "non repudiation" corrisponde esattamente al nostro intento principale quando ordinariamente quando facciamo firmare un documento: impegnare la propria identità in modo non disconoscibile. Le tre proprietà fondamentali di una firma (digitale o meno): 1) Identificazione 2) Integrità 3) Non disconoscimento "digital signature" è un concetto molto più ampio, indica (nel contesto della crittografia a chiave pubblica) il processo di cifratura di una certa sequenza di bit con una chiave privata. riguardo a: intero documento era stato processato dalla card, non solo un hash è una cosa altamente sconsigliabile, perché esporrebbe la firma ad attacchi. La cifratura con chiave privata non protegge di per sé da possibili collisioni (testo cifrato identico a partire da testi in chiaro diversi). L'hashing diminuisce enormemente la probabilità di collisioni. Non sarebbe stato tutto più chiaro? :) Tipici standard da comitato... Beh, basta intendersi sul significato dei termini. rob
Re: [OT] fascicolo sanitario e CIE
Il 07/02/2022 12:03, Roberto Resoli ha scritto: Tecnicamente, i certificati per firma qualificata si distinguono per l'attributo keyUsage con unico flag attivo "nonRepudiation" e marcato critico. I certificati per identificazione (quelli ospitati in ogni caso su CIE e CNS) hanno keyUsage con flag "digitalSignature", e nessun flag "nonRepudiation". Certo che se avessero chiamato i flag col nome giusto si sarebbero evitati tanti problemi: "signature" invece di "nonRepudiation" (con "nonRepudiation" che poteva significare altro, p.e. che l'intero documento era stato processato dalla card, non solo un hash) e "authentication" invece di "digitalSignature". Non sarebbe stato tutto più chiaro? :) Tipici standard da comitato... -- Diego Zuccato DIFA - Dip. di Fisica e Astronomia Servizi Informatici Alma Mater Studiorum - Università di Bologna V.le Berti-Pichat 6/2 - 40127 Bologna - Italy tel.: +39 051 20 95786
Re: [OT] fascicolo sanitario e CIE
Il 06/02/22 09:05, Davide Prina ha scritto: [...] Io non ho ancora la CIE quindi non posso aiutarti ulteriormente. Grazie Davide e a tutti quanti, ho risolto... mi vergogno un po' ma il problema era molto semplice, non mi ero messo gli occhiali e credevo di avere in mano la CIE invece era la tessera sanitaria Un ringraziamento particolare ad Antonio che sta cercando di liberare il software della firma da java e degli spunti forntiti sull'utilizzo di fime elettroniche più deboli ma in effetti utili in moltissimi casi. Buona giornata a tutti quanti! Piviul
Re: [OT] fascicolo sanitario e CIE
Il 07/02/22 12:49, Marco Bodrato ha scritto: Ciao, Il Lun, 7 Febbraio 2022 12:03 pm, Roberto Resoli ha scritto: Il motivo per cui si usano coppie di chiavi diverse per identificazione e firma digitale è che nel primo caso vengono firmate quantità randomiche generato nell'ambito di un processo informatico (es: TLS). Mentre nel caso della firma si firmano quantità (documenti con valore legale) su cui il firmatario impegna la propria identità accettando il non disconoscimento (il "non repudiation" del campo keyUsage, appunto). Imho l'uso di coppie di chiavi pensate per identificazione come chiavi di firma digitale è del tutto improprio. Concordo. Usare la stessa coppia di chiavi sia per firmare che per identificarsi è decisamente pericoloso. Nel firmare un documento, di fatto praticamente sempre si firma l'impronta (Hash) del documento stesso. Con il linguaggio usato da Roberto, questa impronta è apparentemente una "quantità randomica". Semplificando molto, durante il processo informatico (es:TLS) di identificazione, l'utente di fatto si trova a firmare la "quantità randomica" inviata dall'interlocutore presso il quale si sta identificando, senza (alcuna possibilità di) verificarne il contenuto. Che succede se l'interlocutore, invece di mandarci una genuina "quantità randomica" ci manda l'impronta di un documento? Usando la stessa chiave per firmare e per identificarsi, si concederebbe la possibilità, a chi controlla i processi di identificazione, di ottenere firme su documenti arbitrari... Cfr. ad esempio "X.509 V.3 Certificate Profile for Certificates Issued to Natural Persons" https://www.etsi.org/deliver/etsi_ts/102200_102299/102280/01.01.01_60/ts_102280v010101p.pdf: "Security note: Combining the non-repudiation bit (bit 1) in the keyUsage certificate extension with other keyUsage bits may have security implications depending on the security environment in which the certificate is to be used. If the subject's environment can be fully controlled and trusted, then there are no specific security implications. For example, in cases where the subject is fully confident about exactly which data is signed or cases where the subject is fully confident about the security characteristics of the authentication protocol being used. If the subject's environment is not fully controlled or not fully trusted, then unintentional signing of commitments is possible. Examples include the use of badly formed authentication exchanges and the use of a rogue software component. If untrusted environments are used by a subject, these security implications can be limited through use of the following measures: - to not combine non-repudiation key usage setting in certificates with any other key usage setting and to use the corresponding private key only with this certificate; - to limit the use of private keys associated with certificates that have the non-repudiation key usage bit set, to environments which are considered adequately controlled and trustworthy" rob
Re: [OT] fascicolo sanitario e CIE
Ciao, Il Lun, 7 Febbraio 2022 12:03 pm, Roberto Resoli ha scritto: > Il motivo per cui si usano coppie di chiavi diverse per identificazione > e firma digitale è che nel primo caso vengono firmate quantità > randomiche generato nell'ambito di un processo informatico (es: TLS). > > Mentre nel caso della firma si firmano quantità (documenti con valore > legale) su cui il firmatario impegna la propria identità accettando il > non disconoscimento (il "non repudiation" del campo keyUsage, appunto). > > Imho l'uso di coppie di chiavi pensate per identificazione come chiavi > di firma digitale è del tutto improprio. Concordo. Usare la stessa coppia di chiavi sia per firmare che per identificarsi è decisamente pericoloso. Nel firmare un documento, di fatto praticamente sempre si firma l'impronta (Hash) del documento stesso. Con il linguaggio usato da Roberto, questa impronta è apparentemente una "quantità randomica". Semplificando molto, durante il processo informatico (es:TLS) di identificazione, l'utente di fatto si trova a firmare la "quantità randomica" inviata dall'interlocutore presso il quale si sta identificando, senza (alcuna possibilità di) verificarne il contenuto. Che succede se l'interlocutore, invece di mandarci una genuina "quantità randomica" ci manda l'impronta di un documento? Usando la stessa chiave per firmare e per identificarsi, si concederebbe la possibilità, a chi controlla i processi di identificazione, di ottenere firme su documenti arbitrari... Altre cose sono la firma con SPID, la firma remota... insomma quei sistemi di firma che partono da un processo di identificazione, che possono avere altre criticità, ma comunque non usano la stessa chiave. Ĝis, m -- http://bodrato.it/papers/
Re: [OT] fascicolo sanitario e CIE
Il 06/02/22 14:50, ilario.quinson@e.email ha scritto: Il 6 febbraio 2022 14:49:10 CET, Francesco Zanolin ha scritto: Ti metto direttamente un link e ti suggerisco il sito di agid per i dettagli. https://www.aruba.it/magazine/firma-digitale/firma-elettronica-avanzata-e-firma-elettronica-qualificata-l-importanza-di-conoscere-le-differenze.aspx Tengo a precisare che quanto scritto nella pagina in questione alla voce: "Varianti della FEA e precisazioni importanti" Non è interamente corretto è mancano riferimenti alle fonti. Innanzitutto: Le firme apposte con CNS e Tessera Sanitaria possono essere qualificate (FEQ o QES secondo l'acronimo EIdAS), se sono stati utilizzati certificati qualificati (cioè emessi da CA incluse nell'elenco europeo come emittenti di certificati QES). Una delle ragioni d'essere della CNS era appunto essere equivalente alla CIE per scopi di identificazione digitale, e ospitare ulteriori servizi (quale la firma, appunto). Le Tessere Sanitarie della regione Lombardia potevano (non so se sia ancora vero) ospitare opzionalmente anche i certificati di firma. Tecnicamente, i certificati per firma qualificata si distinguono per l'attributo keyUsage con unico flag attivo "nonRepudiation" e marcato critico. I certificati per identificazione (quelli ospitati in ogni caso su CIE e CNS) hanno keyUsage con flag "digitalSignature", e nessun flag "nonRepudiation". Sono facilmente distinguibili perchè nell'attributo "Subject" il campo Common Name (CN) è del tipo: /. e non riporta Nome e Cognome come nel caso dei certificati qualificati. --- Il motivo per cui si usano coppie di chiavi diverse per identificazione e firma digitale è che mnel primo caso vengono firmate quantità randomiche generato nell'ambito di un processo informatico (es: TLS). Mentre nel caso della firma si firmano quantità (documenti con valore legale) su cui il firmatario impegna la propria identità accettando il non disconoscimento (il "non repudiation" del campo keyUsage, appunto). Imho l'uso di coppie di chiavi pensate per identificazione come chiavi di firma digitale è del tutto improprio. rob
Re: [OT] fascicolo sanitario e CIE
Il 6 febbraio 2022 14:49:10 CET, Francesco Zanolin ha scritto: >Ti metto direttamente un link e ti suggerisco il sito di agid per i >dettagli. > >https://www.aruba.it/magazine/firma-digitale/firma-elettronica-avanzata-e-firma-elettronica-qualificata-l-importanza-di-conoscere-le-differenze.aspx Grazie. Ilario -- Inviato da /e/ Mail.
Re: [OT] fascicolo sanitario e CIE
Ti metto direttamente un link e ti suggerisco il sito di agid per i dettagli. https://www.aruba.it/magazine/firma-digitale/firma-elettronica-avanzata-e-firma-elettronica-qualificata-l-importanza-di-conoscere-le-differenze.aspx
Re: [OT] fascicolo sanitario e CIE
Il 6 febbraio 2022 13:50:55 CET, Francesco Zanolin ha scritto: >Scade il certificato firma, non puoi usarlo dopo quella data, non la >firma >apposta. > >I documenti firmati valgo sempre, ma se apponi una firma con un >certificato >già scaduto o sospeso questa risulta non valida. >La cosa è per evidenti motivi di sicurezza, obbligando ad un periodico >controllo delle caratteristiche della persona che esegue la firma o nel >caso di furto del certificato. > Scusa mi sono espresso male. Il fino li no era un termine temporale ma la differenza tra firma cie e digitale qualificata. Ilario >Il dom 6 feb 2022, 13:43 ha scritto: > >> >> >> Il 6 febbraio 2022 13:34:48 CET, Francesco Zanolin < >> francesco.zano...@ingv.it> ha scritto: >> >A firmare digitalmente tutti quei documenti che non richiedono una >> >firma >> >qualificata. >> > >> >Nel nostro ente ad esempio lo stiamo adottando per i verbali e le >> >procedure >> >interne, così da non dover consegnare a tutti i dipendenti la firma >> >digitale qualificata (previsto anche questo in futuro, ma in attesa >di >> >eventuali convenzioni che ne abbattano il costo). >> >> Ma che senso ha avere una firma che vale fino li...? >> >> Ilario >> -- Inviato da /e/ Mail. >> >> -- Inviato da /e/ Mail.
Re: [OT] fascicolo sanitario e CIE
Il giorno Sun, 6 Feb 2022 13:54:54 +0100 valerio ha scritto: > ciao, > sto usando la 1.4.0... e funziona su debian testing aggiornata misteri informatica: aggiornato debian 12 Mate installata cie 1.4.0 Riconosce la CIE precedentemente associata con cie 1.3.1 Eliminata l' associazione Provo associazione con cie 1.4.0. Metto pin e sparisce tutto. Reinstallo cie 1.3.1 e tutto funziona. -- Filippo
Re: [OT] fascicolo sanitario e CIE
Il 06/02/22 11:56, Filippo Dal Bosco - ha scritto: Il giorno Sun, 6 Feb 2022 11:45:43 +0100 Antonio Iacono ha scritto: sostituisce -->> cieid.jar <<-- contenuto nei pacchetti CIE del ministero interno ? cieid.jar fa anche altro, ad esempio la firma. Comunque sì, l'intenzione è quella. bene. Perchè io sono riuscito ad installare cie 1.3.1 su ubuntu 21.04. 21.10 da un po' anche su ubuntu 22.04, su debian 11 e debian 12 Ma cie 1.40. e cie 1.4.1 su nessuno di questi. Sembrerebbe per conflitti con java ciao, sto usando la 1.4.0... e funziona su debian testing aggiornata valerio
Re: [OT] fascicolo sanitario e CIE
Scade il certificato firma, non puoi usarlo dopo quella data, non la firma apposta. I documenti firmati valgo sempre, ma se apponi una firma con un certificato già scaduto o sospeso questa risulta non valida. La cosa è per evidenti motivi di sicurezza, obbligando ad un periodico controllo delle caratteristiche della persona che esegue la firma o nel caso di furto del certificato. Il dom 6 feb 2022, 13:43 ha scritto: > > > Il 6 febbraio 2022 13:34:48 CET, Francesco Zanolin < > francesco.zano...@ingv.it> ha scritto: > >A firmare digitalmente tutti quei documenti che non richiedono una > >firma > >qualificata. > > > >Nel nostro ente ad esempio lo stiamo adottando per i verbali e le > >procedure > >interne, così da non dover consegnare a tutti i dipendenti la firma > >digitale qualificata (previsto anche questo in futuro, ma in attesa di > >eventuali convenzioni che ne abbattano il costo). > > Ma che senso ha avere una firma che vale fino li...? > > Ilario > -- Inviato da /e/ Mail. > >
Re: [OT] fascicolo sanitario e CIE
Il 6 febbraio 2022 13:34:48 CET, Francesco Zanolin ha scritto: >A firmare digitalmente tutti quei documenti che non richiedono una >firma >qualificata. > >Nel nostro ente ad esempio lo stiamo adottando per i verbali e le >procedure >interne, così da non dover consegnare a tutti i dipendenti la firma >digitale qualificata (previsto anche questo in futuro, ma in attesa di >eventuali convenzioni che ne abbattano il costo). Ma che senso ha avere una firma che vale fino li...? Ilario -- Inviato da /e/ Mail.
Re: [OT] fascicolo sanitario e CIE
A firmare digitalmente tutti quei documenti che non richiedono una firma qualificata. Nel nostro ente ad esempio lo stiamo adottando per i verbali e le procedure interne, così da non dover consegnare a tutti i dipendenti la firma digitale qualificata (previsto anche questo in futuro, ma in attesa di eventuali convenzioni che ne abbattano il costo).
Re: [OT] fascicolo sanitario e CIE
Il 6 febbraio 2022 11:56:24 CET, Filippo Dal Bosco - ha scritto: >Il giorno Sun, 6 Feb 2022 11:45:43 +0100 >Antonio Iacono ha scritto: > >> > sostituisce -->> cieid.jar <<-- contenuto nei pacchetti CIE del >> > ministero interno ? >> > >> cieid.jar fa anche altro, ad esempio la firma. >> >> Comunque sì, l'intenzione è quella. > >bene. > > Perchè io sono riuscito ad installare cie 1.3.1 su ubuntu >21.04. 21.10 da un po' anche su ubuntu 22.04, su debian 11 e >debian 12 > >Ma cie 1.40. e cie 1.4.1 su nessuno di questi. Sembrerebbe per >conflitti con java Ciao, complimenti a chi si opera per la buona causa di arrivare dove le istituzioni non arrivano. Detto questo, a cosa serve la possibilità di firmare i documenti con la CIE? Ilario -- Inviato da /e/ Mail.
Re: [OT] fascicolo sanitario e CIE
Il giorno Sun, 6 Feb 2022 11:45:43 +0100 Antonio Iacono ha scritto: > > sostituisce -->> cieid.jar <<-- contenuto nei pacchetti CIE del > > ministero interno ? > > > cieid.jar fa anche altro, ad esempio la firma. > > Comunque sì, l'intenzione è quella. bene. Perchè io sono riuscito ad installare cie 1.3.1 su ubuntu 21.04. 21.10 da un po' anche su ubuntu 22.04, su debian 11 e debian 12 Ma cie 1.40. e cie 1.4.1 su nessuno di questi. Sembrerebbe per conflitti con java -- Filippo
Re: [OT] fascicolo sanitario e CIE
sostituisce -->> cieid.jar <<-- contenuto nei pacchetti CIE del ministero interno ? cieid.jar fa anche altro, ad esempio la firma. Comunque sì, l'intenzione è quella. Avendo a disposizione la libreria pkcs11 il resto può essere gestito con openssl, opensc, ecc. L'unica cosa che questi tool non possono fare è l'abilitazione, per questo ho scritto, sulla base dell'originario AbilitaCIE.cpp il tool a linea di comando. Antonio
Re: [OT] fascicolo sanitario e CIE
Il giorno Sun, 6 Feb 2022 10:42:37 +0100 Antonio Iacono ha scritto: > Ne approfitto per segnalare che sto lavorando ad un fork [1] del sw > originario che ESCLUDE java. Ovvero, la CIE viene abilitata a linea > di comando. L'utilizzo della libreria avviene poi nel modo classico, > ovvero caricando in impostazioni la libcie-pkcs11.so sostituisce -->> cieid.jar <<-- contenuto nei pacchetti CIE del ministero interno ? -- Filippo
Re: [OT] fascicolo sanitario e CIE
capita anche a me, di solito vado in (uso firefox) impostazioni, poi privacy e sicurezza, dispositivi di sicurezza e nel dispositivo di sicurezza (nel mio caso BIT4ID), click su accedi, mi dice connesso e funziona... Confermo quanto detto da Valerio, a volte si "disconnette" e quindi bisogna eseguire questa procedura, inserire il mezzo PIN e connettersi, a quel punto, se non c'è un problema remoto, si potrà accedere al servizio. Ne approfitto per segnalare che sto lavorando ad un fork [1] del sw originario che ESCLUDE java. Ovvero, la CIE viene abilitata a linea di comando. L'utilizzo della libreria avviene poi nel modo classico, ovvero caricando in impostazioni la libcie-pkcs11.so Grazie, Antonio [1] https://github.com/opensignature/cie-pkcs11
Re: [OT] fascicolo sanitario e CIE
On 05/02/22 19:01, Piviul wrote: Ciao a tutti, da oggi non riesco più a loggarmi sul fasciolo elettronico (dell'emilia romagna) usando la CIE come metodo di autenticazione. Tutto sembra andare bene tranne che quando seleziono di proseguire con il computer mi dice che qualcosa è andato storto. ma hai provato a connetterti ad altro? Es: INPS apri un terminale e verifica i log generati $ journalctl -f metti il lettore metti la carta prova ad accedere ad un sito che richiede l'autenticazione Io con la CNS se non funziona faccio le seguenti due cose (spesso ne basta una): * riavvio il servizio (non so per la CIE se la procedura è la stessa) # systemctl restart pcscd pcscd.socket * accedo prima ad altro servizio (es: INPS) e poi esco ed accedo a quello che mi dava problemi. Io non ho ancora la CIE quindi non posso aiutarti ulteriormente. Ciao Davide -- Strumenti per l'ufficio: https://www.libreoffice.org GNU/Linux User: 302090: http://counter.li.org Non autorizzo la memorizzazione del mio indirizzo su outlook
Re: [OT] fascicolo sanitario e CIE
Il 05/02/22 20:35, valerio ha scritto: ciao, capita anche a me, di solito vado in (uso firefox) impostazioni, poi privacy e sicurezza, dispositivi di sicurezza e nel dispositivo di sicurezza (nel mio caso BIT4ID), click su accedi, mi dice connesso e funziona... invece a me dice "non presente"... strano... Piviul
Re: [OT] fascicolo sanitario e CIE
Il 05/02/22 19:01, Piviul ha scritto: Ciao a tutti, da oggi non riesco più a loggarmi sul fasciolo elettronico (dell'emilia romagna) usando la CIE come metodo di autenticazione. Tutto sembra andare bene tranne che quando seleziono di proseguire con il computer mi dice che qualcosa è andato storto. È un problema mio oppure qualcuno riscontra lo stesso problema? Grazie Piviul ciao, capita anche a me, di solito vado in (uso firefox) impostazioni, poi privacy e sicurezza, dispositivi di sicurezza e nel dispositivo di sicurezza (nel mio caso BIT4ID), click su accedi, mi dice connesso e funziona... valerio
[OT] fascicolo sanitario e CIE
Ciao a tutti, da oggi non riesco più a loggarmi sul fasciolo elettronico (dell'emilia romagna) usando la CIE come metodo di autenticazione. Tutto sembra andare bene tranne che quando seleziono di proseguire con il computer mi dice che qualcosa è andato storto. È un problema mio oppure qualcuno riscontra lo stesso problema? Grazie Piviul
