[VoiceOps] SS7

[Mike Ray, MBA, CNE, CTE]

It seems to me that this SS7 vulnerability issue is just the latest result of all of the de-regulation that’s been going on for the past… two decades or so.  There was a time that you could not buy commercial access to the SS7 network; to get that access you had to be a real carrier.  Also, back at that time, inter-company SS7 signalling could only occur on established, ordered signaling routes where both parties placed an order to open the route between them.  Therefore, this would not have been possible back then because the carrier would not have ordered a route to the hacker’s point code(s) and it therefore would not exist.

 

If I am a US local carrier in 2001, I have no need to order a signaling route to a German carrier either so even the hacker having full access to a German carrier’s network would not compromise my network. (in response to the nation-state issue)  To get a call to Germany, I signal to the access tandem or IXC switch I’ve chosen to interconnect with in the US and that switch signals upstream, etc.

 

If we were not on this path of de-regulation where whatever makes commercial sense for one company can open up the whole SS7 network to un-trusted parties, we likely wouldn’t be here.  At some point, a decision was made somewhere to allow this loosy-goosy inter-company signaling over the SS7 network between two point codes that would not, under the original implementation of SS7, be able to talk to each other in the first place.

 

If the drumbeat of “solve everything with IP!” continues, I hope that at least it gets solved by establishing something close to what the VPF was supposed to be, and not just a general dumping of all voice traffic across the internet between carriers.  That certainly wouldn’t bode well for reliability or security.

 

Mike

 

Mike Ray, MBA, CNE, CTE

Astro Companies, LLC

11523 Palm Brush Trail #401

Lakewood Ranch, FL  34202

DIRECT: call or text 941 600-0207

 <http://www.astrocompanies.com> http://www.astrocompanies.com

 

 

 

 

From: VoiceOps [mailto:voiceops-bounces at voiceops.org] On Behalf Of Dan York
Sent: Thursday, April 21, 2016 3:45 PM
To: Kidd Filby <kiddfilby at gmail.com>
Cc: voiceops at voiceops.org
Subject: Re: [VoiceOps] SS7

 

This is generally true if the calls are *unencrypted* on VoIP... 

 

On Thu, Apr 21, 2016 at 2:20 PM, Kidd Filby <kiddfilby at gmail.com <mailto:kiddfilby at gmail.com> > wrote:

 

Also folks, don't forget, the same outcome of recording someone's call is MUCH easier to accomplish once it is VoIP.  IMHO, of course.  ;-)

 

... BUT... what's fascinating is the recent rise in end-to-end (e2e) encryption among IP-based communications platforms that include voice.

 

WhatsApp, for instance, just completed the rollout of e2e encryption on April 5, and not just for messaging, but also for voice and video calls as well as file transfers ( https://blog.whatsapp.com/10000618/end-to-end-encryption ).  Just yesterday the team behind Viber announced that they will soon have e2e encryption for all clients.  The app Wire ( http://wire.com ) also does e2e encryption for voice, video and group chats.

 

In a US Congress hearing this week, a Congressman asked a Dept of Homeland Security representative if e2e encryption available in apps would have prevented this interception that happened via SS7. The DHS answer was that it would mitigate the interception of the content, although the location meta-data would still be available.  (You can view the exchange via the link in this tweet: https://twitter.com/csoghoian/status/722854012567969794 )

 

The end result is that we're definitely moving to a space where the communication over IP-based solutions will wind up being far more secure than what we had before.

 

Interesting times,

Dan

 

-- 

 

Dan York

 <mailto:dyork at lodestar2.com> dyork at lodestar2.com  +1-802-735-1624   Skype:danyork

My writing -> http://www.danyork.me/

 <http://www.danyork.com/> http://www.danyork.com/

http:// <http://twitter.com/danyork> twitter.com/danyork

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/voiceops/attachments/20160422/c964589e/attachment.html>