<html><body><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;" id="yui_3_16_0_1_1433843929015_112441"> <div style="font-family: HelveticaNeue, Helvetica Neue, Helvetica, Arial, Lucida Grande, Sans-Serif; font-size: 16px;" id="yui_3_16_0_1_1433843929015_112440"> <div dir="ltr" id="yui_3_16_0_1_1433843929015_112439"> <hr size="1"> <font size="2" face="Arial" id="yui_3_16_0_1_1433843929015_112438"> <b><span style="font-weight:bold;">From:</span></b> Julien Goodwin <ausnog@studio442.com.au><br> <b><span style="font-weight: bold;">To:</span></b> Radek Tkaczyk <radek@tkaczyk.id.au>; John Lindsay <johnslindsay@mac.com>; Aftab Siddiqui <aftab.siddiqui@gmail.com> <br><b><span style="font-weight: bold;">Cc:</span></b> AusNOG Mailing List <ausnog@ausnog.net> <br> <b><span style="font-weight: bold;">Sent:</span></b> Thursday, 11 June 2015, 0:26<br> <b><span style="font-weight: bold;">Subject:</span></b> Re: [AusNOG] NBN - GPON encryption<br> </font> </div> <div class="y_msg_container" id="yui_3_16_0_1_1433843929015_112442"><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 class="y_msg_container" id="yui_3_16_0_1_1433843929015_112442"><br></div><div class="y_msg_container" id="yui_3_16_0_1_1433843929015_112442" 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 class="y_msg_container" id="yui_3_16_0_1_1433843929015_112442" dir="ltr"><br></div><div class="y_msg_container" id="yui_3_16_0_1_1433843929015_112442" 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 class="y_msg_container" id="yui_3_16_0_1_1433843929015_112442" dir="ltr"><br></div><div class="y_msg_container" id="yui_3_16_0_1_1433843929015_112442" 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 class="y_msg_container" id="yui_3_16_0_1_1433843929015_112442" dir="ltr"><br></div><div class="y_msg_container" id="yui_3_16_0_1_1433843929015_112442" 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 ...)<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 class="qtdSeparateBR"><br><br></div><div class="yqt4733957964" id="yqtfd45647"><br clear="none">_______________________________________________<br clear="none">AusNOG mailing list<br clear="none"><a shape="rect" ymailto="mailto:AusNOG@lists.ausnog.net" href="mailto:AusNOG@lists.ausnog.net">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></div> </div> </div> </div></body></html>