Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
[OT] fascicolo sanitario e CIE
48 views
Skip to first unread message
Piviul
Feb 5, 2022, 1:40:04 PM2/5/22
to
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
(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
valerio
Feb 5, 2022, 2:40:02 PM2/5/22
to
Il 05/02/22 19:01, Piviul ha scritto:
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
Piviul
Feb 5, 2022, 3:30:03 PM2/5/22
to
Il 05/02/22 20:35, valerio ha scritto:
strano...
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...
invece a me dice "non presente"...
> 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...
strano...
Piviul
Davide Prina
Feb 6, 2022, 3:10:04 AM2/6/22
to
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?
> 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.
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
Antonio Iacono
Feb 6, 2022, 5:10:03 AM2/6/22
to
> 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...
>
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
Filippo Dal Bosco -
Feb 6, 2022, 5:30:03 AM2/6/22
to
Il giorno Sun, 6 Feb 2022 10:42:37 +0100
Antonio Iacono <ant...@piumarossa.it> 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
Antonio Iacono <ant...@piumarossa.it> 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
ministero interno ?
--
Filippo
Antonio Iacono
Feb 6, 2022, 5:50:02 AM2/6/22
to
> sostituisce -->> cieid.jar <<-- contenuto nei pacchetti CIE del
> ministero interno ?
>
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
Filippo Dal Bosco -
Feb 6, 2022, 6:00:03 AM2/6/22
to
Il giorno Sun, 6 Feb 2022 11:45:43 +0100
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
> > 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.
> > ministero interno ?
> >
> cieid.jar fa anche altro, ad esempio la firma.
>
> Comunque sì, l'intenzione è quella.
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
ilario....@e.email
Feb 6, 2022, 7:20:02 AM2/6/22
to
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.
Francesco Zanolin
Feb 6, 2022, 7:40:02 AM2/6/22
to
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).
ilario....@e.email
Feb 6, 2022, 7:50:02 AM2/6/22
to
valerio
Feb 6, 2022, 8:00:03 AM2/6/22
to
Il 06/02/22 11:56, Filippo Dal Bosco - ha scritto:
sto usando la 1.4.0... e funziona su debian testing aggiornata
valerio
Francesco Zanolin
Feb 6, 2022, 8:00:07 AM2/6/22
to
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.
Filippo Dal Bosco -
Feb 6, 2022, 8:20:03 AM2/6/22
to
Il giorno Sun, 6 Feb 2022 13:54:54 +0100
valerio <bardo_m...@fastwebnet.it> 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
valerio <bardo_m...@fastwebnet.it> ha scritto:
> ciao,
> sto usando la 1.4.0... e funziona su debian testing aggiornata
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
ilario....@e.email
Feb 6, 2022, 8:30:03 AM2/6/22
to
Il 6 febbraio 2022 13:50:55 CET, Francesco Zanolin <francesc...@ingv.it> 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.
>
Il fino li no era un termine temporale ma la differenza tra firma cie e digitale qualificata.
Ilario
Francesco Zanolin
Feb 6, 2022, 8:50:02 AM2/6/22
to
Ti metto direttamente un link e ti suggerisco il sito di agid per i dettagli.
ilario....@e.email
Feb 6, 2022, 9:00:02 AM2/6/22
to
Roberto Resoli
Feb 7, 2022, 6:10:03 AM2/7/22
to
Il 06/02/22 14:50, ilario....@e.email ha scritto:
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:
<Codice Fiscale>/<numero seriale dispositivo>.<un hash codificato base 64>
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
>
> Il 6 febbraio 2022 14:49:10 CET, Francesco Zanolin<francesc...@ingv.it> 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
> Il 6 febbraio 2022 14:49:10 CET, Francesco Zanolin<francesc...@ingv.it> 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
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:
<Codice Fiscale>/<numero seriale dispositivo>.<un hash codificato base 64>
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
Marco Bodrato
Feb 7, 2022, 6:50:02 AM2/7/22
to
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à
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/
Il Lun, 7 Febbraio 2022 12:03 pm, Roberto Resoli ha scritto:
> Il motivo per cui si usano coppie di chiavi diverse per identificazione
> 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
>
> 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.
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/
Roberto Resoli
Feb 7, 2022, 7:50:02 AM2/7/22
to
Il 07/02/22 12:49, Marco Bodrato ha scritto:
"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
> 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
>
> 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...
"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
Piviul
Feb 8, 2022, 2:00:02 AM2/8/22
to
Il 06/02/22 09:05, Davide Prina ha scritto:
> [...]
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
> [...]
> 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
Roberto Resoli
Feb 9, 2022, 5:50:03 AM2/9/22
to
Il 08/02/22 16:14, Diego Zuccato ha scritto:
> 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
> 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
>
>> 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".
> 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
Marco Bodrato
Feb 10, 2022, 2:10:03 PM2/10/22
to
Ciao,
Il 2022-02-09 11:40 Roberto Resoli ha scritto:
> Il 08/02/22 16:14, Diego Zuccato ha scritto:
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
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 :-)
>
> è 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.
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.
È 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
Davide Prina
Feb 11, 2022, 4:10:03 PM2/11/22
to
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.
> Poiché il testo cifrato può essere decifrato, a cifrati identici
> corrispondono necessariamente testi in chiaro identici.
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,
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.
* 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
Marco Bodrato
Feb 15, 2022, 10:20:03 AM2/15/22
to
Il 2022-02-15 14:57 Diego Zuccato ha scritto:
> 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"!
> 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
>>> Poiché il testo cifrato può essere decifrato, a cifrati identici
>>> corrispondono necessariamente testi in chiaro identici.
>> questa frase è così generica che secondo me è falsa.
> 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.
> 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
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"!
Davide Prina
Feb 20, 2022, 5:00:03 AM2/20/22
to
On 15/02/22 14:57, Diego Zuccato wrote:
> Il 11/02/2022 22:00, Davide Prina ha scritto:
> Il 11/02/2022 22:00, Davide Prina ha scritto:
>> 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 è
>> algoritmi diversi o... potrebbero ottenere lo stesso cifrato a partire
>> da testo in chiaro diverso.
> deterministica: dato [algoritmo,chiave,plaintext] viene sempre generato
> lo stesso cyphertext.
in realtà qui indicavo qualcosa di diverso, che secondo me potrebbe
essere possibile.
Prendo due algoritmi di cifratura diversi (o con chiavi diverse o...) su
due testi diversi e il cifrato risultato è lo stesso.
Alg1 cifra Testo1 e ottiene Cifrato
Alg2 cifra Testo2 e ottiene Cifrato
Secondo me, se si considerano solo gli algoritmi di cifratura che hanno
come risultato una lunghezza "fissa" pari al testo da cifrare e dato che
il numero di algoritmi è in teoria infinito, mentre il numero di
combinazioni possibili su una lunghezza del Testox a piacere è finito si
avranno per forza delle collisioni.
>> * 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
> centinaia) di cifrature a chiave pubblica al secondo.
dipende dall'algoritmo usato, dalla lunghezza della chiave, ... se
arrivi a cifrare tutto il traffico, secondo me, introduci una latenza
tale che il tuo dispositivo diventa inusabile.
> Il problema è che non necessariamente aumenti la sicurezza!
> Esempio classico: cifri ("firmi") con RSA2048 un messaggio, *un
> carattere alla volta*.
naturalmente facendo così elimini del tutto la sicurezza che stai
introducendo con la cifratura.
Se cifri tutto devi cifrare il flusso di dati o il file completo.
Quando scrivevo di cifrare messaggi corti intendevo cifrare l'hash al
posto del messaggio completo.
>> * 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
il problema è che l'utente (al cui gruppo appartengo anch'io), spesso
non è consapevole di quello che sta facendo e se non ha interesse
diretto, ha però un interesse indiretto, quando qualcuno di più esperto
effettua un attacco e ha successo.
> Il problema delle collisioni è che tutti i messaggi che entrano in
> collisione possono essere spacciati come autentici!
infatti.
>> * 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
questa cosa non la conosco. Mi dai qualche esempio?
>> (è 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)
>> * ...
> 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.").
alcuni punti:
1) a me sembra strano tutto questo. Prima di tutto di enigma sono state
create diverse versioni e poi l'uso che è stato fatto è stato modificato
nel tempo e anche a seconda della forza militare che lo utilizzava,
aggiungendo maggior difficoltà d'attacco[2].
Se fosse così com'è indicato nella pagina che hai indicato, come mai è
stato creato questo progetto?
http://www.enigmaathome.net/
per decifrare 3 messaggi il tempo impiegato è totalmente diverso da
quello indicato nell'articolo: "Project total CPU time equivalent to:
366959 years, 282 days, 16 hours of Athlon 3500+ running stock app."
2) TONY SALE[1] ha detto[2]:
* The total number of ways in which the Enigma machine can be configured
for any particular message is 150 million million million
* Its complexity's enormous. I mean, if I sent just one message on an
Enigma machine today it would still take a super Cray computer, the
fastest in the world, a year to go through searching for that one
message without supporting evidence as to what that message might have been.
ok era il 1999, ma da quell'anno all'attuale un PC normale non è
diventato più potente di un supercomputer dell'epoca.
Poi enigma ha dei "bug" che rendono, in taluni casi, la sua robustezza
minore.
3) oltre ad enigma, di cui io non avevo accennato nella mia risposta,
sono stati usati altri "algoritmi" di cifratura, ad esempio Lorenz[2][3]
4) purtroppo, probabilmente a causa di come funziona la mente umana nel
ricostruire i ricordi[4], in realtà io volevo riferirmi a quest'altro
caso di cifratura sempre nato negli anni della seconda guerra mondiale e
portato avanti fino al 1980: i messaggi cifrati spediti dalle spie russe
dagli USA alla Russia
ho trovato questo documentario[5] che ne parla:
revealing thousands of telegrams sent between Moscow and the Soviet
diplomats in the 1940s and '50s.
The Venona project lasted until 1980. Only those messages that reused
sheets of one-time pad could be read, less than one percent of the
total. No messages sent after 1948 could be broken;
C'è anche un documentario, sempre di PBS Nova, più recente, che parla in
modo più approfondito su questo argomento, dove dice esplicitamente che
stanno tentando di decifrare tali messaggi cifrati, ma per ora non sono
riusciti... purtroppo ora non riesco a trovarlo, nei quasi 1.000
documentari PBS Nova[6]
5) come dimostrano i documentari PBS Nova [2][5], la causa principale
del fallimento di un sistema complesso di cifratura è l'inadeguatezza
dell'utente che li utilizza.
Secondo me, più un sistema è complesso e meno l'utente è esperto e più
sono altre le probabilità di fallimento.
Un utente per poter usare qualcosa dovrebbe capire cosa sta usando, come
funziona e adottare conseguentemente un uso consapevole.
Purtroppo questa problematica è generica, ad esempio nell'incidente di
Three Mile Island chi gestiva la centrale nucleare non conosceva
l'argomento che gestiva e non era in grado di interpretare i segnali per
capire cosa stava accadendo (in pratica sapevano fare quasi solo cose
del tipo: si accende la luce A, allora premi il bottone 3). Un esperto
avrebbe risolto il problema in pochi secondi/minuti, mentre si è
rischiata una catastrofe per l'inadeguatezza del personale. E questa
problematica era relativa a tutte le centrali USA[7]
Per fortuna che attualmente le centrali nucleari sono sicure (The
investigation was conducted after unnamed individuals alleged that
"most, if not all," nuclear plants in the US have fake or faulty parts.
The inspector general's office uncovered problems with counterfeit parts
at a few different plants as part of its investigation...[8])
6) Dalla mia scarsa conoscenza della criptografia mi sono fatto l'idea
che il metodo di cifratura più sicuro, anche considerando l'aspetto
dell'utente "ignorante" in materia che lo utilizzerà è quello di usare
un metodo di cifratura basato su una "chiave" diversa per ogni messaggio
e la lista delle chiavi posseduto solo da chi deve comunicare/ricevere.
Tale lista non deve essere generata da una lista pseudocasuale. Questo,
secondo me, è valido e inattaccabile soprattutto per messaggi brevi,
come l'autenticazione. Le chiavi possono benissimo trovarsi su un foglio
di carta.
Un esempio è l'autenticazione a due fattori: Google ha dichiarato che
con l'autenticazione a due fattori gli attacchi che hanno successo sono
circa il 50% in meno rispetto ad un'autenticazione con sola password.
Come dire che aumentare la complessità per l'utente di 10-100 volte
diminuisce la probabilità di successo dell'attaccante del 50%. (non
trovo l'articolo)
>> 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.
> Solo tutti i crittoanalisti e buona parte dei matematici :)
tieni conto che alcuni modelli matematici sono proposti da enti come
l'NSA[9] o indicati come mandatori per l'uso...
Io penso che sia "semplice" verificare se il modello matematico sia
corretto, mentre sia molto più complesso individuare se esista un
ulteriore modello matematico che permetta di avere un passpartout,
backdoor al primo. E nell'articolo che avevo letto, da quello che mi
ricordo, si indicava che questo secondo passaggio non viene generalmente
fatto.
Ciao
Davide
[1] https://en.wikipedia.org/wiki/Tony_Sale
[2] Io mi sono basato su questo documentario PBS Nova che ripercorre la
storia delle comunicazioni cifrate durante la seconda guerra mondiale
(video e trascrizione del video):
https://archive.org/details/DecodingNaziSecrets
https://www.pbs.org/wgbh/nova/transcripts/2615decoding.html
[3] https://en.wikipedia.org/wiki/Lorenz_cipher
[4] https://www.pbs.org/wgbh/nova/video/memory-hackers/
il filmato dovrebbe essere questo su youtube:
https://www.youtube.com/watch?v=uO8pXtvxAA0
[5] https://archive.org/details/SecretsLiesAtomicSpies
https://www.pbs.org/wgbh/nova/transcripts/2904_venona.html
[6] https://en.wikipedia.org/wiki/List_of_Nova_episodes
[7] Sixty Minutes to Meltdown
il filmato dovrebbe essere questo su youtube:
https://www.youtube.com/watch?v=hm4tokGgnvg
[8]
https://news.slashdot.org/story/22/02/11/220246/us-nuclear-power-plants-contain-dangerous-counterfeit-parts-report-finds?utm_source=rss1.0mainlinkanon&utm_medium=feed
[9]The Spy Factory
il filmato dovrebbe essere questo su youtube:
https://www.youtube.com/watch?v=ZdPpdu8OGDQ
--
I didn't use Microsoft machines when I was in my operational phase,
because I couldn't trust them.
Not because I knew that there was a particular back door or anything
like that, but because I couldn't be sure.
Edward Snowden
0 new messages