Author: Martin

In my series on my renewed enthusiasm about Bluetooth (see here and here) I can surprisingly add another entry: Even though it is every now and then amusing to listen to advertisement on the radio I do get bored and annoyed after a while. When recently renting a car for a day and driving overland I got to this point quite quickly. But then I noticed that the car was equipped with a Bluetooth interface for music streaming and telephony. The pairing procedure was not for the faint hearted and one should deny the car's request to access the phone's address book but once done I could stream my music from the phone to the on-board audio system – without advertisement interruptions. Excellent! Voice telephony was also integrated in the system as incoming calls were alerted over the car's loudspeakers.

This quick post was inspired by a comment the previous blog entry about 3G security. As the comment mentioned, 3G security procedures are just used if the SIM card, which should actually be called a UICC (Universal Integrated Circuit Card) these days, contains a USIM (Universal Subscriber Identity Module), i.e. a folder branch and internal logic for 3G security. For details see here.

As also mentioned in the comment, many network operators allow the use of old 2G SIMs (i.e. UICCs with a GSM SIM folder) in their 3G networks. From the outside, a UICC with a 2G SIM and a UICC with a 3G USIM can't be told apart unless the operator has printed something on the SIM that hints its a 3G SIM card. In practice, it's even worse as many network operators still sell 2G UICCs today, probably because they are a couple of cents cheaper.

But this approach now backfires with LTE. Here, the 3GPP specification explicitly states that 2G UICCs can't be used. And indeed, when a user has a 2G SIM card (which he might just have bought recently) he won't be able to use LTE because either the mobile won't even try or because the network rejects the user. I've given it a try and it really doesn't work.

In other words, those network operators on the cheap side will have to exchange a lot of UICCs in the future when they go live with LTE and their customers with an LTE capable device will be stuck in 3G.

One major new feature UMTS introduced when it was designed that GSM did not have was mutual authentication instead of only the device authenticating towards the network. This way, man-in-the-middle attacks can be prevented in which an attacker puts a rouge base station in place and tricks a device into using it instead of the real network. So far I always assumed that the Authentication token (AUTN) that was introduced contained all the magic. But 3G security and ciphering is a bit complex so I never dug down deep enough to actually understand how it really works. Lately, I came across the topic again and this time around I investigated a bit more. So here's how man-in-the-middle attacks are prevented in UMTS:

The story starts with the Authentication token (AUTN). This is a new parameter in UMTS that did not exist in GSM and it is computed in the Home Location Register / Authentication Center (HLR / AuC) and on the SIM card. Input parameters are a random number, which is sent during authentication from the network to the mobile device and the secret key that is only stored in the SIM card and in the Authentication Center and never sent anywhere. Another input parameter I was so far not aware about is a sequence number (SQN) that increases over time. When authentications are performed the mobile device only accepts an AUTN that was generated with a higher sequence number than what it has seen before. In practice, things are a bit complicated by the circuit switched and packet switched core network parts having an individual set of precomputed authentication vectors and each side authenticates a mobile device on its own. In other words sequence numbers increase independently on the core and packet switched side and a mechanism is in place in the mobile device to handle this. How sequence numbers are generated and increased is implementation specific but suffice it to say that the number can only increase and not decrease over time.

At this point we have the AUTN and the sequence number (SEQ) that is encoded in the AUTN to prevent replay attacks, i.e. a reuse of potentially intercepted authentication information. The next and equally vital ingredient is integrity checking of signaling messages that are exchanged between the network and the mobile device. Integrity checking is also based on the secret key and ensures that messages are not altered on the fly by an attacker that has managed to insert itself in the transmission chain. At this point an attacker can still passively eavesdrop on the signaling and user data exchange. Therefore the final ingredient is ciphering of signaling messages and user data to prevent this as well.

To quickly summarize: The following things are needed to prevent man-in-the-middle attacks and eavesdropping:

• An Authentication Token (AUTN) so the mobile knows the Authentication Center trusts the network which performs authentication

• A Sequence Number (SEQ) embedded in the authentication token to prevent replay attacks

• Integrity checking so an attacker can't act as a man in the middle

• Ciphering to prevent passive eavesdropping

For much more details see this paper from adventurous days back in 2001.

Back in April 2013 the Prepaid Wireless Internet Wiki I started many years ago suddenly vanished from the cloud. At the time it was hosted by Wetpaint and I found no way to contact them to find out what happened. Bitten by the cloud, yet again… When I recently searched something on the Internet I suddenly rediscovered the Wiki again, this time hosted on WikiFoundry!

