VoIP Security has long been viewed as another one of those features that no one really needs, but must be in the feature list to win bids. It is also something that companies who have it tout as mandatory and scare the hell out of prospective customers.

I hate both ends of this equation, but I do feel that there is something to consider here.

R Reddy over at the GIPS blog believes that security threats are real in VoIP. It’s just a matter of time:

So in the short term, as new communications products evolve and gain traction, we will most likely not see a lot of VoIP security break-ins.  However, the danger lies down the road, possibly as far off as the next decade.  At this point, current products will be mature and commonplace across enterprise and consumer premises, essentially becoming legacy systems.  This will attract more attention from the hacking world with specific VoIP attacks.

While I do agree with everything Reddy writes, I think there is still a missing piece in this puzzle: The Internet makes VoIP far more susceptible to malicious hacking than PSTN ever was.

That is because the internet is more accessible to hackers (or anyone for that matter) than the PSTN infrastructure ever was. It is also more complex in its protocols than the PSTN was/is, with far more companies developing products for it. This means that any opening left for a hacker in a VoIP system is far more likely to be found and exploited than in the PSTN case. Only reason this hasn’t happened yet is that not enough people use VoIP today to make it really interesting.

Three Layers of Security

Far back, during my joyful university days, slugging it out to get a bachelor’s degree in Computer Sciences, I took a course in Security. The lecturer, whose name I don’t remember (it was over 10 years ago) was a full-time employee of NDS, a company focused until today on conditional access technologies (also known as “security”). In his view, there are three layers to security that needs to be addressed:

1. The algorithmic level, where you pick and choose the algorithms you use to protect whatever it is you want to protect. Think DES, triple DES, AES, MD5, SHA1, RSA and all those other acronyms. (Don’t know ‘em?  Look ‘em up!)
2. The programming level, where people write code which can be broken.
3. The system level, where you define what exactly you want to achieve and write a protocol to achieve it.

The Algorithmic Level

On the algorithmic level things are relatively easy. We know the math; we can try and hack these algorithms – something done all over the world on a daily basis.

MD5, for example, a hashing algorithm known to be quite robust, is being attacked a lot lately with multiple vulnerabilities found. The latest one related to Chosen-Prefix Collisions on GPUs – a combination of guesstimates and brute force.

The good news is that, on the algorithmic level, you can always switch to a similar stronger algorithm or add bits to the keys you use to increase protection. This level is quite easy to get a grip on.

The Programming Level

This is where the human factor comes into play the most. You have your algorithms, your passwords, your procedures and your design. And then programmers sit down and write code. Code that is full of bugs. Not because they are bad programmers, but because they are human.

These bugs can sometimes be exploited to hack into the system.

Need an example? You can hack a Wii game console by running a copy of the game Zelda. The hack simply uses a buffer overrun (which is caused by a bug left behind by programmers) and exploits it to open up the system for copied games.

This level is a cat-and-mouse kind of game, where hackers look for cracks to exploit and programmers fill in the cracks with security patches.

The System Level

The system level is a totally different beast. This is where real brains are required to protect a system and where the real and most dangerous vulnerabilities lay.

This is where VoIP is most vulnerable today.

When people define the security protocol to use, they might end up leaving holes in the protocol itself, which will allow hackers to crack the system.

The one thing that currently saves us (?) is that you cannot patch these vulnerabilities up quite as easily as you can with programming bugs – especially not if you are following a standard that defines the exact protocol you must use.

Need a good example?  There’s a huge vulnerability that allows people to clone GSM phones and place calls billed on the original phone. This GSM vulnerability is documented by the ISAAC research group over at Berkeley University, the reason:

This vulnerability can be attributed to a serious failing of the GSM security design process: it was conducted in secrecy. Experts have learned over the years that the only way to assure security is to follow an open design process, encouraging public review to identify flaws while they can still be fixed. There’s no way that we would have been able to break the cryptography so quickly if the design had been subjected to public scrutiny; nobody is that much better than the rest of the research community.

It is not the only security vulnerability in GSM attributed to bad design as far as I know. The ISAAC research group states that the best solution for design flaws is open standards:

In the telecommunications security field, openness is critical to good design. Codemaking is so hard to get right the first time that it is crucial to have others double-check one’s ideas.

While I agree with that, I have taken part of standardization processes in the past, and I don’t think that the way open standards are being defined places enough leverage and focus on security. Not always the people dealing with defining the standards are those that are the most experienced in designing security protocols, and even if they are – the politics involved in defining standards can always generate design flaws.

It also means that the most dangerous risks are usually those that are hardest to overcome.

Is Your VoIP System Secure?

No. Simply because it probably haven’t been tested against enough hackers yet.

Should you care about it? Sure. But I guess it is way too early for that.

Is there anything you can do? Probably not. You can use security as it is defined today and hope for the best. In the end, if your system is interesting enough and popular enough, hackers will come looking for its vulnerabilities, and once they start looking – they will find the cracks.