October 2021 - nexa - server-nexa.polito.it

Re: [nexa] sistema DCG compromesso? (was Re: https://attivissimo.blogspot...)

by Roberto Resoli

Il 30 ottobre 2021 11:19:17 CEST, Giacomo Tesio <giacomo(a)tesio.it> ha scritto: >Ciao Roberto, > >purtroppo in questo periodo non ho proprio tempo di approfondire la questione. > >Solo una nota: > >On October 30, 2021 6:25:27 AM UTC, Roberto Resoli wrote: >> Notare che oltre alla chiave macedone (MK) altre chiavi sono state rinnovate >> in questi ultimi giorni ... > >Perché sostituirle se non sono state compromesse? Perchè al momento pare è l'unico modo per togliere valdità a livello sovranazionale ai DGC emessi con quelle chiavi. >Vi propongo una ipotesi: le applicazioni di firma erano buggate e selezionavano k [1] >in modo predicibile o peggio costante. Mi sentirei di escluderlo, come anche di escludere "l'ipotesi dell'anteprima" di M. G. Flora, mi sembra veramente troppo ... rob > >[1] https://en.wikipedia.org/wiki/Elliptic_Curve_Digital_Signature_Algorithm#Si… > >[2] https://www.theregister.co.uk/2013/08/12/android_bug_batters_bitcoin_wallet…

Oct. 30, 2021

Re: [nexa] sistema DCG comromesso? (was Re: https://attivissimo.blogspot...)

by Roberto Resoli

Il 28 ottobre 2021 11:45:42 CEST, "380°" <g380(a)biscuolo.net> ha scritto: >Buongiorno nexiane, > ... >> 2) In alcuni contesti le chiavi di firma possono essere usate senza >> lasciare traccia in un log o altro, altrimenti gli operatori sarebbero >> già stati scoperti (non è così, sono apparsi pass validi di Mickey Mouse >> e Sponge Bob in queste ultime ore). Questa è una incredibile falla in >> tutto il sistema, > >ben detto Roberto: possibile che non ci siano i log relativi >all'emissione di "green pass"?!? ...magari ci sono eh, solo non lo >sappiamo noi. https://github.com/eu-digital-green-certificates/dgca-issuance-web/pull/116… >> che si basa sulla fiducia e sul controllo che la stessa sia fondata > >OK ma mancanza dei log a parte (cioè: in un sistema serio la >tracciabilità deve essere garantita), qualunque sistema si basa in ogni >caso sulla fiducia, il punto è saperla gestire bene (e il fattore umano >è fondamentale in questo, non c'è tecnica che tenga) > >[...] Ma certo. Però almeno un audit trail sugli utilizzi delle chiavi ci vorrebbe no? Fermo restando che se esponi il sistema sul web (MK) e magari lasci file htpasswd dell' implementazione di riferimento, nemmeno quello aiuta. ... >> 3) Non mi è chiaro come sia stato possibile invalidare alcuni pass >> farlocchi emessi in questi giorni senza ritirare le relative chiavi, >> invalidando così anche una moltiitudine di pass legittimi. Esiste la >> possibilità di mettere in blacklist singoli pass? > >non l'ho ancora capito esattamente perché il thread è lunghissimo, ma se >n'è discusso qui: >https://github.com/ministero-salute/it-dgc-verificaC19-android/issues/103 > >qualcuno riesce a capire /tecnicamente/ come funziona la revoca di >/singoli/ "green pass" in Italia? > >Stefano Zanero e Matteo Flora, nel Agosto 2021 dicevano [4] che l'app >non ha (aveva?) questa funzione, anche e soprattutto per problemi di >privacy: è così? È così al momento per l'app italiana. Non esiste sistema di revoca per i GP, si può solo ritirare il cert di firma (DSC); cosa avvenuta per i fasulli emessi dal sistema macedone. Notare che i fasulli emessi con chiavi tedesche, francesi e polacche per C19 sono tornati validi. Pare che l'app francese invece abbia un sistema di blacklisting. Un vincolo forte è che l'app di verfica debba solo scaricare, non inviare dati, per evitare alla radice tracciamenti delle persone. >L'allegato B paragrafo 2 del DPCM "Green Pass" [5] sostiene invece che >esiste una lista di revoca (di un "green pass") e che tale lista è >oggetto di scambio con gli altri paesi EU. Esiste solo per i DSC, i certificati di firma, non per i DGC stessi. Ogni DSC copre anche milioni di DGC. Dipende dalla numerosità dei DSC, l'Italia ne ha 1 (uno), la Germania 57. Ma anche per la Germania invalidare un DSC significa invalidare milioni di DGC. >Pare che anche in Francia ci sia un decreto del 30 Settembre [6] che >preveda l'utilizzo di una lista di revoca: «So yes, there are places >where local mechanisms exist to revoke certificates and generate new >ones.» [6] Si, da indagare cosa faccia l'app francese, che sembra aver tolto valdità a tutti i DGC farlocchi. .. >[6] https://github.com/ehn-dcc-development/hcert-spec/issues/103#issuecomment-9… Trasformato in discussione: https://github.com/ehn-dcc-development/hcert-spec/discussions/105 Sembra al momento la fonte migliore di informazioni. rob

