Re: [nexa] Australia passes new law to thwart strong encryption
Ulteriore effetto interessante: Atlassian ha sede a Syndey e BitBucket (maggior competitor di GitHub recentemente acquistato da Microsoft) è un prodotto di Atlassian. Diventa ancora più importante, per chiunque utilizzi BitBucket, firmare crittograficamente le commit per evitare che vengano manomesse. E probabilmente dovremmo pensare nuovi metodi per garantire che il primo scaricamento dei sorgenti non sia vulnerabile a manomissioni. Giacomo On Sun, 9 Dec 2018 at 13:38, Giacomo <giacomo@tesio.it> wrote:
Il December 7, 2018 12:10:01 PM UTC, Alberto Cammozzo <ac+nexa@zeromx.net> ha scritto:
<https://arstechnica.com/tech-policy/2018/12/australia-passes-new-law-to-thwa...>
On Thursday, the Australian parliament approved a measure that critics say will weaken encryption in favor of law enforcement and the demands of government.
The new law, which has been pushed for since at least 2017, requires that companies provide a way to get at encrypted communications and data via a warrant process. It also imposes fines of up to A$10 million for companies that do not comply and A$50,000 for individuals who do not comply. In short, the law thwarts (or at least tries to thwart) strong encryption.
Companies who receive one of these warrants have the option of either complying with the government or waiting for a court order. However, by default, the orders are secret, so companies would not be able to tell the public that they had received one.
"It's a big deal," Adam Molnar, a lecturer in criminology at Deakin University in Australia, told Ars.
However, the law as currently written seems to contain what some view as a loophole. The statute says that companies cannot be compelled to introduce a "systemic weakness" or a "systemic vulnerability" into their software or hardware to satisfy government demands.
Those terms are not fully defined in the current law but are set to be added in the forthcoming amendments.
Molnar pointed out that the new law not only implicates his home country but also the other four members of the so-called "Five Eyes" of English-speaking nations, which include New Zealand, Canada, the United Kingdom, and the United States.
The US government (particularly the FBI and Department of Justice) has long complained of the "going dark" problem, but it has not managed to get any adequate federal legislation to address the issue since the failed "Clipper Chip" of the 1990s.
Australian authorities are already known to cooperate with American law enforcement, notably as part of the investigations into the "Love Zone" child-porn website.
"The Government is responding to the impediment that the increasing prevalence of encrypted data and communications represents to available investigative and interception capabilities," the Australian parliament wrote in its Bill Digest.
"The Bill contains measures aimed at facilitating lawful access to communications and data through two avenues—decryption of encrypted technologies and access to communications and data at points where they are not encrypted."
[...] _______________________________________________ nexa mailing list nexa@server-nexa.polito.it https://server-nexa.polito.it/cgi-bin/mailman/listinfo/nexa
Questa legge potrebbe avere interessanti effetti collaterali sul software libero.
Anzitutto la possibilità di ispezionare il sorgente e compilarlo diventa più importante.
D'altro canto sarà necessario porre maggiore attenzione al software libero guidato da team australiani, che potrebbero essere costretti ad introdurre vulnerabilità.
Quanto ai contributi australiani a software libero internazionale, sarà necessario porre maggiore attenzione durante la revisione delle patch. Tale attenzione potrebbe però rendere i contributi australiani più sicuri degli altri.
Giacomo
On 10/12/2018 09:09, Giacomo Tesio wrote:
Ulteriore effetto interessante: Atlassian ha sede a Syndey e BitBucket (maggior competitor di GitHub recentemente acquistato da Microsoft) è un prodotto di Atlassian.
Diventa ancora più importante, per chiunque utilizzi BitBucket, firmare crittograficamente le commit per evitare che vengano manomesse. E probabilmente dovremmo pensare nuovi metodi per garantire che il primo scaricamento dei sorgenti non sia vulnerabile a manomissioni.
Ecco un buon uso della blockchain: archivio distribuito degli hash di binari o sorgenti scaricati da fonti incerte. :-)
Giacomo On Sun, 9 Dec 2018 at 13:38, Giacomo <giacomo@tesio.it> wrote:
Il December 7, 2018 12:10:01 PM UTC, Alberto Cammozzo <ac+nexa@zeromx.net> ha scritto:
<https://arstechnica.com/tech-policy/2018/12/australia-passes-new-law-to-thwa...>
On Thursday, the Australian parliament approved a measure that critics say will weaken encryption in favor of law enforcement and the demands of government.
The new law, which has been pushed for since at least 2017, requires that companies provide a way to get at encrypted communications and data via a warrant process. It also imposes fines of up to A$10 million for companies that do not comply and A$50,000 for individuals who do not comply. In short, the law thwarts (or at least tries to thwart) strong encryption.
Companies who receive one of these warrants have the option of either complying with the government or waiting for a court order. However, by default, the orders are secret, so companies would not be able to tell the public that they had received one.
"It's a big deal," Adam Molnar, a lecturer in criminology at Deakin University in Australia, told Ars.
However, the law as currently written seems to contain what some view as a loophole. The statute says that companies cannot be compelled to introduce a "systemic weakness" or a "systemic vulnerability" into their software or hardware to satisfy government demands.
Those terms are not fully defined in the current law but are set to be added in the forthcoming amendments.
Molnar pointed out that the new law not only implicates his home country but also the other four members of the so-called "Five Eyes" of English-speaking nations, which include New Zealand, Canada, the United Kingdom, and the United States.
The US government (particularly the FBI and Department of Justice) has long complained of the "going dark" problem, but it has not managed to get any adequate federal legislation to address the issue since the failed "Clipper Chip" of the 1990s.
Australian authorities are already known to cooperate with American law enforcement, notably as part of the investigations into the "Love Zone" child-porn website.
"The Government is responding to the impediment that the increasing prevalence of encrypted data and communications represents to available investigative and interception capabilities," the Australian parliament wrote in its Bill Digest.
"The Bill contains measures aimed at facilitating lawful access to communications and data through two avenues—decryption of encrypted technologies and access to communications and data at points where they are not encrypted."
[...] _______________________________________________ nexa mailing list nexa@server-nexa.polito.it https://server-nexa.polito.it/cgi-bin/mailman/listinfo/nexa Questa legge potrebbe avere interessanti effetti collaterali sul software libero.
Anzitutto la possibilità di ispezionare il sorgente e compilarlo diventa più importante.
D'altro canto sarà necessario porre maggiore attenzione al software libero guidato da team australiani, che potrebbero essere costretti ad introdurre vulnerabilità.
Quanto ai contributi australiani a software libero internazionale, sarà necessario porre maggiore attenzione durante la revisione delle patch. Tale attenzione potrebbe però rendere i contributi australiani più sicuri degli altri.
Giacomo
On Mon, 10 Dec 2018 at 09:14, Alberto Cammozzo <ac+nexa@zeromx.net> wrote:
Ecco un buon uso della blockchain: archivio distribuito degli hash di binari o sorgenti scaricati da fonti incerte. :-)
O più semplicemente content-based addressing per il repository. Giacomo
On Mon, Dec 10, 2018 at 09:14:31AM +0100, Alberto Cammozzo wrote:
Ecco un buon uso della blockchain: archivio distribuito degli hash di binari o sorgenti scaricati da fonti incerte. :-)
Nah, le care vecchie signature sono più che sufficienti per evitare tampering nella catena di download. In questi casi, *se* nel tuo threat model ti vuoi fidare dell'autore/committer del codice, il consensus stile blockchain continua ad essere una soluzione in cerca di un problema :-) -- 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 December 10, 2018 10:46:38 AM UTC, Stefano Zacchiroli <zack@upsilon.cc> wrote: On Mon, Dec 10, 2018 at 09:14:31AM +0100, Alberto Cammozzo wrote: Ecco un buon uso della blockchain: archivio distribuito degli hash di binari o sorgenti scaricati da fonti incerte. :-) Nah, le care vecchie signature sono più che sufficienti per evitare tampering nella catena di download. In questi casi, *se* nel tuo threat model ti vuoi fidare dell'autore/committer del codice, il consensus stile blockchain continua ad essere una soluzione in cerca di un problema :-) Potrei fidarmi del committer ma non del repository, o di tutti i repository. Pensa ad esempio ai molti repository alternativi di app Android (Play, f-droid, ecc). In questo caso il device può autonomamente acquisire e verificare la signature da una fonte write-once distribuita.
On Mon, Dec 10, 2018 at 07:15:06PM +0100, Alberto Cammozzo wrote:
Potrei fidarmi del committer ma non del repository, o di tutti i repository. Pensa ad esempio ai molti repository alternativi di app Android (Play, f-droid, ecc).
Non hai bisogno di fidarti del repository (o del canale tra lui ed esso) se hai un checksum su ciò che scarichi ed una signature che certifichi che il checksum corrisponde a quello dichiarato dal maintainer. Perché puoi verificare entrambe le cose dopo il download e notare mismatch. Molti repository funzionano infatti in questo modo. Che so, puoi scaricare i pacchetti Debian/Ubuntu/etc. via HTTP (anziché via HTTPS) senza rischi di tampering, proprio perché apt-get verifica per te le signature ed i checksum prima di installare i pacchetti in locale. -- 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 10/12/2018 19:18, Stefano Zacchiroli wrote:
On Mon, Dec 10, 2018 at 07:15:06PM +0100, Alberto Cammozzo wrote:
Potrei fidarmi del committer ma non del repository, o di tutti i repository. Pensa ad esempio ai molti repository alternativi di app Android (Play, f-droid, ecc). Non hai bisogno di fidarti del repository (o del canale tra lui ed esso) se hai un checksum su ciò che scarichi ed una signature che certifichi che il checksum corrisponde a quello dichiarato dal maintainer. Perché puoi verificare entrambe le cose dopo il download e notare mismatch.
Molti repository funzionano infatti in questo modo. Che so, puoi scaricare i pacchetti Debian/Ubuntu/etc. via HTTP (anziché via HTTPS) senza rischi di tampering, proprio perché apt-get verifica per te le signature ed i checksum prima di installare i pacchetti in locale.
So come funziona, ma se devi scaricare il cksum dallo stesso repository e questo è compromesso oltre al binario anche il cksum sarà manomesso (e corretto). Il sistema funziona bene comunque nel caso il repository sia trusted, ma se l'utente non può/non vuole fidarsi sarà bene che il checksum stia da un'altra parte (trusted third party). In un repository trusted mi aspetto che chi lo gestisce controlli che i cksum non siano stati alterati -- suppongo Debian lo faccia, e suppongo anche che apt-get non si fidi di http per scaricare i checksum. Non è necessario che Trusted Third Party sia una BlockChain (di cui non sono un fan), ma è uno dei pochi casi in cui può prestarsi: read-only, distribuito, multiple unknown writers, ...
Parlando dei repository git o mercurial hostati da Atlassian su BitBucket, il problema si pone se pubblico la URI da clonare referenziando il master branch. Se firmiamo le commit con GPG (cosa che ahimè fin ora non avevo mai fatto) diventa impossibile per chi non disponga delle chiavi private di falsificare la storia. Tuttavia rimane possibile sostituire l'intero repository con uno non firmato o uno firmato solo fino ad un certo punto. Naturalmente non è possibile condurre questo attacco contro chi abbia già scaricato il repository, ma chiunque non abbia mai scaricato il repository è una potenziale vittima di questo attacco. La nuova legge rende importante pubblicare la URI di una commit specifica per chi intemda clonare il repository. L'hash della commit funzionerebbe così da content address che garantisce l'intera storia fino a quel punto. Giacomo
On Mon, Dec 10, 2018 at 07:44:13PM +0100, Alberto Cammozzo wrote:
So come funziona, ma se devi scaricare il cksum dallo stesso repository e questo è compromesso oltre al binario anche il cksum sarà manomesso (e corretto).
Il checksum manomesso sarà corretto. Ma la *signature* sul checksum non potrà esserlo, perché solo il maintainer/autore del software la può produrre con la sua chiave privata. L'hoster del repository malfido non può produrla perché non ha la chiave. Quindi continuo a non vedere il tipo di attacco che stai cercando di evitare. L'unico "attacco" possibile è che l'hoster *tolga* la signature del maintainer, ma è un attacco con le virgolette del caso perché se il client (il package manager) è fatto bene rifiuterà di installare un pacchetto il cui checksum non è firmato. E quindi gli utenti smetteranno di usare il repository perché semplicemente, dal loro punto di vista, non funziona.
In un repository trusted mi aspetto che chi lo gestisce controlli che i cksum non siano stati alterati -- suppongo Debian lo faccia, e suppongo anche che apt-get non si fidi di http per scaricare i checksum.
apt-get scarica i checksum via http (e persino ftp...) senza problemi, e pure da mirror terze parti, proprio per il motivo di cui sopra: sebbene i checksum possono essere manomessi da terze parti, le signature non possono esserlo. Tornando alla blockchain, puoi certamente immaginare di distribuire le signature via essa ed avere dei client che le cercano nella blockchain anziché nel repository stesso. Ma a quel punto stai usando una blockchain semplicemente come se fosse una CDN per dei file particolari. Funziona, ma non c'è nessun valore aggiunto dato dall'uso della blockchain. Ed il motivo è che i meccanismi di integrità del software basati su signature sono verticali (maintainer / autore / distributore) e non orizzontali, quindi il consenso distribuito non aggiunge nulla. A presto -- 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 »
Stefano il tuo riferimento a Debian mi fa pensare se distribuire solo software in formato sorgente non possa mitigare fortemente i rischi di manomissione. Naturalmente con il software attuale questo comporterebbe un notevole incremento del tempo di installazione (e probabilmente anche un costo energetico/ecologico maggiore visto che la compilazione verrebbe effettuata ad ogni installazione). D'altro canto, cosa succederebbe se il governo Australiano inviasse un ordine di manomettere il repository di Debian al ftp master? Giacomo
On Mon, Dec 10, 2018 at 09:31:29PM +0000, Giacomo wrote:
Stefano il tuo riferimento a Debian mi fa pensare se distribuire solo software in formato sorgente non possa mitigare fortemente i rischi di manomissione.
Naturalmente con il software attuale questo comporterebbe un notevole incremento del tempo di installazione (e probabilmente anche un costo energetico/ecologico maggiore visto che la compilazione verrebbe effettuata ad ogni installazione).
A mio avviso esiste un best of both worlds: ovvero build riproducibili byte-by-byte, nel senso di https://reproducible-builds.org/ Così hai i sorgenti (per audit pubblico) e puoi anche con una certa fiducia usare binari precompilati, basandoti sull'ipotesi che un certo numero di persone nella tua comunità di riferimento (o anche progetti di audit indipendenti) facciano l'esercizio di ricompilare/verificare, ed eventualmente fare un gran casino quando c'è un mismatch. Molte distribuzioni e package manager ci stanno lavorando da un po' di anni, con ottimi risultati. (Disclaimer: sono nello steering committee di reproducible-builds.org, e quindi decisamente di parte.) -- 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 »
participants (4)
-
Alberto Cammozzo -
Giacomo -
Giacomo Tesio
-
Stefano Zacchiroli