It seems the Wetpaint wikis were at some point bought by WikiFoundry and they put the Prepaid Wireless Internet wiki back online. Gee, well thanks for that! It looks like it hasn't been discovered by many, as there haven't been many modifications since then. But my login data was still valid there so I can still (or again?) administer the site. The new 'owner' was also nice enough to provide an export option. Thanks, that's great, just in case this arrangement doesn't last, either.

So there we go, I've put a link to the Wiki back on the blog and hope it will be used as it was in the 'old days'.

Cellular antennas are everywhere to be found on top of buildings these days. Those vertically long white antennas, usually three at a time pointing in different directions. But little is known how they look like on the inside. And there must be quite something in them these days as most of them support several independent frequency ranges and also two polarizations per antenna (horizontal and vertical) for MIMO and RX/TX diversity. I've had a number of posts on this blog on antennas over the years and my two favorites are 'Antenna in Ruins' and 'Antenna Stuff'. But so far I've never seen the inside of one. But recently I stumbled over a picture taken in the German Technical Museum and available on Wikipedia here that shows how it looks inside.

One and a half years ago I wrote a blog post about the growing pains of taking the Paris metro and accessing the Internet over the 2G network that just couldn't absorb the load anymore. At the time I noted that there were talks between the metro and one of the French network operators to deploy 3G and LTE in the metro. Sadly enough it still hasn't happened one and a half years later and the 2G network now just fails completely for Internet access. A sad state of affairs. How long do I have to wait before coming back and being positively surprised?

But to end this post with a positive note I'd like to add that outside the metro, using 3G has become a lot simpler from an international roaming point of view now because European roaming data rates of my home network operator have reached a level where day to day web browsing on the mobile and some data from the notebook is affordable enough so I don't have to ration things quite that strictly anymore. Good!

… yes you read right, the upcoming Chaos Communication Congress will have a 100 Gbit/s Ethernet backhaul. When I first read it in the press I had a hard time to believe it but here's the original blog post on the CCC's web site (and they know what they are talking about…)

Last year's congress was attended by 6000 participants. If you divide one value by the other that's 16 Mbit/s per participant if everybody suddenly decided to download something at the same time. As this will unlikely be the case during any moment during the conference you can imagine what kind of connectivity experience one will have there. Unfortunately I've never been able to adapt to their timing. Next year perhaps.

Let's be a bit crazy and compare the 100 Gigabit/s link to, let's say the aggregate throughput of Vodafone Germany on new year's eve 2011 which I calculated was 7.9 Gbit/s. And the fixed line interconnect traffic of the German incumbent the same day peaked at 1.800 Gbit/s as reported here.

100 Gbit/s for 6000 congress participants. Sounds like a very very fat pipe indeed!

Seldom but from time to time I encounter networks that my VPN struggles with. Sometimes the VPN tunnel is established just fine, pings are going through the tunnel but web browsing and other download activities just don't work. The effect is caused by fragmentation, i.e. the IP packet size of the downlink is too large for some part of the network between me and the server and hence the IP packet is split somewhere or simply discarded because it has become too long.

The remedy for such behavior is to reduce the Maximum Transfer Unit (MTU) for the tunnel interface on my computer to a lower values such as 1200 bytes and things come back to life. What I always wondered, though but never had the time to figure out was how the server is notified of the reduced MTU!?

When I recently encountered the scenario again I had a closer look at the TCP connection establishment and found that the MTU size is contained in the first IP SYNchronize packet in the TCP header. The parameter that conveys the maximum size a TCP packet can have is contained in the Maximum Segment Size (MSS) parameter. The first image on the left shows the default MSS over my Ethernet at home, 1460 bytes. Together with the additional IP overhead the IP packet size is 1506 bytes. The MTU size configured on my Ethernet interface is 1500 bytes.

When I change the MTU size on the fly on my Linux machine with 'sudo ifconfig eth1 mtu 800', my MTU size shown by 'ifconfig' becomes 800. The MSS size then becomes 760 bytes and the Ethernet packet is 814 bytes long. The 14 extra bytes are for the Ethernet header that is not counted in the maximum MTU size because the Ethernet header is discarded at the next router and replaced by another Ethernet header or some other protocol if the next hop is over a different network technology.

There we go, another mystery solved.

Over the years I've used Metageek's WiSpy USB tracer a lot to figure out what is going on in the 2.4 GHz Wi-Fi band. When I was recently investigating a slow Wi-Fi which I ultimately nailed to a runaway Wi-Fi card I also picked up the signals of my wireless mouse and keyboard alongside my own Wi-Fi signal. The image on the left shows the three signals. The mouse transmitted near channel 2, the keyboard near channel 7 and the Wi-Fi center frequency is on channel 11. The green dots in the lower part of the image even show when I used the mouse and when I used the keyboard. The Wi-Fi was pretty dormant during the trace and the image was only created by the beacon frames of the Wi-Fi access point.