October 2020 - nexa - server-nexa.polito.it

Re: [nexa] Ten Commandments of the Small Internet

by Giovanni Biscuolo

Giovanni Biscuolo <giovanni(a)biscuolo.net> writes: > Care nexiane, > > non pensiate che "Small Internet" non vi riguardi: vi riguarda eccome! Che poi, ci ho riflettuto dopo, il titolo dovrebbe essere "...Small Web" (come se tutto su internet fosse web :-( ). Fatta questa tara l'articolo dice cose molto interessanti... sul *web* :-D Saluti, Giovanni. P.S.: e sì, prima o poi andrà sistemato anche quello che sta _sotto_ il web. [...] -- Giovanni Biscuolo

Oct. 22, 2020

Re: [nexa] Libreoffice e verifica validità della firma elettronica: una jungla?

by Roberto Resoli

Il 22/10/20 11:53, Giovanni Biscuolo ha scritto: > Ciao Roberto, > > Roberto Resoli <roberto(a)resolutions.it> writes: > >> Il 21/10/20 19:13, Giovanni Biscuolo ha scritto: > > [...] > >>> Scusa se ne approfitto, ma qual'è la ratio che ha portato il legislatore >>> a differenziare tra "firma semplice" e "firma qualificata"? Siccome dal >>> punto di vista tecnico sempre di certificati X.509 si tratta, ho come >>> l'impressione che la distinzione sia puramente >>> burocratico-certificatoria: vorrei tanto essere smentito. >> >> Non direi. E' il grado diverso di forza probatoria, a sua volta >> dipendente sia dalle tecnologie utilizzate che dal soggetto che attesta >> l'identità del firmatario. > > Non ho capito in cosa sia tecnologicamente inferiore il certificato > X.509 della "firma semplice" rispetto a quello della "firma > qualificata", ovviamente a parità di soggetto attestante (tutti i > sggetti sono approvati dall'autorità pubblica). In nulla, dal punto di vista tecnologico. Dal punto di vista di chi emette il certificato, invece, si tratta di certificati emessi con scopi diversi, cito dal precedente messaggio: >> La differenza tra >> le due coppie di chiavi è dovuta al fatto che si ritiene inopportuno per >> evitare attacchi crittografici utilizzare la stessa coppia di chiavi per >> la firma di documenti (Non Repudiation), e per quantità generate >> automaticamente (all'interno di un protocollo di comunicazione come TLS, >> ad esempio) (Digital Signature). Come conseguenza, le due root CA in cima alla catena dei due certificati sono diverse. E la "Infocert Servizi di Certificazione ...", ad esempio, *non* è tra quelle di firma Qualificata (non è esposta come tale nella TSL italiana). > Però la cosa si sta facendo molto tecnica: mi fido del tuo giudizio se > mi dici che differenziare "fa senso". vedi sopra. >> La normativa in merito è raccolta principalmente nel regolamento europeo >> eIDAS[1], entrato in vigore nel 2016. >> >> All'Art.25, comma 2 (scusa il burocratese) si legge: >> >> 2. A qualified electronic signature shall have the equivalent legal >> effect of a handwritten signature. > > Ecco appunto: distinzione *puramente* de jure, la distinzione tecnica > tra un X.509 "qualificato" e uno "semplice" mi sfugge, CA certificate > usato a parte. La differnza è negli scopi di utilizzo delle chiavi, e si sostanzia nella CA utilizzata per l'emissione. > [...] > >> Ahimè, non avrei creduto di essere ancora qui a parlarne dopo ben più di >> 10 anni ... > > É da 15 anni che il solo e UNICO problema che ho con l'utilizzo del > software libero è quello che mi viene impedito di usare l'hardware (per > mezzo dei "driver" proprietari). Ogni volta che voglio usare un > dispositivo - dalla scheda video allo scanner - devo faticare come un > forsennato per trovare quello che funziona con il kernel Linux mainline > e il software user space per dialogare con il dispositivo. > > Sono esausto. E io faccio il sistemista da anni, per lavoro. ... sfondi portoni spalancati ... :(( > [...] > >> Come in TLS, insomma. > > Sì mi era chiaro grazie. > > [...] > >> Per quanto ne so, nessun fornitore italiano supporta IAS-ECC per i >> dispositivi di firma, anche perchè nessuno gli l'ha chiesto. > > Mavà?!? Sono solo io che noto l'ormai insopportabile e insostenibile > leggerezza del Codice dell'Amministrazione Digitale? > > La soluzione tecnica c'è, basterebbero tre righe in un DPCM :-O Eh sì ... ma non ci sono queste righe, e intanto girano milioni di dispositivi non interoperabili. >> Dovrebbe essere IAS-ECC la nostra CIE, che però non ha certificati di >> firma a bordo. > > Quindi per poter apporre una "firma qualificata" come desidero io dovrei > chiedere asilo politico alla Francia? :-) Non sono aggiornato. Ma ai miei tempi sarebbe stato meglio Finlandia o Estonia. Ah, tra l'altro attualmente è possibile chiedere la e-residenza in Estonia, ricevendo la relativa carta d'identità: https://e-resident.gov.ee/become-an-e-resident/ Naturalmente dovresti poi convincere chi riceve il tuo documento che la firma fatta con la carta estone è valida (lo è). >>>> dato che da noi è invalsa l'abitudine di annegare chiavi simmetriche >>>> 3DES nel binario dell'applicazione per crittare il colloquio tra token >>>> e terminale (Secure Messaging). >>> >>> ...e a che pro? Per evitare un attacco MITM tra il token e il terminale? >> >> Esatto, nessuna ironia. > > Oh mamma. Se ho capito bene, siccome il solo e unico mezzo de > facto per connettere il token al terminale (il mio computer) è l'USB, > l'unico vettore di attacco per un MITM (escludendo me ovviamente) è il > sistema operativo e per proteggere la comunicazione tra token e computer > da possibile malware si usa un canale simil-TLS? > > Ho capito bene o mi sfugge qualcosa? Hai capito bene, ma la normativa astrae dal tipo di canale. Ad esempio ci sono soluzioni che remotizzano l'accesso al dispositivo. >>> Ironia a parte: tu che ne pensi? >> >> Che dopo 15 anni siamo ancora qui a parlarne. > > E saremo qui ancora a parlarne tra 10 anni, magari non proprio dei token > per la firma di altro hardware. Probabilmente sì, anche se credo che nel mondo attuale, invece di permetter l'accesso paritario all'hardware, semplicemente si elimini l'hardware (vedi firma remota), aumentando enormemente il lock-in. > [...] > >> Tra parentesi ho messo esattamente i due flag dell'attributo KeyUsage >> che distinguono i due certificati. >> >> Nella normativa tecnica italiana si prescriveva che le chiavi per firma >> riportassero nel certificato corrispondente l'attributo KeyUsage marcato >> critico con il solo flag "nonRepudiation". Non so se sia ancora così. > > OK, non ne so abbastanza di X.509... uff Basta che apri un qualsiasi certificato ssl, anche dal browser, e trovi tutto. > [...] > >>>> PS: pur aggiungendo la libreria pkcs11 proprietaria corretta sono >>>> riuscito a firmare in libo solo con le chiavi di Autenticazione, mentre >>>> con quelle di sottoscrizione il programma si blocca. >>> >>> La butto lì: incompatibilità ABI?!? >> >> Non saprei, devo indagare. Forse Antonio ne sa di più. Proverò a >> chiedere anche a Giuseppe Castagno che è il guru di LibO. > > In bocca al lupo su questa cosa! > > Per quanto mi riguarda, installare un driver proprietario o l'intero > DIKE proprietario non fa differenza: se sarò costretto farò così, subirò > protestando (al vento, perché con chi protesto?!?) come in tante altre > cose. Ti ho scritto in privato su questo, per non appesantire troppo la lista. Di fatto ti basta solo la libreria PKCS11, per il resto puoi usare sw libero. Questo è il massimo che si possa fare, con il token che hai in mano, al momento. Ciao, rob > Saluti, Giovanni. > > > >> [1] >> https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=uriserv:OJ.L_.2014.257.… >> >> [2] https://github.com/OpenSC/OpenSC/wiki/IAS-ECC

Oct. 22, 2020

Re: [nexa] Libreoffice e verifica validità della firma elettronica: una jungla?

by Giovanni Biscuolo

Ciao Roberto, Roberto Resoli <roberto(a)resolutions.it> writes: > Il 21/10/20 19:13, Giovanni Biscuolo ha scritto: [...] >> Scusa se ne approfitto, ma qual'è la ratio che ha portato il legislatore >> a differenziare tra "firma semplice" e "firma qualificata"? Siccome dal >> punto di vista tecnico sempre di certificati X.509 si tratta, ho come >> l'impressione che la distinzione sia puramente >> burocratico-certificatoria: vorrei tanto essere smentito. > > Non direi. E' il grado diverso di forza probatoria, a sua volta > dipendente sia dalle tecnologie utilizzate che dal soggetto che attesta > l'identità del firmatario. Non ho capito in cosa sia tecnologicamente inferiore il certificato X.509 della "firma semplice" rispetto a quello della "firma qualificata", ovviamente a parità di soggetto attestante (tutti i sggetti sono approvati dall'autorità pubblica). Però la cosa si sta facendo molto tecnica: mi fido del tuo giudizio se mi dici che differenziare "fa senso". > La normativa in merito è raccolta principalmente nel regolamento europeo > eIDAS[1], entrato in vigore nel 2016. > > All'Art.25, comma 2 (scusa il burocratese) si legge: > > 2. A qualified electronic signature shall have the equivalent legal > effect of a handwritten signature. Ecco appunto: distinzione *puramente* de jure, la distinzione tecnica tra un X.509 "qualificato" e uno "semplice" mi sfugge, CA certificate usato a parte. [...] > Ahimè, non avrei creduto di essere ancora qui a parlarne dopo ben più di > 10 anni ... É da 15 anni che il solo e UNICO problema che ho con l'utilizzo del software libero è quello che mi viene impedito di usare l'hardware (per mezzo dei "driver" proprietari). Ogni volta che voglio usare un dispositivo - dalla scheda video allo scanner - devo faticare come un forsennato per trovare quello che funziona con il kernel Linux mainline e il software user space per dialogare con il dispositivo. Sono esausto. E io faccio il sistemista da anni, per lavoro. [...] > Come in TLS, insomma. Sì mi era chiaro grazie. [...] > Per quanto ne so, nessun fornitore italiano supporta IAS-ECC per i > dispositivi di firma, anche perchè nessuno gli l'ha chiesto. Mavà?!? Sono solo io che noto l'ormai insopportabile e insostenibile leggerezza del Codice dell'Amministrazione Digitale? La soluzione tecnica c'è, basterebbero tre righe in un DPCM :-O > Dovrebbe essere IAS-ECC la nostra CIE, che però non ha certificati di > firma a bordo. Quindi per poter apporre una "firma qualificata" come desidero io dovrei chiedere asilo politico alla Francia? >>> dato che da noi è invalsa l'abitudine di annegare chiavi simmetriche >>> 3DES nel binario dell'applicazione per crittare il colloquio tra token >>> e terminale (Secure Messaging). >> >> ...e a che pro? Per evitare un attacco MITM tra il token e il terminale? > > Esatto, nessuna ironia. Oh mamma. Se ho capito bene, siccome il solo e unico mezzo de facto per connettere il token al terminale (il mio computer) è l'USB, l'unico vettore di attacco per un MITM (escludendo me ovviamente) è il sistema operativo e per proteggere la comunicazione tra token e computer da possibile malware si usa un canale simil-TLS? Ho capito bene o mi sfugge qualcosa? >> Ironia a parte: tu che ne pensi? > > Che dopo 15 anni siamo ancora qui a parlarne. E saremo qui ancora a parlarne tra 10 anni, magari non proprio dei token per la firma di altro hardware. [...] > Tra parentesi ho messo esattamente i due flag dell'attributo KeyUsage > che distinguono i due certificati. > > Nella normativa tecnica italiana si prescriveva che le chiavi per firma > riportassero nel certificato corrispondente l'attributo KeyUsage marcato > critico con il solo flag "nonRepudiation". Non so se sia ancora così. OK, non ne so abbastanza di X.509... uff [...] >>> PS: pur aggiungendo la libreria pkcs11 proprietaria corretta sono >>> riuscito a firmare in libo solo con le chiavi di Autenticazione, mentre >>> con quelle di sottoscrizione il programma si blocca. >> >> La butto lì: incompatibilità ABI?!? > > Non saprei, devo indagare. Forse Antonio ne sa di più. Proverò a > chiedere anche a Giuseppe Castagno che è il guru di LibO. In bocca al lupo su questa cosa! Per quanto mi riguarda, installare un driver proprietario o l'intero DIKE proprietario non fa differenza: se sarò costretto farò così, subirò protestando (al vento, perché con chi protesto?!?) come in tante altre cose. Saluti, Giovanni. > [1] > https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=uriserv:OJ.L_.2014.257.… > > [2] https://github.com/OpenSC/OpenSC/wiki/IAS-ECC -- Giovanni Biscuolo

Oct. 22, 2020

PayPal allows Bitcoin and crypto spending

by gianlucaquaglia＠gmail.com

PayPal allows Bitcoin and crypto spending PayPal has entered the cryptocurrency market, announcing that its customers will be able to buy and sell Bitcoin and other virtual currencies using their PayPal accounts. Those virtual coins could then be used to buy things from the 26 million sellers which accept PayPal, it said. PayPal plans to roll out buying options in the US over the next few weeks, with the full rollout due early next year. Bitcoin prices rose alongside the news, breaking the $12,000 (£9,170) mark. The other cryptocurrencies to be added first will be Ethereum, Litecoin, and Bitcoin Cash (a spin-off from Bitcoin). All could be stored "directly within the PayPal digital wallet", the company said. [...] continua qui https://www.bbc.com/news/technology-54630283

Oct. 22, 2020

Re: [nexa] Ten Commandments of the Small Internet

by Giovanni Biscuolo

Care nexiane, non pensiate che "Small Internet" non vi riguardi: vi riguarda eccome! Antonio Iacono <antiac(a)gmail.com> writes: [...] > Stavolta vorrei segnalare un altro movimento, ancora più recente, che > si è creato attorno ad un progetto "Small Internet" [2] https://cheapskatesguide.org/articles/small-internet.html/ Bell'articolo grazie. Mi vien da dire che siccome il web è un terreno di caccia, questi risultati sono quasi scontati. É ormai ovvio che i proprietari delle pagine web usano questa tecnica per raccogliere il maggior numero possibile di informazioni dai loro "visitatori" (la caccia), infischiandosene completamente delle risorse che loro _sprecano_ e delle implicazioni sulla privacy (col tracking) e sulla sicurezza (coi Javascript) implicano. Purtroppo c'è anche una discreta fetta di proprietari di siti che si affidano a sviluppatori che ignorano questa classe di problemi e per moda e/o pigrizia usano librerie Javascript quando potrebbero (dovrebbero) benissimo farne a meno. Il primo comandamento della "Small Internet", ovvero «Lotta per fare agli altri ciò che vorresti fosse fatto a te» dovrebbe essere un faro (anche) per tutti gli altri aspetti della tecnologia digitale. Quelle dell'articolo citato sono tante idee ingenue, per dirla alla Luciano Floridi, ma per le quali vale la pena lottare. C'è molta "cittadinanza digitale" in questo articolo :-D [...] Saluti, Giovanni P.S.: è interessantissimo l'accenno di analisi del fatto che sia necessario un nuovo protocollo come Gemini piuttosto che un uso consapevole di HTML, *credo* che solo apparentemente quello sia un dettaglio. -- Giovanni Biscuolo

Oct. 22, 2020

Re: [nexa] European Commission Open source software strategy 2020-2023

by Roberto Resoli

Il 22/10/20 08:36, Fabio Pietrosanti (naif) ha scritto: > E’ stata pubblicata la European Commission Open source software strategy > 2020-2023 > https://ec.europa.eu/info/departments/informatics/open-source-software-stra… Grazie, leggo subito > Sarebbe certamente interessante per gli interessati e appassionati: > > 1. Effettuarne una traduzione in Italiano Vale la pena? Probabilmente verranno fatte traduzioni in tutte le lingue dell'Unione. Se hai motivo di pensare che non sarà così, posso candidarmi. > 2. Effettuare una riflessione comparata rispetto agli elementi > equivalenti nel piano triennale Agid Indubbiamente. rob

Oct. 22, 2020

Re: [nexa] Flamethrowers and Fire Extinguishers – a review of “The Social Dilemma”

by Roberto Resoli

Il 21/10/20 13:45, Roberto Resoli ha scritto: > Il 21/10/20 11:52, Antonio Iacono ha scritto: >> Torno sull'argomento per segnalarvi un articolo (sotto le conclusioni) >> e un incontro online di un gruppo di lavoro che stasera dialogherà sul >> documentario. >> >> -https://librarianshipwreck.wordpress.com/2020/09/17/flamethrowers-and-fire-extinguishers-a-review-of-the-social-dilemma/ >> >> >> -https://twc-italia.org/events/12 >> >> Antonio > > Messo in agenda, grazie Antonio. Ringrazio ancora, è stata un'ottima occasione per conoscere i ragazzi di twc, una risorsa preziosa. rob

Oct. 22, 2020

Re: [nexa] Libreoffice e verifica validità della firma elettronica: una jungla?

by Roberto Resoli

Il 22/10/20 09:51, Roberto Resoli ha scritto: > Ahimè, non avrei creduto di essere ancora qui a parlarne dopo ben più di > 10 anni ... > > Se non ricordo male tutto nasce dalla normativa tecnica europea che > prescriveva per gli SSCD (Secure Signature Creation Devices), termine > per indicare i token di firma, un "secure path" e "secure channel" tra > dispositivo e applicazione. Detto in soldoni, i due endpoint devono > essere mutuamente identificati e il canale crittato. > > Come in TLS, insomma. > > Il modo più primitivo di fare questo è usare una chiave simmetrica e > cifrare il traffico (Secure Messaging) con quella. Ovviamente la chiave > deve essere presente da entrambi i lati. > > Dato che nessuno ha imposto che l'interoperabilità andasse garantita, il > lock-in era lì pronto per essere usato. > > Notare che fin dall'inizio anche nelle specifiche tecniche europee > esistevano tutti le indicazioni su come negoziare dinamicamente le > chiavi, come si fa in TLS. Con una certa fatica ho recuperato i dettagli (a volte il "Permanent Record" serve a qualcosa ...): http://opensc.1086184.n5.nabble.com/Secure-Messaging-td4174.html#a4175 rob

Oct. 22, 2020

Re: [nexa] Libreoffice e verifica validità della firma elettronica: una jungla?

by Roberto Resoli

Il 22/10/20 09:51, Roberto Resoli ha scritto: > Il 21/10/20 19:13, Giovanni Biscuolo ha scritto: >> Ciao Roberto, >> >> grazie per la pazienza... > grazie a te, sono molto interessato alla firma in LibO, anche perchè > qualche anno fa ho dato una mano al mio amico Giuseppe Castagno per questo: > > https://joinup.ec.europa.eu/solution/oooxadessignit > Per chi fosse interessato, qui si trova ancora la presentazione di Davide Dozza fatta al convegno OpenGood dell'ospedale Galliera di Genova nel 2011: https://www.galliera.it/opengood/presentazioni-pdf/05%20-%20Davide%20Dozza-… rob

Oct. 22, 2020

EU shoots for €10B ‘industrial cloud’ to rival US

by Alberto Cammozzo

<https://www.politico.eu/article/eu-pledges-e10-billion-to-power-up-industri…> BERLIN — The European Union aims to spend up to €10 billion over the next seven years to help build up a homegrown cloud computing sector that could rival foreign corporations such as Amazon, Google and Alibaba. Twenty-five EU countries signed a joint declaration Thursday pledging public money to power up the cloud sector and establishing the "European Alliance on Industrial Data and Cloud," a partnership geared toward facilitating such projects. The alliance — whose funding is to be drawn from existing EU programs and hoped-for pledges from industry and national capitals — will be launched by the end of the year. Cyprus and Denmark were the only EU member countries not to sign the declaration due to “technical reasons.” The declaration “is a foundation stone for the establishment of European cloud technology, which will be very high performing,” said Internal Market Commissioner Thierry Breton, following a meeting of European telecoms ministers organized by the German government, which currently holds the EU’s rotating Council presidency. “Contrary to the prejudices, we are not late [on cloud development]. We are the first to get involved in the industrial cloud,” he added. “EU governments and the public sector need to be fully committed to the initiative by fully shifting to cloud services” — Lise Fuhr, ETNO’s director general The cloud alliance is a key part of the European Commission’s data strategy, which aims to create a single market for industrial data. Commissioner Breton in particular has lobbied hard to make the EU a worldwide data hub, and to develop data processing capabilities that would give Europe an edge over foreign rivals that currently dominate the cloud business. It also fits in with broader efforts by European policymakers to make the Continent less dependent on foreign technology. Currently, U.S. technology firms dominate the global market for cloud storage. In the same vein, the bloc is set to unveil by December a rulebook for platforms dubbed the “Digital Services Act," as well as binding laws for artificial intelligence that are set to be released early next year. The new alliance will have the mandate to develop business, investment and implementation plans for European cloud technologies in the public and private sectors. Signatories also pledge to create common European standards and policy norms to create pan-European cloud services, and help small and medium-sized businesses, startups and the public sector embrace cloud technology. “In order to achieve digital sovereignty, we need to start approaching data processing the way major American and Chinese companies — the hyper-scalers — approach it,” said German Economy Minister Peter Altmaier. “This is an area where we’re far from being equals,” he added. Money, money, money The Commission’s plan is to invest up to €10 billion to develop Europe's cloud and data infrastructures. The EU’s executive arm would invest €2 billion from programs in its long-term budget such as the Digital Europe Programme, Connecting Europe Facility 2 and InvestEU. The rest of the money will come from both industry and member countries. National governments will be able to fund these projects through the EU’s coronavirus recovery plan, which has earmarked 20 percent toward digital projects. The joint cloud declaration also issues demands to non-European cloud companies. Cloud providers must “guarantee European standards in terms of security, data protection, consumer protection, data portability and energy efficiency and contribute to European digital sovereignty.” The companies must offer “adequate assurance” that the EU will maintain control over its strategic and sensitive data. “While all cloud providers are welcome in European cloud federation, the resulting cloud capacities should not be subject to laws of foreign jurisdictions,” the declaration read. One of the first initiatives to come out of Europe’s cloud push is Gaia-X, a much-hyped European effort spearheaded by Germany and France to build up a European platform that sets common standards for cloud technology. Gaia-X has limited the voting rights of non-European cloud computing companies, and they cannot become directors of the association. ETNO, the association representing Europe’s leading telecom operators, applauded the move. “EU governments and the public sector need to be fully committed to the initiative by fully shifting to cloud services. We call for EU targets and commitments that reflect the demand side of the cloud investment story,” said Lise Fuhr, ETNO’s director general.

Oct. 22, 2020