Archive for the 'Cryptography' Category

Underpowered Hardware

Thursday, February 21st, 2008 by Dustin D. Trammell

One of the issues with VoIP endpoints that I regularly encounter as a security researcher is the problem with underpowered hardware. Many VoIP hardware devices are initially designed with just enough horsepower to do their job in order to keep costs low and stay competitive in the market. Due to VoIP technologies evolving so rapidly and devices being updated to include many additional new features shortly after being brought to market, the software running on these devices generally outgrow the hardware and will consume the few remaining unused resources available on the device. Vendors then have to play a balancing game of what software features can be crammed onto a particular device and it still work properly.

Not only does this condition of the technology promote attacks like Denial of Service via resource exhaustion, floods, and so forth, but it also gives rise to other vulnerabilities such as this one which was detailed yesterday by Larry Dignan & George Ou. Due to the resource limitations of the hardware device, corners were cut when adding support for the device’s 802.1x PEAP authentication feature which resulted in the server certificate not being checked during authentication, which then devolves into a number of other security issues. Not only does this affect the device being discussed in the article, but it apparently also affects a number of other devices as well who’s designers cut the same corner, likely for the same reason.

Because VoIP technology evolves so rapidly, and generally grows in resource requirements by leaps and bounds while doing so, VoIP hardware vendors really should be providing much more processing power than the initial software needs when the devices are brought to market. Unfortunately the cost of including this extra horsepower initially is borne by the vendor, whereas the cost of having to upgrade (i.e., replace) masses of deployed hardware devices when their resource limitations become insurmountable is borne by the consumer.  Device replacement results in additional sales and profits for the vendor, so don’t expect properly resilient hardware devices anytime soon…

Breaking Ciphers on a 5.8MHz Pentium?

Friday, February 1st, 2008 by Martyn Davies

The UK’s National Codes Centre recently ran a competition for amateur codebreakers to try their hands on breaking one of the original WW2 codes (Lorenz Cipher) using modern PC hardware. The National Codes Centre at Bletchley Park (known as “Station X” during the war) is a museum and heritage site for early computing as well as codebreaking. In a nice irony, the winner of the competition was a German programmer, Joachim Schueth, who ran his software on a 1.4 GHz laptop with NetBSD as the O/S, beating the original Colossus codebreaker by a factor of hours. The original Colossus could break the code in 3 hours and 15 minutes, whereas Schueth’s code took just 46 seconds.

On the performance difference, Schueth himself said: “My laptop digested ciphertext at a speed of 1.2 million characters per second – 240 times faster than Colossus. If you scale the CPU frequency by that factor, you get an equivalent clock of 5.8 MHz for Colossus. That is a remarkable speed for a computer built in 1944. Even 40 years later many computers did not reach that speed. So the Cipher Challenge would have been very much closer had it taken place 20 years ago.” That’s right, not GHz, but MHz. The original Colossus was not so much a Pentium, but rather a Z80.

At Bletchley Park, they have a working Colossus which was lovingly rebuilt over many years by a team of enthusiasts, with help from some of the original designers. The Colossus MKII can be seen working by visitors to Bletchley Park.

Colossus Redux

Friday, November 16th, 2007 by Martyn Davies

Bletchley Park is the UK’s mecca for people interested in the history of code breaking, and in particular the codes of World War 2. Bletchley Park (in WW2 known as “Station X”) was the home of the code breakers, and where early computing pioneers like Alan Turing worked on the science of breaking cyphers.

This week, a team of volunteers led by Tony Sale completed a 14 year project to rebuild Colossus, one of the code-breaking computers used at Bletchley Park. After the war the machines were dismantled and even the plans destroyed by order of the military, so the Colossus had to be painstakingly remembered and reconstructed, with the help of some of the original engineers that built it. Tony Sale has had a long association with Bletchley Park, and also with remembering and rebuilding the most important antique computers in the British history of computing.

Although the Colossus was somewhat single-minded in its operation, its use of valves as electronic switches paved the way for the general-purpose computers of the 1940s and 50s, and of course the work they did at Bletchley paved the way for the use of encryption technologies that we use today in data and voice applications across the Internet.

