Allicient

Well, it’s finally happened: the elements necessary to build a computer setup capable of passively decrypting GSM have been cobbled together by cryptographer/computer scientist Karsten Nohl. It has been known for some years now that A5/1 – the stream cipher used to protect most GSM calls – was weak, c.f. the wikipedia page on A5/1 for a list of results. Practical attacks were considered slightly more difficult due the requirement for radio equipment and computation time. So despite expensive commercial products being available for a long time, there hasn’t been anything concrete that the general public can try. Until now.

Unveiled at the Chaos Communications Congress, he presents a solution utilising easily available open source software, inexpensive radio equipment and recently available rainbow tables. The combination means that it is now possible to capture and decrypt packets with a high degree of certainty.

What does this mean? It means that monitoring mobile calls and text messages is no longer limited to the Police, Government and criminal gangs that can afford the existing equipment retailing at around £20,000 – any spotty teenager that can afford around £1,500 worth of equipment can in theory intercept your calls. And make calls from your number, and fake SMS messages from your number, etc.

The bright shining light that the GSM consortium had in mind to replace A5/1 – A5/3, which is really just the Kasumi block cipher – is not going to help. Well, on a cursory reading it seems to depend on who you ask: the documentation I had previously read suggested the protocol was changed and that although Kasumi has theoretical breaks, it would be beyond the boundary of a practical attack (where have we heard that before); the presentation slides provided by Nohl however suggest that the mobile handset can be forced to encrypt packets using A5/1 with the same key allowing key recovery, and that Kasumi is fairly weak. Perhaps I’m just mixing up 3G specifications with the older GSM specs… if anyone actually knows the details here I’d appreciate them.

Personally, I think all this is a good thing: it evens the paying field – now everyone should know the security risks with non-provider mobile phone monitoring, not just criminals and bored rich folk.

There are commercial products available – again at significant cost – that can protect mobile calls by using strong encryption and forwarding calls via the data channel; they only however work on certain mobiles and are not in wide use. Given the ever increasing bandwidth available on mobile devices, I cannot imagine it will be long before an open source project pops up with a cross-platform solution of similar nature. The one caveat is that both handsets in the call must use the same software.

In the past few months, I have become increasingly aware of a glaring problem with the security model banks, utility companies, et al, use for their customer services. So a slightly irate and vitriolic post follows…

As online security gradually improves, the security of telephone based services has either stagnated or actually deteriorated. The old maxim of a chain being only a strong as it’s weakest link is sitting in eager anticipation of again being proven correct.

The problems can be split into some broad classifications:

i) the protection against replay attacks that (most) banks use for their online services are not used over the telephone;

ii) authentication credentials are often shared between strong online and weak phone services;

iii) static personal details are used as part of the authentication process over the telephone;

iv) there is an invalid assumption made that the phone call is private and secure;

v) telephone requests tend to “trump” anything done via online services;

vi) unsolicited calls are made from banks to customers that require only the customer to authenticate;

vii) catch phrases are overriding common sense.

The first problem highlighted above, (i), can be illustrated by example. Most banks request only a subset of a “PIN” or password when authenticating to an online banking service, however over the phone almost all banks ask for the full login credentials. For example, the Co-operative Bank has recently improved it’s online security immensely: logins only request a subset of details, there is a second stage of authentication whereby a random selection of one of four preset questions are asked, and most importantly before any transaction can be performed it must be authenticated via a smart card + card reader device. However, upon phoning, the automated service immediately asks for the full PIN. The problem is exacerbated by (iv), specifically that online services are at least encrypted using SSL/TLS, however phone calls are easily tapped if the attacker is physically in the local area.

The second problem, (ii), has some not-so-subtle ramifications. If a phone call to a bank’s customer services is monitored by an attacker, they will often have the credentials necessary to login online. From an anonymity point of view, it would be much more favourable for an attacker to action transactions using the online service as opposed to the telephone service.

The third problem, (iii), is that most telephone services use an automated system that verifies account number against “PIN” or password, then passes the call onto a real advisor. At this point, the advisor will attempt to further confirm the callers identity by asking the standard “name, address, postcode, date of birth” questions. Unfortunately, unless you are the Messiah, things like date of birth won’t change that often. So considering that these details are usually easy to come by and are exposed over an unsecure line anyway, it is worrying that so much trust is placed in them.

The fourth problem, (iv), is that most banks, government departments, etc assume that the telephone is a secure method of communication. It is not. Technologically, it is trivial to tap a person’s phone line. I have lost count of the amount of very personal details and information that I have had no choice but to submit over the phone.

The fifth problem, (v), is that once you’ve authenticated yourself to a bank or similar institution over the phone – they will usually action almost anything. So if an attacker has managed to garner your authentication credentials from previous phone calls, they will pretty much have carte-blanche.

Now onto (vi). This is probably the most concerning development. In the last six months I have had a bank, a utility company, and several other similar institutions phone me without my prior request, then ask me to authenticate myself to them. Each time I have illustrated that I do not know who they are, and they they could be a complete stranger calling to obtain my details. Out of the lot of them, the only one to both understand what I was saying and to be able to appropriately authenticate themselves to me first was Scottish Power.

The last one is more insidious than it first appears, (vii). When I challenged the customer services representatives over (vi), the response I got to every question was “but it’s Data Protection”. It was obvious that the person on the other end of the phone understood what I was saying but it seems company policy generally overrides the security beneficial attribute of common sense. So the public are now left trying to swallow a bunch of meaningless catch phrases like “data protection” and “passing security”: I wonder how many of the people writing the guidelines for these departments has ever read the contents of the Data Protection Act.

There are of course mitigating factors. The two that come to mind are using a 3G mobile which has half decent encryption as standard for (iv), and caller id for (vi). However these are not always available and are not addressing the core problems: namely that trust in the security of phone services are vastly over estimated.

Ah well, rant over.

UPDATED 12th April 2010: Added [] extra meaning in title; changed author.