Schneier on Security

@ Bruce,

"if only theoretical, that would allow a surveillance target to thwart the authorities"

Hmm "theoretical" is not the way I would put it the simple answer is it is actually a real problem that the authorities already have in a number of juresdictions (ie there is a limit on bandwidth thus simultanious targets).

The real question is the possability of explotation by those under watch.

As the old saying goes,

"A quart into a pint pot will not go"

Thus at the simplest level it only requires too many simultanious target activities on a single switch for the wire tap channel to be blocked.

However for pen and tap there is a work around in that the CO records all of the information for billing purposes and as Matt notes this info is usually of more interest in the long term.

Going around is still a lot easier than going through. Both at once is even better. Unless the premises are being physically surveilled, a person could get away with generating robo-IMs and VOIP calls at home to kick off on a known tapped line at a certain time while they went down the street and used a disposable prepaid calling card on a pay phone for the real call.

How would you send multiple simultaneous SMS messages? I bet you cannot? Lets see who can list the steps to doing so

Is this not the case with all surveillance?

Yes and I'm sure such an act would be used as casus belli for a budget to more actively surveil whomever. Ex: If they are trying so hard to prevent surveillance... There must be something there.

Better to just stay off the phone, yes? Or at least go with a method of jamming that doesn't LOOK like jamming.

So, all the authorities have to do now, is mining for simultaneous SMS floods to find out, which calls are worth listening to;-)

@sooth sayer

Sure, nearly anything is vulnerable to a DoS attack, the part that makes this noteworthy is such an attack is actually practicle in this case.

@Grim Reaper-

I hope you're being silly.

1) Buy N programmable telephones that can send SMS telephones, where N is greater than 1, and much greater than the number you think you'll need.
2) Synchronize the times on those phones.
3) Write a program for those phones to send an SMS message at a particular time.
4) Wait for that time.

Just a point to remember the "channel" is not just limited at the CO switch end. The LEO end has a limited number of channels that can be connected to.

Thus if you know what LEO is doing the listening and you have splashed a little cash in the right places you now have a many to one possability and thus can "cascade" calls from a number of switches over a short time period to block the LEO end.

There are other tricks that can be used by getting access to the SS7 address of the LEO and just ringing in. But this requires a level of sophistication above and beyond what most people can do.

There are all sorts of other tricks once you get access to the switch, and lets be honest there are people that know how to do this and I guess in these days of malware "cracking for cash" they might find a profitable outlet for there knowledge.

@ Fred P,

With regards to Grim Reaper's comment,

"How would you send multiple simultaneous SMS messages? I bet you cannot? Lets see who can list the steps to doing so"

Your setup will send multiple SMS's but from different IME's thus different phones.

I suspect what Grim Reaper was questioning is the ability to send "multiple non identical SMS to multiple destinations from the same phone".

That indead would be a difficult problem. Although a single phone could be programed up to send an SMS to multiple phones and repeate with different messages they would be sequential. In practice I suspect the network response would be such that the agrigate bit rate would be well below 64Kb/S of a single ISDN barer channel.

@ Clive, Fred P, Grim Reaper

> Your setup will send multiple SMS's but
> from different IME's

I had thought that it wasn't very hard to clone a known IMEI/IMSI and this was a way to eavesdrop on cellular phone conversations. Or are those days long gone, now?

It's quite common for telco networks to run protocols originally designed for limited data rates over completely different and/or much faster layers.

If I was attempting to avoid wiretaps, I wouldn't be relying on this DoS without positive confirmation that it actually works in practice.

over-subscription != DoS...

this only works if:
a) there is no 'filter' at the 'tap' point
b) target has more usable BW than the smallest pipe between 'tap' and 'collector'.

Seriously folks.. I'm disappointed that this even made it here. There are *much* better ways to achieve the goal.. basic steg comes to mind (and yes you can steg voice).

"There are *much* better ways to achieve the goal.."

@notme

O RLY?

What's the goal, then?

Looks plain to me that the goal is merely to encourage the feds to pay the telcos for upgraded link bandwidth.

That furthers the goal of generating higher profits, and increasing stock prices. Which, in turn, leads to higher bonuses for telco execs.

Or you don't think that's a plausible goal?

@ RonK,

"I had thought that it wasn't very hard to clone a known IMEI/IMSI..."

It can be done but it is not as easy as people tend to think.

However there can (or should) be only one phone with a SIM that gives the IMEI/IMSI and both numbers should be unique (one identifies the handset like a MAC address on a network card, the other effectively identifies the SIM and is on the same analagy a little like a fixed IP address).