Link: Silicon.com report on the Colossus rebuilt.

FYI - I’m speaking on VoIP security at Ingate SIP Trunking Seminar Series Sept 11 in LA (concurrent with Internet Telephony Expo)

Friday, August 31st, 2007 by Dan York

image FYI, for those of you attending the Internet Telephony Conference & Expo in Los Angeles on September 10-12, I’ll be participating in a panel session that is part of Ingate’s SIP Trunking Seminar Series.  I expect it will surprise no one to learn that I’ll be on the panel about “Enterprise Security and VoIP” speaking on behalf of VOIPSA.  My particular session is Tuesday, September 11, 2007, from 9:30-11:00 am.  More details and the schedule are available online.

The sessions are free and open to anyone to attend.  Simply fill out the pre-registration form. If you are going to be there at the show, please do drop me a note, as I’m always interested in meeting readers or others interested in VoIP security.

Rampant Italian Wiretapping Spurs Consumer Encryption Use

Monday, April 30th, 2007 by Dustin D. Trammell

According to the New York Times, it appears as if consumers in Italy are rapidly moving toward encryption for voice technologies due to rampant publication of private conversations, both due to leaked conversations that were a result of government wiretaps as well as conversations recorded through private means. From the article:

What has spurred encryption sales is not so much the legal wiretapping authorized by Italian magistrates–though information about those calls is also frequently leaked to the press–but the widespread availability of wiretapping technology over the Internet, which has created a growing pool of amateur eavesdroppers. Those snoops have a ready market in the Italian media for filched celebrity conversations.

It would seem that in Italy, it’s fairly common to take someone’s private conversations straight to the press… Even the national telco’s head of Security was in on the game:

This year, Bonini’s name was among thousands that surfaced in an illegal-wiretapping scandal involving employees of Telecom Italia, the Italian phone company.

Twenty people were arrested, including the former chief of Telecom Italia security, in what investigators say was an attempt to use the intercepted phone conversations to blackmail Italian public figures.

Many of the cell-phone encryption products mentioned in the article that are being marketed to Italian consumers sound a lot like Zfone, essentially providing end-to-end encryption for the audio between two devices that run the encryption software in advance of the call.

Skype with a ‘Z’

Tuesday, April 10th, 2007 by Martyn Davies

IP Softphone specialists CounterPath recently announced that they will license Phil Zimmermann’s ZRTP (Zfone) technology for use in their client products, namely eyeBeam and X-Lite, joining other publicly announced licencees Borderware, PGP Corp, Ripcord and TiVi.

As you may know, ZRTP has done very well in terms of acceptance in the last few months. Zimmermann has many friends in the security community, but also has great credentials in the open source world. ZRTP is an openly published protocol, but also is available as source code, thereby making it possible to test in all kinds of ways, not only closed-box (black box) testing but also in terms of working through the algorithm and even unit testing the code.

At the recent IETF meeting, methods of key exchange were discussed, as subscribers to the Voipsec list (from the VOIPSA site) cannot have failed to miss. The IETF have gone from a list of thirteen proposals down to a final two, and ZRTP is one of those, despite being considered by some as a latecomer.  Many organizations and people that I have come across trust in Zimmermann and believe that ZRTP is the answer.

If we go to the opposite end of the trust scale, we find Skype.  Poor old Skype are still getting weekly batterings from press critics on the security front.  A lot of the same criticisms are brought up time and time again, and in fairness Skype have countered a lot of the concerns, by allowing features to be switched off, changes to the package and so on.  We don’t need to rehearse all those issues here once again.

However, the issues that keep coming up, and which Skype have not argued away are those of security by obscurity and the secrecy of the protocols they use for encryption and key exchange. Famously, Skype hired security expert Tom Berson to write a report based on a long evaluation of Skype’s security provisions, but most academics still desire transparency, and the ability to evaluate the algorithms for themselves.

Academics and commercial security experts both say that simply using a secret algorithm is no guarantee of safety. Furthermore, the fact that it is secret merely means that when someone does compromise Skype, the detection and mitigation of the problem will be slowed down or prevented. Skype at that point becomes a dangerous ‘bot’ sitting behind thousands of firewalls.

