Category: Uncategorized

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.

Over the past days we've heard in the media that the NSA has infected at least 50.000 computers worldwide with digital sleeper agent software, as Techcrunch puts it. Obviously this has created a lot of outrage across the industry and also in the non-technical media. But despite all the outrage nobody really commented that actively infecting computers is by an order of magnitude worse from an ethical point of view than anything we have heard about the NSA's doings in recent months.

Listening passively on transmission links and harvesting data is one thing (which is already bad enough by itself), but infecting 50.000 computers with spyware is quite quite another. And I wonder who those 50.000 computers belong to!? Did the NSA really find that many terrorists out there? Somehow I doubt it. As if it isn't already bad enough that companies and individuals have to fight criminals trying to infect their PCs with malware that do all sorts of things like stealing passwords, extorting money, and so on. No, now we also have to defend ourselves against nation states doing similar things on a similar scale!?

It makes me wonder when this will go from accusation to proof? What it would take is the code or the executable of the malware and a link back to it's origin. With that in hand it wouldn't take long to actually find the malware in practice (unless all copies destroy themselves without leaving a trace). And then imagine the malware is found on computers of governments and private companies around the world. This is the point when the abstract becomes personalized. And when you look at what happened when the German Chancelor found out her phone calls were listened to you get an idea what is likely to happen in this case. Is it really possible to cover up 50.000 infections?

It really depresses me that a nation goes that far… And while we are at it: What makes us think it is only one nation who thinks it's a good idea to do such things?

One train of thought I followed with my easy smartphone Wi-Fi tracing setup I wrote about recently is how often a typical smartphone contacts the network per hour even if it is not used and just lies on the table and what impact that has on the cellular network in a larger context. Even though I monitored the devices behavior over Wi-Fi the result can be applied to cellular as well as it is likely that most applications do not make a difference anymore between Wi-Fi and cellular connectivity. The result is quite interesting:

Even without user interaction my smartphone contacts the network 10 times per hour. Out of these, 4 times is for checking email. Another 4 times Android calls home to Google, mainly using a Google Talk domain, even though I've disabled the app. Less frequently a DNS query and subsequent traffic can be observed to a number of additional Google domains. I feel quite observed by such unwanted behavior but there's something that can be done about it with a rooted phone as I've described here in the past. Further connections are made for various other purposes. My calendar and address book are synchronized with my Owncloud server at home every four hours, the NTP server is queried to keep the clock in synch, crash reports are sent to crashlytics.com (have I consented to this?), the weather app requests updates, the GPS requests ephemeris data periodically, etc.

So what does this mean on a larger scale? Let's say a network operators has 15.000 3G base stations (extrapolated from here) and 10 million smartphones. If those smartphones were evenly distributed across all base stations there would be around 660 smartphones per base station or around 220 smartphones per sector. If each smartphone connected to the network 10 times an hour that's 2200 requests an hour per sector. If the connection is held for 10 seconds on average, that's 2200 requests / (60 minutes * 60 seconds / 10) = 6 concurrent connections just for the background traffic of the devices.

Some cells are obviously busier than others so some cells probably see two or three times this number, i.e. 15-20 concurrent connections just for background traffic. As the number of concurrent users in 3G cells is likely to be less than a three digit figure that's quite a sizable percentage. And the 10 connections per hour is perhaps even a conservative number as many subscribers use instant messengers that need to send frequent TCP keep-alive packets so they don't loose connectivity to the server. On the other side, many smartphones are used over Wi-Fi, especially when people are at home, which is likely to significantly reduce background traffic over cellular in residential areas. Not so in business areas, however.

So where do we go from here? One good thing is that LTE networks are mostly in place now and many new smartphones, especially those of heavy users are LTE capable by now. That significantly reduces the load on 3G networks. And from what I hear the number of simultaneous users in an LTE cell can be much higher than in a 3G cell. The right technology at the right time.