Australia passes new law to thwart strong encryption
<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." [...]
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. Fin tanto che l'attenzione resterà alta ovviamente. Giacomo
Concordo. Gli articoli 25 e 32 del Reg. UE 2016/679 introducono, e questo lo ho dichiarato sia in rete sia nei convegni in cui mi è stato concesso di descrivere l'adeguamento tecnologico al GDPR, il principio della qualità del software conditio sine qua non al rispetto dell’articolo 1 della stessa legge. Che cosa vuol dire? Vuol dire che il sw open source deve sottostare ai controlli di merito onde ridurre la presenza di istruzioni vulnerabili al suo interno (vedi std CWE SANS, PCI DSS, ecc.) e di conseguenza la probabilità che un evento malevolo possa verificarsi. E non solo! DEVE essere controllata anche la obsolescenza. Tali controlli devono essere svolti durante le fasi iniziali di sviluppo e di test nel ciclo di vita del software Aldo -----Messaggio originale----- Da: nexa [mailto:nexa-bounces@server-nexa.polito.it] Per conto di Giacomo Inviato: domenica 9 dicembre 2018 13:41 A: nexa@server-nexa.polito.it; Alberto Cammozzo <ac+nexa@zeromx.net>; nexa@server-nexa.polito.it Oggetto: Re: [nexa] Australia passes new law to thwart strong encryption 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. Fin tanto che l'attenzione resterà alta ovviamente. Giacomo _______________________________________________ nexa mailing list nexa@server-nexa.polito.it<mailto:nexa@server-nexa.polito.it> https://server-nexa.polito.it/cgi-bin/mailman/listinfo/nexa
Il giorno lun 10 dic 2018 alle ore 10:42 Aldo Pedico <a.pedico@teleion.it> ha scritto:
Gli articoli 25 e 32 del Reg. UE 2016/679 introducono, e questo lo ho dichiarato sia in rete sia nei convegni in cui mi è stato concesso di descrivere l'adeguamento tecnologico al GDPR, il principio della qualità del software conditio sine qua non al rispetto dell’articolo 1 della stessa legge.
Che cosa vuol dire? Vuol dire che il sw open source deve sottostare ai controlli di merito onde ridurre la presenza di istruzioni vulnerabili al suo interno (vedi std CWE SANS, PCI DSS, ecc.) e di conseguenza la probabilità che un evento malevolo possa verificarsi. E non solo! DEVE essere controllata anche la obsolescenza. Tali controlli devono essere svolti durante le fasi iniziali di sviluppo e di test nel ciclo di vita del software
"DEVE" è un po' forte, considerato che il software libero è distribuito WITHOUT WARRANTY. Diciamo piuttosto... "sarebbe meglio che". Beh... ora che ci penso... e anche molto software proprietario è distribuito senza garanzie. Questo è un punto interessante che è emerso precedentemente su questa lista, parlando di robotica e delle morti provocate dalle self-driving car quest'anno. Chi risponde dei danni causati da un software distribuito WITHOUT WARRANTY? Al momento, correggetemi se sbaglio, ne risponde l'utente che lo esegue a meno che non sia comprovabile la mala fede di chi lo ha sviluppato/distribuito. Giacomo
Dal punto di vista formale, hai ragione "sarebbe meglio che". Il mio "DEVE" si riferisce a quelle aziende che si installano il sw open e lo riusano al loro interno ed in taluni casi lo rivendono all'interno di loro applicazioni. Lavorando come consulente in grandi aziende, constato che questi usi sono oramai all'ordine del giorno. Ed ecco il motivo per cui è necessario far analizzare il sw open da prodotti in grado di rilevare le istruzioni vulnerabili indicandone la correzione (inclusi anche come test di qualità). Opportunamente inserita nella fase iniziale dei test e prima del passaggio in ambienti di distribuzione, l'analisi statica del sw abbinata a test dinamici finalizzati alla valutazione della sicurezza perimetrale, alzano la garanzia di sicurezza. Purtroppo questa attività sul sw libero è stata poco utilizzata, soltanto ora s'intravvedono usi in organizzazioni strutturate o obbligate da direttive nazionali e sensibili ai danni di immagine, economici, ecc. Aldo -----Messaggio originale----- Da: Giacomo Tesio [mailto:giacomo@tesio.it] Inviato: lunedì 10 dicembre 2018 12:18 A: Aldo Pedico <a.pedico@teleion.it> Cc: Nexa <nexa@server-nexa.polito.it>; Alberto Cammozzo <ac+nexa@zeromx.net> Oggetto: Re: [nexa] Australia passes new law to thwart strong encryption Il giorno lun 10 dic 2018 alle ore 10:42 Aldo Pedico <a.pedico@teleion.it> ha scritto:
Gli articoli 25 e 32 del Reg. UE 2016/679 introducono, e questo lo ho dichiarato sia in rete sia nei convegni in cui mi è stato concesso di descrivere l'adeguamento tecnologico al GDPR, il principio della qualità del software conditio sine qua non al rispetto dell’articolo 1 della stessa legge.
Che cosa vuol dire? Vuol dire che il sw open source deve sottostare ai controlli di merito onde ridurre la presenza di istruzioni vulnerabili al suo interno (vedi std CWE SANS, PCI DSS, ecc.) e di conseguenza la probabilità che un evento malevolo possa verificarsi. E non solo! DEVE essere controllata anche la obsolescenza. Tali controlli devono essere svolti durante le fasi iniziali di sviluppo e di test nel ciclo di vita del software
"DEVE" è un po' forte, considerato che il software libero è distribuito WITHOUT WARRANTY. Diciamo piuttosto... "sarebbe meglio che". Beh... ora che ci penso... e anche molto software proprietario è distribuito senza garanzie. Questo è un punto interessante che è emerso precedentemente su questa lista, parlando di robotica e delle morti provocate dalle self-driving car quest'anno. Chi risponde dei danni causati da un software distribuito WITHOUT WARRANTY? Al momento, correggetemi se sbaglio, ne risponde l'utente che lo esegue a meno che non sia comprovabile la mala fede di chi lo ha sviluppato/distribuito. Giacomo
participants (4)
-
Alberto Cammozzo -
Aldo Pedico -
Giacomo -
Giacomo Tesio