[AusNOG] Dutton decryption bill

Tue Sep 4 14:15:30 EST 2018

Hi All,

The problem with the ‘device malware’ approach is also that if such an approach is used where the intention is to target a single device and the software / hardware vendor screws up and deploys the ‘weakened’ application to many devices instead of one specific device then there is the potential to weaken the security and compromise the privacy of others. 

I’m sure there’s some political double talk that would cover this scenario and that the onus would be solely on the vendor for making sure this does not happen, the worry is that this exact scenario is possible, especially if proof of concepts accidently get released into the wild.

The public should be concerned about this for if we end up in a situation where users don’t trust security updates (or updates of any type) then we’re in the same boat as having a purposefully compromised application deployed, we’d have devices with known vulnerabilities with updates turned off which would be arguably more serious as time goes on.

I truly believe the reason this legislation is so vague is that they’re trying to find a solution where no one scenario is without significant risks, they’re trying to hold water in a sieve by tipping more water into it in an effort to fill it. 

Kind Regards,

Jim.

From: AusNOG <ausnog-bounces at lists.ausnog.net> On Behalf Of Paul Brooks
Sent: Tuesday, 4 September 2018 12:05 AM
To: ausnog at lists.ausnog.net
Subject: Re: [AusNOG] Dutton decryption bill

On 3/09/2018 11:47 AM, Chris Ford wrote:

Paul,

I agree with you in general as to the point that if we are happy with the premise of the current TIA Act that LEAs should be able to intercept communications with a duly authorised warrant, then extending that to encrypted services seems a reasonable extension to keep up with technology.

However, the current intercept regime is very difficult if not impossible for a bad actor to exploit. The intercept points are within the Carrier and CSP networks, out of reach of most people. When we move to intercept end-to-end encrypted services you either need to break the encryption (which thankfully does not seem to be the path anybody is proposing), OR, you need to access the clear text at the end point itself. The problem I have with this is that the end point is out in user land, often accessible to anyone on the internet, and now exposed to exploit by bad actors.

..And this is it. The new legislation is NOT about encryption, primarily, despite what we thought before the draft was released.
They've explicitly acknowledged they can't 'break' encryption, and do not want to weaken encryption. They want the sent and received message text, stored in the device after/before the encrypted transport.

Its actually a 'device malware' bill - a bill to enable general police forces to achieve things that previously only shadowy four-letter agencies could do - implant malware and modify the function of any end-user device, handset, modem, laptop, tablet, printer, connected TV, Amazon Alexa/Google Home/etc. Actually it goes further - rather than implant the malware themselves once they've achieved physical access, this 'device malware' bill enables them to ask nicely for assistance, and then to require, the device suppliers and manufacturers to build and implant the exploit for them. Why should AS** develop an exploit, when they can ask Apple or Netgear or Samsung nicely to develop and install the exploit for them.

We've spent decades educating users that the green padlock on a website means something, and that 'IOT devices' such as your average Smart TV might be easily hijacked and be recording and watching the home through its microphone and embedded webcam. This bill makes government-authorised modified firmware with exploits that the network and software industry have spent billions developing virus scanning apps to detect and eradicate.

Paul.

--

Chris Ford | CTO

Inabox Group Limited

Ph: + 61 2 8275 6871

Mb: +61 401 988 844

Em: chris.ford at inaboxgroup.com.au <mailto:chris.ford at inaboxgroup.com.au> 

  _____  

From: AusNOG  <mailto:ausnog-bounces at lists.ausnog.net> <ausnog-bounces at lists.ausnog.net> on behalf of Paul Wilkins  <mailto:paulwilkins369 at gmail.com> <paulwilkins369 at gmail.com>
Sent: Monday, 3 September 2018 11:31:14 AM
To: AusNOG at lists.ausnog.net <mailto:AusNOG at lists.ausnog.net> 
Subject: Re: [AusNOG] Dutton decryption bill 

Bradley,

The Common Law has always allowed judicial scrutiny of our privacy. There's always been the right for judicial search warrants to override what's considered one's private domain. I'm supportive of this bill where it extends judicial oversite to the cyber domain, which is a gap that exists only because legislation/common law has lagged behind technology. While at the same time realising that conversations conducted over the internet, even if encrypted, are more properly regarded as public conversations, than say one you might have in your living room. Whether government is going to regulate the internet, the boat has sailed on this long ago. The hard line privacy advocates are simply going to be left out of a conversation democracy needs to have over not whether the internet should be regulated, but how.

What's interesting in this bill is that it goes beyond extending judicial writ, allowing law enforcement emergency powers the right to surveil suspects. This will be authorised by law enforcement, without judicial or governmental oversite. I think this probably goes too far. The best outcome for everyone, to protect privacy, and to empower law enforcement to enforce laws and to protect citizens rights, would be to limit the scope of these new powers to judicial writ.

Kind regards

Paul Wilkins

_______________________________________________
AusNOG mailing list
AusNOG at lists.ausnog.net <mailto:AusNOG at lists.ausnog.net> 
http://lists.ausnog.net/mailman/listinfo/ausnog

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ausnog.net/pipermail/ausnog/attachments/20180904/a5b3579f/attachment.html>