Oct. 30, 2021

Re: [nexa] sistema DCG compromesso? (was Re: https://attivissimo.blogspot...)

by Giacomo Tesio

Ciao Roberto, purtroppo in questo periodo non ho proprio tempo di approfondire la questione. Solo una nota: On October 30, 2021 6:25:27 AM UTC, Roberto Resoli wrote: > Notare che oltre alla chiave macedone (MK) altre chiavi sono state rinnovate > in questi ultimi giorni ... Perché sostituirle se non sono state compromesse? Vi propongo una ipotesi: le applicazioni di firma erano buggate e selezionavano k [1] in modo predicibile o peggio costante. k deve essere impredicibile e diverso ad ogni firma, perché da due firme generate con lo stesso k è possibile calcolare la chiave privata. Immaginiamo un attaccante che osservi come lo stesso json produce la stessa firma tutte le volte: a quel punto sa che c'è un errore nell'implementazione ed è probabile che sia proprio relativo a k. Le applicazioni di firma esposte poi, erano soggette a timing attacks sempre relative a k. Ad esempio, si potrebbe far firmare lo stesso JSON migliaia volte, misurando il tempo della risposta e clusterizzando i risultati ottenuti per tale tempo, ottenendo una serie di firme con una probabilità più elevata di condividere lo stesso k. (Un attacco che non dovrebbe passare inosservato a posteriori analizzando i log, in particolare perché, dovendo ridurre il rumore, gli attaccanti sceglierebbero orari di basso carico). Naturalmente sono solo ipotesi. Non sono però ipotesi del tutto teoriche o da "armageddon crittografico": è già successo in passato [2]. E d'altro canto, perché sostituire le chiavi, in un momento in cui la credibilità del sistema è in discussione se non si hanno concrete ragioni per ritenerle compromesse? Giacomo [1] https://en.wikipedia.org/wiki/Elliptic_Curve_Digital_Signature_Algorithm#Si… [2] https://www.theregister.co.uk/2013/08/12/android_bug_batters_bitcoin_wallet…

Oct. 30, 2021

Re: [nexa] sistema DCG compromesso? (was Re: https://attivissimo.blogspot...)

by Roberto Resoli

Il 30 ottobre 2021 10:35:39 CEST, Antonio Iacono <antiac(a)gmail.com> ha scritto: >> A quanto pare si tratta banalmente di una serie di server macedoni esposti. > >Sono d'accordo ma vorrei comunque continuare a puntare i riflettori >sulle chiavi. ... >Siamo nel 2021, è possibile sapere se le chiavi private usate per i GP >sono all'interno >di un apparato elettronico (HSM, smart card, ecc.) o su un banale file? Sezione 6.2 (Key Management) di https://ec.europa.eu/health/sites/default/files/ehealth/docs/digital-green-… Ma sono solo raccomandazioni, non vincoli! Il sistema della Firma Elettronica è stato ben meditato, DGC è stato messo su in fretta e furia, e senza analisi sulle problematiche di sicurezza ... Lo notava Carmela Troncoso già nell'aprile scorso rob

Oct. 30, 2021

Re: [nexa] sistema DCG compromesso? (was Re: https://attivissimo.blogspot...)

by Antonio Iacono

> A quanto pare si tratta banalmente di una serie di server macedoni esposti. Sono d'accordo ma vorrei comunque continuare a puntare i riflettori sulle chiavi. "Le chiavi private sono conservate e custodite all’interno di un dispositivo di firma, ovvero di un apparato elettronico programmabile solo all’origine in grado di conservare in modo protetto le chiavi private e generare al suo interno firme digitali" Sono frasi scritte nel DPCM 8 febbraio 1999 !!! Siamo nel 2021, è possibile sapere se le chiavi private usate per i GP sono all'interno di un apparato elettronico (HSM, smart card, ecc.) o su un banale file? Antonio

Oct. 30, 2021

Re: [nexa] sistema DCG compromesso? (was Re: https://attivissimo.blogspot...)

by Roberto Resoli

Il 30 ottobre 2021 00:32:32 CEST, "380°" <g380(a)biscuolo.net> ha scritto: >Alberto Cammozzo via nexa <nexa(a)server-nexa.polito.it> writes: > >> A quanto pare si tratta banalmente di una serie di server macedoni esposti. >> >> <https://twitter.com/Xiloeee/status/1453493664806735876?t=OjZOX0kWM7opO1tvkY…> >> >> Se avessi modo di aprire RSA2048 non mi gingillerei con i GP. > >A quanto ne capisco guardando l'elenco disponibile qui: >https://dgcg.covidbevis.se/tp/ > >le chiavi sono EC P-256, non RSA2048: sbaglio? Si, ECDSA è l'algoritmo scelto per motivi di robustezza e compattezza. Il risultato finale deve essere tradotto in QR di dimensioni ragionevoli. Una fonte piú pratica dell'elenco (per chi ama la command line) è la lista tedesca: https://de.dscg.ubirch.com/trustList/DSC/ basta togliere la firma alla prima riga e si ottiene un json valido. Notare che oltre alla chiave macedone (MK) altre chiavi sono state rinnovate in questi ultimi giorni ... rob

Oct. 30, 2021

Re: [nexa] sistema DCG compromesso? (was Re: https://attivissimo.blogspot...)

by 380°

Alberto Cammozzo via nexa <nexa(a)server-nexa.polito.it> writes: > A quanto pare si tratta banalmente di una serie di server macedoni esposti. > > <https://twitter.com/Xiloeee/status/1453493664806735876?t=OjZOX0kWM7opO1tvkY…> > > Se avessi modo di aprire RSA2048 non mi gingillerei con i GP. A quanto ne capisco guardando l'elenco disponibile qui: https://dgcg.covidbevis.se/tp/ le chiavi sono EC P-256, non RSA2048: sbaglio? Saluti, 380° -- 380° (Giovanni Biscuolo public alter ego) «Noi, incompetenti come siamo, non abbiamo alcun titolo per suggerire alcunché» Disinformation flourishes because many people care deeply about injustice but very few check the facts. Ask me about <https://stallmansupport.org>.

Oct. 29, 2021

Re: [nexa] sistema DCG compromesso? (was Re: https://attivissimo.blogspot...)

by 380°

Buonasera Antonio e nexiane oggi non ho avuto modo di seguire nessun thread o issue in merito quindi potrei essermi perso qualcosa di importante, ma fino a questa mattina tutti gli indizi portano a credere che la cosa più probabile che sia successa è che abbiano "bucato" il servizio di emissione GP... sarebbe comunque piuttosto grave dal punto di vista della sicurezza (report ufficiali?!?!?) ma nulla rispetto allo scenario "armageddon", cioè lo scenario 1 descritto da Antionio. Antonio Iacono <antiac(a)gmail.com> writes: [...] > Scenari: > 1) Chiave privata calcolata. Probabilità remotissima, vorrebbe dire > che qualcuno ha trovato un algoritmo per risolvere velocemente il > problema del logaritmo discreto o della fattorizzazione di numeri > primi. [...] Mio **cuggino** mi ha detto che l'altro ieri in una bisca ha sentito di nascosto un tizio losco che sussurrava all'amico che sotto sotto alcune implementazioni degli algoritmi crittografici sono taroccate... pensa te che leggende metropolitane circolano eh!?! :-O Vi lascio con una favola della buonanotte intitolata «Why I don’t Trust NIST P-256», in cui si racconta la famosissima vicenda di Alice e Bob che vogliono scambiarsi un segreto... ma poi si scopre che ci sono anche Eve, Jerry, John, Jim e altri personaggi minori. https://web.archive.org/web/20210410002501/https://credelius.com/credelius/… --8<---------------cut here---------------start------------->8--- consider the fact that the method how EC parameters have been selected is not quite clear. To be more exact, it was not clear how a seed has been chosen to generate a curve parameter. It means that a statement about P-256 being “verifiable random” is simply not true and a D. J. Bernstein’s note in a TLS WG discussion confirms that and provides a hint about Jerry’s employer involvement in this case as well. The common suspicion here is that Jerry has tried many of them until found a weak EC curve that can be exploited in the same way as in Dual_EC_DRBG case. Since there is an opinion that there might be a “spectral weakness” in ECC (check also this), that suspicion seems quite plausible. “Spectral weakness” means that there is a uniform (?) distribution of weak EC curves that can be eventually found through enumeration in a reasonable time interval. --8<---------------cut here---------------end--------------->8--- Ma è una favola eh! Buona notte. 380° P.S.: see also http://safecurves.cr.yp.to/rigid.html -- 380° (Giovanni Biscuolo public alter ego) «Noi, incompetenti come siamo, non abbiamo alcun titolo per suggerire alcunché» Disinformation flourishes because many people care deeply about injustice but very few check the facts. Ask me about <https://stallmansupport.org>.

Oct. 29, 2021

Re: [nexa] sistema DCG compromesso? (was Re: https://attivissimo.blogspot...)

by Alberto Cammozzo

A quanto pare si tratta banalmente di una serie di server macedoni esposti. <https://twitter.com/Xiloeee/status/1453493664806735876?t=OjZOX0kWM7opO1tvkY…> Se avessi modo di aprire RSA2048 non mi gingillerei con i GP. ciao, A On 29/10/21 15:48, Antonio Iacono wrote: > ... >> Rimaniamo in trepida attesa di una relazione UFFICIALE delle autorità >> preposte, altrimenti... ci arrabbiamo :-D > Nel frattempo la notizia ha varcato l'oceano [1] > I non tecnici si staranno chiedendo perché tutta questa enfasi, > concitazione ... paura. E che sarà mai, nella vita "reale" di chiavi > se ne perdono ogni giorno. > Il motivo è che ormai (con un'escalation negli ultimi dieci anni) > quasi tutto il mondo digitale è legato, mani e piedi, alla > crittografia asimmetrica (chiave privata / chiave pubblica). > > Scenari: > 1) Chiave privata calcolata. Probabilità remotissima, vorrebbe dire > che qualcuno ha trovato un algoritmo per risolvere velocemente il > problema del logaritmo discreto o della fattorizzazione di numeri > primi. Oppure si è costruito in garage un computer quantistico. In > quel caso verrebbe giù di colpo il mondo digitale. > > 2) Chiave privata "rubata". Probabilità remota. Per rubare qualcosa > bisogna che esista, la chiave privata ormai (da una ventina d'anni) è > dentro smart card e HSM, di fatto "non leggibile", non > copia/incollabile, ecc. > > Alla luce di questi scenari, mi chiedo, perché dalla lista dei > certificati è stato, appena ieri, cancellato e riemesso quello della > Macedonia del Nord? > > Antonio > > [1] > https://threatpost.com/eus-green-pass-vaccination-id-private-key-leaked/175… > _______________________________________________ > nexa mailing list > nexa(a)server-nexa.polito.it > https://server-nexa.polito.it/cgi-bin/mailman/listinfo/nexa

Oct. 29, 2021

Re: [nexa] nexa Digest, Vol 150, Issue 64

by Alberto Cammozzo

Bella domanda. Mi dico che l'UE nasce attorno ad un mercato, e il mercato deve essere aperto e non protetto, per cui Palantir, anche se partecipa per far la spia al governo americano, deve avere il diritto di entrare nel consorzio fatto per competere con gli americani. Mi pare così assurdo. Per favore non diciamo più che "le ideologie sono morte", diciamo piuttosto che le /altre/ ideologie sono morte e che l'unica sopravvissuta è quella neoliberale, che viene applicata in purezza in UE, mentre negli USA, dove questa è nata, i mercati sono invece ben protetti. Ma per riconoscere che una ideologia è tale occorre almeno un'altra ideologia cui contrapporla, tuttavia non vedo candidate. Alberto On 29/10/21 14:11, maurizio lana wrote: > > > Il 29/10/21 12:00, J.C. DE MARTIN ha scritto: >> *Inside Gaia-X: How chaos and infighting are killing Europe’s grand >> cloud project* >> /The initiative, meant to boost Europe’s cloud services, is failing >> to fix the problems is was intended to solve./ >> By Clothilde Goujard and Laurens Cerulus > il 9 febbraio scorso io scrivevo a questa mailing list: >> a proposito di cloud e sovranità/indipendenza, uno di primi partner di >> GAIA-X, il consorzio per il nascente cloud europeo, è Palantir >> https://ilmanifesto.it/gli-spioni-di-palantir-entrano-nei-dati-europei-di-g… >> >> >> Palantir è un'azienda statunitense: perché prendere un partner >> statunitense nel consorzio se esso deve esprimere la >> sovranità/indipendenza del cloud europeo? > Maurizio > > _______________________________________________ > nexa mailing list > nexa(a)server-nexa.polito.it > https://server-nexa.polito.it/cgi-bin/mailman/listinfo/nexa

Oct. 29, 2021