For receiving GSM you can passivly monitor signals in the cell and see handoff data so can follow a handset around.

It's been a long while since I looked into "phone cloning" on GSM networks, however IIRC if two phones try to register with the network then an error should occure at the network switching center.
However for various resons due to local handoff protocols you can have two handsets registered in adjacent cells etc without the switching center being aware of this and if done correctly can traverse the network to different cell sites.

However if there is any primary traffic such as an incoming call only one handset will get it (the one closest to the original registration cell).

If however more than one handset tries to send at the same time then the network center behaviour will be determind by a number of factors but it should raise an alarm or only accept traffic from one handset.

SMS is however a secondary service and as such may be treated differently to primary traffic, and I have not looked into what might be possible due to "store and forward" or other network managment stratagies.

Like many protocols GSM has certain axioms one of which is "there can only be one" SIM. The result of the axiom not being correct is the assumptions the protocols are designed on fails and unconsidered behaviour can arise that might be exploitable.

It raises an interesting issue. In Iraq something like 20 million of the 27 million citizens have a mobile phone. And due to the dangers of venturing out "phone credit" is being used as electronic currancy with brokers trading phone credits for goods and services (yup prostitutes get paid in phone credits which brings a new side to "call girl"). Most of the trading is done via SMS which begs the question of what if any effect a cloned phone could have on this fledgling E-Currancy...

For SMS, the suggested attack would seem to be trivially defeated by message buffering, which is already a standard feature of SMSCs.

The VoIP attack would seem to work but if I understand it correctly, it costs somewhere in the order of $4/second to carry out (at least at the billing rates around here).

The weakest aspect of all this, though, is that the attacker has no way to know if it has worked, and can only speculate based on the assumed bandwidth provisioning.

Good. The more ways there's to screw the snoops, the better.

In any case, the major problem with all secret services is not that they don't have enough bandwidth, but that they are usually terminally inept. They can make lifes of some unlucky innocents hell, sure; but they seem to be congenitally unable to deal with any real threats.

"... used a disposable prepaid calling card on a pay phone for the real call."

What pay phone? The only working pay phones I've seen in the last couple years have been at Interstate rest areas, and those have signs declaring that the area is under video surveillance.

If you just needed to make a short call, you might have better luck going to a coffee shop and asking a nice random person if you could borrow his or her phone for a quick call.

"When a wiretap is enabled, the phone company's switch establishes a 64-Kbps Call Data Channel to send data about the call to law enforcement."

Since that *IS* the fundamental allocation for a digitized voice channel it was certainly adequate at one time. If this is no longer the case, then it's simply a matter of a spec. falling behind the times.

"When a wiretap is enabled, the phone company's switch establishes a 64-Kbps Call Data Channel to send data about the call to law enforcement."

Is the switch limited to only one such Call Data Channel for all wiretaps on that switch? That's not the implication of the quoted passage, as I read it....

@ PennGwyn,

"Is the switch limited to only one such Call Data Channel for all wiretaps on that switch? That's not the implication of the quoted passage, as I read it....

It is and it is not the spec is not clear on certain things.

Any 64k chanel must have two ends, the DCE and DTE that is the switch initiates a connection with the LEO central office switch.

The COswitch will try to connect to the LEO DTE if it is "on hook" by sending a "ring" signal. If the DTE goes "off hook" then the switch DCE will try to negotiate a data channel.

But if the LEO only has a single DTE only one switch can conneect with only one 64K channel.

If the LEO CO switch has more than one DTE there is then the question of how they are arranged (unique IDs / hunt group), and if DTE channels can be "bonded" for higher data rates etc.

Many of these problems are caused by the "circuit switched" nature of the original X25/ISDN system.

Most can be overcome by using IP based connection protocols with datagram messages. But that as they say is a story for another day.

(I just saw this, reading back issues.)

Sorry, this is wrong. I spent 18 months implementing CALEA for a wireless telcom and tested specifically for this issue.

The simple fact is the telco buffers to disk all the call info -- SMS, numbers dialed, features used, etc. -- and can hold it pretty much indefinitely. Call data -- the actual voice part -- is NOT required to be buffered and will be dropped as soon as the link to the LEO is inactive.

At one point I noticed we had 3 months of test call info buffered for the customer's average CALEA volume. The routine to flush it wasn't working. There was enough disk space to hold YEARS of this stuff. VOICE buffering, however, is a different story. It isn't buffered at all, but sent directly thru the channel to the LEO.

Oh, and it isn't necessarily a 64k channel. Large LEOs like NYPD or the FBI have dedicated circuits that are a hell of a lot bigger than 64k. Not to mention the codecs in use don't require 64k channels...