<div dir="ltr">I would have thought each NTU has its own encryption key, and not a single key nationwide that could be easily compromised. <div><br></div><div>--Damian</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jun 11, 2015 at 10:34 AM, Mark ZZZ Smith <span dir="ltr"><<a href="mailto:markzzzsmith@yahoo.com.au" target="_blank">markzzzsmith@yahoo.com.au</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div style="color:#000;background-color:#fff;font-family:Helvetica Neue-Light,Helvetica Neue Light,Helvetica Neue,Helvetica,Arial,Lucida Grande,Sans-Serif;font-size:16px"><div><span></span></div><br>  <div style="font-family:Helvetica Neue-Light,Helvetica Neue Light,Helvetica Neue,Helvetica,Arial,Lucida Grande,Sans-Serif;font-size:16px"> <div style="font-family:HelveticaNeue,Helvetica Neue,Helvetica,Arial,Lucida Grande,Sans-Serif;font-size:16px"> <div dir="ltr"> <hr size="1">  <font size="2" face="Arial"> <b><span style="font-weight:bold">From:</span></b> Julien Goodwin <<a href="mailto:ausnog@studio442.com.au" target="_blank">ausnog@studio442.com.au</a>><br> <b><span style="font-weight:bold">To:</span></b> Radek Tkaczyk <<a href="mailto:radek@tkaczyk.id.au" target="_blank">radek@tkaczyk.id.au</a>>; John Lindsay <<a href="mailto:johnslindsay@mac.com" target="_blank">johnslindsay@mac.com</a>>; Aftab Siddiqui <<a href="mailto:aftab.siddiqui@gmail.com" target="_blank">aftab.siddiqui@gmail.com</a>> <br><b><span style="font-weight:bold">Cc:</span></b> AusNOG Mailing List <<a href="mailto:ausnog@ausnog.net" target="_blank">ausnog@ausnog.net</a>> <br> <b><span style="font-weight:bold">Sent:</span></b> Thursday, 11 June 2015, 0:26<span class=""><br> <b><span style="font-weight:bold">Subject:</span></b> Re: [AusNOG] NBN - GPON encryption<br> </span></font> </div><span class=""> <div><br>On 10/06/15 14:33, Radek Tkaczyk wrote:<br clear="none">>  >> And all directional splitters have some back propagation.<br clear="none">><br clear="none">> Exactly – that is the problem we are investigating.<br clear="none">><br clear="none">> If there is no encryption on the upstream, then this can be intercepted.<br clear="none">><br clear="none">> What’s worse – is that if the encryption keys are sent in the clear on<br clear="none">> the upstream, then an attacker could in theory get those encryption<br clear="none">> keys, and then decrypt the downstream traffic as well.<br clear="none">><br clear="none">> I just hope I’m wrong about this….<br clear="none"><br clear="none">Which is exactly why if you're deploying encryption you want to do it on <br clear="none">endpoints under your total control.</div><div><br></div></span><div dir="ltr">/ So NBN(co) stick a box on your wall that isn't physically protected from you (i.e., inside a locked rack) that holds those keys and others. Since security is a weakest link problem, I wonder how strong the "link" stuck on your wall is. Temper evident/proof case? Signed and verified firmware images? Hardware security module/secure cryptoprocessor to hold the keys?</div><div dir="ltr"><br></div><div dir="ltr">/ I'd think it more likely that people could discover the critical keys from cracking open the NTU than getting them off of the wire via an optical tap (and even then, those keys should only really be session keys that roll-over periodically).</div><div dir="ltr"><br></div><div dir="ltr">/ Then again, going by the recent articles about widespread vulnerabilities, the device behind the NTU (the RG/CPE) is likely to be a far more attractive target for somebody to spend time on.</div><div dir="ltr"><br></div><div dir="ltr">/ People need to do proper threat modelling before worrying about mitigating specific threats. If they don't, they might miss the vulnerability that the attacker is most likely to target (e.g., focus on buying the best possible locks for the front door, while overlooking the fact that the windows don't have any locks at all ...)<span class=""><br clear="none"><br clear="none">Even ignoring external threats all it would take is one mistake[1], <br clear="none">bug[2], or malicious actor inside NBNco for they, or possibly others to <br clear="none">have access to your traffic.<br clear="none"><br clear="none">And that's without even trotting out intercept requests etc.<br clear="none"><br clear="none">NBNco links, as with any other third party (electrically) multiplexed <br clear="none">service, are best treated the same way you'd treat a random Internet path.<br clear="none"><br clear="none"><br clear="none">1: Meant to debug by sniffing traffic on link 13443, accidentally <br clear="none">sniffed 14334.<br clear="none">2: I've seen bad route memory in routers do some horrible things. And <br clear="none">without good monitoring you might not even notice if all it caused was a <br clear="none">few extra hops.<div><br><br></div><div><br clear="none">_______________________________________________<br clear="none">AusNOG mailing list<br clear="none"><a shape="rect" href="mailto:AusNOG@lists.ausnog.net" target="_blank">AusNOG@lists.ausnog.net</a><br clear="none"><a shape="rect" href="http://lists.ausnog.net/mailman/listinfo/ausnog" target="_blank">http://lists.ausnog.net/mailman/listinfo/ausnog</a><br clear="none"></div><br><br></span></div> </div> </div>  </div></div><br>_______________________________________________<br>
AusNOG mailing list<br>
<a href="mailto:AusNOG@lists.ausnog.net">AusNOG@lists.ausnog.net</a><br>
<a href="http://lists.ausnog.net/mailman/listinfo/ausnog" target="_blank">http://lists.ausnog.net/mailman/listinfo/ausnog</a><br>
<br></blockquote></div><br></div>