What better time, then, for Skype to embrace ZRTP? Licensing ZRTP can hardly be a problem for Skype and its Ebay parent, and there is so much to gain from this. A large community of security and VoIP specialists already believe in ZRTP; the IETF likes it; commercial acceptance exists in licencees in the Softphone and Session Border Controller market. IT Managers, I’m sure, would be happier with Skype usage in the workplace if they were allowed to detect and control it, and (who knows with key escrow) in some way to log and record from it.

Come on, Skype, grab the nettle. The tools are in your hands to silence your critics.

Cracking the WLAN

Wednesday, April 4th, 2007 by Martyn Davies

I previously reported that the Wired Equivalent Privacy (WEP) encryption scheme could be broken in 3 minutes.  Now researchers have reduced this to 1 minute, the most effective attack yet.  Visit the Bruce Schneier blog for the link to the paper in PDF format.  It’s really time to upgrade or reconfigure that home network.

Phil Zimmermann’s “Zfone Project” has new website and new beta release

Wednesday, February 14th, 2007 by Dan York

Perhaps it has been up for a while, but I just noticed today the new Zfone Project Home Page. Previously Phil Zimmermann had Zfone as a subset of his philzimmermann.com website, but now it’s off on its own sharp-looking site. There’s also news of a new beta for download as of February 9th. Kudos to Phil and his team for launching the new site and, as always, we’re definitely interested in hearing what people think (okay, at least I am).

Building a VoIP Network

Wednesday, January 10th, 2007 by Martyn Davies

Dean Elwood, one of the founders of voipuser.org (a free VoIP service provider and online magazine) recently wrote an interesting article called “How To Build A Voip Network: 7 rules for the VoIP entrepreneur in 2007.“  It’s a great read from someone with experience of creating value from a VoIP service, rather than the usual marketing “talking head”.  It also raises some interesting VoIP security questions, including Session Border Controllers, Lawful Intercept, Denial of Service and confidentiality.

Securing the WLAN Link

Wednesday, December 13th, 2006 by Martyn Davies

At the IET Secure Mobile conference last week, Dr Philip Nobles from Cranfield University in the UK spoke about the subject of wireless LAN security.  He showed the output of a tool running on his laptop on a 40 mile train ride into London.  He had captured a large number of WLANs on the way, of which perhaps 60% were completely unsecured.  In addition, you could see that many were using factory default settings, for example SSIDs (LAN identifier) of ‘netgear’.  So all these sites can be compromised in terms of network sniffing, router hijhacking and theft of bandwidth.

Dr Nobles also spoke about WEP (Wired Equivalent Privacy), the first attempt to introduce encryption to WiFi networks.  I had known that WEP was compromised at least in an academic sense, but I was surprised that practical tools exist for breaking WEP in a very short time. “My router gave up its key in 3 minutes”, Nobles said of his own home router.

In view of this, here are a few ideas for securing your WLAN in the home or the office:

1. Use WPA encryption (WiFi Protected Access) if this is available on your router/client setup.  If not, use WEP in preference to leaving the router ‘open’.  Use keys (passphrases) that will not be easy to guess.

2. Most routers have an option to hide the SSID, i.e. not broadcast the name.  This means that the clients have to know the name explicitly.  This is is good idea to switch on, and makes you look much less interesting on the Netstumbler display.

3. Don’t use the default SSID, and it is better to use a name that will not be vulnerable to dictionary attack, and one that doesn’t hint at your physical location.

4. Similarly, set an admin password on your router, again one difficult to guess or get by dictionary attack.  For example, at one time I used “astro0cosmo0.”

5. Often you can block admin logon to the router from the Internet side, which is a good idea if you don’t need to remote manage it.

6. Some routers have the facility to “lock down” access to the router by only accepting connections from specific MAC addresses.  In my experience this can be inconvenient to manage (for example if a WiFi card is replaced, or if a friend comes to visit with his machine), but it does limit the options for attackers.

7. Similarly, with some routers you can assign IP addresses to specific MAC addresses, and use the firewall to block unknown IP clients.  As above, this can be inconvenient to manage, but it does limit access.