Sulla sicurezza del voto elettronico: Come sono riuscito a votare due volte su Rousseau
In merito al tema sicurezza del voto elettronico e relative garanzie per la democrazia segnalo l'inchiesta pubblicata oggi: "Come sono riuscito a votare due volte su Rousseau" https://www.wired.it/attualita/politica/2020/08/19/rousseau-voto-piattaforma... E successiva e immediata risposta intimidatoria della Associazione Rousseau: https://www.ilblogdellestelle.it/2020/08/chi-truffa-rousseau-viene-denunciat... Fabio
Ciao Fabio, una curiosità: come mai hai (avete, hanno?) deciso di arrivare fino al voto e non segnalare prima il baco a quelli di Rousseau? "Fabio Pietrosanti (naif)" <lists@infosecurity.ch> writes:
In merito al tema sicurezza del voto elettronico e relative garanzie per la democrazia segnalo l'inchiesta pubblicata oggi:
"Come sono riuscito a votare due volte su Rousseau" https://www.wired.it/attualita/politica/2020/08/19/rousseau-voto-piattaforma...
Interessante grazie! Nel seguito dirò cose che sicuramente tu Fabio sai meglio di me, ma forse aiutano chi ha meno conoscenze specifiche in merito. In effetti quello dell'identità digitale (e gli speculari furto o falsificazione di identità) è un serio problema: ognuno cerca di inventarsi propri sistemi e a volte (spesso?) se ne vedono delle belle, alcune davvero grossolane tipo questa. Giusto per fare un sesempio di quanto sia complesso il problema, il MEF ha stabilito un sistema pubblico di prevenzione abbastanza articolato: http://www.dt.mef.gov.it/it/attivita_istituzionali/antifrode_mezzi_pagamento... Probabilmente Rousseau dovrebbe passare a SPID… ah no: «SPID e furto di identità: una storia già vista e una lezione ignorata» [1] Per non parlare poi delle informazioni personali associate alle nostre identità, spesso *inglobate* nel sistema di identità digitale o analogico che sia. Per non parlare dell'obbligatorietà o meno di un documento di identità analogico [2], che pone non pochi problemi all'identificazione di un sistema globale di gestione interoperabile della *certificazione* dell'identità digitale… che non a caso oggi è /de-facto/ privatizzato, con alcuni molossi big tech che la fanno da padroni (nel senso che proprio *posseggono* l'anagrafica del sistema di identità digitale), con il pubblico (tipo SPID) che "rincorre" a diversi km di distanza, in termini di utenti gestiti e interoperabilità coi servizi. Probabilmente possiamo fare tecnologicamente di meglio, per esempio come stanno provando a fare con re:claimID https://reclaim.gnunet.org/motivation/ [...] Saluti, Giovanni [1] https://www.key4biz.it/spid-e-furto-di-identita-una-storia-gia-vista-e-una-l... [2] https://it.wikipedia.org/wiki/Carta_d%27identit%C3%A0 -- Giovanni Biscuolo
On 21/08/2020 11:03, Giovanni Biscuolo wrote:
Probabilmente Rousseau dovrebbe passare a SPID… ah no: «SPID e furto di identità: una storia già vista e una lezione ignorata» [1]
posso assicurare che e' piu' facile rubare una identita' analogica che non ingannare il riconoscimento SPID. altro tema e' se uno da' a terzi i propri documenti...
Sarò forse ingenuo, ma a tutt'oggi non capisco perché i comuni non firmino e pubblichino la chiave pubblica PGP dei propri cittadini, magari dietro un piccolo pagamento. Costituirebbe una infrastruttura semplice, economica ed estremamente potente, sia per la comunicazione sicura fra cittadini, sia con la PA (invece della ridicola PEC), sia fra le aziende. Ed educherebne la popolazione all'uso di sistemi criptografici seri e distribuiti. Immaginate quante applicazioni si potrebbero costruire su un web of trust così diffuso. Giacomo
Giacomo Tesio <giacomo@tesio.it> writes:
Sarò forse ingenuo, ma a tutt'oggi non capisco perché i comuni non firmino e pubblichino la chiave pubblica PGP dei propri cittadini, magari dietro un piccolo pagamento.
Mah, forse siamo io e te che la facciamo troppo semplice? :-O In effetti è un pochino complessa [1]… però a me PARE che ci sia qualcuno che la vuole rendere inutilmente complicata.
Costituirebbe una infrastruttura semplice, economica ed estremamente potente, sia per la comunicazione sicura fra cittadini, sia con la PA (invece della ridicola PEC), sia fra le aziende.
Già, il FAMIGERRIMO accreditamento CNIPA, il capitale versato di almeno un milione di EUR... paura! Pensare che le email "normali" possono essere legalmente valide (meglio quando firmate PGP [2]) no eh? (sto volutamente semplificando [3])
Ed educherebne la popolazione all'uso di sistemi criptografici seri e distribuiti.
Immaginate quante applicazioni si potrebbero costruire su un web of trust così diffuso.
Bello! Ciao, Giovanni [...] [1] in particolare SE vogliamo considerare gli aspetti legati all'accesso ai metadati delle nostre identità digitali [2] aggià, e la marca temporale?!? [3] https://www.piana.eu/prova_email/ -- Giovanni Biscuolo
Seguo con interesse questo dibattito che si ripropone ciclicamente. La Pec nasce fondamentalmente per rendere opponibile al terzo una comunicazione inviata ad un certo indirizzo analogamente a quanto avviene con la raccomandata cartacea. Nel modello alternativo proposto, se disconosco di aver ricevuto una certa email da tizio, quali strumenti, legalmente vincolanti, ha tizio per dimostrare in giudizio in modo semplice ed immaginato che ho invece ricevuto quella comunicazione (anche se non l’ho letta)? ----- Blog: www.marcoscialdone.it Twitter: @marcoscialdone LinkedIn: www.linkedin.com/in/marcoscialdone
Il giorno 21 ago 2020, alle ore 20:08, Giovanni Biscuolo <giovanni@biscuolo.net> ha scritto:
Giacomo Tesio <giacomo@tesio.it> writes:
Sarò forse ingenuo, ma a tutt'oggi non capisco perché i comuni non firmino e pubblichino la chiave pubblica PGP dei propri cittadini, magari dietro un piccolo pagamento.
Mah, forse siamo io e te che la facciamo troppo semplice? :-O
In effetti è un pochino complessa [1]… però a me PARE che ci sia qualcuno che la vuole rendere inutilmente complicata.
Costituirebbe una infrastruttura semplice, economica ed estremamente potente, sia per la comunicazione sicura fra cittadini, sia con la PA (invece della ridicola PEC), sia fra le aziende.
Già, il FAMIGERRIMO accreditamento CNIPA, il capitale versato di almeno un milione di EUR... paura!
Pensare che le email "normali" possono essere legalmente valide (meglio quando firmate PGP [2]) no eh? (sto volutamente semplificando [3])
Ed educherebne la popolazione all'uso di sistemi criptografici seri e distribuiti.
Immaginate quante applicazioni si potrebbero costruire su un web of trust così diffuso.
Bello!
Ciao, Giovanni
[...]
[1] in particolare SE vogliamo considerare gli aspetti legati all'accesso ai metadati delle nostre identità digitali
[2] aggià, e la marca temporale?!?
[3] https://www.piana.eu/prova_email/
-- Giovanni Biscuolo _______________________________________________ nexa mailing list nexa@server-nexa.polito.it https://server-nexa.polito.it/cgi-bin/mailman/listinfo/nexa
On August 21, 2020 6:18:37 PM UTC, Marco Scialdone <marcoscialdone@gmail.com> wrote:
La Pec nasce fondamentalmente per rendere opponibile al terzo una comunicazione inviata ad un certo indirizzo analogamente a quanto avviene con la raccomandata cartacea.
Nel modello alternativo proposto, se disconosco di aver ricevuto una certa email da tizio, quali strumenti, legalmente vincolanti, ha tizio per dimostrare in giudizio in modo semplice ed immaginato che ho invece ricevuto quella comunicazione (anche se non l’ho letta)?
È sufficiente che la mail venga firmata automaticamente dai server SMTP che attraversa, in un header, dopo aver allegato un timestamp. Fatto a livello di header SMTP, sarebbe compatibile con tutti i server e tutti i client esistenti. I server SMTP compatibili potrebbero girare la firma con il timestamp al mittente. In questo modo non sarebbe nemmeno necessario detenere i log. Inoltre, contrariamente alla PEC, questo semplicissimo sistema garantirebbe che il contenuto della mail non possa essere alterato successivamente. La PEC, come la raccomandata garantisce la comunicazione, non il contenuto. Se una parte vuole rinnegare non la comunicazione, ma il contenuto della stessa, non c'è modo di stabilire chi mente. In questo modo invece la firma del server SMTP corrisponderà al messaggio originale, non ad uno diverso. Volendo tutelarsi da SMTP server corrotti che potrebbero firmare email aggiuntive a date nel passato, si potrebbe prevedere una hashchain (attenzione, HASHchain, non blockchain) fra le email etc.. Naturalmente, avere una chiave pubblica, firmata da un funzionario statale, associata a mittente e destinatario abilita tutta una serie di protocolli interessanti. Per esempio il mittente potrebbe cifrare il messaggio con una chiave simmetrica (prima di cifrarlo con quella pubblica del destinatario) ed allegare un indirizzo web su una trusted third party a cui il destinatario può trovare la chiave simmetrica. A quel punto, il log sul server della trusted third party garantisce che il destinatario ha provato a leggere l'email almeno una volta. Giacomo
La ricevuta completa della pec (quella che include anche il messaggio inviato e i suoi allegati e che tipicamente si usa nel pct o nelle notifiche processuali)) garantisce anche che quello che è stato ricevuto è esattamente quello che ho mandato (compresi gli allegati) nella remota ipotesi di contestazioni. Poi non so se altri sistemi possano funzionare meglio, quello che so è quanto questo sistema abbia migliorato enormemente lo svolgimento di una serie di attività che prima passavano da lunghe trafile burocratiche (in primis, le notifiche processuali) ----- Blog: www.marcoscialdone.it Twitter: @marcoscialdone LinkedIn: www.linkedin.com/in/marcoscialdone
Il giorno 21 ago 2020, alle ore 23:31, Giacomo Tesio <giacomo@tesio.it> ha scritto:
On August 21, 2020 6:18:37 PM UTC, Marco Scialdone <marcoscialdone@gmail.com> wrote: La Pec nasce fondamentalmente per rendere opponibile al terzo una comunicazione inviata ad un certo indirizzo analogamente a quanto avviene con la raccomandata cartacea.
Nel modello alternativo proposto, se disconosco di aver ricevuto una certa email da tizio, quali strumenti, legalmente vincolanti, ha tizio per dimostrare in giudizio in modo semplice ed immaginato che ho invece ricevuto quella comunicazione (anche se non l’ho letta)?
È sufficiente che la mail venga firmata automaticamente dai server SMTP che attraversa, in un header, dopo aver allegato un timestamp.
Fatto a livello di header SMTP, sarebbe compatibile con tutti i server e tutti i client esistenti.
I server SMTP compatibili potrebbero girare la firma con il timestamp al mittente.
In questo modo non sarebbe nemmeno necessario detenere i log.
Inoltre, contrariamente alla PEC, questo semplicissimo sistema garantirebbe che il contenuto della mail non possa essere alterato successivamente. La PEC, come la raccomandata garantisce la comunicazione, non il contenuto. Se una parte vuole rinnegare non la comunicazione, ma il contenuto della stessa, non c'è modo di stabilire chi mente. In questo modo invece la firma del server SMTP corrisponderà al messaggio originale, non ad uno diverso.
Volendo tutelarsi da SMTP server corrotti che potrebbero firmare email aggiuntive a date nel passato, si potrebbe prevedere una hashchain (attenzione, HASHchain, non blockchain) fra le email etc..
Naturalmente, avere una chiave pubblica, firmata da un funzionario statale, associata a mittente e destinatario abilita tutta una serie di protocolli interessanti.
Per esempio il mittente potrebbe cifrare il messaggio con una chiave simmetrica (prima di cifrarlo con quella pubblica del destinatario) ed allegare un indirizzo web su una trusted third party a cui il destinatario può trovare la chiave simmetrica. A quel punto, il log sul server della trusted third party garantisce che il destinatario ha provato a leggere l'email almeno una volta.
Giacomo
On August 22, 2020 7:32:47 AM UTC, Marco Scialdone <marcoscialdone@gmail.com> wrote:
La ricevuta completa della pec (quella che include anche il messaggio inviato e i suoi allegati e che tipicamente si usa nel pct o nelle notifiche processuali)) garantisce anche che quello che è stato ricevuto è esattamente quello che ho mandato (compresi gli allegati) nella remota ipotesi di contestazioni.
Cosa impedisce al ricevente della ricevuta di modificarne il contenuto prima di allegarla agli atti di un procedimento? Se la risposta è "nulla" (come ricordo dall'ultima volta che l'ho studiata), allora anche il ricevente potrebbe fare lo stesso accusando il mittente di averlo fatto.
Poi non so se altri sistemi possano funzionare meglio
La cosa incredibile è che non lo sapevano nemmeno i tecnici governativi che hanno realizzato o comunque approvato la PEC. Perché sì, esistono molti sistemi più semplici, efficienti e semplici da implementare. Non è un caso che ad oggi non esistano implementazioni libere funzionanti della PEC. È un sistema ridicolo, ridicolmente complicato. A pensar bene, si potrebbe ipotizzare che la sua progettazione sia stata affidata a pivelli con ganci politici. A pensar male, viene da chiedersi chi sia, fra coloro che hanno partecipato alla progettazione della PEC che ci ha guadagnato di più (una società italiana, il cui nome inizia e finisce con la stessa vocale).
quello che so è quanto questo sistema abbia migliorato enormemente lo svolgimento di una serie di attività che prima passavano da lunghe trafile burocratiche (in primis, le notifiche processuali)
Io non festeggerei la sostituzione di una montagna di scartoffie con fragile castello di carte. ;-) Giacomo
Giacomo Tesio <giacomo@tesio.it> writes:
On August 22, 2020 7:32:47 AM UTC, Marco Scialdone <marcoscialdone@gmail.com> wrote:
La ricevuta completa della pec (quella che include anche il messaggio inviato e i suoi allegati e che tipicamente si usa nel pct o nelle notifiche processuali)) garantisce anche che quello che è stato ricevuto è esattamente quello che ho mandato (compresi gli allegati) nella remota ipotesi di contestazioni.
Cosa impedisce al ricevente della ricevuta di modificarne il contenuto prima di allegarla agli atti di un procedimento?
La ricevuta di consegna della PEC di cui parla Marco è un messaggio di tipo multipart/signed firmato con S/MIME dal provider del destinatario del messaggio PEC A meno che io stia prendendo una sonora cantonata (ho verificato su un paio di messaggi PEC) tutto il contenuto della ricevuta, compresi gli allegati, è inglobato in questo: --8<---------------cut here---------------start------------->8--- Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-1; boundary="----=_Part_281003588_807314074.1588076720058" --8<---------------cut here---------------end--------------->8--- Quindi può alterare il contenuto del messaggio solo chi è in grado di firmare con lo stesso certificato X.509: il provider del destinatario o un attaccante con sufficiente determinazione e possibilità tecniche.
Se la risposta è "nulla" (come ricordo dall'ultima volta che l'ho studiata), allora anche il ricevente potrebbe fare lo stesso accusando il mittente di averlo fatto.
No perché anche il messaggio consegnato è sono firmato con S/MIME come il messaggio di avvenuta consegna visto sopra. (sempre a meno di cantonate mie)
Poi non so se altri sistemi possano funzionare meglio
TUTTO dipende da quali criteri si utilizzano per giudicare le qualità dei sistemi. Chi ha deciso per PEC, TECNICAMENTE, ha valutato che la "certification by authority" della PKI (Public Key Infrastructure) X.509 usata in S/MIME è meglio del "web of trust" usato in OpenPGP; altri come me (e Giacomo AFAIU) la pensano diversamente. Ora non voglio andare troppo lontano con questo discorso, ma AFAIU è ormai sufficientemente condiviso nella comunità di chi si occupa di sicurezza IT che l'ecosistema PKI ha degli insanabili bachi [1]… architetturali :-O (cioè non "normali" bachi del software a cui FORSE bene o male si può rimediare)
La cosa incredibile è che non lo sapevano nemmeno i tecnici governativi che hanno realizzato o comunque approvato la PEC.
No dai, non la metterei così :-)
Perché sì, esistono molti sistemi più semplici, efficienti e semplici da implementare.
Sì ma *pare* che anche in EU, con eIDAS, non la pensino come me e te: https://www.forumpa.it/pa-digitale/il-futuro-europeo-della-pec-necessarie-nu... Cioè le regole tecniche del Registered Electronic Delivery (RED) non mi paiono (stando a quanto leggo) meno complicate di quelle PEC. Facciamocene una ragione :-D
Non è un caso che ad oggi non esistano implementazioni libere funzionanti della PEC.
Non so se sia funzionante (oggi *pare* un progetto abbandonato) ma esiste http://openpec.sourceforge.net Comunque sia a cosa serve se per poter implementare un server per ricevere o inviare email PEC occorre accreditarsi presso il CNIPA *e* avere un capitale sociale interamente versato di almeno un milione di EUR? [...]
quello che so è quanto questo sistema abbia migliorato enormemente lo svolgimento di una serie di attività che prima passavano da lunghe trafile burocratiche (in primis, le notifiche processuali)
Io non festeggerei la sostituzione di una montagna di scartoffie con fragile castello di carte. ;-)
Beh, per l'utilizzatore finale potersi dimenticare di procedure farragginose e montagne di scartoffie "solo" per poter dimostrare di aver inviato o meno una certa comunicazione è ESTREMAMENTE conveniente, laddove funziona [2]. Diciamo che secondo te e me si potrebbe fare di meglio e meno complicato. Saluti, Giovanni. [1] https://en.wikipedia.org/wiki/X.509#Security [2] tipo NON nei casi in cui gli enti ti chiedono di inviare via PEC una comunicazione *e* di protocollare presso l'ufficio la stampa fisica della ricevuta PEC :-O -- Giovanni Biscuolo
On August 22, 2020 10:30:57 AM UTC, Giovanni Biscuolo <giovanni@biscuolo.net> wrote:
Cosa impedisce al ricevente della ricevuta di modificarne il contenuto prima di allegarla agli atti di un procedimento?
La ricevuta di consegna della PEC di cui parla Marco è un messaggio di tipo multipart/signed firmato con S/MIME dal provider del destinatario del messaggio PEC [...]
Quindi può alterare il contenuto del messaggio solo chi è in grado di firmare con lo stesso certificato X.509: il provider del destinatario o un attaccante con sufficiente determinazione e possibilità tecniche.
Grazie Giovanni, in effetti questo non lo sapevo. Non è particolarmente diverso da quanto descrivevo. L'uso di sha-1 non lascia puzza parecchio, ma è già più di quanto attribuissi alla PEC. Devo approfondire. ;-) Giacomo
On 22/08/2020 10:03, Giacomo Tesio wrote:
È un sistema ridicolo, ridicolmente complicato. A pensar bene, si potrebbe ipotizzare che la sua progettazione sia stata affidata a pivelli con ganci politici.
non sono molto d'accordo. IMHO si potevano fare anche scelte che conferissero una migliore ergonomia, ma l'idea che il documento sia firmato dal gestore e non dall'utente, nell'epoca storica in cui e' nata, non mi sembra una complicazione per l'utente, anzi. forse oggi la situazione e' diversa (forse) non essendo utente di gmail non so se si possa firmare digitalmente da gmail con un certificato attribuito da una CA riconosciuta dallo stato (chee comunque andrebbe messo in pidi) e se si puo', non so da quando. ciao, s.
Io pensavo più ad un semplice web of trust ma in cui lo Stato (attraverso ad esempio le anagrafi) partecipa come gli altri. Quanto alla firma del mittente, non sono d'accordo. Diversi client email permettono l'integrazione con PGP o GPG: Thunderbird, Mutt, Claws-Mail... persino Outlook! Imparare a firmare (e/o cifrare) una mail con una chiave non richiede una laurea. È una cosa che si impara in 30 minuti. E verificarla o decifrarla può essere persino più semplice: se il mua sa dove trovare le chiavi fa tutto da solo. Dunque se lo Stato avesse imposto l'uso di questi sistemi invece della PEC, la gente si sarebbe arrangiata ed avrebbe imparato. Magari sarebbe nato un piccolo mercato di consulenti informatici per la formazione iniziale. On August 22, 2020 4:44:05 PM UTC, Stefano Quintarelli <stefano@quintarelli.it> wrote:
non essendo utente di gmail non so se si possa firmare digitalmente da gmail con un certificato attribuito da una CA riconosciuta dallo stato
Ricordo un plugin firefox (o era chrome?) che si integrava in GMail per permettere proprio questo. Non l'ho mai usato però. Tuttavia, la compatibilità con GMail non dovrebbe l'obiettivo di uno stato (a meno che non abbia il controllo di Google, ovviamente). L'educazione informatica della propria popolazione invece sì. Giacomo PS: Dovrò ovviamente trovare il tempo di approfondire il funzionamento della ricevuta delineato da Giovanni, perché (sha1 a parte) potrebbe sorprendentemente avere un senso. :-)
Buongiorno Stefano, Stefano Quintarelli <stefano@quintarelli.it> writes: [...]
forse oggi la situazione e' diversa (forse) non essendo utente di gmail non so se si possa firmare digitalmente da gmail con un certificato attribuito da una CA
Se intendi dalla webmail di GMail la risposta è no (ma vale per tutte le webmail): S/MIME (e OpenPGP) non è utilizzabile in un contesto simile, ci vuole un client email che supporti S/MIME. In quest'ultimo caso, se l'utente possiede un certificato può firmare email alla stessa stregua (tecnica) di un ente terzo. Con la PEC sono state introdotte estesioni ai protocolli per fare in modo che terzi certificati attestino la data e ora della comunicazione (marca temporale) e - firmando una *copia* del messaggio - l'autenticità del contenuto: tutto ciò avrebbe potuto essere ottenuto aggiungendo (e concordando a livello internazionale) meccanismi standard di "marca temporale" che non prevedessero la necessità di terzi certificati e lasciando agli utenti l'onere e l'onore di firmare digitalmente i propri messaggi. Oltre all'aspetto tecnico, il "sistema PEC" ha aggiunto "il carico" dell'accreditamento e dei requisiti finanziari. Sull'uso di S/MIME piuttosto che OpenPGP ho già detto: questioni prettamente di FILOSOFIA della burocrazia, che però hanno anche importanti ripercussioni fattuali: infatti la PKI dei certificati X.509 è architetturalmente BACATA [1] e troppo facilmente compromessibile. [2] Il web of trust almeno *può* (e nel caso in questione dovrebbe) essere usato in modo che non ci sia un unico point of failure nella catena di trust, aumentando la resilienza del sistema con l'aumentare dei "nodi" fidati: potrebbero essere gli ufficiali comunali (affiancati da notai e altri funzionari pubblici preposti) che con la loro web of trust "benedicono" i certificati dei cittadini (che poi si benedicono a vicenda). Il web of trust funziona grandiosamente per garantire l'identità dei membri in circoli più o meno ristretti di sviluppatori - penso ad esempio al Debian Keyring [3] - mi sarebbe piaciuto che una cosa del genere fosse stata almeno tentata per garantire l'autenticità dei messaggi email.
riconosciuta dallo stato
Non capisco: cosa intendi con CA riconosciuta dallo stato? [...] Ciao, Giovanni [1] https://en.wikipedia.org/wiki/Certificate_authority#Implementation_weakness_... [2] https://en.wikipedia.org/wiki/Certificate_authority#CA_compromise [3] https://wiki.debian.org/DebianKeyring -- Giovanni Biscuolo
On Sun, Aug 23, 2020 at 11:53:52AM +0200, Giovanni Biscuolo wrote:
Sull'uso di S/MIME piuttosto che OpenPGP ho già detto: questioni prettamente di FILOSOFIA della burocrazia, che però hanno anche importanti ripercussioni fattuali: infatti la PKI dei certificati X.509 è architetturalmente BACATA [1] e troppo facilmente compromessibile. [2]
Il web of trust almeno *può* (e nel caso in questione dovrebbe) essere usato in modo che non ci sia un unico point of failure nella catena di trust, aumentando la resilienza del sistema con l'aumentare dei "nodi" fidati: potrebbero essere gli ufficiali comunali (affiancati da notai e altri funzionari pubblici preposti) che con la loro web of trust "benedicono" i certificati dei cittadini (che poi si benedicono a vicenda).
Il web of trust funziona grandiosamente per garantire l'identità dei membri in circoli più o meno ristretti di sviluppatori - penso ad esempio al Debian Keyring [3] - mi sarebbe piaciuto che una cosa del genere fosse stata almeno tentata per garantire l'autenticità dei messaggi email.
Sono sempre stato un grande sostenitore del Web of Trust (WoT), in particolare come alternativa a soluzioni di PKI più centralizzate. Ma ricordi qui che, ad oggi, l'infrastruttura cardine del Web of Trust per OpenPGP, ovvero i key server SKS, risulta compromessa/inutilizzabile a causa degli attacchi di certificate flooding (c.f. https://lwn.net/Articles/792366/ ; ci sono probabilmente riferimenti più recenti sul tema, ma non li avevo sotto mano) contro i quali non esiste una vera soluzione a cause di scelte fatte in OpenPGP (scelte che avevano un senso decadi fa, ma che purtroppo si sono rivelata liabilities nella internet di oggi). Il caso di Debian che citi come buon esempio e che posso confermare per esperienza personale funzioni molto bene, funziona ancora proprio perché è controllato in maniera centralizzata da un gruppo molto ristretto (2-3 persone) di keyring manager, che devono validare tutti gli update alle chiavi prima che questi arrivino nel keyring condiviso. Quindi di fatto limitando moltissimo gli aspetti decentralizzati dell'architettura WoT. Ci sono proposte di alternative ai key server per WoT, ma ad oggi mi risulta che abbiano un'adozione molto ma molto limitata. Prima di consigliare quindi oggi un'adozione massiva di WoT veramente distribuito a livello di uno Stato ci penserei quindi molte molte volte. Una soluzione ibrida a-la Debian sarebbe certamente fattibile. Ma a quel punto non si capisce bene quale sarebbe il vantaggio rispetto ad una PKI centralizzata, con chiavi/certificati distribuiti direttamente dallo Stato. Ciao -- Stefano Zacchiroli . zack@upsilon.cc . upsilon.cc/zack . . o . . . o . o Computer Science Professor . CTO Software Heritage . . . . . o . . . o o Former Debian Project Leader & OSI Board Director . . . o o o . . . o . « the first rule of tautology club is the first rule of tautology club »
On August 23, 2020 11:45:37 AM UTC, Stefano Zacchiroli <zack@upsilon.cc> wrote:
Ma ricordi qui che, ad oggi, l'infrastruttura cardine del Web of Trust per OpenPGP, ovvero i key server SKS, risulta compromessa/inutilizzabile a causa degli attacchi di certificate flooding
Non a caso, nella ipotetica infrastruttura di WoT che descrivevo, la firma delle chiavi (e ovviamente il loro inserimento nei keyserver comunali, nonché il loro aggiornamento) avveniva dall'anagrafe dietro un piccolo pagamento. La distribuzione (magari federara e replicata) dei keyserver comunali differenzierebbe il rischio di compromissioni e malfunzionamenti, ed insieme al pagamento ridurrebbe moltissimo la probabilità e l'impatto di DDoS.
Il caso di Debian che citi come buon esempio e che posso confermare per esperienza personale funzioni molto bene, funziona ancora proprio perché è controllato in maniera centralizzata da un gruppo molto ristretto (2-3 persone) di keyring manager, che devono validare tutti gli update alle chiavi prima che questi arrivino nel keyring condiviso. Quindi di fatto limitando moltissimo gli aspetti decentralizzati dell'architettura WoT.
Sono certo che fornendo al personale che lavora in un'anagrafe comunale strumenti e formazione adeguata, non avrebbero alcun problema a garantire lo stesso livello qualitativo.
Ci sono proposte di alternative ai key server per WoT, ma ad oggi mi risulta che abbiano un'adozione molto ma molto limitata.
Parli di keybase? Se vuole, uno Stato ha strumenti persuasivi più efficaci del mercato. Dispone di scuole, ospedali, enti locali. Il punto è sempre come li usa. Immagina per esempio i vantaggi di un sistema del genere per la medicina territoriale. Immagina i software che si potrebbero scrivere sulla base di una infrastruttura del genere
Prima di consigliare quindi oggi un'adozione massiva di WoT veramente distribuito a livello di uno Stato ci penserei quindi molte molte volte.
Per carità, come recentemente dimostrato dal contact tracing, prima di introdurre (o lasciar introdurre) modifiche in un sistema cibernetico molto vasto la cautela è sempre importantissima. E di solito manca completamente. Tuttavia, in questo caso, si tratta di un'infrastruttura informatica paragonabile alle strade: difficilmente potrà essere realizzata e gestita dalla magica mano invisibile che governa il mercato, esattamente come avviene per le strade statali, provinciali e comunali che collegano la stragrande maggioranza del territorio italiano.
Una soluzione ibrida a-la Debian sarebbe certamente fattibile. Ma a quel punto non si capisce bene quale sarebbe il vantaggio rispetto ad una PKI centralizzata, con chiavi/certificati distribuiti direttamente dallo Stato.
Beh direi che ci sono almeno un paio di vantaggi evidenti: - un'infrastruttura del genere funzionerebbe da bootstrap culturale - per le amministrazioni pubbliche, i cui dipendenti imparerebbero ad usare la crittografia asimmetrica e a comprenderne le basi del funzionamento - per i cittadini, che inizierebbero a cifrare le proprie comunicazioni (con notevoli vantaggi per privacy e libertà personale) oltre che ad estendere il WoT firmandosi reciprocamente le chiavi - per le aziende italiane, che potrebbero contare su una infrastruttura innovativa (se si può chiamare ancora così nel 2020) capillarmente diffusa sul territorio per realizzare nuove tipologie di servizi privacy-friendly - i keyserver sarebbero tanti, distribuendo i rischi e i costi come detto - contrariamente ad una Certification Authority centralizzata, lo Stato non potrebbe abusare facilmente della fiducia che gli attribuiscono i cittadini proprio perché il Web of Trust è un grafo: se un comune alterasse il proprio keystore per attaccare un cittadino, sarebbe estremamente semplice notarlo e denunciare i responsabili e tale attacco avrebbe una probabilità di successo inversamente proporzionale al numero di firme ricevute dalla PK del cittadino bersaglio. Dunque si può certo discutere sul COME sarebbe meglio implementare un'infrastruttura di questo genere, ma credo che la sua utilità sociale ed economica sia abbastanza evidente. Potrei arrivare a scommettere una cena che, se l'Italia realizzasse un sistema del genere (imponendone l'utilizzo a scuole, ospedali ed aziende, per esempio) verrebbe subito imitata da altre nazioni per colmare il vantaggio competitivo che avrebbero le nostre aziende (dopo la consueta opposizione iniziale).
Ciao
A presto! Giacomo
Ciao Stefano, Stefano Zacchiroli <zack@upsilon.cc> writes:
On Sun, Aug 23, 2020 at 11:53:52AM +0200, Giovanni Biscuolo wrote:
Sull'uso di S/MIME piuttosto che OpenPGP ho già detto: questioni prettamente di FILOSOFIA della burocrazia, che però hanno anche importanti ripercussioni fattuali: infatti la PKI dei certificati X.509 è architetturalmente BACATA [1] e troppo facilmente compromessibile. [2]
Ho lasciato la citazione sopra per due motivi: 1. chiarisco che non era mia intenzione sostenere che OpenPGP è esente da problemi tecnici 2. ritengo (concordando con altri più bravi di me) che i problemi architetturali delle PKI basate su CA siano insanabili [...]
Sono sempre stato un grande sostenitore del Web of Trust (WoT), in particolare come alternativa a soluzioni di PKI più centralizzate. Ma ricordi qui che, ad oggi, l'infrastruttura cardine del Web of Trust per OpenPGP, ovvero i key server SKS,
Non sono d'accordo nel considerare i server di ricerca e distribuzione delle chiavi infrastruttura cardine, però è certo un servizio molto importante.
risulta compromessa/inutilizzabile a causa degli attacchi di certificate flooding (c.f. https://lwn.net/Articles/792366/ ; ci sono probabilmente riferimenti più recenti sul tema, ma non li avevo sotto mano)
Da quello che ho letto in giro mi sento di dire che la miglior analisi (e sunto) di quello che è successo con gli attacchi di "poisoning" dei certificati OpenPGP è quella di Robert J. Hansen https://gist.github.com/rjhansen/67ab921ffb4084c865b3618d6955275f Non voglio sminuire la portata di questo problema, tuttavia voglio sottolineare che si tratta di problemi tecnici (non architetturali) *seri* dovuti sostanzialmente al fatto che il software SKS è abandonware da tempo [1]. La soluzione che la community ha *rapidissimamente* adottato per uscire dal "SKS bug" è stata quella di adottare https://keys.openpgp.org/ che, in circa tre mesi dal suo lancio, è diventato il keyserver (non distribuito e non federato) di riferimento per molti progetti, tra cui Debian. Questo keyserver è tutt'altro che perfetto ma almeno risolve i problemi che c'erano con la rete SKS. Forse, dico *forse*, avere avuto l'attenzione delle istituzioni e qualche risorsa in più (non solo in termini finanziari) avrebbe consentito di creare un'infrastruttura di distribuzione delle chiavi OpenPGP ancora migliore.
contro i quali non esiste una vera soluzione a cause di scelte fatte in OpenPGP (scelte che avevano un senso decadi fa, ma che purtroppo si sono rivelata liabilities nella internet di oggi).
Questo vale praticamente per quasi tutti i protocolli della internet di oggi, per questo va rifatta :-D [...]
Ci sono proposte di alternative ai key server per WoT, ma ad oggi mi risulta che abbiano un'adozione molto ma molto limitata.
https://keys.openpgp.org/ è una alternativa a SKS molto utilizzata
Prima di consigliare quindi oggi un'adozione massiva di WoT veramente distribuito a livello di uno Stato ci penserei quindi molte molte volte.
Ci ho pensato molte molte volte e mi permetto di insistere :-) : i sistemi basati su WoT sono architetturalmente superiori a quelli basati sulle CA, al netto dei problemi tecnici (che hanno anche i software usati nell'ecosistema X.509)… non c'è proprio partita :-D
Una soluzione ibrida a-la Debian sarebbe certamente fattibile. Ma a quel punto non si capisce bene quale sarebbe il vantaggio rispetto ad una PKI centralizzata, con chiavi/certificati distribuiti direttamente dallo Stato.
Ma intendi creazione delle coppie o distribuzione? Se intendi creazione, non è certo quello che succede con il sistema semi-centralizzato di distribuzione delle chiavi pubbliche dei propri membri che effettua Debian, ma probabilmente non ho capito io quello che intendi dire. Semplificando un pochino, il problema architetturale con le CA è esattamente quello che la creazione della coppia chiave/certificato viene effettuata dalla CA e la verifica lato client si fonda sulla fiducia che **la catena** di firma del certificato ricevuto non sia stata compromessa. Dulcis in fundo, come tu sai l'architettura basata su CA non prevede nemmeno un sistema di *distribuzione* dei certificati, tanto che tali certificati sono distribuiti sotto forma di pacchetti da installare localmente (e aggiornare quando vengono aggiornati); Debian, per esempio, li distribuisce nel pacchetto ca-certificates [2] che nella descrizione dice: --8<---------------cut here---------------start------------->8--- Contiene le autorità di certificazione fornite con il browser di Mozilla che permettono alle applicazioni basate su SSL di verificare l'autenticità delle connessioni SSL. Notare che Debian non può né confermare né negare che sia stata in alcun modo verificata l'affidabilità o la conformità con la RFC 3647 delle autorità di certificazione, i cui certificati sono inclusi in questo pacchetto. La responsabilità di verificarle ricade completamente sull'amministratore del sistema locale. --8<---------------cut here---------------end--------------->8--- Le stesse CA sono utilizzate anche da S/MIME per le email. Questo sostanzialmente vale per ogni sistema operativo. Non credo che la situazione sarebbe sostanzialmente migliore se ca-certificates fosse distribuito dallo Stato. [...] Ciao, Giovanni. [1] https://gist.github.com/rjhansen/67ab921ffb4084c865b3618d6955275f#why-hasnt-... [2] https://packages.debian.org/buster/ca-certificates
Ciao Stefano, Stefano Zacchiroli <zack@upsilon.cc> writes:
On Sun, Aug 23, 2020 at 11:53:52AM +0200, Giovanni Biscuolo wrote:
Sull'uso di S/MIME piuttosto che OpenPGP ho già detto: questioni prettamente di FILOSOFIA della burocrazia, che però hanno anche importanti ripercussioni fattuali: infatti la PKI dei certificati X.509 è architetturalmente BACATA [1] e troppo facilmente compromessibile. [2]
Ho lasciato la citazione sopra per due motivi: 1. chiarisco che non era mia intenzione sostenere che OpenPGP è esente da problemi tecnici 2. ritengo (concordando con altri più bravi di me) che i problemi architetturali delle PKI basate su CA siano insanabili [...]
Sono sempre stato un grande sostenitore del Web of Trust (WoT), in particolare come alternativa a soluzioni di PKI più centralizzate. Ma ricordi qui che, ad oggi, l'infrastruttura cardine del Web of Trust per OpenPGP, ovvero i key server SKS,
Non sono d'accordo nel considerare i server di ricerca e distribuzione delle chiavi infrastruttura cardine, però è certo un servizio molto importante.
risulta compromessa/inutilizzabile a causa degli attacchi di certificate flooding (c.f. https://lwn.net/Articles/792366/ ; ci sono probabilmente riferimenti più recenti sul tema, ma non li avevo sotto mano)
Da quello che ho letto in giro mi sento di dire che la miglior analisi (e sunto) di quello che è successo con gli attacchi di "poisoning" dei certificati OpenPGP è quella di Robert J. Hansen https://gist.github.com/rjhansen/67ab921ffb4084c865b3618d6955275f Non voglio sminuire la portata di questo problema, tuttavia voglio sottolineare che si tratta di problemi tecnici (non architetturali) *seri* dovuti sostanzialmente al fatto che il software SKS è abandonware da tempo [1]. La soluzione che la community ha *rapidissimamente* adottato per uscire dal "SKS bug" è stata quella di adottare https://keys.openpgp.org/ che, in circa tre mesi dal suo lancio, è diventato il keyserver (non distribuito e non federato) di riferimento per molti progetti, tra cui Debian. Questo keyserver è tutt'altro che perfetto ma almeno risolve i problemi che c'erano con la rete SKS. Forse, dico *forse*, avere avuto l'attenzione delle istituzioni e qualche risorsa in più (non solo in termini finanziari) avrebbe consentito di creare un'infrastruttura di distribuzione delle chiavi OpenPGP ancora migliore.
contro i quali non esiste una vera soluzione a cause di scelte fatte in OpenPGP (scelte che avevano un senso decadi fa, ma che purtroppo si sono rivelata liabilities nella internet di oggi).
Questo vale praticamente per quasi tutti i protocolli della internet di oggi, per questo va rifatta :-D [...]
Ci sono proposte di alternative ai key server per WoT, ma ad oggi mi risulta che abbiano un'adozione molto ma molto limitata.
https://keys.openpgp.org/ è una alternativa a SKS molto utilizzata
Prima di consigliare quindi oggi un'adozione massiva di WoT veramente distribuito a livello di uno Stato ci penserei quindi molte molte volte.
Ci ho pensato molte molte volte e mi permetto di insistere :-) : i sistemi basati su WoT sono architetturalmente superiori a quelli basati sulle CA, al netto dei problemi tecnici (che hanno anche i software usati nell'ecosistema X.509)… non c'è proprio partita :-D
Una soluzione ibrida a-la Debian sarebbe certamente fattibile. Ma a quel punto non si capisce bene quale sarebbe il vantaggio rispetto ad una PKI centralizzata, con chiavi/certificati distribuiti direttamente dallo Stato.
Ma intendi creazione delle coppie o distribuzione? Se intendi creazione, non è certo quello che succede con il sistema semi-centralizzato di distribuzione delle chiavi pubbliche dei propri membri che effettua Debian, ma probabilmente non ho capito io quello che intendi dire. Semplificando un pochino, il problema architetturale con le CA è esattamente quello che la creazione della coppia chiave/certificato viene effettuata dalla CA e la verifica lato client si fonda sulla fiducia che **la catena** di firma del certificato ricevuto non sia stata compromessa. Dulcis in fundo, come tu sai l'architettura basata su CA non prevede nemmeno un sistema di *distribuzione* dei certificati, tanto che tali certificati sono distribuiti sotto forma di pacchetti da installare localmente (e aggiornare quando vengono aggiornati); Debian, per esempio, li distribuisce nel pacchetto ca-certificates [2] che nella descrizione dice: --8<---------------cut here---------------start------------->8--- Contiene le autorità di certificazione fornite con il browser di Mozilla che permettono alle applicazioni basate su SSL di verificare l'autenticità delle connessioni SSL. Notare che Debian non può né confermare né negare che sia stata in alcun modo verificata l'affidabilità o la conformità con la RFC 3647 delle autorità di certificazione, i cui certificati sono inclusi in questo pacchetto. La responsabilità di verificarle ricade completamente sull'amministratore del sistema locale. --8<---------------cut here---------------end--------------->8--- Le stesse CA sono utilizzate anche da S/MIME per le email. Questo sostanzialmente vale per ogni sistema operativo. Non credo che la situazione sarebbe sostanzialmente migliore se ca-certificates fosse distribuito dallo Stato. [...] Ciao, Giovanni. [1] https://gist.github.com/rjhansen/67ab921ffb4084c865b3618d6955275f#why-hasnt-... [2] https://packages.debian.org/buster/ca-certificates
On August 24, 2020 11:14:16 AM UTC, Giovanni Biscuolo <giovanni@biscuolo.net> wrote:
1. chiarisco che non era mia intenzione sostenere che OpenPGP è esente da problemi tecnici
Tuttavia, affidando la verifica dell'identità e la firma delle chiavi pubbliche all'anagrafe, tutti i problemi classici dei keyserver SKS (bug a parte) spariscono. Per esempio cancellazione ed aggiornamento delle chiavi potrebbe essere gestita in modo molto semplice.
2. ritengo (concordando con altri più bravi di me) che i problemi architetturali delle PKI basate su CA siano insanabili
Ma infatti non credo che Stefano Zacchiroli, suggerisse l'introduzione di una CA di Stato (come invece ipotizzava Stefano Quintarelli). Semplicemente, se ho capito bene (Stefano, correggimi pure se ho frainteso), ritiene che lo Stato non debba occuparsi di infrastrutture informatiche come questa e debba lasciar fare al mercato. Cosa che, nel 2020, equivale lasciare al mercato la progettazione e la manutenzione di strade statali, provinciali, comunali, ponti, gallerie... O meglio: significa lasciar fare ad altri Stati tramite le aziende che proteggono e sovvenzionano in vario modo. Giacomo
On Mon, Aug 24, 2020 at 01:14:16PM +0200, Giovanni Biscuolo wrote:
Non sono d'accordo nel considerare i server di ricerca e distribuzione delle chiavi infrastruttura cardine, però è certo un servizio molto importante.
Fair enough.
Da quello che ho letto in giro mi sento di dire che la miglior analisi (e sunto) di quello che è successo con gli attacchi di "poisoning" dei certificati OpenPGP è quella di Robert J. Hansen https://gist.github.com/rjhansen/67ab921ffb4084c865b3618d6955275f
Non voglio sminuire la portata di questo problema, tuttavia voglio sottolineare che si tratta di problemi tecnici (non architetturali) *seri* dovuti sostanzialmente al fatto che il software SKS è abandonware da tempo [1].
Non capisco perché tu dica questo. Certo, SKS è software non mantenuto che era diventato (suo malgrado) infrastruttura importante del WoT. E certamente più funding (e scelte di implementazione diverse) avrebbe aiutato. Ma l'origine del problema qui non è in SKS, ma nel protocollo OpenPGP. La situazione contestuale di SKS ha impedito di applicare a quella rete un workaround. Che è stato invece implementato su *un* (altro) keyserver, che è diventato un nuovo single point of failure della distribuzione delle chiavi GPG. Questo per me è un altro sintomo del fallimento del sogno di avere una PKI completamente decentralizzata. Ma capisco il tuo punto più sotto che:
Ma intendi creazione delle coppie o distribuzione?
Se intendi creazione, non è certo quello che succede con il sistema semi-centralizzato di distribuzione delle chiavi pubbliche dei propri membri che effettua Debian, ma probabilmente non ho capito io quello che intendi dire.
Giusto. Nel messaggio precedente non avevo fatto questa distinzione, ma pensavo principalmente alla distribuzione delle chiavi. Concordo che la *creazione* distribuita delle chiavi abbia vantaggi importanti su quella centralizzata. Ma porta anche problemi di trust nelle diverse versioni del software che crea le chiavi (immagina una riedizione del famoso bug di OpenSSL in Debian applicato a GPG). Le puoi mitigare con approcci a-la reproducible-builds, ma aumenti molto la complessità diciamo "sociale" di adottare la tecnologia. Con la creazione centralizzata statale aggiungi un altro single point of failure (male!), ma potresti ottenere in cambio più scrutiny, investimenti, migliore manutenzione del software, etc. Se stiamo parlando di identità digitali poi opponibili dai cittadino allo stato e vice-versa è un trade-off che non mi sembrerebbe campato in aria. (Ovviamente sto pensando qui ad uno Stato competente in tecnologie digitali...) Ciao -- Stefano Zacchiroli . zack@upsilon.cc . upsilon.cc/zack . . o . . . o . o Computer Science Professor . CTO Software Heritage . . . . . o . . . o o Former Debian Project Leader & OSI Board Director . . . o o o . . . o . « the first rule of tautology club is the first rule of tautology club »
On August 24, 2020 12:23:45 PM UTC, Stefano Zacchiroli <zack@upsilon.cc> wrote:
Ma l'origine del problema qui non è in SKS, ma nel protocollo OpenPGP.
Scusa la mia ignoranza, ma pur riguardando la documentazione su https://www.openpgp.org/about/standard/ non mi è chiaro cosa intendi.
Con la creazione centralizzata statale aggiungi un altro single point of failure
Non mi è chiaro cosa intendi. "Lo Stato" è un organizzazione estremamente complessa ed articolata. Se distribuisci identità e chiavi su base geografica, con un HKS per comune (e magari per circoscrizione, nelle città metropolitane) non hai single point of failure. Soprattutto se tali server sono federati e ridondati. Non mi è proprio chiaro cosa intendi. D'altro canto, i key server servono solo per reperire la chiave pubblica (con la firma del comune) la prima volta: chiavi e firme così ottenute possono essere scambiate (quasi) liberamente dai cittadini successivamente, un po' come numeri di telefono fra amici. Dunque anche localmente, il point of failure non implicherebbe un interruzione delle comunicazioni.
ma potresti ottenere in cambio più scrutiny, investimenti, migliore manutenzione del software, etc. Se stiamo parlando di identità digitali poi opponibili dai cittadino allo stato e vice-versa è un trade-off che non mi sembrerebbe campato in aria. (Ovviamente sto pensando qui ad uno Stato competente in tecnologie digitali...)
Ovviamente. C'è molto lavoro da fare, ma chi ben comincia... ;-) Giacomo
Stefano Zacchiroli <zack@upsilon.cc> writes: [...]
Non voglio sminuire la portata di questo problema, tuttavia voglio sottolineare che si tratta di problemi tecnici (non architetturali) *seri* dovuti sostanzialmente al fatto che il software SKS è abandonware da tempo [1].
Non capisco perché tu dica questo.
Perché è quello che ho capito studiando il probelma, ma potrei aver capito male ovviamente [...]
Ma l'origine del problema qui non è in SKS, ma nel protocollo OpenPGP. La situazione contestuale di SKS ha impedito di applicare a quella rete un workaround. Che è stato invece implementato su *un* (altro) keyserver, che è diventato un nuovo single point of failure della distribuzione delle chiavi GPG. Questo per me è un altro sintomo del fallimento del sogno di avere una PKI completamente decentralizzata.
Diciamo che si tratta di stabilire se fallisce peggio una PKI completamente centralizzata rispetto a una decentralizzata con sistema di distribuzione chiavi federato
Ma capisco il tuo punto più sotto che:
Ma intendi creazione delle coppie o distribuzione?
Se intendi creazione, non è certo quello che succede con il sistema semi-centralizzato di distribuzione delle chiavi pubbliche dei propri membri che effettua Debian, ma probabilmente non ho capito io quello che intendi dire.
Giusto. Nel messaggio precedente non avevo fatto questa distinzione, ma pensavo principalmente alla distribuzione delle chiavi.
OK chiaro.
Concordo che la *creazione* distribuita delle chiavi abbia vantaggi importanti su quella centralizzata. Ma porta anche problemi di trust nelle diverse versioni del software che crea le chiavi (immagina una riedizione del famoso bug di OpenSSL in Debian applicato a GPG). Le puoi mitigare con approcci a-la reproducible-builds, ma aumenti molto la complessità diciamo "sociale" di adottare la tecnologia.
Diciamo che a livello sociale il problema del trust dei binari va affrontato alrimenti non potremo mai avere confidenza che i nostri sistemi facciano quello che dichiarano, ma per tornare a bimba al problema del trist io direi che con un sistema WoT è tecnicamente fattibile mentre con un sistema di CA è **solo** un atto di fede :-)
Con la creazione centralizzata statale aggiungi un altro single point of failure (male!), ma potresti ottenere in cambio più scrutiny, investimenti, migliore manutenzione del software, etc.
Anche con un WoT cove le istuzioni partecipino attivamente a sviluppare, gestire e migliorare la tecnilogia che lo implementa; la differenza è che rispetto alla CA chi riceve la coppia certificato/chiave. ovvero il cittadino, non può far altro che fidarsi.
Se stiamo parlando di identità digitali poi opponibili dai cittadino allo stato e vice-versa è un trade-off che non mi sembrerebbe campato in aria. (Ovviamente sto pensando qui ad uno Stato competente in tecnologie digitali...)
Io auspico un sistema in cui l'identità digitale sia gestita dai cittadini e "certificata" da un sistema in cui il trust è tecnologicamente (scientificamente?) dimostrabile e non fondato principalmente sulla fiducia in una authority centrale. -- Giovanni Biscuolo
Buongiorno Marco, Marco Scialdone <marcoscialdone@gmail.com> writes: [...]
Nel modello alternativo proposto, se disconosco di aver ricevuto una certa email da tizio, quali strumenti, legalmente vincolanti, ha tizio per dimostrare in giudizio in modo semplice ed immaginato che ho invece ricevuto quella comunicazione (anche se non l’ho letta)?
nell'email che citi, Giacomo e io stavamo FANTASTICANDO su un sistea di cestione e certificazione dell'identità distribuito, la questione "validità legale dell'email" per fortuna è un po' più semplice :-) Questo articolo di Carlo Piana illustra gli scenari e fornisce una caso di realmente avvenuto. (se altri giuristi o legali in lista volessero aggiungere elementi, anche a confutazione, sarebbe fantastico) https://www.piana.eu/prova_email/ --8<---------------cut here---------------start------------->8--- Occhio all’email in giudizio Cosa devo fare per far valere in giudizio il mio diritto, se l’unica prova che ho è un’email? Spesso ci si trova in giudizio a discutere della validità di una comunicazione elettronica semplice. Ma se siamo in giudizio, è troppo tardi per pensarci, e la validità in questione dipende spesso dalle circostanze e dalle prove a corredo. Meglio pensarci prima, possibilmente, ma questo non avverrà mai. --8<---------------cut here---------------end--------------->8--- Anche io, diciamo "per non saper ne leggere ne scrivere", uso la PEC per le comunicazioni che voglio FACILMENTE poter usare legalmente… però non è che il resto finisce in un buco nero come se nulla fosse mai stato detto. In particolare, io delle mie email tengo archivio PERENNE con backup ridondato, oltre a firmarle GPG per poterne garantire il contenuto [1]. Saluti, Giovanni [1] delle mie ovviamente, ma di solito i miei messaggi contengono le parti essenziali del thread quindi OSEREI dire che l'intero thread "fa prova" :-D [...] -- Giovanni Biscuolo
Nulla, però sarebbe verificabile che è stata alterata ----- Blog: www.marcoscialdone.it Twitter: @marcoscialdone LinkedIn: www.linkedin.com/in/marcoscialdone
Il giorno 22 ago 2020, alle ore 10:12, Giovanni Biscuolo <giovanni@biscuolo.net> ha scritto:
Buongiorno Marco,
Marco Scialdone <marcoscialdone@gmail.com> writes:
[...]
Nel modello alternativo proposto, se disconosco di aver ricevuto una certa email da tizio, quali strumenti, legalmente vincolanti, ha tizio per dimostrare in giudizio in modo semplice ed immaginato che ho invece ricevuto quella comunicazione (anche se non l’ho letta)?
nell'email che citi, Giacomo e io stavamo FANTASTICANDO su un sistea di cestione e certificazione dell'identità distribuito, la questione "validità legale dell'email" per fortuna è un po' più semplice :-)
Questo articolo di Carlo Piana illustra gli scenari e fornisce una caso di realmente avvenuto.
(se altri giuristi o legali in lista volessero aggiungere elementi, anche a confutazione, sarebbe fantastico)
https://www.piana.eu/prova_email/
--8<---------------cut here---------------start------------->8---
Occhio all’email in giudizio
Cosa devo fare per far valere in giudizio il mio diritto, se l’unica prova che ho è un’email? Spesso ci si trova in giudizio a discutere della validità di una comunicazione elettronica semplice. Ma se siamo in giudizio, è troppo tardi per pensarci, e la validità in questione dipende spesso dalle circostanze e dalle prove a corredo. Meglio pensarci prima, possibilmente, ma questo non avverrà mai.
--8<---------------cut here---------------end--------------->8---
Anche io, diciamo "per non saper ne leggere ne scrivere", uso la PEC per le comunicazioni che voglio FACILMENTE poter usare legalmente… però non è che il resto finisce in un buco nero come se nulla fosse mai stato detto. In particolare, io delle mie email tengo archivio PERENNE con backup ridondato, oltre a firmarle GPG per poterne garantire il contenuto [1].
Saluti, Giovanni
[1] delle mie ovviamente, ma di solito i miei messaggi contengono le parti essenziali del thread quindi OSEREI dire che l'intero thread "fa prova" :-D
[...]
-- Giovanni Biscuolo
On 21/08/2020 11:03, Giovanni Biscuolo wrote:
Per non parlare poi delle informazioni personali associate alle nostre identità, spesso*inglobate* nel sistema di identità digitale o analogico che sia.
SPID, by design, non lo ammette(va). ciao, s.
On 21/08/2020 11:03, Giovanni Biscuolo wrote:
Ciao Fabio,
una curiosità: come mai hai (avete, hanno?) deciso di arrivare fino al voto e non segnalare prima il baco a quelli di Rousseau?
Come dimostri una vulnerabilità se non tramite lo sviluppo di un PoC (Proof of Concept) ? Qui il PoC è dato dall'essere riusciti, data una stessa persona fisica validata 2 volte con gli stessi documenti, ad esprimere 2 voti, e non tanto dalla modalità tecnica con cui ci si è riusciti. Mi sentirei confidente nella possibilità di riuscire a fare altre 2 iscrizioni, sempre con documento validato, individuando e sfruttando bug di tipo logico-procedurale più che tecnologico, magari più avanti ci si riprova! Quel che importa è la sensibilizzazione e comunicazione sul tema delle debolezze e fragilità del voto elettronico, considerando il lavoro svolto da Giuseppe Brescia (M5S, Presidente Commissione Affari Costituzionali) per portare questo rischio democratico a livello istituzionale https://www.giuseppebrescia.it/tag/voto-elettronico/ . Fabio
"Fabio Pietrosanti (naif)" <lists@infosecurity.ch> writes:
On 21/08/2020 11:03, Giovanni Biscuolo wrote:
Ciao Fabio,
una curiosità: come mai hai (avete, hanno?) deciso di arrivare fino al voto e non segnalare prima il baco a quelli di Rousseau?
Come dimostri una vulnerabilità se non tramite lo sviluppo di un PoC (Proof of Concept) ?
Penso che la vulnerabilità fosse già dimostrata con la duplice registrazione sulla piattaforma, il voto doppio è una naturale evoluzione. Non sto criticando l'operazione, era pura curiosità. [...]
Quel che importa è la sensibilizzazione e comunicazione sul tema delle debolezze e fragilità del voto elettronico
e anche dell'identità digitale? :-) [...] Grazie, Giovanni -- Giovanni Biscuolo
Il 19/08/20 20:26, Fabio Pietrosanti (naif) ha scritto:
In merito al tema sicurezza del voto elettronico e relative garanzie per la democrazia segnalo l'inchiesta pubblicata oggi:
"Come sono riuscito a votare due volte su Rousseau" https://www.wired.it/attualita/politica/2020/08/19/rousseau-voto-piattaforma...
E successiva e immediata risposta intimidatoria della Associazione Rousseau:
https://www.ilblogdellestelle.it/2020/08/chi-truffa-rousseau-viene-denunciat...
Aggiornamento: (non mi pare sia passato in lista): https://www.wired.it/attualita/politica/2020/10/23/rousseau-espulsione-iscri... rob
participants (7)
-
Fabio Pietrosanti (naif) -
Giacomo Tesio -
Giovanni Biscuolo -
Marco Scialdone -
Roberto Resoli -
Stefano Quintarelli -
Stefano Zacchiroli